Re: etch: dash 0.5.3-7, git-core 1:1.4.4.4-1
On Tue, Feb 06, 2007 at 11:13:04AM +, Gerrit Pape wrote: > please include dash 0.5.3-7 into etch, it's 4 days in sid and only > includes new debconf translations. > Additionally I suggest git-core 1:1.4.4.4-1 for etch. It's a new > upstream point release, 25 days in sid now, fixing some important bugs, > see attachment. Upstream handles point releases quite conservative, and > adds no new features, only fixes. I attach the upstream changes since > 1.4.4.3, currently in etch. The oldest hunk already was included in > 1.4.4.3-1 (#388370). Unblocked. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#409882: changes in upstream
On Tue, Feb 06, 2007 at 01:13:09PM +0100, Robert Millan [ackstorm] wrote: > On Tue, Feb 06, 2007 at 11:43:15AM +0100, Daniel Baumann wrote: > > Robert Millan [ackstorm] wrote: > > > Given all this, would still be possible to consider this for etch ? > > ...which would require another round of main and non-free conglomeration > > packages in NEW, together with removals in testing and unstable of the > > non-free ones. Don't know if we can make this happen as it's not > > depending on me. > Well, what does -release have to say about this? Not a high priority. We might look at it for etch once uploaded, if the changes are reasonable. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please allow jedstate_0.5.4.transitional.1-1 and jed-extra_2.2.1-1.etch.1
On Tue, Feb 06, 2007 at 03:53:20PM -0800, Steve Langasek wrote: > > In sum, this fixes RC Bug#406815 and removes the obsolete and unmaintained > > jedstate code from Debian, so please allow: > > * jedstate_0.5.4.transitional.1-3 > > * jed-extra_2.2.1-1.etch.3 > > in testing. > I've unblocked jed-extra, and am in the process of reviewing jedstate. Reviewing jedstate: Why does debian/NEWS contain two entries that contradict each other? Please drop the older one, and integrate any accurate information into the .1-3 NEWS entry. Why is your postinst forcing the removal of /etc/jed-init.d/99jedstate_hook.sl? Was this a conffile in the old version, and if so, shouldn't any removal handling check whether it's been modified? Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Can reports of serious policy violations be downgraded to important?
On Tue, Feb 06, 2007 at 12:05:46PM +0100, Romain Beauxis wrote:
> Le mardi 6 février 2007 02:47, Philippe Cloutier a écrit :
> > >If you wish to add a RC bug more to debian, please ask to the release
> > > managers if they feel that this should be solved for debian etch.
> > Release team: I believe that #388616 should be upgraded back to serious.
> > Please state that you agree with Romain if the report shouldn't be
> > upgraded back to serious.
> Ok, right I acknowledge the answer from the release team.
> Now here is my anwser:
> I do not feel apropriate to correcet this bug and here is why :
> * The configuration file is not located in /etc and this is a policy
> violation, that is a fact. However, this configuration file is linked in /etc
> so that the administrator can locate it when he needs it.
> * Reports claiming that their configuration files had been deleted by update
> were either users of the previous packaging or users that had a wrong
> documentation. Since those bugs were posted, I corrected documentation. Also,
> on a fresh install, messages after install clearly ask for puting this file
> in /var/lib/mediawiki1.7
> * The reason why I did this rely on this header, on the fresh configuration
> file:
> "if( defined( 'MW_INSTALL_PATH' ) ) {
> $IP = MW_INSTALL_PATH;
> } else {
> $IP = dirname( __FILE__ );
> }"
> From this point, the $IP, which is later taken as include path,
> reflects /etc/mediawiki1.7 as soon as the configuration file is located
> in /etc: php resolves dirname by the real directory name and not the name for
> the directory of the link.
> * I choosed to put the file to /var/lib because I misread the policy, and
> because, under this bad assumption, I choosed the solution which involved the
> less patching. Obviously, adding a
> define(MW_INSTALL_PATH,"/var/lib/mediawiki1.7"° on top of the file is the
> good solution. It is also what is done in my next 1.9 package.
Hmm, unfortunate.
> Now that I have cleared the origins of the bug, let's explain why I do not
> feel appropriate to resolve it:
> * To me the violation is not that severe since the file is located in /etc
> after all. I understand that others may not think the same way, but that is
> my point.
No, policy requires that the *file* be stored in /etc, not a symlink *to*
the file. So this is still a policy violation.
Under the circumstances, I would be willing to grant an etch-ignore
exception for the file location. If the location of the file is still
causing upgrade errors (which seems possible, since the symlinks under
/etc/mediawiki1.7 are not conffiles and therefore may overwrite a user's
config), that would be more than just a technicality, and I wouldn't grant
an etch-ignore exception for that.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please allow jedstate_0.5.4.transitional.1-1 and jed-extra_2.2.1-1.etch.1
On Tue, Feb 06, 2007 at 04:50:16PM +0100, Rafael Laboissiere wrote: > * Rafael Laboissiere <[EMAIL PROTECTED]> [2007-02-06 10:10]: > > * Rafael Laboissiere <[EMAIL PROTECTED]> [2007-02-06 00:06]: > > > * Rafael Laboissiere <[EMAIL PROTECTED]> [2007-02-05 23:29]: > > > > Request (short): > > > > Please, allow jedstate_0.5.4.transitional.1-1 and > > > > jed-extra_2.2.1-1.etch.1 in testing. > > > Update: the version of jedstate currently in unstable is > > > 0.5.4.transitional.1-2 (I added a postinst script to the pacakge). > > New update: the version of jed-extra in unstable is now 2.2.1-1.etch.2. I > > added two lines of autoloads in an itialization file (needed for > > gdbmrecent). The diffs are attached below. > This is the last update, really (or hopefully). > After discussion in the pkg-jed-devel mailing list, we decided to improved > the situation in the following way: the changes made in jed-extra > 2.2.1-1.etch.2 are reverted in 2.2.1-1.etch.3, what makes this later version > virtually the same as 2.2.1-1.etch.1. On the other hand, the jedstate > package now in unstable (0.5.4.transitional.1-3) is now rather "functional" > than "transitional", in the sense that it ensures that the gdbmrecent module > will really work. > In sum, this fixes RC Bug#406815 and removes the obsolete and unmaintained > jedstate code from Debian, so please allow: > * jedstate_0.5.4.transitional.1-3 > * jed-extra_2.2.1-1.etch.3 > in testing. I've unblocked jed-extra, and am in the process of reviewing jedstate. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request freeze exception for illuminator
On Mon, Feb 05, 2007 at 09:59:25AM -0500, Adam C Powell IV wrote: > Please consider illuminator for a freeze exception. It does not build > on HPPA because petsc (which I also maintain) )doesn't build on HPPA, > which in turn is because of a python bug, #354139. Nevertheless, this is a problem that it's your responsibility as maintainer to resolve if you want the package included in the release. If you believe the package should be included in etch without the hppa binary, you need to ask the ftpmasters to remove the old hppa binary from unstable. > Illuminator is bug-free and lintian clean. It went into unstable 9 days > ago, so is scheduled to enter testing tomorrow, if unfrozen. It was > part of sarge and woody, and if at all possible I would like it to be in > etch as well. The time for this issue to have been resolved was three months ago, before the targetted release date, not one week ago (or tomorrow, given that hppa is still not sorted). illuminator at this point has been gone from testing for over a year; I'm not likely to take time away from working on release blockers to consider such an update. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
unfreeze request - radiusclient-ng (0.5.5-1)
debian-release,
This unfreeze request is purely an upstream bug fix for 64-bit architectures.
Without it radiusclient-ng will not operate on 64-bit architectures.
Mark
radiusclient-ng (0.5.5-1) unstable; urgency=medium
* New upstream release
[ Mark Purcell ]
* Urgency medium as this release fixes 64-bit architectures
-- Jan Janak <[EMAIL PROTECTED]> Mon, 5 Feb 2007 13:17:10 +0100
Ignoring Makefile changes the debdiff is:
diff -Nru /tmp/Jk0DjtGJ17/radiusclient-ng-0.5.3/CHANGES
/tmp/WWhXiWNXFX/radiusclient-ng-0.5.5/CHANGES
--- /tmp/Jk0DjtGJ17/radiusclient-ng-0.5.3/CHANGES 2005-03-01
14:58:44.0 +
+++ /tmp/WWhXiWNXFX/radiusclient-ng-0.5.5/CHANGES 2007-02-05
12:54:01.0 +
@@ -1,8 +1,11 @@
-$Id: CHANGES,v 1.2 2005/03/01 14:58:44 janakj Exp $
+$Id: CHANGES,v 1.4 2007/02/05 12:54:01 janakj Exp $
This file only documents fixed bugs and new features.. well, if I am not
too lazy...
+05-02-2006 * 64-bit fixes ported from freeradius-client ([EMAIL
PROTECTED])
+* removed debian/Makefile from configure.in ([EMAIL PROTECTED])
+
01-03-2005 Renamed to radiusclient-ng because the API is different
and this change will make it possible to have the original
libraries installed as well ([EMAIL PROTECTED]).
diff -Nru /tmp/Jk0DjtGJ17/radiusclient-ng-0.5.3/include/radiusclient-ng.h
/tmp/WWhXiWNXFX/radiusclient-ng-0.5.5/include/radiusclient-ng.h
--- /tmp/Jk0DjtGJ17/radiusclient-ng-0.5.3/include/radiusclient-ng.h
2005-07-21 09:01:07.0 +0100
+++ /tmp/WWhXiWNXFX/radiusclient-ng-0.5.5/include/radiusclient-ng.h
2006-05-17 19:14:35.0 +0100
@@ -1,5 +1,5 @@
/*
- * $Id: radiusclient-ng.h,v 1.3 2005/07/21 08:01:07 sobomax Exp $
+ * $Id: radiusclient-ng.h,v 1.5 2006/05/17 18:14:35 sobomax Exp $
*
* Copyright (C) 1995,1996,1997,1998 Lars Fenneberg
*
@@ -18,6 +18,7 @@
#define RADIUSCLIENT_NG_H
#include
+#include
#include
#include
@@ -31,8 +32,8 @@
# define __END_DECLS /* empty */
#endif
-typedef unsigned long UINT4;
-typedef long INT4;
+typedef uint32_t UINT4;
+typedef int32_t INT4;
#define AUTH_VECTOR_LEN16
#define AUTH_PASS_LEN (3 * 16) /* multiple of 16 */
diff -Nru /tmp/Jk0DjtGJ17/radiusclient-ng-0.5.3/lib/avpair.c
/tmp/WWhXiWNXFX/radiusclient-ng-0.5.5/lib/avpair.c
--- /tmp/Jk0DjtGJ17/radiusclient-ng-0.5.3/lib/avpair.c 2005-04-01
02:33:10.0 +0100
+++ /tmp/WWhXiWNXFX/radiusclient-ng-0.5.5/lib/avpair.c 2006-05-30
20:18:03.0 +0100
@@ -1,5 +1,5 @@
/*
- * $Id: avpair.c,v 1.15 2005/04/01 01:33:10 sobomax Exp $
+ * $Id: avpair.c,v 1.17 2006/05/30 19:18:03 sobomax Exp $
*
* Copyright (C) 1995 Lars Fenneberg
*
@@ -130,10 +130,13 @@
case PW_DIGEST_NONCE_COUNT:
case PW_DIGEST_USER_NAME:
/* overlapping! */
+ if (vp->lvalue > AUTH_STRING_LEN - 2)
+ vp->lvalue = AUTH_STRING_LEN - 2;
memmove(&vp->strvalue[2], &vp->strvalue[0],
vp->lvalue);
vp->strvalue[0] = vp->attribute -
PW_DIGEST_REALM + 1;
vp->lvalue += 2;
vp->strvalue[1] = vp->lvalue;
+ vp->strvalue[vp->lvalue] = '\0';
vp->attribute = PW_DIGEST_ATTRIBUTES;
default:
break;
@@ -412,7 +415,8 @@
while (*ptr != '"' && *ptr != '\0' && *ptr != '\n')
{
if (string < estring)
- *string++ = *ptr++;
+ *string++ = *ptr;
+ ptr++;
}
if (*ptr == '"')
{
@@ -426,7 +430,8 @@
while (*ptr != '\0' && strchr(stopat, *ptr) == NULL)
{
if (string < estring)
- *string++ = *ptr++;
+ *string++ = *ptr;
+ ptr++;
}
*string = '\0';
*uptr = ptr;
@@ -453,7 +458,7 @@
{
int mode;
charattrstr[AUTH_ID_LEN];
- charvalstr[AUTH_STRING_LEN];
+ charvalstr[AUTH_STRING_LEN + 1];
DICT_ATTR *attr = NULL;
DICT_VALUE *dval;
VALUE_PAIR *pair;
@@ -594,10 +599,13 @@
case PW_DIGEST_NONCE_COUNT:
case PW_DIGEST_USER_NAME:
/* overlapping! */
+ if (pair->lvalue > AUTH_STRING_LEN - 2)
+ pair->lvalue = AUTH_STRING_LEN - 2;
memmove(&pair->strvalue[2], &pair->strvalue[0],
pair->lvalue);
pair->strvalue
Re: libclucene-dev bug marked etch-ignore???
On Tue, Feb 06, 2007 at 06:35:37PM +, Luis Matos wrote: > Hello there. > I must say that everyone is doing an excellent job taking etch out. > i mailed here because there is a bug in clucene-dev[0] that prevents > anything to compile against it. CPPFLAGS+= -I/usr/lib/CLucene Fixed. > There are some disarranged paths in the header files. > if this bug is not corrected, the package is unusable, so ... i don't > agree with the connotation of etch-ignore on it. > I repeat: This package is completly broke by the bugs that where tagged > etch-ignore. I stand by that statement. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
wine 0.9.25-2
Ove just uploaded wine 0.9.25-2 to t-p-u. A debdiff is attached (with the
amd64.tar.lzma.uu part stripped out, of course).
On Fri, Jan 26, 2007 at 09:06:29PM +0100, Robert Millan wrote:
>
> Hi!
>
> I would like to request permission for amd64 support to be backported from
> wine 0.9.29-1 to the version currently in testing, 0.9.25-1.
>
> While discussing this with Steve on IRC, after getting his disapproval, we
> agreed to continue the discussion via mail since I wanted to explain an
> ellaborate argument and prefer it archived as to avoid repeating it.
>
> My understanding is that for each proposal you weight the necessity of the
> proposed change against the chances it has to produce breakage, and the
> magnitude of such. I'll try to explain why I think all three factors should
> be considered in favour of wine on amd64.
>
> I suspect that the time you spend reading this is another factor, so I'll
> try to be brief :-)
>
> Necessity of wine on amd64
> ~~
>
> The thing about amd64 support in wine, that makes it IMHO so much important,
> is that there's a timeline for this feature. It's been predicted [1] that
> the 64-bit migration will be finished in the desktop by late 2008. This
> means etch is the release that will have to go through it.
>
> Because of Microsoft serious problems producing a 64-bit port of their OS,
> we have a great opportunity for expansion in the desktop area, which is
> basicaly composed of users with strong dependance on win32 support (games).
>
> If our amd64 distribution ships without wine, they'll either go for other
> distributions (with a shorter release cycle, they'll all end up providing
> it, or at least Ubuntu will), or be trapped with Microsoft untill the Evil
> Empire[tm] has figured out how to get 64-bit drivers and 3rd party apps.
>
> Of course, this isn't very relevant to our existing userbase; those who
> want it can get wine from backports.org whatsoever. But I think it seriously
> undermines our ability to expand in this area.
>
> [1] based on extrapolation from Moore's law against 4 GiB barrier, see:
> http://catb.org/~esr/writings/world-domination/world-domination-201.html
>
> Chances to produce breakage
> ~~~
>
> Minimal. I admit my patch is really dirty (during i386 build, puts everything
> in debian/amd64.tar.lzma.uu; during amd64 build, just untars instead of
> building), but it also has very small chance of breaking something. Since
> my patch doesn't touch a single line of code, binaries are exactly the same,
> compiled in the same environment.
>
> Magnitude of hypothetical breakage (in case there was such)
> ~~~
>
> AFAICS only xwine depends on it. If it breaks, its only one package.
>
> --
> Robert Millan
>
> My spam trap is [EMAIL PROTECTED] Note: this address is only intended
> for spam harvesters. Writing to it will get you added to my black list.
--
Robert Millan
My spam trap is [EMAIL PROTECTED] Note: this address is only intended
for spam harvesters. Writing to it will get you added to my black list.
diff -u wine-0.9.25/debian/changelog wine-0.9.25/debian/changelog
--- wine-0.9.25/debian/changelog
+++ wine-0.9.25/debian/changelog
@@ -1,3 +1,13 @@
+wine (0.9.25-2) testing-proposed-updates; urgency=low
+
+ * Added amd64 build hack by Robert Millan (from #381341,
+#408433, #408539), which encode the i386 binaries into
+the diff and then just decode them for the amd64 build,
+to work around difficulties with building a 32-bit package
+on amd64.
+
+ -- Ove Kaaven <[EMAIL PROTECTED]> Mon, 5 Feb 2007 05:07:44 -0500
+
wine (0.9.25-1) unstable; urgency=low
* New upstream release 0.9.25.
diff -u wine-0.9.25/debian/control wine-0.9.25/debian/control
--- wine-0.9.25/debian/control
+++ wine-0.9.25/debian/control
@@ -20,11 +20,12 @@
libicu36-dev | libicu34-dev (>= 3.4-4) | libicu28-dev | libicu21-dev,
libfontconfig1-dev, libssl-dev, libcapi20-dev (>= 1:3.3.0.20041024-2) [!kfreebsd-i386 !kfreebsd-amd64 !hurd-i386],
libhal-dev, libdbus-1-dev | dbus-1-dev, libgphoto2-2-dev, liblcms1-dev, libldap2-dev,
- libxml2-dev, libxslt1-dev, fontforge, prelink
+ libxml2-dev, libxslt1-dev, fontforge, prelink,
+ lzma, sharutils
Standards-Version: 3.6.0
Package: wine
-Architecture: i386 hurd-i386 kfreebsd-i386 netbsd-i386 powerpc hurd-powerpc kfreebsd-powerpc netbsd-powerpc sparc hurd-sparc kfreebsd-sparc netbsd-sparc
+Architecture: i386 hurd-i386 kfreebsd-i386 netbsd-i386 amd64 powerpc hurd-powerpc kfreebsd-powerpc netbsd-powerpc sparc hurd-sparc kfreebsd-sparc netbsd-sparc
Depends: ${debconf-depends}, libwine (= ${Source-Version}), xbase-clients (>= 4.0) | xcontrib
Recommends: wine-utils, msttcorefonts
Suggests: wine-doc, binfmt-support
@@ -40,7 +41,7 @@
Wine is often updated.
Package: libwine-dev
-Architecture: i386 hurd-i386 kfreebsd-i386 netbsd-i386 powerpc hurd-powerpc kfreebsd-powerpc netbs
unfreeze request - knemo (0.4.6-2)
knemo (0.4.6-2) unstable; urgency=high [ Mark Purcell ] * Urgency high as this fixes multiple RC bugs * fd-leakage patch from Matthias Dellweg - (Closes: Bug#409707: knemo: fd-leakage in sys backend) -- Debian KDE Extras Team <[EMAIL PROTECTED]> Tue, 6 Feb 2007 11:05:03 + pgpPzmjtwDidP.pgp Description: PGP signature
Re: Bug#409952: azureus: Allocates too big heap
On 2/6/07, tuomov <[EMAIL PROTECTED]> wrote: Package: azureus Version: 2.5.0.0+0-1 Severity: important ~$ azureus Error occurred during initialization of VM Could not reserve enough space for object heap Could not create the Java virtual machine. It seems to allocate a insanely huge heap, by setting JAVA='java -Xmx1024M' in /usr/bin/azureus. Setting this to a lower value, such as 256M, fixes the problem. The -Xmx1024M patch was originally applied to close `Bug#386765: azureus: Torrents with large number of files cause Azureus to exceed default heap size'. The default value for the Sun JVM is 64 MB. A value of 256 MB seems reasonable. Since it's a trivial change, should this patch be pushed into Etch? Cheers, Shaun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please move backuppc 2.1.2-6
Ludovic Drolez wrote: > Hi ! > > Please move backuppc_2.1.2-6 currently in unstable, into the frozen Etch > release. > > The only differences between 2.1.2-6 and 2.1.2-5 are: > - an important bugfix which makes backups fail even if there's no error (1 > line patch). This could make backuppc completely useless for some kind of > backups. See [1] > - an updated README.Debian. Unblocked. Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Please move backuppc 2.1.2-6
Hi ! Please move backuppc_2.1.2-6 currently in unstable, into the frozen Etch release. The only differences between 2.1.2-6 and 2.1.2-5 are: - an important bugfix which makes backups fail even if there's no error (1 line patch). This could make backuppc completely useless for some kind of backups. See [1] - an updated README.Debian. Best regards, Ludovic. [1]. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407785 -- Ludovic Drolez. http://zaurus.palmopensource.com- The Zaurus Open Source Portal http://www.drolez.com - Personal site - Linux and PalmOS stuff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: please allow wallpaper-tray/0.4.6-5 into Etch
Jon Dowland wrote: > Hello there, > > I have prepared wallpaper-tray 0.4.6-5 which is now in > unstable in order to squash two important bugs for Etch. Unblocked. Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: Please allow a freeze exception for Zabbix
Fabio Tranchitella wrote: > Dear RMs, > please allow a freeze exception for zabbix. Already unblocked. Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: Please allow freeze exceptions for the following packages
Fabio Tranchitella wrote: > Dear RMs, > considering the long freeze period, I waited for submitting my freeze > exception requests untill now to minimize your efforts: this is the reason why > this e-mail contains several requests. All these packages waited in unstable > for more than 10 days, and some of them even more than 20 days. > > Please allow freeze exceptions for the following packages: > > # mapserver (from 4.10.0-4 to 4.10.0-5) Unblocked > # phpldapadmin (from 0.9.8.3-7 to 0.9.8.3-8) Unblocked > # psycopg2 (from 2.0.5.1-5 to 2.0.5.1-6) Unblocked > # zope-common (from 0.5.28 to 0.5.31) Unblocked > # zope-debhelper (from 0.3.4 to 0.3.6) Unblocked > # zope-cmfplone (from 2.5.1-3 to 2.5.1-4) Unblocked > # zope2.9 (from 2.9.6-2 to 2.9.6-3) Unblocked > # zope3 (from 3.3.0-5 to 3.3.0-6) Unblocked > # zope-plonecollectorng (from 1.2.9-1 to 1.2.9-2) Unblocked > # zope-exuserfolder (from 0.50.1-5 to 0.50.1-6) Unblocked Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: Please allow tex-common translation updates to migrate
Frank Küster wrote: > Dear release team, > > please > > unblock tex-common/1.0 Unblocked. Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: unfreeze request - libexosip2 (2.2.3-2)
Mark Purcell wrote: > libexosip2 (2.2.3-2) unstable; urgency=low >* libexosip2-dev Depends: libosip2-dev > - Fixes: missing dependency on libosip2-dev (Closes: #393637) > > -- Mark Purcell <[EMAIL PROTECTED]> Sat, 9 Dec 2006 13:06:51 + Unblocked. Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: unfreeze request - kdmtheme (1.1.2-2)
Mark Purcell wrote: > kdmtheme (1.1.2-2) unstable; urgency=low >[ Mark Purcell ] >* Add debian/rules get-orig-source target for http://buildserver.net. > >[ Fathi Boudra ] >* Add a patch to warn users about kdm override files introduced with > desktop-base. Thanks to Sune Vuorela. > > -- Fathi Boudra <[EMAIL PROTECTED]> Wed, 31 Jan 2007 21:11:45 +0100 Unblocked. Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
libclucene-dev bug marked etch-ignore???
Hello there. I must say that everyone is doing an excellent job taking etch out. i mailed here because there is a bug in clucene-dev[0] that prevents anything to compile against it. There are some disarranged paths in the header files. if this bug is not corrected, the package is unusable, so ... i don't agree with the connotation of etch-ignore on it. I repeat: This package is completly broke by the bugs that where tagged etch-ignore. Thank you release Managers. [0] http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=libclucene-dev best regards Luis Matos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: unfreeze request - asterisk-spandsp-plugins (0.0.20060218-4)
Mark Purcell wrote: > asterisk-spandsp-plugins (0.0.20060218-4) unstable; urgency=low >* Fix #407203: make receive_fax be always shipped executable. > > -- Kilian Krause <[EMAIL PROTECTED]> Tue, 16 Jan 2007 22:08:40 +0100 > asterisk-spandsp-plugins (0.0.20060218-3) unstable; urgency=low >* Fix reference of README in faxreceive.conf (Closes: #362309) >* Fix location of faxreceive.conf in receive_fax >* Fix missing counters folder causing script to choke (Closes: #366536) >* Make sure we don't build or install against spandsp 0.0.3. This will > segfault in rxfax's fax_init call (line 281) > > -- Kilian Krause <[EMAIL PROTECTED]> Wed, 3 Jan 2007 21:18:31 +0100 Unblocked. Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: unfreeze request - smstools (3.0.2-3)
Mark Purcell wrote: > smstools (3.0.2-3) unstable; urgency=medium >* Urgency medium as this clears a bug in the upgrade path: > Added prerm script to handle upgrade from 3.0-1 to this version > (Closes: #403615) --- smstools-3.0.2.orig/debian/prerm +++ smstools-3.0.2/debian/prerm @@ -0,0 +1,6 @@ +#!/bin/sh +set -e + +if ! "$1" = 'failed-upgrade'; then + #DEBHELPER# +fi This looks not right as it will try to execute $1, which will probably already fail with an error message AFAICS... I doubt this is tested, though feel free to prove me wrong :-) Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: debian-installer build deps testing/unstable divergences
Steve Langasek wrote: > These changes include a bump to the debhelper compat level with no apparent > rationale, in addition to the extensive upstream changes; I'm not > comfortable unblocking this (and it hardly seems I would have a chance to > anyway, we're already at version 1.4.15 in unstable now). It sounds like > any differences between the two versions are already worked around, so that > this shouldn't be an issue for d-i? Well, it still remains a problem if d-i images include a version of apex that is not included in testing.. -- see shy jo signature.asc Description: Digital signature
Re: unfreeze request - opal (2.2.3.dfsg-3)
Mark Purcell wrote: > opal (2.2.3.dfsg-3) unstable; urgency=high >* Conflict with openmpi-dev to make sure we don't have a filename clash > (Closes: #404004). Setting high urgency due to RC-bug. Unblocked Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
please allow wallpaper-tray/0.4.6-5 into Etch
Hello there, I have prepared wallpaper-tray 0.4.6-5 which is now in unstable in order to squash two important bugs for Etch. The diffstat output might scare you: > 12 files changed, 4658 insertions(+), 3338 deletions(-) however, virtually all of this is regenerated ./configure, ./configure.in and ./config.h.in as a result of a one-line change to ./configure.ac to fix RC bug #382784. The other changes are very small indeed. Excluding the aformentioned regenerations and ./debian: > 2 files changed, 8 insertions(+), 5 deletions(-) These are trivial fixes for important bug #375168 and housekeeping #404231. Please allow wallpaper-tray 0.4.6-5 into Etch. -- Jon Dowland signature.asc Description: Digital signature
Re: Please unblock prc-tools 2.3-1.1
Christian Perrier wrote: > Dear release team, > > I have just uploaded a NMU of prc-tools, to fix its pending l10n > issues (and, if needed, very minor QA issues). > > Could you consider hinting it to enter testing? Not unblocked as it is RC-buggy anyway and not in testing for a long time. Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: maildrop lacking courier-authlib dependency on amd64, still
On Tue, Feb 06, 2007 at 02:22:06PM +0100, Josip Rodin wrote: > > > > BTW, couldn't this also be addressed just by adding a > > -l/usr/lib/courier-authlib option to dh_shlibdeps? That seems to work too. > Why does this only happen on amd64? I don't really want an > architecture-specific kludge in the package, let's fix the tools to be > consistent. Or at least produce useful error information (e.g. crapping out > instead of letting bad things pass). The version you're using of libtool does not work properly (on amd64). It's also mixing various versions, and I have to wonder why not more is broken. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removing quake2-data from etch
Jamie Wilkinson wrote: This one time, at band camp, Andreas Metzler wrote: On a sidenote: Jamie, how about orphaning quake2-data and quake, afaict you have not been maintaining it actively for a couple of years. I see no harm in the current state. I've only recently begun to have enough time to manage packages again in the last 4 years, so hopefully this will see improvement. I have no objection to others maintaining these packages through NMUs, however, and thus I see no reason to orphan them. Would you consider joining and co-maintaining these packages as part of the Debian games team (list CCed and FU'd)? There is a lot of potential cross-pollination that can occur there with these packages, particularly -data (as we are working on combined, generic data installer packages for such things). -- Jon Dowland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Permission to upload gnotime to testing-proposed-updates
Em Seg, 2007-02-05 às 03:26 -0800, Steve Langasek escreveu:
> On Fri, Feb 02, 2007 at 04:14:31PM -0200, Goedson Teixeira Paixao wrote:
>
> > I've upload gnotime 2.2.2-10 to sid a few days ago with the intention of
> > getting it into Etch. I've now realised it won't be possible to migrate
> > it into Etch through Sid because one of its dependencies (libqof1) is a
> > newer upstream version in Sid. So I'm here asking permission to upload a
> > rebuild of this revision against Etch libraries into
> > testing-proposed-updates so that it can be released with Etch.
>
> Why is the newer upstream version of libqof1 a problem? There apparently
> wasn't a shlibs bump, because britney doesn't report libqof1 as a blocker
> for gnotime in unstable -- which means either there are no ABI changes in
> that new upstream version, or libqof1 has an unfiled RC bug.
Looking closer at the issue now, I see it is not a problem. I thought
the dependency on libqof1 would be versioned, but it is not. So I ask
you to hint gnotime into Etch.
> Separately, the changes to src/app.c seem pretty large, and I'm not sure I'm
> comfortable including such an update; it looks to me like a rather large
> diff for the fix described.
The large size of the diff is, in part, due to differences in the
indentation of lines. Attached you'll find a diff file that contains the
real patch.
OK. It's still large, so let me explain why it is so. The status bar of
the application was built using two GtkStatusbar widgets, one for the
"total time worked today" and one for the current project. The problem
is GtkStatusBar won't ask for more space when it needs, truncating the
text if it doesn't fit in its current width. My options were: 1 - Keep
the GtkStatusbar and use Pango to calculate their width each time the
text or font width changes; or 2 - substitute GtkStatusbars by
GtkLabels, which already do the needed calculations and sets its width
accordingly. I've opted for the second option because it would make
status bar updating code a lot simpler.
As for you not feeling comfortable introducing such an update, I'd like
to note that I and some of my co-workers are using this version of the
code daily since a little before the upload to Sid. So it's already more
than one month running with no known issues originating from this
change.
Best regards,
--
Goedson Teixeira Paixao http://mundolivre.wordpress.com/
Debian Project http://www.debian.org/
Jabber ID: [EMAIL PROTECTED]http://www.jabber.org/
--- ../gnotime-2.2.2/src/app.c 2007-02-06 11:03:53.0 -0200
+++ src/app.c 2007-02-06 11:36:20.0 -0200
@@ -57,8 +57,8 @@
GtkWidget *app_window = NULL;
GtkWidget *status_bar = NULL;
-static GtkStatusbar *status_project = NULL;
-static GtkStatusbar *status_day_time = NULL;
+static GtkLabel *status_project = NULL;
+static GtkLabel *status_day_time = NULL;
static GtkWidget *status_timer = NULL;
char *config_shell_start = NULL;
@@ -76,8 +76,6 @@
update_status_bar(void)
{
char day_total_str[25];
- static char *old_day_time = NULL;
- static char *old_project = NULL;
char *s;
if (!status_bar) return;
@@ -92,29 +90,15 @@
gtk_widget_hide(status_timer);
}
- if (!old_day_time) old_day_time = g_strdup("");
- if (!old_project) old_project = g_strdup("");
-
/* update timestamp */
qof_print_hours_elapsed_buff (day_total_str, 25,
gtt_project_list_total_secs_day(), config_show_secs);
- s = g_strdup(day_total_str);
- if (0 != strcmp(s, old_day_time))
- {
- // fprintf(stderr, "before %s\n", s);
- gtk_statusbar_pop(status_day_time, 0);
- gtk_statusbar_push(status_day_time, 0, s);
-// fprintf(stderr, "after %s\n", s);
- g_free(old_day_time);
-// fprintf(stderr, "after gfree %s\n", s);
- old_day_time = s;
- }
- else
- {
- g_free(s);
- }
-
+ if (0 != strcmp(day_total_str, gtk_label_get_text(status_day_time)))
+ {
+gtk_label_set_text(status_day_time, day_total_str);
+ }
+
/* Display the project title */
if (cur_proj)
{
@@ -127,21 +111,11 @@
s = g_strdup(_("Timer is not running"));
}
- if (0 != strcmp(s, old_project))
+ if (0 != strcmp(s, gtk_label_get_text(status_project)))
{
-
- // fprintf(stderr, "before %s\n", s);
- gtk_statusbar_pop(status_project, 0);
- gtk_statusbar_push(status_project, 0, s);
-// fprintf(stderr, "after %s\n", s);
- g_free(old_project);
-// fprintf(stderr, "after g_free %s\n", s);
- old_project = s;
- }
- else
- {
- g_free(s);
+ gtk_label_set_text(status_project, s);
}
+ g_free(s);
}
@@ -275,6 +249,11 @@
GtkWidget *vbox;
GtkWidget *widget;
GtkWidget *vpane;
+GtkWidget *separator;
+GtkLabel *filler;
+GtkHBox *labels;
+GtkVBox *status_vbox;
+GtkStatusbar *grip;
app_window = gnome_app_new(GTT_APP_NAME, GTT_APP_TITLE " " VERSION);
gtk_window_set_wmclass(GTK_WINDOW(app_window),
@@ -296,32 +275,44 @@
vbox = gtk_vbox_n
Re: Please allow jedstate_0.5.4.transitional.1-1 and jed-extra_2.2.1-1.etch.1
* Rafael Laboissiere <[EMAIL PROTECTED]> [2007-02-06 10:10]: > * Rafael Laboissiere <[EMAIL PROTECTED]> [2007-02-06 00:06]: > > > * Rafael Laboissiere <[EMAIL PROTECTED]> [2007-02-05 23:29]: > > > > > Request (short): > > > > > > Please, allow jedstate_0.5.4.transitional.1-1 and > > > jed-extra_2.2.1-1.etch.1 in testing. > > > > Update: the version of jedstate currently in unstable is > > 0.5.4.transitional.1-2 (I added a postinst script to the pacakge). > > New update: the version of jed-extra in unstable is now 2.2.1-1.etch.2. I > added two lines of autoloads in an itialization file (needed for > gdbmrecent). The diffs are attached below. This is the last update, really (or hopefully). After discussion in the pkg-jed-devel mailing list, we decided to improved the situation in the following way: the changes made in jed-extra 2.2.1-1.etch.2 are reverted in 2.2.1-1.etch.3, what makes this later version virtually the same as 2.2.1-1.etch.1. On the other hand, the jedstate package now in unstable (0.5.4.transitional.1-3) is now rather "functional" than "transitional", in the sense that it ensures that the gdbmrecent module will really work. In sum, this fixes RC Bug#406815 and removes the obsolete and unmaintained jedstate code from Debian, so please allow: * jedstate_0.5.4.transitional.1-3 * jed-extra_2.2.1-1.etch.3 in testing. -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian-installer build deps testing/unstable divergences
On Mon, Feb 05, 2007 at 03:14:25AM -0500, Joey Hess wrote: > These are d-i build deps that provide files that go on d-i images, that > currently have different versions in unstable and testing. The > significance is that since rc2 will be built on the autobuilders, it > will build against the unstable versions of these packages. > libc6 | 2.3.6.ds1-10 | testing | amd64, arm, hppa, i386, m68k, > mips, mipsel, powerpc, s390, sparc > libc6 | 2.3.6.ds1-10 | unstable | m68k, s390, sparc > libc6 | 2.3.6.ds1-11 | unstable | amd64, arm, hppa, i386, mips, > mipsel, powerpc > IIRC this is targeted at testing, so no problem. > libnewt-pic | 0.52.2-9 | testing | alpha, amd64, arm, hppa, i386, > ia64, m68k, mips, mipsel, powerpc, s390, sparc > libnewt-pic | 0.52.2-10 | unstable | alpha, amd64, arm, hppa, > hurd-i386, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc > No significant to d-i changes according to the changelog.. Both approved. > syslinux | 3.31-1 | testing | source, amd64, i386 > syslinux | 3.31-2 | unstable | source, amd64, i386 > A fun new feature that would be nice for amd64+i386 CDs, if it is > allowed into testing. Already unblocked by Luk. > apex-nslu2 | 1.4.7 | testing | arm > apex-nslu2 | 1.4.14 | unstable | arm > Several changes. (New version also makes d-i FTBFS though that should be > easy to fix.) These changes include a bump to the debhelper compat level with no apparent rationale, in addition to the extensive upstream changes; I'm not comfortable unblocking this (and it hardly seems I would have a chance to anyway, we're already at version 1.4.15 in unstable now). It sounds like any differences between the two versions are already worked around, so that this shouldn't be an issue for d-i? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: maildrop lacking courier-authlib dependency on amd64, still
On Tue, Feb 06, 2007 at 04:31:35AM -0800, Steve Langasek wrote: > > > [EMAIL PROTECTED]:~$ dpkg -x maildrop_2.0.3-1_amd64.deb tmp/maildrop/ > > > [EMAIL PROTECTED]:~$ objdump -x tmp/maildrop/usr/bin/maildrop | grep auth > > > NEEDED libcourierauth.so.0 > > > RPATH /usr/lib:/usr/lib/courier-authlib > > > You need to either: > > - Fix dpkg-shlibdeps to look at all rpath entries. > > - Prevent /usr/lib from being in the rpath, or atleast have > > /usr/lib/courier-authlib as first in it. > > > The suggested way for the later is upgrading your libtool > > version. It seems this was done _partialy_. Lots of the aclocal.m4 > > files still contain old copies of it. > > Hrm, oh. Sorry, cancelling the binNMU then. > > BTW, couldn't this also be addressed just by adding a > -l/usr/lib/courier-authlib option to dh_shlibdeps? Why does this only happen on amd64? I don't really want an architecture-specific kludge in the package, let's fix the tools to be consistent. Or at least produce useful error information (e.g. crapping out instead of letting bad things pass). -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Please allow a freeze exception for Zabbix
Dear RMs, please allow a freeze exception for zabbix. unblock zabbix/1:1.1.4-8 The current version in unstable is 1:1.1.4-8 while the version in etch is 1:1.1.4-2. The changelog entries between these releases are: """ zabbix (1:1.1.4-8) unstable; urgency=high . * debian/patches/CVE-2007-0640.dpatch: fix buffer overflow related to SNMP IP Address Handling as described in CVE-2007-0640. Closes: #409257 zabbix (1:1.1.4-7) unstable; urgency=high . * Manage configuration files for zabbix-agent and zabbix-frontend-php with ucf in order to prevent user specified data to be overwritten on package Upgrade. (Closes: #408489) * Add ucf to dependencies. zabbix (1:1.1.4-6) unstable; urgency=medium . * Restarting zabbix agent and server after logrotation is not neccessary, should also resolve problems with agents stopping during said task (Closes: #398405) * Disable internal logrotation again. zabbix (1:1.1.4-5) unstable; urgency=medium . * debian/po/pt.po: added, thanks to Miguel Figueiredo. (Closes: #407226) * debian/zabbix-frontend-php.postrm: fail gracefully if debconf is not available anymore at purge time. * debian/zabbix-server-mysql.postrm: fail gracefully if ucf is not available anymore at purge time. * debian/zabbix-server-pgsql.postrm: fail gracefully if ucf is not available anymore at purge time. zabbix (1:1.1.4-4) unstable; urgency=low . * debian/control: zabbix-frontend-php should depend on both php[54]-mysql and php[54]-pgsql, as well as php[54]-cgi. (Closes: #406750). zabbix (1:1.1.4-3) unstable; urgency=low . * Do not install useless manpage templates. * Set the default zabbix server in agent configuration to "localhost". """ All the changes are targeted etch, and fixes several small and big issues which should be addressed before the release. Specifically, the last upload fixes a buffer overflow. Thanks in advance, -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 signature.asc Description: Digital signature
Re: maildrop lacking courier-authlib dependency on amd64, still
On Mon, Feb 05, 2007 at 08:54:28PM +0100, Kurt Roeckx wrote: > On Sun, Feb 04, 2007 at 11:54:47PM +, Stephen Gran wrote: > > [EMAIL PROTECTED]:~$ dpkg -x maildrop_2.0.3-1_amd64.deb tmp/maildrop/ > > [EMAIL PROTECTED]:~$ objdump -x tmp/maildrop/usr/bin/maildrop | grep auth > > NEEDED libcourierauth.so.0 > > RPATH /usr/lib:/usr/lib/courier-authlib > You need to either: > - Fix dpkg-shlibdeps to look at all rpath entries. > - Prevent /usr/lib from being in the rpath, or atleast have > /usr/lib/courier-authlib as first in it. > The suggested way for the later is upgrading your libtool > version. It seems this was done _partialy_. Lots of the aclocal.m4 > files still contain old copies of it. Hrm, oh. Sorry, cancelling the binNMU then. BTW, couldn't this also be addressed just by adding a -l/usr/lib/courier-authlib option to dh_shlibdeps? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: maildrop lacking courier-authlib dependency on amd64, still
On Mon, Feb 05, 2007 at 12:09:03AM +0100, Josip Rodin wrote: > Can someone please suggest a proper solution to #395529? > What happened there, really? Why is the package not getting built properly > on amd64 only? > % cd debian/pool/main/m/maildrop > % for i in maildrop_2.0.2-11_*.deb; do dpkg -I $i | grep Depends | grep -q > courier-authlib || echo $i; done > maildrop_2.0.2-11_amd64.deb > % for i in maildrop_2.0.3-1_*.deb; do dpkg -I $i | grep Depends | grep -q > courier-authlib || echo $i; done > maildrop_2.0.3-1_amd64.deb Well, since the amd64 binary was autobuilt, we have a build log we can compare with: http://buildd.debian.org/fetch.cgi?pkg=maildrop;ver=2.0.2-11;arch=amd64;stamp=1160374704 The lib dep is brought in by courier-authlib-dev, a correct build-dep of the package. At the time of the build, 0.58-4 was the current version of courier-authlib on amd64, which is still the current version in testing. The build log shows that in spite of courier-authlib 0.58-4 being installed, shlibs for libcourierauth.so.0 couldn't be found: dh_shlibdeps -pmaildrop dpkg-shlibdeps: warning: could not find any packages for libcourierauth.so.0 dpkg-shlibdeps: warning: unable to find dependency information for shared library libcourierauth (soname 0, path libcourierauth.so.0, dependency field Depends) But unpacking this version of courier-authlib shows that it *does* contain correct shlibs: libcourierauth 0 courier-authlib So the only available explanations I see are either a buildd error, or a dpkg bug. Either way, a binNMU should be sufficient to address the problem, so I've scheduled one. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#409882: changes in upstream
On Tue, Feb 06, 2007 at 11:43:15AM +0100, Daniel Baumann wrote: > Robert Millan [ackstorm] wrote: > > Given all this, would still be possible to consider this for etch ? > > ...which would require another round of main and non-free conglomeration > packages in NEW, together with removals in testing and unstable of the > non-free ones. Don't know if we can make this happen as it's not > depending on me. Well, what does -release have to say about this? Btw, nice to see my work address is working well for you. Feel free to use that anytime. -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#409882: changes in upstream
Robert Millan [ackstorm] wrote: > Well, what does -release have to say about this? just for the sake of clarity: the conglomeration packages i can upload myself, but i have (oviously) no influence on NEW handling and testing migration, so RM may say if they would like to help getting it in. > Btw, nice to see my work address is working well for you. Feel free to use > that anytime. :) -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debian-arabic-packages] Re: Request to include to l10n packages in Etch
Hi, I'll thank you, if you do the same with aspell-hy. Recently I've submitted a patch for gedit (#406794) to support aspell-hy, and if you accept to enter aspell-hy in Etch, it would be nice. Thanks, Alan > On Sat, Feb 03, 2007 at 11:43:17AM +0200, Lior Kaplan wrote: >> During the last 5 months the Debian Arabic people worked towards >> improving the Arabic support in Debian. > >> Please consider to include in Etch some of the new packages which were >> uploaded to Unstable. > >> aspell-ar-large - 49 days in unstable, not present in Etch. >> ttf-freefarsi - 50 days in unstable, not preset in Etch. > >> Both missed the Etch freeze by only a few days... > > More than "a few" days; both were uploaded after the archive was frozen > (which means, well after the original target release date). > > I've unblocked them anyway on the grounds that these are data packages > whose > impact should be minimal -- and because they can be removed again from the > release if any RC bugs appear. > > -- > Steve Langasek Give me a lever long enough and a Free OS > Debian Developer to set it on, and I can move the world. > [EMAIL PROTECTED] http://www.debian.org/ > > ___ > Debian-arabic-packages mailing list > [EMAIL PROTECTED] > http://lists.alioth.debian.org/mailman/listinfo/debian-arabic-packages > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Please allow freeze exceptions for the following packages
Dear RMs, considering the long freeze period, I waited for submitting my freeze exception requests untill now to minimize your efforts: this is the reason why this e-mail contains several requests. All these packages waited in unstable for more than 10 days, and some of them even more than 20 days. Please allow freeze exceptions for the following packages: # mapserver (from 4.10.0-4 to 4.10.0-5) # * debian/po/de.po: added, thanks to Alwin Meschede. (Closes: #405727) unblock mapserver/4.10.0-5 # phpldapadmin (from 0.9.8.3-7 to 0.9.8.3-8) # * Applied upstream patch to fix vCard exports. Thanks to Jamin W. Collins # * for providing the exact url of the patch. (Closes: #405964) unblock phpldapadmin/0.9.8.3-8 # psycopg2 (from 2.0.5.1-5 to 2.0.5.1-6) # * debian/zope-psycopgda2.dzproduct: requires Zope 2.9 or higher: previous #versions use python2.3 which is not supported anymore in psycopg. unblock psycopg2/2.0.5.1-6 # zope-common (from 0.5.28 to 0.5.31) # * fixes two grave bugs while upgrading from previous releases # * debian/control: Depend on the unversioned python package. unblock zope-common/0.5.31 # zope-debhelper (from 0.3.4 to 0.3.6) # * fixes a grave but while upgrading pre-packaged zope instances # * fixed a bug in the postrm maintainer scripts if debconf is not #available anymore when purge is called. unblock zope-debhelper/0.3.6 # zope-cmfplone (from 2.5.1-3 to 2.5.1-4) # * rebuilt with zope-debhelper/0.3.6 unblock zope-cmfplone/2.5.1-4 # zope-cmfplone (from 2.5.1-3 to 2.5.1-4) # * rebuilt with zope-debhelper/0.3.6 unblock zope-cmfplone/2.5.1-4 # zope2.9 (from 2.9.6-2 to 2.9.6-3) # * rebuilt with zope-debhelper/0.3.6 unblock zope2.9/2.9.6-3 # zope3 (from 3.3.0-5 to 3.3.0-6) # * rebuilt with zope-debhelper/0.3.6 unblock zope2.9/3.3.0-6 # zope-plonecollectorng (from 1.2.9-1 to 1.2.9-2) # * dropped indirect dependency on python2.4, as requested by doko. unblock zope-plonecollectorng/1.2.9-2 # zope-exuserfolder (from 0.50.1-5 to 0.50.1-6) # * debian/po/de.po: added, thanks to Helge Kreutzman. (Closes: #407486) unblock zope-exuserfolder/0.50.1-6 Thanks, -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 signature.asc Description: Digital signature
Re: egroupware for etch
On Sun, Feb 04, 2007 at 09:29:06AM +0100, Peter Eisentraut wrote: > Steve Langasek wrote: > > Yes, I'm afraid I can't view this as a routine "maintenance release" > > with changes of this scope, and don't believe it's appropriate to > > allow this update into etch at this point of the freeze. > > > Prehaps just the patches for php5.2 could be applied. > > I would accept that for consideration via t-p-u, along with the added > > debconf translation. > Then you might as well remove the package from etch because no one in > their right mind is going to want to use or maintain that. Suit yourself; if that's your position as the maintainer, it doesn't exactly bode well for security support post-release if it were to be kept in. Hinted for removal. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
etch: dash 0.5.3-7, git-core 1:1.4.4.4-1
Hi,
please include dash 0.5.3-7 into etch, it's 4 days in sid and only
includes new debconf translations.
Additionally I suggest git-core 1:1.4.4.4-1 for etch. It's a new
upstream point release, 25 days in sid now, fixing some important bugs,
see attachment. Upstream handles point releases quite conservative, and
adds no new features, only fixes. I attach the upstream changes since
1.4.4.3, currently in etch. The oldest hunk already was included in
1.4.4.3-1 (#388370).
Thanks, Gerrit.
commit 8977c110b5bbd230c28c727ddb85856067d55cfb
Author: Junio C Hamano <[EMAIL PROTECTED]>
Date: Wed Jan 3 23:09:08 2007 -0800
pack-check.c::verify_packfile(): don't run SHA-1 update on huge data
Running the SHA1_Update() on the whole packfile in a single call
revealed an overflow problem we had in the SHA-1 implementation
on POWER architecture some time ago, which was fixed with commit
b47f509b (June 19, 2006). Other SHA-1 implementations may have
a similar problem.
The sliding mmap() series already makes chunked calls to
SHA1_Update(), so this patch itself will become moot when it
graduates to "master", but in the meantime, run the hash
function in smaller chunks to prevent possible future problems.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
diff --git a/pack-check.c b/pack-check.c
index c0caaee..8e123b7 100644
--- a/pack-check.c
+++ b/pack-check.c
@@ -1,16 +1,18 @@
#include "cache.h"
#include "pack.h"
+#define BATCH (1u<<20)
+
static int verify_packfile(struct packed_git *p)
{
unsigned long index_size = p->index_size;
void *index_base = p->index_base;
SHA_CTX ctx;
unsigned char sha1[20];
- unsigned long pack_size = p->pack_size;
- void *pack_base;
struct pack_header *hdr;
int nr_objects, err, i;
+ unsigned char *packdata;
+ unsigned long datasize;
/* Header consistency check */
hdr = p->pack_base;
@@ -25,11 +27,19 @@ static int verify_packfile(struct packed_git *p)
"while idx size expects %d", nr_objects,
num_packed_objects(p));
+ /* Check integrity of pack data with its SHA-1 checksum */
SHA1_Init(&ctx);
- pack_base = p->pack_base;
- SHA1_Update(&ctx, pack_base, pack_size - 20);
+ packdata = p->pack_base;
+ datasize = p->pack_size - 20;
+ while (datasize) {
+ unsigned long batch = (datasize < BATCH) ? datasize : BATCH;
+ SHA1_Update(&ctx, packdata, batch);
+ datasize -= batch;
+ packdata += batch;
+ }
SHA1_Final(sha1, &ctx);
- if (hashcmp(sha1, (unsigned char *)pack_base + pack_size - 20))
+
+ if (hashcmp(sha1, (unsigned char *)(p->pack_base) + p->pack_size - 20))
return error("Packfile %s SHA1 mismatch with itself",
p->pack_name);
if (hashcmp(sha1, (unsigned char *)index_base + index_size - 40))
commit 1084b845d9d77bcb2e8255636358dd0dc35360a5
Author: Junio C Hamano <[EMAIL PROTECTED]>
Date: Tue Jan 2 11:19:05 2007 -0800
Fix infinite loop when deleting multiple packed refs.
It was stupid to link the same element twice to lock_file_list
and end up in a loop, so we certainly need a fix.
But it is not like we are taking a lock on multiple files in
this case. It is just that we leave the linked element on the
list even after commit_lock_file() successfully removes the
cruft.
We cannot remove the list element in commit_lock_file(); if we
are interrupted in the middle of list manipulation, the call to
remove_lock_file_on_signal() will happen with a broken list
structure pointed by lock_file_list, which would cause the cruft
to remain, so not removing the list element is the right thing
to do. Instead we should be reusing the element already on the
list.
There is already a code for that in lock_file() function in
lockfile.c. The code checks lk->next and the element is linked
only when it is not already on the list -- which is incorrect
for the last element on the list (which has NULL in its next
field), but if you read the check as "is this element already on
the list?" it actually makes sense. We do not want to link it
on the list again, nor we would want to set up signal/atexit
over and over.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
diff --git a/cache.h b/cache.h
index f2ec5c8..a0e9727 100644
--- a/cache.h
+++ b/cache.h
@@ -174,6 +174,7 @@ extern int refresh_cache(unsigned int flags);
struct lock_file {
struct lock_file *next;
+ char on_list;
char filename[PATH_MAX];
};
extern int hold_lock_file_for_update(struct lock_file *, const char *path,
int);
diff --git a/lockfile.c b/lockfile.c
index 2a2fea3..143d7d8 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -28,9 +28,
Re: Can reports of serious policy violations be downgraded to important?
Le mardi 6 février 2007 02:47, Philippe Cloutier a écrit :
> >If you wish to add a RC bug more to debian, please ask to the release
> > managers if they feel that this should be solved for debian etch.
>
> Release team: I believe that #388616 should be upgraded back to serious.
> Please state that you agree with Romain if the report shouldn't be
> upgraded back to serious.
Ok, right I acknowledge the answer from the release team.
Now here is my anwser:
I do not feel apropriate to correcet this bug and here is why :
* The configuration file is not located in /etc and this is a policy
violation, that is a fact. However, this configuration file is linked in /etc
so that the administrator can locate it when he needs it.
* Reports claiming that their configuration files had been deleted by update
were either users of the previous packaging or users that had a wrong
documentation. Since those bugs were posted, I corrected documentation. Also,
on a fresh install, messages after install clearly ask for puting this file
in /var/lib/mediawiki1.7
* The reason why I did this rely on this header, on the fresh configuration
file:
"if( defined( 'MW_INSTALL_PATH' ) ) {
$IP = MW_INSTALL_PATH;
} else {
$IP = dirname( __FILE__ );
}"
From this point, the $IP, which is later taken as include path,
reflects /etc/mediawiki1.7 as soon as the configuration file is located
in /etc: php resolves dirname by the real directory name and not the name for
the directory of the link.
* I choosed to put the file to /var/lib because I misread the policy, and
because, under this bad assumption, I choosed the solution which involved the
less patching. Obviously, adding a
define(MW_INSTALL_PATH,"/var/lib/mediawiki1.7"° on top of the file is the
good solution. It is also what is done in my next 1.9 package.
Now that I have cleared the origins of the bug, let's explain why I do not
feel appropriate to resolve it:
* To me the violation is not that severe since the file is located in /etc
after all. I understand that others may not think the same way, but that is
my point.
* Let think a moment of what involved solving this issue. It involves:
- Changing the patch for installation messages to reflect the /etc location
- Adding a patch for defining this MW_INSTALL_PATH
- Changing the documentation for reflecting this new path too
- Changing the automated update script
And, perhaps the most important:
- Add an updating code which detects wether the configuration is in /etc or
in /var and apply the good changes. Of course, in order not to blow again any
file, this script as to be started before the packages files are copied.
- Also, you may add an advice to the administrator via debconf so that he is
aware of this change in his configuration.
Now that would let a package for etch that would have a lot of debconf, script
and code specialised for an issue that will not appear for any fresh install
from the forthcoming debian stable and solves an issue that *I* feel not that
important.
Now ok, I am not a blocker, if others come and say that it has to be solved
I'll do it of course, but it is not my opinion. In particular, I would like
to hear for Marc and perhaps the release team on what I wrote above.
Romain
Re: Permission to upload gnat-4.1 with 3 new binary packages?
On Sun, Feb 04, 2007 at 01:52:19AM +0100, Ludovic Brenta wrote: > The build scripts for gnat-4.1 are the same as for gcc-4.1 and > gcj-4.1; their behaviour depends on the source package name as defined > in the first changelog entry. We do not upload all three source > packages whenever the upload number changes, because not all changes > are relevant to all three packages. The latest uploads were: > 4.1.1-17 gcc gcj > 4.1.1-18 gcc > 4.1.1-19 gcc gnat > 4.1.1-20 gcc gcj > 4.1.1-21 gcc > 4.1.1-22 gnat > The rest is details... what you see are really the differences between > -19 and -22, and they include many things unrelated to Ada and which > do not affect the binary packages at all. For example, we do not > apply the updated Java, Objective-C or Objective-C++ patches when > building gnat-4.1; nor do we apply the new m68k patches, since > gnat-4.1 doesn't support m68k. > svn-updates.dpatch deserves a separate explanation. You will note > that that file contains the bulk of the changes. It regularly tracks > the upstream gcc 4.1 branch and contains regression fixes only. The > latest change to this file was made in -20, and is already in gcc-4.1 > and gcj-4.1 in testing. With this new upload, gnat-4.1 merely catches > up. No changes in this patch affect the Ada front-end or library. Unblocked. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please update ttf-dejavu
On Sun, Feb 04, 2007 at 07:31:35PM +0100, Davide Viti wrote: > On Sat, Feb 03, 2007 at 11:37:23AM +0100, Frans Pop wrote: > > The problem with accents seems to be a more general regression. Compare > > also for example the accented y and N characters for be. These look fuzzy > > in 14 when compared to 13. (For the y the accent is centered better > > though.) > > Same goes for r, e and s for cs. > > IMHO this should be fixed. > I'm glad to say that all regressions were because of some characters > stripped out the udeb and has nothing to do with upstream; I've just > committed the patch for #409509 and #409659 in svn ([1]) and created > some more screenshots. > 2.13 can now be compared to (patched) 2.14 using the following: > http://d-i.alioth.debian.org/gtk-frontend/screenshots/20070203_dejavu2.13 > http://d-i.alioth.debian.org/gtk-frontend/screenshots/20070204_dejavu2.14_prerelease > I've already prepared a 2.14-2 package but I'd prefere wait a little > longer before asking bubulle to upload it (let's see if anything new > comes up in the next couple of days) > IMO 2.14-2 is much better than 2.13 and think it deserves to make into etch I'll wait for a sign-off on this from Frans. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please allow t-p-u upload for lua-posix
On Tue, Feb 06, 2007 at 12:47:57AM +0100, Enrico Tassi wrote: > Current vesion of lua-posix in etch has an RC bug (#409448) that can be > solved with a two line patch. I've already prepared the package. > The problem is a FTBFS, caused by an unclear (at least to me) transition > of the unstable package in the already frozen etch: > http://lists.debian.org/debian-release/2007/01/msg01287.html No idea. The unblock hint was added by Marc, and the tags in the BTS were already in place documenting this sid-only status before 1.0-4 was uploaded. > Since version 1.0-3 and 1.0-4 are essentially identical (only the test > file has been modified) I've prepared a 1.0-3 version renamed > 1.0-4etch1. You would need to upload a new version to unstable first, so that the condition testing <= unstable is maintained. If it's not possible to produce a single lua-posix packages that's buildable against both etch and sid, please upload a -5 to unstable for purposes of bumping the version number, and then upload a -4etch1 to t-p-u. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#409882: changes in upstream
Robert Millan [ackstorm] wrote: > Given all this, would still be possible to consider this for etch ? ...which would require another round of main and non-free conglomeration packages in NEW, together with removals in testing and unstable of the non-free ones. Don't know if we can make this happen as it's not depending on me. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request to include to l10n packages in Etch
On Sat, Feb 03, 2007 at 11:43:17AM +0200, Lior Kaplan wrote: > During the last 5 months the Debian Arabic people worked towards > improving the Arabic support in Debian. > Please consider to include in Etch some of the new packages which were > uploaded to Unstable. > aspell-ar-large - 49 days in unstable, not present in Etch. > ttf-freefarsi - 50 days in unstable, not preset in Etch. > Both missed the Etch freeze by only a few days... More than "a few" days; both were uploaded after the archive was frozen (which means, well after the original target release date). I've unblocked them anyway on the grounds that these are data packages whose impact should be minimal -- and because they can be removed again from the release if any RC bugs appear. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
changes in upstream
It seems that the changes between pre9 and pre10 for code we already had
are purely non-technical (license change, etc). See attached diff.
Other than this, we just have changes in documentation/makefiles and
replacement of object code with a newer version of its corresponding
source. I think we can provide a much better QA on the latter, even if it
contains new improvements (better x86-64 support) that the non-free object
code didn't have.
Given all this, would still be possible to consider this for etch ?
(CCing -release)
--
Robert Millan
ACK STORM, S.L. - http://www.ackstorm.es/
--- kqemu-1.3.0pre9/kqemu-linux.c 2006-06-23 22:52:34.0 +0200
+++ kqemu-1.3.0pre10/kqemu-linux.c 2007-02-05 23:57:37.0 +0100
@@ -1,6 +1,20 @@
/*
* Linux kernel wrapper for KQEMU
- * Copyright (c) 2004-2005 Fabrice Bellard
+ *
+ * Copyright (C) 2004-2007 Fabrice Bellard
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
#include
#include
@@ -323,9 +337,7 @@
int ret, max_locked_pages;
struct sysinfo si;
-printk("QEMU Accelerator Module version %d.%d.%d, Copyright (c) 2005-2006 Fabrice Bellard\n"
- "This is a proprietary product. Read the LICENSE file for more information\n"
- "Redistribution of this module is prohibited without authorization\n",
+printk("QEMU Accelerator Module version %d.%d.%d, Copyright (c) 2005-2007 Fabrice Bellard\n",
(KQEMU_VERSION >> 16),
(KQEMU_VERSION >> 8) & 0xff,
(KQEMU_VERSION) & 0xff);
@@ -367,4 +379,4 @@
}
}
-MODULE_LICENSE("Proprietary");
+MODULE_LICENSE("GPL");
Re: kernel-patch-openvz and new patch revision
Ola Lundqvist wrote: Hi On Mon, Feb 05, 2007 at 06:48:30PM +0100, Luk Claes wrote: Ola Lundqvist wrote: Hi I have got a request from upstream to change the patch revision >from 028test007.1 to 028test015. The reason behind this is that it is "definitly more stable" than the 028test007.1 version and have a number of bugfixes corrected. So I want to ask you if it is ok to upload a new version of this patch for etch, and if you will accept it. Can you point us at a source package (for example by uploading to experimental) or something like that so we have an idea of what the actual difference would be? I think it will be difficult to spot the difference as it have to be reapplied which would cause a huge amount of differences in the patch file. Different order in the patch file give other differences... diff -u patch-2.6.18.5-debian-ovz028test007.1-combined patch-ovz028test015.1-combined | wc -l 251086 So no not that easy to review unfortunatly. Kir: Do you know any easy way to see the differences between the two versions? Well, one can use our GIT repo and see the detailed changelog, roughly these two pages http://git.openvz.org/?p=linux-2.6.18-openvz;a=log;h=028test015 http://git.openvz.org/?p=linux-2.6.18-openvz;a=log;h=028test015;pg=1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: nmap_4.20-1 unblock request
On Fri, Feb 02, 2007 at 12:10:25PM -0700, LaMont Jones wrote: > Please consider nmap 4.20-1 for etch. Nearly all of the bugs ever filed > against nmap have been enhancements, etc. It would be a shame to not > have the latest nmap in etch, especially now that it's over 50 days > old... Oh, I can't say that I think it's a shame, nmap has been a great piece of software for years and worked great even in sarge. 50 days old, but still uploaded after the freeze, so without a specific bug of concern I don't think it warrants an exception. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock syslinux 3.31-2
Luk Claes wrote: > Unblocked. thanks. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: openhpi
On Fri, Feb 02, 2007 at 11:55:09AM -0700, Bryan Sutula wrote: > Please move openhpi-2.6.2-3, currently in unstable, into the frozen Etch > release. The openhpi source package produces the following binary > packages: > openhpi > openhpi-clients > openhpi-plugin-ipmi > openhpi-plugin-ipmidirect > openhpi-plugin-snmp-bc > openhpi-plugin-sysfs > openhpid > libopenhpi2 > libopenhpi-dev > Briefly, 2.6.2-3 is in much better shape than the current 2.5.2-2 which > is in testing. Openhpi is a fairly new package, was not part of Sarge, > and no other packages depend on it, so should not pose a risk to the > Etch release. A more complete (long) justification is provided below: Unblocked, still with some misgivings. While I understand it would be of benefit to have this package in main, the changeset is quite large, so the package will not be given much leeway before removal in the case of late-manifesting RC bugs. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please allow jedstate_0.5.4.transitional.1-1 and jed-extra_2.2.1-1.etch.1
* Rafael Laboissiere <[EMAIL PROTECTED]> [2007-02-06 00:06]:
> * Rafael Laboissiere <[EMAIL PROTECTED]> [2007-02-05 23:29]:
>
> > Request (short):
> >
> > Please, allow jedstate_0.5.4.transitional.1-1 and
> > jed-extra_2.2.1-1.etch.1 in testing.
>
> Update: the version of jedstate currently in unstable is
> 0.5.4.transitional.1-2 (I added a postinst script to the pacakge).
New update: the version of jed-extra in unstable is now 2.2.1-1.etch.2. I
added two lines of autoloads in an itialization file (needed for
gdbmrecent). The diffs are attached below.
Sorry for the updates, I was working too fast yesterday.
--
Rafael
Index: debian/patches/gdbmrecent-clean-stack.dpatch
===
--- debian/patches/gdbmrecent-clean-stack.dpatch(.../2.2.1-1)
(revision 0)
+++ debian/patches/gdbmrecent-clean-stack.dpatch(.../2.2.1-1.etch.2)
(revision 548)
@@ -0,0 +1,19 @@
+#! /bin/sh /usr/share/dpatch/dpatch-run
+## gdbmrecent-clean-stack.dpatch by Rafael Laboissiere <[EMAIL PROTECTED]>
+##
+## DP: Empty the stack in call to purge_not_so_recent() in function
+## DP: gdbm_delete(). The problem was confirmed by the upstream author.
+
[EMAIL PROTECTED]@
+
+--- jed-extra-2.2.1.orig/gdbmrecent/gdbmrecent.sl
jed-extra-2.2.1/gdbmrecent/gdbmrecent.sl
+@@ -226,7 +226,7 @@
+foreach(keys)
+ {
+ key=();
+- gdbm_delete(db, key);
++ () = gdbm_delete(db, key);
+ }
+ }
+
Property changes on: debian/patches/gdbmrecent-clean-stack.dpatch
___
Name: svn:executable
+ *
Index: debian/patches/00list
===
--- debian/patches/00list (.../2.2.1-1) (revision 548)
+++ debian/patches/00list (.../2.2.1-1.etch.2)(revision 548)
@@ -1,4 +1,5 @@
+gdbmrecent-clean-stack
#missing_autoload
-
#apsmode
#ding
+
Index: debian/changelog
===
--- debian/changelog(.../2.2.1-1) (revision 548)
+++ debian/changelog(.../2.2.1-1.etch.2)(revision 548)
@@ -1,3 +1,19 @@
+jed-extra (2.2.1-1.etch.2) unstable; urgency=low
+
+ * debian/examples/50jed-extra.sl: Added the required autoloads for
+gdbmrecent [RL]
+
+ -- Rafael Laboissiere <[EMAIL PROTECTED]> Tue, 6 Feb 2007 09:53:19 +0100
+
+jed-extra (2.2.1-1.etch.1) unstable; urgency=low
+
+ * debian/patches/01_gdbmrecent-clean-stack.dpatch: Added patch to fix a
+bug in purge_not_so_recent(), which did not popped a value in the
+stack after the call to gdbm_delete(). This patch is blessed by the
+usptream author. [RL]
+
+ -- Rafael Laboissiere <[EMAIL PROTECTED]> Mon, 5 Feb 2007 22:33:54 +0100
+
jed-extra (2.2.1-1) unstable; urgency=low
New upstream release [GM]
Index: debian/examples/50jed-extra.sl
===
--- debian/examples/50jed-extra.sl (.../2.2.1-1) (revision 548)
+++ debian/examples/50jed-extra.sl (.../2.2.1-1.etch.2)(revision 548)
@@ -44,6 +44,8 @@
autoload("push_defaults", "sl_utils");% needed by ispell_init.sl,
complete, occur, ...
autoload("string_nth_match", "strutils"); % needed by hyperman.sl
autoload("get_keystring", "strutils");% needed by snake.sl
+autoload("what_line_if_wide", "sl_utils");% needed by gdbmrecent.sl
+autoload("buffer_dirname", "bufutils"); % needed by gdbmrecent.sl
% alternatively evaluate the utils/ini.sl file (or set the "initialize"
% argument to 1 in append_libdir($1 + "utils/", 1) above)
% () = evalfile("utils/ini.sl"); % autoloads for all utilit functions
Re: Can reports of serious policy violations be downgraded to important?
Philippe Cloutier ulaval.ca> writes: > Romain Beauxis a écrit : > >It is serious regarding the policy violation. > >However, I do not want to set it to serious as for > >now because of what Steve said. > > > > > What Steve said is for #393962 but not #388616. I'm not a member of the release team, but to me it seems Philippe is right. And Steve was probably wrong, since upgrades from 1.7 to 1.7 can also happen in stable point releases or security updates - and this would again blow away any local customization. > >If you wish to add a RC bug more to debian, please ask to the > >release managers if they feel that this should be solved for > >debian etch. > > > Release team: I believe that #388616 should be upgraded back > to serious. Indeed: Putting configuration files into /var is a serious policy violation, except if they are created on the fly from real configuration files in /etc. Placing a symlink in /etc that points to the location in /var makes it only worse. Regards, Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Please allow tex-common translation updates to migrate
Dear release team, please unblock tex-common/1.0 This is the changelog: tex-common (1.0) unstable; urgency=low * Release as version 1.0, tex-common has been stable for months and deserves a non-zero version number * Debconf translations: [frank] - New Romanian translation, thanks to Eddy Petrișor <[EMAIL PROTECTED]> (closes: #409267) - New Portuguese Brazilian translation, thanks to the Traduz MailingList <[EMAIL PROTECTED]> (closes: #408866) - Updated Catalan translation, thanks to Guillem Jover <[EMAIL PROTECTED]> (closes: #409162) -- Frank Küster <[EMAIL PROTECTED]> Mon, 5 Feb 2007 10:55:26 +0100 tex-common (0.44) unstable; urgency=low * Use full pathname when registering files with ucf (closes: #408263) * New and updated debconf translations: - Galician by Jacobo Tarrio <[EMAIL PROTECTED]> (closes: #408122) -- Frank Küster <[EMAIL PROTECTED]> Fri, 26 Jan 2007 18:10:23 +0100 The changes are only new translations plus one bug fix, the ucf issue. This bug has severity important, although I admit that this is because it is going to be RC in lenny. In etch it is only cosmetical, but it already gave us bug reports and anxious questions to the maintainer, and it's a one-line-fix: - test -x "`which ucfr`" && ucfr tex-common $file || true + test -x "`which ucfr`" && ucfr tex-common /etc/texmf/$file || true (I see that it should rather be an if statement, otherwise it will never get RC in lenny, but that's a different issue). TIA, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
unfreeze request - libexosip2 (2.2.3-2)
libexosip2 (2.2.3-2) unstable; urgency=low * libexosip2-dev Depends: libosip2-dev - Fixes: missing dependency on libosip2-dev (Closes: #393637) -- Mark Purcell <[EMAIL PROTECTED]> Sat, 9 Dec 2006 13:06:51 + pgpZXjCneDxdQ.pgp Description: PGP signature
unfreeze request - kdmtheme (1.1.2-2)
kdmtheme (1.1.2-2) unstable; urgency=low [ Mark Purcell ] * Add debian/rules get-orig-source target for http://buildserver.net. [ Fathi Boudra ] * Add a patch to warn users about kdm override files introduced with desktop-base. Thanks to Sune Vuorela. -- Fathi Boudra <[EMAIL PROTECTED]> Wed, 31 Jan 2007 21:11:45 +0100 pgprmI9Em7zVU.pgp Description: PGP signature
unfreeze request - asterisk-spandsp-plugins (0.0.20060218-4)
asterisk-spandsp-plugins (0.0.20060218-4) unstable; urgency=low * Fix #407203: make receive_fax be always shipped executable. -- Kilian Krause <[EMAIL PROTECTED]> Tue, 16 Jan 2007 22:08:40 +0100 asterisk-spandsp-plugins (0.0.20060218-3) unstable; urgency=low * Fix reference of README in faxreceive.conf (Closes: #362309) * Fix location of faxreceive.conf in receive_fax * Fix missing counters folder causing script to choke (Closes: #366536) * Make sure we don't build or install against spandsp 0.0.3. This will segfault in rxfax's fax_init call (line 281) -- Kilian Krause <[EMAIL PROTECTED]> Wed, 3 Jan 2007 21:18:31 +0100 pgpgUhNEDtDvE.pgp Description: PGP signature
unfreeze request - smstools (3.0.2-3)
smstools (3.0.2-3) unstable; urgency=medium * Urgency medium as this clears a bug in the upgrade path: Added prerm script to handle upgrade from 3.0-1 to this version (Closes: #403615) * Incorporated NMU changes into package. * Added Czech translation for smstools (Closes: #408781) * Added debian/watch file * Made some changes to debian init.d script to fix a few bugs. (Closes: #403616) * Reconstructed sms3 script from upstream as parts of it got lost -- Patrick Schoenfeld <[EMAIL PROTECTED]> Sun, 4 Feb 2007 14:49:44 +0100 pgpFvS8qztj1b.pgp Description: PGP signature
unfreeze request - opal (2.2.3.dfsg-3)
opal (2.2.3.dfsg-3) unstable; urgency=high * Conflict with openmpi-dev to make sure we don't have a filename clash (Closes: #404004). Setting high urgency due to RC-bug. -- Kilian Krause <[EMAIL PROTECTED]> Wed, 27 Dec 2006 15:56:46 +0100 pgp3sgQki9Lns.pgp Description: PGP signature
Please unblock prc-tools 2.3-1.1
Dear release team, I have just uploaded a NMU of prc-tools, to fix its pending l10n issues (and, if needed, very minor QA issues). Could you consider hinting it to enter testing? The NMU changelog is: Source: prc-tools Version: 2.3-1.1 Distribution: unstable Urgency: low Maintainer: Christian Perrier <[EMAIL PROTECTED]> Date: Tue, 6 Feb 2007 08:17:11 +0100 Closes: 45 400532 409641 Changes: prc-tools (2.3-1.1) unstable; urgency=low . * Non-maintainer upload to fix pending l10n issues. * Debconf translations: - German added. Closes: #400532 - Swedish added. Closes: #45 - Portuguese added. Closes: #409641 * Lintian fixes: - Correct the FSF address in debian/copyright - Add po-debconf to Build-Depends -- signature.asc Description: Digital signature
