Bug#1061437: firefox-esr: Fails to build with Python 3.12 as default

2024-02-20 Thread Mike Hommey
On Tue, Feb 20, 2024 at 11:59:11PM -0500, Jeremy Bícha wrote:
> Amin Bandali collected several other fixes that were necessary for
> mozjs115 to build with Python 3.12 beyond the one that I noticed was
> included in 115.8.
> 
> You can find them in the python3.12 patches in
> https://salsa.debian.org/gnome-team/mozjs/-/tree/debian/115/master/debian/patches
> 
> (Note that mozjs115 is partially stripped down so I can't guarantee
> that even those patches are complete for firefox-esr's needs.)
> 
> Therefore, I presume we will need to reopen this bug, but I have not
> tried building firefox-esr myself.

I've totally built Firefox 115esr with python 3.12 without those
patches. At quick glance, they touch code that is not involved during
the build.

Mike



Bug#1059241: [firefox] hi-dpi broken for vertical tab list

2023-12-21 Thread Mike Hommey
On Fri, Dec 22, 2023 at 01:50:34AM +, Lyndon Brown wrote:
> On Fri, 2023-12-22 at 10:31 +0900, Mike Hommey wrote:
> > What happens if you run with MOZ_ENABLE_WAYLAND=0 ?
> > 
> > Mike
> 
> Back to normal. I can scroll the full list, and the list is no longer
> 100% of screen height, it's located just below the button and extends
> down just short of the bottom of the screen.
> 
> I happened to noticed that this also makes bug #1059242 go away.

Would you mind filing these issues upstream?
https://bugzilla.mozilla.org/enter_bug.cgi?product=Core=Widget%3A%20Gtk

Mike



Bug#1059241: [firefox] hi-dpi broken for vertical tab list

2023-12-21 Thread Mike Hommey
On Fri, Dec 22, 2023 at 01:09:01AM +, Lyndon Brown wrote:
> Package: firefox
> Version: 121.0-0
> Severity: important
> 
> The vertical tab list (accessed via the 'down arrow' in the tab bar, to
> the right of the new tab '+' button) is now no longer working correctly
> for Hi-DPI as of version 121.0-1.
> 
> I have many windows with many tabs. Previously with version 120 I had
> no problem scrolling the entire tab list. Now, depending upon which tab
> I have selected, I cannot scroll a certain number of tabs at the top
> and/or bottom of the list into view.
> 
> Notably when trying to scroll to the very top/bottom I see the
> scrollbar going out of view beyond the limits of the screen height.
> 
> I have a Hi-DPI screen set to 200% scaling. Experimenting, if I switch
> to 100% scaling then the problem goes away, being able to scroll the
> full list as previously (with the list drawn with 100% screen height
> regardless of whether the window is maximized or not).
> 
> So it seems that a small regression was introduced.
> 

What happens if you run with MOZ_ENABLE_WAYLAND=0 ?

Mike



Bug#1059171: firefox-esr: Firefox freezes after upgrade from 115.5 to 115.6.0esr-1~deb12u1

2023-12-20 Thread Mike Hommey
On Wed, Dec 20, 2023 at 10:47:19PM +0100, pierre wrote:
> Package: firefox-esr
> Version: 115.6.0esr-1~deb12u1
> Severity: important
> X-Debbugs-Cc: pierre_aussag...@yahoo.fr, t...@security.debian.org
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> 
> apt update && apd upgrade
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> Launch firefox-esr
> 
>* What was the outcome of this action?
> 
> Firefox starts, but stay freezed with 100% core usage. Impossible to change
> tabs, nor close tabs, nor close firefox.

Which process specifically is using the CPU?

> Only solution is to kill it.
> 
>* What outcome did you expect instead?
> 
> Work as expected.
> 
> I tried :
> 
> MOZILLA_DISABLE_PLUGINS=1 firefox-esr
> and it stills freeze
> 
> firefox-esr -safe-mode
> and it stills freeze

Does it happen if you use 115.6.0esr from upstream[1]?

1. 
https://archive.mozilla.org/pub/firefox/releases/115.6.0esr/linux-x86_64/en-US/firefox-115.6.0esr.tar.bz2



Bug#1056561: gcc-12: Upcoming firefox-esr FTBFS on stable

2023-11-22 Thread Mike Hommey
Package: gcc-12
Version: 12.2.0-14
Severity: important

Dear Maintainer,

Future versions of firefox-esr will contain code (related to security)
that currently fails to compile with GCC 12.2. The failure is a
regression from GCC 11, and was fixed in 12.3. Applying the patch[1] to
12.2 fixes the build issue. The corresponding upstream bug report is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107461.  Interestingly,
there is another patch in the bug, but it's somehow not required.

Could you apply the patch to 12.2?

1. 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=31924665c86d47af6b1f22a74f594f2e1dc0ed2d



Bug#1052002: firefox: FTBFS: ERROR: Cannot find wasi headers or problem with the wasm compiler. Please fix the problem. Or build with --without-wasm-sandboxed-libraries

2023-09-15 Thread Mike Hommey
reassign 1052002 clang-16
affects 1052002 firefox
affects 1052002 firefox-esr
thanks

On Fri, Sep 15, 2023 at 08:19:17PM +0200, Aurelien Jarno wrote:
> Source: firefox
> Version: 117.0.1-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> 
> Dear maintainer,
> 
> firefox fails to build from source. From my build log on amd64:
> 
> | checking for vpx >= 1.10.0... yes
> | checking MOZ_LIBVPX_CFLAGS... 
> | checking MOZ_LIBVPX_LIBS... -lvpx -lm
> | checking for vpx/vpx_decoder.h... yes
> | checking for vpx_codec_dec_init_ver... yes
> | checking for nasm... /usr/bin/nasm
> | checking nasm version... 2.16.01
> | checking for the wasm C compiler... /usr/bin/clang
> | checking whether the wasm C compiler can be used... yes
> | checking the wasm C compiler version... 16.0.6
> | checking the wasm C compiler works... yes
> | checking the wasm C compiler can find wasi headers... yes
> | checking the wasm C linker can find wasi libraries... yes
> | checking for the wasm C++ compiler... /usr/bin/clang++
> | checking whether the wasm C++ compiler can be used... yes
> | checking the wasm C++ compiler version... 16.0.6
> | checking the wasm C++ compiler works... yes
> | checking the wasm C++ compiler can find wasi headers... 
> | DEBUG: Creating `/tmp/conftest.t4tbmgsv.cpp` with content:
> | DEBUG: | #include 
> | DEBUG: | int
> | DEBUG: | main(void)
> | DEBUG: | {
> | DEBUG: | 
> | DEBUG: |   ;
> | DEBUG: |   return 0;
> | DEBUG: | }
> | DEBUG: Executing: `/usr/bin/clang++ --target=wasm32-wasi 
> /tmp/conftest.t4tbmgsv.cpp -c`
> | DEBUG: The command returned non-zero exit status 1.
> | DEBUG: Its error output was:
> | DEBUG: | /tmp/conftest.t4tbmgsv.cpp:1:10: fatal error: 'cstring' file not 
> found
> | DEBUG: | #include 
> | DEBUG: |  ^
> | DEBUG: | 1 error generated.
> | ERROR: Cannot find wasi headers or problem with the wasm compiler. Please 
> fix the problem. Or build with --without-wasm-sandboxed-libraries.
> | make[1]: *** [debian/rules:228: stamps/configure-browser] Error 1
> | make[1]: Leaving directory '/<>'
> | make: *** [debian/rules:329: build-arch] Error 2
> | dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
> status 2

This is a regression from the upgrade to clang 16.

with clang 14:
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/wasm32-wasi/c++/v1
 /usr/lib/llvm-14/lib/clang/14.0.6/include
 /usr/local/include
 /usr/include/wasm32-wasi
 /usr/include
End of search list.

with clang 16:
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/llvm-16/lib/clang/16/include
 /usr/local/include
 /usr/include/wasm32-wasi
 /usr/include
End of search list.

Note how /usr/include/wasm32-wasi/c++/v1 is missing.

Mike



Bug#1042859: cargo: Please upgrade to at least 0.67.0

2023-08-01 Thread Mike Hommey
Package: cargo
Version: 0.66.0+ds1-1
Severity: normal

0.66 is the version of cargo that goes alongside rustc 1.65.
0.67 is the version of cargo that goes alongside rustc 1.66.
Unstable and testing have rustc 1.66, so cargo should be updated to at
least version 0.67.

Mike



Bug#1041016: RM: pkg-mozilla-archive-keyring -- ROM; Outdated and useless

2023-07-13 Thread Mike Hommey
Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove

As per the RC bug against the package, the key it contains is expired,
and the repository that was signed by the key has not been in use
for years. It's time to retire the package completely.

Mike



Bug#1039566: "Uncaught exception" on crypto.getRandomValues(new Uint32Array(32))

2023-06-27 Thread Mike Hommey
On Tue, Jun 27, 2023 at 11:39:12AM +0200, Philipp Marek wrote:
> Package: firefox
> Version: 114.0-1
> Severity: grave
> X-Debbugs-Cc: phil...@marek.priv.at
> 
> Websites that need randomness ([1]) are broken,
> on both Debian FF 113.0.2 and 114.0 (114.0.2 not yet available for amd64).
> 
> Reproduced with a new profile without any plugins.
> 
> strace shows FF being able to use getrandom(),
> so it seems to be a userspace problem.
> 
> 
> 114.0.2 from upstream works as expected;
> Mozilla chat recommended asking the packaging team.
> 
> 
> Ad 1:
> - banking.bank99.at uses crypto.getRandomValues() even before login

"The server at banking.bank99.at is taking too long to respond."

> - RedHat support webpage uses getRandomUUID after login
> Both fail with "OperationError: The operation failed for an 
> operation-specific reason"

Obviously, I can't reproduce with this since I can't login...

I also can't reproduce calling the crypto.randomUUID and
crypto.getRandomValues functions from the devtools console...

Try downgrading libnss3.

Mike



Bug#1038889: (No Subject)

2023-06-22 Thread Mike Hommey
On Thu, Jun 22, 2023 at 08:48:23PM +, arizona.rover wrote:
> Thread 1 "pidgin" received signal SIGILL, Illegal instruction.
> 0x7fffdb7489ab in fadd (f2=0x7fffaa60, f1=0x7fffaa40, 
> out=0x7fffaac0)
> at verified/curve25519-inline.h:40
> 40  verified/curve25519-inline.h: No such file or directory.

Can you provide the output from `bt full`?



Bug#1038889: (No Subject)

2023-06-22 Thread Mike Hommey
On Thu, Jun 22, 2023 at 06:38:15PM +, arizona.rover wrote:
> Pidgin is dying on start-up too due to "an illegal instruction"
> 
> Thread 1 "pidgin" received signal SIGILL, Illegal instruction.
> 0x7fffdb7489ab in ?? () from /lib/x86_64-linux-gnu/libfreeblpriv3.so

Can you install libnss3-dbgsym and get another backtrace?

Mike



Bug#1038434: zfsutils-linux: zfs-load-key is not run during (systemd) boot

2023-06-18 Thread Mike Hommey
Package: zfsutils-linux
Version: 2.1.11-1
Severity: normal

Dear Maintainer,

There is a zfs-load-key service that is masked, and as such never
starts, and the script in init.d doesn't do anything either because of
that. The end result is that encrypted zfs volumes won't mount
automatically during boot, and I need to manually run `zfs load-key -a`
and `zfs mount -a`.

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

Kernel: Linux 6.1.0-9-amd64 (SMP w/64 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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 zfsutils-linux depends on:
ii  init-system-helpers  1.65.2
ii  libblkid12.38.1-5+b1
ii  libc62.36-9
ii  libnvpair3linux  2.1.11-1
ii  libuuid1 2.38.1-5+b1
ii  libuutil3linux   2.1.11-1
ii  libzfs4linux 2.1.11-1
ii  libzpool5linux   2.1.11-1
ii  python3  3.11.2-1+b1

Versions of packages zfsutils-linux recommends:
ii  zfs-dkms [zfs-modules]  2.1.11-1
pn  zfs-zed 

Versions of packages zfsutils-linux suggests:
pn  nfs-kernel-server   
pn  samba-common-bin
pn  zfs-initramfs | zfs-dracut  

-- Configuration Files:
/etc/sudoers.d/zfs [Errno 13] 許可がありません: '/etc/sudoers.d/zfs'

-- no debconf information


Bug#1038271: linux-image-6.1.0-9-amd64: Logitech trackpad T651 doesn't work anymore

2023-06-17 Thread Mike Hommey
On Sun, Jun 18, 2023 at 08:15:43AM +0900, Mike Hommey wrote:
> On Sun, Jun 18, 2023 at 06:09:57AM +0900, Mike Hommey wrote:
> > On Sat, Jun 17, 2023 at 01:20:30AM +0200, Diederik de Haas wrote:
> > > Control: tag -1 -moreinfo
> > > Control: found -1 6.1.20-1
> > > 
> > > On Saturday, 17 June 2023 01:00:58 CEST Mike Hommey wrote:
> > > > > 6.1.12-1 and 6.1.15-1 are good. 6.1.20-1 is the first broken one.
> > > 
> > > Excellent, thanks. This is already very useful.
> > > 
> > > > > > A `git bisect` would be best, but grabbing these intermediate 
> > > > > > versions
> > > > > > (from snapshot.debian.org) is the quickest way to narrow the range.
> > > > > 
> > > > > Last time I tried to build Debian linux kernels, it was spending a 
> > > > > large
> > > > > amount of time building packages I don't need, and finding the right
> > > > > incantation to reduce that load was not straightforward, and I can't
> > > > > find my notes, unfortunately. If you have instructions I can use to go
> > > > > through a bisect in a quick manner, I'm all ears.
> > > > 
> > > > Although, if you have instructions to just build the one module and 
> > > > avoid
> > > > rebooting, that would be even better.
> > > 
> > > I _think_ building just one module or without rebooting is not possible.
> > > 
> > > The 'official' instructions: 
> > > https://wiki.debian.org/DebianKernel/GitBisect
> > > 
> > > I know some things to reduce what gets build, like f.e. what's described 
> > > here:
> > > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.7
> > > And there's also a facility to work with _build profiles_.
> > > But I don't know if or how that could be applied to the 'official' 
> > > instructions
> > > as that deals with the upstream kernel source directly.
> > > 
> > > Hopefully one of the (more) experienced people chimes in with 
> > > actual useful things ...
> > 
> > I was able to build the relevant module only. The regression comes from
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=337c3624bcb008f92bab38c8fc4cdf97ae5313a2
> 
> I sent a patch upstream, but it's not showing up on the archives yet.
> I'll update with a link when I have one.

Here we go:
https://patchwork.kernel.org/project/linux-input/patch/20230617230957.6mx73th4blv7o...@glandium.org/

Mike



Bug#1038271: linux-image-6.1.0-9-amd64: Logitech trackpad T651 doesn't work anymore

2023-06-17 Thread Mike Hommey
On Sun, Jun 18, 2023 at 06:09:57AM +0900, Mike Hommey wrote:
> On Sat, Jun 17, 2023 at 01:20:30AM +0200, Diederik de Haas wrote:
> > Control: tag -1 -moreinfo
> > Control: found -1 6.1.20-1
> > 
> > On Saturday, 17 June 2023 01:00:58 CEST Mike Hommey wrote:
> > > > 6.1.12-1 and 6.1.15-1 are good. 6.1.20-1 is the first broken one.
> > 
> > Excellent, thanks. This is already very useful.
> > 
> > > > > A `git bisect` would be best, but grabbing these intermediate versions
> > > > > (from snapshot.debian.org) is the quickest way to narrow the range.
> > > > 
> > > > Last time I tried to build Debian linux kernels, it was spending a large
> > > > amount of time building packages I don't need, and finding the right
> > > > incantation to reduce that load was not straightforward, and I can't
> > > > find my notes, unfortunately. If you have instructions I can use to go
> > > > through a bisect in a quick manner, I'm all ears.
> > > 
> > > Although, if you have instructions to just build the one module and avoid
> > > rebooting, that would be even better.
> > 
> > I _think_ building just one module or without rebooting is not possible.
> > 
> > The 'official' instructions: https://wiki.debian.org/DebianKernel/GitBisect
> > 
> > I know some things to reduce what gets build, like f.e. what's described 
> > here:
> > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.7
> > And there's also a facility to work with _build profiles_.
> > But I don't know if or how that could be applied to the 'official' 
> > instructions
> > as that deals with the upstream kernel source directly.
> > 
> > Hopefully one of the (more) experienced people chimes in with 
> > actual useful things ...
> 
> I was able to build the relevant module only. The regression comes from
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=337c3624bcb008f92bab38c8fc4cdf97ae5313a2

I sent a patch upstream, but it's not showing up on the archives yet.
I'll update with a link when I have one.

Mike



Bug#1038271: linux-image-6.1.0-9-amd64: Logitech trackpad T651 doesn't work anymore

2023-06-17 Thread Mike Hommey
On Sat, Jun 17, 2023 at 01:20:30AM +0200, Diederik de Haas wrote:
> Control: tag -1 -moreinfo
> Control: found -1 6.1.20-1
> 
> On Saturday, 17 June 2023 01:00:58 CEST Mike Hommey wrote:
> > > 6.1.12-1 and 6.1.15-1 are good. 6.1.20-1 is the first broken one.
> 
> Excellent, thanks. This is already very useful.
> 
> > > > A `git bisect` would be best, but grabbing these intermediate versions
> > > > (from snapshot.debian.org) is the quickest way to narrow the range.
> > > 
> > > Last time I tried to build Debian linux kernels, it was spending a large
> > > amount of time building packages I don't need, and finding the right
> > > incantation to reduce that load was not straightforward, and I can't
> > > find my notes, unfortunately. If you have instructions I can use to go
> > > through a bisect in a quick manner, I'm all ears.
> > 
> > Although, if you have instructions to just build the one module and avoid
> > rebooting, that would be even better.
> 
> I _think_ building just one module or without rebooting is not possible.
> 
> The 'official' instructions: https://wiki.debian.org/DebianKernel/GitBisect
> 
> I know some things to reduce what gets build, like f.e. what's described here:
> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.7
> And there's also a facility to work with _build profiles_.
> But I don't know if or how that could be applied to the 'official' 
> instructions
> as that deals with the upstream kernel source directly.
> 
> Hopefully one of the (more) experienced people chimes in with 
> actual useful things ...

I was able to build the relevant module only. The regression comes from
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=337c3624bcb008f92bab38c8fc4cdf97ae5313a2

Mike



Bug#1038271: linux-image-6.1.0-9-amd64: Logitech trackpad T651 doesn't work anymore

2023-06-16 Thread Mike Hommey
On Sat, Jun 17, 2023 at 07:59:17AM +0900, Mike Hommey wrote:
> On Sat, Jun 17, 2023 at 12:13:13AM +0200, Diederik de Haas wrote:
> > Control: tag -1 moreinfo
> > 
> > On Fri Jun 16, 2023 at 11:21 PM CEST, Mike Hommey wrote:
> > > Package: src:linux
> > > Version: 6.1.27-1
> > >
> > > After upgrading to bookworm, my bluetooth trackpad stopped working. It's
> > > properly connected, and `libinput list-devices` displays this message:
> > >
> > > event15 - Logitech Rechargeable Trackpad T651: kernel bug: device has min 
> > > == 
> > max on ABS_MT_POSITION_X
> > >
> > > It worked with earlier kernel versions. I went back to one I had at hand
> > > from before the upgrade (6.1.0-0.deb11.5-amd64), and it worked again,
> > 
> > Version 6.1.0-0.deb11.5 should be the same as version 6.1.12-1.
> > If would be useful if you could verify that with the non-backports kernel
> > it also works again.
> > If that's the case, could you try newer versions (6.1.15-1, 6.1.20-1 and
> > 6.1.25-1) to find the newest kernel version that still works?
> 
> 6.1.12-1 and 6.1.15-1 are good. 6.1.20-1 is the first broken one.
> 
> > A `git bisect` would be best, but grabbing these intermediate versions
> > (from snapshot.debian.org) is the quickest way to narrow the range.
> 
> Last time I tried to build Debian linux kernels, it was spending a large
> amount of time building packages I don't need, and finding the right
> incantation to reduce that load was not straightforward, and I can't
> find my notes, unfortunately. If you have instructions I can use to go
> through a bisect in a quick manner, I'm all ears.

Although, if you have instructions to just build the one module and avoid
rebooting, that would be even better.

Mike



Bug#1038271: linux-image-6.1.0-9-amd64: Logitech trackpad T651 doesn't work anymore

2023-06-16 Thread Mike Hommey
On Sat, Jun 17, 2023 at 12:13:13AM +0200, Diederik de Haas wrote:
> Control: tag -1 moreinfo
> 
> On Fri Jun 16, 2023 at 11:21 PM CEST, Mike Hommey wrote:
> > Package: src:linux
> > Version: 6.1.27-1
> >
> > After upgrading to bookworm, my bluetooth trackpad stopped working. It's
> > properly connected, and `libinput list-devices` displays this message:
> >
> > event15 - Logitech Rechargeable Trackpad T651: kernel bug: device has min 
> > == 
> max on ABS_MT_POSITION_X
> >
> > It worked with earlier kernel versions. I went back to one I had at hand
> > from before the upgrade (6.1.0-0.deb11.5-amd64), and it worked again,
> 
> Version 6.1.0-0.deb11.5 should be the same as version 6.1.12-1.
> If would be useful if you could verify that with the non-backports kernel
> it also works again.
> If that's the case, could you try newer versions (6.1.15-1, 6.1.20-1 and
> 6.1.25-1) to find the newest kernel version that still works?

6.1.12-1 and 6.1.15-1 are good. 6.1.20-1 is the first broken one.

> A `git bisect` would be best, but grabbing these intermediate versions
> (from snapshot.debian.org) is the quickest way to narrow the range.

Last time I tried to build Debian linux kernels, it was spending a large
amount of time building packages I don't need, and finding the right
incantation to reduce that load was not straightforward, and I can't
find my notes, unfortunately. If you have instructions I can use to go
through a bisect in a quick manner, I'm all ears.

Mike



Bug#1038271: linux-image-6.1.0-9-amd64: Logitech trackpad T651 doesn't work anymore

2023-06-16 Thread Mike Hommey
Package: src:linux
Version: 6.1.27-1
Severity: important

Dear Maintainer,

After upgrading to bookworm, my bluetooth trackpad stopped working. It's
properly connected, and `libinput list-devices` displays this message:

event15 - Logitech Rechargeable Trackpad T651: kernel bug: device has min == 
max on ABS_MT_POSITION_X

It worked with earlier kernel versions. I went back to one I had at hand
from before the upgrade (6.1.0-0.deb11.5-amd64), and it worked again,
with `libinput list-devices` reporting:

Device:   Logitech Rechargeable Trackpad T651
Kernel:   /dev/input/event15
Group:7
Seat: seat0, default
Size: 123x103mm
Capabilities: pointer gesture
Tap-to-click: disabled
Tap-and-drag: enabled
Tap drag lock:disabled
Left-handed:  disabled
Nat.scrolling:disabled
Middle emulation: disabled
Calibration:  n/a
Scroll methods:   *two-finger edge
Click methods:*button-areas clickfinger
Disable-w-typing: n/a
Disable-w-trackpointing: n/a
Accel profiles:   flat *adaptive
Rotation: n/a


-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: Gigabyte Technology Co., Ltd.
product_name: TRX40 AORUS PRO WIFI
product_version: -CF
chassis_vendor: Default string
chassis_version: Default string
bios_vendor: American Megatrends International, LLC.
bios_version: F6
board_vendor: Gigabyte Technology Co., Ltd.
board_name: TRX40 AORUS PRO WIFI
board_version: Default string

** PCI devices:
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse 
Root Complex [1022:1480]
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root 
Complex [1022:1480]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 

00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse 
PCIe Dummy Host Bridge [1022:1482]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:01.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse 
GPP Bridge [1022:1483] (prog-if 00 [Normal decode])
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP 
Bridge [1022:1453]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse 
PCIe Dummy Host Bridge [1022:1482]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse 
PCIe Dummy Host Bridge [1022:1482]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller 
[1022:790b] (rev 61)
Subsystem: Gigabyte Technology Co., Ltd FCH SMBus Controller [1458:5001]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- 
Kernel driver in use: nvme
Kernel modules: nvme

02:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe 
SSD Controller SM981/PM981/PM983 [144d:a808] (prog-if 02 [NVM Express])
Subsystem: Samsung Electronics Co Ltd SSD 970 EVO [144d:a801]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel 

Bug#1037308: php8.2-fpm: Fails to start when /run/php doesn't exist.

2023-06-11 Thread Mike Hommey
On Sun, Jun 11, 2023 at 08:27:57AM +0200, Ondřej Surý wrote:
> Control: severity -1 minor
> Control: tags -1 +wontfix
> 
> The package needs systemd-tmpfiles script to work. It has been explicitly 
> requested to not enforce the dependency on systemd because of “containers”, 
> so I’ve removed it.
> 
> So, I am not going to fix this.

apt install systemd-tmpfiles says:
Package systemd-tmpfiles is a virtual package provided by:
  systemd-standalone-tmpfiles 252.6-1 (= 252.6-1)
  systemd 252.6-1 (= 252.6-1)

and systemd is installed...

Mike



Bug#1037308: php8.2-fpm: Fails to start when /run/php doesn't exist.

2023-06-10 Thread Mike Hommey
Package: php8.2-fpm
Version: 8.2.5-2
Severity: important

Dear Maintainer,

(In case this is relevant, this is happening in a LHC container, but I
don't think this is related.)

php8.2-fpm fails to start with:

ERROR: unable to bind listening socket for address '/run/php/php8.2-fpm.sock': 
No such file or directory (2)
ERROR: FPM initialization failed

/run/php doesn't exist. Creating it fixes the issue. (/run is a tmpfs in
the container, just like it is on a normal Debian install)


-- System Information:
Debian Release: 12.0



Bug#1036531: unblock: firefox-esr/102.11.0esr-1

2023-05-21 Thread Mike Hommey
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package firefox-esr

[ Reason ]
Security update for Firefox. The same package has already reached
bullseye.

[ Impact ]
See above

[ Tests ]
Usual smoke tests

[ Risks ]
See above.

[ Other info ]
There are no changes to the package debian/ directory other than
debian/changelog. Everything else is upstream changes for the security
update.

unblock firefox-esr/102.11.0esr-1



Bug#1035947: fresh build from git fails with cannot access local variable 'new_file'

2023-05-11 Thread Mike Hommey
severity 1035947 normal
thanks

This would be serious if it failed to build with the sources in the
Debian archive, which is what counts.

Note that using uscan doesn't get you all the sources.

On Thu, May 11, 2023 at 10:32:40AM -0400, Antoine Beaupre wrote:
> Source: firefox
> Severity: serious
> Tags: patch ftbfs
> Justification: fails to build from source (but built successfully in the past)
> 
> I'm trying to build Firefox 113 from the git repository. I have pulled
> the package with:
> 
> debcheckout firefox
> 
> Then tried to download the latest tarballs with:
> 
> uscan --download-current

> 
> This crashes with a Python exception:
> 
> anarcat@angela:firefox$ uscan --download-current
> Newest version of firefox on remote site is 113.0, specified download version 
> is 113.0
> uscan warn: Possible OpenPGP signature found at:
>
> https://archive.mozilla.org/pub/firefox/releases/113.0/source/firefox-113.0.source.tar.xz.asc
>  * Add opts=pgpsigurlmangle=s/$/.asc/ or opts=pgpmode=auto to debian/watch
>  * Add debian/upstream/signing-key.asc.
>  See uscan(1) for more details
> Successfully symlinked ../firefox-113.0.source.tar.xz to 
> ../firefox_113.0.orig.tar.xz.
> Traceback (most recent call last):
>   File "/home/anarcat/dist/firefox/debian/repack.py", line 217, in 
> main()
>   File "/home/anarcat/dist/firefox/debian/repack.py", line 205, in main
> if not new_file:
>
> UnboundLocalError: cannot access local variable 'new_file' where it is not 
> associated with a value
> uscan: error: python3 debian/repack.py --upstream-version 113.0 
> ../firefox_113.0.orig.tar.xz subprocess returned exit status 1
> anarcat@angela:firefox[1]$ 
> 
> I believe the following patch fixes the issue somehow:
> 
> diff --git i/debian/repack.py w/debian/repack.py
> index 00d20928f6e..4f04ea200fb 100755
> --- i/debian/repack.py
> +++ w/debian/repack.py
> @@ -199,6 +199,8 @@ def main():
>  
>  if options.new_file:
>  new_file = options.new_file
> +else:
> +new_file = None
>  
>  if os.path.islink(args[0]):
>  orig = os.path.realpath(args[0])
> 
> a.
> 
> -- Package-specific info:
> 
> 
> -- Addons package information
> 
> -- System Information:
> Debian Release: 12.0
>   APT prefers testing-security
>   APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500, 
> 'stable-security'), (500, 'testing'), (500, 'stable'), (1, 'experimental'), 
> (1, 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.1.0-8-amd64 (SMP w/16 CPU threads; PREEMPT)
> Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.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
> 
> -- no debconf information
> 



Bug#1034000: snapshot.debian.org: Unusual number of 503s on snapshot.d.o

2023-04-06 Thread Mike Hommey
Package: snapshot.debian.org
Severity: normal

We've seen an unusual number of 503s (and maybe other errors, because
debootstrap is not super verbose about what's happening) coming up from
snapshot.debian.org.

Examples of urls that recently failed (but later worked):

503s:
http://snapshot.debian.org/archive/debian-debug/20221204T212138Z/dists/bullseye-proposed-updates-debug/InRelease
http://snapshot.debian.org/archive/debian/20221204T212138Z/pool/main/d/debootstrap/debootstrap_1.0.123%2bdeb11u1_all.deb

Unknown error codes:
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/a/acl/acl_2.2.52-2_amd64.deb
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/a/alsa-lib/libasound2_1.0.28-1_i386.deb
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/a/at-spi2-atk/libatk-bridge2.0-0_2.14.0-2_i386.deb
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/a/at-spi2-core/libatspi2.0-0_2.14.0-1_i386.deb
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/e/e2fsprogs/e2fsprogs_1.42.12-2+b1_i386.deb
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/g/gtk+3.0/libgtk-3-0_3.14.5-1+deb8u1_amd64.deb
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/h/harfbuzz/libharfbuzz0b_0.9.35-2_amd64.deb
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/k/krb5/libk5crypto3_1.12.1+dfsg-19+deb8u4_amd64.deb
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/libs/libsepol/libsepol1_2.3-2_amd64.deb
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/n/nettle/libhogweed2_2.7.1-5+deb8u2_i386.deb
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/p/po-debconf/po-debconf_1.0.16+nmu3_all.deb
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/p/procps/libprocps3_3.3.9-9+deb8u1_amd64.deb
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/p/procps/procps_3.3.9-9+deb8u1_amd64.deb
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/s/systemd/systemd_215-17+deb8u7_amd64.deb
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/t/tzdata/tzdata_2018e-0+deb8u1_all.deb

Mike



Bug#1033151: unblock: firefox-esr/102.9.0esr-2

2023-03-18 Thread Mike Hommey
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package firefox-esr

(Please provide enough (but not too much) information to help
the release team to judge the request efficiently. E.g. by
filling in the sections below.)

[ Reason ]
New version fixes CVEs and the RC bug that was putting the package in
the autorm list.

[ Impact ]
No firefox in bookwork.

[ Tests ]
Package was smoke-tested.

[ Risks ]
Apart from the upstream differences from the CVE fixes/new upstream
release, that we'd take (and have taken) in stable, the differences are
very limited in scope (see attached diff)

[ 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 testing

unblock firefox-esr/102.9.0esr-2
diff -Nru firefox-esr-102.8.0esr/debian/browser.mozconfig.in 
firefox-esr-102.9.0esr/debian/browser.mozconfig.in
--- firefox-esr-102.8.0esr/debian/browser.mozconfig.in  2023-02-15 
08:44:35.0 +0900
+++ firefox-esr-102.9.0esr/debian/browser.mozconfig.in  2023-03-18 
06:53:04.0 +0900
@@ -30,6 +30,6 @@
 ac_add_options --with-unsigned-addon-scopes=app,system
 ac_add_options --allow-addon-sideload
 ac_add_options --enable-alsa
-%if DIST == bullseye || DIST == buster || DIST == stretch
+%if DIST == bullseye || DIST == buster || DIST == stretch || DEB_HOST_ARCH == 
s390x
 ac_add_options --without-wasm-sandboxed-libraries
 %endif
diff -Nru firefox-esr-102.8.0esr/debian/changelog 
firefox-esr-102.9.0esr/debian/changelog
--- firefox-esr-102.8.0esr/debian/changelog 2023-02-15 08:45:08.0 
+0900
+++ firefox-esr-102.9.0esr/debian/changelog 2023-03-18 06:53:38.0 
+0900
@@ -1,3 +1,22 @@
+firefox-esr (102.9.0esr-2) unstable; urgency=medium
+
+  * gfx/skia/generate_mozbuild.py, gfx/skia/moz.build: Remove explicit NEON
+flags from skia build. Closes: #982794. Thanks Emanuele Rocca.
+
+ -- Mike Hommey   Sat, 18 Mar 2023 06:53:38 +0900
+
+firefox-esr (102.9.0esr-1) unstable; urgency=medium
+
+  * New upstream release.
+  * Fixes for mfsa2023-10, also known as:
+CVE-2023-25751, CVE-2023-28164, CVE-2023-28162, CVE-2023-25752,
+CVE-2023-28176.
+
+  * debian/browser.mozconfig.in: Disable wasm sandboxing on s390x for now.
+It doesn't work at the moment.
+
+ -- Mike Hommey   Wed, 15 Mar 2023 07:26:00 +0900
+
 firefox-esr (102.8.0esr-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru 
firefox-esr-102.8.0esr/debian/patches/debian-hacks/Add-a-2-minutes-timeout-on-xpcshell-tests.patch
 
firefox-esr-102.9.0esr/debian/patches/debian-hacks/Add-a-2-minutes-timeout-on-xpcshell-tests.patch
--- 
firefox-esr-102.8.0esr/debian/patches/debian-hacks/Add-a-2-minutes-timeout-on-xpcshell-tests.patch
  2023-02-15 08:44:54.0 +0900
+++ 
firefox-esr-102.9.0esr/debian/patches/debian-hacks/Add-a-2-minutes-timeout-on-xpcshell-tests.patch
  2023-03-18 06:53:24.0 +0900
@@ -7,7 +7,7 @@
  1 file changed, 18 insertions(+), 3 deletions(-)
 
 diff --git a/testing/xpcshell/runxpcshelltests.py 
b/testing/xpcshell/runxpcshelltests.py
-index 212bfeb..6761334 100755
+index c3de2a2..0636219 100755
 --- a/testing/xpcshell/runxpcshelltests.py
 +++ b/testing/xpcshell/runxpcshelltests.py
 @@ -13,6 +13,7 @@ import os
@@ -18,7 +18,7 @@
  import shutil
  import signal
  import subprocess
-@@ -835,9 +836,23 @@ class XPCShellTestThread(Thread):
+@@ -837,9 +838,23 @@ class XPCShellTestThread(Thread):
  if self.interactive:
  self.log.info("%s | Process ID: %d" % (name, self.proc_ident))
  
diff -Nru 
firefox-esr-102.8.0esr/debian/patches/porting/Bug-1822827-Remove-explicit-NEON-flags-from-skia-bui.patch
 
firefox-esr-102.9.0esr/debian/patches/porting/Bug-1822827-Remove-explicit-NEON-flags-from-skia-bui.patch
--- 
firefox-esr-102.8.0esr/debian/patches/porting/Bug-1822827-Remove-explicit-NEON-flags-from-skia-bui.patch
1970-01-01 09:00:00.0 +0900
+++ 
firefox-esr-102.9.0esr/debian/patches/porting/Bug-1822827-Remove-explicit-NEON-flags-from-skia-bui.patch
2023-03-18 06:53:24.0 +0900
@@ -0,0 +1,44 @@
+From: Emanuele Rocca 
+Date: Sat, 18 Mar 2023 06:48:32 +0900
+Subject: Bug 1822827 - Remove explicit NEON flags from skia build
+
+While Firefox builds for Android ARMv7 don't support non-NEON
+processors, downstreams (including non-Android ones) may still want to
+support them.
+
+Because those Firefox builds don't support non-NEON processors, the NEON
+flags are actually already passed globally, and they don't need to be
+explicitly added. NEON_FLAGS is actually only meant to be used for
+sources that specifically need NEON support even when the target doesn't
+support it, for, e.g. specialized code behind runtime CPU detection.
+---
+ gfx/skia/generate_mozbuild.py | 2 --
+ gfx/skia/moz.build| 2 --
+ 2 files changed, 4 deletions(-)
+
+diff --git a/gfx/skia/generate_mozbuild.py 

Bug#1032983: firefox-esr: TLS websites broken with libnss3 2:3.87.1-1 from Debian testing/bookworm

2023-03-17 Thread Mike Hommey
reassign 1032983 libnss3-dev
fixed 1032983 2:3.89-2
done

On Fri, Mar 17, 2023 at 09:25:21AM +0200, jim_p wrote:
> Package: firefox-esr
> Followup-For: Bug #1032983
> X-Debbugs-Cc: pitsior...@outlook.com
> 
> The same thing applies to thunderbird 102.9.0 that reached the repo yesterday.
> Broken tls support there means no email can be sent or received and rss feeds
> do not work.
> I also have an ms exchange calendar in tb, which I was too upset to check if 
> it
> works, but it probably won't.
> 
> So, can you please add libnss3>=2:3.89 as a version dependency for those
> packages?

The problem was in libnss3-dev and was fixed there. Thunderbird has
received a binNMU to rebuild against it, and Firefox-esr got a new
upload that also ended up building against it.

Mike



Bug#1033101: nmu: thunderbird_1:102.9.0-1

2023-03-17 Thread Mike Hommey
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

libnss3-dev 2:3.89-1 introduced an incompatibility that made builds
against it fail to work with older versions of libnss3. 2:3.89-2 fixed
that. Firefox-esr is also affected, but I'm going to upload a new
version soon anyways.

nmu thunderbird_1:102.9.0-1 . ANY . unstable . -m "Rebuild against libnss3-dev 
2:3.89-2"



Bug#1028504: libc6: valgrind reports "Invalid read of size 8" deep in decompose_rpath in dl-load.c

2023-01-11 Thread Mike Hommey
Package: libc6
Version: 2.36-8
Severity: important

STR:
- apt install firefox valgrind
- valgrind --show-mismatched-frees=no firefox

valgrind will quickly show errors like:
==6383== Invalid read of size 8
==6383==at 0x4023A34: strncmp (strcmp-sse2.S:162)
==6383==by 0x4004C8E: is_dst (dl-load.c:216)
==6383==by 0x4005A5E: _dl_dst_count (dl-load.c:253)
==6383==by 0x4005C37: expand_dynamic_string_token (dl-load.c:395)
==6383==by 0x4005DA2: fillin_rpath.isra.0 (dl-load.c:483)
==6383==by 0x4006092: decompose_rpath (dl-load.c:654)
==6383==by 0x400824B: _dl_map_object (dl-load.c:2111)
==6383==by 0x4002280: openaux (dl-deps.c:64)
==6383==by 0x4BE0E99: _dl_catch_exception (dl-error-skeleton.c:208)
==6383==by 0x40025E9: _dl_map_object_deps (dl-deps.c:232)
==6383==by 0x400BB5C: dl_open_worker_begin (dl-open.c:592)
==6383==by 0x4BE0E99: _dl_catch_exception (dl-error-skeleton.c:208)
==6383==  Address 0x4ebec59 is 9 bytes inside a block of size 15 alloc'd
==6383==at 0x48407B4: malloc (vg_replace_malloc.c:381)
==6383==by 0x402381A: malloc (rtld-malloc.h:56)
==6383==by 0x402381A: strdup (strdup.c:42)
==6383==by 0x4006024: decompose_rpath (dl-load.c:629)
==6383==by 0x400824B: _dl_map_object (dl-load.c:2111)
==6383==by 0x4002280: openaux (dl-deps.c:64)
==6383==by 0x4BE0E99: _dl_catch_exception (dl-error-skeleton.c:208)
==6383==by 0x40025E9: _dl_map_object_deps (dl-deps.c:232)
==6383==by 0x400BB5C: dl_open_worker_begin (dl-open.c:592)
==6383==by 0x4BE0E99: _dl_catch_exception (dl-error-skeleton.c:208)
==6383==by 0x400B2B5: dl_open_worker (dl-open.c:782)
==6383==by 0x4BE0E99: _dl_catch_exception (dl-error-skeleton.c:208)
==6383==by 0x400B6A7: _dl_open (dl-open.c:884)

Mike



Bug#1025046: zfs-dkms: doesn't build with latest linux kernel backport

2022-11-29 Thread Mike Hommey
Package: zfs-dkms
Version: 2.1.5-1~bpo11+1
Severity: wishlist

Dear Maintainer,

The latest linux kernel in bullseye-backports is now 6.0.something, and
zfs-dkms postinst fails with:
```
*** None of the expected "shrinker" interfaces were detected.
*** This may be because your kernel version is newer than what is
*** supported, or you are using a patched custom kernel with
*** incompatible modifications.
***
*** ZFS Version: zfs-2.1.5-1~bpo11+1
*** Compatible Kernels: 3.10 - 5.18
```


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

Kernel: Linux 5.5.0-2-amd64 (SMP w/64 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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 zfs-dkms depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  dkms   2.8.4-3
ii  file   1:5.39-3
ii  libc6-dev [libc-dev]   2.31-13+deb11u5
ii  libpython3-stdlib  3.9.2-3
ii  lsb-release11.1.0
ii  perl   5.32.1-4+deb11u2
ii  python3-distutils  3.9.2-1

Versions of packages zfs-dkms recommends:
ii  linux-libc-dev  5.10.149-2
pn  zfs-zed 
ii  zfsutils-linux  2.1.5-1~bpo11+1

Versions of packages zfs-dkms suggests:
ii  debhelper  13.3.4

-- debconf information excluded



Bug#1024979: please consider enabling gpsd support

2022-11-28 Thread Mike Hommey
On Mon, Nov 28, 2022 at 10:08:30PM +, John Scott wrote:
> On Tue, 2022-11-29 at 06:44 +0900, Mike Hommey wrote:
> > Support compiled in would make libgpsd a hard requirement, which some
> > other people would probably complain about. But anyways, the main
> > problem is that, as far as I know, it doesn't actually work.
> Your reasoning is sound. Thanks for your consideration. I have a
> proposition for you. Let's suppose I can get it to work on my local
> system (I haven't tried yet; as I'm sure you know, rebuilding Firefox
> takes a long time). In that case, would you be willing to entertain a
> merge request which adds an opt-in build profile to enable gpsd support?
> 
> This would make it a little easier for Debianites to experiment with it,
> and then we can revisit whether to enable it by default later down the
> road.

So, I poked upstream, and it turns out Firefox has geoclue support since
version 102 (https://bugzilla.mozilla.org/show_bug.cgi?id=1769664), and
geoclue supports GPS sources...

Mike



Bug#1024979: please consider enabling gpsd support

2022-11-28 Thread Mike Hommey
tag 1024979 + wontfix
thanks

On Mon, Nov 28, 2022 at 04:45:58AM +, John Scott wrote:
> Package: firefox-esr
> Version: 102.4.0esr-1
> Severity: normal
> 
> Hi,
> 
> Firefox has opt-in support for gpsd to determine user location. However, the 
> Debian package doesn't compile in support for it. It should be as easy as 
> configuring with --enable-gpsd and adding the Build-Depends. Even when 
> support is compiled in, this feature is opt-in for the user.

Support compiled in would make libgpsd a hard requirement, which some
other people would probably complain about. But anyways, the main
problem is that, as far as I know, it doesn't actually work.
https://bugzilla.mozilla.org/show_bug.cgi?id=1763347

Mike



Bug#1024727: firefox-esr: does not support IPv6

2022-11-23 Thread Mike Hommey
forwarded 1024727 https://bugzilla.mozilla.org/show_bug.cgi?id=700999
title 1024727 Firefox does not support ipv6 link-local addresses with 
severity 1024727 normal
thanks

On Thu, Nov 24, 2022 at 01:08:19AM +, Thorsten Glaser wrote:
> Mike Hommey dixit:
> 
> >> >Try removing that %eth0 from the ipv6 address.
> >> 
> >> That would invalidate said address and is therefore impossible.
> >
> >Why would it? Is your setup so complex that the network stack can't find
> >the right interface to send packets through?
> 
> It’s a link-local address. These do by definition need the interface
> specified because they aren’t global.

and yet e.g. ping6 is happy with just the IP without the zone-id.

> Please do read up on IPv6 basics when commenting on IPv6 specifics…

Here's some reading for yourself:
- https://bugzilla.mozilla.org/show_bug.cgi?id=700999#c17
- https://www.w3.org/Bugs/Public/show_bug.cgi?id=27234#c2

Neither Chromium nor Firefox currently implement RFC6874.

Mike



Bug#1024727: firefox-esr: does not support IPv6

2022-11-23 Thread Mike Hommey
On Thu, Nov 24, 2022 at 12:00:07AM +, Thorsten Glaser wrote:
> Mike Hommey dixit:
> 
> >Try removing that %eth0 from the ipv6 address.
> 
> That would invalidate said address and is therefore impossible.

Why would it? Is your setup so complex that the network stack can't find
the right interface to send packets through?

Mike



Bug#1024727: firefox-esr: does not support IPv6

2022-11-23 Thread Mike Hommey
On Thu, Nov 24, 2022 at 12:06:06AM +0100, Thorsten Glaser wrote:
> Package: firefox-esr
> Version: 102.5.0esr-1~deb11u1
> Severity: serious
> Justification: violates a Debian Etch release goal
> X-Debbugs-Cc: t...@mirbsd.de
> 
> see attached screenshot

Try removing that %eth0 from the ipv6 address.



Bug#874207: geckodriver: please enable

2022-11-21 Thread Mike Hommey
tag 874207 + wontfix
tag 989455 + wontfix
thanks

On Mon, Sep 04, 2017 at 11:02:06AM +0200, Matthias Urlichs wrote:
> Package: firefox
> Version: 54.0-2
> Severity: normal
> 
> Firefox does not work with python{,3}-selenium because you don't build the
> "geckodriver" executable.
> 
> The end of testing/geckodriver/README.md states:
> 
> geckodriver is built in the Firefox CI by default but not if you build
> Firefox locally. To enable building of geckodriver locally, ensure you
> put this in your mozconfig:
> 
> ac_add_options --enable-geckodriver
> 
> The geckodriver binary will appear in ${objdir}/dist/bin/geckodriver 
> alongside firefox-bin.
> 
> Please enable and install it so that Firefox may be used with Selenium.

It would be better to package it standalone. Nowadays, it is available
on crates.io.

Mike



Bug#1021810: Should firefox-esr be dropped on 32bit architectures in bookworm?

2022-10-15 Thread Mike Hommey
On Sat, Oct 15, 2022 at 09:27:33AM +0300, Adrian Bunk wrote:
> Package: firefox-esr
> Version: 102.3.0esr-1
> Severity: serious
> Tags: bookworm sid
> X-Debbugs-Cc: Carsten Schoenert , 
> debian-rele...@lists.debian.org, t...@security.debian.org, 
> debian-...@lists.debian.org
> 
> [ various potentially interested parties are Cc'ed ]
> 
> 4 GB address space for one process is an absolute limit on 32bit
> architectures, including for native building as is done in Debian.[1]
> 
> mipsel has 2 GB address space (all Debian buildds have 64bit kernels),
> the 2020 Firefox ESR (78) was the last Firefox ESR to build there.
> 
> On i386 and 32bit arm:
> 4 GB address space are available with a 64bit kernel.
> 3 GB address space are typically available with a 32bit kernel.
> 
> All i386 buildds are using a 64bit kernel,
> but armhf buildds are currently mixed.
> 
> This uncovered that the 2022 ESR of Firefox (102) already needs
> more than 3 GB address space on armhf.[2]
>
> There is a new ESR major release of Firefox every summer,
> which is being used also in *stable releases of Debian since the
> previous ESR branch loses upstream security support soon afterwards.
> 
> It is possible to confine building firefox{,-esr} to only the 64bit
> buildds on the buildd side to address the current issue,[3] but during
> the non-LTS lifetime of bookworm firefox-esr will be upgraded three
> times to newer ESR major releses.
>
> One can hope the 2023 ESR might still be buildable with 4 GB address space,
> which would cover the non-LTS support time of bullseye.
> 
> I would be less optimistic that the 2025 ESR will still be buildable
> with 4 GB address space, which implies that it might not be possbile
> to provide security support for firefox-esr on i386 and 32bit arm
> during the whole non-LTS support time of bookworm.

FWIW, ironically, it's not the new version of Firefox that has these
needs in memory, it's the new version of rustc (the memory usage
regression is there) and/or llvm.

As a matter of fact, firefox-esr 91 started to fail to build on 32bits
architectures on unstable when some new version of rustc went into
unstable.

Mike



Bug#1021689: firefox-esr: regression: Ctrl-Shift-T does not work any more, menu option greyed out

2022-10-12 Thread Mike Hommey
On Thu, Oct 13, 2022 at 01:28:33AM +0200, Thorsten Glaser wrote:
> Package: firefox-esr
> Version: 102.3.0esr-1~deb11u1
> Severity: normal
> X-Debbugs-Cc: t...@mirbsd.de, t...@security.debian.org
> 
> Since the upgrade to 102 in bullseye, Ctrl-Shift-T does not work any more.
> Upon looking in the menu, “Recently Closed Tabs” is greyed out instead of
> listing these as before.

It works for me.

Can you try with a fresh profile? Disabling addons? Diagnostic mode in
about:support?

Mike



Bug#1020394: rustc: Please upload 1.61.0 to unstable

2022-09-20 Thread Mike Hommey
Package: rustc
Severity: wishlist

Firefox 105 requires rustc 1.61.0. Please update the version in
unstable.

Mike



Bug#1017426: libnss3: Uninitialised value was created by a stack allocation

2022-08-16 Thread Mike Hommey
On Tue, Aug 16, 2022 at 09:59:30AM +0300, Alexey Kuznetsov wrote:
> On Tue, Aug 16, 2022 at 9:50 AM Mike Hommey  wrote:
> 
> > On Tue, Aug 16, 2022 at 09:06:20AM +0300, Alexey Kuznetsov wrote:
> > > On Tue, Aug 16, 2022 at 9:00 AM Mike Hommey  wrote:
> > >
> > > > On Tue, Aug 16, 2022 at 08:30:07AM +0300, a...@me.com wrote:
> > > > > Package: libnss3
> > > > > Version: 2:3.79-1
> > > > > Severity: normal
> > > > >
> > > > > Dear Maintainer,
> > > > >
> > > > > debuging valgrind pidgin with result:
> > > > >
> > > > > ==804198==  Uninitialised value was created by a stack allocation
> > > > > ==804198==at 0xB089DC0: ssl3_MACEncryptRecord (ssl3con.c:2104)
> > > > >
> > > > > line correspopnds to the ssl3_MACEncryptRecord
> > > >
> > > > Looking at the code, it would seem to be a false positive, but I might
> > > > have overlooked something, but you haven't pasted the most interesting
> > > > parts of the valgrind output...
> > > >
> > > > Mike
> > > >
> > >
> > > This output comes exactly from valgrind. No usual stack trace. Before and
> > > below are different issues.
> > >
> > > BTW pidgin crashing sometimes, and only issues I can record points to the
> > > nss library.
> >
> > Usually, "Uninitialised value was created by a stack allocation" is the
> > reason for the error, with a stack trace, that comes above it. That's
> > the most crucial information. Without that, we don't know what is trying
> > to use that unitialized value.
> >
> 
>  Ok .Let me restart pidgin. It 100% reproducible. Only thing you need is to
> install dbgsym for glibc, nss3, pidgin and add frew irc and jabber accounts
> (I also using matrix plugin). Command would be:
> 
> G_SLICE=always-malloc valgrind --num-callers=30 --track-origins=yes pidgin
> 2>&1 | tee 123.log
> 
> https://paste.debian.net/1250580/

Can you reproduce with 3.81-1 in unstable?

For posterity, the useful information:

==837133== Syscall param socketcall.sendto(msg) points to uninitialised byte(s)
==837133==at 0x5A153D6: __libc_send (send.c:28)
==837133==by 0x5A153D6: send (send.c:23)
==837133==by 0xB083527: pt_Send (ptio.c:2002)
==837133==by 0xB01DFF7: ssl_DefSend (ssldef.c:105)
==837133==by 0xB0229C0: ssl_SendSavedWriteData (sslsecur.c:452)
==837133==by 0xB006839: ssl3_SendRecord (ssl3con.c:2568)
==837133==by 0xB006C2C: ssl3_FlushHandshakeMessages (ssl3con.c:2774)
==837133==by 0xB006C2C: ssl3_FlushHandshake (ssl3con.c:2747)
==837133==by 0xB00F5E4: ssl3_SendFinished (ssl3con.c:11944)
==837133==by 0xB00FB79: ssl3_SendClientSecondRound (ssl3con.c:8191)
==837133==by 0xB011A7A: ssl3_HandleServerHelloDone (ssl3con.c:8061)
==837133==by 0xB011A7A: ssl3_HandlePostHelloHandshakeMessage 
(ssl3con.c:12568)
==837133==by 0xB011A7A: ssl3_HandleHandshakeMessage (ssl3con.c:12479)
==837133==by 0xB014A74: ssl3_HandleHandshake (ssl3con.c:12653)
==837133==by 0xB014A74: ssl3_HandleNonApplicationData (ssl3con.c:13188)
==837133==by 0xB0153C0: ssl3_HandleRecord (ssl3con.c:13529)
==837133==by 0xB01B500: ssl3_GatherCompleteHandshake (ssl3gthr.c:561)
==837133==by 0xB01B500: ssl3_GatherCompleteHandshake (ssl3gthr.c:449)
==837133==by 0xB022A80: SSL_ForceHandshake (sslsecur.c:382)
==837133==by 0xADCC8D6: ssl_nss_handshake_cb (ssl-nss.c:371)
==837133==by 0x1824B1: pidgin_io_invoke (gtkeventloop.c:73)
==837133==by 0x54BBA9E: g_main_dispatch (gmain.c:3417)
==837133==by 0x54BBA9E: g_main_context_dispatch (gmain.c:4135)
==837133==by 0x54BBE57: g_main_context_iterate.constprop.0 (gmain.c:4211)
==837133==by 0x54BC10E: g_main_loop_run (gmain.c:4411)
==837133==by 0x4C57B29: gtk_main (in 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.33)
==837133==by 0x145D7B: main (gtkmain.c:948)
==837133==  Address 0x1b82e246 is 534 bytes inside a block of size 1,553 alloc'd
==837133==at 0x484582F: realloc (vg_replace_malloc.c:1437)
==837133==by 0xB2114A1: PORT_Realloc_Util (secport.c:101)
==837133==by 0xB01E1E4: sslBuffer_Grow (sslencode.c:50)
==837133==by 0xB01E1E4: sslBuffer_Grow (sslencode.c:31)
==837133==by 0xB01E42B: sslBuffer_Append (sslencode.c:82)
==837133==by 0xB006817: ssl3_SendRecord (ssl3con.c:2559)
==837133==by 0xB006C2C: ssl3_FlushHandshakeMessages (ssl3con.c:2774)
==837133==by 0xB006C2C: ssl3_FlushHandshake (ssl3con.c:2747)
==837133==by 0xB00F5E4: ssl3_SendFinished (ssl3con.c:11944)
==837133==by 0xB00FB79: ssl3_SendClientSecondRound (ssl3con.c:8191)
==837133==by 0xB011A7A: ssl3_HandleServerHelloDone (ssl3con.c

Bug#1017426: libnss3: Uninitialised value was created by a stack allocation

2022-08-16 Thread Mike Hommey
On Tue, Aug 16, 2022 at 09:06:20AM +0300, Alexey Kuznetsov wrote:
> On Tue, Aug 16, 2022 at 9:00 AM Mike Hommey  wrote:
> 
> > On Tue, Aug 16, 2022 at 08:30:07AM +0300, a...@me.com wrote:
> > > Package: libnss3
> > > Version: 2:3.79-1
> > > Severity: normal
> > >
> > > Dear Maintainer,
> > >
> > > debuging valgrind pidgin with result:
> > >
> > > ==804198==  Uninitialised value was created by a stack allocation
> > > ==804198==at 0xB089DC0: ssl3_MACEncryptRecord (ssl3con.c:2104)
> > >
> > > line correspopnds to the ssl3_MACEncryptRecord
> >
> > Looking at the code, it would seem to be a false positive, but I might
> > have overlooked something, but you haven't pasted the most interesting
> > parts of the valgrind output...
> >
> > Mike
> >
> 
> This output comes exactly from valgrind. No usual stack trace. Before and
> below are different issues.
> 
> BTW pidgin crashing sometimes, and only issues I can record points to the
> nss library.

Usually, "Uninitialised value was created by a stack allocation" is the
reason for the error, with a stack trace, that comes above it. That's
the most crucial information. Without that, we don't know what is trying
to use that unitialized value.



Bug#1017426: libnss3: Uninitialised value was created by a stack allocation

2022-08-16 Thread Mike Hommey
On Tue, Aug 16, 2022 at 08:30:07AM +0300, a...@me.com wrote:
> Package: libnss3
> Version: 2:3.79-1
> Severity: normal
> 
> Dear Maintainer,
> 
> debuging valgrind pidgin with result:
> 
> ==804198==  Uninitialised value was created by a stack allocation
> ==804198==at 0xB089DC0: ssl3_MACEncryptRecord (ssl3con.c:2104)
> 
> line correspopnds to the ssl3_MACEncryptRecord

Looking at the code, it would seem to be a false positive, but I might
have overlooked something, but you haven't pasted the most interesting
parts of the valgrind output...

Mike



Bug#1015774: dh-python: dh_python --buildsystem=pybuild doesn't work with multiple versions in DEBPYTHON3_SUPPORTED

2022-08-14 Thread Mike Hommey
On Sun, Aug 14, 2022 at 02:13:06PM +0200, Stefano Rivera wrote:
> Hi Mike (2022.07.21_02:33:17_+0200)
> > The code that handles DEB_PYTHON3_SUPPORTED wants multiple versions to
> > be separated with commas:
> >   
> > https://sources.debian.org/src/dh-python/5.20220403/dhpython/_defaults.py/#L61
> 
> And that's what's documented for pybuild.
> 
> > When using dh_python --buildsystem=pybuild, pybuild is called with the
> > -p argument with the value of DEB_PYTHON3_SUPPORTED as is:
> >   https://sources.debian.org/src/dh-python/5.20220403/dh/pybuild.pm/#L214
> >   where py3vers comes from
> >   https://sources.debian.org/src/dh-python/5.20220403/dh/pybuild.pm/#L47
> 
> I think this is the bug, those should be transformed to spaces.
> 
> > pybuild does handle `-p "3.6 3.7"` as meaning both versions, but then
> > dh_python considers it as major version 3, minor version "6 3", and
> > throws an exception.
> 
> Can you expand on that? Why is dh_python even involved?

To get to the point of having pybuild invoked with "3.6 3.7" without
touching its code, you set DEB_PYTHON3_SUPPORTED to "3.6 3.7", which
dh_python interprets the way I mentioned.

Mike



Bug#1015774: dh-python: dh_python --buildsystem=pybuild doesn't work with multiple versions in DEBPYTHON3_SUPPORTED

2022-07-20 Thread Mike Hommey
Package: dh-python
Version: 5.20220403
Severity: normal

Dear Maintainer,

We've originally hit this bug in the version of dh-python in Ubuntu
18.06, but looking at the code currently in unstable, this still
applies.

The code that handles DEB_PYTHON3_SUPPORTED wants multiple versions to
be separated with commas:
  https://sources.debian.org/src/dh-python/5.20220403/dhpython/_defaults.py/#L61

When using dh_python --buildsystem=pybuild, pybuild is called with the
-p argument with the value of DEB_PYTHON3_SUPPORTED as is:
  https://sources.debian.org/src/dh-python/5.20220403/dh/pybuild.pm/#L214
  where py3vers comes from
  https://sources.debian.org/src/dh-python/5.20220403/dh/pybuild.pm/#L47

So, when you use DEB_PYTHON3_SUPPORTED=3.6,3.7 to build with support for
both 3.6 and 3.7, pybuild is called with `-p 3.6,3.7`... which it doesn't
handle as meaning you want both versions:
  here `3.6,3.7` would be taken as one version:
  https://sources.debian.org/src/dh-python/5.20220403/pybuild/#L566
  which is then handled here:
  https://sources.debian.org/src/dh-python/5.20220403/pybuild/#L174
  which uses this parser:
  https://sources.debian.org/src/dh-python/5.20220403/dhpython/version.py/#L60
  which uses this regexp:
  https://sources.debian.org/src/dh-python/5.20220403/dhpython/version.py/#L29
  which stops at the comma and discard everything else.


pybuild does handle `-p "3.6 3.7"` as meaning both versions, but then
dh_python considers it as major version 3, minor version "6 3", and
throws an exception.


Mike



Bug#1012275: closing 1012275

2022-06-09 Thread Mike Hommey
On Thu, Jun 09, 2022 at 01:59:36PM +0200, Christoph Anton Mitterer wrote:
> Could someone then possibly rebuild this with Julian’s patch, ASAP?
> 
> Over a week with a likely remote code exploit hole in the browser of
> any Debian (non-ESR) FF user, seems not so ideal,

There's a 101.0.1 on the way.



Bug#1012197: rust-cbindgen: Please package version 0.23.0

2022-05-31 Thread Mike Hommey
Source: rust-cbindgen
Severity: wishlist

Dear Maintainer,

Firefox 101 requires cbindgen 0.23.0 to build. Could you update the
package?

Cheers,

Mike



Bug#1008659: firefox-esr: shows 'XML Parsing Error: no root element found' when using Zoom

2022-03-30 Thread Mike Hommey
On Wed, Mar 30, 2022 at 11:26:45AM +0200, Jakub Alba wrote:
> Package: firefox-esr
> Version: 91.7.0esr-1~deb11u1
> Severity: important
> X-Debbugs-Cc: t...@security.debian.org
> 
> Dear Maintainer,
> 
>* What led up to the situation? Last 'apt upgrade'
>* What exactly did you do (or not do) that was effective (or
>  ineffective)? I joined a Zoom call in Firefox private window.
>* What was the outcome of this action? In the top left corner of my screen 
> a
> borderless (and titlebarless) window showed with the text:
> XML Parsing Error: no root element found
> Location: chrome://browser/content/webrtcLegacyIndicator.xhtml
>* What outcome did you expect instead? No window with error.
> 
> This is not a regression specifically in Firefox itself. However, it shows
> up in Firefox. xdotool showed that this error window belonged to a firefox-esr
> process. This problem did not occur prior to last 'apt upgrade'. I've uploaded
> the /var/log/apt/history.log entry for this update here:
> 
> 
> 
> firefox-esr is not among the packages which were updated, so I suspect the
> regression was triggered by a change in libxml2, although I'm not certain.
> 
> Screenshot of the window with error message can be seen here:
> 
> 
> 
> The window is "sticky", in the sense that it shows up on all workspaces and
> covers all windows, including the active one (I'm using KDE Plasma). This
> prevents the user from clicking on things displayed in this area, e.g., in my
> case, entries of the "start menu" after pressing / or tabs in
> Firefox when using the Tree Style Tab extension. Thus I set the severity to
> 'important'.
> 
> The window went away after leaving the Zoom meeting (before closing Firefox).

This sounds like /usr/lib/firefox-esr/browser/omni.ja might be
corrupted. Try quitting firefox, reinstalling, and running it again.

Mike



Bug#1005164: nss: Please buildd with NSS_DISABLE_CRYPTO_VSX=1 on powerpc and ppc64

2022-02-09 Thread Mike Hommey
On Tue, Feb 08, 2022 at 10:23:15AM +0100, John Paul Adrian Glaubitz wrote:
> Source: nss
> Version: 2:3.73.1-1
> Severity: normal
> Tags: patch
> User: debian-powe...@lists.debian.org
> Usertags: powerpc ppc64
> X-Debbugs-Cc: debian-powe...@lists.debian.org
> 
> Hello!
> 
> On powerpc and ppc64, nss is still being built with -mcrypto and -mvsx which
> generates code with Crypto and VSX instructions not supported on powerpc and
> ppc64.
> 
> Normally, the build system should automatically detect the host platform and
> set NSS_DISABLE_CRYPTO_VSX=1 for powerpc and ppc64, but that doesn't seem to
> work at the moment.
> 
> Thus, the following patch will explicitly set NSS_DISABLE_CRYPTO_VSX=1 in
> debian/rules, forcing Crypto and VSX instructions to be disabled on powerpc
> and ppc64.

I thought the code built with -mcrypto -mvsx was behind runtime
detection?

Mike



Bug#1005203: rustc: Please package at least version 1.57

2022-02-08 Thread Mike Hommey
Package: rustc
Version: 1.56.0+dfsg1-2
Severity: important

Dear Maintainer,

Firefox 97 requires rustc 1.57 (released 2 months ago), which is not yet
available in unstable.

Mike



Bug#894081: Libvirt debug symbols not available for latest version

2022-01-07 Thread Mike Hommey
On Thu, Mar 05, 2020 at 04:12:48PM +0100, Andreas Oberritter wrote:
> On Tue, 15 May 2018 11:17:24 +0800 Paul Wise  wrote:
> > Control: retitle -1 security.debian.org: please publish dbgsym packages
> > 
> > On Tue, 27 Mar 2018 14:11:28 +0300 Mathieu Tarral wrote:
> > 
> > > But the reason i couldn't find them is that proposed-upates-debug is not 
> > > listed
> > > on the Wiki:
> > > https://wiki.debian.org/AutomaticDebugPackages#Status
> > 
> > Fixed:
> > 
> > https://wiki.debian.org/AutomaticDebugPackages?action=diff=29=30
> > 
> > I heard that the security archive saves dbgsym packages but does not
> > publish them anywhere. Retitling the bug to reflect that.
> 
> This bug has been idle for almost two years. Is anybody still working on it?
> 
> Just wanted to point out that not every package can be found in 
> proposed-updates-debug.
> There don't seem to be dbgsym packages for php 7.3.14-1~deb10u1, for example, 
> which keeps me from debugging a segfault.

Almost two more years have passed, and I have the same problem with
firefox-esr 91.4.1esr-1~deb11u1.

Mike



Bug#1003206: firefox: opening an unsupported text/* file with Emacs silently fails

2022-01-06 Thread Mike Hommey
On Fri, Jan 07, 2022 at 02:23:44AM +0100, Vincent Lefevre wrote:
> On 2022-01-07 10:18:11 +0900, Mike Hommey wrote:
> > Firefox starts whatever glib tells it is in the desktop file. If the
> > command in the desktop file ends up running urxvt, it's not Firefox's
> > fault. If the desktop file says "Terminal=true" and glib tells Firefox
> > to run urxvt, it's not Firefox's fault.
> 
> OK, so the bug would be in libglib2.0-0 (which uses a hardcoded
> list of terminals as said in the reddit post I've mentioned in
> my other message)?

Apparently yes.



Bug#1003206: firefox: opening an unsupported text/* file with Emacs silently fails

2022-01-06 Thread Mike Hommey
On Fri, Jan 07, 2022 at 02:04:01AM +0100, Vincent Lefevre wrote:
> On 2022-01-07 09:17:22 +0900, Mike Hommey wrote:
> > Rephrasing: the main question is why your config/Emacs's desktop
> > file/Emacs's configuration/whatever wants to use urxvt, because
> > Firefox won't do that on its own.
> 
> There's no mention of rxvt in
> /usr/share/applications/emacs-term.desktop
> 
> Anyway, this is Firefox that starts the application. Unfortunately,
> http://kb.mozillazine.org/File_types_and_download_actions and
> https://firefox-source-docs.mozilla.org/uriloader/exthandler/index.html
> are silent on this subject.

Firefox starts whatever glib tells it is in the desktop file. If the
command in the desktop file ends up running urxvt, it's not Firefox's
fault. If the desktop file says "Terminal=true" and glib tells Firefox
to run urxvt, it's not Firefox's fault.

Mike



Bug#1003206: firefox: opening an unsupported text/* file with Emacs silently fails

2022-01-06 Thread Mike Hommey
On Fri, Jan 07, 2022 at 12:43:55AM +0100, Vincent Lefevre wrote:
> On 2022-01-07 05:58:36 +0900, Mike Hommey wrote:
> > On Thu, Jan 06, 2022 at 10:39:17AM +0100, Vincent Lefevre wrote:
> > > If Firefox is started in a terminal, I can see:
> > > 
> > > Can't locate utf8.pm:   /usr/share/perl5/utf8.pm: Permission denied at 
> > > /usr/lib/x86_64-linux-gnu/urxvt/urxvt.pm line 463.
> > > BEGIN failed--compilation aborted at 
> > > /usr/lib/x86_64-linux-gnu/urxvt/urxvt.pm line 463.
> > > Compilation failed in require at -e line 1.
> > > BEGIN failed--compilation aborted at -e line 1.
> > > urxvt: unable to initialize perl-interpreter, continuing without.
> > 
> > Sounds like your terminal has a problem, not Firefox.
> 
> I don't know why urxvt is failing, but anyway, the main question
> is why Firefox wants to start urxvt, and not xterm (the terminal
> I normally use).

Rephrasing: the main question is why your config/Emacs's desktop
file/Emacs's configuration/whatever wants to use urxvt, because
Firefox won't do that on its own.

Mike



Bug#1003206: firefox: opening an unsupported text/* file with Emacs silently fails

2022-01-06 Thread Mike Hommey
On Thu, Jan 06, 2022 at 10:39:17AM +0100, Vincent Lefevre wrote:
> Package: firefox
> Version: 95.0.1-1
> Severity: normal
> 
> Opening an unsupported text/* file with Emacs silently fails.
> For instance, on https://homepages.loria.fr/PZimmermann/CORE-MATH/
> the link "glibc" for acos / binary32
> 
>   https://homepages.loria.fr/PZimmermann/CORE-MATH/acosf-v1.patch
> 
> is served as text/x-diff (as seen with wget, since this is not clear
> with Firefox). Since text/x-diff is not supported, Firefox proposes
> to open it with
> 
>   Emacs (Terminal) (default)
> 
> but nothing happens, not even an error message.
> 
> If Firefox is started in a terminal, I can see:
> 
> Can't locate utf8.pm:   /usr/share/perl5/utf8.pm: Permission denied at 
> /usr/lib/x86_64-linux-gnu/urxvt/urxvt.pm line 463.
> BEGIN failed--compilation aborted at /usr/lib/x86_64-linux-gnu/urxvt/urxvt.pm 
> line 463.
> Compilation failed in require at -e line 1.
> BEGIN failed--compilation aborted at -e line 1.
> urxvt: unable to initialize perl-interpreter, continuing without.

Sounds like your terminal has a problem, not Firefox.

Mike



Bug#1001947: firefox-esr: Update from Firefox 78 to 91 reset browser.ctrlTab.sortByRecentlyUsed

2021-12-19 Thread Mike Hommey
On Sun, Dec 19, 2021 at 02:09:46PM +0200, Shai Berger wrote:
> Package: firefox-esr
> Version: 91.4.0esr-1
> Severity: normal
> 
> Dear Maintainer,
> 
> I have been using Firefox for years; an important part
> of the experience is having ctrl-tab go through tabs in
> the order of recent use, rather than cycling through them
> from left to right. This is not the default, but enabled
> by an about:config flag named 'browser.ctrlTab.sortByRecentlyUsed'
> 
> Following the very welcome upgrade from 78 to 91, I
> found that the browser reverted this flag to its default,
> and I had to set it on again manually (after finding again
> what it was named...)

Filed upstream as https://bugzilla.mozilla.org/show_bug.cgi?id=1746804
but at this point, this is probably unfixable... 

Note the pref is in Settings, under General > Tabs.

Mike



Bug#1001724: /usr/bin/firefox is difficult to wrap

2021-12-14 Thread Mike Hommey
reassign 1001724 firefox-esr
thanks

On Tue, Dec 14, 2021 at 04:18:36PM -0400, Joey Hess wrote:
> Package: firefox
> Version: 94.0.2-1
> Severity: normal
> 
> I have a ~/bin/firefox wrapper script ahead of the usual firefox in PATH.
> 
> #!/bin/sh
> MOZ_USE_XINPUT2=1 /usr/bin/firefox "$@"
> 
> This has a very surprising behavior, because /usr/bin/firefox contains:
> 
> FIREFOX="$(command -v firefox)"
> [ -x "$FIREFOX.real" ] && exec "$FIREFOX.real" "$@"
> 
> So FIREFOX gets set to ~/bin/firefox and there is no ~/bin/firefox.real
> to run. So instead it falls through and runs firefox-esr which I also happen
> to have installed. Since firefox-esr doesn't use my usual firefox
> config, my wrapper script effectively breaks the configuration.
> 
> The workaround was to change my wrapper script to this:
> 
> #!/bin/sh
> MOZ_USE_XINPUT2=1 PATH=/usr/bin:$PATH exec firefox "$@"
> 
> Although notice that this can turn into an infinite loop if firefox
> is somehow not in /usr/bin anymore. Also it prevents firefox from running
> any other wrapper scripts I might have in ~/bin when starting a program
> such as a PDF viewer. So this is a suboptimal workaround.
> 
> I don't know if there is a reason you are not using $0 or not simply
> hardcoding the path to firefox.real, either seems like a way to avoid this.

Using $0 causes #818159. I guess hardcoding /usr/bin/firefox would work.

Mike



Bug#1000472: bullseye-pu: package rustc-mozilla/1.51.0+dfsg1-1~deb11u1

2021-12-12 Thread Mike Hommey
On Sat, Dec 11, 2021 at 05:04:17PM -0500, Roberto C. Sánchez wrote:
> On Sun, Dec 12, 2021 at 06:34:01AM +0900, Mike Hommey wrote:
> > On Sat, Dec 11, 2021 at 01:54:21PM +, Adam D. Barratt wrote:
> > > On Tue, 2021-11-30 at 13:36 -0500, Roberto C.Sánchez wrote:
> > > > On Tue, Nov 30, 2021 at 06:00:57PM +, Adam D. Barratt wrote:
> > > > > On Tue, 2021-11-30 at 09:37 -0500, Roberto C.Sánchez wrote:
> > > > > > If there are no objections, I will proceed with uploading within
> > > > > > the
> > > > > > next 24 hours.  I'd like to ensure that the new FF/TB make it
> > > > > > into
> > > > > > the next point release if at all possible and that work is
> > > > > > currently
> > > > > > blocked by the need for the updated rustc.
> > > > > > 
> > > > > 
> > > > > I was assuming the plan was for the Firefox and Thunderbird updates
> > > > > to
> > > > > be released via the security archive. That's certainly how
> > > > > basically
> > > > > every other update to both packages occurs.
> > > > > 
> > > > Quite right.  I conflated the fact that LLVM and rustc are not going
> > > > in via security update.  Apologies for the confusion.
> > > 
> > > As a quick follow-up to this, with the 11.2 point release being next
> > > weekend, and thus the p-u freeze this weekend, I note that the rustc-
> > > mozilla upload is not yet in NEW, so we're starting to get quite close
> > > timing wise.
> > 
> > Relatedly, what's the plan for cargo in buster? Firefox ESR needs at
> > least 0.47, bullseye has 0.47, but buster has 0.43.1.
> 
> Emilio is working on that.  There were some tweaks needed to the
> rustc-mozilla packages I prepared in order to support his work.  As of
> this morning he identified some small additional tweaks, but he was able
> to work around the issues in order to get a FF build completed.  As soon
> as he gives me the thumbs up, then I will make the final tweaks and
> upload the rustc-mozilla packages.

Will it be cargo-mozilla in buster? How about cbindgen? Will it be
cbindgen-mozilla or is cbindgen just going to be updated?

Mike



Bug#1000472: bullseye-pu: package rustc-mozilla/1.51.0+dfsg1-1~deb11u1

2021-12-11 Thread Mike Hommey
On Sat, Dec 11, 2021 at 01:54:21PM +, Adam D. Barratt wrote:
> On Tue, 2021-11-30 at 13:36 -0500, Roberto C.Sánchez wrote:
> > On Tue, Nov 30, 2021 at 06:00:57PM +, Adam D. Barratt wrote:
> > > On Tue, 2021-11-30 at 09:37 -0500, Roberto C.Sánchez wrote:
> > > > If there are no objections, I will proceed with uploading within
> > > > the
> > > > next 24 hours.  I'd like to ensure that the new FF/TB make it
> > > > into
> > > > the next point release if at all possible and that work is
> > > > currently
> > > > blocked by the need for the updated rustc.
> > > > 
> > > 
> > > I was assuming the plan was for the Firefox and Thunderbird updates
> > > to
> > > be released via the security archive. That's certainly how
> > > basically
> > > every other update to both packages occurs.
> > > 
> > Quite right.  I conflated the fact that LLVM and rustc are not going
> > in via security update.  Apologies for the confusion.
> 
> As a quick follow-up to this, with the 11.2 point release being next
> weekend, and thus the p-u freeze this weekend, I note that the rustc-
> mozilla upload is not yet in NEW, so we're starting to get quite close
> timing wise.

Relatedly, what's the plan for cargo in buster? Firefox ESR needs at
least 0.47, bullseye has 0.47, but buster has 0.43.1.

Mike



Bug#1001334: RM: firefox-esr [mipsel] -- ROM; FTBFS

2021-12-08 Thread Mike Hommey
Package: ftp.debian.org
Severity: normal

Building some rust crates in the Firefox source tree now require more
memory than is available to userspace processes on mipsel (2GiB).

The existing package in testing is going to prevent the long awaited
testing migration of the package.

Mike



Bug#1001234: src:firefox-esr: fails to migrate to testing for too long: FTBFS on mipsel and unresolved RC bug

2021-12-08 Thread Mike Hommey
On Wed, Dec 08, 2021 at 10:31:32AM +0200, Martin-Éric Racine wrote:
> ke 8. jouluk. 2021 klo 9.41 Mike Hommey (m...@glandium.org) kirjoitti:
> > On Wed, Dec 08, 2021 at 09:07:24AM +0200, Martin-Éric Racine wrote:
> > > 91.4.0esr-1 was indeed uploaded. However, mipsel was not removed from the 
> > > list of architectures in the control file, so it attempted building. This 
> > > will likely prevent migration.
> >
> > I don't think removing the architecture from the control file would
> > change anything wrt migration.
> 
> It would.  AFAIK you explicitly need to declare:
> 
> Architecture: [!mipsel]
> 
> ... instead of any.
> 
> You'll also need to contact mipsel admins to ask them to remove the
> package from their port.

Removing the package is going to be necessary either way. I don't think
the lack of control change will prevent migration once the package is
removed.

> > > Better care in maintaining this package would be appreciated. CVE fixes 
> > > have yet to trickle into Testing or be uploaded to Stable-Updates for 
> > > over 60 days. That's not acceptable.
> >
> > For stable, it's not under my control.
> 
> Fair enough.
> 
> > AFAIK, the necessary rust compiler is still not available yet.
> 
> Which is inexcusable. 78 end of life was announced well ahead of time.
> There was plenty of time to prepare for this.

You can vent all you want, but that's not my fault.

Mike



Bug#1001234: src:firefox-esr: fails to migrate to testing for too long: FTBFS on mipsel and unresolved RC bug

2021-12-07 Thread Mike Hommey
On Wed, Dec 08, 2021 at 09:07:24AM +0200, Martin-Éric Racine wrote:
> Package: firefox-esr
> Version: 78.15.0esr-1~deb11u1
> Followup-For: Bug #1001234
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> 91.4.0esr-1 was indeed uploaded. However, mipsel was not removed from the 
> list of architectures in the control file, so it attempted building. This 
> will likely prevent migration.

I don't think removing the architecture from the control file would
change anything wrt migration.

> Better care in maintaining this package would be appreciated. CVE fixes have 
> yet to trickle into Testing or be uploaded to Stable-Updates for over 60 
> days. That's not acceptable.

For stable, it's not under my control. AFAIK, the necessary rust
compiler is still not available yet.

Mike



Bug#1001234: src:firefox-esr: fails to migrate to testing for too long: FTBFS on mipsel and unresolved RC bug

2021-12-06 Thread Mike Hommey
On Mon, Dec 06, 2021 at 09:01:24PM +0100, Paul Gevers wrote:
> Source: firefox-esr
> Version: 78.14.0esr-1
> Severity: serious
> Tags: sid bookworm ftbfs
> User: release.debian@packages.debian.org
> Usertags: out-of-sync
> Control: block -1 by 998679
> 
> Dear maintainer(s),
> 
> The Release Team considers packages that are out-of-sync between testing and
> unstable for more than 60 days as having a Release Critical bug in testing
> [1]. Your package src:firefox-esr has been trying to migrate for 61 days
> [2]. Hence, I am filing this bug. You have an unresolved RC bug and the
> latest uploaded FTBFS on mipsel.

The RC bug is going to be fixed today with a new upstream. The FTBFS on
mipsel is not going to go away ever. The rust compiler needs more than 2GB
of memory to compile a specific crate in Firefox, and processes on
mipsel can only get 2GB memory. The only way around that would be to
cross-compile, which Debian doesn't do as of today.  We'll have to remove
firefox-esr on mipsel.

Mike



Bug#948691: MOZ_APP_LAUNCHER

2021-11-26 Thread Mike Hommey
reassign 948691 thunderbird
ok

On Wed, Nov 24, 2021 at 02:19:15AM +0100, Jonathan Krebs wrote:
> I have this behavior on firefox 94 from sid,
> 
> I suspect the MOZ_APP_LAUNCHER environment variable, which is set by 
> thunderbird and evaluated in 
> browser/components/shell/nsGNOMEShellService.cpp:135
> 
> (Filtered) environment of firefox, when started through thunderbird (this 
> wants thunderbird.desktop as default browser):
> We have thunderbird in $MOZ_APP_LAUNCHER and firefox in 
> $GIO_LAUNCHED_DESKTOP_FILE

Thunderbird shouldn't set MOZ_APP_LAUNCHER.

Mike



Bug#997386: libnss3: cannot co-install libnss3-dbgsym:amd64 and libnss3-dbgsym:i386

2021-11-01 Thread Mike Hommey
On Sat, Oct 23, 2021 at 07:54:05PM +, Witold Baryluk wrote:
> Package: libnss3
> Version: 2:3.70-1
> Severity: important
> X-Debbugs-Cc: witold.bary...@gmail.com
> 
> As in title.
> 
> apt install libnss3-dbgsym:amd64 libnss3-dbgsym:i386
> 
> causes a conflict and failure:
> 
> 
> The following packages have unmet dependencies:
>  libnss3-dbgsym : Conflicts: libnss3-dbgsym:i386 but 2:3.70-1 is to be 
> installed
>  libnss3-dbgsym:i386 : Conflicts: libnss3-dbgsym but 2:3.70-1 is to be 
> installed

I don't know where these conflicts would come from. Not from the
package, at least:

$ wget 
http://snapshot.debian.org/archive/debian-debug/20210908T025327Z/pool/main/n/nss/libnss3-dbgsym_3.70-1_amd64.deb
$ dpkg -I libnss3-dbgsym_3.70-1_amd64.deb
 new Debian package, version 2.0.
 size 5326012 bytes: control archive=984 bytes.
 774 バイト、   14 行  control
 954 バイト、9 行  md5sums
 Package: libnss3-dbgsym
 Source: nss
 Version: 2:3.70-1
 Auto-Built-Package: debug-symbols
 Architecture: amd64
 Maintainer: Maintainers of Mozilla-related packages 

 Installed-Size: 5939
 Depends: libnss3 (= 2:3.70-1)
 Breaks: libnss3-dbg (<< 2:3.37-1~)
 Replaces: libnss3-dbg (<< 2:3.37-1~)
 Section: debug
 Priority: optional
 Description: debug symbols for libnss3
 Build-Ids: 2210ba11fe9481c172ba1969fd3d998c9b6c46fa 
288034785b5563a15acaca0d6e1a3a73785aa1fd 
48cf1be391fed01c9e46683309742ba05f9eb478 
7466955093731977b0d600a4491e848360750f5b 
8017c0d0d462eac86bab2d075e95cb377e0a969d 
80977bd1219b7cbdc44b3b5f0b5c4809a9b6f915 
b2f50ce30032950fcb7ae2b5b6ea849e7e4555d4 
beea65445f297154fddce58abc7b2742542cfefb 
f326dea22c916a7a8f6775264b0ea0536ed42d8a

Mike



Bug#996851: firefox: The New Tab search bar loses the first word of text pasted with the mouse

2021-10-19 Thread Mike Hommey
On Tue, Oct 19, 2021 at 05:59:18PM +0200, Vincent Lefevre wrote:
> Package: firefox
> Version: 93.0-1
> Severity: normal
> 
> Steps to reproduce:
> 
> 1. Open a new tab.
> 
> 2. Paste some text (e.g. "ab cd ef gh") in the search bar (saying
>"Search the web") with the middle button or via the contextual
>menu (right click over the search bar, then click on the "Paste"
>item).
> 
> A Google button appears in the address bar, followed by the text,
> but without the first word, e.g. I get "cd ef gh" without "ab".
> 
> There is no such issue when pasting directly in the address bar or
> when pasting with Ctrl-V.
> 
> This bug seems specific to Debian: I cannot reproduce this issue
> with upstream's Firefox 93.
> 
> FYI, the bug I had reported upstream:
> 
>   https://bugzilla.mozilla.org/show_bug.cgi?id=1733731
> 
> (but no-one can reproduce it on non-Debian machines).

I can't reproduce either.

Mike



Bug#986027: firefox: WebExtensions process sometimes consumes 100% CPU indefinitely on Firefox 87

2021-10-06 Thread Mike Hommey
On Thu, Oct 07, 2021 at 06:06:48AM +0200, Christoph Anton Mitterer wrote:
> On Thu, 2021-10-07 at 12:38 +0900, Mike Hommey wrote:
> > The linked upstream fix landed in version 88.0.
> 
> Uhm...? The commit is from 23 days ago, how could it have gone into 88?

Oh, I misread that bug status. That confirms the day after a covid
vaccine shot is not a good day to do anything.

Mike



Bug#986027: firefox: WebExtensions process sometimes consumes 100% CPU indefinitely on Firefox 87

2021-10-06 Thread Mike Hommey
On Wed, Oct 06, 2021 at 04:06:15PM +0200, Christoph Anton Mitterer wrote:
> Hey Mike.
> 
> Would it be possible to cherry pick the upstream candidate for fix...
> maybe at least for some version in experimental?
> 
> This issue really seems like a showstopper for everyone using addons.

The linked upstream fix landed in version 88.0. Unstable has had
versions newer than that for a while. As for firefox-esr, it has
91.2 as of yesterday.

That'd imply this is fixed?

Mike



Bug#993973: nss FTBFS with glibc 2.32: error: argument 1 is null but the corresponding size argument 2 value is 4096 [-Werror=nonnull]

2021-09-08 Thread Mike Hommey
On Thu, Sep 09, 2021 at 12:52:03AM +0200, Aurelien Jarno wrote:
> control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=27476
> 
> On 2021-09-09 00:21, Helmut Grohne wrote:
> > Source: nss
> > Version: 2:3.70-1
> > Severity: serious
> > Tags: ftbfs
> > X-Debbugs-Cc: debian-gl...@lists.debian.org
> > 
> > A native build of nss now fails as follows:
> > 
> > | x86_64-linux-gnu-gcc -o OBJS/nsinstall.o -c -std=c99 -g -g -fPIC   -pipe 
> > -ffunction-sections -fdata-sections -DHAVE_STRERROR -DLINUX -Dlinux -Wall 
> > -Wshadow -Werror -DXP_UNIX -DXP_UNIX -DDEBUG -UNDEBUG -D_DEFAULT_SOURCE 
> > -D_BSD_SOURCE -D_POSIX_SOURCE -DSDB_MEASURE_USE_TEMP_DIR -D_REENTRANT 
> > -DDEBUG -UNDEBUG -D_DEFAULT_SOURCE -D_BSD_SOURCE -D_POSIX_SOURCE 
> > -DSDB_MEASURE_USE_TEMP_DIR -D_REENTRANT -DNSS_NO_INIT_SUPPORT 
> > -DUSE_UTIL_DIRECTLY -DNO_NSPR_10_SUPPORT 
> > -DSSL_DISABLE_DEPRECATED_CIPHER_SUITE_NAMES -I/<>/dist/include 
> > -I/<>/dist/public/coreconf 
> > -I/<>/dist/private/coreconf  nsinstall.c
> > | nsinstall.c: In function ‘main’:
> > | nsinstall.c:70:16: error: argument 1 is null but the corresponding size 
> > argument 2 value is 4096 [-Werror=nonnull]
> > |70 | #define GETCWD getcwd
> > |   |^
> > | nsinstall.c:239:8: note: in expansion of macro ‘GETCWD’
> > |   239 |  cwd = GETCWD(0, PATH_MAX);
> > |   |^~
> > | In file included from nsinstall.c:20:
> > | /usr/include/unistd.h:520:14: note: in a call to function ‘getcwd’ 
> > declared with attribute ‘write_only (1, 2)’
> > |   520 | extern char *getcwd (char *__buf, size_t __size) __THROW __wur
> > |   |  ^~
> > | nsinstall.c:70:16: error: argument 1 is null but the corresponding size 
> > argument 2 value is 4096 [-Werror=nonnull]
> > |70 | #define GETCWD getcwd
> > |   |^
> > | nsinstall.c:246:13: note: in expansion of macro ‘GETCWD’
> > |   246 | todir = GETCWD(0, PATH_MAX);
> > |   | ^~
> > | In file included from nsinstall.c:20:
> > | /usr/include/unistd.h:520:14: note: in a call to function ‘getcwd’ 
> > declared with attribute ‘write_only (1, 2)’
> > |   520 | extern char *getcwd (char *__buf, size_t __size) __THROW __wur
> > |   |  ^~
> > | cc1: all warnings being treated as errors
> > | make[2]: *** [../../coreconf/rules.mk:292: OBJS/nsinstall.o] Error 1
> > | make[2]: Leaving directory '/<>/nss/coreconf/nsinstall'
> > | make[1]: *** [debian/rules:100: override_dh_auto_build] Error 2
> > | make[1]: Leaving directory '/<>'
> > | make: *** [debian/rules:195: build] Error 2
> > | dpkg-buildpackage: error: debian/rules build subprocess returned exit 
> > status 2
> > 
> > It looks very much like this is due to the glibc 2.32 upload. My reading
> > of man getcwd is that the call of nss is legit (as a glibc extension).
> > Maybe this is a glibc bug?
> 
> This is indeed partially a glibc bug, already reported upstream there:
> https://sourceware.org/bugzilla/show_bug.cgi?id=27476
> 
> Note however that the feature of calling getcwd(NULL, >0) is a GNU
> extension, and that the above code doesn't define _GNU_SOURCE, so this
> is also a bug in the package.

That said, it's also an extension in Solaris.

Mike



Bug#993973: nss FTBFS with glibc 2.32: error: argument 1 is null but the corresponding size argument 2 value is 4096 [-Werror=nonnull]

2021-09-08 Thread Mike Hommey
reassign 993973 libc6-dev
found 993973 2.32-1
thanks

On Thu, Sep 09, 2021 at 12:21:52AM +0200, Helmut Grohne wrote:
> Source: nss
> Version: 2:3.70-1
> Severity: serious
> Tags: ftbfs
> X-Debbugs-Cc: debian-gl...@lists.debian.org
> 
> A native build of nss now fails as follows:
> 
> | x86_64-linux-gnu-gcc -o OBJS/nsinstall.o -c -std=c99 -g -g -fPIC   -pipe 
> -ffunction-sections -fdata-sections -DHAVE_STRERROR -DLINUX -Dlinux -Wall 
> -Wshadow -Werror -DXP_UNIX -DXP_UNIX -DDEBUG -UNDEBUG -D_DEFAULT_SOURCE 
> -D_BSD_SOURCE -D_POSIX_SOURCE -DSDB_MEASURE_USE_TEMP_DIR -D_REENTRANT -DDEBUG 
> -UNDEBUG -D_DEFAULT_SOURCE -D_BSD_SOURCE -D_POSIX_SOURCE 
> -DSDB_MEASURE_USE_TEMP_DIR -D_REENTRANT -DNSS_NO_INIT_SUPPORT 
> -DUSE_UTIL_DIRECTLY -DNO_NSPR_10_SUPPORT 
> -DSSL_DISABLE_DEPRECATED_CIPHER_SUITE_NAMES -I/<>/dist/include 
> -I/<>/dist/public/coreconf 
> -I/<>/dist/private/coreconf  nsinstall.c
> | nsinstall.c: In function ‘main’:
> | nsinstall.c:70:16: error: argument 1 is null but the corresponding size 
> argument 2 value is 4096 [-Werror=nonnull]
> |70 | #define GETCWD getcwd
> |   |^
> | nsinstall.c:239:8: note: in expansion of macro ‘GETCWD’
> |   239 |  cwd = GETCWD(0, PATH_MAX);
> |   |^~
> | In file included from nsinstall.c:20:
> | /usr/include/unistd.h:520:14: note: in a call to function ‘getcwd’ declared 
> with attribute ‘write_only (1, 2)’
> |   520 | extern char *getcwd (char *__buf, size_t __size) __THROW __wur
> |   |  ^~
> | nsinstall.c:70:16: error: argument 1 is null but the corresponding size 
> argument 2 value is 4096 [-Werror=nonnull]
> |70 | #define GETCWD getcwd
> |   |^
> | nsinstall.c:246:13: note: in expansion of macro ‘GETCWD’
> |   246 | todir = GETCWD(0, PATH_MAX);
> |   | ^~
> | In file included from nsinstall.c:20:
> | /usr/include/unistd.h:520:14: note: in a call to function ‘getcwd’ declared 
> with attribute ‘write_only (1, 2)’
> |   520 | extern char *getcwd (char *__buf, size_t __size) __THROW __wur
> |   |  ^~
> | cc1: all warnings being treated as errors
> | make[2]: *** [../../coreconf/rules.mk:292: OBJS/nsinstall.o] Error 1
> | make[2]: Leaving directory '/<>/nss/coreconf/nsinstall'
> | make[1]: *** [debian/rules:100: override_dh_auto_build] Error 2
> | make[1]: Leaving directory '/<>'
> | make: *** [debian/rules:195: build] Error 2
> | dpkg-buildpackage: error: debian/rules build subprocess returned exit 
> status 2
> 
> It looks very much like this is due to the glibc 2.32 upload. My reading
> of man getcwd is that the call of nss is legit (as a glibc extension).
> Maybe this is a glibc bug?

Quoting man getcwd:

  As an extension to the POSIX.1-2001 standard, glibc's getcwd() allocates
  the buffer dynamically using malloc(3) if buf is NULL. In this case, the
  allocated buffer has the length size unless size is zero, when buf is
  allocated as big as necessary

But that's from manpages-dev. The documentation from glibc itself says:

  The GNU C Library version of this function also permits you to specify
  a null pointer for the buffer argument. Then getcwd allocates a buffer
  automatically, as with malloc (see Unconstrained Allocation). If the
  size is greater than zero, then the buffer is that large; otherwise,
  the buffer is as large as necessary to hold the result. 

Which is essentially the same thing. The unistd.h header itself says:

  In GNU, if BUF is NULL, an array is allocated with `malloc'; the array
  is SIZE bytes long, unless SIZE == 0, in which case it is as big as
  necessary.

This doesn't fit with the use of __attribute__((access(write_only(1, 2
IMO.

Mike



Bug#992213: release-notes: Release notes should mention lxc issues with cgroups change

2021-08-21 Thread Mike Hommey
On Sat, Aug 21, 2021 at 11:19:52PM +0200, Paul Gevers wrote:
> Hi Mike,
> 
> On 21-08-2021 23:11, Mike Hommey wrote:
> > On Sat, Aug 21, 2021 at 10:50:13PM +0200, Paul Gevers wrote:
> >> Hi Mike,
> >>
> >> On 16-08-2021 22:29, Paul Gevers wrote:
> >>> Hi Mike,
> >>>
> >>> Sorry for brevity, I'm in a hurry.
> >>>
> >>> On 15-08-2021 23:08, Mike Hommey wrote:
> >>>> The release notes has a section about the issues with openstack, but
> >>>> there are also problems with lxc. I'm not sure what the proper
> >>>> workaround is, but setting `lxc.mount.auto = cgroup:mixed:force` fixed
> >>>> it for me.
> >>>
> >>> Can you elaborate what the issues are you experience with LXC?
> >>
> >> ping.
> > 
> > Sorry, I somehow missed your email.
> > 
> > Containers would just not start, with messages like:
> >   Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted
> >   [!!] Failed to mount API filesystems.
> >   Exiting PID 1...
> 
> Interesting. We heavily use lxc on ci.d.n (all tests run in one) and we
> haven't experienced this. I'm wondering what the specifics of you
> system(s) is that trigger the issue. Do you have ideas?

I actually don't. I have some containers that trigger it, and some that
don't. I wasn't able to figure out why.

Mike



Bug#992213: release-notes: Release notes should mention lxc issues with cgroups change

2021-08-21 Thread Mike Hommey
On Sat, Aug 21, 2021 at 10:50:13PM +0200, Paul Gevers wrote:
> Hi Mike,
> 
> On 16-08-2021 22:29, Paul Gevers wrote:
> > Hi Mike,
> > 
> > Sorry for brevity, I'm in a hurry.
> > 
> > On 15-08-2021 23:08, Mike Hommey wrote:
> >> The release notes has a section about the issues with openstack, but
> >> there are also problems with lxc. I'm not sure what the proper
> >> workaround is, but setting `lxc.mount.auto = cgroup:mixed:force` fixed
> >> it for me.
> > 
> > Can you elaborate what the issues are you experience with LXC?
> 
> ping.

Sorry, I somehow missed your email.

Containers would just not start, with messages like:
  Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted
  [!!] Failed to mount API filesystems.
  Exiting PID 1...

Mike



Bug#992219: [Pkg-zfsonlinux-devel] Bug#992219: zfs-dkms: Error! Bad return status for module build on kernel: 5.13.0-trunk-amd64 (x86_64)

2021-08-15 Thread Mike Hommey
severity 992219 important
retitle 992219 Cannot open 
/usr/src/linux-headers-5.13.0-trunk-common/scripts/modules-check.sh: No such 
file
thanks

On Sun, Aug 15, 2021 at 06:48:02PM -0600, Antonio Russo wrote:
> Control: severity -1 wishlist
> Control: retitle -1 Please backport support for 5.13
> 
> Hello,
> 
> ZFS 2.0.3 doesn't support 5.13.  Neither does 2.0.5, (which is a
> matter of some friction).  You'll have to switch to 2.1 if you
> can't wait -- and I haven't gotten around to packaging it yet.
> 
> - Antonio

The bug was reassigned to the linux-headers package because before
reaching the point where it is made apparent that zfs 2.0.3 doesn't
support Linux 5.13, we hit an error coming from a missing file in the
linux-headers package.



Bug#992219: zfs-dkms: Error! Bad return status for module build on kernel: 5.13.0-trunk-amd64 (x86_64)

2021-08-15 Thread Mike Hommey
reassign 992219 linux-headers-5.13.0-trunk-common
thanks

On Mon, Aug 16, 2021 at 09:31:25AM +0900, Mike Hommey wrote:
> Package: zfs-dkms
> Version: 2.0.3-9
> Severity: important
> 
> Dear Maintainer,
> 
> Installing zfs-dkms with the linux kernel currently in experimental
> fails with:
> 
> Preparing to unpack .../zfs-dkms_2.0.3-9_all.deb ...
> Unpacking zfs-dkms (2.0.3-9) ...
> Setting up zfs-dkms (2.0.3-9) ...
> Loading new zfs-2.0.3 DKMS files...
> Building for 5.13.0-trunk-amd64
> Building initial module for 5.13.0-trunk-amd64
> configure: error:
>   *** Unable to build an empty module.
> 
> Error! Bad return status for module build on kernel: 5.13.0-trunk-amd64 
> (x86_64)
> Consult /var/lib/dkms/zfs/2.0.3/build/make.log for more information.
> dpkg: error processing package zfs-dkms (--configure):
>  installed zfs-dkms package post-installation script subprocess returned 
> error exit status 10
> 
> 
> The contents of /var/lib/dkms/zfs/2.0.3/build/make.log are:
> 
> DKMS make.log for zfs-2.0.3 for kernel 5.13.0-trunk-amd64 (x86_64)
> Mon Aug 16 09:29:50 JST 2021
> make: *** No targets specified and no makefile found.  Stop.

This turns out to be a problem with the
linux-headers-5.13.0-trunk-common package.

zfs-dkms's configure runs the following:
KBUILD_MODPOST_NOFINAL= KBUILD_MODPOST_WARN= make modules -k -j64 -C 
/lib/modules/5.13.0-trunk-amd64/build 
M=/var/lib/dkms/zfs/2.0.3/build/build/conftest >build/conftest/build.log 2>&1

That output log file contains:

  CC [M]  /var/lib/dkms/zfs/2.0.3/build/build/conftest/conftest.o
sh: 0: cannot open 
/usr/src/linux-headers-5.13.0-trunk-common/scripts/modules-check.sh: No such 
file
make[1]: *** [/usr/src/linux-headers-5.13.0-trunk-common/Makefile:1796: 
modules_check] Error 2
make[1]: Target 'modules' not remade because of errors.
make: *** [/usr/src/linux-headers-5.13.0-trunk-common/Makefile:232: __sub-make] 
Error 2
make: Target 'modules' not remade because of errors.
make: Leaving directory '/usr/src/linux-headers-5.13.0-trunk-amd64'

It turns out the modules-check.sh file is missing from the headers
package.

Mike



Bug#992219: zfs-dkms: Error! Bad return status for module build on kernel: 5.13.0-trunk-amd64 (x86_64)

2021-08-15 Thread Mike Hommey
Package: zfs-dkms
Version: 2.0.3-9
Severity: important

Dear Maintainer,

Installing zfs-dkms with the linux kernel currently in experimental
fails with:

Preparing to unpack .../zfs-dkms_2.0.3-9_all.deb ...
Unpacking zfs-dkms (2.0.3-9) ...
Setting up zfs-dkms (2.0.3-9) ...
Loading new zfs-2.0.3 DKMS files...
Building for 5.13.0-trunk-amd64
Building initial module for 5.13.0-trunk-amd64
configure: error:
*** Unable to build an empty module.

Error! Bad return status for module build on kernel: 5.13.0-trunk-amd64 (x86_64)
Consult /var/lib/dkms/zfs/2.0.3/build/make.log for more information.
dpkg: error processing package zfs-dkms (--configure):
 installed zfs-dkms package post-installation script subprocess returned error 
exit status 10


The contents of /var/lib/dkms/zfs/2.0.3/build/make.log are:

DKMS make.log for zfs-2.0.3 for kernel 5.13.0-trunk-amd64 (x86_64)
Mon Aug 16 09:29:50 JST 2021
make: *** No targets specified and no makefile found.  Stop.

(I need to use the version in experimental because the version in
bullseye has some bugs on my hardware that are fixed in that version)

-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.13.0-trunk-amd64 (SMP w/64 CPU threads)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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 zfs-dkms depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  dkms   2.8.4-3
ii  file   1:5.39-3
ii  libc6-dev [libc-dev]   2.31-13
ii  libpython3-stdlib  3.9.2-3
ii  lsb-release11.1.0
ii  perl   5.32.1-4+deb11u1
ii  python3-distutils  3.9.2-1

Versions of packages zfs-dkms recommends:
ii  linux-libc-dev  5.10.46-4
iu  zfs-zed 2.0.3-9
ii  zfsutils-linux  2.0.3-9

Versions of packages zfs-dkms suggests:
ii  debhelper  13.3.4

-- debconf information:
* zfs-dkms/note-incompatible-licenses:
  zfs-dkms/stop-build-for-unknown-kernel: true
  zfs-dkms/stop-build-for-32bit-kernel: true



Bug#992213: release-notes: Release notes should mention lxc issues with cgroups change

2021-08-15 Thread Mike Hommey
Package: release-notes
Severity: important

The release notes has a section about the issues with openstack, but
there are also problems with lxc. I'm not sure what the proper
workaround is, but setting `lxc.mount.auto = cgroup:mixed:force` fixed
it for me.

Mike



Bug#960304: snapshot.debian.org: Snapshot repo repeatedly cutting off connection, returning partial content

2021-08-06 Thread Mike Hommey
Package: snapshot.debian.org
Followup-For: Bug #960304

Dear Maintainer,

We're hitting this problem regularly on Mozilla CI (from using dget),
and what is probably a variant of this bug with apt, which fails with,
for example:

[task 2021-08-05T21:27:09.094Z] Err:187 
http://snapshot.debian.org/archive/debian/20210208T213147Z jessie/main amd64 
adwaita-icon-theme all 3.14.0-2
[task 2021-08-05T21:27:09.094Z]   Undetermined Error [IP: 193.62.202.27 80]
(...)
[task 2021-08-05T21:27:23.590Z] Err:202 
http://snapshot.debian.org/archive/debian/20210208T213147Z jessie/main amd64 
libicu52 amd64 52.1-8+deb8u7
[task 2021-08-05T21:27:23.591Z]   Undetermined Error [IP: 193.62.202.27 80]
(...)
[task 2021-08-05T21:28:41.210Z] E: Failed to fetch 
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/a/adwaita-icon-theme/adwaita-icon-theme_3.14.0-2_all.deb
  Undetermined Error [IP: 193.62.202.27 80]
[task 2021-08-05T21:28:41.210Z] E: Failed to fetch 
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/i/icu/libicu52_52.1-8+deb8u7_amd64.deb
  Undetermined Error [IP: 193.62.202.27 80]

Corresponding server-side log for the same url:
54.162.202.139 - - [05/Aug/2021:21:27:08 +] "GET 
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/a/adwaita-icon-theme/adwaita-icon-theme_3.14.0-2_all.deb
 HTTP/1.1" 200 3518464 "-" "Debian APT-HTTP/1.3 (1.8.2.2)"
54.202.218.195 - - [05/Aug/2021:21:39:12 +] "GET 
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/a/adwaita-icon-theme/adwaita-icon-theme_3.14.0-2_all.deb
 HTTP/1.1" 200 9978092 "-" "Debian APT-HTTP/1.3 (1.8.2.2)"

Mike



Bug#991134: firefox: connection failures when opening links in a new tab

2021-07-15 Thread Mike Hommey
On Thu, Jul 15, 2021 at 12:35:17PM +0200, Vincent Lefevre wrote:
> Package: firefox
> Version: 88.0.1-1
> Severity: normal
> 
> When opening a link in a new tab, connections sometimes fail, either
> for the HTML page, in which case Firefox displays an error message,
> or for the CSS, in which case the page is displayed without the CSS.
> This is always immediate, i.e. this is *not* some kind of timeout.
> I need to reload the page.
> 
> This seems to occur only when opening links in a new tab (and perhaps
> in a new window), not in the current tab, so that I suspect a bug in
> Firefox. This issue is quite recent (a few weeks?).
> 
> Note: This time, I was using an automatic proxy configuration URL, but
> I don't always use it. Anyway, this has also occurred for localhost,
> which is never proxied.
> 
> Firefox 90 should be available in unstable to see if this issue still
> occurs with it...

It's in experimental. It's not in unstable because a necessary build
dependency is not available in unstable because of the freeze.

(and I don't reproduce)



Bug#888831: NS_ERROR_NET_INADEQUATE_SECURITY error on armhf/arm64 at least

2021-07-07 Thread Mike Hommey
On Wed, Jul 07, 2021 at 03:35:48PM +0200, Raphael Hertzog wrote:
> The simplest fix is thus to let nss migrate into bullseye.

The simplest fix is a binNMU of firefox-esr because the issue was fixed
in NSS, but since there's going to be a security update for firefox-esr
next week, I didn't ask for a binNMU. See bug 990699.

Mike



Bug#990699: release.debian.org: Sorting out bug 990059 in bullseye

2021-07-04 Thread Mike Hommey
Package: release.debian.org
Severity: important
Usertags: binnmu transition

Hi,

Recent versions of libnss3 had a backwards incompatible change that made
packages built with the newer versions fail to work properly with the older
version of the package that is in bullseye.

That wouldn't be a problem if 2 packages that use the problematic symbol
and are built with the newer version hadn't themselves made it to
bullseye. The packages are, namely, firefox-esr and curl (curl has only
become a problem this week).

I uploaded a version of nss (2:3.67-2) that works around the issue and
will make rebuilds of those packages work with the version of nss in
bullseye, meaning we'd need binNMUs of both curl and firefox-esr and
subsequent transitions.

However, firefox-esr is due for a security update next tuesday/wednesday,
so it will be rebuilt anyways. I guess we might as well wait.

Which leaves us with just curl.

 nmu curl_7.74.0-1.3 . ANY . -m 'Rebuild against newer libnss3-dev'

Mike



Bug#990059: Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality

2021-07-04 Thread Mike Hommey
On Mon, Jul 05, 2021 at 08:14:45AM +0900, Mike Hommey wrote:
> On Mon, Jul 05, 2021 at 07:57:30AM +0900, Mike Hommey wrote:
> > reopen 990059
> > affects 990059 firefox-esr firefox libcurl3-nss
> > thanks
> > 
> > On Sat, Jun 19, 2021 at 09:00:13AM +0200, Carsten Schoenert wrote:
> > > Hello Kevin, hello Sebastian,
> > > 
> > > thanks for working on this issue in between times, I wasn't able to do
> > > anything practically the last days.
> > > 
> > > Am 18.06.21 um 23:31 schrieb Kevin Locke:
> > > > Hi Sebastian,
> > > > 
> > > > On Fri, 2021-06-18 at 22:26 +0200, Sebastian Ramacher wrote:
> > > >> Thanks for this detailed analysis. That actually means that the symbol
> > > >> file for libnss3 2:3.67-1 is broken. It would need to bump the minimum
> > > >> version requirement for all symbols that works with SSLChannelInfo. 
> > > >> From
> > > >> your description, at least the version for SSL_GetChannelInfo would 
> > > >> need
> > > >> to be bumped. If thunderbird would then be built against a libnss3
> > > >> version with a fixed symbol files, it would pick up tight enought
> > > >> dependencies.
> > > >>
> > > >> So ideally the bug against thunderbird would be reassigned to libnss3
> > > >> 2:3.67-1 and its severits raised to serious. Once fixed, we can rebuild
> > > >> thunderbird to pick up the correct depedencies.
> > > > 
> > > > Good point.  Fixing the libnss3 symbol file sounds like the right fix to
> > > > me.  As far as I can tell SSL_GetChannelInfo is the only symbol which
> > > > takes SSLChannelInfo.  I've opened https://bugs.debian.org/990058 with
> > > > the proposed fix.
> > > 
> > > Fixing libnss3 is obviously the correct thing anyway. But this will take
> > > its time to get it landed into bullseye.
> > > 
> > > >> But since that version of libnss3 is not in bullseye, the rebuild would
> > > >> not be abile to migrate. Ideally libnss3 would be reverted to the
> > > >> version in bullseye to avoid this issue. Otherwise I can schedule
> > > >> binNMUs of thunderbird in tpu, but that means that we would need to do
> > > >> that for any thunderbird upload that we want in bullseye until the
> > > >> release. That is suboptimal - it's more work with less testing.
> > > > 
> > > > That may be tricky.  firefox 88.0.1-1 in unstable depends on
> > > > libnss3 (>= 2:3.63~).  If the maintainers are willing to upload an NSS
> > > > version between 2:3.63 and 2:3.65, I believe that would solve the issue
> > > > without breaking firefox.  (2:3.63-1 is the only suitable version
> > > > in debian/changelog.)  I've opened https://bugs.debian.org/990059 to
> > > > discuss.
> > > 
> > > To prevent quite a lot of work on all involved parties with not that
> > > much gain in the end I'd suggest to go back to my option B that was to
> > > (re)build Thunderbird with it's internal shipped NSS version.
> > 
> > Unfortunately, this affects more than Thunderbird. It also affects
> > Firefox ESR (although not on amd64 because for some reason it was built
> > against an older version of NSS, but it affects other architectures). It
> > also affects the latest upload of curl.
> 
> It also affects openjdk-17, openjdk-8 and pcp in sid, if they're ever
> meant to transition to testing (which, from the look of it, is probably
> not the case).

Scrap that, openjdk* and pcp are not using the problematic symbol.

Mike



Bug#990058: libnss3: increase symbol version for SSL_GetChannelInfo when SSLChannelInfo size changes

2021-07-04 Thread Mike Hommey
severity 990058 normal
thanks

With #990059 addressed in 2:3.67-2, this can be downgraded to normal.
The problem also exists with other functions, which is why I'll keep
this open for a more complete and long-term solution.

Mike

On Fri, Jun 18, 2021 at 03:09:36PM -0600, Kevin Locke wrote:
> Package: libnss3
> Version: 2:3.67-1
> Severity: serious
> Tags: patch
> Justification: Policy 8.6.3.3
> X-Debbugs-Cc: Sebastian Ramacher , Carsten Schoenert 
> 
> 
> Dear Maintainer,
> 
> Thunderbird 1:78.11.0-1 in testing is unable to establish some (all?)
> TLS connections when run with libnss3 2:3.61-1, because it was built
> with libnss3-dev 2:3.66-1.  The issue occurs because the size of
> SSLChannelInfo increased between NSS 3.61 and 3.66 (due to the addition
> of PRBool isFIPS).  SSL_GetChannelInfo takes both a pointer to and size
> of SSLChannelInfo as arguments.  If the size is greater than the size it
> expects, it returns SECFailure, causing the connection to fail.  See
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989839#48 for details.
> 
> The issue is being discussed on debian-release, where Sebastian Ramacher
> pointed out that the libnss3 symbol file should bump the minimum version
> requirement for all symbols that works with SSLChannelInfo.[1]  I agree.
> As far as I can tell, SSL_GetChannelInfo is the only such symbol.  I
> believe it should be bumped to 2:3.66 for package 2:3.67 and bumped in
> future versions whenever the size of SSLChannelInfo changes.  I've
> attached a patch to do so.
> 
> Thanks for considering,
> Kevin
> 
> [1]: https://lists.debian.org/debian-release/2021/06/msg00597.html
> 
> -- System Information:
> Debian Release: 11.0
>   APT prefers testing-debug
>   APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 
> 'unstable-debug'), (500, 'testing-security'), (500, 'stable-debug'), (500, 
> 'unstable'), (500, 'oldstable'), (101, 'experimental'), (1, 
> 'experimental-debug')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.13.0-rc6 (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 /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages libnss3 depends on:
> ii  libc6 2.31-12
> ii  libnspr4  2:4.29-1
> ii  libsqlite3-0  3.34.1-3
> 
> libnss3 recommends no packages.
> 
> libnss3 suggests no packages.
> 
> -- no debconf information

> >From eaffc616b99dd2be285ade5df072cfa1e30924fe Mon Sep 17 00:00:00 2001
> Message-Id: 
> 
> From: Kevin Locke 
> Date: Fri, 18 Jun 2021 14:41:27 -0600
> Subject: [PATCH] libnss3.symbols: bump SSL_GetChannelInfo to 2:3.66
> 
> PRBool isFIPS was added to SSLChannelInfo in NSS 3.66, causing its size
> to increase.  Since SSL_GetChannelInfo is called with
> sizeof(SSLChannelInfo) and returns SECFailure when called with a larger
> size than it expects, it creates a version incompatibility where
> programs compiled with NSS >= 3.66 do not function correction when
> loaded with NSS < 3.66, as in #989839 for thunderbird.
> 
> To avoid breakage, bump the version of SSL_GetChannelInfo, as suggested
> by Sebastian Ramacher in
> https://lists.debian.org/debian-release/2021/06/msg00597.html
> 
> Signed-off-by: Kevin Locke 
> ---
>  debian/libnss3.symbols | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/debian/libnss3.symbols b/debian/libnss3.symbols
> index 5213379c..2bb7294a 100644
> --- a/debian/libnss3.symbols
> +++ b/debian/libnss3.symbols
> @@ -154,5 +154,5 @@ libssl3.so libnss3 #MINVER#
>   (symver)NSS_3.4 2:3.13.4-2~
>   (symver)NSS_3.7.4 2:3.13.4-2~
>   SSL_GetCipherSuiteInfo@NSS_3.4 2:3.44.0
> - SSL_GetChannelInfo@NSS_3.4 2:3.34
> + SSL_GetChannelInfo@NSS_3.4 2:3.66
>   SSL_GetPreliminaryChannelInfo@NSS_3.21 2:3.44.0
> -- 
> 2.30.2
> 



Bug#989839: Bug#990059: Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality

2021-07-04 Thread Mike Hommey
On Mon, Jul 05, 2021 at 07:57:30AM +0900, Mike Hommey wrote:
> reopen 990059
> affects 990059 firefox-esr firefox libcurl3-nss
> thanks
> 
> On Sat, Jun 19, 2021 at 09:00:13AM +0200, Carsten Schoenert wrote:
> > Hello Kevin, hello Sebastian,
> > 
> > thanks for working on this issue in between times, I wasn't able to do
> > anything practically the last days.
> > 
> > Am 18.06.21 um 23:31 schrieb Kevin Locke:
> > > Hi Sebastian,
> > > 
> > > On Fri, 2021-06-18 at 22:26 +0200, Sebastian Ramacher wrote:
> > >> Thanks for this detailed analysis. That actually means that the symbol
> > >> file for libnss3 2:3.67-1 is broken. It would need to bump the minimum
> > >> version requirement for all symbols that works with SSLChannelInfo. From
> > >> your description, at least the version for SSL_GetChannelInfo would need
> > >> to be bumped. If thunderbird would then be built against a libnss3
> > >> version with a fixed symbol files, it would pick up tight enought
> > >> dependencies.
> > >>
> > >> So ideally the bug against thunderbird would be reassigned to libnss3
> > >> 2:3.67-1 and its severits raised to serious. Once fixed, we can rebuild
> > >> thunderbird to pick up the correct depedencies.
> > > 
> > > Good point.  Fixing the libnss3 symbol file sounds like the right fix to
> > > me.  As far as I can tell SSL_GetChannelInfo is the only symbol which
> > > takes SSLChannelInfo.  I've opened https://bugs.debian.org/990058 with
> > > the proposed fix.
> > 
> > Fixing libnss3 is obviously the correct thing anyway. But this will take
> > its time to get it landed into bullseye.
> > 
> > >> But since that version of libnss3 is not in bullseye, the rebuild would
> > >> not be abile to migrate. Ideally libnss3 would be reverted to the
> > >> version in bullseye to avoid this issue. Otherwise I can schedule
> > >> binNMUs of thunderbird in tpu, but that means that we would need to do
> > >> that for any thunderbird upload that we want in bullseye until the
> > >> release. That is suboptimal - it's more work with less testing.
> > > 
> > > That may be tricky.  firefox 88.0.1-1 in unstable depends on
> > > libnss3 (>= 2:3.63~).  If the maintainers are willing to upload an NSS
> > > version between 2:3.63 and 2:3.65, I believe that would solve the issue
> > > without breaking firefox.  (2:3.63-1 is the only suitable version
> > > in debian/changelog.)  I've opened https://bugs.debian.org/990059 to
> > > discuss.
> > 
> > To prevent quite a lot of work on all involved parties with not that
> > much gain in the end I'd suggest to go back to my option B that was to
> > (re)build Thunderbird with it's internal shipped NSS version.
> 
> Unfortunately, this affects more than Thunderbird. It also affects
> Firefox ESR (although not on amd64 because for some reason it was built
> against an older version of NSS, but it affects other architectures). It
> also affects the latest upload of curl.

It also affects openjdk-17, openjdk-8 and pcp in sid, if they're ever
meant to transition to testing (which, from the look of it, is probably
not the case).

Mike



Bug#990059: Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality

2021-07-04 Thread Mike Hommey
reopen 990059
affects 990059 firefox-esr firefox libcurl3-nss
thanks

On Sat, Jun 19, 2021 at 09:00:13AM +0200, Carsten Schoenert wrote:
> Hello Kevin, hello Sebastian,
> 
> thanks for working on this issue in between times, I wasn't able to do
> anything practically the last days.
> 
> Am 18.06.21 um 23:31 schrieb Kevin Locke:
> > Hi Sebastian,
> > 
> > On Fri, 2021-06-18 at 22:26 +0200, Sebastian Ramacher wrote:
> >> Thanks for this detailed analysis. That actually means that the symbol
> >> file for libnss3 2:3.67-1 is broken. It would need to bump the minimum
> >> version requirement for all symbols that works with SSLChannelInfo. From
> >> your description, at least the version for SSL_GetChannelInfo would need
> >> to be bumped. If thunderbird would then be built against a libnss3
> >> version with a fixed symbol files, it would pick up tight enought
> >> dependencies.
> >>
> >> So ideally the bug against thunderbird would be reassigned to libnss3
> >> 2:3.67-1 and its severits raised to serious. Once fixed, we can rebuild
> >> thunderbird to pick up the correct depedencies.
> > 
> > Good point.  Fixing the libnss3 symbol file sounds like the right fix to
> > me.  As far as I can tell SSL_GetChannelInfo is the only symbol which
> > takes SSLChannelInfo.  I've opened https://bugs.debian.org/990058 with
> > the proposed fix.
> 
> Fixing libnss3 is obviously the correct thing anyway. But this will take
> its time to get it landed into bullseye.
> 
> >> But since that version of libnss3 is not in bullseye, the rebuild would
> >> not be abile to migrate. Ideally libnss3 would be reverted to the
> >> version in bullseye to avoid this issue. Otherwise I can schedule
> >> binNMUs of thunderbird in tpu, but that means that we would need to do
> >> that for any thunderbird upload that we want in bullseye until the
> >> release. That is suboptimal - it's more work with less testing.
> > 
> > That may be tricky.  firefox 88.0.1-1 in unstable depends on
> > libnss3 (>= 2:3.63~).  If the maintainers are willing to upload an NSS
> > version between 2:3.63 and 2:3.65, I believe that would solve the issue
> > without breaking firefox.  (2:3.63-1 is the only suitable version
> > in debian/changelog.)  I've opened https://bugs.debian.org/990059 to
> > discuss.
> 
> To prevent quite a lot of work on all involved parties with not that
> much gain in the end I'd suggest to go back to my option B that was to
> (re)build Thunderbird with it's internal shipped NSS version.

Unfortunately, this affects more than Thunderbird. It also affects
Firefox ESR (although not on amd64 because for some reason it was built
against an older version of NSS, but it affects other architectures). It
also affects the latest upload of curl.

I'm going to upload a new version of 3.67 that will restore the binary
compat so that things built against the new version will work with the
older one. That should allow to binNMU the affected packages.

Mike



Bug#989696: mk-build-deps: --remove should also remove changes and buildinfo files

2021-06-17 Thread Mike Hommey
On Thu, Jun 10, 2021 at 01:30:12PM -0400, Ryan Kavanagh wrote:
> Package: devscripts
> Version: 2.21.2
> Severity: wishlist
> 
> The --remove option removes the package file after installing it.
> It should also remove the changes and buildinfo file.

I'd argue it shouldn't create changes and buildinfo files in the first
place (which it didn't do before).

Mike



Bug#989192: diffoscope: Differences in file lists are repeated at each depth level

2021-05-27 Thread Mike Hommey
Package: diffoscope
Version: 175
Severity: normal

STR:
- mkdir -p a/foo/bar b/foo/bar
- touch a/foo/bar/baz b/foo/bar/qux
- diffoscope a b --exclude-directory-metadata=recursive

Actual result:
--- a
+++ b
├── file list
│ @@ -1,3 +1,3 @@
│  foo
│  foo/bar
│ -foo/bar/baz
│ +foo/bar/qux
│   --- a/foo
├── +++ b/foo
│ ├── file list
│ │ @@ -1,2 +1,2 @@
│ │  bar
│ │ -bar/baz
│ │ +bar/qux
│ │   --- a/foo/bar
│ ├── +++ b/foo/bar
│ │ ├── file list
│ │ │ @@ -1 +1 @@
│ │ │ -baz
│ │ │ +qux

Expected Result:
--- a
+++ b
│   --- a/foo
├── +++ b/foo
│ │   --- a/foo/bar
│ ├── +++ b/foo/bar
│ │ ├── file list
│ │ │ @@ -1 +1 @@
│ │ │ -baz
│ │ │ +qux


Bug#988724: firefox: Firefox 88 unusable on intel gpu

2021-05-25 Thread Mike Hommey
On Mon, May 24, 2021 at 08:51:43AM +0200, Kamil Jońca wrote:
> 
> 
> Mike Hommey  writes:
> >
> > Can you also provide about:support content for that working firefox 88?

Can you go to about:config, set gfx.webrender.software to true, then
restore your Xorg configuration and try again?

Mike



Bug#988724: firefox: Firefox 88 unusable on intel gpu

2021-05-23 Thread Mike Hommey
On Sun, May 23, 2021 at 01:55:54PM +0200, Kamil Jońca wrote:
> 
> Mike Hommey  writes:
> 
> > On Tue, May 18, 2021 at 07:39:27PM +0200, Kamil Jońca wrote:
> >> Package: firefox
> >> Version: 87.0-2
> >> Severity: important
> >> X-Debbugs-Cc: kjo...@poczta.onet.pl
> >> 
> >> Dear Maintainer,
> >> 
> >> *** Reporter, please consider answering these questions, where appropriate 
> >> ***
> >> 
> >>* What led up to the situation?
> >> Upgrade to 88.0.1 version
> >>* What exactly did you do (or not do) that was effective (or
> >>  ineffective)?
> >> Start firefox 
> >> 
> >>* What was the outcome of this action?
> >> white window, not responsive.
> >> 
> >>* What outcome did you expect instead?
> >> 
> >> Normally functioning firefox.
> >> 
> >> *** End of the template - remove these template lines ***
> >
> > In Firefox 87, can you go to about:support and copy/paste its content?
> >
> 
> To record: I experimented after issuing bug and found that I have file
> for load intel drivers.:
> 
> --8<---cut here---start->8---
> %cat /etc/X11/xorg.conf.d/10-intel.conf
> Section "Device"
>Identifier  "Intel"
>Driver  "intel"
>BusID   "PCI:0:2:0"
> EndSection
> --8<---cut here---end--->8---
> 
> When I commented out this file (which I believe makes that x.org uses
> "modesetting" driver), firefox 88 starts to work.

Can you also provide about:support content for that working firefox 88?

Thanks

Mike



Bug#988724: firefox: Firefox 88 unusable on intel gpu

2021-05-20 Thread Mike Hommey
On Tue, May 18, 2021 at 07:39:27PM +0200, Kamil Jońca wrote:
> Package: firefox
> Version: 87.0-2
> Severity: important
> X-Debbugs-Cc: kjo...@poczta.onet.pl
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> Upgrade to 88.0.1 version
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> Start firefox 
> 
>* What was the outcome of this action?
> white window, not responsive.
> 
>* What outcome did you expect instead?
> 
> Normally functioning firefox.
> 
> *** End of the template - remove these template lines ***

In Firefox 87, can you go to about:support and copy/paste its content?

Thanks

Mike



Bug#969174: firefox: FF80 seems to have broken all add-ons on existing profiles

2021-02-08 Thread Mike Hommey
On Sun, Feb 07, 2021 at 04:18:50PM +0100, Antoine Le Gonidec wrote:
> With firefox 85.0.1-1, my extensions installed from Debian repositories are 
> no longer disabled on launch.
> 
> I made sure to restart Firefox several times to not get tricked by the 
> temporary normal behaviour right after a firefox update. I browsed a couple 
> Web pages too, to check that the add-ons are actually working and not merely 
> showing as active.
> 
> - firefox 85.0.1-1
> - webext-ublock-origin-firefox 1.32.0+dfsg-1
> - webext-umatrix 1.4.0+dfsg-1
> 

I can confirm, but while I was also able to reproduce with older
versions of Firefox, I can't reproduce it anymore... so I'm not sure...

Mike



Bug#981710: mmdebstrap doesn't use debian-archive-removed-keys.gpg for jessie

2021-02-02 Thread Mike Hommey
Package: mmdebstrap
Version: 0.7.4-1
Severity: normal

Dear Maintainer,

Running `mmdebstrap --variant=extract jessie` fails with
```
E: The repository 'http://deb.debian.org/debian jessie Release' is not signed.
```
after multiple GPG warnings.

Adding `--keyring /usr/share/keyrings/debian-archive-removed-keys.gpg`
works around it, but a cursory look at the code suggests this is
supposed to happen automatically.

Mike



Bug#981709: mmdebstrap: check/qemu should be skipped by default for the extract variant

2021-02-02 Thread Mike Hommey
Package: mmdebstrap
Version: 0.7.4-1
Severity: normal

Dear Maintainer,

Running `mmdebstrap --variant=extract --architectures=`
fails with
```
E: $arch can neither be executed natively nor via qemu user emulation with 
binfmt_misc
```

It works with `--skip check/qemu`, but this should probably be the default
considering --variant=extract doesn't install packages and thus doesn't
run anything under its architecture.

Mike



Bug#981184: firefox-esr: doesn't load pages over internet

2021-01-29 Thread Mike Hommey
On Thu, Jan 28, 2021 at 07:31:32PM +0900, Mike Hommey wrote:
> On Thu, Jan 28, 2021 at 11:04:23AM +0100, Emilian Nowak wrote:
> > On 2021-01-28, at 06:17:07 Mike Hommey wrote:
> > 
> > > Can you try upgrading libnss3?
> > 
> > After upgrading from 
> > 
> > libnss3: 2:3.56-1
> > to 2:3.60-1 firefox works normally.
> > 
> > Thanks for tip. 
> > 
> > Shouldn't this firefox version depend on this version of libnss3 ? 
> 
> firefox does the right thing, but the patch is not applied to
> firefox-esr yet.

Actually, they both have what I was thinking about. This is another
issue :(

Mike



Bug#981184: firefox-esr: doesn't load pages over internet

2021-01-28 Thread Mike Hommey
On Thu, Jan 28, 2021 at 11:04:23AM +0100, Emilian Nowak wrote:
> On 2021-01-28, at 06:17:07 Mike Hommey wrote:
> 
> > Can you try upgrading libnss3?
> 
> After upgrading from 
> 
> libnss3: 2:3.56-1
> to 2:3.60-1 firefox works normally.
> 
> Thanks for tip. 
> 
> Shouldn't this firefox version depend on this version of libnss3 ? 

firefox does the right thing, but the patch is not applied to
firefox-esr yet.

Mike



Bug#981184: firefox-esr: doesn't load pages over internet

2021-01-27 Thread Mike Hommey
On Wed, Jan 27, 2021 at 01:23:02PM +0100, Emilian Nowak wrote:
> Package: firefox-esr
> Version: 78.6.1esr-1
> Severity: important
> 
> Dear Maintainer,
> Every time i try to open page from internet for example bugs.debian.org -
> nothing happnes. Page is not loading.
> 
> I can see in developer console that request is send, but
> there is no response.
> 
> When I access my http on http://localhost it works as expected.
> I tested it on safe-mode, and one clean newly created user.
> 
> Screenshot attached from developer console.

Can you try upgrading libnss3?

Mike



Bug#981153: cargo: Please package new upstream

2021-01-26 Thread Mike Hommey
Source: cargo
Version: 0.47.0-3
Severity: wishlist

Firefox now requires version 0.48, latest upstream is 0.50, and unstable
is on 0.47.

Mike



Bug#978588: firefox: should depend on either libgdk-pixbuf package

2020-12-29 Thread Mike Hommey
reassign 978588 libgdk-pixbuf2.0-dev
thanks

On Tue, Dec 29, 2020 at 10:22:49AM +1100, David Tulloh wrote:
> Package: firefox
> Version: 84.0-3
> Severity: important
> 
> The libgdk-pixbuf packages are migrating from
> libgdk-pixbuf2.0-0 to libgdk-pixbuf-2.0.0
> 
> The most recent firefox package has matched this name transition.
> 
> However many other packages have not yet made the transition, causing
> clashes which require their removal. Popular packages include
> mutter and gimp. This significantly impacts the overall usability of the
> system.
> 
> The dependency should be: libgdk-pixbuf-2.0-0 | libgdk-pixbuf2.0-0
> 
> This is the practice recommended by libgdk-pixbuf
> 
> Firefox only requires 2.22.0 which either package can meet.

I think that rather than having reverse dependencies handle this all one
by one, this should be handled by libgdk-pixbuf itself, via its symbols
file, leaving it to dh_shlibdeps to add the desired deps.

Mike



Bug#972665: ICE building firefox-esr/firefox in unstable on armhf

2020-10-22 Thread Mike Hommey
On Thu, Oct 22, 2020 at 11:12:14AM +0200, Matthias Klose wrote:
> On 10/22/20 9:57 AM, Mike Hommey wrote:
> >> The code in question hasn't changed in a long time, so the same code
> >> effectively built fine with older versions of gcc. The last successful
> >> builds of firefox-esr and firefox were using gcc-10_10.2.0-9.
> >>
> >> I see in the gcc-10 changelog there is "On armel, armhf, configure with
> >> --enable-checking=yes,extra,rtl", this could be related.
> 
> no, that was added to track down that kind of issue.  Do you see the example
> failing every time, or is it just random?

every time.

Mike



Bug#972665: ICE building firefox-esr/firefox in unstable on armhf

2020-10-22 Thread Mike Hommey
And _of course_ I forgot to attach the file.

On Thu, Oct 22, 2020 at 04:50:58PM +0900, Mike Hommey wrote:
> Package: gcc-10
> Version: 10.2.0-15
> Severity: serious
> 
> See the full buildd log in 
> https://buildd.debian.org/status/fetch.php?pkg=firefox-esr=armhf=78.4.0esr-2=1603260510=0
> 
> The preprocessed source that fails is attached as intrapred_neon.i.gz.
> 
> This is reproducible on armhf with:
>gcc -o intrapred_neon.o -c -O1 -mfpu=neon intrapred_neon.i
> 
> The shortened ICE message looks like:
> 
> during RTL pass: reload
> /home/glandium/firefox-esr-78.4.0esr/third_party/aom/aom_dsp/arm/intrapred_neon.c:
>  In function 'aom_highbd_dc_predictor_4x4_neon':
> /home/glandium/firefox-esr-78.4.0esr/third_party/aom/aom_dsp/arm/intrapred_neon.c:589:188:
>  internal compiler error: in decompose_automod_address, at rtlanal.c:6298
>   589 | intra_pred_square(dc);
>   |   
>   
>^
> 0x6cda45 decompose_automod_address
> ../../src/gcc/rtlanal.c:6298
> 0x6cda45 decompose_address(address_info*, rtx_def**, machine_mode, unsigned 
> char, rtx_code)
> ../../src/gcc/rtlanal.c:6463
> 0x6cdb19 decompose_mem_address(address_info*, rtx_def*)
> ../../src/gcc/rtlanal.c:6486
> 0x59a67b process_address_1
> ../../src/gcc/lra-constraints.c:3374
> 0x59c4cd process_address
> ../../src/gcc/lra-constraints.c:3648
> 0x59c4cd curr_insn_transform
> ../../src/gcc/lra-constraints.c:3963
> 0x5a088f lra_constraints(bool)
> ../../src/gcc/lra-constraints.c:5036
> 0x58e7a5 lra(_IO_FILE*)
> ../../src/gcc/lra.c:2443
> 0x54f331 do_reload
> ../../src/gcc/ira.c:5527
> 0x54f331 execute
> ../../src/gcc/ira.c:5713
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> 
> 
> The code in question hasn't changed in a long time, so the same code
> effectively built fine with older versions of gcc. The last successful
> builds of firefox-esr and firefox were using gcc-10_10.2.0-9.
> 
> I see in the gcc-10 changelog there is "On armel, armhf, configure with
> --enable-checking=yes,extra,rtl", this could be related.
> 
> Mike


intrapred_neon.i.gz
Description: application/gzip


Bug#972665: ICE building firefox-esr/firefox in unstable on armhf

2020-10-22 Thread Mike Hommey
Package: gcc-10
Version: 10.2.0-15
Severity: serious

See the full buildd log in 
https://buildd.debian.org/status/fetch.php?pkg=firefox-esr=armhf=78.4.0esr-2=1603260510=0

The preprocessed source that fails is attached as intrapred_neon.i.gz.

This is reproducible on armhf with:
   gcc -o intrapred_neon.o -c -O1 -mfpu=neon intrapred_neon.i

The shortened ICE message looks like:

during RTL pass: reload
/home/glandium/firefox-esr-78.4.0esr/third_party/aom/aom_dsp/arm/intrapred_neon.c:
 In function 'aom_highbd_dc_predictor_4x4_neon':
/home/glandium/firefox-esr-78.4.0esr/third_party/aom/aom_dsp/arm/intrapred_neon.c:589:188:
 internal compiler error: in decompose_automod_address, at rtlanal.c:6298
  589 | intra_pred_square(dc);
  | 

   ^
0x6cda45 decompose_automod_address
../../src/gcc/rtlanal.c:6298
0x6cda45 decompose_address(address_info*, rtx_def**, machine_mode, unsigned 
char, rtx_code)
../../src/gcc/rtlanal.c:6463
0x6cdb19 decompose_mem_address(address_info*, rtx_def*)
../../src/gcc/rtlanal.c:6486
0x59a67b process_address_1
../../src/gcc/lra-constraints.c:3374
0x59c4cd process_address
../../src/gcc/lra-constraints.c:3648
0x59c4cd curr_insn_transform
../../src/gcc/lra-constraints.c:3963
0x5a088f lra_constraints(bool)
../../src/gcc/lra-constraints.c:5036
0x58e7a5 lra(_IO_FILE*)
../../src/gcc/lra.c:2443
0x54f331 do_reload
../../src/gcc/ira.c:5527
0x54f331 execute
../../src/gcc/ira.c:5713
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


The code in question hasn't changed in a long time, so the same code
effectively built fine with older versions of gcc. The last successful
builds of firefox-esr and firefox were using gcc-10_10.2.0-9.

I see in the gcc-10 changelog there is "On armel, armhf, configure with
--enable-checking=yes,extra,rtl", this could be related.

Mike



Bug#971531: firefox-esr: Firefox-esr doesn't apply scale factor of system

2020-10-01 Thread Mike Hommey
On Thu, Oct 01, 2020 at 12:22:16PM +0200, Teo wrote:
> Package: firefox-esr
> Version: 78.3.0esr-2
> Severity: normal
> Tags: a11y
> X-Debbugs-Cc: teodoro777.coluc...@live.com
> 
> When I enlarge the text through the scale factor, for example setting it on
> 1.25, I can see all app with enlarged text, except firefox.
> Searching on internet I see that this is a known bug, like you can see here
> https://bugzilla.mozilla.org/show_bug.cgi?id=1604761
> I read that it has already been fixed in version 73.0b2, but trying the
> 78.3.0esr version, now available in testing, this doesn't seem to be true.

This sounds like https://bugzilla.mozilla.org/show_bug.cgi?id=1554850

Mike



Bug#969174: firefox: FF80 seems to have broken all add-ons on existing profiles

2020-09-02 Thread Mike Hommey
On Thu, Sep 03, 2020 at 06:41:55AM +0200, Christoph Anton Mitterer wrote:
> On Thu, 2020-09-03 at 10:37 +0900, Mike Hommey wrote:
> > With the following steps, I _don't_ reproduce:
> > - create a fresh unstable chroot and enter it
> > - install firefox 79 and webext-ublock-origin
> > - start firefox
> > - stop firefox
> > - upgrade firefox to 80
> > - start firefox
> 
> Well... god know what causes it... could be some legacy cruft in the
> settings from long ago, and thus you wouldn't see it when just
> simulating the upgrade from a 79 profile to 80.
> 
> 
> Once possibly interesting side node:
> When I start FF80 (with the "legacy" profile)... then I see the add-on
> icons for like a second until they vanish (and with the functionality
> of the add-ons).

Try going to about:config, switch extensions.logging.enabled to true,
and try to reproduce, then open the browser console from the web
developer menu and see if there's anything useful.

Mike



Bug#969174: firefox: FF80 seems to have broken all add-ons on existing profiles

2020-09-02 Thread Mike Hommey
On Sat, Aug 29, 2020 at 03:57:17PM +0200, Christoph Anton Mitterer wrote:
> On Sat, 2020-08-29 at 10:55 +0200, Jean-Marc wrote:
> > One remark nevertheless : if I open the page about:support and click
> > on the button "Refresh Firefox..." and then re-start Firefox, I got
> > the icon of the add-ons I installed through Debian packages meaning
> > noScript, privacy Badger and uBlock Origin in the FF bar.
> > 
> > Chris, can you try this ?
> 
> What (temporarily) worked for me was to disable/re-enable the addons
> with the switch in the add-ons menu... but after restarting they were
> all gone again.
> 
> IMO this is even a security issue, as it breaks security-relevant
> plugins like noscript or https-everywhere.
> 
> > Chris, Mike, did you install add-ons from Debian or directly from FF
> > repository ?
> 
> All from Debian, all unstable.

With the following steps, I _don't_ reproduce:
- create a fresh unstable chroot and enter it
- install firefox 79 and webext-ublock-origin
- start firefox
- stop firefox
- upgrade firefox to 80
- start firefox

After all this, ublock works just fine.

Mike



  1   2   3   4   5   6   7   8   9   10   >