Bug#1072679: ITP: papers -- PDF document viewer for GNOME
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org Control: affects -1 src:papers Owner: jeremy.bi...@canonical.com Package Name: papers Version: 46.1 Upstream Author: Pablo Correa Gómez, Markus Göllnitz, Evince authors License: GPL-2+ Programming Lang: C and Rust Description: PDF document viewer for GNOME Papers is a simple multi-page document viewer. It can display and print DjVu, Portable Document Format (PDF) and XML Paper Specification (XPS) files. When supported by the document, it also allows searching for text, copying text to the clipboard, hypertext navigation, and table-of-contents bookmarks. Other Info -- Papers is a fork of Evince. Papers uses GTK4 and libadwaita (evince uses GTK3). The app now uses Rust for some features. Papers has been proposed to replace Evince as the default PDF viewer for GNOME 47. Evince is not just an app but also libraries for other apps to support PDF (etc.) viewing. Papers also provides those libraries but they have been renamed and use GTK4 now. Those other apps may not be ready for GTK4 yet so we will keep the Evince libraries available for Debian 13. It hasn't yet been finalized what formats the app will support beyond PDF. DVI support has been dropped upstream. Debian, like most distros, has continued to enable viewing PostScript files in Evince although the Evince developers have disabled that by default for years. This package will be maintained by the Debian GNOME team. Packaging will be at https://salsa.debian.org/gnome-team/papers The upstream source is at https://gitlab.gnome.org/GNOME/Incubator/papers Thanks, Jeremy Bícha
Re: Mandatory LC_ALL=C.UTF-8 during package building
I believe debhelper already sets LC_ALL=C.UTF-8 for the cmake, meson, and ninja buildsystems; therefore many but definitely not all packages are already built with LC_ALL=C.UTF-8. Thank you, Jeremy Bícha
Bug#1072711: ITP: localsearch -- rename of tracker-miners
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org Control: affects -1 src:tracker-miners Owner: jeremy.bi...@canonical.com Package Name: localsearch Version: 3.8 (not yet released yet) Upstream Author: Sam Thursfield, Carlos Garnacho and others License: GPL-2+ (some parts are LGPL-2.1+) Programming Lang: C Description: metadata database, indexer and search tool - filesystem indexer This package contains the indexer for indexing your files and folders. . localsearch is an advanced framework for first class objects with associated metadata and tags. It provides a one stop solution for all metadata, tags, shared object databases, search tools and indexing. . localsearch was previously known as Tracker Miners. Other Info -- localsearch is a rename of the tracker-miners file indexer included by default in GNOME. The primary driver for this rename is that privacy-conscious curious users are disturbed by the persistent background process named tracker-miner-fs-3. It sounds like something is tracking users perhaps for malicious reasons. Miner brings to mind cryptocurrency miners that could have been installed without authorization. Concerned users can complain or may try to disable or remove these services and break core functionality of their desktop environment. The Debian GNOME team intends to package localsearch (and the tracker replacement named tinysparql) in Experimental probably in July. The intent is for the new binary packages to replace the existing tracker-miners packages. We expect to do the transition in Unstable later in the year. https://gitlab.gnome.org/GNOME/tracker-miners/-/issues/346 Thanks, Jeremy Bícha
Bug#1072712: ITP: tinysparql -- rename of tracker
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org Control: affects -1 src:tracker Owner: jeremy.bi...@canonical.com Package Name: tinysparql Version: 3.8 (not yet released yet) Upstream Author: Sam Thursfield, Carlos Garnacho and others License: GPL-2+. Library: LGPL-2.1+ Programming Lang: C Description: metadata database, indexer and search tool TinySPARQL is an advanced framework for first class objects with associated metadata and tags. It provides a one stop solution for all metadata, tags, shared object databases, search tools and indexing. . TinySPARQL was previously known as Tracker. Other Info -- TinySPARL is a rename of the Tracker file indexer included by default in GNOME. The primary driver for this rename is that privacy-conscious curious users are disturbed by the persistent background process named tracker-miner-fs-3. It sounds like something is tracking users perhaps for malicious reasons. Miner brings to mind cryptocurrency miners that could have been installed without authorization. Concerned users can complain or may try to disable or remove these services and break core functionality of their desktop environment. The Debian GNOME team intends to package tinysparql (and the tracker-miners replacement named localsearch) in Experimental probably in July. The intent is for the new binary packages to replace the existing tracker packages. We expect to do the transition in Unstable later in the year. https://gitlab.gnome.org/GNOME/tracker/-/issues/437 Thanks, Jeremy Bícha
Re: DD's, Debian Mentors needs you!
On Sat, Jul 6, 2024 at 9:46 AM Phil Wyett wrote: > Debian Mentors[1] always struggles to find available Debian Developers for > final reviewing and > sponsoring of packages submitted too our part of the project. One thing that has disrupted my use of https://mentors.debian.net/ for sponsoring is that I am unable to log in. I don't get any of the "sign up" or "reset password" emails. Thank you, Jeremy Bícha
Bug#1076037: ITP: mozjs128 -- SpiderMonkey JavaScript library
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org Control: affects -1 src:mozjs128 Owner: jeremy.bi...@canonical.com Package Name: mozjs128 Version: 128.0.0 Upstream Author: Mozilla etc License: mostly MPL-2.0, other files are licensed under other open source licenses Programming Lang: C++ Description: SpiderMonkey JavaScript library SpiderMonkey is the code-name for Mozilla Firefox's C++ implementation of JavaScript. It is intended to be embedded in other applications that provide host environments for JavaScript. . This library is intended for use in contexts where only trusted JavaScript code will be run, such as GNOME's gjs, Cinnamon's cjs, and polkit's rules parsing. It should not be used to run untrusted JavaScript from web pages: use a security-supported implementation such as Firefox, Chrome or WebKitGTK's JavaScriptCore instead. Other Info -- mozjs is the JavaScript engine from Firefox ESR. Today, a new Firefox ESR series was released. It will be supported by Mozilla for about 14 months. It is likely but not yet certain that GNOME 47, specifically gjs 1.82, will switch from mozjs115 to mozjs128. If that happens, the next major release of Debian (Debian 13 "Trixie") will include mozjs128. The other user of mozjs* in Debian is Cinnamon, specifically their cjs fork of gjs. Based on previous history, it is expected that cjs will continue to use mozjs115 for Debian 13. mozjs102 will be removed from Debian Unstable once cjs 6.2 reaches Unstable which is expected to happen "soon". References -- https://gitlab.gnome.org/GNOME/gjs/-/merge_requests/936 https://whattrainisitnow.com/calendar/ Thanks, Jeremy Bícha
Re: Intent to MBF: move from fuse to fuse3
On Thu, Aug 29, 2024 at 2:56 PM László Böszörményi (GCS) wrote: > On Sun, Aug 25, 2024 at 11:14 PM Chris Hofstaedtler wrote: > > Yeah, I agree. Do you want to upload a new src:fuse package dropping > > the fuse binary package? > > fuse3 already Provides: fuse, so that should be fine. > The question is, how many dependent packages use the binaries from > the fuse package or just depend on it. Sure, fuse3 provides fuse but > the names of the binaries are different. For example scripts need to > update fusermount call to fusermount3 call. As such, it might be > better to ping maintainers of those packages about dropping the fuse > binary for testing their packages first. Then after a month actually > drop it. On the other hand, I've read reports of people breaking their systems because they install fuse which uninstalls fuse3 (perhaps because they are trying to install libfuse2 to get AppImages to work or perhaps because fuse is a generic name). So I'd rather we got rid of the old fuse binary package quicker. https://launchpad.net/bugs/1978310 Although I guess it would be a lot of work to fix that for Debian 12. :( Thank you, Jeremy Bícha
Bug#1036767: ITP: d-spy -- D-Bus explorer and test app for GNOME
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org Owner: jeremy.bi...@canonical.com Package Name: d-spy Version: 1.6.0 Upstream Author: Christian Hergert License: GPL-3+ Programming Lang: C Description: D-Bus explorer and test app for GNOME D-Spy is a tool to explore and test end-points and interfaces on the System or Session D-Bus. You can also connect to D-Bus peers by address. . D-Spy was originally part of the GNOME Builder app. Other Info -- This package will be maintained by the Debian GNOME team. Packaging is at https://salsa.debian.org/gnome-team/d-spy D-Spy is a maintained alternative to the D-Feet app. D-Spy uses GTK4 and libadwaita. D-Spy also provides a library that is used to provide its features integrated into the GNOME Builder app. Thanks, Jeremy Bícha
Re: Future of GNU/kFreeBSD in the debian-ports archive
If and when GNU/kFreeBSD is dropped from debian-ports, is it ok to drop packaging overrides for the architecture from packages in Unstable? Thank you, Jeremy Bícha
Bug#1037262: ITP: syndication-domination -- Python 3 library for parsing RSS and ATOM feeds
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org Owner: jeremy.bi...@canonical.com Control: blocks 1019356 by -1 Package Name: python3-syndom Version: 1.0 Upstream Author: GabMus License: AGPL-3 Programming Lang: C++ (but bindings are for Python 3 Description: Python 3 library for parsing RSS and ATOM feeds syndication-domination is a Python 3 library for parsing RSS and ATOM feeds. Other Info -- This package will be maintained by the Debian Python team. Packaging is at https://salsa.debian.org/python-team/packages/syndication-domination It is a required dependency for newer versions of the GNOME Feeds app. There are C++ header files but the upstream installer does not install them. Since nothing in Debian is using them, I am only packaging the Python3 library at this time. Thanks, Jeremy Bicha
Re: When a magpie is not a magpie
On Fri, Jun 30, 2023 at 6:27 PM David Mohammed wrote: > On examining the upload, mentors' automatic checks tells me that there > is already a package in debian with a last upload date of 2003 https://ftp-master.debian.org/removals-2003.txt says magpie was removed in December 2003 so Debian 3.0 Woody was the last release to include it. That was before the amd64 architecture was introduced. My opinion is that you are more than ok to name your source package magpie. I see that the version number is higher than the old magpie which is helpful for Launchpad (although the old magpie predates Ubuntu). Thank you, Jeremy Bícha
Re: ITP: discord a modern voice & text chat app
On Sat, Jul 1, 2023 at 12:27 AM matt quintanilla wrote: > Package: discord > Severity: ITP This is not the correct way to file an ITP report. Could you install reportbug and and run reportbug using the package name wnpp? And then follow the prompts. By the way, I believe discord is not suitable for packaging in Debian main since it does not follow the Debian Free Software Guidelines. However, it may be possible to package it in non-free. https://wiki.debian.org/DebianFreeSoftwareGuidelines Please also see the Debian Mentors pages where there is some help for packaging things for Debian: https://mentors.debian.net/ Thank you, Jeremy Bícha
Bug#1040590: ITP: tecla -- keyboard layout viewer for the GNOME desktop
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org Owner: jeremy.bi...@canonical.com Package Name: tecla Version: 45~alpha Upstream Author: Red Hat License: GPL-2+ Programming Lang: C Description: keyboard layout viewer for the GNOME desktop This app is a basic keyboard layout viewer for integration with the GNOME desktop. Other Info -- This package will be maintained by the Debian GNOME team. Packaging is at https://salsa.debian.org/gnome-team/tecla It is expected that Tecla will be a dependency of GNOME Shell & the GNOME Settings app (gnome-control-center) for GNOME 45 later this year. Tecla is a basic app written in GTK4 & libadwaita and would replace gkbd-capplet (provided by libgnomekbd) for the GNOME desktop. Thanks, Jeremy Bícha
Re: Bug#1040590: ITP: tecla -- keyboard layout viewer for the GNOME desktop
By the way, there is an existing old unrelated libtecla package in Debian. Upstream for new Tecla does not believe there will be a name conflict. https://gitlab.gnome.org/GNOME/tecla/-/issues/6 Thank you, Jeremy Bícha
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Wed, Jul 12, 2023 at 8:32 AM Lukas Märdian wrote: > (We're also working on a bidirectional Netplan-NetworkManager integration, > that allows NM to feed back it's configuration into Netplan YAML format. It is > a small patch for NetworkManager and is purely optional.) Does that already exist in Ubuntu 23.10 "Mantic"? Thank you, Jeremy Bícha
Re: virtual packages for Ada libraries
On Sun, Jul 16, 2023 at 7:50 AM Jonas Smedegaard wrote: > I now recall: The Rust library packages wreaking havoc by prematurely > entering testing is (at least partly) due to the Rust team choosing to > flag all(!) autopkgtests as flaky, so not really a concern for other > teams (read: just don't take inspiration from that particular pattern). They aren't all flaky but skip-not-installable is used frequently. Thank you, Jeremy Bícha
Bug#1043464: ITP: libpeas2 -- application plugin library
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org Owner: jeremy.bi...@canonical.com Package Name: libpeas2 Version: 1.99.0 Upstream Author: Garret Regier, et al. License: LGPL-2.1+ Programming Lang: C (also Python3, JavaScript, Lua) Description: Application plugin library libpeas-2 is a library that allows applications to support plugins. Other Info -- This package will be maintained by the Debian GNOME team. Packaging is at https://salsa.debian.org/gnome-team/libpeas2 This is a new API for libpeas. It drops the GTK3 dependency and support so I don't think it's very practical for most reverse dependencies to switch to the new libpeas until they are ready to upgrade away from GTK3. Therefore, we will need to keep both versions of libpeas in Debian. Currently, the only thing I know of that uses libpeas2 is GNOME Builder 45. Thanks, Jeremy Bícha
Bug#1050241: ITP: libei -- Emulated Input client library
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debia...@lists.debian.org Owner: tjaal...@debian.org Control: block 1050237 by -1 Package Name: libei Version: 1.0.0 Upstream Author: Red Hat License: Expat Programming Lang: C Description: Emulated Input client library libei is a library for Emulated Input, primarily aimed at the Wayland stack. It provides three parts: - EI (Emulated Input) for the client side (libei) - EIS (Emulated Input Server) for the server side (libeis) - oeffis for D-Bus communication with the XDG RemoteDesktop portal Other Info -- This package will be maintained by the Debian X Strike Force team. Packaging is at https://salsa.debian.org/xorg-team/lib/libei This is a new required dependency for Mutter 45. I believe GNOME Remote Desktop and xdg-desktop-portal-gnome will also be using it soon. More background can be found at the project's website: https://gitlab.freedesktop.org/libinput/libei Thanks, Jeremy Bícha
Bug#1054416: ITP: errands -- simple tasks app for GNOME
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org Owner: jeremy.bi...@canonical.com Package Name: errands Version: 45.0.4 Upstream Author: Vlad Krupinskii License: Expat Programming Lang: Python Description: Simple tasks app for GNOME Errands is a todo app for those who prefer simplicity. It can optionally sync with a CalDAV or NextCloud server. . Errands is a GNOME Circle app. Other Info -- This package will be maintained by the Debian GNOME team. Packaging is at https://salsa.debian.org/gnome-team/errands Thanks, Jeremy Bícha
Bug#1056757: ITP: solanum -- simple pomodoro time tracking app for GNOME
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org Control: affects -1 src:solanum Owner: jeremy.bi...@canonical.com Package Name: solanum Version: 5.0.0 Upstream Author: Christopher Davis License: GPL-3+ Programming Lang: Rust Description: simple pomodoro time tracking app for GNOME Solanum is a time tracking app using the pomodoro technique. Work in four sessions, with breaks in between each session and one long break after all four. Other Info -- This package will be maintained by the Debian GNOME team. Packaging is at https://salsa.debian.org/gnome-team/solanum Thanks, Jeremy Bícha
Re: Bug#1056757: ITP: solanum -- simple pomodoro time tracking app for GNOME
On Sat, Nov 25, 2023 at 5:51 PM David Bremner wrote: > > Jeremy Bícha writes: > > > > Package Name: solanum > > Version: 5.0.0 > > Upstream Author: Christopher Davis > > License: GPL-3+ > > Programming Lang: Rust > > > > Description: simple pomodoro time tracking app for GNOME > > Solanum is a time tracking app using the pomodoro technique. > > Work in four sessions, with breaks in between each session and > > one long break after all four. > > I note that solanum-ircd is a thing (although not yet in Debian). I > guess first come first serve for the name, but it does turn out to be > surprisingly generic (at least a scan of github reveals several other > projects with the same name). Solanum is a GNOME Circle app so we could perhaps use gnome-solanum for the source and binary package names . I don't think it's necessary to rename /usr/bin/solanum though. Repology also notes the name conflict and suggests "solanum-pomodoro"; however, it looks like no other distro has adopted the name gnome-solanum or solanum-pomodoro. The AUR has at least used solanum-ircd. https://repology.org/project/solanum/versions Thank you, Jeremy Bícha
Bug#1061394: ITP: langtable -- Python 3 library for guessing locale defaults
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org Control: affects -1 src:langtable Owner: jeremy.bi...@canonical.com Package Name: langtable Version: 0.0.64 Upstream Author: Mike Fabian License: GPL-3+ Programming Lang: Python 3 Description: Python 3 library for guessing locale defaults langtable is a Python 3 library that guesses reasonable defaults for locale, keyboard, territory, etc. based on the information already known. Other Info -- This package will be maintained by the Debian Python team. Packaging is at https://salsa.debian.org/python-team/packages/langtable langtable is a proposed build dependency for the gnome-desktop library Thanks, Jeremy Bícha
Re: icc-profiles_2.2_source.changes REJECTED
On Fri, Mar 3, 2023 at 5:58 PM Bastien Roucariès wrote: > Le vendredi 3 mars 2023, 22:35:24 UTC Jonas Smedegaard a écrit : > > Quoting Bastien Roucariès (2023-03-03 22:21:49) > > > Le lundi 27 février 2023, 12:11:27 UTC Jonas Smedegaard a écrit : > > > Hi jonas, > > > > > > I have just checked the source code of lintian. Could you double check > > > your package and create a simple test case ? > > > > > > According to: > > > https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Files/NonFree.pm#L91 > > > The test should not raise > > > > Sorry, I don't understand what you ask me to do. > > > > In case it was unclear from my previous posts: The rejection messages I > > shared was not from a lintian check done locally by me, but a rejection > > message I received from ftpmaster. > > > > Locally I did not experience the same messages. Are you asking me to > > test again that I (again) do not experience the kind of messages that > > ftpmasters for some reason unknown to me trigger? > > Yes could you double check ? > > If you do not experience the kind of messages with locally installed lintian, > it means that lintian need to be backported and that ftpmaster should install > a backport version. I am still getting the LIntian autoreject for thawab for license-problem-md5sum-non-free. It is especially annoying that current Lintian does not emit this error or even a warning because it knows that thawab is in non-free. This is blocking me from being able to fix a RC bug in thawab unless I repack the tarball which seems like a lot of work for a package that is in non-free and a version that is **already in the archives**. I originally tried to fix this RC bug a year ago but my upload was auto-rejected then and I forgot to mark this issue for followup. It was an early enough upload that thawab could have landed in Debian 12. https://alioth-lists.debian.net/pipermail/debian-islamic-maintainers/2023-January/004920.html Thank you, Jeremy Bícha
Re: icc-profiles_2.2_source.changes REJECTED
On Wed, Jan 24, 2024 at 9:48 PM Jonas Smedegaard wrote: > For the record I have not heard from ftpmasters on this issues, and I > know only what is in this public mailinglist thread. > > Obviously I would be happy to be able to maintain the package that I am > listed as maintainer of. And if that for some reason is unreasonable of > me to expect then I would appreciate an explanation why. I found https://bugs.debian.org/1021999 which suggests that DSA is responsible for maintaining the version of lintian used for the upload queue. Do you want to contact them about our request for an upgrade? Thank you, Jeremy Bícha
Bug#1062324: ITP: msgraph -- library to access MS Graph API for Office 365
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org Control: affects -1 src:msgraph Owner: jeremy.bi...@canonical.com Package Name: msgraph Version: git snapshot Upstream Author: Jan-Michael Brummer License: LGPL-3+ Programming Lang: C Description: library to access MS Graph API for Office 365 (long description to be added later) Other Info -- msgraph is a new library from a Volkswagen developer that is basically a replacement for libzapojit (which has been removed from Debian). msgraph is a new dependency for GNOME 46, needed to enable Microsoft OneDrive support in apps like the file browser. This is similar to the existing Google Drive support. This package will be maintained by the Debian GNOME team. Packaging will be at https://salsa.debian.org/gnome-team/msgraph The upstream source is at https://gitlab.gnome.org/jbrummer/msgraph Thanks, Jeremy Bícha
Re: New requirements for APT repository signing
On Mon, Mar 4, 2024 at 8:40 AM Thorsten Glaser wrote: > Hm. My own private repo should be ok (3072R), but my Launchpad PPAs > incidentally are not okay (1024D). > > Since this comes from Canonical, they really should message all > affected Launchpad users and tell them how to rotate their PPAs’ keys > (I vaguely recall searching for that and not finding it once). It is not possible to rotate your PPA keys yourself, but Canonical is handling it according to https://discourse.ubuntu.com/t/new-requirements-for-apt-repository-signing-in-24-04/42854 Thank you, Jeremy Bícha
Re: Rebuilding old packages to get rid of overalignment on amd64 which reduces ASLR
On Thu, Mar 7, 2024 at 6:06 AM Mathias Krause wrote: > I, thereby, request to rebuild affected packages. We are rebuilding thousands of packages for the ongoing 32-bit time_t transition. Maybe you can propose this again after the rebuilds for that are finished? Thank you, Jeremy Bícha
Re: Rebuilding old packages to get rid of overalignment on amd64 which reduces ASLR
On Tue, Mar 12, 2024 at 9:30 AM Mathias Krause wrote: > That works for me. The 32-bit time_t transition Jeremy mentioned seems > like a good candidate to force a rebuild of a lot of packages. Is there > an ETA for it? I found [1] which mentions to do the transition in > January but we've March already. The time_t transition has already begun but it will probably take weeks more to complete. I recommend subscribing to https://lists.debian.org/debian-devel-announce/ Thank you, Jeremy Bícha
Bug#1068823: (No Subject)
Control: reassign -1 src:apt Control: severity -1 wishlist On Sat, Apr 13, 2024 at 1:00 PM mYnDstrEAm wrote: > Thanks guys, these are very useful methods and I'll mention these as > alternatives to disk cleanups recommended at > https://unix.stackexchange.com/q/774199/233262 (this would probably very > useful to have at places about upgrades failing due to disk space issues even > though people only look these up once the problems already occurred). > > However, the problem of the upgrade requiring more disk space than displayed > at first remains and the command by Zeimetz can't be used with a built-in > rememberable well-known command like sudo apt-get upgrade --stepwise Personally, I don't think a machine that has that limited storage ought to be upgraded using apt from one Debian stable release to another. I suggest upgrading the storage first. If that's not possible, I recommend replacing the OS with a new image of Debian rather than trying to use apt to upgrade a few packages at a time. As has already been mentioned, it is not supported to arbitrarily break apt updates up like that to upgrade from say Debian 12 to the not-yet-released Debian 13. Thank you, Jeremy Bícha
Re: Binary conflict between Midnight Commander and MinIO Client
On Wed, Apr 24, 2024 at 9:42 AM Andreas Tille wrote: > Am Mon, Apr 22, 2024 at 09:28:29AM +0200 schrieb Philip Hands: > > >> /usr/libexec/minio-client/bin/mc -> /usr/bin/mcli > > > > Might I suggest that the link goes the other way, so that the symlink > > lives in /usr/bin? That way the existence of the lib directory is > > somewhat self-documenting. > > That's an interesting hint. In Debian Med we are using a common > directories > > /usr/lib/debian-med/bin/ > /usr/lib/debian-med/man/ > > where those binaries will be moved to and have some kind of a > README.Debian template[1]. Changing this to have the real executable / > manpage to /usr/lib/debian-med/* makes sense. I believe moving those binaries to a subdirectory of /usr/libexec/ would better comply with FHS 3.0. Maybe this could be done for the Trixie release? I guess a subdirectory of /usr/share/ would be appropriate for the extra manpages. Thank you, Jeremy Bícha
Re: Bug#1013992: ITP: session-migration -- tool to migrate in user session settings
On Thu, Jul 7, 2022 at 4:58 AM Guillem Jover wrote: > On Tue, 2022-06-28 at 21:51:44 -0400, Jeremy Bicha wrote: > > Here's a suggestion: > > user-session-migration > > dh-migrate-user-session Providing dh-sequence-migrate-user-session > > Personally I'd perhaps try to keep both names consistent, also > the name you propose for the dh helper looks as if it would be > performing the migration itself which can be misleading, so perhaps > something like dh-user-session-migration would be better? In any case > I'd take either (or similar variants) over dh-migrations. :) Sorry for the delay. I'm uploading this to the NEW queue now with your suggestion: user-session-migration dh-user-session-migration Providing dh-sequence-user-session-migration Thank you, Jeremy Bícha
Bug#1031746: ITP: libdex -- Library for deferred execution
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org Owner: jeremy.bi...@canonical.com Package Name: libdex-1-1 (etc) Version: 0.1.0 Upstream Author: Christian Hergert License: LGPL-2.1+ Programming Lang: C Description: Library for deferred execution Dex is a library supporting "Deferred Execution" with the explicit goal of integrating with GNOME and GTK-based applications. It provides primatives for supporting futures in a variety of ways with both read-only and writable views. Additionally, integration with existing asynchronous-based APIs is provided through the use of wrapper promises. . "Fibers" are implemented which allows for writing synchronous looking code which calls asynchronous APIs from GIO underneath. Other Info -- This package will be maintained by the Debian GNOME team. Packaging is at https://salsa.debian.org/gnome-team/libdex It is a required dependency for GNOME Builder 44. Thanks, Jeremy Bicha
Re: ITS: aiocoap
On Tue, Oct 15, 2024 at 8:04 AM Guillem Jover wrote: > While you are at it, please renamed the source package to something > like python-aiocoap (AFAIR that did not imply having to go through NEW > again if things have not changed?). So that the source package is > properly namespaced (to avoid taking on the global namespace), it's > easier to see what it is about when doing archive-wide analysis from > Sources, or even reading changelogs via stuff like apt-listchangs. :) Renaming a source package does require going through the NEW queue. Thank you, Jeremy Bícha
Re: Suitability of Rust for *all* architectures? [WAS Re: Rustc unsoundness on i386]
On Sun, Nov 24, 2024 at 12:51 PM Paul Gevers wrote: > [Release Team hat on] I would take consensus for a decision on the topic. If the excess precision issue goes away by bumping the i386 baseline, that would make my life easier. Thank you, Jeremy Bícha
Re: Rustc unsoundness on i386
On Sat, Nov 23, 2024 at 1:57 PM Bastien Roucariès wrote: > > Le samedi 23 novembre 2024, 18:29:04 UTC Andrey Rakhmatullin a écrit : > > On Sat, Nov 23, 2024 at 03:14:42PM +0100, Fabian Grünbichler wrote: > > > B) bump the i386 baseline in Debian to require SSE2, and stop disabling > > > SSE2 there in rustc > > It will break I suppose imagemagick on i386 and scientific software testsuite > > i386 means FPU so excess precision. > > SSE is good and even better but excess precision is worked arround thus FTBFS Debian's i386 already has excess precision: https://wiki.debian.org/ArchitectureSpecificsMemo#i386 If you mean something else, could you be… more precise? Thank you, Jeremy Bícha
Re: Should l10n packages be Recommends or Suggests?
On Fri, Dec 6, 2024 at 6:59 AM Stephan Verbücheln wrote: > Localization is not only about disk space, but also manuals, spell > checking, input method tools, fonts etc. being scattered all over the > system. > > It does not make sense that everyone has to select his spell checker > language from 50+ options he does not speak. > > Particularly annoying is that Thai terminal (xiterm+thai), which is > preinstalled in Debian desktop and appears in launchers such as Gnome > Shell when searching for terminals. To clarify, this happens if you use the Live ISO (that uses Calamares) but not if you use the default netinst ISO. Thank you, Jeremy Bícha
Re: Gnome 48 beta packages in Sid
On Thu, Feb 6, 2025 at 2:32 PM Stephan Verbücheln wrote: > Sid is flooded with early beta versions of many Gnome components. This > is causing a lot of breakage. Please be specific about the breakage you are seeing. The best way to do this is to file bugs against affected packages instead of emailing this list. > Are they not supposed to go to > experimental? No. The Debian GNOME team intends for Debian 13 "Trixie" to include GNOME 48. This means we need GNOME 48 to get into Testing by the Transition Freeze deadline. We can't wait until GNOME 48 RC is released at the beginning of March to start this work. Thank you, Jeremy Bícha
Re: Gnome 48 beta packages in Sid
On Fri, Feb 7, 2025 at 6:08 AM Stephan Verbücheln wrote: > It was not distribution-level breakage but upstream bugs. I immediately > observed multiple bugs in evolution: > - Evolution started to forget various UI settings > - icons were mixed up (showing incorrect icons in various places) Thank you. I am unable to duplicate these issues with the information provided. Please report these as Debian bugs instead of on this mailing list. https://www.debian.org/Bugs/Reporting Jeremy Bícha
Re: Do we need a conflict of interest policy?
On Fri, Feb 7, 2025 at 4:10 AM Charles Plessy wrote: > - Consider potential conflicts and be transparent when a decision might >intersect with their employer’s, sponsor’s, or other affiliations' >interests. I don't see why this is needed. I am privileged to be paid by Canonical to package GNOME for Ubuntu (and more). I do a significant amount of work in Debian that is good for my employer. I believe that my work is also good for Debian. I do all my work without hiding my identity and use my company email for emails like this or bug reports or git commits. Would I need to include a disclaimer for every bug report, git commit, merge request, and IRC message so people are informed that Canonical may benefit? > - Refrain from participating in decisions where their neutrality could > reasonably be questioned. Do you really want employed people to contribute **less** to Debian?? I interpret your explicit mention of Canonical in your original email as an attack against Steve and Colin for daring to prefer upstart over systemd more than a decade ago. I don't think that's fair and I don't think there is any reason to debate that now. There aren't any Canonical members on the Technical Committee and I don't think we should discourage any from joining. Thank you, Jeremy Bícha
Re: Invalid check in debian/patches
On Sat, Feb 1, 2025 at 10:14 AM Abou Al Montacir wrote: > With regards to other possible values (No, NotNeeded), I find it a bit hacky > to use this field to provide an upstream bug URL. > I would completely remove this practice and keep this field human readable > and understandable to be a simple tri-state field (Yes, No, Not-Needed). The vast majority disagree with you on the Forwarded field (4000ish to almost 600) but Forwarded: yes is used a lot. https://codesearch.debian.net/search?q=path%3Adebian%2Fpatches+Forwarded%3A+yes https://codesearch.debian.net/search?q=path%3Adebian%2Fpatches+Forwarded%3A+http A Forwarded link is human-readable and machine-readable. Also, Github and Gitlab separate issues from merge requests so it's possible to have two different upstream links. Personally, I would probably just use the merge request link instead of the issue link in this case though. Thank you, Jeremy Bícha
Bug#1093811: ITP: libgedit-gfls -- File loading and saving library for gedit
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org Control: affects -1 src:libgedit-gfls Owner: jeremy.bi...@canonical.com Package Name: libgedit-gfls Version: 0.2.1 Upstream Author: Sébastien Wilmet License: LGPL-3+ Programming Lang: C Description: File loading and saving library for gedit libgedit-gfls is a file loading and saving library for the gedit text editor. Other Info -- libgedit-gfls is yet another library that is only used by gedit (the others are tepl [since renamed to libgedit-tepl] and libgedit-amtk [which is also used by gyrus). This package will be maintained by the Debian GNOME team. Packaging will be at https://salsa.debian.org/gnome-team/libgedit-gfls The upstream source is at https://gitlab.gnome.org/World/gedit/libgedit-gfls Thanks, Jeremy Bícha
Re: DEP-14: Default branch name 'debian/latest' objections?
On Thu, Jan 23, 2025 at 8:07 PM Otto Kekäläinen wrote: > Git is a great tool for collaboration. It is sad to see that in Debian > usage of git is stifled by simple things like people not agreeing to > use a common branch naming scheme despite there being a proposal for > 10+ years now. Your timeline is inaccurate. According to DEP-14's own Changes section, debian/latest was not recommended until 4 years ago. I did not notice the change right away. The Debian GNOME team was a fairly early adopter of DEP-14 and we had to spend time at the beginning of the trixie development cycle to convert all our packages from debian/master to debian/latest [1]. (Out of an abundance of caution, it seemed not helpful to do that migration while bookworm was frozen.) Therefore, even the strongest supporters of DEP-14 may have only very recently adopted debian/latest. [1] https://lists.debian.org/debian-gtk-gnome/2023/08/msg5.html Thank you, Jeremy Bícha
Re: how to fix lintian error: library-not-linked-against-libc
On Sun, Jan 26, 2025 at 6:28 AM Ahmad Khalifa wrote: > The lintian error is a great heads-up and it's up to the reader to > decide whether it's a true error to fix or a false-positive to override. I have never seen this Lintian error actually be useful. I think an error is far too strong for this; I think even a warning is too strong; maybe info would be ok. Thank you, Jeremy Bícha
Re: DEP-14: Default branch name 'debian/latest' objections?
Until 2020, DEP-14 suggested /master. The use of "master" became undesired if a better word was available. See https://inclusivenaming.org/ DEP-14 was already using upstream/latest so for parallel construction, /latest was kind of an obvious choice. Note that DEP-14 explicitly allows you to use debian/unstable and debian/experimental if you want. As has already been mentioned earlier in this thread, the Debian GNOME renamed all our branches from debian/master to debian/latest a year and a half ago. And for our specific workflow, using debian/latest (or debian/master before) proved better since at the time of packaging, we don't always know whether we will upload to unstable or experimental. For most of our packages, once we upload to Experimental, it is rare to upload to Unstable again. GNOME is on a 6-month release cycle so there is only a small amount of time, usually after GNOME Beta, where we stage some things in experimental before they are ready for upload to Unstable. If we do need to upload to Unstable when a package is already in Experimental, we use a short-lived debian/trixie branch. If the development cycle is long enough, that short-lived branch gets re-created (this was done with libadwaita-1 for a new GNOME series). At or near new stable release time, a permanent debian/trixie branch is created which allows for merge requests for stable updates. As Simon pointed out, long-lived development would probably work better with a debian/experimental branch. I think many Debian packages never or only rarely use Experimental so debian/latest is probably best practice for most packages. Thank you, Jeremy Bícha
Re: Should uncoordinated NMUs unilaterally choose Salsa as the VCS for a package?
On Sat, Mar 15, 2025 at 4:34 PM Roberto C. Sánchez wrote: > Question: Should uncoordinated NMUs unilaterally choose Salsa as the VCS > for a package? Why are you opposed to using Salsa as the VCS for cpuset? You use Salsa for many other packages and Github for some others. Although there are obviously some DDs who dislike Salsa, I think the widespread project consensus is that Salsa should be used for packages if they are not hosted in some other VCS. Our current DPL, Andreas, ran on an explicit platform of encouraging Salsa and has continued to push towards that through his entire DPL term. I consider the lack of using any VCS to be a bug, perhaps of normal severity. And therefore, I do think it is appropriate to import a package with its history into the Debian namespace on Salsa as part of an NMU. The lack of a VCS makes it harder for people to contribute to the package and makes it harder to see full packaging history. Thank you, Jeremy Bícha
Re: Building packages in the future.
On Sun, Jan 5, 2025 at 11:56 AM Santiago Vila wrote: > This is an update for my previous MBF announcement here: Thank you for this wonderful project and for raising the severity to serious since it's clearly easier to fix the bugs in Unstable now rather than as Stable Updates later. I think your next iteration of this could go further. The ELTS project aims to provide security support for 10 years for a given Debian release. While not all packages are included in its scope, it makes sense that many of the packages that have test SSL certificates could be security-sensitive packages. Thank you, Jeremy Bícha
Re: Are there any mentors for this beauty? RFS: Confirmed Packages
On Mon, Apr 7, 2025 at 11:03 AM Kirill Rekhov wrote: > 3. fonts-adwaita > Adwaita Fonts Collection > > Upstream: https://gitlab.gnome.org/GNOME/adwaita-fonts > Salsa: https://salsa.debian.org/krekhov/fonts-adwaita > Last Pipeline: > https://salsa.debian.org/krekhov/fonts-adwaita/-/pipelines/843148 > Mentors: https://mentors.debian.net/package/fonts-adwaita/ > RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101879 The Debian Fonts team has claimed ownership of this RFS. Could you reply to my proposal from Friday there? Thank you, Jeremy Bícha
Bug#1103933: ITP: paper-clip -- PDF metadata editor for GNOME
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org Control: affects -1 src:paper-clip Owner: jeremy.bi...@canonical.com Package Name: paper-clip Version: 5.5.1 Upstream Author: Diego Iván License: GPL-3+ Programming Lang: Vala Description: PDF metadata editor for GNOME Paper Clip is a simple GNOME app for editing metadata in PDF documents. It can edit the Title, Author, Creation Software, Keywords, and more. . Paper Clip is a GNOME Circle app. Other Info -- This package will be maintained by the Debian GNOME team. Packaging will be at https://salsa.debian.org/gnome-team/paper-clip The upstream source is at https://github.com/Diego-Ivan/Paper-Clip See https://circle.gnome.org/ for more information about GNOME Circle. Thanks, Jeremy Bícha
Re: General Resolution: Interpretation of DFSG on Artificial Intelligence (AI) Models
On Mon, May 5, 2025 at 2:49 PM Mo Zhou wrote: > On 5/5/25 11:44, Andrey Rakhmatullin wrote: > >> It is too rush to start to vote for this within 3 weeks > > > > Does this maybe sound like the GR call was premature? > > The project consensus, especially after > > https://www.debian.org/vote/2021/vote_003, seems to say that we don't > > want multi-month GR discussions. > > > > Not quite. Proposal A is mature and I'm confident in it. > Potential proposal B,C,D,... are premature. > I have no intention to let people holding different opinions > to have a very short time to prepare a formal proposal B,C,D. > > But, the whole series of discussions started 7 years ago. > And I have already mailed everywhere about my intention > to submit the GR. If there is no proposal B, that could mean > it is really difficult to formally write a proposal B. > > I lean towards going ahead. I don't believe we have enough information to do the GR now (or one week from today, the longest we can delay). I am unclear on whether existing packages in Debian are affected. Your proposal does not indicate whether the GR would be effective immediately. My suggestion is for you to ask the DPL to extend the discussion period by a week (for constitutional reasons) followed by an immediate withdrawal of the GR. Withdrawing the GR allows you to resubmit later and wait 2-3 weeks from that point. Thank you, Jeremy Bícha
Bug#1104179: ITP: fretboard -- Guitar chord lookup app for GNOME
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org Control: affects -1 src:fretboard Owner: jeremy.bi...@canonical.com Package Name: paper-clip Version: 9.1 Upstream Author: Brage Fuglseth License: GPL-3+ Programming Lang: Rust Description: Guitar chord lookup app for GNOME Fretboard lets you find guitar chords by typing their names or by plotting them on an interactive guitar neck. When you have identified a chord, you can experiment with changing it, see more ways to play it, or bookmark it to save it for later. . Fretboard is a GNOME Circle app. Other Info -- This package will be maintained by the Debian GNOME team. Packaging will be at https://salsa.debian.org/gnome-team/fretboard The upstream source is at https://github.com/bragefuglseth/fretboard and the homepage is at https://apps.gnome.org/Fretboard/ See https://circle.gnome.org/ for more information about GNOME Circle. Thanks, Jeremy Bícha
Re: Bug reports for Uploaders (was: Re #397761: bugs.debian.org: please forward bug reports to Uploaders also)
On Sun, Mar 2, 2025 at 12:07 PM Blair Noctis wrote: > (I'm also confused by the fact that follow-ups to bug reports aren't > forwarded to submitters by default, but the submitter must X-Debbugs-Cc > themselves, but then which is basically the default behavior of reportbug(1) > now IIRC, but that's for another time.) X-Debbugs-CC does not forward replies to bug reports. People replying to bug reports need to explicitly CC the bug submitter or hope that the bug submitter is already subscribed because it is a package they maintain. The workflow to manually subscribe to individual bugs is tedious enough that I only do it occasionally for bugs I am interested in, usually where I am not the bug submitter. Thank you, Jeremy Bícha
Re: Gnome 48 dependency on Xwayland
On Wed, Feb 26, 2025 at 10:10 AM Stephan Verbücheln wrote: > According to reports and changelogs, Gnome 48 should be working without > Xwayland. > > https://gitlab.gnome.org/GNOME/gdm/-/blob/main/NEWS > > Can you remove the package dependency in Debian? No. We are not going to build GNOME for Trixie without support for Xorg. That may be useful for kiosks but is not useful in a general purpose OS like Debian at this time. Also, please report a bug for this kind of packaging suggested change instead of emailing this list. https://www.debian.org/Bugs/Reporting Thank you, Jeremy Bícha
Re: Gnome 48 dependency on Xwayland
On Wed, Feb 26, 2025 at 2:19 PM Stephan Verbücheln wrote: > Looks like this needs a more general discussion to clear up the > misunderstandings. Please, please file a bug instead. I don't want to discuss package change requests like this on debian-devel especially when you haven't tried filing a bug first. Thank you, Jeremy Bícha
Re: Proposed MBF: CMake 4.0 compatibility
On Wed, Apr 23, 2025 at 3:49 PM Timo Röhling wrote: > I have rebuilt the ~3000 packages which build-depend on CMake with > debusine (thanks to Freexian for this helpful service and Stefano Rivera > for his debusine-rebuilds tool) and discovered 936 affected packages; > the dd-list is attached. > > If you want to fix your package, there are two options: > > 1) Add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to dh_auto_configure, which > will override any CMakeLists.txt settings. This is the minimally > invasive procedure, no patching required. See also [1]. > … > [1] > https://cmake.org/cmake/help/latest/variable/CMAKE_POLICY_VERSION_MINIMUM.html Could we have debhelper do this by default for buildsystem=cmake (and cmake+ninja)? It feels like it would be so much nicer to update 1 package instead of more than 900. Thank you, Jeremy Bícha
Bug#1108229: ITP: mozjs140 -- SpiderMonkey JavaScript library
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org Control: affects -1 src:mozjs140 Owner: jeremy.bi...@canonical.com Package Name: mozjs140 Version: 140.0 Upstream Author: Mozilla etc License: mostly MPL-2.0, other files are licensed under other open source licenses Programming Lang: C++ Description: SpiderMonkey JavaScript library SpiderMonkey is the code-name for Mozilla Firefox's C++ implementation of JavaScript. It is intended to be embedded in other applications that provide host environments for JavaScript. . This library is intended for use in contexts where only trusted JavaScript code will be run, such as GNOME's gjs, Cinnamon's cjs, and polkit's rules parsing. It should not be used to run untrusted JavaScript from web pages: use a security-supported implementation such as Firefox, Chrome or WebKitGTK's JavaScriptCore instead. Other Info -- mozjs is the JavaScript engine from Firefox ESR. Tomorrow, a new Firefox ESR series will be released. It will be supported by Mozilla for about 14 months. mozjs140 is unlikely to be backported for trixie. Forky is likely to use the new series after mozjs140 once it's available in 2026. I expect that either GNOME 49 or 50 (specifically gjs 1.86 or 1.88) will switch from mozjs128 to mozjs140. The other user of mozjs* in Debian is Cinnamon, specifically their cjs fork of gjs. Recently, the cjs developers have changed their update processes to make it easier for distros to fully switch to newer versions of mozjs. cjs's new version numbering system makes this more obvious: trixie's cjs 128 is compatible with mozjs128. mozjs packaging is at https://salsa.debian.org/gnome-team/mozjs References -- https://whattrainisitnow.com/calendar/ https://gitlab.gnome.org/GNOME/gjs/-/issues/690 Thanks, Jeremy Bícha
