Source: dublin-traceroute
Version: 0.4.2-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
The package has a manual build-depends on libtins4.0, which is NBS. It
has been renamed libtins4.5. Once it is decrufted, this package will
Source: dublin-traceroute
Version: 0.4.2-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
The package has a manual build-depends on libtins4.0, which is NBS. It
has been renamed libtins4.5. Once it is decrufted, this package will
Source: python-cobra
Version: 0.26.2-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
The package build-depends on the NBS package libsbml5. It has been
renamed libsbml5t64. Once the package is decrufted, this one will
FTBFS.
Please
Source: python-cobra
Version: 0.26.2-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
The package build-depends on the NBS package libsbml5. It has been
renamed libsbml5t64. Once the package is decrufted, this one will
FTBFS.
Please
Source: alire
Version: 1.2.1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
The package libgnatcoll21-dev has been renamed to libgnatcoll-dev. Once
libgnatcoll21-dev is decfufted, it will FTBFS. Please update your build
depends.
Source: alire
Version: 1.2.1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
The package libgnatcoll21-dev has been renamed to libgnatcoll-dev. Once
libgnatcoll21-dev is decfufted, it will FTBFS. Please update your build
depends.
Source: dwarf-fortress
Version: 0.47.04+dfsg1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source
The package has a manual build-depends on libgtk2.0-0, which has been
replaced by libgtk2.0-0t64. Once it has been decrufted, the package
will no longer build.
Scott K
Source: dwarf-fortress
Version: 0.47.04+dfsg1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source
The package has a manual build-depends on libgtk2.0-0, which has been
replaced by libgtk2.0-0t64. Once it has been decrufted, the package
will no longer build.
Scott K
Source: theli
Version: 3.1.4-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Once libcurl4 is decrufted, the package will no longer build. The
libcurl4 package has been replaced by libcurl4t64.
Scott K
Source: theli
Version: 3.1.4-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Once libcurl4 is decrufted, the package will no longer build. The
libcurl4 package has been replaced by libcurl4t64.
Scott K
Source: python-nbxmpp
Version: 4.5.4-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source
This package has a hard coded build-depends on libglib2.0-0, which is
NBS and the package will FTBFS once it is decrufted. It was renamed
libglib2.0-0t64 as part of the 64 bit time
Source: python-nbxmpp
Version: 4.5.4-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source
This package has a hard coded build-depends on libglib2.0-0, which is
NBS and the package will FTBFS once it is decrufted. It was renamed
libglib2.0-0t64 as part of the 64 bit time
On Tuesday, April 16, 2024 5:17:44 PM EDT Todd Herr wrote:
> Colleagues,
>
> DMARCbis currently describes the value of 'n' for the 'psd' tag in a policy
> record as follows:
>
> The DMARC policy record is published for a PSD, but it is not the
> Organizational Domain for itself and its
On Wednesday, April 17, 2024 11:41:34 AM EDT Alessandro Vesely wrote:
> On Tue 16/Apr/2024 23:17:44 +0200 Todd Herr wrote:
> > Colleagues,
> >
> > DMARCbis currently describes the value of 'n' for the 'psd' tag in a
> > policy
> >
> > record as follows:
> > The DMARC policy record is
On Wednesday, April 17, 2024 9:20:10 PM EDT John Levine wrote:
> It appears that Todd Herr said:
> >When DMARC was first developed, there was concern about DNS load and
> >needing to minimize DNS lookups. Operational expertise now shows that this
> >is no longer cause for concern.
> >
> >Short
On Wednesday, April 17, 2024 9:42:23 AM EDT Todd Herr wrote:
> On Wed, Apr 17, 2024 at 1:06 AM Scott Kitterman
>
> wrote:
> > I am confused.
> >
> > Under the current (7489) rules a record for _dmarc.c.d.e.f.tld won't be
> > found
> > either in this cas
On Tuesday, April 16, 2024 4:55:49 PM EDT Todd Herr wrote:
> On Mon, Apr 15, 2024 at 8:08 PM Douglas Foster <
>
> dougfoster.emailstanda...@gmail.com> wrote:
> > Todd, can you clarify this?
> >
> > N is not concerned with maximum labels on a subdomain. We are interested
> > in the maximum
On Tuesday, April 16, 2024 2:24:07 PM EDT John Levine wrote:
> It appears that Scott Kitterman said:
> >In the case of a.b.c.example.com and example.com is in the PSL, the DMARC
> >records in a.b.c.example.com (if present) and example.com (otherwise) are
> >consulted.
On April 16, 2024 2:36:53 AM UTC, John Levine wrote:
>It appears that Scott Kitterman said:
>>>I'm with Scott, pick a number, 5, 8, whatever, and be done with it.
>>>
>>Modulo we do need to explain why 8. Related, I think we also need to explain
>&g
On April 15, 2024 4:34:40 PM UTC, John Levine wrote:
>It appears that Alessandro Vesely said:
>>8 is not needed and not justified. A mail site using 8 labels would have
>>troubles with the RFC 7489 version, which uses the PSL. They'd have to ask
>>for
>>PSL upgrades, right?
>
>No, they
On April 15, 2024 11:43:08 AM UTC, Alessandro Vesely wrote:
>On Mon 15/Apr/2024 13:16:50 +0200 Douglas Foster wrote:
>> Our original choice of N was based on the PSL. The PSL could not detect
>> organizational boundaries could not boundaries below level 5, because it had
>> no entries
Package: casacore-data-services
Version: 2-4
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Will now FTBFS due to missing build-depends.
Scott K
Package: casacore-data-services
Version: 2-4
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Will now FTBFS due to missing build-depends.
Scott K
On April 14, 2024 7:13:55 PM UTC, Steffen Nurpmeso wrote:
>Scott Kitterman wrote in
> <2c92eb24-3332-436c-a0bb-d4bac3322...@kitterman.com>:
> |On April 14, 2024 1:53:07 AM UTC, Steffen Nurpmeso \
> |wrote:
> |>Scott Kitterman wrote in
> |> <5368ac9a-51d5-4ae
On April 14, 2024 1:53:07 AM UTC, Steffen Nurpmeso wrote:
>Scott Kitterman wrote in
> <5368ac9a-51d5-4aec-ab19-613dbead7...@kitterman.com>:
> |On April 14, 2024 12:51:26 AM UTC, Steffen Nurpmeso \
> |wrote:
> |>Hello.
> |>
> |>Thanks to Hanno Böck (know
On April 14, 2024 12:51:26 AM UTC, Steffen Nurpmeso wrote:
>Hello.
>
>Thanks to Hanno Böck (known from ossec and more) i was pointed to
>my falsely published ED25519 DKIM key.
>Until now that simply was the complete ED25519 public key, just
>like for RSA, instead of extracting the actual
On Mon, 25 Mar 2024 18:48:44 + (UTC) Thorsten Alteholz
wrote:
> Control: tags -1 + moreinfo
>
> Hi,
>
> there are reverse dependencies that need to be taken care of:
>
>
> Checking reverse dependencies...
> # Broken Depends:
> baresip: baresip-x11
>
> # Broken Build-Depends:
> baresip:
** Changed in: cyrus-imapd (Ubuntu)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1971469
Title:
FTBFS against openssl 3
To manage notifications about
On April 9, 2024 6:37:23 PM UTC, Holger Levsen wrote:
>hi,
>
>just adding some random data points to this thread:
>
>- I love git.
>- I very much dislike git-buildpackage, too much magic. I try to avoid it
> where I can.
>- I like salsa. (though I think for many new contributors this is
On Monday, April 8, 2024 12:48:13 PM EDT Marc Haber wrote:
> > > "we replace exim with postfix as the default MTA",
> >
> > A, this question always makes me wonder: If our default MTA is exim
> > why do I have such a hard time to find documents about exim in wiki.d.o
> > while there is
On April 8, 2024 1:02:53 AM UTC, Neil Anuskiewicz
wrote:
>
>
>> On Apr 7, 2024, at 7:00 AM, Neil Anuskiewicz wrote:
>>
>>
>>
>>> On Apr 7, 2024, at 6:54 AM, Tero Kivinen wrote:
>>>
>>> Scott Kitterman writes:
>>>>
On April 7, 2024 4:32:06 PM UTC, "John R. Levine" wrote:
>On Sat, 6 Apr 2024, Scott Kitterman wrote:
>> As a side effect of the switch to the tree walk approach in DMARCbis, this is
>> no longer true. For any subdomain without a DMARC record, the domains above
&
osure, copying or
> distribution of the information included in this transmission is prohibited
> and may be unlawful. Please immediately notify the sender by replying to
> this email and then delete it from your system.
>
> On Sat, Apr 6, 2024 at 13:44 Scott Kitterman wrote:
> > Th
d of any use, disclosure, copying or
> distribution of the information included in this transmission is prohibited
> and may be unlawful. Please immediately notify the sender by replying to
> this email and then delete it from your system.
>
> On Sat, Apr 6, 2024 at 13:01 Scott Kitte
On Saturday, March 30, 2024 4:05:17 PM EDT Seth Blank wrote:
> Section 4.6: DNS Tree Walk:
>
> The text is correct, but N is wrong. I've shared my notes with this list
> but we never reached consensus:
> https://mailarchive.ietf.org/arch/msg/dmarc/GoExCeJYWhxnvH8lwjbr7nAcFh4/
>
> tl;dr: N of 5
On Monday, April 1, 2024 4:45:20 PM EDT Todd Herr wrote:
> Greetings.
>
> Issue 141 has been opened to collect ideas around the discussion about what
> to say in DMARCbis (if anything) about honoring SPF records that end in
> -all when SPF fails.
>
>
On Sunday, March 31, 2024 3:45:31 PM EDT Seth Blank wrote:
> On Sun, Mar 31, 2024 at 2:00 PM John Levine wrote:
> > It appears that Mark Alley said:
> > >> People who publish -all know what they do.
> > >
> > >I posit that there is a non-insignificant amount of domain owners that
> > >don't
On April 4, 2024 12:59:34 PM UTC, Andreas Tille wrote:
>Hi Scott,
>
>Am Thu, Apr 04, 2024 at 12:42:11PM + schrieb Scott Kitterman:
>> I'm interested to understand what you think this has to do with the DPL
>> election or the role of the DPL within the project?
>
On April 4, 2024 12:32:45 PM UTC, Andreas Tille wrote:
>Hi,
>
>in the light of the previous discussion I have a question to all voters.
>Due to bug #1066377 more than 30 testing removal warnings hit my mailbox
>today (I stopped counting after 30). While the Debian Med package
>clustalo is the
The next postfix upload to unstable should address this by using a trigger to
restart postfix any time one of the map type packages is configured.
Scott K
On April 1, 2024 11:05:02 PM UTC, John Levine wrote:
>It appears that Todd Herr said:
>>Issue 144 has been opened for the question of what to say about ARC (RFC
>>8617) in the context of indirect mail flows, a la Murray's example text
>>from this post
On March 31, 2024 7:49:08 PM UTC, Seth Blank
wrote:
>On Sun, Mar 31, 2024 at 1:40 PM Scott Kitterman
>wrote:
>
>>
>>
>> On March 31, 2024 5:32:13 PM UTC, "John R. Levine" wrote:
>> >>>> I’m probably being pedantic here: is “gov” a dom
On March 31, 2024 5:32:13 PM UTC, "John R. Levine" wrote:
I’m probably being pedantic here: is “gov” a domain?
>>> Yup, it's a domain.
>> I stand corrected on that.
>
>Anything that meets the DNS spec is a domain namen, e.g., argle.bargle.parp is
>a domain name. If and how particular
On March 30, 2024 11:27:42 PM UTC, "Murray S. Kucherawy"
wrote:
>On only the charter point:
>
>On Sat, Mar 30, 2024 at 2:27 PM Jim Fenton wrote:
>
>>
>> >> ??? Not Found
>> >> -
>> >>
>> >> I expected to find some text at least recommending a rewriting strategy
>> for From
On March 31, 2024 3:20:41 PM UTC, Jim Fenton wrote:
>
>
>On 30 Mar 2024, at 17:22, John R. Levine wrote:
>
> Entities other than domains: Public suffixes aren’t (necessarily) domains,
Of course they're domains. What else could they be? The things that are
out of scope are
On March 29, 2024 6:55:51 PM UTC, "Pierre-Elliott Bécue"
wrote:
>
>Matt Taggart wrote on 29/03/2024 at 17:14:24+0100:
>
>> On 3/29/24 04:11, Fabio Pedretti wrote:
>>> Hi, I'd like to request the backports of xz-utils from bookworm to bullseye.
>>
>> As long as it's the security fixed
On Sun, 21 Jan 2024 12:09:30 -0500 Scott Kitterman
wrote:
> As we approach the first anniversary for this bug, an update:
>
> I've recently adopted pypdf and pypdf2 into the Debian Python Team in
response
> to an RFA for both packages. As these are somewhat security sensitive
On Sun, 21 Jan 2024 12:09:30 -0500 Scott Kitterman
wrote:
> As we approach the first anniversary for this bug, an update:
>
> I've recently adopted pypdf and pypdf2 into the Debian Python Team in
response
> to an RFA for both packages. As these are somewhat security sensitive
On Sun, 21 Jan 2024 12:19:23 -0500 Scott Kitterman
wrote:
> As we approach the first anniversary for this bug, an update:
>
> I've recently adopted pypdf and pypdf2 into the Debian Python Team in
response
> to an RFA for both packages. As these are somewhat security sensitive
On Sun, 21 Jan 2024 12:08:35 -0500 Scott Kitterman
wrote:
> As we approach the first anniversary for this bug, an update:
>
> I've recently adopted pypdf and pypdf2 into the Debian Python Team in
response
> to an RFA for both packages. As these are somewhat security sensitive
On Sun, 21 Jan 2024 12:17:53 -0500 Scott Kitterman
wrote:
> I've recently adopted pypdf and pypdf2 into the Debian Python Team in
response to an RFA for both packages. As these are somewhat security
sensitive packages (among my first acts after adopting the packages was to
upload propo
On Sun, 21 Jan 2024 12:08:35 -0500 Scott Kitterman
wrote:
> As we approach the first anniversary for this bug, an update:
>
> I've recently adopted pypdf and pypdf2 into the Debian Python Team in
response
> to an RFA for both packages. As these are somewhat security sensitive
On Sun, 21 Jan 2024 12:07:19 -0500 Scott Kitterman
wrote:
> As we approach the first anniversary for this bug, an update:
>
> I've recently adopted pypdf and pypdf2 into the Debian Python Team in
response
> to an RFA for both packages. As these are somewhat security sensitive
On Sun, 21 Jan 2024 13:14:34 -0500 Scott Kitterman
wrote:
> Source: ocrmypdf
> Version: 15.2.0+dfsg1-1
> Severity: wishlist
>
> I've recently adopted pypdf and pypdf2 into the Debian Python Team in
response to an RFA for both packages. As these are somewhat security
sensitive
On March 22, 2024 11:31:16 PM UTC, Steffen Nurpmeso wrote:
>David Harris wrote in
> <65fd789c.26406.50826...@david.harris.pmail.gen.nz>:
> |My thanks to Murray S. Kucherawy, who was most helpful in answering my
> |previous questions about specifics of RFC6376..
> |
> |I now have my
On March 22, 2024 2:52:28 AM UTC, John Levine wrote:
>According to Mark Alley :
>>> I don't feel particularly strongly about this, but I can see people
>>> thinking there's some correlation between DKIM testing and DMARC
>>testing. It's not completely illogical, so it might be better to be
On March 21, 2024 11:39:35 PM UTC, "Murray S. Kucherawy"
wrote:
>On Fri, Mar 22, 2024 at 12:59 AM Scott Kitterman
>wrote:
>
>> >> For t=y, DKIM says:
>> >>
>> >>y This domain is testing DKIM. Verifiers MUST NOT treat
&
On March 21, 2024 2:15:00 PM UTC, Todd Herr
wrote:
>On Thu, Mar 21, 2024 at 5:55 AM Alessandro Vesely wrote:
>
>> On Wed 20/Mar/2024 23:11:20 +0100 Matthäus Wander wrote:
>> > Alessandro Vesely wrote on 2024-03-20 15:42:
>> >> what is the result of DMARC on having, say
>> >>
>> >>
On March 20, 2024 3:19:33 PM UTC, Ralph Seichter via clamav-users
wrote:
>* Damian via clamav-users:
>
>>> requirements.txt:
>>> requests >= 2.22.0
>>> SQLAlchemy >= 1.4.0
>>
>> Are those requirements sharp? I wonder if Fangfrisch could run on
>> older Debian systems with Debian-shipped
On Tuesday, March 19, 2024 5:23:52 AM EDT Alessandro Vesely wrote:
> On Mon 18/Mar/2024 21:37:02 +0100 Scott Kitterman wrote:
> > On March 18, 2024 6:40:54 PM UTC, Alessandro Vesely
wrote:
> >>On Mon 18/Mar/2024 09:14:26 +0100 Dotzero wrote:
> >>> On Mon, Mar 18,
On March 18, 2024 6:53:29 PM UTC, John R Levine wrote:
>On Mon, 18 Mar 2024, Alessandro Vesely wrote:
>> The text should be terser and clearer, possibly with an example.
>
>I would be happy to remove the whole thing, since it's only distantly related
>to defining or implementing DMARC.
I
On March 18, 2024 6:40:54 PM UTC, Alessandro Vesely wrote:
>On Mon 18/Mar/2024 09:14:26 +0100 Dotzero wrote:
>> On Mon, Mar 18, 2024 at 2:38 AM John R Levine wrote:
>>> On Sun, 17 Mar 2024, Dotzero wrote:
> Whenever mail is sent, there is a risk that an overly permissive source
> may
On March 18, 2024 9:19:21 AM UTC, Dominik George
wrote:
>Hi,
>
>>FYI: This message got delivered at the public mailing list
>>debian-python@lists.debian.org. To me it looks like someone if trying to find
>>a loophole in launchpad and plans to abuse the system.
>
>Thanks for reaching out to
On March 18, 2024 3:15:42 AM UTC, "Murray S. Kucherawy"
wrote:
>On Mon, Mar 18, 2024 at 1:08 PM Dotzero wrote:
>
>>
>> Add this to 11.1 Authentication Methods
>>>
>>>
>>> Both of the email authentication methods that underlie DMARC provide
>>> some assurance that an email was transmitted by
On March 18, 2024 1:36:29 AM UTC, John Levine wrote:
>Tightened up a little, reworded in view of the fact that your own
>mail provider (M*r*s*ft) may let people spoof you through shared IP ranges.
>
>
>>11.X External Mail Sender Cross-Domain Forgery
>
>Add this to 11.1 Authentication Methods
On March 17, 2024 8:49:02 PM UTC, Gregor Riepl wrote:
>> Someone has asked us to merge one of your Launchpad
>> accounts with another.
>>
>> If you go ahead, this will merge the account called
>> 'Debian Python Modules Team (debian-python)' into the account
>> 'johnfrandes12'.
>>
>> To
Package: python3-fs
Version: 2.4.16-2
Severity: important
Python3-fs uses python3-appdirs, which is dead upstream. It is being
replaced by python3-platformdirs. As a maintainer of appdirs, I would
prefer that we do not release Trixie with appdirs. As far as I can
tell, python3-fs is the only
On March 17, 2024 11:11:04 AM UTC, Alessandro Vesely wrote:
>On Sat 16/Mar/2024 20:01:22 +0100 Scott Kitterman wrote:
>> On Thursday, March 14, 2024 12:24:50 PM EDT Scott Kitterman wrote:
>>> On Thursday, March 14, 2024 11:44:22 AM EDT Todd Herr wrote:
>>&g
On Wednesday, February 28, 2024 7:37:30 PM EDT Barry Leiba wrote:
> The editors and chairs think version -30 resolves the open issues and is
> ready for a final look, so this message starts a working group last call
> for the DMARCbis spec. Because of the upcoming IETF 119 meeting, we’ll let
>
Not sure if this is "significant" or not.
I don't particularly like the title, but that's been that way for quite some
time, so for WGLC, meh.
The particular concern I have is with the text that was added right before
WGLC about multi-valued RFC5322.From fields. It includes the statement:
>
On Thursday, March 7, 2024 8:55:55 AM EDT Todd Herr wrote:
> On Thu, Mar 7, 2024 at 5:08 AM Alessandro Vesely wrote:
> > On 06/03/2024 21:00, Todd Herr wrote:
> > > Section 4.7, DMARC Policy Discovery, starts with the following sentence:
> > > For policy discovery, a DNS Tree Walk starts at
On Wednesday, March 6, 2024 6:04:01 AM EDT Alessandro Vesely wrote:
> On 05/03/2024 21:47, Scott Kitterman wrote:
> > On March 5, 2024 8:10:46 PM UTC, Todd Herr
wrote:
> >> On Tue, Mar 5, 2024 at 1:30 PM Scott Kitterman
wrote:
> >>> On March 5, 2024 2:4
On Thursday, March 14, 2024 12:24:50 PM EDT Scott Kitterman wrote:
> On Thursday, March 14, 2024 11:44:22 AM EDT Todd Herr wrote:
> > Colleagues,
> >
> > Issue 135 is open for the subject topic. Please add your thoughts to this
> > thread and/or to the issue in
On Saturday, March 16, 2024 4:52:54 AM EDT Tero Kivinen wrote:
> John Levine writes:
> > It appears that Todd Herr said:
> > >I agree that clarifying it can't hurt, obviously, ...
> >
> > I disagree, it does hurt.
> >
> > If we say you're allowed to use CNAMEs to point to DMARC records,
> >
On March 15, 2024 11:11:21 PM UTC, Bo YU wrote:
>Hi!
>
>On Sat, Mar 16, 2024 at 1:18 AM Scott Kitterman wrote:
>>
>> On Friday, March 15, 2024 10:55:34 AM EDT Stefano Rivera wrote:
>> > Hi Scott (2024.03.15_13:31:40_+)
>> >
>> > > I origi
gt; ⣾⠁⢠⠒⠀⣿⡁ eam...@debian.org
> ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: FA9DEC5DE11C63F1
> ⠈⠳⣄
>
>
>On Fri, Mar 15, 2024 at 2:50 PM Scott Kitterman
>wrote:
>
>> This is another one I don't use anymore where I'm the sole uploader.
>>
>> It's got a fair number of rdepends, most notably poetry. Any takers
>> before I
>> orphan it?
>>
>> Scott K
This is another one I don't use anymore where I'm the sole uploader.
It's got a fair number of rdepends, most notably poetry. Any takers before I
orphan it?
Scott K
signature.asc
Description: This is a digitally signed message part.
On Friday, March 15, 2024 10:55:34 AM EDT Stefano Rivera wrote:
> Hi Scott (2024.03.15_13:31:40_+)
>
> > I originally packaged python-resolvelib for pip and python-commentjson so
> > we could run python-resolvelib's tests. Pip is no longer using the
> > packaged version. It's currently used
On March 15, 2024 3:47:25 PM UTC, Thomas Goirand wrote:
>On 3/15/24 13:52, Scott Kitterman wrote:
>>
>>
>> On March 15, 2024 7:19:16 AM UTC, Thomas Goirand wrote:
>>> On 3/14/24 08:52, Andreas Tille wrote:
>>>> I would have prefered to
>>
On Friday, March 15, 2024 10:15:55 AM EDT Todd Herr wrote:
> On Fri, Mar 15, 2024 at 1:47 AM Douglas Foster <
>
> dougfoster.emailstanda...@gmail.com> wrote:
> > DMARC is an imperfect tool, as evidenced by the mailing list problem,
> > among others. DMARCbis has failed to integrate RFC7489 with
I originally packaged python-resolvelib for pip and python-commentjson so we
could run python-resolvelib's tests. Pip is no longer using the packaged
version. It's currently used by pdm and ansible-core.
I am the sole uploader for both these packages and intend to orphan them, but
if someone
On March 15, 2024 7:19:16 AM UTC, Thomas Goirand wrote:
>On 3/13/24 18:34, Scott Kitterman wrote:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064979
>>
>> Would some of you who are pushing so hard to change the policy for Uploaders/
>> Maintainer in the t
On March 15, 2024 3:54:05 AM UTC, Steven Robbins wrote:
>According to the "action needed" section for nifticlib [1], it is:
>
>Marked for autoremoval on 31 March: #1063178
>
>But that bug is fixed for the version in unstable.
>Why does that cause the package to be removed?
>
>[1]
On March 14, 2024 8:38:17 PM UTC, Todd Herr
wrote:
>On Thu, Mar 14, 2024 at 4:34 PM Scott Kitterman
>wrote:
>
>>
>> I think this is correct. I think it's obviously enough correct that I'm
>> surprised anyone was confused.
>>
>> Do we know what
On March 14, 2024 8:18:31 PM UTC, Todd Herr
wrote:
>Colleagues,
>
>There was a discussion among M3AAWG members on March 13 that centered on
>the question of whether DMARC records can be published in DNS as CNAMEs,
>e.g.,
>
>_dmarc.example.com IN CNAME _dmarc.example.org
>
>_dmarc.example.org
On Thursday, March 14, 2024 1:59:58 PM EDT Alessandro Vesely wrote:
> On Thu 14/Mar/2024 18:35:05 +0100 Scott Kitterman wrote:
> > On Thursday, March 14, 2024 11:27:03 AM EDT Alessandro Vesely wrote:
> >> On Thu 14/Mar/2024 15:09:37 +0100 Todd Herr wrote:
> >>> [...]
On Thursday, March 14, 2024 11:27:03 AM EDT Alessandro Vesely wrote:
> On Thu 14/Mar/2024 15:09:37 +0100 Todd Herr wrote:
> > [...]
> >
> > In the ticket, I propose the following replacement text:
> >
> > ==
> > Because DMARC relies on SPF
On Thursday, March 14, 2024 11:44:22 AM EDT Todd Herr wrote:
> Colleagues,
>
> Issue 135 is open for the subject topic. Please add your thoughts to this
> thread and/or to the issue in Github.
>
> Thank you.
I'd suggest we discuss where to say it first. I think the right place is
security
On Thursday, March 14, 2024 10:09:37 AM EDT Todd Herr wrote:
> Colleagues,
>
> After reviewing the "Another point SPF advice" thread and Murray's separate
> post re: SHOULD vs. MUST, I have opened issue 132 on the topic:
>
> The current text of section 5.5.1, Publish and SPF Policy for an
Package: hplip
Version: 3.22.10+dfsg0-2
Severity: important
After removing and then purging hplip, the __pycache__ directories
remain.
# apt purge hplip
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
Package: hplip
Version: 3.22.10+dfsg0-2
Severity: important
After removing and then purging hplip, the __pycache__ directories
remain.
# apt purge hplip
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
On Wednesday, March 13, 2024 1:34:14 PM EDT Scott Kitterman wrote:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064979
>
> Would some of you who are pushing so hard to change the policy for
> Uploaders/ Maintainer in the team please step up and take over this
> package.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064979
Would some of you who are pushing so hard to change the policy for Uploaders/
Maintainer in the team please step up and take over this package. It really
needs updated to the new upstream release (blocking both aioquic and
dnspythong
This is starting to affect a lot of things.
Scott K
signature.asc
Description: This is a digitally signed message part.
On March 12, 2024 11:42:11 PM UTC, John Levine wrote:
>It appears that Scott Kitterman said:
>>Or, as RFC 4408 and RFC 7208 warn against, ESPs don't allow customers to send
>>mail for anything other than their own domains. ESP customers, don't use
>>ESPs that do t
On March 12, 2024 5:37:47 PM UTC, Richard Clayton
wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>In message , Scott
>Kitterman writes
>
>>Or, as RFC 4408 and RFC 7208 warn against, ESPs don't allow customers to send
>>mail for anything other than the
Or, as RFC 4408 and RFC 7208 warn against, ESPs don't allow customers to send
mail for anything other than their own domains. ESP customers, don't use ESPs
that do this.
Scott K
On March 12, 2024 4:05:15 PM UTC, Dotzero wrote:
>Neil, SPF essentially deals with hosts and IP address ranges.
On Thursday, March 7, 2024 12:09:51 PM EDT Wietse Venema via Postfix-users
wrote:
> Postfix stable release 3.9.0 is available. Postfix 3.5 - 3.8 were
> updated earlier this week; after that, Postfix 3.5 will no longer
> be updated.
>
> The main changes are below. See the RELEASE_NOTES file for
On March 10, 2024 3:23:32 PM UTC, "Martin-Éric Racine"
wrote:
>On Sat, 2 Mar 2024 18:40:13 +0100 Chris Hofstaedtler wrote:
>> * Christoph Biedl [240302 17:02]:
>> > Chris Hofstaedtler wrote...
>> >
>> > > please remove deborphan. It is stuck, featurewise, in a very old time
>> > > and does
On Fri, 01 Mar 2024 11:33:37 +0100 Aurelien Jarno wrote:
> Source: postfix
> Version: 3.8.5-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the
past)
> User: debian-gl...@lists.debian.org
> Usertags: libnsl-dev
>
> Dear maintainer,
>
>
1 - 100 of 33628 matches
Mail list logo
