Bug#1035940: unblock: squid/5.7-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: sq...@packages.debian.org
Control: affects -1 + src:squid
Please unblock package squid
squid on testing has several bugs which were fixed on version 5.8
of upstream, however 5.8 would not be allowed on bookworm when it
was released, so upstream for squid has sugested us to ship two
patches on top of 5.7, the suggested patches are the only changes
done to the package and can be seen here:
https://salsa.debian.org/squid-team/squid/-/commit/7ffc938c1456033ce4772bec067c6c90584bc348
https://salsa.debian.org/squid-team/squid/-/commit/cdd9134b05ac6587b4391a407061a426d283b840
[ Reason ]
The new package version solves a couple of nasty bugs.
[ Impact ]
Bugs introduced by the version now in testing and not present on stable
[ Tests ]
piuparts and autopkgtest passed, the code has also been tested on production
machines.
[ Risks ]
None identified, patches are from upstream, really small, apply cleanly and
work Ok.
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
[ Other info ]
unblock squid/5.7-2
diff -Nru squid-5.7/debian/changelog squid-5.7/debian/changelog
--- squid-5.7/debian/changelog 2022-10-04 11:04:20.0 +0200
+++ squid-5.7/debian/changelog 2023-04-28 08:35:27.0 +0200
@@ -1,3 +1,10 @@
+squid (5.7-2) unstable; urgency=medium
+
+ * Add a couple of upstream picked patches to fix some issues on 5.7
+that upstream has fixed on 5.8.
+
+ -- Santiago Garcia Mantinan Fri, 28 Apr 2023 08:35:27
+0200
+
squid (5.7-1) unstable; urgency=medium
* Urgency high due to security fixes
diff -Nru
squid-5.7/debian/patches/1f13f721263a4cc75e4b798a230022561047899c.patch
squid-5.7/debian/patches/1f13f721263a4cc75e4b798a230022561047899c.patch
--- squid-5.7/debian/patches/1f13f721263a4cc75e4b798a230022561047899c.patch
1970-01-01 01:00:00.0 +0100
+++ squid-5.7/debian/patches/1f13f721263a4cc75e4b798a230022561047899c.patch
2023-04-28 08:35:27.0 +0200
@@ -0,0 +1,42 @@
+From 1f13f721263a4cc75e4b798a230022561047899c Mon Sep 17 00:00:00 2001
+From: Eduard Bagdasaryan
+Date: Thu, 1 Dec 2022 18:50:37 +
+Subject: [PATCH] Bug 5162: mgr:index URL do not produce MGR_INDEX template
+ (#1191)
+
+Satisfy mgr:index requests using
+
+* a 200 OK response with a body derived from the MGR_INDEX template (if
+ that template file was found during (re)configuration) or
+* a 404 (Not Found) error response (otherwise).
+
+Broken in 2019 commit 7e6eabb, when Squid started replying using a 200
+OK response with a hard-coded "mgr_index" text as a body, ignoring any
+configured MGR_INDEX template.
+---
+ src/errorpage.cc | 5 +
+ 1 file changed, 1 insertion(+), 4 deletions(-)
+
+diff --git a/src/errorpage.cc b/src/errorpage.cc
+index 6fbedbe1dba..f74e6e554e2 100644
+--- a/src/errorpage.cc
b/src/errorpage.cc
+@@ -154,6 +154,7 @@ static const struct {
+ const char *text;
+ }
+
++/// error messages that cannot be configured/customized externally
+ error_hard_text[] = {
+
+ {
+@@ -180,10 +181,6 @@ error_hard_text[] = {
+ {
+ ERR_REQUEST_START_TIMEOUT,
+ "request start timedout"
+-},
+-{
+-MGR_INDEX,
+-"mgr_index"
+ }
+ };
+
diff -Nru
squid-5.7/debian/patches/edad3f150de8af0aeb2f629508be3219b83369b9.patch
squid-5.7/debian/patches/edad3f150de8af0aeb2f629508be3219b83369b9.patch
--- squid-5.7/debian/patches/edad3f150de8af0aeb2f629508be3219b83369b9.patch
1970-01-01 01:00:00.0 +0100
+++ squid-5.7/debian/patches/edad3f150de8af0aeb2f629508be3219b83369b9.patch
2023-04-28 08:35:27.0 +0200
@@ -0,0 +1,31 @@
+From edad3f150de8af0aeb2f629508be3219b83369b9 Mon Sep 17 00:00:00 2001
+From: Alexander Bokovoy
+Date: Sat, 10 Dec 2022 11:50:27 +
+Subject: [PATCH] ext_kerberos_ldap_group_acl: Support -b with -D (#1207)
+
+When both '-b' (i.e. bind DN) and '-D' (i.e. Kerberos domain) options
+are specified, '-b' is ignored completely. This breaks the helper when a
+search subtree has to be limited (e.g., when using FreeIPA).
+
+Fix it to take '-b' into account if it was specified with '-D'.
+---
+ src/acl/external/kerberos_ldap_group/support_ldap.cc | 6 +-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/src/acl/external/kerberos_ldap_group/support_ldap.cc
b/src/acl/external/kerberos_ldap_group/support_ldap.cc
+index 3608148a388..c713215a85c 100644
+--- a/src/acl/external/kerberos_ldap_group/support_ldap.cc
b/src/acl/external/kerberos_ldap_group/support_ldap.cc
+@@ -1114,7 +1114,11 @@ get_memberof(struct main_args *margs, char *user, char
*domain, char *group)
+ "%s| %s: DEBUG: Error during initialisation of ldap
connection: %s\n",
+ LogTime(), PROGRAM, strer
Bug#985390: Uploaded -9 to try to fix the concerns
Hi! I have just uploaded -9 which tries to fix the things that we've talked that you didn't like. I'm attaching the debdiff. Hope this helps getting -9 on Bullseye. Regards. -- Manty/BestiaTester -> http://manty.net diff -Nru squid-4.13/debian/changelog squid-4.13/debian/changelog --- squid-4.13/debian/changelog 2021-03-21 00:58:29.0 +0100 +++ squid-4.13/debian/changelog 2021-03-23 00:18:11.0 +0100 @@ -1,3 +1,11 @@ +squid (4.13-9) unstable; urgency=medium + + * Clarify on NEWS and scripts that we no longer remove logs on purge. + * Clarify on postrm script that the debhelper code was put manually. + * Add README.Debian to squid-openssl. + + -- Santiago Garcia Mantinan Tue, 23 Mar 2021 00:18:11 +0100 + squid (4.13-8) unstable; urgency=medium * Add SQUID-2020_11.patch to fix HTTP Request Smuggling. diff -Nru squid-4.13/debian/NEWS squid-4.13/debian/NEWS --- squid-4.13/debian/NEWS 2021-03-08 22:32:47.0 +0100 +++ squid-4.13/debian/NEWS 2021-03-23 00:18:11.0 +0100 @@ -1,3 +1,13 @@ +squid (4.13-9) unstable; urgency=medium + + Current package flavours: squid (GnuTLS) and squid-openssl share config, + logs and cache. Since 4.13-6 none of them removes the logs on purge, so + that you can purge one flavour when switching to the other without loosing + the logs. If you don't need them anymore and want them removed you'll + have to do it yourself. + + -- Santiago Garcia Mantinan Tue, 23 Mar 2021 00:07:36 +0100 + squid (4.13-6) unstable; urgency=medium If you want to transition from squid to squid-openssl or vice versa you diff -Nru squid-4.13/debian/README.Debian squid-4.13/debian/README.Debian --- squid-4.13/debian/README.Debian 2021-03-08 22:32:47.0 +0100 +++ squid-4.13/debian/README.Debian 2021-03-23 00:18:11.0 +0100 @@ -1,18 +1,43 @@ -This is the next-generation Squid. In version 3.x squid has been ported to C++ -for code manageability. Since squid 2.x is not developed anymore except for bug -fixing, this package is where new features will be added. - -Squid 3.5 supports IPv6, WCCPv2, ICAP, Edge Side Include, SSL offloading, etc. Please -note that not all of the new feature have been enabled in Debian package. - -Squid 3.5 is configured by the /etc/squid/squid.conf file. Syntax of that -file is the same of previous versions of squid and each directive is largely -commented there. Configuration files from 2.x versions of squid will mostly -work in squid 3.5. Changes to the configuration file are reported in +This is the next-generation Squid. In version 3.x squid has been ported to +C++ for code manageability. + +Squid supports IPv6, WCCPv2, ICAP, Edge Side Include, SSL offloading, etc. + +Squid in Debian now comes in two flavours, the GnuTLS flavour, which is the +one that has been tratitionally supplied by Debian's squid package and a new +OpenSSL flavour which is provided by the squid-openssl package. + +Each flavour has its features, that's why we provide the two. The +traditional one is better at handling multiple certificates, while the +openssl flavour comes with SSL-Bump which allows full proxy transparency. + +Both flavours have their own specific options to be setup at config files, +but they share the same config files, both /etc/squid/squid.conf file, as +well as the new /etc/squid/conf.d/ directory. Syntax of those files is the +same of previous versions of squid and each directive is largely commented +there. Configuration files from 2.x versions of squid will mostly work in +later versions of squid. Changes to the configuration files are reported in /usr/share/doc/squid-common/RELEASENOTES.html +Both flavours of squid share not only the config files but also the log +files and the cache. When purging squid, the package didn't remove the +cache files, typically at /var/spool/squid, and now, since version 4.13-6, +it also doesn't remove the logs at /var/log/squid, this means that if you +want to migrate to squid-openssl and, afterwards, purge squid, you must make +sure you have at least version 4.13-6 of squid installed, this way you won't +loose the logs when you purge squid. So, if you have version 4.13-6 or +later of the squid packages, you can switch flavours and try each flavour's +own features without any problem, but first make sure you have at least +version 4.13-6 of the squid packages, otherwise you'll probably loose the +config file and the logs. + +This also means that if you want to fully purge all squid stuff from your +system, you must remove by yourself /var/spool/squid (to save time you can +use mkfs if you have them on a separate filesystem) and /var/log/squid if +you are completely sure that you don't need those files anymore. + The squid homepage is at http://www.squid-cache.org/ Squid was downloaded from that site with HTTP. - -- Luigi Gangitano , Wed 22 Jul 2015 15:57:00 +0200 + -- The Debian Squid Maintainers , Tue, 23 Mar 2021 11:28:15 +0100 diff -Nru squid-4.13/deb
Bug#985390: unblock: squid/4.13-7
I'm Ccing my fellows at the squid team in case they want to add something here, for the full conversation, please see #985390. I have finished testing the changes for -9, I don't know if I like it more now or if it would be better to just leave the comment on the NEWS file and don't echo anything on the console when we purge. This is what it does now when we purge squid if we have squid-openssl installed: (A ler a base de datos ... 603757 files and directories currently installed.) Purging configuration files for squid (4.13-9) ... Log and cache files are not automatically removed. These files are used by squid and squid-openssl flavours. Remove logs (/var/log/squid) and cache (/var/spool/squid) yourself if you no longer need them. As you can see there is a lot of text but the user doesn't really need to see any of this as he has squid-ssl installed, so I could try to only echo if we don't have the other flavour installed, but... When we purge all of squid, in this case I'm purging squid-common and squid-openssl, no piece of squid remains installed... (A ler a base de datos ... 603757 files and directories currently installed.) Removing squid-openssl (4.13-9) ... Purging configuration files for squid-openssl (4.13-9) ... Log and cache files are not automatically removed. These files are used by squid and squid-openssl flavours. Remove logs (/var/log/squid) and cache (/var/spool/squid) yourself if you no longer need them. dpkg: warning: while removing squid-openssl, directory '/var/spool/squid' not em dpkg: warning: while removing squid-openssl, directory '/var/log/squid' not empt Removing squid-common (4.13-9) ... Processing triggers for man-db (2.9.4-2) ... As you can see, we get the text I wrote for -9 and also the dpkg warning. So... I'm thinking, what if we don't echo anything and let dpkg do its work, and leave the note I just added to NEWS and maybe add a README.Debian file explaining the flavours, how they share the cache, the logs and the config file and that we are not cleaning logs and cache, and even sugesting that to clean the cache a mkfs can be faster (like the comment on the postrm says)? What do you think, maybe that way is even cleaner for the user. Regards... -- Manty/BestiaTester -> http://manty.net
Bug#985390: unblock: squid/4.13-7
Hi again! I have just pushed: https://salsa.debian.org/squid-team/squid/-/commit/fe8a10ef8ec40411bb59bec7af2b179796d4f4ef I think I'm addressing all your concerns there, if you like it I'll run tests tomorrow and upload the -9 package. Thanks in advance. -- Manty/BestiaTester -> http://manty.net
Bug#985390: unblock: squid/4.13-7
> > Fixing a couple of nasty bugs discovered late, > Yes, due to handling of a new binary package that you had migrated into > bullseye the day before that wasn't allowed anymore exactly to avoid > this class of bugs. Agreed, this was something that several users had asked for and that we, the screen team, agreed on making, but nobody had the time till I was able to do it, yes, it was late on the cycle, but I think we can get it right before releasing. > > Loss of config and logs and service deactivated when switching squid flavour > > and purging the old one. > And now you don't purge the configuration and logs at all. Policy isn't > totally clear on this (the text is lightly ambiguous), but *I* expect > purging to remove my configuration and logs, what else is the delta > between removal and purging? However, I'm wondering if I want you to fix The package has traditionally left, the cache (something that is probably not usefull at all) without being removed from the disk just because it would take a lot of time to remove it (reading the comments on postrm script) # We do not remove /var/spool/squid because that might # take a lot of time. Most of the time it is on a seperate # disk anyway and it is faster to do a mkfs on it.. I thought that leaving the logs which can be even legally needed, wouldn't hurt, in my case when I found this it was a problem as I lost all the logs I had on the system (luckily I had a backup). > that at this moment at the risk of not getting it right. However, I You are right. > think you're current message is confusing though and needs improvement: > 1) it doesn't mention the configuration file(s) The configuration file (which was forcebly removed by postrm before) is removed by dpkg if squid and squid-openssl are both purged, so as far as config goes, it still does what you would spect. > 2) it doesn't mention that the log is shared with that other > (potentially installed) package. There's context missing here for > sysadmins of why you're not doing it in the package. What happens if > somebody just did exactly as told and deleted the log directory? Agreed, I can try to get a better message on a -9 version of it. > -#DEBHELPER# > +# Automatically added by dh_installinit/13.3.4 > ^ > > Highly confusing, don't you think, for something that's not at all > automatically added. Sure, I didn't remove this to minimize the changes between the binary packages, and given that this was a temporary fix, I thougt it would be better to leave it like that, but I'll remove it on -9. Regards... -- Manty/BestiaTester -> http://manty.net
Bug#985390: Make this request valid for 4.13-8
Hi! While we were waiting for 4.13-7 to age and enter testing, we were filled a security bug for CVE-2020-25097. I decided to fix that security problem ASAP and that is what is on 4.13-8, just that. 4.13-8 just adds the patch to fix the CVE as available at: http://www.squid-cache.org/Versions/v4/changesets/SQUID-2020_11.patch You can see more info on all this on the bug that was assigned, #985068. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#985390: Clarifying changes on resulting binary packages
Hi! Just to clarify a bit, as the changes on the sources may seem big, these are the differences on resulting scripts (the only that was changed besides changelogs and a note on NEWS). >From -5 to -6: diff -ru 5/control/postrm 6/control/postrm --- 5/control/postrm2021-02-08 21:35:48.0 +0100 +++ 6/control/postrm2021-03-04 14:45:00.0 +0100 @@ -6,20 +6,12 @@ remove) ;; purge) - echo "Purging logfiles..." - rm -rf /var/log/squid - - if [ -f /etc/squid/squid.conf ]; then - echo "Removing the config-file .." - rm -f /etc/squid/squid.conf - fi - # # We do not remove /var/spool/squid because that might # take a lot of time. Most of the time it is on a seperate # disk anyway and it is faster to do a mkfs on it.. # - echo "Please, remove /var/spool/squid yourself." + echo "Please, remove logs (/var/log/squid) and cache (/var/spool/squid) yourself." ;; failed-upgrade|abort-upgrade|upgrade|abort-install|disappear) ;; And these are those from -6 to -7: diff -ru 6/control/postrm 7/control/postrm --- 6/control/postrm2021-03-04 14:45:00.0 +0100 +++ 7/control/postrm2021-03-10 09:19:32.0 +0100 @@ -21,7 +21,7 @@ # generated by other debhelper scripts. # Automatically added by dh_installinit/13.3.4 -if [ "$1" = "purge" ] ; then +if [ "$1" = "purge" ] && ! [ -e /etc/init.d/squid ]; then update-rc.d squid remove >/dev/null fi # End automatically added section @@ -42,7 +42,7 @@ fi fi -if [ "$1" = "purge" ]; then +if [ "$1" = "purge" ] && ! [ -e /lib/systemd/system/squid.service ]; then if [ -x "/usr/bin/deb-systemd-helper" ]; then deb-systemd-helper purge 'squid.service' >/dev/null || true deb-systemd-helper unmask 'squid.service' >/dev/null || true Hope that clarifies a bit. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#985390: unblock: squid/4.13-7
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package squid Current version on tesing has two bugs (#984510 and #984880) they both happen when purging squid after transitioning to squid-openssl or vice versa. The first one means loosing the config file and logs (which in the case of squid can even be proves for crimes), and the second one means the service is deactivated. The version in sid, uploaded before hard freeze and with autopkgtests has just the changes made to fix these two bugs. The first bug was addressed on -6 and all we did was not to remove logs and config files on postrm script. The second one is caused by #984897 on debhelper, but debhelper won't be updated this late on release cycle, so the fix I've implemented is not what I'd like, I've added modified debhelper scripts to postrm. [ Reason ] Fixing a couple of nasty bugs discovered late, so that we got hit by hard freeze and given that squid is a key package, it won't transition automatically despite the autopkgtests. [ Impact ] Loss of config and logs and service deactivated when switching squid flavour and purging the old one. [ Tests ] The changes are a removal of a couple of rm commands (added on -6 version) and a condition added to two "if" commands on debhelper's scripts so that if the service still exists it won't get deactivated. The tests were carried to see that they work as expected when transitioning from one flavour to the other and then purging the original one. [ Risks ] No risks at all with changes applied to -6 as removal of code and what is affected is trivial, changes done on -7 should be just a build depends on a newer version of debhelper that would fix #984897 but as that won't happen on Bullseye, I applied the results of fixing this debhelper bug directly on the code produced by debhelper instead of writing some new code, I know this is ugly but it was the option that seemed to pose less risks. [ Checklist ] [X] all changes are documented in the d/changelog [X] I reviewed all changes and I approve them [X] attach debdiff against the package in testing [ Other info ] All changes are on https://salsa.debian.org/squid-team/squid unblock squid/4.13-7 diff -Nru squid-4.13/debian/changelog squid-4.13/debian/changelog --- squid-4.13/debian/changelog 2021-02-08 21:35:48.0 +0100 +++ squid-4.13/debian/changelog 2021-03-10 09:19:32.0 +0100 @@ -1,3 +1,18 @@ +squid (4.13-7) unstable; urgency=medium + + * Add full postrm scripts while we don't solve #984897 on debhelper. +Closes: #984880. + + -- Santiago Garcia Mantinan Wed, 10 Mar 2021 09:19:32 +0100 + +squid (4.13-6) unstable; urgency=medium + + * Stop removing cache and config file on postrm. Closes: #984510. + * Increase debhelper build dependency to 12.8 as we need that from -5. + * Add NEWS note on the problem with purge on previous versions. + + -- Santiago Garcia Mantinan Thu, 04 Mar 2021 14:45:00 +0100 + squid (4.13-5) unstable; urgency=high * Have a deeper look and change all dpkg-buildpackage commands diff -Nru squid-4.13/debian/control squid-4.13/debian/control --- squid-4.13/debian/control 2021-02-07 21:58:30.0 +0100 +++ squid-4.13/debian/control 2021-03-08 22:32:47.0 +0100 @@ -11,7 +11,7 @@ # The compiler dependencies are relevant for backporting. , g++ (>= 4.9) | clang (>= 3.7) , gcc (>= 4.9) | clang (>= 3.7) - , debhelper (>=12), dpkg-dev (>= 1.17.11~), lsb-release + , debhelper (>=12.8), dpkg-dev (>= 1.17.11~), lsb-release , dh-apparmor , libcppunit-dev , libcap2-dev [linux-any] diff -Nru squid-4.13/debian/NEWS squid-4.13/debian/NEWS --- squid-4.13/debian/NEWS 2021-02-07 01:39:45.0 +0100 +++ squid-4.13/debian/NEWS 2021-03-08 22:32:47.0 +0100 @@ -1,3 +1,12 @@ +squid (4.13-6) unstable; urgency=medium + + If you want to transition from squid to squid-openssl or vice versa you + should first make sure you have at least version 4.13-6 of the packages + installed or don't purge your packages, as older packages will remove + logs and config file on purge. + + -- Santiago Garcia Mantinan Thu, 04 Mar 2021 15:36:44 +0100 + squid (4.13-2) unstable; urgency=high Starting from this release we ship the old squid package compiled against diff -Nru squid-4.13/debian/squid-openssl.postrm squid-4.13/debian/squid-openssl.postrm --- squid-4.13/debian/squid-openssl.postrm 2021-02-05 14:38:22.0 +0100 +++ squid-4.13/debian/squid-openssl.postrm 2021-03-10 09:17:36.0 +0100 @@ -6,20 +6,12 @@ remove) ;; purge) - echo "Purging logfiles..." - rm -rf /var/log/squid - - if [ -f /etc/squid/squid.conf ]; then - echo "Removing the config-file .." -
Bug#866045: let this be for 1.5-13+deb9u1
Hi! We've already missed 9.1 with this fix, I left some questions here last time... > Will this be ok for an upload? > > If so... when should I upload it? > > Will a normal dput work given the stretch target on the changelog, or should > I do something special? Can we try to make this into 9.2, please? Regards... -- Manty/BestiaTester -> http://manty.net
Bug#866045: let this be for 1.5-13+deb9u1
Hi!
So, following kibi's advice I've reported the bug and here is the new full
patch.
diff -ru bridge-utils-1.5-13/debian/bridge-utils.sh
bridge-utils-1.5-13+deb9u1/debian/bridge-utils.sh
--- bridge-utils-1.5-13/debian/bridge-utils.sh 2017-07-02 23:27:55.0
+0200
+++ bridge-utils-1.5-13+deb9u1/debian/bridge-utils.sh 2017-07-02
23:29:30.0 +0200
@@ -58,11 +58,11 @@
create_vlan_port()
{
# port doesn't yet exist
-if ! grep -q "$port" /proc/net/dev
+if ! grep -q "$port:" /proc/net/dev
then
dev="${port%.*}"
# port is a vlan and the device exists?
- if [ "$port" != "$dev" ] && grep -q "$dev" /proc/net/dev
+ if [ "$port" != "$dev" ] && grep -q "$dev:" /proc/net/dev
then
if [ -f /proc/sys/net/ipv6/conf/$dev/disable_ipv6 ]
then
@@ -77,7 +77,7 @@
destroy_vlan_port()
{
# port exists
-if grep -q "$port" /proc/net/dev
+if grep -q "$port:" /proc/net/dev
then
dev="${port%.*}"
# port is a vlan
diff -ru bridge-utils-1.5-13/debian/changelog
bridge-utils-1.5-13+deb9u1/debian/changelog
--- bridge-utils-1.5-13/debian/changelog2017-07-02 23:27:55.0
+0200
+++ bridge-utils-1.5-13+deb9u1/debian/changelog 2017-07-02 23:29:30.0
+0200
@@ -1,3 +1,10 @@
+bridge-utils (1.5-13+deb9u1) stretch; urgency=low
+
+ * Fix a problem with some vlan interfaces not being created.
+Closes: #866687.
+
+ -- Santiago Garcia Mantinan <ma...@debian.org> Sun, 02 Jul 2017 23:20:04
+0200
+
bridge-utils (1.5-13) unstable; urgency=low
* Fix a hardcoded interface name on bridge-utils.sh. Closes: #854841.
Will this be ok for an upload?
If so... when should I upload it?
Will a normal dput work given the stretch target on the changelog, or should
I do something special?
Regards...
--
Manty/BestiaTester -> http://manty.net
Bug#866045: stretch-pu: package bridge-utils/1.5-14
I'm sorry about the mistakes on this stretch-pu upload, this is the first time
I try to upload something to stable.
I was following
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable
but didn't find there all the info I was looking for, is there any other
more comprehensive doc?
My first doubt was if I should fill the bug report against current stable
version or if I should first upload a fixed version.
About the bug report as I was the one finding it I directly created the fix,
if you prefer me to file a bug so that we can then close it on our
changelog, that's fine with me.
The full patch should be this one:
diff -ru bridge-utils-1.5-13/debian/bridge-utils.sh
bridge-utils-1.5-13+deb9u1/debian/bridge-utils.sh
--- bridge-utils-1.5-13/debian/bridge-utils.sh 2017-06-27 22:57:15.0
+0200
+++ bridge-utils-1.5-13+deb9u1/debian/bridge-utils.sh 2017-06-27
22:57:37.0 +0200
@@ -58,11 +58,11 @@
create_vlan_port()
{
# port doesn't yet exist
-if ! grep -q "$port" /proc/net/dev
+if ! grep -q "$port:" /proc/net/dev
then
dev="${port%.*}"
# port is a vlan and the device exists?
- if [ "$port" != "$dev" ] && grep -q "$dev" /proc/net/dev
+ if [ "$port" != "$dev" ] && grep -q "$dev:" /proc/net/dev
then
if [ -f /proc/sys/net/ipv6/conf/$dev/disable_ipv6 ]
then
@@ -77,7 +77,7 @@
destroy_vlan_port()
{
# port exists
-if grep -q "$port" /proc/net/dev
+if grep -q "$port:" /proc/net/dev
then
dev="${port%.*}"
# port is a vlan
diff -ru bridge-utils-1.5-13/debian/changelog
bridge-utils-1.5-13+deb9u1/debian/changelog
--- bridge-utils-1.5-13/debian/changelog2017-06-27 22:57:15.0
+0200
+++ bridge-utils-1.5-13+deb9u1/debian/changelog 2017-06-27 22:57:37.0
+0200
@@ -1,3 +1,9 @@
+bridge-utils (1.5-13+deb9u1) stretch; urgency=low
+
+ * Fix a problem with some vlan interfaces not being created.
+
+ -- Santiago Garcia Mantinan <ma...@debian.org> Tue, 27 Jun 2017 22:53:30
+0200
+
bridge-utils (1.5-13) unstable; urgency=low
* Fix a hardcoded interface name on bridge-utils.sh. Closes: #854841.
About the problem we are trying to fix was not with the interfaces but with
other vlans, for example if the first vlan bridge port being created is
eth0.2000 and then eth0.2 is being added to this bridge, eth0.2 won't be
created as the bug will confuse eth0.2 with eth0.2000, with the patch this
will work ok.
So... how do we proceed from here?
Thanks in advance and sorry again.
Regards.
--
Manty/BestiaTester -> http://manty.net
Bug#866045: stretch-pu: package bridge-utils/1.5-14
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
When updating a production machine to Stretch I found that the check for
vlan interfaces was wrong and thus some of the vlans were not being created.
I have worked on a fix for this which is on -14 version of the package, I
have uploaded that already to unstable, but I'd like this to be parth of the
next point release, here is the diff for the fix:
--- bridge-utils.sh-1.5-13 2017-06-26 23:42:52.791730487 +0200
+++ bridge-utils.sh-1.5-14 2017-06-26 23:42:10.215270353 +0200
@@ -58,11 +58,11 @@
create_vlan_port()
{
# port doesn't yet exist
-if ! grep -q "$port" /proc/net/dev
+if ! grep -q "$port:" /proc/net/dev
then
dev="${port%.*}"
# port is a vlan and the device exists?
- if [ "$port" != "$dev" ] && grep -q "$dev" /proc/net/dev
+ if [ "$port" != "$dev" ] && grep -q "$dev:" /proc/net/dev
then
if [ -f /proc/sys/net/ipv6/conf/$dev/disable_ipv6 ]
then
@@ -77,7 +77,7 @@
destroy_vlan_port()
{
# port exists
-if grep -q "$port" /proc/net/dev
+if grep -q "$port:" /proc/net/dev
then
dev="${port%.*}"
# port is a vlan
I hope we can get this into the next stable release.
Regards.
-- System Information:
Debian Release: 9.0
APT prefers stable
APT policy: (990, 'stable'), (500, 'oldoldstable'), (500, 'unstable'), (500,
'oldstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_ES.UTF-8 (charmap=UTF-8),
LANGUAGE=gl_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Bug#864409: unblock: squid3/3.5.23-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package squid3 When we upgrade from Jessie's squid3 to Stretch we are switching from binary package named squid3 to the one named squid. We are preserving the config file which is correctly moved from /etc/squid3 to /etc/squid but squid is started before squid3 moves the config file into place, so it is started with the default config instead of the one that the user wants. We have added a reload to squid in order for it to use the user's one. Diff of can be found here: https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=pkg-squid/pkg-squid3.git;a=commitdiff;h=d8dfa934232e89424dbe99bf5beb651b31137958 unblock squid3/3.5.23-5 -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_ES.UTF-8 (charmap=UTF-8), LANGUAGE=gl_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
removing swfdec from testing (gnome depends on it)
Hi! I'm the maintainer of swfdec and I'd like to have swfdec packages removed from squeeze as upstream is no longer developping it, the problem here is that gnome-desktop-environment is depending on swfdec-gnome, thus if we remove swfdec we'll need to change the dependencies of gnome-desktop-environment or otherwise gnome will loose some of its packages. I mailed pkg-gnome-maintainers about this on the 7th Feb but I still haven't had any reply about this, so my question is... what should I do now? What follows is the message I sent to the gnome guys and to the maintainer of gnash which is the other free alternative to swfdec. Regards. - Forwarded message from Santiago Garcia Mantinan ma...@debian.org - Date: Sun, 7 Feb 2010 01:10:26 +0100 From: Santiago Garcia Mantinan ma...@debian.org To: pkg-gnome-maintain...@lists.alioth.debian.org Cc: little_m...@yahoo.es Subject: what to do with swfdec and thus swfdec-gnome on Debian Hi! Last year I spoke to the main developer of swfdec because people were asking for new features filling bugs on the packages, most asking for me to package the unstable version, and upstream hadn't released any version, stable or unstable. He told me that he had stopped working on swfdec and he had focused on other things. Since then things haven't changed, nobody has picked up on swfdec development, so I'd say that the project is dead upstream, and I'd say that we should remove it from our next version, but I'd like to comment it with you as you have gnome-desktop-environment depending on it. I'm also CCing Miriam, the maintainer of gnash, wich is the other free flash player we have around, to see how we could ease a transition from swfdec to gnash if we feel this is needed, I think it would be a good thing to do. Miriam, I have tried a couple of times to mail you about this, but I didn't get a reply back, I don't know if you have been busy or if ther is any filter dropping mails around :-? Regards -- Manty/BestiaTester - http://manty.net - End forwarded message - -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100215232949.ga3...@dis.manty.net
Re: ROM: Upload of swfdec-mozilla 0.6.0-5 to testing-proposed-updates
Ok, please upload do t-p-u. Ok, uploaded right now. Regards... -- Manty/BestiaTester - http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
ROM: Upload of swfdec-mozilla 0.6.0-5 to testing-proposed-updates
Hi!
After talking with upstream about #496741 and #503315 (one of them is a RC
bug) it has said that this seems to be upstream's bug
http://bugs.freedesktop.org/show_bug.cgi?id=15962
which was solved with this patch:
http://cgit.freedesktop.org/swfdec/swfdec-mozilla/diff/src/swfmoz_player.c?h=0.8id=c37f02fc20a4ffc74eecfceeaff913a250933320
on newer versions, applying it to 0.6.0 would be like this:
--- swfdec-mozilla-0.6.0.orig/src/swfmoz_player.c
+++ swfdec-mozilla-0.6.0/src/swfmoz_player.c
@@ -353,10 +353,6 @@
gdk_region_destroy (player-repaint);
player-repaint = NULL;
}
- if (player-initial) {
-g_object_unref (player-initial);
-player-initial = NULL;
- }
if (player-loaders) {
g_object_unref (player-loaders);
player-loaders = NULL;
Quoting upstream:
[21:07] Company manty: i can tell you the code is wrong in 0.6, because it
unrefs an NPStream
[21:07] Company manty: so whenever player-initial is set, swfdec-mozilla is
gonna crash
Reporters have not been clear on their bugs, they are unresponsive to my
requests of more info and I cannot replicate the problem on amd64 or i386 so
I cannot tell if the patch will really fix this bugs or not, but upstream
thinks it will and at least will fix the crash upstream comments.
So... if you think this is ok I'll try to upload through
testing-proposed-updates (we have 0.8.2 in unstable) or whatever you tell me
to do.
Regards...
--
Manty/BestiaTester - http://manty.net
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removal request: madwifi, madwifi-tools
Hi! Sorry to jump on the discussion so late, I only realised about the discusion today when Kel pointed me to it after I had filled more info on bug #492251 because of the bad state current package is on. I see two issues here: - Maintainability of the packages we ship with (even this is not main but non-free) - Support of old and new hardware I see that the current code on Debian doesn't meet any of the two points, it fails to meet the first one because it is a snapshot taken out of a development tree on which work seems to be at least dying, and it fails to meet second point because if it does support new hardware it does so by causing a lot of hangs on both this new hardware but also the old one (see my latest post on bug #492251). So... as I already sugested on that bug, for me the ideal thing would have been to stick with the stable madwifi (with the necesary patches for current kernels) and then add a new madwifi package with support for the new hardware, this second package should now be based on the code from the dd-wrt and openwrt guys, as it seems quite stable to me (only had it for the last three days but on this time it already hanged my AP which has etch with 0.9.4 while the client based on the the new hal didn't hang at all). I don't know if it is too late for all this, given the usual rules for a release schedule it would be, but as this is non-free stuff and we have a real problem with current code, maybe it is not that late. What we win with having two packages, one based on 0.9.4 as Kel wanted, and another one based on the new hal? We have supported code: I mean that if madwifi continues to live they should support 0.9.4 which is their latest stable version and also the openwrt guys will support the code they use or plan to use on their distro (current code seems not supported by anybody). We have supported hardware: The stable version of madwifi supports well the old hardware giving support for features that are not on the free drivers, and the new hal support the new hardware (correct me if I'm wrong, but seems stable and if not, it will be supported during lenny). The cons will be that we have to give support to two packages instead of one, but it seems that these two packages would be better supported upstream than current one, and that we wouldn't be promoting too well the free alternative, which is false as the free alternative is the one that comes activated by default and in the main part of Debian. So... I'd like to know how would people feel about this two packages scheme, which would mean to go back to the old stable code like kel wanted and have a new package around to support new hardware. Regards... -- Manty/BestiaTester - http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Request for a exception for bridge-utils
The 27th I uploaded a new version of bridge-utils to close two bugs, one was just a doc bug, so I just changed one of the manpages, the other bug was a normal severity bug, so this package wouln't be a candidate for an exception, but the bug (496491) was causing that all the set commands of brctl (i386) where failing when running with amd64 kernels and I would have set this sevirity higher because of that, so I think it qualifies for an exception. On the other hand the changes I did were just the doc and the one liner to fix this architecture bug, so I'd rather we would ship the new version. Regards... -- Manty/BestiaTester - http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Request for a exception for swfdec-mozilla and gnash
Hi! Due to serious severity bug #493307 (swfdec-mozilla: can't use another Flash plugin in mozilla when installed) and the fact that iceweasel and most if not all browsers don't implement a good way to select the plugin to be used to play a content, the maintainers of flash plugins for mozilla have agreed to implement Debian alternatives to solve this bug. We have uploaded new packages of swfdec-mozilla and gnash (the two free plugins), the changes we have done are only the ones needed to support the alternatives, being the bigger one that on swfdec-mozilla I had to change the configure options in order to move the plugin to another directory. As for the nonfree... Marillat has also made the changes to the nonfree plugin he maintains on his nonfree repo. The packages sould be in good shape and we feel that fixing this bug is important because of the dependency gnome has on swfdec-mozilla which currently means that all flash content will be played with swfdec-mozilla without an easy way for the user to select any other flash plugin. If you need any other info on this just ask for it. Regards... -- Manty/BestiaTester - http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Request for a exception for swfdec0.6
Hi! On tuesday after the freeze a bugfix version of swfdec0.6 was released, I uploaded it to unstable (priority=high, sorry about that, I hadn't read the freeze announcement). The new version is just a bugfix version and fixes several crashes, playing content which could be remote content, thus I believe this new version should be accepted on testing. I have made no changes on the packaging from the version currently on testing and this are the changes as descrived by upstream on the announcement of this version: -- Here is another bugfix release for the stable 0.6 series of Swfdec, the Free decoder/renderer for Adobe Flash animations. swfdec-0.6.8 (Mario Rush) http://swfdec.freedesktop.org/download/swfdec/0.6/swfdec-0.6.8.tar.gz MD5: 740caf52068556ffe151703342fb634b Changes: - fix a crash when decoding 1x1 JPEG images - fix a crash in XMLSocket.send - fix crashes when FLV decoding was aborted - fix a crash in exception handling code - fix some infinite loops with prototype loops - fix crasher when handling broken dates - fix crashers with native constructors found in testing - compatibility fixes: compile with gold linker, make includes work from C++ -- If you need any other info just ask for it. Regards... -- Manty/BestiaTester - http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RM: swfdec0.5/testing -- ROM; has been superseded by swfdec0.6
Please remove swfdec0.5 from the archives, currently on testing, unstable and experimental, it has been superseded by swfdec0.6, 0.5 version has security problems and is no longer maintained as it was the old development branch. All packages depending on version 0.5 have been compiled against 0.6 and have now transitioned to testing. Regards... -- Manty/BestiaTester - http://manty.net signature.asc Description: Digital signature
swfdec-mozilla need a build on mips and mipsel to get to testing
Hi! I was looking at the status of the swfdec stuff (swfdec0.5, swfdec-mozilla, swfdec-gnome) before uploading the new version, and It seems [1] that we are just missing the builds for swfdec-mozilla on mips and mipsel so that we can transition. If somebody could please trigger those builds which were tried on December the first and not anymore, we should be able to build and get to testing. The previous build on the first of December had failed because the libraries were not built at that time, but they are currently built and available on the archive. [1] http://bjorn.haxx.se/debian/testing.pl?package=swfdec-mozilla Regards... -- Manty/BestiaTester - http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Including Sarge Release Notes on first CDs
Now for the real request. It would be nice if the release notes (html, pdf and txt versions) could be included on the first CD, same as the installation manual. There are 11 languages that qualify: en, es, fr, de, cs, it, nl, pt_BR, ja, zh_CN, zh_TW As for the manuals, we are currently including some of them, as published in the archives by the debian-boot guys at dists/sarge/main/intsaller-$(arch)/current/doc/manual As for the release notes... I see they are at the web, are them at some other place (in the ftp as a package or in any other place) where we can get them from? As for the space needed... last time joeyh checked we were running out of space as to have the wanted tasks on the cd1, I don't know how much space is left after we fill in all the wanted tasks, we'll take a look. Regards... -- Manty/BestiaTester - http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Including Sarge Release Notes on first CDs
Correct me if I'm wrong but these are based on the manuals provided by the latest debian-installer-manual package and not on the latest SVN sources. Am I right? Just curious, since there have been updates and improvements to the english version of the manual, new translations have been made and available translations have been reviewed since the debian-installer-manual was last uploaded (March this year) Well, they are provided by debian-installer, so they come from the rc3 of debian-installer, the question is... should we use these? should both the manuals and the Release-Notes be updated in the ftp? Well, I believe that if the cds should include the new versions, then the ftp should be updated, just my opinion though. However, if we should include newer versions of the manuals and release-notes in the cds, we need to know what to add and where to get them from, so somebody from the release team should speak about that. Till now we've been including only manuals, not release-notes on the cds, and there are more translations now, which means more space needed in the cds, so we must know this data as soon as posible to see if it will fit in the cds or not. Regards... -- Manty/BestiaTester - http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
