Control: notfound 958708 squid/4.11-4
On Tue, 12 May 2020 13:11:19 +0200 mahashakti89 wrote:
> Package: squid
> Version: 4.11-4
> Followup-For: Bug #958708
>
> Same problem as described above . Squid would'nt start. I got following
> message on upgrade :
>
...
>
> mai 12 13:08:15 ishwara
On Mon, 18 May 2020 18:27:04 -0400 Sergio Durigan Junior wrote:
> On Monday, May 18 2020, I wrote:
>
> > Just a few more details I've been able to gather this afternoon.
> >
> > I'm using a Debian sid VM where I installed sysvinit to replace systemd.
> > I wasn't able to reproduce the problem
Package: squid
Version: 4.11-5
Severity: grave
Since the /run/squid directory now depends on systemd squid.service file
for existence the 'squid' binary cannot be run.
This breaks all non-systemd init systems, multi-tenant installations,
and scripts running the squid binary for control
On 10/02/20 10:45 am, Andreas Beckmann wrote:
> Control: tags -1 - buster + sid bullseye .
>
> On Sun, 9 Feb 2020 17:54:03 +1300 Amos Jeffries wrote:
>> tags 925836 - sid bullseye + buster
>
> What's the point of tagging this bug (squid: ftbfs with GCC-9)
My kernel version is 3.16.0-4-amd64.
That is due to unrelated driver errors the newer kernels have
consistently had on this hardware. I am surely not the only one in this
situation.
I see there was NEWS mention of unspecified impact with the 1.8.1+
versions but did not pay much attention to
Followup experiments isolating the custom sub-chain are showing even
worse behaviour from the new iptables (-nft flavour).
These commands
iptables -N test-foo
iptables -I test-foo 1 -s 127.0.0.1 -j REJECT
Produces this output:
iptables v1.8.2 (nf_tables): RULE_INSERT failed (Invalid
Package: iptables
Version: 1.8.2-2
Severity: grave
The fail2ban attack prevention software scans log files and adds
firewall rules dynamically to iptables/ip6tables to prevent DoS and
login scanning attacks in realtime.
Since upgrading iptables to the 1.8.2 version it has been completely
unable
For the record the specific autoconf macro:
AC_SEARCH_LIBS([__atomic_load_8],[atomic], ...)
Produces this test code:
"
| #ifdef __cplusplus
| extern "C"
| #endif
| char __atomic_load_8 ();
| int
| main ()
| {
| return __atomic_load_8 ();
| ;
| return 0;
| }
"
Which produces this (on all
Accepting this for next upload. BUT,
... is there any info known about why these platforms suddenly need the
-latomic flag to be hard-coded by the packaging?
Squid configure script auto-detects this symbols existence. It has for
some time on both working and non-working buildd's had the same
Package: libltdl-dev
Version: 2.4.6-2.1
Severity: grave
The update of automake to version 1.16 causes FTBFS in software using
libltdl-dev.
The libltdl-dev package installs a libtool/aclocal.m4 file which
contains a macro hard-coding the automake version used to build the
libtool sources.
Any
Source: squid3
thanks
Trying to reassign to 3.x source packages. So BTS does not block v4
squid package uploads on this old RC issue.
Amos
For the record, the intention is not to include the squid3 package in
Buster. Squid-4 packages intended for buster are currently in
experimental awaiting upstream stable release.
Amos
It seems that the systemd/systemctl is removing the
/run/courier/authdaemon/pid file underneath courier.
Removing the line "PIDFile=/run/courier/authdaemon/pid" from the
installed .service file resolves this problem and upgrade works fine.
Amos
Package: courier-authdaemon
Version: 0.68.0-4+b1
Severity: critical
stop
The Courier authdaemon package is failing to configure during install.
Similar issue happened on the -3 package but I managed to get that to
install with manually stopping all courier processes before upgrading.
That
Just an update for the record.
The upstream bug was fixed in code scheduled for 3.5.27. But I'm not
sure if there will be any more uploads for 3.5 series. We have a Squid-4
package underway in the pkg-squid3 repo which should resolve this bug
when it gets uploaded.
Amos
On 26/03/2017 1:34 p.m., Santiago Garcia Mantinan wrote:
>> Maybe it was just that the original code had to be at the
>> upgrade|install-upgrade
>> block of the case?
>>
>> But why is the -d /etc/squid3 checked?
>
IIRC this is for transitions where _both_ squid and squid3 packages are
already
Package: squid
Version: 3.5.23-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
stop
From: Andreas Beckmann
Date: Thu, 23 Mar 2017 04:04:15 +0100
Hi,
the last upload introduced a regression:
Selecting previously unselected package squid.
(Reading database ...
On Thu, 16 Feb 2017 09:25:33 +0100 Andreas Rittershofer wrote:
> Package: squid
> Version: 3.5.23-1
>
> * What led up to the situation?
>
> I tried to install squid via apt-get install squid
>
> The problem is here:
>
>
> Feb 16 08:32:08 dx151 systemd[1]: Starting LSB: Squid HTTP Proxy
> version
Package: postfix-mysql
Version: 3.1.4-1
Severity: grave
I am using postfix with postfix-mysql mappings for mailboxes,
forwarding, and filters. On upgrade from 3.1.3-6 the mailserver appears
to upgrade successfully, but stops sending or receiving mail.
/var/log/mail.err contains only these
Control: found 818747 0.66.4-6
Unfortunately the fix applied is still not working properly. Hard-coding
the action that the script performs as "start" only works for starting
the daemons, not any other init actions.
It can start the daemons now:
# ps aux | grep "courier-auth"
#
Package: courier-authdaemon
Version: 0.66.4-5
Severity: grave
After a recent upgrade to courier-authdaemon the init scripts have
ceased controlling the daemon processes.
Producing the error :
Unknown option '-'
NP: this is after the workaround to bug #818744 has been added to let
the init
Package: courier-authdaemon
Version: 0.66.4-5
Severity: grave
The /etc/init.d/courier-authdaemon script hangs on any use.
It contains the suspicious I/O loop:
if [ -r "$TMPFILES" ]; then
while read type path mode user group; do
if [ "$type" = "d" ]; then
these irrelevant to the Debian security
team. Security issues in the custom additions are *your* problem to
track and fix. I highly recommend building from the Stretch package
instead of patching.
Amos Jeffries
(Squid upstream)
severity 728144 serious
notforwarded 728144
merge 771778 728144
thanks
I think we have enough hints now to say that the original reports
initiating #771778 and #728144 are the same segfault.
I was wrong about the link to upstream bug #2656 for these two crashes,
that was for the third one that
We have the problem that the Squid-2.7 configuration settings which are
always present in 2.7 configs, will not run in squid-3.5. In fact will
cause the 3.5 process to halt with a fatal error. So we have a mandatory
automated edit by during the upgrade.
How does one avoid or suppress the dpkg
tags severity important
On Mon, 14 Sep 2015 11:11:45 +0200 Patrick Cernko wrote:
>
> On a system with systemd, dnsmasq and resolvconf installed, the
> /etc/resolvconf/update-libc.d/squid3 hook prevents dnsmasq from
> starting.
That hints that the dnsmasq startup sequence is being done the wrong
Squid needs the /dev/shm device to be mounted in its normal chmod 777 state.
I believe that is taken care of on regular machinery by the init script
/ system boot dependencies.
If not, then ideas on how to ensure it is mounted properly are welcome.
Amos
--
To UNSUBSCRIBE, email to
Severity: grave
Amos
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
On Tue, 2 Dec 2014 11:47:48 +0100 =?windows-1252?Q?L.P.H._van_Belle?= wrote:
extra info.
This is on debian wheezy, squid recompiled from jesse with icap and i
did rebuild to a deb : squidclamav 6.11
bug 760303, which looks like it.
That bug (and this one) is unrelated to squidclamav. The
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Package: postgresql-9.4
Version: 9.4~rc1-1
Severity: grave
Justification: renders package unusable
This is addendum to bug #764705 and #768009. Opening a new report
since mail replying to update those is rejected 550 Unknown or
archived bug
The
Package: libmysql++-dev
Version: 3.1.0-2+b1
Severity: serious
When installing libmysql++-dev it pulls in several build dependencies.
However a basic test application performing:
#include mysql++/mysql++.h
int main(int charc, char *argv[])
{
my_init();
return 0;
}
will fail to compile
Package: smitools
Version: 0.4.8+dfsg2-6
Priority: serious
The smilint binary is installed as part of the smitools package and
requires libsmi.
But the smitools package does not depend on any package that installs
libsmi.so.2 nor does it install that library itself.
On a system without any
Are the release team willing to accept a squid-3.2.1 stable release
upload 4-6 weeks after Wheezy freeze?
That upload will close this RC bug, a CVE security bug in both squid
and squid3 packages, and a number of regular bugs.
Notice the Ubuntu effort to migrate 2.7 package to 3.1 ahead of
Upstream is working on a clean transition from (squid | squid3) -
squid 3.2 without the need for a removal bump.
At this time it is not completely clear whether a 3.2 package will make
Wheezy before freeze. I'm hopeful though.
Amos
(upstream maintainer)
--
To UNSUBSCRIBE, email to
Just FYI notifying of a potential catch.
To get the earlier broken bundle to install I manually created the
/var/spool/postfix//etc/ssl directory and let the install process
generate certs file etc as needed.
The new fixed bundle now dies in the same spot with the File Exists
message. This
Package: backuppc
Version: 3.2.0-1
Severity: serious
Backuppc 3.2.0 depends on File/Listing.pm which is now in libwww-perl.
This missing dependency renders the backup engine completely unable to
fetch files with the following errors:
Can't locate File/Listing.pm in @INC (@INC contains:
This is a duplicate of Debian bug 597113.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Package: squid3
Version: 3.1.3-1
Sorry Luigi,
this is not quite done. A packaging change adding --enable-ipv6 to the
rules file is also required to prevent a future relapse.
The fix I was able to make upstream just makes --enable-ipv6 behave
properly when specified.
Amos
--
To
upstream bug 2753.
Setting to RC because the behaviour is not sufficient fixed.
Ack, and agreed.
Amos Jeffries
Squid Proxy Project
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
I see Bug No longer marked as fixed in versions squid/2.7.STABLE7-1 and
reopened. above.
Is this correct and 2.7.STABLE7 still showing the vulnerable behaviour?
Terry: If possible I'd like to see some details of the event, for my
interest.
Amos
Squid Team
--
To UNSUBSCRIBE, email to
Am also hitting this issue with a workaround for some.
In my case the system is quite old with crud leftover from ancient
packages (hotplug etc) which were automatically installed and
automatically removed but never manually purged.
(Attempts were made to manually purge during the
Package: ferm
Version: 2.0.2-1
Severity: critical
Justification: breaks unrelated software
Upgrade halts with message:
Reloading Firewall configuration..Died at /usr/sbin/ferm line 1493.
failed!
At which point the firewall scripts from 1.3.4 have failed to load and
the system may be left
42 matches
Mail list logo
