Bug#819684: Uurgent
Cancel any further mailings or contact. On Jun 11, 2016 8:40 PM, "Tax_Defender" wrote: > > Smile Richard > > Solve Your Tax__Problems Now
Bug#685302: Installing html package with Python 3
On 20/08/2012, at 2:19 AM, Russel Winder wrote: > Of course there is then a deeper problem, Python 3 has an html package > in the standard distribution, at least on Debian Unstable. :-( Thanks for the info. I'm looking at making things better but I think to do so I'll want to move my "html" package to "html.format" using the new package namespace support in Python 3.3 - an idea I'll test out once 3.3rc1 is released. Richard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#606622: udev: please add a way to override warn_if_interactive
Package: udev Version: 164-2 Severity: important Tags: patch When I boot a Debian appliance for libguestfs (http://libguestfs.org) the boot sits and waits for 60 seconds while it prints the large "warn_if_interactive" warning (when starting udev service). The warning is wrong: although the tty is /dev/ttyS0, the service is not being started interactively. Therefore please provide a way that we can bypass this warning. A suggested patch will be attached to this bug report. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.36-trunk-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages udev depends on: ii debconf [debconf-2.0]1.5.24 Debian configuration management sy ii libc62.11.2-7Embedded GNU C Library: Shared lib ii libselinux1 2.0.96-1SELinux runtime shared libraries ii libudev0 164-2 libudev shared library ii libusb-0.1-4 2:0.1.12-13 userspace USB programming library ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip ii util-linux 2.17.2-3.3 Miscellaneous system utilities Versions of packages udev recommends: ii pciutils 1:3.1.7-5 Linux PCI Utilities ii usbutils 0.73-10lenny2 Linux USB utilities udev suggests no packages. -- debconf information: udev/new_kernel_needed: false udev/title/upgrade: udev/reboot_needed: udev/sysfs_deprecated_incompatibility: --- udev.old2010-12-10 12:31:14.0 + +++ udev.new2010-12-10 12:29:44.0 + @@ -60,6 +60,10 @@ } warn_if_interactive() { + if [ -n "$DEBIAN_UDEV_NO_WARN_IF_INTERACTIVE" ]; then +return + fi + if [ "$RUNLEVEL" = "S" -a "$PREVLEVEL" = "N" ]; then return fi
Bug#550377: libcurses-ocaml: ocaml-curses can't link even a simple program
Package: libcurses-ocaml Version: 1.0.2-3+b1 Severity: important Even a simple ocaml-curses program canot be compiled: $ echo 'Curses.initscr ()' > test.ml $ ocamlfind ocamlopt -package curses -linkpkg test.ml -o test 2>&1 | head /usr/lib/ocaml/curses/libcurses_stubs.a(ml_curses.o): In function `mlcurses_attrset': (.text+0x33): undefined reference to `stdscr' /usr/lib/ocaml/curses/libcurses_stubs.a(ml_curses.o): In function `mlcurses_standend': (.text+0x63): undefined reference to `stdscr' /usr/lib/ocaml/curses/libcurses_stubs.a(ml_curses.o): In function `mlcurses_standout': (.text+0x93): undefined reference to `stdscr' /usr/lib/ocaml/curses/libcurses_stubs.a(ml_curses.o): In function `mlcurses_attr_set': (.text+0xc3): undefined reference to `stdscr' /usr/lib/ocaml/curses/libcurses_stubs.a(ml_curses.o): In function `mlcurses_colors': (.text+0x133): undefined reference to `COLORS' -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libcurses-ocaml depends on: ii libc6 2.9-12 GNU C Library: Shared libraries ii ocaml-base-nox [ocaml-base-no 3.11.1-2 Runtime system for OCaml bytecode libcurses-ocaml recommends no packages. libcurses-ocaml suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#530427: ITP: libguestfs -- library for accessing and modifying guest disk images
Package: wnpp Severity: wishlist Owner: Richard Jones * Package name: libguestfs Version : 1.0.31 Upstream Author : Richard W.M. Jones * URL : http://et.redhat.com/~rjones/libguestfs/ * License : LGPL Programming Lang: C, Shell script, various others Description : library for accessing and modifying guest disk images (Copied from the website, which best summarises this ...) libguestfs is a library for accessing and modifying guest disk images. Amongst the things this is good for: making batch configuration changes to guests, viewing and editing files inside guests, getting disk used/free statistics (see also: virt-df), migrating between virtualization systems (see also: virt-p2v), performing partial backups, performing partial guest clones, cloning guests and changing registry/UUID/hostname info, and much else besides. libguestfs uses Linux kernel and qemu code, and can access any type of guest filesystem that Linux and qemu can, including but not limited to: ext2/3/4, btrfs, FAT and NTFS, LVM, many different disk partition schemes, qcow, qcow2, vmdk. libguestfs provides ways to enumerate guest storage (eg. partitions, LVs, what filesystem is in each LV, etc.). It can also run commands in the context of the guest. Also you can upload and download files and directories. libguestfs is a library that can be linked with C and C++ management programs (or management programs written in OCaml, Perl, Python, Ruby, Java or Haskell). You can also use it from shell scripts or the command line. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#530425: ITP: febootstrap -- a tool for bootstrapping a Fedora system (like Debian debootstrap)
Package: wnpp Severity: wishlist Owner: Richard Jones * Package name: febootstrap Version : 2.1 Upstream Author : Richard W.M. Jones * URL : http://et.redhat.com/~rjones/febootstrap/ * License : GPL Programming Lang: Shell script Description : a tool for bootstrapping a Fedora system (like Debian debootstrap) febootstrap is a tool we use which is analoguous to debootstrap, to make Fedora root filesystems. The package also includes tools for manipulating the filesystems and creating initramfs images. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#526442: libperl4caml-ocaml-dev: Can't use threads with www_mechanize
I'm highly doubtful this would ever work. Perl contains lots of global state. It's unclear if it's even safe to call this state from separate threads even if it's locked. You'd at least have to build Perl with the MULTIPLICITY option (perlguts q.v.) and change perl4caml dramatically to support it. Rich. -- Richard Jones Red Hat -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#526436: libperl4caml-ocaml-dev: Using regexp fails with www_mechanize.follow_link
I don't think calling 'eval' is a good way to solve this, since the argument could contain all sorts of things, not just a well-behaved regexp. We need to somehow convert the string to a regexp using a function from perlguts. Unfortunately I could work out how to actually do this, so it needs a bit more examination from someone with the relevant Perl skills. Rich. -- Richard Jones Red Hat -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#512834: ITP: ocaml-autoconf -- autoconf macros for OCaml
On Sat, Jan 24, 2009 at 11:45:04AM +0100, Stefano Zacchiroli wrote: > Package: wnpp > Severity: wishlist > Owner: Stefano Zacchiroli > > * Package name: ocaml-autoconf > Upstream Author : Richard Jones, Stefano Zacchiroli, et al. > * URL : http://ocaml-autoconf.forge.ocamlcore.org/ > * License : BSD (3-clauses) > Programming Lang: m4 > Description : autoconf macros for OCaml > > RFC: this package will consists of just one file: > /usr/share/ocaml-autoconf/ocaml.m4 , and this puzzles me a bit as Two files actually, because you'll want to include the man page. > overkilling. Nevertheless, I've no clue about how autoconf extensions > should be packaged, and my naive attempts to find similar packages in > the archive failed. FWIW in Fedora I just packaged the file in /usr/share/ocaml-autoconf/ocaml.m4, and the man page tells people to manually copy this file into their project. This is analogous to how the other autotools work -- eg. look at /usr/share/*/*.m4 and /usr/share/*/*/*.m4. Rich. -- Richard Jones Red Hat -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#512658: ITP: coccinelle -- semantic patching tool for C
On Fri, Jan 23, 2009 at 12:30:19AM +0100, Eugeniy Meshcheryakov wrote: > pycaml version in coccinelle is modified. Diff can be found in > pycaml/modif-orig.txt (not complete). The most important part, > it seems, is: I guess you've already seen it, but I posted an additional patch that is needed for Python 2.6. HOWEVER I'm not very confident that the patch is correct :-( Rich. -- Richard Jones Red Hat diff -ur coccinelle-0.1.4.orig/pycaml/pycaml_ml.c coccinelle-0.1.4/pycaml/pycaml_ml.c --- coccinelle-0.1.4.orig/pycaml/pycaml_ml.c 2008-03-29 20:25:26.0 + +++ coccinelle-0.1.4/pycaml/pycaml_ml.c 2009-01-21 21:58:21.0 + @@ -173,7 +173,7 @@ int fd; int x; int ret_int; -char *rvs; +const char *rvs; int fmt = Int_val(Field(format,1)); PyObject *ob1,*ob2,*ob3; void *func = getcustom(Field(format,0)); @@ -1184,7 +1184,12 @@ { (void *)PyImport_AddModule, 28, "PyImport_AddModule" }, { (void *)PyImport_ImportModule, 28, "PyImport_ImportModule" }, /* 51 */ +#ifndef PyImport_ImportModuleEx +/* In Python 2.6, this because a #define so we cannot take + * the address of the function. - RWMJ. + */ { (void *)PyImport_ImportModuleEx, 51, "PyImport_ImportModuleEx" }, +#endif /* 28 */ { (void *)PyImport_Import, 28, "PyImport_Import" }, /* 14 */
Bug#509803: Fails to properly free memory on exit
On Fri, Dec 26, 2008 at 03:39:06PM +0100, Goswin Brederlow wrote: > I wrote some bindings for libaio using custom blocks for the C > structures I need to allocate for the internal state and buffer. I > also wrote *_finalize(value) functions for them so they get properly > cleaned up when no longer in use. > > I assumed that when the program exits normaly that all memory will be > freed, specifically that *_finalize(value) is called for all custom > blocks in case they have to do some custom cleanup. Unfortunately that > is not the case. I think I've seen this problem before and solved it using something along these lines: at_exit Gc.compact ;; Rich. -- Richard Jones Red Hat -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#503616: libapache2-mod-ocamlnet: mod_netcgi_apache.so will not load
On Tue, Oct 28, 2008 at 11:21:03PM +0100, Stefano Zacchiroli wrote: >Alternatively, we can try adding an RPATH to >/usr/lib/apache2/modules/mod_netcgi_apache.so pointing to `ocamlc >-where`. > >I got a bit rusty on the rpath issue [1,2], but I do think that in >this case it would be acceptable. We'll probably do an rpath for this in Fedora, since it seems to be the simplest and least intrusive solution. Rich. -- Richard Jones Red Hat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#256900: Ocaml compiled programs cannot be stripped
On Mon, Aug 18, 2008 at 05:46:50PM +0200, Xavier Leroy wrote: > 2- If this isn't practical, it's not a big deal that a couple of >executables cannot be stripped. Other packagers (e.g. RedHat and >Mandriva) have had no problems in the past turning stripping off on >a case-by-case basis. Indeed this is true -- we tell people only to disable strip for the particular executables that have this problem. The other executables are stripped as normal. http://fedoraproject.org/wiki/Packaging/OCaml#Stripping_binaries Rich. -- Richard Jones Red Hat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#479152: ITP: core -- Jane Street Capital's alternative standard library for OCaml
Given what Markus said: > Note that communication _among_ machines with different endianness, > assuming that they all have the same byte layout, should work, too, > with the current binary protocol. At least if you do not mix 32/64bit > machines there... I'm going to compile bin-prot for the other architectures anyway, just as it is. I think I will punt on the problem of changing bin-prot to do byte-swabbing to someone who is interested in this inter-architecture case. (But I'll document the shortcoming, of course). Rich. -- Richard Jones Red Hat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#479152: ITP: core -- Jane Street Capital's alternative standard library for OCaml
On Sat, May 03, 2008 at 11:20:21PM +0200, Stefano Zacchiroli wrote: > On Sat, May 03, 2008 at 09:42:24PM +0100, Richard Jones wrote: > > - We think 'core' is a bit too generic a name and risks some > > confusion. If you would like to coordinate with us, then we can > > decide on a different name. (corelib? janestcore? - I admit I don't > > have a good suggestion). > > Same problem here, my intention was to call it ocaml-core, but the idea > of "pressing" Jane St for a better name together is neat. "janestcore" > sounds nice to me. If you feel so, go ahead and mail them with our > concerns; please put me in Cc. OK, I'll do it in a moment. > > - For the description, you might want to use the Fedora description, > > which is in this file, under '%description': > > > > http://www.annexia.org/tmp/ocaml/ocaml-core.spec > > A bit too long for our standards, but in fact I have already grabbed > your module summary posted to the caml list and put it in README.Debian > (with the due kudos). It looks like that summary is exactly what you've > put in the Fedora description. Note there was a typo: at the end it says 'inigroups', it should read 'initgroups' (the name of the C function). > > - If you have patches either to make bin-prot big-endian or to excise > > those bits of core that depend on bin-prot, then I'll take them, or > > try to help. > > I haven't yet attacked the big-endian bits, but I'm working on a patch > to make bin-prot dependency optional and detected at compile time. Will > mail you back when I've something fully working. OK :-) Rich. -- Richard Jones Red Hat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#479152: ITP: core -- Jane Street Capital's alternative standard library for OCaml
A few other points, from the Fedora point of view. - We think 'core' is a bit too generic a name and risks some confusion. If you would like to coordinate with us, then we can decide on a different name. (corelib? janestcore? - I admit I don't have a good suggestion). - For the description, you might want to use the Fedora description, which is in this file, under '%description': http://www.annexia.org/tmp/ocaml/ocaml-core.spec - If you have patches either to make bin-prot big-endian or to excise those bits of core that depend on bin-prot, then I'll take them, or try to help. Rich. -- Richard Jones Red Hat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#479152: ITP: core -- Jane Street Capital's alternative standard library for OCaml
I don't know if you realised, but you'll need 'res' too: http://www.ocaml.info/home/ocaml_sources.html#RES Rich. -- Richard Jones Red Hat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#444360: ocamlnet_2.2.8.1-3(hppa/experimental): FTBFS: tries to link non-PIC static object into shared object
On Sat, Sep 29, 2007 at 12:58:12AM +1000, skaller wrote: > On Fri, 2007-09-28 at 14:26 +0100, Richard Jones wrote: > > On Fri, Sep 28, 2007 at 03:17:27PM +0200, Stefano Zacchiroli wrote: > > > On Fri, Sep 28, 2007 at 02:10:45PM +0100, Richard Jones wrote: > > > > In particular I could do it if INRIA said that they would support the > > > > change in some future release (see the exception "Patches Heading > > > > Upstream"). But otherwise this is quite a large ABI change -- if > > > > Fedora users started to build lots of 64 bit shared libraries linked > > > > with -lcamlrun I could end up maintaining it separately forever. > > > > [I meant to say -lcamlrun_shared here] > > > > > I think you misunderstood my proposal. I don't want to apply your > > > initial fix which changes libcamlrun.a into libcamlrun.so. I want to add > > > a libcamlrun_shared.so, so there would be no ABI change, just the added > > > possibility to link against it. > > > > > > Or maybe you're concerned about having to drop in the future support for > > > libcamlrun_shared.so, but I think the user impact of that new library > > > would be quite low. In fact I don't think anything else that > > > mod_caml-like projects will need it ... > > > > That would also need to go upstream before Fedora could accept it. > > Why? I would have thought it is close to *policy* to provide > libraries for both static and dynamic link. Please don't get me wrong here: I want the patch in OCaml, I want Fedora to follow Debian's packaging decisions where possible, and I want to have mod_caml & ocamlnet + Apache working. But this patch is a big potential change to the API and it can't go in to Fedora unless INRIA accept it upstream, and that concern overrides other issues. Hopefully INRIA will indicate that they want to accept this in which case it can go in to Fedora straightaway. Rich. -- Richard Jones Red Hat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#444360: ocamlnet_2.2.8.1-3(hppa/experimental): FTBFS: tries to link non-PIC static object into shared object
On Fri, Sep 28, 2007 at 03:17:27PM +0200, Stefano Zacchiroli wrote: > On Fri, Sep 28, 2007 at 02:10:45PM +0100, Richard Jones wrote: > > In particular I could do it if INRIA said that they would support the > > change in some future release (see the exception "Patches Heading > > Upstream"). But otherwise this is quite a large ABI change -- if > > Fedora users started to build lots of 64 bit shared libraries linked > > with -lcamlrun I could end up maintaining it separately forever. [I meant to say -lcamlrun_shared here] > I think you misunderstood my proposal. I don't want to apply your > initial fix which changes libcamlrun.a into libcamlrun.so. I want to add > a libcamlrun_shared.so, so there would be no ABI change, just the added > possibility to link against it. > > Or maybe you're concerned about having to drop in the future support for > libcamlrun_shared.so, but I think the user impact of that new library > would be quite low. In fact I don't think anything else that > mod_caml-like projects will need it ... That would also need to go upstream before Fedora could accept it. Rich. -- Richard Jones Red Hat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#444360: ocamlnet_2.2.8.1-3(hppa/experimental): FTBFS: tries to link non-PIC static object into shared object
On Fri, Sep 28, 2007 at 02:32:16PM +0200, Stefano Zacchiroli wrote: > On Fri, Sep 28, 2007 at 01:17:00PM +0100, Richard Jones wrote: > > No I don't actually. It's strange because I didn't hit this bug at > > all when compiling ocamlnet for Fedora. > > Are you building the Apache connector? The bug manifests itself only if > you're building that, and only on architecture in which PIC code is > actually different than non-PIC code. I thought we were but I just checked the specfile and it turns out we aren't. > > Unfortunately Fedora policy stops me from incorporating this fix: > > http://caml.inria.fr/mantis/view.php?id=3866 > > into our OCaml. It would have to be accepted into upstream (INRIA's) > > OCaml first. > > Why? Because of our policy ... http://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream In particular I could do it if INRIA said that they would support the change in some future release (see the exception "Patches Heading Upstream"). But otherwise this is quite a large ABI change -- if Fedora users started to build lots of 64 bit shared libraries linked with -lcamlrun I could end up maintaining it separately forever. Rich. -- Richard Jones Red Hat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#444360: ocamlnet_2.2.8.1-3(hppa/experimental): FTBFS: tries to link non-PIC static object into shared object
On Fri, Sep 28, 2007 at 12:59:20PM +0200, Stefano Zacchiroli wrote: > On Fri, Sep 28, 2007 at 09:59:45AM +0200, Stefano Zacchiroli wrote: > > Aaaarggh, right! IIRC that's an upstream issue for which exists a patch > > (by Richard Jones maybe ...), isn't it? What about applying it in the > > OCaml Debian package? > > Yep, that was the case, here is a link to the corresponding entry in the > caml BTS: http://caml.inria.fr/mantis/view.php?id=3866 . > > Apparently upstream do not care a lot about this issue, but I think the > final solution hinted by Richard is the right one: leave libcarmlrun.a > as it is and additionally provide a libcamlrun_shared.so which we can > use where PIC code is required. > > Any comments / objection to add something like that to the ocaml package > in Debian? > > Richard: do you perhaps already have a patch for this in Red Hat? No I don't actually. It's strange because I didn't hit this bug at all when compiling ocamlnet for Fedora. Unfortunately Fedora policy stops me from incorporating this fix: http://caml.inria.fr/mantis/view.php?id=3866 into our OCaml. It would have to be accepted into upstream (INRIA's) OCaml first. But it's desperately needed, so please vote for INRIA to include it :-) Rich. -- Richard Jones Red Hat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#423506: libcurl3-gnutls-dev: package conflicts with libcurl3-dev
Package: libcurl3-gnutls-dev Version: 7.15.5-1 Severity: important If libcurl3-dev is installed, then libcurl3-gnutls-dev cannot be installed because of a conflicting file: Unpacking libcurl3-gnutls-dev (from .../libcurl3-gnutls-dev_7.15.5-1_amd64.deb) ... dpkg: error processing /var/cache/apt/archives/libcurl3-gnutls-dev_7.15.5-1_amd64.deb (--unpack): trying to overwrite `/usr/include/curl/curl.h', which is also in package libcurl3-dev dpkg-deb: subprocess paste killed by signal (Broken pipe) I think libcurl3-gnutls-dev needs a 'Conflicts: libcurl3-dev'. At the moment, the Conflicts line shows libcurl2-dev. Rich. -- System Information: Debian Release: 3.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-xen Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages libcurl3-gnutls-dev depends on: ii libc6-dev [libc-dev] 2.3.6.ds1-13 GNU C Library: Development Librari ii libcurl3-gnutls7.15.5-1 Multi-protocol file transfer libra ii libgnutls-dev 1.4.4-3 the GNU TLS library - development ii libidn11-dev 0.6.5-1 Development files GNU libidn, impl ii libkrb5-dev1.4.4-7etch1 Headers and development libraries ii zlib1g-dev 1:1.2.2-4.sarge.2 compression library - development libcurl3-gnutls-dev recommends no packages. -- no debconf information -- Richard Jones Red Hat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#390557: wordpress: Setting Options -> General -> Tagline to Japanese string causes webserver to segfault
Package: wordpress Version: 2.0.3-1 Severity: normal Go to Site Admin -> Options -> General Options, ie here: http://www.example.com/wp-admin/options-general.php and set the Tagline to something containing Japanese characters. (For me I used: 太ã£ãå¤äºº) The server immediately gives segfaults to any future requests. As far as I'm aware the only way to correct this is to go into the database and reset the tagline in the wp_options table directly (which is what I did). Wordpress seems to handle UTF-8 characters in all other places I've tested however. -- System Information: Debian Release: 3.1 Architecture: amd64 (x86_64) Kernel: Linux 2.6.16-xen Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages wordpress depends on: ii apache2-mpm-prefork [htt 2.0.54-5sarge1 traditional model for Apache2 ii libapache2-mod-php4 4:4.3.10-16 server-side, HTML-embedded scripti ii mysql-client [virtual-my 4.0.24-10sarge2 mysql database client binaries ii php4 4:4.3.10-16 server-side, HTML-embedded scripti ii php4-mysql 4:4.3.10-16 MySQL module for php4 -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#305457: O: ocamldbi
On Tue, Apr 19, 2005 at 11:01:11PM -0500, John Goerzen wrote: > Package: wnpp > Severity: normal > > I am orphaning this package. Is someone willing to maintain this? The latest version and a working debian/ config is in the subversion repo on alioth. Rich. -- Richard Jones, CTO Merjis Ltd. Merjis - web marketing and technology - http://merjis.com Team Notepad - intranets and extranets for business - http://team-notepad.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#305456: O: perl4caml -- Use Perl code in OCaml programs, runtime library
On Tue, Apr 19, 2005 at 11:00:49PM -0500, John Goerzen wrote: > Package: wnpp > Severity: normal > > I intend to orphan the perl4caml package. > > The package description is: > perl4caml allows you to use Perl code within Objective CAML (OCaml), > thus neatly side-stepping the old problem with OCaml which was that it > lacked a comprehensive set of libraries. Well now you can use any part > of CPAN in your OCaml code. > . > This package provides the runtime dynamic library necessary to use this > in bytecode OCaml programs. About 2-3 weeks ago I put the latest perl4caml and a working debian/ config into subversion on alioth. Can someone help me to upload this? Rich. -- Richard Jones, CTO Merjis Ltd. Merjis - web marketing and technology - http://merjis.com Team Notepad - intranets and extranets for business - http://team-notepad.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#304382: ocamldbi: please rebuild with ocaml 3.08.3
On Tue, Apr 12, 2005 at 09:28:16PM +0200, Julien Cristau wrote: > Package: ocamldbi > Severity: grave > Tags: sid > Justification: renders package unusable > > ocamldbi needs to be rebuilt with ocaml 3.08.3, and its dependencies > updated to ocaml{,-base}-nox-3.08.3. I don't understand this message. Subversion contains a debian/control which specifies Depends: ocaml-nox-3.08.3. What else do I need to do? Rich. -- Richard Jones, CTO Merjis Ltd. Merjis - web marketing and technology - http://merjis.com Team Notepad - intranets and extranets for business - http://team-notepad.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#303339: fuse 2.x
On Apr 8, 2005 8:40 AM, Sebastien Delafond <[EMAIL PROTECTED]> wrote: > On Thu, Apr 07, 2005 at 10:43:47PM +1000, Richard Jones wrote: > > So firstly it looks like I've been fairly boneheaded here. that > > value of 1000 in blocks = 1000*1024 should never have been there, > > that should have been calculated from quoteMbTotal (after > > appropriate parsing into an int, the string might include the MB tag > > which will need stripping (the same way as the quotaMbUsed is > > stripped should work if it does have the {space}MB tag). This > > assumes that the libgmail.py code still calculates the correct > > values for quotainfo. > > I implemented this change ("not hardcoding the gmail quota in > gmailfs"), and that effectively fixed what df reports as the total > size for a gmailfs virtual drive. > > On the other hand, the problem of df reporting 0 as the usage > percentage was more a bit more involved; I had to make a change in the > python-fuse CVS repository (I actually maintain it upstream, on top of > my responsibility for it as a Debian package): it appears that the > statfs stub in _fusemodule.c wasn't dealing whatsoever with > statfs.f_bavail. This value is actually what df uses to figure out how > much space is free, whereas statfs.f_bfree is used to determine how > much space is available *to the superuser only*). > Cool, I'm glad someone has taken over the python fuse bindings. You might have done this already but if not it might be worth looking at exposing the uid/gid of the user who is mounting the filesystem, this is available in the fuse context from memory but didn't used to be exposed via python. > After making this change, I fixed the statfs call in gmailfs as well > (setting statfs.f_bavail to statfs.f_bfree, since I'm not sure blocks > reserved for the superuser make sense in a gmailfs context). > > As soon as both the new python-fuse and gmailfs hit Debian, I'll send > you the gmailfs patch, but you'll have to make it clear that this > change *will break* if not used with the latest python-fuse from > CVS... > I already rely on the CVS version of libgmail (haven't checked for a release recently, that may no longer be the case), so one more CVS checkout dependency isn't really an issue :-) . I look forward to the patch. > > Thanks again for maintaining the package, it means most of the gmailfs > > questions I get are now related to supporting the windows "Gmail > > Drive" which I have nothing to do with :-) > > No problem, I'm glad my work for Debian makes your life easier :) > Not just mine, packages like gmailfs with long lists of obscure dependencies really benefit from being packaged up as a .deb, I'm sure its greatly widened the audience for gmailfs (I even had one guy email me asking for advice on how to install the .deb's on his windows XP machine, poor fellow :-) ) Regards, Richard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]