Bug#1075903: ITP: fonts-noto-emoji -- monochrome emoji font from Google
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,
pkg-fonts-de...@lists.alioth.debian.org
Control: affects -1 src:fonts-noto-emoji
Owner: jeremy.bi...@canonical.com
Package Name: fonts-noto-emoji
Version: 3.002
Upstream Author: Google
License: SIL-1.1
Programming Lang: N/A
Description: monochrome emoji font from Google
Noto is a collection of font families, each visually harmonized across
scripts.
.
The name "Noto" is short for "No Tofu", describing the aim of covering
all living Unicode scripts.
.
Tofu (豆腐) is Japanese jargon for unicode replacement character "�"
(U+FFFD) often displayed as replacement for unassigned or unknown
characters.
.
This package contains the monochrome ("black and white") emoji font.
Both an OpenType variable font and traditional static font files are
provided.
.
Please install fonts-noto-color-emoji instead if you want the color
font used on "stock" Android devices.
Other Info
--
Notably, Google has refused to provide the source for this font since
its introduction in 2022. This is disappointing since Google has been
a major contributor to open source fonts and tooling. Source code is
provided for other Noto fonts including the popular color emoji font
(packaged in Debian as fonts-noto-color-emoji).
There is a Github repo that is linked to in several places but the
repo is private: https://github.com/googlefonts/emoji-bw
Therefore, although this font is licensed under a compatible open
source license, I believe the font violates the Debian Free Software
Guidelines #2 which requires source code. Consequently, this package
will be uploaded to non-free. We hope that Google will eventually
release the source code and this package can be transferred to
Debian main.
This package will be maintained by the Debian Fonts Task Force.
Packaging will be at
https://salsa.debian.org/fonts-team/noto-emoji-font
The upstream homepage is at
https://fonts.google.com/noto/specimen/Noto+Emoji
References
--
https://github.com/googlefonts/noto-emoji/issues/390
https://www.debian.org/social_contract#guidelines
Thanks,
Jeremy Bícha
Bug#678920: ITP: libzapojit -- library for accessing SkyDrive and Hotmail
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-devel@lists.debian.org Owner: Jeremy Bicha * Package name: libzapojit Version : 0.0.2 Upstream Author : Debarshi Ray * URL : http://git.gnome.org/browse/libzapojit * License : LGPL-2.1 Programming Lang: C Description : library for accessing SkyDrive and Hotmail libzapojit is a GLib-based library for accessing online service APIs using the Microsoft SkyDrive and Hotmail REST protocols. libzapojit is a new dependency of gnome-documents for GNOME 3.6, enabling Microsoft SkyDrive support as an alternative to the already existing Google Docs support. I intend to co-maintain this library with the Debian GNOME Team. http://debarshiray.wordpress.com/2012/05/31/gnome-documents-skydrive/ Thanks, Jeremy Bicha -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaajcmaqrj-tkhlf5am-fz+g+odikadhms0ijdufrqudyae...@mail.gmail.com
Re: Recommends for metapackages
On 11 July 2012 14:21, Noel David Torres Taño wrote: > Installing N-M breaks unrelated software. Hi! I don't claim to be a networking expert, but I believe half the conversation here is based on wrong or outdated information. I encourage those who think NetworkManager (NM) doesn't play well with ifup/ifdown to please read http://wiki.debian.org/NetworkManager#NetworkManager_in_Squeeze Furthermore, not having NM running breaks the Network panel in System Settings (gnome-control-center). NetworkManager makes connecting to WiFi points much much easier, while at the same time NOT breaking wired connectivity. Oh, and NM works just fine for USB tethering with my Android phone too. GNOME considers NM to be part of GNOME Core, therefore gnome-core depends on it. If you're allergic to NM, either don't install gnome-core; let NM install but tell it never to run; or follow one of the several workarounds already posted to this list. Thanks, Jeremy -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaajcmzvrd2m1riqq51pxpca0zuey-eluvchczqt0mmzrw3...@mail.gmail.com
Re: CD1 without a network mirror isn't sufficient to install a full desktop environment
On 9 September 2012 23:21, Ztatik Light wrote: > According to popcon, Xfce is more common on Debian than GNOME... And How do you figure that? http://qa.debian.org/popcon.php?package=meta-gnome3 http://qa.debian.org/popcon.php?package=xfce4 Just looking at popcon, GNOME is installed several more times as much as XFCE. Even gnome-shell has more installs than xfce4-panel despite GNOME Shell having not been included in a stable Debian release yet. Jeremy -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaajcmy6nngvdj9j_9mtozgtad18f2zvp6cenvl2oaebzgv...@mail.gmail.com
Re: CD1 without a network mirror isn't sufficient to install a full desktop environment
On 11 September 2012 08:06, Ian Jackson wrote: > Based on this, I think there is at the very least no reason to > reverse the decision to switch the Debian default to xfce. Except as Paul said, the decision to make XFCE default for Wheezy has not been made so it can't be reversed. Jeremy Bicha -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaajcmyy3xrukcng3to015kmqpxgxzw7wp8yw+rvjj906om...@mail.gmail.com
bzr (was: Re: Debian systemd survey)
On 22 May 2013 22:02, Chow Loong Jin wrote: >> [...] Bazaar (which seems to have been abandoned by >> upstream with >2000 open bugs [1]) [...]. > > On the other hand, it would be nice if you keep your FUD to the minimum. > Bazaar > doesn't look abandoned[1], and >2000 open bugs is not uncommon. Nautilus and > Rhythmbox themselves have >1000 open bugs each. > > [1] https://code.launchpad.net/bzr Two commits this year? The only thing that makes it not completely abandoned by upstream is that occasionally there are a few maintenance bugfix commits done. For the record, I do use bzr (with http://jameswestby.net/bzr/builddeb/user_manual/merge.html ) in my normal Ubuntu/Debian packaging workflow. I haven't figured out how to git to work as nicely for that usecase yet. Jeremy Bicha -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaajcmzsv+wibph7dmoce2fq4d3cmtaqoe48axuogzw+6pd...@mail.gmail.com
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 20 July 2013 08:17, Marc Haber wrote: > On Sat, 20 Jul 2013 11:27:58 +0200, Josselin Mouette > wrote: >>If this is about kFreeBSD, it would be nice and all to share the init >>system with these ports, but it should certainly not have an influence >>on the choice of init system for the Linux ports. > > Why? Because http://lists.debian.org/debian-devel/2013/07/msg00379.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAajCMYX_wABY-TsZd0=Ga+rBK7BCq-t6KC8chXASDXnFgN=r...@mail.gmail.com
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 21 July 2013 20:22, The Wanderer wrote: > I'm saying that it looks to me as if the lock-in to systemd would be > even stronger than the lock-in to sysvinit, and might well extend to the > point of even making it harder to implement another new alternative in > the first place. So let's never switch to anything better than what we have now unless we also support 1 or 2 alternatives simultaneously just to be safe. /s Jeremy -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAajCMaWbUDKK1eA=h2oWqR2L0M2wv-b=cp2oz1b-f_8hmx...@mail.gmail.com
Re: Bug#692863: ITP: heimdall -- tool for flashing firmware on Samsung Galaxy S devices
On 9 November 2012 16:43, Steve Langasek wrote: > * Package name: heimdall > Version : 1.4~rc2 > Upstream Author : Benjamin Dobell > * URL : http://www.glassechidna.com.au/products/heimdall/ > * License : MIT/X11 > Programming Lang: C++ > Description : tool for flashing firmware on Samsung Galaxy S devices > > Heimdall is a tool for flashing firmware (aka ROMs) onto Samsung Galaxy S > devices over a USB connection. It accomplishes this using the same > protocol as Odin, Samsung's internal Windows-only firmware updater. > > > The naming of this tool is entirely logical from the upstream's perspective, > given that there are other related pieces of software called "Odin" and > "Loke". However, there's an unfortunate namespace collision here with the > Kerberos implementation Heimdal. Suggestions welcome on how to qualify > the source package name so that the packages are more than one letter off > from one another... There's another ITP that suggested heimdall-flash: http://bugs.debian.org/644520 Jeremy -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAajCMbYue2YsW3n9_qhe_q5Az_4=m7m_zzey_y20dza8tn...@mail.gmail.com
Re: Packaging MATE for Debian
On 3 December 2012 14:28, Stefano Karapetsas wrote: > As I already said you many times, MATE no longer uses these "obsolete" and > "duplicated" libraries. > > And, maybe you dont know, but we are already working with GNOME developers > to share efforts with them. Just some examples: with yelp developer, to use > yelp as documentation viewer and yelp tools to build documentation; with > evince developers to share libriaries and have only separated UI. And we are > working with GNOME to keep alive software no longer maintained too [1]. What's so bad about evince that you need to use a forked version anyway? Or gnome-icon-theme, gnome-keyring, gnome-terminal, etc. Jeremy -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAajCMaYguJVapK-Yra5irs=drnlgdr4c5uvivm-vhvondc...@mail.gmail.com
Re: Uncoordinated upload of the rustified librsvg
On Sat, Nov 3, 2018 at 6:47 PM Adam Borowski wrote: > Perhaps we should quickly upload a revert, using the last good version of > librsvg, before things degrade? Effectively removing librsvg on 11 archs > (not counting non-official ones) stops any GUI there. Including proverbial > fvwm. It sounds to me like you're saying that to fix librsvg being out of date on 11 arches, we need to make it out of date on every architecture. What is the actual consequence of the latest librsvg being unbuildable on those arches? The old binaries won't automatically be removed there, right? As I mentioned in #debian-devel, librsvg is a security-sensitive library. The Debian GNOME team has long wanted a supported version of librsvg to be buildable on all release architectures in time for the Buster release to ease the maintainability burden on the Security team (as well as benefiting from some hardening improvements). I didn't and don't mean to upset you. It honestly didn't occur to me that I ought to talk to ports maintainers before uploading packages that won't build on ports. Instead of putting all the blame on the GNOME team, maybe you could have expressed your concerns during the months that librsvg was still in experimental? Or maybe you could have said "Rust is now available on all release architectures, but please talk to us before uploading a rustified library." While today's upload was apparently a surprise, I don't think it should have been a surprise that this upload was coming. Reference -- https://mail.gnome.org/archives/desktop-devel-list/2017-December/msg00072.html Thanks, Jeremy Bicha
Re: Uncoordinated upload of the rustified librsvg
On Sun, Nov 4, 2018 at 11:33 AM Ben Hutchings wrote: > I do like the proposal of adding a librsvg-c for just the architectures > that don't have Rust (yet). This sounds reasonable. Thanks Samuel for the suggestion. Any volunteers to maintain this new old package? Thanks, Jeremy Bicha
Re: Uncoordinated upload of the rustified librsvg
On Sun, Nov 4, 2018 at 2:30 PM Jeremy Bicha wrote: > On Sun, Nov 4, 2018 at 11:33 AM Ben Hutchings wrote: > > I do like the proposal of adding a librsvg-c for just the architectures > > that don't have Rust (yet). > > This sounds reasonable. Thanks Samuel for the suggestion. Any > volunteers to maintain this new old package? To move forward on the technical fix for the primary issue raised in this thread, let me repeat and restate: It looks like we will want to have a librsvg-c source package to build the older librsvg for architectures that don't support Rust yet. While the Debian GNOME team could maintain librsvg-c's packaging alongside librsvg, I'd be happier if someone who cares more about ports would maintain it. Any volunteers? At a minimum, I don't have an easy way to do the initial binary build of librsvg-c required for the NEW queue. Thanks, Jeremy Bicha
Re: Uncoordinated upload of the rustified librsvg
On Sat, Nov 3, 2018 at 5:54 PM John Paul Adrian Glaubitz wrote: > I'm really annoyed and disappointed by this move and feel really let down by > this > behavior. No heads up, no coordination, no nothing. There was some coordination but the coordination was for release architectures. The coordination was with the Release Team and not with whoever maintains ports. See https://bugs.debian.org/907626 I guess to some degree I consider the ports to be as much or as little a part of Debian as nonfree is. Officially, they aren't part of a strict definition of Debian, but they are part of the broader Debian ecosystem. It's difficult for me to even know how to raise issues with ports. I filed https://bugs.debian.org/908600 for a fairly minor package 2 months ago. I guess I did that sort of right except I only did the usertag for kfreebsd and not for hurd. I even did some minor enablement work for mutter for hurd/kfreebsd recently but I'm absolutely not a porter and I've never used those ports. Thanks, Jeremy Bicha
Re: I resigned in 2004
On Mon, Nov 12, 2018 at 7:46 AM Adam Borowski wrote: > It's social people who put nice forms of speech above actual merit, and > I'm for one anything but social. It sounds to me like you're implying that niceness does not have actual merit in itself. I think that opinion goes against the spirit of the Debian Code of Conduct. You can say "no" to requests and still be nice. You're also pulling someone else in (formorer) to demonstrate your argument and I'm not sure he approves of your message here. Thanks, Jeremy Bicha
Bug#913766: ITP: librsvg-c -- the pre-Rust version of librsvg
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, glaub...@physik.fu-berlin.de Owner: jbi...@debian.org Package Name: librsvg-c Version: 2.40.20 Upstream Authors: Ximian, Eazel, Red Hat, Igalia, etc. License : LGPL-2+ Programming Lang: C Homepage: https://wiki.gnome.org/Projects/LibRsvg Description: SAX-based renderer library for SVG files The rsvg library is an efficient renderer for Scalable Vector Graphics (SVG) pictures. Other Info -- As requested, this is librsvg reintroduced for ports that don't supported the rustified librsvg yet. The name is because this is librsvg written in the C programming language (instead of in Rust). Packaging can be found at https://salsa.debian.org/gnome-team/librsvg-c Currently, the packaging builds the same binary package names as src:librsvg. There was a suggestion to use different binary names with versioned Provides (against the existing librsvg binary package names). I'm not sure that provides much benefit but we can discuss that. I don't have the ability to do the initial upload for this package since I don't have easy access to do the binary build required for ftp-master NEW. I don't have experience with archive management for non-release architectures at all. Thanks, Jeremy Bicha
Re: Bug#913766: ITP: librsvg-c -- the pre-Rust version of librsvg
On Wed, Nov 14, 2018 at 5:22 PM John Paul Adrian Glaubitz wrote: > > Hi Jeremy! > > On 11/14/18 10:52 PM, Jeremy Bicha wrote: > > As requested, this is librsvg reintroduced for ports that don't > > supported the rustified librsvg yet. The name is because this is > > librsvg written in the C programming language (instead of in Rust). > > Thanks a lot for your effort and the initiative, I really appreciate > the idea. I also apologize for my harsh wording in the heated the > discussion we had. I'm very glad that this - as it is always the case > in Debian - is leading to a productive solution. Great! > > > Currently, the packaging builds the same binary package names as > > src:librsvg. There was a suggestion to use different binary names with > > versioned Provides (against the existing librsvg binary package > > names). I'm not sure that provides much benefit but we can discuss > > that. > > > > I don't have the ability to do the initial upload for this package > > since I don't have easy access to do the binary build required for > > ftp-master NEW. > > > > I don't have experience with archive management for non-release > > architectures at all. > > The problem that we have is that it's not possible to upload a package > to Debian which does not build any binaries on the release architectures, > the archive would be removed from the archive immediately. > > I assume what we could do is maybe have a package that is built from > multiple sources so that it builds different binary packages for the > Rust and non-Rust targets. > > I have CC'ed James Clarke and Adrian Bunk who might be interested in > this discussion as well and probably can maybe help in the process. > > Again, thanks a lot for the efforts and sorry for my heated and > unprofessional behavior. > > Thanks a lot! > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 Would an arch:all librsvg-c-doc package be sufficient for the "must build a binary package on a release architecture" requirement? Thanks, Jeremy Bicha
Re: julia_1.0.0-1_amd64.changes REJECTED
On Wed, Nov 21, 2018 at 10:57 AM Holger Levsen wrote: > (in that sense I would appreciate packages getting automatically tested > (and rejected if needed) before they enter *unstable*, and then again, > with stricter automatic tests before they enter testing.) This sounds to me like what Ubuntu does. Packages need to clear autopkgtest testing and library transitions need to complete before packages migrate from "-proposed" to the regular development archive. I believe this approach has significantly improved the quality and usability of Ubuntu's development release since it was implemented a few years ago. I admit I mostly use Ubuntu. In my Debian environment, I usually run Testing (except for building packages) because it avoids a considerable amount of the pain that shows up in Unstable. If an unstable-proposed system were implemented, I expect I would happily upgrade my Debian install to Unstable. Thanks, Jeremy Bicha
Re: usrmerge -- plan B?
On Wed, Nov 21, 2018 at 3:39 PM Russ Allbery wrote: > But it's not just my opinion that matters. I think we need to decide this > somehow as a project, whether via the TC or via GR or something, because > there's a real disagreement here over whether we can or should > force-upgrade all Debian systems and I don't believe doing something short > of that is going to be supportable. If we are going to have a vote, we don't have a lot of time. I think that if Debian were to choose to convert all systems to usrmerge for the Buster release, it ought to be complete in Buster before the Transition Freeze which is scheduled for January 12. [1] [1] https://release.debian.org/ Thanks, Jeremy Bicha
Update on removing obsolete GNOME libraries & gtk2 MBF
It's been several months since the last update from the Debian GNOME team on our efforts to remove unmaintained libraries from Debian. We have made significant progress in this goal and the removal of libgnome is within reach. See the charts later in this email. Also, we have succeeded in removing gtk2 from the default GNOME install for Buster (as of meta-gnome3 1:3.22+13). gtk2 mass bug filing - For Bullseye, we are serious about our intention to remove libglade2, libgtk2-perl, and pygtk. This is part of a larger effort to reduce gtk2 use as much as possible. This is a massive project as over 600 packages in unstable are using gtk2 now. gtk3 was declared stable with its 3.22 release in 2016. gtk3 has many advantages over gtk2: support for HIDPI scaling, support for Wayland, CSS theming, better support for non-C programming languages through GObject Introspection, and more. Practically speaking, gtk2 has nearly reached its End of Life. We want to do a gtk2 mass bug filing now. Please contact us if you would like to help us file all these bugs. If you use or maintain a GTK2 project, please discuss GTK2's deprecation with upstream. I believe a majority of GTK2 apps are unmaintained so you may need to do the porting yourself if you aren't ready for your favorite apps to be removed from Debian. Removed from Debian --- esound gconfmm2.6 gksu & libgksu gnome-keyring-sharp gnome-sharp2 goffice-0.8 gocanvas libsocialweb libunique3 mx opal & ptlib pygoocanvas webkit-sharp webkit-sharp3 libgnome2-perl libgnome2-canvas-perl libgnome2-gconf-perl libgnome2-vfs-perl libgnome2-wnck-perl libgoo-canvas-perl libgtk2-appindicator-perl libgtk2-unique-perl Removed from Testing In this section, the parentheses indicate the remaining packages that depend on them (reverse dependencies). A trailing & is used to point to libraries that themselves are listed as removed. A trailing !! means that the removal process has started either through an Intent to Remove bug or a RM bug. (gbonds & thawab will be uploaded soon to fix their issues.) gnome-python (gnome-python-desktop&, gjots2, revelation) gnome-python-desktop (xword!!) gnome-vfs (libgnome&) libbonobo (libbonoboui&) libbonoboui (libgnomeui&) libgnome (libgnomeui&) libgnomeui (gnome-python&, gbonds, gnome-commander!!, gresolver!!, linsmith) libgnome-keyring (libgnomeui&, moonshot-ui, mozilla-gnome-keyring, mysql-workbench) orbit2 (pyorbit&, libbonobo&) pygtksourceview (cherrytree, liblunar!!) pyorbit (gnome-python&) python-poppler (pdfshuffler) rarian (gbonds) webkitgtk (swt-gtk!!, thawab) libgtk2-gladexml-perl libgtk2-notify-perl libgtk2-sourceview2-perl libgtk2-spell-perl libgtk2-trayicon-perl libgtk2-traymanager-perl Discussing removal - clutter-gesture Deferred until Bullseye -- gconf gtksourceview2 gtksourceview3 gtkspell3 libglade2 libglademm2.4 libgnomecanvas libgnomecanvasmm2.6 libgtk2-perl libunique pygtk python-gtkglext1 (xpra) vte (cdebconf-terminal which is part of debian-installer) Not removing at this time -------- libart-lgpl On behalf of the Debian GNOME Team, Jeremy Bicha
Re: Sending using my @debian.org in gmail
On Fri, Nov 30, 2018 at 9:18 AM 殷啟聰 | Kai-Chung Yan wrote: > However this worries me. During the setup there is no Debian involvement, and > that means anyone can do the same trick to pretend to own my Debian address. There is a confirmation email so a Bad Guy would have to be able to read your email first. Thanks, Jeremy Bicha
Bug#916668: ITP: buildstream -- toolset for the BuildStream project
Package: wnpp Severity: wishlist Owner: jbi...@debian.org X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org Package Name: buildstream Version: 1.2.3 Upstream Authors: Codethink, Tristan Van Berkom, Jürg Billeter License : LGPL-2+ Programming Lang: Python3 Homepage: https://buildstream.build/ Description: toolset for the Buildstream project BuildStream is a GNOME project to improve the continuous integration of complex systems and applications. The project aims to pay special attention to those developers and integrators who care about the maintainability of their projects during a long period of time. . BuildStream is also a powerful and flexible software integration toolset. It has been designed to create different outputs out of a unique input and, at the same time, it is able to adapt to complex workflows, even when additional build tools are required. An important part of BuildStream is a sister project called BuildGrid, that allows BuildStream to build at scale. Other Info -- Note that this package installs a new 3-letter binary: /usr/bin/bst I intend to maintain this with the Debian GNOME Team. Initial packaging is at https://salsa.debian.org/gnome-team/buildstream/ Docs are at https://buildstream.gitlab.io/buildstream/ BuildStream is sort of, but not really, a replacement for jhbuild. BuildStream is used to build GNOME releases (since GNOME 3.28) and the Freedesktop SDKs. The GNOME and KDE Flatpak runtimes depend on the Freedesktop SDKs. Thanks, Jeremy Bicha
Re: Bug#915050: (gitlab) Re: Bug#915050: Keep out of testing
On Tue, Dec 18, 2018 at 10:12 AM Holger Levsen wrote: > On Tue, Dec 18, 2018 at 08:38:39PM +0530, Pirate Praveen wrote: > > But if that is not possible, volatile as a separate archive is also fine. > > instead of volatile we need PPAs. Shortly before the Stretch release, when I was scrambling to find a way to provide updates for webkit2gtk for Stretch's lifetime, I think volatile was suggested as something that was able to sort of do what I needed. But it's not a good example since Debian Security ought to handle webkit2gtk updates for Buster, as is done with Firefox ESR and Chromium. Thanks, Jeremy Bicha
Bug#917830: ITP: pdfarranger -- maintained fork of pdfshuffler
Package: wnpp Severity: wishlist Owner: jbi...@debian.org X-Debbugs-CC: debian-devel@lists.debian.org, python-apps-t...@lists.alioth.debian.org Package Name: pdfarranger Version: 1.1 Upstream Authors: Konstantinos Poulios, Jerome Robert License : GPL-3+ Programming Lang: Python3 Homepage: https://github.com/jeromerobert/pdfarranger/issues/35 Description: merge, split and re-arrange pages from PDF documents PDF Arranger is a small application which allows one to merge or split pdf documents and rotate, crop and rearrange their pages using an interactive and intuitive graphical interface. PDF Arranger was formerly known as PDF Shuffler. Other Info -- pdfshuffler's last release was in 2012. pdfarranger was created because the pdfshuffler maintainer did not seem interested in accepting patches. pdfarranger has been ported from Python 2 and GTK2 to Python 3 and GTK3. pdfshuffler was the last package keeping the obsolete python-poppler in Debian. pdfshuffler was maintained by the Debian Python Applications Team so this is too. Packaging is at https://salsa.debian.org/gnome-team/buildstream/ A transitional package is provided to help people upgrade from pdfshuffler. Thanks, Jeremy Bicha
Re: Bug#917830: ITP: pdfarranger -- maintained fork of pdfshuffler
The packaging link should be https://salsa.debian.org/python-team/applications/pdfarranger If anyone wants more background to justify the fork, see https://github.com/jeromerobert/pdfarranger/issues/9 Thanks, Jeremy Bicha
Re: introduction of x-www-browser virtual package
On Tue, Jan 8, 2019 at 11:46 AM Adam Borowski wrote: > On Tue, Jan 08, 2019 at 02:19:13PM +, Simon McVittie wrote: > > Please use xdg-open instead of reinventing it. Unlike the alternatives > > system, xdg-open respects the per-user configuration written by our > > default GNOME desktop (and hopefully other desktop environments), > > Which raises a question: why does GNOME reinvent this system? Because sensible-utils is not cross-distro. (unless I misunderstood your question) Thanks, Jeremy Bicha
Re: introduction of x-www-browser virtual package
On Fri, Jan 11, 2019 at 10:23 AM Jonathan Dowland wrote: > Right now we have at least one package (one of the lxde* ones) shipping > a .desktop file that references x-www-browser but does not guarantee > that x-www-browser exists; this can be resolved via a virtual package. https://git.lxde.org/gitweb/?p=debian/lxpanel.git;a=blob;f=debian/desktop/lxde-x-www-browser.desktop But I wonder whether that .desktop makes sense. Wouldn't users be better served by just having a Firefox ESR .desktop instead? They would know what it is and could delete it if they don't need it. LXDE doesn't ship with any tool that allows customizing what x-www-browser is, right? I don't see that LXDE .desktop as being very useful in practice. Thanks, Jeremy Bicha
Bug#919120: ITP: bst-external -- external plugins for BuildStream toolset
Package: wnpp Severity: wishlist Owner: jbi...@debian.org X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org Package Name: python3-bst-external Version: 0.9.0 Upstream Authors: Codethink License : LGPL-2+ Programming Lang: Python3 Homepage: https://gitlab.com/BuildStream/bst-external/ Description: external plugins for BuildStream toolset BuildStream is a GNOME project to improve the continuous integration of complex systems and applications. The project aims to pay special attention to those developers and integrators who care about the maintainability of their projects during a long period of time. . BuildStream is also a powerful and flexible software integration toolset. It has been designed to create different outputs out of a unique input and, at the same time, it is able to adapt to complex workflows, even when additional build tools are required. An important part of BuildStream is a sister project called BuildGrid, that allows BuildStream to build at scale. . This package provides a collection of BuildStream plugins that don't currently fit in with the core plugins. Other Info -- This package depends on buildstream. Its ITP is https://bugs.debian.org/916668 I intend to maintain this with the Debian GNOME Team. Initial packaging is at https://salsa.debian.org/gnome-team/bst-external Thanks, Jeremy Bicha
Bug#921464: ITP: gnome-books -- ebook reader for GNOME
Package: wnpp Severity: wishlist Owner: jbi...@debian.org X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org Package Name: gnome-books Version: 3.31.90 Upstream Authors: Cosimo Cecchi License : GPL-2+ Programming Lang: JavaScript Homepage: https://wiki.gnome.org/Apps/Books Description: ebook reader for GNOME GNOME Books is a simple application to access and organize your ebooks. It is meant to be a simple and elegant replacement for using a file manager to deal with ebooks. The app supports comic books and ePub books. Other Info -- Before GNOME 3.32, this app was bundled as part of the GNOME Documents app. It was split to allow users to easily install one app without the other. I am intending to get the new versions of these 2 apps into Debian Buster to fix the usability problem when you try to install or remove one of the apps in the GNOME Software app. Packaging is maintained by the Debian GNOME Team at https://salsa.debian.org/gnome-team/gnome-books Thanks, Jeremy Bicha
Re: Reusing source package name of long-removed, unrelated package
On Wed, Feb 6, 2019 at 5:39 AM Gard Spreemann wrote: > I understand that 3.3.2 of the policy mandates that I at least bump the > epoch, but I wanted to ask the list to make sure: is reusing the source > package name of an unrelated, long-removed package like this OK, or > should I consider using a different name? You don't need to bump the epoch since your package has a higher version number than the old package. Thanks, Jeremy Bicha
Bug#994090: ITP: gnome-connections -- Simple GNOME app to access remote computers
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Owner: jer...@bicha.net Package Name: gnome-connections Version: 41~rc Upstream Author: Red Hat, Inc. License: GPL-3+ Programming Lang: Vala Description: Simple GNOME app to access remote computers GNOME Connections is a desktop client to view or use remote computers using VNC or RDP. GNOME Connections is intentionally simple and easy to use. . GNOME Connections replaces the remote desktop functionality that was previously found in GNOME Boxes. Other Info -- GNOME 41 introduces a new default app for GNOME: GNOME Connections. This app will be maintained by the Debian GNOME team. Packaging is at https://salsa.debian.org/gnome-team/gnome-connections Thanks, Jeremy Bicha
Bug#996609: ITP: gtksourceview5 -- shared libraries for the GTK4 syntax highlighting widget
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Owner: jer...@bicha.net Package Name: libgtksourceview-5-0 Version: 5.2.0 Upstream Author: Many GNOME developers License: LGPL-2.1+ Programming Lang: C Description: Shared libraries for the GTK4 syntax highlighting widget GtkSourceView is a text widget that extends the standard GTK 4 text widget GtkTextView. It improves GtkTextView by implementing syntax highlighting and other features typical of a source editor. . This package contains the shared libraries required by applications to use this widget. Other Info -- This library will be maintained by the Debian GNOME team. Packaging is at https://salsa.debian.org/gnome-team/gtksourceview5 gtksourceview5 is for GTK4 apps gtksourceview4 is for GTK3 apps gtksourceview3 is an older library for GTK3 apps. GTK3 apps should switch to gtksourceview4 soon gtksourceview2 was for GTK2 apps and has recently been removed from Debian Unstable. References --- https://gnome.pages.gitlab.gnome.org/gtksourceview/gtksourceview-5.0/porting-guide-3-to-4.html https://gnome.pages.gitlab.gnome.org/gtksourceview/gtksourceview-5.0/porting-guide-4-to-5.html And since you'll need to port from GTK3 to GTK4 to use gtksourceview5: https://docs.gtk.org/gtk4/migrating-3to4.html Thanks, Jeremy Bicha
Bug#996646: ITP: gnome-text-editor -- simple text editor for GNOME
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Owner: jer...@bicha.net Control: block -1 by 993598 Control: block -1 by 996609 Package Name: gnome-text-editor Version: 41.1 Upstream Author: Christian Hergert License: GPL-3+ Programming Lang: C Description: simple text editor for GNOME GNOME Text Editor is a simple editor for GNOME focused on being a good general purpose default editor. . It works hard to keep track of changes and state even if you quit the application. You can come back to your work even if you've never saved it to a file. . It is simpler than gedit. Other Info -- This app will be maintained by the Debian GNOME team. Packaging is at https://salsa.debian.org/gnome-team/gnome-text-editor I expect GNOME to switch its default text editor in their "core" to GNOME Text Editor soon. Currently, gedit is the default. gedit will still be available and offers more complex features. GNOME Text Editor uses GTK4 and libadwaita. Thanks, Jeremy Bicha
Re: Multiple teams maintaining one package (proposal)
On Sun, Nov 7, 2021 at 5:36 AM Ole Streicher wrote: > One solution here could be to recognize multiple teams: the "primary > one" (by the maintainer's selection) goes into the "Maintainer:" field > in d/control, and all secondary would go into the "Uploaders:" > field. This would imply that the package is conform to all team > policies, except for the salsa location of the package (i.e. a package > that has the Debian Astro Team as primary team would live in the > salsa.d.o/debian-astro/team/). The GNOME and Accessibility Teams co-maintain a few packages. They are hosted on the GNOME team's Salsa. I believe most have the Maintainer set to the Accessibility Team (like orca) but atkmm1.6 has the Maintainer set to the GNOME team. It works well because the GNOME Team has a lot more packaging style tweaks than the Accessibility team so it's easy for these packages to follow GNOME style without conflicting with a different team's style. Thanks, Jeremy Bicha
Re: ayatana-indicator-messages: bump epoch in package version from to 1
On Sun, Dec 12, 2021 at 8:47 AM Mike Gabriel wrote: > Yeah, I am aware of that possibility. However, I don't really feel > like inheriting the versioning from the Ubuntu package (year.month) in > the Debian package and be forced to carry that one along with me in > the future forever... > > I'd rather use the upstream version (of ayatana-indicator-messages) > and be done with it. What you're asking is unusual because: 1. You *are* the upstream maintainer and control its version numbering. 2. You have forked the old unmaintained Ubuntu project. 3. You explicitly are choosing to take over the Ubuntu binary packages. Therefore, it seems pretty easy to me for you to just bump the upstream version in its next release from 0.9.0 to 13.11.0 (or 14.0 or 14.9.0 or whatever higher number). Blame Ubuntu in your release notes. That seems like the least complex way to handle this. No epochs. No version skew between upstream and Debian. No version skew between the Debian source package and the binary packages. No version skew between Debian and Ubuntu. No tricky version number mangling in debian/rules. Version numbers are cheap. It's really not a big deal to bump your version from 0.9 to 14. After that, you don't have any obligation to do year.month versioning. Thanks, Jeremy Bicha
Bug#1004739: ITP: mozjs91 -- SpiderMonkey JavaScript library
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Owner: jeremy.bi...@canonical.com Package Name: mozjs91 Version: 91.5.1 Upstream Author: Mozilla et al License: MPL-2.0+ etc 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 -- This library will be maintained by the Debian GNOME team. Packaging is at https://salsa.debian.org/gnome-team/mozjs Spidermonkey/mozjs is the JavaScript library from Firefox ESR. gjs in GNOME 42 is switching from mozjs78 to mozjs91 now that Firefox 78 ESR has reached End of Life. Besides GNOME, the only other user of the mozjs78 package in Debian is Cinnamon. It is hoped that Cinnamon will be able to switch to mozjs91 soon too. https://discourse.gnome.org/t/spidermonkey-91/8665 Thanks, Jeremy Bicha
Bug#1006006: ITP: libsoup3 -- HTTP library implementation in C
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Owner: jeremy.bi...@canonical.com Package Name: libsoup3 Version: 3.0.4 Upstream Author: Ximian, Novell, Red Hat, etc. License: LGPL-2.1+ Programming Lang: C Description: HTTP library implementation in C -- Development files It was originally part of a SOAP (Simple Object Access Protocol) implementation called Soup, but the SOAP and non-SOAP parts have now been split into separate packages. . libsoup uses the Glib main loop and is designed to work well with GTK+ applications. This enables GNOME applications to access HTTP servers on the network in a completely asynchronous fashion, very similar to the GTK+ programming model (a synchronous operation mode is also supported for those who want it). . Features: * Both asynchronous (GMainLoop and callback-based) and synchronous APIs * Automatically caches connections * SSL Support using GnuTLS * Proxy support, including authentication and SSL tunneling * Client support for Digest, NTLM, and Basic authentication * Server support for Digest and Basic authentication * Basic client-side SOAP support Other Info -- This library will be maintained by the Debian GNOME team. Packaging is at https://salsa.debian.org/gnome-team/libsoup3 libsoup3 will be needed to fully build GNOME 43 later this year. This is a complex major transition and libsoup2.4 will need to remain in Debian for a while until all reverse dependencies are ported. Migration Guide: https://libsoup.org/libsoup-3.0/ch02.html Upstream porting status tracker: https://gitlab.gnome.org/GNOME/libsoup/-/issues/218 Thanks, Jeremy Bicha
Re: MBF: valgrind-if-available
On Sun, Feb 20, 2022 at 1:46 PM Adam Borowski wrote: > The correct answer currently is: > [amd64 arm64 armhf i386 mips64el mipsel ppc64el s390x powerpc ppc64] > but it keeps changing, and you don't want to track it by hand if I can do > that for you. > > Thus: please [b-]depend on valgrind-if-available. Do you have any suggestions on how to handle this when the valgrind test is set by a configure flag? The way I've been handling it is to just keep a hard-coded list of valgrind architectures in sync between my debian/control and debian/rules. Thank you, Jeremy Bicha
Re: proposed MBF: packages still using source format 1.0
On Mon, Mar 7, 2022 at 10:36 AM Wouter Verhelst wrote: > On Sun, Mar 06, 2022 at 09:25:45PM +0100, Lucas Nussbaum wrote: > > Wouter Verhelst > >aspic > >logtool > > Yeah, no. These will be reduced to "wishlist" and probably tagged > "wontfix". > > The packages work just fine, the source format is still supported, I > have better things to do with my time? I guess you'd be ok with orphaning aspic to allow others to more easily modernize the packaging? https://bugs.debian.org/657083 Thank you, Jeremy Bicha
Re: Is there room for improvement in our collaboration model?
On Sat, Apr 16, 2022 at 8:32 AM Steffen Möller wrote: > The only extra request from my side would be for salsa-maintained > packages to havet the NMU not bypassing the version management. I agree with the idea, except that it's common to want to NMU something that you don't have Salsa commit privileges for. Thanks, Jeremy Bicha
Bug#1013289: ITP: glibmm2.68
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: glibmm2.68 Version: 2.72.1 Upstream Author: The gtkmm & glibmm development teams License: LGPL-2.1+ Programming Lang: C++ Description: C++ wrapper for the GLib toolkit (shared libraries) GLib is a low-level general-purpose library used mainly by GTK+/GNOME applications, but is useful for other programs as well. glibmm is the C++ wrapper for GLib. Other Info -- This library will be maintained by the Debian GNOME team. Packaging is at https://salsa.debian.org/gnome-team/glibmm2.68 The existing glibmm2.4 package tracks releases from the glibmm 2.66.x series and is intended for use with gtkmm3.0 (which uses GTK 3). The new glibmm2.68 ABI is intended for use with gtkmm4.0 (which uses GTK 4). The glib2.68 source package naming has been adopted by other distros: https://repology.org/project/glibmm/versions Thanks, Jeremy Bicha
Bug#1013992: ITP: session-migration -- tool to migrate in user session settings
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, pkg-ayatana-de...@lists.alioth.debian.org Owner: jeremy.bi...@canonical.com Package Name: session-migration Version: 0.3.7 Upstream Author: Canonical License: LGPL-3+ Programming Lang: Perl and C Package: session-migration Description: Tool to migrate in user session settings This tool is used to migrate in session user data when a program is evolving its configuration, or needing to have files moved and so on. . This program is generally autostarted at the very beginning of the session and integrates caching capability. Package: dh-migrations Provides: dh-sequence-migrations Description: debhelper extension for session-migration support This package provides a debhelper extension to perform session migration operations on the installed packages. Other Info -- This has been part of Ubuntu for a decade but can solve real problems for Debian too. It will soon be used by both the GNOME and MATE packaging teams. One of its usecases is migrating user-set gsettings to renamed (or functionally similar new) gsettings keys. Often, upstream doesn't handle this migration themselves. And debhelper otherwise doesn't provide a tool for this. Basically, the way it works is that the package maintainer can provide a script. The script will be run at the next login and session-migration will ensure that the script is only run once. https://manpages.ubuntu.com/manpages/dh_migrations This is a "native" package and will be maintained by the Ayatana Packagers team. Packaging is at https://salsa.debian.org/debian-ayatana-team/session-migration Thanks, Jeremy Bicha
Re: Bug#1013992: ITP: session-migration -- tool to migrate in user session settings
On Tue, Jun 28, 2022 at 8:07 PM Guillem Jover wrote: > > Package: session-migration > > Description: Tool to migrate in user session settings > > This tool is used to migrate in session user data when a program is > > evolving > > its configuration, or needing to have files moved and so on. > > . > > This program is generally autostarted at the very beginning of the session > > and integrates caching capability. > > This looks like an extremely generic name for such tool and package, > when it appears to be restricted to gsettings session data only? It is not restricted to gsettings although gsettings is a good use case for it. Here's an example where it's used for something else: https://salsa.debian.org/gnome-team/gnome-boxes/-/commit/b536a968eb192 It would be nice if the upstream developers would handle user session migrations tasks themselves, but they often don't. > > Package: dh-migrations > > Provides: dh-sequence-migrations > > Description: debhelper extension for session-migration support > > This package provides a debhelper extension to perform session migration > > operations on the installed packages. > > This also seems extremely generic. Migrations could refer to anything, > from databases, to any other data source. Something like > dh-gsettings-migrations seems like would be way better? Despite being around for a decade, it looks like it's only used by about 6 current Ubuntu source packages so a rename is doable if needed. I think I wouldn't even need a transitional package since we'd rebuild all those Ubuntu packages which would get them the properly named dependency. Here's a suggestion: user-session-migration dh-migrate-user-session Providing dh-sequence-migrate-user-session Thank you, Jeremy Bicha
Re: Bug#1013992: ITP: session-migration -- tool to migrate in user session settings
I didn't get a reply yet and we need to make a decision. Thank you, Jeremy Bicha On Tue, Jun 28, 2022 at 9:51 PM Jeremy Bicha wrote: > On Tue, Jun 28, 2022 at 8:07 PM Guillem Jover wrote: > > > Package: session-migration > > > Description: Tool to migrate in user session settings > > > This tool is used to migrate in session user data when a program is > > > evolving > > > its configuration, or needing to have files moved and so on. > > > . > > > This program is generally autostarted at the very beginning of the > > > session > > > and integrates caching capability. > > > > This looks like an extremely generic name for such tool and package, > > when it appears to be restricted to gsettings session data only? > > It is not restricted to gsettings although gsettings is a good use case for > it. > > Here's an example where it's used for something else: > https://salsa.debian.org/gnome-team/gnome-boxes/-/commit/b536a968eb192 > > It would be nice if the upstream developers would handle user session > migrations tasks themselves, but they often don't. > > > > Package: dh-migrations > > > Provides: dh-sequence-migrations > > > Description: debhelper extension for session-migration support > > > This package provides a debhelper extension to perform session migration > > > operations on the installed packages. > > > > This also seems extremely generic. Migrations could refer to anything, > > from databases, to any other data source. Something like > > dh-gsettings-migrations seems like would be way better? > > Despite being around for a decade, it looks like it's only used by > about 6 current Ubuntu source packages so a rename is doable if > needed. I think I wouldn't even need a transitional package since we'd > rebuild all those Ubuntu packages which would get them the properly > named dependency. > > Here's a suggestion: > user-session-migration > dh-migrate-user-session Providing dh-sequence-migrate-user-session
Re: Bug#1013992: ITP: session-migration -- tool to migrate in user session settings
On Wed, Jul 6, 2022 at 6:45 PM Fabio Fantoni wrote: > However, I have a doubt, but it allow you to do any operation on user > profiles? in this case, even if it is useful, its wrong use (intentional > or by mistake) would be worrying Yes, it can do anything. .deb packages don't really have limits. You must trust the .deb publisher. Otherwise, you can use something like Snap which has significant restrictions on what Snap publishers can do with the apps they publish. Thanks, Jeremy Bicha
Re: Bug#1014908: ITP: gender-guesser -- Guess the gender from first name
On Thu, Jul 14, 2022 at 3:12 PM Roberto C. Sánchez wrote: > > On Thu, Jul 14, 2022 at 05:48:56PM +0500, Andrey Rahmatullin wrote: > > On Thu, Jul 14, 2022 at 08:45:24AM -0400, Roberto C. Sánchez wrote: > > > > > > Filing the ITP then immediately uploading seems really sensible, > > More sensible than not filing it? > > This defeats both purposes of an ITP: getting it discussed and working as > > a mutex for people who are thinking about packaging the same software. Are > > there other purposes? > > > Filing the ITP and then uploading immediately seems like it still fully > allows for both things you describe. I also file ITP bugs and try to CC debian-devel as an announcement that the package is coming soon to Debian. I generally wait to file the ITP until my packaging is nearly ready in Salsa and provide the Salsa link in my ITP bug which makes it easy for someone to review it if they want. Thank you, Jeremy Bicha
Re: Bug#1014908: ITP: gender-guesser -- Guess the gender from first name
On Thu, Jul 14, 2022 at 2:41 PM Roberto C. Sánchez wrote: > > On Thu, Jul 14, 2022 at 11:14:43AM +0100, Steve McIntyre wrote: > > edw...@4angle.com wrote: > > > > >Package: wnpp > > >Severity: wishlist > > >Owner: Edward Betts > > >X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org > > > > > >* Package name: gender-guesser > > > Version : 0.4.0 > > > Upstream Author : Israel Saeta Pérez > > >* URL : https://github.com/lead-ratings/gender-guesser > > >* License : GPL-3 & GFDL-1.2+ > > > Programming Lang: Python > > > Description : Guess the gender from first name > > > > Oh, not *another* package that tries to guess things from names. > > > > Do you have a real use for this package? > > Why in the world is that even a relevant question? There are plenty of > packages in the archive which are useful to essentially nobody apart > from the maintainer and there are even packages which are maintained > without being useful to the maintainer at all (but rather useful to > others). > > > There are a *lot* of issues > > in this area, and mis-gendering people is not something to risk > > lightly... > > > > "There are a *lot* of issues in this area" seems rather nebulous. In > which area? Given the fact that we have clear and rather unambiguous > guidelines for what constitutes software which is appropriate for > inclusion in the archive, and given that on its face this software does > not seem to be in conflict with any of those guidelines, what then is > the problem? BTW, I'm not interested in any sort of "well I don't like > ..." or "such and such could offend so and so ..." sort of arguments. Debian has a Diversity Statement [1] which says that Debian welcomes people regardless of how they identify themselves. Trans people and non-binary people face a lot of discrimination, harrassment and bullying around the world. That bad treatment of these people is against Debian's core values. Therefore, the Debian Project wouldn't want to distribute software that appears to facilitate that kind of harassment, regardless of the software license it is released under. We might not want to distribute such software even if it also has non-harmful uses. We don't have to distribute *everything* ourselves. [1] https://www.debian.org/intro/diversity Thank you, Jeremy Bicha
Bug#1016316: ITP: gnome-shell-extension-gsconnect -- KDE Connect implementation for GNOME Shell
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: gnome-shell-extension-gsconnect Version: 50 Upstream Author: Andy Holmes License: GPL-2+ Programming Lang: JavaScript (and a Python extension for file browser integration) Description: KDE Connect implementation for GNOME Shell This extension enables you to connect your phone or other devices to your system, sending remote sms, see phone calls, share notifications, send files. . To connect an Android device, install the KDE Connect Android app from the Google Play Store or F-Droid. . GSConnect is a complete KDE Connect protocol implementation for GNOME Shell with Nautilus, contacts and Shell integration. Package Name: gnome-shell-extension-gsconnect-browsers Description: Browser support of KDE Connect implementation for GNOME Shell This extension enables you to connect your phone or other devices to your system, sending remote sms, see phone calls, share notifications, send files. . This package contains Chromium, Firefox and Chrome integration support to send text via sms or open links on your phone. Other Info -- This extension will be maintained by the Debian GNOME team. Packaging is at https://salsa.debian.org/gnome-team/shell-extensions/gnome-shell-extension-gsconnect Packaging is based on the Ubuntu package. No watch file is provided since upstream's version numbering sequence is currently non-linear. https://github.com/GSConnect/gnome-shell-extension-gsconnect/issues/1412 Thanks, Jeremy Bicha
Bug#1016606: ITP: libpanel -- IDE paneling library for GTK
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: libpanel-1-1 (etc) Version: 1.0~alpha Upstream Author: Christian Hergert License: LGPL-3+ Programming Lang: C Description: IDE paneling library for GTK libpanel is a collection of GTK widgets for IDE-like applications targeting GNOME using GTK 4 and libadwaita. Other Info -- This package will be maintained by the Debian GNOME team. Packaging is at https://salsa.debian.org/gnome-team/libpanel It is a required dependency for GNOME Builder 43 which will use GTK4. Thanks, Jeremy Bicha
Bug#1018908: ITP: cairomm1.16 -- C++ wrappers for Cairo
Package: wnpp Severity: wishlist Owner: jeremy.bi...@canonical.com Control: block 1006728 by -1 X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org Package Name: libcairomm-1.16-1 Version: 1.16.1 Upstream Author: The cairomm Development Team License: LGPL-2+ Programming Lang: C++ Description: C++ wrappers for Cairo cairomm provides C++ bindings for the Cairo graphics library, a multi-platform library providing anti-aliased vector-based rendering for multiple target backends. Other Info -- This library will be maintained by the Debian GNOME team. Packaging is at https://salsa.debian.org/gnome-team/cairomm1.16 The existing cairomm source package tracks releases from the cairomm 1.14.x series (1.0 ABI) and is intended for use with gtkmm3.0 (which uses GTK 3). The new cairomm1.16 ABI is intended for use with gtkmm4.0 (which uses GTK 4). The cairomm1.16 source package naming has been adopted by other distros: https://repology.org/project/cairomm/versions Thanks, Jeremy Bicha
Bug#1018974: ITP: pangomm2.48 -- C++ wrapper for Pango
Package: wnpp Severity: wishlist Owner: jeremy.bi...@canonical.com Control: block -1 by 1018908 Control: block 1006728 by -1 X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org Package Name: libpangomm-2.48-1 Version: 2.50.0 Upstream Author: The pangomm Development Team License: LGPL-2.1+ Programming Lang: C++ Description: C++ Wrapper for pango Pangomm is a C++ wrapper for the pango library. Originally part of gtkmm, pangomm provides convenient C++ interfaces for handling both the layout and internationalization of text in graphical applications. Other Info -- This library will be maintained by the Debian GNOME team. Packaging is at https://salsa.debian.org/gnome-team/pangomm2.48 The existing pangomm source package tracks releases from the pangomm 2.46.x series (1.4 ABI) and is intended for use with gtkmm3.0 (which uses GTK 3). The new pangomm2.48 ABI is intended for use with gtkmm4.0 (which uses GTK 4). The pangomm2.48 source package naming has been adopted by other distros: https://repology.org/project/pangomm/versions Thanks, Jeremy Bicha
Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio
On Thu, Sep 8, 2022 at 11:59 AM Dylan Aïssi wrote: > I have been asked several times regarding when Debian will switch its default > sound server from PulseAudio to PipeWire without having an official answer. I think it's a good idea to switch the Debian GNOME default sound service to PipeWire now. I've just been waiting for wireplumber 0.4.11-4 to make it through the NEW queue since it fixes a minor packaging issue. A brief explanation of the project and what it does can be found at https://pipewire.org/ and more details are at https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ >From what I've seen, PipeWire will be as good as or better than PulseAudio for most users. By switching now, we should get enough feedback from both Debian Testing and Ubuntu 22.10 to fix serious bugs or perhaps revert to PulseAudio if necessary before we freeze too much for Debian 12. Most but not all of the Ubuntu desktop flavors have also switched to PipeWire for Ubuntu 22.10. I'm not involved in the decisions for other Debian desktop flavors but they would get the same advantages and their apps designed for PulseAudio should still work with PipeWire. Thank you, Jeremy Bicha
Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio
On Wed, Sep 14, 2022 at 8:07 AM Marvin Renich wrote: > A library transition that affects many rev-deps but is otherwise > transparent to the end user is completely different from changing the > audio stack where the end user will be required to learn a new set of > tools and configuration files/syntax. I believe you are significantly overstating the consequences of this switch. It is just a dependency swap in meta-gnome3. The vast majority of users will not have trouble configuring their audio. PipeWire implements the PulseAudio API. There is no basis to the idea that we must make all major changes to Debian at the beginning of Debian's release cycle. You're also compressing the timeline. Debian 12 will not be released 4 months from now. We have a transition freeze in January which we understand to be the deadline for when we ought to have made a final decision on this topic. We are still able to fix release critical bugs until the Release and after the release as stable updates. I think we should make the swap this week so we can see the actual effects instead of hypothetical concerns. Thank you, Jeremy Bicha
Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio
On Wed, Sep 14, 2022 at 11:36 PM Felipe Sateler wrote: > What does "switch right now" mean? Just switching gnome-core? What about > the other users? They would all have to switch their order from > `pulseaudio | pipewire-pulse` to `pipewire-pulse | pulseaudio`. Otherwise > you would have a different audio server depending on which order packages > are installed. Moreover, what about upgrades? Would they be forcefully > upgraded (ie, drop the pulseaudio alternative)? Or would they be allowed > to continue using pulseaudio (which wouldn't migrate them because the > dependency would be satisfied)? This is what I mean with Yes, I noticed the upgrade problem. apt recognizes that the alternate dependency is already satisfied and doesn't install the preferred (first) dependency. So my draft was for gnome-core to unconditionally switch to pipewire: https://salsa.debian.org/gnome-team/meta-gnome3/-/merge_requests/7/diffs For context, gnome-core in Debian 11 "Bookworm" unconditionally depends on pulseaudio. > > This give us 4 months until the "transition and toolchain freeze" on > > 2023-01-12 [6]. We will also receive feedback from Ubuntu 22.10 (that is > > also doing the switch) planned to be released on 2022-10-20 [7]. > > Do you know what the transition plan for ubuntu is? Are they patching all > rdeps to switch to `pipewire-pulse`? For Ubuntu Desktop, the ubuntu-desktop-minimal metapackage depends on pipewire-pulse & wireplumber & recommends libspa-0.2-bluetooth. Ubuntu's metapackages are generated using germinate and alternate dependencies aren't supported at all. https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/tree/desktop-minimal (Recommends are the lines with parentheses). In general, almost everything in Debian's GNOME metapackages are a hard Depends instead of a Recommends. In our experience, we get a lot of bugs and complaints about things not working correctly because there are a lot of people who believe it's a good idea to disable installing Recommends system-wide and have trouble understanding why their system doesn't run well. Interestingly, in Ubuntu, a lot of the ubuntu-desktop metapackage dependencies are just Recommends. But even there, the sound server is a hard dependency. pipewire and wireplumber are systemd user services. Maybe we just need to write up instructions for disabling PipeWire and switching to PulseAudio. Or maybe we could create a Debian package that handles this. That way we could keep the hard dependency in gnome-core so that upgrades do the expected thing, but there is an easy escape. However, I've not seen a single complaint from Ubuntu about switching to PipeWire. So maybe we still ought to switch gnome-core now to get real feedback. Thank you, Jeremy Bicha
Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio
On Sun, Sep 18, 2022 at 4:53 PM Diederik de Haas wrote: > I think there currently aren't that many Debian users which do use PW and I > think that switching the default audio provider in all of Debian (not just > Gnome) is FAR more involved then the impression I got from this ML thread. At least on my part, this discussion is only about GNOME, specifically, the gnome-core package and probably gnome-settings-daemon. You're still able to keep using PulseAudio especially if you are using other desktops. I don't know when and if other Debian desktops will switch because I'm not involved in those decisions. I'll likely upload the gnome-core change to Unstable tomorrow. Thank you, Jeremy Bicha
Re: Firmware GR result - what happens next?
On Sun, Oct 2, 2022 at 10:53 AM Steve McIntyre wrote: > On Sun, Oct 02, 2022 at 04:43:47PM +0200, Michael Biebl wrote: > >What's the plan for upgraded systems with an existing /etc/apt/sources.list. > >Will the new n-f-f section added on upgrades automatically(if non-free was > >enabled before)? > > So this is the one bit that I don't think we currently have a good > answer for. We've never had a specific script to run on upgrades (like > Ubuntu do), so this kind of potentially breaking change doesn't really > have an obvious place to be fixed. There is /etc/apt/sources.list.d/ . One idea is that you could have a package install a non-free-firmware apt source line there without needing to touch anyone's primary /etc/apt/sources.list I'm guessing things that change apt sources for mirrors would need to be able to handle that file, but maybe they needed to handle sources.list.d/ anyway. Thank you, Jeremy Bicha
Re: Q: How about versions/features in bookworm?
On Sun, Nov 6, 2022 at 5:58 AM Hideki Yamane wrote: > And, some upstream majar version will be released during Debian's > release freeze. Well, how we can save those "missed release train" > releases? Just "ignore and wait 2 years" is easy to say, but if we > can introduce those in point releases with "predictable" schedule, > it would be better, IMHO. > > * KDE Plasma: 5.27 - 2023-02? > * GNOME : 44 - 2023-03 The Debian GNOME team doesn't have anywhere close to enough developer time and energy to make backporting a new major GNOME release feasible. Thank you, Jeremy Bicha
Bug#1029907: ITP: xdg-terminal-exec -- user default terminal execution utility
Package: wnpp Severity: wishlist Owner: jeremy.bi...@canonical.com X-Debbugs-CC: debian-devel@lists.debian.org Package Name: xdg-terminal-exec Version: git snapshot Upstream Author: Vladimir Kudrya License: GPL-3+ Programming Lang: Shell Description: user default terminal execution utility xdg-terminal-exec is an implementation of a proposed freedesktop.org specification for launching a user's default terminal app. Other Info -- I will maintain this with the Debian freedesktop.org team. Packaging is at https://salsa.debian.org/freedesktop-team/xdg-terminal-exec This solves a problem: currently you can use update-alternatives to choose a default terminal for a Debian system, but what happens when you have multiple users on the same Debian system with different preferences? I don't think the "proposed specification" has been fully drafted yet. There is some discussion at https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/54 and over the years in the xdg mailing list. More recently, the alpha for glib 2.76 (part of GNOME 44 Alpha) now supports xdg-terminal -exec and GNOME Terminal 3.46.7 includes the necessary metadata file. We might backport the glib feature to Debian Bookworm, but it is quite late in Bookworm's release process. The metadata would also need to be added to other terminal emulator apps and desktops that use glib would need to ship a metadata file with their preferred terminal emulators. There is no GUI way for users to override the preference; they would need to add/edit the config file in their home directory manually. More details in the README at https://github.com/Vladimir-csp/xdg-terminal-exec Thanks, Jeremy Bicha
Re: Bug#1029907: ITP: xdg-terminal-exec -- user default terminal execution utility
On Sat, Jan 28, 2023 at 7:18 PM Simon McVittie wrote: > I think a better route might be to get it into experimental for now, then > when it seems like it has stabilized more, put it into unstable/trixie > and potentially also bookworm-backports. It's in the NEW queue targeted for experimental now. The only place it's been packaged so far is the Arch Linux AUR: https://repology.org/project/xdg-terminal-exec/versions Thank you, Jeremy Bicha
Re: Merge request friendly handling of debian/changelog
On Mon, Oct 21, 2019 at 11:06 PM Bastian Blank wrote: > There is "gbp dch", which ignores merge commits (so no really good for > merge requests), but I don't consider it to have enough control over the > content of the changelog. Just set your merge settings per project to fast-forward. Thanks, Jeremy
Re: Usage of DEP5
On Sat, Nov 9, 2019 at 4:16 PM Scott Kitterman wrote: > On Saturday, November 9, 2019 3:05:21 PM EST Ole Streicher wrote: > > Hi Scott, > > > > Scott Kitterman writes: > > > I'd like to suggest thinking about this from the perspective of new > > > contributors. Copyright-format 1.0 has a lot of specific requirements. > > > Do we really want to recommend that before someone can package software > > > for Debian they need to learn this too (hint: I think no - there's plenty > > > to learn to get started that's actually necessary). > > > > I am surprised here, since I would recommend exactly the opposite: For a > > beginner, a well-structured format is much better to fill in than a "The > > copyright must be somehow documented in d/copyright". > > > > CF1.0 helps since it makes clear which information to put there, one > > doesn't have to think about the structure etc. Especially with the help > > of the sponsor. > > > > Following magic rules really helps starting to contribute. > > I think there are enough "Oh, you missed a colon here, please fix and I'll > review again" in Debian packaging without adding more. Fundamentally, > copyright-format 1.0 adds a pile of possible things to get wrong that are > actually in no way relevant to the purpose of debian/copyright. Focusing on > form over function isn't the first thing contributors need to learn. Sorry to be a jerk. And sorry to go off-topic. But… I feel like new contributors are discouraged by the inconsistent and sometimes overly formal copyright documentation rejection criteria. For instance, the first point mentioned in the ftpmaster rejection email is a rejection for not specifying the license of autotools cruft. The packager (who is neither a DD nor a DM) has told me that they feel like they might as well switch the buildsystem to meson, not necessarily because of any technical build improvements, but primarily to make it easier to appease the ftpmasters. It does not feel right to me that packages that use Copyright Format 1.0 are held to a **higher** standard than packages that don't. I personally have spent many hours working on a singler package that was required for GNOME to work (mozjs38) just to try to build a complete enough d/copyright file to clear the NEW queue. And I am an experienced packager. [1] https://alioth-lists.debian.net/pipermail/pkg-ayatana-devel/2019-September/002438.html Thanks, Jeremy Bicha
Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)
On Mon, Nov 11, 2019 at 2:59 AM Thomas Goirand wrote: > On 11/11/19 1:02 AM, Theodore Y. Ts'o wrote: > > On Sun, Nov 10, 2019 at 11:20:45PM +0100, Thomas Goirand wrote: > >> > >> Please, *never* do that. It's generally a very bad idea to write > >> anything to debian/gbp.conf. It's as if you were adding your text editor > >> preferences in the package. Instead, please prefer writing in ~/.gbp.conf. > > > > I keep most of my git-buildpackage settings which are specific to my > > developer environment in ~/.gbp.conf. However, there are some gbp > > settings which are specific to the repository set up, and those I > > think, IMHO, *are* appropriate for debian/gbp.conf. For example: > > > > [DEFAULT] > > pristine-tar = True > > upstream-tag='v%(version)s' > > debian-branch=debian/master > > The first 2, yes. The last one, it's my opinion that it's useless, and > that you only need it because "ignore-branch = True" isn't the default > in git-buildpackage. It's ok as long as you always keep the same > packagig branch, but if, like in my team, we need a new branch name > every 6 months, and for 400+ repositories, then keeping the branch name > declared in debian/gbp.conf becomes super annoying (as it forces one to > change the "debian-branch" each time). Could you please add debian/gbp.conf back to your packages? As I understand it, I think your preferred settings would look something like this: [DEFAULT] ignore-branch = True pristine-tar = False [buildpackage] sign-tags = True [dch] multimaint-merge = True [import-orig] upstream-tag = %(version)s [pq] patch-numbers = False It is absolutely not possible to set the correct pristine-tar=True/False in ~/.gbp.conf to work with your packages (which avoid pristine-tar) and the vast majority of gbp packages in Debian which do use pristine-tar. Those settings are specific to the workflow for that repo, and everyone using that repo needs to use those same settings to avoid issues. On the other hand, there are some developer-level preferences like export-dir and "pbuilder = True". Those should not be in the repo's debian/gbp.conf but they should be in ~/.gbp.conf . Thanks, Jeremy Bicha
Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)
On Tue, Nov 12, 2019 at 5:23 AM Thomas Goirand wrote: > On 11/11/19 12:50 PM, Jeremy Bicha wrote: > > It is absolutely not possible to set the correct > > pristine-tar=True/False in ~/.gbp.conf to work with your packages > > (which avoid pristine-tar) and the vast majority of gbp packages in > > Debian which do use pristine-tar. Those settings are specific to the > > workflow for that repo, and everyone using that repo needs to use > > those same settings to avoid issues. > > I don't think what you wrote above is correct. None of the options you > mentioned are mandatory. If GBP doesn't see the use of pristine-tar, it > will assume that we're using an upstream tag, which is fine. > ... > Besides this, nobody is forced to use gbp. Just typing "sbuild" to build > a package is also perfectly valid. So why adding preferences for one set > of tooling, when there's many alternatives? It doesn't make sense. Let me try to be more specific. Many packages are maintained by people who use gbp. Many packages have pristine-tar branches but do not have "pristine-tar = True" set. When I work on one of these packages (and I work on many packages with many maintainers), I need to have "pristine-tar = True" set in my ~/.gbp.conf. However, when I then want to work on an OpenStack package, I have to change my user config to set "pristine-tar = False". This is a very manual process and I'm likely to make a mistake. Ideally, packages maintained by someone who wants to consistently use pristine-tar will have that set in debian/gbp.conf and the minority of maintainers who don't will have that set in debian/gbp.conf too. While you could use sbuild to build gnome-calculator for instance, you do have to use gbp to **maintain** gnome-calculator -- especially when packaging new versions. That is because gnome-calculator is team-maintained by the Debian GNOME team and we have guidelines for how our packages are maintained [1]. To make life easier for contributors, we enforce as many of those guidelines as possible in debian/gbp.conf. Similarly, you have guidelines for how OpenStack packaging updates and bugfixes are handled and it seems to me like it would make a whole lot more sense for you to explicitly "forbid" pristine-tar from being used in your packages, as long as you are the maintainer and you believe that pristine-tar is unsuitable for those packages. [1] https://wiki.debian.org/Gnome/Git Thanks, Jeremy Bicha
Re: Overinterpretation of DFSG? QR code for receiving donation is non-free???
On Mon, Mar 30, 2020 at 4:32 PM Russ Allbery wrote: > I do understand the desire to have the URL in a form that's easily > searchable, but I don't think people are thinking through the implications > of saying we're not allowed to distribute sources even in formats that are > round-trip convertable to editable formats, but have to ensure every > artifact is in a form that can be *directly* edited. The implications for > the archive would be massive busywork that would have no significant > impact on software freedom. I think this goes back to the epic "Editorial amendments" GR which, among other things, applied DFSG beyond code to other things like image files [1]. Over 15 years later, it's still really hard to figure out how to apply the aspirational guideline to things that are not code. The burden of compliance with various interpretations is very inconsistently imposed on Debian contributors. Let's say I take a photo of myself to include in an app so that users can appreciate what I look like. What is the "preferred form of modification"? If it's 15 years later and I no longer look the same, would I edit the photo with free software to make it look like me or would I just take another photo? I believe that the overwhelmingly majority of people who would want to update or change a QR code image would create a whole new image from scratch with one of many QR code generators (some are open source; some aren't) instead of trying to use an app like the GNU Image Manipulation Program (or some specialized decoder/recoder app) to try to tweak the file. Therefore, in my opinion, the preferred form of modification for a QR code is whatever you want. There should not be any requirement that you have to use a DFSG-compatible generator to create the image. Just like there is no requirement that my camera run DFSG-compatible software or that I only use DFSG-compatible editors or software or websites whenever I contribute to Debian. [1] https://www.debian.org/vote/2004/vote_003 Thanks, Jeremy Bicha
Re: Mass bug filing: dependencies on GTK 2
On Wed, Apr 29, 2020 at 5:58 PM Adam Borowski wrote: > I wonder, perhaps it'd be better to use "normal" for packages that _use_ > GTK2, and no bug at all for those that provide an input method/theme/etc > for GTK2+3? A bug that's not supposed to be actioned upon is no good. > > And probably an immediate ITR for GTK2-only inputs/themes. Actually, for themes (and input methods, etc.), I recommend using a hack to avoid the GTK2 dependency. It's safe because the only thing that will use a GTK2 theme is GTK2 so it's unnecessary for the theme itself to depend on GTK2. It's useful because we don't have a good way to provide a user with the GTK2 version of an installed theme at the time they install GTK2 unless we just install the GTK2 theme at the same time as the GTK3 theme. Sort of a Just-In-Time apt dependency resolution would be nice. https://salsa.debian.org/gnome-team/gnome-themes-extra/-/commit/4c5691edd Thanks, Jeremy Bicha
Re: Proposal: use /usr/bin/open as an alternative for run-mailcap and others.
On Wed, Oct 7, 2020 at 4:54 PM Charles Plessy wrote: > /bin/open has been kindly freed a couple years ago (#732796) and I would > like to propose to repurpose it as a standard command for opening files, > like on Mac OS and NextStep before it. You should be aware that Ubuntu implemented this idea 2 years ago. (I'm sure Ubuntu developers would love for this to be implemented by other distros or further upstream.) https://launchpad.net/bugs/1624022 Thanks, Jeremy Bicha
Re: Proposal: use /usr/bin/open as an alternative for run-mailcap and others.
On Wed, Oct 7, 2020 at 7:15 PM Jeremy Bicha wrote: > You should be aware that Ubuntu implemented this idea 2 years ago. Oh, I misread. Ubuntu used /usr/bin/browse but 'open' sounds a lot better. Thanks, Jeremy Bicha
Re: Proposal: use /usr/bin/open as an alternative for run-mailcap and others.
On Tue, Oct 13, 2020 at 1:52 PM Marvin Renich wrote:
>
> * Noah Meyerhans [201013 00:54]:
> > "open" is a verb commonly used to describe the action of accessing a
> > file in Linux. You used it yourself above, and it's one of the most
> > prominent functions in the file API. It seems sensible to provide a
> > tool that matches the verb most commonly used to describe this action.
> >
> > The availability of
> > /usr/bin/open wouldn't preclude your use of whatever program you want to
> > use. What it would do is provide a convenient utility to support people
> > who don't (yet) have a preference for what application they want to use
> > to open a file. Maybe they have only basic needs, or are unfamiliar
> > with the file type and its associated commands. There are surely many
> > other reasons.
>
> Earlier in this thread, the program "see", part of mime-support, was
> mentioned as already providing this functionality. What does the
> proposed "open" do that "see" doesn't, or what does it do in a
> significantly different way that having both of them would be a benefit?
>
> So far, the only answer I have seen is that MacOS users are familiar
> with open. To me, this is not significant enough. A symlink or cover
> script that does simple massaging of the arguments, which invokes an
> existing utility like run-mailcap, would be better served by a
> macos-helpers package that can become a collection of utilities that
> help users coming from MacOS feel more comfortable in Linux. These
> wouldn't clutter the $PATH space for users who did not want them.
>
> The other difference that I remember being mentioned is that the
> proposed open only handled files, not URLs, but the author was willing
> to add that functionality to open if it was deemed popular.
>
> Describing a clear benefit to having both open and see would help
> immensely. Alternatively, convincing the mime-support authors that open
> should replace see would also work.
This thread is full of people who strongly prefer "open" over "see"
("see" is also little known). Add me to that list. In this case, I
don't care whether other operating systems do it or not.
I think "see" was used because "open" was not available. I don't know
why you are so interested in having "see" go away. It could be removed
but it's not clear at all to me that it needs to be removed at the
same time "open" is added. (I don't see anything else that would want
to use "see".)
Thanks,
Jeremy Bicha
> If open does not provide any real benefit over see, I would not want it
> to be in the transitive Depends or Recommends of a standard Debian
> desktop installation, which would then obviate its usefulness in the
> archive (except as a macos-helper as above).
>
> ...Marvin
Bug#836354: ITP: libgepub -- library to read epub files
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package name: libgepub Version: 0.4-1 Upstream Author: Daniel Garcia URL: https://numixproject.org/ License: LGPL-2.1+ Description: library to read epub files libgepub is a GObject based library for handling and rendering epub documents. libgepub provides a C library and GObject Introspection bindings which allow the library to be easily used in several other programming languages. libgepub is required by gnome-documents 3.22 which introduces epub support to its Books app. libgepub is now hosted by the GNOME Project. I am a Debian Maintainer and I intend to package this within the Debian GNOME Packaging Team. Thanks, Jeremy Bicha
Bug#854951: ITP: recipes -- Recipe application for GNOME
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package Name: recipes Version: 0.12-1 Upstream Author: Matthias Clasen URL: https://wiki.gnome.org/Apps/Recipes License: GPL-3+ Description: Recipe application for GNOME GNOME Recipes is an easy-to-use application that will help you to discover what to cook for today, tomorrow, the rest of the week, and your special occasions. GNOME Recipes comes with a collection of recipes that have been collected by GNOME contributors from all over the world. It also lets you store your own recipes, and share them with your friends. I am a Debian Maintainer and I intend to package this within the Debian GNOME Packaging Team. https://anonscm.debian.org/git/pkg-gnome/recipes.git Thanks, Jeremy Bicha
Re: Bug#854951: ITP: recipes -- Recipe application for GNOME
Control: forwarded -1 https://bugzilla.gnome.org/778531 On Sun, Feb 12, 2017 at 9:22 AM, Simon McVittie wrote: > I think this is too generic. The upstream name is Recipes, and that name is > fine within the context of GNOME (particularly when its machine-readable > name is actually org.gnome.Recipes), but within Debian/Ubuntu it would > seem more reasonable to call it gnome-recipes. Thanks. I requested that the developer change the name to gnome-recipes. Jeremy Bicha
Re: Bug#854951: ITP: recipes -- Recipe application for GNOME
Control: rename -1 ITP: gnome-recipes: Recipe application for GNOME On Sun, Feb 12, 2017 at 10:30 AM, Simon McVittie wrote: > On Sun, 12 Feb 2017 at 09:44:53 -0500, Jeremy Bicha wrote: >> On Sun, Feb 12, 2017 at 9:22 AM, Simon McVittie wrote: >> > I think this is too generic. The upstream name is Recipes, and that name is >> > fine within the context of GNOME >> >> Thanks. I requested that the developer change the name to gnome-recipes. > > That isn't actually what I said. As an upstream name, in context, > Recipes is fine. In an OS distribution that isn't particularly GNOME-centric, > it isn't. Mapping between the two is part of the OS distributor job. The rename is done. The upstream project is still named 'recipes' but the binary and data directories are named gnome-recipes. The Debian source and binary package are named gnome-recipes too. Force-pushed since it's a new repo and I didn't know how to make gbp/pristine-tar handle the rename: https://anonscm.debian.org/git/pkg-gnome/gnome-recipes.git Thanks, Jeremy Bicha
Re: Help requested: Packages which FTBFS randomly
On Wed, Feb 15, 2017 at 2:36 PM, Santiago Vila wrote: > Allowing packages to fail 50% of the time is interpreting Release > Policy in a somewhat twisted way. Except that your build system is far more limited than the average system used to build packages in 2017. Thanks, Jeremy Bicha
Re: python2 warnings (Re: Why do we list individual copyright holders?
On Wed, Jan 3, 2018 at 6:46 AM, Holger Levsen wrote: > On Sun, Dec 31, 2017 at 09:50:10PM +0800, Paul Wise wrote: > in the vast majority of cases this is not actionable for us as package > maintainers, which is why I'm going to lintian override these warnings > for src:munin. Has the python2 dependency issue been reported upstream yet? Thanks, Jeremy Bicha
Re: salsa.debian.org (git.debian.org replacement) going into beta
On Thu, Jan 4, 2018 at 7:01 AM, Raphael Hertzog wrote: > I agree. I have plans to create email addresses like > team+@tracker.debian.org that could be used for this purpose. > The package tracker would automatically add those packages to the > respective team. > > We could then expand the use of this email address also for discussion > between team members. If it looks like an email address, I think people will expect to be able to email it without having to join a team first. Or at least I think people would expect a reject message explaining what to do for the email to be delivered. (Maybe that's what you meant, but it wasn't clear to me.) Thanks, Jeremy Bicha
Re: (was: Re: Bug#886238: Please introduce official nosystemd build profile)
On Tue, Jan 9, 2018 at 9:07 AM, Johannes Schauer wrote: > So we > could talk about whether we should allow more build profiles that change > binary > package contents but so far I don't see the use case for them and thus the > discussion would be a bit academic. Ok, let me try to provide a more practical use case for you then. At times, Ubuntu needs to avoid certain build-dependencies because they would add an unwanted "universe" binary dependency to a "main" package. In some cases, that is the *only* change Ubuntu makes to the package. I believe it benefits Debian for Ubuntu and Debian packaging to be as shared as much as possible. https://launchpad.net/bugs/1734339 Thanks, Jeremy Bicha
Updating the Maintainer field in preparation for Alioth's shutdown?
According to the schedule [1], incoming mail will be disabled for mailing lists hosted at Alioth in less than 2 weeks. I am still confused about what we are recommending that maintainers and teams do, so I'm asking questions now. :) 1. Are the lists still expected to stop accepting new mail on that date? 2. I assume that efforts to provide a transitional "continuation" email system haven't been successful yet, right? 3. If a team manages to get a lists.debian.org address, it's recommended that they switch the Maintainer fields in their packages from the Alioth list address to that address, right? 4. There may eventually be a tracker.debian.org team contact service that might be a better fit for the Maintainer field than lists.debian.org but that isn't expected before the deadline, right? [1] https://wiki.debian.org/Alioth#News Thanks, Jeremy Bicha
Bug#888208: ITP: libmanette -- simple GObject game controller library
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Owner: jbi...@debian.org Package Name: libmanette Version: 0.1.2 Upstream Authors : Adrien Plazas License : LGPL-2.1+. Programming Lang: C Description: Simple GObject game controller library libmanette is a library for using game controllers using an API inspired by GDK's device and event handling. It supports the W3C Draft Gamepad specification. Other Info -- libmanette is required for the 3.28 version of the GNOME Games app (packaged in Debian as gnome-games-app). GNOME 3.28 will be released in mid-March. The Debian GNOME team currently intends to maintain this package. Packaging is at https://salsa.debian.org/gnome-team/libmanette Upstream is at https://gitlab.gnome.org/aplazas/libmanette Thanks, Jeremy Bicha
Re: FTBFS with parallel make
On Fri, Jan 26, 2018 at 9:38 AM, Andrey Rahmatullin wrote: > I wonder what percent of the packages has compat < 10. Well start with https://lintian.debian.org/tags/package-uses-deprecated-debhelper-compat-version.html Thanks, Jeremy Bicha
Re: Removing packages perhaps too aggressively?
On Wed, Jan 31, 2018 at 2:14 PM, Andrej Shadura wrote: > For example, in #616376, gbdfed was removed This happened 7 years ago. Sorry :( > Here you go, there's #871004 for you. Missed jessie, stretch, > not in testing, no uploads since the beginning of 2017. I don't think you'll get much sympathy for a package being removed from unstable when it hasn't shipped with a Debian release since Wheezy, and has continuously been out of Testing for 3.5 years. Thanks, Jeremy Bicha
Re: Removing packages perhaps too aggressively?
On Wed, Jan 31, 2018 at 3:03 PM, Christoph Biedl wrote: > Or for example the xmem removal (#733668): 4 years ago. > More suggestions for the, say, manual removals (mostly ROM, ROP, RoQA): > And also give it some time, I'd suggest some two to four weeks. I don't think we need to add an artificial delay for package removals that are approved by the package maintainer. Thanks, Jeremy Bicha
What is the point of RFA? Was: Re: proposal: ITR
On Thu, Feb 1, 2018 at 5:46 PM, Thomas Goirand wrote: > We already have RFA, where maintainers are asking for adoption. I fail > to see how a different type of bug will trigger a quicker adoption. An > ITR is going to (unfortunately) achieve the exact same thing as an RFA, > which in most cases is ... no much. What is the point of RFA? I mean why don't you just Orphan it and continue to maintain it with QA uploads until a volunteer wants to adopt it? See this for reference: https://www.debian.org/doc/manuals/developers-reference/pkgs.html#orphaning Thanks, Jeremy Bicha
Debian part of a version number when epoch is bumped
Hi, moon-buggy recently had its epoch bumped. The old version is 1.0.51-11, the new version is 1:1.0.51-1. I opened https://bugs.debian.org/887740 to request that the version number be bumped to 1:1.0.51-12. The problem with the 1:1.0.51-1 version number is that the Debian source filenames like the .dsc do not include the epoch in the filename. This means that is impossible to include the completely history of files in the same directory (because there would be files with the same file name but different file contents). This also means that it is impossible to auto-sync the package to Ubuntu. The maintainer thinks the 1:1.0.51-12 version number would be "ugly" and the version number issue is only an Ubuntu-specific problem (given that the original 1.0.51-1 was superseded in 2006). I could not find anywhere in Debian Policy that directly addressed this issue. Therefore, I'm bring up this issue here to get input from other developers. Thanks, Jeremy Bicha
Re: Debian part of a version number when epoch is bumped
On Fri, Feb 9, 2018 at 2:22 PM, Andrey Rahmatullin wrote: > On Fri, Feb 09, 2018 at 06:58:49PM +0100, Philipp Kern wrote: >> If Ubuntu uses an epoch without Debian following that decision, they can >> never sync with Debian again, increasing the maintenance burden >> indefinitely. > See e.g. libpulse0 (pulseaudio), sadly (I needed to repack a $job package > and fix the Depends line to use the package on Debian because of that). Would it hurt to take those epoch bumps into Debian? For instance, the only difference gnome-calculator has in Ubuntu now is the epoch bump. The background is that gcalctool 6.4 was renamed upstream to gnome-calculator 3.7. An overhauled upstream version numbering system seemed a pretty clear case for adding an epoch. A month after this landed in Ubuntu, the Debian packaging used a dh_gencontrol hack to only use an epoch for the transitional package gcalctool allowing the rest of gnome-calculator to avoid an epoch. Pretty cool trick except that it just causes extra work in Ubuntu multiple times a year. Thanks, Jeremy Bicha
Update on removing obsolete GNOME libraries
Hi! The Debian GNOME team has continued working on removing obsolete GNOME 2 libraries and we wanted to provide an update on our progress and let you know what's next. We have identified the list of libraries we are targeting for removal from Buster and have filed bugs for affected packages. Several libraries have already been removed from Buster. Soon, we intend to raise the severity of the remaining bugs to serious to try to finish up these removals from Debian Testing. Honestly, the best option for many of these packages is for them to be ported to GTK3. If you are the maintainer for one of these packages that is no longer maintained upstream and if you don't intend to port it to deprecated libraries, you can help us out by filing a removal bug for the package. Thanks, Jeremy Bicha References == Previous email https://lists.debian.org/debian-devel/2017/10/msg00299.html Debian GNOME's "oldlibs" bug list: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-gnome-maintaine rs%2Alists.alioth.debian.org;tag=oldlibs UDD view of "oldlibs" bug list: https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=oldlibs&user=pkg-gn ome-maintainers%40lists.alioth.debian.org gtk2 to gtk3 migration guide: https://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html gconf to gsettings migration guide: https://developer.gnome.org/gio/stable/ch34.html Affected libraries are listed below. Sorry I don't have a dak+dd-list prepared but someone may want to make one. Removed from Debian --- libunique3 Removed from Testing esound gconfmm2.6 gksu gnome-keyring-sharp gnome-python gnome-python-desktop goocanvas goffice-0.8 libgnomecanvasmm2.6 libgksu libgoo-canvas-perl pygoocanvas pygtksourceview python-gtkglext1 pyorbit python-poppler Almost Removed from Testing --- libglademm2.4 vte webkitgtk Raising severity to serious soon clutter-gesture gnome-sharp2 gnome-vfs libbonobo libbonoboui libgnome libgnomecanvas libgnomeui libgnome-keyring libunique rarian libgnome2-perl libgnome2-canvas-perl libgnome2-gconf-perl libgnome2-wnck-perl libgnome2-vfs-perl libgtk2-appindicator-perl libgtk2-unique-perl Also aiming for Buster -- gconf libart-lgpl pygtk
Re: Update on removing obsolete GNOME libraries
On Fri, Feb 9, 2018 at 7:25 PM, Jeremy Bicha wrote: > Debian GNOME's "oldlibs" bug list: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-gnome-maintainers%40lists.alioth.debian.org;tag=oldlibs Thanks, Jeremy Bicha
Bug#890218: ITP: psautohint -- standalone version of the AFDKO autohinter
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-fo...@lists.debian.org Owner: jbi...@debian.org Package Name: psautohint Version: 1.1.0 Upstream Authors : Adobe Systems Incorporated, Khaled Hosny License : Apache 2.0 (one file from Alexander Chemeris is BSD-3-Clause) Programming Lang: Python 3, C Homepage: https://github.com/adobe-type-tools/psautohint Description: standalone version of the AFDKO autohinter psautohint is a standalone version of the autohinter from the Adobe Font Development Kit for OpenType (AFDKO). Other Info -- This is a simplified font tool related to AFDKO (ITP bug #762252). psautohint is required for the Cantarell font 0.100+. Cantarell is the default font for the GNOME desktop. I am told that other font developers are using psautohint too. I am packaging this as part of the Debian Fonts Team. Packaging is at https://salsa.debian.org/fonts-team/psautohint Thanks, Jeremy Bicha
Re: Debian part of a version number when epoch is bumped
On Wed, Feb 14, 2018 at 7:57 AM, Vincent Bernat wrote: > ❦ 14 février 2018 12:53 +0100, Wouter Verhelst : > >>> > Would it hurt to take those epoch bumps into Debian? >>> >>> Depends on what you mean by hurt. I see epochs being used w/o much >>> tought or care, on many situations where they are not supposed to be >>> used, and they are permanent stigmas. >> >> I wonder where this representation of "epoch" as a "stigma" comes from. >> They're a part of a version number. They're as much a stigma as the "57" >> in "libavcodec57". What's the big deal? Just use it if you need to, and >> be done with it. >> >> There's really really really nothing wrong with using an epoch. If some >> of our (or someone else's) infrastructure has issues dealing with them, >> then that's a bug in the infrastructure and we should fix it. But nobody >> should be afraid of using an epoch when the upstream version number >> changes incompatibly, because *that's what they're for*. > > It's not only an infrastructure problem. If you Depends on X (>= 1.8), > this will be true with X 1:1.6 as well. In the particular case of gnome-calculator, virtually nothing depends on a particular version of gnome-calculator. And in this case, it's probably better for me to just go ahead and upload the epoch bump, upsetting a few people, but it's not really a big deal at all and saves a bunch of needless work in the long run. Thanks, Jeremy Bicha
Bug#890510: ITP: gnome-usage -- simple system monitor app for GNOME
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org Owner: jbi...@debian.org Package Name: gnome-usage Version: 3.27.90 Upstream Authors : Red Hat, Felipe Borges License : GPL-3+, parts are LGPL-2.1+ or LGPL-3+ Programming Lang: Vala, C Homepage: https://wiki.gnome.org/Apps/Usage Description: simple system monitor app for GNOME Usage is an application for GNOME that allows monitoring of system resources such as memory, CPU, and disk space. Other Info -- This is the first release of GNOME Usage. I think the intent is for this app to replace Disk Usage Analyzer (baobab), GNOME System Monitor, and GNOME Power Statistics (gnome-power-manager) in core GNOME in a future GNOME release. But baobab and gnome-system-monitor may continue to be maintained to provide more powerful features. GNOME Usage doesn't provide power statistics yet. Packaging is at https://salsa.debian.org/gnome-team/gnome-usage Thanks, Jeremy Bicha
Re: Debian part of a version number when epoch is bumped
On Mon, Feb 5, 2018 at 11:06 AM, Mattia Rizzolo wrote: > Please don't consider the Debian Policy like a stick. Or a all-kwowing > never-wrong oracle. Well the maintainer refuses to make the minor change I requested. See the latest comments at https://bugs.debian.org/887740 I wish Debian had some form of informal conflict resolution besides the Tech Committee. Thanks, Jeremy Bicha
Bug#894578: ITP: mypaint-brushes -- brushes for paint apps
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-multime...@lists.debian.org Owner: jbi...@debian.org Package Name: mypaint-brushes Version: 1.3.0 Upstream Authors : Martin Renold, the MyPaint Development Team, and others License : brushes are CC0-1.0, the rest is GPL-2+ Programming Lang: N/A Homepage: https://github.com/Jehan/mypaint-brushes Description: brushes for paint apps MyPaint is a pressure- and tilt-sensitive painting program which works well with Wacom graphics tablets and other similar devices. It comes with a large brush collection including charcoal and ink to emulate real media, but the highly configurable brush engine allows you to experiment with your own brushes and with not-quite-natural painting. . This package contains the virtual paint brushes. Other Info -- This package and libmypaint are required dependencies for gimp 2.10. There is an obvious duplication here with the brushes included in Debian's mypaint package. I expect a future mypaint release will no longer include the brushes and will depend on the mypaint-brushes package. We could drop the bundled brushes from our mypaint package now, but upstream advised to wait a bit longer for https://github.com/mypaint/mypaint/pull/538 to be approved. I intend to help maintain this package under the Debian Multimedia Team. Packaging is at https://salsa.debian.org/multimedia-team/mypaint-brushes Thanks, Jeremy Bicha
Bug#894579: ITP: libmypaint -- brush library for mypaint
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-multime...@lists.debian.org Owner: jbi...@debian.org Package Name: libmypaint Version: 1.3.0 Upstream Authors : Martin Renold, Jon Norby, and others License : ISC Programming Lang: C Homepage: https://github.com/mypaint/libmypaint Description: brush library for mypaint MyPaint is a pressure- and tilt-sensitive painting program which works well with Wacom graphics tablets and other similar devices. It comes with a large brush collection including charcoal and ink to emulate real media, but the highly configurable brush engine allows you to experiment with your own brushes and with not-quite-natural painting. . This package contains the shared library. Other Info -- This package and mypaint-brushes are required dependencies for gimp 2.10. The next major release of mypaint will use this library also. I intend to help maintain this package under the Debian Multimedia Team. Packaging is at https://salsa.debian.org/multimedia-team/libmypaint Thanks, Jeremy Bicha
Re: Lucas Kanashiro and Athos Ribeiro salvaged my package
On Mon, Apr 16, 2018 at 7:56 AM, Gert Wollny wrote: > So IMO, the right appoach for Lucas Kanashiro and Athos Ribeiro would > have been to do a NMU with the usual delay The Debian Developer's Reference says that a 0-day NMU is appropriate for an RC bug older than 7 days with no developer response: https://www.debian.org/doc/manuals/developers-reference/ch05.html#nmu https://bugs.debian.org/876571 Thanks, Jeremy Bicha
Re: hijack of gjots2 package
On Tue, Apr 17, 2018 at 1:02 AM, Rolf Leggewie wrote: > I am happy you and Athos want to contribute to Debian. My beef is that > you need to do it the proper way (failure #1). And that you need to own > up to and correct in a reasonable time frame mistakes you make (failure > #2). So you gave Lucas 4 days to act before you publicly shamed him. Did you tell him about that deadline in advance? Meanwhile, you haven't made an upload for your package in 4 years and you *never* replied to https://bugs.debian.org/876571 (open for 7 months, and the bug that the failed NMU fixed and you reintroduced). > I would not have made this public if you hadn't failed me the > second time around as well, leaving me little time to push "RC bug" > #876571 to bionic (yes, I do want that Recommends in there for that LTS). Which one and why? You re-introduced 2 recommends, both of which are not in Testing and at high risk of being removed from Ubuntu very soon. (In other words, they are RC bugs in Ubuntu too.) I guess the fact that Ubuntu 18.04 "bionic" will be released very soon helps explains a bit your newfound sense of urgency with gjots2. But let me suggest that since you have upload rights to Ubuntu, you could have made your change in Ubuntu without needing to make the same change in Debian at the same time. Of course the other person you shamed did not have the ability to do the action you demanded. All of us have made mistakes. I think we should be a lot more forgiving to new contributors instead of telling everyone that you will object if he ever applies to become a DM. I strongly hope that Athos does continue contributing to Debian and does apply to be a DM. Thanks, Jeremy Bicha
Re: missing recommends are not RC severity
On Tue, Apr 17, 2018 at 9:16 AM, Holger Levsen wrote: > (not sure this makes sense as the practical impact is a normal bug, but Since I was CC'd on this email and I've filed several Serious bugs for this issue, here is what I've been using lately: "It is my understanding that is a RC bug for package to recommend a library that has been removed from Testing because recommended packages won't be auto-removed on upgrade." That means users will have libraries installed that will not get any security support. I think that's an RC issue. Thanks, Jeremy Bicha
Re: About the MBF on now-failing alioth list addresses (was: Completed: lists.alioth.debian.org migration)
On Thu, Apr 19, 2018 at 3:12 AM, Andreas Tille wrote: > Maintainers: > > udd=# select distinct source, maintainer from packages where release = 'sid' > and maintainer like '%alioth.debian.org%' and maintainer not like > '%lists.alioth.debian.org%' ; >source| maintainer > -+ > libglademm2.4 | Deng Xiyue > libgnomecanvasmm2.6 | Deng Xiyue Neither of those 2 packages are in Testing and it's intended for them to be removed from Unstable "soon". Thanks, Jeremy Bicha
Re: multiple ITPs - mbrola voices
On Sat, Apr 21, 2018 at 4:02 AM, Chris Lamb wrote: > Secondly, am sorry for not seeing this until these hit NEW. For 100% > clarity, I've put them "on hold" there for the time being. Chris, are you aware that there are already about 45 mbrola voices packages in Debian, even before these new ITPs? [1] It might be a bit late to try to change the source packaging for all of that… [1] https://qa.debian.org/developer.php?email=sthibault%40debian.org Thanks, Jeremy Bicha
Re: Questionable mass bug filling
On Sat, Apr 21, 2018 at 11:05 AM, Thomas Goirand wrote: > However, I haven't seen a message from you sent to debian-devel. Did I > miss it, or were you unaware that this is mandatory before such mass > filling? Yes, it looks like you missed the message: https://lists.debian.org/debian-devel/2018/04/msg00258.html Thanks, Jeremy Bicha
Re: Please do not drop Python 2 modules
On Sat, Apr 21, 2018 at 1:57 PM, Adrian Bunk wrote: > The tip of the iceberg are some recent cases where Python 2 modules > were dropped that still had reverse dependencies in unstable, but > also for those without there will in many cases be users who will > still need these modules in buster. Once a Python2 library has no reverse depends, I see no reason in general why the Maintainer can't remove the Python2 library. Further, I think we ought to encourage Maintainers to remove the Python2 libraries. You and I seem to be clashing a bit often on the issue of when it is appropriate to remove obsolete packages from Debian. It seems like some of your resistance is a bit theoretical. It sounds to me like you're saying don't remove any Python2 libraries because somebody somewhere might find it inconvenient to need to port some third-party app to Python3 before 2022. But I think if we had that philosophy, we wouldn't ever remove anything until identified security concerns force it out. Jeremy Bicha
Re: Bug#895246: gconf: Intent to Adopt
On Sun, Apr 8, 2018 at 3:19 PM, Adrian Bunk wrote: Sorry for not replying more promptly. > I hereby declare my intent to adopt gconf. Why? Basically there are only two things left in Buster that depend on gconf: eclipse and pulseaudio. pulseaudio is being worked on upstream so I expect that to be resolved in time for Buster. Eclipse is a major headache as you know. Please be more specific about what software you are interested in that requires gconf and why it can't be ported away from gconf this year. Thanks, Jeremy Bicha
