Bug#993858: ocaml-dune: dune-install doesn't correctly place "doc" section in Debian systems

[Emilio Jesús Gallego Arias]

Hello Stéphane,

Stéphane Glondu  writes:

> I guess we are talking about people doing "sudo dune install", right? As
> opposed to "dune install" being called during Debian package builds.

I am talking about both, in particular it would be nice if

   DESTDIR=debian/tmp dune install

would install OCaml package docs in `share/doc` as opposed to `doc`,
which is the Opam layout.

> Installing arbitrary software this way (with root privileges) should not
> be done IMHO, but if done, it must happen in /usr/local (or outside
> /usr). I remember having trouble configuring dune correctly to do that
> (I couldn't tell it to "dune install" into /usr/local, but still look
> for libraries in /usr/lib/ocaml in "dune build".

This should have been solved, tho not sure in which version.

> It would be nice if dune had a notion of "profile": a default "local"
> one that would use /usr/local directories, and a "debian" one, used only
> for Debian package builds, that would use $destdir/usr and $destdir/etc.
> While searching for libraries in all profiles ("local" first, then
> "debian").

That's an interesting idea; for now, using dune 2.9, you should be able
to emulate profiles using the right options to `dune install`.

I think the idea upstream is more towards let packagers configure the
right defaults at dune build time, then have all the package builds work ok.

> The "correct" path for the "doc" section in the "local" profile would be
> /usr/local/share/doc.

Indeed, so with this patch, `dune install --prefix=/usr/local` will work 
correctly.

>> This creates problems for both users and developers.
>
> What kind of problems?

Developers using

  DESTDIR=debian/tmp dune install

have to manually move doc to share/doc

Users have the problem with --prefix=/usr/local not installing the docs
in the right location.

> Patching things this way could (would, I think) break Debian package
> builds. One has to check that all packages using dune (and there are a
> lot of them now) still build with this patch. Maybe this could be done
> during as part of an OCaml transition... To be continued.

Indeed, it could, tho actually I couldn't find a package installing the
docs as installed by dune.

>> Note that a similar problem may exist for files in the "etc" section.
>
> I am not really sure on how to handle the "etc" section. I would use
> /etc directly, even for third-party software but /usr/local/etc exists
> on the Internet, so maybe it would be better to use it in the "local"
> profile.

I guess the etc section is fine for both uses outlined above? Maybe not
for the packaging one, as actually you'd want

 DESTDIR=debian/tmp dune install --prefix=/usr/ --etcdir=/etc

the current Dune default is the Opam layout which would install config
in /usr/etc IIANM.

Kind regards,
Emilio

Bug#993858: ocaml-dune: dune-install doesn't correctly place "doc" section in Debian systems

[Emilio Jesús Gallego Arias]

Source: ocaml-dune
Version: 2.7.1-2
Severity: important

Dear OCaml Maintainers,

dune-install will by default install files in the "doc" section to
$prefix/doc, this is incorrect in Debian as it should be $share/doc.

This creates problems for both users and developers.

Dune >= 2.9 allows configuring the doc install path. For previous
versions, this patch must be added:

diff --git a/src/dune_rules/install.ml b/src/dune_rules/install.ml
index afa2acdad..9fd7e6779 100644
--- a/src/dune_rules/install.ml
+++ b/src/dune_rules/install.ml
@@ -209,7 +209,7 @@ module Section = struct
   let libexec_root = libdir in
   let share_root = Path.relative destdir "share" in
   let etc_root = Path.relative destdir "etc" in
-  let doc_root = Path.relative destdir "doc" in
+  let doc_root = Path.relative share_root "doc" in
   { lib_root
   ; libexec_root
   ; share_root

Note that a similar problem may exist for files in the "etc" section.

Kind regards,
Emilio

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-81-lowlatency (SMP w/8 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE=es_ES 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#971439: Build procedure is incorrect and produces invalid files

[Emilio Jesús Gallego Arias]

Package: lablgtk3
Version: 3.1.1-1

Dear OCaml maintainers,

as far as I could see this is a general bug on quite a few Debian OCaml
packages; in particular submitting for lablgtk3 but this bug should be
assigned to more packages.

It seems that the build procedure for lablgtk3 is incorrect, see for
example https://github.com/coq/coq/issues/13079 , where the package
contains and invalid META file; moreover as `-p` was not used the wrong
compiler settings were used to build the binaries [for example regarding
optimization]

OCaml packages that use dune as a build system _must_ be built:

- always with `dune build -p $pkg1,$pkg2` for the desired list of packages

and either:

- using the officially released .tbz archive that for example
  dune-release produces, which will contain the right metadata for
  version numbers, etc...

- or if using a git checkout, `dune subst` _must_ be run before the
  build so the metadata is update prior build.

Let us know if we can be of any help.

Kind regards,
Emilio

Bug#684499: Streaming MOVE commands

[Emilio Jesús Gallego Arias]

Hi Adrian,

Adrian Bunk  writes:

> What was the result?
> Any chance of getting this one-line change into jessie?

So far the current Jessie packages don't include the fix, which forces
me to use my own custom packages, so indeed, this is not optimal.

jessie-backports seem to include the fix thou.

Best,
E.

Bug#684499: Streaming MOVE commands

[Emilio Jesús Gallego Arias]

Thanks a lot both for your help!

On Mon, 22 Feb 2016, Timo Sirainen wrote:
>> Is this patch suitable of being backported to 2.2.13? (Debian stable)
>
> Should be.
>
> BTW. This bug only meant that some expunges were ignored, which at
> worst caused unwanted email duplicates. It didn't corrupt the mailbox
> state or the client state in any way.

Thanks for the update. Testing on 2.2.13.

"Jaldhar H. Vyas"  writes:

> I don't know if the release team will allow it for stable even though
> it is a minor change but I'll definitely bring it up for their
> consideration.

Timo said the bug doesn't corrupt data, but IMVHO a case could be made
for stable-updates.

I get around 100-200 duplicated mails a day, so it really hampers the
usability of the package with my mail client (gnus).

Also, it seems that the bug be prevent people to use dsync and other
sync tools with Dovecot.

Luca, does the patch fix your dsync issues?

Unfortunately, I can't properly test the patch with 2.2.13, my mail
servers have really low mail volume to consider them "testing".

Best,
Emilio

Bug#684499: Fixed upstream

[Emilio Jesús Gallego Arias]

found 684499 1:2.2.13-12~deb8u1
found 684499 1:2.2.18-2+b1
forwarded 684499 http://www.dovecot.org/list/dovecot/2016-February/103205.html
severity 684499 serious
tags 684499 +patch +fixed-upstream +confirmed

thanks

Hi,

I think this bug has been fixed and identified upstream.

Raising to serious as missed expunges are not something clients expect
and indeed can cause mail corruption or really weird behavior.

I've asked Timo if the patch would be suited for Jessie.

Thanks,
Emilio

Bug#319837: Not fixed for me.

[Emilio Jesús Gallego Arias]

reopen 319837
thanks

Hi all!

I'm afraid this bug is not fixed for me, as I keep getting the 

Error 28: Selected item cannot fit into memory

both with stock memtest86+ and with patched one (lds patch).

I'm running Lenny.

Versions:

ii  memtest86+ 2.01-1 thorough real-mode memory 
tester
ii  grub   0.97-47GRand Unified Bootloader 
(Legacy version)

Hardware: HP xw6400

iomem:

-00097fff : System RAM
00098000-0009 : reserved
000a-000b : Video RAM area
000c-000cddff : Video ROM
000d0800-000d51ff : Adapter ROM
000e8000-000e : pnp 00:0f
000f-000f : System ROM
0010-7ffc2e3f : System RAM
  0010-002ba032 : Kernel code
  002ba033-0037561f : Kernel data
  003ba000-0041d57f : Kernel bss
7ffc2e40-7fff : reserved
e000-efff : reserved
  e000-e7ff : PCI MMCONFIG 0
f000-f81f : PCI Bus :40
  f000-f7ff : :40:00.0
  f800-f801 : :40:00.0
f840-f8403fff : :00:1b.0
  f840-f8403fff : ICH HD audio
f8404000-f84043ff : :00:1d.7
  f8404000-f84043ff : ehci_hcd
f8404400-f84047ff : :00:1f.2
  f8404400-f84047ff : ahci
f900-fb1f : PCI Bus :40
  f900-f9ff : :40:00.0
f900-f9ff : nvidia
  fa00-faff : :40:00.0
fb20-fd6f : PCI Bus :10
  fb20-fb9f : PCI Bus :1e
fb40-fb6f : PCI Bus :1f
  fb60-fb60 : :1f:00.0
fb60-fb60 : tg3
  fd601000-fd601fff : :10:00.3
fd601000-fd601027 : shpchp
fe00-fe01 : pnp 00:0e
fe60-fe6f : pnp 00:0e
fe70-fe7003ff : pnp 00:0e
fec0- : reserved
  fed0-fed003ff : HPET 0



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

Bug#464574: [Pkg-virtualbox-devel] Bug#464574: Bug#464574: virtualbox-ose: No network in

[Emilio Jesús Gallego Arias]

Michael Meskes [EMAIL PROTECTED] writes:

 I take it you're talking about the first nameserver line, right?
Yes.

 I just added nameserver 1.1.1.1 to my resolv.conf and while becoming
 slower the system still works as advertised.
I tried the same (first line a bad nameserver = 1.1.1.1) and 2nd one a
good (non-local) one and the problem persists.

 Could it be that your local DNS server answered the queries without
 giving the IP number?
I have ruled out this possibility.

I'm running up to date Debian Lenny. Let me know what can I do to help
to debug this.

Regards and thanks,

Emilio


pgpGs9ZuqNp68.pgp
Description: PGP signature

Bug#442628: This bug is fixed upstream.

[Emilio Jesús Gallego Arias]

tag 442627 fixed-upstream

thanks

I had the same annoying bug, and indeed it is fixed in auctex 11.85,
which I'm running now.



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

Bug#406986: Upgrade B2evolution 0.9.2 to 1.10.2

[Emilio Jesús Gallego Arias]

Thijs Kinkhorst [EMAIL PROTECTED] writes:

 Hi Emilio,

 I would also consider removing it from stable, as I think the security
 team cannot support it.

 The security team for stable often supports versions that are upstream
 abandoned. The question is whether such a thing is feasible for a package.
 In this case I see just one open security issue in the tracker, for which
 a patch is available. I therefore see no immediate need to remove the
 package from stable.

I think the problem with this package is that the version in
stable/testing is old enough so recent advisories about b2evolution
don't ever bother to check if the problem exists in 0.9.2. So then it is
a lot of work for the security team/users to check if any new advisory
applies to such and old version of the packages and then write/adapt a
patch. Who knows, security by obsolescence sometimes works. :)

I asked the removal from stable because IMVHO installing b2evolution as
is now in Etch is just asking for [security] trouble. The package is 9
major versions behind upstream! (0.9 - 1.6 - 1.8 - 1.9 - 1.10 -
2.0 - 2.1 - 2.2 - 2.3 - 2.4)

I'm getting a lot of attacks in the logs for b2evolution, ATM none
didn't work as they targeted to higher versions of the software, but it
wouldn't surprise me if one day one of them works, given that
b2evolution is written in php and the attack patterns are similar. I
just switched all my installs.

In fact, I guess the package should be orphaned and removed from Debian
if a new maintainer doesn't step up, as Xavier Luthi (the original
maintainer) is not around (I didn't see him in mentors either).

Thanks a lot for your work,

Emilio



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

Bug#406986: Upgrade B2evolution 0.9.2 to 1.10.2

[Emilio Jesús Gallego Arias]

severity 406986 serious
thanks

This package should not be in testing.

Reasons: No security support from upstream for this version, as it is
upstream abandoned.

I would also consider removing it from stable, as I think the security
team cannot support it.

Regards,

Emilio



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

Bug#464574: [Pkg-virtualbox-devel] Bug#464574: virtualbox-ose: No network in

[Emilio Jesús Gallego Arias]

Dear Mr. Meskes, thanks for your prompt response.

Michael Meskes [EMAIL PROTECTED] writes:

 I was successfully running virtualbox in Etch, but last week I upgraded

 Which package did you use on Etch?

My upgrade process went from 1.5.2-dfsg2-4~bpo40+1 - 1.5.2-dfsg2-7 -
1.5.4-dfsg-4

Umm, interesting, I downgraded back to 1.5.2-dfsg2-7, and that doesn't
work. 1.5.2-dfsg2-4 and 1.5.2-dfsg2-4~bpo40+ neither work in Lenny. 

So the virtualbox upgrade didn't cause the bug, it must be something
else. Umm, the box seems to run perfectly, and I was running the 2.6.22
backported kernel in Etch, I have no idea what can be causing this. The
tun device seems up and running:

$ ls -l /dev/net/tun 
crw--- 1 root root 10, 200 2008-08-08 10:08 /dev/net/tun

I would be good to hear if other Lenny users are suffering the bug, I'll
ask a mate running Lenny to try.

 to Lenny, and all my virtual machines have lost net connectivity.

 Do you use the default NAT setup or a bridged setup? What does you
 /etc/vbox/intercfaces file contain?

The default NAT setup. Should I try other?

$ cat /etc/vbox/interfaces
# Linux static host networking interface configuration
#
# interface user bridge
# vbox0 guest br0

 I can reproduce it with an Ubuntu live CD for the matter.

 Does this mean creating a new VM with that live CD also has no network
 connectivity?

Yes

 $ ping $ANY_OTHER_IP
 100% packet loss

 This doesn't work for me either out of the box. How about some other
 ways to connect, e.g. tcptraceroute or a webbrowser? 

No way to get past the default gateway.

By the way, I lend a host with gutsy and the machines work, version
1.5.0-dfsg2-1ubuntu3.

But as I said, I think the problem is not in VirtualBox but in the way
it interacts with some Lenny subsystem.

Thanks for your work,

Emilio



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

Bug#464574: [Pkg-virtualbox-devel] Bug#464574: Bug#464574: virtualbox-ose: No network in

[Emilio Jesús Gallego Arias]

retitle 464574 If first line of /etc/resolv.conf is invalid, dns doesn't work 
in the guests
severity 464574 minor

thanks

Hi,

Torsten Werner [EMAIL PROTECTED] writes:

 On Feb 9, 2008 11:23 AM, Michael Meskes [EMAIL PROTECTED] wrote:
 ping cannot work with NAT because virtualbox would have to run as root.

Ok, I understood the NAT used in virtualbox and found the problem,
thanks for the hint. (I was incorrectly relying on ping)

The problem is that in my resolv.conf the first line was invalid, as in
the upgrade bind9 got uninstalled. My resolv.conf was like

$ cat /etc/resolv.conf
domain ls.fi.upm.es
nameserver 127.0.0.1
nameserver $exteranl

It seems that virtualbox NAT can only use the first line of resolv.conf
for dns servers, thus dns started to fail in the guests.

I reinstalled my caching dns server:

$ host babel.ls.fi.upm.es localhost
Using domain server:
Name: localhost
Address: 127.0.0.1#53
babel.ls.fi.upm.es has address 138.100.12.136

and the setup wasn't working, but I figure this is because bind by
default listens to local connections. Once I tried setting up a correct
first nameserver line, the virtual machines are working again.

Thanks for your help,

Emilio



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

Bug#464574: virtualbox-ose: No network in guest machines

[Emilio Jesús Gallego Arias]

Package: virtualbox-ose
Version: 1.5.4-dfsg-4
Severity: important

Hi,

I was successfully running virtualbox in Etch, but last week I upgraded
to Lenny, and all my virtual machines have lost net connectivity.

I did purge and install the package with no success, reboot the host,
rebuild the kernel modules, use the provided modules, etc... So far
network doens't work from the guests.

I can reproduce it with an Ubuntu live CD for the matter.

Some info from an Ubuntu live cd guest (sorry I had to type it due to
lack of network):

$ ifconfig
link encap: Ethernet HWaddr 08.
inet addr: 10.0.2.15 Bcast mask: OK
UP
No errors
(looks ok)

$ route 
gateway 10.0.2.2 eth0
(looks ok)

$ ping 10.0.2.2
Ok

$ ping $ANY_OTHER_IP
100% packet loss

Regards,

Emilio

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-3-686 (SMP w/4 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages virtualbox-ose depends on:
ii  adduser 3.105add and remove users and groups
ii  debconf [debconf-2.0]   1.5.18   Debian configuration management sy
ii  libc6   2.7-6GNU C Library: Shared libraries
ii  libgcc1 1:4.3-20080116-1 GCC support library
ii  libgl1-mesa-glx [libgl1 7.0.2-4  A free implementation of the OpenG
ii  libglib2.0-02.14.5-2 The GLib library of C routines
ii  libidl0 0.8.9-0.1library for parsing CORBA IDL file
ii  libqt3-mt   3:3.3.7-9Qt GUI Library (Threaded runtime v
ii  libsdl1.2debian 1.2.13-1 Simple DirectMedia Layer
ii  libstdc++6  4.3-20080116-1   The GNU Standard C++ Library v3
ii  libx11-62:1.0.3-7X11 client-side library
ii  libxalan110 1.10-3.1 Provides XSLT support for applicat
ii  libxcursor1 1:1.1.9-1X cursor management library
ii  libxerces27 2.7.0-5  validating XML parser library for 
ii  libxext61:1.0.3-2X11 miscellaneous extension librar
ii  libxt6  1:1.0.5-3X11 toolkit intrinsics library

Versions of packages virtualbox-ose recommends:
ii  virtualbox-ose-mod 1.5.4-dfsg-4+2.6.22-6 VirtualBox modules for Linux (kern

-- debconf information:
* virtualbox-ose/upstream_version_change: true



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

Bug#413283: Fails to install, so it is serious.

[Emilio Jesús Gallego Arias]

I've raised this bug severity per policy, as the missing dependency
breaks the package postinst whenever libghc6-mtl-dev is not installed,
like in a pbuilder chroot.

Regards,

Emilio


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

Bug#350515: I guess this bug is not fixed.

[Emilio Jesús Gallego Arias]

reopen #350515

thanks

With:

ii  planner-el   3.41-1personal information manager for 
Emacs
ii  emacs-snapshot-gtk   20060623-1The GNU Emacs editor (with GTK+ 
2.x support)

This bug keeps happening, but I actually have found its root.

The problem is present when the user hasn't loaded the planner
'planner-publish file and has a setup as suggested in the docs:

(setq muse-project-alist
  '((PlansWiki
 (~/my/Plans
  :default TaskPool 
  :major-mode planner-mode
  :visit-link planner-visit-link)
 (:base planner-xhtml
:path ~/my/Plans/Exported

Then the style parameter will be planner-xthml when
muse-style-run-hooks is called:

(defun muse-style-run-hooks (keyword style rest args)
  (let (handled)
(while (and style (not handled))
  (setq style (muse-style style))
  (let ((func (muse-get-keyword keyword style t)))
(if func
(if (apply func args)
(setq handled t
  (unless handled
(setq style (muse-style-element :base style
handled))

and muse-style 'planner-xhtml is nil, causing the function to loop
forever: style - planner-xhtml ; handled - false ; style - nil;
func - nil; handled - false ; style - planner-xthml; loop

Regards


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

Bug#353545: ITP: wormsofprey -- Worms like multiplayer, realtime game

[Emilio Jesús Gallego Arias]

Oya [EMAIL PROTECTED] writes:

 Package: wnpp 
 Severity: wishlist 
 * Package name    : wormsofprey

Are you aware of the Debian Games team?

http://wiki.debian.org/Games/Development

Regards,

Emilio

Bug#333438: Gtk2HS suggested changes.

[Emilio Jesús Gallego Arias]

Hi,

I saw your gtk2hs package in m.d.n and indeed it's very well done, but
I think you forgot to include the Cairo bindings, so I tried to fix that.

I think a very good improvement would be trying to build the package
with xulrunner, but maybe you're going to need upstream support for
this, and xulrunner hasn't gone yet through the new queue. For more
info see:

http://web.glandium.org/blog/?p=69
http://web.glandium.org/blog/?p=70

Attached is the interdiff between my changes and yours. Please kill
the changelog and firefox-dev usage.

diffstat gtk2hs-interdiff.patch 
 debian/libghc6-cairo-dev.install  |4 +++
 debian/libghc6-cairo-dev.postinst |   41 ++
 debian/libghc6-cairo-dev.prerm|   38 +++
 gtk2hs-0.9.10/debian/changelog|   13 
 gtk2hs-0.9.10/debian/control  |   26 ++--
 gtk2hs-0.9.10/debian/rules|2 -
 6 files changed, 121 insertions(+), 3 deletions(-)

Regards,

Emilio

--- gtk2hs-0.9.10/debian/control
+++ gtk2hs-0.9.10/debian/control
@@ -2,7 +2,7 @@
 Priority: optional
 Maintainer: Marco Tulio Gontijo e Silva [EMAIL PROTECTED]
 Uploaders: John Goerzen [EMAIL PROTECTED]
-Build-Depends: debhelper (= 4.1.0), autotools-dev, cdbs, ghc6, libglib2.0-dev, libgtk2.0-dev, libglade2-dev, libgconf2-dev, libgtksourceview-dev, mozilla-dev, haddock
+Build-Depends: debhelper (= 4.1.0), autotools-dev, cdbs, ghc6, libglib2.0-dev, libgtk2.0-dev, libglade2-dev, libgconf2-dev, libgtksourceview-dev, firefox-dev, haddock
 Standards-Version: 3.6.2
 Section: libdevel
 
@@ -50,6 +50,28 @@
  .
  Homepage: http://www.gtk2hs.org/
 
+Package: libghc6-cairo-dev
+Section: libdevel
+Architecture: any
+Depends: ghc6, libglib2.0-dev, libcairo2-dev, ${shlibs:Depends}, ${misc:Depends}
+Suggests: gtk2hs-doc (= ${Source-Version}), libghc6-glib-dev (= ${Source-Version}), libghc6-gtk-dev (= ${Source-Version}), libghc6-mogul-dev (= ${Source-Version}), libghc6-glade-dev (= ${Source-Version}), libghc6-sourceview-dev (= ${Source-Version}), libghc6-mozembed-dev (= ${Source-Version})
+Description: A GUI library for Haskell based on GTK (gtk2hs) -- Cairo bindings.
+ It features:
+  * Automatic memory management.
+  * Nearly complete coverage of the underlying Gtk+ library.
+  * Unicode support.
+  * Documentation.
+  * Support for Linux, Unix, MacOS X and Windows platforms.
+  * Bindings for several Gnome modules:
+- libglade for loading GUIs from xml files at run-time. This allows you to
+  design your user interface visually using the Glade user interface
+  builder.
+- GConf, Gnome's system for storing application preferences.
+- SourceView, a source code editor widget with syntax highlighting.
+  * Bindings for the Mozilla browser rendering engine.
+ .
+ Homepage: http://www.gtk2hs.org/
+
 Package: libghc6-gconf-dev
 Section: libdevel
 Architecture: any
@@ -141,7 +163,7 @@
 Package: libghc6-mozembed-dev
 Section: libdevel
 Architecture: any
-Depends: ghc6, libglib2.0-dev, libgtk2.0-dev, mozilla-dev, libghc6-glib-dev (= ${Source-Version}), libghc6-gtk-dev (= ${Source-Version}), ${shlibs:Depends}, ${misc:Depends}
+Depends: ghc6, libglib2.0-dev, libgtk2.0-dev, firefox-dev, libghc6-glib-dev (= ${Source-Version}), libghc6-gtk-dev (= ${Source-Version}), ${shlibs:Depends}, ${misc:Depends}
 Suggests: gtk2hs-doc (= ${Source-Version}), libghc6-gconf-dev (= ${Source-Version}), libghc6-mogul-dev (= ${Source-Version}), libghc6-glade-dev (= ${Source-Version}), libghc6-sourceview-dev (= ${Source-Version})
 Description: A GUI library for Haskell based on GTK (gtk2hs) -- Mozilla bindings
  It features:
--- gtk2hs-0.9.10/debian/rules
+++ gtk2hs-0.9.10/debian/rules
@@ -9 +9 @@
---enable-gconf --enable-sourceview --enable-mozilla --enable-docs
+--enable-gconf --enable-sourceview --enable-firefox --enable-docs --enable-cairo
--- gtk2hs-0.9.10/debian/changelog
+++ gtk2hs-0.9.10/debian/changelog
@@ -1,3 +1,16 @@
+gtk2hs (0.9.10-1.2) unstable; urgency=low
+
+  * Enable support for cairo bindings: new package libghc6-cairo-dev.
+
+ -- Emilio Jesús Gallego Arias [EMAIL PROTECTED]  Thu,  9 Feb 2006 08:53:12 +0100
+
+gtk2hs (0.9.10-1.1) unstable; urgency=low
+
+  * Change mozilla-dev to firefox-dev in debian/control.
+  * Change --enable-mozilla to --enable-firefox in debian/rules.
+
+ -- Emilio Jesús Gallego Arias [EMAIL PROTECTED]  Thu,  9 Feb 2006 07:06:02 +0100
+
 gtk2hs (0.9.10-1) unstable; urgency=low
 
   * New upstream version.
--- gtk2hs-0.9.10.orig/debian/libghc6-cairo-dev.install
+++ gtk2hs-0.9.10/debian/libghc6-cairo-dev.install
@@ -0,0 +1,3 @@
+debian/tmp/usr/lib/gtk2hs/cairo.package.conf usr/lib/libghc6-cairo-dev/
+debian/tmp/usr/lib/gtk2hs/libHScairo.a usr/lib/libghc6-cairo-dev/
+debian/tmp/usr/lib/gtk2hs/imports/cairo/* usr/lib/libghc6-cairo-dev/imports/
--- gtk2hs-0.9.10.orig/debian/libghc6-cairo-dev.postinst
+++ gtk2hs-0.9.10/debian/libghc6-cairo-dev.postinst
@@ -0,0 +1,41 @@
+#! /bin/sh
+# postinst

Bug#317893: Please don't include spamassassin support

[Emilio Jesús Gallego Arias]

Hi,

I would like the htdig support included, but I think that including
spamassassin support in mailman is not the rigth thing to do, as spam
should be handled by the MTA that receives mail for MailMan, such as
exim, etc... Handling it in Mailman is duplicating the effort IMHO.

Regards,

-- 
Emilio Jesús Gallego Arias [EMAIL PROTECTED]

Bug#293888: Severity is excessive

[Emilio Jesús Gallego Arias]

severity 293888 wishlist

thanks,

Hi!

I thinks grave severity is too much for this bug, as thinking about it
maybe clearsilver-dev is a placeholder ATM.

Regards

-- 
Emilio Jess Gallego Arias [EMAIL PROTECTED]

Bug#293574: acknowledged by developer (This isn't a bug)

[Emilio Jesús Gallego Arias]

reopen 293574
retitle 293574 clearsilver-dev depends on unavailable package clearsilver

thanks,

Hi again :)

Unfortunately, it seems that this bug it's not solved by changing
clearsilver-dev to depends on clearsilver, as clearsilver package is
not built by any source package anymore.

I've built clearsilver with the following results:

[EMAIL PROTECTED]:~/fuentes/debian/clearsilver$ ls -l *.deb
-rw-r--r--  1 emilio emilio  4502 2005-02-06 14:51 
clearsilver-dev_0.9.13-2_i386.deb
-rw-r--r--  1 emilio emilio 80602 2005-02-06 14:51 
python2.3-clearsilver_0.9.13-2_i386.deb
-rw-r--r--  1 emilio emilio  4402 2005-02-06 14:51 
python-clearsilver_0.9.13-2_all.deb

so no clearsilver package was built.

This is the output of grep-excuses:

clearsilver (- to 0.9.13-2)
Maintainer: Jesus Climent
Too young, only 0 of 5 days old
clearsilver-dev/alpha unsatisfiable Depends: clearsilver
clearsilver-dev/arm unsatisfiable Depends: clearsilver
clearsilver-dev/hppa unsatisfiable Depends: clearsilver
clearsilver-dev/i386 unsatisfiable Depends: clearsilver
clearsilver-dev/ia64 unsatisfiable Depends: clearsilver
clearsilver-dev/mips unsatisfiable Depends: clearsilver
clearsilver-dev/mipsel unsatisfiable Depends: clearsilver
clearsilver-dev/powerpc unsatisfiable Depends: clearsilver
clearsilver-dev/s390 unsatisfiable Depends: clearsilver
clearsilver-dev/sparc unsatisfiable Depends: clearsilver
Not considered


I think clearsilver-dev should depend on python-clearsilver.

Regards, 

Emilio



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

Bug#293880: FTBFS: Should disable mono bindings.

[Emilio Jesús Gallego Arias]

Subject: FTBFS: Should disable mono bindings.
Package: clearsilver
Severity: serious
Justification: no longer builds from source

tags +patch

Hi!

I tried to build clearsilver on my host, and got a FTBFS:

gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -fPIC -I../ -I/usr/include/python2.3 -c neo_cgi.c -o
build/temp.linux-i686-2.3/neo_cgi.o
gcc -pthread -shared build/temp.linux-i686-2.3/neo_cgi.o
build/temp.linux-i686-2.3/neo_cs.o build/temp.linux-i686-2.3/neo_util.o
-L../libs -lz -lneo_cgi -lneo_cs -lneo_utl -o neo_cgi.so
make[2]: Leaving directory
`/home/emilio/fuentes/debian/clearsilver/clearsilver-0.9.13/build-tree/clearsilver-0.9.13/python'
make[2]: Entering directory
`/home/emilio/fuentes/debian/clearsilver/clearsilver-0.9.13/build-tree/clearsilver-0.9.13/dso'
/usr/bin/ld  -rpath ../libs -shared -o libneo.so
-whole-archive ../libs/libneo_cgi.a ../libs/libneo_cs.a ../libs/libneo_utl.a 
-no-whole-archive -lz -L../libs/
gcc -o dsotest dsotest.c -lneo -L. -I..
make[2]: Leaving directory
`/home/emilio/fuentes/debian/clearsilver/clearsilver-0.9.13/build-tree/clearsilver-0.9.13/dso'
make[2]: Entering directory
`/home/emilio/fuentes/debian/clearsilver/clearsilver-0.9.13/build-tree/clearsilver-0.9.13/csharp'
/usr/bin/mcs -target:library --unsafe CS.cs -out:clearsilver.dll
CS.cs(84) error CS0214: Pointers may only be used in an unsafe context
Compilation failed: 1 error(s), 0 warnings
make[2]: *** [clearsilver.dll] Error 1
make[2]: Leaving directory
`/home/emilio/fuentes/debian/clearsilver/clearsilver-0.9.13/build-tree/clearsilver-0.9.13/csharp'
make[1]: *** [cs] Error 2
make[1]: Leaving directory
`/home/emilio/fuentes/debian/clearsilver/clearsilver-0.9.13/build-tree/clearsilver-0.9.13'
make: *** [debian/stamp-makefile-build] Error 2

This is caused because I have mono-dev installed and configure tried to
build mono bindings, which seem broken.

The workaround is to disable mono bindings:

--- rules.old   2005-02-06 15:06:07.557676648 +0100
+++ rules   2005-02-06 14:50:12.671841360 +0100
@@ -10,6 +10,7 @@

 DEB_CONFIGURE_EXTRA_FLAGS := --with-python=/usr/bin/python2.3 \
  --disable-perl \
+ --disable-csharp \
  --disable-ruby \
  --disable-apache \
  --enable-gettext

Regards and thank you for taking care of this,

Emilio


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.10
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)



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

Bug#293888: Acknowledgement (clearsilver-dev package is empty)

[Emilio Jesús Gallego Arias]

tag +patch

thanks,

Hi, I've made an install file for clearsilver-dev, but I think it's not
ok, because you only package the python bindings:

--- /dev/null   2005-02-06 11:13:22.673574392 +0100
+++ clearsilver-dev.install 2005-02-06 18:19:48.597010136 +0100
@@ -0,0 +1,4 @@
+debian/tmp/usr/include usr/
+debian/tmp/usr/lib/*.a usr/lib/
+debian/tmp/usr/share/man   usr/share
+debian/tmp/usr/bin usr

so:
- Should install /usr/bin? I think not, as this should go into some
clearsilver binary package.

- Should install /usr/share/man? I think yes, as the manual pages
probably match with the python bindings, but this documentation is for c
functions.

- Should install /usr/lib/*.a? Don't know.

- Should install /usr/include? It seems that all of these are .h files,
so I don't know if these can be of any use for python.

If I'm totally wrong because all of this should go when clearsilver c
bindings are packaged,  please kill this bug as appropriate.

Regards,

Emilio

Bug#293574: acknowledged by developer (This isn't a bug)

[Emilio Jesús Gallego Arias]

reopen 293574
retitle 293574 clearsilver-dev depends on unavailable package clearsilver1
severity 293574 serious

thanks,


 Since this isn't a bug in software I'm closing it.
 
 When you want to talk with the maintainers you can send a mail to
 package@packages.qa.debian.org or send a mail directly for one of
 us.
 
 Thanks by your interest.

Thank you very much taking care of this, but as I've seen in when you
asked on -release, this is serious bug in clearsilver.

Regards, 

Emilio



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