Bug#429086: [php-maint] Bug#429086: please update/request removal of your package
On Fri, Jun 15, 2007 at 08:12:06PM +0100, Gerfried Fuchs wrote: Please either send the ftp team a removal request for your package if it isn't able to work with apache2, or update it to build (only) packages for apache2. You mean like Bug#428266 ? I should be processing those removals pretty soon now. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429064: linux-libc-dev: linux/types.h conflicts with sys/ustat.h
reopen 429064 thanks On Fri, Jun 15, 2007 at 09:22:12PM +0200, Aurelien Jarno wrote: The glibc is correct here. If you don't want to get the bug assigned on linux-2.6, then I am closing the bug. The reported problem does still exist, so closing this bug is shoving a real problem under the carpet because of disagreements amongst maintainers how to fix it. There are other (superior) way to deal with situations like this, I suggest you both talk to get to an agreement as to what the best technical fix would be... If that fails, you can invoke arbitration by the tech-ctte for example. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#416902: imapproxy: init script stop action fails
On Sat, Mar 31, 2007 at 12:09:59PM +0100, Sam Morris wrote: # /etc/init.d/imapproxy stop Not running: imapproxy. # ps 12192 PID TTY STAT TIME COMMAND 12192 ?Sl 0:06 /usr/sbin/imapproxyd -f /etc/imapproxy.conf - Does /var/run/imapproxy.pid exist, and if so, what does it contain? - With what version of the init script was imapproxy started? - What's the md5 of /etc/init.d/imapproxy? --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415954: closed by Jeroen van Wolffelaar [EMAIL PROTECTED] (Bug#415954: fixed in up-imapproxy 1.2.4-10.1)
On Wed, Mar 28, 2007 at 06:10:16AM +, Debian Bug Tracking System wrote: * Add code to initscript to not attempt to start a second version if already running, and to not fail if imapproxy is no longer running (also #415954) Actually, for start, using --pidfile --oknodo on start-stop-daemon --start would be a cleaner way to do this than the extra bit of code I myself introduced -- --pidfile on start will do the right thing in start-stop-daemon if combined with --oknodo. For stop a similar thing holds, s-s-d will also do nothing if the process already died, I didn't actually test what happens if the pidfile doesn't exist though. Note that the original had some 'sleep 1; kill' bits, s-s-d also has support for that -- but that's only really useful if imapproxy ever actually fails to obey a regular TERM signal, of which I have no indication. Please, pretty please, don't just /dev/null and || true so much in general, for most things you want to solve that way have a better way to deal with it. My mistake, something to fix post-etch (-10.1 is already unblocked despite of this). --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415954: Bug#416156: PID handling in init.d is fragile
On Wed, Mar 28, 2007 at 08:26:27AM +0200, José Luis Tallón wrote: Jeroen van Wolffelaar wrote: Uploaded as NMU, because I actually made some changes. Reviewed them. Gotta ACK, anyway. (You are right in the changes you made, I would have done it differently) That's of course fine, your decision as maintainer. Changes: - function Daemonize ( const char* pidfile ); Fine. I did put the function back where it was though, instead of moving it way below, because the stuff in between can hang (for example, when failing to connect, it'll indefinitely retry every 15 seconds, causing 'start' to hang). Yup. I noticed that. From my POV, it is related to a misconfiguration of the server --- being configured to connect to a nonexistent/malfunctioning IMAP server. However, I do realize it could hang the booting process, so it should be fixed. ACK to your solution It's a misconfiguration, sure, but one that happens on default install (out of the box imapproxy is misconfigured? Well, it was in my case, but probably related to the fact that I don't actually have any imap server running on my test machine :) In any case, yeah, the problem is that start should simply never hang. Moving Daemonize to later on was not related to this RC bug. Putting it in its own function isn't either, but is pretty harmless, so ok. It does allow to move where Daemonize is called easily ;) - added support for the -p pidfile option Cool. There was a buglet here -- you didn't initialize the var and then only overwrote it with the default if it started with a nulbyte. I changed that to simply always initialize it to the default. Indeed. I know better than to have a variable unitialized, BUT I followed upstream's style here (the same pattern as with the configfile) -- I am aiming for inclusion of this by now HUGE patch, anyway... Yes, but in that case, you failed to properly copypaste the full thing -- upstream *does* set the first byte of ConfigFile to \0, you didn't copy that bit. You also didn't completely copy the logging to be analogous. I have tested starting / restarting / stopping / re-stopping Added code to not actually fail on second start / fail on second stop that I had already prepared. It now should really work fine in all cases. I also removed dead code from checking the exit state of a 'true'. I removed the || true so that the script just fails right there when it eh, fails. ACK. I will re-check the Developer's Reference for mandated/recommended messages and initscript behaviour in those cases not covered by the Policy. I'm not so sure either dev-ref or policy are very verbose on this, it'd be good for someone to look into this at some point... But world peace would also be nice :). Comments? I'll be up until late... This late :)? Wll... not today :-\ Tsk tsk :-P. Anyway, thanks a lot for your work on the pidfile handling, it was convenient to only need to verify, and not really write it all. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415954: Bug#416156: PID handling in init.d is fragile
On Wed, Mar 28, 2007 at 05:01:09PM +0200, José Luis Tallón wrote: Jeroen van Wolffelaar wrote: It's a misconfiguration, sure, but one that happens on default install (out of the box imapproxy is misconfigured? Well, it was in my case, but probably related to the fact that I don't actually have any imap server running on my test machine :) Well, I do. But I did test that case (pointing to a non-existant server) Imapproxy's configuration process does ask you for a server, so a misconfiguration there is certainly due to the user. Fwiw, I was never asked anything. But in the chroot in question I might have debconf set to non-interactive or at least high priority. Anyway, there's no guarantee for any admin to ever see whatever question you try to ask. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415954: [EMAIL PROTECTED]: Re: Bug#416156: PID handling in init.d is fragile]
Oops, I actually NMU'd for this bug (#415954), not for #416156.
--Jeroen
--
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
---BeginMessage---
On Tue, Mar 27, 2007 at 11:53:42PM +0200, Jeroen van Wolffelaar wrote:
On Tue, Mar 27, 2007 at 10:54:58PM +0200, José Luis Tallón wrote:
Jeroen van Wolffelaar wrote:
Package: imapproxy
Version: 1.2.4-10
Severity: important
The pid-handling of imapproxy is pretty fragile, as documented in
#369020 amongst others. The current workaround of writing a new pidfile
after start based on 'ps ax' output is, eh, fragile at best, and
actually pretty bad.
The proper solution would be to patch imapproxy so that it writes out a
pidfile itself, like proper daemons should.
Fixed. Will submit the patch ASAP
Why didn't you attach it? I'm pretty busy tomorrow, and want to get this
fixed ASAP. I mean, the plan is to release this weekend...
NMU'd, based on your patch. See attachment for diff.
--Jeroen
--
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
diff -u up-imapproxy-1.2.4/include/imapproxy.h up-imapproxy-1.2.4/include/imapproxy.h
--- up-imapproxy-1.2.4/include/imapproxy.h
+++ up-imapproxy-1.2.4/include/imapproxy.h
@@ -172,6 +172,10 @@
#define DEFAULT_CONFIG_FILE /etc/imapproxy.conf
#endif
+#ifndef DEFAULT_PID_FILE
+#define DEFAULT_PID_FILE /var/run/imapproxy.pid
+#endif
+
#define LITERAL_PASSWORD1
#define NON_LITERAL_PASSWORD0
#define UNSELECT_SUPPORTED 1
diff -u up-imapproxy-1.2.4/src/main.c up-imapproxy-1.2.4/src/main.c
--- up-imapproxy-1.2.4/src/main.c
+++ up-imapproxy-1.2.4/src/main.c
@@ -242,6 +242,7 @@
static int ParseBannerAndCapability( char *, unsigned int,
char *, unsigned int );
static void ServerInit( void );
+static void Daemonize( const char* );
static void Usage( void );
@@ -265,13 +266,13 @@
pthread_attr_t attr; /* generic thread attribute struct */
int rc, i, fd;
unsigned int ui;
-pid_t pid; /* used just for a fork call */
struct linger lingerstruct;/* for the socket reuse stuff */
int flag; /* for the socket reuse stuff */
ICC_Struct *ICC_tptr;
extern char *optarg;
extern int optind;
char ConfigFile[ MAXPATHLEN ]; /* path to our config file */
+char PidFile[ MAXPATHLEN ]; /* path to our pidfile */
#ifdef HAVE_LIBWRAP
struct request_info r; /* request struct for libwrap */
#endif
@@ -279,6 +280,9 @@
flag = 1;
ConfigFile[0] = '\0';
+/* initialize to default */
+strncpy( PidFile, DEFAULT_PID_FILE, sizeof PidFile -1 );
+
/*
* Ignore signals we don't want to die from but we don't care enough
* about to catch.
@@ -287,7 +291,7 @@
signal( SIGHUP, SIG_IGN );
-while (( i = getopt( argc, argv, f:h ) ) != EOF )
+while (( i = getopt( argc, argv, f:p:h ) ) != EOF )
{
switch( i )
{
@@ -298,7 +302,14 @@
syslog( LOG_INFO, %s: Using configuration file '%s',
fn, ConfigFile );
break;
-
+case 'p':
+/* user specified a pidfile */
+strncpy( PidFile, optarg, sizeof PidFile -1 );
+PidFile[ sizeof PidFile - 1 ] = '\0';
+syslog( LOG_INFO, %s: Using pidfile '%s',
+fn, PidFile );
+break;
+
case 'h':
Usage();
exit( 0 );
@@ -403,58 +414,7 @@
ServerInit();
-/* detach from our parent if necessary */
-if (! (getppid() == 1) ( ! PC_Struct.foreground_mode ) )
-{
- syslog( LOG_INFO, %s: Configured to run in background mode., fn );
-
- if ( (pid = fork()) 0)
- {
- syslog(LOG_ERR, %s: initial call to fork() failed: %s, fn, strerror(errno));
- exit( 1 );
- }
- else if ( pid 0)
- {
- exit( 0 );
- }
-
- if (setsid() == -1)
- {
- syslog(LOG_WARNING, %s: setsid() failed: %s,
- fn, strerror(errno));
- }
- if ( (pid = fork()) 0)
- {
- syslog(LOG_ERR, %s: secondary call to fork() failed: %s, fn,
- strerror(errno));
- exit( 1 );
- }
- else if ( pid 0)
- {
- exit( 0 );
- }
- if( chdir(/) 0 )
- {
- syslog(LOG_ERR, %s: chdir(\/\) failed: %s, fn,
- strerror(errno));
-exit( 1 );
- }
- if( (i=open(/dev/null,O_RDWR)) 0 )
- {
- syslog(LOG_ERR, %s: open(\/dev/null\) failed: %s, fn,
- strerror(errno));
-exit( 1 );
- }
- close(2); dup(i);
- close(1); dup(i);
- close(0); dup(i);
- close(i);
-}
-else
-{
- syslog( LOG_INFO, %s: Configured to run in foreground mode., fn );
-}
-
+Daemonize( PidFile );
SetBannerAndCapability();
@@ -723,7 +683,96 @@
* Function definitions.
*/
+/*++
+ * Function: Daemonize
+ *
+ * Purpose: Daemonize, closing all unneeded descriptors.
+ * Write the daemon's PID
Bug#415954: imapproxy: fails to start if already running
On Fri, Mar 23, 2007 at 05:30:02PM -0700, Steve Langasek wrote: Frankly, though, the init script has a *lot* of bad code that's trying to second-guess start-stop-daemon in ways that it shouldn't. The right way to fix this is to kill off all of this extra code, let s-s-d what it's designed to, and fix imapproxyd to not bail out with an error *after* it's returned control to the parent process... Right, except that I tried that, and it failed. s-s-d's coverage is unfortunately not good enough: #416179 -- making the s-s-d --backround --pid-file workaround useless in this case :( I see three options, all of them suck: (1) fix s-s-d (no way one week before release), (2) fix pidfile-writing imapproxy (ugh, but doable, and arguably the best longtime solution), (3) give up and revert to the sarge killall imapproxyd way of stopping the daemon The current way in this init.d script is worse than the killall imapproxyd thingy, it attempts to kill just one (random) instance of imapproxyd in a very special way (by first writing some found-via-ps PID to the pidfile and then using kill-by-pid...) But anyway it plainly fails at this too. As attachment, my NMU patch which would have fixed this whole mess if not for #416179. The biggest part of it is still applicable for the no-op behaviour of start stop when already started/stopped, and it fixes pid-file-removal. I think the best way forward would be to go for (2). --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415954: imapproxy: fails to start if already running
On Sun, Mar 25, 2007 at 05:53:51PM +0200, José Luis Tallón wrote: Jeroen van Wolffelaar wrote: On Fri, Mar 23, 2007 at 05:30:02PM -0700, Steve Langasek wrote: Frankly, though, the init script has a *lot* of bad code that's trying to second-guess start-stop-daemon in ways that it shouldn't. The right way to fix this is to kill off all of this extra code, let s-s-d what it's designed to, and fix imapproxyd to not bail out with an error *after* it's returned control to the parent process... Right, except that I tried that, and it failed. s-s-d's coverage is unfortunately not good enough: #416179 -- making the s-s-d --backround --pid-file workaround useless in this case :( I see three options, all of them suck: (1) fix s-s-d (no way one week before release), (2) fix pidfile-writing imapproxy (ugh, but doable, and arguably the best longtime solution), As in save the recycler thread's PID instead of any other ? I already have a version which daemonizes as late as possible (i.e. just before launching threads). It does help a bit in the sense that imapproxy will abort execution before dettaching from the parent (s-s-d in this case), but not more. I think the pid of the process right after the second fork in src/main.c is the one you want. imapproxy should have support to write down that process id to a file, for example, to a configurable place (like pidfile /var/run/imapproxy.pid in /etc/imapproxy.conf). If that'd be the default too, then it'd just work, even if the user doesn't upgrade his config. If imapproxy would do that, then the --background and --pid-file options to s-s-d can be dropped, and it'd all just work. If you can implement this minimally, I'll sponsor you, unless some RM tells that even this change would be too intrusive. (3) give up and revert to the sarge killall imapproxyd way of stopping the daemon The current way in this init.d script is worse than the killall imapproxyd thingy, it attempts to kill just one (random) instance of imapproxyd in a very special way (by first writing some found-via-ps PID to the pidfile and then using kill-by-pid...) But anyway it plainly fails at this too. Unfortunately, yes. This initscript has become a pile of patches one of top of the other. A rewrite I have done (reverting to the new LSB-compliant /etc/init.d/skeleton) doesn't work much better, either. In fact, it is unable to even start imapproxy as it is right now [launching 'manually' does work] the killall imapproxyd is still the plan B I'd say. As attachment, my NMU patch which would have fixed this whole mess if not for #416179. The biggest part of it is still applicable for the no-op behaviour of start stop when already started/stopped, and it fixes pid-file-removal. I think the best way forward would be to go for (2). If you elaborate a bit more on this, I can get it done tonight, I think. See above for what I think should be implemented. Otherwise, please feel free to contribute whatever you see fit. My current set of changes just move the daemonization code into a function of its own and call it just before pthread_create. I don't understand, but I'm not sure it matters at this point. You might want to send a patch of your current changes to me or so, so that I can understand, but I don't think this is some change to consider right now. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413968: fixed in clamsmtp 1.8-3
On Fri, Mar 09, 2007 at 03:00:52PM -0800, Steve Langasek wrote: On Fri, Mar 09, 2007 at 04:43:32PM -0600, Chad Walstrom wrote: Steve Langasek [EMAIL PROTECTED] wrote: Um, either the fix is wrong, or the description of the problem is wrong. Pre-Depends are irrelevant to postinst operation, they only matter if you need the other package from the *pre*inst. You're also supposed to discuss Pre-Depends on -devel before adding them... Well, then let's have the ftpmasters drop the package. If that's too late, I'll upload a roll-back. Yes, by the time I get any mail about it, it's too late. :) Not really sure what's up with ftpmaster@ in cc, but I'm assuming it's no longer relevant. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406465: more details needed please (zone data)
On Fri, Feb 16, 2007 at 09:10:31PM +0100, bert hubert wrote: Jeroen (and Bas I assume), Can you provide me with a copy of your problematic a-eskwadraat zone? See attachment. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl ; $Id: db.nl.a-eskwadraat 2753 2007-01-18 14:32:37Z root $ ; Zone file for A-Eskwadraat.nl ; ; rewrite door jeroen, 2 april 2002 $TTL 1D @ IN SOA ns.A-Eskwadraat.nl. sysop.A-Eskwadraat.nl. ( 2007011301 ; serial 6H ; refresh, seconds 1H ; retry, seconds 4W ; expire, seconds 1D ); minimum, seconds ; ; rewrite door jeroen, 2 april 2002 @ TXT ( Study Association A-Eskwadraat Princetonplein 5 NL-3584 CC Utrecht +31-30-253-4499 ) LOC 52 5 14 N 5 9 56 E 50m 10m 30m 50m ; de primary nameserver NS ns ; de primary mail exchanger MX 10 mail ; en de vaste backup MX 20 mail.wolffelaar.nl. ; NS en MX records MOETEN naar een A wijzen (dus geen CNAME) ns A 131.211.39.72 mailA 131.211.39.72 ; VPN stuff vpn-tunnel A 131.211.39.77 vpnsCNAME @ vpn CNAME @ ; Aliassen voor sevices die over VPN moeten ftp CNAME vpn-tunnel imapCNAME vpn-tunnel pop3CNAME vpn-tunnel homeCNAME vpn-tunnel homes CNAME vpn-tunnel homedirsCNAME vpn-tunnel ; @ heeft al records, kan dus geen CNAME zijn. @ A 131.211.39.72 ; *.a-eskwadraat.nl verwijst nu naar square * CNAME @ ; Voor DOMjudge/escapade: ;judge 15 CNAME madeleine.students.cs.uu.nl. ; Erik en Judith erikA 83.83.35.241 ; Kerberos _kerberos TXT A-ESKWADRAAT.NL _kerberos._udp SRV 0 0 88 euclides.localdomain. _kerberos._tcp SRV 0 0 88 euclides.localdomain. ; backup NS: @ NS ns1.xel.nl. NS ns3.xel.nl.
Bug#406465: [bind backend] TXT record parsing overflow with special characters
On Sat, Feb 10, 2007 at 11:13:11AM +0100, Jeroen van Wolffelaar wrote: An option, therefore, is to have a pdns uploaded without the bind backend, and a NEWS.Debian stating that sorry, no bind backend available, because it's not of release quality or something. Since other than our brief attempt at using pdns-with-bind-backend, I'm not having any experience with pdns, I don't feel comfortable making this change (and decision) myself, it's also pretty invasive so not typically something to do in a NMU. Maintainers, what's the status? As it stands now, powerdns runs the risk of being removed from testing and that way not making it into etch. If you'd give your opinion on whether or not removing the bind backend would be an acceptable solution, someone could make an upload of it. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406465: [bind backend] TXT record parsing overflow with special characters
On Sat, Feb 10, 2007 at 01:09:19AM +0100, Moritz Muehlenhoff wrote: Jeroen van Wolffelaar wrote: Package: pdns-server Version: 2.9.20-7 Severity: serious Tags: security (serious because what I see looks like a buffer overflow, however, I didn't look into the code yet, so I make no claims as to whether this is exploitable) Despite having a team in the maintainer field and being RC this bug log shows no visible reaction since a month. If it's unmaintained we shouldn't include it in Etch. One note, for all the bugs that I reported, it seemed limited to the bind backend, and one not-yet-reported bug about it is that it actually often 'forgets' zones too (not reported yet because I wanted to try to reproduce on etch instead of on sarge, I will report it this weekend). Reportedly, the other backends work just fine, and also, those are the backend configuration in which pdns sees wide deployment (the usecase for pdns with bind backend is pretty limited). An option, therefore, is to have a pdns uploaded without the bind backend, and a NEWS.Debian stating that sorry, no bind backend available, because it's not of release quality or something. Since other than our brief attempt at using pdns-with-bind-backend, I'm not having any experience with pdns, I don't feel comfortable making this change (and decision) myself, it's also pretty invasive so not typically something to do in a NMU. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318123: Patch insufficient
severity 318123 important
thanks
On Sat, Dec 09, 2006 at 11:36:02AM -0500, Michael Stone wrote:
The best solution for now is probably just to conflict with
libpam-opensc
NMU'd with this 'solution' -- downgrading this bug and its sister one
accordingly. I don't consider this bug adequately solved, but this
solution IMHO trumps having nothing at all and hence no xlock in etch.
NMU patch attached.
--Jeroen
--
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
diff -u xlockmore-5.22/debian/control xlockmore-5.22/debian/control
--- xlockmore-5.22/debian/control
+++ xlockmore-5.22/debian/control
@@ -10,7 +10,7 @@
Depends: ${shlibs:Depends}
Suggests: fortune
Recommends: libpam-modules
-Conflicts: xlockmore, libpam-modules ( 0.76-13.1), xbase ( 3.3.2.3a-2)
+Conflicts: xlockmore, libpam-modules ( 0.76-13.1), xbase ( 3.3.2.3a-2),
libpam-p11, libpam-opie
Replaces: xlockmore
Provides: xlockmore
Priority: optional
@@ -31,7 +31,7 @@
Depends: ${shlibs:Depends}
Suggests: fortune
Recommends: libpam-modules
-Conflicts: xlockmore-gl, libpam-modules ( 0.76-13.1), xbase ( 3.3.2.3a-2)
+Conflicts: xlockmore-gl, libpam-modules ( 0.76-13.1), xbase ( 3.3.2.3a-2),
libpam-p11, libpam-opie
Replaces: xlockmore-gl
Priority: extra
Description: Lock X11 display until password is entered.
diff -u xlockmore-5.22/debian/changelog xlockmore-5.22/debian/changelog
--- xlockmore-5.22/debian/changelog
+++ xlockmore-5.22/debian/changelog
@@ -1,3 +1,11 @@
+xlockmore (1:5.22-1.2) unstable; urgency=high
+
+ * Non-Maintainer Upload to address RC bug
+ * Add conflicts on libpam-opie and libpam-p11, mitigating a potential
+security issue (addressing: #318123, #399003)
+
+ -- Jeroen van Wolffelaar [EMAIL PROTECTED] Wed, 17 Jan 2007 01:49:41 +0100
+
xlockmore (1:5.22-1.1) unstable; urgency=medium
* Non-maintainer upload, BSP Zurich/Switzerland
Bug#405980: phpbb2: CVE-2006-6839 to -6841: vulnerabilities fixed in phpbb 2.0.22
On Sat, Jan 13, 2007 at 11:07:48PM +0100, Thijs Kinkhorst wrote: I think this is it. Jeroen: opinions on what to upload? I'd include all, although I'm not convinced all are really exploitable the fixes are harmless and with webapps like this it's hard to tell for sure something is *not* exploitable -- so many potential entry points to code. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406465: [bind backend] TXT record parsing overflow with special characters
Package: pdns-server Version: 2.9.20-7 Severity: serious Tags: security (serious because what I see looks like a buffer overflow, however, I didn't look into the code yet, so I make no claims as to whether this is exploitable) Having a TXT record in a bind-backend zone file that contains a parentizes ( character, causes all kinds of weird things. Firstly, the zone fails to serve. Syslog says: Jan 11 11:40:47 foo pdns[29515]: Zone 'a-eskwadraat.nl' (/etc/powerdns/zonefiles/db.nl.a-eskwadraat) reloaded but all queries including zone transfers result in servfail: Jan 11 11:40:47 foo pdns[29515]: Not authoritative for 'foo.a-eskwadraat.nl', sending servfail to 127.0.0.1 (recursion was desired) After replacing foo TXT ( with foo TXT paren-open and reloading, I get the following: | foo:/etc/powerdns# dig foo.a-eskwadraat.nl TXT @localhost | | ; DiG 9.3.3 foo.a-eskwadraat.nl TXT @localhost | ; (1 server found) | ;; global options: printcmd | ;; Got answer: | ;; -HEADER- opcode: QUERY, status: NOERROR, id: 8804 | ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 | | ;; QUESTION SECTION: | ;foo.a-eskwadraat.nl. IN TXT | | ;; ANSWER SECTION: | foo.a-eskwadraat.nl.3600IN TXT paren-open | foo.a-eskwadraat.nl.3600IN TXT foo a 1.2.3.4\010@ ns | ns1.xel.nl. ns ns3.xel.nl.\010$ttl 1d@ in soa ns.a-eskwadraat.nl. | sysop.a-eskwadraat.nl. ( 2006110910 6h 30m 4w 1d This is interesting, because the data listed here comes from the *old* zonefile (afaics). Also, of course the TXT record shouldn't suddenly contain literal zonefile data like this. Powerdns should really treat such TXT record strings as opaque strings, and not treat characters in them specially. --Jeroen -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393974: Unsatisfiable build-depends: gal0.x
Package: gabber
Severity: serious
- Forwarded message from Jeroen van Wolffelaar [EMAIL PROTECTED] -
Date: Wed, 18 Oct 2006 15:24:38 +0200
From: Jeroen van Wolffelaar [EMAIL PROTECTED]
To: Goedson Teixeira Paixao [EMAIL PROTECTED]
Cc: Jeroen van Wolffelaar [EMAIL PROTECTED]
Subject: Re: RM: gal0.x -- RoQA; orphaned, obsolete GNOME 1 package, no
significant revdeps
Message-ID: [EMAIL PROTECTED]
On Wed, Oct 18, 2006 at 09:17:43AM -0300, Goedson Teixeira Paixao wrote:
Em Ter, 2006-10-17 às 20:14 +0200, Jeroen van Wolffelaar escreveu:
And gabber... and gabber2 isn't ready yet for release. Interestingly,
only a build-dependency though, not a runtime dependency.
What's with that?
It's been linked statically to libgal. The previous maintainer decided
to do this because libgal changed too fast and prevented gabber from
entering testing and I forgot to undo this.
I see.
The only functions it uses from libgal are
e_utf8_{from,to}_locale_string. I think the best solution for this would
be copying the code for these functions from libgal into gabber in order
to upload it without this dependency. What do you think?
Surely such functionality can be achieved with glibc? Anyway, if it's
indeed only these two functions, I'll not hold off removing gal0.x over
it, and indeed a solution such as the one you suggest should be
implemented for gabber.
Thanks,
--Jeroen
--
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
- End forwarded message -
--
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393763: Obsolete build-dependency
Package: libgtk-perl Severity: serious libcapplet1-dev was just removed. So now: libgtk-perl has an unsatisfied build-dependency: libcapplet1-dev (= 1:1.5.11-11) There are no run-time dependencies, so I hope the fix is as easy as dropping this build-dependency. --Jeroen -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-3-k7 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393083: Hijacked website
Package: apache2 Version: 2.0.54-5sarge1 Severity: critical Tags: security To reproduce, go to http://cabal.debian.net You will be greeted by: If you can see this, it means that the installation of the Apache web server software on this system was successful. Further on, on the page you deny as packagers being involved in this website. However, it is common knowledge that the cabal always denies being involved and refers to others (like in this case, the so called but nameless person responsible for maintaining this server) for anything done. Therefore, I don't believe you. Anyways, based on the recent bug count, I can't believe anyone would have made a succesful installation anyway. There must be some higher power and/or black helicopters involved. I hereby strongly request you to restore this website. Kthxbye, --Jeroen -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-3-k7 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages apache2 depends on: ii apache2-mpm-worker2.0.54-5sarge1 high speed threaded model for Apac -- no debconf information -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392260: Makes other bluetooth apps stop working
Package: bluemon Version: 1.3-1.2 Severity: serious In its default install, bluemon hooks into the bluetooth stack with a fake macaddress, causing at least kbluetoothd to stop working at all. One could argue it's either of the two, and that by installing bluemon you want it as a service, but... in the default install, it doesn't work anyway (needs configuration), also, I do happen to believe that if bluemon is conflicting with the proper working of kdebluetooth, it should either conflict, or probably better, just not be enabled by default and list appropriate warnings in /etc/default/bluemon on what enabling would entail. --Jeroen -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages bluemon depends on: ii bluez-utils 3.5-1 Bluetooth tools and daemons ii libbluetooth23.5-1 Library to use the BlueZ Linux Blu ii libc62.3.6.ds1-4 GNU C Library: Shared libraries ii libdbus-1-3 0.92-2 simple interprocess messaging syst bluemon recommends no packages. -- no debconf information -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#267040: Is a warning really adequate?
reopen 267040 thanks On Sat, Aug 19, 2006 at 04:36:42PM +0200, Jeroen van Wolffelaar wrote: What do you think about this? I do not feel that my concerns have been adressed. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385486: Upgrade
severity 385486 normal thanks On Thu, Sep 21, 2006 at 03:25:47PM -0400, Filipus Klutiero wrote: severity 385486 serious thanks The severity justification for this bug is innappropriate. However, the severity looks correct considering that, unless someone knows differently, removing the binaries on these archs is the preferred way to allow mcvs to be updated in testing, which is needed to fix serious #346164, at least. Which doesn't make this bug serious. Please refrain from changing severities like this, severities are not transitive. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388708: apt: Upgrading to this version makes status file unparseable
On Sun, Oct 01, 2006 at 12:04:48AM +0200, Michael Vogt wrote: --- apt-pkg/tagfile.h 2006-09-30 20:50:41 + +++ apt-pkg/tagfile.h 2006-09-30 21:35:25 + @@ -77,6 +77,7 @@ unsigned long Size; bool Fill(); + bool Resize(); This would (unnecessarily) change the ABI of libapt, requiring a shlibs versioned bump. Fill() neither should've been part of the ABI (it makes no sense to use it externally), but it is at the moment. This symbol should instead be placed in a private: section of the class (without any explicit definition, symbols are public). Otherwise, the patch logic is as far as I can see, correct. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390523: Obsolete and uninstallable
Package: kernel-patch-ltt Severity: serious This package depends on kernel-patch-relayfs, which has been removed, because 2.4 kernels are being removed from unstable. This makes this kernel patch package uninstallable. Since this package is not usable for 2.6, I guess it should be removed altogether. I don't know whether this means that the whole of ltt should be removed or just this particular package: if all of ltt needs to be removed, please reassign this bug to ftp.debian.org requesting ltt's removal. If just this patch needs to be removed, please stop building it from debian/control and debian/rules, and upload this new revision. --Jeroen -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377560: More direct replacement examples
severity 377560 normal thanks On Fri, Jul 14, 2006 at 01:59:27PM -0700, Walter Landry wrote: Jeroen van Wolffelaar wrote: On Sun, Jun 04, 2006 at 02:37:45PM -0700, Josh Triplett wrote: jikes-sun implements a javac compiler, and uses the Sun JDK. This is indeed as far as I can see a violation of Sun's license to do, it's however a bug in jikes-sun: jikes-sun is the package combining technology in a way that's not allowed by the license of one of the used packages. This was already a problem before the DLJ, also the old Sun Java license didn't allow to do so. Please do Cc me if you want me to recieve updates, I'm not the maintainer of this package, and didn't read this followup until Steve Langasek pointed it out to me. This is not actually a bug, since javac does not use sun-java5, but blackdown's distribution. That makes any issues with jikes-sun wholly separate from the sun-java5 packages. The relevant part of the EULA you get from blackdown is A.Software Internal Use and Development License Grant. Subject to the │ terms and conditions of this Agreement, including, but not limited to │ the Java Technology Restrictions of these Supplemental Terms, Sun grants │ you a non-exclusive, non-transferable, limited license without fees to │ reproduce internally and use internally the Software complete and │ unmodified for the purpose of designing, developing, and testing your │ Programs. I see no conflict with the end-user using jikes-sun in conjunction with the JDK to design, develop, and test programs. So I see no reason why this bug can not be closed. And the current dependencies don't make it co-installable with sun-java5 either, only with blackdown (and java-package generated Sun Java). Neither of those are a legal problem for personal use. Downgrading this bug, but leaving resolution to the maintainer. This question needs to be revisited when the package is updated. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#267040: Is a warning really adequate?
As I explained in my mail below, I have my doubt whether just a warning is an adequate resolution to this bug. I haven't entirely made up my mind though, because well, there is a warning and users sort of choose for themselves, but still, currently I tend to think it's not a good idea to allow *this* easily that users allow remote code execution. What do you think about this? --Jeroen - Forwarded message from Jeroen van Wolffelaar [EMAIL PROTECTED] - Date: Sat, 19 Aug 2006 13:16:54 +0200 From: Jeroen van Wolffelaar [EMAIL PROTECTED] To: Robert Millan [EMAIL PROTECTED], debian-gcc@lists.debian.org, debian-release@lists.debian.org Subject: Re: gcj and etch freeze Message-ID: [EMAIL PROTECTED] Resent-From: debian-release@lists.debian.org List-Id: debian-release.lists.debian.org On Sat, Aug 19, 2006 at 02:59:28AM -0700, Steve Langasek wrote: On Sat, Aug 19, 2006 at 11:42:03AM +0200, Robert Millan wrote: Last I knew, it still had serious security problems. Which ones? I can't see anything in the BTS. I wouldn't know them by bug number; previously though, the problem was that gcjwebplugin didn't have appropriate sandboxing. #267040: remote code execution hole due to lack of Java security manager This is 'fixed' by: - Shows warning before loading an applet (Closes: #267040, #301134) Which, IMHO, doesn't make this usable except in fully trusted environments where the browser is exclusively used to browse a fully trusted intranet where nobody can change web content that doens't already have root on your machine. Which is, basicly nowhere (IMHO, and barring myself misunderstanding something). The warning is talked about here: http://langel.wordpress.com/2006/06/05/gcjwebplugin-is-actually-worth-using/ (thanks Michael Koch for the link) I personally do not think we should offer this option to users, because users tend to trust sites easily (and they are too often asked about 'trusting' too, w.r.t. https websites, for example), even though the wording used is strong, and the consequence is arbitrary remote code execution. Anyway, I will followup to the bug in question for discussion about this issue. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] - End forwarded message - -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#376771: remove unused 2.4 images
On Fri, Aug 18, 2006 at 06:55:26PM +0200, maximilian attems wrote: retitle 376771 RM: kernel-image-2.4.27-2-* -- RoM thanks in accordance with the d-i team any 2.4 kernel-image package can be removed from unstable for all archs except i386 and m68k (both legacy archs :-P) this includes the following list of kernel-images: Package kernel-image-2.4.27-2-s390 Package kernel-image-2.4.27-2-s390-di Package kernel-image-2.4.27-2-s390-tape Package kernel-image-2.4.27-2-s390-tape-di Package kernel-image-2.4.27-2-s390x Package kernel-image-2.4.27-2-sparc32 Package kernel-image-2.4.27-2-sparc32-di Package kernel-image-2.4.27-2-sparc32-smp Package kernel-image-2.4.27-2-sparc64 Package kernel-image-2.4.27-2-sparc64-di Package kernel-image-2.4.27-2-sparc64-smp Package kernel-image-2.4.27-bast Package kernel-image-2.4.27-bast-di Package kernel-image-2.4.27-lart Package kernel-image-2.4.27-lart-di Package kernel-image-2.4.27-netwinder Package kernel-image-2.4.27-netwinder-di Package kernel-image-2.4.27-r3k-kn02 Package kernel-image-2.4.27-r3k-kn02-di Package kernel-image-2.4.27-r4k-ip22 Package kernel-image-2.4.27-r4k-ip22-di Package kernel-image-2.4.27-r4k-kn04 Package kernel-image-2.4.27-r4k-kn04-di Package kernel-image-2.4.27-r5k-cobalt Package kernel-image-2.4.27-r5k-cobalt-di Package kernel-image-2.4.27-r5k-ip22 Package kernel-image-2.4.27-r5k-ip22-di Package kernel-image-2.4.27-r5k-lasat Package kernel-image-2.4.27-riscpc Package kernel-image-2.4.27-riscstation Package kernel-image-2.4.27-sb1-swarm-bn Package kernel-image-2.4.27-sb1-swarm-bn-di Package kernel-image-2.4.27-xxs1500 the following meta packages: Package kernel-image-2.4-generic Package kernel-image-2.4-s390 Package kernel-image-2.4-s390x Package kernel-image-2.4-smp Package kernel-image-2.4-sparc32 Package kernel-image-2.4-sparc32-smp Package kernel-image-2.4-sparc64 Package kernel-image-2.4-sparc64-smp I assume this also includes: kernel-patch-2.4.27-s390 | 2.4.27-2 | unstable | source, all the -di packages were already included in #383546, the arm image in #383553, and so was the, here unmentioned, arm patch. kernel-patch-2.4.27-mips is also not mentioned? And what to do with kernel-patch-2.4.27-apus, kernel-patch-2.4-fasttraks150, kernel-patch-2.4-grsecurity and kernel-patch-2.4-lowlatency? So, you mention (excluding those packages already removed), source-package based: kernel-image-2.4.27-s390 kernel-image-2.4.27-sparc kernel-latest-2.4-alpha kernel-latest-2.4-s390 kernel-latest-2.4-sparc kernel-patch-2.4.27-mips I assume you also mean: kernel-patch-2.4.27-s390 kernel-patch-2.4.27-mips And I have no idea about: kernel-patch-2.4.27-apus kernel-patch-2.4-fasttraks150 kernel-patch-2.4-grsecurity kernel-patch-2.4-lowlatency Can you please provide a complete list, or if the original list *was* complete, confirm that? --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383487: parsing packages files: Reads from pipe results in corrupt data
On Thu, Aug 17, 2006 at 05:53:35PM +0200, Jeroen van Wolffelaar wrote: Package: python-apt Version: 0.6.19 Severity: serious I could reproduce this with 0.5.10 (sarge's version) of python-apt, compiled on unstable. 0.5.10 on stable does not exhibit this problem. So: env. apt python-apt result sarge sarge sarge ok sarge sarge sid? sarge sid sarge ? sarge sid sidbroken sid sarge sarge ? sid sarge sid? sid sid sarge broken sid sid sidbroken (env. = environment, 'the rest' (python, libc, etc)) This does not exclude the possibility that the problem is in libapt. Looking at the differences in tagfile.cc in apt, there are buffering/mmap changes made to the reading code, which is IMHO highly suspicious of the exhibited buggy behaviour. Also, in python-apt, there are no noteworthy changes that could have introduced this bug, although it's always a possibility that the code has always been wrong but only now triggered by the changes in apt. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377109: Remove cdrtools
tags 377109 moreinfo thanks On Fri, Aug 11, 2006 at 10:51:11PM +0200, Joerg Jaspert wrote: reassign 377109 ftp.debian.org retitle 377109 RM: cdrtools -- RoM: non-free, license problems thanks Hi guys, ok well, as JS stays with an interpretation of CDDL and GPL that the whole world does not follow (all wrong, of course :) ), lets go and fix this. The sane way is to remove cdrtools from Debian main (unstable) and add a free replacement, most possible a fork from the last free version (which had only the CDDL licensed build scripts, which can easily be replaced by some automake thing). If you want to join that effort - contact me. For Debian etch I dont think its a big problem right now, dependencies will stop it from getting removed before we release. There many reverse dependencies still, and there is no replacement at the moment nor dummy upgrade packages for users of tools like 'mkisofs'. Removing now would break too many things. Therefore, we cannot sanely remove it right now. One possibility is to do an epoched upload of the previous version, that doesn't have this controversial legal issue around it? It doesn't seem controversial to me either to apply code patches from upstream to this version if so needed, as the controversy doesn't include the code itself. This allows to not have this controversy hold etch hostage. For the record, I do not (yet) hereby judge on the legal controversy itself, there is no ftp-master position on the matter (yet). --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383487: parsing packages files: Reads from pipe results in corrupt data
reassign 383487 apt thanks On Fri, Aug 18, 2006 at 02:00:53PM +0200, Jeroen van Wolffelaar wrote: This does not exclude the possibility that the problem is in libapt. Looking at the differences in tagfile.cc in apt, there are buffering/mmap changes made to the reading code, which is IMHO highly suspicious of the exhibited buggy behaviour. Further tests showed that: - 0.6.45exp1 (which lists: apt-pkg/tagfile.cc: support not-mmapable files again) does not fix this issue - #275852 is not the same issue, and indeed, the patch does not resolve this issue. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#376777: parsing packages files: Reads from pipe results in corrupt data
The problem lies in the addition of several lines in
apt/apt-pkg/tagfile.cc that were added for the mmappable package file
case, but in the fix for #376777, were not put inside proper
ifstatements for the non-mmap case, and are actually broken in that
case (corruption every 64kB of package file).
This patch reverts to having really the pre-mmap code in cases where
mmap is not possible, as a more complete fix than the fix for #376777
(which I believe is incomplete and still results in broken behaviour,
though more subtly).
Well, patch, pseudo-code -- Map isn't in scope in Scan, so this code
doesn't compile. And passing it as parameter changes the API (why Scan
is in the API is unclear to me). Someone better aware of the logic
involved here should really take a look -- maybe those two changes in
Scan can actually really be reverted without bad effects.
--- apt-pkg/tagfile.cc 2006-07-27 00:51:47.0 +0200
+++ apt-pkg/tagfile.cc 2006-08-19 00:54:32.240562270 +0200
@@ -207,7 +207,7 @@
Stop = Section = Start;
memset(AlphaIndexes,0,sizeof(AlphaIndexes));
- if (Stop == 0 || MaxLength == 0)
+ if (Stop == 0 || (Map != NULL MaxLength == 0))
return false;
TagCount = 0;
@@ -238,7 +238,7 @@
Stop++;
}
- if ((Stop+1 = End) (End[-1] == '\n' || End[-1] == '\r'))
+ if (Map != NULL (Stop+1 = End) (End[-1] == '\n' || End[-1] == '\r'))
{
Indexes[TagCount] = (End - 1) - Section;
return true;
Thanks,
--Jeroen
--
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383487: parsing packages files: Reads from pipe results in corrupt data
Package: python-apt Version: 0.6.19 Severity: serious Please find attached a simple python script that can parse and print a package file, via a pipe using cat or directly with 'open()'. With open, the result will be identical to the original, as verifiable via 'diff'. However, using os.popen with cat will result in inserted newlines, which indicates that stanza's with packages are not read in correctly. In some bigger files, such as current i386 packages files, you'll also see partial reads of the long descriptions. So far, I can reproduce this with all Packages files in unstable/main, or basicly any packages file that has sufficient many entries. I cannot at first sight find and pattern, it's seemingly random, but it's reproducible to the exact same places when dealing with the same packages file. I've reproduced (actually, first encountered) this bug on the 0.6.19.dsa.1 backport as installed on merkel.debian.org (otherwise ia64 stable). The places where stanza's were broken up were identical there. On merkel this is with python 2.3, on my own system I could reproduce it with both python2.3 and python2.4. --Jeroen -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-3-k7 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages python-apt depends on: ii apt [libapt-pkg-libc6.3-6-3.1 0.6.45 Advanced front-end for dpkg ii apt-utils [libapt-inst-libc6. 0.6.45 APT utility programs ii libc6 2.3.6-19 GNU C Library: Shared libraries ii libgcc1 1:4.1.1-10 GCC support library ii libstdc++64.1.1-10 The GNU Standard C++ Library v3 ii python2.4.3-11 An interactive high-level object-o ii python-central0.5.5 register and build utility for Pyt python-apt recommends no packages. -- no debconf information -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl #!/usr/bin/python2.3 import os, sys, apt_pkg # Doesn't trigger bug: #file = open(sys.argv[1]) # Does trigger bug: file = os.popen(cat +sys.argv[1], 'r') parse = apt_pkg.ParseTagFile(file) while parse.Step() == 1: for k in parse.Section.keys(): print k + : + parse.Section.get(k) print
Bug#382956: Reassign
# way too early to remove still reassign 370436 mozilla thanks On Mon, Aug 14, 2006 at 08:02:51PM -0400, Filipus Klutiero wrote: Alexander Sack - Debian Bugmail a écrit : On Mon, Aug 14, 2006 at 06:34:24AM -0400, Filipus Klutiero wrote: Package: mozilla Severity: serious Mozilla applications are known to require a lot of maintainance, and this is particularly true for the huge Mozilla suite. The 6 Mozilla updates since Sarge's release should show that, each fixing an average of about 10 security vulnerabilities that got CVE IDs assigned. The difficulty of keeping Mozilla secure is expected to increase largely due to the end of upstream support, already effective. Considering the security track up to now in Sarge, and the important security drop expected, even if the grave bugs currently opened against Mozilla suite are resolved, the suite will most likely get to a point where it will be better to remove it from stable Etch than keeping it, which is not desirable. Instead, as there are alternatives to the Mozilla suite, packages depending on Mozilla should find alternatives or be removed, and then the Mozilla suite should be removed before Etch's release. Takuo, please reassign this to ftp.d.o unless you disagree. Takuo is MIA for this package. We are already taking care of this problem. Anyway, please push the ITP holder for seamonkey to finally upload his package [EMAIL PROTECTED] Thanks for the information about Takuo. seamonkey was already uploaded, but was rejected by ftp-master. I'm reassigning to ftp.d.o. ftp-master may choose to wait some time before proceeding, which could let seamonkey become an upgrade path. Otherwise, I think that removing Mozilla now won't break unstable too badly. The main problem is eclipse (#364368), which isn't in testing since a long time anyway. Note that there should be serious bugs against all source packages in testing depending on mozilla-browser, except for about 10 mozilla-locale packages. Please provide a transition package for mozilla-browser from seamonkey, as soon as (but no earlier than) seamonkey is an adequate replacement in Debian. Mozilla is a major package with over 35% installed base in popcon. It shouldn't just be removed and leaving users without an upgrade path. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368967: libgcj6-dev: placing jni.h in versioned subdirectory makes no sense
tags 368967 moreinfo thanks On Fri, Jun 02, 2006 at 07:21:25PM +0200, Matthias Klose wrote: reassign 368967 ftp.debian.org retitle 368967 RM: gcj-4.0 -- old gcj packages, replaced by gcj-4.1 There is still quite some packages reverse-depending on gcj-4.0, are you sure you want it removed now? --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#370295: More direct replacement examples
clone 370295 -1 retitle -1 Can only be used to utilize software in an illegal manner reassign -1 jikes-sun thanks On Sun, Jun 04, 2006 at 02:37:45PM -0700, Josh Triplett wrote: jikes-sun implements a javac compiler, and uses the Sun JDK. This is indeed as far as I can see a violation of Sun's license to do, it's however a bug in jikes-sun: jikes-sun is the package combining technology in a way that's not allowed by the license of one of the used packages. This was already a problem before the DLJ, also the old Sun Java license didn't allow to do so. Cloning and reassigning for this -- please ensure in your reply that you reply to the cloned bug, not the original. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#278527: fixed in pvpgn 1.6.4+20040826-2
reopen 278527 submitter 278527 ! thanks On Tue, Jul 12, 2005 at 04:32:33PM -0400, Philipp Kern wrote: * Addressed pvpgn-support in README.Debian (Closes: #278527) I'm sorry, but this is not an adequare resolution for this bug for a package in main. The package is disfunctional out of the box and can only work by getting external files of doubtful copyright either manually or via an installer script. While this might be acceptable for a package in contrib (if the files can be downloaded legally in some circumstances), it is not as long as this package is in main. Also, I think you should really research the copyright situation a bit better, in order to provide users of this package with adequate advice in the README what the concerns are with the support files, currently there's a bit of handwaving and the user is left on his own on this matter. While it's the user who is downloading the support files, I think Debian should only offer that option if that can be done legally in at least some circumstances. Thanks, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373245: Fails to get removed
Package: pvpgn Version: 1.7.9-2+b1 Severity: serious | The following packages will be REMOVED: | pvpgn | 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded. | Need to get 0B of archives. | After unpacking 2114kB disk space will be freed. | Do you want to continue [Y/n]? | (Reading database ... 18022 files and directories currently installed.) | Removing pvpgn ... | Stopping bnetd daemon: start-stop-daemon: nothing in /proc - not mounted? (Success) | invoke-rc.d: initscript pvpgn, action stop failed. | dpkg: error processing pvpgn (--remove): | subprocess pre-removal script returned error exit status 2 | | You are missing the pvpgn support files and daemon will not start without them. | Run pvpgn-support-installer or read /usr/share/doc/pvpgn/README.Debian | invoke-rc.d: initscript pvpgn, action start failed. | dpkg: error while cleaning up: | subprocess post-installation script returned error exit status 1 | Errors were encountered while processing: | pvpgn | E: Sub-process /usr/bin/dpkg returned an error code (1) This shouldn't happen, pvpgn should let itself being removed if the daemon is not running at all, and also equally when the support files were not (manually) added. --Jeroen -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367267: ftp.debian.org: Missing .orig.tar.gz files for dresden-ocl and libbsf-java
On Fri, Jun 02, 2006 at 01:34:56PM -0700, Steve Langasek wrote: AIUI, the proper fix for this is to do a reupload of the package with dpkg-buildpackage -sa, to get the orig.tar.gz re-tagged by dak. Except that doesn't work, last time I tried to fix a similar situation this way. Requires database fiddling or a new upstream version number. Fwiw, this is not a legal issue IMHO, since it's available in the archive, just at a different spot. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365533: [Secure-testing-team] Re: Bug#365533: CVE-2006-1896: Admin command execution
On Tue, May 30, 2006 at 09:55:16AM +0200, Thijs Kinkhorst wrote: On Sun, 2006-05-28 at 22:11 +0100, Steve Kemp wrote: Uploaded. Thanks! But... can't find the upload anywhere? Maybe something went wrong or am I looking the wrong way? I got a 'upload removed due to not being signed by gnupg/gpg' mail. So, it looks like something went wrong. Since I have internet again here in Mexico, I'll see whether I can do it tonight (but otoh... so much to do tonight in Mex. City). So Steve (or anyone), if you can sponsor, that's very much appreciated. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365533: [Secure-testing-team] Re: Bug#365533: CVE-2006-1896: Admin command execution
On Tue, May 30, 2006 at 06:21:39PM +0100, Steve Kemp wrote: On Tue, May 30, 2006 at 07:14:11PM +0200, Jeroen van Wolffelaar wrote: On Tue, May 30, 2006 at 09:55:16AM +0200, Thijs Kinkhorst wrote: On Sun, 2006-05-28 at 22:11 +0100, Steve Kemp wrote: Uploaded. Thanks! But... can't find the upload anywhere? Maybe something went wrong or am I looking the wrong way? I got a 'upload removed due to not being signed by gnupg/gpg' mail. So, it looks like something went wrong. Strange. I don't remember noticing an upload error, or a signing error. I've resigned + reuploaded for you. If it works great, if not I guess test that network access ;) Just ACCEPTED indeed. Must've been a magnetic sunstorm or so. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367504: sun-java5-bin: pre-installation script returned error exit status 10
On Tue, May 16, 2006 at 03:28:22PM +0200, Petter Reinholdtsen wrote: When trying to install sun-java5-jdk, the installation failed with subprocess pre-installation script returned error exit status 10 for sun-java5-bin. I have no idea what went wrong. This is the output from when I tried to install it. Hm, the problem is that the preinst tries to ask a debconf question, but that the actual templates are not included in this package. This is indeed a bug, thanks for finding it and reporting it. The solution is to either also ship the templates here, or simply drop the questioning -- because -bin depends on -jre, the license is shown and asked to be agreed upon anyway. I tend to go for the latter option. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365533: CVE-2006-1896: Admin command execution
tags 365533 patch
thanks
On Wed, May 03, 2006 at 10:56:33AM +0200, Thijs Kinkhorst wrote:
Thanks for the report. While I think that people who are admin can
already do a lot of damage and should hence be considered trusted,
executing php code is a step further in permissions and thus this can be
considered a security issue. I will look into a fix soon.
Patch (untested):
--- phpBB2/viewtopic.php2005-10-31 08:32:37.0 +0100
+++ phpBB2/viewtopic.php2006-05-15 08:25:12.0 +0200
@@ -1105,6 +1105,12 @@
{
// This was shamelessly 'borrowed' from volker at
multiartstudio dot de
// via php.net's annotated manual
+
+ // First, defuse fontcolor3, as it'd otherwise be arbitrary
code execution
+ if (!eregi(^[0-9a-f]+$, $theme['fontcolor3'])) {
+ $theme['fontcolor3'] = 'FFA34F';
+ }
+
$message = str_replace('\', '',
substr(@preg_replace('#(\(((?([^]+|(?R)))*)\))#se', @preg_replace('#\b(
. str_replace('\\', '', addslashes($highlight_match)) . )\b#i', 'span
style=\color:# . $theme['fontcolor3'] . \b1/b/span', '\\0'),
'' . $message . ''), 1, -1));
}
--Jeroen
--
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366484: ircp -r silently overwrites files
Package: openobex-apps Version: 1.2-2 Severity: serious Tags: security If you ircp -r, and someone sends you a file, the filename provided by the remote source is used -- even if the file still exists. The source has actually a TODO about this: //TODO! Rename file if already exist. (line 129, ircp_io.c) It think this is quite dangerous, because you could be doing ircp -r in your homedir, and get '.bashrc' or so accidently. Of course, risk is quite limited due to the need of physical proximity, but still. --Jeroen -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages openobex-apps depends on: ii libbluetooth1 2.25-1 Library to use the BlueZ Linux Blu ii libc6 2.3.6-7GNU C Library: Shared libraries ii libopenobex1 1.2-2 OBEX protocol library ii libusb-0.1-4 2:0.1.12-2 userspace USB programming library openobex-apps recommends no packages. -- no debconf information -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361874: libgnutls12: uninstallable due to Conflicts/Depends cycle with libtasn1-2
severity 361874 important thanks On Mon, Apr 10, 2006 at 06:08:19PM -0400, Aaron M. Ucko wrote: libgnutls12 depends on libtasn1-2, which however conflicts with libgnutls12 ( 1.3.5) as of version 0.3.1-1. As a result, (...) The libtasn1-2 upload with the problemetic conflict was reverted, so this is not currently an RC issue, or actually an issue at all. Since the conflicts will come back in due course, I'm leaving the bug open for now. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365225: NMU patch
Please find attached the patch for the NMU I'm uploading in a minute.
Thanks,
--Jeroen
--
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
diff -Nru /tmp/aUtNU0KhXf/usbmount-0.0.14/debian/changelog
/tmp/deduWrsWep/usbmount-0.0.14/debian/changelog
--- /tmp/aUtNU0KhXf/usbmount-0.0.14/debian/changelog2005-07-10
22:17:00.0 +0200
+++ /tmp/deduWrsWep/usbmount-0.0.14/debian/changelog2006-05-01
02:16:55.0 +0200
@@ -1,3 +1,14 @@
+usbmount (0.0.14-0.1) unstable; urgency=low
+
+ * Non-Maintainer Upload
+ * Change path of vol_id of udev to the new location in /lib/udev. Thanks to
+Eric Evans for the patch (Closes: #361351)
+- Minimum udev dependency now 0.084-2, first version to ship vol_id in
+ that location
+ * Fix udev rule syntax, patch by Eric Evans (Closes: #365225)
+
+ -- Jeroen van Wolffelaar [EMAIL PROTECTED] Sun, 30 Apr 2006 23:45:57 +
+
usbmount (0.0.14) unstable; urgency=low
* Upload sponsored by Rafael Laboissiere.
diff -Nru /tmp/aUtNU0KhXf/usbmount-0.0.14/debian/control
/tmp/deduWrsWep/usbmount-0.0.14/debian/control
--- /tmp/aUtNU0KhXf/usbmount-0.0.14/debian/control 2005-07-05
22:25:40.0 +0200
+++ /tmp/deduWrsWep/usbmount-0.0.14/debian/control 2006-05-01
02:02:15.0 +0200
@@ -8,7 +8,7 @@
Package: usbmount
Architecture: all
-Depends: udev (= 0.060-1), lockfile-progs
+Depends: udev (= 0.084-2), lockfile-progs
Description: automatically mount and unmount USB mass storage devices
This package automatically mounts USB mass storage devices (typically
USB pens) when they are plugged in, and unmounts them when they are
diff -Nru /tmp/aUtNU0KhXf/usbmount-0.0.14/usbmount
/tmp/deduWrsWep/usbmount-0.0.14/usbmount
--- /tmp/aUtNU0KhXf/usbmount-0.0.14/usbmount2005-07-08 18:51:02.0
+0200
+++ /tmp/deduWrsWep/usbmount-0.0.14/usbmount2006-05-01 01:48:06.0
+0200
@@ -36,8 +36,8 @@
}
-# Test if /sbin/vol_id is executable.
-test -x /sbin/vol_id || { log err cannnot execute /sbin/vol_id; exit 1; }
+# Test if /lib/udev/vol_id is executable.
+test -x /lib/udev/vol_id || { log err cannnot execute /lib/udev/vol_id; exit
1; }
# Default values for configuration variables.
MOUNTPOINTS=
@@ -85,10 +85,10 @@
# Test if the device contains a filesystem. If it doesn't, no
# further action is required, but calling vol_id has the side effect
# that the partition table is read and partition devices are created.
-if /sbin/vol_id $DEVNAME | egrep -q
'^ID_FS_USAGE=(filesystem|disklabel)$'; then
+if /lib/udev/vol_id $DEVNAME | egrep -q
'^ID_FS_USAGE=(filesystem|disklabel)$'; then
log debug $DEVNAME contains a filesystem or disklabel
- fstype=`/sbin/vol_id -t \$DEVNAME\`
+ fstype=`/lib/udev/vol_id -t \$DEVNAME\`
log debug $DEVNAME contains filesystem type $fstype
# Test if the filesystem type is in the list of filesystem
diff -Nru /tmp/aUtNU0KhXf/usbmount-0.0.14/usbmount.rules
/tmp/deduWrsWep/usbmount-0.0.14/usbmount.rules
--- /tmp/aUtNU0KhXf/usbmount-0.0.14/usbmount.rules 2005-07-08
19:08:16.0 +0200
+++ /tmp/deduWrsWep/usbmount-0.0.14/usbmount.rules 2006-05-01
02:06:16.0 +0200
@@ -1,6 +1,6 @@
# Rules for USBmount
-KERNEL=sd*, BUS==usb, ACTION==add,RUN+=/usr/share/usbmount/usbmount
add
-KERNEL=ub*, BUS==usb, ACTION==add,RUN+=/usr/share/usbmount/usbmount
add
-KERNEL=sd*, ACTION==remove, RUN+=/usr/share/usbmount/usbmount
remove
-KERNEL=ub*, ACTION==remove, RUN+=/usr/share/usbmount/usbmount
remove
+KERNEL==sd*, BUS==usb, ACTION==add,
RUN+=/usr/share/usbmount/usbmount add
+KERNEL==ub*, BUS==usb, ACTION==add,
RUN+=/usr/share/usbmount/usbmount add
+KERNEL==sd*, ACTION==remove,
RUN+=/usr/share/usbmount/usbmount remove
+KERNEL==ub*, ACTION==remove,
RUN+=/usr/share/usbmount/usbmount remove
Bug#364729: Should stop building libgnutls-dev and gnutls-bin
Package: gnutls12 Version: 1.2.9-2 Severity: serious gnutls12 builds libgnutls-dev and gnutls-bin, which are now also provided by gnutls13. gnutls12 got scheduled a number of binNMUs for the libtasn1-3 transition. This doesn't work now anymore, because of gnutls13 providing a newer version. gnutls12 will need a sourceful upload -- or removal once the gnutls13 transition is completed, of course. Thanks, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362051: RM: zope-testcase -- this product is included within Zope = 2.8
Package: zope-plonetestcase Severity: serious On Tue, Apr 11, 2006 at 02:00:20PM +0200, Fabio Tranchitella wrote: Package: ftp.debian.org Severity: normal Please, remove zope-testcase package: it is included with zope2.8, and zope2.7 will be soon removed from testing/unstable. Done, note that this broke zope-plonetestcase. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334633: FTBFS: Unsatisfiable build-dependency on kernel-headers-2.6.8-2-386
On Tue, Oct 18, 2005 at 02:47:44PM -0700, Matt Kraai wrote: hostap-modules-i386 fails to build: And fails to be useful in testing/unstable, because it's for 2.6.8. Anyway, Bastiaan Blank noted that this module is actually not needed anymore, as it's been integrated in upstream kernels. Can this package indeed be removed? Please reassign this bug to ftp.debian.org if this package is to be removed. If it can't/shouldn't, please let me know as soon as possible. Thanks, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361004: Please upgrade to using python 2.4
Package: carpaltunnel Severity: serious Python 2.1 and 2.2 are on the nomination of being removed. This includes by proxy python2.2-optik. Please use optparse which is in python itself as of 2.3. --Jeroen -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages carpaltunnel depends on: ii iproute20041019-3Professional tools to control the ii openvpn2.0-1sarge2 Virtual Private Network daemon ii python2.2 2.2.3dfsg-2sarge1 An interactive high-level object-o pn python2.2-optik Not found. -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#356372: FTBFS on mips, other !i386 nastiness
On Sat, Mar 11, 2006 at 03:07:56PM +, Martin Michlmayr wrote:
b) [i386] in a Depends/Suggests line is not supported.
(...)
And on i386:
dh_gencontrol
dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
dpkg-gencontrol: warning: can't parse dependency supercollider [i386
dpkg-gencontrol: error: error occoured while parsing Suggests
dh_gencontrol: command returned error code 2304
And this error is ignored, presumably because you fork a new make
without checking the error code of it. This is also a serious error.
--Jeroen
--
Jeroen van Wolffelaar
[EMAIL PROTECTED]
http://jeroen.A-Eskwadraat.nl
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#358073: lxdoom: no .orig.tar.gz file in the archive!
On Tue, Mar 21, 2006 at 02:49:20AM +, Martin Michlmayr wrote: Maybe I'm missing something, but afaict there is no .tar.gz file for lxdoom in the archive. If ftp-master cannot do something about this, can you please upload a new package and pass an option to dpkg-buildpackage so it'll include the tar ball. Unless you happen to have a newer upstream, this will be futile. According to the katie software, the .orig.tar.gz is fine -- this is because there is no constraint enforcing same component for the different source files. And indeed: /org/ftp.debian.org/ftp/pool/contrib/l/lxdoom/lxdoom_1.4.4.orig.tar.gz Unfortunately, woody still ships this .orig.tar.gz too. Other than really uploading a new upstream, this can only be fixed by some manual SQLing on ftp-master, if the core bug isn't fixed (and there isn't a patch yet, which would also be complicated, because of uniqueness-of-filenames assumptions). So the source is available, but not on the expected spot. This prevents (auto)building, and automatic source retrieval. Bottom line: by far easiest is to ensure you get a new upstream. There are bugreports on ftp.debian.org about this problem, but it's a very rare cornercase (non-new-upstream versions of packages moving from contrib to main and such), with a tricky fix. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357106: alsaconf modifies modules.conf unrelatedly
Package: alsa-utils Version: 1.0.8-4 Severity: grave (note, I'm running Sarge) Running alsaconf, my modules.conf was modified: -alias net-pf-10 off# IPv6 +# alias net-pf-10 off # IPv6 It did ask for modification of modules.conf, but not to actually enable IPv6 on my machine, something some services over here break under. alsaconf should definitely not modify a configuration file with totally unrelated modifications, without very clearly asking to. Also, there is no dry-run option what would list the proposed modifications, and alsaconf is very chatty. While nice, in most cases I guess it can be much less so, and actually with only slight modifications cause sound to work out-of-the-box: autodetected at bootup, without writing anything to a configuration file? Thanks, --Jeroen PS: I *do* like alsaconf, because it actually makes sound config very trivial (if you happen to know about alsaconf), thanks for that :) -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-k7 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages alsa-utils depends on: ii alsa-base 1.0.8-7 ALSA driver configuration files ii libasound2 1.0.8-3 ALSA library ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libncurses5 5.4-4Shared libraries for terminal hand ii module-init-tools 3.2-pre1-2 tools for managing Linux kernel mo ii modutils2.4.26-1.2 Linux module utilities ii pciutils1:2.1.11-15 Linux PCI Utilities ii whiptail0.51.6-20Displays user-friendly dialog boxe -- no debconf information -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349196: a fix for sudo in sarge
tags 349196 + patch thanks On Thu, Feb 09, 2006 at 05:28:30PM +0200, Mikko Rapeli wrote: This seems to work and allows me to use ethereal remotely through ssh again. The for loop was just copied from above and keepit changed to okvar, so this is pretty simple. We did go through all the bits and if clauses and tested the result manually. The manual page changes are pretty obvious too. I did not go through the list of environment variables mentioned on manual pages and 'sudo -V' when run as root, but perhaps the documentation is enough as this is only first aid for sarge. Thank you for preparing a patch. Bdale, Security team, what do you think about it? --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353277: Please reject to rule on the ndiswrapper question
On Tue, Feb 28, 2006 at 02:05:16PM +0100, Wouter Verhelst wrote: The correct way to proceed would seem to be a ruling by a body authorized to make authoritative interpretations of the Social Contract, or, failing that (since I believe we have no such body), a General Resolution. You (or whoever feels strongly about this) could also provide a motivation to ftpmaster@ why you believe so, and ask for reconsideration. Everybody, even the ftp-master team, can make mistakes, or be persuadated to change mind provided with a good argumentation. I also note that the only ftp-master team member that spoke up in this thread seems to be inclined to prefer contrib over main for this package. There was no mail at all to ftpmaster@ about this, nor a bugreport filed/reassigned to the ftp.debian.org pseudopackage. Shouldn't overruling of any sort only happen after talking to the involved parties failed to yield a satisfactionary response? C.f. Constitution 6.3.6: | Technical Committee makes decisions only as last resort. | | The Technical Committee does not make a technical decision until efforts | to resolve it via consensus have been tried and failed, unless it has | been asked to make a decision by the person or body who would normally | be responsible for it. Of course, this paragraph only applies if one assumes the (initial) authority to make the main vs contrib decision is with ftp-master, but I believe it is. --Jeroen Another FTP-Team member, who doesn't yet have an opinion on this matter, but hasn't been asked for one either -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#351950: Please use guile-1.6, not guile-core
Package: gnurobots Severity: serious I'm about to remove guile-core, because it's long since been superseded by guile-1.6 (#338407). It looks like this package manually has once already been built with guile-1.6 (i386 only of 1.0D-6), but that was due to the build environment of the uploader, and not fixed properly with build-depends. --Jeroen -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-k7 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345823: apt: Key error at year turnover resembles security problem, and may represent one
On Wed, Jan 04, 2006 at 02:41:30AM -0800, Joshua Rodman wrote: On Wed, Jan 04, 2006 at 03:01:35AM +0100, Jeroen van Wolffelaar wrote: Fwiw, the Release.gpg file contains two signatures now, both one with the 2005 key and the 2006 key, to have a short transition period. The archive still validates with the 2005 key, which isn't expired yet, and I think APT should not spread too worrysome errors at users while the archive can still be verified. Not to contradict you, since my understanding of these issues is strongly limited, but apt seems to think that it cannot validate the archive? I know, I said should, because I believe apt should deal with the multiple signatures correctly, instead of the current behaviour of (it seems) only looking at the last one and/or requiring all signatures to verify. Apt needs to be satisfied with just at least one of the multiple signatures verifying, so that there can be turnover periods, and for example third party repositories can have multiple signatures too, for certain circumstances. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336582: phpbb2 -6sarge2 ready for Security release (Was: Re: Bug#336582: phpbb2: New round of security issues)
On Wed, Dec 21, 2005 at 08:52:37PM +0100, Martin Schulze wrote: I've added CVE-2005-3536 Missing input sanitising of the topic type allows remote attackers to inject arbitrary SQL commands. ack. CVE-2005-3537 Missing request validation permitted remote attackers to edit private messages of other users. Edit, *and read*. to the advisory. Thanks a lot! I'll add those CVE id's to our svn for unstable and for any potential further stable update. Thank you for the continued hard work on security stuff, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336582: phpbb2 -6sarge2 ready for Security release (Was: Re: Bug#336582: phpbb2: New round of security issues)
On Tue, Dec 20, 2005 at 06:54:18AM +0100, Martin Schulze wrote: Thijs Kinkhorst wrote: On Mon, 2005-12-19 at 06:53 +0100, Martin Schulze wrote: Thanks. Could somebody explain the issues that were fixed which have no security relevance? From the changelog there are at least two of them. Could you please explain which ones? In the changelog that is in the mentioned package I can only see security-relevant changes. - fixed validation of topic type when posting. +// Debian: fix for [Sec] fixed validation of topic type when posting from 2.0.18 +$topic_type = ( in_array($topic_type, array(POST_NORMAL, POST_STICKY, POST_ANNOUNCE)) ) ? $topic_type : POST_NORMAL; Without this fix, SQL injection exists, as $topic_type is not escaped when the actual query is done. There is no CVE id for this issue. - fixed ability to edit PM's you did not send. PM == private message, kind of like a middle way of instant message and email. Edit, *and* read actually. So relevant for privacy, plus relevant because an attacker can then fake a post from a trustworthy person to someone else, with falsified, possibly harmful, information. The problem is simply lack of authentication for this particular page -- so it can be exploited by simple manipulating of the post id in the url to actually see (and edit) random private messages. There is no CVE id for this. These don't smell like security. There's also no bug report or cve name attached to them, so I don't know which issues they intend to fix if any. The issues were mentioned in the changelog, and as part of cvs commit messages. No more maintstream source of information (like, bugtraq or so) picked it up. Here are the descriptions for the advisory: (looks fine to me) In addition, we'd have: CVE-2005-: Missing input sanitizing of $topic_type in posting.php could lead to SQL injection while making a post. CVE-2005-: Missing authentication in the private messaging mechanism allows any user to read and edit any private message, including those sent by others than the user himself. On Tue, Dec 20, 2005 at 06:57:10AM +0100, Martin Schulze wrote: Since I've already moved the package into the security queue, we'll only mention this cve name in the advisory. In the sid version, however, please add the missing id to the changelog when you're doing the next upload. Ok, will do. On Tue, Dec 20, 2005 at 07:20:22AM +0100, Martin Schulze wrote: Jeroen van Wolffelaar wrote: All have security relevance, I just couldn't find and CVE id for three of the issues. If you can allocate CVE id's for them, we could provide descriptions? Or what do you prefer? It's extremely unlikely anyone else will go through the effort of getting one otherwise, as those are a bit older vulnerabilities. Hmm. For that I'd require a description of the problem (and a note about its impact). See above, we are not terribly fussed about whether or not these two issues will gain their own CVE id. We're working on getting upstream to get a better security policy, but it's hard. Thanks a lot, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342619: [exim] Potential logic error in retry handling for IPv4+IPv6 hosts
(Please cc me on all replies, I'm not subscribed) On Sat, Dec 17, 2005 at 05:32:15PM +0100, Florian Weimer wrote: * Marc Haber: This is, btw, not an ipv6 issue exclusively, it might happen in ipv4-only setups as well. See Debian Bug #342619 for another example. I'm not sure if it's the same bug, and I wouldn't be surprised if the behavior was deliberate in that case (after all, the whole long failure period business is there to generate immediate bounces, so that users won't have to wait for five days until they are told about their mistake). In the example in the bug report, we there are two A RRs: mailrelay.direct-adsl.nl. 86400 IN A 195.121.6.12 mailrelay.direct-adsl.nl. 86400 IN A 195.121.6.56 But resolvers MUST cache the whole set of records and expire them at the same time. If the resolver fails to do this properly and provides a wrong view on DNS, there is no workaround on Exim's side. The DNS setup changed in the meanwhile, because of, as I now know, a wrong guess at the cause of the failure. The old setup had MX's from multiple different zone's, and the one MX that had a long failure was also served the DNS server of the mail server, but the secundary MX's to which the mail should have been delivered to, was only remotely DNS-served -- so the DNS server in question at times only had the broken MX cached (well, was authoritive for it, even), and only that was in the additional section -- the IP addresses of the working MX's were out of the cache. The only solution seems to me to actively query for all A (and ) records of all MX's before determining that no MX's are available for delivery -- the additional DNS section is not to be trusted to ever give an exhaustive list of IP addresses to try. I'd even say that it needs to happen at every delivery attempt after delivery is found to be unsuccesful to all the MX's in the additional section, because it can happen that some MX's are more often in it than others. And you don't want delivery to fail just because at the ultimate attempt all MX's happen to be down -- but some were up in the past 4 days. Note that RFC 974, MAIL ROUTING AND THE DOMAIN SYSTEM from 1986 (predating IPv6 by 12 years) explicitely warns against wrong handling of the DNS additional section for MX queries: | The incomplete data problem also requires some care when handling | domain queries. If the answer section of a query is incomplete | critical MX RRs may be left out. This may result in mail looping, or | in a message being mistakenly labelled undeliverable. As a result, | mailers may only accept responses from the domain system which have | complete answer sections. Note that this entire problem can be | avoided by only using virtual circuits for queries, but since this | situation is likely to be very rare and datagrams are the preferred | way to interact with the domain system, implementors should probably | just ensure that their mailer will repeat a query with virtual | circuits should the truncation bit ever be set. Even though the RFC only mentions problems regarding to DNS datagram truncation, and does not mention the issue that is more relevant here, incomplete answer due to unbalanced caching -- a problem which only can happen with MX's out of multiple zone's or with IPv6 (or explicitely unbalanced TTL's in one zone, but I consider *that* very unlikely). --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342619: Possible exim retry bug (Re: master mail problems -- help needed)
On Sat, Dec 17, 2005 at 04:07:51PM +0100, Marc Haber wrote: On Fri, Dec 09, 2005 at 01:12:56AM +0100, Jeroen van Wolffelaar wrote: I'm quite sure it's an exim bug, but haven't quite nailed it yet. The bug has been witnessed positively both on master.d.o and on one mailserver I maintain. Interestingly, it doesn't seem to be IPv6 related (or maybe there are two bugs). It might be DNS related. Can you comment about http://www.exim.org/mail-archives/exim-users/Week-of-Mon-20051212/msg00196.html please? That sounds very much like the cause of this bug. It's also possible even for IPv4 issues like the one in my original bugreport, as also in that case, TTL's were distinct, and indeed, the situation could arrise that a DNS query would give only partial results in the additional section, because of the setup of the involved DNS servers. So, it seems like the logic error is in that the additional DNS section is believed to be complete, which is not at all guaranteed to be true -- it can be partial for any reason. Thanks a lot for finding the (IMHO) most logical cause of this bug, which according to Ockham's razor, is the cause of this bug. I tried looking into the code etc, but simply failed to find the reason and wouldn't easily have found this at all... If you have any further questions, please ask, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343833: Uploaders: field broken
Package: xfce4-icon-theme Severity: serious The Uploaders field of this package is broken, as detected by lintian: E: xfce4-icon-theme source: uploader-address-missing Yves-Alexis Perez This causes several QA scripts, such as the PTS, to choke on this package. Could you please fix this in the next upload, meanwhile, also paying attention to other lintian warnings and errors? (policy 5.6.2 is defining syntax for Maintainer Uploaders, and lists email as mandatory) Thanks, --Jeroen -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-k7 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342619: Possible exim retry bug (Re: master mail problems -- help needed)
Package: exim4-daemon-heavy Version: 4.50-8 Severity: serious On Thu, Dec 08, 2005 at 10:33:54PM +0100, Florian Weimer wrote: * Lionel Elie Mamane: On Thu, Dec 08, 2005 at 09:30:52PM +0100, Wouter Verhelst wrote: The fact that my primary MX is only available through IPv6, and that this is the case for other people who're having problems too might then be a better chance at being the problem. My primary MX is IPv6-only, too. I don't have detected a problem yet :) Do you receive lots of mail from master.debian.org, and would you notice the bounces? Mail from Debian mailing lists come directly from murphy.debian.org, which does not seem to have the problem. You also have one IPv4-only MX, which might be enough to prevent the Exim bug[1] from occurring. [1] I'm not sure if it's a Exim's fault, it's only a hunch. I'm quite sure it's an exim bug, but haven't quite nailed it yet. The bug has been witnessed positively both on master.d.o and on one mailserver I maintain. Interestingly, it doesn't seem to be IPv6 related (or maybe there are two bugs). The situation on my mailserver was that the primary MX had a long term unavailability and was way past cutoff time, but the secondary MX worked fine. However, for some reason, what suddenly happened was that all the mail queued for the domain in question got bounced for reason of having a extended time of being unreacheable, past the retry time. Obviously, that's bogus, as the secundary MX wasn't past cutoff yet. I've meant to look into the code for this, but didn't yet get around to it. If someone wants to do so, please -- I seriously suspect that Exim in Sarge has a serious bug in there somewhere, it's showing up with this IPv6 and IPv4 multihomed MX's too, after all. I think this is a serious bug, as it can cause mail to get lost (bouncing a mail for no good reason at all in some very common situations like the IPv6 vs IPv4 multimhomed MX's) Log snippets: # Primary (long time unreacheable) MX is shrek.vanschaik.tk, secundary # reacheable MX is mailrelay.direct-adsl.nl Last succesful delivery: 2005-11-30 17:49:53 1EhV6R-uq-Qg shrek.vanschaik.tk [81.207.193.3]: Connection timed out 2005-11-30 17:50:02 1EhV6R-uq-Qg = [EMAIL PROTECTED] [EMAIL PROTECTED] R=dnslookup_relay_to_domains T=remote_smtp H=mailrelay.direct-adsl.nl [195.121.6.56] C=250 2.0.0 jAUGo2wm025502 Message accepted for delivery QT=3m19s First failure: 2005-11-30 18:35:41 1EhVnA-0002GK-L1 shrek.vanschaik.tk [81.207.193.3]: No route to host 2005-11-30 18:35:41 1EhVnA-0002GK-L1 == [EMAIL PROTECTED] [EMAIL PROTECTED] R=dnslookup_relay_to_domains T=remote_smtp defer (113): No route to host 2005-11-30 18:35:41 1EhVnA-0002GK-L1 ** [EMAIL PROTECTED] [EMAIL PROTECTED]: retry timeout exceeded Second failure: 2005-11-30 18:36:43 1EhVrp-0001pB-Jw ** [EMAIL PROTECTED] [EMAIL PROTECTED] R=dnslookup_relay_to_domains T=remote_smtp: retry time not reached for any host after a long failure period Obviously, the secundary MX was okay, so retry timeout exceeded and especially the second failure should not have happened. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342619: [EMAIL PROTECTED]: Mail delivery failed: returning message to sender]
Heh. Example: - Forwarded message from Mail Delivery System [EMAIL PROTECTED] - Return-path: Envelope-to: [EMAIL PROTECTED] Delivery-date: Fri, 09 Dec 2005 01:42:04 +0100 Received: from 220pc220.sshunet.nl ([145.97.220.220] helo=mordor.wolffelaar.nl ident=Debian-exim) by a-eskwadraat.nl with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1EkWKq-0004xe-EP for [EMAIL PROTECTED]; Fri, 09 Dec 2005 01:42:04 +0100 Received: from master.debian.org ([146.82.138.7]) by mordor.wolffelaar.nl with esmtp (Exim 4.50) id 1EkWKp-0001Ke-I1 for [EMAIL PROTECTED]; Fri, 09 Dec 2005 01:42:03 +0100 Received: from Debian-exim by master.debian.org with local (Exim 4.50) id 1EkWKo-00040c-IO for [EMAIL PROTECTED]; Thu, 08 Dec 2005 18:42:02 -0600 X-Failed-Recipients: [EMAIL PROTECTED] Auto-Submitted: auto-generated From: Mail Delivery System [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Mail delivery failed: returning message to sender Message-Id: [EMAIL PROTECTED] Date: Thu, 08 Dec 2005 18:42:02 -0600 This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: [EMAIL PROTECTED] retry time not reached for any host after a long failure period -- This is a copy of the message, including all the headers. -- Return-path: [EMAIL PROTECTED] Received: from a-eskwadraat.nl ([131.211.39.72]) by master.debian.org with esmtp (Exim 4.50) id 1EkWKn-00040K-Cd; Thu, 08 Dec 2005 18:42:01 -0600 Received: from jeroen by a-eskwadraat.nl with local (Exim 4.50) id 1EkWKh-0004xF-Q0; Fri, 09 Dec 2005 01:41:55 +0100 Date: Fri, 9 Dec 2005 01:41:55 +0100 To: Florian Weimer [EMAIL PROTECTED] Cc: Lionel Elie Mamane [EMAIL PROTECTED], Wouter Verhelst [EMAIL PROTECTED], Romain Francoise [EMAIL PROTECTED], debian-devel@lists.debian.org Subject: Re: master mail problems -- help needed Message-ID: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: [EMAIL PROTECTED] User-Agent: Mutt/1.5.9i From: Jeroen van Wolffelaar [EMAIL PROTECTED] On Thu, Dec 08, 2005 at 10:33:54PM +0100, Florian Weimer wrote: * Lionel Elie Mamane: On Thu, Dec 08, 2005 at 09:30:52PM +0100, Wouter Verhelst wrote: The fact that my primary MX is only available through IPv6, and that this is the case for other people who're having problems too might then be a better chance at being the problem. My primary MX is IPv6-only, too. I don't have detected a problem yet :) Do you receive lots of mail from master.debian.org, and would you notice the bounces? Mail from Debian mailing lists come directly from murphy.debian.org, which does not seem to have the problem. You also have one IPv4-only MX, which might be enough to prevent the Exim bug[1] from occurring. [1] I'm not sure if it's a Exim's fault, it's only a hunch. I've filed #342619 on the strong suspicion something fishy is going on in exim, even though I don't know for sure what's going on exactly. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl - End forwarded message - -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308755: acknowledged by developer (Bug#308755: fixed in webmagick 2.02-8)
reopen 308755 thanks On Tue, Dec 06, 2005 at 09:03:05PM -0800, Debian Bug Tracking System wrote: * closes by maintainer. closes: #308755 Huh? This is from the changelog, which is supposed to list the changes in the package. Based on this entry, I have no idea what the resolution of the bug was -- it doesn't specify the change in the package that caused this bug to be fixed. Perhaps you meant to use -v with dpkg-buildpackage instead, or otherwise, please just close this bug with a descriptive entry -- the changelog is not a bug closing device, it's only provided as a convenience in case an upload directly corresponds to fixing a bug. Thanks, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340306: ldapvi_1.4-1_i386.changes REJECTED
severity 340306 wishlist retitle 340306 dpkg-sig'd .deb's rejected: please support it reassign 340306 dak thanks On Tue, Nov 22, 2005 at 04:35:37PM +0100, Gerfried Fuchs wrote: * Debian Installer [EMAIL PROTECTED] [2005-11-22 07:02]: Rejected: ldapvi_1.4-1_i386.deb: found 4 chunks, expected 3. === If you don't understand why your files were rejected, or if the override file requires editing, reply to this email. Citing man 5 deb (which is referenced by policy): These members must occur in this exact order. Current implementations should ignore any additional members after data.tar.gz. Should != must. Besides, Policy deals with packages' behaviour not with how the archive should behave. In any case, I do not follow your reading of policy that would mandate debian.org's archive to allow extra members of .deb's. Anyway, it seems work is underway to allow specifically dpkg-sig'd .deb's in the archive proper (rather than not checking extra members at all, with the potentional to contain any random sort of data that's not normally visible by usage of dpkg), once the code is there, this issue will be revisited. For now though, the check will remain in place. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#232702: Status of package?
On Sat, Sep 10, 2005 at 05:45:57PM +0200, Frank Lichtenheld wrote: Hi. This package was removed before sarge. Is it planned to get it fixed up for etch or at least in unstable or should it just be removed from the archive alltogether? One of the dependencies, irssi-snapshot-dev, is now removed from the archive, making this package FTBFS too. What's that status? If a package is removed, it can later also be re-added relatively easily, NEW is quite fast nowadays. In its current state, it's unuseable. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332799: FTBFS/mipsel: Please stop building java bindings for mipsel
On Sat, Oct 08, 2005 at 08:04:00PM +0200, Jeroen van Wolffelaar wrote: When you've made that upload, please reassign this bug to to ftp.debian.org so that the mipsel bindings of subversion as they are in the archive now can be dropped. Done now anyway (the removal), though this bug mistakenly didn't get reassigned after you fixed this bug. (See #336060). Thanks, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332799: FTBFS/mipsel: Please stop building java bindings for mipsel
Package: subversion Version: 1.1.4-2 Severity: serious Because gcj nor jikes are able to compile java code on mipsel, kaffe unfortunately needed to be dropped for mipsel. Please stop building the java bindings for mipsel, and add a [!mipsel] qualification to your kaffe build-dependency. When you've made that upload, please reassign this bug to to ftp.debian.org so that the mipsel bindings of subversion as they are in the archive now can be dropped. Please note that mips is in a similar situation, it's likely that kaffe will stop supporting mips too in the near future. So you could stop building java bindings for mips too, if you wish -- or alternatively wait and see, it's not sure yet. --Jeroen -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-k7 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages subversion depends on: ii db4.2-util 4.2.52-18 Berkeley v4.2 Database Utilities ii libapr02.0.54-5 the Apache Portable Runtime ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libdb4.2 4.2.52-18 Berkeley v4.2 Database Libraries [ ii libexpat1 1.95.8-3 XML parsing C library - runtime li ii libldap2 2.1.30-8 OpenLDAP libraries ii libneon24 0.24.7.dfsg-2 An HTTP and WebDAV client library ii libssl0.9.70.9.7e-3 SSL shared libraries ii libsvn01.1.4-2 shared libraries used by Subversio ii libxml22.6.16-7 GNOME XML library ii patch 2.5.9-2 Apply a diff file to an original ii zlib1g 1:1.2.2-4.sarge.2 compression library - runtime -- no debconf information -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332800: FTBFS/mipsel: kaffe no longer supports mipsel
Package: bigloo Severity: serious Because gcj nor jikes are able to compile java code on mipsel, kaffe unfortunately needed to be dropped for mipsel. Please stop building the java bindings for mipsel, and add a [!mipsel] qualification to your kaffe build-dependency. When you've made that upload, please reassign this bug to to ftp.debian.org so that the mipsel versions of bigloo-backend-jvm as they are in the archive now can be dropped. Please note that mips is in a similar situation, it's likely that kaffe will stop supporting mips too in the near future. So you could stop building java bindings for mips too, if you wish -- or alternatively wait and see, it's not sure yet. Thanks, --Jeroen -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-k7 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302462: Please remove howl
On Fri, Sep 02, 2005 at 02:26:53AM +1000, Jeff Waugh wrote: Hi, I didn't realise I was a blocker on this, my apologies. Please just completely remove howl. There's really no point putting it in non-free. Hm, this will break daapd. Michael, are you aware of the state of howl? Please be adviced that if this package is removed, daapd will be uninstalleable. So please adopt this package and move it to non-free if you want to keep daapd installeable. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292951: not detecting cdrom on iMac G5
On Thu, May 26, 2005 at 02:23:12PM +0200, Santiago Vila wrote: severity 292951 serious thanks On Tue, 1 Feb 2005, Joel Van Velden wrote: Debian Installer (nightly version 20050128 netinst.iso) does not succeed in loading the cdrom drive so it cannot proceed further with the installation. To clarify: The cdrom boots an i choose expert-power4 from the choice of kernels prompt. Kernel loads. Debian installer loads. Prompts for choosing keyboard, locale, etc., which work. Only option now left is to load off the cdrom the next part of the installer, but it cant detect the cdrom at all. I can reproduce this behaviour on an iMac G5 from a friend, using RC3 of d-i. Do you (d-i team) really consider this bug release-critical? It was ignored unfixed for sarge, and I would classify having etch detect this particular brand of cd-rom as a wishlist... considering Sarge didn't. Other than the arm build being MIA, this is the only issue currently blocking hw-detect. Right? --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#288586: sword: FTBFS (amd64/gcc-4.0): cast from 'sword::SWMgr*' to 'int' loses precision
On Tue, Jan 04, 2005 at 03:45:50PM +0100, Andreas Jochens wrote:
When building 'sword' on amd64 with gcc-4.0,
I get the following error:
../bindings/flatapi.cpp:46: error: cast from 'sword::SWMgr*' to 'int' loses
precision
(...)
make[3]: *** [flatapi.lo] Error 1
With the attached patch 'sword' can be compiled
on amd64 using gcc-4.0.
I'm about to upload a NMU as part of the current bugsquashingpart,
including C++ transition and several fixes for serious issues with the
library package as it is (ldconfig was not run in postinst/prerm, etc).
Please find the diff attached.
Thanks,
--Jeroen
--
Jeroen van Wolffelaar
[EMAIL PROTECTED]
http://jeroen.A-Eskwadraat.nl
diff -u sword-1.5.7/debian/changelog sword-1.5.7/debian/changelog
--- sword-1.5.7/debian/changelog
+++ sword-1.5.7/debian/changelog
@@ -1,3 +1,16 @@
+sword (1.5.7-7.1) unstable; urgency=low
+
+ * Non-Maintainer Upload
+ * C++ transition: libsword4 - libsword4c2
+ * Fix gcc4 compile error: Use intptr_t as type for pointers, not 'int'
+(Closes: #288586)
+ * Debhelper compat level 4, to fix calls to ldconfig properly, and drop a
+lot of manual stuff
+ * Run dh_makeshlibs *before* dh_installdeb
+ * Fix broken dh_shlibs invocation
+
+ -- Jeroen van Wolffelaar [EMAIL PROTECTED] Sat, 6 Aug 2005 19:42:38 +0200
+
sword (1.5.7-7) unstable; urgency=high
* Patch from security team, Closes: #291433
diff -u sword-1.5.7/debian/control sword-1.5.7/debian/control
--- sword-1.5.7/debian/control
+++ sword-1.5.7/debian/control
@@ -5,12 +5,12 @@
Maintainer: Daniel Glassey [EMAIL PROTECTED]
Standards-Version: 3.6.1.0
-Package: libsword4
+Package: libsword4c2
Architecture: any
Section: libs
Depends: ${shlibs:Depends}
Recommends: sword-frontend
-Replaces: libsword1, libsword2c102, libsword3, libsword-runtime,
libsword-config
+Replaces: libsword1, libsword4, libsword-runtime, libsword-config
Description: API/library for bible software
The SWORD Project is an open source, cross-platform (Linux, Windows, Solaris,
MacOSX etc.) API/library for Bible software with a constantly growing list
@@ -26,7 +26,7 @@
Package: libsword-dev
Architecture: any
Section: libdevel
-Depends: libsword4 (= ${Source-Version}), libc6-dev, libz-dev, libcurl3-dev
+Depends: libsword4c2 (= ${Source-Version}), libc6-dev, libz-dev, libcurl3-dev
Provides: sword-dev
Description: Development files for libsword
This package contains the static libraries and headers for developing
diff -u sword-1.5.7/debian/libsword-dev.dirs
sword-1.5.7/debian/libsword-dev.dirs
--- sword-1.5.7/debian/libsword-dev.dirs
+++ sword-1.5.7/debian/libsword-dev.dirs
@@ -2,3 +1,0 @@
-usr/lib/pkgconfig
-usr/include/sword
-usr/share/doc/libsword-dev/html
diff -u sword-1.5.7/debian/rules sword-1.5.7/debian/rules
--- sword-1.5.7/debian/rules
+++ sword-1.5.7/debian/rules
@@ -8,15 +8,15 @@
package=sword
+# We want to use bashisms like {a,b}
+export SHELL=/bin/bash
+
version=$(shell expr `pwd` : '.*-\([0-9.]*\)')
version_major=$(shell expr `pwd` : '.*-\([0-9]*\).[0-9.]*')
# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1
-# This is the debhelper compatability version to use.
-#export DH_COMPAT=2
-
export DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
export DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
@@ -64,12 +64,13 @@
dh_clean -k
dh_installdirs
- # Add here commands to install the package into debian/tmp.
- \$(MAKE) install DESTDIR=`pwd`/debian/tmp
+ # Add here commands to install the package into debian/libsword4c2.
+ $(MAKE) install DESTDIR=$(PWD)/debian/libsword4c2
- dh_movefiles -plibsword-dev usr/lib/lib*so usr/lib/lib*.a \
- usr/lib/lib*.la usr/include/* usr/lib/pkgconfig/*
- dh_movefiles -pdiatheke usr/bin/diatheke
+ mv debian/libsword4c2/usr/lib/{lib*.{so,a,la},pkgconfig} \
+ debian/libsword-dev/usr/lib
+ mv debian/libsword4c2/usr/include debian/libsword-dev/usr
+ mv debian/libsword4c2/usr/bin/diatheke debian/diatheke/usr/bin
#dh_movefiles -plibsword-runtime usr/bin/*
#dh_movefiles -plibsword-config etc/*
usr/share/sword/mods.d/globals.conf \
# usr/share/sword/locales.d/*
@@ -101,11 +102,11 @@
dh_link
dh_compress
dh_fixperms
- dh_installdeb
- dh_makeshlibs -V 'libsword4 (=1.5.7-1)'
+ dh_makeshlibs
dh_perl
- dh_shlibdeps -ldebian/tmp/usr/lib
+ dh_shlibdeps -L libsword4c2 -ldebian/libsword4c2/usr/lib
dh_gencontrol
+ dh_installdeb
dh_md5sums
dh_builddeb
reverted:
--- sword-1.5.7/debian/libsword4.dirs
+++ sword-1.5.7.orig/debian/libsword4.dirs
@@ -1,7 +0,0 @@
-usr/lib
-usr/bin
-etc/
-usr/share/sword
-usr/share/sword/mods.d
-usr/share/sword/modules
-usr/share/sword/locales.d
reverted:
--- sword-1.5.7/debian/libsword4.docs
+++ sword-1.5.7.orig/debian/libsword4.docs
@@ -1,2 +0,0
Bug#276789: Uses /tmp/tleds.pid as a pid symbolic link
tags 276789 patch thanks On Sun, Apr 03, 2005 at 12:47:27AM +0200, Juergen Salk wrote: Tags: patch When only mailing -submitter, the maintainer won't get a mail about it, also, the above way doesn't set the patch tag on an existing bugreport. Repairing now, and thank you for the patch! --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321449: gcc-snapshot should stay in unstable
Package: gcc-snapshot Severity: serious To the best of my understanding, gcc-snapshot is not intended to be ever released with a stable Debian release. This bug is intended to serve as a marker bug to make sure gcc-snapshot won't enter testing. Thanks, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321534: Depends on about-to-be-removed tuxtype
Package: junior-typing Severity: serious One of the junior-typing dependencies, tuxtype, is RC buggy for a while (copyright reasons) and doesn't seem like to be fixed soonishly. It's therefore marked for removal, so either please fix tuxtype, or stop depending on it, or junior-typing risks getting removed from testing too. Thanks, --Jeroen -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) Versions of packages junior-typing depends on: pn gtypist Not found. pn tipptrainer Not found. pn tuxtype Not found. pn typespeedNot found. pn xletters Not found. -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320941: rtfm: request-tracker3 being removed
On Tue, Aug 02, 2005 at 10:24:26AM +0100, Andrew Stribblehill wrote: This is warning of a grave bug-to-be. We're removing request-tracker3, upon which rtfm depends -- but that's okay because rtfm doesn't work anyway with current rt 3.0. I'll leave this report with you for a week or so before reassigning it to the ftpmasters to remove rtfm. In what way does rtfm not work with current rt3.0? Can you please elaborate? Also, note that only the maintainer or QA can request removal of a package, and in this specific case, I don't yet see enough grounds for removal, certainly one week notice is not enough, nor is only a vague reference to an RC bug that was previously unfiled. Regards, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321284: libatomic-ops override disparity
Package: libatomic-ops Version: 1.0-1 Severity: serious On Wed, Aug 03, 2005 at 11:46:37AM +1000, Ian Wienand wrote: On Tue, Aug 02, 2005 at 08:47:04AM -0700, Debian Installer wrote: There are disparities between your recently accepted upload and the override file for the following file(s): libatomic-ops_1.0-1_i386.deb: package says section is libdevel, override says libs. Hi, This package only contains static libraries (as requested by upstream), so I belive it fits best into libdevel. You have a separate -dev package too... If you were to only have a static version of the library (which I would strongly discourage, fwiw, regardless of what upstream says, but still), there is no reason to have two packages, everything could and should be in the -dev. Static libraries belong in the -dev, not in the normal package[1]. Also, any package depending on libatomic-ops will now break because the .so simply disappeared. There is no such package in Debian, but still. Also, you moved the static libraries without adding a proper Replaces: field, breaking all upgrades. I suggest dropping the libatomic-ops binary package, moving the .a's back. You could add a replaces for people who managed to upgrade regardless too. Thanks, --Jeroen [1] http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-static -- It [static library (libraryname.a)] is placed into the development package -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320351: Dependency (kernel-patch-acl) about to be removed from the archive
Package: kernel-patch-exec-shield Severity: serious Hi, A dependency of this package, kernel-patch-acl, is about to be removed from the archive. Considering the state of this package (new upstream for more than 15 months without maintainer response, doesn't apply to any kernel in Debian at the moment), I'm not going to refrain from removing the package because of this reverse dependency. Instread, since 2.4 is obsolete by the time we release etch anyway, I strongly suggest to remove kernel-patch-exec-shield too. If you agree, please reassign this bug to the ftp.debian.org pseudopackage. Thanks, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317739: Patch for #317739
On Tue, Jul 12, 2005 at 09:51:12AM +0200, Thijs Kinkhorst wrote: tags 317739 +patch thanks Hey people, I've prepared the attached patch with addresses this issue. Jeroen, can you review? And shall we release an advisory about this or wait for information from the phpbb-team? It should really be tested on plain upstream 2.0.16 before reporting. Can you try that? I'll then report it upstream and hopefully get a response quickly. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Bug#315115: [EMAIL PROTECTED]: sudo fix]
reopen 315115 tags 315115 woody sarge pending thanks Updated packages mailed to security team, awaiting review and upload. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#296524: License problem with debian memtester package
On Tue, Feb 22, 2005 at 07:01:58PM -0600, Charles Cazabon wrote: Package: memtester Version: all Greetings, There is a licensing problem with the memtester package included in Debian. I tried to report this to the package maintainer, but your system reports the address is no longer valid. Hm, yes, I notice. My software is licensed under /only/ version 2 of the GPL, but your package states the typical FSF or any later version, which does not apply to any of my software. Ai, that's a serious mistake on part of the Debian maintainer for your package. Please do accept our apologies for that. It looks like the maintainer since has switched email addresses, as the domain masqmail.cx is not working anymore. I'm cc'ing him on his @debian.org address, and noting the issue for further tracking in case nothing happens. I'm sorry it took a while to notice, typically a mailinglist like debian-qa@lists.debian.org yields better response times. Oliver, please update this package and dumpasn1 to your new email address, and update those packages (and of course, fix this bug). Thanks, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#312607: dasher: crashes on startup.
On Thu, Jun 09, 2005 at 02:41:25AM -0400, Robin Millette wrote: Package: dasher Version: 3.2.13-1 Severity: grave Justification: renders package unusable Maybe a conflict with the ion3 window manager ? After trying a few times to start it, from an xterm or run (F3), I reinstalled it, purging everything. After a second reinstall, I was able to launch dasher from an xterm. I closed it, but it crashed again when I started it from run (F3) and it crashed too the second time I tried to launch it from an xterm. Reproducible on sarge with ion2. It starts, I sub-second get to see a bit of what I guess is supposed to be the main screen, and then gnome kicks in and notifies me the application quitted unexpectedly. strace didn't give me anything useful, a lot of networking activity and it looks like a normal exit from their (no SIGSEGV or something). --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308705: removing ipfwadm
On Fri, Jun 10, 2005 at 11:47:40PM -0700, Adam McKenna wrote: There is no consensus that this package should be removed. Since I am still willing to maintain it, I don't believe removal is appropriate at this time. I see, I'm curious how many people actually still use this package, now that 2.2 kernels will get dropped for Etch quite likely, and only 2.4/2.6 remain. But well, as you note, there's at least someone (you) supporting it to remain in Debian, and that has always been enough reason in Debian to keep a package. Thanks, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#312578: Dummy package should be removed?
Package: raidtools2 Severity: serious As this is a dummy transitional package for Sarge, and upgrades skipping a stable release are not supported, I think this package should be removed from unstable and that way from etch, in order to reduce package bloat. Please do reassign this bug to ftp.debian.org if you agree. Thanks, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308680: Removed mysql-nonfree, mysql-nonfree-4.1 from unstable
reopen 308680 thanks On Mon, May 30, 2005 at 03:47:29PM -0400, Debian Archive Maintenance wrote: We believe that the request you reported is now fixed; the following package(s) have been removed from unstable: mysql-doc | 4.0.24-1 | all mysql-doc-4.1 | 4.1.10a-1 | all mysql-nonfree | 4.0.24-1 | source mysql-nonfree-4.1 | 4.1.10a-1 | source Reason: RoM; undistributeable Right, and this 'undistributable' still holds, as I noted just before actually removing over here, so reopening as these packages erroneously got reintroduced. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308680: Please remove source packages mysql-nonfree and mysql-nonfree-4.1
On Tue, May 24, 2005 at 04:12:56PM +0200, Jeroen van Wolffelaar wrote: Reading [EMAIL PROTECTED], that doesn't really read as the intention and how it might end up with upstream. The attached statement only mentions that Stefan Hinz misunderstood in his last mail, but doesn't imply as far as I can see that MySQL really intends to forbid distribution of the manual is something like Debian. I'll be replying to [EMAIL PROTECTED] shortly. Followup shows that indeed the MySQL manual is undistributeable until upstream can see a possibility to provide more allowing license terms for distribution of the manual. Gory details are in the debian-email archives. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308680: MySQL docs not distributable?
On Tue, May 24, 2005 at 04:53:12PM +0200, Jeroen van Wolffelaar -- Debian FTP wrote: On Wed, May 18, 2005 at 04:13:01PM +0200, Stefan Hinz wrote: On 2005-05-18 Stefan Hinz wrote: What's not mentioned here is what we *do* allow, and that's what all this discussion is about: We want the Manual to be shipped with the software *but not separately*. (...) I was imprecise. What I meant to say is not separately in the sense of putting the Manual somewhere outside the vicinity of the MySQL software. E.g. putting the Manual on a book CD that doesn't contain the MySQL software. Does this sound clearer? In my opinion yes, as I interpret this as that it's (for example) okay to ship the manual on Debian's FTP mirror network, all of which are shipping the MySQL server and client software alongside the manual. Dear Stefan, or any other MySQL (documentation) representative, By request of our Release Team, could you please confirm to us as soon as possible that my conclusion I drew here is correct, and that your statemnt indeed implies it's okay for all of the mirrors in Debian's mirror network (or any mirror, because your statement is not Debian-specific) to have to have the MySQL documentation alongside the server software like: http/ftp://ftp//pool/non-free/m/mysql-nonfree/mysql-doc_version_all.deb http/ftp://ftp//pool/main/m/mysql-dfsg/mysql-server_version_arch.deb (etc) ? If you could positively confirm this, there would be no reason not to ship MySQL's manual via Debian's mirror network. Thank you very much in advance, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308680: Please remove source packages mysql-nonfree and mysql-nonfree-4.1
tags 308680 = moreinfo thanks On Mon, May 23, 2005 at 01:28:57PM +0200, Christian Hammers wrote: reassign 308680 ftp.debian.org severity 308680 serious justification: licence problem retitle 308680 Please remove mysql-nonfree(-4.1) -- RoM thanks Hello FTP-maintainers Please remove the following source and binary packages from all releases due to a licence that makes it undistributionable for us. The problem has been discussed and confirmed with the upstream author. source:binary: mysql-nonfree - mysql-doc(woody, sarge, sid) mysql-nonfree-4.1 - mysql-doc-4.1( sarge, sid) Reading [EMAIL PROTECTED], that doesn't really read as the intention and how it might end up with upstream. The attached statement only mentions that Stefan Hinz misunderstood in his last mail, but doesn't imply as far as I can see that MySQL really intends to forbid distribution of the manual is something like Debian. I'll be replying to [EMAIL PROTECTED] shortly. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308680: MySQL docs not distributable?
Hi Stefan, hi all, Let me first introduce myself, I'm member of the Debian FTP team, and Christian Hammers assigned this issue to us. On Wed, May 18, 2005 at 04:13:01PM +0200, Stefan Hinz wrote: On 2005-05-18 Stefan Hinz wrote: What's not mentioned here is what we *do* allow, and that's what all this discussion is about: We want the Manual to be shipped with the software *but not separately*. (...) I was imprecise. What I meant to say is not separately in the sense of putting the Manual somewhere outside the vicinity of the MySQL software. E.g. putting the Manual on a book CD that doesn't contain the MySQL software. Does this sound clearer? In my opinion yes, as I interpret this as that it's (for example) okay to ship the manual on Debian's FTP mirror network, all of which are shipping the MySQL server and client software alongside the manual. Debian's non-free section already cannot in general be distributed in any other way than via the Debian FTP-server network, so additional restrictions do not affect packages in non-free, including the MySQL manual -- it's the responsability of those redistributors to check the legal issues of doing so. If, on the other hand, you want to have it shipped in a distribution that also has the mysql server and client binaries in another package then I need a short and clear copyright addition that I can put into the copyright file of the package to make the ftp master happy again. OK, I've asked our contract dept. for such a paper. Not sure if they get this done by ... By when do you need to have it? And since it's legal stuff, you probably need it on paper; so where should we send that paper to? You do not need to commit such a statement to dead-tree paper, that's not needed as far as Debian is concerned. An 'authorative' statement from the copyright holder by email or via website will do. As far as I'm concerned, your statement above (the 3+4 lines) suffices -- you're saying 'We want (...)' mailing from an @mysql.com address. Christian, Stefan, anyone else: any more questions/remarks? --Jeroen -- Jeroen van Wolffelaar Member of the Debian FTP team -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310407: Bug#308680: MySQL docs not distributable?
severity 310406 normal severity 310407 normal tags 310406 patch tags 310407 patch thanks Stefan Hinz [EMAIL PROTECTED], of the MySQL AB Documentation Team, wrote in [EMAIL PROTECTED][1] and [EMAIL PROTECTED][2] as documented in this bug with regards to the MySQL manual: | What's not mentioned here is what we *do* allow, and that's what all this | discussion is about: We want the Manual to be shipped with the software | *but not separately*. | (...) | I was imprecise. What I meant to say is not separately in the sense of | putting the Manual somewhere outside the vicinity of the MySQL software. | E.g. putting the Manual on a book CD that doesn't contain the MySQL | software. Including this in debian/copyright ought to be sufficient, seem by reasoning at [3]. Although it'd be nice to have this statement included in the package's copyright file itself, as far as I know it's not a release critical issue for it to not be, as long as such statement exists, especially for non-free. Release team, could you please reconsider removing the documentation of MySQL from Sarge? IMHO proper documentation for important pieces of software is an important to have. Thanks, --Jeroen [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=308680msg=19 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=308680msg=25 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=308680msg=62 -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308272: Cannot distribute in Debian
On Fri, May 13, 2005 at 12:41:50PM +0200, Thijs Kinkhorst wrote:
Please note that the rar package, by the same upstream author,
contains such permission. So it should not be a problem to get the same
statement for unrar.
NMU sitting in NEW, diff below.
Explanation on what and why I've done will be forthcoming on -devel and
-release as followup to the unrar version confusion thread once this
package has cleared NEW.
--Jeroen
reverted:
--- unrar-nonfree-3.4.3/pathfn.cpp
+++ unrar-nonfree-3.4.3.orig/pathfn.cpp
@@ -311,8 +311,7 @@
char *EnvStr=getenv(HOME);
if (EnvStr==NULL)
return(false);
+strcpy(Path,EnvStr);
-strncpy(Path,EnvStr,NM);
-Path[NM-1]='\0';
return(true);
}
static char *AltPath[]={
diff -u unrar-nonfree-3.4.3/debian/changelog
unrar-nonfree-3.5.2/debian/changelog
--- unrar-nonfree-3.4.3/debian/changelog
+++ unrar-nonfree-3.5.2/debian/changelog
@@ -1,3 +1,17 @@
+unrar-nonfree (1:3.5.2-0.1) unstable; urgency=medium
+
+ * Non-Maintainer Upload
+ * New upstream (Closes: #302986)
++ License no longer prohibits packaging changes (Closes: #308272)
++ Dropped security patch, as it has been incorporated upstream
+ * Make if very clear in copyright that you can't use the source code for
+recreating rar compression algorithm
+ * Renamed binary package to 'unrar' to replace the still-in-development free
+'equivalent', add epoch to cope with version increase too
+(Closes: #265045)
+
+ -- Jeroen van Wolffelaar [EMAIL PROTECTED] Sun, 22 May 2005 11:47:41 +0200
+
unrar-nonfree (3.4.3-1) unstable; urgency=low
* New upstream release
diff -u unrar-nonfree-3.4.3/debian/copyright
unrar-nonfree-3.5.2/debian/copyright
--- unrar-nonfree-3.4.3/debian/copyright
+++ unrar-nonfree-3.5.2/debian/copyright
@@ -3,12 +3,16 @@
Further modifications have been made by Chris Anderson [EMAIL PROTECTED]
on Wed Aug 25 19:03:47 EDT 2004
-It was downloaded from http://www.rarlab.com/rar/unrarsrc-3.4.2.tar.gz
+It was downloaded from http://www.rarlab.com/rar/unrarsrc-3.5.2.tar.gz
Copyright:
-Copyright (c) 1993-1999, 2000-2002 Eugene Roshal
+Copyright (c) 1993-2005 Alexander L. Roshal
-This software is freeware.
+NOTE: this software is non-free, therefore carefully read this license before
+doing anything with it. In particular, this source code may not be used for
+recreating the rar compression algorithm.
+
+Full license follows:
*** ** unRAR - free utility for RAR archives
** ** ** ** ** ** ~
@@ -20,7 +24,7 @@
The source code of unRAR utility is freeware. This means:
1. All copyrights to RAR and the utility unRAR are exclusively
- owned by the author - Eugene Roshal.
+ owned by the author - Alexander Roshal.
2. The unRAR sources may be used in any software to handle RAR
archives without limitations free of charge, but cannot be used
@@ -30,8 +34,7 @@
stated in the documentation and source comments that the code may
not be used to develop a RAR (WinRAR) compatible archiver.
- 3. The unRAR utility may be freely distributed, provided the
- distribution package is not modified. No person or company
+ 3. The unRAR utility may be freely distributed. No person or company
may charge a fee for the distribution of unRAR without written
permission from the copyright holder.
@@ -54 +57 @@
-Eugene Roshal
+Alexander L. Roshal
diff -u unrar-nonfree-3.4.3/debian/control unrar-nonfree-3.5.2/debian/control
--- unrar-nonfree-3.4.3/debian/control
+++ unrar-nonfree-3.5.2/debian/control
@@ -5,12 +5,10 @@
Build-Depends: debhelper (= 4)
Standards-Version: 3.6.1
-Package: unrar-nonfree
+Package: unrar
Architecture: any
Depends: ${shlibs:Depends}
-Replaces: unrar
-Provides: unrar
-Conflicts: unrar, rar (= 2.60-1)
+Conflicts: rar (= 2.60-1)
Description: Unarchiver for .rar files (non-free version)
Unrar can extract files from .rar archives. If you want to create .rar
archives, install package rar.
diff -u unrar-nonfree-3.4.3/debian/rules unrar-nonfree-3.5.2/debian/rules
--- unrar-nonfree-3.4.3/debian/rules
+++ unrar-nonfree-3.5.2/debian/rules
@@ -25,7 +25,7 @@
dh_clean -k
dh_installdirs
- install -o root -g root -s -m 0755 unrar debian/unrar-nonfree/usr/bin
+ install -o root -g root -s -m 0755 unrar debian/unrar/usr/bin
dh_installdocs
dh_installman debian/unrar.1
--
Jeroen van Wolffelaar
[EMAIL PROTECTED]
http://jeroen.A-Eskwadraat.nl
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#294413: useless package
severity 294413 normal clone 294413 -1 reassign 294413 ftp.debian.org retitle 294413 RM: appunti-informatica-libera -- RoM; Number of (potential) users doesn't warrant size retitle -1 Is alml being used without appunti-informatica-libera? reassign -1 alml thanks On Fri, May 20, 2005 at 05:36:51PM +0200, Massimo Dal Zotto wrote: On Fri, May 20, 2005 at 02:44:40PM +0200, Jeroen van Wolffelaar wrote: If you're positive, officially you're requested to file a bug on ftp.debian.org pseudopackage asking for its removal, but I can take it on from you if you explicitely say you've decided you want it to be removed. For sarge, I think we'll now remove it, for unstable, a more explicit statement is needed :). Ok, since a bug is already open go for the removal. Ok, doing so. BTW, you should remove also alml which is only used for packaging this book. It might be of wider use though, I don't know. I'm hoping for input from the alml maintainer on this. As fas as I know this package is not used for anything else. I'd first like the maintainer's opinion on that though, it looks like it can be used for any documentation/book project. I don't know enough of it to make a call on this. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309111: gnutls DoS bug - Already filed
tags 309111 - fixed
tags 309111 + sarge
thanks
On Sun, May 15, 2005 at 09:15:23PM +0200, Moritz Muehlenhoff wrote:
The second part fixes an issue in the RSA key export that looks worthy
to be included in Sarge as well. My original report includes two
patches; for the DoS issue and a patch which includes the RSA fix as
well.
NMU'd -13.1 for unstable, Sarge still needs to be fixed. Steve Langasek
has expressed concerns about the unstable vs testing difference,
especially the changes in -11.
The below patch also applies cleanly to the sarge version, and I tested
it succesfully with some ssl using applications on two sarge machines
(both i386 though). Also the fix looks really non-invasively trivial.
Joey/security team, ok to upload the below (built for sarge, with
modified changelog entry (version dist) to testing-security?
--Jeroen
--- gnutls11-1.0.16/debian/changelog
+++ gnutls11-1.0.16/debian/changelog
@@ -1,3 +1,11 @@
+gnutls11 (1.0.16-13.1) unstable; urgency=high
+
+ * Non-Maintainer Upload fixing DoS
+ * DoS in TLS 1.x record packet parsing [CAN-2005-1431, GNUTLS-SA-2005-1]
+(Closes: #309111)
+
+ -- Jeroen van Wolffelaar [EMAIL PROTECTED] Sun, 22 May 2005 21:47:58 +0200
+
gnutls11 (1.0.16-13) unstable; urgency=high
* Fixed an ASN.1 extraction error.
--- gnutls11-1.0.16.orig/lib/gnutls_cipher.c
+++ gnutls11-1.0.16/lib/gnutls_cipher.c
@@ -448,7 +448,7 @@
/* Check the pading bytes (TLS 1.x)
*/
- if ( ver = GNUTLS_TLS1)
+ if ( ver = GNUTLS_TLS1 pad_failed==0 )
for (i=2;ipad;i++) {
if (ciphertext.data[ciphertext.size-i] !=
ciphertext.data[ciphertext.size - 1])
pad_failed = GNUTLS_E_DECRYPTION_FAILED;
--
Jeroen van Wolffelaar
[EMAIL PROTECTED]
http://jeroen.A-Eskwadraat.nl
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#294413: useless package
On Fri, May 20, 2005 at 02:18:32PM +0200, Massimo Dal Zotto wrote: On Fri, May 20, 2005 at 12:43:16PM +0200, Jeroen van Wolffelaar wrote: severity 294413 serious thanks Hi, On Wed, Feb 09, 2005 at 05:57:45PM +0100, [EMAIL PROTECTED] wrote: Hi, this package should really be removed from debian. - It is in italian, so it is absolutely useless for 99% of debian users. - The book can easily be downloaded from the internet as stated in the Description. So it does not make much sense to wrap it as a debian package. - It wastes *** 80 Megabytes of disk space *** in the debian mirror. If debian was jammed with such a documentation in every language on the world, the distribution would burst. Whoever wants to read this can do it much easier online or could easily download it with a simple click. There's no need to waste that much space on all debian mirror. Hm, I do think the submitter might have a point here. popcon notes 9 installations of this book, and indeed, this is a full (huge) book being packaged, which also isn't specifically Debian. There is a huge amount of resources about linux and debian on the internet, and I myself am indeed not able to see why this book would need to be distributed on all mirrors and CD's/DVD's, and not merely be available from some unofficial repository for those interested in a .deb package of the book. Also documentation isn't hard to do without packaging, unlike programs, further reducing the arguments in favour of inclusion. I'm not 100% sure though. Massimo, you didn't yet reply to this bug. What is your opinion? Please share your thoughts. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl I don't know. In the past I was requested to package this book by some italian readers, but I don't know really how may users actually use it and if it's still useful for debian. Anyway if you think the package wastes too much disk space it is ok for me to remove it. 80MB can be significant in making the cut between 2 DVD's or 3 DVD's, or whether or not sarge fits on 1 dual-layer DVD. To be honest, for the latter 80MB savings might not be enough, but it certainly helps a big deal, this book being close to 1% of the size of sarge. Should I take some action to have the package actually removed from the archives or is this mail sufficient? If you're positive, officially you're requested to file a bug on ftp.debian.org pseudopackage asking for its removal, but I can take it on from you if you explicitely say you've decided you want it to be removed. For sarge, I think we'll now remove it, for unstable, a more explicit statement is needed :). BTW, you should remove also alml which is only used for packaging this book. It might be of wider use though, I don't know. I'm hoping for input from the alml maintainer on this. Thank you very much, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309367: non-bug
(Please cc submitter when updating a bug) On Wed, May 18, 2005 at 01:27:37PM +0200, Robert Millan wrote: Hi, I have verified that gnome-applets debian/control file is correct. The broken lines you pasted are the result of running the clean target without satisfying the build dependencies (which is not correct as exlained in Policy 7.6). Well, the bug I discovered because some ftp-master script puking on the Sources.gz file of upstream, which comes from the .dsc of gnome-applets. In whatever way that has become, is not relevant to this being an question of Build-Depends syntax error. The problem with the package is then that the .dsc can have different Build-Depends depending on what packages were installed during clean run, something that's very awkward and, as this bugs shows, will introduce bugs. If you're doing akward things like control rebuilding in clean, please make sure you have proper tests in place to get it right, that is, error out if something is missing, and/or even better, don't autoupdate control, but only do so on a specific, non-automaticly invoked, debian/rules target. Josselin, however, if you want to use type-handling's Provides feature, you'll be happy to know I had to bring it back. Otherwise you may just close this bug. No, please don't, the bug is present in this version. This also applies to the elinks bug. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309685: Unused library while zorp is not in testing
Package: libzorpll Severity: serious This package has been tagged for removal because it is not used in testing at the moment, while zorp is held out by an RC bug. Having an unused library in Sarge benefits basicly noone. --Jeroen -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages libzorpll depends on: ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an ii libcap1 1:1.10-14support for getting/setting POSIX. ii libglib2.0-02.6.4-1 The GLib library of C routines ii libssl0.9.7 0.9.7e-3 SSL shared libraries -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308875: patch does not work
On Mon, May 16, 2005 at 11:00:39PM +0200, Djoum? SALVETTI wrote: On Mon, May 16, 2005 at 08:57:10PM +0200, Jeroen van Wolffelaar wrote: Djoume's patch is no good since it still leaves open a race between checking whether the file exists and writing to it. Of course you are right. I have made another patch, I hope this one is ok. No, I'm sorry, the best way is to use mktemp and move it over with 'mv', for example. Nevermind, I'm going to prepare an upload now. Thanks for your efforts anyway! --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#271782: Udeb handling by britney -- a proposal
Hi all, Let me first briefly outline how britney currently handles udebs: - Well, it doesn't really, there's simply a plain text file in heidi format, called 'HeidiDI', that lists the testing versions for udebs, and commits that daily to the database. That's it, it requires manual updating. This is of course not an ideal situation. Not only requires it manual intervention every time something changes, it also makes the 'sources go in along with all the corresponding binaries' property not true for d-i binaries. When unstable slugs on, udeb's that one might want to have in testing, could be already being removed due to this. My proposal is to maintain the 'sources go in along with all corresponding binaries' property for testing at all times. There are two major cases for d-i binaries: - Source packages with only udebs - Source packages with both debs and udebs Both could be handled just like the other source packages in principle, but a number of assumptions why britney keeps testing in an mostly releaseable state at all times don't go for udebs: dependencies are often inadequate, and so is testing/filing of RC bugs on the correct packages. With the current hints available to the release team though, this can be handled adequately and consistently by them, in stead of via HeidiDI. I think that for now[1] udeb-only sources definitely should get a semi-permanent block hint, and only updated manually via an unblock hint. Mixed packages can go either way, if their maintainers are well aware of the implications of modifying the udeb's, they can be handled as any non-udeb related package. But when gearing up for a release, at least when entering the stage where one thinks about release candidates, those mixed packages are better off with block hints too (a partial freeze). Does anyone see any disadvanteage of this approach to udeb handling? Otherwise, with a realatively simple patch to britney udeb disparities will become something of the past, and the d-i team has by means of Joey Hess the possibility to push the testing set of udeb's into shape easily. --Jeroen [1] While britney cannot accurately enough propgate udeb's automatically -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309367: Syntax error in Build-Depends
Package: elinks Version: 0.10.4-6 Severity: serious | Build-Depends: (...) libgpmg1-dev [] (...) It's actually also unclear what this means, because you don't know whether this is a negative empty list, or a positive empty list. In reality, apt for example, will completely ignore this build depends, while sbuild (what the buildd's use) iirc will assume it needs to be installed. I'm guessing you use some tool to autogenerate build-depends, please don't do that. Build-depends must remain constant over rebuilds of your package, you can use some tool/table to generate them, but you *need* to check the changes before uploading. --Jeroen -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) Versions of packages elinks depends on: ii debconf 1.4.30.13Debian configuration management sy ii libbz2-1.0 1.0.2-6 high-quality block-sorting file co ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an ii libexpat1 1.95.8-3 XML parsing C library - runtime li ii libgnutls10 1.0.4-8 GNU TLS library - runtime library ii libgpmg11.19.6-19General Purpose Mouse - shared lib ii liblua505.0.2-5 Main interpreter library for the L ii liblualib50 5.0.2-5 Extension library for the Lua 5.0 ii zlib1g 1:1.2.2-4compression library - runtime -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#276212: supercollider binaries
reassign 276212 supercollider thanks On Fri, Apr 01, 2005 at 01:02:47PM +0100, Paul Brossier wrote: Hi, I am looking at sorting 290339 out, but for now the archives contains the following broken binaries: 040926-3: hppa mipsel 040926-2: alpha arm ia64 m68k mips s390 sparc thanks for considergin, piem Hm, please reassign back when it's clear what binaries on what archs are broken-beyond-repair, and what not. For now, I really see not enough info to have a definite list of packages to remove, and doing this job only halfly is of no help to anyone. Thanks, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
