Bug#1024998: g810-led: Security risk: Leaves /dev/input/event* with read and write permissions for all users

[Xavi Drudis Ferran]

Package: g810-led
Version: 0.4.2-2.1
Severity: critical
Tags: patch upstream security
Justification: root security hole
X-Debbugs-Cc: xdru...@tinet.cat, Debian Security Team 

Dear Maintainer,

I hesitate to file as critical, but I came across a bug report in
upstream that looked serious enough since it would allow all local
processes to eavesdrop on keyboard input, including passwords, etc. I
haven't tried an exploit, but it seemed better to just restrict
/dev/input/event* permissions to those of other event dev files.

Without this patch, I can read /dev/input/event2 and /dev/input/event3 as a
normal user. I see bytes in /dev/input/event2 when typing as a normal
user and also typing in another terminal (Konsole) typing as
root. event3 only shows the characters typed by the normal user.

With the patch I can't read /dev/input/event* as a normal user.

And the bug is publically reported upstream (some 10 days ago).

   * What led up to the situation?

Reviewing upstream bugs, found https://github.com/MatMoul/g810-led/issues/293

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Nothing really. I wrote the patch, rebuilt, and observed the
permissions were fixed. My keyboard seems to work both with and
without the patch (needs a kernel with CONFIG_HIDRAW), when calling
g810-led as root. As normal user it doesn't work (both with or without
patch), due to no permission for /dev/hidraw2.

It should really be fixed upstream, but maybe it's worth fixing meanwhile
or removing the package temporarily ?

-- System Information:
Debian Release: 11.5
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.19.4-gnu-eowyn21so-gc9d5f2140717-dirty (SMP w/6 CPU threads; 
PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages g810-led depends on:
ii  libc6 2.31-13+deb11u4
ii  libg810-led0  0.4.2-2.1
ii  libgcc-s1 10.2.1-6
ii  libstdc++610.2.1-6

g810-led recommends no packages.

g810-led suggests no packages.

-- Configuration Files:
/etc/g810-led/profile changed [not included]

-- no debconf information

*** 
/home/xdrudis/g810-led/debian/patches/correct_permissions_in_event_device_files.patch
--- a/udev/g810-led.rules
+++ b/udev/g810-led.rules
@@ -1,25 +1,25 @@
-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", 
ATTRS{idProduct}=="c336", MODE="666" RUN+="/usr/bin/g213-led -p 
/etc/g810-led/profile"
-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", 
ATTRS{idProduct}=="c330", MODE="666" RUN+="/usr/bin/g410-led -p 
/etc/g810-led/profile"
-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", 
ATTRS{idProduct}=="c33a", MODE="666" RUN+="/usr/bin/g413-led -p 
/etc/g810-led/profile"
-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", 
ATTRS{idProduct}=="c342", MODE="666" RUN+="/usr/bin/g512-led -p 
/etc/g810-led/profile"
-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", 
ATTRS{idProduct}=="c33c", MODE="666" RUN+="/usr/bin/g513-led -p 
/etc/g810-led/profile"
-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", 
ATTRS{idProduct}=="c333", MODE="666" RUN+="/usr/bin/g610-led -p 
/etc/g810-led/profile"
-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", 
ATTRS{idProduct}=="c338", MODE="666" RUN+="/usr/bin/g610-led -p 
/etc/g810-led/profile"
-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", 
ATTRS{idProduct}=="c331", MODE="666" RUN+="/usr/bin/g810-led -p 
/etc/g810-led/profile"
-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", 
ATTRS{idProduct}=="c337", MODE="666" RUN+="/usr/bin/g810-led -p 
/etc/g810-led/profile"
-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", 
ATTRS{idProduct}=="c33f", MODE="666" RUN+="/usr/bin/g815-led -p 
/etc/g810-led/profile"
-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", 
ATTRS{idProduct}=="c32b", MODE="666" RUN+="/usr/bin/g910-led -p 
/etc/g810-led/profile"
-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", 
ATTRS{idProduct}=="c335", MODE="666" RUN+="/usr/bin/g910-led -p 
/etc/g810-led/profile"
-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", 
ATTRS{idProduct}=="c339", MODE="666" RUN+="/usr/bin/gpro-led -p 
/etc/g810-led/profile"
-ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="046d", 
ATTRS{idProduct}=="c336", MODE="666" RUN+="/usr/bin/g213-led -p 
/etc/g810-led/profile"
-ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="046d", 
ATTRS{idProduct}=="c330", MODE="666" RUN+="/usr/bin/g410-led -p 
/etc/g810-led/profile"
-ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="046d", 
ATTRS{idProduct}=="c33a", MODE="666" RUN+="/usr/bin/g413-led -p 
/etc/g810-led/profile"
-ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="046d", 
ATTRS{idProduct}=="c342", MODE="666" RUN+="/usr/bin/g512-led -p 

Bug#866472: Playing with a different approach for the color profiles

[Xavi Drudis Ferran]

El Mon, Jul 29, 2019 at 02:46:14PM +0200, Agustin Martin deia:
> I am attaching a couple of files with current state of my experiments. I am
> also not fluent with python (that is why I did not adopt or sponsored this
> or any other python package), so my changes would definitely need review, if
> considered.
>

I've tried your packaging and it works in my very limited use case. 
But it still seems to install the files

dpkg -L python-uniconvertor
/usr/lib/python2.7/dist-packages/uniconvertor-2.0rc4/uc2/cms/cmyk_profile_rc.py
/usr/lib/python2.7/dist-packages/uniconvertor-2.0rc4/uc2/cms/display_profile_rc.py
/usr/lib/python2.7/dist-packages/uniconvertor-2.0rc4/uc2/cms/gray_profile_rc.py
/usr/lib/python2.7/dist-packages/uniconvertor-2.0rc4/uc2/cms/lab_profile_rc.py
/usr/lib/python2.7/dist-packages/uniconvertor-2.0rc4/uc2/cms/srgb_profile_rc.py

 
> A DEP5 copyright with file exclusion line is included, which should make
> easier to create a DFSG free tarball.
>

But I think
Files-Excluded: */src/uc2/cms/*_profile.py
should be 
Files-Excluded: */src/uc2/cms/*_profile_rc.py

With that it no longer installs the dubious files.

Neither your debian/watch nor mine worked for me this time for some
reason (the version 2.0~rc4 instead of 2.0rc4 maybe among others), I
ended up with

version=4
opts=compression=gz,repack,uversionmangle=s/rc/~rc/,filenamemangle=s/^.*uniconvertor-(\d.*)\.(tgz|tbz2|tar\.(?:gz|bz2|xz)).*$/python-uniconvertor-$1.$2/
 
https://sk1project.net/modules.php?name=Products=uniconvertor=download
 .*=uniconvertor-(\d.*)\.(?:tgz|tbz2|tar\.(?:gz|bz2|xz))

(compression=gz is not really necessary, I guess) 

now uscan is happier (it detected the upstream as always newer before)
and deletes the excluded files from the orig.tar.gz archive. 
I hope it stays so the next time I try it, must have tested it wrong before. 

Another nitpick, in debian/copyright  the text 

On Debian systems, the complete text of the GNU General
 Public License version 3 can be found in
 "/usr/share/common-licenses/GPL-2".

should list the correct path for GPLv3:

On Debian systems, the complete text of the GNU General
 Public License version 3 can be found in
 "/usr/share/common-licenses/GPL-3".

Thank you very much for your work. Let's hope it's useful for whoever
ends up being maintainer and they can return python-uniconvertor to
debian.

Bug#866472: Playing with a different approach for the color profiles

[Xavi Drudis Ferran]

El Mon, Jul 29, 2019 at 02:46:14PM +0200, Agustin Martin deia:
> I am attaching a couple of files with current state of my experiments. I am
> also not fluent with python (that is why I did not adopt or sponsored this
> or any other python package), so my changes would definitely need review, if
> considered.
>

It looks fine to me. I'll try it when I can, but I'll only test a very specific 
use case, 
i'm not sure how to test uniconvertor in general. 

Thanks a lot. 

Bug#866472: copyright extract script

[Xavi Drudis Ferran]

El Thu, Jul 11, 2019 at 05:28:30PM +0200, Agustin Martin deia:
> On Thu, Jul 11, 2019 at 04:17:30PM +0200, Agustin Martin wrote:
> > On Thu, Jul 11, 2019 at 04:02:13PM +0200, Xavi Drudis Ferran wrote:
> > > 
> > > I attach the script. It prints some (c) info on the *_rc.py files. 
> > > You might need to change the uniconvertor directory in the script. 
> > > And you may not really find it too enlightening...
> > 
> > Thanks a lot,
> > 
> > I was already looking at the files generated under
> > ~/.config/uc2/profiles/ where those strings can also be guessed. I will look
> > more carefully, but at least one of the color profiles seems non free (the
> > HP one).
> 
> Hi again, Xavi
> 
> I was looking at the color profiles. Here goes a summary of what I found:
>

that was the intention of this code in my debian/rules (probably misplaced) 

python src/uc2/utils/rcc2py/rcc2py.py 
/usr/share/color/icc/ghostscript/default_cmyk.icc src/uc2/cms/cmyk_profile_rc.py
python src/uc2/utils/rcc2py/rcc2py.py /usr/share/color/icc/Gray.icc 
src/uc2/cms/gray_profile_rc.py
python src/uc2/utils/rcc2py/rcc2py.py /usr/share/color/icc/sRGB.icc 
src/uc2/cms/srgb_profile_rc.py
#   python src/uc2/utils/rcc2py/rcc2py.py ? 
src/uc2/cms/display_profile_rc.py
python src/uc2/utils/rcc2py/rcc2py.py 
/usr/share/color/icc/ghostscript/lab.icc src/uc2/cms/lab_profile_rc.py
 
>   * cmyk_profile_rc.py -> built-in_CMYK.icm
> 
> (Fogra27L.icc) Fogra27L CMYK Coated Press
> (C) Richard Hughes 
> Public Domain
>

I replaced it from /usr/share/color/icc/ghostscript/default_cmyk.icc

But I think I found it had a different checksum to the original. 

The problem is despite beliving the attribution and license of the
original, can I be saying to distribute the source code if I only have
src/uc2/cms/cmyk_profile_rc.py ?  or should I add the file that file
was generated from, which I'm not sure which was?  So to avoid the
doubt, I just removed it, and regenerated from _another_ icc profile,
that I hope is good enough but I can't tell.

Maybe it would be enough to just ship the py or the rcc2py and the
.icc binary decoded from the *_rc.py so people can regenerate the
*_rc.py (but this seems backwards? is it really the binary obtained
from *_rc.py a source for *_rc.py?)
 
To know what counts as source, I should know what is the prefered
format for people modifying icc profiles ?  .icc ? *_rc.py ? something
else ? I've never used an .icc file (conciously).

>   * display_profile_rc.py -> built-in_Display.icm
> 
> Contains this string:
> No copyright. Created with dispcalGUI 1.1.2.9 and Argyll CMS 1.4.0 -M 
> P244W -A Acer Technologies
> 
> Could get no more info about this profile
> 

Yes, I'm in the dark too. 

>   * gray_profile_rc.py -> built-in_Grayscale.icm
> 
> This is the same as /usr/share/color/icc/Gray.icc, shipped in
> icc-profiles-free package
>  
> Copyright (C) 2005-2008 Kai-Uwe Behrmann 
> License: zlib/libpng License
> 

Yes, but I seem to recall the checksum did not match the base64
decoded file from the _rc.py .  I don't remember well, I should
recheck, maybe some of the files matched, my impression was that most
or all didn't.

Like the first case, I generated it from a debian file
/usr/share/color/icc/Gray.icc
and I don't know if this is a good enough substitute. 

>   * lab_profile_rc.py -> built-in_LAB.icm
> 
> Seems similar (but not exact) to /usr/share/color/icc/LCMSXYZI.ICM,
> shipped in icc-profiles-free package
> 
> Copyright (C) Marti Maria Saguer 1999
> License: zlib/libpng License
>

 Could be, I tried 
/usr/share/color/icc/ghostscript/lab.icc

>   * srgb_profile_rc.py -> built-in_RGB.icm
> 
> Copyright (c) 1998 Hewlett-Packard Company
> 
> $ md5sum built-in_RGB.icm 
> 1d3fda2edb4a89ab60a23c5f7c7d81dd  built-in_RGB.icm
>
> If you look at https://bugs.debian.org/699301 this is exactly the same
> file that was reported as non-free. It is shipped as 
> /usr/share/color/icc/sRGB.icm in non-free icc-profiles package.
>

I tried /usr/share/color/icc/sRGB.icc hoping it is free. But is it a
good enough substitute ?  I mean does it work like the original ? How
do I know ?
 
> Some Debian packages are currently shipping free color profiles, at least
> 
> icc-profiles-free
> colord-data
> libgs9-common
> 

I added to build-depends : 
 libgs9-common,
 icc-profiles-free
But I didn't use colord-data

> I wonder if some profile in those packages could help. I have no idea about
> color profiles and such.
> 

Yes. What does one do here ? Ask the maintainers from libgs9-common,
icc-profiles-free for any ideas on source ? the legal team ? ask
nobody until one has something tested that looks useful ?

Bug#866472: copyright extract script

[Xavi Drudis Ferran]

I attach the script. It prints some (c) info on the *_rc.py files. 
You might need to change the uniconvertor directory in the script. 
And you may not really find it too enlightening...
# -*- coding: utf-8 -*-
#
#  Copyright (C) 2011-2018 by Igor E. Novikov
#
#  This program is free software: you can redistribute it and/or modify
#  it under the terms of the GNU General Public License as published by
#  the Free Software Foundation, either version 3 of the License, or
#  (at your option) any later version.
#
#  This program is distributed in the hope that it will be useful,
#  but WITHOUT ANY WARRANTY; without even the implied warranty of
#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#  GNU General Public License for more details.
#
#  You should have received a copy of the GNU General Public License
#  along with this program.  If not, see .

import os
import sys

sys.path.insert(1, '/usr/lib/uniconvertor-2.0rc4')

from uc2 import cms

man = cms.ColorManager()
for k in man.handles:
print k, '(c)', cms.libcms.cms_get_profile_copyright(man.handles[k]), ' name: ', cms.libcms.cms_get_profile_name(man.handles[k]), ' info: ', cms.libcms.cms_get_profile_info(man.handles[k])
profile = cms.libcms.cms_create_display_profile();
print 'display', '(c)', cms.libcms.cms_get_profile_copyright(profile), ' name: ', cms.libcms.cms_get_profile_name(profile), ' info: ', cms.libcms.cms_get_profile_info(profile)

Bug#866472: Uniconvertor 2.0 upstream depends on python-pil and has some .debs

[Xavi Drudis Ferran]

El Thu, Jul 11, 2019 at 03:38:03PM +0200, Agustin Martin deia:
> On Fri, Jul 05, 2019 at 10:50:08PM +0200, Xavi Drudis Ferran wrote:
> > Well, for what is worth here're the files for a package that builds
> > and install on buster for uniconvertor-2.0rc4. But I haven't
> > tested. Only did a sg to pdf conversion once. I may have done
> > lots of things wrong, of course.
> > 
> > So far it does no seem to require sk1libs. 
> 
> Hi, Xavi,
> 
> Thanks for your work.
> 
> I was doing some work in parallel about how to build uniconvertor 2.0rc4
> and learn something about packaging python stuff. I am attaching the
> current status of what I did. Note that I changed upstream version to
> 2.0~rc4 to keep proper version sorting in Debian.
> 
> I only needed to use your reportlab patch.
> 
> I am trying to guess if there is some license info about the color profiles.
> Will let you know.
> 
> Regards,
>

Thanks, i'll have a look at your work.

There's some copyright info inside the .icc file itself (optional, not
in all) The original icc is embedded in Base64 inside the *_rc.py
file, and I wrote some script to print it. I'll see if I still have it
and attach it, but I think t wasn't definitive enough for me. Possibly
because I don't have the DFSG criteria clear enough. Hold on.

Bug#866472: Uniconvertor 2.0 upstream depends on python-pil and has some .debs

[Xavi Drudis Ferran]

Well, for what is worth here're the files for a package that builds
and install on buster for uniconvertor-2.0rc4. But I haven't
tested. Only did a sg to pdf conversion once. I may have done
lots of things wrong, of course.

So far it does no seem to require sk1libs. 



python-uniconvertor_2.0rc4-1.dfsg.1.debian.tar.xz
Description: application/xz
Format: 3.0 (quilt)
Source: python-uniconvertor
Binary: python-uniconvertor, python-uniconvertor-dbg
Architecture: any
Version: 2.0rc4-1.dfsg.1
Maintainer: Debian QA Group 
Homepage: https://sk1project.net/modules.php?name=Products=uniconvertor
Standards-Version: 4.0
Build-Depends: debhelper (>= 9), dh-python, perl, python-all-dbg (>= 2.4), 
python-all-dev (>= 2.4), libcairo2-dev, liblcms2-dev, libmagickwand-dev, 
libpango1.0-dev, python-cairo-dev, libgs9-common, icc-profiles-free
Package-List:
 python-uniconvertor deb python optional arch=any
 python-uniconvertor-dbg deb debug extra arch=any
Checksums-Sha1:
 cf75fe706b9d144603f15b0ee8bd0674122453b0 801880 
python-uniconvertor_2.0rc4.orig.tar.xz
 aae32f0c76337d2baa516a5c46a557cb12506301 12540 
python-uniconvertor_2.0rc4-1.dfsg.1.debian.tar.xz
Checksums-Sha256:
 a0a658a140fcadd1090b2ce91ceecf9b840ee8521ee3fc3d8ea2713f19ce1d15 801880 
python-uniconvertor_2.0rc4.orig.tar.xz
 c114a218964c37c83954206c29b6bfc2d9819d690215dc59d785710032d1a942 12540 
python-uniconvertor_2.0rc4-1.dfsg.1.debian.tar.xz
Files:
 a58ca4de9c8db19bc092330f3b2f660e 801880 python-uniconvertor_2.0rc4.orig.tar.xz
 42146410bdf17a1e5fc9a734d9a56a90 12540 
python-uniconvertor_2.0rc4-1.dfsg.1.debian.tar.xz

Bug#866472: Uniconvertor 2.0 upstream depends on python-pil and has some .debs

[Xavi Drudis Ferran]

El Thu, Jun 27, 2019 at 04:07:53PM +0200, Agustin Martin deia:
> On Fri, Jun 21, 2019 at 07:24:15AM +0200, Xavi Drudis Ferran wrote:
> > 
> > Hello. Maybe you know already (because the problem seems to be lack of 
> > maintainer). But there is a python-uniconvertor 2.0 that no longer depends 
> > on python-imaging but on python-pil (python2, I believe)
> > 
> > https://sk1project.net/modules.php?name=Products=uniconvertor=download
> 
> Hi,
> 
> Even if that dependency is declared, python-uniconvertor in Debian does
> not really depend on python-imaging, but on a copy of it embedded as
> sk1libs.imaging in sk1libs, which is not in Debian.
> 
> The biggest problem is the lack of sk1libs, because there are some other
> functions that are required by uniconvertor as soon as you try to go
> beyond the usage message (See https://bugs.debian.org/820748).
> 
> I am not a python expert, but for the imaging part I would expect something
> similar to attached patch to work. It changes dependency to python-pil and
> tries to change calls to sk1libs.imaging stuff to the equivalent PIL calls.
> 
> Regards,
>

Thank you.

I'm looking into 2.0rc4. 

It seems to use PIL already, but it uses a previous version of
reportlab (should work in stretch but not buster, I think it needed
python-reportlab < 3.4.2 IIRC). I only tried generating an pdf from an
svg and failed. So I suspect 1.1.5 would not work with buster
python-reportlab either. 

In 2.0rc4 there are also generated files in src/uc2/cms/*_rc.py that I
don't know how DFSG compatible are. I found the script that generates
them from icc files, and some carry public domain or other licenses,
but I don't know what are the original icc profile files used to
generate the _rc.py files. Meybe one could use icc files from
icc-profiles-free or other packages. But how do I know if I'm breaking
something with the change?

I mean I could maybe with some effort put up some version of 2.0 that
works for me (or not, it's not really my stuff tbh) but I would not
know how to test it all.

upstream offers 2.0rc4 debs for 2 architectures, but for debian 9, not 10. 
That would confirm my dependence issue. 

But I'll keep your patch in mind. Maybe it's easier to port 1.1.5 to
buster (or sid).

Or maybe we should just ask upstream for their plans.

Bug#866472: Uniconvertor 2.0 upstream depends on python-pil and has some .debs

[Xavi Drudis Ferran]

Hello. Maybe you know already (because the problem seems to be lack of 
maintainer). But there is a python-uniconvertor 2.0 that no longer depends on 
python-imaging but on python-pil (python2, I believe)

https://sk1project.net/modules.php?name=Products=uniconvertor=download

They offer source and some .debs for a couple architechtures and Debian 9, but 
I haven't tried them or audited the licenses or anything. 

I suppose it would still require packaging. Unfortunately I don't know
enough about debian policies or about python. I might try to learn, but 
I think Debian is frozen now ? 

Bug#909498: Fixed with firefox-esr from jessie

[Xavi Drudis Ferran]

Hello. 

I hope I'm not adding only noise. 

I found the same error on my Wandboard Quad when I updated my stretch 
from aptitude, and jumper from firefox-esr 58 (I think) to 60.3 .

I tried to install the version from sid, but dependencies didn't allow. 

But it started working when I dpkg -i firefox-esr_60.3.0esr-1~deb8u1_armhf.deb 
(the version from jessie, downloaded from 
http://security.debian.org/debian-security/pool/updates/main/f/firefox-esr/firefox-esr_60.3.0esr-1~deb8u1_armhf.deb
and checked against checksums at 
https://packages.debian.org/jessie/armhf/firefox-esr/download
) .

I don't know why. I have a custom kernel, an old system upgraded
from years ago, and some other custom or eclectic package might 
be around here too. So my example might not really be significative, 
but if other people can reproduce it then maybe there might be some
dependency info to improve somehow ?

I just notice 

stretch firefox depends on libcairo-gobject2 >= 1.10.0 and jessie firefox 
doesn't, 

stretch firefox depends on  libdbus-1-3 (>= 1.9.14) and jessie firefox on (>= 
1.0.2)

stretch firefox depends on  libgcc1 (>= 1:4.3) and jessie firefox on (>= 
1:4.4.0)

stretch firefox depends on  libjsoncpp1 (>= 1.7.4) and jessie firefox doesn't

stretch firefox depends on  libstdc++6 (>= 6) and jessie firefox on  libstdc++6 
(>= 4.9) 

stretch firefox depends on  libvpx4 (>= 1.6.0)  and jessie firefox doesn't

The rest of deps seem the same for jessie and stretch firefoxes.

I have installed: 

libcairo-gobject2 1.14.8-1
libdbus-1-3   1.10.26-0+deb9u1
libgcc1   1:6.3.0-18+deb9u1
libjsoncpp1   1.7.4-3
libstdc++66.3.0-18+deb9u1
libvpx4   1.6.1-3+deb9u1

I'm not sure this info is any useful, but just in case someone happens
to find the bug and wants to try the jessie package and tell the
result...

Bug#733058: eyed3: Option to use patterns for the tag values

[Xavi Drudis Ferran]

Package: eyed3
Version: 0.6.18-1
Severity: wishlist
Tags: upstream patch

Dear Maintainer,

I added an option to have the value written into the tag
come from the substitution of other tag values and/or the filename
according to a pattern. 

Just as you can use a pattern for the filename to rename to, you 
can use a pattern for the tag value. 

I had downloaded some files with DownThemAll asking to name 
the files from the link text. The filename was more accurate as
a tittle than the title tag, so I wanted to replace the tittle 
with the filename and the old title.

Maybe I should have changed the tag class and introduce the old filename 
as a variable for renaming the file too.

I'm not sure how lively this package is, so I'm just sending a patch
that worked for me in case anyon emight find it useful. 

I'm sending this to debian because I'm not finding upstream, the url 
http://www.travisshirk.net/eyeD3/releases/ gives 404 Not Found


-- System Information:
Debian Release: 7.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: i386 (i686)
Foreign Architectures: armhf

Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages eyed3 depends on:
ii  python2.7.3-4+deb7u1
ii  python-eyed3  0.6.18-1

eyed3 recommends no packages.

eyed3 suggests no packages.

-- no debconf information
--- eyeD3.orig	2013-12-24 20:28:09.013765827 +0100
+++ eyeD3	2013-12-24 20:37:14.569426681 +0100
@@ -259,6 +259,11 @@
grp1.add_option(--remove-all, action=store_true,
 dest=remove_all, default=0,
 help=Remove both ID3 v1.x and v2.x tags.);
+   grp1.add_option(--pattern, action=store_true,
+dest=pattern, default=0,
+help=Treat the tag value given as a pattern using \
+ substitution variables as with --rename, plus \
+ %f for the filename (without directory or extension).);
optParser.add_option_group(grp1);
 
# Misc. options.
@@ -543,7 +548,7 @@
 
  # Handle frame edits.
  try:
- tagModified = self.handleEdits(self.tag) or self.opts.force_update;
+ tagModified = self.handleEdits(self.tag,f) or self.opts.force_update;
  except CommandException, ex:
  printError(ex);
  return self.R_HALT;
@@ -610,7 +615,7 @@
 
   return status;
 
-   def handleEdits(self, tag):
+   def handleEdits(self, tag,f):
   retval = 0;
 
   # First set new version if requested
@@ -629,19 +634,19 @@
   artist = self.opts.artist;
   if artist != None:
  printWarning(Setting artist: %s % artist);
- tag.setArtist(artist);
+ tag.setArtist(self.fill(f,tag,artist));
  retval |= 1;
 
   album = self.opts.album;
   if album != None:
  printWarning(Setting album: %s % album);
- tag.setAlbum(album);
+ tag.setAlbum(self.fill(f,tag,album));
  retval |= 1;
 
   title = self.opts.title;
   if title != None:
  printWarning(Setting title: %s % title);
- tag.setTitle(title);
+ tag.setTitle(self.fill(f,tag,title));
  retval |= 1;
 
   discNum = self.opts.disc
@@ -679,13 +684,13 @@
   genre = self.opts.genre;
   if genre != None:
  printWarning(Setting track genre: %s % genre);
- tag.setGenre(genre);
+ tag.setGenre(self.fill(f,tag,genre));
  retval |= 1;
 
   year = self.opts.year;
   if year != None:
  printWarning(Setting year: %s % year);
- tag.setDate(year);
+ tag.setDate(self.fill(f,tag,year));
  retval |= 1;
 
   play_count = self.opts.play_count;
@@ -728,7 +733,7 @@
   pub = self.opts.publisher;
   if pub != None:
   printWarning(Setting publisher: %s % (pub));
-  tag.setPublisher(pub);
+  tag.setPublisher(self.fill(f,tag,pub));
   retval |= 1;
 
   comments = self.opts.comments;
@@ -746,7 +751,7 @@
printWarning(Removing comment: %s % (desc));
else:
printWarning(Setting comment: [%s]: %s % (desc, comm));
-   tag.addComment(comm, desc, lang);
+   tag.addComment(comm, self.fill(f,tag,desc), lang);
retval |= 1;
 except ValueError:
printError(Invalid Comment; see --help: %s % c);
@@ -929,6 +934,16 @@
 
   return retval;
 
+   def fill(self,f,tag,pattern):
+ 
+   if (self.opts.pattern):
+  result = tag.tagToString(pattern);
+  result = tag._subst(result,%f,unicode(os.path.splitext(os.path.basename(f))[0],
+   self.opts.fs_encoding,'replace'));
+   else:
+  result = pattern;
+   return result;  
+
def 

Bug#690548: iptables: invalid size 40 (kernel) != (user) 48 on yeelong because kernel is 64 bits, iptables 32 bits

[Xavi Drudis Ferran]

Package: iptables
Version: 1.4.14-3
Severity: important
Tags: patch

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

* What led up to the situation?

I changed the hard disk of my Lemote Yeeloong laptop, and tried reinstalling
debian wheezy on it.

I followed http://wiki.debian.org/DebianYeeloong/HowTo/Install with 2012-10-11 
installer
(loongson-2f netboot).

It installed ok at least to console, I still have to try X.

I then installed arno-iptables-firewall and it complained that
iptables was failing, telling me to look at dmesg.

dmesg said :

[ 0.068000] TCP: Hash tables configured (established 65536 bind 65536)
[ 23.22] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 23.256000] ip6_tables: (C) 2000-2006 Netfilter Core Team
[ 25.896000] x_tables: ip_tables: limit.0 match: invalid size 40 (kernel) != 
(user) 48
[ 25.928000] x_tables: ip_tables: limit.0 match: invalid size 40 (kernel) != 
(user) 48
[ 25.96] x_tables: ip_tables: limit.0 match: invalid size 40 (kernel) != 
(user) 48
[ 25.988000] x_tables: ip_tables: limit.0 match: invalid size 40 (kernel) != 
(user) 48
[ 26.016000] x_tables: ip_tables: limit.0 match: invalid size 40 (kernel) != 
(user) 48
[ 26.068000] x_tables: ip_tables: limit.0 match: invalid size 40 (kernel) != 
(user) 48
[ 26.096000] x_tables: ip_tables: limit.0 match: invalid size 40 (kernel) != 
(user) 48

It was the same that happened to me last year around june.

So after 3 or 4 tries I remembered the solution, but I don't remember that I 
reported
it then and so I'll do it now. I may be reporting on the wrong package or it 
may need
2 reports, I don't know

The problem seems to be that the linux kernel is 64 bits (it could be 32 bits, 
and iptables
would work as packaged, but then the kernel does only see 256 MB of RAM and I 
have 1 GB).

Iptables as packaged is a 32 bits mipsel executable, and seems to have some 
data structures
that include 32 bits pointers or something that don't work when shared with the 
64 bit
kernel. Or something like that.

* What exactly did you do (or not do) that was effective (or
ineffective)?

The following procedure fixed it for me but I'm not sure what would be best for 
debian
as a whole. Maybe there could be 2 iptables and libnfnetlink packages for 
mipsel, one 32
bits and one 64 bits, and dependencies could be arranged somehow to have the 
right one
installed when the kernel is 64 bits ? Or maybe iptables code can be changed to 
cater
for the kernel data structures size being different of their own?

I don't know how usable is this fix but at least should explain the problem and 
help
someone find a better fix.

Here are my steps with missteps removed:

# cat -  /etc/dpkg/buildflags.conf
APPEND CFLAGS -march=loongson2f -Wa,--trap -mabi=64 -Wa,-mfix-loongson2f-nop 
-mno-branch-likely -L/usr/lib/gcc/mipsel-linux-gnu/4.6/64/
APPEND LDFLAGS -mabi=64 -Wl,-melf64ltsmip -Wl,-EL 
-Wl,-L/usr/lib/gcc/mipsel-linux-gnu/4.4.5/64/

(I just realised the second line -L argument is wrong, was right last year but 
I should have upgraded it for gcc 4.6
I'm using now, but the fact is that this is how I've done it, I guess it should 
work without -L)

# aptitude build-depends iptables
# aptitude install debian-keyring build-essential
$ apt-get source iptables
$ apt-get source libnfnetlink
$ cd libnfnetlink-1.0.0
(i tried dpkg-buildpackage but later discovered it was ignoring 
/etc/dpkg/buildflags.conf, and building a
32 bits library, until I saw I had to change debian/rules last year to make it 
use buildflags.conf, not
sure if that is the correct thing to do for the general debian case, I edited 
debian rules, haven't really
tried next command, but if it fails it's adding 5 lines there)
$ patch -p 1
--- libnfnetlink-1.0.0/debian/rules2012-10-13 22:11:25.0 +0200
+++ libnfnetlink-1.0.0/debian/rules2011-06-02 21:01:21.191999657 +0200
@@ -8,6 +8,11 @@
DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)

CFLAGS = -Wall -g
+success:=$(shell dpkg-buildflags --export=make build.flags  echo y)
+ifneq ($(success),y)
+$(error dpkg-buildflags failed)
+endif
+include build.flags

ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
CFLAGS += -O0
$ dpkg-buildpackage

# dpkg -i libnfnetlink-dev_1.0.0-1_mipsel.deb libnfnetlink0_1.0.0-1_mipsel.deb

$ cd ../iptables-1.4.14
$ dpkg-buildpackage

# dpkg -i iptables_1.4.14-3_mipsel.deb

# /etc/init.d/arno-iptables-firewall start

* What was the outcome of this action?

no errors about iptables reported by arno-iptables-firewall and none in dmesg.
Firewall seems to work fine

* What outcome did you expect instead?

I'd like that the next time I install on a yeeloong iptables works out of the 
box,
or that I can keep upgrading iptables and libnfnetlink from the debian archive
without need to rebuild them each time.

Not sure what's the proper fix that makes it just work for yeeloong and doesn't
break or make things difficult for others...

Hope it helps me next time, 

Bug#570913: guessnet: uninstallable on sid i386 for lack of libiw29. Should it be libiw30 ?

[Xavi Drudis Ferran]

Package: guessnet
Severity: grave
Justification: renders package unusable


Hello. 

I've been unable to install guessnet on i386 for a couple of weeks now. 
Available version in sid is 0.51-1 . 

It depends on libiw29 (=28+29pre7) 
but there is no such package available. 
I think it depends on libiw30 on other architecture(s).
For sid i386 libiw30 is available. 

May there be some mistake in the package dependencies ? 

Thanks a lot. Guessnet has been very useful for me. 

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

Kernel: Linux 2.6.32psmouse (PREEMPT)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



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

Bug#567747: patches that helped me with this or a similar problem

[Xavi Drudis Ferran]

Hello.

Sorry if I send this to the wrong place, but I started commenting on
another bug (#534422), now I no longer think it is appropiate there and I
don't know if it belongs here, but it's late, I'm half asleep and yesterday
I already felt asleep before finding the right place to post.

2.6.26 from a clean lenny install worked, and the I just upgraded to
sid, with some misunderstnading on my part about udev and the kernel,
that I finally sorted out.

I've also being unable to boot with KMS on my laptop, with
linux-image-2.6.32-trunk-686 2.6.32-5 . The laptop is some model of
the brand Ahtec, forgot which, but it is a clone of an AOpen 1551 and
a label at the bottom says so.  I can dig up old papers if you need
more info. It has a 1.5 GHz pentium M and intel 855 GME graphics. The
panel native resolution is 1280x800, and I set it in Grub-pc after
using its 915resolution module.

It showed the console on an external monitor but it would not display on
the laptop panel. If I booted in text mode then it showed text, but X
would not start, and the Xorg log said LVDS1 was disconnected. It could
be fixed by closing and opening the laptop lid twice before re/starting X.
But then Ctrl-Alt-F1 did not work. It just removed the cursor from screen
until I pressed Ctrl-Alt-F7.
So it apparently was something about guessing wrong the initial lid state
in inteldrmfb (i915 kernel module).
In the kernel source I found some quirk provision for an Aspire One which
apparently had the same problem, and I just copypasted it for my laptop.
This is patch i915-aopen1551.diff
It works for me (it no longer requires me to open and close the laptop
before X) but I don't know if the match with DMI info is the best one.
It might be too specific or too general (is BOARD_SERIAL supposed to
be unique for each board manufactured, like a CPU UUID, or just identifies
the board model?). I'll attach the output of dmidecode, but it does not
look very explicit to me.

Then I did another patch (forcelvds.diff) to simply accept a kernel
boot parameter to tell it it should consider the LVDS1 connected at
boot regardless of the lid state it thinks it's in just in case the
previous quirk does not match all cases. With this patch I can pass
i915.forcelvds=1 in the kernel command line and it also works for me
like with the i915_aopen1551.diff. Its the same with either patch or both.

But with either of those I have to boot in text mode (i.e. without
video=i915 in the kernel command line).

If I put video=i915 then i get blank screen and the console or X only
in the external monitor. I also get /dev/fb0 and
/dev/fb1 and the messages below in syslog .
This happens both with and without those
patches, i.e. with the debian kernel too. It's the same also with this
patch http://lists.freedesktop.org/archives/intel-gfx/2009-December/004979.html
(I tried it because i2cdetect output looked strange).

# grep fb /var/log/syslog
Feb  9 23:21:54 ideafix kernel: [0.513612] efifb: probing for efifb
Feb  9 23:21:54 ideafix kernel: [0.513708] efifb: framebuffer at 
0xe800, mapped to 0xdff0, using 4000k, total 4000k
Feb  9 23:21:54 ideafix kernel: [0.513712] efifb: mode is 1280x800x32, 
linelength=5120, pages=1
Feb  9 23:21:54 ideafix kernel: [0.513714] efifb: scrolling: redraw
Feb  9 23:21:54 ideafix kernel: [0.513719] efifb: Truecolor: size=8:8:8:8, 
shift=24:16:8:0
Feb  9 23:21:54 ideafix kernel: [0.618139] fb0: EFI VGA frame buffer device
Feb  9 23:21:54 ideafix kernel: [2.183638] fb: conflicting fb hw usage 
inteldrmfb vs EFI VGA - removing generic driver
Feb  9 23:21:54 ideafix kernel: [2.183836] fb1: inteldrmfb frame buffer 
device

So it looks that efifb is finding the laptop panel already configured by
grub, and the efifb gets hold of it, and it won't let go when i915 (inteldrmfb)
tries to open it, so i915 uses the external monitor for an output (and I think
it hangs if it is not connected).

If I compile a kernel with either or both patches, without vesafb or
efifb and with i915, intel_agpgart, drm etc. linked in (y), not as
modules (not m) , and without initrd (I don't think initrd matters, but
I never use it in custom kernels) then inteldrmfb gets the laptop
panel, I can see the console in it, X works fine and all is well.

Is there away to tell the kernel to never activate efifb or vesafb
and load i915 form initrd instead ? Or is there a way to unbind it
from all outputs before loading inteldrmfb ? I'd prefer to use debian kernels
than rebuild them at each upgrade. And I guess that compiling
in all framebuffers in a distribution kernel is a little contrary to the
idea of initrd, keeping the kernel small and all that.

It should be obvious by now, but I have no clue about kernel programming,
so don't trust the patches too much (at least until someone knowledgeable
looks at them). It's more a way to describe a problem
by something that fixes it than a good fix. They might be incorrect or
undesirable or redundant or ...

Bug#534422: More tests

[Xavi Drudis Ferran]

Well, I'm not sure I'm sending this to the right bug any longer.

My problem was the blank screen more that segfaults.

I've now compiled three more kernels, and it doesn't seem much related to  
efifb.
It may be inteldrmfb not understanding that I have a lvds .

If I compile a kernel like linux-image-2.6.32-686 but without the vesafb and 
efifb
I can boot in text mode but not start X.

If I compile a custom kernel for my laptop, without initrd and so on it's the 
same.

If I compile that configuring drm, agpart, etc. and i915 as y, not m and 
pass it video=i915
the lvds is blank, but I get the console on external monitor. Without external 
monitor
it seems to hang.

In any case I can see X in the lvds if I open and close the lid twice before 
starting X
(or after starting X if I press  ctrl-alt-backspace to restart gdm).

So it just seems that my hardware is not reporting properly the fact that the 
lvds is
connected (or the lid open). I'm trying to add an exception like the one that's 
there
in intel_lvds.c for my laptop and see if it helps.

So, sorry if this wasn't the right bug to comment on.




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

Bug#562515: lives: Please package marcos-encoders for multi_encode

[Xavi Drudis Ferran]

Package: lives
Version: 1.1.6-1
Severity: wishlist


Hello, and thanks for packaging lives. 

I've tried to encode to theora but didn't find the way. 
One of the encoder plugins, multi_encode dpeends on several 
python programs that don't seem packaged. I wonder whether 
there is any legal problem or other reason. But I could find 
no hint on why these encoders are missing. 

Everything worked once I downloaded them from 
http://lives.svn.sourceforge.net/viewvc/lives/branches/1.0.0/lives-plugins/marcos-encoders/
and copied them to /usr/local/bin

according to packages.debian.org they don't seem to be in any debian package. 

I think it would be good to include them in the packages or 
if this can't be done then document briefly why. 

Thanks. 

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

Kernel: Linux 2.6.30badram (PREEMPT)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages lives depends on:
ii  frei0r-plugins 1.1.22git20090409-2   minimalistic plugin API for video 
ii  imagemagick7:6.5.8.3-1   image manipulation programs
ii  libasound2 1.0.21a-1 shared library for ALSA applicatio
ii  libatk1.0-01.28.0-1  The ATK accessibility toolkit
ii  libavc1394-0   0.5.3-1+b2control IEEE 1394 audio/video devi
ii  libc6  2.10.2-2  GNU C Library: Shared libraries
ii  libcairo2  1.8.8-2   The Cairo 2D vector graphics libra
ii  libdv4 1.0.0-2   software library for DV format dig
ii  libfontconfig1 2.6.0-4.2 generic font configuration library
ii  libfreetype6   2.3.11-1  FreeType 2 font engine, shared lib
ii  libglib2.0-0   2.22.3-1  The GLib library of C routines
ii  libgtk2.0-02.18.5-1  The GTK+ graphical user interface 
ii  libjack0   0.118+svn3796-1   JACK Audio Connection Kit (librari
ii  libogg01.1.4~dfsg-2  Ogg bitstream library
ii  liboil0.3  0.3.16-1  Library of Optimized Inner Loops
ii  libpango1.0-0  1.26.2-1  Layout and rendering of internatio
ii  libpulse0  0.9.21-1  PulseAudio client libraries
ii  libraw1394-11  2.0.4-1   library for direct access to IEEE 
ii  libsdl1.2debian1.2.13-5  Simple DirectMedia Layer
ii  libtheora0 1.1.1+dfsg.1-3The Theora Video Compression Codec
ii  libweed0   1.1.6-1   Runtime library for inclusion of p
ii  libx11-6   2:1.3.2-1 X11 client-side library
ii  lives-data 1.1.6-1   Data files for LiVES
ii  mplayer1.0~rc3+svn20090405-1 movie player for Unix-like systems
ii  ogmtools   1:1.5-3+b1Tools for manipulating Ogg multime
ii  perl   5.10.1-8  Larry Wall's Practical Extraction 
ii  python 2.5.4-4   An interactive high-level object-o
ii  sox14.3.0-1.1Swiss army knife of sound processi

Versions of packages lives recommends:
ii  cdda2wav9:1.1.10-1   Dummy transition package for iceda
ii  dvgrab  3.5-1grab digital video data via IEEE13
ii  mkvtoolnix  2.7.0-0.2+b1 Set of command-line tools to work 
ii  pulseaudio  0.9.21-1 PulseAudio sound server
ii  x11-utils   7.5+1X11 utilities

Versions of packages lives suggests:
ii  libdv-bin 1.0.0-2software library for DV format dig
ii  libtheora-bin 1.1.1+dfsg.1-3 The Theora Video Compression Codec

-- no debconf information



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

Bug#530417: totem-mozilla: video/ogg no longer played in browser (Streaming)

[Xavi Drudis Ferran]

Package: totem-mozilla
Version: 2.26.2-1
Severity: normal


In this computer iceweasel will offr to download files such as
http://www.archive.org/download/CollserolaDesDeLEcologia/Collserola_des_de_l_ecologia.ogv

You can either save to disk or open in totem or vlc, but that's after 
downloading them full, you can't watch them as they download.

In another computer with a less up-to-date sid (totem-mozilla is 2.24 )
totem plays the file inside the browser, starting right away (streaming,
not after download).

It looks like the totem-mozilla plugin (as well as mplayer, kaffeine,
and vlx browser plugins) don't associate themselves with .ogv files
or video/ogg streams.

I tired to download and install totem-mozilla from testing in this computer,
but it didn't work either.

But at least totem used to do it in the past.

Thank you very much for your work.
-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.28usb (PREEMPT)
Locale: LANG=ca_ES, LC_CTYPE=ca_ES (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages totem-mozilla depends on:
ii  dbus-x11  1.2.14-2   simple interprocess messaging syst
ii  totem-gstreamer   2.26.2-1   A simple media player for the GNOM
ii  totem-xine2.26.2-1   A simple media player for the GNOM

Versions of packages totem-mozilla recommends:
ii  epiphany-browser   2.26.1-1  Intuitive web browser - dummy pack
ii  epiphany-gecko [www-br 2.26.1-1  Intuitive GNOME web browser - Geck
ii  iceape-browser [www-br 1.1.14-1  Iceape Navigator (Internet browser
ii  iceweasel [www-browser 3.0.9-1   lightweight web browser based on M
ii  konqueror [www-browser 4:3.5.10.dfsg.1-2 KDE's advanced file manager, web b
ii  lynx-cur [www-browser] 2.8.7pre2-1   Text-mode WWW Browser with NLS sup
ii  w3m [www-browser]  0.5.2-2+b1WWW browsable pager with excellent

totem-mozilla suggests no packages.

-- no debconf information





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

Bug#518816: Font suport may be incomplete but not completely undocumented.

[Xavi Drudis Ferran]

I can't help much, but I've sent what I discovered to the other bug
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504223

Later today I'll try to send some patch to work around font problemes with
path-based svgs, but it won't help for files with (non-empty) text.

From my tests yesterday, the directory for fonts is currently
~/.unicode, no ~/.unicode/font.
There should be .sfd, .afm and pfa or pfb files there, not only
sfd. But I'm not sure it works even so.

I found some info on sfd at the skencil pakage manual
/usr/share/doc/skencil or so. I thik it's the same as this
http://www.skencil.org/Doc/usersguide-4.html

The mkfontdb.py program is in the /usr/share/doc/skencil
dir or thereabouts (see my message to the other bug).







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

Bug#504223: patch suggestion

[Xavi Drudis Ferran]

Ok, I don't speak python and I'd like someone more fluent 
to take the idea and program it more properly.
but after all this is only a workaround to avoid the situation 
where there is no fallback font and the program won't work 
even with path based svg files that happen to mention font info. 
 
It works for me (with hola-path.svg and hola+empty.svg from my previous post).

This is an alternative to making a ~/.uniconvertor directory and
building a std.sfd file. 

It implies changes to only one file in python-uniconvertor, and
does not require tools or font files from other packages. 
The function could be called more than once without any bad effects.

But it is onlt a workaround, I still don't know why it doesn't 
seem to load the fonts with read_font_dirs()



-- 
xdru...@tinet.cat
Signa per fer Collserola parc natural com cal
http://www.collserola.org/salvemelparcnatural/--- /usr/lib/python2.5/site-packages/uniconvertor/app/Graphics/font.py.orig	2009-05-05 22:37:15.0 +0200
+++ /usr/lib/python2.5/site-packages/uniconvertor/app/Graphics/font.py	2009-05-05 22:15:25.0 +0200
@@ -433,4 +433,38 @@
 #	Initialisation on import
 #
 
+## workaround for a bug that stops uniconvertor from working with svg
+## files winth font properties in style attributes, even if they apply
+## to no text because all text is empty or transformed to paths
+## see http://svn.berlios.de/viewcvs/bulmages/branches/docsMonolitic/bulmages/installbulmages/openreports/ca/
+
+class FakeFont(Font):
+def __init__(self, name):
+self.name = name
+self.family = name
+self.font_attrs = 'Regular Italic'
+self.xlfd_start = '-adobe-Nimbus Roman No9 L-regular-i-normal'
+self.encoding_name = 'iso8859-1'
+self.outlines = None
+self.ref_count = 0
+font_cache[self.name] = self
+
+def ensure_there_is_at_least_a_fake_fallback_font():
+   fallback = 'Slim';
+   if (not (config is  None)) and (hasattr(config,'preferences'))  and (hasattr(config.preferences,'fallback_font')):
+   fallback = config.preferences.fallback_font
+   if not font_cache.has_key(fallback):
+  return FakeFont(fallback)
+   return font_cache[fallback]
+
+
+fallbackFont = ensure_there_is_at_least_a_fake_fallback_font()
+
+## end of font workaround
+
+
 Subscribe(const.INITIALIZE, read_font_dirs)
+
+
+
+

Bug#518816: correction

[Xavi Drudis Ferran]

 From my tests yesterday, the directory for fonts is currently
 ~/.unicode, no ~/.unicode/font.

I meant 

~/uniconvertor, no ~/.uniconvertor/fonts


-- 
xdru...@tinet.cat
Signa per fer Collserola parc natural com cal
http://www.collserola.org/salvemelparcnatural/



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

Bug#504223: can the debian package include some workaround to #504223 (fonts unsupported) until it's fixed upstream ?

[Xavi Drudis Ferran]

Hello. Here's a recent use case I've found myself with, 
and I think the user experience could be improved. 
The names and files have been changed to protect the 
guilty (and to simplify, to familiarize, to entertain...).  


Alice installs a Debian sid system, because when real girls 
want to go to Wonderland they know how to use a mirror
(to download from, not to go through, what was Lewis Carroll thinking?).

Alice is quite unexperienced with graphics, and worse with svg, 
but she's got this hola.svg file she would like to convert to pdf. 

In aptitude, the roadmap to Wonderland, she finds python-uniconvertor.

So she installs it and simply runs:
   
   al...@wonderland:~$ uniconvertor hola.svg hola.pdf
   I can't find font Bitstream Vera Sans. I'll use Slim instead
   I can't find font Slim. I'll use Slim instead
   Fontsystem not yet implemented in UniConvertor. See 
/usr/share/doc/python-uniconvertor/README.Debian for more info
   
She's directed to README.Debian, and she reads: 

   --- Font support ---
   UniConvertor doesn't have font support yet and should be used against 
path-based files only.
   
   See: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504223
   
   SVG (and possibly other files as well) can be converted to path-based files 
in inkscape.
   
Ok, ideally she would just draw a patch from a hat to implement ttf
in python-uniconvertor, but she doesn't have a hat and the White Rabbit
is in a hurry and can't lend her his hat. So she opens inkscape instead,
loads hola.svg, and starts looking for a way to convert text to
path-based files. She finds a menu called camí (path) and an option
called Objecte a camí (object to path). Looks like it could be
it. She clicks on the arrow tool, she uses select All in all layers
from the Edit menu, and then she uses this object to path option. 
Finally she saves, as hola-path.svg (for good measure she chooses simple SVG
as format).

When she looks at the files, hola.svg has a text element and 
hola-path.svg has a path element instead. Good. :) 

So she now runs 

   al...@wonderland:~$ uniconvertor hola-path.svg hola-path.pdf

And she gets exactly the same error refering her to docs 
that keep telling her to do what she thought she had already done. :(
She's starting to feel some empathy for the Queen of Hearts,
but she regains her temper and decides to ask for help.
So Alice in Wonderland sends a message to Bob in Workaroundland
(encrypted, of course, but that's irrelevant) asking him to 
come over here.

When Bob meets Alice, looking closer, they see that the path 
element in hola-path.svg has a style attribute that defines 
a font-family property.
Namely:
  
style=font-size:12px;font-style:normal;font-weight:normal;fill:#00;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoi
n:miter;stroke-opacity:1;font-family:Bitstream Vera Sans 

The Mad Hatter says that's beacuse inkScape knows the font-family
attribute won't be used for rendering but it may come handy in case
anyone was to add other text or whatever, at least the information is
not lost, but the March Hare thinks it's just that there was no need
 to change the style attribute value, since other properties in it 
may be relevant. Alice and Bob don't care.

Alice asks: 
Is there a better way to use inkScape to change text based svg files 
to path based svg files ? If so, could it please be explained clearer
in README.Debian ? Thanks. 

But Bob isn't satisfied, so he goes:
b...@workaround~: mkdir ~/.uniconvertor
b...@workaround~: cd ~/.uniconvertor/
b...@workaround~: ln -s /usr/share/fonts/type1/gsfonts/n021023l.afm .
b...@workaround~: ln -s /usr/share/fonts/type1/gsfonts/n021023l.pfm .
b...@workaround~: ln -s /usr/share/fonts/type1/gsfonts/n021023l.pfb .
b...@workaround~: python /usr/share/doc/skencil/tools/mkfontdb.py -sxg .
b...@workaround~: perl -pi -e 's/^[^,]+,[^,]+,/Slim,Slim,/' std.sfd 
b...@workaround~: cd 
b...@workaround~: uniconvertor hola-path.svg hola-path.pdf

And it still fails the same as before

Alice: So what ?. At least I didn't waste my time on my console...

Bob: No, wait, the problem is uniconvertor can't load its fonts, 
in particular the fallback font (Slim). If it could, we wouldn't
have to remove font-family styles from svgs...  it would only 
fail when actually rendering fonts whch wouldn't happen in 
path-based files...

Alice: I see. That's why you tried to generate the .sfd file listing
the fonts it loads and give it one random type1 font from ghostscript 
which you named as Slim in the sfd. You won't make it render fonts, 
but at least you can make it survive the mention of fonts.

[...]

After some more debugging, Alice finds that adding this one line at the 
end of /usr/lib/python2.5/site-packages/uniconvertor/app/Graphics/font.py
fixes it:

read_font_dirs()

Now she can convert hola-path.svg to hola-path.pdf correctly, 
by following README.Debian.

Bob: Great!. So this is it. 

Alice: Well. I can go on with my work, but it's 

Bug#510658: postgresql-8.3: default cluster main not created

[Xavi Drudis Ferran]

On Sat, Feb 28, 2009 at 02:26:27PM +0100, Martin Pitt wrote:
 Hello again everyone,
 
 Martin Pitt [2009-02-28 13:46 +0100]:
  First, I assume that most of you installed postgresql-8.3 *after* the
  initial Debian installation, i. e. you did not choose the database
  server task in debian-installer? If you did, then please have a look
  at /var/log/installer and check if they have anything regarding to
  postgresql, in particular the package install log.
 
 In particular, please check if you have the same symptoms as
 http://bugs.debian/org/517389, i. e. you get something like
 
   /dev/null: Permission denied
 
 in the installer environment.
 

I don't remember having seen that.
But I'm pretty sure I would have reported it if I had seen it, even tired
as I was when filing the bug.




-- 
xdru...@tinet.cat
Signa per fer Collserola parc natural com cal
http://www.collserola.org/salvemelparcnatural/



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

Bug#510658: postgresql-8.3: default cluster main not created

[Xavi Drudis Ferran]

On Sat, Feb 28, 2009 at 01:46:32PM +0100, Martin Pitt wrote:
 Hello all,
 
 First, I assume that most of you installed postgresql-8.3 *after* the
 initial Debian installation, i. e. you did not choose the database
 server task in debian-installer? If you did, then please have a look
 at /var/log/installer and check if they have anything regarding to
 postgresql, in particular the package install log.


I did an install without the dtabase task and after that I 
selected many packages for instalation, postgresql among them. 
 
 But many reporters pointed out that the installed PostgreSQL later,
 thus I don't think it is an install-time only bug. Can anyone of you
 still say whether you already had the package locales installed when
 you installed postgresql-8.3? Did you have a locale configured and
 used?
 

I was using ca_ES.UTF-8. Apparently well configured/installed. 

 
 First, failure case: This usually happens if the locale is invalid,
 but that wouldn't leave an /etc/postgresql/ behind (see above). Then
 there can be all sorts of file system things, such as /var not being
 writable, but since it works with a manual pg_createcluster, I don't
 believe that this is the reason for all your reports.


I didn't fic any of these before I could manually create the cluster. 
I installed with just the root partition and swap. And the partition 
was writeable. I checked the logs and I didn't see anything unusal, 
so I guess /var/log/ was writable. 

I don't know much more and that system is still running windows :( .
I think it's only been booted to linux once since my report, for some minutes 
only. 
  
 Then, the not attempted case: This is determined in
 /usr/share/postgresql-common/maintscripts-functions,
 configure_version():
 
|# arguments: major version most recently configured package version
|configure_version() {
|VERSION=$1
|
|# Create a main cluster for given version ($1) if no cluster already 
 exists
|# for that version and we are installing from scratch.
|[ $VERSION ] || { echo Error: configure_version: need version 
 parameter 2; exit 1; }
|if [ ! -d /etc/postgresql/$VERSION ] || [ -z $(ls 
 /etc/postgresql/$VERSION) ] || \
|   [ -z $(ls /etc/postgresql/$VERSION/*/postgresql.conf 
 2/dev/null) ]; then
|[ $2 ] || /usr/bin/pg_createcluster -u postgres $VERSION main 
 || {
|echo Error: could not create default cluster. Please create it 
 manually with
|
|  pg_createcluster $VERSION main --start
|
|or a similar command (see 'man pg_createcluster'). 2
|}
|fi
|
|_link_manpages $VERSION postgresql-$VERSION postmaster.1.gz
|}
 
 So this means that a cluster is only created automatically if:
 
  1. /etc/postgresql/8.3/ does not exist, or /etc/postgresql/8.3/ is
 empty, or /etc/postgresql/8.3/main/postgresql.conf does not exist

Mmm.. I copied some configurations from another machine. I don't think 
I copied  /etc/postgresql/8.3/main/postgresql.conf but I guess I might have. 
But I reported /etc/postgres was empty, so I guess I didn't copy it. 

  2. The package postgresql-8.3 was not installed before, or was
 purged.



It wasn't installed before and was ony purged after the issue appeared.
 
 It seems very unlikely to me that those conditions were not met with a
 fresh Lenny install, though, but perhaps it gives some of you a clue
 what could have happened.
 

No clue, sorry. In fact the more I think of it the less I can explained it. 
It just happened. What gives ?

 How exactly did you install Lenny? Which medium, which tasks, which
 locales? Could any of you attach the installer logs
 (/var/log/installer)?
 

I choosed Catalan language in the installer, and configured ca_ES.UTF-8 
as default locale. I can't attach the logs now, but I guess it doesn't 
matter since it wasn't installed from the debian installer.

Sorry for being unhelpful. 

Thanks for your caring for this bug report. 



-- 
xdru...@tinet.cat
Signa per fer Collserola parc natural com cal
http://www.collserola.org/salvemelparcnatural/



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

Bug#514366: udev: iRiver IFP590T usable only by root

[Xavi Drudis Ferran]

Package: udev
Version: 0.125-7
Severity: normal
File: /sbin/udevd
Tags: patch


Hello, and thanks for Debian.

Years ago I made an iRiver IFP-590T work for a friend of mine (using
sid). It is a music player accessed by USB but it's not using USB Mass
Storage
firmware. It uses managed firmware which allows a little more
functionality and has a driver.

She stopped using it it for some time and recently told she's tried
again
and it no longer works. I checked and saw that it her user (in plugdev
group) did not have permissions for the device, but root had.

I found some lines in  /etc/udev/rules.d/91-permissions.rules assigning
group plugdev for iRiver devices, but
they seemed to be outdated. I added some other lines and now it works.

I'm not sure I know what I'm doing but it works for us now, so I leave
it here and inform the maintainers in case they want to consider to add
the lines or fixing it somehow else.

Old lines were

 SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device,  GROUP=plugdev, \
ATTRS{idVendor}==4102, ATTRS{idProduct}==10[01][135789]

and I added
SUBSYSTEM==usb_device,GROUP=plugdev, \
ATTRS{idVendor}==4102, ATTRS{idProduct}==10[01][135789]


...s'està ometent 53 línies
/sys/block/hda/hda1/dev
/sys/block/hda/hda2/dev
/sys/block/hda/hda3/dev
/sys/block/hda/hda5/dev
/sys/block/hdc/dev
/sys/block/ram0/dev
/sys/block/ram10/dev
/sys/block/ram11/dev
/sys/block/ram12/dev
/sys/block/ram13/dev
/sys/block/ram14/dev
/sys/block/ram15/dev
/sys/block/ram1/dev
/sys/block/ram2/dev
/sys/block/ram3/dev
/sys/block/ram4/dev
/sys/block/ram5/dev
/sys/block/ram6/dev
/sys/block/ram7/dev
/sys/block/ram8/dev
/sys/block/ram9/dev
/sys/class/cpuid/cpu0/dev
/sys/class/input/input0/event0/dev
/sys/class/input/input1/event1/dev
/sys/class/input/input2/event2/dev
/sys/class/input/input2/mouse0/dev
/sys/class/input/mice/dev
/sys/class/misc/agpgart/dev
/sys/class/misc/fuse/dev
/sys/class/misc/hpet/dev
/sys/class/misc/psaux/dev
/sys/class/misc/snapshot/dev
/sys/class/ppdev/parport0/dev
/sys/class/printer/lp0/dev
/sys/class/sound/adsp/dev
/sys/class/sound/audio/dev
/sys/class/sound/controlC0/dev
/sys/class/sound/dsp/dev
/sys/class/sound/mixer/dev
/sys/class/sound/pcmC0D0c/dev
/sys/class/sound/pcmC0D0p/dev
/sys/class/sound/pcmC0D1c/dev
/sys/class/sound/seq/dev
/sys/class/sound/sequencer2/dev
/sys/class/sound/sequencer/dev
/sys/class/sound/timer/dev
/sys/class/usb_device/usbdev1.1/dev
/sys/class/usb_device/usbdev1.3/dev
/sys/class/usb_device/usbdev1.9/dev
/sys/class/usb_device/usbdev2.1/dev
/sys/class/usb_device/usbdev3.1/dev
/sys/class/usb_endpoint/usbdev1.1_ep00/dev
/sys/class/usb_endpoint/usbdev1.1_ep81/dev
/sys/class/usb_endpoint/usbdev1.3_ep00/dev
/sys/class/usb_endpoint/usbdev1.3_ep81/dev
/sys/class/usb_endpoint/usbdev1.9_ep00/dev
/sys/class/usb_endpoint/usbdev1.9_ep03/dev
/sys/class/usb_endpoint/usbdev1.9_ep83/dev
/sys/class/usb_endpoint/usbdev2.1_ep00/dev
/sys/class/usb_endpoint/usbdev2.1_ep81/dev
/sys/class/usb_endpoint/usbdev3.1_ep00/dev
/sys/class/usb_endpoint/usbdev3.1_ep81/dev

-- Kernel configuration:
 isapnp_init not present.


-- System Information:
Debian Release: 5.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.21usbaudio1 (PREEMPT)
Locale: LANG=ca_ES, LC_CTYPE=ca_ES (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages udev depends on:
ii  debconf [debconf-2.0] 1.5.24 Debian configuration management sy
ii  libc6 2.7-18 GNU C Library: Shared libraries
ii  libselinux1   2.0.65-5   SELinux shared libraries
ii  libvolume-id0 0.125-7libvolume_id shared library
ii  lsb-base  3.2-20 Linux Standard Base 3.2 init scrip

udev recommends no packages.

udev suggests no packages.

-- debconf information:
  udev/new_kernel_needed: false
  udev/reboot_needed:

--- /etc/udev/rules.d/91-permissions.rules~	2008-09-19 03:11:42.0 +0200
+++ /etc/udev/rules.d/91-permissions.rules	2009-02-06 19:14:27.0 +0100
@@ -42,6 +42,8 @@
 # iRiver music players
 SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device,	GROUP=plugdev, \
 	ATTRS{idVendor}==4102, ATTRS{idProduct}==10[01][135789]
+SUBSYSTEM==usb_device, 	GROUP=plugdev, \
+	ATTRS{idVendor}==4102, ATTRS{idProduct}==10[01][135789]
 
 # serial devices
 SUBSYSTEM==tty,GROUP=dialout

Bug#510658: postgresql-8.3: default cluster main not created

[Xavi Drudis Ferran]

Package: postgresql-8.3
Version: 8.3.5-1
Severity: important



Hello , and thanks for packaging postgresql in Debian. 
I've used it for some years (though I'm no expoert) and 
has always worked fine . 

This time I installed it on 2 amd64 PCs . 

I one it run ok, but in the other it didn't create the main 
cluster. /etc/postgresql and /var/lib/postgresql were empty
after installation. 

I tried /etc/init.d/postgresql-8.3 restart ,  aptitude reinstall and 
purge and 
install but 
still
it wouldn't create it. 

The only message I could see in the console was about Debian version 
5.0 being unknown (there's another bug about that but it said it's a 
warning only). 

After reading the docs I did a simple 

pg_createcluster 8.3  main --start

and it worked. It created the cluster, populating 
etc/postgresql/8.3/main and /var/lib/postgresql

I'm not sure it can be reproduced because the other PC I was installing 
at the same time had no issue at all. 

The installation was on 26.12.2008, I believe. 

I installed from a Lenny RC1 netinst CD for amd64. 
I think I picked file server and print server from the tasksel
I then did dpkg --set-selections from a list of packages 
taken from a laptop , I'll attach the list. 

I configured printers, ssh, X, etc.

And when I tried to access psql a week later, found there wasn't 
a cluster, only in one of the 2 PCs. 

I'm puzzled, but I'm also tired right now. 
I'm not sure this report it's useful, but I found it very strange, 
and didn't know where to llok for clues. It works now, but it's 
never failed installation like this before. I never had to create main.


-- System Information:
Debian Release: 5.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages postgresql-8.3 depends on:
ii  libc6 2.7-16 GNU C Library: Shared libraries
ii  libcomerr21.41.3-1   common error description library
ii  libkrb53  1.6.dfsg.4~beta1-4 MIT Kerberos runtime libraries
ii  libldap-2.4-2 2.4.11-1   OpenLDAP libraries
ii  libpam0g  1.0.1-4+b1 Pluggable Authentication Modules l
ii  libpq58.3.5-1PostgreSQL C client library
ii  libssl0.9.8   0.9.8g-14  SSL shared libraries
ii  libxml2   2.6.32.dfsg-5  GNOME XML library
ii  locales   2.7-16 GNU C Library: National Language (
ii  postgresql-client-8.3 8.3.5-1front-end programs for PostgreSQL 
ii  postgresql-common 94 PostgreSQL database-cluster manage
ii  ssl-cert  1.0.23 simple debconf wrapper for OpenSSL
ii  tzdata2008h-2time zone and daylight-saving time

postgresql-8.3 recommends no packages.

Versions of packages postgresql-8.3 suggests:
ii  pidentd [ident-server]  3.0.19.ds1-4 TCP/IP IDENT protocol server with 

-- no debconf information
acheck  install
acheck-rules-fr install
acpiinstall
acpi-supportinstall
acpi-support-base   install
acpid   install
adduser install
alacarteinstall
alsa-base   install
alsa-utils  install
anacron install
apertiuminstall
apertium-es-ca  install
apertium-es-pt  install
apertium-fr-ca  install
apmdinstall
app-install-datainstall
apt install
apt-utils   install
aptitudeinstall
aptitude-doc-fr install
arj install
arno-iptables-firewall  install
aspell  install
aspell-ca   install
aspell-es   install
aspell-fr   install
at  install
autoconfinstall
automakeinstall
automake1.4 install
automake1.9 install
autotools-dev   install
base-files 

Bug#498618: syntax error makes apertium fail

[Xavi Drudis Ferran]

Package: apertium
Version: 3.0.7+1-1.1
Severity: grave
Tags: patch
Justification: renders package unusable



There's a syntax error at line 113 /usr/bin/apertium, 
because of a misplace temporary file creation . 

It's solved by this tiny patch

Patch 

113,114c113,114
   TMP_XLSXEMBED=`mktemp`
   do $APERTIUM_PATH/apertium -f xlsx -d $DIRECTORY $OPCIONU $PREFIJO 
$i $TMP
_XLSXEMBED;
---
   do TMP_XLSXEMBED=`mktemp` ;
$APERTIUM_PATH/apertium -f xlsx -d $DIRECTORY $OPCIONU $PREFIJO $i 
$TMP_X
LSXEMBED;

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

Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages apertium depends on:
ii  libapertium3-3.0-0 3.0.7+1-1.1   Shared library for Apertium
ii  libc6  2.7-13GNU C Library: Shared libraries
ii  libgcc11:4.3.2-1 GCC support library
ii  liblttoolbox3-3.0-03.0.2+1-1 Shared library for the lttoolbox
ii  libpcre3   7.6-2.1   Perl 5 Compatible Regular Expressi
ii  libpcrecpp07.6-2.1   Perl 5 Compatible Regular Expressi
ii  libstdc++6 4.3.2-1   The GNU Standard C++ Library v3
ii  libxml22.6.32.dfsg-3 GNOME XML library
ii  libxml2-utils  2.6.32.dfsg-3 XML utilities
ii  lttoolbox  3.0.2+1-1 Apertium lexical processing module

apertium recommends no packages.

apertium suggests no packages.

-- debconf-show failed
113,114c113,114
   TMP_XLSXEMBED=`mktemp`
   do $APERTIUM_PATH/apertium -f xlsx -d $DIRECTORY $OPCIONU $PREFIJO $i 
$TMP_XLSXEMBED;
---
   do TMP_XLSXEMBED=`mktemp` ;
$APERTIUM_PATH/apertium -f xlsx -d $DIRECTORY $OPCIONU $PREFIJO $i 
 $TMP_XLSXEMBED;

Bug#482140: [xml/sgml-pkgs] Bug#482140: must be /etc/sgml

[Xavi Drudis Ferran]

On Fri, May 30, 2008 at 01:45:40AM +0200, Daniel Leidert wrote:
 Am Mittwoch, den 28.05.2008, 22:34 +0200 schrieb Xavi Drudis Ferran:
 
  I'm sending my /var/lib/dpkg/info/docbook-xml.postinst
 
 Please set -ex at the top of the script to get more output and then just
 configure the package (dpkg -a docbook-xml). This should show, which
 command fails.
 

Just one quick note, I must leave. I no longer have that amd64 laptop with 
me. I was installing it for a friend and gave it back to her today.
(I could fix the problem by removing and installing the package, but 
of course this is not the solution we want). 
I'll see what I can do to try to reproduce it though.


 
 I really have no clue about the issue atm. For me everything works (I
 now ran 3 upgrades in a CHROOT - all successful) and I currently have no
 idea, which part could fail/fails.
 

I see. I don't have much clue either. 

I'll try to think a little more on what can I do later. 

-- 
[EMAIL PROTECTED]
Signa per fer Collserola parc natural com cal
http://www.collserola.org/salvemelparcnatural/



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

Bug#482140: /etc/xml tarball

[Xavi Drudis Ferran]

Here's my /etc/xml diretory in a tarball.

My catalog file is the same as postedby Christofer C. Bell, just with the lines
in different order (I guess it doesn't matter)

I'll try to have a look before removing and reinstalling the package, just in 
case I see
ehat may be happening...



xml.tgz
Description: application/compressed-tar

Bug#482140: must be /etc/sgml

[Xavi Drudis Ferran]

Hi.

I'm sending my /var/lib/dpkg/info/docbook-xml.postinst

The line that's failing is the one after the initial for loop:

update-catalog  --add --super /etc/sgml/docbook-xml.cat

In my /etc/sgml/catalog I already have a line with /etc/sgml/docbook-xml.cat

and it's also in /etc/sgml/catalog.old

I'm attaching a tarball of /etc/sgml (before playing with the scripts)

But the .prerm script looks like it should have removed the docbook-xml.cat 
entry.
In fact it does if I run it with upgrade as an argument

In my /var/log/dpkg.log it looks like docbook-xml 4.4-5 was installed, and 
afterwards
and upgrade to 4.5-5 was attempted but it was left half-configured

So my only guess is that maybe the prerm script in docbook-xml 4.4-5 did not
run update-catalog --quiet --remove --super /etc/sgml/docbook-xml.cat
for some reason ?

Maybe the bug is in etch, not lenny, but it can be worked around in lenny ?

I can't seem to understand anything more, so I'm removing and installing the 
package to
continue the instalation.

Hope this helps somehow...

sgml.tgz
Description: application/compressed-tar


docbook-xml.postinst
Description: Binary data

Bug#482140: sorry, different bug

[Xavi Drudis Ferran]

I have lost the error message now, but I guess in my case
it must have been update-catalog complaining, and not
update-xmlcatalog, so my bug must be a different one,
although possibly related. Something didn't work right
in docbook-xml.prerm for 4.4-5, I guess




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

Bug#482140: Confirming bug

[Xavi Drudis Ferran]

Hi.

This exact problem happened to me last night.
I installed etch (amd64) on a new laptop, wasn't happy with the support
of the intel GM965 graphics board, and decided to upgrade to lenny
for the intel Xorg driver. I selected printing server, desktop environment,
and standard system, in the etch installer.

Then it complained of this error.

I can't send the file now, because I'm not at that computer, I'll try to send it
asap, (in some 6 or 7 hours hopefully, else in a couple of days :( )

I'm just replying since I see the bug marked as unreproducible, and it just
hit me.

Thanks all for your great work.




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

Bug#414380: amaya_wx-9.99-1_i386.deb does not suffer of #414380 here

[Xavi Drudis Ferran]

Package: amaya
Followup-For: Bug #414380


Hi.

I'm at a friend's computer, on debian unstable.
We ran into a problem looking all like  #414380 in which amaya
did not start. Curious thig is that it worked over
freeNX (tried from 2 different clients, the remote amaya
opened fine). I tried disabling GLX and/or DRI in  /etc/X11/xorg.conf
but it didn't fix it. I tried other packages from w3c.org,
instead of the debian one. No luck.

Today I've tried W3C's amaya-9.99 (the deb package) from
http://wam.inrialpes.fr/software/amaya/amaya_wx-9.99-1_i386.deb
and it started ok and seems to work fine.

 amaya 9.54~dfsg.0-1 did not work.

I have no idea what the cause may be, but I thought I wrote
to let you know, just in case it gives some hitn to fix or
work around it.

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

Kernel: Linux 2.6.21usbaudio1 (PREEMPT)
Locale: LANG=ca_ES, LC_CTYPE=ca_ES (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages amaya depends on:
ii  libatk1.0-0 1.20.0-1 The ATK accessibility toolkit
ii  libc6   2.6.1-5  GNU C Library: Shared libraries
ii  libexpat1   1.95.8-4 XML parsing C library - runtime li
ii  libfontconfig1  2.4.2-1.2generic font configuration library
ii  libfreetype62.3.5-1+b1   FreeType 2 font engine, shared lib
ii  libgcc1 1:4.2.2-1GCC support library
ii  libgl1-mesa-swx11 [libg 7.0.1-2  A free implementation of the OpenG
ii  libglib2.0-02.14.1-5 The GLib library of C routines
ii  libglu1-mesa [libglu1]  7.0.1-2  The OpenGL utility library (GLU)
ii  libgtk2.0-0 2.12.0-2 The GTK+ graphical user interface
ii  libpango1.0-0   1.18.2-2 Layout and rendering of internatio
ii  libsm6  2:1.0.3-1+b1 X11 Session Management library
ii  libstdc++6  4.2.2-1  The GNU Standard C++ Library v3
ii  libx11-62:1.0.3-7X11 client-side library
ii  libxcursor1 1:1.1.9-1X cursor management library
ii  libxext61:1.0.3-2X11 miscellaneous extension librar
ii  libxfixes3  1:4.0.3-2X11 miscellaneous 'fixes' extensio
ii  libxi6  2:1.1.3-1X11 Input extension library
ii  libxinerama11:1.0.2-1X11 Xinerama extension library
ii  libxrandr2  2:1.2.2-1X11 RandR extension library
ii  libxrender1 1:0.9.4-1X Rendering Extension client libra
ii  zlib1g  1:1.2.3.3.dfsg-6 compression library - runtime

amaya recommends no packages.

-- no debconf information





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

Bug#434111: gthumb: Please add utf-8 hint in .htaccess in album themes

[Xavi Drudis Ferran]

Package: gthumb
Version: 3:2.10.2-4
Severity: wishlist

Hi. 

I've found this small problem twice or thrice already, so I'm sending 
this suggestion.

When gthumb generated photo albums it writes utf-8 encoded xhtml files, 
and declares them as utf-8. So when you open the album in a local 
browser it displays ok. But some people upload the album to an apache 
web server that is configured to send an http header declaring 
iso-8859-1 encoding for every html file it serves (for instance because 
they sually write their html pages in iso-8859-1). When browsing 
the uploaded album remotely the browser apparently gets the wrong header
and renders the international characters wrong. 

If the server is configured to allow configuration in every content 
directory with .htaccess files (that is if the AllowOverride directive
aplicable to the given directory includes the FileInfo keyword), then 
there is a simple fix which is to include an .htaccess file in the 
album with a singe line in its content: 

  AddType text/html; charset=UTF-8 html

This will only solve anything in some apache configurations, but at 
least in my sid I see the apache2 configured with AllowOverride FileInfo
for user directories (in fact it might not show this problems because
the default encodign is already UTF-8, but one may change it either 
in httpd.conf or in a upper level .htaccess in a user dir or whatever). 
At least I don't think this has any chance of breaking anything, so 
I suggest adding this .htaccess file in every album theme in gthumb, 
so that it gets automatically copied to the generated photo albums 
and they work ok when uploaded to some apache servers. 

I did it in my computer with 

for d in /usr/share/gthumb/albumthemes/* ; do  cp .htaccess $d ; done

as root. 

Maybe the .htaccess file and some similar configuration could 
be added to some gthumb post-inst script ? 


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

Kernel: Linux 2.6.21-2-486
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages gthumb depends on:
ii  gconf2  2.18.0.1-3   GNOME configuration database syste
ii  libart-2.0-22.3.19-3 Library of functions for 2D graphi
ii  libatk1.0-0 1.18.0-2 The ATK accessibility toolkit
ii  libbonobo2-02.18.0-2 Bonobo CORBA interfaces library
ii  libbonoboui2-0  2.18.0-5 The Bonobo UI library
ii  libc6   2.6-2GNU C Library: Shared libraries
ii  libcairo2   1.4.10-1 The Cairo 2D vector graphics libra
ii  libexif12   0.6.16-1 library to parse EXIF files
ii  libfontconfig1  2.4.2-1.2generic font configuration library
ii  libgconf2-4 2.18.0.1-3   GNOME configuration database syste
ii  libglade2-0 1:2.6.1-1library to load .glade files at ru
ii  libglib2.0-02.12.12-1+b1 The GLib library of C routines
ii  libgnome-keyring0   0.8.1-2  GNOME keyring services library
ii  libgnome2-0 2.18.0-4 The GNOME 2 library - runtime file
ii  libgnomecanvas2-0   2.14.0-3 A powerful object-oriented display
ii  libgnomeui-02.18.1-2 The GNOME 2 libraries (User Interf
ii  libgnomevfs2-0  1:2.18.1-3+b1GNOME Virtual File System (runtime
ii  libgphoto2-22.3.1-5+b1   gphoto2 digital camera library
ii  libgphoto2-port02.3.1-5+b1   gphoto2 digital camera port librar
ii  libgtk2.0-0 2.10.13-1The GTK+ graphical user interface 
ii  libice6 1:1.0.3-2X11 Inter-Client Exchange library
ii  libjpeg62   6b-13The Independent JPEG Group's JPEG 
ii  liborbit2   1:2.14.7-0.1 libraries for ORBit2 - a CORBA ORB
ii  libpango1.0-0   1.16.4-2 Layout and rendering of internatio
ii  libpopt01.10-3   lib for parsing cmdline parameters
ii  libsm6  2:1.0.3-1+b1 X11 Session Management library
ii  libtiff43.8.2-7  Tag Image File Format (TIFF) libra
ii  libusb-0.1-42:0.1.12-7   userspace USB programming library
ii  libx11-62:1.0.3-7X11 client-side library
ii  libxcursor1 1:1.1.8-2X cursor management library
ii  libxext61:1.0.3-2X11 miscellaneous extension librar
ii  libxfixes3  1:4.0.3-2X11 miscellaneous 'fixes' extensio
ii  libxi6  2:1.1.1-1X11 Input extension library
ii  libxinerama11:1.0.2-1X11 Xinerama extension library
ii  libxml2 2.6.29.dfsg-1GNOME XML library
ii  libxrandr2  2:1.2.1-1X11 RandR extension library
ii  libxrender1 

Bug#408082: amaya: 9.51-2.1 upgraded from 9.2.1 does not start

[Xavi Drudis Ferran]

Package: amaya
Version: 9.51-2.1
Severity: important

Hi. 

I'm not sure how important this is but I found a reminder I had to send 
a report, it may affect few users, but for those like me amaya does not 
start. 

I had amaya 9.2.1 installed on 3 PCs and tried to upgrade to amaya 
9.51-2.1, but after the upgrade amaya wouldn't start. I haven't 
researched whether I did something special to that amaya installation
because I don't think I might have done it in all 3 computers. 

Apparently it was because there were som empty directoris under
/usr/lib/amaya . I don't know the exact reason, but it wasn't finding
some files and I could fix it by doing 

for f in /usr/share/amaya/* ; do b=`basename $f`;  rmdir 
/usr/lib/amaya/$b ; ln -s $f /usr/lib/amaya/$b ; done

I hope it helps somehow...



-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18ideafix1
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)

Versions of packages amaya depends on:
ii  libc6 2.3.6.ds1-10   GNU C Library: Shared libraries
ii  libexpat1 1.95.8-3.4 XML parsing C library - runtime li
ii  libfreetype6  2.2.1-5FreeType 2 font engine, shared lib
ii  libgcc1   1:4.1.1-21 GCC support library
ii  libgl1-mesa-glx [libgl1]  6.5.1-0.5  A free implementation of the OpenG
ii  libglu1-mesa [libglu1]6.5.1-0.5  The OpenGL utility library (GLU)
ii  libjpeg62 6b-13  The Independent JPEG Group's JPEG 
ii  libpng12-01.2.15~beta5-1 PNG library - runtime
ii  libraptor11.4.13-1   Raptor RDF parser and serializer l
ii  librdf0   1.0.4-1Redland Resource Description Frame
ii  libstdc++64.1.1-21   The GNU Standard C++ Library v3
ii  libwww-ssl0   5.4.0-11   The W3C-WWW library (SSL support)
ii  libwxbase2.6-02.6.3.2.1.5wxBase library (runtime) - non-GUI
ii  libwxgtk2.6-0 2.6.3.2.1.5wxWidgets Cross-platform C++ GUI t
ii  ttf-freefont  20060501cvs-10 Freefont Serif, Sans and Mono True
ii  zlib1g1:1.2.3-13 compression library - runtime

amaya recommends no packages.

-- no debconf information


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

Bug#348706: amaya: Something similar on 9.4-1

[Xavi Drudis Ferran]

Package: amaya
Version: 9.4-1
Followup-For: Bug #348706


I'm not sure whether my bug is related to this one,
or is something new, but at least it's error code 8 too
It happend on two different sid machines.

amaya won't start complaining of 

The program 'amaya' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
  (Details: serial 11267 error_code 8 request_code 144 minor_code 5)
(Note to programmers: normally, X errors are reported
asynchronously;
   that is, you will receive the error a while after causing it.
  To debug your program, run it with the --sync command line
 option to change this behavior. You can then get a
 meaningful
backtrace from your debugger if you break on the
gdk_x_error() function.)


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (650, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=locale: Cannot set 
LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968)

Versions of packages amaya depends on:
ii  libatk1.0-0   1.10.3-1   The ATK accessibility toolkit
ii  libc6 2.3.6-3GNU C Library: Shared libraries an
ii  libcairo2 1.0.2-3The Cairo 2D vector graphics libra
ii  libexpat1 1.95.8-3   XML parsing C library - runtime li
ii  libfontconfig12.3.2-2generic font configuration library
ii  libfreetype6  2.1.10-1   FreeType 2 font engine, shared lib
ii  libgcc1   1:4.0.2-10 GCC support library
ii  libglib2.0-0  2.8.6-1The GLib library of C routines
ii  libglu1-xorg [libglu1]6.9.0.dfsg.1-4 Mesa OpenGL utility library [X.Org
ii  libgtk2.0-0   2.8.13-1   The GTK+ graphical user interface 
ii  libpango1.0-0 1.10.4-1   Layout and rendering of internatio
ii  libstdc++64.0.2-10   The GNU Standard C++ Library v3
ii  libx11-6  6.9.0.dfsg.1-4 X Window System protocol client li
ii  libxcursor1   1.1.3-1X cursor management library
ii  libxext6  6.9.0.dfsg.1-4 X Window System miscellaneous exte
ii  libxi66.9.0.dfsg.1-4 X Window System Input extension li
ii  libxinerama1  6.9.0.dfsg.1-4 X Window System multi-head display
ii  libxrandr26.9.0.dfsg.1-4 X Window System Resize, Rotate and
ii  libxrender1   1:0.9.0.2-1X Rendering Extension client libra
ii  libxxf86vm1   6.9.0.dfsg.1-4 X Video Mode selection library
ii  xlibmesa-gl [libgl1]  6.9.0.dfsg.1-4 Mesa 3D graphics library [X.Org]
ii  zlib1g1:1.2.3-10 compression library - runtime

Versions of packages amaya recommends:
pn  amaya-doc none (no description available)

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = [EMAIL PROTECTED]
are supported and installed on your system.
perl: warning: Falling back to the standard locale (C).
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory


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