Bug#770171: closed by Debian FTP Masters (reply to Sylvestre Ledru ) (Bug#770171: fixed in fail2ban 1.0.2-3)

[Luca Capello]

found 770171 1.0.2-2
tags 770171 + upstream
forwarded 770171 https://github.com/fail2ban/fail2ban/issues/1372
user l...@pca.it
usertags 770171 + pca.it-security
thanks

Hi there,

I just got hit by this as well, plus the nftables issue:

  

On Tue, 02 Jan 2024 19:39:13 +, Debian Bug Tracking System wrote:
> Changes:
>  fail2ban (1.0.2-3) unstable; urgency=medium
>  .
>* Add banaction = nftables in the defaults-debian.conf default
>  see 
> https://github.com/fail2ban/fail2ban/discussions/3575#discussioncomment-7045315
>* Move python3-systemd as depend (Closes: #770171, #1037437)
>* Add backend = systemd to jail.d/defaults-debian.conf

The commit corresponding to the last line is:

  


For those waiting the fixed pacakge, without touching any other
packaged file I can confirm that `apt-get install python3-systemd`
plus the below `jail.local` are enough to get `fail2ban` starts on a
fresh Debian 12.4/bookworm:
```
[DEFAULT]
### 
banaction = nftables
banaction_allports = nftables[type=allports]
### 
backend = systemd
```

Thx, bye,
Gismo / Luca

PS, the upstream bug is quite interesting, especially to understand the
differences between `(|*_)backend`:

  


signature.asc
Description: PGP signature

Bug#1056360: python3-wikitrans: [wikimarkup.py] 'str' object has no attribute 'decode'

[Luca Capello]

Package: python3-wikitrans
Version: 1.3-2
Severity: grave
Control: affects -1 dico-module-mediawiki
Usertags: pca.it-communication

Hi there,

after the dicod's `load python`[1] and `M4 quoting`[2], querying the
WikiMedia databases gives no match and the following errors in `dicod`:
```
root@harlock:~# /usr/bin/dicod --stderr -f
dicod: Info: dicod (GNU dico) 2.11 started
dicod: Info: Client info: "GNU dico 2.11"
dicod: Info: Client info: "GNU dico 2.11"
dicod: Debug: 57843 exited successfully
dicod: Info: Client info: "GNU dico 2.11"
dicod: Error: Traceback (most recent call last):
dicod: Error:   File "/usr/share/dico/python/mediawiki.py", line 98, in 
define_word
dicod: Error: wikiparser = TextWiktionaryMarkup (text=data)
dicod: Error:  
dicod: Error:   File "/usr/lib/python3/dist-packages/wikitrans/wiki2text.py", 
line 278, in __init__
dicod: Error: super(TextWikiMarkup, self).__init__(*args, **keywords)
dicod: Error:   File "/usr/lib/python3/dist-packages/wikitrans/wikimarkup.py", 
line 1028, in __init__
dicod: Error: self.text = keywords[kw].decode('utf-8').split("\n")
dicod: Error: ^^^
dicod: Error: AttributeError: 'str' object has no attribute 'decode'. Did you 
mean: 'encode'?
dicod: Debug: 57846 exited successfully
dicod: Debug: 57847 exited successfully
^Cdicod: Info: dicod (GNU dico) 2.11 terminating
root@harlock:~# 
```

[1] 
[2] 

I am not a Python expert, the problem obviously disappears (and the
query succeeds) if I remove the conditional case at line 1027, which
seems bad to me since AFAIK only from Python3 `str` contains by
default UTF-8/Unicode characters[3] (and anyway user input could not
be in UTF-8):
```
elif kw == 'text':
if sys.version_info[0] > 2:
self.text = keywords[kw].decode('utf-8').split("\n")
else:
self.text = keywords[kw].split("\n")
```

[3] 

Thx, bye,
Gismo / Luca

-- System Information:
Debian Release: 12.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldoldstable'), (500, 
'stable'), (500, 'oldstable'), (100, 'bookworm-fasttrack'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-0.deb12.1-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-wikitrans depends on:
ii  python3  3.11.2-1+b1

python3-wikitrans recommends no packages.

python3-wikitrans suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#860602: ruby-net-ldap: FTBFS: ERROR: Test "ruby2.3" failed.

[Luca Capello]

tags 860602 + confirmed
tags 860602 + upstream
tags 860602 + patch
thanks

Hi,

On Wed, Apr 19, 2017 at 08:13:46AM +0200, Lucas Nussbaum wrote:
> Source: ruby-net-ldap
> Version: 0.12.1-1
> Severity: serious

Actually, this severity is questionable, the bug is not in the *build*
process, but in the *test* suite.  For the rationale, see:

  <https://lists.debian.org/871t0vzneq@hope.eyrie.org>

> Tags: stretch sid

We tested this on a clean sid chroot as well with *no* network during
the GULL BSP:

  <http://www2.linux-gull.ch/?q=node/23>

> Relevant part (hopefully):
> > /usr/bin/ruby2.3 /usr/bin/gem2deb-test-runner
> > 
> > ┌──┐
> > │ Run tests for ruby2.3 from debian/ruby-test-files.yaml
> >│
> > └──┘
> > 
> > RUBYLIB=/<>/debian/ruby-net-ldap/usr/lib/ruby/vendor_ruby:. 
> > GEM_PATH=debian/ruby-net-ldap/usr/share/rubygems-integration/all:/var/lib/gems/2.3.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.3.0:/usr/share/rubygems-integration/2.3.0:/usr/share/rubygems-integration/all
> >  ruby2.3 -ryaml -e YAML.load_file\(\"debian/ruby-test-files.yaml\"\).each\ 
> > \{\ \|f\|\ require\ f\ \}
> > Loaded suite -e
> > Started
> > ..Deprecation warning: 
> > Net::LDAP::ConnectionRefused will be deprecated. Use Errno::ECONNREFUSED 
> > instead.
> > .Deprecation warning: Net::LDAP::ConnectionRefused will be deprecated. Use 
> > Errno::ECONNREFUSED instead.
> > Deprecation warning: Net::LDAP::ConnectionRefused will be deprecated. Use 
> > Errno::ECONNREFUSED instead.
> > Deprecation warning: Net::LDAP::ConnectionRefused will be deprecated. Use 
> > Errno::ECONNREFUSED instead.
> > Deprecation warning: Net::LDAP::ConnectionRefused will be deprecated. Use 
> > Errno::ECONNREFUSED instead.
> > F
> > ===
> > Failure: test_unresponsive_host(TestLDAPConnection)
> > /<>/test/test_ldap_connection.rb:64:in `test_unresponsive_host'
> >  61:   end
> >  62: 
> >  63:   def test_unresponsive_host
> >   => 64: assert_raise Net::LDAP::Error do
> >  65:   Net::LDAP::Connection.new(:host => 'test.mocked.com', :port 
> > => 636)

test.mocked.com does not respond on port 636:
=
rescue@debian:~$ ldapsearch -x -H ldaps://test.mocked.com
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
rescue@debian:~$ 
=

There are different solutions:

1) uncomment "export DH_RUBY_IGNORE_TESTS=all" in debian/rules

2) add "export RES_OPTIONS=attempts:0" do debian/rules, as per

 <https://lists.debian.org/20160929205427.4ormkscfms5gm...@jwilk.net>

3) comment test/test_ldap_connection.rb in debian/ruby-test-files.yaml
   (this seems the best solution)

However, even with network access and DNS resolution, the test does not
behave the same if the connection to test.mocked.com is possible or not.
This can be tested via `iptables -I OUTPUT -p tcp -m tcp -d
test.mocked.com -j $ACTION`:

* DROP, the test does not fail
* REJECT, the test fails

Nevertheless, if no one replies in 7 days, I will upload an NMU with the
solution 3 above (Git patch attached).

Thx, bye,
Gismo / Luca
>From 5e1b2c167c4608110461b10d46c91ba8bf9ee63b Mon Sep 17 00:00:00 2001
From: Luca Capello 
Date: Thu, 20 Apr 2017 23:56:23 +0200
Subject: [PATCH] debian/ruby-test-files.yaml: (#860602) comment LDAP

Signed-off-by: Luca Capello 
---
 debian/changelog| 7 +++
 debian/ruby-test-files.yaml | 3 ++-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index d7c96dc..351daed 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+ruby-net-ldap (0.12.1-2) UNRELEASED; urgency=medium
+
+  * debian/ruby-test-files:
++ comment test/test_ldap_connection.rb (Closes: #860602).
+
+ -- 
+
 ruby-net-ldap (0.12.1-1) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/ruby-test-files.yaml b/debian/ruby-test-files.yaml
index 1db6484..d5874e5 100644
--- a/debian/ruby-test-files.yaml
+++ b/debian/ruby-test-files.yaml
@@ -1,7 +1,8 @@
 --- 
 - test/test_entry.rb
 - test/test_filter.rb
-- test/test_ldap_connection.rb
+## <https://bugs.debian.org/860602>
+#- test/test_ldap_connection.rb
 - test/test_ldif.rb
 - test/test_password.rb
 - test/test_rename.rb
-- 
2.1.4

Bug#808433: nethogs STILL crashes in STABLE (Jessie), two months after bug was closed

[Luca Capello]

fixed 808433 0.8.1-1~bpo8+1
user product...@infomaniak.com
usertag 808433 + infomaniak.com-network
thanks

Hi there,

On Sun, 12 Jun 2016 10:01:20 +0200, S. G. wrote:
> I'm desparately waiting to see this fix in jessie.
> 
> Is there a schedule for patching 0.8.0?

No need for a jessie-pu, the problem is fixed for us using the
jessie-backports package (bug updated).

Thx, bye,
Gismo / Luca

-- 
Luca Capello
Administrateur GNU/Linux

Infomaniak Network SA


signature.asc
Description: Digital signature

Bug#701684: [Pkg-libvirt-maintainers] Bug#701684: virt-viewer no longer contains virt-viewer

[Luca Capello]

Hi there!

On Wed, 24 Apr 2013 04:13:24 +0200, Guido Günther wrote:
> On Tue, Apr 23, 2013 at 03:00:54PM +0200, Luca Capello wrote:
>> On Thu, 18 Apr 2013 08:22:39 +0200, Guido Günther wrote:
>> > It's fixed now in sid. I'm sorry for the long delay.
>> 
>> No problem, and actually I am grateful to you for the notice.
>> 
>> Nevertheless, I now get a segfault and since restarting libvirt-bin does
>> not change anything I removed the fixed tag:
[...]
> Which is wired since it works here and the log lines before the crash
> look the same. Could you attach a gdb backtrace?

A quick note: 0.5.5+really0.5.4-1 works in a sid schroot with
libvirt0_1.0.4-1 via SSH.  I will investigate a bit more and come back.

Thx, bye,
Gismo / Luca


pgpoAaYOpgArS.pgp
Description: PGP signature

Bug#701684: [Pkg-libvirt-maintainers] Bug#701684: virt-viewer no longer contains virt-viewer

[Luca Capello]

notfixed 701684 0.5.5+really0.5.4-1
thanks

Hi there!

On Thu, 18 Apr 2013 08:22:39 +0200, Guido Günther wrote:
> On Sun, Mar 03, 2013 at 06:46:04PM +0100, Luca Capello wrote:
>> On Thu, 28 Feb 2013 08:31:22 +0100, Guido Günther wrote:
>> > On Mon, Feb 25, 2013 at 10:54:41PM -0700, Bob Proulx wrote:
>> >> After upgrading from yesterday's 0.5.4-1 to today's 0.5.5-3 the
>> >> virt-viewer program has disappeared from the system.
>> >> 
>> >>   # dpkg -L virt-viewer | grep bin/virt-viewer
>> >>   ...nothing...
>> >> 
>> >> Installing the previous 0.5.4-1 restored it and worked around the
>> >> problem.
>> > This is caused by a too old libvirt in sid. We're also lacking a newer
>> > spice-gtk to fix this in a at least experimental (#700562 ). In case
>> > this doesn't get uploaded soonish we'll need to revert the version in
>> > sid.
>> 
>> I just got it by this bug as well and IMHO the current solution
>> (upgrading to the versions in experimental) is not fine: virt-viewer in
>> sid is still broken and, after having visited the bug report, there is
>> no ETA for a fixed version in sid.
>> 
>> BTW, I know I am complaining without helping, but I am currently lacking
>> time for my work as well :-(
>
> It's fixed now in sid. I'm sorry for the long delay.

No problem, and actually I am grateful to you for the notice.

Nevertheless, I now get a segfault and since restarting libvirt-bin does
not change anything I removed the fixed tag:
=
$ dpkg-query -W \*virt\*
java-virtual-machine
libvirt-bin 0.9.12-11
libvirt00.9.12-11
python-libvirt  0.9.12-11
python-virtualenv
python2.6-libvirt
python2.7-libvirt
virt-viewer 0.5.5+really0.5.4-1
virt-what   1.12-1
virtinst0.600.3-3
$ virsh -c qemu:///system list
 IdName   State

 1 gismo-xp.pca.itrunning

$ virt-viewer --debug -c qemu:///system gismo-xp.pca.it
(virt-viewer:5470): virt-viewer-DEBUG: Insert window 0 0xd19050
(virt-viewer:5470): virt-viewer-DEBUG: fullscreen display 0: 0
(virt-viewer:5470): virt-viewer-DEBUG: fullscreen display 0: 0
(virt-viewer:5470): virt-viewer-DEBUG: Opening connection to libvirt with URI 
qemu:///system
n
(virt-viewer:5470): virt-viewer-DEBUG: Add handle 7 1 0xde5780
(virt-viewer:5470): virt-viewer-DEBUG: Add timeout 0xde5300 -1 0x7fccd2366590 
0xde55d0 1
(virt-viewer:5470): virt-viewer-DEBUG: notebook show status 0xd1a010
(virt-viewer:5470): virt-viewer-DEBUG: notebook show status 0xd1a010
(virt-viewer:5470): virt-viewer-DEBUG: Guest gismo-xp.pca.it is running, 
determining display

(virt-viewer:5470): virt-viewer-DEBUG: Set connect info: 
(null),(null),(null),-1,(null),(null),(null),0
(virt-viewer:5470): virt-viewer-DEBUG: Guest gismo-xp.pca.it has a vnc display

Segmentation fault

$ tail /var/log/libvirt/qemu/gismo-xp.pca.it.log 
2013-04-23 12:52:25.979+: starting up
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin 
HOME=/ QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -enable-kvm -m 512 -smp 
1,sockets=1,cores=1,threads=1 -name gismo-xp.pca.it -uuid 
a26627e3-0a36-dc27-edd0-f9ccc57f7bc7 -no-user-config -nodefaults -chardev 
socket,id=charmonitor,path=/var/lib/libvirt/qemu/gismo-xp.pca.it.monitor,server,nowait
 -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime 
-no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive 
file=/var/lib/libvirt/images/gismo-xp.pca.it.img,if=none,id=drive-virtio-disk0,format=qcow2
 -device 
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw -device 
ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev 
tap,fd=20,id=hostnet0,vhost=on,vhostfd=21 -device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:74:ce:8b,bus=pci.0,addr=0x3 
-chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 
-device usb-tablet,id=input0 -vnc 127.0.0.1:0 -vga std -device 
AC97,id=sound0,bus=pci.0,addr=0x4 -device 
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6
char device redirected to /dev/pts/6

$ tail /var/log/libvirt/libvirtd.log
2013-04-18 15:08:18.988+: 2771: error : qemuMonitorIO:612 : internal error 
End of file from monitor
2013-04-18 15:08:19.107+: 2771: error : virNetSocketReadWire:991 : Cannot 
recv data: Connection reset by peer
2013-04-18 17:47:15.289+: 2771: error : qemuMonitorIO:612 : internal error 
End of file from monitor
2013-04-18 17:47:15.337+: 2771: error : virNetSocketReadWire:991 : Cannot 
recv data: Connection reset by peer
2013-04-23 12:52:26.842+: 2724: info : libvirt version: 0.9.12
2013-04-23 12:52:26.842+: 2724:

Bug#701684: [Pkg-libvirt-maintainers] Bug#701684: virt-viewer no longer contains virt-viewer

[Luca Capello]

Hi there!

On Thu, 28 Feb 2013 08:31:22 +0100, Guido Günther wrote:
> On Mon, Feb 25, 2013 at 10:54:41PM -0700, Bob Proulx wrote:
>> After upgrading from yesterday's 0.5.4-1 to today's 0.5.5-3 the
>> virt-viewer program has disappeared from the system.
>> 
>>   # dpkg -L virt-viewer | grep bin/virt-viewer
>>   ...nothing...
>> 
>> Installing the previous 0.5.4-1 restored it and worked around the
>> problem.
> This is caused by a too old libvirt in sid. We're also lacking a newer
> spice-gtk to fix this in a at least experimental (#700562 ). In case
> this doesn't get uploaded soonish we'll need to revert the version in
> sid.

I just got it by this bug as well and IMHO the current solution
(upgrading to the versions in experimental) is not fine: virt-viewer in
sid is still broken and, after having visited the bug report, there is
no ETA for a fixed version in sid.

BTW, I know I am complaining without helping, but I am currently lacking
time for my work as well :-(

On a side note, the debian/changelog is a bit empty WRT the reasons for
new uploads since 0.5.4-1 (and #684725 has not marked as fixed), which
means that apt-listchanges for virt-viewer is useless:

--8<---cut here---start->8---
virt-viewer (0.5.5-3) unstable; urgency=low

  * New upload

 -- Laurent Léonard   Sun, 24 Feb 2013 19:45:49 +0100

virt-viewer (0.5.5-2) unstable; urgency=low

  * New upload

 -- Laurent Léonard   Sun, 24 Feb 2013 16:53:02 +0100

virt-viewer (0.5.5-1) unstable; urgency=low

  * [5bf850a] Imported Upstream version 0.5.5 (Closes: #684725)

 -- Laurent Léonard   Wed, 20 Feb 2013 23:20:54 +0100

virt-viewer (0.5.4-1) unstable; urgency=low

  * [e3fbded] Imported Upstream version 0.5.4
  * [43b4d1e] Remove LDFLAGS override

 -- Laurent Léonard   Mon, 17 Sep 2012 23:09:48 +0200
--8<---cut here---end--->8---

Thx, bye,
Gismo / Luca


pgpGUVud5qqxY.pgp
Description: PGP signature

Bug#697373: colorhug-client: must Depends: on librsvg2-common for SVG loading

[Luca Capello]

tags 697373 + patch
thanks

Hi there!

On Fri, 04 Jan 2013 15:22:51 +0100, Luca Capello wrote:
> I will provide a Git patch as soon as this bug gets its number.  IMHO
> this deserves a wheezy unblock, I will be glad to do an NMU and contact
> the RM, if needed.

Here we are, attached the Git, to be applied after the one at:

  <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697364#10>

Thx, bye,
Gismo / Luca

From a7a6dc9e74f7450c0dc089aa5005ff7ba73dcd47 Mon Sep 17 00:00:00 2001
From: Luca Capello 
Date: Fri, 4 Jan 2013 15:51:42 +0100
Subject: [PATCH 2/2] debian/control: (#697373) add Depends: on
 librsvg2-common

---
 debian/changelog |3 +++
 debian/control   |2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index e73de96..b2c33af 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,5 +1,8 @@
 colorhug-client (0.1.12-2) UNRELEASED; urgency=low
 
+  * debian/control:
++ colorhug-client must Depends: on librsvg2-common, which ships
+  the gdk-pixbuf loader for SVG icons (Closes: #697373).
   * debian/libcolorhug1.udev:
 + always set ownership to plugdev group, since relying on
   ConsoleKit only is not enough (Closes: #697364).
diff --git a/debian/control b/debian/control
index 6223c47..5cea973 100644
--- a/debian/control
+++ b/debian/control
@@ -24,7 +24,7 @@ Vcs-Browser: http://git.debian.org/?p=collab-maint/colorhug-client.git;a=summary
 
 Package: colorhug-client
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}, librsvg2-common
 Suggests: gnome-color-manager, argyll
 Description: Tools for the Hughski Colorimeter
  The Hughski ColorHug colorimeter is a low cost open-source hardware
-- 
1.7.10.4



pgpURIC3qo7Re.pgp
Description: PGP signature

Bug#697373: colorhug-client: must Depends: on librsvg2-common for SVG loading

[Luca Capello]

Package: colorhug-client
Version: 0.1.11-1
Severity: serious
Usertags: debian-packaging

Hi there!

After having got access to my ColorHug (see #697364), I followed the
instructions provided by the producer and got some errors:
=
$ colorhug-cmd set-leds 1 5 200 200 && echo OK
OK

$ colorhug-flash && echo OK
**
Ch:ERROR:ch-flash.c:1366:ch_flash_startup_cb: assertion failed: (pixbuf != NULL)
Aborted
=

I have also tried with the version in experimental (0.1.12-1), with the
same failures.  BTW, upstream has released 0.1.13:

  

The error is generated from the code below:

--8<---cut here---start->8---
/* setup USB image */
widget = GTK_WIDGET (gtk_builder_get_object (priv->builder, 
"image_usb"));
pixbuf = gdk_pixbuf_new_from_file_at_scale (CH_DATA
G_DIR_SEPARATOR_S "icons"
G_DIR_SEPARATOR_S "usb.svg",
-1, 48, TRUE, &error);
g_assert (pixbuf != NULL);
--8<---cut here---end--->8---

However, /usr/share/colorhug-client/icons/usb.svg exist and it is
accessible, as strace shown.

Since on my real sid I use 'APT::Install-Recommends "false"' and
colorhug-flash started finely on a chroot with recommends on, I started
checking the different packages.  What helped me was:

  

Indeed, libpixbufloader-svg.so is shipped by librsvg2-common: installing
it on my real sid solved the error.

I will provide a Git patch as soon as this bug gets its number.  IMHO
this deserves a wheezy unblock, I will be glad to do an NMU and contact
the RM, if needed.

Thx, bye,
Gismo / Luca

-- System Information:
Debian Release: 7.0
  APT prefers unstable
  APT policy: (990, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages colorhug-client depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.12.1-3
ii  libatk1.0-0  2.4.0-2
ii  libc62.13-38
ii  libcairo-gobject21.12.2-2
ii  libcairo21.12.2-2
ii  libcanberra-gtk3-0   0.28-6
ii  libcanberra0 0.28-6
ii  libcolord1   0.1.21-4
ii  libcolorhug1 0.1.11-1
ii  libgdk-pixbuf2.0-0   2.26.1-1
ii  libglib2.0-0 2.33.12+really2.32.4-3
ii  libgtk-3-0   3.4.2-4
ii  libgusb2 0.1.3-5
ii  libpango1.0-01.30.0-1
ii  libsoup2.4-1 2.38.1-2
ii  libusb-1.0-0 2:1.0.12-2

colorhug-client recommends no packages.

Versions of packages colorhug-client suggests:
pn  argyll   
pn  gnome-color-manager  

-- no debconf information


pgp7VxFNgXqPw.pgp
Description: PGP signature

Bug#689221: installation-reports: QNAP TS-409U does not reboot after installation

[Luca Capello]

Hi there!

On Tue, 16 Oct 2012 00:05:59 +0200, Luca Capello wrote:
> On Mon, 08 Oct 2012 23:12:33 +0200, Luca Capello wrote:
>> At the next reboot mdadm does not segfault anymore, so at least this
>> problem is fixed in 3.2.5-3~bpo60+1, it could be related to:
>>
>>   <http://bugs.debian.org/621786>
>
> I am quite sure I got it by this one, I do not know why I have not
> completely read it the first time, it would have saved me quite a lot of
> tests...
>
> Cc:ing all the persons involved in that bug: Arnaud, I would try
> mdadm_3.2.5-3~bpo60+1 (from backports, and a more recent kernel just to
> be sure).  If we experience the same bug that should be solve it.
[...]
> I will prepare a d-i network-console based on 20110106+squeeze4+b1 plus
> mdadm_3.2.5-3~bpo60+1 and try again the full installation next Sunday
> 21st: if everything goes well, I will close this bug :-)

Summary: installing mdadm_3.2.5-3~bpo60+1 *before* rebooting allow a
normal boot into the new installed system, so I guess this bug is fixed.

The long story is that it was even easier, because the backports udeb
was already available, so I used it with the following procedure:

1) flash d-i
2) ssh installer@IP
3) start 'basic mode'
4) at 'Select a language' screen -> Go back
5) execute a shell
=
~ # wget 
http://ftp.de.debian.org/debian-backports/pool/main/m/mdadm/mdadm-udeb_3.2.5-3~bpo60+1_armel.udeb
~ # udpkg -i mdadm-udeb_3.2.5-3~bpo60\+1_armel.udeb 
~ # exit
=
6) continue installation (no more segfaults)
7) manual partitioning (the same layout as the first try, thus without
   recreating the RAID-5, but reusing it)
8) installation continued, but at "Configure mdadm" and "Flash
   kernel..." there were segfaults (mdadm from within the target, thus
   the squeeze version, not from backports)
9) installation finished -> Go back
10) execute a shell
=
~ # mount /sys/ /target/sys/ -o bind
~ # mount /proc/ /target/proc/ -o bind
~ # chroot /target /bin/bash
root@jem:/# mv /etc/mdadm/mdadm.conf{,.squeeze}
[missing ARRAY entry]
root@jem:/# echo "deb http://backports.debian.org/debian-backports 
squeeze-backports main" >>/etc/apt/sources.list
root@jem:/# apt-get update
root@jem:/# apt-get -t squeeze-backports install mdadm
Preparing to replace mdadm 3.1.4-1+8efb9d1+squeeze1 (using 
.../mdadm_3.2.5-3~bpo60+1_armel.deb) ...
[...]
Generating mdadm.conf... done.
update-initramfs: deferring update (trigger activated)
Generating udev events for MD arrays...done.
Starting MD monitoring service: mdadm --monitor.
Processing triggers for initramfs-tools ...
update-initramfs: Generating /boot/initrd.img-2.6.32-5-orion5x
Generating kernel u-boot image... done.
Flashing kernel... done.
Flashing initramfs... done.
root@jem:/#
=
11) now finish the installation, reboot and enjoy, finally!

Please note that I previously reported a kernel panic at the first
reboot after having installed mdadm from backports.  Well, it happened
again but on a random basis, which seems to correlated with other
segfaults I experienced:
=
root@jem:/etc# apt-get install etckeeper
[...]
Selecting previously deselected package etckeeper.
Unpacking etckeeper (from .../etckeeper_0.48_all.deb) ...
Selecting previously deselected package rsync.
Unpacking rsync (from .../rsync_3.0.7-2_armel.deb) ...
Processing triggers for man-db ...
locale: Cannot set LC_ALL to default locale: No such file or directory
Setting up libcurl3-gnutls (7.21.0-2.1+squeeze2) ...
Segmentation fault
dpkg: error processing libcurl3-gnutls (--configure):
 subprocess installed post-installation script returned error exit status 139
[...]
root@jem:/etc# git status
error: corrupt loose object '1ef26ebf2691cf6b09a55a2a10a02ff7634f3b24'
fatal: object 1ef26ebf2691cf6b09a55a2a10a02ff7634f3b24 is corrupted
root@jem:/etc# git log
commit 361404b10074730c1710edc5bef5c06a332872e9
Author: root 
Date:   Mon Oct 22 19:08:44 2012 +0200

Initial commit
root@jem:/etc# apt-get install screen
[...]
Setting up screen (4.0.3-14+b1) ...
fatal: object 49111c287d678ddd1148f8c9832625036e0aef33 is corrupted
[master E: Problem executing scripts DPkg::Post-Invoke 'if [ -x 
/usr/sbin/etckeeper ]; then etckeeper post-install; fi'
E: Sub-process returned an error code
root@jem:/etc# apt-get --reinstall install screen
[...]
Setting up screen (4.0.3-14+b1) ...
[master 01881cc] committing changes in /etc after apt run
 Committer: root 
[...]
 1 files changed, 1 insertions(+), 1 deletions(-)
root@jem:/etc#
=

The various segfaults could be related to the RAID-5 being repaired,
given that RAIDs are created in a degrade state:
=
root@jem:/etc# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sda1[0] sdd1[3] sdc1[2] sdb1[1]
  5860538880 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] []
  [>]  resync =  3.2% (

Bug#599188: [Fingerforce-devel] Bug#599188: Blocking dummy bug for squeeze release remotion [pam-fprint]

[Luca Capello]

reassign 599188 ftp.debian.org
retitle 599188 RM: pam-fprint -- ROM; dead upstream, replaced by libpam-fprintd
severity 599188 normal
usertags 599188 + debian-packaging
thanks

Hi there!

On Tue, 13 Mar 2012 16:37:51 -0600, Luca Capello wrote:
> So, basically, we should move to fprintd (and pam-fprintd).  When this
> will happen, however, is still unknown.  If needed, I am all in favor of
> a complete removal of pam-fprint.

Here we are, given that pam-fprintd has been in the archive since
2012-05-21.

About the bugs present in pam-fprint:

  #469059: reassigned to libpam-fprintd
  #578858: to be closed with the removal (pam-fprintd works fine)
  #597285: reassigned to libpam-fprintd
  #606381: to be closed with the removal (pam-fprintd stores
   fingerprints in /var/lib/fprint/)
  #633633: to be closed with the removal (pam-fprintd supports that
   device)

Thx, bye,
Gismo / Luca


pgpGEBE4D2CdQ.pgp
Description: PGP signature

Bug#677700: [pkg-bacula-devel] Bug#677700: bacula-director-mysql: fails to upgrade from testing - Table 'bacula.Version' doesn't exist

[Luca Capello]

Hi there!

On Sun, 24 Jun 2012 15:52:43 +0200, Luca Capello wrote:
> This is caused by the fact that there is no MySQL server running yet.
> While this could be solved via a Pre-Depends: in bacula-director-mysql,
> this is actually not possible because the MySQL server could be on a
> remote location.  BTW, this happens to bacula-director-pgsql, too.

I just got it again by this while testing the squeeze-backports package.
At least I discovered that the above was already discussed in #605449.

Thx, bye,
Gismo / Luca


pgpJFAiVktrTr.pgp
Description: PGP signature

Bug#677700: [pkg-bacula-devel] Bug#677700: bacula-director-mysql: fails to upgrade from testing - Table 'bacula.Version' doesn't exist

[Luca Capello]

Hi there!

On Sun, 24 Jun 2012 19:04:19 +0200, Adam D. Barratt wrote:
> On Sun, 2012-06-24 at 15:52 +0200, Luca Capello wrote:
>> On Sat, 16 Jun 2012 11:49:34 +0200, Andreas Beckmann wrote:
>> > during a test with piuparts I noticed your package fails to upgrade from
>> > 'wheezy'.
>> > It installed fine in 'wheezy', then the upgrade to 'sid' fails.
>> 
>> Actually, I was not able to install bacula-director-mysql_5.0.3-1+b1 on
>> a clean wheezy (CD-1_20120618-04:55; d-i_20120508) with the default
>> mysql-server, i.e. 5.5:
>
> Andreas's log also shows that failure:
[...]
> I'm therefore marking the bug as found in the version in testing, as
> trying to install that on a current wheezy will already fail.  (The
> offending syntax appears to be fixed in a mysql-5.5 patch in bacula
> 5.2.)

Thank you for the notice, I did not completely read Andreas's log, my
fault.

> If anyone has a /working/ 5.0.3 install that they could try upgrading to
> 5.2.6, that would be helpful, just to confirm.

FWIW I have already planned to test that during DebCamp.

Thx, bye,
Gismo / Luca


pgpPYUnT6KvSF.pgp
Description: PGP signature

Bug#677700: [pkg-bacula-devel] Bug#677700: bacula-director-mysql: fails to upgrade from testing - Table 'bacula.Version' doesn't exist

[Luca Capello]

affects 677057 + bacula
usertags 677700 + debian-packaging
thanks

Hi Andreas!

IMHO bacula-director-mysql_5.2.6+dfsg-1 is not broken at all, but
leaving Severity: to serious and Cc:ing debian-release@ for an advice.

On Sat, 16 Jun 2012 11:49:34 +0200, Andreas Beckmann wrote:
> during a test with piuparts I noticed your package fails to upgrade from
> 'wheezy'.
> It installed fine in 'wheezy', then the upgrade to 'sid' fails.

Actually, I was not able to install bacula-director-mysql_5.0.3-1+b1 on
a clean wheezy (CD-1_20120618-04:55; d-i_20120508) with the default
mysql-server, i.e. 5.5:
=
root@debian:~# apt-get update
[...]

root@debian:~# apt-cache policy bacula-director-mysql
bacula-director-mysql:
  Installed: (none)
  Candidate: 5.0.3-1+b1
  Version table:
 5.0.3-1+b1 0
500 http://cdn.debian.net/debian/ wheezy/main amd64 Packages

root@debian:~# apt-get install bacula-director-mysql
[...]
The following NEW packages will be installed:
  bacula-common bacula-common-mysql bacula-director-common
  bacula-director-mysql dbconfig-common libaio1 libdbd-mysql-perl libdbi-perl
  libhtml-template-perl libmysqlclient16 libmysqlclient18 libnet-daemon-perl
  libplrpc-perl libpython2.7 mysql-client mysql-client-5.5 mysql-common
  mysql-server mysql-server-5.5 mysql-server-core-5.5
[...]
Setting up mysql-client-5.5 (5.5.24+dfsg-3) ...
Setting up mysql-client (5.5.24+dfsg-3) ...
Setting up bacula-director-mysql (5.0.3-1+b1) ...
dbconfig-common: writing config to 
/etc/dbconfig-common/bacula-director-mysql.conf
Creating config file /etc/dbconfig-common/bacula-director-mysql.conf with new 
version
ERROR 2002 (HY000): Can't connect to local MySQL server through socket 
'/var/run/mysqld/mysqld.sock' (2).
unable to connect to mysql server.
error encountered creating user:
ERROR 2002 (HY000): Can't connect to local MySQL server through socket 
'/var/run/mysqld/mysqld.sock' (2)
=

This is caused by the fact that there is no MySQL server running yet.
While this could be solved via a Pre-Depends: in bacula-director-mysql,
this is actually not possible because the MySQL server could be on a
remote location.  BTW, this happens to bacula-director-pgsql, too.

The story is not finished, given that even installing the MySQL server
*beforehand* does not result in a correct installation of
bacula-director-mysql:
=
root@debian:~# dpkg-query -W \*mysql\*
libdbd-mysql-perl   4.021-1+b1
libmysqlclient-dev  
libmysqlclient18:amd64  5.5.24+dfsg-3
mysql-client
mysql-client-5.0
mysql-client-5.1
mysql-client-5.55.5.24+dfsg-3
mysql-common5.5.24+dfsg-3
mysql-server5.5.24+dfsg-3
mysql-server-5.0
mysql-server-5.1
mysql-server-5.55.5.24+dfsg-3
mysql-server-core   
mysql-server-core-5.0   
mysql-server-core-5.1   
mysql-server-core-5.5   5.5.24+dfsg-3
rsyslog-mysql   
virtual-mysql-client
virtual-mysql-server

root@debian:~# apt-get update
[...]
root@debian:~# apt-get install bacula-director-mysql
[...]
The following NEW packages will be installed:
  bacula-common bacula-common-mysql bacula-director-common
  bacula-director-mysql dbconfig-common libmysqlclient16 libpython2.7
[...]
Setting up libmysqlclient16 (5.1.62-1) ...
Setting up bacula-common-mysql (5.0.3-1+b1) ...
Setting up bacula-director-common (5.0.3-1+b1) ...
Setting up dbconfig-common (1.8.47+nmu1) ...

Creating config file /etc/dbconfig-common/config with new version
Setting up bacula-director-mysql (5.0.3-1+b1) ...

Creating config file /etc/dbconfig-common/bacula-director-mysql.conf with new 
version
granting access to database bacula for bacula@localhost: success.
verifying access for bacula@localhost: success.
creating database bacula: success.
verifying database bacula exists: success.
populating database via sql...  error encountered populating database:
mysql said: ERROR 1064 (42000) at line 316: You have an error in your SQL 
syntax; check the manual that corresponds to your MySQL server version for the 
right syntax to use near 'MaxValue INTEGER DEFAULT 0, CurrentValue INTEGER 
DEFAULT 0, WrapCounter TI' at line 4

dbconfig-common: bacula-director-mysql configure: ignoring errors from here 
forwards
done.
dbconfig-common: flushing administrative password
dbconfig-common: bacula-director-mysql configure: ignoring errors from here 
forwards
dbconfig-common: bacula-director-mysql configure: ignoring errors from here 
forwards
Processing configuration...Ok.
[.ok.] Starting Bacula Director...:.
=

I could not test the above with mysql-server-5.1, since it is actually
not installable as you have already reported:

  

I do not know how to solve this bug, given that IMHO it is not a bug at
all: 5.0.3-1+b1 is no more installable on wheezy and 5.2.6+dfsg-1 solves
this (the latter installs fine with mysql-server-5.5_5.5.24+dfsg-3).

>>From the attached log (scroll to the bottom...):
>
>   Setting up bacula-director-mysql (5.2.6+dfsg-1) ...
>   Inst

Bug#658326: [pkg-bacula-devel] Bug#658326: marked as done (bacula: sha implimentation is non-free)

[Luca Capello]

found 658326 5.0.2-2.2
tags 658326 + squeeze
found 658326 5.0.3-1
tags 658326 + sid
thanks

Hi there!

On Fri, 15 Jun 2012 14:06:52 +0200, Karl Goetz wrote:
> On Wed, 02 May 2012 15:16:36 +0200
> Luca Capello  wrote:
>
> Sorry I missed this entire discussion; I forgot about the bug entirely
> until I saw the close email :/

No problem and actually thank you for the email, I just realized that I
forgot to fix it in stable, so Version:/Tags: added to the BTS and bug
fixed in squeeze-proposed-updates with the packages at:
=
$ sudo cat >/etc/apt/sources.list.d/people.debian.org_gismo.list
# 
<http://upsilon.cc/~zack/blog/posts/2009/04/howto:_uploading_to_people.d.o_using_dput/>
deb http://people.debian.org/~gismo/debian gismo-squeeze-proposed-updates/
deb-src http://people.debian.org/~gismo/debian gismo-squeeze-proposed-updates/
$ sudo wget -O /etc/apt/trusted.gpg.d/luca.pca.it-keyring.gpg \
 http://people.debian.org/~gismo/debian/luca.pca.it-keyring.gpg
$ sudo apt-get -t gismo-squeeze-proposed-updates $DEB
=

I am testing the above packages on my squeeze boxes, but any more
testing is appreciated.

>> 2) Have you seen that Karl (the original submitter) specifically
>> talked about stable and oldstable?  The problem should be fixed there
>> as well, but the first question above must be addressed first.
>> 
>>Karl, given that the latest upstream sources still contain the
>>incriminated files, have you already brought this problem up to the
>>upstream authors?
>> 
>>  <http://www.bacula.org/git/cgit.cgi/bacula/tree/bacula/src/lib/sha1.c>
>>  <http://www.bacula.org/git/cgit.cgi/bacula/tree/bacula/src/lib/sha1.h>
>
> As you noted later (by filing a bug of your own) I had not done this -
> apologies.

No need to apologize :-)

Just to be clear about upstream reply:

  <http://bugs.bacula.org/view.php?id=1869#c6325>

  kern (administrator) 2012-05-24 07:25

  I am closing this bug report because it proposes making a change that
  is not necessary, and makes Bacula less free. My reasons are:

  1. This change doesn't make sense, because in the context of the code
  the reference to "this document" means the license, and it is quite
  standard to make the license text non-changable. It is clear from the
  wording of the license that it is not restrictive.

  2. This code does not contain an RFC. It contains an open and free
  implementation of an RFC.

  3. Implementing the proposed fix, in fact, adds an additional
  dependency on OpenSSL to build the base part of Bacula, which is not
  present in the current code. This is unacceptable to me.

  4. By requiring OpenSSL, you are making Bacula less free and also more
  incompatible with the GPL (even if I have made an exception for it).

  5. Bacula is unavailable from Source Forge for a good number of people
  in the world, because it has the possibility of using encryption
  software. Your patch makes it require encryption software, unless I
  misunderstand the proposed patch.

  We do not intend to change our code unless we hear from the Internet
  Society that we are somehow infringing on their license, which seems
  to me highly improbable.

  You are, of course, free to under our current license to make the
  changes you propose.

This means that Debian (and any derivative who wants to be DFSG-free)
should carry the modification.

Thx, bye,
Gismo / Luca


pgpCYLhECMYR4.pgp
Description: PGP signature

Bug#639466: [pkg-bacula-devel] Bug#639466: bacula: Please move to postgresql-9.1

[Luca Capello]

Hi there!

On Fri, 01 Jun 2012 16:45:24 +0200, Julien Cristau wrote:
> On Sun, Feb 26, 2012 at 12:17:57 +0100, Martin Pitt wrote:
>> Luca Capello [2011-10-30  3:26 +0100]:
>> > tags 639466 + pending
>> 
>> Any chance to do an upload soon? I'll bump the severity of the
>> remaining four 8.4 bugs to RC now, and request removal of 8.4.
>> 
> Ping.  This is the last reverse dep of pg 8.4 now.

We are working to including all the pending changes in Bacula before the
freeze, with the intent to finally upload a new package this week-end
(or at the very beginning of the next week).  However, given that the
new version adds new -dbg binary packages, it should pass NEW.

Thx, bye,
Gismo / Luca


pgpkDqHHP7zft.pgp
Description: PGP signature

Bug#658326: [pkg-bacula-devel] Bug#658326: patch for switch to openssl SHA1 implementation

[Luca Capello]

tags 658326 + pending
thanks

Hi there!

On Thu, 17 May 2012 18:05:49 +0200, Luca Capello wrote:
> On Mon, 14 May 2012 22:43:12 +0200, Alexander Golovko wrote:
>> Ok, i add it into master branch
>> <http://anonscm.debian.org/gitweb/?p=pkg-bacula/bacula.git;a=commitdiff;h=6c562cfdaffd730c796518233f0d97da08a3891b>
>
> While the patch is perfectly fine, we should completely remove the two
> offending files from the upstream sources as well.  Unfortunately, the
> DFSG-free .orig.tar.gz Kefu uploaded still contains them:
>
>   <http://packages.qa.debian.org/b/bacula/news/20120430T091734Z.html>
>
> I am going to upload a fixed package this weekend.

Upstream sources re-packaged:

  
<http://anonscm.debian.org/gitweb/?p=pkg-bacula/bacula.git;a=commit;h=47fbab2da0062f2d4df087496220d969dd755d7b>

Thx, bye,
Gismo / Luca


pgpVftq5RVMTD.pgp
Description: PGP signature

Bug#672765: [pkg-bacula-devel] Bug#672765: FTBFS: Cannot find libmysqlclient following multi-arch conversion

[Luca Capello]

forwarded 672765 http://bugs.bacula.org/view.php?id=1829
thanks

Hi there!

On Thu, 17 May 2012 20:52:11 +0200, Luca Capello wrote:
> On Sun, 13 May 2012 17:30:29 +0200, Ben Hutchings wrote:
>> This fixes the failure to build.
>
> Thank you for the patch, applied to the Git master branch:

I should have checked the upstream BTS *before*:

  <http://bugs.bacula.org/view.php?id=1829>
  
<http://www.bacula.org/git/cgit.cgi/bacula/commit/?id=a5b5e28313beb43a5df8b6a956fa421142d837cf>

The upstream fix is different, nevertheless I kept yours for two
reasons: first, because it has been tested on different Debian systems
and, second, because this will come back when merging the Ubuntu package
(from which the upstream patch originates).

Thx, bye,
Gismo / Luca


pgpJHkhUGTMm3.pgp
Description: PGP signature

Bug#672765: [pkg-bacula-devel] Bug#672765: FTBFS: Cannot find libmysqlclient following multi-arch conversion

[Luca Capello]

tags 672765 + pending
usertags 672765 + debian-packaging
thanks

Hi Ben!

On Sun, 13 May 2012 17:30:29 +0200, Ben Hutchings wrote:
> This fixes the failure to build.

Thank you for the patch, applied to the Git master branch:

  


Thx, bye,
Gismo / Luca


pgpTTr4OJYvbI.pgp
Description: PGP signature

Bug#658326: [pkg-bacula-devel] Bug#658326: patch for switch to openssl SHA1 implementation

[Luca Capello]

Hi Alexander!

On Mon, 14 May 2012 22:43:12 +0200, Alexander Golovko wrote:
> On Mon, 14 May 2012 14:48:25 +0200, Luca Capello wrote:
>> On Thu, 10 May 2012 00:06:25 +0200, Alexander Golovko wrote:
>>> Fortunally, there are SHA1 implementation in openssl library.
>>> Used functions have the same names and arguments and bacula already
>>> linked with libssl
>>>
>>> We need only change headers, makefile.in and remove bad files.
>>
>> Thank you, forwarded upstream to:
>>
>>   <http://bugs.bacula.org/view.php?id=1869>
>>
>
> I'm afraid, this patch can't be merged into upstream without changes,
> because bacula can be built without SSL support, but with SHA1.
> But it will be greate if we will not need to support it always.

For the time being (the upstream BTS shows some discussion) I will
simply apply your patch and "forget" that we can build Bacula without
SSL support but with SHA-1, given that Debian does not provide such
packages.

> Ok, i add it into master branch
> <http://anonscm.debian.org/gitweb/?p=pkg-bacula/bacula.git;a=commitdiff;h=6c562cfdaffd730c796518233f0d97da08a3891b>

While the patch is perfectly fine, we should completely remove the two
offending files from the upstream sources as well.  Unfortunately, the
DFSG-free .orig.tar.gz Kefu uploaded still contains them:

  <http://packages.qa.debian.org/b/bacula/news/20120430T091734Z.html>

I am going to upload a fixed package this weekend.

Thx, bye,
Gismo / Luca


pgpmkLcDYfWkr.pgp
Description: PGP signature

Bug#672851: netbase 5.0: network connection does not come up upon reboot

[Luca Capello]

Hi there!

On Mon, 14 May 2012 11:18:28 +0200, Marco d'Itri wrote:
> On May 14, Adam Warner  wrote:
>
>> Multiple Debian sid operating systems (amd64 and i386): Could not
>> connect to them over the network after dist-upgrade and reboot. Isolated
>> cause to netbase 5.0 (which also removes ifupdown). 
> Only if you actually *agree* to remove ifupdown, which most people will 
> probably recognize to not be the wisest move...
>
> Andrew, I mistakenly tought that >= 0.7~rc1 already was in unstable: 
> either you upload it today or I will have to revert this change (and 
> I do not want to).

FYI, no problem here, `apt-get upgrade` pulled:

--8<---cut here---start->8---
2012-05-15 16:13:58 upgrade ifupdown:amd64 0.7~alpha5+really0.6.16 0.7~rc3
2012-05-15 16:13:59 upgrade netbase:all 4.47 5.0
--8<---cut here---end--->8---

So I guess this bug should be closed with ifupdown_0.7~rc3.

Thx, bye,
Gismo / Luca


pgp69vVxTNjEe.pgp
Description: PGP signature

Bug#658326: [pkg-bacula-devel] Bug#658326: patch for switch to openssl SHA1 implementation

[Luca Capello]

forwarded 658326 http://bugs.bacula.org/view.php?id=1869
tags 658326 + patch
usertags 658326 + debian-packaging
thanks

Hi there!

Re-adding Kefu and Karl to the Cc:.

On Thu, 10 May 2012 00:06:25 +0200, Alexander Golovko wrote:
> Fortunally, there are SHA1 implementation in openssl library.
> Used functions have the same names and arguments and bacula already
> linked with libssl
>
> We need only change headers, makefile.in and remove bad files.

Thank you, forwarded upstream to:

  

> With this patch, applied to bacula_5.0.2-2.2
>  - bacula packages sucessfully builded
>  - patched bacula-director-mysql can backup patched client (whith
> signature = SHA1 in fileset)
>  - patched bacula-director-mysql can backup original client (whith
> signature = SHA1 in fileset)
>  - for same files in database written the same SHA1 signature for both
> patched and original clients.

This means that we can *safely* apply the patch.  Alexander, can you
do it in the Git repository, directly in the master branch?  You should
add your patch in debian/patches, something similar to:

  


> OpenSSL all versions has SHA1 functions, so there is big chance patch
> can be applied to oldstable too.

Uploading to oldstable/lenny is no more possible, given that it reached
EOL on 2012-03-10:

  

While we could provide a fixed package in the pkg-bacula HTTP space,
IMHO it is better to focus on stable, thus "obliging" people to move on
something which is fully supported.

Thx, bye,
Gismo / Luca


pgpORdVlDsfXj.pgp
Description: PGP signature

Bug#658326: [pkg-bacula-devel] Bug#658326: marked as done (bacula: sha implimentation is non-free)

[Luca Capello]

tags 658326 + upstream
notfixed 658326 5.0.3+dfsg-0.1
thanks

Hi there!

On Mon, 30 Apr 2012 11:21:51 +0200, Debian Bug Tracking System wrote:
> Your message dated Mon, 30 Apr 2012 09:17:34 +
> with message-id 
> and subject line Bug#658326: fixed in bacula 5.0.3+dfsg-0.1
> has caused the Debian Bug report #658326,
> regarding bacula: sha implimentation is non-free
> to be marked as done.
[...]
> Changes:
>  bacula (5.0.3+dfsg-0.1) unstable; urgency=low
>  .
>* Non-maintainer upload.
>* Remove non-free SHA implementation (Closes: #658326).
>* debian/control: add libncurses5-dev into Build-Depends

Thank you for the NMU, but this is NOT the proper way, please read:

  

Specifically:

  § 5.11.1. When and how to do an NMU

  Before doing an NMU, consider the following questions:

  [...]

* How confident are you about your changes? Please remember the
  Hippocratic Oath: "Above all, do no harm." It is better to leave a
  package with an open grave bug than applying a non-functional
  patch, or one that hides the bug instead of resolving it. If you
  are not 100% sure of what you did, it might be a good idea to seek
  advice from others. Remember that if you break something in your
  NMU, many people will be very unhappy about it.

1) Have you checked what are the implication of removing the non-free
   SHA1 implementation?  I imagine that all the installations that have
   'signature=SHA1' in their FileSet resources are now broken, which is
   not acceptable without any warning *before* installation via
   NEWS.Debian, so administrators can act accordingly.  This is why I
   marked this bug as notfixed.

2) Have you seen that Karl (the original submitter) specifically talked
   about stable and oldstable?  The problem should be fixed there as
   well, but the first question above must be addressed first.

   Karl, given that the latest upstream sources still contain the
   incriminated files, have you already brought this problem up to the
   upstream authors?

 
 

Going on with the NMU policies:

* Have you clearly expressed your intention to NMU, at least in the
  BTS? It is also a good idea to try to contact the maintainer by
  other means (private email, IRC).

  When doing an NMU, you must first make sure that your intention to NMU
  is clear. Then, you must send a patch with the differences between the
  current package and your proposed NMU to the BTS. The nmudiff script
  in the devscripts package might be helpful.

  Sometimes, release managers decide to allow NMUs with shorter delays
  for a subset of bugs (e.g release-critical bugs older than 7
  days). Also, some maintainers list themselves in the Low Threshold NMU
  list, and accept that NMUs are uploaded without delay. But even in
  those cases, it's still a good idea to give the maintainer a few days
  to react before you upload, especially if the patch wasn't available
  in the BTS before, or if you know that the maintainer is generally
  active.

You have not contacted the pkg-bacula-devel@ mailing list neither sent
anything to the BTS.  Please note that I am not saying that I (as one of
the bacula maintainers) am active (actually, it is more the contrary).

Moreover, your NMU does not *only* include the fix for #658326, but also
the one for #646730, without any notice neither taking into account the
submitter proposal (patching the upstream build system).

Thx, bye,
Gismo / Luca


pgpb6eMiYEOGc.pgp
Description: PGP signature

Bug#670133: nslcd: /etc/nslcd.conf's binddn/bindpw removed during upgrade

[Luca Capello]

Package: nslcd
Version: 0.8.7-1
Severity: critical
Tags: patch
Usertags: pca.it-authentication

Hi there!

Basically, with today's upgrade, my /etc/nslcd.conf was automatically
changed and the LDAP setup completely broke:
=
root@gismo:/etc# cat /var/log/syslog
[...]
Apr 23 10:27:29 gismo nslcd[5209]: version 0.8.7 starting
Apr 23 10:27:29 gismo nslcd[5209]: accepting connections
Apr 23 10:27:37 gismo nslcd[5209]: [8b4567]  ldap_result() 
failed: Insufficient access
[...]

root@gismo:/etc# git log -p -1
commit abc0c29950469771617ffd0be132456669b7d305
Author: Luca Capello 
Date:   Mon Apr 23 10:27:35 2012 +0200

committing changes in /etc after apt run

Package changes:
[...]
-nslcd 0.8.6-1
+nslcd 0.8.7-1
[...]
diff --git a/nslcd.conf b/nslcd.conf
index 8ea8f0c..db2131d 100644
--- a/nslcd.conf
+++ b/nslcd.conf
@@ -16,8 +16,8 @@ base dc=pca,dc=it
 #ldap_version 3
 
 # The DN to bind with for normal lookups.
-binddn HIDDEN
-bindpw HIDDEN
+#binddn HIDDEN
+#bindpw *removed*
 
 # The DN used for password modifications by root.
 #rootpwmoddn cn=admin,dc=example,dc=com
=

I was quite surprised by that and then discovered the reason:
/etc/nslcd.conf is not a dpkg's conffile (it does not show up with
`dpkg-query -s nslcd`), thus any modification done is not automatically
preserved during upgrades, which is a bug according to
debian-policy_3.9.3.1's § 10.7.3:

  <http://www.debian.org/doc/debian-policy/ch-files.html#s10.7.3>

  10.7 Configuration files

  [...]

  10.7.3 Behavior

  Configuration file handling must conform to the following behavior:

* local changes must be preserved during a package upgrade,

NB, the Severity: of this bug is critical (and not serious) because no
more LDAP users can work with the system.

Strangely enough, this should have already been fixed by #610117.  Some
debugging and the problem in my case was clear: I did not used
debconf/dpkg-reconfigure to configure nslcd (which is perfectly fine, no
configuration method is mandatory in Debian), thus given that debconf's
nslcd/ldap-auth-type was empty /var/lib/dpkg/info/nslcd.postinst:212
thinks that there is no authentication at all.

This is easily fixed with the following patch, but further investigation
is still needed, given that bindpw is still removed, again if you do not
use debconf/dpkg-reconfigure:

--8<---cut here---start->8---
--- nslcd.postinst.ORG  2012-04-23 01:22:29.0 +0200
+++ nslcd.postinst  2012-04-23 12:04:15.180373883 +0200
@@ -211,6 +211,10 @@
   update_config nslcd/ldap-base base
   db_get nslcd/ldap-auth-type
   authtype="$RET"
+  db_get nslcd/ldap-binddn
+  if [ -n "$RET" ] && [ "$authtype" = none ]; then
+authtype=simple
+  fi
   case "$authtype" in
   simple)
 update_config nslcd/ldap-binddn binddn
--8<---cut here---end--->8---

The problem is present on the debconf's side as well, reproducible with:
=
root@gismo:/etc# debconf-show nslcd
* nslcd/ldap-bindpw: (password omitted)
  nslcd/ldap-sasl-realm:
* nslcd/ldap-starttls: false
  nslcd/ldap-sasl-krb5-ccname: /var/run/nslcd/nslcd.tkt
  nslcd/ldap-auth-type: none
  nslcd/ldap-reqcert:
* nslcd/ldap-uris: ldap://ldap.pca.it
  nslcd/ldap-sasl-secprops:
* nslcd/ldap-binddn: HIDDEN
  nslcd/ldap-sasl-authcid:
  nslcd/ldap-sasl-mech:
* nslcd/ldap-base: dc=pca,dc=it
  nslcd/ldap-sasl-authzid:

root@gismo:/etc# git diff
diff --git a/nslcd.conf b/nslcd.conf
index db2131d..2984a50 100644
--- a/nslcd.conf
+++ b/nslcd.conf
@@ -16,8 +16,8 @@ base dc=pca,dc=it
 #ldap_version 3

 # The DN to bind with for normal lookups.
-#binddn HIDDEN
-#bindpw *removed*
+binddn test
+bindpw test

 # The DN used for password modifications by root.
 #rootpwmoddn cn=admin,dc=example,dc=com

root@gismo:/etc# dpkg-reconfigure nslcd
[...]

root@gismo:/etc# git diff | less
diff --git a/nslcd.conf b/nslcd.conf
index db2131d..41b888f 100644
--- a/nslcd.conf
+++ b/nslcd.conf
@@ -16,7 +16,7 @@ base dc=pca,dc=it
 #ldap_version 3

 # The DN to bind with for normal lookups.
-#binddn HIDDEN
+#binddn test
 #bindpw *removed*

 # The DN used for password modifications by root.

root@gismo:/etc# debconf-show nslcd
* nslcd/ldap-bindpw: (password omitted)
  nslcd/ldap-sasl-realm:
* nslcd/ldap-starttls: false
  nslcd/ldap-sasl-krb5-ccname: /var/run/nslcd/nslcd.tkt
* nslcd/ldap-auth-type: none
  nslcd/ldap-reqcert:
* nslcd/ldap-uris: ldap://ldap.pca.it
  nslcd/ldap-sasl-secprops:
* nslcd/ldap-binddn: test
  nslcd/ldap-sasl-authcid:
  nslcd/ldap-sasl-mech:
* nslcd/ldap-base: dc=pca,dc=it
  nslcd/ldap-sasl-authzid:

root@gismo:/etc#
=

It seems the /etc/nslcd.conf handling is in some way broken :-(

Thx, bye,
Gismo / Luca

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

Bug#599188: [Fingerforce-devel] Bug#599188: Blocking dummy bug for squeeze release remotion [pam-fprint]

[Luca Capello]

Hi Adam!

On Sat, 03 Mar 2012 16:07:53 +0100, Adam D. Barratt wrote:
> On 05.10.2010 12:47, Dererk wrote:
>> Following to the FingerForce developers list discussion found here
>> [1],
>> I'm filling a dummy bug for the fprint software.
>>
>> As mentioned on that thread, we will provide newly and well-tested
>> fprint software for the Squeeze stable release through the backports
>> system in the future.
>
> That was a while ago now.  What's the plan for wheezy?

Waiting for Dererk to reply, here what I can say.

The situation has not changed so much, according to the upstream News
section:

  

  News

  * 2008-11-23: Bastien Nocera has been doing a lot of work on fprintd
and has put out a request for testing in Fedora.

Please note, however, that the mailing list as well as the Git
repositories are still active:

  
  
  

So, basically, we should move to fprintd (and pam-fprintd).  When this
will happen, however, is still unknown.  If needed, I am all in favor of
a complete removal of pam-fprint.

Thx, bye,
Gismo / Luca


pgpMAKR9iK374.pgp
Description: PGP signature

Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib

[Luca Capello]

Hi there!

On Thu, 15 Dec 2011 18:19:54 +0100, Marco d'Itri wrote:
> On Dec 15, Roger Leigh  wrote:
>
>> > You keep repeating arguments in favour of moving /{bin,sbin,lib}/ to
>> > /usr/ :-)
>> Well, I think I still need persuading that this is the right direction
>> to move the files.  I still think that moving /usr to / is a better
>> strategy, albeit introducing some problems with users who would need
> /usr to / does not allow any new features, while / to /usr allows
> implementing new features like creating OS snapshots at file system
> level (something which Fedora already supports) or a real complete OS
> image (to be NFS-shared, replicated, etc).

Maybe a naive comment, but I would say that there should be a list of
all the benefits for any change, being it / -> /usr or /usr -> /, then
deciding which is the Right Thing™ would be "easier" (doing so we can
also document our choices).

So THANK YOU Marco for explaining (another) one for / -> /usr, I was
thinking of asking Roger about it [1] before reading your reply ;-)

[1] 

Thx, bye,
Gismo / Luca


pgpq8gq6Zuw7t.pgp
Description: PGP signature

Bug#619636: Info received (Clutter problem?)

[Luca Capello]

user 619636 l...@pca.it
usertags 619636 + pca-communication
thanks

Hi there!

Cc:ing all the people involved with this bug, sorry for the spam.  Also
Cc:ing the Debian X Strike Force for comments about the Mesa part.

On Sat, 16 Apr 2011 17:38:51 +0200, Alex Stewart wrote:
> See also bug 620908. IMO, they should not be merged, because 619636
> can be solved in two ways: depending on a version of libclutter-1.0-0
> with a fix for bug 620908 or, AFAICT, building empathy without
> libchamplain support.

I can confirm that with the following diff empathy works without no
problem on a last-week up-to-date sid on libvirt/KVM with no HW
acceleration:

--8<---cut here---start->8---
diff -Nru empathy-3.2.2/debian/control empathy-3.2.2/debian/control
--- empathy-3.2.2/debian/control2011-11-19 18:24:56.0 +0100
+++ empathy-3.2.2/debian/control2011-11-21 00:36:24.0 +0100
@@ -13,7 +13,6 @@
debhelper (>= 8),
rarian-compat,
librarian-dev,
-   libchamplain-gtk-0.12-dev,
libglib2.0-dev (>= 2.28),
libgtk-3-dev (>= 3.0.2),
libtelepathy-glib-dev (>= 0.16.0),
diff -Nru empathy-3.2.2/debian/rules empathy-3.2.2/debian/rules
--- empathy-3.2.2/debian/rules  2011-11-19 18:24:56.0 +0100
+++ empathy-3.2.2/debian/rules  2011-11-21 00:51:04.0 +0100
@@ -13,7 +13,7 @@
 
 DEB_CONFIGURE_EXTRA_FLAGS := --enable-spell \
  --enable-webkit \
- --enable-map=yes \
+ --enable-map=no \
  --enable-geocode=yes \
  --with-cheese \
  --with-eds \
--8<---cut here---end--->8---

On Wed, 16 Nov 2011 11:07:45 +0100, Laurent Bigonville wrote:
> According to upstream this is a known issue and due to the software
> rasterizer in mesa. The only way here is, for now, to use proper
> hardware acceleration.

Until this week-end Mesa updates (see below), it seemed that there was
another way: installing libgl1-mesa-swx11 solved the problem for two
up-to-date sid, a schroot and the libvirt/KVM above.  However, in the
latter case GNOME 3 always crashes and I can not login (this should be
confirmed on a real machine, i.e. not on a VM).  So the situation was
the following:

1) libgl1-mesa-glx alone
   => empathy segfault

2) libgl1-mesa-glx *AND* libgl1-mesa-dri *AND* HW acceleration
   => empathy works

3) libgl1-mesa-swx11 (with or without libgl1-mesa-dri)
   => empathy works, but GNOME 3 crashes 

libclutter-1.0 already Depends: on 'libgl1-mesa-glx | libgl1' and this
includes also libgl1-mesa-swx11 (which Provides: libgl1).  What it could
be needed is a Depends: on 'libgl1-mesa-dri | libgl1-mesa-swx11':

--8<---cut here---start->8---
diff -Nru clutter-1.0-1.8.2/debian/control.in 
clutter-1.0-1.8.2/debian/control.in
--- clutter-1.0-1.8.2/debian/control.in 2011-11-14 13:18:06.0 +0100
+++ clutter-1.0-1.8.2/debian/control.in 2011-11-21 15:16:07.0 +0100
@@ -36,6 +36,7 @@
 Architecture: any
 Depends: ${shlibs:Depends},
  ${misc:Depends},
+ libgl1-mesa-dri | libgl1-mesa-swx11
 Recommends: libclutter-1.0-common
 Breaks: python-clutter (<< 1.3.2)
 Pre-Depends: ${misc:Pre-Depends}
--8<---cut here---end--->8---

> The long term solution is to switch to llvmpipe in debian to make it
> work for people that cannot get hardware acceleration. I think that the
> next release of mesa has switch to this.

It seems that upstream Mesa already solved this in a different way:

  
  

The upstream fix went into the new Mesa package during the week-end (I
was building the old 7.11-6 plus this patch, but given that the build
process needed more than 5 GB of disk space I could not get it earlier):

  

  

Nevertheless, empathy still segfaults witwh libgl1-mesa-glx_7.11.1-1
alone (i.e. without libgl1-mesa-dri) on both sid above, the schroot and
the libvirt/KVM.  However, the error on the latter is a bit more
explicative:
=
luca.capello@gismo-sid:~$ empathy

(empathy:2824): Clutter-CRITICAL **: Unable to initialize Clutter: \
 The OpenGL version could not be determined
Segmentation fault
luca.capello@gismo-sid:~$ empathy
=

Installing libgl1-mesa-dri solves the problem, which is anyway a
progress, given that before it did not work at all on libvirt/KVM with
no HW acceleration (see point 2 above).

Thx, bye,
Gismo / Luca


pgplLeRisoVwF.pgp
Description: PGP signature

Bug#638045: warning: xsasl_cyrus_server_get_mechanism_list: no mechanism available

[Luca Capello]

Hi there!

On Wed, 17 Aug 2011 15:34:23 +0200, Ondřej Surý wrote:
> On Wed, Aug 17, 2011 at 15:05, Sven Joachim  wrote:
>> So this bug has been triggered by the switch to multiarch paths in
>> cyrus-sasl2, and postfix is to blame for hardcoding /usr/lib/sasl2.
>
> I guess the Ubuntu already have a patch for that
>
> I could remove the MultiArch patch as a quick remedy and wait for
> postfix to catch up. Opinions?

The correct solution would be for libsasl2-2 to add:

  Breaks: postfix (<< $VERSION_INTRODUCING_MULTIARCH)

If you want to react ASAP, you can start with 2.8.3-1, the postfix
version in sid and then upgrading it later coordinating with the postfix
maintainers.

Thx, bye,
Gismo / Luca


pgpKzjJyboxrO.pgp
Description: PGP signature

Bug#638045: warning: xsasl_cyrus_server_get_mechanism_list: no mechanism available

[Luca Capello]

Hi there!

On Wed, 17 Aug 2011 11:59:19 +0200, Stefano Zacchiroli wrote:
> On Tue, Aug 16, 2011 at 09:54:14PM +0200, Johnny Morano wrote:
>> Postfix is unable to receive mail and unable to send mail via SASL
>> authentication, after installing the updates of today.  These are the
>> error messages:
>
> I can reproduce this in Sid.

/me too.

> Reverting both "libsasl2-2" and "libsasl2-modules" to version
> 2.1.23.dfsg1-7 fixes the problem.

FWIW, reverting to 2.1.24~rc1.dfsg1+cvs2011-05-23-4 is enough.

BTW, if you use Cyrus SASL authentication in Postfix, you can not
 actually revert libsasl2-2 and libsasl2-modules only, but you need
 to revert sasl2-bin as well because of its versioned dependency.

> I'm setting severity as serious, as it breaks pretty heavily mail
> delivery for SASL-based postfix configuration. I'm also marking the bug
> as affecting postfix, as many people will probably look for some issue
> there.

Thank you, indeed I did not find it during a first look, maybe the title
should be changed to reflect the IMHO most common error?  In my case:

  C61E120DDD 2071 Wed Aug 17 10:45:55  l...@pca.it
  (SASL authentication failed; cannot authenticate to server \
   home.pca.it[83.211.85.135]: no mechanism available)
 debian-public...@lists.debian.org

Two notes, maybe they could be useful:

1) the upgrade from -4 to -5 created an /etc/sasldb2 file, is it really
   useful?  And why not in /etc/sasl2/ instead, already used by
   libvirt-bin?

2) the remote SMTP server uses Postfix_2.7.1-1+squeeze1, but SASL
   authentication is provided by Dovecot_1:1.2.15-7.gismo.gnus8959~1
   (see #632844).

Thx, bye,
Gismo / Luca

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

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

Versions of packages sasl2-bin depends on:
ii  db-util 5.1.4Berkeley Database Utilities
ii  debconf 1.5.41   Debian configuration management sy
ii  libc6   2.13-16  Embedded GNU C Library: Shared lib
ii  libcome 1.42~WIP-2011-07-02-1common error description library
ii  libdb5. 5.1.25-11Berkeley v5.1 Database Libraries [
ii  libgssa 1.9.1+dfsg-2 MIT Kerberos runtime libraries - k
ii  libk5cr 1.9.1+dfsg-2 MIT Kerberos runtime libraries - C
ii  libkrb5 1.9.1+dfsg-2 MIT Kerberos runtime libraries
ii  libldap 2.4.25-3 OpenLDAP libraries
ii  libpam0 1.1.3-2  Pluggable Authentication Modules l
ii  libsasl 2.1.24~rc1.dfsg1+cvs2011-05-23-5 Cyrus SASL - authentication abstra
ii  libssl1 1.0.0d-3 SSL shared libraries
ii  lsb-bas 3.2-27   Linux Standard Base 3.2 init scrip

sasl2-bin recommends no packages.

sasl2-bin suggests no packages.

-- Configuration Files:
/etc/default/saslauthd changed:
START=yes
DESC="SASL Authentication Daemon"
NAME="saslauthd"
MECHANISMS="pam"
MECH_OPTIONS=""
THREADS=5
OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"


-- debconf information:
  cyrus-sasl2/upgrade-sasldb2-failed:
  cyrus-sasl2/backup-sasldb2: /var/backups/sasldb2.bak
  cyrus-sasl2/upgrade-sasldb2-backup-failed:
  cyrus-sasl2/purge-sasldb2: false


pgpp9ghUclCWt.pgp
Description: PGP signature

Bug#614252: qemu -enable-kvm freezes

[Luca Capello]

Hi there!

On Sun, 20 Feb 2011 19:39:23 +0100, Vagrant Cascadian wrote:
> On Sun, Feb 20, 2011 at 11:24:16AM -0600, Javier Vasquez wrote:
>> On an amd64 laptop (debian unstable) I've been using qemu with the
>> following arguments (with windows XP guest):

Same here: Debian sid with the latest qemu and Windows XP guest.

>> qemu $ARGS_GEN $ARGS_NET $ARGS_BIOS0 $ARGS_BIOS1 $ARGS_VGA $ARGS_AUDIO
>> $ARGS_USB $ARGS_CPU $ARGS_NIC
>
> i know you've tried a variety of commandline options, but what about just 
> using
> the defaults with -enable-kvm?

  $ qemu -enable-kvm -rtc base=localtime -m 512M -vnc 127.0.0.1:9,none \
 -monitor stdio -runas luca /home/luca/xp-pro-en_BioEdit.img

NB, I used that configuration with `kvm` (from the qemu-kvm package,
version 0.12.5+dfsg-5).  Strange enough, now that I started using `qemu
-enable-kvm` the wired NIC is recognized as 8086:100e (Intel PRO/1000 MT
Network Connection [1]) and not as 10ec:8139 (Realtek RTL8139 Family PCI
Fast Ethernet NIC).  I thought there were no differences (except
optimizations) between `qemu -enable-kvm` and `kvm` itself, but this
does not seem to be the case, am I wrong or is this a bug in qemu/kvm?
Reading both qemu and kvm's manpages, however, I found out that "the NIC
is an e1000 by default on the PC target", so I guess kvm is at fault
here, please let me know if I should report it as a bug.

[1] unfortunately Windows XP SP3 by default does not seem to have
drivers for this NIC, I thus used the one provided by Intel itself

  


>> qemu: pci_add_option_rom: failed to find romfile "vgabios-stdvga.bin"
>
> this is bug#614169, and as far as i know, shouldn't really be a problem.

You mean, it is not a problem related to *this* bug?  Because it is
anyway a problem, the above command results in an unusable VNC
connection: the window first shows a vertically-degraded gray (from
center to sides), then a degraded blue-to-gray, from left to right, with
some orange in the middle.

> do you have other hardware you can test with? -enable-kvm seems to work for me
> on i386, at least. 
>
> are you able to boot a different OS? i've only tested with Debian/GNU Linux or
> Debian/GNU kFreeBSD.

-enable-kvm works here as well with no problems, tested with an XP guest
run for the whole afternoon.

However, please note that both as qemu-system-i386 and -x86_64 [why for
the hell it is not called amd64, then?  Or -i386 called -x86...] are way
slower (i.e. barely usable) than kvm itself: could this be caused by the
missing vgabios-stdvga.bin above?

Thx, bye,
Gismo / Luca


pgpz9phaUNuaI.pgp
Description: PGP signature

Bug#612471: xserver-xorg-core uninstallable, dependencies broken

[Luca Capello]

Hi there!

On Tue, 08 Feb 2011 18:26:09 +0100, Cyril Brulebois wrote:
> the_...@gmx.net  (08/02/2011):
>> Package: xserver-xorg-core
>> Version: 1.9.4-1
>> Severity: grave
>
> not a bug per se. Welcome to sid.

This is questionable, there is a bug (upgrades are not possible, of
course Severity: at most important, IMHO normal) and the fact that it is
in sid or not does not matter.  And closing this bug does not help at
all users that look at the BTS to find already-reported bug, here what I
was submitting as a new bug:
--8<---cut here---start->8---
I found this problem yesterday morning, but then I waited until today to
be sure it was not a problem of mirror syncing (cdn.debian.net ->
129.132.86.210 AKA ftp.ch.debian.org).

Basically, upgrading to the latest version in sid does not work:
=
gismo:~# apt-get install xserver-xorg-core xserver-xorg \
 xserver-xorg-video-intel xserver-xorg-input-evdev
Reading package lists... Done
Building dependency tree
Reading state information... Done
xserver-xorg-input-evdev is already the newest version.
xserver-xorg-input-evdev set to manually installed.
xserver-xorg-video-intel is already the newest version.
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 xserver-xorg : Depends: xserver-xorg-input-all but it is not going to be 
installed or
 xorg-driver-input
 xserver-xorg-core : Breaks: xserver-xorg-input-4
 Breaks: xserver-xorg-input-7
 Breaks: xserver-xorg-video-6
 xserver-xorg-input-evdev : Depends: xorg-input-abi-7.0
 xserver-xorg-video-intel : Depends: xorg-video-abi-6.0
E: Broken packages
=
--8<---cut here---end--->8---

>> I'm not sure wether my system is just fucked up, but to me it seems
>> likely, that this bug makes it completely impossible to install any
>> graphical environment right now. For everyone.
>
> Yes. Drivers are missing due to:
>   http://bugs.debian.org/612137

Sorry, but I do not see any explanation there which could help users to
understand what is the real problem with X.org packages.

> In the meanwhile, you could pick drivers from experimental.

Thanks, this does the trick:
=
gismo:~# apt-get install xserver-xorg-core xserver-xorg \
 xserver-xorg-video-intel/experimental xserver-xorg-input-evdev/experimental
Reading package lists... Done
Building dependency tree
Reading state information... Done
Selected version '2:2.14.0-2' (Debian:experimental [amd64]) for 
'xserver-xorg-video-intel'
Selected version '1:2.6.0-1' (Debian:experimental [amd64]) for 
'xserver-xorg-input-evdev'
Suggested packages:
  xfonts-100dpi xfonts-75dpi xfonts-scalable
The following packages will be upgraded:
  xserver-xorg xserver-xorg-core xserver-xorg-input-evdev 
xserver-xorg-video-intel
4 upgraded, 0 newly installed, 0 to remove and 11 not upgraded.
=

What I would do:
--8<---cut here---start->8---
reopen 612471 !
retitle 612471 xserver-xorg: dependencies problem with -input-evdev and 
-video-intel
reassign 612471 xserver-xorg
found 612471 1:7.5+8
severity 612471 normal
block 612471 by 612137
thanks
--8<---cut here---end--->8---

I did not do anything because you are the maintainer, so I am fine if
you want to keep the situation as it is.

Thx, bye,
Gismo / Luca


pgpriUNMpshmN.pgp
Description: PGP signature

Bug#602697: chef: remove from squeeze because of solr (#602697)? (was Re: Bug#602697: chef-solr depends on solr)

[Luca Capello]

Hi there!

> Cc:ing all the people that have interacted with this bug.

Still true, but this is the last email about this subject from me.

On Sun, 28 Nov 2010 17:47:41 +0100, Luca Capello wrote:
> Some hints about the chef package in Debian:
>
> - Debian has (6-month-old) 0.8.16-4.1, while upstream is at 0.9.12
> - popcon show 41 installation (2 recent) for the chef binary package and
>   2 (0 recent) for the chef-solr binary package
> - there is an RC bug for chef-solr (#604231, installation fails because
>   of nodedown)
>
> Thus, I think the best thing would be to remove chef from squeeze (new
> bugs created), so then we can remove solr as well.

chef has been removed from squeeze because of #610127 and #596351:

  <http://packages.qa.debian.org/c/chef/news/20110121T163911Z.html>

>>> It's also in lenny (albeit in contrib) so if it were removed then a
>>> migration path for those users to a replacement would be good.
>
> Given that chef-solr was not in lenny, the above applies to solr only.
> However, I should say that I do not know at all a good migration path.

This concern still stands, but given that no one has shown interest in
implementing this in mostly two months, I would say that we should
simply remove solr from squeeze.

For the Release Team: should I file an RM bug or this one is sufficient?

Thx, bye,
Gismo / Luca


pgpxIZ9dwavX3.pgp
Description: PGP signature

Bug#609761: [Foo2zjs-maintainer] Processed: severity of 609761 is serious, tagging 609761

[Luca Capello]

Hi there!

On Mon, 17 Jan 2011 14:22:51 +0100, Julien Cristau wrote:
> On Mon, Jan 17, 2011 at 12:42:20 +0100, Didier 'OdyX' Raboud wrote:
>
>> Le Monday 17 January 2011 10:00:08 Julien Cristau, vous avez écrit :
>> > Rescheduling Didier's upload would probably be a good idea.  I can
>> > change urgency afterwards.
>> 
>> That's now done; to 0-day:
>> 
>> > reschedule foo2zjs_20090908dfsg-5.1_amd64.changes 0-day
>> foo2zjs_20090908dfsg-5.1_amd64.changes moved to 0-day
>> …
>> 
> Unblocked and aged, thanks.

Thank you for the fast reply/support, for the rest all the credits goes
to Didier ;-)

Thx, bye,
Gismo / Luca


pgpJUJoXFpWv5.pgp
Description: PGP signature

Bug#609761: [Foo2zjs-maintainer] Processed: severity of 609761 is serious, tagging 609761

[Luca Capello]

Hi Julien!

On Sun, 16 Jan 2011 19:45:04 +0100, Debian Bug Tracking System wrote:
>> severity 609761 serious
> Bug #609761 [foo2zjs] foo2zjs depends on dc to work
> Severity set to 'serious' from 'critical'
>
>> tags 609761 - squeeze
> Bug #609761 [foo2zjs] foo2zjs depends on dc to work
> Removed tag(s) squeeze.

Mmm, I do not understand why removing the squeeze tag.  I am perfectly
fine with Didier's NMU (which IMHO should not have been delayed at all),
which means that this bug will be fixed in 2 days: is this still a good
timeframe for squeeze or should I (or Didier) upload a new version *now*
(and better with urgency=high)?

Thx, bye,
Gismo / Luca


pgp2cWaaDVMC2.pgp
Description: PGP signature

Bug#601977: cyrus-sasl2-heimdal-dbg: file conflict during upgrade from lenny

[Luca Capello]

Hi there!

On Tue, 14 Dec 2010 01:29:01 +0100, Roberto C. Sánchez wrote:
>> > created by dh_strip, excerpted from debian/rules below:
>> > 
>> > dh_strip -s -psasl2-bin -plibsasl2-2 -plibsasl2-modules 
>> > -plibsasl2-modules-ldap -plibsasl2-modules-otp -plibsasl2-modules-sql 
>> > -plibsasl2-modules-gssapi-mit -plibsasl2-dev 
>> > -Nlibsasl2-modules-gssapi-heimdal --dbg-package=cyrus-sasl2-dbg
>> > dh_strip -s -plibsasl2-modules-gssapi-heimdal -Nsasl2-bin -Nlibsasl2-2 
>> > -Nlibsasl2-modules -Nlibsasl2-modules-ldap -Nlibsasl2-modules-otp 
>> > -Nlibsasl2-modules-sql -Nlibsasl2-modules-gssapi-mit -Nlibsasl2-dev 
>> > --dbg-package=cyrus-sasl2-heimdal-dbg
>> > 
>> > Both packages need to be able to be installed together, so my question
>> > centers around whehter it is OK to put a diversion in place so that
>> > cyrus-sasl2-heimdal-dbg diverts the file.  What does everyone think?

I guess that it would have helped me quite a lot to know that this bug
had a reply and it was now ignored for quite a month, but it seems that
the reply above was not sent to the BTS and only to the mailing list:

  
http://lists.alioth.debian.org/pipermail/pkg-cyrus-sasl2-debian-devel/2010-October/001957.html

>> So, it appears that there are some other possibilities, thanks to a
>> posting by Luca Capello [0].

Is there any reason why you did not Cc: me?  I was wondering if this bug
was forgot, given that I did not receive any update on it (and no, going
to the BTS or subscribing to *every* bug someone is interacting with it
is not an acceptable solution).

>> The first possibility is trivial, but is not as "correct."  The
>> second is more "correct" but a larger diff.  Given that this must go
>> into Lenny, what opinion or preference does the release team have on
>> the matter?
[...]
>
> Given the just announced deep freeze, I'd like some guidance from the
> release team on this, so that I can prepare an update with an acceptable
> fix to go into Squeeze.

I am not a library expert, but you cannot install both libraries
together:
=
l...@gismo:~$ apt-cache show libsasl2-modules-gssapi-mit | grep Conflicts
Conflicts: libsasl2-modules-gssapi-heimdal
l...@gismo:~$
=

So, if you want to debug the GSSAPI Heimdal library you need
cyrus-sasl2-heimdal-dbg and, I guess, at the same time
libsasl2-modules-gssapi-heimdal.  Given that the latter conflicts with
the former, it seems clear that the correct approach is the second
option I proposed.

Thx, bye,
Gismo / Luca


pgp83wFcbXc0q.pgp
Description: PGP signature

Bug#604231: chef-solr

[Luca Capello]

block 604231 by 606274
tags 604231 + patch
thanks

Hi there!

On Mon, 06 Dec 2010 19:04:38 +0100, Mehdi Dogguy wrote:
> On 06/12/2010 18:47, Luca Capello wrote:
>> Hi there!
>>
>
> (I should have CC'ed you too... I'm sorry for that).

Np.

>> On Sat, 04 Dec 2010 19:56:14 +0100, Mehdi Dogguy wrote:
>>>
>>> These can't be updated to the latest release because of the freeze.
>>> Are you fine with removing the chef-* binary packages from the source
>>> package and keep the same upstream version? or should I add a removal
>>> hint from Squeeze for src:chef?
>>
>> Already there:
>>
>> http://bugs.debian.org/605277
>>
>> Please note that if chef-solr is being removed from squeeze, the
>> reverse dependency that impeded solr removal goes away as well:
>>
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602697#10
>>
>
> Yeah, that's why we are here :)
>
>>
>> Mehdi, is it OK if I stop to care about this bug and leave it to you?
>>
>
> As you like, I don't know what to do here, except adding a removal hint
> for chef. If you'd like to prepare an NMU that would leave the client
> only, I'd accept it. Besides, not having any reply from the maintainers
> doesn't help to decide...

While preparing the NMU below I discovered that chef FTBFS, so I also
fixed that:

--8<---cut here---start->8---
diff -u chef-0.8.16/debian/changelog chef-0.8.16/debian/changelog
--- chef-0.8.16/debian/changelog
+++ chef-0.8.16/debian/changelog
@@ -1,3 +1,16 @@
+chef (0.8.16-4.2) UNRELEASED; urgency=low
+
+  * Non-maintainer upload.
+  * debian/control:
+- remove outdated -server* packages and chef-solr as well, with
+  maintainer's approval (Closes: #604231).
+  * debian/patches/series: update.
+  * debian/patches/chef_client_ruby18.patch:
++ fix FTBFS, use a versioned shebang for client binaries, since
+  the chef binary package Depends: on Ruby-1.8 (Closes: #606274).
+
+ -- Luca Capello   Wed, 08 Dec 2010 00:31:34 +0100
+
 chef (0.8.16-4.1) unstable; urgency=low
 
   * Non-maintainer upload to fix pending l10n issues
diff -u chef-0.8.16/debian/control chef-0.8.16/debian/control
--- chef-0.8.16/debian/control
+++ chef-0.8.16/debian/control
@@ -24,96 +24,6 @@
  This package contains the chef-client and chef-solo binaries and associated
  files.
 
-Package: chef-solr
-Architecture: all
-Depends: ${misc:Depends}, ruby1.8, rabbitmq-server (>= 1.6), 
default-jre-headless | java6-runtime-headless, libjson-ruby1.8, libchef-ruby1.8 
(= ${source:Version}), solr-jetty (>=1.4.0), libxml-ruby1.8, adduser, ucf
-Suggests: chef (= ${source:Version})
-Replaces: chef-indexer
-Conflicts: chef-indexer
-Description: system integration framework - search indexes management
- Chef is a systems integration framework and configuration management library
- written in Ruby. Chef provides a Ruby library and API that can be used to
- bring the benefits of configuration management to an entire infrastructure.
- .
- Chef can be run as a client (chef-client) to a server, or as a standalone
- tool (chef-solo). Configuration recipes are written in a pure Ruby
- domain-specific language.
- .
- The chef indexer listens to a message queue via AMQP for changes to search
- indexes. It then either creates or deletes entries in the index according
- to the information it is passed.
- .
- This package provides the chef-solr search engine which runs as a solr-jetty
- server, and chef-solr-indexer that talks to the AMQP message queue, by
- default rabbitmq-server.
-
-Package: chef-server
-Architecture: all
-Depends: ${misc:Depends}, ruby, merb-slices, libmerb-assets-ruby, 
libmerb-haml-ruby, libmerb-helpers-ruby, chef-server-api (= ${source:Version}), 
chef-solr (= ${source:Version}), thin, libjson-ruby, libchef-ruby (= 
${source:Version}), libuuidtools-ruby1.8, adduser, libjs-jquery (>= 1.3.2), ucf
-Recommends: chef (= ${source:Version})
-Suggests: nginx, apache2, rake, chef-server-webui (=${source:Version})
-Description: system integration framework - centralized server
- Chef is a systems integration framework and configuration management library
- written in Ruby. Chef provides a Ruby library and API that can be used to
- bring the benefits of configuration management to an entire infrastructure.
- .
- Chef can be run as a client (chef-client) to a server, or as a standalone
- tool (chef-solo). Configuration recipes are written in a pure Ruby
- domain-specific language.
- .
- The Chef Server is a Merb application that provides centralized storage and
- distribution for recipes stored in "cookbooks," management and authentication
- of client nodes and node data, and search indexes for that data.
- .
- The chef-server package provides a merb binary wrapper that loads up the
- chef-serv

Bug#606274: chef: FTBFS: Patch remove_rubygems.patch does not remove cleanly (refresh it or enforce with -f)

[Luca Capello]

Package: chef
Version: 0.8.16-4.1
Severity: serious
Tags: patch

Hi there!

=
l...@gismo:~/$ gismo-pbuilder.sh --build base-sid chef_0.8.16-4.1.dsc
[...]
dpkg-deb: building package `libchef-ruby1.8' in 
`../libchef-ruby1.8_0.8.16-4.1_all.deb'.
 dpkg-genchanges  >../chef_0.8.16-4.1_amd64.changes
dpkg-genchanges: not including original source code in upload
 fakeroot debian/rules clean
test -x debian/rules
dh_testroot
dh_clean
/usr/bin/make -f debian/rules reverse-config
make[1]: Entering directory `/tmp/buildd/chef-0.8.16'
make[1]: Nothing to be done for `reverse-config'.
make[1]: Leaving directory `/tmp/buildd/chef-0.8.16'
if [ -d "." ]; then \
  cd . && QUILT_PATCHES=/tmp/buildd/chef-0.8.16/debian/patches quilt 
--quiltrc /dev/null pop -a -R || test $? = 2 ; \
fi
Removing patch jquery_unminified.patch
Removing chef-server-webui/public/javascripts/jquery.jeditable.js
Removing chef-server-webui/public/javascripts/yetii.js
Removing chef-server-webui/public/javascripts/jquery.tools.js

Patch remove_rubygems.patch does not remove cleanly (refresh it or enforce with 
-f)
make: *** [reverse-patches] Error 1
dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit status 2
E: Failed autobuilding of package
=

When you do not build the package, the patch above seems to cleanly
apply and remove, so I guess the building process modifies some files.
And indeed if I compare the patched files above with the original ones,
the diff includes more than the quilt patch:

--8<---cut here---start->8---
--- chef-0.8.16/chef/bin/chef-client 2010-12-07 21:57:20.0 +0100
+++ chef-client 2010-12-07 22:17:57.0 +0100
@@ -1,4 +1,4 @@
-#!/usr/bin/env ruby
+#! /usr/bin/ruby1.8
 #
 # ./chef-client - Run the chef client
 #
@@ -18,7 +18,6 @@
 # See the License for the specific language governing permissions and
 # limitations under the License.

-require 'rubygems'
 $:.unshift(File.join(File.dirname(__FILE__), "..", "lib"))
 require 'chef'
 require 'chef/application/client'
--8<---cut here---end--->8---

This applies to the four chef-client binaries: chef-client, chef-solo,
knife and shef.  The build log contains the following:
=
(cd chef && /usr/bin/ruby debian-setup.rb setup)
---> bin
updating shebang: chef-client
updating shebang: shef
updating shebang: knife
updating shebang: chef-solo
<--- bin
=

What is strange is that the current chef binary package available in sid
contains the four binaries above with exactly the same shebang as the
one that causes the error, which means that the build process should
have stopped even in the past...

Actually, the same problem should happen for the -server* binaries, but
it does not, given that the shebang in these binaries is specifically
modified to ruby1.8 because the -server* binaries do not support
Ruby-1.9 yet:

  [chef-0.8.16/debian/patches/chef_solr_ruby18.patch]
  # Description: Use ruby1.8 specifically as Chef Solr/Server doesn't support
  # ruby1.9 yet.

Nevertheless, I am not a Ruby nor a chef expert, but applying the same
trick patch to the client binaries solves the FTBFS.  I am confident
this is the correct fix also because the chef binary package (which
contains the client binaries) Depends: on Ruby-1.8:

  Depends: ${misc:Depends}, ruby1.8, liberubis-ruby1.8, libjson-ruby1.8,
   libextlib-ruby1.8 (>= 0.9.13), ohai (>= 0.4.0),
   libchef-ruby1.8 (= ${source:Version}), libopenssl-ruby1.8,
   libmixlib-authentication-ruby1.8 (>= 1.1.0), ucf

--8<---cut here---start->8---
diff -u chef-0.8.16/debian/changelog chef-0.8.16/debian/changelog
--- chef-0.8.16/debian/changelog
+++ chef-0.8.16/debian/changelog
@@ -1,3 +1,13 @@
+chef (0.8.16-4.2) UNRELEASED; urgency=low
+
+  * Non-maintainer upload.
+  * debian/patches/series: update.
+  * debian/patches/chef_client_ruby18.patch:
++ fix FTBFS, use a versioned shebang for client binaries, since
+  the chef binary package Depends: on Ruby-1.8 (Closes: #NN).
+
+ -- Luca Capello   Tue, 07 Dec 2010 23:13:49 +0100
+
 chef (0.8.16-4.1) unstable; urgency=low
 
   * Non-maintainer upload to fix pending l10n issues
diff -u chef-0.8.16/debian/patches/series chef-0.8.16/debian/patches/series
--- chef-0.8.16/debian/patches/series
+++ chef-0.8.16/debian/patches/series
@@ -4,0 +5 @@
+chef_client_ruby18.patch
only in patch2:
unchanged:
--- chef-0.8.16.orig/debian/patches/chef_client_ruby18.patch
+++ chef-0.8.16/debian/patches/chef_client_ruby18.patch
@@ -0,0 +1,34 @@
+# Description: Use ruby1.8 specifically as Chef clients do not support
+# ruby1.9 yet (Closes: #NN).
+--- chef-0.8.16.orig/chef/bin/chef-client
 chef-0.8.16/chef/bin/chef-client
+@@ -1,4 +1,4 @@
+-#!/usr/bin/env ruby
++#!/usr/bin/ruby1.8
+ #
+ # 

Bug#604231: chef-solr

[Luca Capello]

Hi there!

On Sat, 04 Dec 2010 19:56:14 +0100, Mehdi Dogguy wrote:
> Joshua Timberman  wrote:
> > We (Opscode, upstream maintainers of Chef) are fine with removal
> > of the following chef packages from Debian Squeeze:

I would have preferred to be cc:ed by Joshua in his first reply, given
that I work on chef/solr bugs during the Bern BSP
 and I guess Joshua's
acknowledgement of removal is because of:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602697#35
  http://bugs.debian.org/605277

> > chef-server
> > chef-server-api
> > chef-server-webui
> > chef-solr
> > 
> > The client packages should remain, and should be updated to the
> > latest release (0.9.12):
> > 
> > chef
> > libchef-ruby
> > libchef-ruby1.8
> > 
> 
> These can't be updated to the latest release because of the freeze.
> Are you fine with removing the chef-* binary packages from the source
> package and keep the same upstream version? or should I add a removal
> hint from Squeeze for src:chef?

Already there:

  http://bugs.debian.org/605277

Please note that if chef-solr is being removed from squeeze, the
reverse dependency that impeded solr removal goes away as well:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602697#10

> > I do have updated packaging in the Debian Ruby Extras team repository
> > for these packages.
> > 
> 
> Where can I find the packaging? (where is the repository?)

I guess

  http://wiki.opscode.com/display/chef/Package+Installation+on+Debian+and+Ubuntu

Mehdi, is it OK if I stop to care about this bug and leave it to you?

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#603141: postgresql-8.4 and lenny upgrades (was Re: Bug#603141: dbi-link: fails to install due to incorrect dependencies in init.d LSB header)

[Luca Capello]

Hi Holger!

On Sun, 28 Nov 2010 14:55:46 +0100, Holger Levsen wrote:
> On Sonntag, 28. November 2010, Luca Capello wrote:
> > I could not find this version anymore, not in the postgresql-8.4's
> > debian/changelog nor in snapshots.d.o, where did it come from?
> 
> it's there: http://snapshot.debian.org/package/postgresql-8.4/8.4.4-1/

Yeah, now that you told me I checked that page and found it, it seems
I still need to understand how snapshot.d.o works :-)

Thx, bye,
Gismo / Luca



signature.asc
Description: Digital signature

Bug#602222: bacula meta-package not installable with recommended packages

[Luca Capello]

Hi there!

Cc:ing all the people involved with this bug (hi, Gregor!).

On Tue, 02 Nov 2010 18:08:13 +0100, Olivier BONHOMME wrote:
> When trying to install the bacula meta-package, the aptitude command raises 
> the following error : 
>
> The following packages have unmet dependencies:
>   bacula-common-sqlite3: Conflicts: bacula-common-mysql but 5.0.2-2 is to be 
> installed.
>   bacula-common-mysql: Conflicts: bacula-common-sqlite3 but 5.0.2-2 is to be 
> installed.
>
> It seems that the conflict is provided by the virtual package bacula-sd-tools 
> (Which is a recommended one) because
> this package tries to install bacula-common-mysql.
>
> If we install bacula without the recommended packages, the installation is 
> possible.

Strange enough, when using the --with-recommends option aptitude should
resolve them as --without-recommends (which works as expected).

> It is not impossible to install bacula with apt-get anymore. The following 
> error is raised : 
>
> The following packages have unmet dependencies:
>  bacula : Depends: bacula-server but it is not going to be installed

If you do not install recommends, it is OK, exactly as with aptitude.

On Thu, 25 Nov 2010 14:35:40 +0100, Hideki Yamane wrote:
>  Clint Byrum  wrote:
>> Would it fix the problem if bacula-sd had
>>
>> Recommends: mt-st, bacula-sd-sqlite3 (>= 5.0.2-2) | bacula-sd-tools
>
>  I wrote small patch as below, and works fine with piuparts.

I think that a better (and common with other situations,
i.e. mail-transport-agent) fix is the one suggested by Clint: one single
real package recommended.  This is a maintainer's choice, which as Clint
suggested, it was already made for the bacula-server package, i.e. the
sqlite3 backend.

John, two questions:

- have you any preference on the solution?

- do you mind if Hideki uploads its NMU?  This is a serious bug that
  affects squeeze as well...

> +bacula (5.0.2-2.1) unstable; urgency=low
^^^
This should be at least medium, given that the bug is severity serious,
but I could not find the documentation about that, sorry:

  Developer's Reference, § 5.13.2. Updates from unstable
  
http://www.debian.org/doc/manuals/developers-reference/pkgs.html#testing-unstable

>  Depends: ${shlibs:Depends}, mtx, python, lsb-base (>= 3.2-13), 
> ${misc:Depends}
> -Recommends: mt-st, bacula-sd-tools
> +Recommends: bacula-sd-sqlite3 (= ${binary:Version}) | bacula-sd-mysql (= 
> ${binary:Version}) |
> +bacula-sd-pgsql (= ${binary:Version}) | bacula-sd-tools, mt-st

What is the reason for a strict versioned Recommends?  The bacula-server
package has it in the form:

  bacula-sd-sqlite3 (>= ${source:Version}) | bacula-sd-tools

John, any comments or suggestions?

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#604231: chef-solr: installation fails with debconf noninteractive frontend

[Luca Capello]

retitle 604231 chef-solr: installation fails, unable to connect to node, 
nodedown
thanks

Hi there!

On Sun, 21 Nov 2010 11:14:05 +0100, Lucas Nussbaum wrote:
> While testing the installation of all packages in unstable, I ran
> into the following problem:
>
> Setting up chef-solr (0.8.16-4.1) ...
> Error: unable to connect to node 'rab...@parapluie-8': nodedown
> diagnostics:
> - nodes and their ports on parapluie-8: [{rabbitmqctl24301,59110}]
> - current node: 'rabbitmqctl24...@parapluie-8'
> - current node home dir: /var/lib/rabbitmq
> - current node cookie hash: fJiJth+YsTHJfj5ZQWvUSQ==
> Creating vhost "/chef" ...
> Error: unable to connect to node 'rab...@parapluie-8': nodedown
> diagnostics:
> - nodes and their ports on parapluie-8: [{rabbitmqctl24349,46122}]
> - current node: 'rabbitmqctl24...@parapluie-8'
> - current node home dir: /var/lib/rabbitmq
> - current node cookie hash: fJiJth+YsTHJfj5ZQWvUSQ==
> dpkg: error processing chef-solr (--configure):
>  subprocess installed post-installation script returned error exit status 2
> configured to not write apport reports
>   Errors were encountered while 
> processing:
>  chef-solr
> E: Sub-process /usr/bin/dpkg returned an error code (1)
>
> The full build log is available from:
>  http://people.debian.org/~lucas/logs/2010/11/20/chef-solr.log
>
> It is reproducible by installing your package in a clean chroot, using
> the debconf Noninteractive frontend, and priority: critical.

The problem is not the debconf frontend used, but the fact that the node
is down, given that it is reproducible on a cowbuilder chroot even with
an interactive debconf frontend:
=
(sid)r...@gismo:/# unset DEBIAN_FRONTEND
(sid)r...@gismo:/# apt-get install chef-solr
[...]
 Ĵ Configuring chef-solr 
�Ŀ
 � Please choose a password for the default user (named "chef") in the AMQP 
server queue, under the default RabbitMQ vhost  �
 � (also "/chef").  
�
 �  
�
 � RabbitMQ's rabbitmqctl program, which will be used to set this password, 
cannot read input from a file. Instead it will  �
 � be passed as a command-line argument, so the password should not include any 
shell meta-characters that could cause  �
 � errors, such as "!". 
�
 �  
�
 � Password for the AMQP user "chef":   
�
 �  
�
 � 

 �
 �  
�
 �  
�
 �  
�
 

Error: unable to connect to node rab...@gismo: nodedown
diagnostics:
- nodes and their ports on gismo: [{rabbitmqctl25863,47783}]
- current node: rabbitmqctl25...@gismo
- current node home dir: /var/lib/rabbitmq
- current node cookie hash: x1rh/KXp98TJcRmgh8eJTA==
Creating vhost "/chef" ...
Error: unable to connect to node rab...@gismo: nodedown
diagnostics:
- nodes and their ports on gismo: [{rabbitmqctl25892,45949}]
- current node: rabbitmqctl25...@gismo
- current node home dir: /var/lib/rabbitmq
- current node cookie hash: x1rh/KXp98TJcRmgh8eJTA==
dpkg: error processing chef-solr (--configure):
 subprocess installed post-installation script returned error exit status 2
configured to not write apport reports
  Setting up default-jre-headless 
(1:1.6-40) ...
Setting up ca-certificates-java (20100412) ...
creating /etc/ssl/certs/java/cacerts...
done.
Errors were encountered while processing:
 chef-solr
E: Sub-process /usr/bin/dpkg returned an error code (1)
(sid)r...@gismo:/#
=

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#602697: chef: remove from squeeze because of solr (#602697)? (was Re: Bug#602697: chef-solr depends on solr)

[Luca Capello]

clone 602697 -1
retitle -1 chef: remove from squeeze because of solr (#602697)?
found -1 0.8.16-4.1
block 602697 by -1
thanks

Hi there!

Cc:ing all the people that have interacted with this bug.

On Sun, 07 Nov 2010 14:52:24 +0100, Thomas Koch wrote:
> Adam D. Barratt:
>> On Sun, 2010-11-07 at 11:38 +0100, Thomas Koch wrote:
>> > I've written a mail ("Remove Solr from Squeeze?") on 2010/10/12 to
>> > debian-java and the package's maintainer Jan-Pascal van Best and
>> > proposed the removal of solr from Squeeze, mainly because:
>> > 
>> > - - it's already outdated a year by now (see bug #602696 )
>> > - - it doesn't even include all contribs (see bug #602695 )
>> > - - the package has accumulated too many bugs
>> > - - there doesn't seem to be enough (wo)man power to maintain the package
>> > 
>> >   right now on a standard that would make it fit for Debian _stable_
>> > 
>> > So until nothing else happens, please don't include solr in Debian
>> > squeeze.
>> 
>> The package has a reverse-dependency in testing already, so can't be
>> removed right now:
>> 
>> Checking reverse dependencies...
>> # Broken Depends:
>> chef: chef-solr
>
> to the maintainer of Chef in Debian,
>
> this is just to inform you, that there is a recommendation from me to remove 
> the solr package from Debian. However since chef-solr does depend on solr, 
> you'd affected by this removal.

Some hints about the chef package in Debian:

- Debian has (6-month-old) 0.8.16-4.1, while upstream is at 0.9.12
- popcon show 41 installation (2 recent) for the chef binary package and
  2 (0 recent) for the chef-solr binary package
- there is an RC bug for chef-solr (#604231, installation fails because
  of nodedown)

Thus, I think the best thing would be to remove chef from squeeze (new
bugs created), so then we can remove solr as well.

>> It's also in lenny (albeit in contrib) so if it were removed then a
>> migration path for those users to a replacement would be good.

Given that chef-solr was not in lenny, the above applies to solr only.
However, I should say that I do not know at all a good migration path.

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#601161: NMU for synce-serial (Re: Bug#601161: Some links, and some thoughts)

[Luca Capello]

tags 601161 + patch
thanks

Hi there!

On Tue, 16 Nov 2010 04:00:55 +0100, Asheesh Laroia wrote:
> I would say the most reasonable next step is to make synce-serial not
> build on GNU/kFreeBSD since ppp isn't available there. The same should
> probably be done to the ppp package.
[...]
> CC:ing Anarcat in case he has related thoughts.

On Tue, 16 Nov 2010 04:18:52 +0100, The Anarcat wrote:
> So I am not sure what opinion you are seeking for me, but I think it's
> safe to say that 'ppp' is not quite available right now in kFreeBSD.

Given that synce-serial Depends: on ppp, we should only build it on
those architectures that have the binary ppp package.

Here the patch for the NMU uploaded to DELAYED/2 (upgrade from lenny
tested):

--8<---cut here---start->8---
diff -Nru synce-serial-0.11/debian/changelog synce-serial-0.11/debian/changelog
--- synce-serial-0.11/debian/changelog  2010-10-19 07:31:42.0 +0200
+++ synce-serial-0.11/debian/changelog  2010-11-28 17:22:22.0 +0100
@@ -1,3 +1,12 @@
+synce-serial (0.11-5.2) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * debian/control:
++ build it only on those architectures that have the dependent
+  ppp binary package (Closes: #601161).
+
+ -- Luca Capello   Sun, 28 Nov 2010 17:22:22 +0100
+
 synce-serial (0.11-5.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru synce-serial-0.11/debian/control synce-serial-0.11/debian/control
--- synce-serial-0.11/debian/control2010-05-13 11:38:14.0 +0200
+++ synce-serial-0.11/debian/control2010-11-28 16:25:01.0 +0100
@@ -9,7 +9,7 @@
 Vcs-Git: git://git.jonnylamb.com/git/packaging/synce-serial.git
 
 Package: synce-serial
-Architecture: any
+Architecture: alpha amd64 armel armhf avr32 hppa i386 ia64 m68k mips mipsel 
powerpc powerpcspe s390 sh4 sparc sparc64 
 Depends: ${shlibs:Depends}, ${misc:Depends}, ppp (>= 2.4.2+20040202)
 Description: SynCE connection manipulation scripts
  This scripts are used to manipulate (start/stop/configure) a connection
--8<---cut here---end--->8---

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#603141: postgresql-8.4 and lenny upgrades (was Re: Bug#603141: dbi-link: fails to install due to incorrect dependencies in init.d LSB header)

[Luca Capello]

found 603141 8.4.4-1+b1
fixed 603141 8.4.4-2
thanks

Hi there!

On Thu, 11 Nov 2010 10:31:00 +0100, Holger Levsen wrote:
> during a test with piuparts I noticed your package failed to install due to 
> incorrect dependencies in the init.d LSB header. Some debian notes are 
> available from at http://wiki.debian.org/LSBInitScripts
>
> From the attached log (scroll to the bottom...):
>
>   Setting up postgresql-8.4 (8.4.4-1+b1) ...
   ^^
I could not find this version anymore, not in the postgresql-8.4's
debian/changelog nor in snapshots.d.o, where did it come from?

Please also note that at the time you sent the email, it seems that
squeeze already has 8.4.4-2:

  http://packages.qa.debian.org/p/postgresql-8.4/news/20100730T163913Z.html

>   insserv: script postgresql-8.4: service postgresql already provided!
>   insserv: exiting now!
>   update-rc.d: error: insserv rejected the script header

This was already reported (#585890, hey, by you!), solved in 8.4.4-2 (I
added the versions to the BTS):

--8<---cut here---start->8---
postgresql-8.4 (8.4.4-2) unstable; urgency=low

  * Migrate to a common init script for all server versions, to avoid
providing the "postgresql" service in multiple packages (which causes
insserv to complain bitterly):
- Drop debian/postgresql-8.4.init.
- debian/control: Bump dependency to postgresql-common to ensure we have a
  common /etc/init.d/postgresql init script.
- debian/postgresql-8.4.preinst: Remove/rename our init script on upgrade.  
- debian/postgresql-8.4.prerm: Call stop_version on upgrade.
- debian/rules: Drop dh_installinit arguments.
- (Closes: #585890)
--8<---cut here---end--->8---

> Please keep in mind that this was a test where first the lenny version was 
> installed and then an upgraded was done to squeeze. Also this bug is probably 
> just another duplicate of #603140, if so, please reassign there. (And sorry 
> for the noise.)

And yes, I would also say this was a duplicate of #603140, fixed in
postgresql-common_112.

On Wed, 24 Nov 2010 18:30:26 +0100, Holger Levsen wrote:
> On Mittwoch, 24. November 2010, Alexander Reichle-Schmehl wrote:
>> notfound 603141 2.0.0-3
> [...]
>> I'm quite sure that this is a failse positive, and therefore mark this
>> bug as done.
>
> A false-positive for dbi-link probably, but its a real bug when upgrading 
> from 
> lenny.

I tried to reproduce your upgrade bug, but with no success, both in
piuparts or in a cowbuilder lenny chroot:
=
(lenny)r...@gismo:/# apt-get install dbi-link
(lenny)r...@gismo:/# sed -i -e 's/lenny/squeeze/g' /etc/apt/sources.list
(lenny)r...@gismo:/# apt-get update && apt-get dist-upgrade
[...]
Setting up libyaml-perl (0.71-1) ...
Setting up dbi-link (2.0.0-3) ...
(lenny)r...@gismo:/# dpkg -l postgresql\*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version   
+++-=-=-
un  postgresql
un  postgresql-7.4
un  postgresql-8.0
ii  postgresql-8.38.3.12-0lenny1
ii  postgresql-8.48.4.5-0squeeze1
un  postgresql-client 
ii  postgresql-client-8.3 8.3.12-0lenny1
ii  postgresql-client-8.4 8.4.5-0squeeze1
ii  postgresql-client-common  112
ii  postgresql-common 112
un  postgresql-doc-8.3
un  postgresql-doc-8.4
ii  postgresql-plperl-8.3 8.3.12-0lenny1
ii  postgresql-plperl-8.4 8.4.5-0squeeze1
(lenny)r...@gismo:/#
=

However, I would like to note that an upgrade from lenny+backports to
squeeze is not possible, given that the version lenny-backports is
higher that the one in squeeze:
=
(lenny)r...@gismo:/# echo \
 "deb http://backports.debian.org/debian-backports lenny-backports main" \
 >>/etc/apt/sources.list
(lenny)r...@gismo:/# apt-get update
[...]
(lenny)r...@gismo:/# apt-get -t lenny-backports install postgresql-8.4
[...]
(lenny)r...@gismo:/# sed -i -e 's/lenny/squeeze/g' /etc/apt/sources.list
(lenny)r...@gismo:/# apt-get update
[...]
(lenny)r...@gismo:/# apt-cache policy postgresql-8.4
(lenny)r...@gismo:/# apt-cache policy postgresql-8.4
postgresql-8.4:
  Installed: 8.4.5-2~bpo50+1
  Candidate: 8.4.5-2~bpo50+1
  Version table:
 *** 8.4.5-2~bpo50+1 0
  1 http://backports.debian.org lenny-backports/main Packages
100 /var/lib/dpkg/status
 8.4.5-0squeeze1 0
500 http://cdn.debian.net squeeze/main Packages
(lenny)r...@gismo:/#
=

So, for the current title of this bug everything is OK, while for the
upgrade from lenny+backports this is not, I will leave it to the
postgresql-8.4 maintainers ;-)

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#601977: cyrus-sasl2-heimdal-dbg: file conflict during upgrade from lenny

[Luca Capello]

tags 601977 + patch
thanks

Hi there!

On Sun, 31 Oct 2010 15:42:29 +0100, Lucas Nussbaum wrote:
> Installing cyrus-sasl2-heimdal-dbg in a lenny chroot, then upgrading to
> squeeze, causes:
[...]
> dpkg: error processing 
> /var/cache/apt/archives/cyrus-sasl2-dbg_2.1.23.dfsg1-6_amd64.deb (--unpack):
>  trying to overwrite
> /usr/lib/debug/usr/lib/sasl2/libgssapiv2.so.2.0.23', which is also in
> package cyrus-sasl2-heimdal-dbg 2.1.23.dfsg1-6

Here the situation in lenny:
=
(lenny)r...@gismo:/# dpkg -L cyrus-sasl2-dbg | grep gssapi
/usr/lib/debug/usr/lib/sasl2/libgssapiv2.so.2.0.22
diverted by cyrus-sasl2-heimdal-dbg to: 
/usr/lib/debug/usr/lib/sasl2/libgssapiv2.so.2.0.22.mit
(lenny)r...@gismo:/#
=

This happens because cyrus-sasl2-heimdal-dbg is unpacked *before*
cyrus-sasl2-dbg, thus /u/l/debug/u/l/sasl2/libgssapiv2.so.2.0.23 is the
one shipped by the cyrus-sasl2-heimdal-dbg package.  It is (sort of)
funny that this happens because of two other NMU fixes (#530781 and
#590759).

Solutions...


1) cyrus-sasl2-heimdal-dbg Pre-Depends: cyrus-sasl2-dbg

   If we want to preserve the status quo, I guess this is the more
   logical solution, i.e. the non-heimdal package must be unpacked
   *before* the heimdal one.  However, technically speaking I do not
   think this will be ever accepted...

   FWIW, tested to work with the following patch:

--8<---cut here---start->8---
diff -u cyrus-sasl2-2.1.23.dfsg1/debian/changelog 
cyrus-sasl2-2.1.23.dfsg1/debian/changelog
--- cyrus-sasl2-2.1.23.dfsg1/debian/changelog
+++ cyrus-sasl2-2.1.23.dfsg1/debian/changelog
@@ -1,3 +1,12 @@
+cyrus-sasl2 (2.1.23.dfsg1-6.1) UNRELEASED; urgency=low
+
+  * Non-maintainer upload.
+  * debian/control:
++ in the cyrus-sasl2-heimdal-dbg binary package, move
+  cyrus-sasl2-dbg to Pre-Depends: (Closes: #601977).
+
+ -- Luca Capello   Sat, 27 Nov 2010 20:35:49 +0100
+
 cyrus-sasl2 (2.1.23.dfsg1-6) unstable; urgency=low
 
   * Acknowlge NMU (thanks to Ben Hutchings)
diff -u cyrus-sasl2-2.1.23.dfsg1/debian/control 
cyrus-sasl2-2.1.23.dfsg1/debian/control
--- cyrus-sasl2-2.1.23.dfsg1/debian/control
+++ cyrus-sasl2-2.1.23.dfsg1/debian/control
@@ -155,7 +155,8 @@
 Section: debug
 Architecture: any
 Priority: extra
-Depends: cyrus-sasl2-dbg (= ${binary:Version}), 
libsasl2-modules-gssapi-heimdal (= ${binary:Version}), ${misc:Depends}
+Pre-Depends: cyrus-sasl2-dbg (= ${binary:Version})
+Depends: libsasl2-modules-gssapi-heimdal (= ${binary:Version}), ${misc:Depends}
 Description: Debugging symbols for Cyrus SASL
  This is the Cyrus SASL API implementation, version 2. See package
  libsasl2-2 and RFC  for more information.
--8<---cut here---end--->8---


2) splitting the offending library out of the "common" cyrus-sasl2-dbg
   package into its own cyrus-sasl2-mit-dbg, which Conflicts: with
   cyrus-sasl2-heimdal-dbg.  This reflects the situation present with
   the runtime libraries and avoid any diversion at all.

   FWIW, tested to work with the following patch:

--8<---cut here---start->8---
diff -u cyrus-sasl2-2.1.23.dfsg1/debian/changelog 
cyrus-sasl2-2.1.23.dfsg1/debian/changelog
--- cyrus-sasl2-2.1.23.dfsg1/debian/changelog
+++ cyrus-sasl2-2.1.23.dfsg1/debian/changelog
@@ -1,3 +1,24 @@
+cyrus-sasl2 (2.1.23.dfsg1-6.1) UNRELEASED; urgency=low
+
+  * Non-maintainer upload.
+  * Fix for (Closes: #601977), the idea coming from Gaudenz Steinlin
+:
+* debian/control:
+  + cyrus-sasl2-dbg Depends: on one of the two GSSAPI dbg packages.
+  + new cyrus-sasl2-mit-dbg package which Conflicts: with
+cyrus-sasl2-heimdal-dbg.
+  + cyrus-sasl2-heimdal-dbg now Conflicts: with cyrus-sasl2-mit-dbg.
+* debian/cyrus-sasl2-heimdal-dbg.prerm:
+  - remove, useless.
+* debian/cyrus-sasl2-heimdal-dbg.postinst:
+  - remove, useless.
+* debian/cyrus-sasl2-mit-dbg.dirs:
+  + create /usr/lib/debug/usr/lib/sasl2/.
+* debian/rules:
+  + mv MIT libgssapiv2.so.2.0.23 into cyrus-sasl2-mit-dbg.
+
+ -- Luca Capello   Sun, 28 Nov 2010 03:57:38 +0100
+
 cyrus-sasl2 (2.1.23.dfsg1-6) unstable; urgency=low
 
   * Acknowlge NMU (thanks to Ben Hutchings)
diff -u cyrus-sasl2-2.1.23.dfsg1/debian/control 
cyrus-sasl2-2.1.23.dfsg1/debian/control
--- cyrus-sasl2-2.1.23.dfsg1/debian/control
+++ cyrus-sasl2-2.1.23.dfsg1/debian/control
@@ -141,7 +141,7 @@
 Section: debug
 Architecture: any
 Priority: extra
-Depends: libsasl2-2 (= ${binary:Version}), ${misc:Depends}
+Depends: libsasl2-2 (= ${binary:Version}), ${misc:Depends}, 
cyrus-sasl2-mit-dbg | cyrus-sasl2-heimdal-dbg
 Description: Cyrus SASL - debugging symbols
  This is the Cyrus SASL API implementation, version 2. See package
  libsasl2-2 and RFC  for more information.
@@ -151,11 +151,28 @@
  library or tools. You may be asked to install this package if you encounter
  such a crash.
 
+Package: 

Bug#568529: Bug#579519: grub-installer - Overwrites bootloaders on different device

[Luca Capello]

Hi there!

Cc:ing the three submitters, Colin who is GRUB maintainer and Miguel who
wrote the report for the debian-boot meeting where this bug was still
discussed.

On Sat, 30 Oct 2010 18:19:41 +0200, Gaudenz Steinlin wrote:
> You all reported issues with installing debian with debian-installer
> from usb sticks. The issue was that grub2 got installed on the mbr of
> the stick instead to the harddisk. But none of you sumitted a full
> installation log or more detailed information about your hardware.

I did not experience this bug, because even if I started d-i from a USB
stick, GRUB-2 installation stopped even before:

  http://bugs.debian.org/600671

> Even more usefull would be if you could retry the installation using
> the latest beta1 images:

I *wanted* to use my new shiny Intel SSD so this evening I tried to
debug the problem of the bug above and it was quite easy:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=600671#45

After that, I re-installed sid on the same SSD *twice*, always starting
d-i_squeeze_beta1 from the same USB stick and in both cases the GRUB-2
installation was perfectly fine.

FWIW, I previosly tested the same USB stick on QEMU with a virtual disk
and, again, GRUB-2 was correctly installed.

I have to perform at least another squeeze installation on an i386
computer, but since I am not sure it can boot from USB please do not
wait for my confirmation.

Thx, bye,
Gismo / Luca


pgpcJJ6PIBoJJ.pgp
Description: PGP signature

Bug#579460: clisp: diff for NMU version 1:2.48-1.2

[Luca Capello]

Package: clisp
Version: 1:2.48-1.2

Hi Alexander!

On Wed, 05 May 2010 11:07:25 +0200, Alexander Reichle-Schmehl wrote:
> I've prepared an NMU for clisp (versioned as 1:2.48-1.2) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.

Thank you for the fix, but I bet this problem was the same as bug
#565522, which is not in clisp, but in common-lisp-controller and its
dependency on cl-asdf:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565522#48

Briefly, c-l-c_7.1 depends on cl-asdf >= 1.625, but the epoch in cl-asdf
causes troubles:
=
l...@gismo:$ dpkg --compare-versions 1.625 lt 2:1.502-1 && echo OK
OK
l...@gismo:$
=

Anyway, given that the bug is fixed from a clisp POV, I am closing bug
#565522 since your upload indirectly fixed that as well, thank you
again!  Kenyon, feel free to reopen it in case of!

Thx, bye,
Gismo / Luca


pgpD5U8MSgJJ6.pgp
Description: PGP signature

Bug#571791: Can this be still be reproduced?

[Luca Capello]

Hi Pierre!

On Sun, 07 Mar 2010 20:05:06 +0100, Marco Túlio Gontijo e Silva wrote:
> I installed the newest version of clisp and I got not problem in the
> configuration step.  Can anyone reproduce this bug?

I can not reproduce it in a clean squeeze chroot, setting the locale to
fr_FR.UTF8 as Pierre.  This does not mean that the bug is not a bug (or
is it solved), however.

Thx, bye,
Gismo / Luca


pgpxVosDWQmUv.pgp
Description: PGP signature

Bug#527840: Preparing an NMU for xpdf?

[Luca Capello]

Hi there!

I am a happy Xpdf user, for various reasons, the first one being is its
small number of dependencies:

=
r...@gismo:/# apt-get install xpdf
[...]
The following NEW packages will be installed:
  defoma file gsfonts lesstif2 libfreetype6 libice6 libmagic1
  libnewt0.52 libpaper1 libpopt0 libsm6 libt1-5 libx11-6
  libx11-data libxau6 libxcb1 libxdmcp6 libxext6 libxp6 libxpm4 libxt6
  ucf whiptail x11-common xpdf xpdf-common xpdf-reader
  xpdf-utils
0 upgraded, 28 newly installed, 0 to remove and 0 not upgraded.
Need to get 9970kB of archives.
After this operation, 27.0MB of additional disk space will be used.
Do you want to continue [Y/n]? n
Abort.

r...@gismo:/# apt-get install epdfview poppler-utils
[...]
The following NEW packages will be installed:
  defoma epdfview file fontconfig fontconfig-config libatk1.0-0
  libavahi-client3 libavahi-common-data libavahi-common3
  libcairo2 libcups2 libdatrie1 libdbus-1-3 libdirectfb-1.2-0
  libfontconfig1 libfreetype6 libglib2.0-0 libgssapi-krb5-2
  libgtk2.0-0 libgtk2.0-common libjasper1 libjpeg62 libk5crypto3
  libkeyutils1 libkrb5-3 libkrb5support0 liblcms1 libmagic1
  libnewt0.52 libopenjpeg2 libpango1.0-0 libpango1.0-common libpcre3
  libpixman-1-0 libpng12-0 libpoppler-glib4 libpoppler5
  libpopt0 libsysfs2 libthai-data libthai0 libtiff4 libts-0.0-0 libx11-6
  libx11-data libxau6 libxcb-render-util0
  libxcb-render0 libxcb1 libxcomposite1 libxcursor1 libxdamage1
  libxdmcp6 libxext6 libxfixes3 libxft2 libxi6 libxinerama1
  libxml2 libxrandr2 libxrender1 poppler-utils shared-mime-info tsconf
  ttf-dejavu-core ucf whiptail
0 upgraded, 67 newly installed, 0 to remove and 0 not upgraded.
Need to get 23.4MB of archives.
After this operation, 66.0MB of additional disk space will be used.
Do you want to continue [Y/n]? n
Abort.

r...@gismo:/#
=

While I agree that on any modern system most of the epdfview
dependencies will be anyway installed, the same is true for Xpdf as
well.  And the 2/3 times I tried to move to epdfview I was quite
unsatisfied (let Evince out from this...).

Anyway, I am now in a situation where either I move away from Xpdf or I
fix the bugs which are blocking CUPS upgrades on my sid:

  http://bugs.debian.org/557885
  http://bugs.debian.org/558020

I was preparing an NMU for #558020 when I discovered an FTBFS bug,
with a patch available in another bug (I have merged the two bugs):

  http://bugs.debian.org/528807
  http://bugs.debian.org/458763

The patch Moritz attached to #458763 is enough for Xpdf to build again.
Thus, my plan would be to upload an NMU that fixes both #458763 and
#558020.  While I was at it, I gave a look at other bugs in the BTS and
found that #495150, #551544 and #515495 can be easily included as well.

Rogério, should I go ahead with the NMU or a new upload is expected
really soon?  Or, better, would you like to prepare an NMU for the bugs
above based on your debian/changelog?  I will be happy to sponsor it, if
needed.

Thx, bye,
Gismo / Luca


pgpZ6RPwkDP3e.pgp
Description: PGP signature

Bug#536915: stumpwm: FTBFS: stumpwm.texi: No such file or directory

[Luca Capello]

tags 536915 + pending
thanks

Hi Lucas!

On Tue, 14 Jul 2009 15:51:41 +0200, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
[...]
>> ; compilation aborted because of fatal error:
>> ;   READ failure in COMPILE-FILE:
>> ; SB-INT:SIMPLE-READER-PACKAGE-ERROR at 7134 (line 149, column 49) on 
>> #> /build/user-stumpwm_20090502.git482df740-1-amd64-xV3Jo4/stumpwm-20090502.git482df740/wrappers.lisp"
>>  {1002EE3CA1}>:
>> ;   Symbol "UNIX-NAMESTRING" not found in the SB-INT package.; compiling 
>> (DEFUN (SETF GETENV) ...)
>> ; compilation aborted after 0:00:00.044
[...]
>> stumpwm.texi: No such file or directory
>> * makeinfo stumpwm.texi
>> make[1]: *** [stumpwm.info] Error 1

This was caused by a change in new SBCL, fixed upstream:

  http://lists.gnu.org/archive/html/stumpwm-devel/2009-06/msg00017.html

Since I am uploading a new upstream checkout, everything should be fixed
for Debian as well (successfully tested on a clean amd64 chroot):

  
http://git.debian.org/?p=pkg-common-lisp/stumpwm.git;a=commitdiff;h=7b2ef496f3032cbf35bce797681b428e349ac90b

Thx, bye,
Gismo / Luca


pgpi3nwsg5akk.pgp
Description: PGP signature

Bug#521906: clisp: FTBFS: 'DB_DIRECT_LOG' undeclared

[Luca Capello]

severity 494587 serious
merge 494587 521906
thanks

Hi Daniel!

On Mon, 30 Mar 2009 22:13:39 +0200, Daniel Schepler wrote:
> Package: clisp
> Version: 1:2.44.1-4.1
> Severity: serious
>
>>From my pbuilder build log:
[...]
> bdb.c:703: error: 'DB_DIRECT_LOG' undeclared (first use in this function)

This was already reported as bug #494587 [1], merged.

I am experiencing some problems compiling 2.47 [2], but once I have
solved them, I will backport the BDB upstream patch.

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://bugs.debian.org/494587
[2] 
http://lists.alioth.debian.org/pipermail/pkg-common-lisp-devel/2009-April/001232.html


pgp1tLLLmoFNC.pgp
Description: PGP signature

Bug#517205: fixed in slime 1:20090409-1

[Luca Capello]

Hi Peter!

On Fri, 24 Apr 2009 08:38:54 +0200, Peter Van Eynde wrote:
> Evgeny M. Zubok wrote:
>> Peter Van Eynde  writes:
>>
>>>* Removed xref.lisp again and added a test in the makefile for it
>>>  (Closes: #517205)
>>
>> And what about Lenny? Does this DFSG violation need a fix in stable
>> distribution?
>
> Good question.
>
> $ tar zft slime_20080223.orig.tar.gz | grep xref
> slime-20080223/contrib/slime-xref-browser.el
> slime-20080223/xref.lisp
>
> Damn. We have the problem in stable too. I'll prepare a fix for that...
> But how. As I need to use a new 'upstream' version, I would have to use
> a new epoch... not?

I would just repackage upstream as 20080223:
=
l...@gismo:~$ dpkg --compare-versions 1:20080223-2 lt 1:20080223.dfsg-1 && echo 
OK
OK
l...@gismo:~$
=

Thx, bye,
Gismo / Luca


pgpjuIoa4lTMf.pgp
Description: PGP signature

Bug#518877: libsigsegv: FTBFS: autoconf version mismatch

[Luca Capello]

tags 518877 + pending
thanks

Hi Peter!

On Sat, 21 Mar 2009 04:55:54 +0100, peter green wrote:
> The attatched patch makes the package use autoreconf rather than
> autoconf so all the autotools stuff is regenerated consistantly.

Thank you, applied:

http://git.debian.org/?p=pkg-common-lisp/libsigsegv.git;a=commitdiff;h=00ccc3a8e4364496513ce1fe45c46972d7c4fe0f

Thx, bye,
Gismo / Luca


pgpnPqm5Jt6xW.pgp
Description: PGP signature

Bug#517839: slime: SLIME fails to upgrade

[Luca Capello]

tags 517839 + upstream
thanks

Hi Christoph!

Cc:ing the slime-devel mailing list, since this is an upstream issue
(already reported, read below).  Please keep the Debian BTS as cc:ed (no
subscription requnired).

On Mon, 02 Mar 2009 14:09:10 +0100, Christoph Egger wrote:
>   Updating SLIME in testing fails on configuration. See the aptitude
> output attached to this mail.

Please always set LANG=C when you provide logs, since it is difficult to
parse foreign languages ;-)

I can reproduce the bug on a clean cowbuilder chroot: first, I created
it for lenny, then installed slime together with xemacs21 and emacs22
(no errors).  After that I modified apt's sources.list to point to
testing:
=
r...@gismo:/# apt-get update
Get:1 http://cdn.debian.net testing Release.gpg [197B]
Get:2 http://cdn.debian.net testing Release [71.6kB]
Get:3 http://cdn.debian.net testing/main Packages [5533kB]
Fetched 5604kB in 11s (497kB/s)
Reading package lists... Done

r...@gismo:/# apt-get dist-upgrade
[...]
The following packages will be upgraded:
  aptitude base-files bash binutils cl-swank cowdancer cpio cpp cpp-4.3
  debconf debconf-i18n debianutils fakeroot findutils g++ g++-4.3 gcc
  gcc-4.3 gcc-4.3-base gnupg gpgv grep gzip libc6 libc6-dev libdb4.6
  libept0 libgcc1 libgcrypt11 libgdbm3 libgmp3c2 libgnutls26 libgomp1
  libice6 libmpfr1ldbl libncurses5 libncursesw5 libreadline5 libsepol1
  libsm6 libstdc++6 libstdc++6-4.3-dev libtasn1-3 libxapian15 libxau6
  libxaw7 mawk mktemp ncurses-base ncurses-bin pbuilder readline-common
  realpath sed slime tzdata
56 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 37.5MB/38.7MB of archives.
After this operation, 3084kB of additional disk space will be used.
Do you want to continue [Y/n]? y
[...]
=

> Compiling /usr/share/xemacs21/site-lisp/slime/slime.el...
> While compiling toplevel forms in file 
> /usr/share/xemacs21/site-lisp/slime/slime.el:
>   !! error (("Required feature arc-mode was not provided"))
>>>Error occurred processing slime.el: 
> Required feature arc-mode was not provided

This is the problem, specific to xemacs21 and not emacs22.  The problem
is in slime.el at line 69:

--8<---cut here---start->8---
  (require 'overlay))
(require 'easymenu)
(eval-when (compile)
  (require 'arc-mode)
  (require 'apropos)
  (require 'outline)
  (require 'etags))
--8<---cut here---end--->8---

This has already been reported upstream, see the discussion at

  http://common-lisp.net/pipermail/slime-devel/2008-October/015633.html

Quoting Helmut Heller from the thread above:

--8<---cut here---start->8---
On Mon, 27 Oct 2008 19:49:13 +0100, Helmut Eller wrote:
> * Steven E. Harris [2008-10-27 00:21+0100] writes:
>
>>> Byte-compilation doesn't work in XEmacs, though.
>>
>> In general, or as a result of this change? Before my last post, I was
>> able to byte-compile slime.el when I commented out the `require' form,
>> but I concede that I didn't test the result.
>
> It doesn't work because arc-mode.el in XEmacs provides 'archive-mode
> instead of 'arc-mode.
--8<---cut here---end--->8---

Since on Debian we byte-compile emacsen files at installation, I do not
know how to proceed here.

Is not this a bug in XEmacs?  I would say so and thus reassign the bug
to xemacs21.

Thx, bye,
Gismo / Luca


pgp4wFIQIJH3O.pgp
Description: PGP signature

Bug#517434: HP LasetJet 1018 won't print

[Luca Capello]

Hi Daniel!

On Thu, 05 Mar 2009 08:21:37 +0100, Daniel Schröter wrote:
> Luca Capello wrote:
>> On Wed, 04 Mar 2009 18:39:43 +0100, Андрей Парамонов wrote:
>>>
>>> I've just tried to downgrade the hplip and related packages from
>>> 2.8.12-3 to 2.8.6.b-4, and the printing works again! So, the problem
>>> is actually in the new version of hplip, not in foo2zjs.
>>
>> Daniel, can you confirm it, please?
>
> Conformed!
> Downgrading
> hpijs 2.8.12-3 to 2.8.6.b-4
> hplip 2.8.12-3 to 2.8.6.b-4
> hplip-data 2.8.12-3 to 2.8.6.b-4
> and(!) restarting cups let's the printer print again :-D

Good to know, thank you.

> Someone fills a bug for hplip?

No need, Andrey already reassigned this bug to hplip:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=32;bug=517434

Thx, bye,
Gismo / Luca


pgpHNkEABNNc2.pgp
Description: PGP signature

Bug#517434: HP LasetJet 1018 won't print

[Luca Capello]

Hi Andrey!

The next time that you provide such kind of information, which is
*vital* for a bug, please send it to the bug as well and not only to
cont...@b.d.o, since I needed to open the bug report in order to
understand why the bug was reassigned:

  
http://lists.alioth.debian.org/pipermail/foo2zjs-maintainer/2009-March/000385.html

On Wed, 04 Mar 2009 18:39:43 +0100, Андрей Парамонов wrote:
> reassign 517434 hplip 2.8.12-3
> thanks
>
> I've just tried to downgrade the hplip and related packages from
> 2.8.12-3 to 2.8.6.b-4, and the printing works again! So, the problem
> is actually in the new version of hplip, not in foo2zjs.

Thank you for the information.  Daniel, can you confirm it, please?

Thx, bye,
Gismo / Luca


pgp96F530Zvmx.pgp
Description: PGP signature

Bug#508707: zhone fails to load on latest

[Luca Capello]

forcemerge 508707 508710
thanks

Hi Brendan!

Please read carefully the instruction at [1], so the pkg-fso-maint
mailing list receives a copy of your bugs.

[1] 
http://wiki.debian.org/DebianOnFreeRunner#head-c33d5a71a5654ad5592accc5e699ec6f64933582

On Sun, 14 Dec 2008 14:36:37 +0100, Brendan Johan Lee wrote:
> Installed a clean debian today, and zhone never managed to load, even
> on a clean system. I think I've tracked down the error to be a python
> function that with an empty return statemante.
[...]
> debian-gta02:~# zhone
> Traceback (most recent call last):
>   File "/usr/bin/zhone", line 896, in 
> class pyphone_location( edje_group ):
>   File "/usr/bin/zhone", line 898, in pyphone_location
> class SignalGraph( evas.ClippedSmartObject ):
>   File "evas.c_evas_object_smart.pxi", line 184, in
> evas.c_evas.EvasSmartObjectMeta.__init__ (evas/evas.c_evas.c:29553)
> SystemError: NULL result without error in PyObject_Call

I do not remember I have experienced this bug, but I clearly remember
this was discussed on the smartphones-userland mailing list [2].

[2] 
http://lists.linuxtogo.org/pipermail/smartphones-userland/2008-December/000718.html

That discussion led to bug #508697 [3], of which I think both this one
(#508707 [4]) and the same other you submitted (#508710 [5]) are
duplicate.

[3] http://bugs.debian.org/508697#10
[4] http://bugs.debian.org/508707
[5] http://bugs.debian.org/508710

Can someone more involved with E stuff confirm my feelings above,
please?  In case I am wrong, then I think zhone needs a versioned
dependency on python-evas.

Thx, bye,
Gismo / Luca


pgpxQNkiVrKSi.pgp
Description: PGP signature

Bug#477923: [Foo2zjs-maintainer] Bug#477923: marked as done (foo2zjs: Hotplug firmware not loaded because of switch to udev)

[Luca Capello]

severity 477923 important
thanks

Hi ilf!

On Sat, 27 Dec 2008 16:45:04 +0100, ilf wrote:
> On 12-22 13:09, Debian Bug Tracking System wrote:
>> and subject line Bug#477923: fixed in foo2zjs 20070718dfsg-9
>> has caused the Debian Bug report #477923,
>> regarding foo2zjs: Hotplug firmware not loaded because of switch to udev
>> to be marked as done.
>
> I think the severity of this Bug classifies as "grave", since it does
> make it mostly unusable.

Please re-read the severity definition at [1]: while I think the correct
severity is important (and I set it as well).

  grave
makes the package in question unusable or mostly so, or causes data
loss, or introduces a security hole allowing access to the accounts
of users who use the package.

  important
a bug which has a major effect on the usability of a package,
without rendering it completely unusable to everyone.

Rationale: out of the 20 printers supported by version 20070718dfsg-9,
only 4 of them are affected by this bug, which means that some users are
not affected.

> I would like to see this fixed for Lenny, especially since the package
> with it fixed (foo2zjs/20070718dfsg-9) would be almost ready for
> testing anyways.
>
> Do any of the maintainers agree with this and want to contact
> debian-release please?

I think it was quite clear from my first reply to you [2] that I wanted
to fix this bug for lenny: this is why I cc:ed d-release in primis and
wait for their reply (thanks to Luk) before any action.

I prepared a package and asked to test it [3] (unfortunately, I do not
have any of the affected printers), but no one replied.  Finally, I
anyway updated the package to unstable and I have already planned to ask
for a freeze exception.  I have not done it yet because anyway the
package needs 10 days in unstable before any possible migration.

So, yes, expect to read an unblock request on the foo2zjs-maintainer
list very soon :-D

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://www.debian.org/Bugs/Developer
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477923#22
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477923#32


pgppdRGMVfBKK.pgp
Description: PGP signature

Bug#508476: xserver-xorg-core: Cannot run in framebuffer mode. Please specify busIDs for all framebuffer devices

[Luca Capello]

Package: xserver-xorg-core
Version: 2:1.5.3-1
Severity: grave

Hi there!

I tried a configless situation with the latest X.Org in experimental,
but this resulted in X not starting at all:
=
luca$gismo:~$ startx


X.Org X Server 1.5.3
Release Date: 5 November 2008
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.17.7 x86_64 Debian
Current Operating System: Linux gismo.pca.it 2.6.27-1-amd64 #1 SMP Wed Dec 10 
04:03:39 UTC 2008 x86_64
Build Date: 12 November 2008  12:59:43PM
xorg-server 2:1.5.3-1 (bui...@xenophanes) 
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Thu Dec 11 01:04:20 2008
(EE) Unable to locate/open config file
New driver is "intel"
(==) Using default built-in configuration (30 lines)

Fatal server error:
Cannot run in framebuffer mode. Please specify busIDsfor all 
framebuffer devices

giving up.
xinit:  No such file or directory (errno 2):  unable to connect to X server
xinit:  No such process (errno 3):  Server error.

l...@gismo:~$
=

I do not remember why I have installed the X.Org fbdev, but simply
removing it (version 1:0.4.0-2 from experimental) lets X starts.

I am not completely sure the severity is correct, but from what I
understood X tries to use every driver is installed, which does not
sound correct to me.

BTW1, in the information below, I substituted the Xorg.0.log with the
  one coming from the non-starting X

BTW2, why does X consider not having a config file an non-fatal error?
  Should not that be a warning instead?

Thx, bye,
Gismo / Luca

-- Package-specific info:
Contents of /var/lib/x11/X.roster:
xserver-xorg

/var/lib/x11/X.md5sum does not exist.

X server symlink status:
lrwxrwxrwx 1 root root 13 2008-10-13 18:41 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 1797392 2008-11-12 14:14 /usr/bin/Xorg

Contents of /var/lib/x11/xorg.conf.roster:
xserver-xorg

VGA-compatible devices on PCI bus:
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 
943/940GML Express Integrated Graphics Controller (rev 03)

/etc/X11/xorg.conf does not exist.

Xorg X server log files on system:
-rw-r--r-- 1 root root 22434 2008-12-11 02:13 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file
/var/log/Xorg.0.log:

X.Org X Server 1.5.3
Release Date: 5 November 2008
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.17.7 x86_64 Debian
Current Operating System: Linux gismo.pca.it 2.6.27-1-amd64 #1 SMP Wed Dec 10 
04:03:39 UTC 2008 x86_64
Build Date: 12 November 2008  12:59:43PM
xorg-server 2:1.5.3-1 (bui...@xenophanes) 
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Thu Dec 11 01:02:06 2008
(EE) Unable to locate/open config file
(II) Loader magic: 0x7b1ec0
(II) Module ABI versions:
X.Org ANSI C Emulation: 0.4
X.Org Video Driver: 4.1
X.Org XInput driver : 2.1
X.Org Server Extension : 1.1
X.Org Font Renderer : 0.6
(II) Loader running on linux
(--) using VT number 7

(--) PCI:*(0...@0:2:0) Intel Corporation Mobile 945GM/GMS, 943/940GML Express 
Integrated Graphics Controller rev 3, Mem @ 0xee10/524288, 
0xd000/268435456, 0xee20/262144, I/O @ 0x1800/8
(--) PCI: (0...@0:2:1) Intel Corporation Mobile 945GM/GMS/GME, 943/940GML 
Express Integrated Graphics Controller rev 3, Mem @ 0xee18/524288
(II) Scanning /usr/share/xserver-xorg/pci directory for additional PCI ID's 
supported by the drivers
(II) Matched intel from file name intel.ids
(==) Matched intel for the autoconfigured driver
New driver is "intel"
(==) Using default built-in configuration (30 lines)
(==) --- Start of built-in configuration ---
Section "Device"
Identifier  "Builtin Default intel Device 0"
Driver  "intel"
EndSection
Section "Screen"
Identifier  "Builtin Default intel Screen 0"
Device  "Builtin Default intel Device 0"
EndSection
Section "Device"
Identifier  "Builtin Default fbdev Device 0"
Driver  "fbdev"
EndSection
Section "Screen"
Identifier  "Builtin Default fbdev Screen 0"
Device  "Builtin Default fbdev Device 0"
EndSection
Section "Device"
Identifier  "Builtin Default vesa Device 0"
Driver  "vesa"
EndSec

Bug#505196: NMUing kpax?

[Luca Capello]

Hi Thomas!

On Sat, 22 Nov 2008 20:22:24 +0100, Thomas Viehmann wrote:
> I'm not sure why we have the urgent desire to release with stuff that
> "is quite mature and has been in production use for years, the
> documentation is currently not good enough to support use by the
> general public" per the package description,

As I already did for cl-geodesics [1], if the software is working I
would like to keep it in the next stable release.

> but if we're going to keep it and the maintainers, let's say, are
> exceptionally busy in November,

The maintainers are exceptionally busy because ATM I am the only one
available.  I have already called for help in the past, but no one has
volunteered yet, thus I try to keep up as much as I can.

> could you prepare this as an NMU to sponsor?

FWIW, the Debian Common Lisp Team is already on the LowThresholdNmu [2],
thus every NMU is welcome.  In case the NMU is ready I can sponsor them
as well, since it is easier to check the NMU than digging into any bug.

Now, going back to this particular bug...

On Wed, 19 Nov 2008 20:45:27 +0100, Peter De Wachter wrote:
> Wed Nov 19 20:29:46 CET 2008  Peter De Wachter <[EMAIL PROTECTED]>
>   * Added cl-ironclas dependency.
>   There's still one missing dependency: s-http-client (for the
>   kpax-examples system), but that library isn't packaged yet.

Peter, thank you for the patch, but could you please prepare another one
without the comment about the last missing dependency?  It has nothing
to do with the single patch, which BTW I would call something like

  * debian/control: (Closes: #505196) add cl-ironclad to Depends:

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://lists.debian.org/debian-release/2008/10/msg01113.html
[2] http://wiki.debian.org/LowThresholdNmu


pgpgTd1qML5PV.pgp
Description: PGP signature

Bug#503814: [Foo2zjs-maintainer] foo2zjs

[Luca Capello]

Hi there!

Can you please keep the foo2zjs-maintainer mailing list cc:ed?  If you
do so, no need to cc: me, I read the list.  TIA.

I'm sorry for the long mail: I performed more tests with the only
foo2zjs printer I have [1] and I found some interesting stuff, please
read below.  I tried to be as more detailed as I could, at least to give
a better overview of the foo2zjs driver status.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466758#15

On Sat, 01 Nov 2008 09:47:21 +0100, Anthony Towns wrote:
> On Fri, Oct 31, 2008 at 03:52:31PM +0100, Andreas Barth wrote:
>> 2.  As per constitution, we (the tech ctte) only makes decision as last
>> resort. So currently, the next step would be for anyone who disagrees
>> with this bug not being release critical to ask the release team to
>> review the decision and maybe overrule it.
>
> I'm not sure I'd want the release team to be able to stop the tech-ctte
> from being involved simply by not making a decision, so I'm not sure I
> agree with this precisely. But in the general case, yes, I'd rather see
> the release team making the call on this.

FYI, the Release Team was asked for an advice on Sun, 26 October [2].
However, I know we (the Debian foo2zjs maintainers) decided to go to the
tech-ctte just two days later...

[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=yes&bug=503814#125

>> tech ctte members, any opinion from you on that?
>
> Basically, +1.
>
> On a technical level, it seems to me there's two aspects:
>
>(1) can a package in main include a script that gets stuff from some
>random website really be considered DFSG-free/policy-compliant?

NB, in this case it is not "from some random website", but it is from
*upstream* website, which means that these data are not included in the
upstream sources for other reasons.

Anyway, if the script is moved to /u/s/d/$PKG/examples I would say it is
OK for the package to be in main.  And, again, I think the main point is
if printers can work without those data, read below.

>(2) should we make sure that the stuff on the random website is also
>available from somewhere in Debian, in case the random website gets
>shut down, etc?

If there are licensing issues, I see no advantages for Debian in
distributing them.  Here what the getweb script from the last tested
upstream version [1] would download:

- not strictly required files (not fully sure, but read below for my
  experience with the HP Color LaserJet 1500L)

$ ./getweb 2600n# Get HP Color LaserJet 2600n .ICM files
$ ./getweb 1600 # Get HP Color LaserJet 1600 .ICM files
$ ./getweb 1500 # Get HP Color LaserJet 1500 .ICM files
$ ./getweb 1215 # Get HP Color LaserJet CP1215 .ICM files

$ ./getweb 2530 # Get Konica Minolta 2530 DL .ICM files
$ ./getweb 2490 # Get Konica Minolta 2490 MF .ICM files
$ ./getweb 2480 # Get Konica Minolta 2480 MF .ICM files
$ ./getweb 6115 # Get Xerox Phaser 6115MFP .ICM files

$ ./getweb 2430 # Get Konica Minolta 2430 DL .ICM files
$ ./getweb 2300 # Get Minolta 2300 DL .ICM files
$ ./getweb 2200 # Get Minolta 2200 DL .ICM files
$ ./getweb cpwl # Get Minolta Color PageWorks/Pro L .ICM files

$ ./getweb 300  # Get Samsung CLP-300 .ICM files
$ ./getweb 315  # Get Samsung CLP-315 .ICM files
$ ./getweb 600  # Get Samsung CLP-600 .ICM files
$ ./getweb 610  # Get Samsung CLP-610 .ICM files
$ ./getweb 2160 # Get Samsung CLX-2160 .ICM files
$ ./getweb 3160 # Get Samsung CLX-3160 .ICM files
$ ./getweb 6110 # Get Xerox Phaser 6110 and 6110MFP .ICM files

$ ./getweb 500  # Get Lexmark C500 .ICM files

$ ./getweb 3200 # Get Oki C3200 .ICM files
$ ./getweb 3300 # Get Oki C3300 .ICM files
$ ./getweb 3400 # Get Oki C3400 .ICM files
$ ./getweb 3530 # Get Oki C3530 MFP .ICM files
$ ./getweb 5100 # Get Oki C5100 .ICM files
$ ./getweb 5200 # Get Oki C5200 .ICM files
$ ./getweb 5500 # Get Oki C5500 .ICM files
$ ./getweb 5600 # Get Oki C5600 .ICM files
$ ./getweb 5800 # Get Oki C5800 .ICM files

- firmwares needed for the print to work (the problem with these files
  should be the same about "kernel" firmwares)

$ ./getweb 1020 # Get HP LJ 1020 firmware file
$ ./getweb 1018 # Get HP LJ 1005 firmware file
$ ./getweb 1005 # Get HP LJ 1005 firmware file
$ ./getweb 1000 # Get HP LJ 1000 firmware file

$ ./getweb p1505# Get HP LJ P1505 firmware file
$ ./getweb p1008# Get HP LJ P1008 firmware file
$ ./getweb p1007# Get HP LJ P1007 firmware file
$ ./getweb p1006# Get HP LJ P1006 firmware file
$ ./getweb p1005# Get HP LJ P1005 firmware file

$ ./getweb 2300dl_fw # Get Minolta 2300DL v2.55 firmware (experts only)

> (1) seems to be resolved as per Andi's comments, but I kind-of think
> (2) is actually the more important is

Bug#503814: [Foo2zjs-maintainer] Bug#449497: foo2zjs: getweb script depends on non-free firmware

[Luca Capello]

Hi Michael!

Adding the d-release mailing list to cc:.

On Fri, 31 Oct 2008 13:41:25 +0100, Michael Gilbert wrote:
> i'll go ahead and start the discussion since no one else is running
> with it.  this matter is rather urgent since the problem is now being
> considered release-critical for lenny.
[...]
> let me again stress that action is URGENT since this is
> release-critical for lenny.

Can you please stop dealing with this bug and let the tech-ctte [1] do
their work?

About the urgency and lenny: the bug is marked as serious, which means
that if the tech-ctte does not fix it before lenny (something which I do
not think is going to happen), the Release Team must deal with it.

FYI, other people have already started to work on it, check the thread
on the d-ctte mailing list [2].

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://www.debian.org/devel/tech-ctte
[2] http://lists.debian.org/debian-ctte/2008/10/msg0.html


pgpldEY8q46y5.pgp
Description: PGP signature

Bug#503367: [Debian-med-packaging] Bug#503367: Bug#503367: Bug#503367: plink: file conflict with putty-tools

[Luca Capello]

Hi there!

On Tue, 28 Oct 2008 15:58:20 +0100, Andreas Tille wrote:
> On Tue, 28 Oct 2008, Steffen Möller wrote:
>> Except that snplink is taken by another program
>
> This is a valid point and should probably be discussed with plink
> (and snplink??) authors.

FWIW both software have been published in scientific papers, thus
changing one name or the other can be more difficult.

However, while Steffen's point is valid, it's not problematic ATM, since
we don't have the "other" snplink [1] in Debian yet.

>> With an increasing number of applications in
>> Debian I am certain that b) or c) will be needed sooner or later,
>
> I do not think so.  IMHO the Debian maintainer has the duty to teach
> upstream about problems.
[...]
> So the user might face problems we just detected in Debian and could
> have solved by informing upstream that there is a name space polution
> in the Free Software name space which really should be avoided.

Fully ACK, something like "population-link" or "wgaplink" [2] would have
been clearly better [3].

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://bioinformatics.oxfordjournals.org/cgi/content/full/21/13/3060
[2] the title of the paper being "PLINK: a toolset for whole-genome
association and population-based linkage analysis"
  http://pngu.mgh.harvard.edu/~purcell/plink/contact.shtml#cite
[3] yes, I know it's sound worse than "plink", but it's at least an
acronym of the title of the paper


pgpyycB2cSHmK.pgp
Description: PGP signature

Bug#503367: [Debian-med-packaging] Bug#503367: Bug#503367: Bug#503367: plink: file conflict with putty-tools

[Luca Capello]

Hi Steffen!

Disclaimer: I'm a biologist [1] and I performed genome-wide analyses.

On Tue, 28 Oct 2008 12:00:02 +0100, Peter Palfrader wrote:
> Steffen Möller schrieb am Dienstag, dem 28. Oktober 2008:
>> To summarise things up: the renaming of the executable of plink to
>> snplink renders the plink package inferior to a manual installation of
>> plink under the proper name.

From a *very* quick read of the plink webpage [2], I understand that
plink mainly deals with SNPs [3].  Thus I don't see the rename as
something inferior, on the contrary it helps better understanding what
the binary does [4].

>> What I'll do now unless I hear some objections that I am mentally
>> prepared to follow: I'll prepare the new version, add the conflict to
>> debian/control to close 503367 (won't fix) and herewith truly
>> apologize for all these emails.
>
> The packages provide different functionality.  They should therefore not
> conflict.
[...]
> Tho I think that putty being the more senior one should have the right
> of the name and not be forced to rename its binaries.

Fully ACK, on both sentences.

FWIW, according to [5], plink has been included in PuTTY since version
beta 0.50 (released 2000/10/16).  The oldest Debian version I could find
is 0.57-1 (2005/03/13), which already contains /usr/bin/plink.

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://www.unige.ch/irlab
[2] http://pngu.mgh.harvard.edu/~purcell/plink/index.shtml
[3] http://en.wikipedia.org/wiki/Single_nucleotide_polymorphism
[4] I agree that for someone not in genetics this is not true
[5] http://www.chiark.greenend.org.uk/~sgtatham/putty/changes.html
[6] http://snapshot.debian.net/putty


pgpb8a9kMjmnK.pgp
Description: PGP signature

Bug#449497: [Foo2zjs-maintainer] Bug#449497: TC proposal for dispute

[Luca Capello]

Hi there!

I put back d-release to the cc: list, since we previously asked for
their help on this matter.

On Mon, 27 Oct 2008 11:01:31 +0100, Steffen Joeris wrote:
> I am upset that you again raised the severity without consulting
> anyone.

Which, sadly, went against my specific request to not play the
severity-change game anymore [1].

> The package as it stands is DFSG free and the getweb script is there
> for the convenience of the users as well as the documentation.  Your
> arguments haven't changed my opinion.

FWIW, I completely agree with Steffen here.

> However, it doesn't look like we are finding an agreement on this
> issue. I have pinged the release team on IRC for a statement, but
> maybe this issue deserves some attention from another body of debian.
> Therefore, I suggest we write up a paragraph for the TC following
> their guidelines[0].

Since the TC seems to be the only possible solution, let's go with it.
If it's needed, I can go *again* through the sources, spotting the
copyright owners and licenses for each file Debian ships (I, in purpose,
considered only what Debian includes in its package, which is clearly
marked as $UPSTREAMVERSIONdfsg-$DEBIANVERSION).

> My proposal would be:
>
> Dear TC members
>
> Bug #449497 has reported against foo2zjs. The maintainers and the
> submitter do not seem to reach an agreement.

I would change that underlying that not only the foo2zjs maintainers,
but also other people (including a DD) agree [2].  Moreover, you can
find other DDs opinion on the thread on d-legal [3], which I looked at
quickly since, frankly speaking, things got repeated and repeated again
with no step forward.

> The problem is as follows. The submitter sees the inclusion of the
> getweb script as a violation of the DFSG. The script is provided by
> upstream to download non-free firmware from his upstream webpage.  The
> package includes documentation in README.Debian and a GUI interface
> (hannah-foo2zjs) around the getweb script for the user's
> convenience. Some printers need this non-free firmware to run, others
> don't.  More information can be found in the bugreport. Could we
> please ask you to settle this dispute?

It seems OK to me.

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=449497#125
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=yes&bug=449497#39
[3] http://lists.debian.org/debian-legal/2007/11/msg00103.html


pgpkvttQ67Dfd.pgp
Description: PGP signature

Bug#449497: foo2zjs: application depends on non-free firmware

[Luca Capello]

Hi there!

On Sun, 26 Oct 2008 08:03:46 +0100, Steffen Joeris wrote:
> On Sun, 26 Oct 2008 07:38:51 +0100. Joost Yervante Damad wrote:
>> I understand your sentiment, and it is indeed a "grey" area situation. If I
>> take policy literary, I think this package is fine in main, but it is not
>> as simple...
>>
>> In order to get this bug rolling (and lenny released ;-) ), can you all
>> live with me splitting up the package in two packages:
>>
>> 1) foo2zjs: this contains everything, and lives in mains, which Suggests:
>> 2) foo2zjs-contrib: this contains getweb

I strongly object to a single-script package.

Quickly speaking, I think the situation is similar to the kernel
firwmare issue ATM discussed on d-d (started at [1]): foo2zjs, the
software, seems to be perfectly fine for main, not only because as
Steffen already pointed out some printers can work without the non-free
firmware [2][3].  And despite upstream opinion [4], all the non-free
files have already been stripped out from the package [5].

The only problem remaining for foo2zjs in main is then the getweb
script: this can be broken because upstream changes his website layout,
but this is nothing different than any other simple bug.  If this
happened, then we'll fix it, full stop.

>> I know a package with just a script is not nice, but it is more in the
>> spirit of the debian policy indeed.
>
> I would like to hear Michael's word on it, since he was the more
> active one during the last uploads. In fact, I am happy to give up
> maintainership, as this package (and the tiresome discussion around
> it) is really no fun.
>
> Maybe Michael would like to step in and help out maintaining the
> package?

Since I needed this package and it was broken/not-updated in lenny, I
spent some time on it and already offered to take over maintenance [6],
but no one replied yet.  Again, I volunteer to become part of the Debian
maintainer team.

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://lists.debian.org/debian-devel/2008/10/msg00368.html
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=449497#10
[3] not that I checked with such printers, I'm only in touch with one
that needs a non-free firmware
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466758#15
[4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=449497#44
[5] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=449497#63
[6] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466758#27


pgprTAxoGkqpD.pgp
Description: PGP signature

Bug#482140: Reproducible and playing machine available

[Luca Capello]

Hi Daniel!

I'm sorry for being late: I was hit by two bugs during the etch
installation on QEMU [1][2] and free time is missing here.

On Tue, 07 Oct 2008 15:17:24 +0200, Daniel Leidert wrote:
> Am Dienstag, den 07.10.2008, 09:53 +0200 schrieb Luca Capello:
>> 1) IMHO this bug is Severity: important, it leaves GNOME in an not
 ^
Sorry, my fault, this should have been "critical".

>>usable state (see attached log)
>
> It breaks the upgrade, not GNOME. It needs manual intervention. IMHO
> seeverity > important is correct.

It breaks GNOME, try it: I've only create one non-root user (the one d-i
asks for) and after login I get a GNOME error and cannot continue:

  The configuration could not be loaded

  You are not allowed to access the system configuration.

This means "makes unrelated software on the system (or the whole system)
break, or causes serious data loss, or introduces a security hole on
systems where you install the package" [3].

>> I reproduced the error on three different installations: two plain etch
>> on powerpc (where "plain" means "Dekstop + Standard tasks, no more") and
>> another etch on i386 which I installed on May and then left there,
>> without never upgrading.
>
> All installations from an Etch installation media (CD/DVD)?

Netinst for i386 and powerpc, businesscard for QEMU.  All etch 4.0r4

>> One of the two powerpc installation is still in the error state,
>> i.e. `apt-get dist-upgrade` produces an error.  I can put it online and
>> accessible via SSH only if you need it, it's a playing machine (the same
>> used for bug #501367 [1]), thus you can do whatever you want.
>
> I would indeed like to take a look at it.

Since it seems that you have found a way to reproduce it [4], I don't
think you still want to take a look at my powerpc machine.  In case of,
I won't touch this machine for one week.

About [4], I would have expected to be at least cc:ed: I clearly stated
in my first mail to this bug [5] that before reporting my experience I
tried different times to reproduce the bug, which means I spent my
(already small) free time on it instead of other Debian-related stuff I
like more.  Please no insult here, just a consideration.

>> IIRC [2]
>> I still have the whole etch /etc folder, in case you want to analyze it.
>
> Not sure, if it is necessary. Maybe it will help.

As above, it'll be available for one week more.

>> I'm now installing etch on a QEMU image to check *again* if I can
>> reproduce this bug: the advantage of QEMU is that you've the -snapshot
>> option, thus you can test it whatever times you need.  I'll report back
>> as soon as the installation has finished.
>
> Thanks. Please tell, if you can reproduce it with QEMU.

Because of the bugs I found [1][2] and the fact that you can now
reproduce it, I stopped working on it.  FWIW, I still have the QEMU etch
image, which I'll discard in one week from now.

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://bugs.debian.org/501723
[2] http://bugs.debian.org/501731
[3] http://www.debian.org/Bugs/Developer#severities
[4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482140#232
[5] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482140#222


pgp3vWcaqw1Al.pgp
Description: PGP signature

Bug#482140: Reproducible and playing machine available

[Luca Capello]

Hi there!

Some notes before starting:

1) IMHO this bug is Severity: important, it leaves GNOME in an not
   usable state (see attached log)

2) I found this bug around one and a half week ago, but I performed more
   tests before replying (yes, I'm quite maniac with bugs...)

I reproduced the error on three different installations: two plain etch
on powerpc (where "plain" means "Dekstop + Standard tasks, no more") and
another etch on i386 which I installed on May and then left there,
without never upgrading.

One of the two powerpc installation is still in the error state,
i.e. `apt-get dist-upgrade` produces an error.  I can put it online and
accessible via SSH only if you need it, it's a playing machine (the same
used for bug #501367 [1]), thus you can do whatever you want.  IIRC [2]
I still have the whole etch /etc folder, in case you want to analyze it.

I'm now installing etch on a QEMU image to check *again* if I can
reproduce this bug: the advantage of QEMU is that you've the -snapshot
option, thus you can test it whatever times you need.  I'll report back
as soon as the installation has finished.

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://bugs.debian.org/501367
[2] it was last week, then I worked on other stuff



etch-i386_dist-upgrade.log.gz
Description: etch dist-upgrade: but in docbook-xml


pgplUMMOyV0GC.pgp
Description: PGP signature

Bug#494404: patch + comments on cl-geodesics

[Luca Capello]

Hi Peter!

On Tue, 26 Aug 2008 22:36:11 +0200, Peter De Wachter wrote:
> On Tue, 26 Aug 2008 01:08:53 +0200
> Luca Capello <[EMAIL PROTECTED]> wrote:
>> > - utilities.lisp doesn't have an IN-PACKAGE form, so it gets loaded
>> > in whatever random package happens to be active.
>> 
>> Since it's loaded by all the three subsystems, I'd say it's correct.
>
> Well, consider this transcript:
[...]
> Utilities.lisp clobbers variables and functions in whatever package the
> user happened to be in, that can't be right. And re-loading the
> geodesics fasls won't work if that :foo package no longer exists.

OK, now I understood what you meant, fixed [1].

>> I guess the idea was to having to load only one system instead of
>> three. It can also be possible to split geodesics.asd in three
>> different files, one for each subsystem, still providing the old
>> geodesics.asd which loads the three.
>
> But those three systems define functions with the exact same names:
>   geodesics:a
>   geodesics:da/dt
>   geodesics:adash
>   geodesics:n
>   geodesics:dn/dt
>   geodesics:ndash
> If you load GD-STATIC-UNEQUAL after GD-STATIC-EQUAL, you'll redefine
> GD-STATIC-EQUAL's functions. If you next load GD-COSMOLOGICAL, you'll
> just redefine them again. A system that loads more than one of these
> three is nonsensical.

I committed the split [2], but I kept geodesics.asd for backward
compatibility.  However, we still have only one package, GEODESICS:
should each system define their own package?

Thx, bye,
Gismo / Luca

Footnotes: 
[1] 
http://git.debian.org/?p=pkg-common-lisp/cl-geodesics.git;a=commitdiff;h=09db012a40ac704ad6b54b8b7c3047e89caa7123
[2] 
http://git.debian.org/?p=pkg-common-lisp/cl-geodesics.git;a=commitdiff;h=8915755ac6b198502312789a11c4d335e50064c1


pgpgp3hDdVG44.pgp
Description: PGP signature

Bug#497680: cmucl: FTBFS in lenny: Error in function UNIX::SIGSEGV-HANDLER: Segmentation Violation at #x10044FF0.

[Luca Capello]

unarchive 483331
forcemerge 483331 497680
severity 483331 minor
thanks

Hi Lucas!

On Wed, 03 Sep 2008 16:24:05 +0200, Lucas Nussbaum wrote:
> During a rebuild of all packages in lenny, your package failed to build on
> i386.
[...]
>> Error in function UNIX::SIGSEGV-HANDLER:  Segmentation Violation at 
>> #x10044FF0.
>> make[1]: *** [all] Error 3

This is the same as bug #483331 [1], merged.

> About the archive rebuild: The rebuild was done on about 50 AMD64 nodes
> of the Grid'5000 platform, using a clean chroot containing a sid i386
> environment.  Internet was not accessible from the build systems.

I just successfully built cmucl on a sid-i386 chroot on my ThinkPad X60
(Intel Core2 T7200 [2]): can the Grid'5000 be the problem, here?

If needed I can try a native i386 build, but I don't think we need it.

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://bugs.debian.org/483331
[2] http://luca.pca.it/projects/ibm/x60_1706-gmg/


pgpKLZy77XFw5.pgp
Description: PGP signature

Bug#495351: [Ecls-list] ECL sigill on debian armel (lenny)

[Luca Capello]

severity 495351 minor
thanks

Hi!

Please, if you deal with a Debian bug which has already been reported
(and thus has a number), don't forget to always cc: the bug as well (no
need to subscribe).  For the record, the threads on the upstream mailing
list are [1], [2] and [3].

On Sat, 30 Aug 2008 17:31:44 +0200, Martin Guy wrote:
>   This problem doesn't present itself on native debian systems:

Maybe not this specific problem, but the Debian package misses a
dependency on gcc:

=
[EMAIL PROTECTED]:~# apt-get install ecl
[...]

Selecting previously deselected package ecl.
Unpacking ecl (from .../ecl_0.9j-20080306-4_armel.deb) ...
Processing triggers for man-db ...
Setting up libgc1c2 (1:6.8-1.2) ...
Setting up cl-asdf (1.111-1) ...
Reinstalling for ecl
Recompiling Common Lisp Controller for ecl
/usr/lib/common-lisp/bin/ecl.sh loading and dumping clc.
;;; Loading "/usr/lib/ecl/install-clc.lisp"
;;; Loading #P"/usr/lib/ecl/cmp.fas"
;;; Loading #P"/usr/lib/ecl/sysfun.lsp"

Saving to new-ecl...sh: arm-linux-gnueabi-gcc: not found
=

It happens that ranma is my Openmoko FreeRunner, powered by Debian [4].
Since we (the Debian FSO Team [5]) decided to install a very minimal
Debian (cdeboostrap minimal flavour), gcc is not installed by default
(Priority: optional).

As soon as gcc is installed, ecl works like a charm (I tried the "hello
world" example in the documentation [6]).  Problem fixed [7].

FWIW, this is with Openmoko upstream 2.6.24 kernel.

> I've tried it on armv54te and armv4t boxes and ecl installs and runs
> fine, also under gdb. I can only think maybe some kernel difference -
> for example, ecl makes use of threads.

As explained by Detlef [3], this could be a kernel bug.  Thus this bug
should be reassigned to the kernel package, but since it could be
already fixed, I'd rather close it.

Detlef, what do you think?

> If it would help to have ssh access to a native Debian armel box, to
> help find the difference, you are welcome - just write me.

You can also play with qemu/qemubuilder as explained at [4]: ECL
installs and works fine with a Debian 2.6.24 kernel.

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://thread.gmane.org/gmane.lisp.ecl.general/4210
[2] http://thread.gmane.org/gmane.lisp.ecl.general/4341
[3] http://thread.gmane.org/gmane.lisp.ecl.general/4372
[4] http://wiki.debian.org/DebianOnFreeRunner
[5] http://wiki.debian.org/Teams/DebianFSO
[6] New manual: "1.6. Compiler examples"
[7] 
http://git.debian.org/?p=pkg-common-lisp/ecl.git;a=commitdiff;h=0f9b75fad97065c28242d47a77aa9cca7766ffa5


pgpNlvi0abKda.pgp
Description: PGP signature

Bug#495756: Bug#486376: Bug#495756: ecl has rpath to insecure location (/tmp/buildd/ecl-0.9j-20080306/build/)

[Luca Capello]

tags 495756 + pending
thanks

Hi Bill!

Please check the bug number you reply, I sent this back to the original
bug report ;-)

On Tue, 26 Aug 2008 14:09:12 +0200, Bill Allombert wrote:
> On Mon, Aug 25, 2008 at 11:54:26PM +0200, Luca Capello wrote:
>> I've added the ECL list to cc:.  While I can easily remove the rpath
>> as explained at [3], I'll wait for upstream's voice :-)
>
> Instead of removing it, if /usr/lib/ecl/ was the intended rpath, you
> can just replace the rpath with /usr/lib/ecl/.

According to [1], upstream stopped using rpath, so the simplest solution
is to remove the rpath with chrpath.  Committed [2] :-)

Thx, bye,
Gismo / Luca

Footnotes: 
[1] 
http://thread.gmane.org/gmane.linux.debian.devel.bugs.general/476895/focus=922
[2] 
http://git.debian.org/?p=pkg-common-lisp/ecl.git;a=commitdiff;h=161f45dfae8871ed33817daa0cdecddc62d2950e


pgpBeZGtglCLn.pgp
Description: PGP signature

Bug#494404: patch + comments on cl-geodesics

[Luca Capello]

tags 494404 + upstream
tags 494404 + fixed
thanks

Hi Peter!

Thank you for your reply and sorry for the lag.

On Tue, 12 Aug 2008 00:36:19 +0200, Peter De Wachter wrote:
> One of the problems is that the ASDF system definition has unbalanced
> parentheses. This makes it impossible to load/use this package.

Already fixed in commit 8e9239ff8ed1a874a399943c28d55aad297d6be4 [1].

> The version in sarge and etch has the same bug, so it doesn't look
> like anybody has used cl-geodesics in the past several years. It
> should probably be removed rather than fixed.

Actually, today cl-geodesics was removed from 'testing' [2].

During DebConf8 I discussed with Luk Claes (part of the Release Team)
about its inclusion in lenny or not.  This doesn't really matter, since
cl-geodesics is in 'contrib', thus it's not part of the official Debian
images.

I'd say that if it compiles, we should keep it, since at least 20 (but
not new) users have it installed [3].  So, again, thank you for the
patch!  Applied: [4] and [5]!

> OTOH, if you decide to keep it, there are a few other problems I
> noticed:
>
> - utilities.lisp doesn't have an IN-PACKAGE form, so it gets loaded in
> whatever random package happens to be active.

Since it's loaded by all the three subsystems, I'd say it's correct.

> - The GD-STATIC-EQUAL, GD-STATIC-UNEQUAL and GD-COSMOLOGICAL
> systems each define the same symbols in the GEODESICS package, so they
> can't be loaded simultaneously. But that's exactly what the GEODESICS
> system does. I think each of the GD-* systems needs to live in a
> separate package?

I guess the idea was to having to load only one system instead of three.
It can also be possible to split geodesics.asd in three different files,
one for each subsystem, still providing the old geodesics.asd which
loads the three.

I haven't uploaded the fixed package yet, I'll wait one more week for
your comments :-)

Thx, bye,
Gismo / Luca

Footnotes: 
[1] 
http://git.debian.org/?p=pkg-common-lisp/cl-geodesics.git;a=commitdiff;h=8e9239ff8ed1a874a399943c28d55aad297d6be4
[2] 
http://lists.alioth.debian.org/pipermail/pkg-common-lisp-devel/2008-August/000931.html
[3] http://qa.debian.org/popcon.php?package=cl-geodesics
[4] 
http://git.debian.org/?p=pkg-common-lisp/cl-geodesics.git;a=commitdiff;h=e085790b18da66d34dce642a86e9c3c35d78093a
[5] 
http://git.debian.org/?p=pkg-common-lisp/cl-geodesics.git;a=commitdiff;h=15f3f896ca053494898ccc6e818d998ec2aaa7f6


pgptjqkdr553d.pgp
Description: PGP signature

Bug#495756: ecl has rpath to insecure location (/tmp/buildd/ecl-0.9j-20080306/build/)

[Luca Capello]

Hi Bill!

For the ECL list: this is a 'serious' bug in the Debian BTS [1].  For
the reason why rpath is considered harmful by Debian see [2] and [3].

Please don't Cc: me, I read the list.  However, please keep the Debian
bug cc:ed (no need to subscribe), I set the M-F-T and R-T to both the
bug and the mailing list to facilitate the above :-)

On Wed, 20 Aug 2008 10:55:51 +0200, Bill Allombert wrote:
> Hello Debian Common Lisp Team,
> ecl includes a ELF file /usr/lib/ecl/asdf.fas with a rpath pointing to
> /tmp/buildd/ecl-0.9j-20080306/build/.

If I'm not wrong, this is a design decision, which seems to be
officially documented at [4].  However, it's strange that the rpath is
pointing to /tmp/... and not /usr/lib/ecl/.

> This allows an attacker with write access to that directory to
> add modified libraries which will be loaded when someone
> else run ecl.

I've added the ECL list to cc:.  While I can easily remove the rpath as
explained at [3], I'll wait for upstream's voice :-)

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://bugs.debian.org/495756
[2] http://people.debian.org/~che/personal/rpath-considered-harmful
[3] http://wiki.debian.org/RpathIssue
[4] http://thread.gmane.org/gmane.lisp.ecl.general/205/focus=215


pgpvfYgCQzRqx.pgp
Description: PGP signature

Bug#494404: cl-geodesics: geodesics.lisp:40, no dispatch function defined for #\I

[Luca Capello]

Package: cl-geodesics
Version: 20010214-7
Severity: grave
Justification: renders package unusable
Tags: upstream

Hello,

cl-geodesics doesn't compile with neither SBCL nor CLISP, tested on etch
and sid:

=
[EMAIL PROTECTED]:~$ sbcl --eval "(require 'geodesics)"

; compiling file "/usr/share/common-lisp/source/geodesics/geodesics.lisp" \
 (written 11 NOV 2002 09:11:07 AM):
[...]
; compiling (DECLAIM (DOUBLE-FLOAT K ...))compilation aborted because of \
 fatal error:
  READ failure in COMPILE-FILE:
   READER-ERROR at 1495 (line 40, column 26) on #:
no dispatch function defined for #\I
=

=
[EMAIL PROTECTED]:~$ clisp -x "(asdf:oos 'asdf:load-op 'geodesics)"
[...]

;; Compiling file /usr/share/common-lisp/source/geodesics/geodesics.lisp ...
*** - READ from #: \
  After #\# is #\i an undefined dispatch macro character
=

Thx, bye,
Gismo / Luca

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.24-etchnhalf.1-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)

Versions of packages cl-geodesics depends on:
ii  cl-infix19960628.2-3 an infix reader macro for Common L
ii  cl-integrate20021107.3-2 Common Lisp library for integratin
ii  common-lisp-controller  6.9  This is a Common Lisp source and c

cl-geodesics recommends no packages.

-- no debconf information


pgpEeWrR1zZvy.pgp
Description: PGP signature

Bug#488817: clisp - FTBFS: configure: error: C preprocessor "gcc -E" fails sanity check

[Luca Capello]

notfixed 488817 1:2.44.1-3
tags 488817 normal
thanks

Hello!

On Sun, 20 Jul 2008 17:03:02 +0200, Luca Capello wrote:
> On Tue, 08 Jul 2008 01:14:03 +0200, Luca Capello wrote:
>> I investigated a bit more and actually the problem relies on CLISP's
>> configure: upstream added the support for autoconf --build in version
>> 2.45 [1].  So the ideal fix was to backport the upstream one, not only
>> for configure but various files [2].
>>
>> However, this seems to be more pain than expected and it's IMHO an
>> upstream bug: tagged as this and forwarded at [3].
>
> Actually, I now see two bugs: the FTBFS on s390 and the needed support
> for --build in ./configure.
>
> Since we're freezing [1], let's (try to) quickly fix the former (or at
> last drop s390 support) and than deal with the latter.

Unfortunately, the quick fix I opted for [2] didn't worked:

=
./configure debian/build --prefix=/usr --fsstnd=debian --without-dynamic-ffi \
--with-module=clx/mit-clx --with-module=berkeley-db
executing /build/buildd/clisp-2.44.1/debian/build/configure \
 --srcdir=/build/buildd/clisp-2.44.1/src --prefix=/usr --without-dynamic-ffi \
--with-module=clx/mit-clx --with-module=berkeley-db --cache-file=config.cache
configure: creating cache config.cache
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
configure: ** check for host type
checking build system type... s390x-ibm-linux-gnu
checking host system type... s390x-ibm-linux-gnu
checking for style of include used by make... GNU
checking for gcc... s390-linux-gnu-gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether s390-linux-gnu-gcc accepts -g... yes
checking for s390-linux-gnu-gcc option to accept ISO C89... none needed
checking dependency style of s390-linux-gnu-gcc... gcc3
checking how to run the C preprocessor... s390-linux-gnu-gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
configure: ** checks for programs
checking for gcc... (cached) s390-linux-gnu-gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether s390-linux-gnu-gcc accepts -g... (cached) yes
checking for s390-linux-gnu-gcc option to accept ISO C89... (cached) none needed
checking dependency style of s390-linux-gnu-gcc... (cached) gcc3
checking how to run the C preprocessor... s390-linux-gnu-gcc -E
configure: error: C preprocessor "s390-linux-gnu-gcc -E" fails sanity check
See `config.log' for more details.
make: *** [configure-stamp] Error 1
=

It seems we really need to wait for --build/--host [3].  In the
meantime, I'll drop s390 support.  This is the reason I downgrade this
bug to Severity: normal, I expect s390 support to be back ASAP.

Thx, bye,
Gismo / Luca

Footnotes: 
[2] export CC=$(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)-gcc

http://git.debian.org/?p=pkg-common-lisp/clisp.git;a=commitdiff;h=1cb1cc2ec574235f09c5587b745a988faf47791e
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=491573


pgpJ32UBdoaT1.pgp
Description: PGP signature

Bug#469896: tagging 469896

[Luca Capello]

Hi Frank!

On Sun, 20 Jul 2008 18:30:32 +0200, Frank Lichtenheld wrote:
> # pending for longer than two months?
> tags 469896 - pending

I don't think that untagging it without prior discussion with the
maintainer is fair.

The fix is quite simple and has been applied, yes, more than two months
ago [1].  However, once installed, the package cannot be loaded through
ASDF [2] and this happens independently of this fix.

With my Common Lisp maintainer hat on, since cl-geodesics is not really
at the top of my priority list [3], I haven't had any time to
investigate how to solve the other bug, thus this fix is marked as
pending for more than two months.  I don't see the point in solving an
RC bug is the package isn't usable at all.

Thx, bye,
Gismo / Luca

Footnotes: 
[1] 
http://git.debian.org/?p=pkg-common-lisp/cl-geodesics.git;a=commitdiff;h=26df9a3a05276a471a774046ce865278cb91c6e8
[2] http://www.cliki.net/asdf
[3] at the time I started to work on this bug I also started the triage
for bugs in the Debian Common Lisp packages: since I'm mostly alone,
the compilers (e.g. CLISP and ECL) come before, sorry!


pgpRl33FSNJDq.pgp
Description: PGP signature

Bug#490944: [ clisp-Bugs-2018687 ] [arm] ariarm.s:1343: Error: bad instruction `replaced by...`

[Luca Capello]

Hi there!

On Thu, 17 Jul 2008 12:00:37 +0200, Luca Capello wrote:
> On Tue, 15 Jul 2008 16:15:46 +0200, SourceForge.net wrote:
>>>Comment By: Sam Steingold (sds)
>> Date: 2008-07-15 10:15
> [...]
>> this bug has been fixed in clisp 2.45

FWIW, the commit is at:

http://clisp.cvs.sourceforge.net/clisp/clisp/src/ariarm.d?r1=1.6&r2=1.7

Thx, bye,
Gismo / Luca


pgpKqv7iPB7wb.pgp
Description: PGP signature

Bug#491168: debsecan: zlib.error: Error -3 while decompressing data: incorrect header check

[Luca Capello]

Package: debsecan
Version: 0.4.10+nmu1
Severity: grave

Hello,

since yesterday I started getting errors from the debsecan daily
cronjob:

=
From: [EMAIL PROTECTED] (Cron Daemon)
Subject: Cron <[EMAIL PROTECTED]> test -x /usr/bin/debsecan && 
/usr/bin/debsecan --cron
To: [EMAIL PROTECTED]
Date: Wed, 16 Jul 2008 13:12:01 +0200 (CEST)

Traceback (most recent call last):
  File "/usr/bin/debsecan", line 1315, in 
rate_system(target, options, fetch_data(options, config), history)
  File "/usr/bin/debsecan", line 500, in fetch_data
data = StringIO(zlib.decompress(''.join(data)))
zlib.error: Error -3 while decompressing data: incorrect header check
=

Thx, bye,
Gismo / Luca

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

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

Versions of packages debsecan depends on:
ii  debconf [debconf-2.0] 1.5.22 Debian configuration management sy
ii  python2.5.2-1An interactive high-level object-o
ii  python-apt0.7.6  Python interface to libapt-pkg

Versions of packages debsecan recommends:
ii  cron  3.0pl1-104 management of regular background p
ii  postfix [mail-transport-agent 2.5.2-2High-performance mail transport ag

-- debconf information:
  debsecan/source:
  debsecan/mailto: root
  debsecan/report: true
  debsecan/suite: sid


pgp5GbehuW9Sx.pgp
Description: PGP signature

Bug#490944: [ clisp-Bugs-2018687 ] [arm] ariarm.s:1343: Error: bad instruction `replaced by...`

[Luca Capello]

tags 490944 + upstream
forwarded 490944 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=2018687&group_id=1355
tags 490944 + fixed-upstream
thanks

Hello!

On Tue, 15 Jul 2008 16:15:46 +0200, SourceForge.net wrote:
>>Comment By: Sam Steingold (sds)
> Date: 2008-07-15 10:15
[...]
> this bug has been fixed in clisp 2.45
> patch is attached
> File Added: ariarm.diff

Thx, bye,
Gismo / Luca


pgplz48kjbbjJ.pgp
Description: PGP signature

Bug#490944: clisp: FTBFS on arm: ariarm.s:1343: Error: bad instruction `replaced by multiplication of a small x=a1 and a big y=ip:*/'

[Luca Capello]

Package: clisp
Version: 1:2.44.1-3
Severity: serious

Hello!

This is a remind to track CLISP bugs, full log available at:

http://buildd.debian.org/fetch.cgi?&pkg=clisp&ver=1%3A2.44.1-2&arch=arm&stamp=1215636948&file=log

=
Automatic build of clisp_1:2.44.1-2 on cats by sbuild/arm 98
Build started at 20080709-2104
**
Checking available source versions...
Fetching source files...
Reading package lists...
Building dependency tree...
[...]
gcc  -g -O2 -Igllib -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit 
-Wreturn-type \
  -Wmissing-declarations -Wno-sign-compare -O2 -DUNICODE -I. -c built.c
gcc -E ariarm.c | grep -v '^#' > ariarm.s
gcc  -g -O2 -Igllib -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit 
-Wreturn-type \
  -Wmissing-declarations -Wno-sign-compare -O2 -DUNICODE -I. -x assembler -c 
ariarm.s
ariarm.s: Assembler messages:
ariarm.s:1: Warning: ignoring attempt to redefine built-in register 'a1'
ariarm.s:2: Warning: ignoring attempt to redefine built-in register 'a2'
ariarm.s:3: Warning: ignoring attempt to redefine built-in register 'a3'
ariarm.s:4: Warning: ignoring attempt to redefine built-in register 'a4'
ariarm.s:5: Warning: ignoring attempt to redefine built-in register 'v1'
ariarm.s:6: Warning: ignoring attempt to redefine built-in register 'v2'
ariarm.s:7: Warning: ignoring attempt to redefine built-in register 'v3'
ariarm.s:8: Warning: ignoring attempt to redefine built-in register 'v4'
ariarm.s:9: Warning: ignoring attempt to redefine built-in register 'v5'
ariarm.s:10: Warning: ignoring attempt to redefine built-in register 'v6'
ariarm.s:12: Warning: ignoring attempt to redefine built-in register 'sl'
ariarm.s:13: Warning: ignoring attempt to redefine built-in register 'fp'
ariarm.s:14: Warning: ignoring attempt to redefine built-in register 'ip'
ariarm.s:15: Warning: ignoring attempt to redefine built-in register 'sp'
ariarm.s:16: Warning: ignoring attempt to redefine built-in register 'lr'
ariarm.s:17: Warning: ignoring attempt to redefine built-in register 'pc'
ariarm.s:152: Warning: s suffix on comparison instruction is deprecated
ariarm.s:1027: Warning: s suffix on comparison instruction is deprecated
ariarm.s:1032: Warning: s suffix on comparison instruction is deprecated
ariarm.s:1343: Error: bad instruction `replaced by multiplication of a small 
x=a1 and a big y=ip:*/'
make[1]: *** [ariarm.o] Error 1
make[1]: Leaving directory `/build/buildd/clisp-2.44.1/debian/build'
make: *** [build-stamp] Error 2
dpkg-buildpackage: failure: debian/rules build gave error exit status 2
**
Build finished at 20080709-2154
=

Thx, bye,
Gismo / Luca

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

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

Versions of packages clisp depends on:
ii  common-lisp-controller6.16   Common Lisp source and compiler ma
ii  libc6 2.7-12 GNU C Library: Shared libraries
ii  libdb4.6  4.6.21-10  Berkeley v4.6 Database Libraries [
ii  libffcall11.10+2.41-3Foreign Function Call Libraries
ii  libncurses5   5.6+20080621-2 shared libraries for terminal hand
ii  libreadline5  5.2-3  GNU readline and history libraries
ii  libsigsegv0   2.5-1  Library for handling page faults i
ii  libx11-6  2:1.1.4-2  X11 client-side library
ii  libxau6   1:1.0.3-3  X11 authorisation library
ii  libxext6  2:1.0.4-1  X11 miscellaneous extension librar
ii  libxpm4   1:3.5.7-1  X11 pixmap library

clisp recommends no packages.

-- no debconf information


pgpDgnRDl7Zuz.pgp
Description: PGP signature

Bug#488817: clisp - FTBFS: configure: error: C preprocessor "gcc -E" fails sanity check

[Luca Capello]

tags 488817 + upstream
forwarded 488817 http://thread.gmane.org/gmane.lisp.clisp.devel/18516
thanks

Hi Bastian!

On Wed, 02 Jul 2008 21:39:28 +0200, Luca Capello wrote:
> On Wed, 02 Jul 2008 17:23:47 +0200, Luca Capello wrote:
>> On Wed, 02 Jul 2008 17:17:38 +0200, Bastian Blank wrote:
>>> The configure call lacks a --build=$(DEB_BUILD_GNU_TYPE) argument.
>>
>> Thank you for the hint, I'll test on raptor.d.o if this is the only
>> thing needed.
>
> This doesn't seem to work, at least on amd64 :-(
[...]
> Indeed, if I simply use "export CC=$(DEB_BUILD_GNU_TYPE)-gcc" the
> package is built and checked by debdiff shows no difference with the
> package built without the export.  However, since I'm not a GCC expert,
> I'm not sure this is the preferred way.

I investigated a bit more and actually the problem relies on CLISP's
configure: upstream added the support for autoconf --build in version
2.45 [1].  So the ideal fix was to backport the upstream one, not only
for configure but various files [2].

However, this seems to be more pain than expected and it's IMHO an
upstream bug: tagged as this and forwarded at [3].

Thx, bye,
Gismo / Luca

Footnotes: 
[1] 
http://clisp.cvs.sourceforge.net/clisp/clisp/configure?revision=1.121&view=markup
[2] other than the necessary files, I corrected the documentation, too:
=
[EMAIL PROTECTED]:~/test-clisp/clisp$ quilt push
Applying patch 01_standard-autoconf-options-build-host.patch
patching file configure
patching file unix/INSTALL
patching file clisp.spec
patching file doc/clisp.xml.in
patching file doc/_clisp.1
patching file doc/_clisp.html
patching file src/makemake.in

Now at patch 01_standard-autoconf-options-build-host.patch
[EMAIL PROTECTED]:~/test-clisp/clisp$
=
[3] http://thread.gmane.org/gmane.lisp.clisp.devel/18516


pgp7yBxP2XZ57.pgp
Description: PGP signature

Bug#488811: ecl - FTBFS: ls: cannot access /build/buildd/ecl-0.9j-20080306/debian/ecl-doc/usr/share/info/: No such file or directory

[Luca Capello]

tags 488811 + pending
thanks

Hi Bastian!

On Tue, 01 Jul 2008 14:46:05 +0200, Bastian Blank wrote:
>> Automatic build of ecl_0.9j-20080306-2 on lxdebian.bfinv.de by sbuild/s390 98
> [...]
>> dh_testdir -a
>> dh_testroot -a
>> ls -l /build/buildd/ecl-0.9j-20080306/debian/ecl-doc/usr/share/info/
>> ls: cannot access 
>> /build/buildd/ecl-0.9j-20080306/debian/ecl-doc/usr/share/info/: No such file 
>> or directory
>> make: *** [binary-arch] Error 2

I guess that the ls call was there for debug purpose on the ecl-doc
contents, so it should be in the binary-indep target, fixed [1]!

Thx, bye,
Gismo / Luca

Footnotes: 
[1] 
http://git.debian.org/?p=pkg-common-lisp/ecl.git;a=commitdiff;h=3d16062eeb14fbc3198a26723d84d9a8a862752e


pgp8LxFjkjP5i.pgp
Description: PGP signature

Bug#488817: clisp - FTBFS: configure: error: C preprocessor "gcc -E" fails sanity check

[Luca Capello]

tags 488817 + patch
thanks

Hi Bastian!

On Wed, 02 Jul 2008 17:23:47 +0200, Luca Capello wrote:
> On Wed, 02 Jul 2008 17:17:38 +0200, Bastian Blank wrote:
>> The configure call lacks a --build=$(DEB_BUILD_GNU_TYPE) argument.
>
> Thank you for the hint, I'll test on raptor.d.o if this is the only
> thing needed.

This doesn't seem to work, at least on amd64 :-(

If I add "--build=$(DEB_BUILD_GNU_TYPE)" to ./configure:
=
./configure debian/build --prefix=/usr --fsstnd=debian --with-dynamic-ffi 
--with-dynamic-modules \
--with-module=bindings/glibc --with-module=clx/new-clx
--with-module=berkeley-db --build=x86_64-linux-gnu
./configure: invalid argument --build=x86_64-linux-gnu
./configure: Try `./configure --help'
make: *** [configure-stamp] Error 1
dpkg-buildpackage: failure: debian/rules build gave error exit status 2
=

And if I add "--build $(DEB_BUILD_GNU_TYPE)" to ./configure:
=
dh_testdir
./configure debian/build --prefix=/usr --fsstnd=debian --with-dynamic-ffi 
--with-dynamic-modules \
--with-module=bindings/glibc --with-module=clx/new-clx
--with-module=berkeley-db --build x86_64-linux-gnu
[...]
configure: ** check for host type
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for style of include used by make... GNU
checking for gcc... x86_64-linux-gnu
checking for C compiler default output file name...
configure: error: C compiler cannot create executables
See `config.log' for more details.
make: *** [configure-stamp] Error 77
dpkg-buildpackage: failure: debian/rules build gave error exit status 2
=

I guess this is because:
=
sh-3.2# ./configure --help
Usage: configure [options] [dirname]
[...]
  --build   unix/INSTALL steps 3-8: configure, build, check
[...]
Specifying the C compiler:
  If you wish to specify the C compiler that will get used to build
  CLISP, set the environment variables CC, CFLAGS, LIBS.
  Put compiler flags that have to be passed to the preprocessor
  into the CC variable, not the CFLAGS variable.
  For example, if you want to use gcc in ANSI C mode,
  execute the following before calling `configure':
setenv CC "gcc -ansi" if using csh
export CC="gcc -ansi" if using bash or ksh
CC="gcc -ansi"; export CC if using sh
=

Indeed, if I simply use "export CC=$(DEB_BUILD_GNU_TYPE)-gcc" the
package is built and checked by debdiff shows no difference with the
package built without the export.  However, since I'm not a GCC expert,
I'm not sure this is the preferred way.

I'll try the patch above on raptor.d.o and commit it if ./configure will
continue.  Let's see if there are other errors then ;-)

Thx, bye,
Gismo / Luca


pgp7u5nMb6WfD.pgp
Description: PGP signature

Bug#488817: clisp - FTBFS: configure: error: C preprocessor "gcc -E" fails sanity check

[Luca Capello]

Hi Bastian!

Thank you for your fast reply :-)

On Wed, 02 Jul 2008 17:17:38 +0200, Bastian Blank wrote:
> On Wed, Jul 02, 2008 at 04:43:54PM +0200, Luca Capello wrote:
>> Is config.log available somewhere?
>
> | configure:5183: checking how to run the C preprocessor
> | configure:5299: result: gcc -E
> | configure:5328: gcc -E  conftest.c
> | In file included from /usr/include/features.h:354,
> |  from /usr/include/limits.h:27,
> |  from 
> /usr/lib/gcc/s390-linux-gnu/4.3.1/include-fixed/limits.h:122,
> |  from 
> /usr/lib/gcc/s390-linux-gnu/4.3.1/include-fixed/syslimits.h:7,
> |  from 
> /usr/lib/gcc/s390-linux-gnu/4.3.1/include-fixed/limits.h:11,
> |  from conftest.c:14:
> | /usr/include/gnu/stubs.h:9:27: error: gnu/stubs-64.h: No such file
> | or directory
[...]
> The configure call lacks a --build=$(DEB_BUILD_GNU_TYPE) argument.

Thank you for the hint, I'll test on raptor.d.o if this is the only
thing needed.

>> I'll ask for access to raptor.d.o
>> and try to investigate the failure, but I'm not a gcc expert and frankly
>> speaking I don't have a lot of time (other Common Lisp bugs come
>> before).
>
> Hmm. The Debian Lisp team don't have a DD?

Yes, more than one, /me included :-D

Thx, bye,
Gismo / Luca


pgp9zH76Ex7aL.pgp
Description: PGP signature

Bug#488817: clisp - FTBFS: configure: error: C preprocessor "gcc -E" fails sanity check

[Luca Capello]

tags 488817 + help
thanks

Hi Bastian!

On Tue, 01 Jul 2008 14:59:22 +0200, Bastian Blank wrote:
> There was an error while trying to autobuild your package:
>
>> Automatic build of clisp_1:2.44.1-1 on lxdebian.bfinv.de by sbuild/s390 98
> [...]
>> checking dependency style of gcc... (cached) gcc3
>> checking how to run the C preprocessor... gcc -E
>> configure: error: C preprocessor "gcc -E" fails sanity check

I cannot reproduce it on i386 nor on amd64, so this should be s390
specific.

>> See `config.log' for more details.

Is config.log available somewhere?  I'll ask for access to raptor.d.o
and try to investigate the failure, but I'm not a gcc expert and frankly
speaking I don't have a lot of time (other Common Lisp bugs come
before).

The last solution would be to completely drop support for s390, since
the Debian Common Lisp Team is missing manpower...

Thx, bye,
Gismo / Luca


pgpR0RXMfLsSO.pgp
Description: PGP signature

Bug#488040: cl-ppcre: Cannot include package in clisp compiler

[Luca Capello]

severity 488040 normal
thanks

Hi Riccardo!

On Wed, 25 Jun 2008 21:47:16 +0200, Riccardo Ricci wrote:
> Severity: grave
> Justification: renders package unusable

I set the severity to normal, since this bug is quite vague.

FWIW, hunchentoot [1] requires cl-ppcre and works without any problem on
sid-amd64.  Thus the bug can be at most Severity: important, but still,
we're missing the necessary information.

> When I try to compile a file .lisp that include cl-ppcre:X compile
> fails.

Can you provide more information, please?  Something like answering to
the following questions:

1) how do you compile your file?  BTW, is your file available somewhere?

2) how do you "include" cl-ppcre?  What does "cl-ppcre:X" mean?

3) how does the whole fail?  Can you provide the backtrace or, at least,
   the last 30 lines of output, please?

Please, read carefully the text at [2]: you'll find the best practice to
report a bug which will speed up the process of solving the bug, since
providing the most information you can is vital.

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://weitz.de/hunchentoot/
[2] http://www.debian.org/Bugs/Reporting


pgpQprH1QGvgj.pgp
Description: PGP signature

Bug#478000: clisp: FTBFS on sparc: ALLOCATE-METAOBJECT-INSTANCE: length 0 should be of type (INTEGER (0) (0000))

[Luca Capello]

severity 478000 normal
thanks

Hi Bernd!

On Wed, 18 Jun 2008 19:21:06 +0200, Luca Capello wrote:
> On Sat, 26 Apr 2008 10:58:07 +0200, Bernd Zeimetz wrote:
>> after lebrun.d.o timed out while building clisp I gave it a try in the
>> sid chroot of sperger, this time it failed to build, too.
>
> I don't really understand why lebrun started to build clisp:

This is still true, i.e. I still don't understand.

> Bernd, I'd downgrade the severity at least to normal or wishlist (sparc
> is not supported).

Done.

> I planned to upload version 2.44.1 this evening or tomorrow: since
> this is a bugfix upstream version for gcc-4.2/-4.3 [3], we can give it
> a try on sparc again.  What do you think?

In case you want to try it, feel free!  I don't have a lot of time since
I'm a bit busy fixing the RC bugs in the Common Lisp packages...

Thx, bye,
Gismo / Luca


pgp8HEeEUyhtX.pgp
Description: PGP signature

Bug#483331: cmucl: FTBFS: Error in function UNIX::SIGSEGV-HANDLER: Segmentation Violation at #x10044FF0.

[Luca Capello]

Hi Lucas!

On Wed, 28 May 2008 14:38:57 +0200, Lucas Nussbaum wrote:
> Package: cmucl
> Version: 19d-20061116-4.1
[...]
> During a rebuild of all packages in sid, your package failed to build
> on i386.
>
> Relevant part:
[...]
>> Error in batch processing:
>> 
>> Error in function UNIX::SIGSEGV-HANDLER:  Segmentation Violation at 
>> #x10044FF0.
>> make[1]: *** [all] Error 3

I tried to reproduce this error on three different chroots (two from
i386, one through cowbuilder and the other "normal", and one from amd64,
"normal"), but without success, i.e. the package was always built fine.

> If you determine that this failure is caused by gcc 4.3, feel free to
> downgrade this bug to 'important' if your package is only built on i386,
> and this bug is specific to gcc 4.3 (i.e the package builds fine with
> gcc 4.2).

I'd say that if there was an error, it was fixed in gcc, since nothing
changed for cmucl.  Moreover, the main binary package is build only on
i386.

Lucas, how should I proceed?  Should I tag the bug unreproducible and
close it?  Or just downgrage to important?  IMO it's clearly not RC.

Thx, bye,
Gismo / Luca


pgpnPRQRlGD6Q.pgp
Description: PGP signature

Bug#478000: clisp: FTBFS on sparc: ALLOCATE-METAOBJECT-INSTANCE: length 0 should be of type (INTEGER (0) (0000))

[Luca Capello]

Hi Bernd!

On Sat, 26 Apr 2008 10:58:07 +0200, Bernd Zeimetz wrote:
> after lebrun.d.o timed out while building clisp I gave it a try in the
> sid chroot of sperger, this time it failed to build, too.

I don't really understand why lebrun started to build clisp: while the
debian/rules file contains some checks for sparc, debian/control
explicitly avoid sparc [1]:

  Package: clisp
  Architecture: alpha amd64 arm hppa i386 ia64 mips mipsel powerpc
s390 kfreebsd-i386 m68k hurd-i386

FWIW, sparc support was present in sarge, but not in etch.

> ;; Loading file /home/bzed/clisp-2.44/src/clos-class2.lisp ...
> ;; Loaded file /home/bzed/clisp-2.44/src/clos-class2.lisp
> ;; Loading file /home/bzed/clisp-2.44/src/clos-class3.lisp ...
> *** - ALLOCATE-METAOBJECT-INSTANCE: length 0 should be of type (INTEGER
> (0) ())
> Bye.

This is exactly the same error that cause sparc removal from the
supported architecture, see bug #386075 [2].

Bernd, I'd downgrade the severity at least to normal or wishlist (sparc
is not supported).  I planned to upload version 2.44.1 this evening or
tomorrow: since this is a bugfix upstream version for gcc-4.2/-4.3 [3],
we can give it a try on sparc again.  What do you think?

Thx, bye,
Gismo / Luca

Footnotes: 
[1] 
http://git.debian.org/?p=pkg-common-lisp/clisp.git;a=blob;f=debian/control;h=1163e658a01d4307ce6945c2536c8d7e1b839f16;hb=HEAD
[2] http://bugs.debian.org/386075
[3] 
http://git.debian.org/?p=pkg-common-lisp/clisp.git;a=commitdiff;h=309d00d9cb2c4f17a6e9151e3863638e1c06a082


pgpsmQ60w496z.pgp
Description: PGP signature

Bug#474810: clisp: FTBFS: floatparam.h:18:2: error: #error "Unknown rounding mode for type double!"

[Luca Capello]

tags 474810 + pending
thanks

Hi Sebastian!

On Thu, 08 May 2008 19:25:46 +0200, Sebastian Bober wrote:
> On Thu, May 08, 2008 at 07:01:19PM +0200, Luca Capello wrote:
>> 
>> I'm reluctant to apply your patch because I could go and package the new
>> upstream version instead.  What do you think?
>
> That's reasonable as the diff between the currently packaged and the new
> upstream version is very small. I just wanted to supply a minimal fix
> for this RC bug for potential NMUers.

Thank you again!

> So, I'd say, go forward with the new upstream version.

Done [1].

I preferred to not go with the latest 2.45 because the changes that it
introduces [2] are quite big and we want to freeze...

Thx, bye,
Gismo / Luca

Footnotes: 
[1] 
http://git.debian.org/?p=pkg-common-lisp/clisp.git;a=commit;h=309d00d9cb2c4f17a6e9151e3863638e1c06a082
[2] http://clisp.cvs.sourceforge.net/*checkout*/clisp/clisp/src/NEWS


pgpybNpRQckuo.pgp
Description: PGP signature

Bug#471223: ecl - FTBFS: dpkg-genchanges: failure: cannot read files list file: No such file or directory

[Luca Capello]

tags 471223 + pending
thanks

Hi Sebastian!

On Mon, 28 Apr 2008 21:55:04 +0200, Sebastian Bober wrote:
> I have changed debian/rules in a way that the "Architecture: any"
> package "ecl" is created in "binary-arch" and the "Architecture: all"
> package "ecl-doc" in "binary-indep".

Thank you for the patch, I applied it:

http://git.debian.org/?p=pkg-common-lisp/ecl.git;a=commitdiff;h=ea533d37e8d7e26413811b09f3caf89fb61c1710

Thx, bye,
Gismo / Luca


pgph6iNXrb4iD.pgp
Description: PGP signature

Bug#470381: cl-asdf: installation fails

[Luca Capello]

Hi Lucas!

On Mon, 10 Mar 2008 22:18:59 +0100, Lucas Nussbaum wrote:
> In a clean unstable i386 chroot:
>
> Setting up cl-asdf (1.111-1) ...
> Reinstalling for sbcl
> Recompiling Common Lisp Controller for sbcl
> /usr/lib/common-lisp/bin/sbcl.sh loading and dumping clc.
[...]
> ; loading system definition from /usr/lib/sbcl/sb-grovel/sb-grovel.asd
> into
> ; #
> ; registering # as SB-GROVEL
> fatal error encountered in SBCL pid 4197(tid 3085297328):
> GC invariant lost, file "gencgc.c", line 4641
>
> Welcome to LDB, a low-level debugger for the Lisp runtime environment.
> ldb> 

I cannot reproduce it on two clean unstable i386 chroots, both generated
by cowbuilder, the first on my sid amd64 and the second on an etch i386.

FWIW, I also tried SBCL_1:1.0.14.0-1, which should be the SBCL version
present in sid on March 10th, so when the bug occurred: again, the bug
is not reproducible.

Lucas, since you're the only one who experienced this bug, it's OK for
you if I set 'Severity: important' (IMHO this isn't RC) and 'Tags:
unreproducible'?

Thx, bye,
Gismo / Luca


pgp0rGMQKFksY.pgp
Description: PGP signature

Bug#472776: ASDF system definition missing

[Luca Capello]

Hi Sebastian!

I'm sorry to come to you so late, real work and life took precedence...

On Mon, 28 Apr 2008 01:02:06 +0200, Sebastian Bober wrote:
> the bug is caused by the specifications in debian/cl-usocket.install
> that overwrites the original usocket.asd with a symlink from the
> "test" directory.

It seems the problem is deeper than that.  In fact, after having
corrected the usocket.asd bug you get another error:

=
[EMAIL PROTECTED]:~$ sbcl
* (require 'usocket)
[...]

; compiling file "/usr/share/common-lisp/source/cl-usocket/package.lisp" 
(written 19 DEC 2007 07:13:00 AM):
; compiling (IN-PACKAGE :CL-USER)
; compiling (DEFPACKAGE :USOCKET-TEST ...)
debugger invoked on a SB-KERNEL:SIMPLE-PACKAGE-ERROR in thread #:
  The name "REGRESSION-TEST" does not designate any package.
=

This error is caused by...

> In the attached patch the .install file is cut down to the necessary
> files. The test suite itself is not that interesting and including it
> causes file name overlaps ("package.lisp" is in usocket and
> usocket-test).

...the installed "package.lisp" coming from usocket/test/ instead of
usocket/, but correcting also this causes:

=
[EMAIL PROTECTED]:~$ sbcl
* (require 'usocket)
[...]

; /var/cache/common-lisp-controller/1000/sbcl/cl-usocket/usocket.fasl written
; compilation finished in 0:00:00

debugger invoked on a SB-INT:SIMPLE-FILE-ERROR in thread #:
  failed to find the TRUENAME of 
/usr/share/common-lisp/source/cl-usocket/condition.lisp:
No such file or directory
=

So there are more bugs than the single ASDF system definition missing.

The first problem relies in debian/cl-usocket.install: since we want to
install the whole folders, we should omit the '*'.  This solves the
usocket.asd and package.lisp problems, not the missing condition.lisp
one, because this is not listed in debian/cl-usocket.install.

The following git commit completely fixes this bug:

http://git.debian.org/?p=pkg-common-lisp/cl-usocket.git;a=commit;h=d4f1ee5ea09a550774df7ca218d48d4541b289ce

> Another way would be to have usocket-test its own directory under
> /usr/share/common-lisp/source, but I really don't think thats
> necessary.

I'm always in favor of providing a test suite, if available, and
especially if it's minimal (in this case usocket/test/ is only 44K).
This is why I didn't remove it :-)

Thx, bye,
Gismo / Luca


pgpC2U3kgljLe.pgp
Description: PGP signature

Bug#480242: Bug#440007: cl-irc: unsatisfied dependency on cl-trivial-sockets

[Luca Capello]

Hi Ben!

I'm not sure you're still interested in this bug, in case you don't
please excuse me for the spam :-)

The Debian git repository it at

  http://git.debian.org/?p=pkg-common-lisp/cl-irc.git;a=summary

On Fri, 09 May 2008 03:28:34 +0200, Luca Capello wrote:
> I'd say that the best thing to do now would be to integrate the darcs
> missing versions (20070106-dfsg-1, 20070315-dfsg-1, 20070430-dfsg-1 and
> 20070905-dfsg-1) into the changelog for version 1:0.8.1-dfsg-1 and to
> remove the already present 20070504-dfsg-1.

Done (commit "debian/changelog: reflect uploaded versions",
a6857587300f164a5bb089bf3554643296417eb2).

> If we really want to be (quite) perfect, we can remove the unnecessary
> bits (Vcs-Bzr and usocket) from the 1:0.8.1-dfsg-1 changelog entry.

Not done: I was reluctant since the git repository contains a reference
at the old bzr repository (commit "Corrected Vcs-Git control field",
96f6ded900b6d329dba9167c7c65f8f37702).

Thx, bye,
Gismo / Luca


pgpXrMRGIX7BP.pgp
Description: PGP signature

Bug#440007: cl-irc: unsatisfied dependency on cl-trivial-sockets

[Luca Capello]

clone 440007 -1
retitle -1 cl-irc: Debian changelog doesn't reflect uploaded versions
notfound -1 20060514-dfsg-1
notfixed -1 20070905-dfsg-1
found -1 1:0.8.1-dfsg-1
thanks

Hi Ben!

I cloned this bug since the Debian changelog mess has nothing to do with
the original bug.  Please check the new bug number before replying.

On Wed, 16 Apr 2008 03:59:32 +0200, Ben Hutchings wrote:
> Bug #440007 isn't known to be fixed in 1:0.8.1-dfsg-1 because it was
> originally fixed in version 20070905-dfsg-1 and the current version is
> not based on that.

Version 20070905-dfsg-1 clearly enters unstable [1], but it seems that
during the migration of the Debian VCS from darcs to git Peter forgot it
was using darcs and instead imported the old bzr repository [2].  This
led to your problem.

Actually, the Debian changelog for version 20070905-dfsg-1 records to
not-uploaded versions (20070315-dfsg-1 and 20070430-dfsg-1), since
there's no mention of those into the Debain PTS or snapshot.d.n [3] and
being version 20070106-dfsg-1 the previous one (but uploaded to
experimental because of the etch freeze [4]).  However, these two
"stealth" versions are clearly present in the old darcs repository [5].

However, the Debian changelog for version 1:0.8.1-dfsg-1 completely
misses the above four records and contains, instead, an unrelated
version 20070504-dfsg-1, never uploaded.  I guess this last version is
present in the old bzr repository [6], but since I'm a bzr agnostic...

I'd say that the best thing to do now would be to integrate the darcs
missing versions (20070106-dfsg-1, 20070315-dfsg-1, 20070430-dfsg-1 and
20070905-dfsg-1) into the changelog for version 1:0.8.1-dfsg-1 and to
remove the already present 20070504-dfsg-1.  If we really want to be
(quite) perfect, we can remove the unnecessary bits (Vcs-Bzr and
usocket) from the 1:0.8.1-dfsg-1 changelog entry.

Comments?

I'll go with the solution above if no one replies in one week from now.

> Has it been fixed?

Yes, this for sure, even two times: 20070905-dfsg-1 and 1:0.8.1-dfsg-1!

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://packages.qa.debian.org/c/cl-irc/news/20070917T190207Z.html
[2] 
http://git.debian.org/?p=pkg-common-lisp/cl-irc.git;a=commitdiff;h=3ccbfb9a2fc4d4de54f68d3aa7de4a3d58a52b7f#patch8
[3] http://snapshot.debian.net/package/cl-irc
[4] http://packages.qa.debian.org/c/cl-irc/news/20070206T133207Z.html
[5] http://cl-debian.alioth.debian.org/repository/pvaneynd/cl-irc/
[6] http://cl-debian.alioth.debian.org/repository/pvaneynd/bzr-moved/cl-irc/


pgpeM3UA5d84l.pgp
Description: PGP signature

Bug#474810: clisp: FTBFS: floatparam.h:18:2: error: #error "Unknown rounding mode for type double!"

[Luca Capello]

Hi Sebastian!

On Mon, 28 Apr 2008 01:52:10 +0200, Sebastian Bober wrote:
> this bug is fixed in a new upstream version 2.44.1 of clisp. I have
> extracted a minimal fix for this build failure.

I'm reluctant to apply your patch because I could go and package the new
upstream version instead.  What do you think?

Thx, bye,
Gismo / Luca


pgpwxCTJ4Ys3e.pgp
Description: PGP signature

Bug#471213: cl-rsm-random - FTBFS: dpkg-genchanges: failure: cannot read files list file: No such file or directory

[Luca Capello]

tags 471213 + pending
thanks

Hi Sebastian!

On Sun, 27 Apr 2008 22:52:46 +0200, Sebastian Bober wrote:
> the latest upload of this package swapped the rules for binary-arch and
> binary-indep. This resulted in this FTBFS bug. The attached patch
> reverses the change and binary-arch only builds should be possible
> again.

Applied, thank you!

Thx, bye,
Gismo / Luca


pgph4R168QBka.pgp
Description: PGP signature

Bug#469896: cl-geodesics - FTBFS: dpkg-genchanges: failure: cannot read files

[Luca Capello]

tags 469896 + pending
thanks

Hi Sebastian!

On Sun, 27 Apr 2008 22:28:39 +0200, Sebastian Bober wrote:
> in my view the correct way to fix this bug is to make the package
> "Architecture: all" as no architecture specific content is generated. An
> according patch is attached.

Agreed and patch applied, thank you!

Thx, bye,
Gismo / Luca


pgp2aGCPDJ9mf.pgp
Description: PGP signature

Bug#471219: cl-gd - FTBFS: dpkg-genchanges: failure: cannot read files list file: No such file or directory

[Luca Capello]

tags 471219 + pending
thanks

Hi Sebastian!

On Sun, 27 Apr 2008 20:15:29 +0200, Sebastian Bober wrote:
> as this package is "Architecture: any" the "binary-arch" target in
> debian/rules is called for generating the .deb. The attached patch swaps
> the binary-* targets in debian/rules.

I applied your patch, which was the same as `git revert $COMMIT`, but
since I wanted to record the fix into debian/changelog as well, I
preferred a new "manual" commit.  Maybe I'm still a bit too "gitbie"...

> Peter, what was the reason for deliberately swapping these build targets
> in the latest upload?

I cannot speak for Peter, but I guess it was a pure mistake.

Thx, bye,
Gismo / Luca


pgpQTyqwreojj.pgp
Description: PGP signature