Package: ntpsec
Severity: wishlist
Enable the gpsd JSON driver.
Upstream NTPsec never followed through with the plans to remove it.
Gary (upstream NTPsec and upstream gpsd) prefers SHM and does not use
it, but is not against users using it:
https://gitlab.com/NTPsec/ntpsec/-/issues/668#note_2
Package: ntpsec
Severity: wishlist
On 2025-06-25 18:53, Dave Hart wrote:
I certainly would encourage you to add "nomrulist" to Debian's
"restrict default" line, despite it having no effect combined with
"noquery". It would raise awareness and provide a backstop for those
who find reason for r
On 2025-04-14 11:10, Russ Allbery wrote:
I do find it fairly hard to understand the logic behind a position that
somehow our git-remote-https binary as distributed is a derived work of
OpenSSL and thus violates the GPLv2 license based on the nature of this
specific dependency chain, but then I wa
The relevant bit of the build log is this:
PYTHONDIR : /usr/local/lib/python3.13/dist-packages
PYTHONARCHDIR : /usr/local/lib/python3.13/dist-packages
That's not what happens on my system (running unstable). I get this,
which is what it always has been:
On 2025-04-12 08:31, Sebastian Ramacher wrote:
stderr:
runtests: ../../libaes_siv/tests.c:80: test_malloc_failure: Assertion `ret ==
1' failed.
Nothing in that code has changed recently.
Is this reproducible?
Here is what the relevant test case code looks like:
/* This needs to be the
On 2025-03-03 03:31, MOESSBAUER, Felix wrote:
On Fri, 2025-02-28 at 23:23 -0600, Richard Laager wrote:
On 2024-10-24 09:24, Felix Moessbauer wrote:
the ntpsec service starts the ntpd binary with the option "-N|--
nice" (defined
in ntpsec.default (/etc/default/ntpsec) [1]. By that
On 2025-03-03 05:16, Thorsten Glaser wrote:
Is there a way to say “give me only v4 or only v6 from this pool”
I haven't tested, but you could try:
pool -4
pool -6
I believe the server directive takes that, but I don't know if the pool
does.
or “deduplicate the pool result based on reverse
First off, I'm sorry this took forever.
I've removed the transitional packages from src:ntpsec. I removed all of
them, not just ntpdate.
I uploaded with "low" priority to give this a little longer in unstable
before it hits testing.
Once it does, I presume I need to ask ftp-master to remove
What does `ntpq -pn` report?
I suspect the answer is that you are getting the server once with IPv4
and once with IPv6.
--
Richard
OpenPGP_signature.asc
Description: OpenPGP digital signature
I'm sorry for the very delayed response...
If I'm understanding this correctly, you are using a udev rule to create
a symlink from /dev/refclock-0 to /dev/ttyUSB0 (or whatever number).
I'm not sure how AppArmor deals with symlinks in this context. Does it
work if you just allow the /dev/refcl
On 2024-10-24 09:24, Felix Moessbauer wrote:
the ntpsec service starts the ntpd binary with the option "-N|--nice" (defined
in ntpsec.default (/etc/default/ntpsec) [1]. By that, the ntpd will run with
the highest possible priority, which is SCHED_FIFO, prio 99. These
priorities are discouraged as
Control: fixed 1079734 2.14.14-1
--
Richard
OpenPGP_signature.asc
Description: OpenPGP digital signature
Control: fixed 2.14.14-1
--
Richard
OpenPGP_signature.asc
Description: OpenPGP digital signature
Package: phppgadmin
phpPgAdmin seems to be unsupported upstream.
See, for example:
https://github.com/phppgadmin/phppgadmin/pulls
There are multiple PRs open for supporting PHP 8 and PostgreSQL 15.
There seems to be an actively maintained fork here:
https://github.com/ReimuHakurei/phpPgAdmin
This sounds reasonable to. It looks like you beat me to this with an
NMU. Thanks!
On 2024-03-15 04:08, Gianfranco Costamagna wrote:
Package: libgnt
Version: 2.14.4-1.1
Severity: serious
Tags: patch
Hello, I found some runtime dependencies, such as removed libglib2.0-0
breaking every 32bit bui
(Replying via mobile, so non-Debian address.)
It should be reasonably possible to convert this to .d style. I will have to
dig into this to fully consider all the implications, especially around
handling upgrades. I think part of the issue here is that ntpd logs there by
default. That is, you d
Control: reopen -1
On 2024-03-12 11:10, MOESSBAUER, Felix wrote:
On Tue, 2024-03-12 at 10:33 -0500, Richard Laager wrote:
This is intentional. The logging is optional and whether the
directory
exists controls this.
Hi Richard,
that's a quite uncommon interface. Is this at least docum
I think, but am not sure, that this is now functionally a duplicate of
#1060506. That one tells me to change it from systemd to systemd-dev
because:
Since systemd_253-2 [1], these two pkgconfig files have been split
into a separate package named systemd-dev. This package is arch:all,
I agree that the description, as provided, would be a bug.
However, I cannot reproduce this.
Can you provide your ntp.conf file, in full, please?
--
Richard
OpenPGP_signature.asc
Description: OpenPGP digital signature
If I'm understanding this correctly, I just need to install a file with
the contents "ntpsec.service" to
/usr/lib/systemd/ntp-units.d/50-ntpsec.list. That's easy enough to do.
--
Richard
OpenPGP_signature.asc
Description: OpenPGP digital signature
On 2023-12-26 22:02, Martin-Éric Racine wrote:
On Wed, Dec 27, 2023 at 5:54 AM Richard Laager wrote:
On 2023-12-26 21:43, Martin-Éric Racine wrote:
Looking at the diff for the Hurd port
What Hurd port?
https://deb.debian.org/debian-ports/pool-hurd-i386/main/n/ntp/
That is the wrong
On 2023-12-26 21:43, Martin-Éric Racine wrote:
Looking at the diff for the Hurd port
What Hurd port?
--
Richard
OpenPGP_signature.asc
Description: OpenPGP digital signature
On 2023-12-26 02:38, Martin-Éric Racine wrote:
On Mon, Dec 25, 2023 at 12:20 AM Richard Laager wrote:
If past me was correct, without systemd at build-time, waf will not
install the systemd units. Then we will end up with other failures in
debian/rules or from the .install files.
Not
On 2023-12-12 04:52, Martin-Éric Racine wrote:
Build-Depends: systemd must be changed to systemd [linux-any], since systemd
has not been powerted to non-Linux platforms.
I suspect that change would be necessary, but not sufficient.
In commit 7f969a0ecab4ef3ab50defd4fe9d7e7a47817dbe, I wrote:
Control: fixed 1.2.2+dfsg1-3
This looks to be the same as #1052664.
--
Richard
OpenPGP_signature.asc
Description: OpenPGP digital signature
On 2023-12-18 16:15, Bob Proulx wrote:
Package: ntpsec
Version: 1.2.2+dfsg1-3
Severity: normal
Tags: patch
Every time the ntpsec package upgrades it attempts to unconditionally
add the ntpsec user and group as per the following postinst snippet.
addgroup --system --quiet ntpsec
On 2023-12-22 05:32, Stefan Bauer wrote:
Apparmor denies creation of /var/lib/ntp/drift-tmp.
Where are you getting /var/lib/ntp/drift from?
The ntpsec package in Debian has (from when both ntp and ntpsec existed
in Debian) everything namespaced under "ntpsec". It uses
/var/lib/ntpsec/ntp.dri
On 2023-12-20 09:57, Sven Joachim wrote:
I have not tested it myself, but these errors should be fixed in libgnt
2.14.4 which has been released upstream the other day. See
https://keep.imfreedom.org/libgnt/libgnt/rev/2da723f790d6, which
explicitly mentions this bug.
Thanks for letting me know!
From ntpdate (the wrapper):
# Known bugs:
# * The -e and -p options of ntpdate are not yet implemented.
# * ntpdate took 4 samples and chose the best (shortest trip time).
# This takes the first.
I suppose there are maybe 4 options here:
A) Do nothing.
B) Change adjtimex to not pass -p.
C) Cha
On 2023-08-15 10:35, Santiago Vila wrote:
Either a missing /var/log/ntpsec directory is considered a "supported
configuration" or it's not.
I agree with you on the general point.
I'll process this bug in more detail when time allows, in the relatively
near future. I currently expect the answe
The "pool" directive spins up more associations than it needs and then
prunes them back (which takes a while).
https://docs.ntpsec.org/latest/quick.html#pool
https://docs.ntpsec.org/latest/discover.html#assoc
With 4 pool servers each returning 4 A records and one of them returning
4 recor
Fix pending as:
https://salsa.debian.org/debian/ntpsec/-/commit/ed7cf69b3c7ec6cc21a604e47fbf6ee9a9966117
Feedback welcome!
1. I brought back some of the (manual) postrm bits for the ntp &
ntpdate packages. This was something I should have preserved when
making the transitional packages.
Fix pending as:
https://salsa.debian.org/debian/ntpsec/-/commit/ed7cf69b3c7ec6cc21a604e47fbf6ee9a9966117
Feedback welcome!
1. I brought back some of the (manual) postrm bits for the ntp &
ntpdate packages. This was something I should have preserved when
making the transitional packages.
Fix pending as:
https://salsa.debian.org/debian/ntpsec/-/commit/ed7cf69b3c7ec6cc21a604e47fbf6ee9a9966117
Feedback welcome!
1. I brought back some of the (manual) postrm bits for the ntp &
ntpdate packages. This was something I should have preserved when
making the transitional packages.
Is this reproducible for you? If you have experience with building from
source, upstream has proposed the following patch. Otherwise, I could
build a test package for you.
diff --git a/ntpd/nts_cookie.c b/ntpd/nts_cookie.c
index 166d0230f..a73955fb7 100644
--- a/ntpd/nts_cookie.c
+++ b/ntpd/nts
Some questions from upstream, with my commentary added...
How busy is this sustem? Is it just a simple client or also a server? If
server, how busy?
From the stack trace, the server side is trying to decode a NTS cookie. Is this
box setup as a NTS server? That needs a certificate and key so i
I forwarded this upstream. I'm not sure how much upstream will care. But
hopefully I can get a firm answer either way.
--
Richard
On 2023-06-28 20:14, forest.ow...@riseup.net wrote:
On 2023-06-28 02:39, Richard Laager wrote:
The original submitter replied off the tracker (probably by accident). I'll
summarize here.
The ntp.conf he included is the stock ntp.conf.
He indicated he will try to get a backtrace.
I
On 2023-06-27 17:35, Bastian Germann wrote:
Am 28.06.23 um 00:13 schrieb Richard Laager:
The last bugfix release took them more than 3 years and when #767 is
released is unknown.
When a release happens is irrelevant, as you can carry #767 as a patch
in the Debian package until then.
Even
The original submitter replied off the tracker (probably by accident).
I'll summarize here.
The ntp.conf he included is the stock ntp.conf.
He indicated he will try to get a backtrace.
--
Richard
Wait a minute... You are a maintainer for cyrus-sasl.
You have already addressed the BSD-4-clause-KTH in the latest upload.
You also fixed debian/copyright to reference BSD-3-Clause-Attribution in
the latest upload. That license is fine for the reasons I mentioned.
That just leaves the MD5 st
On 2023-06-27 16:19, Richard Laager wrote:
For BSD-3-Clause-Attribution
BTW, my suggestion of asking CMU to drop the clause should not be read
as taking or agreeing to the position that it is GPL-incompatible.
I don't actually see an incompatibility with BSD-3-Clause-Attribution.
Bastian,
I see you have raised the severity on this bug again.
What is your goal here?
Cyrus SASL has reverse (binary) dependencies in the ballpark of 7,500.
Quickly taking that list through UDD gives me just over 4,500 source
packages. Surely, a large number of those are going to be GPL lice
On 2023-06-27 16:19, Richard Laager wrote:
For RSA-MD, I'd imagine there are other MD5 implementations that could
be dropped in relatively easily.
Also, Bastian Germann mentioned in bug #1036113:
"See https://github.com/cyrusimap/cyrus-sasl/issues/513 for an
implementation that l
On Thu, 13 Apr 2023 14:36:12 +0200 Bastian Germann wrote:
Hi Philipp,
Thanks for clarifying that. There is one file in cyrus-sasl2 that is licensed under BSD-4-clause-KTH (which really has
an advertisement clause), which we can get rid of; see https://github.com/cyrusimap/cyrus-sasl/pull/724.
I'm not sure if you saw this, as he didn't send it directly to you, but
Matt Selsky asked:
> Can you please share your ntp.conf or if there's a particular server
> that seems to cause this segfault so that we can try to reproduce it?
Also, can you get a stack trace? There are some instructions
I've made a suggestion upstream of how we could do better here by making
this either a fatal error or at least a warning. If it was a fatal error
with a good error message, you would have figured it out immediately.
Let's see what people think of that.
--
Richard
On 2023-06-07 03:22, Rob Janssen wrote:
On 6/7/23 10:13, Richard Laager wrote:
On 2023-06-07 02:37, Rob Janssen wrote:
Yes I was using the "ntp" package before.
I have upgraded and it installed "ntpsec". I tried to remove it as I have no
need
for the "security"
On 2023-06-07 02:37, Rob Janssen wrote:
Yes I was using the "ntp" package before.
I have upgraded and it installed "ntpsec". I tried to remove it as I have no
need
for the "security" part but it removed "ntp" as well.
And then you presumably reinstalled it. Did this result in you starting
ov
The answer is so obvious as soon as someone said it!
The default "minsane" is "3" (see "tos minclock 4 minsane 3" in
/etc/ntpsec/ntp.conf). Try commenting out that line, or if that doesn't
work, set both to "1".
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
Since you've moved to chrony, this is probably moot for you. But in case
it affects anyone else, I forwarded this upstream:
https://gitlab.com/NTPsec/ntpsec/-/issues/790
Can you confirm you were running the "ntp" package on bullseye, not
"ntpsec"?
--
Richard
OpenPGP_signature
Description:
At first glance, I agree that these should be cleaned up. I just need to
actually do the work on this, ASAP, of course.
On 2023-05-22 08:40, Christoph Anton Mitterer wrote:
Oh and I've just noticed that I've had accidentally reported the bug
against ntpsec, not ntp.
That is correct, I believe
First, I've downgraded the severity on this to "important". We are
currently in a freeze with a release imminent. Removing pidgin from the
next Debian release is a significant step that we should not undertake
lightly. The issue at hand has existed for years, possibly a decade or
even two, with
On 4/29/23 21:54, Steven Monai wrote:
I downloaded and unpacked this source on a Bookworm host. The build
system bundled with the source ("waf") seems to assume python 2.x, but,
unfortunately, Bookworm provides only python3. Any hints?
Quick approach is try this:
python3 waf configure ...
pyth
forwarded 1033088 https://gitlab.com/NTPsec/ntpsec/-/issues/785
thanks
Sorry for the delay in responding. I had hoped to try to reproduce this
myself. But I need to be honest with myself that it's simply not going
to happen.
Can you confirm whether you get either of these messages to stderr o
On 9/27/22 14:00, Dima Kogan wrote:
root@shorty:/home/dima# ntpdate-debian
sed: can't read /etc/ntpsec/ntp.conf: No such file or directory
Yep, I see the issue. I'll upload a fix.
The missing file is in the "ntpsec" package, which is not in the
Depends, and maybe should be there. If I i
I've submitted a patch upstream to suppress those messages except in
debug mode, since they are clearly confusing:
https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1288
This bug probably should have been marked fixed already once the
upstream change to make them non-fatal was uploaded to Debi
On 6/26/22 02:18, Klaus Ethgen wrote:
When package ntp is installed (from long history), the ntp daemon is
started by this /etc/init.d/ntp which uses user ntp:ntp. So all
auxiliary directories and files are owned by ntp:ntp.
I agree this is the expected "before" state.
When ntpsec starts to s
I think this is because it Depends: a kernel << 5.18 and not
Conflicts/Breaks a kernel >= 5.18. Since you can install multiple kernel
packages, your existing kernel package is satisfying the dependency.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
[Responding on mobile.] I’ll take a look at it, as obviously it should be made
to work. But on Debian, there shouldn’t be a need for ntpleapfetch, as the
tzdata package ships the leap second file.
--
Richard
> On Jun 11, 2022, at 22:33, Martin Maney wrote:
>
>
> Correction: does not apply
On 5/25/22 02:05, Samtinel wrote:
Are other GTK apps working?
Yes, dino-im starts successfully.
GTK 2
Uh, this I did not check. I will do that when I get to my terminal later. So
you happen to know a simple GTK 2 package I can test on?
I don't. So much stuff has moved to GTK 3 (or now GTK
I really don't know. Are other GTK apps working? If so, GTK 2 apps
specifically?
--
Richard
On 5/20/22 01:56, Evangelos Ribeiro Tzaras wrote:
Hi,
On Thu, 2022-05-19 at 22:23 -0500, Richard Laager wrote:
On 5/19/22 04:04, Evangelos Ribeiro Tzaras wrote:
Thanks for the patch! I'll upload a fixed version soon.
If you upload a new version, you (or I) can then close the binNMU
re
On 5/19/22 04:04, Evangelos Ribeiro Tzaras wrote:
Thanks for the patch! I'll upload a fixed version soon.
If you upload a new version, you (or I) can then close the binNMU
request, bug #1011201.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
Control: notfound 1011166 pidgin/2.14.9-2
Control: tags 1011166 patch
On 5/17/22 15:34, Paul Gevers wrote:
I note that
the library moved location from /usr/lib/purple-2/libjabber.so.0.0.0 to
/usr/lib/x86_64-linux-gnu/purple-2/libjabber.so.0.0.0.
I converted from an ancient compat version to m
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
Severity: normal
chatty directly links against an internal library (libjabber.so.0) in
libpurple0. This is technically wrong, but at the moment, it is what it is.
I converted libpurple0 to multiarch, which
This has hopefully been fully fixed now (upstream). It will land in the
2.14.9 release, which should be coming next week. However, I've uploaded
a backport of it now.
--
Richard
On 1/31/22 19:37, Trey Glover wrote:
I had no idea that the treasury was doing this. Is there a code fix in place
yet?
In unstable, yes; it's fixed in 2.0.3-17. I wrote code to use the
Treasury API to generate old-style sbMM.asc files which are stored
(as always) in ~/.gbonds/
In stabl
Package: ieee-data
Version: 20210605.1
I ran into this on 20180805.1 on Ubuntu 20.04, but I verified that the
same URLs are present in Debian's 20210605.1.
update-ieee-data references URLs (see the files_to_get variable near the
top) which which no longer work.
For example, this 404s:
https
On 1/25/22 17:08, Christoph Anton Mitterer wrote:
On Tue, 2022-01-25 at 16:34 -0600, Richard Laager wrote:
Consider a powerful attacker who a) runs a clocksource one trusts and
b) can block traffic to any other sources in the pool one uses?
Does NTP(sec) complain eventually (like too many
On 1/25/22 10:45, Christoph Anton Mitterer wrote:
On Tue, 2022-01-25 at 00:54 -0600, Richard Laager wrote:
There are two potential issues:
A) the server serves bogus/malicious time
B) a MITM messes with the time.
(A) is kinda what I'd want to prevent by having -g removed... at lea
I'm relatively set on the idea of breaking out ntpdig, since it's the
renamed replacement for sntp which is broken out in src:ntp, which we
are talking (on debian-devel) about ntpsec replacing.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
Control: reopen -1
On 1/24/22 13:25, Christoph Anton Mitterer wrote:
On Tue, 2022-01-18 at 21:52 -0600, Richard Laager wrote:
Shouldn't -g be removed?
First off, note that the stock ntpsec.service has Restart=no, not
Restart=yes. So in the malicious/broken server scenario described,
I have a few questions:
1. What is your use case for ntpdig and/or ntpdate (please be specific
which) if not for the hooks? Note that ntpdate is a wrapper script
around ntpdig that upstream does not install by default. And then
there's ntpdate-debian wrapping ntpdate.
2. My recollection is t
A couple more things:
This seems like it would qualify for the stable-updates special case to
be pushed out before the next point release. Granted, this is not a
popular package, so I'm not sure if that affects the decision.
I don't immediately have plans to make updates for buster or stretc
s/download-sites 2020-08-15 17:41:52.0
-0500
+++ gbonds-2.0.3/debian/patches/download-sites 1969-12-31 18:00:00.0
-0600
@@ -1,15 +0,0 @@
-Description: Remove snaught.com from the download list
- It didn't have the latest redemption data. This leaves only the
- offici
Package: gbonds
Version: 2.0.3-8
Severity: grave
The U.S. Treasury has discontinued publishing the sbMM.asc files on
its FTP site. Unfortunately, this means that GBonds is unable to update
its redemption tables. Given that a, if not the, major reason to use
GBonds is to track the current r
FWIW, you can force OpenSSL with this, which is what I do:
module(load="omrelp" tls.tlslib="openssl")
--
Richard
On a related note, I still need to bring this package's debehlper compat
level current. That would hopefully address these:
W: finch-dev: pkg-config-unavailable-for-cross-compilation
usr/lib/pkgconfig/finch.pc
W: libpurple-dev: pkg-config-unavailable-for-cross-compilation
usr/lib/pkgconfig/purpl
I've uploaded a 2.14.7-2 with the upstream patch that should fix the
issue. If it doesn't, please let me know.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
On 10/1/21 7:11 AM, Václav Ovsík wrote:
This is the changeset causing segfaults.
Thanks! That's excellent that you bisected it all the way to a commit
(not just a release). I've copied this to the upstream bug report.
--
Richard
On 9/30/21 7:16 AM, Vaclav Ovsik wrote:
after ugprade of pidgin:amd64 to 2.14.7-1 from 2.14.1-1+b1
Are you in any position to bisect this by building the intermediate
2.14.x versions of Pidgin?
--
Richard
Thanks for your report. I was finally able to find some time today for
Debian work. I've updated to the latest Pidgin release. I do have a lot
more work to do on modernizing the packaging, but at least we're
shipping the latest upstream release now.
--
Richard
Package: systemd
Version: 247.9-2+b1
Severity: normal
$ pkg-config --variable systemd_system_unit_dir systemd
/lib/systemd/system
This should be /usr/lib/systemd/system instead. debhelper and lintian
now use/expect this path. See:
lintian-explain-tags systemd-service-in-odd-location
which re
og
ntpsec-1.2.0+dfsg1/debian/changelog
--- ntpsec-1.2.0+dfsg1/debian/changelog 2021-01-20 20:36:38.0 -0600
+++ ntpsec-1.2.0+dfsg1/debian/changelog 2021-06-17 00:15:04.0 -0500
@@ -1,3 +1,9 @@
+ntpsec (1.2.0+dfsg1-4) unstable; urgency=medium
+
+ * ntpkeygen: Stop using # character: CVE-202
I've uploaded a targeted fix to unstable and requested an unblock.
--
Richard
On 6/14/21 1:59 PM, Moritz Muehlenhoff wrote:
Package: ntpsec
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team
This was assigned CVE-2021-22212:
https://gitlab.com/NTPsec/ntpsec/-/issues/699
Patch:
https://gitlab.com/NTPsec/ntpsec/-/commit/b09be47d650280cc7ebdcd45dfa07eca4
Unfortunately, I don't see any references to 5353 in any of that.
However, I do see a mention of libgstmicrodns.so. I wonder if that's
related. Could you run:
dpkg -S /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstmicrodns.so
Then remove whatever package ships that library? You can reinstall it
On 5/16/21 7:50 PM, Richard Laager wrote:
So it's happening in a child process.
Gary had an idea here... Pidgin generally only uses child processes for
DNS. Is it possible that you have some NSS plugin that is doing this?
Specifically, do you have libnss-mdns installed? I do, and I
On 5/19/21 3:31 PM, Andreas Beckmann wrote:
Should libgnt-doc have a Depends/Recommends/Suggests: libglib2.0-doc ?
Yes. Thanks! In the course of investigating this, I found that I also
need libglib2.0-doc as a Build-Depends.
I've made both fixes, but intend to wait to upload until after the
On 5/16/21 3:21 AM, Slavko wrote:
I didn't see it, pidgin.log attached, but tcpdump shows them. Then i
tried it with -f option to strace:
Good thinking. So it's happening in a child process.
A good next step is to use gdb, but the fork will complicate things. I
think you can do "set detach-on
Can you try this:
rm -rf pidgin-test
mkdir pidgin-test
strace -e trace=socket,sendto pidgin -c pidgin-test 2>&1 | \
tee pidgin.log
Hopefully you'll see some socket() call for 5353 and some sendto() calls
as it sends the packets.
If so, then let's try to find out what is opening that socke
I was never able to reproduce this, nor was Gary (Pidgin lead developer).
Are you able to narrow this down at all? For example, if you run:
mkdir pidgin-test
pidgin -c pidgin-test
that will start with a blank config. Does it happen then? If not, try
adding accounts and/or enabling plug
I am not able to reproduce this. Do you have a packet capture?
Specifically, I'd like to know what sort of request it is.
--
Richard
This obviously took me a long time to get to, but I finally have.
1. As discussed with Ari, I have adopted the Pidgin package. I also
made a few cleanups at the same time. More extensive updating (e.g.
to modern debhelper compat) will probably have to wait until after
bullseye, given the
On 1/19/21 6:09 PM, Diederik de Haas wrote:
# journalctl -kaf --no-hostname | grep -w 'apparmor="DENIED"'
jan 20 00:45:32 kernel: audit: type=1400 audit(1611099932.689:41):
apparmor="DENIED" operation="open" profile="/usr/sbin/ntpd"
name="/etc/ssl/openssl.cnf" pid=43157 comm="ntpd" requested_mask
FWIW, I gave the patch a review and it seems sane to me. I also looked
at the package in unstable and confirmed that zgenhostid is being
installed to /sbin, not /bin.
--
Richard
On 12/21/20 2:51 AM, Debian Bug Tracking System wrote:
I'd expect the update of ntpsec triggers too the update of libssl1.1 to a
compatible version.
I ended up taking the opposite approach. I patched out the OpenSSL build
vs install version check from upstream NTPsec. While I definitely think
tags 971523 upstream
forwarded 971523 https://gitlab.com/NTPsec/ntpsec/-/issues/680
On 10/1/20 4:13 AM, Petter Reinholdtsen wrote:
> ntpdig: socket error on transmission: [Errno 101] Network is unreachable
>
> My guess is that you have working IPv6, while I do not.
>
> root@devuan-n900:~# ping6
On 10/12/20 9:29 PM, John Goerzen wrote:
> I have set up this system to use ZFS crypto rather than my more conventional
> zfs-atop-LUKS.
Can you explain a little bit more about how you setup your system?
This (root-on-ZFS with native encryption) already works for me on Buster
(with ZFS from bust
1 - 100 of 340 matches
Mail list logo
