Bug#1080521: transition: Removing gjs and GNOME Shell from armel
On Fri, Sep 6, 2024 at 9:16 AM Simon McVittie wrote: > 0. Adapt some packages to stop depending on gjs or gnome-shell on armel: > […] > 1. Wait for release team ack > 2. Upload gjs/experimental and packages from (0.) to unstable > 3. Adapt meta-gnome3 so gnome-core and gnome are only built on >architectures that have a working gjs > 4. Remove only these armel *binaries* (as NBS), leaving the rest of their >source packages intact: >- gdm3 (from src:gdm3) >- gnome-core (from src:meta-gnome3) >- gnome (from src:meta-gnome3) > 5. Remove all binaries of these source packages from armel: >- eos-sdk >- foliate >- gjs >- gnome-characters >- gnome-maps >- gnome-shell >- gnome-shell-extension-desktop-icons-ng >- gnome-shell-extension-gsconnect >- gnome-shell-extension-manager >- gnome-shell-mailnag >- gnome-shell-pomodoro >- gnome-sound-recorder >- gnome-sushi >- gnome-weather >- gpaste >- polari > 6. Release team will need to force through the transition by ignoring the >"all task packages are installable" check on armel, because >task-gnome-desktop will now be uninstallable on armel I believe we have finished steps 0, 1, and 3. Step 4 is mostly done: gdm3's removal is only requested not done yet. Can I proceed with uploading the new gjs to unstable to finish step 2? I also created https://salsa.debian.org/installer-team/tasksel/-/merge_requests/32 but maybe that's unnecessary since task-gnome-desktop is currently arch: all. Thank you, Jeremy Bícha
Bug#1082036: orca: Please update to 47.0
Source: orca Version: 47~rc-1 Severity: wishlist Please update orca to 47.0 which was released earlier today. I think it is appropriate to release this to Unstable now. I am filing a bug because I think some care is needed to transition from the debian/experimental branch. The workflow here with the Salsa branches is a bit different than in other Debian GNOME packages. https://gitlab.gnome.org/GNOME/orca/-/blob/gnome-47/NEWS Thank you, Jeremy Bícha
Bug#1082010: libgdata: unmaintained upstream
On Tue, Sep 17, 2024 at 8:45 AM Simon McVittie wrote: > I think we should seriously consider removing this from trixie. My opinion is that libgdata is the most critical thing blocking removal of libsoup2.4 from Debian. I was intending to have it removed from Testing after Trixie is released if https://gitlab.gnome.org/GNOME/libgdata/-/merge_requests/49 hadn't been resolved by then. https://release.debian.org/transitions/html/libsoup3.html https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=pkg-gnome-maintainers%40lists.alioth.debian.org&tag=libsoup2 I think the Google Drive integration is very useful and it would be a shame to lose it. There were other apps that had extra Google integration like gnome-photos but those were lost when libgdata wasn't ported to libsoup3 and apps can't directly link against libsoup2.4 and libsoup3. Except for the libsoup issue, I didn't have other problems with libgdata. Thank you, Jeremy Bícha
Bug#1069502: [Help] Re: input-utils: FTBFS on armhf: input.c:146:18: error: ‘struct input_event’ has no member named ‘time’
On 2024-09-16, at 15:18:27 +0200, Andreas Tille wrote:
> Am Mon, Sep 16, 2024 at 12:23:36PM +0100 schrieb Jeremy Sowden:
> > Try this patch.
>
> Works.
>
> Thanks a lot for the quick help
A quick follow-up now I have more time. The definition of `struct
input_event` in /usr/include/linux/input.h looks like this:
/*
* The event structure itself
* Note that __USE_TIME_BITS64 is defined by libc based on
* application's request to use 64 bit time_t.
*/
struct input_event {
#if (__BITS_PER_LONG != 32 || !defined(__USE_TIME_BITS64)) &&
!defined(__KERNEL__)
struct timeval time;
#define input_event_sec time.tv_sec
#define input_event_usec time.tv_usec
#else
__kernel_ulong_t __sec;
#if defined(__sparc__) && defined(__arch64__)
unsigned int __usec;
unsigned int __pad;
#else
__kernel_ulong_t __usec;
#endif
#define input_event_sec __sec
#define input_event_usec __usec
#endif
__u16 type;
__u16 code;
__s32 value;
};
The ifdeffery is to support 64-bit `time_t`. The patch I gave you
replaces direct references to the `struct timeval time` member, which is
not defined on some 32-bit architectures, with the `input_event_[u]sec`
macros.
J.
signature.asc
Description: PGP signature
Bug#1067577: sysprof: B-D on libunwind-dev which is not generally available
On Sun, Mar 24, 2024 at 1:09 PM Thorsten Glaser wrote: > lgtm; m68k successfully built gtk4 as an older version of > sysprof was still available and installable, and the other > ports architectures except hurd-amd64 will likely have the > same. We have done what Simon suggested earlier and libraries that use sysprof only use it on architectures where sysprof is built. Therefore, sysprof being unbuildable on some architectures should not be a blocker except for gnome-builder where I haven't tried disabling sysprof for miscellaneous architectures (because I don't think that is currently worth the effort). A good example is pango. I recently enabled sysprof support there for available architectures and pango is built on every Debian architecture and port. The latest gtk4 is now built for m68k; however the m68k buildds are configured to skip dh_auto_test so I don't know if gtk4 is actually usable there. Thank you, Jeremy Bícha
Bug#1069502: [Help] Re:input-utils: FTBFS on armhf: input.c:146:18: error: ‘struct input_event’ has no member named ‘time’
On 2024-09-16, at 12:32:59 +0200, Andreas Tille wrote:
> Control: tags -1 help
> Control: tags -1 confirmed
> Thanks
>
> Hi,
>
> since input-utils showed up as Bug of the Day[1] I worked down the list
> of bugs including upgrading to latest upstream. Unfortunately the FTBFS
> for several 32bit architectures (not only armhf) remains[2].
>
> Since I have no experience with these architectures I'd kindly ask for
> help here.
>
> Kind regards
> Andreas.
>
> [1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks
> [2] https://buildd.debian.org/status/package.php?p=input-utils
Try this patch.
J.
--- a/input.c
+++ b/input.c
@@ -209,9 +209,9 @@
char ts[32];
time_t t;
- t = event->time.tv_sec;
+ t = event->input_event_sec;
strftime(ts,sizeof(ts),"%H:%M:%S",localtime(&t));
- printf("%s.%06ld: %s",ts,event->time.tv_usec,
+ printf("%s.%06ld: %s",ts,event->input_event_usec,
EV_NAME[event->type]);
switch (event->type) {
case EV_KEY:
--- a/input-send.c
+++ b/input-send.c
@@ -73,8 +73,8 @@
print_event(ev);
/* convert to network byte order ... */
- ev->time.tv_sec = htonl(ev->time.tv_sec);
- ev->time.tv_usec = htonl(ev->time.tv_usec);
+ ev->input_event_sec = htonl(ev->input_event_sec);
+ ev->input_event_usec = htonl(ev->input_event_usec);
ev->type = htons(ev->type);
ev->code = htons(ev->code);
ev->value= htonl(ev->value);
signature.asc
Description: PGP signature
Bug#1081904: pipewire: consider cherry-picking gnome-snapshot fix
Source: pipewire Version: 1.2.3-1 Severity: important Tags: patch Control: affects -1 src:gnome-snapshot Please consider cherry-picking the 2 patches that Ubuntu 24.10 has picked up to fix gnome-snapshot not working unless the camera is reconnected or pipewire/wireplumber restarted. The issue doesn't affect everyone but I have personally experienced it on multiple computers. https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/2118 https://launchpad.net/ubuntu/+source/pipewire/1.2.3-1ubuntu1 Thank you, Jeremy Bícha
Bug#1081900: rust-curve25519-dalek: autopkgtests failures: merlin unavailable
Source: rust-curve25519-dalek Version: 4.1.3+20240618+dfsg-7 Severity: serious rust-curve25519-dalek is unable to migrate to testing because its autopkgtests are failing. error: no matching package named `merlin` found https://qa.debian.org/excuses.php?package=rust-curve25519-dalek Thank you, Jeremy Bícha
Bug#1081885: forensics-all-gui: Depends on hydra-gtk which no longer exists
Package: forensics-all-gui Version: 3.56 Severity: serious Control: affects -1 src:hydra hydra-gtk is no longer built in Debian as of hydra 9.5-2. Therefore, please remove it from Depends for forensics-all-gui. Thank you, Jeremy Bícha
Bug#1081865: gnome-keyring: FTBFS: ERROR: test-import Invalid test number: /gnome2-store/import/pkcs12 - Gck-FATAL-WARNING: couldn't close session properly: The module has not been initialized
Control: severity -1 important On Sun, Sep 15, 2024 at 1:33 PM Santiago Vila wrote: > Package: src:gnome-keyring > Version: 46.2-1 > Severity: serious > Tags: ftbfs > > Dear maintainer: > > During a rebuild of all packages in unstable, your package failed to build: Yes, this failure can be seen in the most recent upload so this is definitely a flaky test currently. https://buildd.debian.org/status/logs.php?pkg=gnome-keyring&ver=46.2-1 However, I don't think it happens frequently enough to be RC now. Thank you, Jeremy Bícha
Bug#1081519: transition: gnome-shell 47
Control: tags -1 -moreinfo Control: unblock -1 by 1080521 1079548 GNOME Shell and Mutter 47.0 have been released and are packaged in Experimental. We are ready to proceed with this transition. On behalf of the Debian GNOME team, Jeremy Bícha
Bug#648485: RFP: gnome-shell-frippery -- Frippery GNOME Shell extensions
The extensions are now at https://frippery.org/extensions/ Thank you, Jeremy Bícha
Bug#950713: gnome-shell-extensions: window-list: keeps disappearing: TypeError: Main.windowPicker is undefined
Paul, Are you still experiencing this bug? Thank you, Jeremy Bícha
Bug#1081798: gnome-shell-extensions: Split into separate packages
Source: gnome-shell-extensions Version: 46.2-3 It should be possible to do any of these: - Install the GNOME Classic mode without installing unnecessary additional extensions - Install only the extensions you want to use so that the extensions list isn't cluttered - Install the GNOME Classic session without also installing the GNOME Classic on Xorg session, similar to what is possible by installing gnome-session and uninstalling gnome-session-xsession This is similar to how this is packaged in Fedora: https://packages.fedoraproject.org/pkgs/gnome-shell-extensions/ Thank you, Jeremy Bícha
Bug#1081783: RM: rust-failure -- RoM; FTBFS, unmaintained
Package: ftp.debian.org User: ftp.debian@packages.debian.org Usertags: remove Control: affects -1 src:rust-failure X-Debbugs-Cc: debian-r...@lists.debian.org Control: block -1 by 1081772 1081773 1081774 1081779 Please remove rust-failure It is unbuildable in Debian. It was archived upstream years ago because there are alternative ways to do what it did. https://github.com/rust-lang-deprecated/failure On behalf of the Debian Rust team, Jeremy Bicha
Bug#1081782: RM: rust-failure-derive -- RoM; unmaintained and unneeded
Package: ftp.debian.org User: ftp.debian@packages.debian.org Usertags: remove Control: affects -1 src:rust-failure-derive X-Debbugs-Cc: debian-r...@lists.debian.org Please remove rust-failure-derive It is unbuildable in Debian. It was archived upstream years ago because there are alternative ways to do what rust-failure did. https://github.com/rust-lang-deprecated/failure On behalf of the Debian Rust team, Jeremy Bicha
Bug#1081779: RM: rust-include-dir-impl -- RoM; FTBFS, unused
Package: ftp.debian.org User: ftp.debian@packages.debian.org Usertags: remove Control: affects -1 src:rust-include-dir-impl X-Debbugs-Cc: debian-r...@lists.debian.org Please remove rust-include-dir-impl It is blocking removal of rust-failure which is unbuildable in Debian. It has no reverse dependencies. On behalf of the Debian Rust team, Jeremy Bicha
Bug#1081774: RM: rust-mdl -- RoM; unmaintained
Package: ftp.debian.org User: ftp.debian@packages.debian.org Usertags: remove Control: affects -1 src:rust-mdl X-Debbugs-Cc: debian-r...@lists.debian.org Please remove rust-mdl It hasn't been updated in years upstream and is unbuildable in Debian. https://gitlab.gnome.org/danigm/mdl On behalf of the Debian Rust team, Jeremy Bicha
Bug#1081773: RM: rust-exitfailure -- RoM; unmaintained
Package: ftp.debian.org User: ftp.debian@packages.debian.org Usertags: remove Control: affects -1 src:rust-exitfailure X-Debbugs-Cc: debian-r...@lists.debian.org Please remove rust-exitfailure. It hasn't been updated in years upstream and is blocking completion of the rust-synstructure transition. https://github.com/tismith/exitfailure On behalf of the Debian Rust team, Jeremy Bicha
Bug#1081772: RM: rust-assert-cli -- RoM; unmaintained
Package: ftp.debian.org User: ftp.debian@packages.debian.org Usertags: remove Control: affects -1 src:rust-assert-cli X-Debbugs-Cc: debian-r...@lists.debian.org Please remove rust-assert-cli. It was archived upstream years ago with a note that assert_cmd is the successor project. rust-assert-cmd is already in Debian. https://github.com/assert-rs/assert_cli rust-assert-cli is blocking completion of the rust-synstructure transition. On behalf of the Debian Rust team, Jeremy Bicha
Bug#910573: New upstream version 3.28
The latexila/GNOME LaTeX project has been renamed again. https://gitlab.gnome.org/swilmet/enter-tex Thank you, Jeremy Bícha
Bug#1081570: RFS: luit/2.0.20240910-1 -- locale and ISO 2022 support for Unicode terminals
On 2024-09-14, at 06:52:31 -0400, Thomas Dickey wrote: > On Sat, Sep 14, 2024 at 02:08:44AM +0100, Phil Wyett wrote: > > Control: tags -1 +moreinfo > > > > Thomas, > > > > Many thanks for addressing some of the issues raised. > > > > One lintian issue remains. > > > > I: luit source: unused-override no-debian-changes [debian/source/lintian- > > overrides:2] > > On removing that file, I get this warning (and by the way do not see the > warning which you report): > > > run-lintian luit_2.0.20240910-1.dsc luit_2.0.20240910-1_amd64.buildinfo > > luit_2 > .0.20240910-1_amd64.changes > N: > W: luit source: no-debian-changes > N: > N: This non-native package makes no changes to the upstream sources in the > N: Debian-related files. > N: > N: Maybe a mistake was made when the upstream tarball was created, or maybe > N: this package is really a native package but was built non-native by > N: mistake. > N: > N: Debian packaging is sometimes maintained as part of upstream, but that is > N: not recommended as best practice. Please make this package native, if the > N: software is only for Debian. Otherwise, please remove the debian > directory > N: from upstream releases and add it in the Debian packaging. > N: > N: Format 1.0 packages are subject to the restriction that the diff cannot > N: remove files from the debian directory. For Format 3.0 packages, the > N: debian directory is automatically purged during unpacking. > N: > N: Visibility: warning > N: Show-Always: no > N: Check: files/artifact > N: Renamed from: empty-debian-diff > N: I've just cloned g...@salsa.debian.org:debian/luit, added the missing upstream/2.0.20240910 tag, and built the package using gbp-buildpackage. I got two lintian warnings: $ schroot -c sid -- lintian --display-info --pedantic --tag-display-limit 0 W: luit source: orig-tarball-missing-upstream-signature luit_2.0.20240910.orig.tar.gz I: luit source: unused-override no-debian-changes [debian/source/lintian-overrides:2] N: 0 hints overridden; 1 unused override I deleted d/s/lintian-overrides, built the package again and got just one: $ schroot -c sid -- lintian --display-info --pedantic --tag-display-limit 0 W: luit source: orig-tarball-missing-upstream-signature luit_2.0.20240910.orig.tar.gz Do you have local changes that you haven't pushed? J. signature.asc Description: PGP signature
Bug#1081699: librsvg-tests: No longer includes tests
Source: librsvg Version: 2.59.0+dfsg-1 Severity: important Forwarded: https://gitlab.gnome.org/GNOME/librsvg/-/issues/1119 The librsvg 2.59 release switched to meson and removed the installed tests feature. I reported this issue upstream and upstream is not sure whether these tests in their previous form were useful. I kept the librsvg-tests binary package for now to avoid a trip through the NEW queue, but we'll eventually need to remove the package if we aren't able to replace the installed tests. Thank you, Jeremy Bícha
Bug#1081417: gnome-settings-daemon: frequent test failure: timed out waiting for plugin startup: XSettings
Simon, I'm following up here instead of at https://bugs.debian.org/1081519 because I didn't think we needed to copy the Release Team on this and it's a more specific issue. These build tests backed by Mutter have only been enabled starting in July. We didn't know that we weren't running them, but we could consciously choose not to run them now. They won't run if mutter and related Build-Depends marked with and architecture qualifiers aren't installed at build time. One negative of using Mutter for gnome-settings-daemon build tests is that gnome-settings-daemon is used by several other desktops like GNOME Flashback which we expect would be easier for some architectures to get working than Mutter. That's why I was ok with not running these tests on many architectures anyway. Do you want me to basically just undo my test enablement from July or do you want to use a different approach? Thank you, Jeremy Bícha
Bug#1081519: transition: gnome-shell 47
On Thu, Sep 12, 2024 at 7:15 AM Simon McVittie wrote: > Ideally gnome-settings-daemon would go along with this transition, but it > has several very flaky build-time tests which cause FTBFS. If they can't > be fixed soon, a mitigation would be to disable those tests (I suspect > this is a problem with the test scaffolding rather than g-s-d itself). Some things like xwayland scaling won't work right if we don't have gnome-settings-daemon >= 47~rc. The build tests do pass if retried a few times. I think overall it would be better to get GNOME Shell 47 into Unstable faster. If it helps, we only started running this mutter set of tests in July because we didn't notice earlier we had tests that were not being run. > Packages involved > = I believe we have 3 different sets remaining for "GNOME 47" and they can each happen independently or simultaneously: - gtk4 + libadwaita + all the GNOME 47 app & library updates that are not in Unstable already and not part of the other 2 categories - gjs with the switch to mozjs128. Years ago, gjs updates were disruptive but not really anymore. We are doing some armel surgery this time though. - GNOME Shell Historically, we do usually land the xdg-desktop-portal-gnome update at the same time as GNOME Shell. This time it depends on nautilus 47 which needs the new gtk4 & libadwaita. The only other big change this time is that the xdg-desktop-portal-gnome update is required for the new Accent Colors feature which won't work until GTK4 & libadwaita are updated. So here's my modified list of packages for the GNOME Shell 47 transition: - gnome-kiosk gnome-remote-desktop gnome-settings-daemon gnome-shell gnome-shell-extensions mutter xdg-desktop-portal-gnome (but only if GTK4 & libadwaita & nautilus were pushed first) and then there are a few GNOME Shell extensions left to upload (the red ones on the tracker), some as NMUs, and yaru-theme [which I can handle]. This transition will be much smoother than any GNOME Shell transition we have had in years. We may ask for a few packaged extensions to be removed, but since GNOME didn't change as much this cycle, it's also possible that no removals will be needed. Many extensions have already been updated in Unstable since most extensions work with both 46 and 47. I did several of these uploads this week and pinged maintainers for the remaining ones. Thank you, Jeremy Bícha
Bug#1081654: transition: gspell 1.14
Package: release.debian.org User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: gsp...@packages.debian.org Control: affects -1 src:gspell I request permission to do the transition for gspell 1.14 "Bump soversion because a symbol was exported by mistake with the Autotools." The symbol was gspell_get_resource which seems unused in Debian. https://release.debian.org/transitions/html/auto-gspell.html Thank you, Jeremy Bicha
Bug#1081638: gnome-shell-extension-no-annoyance: needs update for GNOME Shell 47
Source: gnome-shell-extension-no-annoyance Version: 0+20240813-8312e01-1 Severity: serious Tags: trixie sid upstream User: pkg-gnome-maintain...@lists.alioth.debian.org Usertags: gnome-shell-47 X-Debbugs-CC: hank.k...@gmail.com, dilin...@debian.org GNOME Shell 47 RC is in Experimental and I'd like to upload it to Unstable in a few days after 47.0 is released. >From what I've seen, most packaged GNOME Shell extensions compatible with 46 can be made compatible with 47 by simply patching the metadata.json file to add "47" to the list and then bumping the upper GNOME Shell Depends to gnome-shell (<<48~) There's also https://gjs.guide/extensions/upgrading/gnome-shell-47.html By the way, I could give you commit access if you want to move this packaging back to the GNOME team repo. Thank you, Jeremy Bícha
Bug#1081577: gnome-session-bin: should not depend on upower
On Thu, Sep 12, 2024 at 6:48 PM Russell Coker wrote: > Package: gnome-session-bin > Version: 46.0-7 > Severity: normal > > The packahe upower doesn't seem to provide any benefit on desktop systems > and should be a recommended package not a dependency. Why? Thank you, Jeremy Bícha
Bug#1052105: gnome-shell-extension-no-annoyance: needs update for GNOME Shell 46
On Wed, Aug 28, 2024 at 8:40 PM Hank Knox wrote: > I submitted a merge request for the first step, the updated files from > the new upstream source. Thank you for working on this package. I need to inform you that we will be uploading GNOME Shell 47 to Unstable soon after 47.0 is released in a few days. GNOME Shell 47 RC is available in Debian Experimental. What this means is that in order for your package to migrate to Testing, it will also need to be compatible with GNOME Shell 47. In many cases, this is as simple as patching metadata.json to also mark it compatible with "47" and changing the maximum dependency in debian/control to gnome-shell (<< 48~), I encourage you to submit a bug request or merge request upstream to encourage them to mark the extension as compatible with GNOME Shell 47 (hopefully someone tests that it actually is too). See also https://gjs.guide/extensions/upgrading/gnome-shell-47.html Thank you, Jeremy Bícha
Bug#1081580: gnome-shell-extension-panel-osd: Intent to remove from Debian
Source: gnome-shell-extension-panel-osd Version: 1.0.50.gc032923-4 Severity: serious gnome-shell-extension-panel-osd is not compatible with GNOME Shell >= 45. The current version of GNOME Shell in Debian Unstable is 46 and will likely be 47 later this month. Meanwhile, this extension has been abandoned upstream a while ago: https://bugs.debian.org/1018274 I intend to file a bug to request removal of this package from Debian soon. Thank you, Jeremy Bícha
Bug#1079260: workrave-gnome: needs update for GNOME Shell 47
Control: severity -1 serious Control: tags -1 +patch Control: forwarded -1 https://salsa.debian.org/debian/workrave/-/merge_requests/11 GNOME Shell 47 RC is in Experimental and I'd like to upload it to Unstable in a few days after 47.0 is released. I submitted a merge request to fix this issue. Thank you, Jeremy Bícha
Bug#1079257: gnome-shell-extensions-extra: needs update for GNOME Shell 47
Control: severity -1 serious GNOME Shell 47 RC is in Experimental and I'd like to upload it to Unstable in a few days after 47.0 is released. >From what I've seen, most packaged GNOME Shell extensions compatible with 46 can be made compatible with 47 by simply patching the metadata.json file to add "47" to the list and then bumping the upper GNOME Shell Depends to 48 Thank you, Jeremy Bícha
Bug#1079253: gnome-shell-extension-kimpanel: needs update for GNOME Shell 47
Control: severity -1 serious GNOME Shell 47 RC is in Experimental and I'd like to upload it to Unstable in a few days after 47.0 is released. I wasn't sure how to test that this extension works. It might be as simple as patching the metadata.json file to add "47" to the list and then setting the Depends to gnome-shell (>= 45~), gnome-shell (<< 48~), Thank you, Jeremy Bícha
Bug#1079256: gnome-shell-extension-shortcuts: needs update for GNOME Shell 47
In the future, I encourage you to set the lower bound to gnome-shell (>= 47~) The current version of gnome-shell in Experimental is 47~rc which sorts lower than 47 so this package is currently uninstallable in Experimental. gnome-shell 47.0 is expected to be released in a few days and we are waiting for it to be released and packaged before uploading any GNOME Shell 47 version to Unstable. So this issue will go away in a few days. Thank you, Jeremy Bícha
Bug#1081578: librsvg: Upload 2.59.0 to Unstable
Source: librsvg Version: 2.58.94+dfsg-3 Severity: wishlist X-Debbugs-CC: werdah...@riseup.net, librsvg 2.59.0 was released today. I packaged the release candidate in Experimental already. I have hesitated to upload this to Unstable because the new version switched to meson and removed the installed tests. I reported this issue at https://gitlab.gnome.org/GNOME/librsvg/-/issues/1119 . Upstream had follow-up questions which Alessandro recently replied to. On the other hand, the current version of librsvg in Unstable recently started failing to build. See https://salsa.debian.org/gnome-team/librsvg/-/merge_requests/27 for the fix. Thank you, Jeremy Bícha
Bug#1079239: gnome-shell-extension-autohidetopbar: needs update for GNOME Shell 47
Control: severity -1 serious Control: tags -1 +patch Control: forwarded -1 https://salsa.debian.org/debian/gnome-shell-extension-autohidetopbar/-/merge_requests/3 I have prepared a merge request to fix this issue. Thank you, Jeremy Bícha
Bug#1079250: gnome-shell-extension-hamster: needs update for GNOME Shell 47
Control: severity -1 serious Control: tags -1 +patch Control: forwarded -1 https://salsa.debian.org/projecthamster-team/gnome-shell-extension-hamster/-/merge_requests/7 I have prepared a merge request to fix this issue. Thank you, Jeremy Bícha
Bug#1081551: gnome-shell-extension-freon: Add Depends lm-sensors?
Source: gnome-shell-extension-freon Version: 56+dfsg-1 Severity: important X-Debbugs-CC: m...@debian.org While testing this extension briefly for the GNOME Shell 47 transition, I noticed that it appears like this extension doesn't work without lm-sensors installed. I was testing in a VM so I didn't actually have sensors available. Thank you, Jeremy Bícha
Bug#1079259: gnome-shell-extension-pomodoro: needs update for GNOME Shell 47
Control: severity -1 serious There is a new version 0.26.0 release that claims compatibility with GNOME Shell 47 while preserving it for 46. Could you work on packaging this update? GNOME Shell 47 RC is in Experimental and I'd like to upload it to Unstable in a few days after 47.0 is released. Thank you, Jeremy Bícha
Bug#1081537: fuse transitional package is required for upgrades
Patch attached.
Thank you,
Jeremy Bícha
From 87c8fda73670e158da7fd797cfbf2a35cbcc0d94 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jeremy=20B=C3=ADcha?=
Date: Thu, 12 Sep 2024 10:37:58 -0400
Subject: [PATCH] Add fuse transitional package to upgrade to fuse3
Closes: #918984
Closes: #927291
Closes: #1074767
Closes: #1081537
LP: #1978310
---
debian/control | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/debian/control b/debian/control
index 3d2c0a5..e8e80d1 100644
--- a/debian/control
+++ b/debian/control
@@ -24,8 +24,7 @@ Depends:
mount (>= 2.19.1),
sed (>= 4)
Provides: fuse (= ${source:Version})
-Breaks: fuse
-Conflicts: fuse
+Breaks: fuse (<< ${source:Version})
Description: Filesystem in Userspace (3.x version)
Filesystem in Userspace (FUSE) is a simple interface for userspace programs to
export a virtual filesystem to the Linux kernel. It also aims to provide a
@@ -85,3 +84,12 @@ Depends:
${misc:Depends},
${shlibs:Depends},
Description: Filesystem in Userspace (library) (3.x version)
+
+Package: fuse
+Architecture: all
+Section: oldlibs
+Depends:
+ ${misc:Depends},
+ fuse3,
+Description: Filesystem in Userspace (transitional package)
+ This is a transitional package. It can safely be removed.
--
2.45.2
Bug#1081537: fuse transitional package is required for upgrades
Source: fuse3
Version: 3.14.0-7
Severity: serious
Control: affects -1 src:fuse
Tags: patch
X-Debbugs-CC: j...@debian.org
fuse 2.9.9-9 stopped building the fuse binary package. The fuse3
binary package has Provides, Conflicts, Breaks: fuse. This is
insufficient for apt to be able to perform the upgrade. On my system
where I installed fuse (to test this issue), apt was unable to upgrade
libfuse2t64 to 2.9.9-9 without manually ordering it to install that
upgrade, even with apt dist-upgrade.
We need to add a transitional package to handle this upgrade. For the
transitional package to work, we need to remove the Conflicts and
change the Breaks to a versioned Breaks. As suggested by Julian, I am
using << ${source:Version} to make backports, etc. easier than
specifying the exact version we need.
I am attaching a patch in my follow up email so that it can have the
correct Closes annotation. This upload would also close several other
bugs so I'm marking that in my patch too.
Thank you,
Jeremy Bícha
Bug#1081531: pidgin-sipe: Stop using freerdp2
Source: pidgin-sipe Severity: serious Version: 1.25.0-2.1 User: debian-rem...@lists.debian.org Usertags: freerdp2 The Debian Remote team is working to remove freerdp2 from inclusion in Debian 13 next year. freerdp3 has been available in Debian Testing for months. I am filing this bug as RC now because I expect there are only a few months before Debian begins freezing for the next stable release and it's best to give affected maintainers as much notice as possible. pidgin-sipe has a build option (related to appshare) to enable building without freerdp2. I recommend that be done now. On behalf of the Debian Remote team, Jeremy Bicha
Bug#1081528: krdp: Stop using freerdp2
Source: krdp Severity: serious Version: 6.1.4-2 User: debian-rem...@lists.debian.org Usertags: freerdp2 Tags: experimental Forwarded: https://invent.kde.org/plasma/krdp/-/issues/15 The Debian Remote team is working to remove freerdp2 from inclusion in Debian 13 next year. freerdp3 has been available in Debian Testing for months. I am filing this bug as RC now because I expect there are only a few months before Debian begins freezing for the next stable release and it's best to give affected maintainers as much notice as possible. On behalf of the Debian Remote team, Jeremy Bicha
Bug#1081530: patator: Stop recommending freerdp2-x11
Source: patator Severity: important Version: 1.0-2 User: debian-rem...@lists.debian.org Usertags: freerdp2 The Debian Remote team is working to remove freerdp2 from inclusion in Debian 13 next year. freerdp3 has been available in Debian Testing for months. I am told that freerdp3-sdl is better than freerdp3-wayland so that is what I suggest you use as the replacement. On behalf of the Debian Remote team, Jeremy Bicha
Bug#1081529: education-desktop-other: Stop recommending freerdp2-x11
Package: education-desktop-other Severity: important Version: 2.12.15 User: debian-rem...@lists.debian.org Usertags: freerdp2 The Debian Remote team is working to remove freerdp2 from inclusion in Debian 13 next year. freerdp3 has been available in Debian Testing for months. I am told that freerdp3-sdl is better than freerdp3-wayland so that is what I suggest you use as the replacement. On behalf of the Debian Remote team, Jeremy Bicha
Bug#1081527: krdc: Stop using freerdp2
Source: krdc Severity: serious Version: 4:23.08.3-1 User: debian-rem...@lists.debian.org Usertags: freerdp2 Forwarded: https://invent.kde.org/network/krdc/-/issues/30 The Debian Remote team is working to remove freerdp2 from inclusion in Debian 13 next year. freerdp3 has been available in Debian Testing for months. I am filing this bug as RC now because I expect there are only a few months before Debian begins freezing for the next stable release and it's best to give affected maintainers as much notice as possible. It looks to me like krdc has a build option to build without freerdp2. That might be the best immediate step. On behalf of the Debian Remote team, Jeremy Bicha
Bug#1081526: lightdm-remote-session-freerdp2: Stop using freerdp2
Source: lightdm-remote-session-freerdp2 Severity: serious Version: 2.0.0-1 User: debian-rem...@lists.debian.org Usertags: freerdp2 Control: block 1081525 by -1 The Debian Remote team is working to remove freerdp2 from inclusion in Debian 13 next year. freerdp3 has been available in Debian Testing for months. Because of the name of this package, I imagine this source package would need to be removed and a replacement source package added once the project is ported to freerdp3. On behalf of the Debian Remote team, Jeremy Bicha
Bug#1081525: libpam-freerdp2: Stop using freerdp2
Source: libpam-freerdp2 Severity: serious Version: 2.0.0-3.1 User: debian-rem...@lists.debian.org Usertags: freerdp2 The Debian Remote team is working to remove freerdp2 from inclusion in Debian 13 next year. freerdp3 has been available in Debian Testing for months. Because of the name of this package, I imagine this source package would need to be removed and a replacement source package added once the project is ported to freerdp3. On behalf of the Debian Remote team, Jeremy Bicha
Bug#1081523: guacomole-server: Switch from freerdp2 to freerdp3
Source: guacamole-server Severity: serious Version: 1.3.0-1.3 User: debian-rem...@lists.debian.org Usertags: freerdp2 Forwarded: https://github.com/apache/guacamole-server/pull/517 The Debian Remote team is working to remove freerdp2 from inclusion in Debian 13 next year. freerdp3 has been available in Debian Testing for months. It appears like git main already has support for building guacamole-server with freerdp3. See the linked pull request. I am filing this bug as RC now because I expect there are only a few months before Debian begins freezing for the next stable release and it's best to give affected maintainers as much notice as possible. On behalf of the Debian Remote team, Jeremy Bicha
Bug#1081522: hydra: Switch from freerdp2 to freerdp3
Source: hydra Severity: serious Version: 9.5-1 User: debian-rem...@lists.debian.org Usertags: freerdp2 The Debian Remote team is working to remove freerdp2 from inclusion in Debian 13 next year. freerdp3 has been available in Debian Testing for months. I believe hydra already has support for building with freerdp3 instead of freerdp2. Please try switching. I am filing this bug as RC now because I expect there are only a few months before Debian begins freezing for the next stable release and it's best to give affected maintainers as much notice as possible. On behalf of the Debian Remote team, Jeremy Bicha
Bug#1079244: gnome-shell-extension-flypie: needs update for GNOME Shell 47
Control: severity -1 serious There is a new version 27 release upstream that claims compatibility with GNOME Shell 47 while preserving it for 46. Could you work on packaging this update? GNOME Shell 47 RC is in Experimental and I'd like to upload it to Unstable in a few days after 47.0 is released. Thank you, Jeremy Bícha
Bug#1079238: gnome-shell-extension-arc-menu: needs update for GNOME Shell 47
Jonathan, The Arc Menu GNOME Shell extension has a new version 60 release that adds support for GNOME Shell 47. Could you package it? I'd like to try to upload GNOME Shell 47 to Unstable soon after 47.0 is released, which is expected in a few days. https://gitlab.com/arcmenu/ArcMenu/-/releases Also, could you update the Homepage and similar field in debian/copyright to point to https://gitlab.com/arcmenu/ArcMenu ? Thank you, Jeremy Bícha
Bug#1081113: RFS: emacs-buttercup/1.36-1 -- behaviour-driven testing for Emacs Lisp packages
On 2024-09-11, at 18:29:51 +0100, Jeremy Sowden wrote: > On 2024-09-10, at 23:07:28 -0700, Xiyue Deng wrote: > > Xiyue Deng writes: > > > Jeremy Sowden writes: > > >> On 2024-09-07, at 22:50:28 -0700, Xiyue Deng wrote: > > >>> Package: sponsorship-requests > > >>> Severity: normal > > >>> > > >>> Dear mentors, > > >>> > > >>> I am looking for a sponsor for my package "emacs-buttercup": > > >>> > > >>> * Package name : emacs-buttercup > > >>>Version : 1.36-1 > > >>>Upstream contact : Jorgen Schaefer > > >>> * URL : https://github.com/jorgenschaefer/emacs-buttercup/ > > >>> * License : GPL-3+, GFDL-1.2+ or CC-BY-SA-3.0 > > >>> * Vcs : > > >>> https://salsa.debian.org/emacsen-team/emacs-buttercup > > >>>Section : lisp > > >>> > > >>> The source builds the following binary packages: > > >>> > > >>> elpa-buttercup - behaviour-driven testing for Emacs Lisp packages > > >>> > > >>> To access further information about this package, please visit the > > >>> following URL: > > >>> > > >>> https://mentors.debian.net/package/emacs-buttercup/ > > >>> > > >>> Alternatively, you can download the package with 'dget' using this > > >>> command: > > >>> > > >>> dget -x > > >>> https://mentors.debian.net/debian/pool/main/e/emacs-buttercup/emacs-buttercup_1.36-1.dsc > > >>> > > >>> Changes since the last upload: > > >>> > > >>> emacs-buttercup (1.36-1) unstable; urgency=medium > > >>> . > > >>>* New upstream release > > >> > > >> This doesn't work: > > >> > > >>>* Drop override_dh_auto_test to use default dh_elpa_test > > >> > > >> dh_elpa_test only runs a package's test-suite if the package build- > > >> depends on elpa-buttercup. Since this is the source package for > > >> elpa-buttercup, that is not the case, and dh_elpa_test exits without > > >> doing anything. > > >> > > >> Because we can't use dh_elpa_test, we also can't do this: > > >> > > >>>* Drop setting EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION now it is > > >>> the > > >>> default > > >> > > >> As it happens, the existing dh_auto_test override doesn't actually work > > >> any more: the upstream code has changed sufficiently that it just loads > > >> tests/test-buttercup.el without actually running any tests. However, > > >> the default make target, "all", has no rules and one dependency on a > > >> target that _does_ run the full test-suite, so dh_auto_build has been > > >> running it instead by accident. My suggestion, therefore, is to skip > > >> dh_auto_build, remove the dh_auto_test override, and let dh_auto_test > > >> just run `make check`. I have pushed a branch to Salsa that implements > > >> this and makes a few other changes: > > >> > > >> > > >> https://salsa.debian.org/emacsen-team/emacs-buttercup/-/tree/dh-auto-test-fixes?ref_type=heads > > >> > > >> Seem reasonable? > > > > > > Thanks for checking and the fixes! I have removed the package on > > > mentors to prevent any premature sponsoring/uploading. > > > > > > One small suggestion: instead of using a comment, add @echo with the > > > message in override_dh_auto_build so that we get this info in the build > > > log. > > > > > > Please feel free to merge to debian/master. > > > > > > > I took the liberty and merged your branch, as well as the small > > suggestion from my other email. Thanks again for the fix. > > > > BTW, will you do the uploading? In which case I'll avoid re-uploading > > to mentors. Thanks in advance! > > Yup. Done. J. signature.asc Description: PGP signature
Bug#1081113: RFS: emacs-buttercup/1.36-1 -- behaviour-driven testing for Emacs Lisp packages
On 2024-09-10, at 23:07:28 -0700, Xiyue Deng wrote: > Xiyue Deng writes: > > Jeremy Sowden writes: > >> On 2024-09-07, at 22:50:28 -0700, Xiyue Deng wrote: > >>> Package: sponsorship-requests > >>> Severity: normal > >>> > >>> Dear mentors, > >>> > >>> I am looking for a sponsor for my package "emacs-buttercup": > >>> > >>> * Package name : emacs-buttercup > >>>Version : 1.36-1 > >>>Upstream contact : Jorgen Schaefer > >>> * URL : https://github.com/jorgenschaefer/emacs-buttercup/ > >>> * License : GPL-3+, GFDL-1.2+ or CC-BY-SA-3.0 > >>> * Vcs : > >>> https://salsa.debian.org/emacsen-team/emacs-buttercup > >>>Section : lisp > >>> > >>> The source builds the following binary packages: > >>> > >>> elpa-buttercup - behaviour-driven testing for Emacs Lisp packages > >>> > >>> To access further information about this package, please visit the > >>> following URL: > >>> > >>> https://mentors.debian.net/package/emacs-buttercup/ > >>> > >>> Alternatively, you can download the package with 'dget' using this > >>> command: > >>> > >>> dget -x > >>> https://mentors.debian.net/debian/pool/main/e/emacs-buttercup/emacs-buttercup_1.36-1.dsc > >>> > >>> Changes since the last upload: > >>> > >>> emacs-buttercup (1.36-1) unstable; urgency=medium > >>> . > >>>* New upstream release > >> > >> This doesn't work: > >> > >>>* Drop override_dh_auto_test to use default dh_elpa_test > >> > >> dh_elpa_test only runs a package's test-suite if the package build- > >> depends on elpa-buttercup. Since this is the source package for > >> elpa-buttercup, that is not the case, and dh_elpa_test exits without > >> doing anything. > >> > >> Because we can't use dh_elpa_test, we also can't do this: > >> > >>>* Drop setting EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION now it is the > >>> default > >> > >> As it happens, the existing dh_auto_test override doesn't actually work > >> any more: the upstream code has changed sufficiently that it just loads > >> tests/test-buttercup.el without actually running any tests. However, > >> the default make target, "all", has no rules and one dependency on a > >> target that _does_ run the full test-suite, so dh_auto_build has been > >> running it instead by accident. My suggestion, therefore, is to skip > >> dh_auto_build, remove the dh_auto_test override, and let dh_auto_test > >> just run `make check`. I have pushed a branch to Salsa that implements > >> this and makes a few other changes: > >> > >> > >> https://salsa.debian.org/emacsen-team/emacs-buttercup/-/tree/dh-auto-test-fixes?ref_type=heads > >> > >> Seem reasonable? > > > > Thanks for checking and the fixes! I have removed the package on > > mentors to prevent any premature sponsoring/uploading. > > > > One small suggestion: instead of using a comment, add @echo with the > > message in override_dh_auto_build so that we get this info in the build > > log. > > > > Please feel free to merge to debian/master. > > > > I took the liberty and merged your branch, as well as the small > suggestion from my other email. Thanks again for the fix. > > BTW, will you do the uploading? In which case I'll avoid re-uploading > to mentors. Thanks in advance! Yup. J. signature.asc Description: PGP signature
Bug#1081444: RM: vinagre -- RoM; unmaintained
Package: ftp.debian.org User: ftp.debian@packages.debian.org Usertags: remove Control: affects -1 src:vinagre X-Debbugs-Cc: vina...@packages.debian.org Please remove vinagre. Its last upstream release was 8 years ago. It has been archived which means bug reports, bug fixes, and translation updates are no longer accepted. vinagre currently fails to build because gcc-14 is stricter. Even more pressing is that vinagre uses freerdp2 which will be removed from Debian "soon" in favor of freerdp3. There are several actively maintained replacement apps packaged in Debian including Remmina and GNOME Connections. https://gitlab.gnome.org/GNOME/vinagre On behalf of the Debian GNOME team, Jeremy Bicha
Bug#1081440: gnome-settings-daemon: test failure on arm64: Lid: timed out waiting for unblank
Yes, I saw the power lid test failure once in a PPA with amd64 and I believe Simon saw it at least once with his sbuild. Thank you, Jeremy Bícha
Bug#1076283: poppler-utils: (pdfimages) the working sample is attached
Sorry, I have almost no time to help with poppler rendering issues on Debian Stable. Could you try with Debian Testing (or Unstable) which has poppler 24.08 (August 2024)? You could use a virtual machine to not disrupt your existing Debian Stable install. If the bug still exists there, please report the issue upstream: https://gitlab.freedesktop.org/poppler/poppler/-/issues Thank you, Jeremy Bícha
Bug#1081352: python-aiohomekit: Depends on aiocoap which FTBFS
Source: python-aiohomekit Version: 3.2.1-2 Severity: serious python-aiohomekit's dependency aiocoap fails to build from source. Therefore, it is not possible for python-aiohomekit to migrate to Testing. Thank you, Jeremy Bícha
Bug#1081351: unicode-data: Please update for the new 16.0 release
Source: unicode-data Version: 15.1.0-1 Severity: wishlist Unicode 16 was released today. https://blog.unicode.org/2024/09/announcing-unicode-standard-version-160.html https://blog.emojipedia.org/whats-new-in-unicode-16-0/ Please package the new release in experimental. We need to coordinate a transition but this is an important first step. See https://bugs.debian.org/1052191 Thank you, Jeremy Bícha
Bug#1081350: RM: vowpal-wabbit -- RoQA; FTBFS, unmaintained in Debian
Package: ftp.debian.org User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: vowpal-wab...@packages.debian.org Control: affects -1 src:vowpal-wabbit Control: block 1060453 by -1 Please remove vowpal-wabbit from Debian because it is blocking the boost1.74 transition. Additionally, it has been failing to build for a while. It missed the time transition earlier this year. It last upload was in 2018, despite upstream continuing to make releases: https://github.com/VowpalWabbit/vowpal_wabbit/tags Thank you, Jeremy Bicha
Bug#1081348: RM: openems -- RoQA; FTBFS; blocking boost1.74 removal
Package: ftp.debian.org User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: open...@packages.debian.org Control: affects -1 src:openems Control: block 1060453 by -1 Please remove openems from Debian. It has been failing to build since October 2023. Before that, it had received 2 NMUs to keep it building. Its last maintainer upload was in early 2021. More importantly, it is blocking the removal of boost1.74. Thank you, Jeremy Bicha
Bug#1081347: vg: intent to file removal bug
Source: vg Version: 1.30.0+ds-1 Severity: serious I intend to file a removal bug for vg soon. It is blocking the removal of boost1.74 from Debian. https://bugs.debian.org/1060453 Thank you, Jeremy Bícha
Bug#1081346: RM: slic3r [i386] -- RoQA; NBS
Package: ftp.debian.org User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: sli...@packages.debian.org Control: affects -1 src:slic3r Control: block 1060453 by -1 Please remove slic3r binaries on i386. It hasn't built on that architecture in Unstable this year or in 2023. It has no reverse dependencies, only a reverse Recommends from 2 binaries built by printrun. Thank you, Jeremy Bicha
Bug#1081345: RM: slic3r-prusa [s390x] -- RoQA; NBS
Package: ftp.debian.org User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: slic3r-pr...@packages.debian.org Control: affects -1 src:slic3r-rusa Control: block 1060453 by -1 Please remove slic3r-prusa's binaries on s390x. It hasn't built on that architecture in Unstable this year. The package has no reverse dependencies and it is blocking the removal of boost1.74. Thank you, Jeremy Bicha
Bug#1081250: RM: llvm-toolchain-17 -- ROM; Too many version of llvm
Control: tags -1 +moreinfo Please remove the moreinfo tag once this is ready for removal. Thank you, Jeremy Bícha
Bug#1081113: RFS: emacs-buttercup/1.36-1 -- behaviour-driven testing for Emacs Lisp packages
On 2024-09-07, at 22:50:28 -0700, Xiyue Deng wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "emacs-buttercup": > > * Package name : emacs-buttercup >Version : 1.36-1 >Upstream contact : Jorgen Schaefer > * URL : https://github.com/jorgenschaefer/emacs-buttercup/ > * License : GPL-3+, GFDL-1.2+ or CC-BY-SA-3.0 > * Vcs : https://salsa.debian.org/emacsen-team/emacs-buttercup >Section : lisp > > The source builds the following binary packages: > > elpa-buttercup - behaviour-driven testing for Emacs Lisp packages > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/emacs-buttercup/ > > Alternatively, you can download the package with 'dget' using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/e/emacs-buttercup/emacs-buttercup_1.36-1.dsc > > Changes since the last upload: > > emacs-buttercup (1.36-1) unstable; urgency=medium > . >* New upstream release This doesn't work: >* Drop override_dh_auto_test to use default dh_elpa_test dh_elpa_test only runs a package's test-suite if the package build- depends on elpa-buttercup. Since this is the source package for elpa-buttercup, that is not the case, and dh_elpa_test exits without doing anything. Because we can't use dh_elpa_test, we also can't do this: >* Drop setting EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION now it is the > default As it happens, the existing dh_auto_test override doesn't actually work any more: the upstream code has changed sufficiently that it just loads tests/test-buttercup.el without actually running any tests. However, the default make target, "all", has no rules and one dependency on a target that _does_ run the full test-suite, so dh_auto_build has been running it instead by accident. My suggestion, therefore, is to skip dh_auto_build, remove the dh_auto_test override, and let dh_auto_test just run `make check`. I have pushed a branch to Salsa that implements this and makes a few other changes: https://salsa.debian.org/emacsen-team/emacs-buttercup/-/tree/dh-auto-test-fixes?ref_type=heads Seem reasonable? >* Update d/watch with filenamemangle for generating sane package name >* Update Standards-Version to 4.7.0; no change needed J. signature.asc Description: PGP signature
Bug#1081284: setuptools: Causes build failures in things using gobject-introspection
Control: reassign -1 src:gobject-introspection 1.80.1-3 Control: fixed -1 src:gobject-introspection/1.81.4-1 Control: affects -1 src:setuptools Control: forwarded -1 https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/515 I'm going to try to fix this issue in the gobject-introspection packaging. Thank you, Jeremy Bícha
Bug#1081284: setuptools: Causes build failures in things using gobject-introspection
Source: setuptools Version: 74.1.2-1 Severity: grave Tags: ftbfs Control: affects -1 src:gobject-introspection, src:webkit2gtk Yesterday's upload of setuptools is causing several packages to fail to build. A few examples: webkit2gtk on all https://buildd.debian.org/status/package.php?p=webkit2gtk gnome-bluetooth3 on Ubuntu (and Debian Experimental): https://launchpad.net/ubuntu/+source/gnome-bluetooth3/47~rc-1 This is the build error: Traceback (most recent call last): File "/usr/bin/g-ir-scanner", line 103, in from giscanner.scannermain import scanner_main File "/usr/lib/x86_64-linux-gnu/gobject-introspection/giscanner/scannermain.py", line 35, in from giscanner.ast import Include, Namespace File "/usr/lib/x86_64-linux-gnu/gobject-introspection/giscanner/ast.py", line 27, in from .sourcescanner import CTYPE_TYPEDEF, CSYMBOL_TYPE_TYPEDEF File "/usr/lib/x86_64-linux-gnu/gobject-introspection/giscanner/sourcescanner.py", line 25, in from .ccompiler import CCompiler File "/usr/lib/x86_64-linux-gnu/gobject-introspection/giscanner/ccompiler.py", line 29, in from distutils.msvccompiler import MSVCCompiler ModuleNotFoundError: No module named 'distutils.msvccompiler' This happens with both 74.1.2-1 and 74.1.2-2. Thank you, Jeremy Bícha
Bug#1071322: Bug#1068782: Bug#1071322: News on those issues?
My dev machine is currently DOA, and I'm still working on rebuilding it. On Sat, Sep 7, 2024 at 3:39 AM Salvatore Bonaccorso wrote: > Hi Jeremy, > > On Thu, Aug 01, 2024 at 07:22:34AM +0200, Salvatore Bonaccorso wrote: > > Hi Jeremy, > > > > On Sun, Jun 30, 2024 at 02:47:41PM +0200, Salvatore Bonaccorso wrote: > > > Hi Jeremy, > > > > > > On Mon, Jun 17, 2024 at 04:31:04PM -0400, Jeremy T. Bouse wrote: > > > > Upstream had been MIA for years; its last release was in 2010. It > appears > > > > he has finally returned, but I haven't had time to deal with the new > > > > version that was released two weeks ago. > > > > > > Thanks for the answer. > > > > > > Question: will you find time to deal with those issues, before 17th of > > > upciming month? Because then libesmtp and reverse dependencies will be > > > removed otherwise from trixie. > > > > FWIW, libesmtp and its reverse dependencies are now removed from > > testing, so I'm pretty much interested seeing it in trixie. > > > > Upstream has not responded to the Ubuntu proposed patches in > > https://github.com/libesmtp/libESMTP/issues/21 . > > > > Can you try to approach upstream to see if upstream can deal with the > > issue in their preferred way and we can cherry-pick the fixes as > > needed? > > Any news here? Currently libesmtp and reverse dependencies are out of > Debian trixie/testing and the package needs to come back before the > freeze. > > Regards, > Salvatore > -- Jeremy T. Bouse Sr. DevOps Engineer 321.525.3280 UnderGrid.net <https://undergrid.net/> <https://www.credly.com/badges/69208741-17c8-4876-a5c0-bcaa9078ba29> <https://www.credly.com/badges/8613a442-3830-42c9-a629-8e1576dfec5e>
Bug#1081135: RM: autoconf2.13 -- RoQA; severely outdated package
Control: tags -1 +moreinfo Please remove the moreinfo tag once the blocking bugs are fixed. Thank you, Jeremy Bícha
Bug#1081051: RM: mozjs102 -- RoM; unmaintained, use mozjs128 instead
Package: ftp.debian.org User: ftp.debian@packages.debian.org Usertags: remove Control: affects -1 src:mozjs102 X-Debbugs-Cc: mozjs...@packages.debian.org Please remove mozjs102 mozjs is the SpiderMonkey JavaScript engine for Firefox. mozjs102 is from Firefox ESR 102 which is no longer supported. It has no remaining reverse dependencies in Unstable. The supported alternative is mozjs128. mozjs115 is also in Debian Unstable and Testing and was originally expected to reach End of Life this month, but it will apparently be supported until March for old Windows and macOS. https://bugs.debian.org/1081040 On behalf of the Debian GNOME team, Jeremy Bicha
Bug#1078326: tilix: no badge with libvte-2.91-0.77.91-2
Control: severity -1 important Well, it has been a month and we can't indefinitely keep the new vte2.91 from migrating to Testing so I'm downgrading this bug. Thank you, Jeremy Bícha
Bug#1081040: mozjs115: Linux is no longer supported upstream
Source: mozjs115 Version: 115.14.0-1 Severity: important Control: block -1 by 1081039 mozjs is the SpiderMonkey JavaScript engine from Firefox ESR. Firefox ESR 115 was scheduled to have its final release, 115.15, this week. However, support has now been extended only for old WIndows and macOS versions until March 2025. https://whattrainisitnow.com/release/?version=esr Now that mozjs128 is available, we should remove mozjs115. This is blocked because Debian's cjs uses mozjs115. Thank you, Jeremy Bícha
Bug#1081039: cjs: Please switch to mozjs128
Source: cjs Version: 6.2.0-2 Severity: important Tags: upstream Control: affects -1 src:mozjs115 The End of Life for mozjs115 was scheduled to be in September 2024. Mozilla have recently announced that End of Life has been extended but support is only provided for old versions of Windows and macOS. mozjs128 is the current version of mozjs and is not scheduled to reach End of Life until September 2025. https://whattrainisitnow.com/release/?version=esr The latest development release of gjs, 1.81.90, has support for mozjs115. The next stable version of gjs, 1.82.0 is expected in about a week. Note that mozjs128 is currently not built on armel. If that is not fixed, then more work will be needed to remove cinnamon on armel. See https://bugs.debian.org/1080521 Thank you, Jeremy Bícha
Bug#1081038: RM: mozjs105 -- RoM; unmaintained, use mozjs128 instead
Package: ftp.debian.org User: ftp.debian@packages.debian.org Usertags: remove Control: affects -1 src:mozjs105 X-Debbugs-Cc: mozjs...@packages.debian.org Please remove mozjs105. mozjs is the SpiderMonkey JavaScript engine for Firefox. mozjs105 is from Firefox ESR 105 which is no longer supported. It has no remaining reverse dependencies in Unstable. The supported alternative is mozjs128. mozjs115 is also in Debian Unstable and Testing and was originally expected to reach End of Life this month, but it will apparently be supported until March for old Windows and macOS. On behalf of the Debian GNOME team, Jeremy Bicha
Bug#1081016: mutter: keybindings autopkgtest fails because it needs compiled org.gnome.mutter.test gsettings schema
I have now fixed the other autopkgtest failures in Salsa. Thank you, Jeremy Bícha
Bug#1081016: mutter: keybindings autopkgtest fails because it needs compiled org.gnome.mutter.test gsettings schema
Source: mutter Version: 47~rc-1 Severity: serious mutter added new installed tests in 47~rc that we then run as autopkgtests. They asked me before and I said it was ok. One of the new tests is a keybindings test that depends on a gsettings schema org.gnome.mutter.test . That schema is installed by upstream to /usr/share/mutter-15/tests/org.gnome.mutter.test.gschema.xml If mutter is built first, that gsettings schema is compiled by meson and works. But that doesn't happen when it's run as an autopkgtest. Off the top of my head, I'm not sure how to compile this gsettings schema where we need it. There are other installed tests that need access to regular gsettings schemas. The test is mutter-15/keybindings.test and the source code is src/tests/keybindings.c Thank you, Jeremy Bícha
Bug#1072124: gnome-shell: CVE-2024-36472
On Sat, Aug 17, 2024 at 8:45 AM Salvatore Bonaccorso wrote: > That said, as mentioned in the notes of the CVE, no DSA is planned but > a fix could be done via an upcoming point release. We ran out of time with other priorities to copy Ubuntu's gnome-shell hardening into Debian 12.7. There is probably enough time to get it into Debian 12.8 since 12.8 won't be released until at least late October. I'm landing the changes in the 47 packaging for Experimental now and then we need to either get 47 into Unstable (my preference) or cherry-pick them for the 46 packaging. https://ubuntu.com/security/notices/USN-6963-1 Thank you, Jeremy Bícha
Bug#1080477: gtk4: FTBFS on mips64el with Mesa 24.2.x: GALLIUM_DRIVER=softpipe no longer works
Also verified working at https://buildd.debian.org/status/package.php?p=gtk4&suite=experimental Jeremy
Bug#1059000: mutter : Please add support for loong64
Dandan, Thank you for the screenshots and testing. I would prefer to avoid doing further 46.x uploads for mutter; instead I am working to getting GNOME Shell & Mutter 47 into Debian Unstable this month. We are unwilling to completely ignore build test failures. We are going to need a more targeted fix, possibly only ignoring the 2 tests that fail. Here's a snippet from gtk4's debian/rules. Could you try adjusting this for loong64 and see if running the mutter build with softpipe avoids the test failures? ifneq ($(filter mips% powerpc riscv% sparc%,$(DEB_HOST_ARCH_CPU)),) $(info Disabling use of llvmpipe on this CPU, see https://bugs.debian.org/993550 and https://bugs.debian.org/1080435) export GALLIUM_DRIVER=softpipe endif Jeremy Bícha
Bug#1035983: libsoap3 (and libsoap2) autopkgtests are flaky: Address already in use: AH00072: make_sock: could not bind to address 127.0.0.1:47524
On Fri, Sep 6, 2024 at 12:24 AM Michael Tokarev wrote: > > Control: severity -1 important > > After about 1.5 years, I'm pinging this bug and raising its severity. > On almost every samba package upload I have to retry a few libsoup > autopkgtest jobs due to this flakiness, as it fails to verify again > and again and stalls migration of unrelated packages. Also raising > severity here because it affects other, unrelated packages. > > https://ci.debian.net/packages/libs/libsoup3/testing/arm64/51269589/ > https://ci.debian.net/packages/libs/libsoup3/testing/armhf/51269236/ For reference, it looks like the autopkgtests are not failing so frequently as to be especially problematic. https://ci.debian.net/packages/libs/libsoup3/testing/armhf/ https://ci.debian.net/packages/libs/libsoup3/testing/arm64/ Severity important is fine though. Thank you, Jeremy Bícha
Bug#1059000: mutter : Please add support for loong64
On Mon, Sep 2, 2024 at 5:12 AM zhangdandan wrote: > Now, there are still 2 failing tests. > ``` > 182/185 mutter:core+mutter/x11 / x11 > FAIL10.27s (exit status 133 or signal > 5 SIGTRAP) > 183/185 mutter:core+mutter/x11 / x11-sync > FAIL10.27s (exit status 133 or signal > 5 SIGTRAP) > > Ok: 178 > Expected Fail: 5 > Fail: 2 > Unexpected Pass:0 > Skipped:0 > Timeout:0 > > ``` > > Could you add loong64 to the override_dh_auto_test lists in d/rules? Well that is progress. The Debian GNOME team requests that we have some proof that mutter actually works on a non-release architecture before disabling test failures. The goal here from our perspective is not trying to get loong64 to build 99% of Debian packages, but whether those built packages actually are usable. The strongest evidence is if you can show that GNOME Shell works on that architecture. Alternatively, gnome-settings-daemon has build tests that use mutter. Those currently aren't run on several architectures because mutter is so broken that the tests fail. If you can remove the !loong64 overrides from its debian/control so that the mutter tests run and all pass, I think that could be enough evidence too. Thank you, Jeremy Bícha
Bug#1067679: libvte-2.91-0: backspace character (code 8) output at the end of a line goes 2 columns backward
I don't think there is anything we are going to change directly in the vte packaging for this. I suggest closing this bug and working on upstream's bug tracker if you have any remaining or related followup issues? https://gitlab.gnome.org/GNOME/vte/-/issues Thank you, Jeremy Bícha
Bug#1080337: gst-plugins-base1.0: Fails to build with mesa 24.2
Source: mesa Version: 24.2.1-3 Severity: serious Tags: ftbfs Control: affects -1 src:gst-plugins-base1.0 The new version of mesa is causing gst-plugins-base1.0 to fail to build on amd64 because of failing build tests. (Build test failures are currently ignored on other architectures.) See also https://launchpad.net/bugs/2077965 Thank you, Jeremy Bícha
Bug#1080325: libadwaita-1: FTBFS on i386: segfault in test-bottom-sheet
Control: forwarded -1 https://gitlab.gnome.org/GNOME/libadwaita/-/issues/913 On Mon, Sep 2, 2024 at 5:12 AM Simon McVittie wrote: > libadwaita-1 since 1.6~beta-1 failed to build from source on the i386 buildd, > with a test failure that does not seem to occur on any other architecture: I reported this upstream, but I haven't made the time to work on it more thoroughly. Thank you, Jeremy Bícha
Bug#1080310: RM: gnome-shell-mailnag -- RoQA; unmaintained, no longer works with current GNOME Shell
Package: ftp.debian.org User: ftp.debian@packages.debian.org Usertags: remove Control: affects -1 src:gnome-shell-mailnag X-Debbugs-Cc: gnome-shell-mail...@packages.debian.org, b...@debian.org Please remove gnome-shell-mailnag from Debian. - It was orphaned in 2020 https://bugs.debian.org/968541 - It does not currently work https://bugs.debian.org/1078015 - It has been abandoned upstream since 2021 https://github.com/pulb/mailnag-gnome-shell - It actively requires maintenance work for every new major GNOME Shell release twice per year - It depends on mailnag which is also orphaned and abandoned upstream since 2011 Except for one NMU, I have been the sole uploader for the package since 2022. I have confirmed that the last other NMUer, Bage, is ok with this package's removal. I have only been doing uploads to keep the package installable with new GNOME Shell releases; I do not use the package myself. Alternatives --- - Evolution sends desktop notifications - Thunderbird has a Linux system tray: https://www.theregister.com/2024/07/22/mozilla_thunderbird_ffix/ This might require gnome-shell-extension-appindiator - Webmail also generally can send desktop notifications as long as there is a browser tab open for the email service Thank you, Jeremy Bícha
Bug#1080241: debcargo: Use crates.io for Homepage if no other homepage is set
Source: debcargo Version: 2.6.1-6 I suggest that debcargo should use crates.io as the homepage when: - Cargo.toml doesn't set a homepage - and when debian/debcargo.toml doesn't set a homepage This would fix bugs like https://bugs.debian.org/919989 . A lot of Rust crates don't set the homepage and this would make https://tracker.debian.org/ more useful for people who want to click links to find upstream. Thank you, Jeremy Bícha
Bug#1008815: Unable to record screencast: "Error starting screencast"
Control: reopen -1 Actually, this might be the same as https://launchpad.net/bugs/1963264 . At least the GNOME bug there also refers to this Debian bug. We have not yet figured out an appropriate way to fix that issue. Thank you, Jeremy Bícha
Bug#1024531: tasksel: Add task-budgie-desktop
Control: block -1 by 1067117 Currently, budgie-desktop is not buildable or installable in Debian Unstable and therefore has been removed from Debian Testing. After that issue has been fixed, it would be helpful for someone to prepare a merge request to add the appropriate task with dependencies to tasksel. Thank you, Jeremy Bícha
Bug#1071383: gnome-core should recommend network-manager instead of network-manager-gnome
Control: reopen -1 Control: reassign -1 task-gnome-desktop Control: fixed gnome-core/1:47~beta+1 Control: forwarded -1 https://salsa.debian.org/installer-team/tasksel/-/merge_requests/31 I'm reopening and reassigning this issue since to fix this issue properly as intended, we also need to get this fixed in tasksel. I submitted a merge request to fix this and fix another unintended dependency, and hopefully we will have less unintended dependencies in the future. Thank you, Jeremy Bícha
Bug#987882: Printing does not work on a bullseye install with tasksel gnome
This issue was fixed for Debian 12 by making task-gnome-desktop install cups. I am keeping this issue open because I believe that it should be possible to get a fully functional GNOME desktop by installing gnome-core without also installing task-gnome-desktop which currently is not really maintained by the Debian GNOME team. Thank you, Jeremy Bícha
Bug#1050575: gnome randomly ignoring my keybinding settings
Control: tags -1 +moreinfo On Sat, Aug 26, 2023 at 9:48 AM Michael P. Soulier wrote: > Package: gnome > Version: 1:43+1 > Severity: important > X-Debbugs-Cc: msoul...@digitaltorque.ca > > Dear Maintainer, > > I set my keybindings to change workspaces on Super+1 to 4, for each of the 4 > workspaces. Suddenly when I login, Super+3 opens the damned calendar instead. > But that's on a default X session. If I login with Wayland, suddenly 1-3 work > but Super+4 opens my browser. I am unable to reproduce this bug as described with Debian 12.6. Please do see the attached screenshot. By default, Super+3 opens the 3rd favorite/pinned app in the dash (the list of apps at the bottom of the Activities Overview). However, it is possible to override that shortcut. Note that you'll also need to enable a fixed number of workspaces because by default, GNOME only provides one more workspace than currently used by apps. That means that there are only 2 workspaces when you first log in. Go to Settings > Workspaces and switch to Fixed number of workspaces and set the number to 4. If you are still experiencing this issue, try again without any GNOME Shell extensions enabled. GNOME Shell extensions can break the normal functionality of GNOME Shell. If you are still experiencing this issue after all that, please try again from a clean install of Debian GNOME. If the bug happens here, please reply with detailed steps of how to reproduce this issue. Thank you, Jeremy Bícha
Bug#1080214: lomiri-system-settings-security-privacy: Conflicts with lomiri-system-settings
Source: lomiri-system-settings-security-privacy Severity: serious Version: 1.0.2-3 Affects: src:lomiri-system-settings lomiri-system-settings-security-privacy is unable to migrate to Testing because of a piuparts regression. piuparts is detecting that lomiri-system-settings-security-privacy is uninstallable with lomiri-system-settings. lomiri-system-settings 1.2.0-1 sets Breaks: lomiri-system-settings-security-privacy, Replaces: lomiri-system-settings-security-privacy, Provides: lomiri-system-settings-security-privacy, Please clean this up. It appears like you just need to file a removal bug for lomiri-system-settings-security-privacy Thank you, Jeremy Bícha
Bug#984964: gnome: Graphics Card remains black when waking from suspend
There have been many changes to Debian since this bug was originally reported. If you are still experiencing this issue with Debian 12, please report a new bug. Debian 11 has reached regular End of Life. There is still LTS security support for Debian 11, but this doesn't seem like the kind of issue that would be fixed there. https://wiki.debian.org/DebianReleases Thank you, Jeremy Bícha
Bug#1080088: gnome-settings-daemon: Volume is reset to max level on HDMI audio output after unlock
On Fri, Aug 30, 2024 at 8:51 AM George Shuklin wrote: > Package: gnome-settings-daemon > Version: 47~beta-1 > Severity: normal > X-Debbugs-Cc: george.shuk...@gmail.com > > When I lock (or unlock) my computer, the audio volume is set to maximum value, > even if I set it to lower. > > I use HDMI audio from my monitor I do not know all the details of how audio volume is set on a GNOME desktop, but I think this is handled at a lower level like pipewire. Thank you, Jeremy Bícha
Bug#1079950: chafa: Fails to build on some architectures with glibc 2.40
Source: chafa Version: 1.14.2-1 Severity: serious Tags: ftbfs Based on the Ubuntu build logs, I suspect that chafa fails to build on some architectures with glibc 2.40. Note that although chafa was uploaded a few days ago, the new version of glibc was uploaded to Unstable for the first time after that date. Feel free to close this bug if it's verified that chafa does build on all Debian release architectures. Build log excerpt -- /usr/bin/ld: chafa-svg-loader.o: undefined reference to symbol 'lrint@@GLIBC_2.4' /usr/bin/ld: /lib/arm-linux-gnueabihf/libm.so.6: error adding symbols: DSO missing from command line Full build logs https://launchpad.net/ubuntu/+source/chafa/1.14.2-1 Thank you, Jeremy Bícha
Bug#1079702: Both autopkgtest are flaky
On Wed, Aug 28, 2024 at 8:51 AM Johannes Schauer Marin Rodrigues wrote: > That would be odd because the autopkgtest runs just fine and reliable on salsa > ci. But I have to find a better way to automate testing of gtk4 applications > before I tackle this problem again. Taking screenshots via VNC and trying to > find buttons in them is not smart. There is dogtail but I haven't really used it. There is openqa.debian.net but I believe it's not currently connected to britney for blocking migration to Testing. It appears to only current support amd64 and arm64 which may be enough since that's where most of our users are. Since OpenQA also works with screenshots, it is susceptible to changes in fonts, themes, and text rendering although the threshold for how sensitive it is can be modified. Thank you, Jeremy Bícha
Bug#1079702: autopkgtest 'test_without_chroot' is flaky
gtk4 has more failing build tests than other architectures. Unfortunately, we are forced to ignore them because our understanding is that it's currently required for desktop tasks to be installable on all release architectures. (Or I guess someone could fix the bugs but that can be difficult.) If you have screenshots to demonstrate s390x breakage that may be gtk4's fault, please forward them to the Debian bugtracker for gtk4. Thank you, Jeremy Bícha
Bug#1079498: helvum: build against GNOME 47 crates
Control: severity -1 serious On Fri, Aug 23, 2024 at 7:15 PM Jonas Smedegaard wrote: > Quoting Jeremy Bícha (2024-08-24 00:40:40) > > Source: helvum > > Version: 0.5.1+20240328-3 > > Tags: ftbfs experimental patch > > X-Debbugs-CC: werdah...@riseup.net > > > > In my followup email, I'm attaching patches for helvum to build > > against the new rust-gtk 0.9 stack, currently in Experimental. We'll > > be uploading the packages to Unstable soon which will then mean helvum > > will fail to build. I don't think there is a lot of benefit to > > uploading helvum to Experimental now but you can if you want. > > Thanks! > > I'll wait until it breaks and fix it then. > > Patches much appreciated! I uploaded rust-gtk4 0.9 to Unstable today. Therefore, I'm raising the severity. I included patches with a previous email. Thank you, Jeremy Bícha
Bug#1079332: reform-setup-wizard: upcoming rust-gtk4 update
Control: severity -1 serious Control: tags -1 +ftbfs On Thu, Aug 22, 2024 at 3:21 PM Matthias Geiger wrote: > On 22.08.24 17:53, Johannes Schauer Marin Rodrigues wrote: > > thank you! Do you have any preference when I upload r-s-w with your patch? > > Feel > > free to ping me whenever you'd like me to make that upload. > > Since I will likely be on vacation I can't really tell. I CC'd jbicha > who is working with me on this update. > > it will definitly land sometime in the next two weeks; I can ping back > here one we start uploading it to unstable. We are uploading rust-libadwaita 0.7 to Unstable today. Therefore, I am raising the severity. Thank you, Jeremy Bícha
