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:
r 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
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
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
o handle that file, but maybe they needed to handle
sources.list.d/ anyway.
Thank you,
Jeremy Bicha
ause I'm not involved in those decisions.
I'll likely upload the gnome-core change to Unstable tomorrow.
Thank you,
Jeremy Bicha
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
sion 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
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
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
cairomm1.16 source package naming has been adopted by other distros:
https://repology.org/project/cairomm/versions
Thanks,
Jeremy Bicha
dependency for GNOME Builder 43 which will use GTK4.
Thanks,
Jeremy Bicha
ce
is currently non-linear.
https://github.com/GSConnect/gnome-shell-extension-gsconnect/issues/1412
Thanks,
Jeremy Bicha
n-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
link in my ITP bug which makes it easy for
someone to review it if they want.
Thank you,
Jeremy Bicha
;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
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 se
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
s
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
urce package naming has been adopted by other distros:
https://repology.org/project/glibmm/versions
Thanks,
Jeremy Bicha
ave Salsa commit privileges for.
Thanks,
Jeremy Bicha
quot;.
>
> 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
-]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
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
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
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
ty team so it's easy for these packages to
follow GNOME style without conflicting with a different team's style.
Thanks,
Jeremy Bicha
default. gedit will still be
available and offers more complex features.
GNOME Text Editor uses GTK4 and libadwaita.
Thanks,
Jeremy Bicha
-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
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
r 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
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
nted 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
nice.
https://salsa.debian.org/gnome-team/gnome-themes-extra/-/commit/4c5691edd
Thanks,
Jeremy Bicha
t
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
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 majori
hat 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
st 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
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,
nsider 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
Software app.
Packaging is maintained by the Debian GNOME Team at
https://salsa.debian.org/gnome-team/gnome-books
Thanks,
Jeremy Bicha
tream. 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
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
lt 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
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
ffler.
Thanks,
Jeremy Bicha
Firefox ESR and
Chromium.
Thanks,
Jeremy Bicha
depend on the
Freedesktop SDKs.
Thanks,
Jeremy Bicha
d your email first.
Thanks,
Jeremy Bicha
ceview2
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
to be complete in Buster before the
Transition Freeze which is scheduled for January 12. [1]
[1] https://release.debian.org/
Thanks,
Jeremy Bicha
appily
upgrade my Debian install to Unstable.
Thanks,
Jeremy Bicha
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
r NEW.
I don't have experience with archive management for non-release
architectures at all.
Thanks,
Jeremy Bicha
es 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
id 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
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 sugge
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
27;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
nchpad to allow whitelisted downgrades
I appreciate your thinking of possible solutions, but my understanding
is that Canonical isn't investing in any more Launchpad work than is
necessary. And it's rare for anyone else to work on Launchpad.
Thanks,
Jeremy Bicha
, at least it will be available as an option for people using
Buster.
Packaging is at
https://salsa.debian.org/gnome-team/gnome-remote-desktop
Thanks,
Jeremy Bicha
x27;s epoch?
[1] Current example of the hack:
https://salsa.debian.org/fonts-team/fonts-ubuntu/blob/debian/unstable/debian/rules
Thanks,
Jeremy Bicha
eople want to try to hold on to
Firefox 52 ESR past its expiration date, but may have Chromium
installed), I think it's probably as good as we can get there.
Thanks,
Jeremy Bicha
ripfiles, a bash script in the
pkgbinarymanagler package. That package is not available in Debian.
Thanks,
Jeremy Bicha
On Sun, May 13, 2018 at 1:54 PM, Adrian Bunk wrote:
> On Mon, Apr 30, 2018 at 06:47:41PM -0400, Jeremy Bicha wrote:
>> Why? Basically there are only two things left in Buster that depend on
>> gconf: eclipse and pulseaudio.
>
> Plus ~ 50 more in unstable.
>
>> Plea
you maintain
yet another web browser.
[1]
https://www.debian.org/releases/stretch/amd64/release-notes/ch-information.html#browser-security
Jeremy Bicha
.
Packaging is at
https://salsa.debian.org/freedesktop-team/bolt
Thanks,
Jeremy Bicha
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
2022. But I think if we had that philosophy, we
wouldn't ever remove anything until identified security concerns force
it out.
Jeremy Bicha
ian-devel/2018/04/msg00258.html
Thanks,
Jeremy Bicha
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
ts.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
ng 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
s. 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
o developer response:
https://www.debian.org/doc/manuals/developers-reference/ch05.html#nmu
https://bugs.debian.org/876571
Thanks,
Jeremy Bicha
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
, 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
Debian had some form of informal conflict resolution besides
the Tech Committee.
Thanks,
Jeremy Bicha
ovide power
statistics yet.
Packaging is at
https://salsa.debian.org/gnome-team/gnome-usage
Thanks,
Jeremy Bicha
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
at
https://salsa.debian.org/fonts-team/psautohint
Thanks,
Jeremy Bicha
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
r 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/msg
or 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
#x27;m bring up this issue here to get input from other
developers.
Thanks,
Jeremy Bicha
n 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
k we need to add an artificial delay for package removals
that are approved by the package maintainer.
Thanks,
Jeremy Bicha
ink 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
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
ed
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
t 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
it benefits Debian for Ubuntu and Debian packaging
to be as shared as much as possible.
https://launchpad.net/bugs/1734339
Thanks,
Jeremy Bicha
email to be delivered. (Maybe that's what you meant, but it wasn't
clear to me.)
Thanks,
Jeremy Bicha
Has the python2 dependency issue been reported upstream yet?
Thanks,
Jeremy Bicha
web tools (packages, tracker, qa, ...) would link
> to the group page automatically, right?
Tracker currently needs someone to create the team but that takes a
few seconds. It can automatically keep the team up-to-date for all
packages that use the same Maintainer email address.
Thanks,
Jeremy Bicha
is gone, we would need an alternative.
Someone just has to add the packages to the team list. It's a one-time
maintenance cost that in my opinion takes very little time. I don't
think it's a scalability problem at all. Surely, someone can spend a
few seconds per package.…
Thanks,
Jeremy Bicha
ams.
Thanks,
Jeremy Bicha
On Wed, Dec 27, 2017 at 12:27 PM, Tobias Frost wrote:
> How can one easily retrieve a list of packages from a specific team,
The team can make a Tracker team and add their packages individually
to the team like this:
https://tracker.debian.org/teams/desktop-themes-team/
(This is a very new team
yone listed in a Copyright line to always be mentioned in
debian/copyright.
Anyway, I do appreciate your email.
Thanks,
Jeremy Bicha
r
mozjs52 which is simply the JavaScript engine from Firefox 52 ESR. I
first tried copying the Firefox 52 ESR's copyright file (removing the
extra lines that didn't apply to this more minimal source) but it
wasn't complete enough. (mozjs52 is essential for GNOME Shell 3.26.)
Thanks,
Jeremy Bicha
1 - 100 of 170 matches
Mail list logo
