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]
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]
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]
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]
eek or two if nobody else picks this up.
--
Colin Watson [cjwat...@debian.org]
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
. 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
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
>
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://
ase-passwd_3.5.39_amd64.deb
> dpkg_1.18.10_amd64.deb
> mawk_1.3.3-17_amd64.deb
> sensible-utils_0.0.9_all.deb
Thanks for your analysis. I agree that this ship has comprehensively
sailed, so I've removed the gzip override from base-passwd.
--
Colin Watson [cjwat...@debian.org]
32-434 in the latter link, at the moment), so I'm not sure if one needs
to bother in practice, but the option is certainly there.
Anyway, the spirit of Simon's remark is true even if details were a bit
off. Merely using libsystemd for sd_notify or similar doesn't make
daemon code systemd-specific.
--
Colin Watson [cjwat...@debian.org]
ated IDs across the whole archive, and the chances of
me requesting that you use a statically-allocated ID rather than the
other way round are vanishingly small).
In any case, I have no issues with this request.
Thanks,
--
Colin Watson [cjwat...@debian.org]
on with dose-builddebcheck
(https://anonscm.debian.org/cgit/mirror/wanna-build.git/tree/bin/wanna-build#n1846
and the various functions it calls).
--
Colin Watson [cjwat...@debian.org]
structure to follow through on
implementing Build-Indep-Architecture. I'm not sure how this interacts
with Debian's decision to make Architecture: all buildds separate
entities, since that means it isn't just a matter of setting a "build
the arch-indep portion as well&qu
On Sat, Nov 12, 2016 at 09:56:01AM +0100, Christoph Biedl wrote:
> Colin Watson wrote...
> > On Thu, Nov 10, 2016 at 08:52:15PM -0800, Nikolaus Rath wrote:
> > > That's a good theoretical argument. But in practice, I think the subset
> > > of architectures for which
On Sat, Nov 12, 2016 at 03:13:54PM +0100, Adam Borowski wrote:
> On Sat, Nov 12, 2016 at 09:56:01AM +0100, Christoph Biedl wrote:
> > Colin Watson wrote...
> > > We know this not to have been the case in the past.
> > > https://bugs.launchpad.net/launchpad/+bug/2
(fenix is dead upstream - homepage is still up but the links are all
> broken; it's never had a new upstream version in Debian.)
I have no particular attachment to pixfrogger et al, but the underlying
problem isn't new and isn't likely to be fixed by whack-a-mole.
--
Colin Watson [cjwat...@debian.org]
On Sat, Nov 12, 2016 at 06:27:55PM +0100, Johannes Schauer wrote:
> Quoting Colin Watson (2016-11-12 18:09:22)
> > > * it supports only a single build-indep architecture rather than a list
> >
> > Not so; you have misread the code. It is a list of architectures that
>
debconf database after
> installing the package?
You were right to check, since it's possible for packages to get this
wrong, but no, it's not.
Also, by default, questions of "password" type go into a separate
debconf database which is only readable by root. This isn't great
protection and packages should still ensure that passwords aren't left
there long-term, but it's better than nothing.
--
Colin Watson [cjwat...@debian.org]
And even aside from that, one sometimes needs to build-depend on a newer
debhelper because it fixes a bug or adds a particular feature, yet
without necessarily immediately opting into all the
compatibility-breaking changes that come with the higher compat level.
--
Colin Watson
ially true for cases like OpenSSH where some of the
patches correspond to externally-maintained patch sets - though in
practice upstream for said patch sets has been fallow for some time, but
at least in theory!)
--
Colin Watson [cjwat...@debian.org]
aybe git-dpm puts them there as well in some way that I don't
> understand?
Yes, it absolutely does. See e.g. openssh if you want to peer at a
medium-sized example.
--
Colin Watson [cjwat...@debian.org]
pkgtest extension: "Restrictions: unreliable"?
May as well just use "Restrictions: allow-stderr" and "... || true".
That's easier to do on a more fine-grained level, too.
--
Colin Watson [cjwat...@debian.org]
7;t AFAIK) any
> notion
> of blocking due to RC bugs.
That's not quite true: I added support for considering bugs with a
"block-proposed" tag in October 2013. I agree that that's after
autopkgtest handling was added (June 2013), and that the block-proposed
tag is not as w
distinct term for that segment of the suite for tools such as
Launchpad that need to apply policy to the same pocket in multiple
series, such as "can't change -updates when the series hasn't been
released yet" or "-backports is published with NotAutomat
he benefit of a tiny audience: the
> disturbed people who hate systemd so much that they cannot accept even
> that libsystemd is installed on their computers.
It would be of some benefit to the rest of us because we could probably
stop having conversations about it more quickly by pointing to
he Ubuntu archive. We
publish PPAs directly from our database rather than going via
apt-ftparchive, but we've never quite managed to get that to perform
acceptably at the scale of the Ubuntu archive. I suppose it might be
worth another go.
--
Colin Watson [cjwat...@debian.org]
more likely to see that it is about to be removed, and can
> take corrective action if they don't want to have that happen?
It'd probably make sense to use
https://www.debian.org/Bugs/server-control#affects for this.
--
Colin Watson [cjwat...@debian.org]
On Fri, Feb 02, 2018 at 06:44:36PM +0200, Adrian Bunk wrote:
> On Fri, Feb 02, 2018 at 02:29:49AM +0000, Colin Watson wrote:
> > It'd probably make sense to use
> > https://www.debian.org/Bugs/server-control#affects for this.
>
> How would that help?
It would at least m
On Sun, Feb 04, 2018 at 03:22:13PM +0200, Adrian Bunk wrote:
> On Sat, Feb 03, 2018 at 05:57:26PM +0000, Colin Watson wrote:
> > I think at the moment the "affects" field in a bug's metadata doesn't
> > cause the maintainer of the affected packages to be copied o
e they could get it
> through manually?
There's no such facility. The only way is to bump the version in some
way so that there are no collisions.
--
Colin Watson [cjwat...@debian.org]
On Tue, Feb 06, 2018 at 12:28:54PM +0100, Mattia Rizzolo wrote:
> On Tue, Feb 06, 2018 at 08:37:44AM +0000, Colin Watson wrote:
> > I disagree - reusing file names with different contents in a
> > Debian-format archive is IMO always wrong regardless of the time elapsed
> > be
accepted solution?
Simply jumping back to -12 seems perfectly reasonable; there's no need
for fake changelog entries. There's no requirement to increment
versions one by one.
--
Colin Watson [cjwat...@debian.org]
e version,
because the contents of that tarball will (one hopes) be identical.
You'd just need to make sure that the Debian revision isn't reused.
--
Colin Watson [cjwat...@debian.org]
e/ch06.en.html#repackagedorigtargz
[2] https://lists.gnu.org/archive/html/grub-devel/2018-02/msg00033.html
Thanks,
--
Colin Watson [cjwat...@debian.org]
On Mon, Feb 12, 2018 at 10:42:16AM +, Simon McVittie wrote:
> On Mon, 12 Feb 2018 at 10:28:33 +0000, Colin Watson wrote:
> > I also cannot simply remove the relevant file in this case (a CRC
> > implementation), as doing that would break too many existing pa
On Mon, Feb 12, 2018 at 12:09:50PM +, Wookey wrote:
> On 2018-02-12 11:22 +0000, Colin Watson wrote:
> > Huh. I hadn't thought of that option, but it seems peculiar and
> > excessively baroque (it basically splits the patch into a remove and an
> > add, making it l
On Sat, Feb 17, 2018 at 08:42:44PM +0100, Adam Borowski wrote:
> Binary code that has debug symbols isn't that bad. I don't think you can
> have those for minified JS.
JavaScript source maps have been around for a few years and AIUI are
pretty much exactly that.
On Mon, Feb 12, 2018 at 10:28:33AM +, Colin Watson wrote:
> Does this seem like a reasonable way forward, or should I instead just
> apply the backport as an ordinary patch and override
> license-problem-non-free-RFC for the patch file?
Thanks for the feedback, everyone. While
this is all so much blowing smoke, since I'm not
actually volunteering ... but I develop webapps in the
frozen-dependencies style at work and still see value that a
distribution like Debian could provide by way of packaging, so wanted to
offer some suggestions that I think might be useful compromises.
--
Colin Watson [cjwat...@debian.org]
On Sun, Feb 18, 2018 at 12:48:49PM +, Holger Levsen wrote:
> On Sat, Feb 17, 2018 at 11:14:51PM +0000, Colin Watson wrote:
> > * Constrained to the sort of server-side applications that might
> >reasonably be run in a container on their own, just to keep the
> >pr
March/040222.html
too.
(Without support in Launchpad, the format isn't going to be widespread
in Ubuntu.)
--
Colin Watson [cjwat...@debian.org]
ferent than in Ubuntu).
Can you elaborate on how this is different than in Ubuntu? It sounds
pretty similar to me, except for being a delay instead of a block. Or
did you mean that the social consequences are different?
(I echo Simon's thanks for doing this, though!)
--
Colin Watson [cjwat...@debian.org]
whether I want to mostly leave them alone and deploy something that's
maybe not absolutely up to date but where somebody else is dealing with
most of the maintenance work (in which case packages would be
preferable).
--
Colin Watson [cjwat...@debian.org]
n thing to
varying extents; we can still very usefully serve those who just want a
package that works out of the box.
--
Colin Watson [cjwat...@debian.org]
t'd be incumbent on whoever's doing the Debian upload to
actually check the licensing status.
--
Colin Watson [cjwat...@debian.org]
y even less work for you, and
it doesn't make it look like the old version of protobuf is being
packaged for general use.
--
Colin Watson [cjwat...@debian.org]
vel of course, but
you can contact us at feedb...@launchpad.net, or #launchpad on freenode.
--
Colin Watson [cjwat...@debian.org]
d then be stranded on an old
version that compares greater than all current versions. Doing so for
source packages would be unconventional but could be discussed.
--
Colin Watson [cjwat...@debian.org]
nchpad work is
needed in this case.)
--
Colin Watson [cjwat...@debian.org]
simultaneously ?
I don't disagree with you in general, but this is a bad example since
the way you work on porterboxes these days is to run a thing that gives
you your own schroot instance (https://dsa.debian.org/doc/schroot).
--
Colin Watson [cjwat...@debian.org]
could be tolerable with
sufficient commentary and care. I doubt I would be contemplating it if
init-select hadn't been removed from stretch.
Thoughts? Can anyone think of a better solution than either of the two
I've outlined here?
Thanks,
--
Colin Watson [cjwat...@debian.org]
doesn't hurt.
I think I probably agree that removing the file is sensible, but my
experience is that it's a good idea to have an unusual amount of review
of unusual and difficult-to-undo conffile handling ideas: so I've
written this up for the TC's consideration as
https://bugs.debian.org/865929.
Thanks,
--
Colin Watson [cjwat...@debian.org]
Package: wnpp
Severity: wishlist
Owner: Colin Watson
* Package name: httmock
Version : 1.2.6
Upstream Author : Patryk Zawadzki
* URL : https://github.com/patrys/httmock
* License : Apache-2.0
Programming Lang: Python
Description : Mocking library for
Package: wnpp
Severity: wishlist
Owner: Colin Watson
* Package name: py-macaroon-bakery
Version : 0.0.1
Upstream Author : Juju UI Team
* URL : https://github.com/go-macaroon-bakery/py-macaroon-bakery
* License : LGPL-3
Programming Lang: Python
Description
are-1.1.2/change.log
Debian *may* have been the first distribution to include
machine-parseable changelogs in a consistent source package format, but
I'm not particularly certain of that.
--
Colin Watson [cjwat...@debian.org]
ow installed as
"changelog" installed. But there were two files both before and after
that change.
In any case, that wasn't a typical matter of an upstream changelog vs.
Debian changelog, but more like two separate packages that were managed
as part of the same source tree but had in
existing system to use.
If you want to look at the history of discussions, you're welcome to
look at Debian's mailing list archives; most of the early stuff will be
on debian-devel (https://lists.debian.org/debian-devel/).
--
Colin Watson [cjwat...@debian.org]
it's been a pretty good experience on armhf and
definitely much faster than what we had before.
[1]
https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/commit/kernel/sys.c?id=fff84367fa2a19f20c2b9094b47bc3db51fed183
I can't really speak for how it would be on arm
ebconf, or am I wrong
>there?
The frontend is often started via the confmodule sourced by a maintainer
script (and then the maintscript re-execed under the frontend), so for
better or worse you do need DISPLAY and the like in the current design.
--
Colin Watson [cjwat...@debian.org]
nk?
I probably wouldn't bother. Although the project doesn't formally
support skip-upgrades, a fair few maintainers probably do so informally.
> Probably it's more useful to file wishlist bugs against packages
> depending on those… or should those be normal severity?
Normal
On Sun, Oct 15, 2017 at 10:21:59AM +, Holger Levsen wrote:
> On Sun, Oct 15, 2017 at 10:49:37AM +0100, Colin Watson wrote:
> > >parted (U)
> > This is blocked on reverse-dependencies. I've filed:
> > https://bugs.debian.org/878626
> > https:/
036346.html
[4] https://github.com/openssh/openssh-portable/pull/48
[5] Sorry, I don't have a link for this right now; if needed I can trawl
back through openssh-unix-dev history for it.
--
Colin Watson [cjwat...@debian.org]
On Mon, Oct 16, 2017 at 10:00:50PM +0200, Sebastian Andrzej Siewior wrote:
> On 2017-10-16 17:29:09 [+0100], Colin Watson wrote:
> > While there does exist a skeletal compatibility layer linked from the
> > upstream wiki [1], the OpenSSL developers explicitly don't want
ckaged library though; I don't have enough experience with
SSL library maintenance to be able to say.
--
Colin Watson [cjwat...@debian.org]
isn't great, but it would probably
still be better than maintaining my own list! I think I'll do this.)
--
Colin Watson [cjwat...@debian.org]
On Fri, Dec 01, 2017 at 12:35:06AM +, Colin Watson wrote:
> (Hmm, though maybe a reasonable stopgap would be to copy the relevant
> syscall lists from systemd's code. That would leave me updating things
> manually from time to time, which isn't great, but it would probabl
On Thu, Nov 30, 2017 at 07:18:43PM -0800, Seth Arnold wrote:
> On Fri, Dec 01, 2017 at 01:29:44AM +0000, Colin Watson wrote:
> > but should be much easier to maintain, and would probably also make it
> > easier to switch to a syscall-set-confining library if such a thing
> >
somebody who's putting more work into keeping it
complete and current than I want to put into doing a small part of the
job. :-)
--
Colin Watson [cjwat...@debian.org]
t belong in a version string; it can be
documented in the changelog instead. I'd put a date in the version.
--
Colin Watson [cjwat...@debian.org]
On Mon, Sep 14, 2015 at 10:46:10AM +0200, Pau Garcia i Quiles wrote:
> On Mon, Sep 14, 2015 at 8:51 AM, Colin Watson wrote:
> > I wouldn't put the commit identifier in the package version at all. It
> > isn't sortable, so clearly doesn't belong in a version strin
rchitectures entirely unnecessarily. Hi,
Haskell.)
--
Colin Watson [cjwat...@debian.org]
:Depends}
>
> and generate substitution for ${astrometry-data} appropriate for the host
> architecture in debian/rules.
... especially if you use DEB_HOST_ARCH_ENDIAN to do it. See
dpkg-architecture(1).
--
Colin Watson [cjwat...@debian.org]
e
> > host architecture in debian/rules.
>
> The virtual package should then not be Architecture: all, but "any"?
That would be required for architecture-specific dependencies in any
case; [...] architecture specifiers are handled at build-time by
uot;live-build-ng".
This seems pretty over the top to me and I was expecting it to be called
vmdebootstrap-live or something like that; at the very least, calling
something "-ng" seems like it sets pretty high expectations.
--
Colin Watson [cjwat...@debian.org]
usr/bin/tbl
debian/groff-base/usr/bin/troff debian/groff-base/usr/bin/soelim
debian/groff-base/usr/bin/groff returned exit code 2
debian/rules:3: recipe for target 'binary-arch' failed
make: *** [binary-arch] Error 2
groff doesn't build-depend on libstdc
Package: wnpp
Severity: wishlist
Owner: Colin Watson
* Package name: git-build-recipe
Version : 0.2.1
Upstream Author : Colin Watson
* URL : https://launchpad.net/git-build-recipe
* License : GPL-3
Programming Lang: Python 3
Description : construct a
gt;= 0.43), foo (<< 1.0)
>
> have the desired effect?
This is indeed exactly what you should do.
--
Colin Watson [cjwat...@debian.org]
On Tue, Mar 22, 2016 at 12:51:20AM +0100, Adam Borowski wrote:
> [1]. There's probably some method that puts way less load on the BTS server
> available for DDs.
https://www.debian.org/Bugs/Access documents rsync access for this kind
of thing.
--
C
ctually prove Steve's point?
You were able to stick with the behaviour you wanted by continuing to
use an older compat level, which means that things weren't changed on
you retroactively.
--
Colin Watson [cjwat...@debian.org]
age1 perl for the sake of debhelper,
or avoiding debhelper in perl's own packaging, helps anything.
(This was all doubtless entirely different pre-multiarch; I'm not
criticising decisions made back then.)
--
Colin Watson [cjwat...@debian.org]
h_auto_build and dh_auto_clean to use
phing rather than ant. This will be in addition to the Build-Depends on
phing.
If this starts being widespread, then you might consider writing a
debhelper add-on yourself, although it's unlikely to be worth the effort
for just one package.
--
Colin Watson [cjwat...@debian.org]
Package: wnpp
Severity: wishlist
Owner: Colin Watson
* Package name: pymacaroons
Version : 0.9.2
Upstream Author : Evan Cordell
* URL : https://github.com/ecordell/pymacaroons
* License : Expat
Programming Lang: Python
Description : Macaroon library
On Tue, May 17, 2016 at 01:35:14PM +0100, Colin Watson wrote:
> On Tue, Jul 28, 2015 at 08:44:05AM +0200, David Douard wrote:
> > On 07/27/2015 12:08 PM, Vincent Bernat wrote:
> > > ❦ 5 avril 2015 22:12 +0200, David Douard :
> > >> * Package name: libnacl
&g
On Mon, May 23, 2016 at 11:03:37AM +0200, David Douard wrote:
> On 05/23/2016 10:49 AM, Colin Watson wrote:
> > I've pushed preliminary packaging here:
> >
> > https://anonscm.debian.org/cgit/collab-maint/python-libnacl.git
> >
> > David, if I don'
r would type on the keyboard
> using that key such as an --option or command-name, the manpage should
> just use "-".
That's specifically contrary to upstream's consistent typographical
advice over the years, and your suggested advice has its own problems
such as inappropria
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
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
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
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.
[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
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]
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
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
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]
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 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
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
1001 - 1100 of 1141 matches
Mail list logo
