I don't want to exacerbate the off-topic-message problem, but I'm hoping
that by saying the following I may perhaps be able to prevent further
messages to the list about this.
First, can we please be very careful, when we're throwing around talk
about banning people from lists, to make it
I think even "ssh-h3" is a confusing and frankly impudent name. The creator of
this new package appears to be intentionally trying to use the ubiquity of the
ssh "brand" to their benefit. This brand confusion can only harm end users and
I do not think Debian should facilitate it.
Even
Hello Lucas,
I think the reason why people are puzzled and hesitant to reply is that
your inquiry seemingly came out of nowhere and you've offered no context
for it. Why is this question being asked? Why are you the person asking
it? What are you going to do with the responses?
People are
enough to build/release to unstable
after some end-user testing without any additional changes. We'll see!
Thank you,
Jonathan Kamens
Version 4.2 of apt-listchanges is now available in experimental. Please
test.
Three important notes:
1) There was a bug in 4.1 that caused corruption in the database of
previously seen changelog entries (sorry!). The bug has been fixed, but
the corruption was too complex to be recoverable,
On 10/11/23 03:37, Alexandre Detiste wrote:
Le dim. 8 oct. 2023 à 17:27, Jonathan Kamens a écrit :
I'd appreciate some testing from folks here before it gets promoted to unstable.
I got important NEWS from libx11 from 2006 (?)
so far so good for the rest.
Can you confirm
,
jik
On 10/8/23 11:27, Jonathan Kamens wrote:
Hello friends,
I've adopted apt-listchanges and pushed a new version, 4.0, to
experimental, with a bunch of fixes in it. Given how extensive the
changes are, I'd appreciate some testing from folks here before it
gets promoted to unstable
On 10/10/23 02:18, Simon Richter wrote:
On 10/10/23 06:24, Jonathan Kamens wrote:
* binary package name different from source name
* deb contains no changelog or NEWS files in /usr/share/doc
* creates a symlink in /usr/share/doc with the binary package name as
its name, pointing
As Russ noted in his recent message, it may be safe to optimize
apt-listchanges by having it ignore packages which don't install any
actual files in /usr/share/doc and which create a /usr/share/doc symlink
pointing at another package.
I am therefore am considering adding the following
Allbery wrote:
Jonathan Kamens writes:
Regarding what I'm trying to accomplish, as part of the revamp of
apt-listchanges I need to rebuild the database that apt-listchanges uses
to determine which changelog and NEWS entries it has already shown to the
user. This can mostly be done from files
Thanks to everyone for the useful feedback. Some additional info and
comments:
I'm well aware that this is a hard problem and that just calling nmcli
is not an adequate solution. I was asking whether the problem has
already been solved in a Debian-canonical way, since there are lots of
other
generic, canonical way to do
this check?
Thanks,
Jonathan Kamens
that
attempts to run the job hourly after installation, and then have the job
disable the timer when it completes successfully.
Is there a better / different / "Debian standard" way to accomplish this?
Thanks,
Jonathan Kamens
P.S. Just for the record, the background job will checkpoint its
fine and you can take a moment to email me and let me know that as well,
I'd appreciate it, since that'll give me confirmation that it's gone
through some testing by people other than me.
Thank you,
Jonathan Kamens
On 9/26/23 10:24, Johannes Schauer Marin Rodrigues wrote:
piuparts is run outside the build chroot, not inside of it.
Thanks, that's useful info.
My best guess is that the issue here is that piuparts is installed in /sbin
and /sbin isn't in the default sudo path, but that would imply that
I'm trying to use sbuild to build my package, and it's failing to find
piuparts:
| Post Build |
+--+
piuparts
sudo: piuparts: command not
ider this a bug" seems, to me, to fit under "other reasons."
Is there some harm that is done by marking a bug that falls into this
category with "wontfix"?
jik
On 9/25/23 13:40, Andrey Rakhmatullin wrote:
On Mon, Sep 25, 2023 at 12:55:16PM -0400, Jonathan Kamens wr
sed the bug because it
wasn't actually a bug, but rather a PEBKAC issue (user complaining that
a program wasn't respecting his locale when he had LC_ALL set to "C" so
he was essentially telling the program to ignore his locale).
jik
On 9/25/23 12:13, Marvin Renich wrote:
* Jona
Thank you! A canonical answer at last.
On 9/25/23 10:53, Andrey Rakhmatullin wrote:
On Mon, Sep 25, 2023 at 07:16:56AM -0400, Jonathan Kamens wrote:
I recently tried to close a bug, explain why, and set a "wontfix" tag all at
once by sending my explanation to ###-d...@bugs.
...and I just successfully used a Control: header in an email to
###@bugs.debian.org, so the only question remaining in my mind is
whether the one that didn't work failed because it was sent to ###-done,
or failed because of the base64 encoding. I can't think of any other
reasons why the
o make it reliable and not catch something it
shouldn't.
So, if this is correct, then I apparently what I tried to do just
doesn't work. :shrug:
On 9/25/23 09:44, Peter B wrote:
On 25/09/2023 14:25, Jonathan Kamens wrote:
So putting a Control: line in the pseudo-header of a message sent to
###-d.
So putting a Control: line in the pseudo-header of a message sent to
###-d...@bugs.debian.org doesn't work at all?
On 9/25/23 09:06, Peter B wrote:
On 25/09/2023 12:16, Jonathan Kamens wrote:
Hi all,
I recently tried to close a bug, explain why, and set a "wontfix" tag
a
Hi all,
I recently tried to close a bug, explain why, and set a "wontfix" tag
all at once by sending my explanation to ###-d...@bugs.debian.org with
"Control: tags ### wontfix" as the first line of my message body. The
bug was closed but the tags command wasn't processed.
Looking at the raw
to maintain
high quality in Debian.
Thank you so much to everyone who has worked on this.
Regards,
Jonathan Kamens
24 matches
Mail list logo
