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
ver passing every macro into a
> package, independent if it's used or not.
>
> Not seeing any benefit in this feature (hard failure).
Your examples aren't what Niels refers to as "relationship substvars",
so aren't affected either way by this proposal.
--
Colin Watson (he/him) [cjwat...@debian.org]
rticular field would be simpler than that - probably just two lines in
debian/rules. I think that would be tolerable if the need is as rare as
I think it is, though of course it'd be worth documenting.
--
Colin Watson (he/him) [cjwat...@debian.org]
he terminal log, but it's
possible you don't.
> This system is using sysvinit instead of systemd, and perhaps that's the
> problem? I noticed when I tried to reinstall wdm, apt wanted to remove
> sysvinit and presumably use systemd as the init program.
What happens if you try
iffs via the BTS. This remains the standard
> policy for NMUs in Debian per the Developer's Reference, and as far as I
> know has worked effectively for all such previous ABI transitions.
In the current situation, though, not having experimental available
means that there's no opp
at will break this
independent parser in future.
I also feel that something security-critical like this that's labelled
by upstream as "still experimental" probably shouldn't be in a Debian
release. Maybe it should be kept in Debian experimental for the time
being?
--
Colin Watson (he/him) [cjwat...@debian.org]
(as opposed to "-", "'",
"`", "^", and "~" respectively) will produce better printed output.
--
Colin Watson (he/him) [cjwat...@debian.org]
rom the typo in the last URL segment, the penultimate segment
identifies the binary package, and grog(1) is in the groff-base package
rather than groff.
https://manpages.debian.org/unstable/groff-base/grog.1.en.html
--
Colin Watson (he/him) [cjwat...@debian.org]
pe/2.13.0%2Bdfsg-1/ft2demos/man/ftlint.1/
Your problem is that you need this line as the very first line of the
page to instruct man(1) to run the tbl preprocessor:
'\" t
See https://manpages.debian.org/bookworm/man-db/man.1.en.html#DEFAULTS.
--
Colin Watson (he/him) [cjwat...@debian.org]
se you're seeing a warning from groff.
What exact check is failing here (is it lintian, or something else)?
Could you please give us a pointer to the man page in question?
--
Colin Watson (he/him) [cjwat...@debian.org]
hich
means any warnings it issues are going to be inaccurate representations
of how pages are actually rendered in practice. Your starting point
should be to add -t to the groff command line in this check, and then
see what else shows up after that.
--
Colin Watson (he/him) [cjwat...@debian.org]
kages from a source package rather than directly from git and the
source package doesn't usually include a git tree? Is it just a matter
of causing the plugin to exist so that pybuild doesn't fail, but in
practice the version is still going to be set by something that's
actually in th
compatibility syscalls allows
circumventing other systemd hardening that filters syscalls
(RestrictAddressFamilies=, MemoryDenyWriteExecute=, SystemCallFilter=).
Allowing qemu also doesn't make much difference either way to that
though - if your process can't make a syscall directly, it can
doesn't depend on installer support. There are doubtless edge cases
where you need a completely separate kernel, but they aren't really ones
I run into.
--
Colin Watson (he/him) [cjwat...@debian.org]
On Mon, Feb 27, 2023 at 03:26:52PM +0100, Alejandro Colomar wrote:
> On 2/27/23 13:56, G. Branden Robinson wrote:
> > At 2023-02-26T13:30:58+0000, Colin Watson wrote:
> >> First, move your current branch somewhere for reference, then make a new
> >> one. Then, my
deed take rather more than a month to clear its
build queues last time, even though it was only running two full
rebuilds rather than four. I don't think we're going to be able to get
real hardware with the hypervisor extension particularly soon, but we
may be able to throw some more x
which is probably a good idea since you're unfamiliar with
git-dpm.
> How do we move forward with this? I am anxious about the closing of the
> soft freeze window.
There is no way that this giant new upstream release will be suitable at
this stage in the freeze; it's too late.
On Sun, Nov 06, 2022 at 01:58:21PM +0900, Hideki Yamane wrote:
> Q3: Does OpenSSH9.1p go into bookworm?
I just uploaded this to unstable, so barring any major unforeseen issues
I expect this to be in bookworm, yes.
--
Colin Watson (he/him) [cjwat...@debian.org]
ch is still full of stupid vulnerabilities due to people
getting sprintf or realpath buffer sizes wrong or race conditions
while traversing directory trees.
--
Colin Watson (he/him) [cjwat...@debian.org]
1 - 100 of 1125 matches
Mail list logo
