Bug#1051606: RM: sysprof [i386] -- RoM; ANAIS; The GUI binary package is no longer built

[jeremy . bicha]

The removals page suggests removing too much. I think this string would work:

dak rm -p -d 1051606 -R -C package -m "RoM; ANAIS; The GUI binary package is no 
longer built" -b -a i386 sysprof

Thank you,
Jeremy Bícha

Bug#1043144: transition: mutter/gnome-shell 44

[jeremy . bicha]

Graham, please add a few more hints:

age-days 2 budgie-desktop/10.8-2
age-days 2 gnome-remote-desktop/44.2-6
age-days 2 gnome-shell-extension-dashtodock/87-1

remove gnome-shell-extension-no-annoyance/0+20220925-c6804a4-3
remove bfh-metapackages/20211009-20

Thank you,
Jeremy Bícha

Bug#986545: ITP: gnome-tour -- A modern introduction and tour to GNOME

[jeremy . bicha]

Control: owner -1 jeremy.bi...@canonical.com
Control: retitle -1 ITP: gnome-tour -- A modern introduction and tour to GNOME

This is blocked on ftpmasters letting rust-libadwaita-sys
(and afterwards rust-libadwaita) into Debian.

Meanwhile, I am uploading this to Ubuntu. My packaging is at
https://salsa.debian.org/gnome-team/gnome-tour

Thank you,
Jeremy Bícha

Bug#1019604: bsfilter: FTBFS with ruby3.1: ERROR: Test "ruby3.1" failed.

[Jeremy Bicha]

Control: reopen -1

No, bsfilter does still fail to build in Debian Unstable, presumably
triggered by ruby 3.1.

This can also be seen with the autopkgtest failures.
https://ci.debian.net/packages/b/bsfilter/unstable/amd64/

Thank you,
Jeremy Bicha

Bug#1029614: blueprint-compiler: crashes when run on s390x

[Jeremy Bicha]

Control: severity -1 important
Control: tags -1 + trixie

We removed gnome-shell-extension-manager and dialect from s390x. This
means that this issue is no longer release critical.

Thank you,
Jeremy Bicha

Bug#1030354: RM: dialect [s390x] -- RoQA; NBS

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-Cc: dial...@packages.debian.org
Affects: src:dialect

Please remove dialect from s390x because it no longer builds there.
See https://bugs.debian.org/1029614

It's generally understood that s390x isn't really a desktop
architecture. dialect is a GNOME app.

dialect has no reverse dependencies.

dialect was not packaged for Debian 11 so this removal won't be a
regression compared to Debian 11.

Thanks,
Jeremy Bicha

Bug#1030353: RM: gnome-shell-extension-manager [s390x] -- ROM; NBS

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-Cc: gnome-shell-extension-mana...@packages.debian.org
Affects: src:gnome-shell-extension-manager

Please remove gnome-shell-extension-manager from s390x because it no
longer builds there. See https://bugs.debian.org/1029614

It's generally understood that s390x isn't really a desktop architecture.

gnome-shell-extension-manager has no reverse dependencies.

gnome-shell-extension-manager was not packaged for Debian 11 so this
removal won't be a regression compared to Debian 11.

Thanks,
Jeremy Bicha

Bug#1030331: scribus: enable harfbuzz subset feature

[Jeremy Bicha]

Source: scribus
Version: 6.0.0+dfsg-3
Severity: wishlist

The scribus maintainer requested that harfbuzz make available the
subset library. This has been done now in Unstable. See
https://bugs.debian.org/988781

Therefore, please rebuild scribus to pick up the new library. There
wasn't any change to harfbuzz-dev or a need to add a new -dev library
for the subset feature. I suppose you could optionally raise the
dependency on harfbuzz to >= 6.0.0+dfsg-2~

New build log excerpt
---
Harfbuzz library Found OK
-- Checking for module 'icu-uc'
--   Found icu-uc, version 72.1
-- Checking for module 'harfbuzz-subset>=2.4.0'
--   Found harfbuzz-subset, version 6.0.0
Harfbuzz subset library Found OK


Thank you,
Jeremy Bicha

Bug#1030195: RM: pytango [s390x] -- RoQA; NBS; no arch-specific reverse-dependencies

[Jeremy Bicha]

Ubuntu did the s390x removal, by the way.

https://launchpad.net/bugs/2004445

Thank you,
Jeremy Bicha

Bug#1030195: RM: pytango [s390x] -- RoQA; NBS; no arch-specific reverse-dependencies

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-Cc: pyta...@packages.debian.org
Affects: src:pytango

Please remove the binary package python3-tango on s390x. This will
allow the package to migrate back into Testing. No s390x package
depends on it.

python3-tango is not arch:all because it builds an
architecture-dependent file (C extension for Python).

python3-tango arch:all reverse dependencies
-
pan-control-systems (recommends)
python3-itango
python3-sardana
python3-taurus
python3-taurus-pyqtgraph (indirect)

This leaves one other reverse (build) dependency, python3-xrstools
which is only built on amd64 and all (and currently is not in
Testing).

There was a Debian bug filed against the package for the s390x issue
but there has been no response: https://bugs.debian.org/1017990

Thanks,
Jeremy Bicha

Bug#1029980: pyglossary: typo in package description

[Jeremy Bicha]

Source: pyglossary
Version: 4.5.0-2
Severity: minor

The package short description is
Description: tool for workig with dictionary databases - Python 3.X

Please replace workig with working

Thank you,
Jeremy Bicha

Bug#1029979: pyglossary: re-enable build test

[Jeremy Bicha]

Source: pyglossary
Version: 4.5.0-2

Please re-enable the build test for pyglossary.

I think the test will work again if you add these to Build-Depends
   python3-gi ,
   gir1.2-gtk-3.0 ,

Thank you,
Jeremy Bicha

Bug#1029955: scrape-schema-recipe: missing build dependency, python3-extruct

[Jeremy Bicha]

Source: scrape-schema-recipe
Version: 0.2.0-1
Severity: serious
Tags: ftbfs

scrape-schema-recipe fails to build from source in a clean minimal
build environment. It appears to have a test dependency on
python3-extruct. The package builds when I add that package name to
the list of Build-Depends. You may also need to adjust the Depends to
ensure the resulting package has everything it needs to work.

By the way, extruct will need a source-only upload to be able to
migrate to Testing. Although, extruct depends on python-pyrdfa which
is not in Testing because it no longer is successfully buildable.

Build log excerpt
--
ModuleNotFoundError: No module named 'extruct'

Full build log

Click amd64 at
https://launchpad.net/ubuntu/+source/scrape-schema-recipe/0.2.0-1

Thank you,
Jeremy Bicha

Bug#1029907: ITP: xdg-terminal-exec -- user default terminal execution utility

[Jeremy Bicha]

On Sat, Jan 28, 2023 at 7:18 PM Simon McVittie  wrote:
> I think a better route might be to get it into experimental for now, then
> when it seems like it has stabilized more, put it into unstable/trixie
> and potentially also bookworm-backports.

It's in the NEW queue targeted for experimental now.

The only place it's been packaged so far is the Arch Linux AUR:
https://repology.org/project/xdg-terminal-exec/versions

Thank you,
Jeremy Bicha

Bug#1029907: ITP: xdg-terminal-exec -- user default terminal execution utility

[Jeremy Bicha]

Package: wnpp
Severity: wishlist
Owner: jeremy.bi...@canonical.com
X-Debbugs-CC: debian-de...@lists.debian.org

Package Name: xdg-terminal-exec
Version: git snapshot
Upstream Author: Vladimir Kudrya
License: GPL-3+
Programming Lang: Shell

Description: user default terminal execution utility
 xdg-terminal-exec is an implementation of a proposed freedesktop.org
 specification for launching a user's default terminal app.

Other Info
--
I will maintain this with the Debian freedesktop.org team. Packaging is at
https://salsa.debian.org/freedesktop-team/xdg-terminal-exec

This solves a problem: currently you can use update-alternatives to
choose a default terminal for a Debian system, but what happens when
you have multiple users on the same Debian system with different
preferences?

I don't think the "proposed specification" has been fully drafted yet.
There is some discussion at
https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/54
and over the years in the xdg mailing list.

More recently, the alpha for glib 2.76 (part of GNOME 44 Alpha) now
supports xdg-terminal -exec and GNOME Terminal 3.46.7 includes the
necessary metadata file. We might backport the glib feature to Debian
Bookworm, but it is quite late in Bookworm's release process.

The metadata would also need to be added to other terminal emulator
apps and desktops that use glib would need to ship a metadata file
with their preferred terminal emulators.

There is no GUI way for users to override the preference; they would
need to add/edit the config file in their home directory manually.

More details in the README at https://github.com/Vladimir-csp/xdg-terminal-exec

Thanks,
Jeremy Bicha

Bug#1029707: Maybe set DejaVu Sans Mono as default font for Arabic

[Jeremy Bicha]

On Thu, Jan 26, 2023 at 5:39 PM Gunnar Hjalmarsson  wrote:
> That detail made me curious. I suppose it's related to this commit:
>
> https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/ad70d785
>
> Which is not only about monospace, but affects most Debian users, also
> for sans-serif and serif, and also for web browsing, since
> fonts-noto-core is installed by default (probably due to the meta
> package libreoffice).
>
> That's a pretty radical change to come from fontconfig upstream. Hello
> Noto, goodbye DejaVu. Was it even discussed anywhere?

The individual who made the change upstream started this discussion:
https://fedoraproject.org/wiki/Changes/DefaultToNotoFonts

Thank you,
Jeremy Bicha

Bug#1029722: lintian-brush: upstream-metadata should add Repository line

[Jeremy Bicha]

On Thu, Jan 26, 2023 at 2:48 PM Jelmer Vernooij  wrote:
> Do you happen to have a few examples handy?

First one is Github, second is https://gitlab.gnome.org

https://salsa.debian.org/werdahias/trompeloeil/ as of January 22
https://salsa.debian.org/gnome-team/gnome-weather

Thank you,
Jeremy Bicha

Bug#1029722: lintian-brush: upstream-metadata should add Repository line

[Jeremy Bicha]

On Thu, Jan 26, 2023 at 2:36 PM Jelmer Vernooij  wrote:
> It does actally support setting the Repository field, but it will verify
> that the upstream repository looks plausible - i.e. that it has at least
> some tags matching upstream versions. That verification is probably
> broken for some reason.

It isn't adding the Repository field most of the time that I've been
running it this month.

Thank you,
Jeremy Bicha

Bug#1029722: lintian-brush: upstream-metadata should add Repository line

[Jeremy Bicha]

Source: lintian-brush
Version: 0.146

The upstream-metadata-file fixer creates the Repository-Browse line
but not the Repository line.

Recent versions of git-buildpackage support use that field. For instance:

gbp clone https://salsa.debian.org/gnome-team/gnome-console --add-upstream-vcs

For Github and Gitlab, the Repository field is the same as
Repository-Browse but with a .git suffix.

Thank you,
Jeremy Bicha

Bug#1029614: blueprint-compiler: crashes when run on s390x

[Jeremy Bicha]

Source: blueprint-compiler
Version: 0.6.0-1
Severity: serious
Tags: ftbfs bookworm sid upstream
Forwarded: https://gitlab.gnome.org/jwestman/blueprint-compiler/-/issues/96
Affects: src: gnome-shell-extension-manager, src:dialect

Things that use blueprint-compiler are failing to build on s390x. This
is preventing important fixes from reaching Testing/Bookworm.

Thank you,
Jeremy Bicha

Bug#1029473: gnome-settings-daemon: automatic suspend after 20 minutes is undesired by some users

[Jeremy Bicha]

On Mon, Jan 23, 2023 at 3:09 PM Witold Baryluk  wrote:
> I will consider some workaround on my side, or adjusting default in my
> live-build build itself (as long as it is used only by me).

Another workaround is to create a file named something like
/usr/share/glib-2.0/schemas/90_local_override.gschema.override

with contents
# Custom local override for https://bugs.debian.org/1029473
[org.gnome.settings-daemon.plugins.power]
sleep-inactive-ac-timeout = 0

then run
sudo glib-compile-schemas /usr/share/glib-2.0/schemas

Ubuntu basically does this, although I'm not sure whether it's a good
idea for Ubuntu to be doing it.

Thank you,
Jeremy Bicha

Bug#1029380: sra-toolkit: Has hard-coded dependency on obsolete libncbi-wvdb2 (>= 2.10.6+dfsg-3~),

[Jeremy Bicha]

Package: sra-toolkit
Version: 2.11.3+dfsg-1
Severity: serious

sra-toolkit has a manually Depends: libncbi-wvdb2 (>= 2.10.6+dfsg-3~)

But libncbi-wvdb2 is no longer built from source.

Generally, you should let ${shlibs:Depends} add the dependency so that
a simple rebuild can handle many soname bump transitions.

Thank you,
Jeremy Bicha

Bug#990746: /usr/bin/thawab-gtk: thawab fails to start.

[Jeremy Bicha]

I am uploading thawab 4.1-3 now which fixes the initial reported error.

However, then I get this error, which would take more work to fix properly:

$ thawab-gtk
Traceback (most recent call last):
  File "/usr/bin/thawab-gtk", line 5, in 
from Thawab.gtkUi import main
  File "/usr/share/thawab/Thawab/gtkUi.py", line 35, in 
from Thawab.shamelaUtils import ShamelaSqlite, shamelaImport
  File "/usr/share/thawab/Thawab/shamelaUtils.py", line 51, in 
os.urandom(hashlen*3/4).encode('base64')[:hashlen]
TypeError: 'float' object cannot be interpreted as an integer

Thank you,
Jeremy Bicha

Bug#1029206: [pre-approval] unblock: webkit2gtk 2.40.0-2

[Jeremy Bicha]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock transition moreinfo
Tags: security
X-Debbugs-CC: webkit2...@packages.debian.org

I am filing this bug early so that the Release Team is aware early.

[ Reason ]
webkit2gtk only provides security support for one stable series at a
time. A new series is released each March and September. The Debian
Security Team backports these new release as security updates [1] [2]

The upcoming 2.40.0 is more disruptive than usual as it makes a major
API break for the new GTK4 library, bumping the API series from 5 to 6
[3]. This causes a small transition: gnome-builder 43 and
gnome-initial-setup 43 are the only two packages that use the gtk4
library. They will both need sourceful uploads. Patches will be ready
for both since the upstream webkitgtk team works closely with the
GNOME project.

[ Impact ]
Because the 2.38 series will be End of Life before Debian 12 is
released, I believe the Security Team wants 2.40 to make it to Testing

[ Tests ]
There are no automated tests (!)
The person who uploads gnome-builder and gnome-initial-setup (likely
me) will make sure those 2 apps still run well with the new webkit2gtk
version.

[ Risks ]
The code changes in a new major webkit2gtk release are too large to
manually review.
webkit2gtk is a key package.
Besides gnome-builder and gnome-initial-setup, webkit2gtk is used by
many packages. [4]

[ Checklist ]
  [ ] all changes are documented in the d/changelog
  [ ] I reviewed all changes and I approve them
  [ ] attach debdiff against the package in testing

[ Other Info ]
webkit2gtk generally follows the GNOME release schedule. [5] A beta
(2.39.90) is expected in February. A release candidate (2.39.91)
around March 6, and the first stable release (2.40.0) around March 20.
We intend to do a test build in experimental first. I think it makes
the most sense to wait for the 2.40.0 release and not push a prelease
to Unstable/Testing.

Ubuntu 23.04 will also switch to the 2.40 series by February or early
March. Ubuntu 22.10 will need to do this transition as stable release
updates.

I don't have a ben file since the final soname isn't known yet.

[1]
https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#limited-security-support

[2] https://tracker.debian.org/pkg/webkit2gtk

[3] 
https://discourse.gnome.org/t/webkitgtk-for-gtk-4-status-update-and-api-changes/11033

[4] https://release.debian.org/transitions/html/webkit2gtk-4.0.html

[5] https://wiki.gnome.org/FortyFour

Thank you,
Jeremy Bicha

Bug#1029196: kylin-video: Has hard dependency on libmpv1 which doesn't exist

[Jeremy Bicha]

Source: kylin-video
Severity: serious
Version: 3.1.3-4
X-Debbugs-CC: jianfen...@ubuntukylin.com

kylin-video is unable to migrate to Testing because it has Depends:
libmpv1 in debian/control.

libmpv1 is no longer built in Debian Testing; the new version is libmpv2.

Please remove that line. It will automatically get a dependency on
libmpv2 when it builds against libmpv-dev.

Thank you,
Jeremy Bicha

Bug#1029167: mozjs78: Fails to build on armhf and armel

[Jeremy Bicha]

On Wed, Jan 18, 2023 at 2:08 PM Joshua Peisach
 wrote:
> CJS ported to mozjs78 in October 2020, and Cinnamon is still finishing their 
> 5.6x releases/making cleanups.
>
> Considering upstream uses Ubuntu Jammy, mozjs102 isn’t an option unless they 
> are willing to build it for their main development target. I think Cjs should 
> rebase for mozjs91,
> Especially if mozjs78 is EOL.

Cinnamon upstream is more than welcome to add a backported mozjs* to
the list of custom packages they provide. The absence of the latest
mozjs on Debian Stable or Ubuntu LTS does not need to be a blocker at
all.

But I have news: Ubuntu 22.04 LTS now has mozjs102 in jammy-proposed.
The intent is to release this as a security update there soon. See
https://launchpad.net/bugs/1993214 for more details.

If that works well, we may continue to backport new major mozjs
releases in the future for Ubuntu LTS. Perhaps for Debian 12 too.

Thank you,
Jeremy Bicha

Bug#1029167: mozjs78: Fails to build on armhf and armel

[Jeremy Bicha]

Source: mozjs78
Version: 78.15.0-6
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-...@lists.debian.org, c...@packages.debian.org
User: debian-...@lists.debian.org
Usertags: armel armhf

mozjs78 fails to build on armhf & armel.

I have little interest in working on this bug myself. I only stumbled
across this bug because I applied a build fix needed by Debian's
switch to Python 3.11. mozjs78 has been End of Life since October 2021
and is only still in Debian because Cinnamon hasn't switched to
mozjs102 yet.

By the way, 0ad has an embedded copy of mozjs78 and still builds on
armhf so maybe it includes a fix or a workaround for this build
failure.

I'm pasting the end of the build log below, but the actual build error
may have been earlier in the log.

/usr/bin/arm-linux-gnueabihf-g++ -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2
-fstack-protector-strong -Wdate-time -D_FORTIFY_SOURCE=2 -Wall
-Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith
-Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings
-Wno-invalid-offsetof -Wc++2a-compat -Wduplicated-cond
-Wimplicit-fallthrough -Wunused-function -Wunused-variable
-Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations
-Wno-error=array-bounds -Wno-error=coverage-mismatch
-Wno-error=free-nonheap-object -Wno-multistatement-macros
-Wno-error=class-memaccess -Wno-error=deprecated-copy -Wformat
-Wformat-overflow=2 -Wno-noexcept-type -fno-sized-deallocation
-fno-aligned-new -g -O2 -ffile-prefix-map=/<>=.
-fstack-protector-strong -Wformat -Werror=format-security -fno-rtti
-ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno
-pthread -pipe -g -freorder-blocks -O3 -fomit-frame-pointer
-funwind-tables  -fPIC -shared -Wl,-z,defs -Wl,--gc-sections
-Wl,-h,libmozjs-78.so -o libmozjs-78.so
/<>/debian/build/js/src/build/libmozjs-78_so.list
-lpthread -Wl,-z,relro -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro
-Wl,-z,nocopyreloc -Wl,-Bsymbolic-functions -Wl,--build-id=sha1
-fstack-protector-strong
-Wl,-rpath-link,/<>/debian/build/dist/bin
-Wl,-rpath-link,/usr/lib
/<>/debian/build/armv7-unknown-linux-gnueabihf/release/libjsrust.a
 -Wl,--version-script,symverscript -Wl,-soname,libmozjs-78.so.0  -lm
-lz -lm -ldl
/usr/bin/ld: 
/<>/debian/build/js/src/build/../../../config/external/icu/common/rbbi.o:
in function `std::type_info::operator!=(std::type_info const&) const':
/usr/include/c++/12/typeinfo:115: undefined reference to
`std::type_info::operator==(std::type_info const&) const'
/usr/bin/ld: 
/<>/debian/build/js/src/build/../../../config/external/icu/common/schriter.o:
in function `std::type_info::operator!=(std::type_info const&) const':
/usr/include/c++/12/typeinfo:115: undefined reference to
`std::type_info::operator==(std::type_info const&) const'
/usr/bin/ld: 
/<>/debian/build/js/src/build/../../../config/external/icu/common/stringtriebuilder.o:
in function 
`icu_67::StringTrieBuilder::Node::operator==(icu_67::StringTrieBuilder::Node
const&) const':
./debian/build/config/external/icu/common/./intl/icu/source/common/stringtriebuilder.cpp:388:
undefined reference to `std::type_info::operator==(std::type_info
const&) const'
/usr/bin/ld: 
./debian/build/config/external/icu/common/./intl/icu/source/common/stringtriebuilder.cpp:388:
undefined reference to `std::type_info::operator==(std::type_info
const&) const'
/usr/bin/ld: 
./debian/build/config/external/icu/common/./intl/icu/source/common/stringtriebuilder.cpp:388:
undefined reference to `std::type_info::operator==(std::type_info
const&) const'
/usr/bin/ld: 
/<>/debian/build/js/src/build/../../../config/external/icu/common/stringtriebuilder.o:./debian/build/config/external/icu/common/./intl/icu/source/common/stringtriebuilder.cpp:388:
more undefined references to
`std::type_info::operator==(std::type_info const&) const' follow
collect2: error: ld returned 1 exit status
make[4]: *** [/<>/config/rules.mk:608: libmozjs-78.so] Error 1
make[4]: Leaving directory '/<>/debian/build/js/src/build'
make[3]: *** [/<>/config/recurse.mk:74:
js/src/build/target] Error 2
make[3]: Leaving directory '/<>/debian/build'
make[2]: *** [/<>/config/recurse.mk:34: compile] Error 2
make[2]: Leaving directory '/<>/debian/build'
make[1]: *** [/<>/config/rules.mk:392: default] Error 2
make[1]: Leaving directory '/<>/debian/build'
dh_auto_build: error: cd debian/build && make -j8 returned exit code 2


Thank you,
Jeremy Bicha

Bug#1019865: evolution Hangs and goes to 100% CPU usage on compose

[Jeremy Bicha]

On Sun, Dec 11, 2022 at 9:29 AM Jeremy Bicha  wrote:
> Could y'all verify whether you still have this issue?
>
> Please upgrade to Evolution 3.46.2 which just landed in Testing today.
> Please log out and log back in to make sure you're running the latest
> version of evolution-data-server also.

Could anyone affected by this issue please verify whether the issue
still happens with 3.46.2 or 3.46.3?

Also, if you're running Unstable or Testing, you may get faster
results by reporting issues upstream:

https://gitlab.gnome.org/GNOME/evolution/-/issues

Thank you,
Jeremy Bicha

Bug#1028628: rust-lsd: ftbfs, build-depends on librust-lscolors-0.12+default-dev

[Jeremy Bicha]

Source: rust-lsd
Version: 0.23.1-1
Severity: serious
Tags: ftbfs

rust-lsd fails to build from source because it Build-Depends on
librust-lscolors-0.12+default-dev but the current version of
rust-lscolors in Debian is 0.13

Thank you,
Jeremy Bicha

Bug#1027529: gnote: FTBFS: ../src/test/unit/datetimeutests.cpp:97:1: error: Failure in pretty_print_date: Expected Yesterday but was Dec 31 2022

[Jeremy Bicha]

On Fri, Jan 13, 2023 at 9:58 AM Santiago Vila  wrote:
> El 13/1/23 a las 15:36, Jeremy Bicha escribió:
> > Control: severity -1 minor
> > Control: forwarded -1 https://gitlab.gnome.org/GNOME/gnote/-/issues/145
> >
> > I'm downgrading the severity since the package builds fine today;
> > might build fine every day except January 1.
>
> Why don't you disable the test instead? It's clearly wrong.
>
> If we start allowing packages to FTBFS one day a year,
> building the 34231 source packages in bookworm
> might result in 93 completely gratuitous failures.
>
> I don't think that's the standard of quality we want for bookworm.

The test failure might be showing an actual behavior bug. I reported
the issue upstream so they can figure out whether the app needs to be
fixed or the test needs to be fixed.

The test failure on January 1 is a minor issue since that day is a
global holiday. It's rare to build or rebuild this package on that
day: this FTBFS bug may have existed for more than 8 years.

Thank you,
Jeremy Bicha

Bug#1027529: gnote: FTBFS: ../src/test/unit/datetimeutests.cpp:97:1: error: Failure in pretty_print_date: Expected Yesterday but was Dec 31 2022

[Jeremy Bicha]

Control: severity -1 minor
Control: forwarded -1 https://gitlab.gnome.org/GNOME/gnote/-/issues/145

I'm downgrading the severity since the package builds fine today;
might build fine every day except January 1.

Thank you,
Jeremy Bicha

Bug#1028568: nautilus: no longer able to move files/directories between open tabs

[Jeremy Bicha]

On Thu, Jan 12, 2023 at 6:09 PM Sandro Tosi  wrote:
> Version: 43.1-1
> Severity: normal
> X-Debbugs-Cc: mo...@debian.org
>
> Hello,
> i have a Nautilus/Files window open with 3 tabs in it (3 subdirs of the same

Could you try again with nautilus 43.2 which was just uploaded to Unstable?

Thank you,
Jeremy Bicha

Bug#1028502: cpdb-libs: Missing Breaks/Replaces for file move

[Jeremy Bicha]

Patch attached.

Thank you,
Jeremy Bicha
From 868befddf686c24780207c9e3b7ae2744a570da7 Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Wed, 11 Jan 2023 19:35:36 -0500
Subject: [PATCH] Add Breaks/Replaces for file moved compared to older Ubuntu
 package

Closes: #1028502
---
 debian/control | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/control b/debian/control
index 52942ba..c19834d 100644
--- a/debian/control
+++ b/debian/control
@@ -149,6 +149,9 @@ Package: libcpdb-libs-tools
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends},
  libcpdb-libs-common1 (= ${binary:Version})
+# The Breaks/Replaces can be dropped after Ubuntu 24.04 LTS (April 2024)
+Breaks: libcpdb-libs-common-dev (<< 1.2.0-1~)
+Replaces: libcpdb-libs-common-dev (<< 1.2.0-1~)
 Description: Common Print Dialog Backends - tools
  The Common Print Dialog Backends project provides a D-Bus interface
  so that the print dialogs of GUI applications and the communication

Bug#1028502: cpdb-libs: Missing Breaks/Replaces for file move

[Jeremy Bicha]

Source: cpdb-libs
Version: 1.2.0-1
Severity: important
Tags: patch
X-Debbugs-CC: deb...@alteholz.de

The Debian packaging for cpdb-libs was based on the Ubuntu packaging.
One change was that usr/bin/print_frontend was moved to a separate
binary package. Breaks/Replaces are required for that move to avoid
upgrade problems in Ubuntu. I'm attaching a patch in my followup
email.

Thank you,
Jeremy Bicha

Bug#1028500: cpdb-libs: missing VCS

[Jeremy Bicha]

Source: cpdb-libs
Version: 1.2.0-1
X-Debbugs-CC: deb...@alteholz.de

There is no public repo at the location listed in the Vcs fields in
the packaging for cpdb-libs or cpdb-backend-cups.

Thank you,
Jeremy Bicha

Bug#1026093: RFS: dia/0.97.3+git20220525-5 -- Diagram editor

[Jeremy Bicha]

On Wed, Jan 11, 2023 at 4:54 PM Jeremy Bicha  wrote:
> I uploaded this for you after making my one suggested change to bump
> the urgency to high.

Actually, I was too slow and someone else uploaded first!

Thank you,
Jeremy Bicha

Bug#1026093: RFS: dia/0.97.3+git20220525-5 -- Diagram editor

[Jeremy Bicha]

I uploaded this for you after making my one suggested change to bump
the urgency to high.

The Debian bug tracker didn't automatically send your email to me. I
would have needed to explicitly subscribe to email updates. Therefore,
I suggest explicitly CCing people when replying to Debian bugs unless
they are the package maintainer.

Thank you,
Jeremy Bicha

Bug#1026093: Patch for Poppler/dia applied

[Jeremy Bicha]

I received approval from the Release Team to start the poppler
transition now and have uploaded poppler 22.12 to Unstable.

Could you do the dia upload now? I suggest using urgency=high because
we are nearly at the transition deadline.

Thank you,
Jeremy Bicha

Bug#1028364: dh-python: X-Python3-Version: doesn't work for versions >= 3.10

[Jeremy Bicha]

Source: dh-python
Version: 5.20221230
Severity: important

Test Case
--
Add this to debian/control (and debian/control.in) for gi-docgen:
X-Python3-Version: >= 3.11

Justification is that gi-docgen 2023.1 can use Python 3.11's new
standard library tomllib instead of a separately packaged
implementation.

What Happens

The package ends up with this:
Depends: python3:any (>= 3.1~)

What I Expected
--
The dependency version should be >= 3.11~

Other Info
-
It works correctly for 3.9.

I tried using 3.11.0 but it didn't change the result and I got a
Lintian error for doing that.

If I drop the >= and use X-Python3-Version: 3.11
Depends: python3.11, python3:any


Thank you,
Jeremy Bicha

Bug#1027942: transition: poppler 22.12

[Jeremy Bicha]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: popp...@packages.debain.org
Control: block -1 by 1026040
Control: block -1 by 1026093

Poppler is now on a monthly release cycle. I request that we use
poppler 22.12 for Debian 12 instead of poppler 22.08 from August.
(This week, there was also a 23.01 release, but it's impractical for
that update to be included in Debian 12.) I apologize for the late
request.

This transition is mostly done in Ubuntu, but completion is blocked
there by the Qt transition and some other transitions.

This transition will need a sourceful upload for dia and for
ipe-tools. ipe-tools is fixed in Experimental. I can do NMUs for these
2 packages.

inkscape fails to build on some architectures but that's not caused by
the new poppler and the build failures didn't block the poppler 22.08
transition several months ago. Everything else should be binNMUable
without an issue.

This tracker is good:
https://release.debian.org/transitions/html/auto-poppler.html

Thank you,
Jeremy Bicha

Bug#922456: Bug#929997: Intent to NMU gnome-menus to fix longstanding l10n bugs

[Jeremy Bicha]

On Wed, Jan 4, 2023 at 3:57 AM Helge Kreutzmann  wrote:
>* Update Debian translation
>  - French translation.
>Thanks Quentin Lejard (Closes: #922456)
>  - German translation.
>Thanks Helge Kreutzmann (Closes: #929997)
>
> Please tell me if you are currently preparing a new release yourself
> and would like me to skip the NMU.

Please include the most recent change from
https://salsa.debian.org/gnome-team/gnome-menus/-/commits/debian/master
to update debian/watch if you do an NMU. If you do that, you are
welcome to do the NMU when you are ready.

Alternatively, you can submit a Salsa merge proposal and we can do a
maintainer upload.

It would be nice if someone could work with GNOME to get these
translation improvements pushed to GNOME's master branch so that
future new releases include these fixes for all distros and there
isn't a risk of trying to figure out how to rebase the patches.

Thank you,
Jeremy Bicha

Bug#1027295: test-network-panel times out on riscv64

[Jeremy Bicha]

On Thu, Dec 29, 2022, 14:21 Gunnar Hjalmarsson  wrote:

> Package: src:gnome-control-center
> Version: 1:43.2-1
> Severity: important
> Tags: ftbfs
> X-Debbugs-CC: gunna...@debian.org
>
> g-c-c 1:43.2-1 fails to build on riscv64:
>
>
> https://buildd.debian.org/status/logs.php?pkg=gnome-control-center=riscv64
>
> It's some kind of test timeout for test-network-panel.
>
> While this is not an RC bug — riscv64 is not an official arch in Debian
> — it's a regression from g-c-c 1:43.1-2, so it may be worth looking at
> if we want to keep g-c-c available on riscv64. (FWIW it builds on
> riscv64 in Ubuntu.)
>

Ubuntu doesn't run dh_auto_test for riscv64.

Jeremy

Bug#1026167: balsa: Balsa truncates the mail title

[Jeremy Bicha]

On Thu, Dec 15, 2022 at 12:15 PM Nicolas Patrois
 wrote:
> Package: balsa
> Version: 2.6.4-1
> Severity: minor
> Tags: upstream
>
> Dear Maintainer,
>
> Since the last upgrade, Balsa truncates the mail titles’ display.
> Yes, only their display: I checked with the mail command line tool.

Please report this issue to
https://gitlab.gnome.org/GNOME/balsa/-/issues

Thanks,
Jeremy Bicha

Bug#1026032: bump severity of poppler build-depends

[Jeremy Bicha]

Control: severity -1 important

We would like to finish the poppler 22.12 transition before the Debian
Transition Freeze in one month. Therefore, I'm bumping the severity of
this bug.

Thank you,
Jeremy Bicha

Bug#1025268: Should mozjs102 in bookworm use the system icu?

[Jeremy Bicha]

On Thu, Dec 1, 2022 at 1:42 PM Adrian Bunk  wrote:
> The system icu 72 is no longer older than the icu 71 vendored
> in mozjs102, should mozjs102 in bookworm use the system icu?

It's possible for a newer mozjs to be backported to Debian 12, later
in Debian 12's life. In this case, it might be simpler for everyone if
mozjs was using the vendored ICU.

By the way, I am working on backporting mozjs102 to Ubuntu 22.04 LTS
now: https://launchpad.net/bugs/1993214

Thank you,
Jeremy Bicha

Bug#1026039: lyx: LyX is listed as proprietary software in Gnome-software

[Jeremy Bicha]

On Tue, Dec 13, 2022 at 4:19 PM Pavel Sanda  wrote:
>
> On Tue, 13 Dec 2022 17:50:03 +0100 Lorenzo Bertini 
>  wrote:
> > LyX is listed on my system as proprietary software in gnome-software. 
> > Looking online I found several people having this issue with other 
> > programs, and the cause was always that the license couldn't be read by 
> > gnome-software properly.
> >
> > Please ensure that gnome-software can properly read the license. If the bug 
> > is not on our end, let me know and I will contact gnome-software developers.
>
> Well, LyX installs it's licences where it should, i.e. into
> /usr/share/doc/lyx/copyright.
> If there is something specific WRT gnome, we can do it but we need
> gnome maintainers input... I don't use gnome personally so can't
> even test it.
>
> I CC maintainer of gnome-software if he has some hints for us.

The GNOME Software app prefers to use AppStream metadata.

https://wiki.debian.org/AppStream/Guidelines
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html

Thank you,
Jeremy Bicha

Bug#1012428: gnome-shell-common: drmModeAddFB2WithModifiers Failed

[Jeremy Bicha]

Many things have changed in Debian in the past 6 months. Are you still
experiencing this issue?

Thank you,
Jeremy Bicha

On Mon, Jun 6, 2022 at 7:39 PM Tim McConnell  wrote:
> Package: gnome-shell-common
> Version: 42.1-1
> Severity: grave
> Justification: renders package unusable
> X-Debbugs-Cc: tmcconnell...@gmail.com
>
> Dear Maintainer,
>
> What led up to the situation? Do not know, my logs are getting multiple 
> reports
> of this error(?)
>
> What exactly did you do (or not do) that was effective (or
>  ineffective)? Unknown
>
> What was the outcome of this action?
> 11433 lines of:
> gnome-shell[4883]: Failed to scan out client buffer: 
> drmModeAddFB2WithModifiers
> failed: Invalid argument
>
> What outcome did you expect instead?
> Not getting all of those errors in one hour
>
>
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386

Bug#996780: gnome-boxes: Systematic system freeze few seconds after launching a Windows WM

[Jeremy Bicha]

It has been a year since the last comment and many things have changed
in Debian in that time. Are you still experiencing this issue?

Thank you,
Jeremy Bicha

Bug#1019865: evolution Hangs and goes to 100% CPU usage on compose

[Jeremy Bicha]

Could y'all verify whether you still have this issue?

Please upgrade to Evolution 3.46.2 which just landed in Testing today.
Please log out and log back in to make sure you're running the latest
version of evolution-data-server also.

Thank you,
Jeremy Bicha

Bug#1016881: Please update chrome-gnome-shell to version 42

[Jeremy Bicha]

Control: tags -1 +pending

On Mon, Aug 8, 2022 at 4:48 PM Amr Ibrahim  wrote:
> Upstream has renamed chrome-gnome-shell into gnome-browser-connector,
> and released version 42. Please follow the new upstream source.
>
> GNOME Shell browser integration homepage
> https://wiki.gnome.org/Projects/GnomeShellIntegration
>
> gnome-browser-connector source
> https://gitlab.gnome.org/nE0sIghT/gnome-browser-connector

This is now in the NEW queue.

> A question: is there a reason why gnome-browser-extension is not
> packaged in Debian, and has to be installed from Firefox Add-ons?
>
> gnome-browser-extension source
> https://gitlab.gnome.org/GNOME/gnome-browser-extension

It's a separate source package so someone that cares about it would
need to package it.

Personally, I use the Firefox snap (and the Chromium snap) so I won't
be packaging it.

Thank you,
Jeremy Bicha

Bug#642906: RFH: balsa -- An e-mail client for GNOME

[Jeremy Bicha]

Daniel,

Do you still use balsa? If so, do you think we can close this RFH bug?

The biggest thing we were missing was someone who uses the app to
confirm it's still working and able to make occasional fixes (which
you can since you're a team maintainer for it).

Thank you,
Jeremy Bicha

Bug#1025729: evolution-data-server: Gmail OAuth2: "Access blocked: GNOME Evolution’s request is invalid"

[Jeremy Bicha]

On Thu, Dec 8, 2022 at 9:11 PM Full Name  wrote:
> To reproduce for an existing account that hasn't yet been blocked, I
> think revoking Evolution from third party app access should do the
> trick:
>
> 1. Login to google
> 2. Go to https://myaccount.google.com/permissions?pli=1
> 3. Under GNOME Evolution, Remove Access
> 4. Attempt to login using Evolution

Instead of using Evolution to log in, use GNOME Online Accounts.

Open the GNOME Settings app.
In the sidebar, click Online Accounts
Click Add an account > Google
Log in here.
After you log in, open Evolution.

Thank you,
Jeremy Bicha

Bug#971420: jhbuild: please make the build reproducible

[Jeremy Bicha]

On Thu, Dec 8, 2022 at 5:36 PM Vagrant Cascadian
 wrote:
> Control: tags 971420 pending
>
> On 2020-09-30, Chris Lamb wrote:
> > Whilst working on the Reproducible Builds effort [0] we noticed that
> > jhbuild could not be built reproducibly.
> >
> > This is because the /usr/bin/jhbuild binary embedded the absolute
> > build to get it's "source" directory. A patch is attached that imports
> > the jhbuild module and determines this location programmatically
> > instead.
>
> Uploaded an NMU to DELAYED/10 fixing this issue:

Feel free to upload now without delay.

Thank you,
Jeremy Bicha

Bug#1025773: bullseye-pu: package evolution-data-server/3.38.3-1+deb11u1

[Jeremy Bicha]

On Thu, Dec 8, 2022 at 4:04 PM Adam D. Barratt  wrote:
>
> Control: tags -1 + confirmed
>
> On Thu, 2022-12-08 at 15:45 -0500, Jeremy Bicha wrote:
> > Adapt to Google Contacts API change
> >
> > [ Impact ]
> > Google Contacts integration in Evolution and the GNOME Contacts app
> > won't work without this fix.
> >
>
> Please go ahead.

I made a typo in the changelog which means the bug number won't be
closed automatically.
It says:  Closes #9978240  but it should be  Closes: #997824)

How should we handle this?

Thank you,
Jeremy Bicha

Bug#1025774: bullseye-pu: package evolution/3.38.3-1+deb11u1

[Jeremy Bicha]

On Thu, Dec 8, 2022 at 4:02 PM Adam D. Barratt  wrote:
>
> On Thu, 2022-12-08 at 15:49 -0500, Jeremy Bicha wrote:
> > Adapt to Google Contacts API change
> >
> > [ Impact ]
> > Google Contacts integration in Evolution won't work without this fix.
>
> +evolution (3.38.3-1+deb11u1) unstable; urgency=medium
>
> ^ s/unstable/bullseye/
>
> > This bug fix requires evolution-data-server to be updated too. See
> > https://bugs.debian.org/1025773
> >
>
> Do the package relationships ensure that the new versions are always
> installed together? If not, what's the user experience if there's a
> mismatch?

If someone managed to install the new evolution and old
evolution-data-server or the other way around, they would get the same
behavior as currently in Debian 11: Google Contacts integration won't
work.

I could have evolution have a bumped Depends on the new
evolution-data-server. To fix it the other way, we could add a Breaks.
I don't know if adding either of those really helps much.

I already uploaded both evolution and evolution-data-server to the
bullseye-pu queue. If we did end up wanting to change this, would it
be best to upload with a bumped version number (3.38.3-1+deb11u2) or
just have the old ones rejected?

Thank you,
Jeremy Bicha

Bug#1025774: bullseye-pu: package evolution/3.38.3-1+deb11u1

[Jeremy Bicha]

Updated debdiff attached to fix typo in the Debian series field of
debian/changelog.

Thank you,
Jeremy Bicha


evolution_3.38.3-1+deb11u1.debdiff
Description: Binary data

Bug#1025774: bullseye-pu: package evolution/3.38.3-1+deb11u1

[Jeremy Bicha]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: bullseye
X-Debbugs-CC:evolut...@packages.debian.org

[ Reason ]
Adapt to Google Contacts API change

[ Impact ]
Google Contacts integration in Evolution won't work without this fix.

[ Tests ]
I manually tested this fix and the corresponding evolution-data-server
fix on Debian 11 to ensure that the fix fixes the bug.

This fix was delayed several months because the original attempts to
fix this bug were missing one of the necessary patches. This was
noticed because the manual test failed to demonstrate that the bug was
fixed.

[ Risks ]
The required patch was cherry-picked from a newer evolution series.
The upstream evolution project no longer maintains the 3.38.x branch
that Debian 11 uses.

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

[ Changes ]
1 patch cherry-picked from a newer evolution series

[ Other info ]
This bug fix requires evolution-data-server to be updated too. See
https://bugs.debian.org/1025773

Thank you,
Jeremy Bicha


evolution_3.38.3-1+deb11u1.debdiff
Description: Binary data

Bug#1025729: evolution-data-server: Gmail OAuth2: "Access blocked: GNOME Evolution’s request is invalid"

[Jeremy Bicha]

On Wed, Dec 7, 2022 at 10:48 PM James Taylor  wrote:
> Package: evolution-data-server
> Version: 3.30.5-1+deb10u2
> Severity: important
>
> Dear Maintainer,
>
> Google deprecated a type of OAuth flow in Feb 28, 2022. This was fixed and 
> addressed upstream
> shortly after at 
> https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/388 and
> the fix was included in version 3.44.2. However, Google has recently begun 
> blocking
> the old format. My Oauth2 token expired December 7th, 2022 so I can no longer 
> access
> my gmail account from evolution. A suitably recent version is available in 
> Testing.

Debian 10 has reached end of life for standard support. Please upgrade
to Debian 11.

I was able to successfully log into a Google account today using
Debian 11 using GNOME Settings > Online Accounts.

Could you provide detailed steps for how to reproduce this bug from a
clean Debian 11 install?

Thank you,
Jeremy Bicha

Bug#1025768: transition: snapd-glib 1.63

[Jeremy Bicha]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: snapd-g...@packages.debian.org

I am ready to do the snapd-glib transition now. You can use the auto tracker:
https://release.debian.org/transitions/html/auto-snapd-glib.html

I need to do source uploads for gnome-control-center and
gnome-software for the transition but I am a team maintainer for
those. The other 2 packages can be binNMU'd.

Ubuntu completed this transition months ago and I verified today that
the 4 affected packages build successfully against the new library.

Thank you,
Jeremy Bicha

Bug#1025762: gnome-session: Install and enable appindicator and desktop icons NG extensions

[Jeremy Bicha]

Here are merge proposals:

https://salsa.debian.org/gnome-team/gnome-shell/-/merge_requests/67
https://salsa.debian.org/gnome-team/gnome-session/-/merge_requests/11

And there's more explanation at https://bugs.debian.org/1025762

I'd like to land this soon so that it's included in Debian 12 and I'd
appreciate review first.

Thank you,
Jeremy Bicha

Bug#1025762: gnome-session: Install and enable appindicator and desktop icons NG extensions

[Jeremy Bicha]

Source: gnome-session
Version: 43.0-1

I propose that Debian enable 2 GNOME Shell extensions by default:
- gnome-shell-extension-appindicator
- gnome-shell-extension-desktop-icons-ng

Justification

Both those extensions fill gaps in our default desktop. For people
that use desktop icons or app status icons, these extensions are very
useful. For people that don't, the extensions can be basically
ignored.

Ubuntu includes these 2 extensions by default plus a variation of Dash to Dock.

Google has an internal distro for their developers that enables Dash
to Panel and appindicators. As of a few months ago, they were
considering adding Desktop Icons NG also.

I am expecting GNOME Classic, as early as GNOME 44, to re-enable
desktop icons by default and the Desktop Icons NG extension to be
moved upstream to the gnome-shell-extensions project.

There has been discussion about GNOME eventually enabling some sort of
app status icon feature by default, but work on the spec and
implementation appears stalled.

I think a discussion of adding Dash to Dock or Dash to Panel by
default should be discussed in a separate bug.

Implementation
-
I suggest that we adapt similar work done by Ubuntu to add a GNOME
Shell mode and corresponding gnome-session files.

A GNOME Shell mode allows enabling specific extensions by default and
also allows enabling a few other customizations. GNOME itself uses a
GNOME Shell mode for GNOME Classic and the GNOME Initial Setup new
user mode. Ubuntu and Pop!_OS use GNOME Shell modes too.

The session identifies itself with the environment variable
XDG_CURRENT_DESKTOP=debian:GNOME

gsettings overrides can be set for just this debian session or for
GNOME sessions in general. For an example, see
https://git.launchpad.net/~ubuntu-desktop/ubuntu/+source/ubuntu-settings/tree/debian/ubuntu-settings.gsettings-override#n67

If anyone prefers the upstream experience, they can install the binary
package 'gnome-session' which I'm proposing we no longer install by
default.

This will need changes to our packaging for gnome-shell and
gnome-session. Later, we'll also need to patch gdm3 to prefer the new
Debian session instead of GNOME.

Thank you,
Jeremy Bicha

Bug#1022404: raqm: diff for NMU version 0.7.0-4.1

[Jeremy Bicha]

Also, I suggest bumping harbuzz in Build-Depends. I don't know the
exact version needed, setting it to 5.2 is probably ok.

Thank you,
Jeremy Bicha

Bug#1022404: raqm: diff for NMU version 0.7.0-4.1

[Jeremy Bicha]

On Thu, Dec 1, 2022 at 2:21 PM Adrian Bunk  wrote:
> On Fri, Nov 25, 2022 at 05:16:03AM -0600, Jeremy Bicha wrote:
> > Do you think it would be useful to include Ubuntu's change in your NMU
> > to add an autopkgtest so that these build failures are detected sooner
> > next time? It would have blocked the new harfbuzz from migrating to
> > Testing.
>
> Sounds reasonable to me, but let's give the maintainer a chance to
> agree or disagree to that.

Adrian, did you cancel your NMU?

I believe Ahmed El-Mahmoudy hasn't been active in Debian for a while.

> > https://patches.ubuntu.com/r/raqm/raqm_0.7.0-4ubuntu1.patch
>
>   Depends: @, @builddeps@
> would be better than the duplication in Ubuntu's change.

Yes, that's a good idea.

Thank you,
Jeremy Bicha

Bug#1022404: raqm: diff for NMU version 0.7.0-4.1

[Jeremy Bicha]

Adrian,

Do you think it would be useful to include Ubuntu's change in your NMU
to add an autopkgtest so that these build failures are detected sooner
next time? It would have blocked the new harfbuzz from migrating to
Testing.

https://patches.ubuntu.com/r/raqm/raqm_0.7.0-4ubuntu1.patch

Thank you,
Jeremy Bicha

Bug#1024674: libphonenumber8: breaks Evolution

[Jeremy Bicha]

On Wed, Nov 23, 2022 at 5:15 PM László Böszörményi (GCS)  
wrote:
> On Wed, Nov 23, 2022 at 6:52 AM tony mancill  wrote:
> > This issue goes away for me after a rebuild of src:evolution-data-server
> > and installing the freshly rebuilt libebook-contacts-1.2-4.
> >
> > Maybe we can kick off a rebuild via the transition.  If not that, would
> > you be willing to do a sourceful upload Jeremy?
>  Just for the record, he asked for a evolution-data-server binNMU [1]
> for this issue. No sourceful upload will be needed.

Will the evolution-data-server binNMU be held in Unstable until
libphonenumber and protobuf migrate to Testing?

I don't want to have Testing broken because of this issue either.

Thank you,
Jeremy Bicha

Bug#1024726: nmu: evolution-data-server_3.46.1-1+b1

[Jeremy Bicha]

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

Please schedule this rebuild to fix evolution-data-server
compatibility with libphonenumber which was rebuilt for the ongoing
protobuf transition. This rebuild wasn't on the auto tracker which
suggests that there is a bigger dependency issue somewhere. I don't
know if other packages are also affected. See
https://bugs.debian.org/1024674

Here's my guess at the syntax:

nmu evolution-data-server_3.46.1-1+b1 . ANY . unstable . -m
"libphonenumber8 (>= 8.12.57+ds-1+b2)"

Thanks,
Jeremy Bicha

Bug#1024532: gjs allocates 237 GB of RAM during build (!)

[Jeremy Bicha]

On Mon, Nov 21, 2022 at 7:54 AM Santiago Vila  wrote:
> El 21/11/22 a las 11:20, Simon McVittie escribió:
> > I think you might accidentally be measuring how much it *can* allocate
> > if given the opportunity, as opposed to how much it strictly *needs*
> > to allocate?
>
> Not exactly. As explained, I am intentionally measuring the allocated
> memory as a completely safe upper bound for the required memory, and I
> am aware that they are not the same. Nevertheless, I try to report
> anomalies like this one when I find them.

Another example is webkitgtk. It uses overcommit as a security feature
codenamed Gigacage. The webkitgtk maintainers would close this kind of
bug as NOTABUG. Perhaps, gjs is doing something similar.

https://blogs.gnome.org/mcatanzaro/2018/11/02/on-webkit-build-options-also-how-to-accidentally-disable-important-security-features/

Thank you,
Jeremy Bicha

Bug#1024388: libtepl-6-1: missing (unversioned) Breaks+Replaces: libtepl-6-0

[Jeremy Bicha]

Control: severity -1 important

On Fri, Nov 18, 2022 at 12:51 PM Andreas Beckmann  wrote:
> Package: libtepl-6-1
> Version: 6.2.0-2
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> during a test with piuparts I noticed your package fails to upgrade from
> 'testing'.
> It installed fine in 'testing', then the upgrade to 'sid' fails
> because it tries to overwrite other packages files without declaring a
> Breaks+Replaces relation.
>
> See policy 7.6 at
> https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces
>
> From the attached log (scroll to the bottom...):
>
>   Preparing to unpack .../libtepl-6-1_6.2.0-2_amd64.deb ...
>   Unpacking libtepl-6-1:amd64 (6.2.0-2) ...
>   dpkg: error processing archive 
> /var/cache/apt/archives/libtepl-6-1_6.2.0-2_amd64.deb (--unpack):
>trying to overwrite '/usr/share/locale/ca/LC_MESSAGES/tepl-6.mo', which is 
> also in package libtepl-6-0:amd64 6.1.2-1+b2
>   Errors were encountered while processing:
>/var/cache/apt/archives/libtepl-6-1_6.2.0-2_amd64.deb
>
>
> The *.mo files have the same name in both packages.

I am downgrading the severity because nothing in Debian used libtepl-6-0

Nevertheless, we still ought to split the translations to a separate
binary package so we didn't run into this issue again later.

Thanks,
Jeremy Bicha

Bug#1013146: Doesn't fail build on symbol changes

[Jeremy Bicha]

Would you be willing to accept this merge proposal?

https://salsa.debian.org/debian-gis-team/lerc/-/merge_requests/1

During Ubuntu's Main Inclusion review, it was requested that the build
should fail on Ubuntu if symbols disappear.

Thank you,
Jeremy Bicha

Bug#1017958: tiff: Don't build with LERC on i386

[Jeremy Bicha]

On Sun, Aug 28, 2022 at 3:39 AM László Böszörményi (GCS)  
wrote:
> On Tue, Aug 23, 2022 at 5:09 PM Jeremy Bicha  
> wrote:
> > Is having lerc compression support critical enough on i386 to justify
> > making extra work for Ubuntu? It already is not critical enough to be
> > enabled on some Debian release architectures.
>  Well, there were eleven tiff uploads this year (meaning one upload by
> 21 days on average) and two uploads in 2021. You already have a quite
> simple patch to apply. How much burden would that be on Ubuntu? Can I
> do the tiff uploads for Ubuntu as well? That would get some pressure
> out of you guys.

If you wanted to have direct upload rights to Ubuntu, you could apply
to be an Ubuntu Core Developer. Since you are a Debian Developer, I
believe the threshold for approval is lower but you need to be
familiar with Ubuntu's release schedule and Ubuntu's
proposed-migration, and a few other Ubuntu-specific practices.

https://wiki.ubuntu.com/UbuntuDevelopers#CoreDev
https://wiki.ubuntu.com/ProposedMigration
https://wiki.ubuntu.com/StableReleaseUpdates
https://discourse.ubuntu.com/t/lunar-lobster-release-schedule/27284

Manually merging Ubuntu's tiff package for every Debian upload is not
an overwhelming burden. In my opinion, the benefit of not having to do
that extra work outweighs the benefit of keeping LERC compression
around for i386, which is why I made this request.

Thank you,
Jeremy Bicha

Bug#1022955: Acknowledgement (gnome-network-displays: fails to find remote display)

[Jeremy Bicha]

The package description says that wpasupplicant is required; you can't use iwd.

Thank you,
Jeremy Bicha

Bug#972078: sound-juicer: diff for NMU version 3.38.0-2.1

[Jeremy Bicha]

Feel free to upload this without delay.

On behalf of the Debian GNOME team,
Jeremy Bicha

On Wed, Oct 26, 2022, 21:12 Philip Rinn  wrote:

> Control: tags 972078 + pending
>
>
> Dear maintainer,
>
> I've prepared an NMU for sound-juicer (versioned as 3.38.0-2.1) and
> uploaded it to DELAYED/14. Please feel free to tell me if I
> should delay it longer.
>
> (The change in Uploaders somehow happened automatically during the gbp
> buildpackage run, not sure why.)
>
> Best,
> Philip
>
>
> diff -Nru sound-juicer-3.38.0/debian/changelog
> sound-juicer-3.38.0/debian/changelog
> --- sound-juicer-3.38.0/debian/changelog2022-02-18
> 22:16:14.0 +0100
> +++ sound-juicer-3.38.0/debian/changelog2022-10-26
> 20:58:46.0 +0200
> @@ -1,3 +1,12 @@
> +sound-juicer (3.38.0-2.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Make build reproducible: Replace absolute path to source location of
> +data/rhythmbox.gep embedded in binary with relative path. It would
> never
> +resolve and is not necassary in an end-user installation (Closes:
> #972078)
> +
> + -- Philip Rinn   Wed, 26 Oct 2022 20:58:46 +0200
> +
>  sound-juicer (3.38.0-2) unstable; urgency=medium
>
>* Drop unneeded -Wl,--as-needed and -Wno-unused-parameter
> diff -Nru sound-juicer-3.38.0/debian/control
> sound-juicer-3.38.0/debian/control
> --- sound-juicer-3.38.0/debian/control  2022-02-18 22:16:14.0 +0100
> +++ sound-juicer-3.38.0/debian/control  2022-10-26 20:58:46.0 +0200
> @@ -6,7 +6,7 @@
>  Section: sound
>  Priority: optional
>  Maintainer: Debian GNOME Maintainers <
> pkg-gnome-maintain...@lists.alioth.debian.org>
> -Uploaders: Jeremy Bicha , Laurent Bigonville <
> bi...@debian.org>, Michael Biebl 
> +Uploaders: Laurent Bigonville , Michael Biebl <
> bi...@debian.org>
>  Build-Depends: debhelper-compat (= 13),
> appstream,
> appstream-util ,
> diff -Nru sound-juicer-3.38.0/debian/patches/reproducible-build.patch
> sound-juicer-3.38.0/debian/patches/reproducible-build.patch
> --- sound-juicer-3.38.0/debian/patches/reproducible-build.patch 1970-01-01
> 01:00:00.0 +0100
> +++ sound-juicer-3.38.0/debian/patches/reproducible-build.patch 2022-10-26
> 18:01:17.0 +0200
> @@ -0,0 +1,15 @@
> +Description: Make the build reproducible
> +Author: Chris Lamb 
> +Last-Update: 2020-10-12
> +
> +--- sound-juicer-3.38.0.orig/libjuicer/rb-gst-media-types.c
>  sound-juicer-3.38.0/libjuicer/rb-gst-media-types.c
> +@@ -34,7 +34,7 @@
> +
> + #include "rb-gst-media-types.h"
> +
> +-#define SOURCE_ENCODING_TARGET_FILE TOPSRCDIR"/data/rhythmbox.gep"
> ++#define SOURCE_ENCODING_TARGET_FILE "./data/rhythmbox.gep"
> + #define INSTALLED_ENCODING_TARGET_FILE
> DATADIR"/sound-juicer/rhythmbox.gep"
> + static GstEncodingTarget *default_target = NULL;
> +
> diff -Nru sound-juicer-3.38.0/debian/patches/series
> sound-juicer-3.38.0/debian/patches/series
> --- sound-juicer-3.38.0/debian/patches/series   2022-02-18
> 22:16:14.0 +0100
> +++ sound-juicer-3.38.0/debian/patches/series   2022-10-26
> 18:01:37.0 +0200
> @@ -2,3 +2,4 @@
>  Fix-showing-icon-in-the-about-dialog.patch
>  build-fix-doc-directory.patch
>  meson-drop-unused-argument-for-i18n.merge_file.patch
> +reproducible-build.patch
>
>

Bug#1022137:

[Jeremy Bicha]

On Mon, Oct 24, 2022 at 9:45 AM Archisman Panigrahi  wrote:
> Will the patch be backported to Debian Bookworm?

Yes, it will land in Bookworm automatically in a few days.

Thank you,
Jeremy Bicha

Bug#1021804: gnome-terminal: Wrong window name "Preferences" showing up in Gnome Dash and the application switcher (Alt-Tab) for running terminals

[Jeremy Bicha]

On Sat, Oct 15, 2022 at 12:03 AM Ronny Rentner
 wrote:
> when I run Gnome Terminal, it shows up under the name "Preferences" in Gnome
> Dash and in the application switcher. This also makes the application grouping
> fail in Gnome Dash.
>
> This seems to be caused by having 2 .desktop files:
> /usr/share/applications/org.gnome.Terminal.Preferences.desktop
> /usr/share/applications/org.gnome.Terminal.desktop
>
> After I have manually deleted the org.gnome.Terminal.Preferences.desktop file,
> the problem goes away.

It works for me. Please reinstall gnome-terminal. Then close all your
terminals and then try opening the terminal again.

Thank you,
Jeremy Bicha

Bug#1021588: Please apply the proposed fix (revert) for hi-dpi thumbnailing, until glib is properly fixed

[Jeremy Bicha]

Control: reassign -1 src:glib2.0 2.74.0-2
Control: affects -1 src:nautilus

We'll fix this in glib. My understanding is that the glib fix is
sufficient to not need to patch Nautilus.

Thank you,
Jeremy Bicha

Bug#940139: nautilus: open files by double clicking or right click "open"

[Jeremy Bicha]

Control: severity -1 normal
Control: tags -1 -moreinfo

Are you still experiencing this issue?

Could you make a new user, log in as the new user and verify whether
the new user is affected by this issue?

Thank you,
Jeremy Bicha

Bug#1021659: freerdp2: Update to 2.8.1

[Jeremy Bicha]

Source: freerdp2
Version: 2.8.0+dfsg1-1

Please update freerdp2 to the new version. Because I needed to work on
the update today for Ubuntu 22.10 deadlines, I am submitting merge
proposals for you.

https://github.com/FreeRDP/FreeRDP/releases/tag/2.8.1
https://github.com/FreeRDP/FreeRDP/compare/2.8.0...2.8.1

The changes say that it fixes 2 CVEs, CVE-2022-39282 and CVE-2022-39283

Thank you,
Jeremy Bicha

Bug#919914: gnome-tweaks now equates "don't suspend on lid close" with "don't lock on lid close" (security issue)

[Jeremy Bicha]

Control: severity -1 important

Let's downgrade.

Thank you,
Jeremy Bicha

On Tue, Oct 11, 2022 at 4:09 PM Paul Gevers  wrote:
>
> Hi all,
>
> I'm going to try and summarize what I believe is the situation of this bug.
>
> 1) There's a patch upstream for a long time already, however it's not
> merged.
> 2) The Debian maintainer is reluctant to apply the patch without
> upstream applying it *or* consensus in Debian that it's the right
> thing to do.
> 3) I don't believe consensus has been reached.
>
> As a result, without a call from authorities¹ this RC bug remains
> stalled. At this moment, as a member of the Release Team, I'll say that
> I'd like to see this bug resolved (patch applied, closed+wontfix or
> downgraded), but we'll not hold up the bookworm release if it's not.
>
> Paul
>
> ¹ the maintainers, the bug reporter or the Release Team

Bug#1021432: RM: gnome-passwordsafe -- RoM; renamed to secrets

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-Cc: gnome-passwords...@packages.debian.org
Affects: src:gnome-passwordsafe

gnome-passwordsafe has been renamed upstream to secrets. Therefore, we
have packaged the secrets source package and added a transitional
binary package to upgrade users to the new package name.

Therefore, please remove gnome-passwordsafe.

With permission from the gnome-passwordsafe Uploader,
Jeremy Bicha

Bug#1003658: geary: Search stops working after a while

[Jeremy Bicha]

On Wed, Oct 5, 2022 at 6:27 PM Andres Salomon  wrote:
>
> On Thu, 13 Jan 2022 12:04:45 +0100 Matthias Brennwald
>  wrote:
>  > Package: geary
>  > Version: 40.0-1
>  > Severity: normal
>  > Tags: patch
>  > X-Debbugs-Cc: mbren...@gmail.com
>  >
>  > Dear Maintainer
>  >
>  > The function to search for emails stops working after running Geary
> for a
>  > while. I can get it to work again either by rebooting the computer,
> or by doing
>  > "killall geary" and then restart Geary. Just restarting Geary alone
> does not
>  > help. I guess there is some background process related to the Geary
> search,
>  > which gets stuck and then causes the search to stop working.
>
>
>
> I've experienced this bug as well. However, it's in debian stable
> (bullseye) with geary 3.38.1-1. Oddly enough, upgrading to (a backport
> of) geary 40.0-7 seems to have fixed the issue.  3.38.1-1 worked fine
> for me for at least a year, and then suddenly I couldn't search any
> more and no amount of restarting seemed to fix it.

When did you start experiencing the bug?

Thank you,
Jeremy Bicha

Bug#1021256: gtkmm4: autopkgtest failure: Failed to locate “gtk-logo.webm” in any source directory

[Jeremy Bicha]

On Tue, Oct 4, 2022 at 3:05 PM Adrian Bunk  wrote:
>
> On Tue, Oct 04, 2022 at 02:57:07PM -0400, Jeremy Bicha wrote:
> > On Tue, Oct 4, 2022 at 2:54 PM Adrian Bunk  wrote:
> > > On Tue, Oct 04, 2022 at 02:49:37PM -0400, Jeremy Bicha wrote:
> > > > Control: severity -1 important
> > > >
> > > > Since gtkmm4.0 is new to Debian, a broken autopkgtest isn't a
> > > > regression and doesn't block migration to Testing.
> >
> > I think that's a bug in the testing migration. I don't believe it's
> > supposed to block in this case.
>
> autopkgtest failures in testing are release critical bugs,
> blocking prevents an RC bug from entering testing.

I don't think so? I believe there are autopkgtests that have always
failed in Testing.

Anyway, here's the current failure:

gtktest.cc: In function ‘void {anonymous}::do_quit()’:
gtktest.cc:10:10: error: ‘Gtk::Main’ has not been declared
   10 | Gtk::Main::quit();
  |  ^~~~
gtktest.cc: In function ‘int main(int, char**)’:
gtktest.cc:18:10: error: ‘Main’ is not a member of ‘Gtk’
   18 | Gtk::Main main_instance (, );
  |  ^~~~
gtktest.cc:24:10: error: ‘Gtk::Main’ has not been declared
   24 | Gtk::Main::run();
  |  ^~~~

The gtkmm4 documentation provides an example ("Hello, world") app but
it works differently. I don't have much experience with gtkmm coding
or C++. We'll need to decide whether we want to just use their example
or tweak what we copied from gtkmm3. Or just drop our custom basic
app.

Jeremy Bicha

Bug#1021256: gtkmm4: autopkgtest failure: Failed to locate “gtk-logo.webm” in any source directory

[Jeremy Bicha]

On Tue, Oct 4, 2022 at 2:54 PM Adrian Bunk  wrote:
> On Tue, Oct 04, 2022 at 02:49:37PM -0400, Jeremy Bicha wrote:
> > Control: severity -1 important
> >
> > Since gtkmm4.0 is new to Debian, a broken autopkgtest isn't a
> > regression and doesn't block migration to Testing.

I think that's a bug in the testing migration. I don't believe it's
supposed to block in this case.

Thank you,
Jeremy Bicha

Bug#1021256: gtkmm4: autopkgtest failure: Failed to locate “gtk-logo.webm” in any source directory

[Jeremy Bicha]

Control: severity -1 important

Since gtkmm4.0 is new to Debian, a broken autopkgtest isn't a
regression and doesn't block migration to Testing.

I've fixed the one line seen in the autopkgtest failure, but…

We need to either port the minimal gtkmm app to gtkmm4 or drop it and
just use the included demos apps to test whether simple gtkmm apps
build and work.

Thank you,
Jeremy Bicha

Bug#1021211: remmina: switch to libsoup3

[Jeremy Bicha]

Source: remmina
Version: 1.4.27+dfsg-2
Forwarded: https://gitlab.com/Remmina/Remmina/-/merge_requests/2431
User: pkg-webkit-maintain...@lists.alioth.debian.org
Usertags: webkit-4.0

Please switch remmina to build with libsoup3 and webkit2gtk 4.1
instead of libsoup2.4 and webkit2gtk 4.0. You can backport the commits
from the linked merge proposal.

This will also allow you to re-enable the spice plugin.

Thank you,
Jeremy Bicha

Bug#1020639: pdfarranger: libqpdf 11 require pdfarranger 1.9.1

[Jeremy Bicha]

On Sun, Oct 2, 2022 at 8:15 AM Jérémy Lal  wrote:
> i've prepared and pushed an update to salsa.
>
> I can upload it, if no one is planning to do it.

Go ahead.

Thank you,
Jeremy Bicha

Bug#1009990: libmutter-11-0: Night Light is unavailable on a system where it was working earlier

[Jeremy Bicha]

On Wed, Sep 28, 2022 at 9:00 AM Chandra Sekar Srinivasan
 wrote:
> Even after upgrading mutter to 43.0.2, the Night Light panel under
> Display settings says,
>
> "Night Light Unavailable
>
> This could be the result of the graphics driver being used, or the desktop 
> being used remotely"
>
> I have an AMD graphics card and Night Light used to work on this system
> until one of the updates in the past broke it, as described in the
> original report.
>
> $ lspci | grep VGA

You should file a new bug since your specific issue may not be the
same as the original issue.

I know that there is a bug where gnome-control-center says that Night
Light is Unavailable but it may actually work.

Thank you,
Jeremy Bicha

Bug#1020249: PipeWire?

[Jeremy Bicha]

On Tue, Sep 27, 2022 at 5:36 PM Herbert Snorrason  wrote:
>
> I'm guessing this is why a.) my system removed pulseaudio in favour of 
> pipewire
> and b.) removed gnome and gnome-core when I reinstalled pulseaudio to get
> working sound again.
>
> Do I understand correctly that I need to figure how to get pipewire working
> before the gnome and gnome-core packages can be installed again? Pipewire
> completely fails to start, and I really don't see how it's unreasonable to
> prefer continuing to use the sound system that, you know, works. :)

Did you restart your computer after installing pipewire?

If you still have issues, please file a new bug, probably against pipewire.

Generally, the GNOME metapackages are provided by the Debian GNOME
team to give users a complete working set of packages without allowing
arbitrary substitutions. It's possible to have a system without
gnome-core and gnome installed, but then you're on your own.

Thank you,
Jeremy Bicha

Bug#1020249: gnome-core: Switch to PipeWire

[Jeremy Bicha]

On Mon, Sep 26, 2022 at 3:50 AM Dylan Aïssi  wrote:
> Is there anything to address before uploading this change?

No, I was just waiting for your Friday pipewire upload and then I
wanted to do this upload during my work week. Done now and a similar
upload for gnome-settings-daemon.

Thank you,
Jeremy Bicha

Bug#1020642: webkit2gtk: FTBFS on mipsel: virtual memory exhausted

[Jeremy Bicha]

On Mon, Sep 26, 2022 at 9:03 AM Adrian Bunk  wrote:
> I had the worst possible outcome on the porterbox:
> The reference build succeeded unchanged.  :-(

You mean you got 2.38.0-1 to build successfully once? I expected it
would succeed some of the time because I don't think much changed
since the 2.37.9* versions. But it clearly wasn't reliable enough this
month.

https://buildd.debian.org/status/logs.php?pkg=webkit2gtk=mipsel

Thank you,
Jeremy Bicha

Bug#1020731: Please package the non-color version

[Jeremy Bicha]

Control: forwarded -1 https://github.com/googlefonts/noto-emoji/issues/390
Control: tags -1 +upstream

Google hasn't released the source for the new monochrome font yet.

When it's released, we'll likely do a new binary package for it. If
Google releases it in a separate git repo (which is what I'm guessing
they'll do), this will also be in a new source package.

Thank you,
Jeremy Bicha

Bug#1020705: glibc: Keep DT_HASH

[Jeremy Bicha]

Source: glibc
Version: 2.36-1
Tags: patch

Please consider restoring DT_HASH in your glibc 2.36 packaging. Here's
an article with more details:

https://lwn.net/Articles/904892/

Below is the patch that Ubuntu 22.10 is applying. Or you could use the
Arch Linux patch
https://github.com/archlinux/svntogit-packages/blob/packages/glibc/trunk/reenable_DT_HASH.patch


diff -pruN 2.36-1/debian/patches/restore-libc-DT_HASH.patch
2.36-0ubuntu2/debian/patches/restore-libc-DT_HASH.patch
--- 2.36-1/debian/patches/restore-libc-DT_HASH.patch 1970-01-01
00:00:00.0 +
+++ 2.36-0ubuntu2/debian/patches/restore-libc-DT_HASH.patch 2022-08-22
01:24:09.0 +
@@ -0,0 +1,32 @@
+Description: restore DT_HASH tag for libc.so.6
+ Should consider upstreaming a configure flag for this, perhaps.
+Author: Michael Hudson-Doyle
+Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29456
+Last-Update: 2022-08-22
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/Makerules
 b/Makerules
+@@ -558,6 +558,9 @@
+  -Wl,--verbose 2>/dev/null | \
+  sed > $@T \
+  -e '/^=/,/^=/!d;/^=/d' \
++  -e 's/^.*\.gnu\.hash[]*:.*$$/  .note.ABI-tag :
{ *(.note.ABI-tag) } &/' \
++  -e '/^[  ]*\.hash[   ]*:.*$$/{h;d;}' \
++  -e '/DATA_SEGMENT_ALIGN/{H;g}' \
+  -e 's/^.*\*(\.dynbss).*$$/& \
+ PROVIDE(__start___libc_freeres_ptrs = .); \
+ *(__libc_freeres_ptrs) \
+--- a/Makeconfig
 b/Makeconfig
+@@ -367,6 +367,10 @@
+ LDFLAGS.so += $(relro-LDFLAGS)
+ LDFLAGS-rtld += $(relro-LDFLAGS)
+
++hashstyle-LDFLAGS = -Wl,--hash-style=both
++LDFLAGS.so += $(hashstyle-LDFLAGS)
++LDFLAGS-rtld += $(hashstyle-LDFLAGS)
++
+ # Linker options to enable and disable DT_RELR.
+ ifeq ($(have-dt-relr),yes)
+ dt-relr-ldflag = -Wl,-z,pack-relative-relocs


Thank you,
Jeremy Bicha

Bug#1017063: fixed in gjs 1.73.1-2

[Jeremy Bicha]

On Sun, Sep 4, 2022 at 11:42 AM Paul Gevers  wrote:
> On Sat, 13 Aug 2022 01:48:54 + Debian FTP Masters
>  wrote:
> >  gjs (1.73.1-2) unstable; urgency=medium
> >  .
> >* Rebuild against latest mozjs91 (Closes: #1017063)
>
> You forgot to enforce this with a *versioned* build dependency and now
> armhf got build with the old version.
>
> But anyways. This smells a bit like an ABI breakage. Did something go
> wrong with mozjs91? And maybe we want to prevent issues during partial
> upgrades, then mozjs91 should break the old version of gjs.
>
> Normally no-change rebuilds are handled as binNMU's by the Release Team,
> is there any particular reason why you didn't do that?

Sorry, I didn't see your message until now.

I believe mozjs91 started failing to build on arm with gcc-12. Perhaps
that was related to this breakage or maybe Mozilla changed things a
bit more than usual in the 91.12 ESR release.

By not bumping the Build-Depends, gjs was able to build everywhere.
But then it couldn't migrate because on most architectures it got a
Depends on the new mozjs so that didn't really help.

Anyway, this is all fixed in Unstable as gjs now depends on mozjs102
and mozjs102 now builds on all release architectures.

I'll try to remember that a binnmu would have been better in this kind
of situation.

Thank you,
Jeremy Bicha

Bug#1020689: RM: atk1.0 -- RoM; binaries now built by at-spi2-core

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-Cc: atk...@packages.debian.org
Affects: src:atk1.0

at-spi2-core now builds all the binary packages that were built by
atk1.0 before. (This change was made upstream first.)

Therefore, please remove atk1.0

On behalf of the Debian Accessibility Team,
Jeremy Bicha

Bug#1020688: RM: at-spi2-atk -- RoM; binaries now built by at-spi2-core

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-Cc: at-spi2-...@packages.debian.org
Affects: src:at-spi2-atk

at-spi2-core now builds all the binary packages that were built by
at-spi2-atk before. (This change was made upstream first.)

Therefore, please remove at-spi2-core.

On behalf of the Debian Accessibility Team,
Jeremy Bicha

Bug#1018283: gnome-shell-extension-vertical-overview: needs update for GNOME Shell 43

[Jeremy Bicha]

Control: reopen -1

Please raise the maximum gnome-shell version listed in debian/control to 44~

This will ensure it is installable with any GNOME Shell 43 version but
not with any of the GNOME Shell 44 pre-release versions which are
packaged as 43~beta, etc.

So the workflow when there's a new GNOME Shell release is to bump the
version in both metadata.json and debian/control once it's been tested
to verify that it still works.

Thank you,
Jeremy Bicha

Bug#1020643: stardict: Build-Depends on default-mysql but build needs mariadb

[Jeremy Bicha]

Source: stardict
Version: 3.0.7+git20220909+dfsg-2
Severity: important
Tags: patch

stardict Build-Depends on default-libmysqlclient-dev which on Debian
is MariaDB. However, on Ubuntu, it's MySQL.

tools/configure.ac is specifically looking for MariaDB. So I believe
we need to change the Build-Depends to libmariadb-dev unless someone
does the work to make it compatible with MySQL too.

https://salsa.debian.org/debian/stardict/-/merge_requests/3

Thank you
Jeremy Bicha

Bug#1020503: RM: gsfonts -- RoQA; binaries now built by fonts-urw-base35

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-Cc: gsfo...@packages.debian.org
Affects: src:gsfonts

fonts-urw-base35 now builds all the binary packages that were built by
gsfonts before, as transitional packages.

Therefore, please remove gsfonts.

On behalf of the Debian Fonts Task Force,
Jeremy Bicha

Bug#1018277: gnome-shell-extension-sound-device-chooser: needs update for GNOME Shell 43

[Jeremy Bicha]

Control: forwarded -1
https://github.com/kgshank/gse-sound-output-device-chooser/issues/258

Upstream added a poll to get feedback about whether to continue
development of the extension.

Thank you,
Jeremy Bicha

Bug#1020431: libcdio: realpath test failure with glibc 2.36

[Jeremy Bicha]

Source: libcdio
Version: 2.1.0-3
Severity: important
Tags: ftbfs patch bookworm sid

libcdio fails to build with glibc 2.36.

I am submitting a merge proposal to fix this:
https://salsa.debian.org/debian/libcdio/-/merge_requests/4

Thank you,
Jeremy Bicha

Bug#1017015: [Debian-on-mobile-maintainers] Bug#1017015: gnome-console: bugs after switch to GTK4

[Jeremy Bicha]

On Tue, Sep 20, 2022 at 12:26 PM Arnaud Ferraris  wrote:
> That sounds good, thanks for tracking those issues! IIUC the workaround
> for the remaining issue is using middle-click-paste, is that right?

Yeah, that's probably the easiest workaround. There are a few other
ideas on the upstream bug.

Thank you,
Jeremy Bicha