the
Software app does not display debconf prompts.
Jeremy Bicha
maybe mozjs52
(the current version) for GNOME 3.26 later this year.
Besides GNOME, there are 3 Debian packages that use mozjs24 (edbrowse
and Cinnamon with its gjs fork, cjs). Both upstreams are working on
porting to mozjs38 now.
Thanks,
Jeremy Bicha
On Sun, Apr 16, 2017 at 2:56 AM, Evgeni Golov wrote:
> On Sat, Mar 11, 2017 at 09:51:03PM -0500, Jeremy Bicha wrote:
>> we created the metapackage for upgrades and convenience.
> Why not retire the gnome-games metapackage if it was only for upgrades?
Sorry, I was unclear in my or
launchpad.net/ubuntu/+source/webkit2gtk
[2] https://www.ubuntu.com/usn/usn-3257-1/
[3] https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy
[4] https://webkitgtk.org/security.html
Thank you,
Jeremy Bicha
to consider what dgit has to offer. dgit
> provides a single git workflow for all Debian packages.
Of course, dgit is yet another workflow and my understanding is that
git-buildpackage (without dgit) is far more commonly used in Debian.
Thanks,
Jeremy Bicha
breaking several of those addons next year,
whereas the webkit2gtk developers try to avoid regressions.
Thanks,
Jeremy Bicha
the release is now
pushed as a security update into Ubuntu Stable Releases fairly
quickly.
Thanks,
Jeremy Bicha
h that these shouldn't Recommend a MTA usually either).
Ansgar, I see that you're an uploader for 'at'. What about the patches
I submitted at
https://bugs.debian.org/830950 ?
Thanks,
Jeremy Bicha
d I doubt they want to deal with that kind of API
> "stability" either).
That sounds like a good way to start.
I want webkit2gtk 2.16.3 in Debian 9.0. Does it just need a regular unblock bug?
Thanks,
Jeremy Bicha
On Tue, May 30, 2017 at 5:47 PM, Jeremy Bicha wrote:
> On Tue, May 30, 2017 at 5:32 PM, Moritz Mühlenhoff wrote:
>> You're best technical bet would be to upgrade to new webkit releases in
>> stretch point releases, this would allow proper binNMUs and allow
>> people t
pends
relationship is needed not a Recommends.
Thanks,
Jeremy Bicha
ofile and be authoritative, so that means taking
> a couple of contested cases to the TC. Maybe #849619 would make a
> good test case.
Respectfully, #849619 is not at all a very convincing test case yet.
Thanks,
Jeremy Bicha
On Mon, Jun 5, 2017 at 9:42 AM, Ian Jackson
wrote:
> Jeremy Bicha writes ("Re: Too many Recommends (in particular on
> mail-transport-agent)"):
>> Respectfully, #849619 is not at all a very convincing test case yet.
>
> That's why I wrote, earlier:
I thin
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714320#17
That particular example appears to have been fixed years ago with
https://bugs.debian.org/682062
Thanks,
Jeremy Bicha
of pushing dgit?
Thanks,
Jeremy Bicha
ckage should declare at most a Recommends on
> package-doc.
By the way, that paragraph is new in Policy 4.0.0.
Thanks,
Jeremy Bicha
On Sun, Jun 11, 2017 at 3:30 PM, Adam Borowski wrote:
> No, when taken alone, -dev packages Recommending -doc is just right.
https://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=dc3b001
Thanks,
Jeremy Bicha
https://gcc.gnu.org/ml/gcc/2017-06/msg00046.html
--
Jeremy Stanley
next upload, for whatever reason. So they can merge the
> PR to next/sid.
Respectfully, why? And why does that unusual workflow need a DEP?
Thanks,
Jeremy Bicha
https://eclipse.org/legal/CLA.php
--
Jeremy Stanley
build gnome-builder 3.25.3+.
Here's the initial announcement by its creator:
https://blogs.gnome.org/chergert/2017/05/31/razzle-dazzle/
libdazzle will be maintained by the pkg-gnome team. Packaging is at
https://anonscm.debian.org/git/pkg-gnome/libdazzle.git
Thanks,
Jeremy Bicha
recommend disabling SELinux by
default on Fedora/RHEL (at least in the past), it's far, far less
common to hear about anyone recommending disabling AppArmor. And
that's one reason AppArmor is being proposed here and not SELinux.
Thanks,
Jeremy Bicha
On Mon, Aug 7, 2017 at 9:08 AM, Ritesh Raj Sarraf wrote:
> But for desktop users, I worry this would cause more pain.
My point is that it hasn't so far and Ubuntu and SUSE has had millions
of people using it for a decade, more or less.
Thanks,
Jeremy Bicha
t/pkg-gnome/template-glib.git
Thanks,
Jeremy Bicha
libraries will be maintained by the pkg-gnome team. Packaging is at
https://anonscm.debian.org/git/pkg-gnome/jsonrpc-glib.git
Thanks,
Jeremy Bicha
.
Packaging is at
https://anonscm.debian.org/git/collab-maint/tracker-miners.git
but we may move it to
https://anonscm.debian.org/git/pkg-gnome/tracker-miners.git
Thanks,
Jeremy Bicha
s, I think.
Not that I've personally tested them together, but this would
probably count if someone gets a chance to try:
https://git.openstack.org/cgit/openstack/swift3/
https://tarballs.openstack.org/swift3/
It's not packaged in Debian though (at least not yet anyway).
--
Jeremy
g/wiki/Softlanding_Linux_System
(feeling kinda old now that I realize that was 25 years ago, still
almost seems like yesterday sometimes)
--
Jeremy Stanley
/unstable/
The Debian GNOME team intends to maintain this package.
I'm uploading to experimental for now.
Packaging is currently at
https://anonscm.debian.org/viewvc/pkg-gnome/desktop/experimental/gtksourceview4/
Thanks,
Jeremy Bicha
[3] https://2017.guadec.org/talks-and-events/#abstract-opentalk8-pipewire
Thanks,
Jeremy Bicha
On Sat, Sep 2, 2017 at 10:33 PM, Jeremy Bicha wrote:
> PipeWire [1] is an optional dependency of mutter 3.26 to enable
> experimental Remote Desktop support in GNOME on Wayland.
https://wiki.gnome.org/Projects/Mutter/RemoteDesktop
Thanks,
Jeremy Bicha
to close down and its replacement is not
yet ready, how would I start this team now?
Thanks,
Jeremy Bicha
On Fri, Sep 15, 2017 at 2:13 PM, Ben Hutchings wrote:
> You could use the public Gitlab site <https://gitlab.com> for now.
Oh, I guess I could use Launchpad then since it supports git and has
mailing lists.
Thanks,
Jeremy Bicha
2B4.0/
Thanks,
Jeremy Bicha
RC-bug but I assume we won't be doing thousands of
stretch updates just to fix that.
Thanks,
Jeremy Bicha
a new packaging team (which is being discussed in multiple
threads on debian-devel now).
Thanks,
Jeremy Bicha
If your package requires internet access to build, it will not be
buildable for Ubuntu.
Thanks,
Jeremy Bicha
On Sun, Oct 15, 2017 at 8:09 AM, Michael Stone wrote:
> It does make backports easier. More than one generation back, though, the
> value diminishes rapidly.
If the transitional package was added late to stretch, it will
probably still be needed in Ubuntu until Ubuntu 18.04 LTS.
Thanks,
,
Jeremy Bicha
for several years.
Packaging is at
https://anonscm.debian.org/git/pkg-gnome/libgdamm5.0.git
Thanks,
Jeremy Bicha
://bugs.debian.org/454805
The other ITP needed for glom is goocanvasmm-2.0: https://bugs.debian.org/878822
[1] https://www.debian.org/devel/wnpp/being_packaged_byage
Thanks,
Jeremy Bicha
old version numbers.
For context, the new ITP is https://bugs.debian.org/860055
Thanks,
Jeremy Bicha
Packaging is at
https://anonscm.debian.org/git/pkg-ayatana/snapd-glib.git
Thanks,
Jeremy Bicha
dn't it stay a Recommends for Bullseye (buster+1) too?
Thanks,
Jeremy Bicha
Suggests in Bullseye seems counter-productive.
Thanks,
Jeremy Bicha
e.
Packaging is at
https://anonscm.debian.org/git/pkg-gnome/libcloud-providers.git
Thanks,
Jeremy Bicha
lieve the failure was because
upstream switched to meson and python3).
Further reading:
https://fedoraproject.org/wiki/Upstream_release_monitoring
Thanks,
Jeremy Bicha
omplicated to set up in a trusted
way. I don't think you need a vote to work on implementing and
offering the rest.
Thanks,
Jeremy Bicha
.
I am packaging this as part of the Debian Fonts Team.
Packaging is at
https://anonscm.debian.org/git/pkg-fonts/compreffor.git/
Thanks,
Jeremy Bicha
e properties.
[...]
Hopefully "in contrast with ALL the software in Debian" since
non-free firmware is not actually part of Debian and merely being
provided as a convenience (read: necessary evil) for the user.
--
Jeremy Stanley
tirely
incorrect. (I am not a lawyer.)
--
Jeremy Stanley
Fonts Team.
Packaging is at
https://anonscm.debian.org/git/pkg-fonts/woff2.git/
The specification is at https://www.w3.org/TR/WOFF2/
Thanks,
Jeremy Bicha
q=CC0-1%5C.0&perpkg=1
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
upstream and downstream in
these sorts of situations, and what sort of tracking information is
actually reasonable to expect a package maintainer or an upstream
project to be able to obtain.
--
Jeremy Stanley
signature.asc
Description: Digital signature
yone listed in a Copyright line to always be mentioned in
debian/copyright.
Anyway, I do appreciate your email.
Thanks,
Jeremy Bicha
yright
statements present in the files, but we cannot produce a list of all
copyright holders because we have no way to know about copyright
holders who have not added copyright statements.
(perhaps this is a nuanced distinction, but listing all copyright
statements is not the same thing as list
On 2017-12-23 15:15:35 -0800 (-0800), Russ Allbery wrote:
[...]
> I think a separate (public) mailing list dedicated to this would
> be ideal
[...]
As in debian-legal@l.d.o or a completely new ML specifically for
copyright documentation discussions?
--
Jeremy Stanley
cope of the team? (just as two example)
If a team stops using the BTS for bugs and just uses Salsa's Issues
tracker, you can just go to a page like this (for the Salsa Team)
https://salsa.debian.org/groups/salsa/-/issues
Jeremy
ams.
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
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
On 2015-09-18 14:03:17 +0100 (+0100), Ian Jackson wrote:
[...]
> they could be called some other kind of shed or hut or something.
[...]
While marvellously entertaining, I can only hope that the irony of
this protracted debate is not entirely lost on its participants.
--
Jeremy Stanley
Debian Maintainer and I intend to package this within the
Debian MATE Packaging Team.
Thanks,
Jeremy Bicha
nd to package this within the Debian MATE Packaging Team.
[1] https://github.com/numixproject/numix-icon-theme/issues/855
Thank you,
Jeremy Bicha
acement, but
ideally wait until all versions for old Debian releases had
completely aged out of the pool (these days I guess that would
include waiting for LTS versions to no longer include it as well?).
--
Jeremy Stanley
signature.asc
Description: PGP signature
ed (to avoid taking on the global namespace), it's
> easier to see what it is about when doing archive-wide analysis from
> Sources, or even reading changelogs via stuff like apt-listchangs. :)
Renaming a source package does require going through the NEW queue.
Thank you,
Jeremy Bícha
On Sun, Nov 24, 2024 at 12:51 PM Paul Gevers wrote:
> [Release Team hat on] I would take consensus for a decision on the topic.
If the excess precision issue goes away by bumping the i386 baseline,
that would make my life easier.
Thank you,
Jeremy Bícha
On 2024-11-09 14:19:53 +0100 (+0100), PICCA Frederic-Emmanuel wrote:
> is it via ChatGPT or an llm self hosted ?
[...]
It's DebGPT: https://salsa.debian.org/deeplearning-team/debgpt
--
Jeremy Stanley
signature.asc
Description: PGP signature
already has excess precision:
https://wiki.debian.org/ArchitectureSpecificsMemo#i386
If you mean something else, could you be… more precise?
Thank you,
Jeremy Bícha
t probably not. As you noted,
priorities matter and it's entirely possible to be involved in
Debian without that (depending on what exactly you want to do of
course). There's quite a lot that doesn't require upload permissions
in the archive, and also quite a lot of amazing people
uses Calamares)
but not if you use the default netinst ISO.
Thank you,
Jeremy Bícha
package of a project where I eventually
moved the upstream codebase into revision control but have been too
lazy/distracted to do the same for the debian directory (which I
realistically only update once every year or two). I'm committed to
importing that into Salsa eventually, it's just
d at the beginning of March to start this work.
Thank you,
Jeremy Bícha
aces)
Thank you. I am unable to duplicate these issues with the information
provided. Please report these as Debian bugs instead of on this
mailing list.
https://www.debian.org/Bugs/Reporting
Jeremy Bícha
w. There aren't any
Canonical members on the Technical Committee and I don't think we
should discourage any from joining.
Thank you,
Jeremy Bícha
link in this case
though.
Thank you,
Jeremy Bícha
x27;t depicted directly on my keyboard's keycaps,
after all.
--
Jeremy Stanley
signature.asc
Description: PGP signature
s older than I am, I'd found other
hobbies and/or gone into a different field of work.
--
Jeremy Stanley
signature.asc
Description: PGP signature
On 2024-12-21, at 17:55:39 +0100, Marc Haber wrote:
> On Sat, 21 Dec 2024 12:08:35 +0100, Tobias Frost wrote:
> > We DO already have the debian namespace on salsa, everything in this
> > namespace is "team maintained by everyone.",
>
> Is that so? I know that I agree that anybody can commit to my
[which is also used by gyrus).
This package will be maintained by the Debian GNOME team. Packaging will be at
https://salsa.debian.org/gnome-team/libgedit-gfls
The upstream source is at https://gitlab.gnome.org/World/gedit/libgedit-gfls
Thanks,
Jeremy Bícha
/lists.debian.org/debian-gtk-gnome/2023/08/msg5.html
Thank you,
Jeremy Bícha
I
know GitLab does not do it, so this is not particularly relevant to
Debian while Salsa is running GitLab.
--
Jeremy Stanley
signature.asc
Description: PGP signature
r too strong for this; I think even a warning is too
strong; maybe info would be ok.
Thank you,
Jeremy Bícha
ental branch. I think many Debian packages
never or only rarely use Experimental so debian/latest is probably
best practice for most packages.
Thank you,
Jeremy Bícha
l
Out of curiosity, what does the Tinker Blend have to do with Debian
Wiki management? It's described as "a Debian Pure Blend which aims
to provide fully configured installations for various forms of
tinkering/hacking on electronics and other hardware devices."
--
Jeremy Stanley
s
at it's
implemented in Python instead of PHP, which made modifying it or
writing custom plugins for MoinMoin myself a little easier and less
dicey.
--
Jeremy Stanley
signature.asc
Description: PGP signature
and often face different
challenges that need their own solutions or aren't willing to
compromise by adopting partial solutions popular elsewhere just to
conform.
--
Jeremy Stanley
signature.asc
Description: PGP signature
r list I recognize as being in
the same situation, but no idea how many more there might be.
--
Jeremy Stanley
signature.asc
Description: PGP signature
to build GNOME for Trixie without support for
Xorg. That may be useful for kiosks but is not useful in a general
purpose OS like Debian at this time.
Also, please report a bug for this kind of packaging suggested change
instead of emailing this list.
https://www.debian.org/Bugs/Reporting
Thank you,
Jeremy Bícha
On 2025-02-26, at 11:21:42 -0700, Soren Stoutner wrote:
> The purpose of this email is to propose that the expectation that
> emails should be wrapped at 80 characters when they are sent should be
> dropped.
No, thanks.
J.
signature.asc
Description: PGP signature
t
tried filing a bug first.
Thank you,
Jeremy Bícha
ndent levels deep, but I do sometimes manually re-flow any
quoted material I haven't trimmed from others' messages if I see
they're near to or exceeding my 80-character terminal margin.
--
Jeremy Stanley
signature.asc
Description: PGP signature
On 2025-02-26 15:30:48 -0500 (-0500), Marvin Renich wrote:
> * Jeremy Stanley [250226 13:39]:
> > The only real hassle is
> > if I want to copy a very long URL out of a message, I either need to
> > piecemeal reassemble it from the lines that URL is spread across or
> >
source tarballs where that
data is extracted from their Git repositories so it can be included
correctly, but package maintainers need to be careful to run the
same source tarball build process for the basis of the Debian source
package in those cases and not just pretend that the _files_ tracke
t being fixed or fixes for it not getting
backported, we remind them that we don't consider it a vulnerability
and they're free to take it up with whoever requested or issued it.
--
Jeremy Stanley
signature.asc
Description: PGP signature
On 2025-03-03, at 14:26:36 -0800, Russ Allbery wrote:
> [snip] I am getting nerd-sniped here [snip]
I did not know that there was a word for this. I have learnt
something fun to-day. Thanks, Russ (and Randall). :)
J.
signature.asc
Description: PGP signature
7;ll go ahead and annotate the recommendation to suggest it's
probably outdated, thanks for pointing that out!
--
Jeremy Stanley
signature.asc
Description: PGP signature
gh nonfree-firmware match official vendor checksums
would be roughly the same as if you fetched them from the hardware
vendor to install manually yourself.
--
Jeremy Stanley
signature.asc
Description: PGP signature
On 2025-03-07 10:08:23 + (+), Jonathan Dowland wrote:
On Thu Mar 6, 2025 at 7:08 AM GMT, Henrik Ahlgren wrote:
> It is essential to have a method for distinguishing between hard
> and soft newlines if you want to reflow text properly.
Agreed! And, as Jeremy Stanley points
401 - 500 of 536 matches
Mail list logo
