ewalld.service/start
I believe this is the same issue as
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025618, which is
fixed in trixie. Unfortunately it's fixed by adding a Conflicts
relationship with firewalld.
If you remove firewalld, is the cyclic dependency resolved?
noah
Control: block -1 by 1109891
On Fri, Aug 01, 2025 at 05:01:27PM -0400, Noah Meyerhans wrote:
> > > The repository entries for bullseye-backports should be removed from the
> > > sources.list file as the repository no longer exists on the mirrors.
> >
> > For the
On Thu, Jul 31, 2025 at 02:40:42PM -0400, Noah Meyerhans wrote:
> On Fri, Jul 25, 2025 at 09:39:10AM +, Jens Meißner wrote:
> > The repository entries for bullseye-backports should be removed from the
> > sources.list file as the repository no longer exists on the mirror
Source: cloud-init
Version: 20.4.1-2+deb11u1
Severity: important
Cloud-init has the ability to generate apt sources when provisioning a system.
It does this based on a template installed at
/etc/cloud/templates/sources.list.debian.tmpl. The template currently in
bullseye results in an incorrect s
e, but
there's no clear timeline for that at this time.
noah
6.1 version of that package.
I think I'm OK with the risk associated with those issues, and am in
favor of doing the most basic work to enable the 5.10 hyperv-daemons
binary package.
Thanks
noah
nd on cloud-init to generate network configuration, I
recommend installing the dependencies for the desired backend explicitly
in the images, and possibly installing cloud-init configuration to tell
it to use the particular back-end in question.
noah
the cloud team's
arm64 image builds for Hyper-V environments.
Please enable the hyperv-daemons binary package in the linux-6.1 builds for
bullseye-security.
noah
-0400
+++ cloud-init-22.4.2/debian/changelog 2025-07-10 15:07:51.0 -0400
@@ -1,3 +1,11 @@
+cloud-init (22.4.2-1+deb12u3) bookworm; urgency=medium
+
+ * Import upstream fix for CVE-2024-6174 (Closes: #1108403)
+ * salsa-ci: build in bookworm
+ * Backport upstream fix for CVE-2024-1
0 -0400
+++ cloud-init-25.1.4/debian/changelog 2025-07-07 15:13:38.0 -0400
@@ -1,3 +1,11 @@
+cloud-init (25.1.4-1) unstable; urgency=medium
+
+ * New upstream version 25.1.4 (Closes: #1108402, #1108403)
+- Fixes CVE-2024-6174
+- Fixes CVE-2024-11584
+
+ -- Noah Meyerhans M
.
Does anybody disagree with the above?
noah
1. https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2069607/comments/31
2. https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2069607/comments/32
t how
disruptive this change is likely to be?
Still researching this one...
noah
On Sun, Jun 22, 2025 at 11:39:41PM +0200, Guillem Jover wrote:
> > This may be a usage error on my part, but it should probably not be
> > segfaulting either way. While investigating a possible solution to
> > #1108166, I encountered the following segfault in dpkg-trigger:
> >
> > root@satest-tri
t analysis...
>
> and
>
> Jun 21 13:25:50 qaa systemd[1]: spamd.service: State 'stop-sigterm' timed
> out. Killing.
>
> No issues with "systemctl start spamassassin-maintenance.service".
> But the upgrade case may be different.
It seems likely that the sa-comple postinst and spamd postinst are
racing with each other here. I'm really surprised that this hasn't come
up before...
noah
Control: tags -1 - moreinfo
On Sun, Jun 22, 2025 at 01:55:38PM -0400, Noah Meyerhans wrote:
> > > It seems likely that the sa-comple postinst and spamd postinst are
> > > racing with each other here. I'm really surprised that this hasn't come
> > > up befor
Package: dpkg
Version: 1.22.20
Severity: normal
This may be a usage error on my part, but it should probably not be
segfaulting either way. While investigating a possible solution to
#1108166, I encountered the following segfault in dpkg-trigger:
root@satest-trixie:~# dpkg-trigger --by-package=s
On Sun, Jun 22, 2025 at 12:45:31PM -0400, Noah Meyerhans wrote:
> > It seems likely that the sa-comple postinst and spamd postinst are
> > racing with each other here. I'm really surprised that this hasn't come
> > up before...
>
> A dpkg trigger allowing s
> It seems likely that the sa-comple postinst and spamd postinst are
> racing with each other here. I'm really surprised that this hasn't come
> up before...
A dpkg trigger allowing spamd's own postinst to restart the process,
rather than doing it directly from sa-compile's postinst, may resolve
On Sun, Jun 22, 2025 at 10:01:52AM -0400, Noah Meyerhans wrote:
> I also don't see it on upgrade from -3 in trixie, but I do see a couple
> of unexpected things:
>
> Setting up sa-compile (4.0.1-4) ...
> Running sa-compile (may take a long time)
> Warning: The unit file, so
Control: tags -1 + moreinfo
On Sun, Jun 22, 2025 at 01:17:23PM +0200, Vincent Lefevre wrote:
> I got the following error in the logs:
>
> Jun 21 13:25:30 qaa spamd[1978]: replacetags: regexp compilation failed for
> __HOURS_DEADLINE: '(?aa)(?i)(?:^|\\s)(?:(?:(?:[gGk]|[\\xc4]...
>
> with a regex
Control: severity -1 important
> Severity: serious
Serious is not an appropriate severity for this bug.
> Tags: patch
Ack, thanks
Control: severity -1 important
On Thu, Jun 19, 2025 at 02:11:54AM +0530, Pirate Praveen wrote:
> Control: severity -1 serious
Serious is not an appropriate severity for this bug. Please read the
debbugs documentation.
On Wed, Jun 11, 2025 at 10:58:28AM -0400, Noah Meyerhans wrote:
> > 2. When spamassassin does a Validity query and this is blocked,
> >it creates files in the root account.
>
> Yes, this seems like a bug. But I don't think it reflects a bug in the
> default co
uching) the user
> > preferences directory before calling setuid() to process an inbound
> > message, then this seems like a distinct bug that should be reported
> > upstream.
>
> Some user has "spamd child" processes as spamd user. But in Debian,
> they are root. Perhaps this is the issue?
No, those root processes are just pre-spawned workers. They're the ones
expected to setuid() to the recipient when processing mail.
noah
On Wed, Jun 11, 2025 at 04:16:38PM +0200, Vincent Lefevre wrote:
> On 2025-06-11 10:06:03 -0400, Noah Meyerhans wrote:
> > There's a difference between running spamassassin as root versus running
> > spamd as root. Spamd runs as root so that it can setuid to the
> > indi
nctional.
See more at https://svn.apache.org/repos/asf/spamassassin/trunk/spamd/README
In some sites, it may make sense to use the alternate configuration
described there, but that's a more involved setup and not something that
we're going to make the default. Thus my reduction of the severity here.
Running spamassassin itself, which is the part that actually processes
inbound mail, as root would indeed be a bad idea. But that doesn't happen
by default.
noah
ship the fix there, but if there's
a chance to get it in before the initial release, we can.
noah
On Mon, May 05, 2025 at 03:51:24PM +0200, Pierre-Emmanuel Le Roux wrote:
>Thank you for your answer.
>I did not know that dovecot 2.4.1 would be available in trixie so I did
>not tested it. I will try it from unstable.
Have you been able to test the 2.4.1 packages, which are now in tri
not link to it from really anywhere.
noah
Source: amazon-ecr-credential-helper
Version: 0.7.1-2.1
Severity: wishlist
Tags: newcomer
The recently released version 0.10.0 of amazon-ecr-credential-helper adds
support for the dualstack ECR endpoints. It would be good to get this package
updated.
https://github.com/awslabs/amazon-ecr-credent
This is done in sid and trixie with
https://salsa.debian.org/cloud-team/debian-cloud-images/-/commit/9ae531165d4d3a9c9ef829083e91a27248cb15d5
noahm@temp-3ddb:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.12.29-cloud-amd64
root=PARTUUID=90744ed4-8826-4e4f-9347-9942544a209f ro console=tty0
cons
> I have prepared a patch for upstream[1] and applied it to the Debian
> packaging[2] which restored functionality for me.
Thanks for the details and the patch. I'll monitor the upstream PR and
apply the fix once they've merged it. I don't want the package to get
ahead of what's in their repos.
noah
e azure-vm-utils is ultimately the correct
place for this sort of configuration...
noah
On Thu, May 15, 2025 at 12:31:32PM -0400, Noah Meyerhans wrote:
> I thought azure-vm-utils was aready doing this, but apparently it's not. I've
> requested that feature upstream at
> https://github.com/Azure/azure-vm-utils/issues/80. If it gets implemented
> upstream in th
e32c665a1896c282aad400fcdf7
I don't think this rises to the level of justifying an upload targeting
trixie on its own, but if anything else comes up to warrant a -5 during
the freeze then this will be included.
noah
Package: cloud.debian.org
Severity: normal
User: cloud.debian@packages.debian.org
Microsoft would like us to adjust the default NVMe timeout settings on our
bookworm images to improve reliability on Azure.
Azure VMs use NVMe for ephemeral storage, and newer VM sizes use it for their
root volu
ly,
even on i386. While this may have been OK within dovecot, it broke
out-of-tree extensions like dovecot-fts-xapian. I've disabled this
behavior on i386 in 2.4.1+dfsg1-4, just uploaded.
This will require a binNMU of dovecot-fts-xapian on i386. Other
architectures will not need to be rebuilt.
noah
t as part of the plugin interface. What's not yet clear is
whether dovecot has not correctly initialized the datastructure or
whether the plugin is failing to cope with a legitimate state. Also
unclear why this is only happening on i386. Other 32-bit architectures
aren't impacted.
noah
tainer attention on
https://salsa.debian.org/debian/dovecot-fts-xapian/-/merge_requests/3.
I suggested there that I'd NMU it today if I didn't hear otherwise from
the maintainer, so expect the upload soon.
noah
#x27;t inspect that
> itself. For the cases where maintainers prefer not to add the
> relations for test only failures, I can schedule the combination
> manually.
The failure is only in the tests. I'm happy to do an NMU adding the
missing version constraing to gsasl's debian/tests/control if that's
useful.
noah
he gsasl d/tests/control contains an unversioned dependency on dovecot
packages, the 2.3.x packages from trixie get installed, which leads to a
test failure because gsasĺ's tests now expect 2.4. If this is accurate,
then adding a version constraint of (>= 1:2.4~) to the dovecot
dependencies for the tests is the correct solution.
noah
On Sat, Apr 26, 2025 at 12:05:31PM +0200, Paul Gevers wrote:
> Hi Noah,
>
> On 26-04-2025 10:03, Paul Gevers wrote:
> > For the record of this bug, there's a piuparts issue (tagged pending):
> > 1104047.
>
>
> Please also help the reverse dependencies to fi
it be possible to apply this patch to the debian package ?
Is this problem still present in the 2.4.1 packages in unstable?
They're still on track to migrate to trixie in time for the release.
There will be no more uploads of 2.3.x targeting trixie.
noah
rate there. In fact, I
wasn't able to trigger the repro at all in the last few dozen attempts.
noah
active metadata service found
Note in particular this:
Exception(s) [UrlError('HTTPConnectionPool(host=\'fe80::a9fe:a9fe%25enp3s0\',
port=80): Max retries exceeded with url: /openstack (Caused by
NameResolutionError(": Failed to resolve \'fe80::a9fe:a9fe%25enp3s0\' ([Errno -2]
Name or service not known)"))')
There shouldn't be any name resolution involved here at all. My guess
is that something is not recognizing the scoped link-local address as an
IP address, and is treating it as a hostname that needs to be resolved
in DNS. Which is obviously going to fail. I haven't looked deeply
enough to determine whether this is cloud-init or a lower-level http
client.
noah
On Thu, May 01, 2025 at 05:04:33PM -0400, Noah Meyerhans wrote:
> For dovecot in trixie, I'm considering reverting channel binding support
> altogether. That'll force us to drop SCRAM-SHA-1-PLUS and
> SCRAM-SHA-256-PLUS support, but I'd rather do that than ship dovecot 2
g support
altogether. That'll force us to drop SCRAM-SHA-1-PLUS and
SCRAM-SHA-256-PLUS support, but I'd rather do that than ship dovecot 2.3
again, which is the most likely alternative. (This assumes that I don't
find a proper fix for the regression.)
noah
Control: tags -1 + patch
On Thu, May 01, 2025 at 03:56:11PM -0400, Noah Meyerhans wrote:
> So for gsasl (and libgssglue) expect a merge request soon to update
> their autopkgtests to the dovecot 2.4 configuration language.
And that is now https://salsa.debian.org/xmpp-team/gsasl/-/merge_re
Package: dovecot-gssapi
Version: 1:2.4.1+dfsg1-2
Severity: grave
Tags: upstream
Justification: Breaks other package's autopkgtests
Issue was first observed in gsasl's autopkgtest failures. Protocol traces are
available in #1104411.
Some (but not all) IMAP clients are unable to negotiate GSSAPI a
gsasl (and libgssglue) expect a merge request soon to update
their autopkgtests to the dovecot 2.4 configuration language.
noah
/images/cloud/trixie/daily/) I'd love to hear
how it works.
noah
H 1" line contains an additional field on the
successful log "resp="
2. The successful login logs "Debug: gssapi: security context state
completed." fairly early in the output, but there seems to be some
additional protocol activity at the same point in the unsuccessful
session, and it never indicates "security context state completed".
noah
doesn't mean much.
I'll work on setting up a krb5 environment and will let you know how
things go...
noah
om either gsasl's or
dovecot's output what's going wrong, and I'm hoping you're able to provide
some insight.
Once the test suite is fixed, I'm happy to NMU the fixes if that's useful to
you, or I can leave it for you.
Thanks
noah
1.
https://salsa.debian.org/noahm/gs
e most appropriate?
RC with 'sid' tag seems like it could be appropriate, but maybe not
necessary?
Thanks
noah
Package: dovecot-ldap
Version: 1:2.4.1+dfsg1-1
Severity: grave
Tags: pending
Justification: renders package unusable
dovecot-ldap fails to configure with:
Setting up dovecot-ldap (1:2.4.1+dfsg1-1) ...
Error: The new file /usr/share/dovecot/dovecot-ldap.conf.ext does not exist!
dpkg: error p
Control: severity -1 serious
With dovecot 2.4.1 now in unstable, this is release critical. Adjusting
severity accordingly.
Source: dovecot-antispam
Version: 2.0+20171229-1
Severity: important
Tags: ftbfs upstream
dovecot-antispam does not currently build against dovecot 2.4 (currently in
experimental). Logs from an attempted build are included below.
The upstream status of this project is unclear, given that the las
vides from
> dovecot-core IIUC) makes me want to defer to Release Team member colleagues
> who handle much more transitions than I do.
I did notify the maintainer privately, before realizing that they seem
MIA, but didn't follow up with a bug report. I've now opened #1104033
for better visibility.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1104033
noah
On Fri, Apr 11, 2025 at 04:07:28PM +0200, Bastian Blank wrote:
> The Ec2 and Azure datasources generate netplan config with "set-name".
> Ec2 uses the same name that udev already set, Azure generates a new
> "ethX". This instructs netplan to forcibly change the name, even if
> there is a link unit
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: google-guest-ag...@packages.debian.org, Andrew Jorgensen
, Leandro (Leo) Dorileo
Control: affects -1 + src:google-guest-agent
Please unblock package google-guest-agent
[ Rea
found for
> prompt_toolkit
It does appear that python3-prompt-toolkit 3.0.51-1 introduces this
regression, so I'm reassigning the bug there. The version in trixie is
3.0.50-1 and awscli works as expected there. Updating to 3.0.51-1 with
no other changes introduces the regression.
Autopkgtest has also identified the problem, as visible at
https://ci.debian.net/packages/a/awscli/testing/amd64/60175397/
noah
an reproduce this on sid, but not on trixie. Since they both have
the same version of awscli, I suspect a regression in one of the
dependencies. Not exactly clear which yet, though.
python3-prompt-toolkit has a newer version in sid, so that's a
possibility...
noah
Control: tags -1 + pending
Fix in
https://salsa.debian.org/noahm/waagent/-/commit/93d300d8b40b1c3db1c4b4e00caff57848add732
Control: tags -1 + pending
Fix is pending review in
https://salsa.debian.org/cloud-team/google-guest-agent/-/merge_requests/2
Fix is in
https://salsa.debian.org/noahm/dovecot/-/commit/e30a611fc3b58d7ed18e53d69b2ebf0b69d28b06
noah
On Wed, Apr 16, 2025 at 01:11:34PM -0400, Noah Meyerhans wrote:
> > Do you have any upstream statement how they will handle the 2.3.y
> > series after their 2.4 release? Do they plan to still backport CVE
> > fixes for the 2.3 series or is it considered officially end of life?
rimental. I've been running them for some time now and find them to
be stable (more so than 2.4.0), but more testing in different
environments would be very helpful.
noah
s, bugs from users?
>
> Sorry that are not very specific questions.
I haven't seen a public statement on 2.3.x support, but upstream has
noted on their mailing lists that it's "on life support". I've reached
out for clarification...
noah
t get ahead of ourselves. I think Stefano was simply
pointing out something that had happned in the past, not any new DAM
involvement.
Keeping systemd-resolved in place is vastly preferable to any
cloud-specific workaround. We used to have such a thing, before moving
to systemd-networkd/resolved, and are not excited about the prospect of
going back thered.
noah
@bsd.network/114242208525201480
> https://fosstodon.org/@paradegrotes...@mastodon.sdf.org/114242559527495102
>
> So, just one simple question: why the should I even bother
> anymore?
Please try to ignore them; they're not contributing anything of value to
the conversation. I assert that they also represent a tiny minority.
Within the cloud team, I certainly can't recall any users complaining
about our choice to enable systemd-resolved, and there are a lot of
them.
noah
networkd altogether, should it come to that, but I'd hope we
don't get to that point.
noah
On Tue, Apr 01, 2025 at 09:35:02PM +, Luca Boccassi wrote:
> > > > Please let's not get ahead of ourselves. I think Stefano was simply
> > > > pointing out something that had happned in the past, not any new DAM
> > > > involvement.
> > >
> > > Sorry I should have been clearer: when I said war
ie
is the worst possible outcome of this discussion so far.
noah
gt; DAM's involvement is not the result of any discussion on any MR.
Is the TC opposed to Luca's earlier proposal to add back
systemd-resolved with a Conflicts relationship on avahi-daemon?
noah
Control: tags -1 + security
Control: fixed -1 2:7.2-1
Note that this has been assigned CVE-2025-2312
o late to change any minds there. I don't know
what to suggest to the TC at this point, but the current situation risks
leaving a fairly large subset of our users without a clear path forward.
I don't agree with Luca's decision to drop systemd-resolved altogether
in response to the TC's decision, but I do recognize that he's the one
who's going to be on the receiving end of the hate mail from user's when
their DNS breaks when upgrading from bookworm, so I'm somewhat
sympathetic to his position.
noah
st manages the contents of /etc/resolv.conf
and is not directly involved in the name resolution process at all.
That's how we use it in the bookworm cloud images, and it has proven
reliable.
So I don't consider our usage of systemd-resolved to be a mistake any
more than I consider our usage of systemd-networkd to be one. Removing
it would not benefit our users in any way.
noah
xperimental where various bugs
were identified and squashed.
The complete debdiff is at
https://people.debian.org/~noahm/dovecot_2.4.1+dfsg1-1~exp1.debdiff
The debian/changelog diff between testing and experimental is attached.
Thanks
noah
1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100
On Mon, Mar 17, 2025 at 10:27:46AM -0400, Noah Meyerhans wrote:
> 2. Dovecot 2.4 does not build on 32-bit architectures. My intent was to
> drop i386 anyway, but I did put out a call for help on debian-arm@lists.d.o
> in case anybody wants to fix the issues as they impact 3
The match makes sense to me, but I'd prefer if it gets merged upstream
first. Is there any chance you could submit it there using their
bugzilla system? https://bz.apache.org/SpamAssassin/
Thanks
noah
Package: wnpp
Severity: wishlist
Owner: Noah Meyerhans
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-cl...@lists.debian.org
* Package name: azure-proxy-agent
Version : 1.0.25
* URL : https://github.com/Azure/GuestProxyAgent
* License : MIT
Programming
elease, getting into trixie would
also be ideal. I'd consider that a second transition for this package, as
we're currently working with 2.4.0, but I do want to mention it.
Thanks
noah
Ben file:
title = "dovecot";
is_affected = .depends ~ "dovecot-dev" | .depends ~
Package: cloud.debian.org
Severity: important
This has so far only been observed on Azure. It's not clear whether it's
impacted other cloud environments or not.
Cloud-init is not consistently being enabled during VM provisioning on
Microsoft Azure. The external symptom is that the launch times
short circuits the error handling and kills
> off all other generators.
Yep, that's basically the path I was on, too. That explains the
intermittent nature of the failures, too, since it's possible for the
ABRT to happen after some generators have already completed
successfully.
I wonder what's going on with netplan-generator...
noah
On Thu, Mar 13, 2025 at 06:21:13PM +0100, Bastian Blank wrote:
> "systemd.log_level=debug systemd.log_target=console" on the kernel
> command line gives some more insight. But this is a lot of output, so
> requires serial console output.
Yep. One of my earlier updates contains the full debug outp
s, which we can discuss further once it's packaged.
noah
I can confirm that systemd is sending a TERM to (at least) the
cloud-init-generator process. However, I'm not yet sure why:
* The cloud-init-generator process typically runs in approximately 30ms,
and is sometimes killed.
* I've been able to insert an artificial 2s pause in the middle of the
d execution of restart.
> | Errors were encountered while processing:
> | dovecot-core_1%3a2.4.0+dfsg1-1~exp2_amd64.deb
>
> I suspect dovecot-core needs Breaks+Replaces for dovecot-sieve.
Hm. I suspect the migration of the file to dovecot-core was a mistake.
noah
Control: tags -1 + moreinfo
On Mon, Mar 10, 2025 at 12:46:41PM +0100, Santiago Vila wrote:
> In my tests, this fails 100% of the time on
> single-CPU systems and 40% of the time on systems
> with 2 CPUs. I think that's bad enough.
I have not been able to reproduce this, even with single-CPU build
n behavior.
noah
://lists.samba.org/archive/samba-technical/2025-February/139330.html
Thanks!
noah
-- System Information:
Debian Release: 12.9
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
age if that would help.
> >
> > Thanks I will shortly have a look at that as I'm rebasing 6.1.y for
> > bookworm for the next upload.
>
> Investigating this further I believe we have the same problem as well
> for CVE-2024-42069.
Yes, that seems likely.
noah
top of our patched 6.1 kernel with an
offset. [3]
I didn't propose a fix to the security-tracker data because I don't know
the file format well enough.
I can prepare a merge request to the kernel package if that would help.
Thanks
noah
1. https://security-tracker.debian.org/tracker/CVE-
ange to the upstream project at
https://github.com/aya-rs/aya? Maintaining this set of
architecture-specific bindings over the long term is impactical.
noah
10.y. Can
> > > you re-ping upstream to make sure it get included in the 5.10.y
> > > series? Once this has happened as we follow the 5.10.y series it will
> > > be included (or can be included in advance once it has been queued).
> >
> > Yes, I forgot to reset the
forgot to reset the date on the commit that I sent upstream,
which is why it looks like it's been around since 2021. I requested
that upstream apply the fix to 5.10.y last week, and will ping them in
another week or two if it hasn't been acknowledged either way...
noah
races in nvme_setup_io_queues"), so this only impacts
oldstable. I have provided a backport of this commit upstream in
https://lore.kernel.org/stable/E1tj8vO-00471h-2H@lore/
I'm requesting that this commit be included in a bullseye kernel update.
Thanks
noah
SCSI subsystem initialized
[1.1
On Sun, Feb 16, 2025 at 02:06:31PM +0100, Felix Zielcke wrote:
> > I've just uploaded dovecot 1:2.4.0+dfsg1-1~exp1 to experimental.
> Please
> > test to the extent that you're able.
> >
> [...]
> > noah
> >
>
> thanks for doing the 2.4 uplo
issues on (at least) i386, which
look on first glance like they're related to the 64 bit time_t change.
I'm not sure it's worth fixing those, but am happy to hear other
opinions and/or review patches.
noah
1 - 100 of 1124 matches
Mail list logo
