Mailman 3 is
(mailman3-full metapackage), though I gather that distinction makes
little difference to DSA as members have stated on multiple
occasions they prefer not to rely on Debian packaging for services
they operate.
--
Jeremy Stanley
signature.asc
Description: PGP signature
es to the message IDs replied to
within each message's headers, precisely so that readers can
construct a reference graph of message relationships for this use
case. If you find that mailing list discussions lack a tree-like
structure, that's a failing of the mail client you've chosen, not
the medium itself.
--
Jeremy Stanley
signature.asc
Description: PGP signature
g the tools they're
familiar with and then complain about the medium--asking for (or
better still, implementing themselves) improvements in the tools
they use is going to be the last thing they consider.
--
Jeremy Stanley
signature.asc
Description: PGP signature
of forums
today if it hadn't been the first line breached in the spam wars.
--
Jeremy Stanley
signature.asc
Description: PGP signature
available from
https://cdimage.debian.org/images/unofficial/non-free/images-including-firmware/
which have it baked in.
--
Jeremy Stanley
signature.asc
Description: PGP signature
to fast-forward.
Thanks,
Jeremy
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
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
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
rimitives can
weaken the resulting output (for example if, in a case like this,
the input hash were to be shorter than the signing system's internal
hash... granted their HMAC in question is likely already using
SHA2-256 as well, I haven't checked).
--
Jeremy Stanley
signature.asc
Description: PGP signature
for a very large community of projects, I'm
actually curious what you see as culturally incompatible between the
two. It may be the communities I'm most embedded in don't suffer
this cultural rift, but it's also entirely possible I've got some
sort of tunnel vision prevent
it's allowed to merge reduces the risk that you pick a bad
branch point. Also having the ability to branch your job
configuration along with your source code makes a big difference
when it comes to handling behavior needs for stable maintenance, and
avoiding development in master from bleeding into those stable jobs.
--
Jeremy Stanley
signature.asc
Description: PGP signature
obtain a visa
and/or enter. As it turns out, Canada is actually more picky about
who it will let visit than the USA is, it's just not as well-known
for that.
--
Jeremy Stanley
signature.asc
Description: PGP signature
T protocol (a long-established
ISO/OASIS standard). I gather there was some work done to make
fedmsg support MQTT as a result of that, so it might be an
alternative to relying on ZeroMQ at least.
--
Jeremy Stanley
signature.asc
Description: PGP signature
ackages. Some software
ecosystems have chosen to focus on tools and workflows which are
incompatible with Debian's, but that doesn't mean that either one is
inherently bad nor that they need to be integrated at all costs.
--
Jeremy Stanley
signature.asc
Description: PGP signature
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
tural that if
users ask questions about old tech, they may find that the number of
folks still around who remember how it worked (beyond what's already
in the older versions of the software's documentation) will be
vanishingly small.
--
Jeremy Stanley
signature.asc
Description: PGP signature
a benefit to the Kubernetes community as it
allowed their work to help shape the language (not to say that
OpenStack hasn't had a significant impact on Python as well), but
with that also comes the joys of trying to maintain a very large
project in a rapidly-evolving language.
--
Jeremy Stanley
signature.asc
Description: PGP signature
On 2020-04-09 22:27:31 +0200 (+0200), Thomas Goirand wrote:
> On 4/9/20 6:09 PM, Jeremy Stanley wrote:
[...]
> > for example I anticipate an interest in expiring releases
> > prior to the current one a bit faster because it will mean not
> > having to continue supporting Pytho
nd that for others on the planet it was not the
same seasons they were experiencing. These days, I have my editor
treat names of seasons as a red flag when I'm reviewing what I've
written, so that I hopefully don't forget.
--
Jeremy Stanley
signature.asc
Description: PGP signature
d to activate my TOTP client
software every time I invoke `git push` so I can understand the
resistance to your proposal.
--
Jeremy Stanley
signature.asc
Description: PGP signature
or change it
to whatever you like really, so long as it's not already taken by
someone else).
--
Jeremy Stanley
signature.asc
Description: PGP signature
.
Thankfully, it sounds like the Salsa admins plan to keep use of 2FA
voluntary.
--
Jeremy Stanley
signature.asc
Description: PGP signature
nice.
https://salsa.debian.org/gnome-team/gnome-themes-extra/-/commit/4c5691edd
Thanks,
Jeremy Bicha
been eschewing NM on them in favor of ifupdown for
simplicity, but I could foresee wanting to install it on them and
having zero use for either wpa-supplicant or iwd. I've actually
grown quite fond of nmcli, once NM mostly got over its (lengthy)
rough patch.
--
Jeremy Stanley
signature.asc
Description: PGP signature
ilesystem on which that signing key resides
(via LUKS or similar) then this might keep you safe from someone
with access to replace the kernel or initrd on the unencrypted boot
partition... but only if they can't unlock the decryption key for
the FS which holds the signing key of course.
--
Jeremy Stanley
signature.asc
Description: PGP signature
On 2020-08-05 20:30:59 +0100 (+0100), Nikolaus Rath wrote:
> On Aug 04 2020, Jeremy Stanley wrote:
> > Okay, so for systems to which a malicious party may gain physical
> > access (or remote console access) there's sort of a third risk this
> > addresses. A special case
On 2020-08-06 08:04:56 +0100 (+0100), Nikolaus Rath wrote:
> On Aug 05 2020, Jeremy Stanley wrote:
> > On 2020-08-05 20:30:59 +0100 (+0100), Nikolaus Rath wrote:
> >> On Aug 04 2020, Jeremy Stanley wrote:
> >> > Okay, so for systems to which a malicious party may g
On 2020-08-06 21:49:06 +0200 (+0200), Sven Bartscher wrote:
> Am Thu, 6 Aug 2020 17:24:08 +
> schrieb Jeremy Stanley :
>
> > The idea is that UEFI/BIOS checks the signature for GRUB before
> > executing it, and does so instructing GRUB to verify the signature
> >
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
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
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
ver transport security is worth anyway).
--
Jeremy Stanley
https://git.fedorahosted.org/cgit/setup.git/tree/uidgid
--
Jeremy Stanley
Project.
I am a Debian Maintainer and I intend to package this within the
Debian GNOME Packaging Team.
Thanks,
Jeremy Bicha
for them. Debian helps those who help themselves.
--
Jeremy Stanley
rs familiar with how we
maintain the services they use, and so broadens the pool of
potential future contributors to related efforts.
--
Jeremy Stanley
signature.asc
Description: Digital signature
files/dgit/git.dgit.debian.org
>
so I'm assuming something like that was done for the anonscm service
as well. Am I looking in the wrong place for the configuration
management covering the anonscm.d.o service, or is that not actually
published anywhere?
--
Jeremy Stanley
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
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
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.
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
Has the python2 dependency issue been reported upstream yet?
Thanks,
Jeremy Bicha
email to be delivered. (Maybe that's what you meant, but it wasn't
clear to me.)
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
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
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
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
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
k we need to add an artificial delay for package removals
that are approved by the package maintainer.
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
#x27;m bring up this issue here to get input from other
developers.
Thanks,
Jeremy Bicha
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
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
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
at
https://salsa.debian.org/fonts-team/psautohint
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
ovide power
statistics yet.
Packaging is at
https://salsa.debian.org/gnome-team/gnome-usage
Thanks,
Jeremy Bicha
Debian had some form of informal conflict resolution besides
the Tech Committee.
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
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
here:
https://github.com/distributedweaknessfiling/cvelist/tree/master/2018/1000xxx
Odds are it'll show up there in the coming days (I don't know how
quickly he syncs in IDs he's assigned).
--
Jeremy Stanley
signature.asc
Description: PGP signature
o developer response:
https://www.debian.org/doc/manuals/developers-reference/ch05.html#nmu
https://bugs.debian.org/876571
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
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
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
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
ian-devel/2018/04/msg00258.html
Thanks,
Jeremy Bicha
rrently
got a mandate to support latest RHEL, which still doesn't officially
provide Python 3.x (and no, "software collections" doesn't count).
--
Jeremy Stanley
signature.asc
Description: PGP signature
2022. But I think if we had that philosophy, we
wouldn't ever remove anything until identified security concerns force
it out.
Jeremy Bicha
lear, OpenStack has been thoroughly testing its upstream
releases against Python 3 for a while. The reason it was brought up
earlier in this thread is because Thomas has recently dropped Python
2.7 builds for it and switched to only building Python 3.x packages.
--
Jeremy Stanley
signature.a
rise Linux (RHEL) major release."
[*] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.5_release_notes/chap-red_hat_enterprise_linux-7.5_release_notes-deprecated_functionality
>
--
Jeremy Stanley
signature.asc
Description: PGP signature
e same as
providing an optional Python interpreter within the global system
context as Debian has done. At least the projects I work on don't
see RHEL software collections Python 3 as remotely supportable.
--
Jeremy Stanley
signature.asc
Description: PGP signature
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
"legacy" XUL-based extensions was
entirely dropped between 52 and 60, users who were relying on any of
them will cease to be able to do so and the corresponding packaged
versions of them likely need to be dropped from the archive.
https://blog.mozilla.org/addons/2017/10/03/lega
.
Packaging is at
https://salsa.debian.org/freedesktop-team/bolt
Thanks,
Jeremy Bicha
you maintain
yet another web browser.
[1]
https://www.debian.org/releases/stretch/amd64/release-notes/ch-information.html#browser-security
Jeremy Bicha
imilar to its Gerrit and GitHub drivers,
so could eventually be added as an opt-in solution for Salsa repos
if someone has the bandwidth to run an instance (and sooner if
someone actually volunteers for writing the Gitlab driver!).
--
Jeremy Stanley
signature.asc
Description: PGP signature
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
y
gets regression tested, reviewed by the root sysadmin team, and then
automatically deployed to production) is very empowering for our
community at large.
--
Jeremy Stanley
signature.asc
Description: PGP signature
except for changes to
"lightweight" tags but those are really just a symlink to a ref and
not a typical tag object). Treating published tags as if they can't
be changed is far more friendly to other users of your repositories.
--
Jeremy Stanley
signature.asc
Description: PGP signature
Unless there is also a goal to show support for the projects which
create those free software backends, by choosing the providers who
deploy them over providers who build their own proprietary backends
rather than participating in open community development efforts.
--
Jeremy Stanley
signature.asc
Description: PGP signature
draw
conclusions about Debian's stance on software freedom from the sorts
of software and services it chooses to deploy for its developer
community.
And apologies, the OpenStack subthread here got pretty off-topic. I
don't normally post about OpenStack on debian-devel (or any other
non-OpenStack mailing lists for that matter), but I felt like I
really did need to address a few of your points on the subject.
--
Jeremy Stanley
signature.asc
Description: PGP signature
n explaining supported
storage options for Gitlab *CE* (note the "ee" in those
documentation URLs, they're the same ones I already found). Is it to
be assumed, generally, that Gitlab's Enterprise Edition
documentation is also appropriate for Community Edition deployments?
--
Jeremy Stanley
signature.asc
Description: PGP signature
On 2018-08-20 20:55:46 +0200 (+0200), Alexander Wirt wrote:
> On Mon, 20 Aug 2018, Jeremy Stanley wrote:
>
> > On 2018-08-20 20:05:42 +0200 (+0200), Alexander Wirt wrote:
[...]
> > > https://docs.gitlab.com/ee/administration/repository_storage_paths.html
> > > https
If this is an alternative you're
willing to consider, feel free to follow up with me privately and
I'll make introductions.
[*] https://github.com/fog/fog-openstack/blob/master/docs/storage.md
--
Jeremy Stanley
signature.asc
Description: PGP signature
ripfiles, a bash script in the
pkgbinarymanagler package. That package is not available in Debian.
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
n the archive three Debian releases earlier (removed
after Potato). I could have made the case for it, but packages names
are cheap and reusing a package name (no matter how old) is just a
recipe for headaches.
--
Jeremy Stanley
signature.asc
Description: PGP signature
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
, 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
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
packages that build with meson?
I found this request for debhelper to handle meson:
https://bugs.debian.org/795253
[1] https://git.gnome.org/browse/gnome-builder/tree/NEWS/
Thanks,
Jeremy Bicha
.
[...]
It's not packaged for Debian yet nor do I see any RFP/ITP, but I've
been happily using https://github.com/tehmaze/diagram for a few
years (installable from PyPI via pip so probably easy enough to
package). Its default mode uses 8-dot Braille patterns for axis
graphs.
--
Jeremy Stanley
ut what
beignet-opencl-icd does?
Thanks,
Jeremy
tch at this
point.
Jeremy
4 optionally use the interface
exposed by this service. Fedora 25 backported these enhancements to
the GNOME 3.22 it shipped.
http://www.hadess.net/2016/10/dual-gpu-integration-in-gnome.html
The project name is derived from the Linux kernel interface it uses:
vga_switcheroo.
Thanks,
Jeremy Bicha
stable
with continued bugfix releases in the 3.22.* series.
https://wiki.gnome.org/Projects/GTK+/Roadmap
My packaging uses meson. (GNOME is considering switching many of their
modules to meson for 3.26 later this year.)
Thanks,
Jeremy Bicha
app,
Thanks,
Jeremy Bicha
convenience.
When I complained about the name conflict, the developer suggested we
use the name gnome-games-app for packaging.
https://mail.gnome.org/archives/desktop-devel-list/2016-June/msg00040.html
Thanks,
Jeremy Bicha
301 - 400 of 541 matches
Mail list logo
