Re: Bug#308290: libgphoto2-2: fails to import avis from Canon IXUS IIs
Adalbert Dawid wrote: Package: libgphoto2-2 Version: 2.1.5-5.0 Followup-For: Bug #308290 Indeed, after installing the three debs everything works fine again! (Would be great if this bug could be eliminated before the Sarge release...) Aurelien, this is another camera that works with MAX_READ_WRITE set at 4KB but not at 16KB. This value really looks hardcoded, I can't find how libgphoto2 could fallback to a working value. Is there a way ? Would you mind going back to 4KB blocks so we can hope for a working libgphoto2/libusb combination in Sarge ? Release team, if we agree on that change, would you be ok with an upload to sarge ? Thanks, Frederic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#308290: libgphoto2-2: fails to import avis from Canon IXUS IIs
Hi, Frederic Peters a écrit : Adalbert Dawid wrote: Package: libgphoto2-2 Version: 2.1.5-5.0 Followup-For: Bug #308290 Indeed, after installing the three debs everything works fine again! (Would be great if this bug could be eliminated before the Sarge release...) Aurelien, this is another camera that works with MAX_READ_WRITE set at 4KB but not at 16KB. This value really looks hardcoded, I can't find how libgphoto2 could fallback to a working value. Is there a way ? The USB devices don't see this kind of block size, they only see a block size of 64 or 512 bytes depending if they are USB 1.1 or USB 2.0 devices. The block size you are talking about is only the block size to dialog with the kernel. So it is not the camera which don't work with this block size, but rather the driver. Would you mind going back to 4KB blocks so we can hope for a working libgphoto2/libusb combination in Sarge ? I agree to do that in Sarge but not in Sid, as it would decrease the transfer rate of some devices by about 20%. For Sid the code has to be fixed in libgphoto2. Bye, Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian GNU/Linux developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libmail-cclient-perl
On Mon, May 09, 2005 at 03:02:57PM -0700, Steve Langasek wrote: On Mon, May 09, 2005 at 03:03:51PM +0100, Stephen Quinney wrote: Is there any chance of the libmail-cclient-perl package making it into Sarge please? The only thing holding it out previously was a lack of build on ia64 for version 1.12-1. It looks like that version built successfully on that arch on 16th April, see: http://buildd.debian.org/fetch.php?pkg=libmail-cclient-perlver=1.12-1arch=ia64stamp=1113683340file=logas=raw Nevertheless, no ia64 binaries have been uploaded: So, how do I find out why no ia64 binaries have been uploaded even though the package successfully built over three weeks ago? Is it a case of pestering the ia64 buildd people? Stephen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libmail-cclient-perl
On Tue, May 10, 2005 at 08:56:42AM +0100, Stephen Quinney wrote: On Mon, May 09, 2005 at 03:02:57PM -0700, Steve Langasek wrote: On Mon, May 09, 2005 at 03:03:51PM +0100, Stephen Quinney wrote: Is there any chance of the libmail-cclient-perl package making it into Sarge please? The only thing holding it out previously was a lack of build on ia64 for version 1.12-1. It looks like that version built successfully on that arch on 16th April, see: http://buildd.debian.org/fetch.php?pkg=libmail-cclient-perlver=1.12-1arch=ia64stamp=1113683340file=logas=raw Nevertheless, no ia64 binaries have been uploaded: So, how do I find out why no ia64 binaries have been uploaded even though the package successfully built over three weeks ago? Is it a case of pestering the ia64 buildd people? Packages-arch-specific line 495: 1.399 (lamont 05-Mar-04): %libmail-cclient-perl: !ia64 # [ANAIS] So, this package is marked as 'not for ia64', this line should be removed if that's no longer the case, or the ia64 binary should be removed if this is still valid (I don't see any rationale for this, except that the package apparantly excluded ia64 from its architecture: line previously, so I guess not). --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]
Re: Update of sarge - gnurobbo
On Mon, May 09, 2005 at 10:32:25AM +0200, ukasz Jachowicz wrote: Hi, - If your package needs to be updated for sarge, and the version in [..] same between testing and unstable), please upload your fix to unstable and contact [EMAIL PROTECTED] I've uploaded fixed version of gnurobbo (some problems with proprietary fonts, I've replaced both original source code and the package). It's in unstable already, checked and tested, could you please move it to Sarge? Approved. FWIW, it's fairly customary to use names such as 0.57.dfsg1 when making such changes, to protect against possible collisions with upstream versioning. Cheers, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Bug#307258: marked as done (Components.idl missing)
Hi Konstantinos, On Mon, May 09, 2005 at 03:03:20AM -0700, Debian Bug Tracking System wrote: Format: 1.7 Date: Sun, 8 May 2005 19:30:01 +0200 Source: ace Binary: libkokyu-dev libtao-orbsvcs-dev libace-rmcast-dev libtao1.4 libtao-xtreactor-dev libtao-qtreactor-dev libace-tkreactor5.4 libacexml-dev libace-doc libace-flreactor5.4 libace-tkreactor-dev libace-xtreactor5.4 libciao-dev libace-rmcast5.4 libace-qtreactor-dev libtao-dev libtao-doc libace-qtreactor5.4 libtao-qtreactor1.4 libciao1.4 libkokyu5.4 mpc-ace libace-dev gperf-ace libace-xtreactor-dev libtao-orbsvcs1.4 libtao-xtreactor1.4 libace5.4 libace-flreactor-dev libacexml5.4 Architecture: source all i386 Version: 5.4.2.1.0-4 Distribution: unstable Urgency: high Maintainer: Debian ACE+TAO maintainers [EMAIL PROTECTED] Changed-By: Konstantinos Margaritis [EMAIL PROTECTED] Description: gperf-ace - Perfect hash function generator (ACE version) libace-dev - An Object-Oriented Network Programming Toolkit in C++ libace-doc - Documentation for the ADAPTIVE Communication Environment (ACE) libace-flreactor-dev - GUI Integrated Reactors for ACE: FastLight Reactor (development f libace-flreactor5.4 - GUI Integrated Reactors for ACE: FastLight Reactor libace-qtreactor-dev - GUI Integrated Reactors for ACE: Qt Reactor (development files) libace-qtreactor5.4 - GUI Integrated Reactors for ACE: Qt Reactor libace-rmcast-dev - A reliable multicast library in C++ libace-rmcast5.4 - A reliable multicast library in C++ libace-tkreactor-dev - GUI Integrated Reactors for ACE: Tk Reactor (development files) libace-tkreactor5.4 - GUI Integrated Reactors for ACE: Tk Reactor libace-xtreactor-dev - GUI Integrated Reactors for ACE: Xt Reactor (development files) libace-xtreactor5.4 - GUI Integrated Reactors for ACE: Xt Reactor libace5.4 - An Object-Oriented Network Programming Toolkit in C++ libacexml-dev - ACE XML PARSER Framework (development) libacexml5.4 - ACE XML PARSER Framework (runtime) libciao-dev - CIAO, TAO's implementation of CORBA Component Model (CCM) libciao1.4 - CIAO, TAO's implementation of CORBA Component Model (CCM) libkokyu-dev - Kokyu middleware for TAO libkokyu5.4 - Kokyu middleware for TAO libtao-dev - Development Files for TAO, The ACE ORB libtao-doc - Documentation for TAO, The ACE ORB libtao-orbsvcs-dev - The ACE ORB, an open-source implementation of CORBA ORB libtao-orbsvcs1.4 - The ACE ORB, an open-source implementation of CORBA ORB libtao-qtreactor-dev - GUI Integrated Reactors for TAO: Qt Reactor (development files) libtao-qtreactor1.4 - GUI Integrated Reactors for TAO: Qt Reactor libtao-xtreactor-dev - GUI Integrated Reactors for TAO: Xt Reactor (development files) libtao-xtreactor1.4 - GUI Integrated Reactors for TAO: Xt Reactor (development files) libtao1.4 - The ACE ORB, an open-source implementation of CORBA ORB mpc-ace- A Makefile generator in Perl Closes: 307258 Changes: ace (5.4.2.1.0-4) unstable; urgency=high . * Thomas Girard [EMAIL PROTECTED] - debian/control: o libacexml-dev depends on libace-dev. o libkokyu-dev depends on libace-dev. o libtao-dev depends on libtao1.4. o normalize Depends: and Build-Depends: sections. - debian/ace-config.1 debian/tao-config.1: fix hyphenation problem reported by lintian. - debian/libciao-dev.install: add missing .idl and .pidl files. (Closes: #307258) Approved for testing. BTW, you may want to clean out the debian/.#changelog.1.14 that ended up in the diff; also, when making documentation changes like -Please refer to debian/control or packge's description on more details on +Please refer to debian/control or packge's description for more details on ... it would be nice if someone would spellcheck the rest of the words on the line :-) Cheers, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Please consider loop-aes-utils 2.12p-4 for sarge
Hi Max, On Tue, May 10, 2005 at 03:54:34AM +0200, Max Vozeler wrote: I just noticed that util-linux 2.12p-4 is now in testing - somewhat unexpectedly for me, since the last discussion on -release seemed to conclude that updating it was out of question. loop-aes-utils 2.12p-4 has been held out of testing as it depends on versions of mount (=2.12p-1) that use libblkid, which I added in order to keep both packages synced for sarge. The difference now in upstream versions between util-linux and loop-aes-utils is suboptimal for a number of reasons: - Bugs fixed in mount between 2.12a and 2.12p resurface if users install loop-aes-utils 2.12a-3 - Security updates are probably complicated by having two different upstream versions of setuid /bin/mount. - Translations from util-linux-locales 2.12p may not apply to the code from 2.12a. loop-aes-utils 2.12p-4 is the same as the mount parts of util-linux 2.12p-4, modulo the loop-AES patch. It should be identical to it in terms of non-crypto bugs and features. The current version has been in unstable for 47 days with no bugs reported against it, and for above reasons, I would like to ask you to make a freeze exception for this package. Yes, given that this was only blocked by util-linux before, I'm going to go ahead and push it in. Thanks, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: please consider pinfo for sarge
Hi again, On Mon, May 09, 2005 at 02:37:55PM +0200, Bas Zoetekouw wrote: Well, I don't think you've fixed this RC bug at all: instead, by removing doc/pinfo.info in debian/rules, you've ensured that makeinfo is required for *all* builds of the package, and by not adding a build-depends on texinfo, it will be missing when building on all of the buildds. I think you really need to add that build-dep. You're right of course, I overlooked that. You may also want to clean up debian/changelog.dch and src/pinforc before your next upload, I guess. I just uploaded -6, in which all of this should be fixed. I also checked building it in a clean chroot, so it really should be fine now. Ok, approved for sarge. Thanks, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Please allow kdenetwork and kdelibs into Sarge
On Mon, May 09, 2005 at 08:32:54AM -0400, Christopher Martin wrote:
kdenetwork 4:3.3.2-3, replacing 4:3.3.2-1 in Sarge, fixes a number of bugs,
including several that are RC. These packages have been in Sid for some
time, but held out due to missing buildds, so they've proven themselves
solid. The most recent upload, from late April, contained only packaging
changes:
Approved (though still waiting on a sarge upload).
Going forward, it would be nice if you would check whether uuencoding
something that's already a diff (and, er, not changing the name of a diff
just because the date changed), so that changes can be reviewed using
interdiff alone. I imagine this is being done here to guard against dpkg's
failure to use -a when generating diffs, and I suspect it's not actually
necessary if you've got everything in a diff file *anyway*, because the diff
header itself ought to mark the file as ascii.
As for kdelibs, the sole change between 4:3.3.2-5 and 4:3.3.2-6 is that we
added a very small patch (from upstream) to upstream's latest security fix,
which caused regressions reading some image files. Definitely worth getting
into Sarge, even if the problem doesn't seem to have security implications.
23_kimgio_fix.diff
--- kde.orig/kimgio/rgb.cpp
+++ kde.patched/kimgio/rgb.cpp
@@ -272,7 +272,8 @@ bool SGIImage::readImage(QImage img)
// sanity ckeck
if (m_rle)
for (uint o = 0; o m_numrows; o++)
- if (m_starttab[o] + m_lengthtab[o] = m_data.size())
{
+ // do not convert to =
+ if (m_starttab[o] + m_lengthtab[o] m_data.size())
{
kdDebug(399) image corrupt (sanity check
failed) endl;
return false;
}
The accompanying changelog isn't very enlightening; what filetypes are
broken, and why? Can you offer a pointer to discussion of this bug?
--
Steve Langasek
postmodern programmer
signature.asc
Description: Digital signature
Re: Accept wesnoth 0.9.0-5 in testing
On Mon, May 09, 2005 at 09:38:32PM +0200, Isaac Clerencia wrote: I've just uploaded Wesnoth 0.9.0-5 to t-p-u, as 0.9.1-1 is already in Sid (with a serious bug that does *not* affect 0.9.0). This is the changelog: +wesnoth (0.9.0-5) testing-proposed-updates; urgency=low + + * Use wesnoth.debian.net as multiplayer server + * Apply one-line patch from CVS to fix a segfault when running +wesnoth --decompress + + -- Isaac Clerencia [EMAIL PROTECTED] Mon, 9 May 2005 16:45:01 +0200 The usual package uses server.wesnoth.org as multiplayer server, but that server is already using 0.9.1 and 0.9.0 is unable to connect there. There exists a Wesnoth server with 0.9.0 in wesnoth.debian.net, which will keep that version until etch is released, and the package has been set up to use it. The other changelog entry is quite clear. The interdiff also shows a very small update in config.sub. It would be great to have this accepted in Sarge. Approved, assuming no problems with autobuilding. Cheers, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: [Pkg-kde-talk] Re: Please allow kdenetwork and kdelibs into Sarge
On May 10, 2005 07:45, Steve Langasek wrote:
On Mon, May 09, 2005 at 08:32:54AM -0400, Christopher Martin wrote:
kdenetwork 4:3.3.2-3, replacing 4:3.3.2-1 in Sarge, fixes a number of
bugs, including several that are RC. These packages have been in Sid
for some time, but held out due to missing buildds, so they've proven
themselves solid. The most recent upload, from late April, contained
only packaging changes:
Approved (though still waiting on a sarge upload).
Thanks.
Going forward, it would be nice if you would check whether uuencoding
something that's already a diff (and, er, not changing the name of a diff
just because the date changed), so that changes can be reviewed using
interdiff alone. I imagine this is being done here to guard against
dpkg's failure to use -a when generating diffs, and I suspect it's not
actually necessary if you've got everything in a diff file *anyway*,
because the diff header itself ought to mark the file as ascii.
Sorry about the hassle - the kdenetwork uploads were made before the freeze,
which is when we started thinking in terms of ease-of-readability. As for
uuencoding, it is, unfortunately, necessary when binary files are
added/updated in a diff. The use of -a when generating a diff doesn't seem
to prevent dpkg from choking on it. While for the KDE 3.3 packages all
branch diffs are uuencoded (more out of tradition than anything else),
we're being more selective with the post-Sarge 3.4 branch pulls.
As for kdelibs, the sole change between 4:3.3.2-5 and 4:3.3.2-6 is that
we added a very small patch (from upstream) to upstream's latest
security fix, which caused regressions reading some image files.
Definitely worth getting into Sarge, even if the problem doesn't seem
to have security implications.
23_kimgio_fix.diff
--- kde.orig/kimgio/rgb.cpp
+++ kde.patched/kimgio/rgb.cpp
@@ -272,7 +272,8 @@ bool SGIImage::readImage(QImage img)
// sanity ckeck
if (m_rle)
for (uint o = 0; o m_numrows; o++)
- if (m_starttab[o] + m_lengthtab[o] =
m_data.size()) {
+ // do not convert to =
+ if (m_starttab[o] + m_lengthtab[o]
m_data.size()) {
kdDebug(399) image corrupt (sanity
check failed) endl;
return false;
}
The accompanying changelog isn't very enlightening; what filetypes are
broken, and why? Can you offer a pointer to discussion of this bug?
Certainly. The security advisory can be found at
http://www.kde.org/info/security/advisory-20050504-1.txt. In summary, most
RGB files (an older SGI format, but it's still around) can no longer be
read. The one-line change (from upstream) we added between -5 and -6 fixes
this regression.
Cheers,
Christopher Martin
pgpPQzrNKVIy5.pgp
Description: PGP signature
please approve php4-auth-pam for sarge
Hi, first, I'm not subscribed, please CC. php4-auth-pam has been bugfree for a long time, but it was pulled from sarge because of the phpapi seesaw. Please consider it for sarge, there are dependencies on it, already. Thanks, Carsten -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
upload closing RC bug in kernel-patch-adeos
Hi, just uploaded the packages made from the rtai source to unstable with urgency=high. One of the packages, kernel-patch-adeos, fixes RC bug #307982. This bug in fact occurs in all 2.4 patches currently in sarge. Greetings, Edelhard -- ~ ~ :wq signature.asc Description: Digital signature
Re: vim-vimoutliner -- please allow into sarge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 martin f krafft scripsit: 1) to create -6 version of package, which would have empty (or fully commented out) /etc/vim/vimoutlinerrc. 2) to create -6 version of package without any /etc/vim/vimoutlinerrc (everything should work as well, because vim's runtime! is not offended when the file is not available), I prefer 1 or 2, but Steve has a good point. I think you need to decide for yourself whether this new release really needs to go into sarge. If it does, I don't think either of the above two are going to make a big difference. OK, I choose #1 (/etc/vim/vimoutlinerrc fully commented out) and it is actually just now available at http://www.ceplovi.cz/matej/progs/debian (usual place). 3) to create -6 version of package without a mechanism for loading /etc/vim/vimoutlinerrc Does upstream support it? Well, actually upstream is much more oriented towards personal installation (i.e., install to $HOME), so most of the site-wide tricks I had to do on my own (of course, upstream is fully aware of what I am doing). So the only change I really did to the upstream is that in ftplugin/vo_base.vim (the main script of the whole thing) is this: - --- vimoutliner-0.3.3.orig/ftplugin/vo_base.vim +++ vimoutliner-0.3.3/ftplugin/vo_base.vim @@ -564,8 +564,8 @@ Added an indication of current syntax as per Dillon Jones' request let b:current_syntax = outliner - - Personal configuration options files as per Matej Cepl + Personal configuration options files setlocal runtimepath+=$HOME/.vimoutliner,$HOME - -ru .vimoutlinerrc +runtime! .vimoutlinerrc vimoutlinerrc The End vim600: set foldmethod=marker foldlevel=0: And then I just added new the copy of upstream example to /etc/vim. Matej - -- Matej Cepl, http://www.ceplovi.cz/matej GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC 138 Highland Ave. #10, Somerville, Ma 02143, (617) 623-1488 MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development. -- [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCgO7K4J/vJdlkhKwRAhGYAJ9LSwF8dnB0Mt7JfsK1Cw27UbnjZQCdF21Y /pnhdWSD61TMOT+l8Nb9C8A= =gq1k -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFFE for openntpd 3.6.1p1-2.
Hi, I've uploaded a new version of openntpd which fix what I think are several important bugs of which only 1 was reported. Here is the changelog: * Change E-mail address to [EMAIL PROTECTED] * poll_errors.dpatch: When poll() says there was an error on a socket, it didn't get checked and on the next poll() call got the same error again resulting in cpuhog. poll_errors.dpatch (Closes: #307348) Patch from upstream CVS. * Add a Depends on adduser since we use it in the postinst/postrm. * Use set -e in postinst/postrm instead of doing /bin/sh -e. * Create a defaults file, and mention the -s option in it. * freeifaddrs.dpatch: Call freeifaddrs() with the proper pointer. Patch from upstream CVS. * imsg_memmove.dpatch: Use a memmove() instead of memcpy() as those buffers might overlap. Patch from upstream CVS. * network_unreachable.dpatch: Do not consider ENETUNREACH as a fatal error. Patch from upstream CVS. * daemonize_settime.dpatch: When started with -s option (which isn't used by default) daemonize if sending failed instead of waiting for a reply. This might be a problem when the network is down. Patch from upstream CVS. I've noticed that I forgot to mention 1 change in it: The init script has changed to no longer have a reload option since it's not working. The program sees the SIGHUP, sets a variable, but then does nothing with it. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On Sat, 7 May 2005, Joey Hess wrote: So here is a list (from update-excuses) of all 491 packages that is being held out of sarge[1]. If you've already done all you can on the RC bugs on packages in sarge, take a look over it and if you spot anything important or generally worth fixing, point it out, or just work on it. Remember that due to the freeze you'll need to ask on debian-release to get any fixed packages accepted back into sarge. [...] pgp4pine I fixed the RC and other bugs in this several weeks ago but it is in contrib so does it need a nudge to be autobuilt? -- Jaldhar H. Vyas [EMAIL PROTECTED] La Salle Debain - http://www.braincells.com/debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please consider syslog-ng for testing
Micah Anderson wrote:
I've just backported the fix that appeared in 1.6.6 and was sent as a
patch to the debian bug by the upstream maintainer.
The version uploaded to unstable (1.6.5-2.1) contains the fix for the
security hole, two fixes for lintian errors (not warnings) and three
documentation updates:
* Non-maintainer upload to fix security hole for sarge
* Changed debian/control to use a versioned depends on util-linux
to fix lintian error
* Converted debian/changelog to be valid UTF-8 by to fix lintian
error
* Updated documentation: doc/syslog-ng.conf.5, doc/syslog-ng.8 to fix
outdated information and typos and language clarification on klogd
in doc/sgml/syslog-ng.sgml
Please consider allowing this version into sarge.
-Depends: ${shlibs:Depends}, util-linux
+Depends: ${shlibs:Depends}, util-linux (=2.12-10)
You're missing a space here. ^^
Otherwise looks ok.
--
see shy jo
signature.asc
Description: Digital signature
Please push f2c 20020621-3.4 into sarge
tags 292792 - fixed tags 292792 + sarge thanks Hi, f2c is broken in sarge (Bug#292792) and causing a build failure for nec (Bug#308181). Version 20020621-3.4 fixed this a while ago, please push it in. Thanks! Matej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#308181: Please push f2c 20020621-3.4 into sarge
* Matej Vela ([EMAIL PROTECTED]) [050510 21:10]: f2c is broken in sarge (Bug#292792) and causing a build failure for nec (Bug#308181). Version 20020621-3.4 fixed this a while ago, please push it in. approved. Thanks, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: push lurker 1.3-2 into sarge
* Jonas Meurer ([EMAIL PROTECTED]) [050510 18:15]: please push lurker 1.3-2 into sarge. the version currently in sarge (1.2-5) has some annoying bugs like problems with timestamp, and lurker 1.3 is a bugfix-only release. additionally several template translation updates would make it into sarge with 1.3-2. please wait for 1.3-2, as it includes one more debconf template translation update plus a minor compilation fix. it has been uploaded to incoming today. Hi, sorry, but I can't exactly say that 1.3-2 is an important and above bugfix-only release in relation to 1.2-5 -- which might be related to the fact that I might not have recognized the bugs. Could you please give more details why all these changes are required? Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: vim-vimoutliner -- please allow into sarge
also sprach Matej Cepl [EMAIL PROTECTED] [2005.05.10.1926 +0200]: Well, actually upstream is much more oriented towards personal installation (i.e., install to $HOME), so most of the site-wide tricks I had to do on my own (of course, upstream is fully aware of what I am doing). So the only change I really did to the upstream is that in ftplugin/vo_base.vim (the main script of the whole thing) is this: Seems like a minimal change which cannot or should not have too much effect on the stable source. Thus, it could go into sarge, I think. Nevertheless, you are basically fixing a wishlist bug here (although no bug ever existed), and we have entered the freeze. Of course we could try to make exceptions here and another one here and yet another exception for that package over there, but then we won't ever release. Hence, as -5 fixes no release-critical bugs and otherwise does not qualify as a freeze-exception, I am not willing to argue that it should enter sarge. My intuition is that it could enter without breakage, but that's not a guarantee. Thus, if the release team decides to let if in, I won't object. But if the release team deems it an inappropriate change for a frozen target, I accept this decision. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! i must get out of these wet clothes and into a dry martini. -- alexander woolcott signature.asc Description: Digital signature
Re: Please approve quark grcm to let linc go away
* Jeroen van Wolffelaar ([EMAIL PROTECTED]) [050510 12:25]: 12:16:35 jvw vorlon: grcm quark are 10 days old, if you freeze-except them, linc can be dropped from testing 12:16:57 vorlon jvw: email :) linc's code has been included in orbit2 since, and the uploads of grcm quark were rebuild-only NMU's. approved. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Accepted quintuple-agent 1.0.4-6 (i386 source)
* Norbert Tretkowski wrote: quintuple-agent (1.0.4-6) unstable; urgency=medium . * Added a patch from LaMont Jones, which fixes a memory corruption crash in agpg.c. (closes: #305634) Please approve for sarge. Norbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Please allow uim 1:0.4.6final1-3 into Sarge
Hello, (B (Buim 1:0.4.6final1-3 is fixed dependency problem which is marked as RC (BBug#303321. Please allow puttinginto Sarge. (B (BThanks, (B (BMasahito Omote([EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) (B (B (B-- (BTo UNSUBSCRIBE, email to [EMAIL PROTECTED] (Bwith a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Please allow eskuel 1.0.5-3.1 into sarge
Hello, Today a new version of the eskuel package, 1.0.5-3.1, was uploaded in which the only change is to fix an RC, security bug. Could this be allowed to proceed into testing? (NB I provided the fixed version, which was checked and uploaded by Jeroen since I'm not a DD, with consent of the current maintainer who indicated she was too busy at the moment) Thanks, Thijs Kinkhorst signature.asc Description: This is a digitally signed message part
Re: upload closing RC bug in kernel-patch-adeos
Hi Edelhard, On Tue, May 10, 2005 at 07:41:36PM +0200, Edelhard Becker wrote: just uploaded the packages made from the rtai source to unstable with urgency=high. One of the packages, kernel-patch-adeos, fixes RC bug #307982. This bug in fact occurs in all 2.4 patches currently in sarge. Approved. Thanks, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: vim-vimoutliner -- please allow into sarge
martin f krafft scripsit: Nevertheless, you are basically fixing a wishlist bug here (although no bug ever existed), and we have entered the freeze. Of course we could try to make exceptions here and another one here and yet another exception for that package over there, but then we won't ever release. Well, I am fixing two important bugs (one is actually merged from other package vim-latexsuite) which are breaking Debian VIM policy (not using helpztags, which breaks help files for other supplemental vim packages). I thought that adding this innocent wish-bug (which really shouldn't break anything) should not be offensive to Steve and couple of users (apparently packaging this into Debian doubled number of actual users!) really complained about missing plugins, because they are apparently very popular (one of them basically allows managing huge todo lists in vim). However, if the inclusion of /etc/vim/vimoutliner should mean that whole package would not go into sarge and thus these two important bugs wouldn't be fixed then I would gladly eliminate /etc/vim/vimoutlinerrc. Should I do it? Matej -- Matej Cepl, http://www.ceplovi.cz/matej GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC 138 Highland Ave. #10, Somerville, Ma 02143, (617) 623-1488 He loves nature in spite of what it did to him. -- Forrest Tucker -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please allow uim 1:0.4.6final1-3 into Sarge
On Wed, May 11, 2005 at 06:02:31AM +0900, Masahito Omote wrote: uim 1:0.4.6final1-3 is fixed dependency problem which is marked as RC Bug#303321. Please allow puttinginto Sarge. Approved. Thanks, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Accepted quintuple-agent 1.0.4-6 (i386 source)
On Tue, May 10, 2005 at 11:04:29PM +0200, Norbert Tretkowski wrote: * Norbert Tretkowski wrote: quintuple-agent (1.0.4-6) unstable; urgency=medium . * Added a patch from LaMont Jones, which fixes a memory corruption crash in agpg.c. (closes: #305634) Please approve for sarge. Approved. Thanks, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Please allow eskuel 1.0.5-3.1 into sarge
On Wed, May 11, 2005 at 12:08:02AM +0200, Thijs Kinkhorst wrote: Today a new version of the eskuel package, 1.0.5-3.1, was uploaded in which the only change is to fix an RC, security bug. Could this be allowed to proceed into testing? Yes, approved. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: vim-vimoutliner -- please allow into sarge
On Tue, May 10, 2005 at 01:26:33PM -0400, Matej Cepl wrote: martin f krafft scripsit: 1) to create -6 version of package, which would have empty (or fully commented out) /etc/vim/vimoutlinerrc. 2) to create -6 version of package without any /etc/vim/vimoutlinerrc (everything should work as well, because vim's runtime! is not offended when the file is not available), I prefer 1 or 2, but Steve has a good point. I think you need to decide for yourself whether this new release really needs to go into sarge. If it does, I don't think either of the above two are going to make a big difference. OK, I choose #1 (/etc/vim/vimoutlinerrc fully commented out) and it is actually just now available at http://www.ceplovi.cz/matej/progs/debian (usual place). Adding a config that's commented out by default should be ok. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Please allow pja into sarge
Hi Wolfgang, On Tue, May 10, 2005 at 08:32:57AM +0200, Wolfgang Baer wrote: please let pja (source) libpja-java / libpja-java-doc into sarge. pja (2.5-3) unstable; urgency=low . * debian/control: added jikes, thanks to Andreas Jochens (closes: #306596). Fixes FTBS * debian/rules: added JDK directories created by java-package. Approved. When uploading fixes for RC bugs needed for sarge, please use urgency=high. Thanks, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: vim-vimoutliner -- please allow into sarge
Steve Langasek scripsit: Adding a config that's commented out by default should be ok. So is it approved? Thanks! Matej -- Matej Cepl, http://www.ceplovi.cz/matej GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC 138 Highland Ave. #10, Somerville, Ma 02143, (617) 623-1488 Some cause happiness wherever they go; others whenever they go. -- Oscar Wilde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
davfs2 0.2.3-1.1 needs an update in sarge
The davfs2 unstable version (0.2.3-1.1)[1] its a NMU and it resolved a RC Bug[2]. Please, update it to the frozen sarge. BTW, I worked in a new package version 0.2.3-2 which resolve some minors bugs. Have sense to add it to the sarge too? Please, CC me, Im not subscribed on the list [1] http://packages.debian.org/unstable/utils/davfs2 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=307085 -- Luciano Bello [EMAIL PROTECTED] Linux Argetina signature.asc Description: This is a digitally signed message part
Re: davfs2 0.2.3-1.1 needs an update in sarge
also sprach Luciano Bello [EMAIL PROTECTED] [2005.05.10.0611 +0200]: BTW, I worked in a new package version 0.2.3-2 which resolve some minors bugs. Have sense to add it to the sarge too? In general: no. It's especially difficult to tell if we do not have the actual package available. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! i wish i hadn't slept all day, it's really lowered my productivity -- robert mcqueen signature.asc Description: Digital signature
Re: vim-vimoutliner -- please allow into sarge
also sprach Matej Cepl [EMAIL PROTECTED] [2005.05.11.0015 +0200]: Well, I am fixing two important bugs (one is actually merged from other package vim-latexsuite) which are breaking Debian VIM policy (not using helpztags, which breaks help files for other supplemental vim packages). Even though it's good that there is a VIM policy, important bugs are not release-critical. I thought that adding this innocent wish-bug (which really shouldn't break anything) should not be offensive to Steve and couple of users (apparently packaging this into Debian doubled It's not about being offensive or intrusive, it's about trying to get sarge out the door with stable software. I think the release team approved it, so we can settle this discussion. Thanks for your good work for Debian! -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! driving with a destination is like having sex to have children -- backwater wayne miller signature.asc Description: Digital signature
Re: doc++ 3.4.10-3.1 NMU
Hi Matej, On Wed, May 11, 2005 at 01:04:55AM +0200, Matej Vela wrote: On Tue, May 10, 2005 at 02:02:06AM +0200, Frank Lichtenheld wrote: On Tue, May 10, 2005 at 01:31:25AM +0200, Frank Lichtenheld wrote: On Sun, May 08, 2005 at 06:32:54PM +0200, Matej Vela wrote: I've uploaded an NMU for doc++ which fixes the FTBFS bug (#292337) along with some minor issues. Patch attached. Approved Hmm, seems I missed the reopening of the RC bug... Sorry about that, this is fixed in 3.4.10-3.2, which works for all reverse dependencies (dancer-xml, dlisp, dmachinemon, libdshconfig, libupnp). Please approve it for sarge. Re-approved. :) Thanks, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: vim-vimoutliner -- please allow into sarge
On Tue, May 10, 2005 at 07:11:09PM -0400, Matej Cepl wrote: Steve Langasek scripsit: Adding a config that's commented out by default should be ok. So is it approved? Thanks! The one currently in the archive is *not* commented out by default, AIUI. If one gets uploaded to unstable that provides a no-op vimoutlinerrc by default, I would be willing to approve it. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Pushing gtk+2.0 (2.6.4-2)
Oi kov,
On Tue, May 10, 2005 at 01:04:39AM -0300, Gustavo Noronha Silva wrote:
As with gconf2 I just uploaded gtk+2.0 2.6.4-2 fixing a documentation
problem related to its devhelp file and including a patch grabbed from
upstream's CVS to fix a sucky focus problem, following the main
maintainer's advice.
This later problem can be quite a big inconvenience for users of
combinations like ion and firefox or other gtk2-based apps; the fix was
written and incorporated by upstream on HEAD and on the stable branch,
so we consider it to be safe.
The diff also seems to contain changes not documented in the changelog,
which look quite intrusive:
--- gtk+2.0-2.6.4/debian/patches/004_fs_newdir.patch
+++ gtk+2.0-2.6.4.orig/debian/patches/004_fs_newdir.patch
@@ -1,40 +0,0 @@
file completely removed
--- gtk+2.0-2.6.4/debian/rules
+++ gtk+2.0-2.6.4/debian/rules
@@ -121,7 +121,7 @@
touch $@
-configure: configure-static configure-shared
+configure: configure-shared
build-shared: debian/control configure-shared
$(STAMP_DIR)/build-shared-stamp
$(STAMP_DIR)/build-shared-stamp:
@@ -147,7 +147,7 @@
touch $@
-build: build-static build-shared
+build: build-shared
clean:: debian/control
dh_testdir
@@ -182,7 +182,7 @@
RUN_QUERY_IMMODULES_TEST=false \
RUN_QUERY_LOADER_TEST=false
-install: install-static install-shared
+install: install-shared
# generating debian files from .in
for f in `find debian/ -name [^c]*.in; do \
sed -e s/@VERSION@/${version}/g -e s/@MODVER@/${modver}/g
-e s/@APIVER@/${apiver}/g $$f `echo $$f | sed -e s/\.in//; \
--- gtk+2.0-2.6.4/debian/shlibs.local
+++ gtk+2.0-2.6.4.orig/debian/shlibs.local
@@ -1,4 +0,0 @@
-libgdk_pixbuf-2.0 0 libgtk2.0-0 (= 2.6.0)
-libgdk-x11-2.0 0 libgtk2.0-0 (= 2.6.0)
-libgtk-x11-2.0 0 libgtk2.0-0 (= 2.6.0)
-libgdk_pixbuf_xlib-2.0 0 libgtk2.0-0 (= 2.6.0)
Please explain what's going on with these changes, or (perhaps easier
anyway) upload a package that reverts them so that the other changes can be
approved more quickly.
BTW, I think the following change is also a no-op, because there is no
libgtk2.0-dbg package in sarge/sid:
only in patch2:
--- gtk+2.0-2.6.4.orig/debian/libgtk2.0-dbg.files
+++ gtk+2.0-2.6.4/debian/libgtk2.0-dbg.files
@@ -0,0 +1 @@
+usr/lib/debug/*
only in patch2:
--- gtk+2.0-2.6.4.orig/debian/libgtk2.0-dbg.dirs
+++ gtk+2.0-2.6.4/debian/libgtk2.0-dbg.dirs
@@ -0,0 +1 @@
+usr/lib/debug
Thanks,
--
Steve Langasek
postmodern programmer
signature.asc
Description: Digital signature
Re: Accepted lesstif1-1 1:0.93.94-11.3 (i386 source all)
Matej Vela wrote:
* NMU.
* lib/Xm/LTXpm.c: Backport previous security fixes to lesstif1
(CAN-2004-0914, CAN-2005-0605). Thanks to Kimmo Jukarainen for
doing the bulk of the work! Closes: #294099.
* lib/Xm-2.1/RCUtils.c: Apply upstream fix for label positioning in
menus. Closes: #279402.
Had a look for testing propigation purposes.
This seems broken:
- sprintf(buf, compress \%s\, filename);
- if (!(mdata-stream.file = popen(buf, w)))
+ snprintf(buf, sizeof(buf), compress \%s\, filename);
+ if (!(mdata-stream.file = s_popen(buf, w)))
And this:
- sprintf(buf, gzip -q \%s\, filename);
- if (!(mdata-stream.file = popen(buf, w)))
+ snprintf(buf, sizeof(buf), gzip -q \%s\, filename);
+ if (!(mdata-stream.file = s_popen(buf, w)))
Because s_popen does not support redirection and so on since it avoids
accessing the shell:
+** This is a secure but NOT 100% compatible replacement for popen()
+** Note:- don't use pclose() use fclose() for closing the returned
+**filedesc.!!!
+**
+** Known Bugs: - unable to use i/o-redirection like or
I didn't check to see if NO_ZPIPE gets defined; if it does the blocks of
code above won't be built in. And yes, I noticed the same code already
exists in Xm-2.1/Xpm.c, also in #ifndef NO_ZPIPE.
Another problem with this s_popen is that it doesn't interpolate quotes
the way the shell does, so calls to s_popen (or popen with the above
#define) like these all won't work:
+ snprintf(buf, sizeof(buf), uncompress -c \%s\,
compressfile);
+ if (!(mdata-stream.file = s_popen(buf, r))) {
+ snprintf(buf, sizeof(buf), gunzip -c \%s\,
compressfile);
+ if (!(mdata-stream.file = s_popen(buf, r))) {
+ snprintf(buf, sizeof(buf), uncompress -c \%s\, filename);
+ if (!(mdata-stream.file = s_popen(buf, r)))
+ snprintf(buf, sizeof(buf), gunzip -qc \%s\, filename);
+ if (!(mdata-stream.file = s_popen(buf, r)))
+ snprintf(buf, sizeof(buf), gzip -q \%s\, filename);
+ if (!(mdata-stream.file = s_popen(buf, w)))
+ snprintf(buf, sizeof(buf), compress \%s\, filename);
+ if (!(mdata-stream.file = s_popen(buf, w)))
For example, this last one ends up calling
execvp(compress, compress, , \%s\, filename).
This looks iffy:
+#ifndef NO_ZPIPE
+/* FILE *s_popen(char *cmd, const char *type); */
+#else
+# define s_popen popen
+#endif
I couldn't find any unpatches occurances of popen() in LTXpm.c. If there
were some and this is defined, it will break them because:
1. Like the comment above says, s_popen() calls must be paired with
fclose(), not pclose().
2. They'd be subject to the shell interpolation problems described
above.
I think this is broken; data_size is used undefined AFAICS:
@@ -7027,6 +7289,7 @@
static void
CreateExtensions(
char **dataptr,
+unsigned int data_size,
unsigned int offset,
_LtXpmExtension *ext,
unsigned int num,
@@ -7039,12 +7302,12 @@
dataptr++;
a = 0;
for (x = 0; x num; x++, ext++) {
- sprintf(*dataptr, XPMEXT %s, ext-name);
+ snprintf(*dataptr, data_size, XPMEXT %s, ext-name);
A similar problem is in the patch to CreatePixels and WritePixels2 and
WriteExtensions2.
--
see shy jo
signature.asc
Description: Digital signature
Removed nautilus-sendto from testing-proposed-updates
We believe that the request you reported is now fixed; the following package(s) have been removed from testing-proposed-updates: nautilus-sendto | 0.3-2sarge1 | source, i386 Reason: RoRM; Doesn't meet the freeze guidelines Note that the package(s) have simply been removed from the tag database and may (or may not) still be in the pool; this is not a bug. The package(s) will be physically removed automatically when no suite references them (and in the case of source, when no binary references it). Please also remember that the changes have been done on the master archive (ftp-master.debian.org) and will not propagate to any mirrors (ftp.debian.org included) until the next cron.daily run at the earliest. Packages are never removed from testing by hand. Testing tracks unstable and will automatically remove packages which were removed from unstable when removing them from testing causes no dependency problems. Bugs which have been reported against this package are not automatically removed from the Bug Tracking System. Please check all open bugs and close them or re-assign them to another package if the removed package was superseded by another one. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to the just-closed bug (or by replying to this mail if there is no bug closed). This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED] Debian distribution maintenance software pp. Jeroen van Wolffelaar (the ftpmaster behind the curtain) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#301370: marked as done (quota postrm fails due to missing dependency)
Hi Michael, On Tue, May 10, 2005 at 06:03:25AM -0700, Debian Bug Tracking System wrote: Format: 1.7 Date: Tue, 10 May 2005 14:19:40 +0200 Source: quota Binary: quota Architecture: source i386 Version: 3.12-5 Distribution: unstable Urgency: medium Maintainer: Michael Meskes [EMAIL PROTECTED] Changed-By: Michael Meskes [EMAIL PROTECTED] Description: quota - implementation of the disk quota system Closes: 301035 301040 301370 Changes: quota (3.12-5) unstable; urgency=medium . * Added some fixes for documentation from CVS, closes: #301035, #301040 * Fixed postrm to not call update-inetd if not present, closes: #301370 There appear to be a number of undocumented changes, relative to -4, which are not documentation fixes. :/ Would you remind removing them and uploading a -4sarge1 to testing-proposed-updates, or else explain why these changes are warranted during the freeze? Incidentally, I'm puzzled why quota is calling update-inetd at all from the postrm, since there's no code in the postinst which adds an inetd entry. That shouldn't be a blocker for sarge, though. Thanks, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
updated kftgt 1.6-3 for sarge
I uploaded kftgt 1.6-3 to fix Bug#308400 missing dependency for update-inetd. The only change from 1.6-2 is an added dependency on netbase. I believe that this should go into sarge. Thanks, Ben. -- It takes a certain amount of shamelessness to be a monomaniac billionaire dwarf. --Jon Katz URL:http://slashdot.org/articles/99/03/17/1634238.shtml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
