Bug#1037878: ultracopier: diff for NMU version 2.2.6.0-1.1

[Thomas Preud'homme]

Thanks, much appreciated. Feel free to upload it right away.

Best regards,
Thomas

On 10 September 2023 09:12:35 WEST, Marcos Talau  wrote:
>Control: tags 1037878 + patch
>Control: tags 1037878 + pending
>
>
>Dear maintainer,
>
>I've prepared an NMU for ultracopier (versioned as 2.2.6.0-1.1) and
>uploaded it to DELAYED/2. Please feel free to tell me if I
>should delay it longer.
>
>Regards.
>

Bug#1043140: Patches work for me

[Thomas Preud'homme]

FYI when rebuilding weston-12 with the patches listed in 
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1257/commits 
weston stop crashing.


Best regards,
Thomas

Bug#1043140: libweston-12-0: Weston fails to start with "Assertion `csi->width == width' failed"

[Thomas Preud'homme]

Package: libweston-12-0
Version: 12.0.1-1
Severity: important
Tags: upstream

After upgrading my system sddm fails to start a wayland session with the
following error in .local/share/sddm/wayland-session.log:

weston: ../libweston/output-capture.c:398 weston_output_pull_capture_task: 
Assertion `csi->width == width' failed.
Failed to process Wayland connection: Broken pipe
failed to create display: Broken pipe
Failed to process Wayland connection: Broken pipe
failed to create display: Broken pipe

This seems to match upstream bug
https://gitlab.freedesktop.org/wayland/weston/-/issues/757 which is also
against weston 12.0 and has a fix. Hopefully this can be applied to the
Debian package.

Best regards,
Thomas

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (500, 'unstable-debug'), (500, 
'stable-updates'), (500, 'stable-security'), (500, 'testing'), (500, 'stable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.4.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libweston-12-0 depends on:
ii  libaml0 0.3.0-1
ii  libc6   2.37-7
ii  libcairo2   1.16.0-7
ii  libdrm2 2.4.115-1
ii  libegl1 1.6.0-1
ii  libfontconfig1  2.14.1-4
ii  libfreerdp-server2-22.10.0+dfsg1-1
ii  libfreerdp2-2   2.10.0+dfsg1-1
ii  libgbm1 23.1.4-1
ii  libgles21.6.0-1
ii  libglib2.0-02.77.1-2
ii  libgstreamer-plugins-base1.0-0  1.22.4-1
ii  libgstreamer1.0-0   1.22.4-1
ii  libinput10  1.23.0-2
ii  libjpeg62-turbo 1:2.1.5-2
ii  liblcms2-2  2.14-2
ii  libneatvnc0 0.6.0+dfsg-4+b1
ii  libpam0g1.5.2-6
ii  libpango-1.0-0  1.50.14+ds-1
ii  libpangocairo-1.0-0 1.50.14+ds-1
ii  libpipewire-0.3-0   0.3.77-1
ii  libpixman-1-0   0.42.2-1
ii  libpng16-16 1.6.40-1
ii  libseat10.8.0-1
ii  libudev1254-1
ii  libva-drm2  2.19.0-1
ii  libva2  2.19.0-1
ii  libwayland-client0  1.22.0-2
ii  libwayland-cursor0  1.22.0-2
ii  libwayland-egl1 1.22.0-2
ii  libwayland-server0  1.22.0-2
ii  libwebp71.2.4-0.2
ii  libwinpr2-2 2.10.0+dfsg1-1
ii  libx11-62:1.8.6-1
ii  libx11-xcb1 2:1.8.6-1
ii  libxcb-composite0   1.15-1
ii  libxcb-render0  1.15-1
ii  libxcb-shm0 1.15-1
ii  libxcb-xfixes0  1.15-1
ii  libxcb-xkb1 1.15-1
ii  libxcb1 1.15-1
ii  libxcursor1 1:1.2.1-1
ii  libxkbcommon0   1.5.0-1

libweston-12-0 recommends no packages.

libweston-12-0 suggests no packages.

-- no debconf information

Bug#1037878: Processed: tagging 1037878

[Thomas Preud'homme]

Unfortunately I won't be able to do it until August but anyone feel free to do 
an NMU.

My apologies. Best regards,
Thomas

On 21 July 2023 07:04:57 GMT+08:00, alpha_one_x86 
 wrote:
>Fixed into the last version, please update to Ultracopier 2.2.6.7

Bug#971291: salutatoi: Switch to python3-pycryptodome

[Thomas Preud'homme]

I've contacted upstream who said they are planning an alpha in the next 
few weeks and a stable release later in the year. I'll try to upload the 
alpha to experimental and once the new release comes out upload it to 
unstable and close this bug.


Best regards,

Thomas

On 2020-09-28 23:26, Thomas Preud'homme wrote:

Upstream seems to have moved to the module cryptography:
https://repos.goffi.org/sat/rev/330a5f1d9eea. Unfortunately that
commit is not part of the 0.7 release. I wonder if we could persuade
upstream from cutting a minor release for us to package.

Best regards,

Thomas

On 2020-09-28 22:29, Sebastian Ramacher wrote:

Source: salutatoi
Version: 0.8.0~hg3247.f981c0e99220-2
Severity: important
Tags: sid bullseye
Usertags: pycrypto

Dear maintainer,

salutatoi currently Build-Depends or Depends on python3-crypto from
PyCrypto. This project is no longer maintained and PyCryptodome
(https://www.pycryptodome.org/en/latest/) provides a drop in
replacement. Please switch to python3-pycryptodome. I'd like to
remove python-crypto before the release of bullseye.

Cheers

Bug#971291: salutatoi: Switch to python3-pycryptodome

[Thomas Preud'homme]

Upstream seems to have moved to the module cryptography: 
https://repos.goffi.org/sat/rev/330a5f1d9eea. Unfortunately that commit 
is not part of the 0.7 release. I wonder if we could persuade upstream 
from cutting a minor release for us to package.


Best regards,

Thomas

On 2020-09-28 22:29, Sebastian Ramacher wrote:

Source: salutatoi
Version: 0.8.0~hg3247.f981c0e99220-2
Severity: important
Tags: sid bullseye
Usertags: pycrypto

Dear maintainer,

salutatoi currently Build-Depends or Depends on python3-crypto from
PyCrypto. This project is no longer maintained and PyCryptodome
(https://www.pycryptodome.org/en/latest/) provides a drop in
replacement. Please switch to python3-pycryptodome. I'd like to
remove python-crypto before the release of bullseye.

Cheers

Bug#970261: RM: mrd6 -- ROM; No longer maintained

[Thomas Preud'homme]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: 

Dear FTP masters,

Please remove mrd6 from the unstable distribution as it is no longer
maintained since 2013. Quoting its README file [1]:

"[note from the author, 2013: mrd6 is unsupported software. Since
 2005 native multicast forwarding support has been added to Linux
 and pim6sd can be used to manage it. mrd6's codebase is kept
 around for historical reasons, it should still work in current
 kernels and still allows you to do funky things with routing.
 Feel free to fork. -hugo]"

[1] https://github.com/hugosantos/mrd6/blob/master/README

It currently has a popcon of 13.

Best regards,

Thomas

Bug#968214: ultracopier FTCBFS: missing Build-Depends: qt5-qmake:native for lrelease

[Thomas Preud'homme]

On 2020-08-10 22:06, Helmut Grohne wrote:

Source: ultracopier
Version: 1.6.1.3-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

ultracopier fails to cross build from source, because it runs lrelease
on a .pro file without the relevant build dependency on
qt5-qmake:native. Please consider applying the attached patch.


tag 968214 + moreinfo
thanks


Hi Helmut,

It seems from #920878 that all I need would be to actually build-depend 
on dpkg >= 1.20.0 and export QMAKE or did I misunderstand? BTW what's 
the error message when nonnative lrelease is run? I only saw on the bug 
what happens when it's called without qmake altogether.


Best regards,

Thomas

Bug#937437: pyfeed: Python2 removal in sid/bullseye

[Thomas Preud'homme]

Hi Moritz,

I've filled #962985 and #962986. I don't see why these library packages should 
be kept without reverse dependency.

Best regards,

Thomas.

Bug#962986: RM: xmlelements -- ROM; Last reverse dependency is to be removed

[Thomas Preud'homme]

Package: ftp.debian.org
Severity: normal

With the upcomming removal of pyfeed (#962985), xmlements is going to be without
reverse dependency and should therefore be removed from both unstable
and experimental.

Best regards,

Thomas

Bug#962985: RM: pyfeed -- ROM; No reverse dependency

[Thomas Preud'homme]

Package: ftp.debian.org
Severity: normal

Dear FTP masters,

pyfeed is no longer needed by sat-xmpp-core and is therefore no longer
needed in the Debian archive. I would thus like to remove it from both
unstable and experimental.

Best regards,

Thomas

Bug#894476: #894476: Solved from the Qt side. (rcc: please honour SOURCE_DATE_EPOCH)

[Thomas Preud'homme]

On jeudi 12 juillet 2018 18:28:21 BST Sune Vuorela wrote:
> On Wednesday, July 11, 2018 10:08:23 PM CEST Vagrant Cascadian wrote:
> > Ideally QT_RCC_SOURCE_DATE_OVERRIDE would get set based on
> > SOURCE_DATE_EPOCH, otherwise build tools have an arbitrary growing
> 
> No. As explained, we need to look at each individual package to check if the
> timestamp is actually used for anything. It can be. It probably is.
> 
> I think a better fix might be to specifically mark in the rcc file if the
> dates are important or not. But it requires involvement upstream. (Or maybe
> if the rcc file is autogenerated or not). I don't think it is a problem for
> non- autogenerated rcc files.

Agreed, it's only a problem for files autogenerated at build time. rcc on a 
file that's part of the source tarball is gonna give a reproducible result.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.

Bug#899264: libnewlib-arm-none-eabi: Multilib directory structure incapatible with

[Thomas Preud'homme]

Package: libnewlib-arm-none-eabi
Version: 2.4.0.20160527-4
Severity: important

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Thomas Preud'homme <thomas.preudho...@arm.com>
To: Debian Bug Tracking System <sub...@bugs.debian.org>
Subject: libnewlib-arm-none-eabi: Multilib directory structure incapatible with
 gcc-arm-none-eabi >= 6
Message-ID: 
<152693762196.22500.8895484219841600078.report...@e108577-lin.cambridge.arm.com>
X-Mailer: reportbug 6.6.6ubuntu1
Date: Mon, 21 May 2018 22:20:21 +0100

Package: libnewlib-arm-none-eabi
Version: 2.4.0.20160527-4
Severity: important

Dear Maintainer,

gcc-arm-none-eabi 15:6.3.1+svn253039-1 introduced a new multilib
directory structure which libnewlib must follow for the right C library
variant to be linked. Eg. compiling with:

-mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16

now looks for library under the thumb/v7e-m/fpv4-sp/hard subdirectory
instead of the armv7e-m/fpu subdirectory used by currently packaged
newlib. Users have come accross this problem in Ubuntu (which takes the
packaging straight from Debian), see [1].

[1] https://bugs.launchpad.net/gcc-arm-embedded/+bug/1772332

I believe newlib asks GCC for the scheme to use and thus doing a
binNMU of newlib should be enough.

Best regards,

Thomas Preud'homme


-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (990, 'xenial-updates'), (990, 'xenial-security'), (990, 'xenial')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-121-generic (SMP w/16 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (990, 'xenial-updates'), (990, 'xenial-security'), (990, 'xenial')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-121-generic (SMP w/16 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Bug#894476: RCC: provide option to encode EPOCH timestamp

[Thomas Preud'homme]

On April 3, 2018 10:15:42 PM GMT+01:00, "Lisandro Damián Nicanor Pérez Meyer" 
 wrote:
>El mar., 3 de abr. de 2018 16:42, Sune Vuorela 
>escribió:
>
>> On Tuesday, April 3, 2018 9:24:58 PM CEST Chris Lamb wrote:
>> > I'm not /entirely/ sure what the difference is as I'm not in the
>> > Qt/RCC world too often these days (alas !), but why just not use
>> > SOURCE_DATE_EPOCH *iff* it is exported?
>> >
>> > Normal systems simply do not have this envvar set, so there is
>really
>> > no danger of it leaking elsewhere or causing unintended
>side-effects.
>>
>> We don't know how application users are using this.
>>
>> The following is some theoretical example, that I'm quite sure could
>be
>> used
>> in some real world applications:
>>
>> QFileInfo embeddedFile(":/foo/data.xml"); // fallback downloaded in
>the
>> ancient past
>> QFileInfo systemfile("/usr/share/foo/data.xml");
>>
>> if (systemfile.lastModified() > embeddedFile.lastModified())
>> {
>>data = readFromFile(systemFile);
>> }
>> else
>> {
>>data = readFromFile(embeddedFile);
>> }
>>
>> If S_D_E gets used, rather than the data.xml modified date in the
>source,
>> this
>> will end up using the wrong file if S_D_E is newer than the system
>copy of
>> the
>> file.
>>
>> This is not a unused databit, but a fully available piece of metadata
>for
>> the
>> files.
>
>
>I'm afraid Sune is right here, it might be used that way. Questionable?
>Sure thing, but still valid code.
>
>But after all the same can be said from embedding translations into the
>binary itself.
>
>So yes, we will need help from upstream with this one.
>
>>
>>

Maybe the solution is then not in rcc but in whatever generate the files that 
the qrc that rcc processes refer to. For instance in the case of ultracopier 
lrelease could have a mean if generating .qm files with the same modified 
timestamp as the .ts file it processes. This would guarantee stable output for 
a stable source and this later on rcc would also generate stable output.

Thoughts?

Best regards,

Thomas

Bug#894476: RCC: provide option to encode EPOCH timestamp

[Thomas Preud'homme]

On April 3, 2018 8:20:22 PM GMT+01:00, Sune Vuorela  wrote:
>On Tuesday, April 3, 2018 9:14:23 PM CEST Chris Lamb wrote:
>> Hi Sune!
>> 
>> > I don't think honouring SOURCE_DATE_EPOCH is the right idea under
>normal
>> > circumstances
>> 
>> Can you elaborate on what you mean by "normal circumstances"? :)
>
>"normal circumstances" is rcc on a source file, as opposed to an
>autogenerated 
>file.
>
>> How about e use S_D_E if it is setup/exported, otherwise use the
>mtime
>> of the file as before?
>
>I think that using S_D_E only makes sense if rcc is run on an
>autogenerated 
>file, but I do think that most rcc runs is run on existing source
>files.
>
>
>I don't have a good idea to differentiate those.
>
>/Sune
>-- 
>I didn’t stop pretending when I became an adult, it’s just that when I
>was a 
>kid I was pretending that I fit into the rules and structures of this
>world. 
>And now that I’m an adult, I pretend that those rules and structures
>exist.
>   - zefrank

One small clarification: in my case rcc *is* run on a nongenerated resource 
file. It's some of the files that the resource file list that are generated and 
whose timestamp end up in the cpp file generated by rcc.

In other hand:

foo.qrc mentions bar.qm which is generated from bar.ts.

rcc foo.qrc generates resource_bar.cpp which contains constant data that 
encodes bar.qm timestamp and this create different resource_bar.o at every 
build.

Best regards,

Thomas

Bug#894476: RCC: provide option to encode EPOCH timestamp

[Thomas Preud'homme]

On April 3, 2018 7:25:03 PM GMT+01:00, Sune Vuorela  wrote:
>On Saturday, March 31, 2018 12:05:02 PM CEST Chris Lamb wrote:
>> > While investigating ultracopier's lack of build reproducibility, I
>found
>> > out that rcc encodes the timestamp of the files the QRC file being
>> > compiled references
>
>I don't actually see why this should be a problem. If input changes,
>output 
>changes.
>I do think that using touch(1) on the input should allow different
>output.
>
>It is quite easy to reproduce:
>
>qtbase/tests/auto/gui/image/qimage/foo (dev $%=)$ rcc --format-version
>2 ../
>qimage.qrc -o 1
>qtbase/tests/auto/gui/image/qimage/foo (dev $%=)$ rcc --format-version
>2 ../
>qimage.qrc -o 2
>qtbase/tests/auto/gui/image/qimage/foo (dev $%=)$ rcc --format-version
>2 ../
>qimage.qrc -o 3
>
>Gives same output.
>Even adding in touch ../qimage.qrc keeps the same output.
>
>qtbase/tests/auto/gui/image/qimage/foo (dev $%=)$ rcc --format-version
>2 ../
>qimage.qrc -o 4
>
>touch ../images/image.bmp
>
>qtbase/tests/auto/gui/image/qimage/foo (dev $%=)$ rcc --format-version
>2 ../
>qimage.qrc -o 5
>
>is needed to get different output
>
>14ef6dae8e4992ce907948c1c4af272b  1
>14ef6dae8e4992ce907948c1c4af272b  2
>14ef6dae8e4992ce907948c1c4af272b  3
>14ef6dae8e4992ce907948c1c4af272b  4
>54c6f8c09a347955ae2f36e68bbd2539  5
>
>
>So. What touches the files?
>
>/Sune
>-- 
>I didn’t stop pretending when I became an adult, it’s just that when I
>was a 
>kid I was pretending that I fit into the rules and structures of this
>world. 
>And now that I’m an adult, I pretend that those rules and structures
>exist.
>   - zefrank

Hi Sune,

The problematic files are Qt message files (ie .qm files) generated at build 
time via lrelease from translation files (ie .ts files). Therefore two 
different builds will generate those .qm files at different times which will 
end up with different cpp files generated by rcc. Currently I'm working around 
it by setting the modified time of those .qm files to EPOCH after they are 
generated. I think it would be nice if there was a way for rcc to avoid doing 
that manually. I agree with Chris that honouring SOURCE_DATE_EPOCH in rcc would 
be a nice solution.

Best regards,

Thomas

Bug#894476: RCC: provide option to encode EPOCH timestamp

[Thomas Preud'homme]

Package: qtbase5-dev-tools
Version: 5.9.2+dfsg-12
Severity: wishlist
Tags: upstream
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps toolchain

Hi,

While investigating ultracopier's lack of build reproducibility, I found
out that rcc encodes the timestamp of the files the QRC file being
compiled references (see end of RCCFileInfo::writeDataInfo()). This
becomes a problem for generated files because the output of rcc is then
different in 2 different builds. It would be nice if rcc had an option
to encode a stable timestamp, eg. EPOCH.

Best regards,

Thomas

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (500, 'unstable-debug'), (500, 
'stable-updates'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR:fr (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages qtbase5-dev-tools depends on:
ii  libc62.27-2
ii  libgcc1  1:8-20180321-1
ii  libqt5core5a [qtbase-abi-5-9-2]  5.9.2+dfsg-12
ii  libqt5dbus5  5.9.2+dfsg-12
ii  libstdc++6   8-20180321-1
ii  perl 5.26.1-5
ii  qtchooser64-ga1b6736-5
ii  zlib1g   1:1.2.8.dfsg-5

qtbase5-dev-tools recommends no packages.

qtbase5-dev-tools suggests no packages.

-- no debconf information

Bug#892899: tcc: i386-tcc links against 64bit libraries

[Thomas Preud'homme]

Package: tcc
Version: 0.9.27-6
Severity: normal

tcc -m32 links against 64bit libraries instead of 32bit. This is caused
by the call to dpkg-architecture to determine i386 multiarch triplet in
debian/rules missing the -f option. Without it the host selected is the
one set from the environment, ie. amd64 and thus the triplet ends up
wrong.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (500, 'stable-updates'), (500, 'testing'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR:fr (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tcc depends on:
ii  libc6  2.27-2

Versions of packages tcc recommends:
ii  libc6-dev [libc-dev]  2.27-2

tcc suggests no packages.

-- no debconf information

Bug#832759: tagging 832759

[Thomas Preud'homme]

tags 832759 + fixed-upstream
thanks

This seems fixed on the mob branch (test passses).

Bug#882833:

[Thomas Preud'homme]

Changing ServerPath in ~/.config/akonadi/akonadiserverrc to /usr/sbin/mysqld-
akonadi solved the issue for me. Maybe this should be updated automatically 
somehow?

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.

Bug#882833: (no subject)

[Thomas Preud'homme]

I've also had issues with kontact and my .xsession-errors contained the 
following lines:

org.kde.pim.akonadiserver: database server stopped unexpectedly 

org.kde.pim.akonadiserver: stderr: "mysqld: [ERROR] Could not open required 
defaults file: 
$HOME/.local/share/akonadi/mysql.conf\nmysqld: [ERROR] Fatal error in defaults 
hand


Where $HOME and $USER are substitution of my own to mask my home directory and 
username.

I've noticed some DENIED lines in dmesg that seem related:

audit: type=1400 audit(1515103889.923:49): apparmor="DENIED" operation="open" 
profile="/
usr/sbin/mysqld" name="$HOME/.local/share/akonadi/mysql.conf" pid=2655 
comm="mysqld" requested_mask="r" denied_mask="r" fsuid=1000 

== Successful attempt ==


Trying to launch the mysqld command mentioned in .xsession-errors but using 
mysqld-
akonadi instead (which seems to have special treatment for 
$HOME/.local/share/akonadi) 
and relaunching akonadi and then kontact seems to have worked (am writing this 
from that 
very kontact process).

Best regards,

Thomas


signature.asc
Description: This is a digitally signed message part.

Bug#794110: plasma-workspace: plasmashell segmentation fault (11) every few minutes (and restarted)

[Thomas Preud'homme]

On vendredi 16 juin 2017 19:04:54 BST Sven-Haegar Koch wrote:
> On Fri, 16 Jun 2017, Maximiliano Curia wrote:
> > Control: tag -1 + unreproducible
> > 
> > El 2016-04-14 a las 13:12 -0300, Lisandro Damián Nicanor Pérez Meyer 
escribió:
> > > We expect this might get fixed with Qt 5.6, and we are waiting for 5.6.1
> > > to
> > > be released to push it to unstable.
> > 
> > We are currently using qt 5.7.1 for stretch, and I haven't seen this issue
> > in a while now. Is any one still able to reproduce this issue?
> 
> For me this also did not happen anymore for quite some time, at least
> over a year ago.

Likewise, I did not experience such a crash for quite a while now.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.

Bug#829765: mrd6: please make the build reproducible

[Thomas Preud'homme]

On dimanche 7 août 2016 22:44:30 BST Thomas Preud'homme wrote:
> On dimanche 10 juillet 2016 10:24:46 BST Reiner Herrmann wrote:
> > Hi Thomas,
> 
> Hi Reiner,
> 
> Sorry for the delay.
> 
> > On Sat, Jul 09, 2016 at 10:34:10PM +0100, Thomas Preud'homme wrote:
> > > > While working on the "reproducible builds" effort [1], we have noticed
> > > > that mrd6 could not be built reproducibly.
> > > > It embeds the build date into the binary.
> > > > 
> > > > The attached patch strips this to enable reproducible building.
> > > 
> > > Thanks for the patch! Why remove the build date in src/mrd.cpp since
> > > it's
> > > already made reproducible by using unknown instead of the date? I
> > > suspect
> > > upstream will want to keep the date for normal build and I could make
> > > the
> > > change in the Makefile to be conditional on some variable, allowing
> > > Debian
> > > build to be reproducible while keeping the build unchanged for other
> > > usage.
> > 
> > I also changed the build date to "unknown", or else the date would still
> > be part of the object file, even if it is no longer printed or used.
> > If upstream really insists on keeping the build date in (even though it
> > doesn't really provide any meaningful information), you could use the
> > __DATE__ / __TIME__ macros instead.
> 
> My question was rather opposite. I understand the unknown, I don't
> understand why does it need to be removed from the object file.
> 
> > gcc supports replacing them with reproducible dates (based on the
> > SOURCE_DATE_EPOCH environment variable).
> > If you want, I can provide an updated patch for this.
> 
> No need, I can do it myself. I'll propose a patch removing the date
> altogether and see how it is received. By the way, I've just submitted the
> following pull request upstream:
> 
> https://github.com/hugosantos/mrd6/pull/30

The pull request has been merged upstream. I want to fix the hardening info 
that lintian is throwing at me. Feel free to ping me if I haven't uploaded 
anything within one week and I'll upload what I got.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.

Bug#776283: sat-xmpp-wix: assertion fails when not configuring in the right order

[Thomas Preud'homme]

On lundi 8 août 2016 10:27:55 BST Dominik George wrote:
> Hi,
> 
> > First of all, my apologize for this extreme delay. Haven't been very
> > present in Debian for a while. The experience you describe rings a bell,
> > I think I went through it myself and I've probably reported it to
> > upstream in private. Sadly there is no point raising a ticket now because
> > Wix has been discontinued.
> 
> In that case, please file a RoM to remove salutatoi-0.5.1 from testing.

It's been a long time I haven't done it but I was under the impression that 
this was done automatically. Devref seems to agree with me:

"Furthermore, if a package has been removed from unstable, and no package in 
testing depends on it any more, then it will automatically be removed."

I'm guessing once the package will have migrated to testing that situation 
will be met. If I remember well I was even frowned upon once because I 
requested a RoM when this was not necessary and I think it was a situation 
similar to that one.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.

Bug#829765: mrd6: please make the build reproducible

[Thomas Preud'homme]

On dimanche 10 juillet 2016 10:24:46 BST Reiner Herrmann wrote:
> Hi Thomas,

Hi Reiner,

Sorry for the delay.

> 
> On Sat, Jul 09, 2016 at 10:34:10PM +0100, Thomas Preud'homme wrote:
> > > While working on the "reproducible builds" effort [1], we have noticed
> > > that mrd6 could not be built reproducibly.
> > > It embeds the build date into the binary.
> > > 
> > > The attached patch strips this to enable reproducible building.
> > 
> > Thanks for the patch! Why remove the build date in src/mrd.cpp since it's
> > already made reproducible by using unknown instead of the date? I suspect
> > upstream will want to keep the date for normal build and I could make the
> > change in the Makefile to be conditional on some variable, allowing Debian
> > build to be reproducible while keeping the build unchanged for other
> > usage.
> 
> I also changed the build date to "unknown", or else the date would still
> be part of the object file, even if it is no longer printed or used.
> If upstream really insists on keeping the build date in (even though it
> doesn't really provide any meaningful information), you could use the
> __DATE__ / __TIME__ macros instead.

My question was rather opposite. I understand the unknown, I don't understand 
why does it need to be removed from the object file.

> gcc supports replacing them with reproducible dates (based on the
> SOURCE_DATE_EPOCH environment variable).
> If you want, I can provide an updated patch for this.

No need, I can do it myself. I'll propose a patch removing the date altogether 
and see how it is received. By the way, I've just submitted the following pull 
request upstream:

https://github.com/hugosantos/mrd6/pull/30

Cheers,

Thomas

signature.asc
Description: This is a digitally signed message part.

Bug#829765: mrd6: please make the build reproducible

[Thomas Preud'homme]

Le Tuesday 05 July 2016, 22:20:33 Reiner Herrmann a écrit :
> Source: mrd6
> Version: 0.9.6-12
> Severity: wishlist
> Tags: patch upstream
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: timestamps
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
> 
> Hi!

Hi Reiner,

> 
> While working on the "reproducible builds" effort [1], we have noticed
> that mrd6 could not be built reproducibly.
> It embeds the build date into the binary.
> 
> The attached patch strips this to enable reproducible building.

Thanks for the patch! Why remove the build date in src/mrd.cpp since it's 
already made reproducible by using unknown instead of the date? I suspect 
upstream will want to keep the date for normal build and I could make the 
change in the Makefile to be conditional on some variable, allowing Debian 
build to be reproducible while keeping the build unchanged for other usage.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.

Bug#794110: More info needed

[Thomas Preud'homme]

Le mercredi 16 mars 2016, 10:16:18 Lisandro Damián Nicanor Pérez Meyer a écrit 
:
> tag 794110 moreinfo
> thanks
> 
> Hi everyone! With my Qt maintainer hat on, I would like you to give me some
> info.
> 
> First: We have only one backtrace coming from the original submitter. Can
> the rest of you check if when a crash happens the current thread's (the
> crashing one) backtrace says something like:

Hi Lisandro,

I hope you are doing well.

Sorry for the late answer, I was in the middle of a relocation and didn't 
touch my computer much. I haven't had any crash since I have so the bug seems 
to be solved on my side. I'll update the bug report if I ever get a new crash 
in the following (14) days but I don't expect to.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.

Bug#816709: Processed: tagging 816709

[Thomas Preud'homme]

I gave a quick look at the source to find the bug and it seems clear that the 
code is not organized to catch errors. It starts parsing by looking for a word 
(not specially a BEGIN) and then accept anything that could follow a word (be 
it comma, dot, colon or something else).

In other words, there is a strong assumption in the parser,that the file is a 
valid vcard. I agree that this is a bad assumption but it is one requiring a 
significant effort to fix. The code is clean so it shouldn't be difficult, just 
a bit long.

I'll forward the bug upstream once I get back to my desktop computer, we'll see 
if he feels like tackling this issue.

Best regards,

Tom

Bug#805175: libkonq-common: konqpopupmenuplugin not working on KDE SC 5

[Thomas Preud'homme]

Package: libkonq-common
Version: 4:15.08.2-1
Severity: normal
Tags: upstream

Hi,

There is no action entries (such as to compress/decompress) in the right
click menu on KDE SC 5 due to konqpopupmenuplugin.desktop missing in
/usr/share/kservicetypes5. I know this was fixed upstream [1] but not
part of any release yet. This can be worked around though by providing a
symbolic link from
/usr/share/kde4/servicetypes/konqpopupmenuplugin.desktop to
/usr/share/kservicetypes5/

Since the first file is provided by this package, maybe the symlink
could be provided here too until the upstream bug fix flows to a Debian
package.

[1] https://bugs.kde.org/show_bug.cgi?id=350769

Best regards.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (500, 'stable-updates'), (500, 'testing'), 
(500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libkonq-common depends on:
ii  libc6   2.19-22
ii  libkdecore5 4:4.14.13-1
ii  libkio5 4:4.14.13-1
ii  libkonq5-templates  4:15.08.2-1
ii  libphonon4  4:4.8.3-2
ii  libqt4-dbus 4:4.8.7+dfsg-3
ii  libqtcore4  4:4.8.7+dfsg-3
ii  libqtgui4   4:4.8.7+dfsg-3
ii  libstdc++6  5.2.1-23
ii  phonon  4:4.8.3-2

libkonq-common recommends no packages.

libkonq-common suggests no packages.

-- no debconf information

Bug#770657: tcc: fails with struct defined in function

[Thomas Preud'homme]

Control: forwarded -1 
http://lists.nongnu.org/archive/html/tinycc-devel/2014-08/msg00050.html
Control: tags -1 + upstream

A patch has been floating on the mailing list but was not of good enough 
quality to be included. I shall be able to commit soon again to this project 
and will try to move this forward.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.

Bug#771196: Acknowledgement ((pre-approval) unblock: gdb-arm-none-eabi/7.7.1+dfsg-5+7)

[Thomas Preud'homme]

Ping?


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

Bug#771195: Acknowledgement ((pre-approval) unblock: gcc-arm-none-eabi/4.8.3-13+12)

[Thomas Preud'homme]

Ping?


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

Bug#771194: Acknowledgement ((pre-approval) unblock: binutils-arm-none-eabi/2.24.90.20141124-1+6)

[Thomas Preud'homme]

Ping?


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

Bug#771194: (pre-approval) unblock: binutils-arm-none-eabi/2.24.90.20141124-1+6

[Thomas Preud'homme]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hi there,

A new update release of the ARM embedded toolchain was released few days
before the freeze but we missed the deadline due to various reasons
(internal process, holidays, etc.). The update consists solely of
important bugfixes and support for the recently announced Cortex-M7
ARM processors.

I understand that this latter change is against the freeze policy which
is why we haven't uploaded the package to unstable yet but please
consider that it's a quite small change and isolated. It doesn't affect
the current support of other processors and in the worst case it would
only offer a broken support for this new processor. In addition, this is
considered as a minor update by ARM and is rigorously tested on a wide
range of devices.

I would understand and respect any decision you would make but I would
just ask you to consider the toolchain as a whole when making the
decision, i.e. approve or reject the unblock for all 3 [1] packages that
needs updating.

[1] binutils-arm-none-eabi, gcc-arm-none-eabi, gdb-arm-none-eabi

debdiff for the package attached. Also attached is the ARM embedded
toolchain patch from debian/patches for easier review.

unblock binutils-arm-none-eabi/2.24.90.20141124-1+6

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.13.0-38-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dashdiff --git a/debian/changelog b/debian/changelog
index 7f47731..55db5d4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+binutils-arm-none-eabi (6) UNRELEASED; urgency=medium
+
+  * New upstream release: 4.8-2014-q3-update.
+  * Add myself to Uploaders.
+
+ -- Thomas Preud'homme thomas.preudho...@arm.com  Thu, 21 Aug 2014 09:20:37 +
+
 binutils-arm-none-eabi (5) unstable; urgency=medium
 
   * New upstream release (2.24.51)
diff --git a/debian/control b/debian/control
index 1cb4a18..0f2d31f 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,8 @@ Source: binutils-arm-none-eabi
 Section: devel
 Priority: extra
 Maintainer: Agustin Henze t...@debian.org
-Uploaders: Keith Packard kei...@keithp.com
+Uploaders: Keith Packard kei...@keithp.com,
+   Thomas Preud'homme thomas.preudho...@arm.com
 Build-Depends:
  binutils-source,
  debhelper (= 8.0.0),
diff --git a/debian/patches/0001-Add-GNU-ARM-embedded-toolchain-patches.patch b/debian/patches/0001-Add-GNU-ARM-embedded-toolchain-patches.patch
new file mode 100644
index 000..fb7ad38
--- /dev/null
+++ b/debian/patches/0001-Add-GNU-ARM-embedded-toolchain-patches.patch
@@ -0,0 +1,533 @@
+diff --git a/bfd/ChangeLog.arm b/bfd/ChangeLog.arm
+new file mode 100644
+index 000..d54d76d
+--- /dev/null
 b/bfd/ChangeLog.arm
+@@ -0,0 +1,74 @@
++2014-01-02  Joey Ye  joey...@arm.com
++
++	Backport from mainline
++	2013-03-30  Alan Modra  amo...@gmail.com
++
++	PR ld/15323
++	* elf-m10300.c (mn10300_elf_check_relocs): Set non_ir_ref for
++	global symbols referenced by relocs.
++	* elf32-arm.c (elf32_arm_check_relocs): Likewise.
++	* elf32-bfin.c (bfin_check_relocs): Likewise.
++	* elf32-cr16.c (cr16_elf_check_relocs): Likewise.
++	* elf32-cris.c (cris_elf_check_relocs): Likewise.
++	* elf32-d10v.c (elf32_d10v_check_relocs): Likewise.
++	* elf32-dlx.c (elf32_dlx_check_relocs): Likewise.
++	* elf32-fr30.c (fr30_elf_check_relocs): Likewise.
++	* elf32-frv.c (elf32_frv_check_relocs): Likewise.
++	* elf32-hppa.c (elf32_hppa_check_relocs): Likewise.
++	* elf32-i370.c (i370_elf_check_relocs): Likewise.
++	* elf32-iq2000.c (iq2000_elf_check_relocs): Likewise.
++	* elf32-lm32.c (lm32_elf_check_relocs): Likewise.
++	* elf32-m32c.c (m32c_elf_check_relocs): Likewise.
++	* elf32-m32r.c (m32r_elf_check_relocs): Likewise.
++	* elf32-m68hc1x.c (elf32_m68hc11_check_relocs): Likewise.
++	* elf32-m68k.c (elf_m68k_check_relocs): Likewise.
++	* elf32-mcore.c (mcore_elf_check_relocs): Likewise.
++	* elf32-microblaze.c (microblaze_elf_check_relocs): Likewise.
++	* elf32-moxie.c (moxie_elf_check_relocs): Likewise.
++	* elf32-msp430.c (elf32_msp430_check_relocs): Likewise.
++	* elf32-mt.c (mt_elf_check_relocs): Likewise.
++	* elf32-openrisc.c (openrisc_elf_check_relocs): Likewise.
++	* elf32-ppc.c (ppc_elf_check_relocs): Likewise.
++	* elf32-rl78.c (rl78_elf_check_relocs): Likewise.
++	* elf32-s390.c (elf_s390_check_relocs): Likewise.
++	* elf32-score.c (s3_bfd_score_elf_check_relocs): Likewise.
++	* elf32-score7.c (s7_bfd_score_elf_check_relocs): Likewise.
++	* elf32-sh.c (sh_elf_check_relocs): Likewise.
++	* elf32-tic6x.c (elf32_tic6x_check_relocs): Likewise.
++	* elf32-tilepro.c (tilepro_elf_check_relocs): Likewise.
++	* elf32-v850.c (v850_elf_check_relocs): Likewise.
++	* elf32-vax.c (elf_vax_check_relocs): Likewise.
++	* elf32

Bug#771195: (pre-approval) unblock: gcc-arm-none-eabi/4.8.3-13+12

[Thomas Preud'homme]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hi there,

A new update release of the ARM embedded toolchain was released few days
before the freeze but we missed the deadline due to various reasons
(internal process, holidays, etc.). The update consists solely of
important bugfixes and support for the recently announced Cortex-M7
ARM processors.

I understand that this latter change is against the freeze policy which
is why we haven't uploaded the package to unstable yet but please
consider that it's a quite small change and isolated. It doesn't affect
the current support of other processors and in the worst case it would
only offer a broken support for this new processor. In addition, this is
considered as a minor update by ARM and is rigorously tested on a wide
range of devices.

I would understand and respect any decision you would make but I would
just ask you to consider the toolchain as a whole when making the
decision, i.e. approve or reject the unblock for all 3 [1] packages that
needs updating.

[1] binutils-arm-none-eabi, gcc-arm-none-eabi, gdb-arm-none-eabi

Since a typo in the name of the patch in debian/patches was fixed, the
true debdiff is large. I thus attached a debdiff without the file
renaming part.

unblock gcc-arm-none-eabi/4.8.3-13+12

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.13.0-38-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dashdiff --git a/debian/changelog b/debian/changelog
index 50c3bd1..a261842 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+gcc-arm-none-eabi (12) UNRELEASED; urgency=medium
+
+  * New upstream release: 4.8-2014-q3-update.
+  * Modify patching so that patches can be version independent.
+
+ -- Thomas Preud'homme thomas.preudho...@arm.com  Mon, 20 Oct 2014 10:01:25 +
+
 gcc-arm-none-eabi (11) unstable; urgency=medium
 
   * Track GCC embedded branch.
diff --git a/debian/patches/0001-Ad-GNU-ARM-embedded-toolchain-patches.patch b/debian/patches/0001-Ad-GNU-ARM-embedded-toolchain-patches.patch
index 19be0f2..f1fed98 100644
--- a/debian/patches/0001-Ad-GNU-ARM-embedded-toolchain-patches.patch
+++ b/debian/patches/0001-Ad-GNU-ARM-embedded-toolchain-patches.patch
@@ -1,9 +1,25 @@
 diff --git a/gcc/ChangeLog.arm b/gcc/ChangeLog.arm
 new file mode 100644
-index 000..8f04bc3
+index 000..0ef5a74
 --- /dev/null
-+++ b/gcc-4.8.3/gcc/ChangeLog.arm
-@@ -0,0 +1,311 @@
 b/gcc/ChangeLog.arm
+@@ -0,0 +1,327 @@
++2014-09-30  Terry Guo  terry@arm.com
++
++	Backport mainline r215711
++	2014-09-30  Terry Guo  terry@arm.com
++
++	* config/arm/arm-cores.def (cortex-m7): New core name.
++	* config/arm/arm-fpus.def (fpv5-sp-d16): New fpu name.
++	(fpv5-d16): Ditto.
++	* config/arm/arm-tables.opt: Regenerated.
++	* config/arm/arm-tune.md: Regenerated.
++	* config/arm/arm.h (TARGET_VFP5): New macro.
++	* config/arm/bpabi.h (BE8_LINK_SPEC): Include cortex-m7.
++	* config/arm/vfp.md (vrint_patternSDF:mode2,
++	smaxmode3, sminmode3): Enabled for FPU FPv5.
++	* doc/invoke.texi: Document new cpu and fpu names.
++
 +2014-02-28  Joey Ye  joey...@arm.com
 +
 +	Backport mainline r208217
@@ -315,16 +331,10 @@ index 000..8f04bc3
 +	* configure: Regenerated.
 +	* config/arm/t-mlibs: New files to define multilibs.
 +	* config.gcc: Use above multilib fragment.
-diff --git a/gcc/DEV-PHASE b/gcc/DEV-PHASE
-index 373fbc6..d702569 100644
 /dev/null
-+++ b/gcc-4.8.3/gcc/DEV-PHASE
-@@ -0,0 +1,1 @@
-+release
 diff --git a/gcc/Makefile.in b/gcc/Makefile.in
 index 2a4475b..56b7baa 100644
 a/gcc-4.8.3/gcc/Makefile.in
-+++ b/gcc-4.8.3/gcc/Makefile.in
+--- a/gcc/Makefile.in
 b/gcc/Makefile.in
 @@ -526,6 +526,7 @@ lang_opt_files=@lang_opt_files@ $(srcdir)/c-family/c.opt $(srcdir)/common.opt
  lang_specs_files=@lang_specs_files@
  lang_tree_files=@lang_tree_files@
@@ -337,7 +347,7 @@ diff --git a/gcc/c-family/ChangeLog.arm b/gcc/c-family/ChangeLog.arm
 new file mode 100644
 index 000..056bf52
 --- /dev/null
-+++ b/gcc-4.8.3/gcc/c-family/ChangeLog.arm
 b/gcc/c-family/ChangeLog.arm
 @@ -0,0 +1,8 @@
 +2014-07-29  Terry Guo  terry@arm.com
 +
@@ -349,8 +359,8 @@ index 000..056bf52
 +	* c.opt (fshort-wchar): Likewise.
 diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
 index 4da80b0..8dfa739 100644
 a/gcc-4.8.3/gcc/c-family/c.opt
-+++ b/gcc-4.8.3/gcc/c-family/c.opt
+--- a/gcc/c-family/c.opt
 b/gcc/c-family/c.opt
 @@ -1121,11 +1121,11 @@ C ObjC C++ ObjC++ Optimization Var(flag_short_double)
  Use the same size for double as for float
  
@@ -367,8 +377,8 @@ index 4da80b0..8dfa739 100644
  fsigned-bitfields
 diff --git a/gcc/calls.c b/gcc/calls.c
 index bf0ba30..a066e52 100644
 a/gcc-4.8.3/gcc/calls.c
-+++ b/gcc-4.8.3/gcc/calls.c
+--- a/gcc/calls.c

Bug#771196: (pre-approval) unblock: gdb-arm-none-eabi/7.7.1+dfsg-5+7

[Thomas Preud'homme]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hi there,

A new update release of the ARM embedded toolchain was released few days
before the freeze but we missed the deadline due to various reasons
(internal process, holidays, etc.). The update consists solely of
important bugfixes and support for the recently announced Cortex-M7
ARM processors.

I understand that this latter change is against the freeze policy which
is why we haven't uploaded the package to unstable yet but please
consider that it's a quite small change and isolated. It doesn't affect
the current support of other processors and in the worst case it would
only offer a broken support for this new processor. In addition, this is
considered as a minor update by ARM and is rigorously tested on a wide
range of devices.

Note that this package only contains bug fixes backported for this
version of gdb.

I would understand and respect any decision you would make but I would
just ask you to consider the toolchain as a whole when making the
decision, i.e. approve or reject the unblock for all 3 [1] packages that
needs updating.

[1] binutils-arm-none-eabi, gcc-arm-none-eabi, gdb-arm-none-eabi

debdiff for the package attached. Also attached is the ARM embedded
toolchain patch from debian/patches for easier review.

unblock gdb-arm-none-eabi/7.7.1+dfsg-5+7

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.13.0-38-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dashdiff --git a/debian/changelog b/debian/changelog
index 0aab5b3..f78f7d6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+gdb-arm-none-eabi (7) UNRELEASED; urgency=medium
+
+  * New upstream release: 4.8-2014-q3-update.
+  * Fix my email.
+
+ -- Thomas Preud'homme thomas.preudho...@arm.com  Mon, 20 Oct 2014 15:38:58 +
+
 gdb-arm-none-eabi (6) unstable; urgency=medium
 
   * Workaround for upstream manpages stripped on the last gdb-source version
diff --git a/debian/control b/debian/control
index 0f2370b..8fa6261 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: devel
 Priority: extra
 Maintainer: Agustin Henze t...@debian.org
 Uploaders: Keith Packard kei...@keithp.com,
-   Thomas Preud'homme thomas.preud-ho...@arm.com
+   Thomas Preud'homme thomas.preudho...@arm.com
 Build-Depends:
  debhelper (= 8.0.0),
  gdb-source,
diff --git a/debian/patches/0001-Add-GNU-ARM-embedded-toolchain-patches.patch b/debian/patches/0001-Add-GNU-ARM-embedded-toolchain-patches.patch
new file mode 100644
index 000..cce7b83
--- /dev/null
+++ b/debian/patches/0001-Add-GNU-ARM-embedded-toolchain-patches.patch
@@ -0,0 +1,383 @@
+diff --git a/gdb/ChangeLog.arm b/gdb/ChangeLog.arm
+new file mode 100644
+index 000..7f60687
+--- /dev/null
 b/gdb/ChangeLog.arm
+@@ -0,0 +1,18 @@
++Backport from 9a9a76082919371f4ceb571f6c9892325b80a2e0
++
++2014-07-09  Andrew Burgess  andrew.burg...@embecosm.com
++
++	* ada-varobj.c (ada_varobj_ops): Fill in is_path_expr_parent
++	field.
++	* c-varobj.c (c_is_path_expr_parent): New function, moved core
++	from varobj.c, with additional checks.
++	(c_varobj_ops): Fill in is_path_expr_parent field.
++	(cplus_varobj_ops): Fill in is_path_expr_parent field.
++	* jv-varobj.c (java_varobj_ops): Fill in is_path_expr_parent
++	field.
++	* varobj.c (is_path_expr_parent): Call is_path_expr_parent varobj
++	ops method.
++	(varobj_default_is_path_expr_parent): New function.
++	* varobj.h (lang_varobj_ops): Add is_path_expr_parent field.
++	(varobj_default_is_path_expr_parent): Declare new function.
++
+diff --git a/gdb/ada-varobj.c b/gdb/ada-varobj.c
+index 3da6018..b49eaf0 100644
+--- a/gdb/ada-varobj.c
 b/gdb/ada-varobj.c
+@@ -1032,5 +1032,6 @@ const struct lang_varobj_ops ada_varobj_ops =
+   ada_type_of_child,
+   ada_value_of_variable,
+   ada_value_is_changeable_p,
+-  ada_value_has_mutated
++  ada_value_has_mutated,
++  varobj_default_is_path_expr_parent
+ };
+diff --git a/gdb/c-varobj.c b/gdb/c-varobj.c
+index 9c2860d..f7bc52b 100644
+--- a/gdb/c-varobj.c
 b/gdb/c-varobj.c
+@@ -126,6 +126,56 @@ adjust_value_for_child_access (struct value **value,
+ }
+ }
+ 
++/* Is VAR a path expression parent, i.e., can it be used to construct
++   a valid path expression?  */
++
++static int
++c_is_path_expr_parent (struct varobj *var)
++{
++  struct type *type;
++
++  /* Fake children are not path_expr parents.  */
++  if (CPLUS_FAKE_CHILD (var))
++return 0;
++
++  type = varobj_get_gdb_type (var);
++
++  /* Anonymous unions and structs are also not path_expr parents.  */
++  if ((TYPE_CODE (type) == TYPE_CODE_STRUCT
++   || TYPE_CODE (type) == TYPE_CODE_UNION)
++   TYPE_NAME (type) == NULL
++   TYPE_TAG_NAME (type) == NULL

Bug#740190: udisks2: mounts floppy always for root:root (not writable for normal user)

[Thomas Preud'homme]

Le samedi 10 mai 2014, 10:59:10 Torquil Macdonald Sørensen a écrit :
 Package: udisks2
 Followup-For: Bug #740190
 
 Since you got no response on this, I will offer a suggestion. The same
 happened for me with USB memory. The device name in my case was /dev/sdb1.
 I noticed that I had a line in /etc/fstab containing /dev/sdb1. I commented
 it out. After that, udisks would mount my USB memory with proper file
 ownership, not root.root. Instead of mounting it at /media/NAME, it now
 mounts it below /media/tmac/NAME. It is now correctly mounted when using
 Thunar.

You Sir have made my day. I had the same problem with USB stick and it was 
indeed the source of the problem. I'm pretty sure I didn't add these lines in 
fstab but my system was recently installed with debian-installer from testing. 
Might this be the source of these lines?

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.

Bug#754810: RM: dspam -- ROM; No longer maintained upstream

[Thomas Preud'homme]

Package: ftp.debian.org
Severity: normal

Dear FTP team,

I am hereby requesting for dspam to be removed from unstable (and
therefore testing) since the sole upstream developer has publicly
announced [1] it is leaving the project. Given the absence of any
commit since several months, it seems quite clear that nobody will take
over maintainance.

[1] http://sourceforge.net/p/dspam/mailman/message/32585111/

As annoying as it is for all its users (and I'm one of them) it's best
to make it clear that dspam is no longer supported. For the past 2 years
I've been stacking patches to fix security issues and serious bugs and I
can't imagine another release cycle like this, with no hope of any patch
being merged.

Best regards,

Thomas Preud'homme

signature.asc
Description: This is a digitally signed message part.

Bug#675024: tcc: errors Symbol `mpfr_xxx' causes overflow in R_X86_64_PC32 relocation

[Thomas Preud'homme]

Control: tags -1 + fixed-upstream

Two commits were done upstream to fix this bug. The author (Michael Matz) would 
appreciate some testing to see if it works correctly. I don't think you need 
instructions on how to try the latest development version but in case you need 
let me know and I'll provide you instructions.

Best regards,

Thomas


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

Bug#537622: tcc FTB mksh with bounds checking

[Thomas Preud'homme]

Le dimanche 30 mars 2014, 18:19:32 Thorsten Glaser a écrit :
 Oh, nice. I’ve found logs of bugs in, for example, GCC with it too,
 but They never bothered to fix them, they just deprecated the code.

We'll try to avoid that but it seems quite clear that that will imply doing 
less checks to cover currently problematic cases.

 Yes, surprisingly. Signals, for example on Linux/amd64, go from 1 to 64,
 with valid kill() arguments and siglist entries ranging from 0 to 64,
 where 0 is just never used. They shift the 1‥64 into 0‥63 for the signal
 mask in order to not waste any.

Ok, so a bug in tcc then.

 
 If they are NULL it doesn’t matter because mksh does Signal %d then.
 It basically doesn’t dereference it. But it’s important that NSIG has
 them, so a user can send those signals (they are real-time signals,
 but still valid).

Certainly, I was not implying there was a bug in mksh in the null case, just 
that I could see it confusing bound checking code in some way.

 
 failed on the use of environ because the bound checking code cannot know
 the size of the valid area for environ and thus thinks an unsafe access is
 being
 Hm. Well, “environ” is just a pointer to some (structured but not
 easily bound) memory are. There *could* be code to scan for the
 end, but that’d not perform.

That's what I added in tcc for argv and the arge (third parameter of main). 
Look for the end of the array and register a bound region. But it doesn't work 
in the general case, tcc cannot know when considering an externally defined 
symbol if it's an array ended with a NULL value. We need a more generic 
solution.

 
 OK. If there is anything I should change in mksh (especially if it
 could be a bug rather than a compiler workaround), feel free to say
 so. (On the other hand, other compiler authors _did_ recommend to
 just disable the bounds checking flag because their compilers’ code
 for that didn’t manage to work, either.)

We'll see but I'm afraid it'll have to wait for the release after the one 
coming soon.

 
 Thanks, much welcome! Are you also upstream?

Yep. When I took over the maintainance of tcc I soon discovered that all of 
the bugs that were reported were upstream bug and that nobody would work on 
them if I didn't. So I started tackling just the bugs reported within Debian 
and eventually I became upstream. :)

Cheers,

Thomas


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

Bug#537622: tcc FTB mksh with bounds checking

[Thomas Preud'homme]

Le mardi 3 janvier 2012 17:03:29, vous avez écrit :
 
 I’m omitting -b when building mksh with tcc now, and it works
 and passes its testsuite fully, on i386. Just FYI.

I took a look at this bug recently. Thanks to this, two bugs have been fixed in 
tcc. Sadly it was regression both in tcc and due to change in the environment. 
I managed to go a bit further by changing the condition on NSIG from = NSIG 
to  NSIG in inittraps in histrap.c Are you sure it should be =NSIG?

I could go even further by changing NSIG to 32 when I noticed that the entries 
from 32 to 64 are null (I thought it could confuse tcc in some way). It then 
failed on the use of environ because the bound checking code cannot know the 
size of the valid area for environ and thus thinks an unsafe access is being 
done. The problem in histtrap seems to be the same. When computing the address 
of histtraps[i] at some point the bound checking code returns -2 (access to 
unsafe zone) which once multiplied by i * sizeof(void *) goes in the end of 
address space and causes a crash. I'll think how to solve this.

Anyway, I just wanted to tell you that we are trying to fix this and we didn't 
forget that bug.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.

Bug#739956: Fails with linux-vdso.so.1 not found

[Thomas Preud'homme]

Control: tags -1 + fixed-upstream

Le lundi 24 février 2014 12:14:45, vous avez écrit :
 Package: pstack
 Version: 1.3.1-1
 Severity: important
 
 pstack 11019
 
 11019: test.debug
 'linux-vdso.so.1': opening object file: No such file or directory
 Could not open object file.
 
 Trying to locate linux-vdso is never going to work.

Indeed. I'm hardcoding the value for now as having a regex is less easy. 
Anyway, although I started a process to make pstack more platform independant, 
the work is currently stalled and thus pstack only has to deal with x86 (and 
amd64 is a bit broken for now).

You can pull from git clone git://git.celest.fr/pstack.git

I'd like to at least finish fixing amd64 before doing a new release but if it 
takes time (let's say, more than 3 months or so) I'll release with just this 
fix as a bugfix release.

If the fix works for you, I'll upload a patched version in Debian.

Cheers,

Thomas


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

Bug#738222: dspam-webfrontend: Please replace ttf-freefont by fonts-freefont-ttf in package dependencies

[Thomas Preud'homme]

Le samedi 8 février 2014 18:27:35, vous avez écrit :
 Package: dspam-webfrontend
 Version: N/A
 Severity: normal
 
 Hello,
 
 The ttf-freefont binary package has been renamed to fonts-freefont-ttf
 as per the Font Packaging Team internal naming policy.
 
 The package provides a transitional package but we would like to drop
 it and therefore we need packages that depend on ttf-freefont to
 switch their dependency to fonts-freefont-ttf.

Right and as well the package should depend on fonts-dejavu-core instead of 
ttf-dejavu-core. Considered it done, I'll just wait a bit in case I could cram 
some more change in the same upload.

Cheers.


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

Bug#737529: gcc-4.8: __builtin_frame_address not working on ARM

[Thomas Preud'homme]

Package: gcc-4.8
Version: 4.8.2-14
Severity: normal

__builtin_frame_address does not work as documented on ARM. For a value
greater or equal to 1 it returns a non null value but the returned
pointer does not seem to match a frame. See the attached testcase. With
tcc and clang it displays __builtin_frame_address while with gcc it
first displays bfa1: %s and then segfaults if the #if is removed.

Best regards,

Thomas Preud'homme

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: armhf (armv7l)

Kernel: Linux 2.6.38-ac2-ac100 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gcc-4.8 depends on:
ii  binutils2.24-3
ii  cpp-4.8 4.8.2-14
ii  gcc-4.8-base4.8.2-14
ii  libc6   2.17-97
ii  libcloog-isl4   0.18.1-3
ii  libgcc-4.8-dev  4.8.2-14
ii  libgmp102:5.1.3+dfsg-1
ii  libisl100.12.1-2
ii  libmpc3 1.0.1-1
ii  libmpfr43.1.2-1
ii  zlib1g  1:1.2.8.dfsg-1

Versions of packages gcc-4.8 recommends:
ii  libc6-dev  2.17-97

Versions of packages gcc-4.8 suggests:
ii  binutils [binutils-gold]  2.24-3
pn  gcc-4.8-doc   none
pn  gcc-4.8-locales   none
pn  libasan0-dbg  none
pn  libatomic1-dbgnone
pn  libbacktrace1-dbg none
pn  libgcc1-dbg   none
pn  libgomp1-dbg  none
pn  libitm1-dbg   none
pn  libquadmath-dbg   none
pn  libtsan0-dbg  none

-- no debconf information#include stdio.h
#include stddef.h

void bfa3(ptrdiff_t str_offset)
{
printf(bfa3: %s\n, (char *)__builtin_frame_address(3) + str_offset);
}
void bfa2(ptrdiff_t str_offset)
{
printf(bfa2: %s\n, (char *)__builtin_frame_address(2) + str_offset);
bfa3(str_offset);
}
void bfa1(ptrdiff_t str_offset)
{
printf(bfa1: %s\n, (char *)__builtin_frame_address(1) + str_offset);
#if defined(__arm__)  !defined(__GNUC__)
bfa2(str_offset);
#endif
}

void builtin_frame_address_test(void)
{
char str[] = __builtin_frame_address;
char *fp0 = __builtin_frame_address(0);

printf(str: %s\n, str);
bfa1(str-fp0);
}

int main(void)
{
builtin_frame_address_test();
return 0;
}

Bug#735813: salutatoi: FTBFS: dpkg-source: error: unrepresentable changes to source

[Thomas Preud'homme]

Control: tags 735813 + pending

I pushed a fix in the git repository. Unfortunately I won't have access to my 
gpg key for a few days so I can't upload the result. I notified my co-
maintainer and I expect him to do an upload very soon but in the worst case 
I'll do it myself in about a week.

Best regards,

Thomas


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

Bug#735793: urwid-satext: FTBFS: dpkg-source: error: unrepresentable changes to source

[Thomas Preud'homme]

Control: tags 735793 + pending

I pushed a fix in the git repository. Unfortunately I won't have access to my 
gpg key for a few days so I can't upload the result. I notified my co-
maintainer and I expect him to do an upload very soon but in the worst case 
I'll do it myself in about a week.

Best regards,

Thomas


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

Bug#611190: closed by Osamu Aoki os...@debian.org (Bug#611190: fixed in ibus-qt 1.3.2-1)

[Thomas Preud'homme]

Hi Osamu,

I'm sorry I haven't said it but I managed to make it work without qt4-config 
eventually. The possible was because of some unexported variables due to 
Xsession being sourced as a zsh script by kdm. The bug is still open but it's 
not related to ibus and qt-config is not needed as recommends. You should 
remove the recommends or downgrade it to suggests.

Best regards,

Thomas


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

Bug#698351: tcc: FE_INVALID flag not set on comparison with NAN (unordered)

[Thomas Preud'homme]

Le mardi 24 décembre 2013, 16:20:23 Thomas Preud'homme a écrit :
 

Sorry, I don't know what happened when I sent that mail. So I did a patch to 
solve this problem but I can't test it due to not having an x86 machine. Can 
you try applying the attached patch to the upstream development branch and 
tell me if it works? Anyway, thanks for your bug report. There was all the 
information for a quick fix as you gave the root cause of the problem.

By the way, was the bug fixed in gcc since?

Best regards,

Thomasdiff --git a/i386-gen.c b/i386-gen.c
index b26b844..5f0c0f4 100644
--- a/i386-gen.c
+++ b/i386-gen.c
@@ -895,7 +895,7 @@ ST_FUNC void gen_opf(int op)
 swapped = 0;
 if (swapped)
 o(0xc9d9); /* fxch %st(1) */
-o(0xe9da); /* fucompp */
+o(0xd9de); /* fcompp */
 o(0xe0df); /* fnstsw %ax */
 if (op == TOK_EQ) {
 o(0x45e480); /* and $0x45, %ah */
diff --git a/x86_64-gen.c b/x86_64-gen.c
index 0962056..dc2ced1 100644
--- a/x86_64-gen.c
+++ b/x86_64-gen.c
@@ -1792,7 +1792,7 @@ void gen_opf(int op)
 swapped = 0;
 if (swapped)
 o(0xc9d9); /* fxch %st(1) */
-o(0xe9da); /* fucompp */
+o(0xd9de); /* fcompp */
 o(0xe0df); /* fnstsw %ax */
 if (op == TOK_EQ) {
 o(0x45e480); /* and $0x45, %ah */
@@ -1876,7 +1876,7 @@ void gen_opf(int op)
 
 if ((vtop-type.t  VT_BTYPE) == VT_DOUBLE)
 o(0x66);
-o(0x2e0f); /* ucomisd */
+o(0x2f0f); /* comisd */
 
 if (vtop-r  VT_LVAL) {
 gen_modrm(vtop[-1].r, r, vtop-sym, fc);

Bug#698351: tcc: FE_INVALID flag not set on comparison with NAN (unordered)

[Thomas Preud'homme]

Le jeudi 17 janvier 2013 15:40:31, vous avez écrit :
 Package: tcc
 Version: 0.9.26~git20120612.ad5f375-6
 Severity: normal

Hi Vincent,

sorry for answering so late.

 
 TCC doesn't set the FE_INVALID flag on comparison with NAN (=, =, , ),
 at least on amd64, e.g. with:
 
 #include stdio.h
 #include math.h
 #include fenv.h
 
 #pragma STDC FENV_ACCESS ON
 
 int main (void)
 {
   double d = NAN;
   volatile double v = NAN;
   int err = 0;
 
   feclearexcept (FE_INVALID);
   if (d = 0.0)
 {
   printf (NAN comparison is wrong (1)\n);
   err = 1;
 }
   if (! fetestexcept(FE_INVALID))
 {
   printf (The FE_INVALID flag is not set (1)\n);
   err = 1;
 }
 
   feclearexcept (FE_INVALID);
   if (v = 0.0)
 {
   printf (NAN comparison is wrong (2)\n);
   err = 1;
 }
   if (! fetestexcept(FE_INVALID))
 {
   printf (The FE_INVALID flag is not set (2)\n);
   err = 1;
 }
 
   feclearexcept (FE_INVALID);
   v = 0.0;
   if (! fetestexcept(FE_INVALID))
 {
   printf (The FE_INVALID flag is not set (3)\n);
   err = 1;
 }
 
   return err;
 }
 
 I get:
 
 $ tcc nancmp.c -o nancmp -lm
 $ ./nancmp
 The FE_INVALID flag is not set (1)
 The FE_INVALID flag is not set (2)
 The FE_INVALID flag is not set (3)
 
 Like GCC (which is affected by the same bug), the problem is that
 tcc uses ucomisd instead of comisd for =, =, , .
 

This seems like an easy bug to fix, especially with the precise information you 
gave as to the reason. Unfortunately I don't have any x86 machine to test the 
fix, would you mind compiling upstream tcc on your own with the attached patch 
applied?

Best regards,

Thomasdiff --git a/i386-gen.c b/i386-gen.c
index b26b844..5f0c0f4 100644
--- a/i386-gen.c
+++ b/i386-gen.c
@@ -895,7 +895,7 @@ ST_FUNC void gen_opf(int op)
 swapped = 0;
 if (swapped)
 o(0xc9d9); /* fxch %st(1) */
-o(0xe9da); /* fucompp */
+o(0xd9de); /* fcompp */
 o(0xe0df); /* fnstsw %ax */
 if (op == TOK_EQ) {
 o(0x45e480); /* and $0x45, %ah */
diff --git a/x86_64-gen.c b/x86_64-gen.c
index 0962056..dc2ced1 100644
--- a/x86_64-gen.c
+++ b/x86_64-gen.c
@@ -1792,7 +1792,7 @@ void gen_opf(int op)
 swapped = 0;
 if (swapped)
 o(0xc9d9); /* fxch %st(1) */
-o(0xe9da); /* fucompp */
+o(0xd9de); /* fcompp */
 o(0xe0df); /* fnstsw %ax */
 if (op == TOK_EQ) {
 o(0x45e480); /* and $0x45, %ah */
@@ -1876,7 +1876,7 @@ void gen_opf(int op)
 
 if ((vtop-type.t  VT_BTYPE) == VT_DOUBLE)
 o(0x66);
-o(0x2e0f); /* ucomisd */
+o(0x2f0f); /* comisd */
 
 if (vtop-r  VT_LVAL) {
 gen_modrm(vtop[-1].r, r, vtop-sym, fc);

Bug#731093: [Pkg-dspam-misc] Bug#731093: (no subject)

[Thomas Preud'homme]

Le dimanche 8 décembre 2013, 00:01:05 Thomas Preud'homme a écrit :
 So from what Adrien showed me, it seems with -11 there is an INSERT being
 done with: E'\\x...' while with -12 it becomes: E'\x...'.
 
 So there seems to be some escaping issue. I'll be busy tomorrow but I'll
 look into it monday and I hope this is enough clue for me to find out
 what's the problem here.

Sorry, I got distracted by another project of mine and real life issue.

So I'm not sure about why there is only a single backslash for bytea values as 
string litteral but two backslashes are clearly necessary. Indeed, the two 
backslashes are first interpreted by the string litteral parser which leads to 
a single escape in the result, something of the form '\x...'. Then this is 
parsed by the bytea input which transform it into a sequence of bytes.

Adrien, are you familiar with gdb? If yes, would you mind helping me debug 
this issue? We could set up a meeting on IRC which would be the most 
convenient way to do it or do it over email (that would be a bit slower but 
allow for more asynchronism between us).

Best regards,

Thomas


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

Bug#731093: [Pkg-dspam-misc] Bug#731093: Bug#731093: (no subject)

[Thomas Preud'homme]

Le vendredi 13 décembre 2013, 16:57:06 Thomas Preud'homme a écrit :
 
 So I'm not sure about why there is only a single backslash for bytea values
 as string litteral but two backslashes are clearly necessary. Indeed, the
 two backslashes are first interpreted by the string litteral parser which
 leads to a single escape in the result, something of the form '\x...'. Then
 this is parsed by the bytea input which transform it into a sequence of
 bytes.
 
 Adrien, are you familiar with gdb? If yes, would you mind helping me debug
 this issue? We could set up a meeting on IRC which would be the most
 convenient way to do it or do it over email (that would be a bit slower but
 allow for more asynchronism between us).

That might not be necessary. I checked libpq's code (the C library to use 
postgresql from a program) of the function PQescapeByteaInternal and the 
amount of backslashed depends on whether standard_conforming_strings is set to 
on or off. Since version -12 of dspam, the default value (on) is used while the 
value was set to off (by mistake) in version -11. That explains why the bug 
appears. I just need to understand why two backslashes are not present in both 
cases and I will be able to fix this bug.

So please be patient, this issue should be resolved soon.

Best regards,

Thomas


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

Bug#731093: (no subject)

[Thomas Preud'homme]

So from what Adrien showed me, it seems with -11 there is an INSERT being done 
with: E'\\x...' while with -12 it becomes: E'\x...'.

So there seems to be some escaping issue. I'll be busy tomorrow but I'll look 
into it monday and I hope this is enough clue for me to find out what's the 
problem here.

Thanks Adrien.

Thomas


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

Bug#731093: [Pkg-dspam-misc] Bug#731093: libdspam7-drv-pgsql: dspam logs showing invalid byte sequence

[Thomas Preud'homme]

Le jeudi 5 décembre 2013, 19:11:26 Adrien Clerc a écrit :
 Hi,
 
 I got exactly the same behavior since upgrade to last package. Before
 that, I got something like this in /var/log/postgresql/:
 
 2013-12-05 18:58:49 CET ATTENTION: utilisation non standard de \\ dans
 une chaîne littérale au caractère 127
 2013-12-05 18:58:49 CET ASTUCE : Utilisez la syntaxe de chaîne
 d'échappement pour les antislashs, c'est-à-dire E'\\'.
 2013-12-05 18:58:49 CET LOG: instruction : INSERT INTO
 dspam_signature_data (uid,signature,length,created_on,data) VALUES
 (4,'52a0bed916707
 9777898567',4392,CURRENT_DATE,'\\xd0 [truncated…]
 
 (Basicaly, it say to use escape sequence for backslashes, instead of \\x
 inside the value)

Yes it was already reported and that is one of the bug that the latest version 
was supposed to fix. I'll see what I did wrong there and try to fix it as soon 
as possible.

 
 After upgrade, I got:
 
 2013-12-04 13:55:53 CET ERREUR: séquence d'octets invalide pour
 l'encodage « UTF8 » : 0xf6 0x33 0x65 0x30
 2013-12-04 13:55:53 CET INSTRUCTION : INSERT INTO dspam_signature_data
 (uid,signature,length,created_on,data) VALUES (4,E'529f2659145699019
 213421',1644,CURRENT_DATE,E'\xf63e0 [truncated…]
 
 So exactly the same message. And exactly the same behavior as reported,
 if I try to decode this in Python. The signature seems to be wrong. I
 can provide you a simple email if you like.

Yes please.

Best regards,

Thomas


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

Bug#731093: [Pkg-dspam-misc] Bug#731093: libdspam7-drv-pgsql: dspam logs showing invalid byte sequence

[Thomas Preud'homme]

Le mardi 3 décembre 2013, 23:01:52 Craig Small a écrit :
 On Mon, Dec 02, 2013 at 01:31:34PM +0800, Thomas Preud'homme wrote:
  If you just installed libdspam7-drv-pgsql, could you try installing
  previous dspam version from snapshot.debian.org and see if you still have
  this error?
 With libdspam7-drv-pgsql 3.10.2+dfsg-11 I get none of these error
 messages. Looks like it was introduced in -12 then.

Thanks, it should help a lot. If I may, would you mind sending me one of the 
email that generate these errors? It would help me reproduce the problem and 
also reduce the number of hypothesis I have to do by looking at an actual 
message that cause the bug instead of imagining all what can happen.

Thanks a lot again.

Best regards,

Thomas


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

Bug#730999: [Pkg-dspam-misc] Bug#730999: [dspam] Respect --rcpt-to parameter for dspam client to daemon

[Thomas Preud'homme]

Le samedi 30 novembre 2013, 21:10:51 Adrien CLERC a écrit :
 Package: dspam
 Version: 3.10.2+dfsg-12
 Severity: important
 Tags: patch
 
 --- Please enter the report below this line. ---
 Hi,
 
 I'm using dspam as a content_filter in postfix, and discovered that
 using --rcpt-to ${recipient} doesn't work as expected.
 Indeed, the dspam client send the user in RCPT-TO while discussing to
 the server.

Indeed. I also don't understand the purpose of the strcpy before the loop but 
I might have overlooked something as I just did a very quick look.

 Here is the patch that make it work like in the man: use rcpt-to if
 available, else use the user.

Seems fine.

 
 Maybe it should be send upstream…

It definitely should. Would you mind doing it? If you don't have a sourceforge 
account already I can do it myself.

 
 Thanks for integration and comments,

Well, the patch looks fine and you did all the work so really, thank *you*.

 
 Adrien

Best regards,

Thomas


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

Bug#731093: [Pkg-dspam-misc] Bug#731093: libdspam7-drv-pgsql: dspam logs showing invalid byte sequence

[Thomas Preud'homme]

Control: clone 731093 -1
Control: reassign -1 dspam
Control: retitle -1 Incorrect permission on /var/log/dspam

Le lundi 2 décembre 2013, 09:04:13 Craig Small a écrit :
 Package: libdspam7-drv-pgsql
 Version: 3.10.2+dfsg-12
 Severity: normal
 
 Hi,
   First of all, there is a problem with the permissions on
 /var/log/dspam. I think they need to be dspam group writeable. My mail
 logs were filling up with unable to write to the logfile before I fixed
 that.

Duplicating this bug report to keep track of this separate issue.

 
 Second, there is a problem with the encoding when sending signatures
 into the postgresql backend.  I don't get it for every email but it is
 quite a few:
 
 [12/02/2013 07:04:42] 21058: ERROR:  invalid byte sequence for encoding
 UTF8: 0xcf 0x37 [12/02/2013 07:13:45] 22856: ERROR:  invalid byte
 sequence for encoding UTF8: 0xca 0x37 [12/02/2013 07:33:28] 26369: ERROR:
  invalid byte sequence for encoding UTF8: 0xb7 [12/02/2013 07:39:34]
 27253: ERROR:  invalid byte sequence for encoding UTF8: 0xf7 0x36 0x34
 0x34

Did you already have libdspam7-drv-pgsql installed prior to the last upload 
and this error appeared after the upgrade? A change was made to the SQL query 
in the last upload so if you just encountered this error I guess it would be 
the cause. On the other hand, the change was just about marking strings as 
escape strings and shouldn't affect the encoding.

If you just installed libdspam7-drv-pgsql, could you try installing previous 
dspam version from snapshot.debian.org and see if you still have this error?

 
 I take the offending string and put it into python and try to decode it
 and get a similiar message. If I take one of the signatures out of the
 database and do the same trick in python, it does decode correctly.
 So it seems that dspam is not feeding correct UTF-8 into the database
 and the database is having a whinge about it.

Ok, thanks for the test.

 
  - Craig

Best regards,

Thomas


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

Bug#729787: Does not remove everything on purge

[Thomas Preud'homme]

Le dimanche 17 novembre 2013, 13:43:35 Gaudenz Steinlin a écrit :
 Package: dspam
 Version: 3.10.1+dfsg-11
 Severity: serious
 
 According to the Debian Policy packages should remove everything on
 purge. The dspam package does not remove /var/spool/dspam and
 /var/log/dspam if there are files (created by dspam) in there.

So I checked policy again because I wanted to know exactly what it says. I am 
not sure purging mysql-server-$version should remove the databases. Policy 
mentions that configuration files and logs should be removed on purge but I 
could not find anything else by searching for purge. Beside, section 6.8 about 
the datails of how the purge script is called is explicitely named Details of 
removal and/or *configuration* purging. Therefore I am not sure 
/var/spool/dspam should be removed, especially this folder contain data 
collected by dspam to take decisions. It is thus really akin the mysql example 
cited above.

What do you think about it?

 
 The package should remove these directories in a postrm script if the
 package is purged.

Agreed for /var/log/dspam at least. I'm really not sure for /var/spool/dspam.

 
 Gaudenz

Best regards,

Thomas


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

Bug#729787: Does not remove everything on purge

[Thomas Preud'homme]

Le dimanche 17 novembre 2013 21:36:34, vous avez écrit :
 Hi
 
 Thomas Preud'homme robo...@debian.org writes:
  
  So I checked policy again because I wanted to know exactly what it says. I
  am not sure purging mysql-server-$version should remove the databases.
  Policy mentions that configuration files and logs should be removed on
  purge but I could not find anything else by searching for purge. Beside,
  section 6.8 about the datails of how the purge script is called is
  explicitely named Details of removal and/or *configuration* purging.
  Therefore I am not sure
  /var/spool/dspam should be removed, especially this folder contain data
  collected by dspam to take decisions. It is thus really akin the mysql
  example cited above.
  
  What do you think about it?
 
 I agree that policy is not cristal clear about this. The dpkg manpage
 says that --purge removes everything including conffiles. At another
 place it says The package is selected to be purged (i.e. we want to
 remove everything from system directories, even  configuration files).
 As I read this, system directories includes /var/spool/dspam.
 
 I also had look at what other packages do. PostgreSQL remvoes the
 databases on purge. MySQL has a debconf question asking if the databases
 should be removed. It even removes the mysql user (which is bad IMHO).
 From this I conclude that it's at least not unheared that data is
 removed on purge.

Ok, then if postgresql do it, dspam can definitely do it. I'll add this to the 
next version of the package. I have to fix an RC bug first though, so I don't 
know when that would be.

 
 IMO all traces of a package should be removed on purge, including data.
 I don't see a good use case for removing all configuration files and
 keeping the data. If you prefer a debconf question as a precaution, that
 seems fine to me.
 
 One last consideration would be if /var/spool/dspam could be on a
 network filesystem. I don't know enough about the hash driver to be sure
 if that's possible, but my guess is that most people would use either
 the pgsql or mysql drivers if they want to share the data between
 different dspam instances.

I am not sure to follow you. Do you suggest not to remove this directory if it 
is on NFS?

Best regards,

Thomas


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

Bug#722485: [Pkg-dspam-misc] Bug#722485: dspam: Same problem with stable (3.10.1+dfsg-11) and testing (3.10.2+dfsg-11) versions

[Thomas Preud'homme]

Le vendredi 1 novembre 2013 11:24:34 Gabriel Francisco a écrit :
 Package: dspam
 Version: 3.10.2+dfsg-11
 Followup-For: Bug #722485
 
 Dear Maintainer,
 how are you?

I'm fine although not much available right now, thank you for asking :)

Thank you for reminding me about this issue. I know what is the root of the 
problem and had already attempted to make a fix but I failed to understand all 
the interaction of the lines I wrote with the rest of the code. The problem is 
that the code assume the files are not corrupted and that causes a segfault 
when it is the case. As to why the file gets corrupted in the first place, it's 
more difficult to understand. If you find that the problem always appear after 
the same number of email received that would give me a big clue but if the 
number is fluctuating that could just be some race condition.

At least for the immediate problem the problem is known and it is quite easily 
fixable. However, upstream development seems rather dead and I don't have much 
time to look into it right now (I can't promise any deadline). Furthermore, I 
don't think it is good to fix everything on Debian side, even if it's critical 
bug. I'll check with upstream if someone is still around but if not I'll write 
a note recommending to switch away from dspam.

Best regards,

Thomas Preud'homme


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

Bug#722484: Bug#726138: dspam css file size dramatically increased after upgrade

[Thomas Preud'homme]

Given the problem with the last upload, I'll revert it for now and see how to 
solve the problem without breakage.


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

Bug#722484: Info received (libdspam7-drv-hash segfaults since 3.10.2+dfsg-10)

[Thomas Preud'homme]

Control: reopen 722484 m...@blackshift.org

Le lundi 7 octobre 2013 23:01:47, vous avez écrit :
 Hello
 
 I've deleted /var/spool/dspam/data and let dspam deliver a mail, that
 produces this backtrace:
 
 #0  0xb6f118ec in raise () from /lib/arm-linux-gnueabi/libpthread.so.0
 No symbol table info available.
 #1  0xb6a5acf4 in __aeabi_ldiv0 () from
 /usr/lib/arm-linux-gnueabi/dspam/libhash_drv.so No symbol table info
 available.
 #2  0xb6a59b9c in _hash_drv_seek (map=map@entry=0xb57073d8,
 offset=offset@entry=16147856, hashcode=optimized out,
 flags=flags@entry=1) at hash_drv.c:1194 header = optimized out
 rec = optimized out
 fpos = optimized out
 iterations = 0

Ok, this bug was very likely introduced with the patch I made to handle 
corrupted css file. Unfortunetely I don't have the time to fix the patch now. 
I'm very busy for a few weeks but I'll try to take a look at it as soon as 
possible.

Best regards.


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

Bug#722484: Info received (libdspam7-drv-hash segfaults since 3.10.2+dfsg-10)

[Thomas Preud'homme]

Le mercredi 9 octobre 2013 14:56:23, vous avez écrit :
 
 Yes the bug was introduced between 3.10.2+dfsg-9 and 3.10.2+dfsg-10. As
 I'm running -9 without problems.
 
 Although the incremental diff from -9 to -10 doesn't look suspicious at
 
 the first glance:
  diff --git a/src/hash_drv.c b/src/hash_drv.c
  index 349b491..daae2e7 100644
  --- a/src/hash_drv.c
  +++ b/src/hash_drv.c
  @@ -1187,32 +1187,36 @@ unsigned long _hash_drv_seek(
  
 unsigned long fpos;
 unsigned long iterations = 0;
 
 if (offset = map-file_len)
 
   return 0;
 
 fpos = sizeof(struct _hash_drv_header) +
 
   ((hashcode % header-hash_rec_max) * sizeof(struct
   _hash_drv_spam_record));
 
 
 
 According to the backtrace's line number the diff-by-zero should happen
 here. But the modulo, which is IIRC implemented on ARM as
 divide/multiply/difference, was here all the time.
 
 Was there a compiler change? Maybe some new optimisations brakes the code.

Without having looked at the code, I suspect that hash_rec_max is updated from 
_hash_drv_seek's return value. Since I added a check to detect when the end of 
file is going to be reached, the function returns 0 in case where it was not 
the case before.


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

Bug#722248: [Pkg-haskell-maintainers] Bug#722248: ghci not provided on arm

[Thomas Preud'homme]

Le mardi 10 septembre 2013 18:23:42 Colin Watson a écrit :
 
 Thanks for looking into this further.
 
 I think that inlining the cache flush will mean that every chunk of
 bytecode assembled by the interpreter will flush the instruction cache
 every time it's called.  It will be even slower than it's necessary for
 it to be.  That in itself would probably be tolerable.
 
 Much more importantly, though, this patch misses the point of flushing
 the instruction cache.  The point is that we need to flush the cache in
 order for the processor to reliably read back the code that we just
 wrote out; flushing the cache in that very code is not a viable approach
 to that, because the cache-flushing code itself might not be read.  So
 I'm afraid I don't think this is going to work properly.  It might work
 some of the time, of course, depending on cache locality, but I can't
 see how it would work reliably.

My apologize, I didn't realize this was the generated code. I don't know if 
it's because of the language but I can't make much sense of what the code is 
doing. I assumed this code was some jit compiler and that the jump was 
executed when a function has just been compiled in order to actually call that 
function. If it's part of the generated function indeed it's very suboptimal 
and won't work as you very well explained.

My apologize but I don't think I can bring this further without investing 
quite some time to understand the code.

 
 I would suggest testing whether some reasonable stack actually builds
 with this; I don't know how much testing you did but it e.g. isn't
 enough to just start ghci.  Perhaps see if haskell-conduit runs its
 doctests successfully during build.

You're right, I should have done so. I don't know anything about ghc and I 
didn't know how to test it. I should have searched a bit on google, probably I 
would have found some code sample easily but I guess I lacked motivation.

Thanks for being so quick in looking at the patch.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.

Bug#722057: Bug not fixed in libhash_drv

[Thomas Preud'homme]

Control: clone 722057 -1
Control: retitle 722057 libdspam7-drv-hash: dspam segfaults [cssclean]
Control: reopen -1
thanks

Reopening since only the crash in cssclean was fixed. The sample of
dmesg suggest that there is a similar kind of bug in libhash_drv. Sorry
for forgetting about this.

signature.asc
Description: This is a digitally signed message part.

Bug#722057: libdspam7-drv-hash: dspam segfaults [libhash_drv on _hash_drv_seek()]

[Thomas Preud'homme]

Le samedi 7 septembre 2013 23:46:14 Thomas Preud'homme a écrit :
 
 By the way, could you send me that css file so that I can run some test on
 it? It's better to not send it to the bug log as it might contain some
 private information. I don't know exactly what is stored in those files so
 better be safe than sorry.

Alright, I managed to reproduce the issue with the file you sent me. From what 
I could gather quickly in gdb the file is corrupted. Cssclean assume the file 
respect some constraint but since they are not respected it reads too far in 
memory which causes the segfault. The bug didn't happened for me when I was 
running as simple user because it could not read the configuration.

I'll forward the problem upstream but given how silent is the development 
since one year (not a single commit, almost no message on mailing list), I 
doubt they will fix it. This means I'll probably do the fix myself but I don't 
have much time right now.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.

Bug#722248: ghci not provided on arm

[Thomas Preud'homme]

Source: ghc
Version: 7.6.3-4
Severity: wishlist
Tags: patch upstream

Dear Maintainer,

please reenable ghci on arm as it prevents many package from building. I
improved on the patch proposed upstream and it works on porterbox. Maybe
you could give it a try in experimental. See the patch in the attached
file.

Best regards.


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'oldstable-updates'), (500, 'testing'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.10-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Description: Add ARM implementation for mkJumpToAddr
 TODO: Put a short summary on the line above and replace this paragraph
 with a longer explanation of this change. Complete the meta-information
 with other relevant fields (see below for details). To make it easier, the
 information below has been extracted from the changelog. Adjust it or drop
 it.
 .
 ghc (7.6.3-4) unstable; urgency=low
 .
   [ Colin Watson ]
   * Enable verbose build output (see
 http://lists.debian.org/debian-devel/2013/06/msg00539.html).
 .
   [ Gianfranco Costamagna ]
 .
   * Switch to llvm (Closes: #711948)
   * removed deprecated DM-Upload-Allowed
   * removed some version checks, higher versions are already in oldstable.
   * Added dpkg-buildflags as build-dep, fixing lintian warning.
Author: Joachim Breitner nome...@debian.org
Bug-Debian: http://bugs.debian.org/711948

---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: vendor|upstream|other, url of original patch
Bug: url in upstream bugtracker
Bug-Debian: http://bugs.debian.org/bugnumber
Bug-Ubuntu: https://launchpad.net/bugs/bugnumber
Forwarded: no|not-needed|url proving that it has been forwarded
Reviewed-By: name and email of someone who approved the patch
Last-Update: -MM-DD

--- ghc-7.6.3.orig/compiler/ghci/ByteCodeItbls.lhs
+++ ghc-7.6.3/compiler/ghci/ByteCodeItbls.lhs
@@ -242,6 +242,18 @@ mkJumpToAddr a
   , fromIntegral ((w64 `shiftR` 32) .. 0x) ]
 where w64 = fromIntegral (ptrToInt a) :: Word64
 
+#elif arm_TARGET_ARCH
+type ItblCode = Word32
+mkJumpToAddr a
+= [ 0xe92d0080  -- push{r7}
+  , 0xe3a0780f  -- mov r7, #983040 ; 0xf
+  , 0xe2877002  -- add r7, r7, #2
+  , 0xe3a02000  -- mov r2, #0
+  , 0xef00  -- swi 0x0
+  , 0xe8bd0080  -- pop {r7}
+  , 0xe51ff004  -- ldr pc, [pc, #-4]# pc reads as current insn+8
+  , fromIntegral (ptrToInt a) ]
+
 #else
 type ItblCode = Word32
 mkJumpToAddr a

Bug#722057: libdspam7-drv-hash: dspam segfaults [libhash_drv on _hash_drv_seek()]

[Thomas Preud'homme]

Le samedi 7 septembre 2013 09:51:28 Raphael Droz a écrit :
 
 I happened to be in a situation where I can't even fully flush the postfix
 queue without having Dspam to segfault.
 I end up installing dspam-dbg and gdb and attach to the process [I wasn't
 able to run the process without the init-script].

Symbols for libdspam7-drv-hash are found in libdspam7-dbg. Could you install 
it and give me stacktrace you get with it?

Thanks a lot

signature.asc
Description: This is a digitally signed message part.

Bug#722057: libdspam7-drv-hash: dspam segfaults [libhash_drv on _hash_drv_seek()]

[Thomas Preud'homme]

Le samedi 7 septembre 2013 21:13:24 vous avez écrit :
 On Sat, Sep 07, 2013 at 08:33:21PM +0200, Thomas Preud'homme wrote:
  Le samedi 7 septembre 2013 09:51:28 Raphael Droz a écrit :
   I happened to be in a situation where I can't even fully flush the
   postfix
   queue without having Dspam to segfault.
   I end up installing dspam-dbg and gdb and attach to the process [I
   wasn't
   able to run the process without the init-script].
  
  Symbols for libdspam7-drv-hash are found in libdspam7-dbg. Could you
  install it and give me stacktrace you get with it?
 
 thanks!
 sadly for now I've postsuper'ed -r ALL emails for now.
 
 But I installed libdspam7-dbg, relink postfix to dspam and I will need
 to wait for another email to come to mailman in order reproduce it.
 
 But could you offer me another reliable way to make Dspam dumps its core
 somewhere automatically instead of this situation where I'm waiting for
 hours through ssh with $ gdb pid-of-dspam ?

Unfortunetely, dspam being setgid, it can't produce coredump on segfault even 
if coredump are enabled. It seems a call to prctl with option PR_SET_DUMPABLE 
can remediate this but it means dspam would need to be recompiled.

 
 
 thx

Thanks for the bug report and for helping to resolve it. I'll take a look at 
the CSS problem later.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.

Bug#721848: freeciv-client-sdl depends on ttf-arphic-uming

[Thomas Preud'homme]

Source: freeciv-client-sdl
Version: 2.3.4-1
Severity: serious
Justification: §3.5

Dear Maintainer,

freeciv-client-sdl depends on ttf-arphic-uming package which is no
longer built by fonts-arphic-uming. Please change the dependency to
depends on fonts-arphic-uming instead.

Best regards.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'oldstable-updates'), (500, 'testing'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.10-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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#720217: debtags: Typo in debtags editor website interface

[Thomas Preud'homme]

Package: debtags
Version: 1.10.2
Severity: minor
Tags: patch upstream

There is a typo in debtags tag editor in the sentence displayed when 1
change is pending. The sentence currently reads There is one change
change to submit: when it should be There is one change to submit:.

See attached patch.

-- System Information:
Debian Release: jessie/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.10-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff --git a/debtagslayout/static/js/debtags-ui.js b/debtagslayout/static/js/debtags-ui.js
index bcba898..770dbd7 100644
--- a/debtagslayout/static/js/debtags-ui.js
+++ b/debtagslayout/static/js/debtags-ui.js
@@ -254,7 +254,7 @@ Settings.prototype = {
 if (count_changes  0)
 {
 if (count_changes == 1)
-self._submit_summary.text(There is one change change to submit:);
+self._submit_summary.text(There is one change to submit:);
 else
 self._submit_summary.text(There are  + count_changes +  changes to submit:);
 self._submit_button.attr(disabled, false);

Bug#720202: ITP: qreator -- utility for creating QR codes

[Thomas Preud'homme]

Le lundi 19 août 2013 23:24:48 Chow Loong Jin a écrit :
 Package: wnpp
 Severity: wishlist
 Owner: Chow Loong Jin hyper...@debian.org
 
 * Package name: qreator
   Version : 13.05.3
   Upstream Author : David Planella david.plane...@ubuntu.com
 * URL : https://launchpad.net/qreator
 * License : GPL-3
   Programming Lang: Python
   Description : utility for creating QR codes
 
 Qreator enables you to easily create your own QR codes to encode different
 types of information in an efficient, compact and cool way.

Greetings Loong Jin,

Since it seems there is already a qr generator in Debian (qrencode), I suppose 
qreator has some feature that are lacking in qrencode. Could you develop 
those? That would be especially useful in the long description so that a user 
looking for a tool creating a qr code have enough information to choose 
between these two packages.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.

Bug#719663: Postgresql driver leads to errors on console

[Thomas Preud'homme]

Le mercredi 14 août 2013 06:43:12, Erwan David a écrit :
 Package: dspam
 Version: 3.10.2+dfsg-8
 Severity: normal
 
 At each mail that dspam handles I get the following message on console :
 
 WARNING:  nonstandard use of \\ in a string literal
 LINE 1: ...ES (1,'520b09db156066170345973',1016,CURRENT_DATE,'\\x526563...
 
 It reminds of a former bug in postgresql driver.

Indeed. So it seems that the patch 010_set_legacy_escape_strings.diff is 
incomplete. Unfortunetely, I can't easily look into it right now and maybe for 
quite some time though.

Best regards,

Thomas Preud'homme


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

Bug#717089: sat-xmpp-core: missing python-gobject dependencies

[Thomas Preud'homme]

Control: reassign -1 python-twisted-core
Control: retitle -1 «Missing dependency on python-gobject

Le mardi 16 juillet 2013 18:10:41 Julien Hebert a écrit :
 
* What led up to the situation?
 
% sat

Ok, I tried in a chroot and got the following traceback:

robotux@trevize:~$ sat
Unhandled Error
Traceback (most recent call last):
  File /usr/lib/python2.7/dist-packages/twisted/application/app.py, line 
652, in run
runApp(config)
  File /usr/lib/python2.7/dist-packages/twisted/scripts/twistd.py, line 23, 
in runApp
_SomeApplicationRunner(config).run()
  File /usr/lib/python2.7/dist-packages/twisted/application/app.py, line 
386, in run
self.application = self.createOrGetApplication()
  File /usr/lib/python2.7/dist-packages/twisted/application/app.py, line 
451, in createOrGetApplication
application = getApplication(self.config, passphrase)
--- exception caught here ---
  File /usr/lib/python2.7/dist-packages/twisted/application/app.py, line 
462, in getApplication
application = service.loadApplication(filename, style, passphrase)
  File /usr/lib/python2.7/dist-packages/twisted/application/service.py, line 
405, in loadApplication
application = sob.loadValueFromFile(filename, 'application', passphrase)
  File /usr/lib/python2.7/dist-packages/twisted/persisted/sob.py, line 210, 
in loadValueFromFile
exec fileObj in d, d
  File /usr/lib/python2.7/dist-packages/sat/sat.tac, line 26, in module
from twisted.internet import glib2reactor
  File /usr/lib/python2.7/dist-packages/twisted/internet/glib2reactor.py, 
line 19, in module
from twisted.internet import gtk2reactor
  File /usr/lib/python2.7/dist-packages/twisted/internet/gtk2reactor.py, 
line 45, in module
import gobject
exceptions.ImportError: No module named gobject

Failed to load application: No module named gobject

Sounds like a missing dependency in twisted, hence reassigning.

Best regards.

signature.asc
Description: This is a digitally signed message part.

Bug#716752: /usr/bin/kvm: State clearly that kvm = qemu -machine accel=kvm:tcg

[Thomas Preud'homme]

Package: qemu-system-x86
Version: 1.5.0+dfsg-4
Severity: minor
File: /usr/bin/kvm
Tags: patch

Dear Maintainer,

Currently when using kvm binary (/usr/bin/kvm), a message is displayed
announcing its deprecation and advising to use qemu-system-x86_64
instead. However, as can be seen by reading /usr/bin/kvm script, kvm is
equivalent to qemu-system-x86_64 -machine accel=kvm:tcg. The message
should thus clearly state so.

Attached is a patch with a more accurate suggestion.

Best regards.


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'oldstable-updates'), (500, 'testing'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages qemu-system-x86 depends on:
ii  ipxe-qemu   1.0.0+git-20120202.f6840ba-3
ii  libaio1 0.3.109-4
ii  libasound2  1.0.27.2-1
ii  libbluetooth3   4.99-3
ii  libbrlapi0.64.5-3
ii  libc6   2.17-7
ii  libcairo2   1.12.14-5
ii  libcurl3-gnutls 7.31.0-2
ii  libfdt1 1.3.0-4
ii  libgdk-pixbuf2.0-0  2.28.2-1
ii  libglib2.0-02.36.3-3
ii  libgnutls26 2.12.23-5
ii  libgtk2.0-0 2.24.20-1
ii  libiscsi1   1.4.0-3
ii  libjpeg88d-1
ii  libncurses5 5.9+20130608-1
ii  libpixman-1-0   0.26.0-4
ii  libpng12-0  1.2.49-4
ii  libpulse0   4.0-3
ii  libsasl2-2  2.1.25.dfsg1-13
ii  libsdl1.2debian 1.2.15-5
ii  libseccomp1 1.0.1-2
ii  libspice-server10.12.3-0nocelt1
ii  libssh2-1   1.4.3-1
ii  libtinfo5   5.9+20130608-1
ii  libusb-1.0-02:1.0.15-1
ii  libusbredirparser1  0.6-2
ii  libuuid12.20.1-5.5
ii  libvdeplug2 2.3.2-4
ii  libvte9 1:0.28.2-5
ii  libx11-62:1.6.0-1
ii  libxen-4.2  4.2.2-1
ii  libxenstore3.0  4.2.2-1
ii  qemu-keymaps1.5.0+dfsg-4
ii  qemu-system-common  1.5.0+dfsg-4
ii  seabios 1.7.3-1
ii  vgabios 0.7a-3
ii  zlib1g  1:1.2.8.dfsg-1

Versions of packages qemu-system-x86 recommends:
ii  qemu-utils  1.5.0+dfsg-4

Versions of packages qemu-system-x86 suggests:
ii  kmod 9-3
pn  sambanone
pn  sgabios  none
ii  vde2 2.3.2-4

-- no debconf information
diff -Nru qemu-1.5.0+dfsg/debian/kvm qemu-1.5.0+dfsg/debian/kvm
--- qemu-1.5.0+dfsg/debian/kvm	2013-05-21 20:30:46.0 +0200
+++ qemu-1.5.0+dfsg/debian/kvm	2013-07-12 11:09:07.0 +0200
@@ -1,4 +1,4 @@
 #! /bin/sh
 
-echo W: kvm binary is deprecated, please use qemu-system-x86_64 instead 2
+echo W: kvm binary is deprecated, please use qemu-system-x86_64 -machine accel=kvm:tcg instead 2
 exec qemu-system-x86_64 -machine accel=kvm:tcg $@

Bug#716704: /usr/share/man/fr/man1/install.1.gz: Wrong french translation in manpage of install(1)

[Thomas Preud'homme]

Package: manpages-fr-extra
Version: 20130618
Severity: minor
File: /usr/share/man/fr/man1/install.1.gz
Tags: patch upstream

Dear Maintainer,

The french translation of install manpage introduced a typo about the
default right of files installed with install. The original sentence is:

set permission mode (as in chmod), instead of rwxr-xr-x

while the translation is:

configurer les permissions (comme avec chmod), à la place de rwxrr-xr-x

Notice the doubled r for owner's rights.

Please find attached a patch fixing this problem.

Best regards.


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'oldstable-updates'), (500, 'testing'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

manpages-fr-extra depends on no packages.

Versions of packages manpages-fr-extra recommends:
ii  manpages-fr  3.51d1p1-1

Versions of packages manpages-fr-extra suggests:
ii  konqueror [man-browser]  4:4.8.4-2
ii  man-db [man-browser] 2.6.5-2
pn  manpages-fr-dev  none

-- no debconf information
diff --git a/coreutils/po4a/po/fr.po b/coreutils/po4a/po/fr.po
index 6a0a687..498e95a 100644
--- a/coreutils/po4a/po/fr.po
+++ b/coreutils/po4a/po/fr.po
@@ -7720,7 +7720,7 @@ msgstr B-m, B--mode=IMODE
 #: C/man1/install.1:57
 msgid set permission mode (as in chmod), instead of rwxr-xr-x
 msgstr 
-configurer les permissions (comme avec chmod), à la place de rwxrr-xr-x
+configurer les permissions (comme avec chmod), à la place de rwxr-xr-x
 
 #. type: TP
 #: C/man1/install.1:57

Bug#715012: mention zsh popular among power shell users

[Thomas Preud'homme]

Le lundi 8 juillet 2013 10:31:55, Osamu Aoki a écrit :
 
 Oh, thanks it is neutral and better.  Since non-POSIX ones are diffrent
 anyway and POSIX may need to be used in the narrower context:
 
 Change POSIX shell - POSIX-like in Table 1.13.
 
 Add:
 
 TIP: Although POSIX-like shells share the basic syntax, they can differ
 in behavior for things as basic as shell variables and glob expansions.
 Please check their documentation for details.

Ack, sounds good. Thank you Osamu for your initiative.

Best regards,

Thomas


signature.asc
Description: This is a digitally signed message part.

Bug#715012: mention zsh popular among power shell users

[Thomas Preud'homme]

Le vendredi 5 juillet 2013 14:39:03, Osamu Aoki a écrit :
 Package: debian-reference
 Version: 2.50
 Severity: normal
 
 This discussion for bug #713885 reminded me to add a short note for zsh
 to debian-reference.  (I do not use zsh but ...)

[SNIP example of zsh behavior]

 
 Let me add at the end of 1.4.1. The login shell:
  
 http://www.debian.org/doc/manuals/debian-reference/ch01.en.html#_the_login
 _shell
 
 TIP:
 For the login interactive shell, Zsh is a feature rich alternative to
 Bash and popular with some power users.  Please note that some features
 of Zsh such as shell variable and glob expansions are slightly different
 from that of Bash.
 
 Osamu

Although I really like zsh, I'd rather avoid the first sentence and let people 
choose by themselves. Therefore I suggest:

Please note that shells can differ in behavior for things as basic as shell 
variables and glob expansions. Check their documentation for more information 
about their behavior.


signature.asc
Description: This is a digitally signed message part.

Bug#713885: im-config: Sourcing of 20_ibus.rc fails when shell is zsh

[Thomas Preud'homme]

Le jeudi 4 juillet 2013 13:29:39, Osamu Aoki a écrit :
 Hi,
 
 On Wed, Jul 03, 2013 at 11:59:15PM +0200, Thomas Preud'homme wrote:
  Le dimanche 23 juin 2013 21:34:59, Thomas Preud'homme a écrit :
   Sorry for the spam but I just found it. It was just in front of me.
   /etc/kde4/kdm/Xsession contains the following excerpt:
   
   case $SHELL in
   [SNIP bash case]
   
 */zsh)
 
   [ -z $ZSH_NAME ]  exec $SHELL $0 $@
   emulate -R zsh
   
   I've seen several occurences in kdm's code to set the SHELL environment
   variable. So later Xsession is executed, $SHELL is detected to be zsh
   so it exec zsh /etc/kde4/kdm/Xsession $otherargs which set zsh to zsh
   emulation mode and then source /etc/X11/Xsession. I suppose the bug
   could be fixed by setting zsh to sh emulate mode.
  
  So I'm running with emulate -R sh instead of emulate -R zsh since I wrote
  this message and it seems to work fine. I get working ibus in both GTK
  and Qt while it wasn't the case before and the session is started
  without any visible glitch. So I intend to reassign the bug with a
  little explanation to kdm package in the next days.
 
 Yes please.  I also found zsh behavior odd.

Ok, reassigning after this mail.

It's not a bug, it's a feature™.

Zsh has lots of odd behavior like this. See for instance:

# With zsh
% foo=bar baz
% for name in $foo ; do echo name: $name ; done
name: bar baz

# With bash
% foo=bar baz
$for name in $foo ; do echo name: $name ; done
name: bar
name: baz

Although it's disturbing when compared to bash, I find it a better default.

 
 === DASH ===
 
 $ EEE=$(ls /usr/lib/*/gtk-2.0/*/immodules/im-ibus.so
 /usr/lib/gtk-2.0/*/immodules/im-ibus.so) ls: cannot access
 /usr/lib/gtk-2.0/*/immodules/im-ibus.so: No such file or directory $ echo
 $EEE
 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-ibus.so
 $ ls /usr/lib/*/gtk-2.0/*/immodules/im-ibus.so
 /usr/lib/gtk-2.0/*/immodules/im-ibus.so 2/dev/null
 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-ibus.so
 $ ls /usr/lib/*/gtk-2.0/*/immodules/im-ibus.so
 /usr/lib/gtk-2.0/*/immodules/im-ibus.so 1/dev/null ls: cannot access
 /usr/lib/gtk-2.0/*/immodules/im-ibus.so: No such file or directory
 
 === ZSH ===
 osamu@goofy ~ % EEE=$(ls /usr/lib/*/gtk-2.0/*/immodules/im-ibus.so
 /usr/lib/gtk-2.0/*/immodules/im-ibus.so) zsh: no matches found:
 /usr/lib/gtk-2.0/*/immodules/im-ibus.so
 osamu@goofy ~ % echo $EEE
 
 osamu@goofy ~ % ls /usr/lib/*/gtk-2.0/*/immodules/im-ibus.so
 /usr/lib/gtk-2.0/*/immodules/im-ibus.so 2/dev/null zsh: no matches found:
 /usr/lib/gtk-2.0/*/immodules/im-ibus.so
 osamu@goofy ~ % ls /usr/lib/*/gtk-2.0/*/immodules/im-ibus.so
 /usr/lib/gtk-2.0/*/immodules/im-ibus.so 1/dev/null zsh: no matches found:
 /usr/lib/gtk-2.0/*/immodules/im-ibus.so

 
 The second path is not expected to match anything.  That is the same in
 dash or bash.  But, zsh spits some error message to non-stderr and quits.
 EEE is not set either.
 
 This is strange for me.

The thing is zsh's behavior is safer by default. In bash, if a * doesn't match 
any file it will be left as is. Thus, if you do touch * and there is no file in 
the current directory, it will create a file named '*'. In zsh, the default is 
to just returns an error. Bash's behavior can be obtained by setting NOMATCH. 
Alternatively, you can set NULL_GLOB to replace '*' by nothing. This is 
explained in the zshexpn man page, in the FILENAME GENERATION section:

The word is replaced with a list of sorted filenames that match the pattern. 
If  no  matching  pattern is found,  the  shell  gives  an  error message, 
unless the NULL_GLOB option is set, in which case the word is deleted; or 
unless the NOMATCH option is unset, in which case the word is left unchanged.

 
 Osamu
 
 PS: The second path is there to support backport etc.  This is intentional
 and works fine with dash/bash.

Yes I know, I figured it out :)

Best regards,

Thomas


signature.asc
Description: This is a digitally signed message part.

Bug#713885: im-config: Sourcing of 20_ibus.rc fails when shell is zsh

[Thomas Preud'homme]

Control: reassign -1 kdm
Control: retitle -1 kdm does not execute Xsession scripts as sh scripts

Currently, when the user shell is zsh, kdm launch the X session in zsh 
emulation mode (it does emulate -R zsh in /etc/kde4/kdm/Xsession). However, 
all X session scripts assume bourne shell behavior. In particular, this leads 
to a bug in /usr/share/im-config/data/20_ibus.rc

This file contains several line like this one:

for IM_CONFIG_MARKER in $(ls /usr/lib/*/gtk-2.0/*/immodules/im-ibus.so \
/usr/lib/gtk-2.0/*/immodules/im-ibus.so 2/dev/null || 
true); do

In zsh emulation mode this fails because either all the modules are in arch-
specific path, or not and in this case zsh just returns an error. Quoting 
zshexpn manpage:

The word is replaced with a list of sorted filenames that match the pattern. If 
no matching pattern is found, the shell gives an error message, unless the 
NULL_GLOB option is set, in  which  case  the  word is deleted; or unless the 
NOMATCH option is unset, in which case the word is left unchanged.

Because of this, GTK and QT apps don't use ibus despite it being running.

I tried changing the emulate -R zsh line by emulate -R sh and it now works 
great for me since more than a week. It seems though that kdm developers 
explicitely want the shell to behave in its normal mode since you run set +o 
posix for bash so there might be a reason to execute zsh in zsh emulation 
mode.

Therefore, I'm not sure what the correct solution is but Osamu Aoki, 
maintainer of im-config, believe that Xsession scripts should be executed in 
bourne shell mode as can be seen from the few #!/bin/sh shebang lines in 
/etc/X11/Xsession and in some other places (I forgot where).

Best regards,

Thomas


signature.asc
Description: This is a digitally signed message part.

Bug#713885: im-config: Sourcing of 20_ibus.rc fails when shell is zsh

[Thomas Preud'homme]

Le dimanche 23 juin 2013 21:34:59, Thomas Preud'homme a écrit :
 
 Sorry for the spam but I just found it. It was just in front of me.
 /etc/kde4/kdm/Xsession contains the following excerpt:
 
 case $SHELL in
 [SNIP bash case]
   */zsh)
 [ -z $ZSH_NAME ]  exec $SHELL $0 $@
 emulate -R zsh
 
 I've seen several occurences in kdm's code to set the SHELL environment
 variable. So later Xsession is executed, $SHELL is detected to be zsh so it
 exec zsh /etc/kde4/kdm/Xsession $otherargs which set zsh to zsh emulation
 mode and then source /etc/X11/Xsession. I suppose the bug could be fixed
 by setting zsh to sh emulate mode.

So I'm running with emulate -R sh instead of emulate -R zsh since I wrote this 
message and it seems to work fine. I get working ibus in both GTK and Qt while 
it wasn't the case before and the session is started without any visible 
glitch. So I intend to reassign the bug with a little explanation to kdm 
package in the next days.

Best regards,

Thomas


signature.asc
Description: This is a digitally signed message part.

Bug#713035: eatmydata bugs

[Thomas Preud'homme]

Le vendredi 28 juin 2013 00:35:48, Stewart Smith a écrit :
 Hi!
 
 I'm the upstream eatmydata maintainer.
 
 The aim of libeatmydata is to behave exactly the same but instead have a
 zero time fsync (and friends). So, if fsync(), msync() and fdatasync()
 are meant to be cancellation points and I can simulate that in eatmydata
 with calling pthread_testcancel(), I'd consider it a bug in eatmydata
 and with luck I'll make another upstream release today with that fixed.
 
 If you have a really short test program for it, I'll happily include it
 in the eatmydata test suite.

Here is a small test case extracted from tst-cancel4.c in eglibc sources. I 
modified it so that it exits with 2 (instead of 1 for other errors) when fsync 
| msync | fdatasync doesn't act as cancellation points while it should.

You need to have a file called Makefile in the working directory for the test 
to work:

2:17 robotux@trevize ~% touch Makefile 
2:19 robotux@trevize ~% ./tst-cancel4 
early cancel test of 'fsync' successful
early cancel test of 'fdatasync' successful
early cancel test of 'msync' successful
2:19 robotux@trevize ~% eatmydata ./tst-cancel4
tf_fsync: fsync returned
cleanup handler not called for 'fsync'
tf_fdatasync: fdatasync returned
cleanup handler not called for 'fdatasync'
tf_msync: msync returned
cleanup handler not called for 'msync'
zsh: exit 2 eatmydata ./tst-cancel4

 
 Last time I checked, Debian was carrying an older eatmydata version, so
 it'll likely need to be updated to get this fix.

And the buildd environment to updated I think. Since eatmydata is not 
installed as a build-dep but already part of the chroot, it needs to be 
manually updated by buildd admin.

Best regards,

Thomas
/* Copyright (C) 2002, 2003, 2004, 2006, 2007 Free Software Foundation, Inc.
   This file is part of the GNU C Library.
   Contributed by Ulrich Drepper drep...@redhat.com, 2002.

   The GNU C Library is free software; you can redistribute it and/or
   modify it under the terms of the GNU Lesser General Public
   License as published by the Free Software Foundation; either
   version 2.1 of the License, or (at your option) any later version.

   The GNU C Library 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
   Lesser General Public License for more details.

   You should have received a copy of the GNU Lesser General Public
   License along with the GNU C Library; if not, see
   http://www.gnu.org/licenses/.  */

/* NOTE: this tests functionality beyond POSIX.  POSIX does not allow
   exit to be called more than once.  */

#include errno.h
#include fcntl.h
#include limits.h
#include pthread.h
#include stddef.h
#include stdio.h
#include stdlib.h
#include string.h
#include termios.h
#include unistd.h
#include sys/mman.h
#include sys/msg.h
#include sys/poll.h
#include sys/select.h
#include sys/socket.h
#include sys/uio.h
#include sys/un.h
#include sys/wait.h

//#include pthreadP.h


/* Since STREAMS are not supported in the standard Linux kernel and
   there we don't advertise STREAMS as supported is no need to test
   the STREAMS related functions.  This affects
 getmsg()  getpmsg()  putmsg()
 putpmsg()

   lockf() and fcntl() are tested in tst-cancel16.

   pthread_join() is tested in tst-join5.

   pthread_testcancel()'s only purpose is to allow cancellation.  This
   is tested in several places.

   sem_wait() and sem_timedwait() are checked in tst-cancel1[2345] tests.

   mq_send(), mq_timedsend(), mq_receive() and mq_timedreceive() are checked
   in tst-mqueue8{,x} tests.

   aio_suspend() is tested in tst-cancel17.

   clock_nanosleep() is tested in tst-cancel18.
*/

/* Pipe descriptors.  */
static int fds[2];

/* Temporary file descriptor, to be closed after each round.  */
static int tempfd = -1;
static int tempfd2 = -1;
/* Name of temporary file to be removed after each round.  */
static char *tempfname;
/* Temporary message queue.  */
static int tempmsg = -1;

/* Often used barrier for two threads.  */
static pthread_barrier_t b2;


#ifndef IPC_ADDVAL
# define IPC_ADDVAL 0
#endif

#define WRITE_BUFFER_SIZE 4096

/* Cleanup handling test.  */
static int cl_called;

static void
cl (void *arg)
{
  ++cl_called;
}



static void *
tf_fsync (void *arg)
{
  if (arg == NULL)
// XXX If somebody can provide a portable test case in which fsync()
// blocks we can enable this test to run in both rounds.
abort ();

  tempfd = open (Makefile, O_RDONLY);
  if (tempfd == -1)
{
  printf (%s: cannot open Makefile\n, __FUNCTION__);
  exit (1);
}

  int r = pthread_barrier_wait (b2);
  if (r != 0  r != PTHREAD_BARRIER_SERIAL_THREAD)
{
  printf (%s: barrier_wait failed\n, __FUNCTION__);
  exit (1);
}

  r = pthread_barrier_wait (b2);
  if (r != 0  r != PTHREAD_BARRIER_SERIAL_THREAD)
{
  printf (%s: 2nd barrier_wait 

Bug#713035: eatmydata bugs

[Thomas Preud'homme]

Le vendredi 28 juin 2013 02:21:00, Thomas Preud'homme a écrit :
 Le vendredi 28 juin 2013 00:35:48, Stewart Smith a écrit :
  Hi!
  
  I'm the upstream eatmydata maintainer.
  
  The aim of libeatmydata is to behave exactly the same but instead have a
  zero time fsync (and friends). So, if fsync(), msync() and fdatasync()
  are meant to be cancellation points and I can simulate that in eatmydata
  with calling pthread_testcancel(), I'd consider it a bug in eatmydata
  and with luck I'll make another upstream release today with that fixed.
  

And here is a proposed patch although I'm sure you don't need it :)

Sorry for the HTML part in the previous message by the way. I don't know why 
that settings changed in my MUA.

Best regards,

Thomas
diff -Nru libeatmydata-26/debian/changelog libeatmydata-26/debian/changelog
--- libeatmydata-26/debian/changelog	2011-02-19 13:28:02.0 +0100
+++ libeatmydata-26/debian/changelog	2013-06-28 02:28:17.0 +0200
@@ -1,3 +1,11 @@
+libeatmydata (26-2.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Make fsync, msync and fdatasync cancellation points as required by POSIX
+(Closes: #713035).
+
+ -- Thomas Preud'homme robo...@debian.org  Fri, 28 Jun 2013 02:27:30 +0200
+
 libeatmydata (26-2) unstable; urgency=low
 
   * Switch homepage to launchpad.net/libeatmydata.
diff -Nru libeatmydata-26/debian/patches/Make_sync_fct_cancellation_points.diff libeatmydata-26/debian/patches/Make_sync_fct_cancellation_points.diff
--- libeatmydata-26/debian/patches/Make_sync_fct_cancellation_points.diff	1970-01-01 01:00:00.0 +0100
+++ libeatmydata-26/debian/patches/Make_sync_fct_cancellation_points.diff	2013-06-28 02:31:55.0 +0200
@@ -0,0 +1,38 @@
+Description: Make (f|m|fdata)sync functions cancellation points
+
+fsync(), msync() and fdatasync() functions are supposed to be cancellation
+points according to POSIX specification, as can be seen in pthreads (7).
+Current libeatmydata does not respect this part of the specification and
+this patch fixes that.
+
+Author: Thomas Preud'homme robo...@debian.org
+Bug-Debian: http://bugs.debian.org/713035
+Forwarded: no
+Last-Update: 2013-06-28
+
+--- libeatmydata-26.orig/eatmydata.c
 libeatmydata-26/eatmydata.c
+@@ -81,6 +81,7 @@ int fsync(int fd)
+ 		errno= 0;
+ 		return 0;
+ 	}
++	pthread_testcancel();
+ 
+ 	return (*libc_fsync)(fd);
+ }
+@@ -126,6 +127,7 @@ int fdatasync(int fd)
+ 		errno= 0;
+ 		return 0;
+ 	}
++	pthread_testcancel();
+ 
+ 	return (*libc_fdatasync)(fd);
+ }
+@@ -136,6 +138,7 @@ int msync(void *addr, size_t length, int
+ 		errno= 0;
+ 		return 0;
+ 	}
++	pthread_testcancel();
+ 
+ 	return (*libc_msync)(addr, length, flags);
+ }
diff -Nru libeatmydata-26/debian/patches/series libeatmydata-26/debian/patches/series
--- libeatmydata-26/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ libeatmydata-26/debian/patches/series	2013-06-28 02:28:53.0 +0200
@@ -0,0 +1 @@
+Make_sync_fct_cancellation_points.diff


signature.asc
Description: This is a digitally signed message part.

Bug#713885: im-config: Sourcing of 20_ibus.rc fails when shell is zsh

[Thomas Preud'homme]

Package: im-config
Version: 0.22-2
Severity: normal
Tags: patch upstream

It seems that 20_ibus.rc is ultimately sourced by the user's shell. I
couldn't find what script seems to source Xsession but the behavior of:

ls /usr/lib/*/gtk-2.0/*/immodules/im-ibus.so \
/usr/lib/gtk-2.0/*/immodules/im-ibus.so 2/dev/null || true

is to not run ls at all because the second line doesn't match any path
on my system. This is the normal behavior of zsh but dash (which /bin/sh
is linked too on my system) would output
/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-ibus.so on my
system.

The attached patch makes the sourcing work when the shell is zsh and
should work too for other shell (at least bourne shells).

Best regards.

-- System Information:
Debian Release: jessie/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages im-config depends on:
ii  dialog1.2-20130523-1
ii  gettext-base  0.18.1.1-10
ii  zenity3.8.0-1

Versions of packages im-config recommends:
ii  dialog  1.2-20130523-1
ii  x11-common  1:7.7+3

im-config suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/share/im-config/data/20_ibus.rc (from im-config 
package)
diff -Nru im-config-0.22/debian/changelog im-config-0.22/debian/changelog
--- im-config-0.22/debian/changelog	2013-06-04 16:36:39.0 +0200
+++ im-config-0.22/debian/changelog	2013-06-23 15:52:21.0 +0200
@@ -1,3 +1,10 @@
+im-config (0.22-3.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Fix sourcing of data/20_ibus.rc in zsh shell. Closes: #713885
+
+ -- Thomas Preud'homme robo...@debian.org  Sun, 23 Jun 2013 15:51:15 +0200
+
 im-config (0.22-3) unstable; urgency=low
 
   * Fix typo regression in 0.22-2. Closes: #710969
diff -Nru im-config-0.22/debian/patches/fix_sourcing_ibus.rc_from_zsh.diff im-config-0.22/debian/patches/fix_sourcing_ibus.rc_from_zsh.diff
--- im-config-0.22/debian/patches/fix_sourcing_ibus.rc_from_zsh.diff	1970-01-01 01:00:00.0 +0100
+++ im-config-0.22/debian/patches/fix_sourcing_ibus.rc_from_zsh.diff	2013-06-23 16:06:00.0 +0200
@@ -0,0 +1,69 @@
+Description: Fix sourcing 20_ibus.rc from zsh
+ When a user starts an X session, 20_ibus.rc is sourced ultimately by
+ XSession script which runs with the user's shell (probably because it's
+ itself sourced instead of being executed). But when the user's shell is zsh,
+ the ls /usr/lib/*/foo/* /usr/lib/foo/* does not output anything because in zsh
+ when a wildcard does not match any path the command is not executed.
+ Therefore, the markers are not exported and (GTK|QT4)_IM_MODULE is not
+ exported which leads to dead letters not functionning because ibus is running
+ but not used.
+Author: Thomas Preud'homme robo...@debian.org
+Bug-Debian: http://bugs.debian.org/713885
+
+---
+Origin: vendor
+Bug-Debian: http://bugs.debian.org/713885
+Forwarded: no
+Last-Update: 2013-06-23
+
+--- im-config-0.22.orig/data/20_ibus.rc
 im-config-0.22/data/20_ibus.rc
+@@ -13,8 +13,8 @@ XMODIFIERS=@im=ibus
+ GTK_IM_MODULE=xim
+ # use immodule only when available for both GTK 2.0 and 3.0
+ IM_CONFIG_MARKER2=0
+-for IM_CONFIG_MARKER in $(ls /usr/lib/*/gtk-2.0/*/immodules/im-ibus.so \
+-/usr/lib/gtk-2.0/*/immodules/im-ibus.so 2/dev/null || true); do
++for IM_CONFIG_MARKER in $({ ls /usr/lib/*/gtk-2.0/*/immodules/im-ibus.so; \
++ls /usr/lib/gtk-2.0/*/immodules/im-ibus.so } 2/dev/null || true); do
+ if [ -e $IM_CONFIG_MARKER ]; then
+ IM_CONFIG_MARKER2=1
+ break
+@@ -22,21 +22,22 @@ for IM_CONFIG_MARKER in $(ls /usr/lib/*/
+ done
+ 
+ IM_CONFIG_MARKER3=0
+-for IM_CONFIG_MARKER in $(ls /usr/lib/*/gtk-3.0/*/immodules/im-ibus.so \
+-/usr/lib/gtk-3.0/*/immodules/im-ibus.so 2/dev/null||true); do
++for IM_CONFIG_MARKER in $({ ls /usr/lib/*/gtk-3.0/*/immodules/im-ibus.so; \
++ls /usr/lib/gtk-3.0/*/immodules/im-ibus.so } 2/dev/null || true); do
+ if [ -e $IM_CONFIG_MARKER ]; then
+ IM_CONFIG_MARKER3=1
+ break
+ fi
+ done
++
+ if [ $IM_CONFIG_MARKER2 = 1 ]  [ $IM_CONFIG_MARKER3 = 1 ] ; then
+ GTK_IM_MODULE=ibus
+ fi
+ 
+ QT4_IM_MODULE=xim
+ # use immodule when available for Qt4 (Qt3 has been long dead)
+-for IM_CONFIG_MARKER in $(ls /usr/lib/*/qt4/plugins/inputmethods/libqtim-ibus.so\
+-/usr/lib/qt4/plugins/inputmethods/libqtim-ibus.so 2/dev/null||true) ; do
++for IM_CONFIG_MARKER in $({ ls /usr/lib/*/qt4/plugins/inputmethods/libqtim-ibus.so; \
++ls /usr/lib/qt4/plugins/inputmethods/libqtim-ibus.so } 2/dev/null || true) ; do
+ if [ -e

Bug#713885: im-config: Sourcing of 20_ibus.rc fails when shell is zsh

[Thomas Preud'homme]

Le dimanche 23 juin 2013 16:21:22, Thomas Preud'homme a écrit :
 Package: im-config
 Version: 0.22-2
 Severity: normal
 Tags: patch upstream
 
 It seems that 20_ibus.rc is ultimately sourced by the user's shell. I
 couldn't find what script seems to source Xsession but the behavior of:
 
 ls /usr/lib/*/gtk-2.0/*/immodules/im-ibus.so \
 /usr/lib/gtk-2.0/*/immodules/im-ibus.so 2/dev/null || true
 
 is to not run ls at all because the second line doesn't match any path
 on my system. This is the normal behavior of zsh but dash (which /bin/sh
 is linked too on my system) would output
 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-ibus.so on my
 system.

So it seems that:

1) 20_bus.rc is read both by /bin/sh and by zsh on my system. It's probably 
executed at some point and sourced by my shell later.

2) my patch doesn't work for dash since I couldn't boot with it.
 
 The attached patch makes the sourcing work when the shell is zsh and
 should work too for other shell (at least bourne shells).

Find an updated patch which work with both /bin/sh and zsh.

Best regards,

Thomas
diff -Nru im-config-0.22/debian/changelog im-config-0.22/debian/changelog
--- im-config-0.22/debian/changelog	2013-06-04 16:36:39.0 +0200
+++ im-config-0.22/debian/changelog	2013-06-23 15:52:21.0 +0200
@@ -1,3 +1,10 @@
+im-config (0.22-3.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Fix sourcing of data/20_ibus.rc in zsh shell. Closes: #713885
+
+ -- Thomas Preud'homme robo...@debian.org  Sun, 23 Jun 2013 15:51:15 +0200
+
 im-config (0.22-3) unstable; urgency=low
 
   * Fix typo regression in 0.22-2. Closes: #710969
diff -Nru im-config-0.22/debian/patches/fix_sourcing_ibus.rc_from_zsh.diff im-config-0.22/debian/patches/fix_sourcing_ibus.rc_from_zsh.diff
--- im-config-0.22/debian/patches/fix_sourcing_ibus.rc_from_zsh.diff	1970-01-01 01:00:00.0 +0100
+++ im-config-0.22/debian/patches/fix_sourcing_ibus.rc_from_zsh.diff	2013-06-23 16:06:00.0 +0200
@@ -0,0 +1,69 @@
+Description: Fix sourcing 20_ibus.rc from zsh
+ When a user starts an X session, 20_ibus.rc is sourced ultimately by
+ XSession script which runs with the user's shell (probably because it's
+ itself sourced instead of being executed). But when the user's shell is zsh,
+ the ls /usr/lib/*/foo/* /usr/lib/foo/* does not output anything because in zsh
+ when a wildcard does not match any path the command is not executed.
+ Therefore, the markers are not exported and (GTK|QT4)_IM_MODULE is not
+ exported which leads to dead letters not functionning because ibus is running
+ but not used.
+Author: Thomas Preud'homme robo...@debian.org
+Bug-Debian: http://bugs.debian.org/713885
+
+---
+Origin: vendor
+Bug-Debian: http://bugs.debian.org/713885
+Forwarded: no
+Last-Update: 2013-06-23
+
+--- im-config-0.22.orig/data/20_ibus.rc
 im-config-0.22/data/20_ibus.rc
+@@ -13,8 +13,8 @@ XMODIFIERS=@im=ibus
+ GTK_IM_MODULE=xim
+ # use immodule only when available for both GTK 2.0 and 3.0
+ IM_CONFIG_MARKER2=0
+-for IM_CONFIG_MARKER in $(ls /usr/lib/*/gtk-2.0/*/immodules/im-ibus.so \
+-/usr/lib/gtk-2.0/*/immodules/im-ibus.so 2/dev/null || true); do
++for IM_CONFIG_MARKER in $( (ls /usr/lib/*/gtk-2.0/*/immodules/im-ibus.so; \
++ls /usr/lib/gtk-2.0/*/immodules/im-ibus.so) 2/dev/null || true); do
+ if [ -e $IM_CONFIG_MARKER ]; then
+ IM_CONFIG_MARKER2=1
+ break
+@@ -22,21 +22,22 @@ for IM_CONFIG_MARKER in $(ls /usr/lib/*/
+ done
+ 
+ IM_CONFIG_MARKER3=0
+-for IM_CONFIG_MARKER in $(ls /usr/lib/*/gtk-3.0/*/immodules/im-ibus.so \
+-/usr/lib/gtk-3.0/*/immodules/im-ibus.so 2/dev/null||true); do
++for IM_CONFIG_MARKER in $( (ls /usr/lib/*/gtk-3.0/*/immodules/im-ibus.so; \
++ls /usr/lib/gtk-3.0/*/immodules/im-ibus.so) 2/dev/null || true); do
+ if [ -e $IM_CONFIG_MARKER ]; then
+ IM_CONFIG_MARKER3=1
+ break
+ fi
+ done
++
+ if [ $IM_CONFIG_MARKER2 = 1 ]  [ $IM_CONFIG_MARKER3 = 1 ] ; then
+ GTK_IM_MODULE=ibus
+ fi
+ 
+ QT4_IM_MODULE=xim
+ # use immodule when available for Qt4 (Qt3 has been long dead)
+-for IM_CONFIG_MARKER in $(ls /usr/lib/*/qt4/plugins/inputmethods/libqtim-ibus.so\
+-/usr/lib/qt4/plugins/inputmethods/libqtim-ibus.so 2/dev/null||true) ; do
++for IM_CONFIG_MARKER in $( (ls /usr/lib/*/qt4/plugins/inputmethods/libqtim-ibus.so; \
++ls /usr/lib/qt4/plugins/inputmethods/libqtim-ibus.so) 2/dev/null || true) ; do
+ if [ -e $IM_CONFIG_MARKER ]; then
+ QT4_IM_MODULE=ibus
+ break
+@@ -45,8 +46,8 @@ done
+ 
+ CLUTTER_IM_MODULE=xim
+ # use immodule when available for clutter
+-for IM_CONFIG_MARKER in $(ls /usr/lib/*/clutter-imcontext/immodules/im-ibus.so \
+-/usr/lib/clutter-imcontext/immodules/im-ibus.so 2/dev/null||true); do
++for IM_CONFIG_MARKER in $( (ls /usr/lib/*/clutter-imcontext/immodules/im-ibus.so

Bug#713885: im-config: Sourcing of 20_ibus.rc fails when shell is zsh

[Thomas Preud'homme]

Le dimanche 23 juin 2013 18:43:14, Osamu Aoki a écrit :
 Hi,
 
 On Sun, Jun 23, 2013 at 05:17:56PM +0200, Thomas Preud'homme wrote:
  Le dimanche 23 juin 2013 16:21:22, Thomas Preud'homme a écrit :
   Package: im-config
   Version: 0.22-2
   Severity: normal
   Tags: patch upstream
   
   It seems that 20_ibus.rc is ultimately sourced by the user's shell.
 
 Really?  Why?

I don't know, as said I didn't manage to track down the cause. Maybe I'm wrong 
and it's executed by sh but the ls was not working on my system (the loop was 
not entered) exactly like zsh would. I assumed it was because the script is 
run at some point by zsh but I might be wrong and maybe dash act differently 
when sourcing something than when run in interactive mode (I made my debugging 
with dash in interactive mode).

 
 im-config is bash script.

Being sourced ultimately by /etc/X11/Xsession.d/70im-config_launch, it should 
be a sh script.

 
 Isn't your X boot process uses /bin/sh?

It does I think since the first version of the patch was not working with dash 
and prevented me from booting. As I said, somehow the file is read twice.

 
 There is no need to read im-config related file from .profile etc.

I didn't do anything of that sort. As far as X is concerned, my system is 
untouched (at least AFAIK).

I tried to display /proc/$PPID/exe from that file and redirecting the output 
in a file on /tmp but the file was empty so I can't know for sure what's 
happening exactly.

Best regards,

Thomas


signature.asc
Description: This is a digitally signed message part.

Bug#713885: im-config: Sourcing of 20_ibus.rc fails when shell is zsh

[Thomas Preud'homme]

Le dimanche 23 juin 2013 18:52:24, Thomas Preud'homme a écrit :
 Le dimanche 23 juin 2013 18:43:14, Osamu Aoki a écrit :
  On Sun, Jun 23, 2013 at 05:17:56PM +0200, Thomas Preud'homme wrote:
It seems that 20_ibus.rc is ultimately sourced by the user's shell.
  
  Really?  Why?
 
 I don't know, as said I didn't manage to track down the cause. Maybe I'm
 wrong and it's executed by sh but the ls was not working on my system (the
 loop was not entered) exactly like zsh would. I assumed it was because the
 script is run at some point by zsh but I might be wrong and maybe dash act
 differently when sourcing something than when run in interactive mode (I
 made my debugging with dash in interactive mode).

Ok, it seems it's kdm's fault. If you look at the file /etc/kde4/kdm/Xsession, 
you'll see that it test what is the shell (which suggests that this file is 
not executed but sourced, despite the shebang) and at the end it source 
/etc/X11/Xsession. I couldn't find where is /etc/kde4/kdm/Xsession sourced yet 
but to me it seems it's sourced and then it source Xsession which eventually 
sources 20_ibus.rc.

I let it up to you to reassign to kdm, in which case the patch tags ought to 
be removed.

Best regards,

Thomas


signature.asc
Description: This is a digitally signed message part.

Bug#713885: im-config: Sourcing of 20_ibus.rc fails when shell is zsh

[Thomas Preud'homme]

Le dimanche 23 juin 2013 21:21:31, Thomas Preud'homme a écrit :
 Le dimanche 23 juin 2013 18:52:24, Thomas Preud'homme a écrit :
  Le dimanche 23 juin 2013 18:43:14, Osamu Aoki a écrit :
   On Sun, Jun 23, 2013 at 05:17:56PM +0200, Thomas Preud'homme wrote:
 It seems that 20_ibus.rc is ultimately sourced by the user's shell.
   
   Really?  Why?
  
  I don't know, as said I didn't manage to track down the cause. Maybe I'm
  wrong and it's executed by sh but the ls was not working on my system
  (the loop was not entered) exactly like zsh would. I assumed it was
  because the script is run at some point by zsh but I might be wrong and
  maybe dash act differently when sourcing something than when run in
  interactive mode (I made my debugging with dash in interactive mode).
 
 Ok, it seems it's kdm's fault. If you look at the file
 /etc/kde4/kdm/Xsession, you'll see that it test what is the shell (which
 suggests that this file is not executed but sourced, despite the shebang)
 and at the end it source /etc/X11/Xsession. I couldn't find where is
 /etc/kde4/kdm/Xsession sourced yet but to me it seems it's sourced and
 then it source Xsession which eventually sources 20_ibus.rc.

Sorry for the spam but I just found it. It was just in front of me. 
/etc/kde4/kdm/Xsession contains the following excerpt:

case $SHELL in
[SNIP bash case]
  */zsh)
[ -z $ZSH_NAME ]  exec $SHELL $0 $@
emulate -R zsh

I've seen several occurences in kdm's code to set the SHELL environment 
variable. So later Xsession is executed, $SHELL is detected to be zsh so it 
exec zsh /etc/kde4/kdm/Xsession $otherargs which set zsh to zsh emulation mode 
and then source /etc/X11/Xsession. I suppose the bug could be fixed by setting 
zsh to sh emulate mode.

 
 I let it up to you to reassign to kdm, in which case the patch tags ought
 to be removed.

Let me know if you want me to do it instead.

Best regards,

Thomas


signature.asc
Description: This is a digitally signed message part.

Bug#709002: [pdfsam] unable to load java after upgrade

[Thomas Preud'homme]

Le lundi 20 mai 2013 08:39:20, Marco Righi a écrit :
 08:35:09,411 FATAL GuiClient  Error:
 java.lang.NoClassDefFoundError: com/jgoodies/common/base/SystemUtils
 at java.lang.ClassLoader.defineClass1(Native Method)
 at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
 at
 java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
 at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
 at java.net.URLClassLoader.access$000(URLClassLoader.java:73)
 at java.net.URLClassLoader$1.run(URLClassLoader.java:212)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
 at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
 at
 com.jgoodies.looks.plastic.PlasticLookAndFeel.clinit(PlasticLookAndFeel.j
 ava:137) at
 org.pdfsam.guiclient.utils.ThemeUtility.setTheme(ThemeUtility.java:160)
 at
 org.pdfsam.guiclient.configuration.Configuration.setLookAndFeel(Configurati
 on.java:192) at
 org.pdfsam.guiclient.configuration.Configuration.init(Configuration.java:16
 9) at
 org.pdfsam.guiclient.configuration.Configuration.init(Configuration.java:
 54) at
 org.pdfsam.guiclient.configuration.Configuration.getInstance(Configuration.
 java:59) at
 org.pdfsam.guiclient.gui.frames.JMainFrame.init(JMainFrame.java:90)
 at org.pdfsam.guiclient.GuiClient.main(GuiClient.java:61)

To all those who have this problem, it can be avoided by setting the theme 
(theme) and look and feel (LAF) to 0 in .pdfsam/config.xml.

Best regards,

Thomas Preud'homme


signature.asc
Description: This is a digitally signed message part.

Bug#709002: reassign 709002 to libjgoodies-looks-java

[Thomas Preud'homme]

Le jeudi 30 mai 2013 15:53:10, tony mancill a écrit :
 On 05/30/2013 06:47 AM, Thomas Preud'homme wrote:
  reassign 709002 libjgoodies-looks-java
  thanks
  
  A ClassNotFoundException poped up in pdfjam but it seems to me to be
  a problem of libjgoodies-looks-java not specifying the jar for
  libjgoodies-common-java in its classpath.
 
 Thank you Thomas, I'll take a look.

Great. I've found that lib.common.jar is defined to the correct location of 
jgoodies-common.jar but it doesn't seem that lib.common.jar is a special 
property so I have the feeling this is useless.

 
 Regards,
 tony

Best regards,

Thomas


signature.asc
Description: This is a digitally signed message part.

Bug#698732: dspam external map does not work with TLS enabled

[Thomas Preud'homme]

Le mercredi 29 mai 2013 08:16:24, Jason a écrit :
 Hi
 
 I noticed Weezy has been released. Did the fixes for DSPAM make it in?

Not this one. As said before I don't intend to add this patch to the packaging 
as long as upstream don't accept it. Since the project seems a bit silent 
these days, I wouldn't hold my breath.  Besides, the patch was made during the 
freeze before the release and such a patch couldn't have been accepted at this 
stage because it doesn't fix an issue serious enough.

I've just (finally) built the package and uploaded it to my personal repository 
if you want to try.

To use my repository, add the following line to your sources.list (or add a 
file containing this line in /etc/apt/sources.list.d):

deb [ arch=amd64 ] http://people.debian.org/~robotux/pkgs/ unstable main

That means only packages for the amd64 architecture are available. If you need 
i386, please let me know. The  version of the packages contained in this 
repository are chosen so that when/if the packages will be uploaded to the 
Debian official archive, it will migrate seamlessly to them.

Before installing anything, you should check the PGP key that signs the 
archive. Run all the following steps (1-4) as root

1) First, import the key in a new keyring (robotux.gpg):

gpg --no-default-keyring --keyring /etc/apt/trusted.gpg.d/robotux.gpg --recv-
keys E851CC9AE4743BA4

2) Then check the signature of this key is fine. It's signed by my key which is 
in the debian keyring containing the keys of debian developers so we need to 
install the debian keyring:

aptitude install debian-keyring

3) gpg --no-default-keyring --keyring /etc/apt/trusted.gpg.d/robotux.gpg --
keyring /usr/share/keyrings/debian-keyring.gpg --check-sigs E851CC9AE4743BA4

if a ! (exclamation mark) follows sig it means the signature was correctly 
verified. You should have 2 signatures, the self signature and the one from my 
Debian Developer's key:

sig!3E4743BA4 2013-03-29  Thomas Preud'homme APT archive 
robo...@debian.org
sig! BD52529E 2013-03-29  Thomas Preud'homme (RoboTux) 
robo...@celest.fr

You can then proceed and import the key in the apt keyring:

4) gpg --no-default-keyring --keyring /etc/apt/trusted.gpg.d/robotux.gpg --
export E851CC9AE4743BA4 | apt-key add -


You can now update your apt database and upgrade dspam:

aptitude update
aptitude safe-upgrade

Best regards,

Thomas


signature.asc
Description: This is a digitally signed message part.

Bug#704940: Bug#705552: unblock: subversion/1.6.17dfsg-4+deb7u2

[Thomas Preud'homme]

Le jeudi 18 avril 2013 14:38:15, Adam D. Barratt a écrit :
 
 Upstream appear to believe it {does,should}n't -
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704940#32

Oh good. I hadn't time to look at that yet. Should I upload the NMU then?

 
 Regards,
 
 Adam

Best regards,

Thomas


signature.asc
Description: This is a digitally signed message part.

Bug#704940: Bug#705552: unblock: subversion/1.6.17dfsg-4+deb7u2

[Thomas Preud'homme]

Le jeudi 18 avril 2013 21:46:18, Adam D. Barratt a écrit :
 Control: tags 705552 + confirmed
 
 On Thu, 2013-04-18 at 14:54 +0200, Thomas Preud'homme wrote:
  Le jeudi 18 avril 2013 14:38:15, Adam D. Barratt a écrit :
   Upstream appear to believe it {does,should}n't -
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704940#32
  
  Oh good. I hadn't time to look at that yet. Should I upload the NMU then?
 
 Please go ahead; thanks.

Done.

 
 Regards,
 
 Adam

Thanks.

Thomas


signature.asc
Description: This is a digitally signed message part.

Bug#683054: /usr/games/torus-trooper-pure: torus-trooper(-pure) segfaults at startup on armhf

[Thomas Preud'homme]

Le samedi 28 juillet 2012 09:42:46, Thomas Preud'homme a écrit :
 Package: torus-trooper-pure
 Version: 0.22.dfsg1-8
 Severity: normal
 File: /usr/games/torus-trooper-pure
 
 torus-trooper and torus-trooper-pure segfaults on my Toshiba AC100
 running Debian armhf. It runs fine on my computer running amd64 so it
 might be architecture specific. Here is the stacktrace I could gather:

Since I don't have hardware acceleration on that laptop I suppose the bug come 
from here. I'm just surprised a SEGFAULT happens instead of just an error but 
you can close the bug if you feel it's not a problem.

Best regards,

Thomas


signature.asc
Description: This is a digitally signed message part.

Bug#705552: unblock: subversion/1.6.17dfsg-4+deb7u2

[Thomas Preud'homme]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package subversion

I prepared an upload targetting wheezy fixing #683188 and #704940.

For #704940 I took the patch from the corresponding CVE entries
(CVE-2013-1845, CVE-2013-1846, CVE-2013-1847, CVE-2013-1849). There is
no patch for CVE-2013-1884 since it doesn't affect the version in
wheezy.

Concerning #683188, I just refreshed the patch used in unstable for it
to apply on wheezy's version.

unblock subversion/1.6.17dfsg-4+deb7u2

-- System Information:
Debian Release: 7.0
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'stable-updates'), (500, 'testing'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -u subversion-1.6.17dfsg/debian/changelog subversion-1.6.17dfsg/debian/changelog
--- subversion-1.6.17dfsg/debian/changelog
+++ subversion-1.6.17dfsg/debian/changelog
@@ -1,3 +1,16 @@
+subversion (1.6.17dfsg-4+deb7u2) wheezy; urgency=low
+
+  * Non-maintainer upload.
+  * Include following security fixes (Closes: #704940):
+- CVE-2013-1845: Remotely triggered memory exhaustion in mod_dav_svn
+- CVE-2013-1846: Remotely triggered crash in mod_dav_svn
+- CVE-2013-1847: Remotely triggered crash in mod_dav_svn
+- CVE-2013-1849: Remotely triggered crash in mod_dav_svn
+  * Convert SVN_STREAM_CHUNK_SIZE to an integer in svn/core.py
+(Closes: #683188).
+
+ -- Thomas Preud'homme robo...@debian.org  Tue, 16 Apr 2013 14:36:14 +0200
+
 subversion (1.6.17dfsg-4+deb7u1) wheezy; urgency=low
 
   * Non-maintainer upload.
diff -u subversion-1.6.17dfsg/debian/patches/series subversion-1.6.17dfsg/debian/patches/series
--- subversion-1.6.17dfsg/debian/patches/series
+++ subversion-1.6.17dfsg/debian/patches/series
@@ -36,0 +37,4 @@
+chunksize-integer.patch
+cve-2013-1845
+cve-2013-1846
+cve-2013-1849
only in patch2:
unchanged:
--- subversion-1.6.17dfsg.orig/debian/patches/cve-2013-1849
+++ subversion-1.6.17dfsg/debian/patches/cve-2013-1849
@@ -0,0 +1,39 @@
+Author: Philip Martin philip.mar...@wandisco.com
+Subject: Reject operations on prop if the resource is an activity
+
+Subversion's mod_dav_svn Apache HTTPD server module will crash when
+a PROPFIND request is made against activity URLs. The patch consists
+in rejecting operations on getcontentlength and getcontenttype
+properties if the resource is an activity.
+
+Origin: upstream, commit:r1453780
+Bug-CVE: http://subversion.apache.org/security/CVE-2013-1849-advisory.txt
+Bug-Debian: http://bugs.debian.org/704940
+Last-Update: 2013-04-16
+Applied-Upstream: commit:r1453780
+
+Index: subversion/mod_dav_svn/liveprops.c
+===
+--- a/subversion/mod_dav_svn/liveprops.c	(revision 1458455)
 b/subversion/mod_dav_svn/liveprops.c	(working copy)
+@@ -410,7 +410,8 @@ insert_prop_internal(const dav_resource *resource,
+ svn_filesize_t len = 0;
+ 
+ /* our property, but not defined on collection resources */
+-if (resource-collection || resource-baselined)
++if (resource-type == DAV_RESOURCE_TYPE_ACTIVITY
++|| resource-collection || resource-baselined)
+   return DAV_PROP_INSERT_NOTSUPP;
+ 
+ serr = svn_fs_file_length(len, resource-info-root.root,
+@@ -434,7 +435,9 @@ insert_prop_internal(const dav_resource *resource,
+ svn_string_t *pval;
+ const char *mime_type = NULL;
+ 
+-if (resource-baselined  resource-type == DAV_RESOURCE_TYPE_VERSION)
++if (resource-type == DAV_RESOURCE_TYPE_ACTIVITY
++|| (resource-baselined
++ resource-type == DAV_RESOURCE_TYPE_VERSION))
+   return DAV_PROP_INSERT_NOTSUPP;
+ 
+ if (resource-type == DAV_RESOURCE_TYPE_PRIVATE
only in patch2:
unchanged:
--- subversion-1.6.17dfsg.orig/debian/patches/cve-2013-1845
+++ subversion-1.6.17dfsg/debian/patches/cve-2013-1845
@@ -0,0 +1,189 @@
+Author: Philip Martin philip.mar...@wandisco.com
+Subject: Introduce a subpool to control memory use
+
+Setting or deleting a large number of properties on a node (file or
+directory)  will result in a large amount of memory use.  Due to the
+memory pooling behavior of Apache httpd and Subversion the completion of
+the request will not result in the immediate release of memory used.
+Repeated commits with the same properties will result in each httpd process
+plateauing out at some amount of memory.  This could result in a Denial of
+Service if the system is exhausted of all available memory.
+
+Origin: upstream, commit:r1443929
+Bug-CVE: http://subversion.apache.org/security/CVE-2013-1845-advisory.txt
+Bug-Debian: http://bugs.debian.org/704940
+Last-Update: 2013-04-16
+Applied-Upstream: commit:r1443929
+
+
+Index: subversion

Bug#698732: dspam external map does not work with TLS enabled

[Thomas Preud'homme]

Le jeudi 11 avril 2013 10:59:28, Jason Johnson a écrit :
 Wonderful. Tranks for your help!  For now I would need a special repo for
 it. I'm currently using DSPAM in Squeeze via the backports repo.

Alright, I'll provide you a version you can upgrade from backport without 
using the version from wheezy.

 
 Thanks again,
 Jason

I'll keep you informed.

Best regards,

Thomas


signature.asc
Description: This is a digitally signed message part.

Bug#705169: RFH: iproute2 -- networking and traffic control tools

[Thomas Preud'homme]

Le mercredi 10 avril 2013 21:33:32, Andreas Henriksson a écrit :
 Package: wnpp
 Severity: normal
 
 I request assistance with maintaining the iproute2 package.
 
 Help is welcome in all areas, but following ones would be
 extra appreciated:
 
 Please perform a full source scan and document all licensing information.
 As requested by ftp-masters.
 

I didn't find a bug report mentionning this request. Is there a place
mentionning it where progress to review the licensing could be posted?

I'm willing to help on this point. I might have some time this WE to start
looking at it.

Best regards,

Thomas


signature.asc
Description: This is a digitally signed message part.

Bug#705015: ITP: ie7-js -- help Internet Explorer behave like a standards-compliant browser

[Thomas Preud'homme]

Le lundi 8 avril 2013 23:35:42, David Prévot a écrit :
 Hi,
 
 Le 08/04/2013 16:41, Jonas Smedegaard a écrit :
  For general use I believe, however, that html5shiv has proven a better
  shim.  It is part of Modernizr already packaged for Debian.
 
 AFAICT, html5shiv is not in Debian, nor part of the modernizr package.
 Did I miss something?

Seems to be part of usr/share/javascript/modernizr/modernizr.js from line 1006 
onwards.

 
 Regards
 
 David

Best regards,

Thomas


signature.asc
Description: This is a digitally signed message part.

Bug#698732: dspam external map does not work with TLS enabled

[Thomas Preud'homme]

Le samedi 2 mars 2013 09:34:32, Jason a écrit :
 I think we've already figured it out. The problem is that DSPAM currently
 only supports TLS via STARTTLS but I'm using ldaps which is a different
 protocol. I would have submitted a patch already but I currently don't
 have a Linux dev environment to do the build on (only a server which, for
 security reasons I don't want things like compilers on).

I think *you* had already figured it out ;)

 
 All that needs to happen is the field where you specify ldap or
 database needs to also accept ldaps and put what ever is in that field
 as the schema. Then the ldap library will do the right thing.

So here's the patch. I'll open a bug upstream to ask them to integrate it. 
Don't expect miracles though: the last commit in the upstream git repository 
was in august 2012. If nobody answer within 2 months, I might consider to 
include it in Debian anyway given the small size of the patch (most of the 
diff is just increasing the indentation).

Any testing on your side would be appreciated. I can provide you deb packages 
in my personal repository if you need.

Best regards,

Thomas
diff --git a/src/external_lookup.c b/src/external_lookup.c
index 4f8e10e..eaf48e0 100644
--- a/src/external_lookup.c
+++ b/src/external_lookup.c
@@ -164,7 +164,7 @@ ldap_lookup(config_t agent_config, const char *username, char *external_uid)
 	struct		timeval	ldaptimeout = {.tv_sec = BIND_TIMEOUT, .tv_usec = 0};
 	int			i, rc=0, num_entries=0;
 	char		*transcoded_query = NULL;
-	char		*ldap_uri = NULL;
+	char		*ldap_uris[2] = {NULL, NULL}; // 0 = ldap, 1 = ldaps
 	char		*end_ptr;
 	char		*ldap_host = _ds_read_attribute(agent_config, ExtLookupServer);
 	char		*port = _ds_read_attribute(agent_config, ExtLookupPort);
@@ -249,30 +249,43 @@ ldap_lookup(config_t agent_config, const char *username, char *external_uid)
 		url.lud_port = ldap_port;
 		url.lud_scope = LDAP_SCOPE_SUBTREE;
 
-		ldap_uri = ldap_url_desc2str( url );
-	}
+		ldap_uris[0] = ldap_url_desc2str( url );
 
-	rc = ldap_initialize( ld, ldap_uri );
-	if( rc != LDAP_SUCCESS ) {
-		LOG(LOG_ERR, External Lookup: Could not create LDAP session handle for URI=%s (%d): %s\n, ldap_uri, rc, ldap_err2string(rc));
-		return NULL;
-	}
+		url.lud_scheme = ldaps;
+		url.lud_host = ldap_host;
+		url.lud_port = ldap_port;
+		url.lud_scope = LDAP_SCOPE_SUBTREE;
 
-	if( ldap_set_option( ld, LDAP_OPT_PROTOCOL_VERSION, ldap_version ) != LDAP_OPT_SUCCESS ) {
-		LOG(LOG_ERR, External Lookup: Could not set LDAP_OPT_PROTOCOL_VERSION %d\n, ldap_version );
-		return NULL;
+		ldap_uris[1] = ldap_url_desc2str( url );
 	}
 
-	/* use TLS if configured */
-	if ( _ds_match_attribute(agent_config, ExtLookupCrypto, tls )) {
-		if (ldap_version != 3) {
-			LOG(LOG_ERR, External Lookup: TLS only supported with LDAP protocol version 3);
+	/* Try ldap then ldaps */
+	for (i = 0; i  2; i++) {
+		rc = ldap_initialize( ld, ldap_uris[i] );
+		if( rc != LDAP_SUCCESS ) {
+			LOG(LOG_ERR, External Lookup: Could not create LDAP session handle for URI=%s (%d): %s\n, ldap_uris[i], rc, ldap_err2string(rc));
 			return NULL;
 		}
-		if ( ldap_start_tls_s( ld, NULL, NULL ) != LDAP_SUCCESS ) {
-			LOG(LOG_ERR, External Lookup: %s: %s (%d), ERR_EXT_LOOKUP_INIT_FAIL, strerror(errno), errno);
+
+		if( ldap_set_option( ld, LDAP_OPT_PROTOCOL_VERSION, ldap_version ) != LDAP_OPT_SUCCESS ) {
+			LOG(LOG_ERR, External Lookup: Could not set LDAP_OPT_PROTOCOL_VERSION %d\n, ldap_version );
 			return NULL;
 		}
+
+		/* use TLS if configured */
+		if ( _ds_match_attribute(agent_config, ExtLookupCrypto, tls )) {
+			if (ldap_version != 3) {
+LOG(LOG_ERR, External Lookup: TLS only supported with LDAP protocol version 3);
+return NULL;
+			}
+			if ( ldap_start_tls_s( ld, NULL, NULL ) != LDAP_SUCCESS ) {
+if (!i)
+	continue;
+LOG(LOG_ERR, External Lookup: %s: %s (%d), ERR_EXT_LOOKUP_INIT_FAIL, strerror(errno), errno);
+return NULL;
+			}
+		}
+		break;
 	}
 
 	/* schedules alarm */


signature.asc
Description: This is a digitally signed message part.

Bug#702293: unblock: dspam/3.10.1+dfsg-10

[Thomas Preud'homme]

Le jeudi 4 avril 2013 22:22:34, Adam D. Barratt a écrit :
 Control: tags -1 + confirmed
 
 On Sun, 2013-03-17 at 17:42 +0100, Thomas Preud'homme wrote:
  Le jeudi 7 mars 2013 11:10:33, Thomas Preud'homme a écrit :
   After explaining my problem on IRC, formorer showed me an SQL
   expression that creates plpgsql only if needed. You'll notice that
   plpgsql is created with CREATE LANGUAGE because since PostgreSQL 9,
   plpgsql is created by default. Hence, if it needs to be created the
   old CREATE LANGUAGE construct should be used.
   
   I tried installing dspam with this patch with both PostgreSQL 8.4 from
   Squeeze and PostgreSQL 9.1 from Wheezy with success. Purging works fine
   too.
   
   If this diff suits you, should I rather upload to tpu with a new
   changelog entry as in the attached debdiff or merge the entry in the
   previous one so that only one upload appears to have been done?
  
  Forgive me for resending this, I thought maybe this issue had be
  forgotten. If this is merely a consequence of your work overload, then I
  send you my full apologize.
 
 Please go ahead.
 
 Regards,
 
 Adam

Done. I just added a close for a bug created later about that plpgsql bug.

Best regards,

Thomas


signature.asc
Description: This is a digitally signed message part.

Bug#611190: Works like a charm now

[Thomas Preud'homme]

Le jeudi 22 septembre 2011 15:26:45, Thomas Preud'homme a écrit :
 Hi there,
 
 I tried again today and it now works like a charm. I'm sorry I can't put a
 version in it but anyway, I have the feeling the problem was solved thanks
 to another component change. Thanks for maintaining ibus.

I don't remember what I did in my tests but I supposed I had deactivated ibus 
by mistake. I reinstalled ibus this WE and the problem is still present. I 
managed to make it disappear by installing qt4-qtconfig and running qtconfig to 
set ibus as the input method. It would be nice if qt4-qtconfig could be at 
least recommended by ibus-qt4 and the procedure of running qtconfig documented 
unless it is supposed to work without qtconfig in which case there is a bug.

Best regards,

Thomas


signature.asc
Description: This is a digitally signed message part.