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]
irmware (which is
fine, the new debmirror doesn't object), but most people running mirrors
probably run stable rather than testing.
--
Colin Watson (he/him) [cjwat...@debian.org]
x27;t show it again for that version, but it's still
possible to edit it retroactively so that (for example) people upgrading
between stable releases see improved text. That can sometimes be
worthwhile.
--
Colin Watson (he/him) [cjwat...@debian.org]
-specific language for crontabs remains available, which seems
like a decent approach. I haven't used it, but in general I think the
crontab syntax is much stickier than the particular cron implementation.
--
Colin Watson (he/him) [cjwat...@debian.org]
On Fri, Mar 04, 2022 at 03:59:09PM +0100, Guillem Jover wrote:
> On Fri, 2022-03-04 at 14:36:01 +0000, Colin Watson wrote:
> > I reproduced a similar problem, then set up DKIM for myself and
> > everything then worked, so I think you're correct.
> >
> > The links
found
https://bynicolas.com/server/exim-multi-domain-dkim-custom-selector/
helpful in getting this going with my local Exim setup.
--
Colin Watson (he/him) [cjwat...@debian.org]
//buildd.debian.org/status/fetch.php?pkg=matplotlib&arch=mips64el&ver=3.3.4-2&stamp=1633211581&raw=1')
<(curl -s
'https://buildd.debian.org/status/fetch.php?pkg=matplotlib&arch=mips64el&ver=3.3.4-2%2Bb1&stamp=1637459674&raw=1')
--
Colin Watson (he/him) [cjwat...@debian.org]
all over the place, and there'll
be an enormous long tail of things to update, not to mention things like
old forum posts that can never really be updated.
I agree we might feel different in ten years' time!
--
Colin Watson (he/him) [cjwat...@debian.org]
On Mon, Aug 30, 2021 at 12:30:49PM +0200, David Kalnischkies wrote:
> On Sun, Aug 29, 2021 at 11:30:41PM +0100, Colin Watson wrote:
> > case) it seems mostly like the sort of user that could be anonymous
> > outside of the lifetime of an apt process, analogous to systemd&#x
On Sun, Aug 29, 2021 at 11:31:05AM -0700, Russ Allbery wrote:
> Colin Watson writes:
> > I think it's an interesting idea and worth pursuing, but on the face of
> > it it seems that this would end up violating policy 9.2.2:
>
> > "Globally allocated by the
_apt UID on upgraded systems, is in fact the better option?
Of course, another approach to the overall problem might be declarative
user creation in dpkg, e.g. #685734 and
https://wiki.debian.org/Teams/Dpkg/Spec/SysUser. But that's clearly a
lot of work, and this change wouldn't preclude it.
--
Colin Watson (he/him) [cjwat...@debian.org]
ly in each camp; I certainly
didn't see it as a confrontational sort of thing where we were having to
drag Debian along with us - rather the contrary, there was a lot of
enthusiasm in Debian for it.)
--
Colin Watson (he/him) [cjwat...@debian.org]
27;t have been before
2000 and I think it was probably around 2002.
I contributed that script to Debian in 2002 in response to
https://bugs.debian.org/94507, where it became clear that the previous
implementation wasn't really salvageable; Clint merged that in
debianutils 1.16.5. It's been
sn't exist without making it a full conffile. My own view
is: we should clarify Policy now to match current reality, and it can
always be strengthened later if people manage to get a more declarative
approach working well. I think this is in line with the last few
substantive messages in the bug report above.
--
Colin Watson (he/him) [cjwat...@debian.org]
On Mon, Nov 30, 2020 at 10:18:05AM +, Steve McIntyre wrote:
> Colin Watson wrote:
> >On Sun, Nov 29, 2020 at 07:21:54PM +, Steve McIntyre wrote:
> >> AFAICS I'd need to add at least basic support for the new type(s) into
> >> all the frontends that *can* su
about UI here: my plan would be to not have
> anything *selectable* at "a" - it would just toggle the display of the
> "a/*" subtree in those frontends that can display such a thing.
If we took that approach then it wouldn't work so well for the grub2
case, whe
y ever using the more obscure (to me!) frontends
> (e.g. kde, editor)? Is it worth spending time there?
Although these require manual selection, I think they do have at least
some use, and I'd rather keep them going. It shouldn't be too hard to
get full coverage, pulling in help from specialists if necessary.
--
Colin Watson (he/him) [cjwat...@debian.org]
On Wed, Nov 11, 2020 at 12:59:49PM -0500, Timothy M Butterworth wrote:
> I added a symbolic link "libGL.so ->
> /usr/lib/x86_64-linux-gnu/libGL.so.1" and that fixed the issue.
You should install the libgl-dev package instead of doing this manually.
--
C
information, Ubuntu imports packages from unstable (and runs its own
equivalent of a testing migration process), not from testing.
--
Colin Watson (he/him) [cjwat...@debian.org]
On Mon, Oct 26, 2020 at 08:16:43PM +, Simon McVittie wrote:
> On Mon, 26 Oct 2020 at 18:35:53 +0000, Colin Watson wrote:
> > LC_ALL should imply LANG
>
> One thing that it does not imply is LANGUAGE, used for LC_MESSAGES as a
> GNU extension (at a higher precedence than eve
et LC_ALL as
implying LANG, I'd consider that a bug.
--
Colin Watson (he/him) [cjwat...@debian.org]
On Tue, Jun 23, 2020 at 08:14:37AM +0200, Christian Kastner wrote:
> On 2020-06-23 02:12, Colin Watson wrote:
> > On Tue, Jun 23, 2020 at 01:10:31AM +0200, Ansgar wrote:
> >> On Mon, 2020-06-22 at 22:13 +0100, Colin Watson wrote:
> >>> [1]
> >>> https://
On Tue, Jun 23, 2020 at 01:10:31AM +0200, Ansgar wrote:
> On Mon, 2020-06-22 at 22:13 +0100, Colin Watson wrote:
> > For a while I'd thought that it was relatively harmless in comparison
> > to
> > full-blown uses of master/slave metaphors, but I saw some analysis of
>
. further discussion / something else / etc.
5. stick with master
I'm not that fussed about the relative ranking of 1-3, though, and I
agree it would be good to end up with something consistent if we can.
[1] https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00066.html
--
Colin
up taking for pydoctor
was to take a copy of the bits of epydoc that they needed and port those
bits to Python 3 themselves.
(This is second-hand; I'm not on the Twisted team, but I contribute a
fair bit there and generally keep an eye on what they're doing since we
rely on Twisted at
eek or two if nobody else picks this up.
--
Colin Watson [cjwat...@debian.org]
supported by libtool, so in libxcrypt I had to conditionally patch the
> generated libtool executable for the architectures that did this.
What exactly went wrong? libpipeline uses libtool and I've never had to
patch it for libc6.1.
--
Colin Watson [cjwat...@debian.org]
usually feels better to me). I don't think it matters
too much as long as it remains topologically-sorted, which both of these
approaches satisfy.
--
Colin Watson [cjwat...@debian.org]
ed-By in
> sources.list? I scanned the changelog but it was not immediately clear.
1.1~exp9. The commit was:
https://salsa.debian.org/apt-team/apt/commit/b0d408547734100bf86781615f546487ecf390d9
--
Colin Watson [cjwat...@debian.org]
ENOENT,
and then computes the timezone using the systematic format. So it isn't
even likely to make any performance difference worth mentioning.
Since TZ=UTC is technically correct per timezone(3), I'd stick with it
unless there's a demonstrable practical difference (perhaps
compatibility on some odd systems?) justifying the effort involved in
changing it.
--
Colin Watson [cjwat...@debian.org]
On Tue, Sep 24, 2019 at 11:52:11PM +0100, Colin Watson wrote:
> However, if you're worried you could patch in an extra bit of commentary
> in the header files. There's no need to repack the original tarball for
> this, and you mustn't remove the MIT licence notices (doing
On Tue, Sep 24, 2019 at 09:30:38PM +0200, Gard Spreemann wrote:
> Colin Watson writes:
> > On Tue, Sep 24, 2019 at 10:41:07AM +0200, Gard Spreemann wrote:
> >> A package I maintain (src:gudhi) was mostly under GPL-3+ up to and
> >> including the current version
ole; it's quite common for different parts of a work to
have different licences.
--
Colin Watson [cjwat...@debian.org]
1 - 100 of 1093 matches
Mail list logo
