Bug#819684: Uurgent

2016-06-11 Thread Richard Jones
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

2012-08-21 Thread Richard Jones
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

2010-12-10 Thread Richard Jones
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

2009-10-09 Thread Richard Jones
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 21 | 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#530425: ITP: febootstrap -- a tool for bootstrapping a Fedora system (like Debian debootstrap)

2009-05-24 Thread Richard Jones
Package: wnpp
Severity: wishlist
Owner: Richard Jones rjo...@redhat.com


* Package name: febootstrap
  Version : 2.1
  Upstream Author : Richard W.M. Jones rjo...@redhat.com
* 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#530427: ITP: libguestfs -- library for accessing and modifying guest disk images

2009-05-24 Thread Richard Jones
Package: wnpp
Severity: wishlist
Owner: Richard Jones rjo...@redhat.com


* Package name: libguestfs
  Version : 1.0.31
  Upstream Author : Richard W.M. Jones rjo...@redhat.com
* 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#526436: libperl4caml-ocaml-dev: Using regexp fails with www_mechanize.follow_link

2009-05-02 Thread Richard Jones


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#526442: libperl4caml-ocaml-dev: Can't use threads with www_mechanize

2009-05-02 Thread Richard Jones
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#512834: ITP: ocaml-autoconf -- autoconf macros for OCaml

2009-01-24 Thread Richard Jones
On Sat, Jan 24, 2009 at 11:45:04AM +0100, Stefano Zacchiroli wrote:
 Package: wnpp
 Severity: wishlist
 Owner: Stefano Zacchiroli z...@debian.org
 
 * 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

2009-01-23 Thread Richard Jones
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

2008-12-31 Thread Richard Jones
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

2008-10-29 Thread Richard Jones
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

2008-08-19 Thread Richard Jones
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

2008-05-05 Thread Richard Jones

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

2008-05-03 Thread Richard Jones
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#479152: ITP: core -- Jane Street Capital's alternative standard library for OCaml

2008-05-03 Thread Richard Jones
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

2008-05-03 Thread Richard Jones
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#444360: ocamlnet_2.2.8.1-3(hppa/experimental): FTBFS: tries to link non-PIC static object into shared object

2007-09-28 Thread Richard Jones
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

2007-09-28 Thread Richard Jones

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

2007-09-28 Thread Richard Jones
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#444360: ocamlnet_2.2.8.1-3(hppa/experimental): FTBFS: tries to link non-PIC static object into shared object

2007-09-28 Thread Richard Jones
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#423506: libcurl3-gnutls-dev: package conflicts with libcurl3-dev

2007-05-12 Thread Richard Jones
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

2006-10-01 Thread Richard Jones
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#305456: O: perl4caml -- Use Perl code in OCaml programs, runtime library

2005-05-01 Thread Richard Jones
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#305457: O: ocamldbi

2005-05-01 Thread Richard Jones
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#304382: ocamldbi: please rebuild with ocaml 3.08.3

2005-04-13 Thread Richard Jones
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

2005-04-09 Thread Richard Jones
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]