Bug#1062810: Update

[Joel Rosdahl]

On Sun, Feb 4, 2024, at 13:04, Pushkar Kulkarni wrote:
> Do you plan on doing a new upstream release?

Yes, that's what I plan to do tomorrow in addition to uploading a new Debian 
package.

-- Joel

Bug#1062810: ccache fails to run it's autopkg tests

[Joel Rosdahl]

I hope to find time to fix this tomorrow.

-- Joel

Bug#1059468: defsubst with leads to "Optimizer error: too much on the stack"

[Joel Rosdahl]

Package: emacs-gtk
Version: 1:29.1+1-5

As noted in Debian bug report #1058739, Emacs fails to byte-compile code like 
this:

(defsubst bar (a  b) nil)
(defun foo () (bar 1 2 3 4))

Result:

$ emacs -Q --batch -f batch-byte-compile repro.el

In toplevel form:
repro.el:2:2: Error: Optimizer error: too much on the stack

This makes the lyskom-elisp-client package uninstallable.

-- Joel

Bug#1058739: lyskom-elisp-client: fails to install with Emacs 29: lyskom-elisp-client.el:17452:2: Error: Optimizer error: too much on the stack

[Joel Rosdahl]

This looks like an Emacs bug.

Reduced reproducer:

$ cat repro.el
(defsubst bar (a  b) nil)
(defun foo () (bar 1 2 3 4))
$ emacs -Q --batch -f batch-byte-compile repro.el

In toplevel form:
repro.el:2:2: Error: Optimizer error: too much on the stack

I'll see if I can make some workaround.

-- Joel

Bug#1033349: unblock: ccache/4.8+really4.7.5-1

[Joel Rosdahl]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Control: affects -1 + src:ccache

Please unblock package ccache

[ Reason ]
Ccache versions 4.7 - 4.7.4 by default enable a feature called the inode cache
which shares information between processes via a memory mapped file,
synchronized by pthread mutexes. There have been reports that there is some
problem related to this in at least the GitHub actions environment; see Debian
bug #1033191.

In versions earlier than 4.7 the feature was off by default. Version 4.7.5 turns
the feature off by default again. (I made version 4.7.5 as the upstream ccache
maintainer for this purpose alone.)

[ Impact ]
Users running Debian in containers in the GitHub environment may experience
hanging builds. It is of course possible that the feature triggers problems in
other environments as well.

[ Tests ]
There are automated functional tests, but nothing that is relevant for this
specific issue.

[ Risks ]
No risk. It is a trivial change of making the feature off by default, just like
it was in versions before 4.7.

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

unblock ccache/4.8+really4.7.5-1


ccache.debdiff
Description: Binary data

Bug#1033191: ccache: Solution to address the deadlocking issue with ccache 4.7 on Debian Bookworm.

[Joel Rosdahl]

On Sun, Mar 19, 2023, at 11:42, David Heidelberg wrote:
> The authors of ccache have mentioned that this version includes a rewrite 
> that addresses serious issues, such as deadlocks [2].

Just to clarify: the rewritten locking solution in 4.8 was not done to fix any 
known bug - it was done for portability reasons since the previous solution 
relied on pthread mutex behavior that is different in FreeBSD.

-- Joel

Bug#1033267: Upload ccache bookworm fix via testing-proposed-updates?

[Joel Rosdahl]

On Tue, Mar 21, 2023, at 20:55, Paul Gevers wrote:
> I'm wondering where you are reading that. The text says: If there are 
> unrelated changes in unstable, we ask you to revert these changes 
> instead of making an upload to testing-proposed-updates.
>
> What's unclear in that phrase?

I think that what made things unclear to me was the "revert" part which just
didn't fit my mental model of how things work. But under "Applying for an
unblock" I now read "[...] revert [...] e.g. by using a
new-version+reallyold-version versioning scheme". I've never seen that
workaround before. So IIUC this suggests using a version like
4.8-2+really4.7.5? Are there other ways since it says "e.g."?

-- Joel

Bug#1033267: Upload ccache bookworm fix via testing-proposed-updates?

[Joel Rosdahl]

Package: release.debian.org
Severity: normal

[ Short version ]
I prematurely uploaded ccache/4.8-1 to unstable to fix bug #1033191. I would
like to get a more targeted fix into testing instead of that one. Would it be
appropriate to use testing-proposed-updates for this, as suggested on the freeze
policy page?

[ Long version ]
Ccache versions 4.7–4.7.4 by default enable a feature called the inode cache
which shares information between processes via a memory mapped file,
synchronized by pthread mutexes. Yesterday, a user reported that he is seeing
ccache processes hanging on futex calls (related to the inode cache feature) on
GitLab runners with Debian bookworm as well as other distributions using ccache
4.7.4. The inode cache synchronization mechanism was rewritten in ccache 4.8 to
use spin locks, thus taking pthread mutexes out of the equation, so after
reviewing the freeze policy page briefly I uploaded ccache/4.8-1 to improve the
situation since ccache is a non-key package with good autopkgtests.

Except I was wrong: ccache is apparently considered a key package, which I did
not know. Also, in retrospect, I was too stressed and should definitely have
made a more targeted fix.

The user then submitted Debian bug #1033191 with severity serious. I agree that
it would be unfortunate to ship ccache 4.7.4 in bookworm. Unless fixed, builds
using ccache 4.7.4 (maybe in specific container environments such as GitLab
runners with buggy kernels, maybe in other scenarios) risk getting stuck.

For reference, I'm attaching the targeted fix I would like to make.

-- Joel
diff -Nru ccache-4.7.4/LICENSE.adoc ccache-4.7.5/LICENSE.adoc
--- ccache-4.7.4/LICENSE.adoc	2022-11-21 19:53:32.0 +0100
+++ ccache-4.7.5/LICENSE.adoc	2023-03-20 20:47:12.0 +0100
@@ -35,7 +35,7 @@
 
 
 Copyright (C) 2002-2007 Andrew Tridgell
-Copyright (C) 2009-2022 Joel Rosdahl and other contributors
+Copyright (C) 2009-2023 Joel Rosdahl and other contributors
 
 
 
diff -Nru ccache-4.7.4/cmake/CcacheVersion.cmake ccache-4.7.5/cmake/CcacheVersion.cmake
--- ccache-4.7.4/cmake/CcacheVersion.cmake	2022-11-21 19:53:32.0 +0100
+++ ccache-4.7.5/cmake/CcacheVersion.cmake	2023-03-20 20:47:12.0 +0100
@@ -22,7 +22,7 @@
 # CCACHE_VERSION_ORIGIN is set to "archive" in scenario 1 and "git" in scenario
 # 3.
 
-set(version_info "1527040bc2a278b9d3d51badb732ecf5841d8bb5 HEAD, tag: v4.7.4, origin/master, origin/HEAD, master")
+set(version_info "9b1033f3ae534e5aad02c10f663b589b8f28c026 HEAD, tag: v4.7.5, origin/HEAD, origin/4.7-maint, 4.7-maint")
 set(CCACHE_VERSION "unknown")
 
 if(version_info MATCHES "^([0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f])[0-9a-f]* (.*)")
diff -Nru ccache-4.7.4/debian/changelog ccache-4.7.5/debian/changelog
--- ccache-4.7.4/debian/changelog	2022-11-21 20:40:46.0 +0100
+++ ccache-4.7.5/debian/changelog	2023-03-20 21:59:44.0 +0100
@@ -1,3 +1,10 @@
+ccache (4.7.5-1) unstable; urgency=medium
+
+  * New upstream release 4.7.5, whose only change compared with 4.7.4 is
+to disable the inode cache by default (closes: #1033191)
+
+ -- Joel Rosdahl   Mon, 20 Mar 2023 21:59:44 +0100
+
 ccache (4.7.4-1) unstable; urgency=medium
 
   * New upstream release 4.7.4
diff -Nru ccache-4.7.4/doc/MANUAL.adoc ccache-4.7.5/doc/MANUAL.adoc
--- ccache-4.7.4/doc/MANUAL.adoc	2022-11-21 19:53:32.0 +0100
+++ ccache-4.7.5/doc/MANUAL.adoc	2023-03-20 20:47:12.0 +0100
@@ -756,7 +756,7 @@
 
 If true, ccache will cache source file hashes based on device, inode and
 timestamps. This reduces the time spent on hashing include files since the
-result can be resused between compilations. The default is true. The feature
+result can be resused between compilations. The default is false. The feature
 requires <> to be located on a local
 filesystem of a supported type.
 +
diff -Nru ccache-4.7.4/doc/NEWS.adoc ccache-4.7.5/doc/NEWS.adoc
--- ccache-4.7.4/doc/NEWS.adoc	2022-11-21 19:53:32.0 +0100
+++ ccache-4.7.5/doc/NEWS.adoc	2023-03-20 20:47:12.0 +0100
@@ -1,5 +1,16 @@
 = Ccache news
 
+== Ccache 4.7.5
+
+Release date: 2023-03-20
+
+=== Bug fixes
+
+- Disabled the inode cache by default again since there have reports of ccache
+  processes hanging on futex calls related to the inode cache. +
+  [small]#_[contributed by Joel Rosdahl]_#
+
+
 == Ccache 4.7.4
 
 Release date: 2022-11-21
diff -Nru ccache-4.7.4/src/Config.hpp ccache-4.7.5/src/Config.hpp
--- ccache-4.7.4/src/Config.hpp	2022-11-21 19:53:32.0 +0100
+++ ccache-4.7.5/src/Config.hpp	2023-03-20 20:47:12.00000 +0100
@@ -1,4 +1,4 @@
-// Copyright (C) 2019-2022 Joel Rosdahl and other contributors
+// Copyright (C) 2019-2023 Joel Rosdahl and other contributors
 //
 // See doc/AUTHORS.adoc for a complete list of contributors.
 //
@@ -181,7 +181,7 @@
   bool m_hash_dir = true;
   std::string m_ignore_headers_in_manif

Bug#1022704: ccache: broken in cross-architecture chroot

[Joel Rosdahl]

Thanks!

Now I understand the problem and will work on a fix.

The issue is sharing the inode cache file between architectures. A workaround is
to either use separate temporary directories for the architectures (or different
cache directories when the temporary directory defaults to the cache directory,
which is the case for you), or to disable the inode cache by setting

inode_cache = false

in the config file.

Regards,
Joel

Bug#1022704: ccache: broken in cross-architecture chroot

[Joel Rosdahl]

On Mon, Oct 24, 2022, at 21:31, Raphaël Halimi wrote:
> I don't know how to use strace. Could you please direct me ?

If you find the process that hangs (likely a ccache process in this case) with
PID P, use

strace -p P

to attach to it and see which system call it is waiting for.

> The file does not exist on my machine; do I just need to create
> /var/cache/pbuilder/ccache/ccache.conf containing a single line "log_file=..."
> or is there something else to do ?

Yes, something like

echo "log_file = /var/cache/pbuilder/ccache/ccache.log" 
>/var/cache/pbuilder/ccache/ccache.conf

should do it.

Regards,
Joel

Bug#1022704: ccache: broken in cross-architecture chroot

[Joel Rosdahl]

On Mon, Oct 24, 2022, at 15:26, Raphaël Halimi wrote:
> Install pbuilder on an amd64 host and prepare an i386 chroot. Then, try to
> build a package in it (I was rebuilding timidity). It should hang during the
> configure phase.

I've never used pbuilder before, but I've tried creating an i386 chroot now,
setting CCACHEDIR according to pbuilderrc(5).

I then built timidity multiple times with "pdebuild --architecture i386", but it
works fine for me every time. I've checked that ccache 4.7.1-1 is being used and
that the ccache directory is being utilized. I'm afraid I'll need more help to
track this down.

1. When you say that it systematically hangs, can you check which process is
   hanging and what it hangs on, e.g. using strace?
2. Would it be possible for you to set CCACHE_LOGFILE (or log_file in
   ccache.conf in the ccache directory) to a file inside the pbuilder chroot and
   then publish the created log file?

Regards,
Joel

Bug#1022704: ccache: broken in cross-architecture chroot

[Joel Rosdahl]

On Mon, Oct 24, 2022, at 13:40, Raphaël Halimi wrote:
> I also tested it, it's broken too.

Thanks.

Can you give me more some detailed hints on how I can reproduce the issue?

Regards,
Joel

Bug#1022704: ccache: broken in cross-architecture chroot

[Joel Rosdahl]

Hi Raphaël,

Could you test if ccache 4.7.1-1 improves the situation?

Regards,
Joel

Bug#987328: unblock: lyskom-elisp-client/0.48+git.20200923.ec349ff4-3

[Joel Rosdahl]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package lyskom-elisp-client

0.48+git.20200923.ec349ff4-3 fixes two important/release critical
bugs: #985871 and #987260.

Changes:

1. Only support Emacs flavor "emacs", i.e., drop support for xemacs21 since it's
   unsupported. This addresses #987260.
2. Be more robust when removing files on purge of the package. This addresses
   #985871.

Debdiff between the version currently in testing (0.48+git.20200923.ec349ff4-1)
and the one in unstable (0.48+git.20200923.ec349ff4-3) attached.

Regards,
Joel


lyskom-elisp-client.debdiff
Description: Binary data

Bug#984674: ccache: clang links missing in /usr/lib/ccache

[Joel Rosdahl]

On Sat, 6 Mar 2021 at 22:51, Joachim Wuttke  wrote:
> Package ccache installs a number of symbolic links to /usr/lib/ccache, among
> them clang-11 and clang++-11, but not clang and clang++. May I kindly suggest
> you add these two?

The problem is that /usr/bin/clang is created (via the alternatives mechanism)
after ccache's postinst script has run, so ccache currently has no way of
detecting that compiler name. A workaround is to run
/usr/sbin/update-ccache-symlinks manually to install the symlink.

This is essentially the same bug as #632779.

Regards,
Joel

Bug#972256: ccache: please add symlink for emcc (emscripten)

[Joel Rosdahl]

Hi Jonas,

I've had a quick look at emcc now. I don't feel comfortable adding a ccache
symlink for it without some kind of evaluation of how emcc's options interact
when using the "-c" mode -- a symlink in /usr/lib/ccache would signal that
ccache officially supports emcc, which it doesn't (yet).

>From "emcc --help" I see that the following options take an argument, which is
something that ccache would need to be taught about to work properly:

--closure
--js-transform
--llvm-opts
--memory-init-file
--minify
--output_eol
--source-map-base
--valid-abspath
-s

On the other hand, perhaps none of these are applicable (or used in practice)
when using "-c", but that's not something I can rule out.

This option definitely isn't compatible with ccache since it changes the output
filename:

--default-obj-ext

These options take an argument that refers to an input file which ccache should
read and hash separately as part of the input:

--embed-file
--exclude-file
--extern-post-js
--extern-pre-js
--js-library
--post-js
--pre-js
--preload-file
--shell-file

Again, maybe none of those are applicable when using "-c" but I can't really
tell.

These produce another output file which would need to be cached by ccache:

-gseparate-dwarf
--emit-symbol-map

They don't seem to have any effect when using "-c", though?

Some environment variables (EMMAKEN_CFLAGS, EMCC_CLOSURE_ARGS) maybe also need
special treatment?

Regards,
Joel

On Thu, 15 Oct 2020 at 12:39, Jonas Smedegaard  wrote:
>
> Package: ccache
> Version: 3.7.12-1
> Severity: normal
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> The emcc command part of emscripten supports ccache:
> https://github.com/emscripten-core/emscripten/issues/11974
>
> Please ship the Debian ccache package with symlink for emcc.
>
>  - Jonas
>
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl+IJmQACgkQLHwxRsGg
> ASHfYQ/8DGUQ8OMRwT2w/SSnFpkTghr0TkNbEb45YwAY8xuSL0oAQR5+roQ313Nj
> oBGBovDd1lDa/D3uOuCfcLkNxH3C4s0hvZ/fh38XU1QN9F2HZWfkzpvaL5FGbt7+
> GbRtwxPRAu8NwJkwvecQKKRNEAyS/pLdQ1U04ephVjDsNh4dTn7nS2pEOUfO/Dwo
> 6UiU+FMupQDq0EaSPpakczFSZRRdtaBuBYkBuHVkMUild3GVrQZr5pOFogF+S823
> hsnvMmkmaZ1PEpOueU0iD8Yvj8k2EO5nT5iN3+b9vm/o2HezKDNC1YchhjmBjjxL
> oQF1TOeAl+E5WZDKx/9TVgpnXqSLWbANyoICzMCpumfLSYNm/88TraFd8AE7eLSc
> O1BZkXId4Rb3ZwCbucMz+rWo8lHvFMaUuCTuQuXLwCE7ieFhhcNuvg62NEw9c7lt
> E896UwlcGVcEvaao1vvLobeaTO+NY+a0CqdQO8Oipe8VSMP9MG+iKezNferJwbXa
> K8lof9cYe9inTgchdQXUOPPEEkT3Y/Eii1Mh4sDxaMphFct9y+CNwRHz5xjZLW5N
> nZSZlr+Z0SRe2s0J6XfyfBkXzx/VicDwLnji8i5/ENZCiShraabl6v6wGtPltOMJ
> +9AcRB7MneolTxFSaGN37T+ARpYNgPEu3NolS0d2BJEJai4wxf4=
> =DEVw
> -END PGP SIGNATURE-
>

Bug#965271: ccache: Doesn't cache anymore C++ files

[Joel Rosdahl]

Hi Christian,

Thanks for the bug report.

ccache works for me for C++ files (I use it all the time) so I need
more information than "it doesn't work" to have any chance of doing
anything. For example what you do to draw the conclusion that ccache
doesn't cache C++ files anymore.

Here is some general information on how to debug caching problems:
https://ccache.dev/manual/3.7.10.html#_cache_debugging

Regards,
Joel



On Sat, 18 Jul 2020 at 17:09, Christian Marillat  wrote:
>
> Package: ccache
> Version: 3.7.10-1
> Severity: normal
>
> Dear Maintainer,
>
> Since recently (maybe 2 or 3 weeks) ccache doesn't cache c++ files.
>
> I see the same for all my architectures amd64, i386, armel, armhf, arm64 and 
> powerpc
>
> Christian
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers buildd-unstable
>   APT policy: (500, 'buildd-unstable'), (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.7.9 (SMP w/8 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages ccache depends on:
> ii  libc6   2.31-1
> ii  zlib1g  1:1.2.11.dfsg-2
>
> ccache recommends no packages.
>
> Versions of packages ccache suggests:
> pn  distcc | icecc  
>
> -- no debconf information
>

Bug#938192:

[Joel Rosdahl]

I think that it's time to remove python-sqlite from Debian: it's a
module for the obsolete SQLite 2 API and there's (understandably) no
upstream activity.

Bug#938099:

[Joel Rosdahl]

I think that it's time to remove python-pysqlite2 from Debian: Python
has had support for SQLite 3 since version 2.5 and there is
(understandably) no upstream activity for the Python wrapper.

Bug#947607: O: egenix-mx-base -- eGenix mx Base Distribution for Python

[Joel Rosdahl]

Package: wnpp
Severity: normal
thanks

Bug#944399: ccache: Building aosp-10 bionic leads to ld.lld: error: undefined symbol: strcpy_a9

[Joel Rosdahl]

Thanks for the bug report.

On Sat, 9 Nov 2019 at 08:06, Stefan Rücker 
wrote:
> I can provide you files or infos from the failing build if you need
those, the
> problem is reproducible.

Yes, I will need assistance to investigate this. From
https://github.com/sonyxperiadev/bug_tracker/issues/492 I followed the
trail to
https://github.com/stefanhh0/aosp-10/blob/master/ and then to
https://developer.sony.com/develop/open-devices/guides/aosp-build-instructions
but failed at the "Initialise the AOSP tree" step. "repo sync" said this:

fatal: remove-project element specifies non-existent project:
device/google/marlin

Could you perhaps share more or less exactly which commands to use to get
the
AOSP source code and build it to reproduce the problem?

Also, could you report the bug in ccache's GitHub project
(https://github.com/ccache/ccache)?

Thanks,
-- Joel

Bug#942686: fix the installation of 3.8 extensions

[Joel Rosdahl]

reopen 942686
thanks

I applied the patch too quickly (see #943506) – it doesn't work with
the Python 3.7 filenames in current Debian unstable.

Python 3.8 apparently produces

apsw.cpython-38-x86_64-linux-gnu.so
apsw.cpython-38d-x86_64-linux-gnu.so

but Python 3.7 produces

apsw.cpython-37m-x86_64-linux-gnu.so
apsw.cpython-37dm-x86_64-linux-gnu.so

so the proposed pattern

usr/lib/python3*/*-packages/*.cpython-3?*-*.so

in python-apsw.install matches both the regular and the debug filename
for Python 3.7.

Matthias Klose: What's the preferred way of dealing with this situation?

-- Joel

Bug#928929: ccache: please add support for gcc/g++ 9

[Joel Rosdahl]

On Mon, 13 May 2019 at 11:21, Cyril Brulebois  wrote:
> Even if gcc-9 only appears in experimental for now (where gcc-defaults
> defaults to it), it'd be nice to have ccache have support for it.

With support, do you mean a symlink in /usr/lib/ccache? ccache should pick up
gcc-9 automatically by looking in /usr/lib/gcc/*, finding a directory called 9
and then finding /usr/bin/gcc-9. It seems to work for me when installing gcc-9
in unstable at least.

-- Joel

Bug#835812: jessie-pu: package ccache/3.1.12-2

[Joel Rosdahl]

Oh, right. I'm clearly confused on multiple levels here. (I erroneously
referenced #829088 above instead of #835460, and I closed #835460
prematurely. And I mixed up 3.1.12-1 with 3.1.12-2. This might or might not
be related to my daughter being born two days after I got the approval...)

I made some quick attempts at understanding how to use sbuild for
oldstable, but I failed, so unless somebody would like to help me build the
package in a clean oldstable environment, I think that we can close this
bug. I don't feel that I have time or patience enough to figure out why
sbuild doesn't work for me. :-(

-- Joel


On 27 June 2017 at 20:39, Cyril Brulebois <k...@debian.org> wrote:

> Joel Rosdahl <j...@debian.org> (2017-06-27):
> > Isn't it in jessie already? See <https://packages.debian.org/
> jessie/ccache>.
>
> Jessie has:
>   ccache | 3.1.12-1  | oldstable  | source, arm64, armel, armhf,
> i386, mips, mipsel, powerpc, ppc64el, s390x
>   ccache | 3.1.12-1+b1   | oldstable  | amd64
>
> You asked permission to update it to a new revision: 3.1.12-2 (note the
> last digit).
>
>
> KiBi.
>

Bug#835812: jessie-pu: package ccache/3.1.12-2

[Joel Rosdahl]

Hi,

> I still don't see ccache uploaded; should we keep this jessie-pu request
open?

Isn't it in jessie already? See <https://packages.debian.org/jessie/ccache>.

Regards,
-- Joel


On 27 June 2017 at 05:42, Cyril Brulebois <k...@debian.org> wrote:

> Hi Joel,
>
> Adam D. Barratt <a...@adam-barratt.org.uk> (2016-09-10):
> > On Sun, 2016-08-28 at 16:59 +0200, Joel Rosdahl wrote:
> > > To fix #829088 ("ccache don't stop immediately on SIGINT and
> SIGTERM"), I
> > > propose to upgrade ccache from 3.1.12-1 to 3.1.12-2 in
> stable-proposed-updates.
> > >
> > > The change is a simple one-liner: Call _exit(1) at the end of the
> signal
> > > handler to exit from e.g. SIGTERM. Without the exit, ccache will
> resume and run
> > > the compiler again.
> >
> > Please go ahead, bearing in mind that the window for 8.6 closes this
> > weekend.
>
> I still don't see ccache uploaded; should we keep this jessie-pu request
> open?
>
>
> KiBi.
>

Bug#855500: unblock: ccache/3.3.4-1

[Joel Rosdahl]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hi,

ccache 3.3.3 (which is in testing) has a serious bug which leads to
potentially
bad content of dependency files when compiling identical source code but
with
different source paths.

Debian bug: #853834
Upstream bug: https://github.com/ccache/ccache/issues/134

ccache 3.3.4 fixes this and two other minor bugs. No other functionality
was touched between 3.3.3 and 3.3.4. Please see the attached diff (changes
to auto-generated files have been trimmed).

I think that it would be a good idea to let ccache/3.3.4-1 into testing.

unblock ccache/3.3.4-1

-- Joel
diff -Nru ccache-3.3.3/debian/changelog ccache-3.3.4/debian/changelog
--- ccache-3.3.3/debian/changelog   2016-10-28 00:00:15.0 +0200
+++ ccache-3.3.4/debian/changelog   2017-02-17 23:02:40.0 +0100
@@ -1,3 +1,18 @@
+ccache (3.3.4-1) unstable; urgency=high
+
+  * New upstream release 3.3.4, which contains the following changes:
+* Fixes a serious regression in ccache 3.3 related to potentially bad
+  content of dependency files when compiling identical source code but
+  with different source paths (closes: #853834).
+* Trivial bug fix: Corrects which statistics counter to update for
+  -optf/--options-file failure.
+* Trivial bug fixes: Fixes undefined behavior warnings found by
+  -fsanitize=undefined.
+* Documentation update: Adds description of statistics counters to the
+  man page.
+
+ -- Joel Rosdahl <j...@debian.org>  Fri, 17 Feb 2017 23:02:40 +0100
+
 ccache (3.3.3-1) unstable; urgency=medium
 
   * New upstream release 3.3.3
diff -Nru ccache-3.3.3/AUTHORS.txt ccache-3.3.4/AUTHORS.txt
--- ccache-3.3.3/AUTHORS.txt2016-10-26 23:31:19.0 +0200
+++ ccache-3.3.4/AUTHORS.txt2017-02-17 22:28:53.0 +0100
@@ -7,7 +7,7 @@
 ccache is a collective work with contributions from many people, including:
 
 * Alfred Landrum <alfred.land...@riverbed.com>
-* Anders Björklund <and...@itension.se>
+* Anders Björklund <and...@psqr.se>
 * Andrea Bittau <a.bit...@cs.ucl.ac.uk>
 * Andrew P Boie <andrew.p.b...@intel.com>
 * Andrew Stubbs <a...@codesourcery.com>
@@ -56,6 +56,7 @@
 * Patrick von Reth <vonr...@kde.org>
 * Paul Griffith <pa...@cse.yorku.ca>
 * Pavel Boldin <pbol...@cloudlinux.com>
+* Philippe Proulx <eeppelitel...@gmail.com>
 * RW <fbs...@mlists.homeunix.com>
 * Ramiro Polla <ramiro.po...@gmail.com>
 * Robin H. Johnson <robb...@gentoo.org>
diff -Nru ccache-3.3.3/LICENSE.txt ccache-3.3.4/LICENSE.txt
--- ccache-3.3.3/LICENSE.txt2016-10-26 23:31:19.0 +0200
+++ ccache-3.3.4/LICENSE.txt2017-02-17 22:28:53.0 +0100
@@ -38,7 +38,7 @@
 
 -------
   Copyright (C) 2002-2007 Andrew Tridgell
-  Copyright (C) 2009-2016 Joel Rosdahl
+  Copyright (C) 2009-2017 Joel Rosdahl
 ---
 
 
diff -Nru ccache-3.3.3/MANUAL.txt ccache-3.3.4/MANUAL.txt
--- ccache-3.3.3/MANUAL.txt 2016-10-26 23:31:19.0 +0200
+++ ccache-3.3.4/MANUAL.txt 2017-02-17 22:28:53.0 +0100
@@ -163,10 +163,11 @@
 When run as a compiler, ccache usually just takes the same command line options
 as the compiler you are using. The only exception to this is the option
 *--ccache-skip*. That option can be used to tell ccache to avoid interpreting
-the next option in any way and to pass it along to the compiler as-is. *Note*:
-*--ccache-skip* currently only tells ccache not to interpret the next option as
-a special compiler option -- the option will still be included in the direct
-mode hash.
+the next option in any way and to pass it along to the compiler as-is.
+
+NOTE: *--ccache-skip* currently only tells ccache not to interpret the next
+option as a special compiler option -- the option will still be included in the
+direct mode hash.
 
 The reason this can be important is that ccache does need to parse the command
 line and determine what is an input filename and what is a compiler option, as
@@ -297,8 +298,14 @@
 separator. Examples:
 +
 --
-* +%compiler% -v+
-* +%compiler% -dumpmachine; %compiler% -dumpversion+
+
+
+%compiler% -v
+
+
+
+%compiler% -dumpmachine; %compiler% -dumpversion
+
 
 You should make sure that the specified command is as fast as possible since it
 will be run once for each ccache invocation.
@@ -374,15 +381,15 @@
 when generating debug info (compiler option *-g* with variations).
 Exception: The CWD will not be included in the hash if *base_dir* is set
 (and matches the CWD) and the compiler option *-fdebug-prefix-map* is used.
-
-The reason for including the CWD in the hash by default is to prevent a
-problem with the storage of the current working directory in the debug info
-o

Bug#853834: Ccache storing and restoring file paths that may no longer be correct

[Joel Rosdahl]

On 18 February 2017 at 00:54, Ben Hutchings  wrote:
> I've also found that disabling direct mode (CCACHE_NODIRECT=1) is a
workaround,
> at least in this case.

Yes. When the direct mode is disabled, dependency files are created fresh
by the preprocessor instead of taken from the cache.

> The problem seems to be that a direct mode manifest contains a hash of
> the source and object files, but not any other associated output files.

Hm, not quite. The manifest (looked up from a hash of source code file +
command line arguments) contains a mapping from a set of include file
hashes to output file names (used for object file, dependency file and a
handful other types of output files). The output file names are in turn
based on a hash of the preprocessed output of the compilation. There's no
hash of the object file itself or any other output file. However, what I
call "output file name" above is called "object" in the manifest source
code, which is misleading. I'll change it! :-) See
https://ccache.samba.org/manual.html#_the_direct_mode if you're interested
in more details on how the direct mode works.

> It seems to be assumed that if the object files are identical then so any
other output files
> will also be identical, and that's not the case.

I wouldn't call it an assumption but rather an unforeseen side effect of
the "names of included files are no longer included in the hash of the
compiler's
preprocessed output" feature that snuck into ccache 3.3.

-- Joel

Bug#853834: Ccache storing and restoring file paths that may no longer be correct

[Joel Rosdahl]

Hi,

Upstream release 3.3.4 contains a fix for this problem. I uploaded a Debian
package of it to unstable just now and will look into requesting a freeze
unblock.

Regards,
-- Joel

Bug#835460: ccache don't stop immediately on SIGINT and SIGTERM

[Joel Rosdahl]

Thanks for the bug report.

I have submitted a request to fix this in stable:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835812

-- Joel

On 26 August 2016 at 00:22, Zavadovsky Yan  wrote:
> Package: ccache
> Version: 3.1.10-1
> Severity: important
> Tags: patch
>
> ccache 3.1.10 have regression in compare with 3.1.9 and earlier versions.
>
> Using ninja-build + ccache + some heavy cpp code which take long time to
> compile.
>
> 1)run ninja
> 2)ninja execute several ccache processes
> 3)ccaches run real compiler
> 4)while compiler is running press CTRL-C (or run kill -TERM|-INT )
> 5)ninja catch termination signal and sends same signal to all child process
> groups (every ccache+compiler was executed in own process group)
> 6)real compiler get signal and immediately exits
> 7)ccache get signal and just remove some own tempo files
> 8)ccache get SIGCHLD after childish compiler process, thinks that something
> fails and continue using 'fallback' function - i.e. running compiler again
> instead exiting
> 9)next CTRL-Cs is ignored by ninja and it is needed to manually run
> kill/killall to stop build process
>
> ccache 3.1.9 and earlier don't have this bug.
> ccache 3.2.3 and newer contain fix.
> 3.2.3 contain very simple fix which can be easily backported(patch included)
> into 3.1.10.
> 3.2.4 have better but more complex fix.
>
>
>
> -- System Information:
> Debian Release: 8.5
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.6.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=ru_RU.utf8, LC_CTYPE=ru_RU.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages ccache depends on:
> ii  libc6   2.19-18+deb8u4
> ii  zlib1g  1:1.2.8.dfsg-2+b1
>
> ccache recommends no packages.
>
> Versions of packages ccache suggests:
> ii  distcc  3.1-6.1

Bug#835812: jessie-pu: package ccache/3.1.12-2

[Joel Rosdahl]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: jessie
Severity: normal

To fix #829088 ("ccache don't stop immediately on SIGINT and SIGTERM"), I
propose to upgrade ccache from 3.1.12-1 to 3.1.12-2 in stable-proposed-updates.

The change is a simple one-liner: Call _exit(1) at the end of the signal
handler to exit from e.g. SIGTERM. Without the exit, ccache will resume and run
the compiler again.

See attachment for the proposed update diff relative to 3.1.12-1.

-- Joel
diff -Nru ccache-3.1.12/debian/changelog ccache-3.1.12/debian/changelog
--- ccache-3.1.12/debian/changelog  2016-07-15 19:54:06.0 +0200
+++ ccache-3.1.12/debian/changelog  2016-08-28 15:45:26.0 +0200
@@ -1,3 +1,11 @@
+ccache (3.1.12-2) stable; urgency=medium
+
+  * Exit properly from signal handler (closes: #835460)
+This fixes a regression in ccache 3.1.10 leading to ccache not dying
+properly when interrupted by a signal.
+
+ -- Joel Rosdahl <j...@debian.org>  Sun, 28 Aug 2016 15:45:26 +0200
+
 ccache (3.1.12-1) stable; urgency=medium

   * New upstream release 3.1.12 containing important bug fixes (and only
diff -Nru ccache-3.1.12/debian/patches/fix_signal_handler_exit.patch 
ccache-3.1.12/debian/patches/fix_signal_handler_exit.patch
--- ccache-3.1.12/debian/patches/fix_signal_handler_exit.patch  1970-01-01 
01:00:00.0 +0100
+++ ccache-3.1.12/debian/patches/fix_signal_handler_exit.patch  2016-08-28 
15:45:26.0 +0200
@@ -0,0 +1,13 @@
+Description: Exit properly from exit handler
+Author: Joel Rosdahl <j...@rosdahl.net>
+
+--- a/ccache.c
 b/ccache.c
+@@ -264,6 +264,7 @@ signal_handler(int signo)
+ {
+   (void)signo;
+   clean_up_pending_tmp_files();
++  _exit(1);
+ }
+
+ static void
diff -Nru ccache-3.1.12/debian/patches/series 
ccache-3.1.12/debian/patches/series
--- ccache-3.1.12/debian/patches/series 2016-07-15 19:54:06.0 +0200
+++ ccache-3.1.12/debian/patches/series 2016-08-28 15:45:26.0 +0200
@@ -1 +1,2 @@
 debian_specific_usage_docs.patch
+fix_signal_handler_exit.patch

Bug#831426: jessie-pu: package ccache/3.1.12-1

[Joel Rosdahl]

On 29 July 2016 at 14:18, Julien Cristau  wrote:
> It doesn't look like you're doing any error checking from lstat; is there no
> way it'll fail here?

Hm, right, not checking the error code is a mistake I made when backporting the
fix. However, I don't think it will cause any problem in practice.

The code looks like this about 30 lines above:

if (stat(argv[i], ) != 0 || !S_ISREG(st.st_mode)) {
// ...
continue;
}

So if argv[i] doesn't exist or is not a file (or a symlink to an existing
file), we won't reach the lstat call. However, lstat will fail if the file or
symlink happens to be removed between the stat and lstat calls. It looks like
lstat doesn't touch the stat buffer on failure, so st's content will remain
from the stat call and S_ISLNK(st.st_mode) will then be false. The false branch
will call make_relative_path which handles non-existing files correctly.

Do you think that this is serious enough to require an updated
package? If so, I'll do it.

-- Joel

Bug#829088: Jessie

[Joel Rosdahl]

For reference: I have requested to include ccache 3.1.12 in Jessie in
#831426 .

-- Joel

Bug#831426: jessie-pu: package ccache/3.1.12-1

[Joel Rosdahl]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: jessie
Severity: normal

As suggested by Stefan Fritsch in #829088 ("ccache may silently
miscompile symlinked source files"), I propose to upgrade ccache from
3.1.10 to 3.1.12 in jessie. I'm the upstream maintainer of ccache as
well and I made the 3.1.12 release specifically for Debian stable to fix
#829088. Upgrading from 3.1.10 to 3.1.12 would also include three other
bug fixes that I think would be good to have in jessie.

Here's a summary of the bug fixes:

>From 3.1.12:

- Fixes a bug where (due to ccache rewriting paths) the compiler could
  choose incorrect include files if CCACHE_BASEDIR is used and the
  source file path is absolute and is a symlink. (Closes: #829088.)

>From 3.1.11:

- Fixes a bug which could result in false cache hits when source code
  contains '"' followed by " /*" or " //" (with variations).
- Makes hash of cached result created with and without CCACHE_CPP2
  different. This makes it possible to rebuild with CCACHE_CPP2 set
  without having to clear the cache to get new results.
- Fixes a bug which could result in "No such file or directory" messages
  in the ccache log when the cache directory doesn't exist.

See attachment for the proposed update diff.

-- Joel
diff -Nru ccache-3.1.10/AUTHORS.html ccache-3.1.12/AUTHORS.html
--- ccache-3.1.10/AUTHORS.html  2014-10-19 19:12:05.0 +0200
+++ ccache-3.1.12/AUTHORS.html  2016-07-12 21:34:50.0 +0200
@@ -734,7 +734,7 @@
 
 
 ccache authors
-version 3.1.10
+version 3.1.12
 
   Table of Contents
   JavaScript must be enabled in your browser to display the 
table of contents.
@@ -915,8 +915,9 @@
 
 
 
-Version 3.1.10
-Last updated 2014-10-19 19:05:10 CEST
+Version 3.1.12
+Last updated
+ 2016-07-12 21:34:27 CEST
 
 
 
diff -Nru ccache-3.1.10/INSTALL.html ccache-3.1.12/INSTALL.html
--- ccache-3.1.10/INSTALL.html  2014-10-19 19:12:05.0 +0200
+++ ccache-3.1.12/INSTALL.html  2016-07-12 21:34:50.0 +0200
@@ -734,7 +734,7 @@
 
 
 ccache installation
-version 3.1.10
+version 3.1.12
 
   Table of Contents
   JavaScript must be enabled in your browser to display the 
table of contents.
@@ -843,8 +843,9 @@
 
 
 
-Version 3.1.10
-Last updated 2014-10-19 19:02:09 CEST
+Version 3.1.12
+Last updated
+ 2016-07-12 21:34:27 CEST
 
 
 
diff -Nru ccache-3.1.10/LICENSE.html ccache-3.1.12/LICENSE.html
--- ccache-3.1.10/LICENSE.html  2014-10-19 19:12:05.0 +0200
+++ ccache-3.1.12/LICENSE.html  2016-07-12 21:34:50.0 +0200
@@ -734,7 +734,7 @@
 
 
 ccache copyright and license
-version 3.1.10
+version 3.1.12
 
   Table of Contents
   JavaScript must be enabled in your browser to display the 
table of contents.
@@ -776,7 +776,7 @@
 
 
   Copyright (C) 2002-2007 Andrew Tridgell
-  Copyright (C) 2009-2011 Joel Rosdahl
+  Copyright (C) 2009-2016 Joel Rosdahl
 
 
 
@@ -1210,8 +1210,9 @@
 
 
 
-Version 3.1.10
-Last updated 2014-10-19 19:02:09 CEST
+Version 3.1.12
+Last updated
+ 2016-07-12 21:34:27 CEST
 
 
 
diff -Nru ccache-3.1.10/LICENSE.txt ccache-3.1.12/LICENSE.txt
--- ccache-3.1.10/LICENSE.txt   2014-10-19 19:12:05.0 +0200
+++ ccache-3.1.12/LICENSE.txt   2016-07-12 21:34:50.0 +0200
@@ -38,7 +38,7 @@
 
 ---
   Copyright (C) 2002-2007 Andrew Tridgell
-  Copyright (C) 2009-2011 Joel Rosdahl
+  Copyright (C) 2009-2016 Joel Rosdahl
 ---
 
 
diff -Nru ccache-3.1.10/MANUAL.html ccache-3.1.12/MANUAL.html
--- ccache-3.1.10/MANUAL.html   2014-10-19 19:12:05.0 +0200
+++ ccache-3.1.12/MANUAL.html   2016-07-12 21:34:50.0 +0200
@@ -734,7 +734,7 @@
 
 
 CCACHE(1)
-version 3.1.10
+version 3.1.12
 
   Table of Contents
   JavaScript must be enabled in your browser to display the 
table of contents.
@@ -2014,8 +2014,9 @@
 
 
 
-Version 3.1.10
-Last updated 2014-10-19 19:02:09 CEST
+Version 3.1.12
+Last updated
+ 2016-07-12 21:34:27 CEST
 
 
 
diff -Nru ccache-3.1.10/NEWS.html ccache-3.1.12/NEWS.html
--- ccache-3.1.10/NEWS.html 2014-10-19 19:12:05.0 +0200
+++ ccache-3.1.12/NEWS.html 2016-07-12 21:34:50.0 +0200
@@ -734,7 +734,7 @@
 
 
 ccache news
-version 3.1.10
+version 3.1.12
 
   Table of Contents
   JavaScript must be enabled in your browser to display the 
table of contents.
@@ -742,6 +742,55 @@
 
 
 
+ccache 3.1.12
+
+Release date: 2016-07-12
+
+Bug fixes
+
+
+
+Fixed a bug where (due to ccache rewriting paths) the compiler could choose
+  incorrect include files if CCACHE_BASEDIR is used and the 
source file path
+  is absolute and is a symlink.
+
+
+
+
+
+
+
+ccache 3.1.11
+
+Release date: 2015-03-07
+
+Bug fixes
+
+
+
+Fixed bug which could result in false cache hits when source code contains
+  '"' followed by " /*" or " //" (with 
variations).
+
+
+
+

Bug#829088: ccache may silently miscompile symlinked source files

[Joel Rosdahl]

On 15 July 2016 at 07:55, Jaap Keuter  wrote:
> Don't the release notes of the next version address this?
> https://ccache.samba.org/releasenotes.html#_ccache_3_2_6

Yes, it's a fix for this bug. I also made a 3.1.12 release especially for
Debian stable. I just haven't had time to make a Debian package of it yet.

-- Joel

Bug#815585: ccache: Incomplete link list for mingw-w64

[Joel Rosdahl]

On 22 February 2016 at 19:17, Andreas Metzler  wrote:
> installing mingw-w64 adds the following links to /usr/lib/ccache:
> i686-w64-mingw32-gcc-5.3-posix
> i686-w64-mingw32-gcc-5.3-win32
> x86_64-w64-mingw32-gcc-5.3-posix
> x86_64-w64-mingw32-gcc-5.3-win32
>
> However with "./configure --host i686-w64-mingw32" the Makefiles will
> invoke i686-w64-mingw32-gcc, which is not cached.

The problem is that i686-w64-mingw32-gcc is created (via the alternatives
mechanism) after ccache's postinst script has run, so ccache currently has
no way of detecting that compiler name. A workaround is to
run /usr/sbin/update-ccache-symlinks manually to install the symlinks.

Essentially the same bug as #632779.

-- Joel

Bug#784681: ccache: mednafen fails to build with ccache

[Joel Rosdahl]

I would say that this is a GCC bug - g++ can't compile its own preprocessed
source code.

The problem can be reproduced without ccache by building src/hash/sha1.cpp
with -save-temps:

% cd src
% /usr/bin/g++ -save-temps -DLOCALEDIR=\/usr/local/share/locale\
-DHAVE_CONFIG_H -I../include -I../include -I../intl-fsigned-char  -Wall
-Wshadow -Wempty-body -Wignored-qualifiers -Wvla -Wvariadic-macros
-Wdisabled-optimization  -fno-fast-math -fno-unsafe-math-optimizations
-fno-aggressive-loop-optimizations -fomit-frame-pointer -fwrapv  -g -O2
-std=gnu++11 -MT hash/sha1.o -MD -MP -MF $depbase.Tpo -c -o hash/sha1.o
hash/sha1.cpp
hash/sha1.cpp:161:128: error: invalid digit 9 in octal constant
  assert(sha1(tv, 65) == 079b9ef0684bd9a600b9a23caa4297d064ce076e_sha1);

^
hash/sha1.cpp: In function 'void sha1_test()':
hash/sha1.cpp:156:168: error: unable to find string literal operator
'operatore119a863bce69ad1b6ca1a51e94994531d122088'
  assert(sha1(tv, 55) == e119a863bce69ad1b6ca1a51e94994531d122088_sha1);


^
hash/sha1.cpp:157:168: error: unable to find string literal operator
'operatorfd62c272e1f0f24b92a0ec8360519cd64d6ab986'
  assert(sha1(tv, 56) == fd62c272e1f0f24b92a0ec8360519cd64d6ab986_sha1);


^
hash/sha1.cpp:158:128: error: expected ')' before numeric constant
  assert(sha1(tv, 57) == 010b0113d06cffb80f2beb657ef39682e5e7de79_sha1);

^
hash/sha1.cpp:159:168: error: unable to find string literal operator
'operatoradf8998c4791fc378fa6d8b23666934522546778'
  assert(sha1(tv, 63) == adf8998c4791fc378fa6d8b23666934522546778_sha1);


^
hash/sha1.cpp:160:128: error: expected ')' before numeric constant
  assert(sha1(tv, 64) == 787680a25bf74f34c22b2c37d7d5bae2feceb20c_sha1);

^
hash/sha1.cpp:161:128: error: expected ')' before numeric constant
  assert(sha1(tv, 65) == 079b9ef0684bd9a600b9a23caa4297d064ce076e_sha1);

^
% g++ --version | head -n1
g++ (Debian 4.9.2-16) 4.9.2

-- Joel

On 7 May 2015 at 20:17, Stephen Kitt sk...@debian.org wrote:

 Package: ccache
 Version: 3.1.10-1
 Severity: normal

 Dear Maintainer,

 The current version of mednafen (0.9.38.4) fails to build with ccache
 (after the first build):

 g++ -DLOCALEDIR=\/usr/share/locale\ -DHAVE_CONFIG_H -I../include
 -I../include -I../intl   -D_FORTIFY_SOURCE=2   -fsigned-char  -Wall
 -Wshadow -Wempty-body -Wignored-qualifiers -Wvla -Wvariadic-macros
 -Wdisabled-optimization  -fno-fast-math -fno-unsafe-math-optimizations
 -fno-aggressive-loop-optimizations -fomit-frame-pointer -fwrapv  -g -O2
 -fstack-protector-strong -Wformat -Werror=format-security -std=gnu++11 -c
 -o hash/sha1.o hash/sha1.cpp
 hash/sha1.cpp:161:128: error: invalid digit 9 in octal constant
   assert(sha1(tv, 65) == 079b9ef0684bd9a600b9a23caa4297d064ce076e_sha1);

   ^
 hash/sha1.cpp: In function ‘void sha1_test()’:
 hash/sha1.cpp:156:168: error: unable to find string literal operator
 ‘operatore119a863bce69ad1b6ca1a51e94994531d122088’
   assert(sha1(tv, 55) == e119a863bce69ad1b6ca1a51e94994531d122088_sha1);


   ^
 hash/sha1.cpp:157:168: error: unable to find string literal operator
 ‘operatorfd62c272e1f0f24b92a0ec8360519cd64d6ab986’
   assert(sha1(tv, 56) == fd62c272e1f0f24b92a0ec8360519cd64d6ab986_sha1);


   ^
 hash/sha1.cpp:158:128: error: expected ‘)’ before numeric constant
   assert(sha1(tv, 57) == 010b0113d06cffb80f2beb657ef39682e5e7de79_sha1);

   ^
 hash/sha1.cpp:159:168: error: unable to find string literal operator
 ‘operatoradf8998c4791fc378fa6d8b23666934522546778’
   assert(sha1(tv, 63) == adf8998c4791fc378fa6d8b23666934522546778_sha1);


   ^
 hash/sha1.cpp:160:128: error: expected ‘)’ before numeric constant
   assert(sha1(tv, 64) == 787680a25bf74f34c22b2c37d7d5bae2feceb20c_sha1);

   ^
 hash/sha1.cpp:161:128: error: expected ‘)’ before numeric constant
   assert(sha1(tv, 65) == 079b9ef0684bd9a600b9a23caa4297d064ce076e_sha1);

   ^
 Makefile:944: recipe for target 'hash/sha1.o' failed


 Uninstalling ccache allows the source to build.

 Regards,

 Stephen


 -- System Information:
 Debian Release: stretch/sid
   APT prefers testing
   APT policy: (500, 'testing'), (500, 'stable'), (200, 'unstable'), (1,
 'experimental')
 Architecture: amd64 (x86_64)
 Foreign Architectures: i386

 Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
 Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash
 Init: sysvinit (via /sbin/init)

 Versions of packages ccache depends on:
 ii  libc6   2.19-18
 ii  zlib1g  1:1.2.8.dfsg-2+b1

 ccache recommends no 

Bug#766604: ccache: C++ compiler does not support C++11 standard

[Joel Rosdahl]

Hi Jérémy,

Have you tried reproducing the problem with the mentioned steps?

Regards,
-- Joel


On 27 October 2014 at 21:39, Joel Rosdahl j...@debian.org wrote:

 Hi,

  Is it a bug or an unsupported feature ?

 It's a bug in something, but it's hard to say where with the given
 information. It could be in ccache, the compiler or mapnik's configure
 logic.

 I can't reproduce the problem by simply running mapnik's configure with
 ccache. Here's what I did:

 1. Downloaded mapnik v3.0.0-rc1 sources.
 2. Ran PATH=/usr/lib/ccache:$PATH ./configure.
 3. Got this output: Checking if compiler (g++) supports -std=c++11
 flag... (cached) yes

 Can you reproduce the problem with the above steps? If not, then sbuild
 might have something to do with it, although I find it unlikely.

 I don't quite understand why scons says (cached), by the way.

 I'm used these versions of ccache and g++:

 ccache version 3.1.10
 g++ (Debian 4.9.1-18) 4.9.1

 -- Joel

Bug#778388: ccache: scanner confused by comment signs in strings

[Joel Rosdahl]

Yes, a reduced testcase would be much appreciated. I don't have access to
https://codereview.qt-project.org/105039 and I wouldn't know what to do
anyway. :-)

(BTW: You did clear the cache before you compiled the changed source code,
right? Otherwise a cache hit is expected from the previous experiments, of
course. Just checking.)

-- Joel

On 16 February 2015 at 20:37, Oswald Buddenhagen oswald.buddenha...@gmx.de
wrote:

 this is pretty incredible ...
 i can't reproduce it with your testcase, either.
 but when i run the actual build with CCACHE_LOGFILE=/dev/stdout, it
 totally confirms that the issue is real:

 [2015-02-16T20:25:26.035076 20314] === CCACHE STARTED
 =
 [2015-02-16T20:25:26.035222 20314] Command line: /usr/bin/ccache
 /usr/bin/g++ -c -pipe -g -Wall -W -D_REENTRANT -fPIE -DQT_NO_MTDEV
 -DQT_NO_TSLIB -DQT_NO_LIBINPUT -DQT_NO_XKB -DPROPARSER_DEBUG
 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_TESTLIB_LIB -DQT_CORE_LIB
 -DQT_NAMESPACE=TestSpace
 -DQT_TESTCASE_BUILDDIR=/home/obuddenh/depot/qt5_build/qtbase/tests/auto/tools/qmakelib
 -I/home/obuddenh/depot/qt5/qtbase/tests/auto/tools/qmakelib -I.
 -I/home/obuddenh/depot/qt5/qtbase/qmake/library -I../../../../include
 -I../../../../include/QtTest -I../../../../include/QtCore -I.moc
 -I/home/obuddenh/depot/qt5/qtbase/mkspecs/linux-g++ -o .obj/qmakeparser.o
 /home/obuddenh/depot/qt5/qtbase/qmake/library/qmakeparser.cpp
 [2015-02-16T20:25:26.035255 20314] Hostname: troll08
 [2015-02-16T20:25:26.035295 20314] Working directory:
 /home/obuddenh/depot/qt5_build/qtbase/tests/auto/tools/qmakelib
 [2015-02-16T20:25:26.035379 20314] Source file:
 /home/obuddenh/depot/qt5/qtbase/qmake/library/qmakeparser.cpp
 [2015-02-16T20:25:26.035393 20314] Object file: .obj/qmakeparser.o
 [2015-02-16T20:25:26.035412 20314] Trying direct lookup
 [2015-02-16T20:25:26.035865 20314] Looking for object file hash in
 /home/obuddenh/.ccache/1/8/3571b3286295ea842e4d0e4b5d8614-51629.manifest
 [2015-02-16T20:25:26.055382 20314] Got object file hash from manifest
 [2015-02-16T20:25:26.055444 20314] Unlink .obj/qmakeparser.o via
 .obj/qmakeparser.o.tmp.rm.troll08.20314
 [2015-02-16T20:25:26.055697 20314] Copying
 /home/obuddenh/.ccache/6/1/77b6a1a9b40804c3fde51f0bc6c051-1584683.o to
 .obj/qmakeparser.o via .obj/qmakeparser.o.troll08.20314.XX
 (uncompressed)
 [2015-02-16T20:25:26.056724 20314] Created .obj/qmakeparser.o from
 /home/obuddenh/.ccache/6/1/77b6a1a9b40804c3fde51f0bc6c051-1584683.o
 [2015-02-16T20:25:26.056755 20314] Succeeded getting cached result
 [2015-02-16T20:25:26.056793 20314] Acquired lock
 /home/obuddenh/.ccache/6/stats.lock
 [2015-02-16T20:25:26.056988 20314] Releasing lock
 /home/obuddenh/.ccache/6/stats.lock
 [2015-02-16T20:25:26.057008 20314] Unlink
 /home/obuddenh/.ccache/6/stats.lock (as-tmp)
 [2015-02-16T20:25:26.057033 20314] Result: cache hit (direct)

 to reproduce it, you only need:

 qtbase/dev (@1d2efe1f27bedcbaa157ef4e82b8eda33dda46ad).
 this pending change: https://codereview.qt-project.org/105039 (PS3)
 including dependencies.
 this hunk on top:

 --- a/qmake/library/qmakeparser.cpp
 +++ b/qmake/library/qmakeparser.cpp
 @@ -1340,6 +1374,7 @@ static bool getBlock(const ushort *tokens, int
 limit, int offset, QString *outS
  return false;
  }
  *outStr += fL1S(  H() + fL1S(tokNames[maskedTok]);
 +*outStr += fL1S( /* \\u) + QString::number(maskedTok, 16) +
 fL1S( */);
  if (tok  TokNewStr)
  *outStr += fL1S( | TokNewStr);
  if (tok  TokQuoted)

 ... and a lot of time, heh.

 i thought i might have some env variables set (CCACHE_UNIFY), but this
 doesn't appear to be the case, either.

 i can try to extract a smaller testcase if you don't beat me to it.

Bug#778388: ccache: scanner confused by comment signs in strings

[Joel Rosdahl]

Thanks. After seeing more of the code, I have been able to reproduce the
problem. It's not only related to the code you added but also to the usage
of '' further up in the code. See attachment for a reproduction script.

The bug is not present in ccache 3.2 due to a rewrite of the relevant code.

-- Joel


On 16 February 2015 at 21:41, Oswald Buddenhagen oswald.buddenha...@gmx.de
wrote:

 On Mon, Feb 16, 2015 at 09:26:02PM +0100, Joel Rosdahl wrote:
  Yes, a reduced testcase would be much appreciated. I don't have access to
  https://codereview.qt-project.org/105039 and I wouldn't know what to do
  anyway. :-)
 
 oh, right, it was a draft, invite only. fixed now.
 i think you'll figure it out easily.
 anyway, cloning the whole thing seems like overkill, indeed.
 you can just get the patched version of the file from the diff view.
 from there it is extracting the code into a minimal qt/qmake project.
 i expect this to be a somewhat time-consuming iterative process, so i'm
 not exactly in a hurry ...

  (BTW: You did clear the cache before you compiled the changed source
 code,
  right? Otherwise a cache hit is expected from the previous experiments,
 of
  course. Just checking.)
 
 i retried with multiple string and number variants i didn't use before,
 so this is of no concern.




debian-bug-778388.sh
Description: Bourne shell script

Bug#778388: ccache: scanner confused by comment signs in strings

[Joel Rosdahl]

Hi Oswald,

I can't reproduce this problem. Here is what I did:

% ccache -C
Cleared cache
% sh debian-bug-778388.sh
cache miss
% sh debian-bug-778388.sh
cache hit (direct)
% sed -i s/16/17/ debian-bug-778388.sh
% sh debian-bug-778388.sh
cache miss
% sh debian-bug-778388.sh
cache hit (direct)


Note the cache miss after 16 was changed to 17 in the input source file.

See attachment for the debian-bug-778388.sh script.

I don't see anything in your source code example that ccache shouldn't be
able to handle. Could you give a more detailed reproduction recipe?

-- Joel

On 14 February 2015 at 14:26, Oswald Buddenhagen oswald.buddenha...@gmx.de
wrote:

 Package: ccache
 Version: 3.1.10-1
 Severity: normal

 i have this fine piece of code:

 *outStr += fL1S( /* \\u) + QString::number(maskedTok, 16) +
 fL1S( */);

 if i change anything between the /* parts, ccache will think that
 nothing changed ... even though the comment chars are obviously quoted,
 so they do not denote a section that is irrelevant for comparison.

 as expected, the problem goes away when the line is changed to:

 *outStr += fL1S( /* \\u) + QString::number(maskedTok, 16) +
 fL1S( */);

 -- System Information:
 Debian Release: jessie/sid
   APT prefers unstable
   APT policy: (500, 'unstable'), (1, 'experimental')
 Architecture: amd64 (x86_64)
 Foreign Architectures: i386

 Kernel: Linux 3.16-1-amd64 (SMP w/8 CPU cores)
 Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash

 Versions of packages ccache depends on:
 ii  libc6   2.19-7
 ii  zlib1g  1:1.2.8.dfsg-1

 ccache recommends no packages.

 Versions of packages ccache suggests:
 pn  distcc  none

 -- no debconf information




debian-bug-778388.sh
Description: Bourne shell script

Bug#766604: ccache: C++ compiler does not support C++11 standard

[Joel Rosdahl]

Hi,

 Is it a bug or an unsupported feature ?

It's a bug in something, but it's hard to say where with the given
information. It could be in ccache, the compiler or mapnik's configure
logic.

I can't reproduce the problem by simply running mapnik's configure with
ccache. Here's what I did:

1. Downloaded mapnik v3.0.0-rc1 sources.
2. Ran PATH=/usr/lib/ccache:$PATH ./configure.
3. Got this output: Checking if compiler (g++) supports -std=c++11 flag...
(cached) yes

Can you reproduce the problem with the above steps? If not, then sbuild
might have something to do with it, although I find it unlikely.

I don't quite understand why scons says (cached), by the way.

I'm used these versions of ccache and g++:

ccache version 3.1.10
g++ (Debian 4.9.1-18) 4.9.1

-- Joel

Bug#736301: python-sqlite-dbg: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Joel Rosdahl]

Hi Sebastian,

Thank you.

What confused me was that:

1. The python-sqlite-dbg_1.0.1-9_amd64.deb I have lying around does not
contain the symlink. This is the exactly the file I uploaded to the archive
on 2011-12-09.

and

2. My attempted piuparts command did not trigger the error. On a closer
look at the log, that's because it didn't even try to install
python-sqlite-dbg since it apparently doesn't work to run piuparts in a
chroot.

-- Joel



On 5 February 2014 17:50, Sebastian Ramacher sramac...@debian.org wrote:

 Hi Joesl

 On 2014-02-01 11:45:44, Joel Rosdahl wrote:
  As far as I can tell, neither python-sqlite-dbg nor python-sqlite in
  neither wheezy nor jessie contain symlinks for (or in) /usr/share/doc and
  don't create any symlinks in preinstall/postinstall scripts.

 python-sqlite-dbg in wheezy contains a symlink:

 $ dpkg -l python-sqlite-dbg
 ...
 ii  python-sqlite-dbg 1.0.1-9   amd64 ...

 $ file /usr/share/doc/python-sqlite-dbg
 /usr/share/doc/python-sqlite-dbg: symbolic link to `python-sqlite'

 However, python-sqlite-dbg in jessie ships a directory. After a fresh
 install:

 $ dpkg -l python-sqlite-dbg
 ...
 ii  python-sqlite-dbg 1.0.1-10  amd64 ...

 $ file /usr/share/doc/python-sqlite-dbg
 /usr/share/doc/python-sqlite-dbg: directory

 You can see the problem if you install python-sqlite-dbg in wheezy,
 upgrade to the version from jessie and then remove it (without removing
 python-sqlite). /usr/share/doc/python-sqlite no longer contains any
 files apart from README.Debian. copyright and changelog.Debian.gz are
 missing.

 So for upgrades this conversion from a symlink to a directory needs
 special handling: either handle the removal of the symlink in maintainer
 scripts or use dpkg-maintscript-helper's symlink_to_dir command to do
 that.

 Regards
 --
 Sebastian Ramacher

Bug#736301: python-sqlite-dbg: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Joel Rosdahl]

Hi Andreas,

Thanks for the bug report!

As far as I can tell, neither python-sqlite-dbg nor python-sqlite in
neither wheezy nor jessie contain symlinks for (or in) /usr/share/doc and
don't create any symlinks in preinstall/postinstall scripts. Therefore I
don't understand what needs to be done, if anything. In particular,

/usr/share/doc/python-sqlite-dbg/changelog.Debian.gz
(python-sqlite-dbg) != /usr/share/doc/python-sqlite/changelog.Debian.gz
(python-sqlite)
/usr/share/doc/python-sqlite-dbg/copyright (python-sqlite-dbg) !=
/usr/share/doc/python-sqlite/copyright (python-sqlite)

doesn't give me any ideas on what could be wrong. The fact that those files
are not the same doesn't sound like an error to me - of course they should
be different entities? I can't see anything about this in the piuparts FAQ.

I have never used piuparts before, but I tried running piuparts -a -d
wheezy -d jessie python-sqlite-dbg and that didn't seem to result in any
errors. Please describe in further detail how to reproduce the problem.

Thanks,
-- Joel


On 22 January 2014 03:50, Andreas Beckmann a...@debian.org wrote:

 Package: python-sqlite-dbg
 Version: 1.0.1-10
 Severity: serious
 User: debian...@lists.debian.org
 Usertags: piuparts

 Hi,

 an upgrade test with piuparts revealed that your package installs files
 over existing symlinks and possibly overwrites files owned by other
 packages. This usually means an old version of the package shipped a
 symlink but that was later replaced by a real (and non-empty)
 directory. This kind of overwriting another package's files cannot be
 detected by dpkg.

 This was observed on the following upgrade paths:

   wheezy - jessie

 For /usr/share/doc/PACKAGE this may not be problematic as long as both
 packages are installed, ship byte-for-byte identical files and are
 upgraded in lockstep. But once one of the involved packages gets
 removed, the other one will lose its documentation files, too,
 including the copyright file, which is a violation of Policy 12.5:
 http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile

 For other overwritten locations anything interesting may happen.

 Note that dpkg intentionally does not replace directories with symlinks
 and vice versa, you need the maintainer scripts to do this.
 See in particular the end of point 4 in

 http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-unpackphase

 It is recommended to use the dpkg-maintscript-helper commands
 'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.2)
 to perform the conversion, ideally using d/$PACKAGE.mainstscript.
 See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.


 From the attached log (usually somewhere in the middle...):

 0m40.3s ERROR: FAIL: silently overwrites files via directory symlinks:
   /usr/share/doc/python-sqlite-dbg/changelog.Debian.gz (python-sqlite-dbg)
 != /usr/share/doc/python-sqlite/changelog.Debian.gz (python-sqlite)
   /usr/share/doc/python-sqlite-dbg/copyright (python-sqlite-dbg) !=
 /usr/share/doc/python-sqlite/copyright (python-sqlite)


 cheers,

 Andreas

Bug#666525: trying to disable ccache locally, failing

[Joel Rosdahl]

Hi,

 ccache seems to ignore the request [...] Is there some ccache subtlety
I'm missing?

ccache doesn't ignore the request, it just happens to make sure that the
ccache directory exists before reacting to CCACHE_DISABLE (or
CCACHE_READONLY)... Looks like it has been that way since day one (well,
day two, actually:
http://gitweb.samba.org/?p=ccache.git;a=commit;h=10920460b5b00b77316602eb4e7c998a80464a88
).

I've fixed the bug now (upstream), but there's no workaround in currently
released ccache versions, I'm afraid.

-- Joel


On 30 August 2013 00:03, Yann Dirson ydir...@free.fr wrote:

 By tuning the stap script to SIGSTOP the offending process, we can get
 a much better view of the situation - here using pstree:

 pbuilder,4611 /usr/sbin/pbuilder --build --buildresult .. --debbuildopts
  --debbuildopts -i ../cssc_1.3.0-1.dsc
   └─pbuilder-buildp,4612 /usr/lib/pbuilder/pbuilder-buildpackage
 --buildresult .. --debbuildopts  --debbuildopts -i ../cssc_1.3.0-1.dsc
   └─pbuilder-satisf,5767 /usr/lib/pbuilder/pbuilder-satisfydepends
 --control ../cssc_1.3.0-1.dsc --chroot /work/pbuilder/build//4612
 --internal-chrootexec chroot /work/pbuilder/build//4612  --binary-all
   └─pbuilder-satisf,5768 /usr/lib/pbuilder/pbuilder-satisfydepends
 --control ../cssc_1.3.0-1.dsc --chroot /work/pbuilder/build//4612
 --internal-chrootexec chroot /work/pbuilder/build//4612  --binary-all
   └─dpkg-architectu,5769 /usr/bin/dpkg-architecture
 -qDEB_HOST_ARCH
   └─sh,5770 -c ${CC:-gcc} -dumpmachine
   └─gcc,5771 -dumpmachine

 A quick test can be done of reqesting disabling of ccache while calling
 dpkg-architecture.

 Test:

 --- /usr/lib/pbuilder/pbuilder-satisfydepends.orig  2013-08-29
 23:34:32.0 +0200
 +++ /usr/lib/pbuilder/pbuilder-satisfydepends   2013-08-29
 23:36:23.0 +0200
 @@ -59,7 +59,7 @@

  function checkbuilddep_internal () {
  # Use this function to fulfill the dependency (almost)
 -local ARCH=$($CHROOTEXEC dpkg-architecture -qDEB_HOST_ARCH)
 +local ARCH=$($CHROOTEXEC env CCACHE_DISABLE=1 dpkg-architecture
 -qDEB_HOST_ARCH)
  local BUILD_DEP_DEB_DIR
  local BUILD_DEP_DEB_CONTROL
  local DEPENDS

 For some reason, the stap script still traps a mkdir done as root,
 while I can check through /proc that dpkg-architecture and gcc do have
 CCACHE_DISABLE=1 in their env.

 Another try: if ccache ignores the disable request, maybe we can ask
 it not to touch the cache ?

 --- /usr/lib/pbuilder/pbuilder-satisfydepends.orig  2013-08-29
 23:34:32.0 +0200
 +++ /usr/lib/pbuilder/pbuilder-satisfydepends   2013-08-29
 23:56:48.0 +0200
 @@ -59,7 +59,7 @@

  function checkbuilddep_internal () {
  # Use this function to fulfill the dependency (almost)
 -local ARCH=$($CHROOTEXEC dpkg-architecture -qDEB_HOST_ARCH)
 +local ARCH=$($CHROOTEXEC env CCACHE_READONLY=1
 CCACHE_TEMPDIR=${TMPDIR:-/tmp} dpkg-architecture -qDEB_HOST_ARCH)
  local BUILD_DEP_DEB_DIR
  local BUILD_DEP_DEB_CONTROL
  local DEPENDS

 ... but similarly, ccache seems to ignore the request, which can be
 seen in the processes' env.


 Is there some ccache subtlety I'm missing ?  Could ccache maints lend a
 hand here ?

 Best regards,
 --
 Yann

Bug#718830: python-apsw: Required dependencies missing due to incorrect python:Depends expansion

[Joel Rosdahl]

Thanks! I'm fine either way - you can upload it if you like.

-- Joel


On 6 August 2013 00:34, Scott Kitterman deb...@kitterman.com wrote:

 Package: python-apsw
 Version: 3.7.17-r1-1
 Severity: serious
 Tags: patch
 Justification: Policy 3.5

 Both python-apsw and python3-apsw are missing depends on the correct python
 interpreter.  The attached patch resolves the issue.  I can either upload
 this
 as an NMU or you can, please let me know if you intend to upload.

Bug#706992: python-apsw: Please provide Python 3 package

[Joel Rosdahl]

Thanks, I'll apply the patch and upload soon.

-- Joel


On 15 June 2013 23:13, Nikolaus Rath nikol...@rath.org wrote:

 On 06/15/2013 01:52 PM, Nikolaus Rath wrote:
  I've attached a debdiff for building Python 3 packages. It also fixes
  bug #710049. Please let me know if that's acceptable, or if you would
  like me to make any changes.

 Note that the patch includes a small change in packaging style: all
 files are now installed in debian/tmp, and dh_install is used to
 populate the debian/python[3]-apsw/ directories.

 That way we do not need 4 separate install targets, and as an added
 bonus the -dbg packages now contain not just the extension built for the
 Python debug interpreter, but also the debug symbols for the extension
 build with the regular Python interpreter.


 Best,

-Nikolaus

 --
  »Time flies like an arrow, fruit flies like a Banana.«

   PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

Bug#624589: clang support

[Joel Rosdahl]

RESOLVED/FIXED in the upstream ccache case means a fix has been committed
to some branch, and Target Milestone says which version the fix will be
in. When the version has been releated, the bug is set to CLOSED/FIXED.

-- Joel


On 9 May 2013 22:52, Ben Longbons brlongb...@gmail.com wrote:

 That upstream bug is now marked as fixed, though it's not entirely
 clear in what release.

 Note that the clang packaging may transition in future to have
 versioned names like clang++-3.2. There's also clang++-libc++ if you
 install libc++-dev from experimental (g++-libc++ is not really
 usable).

Bug#672570: ccache: Does not handle nonwriteable/not-a-directory HOME gracefully, breaks autogen

[Joel Rosdahl]

Hi,

On 12 May 2012 09:22, Andreas Metzler ametz...@downhill.at.eu.org wrote:
 it is not possible to build GNU autogen with ccache installed and in
 PATH. Afaict this caused by autogen setting HOME=/dev/null.
 [...]
 ccache should be able to handle this more gracefully and not try to write
to
 nonwriteable/not-a-directory HOME.

This was actually brought this up on the ccache mailing list recently:
http://www.mail-archive.com/ccache@lists.samba.org/msg00754.html. I still
think that not failing silently is a good thing in general, but having a
special exception for HOME=/dev/null could perhaps be a good idea. On the
other hand, if ccache disables itself when HOME=/dev/null (and when
CCACHE_DIR isn't set explicitly), you won't get the chance to know that you
need to set CCACHE_DIR to use ccache when compiling autogen...

 The fact that it tries to to so even with CCACHE_DISABLE=true is
 broken, isn't it?

Yes, that's a bug. It will be fixed in ccache 3.2.

-- Joel

Bug#465324: Random preprocessor errors

[Joel Rosdahl]

On 10 May 2012 12:54, ka...@karme.de wrote:
 I still can reproduce it using ccache 3.1.7-1 and gcc 4.4.7-1

Thanks!

The root cause is a bug in preprocessor. Since ccache by default runs the
preprocessor and then compiles its output, the error shows up when using
ccache.

Here's a reduced test case:

% cat bug465324.c
#define m(x) int x;
m(
#line 1 f
x)
#line 2 f
% gcc-4.4 -E bug465324.c -o bug465324.i
% cat bug465324.i
# 1 bug465324.c
# 1 built-in
# 1 command-line
# 1 bug465324.c


# 1 f
int x;# 2 f
% gcc-4.4 bug465324.i
f:1: error: stray ‘#’ in program
f:1: error: expected identifier or ‘(’ before numeric constant
% gcc-4.6 -E bug465324.c -o bug465324.i
% cat bug465324.i
# 1 bug465324.c
# 1 built-in
# 1 command-line
# 1 bug465324.c


# 1 f
# 2 bug465324.c
 int x;
# 2 f
% gcc-4.6 -c bug465324.i  echo works
works


It seems to work for me with GCC =4.5 and fails with GCC 4.5. A
workaround is to set CCACHE_CPP2=1 since that avoids compiling the
preprocessed output (but also makes cache misses slower).

Note that this only covers the stray ‘#’ in program error. The original
bug report mentions stray ‘\177’ in program, which sounds like another
problem.

-- Joel

Bug#671929: ccache: trigger not multi-arch safe, prevents proper gcc upgrade

[Joel Rosdahl]

Hi,

I don't see anything in the triggered ccache postinst script that could
cause this.

Can you reproduce the problem? Could it be that something other than
ccache's trigger that causes this? See for instance bug#665727.

-- Joel

On 8 May 2012 11:10, Yann Dirson ydir...@free.fr wrote:

 Package: ccache
 Version: 3.1.7-1
 Severity: grave

 Cannot configure the new gcc-4.7-base:

 |Preparing to replace gcc-4.7-base:amd64 4.7.0-3 (using
 .../gcc-4.7-base_4.7.0-7_amd64.deb) ...
 |De-configuring gcc-4.7-base:armel ...
 |Unpacking replacement gcc-4.7-base:amd64 ...
 |Processing triggers for ccache ...
 |Updating symlinks in /usr/lib/ccache ...
 |dpkg: error: --configure needs a valid package name but 'gcc-4.7-base' is
 not: ambiguous package name 'gcc-4.7-base' with more than one installed
 instance

 I have:

 |# dpkg -l 'gcc-4.7-base'
 |iU  gcc-4.7-base:amd64  4.7.0-7
 |iF  gcc-4.7-base:armel  4.7.0-3

 -- System Information:
 Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101,
 'experimental')
 Architecture: amd64 (x86_64)

 Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
 Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/bash

 Versions of packages ccache depends on:
 ii  libc6   2.13-32
 ii  zlib1g  1:1.2.6.dfsg-2

 ccache recommends no packages.

 Versions of packages ccache suggests:
 pn  distcc  none

 -- no debconf information

Bug#639223: ccache: Please install symlinks in /usr/bin as alternatives

[Joel Rosdahl]

On 2011-08-25 07:41, Reuben Thomas wrote:
 For the majority of users of ccache, it would be nice if installing it
 simply installed alternatives symlinks for gcc, so that no user
 configuration is necessary.

While I can understand the wish for this, my opinion is that enabling
ccache by default is not a good idea. It should be up to the user to
make an informed choice to enable ccache, so that the user has the
responsibility of setting it up correctly and learning about potential
pitfalls. ccache has too many known and unknown ways of altering the
build result in edge cases to be enabled by default.

-- Joel



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#639223: ccache: Please install symlinks in /usr/bin as alternatives

[Joel Rosdahl]

On 2011-12-18 11:44, Reuben Thomas wrote:
 I agree with all of the above, but why not s/enable/install/?

I think that it's not uncommon to want to use ccache only explicitly,
but that's mostly speculation. Another example of where it could be bad
is that if the ccache package gets installed on a multi-user server
where home directories are on (slow) NFS, then each user has to either
disable ccache or explicitly set CCACHE_DIR to be on a non-NFS location
since ccache on NFS is not very performant.

I realize that the above reasoning is not entirely rational, but as the
ccache upstream maintainer, I'm actually a bit nervous about the
intrusiveness of enabling ccache by default, perhaps since I know that
it's not without flaws. If ccache had more conservative defaults, then I
would feel better about it.

 The same applies to many tools the user can install: they change the
 system works in subtle ways (e.g. a firewall), and Debian switches
 them on by default when installed. If the user doesn't want that
 behaviour, normally the solution is not to install the package. [...]

If a user installs a firewall package, she is probably aware of that a
firewall actually is meant to change the system behavior, while the goal
of ccache is to not change the system at all from a functional point of
view.

 With ccache, that could perhaps be achieved by having it provide an
 /etc/alternative for gcc which has higher priority than gcc; a user
 who wants normal gcc to take precedence can simply set alternatives
 manually.

I personally don't think easy and /etc/alternatives belong in the
same sentence. :-) I think that prepending /usr/lib/ccache to PATH, or
removing it, is much easier to do or understand.

If we would want a way of enabling ccache by default, I suggest that it
should be done in a separate package, say ccache-global-enable.

 For what it's worth, my own experience was read about ccache, install
 it, configure it, use it. I have never found a pitfall, and I have
 not learned about any pitfalls. I would quite happily avoid the
 configure it step, since it didn't teach me anything, it merely
 wasted my time (and in fact I had to do it more than once). I do not
 doubt there are pitfalls; I merely observe that ccache's default
 install did not teach me anything about them.

Yes, documentation could indeed be improved.

-- Joel



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#652582: override: python-pysqlite1.1:python/extra

[Joel Rosdahl]

Package: ftp.debian.org
Severity: normal

python-pysqlite1.1_1.1.8a-5_amd64.deb: package says priority is extra,
override says optional.

As per bug #641322, python-pysqlite1.1 should have priority extra
because it conflicts with the optional package python-sqlite.

-- Joel



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#639223: ccache: Please install symlinks in /usr/bin as alternatives

[Joel Rosdahl]

On 2011-12-18 17:27, Reuben Thomas wrote:
 Here's another suggestion: how about having a dpkg configuration item?
 This way, the user gets to choose at install time whether to enable
 it, and has an easy way to switch it on/off via dpkg-reconfigure.

That sounds OK to me.

-- Joel



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#632779: cc and c++ symlinks aren't updated when installing gcc or g++ before ccache

[Joel Rosdahl]

On 2011-07-06 00:23, José Manuel Santamaría Lema wrote:
 [...]
 So ... if the gcc maintainers accept the gcc-defaults patch, would you
 accept the ccache one? If yes, I would open a new bug report against
 src:gcc-defaults with the patch and mark this one as blocked. A reply just
 saying go ahead is enough, thanks for your time.

Sure, sounds fine to me.

-- Joel



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#630352: ccache: inoperative with multiarchized compilers

[Joel Rosdahl]

On 2011-06-14 13:06, Adam Borowski wrote:
 For an actual break, you'd need a more complex setup with extra layers like
 colorgcc or distcc, and in that case it might be argued to be an user
 configuration error (except that there's no proper configuration in such
 cases other than creating the symlink yourself).

Please explain further what the actual problem is. In what situation
does it break? In what way does it break?

 But even when ccache is used by itself, it will merely not work.

Sorry, I don't understand. Why not?

 Or is the problem that ccache doesn't correctly create symlinks in
 /usr/lib/ccache anymore so that some compilers will not be invoked via
 ccache (if the user has /usr/lib/ccache the path)?

 Yeah.

OK. But I'm still not sure if this is the only problem you see (I
wouldn't call that break compilation, which perhaps is why I'm
confused) or if it actually breaks compilation (as in gives a bad
result when invoked).

 If you want to ever use distcc when the server might be on a
 different architecture, you need to invoke $(gcc -dumpmachine)-gcc.
 The current version of ccache will handle plain gcc but not one with
 explicitely specified architecture.

I don't see why. Please explain.

 What package should I install and
 what should I do to reproduce the problem?
 
 ccache and recent gcc.
 Try to run x86_64-linux-gnu-gcc - no ccache.

I can't reproduce this using Debian unstable freshly updated today with
gcc 4:4.6.0-5, gcc-4.6 4.6.0-11 and ccache 3.1.5-1.

# x86_64-linux-gnu-gcc --version | head -1
x86_64-linux-gnu-gcc (Debian 4.6.0-11) 4.6.1 20110604 (prerelease)
# ls -l /usr/lib/gcc
total 8
drwxr-xr-x 3 root root 4096 Aug  4  2010 i586-mingw32msvc
drwxr-xr-x 4 root root 4096 Jun 13 21:51 x86_64-linux-gnu
# ls -l /usr/lib/gcc/x86_64-linux-gnu
total 8
drwxr-xr-x 3 root root 4096 May 16  2010 4.1
lrwxrwxrwx 1 root root3 May 16  2010 4.1.3 - 4.1
drwxr-xr-x 4 root root 4096 Jun  5 21:12 4.6
lrwxrwxrwx 1 root root3 Apr 22 05:27 4.6.1 - 4.6
# ccache -s | grep miss
cache miss  4577
# touch foo.c
# x86_64-linux-gnu-gcc -c foo.c
# ccache -s | grep miss
cache miss  4578

So, no problem there.

I see now that when I install gcc-4.4 and gcc-4.5, they don't create
directories in /usr/lib/gcc/$(gcc -dumpmachine) anymore, so symlinks
like /usr/lib/ccache/gcc-4.5 aren't created. But for me, gcc-4.6 works
since it creates a /usr/lib/gcc/x86_64-linux-gnu/4.6 directory just like
update-ccache-symlinks expects.

-- Joel



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#630352: ccache: inoperative with multiarchized compilers

[Joel Rosdahl]

On 2011-06-13 12:02, Adam Borowski wrote:
 I'm afraid that ccache will break compilation of anything that specifies the
 full name of the compiler (x86_64-linux-gnu-gcc rather than gcc).  It
 does still work with non-multiarch ones.

Thanks for the bug report! I'm afraid I don't understand it, though. Can
you please describe in more detail what doesn't work anymore?

Does ccache actually break compilation? If so, in what way? Or is the
problem that ccache doesn't correctly create symlinks in /usr/lib/ccache
anymore so that some compilers will not be invoked via ccache (if the
user has /usr/lib/ccache the path)? What package should I install and
what should I do to reproduce the problem?

Thanks,
Joel



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#624589: clang support

[Joel Rosdahl]

On 2011-04-29 23:33, Peter Eisentraut wrote:
 Please add integration for the clang compiler suite.  You'd just need to add
 
 /usr/bin/clang
 /usr/bin/clang++
 /usr/bin/llvm-clang
 
 into update-ccache-symlinks and add some dpkg triggers.

I don't think that this should be done until ccache has acceptable
support for clang. See
https://bugzilla.samba.org/show_bug.cgi?id=8118.

-- Joel



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#349315: Please list gcc-snapshot

[Joel Rosdahl]

I think we should close this bug. Any objections?

-- Joel



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#465324: Random preprocessor errors

[Joel Rosdahl]

Has anyone been able to reproduce this problem lately? I've never seen it.

-- Joel



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#349315: Too intrusive

[Joel Rosdahl]

I don't think this is a good idea -- it's too intrusive. Another much
simpler way of accomplishing it is this:

export CCACHE_PATH=/usr/lib/gcc-snapshot/bin

This of course requires some action by the user, but I think that's a
good thing in this case.

-- Joel



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#580944: Please update to 3.0 from upstream

[Joel Rosdahl]

Hi,

I've just released version 3.0 of ccache. See
http://ccache.samba.org/news-3.0.html for a list of changes.

Since I'm also a Debian developer, I'm glad to help with the Debian
package if wanted.

-- Joel



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#565868: python-apsw: too strong dependency on libjs-jquery

[Joel Rosdahl]

On Mon, 18 Jan 2010 23:53:59 -0600
Raphael Geissert geiss...@debian.org wrote:

 While it is reasonable for python-apsw to depend on libjs-jquery,
 making it a strong dependency is overly exaggerating it.
 Only the rare users who happen to use the search functionality of the
 already few users who happen to read the shipped documentation need
 jquery.

I agree. But on the other hand, I don't think we should ship a broken
package, even if it's broken just for a few people, so I think I'll
instead make a python-apsw-doc package depending on libjs-jquery.
Sounds fair?

-- 
Regards,
Joel



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#564791: --git-export doesn't work when specified version's upstream version != HEAD's upstream version

[Joel Rosdahl]

Package: git-buildpackage
Version: 0.4.63
Tags: patch

git-buildpackage fails when --git-export specifies a version whose
upstream version is not the same as HEAD's upstream version. Transcript:

# head -1 debian/changelog 
python-pysqlite2 (2.5.5-3) unstable; urgency=low
# git-buildpackage --git-pristine-tar --git-export-dir=../build 
--git-export=debian/2.4.1-1
dh_testdir
dh_testroot
rm -f build*stamp dbg-build*stamp
rm -rf build
find . -name '*.pyc' | xargs rm -f
dh_clean
pristine-tar: successfully generated 
/root/git/build/python-pysqlite2_2.5.5.orig.tar.gz
Exporting 'debian/2.4.1-1' to '/root/git/build/python-pysqlite2-tmp'
This package has a Debian revision number but there does not seem to be
an appropriate original tar file or .orig directory in the parent directory;
(expected one of python-pysqlite2_2.4.1.orig.tar.gz, 
python-pysqlite2_2.4.1.orig.tar.bz2,
python-pysqlite2_2.4.1.orig.tar.lzma or python-pysqlite2-2.5.5.orig)
continue anyway? (y/n) 

As can be seen above, git-buildpackage creates the original tar file
from HEAD's upstream version, which of course leads to failure.

Attached is a patch that fixes the problem for me. It's not heavily
tested, but works for me and my use cases. I have not tried the overlay
feature or other exotic option combinations.

Regards,
Joel
--- /usr/bin/git-buildpackage.orig	2010-01-11 22:26:54.0 +0100
+++ /usr/bin/git-buildpackage	2010-01-11 23:00:03.0 +0100
@@ -278,21 +278,6 @@
 print sys.stderr, You are not on branch '%s' but on '%s' % (options.debian_branch, branch)
 raise GbpError, Use --git-ignore-new to ignore or --git-debian-branch to set the branch name.
 
-try:
-cp = du.parse_changelog(changelog)
-version = cp['Version']
-version_no_epoch = cp['NoEpoch-Version']
-if du.is_native(cp):
-major = cp['Debian-Version']
-else:
-major = cp['Upstream-Version']
-except du.NoChangelogError:
-raise GbpError, '%s' does not exist, not a debian package % changelog
-except du.ParseChangeLogError, err:
-raise GbpError, Error parsing Changelog: %s % err
-except KeyError:
-raise GbpError, Can't parse version from changelog
-
 if not options.tag_only:
 output_dir = prepare_output_dir(options.export_dir)
 if options.tarball_dir:
@@ -300,21 +285,13 @@
 else:
 tarball_dir = output_dir
 
-# Get/build the orig.tar.gz if necessary:
-if not du.is_native(cp):
-orig_file = du.orig_file(cp, options.comp_type)
-
-# look in tarball_dir first, if found force a symlink to it
-if options.tarball_dir:
-print Looking for orig tarball '%s' at '%s' % (orig_file, tarball_dir)
-if not du.symlink_orig(cp, options.comp_type, tarball_dir, output_dir, force=True):
-print Orig tarball '%s' not found at '%s' % (orig_file, tarball_dir)
-else:
-print Orig tarball '%s' found at '%s' % (orig_file, tarball_dir)
-# build an orig unless the user forbidds it
-if not options.no_create_orig and not du.has_orig(cp, options.comp_type, output_dir):
-if not pristine_tar_build_orig(repo, cp, output_dir, options):
-git_archive_build_orig(repo, cp, output_dir, options)
+# Parse changelog just to get source package name.
+try:
+cp = du.parse_changelog(changelog)
+except du.NoChangelogError:
+raise GbpError, '%s' does not exist, not a debian package % changelog
+except du.ParseChangeLogError, err:
+raise GbpError, Error parsing Changelog: %s % err
 
 # Export to another build dir if requested:
 if options.export_dir:
@@ -337,16 +314,49 @@
 
 print Exporting '%s' to '%s' % (options.export, tmp_dir)
 dump_tree(tmp_dir, tree)
-cp = du.parse_changelog(os.path.join(tmp_dir, 'debian', 'changelog'))
+changelog = os.path.join(tmp_dir, changelog)
+
+# Now parse the correct changelog to get hold of the version.
+try:
+cp = du.parse_changelog(changelog)
+version = cp['Version']
+version_no_epoch = cp['NoEpoch-Version']
+except du.NoChangelogError:
+raise GbpError, '%s' does not exist, not a debian package % changelog
+except du.ParseChangeLogError, err:
+raise GbpError, Error parsing Changelog: %s % err
+except KeyError:
+raise GbpError, Can't parse version from changelog
+
+# Continue exporting if 

Bug#547826: Not fixed, FTBFS when building with Python2.6 present

[Joel Rosdahl]

On Wed, 21 Oct 2009 18:50:34 +0200
Roderich Schupp roderich.sch...@googlemail.com wrote:

 debian/movefiles.sh still references names with hard-coded site-packages, 
 e.g.

Crap. OK, uploaded 3.1.2-5 now. Thanks!

-- 
Regards,
Joel Rosdahl j...@debian.org
Key BB845E97 (9F4B D780 6EF4 5700 778D  8B22 0064 F9FF BB84 5E97)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#547826: Not fixed, FTBFS when building with Python2.6 present

[Joel Rosdahl]

On Mon, 19 Oct 2009 17:53:23 +0200
Roderich Schupp roderich.sch...@googlemail.com wrote:

 The debian/*.install files still refer to usr/lib/python*/site-packages. 
 FTBFS:
 
 ...
 /usr/bin/python2.6 -O /tmp/tmpPBZ_Fk.py
 removing /tmp/tmpPBZ_Fk.py
 running install_data
 running install_egg_info
 Writing 
 debian/python2.6-tmp/usr/lib/python2.6/dist-packages/egenix_mx_base-3.1.2.egg-info
 d=$(echo build/temp.*-2.6_ucs4); mv $d ${d}_normal
 find debian/python2.6-tmp -name '*_d.so' | xargs rm -f
 dh_install -ppython-egenix-mxbeebase \
-ppython-egenix-mxdatetime \
-ppython-egenix-mxproxy \
-ppython-egenix-mxqueue \
-ppython-egenix-mxstack \
-ppython-egenix-mxtexttools \
-ppython-egenix-mxtools \
-ppython-egenix-mxuid \
-ppython-egenix-mxurl \
--sourcedir=debian/python2.6-tmp
 dh_install: python-egenix-mxbeebase missing files
 (usr/lib/python*/site-packages/mx/BeeBase), aborting
 make: *** [install-ext-python2.6] Error 1
 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 
 2

Thanks! Could you please try version 3.1.2-4?

-- 
Joel Rosdahl j...@debian.org




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#508683: python-pysqlite2: .txt Documentation has include statements rather than real code snippet.

[Joel Rosdahl]

Hi,

I agree that the text version isn't very useful in its current form.
There doesn't seem to be a way of automatically expanding the
code-block directives other than what's already done in the HTML
version of the usage guide. The best option is probably to include
only the HTML version in the package.

On the other hand: The documentation is in an another (HTML only)
format in python-pysqlite2 2.5.0-1 and later.

-- 
Regards,
Joel Rosdahl j...@debian.org
Key BB845E97; fingerprint 9F4B D780 6EF4 5700 778D  8B22 0064 F9FF BB84 5E97



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#508683: python-pysqlite2: .txt Documentation has include statements rather than real code snippet.

[Joel Rosdahl]

Junichi Uekawa dan...@netfort.gr.jp writes:

 Joel Rosdahl wrote:
 
 I agree that the text version isn't very useful in its current
 form. There doesn't seem to be a way of automatically expanding the
 code-block directives other than what's already done in the HTML
 version of the usage guide. The best option is probably to include
 only the HTML version in the package.

 Is this going to stay like this for lenny release ?

I guess so, since it's not a very serious bug.

 On the other hand: The documentation is in an another (HTML only)
 format in python-pysqlite2 2.5.0-1 and later.

 Is there a text version? I don't want to have to work with a web
 browser.

No, just HTML. Sorry. (Just like Python's documentation, by the way.)

-- 
Regards,
Joel Rosdahl j...@debian.org
Key BB845E97; fingerprint 9F4B D780 6EF4 5700 778D  8B22 0064 F9FF BB84 5E97



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#500425: python-pysqlite2: depends on libjs-jquery

[Joel Rosdahl]

Hi,

Nicolas Évrard [EMAIL PROTECTED] writes:

 I notice that when I wanted to upgrade python-pysqlite2, aptitude
 insisted to install libjs-jquery, AFAIK this is just in order to be
 able to see the documentation.

 Wouldn't it be better to create a -doc package depending on jquery
 and let people who do not need jquery/documentation install the
 binary package ?
 [...]

Yes, that seems reasonable. Will fix shortly.

-- 
Regards,
Joel Rosdahl [EMAIL PROTECTED]
Key BB845E97; fingerprint 9F4B D780 6EF4 5700 778D  8B22 0064 F9FF BB84 5E97



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#469644: python-pysqlite2: unicode bug while processing non-unicode text

[Joel Rosdahl]

Hi Benjamin,

Thanks for your bug report and sorry for the delay.

Benjamin Schweizer [EMAIL PROTECTED] writes:

 pysqlite-2.3.2 accepts binary data on insertss but selects return
 unicode strings. This results in unicode conversion bugs when
 non-unicode bytes are stored in the database.

 As sqlite3 accepts binary data in text fields, this seems to be a
 bug in pysqlite. To fix it, one could i) either restrict inserts to
 unicode strings or ii) change the result from unicode to binary.

 However, the first would break compatibility with sqlite and that
 latter would break compatibility with existing code. Thus, this
 should be discussed with the authors.

I agree with you. I have created a ticket about this:

http://oss.itsystementwicklung.de/trac/pysqlite/ticket/229

-- 
Regards,
Joel Rosdahl [EMAIL PROTECTED]
Key BB845E97; fingerprint 9F4B D780 6EF4 5700 778D  8B22 0064 F9FF BB84 5E97



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#456500: python-apsw

[Joel Rosdahl]

Hello Vitaliyi,

Vitaliyi [EMAIL PROTECTED] writes:

 Package: python-apsw
 Version: 3.3.13-r1-3

 It raising the fillowing a bit vague tracebacks:

 Traceback (most recent call last):
 ...
 cur.execute(INSERT INTO fs (path, ls) VALUES (?, ?), (toUnicode(path), 
 dum
 ps(ls)))
   File apsw.c, line 3518, in resetcursor
 ConstraintError: ConstraintError: not an error

Thanks for your bug report.

Do you have any runnable example of code that I can use to reproduce
this error?

Regards,
Joel

-- 
Joel Rosdahl [EMAIL PROTECTED]
Key BB845E97; fingerprint 9F4B D780 6EF4 5700 778D  8B22 0064 F9FF BB84 5E97



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#454424: other arch

[Joel Rosdahl]

Thomas Guebels [EMAIL PROTECTED] writes:

 Can you please upload the fix for other architectures than amd64 as
 well ? Thanks.

That's the job of the auto-builders. They should upload binary
packages for the other architectures soon.

Regards,
Joel

-- 
Joel Rosdahl [EMAIL PROTECTED]
Key BB845E97; fingerprint 9F4B D780 6EF4 5700 778D  8B22 0064 F9FF BB84 5E97



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#436003: preinst fails when /proc/mounts doesn't exist

[Joel Rosdahl]

Package: mount
Version: 2.13~rc2-5
Severity: normal

mount's preinst fails in a chrooted Debian where /proc isn't mounted:

(Reading database ... 27038 files and directories currently installed.)
Preparing to replace mount 2.12r-19 (using .../mount_2.13~rc2-5_amd64.deb) ...
sed: can't read /proc/mounts: No such file or directory
dpkg: error processing /var/cache/apt/archives/mount_2.13~rc2-5_amd64.deb 
(--unpack):
 subprocess pre-installation script returned error exit status 2
Errors were encountered while processing:
 /var/cache/apt/archives/mount_2.13~rc2-5_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

-- 
Joel Rosdahl [EMAIL PROTECTED]
Key BB845E97; fingerprint 9F4B D780 6EF4 5700 778D  8B22 0064 F9FF BB84 5E97


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#430557: mx.DateTime.Date constructor regression (Debuan bug #430557)

[Joel Rosdahl]

Hello,

(If this is not the correct address to send bug reports to, please
tell me.)

Enclosed is a bug report sent by a Debian user.

Regards,
Joel (Debian maintainer of the egenix base packages)

---BeginMessage---
Package: python-egenix-mxdatetime
Version: 3.0.0-1
Severity: normal


It used to be

 from mx.DateTime import Date
 d = Date(2007,1,-1)
 print d.year, d.month, d.day
2007 1 31

and now is 

 from mx.DateTime import Date
 d = Date(2007,1,-1)
 print d.year, d.month, d.day
2007 1 -1

which is problematic and the opposite of what the documentation says
(downloaded pdf from egenix website for version 3.0 of mx.datetime).

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.18-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) (ignored: LC_ALL set to 
fr_FR)
Shell: /bin/sh linked to /bin/bash

Versions of packages python-egenix-mxdatetime depends on:
ii  libc6 2.5-7  GNU C Library: Shared libraries
ii  python2.4.4-6An interactive high-level object-o
ii  python-central0.5.14 register and build utility for Pyt
ii  python-egenix-mxtools 3.0.0-1collection of additional builtins 
ii  python2.4 2.4.4-4An interactive high-level object-o
ii  python2.5 2.5.1-1An interactive high-level object-o

python-egenix-mxdatetime recommends no packages.

-- no debconf information

---End Message---


-- 
Joel Rosdahl [EMAIL PROTECTED]
Key BB845E97; fingerprint 9F4B D780 6EF4 5700 778D  8B22 0064 F9FF BB84 5E97

Bug#429512: RFP: python2.5-pysqlite2 -- python interface to SQLite 3

[Joel Rosdahl]

Michael Mende [EMAIL PROTECTED] writes:

 Shouldn't python2.5-pysqlite2 provided by python-pysqlite2? - See
 http://wiki.debian.org/DebianPython/NewPolicy

Yes. python-pysqlite2 2.3.4-1, which I uploaded yesterday, will
provide Python 2.5 modules too.

-- 
Regards,
Joel Rosdahl [EMAIL PROTECTED]
Key BB845E97; fingerprint 9F4B D780 6EF4 5700 778D  8B22 0064 F9FF BB84 5E97


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#427338: Type affinity broken

[Joel Rosdahl]

Florian Weimer [EMAIL PROTECTED] writes:

 As the program below shows, ASCII values of type string which are
 written into the database are converted to Unicode strings when
 reading them back.
 [...]

I assume you're referring to this paragraph in the documentation:

When reading values from SQLite, ASPW uses the Python string
class for any pure ASCII text, else it uses the Python unicode
class.

I think it's just documentation bug since it's clearly stated both
near the top and in the version history that all strings now are
returned as Unicode.

I've filed a bug in APSW's bug tracker. See
http://initd.org/tracker/pysqlite/ticket/199.

-- 
Regards,
Joel Rosdahl [EMAIL PROTECTED]
Key BB845E97; fingerprint 9F4B D780 6EF4 5700 778D  8B22 0064 F9FF BB84 5E97


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#406363: python-egenix-mxdatetime: import using python2.5 fails

[Joel Rosdahl]

Hi Ryan,

Ryan Nowakowski [EMAIL PROTECTED] writes:

 [...]
 import works fine in python2.4 but fails in python2.5
 [...]

python-egenix-mxdatetime hasn't got support for Python 2.5 since
2.5 isn't flagged as a supported version in unstable yet. (See
/usr/share/python/debian_defaults.) When support has been added, I (or
someone else) can rebuild the python-egenix-mxdatetime package to get
2.5 support.

-- 
Regards,
Joel Rosdahl [EMAIL PROTECTED]
Key BB845E97; fingerprint 9F4B D780 6EF4 5700 778D  8B22 0064 F9FF BB84 5E97


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#373829: Please add BLOB support

[Joel Rosdahl]

Hello Florian,

Joel Rosdahl [EMAIL PROTECTED] writes:

 Florian Weimer [EMAIL PROTECTED] writes:

 Package: python2.3-apsw
 Version: 3.3.5r1-1
 Severity: wishlist

 Currently, it is not possible to store arbitrary 8-bit data in the
 database, even though this is supported by SQLite3. [...]
 
 APSW uses the buffer class to store store binary data (see
 http://www.rogerbinns.com/apsw.html#Types).
 [...]

Are you happy with this answer? If so, I will close the bug report.

Regards,
Joel

-- 
Joel Rosdahl [EMAIL PROTECTED]
Key BB845E97; fingerprint 9F4B D780 6EF4 5700 778D  8B22 0064 F9FF BB84 5E97


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#373829: Please add BLOB support

[Joel Rosdahl]

Florian Weimer [EMAIL PROTECTED] writes:

 Package: python2.3-apsw
 Version: 3.3.5r1-1
 Severity: wishlist

 Currently, it is not possible to store arbitrary 8-bit data in the
 database, even though this is supported by SQLite3.  For example, the
 following script should print [('\377',), ('\000A',)]

 import apsw

 db = apsw.Connection(:memory:)
 c = db.cursor()
 c.execute(CREATE TABLE test (a BLOB))
 c.execute(INSERT INTO test VALUES (?), (\377,))
 c.execute(INSERT INTO test VALUES (?), (\000A,))
 print list(c.execute(SELECT * FROM test))

APSW uses the buffer class to store store binary data (see
http://www.rogerbinns.com/apsw.html#Types).

Try this:

import apsw

db = apsw.Connection(:memory:)
c = db.cursor()
c.execute(CREATE TABLE test (a BLOB))
c.execute(INSERT INTO test VALUES (?), (buffer(\377),))
c.execute(INSERT INTO test VALUES (?), (buffer(\000A),))
print list(c.execute(SELECT * FROM test))

Regards,
Joel

-- 
Joel Rosdahl [EMAIL PROTECTED]
Key BB845E97; fingerprint 9F4B D780 6EF4 5700 778D  8B22 0064 F9FF BB84 5E97


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#372656: python-irclib 0.4.6 available

[Joel Rosdahl]

Package: python-irclib
Version: 0.4.4-1
Severity: wishlist

python-irclib 0.4.6 is available. Please consider packaging it.

Regards,
Joel

-- 
Joel Rosdahl [EMAIL PROTECTED]
Key BB845E97; fingerprint 9F4B D780 6EF4 5700 778D  8B22 0064 F9FF BB84 5E97


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#365222: python-apsw: please package new upstream release (3.3.5)

[Joel Rosdahl]

Hello,

Aaron M. Ucko [EMAIL PROTECTED] writes:

 As you may already have heard, APSW's developer recently issued a
 new upstream release (version 3.3.5). As stated at
 http://permalink.gmane.org/gmane.comp.mobile.bitpim.devel/3876 ,
 BitPim (which I maintain in Debian) will soon require this release,
 so I'd greatly appreciate it if you could find the time to get it
 into Debian within the next week or so.

Yes, I'm aware of the new release, but thanks for reminding me anyway!
I'm quite busy at the moment, but I'll try to package it in the
beginning of next week.

Regards,
Joel

-- 
Joel Rosdahl [EMAIL PROTECTED]
Key BB845E97; fingerprint 9F4B D780 6EF4 5700 778D  8B22 0064 F9FF BB84 5E97


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#361507: python2.4-pysqlite1.1: hangs on execute()

[Joel Rosdahl]

M. Dietrich [EMAIL PROTECTED] writes:

 [...]
 this may be related to Bug#361254, 361066 and 361097. if using the
 following program:

 import sqlite
 con = sqlite.connect('data.db')
 res = con.cursor().execute('SELECT * FROM data')

 the program hangs in execute() with high system load. this does
 happen with libsqlite3-0_3.3.5-0.1 but not with
 libsqlite3-0_3.2.8-1.

Thanks for the report.

I just uploaded python-pysqlite1.1_1.1.7-1. Please let me know whether
the new version fixes the problem.

Regards,
Joel

-- 
Joel Rosdahl [EMAIL PROTECTED]
Key BB845E97; fingerprint 9F4B D780 6EF4 5700 778D  8B22 0064 F9FF BB84 5E97


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#361097: python-pysqlite2 and new sqlite3 packages

[Joel Rosdahl]

Hello Laszlo,

Laszlo Boszormenyi [EMAIL PROTECTED] writes:

 I have NMUed SQLite3 for it's fixes (there was one grave in BTS
 even). But it is version 3.3.5 ATM, which needs the newest
 python-pysqlite2 release from the 2.0.x branch as the changelog
 says: [version 2.0.7] Fixed an API misuse that made pysqlite 2.0.x
 unusable with SQLite versions 3.3.3 or later. So please package and
 upload it due to #361097 .

Okay. I will upload python-pysqlite2_2.2.0-1 shortly.

Regards,
Joel

-- 
Joel Rosdahl [EMAIL PROTECTED]
Key BB845E97; fingerprint 9F4B D780 6EF4 5700 778D  8B22 0064 F9FF BB84 5E97


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#341092: python2.3-sqlite: Python2.3 package uses decorators

[Joel Rosdahl]

Hi Kevin,

Joel Rosdahl [EMAIL PROTECTED] writes:

 [...]
 Thanks for the bug report! However, I think you are mistaken. The
 only thing python2.3-sqlite does in its postinstall script is to run
 /usr/lib/python2.3/compileall.py on each directory found in
 /usr/lib/python2.3/site-packages. It also does not use or install
 any Python egg or formencode module.

 The only conclusion I can draw is that the egg comes from some other
 package or module that you have installed by other means.

Do you agree with my conclusion? Can I close the bug?

Regards,
Joel

-- 
Joel Rosdahl [EMAIL PROTECTED]
Key BB845E97; fingerprint 9F4B D780 6EF4 5700 778D  8B22 0064 F9FF BB84 5E97


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#341092: python2.3-sqlite: Python2.3 package uses decorators

[Joel Rosdahl]

Hi Kevin,

Kevin Campbell [EMAIL PROTECTED] writes:

 The 2.3 package for python-sqlite downloads an egg for formencode
 which uses decorators. These are not supported in python2.3 and as
 such the package will not install.

 Compiling
 /usr/lib/python2.3/site-packages/FormEncode-0.3-py2.3.egg/formencode/formgen.py
 ...
   File
 /usr/lib/python2.3/site-packages/FormEncode-0.3-py2.3.egg/formencode/formgen.py,
 line 8
 @dispatch.generic()
 ^
 SyntaxError: invalid syntax

 Compiling
 /usr/lib/python2.3/site-packages/FormEncode-0.3-py2.3.egg/formencode/sqlformgen.py
 ...
   File
 /usr/lib/python2.3/site-packages/FormEncode-0.3-py2.3.egg/formencode/sqlformgen.py,
 line 11
 @makeform.when('isinstance(obj, SQLObject) or (isinstance(obj, type)
 and issubclass(obj, SQLObject))')
 ^
 SyntaxError: invalid syntax
 [...]

Thanks for the bug report! However, I think you are mistaken. The only
thing python2.3-sqlite does in its postinstall script is to run
/usr/lib/python2.3/compileall.py on each directory found in
/usr/lib/python2.3/site-packages. It also does not use or install any
Python egg or formencode module.

The only conclusion I can draw is that the egg comes from some other
package or module that you have installed by other means.

Regards,
Joel

-- 
Joel Rosdahl [EMAIL PROTECTED]
Key BB845E97; fingerprint 9F4B D780 6EF4 5700 778D  8B22 0064 F9FF BB84 5E97


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#327128: ITP: python-pysqlite1.1 -- python interface to SQLite 3

[Joel Rosdahl]

Package: wnpp
Severity: wishlist
Owner: Joel Rosdahl [EMAIL PROTECTED]

By request (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=304067),
I intend to package pysqlite 1.1 so that SQLite 3 can be used while
using the old pysqlite API. The package will conflict with
python-sqlite (which is pysqlite 1.0, i.e. for SQLite 2) but not with
python-pysqlite2 (which uses another, non-conflicting API).

URL:

http://pysqlite.org

Binary package names:

python-pysqlite1.1
python2.3-pysqlite1.1
python2.4-pysqlite1.1

Short description:

python interface to SQLite 3

Description:

pysqlite is an interface to the SQLite database server for Python.
It aims to be fully compliant with Python database API version 2.0
while also exploiting the unique features of SQLite.

This version of pysqlite (1.1) is built against SQLite 3 but uses
the same API as pysqlite 1.0 (which is built against SQLite 2 and
packaged in python-sqlite). For a newer Python interface to SQLite
3, see the package python-pysqlite2.

License:

Copyright (c) 2001-2003
Michael Owens [EMAIL PROTECTED]
Gerhard Häring [EMAIL PROTECTED]

Permission to use, copy, modify, and distribute this software and
its documentation for any purpose and without fee is hereby
granted, provided that the above copyright notice appear in all
copies and that both that copyright notice and this permission
notice appear in supporting documentation.

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.

-- 
Joel Rosdahl [EMAIL PROTECTED]
Key BB845E97; fingerprint 9F4B D780 6EF4 5700 778D  8B22 0064 F9FF BB84 5E97

Bug#304067: Closing

[Joel Rosdahl]

Hi Filip!

Filip Van Raemdonck [EMAIL PROTECTED] writes:

 In the mean time it'd be nice if pysqlite 1.1 were still packaged, so
 people can: move to sqlite 3 (pysqlite 1.1 packages), then migrate to
 pysqlite 2.0 api later on.

OK, fair enough. Do you have a suggestion of an appropriate name for
the PySQLite 1.1 package?

Regards,
Joel

-- 
Joel Rosdahl [EMAIL PROTECTED]
Key BB845E97; fingerprint 9F4B D780 6EF4 5700 778D  8B22 0064 F9FF BB84 5E97


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#323619: typo in python-egenix-stack dependency

[Joel Rosdahl]

Hi!

 Package: python-egenix-stack
 Version: 2.0.6-1
 Severity: serious
 
 missing comma.

Hm, I fail to see where the comma is missing. Please elaborate.

 maybe you can drop the 2.1 and 2.2 packages?

Yes, I guess it's about time to do that.

Regards,
Joel

-- 
Joel Rosdahl [EMAIL PROTECTED]
Key BB845E97; fingerprint 9F4B D780 6EF4 5700 778D  8B22 0064 F9FF BB84 5E97


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#309371: ITP: python-pysqlite2 -- python interface to SQLite

[Joel Rosdahl]

Package: wnpp
Severity: wishlist

I intend to package PySQLite 2. It will happily coexist with the
current python-sqlite package, which has another API.

URL:

http://pysqlite.org

Description:

pysqlite a DB-API 2.0-compliant database interface for SQLite.

SQLite is a relational database management system contained in a
relatively small C library. It is a public domain project created
by D. Richard Hipp. Unlike the usual client-server paradigm, the
SQLite engine is not a standalone process with which the program
communicates, but is linked in and thus becomes an integral part
of the program. The library implements most of SQL-92 standard,
including transactions, triggers and most of complex queries.

pysqlite makes this powerful embedded SQL engine available to
Python programmers. It stays compatible with the Python database
API specification 2.0 as much as possible, but also exposes most
of SQLite's native API, so that it is for example possible to
create user-defined SQL functions and aggregates in Python.

If you need a relational database for your applications, or even
small tools or helper scripts, pysqlite is often a good fit. It's
easy to use, easy to deploy, and does not depend on any other
Python libraries or platform libraries, except SQLite. SQLite
itself is ported to most platforms you'd ever care about.

It's often a good alternative to MySQL, the Microsoft JET engine
or the MSDE, without having any of their license and deployment
issues.

License:

Copyright (c) 2004 Gerhard Häring

This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any
damages arising from the use of this software.

Permission is granted to anyone to use this software for any
purpose, including commercial applications, and to alter it and
redistribute it freely, subject to the following restrictions:

1. The origin of this software must not be misrepresented; you
   must not claim that you wrote the original software. If you
   use this software in a product, an acknowledgment in the
   product documentation would be appreciated but is not
   required.

2. Altered source versions must be plainly marked as such, and
   must not be misrepresented as being the original software.

3. This notice may not be removed or altered from any source
   distribution.

-- 
Joel Rosdahl [EMAIL PROTECTED]
Key BB845E97; fingerprint 9F4B D780 6EF4 5700 778D  8B22 0064 F9FF BB84 5E97

Bug#304067: python-sqlite: Please package pysqlite 1.1 (SQLite 3.x)

[Joel Rosdahl]

Hello Hugo,

Hugo Haas [EMAIL PROTECTED] writes:

 Would it be possible to have version 1.1.6 packaged in order to
 access SQLite 3.x databases?

Well, yes, but I would like to provide a clean upgrade path from older
SQLite 2.x-based python-sqlite packages.

I see the following solutions:

1. Just release a new python-sqlite package with PySQLite 1.1.x.
2. Keep python-sqlite as a PySQLite 2.x package and create a new
   package, say python-sqlite3, with PySQLite 1.1.x and let it
   conflict with python-sqlite. (It must conflict, since it uses the
   same API.)
3. Ignore PySQLite 1.1.x and wait for PySQLite 2.x. (PySQLite 2.x uses
   a different API than PySQLite 1.x and can therefore coexist with
   PySQLite 1.0.x.)

The problem with solution 1 is that all existing applications will
break unless the user does something like

mv foo.db foo.db.old
sqlite foo.db.old .dump | sqlite3 foo.db

for each database. That feels unacceptable to me, since the user can't
possibly be expected to know what should be done in all cases.

Solution 2 is maybe feasible, but it's kind of boring.

So far, my intention has been to go for solution 3. Opinions on this?
(Are there other solutions?)

You might also want consider using python-apsw, which now is part of
unstable.

Regards,
Joel


-- 
Joel Rosdahl [EMAIL PROTECTED]
Key BB845E97; fingerprint 9F4B D780 6EF4 5700 778D  8B22 0064 F9FF BB84 5E97


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#296652: ITP: python-apsw -- another Python SQLite wrapper

[Joel Rosdahl]

Package: wnpp
Severity: wishlist

I intend to package APSW (Another Python SQLite Wrapper).

URL:

http://www.rogerbinns.com/apsw.html

Description:

APSW (Another Python SQLite Wrapper) is an SQLite 3 wrapper that
provides the thinnest layer over SQLite 3 possible. Everything you
can do from the C API to SQLite 3, you can do from Python.
Although APSW's API looks vaguely similar to Python's DB-API, it
is not compliant with that API and instead works the way SQLite 3
does.

License:

Copyright (C) 2004 Roger Binns [EMAIL PROTECTED]

This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any
damages arising from the use of this software.

Permission is granted to anyone to use this software for any
purpose, including commercial applications, and to alter it and
redistribute it freely, subject to the following restrictions:

1. The origin of this software must not be misrepresented; you
   must not claim that you wrote the original software. If you use
   this software in a product, an acknowledgment in the product
   documentation would be appreciated but is not required.

2. Altered source versions must be plainly marked as such, and
   must not be misrepresented as being the original software.

3. This notice may not be removed or altered from any source
   distribution.

-- 
Joel Rosdahl [EMAIL PROTECTED]
Key BB845E97; fingerprint 9F4B D780 6EF4 5700 778D  8B22 0064 F9FF BB84 5E97


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#290734: please support python2.4

[Joel Rosdahl]

Matthias Klose [EMAIL PROTECTED] writes:

 Package: egenix-mx-base
 Version: 2.0.5
 Tags: patch

 Pleae build the egenix modules for python2.4 as well. At least
 pygresql already depends on it. According to the upstream release
 notes 2.0.6 is needed for python2.4 support.

I uploaded new packages January 16th, but they seem to be stuck in the
new queue.

Regards,
Joel

-- 
Joel Rosdahl [EMAIL PROTECTED]
Key BB845E97; fingerprint 9F4B D780 6EF4 5700 778D  8B22 0064 F9FF BB84 5E97


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]