t's already packaged with specific commit needed by
gamescope, so it's fine for now)
I'm not quite sure from looking at https://github.com/misyltoad/vkroots,
but that may be OK. If it's easy to use the packaged version, that's
better.
--
Colin Watson (he/him) [cjwat...@debian.org]
* the embedding would not seem
relevant.
Yes, I was involved in drafting that policy language and the way you
describe it is what we intended. Otherwise the whole clause would have
been a no-op in practice.
--
Colin Watson (he/him) [cjwat...@debian.org]
f how people
should respond to review.
--
Colin Watson (he/him) [cjwat...@debian.org]
On Wed, Jun 18, 2025 at 11:59:11AM +0200, PICCA Frederic-Emmanuel wrote:
Do we have a cli-tool whcih is an equivalent of apt source blabla=version, but
connected by default to snapshot ?
There's debsnap(1) in devscripts.
--
Colin Watson (he/him) [
n a PostgreSQL port a while ago I infer that he probably
agrees with me on this.
--
Colin Watson (he/him) [cjwat...@debian.org]
bbugs very actively; I would
100% have switched to it.
--
Colin Watson (he/him) [cjwat...@debian.org]
ectly, definitly more than once per months.
One possibility would be for the BTS to offer a way to follow up
privately, similar to the N-submitter@ addresses. (This idea would
obviously need refinement.)
--
Colin Watson (he/him) [cjwat...@debian.org]
completely
inactive.)
--
Colin Watson (he/him) [cjwat...@debian.org]
ly.
That said, making it easy for established users to hand out invitation
tokens seems pretty harmless from this point of view (although I don't
know how much effort it would be to build or maintain).
--
Colin Watson (he/him) [cjwat...@debian.org]
that debbugs doesn't just replay everyone's email addresses through to
mailing list archives.
--
Colin Watson (he/him) [cjwat...@debian.org]
before the url (we can all say how
bad gmail is, but that doesnt solve anything)
You can use the bts(1) command for that sort of thing.
--
Colin Watson (he/him) [cjwat...@debian.org]
ed to it for a lot of
things a couple of years before I left. Let's just say that I am
extremely unenthusiastic about having to use it for hobby work as well.
--
Colin Watson (he/him) [cjwat...@debian.org]
installations. But I've
updated it there anyway.
--
Colin Watson (he/him) [cjwat...@debian.org]
On Thu, May 22, 2025 at 04:37:33PM +0500, Andrey Rakhmatullin wrote:
On Thu, May 22, 2025 at 12:00:05PM +0100, Colin Watson wrote:
Do you really enjoy waiting 30 min for a bug to be created to get
a bug number?
I agree there are a number of problems with debbugs, but I don't
think
ldn't think of a reason not to.
--
Colin Watson (he/him) [cjwat...@debian.org]
ing would most
likely converge.
I think this significantly underestimates the annoyance involved in
renaming existing long-lived branches (in that all clients have to
re-clone or manually adjust), which is certainly why I generally avoid
doing so unless I absolutely
Package: wnpp
Severity: wishlist
Owner: Colin Watson
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: python-django-hashids
Version : 0.7.0
Upstream Contact: Shen Li
* URL : https://github.com/ericls/django-hashids
* License : Expat
Programming
Package: wnpp
Severity: wishlist
Owner: Colin Watson
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: python-django-pgbulk
Version : 3.2.2
Upstream Contact: Wes Kendall
* URL : https://github.com/AmbitionEng/django-pgbulk
* License : BSD-3-clause
On Thu, Apr 17, 2025 at 08:40:42PM +0200, Santiago Vila wrote:
Installed size of mawk is 263 MB which is really small for today's standards.
KB rather than MB, thankfully!
--
Colin Watson (he/him) [cjwat...@debian.org]
Package: wnpp
Severity: wishlist
Owner: Colin Watson
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: python-typing-inspection
Version : 0.4.0
Upstream Contact: Victorien Plot
* URL : https://github.com/pydantic/typing-inspection
* License : MIT
ir systems configured this way
makes me wonder what's going on. Does anyone know of documentation
somewhere that recommends configuring stable systems this way?
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
On Thu, Feb 27, 2025 at 03:53:41PM +, Jonathan Dowland wrote:
On Thu Feb 27, 2025 at 1:29 PM GMT, Colin Watson wrote:
And this in ~/.muttrc:
set text_flowed
That seems to work pretty well. I reflowed the parts of your
message that I quoted here to match.
If you happen to use
message
that I quoted here to match.
--
Colin Watson (he/him) [cjwat...@debian.org]
er than having to disentangle things later when several
different failures have all piled up into a big ball of mud.
--
Colin Watson (he/him) [cjwat...@debian.org]
gt;
> With tarballs the granularity of these tools is so much less.
This is a false dichotomy, though. It's perfectly possible to use both
in conjunction with each other, by importing a tarball on top of an
upstream git tag so that the differences between them are represented by
a git comm
> patched vulnerabilities or not.
But it doesn't. Santiago's using the data from the security tracker to
determine whether CVEs are open.
--
Colin Watson (he/him) [cjwat...@debian.org]
todo,
some kind of prioritization of which packages out of the huge pile are
worth paying more attention to than others is useful to me.
--
Colin Watson (he/him) [cjwat...@debian.org]
in bulk, the change is still
going to be disruptive to anyone who has a local clone of any of the
affected repositories at the moment. So maybe let's spend time on
something else instead.
--
Colin Watson (he/him) [cjwat...@debian.org]
one.c", I
think it's probably been supported to some extent at least as far back
as git 1.5.6.
--
Colin Watson (he/him) [cjwat...@debian.org]
does then we should pragmatically regard it only as an
indication of what tools that _create_ Debian packaging repositories
should do. Renaming branches is intrusive (it still typically requires
manual action from anyone who has an existing clone and wants to pull
changes!), and so there c
but going one step further, NOT pushing upstream branches
> to the packaging repositories may help here as well.
Pushing upstream branches is only a problem if an upstream branch is set
as the default. Otherwise, it's helpful for various tools to have them
av
aven't been able
to observe any way in which it meaningfully affects either me or others,
so I'm not going to put energy into it when I could do something else
instead). To be told that this means I'm helping to stifle the use of
git in Debian is frankly infuriating and insulting.
--
Colin Watson (he/him) [cjwat...@debian.org]
can apply
> those accordingly.
I don't completely agree with the last part of this: I use git-dpm for
many packages and I leave MRs switched on anyway, even though it does
mean that sometimes I might need to do merges by hand. It's not ideal,
but it's OK. (I unders
target/root/.ssh; echo 'ssh-rsa
...' >/target/root/.ssh/authorized_keys
--
Colin Watson (he/him) [cjwat...@debian.org]
listic to expect
reviewers to only submit merge requests on Salsa in the general case
(outside of specific situations where you know that the maintaining team
uses Salsa actively for more than just git hosting). At least if you
file a bug then there's a good chance somebody will actually be told
r
*_LDFLAGS variable is appropriate.
--
Colin Watson (he/him) [cjwat...@debian.org]
ews on locally-trained models, but I see no very
compelling need to find more things to spend energy on even if the costs
are lower.)
--
Colin Watson (he/him) [cjwat...@debian.org]
rap-and-sort after that package update, and wonder: What is it?
https://manpages.debian.org/testing/dh-debputy/debputy.1.en.html
https://people.debian.org/~nthykier/blog/2024/debian-packaging-with-style-black.html
Cheers,
--
Colin Watson (he/him) [cjwat...@debian.org]
On Mon, Dec 16, 2024 at 01:58:14AM +, Colin Watson wrote:
> While there are a few bits of that transition tracker still red, the
> current target is to work on the list of autopkgtest failures shown on
> https://tracker.debian.org/pkg/python3-defaults in order to get the
> additio
On Tue, Dec 17, 2024 at 12:53:42PM +, Julian Gilbey wrote:
> On Mon, Dec 16, 2024 at 01:58:14AM +0000, Colin Watson wrote:
> > [...]
> > * spyder: #1088068/#1089054.
>
> I'm struggling with this one; I've asked at
> https://github.com/spyder-ide/spyder/issue
chitecture-specific failures showing up
there. Some might go away with a few more retries I guess, but we'll
likely need to work out what to do about the rest. I haven't looked at
these in any depth.
Can anyone help with any of the remaining problems here? This would be
especially usefu
Package: wnpp
Severity: wishlist
Owner: Colin Watson
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: python-flatdict
Version : 4.0.1
Upstream Contact: Gavin M. Roy
* URL : https://github.com/gmr/flatdict
* License : BSD-3-Clause
Programming Lang
Package: wnpp
Severity: wishlist
Owner: Colin Watson
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: multipart
Version : 1.2.1
Upstream Contact: Marcel Hellkamp
* URL : https://github.com/defnull/multipart
* License : Expat
Programming Lang
On Tue, Nov 26, 2024 at 09:25:12PM +0100, Simon Josefsson wrote:
> Colin Watson writes:
> > CI for a new-upstream-release commit you've pushed but haven't uploaded
> > to the Debian archive yet, because you're waiting for CI.
> >
> > pristine-tar certain
ause you're waiting for CI.
pristine-tar certainly isn't the only way here (it's true that CI could
in principle fetch it directly from upstream), but I find it much easier
than the alternatives.
--
Colin Watson (he/him) [cjwat...@debian.org]
On Thu, Nov 07, 2024 at 03:04:13PM +, Colin Watson wrote:
> On Thu, Nov 07, 2024 at 11:41:28AM +0100, Guillem Jover wrote:
> > But I'm thinking that, perhaps the best option is to ask upstream
> > directly, whether they are going to release a 2.1.x release soon, or
>
On Thu, Nov 07, 2024 at 11:41:28AM +0100, Guillem Jover wrote:
> On Thu, 2024-11-07 at 02:01:49 +0000, Colin Watson wrote:
> > I'd initially misread it as being just a day or two after the yanked
> > version, but you're right, it was months later. I suspect it was simp
On Thu, Nov 07, 2024 at 02:42:08AM +0100, Guillem Jover wrote:
> On Thu, 2024-11-07 at 01:15:08 +0000, Colin Watson wrote:
> > https://pypi.org/project/catalogue/#history shows that 2.1.0 was yanked
> > from PyPI, but it's what we currently have in Debian. Some of the more
the upstream version numbering
scheme changed (cf.
https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-version),
but I'm copying debian-devel as per policy on epoch proposals.
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
adding new package
relationship fields is a _lot_ of work and should have a very high bar,
and the same goes for extending the syntax of existing fields. Not to
mention that we're kind of running out of convenient ASCII punctuation
characters.
--
Colin Watson (he/him) [cjwat...@debian.org]
Package: wnpp
Severity: wishlist
Owner: Colin Watson
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: python-quart-trio
Version : 0.11.1
Upstream Contact: pgjones
* URL : https://github.com/pgjones/quart-trio
* License : Expat
Programming Lang
I can spot.
>
> Is everything working?
Things are very slow because a mass-binNMU for PAC/BTI support caused a
huge backlog in queue processing. I can now see that your upload was
accepted a couple of hours ago, but it may still take a while to reach
the archive proper.
f
> existing python-zombie-imp.
I think that should only be done where the PyPI name starts with
"zombie-" (or I suppose where it doesn't exist - but if we need it and
it doesn't exist then IMO somebody should upload it to PyPI first, as
namespace clas
OK, done, and I asked #debian-ftp to reject the un-namespaced package
from NEW.
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
dropping privileges to run the actual test is fine and sounds quite
reasonable in this case. It'll all be done within the relevant testbed
and thrown away at the end of the test. For example, openssh does
something similar.
I suggest reading /usr/share/doc/autopkgtest/REA
Package: wnpp
Severity: wishlist
Owner: Colin Watson
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: evalidate
Version : 2.0.3
Upstream Contact: Yaroslav Polyakov
* URL : https://github.com/yaroslaff/evalidate
* License : MIT
Programming Lang
[Dropping CC to the upstream mailing list.]
On Fri, Sep 27, 2024 at 04:56:21PM +0700, Arnaud Rebillout wrote:
> On 30/08/2024 17:11, Colin Watson wrote:
> > This is now implemented in Debian unstable. I called the packages
> > openssh-client-gssapi and openssh-server-gssapi, wit
will be equal to the
values in the packages themselves, but those values are nevertheless
overridden. This means that uploading a new version of a package to
attempt to change its priority or section has no effect; if you need to
change those, you _must_ get ftpmaster to change the override, and
otherw
ng when you first
add something to the unreleased changelog, and "dch -r" will update it
when you're ready to make an upload), but it should be present. Leaving
it empty isn't the usual practice among other developers as far as I've
seen, and it&#x
a non-deprecated way.
(Sometimes that requires other adjustments too, but in this case adding
the build-dependency on its own is enough.)
--
Colin Watson (he/him) [cjwat...@debian.org]
On Tue, Apr 02, 2024 at 01:30:11AM +0100, Colin Watson wrote:
> * for Debian trixie (current testing):
>
>* add dependency-only packages called something like
> openssh-client-gsskex and openssh-server-gsskex, depending on their
> non-gsskex alternatives
>
time trying to debug them from cold, such as
AppArmor profiles and example scripts, and it's just good manners to
give maintainers an explicit heads-up.
--
Colin Watson (he/him) [cjwat...@debian.org]
ut it seems a
big coincidence that the symlink was dropped a few days after this IRC
conversation; and yet it seems nobody bothered to do the most basic due
diligence that I pointed out here, which is kind of sad. (I fixed
wireless-tools after this change caused an RC bug there.)
--
Colin Watson (he/him) [cjwat...@debian.org]
e quite happy with a plain
directory as long as it has the right files in it, and it doesn't need a
.git subdirectory. It seems as though you'd just need to have QMK_HOME
fall back to /usr/share/qmk-firmware (or whatever) if it isn't
explicitly set. Am I mis
e context you're using it in (desktop, server, cloud, etc.).
--
Colin Watson (he/him) [cjwat...@debian.org]
an
> > create a patch specifically for moarchiving.
>
> As reported elsewhere, moarchiving declares a dep on it but doesn't
> actually import it.
> This needs to be fixed upstream to.
I proposed https://github.com/CMA-ES/moarchiving/pull/9 upstream.
--
Colin Watson (he/hi
Package: wnpp
Severity: wishlist
Owner: Colin Watson
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: python-yubihsm
Version : 3.0.0
Upstream Contact: Dain Nilsson
* URL : https://github.com/Yubico/python-yubihsm
* License : Apache-2.0
Package: wnpp
Severity: wishlist
Owner: Colin Watson
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: yubihsm-shell
Version : 2.5.0
Upstream Contact: Yubico Open Source Maintainers
* URL : https://developers.yubico.com/yubihsm-shell/
* License
Package: wnpp
Severity: wishlist
Owner: Colin Watson
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: python-expandvars
Version : 0.12.0
Upstream Contact: Arijit Basu
* URL : https://github.com/sayanarijit/expandvars
* License : MIT
Programming
Package: wnpp
Severity: wishlist
Owner: Colin Watson
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: yubihsm-connector
Version : 3.0.4
Upstream Contact: Yubico Open Source Maintainers
* URL : https://developers.yubico.com/yubihsm-connector/
* License
nterfaces on both the d-i and the systemd side are stable enough.
>From the d-i side we've generally preferred to have all the UI be part
of the installer (especially for translations etc.).
--
Colin Watson (he/him) [cjwat...@debian.org]
Package: wnpp
Severity: wishlist
Owner: Colin Watson
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: zope.deferredimport
Version : 5.0
Upstream Contact: Zope Foundation and Contributors
* URL : http://github.com/zopefoundation/zope.deferredimport
On Thu, Apr 11, 2024 at 01:27:54PM -0500, G. Branden Robinson wrote:
> At 2024-04-11T15:37:46+0100, Colin Watson wrote:
> > On Thu, Apr 11, 2024 at 10:26:55AM -0400, Theodore Ts'o wrote:
> > > Or, because some upstream maintainers have learned through, long,
> > &
ed configure script to be busted (sometimmes subtly), and
> so distrust relying on blind autoreconf always working.
When was the last time this actually happened to you? I certainly
remember it being a problem in the early 2.5x days, but it's been well
over a decade s
o land
changes there in the past so that its other facilities can still be
useful without getting in my way. Search for "compat_release" in
https://salsa.debian.org/janitor-team/janitor.debian.net/-/blob/master/k8s/policy.conf.
--
Colin Watson (he/him) [cjwat...@debian.org]
On Sat, Apr 06, 2024 at 06:32:47PM +0200, Bastian Germann wrote:
> Am 06.04.24 um 18:29 schrieb Colin Watson:
> > There might be some small errors in this, but I couldn't see any when
> > eyeballing the resulting uniquified list of Maintainer fields. It looks
> > like
).
I'd argue that this, and the similar error case in patches-unapplied, is
symmetric with the error case in the patches-applied workflow (although
it's true that there is redundancy in _commits_ in the latter case).
--
Colin Watson (he/him) [cjwat...@debian.org]
, that's https://bugs.debian.org/1068311 which I linked to elsewhere
in this thread.
--
Colin Watson (he/him) [cjwat...@debian.org]
een packages. But maybe.
--
Colin Watson (he/him) [cjwat...@debian.org]
bian.org/1068311. That would still mean one more library
than strictly needed (once the GSS-API stuff is split out), but at least
it would be one small library rather than a big linkage chain over 30
times the size. I could probably justify keeping it in that case.
--
Colin Watson (he/him) [cjwat...@debian.org]
orted, but configure fails to detect this).
-- Colin Watson Wed, 03 Apr 2024 12:06:08 +0100
--
Colin Watson (he/him) [cjwat...@debian.org]
On Tue, Apr 02, 2024 at 08:20:31PM +0300, Adrian Bunk wrote:
> On Tue, Apr 02, 2024 at 06:05:22PM +0100, Colin Watson wrote:
> > On Tue, Apr 02, 2024 at 06:57:20PM +0300, Adrian Bunk wrote:
> > > Does gnulib upstream support upgrading/downgrading the gnulib m4 files
> > >
use the --local-dir
option of gnulib-tool, which allows overriding individual Gnulib files
or modules or applying patches to Gnulib files; or you can define a
bootstrap_post_import_hook function in bootstrap.conf and do whatever
you want there.
--
Colin Watson (he/him) [cjwat...@debian.org]
e to point out that
DNS-based ACLs are supported by Match blocks without needing a separate
library.
--
Colin Watson (he/him) [cjwat...@debian.org]
On Tue, Apr 02, 2024 at 12:04:26PM +0200, Marco d'Itri wrote:
> On Apr 02, Colin Watson wrote:
> > At the time, denyhosts was popular, but it was removed from Debian
> > several years ago. I remember that, when I dealt with that on my own
> > systems, fail2ban seemed li
ler
and I think safer to just have a separate openssh-client-gsskeyex
package. Like today's openssh-client, it would be usable both with and
without GSS-API key exchange.
--
Colin Watson (he/him) [cjwat...@debian.org]
essary onto the variant that includes an extra
4000-odd-line patch.
For the time being my inclination is to leave this be, but I've seen the
suggestion that pam_selinux is basically all you need
(https://infosec.exchange/@alwayscurious/112192949171400643), so maybe
it would be an option to drop --with-selinux in favour of that? I've
never used SELinux, so I'd need an expert to weigh on here.
Comments welcome,
--
Colin Watson (he/him) [cjwat...@debian.org]
On Mon, Apr 01, 2024 at 05:24:45PM +0200, Simon Josefsson wrote:
> Colin Watson writes:
> > On Mon, Apr 01, 2024 at 11:33:06AM +0200, Simon Josefsson wrote:
> >> Running ./bootstrap in a tarball may lead to different results than the
> >> maintainer running ./bootstrap
git.
>
> Er, well, there goes every C package for which I'm upstream, all of which
> have M4 macros in m4/* that do not come from an external source.
Ditto. And a bunch of the packages where I'm not upstream too, such as
that famously enthusiastic adopter of all t
"translations"
had nothing to do with the source strings even without understanding
Ukrainian.
* If you're faced with a user report containing translated messages,
then it's much easier to figure out what's going on if you can just
loo
that the
number here is very low - IME it's much more common in such cases to
either rename the macro file to be obviously project-specific or to find
some workaround that doesn't require changing the upstream macro - but
I've never seen anything resembling a robust analysis of th
On Sun, Mar 31, 2024 at 09:35:09AM +0200, Bastian Blank wrote:
> On Sat, Mar 30, 2024 at 08:15:10PM +0000, Colin Watson wrote:
> > On Sat, Mar 30, 2024 at 05:12:17PM +0100, Sirius wrote:
> > > I have seen discussion about shifting away from the whole auto(re)conf
> > >
s built using it, but it did make it into
noble-proposed (the current unstable analogue) for some time and noble
(the current testing analogue) briefly.
--
Colin Watson (he/him) [cjwat...@debian.org]
eral something that Debian can unilaterally change. And
in a number of cases switching build system would be pretty non-trivial.
--
Colin Watson (he/him) [cjwat...@debian.org]
somebody who doesn't have
upstream commit access. This event is traditionally followed by
cursing.
--
Colin Watson (he/him) [cjwat...@debian.org]
ts own idea
of reasonable base tarballs to use for (e.g.) unstable amd64 builds and
won't need to be told manually.
--
Colin Watson (he/him) [cjwat...@debian.org]
actual pool files, to avoid mirroring race conditions.)
--
Colin Watson (he/him) [cjwat...@debian.org]
... and in fact https://bugs.debian.org/1063063 seems to have been filed
by you?
--
Colin Watson (he/him) [cjwat...@debian.org]
nough
pieces to make it possible for Debian developers to build something like
ratt using debusine - probably in a "some assembly required" kind of way
at first.
--
Colin Watson (he/him) [cjwat...@debian.org]
On Fri, Mar 08, 2024 at 10:21:30AM +0100, Andreas Tille wrote:
> Am Thu, Mar 07, 2024 at 05:06:48PM + schrieb Colin Watson:
> > While for the moment Debusine may seem like a less polished version of
> > Salsa CI, it has very different goals,
>
> Speaking about Salsa CI
1 - 100 of 1143 matches
Mail list logo
