Bug#1036331: unblock: squidguard/1.6.0-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: squidgu...@packages.debian.org
Control: affects -1 + src:squid
Please unblock package squid
This fixes RC bug #1036028 which could affect users upgrading from
bullseye to bookworm.
unblock squidguard/1.6.0-4
diff -Nru squidguard-1.6.0/debian/changelog squidguard-1.6.0/debian/changelog
--- squidguard-1.6.0/debian/changelog 2022-03-18 08:38:18.0 +0100
+++ squidguard-1.6.0/debian/changelog 2023-05-16 16:22:49.0 +0200
@@ -1,3 +1,9 @@
+squidguard (1.6.0-4) unstable; urgency=medium
+
+ * Fix dependency to squid-openssl | squid. Closes: #1036028
+
+ -- Joachim Wiedorn Tue, 16 May 2023 16:22:49 +0200
+
squidguard (1.6.0-3) unstable; urgency=medium
* Recompiling with newer libc.
diff -Nru squidguard-1.6.0/debian/control squidguard-1.6.0/debian/control
--- squidguard-1.6.0/debian/control 2022-03-18 08:38:18.0 +0100
+++ squidguard-1.6.0/debian/control 2023-05-16 16:21:06.0 +0200
@@ -13,7 +13,7 @@
Package: squidguard
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
-Recommends: squid (>= 3.4.0), liburi-perl, libwww-perl
+Recommends: squid-openssl | squid, liburi-perl, libwww-perl
Suggests: ldap-utils, squidguard-doc
Description: filter and redirector plugin for Squid
squidGuard is a free, flexible and ultra fast filter, redirector
diff -Nru squidguard-1.6.0/debian/copyright squidguard-1.6.0/debian/copyright
--- squidguard-1.6.0/debian/copyright 2022-03-18 08:38:18.0 +0100
+++ squidguard-1.6.0/debian/copyright 2023-05-16 16:19:47.0 +0200
@@ -19,7 +19,7 @@
License: W3C-Software
Files: debian/*
-Copyright: 2010-2022, Joachim Wiedorn
+Copyright: 2010-2023, Joachim Wiedorn
License: GPL-2
squidguard_160-4.debdiff
Description: Binary data
pgpxOwUR2KfQX.pgp
Description: Digitale Signatur von OpenPGP
Re: Request: removal of package lilo from testing
Hello Paul, Paul Gevers wrote on 2019-11-29 20:35: > Do you mean, a new version of the lilo package (I was reading it for a > while you were going to introduce a new binary package, which doesn't > make sense to me)? Not a new upstream lilo package, but only a updated Debian package, only with a new NEWS file. > Your approach above will be good for users of unstable and testing, but > how does this help users of stable, when they upgrade from buster to > bullseye after the release of the latter? Just by writing this in the > release notes? Is that the best we can do? That's right, it doesn't help users of stable and oldstable, if they make an upgrade. But then the only solution is making a transitional package "lilo" which have dependency to grub2, which will install grub2 and remove the binaries of lilo. This can entail many risks. Because of many different system structures it could be, that at the end there is no functioning booting on this system ... --- Have a nice day. Joachim (Germany) pgpE3JWH7Hh0c.pgp Description: Digitale Signatur von OpenPGP
Re: Request: removal of package lilo from testing
Hello Paul, Paul Gevers wrote on 2019-11-16 20:20: > Hi Joachim, > > On 16-11-2019 13:42, Joachim Wiedorn wrote: > > Paul Gevers wrote on 2019-11-11 22:57: > > > >> On different thoughts, are users of lilo migrated to grub2 in any way? > >> Is this possible? If not, this is probably worth mentioning in the > >> release-notes, no? > > > > This is a important point. What is the best way? Now I have decided to let lilo in the repository for some more months and create a new package with debian/NEWS file with this content: Lilo is at the end of development for some years. Finally the Debian package of lilo will set as deprecated and will vanish as install package until the end of year 2020. All machines with lilo should move to grub2 (or others) in the next months. I have checked the "Popularity contest statistics for lilo" which say: Vote: 104 Recent: 23 (and 6 of them are devices from me) Because of this statistic I think this is the easiest way for this package. What do you think? Perhaps you have a better text for the NEWS file? --- Have a nice day. Joachim (Germany) pgpIEyyACyzpe.pgp Description: Digitale Signatur von OpenPGP
Re: Request: removal of package lilo from testing
Hello Paul, Paul Gevers wrote on 2019-11-11 22:57: > On different thoughts, are users of lilo migrated to grub2 in any way? > Is this possible? If not, this is probably worth mentioning in the > release-notes, no? This is a important point. What is the best way? Should I create a "last" package for bullseye and then write the RC? Or should I create a transition package instead of orphan the package? Have a nice day. Joachim (Germany) pgptxHbDO2zvY.pgp Description: Digitale Signatur von OpenPGP
Request: removal of package lilo from testing
Hello release team! For more than 10 years grub2 is the successor of lilo as boot loader and finally it seems all problems and wishes were solved with grub2. I have maintained lilo for many years and I think it is now the right time to remove lilo from testing. I am also the (last) developer of lilo. I have searched for somebody who want to overtake development, but it seems nobody want to work with "this old software". Because the software is in a good state until now it should stay in sid until the next Debian release. Have a nice day. Joachim (Germany) pgpwPixcn7Gmo.pgp Description: Digitale Signatur von OpenPGP
Re: xfe is marked for autoremoval from testing
Hello release team, Debian testing autoremoval watch wrote on 2015-12-18 04:39: > > xfe 1.41-3 is marked for autoremoval from testing on 2015-12-28 > > It is affected by these RC bugs: > 806579: xfe: FTBFS: configure:14251: error: "ftheader.h not found" since xfe version 1.41-1 the FTBFS bug #806579 is solved. But I still get the message about 'autoremoval'. I don't understand, why? While compiling using pbuilder I don't get such errors. How can I solve this problem? --- Have a nice day. Joachim (Germany) pgpj8E6mNx8NP.pgp Description: Digitale Signatur von OpenPGP
Bug#782175: Unblock: chrony/1.30-2 [RC] -- RFS at mentors.debian.net
Package: release.debian.org
Severity: important
User: release.debian@packages.debian.org
Usertags: unblock
Hello release team,
because of three CVE security messages I have made an updated package
of chrony which is now on mentors.debian.net.
Please unblock package chrony/1.30-2.
The RFS can be seen here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782173
The updated package fixes three RC bugs:
* It includes the following security fixes (Closes: #782160):
- Fix CVE-2015-1853: Protect authenticated symmetric NTP
associations against DoS attacks.
- Fix CVE-2015-1821: Fix access configuration with subnet
size indivisible by 4.
- Fix CVE-2015-1822: Fix initialization of reply slots for
authenticated commands.
Details are in the attached debdiff.
Please unblock package chrony/1.30-2.
Many thanks for your work,
---
Have a nice day.
Joachim (Germany)
diff -urN d10/debian/changelog d14/debian/changelog
--- d10/debian/changelog 2014-08-10 19:10:56.0 +0200
+++ d14/debian/changelog 2015-04-09 00:31:10.0 +0200
@@ -1,3 +1,19 @@
+chrony (1.30-2) unstable; urgency=medium
+
+ * New upstream release.
+ * It includes the following security fixes (Closes: #782160):
+- Fix CVE-2015-1853: Protect authenticated symmetric NTP
+ associations against DoS attacks.
+- Fix CVE-2015-1821: Fix access configuration with subnet
+ size indivisible by 4.
+- Fix CVE-2015-1822: Fix initialization of reply slots for
+ authenticated commands.
+ * debian/control:
+ - Update e-mail address of myself.
+ - Add Vincent Blut as co-maintainer.
+
+ -- Joachim Wiedorn joodeb...@joonet.de Thu, 09 Apr 2015 00:06:34 +0200
+
chrony (1.30-1) unstable; urgency=medium
* New upstream release with following bugfixes:
diff -urN d10/debian/control d14/debian/control
--- d10/debian/control 2014-08-08 20:40:03.0 +0200
+++ d14/debian/control 2015-04-09 00:05:48.0 +0200
@@ -1,7 +1,8 @@
Source: chrony
Section: admin
Priority: extra
-Maintainer: Joachim Wiedorn ad_deb...@joonet.de
+Maintainer: Joachim Wiedorn joodeb...@joonet.de
+Uploaders: Vincent Blut vincent.deb...@free.fr
Standards-Version: 3.9.5
Build-Depends: debhelper (= 9),
texinfo, bison,
diff -urN d10/debian/patches/11_protect-authenticated-symmetric-ass.patch d14/debian/patches/11_protect-authenticated-symmetric-ass.patch
--- d10/debian/patches/11_protect-authenticated-symmetric-ass.patch 1970-01-01 01:00:00.0 +0100
+++ d14/debian/patches/11_protect-authenticated-symmetric-ass.patch 2015-04-08 23:50:45.0 +0200
@@ -0,0 +1,72 @@
+From d856bd34c4862398411d29200520e3a3b1d4569e Mon Sep 17 00:00:00 2001
+From: Miroslav Lichvar mlich...@redhat.com
+Date: Thu, 5 Mar 2015 12:44:30 +0100
+Subject: ntp: protect authenticated symmetric associations against DoS attacks
+
+An attacker knowing that NTP hosts A and B are peering with each other
+(symmetric association) can send a packet with random timestamps to host
+A with source address of B which will set the NTP state variables on A
+to the values sent by the attacker. Host A will then send on its next
+poll to B a packet with originate timestamp that doesn't match the
+transmit timestamp of B and the packet will be dropped. If the attacker
+does this periodically for both hosts, they won't be able to synchronize
+to each other. It is a denial-of-service attack.
+
+According to [1], NTP authentication is supposed to protect symmetric
+associations against this attack, but in the NTPv3 (RFC 1305) and NTPv4
+(RFC 5905) specifications the state variables are updated before the
+authentication check is performed, which means the association is
+vulnerable to the attack even when authentication is enabled.
+
+To fix this problem, save the originate and local timestamps only when
+the authentication check (test5) passed.
+
+[1] https://www.eecis.udel.edu/~mills/onwire.html
+
+diff --git a/ntp_core.c b/ntp_core.c
+index ebb6a7c..e654c88 100644
+--- a/ntp_core.c
b/ntp_core.c
+@@ -914,9 +914,6 @@ receive_packet(NTP_Packet *message, struct timeval *now, double now_err, NCR_Ins
+
+ /* */
+
+- /* Save local receive timestamp */
+- inst-local_rx = *now;
+-
+ pkt_leap = (message-lvm 6) 0x3;
+ if (pkt_leap == 0x3) {
+ source_is_synchronized = 0;
+@@ -948,14 +945,6 @@ receive_packet(NTP_Packet *message, struct timeval *now, double now_err, NCR_Ins
+ test2 = 1; /* Success */
+ }
+
+- /* Regardless of any validity checks we apply, we are required to
+- save this field from the packet into the ntp source
+- instance record. See RFC1305 section 3.4.4, peer.org - pkt.xmt
+- peer.peerpoll - pkt.poll. Note we can't do this assignment
+- before test1 has been carried out!! */
+-
+- inst-remote_orig = message-transmit_ts;
+-
+ /* Test 3 requires that pkt.org
Bug#773983: Unblock: squidguard/1.5-4
Package: release.debian.org
Severity: important
User: release.debian@packages.debian.org
Usertags: unblock
Hello release team,
please unblock package squidguard.
Unblock squidguard/1.5-4
The version squidguard/1.5-4 fixes one RC bug which prevents webfiltering
with squid3 because of a new redirector protocol introduced in Debian with
squid3 version 3.4.8-1. Here is the changelog for updated squidguard:
* Fix for working with squid 3.4 and higher. Closes: #772831
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772831
* Update dependency to squid3 (= 3.4.0) because the new patch
let squidguard only support newer versions of squid3 and
don't support squid 2.7 anymore.
Details are in the attached debdiff.
Many thanks for your work,
---
Have a nice day.
Joachim (Germany)
diff -urN d00/debian/changelog d02/debian/changelog
--- d00/debian/changelog 2014-09-22 16:41:02.0 +0200
+++ d02/debian/changelog 2014-12-25 20:26:51.333680178 +0100
@@ -1,3 +1,12 @@
+squidguard (1.5-4) unstable; urgency=medium
+
+ * Fix for working with squid 3.4 and higher. Closes: #772831
+ * Update dependency to squid3 (= 3.4.0) because the new patch
+ let squidguard only support newer versions of squid3 and
+ don't support squid 2.7 anymore.
+
+ -- Joachim Wiedorn joodeb...@joonet.de Thu, 25 Dec 2014 20:21:03 +0100
+
squidguard (1.5-3) unstable; urgency=medium
* debian/control:
diff -urN d00/debian/control d02/debian/control
--- d00/debian/control 2014-09-21 01:30:31.0 +0200
+++ d02/debian/control 2014-12-25 20:23:22.241254212 +0100
@@ -1,7 +1,7 @@
Source: squidguard
Section: web
Priority: optional
-Maintainer: Joachim Wiedorn ad_deb...@joonet.de
+Maintainer: Joachim Wiedorn joodeb...@joonet.de
Build-Depends: debhelper (= 9),
libldap2-dev, libdb-dev,
po-debconf, bison, flex
@@ -13,7 +13,7 @@
Package: squidguard
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
-Recommends: squid3 | squid, liburi-perl, libwww-perl
+Recommends: squid3 (= 3.4.0), liburi-perl, libwww-perl
Suggests: ldap-utils, squidguard-doc
Description: filter and redirector plugin for Squid
squidGuard is a free, flexible and ultra fast filter, redirector
diff -urN d00/debian/copyright d02/debian/copyright
--- d00/debian/copyright 2014-09-21 00:10:14.0 +0200
+++ d02/debian/copyright 2014-12-25 20:22:00.403519436 +0100
@@ -19,7 +19,7 @@
License: W3C-Software
Files: debian/*
-Copyright: 2010-2014, Joachim Wiedorn ad_deb...@joonet.de
+Copyright: 2010-2014, Joachim Wiedorn joodeb...@joonet.de
License: GPL-2
diff -urN d00/debian/patches/14_fix-working-with-squid-3-4.patch d02/debian/patches/14_fix-working-with-squid-3-4.patch
--- d00/debian/patches/14_fix-working-with-squid-3-4.patch 1970-01-01 01:00:00.0 +0100
+++ d02/debian/patches/14_fix-working-with-squid-3-4.patch 2014-12-25 19:23:52.0 +0100
@@ -0,0 +1,144 @@
+Package: squidguard
+Subject: fix for working (only) with squid 3.4 and higher
+Author: Joachim Wiedorn joodebian at joonet.de
+Origin: other, http://bugs.squid-cache.org/show_bug.cgi?id=3978
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772831
+Forwarded: yes
+Last-Update: 2014-12-22
+
+Incorrectly use of Squid helper protocol (old squid-2.5 protocol).
+This bugfix let it work together with squid3 v3.4 and higher. Pay
+attention that with this patch squidguard don't work with squid 3.3
+and lower anymore!
+---
+
+diff -urN s13/src/main.c s14/src/main.c
+--- s13/src/main.c 2014-12-11 18:10:03.943372692 +0100
s14/src/main.c 2014-12-23 23:07:49.583732080 +0100
+@@ -185,7 +185,7 @@
+ sgReloadConfig();
+ }
+ if(failsafe_mode) {
+- puts();
++ puts(ERR message=\squidGuard failsafe mode\);
+ fflush(stdout);
+ if(sig_hup){
+ sgReloadConfig();
+@@ -194,7 +194,7 @@
+ }
+ if(parseLine(buf,squidInfo) != 1){
+ sgLogError(ERROR: Error parsing squid line: %s,buf);
+- puts();
++ puts(BH message=\squidGuard error parsing squid line\);
+ }
+ else {
+ src = Source;
+@@ -206,14 +206,14 @@
+ acl = sgAclCheckSource(src);
+ if((redirect = sgAclAccess(src,acl,squidInfo)) == NULL){
+ if(src == NULL || src-cont_search == 0){
+- puts();
++ puts(ERR);
+ break;
+ } else
+ if(src-next != NULL){
+ src = src-next;
+ continue;
+ } else {
+- puts();
++ puts(ERR);
+ break;
+ }
+ } else {
+@@ -225,9 +225,11 @@
+ squidInfo.ident[0] = '-';
+ squidInfo.ident[1] = '\0';
+ }
+- fprintf(stdout,%s %s/%s %s %s\n,redirect,squidInfo.src,
+- squidInfo.srcDomain,squidInfo.ident,
+- squidInfo.method);
++ if (isdigit(redirect[0]) isdigit(redirect[1]) isdigit(redirect[2]) redirect[3]==':') {
++ fprintf(stdout,OK status=%c%c%c url=\%s\\n, redirect[0], redirect[1], redirect[2], redirect[4]);
++ } else
++ fprintf(stdout,OK rewrite-url=\%s\\n,redirect
Bug#699171: Pre-Approval: capi4hylafax/1:01.03.00.99.svn.300-19
Hello Julien, Julien Cristau wrote on 2013-03-19 10:36: I don't understand. dpkg won't try to remove a directory owned by two packages if you remove one of them. It isn't done by dpkg but by postrm of hylafax-server package in this way: [ -d /var/spool/hylafax/etc ] rm -rf /var/spool/hylafax/etc [ -L /var/spool/hylafax/bin ] rm /var/spool/hylafax/bin for i in /etc/hylafax/setup.cache /etc/hylafax/setup.modem \ /var/spool/hylafax/status/any.info /var/spool/hylafax/dev/null \ /var/spool/hylafax/FIFO /var/spool/hylafax/bin/ps2fax \ /var/spool/hylafax/bin/pdf2fax /var/spool/hylafax/bin/bin \ /etc/default/hylafax do [ -e $i -o -L $i ] rm $i done [ -d /var/spool/hylafax/bin ] rmdir --ignore-fail-on-non-empty /var/spool/hylafax/bin With hylafax 6.0.6-5 the postrm script do not remove /var/spool/hylafax anymore. So capi4hylafax have the chance to use this directory without problems. --- Have a nice day. Joachim (Germany) -- 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/20130319202722.469c4...@jupiter.home
Bug#699171: Pre-Approval: capi4hylafax/1:01.03.00.99.svn.300-19
Hello Julien, Julien Cristau wrote on 2013-03-18 20:42: The debdiff and the above is rather short on explanations (and I'd rather not read the whole bug log for 661482)... Care to explain why these directories must be created in postinst rather than shipped in the package? hylafax itself have the working directory /var/spool/hylafax with many subdirectories. To make capi4hylafax working together with hylafax it must use these directories, too. But there is another case: capi4hylafax can also work without hylafax. The main problem is: while deinstalling hylafax the package hylafax doesn't know something about capi4hylafax. If the package capi4hylafax would shipping these named directories of hylafax in its package and hylafax would be purged then this give errors because the directory /var/spool/hylafax with some subdirectories would be owned by both packages and hylafax want to delete these directories. To manage all the different cases the only way is the handling in the pre* post* scripts of capi4hylafax. I hope these information helps. I think Giuseppe could explain some more details in better english. --- Have a nice day. Joachim (Germany) -- 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/2013031803.3eab4...@jupiter.home
Bug#685230: unblock hylafax 3:6.0.6-4 / -5
Hallo Giuseppe, Giuseppe Sacco wrote on 2013-03-11 00:16: I checked your package diff, rebuilt the package and tested it. Then I uploaded it, so hopefully it should enter unstable. Perfectly! Tomorrow I will also check capi4hylafax -19. If you still need a sponsor, I'll gladly upload the package. This would be very nice. Unfortunately until now I haven't any answer about my pre-approval of capi4hylafax ...300-19 from release team: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699171 But without the updated capi4hylafax the RC bug #661482 cannot be solved. --- Have a nice day. Joachim (Germany) -- 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/20130311171724.2830c...@jupiter.home
Bug#685230: unblock hylafax 3:6.0.6-4
Hello Guiseppe, Giuseppe Sacco wrote on 2013-03-01 10:44: The diff I'll use is almost what Ivo suggested in http://lists.debian.org/debian-release/2012/12/msg00886.html Until now I haven't your updated package. So I have made one with the following debdiff (see attached file). And I have already tested both packages (hylafax-server 6.0.6-19 with capi4hylafax ...300-19) with piuparts. You see the (successful) result in attached logfile. I have already uploaded this package to mentors.d.n for sponsoring. Do you have time to review and sponsor this upload? If not I can write RFS. See: https://mentors.debian.net/package/hylafax --- Have a nice day. Joachim (Germany) debdiff_hylafax-606-5.diff.gz Description: GNU Zip compressed data hyl+c4h_amd64_wheezy_piu.log.gz Description: GNU Zip compressed data
Bug#685230: unblock hylafax 3:6.0.6-4
Hello Julien, Julien Cristau wrote on 2013-02-28 22:11: This version 3:6.0.6-5 should be uploaded to unstable. is there an ETA for that new upload? At first we need an updated version of capi4hylafax to solve one half of the problems between hylafax and capi4hylafax. This new version is already on mentors.d.o ready for wheezy: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697733 And I have asked the release team for pre-approval: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699171 The next step is creating hylafax 6.0.6-5 as mentioned by Ivo De Decker. Should I already prepare these updated package of hylafax now? --- Have a nice day. Joachim (Germany) -- 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/20130301080027.2fd6b...@jupiter.home
Bug#699171: Pre-Approval: capi4hylafax/1:01.03.00.99.svn.300-19
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: pre-approval Hello release team, I ask for pre-approval for package capi4hylafax. There is a difficult RC bug (#661482) which mention also package hylafax. To resolve this RC bug a bugfix for hylafax and capi4hylafax is needed. As first step here is the bugfix of capi4hylafax: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697733 The updated capi4hylafax 1:01.03.00.99.svn.300-19 fixes a part of RC bug #661482: * Optimize postrm script and add new postinst script to work together with hylafax-server and its 'mountbind'. (See: #661482) Details are in the attached debdiff. Many thanks for your work, --- Have a nice day. Joachim (Germany) debdiff_capi4hylafax_300-19.diff.gz Description: GNU Zip compressed data
Bug#685230: unblock hylafax 3:6.0.6-4
Hello! Ivo De Decker wrote on 2012-12-22 22:35: As there is still an RC bug in sid, I don't think it makes sense to do a TPU upload for the other one now. I'm attaching the TPU fix for 682824 for reference. As said I will try to update capi4hylafax because of this RC bug. If I can fix this RC in capi4hylafax, then I must move this bug to the capi4hylafax package before upload, right? It might be best to revert all the changes in unstable (since -1) that are not suitable for wheezy, and try to get a version in unstable that fixes both RC bugs in a non-intrusive way (based on -1). That way, the package could be tested in unstable before it gets to wheezy. The changes that are in -2 could go to experimental for now. Which is the best way? a) create the updated version 3:6.0.6-5 which is the same as 3:6.0.6-1 and then create the next version 3:6.0.6-6 which all needed patches for Wheezy, or b) create the updated version 4:6.0.6-1 which is the same as 3:6.0.6-1 and then create the next version 4:6.0.6-2 which all needed patches for Wheezy, or c) create a special Wheezy version 3:6.0.6-2+deb7u1 with all needed patches for Wheezy. What is your opinion? I would prefer way c). --- Have a nice day. Joachim (Germany) -- 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/20130103183927.33e1f...@jupiter.home
Re: Pre approval request for chrony (for Wheezy)
Hello Adam, Adam D. Barratt wrote on 2012-11-26 20:13: Actually, you can skip the unblock bug. :-) I've just added an approve hint for the t-p-u upload; thanks. Thank you very much. Now I have seen at http://qa.debian.org/excuses.php?package=chrony the following message: Unblock request by adsb ignored due to version mismatch: 1.24-3.1+deb7u1 Do you know the problem? Or can I ignore this message? --- Have a nice day. Joachim (Germany) -- 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/20121127201209.6113a...@jupiter.home
Re: Pre approval request for chrony (for Wheezy)
Hello release team, sorry for asking: I think I have done all correct to initiate an update of chrony for Wheezy, but since last week I haven't heard anythink about my request. Are there more problems? Could I solve them? Have a nice day. Joachim (Germany) --- Joachim Wiedorn wrote on 2012-11-16 15:12: Dear release team, after some mails in the last week with David I worked out some important patches to fix the both RC-bugs of package chrony and made a new package of chrony as update of the Wheezy package. Because chrony version in Unstable is made with new upstream version 1.26, my chrony package based on the version of Wheezy (1.24-3.1). Would you allow the changed chrony package for Wheezy? Debdiff is attached. Fixed RC-bugs: #689012 #691340 : : Have a nice day. Joachim (Germany) -- 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/20121121112605.4f4dd...@jupiter.home
Re: Pre approval request for chrony (for Wheezy)
Hello Adam, Adam D. Barratt wrote on 2012-11-21 11:40: a) by being more patient :) O.k. I will do. b) by filing requests in the BTS, not just mailing the list. That was not clear for me. I thought only unblocking need a bug report. --- Have a nice day. Joachim (Germany) -- 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/20121121151650.168c3...@jupiter.home
Re: Pre approval request for chrony (for Wheezy)
Hello Adam, Adam D. Barratt wrote on 2012-11-21 11:53: Ugh, what a mess. The two RC bugs you mention are merged, so closing one will by definition close the other. However, they appear to refer to different issues, so I'm not sure why they're merged in the first place. Both RC bugs concern a kernel 3.x problem, but technically they concern two different problems. I would be logical to unmerge these RC bugs. I want to do this before my upload. If #642209 and #691340 are the same bug, they should *be* the same bug (i.e. merged). As it is, the earlier bug will still be marked as outstanding in testing after the above upload, whereas the newer RC bug is still marked as applying to unstable, which it logically cannot. #628919 claims to be fixed in testing already, due to the unversioned -done. You are right, that's a mess. I will try to repair the flags of these bugs. Please feel free to go ahead with the upload, and file an unblock bug afterwards. The state of the bugs against chrony will need fixing up, however, as above. Thank you. So I will do the next steps. --- Have a nice day. Joachim (Germany) -- 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/20121121152556.5...@jupiter.home
Pre approval request for chrony (for Wheezy)
Dear release team,
after some mails in the last week with David I worked out some important
patches to fix the both RC-bugs of package chrony and made a new package
of chrony as update of the Wheezy package.
Because chrony version in Unstable is made with new upstream version 1.26,
my chrony package based on the version of Wheezy (1.24-3.1).
Would you allow the changed chrony package for Wheezy? Debdiff is attached.
Fixed RC-bugs: #689012 #691340
Changelog:
chrony (1.24-3.1+deb7u1) wheezy; urgency=medium
* Non-maintainer upload.
* Fix: Remove obsolete check for supported kernel versions (rtc_linux.c)
to run also for kernel versions 3.0 and higher. Since kernel 2.2 all
kernels have RTC support. Backport of upstream patch for version
1.26. Solves: #642209 for version 1.24. Closes: #691340
* Fix: Enable full support for kernel versions 3.0 and higher
(sys_linux.c) and ignore nonexistent patch level of kernel version
(which come with some kernel versions). Backport of upstream patch for
version 1.26. Solves: #628919 for version 1.24. Closes: #689012
-- Joachim Wiedorn ad_deb...@joonet.de Fri, 16 Nov 2012 10:01:01 +0100
Attachments:
* debdiff
* patchset (debdiff split in tree patches)
---
Have a nice day.
Joachim (Germany)
diff -urN chrony-1.24-old/debian/changelog chrony-1.24/debian/changelog
--- chrony-1.24-old/debian/changelog 2011-11-18 22:14:14.0 +0100
+++ chrony-1.24/debian/changelog 2012-11-16 10:11:44.244707530 +0100
@@ -1,3 +1,19 @@
+chrony (1.24-3.1+deb7u1) wheezy; urgency=medium
+
+ * Non-maintainer upload.
+
+ * Fix: Remove obsolete check for supported kernel versions (rtc_linux.c)
+ to run also for kernel versions 3.0 and higher. Since kernel 2.2 all
+ kernels have RTC support. Backport of upstream patch for version 1.26.
+ Solves: #642209 for version 1.24. Closes: #691340
+
+ * Fix: Enable full support for kernel versions 3.0 and higher (sys_linux.c)
+ and ignore nonexistent patch level of kernel version (which come with
+ some kernel versions). Backport of upstream patch for version 1.26.
+ Solves: #628919 for version 1.24. Closes: #689012
+
+ -- Joachim Wiedorn ad_deb...@joonet.de Fri, 16 Nov 2012 10:01:01 +0100
+
chrony (1.24-3.1) unstable; urgency=low
* Non-maintainer upload.
diff -urN chrony-1.24-old/rtc_linux.c chrony-1.24/rtc_linux.c
--- chrony-1.24-old/rtc_linux.c 2010-02-04 13:07:19.0 +0100
+++ chrony-1.24/rtc_linux.c 2012-11-16 08:56:27.227441065 +0100
@@ -541,63 +541,8 @@
int
RTC_Linux_Initialise(void)
{
- int major, minor, patch;
char *direc;
- /* Check whether we can support the real time clock.
-
- Linux 1.2.x - haven't checked yet
-
- Linux 1.3.x - don't know, haven't got a system to look at
-
- Linux 2.0.x - For x=31, using any variant of the adjtimex() call
- sets the kernel into a mode where the RTC was updated every 11
- minutes. The only way to escape this is to use settimeofday().
- Since we need to have sole control over the RTC to be able to
- measure its drift rate, and there is no 'notify' callback to warn
- you that the kernel is going to do this, I can't see a way to
- support this.
-
- Linux 2.0.x - For x=32 the adjtimex()/RTC behaviour was
- modified, so that as long as the STA_UNSYNC flag is set the RTC
- is left alone. This is the mode we exploit here, so that the RTC
- continues to go its own sweet way, unless we make updates to it
- from this module.
-
- Linux 2.1.x - don't know, haven't got a system to look at.
-
- Linux 2.2.x, 2.3.x and 2.4.x are believed to be OK for all
- patch levels
-
- */
-
- SYS_Linux_GetKernelVersion(major, minor, patch);
-
- /* Obviously this test can get more elaborate when we know about
- more system types. */
- if (major != 2) {
-return 0;
- } else {
-switch (minor) {
- case 0:
-if (patch = 31) {
- return 0;
-}
-break;
- case 1:
-return 0;
-break;
- case 2:
- case 3:
- case 4:
- case 5:
- case 6:
- case 7:
- case 8:
-break; /* OK for all patch levels */
-}
- }
-
/* Setup details depending on configuration options */
setup_config();
diff -urN chrony-1.24-old/sys_linux.c chrony-1.24/sys_linux.c
--- chrony-1.24-old/sys_linux.c 2011-11-18 22:14:14.0 +0100
+++ chrony-1.24/sys_linux.c 2012-11-16 08:56:27.235460778 +0100
@@ -735,7 +735,12 @@
if (uname(uts) 0) {
LOG_FATAL(LOGF_SysLinux, Cannot uname(2) to get kernel version, sorry.);
}
- if (sscanf(uts.release, %d.%d.%d, major, minor, patch) != 3) {
+
+ /* default patch level if not defined */
+ patch = 0;
+
+ /* first check about kernel version */
+ if (sscanf(uts.release, %d.%d.%d, major, minor, patch) 2) {
LOG_FATAL(LOGF_SysLinux, Cannot read information from uname, sorry);
}
@@ -746,30 +751,8 @@
version_patchlevel = patch
Way for package chrony with its RC
Hello release team, hello John, I care about the package chrony: There is a new upstream version in unstable which didn't go into testing before freeze. But for some days there is a RC bug which should be solved. How is the right way to update the testing version? I could create an update of this package with the old upstream version 1.24. But it cannot be uploaded to unstable, right? --- Have a nice day. Joachim (Germany) -- 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/20121106200613.34e84...@jupiter.home
Bug#692921: Unblock: capi4hylafax/1:01.03.00.99.svn.300-18
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Hello release team,
please unblock package capi4hylafax.
The updated capi4hylafax 1:01.03.00.99.svn.300-18 fixes two RC bugs about
the same issue:
* Only suggest package isdnactivecards. Closes: #682135, #691863.
Could you unblock capi4hylafax 1:01.03.00.99.svn.300-18?
Details are in the attached debdiff.
unblock capi4hylafax/1:01.03.00.99.svn.300-18
Many thanks for your work,
---
Have a nice day.
Joachim (Germany)
diff -Nru capi4hylafax-01.03.00.99.svn.300/debian/changelog capi4hylafax-01.03.00.99.svn.300/debian/changelog
--- capi4hylafax-01.03.00.99.svn.300/debian/changelog 2012-06-18 21:10:11.0 +0200
+++ capi4hylafax-01.03.00.99.svn.300/debian/changelog 2012-11-04 10:02:35.0 +0100
@@ -1,3 +1,9 @@
+capi4hylafax (1:01.03.00.99.svn.300-18) unstable; urgency=low
+
+ * Only suggest package isdnactivecards. Closes: #682135, #691863.
+
+ -- Joachim Wiedorn ad_deb...@joonet.de Sat, 03 Nov 2012 22:03:33 +0100
+
capi4hylafax (1:01.03.00.99.svn.300-17) unstable; urgency=medium
* New maintainer (adopted).
diff -Nru capi4hylafax-01.03.00.99.svn.300/debian/control capi4hylafax-01.03.00.99.svn.300/debian/control
--- capi4hylafax-01.03.00.99.svn.300/debian/control 2012-06-18 21:10:11.0 +0200
+++ capi4hylafax-01.03.00.99.svn.300/debian/control 2012-11-02 22:02:03.0 +0100
@@ -11,8 +11,8 @@
Package: capi4hylafax
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, capiutils
-Recommends: hylafax-server, isdnactivecards
-Suggests: dialog
+Recommends: hylafax-server
+Suggests: dialog, isdnactivecards
Description: Faxing over CAPI 2.0 device
If you have working capi20 interface, use this package to send and
receive fax over capi. It can be used as a fax-modem for a
diff -Nru capi4hylafax-01.03.00.99.svn.300/debian/README.Debian capi4hylafax-01.03.00.99.svn.300/debian/README.Debian
--- capi4hylafax-01.03.00.99.svn.300/debian/README.Debian 2012-06-12 18:13:15.0 +0200
+++ capi4hylafax-01.03.00.99.svn.300/debian/README.Debian 2012-11-04 10:15:12.0 +0100
@@ -35,3 +35,20 @@
and edit it.
-- Lionel Elie Mamane lmam...@debian.org, Wed, 19 Mar 2008 10:36:26 +0100
+
+
+Additional package isdnactivecards:
+
+ With version -18 the package 'isdnactivecards' were defined only as
+ suggested package because of Debian Policy 2.2.1. This package is in
+ section contrib because it needs/uses non-free firmwares.
+
+ You should install 'isdnactivecards' only if want to use one of the
+ following (older) active ISDN cards:
+ - Eicon
+ - Eicon Diva
+ - IBM Active 2000
+ - ICN
+ - PCBIT-D
+
+ -- Joachim Wiedorn ad_deb...@joonet.de Sat, 03 Nov 2012 22:03:33 +0100
Re: Request for update of package capi4hylafax (with debdiff)
Hello, Julien Cristau wrote on 2012-10-11 22:02: Perhaps the package could give a hint about this useful change while starting the init script? Or give a hint while upgrading? Let dpkg's conffile prompt handle that... O.K. udevd-work [428]: kernel-provided name 'capi' and NAME='capi20' disagree, please use SYMLINK= or change the kernel to provide the proper name So you could leave the SYMLINK in place if you like, and drop the NAME= bit? No, I think that is not the best way. In wheezy the udev package do not create /dev/capi, but capiutils creates this device with its init script at boot time, which is absolutly ok. So I think it is the best to go the similar way with the symlink /dev/faxCAPI - /dev/capi20 to create it in the init script of capi4hylafax to get support of hylafax for the device faxCAPI. --- Have a nice day. Joachim (Germany) -- 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/20121015214710.2ac89...@jupiter.home
Re: Request for update of package capi4hylafax (with debdiff)
Hello Julien, Julien Cristau wrote on 2012-10-11 00:18: No. For a conffile change, you modify the file that's shipped in the package, and dpkg handles what happens with it on install. Then there is no way to only change the old log path into new log path. All the other options in this file are usually changed from the admin. Perhaps the package could give a hint about this useful change while starting the init script? Or give a hint while upgrading? You still haven't explained what exact warning you're talking about... Now I have checked this topic in detail. The warning is: udevd-work [428]: kernel-provided name 'capi' and NAME='capi20' disagree, please use SYMLINK= or change the kernel to provide the proper name But finally I have found this warning only comes in Debian Squeeze. In Testing/Wheezy the file /lib/udev/rules.d/50-udev-default.rules does not have the line for capi anymore and the warning is gone. But I am wondering why the udev config file of capi4hylafax does not triggering the same warning. For your info: the /dev/capi20 device will be created in the init script of the package capiutils. Because of this situation it would useful to create the needed link /dev/faxCAPI in the init script of capi4hylafax, too. And then the capi-fax solution can be used directly after capi4hylafax were installed. --- Have a nice day. Joachim (Germany) -- 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/20121011203738.77539...@jupiter.home
Re: Request for update of package capi4hylafax (with debdiff)
Hello Julien, thanks for your reply. Julien Cristau wrote on 2012-10-10 21:59: * Add postinst script to update logfile name and path in /etc/hylafax/config.faxCAPI. Closes: #647164 This is wrong, postinst doesn't get to modify a conffile. Does you mean, postinst is not allowed to change the default logging path in this config file? How would be the right way? With debconf? * Fix udev warning: create symlink /dev/faxCAPI with init script and remove udev rules file. Closes: #684741 Why is that symlink necessary, and what is the warning you're referring to? The warning appear while booting and udev will be started. But some weeks ago I have found that this warning still appears, because the first part of the udev rule for capi4hylafax is the same as a default udev rule in file /lib/udev/rules.d/50-udev-default.rules. Independent of the way: capi4hylafax have a default configuration which expect a device /dev/faxCAPI which must show to the device /dev/capi20. If you think both changes are unnecessary or insanely, then we don't need this update of the package for wheezy. --- Have a nice day. Joachim (Germany) -- 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/20121010231725.3f862...@jupiter.home
Request for update of package capi4hylafax (with debdiff)
Hallo, [now with debdiff as attachment] I took over the package capi4hylafax a very short time before freeze and my first package still need some fixes. Could you please allow updating the package in testing? Compared with version 01.03.00.99.svn.300-17 (in testing) the updated package have this changes: capi4hylafax (1:01.03.00.99.svn.300-18) unstable; urgency=low * Add postinst script to update logfile name and path in /etc/hylafax/config.faxCAPI. Closes: #647164 * Fix udev warning: create symlink /dev/faxCAPI with init script and remove udev rules file. Closes: #684741 * Only suggest contrib package isdnactivecards. Closes: #682135 -- Joachim Wiedorn ad_deb...@joonet.de Mon, 13 Aug 2012 17:57:37 +0200 I know these are all normal bugs, but especially the problem with the logfile (#647164) should be solved, because on small systems this could induce to full harddisk partition. So this bugfix would be important for all users in the next stable Wheezy. The other both bugs give always irritating warnings to users and should also be solved. I would be very appreciated if you allow this update. --- Have a nice day. Joachim (Germany) capi4hylafax-debdiff.log.gz Description: GNU Zip compressed data
Request for update of package capi4hylafax
Hallo, I took over the package capi4hylafax a very short time before freeze and my first package still need some fixes. Could you please allow updating the package in testing? Compared with version 01.03.00.99.svn.300-17 (in testing) the updated package have this changes: capi4hylafax (1:01.03.00.99.svn.300-18) unstable; urgency=low * Add postinst script to update logfile name and path in /etc/hylafax/config.faxCAPI. Closes: #647164 * Fix udev warning: create symlink /dev/faxCAPI with init script and remove udev rules file. Closes: #684741 * Only suggest contrib package isdnactivecards. Closes: #682135 -- Joachim Wiedorn ad_deb...@joonet.de Mon, 13 Aug 2012 17:57:37 +0200 I know these are all normal bugs, but especially the problem with the logfile (#647164) should be solved, because on small systems this could induce to full harddisk partition. So this bugfix would be important for all users in the next stable Wheezy. The other both bugs give always irritating warnings to users and should also be solved. I would be very appreciated if you allow this update. --- Have a nice day. Joachim (Germany) -- 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/20120814093050.14f18...@jupiter.home
hylafax: Update because of RC (for Wheezy)
Hello release team, I am still working on the package hylafax to resolve the RC bug. I want to create a patch in the next (few) days and then the package maintainer Giuseppe Sacco want to create an updated package for Wheezy. I hope that we have the chance to get hylafax into Wheezy? --- Have a nice day. Joachim (Germany) -- 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/20120630091732.76cd1...@jupiter.home
capi4hylafax: updating package before freeze
Hello release team, I have started my second try searching for a sponsor of my package capi4hylafax. See here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677433 The old maintainer allowed an NMU, see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653539#15 and after some mails in the last two weeks he allowed me to adopt his package because of lacking in time. Unfortunately it is very difficult to get a sponsor. But this package should be hardenend (#653539) and should work better together with hylafax. So it is an important step to move the updated package into the repository. What could I do that the package still go into unstable/testing before freeze? --- Have a nice day. Joachim (Germany) -- 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/20120621225257.449c3...@jupiter.home
Re: Some bugfixes for LILO to go into Squeeze [new DM]
Mehdi Dogguy me...@dogguy.org wrote on 2010-12-06 23:56: Yes. Sending us a debdiff before the upload would be appreciated. Thanks for your readiness. Now I have created a LILO package only with essential fixes and updates. I have appended the debdiff log. And here is the changelog: lilo (1:22.8-9) unstable; urgency=low * New maintainter. * debian/patches: - Remove patch 16_geometry.patch for inaccessible disks and add information in README.Debian about using of 'inaccessible' option. (Closes: #409285, #400642) - Fix script checkit for newer gcc. - Fix for use LVM volume as root device. (Closes: #398957) - Fix for better computing vmlinux size, upgrade hints in README.Debian. (fixing sporadic failures). * Fix hook scripts: check for /sbin/lilo. * Add lacking file disk.com for creating test floppy. * Add universal menu image for debian, remove menu image for sarge. Update of template, postinst and postrm. (Closes: #420587, #427507) * Set source format 1.0. Add README.source file. * Update watch file to new alioth project area. * debian/control: - Remove VCS urls and add new Homepage url. - Remove IA64 architecture (this is already status quo). - Remove double lines of Priority and Section. - Add package conflicts to grub-pc and grub-legacy. - Remove conflicts to manpages. - Bump to Standards-Version 3.9.1 (without changes). The new package files already can be found here: http://lilo.alioth.debian.org/debian-mentors/ Today I will upload the new package to mentors.d.o. I would be glad if the release team would accept this new package and let it go into squeeze. Have a nice day, Joachim (Germany) lilo-debdiff_22.8-9.log.gz Description: GNU Zip compressed data signature.asc Description: PGP signature
Some bugfixes for LILO to go into Squeeze [new DM]
Hello Release Team, the CTTE disposed some days before, that I am allowed to be the new DM for the package LILO: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587886#158 Now it would be possible to update the LILO package (based on lilo 22.8-8.3) with some bugfixes to work better within Squeeze. My question: If I create an updated LILO package for testing/squeeze, would the release team accept this new package and let it go into squeeze? I know we are in the deep freeze, but I had no possibility in the last months (see bug link above). Have a nice day, Joachim (Germany) -- 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/20101204222817.552b3...@jupiter.home
Request for unblocking: bugfixes for xfe filemanager
Hello, I know I'm very late, but the updated version of xfe is in unstable since three days with the exception of a few architectures, which are already built since two days but not moved into the repository: https://buildd.debian.org/status/package.php?p=xfe Would it possible to unblock xfe 1.32.1-6 which is currently in unstable, when all architectures finally be in the repository? Compared with version 1.32.1-4 (in testing) the new version have this updates: * update of german translation. * package xfe-themes as dependency of package xfe. (Closes: #570205) and resolved circular dependency. (Closes: #598843) * Fix: remove unsupported Bugs field in debian/control. (Closes: #591217) * Use correct upstream licenses in debian/copyright and use new format. * Fix: file-open error of program xfpack. (Closes: #593215) Because of the bugfixes it would be important for all user in the next stable Squeeze. Best Regards, Joachim (Germany) signature.asc Description: PGP signature
