Bug#912099: gnumeric: FTBFS with itstool 2.0.4: 'ascii' codec can't decode byte 0xc2

[Tanguy Ortolo]

Hello,

Niko Tyni, 2018-10-28 11:05+0200:

gnumeric fails to build on current sid/amd64. It seems to have broken
with itstool 2.0.4 in early October or so. From the build log:

 Warning: Could not merge cs translation for msgid:
 The chapters of this version of the Gnumeric manual are 
organized as follows: <_:itemizedlist-1/>
[...]
 Error: Could not merge translations:
 'ascii' codec can't decode byte 0xc2 in position 97: ordinal not in range(128)


I am investigating this, and this seems to be at least linked to the 
fact that the Czech translation is buggy, with several errors in XML 
tags (not closed, opened twice instead of closed…).


I am still checking this, but it does not sound abnormal for itstool to 
fail on invalid XML, in which case I would reassign this bug to Gnumeric 
and provide you with a patch to fix it.


--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: PGP signature

Bug#895688: RFP: libtepl -- a text editor library

[Tanguy Ortolo]

Here is the work, almost finished:
https://salsa.debian.org/gnome-team/tepl

--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: PGP signature

Bug#904643: RFP: amtk -- Actions, Menus and Toolbars Kit library for GTK+ applications

[Tanguy Ortolo]

Hello,

Simon McVittie, 2018-10-10 10:33+0100:

I think the GNOME team would prefer to have new GNOME libraries in the
gnome-team group on Salsa, so that we can update all the packages for a
new GNOME version as a batch. I can create an empty repository for amtk
and make you a Maintainer or Owner there if that would be helpful?


amtk is now in Salsa gnome-team 
<https://salsa.debian.org/gnome-team/amtk> and uploaded, now waiting for 
FTP masters to accept it.


Cheers,

--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: PGP signature

Bug#895688: RFP: libtepl -- a text editor library

[Tanguy Ortolo]

package wnpp
retitle 895688 ITP: libtepl -- a text editor library
thanks

Hello,

I have started packaging tepl, which will be needed for the new version 
of LaTeXila, now renamed GNOME LaTeX.


--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: PGP signature

Bug#904643: RFP: amtk -- Actions, Menus and Toolbars Kit library for GTK+ applications

[Tanguy Ortolo]

package wnpp
retitle 904643 ITP: amtk -- Actions, Menus and Toolbars Kit library for GTK+ 
applications
thanks

Hello,

Being interested as this is a new indirect dependency of my package 
latexila, I have prepared that package. My work can be found at 
<http://git.ortolo.eu/pkg-amtk.git/>. I have yet to determine whether or 
not to make this package part of the GNOME Team packaging, until that, I 
will probably keep working on my repository.


Regards,

--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: PGP signature

Bug#910574: New upstream version 1.8.1

[Tanguy Ortolo]

Package: gspell
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

As a note to myself and to track dependencies to updates of other
packages, there is a new version of gspell, 1.8.1.

- -- System Information:
Debian Release: 8.11
  APT prefers oldstable
  APT policy: (990, 'oldstable'), (500, 'stable-updates'), (500, 
'oldstable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-6-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: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iQJMBAEBCgA2FiEEC1QNJk2lrQnjLj0t6vLNUcUAaBkFAlu7HI8YHHRhbmd1eStk
ZWJpYW5Ab3J0b2xvLmV1AAoJEOryzVHFAGgZq7QP+wcQ//cDI1Qq4dNqW3HHdu+E
PJxJo/la7CZoobqDWbIUQTgHoa3Vvf2jGhmp7agvl7a3XAtXavcODLOiWXKYmSb9
I7XcU/MymjUzVPi7/E4u19Ogn8EC//GLFqxZSz1zK5NkJaYpJ03O7ERaI8UgBtHI
koclNi18qof1EAJTBk01pZhHPvajNLcnPMy/GMBogNgSTw0PXp5NGkhxC6Inz3Gq
8dDc9OdJ76j9mmCC5waZaC23KEXJ9kVVVcteHDXAeRYgs2YodvS+mWDiWRRia3H9
udOeIz7V6Ck5YK+cDZOWrvA6lERb8+AAFLct2QmxnTzwJHscOJMdfU5TF1e98qAk
c9konLAq/48fxvJDIgKrE9NSPPE5Ec0BcmDUtdfR4qOVc0ooTvs9OR1Q/buZvemC
GmkkQfe2F9DdzbHnKIDZY9s0eWKe680oHueP0p9v2p4ZMZDJGZvZqDZHlHjXQBzk
yfluUTHuYDRtQX8b9u4wn2EM9ZlAgxYSNR5gkiLbT+v+hNIsA3cOn1VAuUZ6AXAD
itw3FaEw1ag0gLbVtKD0jCr4twtsaUJ9i8Hq3wx5awudUqyUnW2J5MHQrMy6/wX9
dKltRBBeBGys1XOjXby8CS7akCXI0Bu41ipZOOk3kmSKZOoJMLyUKDim0JV+vzDb
SeupLflnFyA3MyJ4U/5u
=EVm2
-END PGP SIGNATURE-

Bug#910573: New upstream version 3.28

[Tanguy Ortolo]

Package: latexila
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

For myself, and to track dependencies to other packages: there is a new
version of LaTeXila available, now renamed GNOME LaTeX 3.28. It has
updated dependencies which will require some work on other packages.

- -- System Information:
Debian Release: 8.11
  APT prefers oldstable
  APT policy: (990, 'oldstable'), (500, 'stable-updates'), (500, 
'oldstable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-6-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: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iQJMBAEBCgA2FiEEC1QNJk2lrQnjLj0t6vLNUcUAaBkFAlu7GS4YHHRhbmd1eStk
ZWJpYW5Ab3J0b2xvLmV1AAoJEOryzVHFAGgZ4TMQAIKExRfRr/4MYghHZbvtLM6r
TJiDigWF3Pe3pSOyhFn0kF30SUaOTON7GVIYTzjT43Uq3dAta3XN9ENUULOxr7uw
W32du+ANCAlEF4SLPN8T5OyINgSRMBjED8DedcBRdtHV049sBxzp9lKc2zB3AIy7
RLONb58X7euySFHXiJDTecib3pL6XHu5FgkAlgUL0wQc3+UcPWmiZVGl3PN9VOLM
uKtWUm5e0dCI5OAs+fY8b7KRhm5ZUD7tshhtr+o+cfdHelPlu6jW7QDZR762V4dB
3RSoaunKM0rpUjl6nGqV7GBS8rhUoBFrHBQ5ZIgC/PQtfBn2fXwxt1chheDdTpGz
sj50hSs2myp/0mCGJpMUfUAgk1QaX8p2SeKTTDKqr1rR0LwSvpPaY0eARnVtB3hN
fd5h6r9L+jIT3pXfFd9ljnInlBoZdTqpoNEANO5s3Bdld8rYDUrfeWjYk0Vi5hsD
fLGtiOCBDMYgiZ8Ouu9BW2HCe6lM9kxRS6nW0bKZynyUuXIslO/47UTHO/7mVi2s
Oa8JsXVxlg9lCZhPJtdBaw3VRWikyWyV8M+yhJKN5eoOLO1VjfVR8X+NWg7Rcm4A
2bHcO/iMc7q5/JRz2OKWvGQd3+e24+LRVgcUJV8mYMhyf3R5zPcVHvLNln5LPqZ4
k4XisyUqwDKA9ytGHj6t
=0U5y
-END PGP SIGNATURE-

Bug#860323: unblock: dokuwiki/0.0.20160626.a-2

[Tanguy Ortolo]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please unblock package dokuwiki

I know dokuwiki was autoremoved because of #854592 (grave), which for
personal reasons I was not able to fix in time. Now, if this is final, I
do not want to waste your time, dura lex sed lex.

That said, I think users would be better served by having an up-to-date
and fixed version in the next stable, than keeping an old version from
oldstable, especially considering how tiny the fix is, basically
(simplified diff):
- --- old/debian/control
+++ new/debian/control
- -Depend: php-seclib
+depend: php-seclib (<< 2)

I am attaching the full debdiff from 0.0.20140929.a-1 previously in
testing and the new 0.0.20160626.a-2 in unstable. Thanks for all your
work.

unblock dokuwiki/0.0.20160626.a-2

- -- System Information:
Debian Release: 8.7
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (50, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.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
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJY8OHTAAoJEOryzVHFAGgZ+Q8QAMOFaBz+u+VcB6JDr0HzK9pM
q2EOIUThgDZyD+BMWGQN3b9b0lcdZ1EeFZ0MOW/1AJMIl+KzQ3JWH+Snt2pF2q1V
TuaRyCq4uxEVnS6F/k2/6ZPXKC8plSFjXdWhZLSpfPerGb9WsKLzQjGXGhdl4xbL
wgCyCEmlFXCoaXQgbAu82QTNZ69W2Ya4i8Lkpseax70UZ91T2WxYxYAnyynn6dCA
ce0K8ulFNcM3/jyUhLalF8Ad+pei9VzQtEeMX4mGjjb3JJcGvDbC5PHRAUQmHLDz
BJuE/9Dg6IQUx0XpUu0XhF9McmGGfBAeM73hSjv+f9YL7TlB8FI3cv9W2yU4SXEH
0tvKvTCrsLK19uf5ediZpYsLpW/n8kfG82rIZ99neKxRHBchvRPKGbtyjZNjrT8U
6rM8wVg9UmdtRnk3rySeIjcdX3c148G+bbRr//bMlzdxVh23gFa8klwFL1cw7gls
2jdWn3XI3Pg0EeuzcbmrPVflpKqQyJ9MKzIvuvF82tnoyn06edx4N+bS3sz3XdIR
hGzgVc21OIjjWyPKUOziuBTMCdcgqygq3Js33e4QYD5tPOb+2jba3QdpkDBBii5T
fGWlbmlsRwBPQVtG7TgWlbwsjveWiSDGzfiBjah4cqXme44d/awn2jGb7rjZ/72Q
UYnYZM9h8kuIaatHhKkI
=PrV9
-END PGP SIGNATURE-
diff -Nru dokuwiki-0.0.20160626.a/debian/changelog dokuwiki-0.0.20160626.a/debian/changelog
--- dokuwiki-0.0.20160626.a/debian/changelog	2016-08-14 13:37:56.0 +0200
+++ dokuwiki-0.0.20160626.a/debian/changelog	2017-04-14 15:40:24.0 +0200
@@ -1,3 +1,10 @@
+dokuwiki (0.0.20160626.a-2) unstable; urgency=medium
+
+  * debian/control: depend on php-seclib (<<2) as the new php-phpseclib
+provides php-seclib (>= 2) which is not compatible. (Closes: #854592)
+
+ -- Tanguy Ortolo   Fri, 14 Apr 2017 15:23:13 +0200
+
 dokuwiki (0.0.20160626.a-1) unstable; urgency=medium
 
   * New upstream release. (Closes: #834150)
diff -Nru dokuwiki-0.0.20160626.a/debian/control dokuwiki-0.0.20160626.a/debian/control
--- dokuwiki-0.0.20160626.a/debian/control	2016-08-14 13:37:56.0 +0200
+++ dokuwiki-0.0.20160626.a/debian/control	2017-04-14 15:19:39.0 +0200
@@ -23,7 +23,7 @@
 libphp-simplepie,
 php,
 php-geshi,
-php-seclib,
+php-seclib (<< 2),
 php-xml,
 ucf,
 Recommends:

Bug#854592: [pkg-php-pear] Bug#854592: dokuwiki: Unable to login, missing usr/share/php/Crypt/AES.php

[Tanguy Ortolo]

Hello,

David Prévot, 2017-02-13 08:45-0900:

Then it sounds like this bug was incorrectly reassigned to
php-phpseclib: either dokuwiki should depend on version 1 of phpseclib
via the php-seclib package and have the files where expected, or it is
able to use version 2 via the php-phpseclib package installed where it
belongs. In any way, please, do keep both packages installable together,
the proposed patch is not acceptable.

Either way, dokuwiki should be able to use the provided autoloader:
- /usr/share/php/phpseclib/autoload.php for php-phpseclib
- /usr/share/php/phpseclib.autoloader.php for php-seclib


This is right, I though I already did that, but that modification got 
lost between two updates of the package. Let me reintegrate it.


--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#845179: FTBFS with super-fresh cython -- seems to carry pre-cythoned sources which get rebuilt during clean

[Tanguy Ortolo]

Yaroslav Halchenko, 2016-11-21 00:27-0500:

While preparing for upload of fresh cython (0.25.2~b0-1) and running build of
rdepends python-aiohttp failed to build with

so you can see that clean does recythonizing, which modifies shipped with
upstream tarball slixmpp-1.2.1/slixmpp/stringprep.c


Well, I am not surprised that generating it again with a newer version 
of Cython results in something a bit different. :-)

Thanks for catching this!


as a quick&dirty solution (besides cleansing the sources pkg) I think you
could make use of  dh_autoreconf so it memorizes changed files


I already had the case with a package written in Vala and shipped with 
pre-generated C file: what I did then was simply to delete these files 
during clean. This is simple, and good enough since missing files are 
not an issue if they are not actually needed. I think I will do the same 
here.


Cyrthonizing at clean is silly, but this seems to be a known limitation 
of the current integration of Cython and distutils… I guess we will have 
to deal with it, as the only consequence will be using the CPU for 
nothing.


--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#819590: RFP: python3-slixmpp -- XMPP library for Python 3 using asyncio

[Tanguy Ortolo]

package wnpp
retitle 819590 ITP: slixmpp -- XMPP library for Python 3
thanks

The source package will simply be named slixmpp since this is the 
upstream project name. The binary package will be python3-slixmpp 
according to the convention for Python libraries.


--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#819590: slixmpp 1.2.1 released

[Tanguy Ortolo]

W. Martin Borgert, 2016-10-06 02:24+0200:

https://blog.mathieui.net/slixmpp-1-2.html
(And there is even 1.2.1 in git.)

Any packaging progress so far?


Yes, I have uploaded slixmpp 1.2.1-1, it just has to be validated by the 
ftpmasters now.


--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#835339: ITP: python3-aiodns -- Asynchronous Python DNS resolver library for Python

[Tanguy Ortolo]

Piotr Ożarowski, 2016-08-25 12:53+0200:

heh, you don't need a sponsor (I was mislead by your email address),
stil happy to help with Python bits if you have problems with
pybuild/dh_python3 or so...


Thank you, it seems to work just fine. I have just uploaded pycares, and 
I have basically finished packaging aiodns but I will first test it 
before uploading it.



--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#835348: ITP: python-pycares -- Python interface for c-ares

[Tanguy Ortolo]

For the record, I am progressing on this. My work can be found at 
<https://git.ortolo.eu/pkg-pycares.git>. It builds a package that seems 
to work, but I still have to check it further.


--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#592159: Intent to package Poerio

[Tanguy Ortolo]

package wnpp
retitle 592159 ITP: poezio -- XMPP terminal-based client
owner 592159 Tanguy Ortolo 
thanks

I am willing to package Poezio. It will take some time, since it depends 
on python3-slixmpp (#819590), python3-aiodns (#835339) which in turn 
depends on python-pycares (#835348) which all need to be packaged.


Librement,

--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#835348: ITP: python-pycares -- Python interface for c-ares

[Tanguy Ortolo]

Package: wnpp
Severity: wishlist
Owner: Tanguy Ortolo 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-pycares
  Version : 2.1.0
  Upstream Author : Saúl Ibarra Corretgé 
* URL : https://github.com/saghul/pycares
* License : Expat
  Programming Lang: Python
  Description : Python interface for c-ares

pycares is a Python module which provides an interface to c-ares. c-ares
is a C library that performs DNS requests and name resolutions
asynchronously.

This library is used by aiodns <https://github.com/saghul/aiodns> which
is used by Poezio <http://poez.io/> which I am willing to package.

Librement,

- -- 
Tanguy

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJXvbfJAAoJEOryzVHFAGgZkoMP/2b1PaP4z+tadoyMMMaor/ye
JSQGdvhUdlh8wOiwyAsK4g0DlUkLOW1OTuJ8BIXTUWca1EJ/CfRt11gSuJo0wkUW
Tan5iDGvfnw8nS9twm6YRQDFoV+OFS4mima2QuNZP3brBBF9bwkHCsq13q4w+xyo
+m9mUcItni/BvoPQJN7yGrfX3UV1ww89XXmggoWkg5c1+wfJTS7THS3+B+nwVtXb
rm5brRARwVRgOrTV/s4CjGjRuMWHUIPSQF2LHgdAr/mhZTT2ZwymBPf5gfugWKeE
EuHbGa7mb2TmfTjr+7tOQ0rwyTD/VHlSTi9vKho/5UllKYjcgLAk5+MmP8qaK1MF
+qlOlmCX7z9dMbxJJ2z/cdIaPsR7nEcVejouBbTB4y/TiIgdoK0JUo9uX0X68fs9
UGs69Hf6zy7tYYaD8j5IPpWYiN7jsUXVWQmq6SJ+f0InN/0bEi8OXq3QjMmpHOC3
ibuYWHgHGFB2wuPaIs14GLRlLhNCsY04rLsYejC3HxyeKs/p3tZWi4IkC9p4/T1h
809Nrhaj8JOz3Z63m+zM0Kvn5wlZzNqhL4v9FbFHYj+/g6ILhVHc1C+LnEkNcJuX
iBh8VD/y8qMjh0J06Y3h9TMJ5tInLPykrH92EEuHmErNhrqMzICwvnPJOkICkWC6
BOOnVH/Ef9WrsIHyOnwH
=b0Ep
-END PGP SIGNATURE-

Bug#835339: ITP: python3-aiodns -- Asynchronous Python DNS resolver library for Python

[Tanguy Ortolo]

Package: wnpp
Severity: wishlist
Owner: Tanguy Ortolo 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python3-aiodns
  Version : 1.0.1
  Upstream Author : Saúl Ibarra Corretgé 
* URL : https://github.com/saghul/aiodns
* License : Expat
  Programming Lang: Python 3
  Description : Asynchronous DNS resolver library for Python

aiodns is a Python library that provides a simple way for doing
asynchronous DNS resolutions with a synchronous looking interface by
using pycares.

This library is used by Poezio <http://poez.io/> which I am considering
to package.

Librement,

- -- 
Tanguy

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJXvbPyAAoJEOryzVHFAGgZ7fgP+wXlgEEGN1Z6pj4VFQbvqMFF
ILFTwVBTZYrAtKZK/YN2JFGkWAJLg46Yh21eKqW0hF1Z97YcgHhMFDkymSBgXHsJ
oaUsuJ6KItBP+66xXl2DOk/+YjhNW/uK0f2HBeCe5l0V+IXaZVR7a/kBezfmd6Gv
uDjB5M56dD8VrZlkxUPyEfiJTTmhpeHB8KZUb65C4RMY8DZ9RDmotOaLl8yRJUkj
fx2EfmhkkKFzcELB1sgNaOjeropJIsuecm0WqPZya5daR+X1hxqcSsUG/DqY1o9O
stLTIR4CIwfSntqqvJwCNpD6XzAgEeb/FCn1tw2GF+33xcWJyo5PxyulUOenddB+
+TRAv1pSC9Jkpz57HXyRppMV64aCXFo+5Wdzhud22A+mljJdBs2WkkAD1z7nkBsn
nWJ4NgnkNyUv4f4mgu0VGWEfN0U4qhdw21r+XVopKgQYLd9va+RWiHKEovshPHFt
0RwWYwRTv4IyaWdlkyUYuARCsjQPynoWqsdNDCJmXEEfCYpIISeaG08hwxV6c3Vu
5STQM7BRYGYVVgPHDTPfcDAXX66MUPJwU9E+SKXBYtc1PggcsQ8JHvO8Z1w9bE+l
Wv0rM2NG7vILLZd4zfBD6YSxlJYsuhV8gWqWBD2DGOnKKCWD6sTXIU4KObyf1rsZ
9d3G3C78KUpkMUd8K6jc
=gw8t
-END PGP SIGNATURE-

Bug#819590: RFP: python3-slixmpp -- XMPP library for Python 3 using asyncio

[Tanguy Ortolo]

package wnpp
retitle 819590 ITP: python3-slixmpp
owner 819590 Tanguy Ortolo 
thanks

Hello,

I am considering packaging Poezio, which uses Slixmpp, which I should 
therefore package first.


Librement,

--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#834399: [pkg-gnupg-maint] Bug#834399: Bug#834399: gnupg: gnupg2-bases gpg breaks Gajim

[Tanguy Ortolo]

package gajim
severity 834399 normal
thanks

Okay, this is not an issue with GnuPG 2 breaking Gajim, but with Gajim 
not being able to use GnuPG 2 properly. But then it is not serious, not 
even important, but normal : main functionnality of Gajim, which is 
instant messaging, it working fine, only you cannot use OpenPGP which is 
a secondary feature.


That said, I will see what I can do. Maybe I can patch that myself (I am 
not optimistic about that option…) then forward the patch, otherwise I 
will forward the bug.


Librement,

--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#812739: latexila-3.14.0-1: debug comments don't show up on bottom panel

[Tanguy Ortolo]

Hello, and sorry for the late reply.

jessie latexila-3.14.0-1 debug messages not displayed, 2016-01-26 09:41+0100:

this bug makes the default latexila-3.14.0-1 package from jessie unusable
for me.


I do not see how that would render it unusable, are you unable to edit 
LaTeX files or to compile them?



I solved it by uninstalling this package version from apt, and by building
the sources from the 3.14.1 version I got on the developper site,


Okay, I guess something was wrong. Did you have any chance to try with 
the latest version of LaTeXila in Debian?


Regards,

--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#821576: php-geshi: PHP 7.0 Transition

[Tanguy Ortolo]

I will try to fix this with an NMU.

--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#821714: src:simplepie: PHP 7.0 Transition

[Tanguy Ortolo]

Tanguy Ortolo, 2016-05-16 12:39+0200:
As I maintain dokuwiki which depends on php-simplepie, I am concerned 
by this. I will try to NMU this.


NMU done, without delay considering this is an RC bug.  Marcelo, I have 
put my changes on a Git repository of mine, so you want you can merge 
them at your convenience, with:


   $ git pull https://git.ortolo.eu/git/contrib-pkg-simplepie.git

Librement,

--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#821714: src:simplepie: PHP 7.0 Transition

[Tanguy Ortolo]

As I maintain dokuwiki which depends on php-simplepie, I am concerned by 
this. I will try to NMU this.


--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#824174: RM: sam2p -- ROM; unmaintained upstream; FTBFS

[Tanguy Ortolo]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

sam2p is unmaintained upstream (no release for 2.5 years, homepage
disappeared with Google Code), and uses a specific and unusual build
system that does not work with latest build chain, resulting in FTBFS.

Its features can be found in alternatives such as imagemagick and
ghostscript.

It has no reverse dependencies, only one reverse suggestion from rubber,
for which I have filed #824118.

Could you remove sam2p from unstable?

Librement,

- -- 
Tanguy

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJXNbo9AAoJEOryzVHFAGgZqKoQAK57CNhFBYU8mOvT7EJ05iKA
8+/w7zkeajPn46S/vVjQYMqHw/e7qxl9BZmL9PjxyEB7AdtFCfxcFxJEjIeN0K5s
35ZZn+F4wRmyWBMMPyjiZyrxwkBULS42MXbiXMPWtbOfBlmeNfL3A1YWg6YGJHcY
GK/yBkq5OKMzDqgle24AR1aQZX+GTKMDBn80NEOM+D/Z2tHIqGr+wXu8WRu0t0Ms
QNFsdBAjZOKIdqzArbUagOoYwhegg8tCrVhwTTC38p9iGsZYKxMB0RQwYpvCWBXV
ElVLJSWJrR33SfuukC+3bV5leZbX0iPW39yqmRepGWSHqZETEhVPxEKXU8xt6+Vi
UJ55ezrNsU5I0H/sjSsgqK3qxNyKndlimIcbawNkzaG26RPMEP/9Kn0dKWPYdkDc
htG/H8PPj+DznYeXMc3sXVkY+x+UbCua5e0y1EGrZLR/5qzF146xD6SbdPRjc4eQ
u3FWXbGp/uTAWGvOno3n7zp+v3qb0oWZQXDaL1vjO86CnxNq8ve27xBg/F3K36Hj
4iKA2KUuy6ydnCBNGd/ccaq74w/yefRr5kX3lnUntLiga4gpijOv+ZrK5oIaEx+h
XMJ4GfP5aGBZu8ekIMJAflqDMtuvuV0UFLDe8VmU1UC391V32QFb+UtDOsiV83uj
JbAC//uaGRf1J05RBqDe
=CwJq
-END PGP SIGNATURE-

Bug#824118: Please remove Suggests: sam2p

[Tanguy Ortolo]

Package: rubber
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

sam2p will be removed from Debian, as it is not really maintained
upstream, uses a customer and quite unusual build system that does not
works with current build tools, and can easily be replaced by other
tools like ImageMagick.

Could you therefore remove it from the Suggest control field of rubber?
I have checked, and all useful formats supports through sam2p, are also
supported through ImageMagick or other tools (some unusual formats are
not, but nobody uses things like  IFF Interleaved Bitmap with LaTeX, and
if such people would exist, they would be skilled enough to know how to
convert them by other means…).

Regards,

- -- 
Tanguy Ortolo

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJXNID/AAoJEOryzVHFAGgZlIEQAMjAR8H8UJGb4vUdpR1IzpUU
HhDMIfx+Fb4dyrlzQD5WVU7HsSb9ry9SxZJPE1NQ06x3qv4VK/KQS1QvjtTL/6O4
6GgF/2yftoIeNzrz5hsIjXdS+XBvHJUiurp0rNCo2n1XqgPXv4uivAAC/WLMrC83
S27WRqtw/YlrV3rND9KKZ4Q37iNWx/9p125XL8V1vO4c8XKYRxzB/uMxRVJvj2Gn
ebpW+aoEnqupSV0kOG5YnlUDcGUU1FrMO2QF82TmB38WCB7657ZzKgKNLOvotRj8
WDqE2QalteIX/9p8/34Fy4E7V3gmoDebtpRRb7Stln9W3azJGO+nDqrUjT1Pgb7o
E9myDtHG8p42tKqYjsvNO6aKeAB/tHm31KmzkXSDqQG15wVhdnaRfVmt24vshxJ4
9XmZCGvIBW7wIa6nNKMG1tV8+MeQaxhzBBG4/KvZJ2MoCZRTWGWpfe7eNXG7vNd0
jhma3SIDVijchiP0zZz0ytOdmlWgvmtCdl3XnMpDETR/WQCsQz69SLHW0/8Q9PRj
4OpgPKKnoloTy+khFcBU4jMOHIMDYM97oVTUraQT5DpI0Mo7NvOocl3N7d0CRLXE
7oqgBecJa2ggP+x420G0slH7IyFZwo4/21oJVqjDiYKGC8m7bWZ428iHli5ua9Zb
ZTKmKeqjPVFGvkpfwSzr
=cdqD
-END PGP SIGNATURE-

Bug#810989: itstool: Itstool fails to translate xml attributes, when unicode character is used

[Tanguy Ortolo]

Guillaume Bernard, 2016-01-14 17:11+0100:

When trying to translate strings from English to another langage, itstool fails
because unicode character where used in the translation file (.mo).
As mainly every langage except english uses unicode characters, the package
is unusable.


Well, this is serious indeed!


A fix has been published on the official Github page :
https://github.com/itstool/itstool/commit/6f1761d86b4749a65607d4b4af622f6771e1f330


I think that may not be the right commit, as it is the last one in the 
current version in Debian, therefore already applied. I think you meant 
that one:


https://github.com/itstool/itstool/commit/d75f68cbc58075b57aee53d57b9156655a2fc99a

I will apply it and upload a new version, thank you for the report.

--
,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
\_


signature.asc
Description: Digital signature

Bug#819779: gdk-pixbuf: libgdk-pixbuf2.0-dev depends on libpng-dev but gdk-pixbuf2.0.pc requires libpng12-dev

[Tanguy Ortolo]

Package: libgdk-pixbuf2.0-dev
Version: 2.32.3-1.2
Severity: grave
Justification: renders package unusable

Hello,


While trying to build a new version of my package latexila for
experimental, I noticed it was failing because of libgtk-pixbuf2.0-dev.
Indeed, that package, in unstable and in experimental as well:

* ships a gdk-pixbuf2.0.pc that requires libpng12.pc;
* depends on libpng-dev which:
  - on experimental, is a real package that does not ship libpng12.pc
but only libpng16.pc and libpng.pc;
  - on unstable, is provided by libpng12-dev which does provide
libpng12.pc, but that situation should change to that of
experimental whenever the new libpng-dev real package is uploaded to
it.


Basically, when requiring libpng12.pc, it does not seem right to depend
on a package, either virtual or real, that is not guaranteed to provide
it. In my opinion, in its current state, libgdk-pixbuf2.0-dev should
depend on libpng12-dev as this is what it uses, and not on libpng-dev
which may or may not provide what it currently needs.


Since there is a transition to make to libpng-dev, one solution would be
to rebuild gdk-pixbuf for experimental, but doing it in an environment
with libpng12-dev not installed and libpng-dev installed from
experimental. That way, its configure script (l. 18507) would just pick
libpng16 and the resulting gdk-pixbuf2.0.pc would require the
libpng16.pc it provides:

>for l in libpng16 libpng15 libpng14 libpng12 libpng13 libpng10; do
>  […]


In the longer term, it could be better to have the configure script
check for libpng before libpng16 or libpng12:

>for l in libpng libpng16 libpng15 libpng14 libpng12 libpng13 libpng10; do
>  […]


That way, it would not even need to be adapted for future versions of
libpng.


Regards,

-- 
Tanguy

Bug#819660: explicitly allow building automatic debug symbols packages not listed in control

[Tanguy Ortolo]

Tanguy Ortolo, 2016-04-01 11:23+0200:

My new package gspell has just been rejected


That was an explicit April fool, shame on me for not noticing it!

concluding that they are okay with automatic debug packages may have 
been a bit premature. I will check what is going on here and update 
this report.


ftpmasters are still fine with automatic debug packages. I am just not 
fine with April fools… ;-)


--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#819660: explicitly allow building automatic debug symbols packages not listed in control

[Tanguy Ortolo]

Tanguy Ortolo, 2016-04-01 10:38+0200:
I have just checked on #debian-ftp, and joerg confirmed that they are 
okay with automatic debug packages. That question was in fact already 
implicitly answered, since they did the work to accept these packages 
in the archive!


My new package gspell has just been rejected because it builds an 
automatic debug package not listed in debian/control, so that concluding 
that they are okay with automatic debug packages may have been a bit 
premature. I will check what is going on here and update this report.


--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#819660: explicitly allow building automatic debug symbols packages not listed in control

[Tanguy Ortolo]

Bill Allombert, 2016-03-31 18:42+0200:

Are the FTP masters happy with that ?


I have just checked on #debian-ftp, and joerg confirmed that they are 
okay with automatic debug packages. That question was in fact already 
implicitly answered, since they did the work to accept these packages in 
the archive!


I will still ask them to update their Reject FAQ, which could do with an 
update, as the Policy.


Regards,

--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#819660: explicitly allow building automatic debug symbols packages not listed in control

[Tanguy Ortolo]

Hello, and thanks for the super fast reply.

Bill Allombert, 2016-03-31 18:42+0200:

The Policy implicitly indicates a source package should only build
binary packages listed in debian/control. At least, this is how
ftpmaster interprets §5.2, 5.4 and 5.6.19, when you look at the Reject
FAQ <https://ftp-master.debian.org/REJECT-FAQ.html> (search for
“debian/control breakage #2”).


Well, historically, this is the FTP masters that asked for this
rule.


Now, this is quite not compatible with the new debug symbol packages
<https://wiki.debian.org/AutomaticDebugPackages> that are now
automatically created.


Are the FTP masters happy with that ?


Not sure, I guess they should be as it is all the point of these 
automatic debug packages, but I will ask them.


--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#819660: explicitly allow building automatic debug symbols packages not listed in control

[Tanguy Ortolo]

Package: debian-policy
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,


The Policy implicitly indicates a source package should only build
binary packages listed in debian/control. At least, this is how
ftpmaster interprets §5.2, 5.4 and 5.6.19, when you look at the Reject
FAQ  (search for
“debian/control breakage #2”).

Now, this is quite not compatible with the new debug symbol packages
 that are now
automatically created.


Since explicit is better than implicit, I think §5.2:

>The debian/control file contains the most vital (and
>version-independent) information about the source package and about the
>binary packages it creates.
>
>The first paragraph of the control file contains information about the
>source package in general. The subsequent sets each describe a binary
>package that the source tree builds.

could be completed by:

>[…]
>
>The first paragraph of the control file contains information about the
>source package in general. The subsequent sets each describe a binary
>package that the source tree builds. All the binary packages have a
>corresponding paragraph, except for the possible automatic debug
>packages that do not require one.

There may be better ways to phrase this, but I think there is still a
need for some clarification about this.


Regards,

- -- 
Tanguy


-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJW/VAkAAoJEOryzVHFAGgZiicQAL0PkKP9AuTl5bo/5+eITdMQ
N9b0raQzKUFOKnoAMW8flfF7xRVwLppH9Bansylhg6kkKT/bK9nH3kvvI9rjCrcu
GpZvhsstQ8fxNrHusfkoDjjkgDhtklfLqdOHrN9hetj/cxjdhA9Udg3GcZOCZDSp
e+GnFBzla+xbtyDQxMlP6AjUqVsmD9CNshga0VHmJKNl1LQjQXvwVMGkK98116k2
FoYvM0PfLWvn9T8U4iGZsYPN/DB/U4RqLgF9gDPbZrnuqVtWuug9+GsrJOEH4a6x
7KCOJt9LGo6ca+iVWe2fDW5kkHgK19zAaUeIv+Diy72+BBBGIHl+5lO8T4KOcfqW
WIkD+f3NhmzT5vG/v19R/A442uoYA4kkOF/Gh2khb2fimW/48vOl+4yHmR8zqTRa
PTJ/UHqJCZbpm5Gbvgw44LjK27g3uvYpSD5cCF34LO7Wkxq1XZWd3ZWJMZkKd4nU
EbtT+Ky6E40hmA+xfOBbi3BdLvg7aoepmgtkIHBhe/UcU/rW1t1MIIhDPa4HrMUl
l/qlZ6D30eecYrA92QnUqIrl0pspmWBrle5ryv7DlO/csZWmmok32il4kC76PWgP
eNFbSnw0fRZILvqqkq5qdlC9rSNg8rSvQfnanzh/KjqlwXYMhNy+xK1KqPLrQlYZ
N3fJLGysmEX2rKUaYdtx
=ZF0E
-END PGP SIGNATURE-

Bug#813708: autojump: Wrong path for zsh in README.Debian

[Tanguy Ortolo]

package autojump
tags 813708 moreinfo
thanks

Hello,

Simon Marchi, 2016-02-04 10:48-0500:

In /usr/share/doc/autojump/README.Debian, the path to add to .zshrc is
wrong.  It should be:
. /usr/share/autojump/autojump.zsh

instead of
. /usr/share/autojump/autojump.sh


Well, not exactly. If you look at autojump.sh, you will see that, 
depending on the shell you use, it sources autojump.bash, autojump.zsh, 
autojump.fish or autojump.tcsh.


While directly sourcing autojump.zsh would work just fine, I find it 
easier to have instructions as similar as possible for every shell.


Is there a good reason to change the instructions, for instance if the 
current suggestion of sourcing autojump.sh does not work?


--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#816557: ITP: gspell -- spell-checking library for GTK

[Tanguy Ortolo]

gspell 1.0.0 has been published, so I will work on packaging it now.

--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#816557: ITP: gspell -- spell-checking library for GTK

[Tanguy Ortolo]

Upstream confirmed that:
* current gspell-1 0.1.* (libgspell-1.so.0.0.0) and gspell-1 0.2.* 
 (libgspell-1.so.0.0.0 as well) are development versions with no stable 
 API, although LaTeXila 3.18 depends on gspell-1 0.1;
* gpell-1 1.0.0 (libgspell-1.so.1.0.0) is planned to be released for 
 GNOME 3.20.


Considering this information, and according to upstream suggestions, the 
best course of action is probably to skip development versions and only 
start packaging with gspell-1 1.0.0 (libgspell-1.so.1.0.0, package 
libgspell-1-1). This implies that it will not be possible to package 
LaTeXila 3.18, but hopefully LaTeXila 3.20 will use gspell-1 1.0.0.


I will notify the Debian GNOME Maintainers, as next Gedit will be able 
to use gspell.


--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#816557: ITP: gspell -- spell-checking library for GTK

[Tanguy Ortolo]

Packaging work in progress can be checked out at 
<http://git.ortolo.eu/pkg-gspell.git>.



There is an issue to solve with API breakage without SONAME bump: the 
gspell project show two “development” branches numbered 0.1.* and 0.2.*, 
both of them providing libgspell-1.so.0.0.0, but with an incompatible 
API.


Problem is, another software, LaTeXila, has a dependency against the 
“0.0.0” API from branch 0.1.* only…



I am checking with the upstream maintainer to see what can be done about 
that. I think there are two possibilities:

1. change the SONAME in Debian, so:
  - branch 0.1.* will provide libgspell-1.so.0.1.0 (Debian package 
libgspell1-0.1),
  - branch 0.2.* will provide libgspell-1.so.0.2.0 (Debian package 
libgspell1-0.2);
2. consider these as temporary versions only to be used by LaTeXila 
  (which is the software this library was written for) and package 
  branch 0.1.* to provide libgspell-1.so.0.0.0 (Debian package 
  libgspell1-0), never package branch 0.2.*, and wait for an API 
  version 1.*.


--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#816557: ITP: gspell -- spell-checking library for GTK

[Tanguy Ortolo]

Package: wnpp
Severity: wishlist
Owner: Tanguy Ortolo 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: gspell
  Version : 0.2.4-1
  Upstream Author : Sébastien Wilmet 
* URL : https://wiki.gnome.org/Projects/gspell
* License : LGPL-2.1+
  Programming Lang: C
  Description : spell-checking library for GTK

gspell provides a flexible API to add spell checking to a GTK+
application.

This library was adapted from gedit's spell splugin by Sébastien Wilmet
for his application LaTeXila, as described in this blog post [1]. Since
then, it has become a dependency of LaTeXila and therefore needs to be
packaged.

[1] 
https://blogs.gnome.org/swilmet/2015/09/16/introducing-gspell-a-new-spell-checking-library/

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJW12gIAAoJEOryzVHFAGgZEKoP/3l0iKeQFW4lGZt/1Lh7mqy1
3NO3meHh7ik792d5aC4CfhY0DjTU+u6CIOOalIgxa4ipB0WjswMSWc6wXgRPtPY8
qu1zRQijlO/8z1CIK8LNOCxuQkjn2jrOOr53bwh2mBNwvzvHUCB7ARJEOFMVSzrX
K3EvDdpok/rcq28mFAq2Ql/wLJlBN0TKmXH5nYWsPyqJiLe0cEKhCQ8PMjve6hwi
Uz70ZKnpsxk3wAMprXJohIehiJYkUA06ZAvFgdCOTBWaEmoeGnQ0rHh9Q2BqGnjK
rV3cskc4PQ8AjeCvf6OxXvWf7+5FTaYsr5ES9tpypgN0RwAo29p5oa3aHWDSYnUt
GPFzME8IEGVJbsnqDoKPUmrCGLuM+5zkX88b9MtBZvHmIjcgGJM1iqXd7Whs4SiL
4f5v6QeU6prDQbXu2TlKjAGlk+j56j00wode4OfuID85L8BvKfrP9TJczjXKgmBl
Gd1eTTc263H7Q3AZeeRlAs9IPN4Tbasn6/dorSjheF5ObEhJncqMOxT889EnC0Hl
/JpWr6na1bmUHLytzuRugSTsNcxeK0Q1I+Zkqs9vr0Iuscbj6PVhLaphXPSPr2Zy
Uo02kr/Q99xrjMzJIikeD9reonWUqKzAY4WMXqvdx4HOKP6OYSXhGf59MG3WF+LI
seu8KMJVC8ZUCfXanQM/
=ndHF
-END PGP SIGNATURE-

Bug#774572: [PATCH 6/6] Added latex-beamer, texlive-latex-extra and xetex

[Tanguy Ortolo]

Hello Matthieu,

Sorry for the late reply; I will integrate most of your suggestions, 
except this one:


Matthieu Baerts, 2015-01-04 16:43+0100:

Suggested packages: can be useful for beginners.


Beamer, XeTeX and texlive-latex-extra could be useful, but for people 
that want to do specific things and know what they want to do. For 
beginners, all we can assume is that they will have a common use of 
LaTeX, which is what the meta-package texlive is for.


Other than that, many things could be useful, but we cannot suggest them 
all, otherwise we could as well suggest texlive-full.



Now, about your patches, unfortunately I have been working on 
debian/control without thinking about them, so I am integrating them 
manually.


Regards,

--
,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
\_


signature.asc
Description: Digital signature

Bug#780976: unblock: dokuwiki/0.0.20140505.a+dfsg-4

[Tanguy Ortolo]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please unblock package dokuwiki

Version 0.0.20140505.a+dfsg-4 in testing-proposed-updates fixes RC bug
#779547 (CVE-2015-2172, a privilege escalation vulnerability), by adding
a debian/patches/cve-2015-2172_check_permissions_in_rpc.patch,
cherry-picked from the upstream bugfix release 2014-05-05d (upstream
commit https://github.com/splitbrain/dokuwiki/commit/16ca97e1).

Changelog entry:
>dokuwiki (0.0.20140505.a+dfsg-4) testing-proposed-updates; urgency=high
>
>  * debian/patches: security fix, from upstream hotfix release
> + cve-2015-2172_check_permissions_in_rpc.patch: check permissions in the
>   ACL plugin's RPC API to avoid a privilege escalation. (CVE-2015-2172)
>   (Closes:  #779547)
>
> -- Tanguy Ortolo   Sun, 22 Mar 2015 17:40:22 +0100

unblock dokuwiki/0.0.20140505.a+dfsg-4

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJVDwQTAAoJEOryzVHFAGgZpfQP+wUw73xabOLo81nJ4HYQiNAs
BRPXqP4ZH3u7KFdaOyuuKv4H1tCKP6WjPO6zjaVYie35PcnrsqWkvm78xX9RgBaR
Bt1yKEnM6oqfAKUFxa/qSs1uovcFGwLOWko6wp155tPE6CYGNWAMWcv3YsU1I2MW
PfqGIrUfL1JliA5juDNy1Ydp66zBNV1bS0a/TIi9e4LdcYBRRRhOAIJvQ7NocpfQ
UmkU9Xb0H4KyWwA7QCVOlQmd8zvQUjxrxXbhO+ai0VlMo1HkhkWmI5vvA96IJn3b
nIIGkj5nFD0bbGcwQjOhiPWlTbnLs0gTKOmcRuLy6KCoyJBFGRpNWQBfSdunalES
ytmGl5OTW0qvWCx7PEhRNo1E1x45LWylsuqMIdDT7b2ac94Pl/nqkw49TMOPo5Id
5mZd4xZZZUmp38gBvq1dUEXKKmr7iRh3awchUDYOO5pGKvKEqhl55k69NMXPyuMv
nWaw8+Tfd5YCG4D7VHDTfxbi+JScGxV9+pKD4rjlmtgzqQfK8nvIOBQraDgQ4adE
mhF0ivBExhTglVQMFF4pKNbY+Bl/bgmBx6CvW+nrEIa8b4NjvI1rBf/b7IvzzfSw
wbPR6QG4kN2L7hXZ0+177u7POqouuJpMPPVQ46ndC/E+pGkjbFSlkTpM8eKb2FQJ
jkKKV90kIFvUYSpepbOx
=typ3
-END PGP SIGNATURE-
diff -Nru dokuwiki-0.0.20140505.a+dfsg/debian/changelog dokuwiki-0.0.20140505.a+dfsg/debian/changelog
--- dokuwiki-0.0.20140505.a+dfsg/debian/changelog	2014-10-05 21:58:22.0 +0200
+++ dokuwiki-0.0.20140505.a+dfsg/debian/changelog	2015-03-22 18:50:07.0 +0100
@@ -1,3 +1,12 @@
+dokuwiki (0.0.20140505.a+dfsg-4) testing-proposed-updates; urgency=high
+
+  * debian/patches: security fix, from upstream hotfix release
+ + cve-2015-2172_check_permissions_in_rpc.patch: check permissions in the
+   ACL plugin's RPC API to avoid a privilege escalation. (CVE-2015-2172)
+   (Closes:  #779547)
+
+ -- Tanguy Ortolo   Sun, 22 Mar 2015 17:40:22 +0100
+
 dokuwiki (0.0.20140505.a+dfsg-3) unstable; urgency=medium
 
   * debian/config: only set a default password if the question was skipped
diff -Nru dokuwiki-0.0.20140505.a+dfsg/debian/patches/cve-2015-2172_check_permissions_in_rpc.patch dokuwiki-0.0.20140505.a+dfsg/debian/patches/cve-2015-2172_check_permissions_in_rpc.patch
--- dokuwiki-0.0.20140505.a+dfsg/debian/patches/cve-2015-2172_check_permissions_in_rpc.patch	1970-01-01 01:00:00.0 +0100
+++ dokuwiki-0.0.20140505.a+dfsg/debian/patches/cve-2015-2172_check_permissions_in_rpc.patch	2015-03-22 18:06:36.0 +0100
@@ -0,0 +1,58 @@
+Description: Fix CVE-2015-2172 by checking permissions in ACL plugin's RPC API
+ This fixes a security hole in the ACL plugins remote API component. The
+ plugin failed to check for superuser permissions before executing ACL
+ addition or deletion. This means everybody with permissions to call the
+ XMLRPC API also had permissions to set up their own ACL rules and thus
+ circumventing any existing rules.
+Origin: upstream, https://github.com/splitbrain/dokuwiki/commit/16ca97e1690c775fa74d3c3cb1a906685a37b53b
+Bug-Debian: https://bugs.debian.org/779547
+Author: Andreas Gohr 
+Last-Update: 2015-03-22
+
+diff --git a/lib/plugins/acl/remote.php b/lib/plugins/acl/remote.php
+index 6d5201c..9433b77 100644
+--- a/lib/plugins/acl/remote.php
 b/lib/plugins/acl/remote.php
+@@ -17,12 +17,39 @@ class remote_plugin_acl extends DokuWiki_Remote_Plugin {
+ );
+ }
+ 
+-function addAcl($scope, $user, $level){
++/**
++ * Add a new entry to ACL config
++ *
++ * @param string $scope
++ * @param string $user
++ * @param int$level see also inc/auth.php
++ * @throws RemoteAccessDeniedException
++ * @return bool
++ */
++public function addAcl($scope, $user, $level){
++if(!auth_isadmin()) {
++throw new RemoteAccessDeniedException('You are not allowed to access ACLs, superuser permission is required', 114);
++}
++
++/** @var admin_plugin_acl $apa */
+ $apa = plugin_load('admin', 'acl');
+ return $apa->_acl_add($scope, $user, $level);
+ }
+ 
+-function delAcl($scope, $user){
++/**
++ * Remove an entry from ACL config
++ *
++ * @param string $scope
++ * @param string $user
++ * @throws RemoteAccessDeniedException
++ * @return bool
++ */
++public function delAcl($scope, $user){
++if(!auth_isadm

Bug#780349: dokuwiki: The css of the generated page is empty.

[Tanguy Ortolo]

package dokuwiki
severity 780349 important
tags 780349 + moreinfo
thanks

Hello.

You issue sounds like some cases of Web server error, unfortunately I 
cannot reproduce it. If you still have this problem, could you provide 
your Web server error log while it happens?


Also, this should not render DokuWiki unusable: ugly, certainly, but 
hardly unusable, I am therefore lowering this bug severity.


Librement,

--
,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
\_


signature.asc
Description: Digital signature

Bug#764188: dokuwiki: [INTL:nl] Dutch translation of debconf messages

[Tanguy Ortolo]

Hello Frans,

Please notice that your translation was indicated to be encoded in 
UTF-8, but that it was in fact encoded in Latin1, and I had to iconv it 
to UTF-8 before adding it.


In the future, you should make sure that your MTA is not altering files, 
by either:

* switching to UTF-8;
* compressing them before attaching them.

Librement,

--
 ,--.
: /` )   ن Tanguy Ortolo
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#766545: CVE-2014-8763 CVE-2014-8764

[Tanguy Ortolo]

package dokuwiki
fixed 766545 dokuwiki/0.0.20140929.a-1
thanks

Moritz Muehlenhoff, 2014-10-23 23:11+0200:

Hi Tanguy,
CVE-2014-8763/CVE-2014-8764 have been assigned to this:
http://www.freelists.org/post/dokuwiki/Fwd-Dokuwiki-maybe-security-issue-Null-byte-poisoning-in-LDAP-authentication

There was also a CVE assignment for this issue, which is
already fixed in jessie:
https://github.com/splitbrain/dokuwiki/issues/765


No it is not fixed in Jessie. That is, it is now, or rather, it will be 
when the version 0.0.20140929.a-1 I have just uploaded will reach 
testing.



I don't know dokuwiki, should we fix the media manager issue in wheezy?


I do not think that only affects the media manager, but I will see to 
fix it in stable and oldstable, yes.


Librement,

--
 ,--.
: /` )   ن Tanguy Ortolo
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#765569: please add this script to use su instead of sudo (or the reverse) (e.g. for pdebuild)

[Tanguy Ortolo]

Package: devscripts
Version: 2.12.6+deb7u2
Severity: wishlist
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

I have written a script that can be used to replace sudo by using su
instead, or to replace su by using sudo instead.

This is useful for commands such as pdebuild, which normally use sudo,
can be configured to use another command, but that will then use it like
sudo (sudo-like-command command-to-run-as-root), so su cannot be used
instead (as it is meant to be used as su -c "command-to-run-as-root").

Since my scripts are not specific to pdebuild, but can be used for other
purposes, I suggest they are added to devscripts. Attached is a tarball
with: the scripts (in fact, a single one with a symlink, which acts
differently depending on how it is called), a manpage (in DocBook, and
compiled in Troff), and the Makefile to compile this manpage to Troff.

For convenience, I am also attaching the main script itself, so it can
be reviewed without having to extract the tarball.

Librement,

- -- 
 ,--.
: /` )   ن Tanguy Ortolo
| `-'Debian Developer   
 \_

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCgAGBQJUP5qaAAoJEOryzVHFAGgZ5coP/28jueFraUOfrE2am0HAcHlw
Qx4Uoejx2NCtkt8qVAGUBdt9RQO9vbhelfgfR125CbDZsbYOym/oCq7kPjpi4VQU
L7Db9bV66z9yrvryw/7Ujx+arstWE3w1d9mUG/yjAe5rQUOs3eVp+mY27iueP41B
SRvxG7s22KrKZbkR95kRDC3dqS2XwA1rw6h+Yuita1ZeB62g9mAvxxCxZEHSBAlV
5t0uQZAfNzBDnGZH1WH1yfoX+rgnUp3B0u2dy3lgx+3Kgtd1B9moS9vPiJllLj0f
U+ojzmSK1Y7wDHfGVIng1sxXiYPE2CmH4IU4ClYXNS8rdEVO4QzOKW8QmDOVvlWO
XkDsWvsSx1VbcNG+g2m6AwDTUriCMqD9h4HXbJTMJoDsF/SWaejhaj7J6i9hg5h7
qFr+kT8AYW93AH1qF+Y+wP2nUghhHi9vwtIyhMxvJ3aWJW0yc2C5GE6TZ/2KMsCt
5TKmSa+o2HRaEmekWyHAAcNfezGWh6uAtx9PV9yVI87oeANqRCDC+kFTPEVA4e5j
t0csF5rFKbZ9VWVsgZP7ueDhx7SiGuHmU6ImQq+Gw6nq05hbBj5K81MG5M0/aBkS
QQ8CqThJQMSpVQDbBZrlYMhAIZqseOIKLqhxMRJy8lXNKudji9f2zanPhhWDvIvp
6Xtl84d79YWkLbvbQnww
=GBV/
-END PGP SIGNATURE-


sudo-su.tar.xz
Description: application/xz
#! /bin/sh
set -e

# A wrapper around su and sudo to implement a basic sudo-style interface with
# su and a basic su-style interface with sudo.
# 
# This can be useful when using tools such as pdebuild(1) that integrate
# privilege escalation only with sudo, or only with su: by having it run
# this program instead, you actually use su, or sudo instead seemlessly.
#
# Copyright (C) Tanguy Ortolo  2011
#
# This program is free software. It comes without any warranty, to
# the extent permitted by applicable law. You can redistribute it
# and/or modify it under the terms of the Do What The Fuck You Want
# To Public License, Version 2, as published by Sam Hocevar. See
# http://sam.zoy.org/wtfpl/COPYING for more details. 


usage()
{
rc=$1
echo "Usage: sudo-su [SUDO_OPTIONS] COMMAND" >&2
echo "   su-sudo [SUDO_OPTIONS] -- [SU_OPTIONS] -c \"COMMAND\"" >&2
echo "sudo-su uses su to implement a basic sudo-style interface" >&2
echo "su-sudo uses sudo to implement a basic su-style interface" >&2
exit $rc
}

fake_sudo()
{

args="$(getopt -s sh -o +hisEu:o: --long help,login,shell,preserve-env,user:,options: -n "$0" -- "$@")"
if [ "$?" != 0 ]
then
usage $?
fi
eval set -- "$args"
while [ "$1" != "--" ]
do
case "$1"
in
-h|--help) usage 0 ; shift ;;
-i) su_options="$su_options -l" ; shift ;;
--login) su_options="$su_options --login" ; shift ;;
-s|--shell)
# This options is to get a shell instead of running a command,
# which is done with sudo by specifying no command to run.
shift ;;
-E) su_options="$su_options -p" ; shift ;;
--preserve-env) su_options="$su_options --preserve-environment"
shift ;;
-u|--user) user="$2" ; shift 2 ;;
-o|--options) su_options="$su_options $2" ; shift 2 ;;
esac
done
shift
if [ "$#" -eq 0 ]
then
# No command specified, the user wants to get a shell
exec su $su_options $user
else # The remaining arguments are the command to run
# Build a single string that will be used by su to run that command
# through a shell's -c options
command=""
for arg in "$@"
do
# To represent single quotes from single-quote mode:
# leave single-quote mode, enter double-quote mode, write the
# single quote, leave double-quote mode, enter single-quote mode.
arg="$(echo "$arg" | sed -e "s/'/'\"'\"'/g")"
command="$command${command:+ } '$arg'"
 

Bug#765451: Acknowledgement (New version 0.16 available)

[Tanguy Ortolo]

package gajim
block 765451 by 672847
thanks

As indicated, this new version depends on a new package, for a library 
that used to be part of gajim.


--
 ,--.
: /` )   ن Tanguy Ortolo
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#765451: New version 0.16 available

[Tanguy Ortolo]

Package: gajim
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

(Just for tracking changes, since there are several packages involved)

A new version of Gajim, 0.16, is available.

Gajim used to come with its own XMPP library, which has now been made a
distinct project, python-nbxmpp, and will have to be packaged, see ITP
#672847.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCgAGBQJUPjSQAAoJEOryzVHFAGgZQb0P/A8VVQqHeNaiO7heW5IDVQdP
ksGjaU1oC+R7cCbPTTWXDiDwf2c8PeOFHtYgq9sXpInfyNDxbr7C8HSyWEgrwvRj
7DrXxaXqg9lh4tsWKDRKZatEIb5uUblCGFbKY89ljIwi6rR8gmSrw5eG0hvhjpno
fTu9IoggFR6tzDJSr43iKvy4Q2v4SvT+S8kfJwlY/Pb3SSDwoFX8+nn6SBL98oUW
yYVL4FiGFM4Wos16/NzDCf7Fiiwlw2XqZrgeS6GxuqIUFCMIT5d1f2QgU+NOp1q9
OyMD00AiWqlfYHB9J/owk1XkK6ArYmLLzbm5f1IFHYjvf+tu7uT44COUm66fY/W0
xlVihtZ7k8on6dKNcnR4YmxeO+Euh7Cledh3bohtAKpjTjtcn110/DMOjskp75t3
8mGMepJ9BUAMx50ffJvu9ogI11OTB3gRewfFIO6nO+SWZQhpJOSp/xqfII9h00BZ
nr5HxNE123OVVBF3uPTG0slOTCvG1lc9VYRuWRMLgDZbG8eKeWVF6XkkBZJb73rW
VVY+YaNLeQmTDQdqW7FjrGW+eveCxSRgl3BT7csh0v916D+ElA2uI+mrLhkEVJfr
A1Au8ju0hqgT63JRAEZzP/r2NUhNMOeKogadF1j66k12DEgS3bFGS3T690y7+sNN
uGCkMO3kUkZXiRe3X5x1
=2CbC
-END PGP SIGNATURE-


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

Bug#672847: ITP: python-nbxmpp -- Non blocking Jabber/XMPP module

[Tanguy Ortolo]

package wnpp
retitle 672847 ITP: python-nbxmpp -- Non blocking Jabber/XMPP module
owner 672847 Tanguy Ortolo 
thanks

This library was part of gajim and was separated from it, so it is now 
necessary for newer versions of gajim. Too bad I was not noticed of that 
earlier.


Librement,

--
 ,--.
: /` )   ن Tanguy Ortolo
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#763053: dokuwiki: debconf does not set password

[Tanguy Ortolo]

Tobias Frost, 2014-10-01 08:39+0200:

For the other options I selected the defaults; NOTE, that this time
debconf did NOT ask for the password, but AFAIK this is OK as debconf
would not repeat questions if already asked).


Well, not exactly, With dpkg-reconfigure, it would ask everything, 
except the dokuwiki config script skips the user-related questions if 
there is already a user file.


Now, I think I found what causes this problem: when installing a 
package, the config script can be run twice, during preconfiguration 
and during postinst. During that second run, all questions have already 
be asked and are thus skipped, including the password question, which I 
configured to set the default password if the question is skipped!


Obviously, that way of detecting the the user did not have the 
possibility to set a password is incorrect. I think I will simply add 
the extra security I thought of initially: set the default password if 
the question was skipped *and* the “chosen” (or not) password is empty. 
This way, if the question was skipped but the user already chose a 
password, it will not force the default one.


That was tricky!

Librement.

--
 ,--.
: /` )   ن Tanguy Ortolo
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#763053: dokuwiki: debconf does not set password

[Tanguy Ortolo]

Tobias Frost, 2014-09-27 17:02+0200:

On a friendi's machine we just installed dokuwiki with lighttpd as webserver.
During installation, debconf askes for a password as intended.
However, the password is not set when trying to login (login error, wrong 
password)
Instead, the "default" password, as stated in README.Debian does work.



This is strange, since my config script is supposed to set that default 
password only if the question is not to be shown:


my @ret = input("high", "dokuwiki/wiki/password");
input("high", "dokuwiki/wiki/confirm");
my $skipped = 0;
if ($ret[0] == 30) {
# debconf is configured to skip even high priority questions;
# this is insane but we will have to set a default password
# nonetheless
$skipped = 1;
}
@ret = go();
if ($skipped)
{
set("dokuwiki/wiki/password", "fix-your-debconf-settings");
set("dokuwiki/wiki/confirm", "fix-your-debconf-settings");
}


Before I add some additional safety, like
`if ($skipped && get("dokuwiki/wiki/password") eq "")`, could you by 
chance tell me how debconf is configured on that server?



--
 ,--.
: /` )   ن Tanguy Ortolo
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#757570: NameError in StreamCB

[Tanguy Ortolo]

package gajim
forwarded 757570 https://trac.gajim.org/ticket/7816
thanks

Hello.

Jelmer Vernooij, 2014-08-09 15:25+0200:

I'm getting this error during normal use of gajim:

15:21:30 (W) gajim.c.x.dispatcher_nb Unknown stanza: error


I have just forwareded this issue to the upstream bug tracker. If you 
have more information about this issue, the upstream bug report page 
will is <https://trac.gajim.org/ticket/7816>.


Librement,

--
 ,--.
: /` )   ن Tanguy Ortolo
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#619824: sam2p -m:dpi:res generates bigger image for bigger resolution

[Tanguy Ortolo]

package: sam2p
forwarded 619824 https://code.google.com/p/sam2p/issues/detail?id=14
thanks

Hello, and sorry for taking so much time to anwser you on this bug 
report.


Tanaka Akira, 2011-03-27 23:33+0900:

I found that -m:dpi:res works that bigger resolution
generates bigger image.
But I think bigger resolution should generate smaller image.


So do I, so I have just submitted this issue to the upstream bug 
tracker. By the way, while looking at the few upstream issues, I noticed 
in one of them that it is possible to give negative DPI values, like:


% sam2p -m:dpi:-50 a.pbm 50dpi.pdf
% sam2p -m:dpi:-300 a.pbm 300dpi.pdf

Looking at the /usr/share/doc/sam2p/README.gz, which is the upstream 
README, this appears to be on purpose:

1. EPS and PDF are written with 72 dpi by default (1 pixel = 1 point);
2. -m:dpi:RES will make them at 72*72/RES;
3. -m:dpi:-RES will make them at RES.

I must say I fail to see the rationale for 2., but 3. works as I would 
expect.


Librement,

--
 ,--.
: /` )   ن Tanguy Ortolo
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#759316: Document the use of /etc/default for cron jobs

[Tanguy Ortolo]

Charles Plessy, 2014-08-27 06:56+0900:

I am unsure what the standard practice is in this situation.  Can you and
others comment on the existence or not of alternatives, in Debian and
elsewhere ?


The only alternatives I know of are:
1. to put all the configuration in the cron job script itself;
2. to put that configuration somewhere else in /etc.


If we document the use of /etc/default to configure cron jobs without
considering alternatives, the risk will be to push towards a Debian-only
standard, or worse, to push maintainers to modify upstream cron jobs using a
legitimate way to configure, but not using /etc/default.


Well, I think there are mostly two kind of packages that use cron jobs.  
First, software which use is partly based on a cron task, like 
logrotate, sks, apticron, popularity-contest, etc. For these packages, 
the cron job is normally provided in the upstream source, and for what I 
have seen, if needed they usually refer to a configuration file located 
in /etc but not /etc/default, like /etc/sks/cron.conf.


And second, software for which a cleanup or update task, while not 
essential to their use, is useful and has been added by the Debian 
package maintainer, like apache2 or bsdmainutils for instance, a 
configuration file /etc/default/package is used.


My opinion would be to keep packages of the first type as they are, as 
the cron job is part of the upstream source and should not be modified 
(unless it does thinks  like violating the FHS, that is). In fact, my 
proposal was rather to issue a recommendation for Debian packagers when 
they have to instal a cron job and allow the user to alter its behaviour 
with a configuration file.


--
 ,--.
: /` )   ن Tanguy Ortolo
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#756050: dokuwiki: Doesn't erase the cache nor does other needed maintenance

[Tanguy Ortolo]

Rodrigo Campos, 2014-08-26 01:55+0100:

On Mon, Aug 25, 2014 at 05:51:52PM +0200, Tanguy Ortolo wrote:

Given the importance of this modification, and the level of damage
it could do if we made a mistake (it deletes file in a wiki data
directory!), I will upload this revision to experimental: could you
please test it and confirm it does not delete production data? Only
after that will I be able to upload it to unstable.


Sure! I've just tried it and I can confirm it worked fine on my production
system. Let me explain how I tried it, just in case:

I installed the dokuwiki in my local PC, copied the cron file to my server (I've
done a snapshot just before trying this, of course ;) and changed all default
from false to true (so I try all the cases). Oh, and also commented the source
to /etc/default/dokuwiki as that file does not exist on my installation from
stable.


You could have copied /etc/default/dokuwiki that only exists for 
configuring the cron job!



Then run the script and everything went fine.

I didn't test changing the date of the files and verify they are deleted, but
that should work.

I've detected a very simple problem on my local machine, though. The line that
says:

find cache/?/ -type f -mtime "+$max_days" -delete

fails on a new dokuwiki installation. And it faile because the cache directory
is empty on a brand new installation. Just changing it to:

find cache -type f -mtime "+$max_days" -delete

works just fine (the "/?/" is not really important, as the filter for "-type f"
is there) because the cache directory is created during the installation.


Correct, I will apply the same.


If you want me to test something else, please let me know :)


That should be enough, I shall upload it to unstable soon. Thank you!

--
 ,--.
: /` )   ن Tanguy Ortolo
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#759316: Document the use of /etc/default for cron jobs

[Tanguy Ortolo]

Package: debian-policy
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

For practical reasons, variables that are used to configure init scripts
behaviour are placed in separate files in /etc/default, as documented in
Policy §9.3.2.

The same is often applied to cron jobs as well, for the same practical
reasons as crontab jobs are quite similar to init scripts (being both
configuration files and scripts, and containing both configuration and
code). But, contrary to init scripts, this practice is not yet
documented in the Policy.

I think this practice would be worth adding to the Policy, as it is both
useful and already used with no opposition as far as I know. If that
seems relevant, I can write a patch for that.

Regards,

- -- 
Tanguy Ortolo

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCgAGBQJT/D1rAAoJEOryzVHFAGgZUd8P/18b/q48c575Ur43BBpidc3D
F/GOLMmSzKK6mmcl9qhUHgGLIvddbaKTS1P0/eYr1B2naEvpYE8T0Q3/fIklfy9B
NYo9pDQvgoR6H8azWvH+TwgX/Yd5mZyIpSLBbg7hpUi1DYBytolGMNBWWT2uiJYO
tULX8huLatwF1ufEZPDPS8Hcjz2jHxNdEhB0QHJkWkSwRpIftgUKCjNKvYyByYxD
OQbI3ELCE4KOOPYM6YZUNgdtePr/v38CDsx+ro8QmXwqJGKK7xDbNmgdbBQgDB/c
P04imnyLxtgqkxrfJuTcoISIpETavLsYxsBfhMNISuQuEY3KaGXakh9GUIDHyMPQ
hRrGCNfzO2iAUAPmteRjUUctKN1xEZ9yxAneVQHvMiCVZD9fl1aSADBIi7lgk0KC
YYJ0sKKIHUvXVnD9wTY27mObmYnqO+h5HHnZDKGq4Lz44PntzX+VIdlVb0j3k4H5
sijwKEmYOlR4HX4nz7nehBMJyj7BPPOOw2+UmYeZtR7CTAqOFmiqYGgD3pCeaoqV
f6vPmzP4A8mS+QdcFCdi9Kchdh/Gf9rBKgOtu+RRtdTwK32eN2uOOb3j3dvK88Ql
VOvPPNfwEQb9YbJCIQQX4HjYsEc7HMfECGrKCJCZkyWDr1rKd7xpqw8TOlJ7fiE3
Dy2kE+J31bteSZB4NxC+
=NiNG
-END PGP SIGNATURE-


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

Bug#756050: dokuwiki: Doesn't erase the cache nor does other needed maintenance

[Tanguy Ortolo]

Hello,

Rodrigo Campos, 2014-07-25 19:12+0100:

The dokuwiki installation doesn't ever erase the cache. In my installation the
cache was using 750M and the whole data directory, excluding the cache, was 20M.

When looking how to erase the cache, I found this:
https://www.dokuwiki.org/tips:maintenance

Based on that, I did a script to erase the cache and some other stale files that
page recommends. And also update the wordlist. I attach the script just in case
is useful for you.

Please consider fixing this using the script or in some other way.


Thank you for reporting this issue. I used your script as a daily 
crontab script, with some modifications:

* switch to pure /bin/sh;
* use find -delete instead of find | xargs rm;
* make it modular so the user can configure in /etc/default/dokuwiki 
  whether or not to run the cleanup at all (default: yes), after how 
  many days a file is to be considered as old (default: 180), whether or 
  not to remove old revisions (default: NO!), and whether or not to 
  update the spam blacklist (default: no, as it implies importing data 
  from outside, which may or may not be possible or desirable depending 
  on the case).


Given the importance of this modification, and the level of damage it 
could do if we made a mistake (it deletes file in a wiki data 
directory!), I will upload this revision to experimental: could you 
please test it and confirm it does not delete production data? Only 
after that will I be able to upload it to unstable.


Regards,

--
 ,--.
: /` )   ن Tanguy Ortolo
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#664742: RFP: photoshow -- A free Web Gallery for your server

[Tanguy Ortolo]

package wnpp
retitle 664742 ITP: photoshow -- A free Web Gallery for your server
owner 664742 tanguy+deb...@ortolo.eu
thanks

Hello,

I will package that, as this is a project I have been looking at for 
some time, and it would be a fine replacement for my current Gallery 3 
installation, as Gallery 3 has been abandonned. Stay tuned, as they say.


--
 ,--.
: /` )   ن Tanguy Ortolo
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#755809: xorg.conf.5 man page mentions an incorrect "Enable" option for Monitors

[Tanguy Ortolo]

Julien Cristau, 2014-07-28 23:56+0200:

Note how the manpage says "enable all connected monitors", not "enable
all monitors".


Right, that was subtle but useful indeed. Here is an updated patch then.

--
 ,--.
: /` )   ن Tanguy Ortolo
| `-'Debian Developer   
 \_
Description: Complete the xorg.conf.5 manpage with Option "Disable"
 The xorg.conf.5 manpage mentions an "Enable" option to enable a monitor
 regardless of whether or not it is connected, but gives no indication of how
 to disable it. This patch corrects that by documenting the "Disable" option.
Author: Tanguy Ortolo 
Last-Update: 2014-07-29
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
Index: xorg-server/hw/xfree86/man/xorg.conf.man
===
--- xorg-server.orig/hw/xfree86/man/xorg.conf.man
+++ xorg-server/hw/xfree86/man/xorg.conf.man
@@ -1812,6 +1812,12 @@ at startup.  By default, the server will
 monitors.
 (RandR 1.2-supporting drivers only)
 .TP 7
+.BI "Option \*qDisable\*q \*q" bool \*q
+This optional entry specifies whether the monitor should be turned off
+at startup.  By default, the server will attempt to enable all connected
+monitors.
+(RandR 1.2-supporting drivers only)
+.TP 7
 .BI "Option \*qDefaultModes\*q \*q" bool \*q
 This optional entry specifies whether the server should add supported default
 modes to the list of modes offered on this monitor. By default, the server


signature.asc
Description: Digital signature

Bug#755809: xorg.conf.5 man page mentions an incorrect "Enable" option for Monitors

[Tanguy Ortolo]

Julien Cristau, 2014-07-28 16:47+0200:

On Mon, Jul 28, 2014 at 16:35:06 +0200, Tanguy Ortolo wrote:

Is that useful at all, considering that a monitor is on by default at
startup?

If needed, I can write a patch that documents both options, of course, but I
am not convinced that an option that does that same than the default
behaviour is useful.


That's not the same as the default behaviour.


Then what is the default behaviour? According to the manpage:

Option "Enable" "bool"
   This  optional  entry  specifies  whether the monitor should be
   turned on at startup.  By default, the server will  attempt  to
   enable  all  connected monitors.  (RandR 1.2-supporting drivers
   only)


If this is not the case, then this last sentence should be corrected as 
well, which I can do in the same patch, only I am not sure of what the 
default behaviour is then.


--
 ,--.
: /` )   ن Tanguy Ortolo
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#755809: xorg.conf.5 man page mentions an incorrect "Enable" option for Monitors

[Tanguy Ortolo]

Julien Cristau, 2014-07-27 14:11+0200:

The "enable" option forces a monitor on.


Is that useful at all, considering that a monitor is on by default at 
startup?


If needed, I can write a patch that documents both options, of course, 
but I am not convinced that an option that does that same than the 
default behaviour is useful.


signature.asc
Description: Digital signature

Bug#755809: xorg.conf.5 man page mentions an incorrect "Enable" option for Monitors

[Tanguy Ortolo]

Julien Cristau, 2014-07-24 22:46+0200:

I don't know what you think is incorrect about the existing text.


The existing texts is about an option named “Enable”, which may or may 
not exist, but does nothing and is thus useless to mention. The 
behaviour expected from that option (disabling a monitor at server 
startup) is achieved by using the option “Disable” which is not 
documented at all.


To be more specific, according to the man page:

Option "Enable" "bool"
   This  optional  entry  specifies  whether the monitor should be
   turned on at startup.  By default, the server will  attempt  to
   enable  all  connected monitors.  (RandR 1.2-supporting drivers
   only)


The following configuration should disable the projector monitor at 
startup:

Section "Device"
   Identifier  "Intel HD Graphics"
   Option  "Monitor-HDMI2" "Main"
   Option  "Monitor-HDMI1" "Projector"
EndSection

Section "Monitor"
   Identifier  "Main"
EndSection

Section "Monitor"
   Identifier  "Projector"
   Option  "Enable""false"
EndSection


But it does not work, and the projector is turned on at startup. On the 
contrary, the following, which uses an undocumented option “Disable” 
does disable the projector at startup:

Section "Device"
   Identifier  "Intel HD Graphics"
   Option  "Monitor-HDMI2" "Main"
   Option  "Monitor-HDMI1" "Projector"
EndSection

Section "Monitor"
   Identifier  "Main"
EndSection

Section "Monitor"
   Identifier  "Projector"
   Option  "Disable"   "true"
EndSection



My patch aims at correcting that by simply replacing the incorrect 
option “Enable” by the correct one “Disable” in the man page. It also 
does a small change in the explanation text since this option is used 
the reverse way:

Option "Disable" "bool"
   This  optional  entry  specifies  whether the monitor should be
   turned off at startup.  By default, the server will  attempt  to
   enable  all  connected monitors.  (RandR 1.2-supporting drivers
   only)


Librement,

--
 ,--.
: /` )   ن Tanguy Ortolo
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#755809: xorg.conf.5 man page mentions an incorrect "Enable" option for Monitors

[Tanguy Ortolo]

Julien Cristau, 2014-07-23 16:10+0200:

I believe this patch is wrong.


How so? I would be happy to provide an updated patch if you tell me what 
you think is wrong in it.


--
 ,--.
: /` )   ن Tanguy Ortolo
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#755809: xorg.conf.5 man page mentions an incorrect "Enable" option for Monitors

[Tanguy Ortolo]

Package: xorg-server
Version: 2:1.16.0-1
Severity: minor
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

The xorg.conf.5 man page mention an "Enable" Option for Monitors, which
does not work. The right option is in fact "Disable", as I indicated in
a blog post:

http://tanguy.ortolo.eu/blog/article128/ck-allow-suspend-xorg-disable-monitor

This small patch corrects it, please consider adding it.

Regards,

- -- 
 ,--.
: /` )   ن Tanguy Ortolo
| `-'Debian Developer   
 \_

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCgAGBQJTz7zmAAoJEOryzVHFAGgZBC4P/i7uLZ29STPqTaAds6UjTOn9
uIModwYUOp5nG/4LdVb5iPpf0lB72mIGbaDz54PkPr/UnnWBCaobJHc2o9PhRS1j
8I4YbVVovZhBYqCV3DZC4xbjZW5D2fiQUXtDFlwgsL2gC5Xrlz8fMQ2mGFG/RNh8
PCB+AR6D5mXcMkv7D59KjNJCegHWNo23H0IRQML5j/5moprkpHYRDKXZJ8I17Puy
sdsCD1kQ+t6W5OHJBquDR4Itwg0UwPkZdqiRQ99JConBKRH87pbKcD+pBLIeLRl0
ADqugcVU/QA3zILUWMxUUp1ZZNNenvv5TsVnCNF9azx9pGnE/ZyXzqrSVVgJFtLy
Mx2yO7+uxGMiNvow5UPLdOCW0gAl6JqnV8aAcQKV2zjxCJmF04O83avCf0xcsUjP
8pVC9S1KcT/SDckZ1pyeDkhprWUab2/50p0bh9zzsLz513h72+85omJc70wniYt7
vgOczHmofdKacp3J9w0vAoe+A05V+oAMfJqbg7G7HoHJxZrwkucWg493zEq+QKY4
P5V0jpSxyT0GTJLcX/v+2XAFGju4/CqklR6pWnLw9tw7B9n1v4waPgn9FSlSbFor
g2eF+UIibpuphHOTfXfBpEsGnp5zF13SAvqTZzktuar3wW4gYzH6wWuCFa6kkbUE
VTzdczq0Yl37asHQ84D0
=a7vq
-END PGP SIGNATURE-
Description: Correct the xorg.conf.5 manpage
 The xorg.conf.5 manpage mentions an incorrect "Enable" option for monitors.
 This patch corrects that by documenting the correct "Disable" option.
Author: Tanguy Ortolo 
Last-Update: 2014-07-23
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
Index: xorg-server/hw/xfree86/man/xorg.conf.man
===
--- xorg-server.orig/hw/xfree86/man/xorg.conf.man
+++ xorg-server/hw/xfree86/man/xorg.conf.man
@@ -1806,8 +1806,8 @@ This optional entry specifies that the m
 output (not monitor) of the given name.
 (RandR 1.2-supporting drivers only)
 .TP 7
-.BI "Option \*qEnable\*q \*q" bool \*q
-This optional entry specifies whether the monitor should be turned on
+.BI "Option \*qDisable\*q \*q" bool \*q
+This optional entry specifies whether the monitor should be turned off
 at startup.  By default, the server will attempt to enable all connected
 monitors.
 (RandR 1.2-supporting drivers only)

Bug#752676: dokuwiki: wrong link in README.Debian

[Tanguy Ortolo]

Bernard Massot, 2014-06-25 16:23+0200:

The link about stylesheet loading in README.Debian.gz should be 
https://www.dokuwiki.org/devel:css#user_styles (instead of 
http://wiki.splitbrain.org/wiki:devel:css#stylesheet_loading).


That is right, thank you for reporting that. Given the low importance of 
that, I will probably wait before uploading an update, to see if there 
are other things I could fix at  the same time.


Regards,

--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#752084: Debian lists need a plan to deal with messages from DMARC p=reject domains

[Tanguy Ortolo]

Marco d'Itri, 2014-06-19 16:10+0200:

The possible solutions are:

a) keep rejecting mail from these domains

b) rewrite the From headers of messages from these domains

c) implement a permanent and elegant solution like 
http://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail#Relay_one_copy_through_author_domain_server


d) set up lists so DKIM-signed messages are not modified in any way
Mailing lists break SPF and solutions to that are heavy, but DMARC 
relies on /either/ SPF /or/ DKIM, and mailing-lists do not necessarily 
break DKIM: they only do when the message is altered, often to add a 
footer explaining how to unsubscribe. Now, there has been a standard 
mail header for that for some time, which should now be recognized by 
all serious mail user agents, so altering messages to add such a footer 
could be avoided now, at least for DKIM-signed messages.


--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#745134: live-build: please add man pages for lb commands

[Tanguy Ortolo]

package live-build
reopen 745134
thanks

Excuse me, but this has not been fixed, and the point of the bug 
tracking system is to track bugs, which cannot be done properly this 
way. To quote the Debian Policy, §12.1 [1]:
If no manual page is available, this is considered as a bug and should 
be reported to the Debian Bug Tracking System (the maintainer of the 
package is allowed to write this bug report themselves, if they so 
desire). Do not close the bug report until a proper man page is 
available.


[1] https://www.debian.org/doc/debian-policy/ch-docs.html#s12.1

Also, for readers of this bug, the missing manpages are present in 
the previous version of live-build, so you can get a properly documented 
live-build by installing the version 3.0.5-1, available in Debian 
stable.


Regards,

--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#518069: #518069 - D-Bus daemon is auto-spawned several times upon login

[Tanguy Ortolo]

althaser, 2014-05-14 16:40+0100:

this is an old bug.


A demon of the ancient world indeed. :-)


Could you please still reproduce this issue with newer gnome-session
version like 3.4.2.1-4 or 3.8.4-4 ?


I have mostly stopped using GNOME for years, but I used it from time to 
time, and I do remember being able to launch it with xinit without any 
problem. As far as I remember, running `xinit /usr/bin/gnome-session` 
has been working fine for years.


Regards,

--
,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
\_


signature.asc
Description: Digital signature

Bug#740708: libjack0:amd64 uninstallable with libjack0:i386

[Tanguy Ortolo]

Hello,

This issue is pretty annoying for Debian testing, as it renders Wine 
uninstallable on amd64, as it depends on libjack0:i386, which is 
uninstallable together while keeping libjack0:amd64.


Since it seems to be caused only by the tiny version number difference 
which was introduced by the binNMU, there should be a very simple fix 
for it: artificially bump the version number to 
1:0.124.1+20140122git5013bed0-3, changing nothing else, upload and let 
the buildd do the job, producing binaries linked with db5.3 for all 
architectures.


Can Debian Multimedia Maintainers do that, or should I (src)NMU it?

--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#742795: when selecting no webservers to configure, asks whether to restart

[Tanguy Ortolo]

Thijs Kinkhorst, 2014-03-27 16:13+0100:

If you unselect all webservers in the debconf question on which one to
configure, after that still a question appears about whether the webserver
should be restarted. This could of course be omitted in that case.


Indeed, thanks for the suggestion, I shall do that in the next revision. :-)

--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#736079: gajim doesn't start

[Tanguy Ortolo]

Andrey Gusev, 2014-01-19 18:55+0400:

Dear Maintainer,
I try to start gajim and it doesn't start. The oputput to console is
Traceback (most recent call last):
 File "gajim.py", line 217, in 
from ctypes import CDLL


Can you try that alone in a plain Python interpreter?


from ctypes import CDLL


If it yields the same result, then it is likely a Python bug only.

--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#735504: Sourceless file

[Tanguy Ortolo]

package pluxml
reopen 735504
retitle 735504 Add a lintian override for themes/defaut/js/respond.min.js
severity 735504 wishlist
thanks

Bastien ROUCARIES, 2014-01-16 22:56+0100:

Could you add a Lintian override ? It hard to spot.


Sure, I will, but since it is not very important or urgent, I will 
probably wait for the next version or for other modifications to avoid 
an upload just for that. For now, that issue is documented in 
debian/copyright, which is enough for people wondering.


Librement,

--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#725778: libasyncns:config.guess/config.sub out of date for arm64

[Tanguy Ortolo]

Wookey, 2014-01-09 18:37+:

I was talking about the patch in the initial bug report (providing a
full dh-autoreconf), versus my patch providing only dh-autotools-dev
updates. Sorry if that wasn't clear.


I see. For some reason, I completely missed that bug report, so I 
supposed it was new. Sorry about that, I shall fix it soon them, no 
problem.


--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#725778: libasyncns:config.guess/config.sub out of date for arm64

[Tanguy Ortolo]

Wookey, 2014-01-09 03:12+:

The automatic autoreconf in the above patch is generally best, but if
you baulk at that I can confim that the attached more conservative
dh-autotools-dev patch also fixes the ftbfs for arm64.


You are mentionning two possible patches but providing only one, as it 
seems. Forgot to attach one?


--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#733458: gajim: Additional dependency needed for sound playback

[Tanguy Ortolo]

Ralf Jung, 2013-12-29 00:30+0100:

to properly play notification sounds, gajim needs either aplay, play or 
ossplay. So the package should depend on either of these.
Also see <https://trac.gajim.org/ticket/7608>.


Correct, I shall add these dependencies. But do you know what Gajim does 
when none of them are available? Unless it always crash, I think I will 
add these as Recommends rather than Depends, since sound notification is 
only a secondary feature of Gajim, not a core one I think: without 
sound, its basic functionnality, which is XMPP chat, is still available.


--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#733625: new upsteam (2013-12-08)

[Tanguy Ortolo]

Daniel Baumann, 2013-12-30 15:02+0100:

It would be nice if you could upload the current upstream release to debian.


Indeed. I did not see it as upstream changed their release location, 
breaking my watch file. Bad news is, their current release convention 
will not allow any watch file to work. :-(


--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#730564: Japanese template translation (was: dokuwiki 0.0.20130510a-2: Please update debconf PO translation) for the package dokuwiki

[Tanguy Ortolo]

Package: dokuwiki
Version: 0.0.20130510a-3
Severity: wishlist
Tags: patch, l10n
Control: retitle -1 Japanese template translation

victory, 2013-11-27 00:41+0900:

here's a ja.po file for dokuwiki if you haven't received from someone


I did not, thank you. I am opening a bug report not to forget it.

--
< o   TanguyQuant les hommes ne peuvent changer les choses,
 /--)   ils changent les mots.
/ > -+- Jean Jaurès -+-


ja.po.gz
Description: Binary data


signature.asc
Description: Digital signature

Bug#729042: gajim: Self-signed SSL certificates are lost on exit

[Tanguy Ortolo]

package gajim
forwarded 729042 https://trac.gajim.org/ticket/7575
thanks

Salut Roland.

Roland Mas, 2013-11-08 10:30+0100:

I run my own ejabberd server, with a self-signed certificate.  After
creating an account there (outside Gajim), I can connect Gajim to that
account, and I get a dialog warning me about the unknown certificate
("SSL Error: Unable to get local issuer certificate").  This is
expected.

Now if at any time I tick the "Ignore the error for this certificate"
checkbox in the dialog before clicking OK, I can connect and chat.  But
I can only connect once: as soon as I go offline (or restart Gajim),
trying to connect again doesn't display the dialog (which is expected),
but the connection doesn't proceed.


Thanks for the report, I have forwarded that to the upstream bug tracker.

Librement,

--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#658905: gajim fails to start

[Tanguy Ortolo]

Thomas Prokosch, 2013-11-24 22:32+0100:
You are right - if it is data that is going to be written here, it 
really does not make much sense to insist on a read-only $HOME. One 
can always redirect $XDG_DATA_HOME to some other location.


That seems to be the most sensible solution indeed. Perhaps to something 
under /tmp.


Thank you for helping me. I think we can refrain from forwarding that 
request, and thus give the developers some time back so that they are 
able to develop some desired features and/or fix real bugs :)


Good. Do you want me to mark this bug as wontfix, to close it as not 
really a bug, or something?


--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#721790: pluxml: General update after the debconf review process

[Tanguy Ortolo]

Christian PERRIER, 2013-10-30 17:59+0100:

Please consider using it EVEN if you committed files to your
development tree as long as they were reported.

The attached tarball contains:

- debian/changelog with the list of changes


Nothing to add to my current changelog. :-)


- debian/control with rewrites of packages' descriptions


I take that.


- debian/ with all the rewritten templates file(s)
- debian/po/*.po with all PO files (existing ones and new ones)


I do not take that, since I already have the corrected templates and 
their translations, plus a correction of my own: in the language 
selection template, the value has to be a two-letter language code, not 
an English or native language name.


So, taking these templates and correction would add nothing but a bug I 
already corrected: I will not take that.


For future reference: when a select-type template has __Choices and 
Choices-C, the Default (or _Default and translated values) must be taken 
among the Choices-C, not among the __Choices or their translations. 
Careful with that, since it may have a high confusion potential for both 
translators and the package maintainer.



As said, please use *at least* the PO files as provided here,
preferrably over those sent by translators in their bug reports. All
of them have been checked and reformatted. In some cases, formatting
errors have been corrected.


No, fortunately, nothing was added compared to what I have.

--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#658905: gajim fails to start

[Tanguy Ortolo]

package gajim
retitle 658905 fails to start it ~/.local is not writable
severity 658905 normal
thanks

Hello Thomas.

First of all, sorry for the very high delay of response, I have taken 
over the maintenance of the package gajim and this bug is anterior to 
that.


Thomas Prokosch, 2012-02-06 18:33+0100:

In case gajim cannot create a subdirectory share within directory $HOME/.local, 
it fails to start with the following error message:

[…]

In this case, gajim should revert to the default configuration and start 
nevertheless.


Yes, except here, it is not trying to save any configuration but some 
data. I am not certain that Gajim is supposed to work if it cannot write 
any data, but if you really want to work with a read-only /home file 
system, you may want to mount some tmpfs on that directory ~/.local, 
perhaps using aufs or unionfs?


I may forward this bug to the upstream developers, but they may consider 
it normal that Gajim does not work correctly under such an environment. 
Do you want me to try forwarding it anyway?


Regards,

--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#725196: gajim: segmentation fault when double clicking contact in unified chat window

[Tanguy Ortolo]

package gajim
tag 725196 + moreinfo unreproducible
severity 725196 important
thanks

Hello.

I cannot reproduce that bug, and in fact, nobody to whom I spoke can, 
including the upstream developer. If you can still reproduce it and 
provide us with a gdb backtrace as explained by Dominik, that would 
allow the upstream developer to identify and fix that bug.


For now, I am lowering this bug's severity, since it only seems to 
affect you and thus does not render this package unusable, not even for 
you in fact, since there is a work around, even though it may be more or 
less inconvenient.


Regards,

--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#728199: fails to upgrade: ln: failed to create symbolic link '/etc/apache2/conf-available/dokuwiki.conf': File exists

[Tanguy Ortolo]

Hello again.

I finally understood what caused this error. This is subtle and I was 
not expecting it! In the postinst, I test for the existence of 
/etc/apache2/conf-available/dokuwiki.conf, and I install it a a link to 
/etc/dokuwiki/apache.conf only if it does not. The problem is that the 
test dereferences it if it is a symlink.


My guess is that, with the previous version of the package, which was 
not adapted to apache2 >= 2.4, you did a symlink 
/etc/apache2/conf-available/dokuwiki.conf -> 
/etc/apache2/conf.d/dokuwiki.conf.  Since the file 
/etc/apache2/conf.d/dokuwiki.conf is removed just before the test, it is 
considered a /not existing/ by the test!


I think I will fix that by adding an additional test: if 
/etc/apache2/conf-available/dokuwiki.conf exists but is only a symlink, 
remove it, considering it was added by the user for apache2 >= 2.4 
compatibility.


Regards,

--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#728199: fails to upgrade: ln: failed to create symbolic link '/etc/apache2/conf-available/dokuwiki.conf': File exists

[Tanguy Ortolo]

Thijs Kinkhorst, 2013-10-29 13:35+0100:

dokuwiki fails to upgrade, and exits the upgrade with an error.
Turning set -x on in postinst, this is what happens:

+ [ -e /etc/apache2/conf.d/dokuwiki.conf ]
+ [ -d /etc/apache2/conf-available -a ! -e 
/etc/apache2/conf-available/dokuwiki.conf ]
+ ln -s /etc/dokuwiki/apache.conf /etc/apache2/conf-available/dokuwiki.conf
ln: failed to create symbolic link '/etc/apache2/conf-available/dokuwiki.conf': 
File exists
dpkg: error processing dokuwiki (--configure):
subprocess installed post-installation script returned error exit status 1

The code fails because /etc/apache2/conf.d/dokuwiki.conf, the link target,
does not exist (it is removed in the same script) and therefore the -e
on the link itself fails.


I do not understand how that is possible. The script checks that the 
directory /etc/apache2/conf-available exists and that the file 
/etc/apache2/conf-available/dokuwiki.conf /does not exist/, then fails 
to create a symlink /etc/apache2/conf-available/dokuwiki.conf because 
that files /already exists/???


So, you have a file named /etc/apache2/conf-available/dokuwiki.conf? 
What is it, a regular file or a symlink? Do you have any idea why it was 
created?


--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#727140: order of conf files

[Tanguy Ortolo]

Hontvári József Levente, 2013-10-27 18:21+0100:

The emphasis is on "if dokuwiki is installed in the root path". In that
case the two aliases are "/javascript" and "/", which are overlapping.


Right, well, I am afraid this is a specific case that I did not expect, 
and that I will not be able to support. Anyway, the initial configuration 
of the webserver for DokuWiki is only meant as a starting base, and in 
most production cases it will have to be customized by the user.


--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#727140: dokuwiki is not installed into apache

[Tanguy Ortolo]

Hontvari Jozsef Levente, 2013-10-22 17:39+0200:

The problem is that the postinst script tries to create a link in 
/etc/apache2/conf.d to /etc/dokuwiki/apache.conf. However, apache has no conf.d 
directory. It has conf-available and conf-enabled directories.


Right, this is because of the new configuration structure with 
apache2 >= 2.4. I will update the package now, sorry for the delay.


--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#727140: order of conf files

[Tanguy Ortolo]

Hontvári József Levente, 2013-10-25 13:48+0200:

I would add, that creating the link
/etc/apache2/conf-available/dokuwiki.conf is not enough if dokuwiki is
installed in the root path, e.g. wiki.example.com. In that case
javascript-common.conf, which is dependency, will be read only after
dokuwiki.conf. The order is important, the javascript-common "Alias
/javascript /usr/share/javascript/" directive must come first, before
the  dokuwiki "Alias / /usr/share/dokuwiki/" directive. Using the link
name zzzdokuwiki.conf, for example, solves the ordering issue.


Are you sure about that? For what I understand, order is not relevant at 
all, since all these only defines what the web server will answer to 
client's requests: requests to think in /dokuwiki will use one alias, 
and thos in /javascript will use the other, no matter what request is 
made first by the browser…



I do not know Apache2 enough, but I guess a more elegant solution would
be to adding dokuwiki to apache as a virtual host, instead of a server
level configuration. In that case the name of the link would not affect
the behavior.


No, a virtual host would not be acceptable and is better left to the 
user when he polishes his installation, since we cannot guess if he will 
want an IP address-based virtual host or a name-based virtual host, and, 
most importantly, all these require network configuration, while the 
current default path-based solution just works once the package is 
installed. Or rather, will work when I fix it, that is. :-)


--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#723798: pu: package gajim/0.15.1-4

[Tanguy Ortolo]

Cyril Brulebois, 2013-09-23 05:14+0200:

Also, one can wonder why urgency is high for an upload prepared in
april, and not going through security channels.


I was not maintaining this package at that time, and I just took the 
proposed NMU, thinking that urgency was relevant. If it is not, I can 
change it, no problem.


Librement,

--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#723798: pu: package gajim/0.15.1-4

[Tanguy Ortolo]

package gajim
fixed 693282 0.15.4-1
thanks

Adam D. Barratt, 2013-09-19 23:08+0100:

If http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693282#50 is correct
and the bug is already fixed in unstable, please also add an appropriate
fixed version.


Indeed. I have just checked, the changes that fix it are included in 
upstream release 0.15.4.


--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#723915: postfix: please add /etc/host.conf to the chroot

[Tanguy Ortolo]

Package: postfix
Version: 2.9.6-2
Severity: wishlist
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,


Using mailman and Postfix (but that would have been the same with any software
locally sending mail to Postfix using ::1), I had tons of such warnings:

Sep 21 09:37:49 dick postfix/smtpd[18250]: warning: ::1: address not listed 
for hostname localhost


According to the thread [1], this is because the multiple address resolutions
for /etc/hosts. This seems not to be the default of libc, but to be enabled in
/etc/host.conf anyway in Debian installations. However, that file is not copied
to the Postfix chroot…

[1] 
http://postfix.1071664.n5.nabble.com/Issues-with-address-not-listed-for-hostname-td51442.html


Here is a very simple patch that adds /etc/host.conf to the list of files that
are copied to the chroot.


Librement,

- -- 
Tanguy Ortolo

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCgAGBQJSPVa/AAoJEOryzVHFAGgZHeQP/1obuhF4zFJbidvrQSRfq1Ko
UyCVU7jY2P1R8tBVWn9NfMV7njJcwe8RbojmEYVU+SF9XGkpROLBBsbRe196VqUn
Xfw2/H6iu1zIiNwNltbjuXxFuL0PuB/7u+j2w9cDE5uLOrlY3Q8GAmSwpAzz7Zlv
FPaA8/buxzQYlxs+xakhKxukAhvqYIZk5TKzOfjc9Whmg/LyjyLp4wM19+P9wCbM
PejYjqI/QYKvRknimo3yfp+dvgTsLOJN6LAROhXZOqXx3cRYf83mEOLNoWiSCnTu
Bw3Jl3h3KkRFnfWZ2pC7NhROr+bTrJz6IERA7raQ4fq7LFujYSqVfUmNIw6SEr0p
OBoPJTk/sNc3CrzIajRLJGuRYU36kZ40De4K0iyRNP3pXPRNLI16P99VposWIXnD
JfelzDmOqcj+JU7V0WQjk6xYAooYjmSr9EzfkNLPiFpegG1Fjh3uY2CDezGfVB1X
kY+Ypt3rIlkgGLuYVc0MHtl0vrmjY6w19JFSzMAFukqYsy68ZdtrJMVbHNenUt77
/KXNtUPJlvFyAIjdShjNl5w8YjT1x0INHJ6oT8xWxQ8Xm57926T5ywrx7MkO2aMT
q6To0A1LsfVHUYIyB7mUhRArEufjKPPqAokC9X6m7Lx6/eTV1CfXR1QIWDsRt5Lm
1zIi94AfDhlio3leajAX
=cRIE
-END PGP SIGNATURE-
>From a34aaab01588853e13087f734507278828c718ac Mon Sep 17 00:00:00 2001
From: Tanguy Ortolo 
Date: Sat, 21 Sep 2013 10:03:46 +0200
Subject: [PATCH] Init script: also copy /etc/host.conf to the chroot
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="true"

This is a multi-part message in MIME format.
--true
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit

---
 debian/init.d |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


--true
Content-Type: text/x-patch; name="0001-Init-script-also-copy-etc-host.conf-to-the-chroot.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="0001-Init-script-also-copy-etc-host.conf-to-the-chroot.patch"

diff --git a/debian/init.d b/debian/init.d
index 04669db..837d7ac 100644
--- a/debian/init.d
+++ b/debian/init.d
@@ -94,7 +94,7 @@ case "$1" in
 		fi
 
 		FILES="etc/localtime etc/services etc/resolv.conf etc/hosts \
-		etc/nsswitch.conf etc/nss_mdns.config"
+		etc/nsswitch.conf etc/nss_mdns.config etc/host.conf"
 		for file in $FILES; do 
 		[ -d ${file%/*} ] || mkdir -p ${file%/*}
 		if [ -f /${file} ]; then rm -f ${file} && cp /${file} ${file}; fi

--true--

Bug#723798: pu: package gajim/0.15.1-4

[Tanguy Ortolo]

Julien Cristau, 2013-09-19 23:48+0200:

The debdiff should be in this bug, please.


Sorry, I thought I did it. Here it is.

--
  ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
  \_
diff -u gajim-0.15.1/debian/changelog gajim-0.15.1/debian/changelog
--- gajim-0.15.1/debian/changelog
+++ gajim-0.15.1/debian/changelog
@@ -1,3 +1,14 @@
+gajim (0.15.1-4.1) stable; urgency=high
+
+  * Non-maintainer upload by the Security Team.
+  * debian/patches:
+- 02_fix-cert-validation.diff added, fix certificate validation
+  (CVE-2012-5524)   closes: #693282
+- 03_correctly-get-SSL-certificate and 04_store-all-ssl-errors added,
+  improve SSL/TLS handling.
+
+ -- Yves-Alexis Perez   Wed, 17 Apr 2013 22:22:30 +0200
+
 gajim (0.15.1-4) unstable; urgency=low
 
   * apply patches using dpatch in debian/rules
diff -u gajim-0.15.1/debian/patches/00list gajim-0.15.1/debian/patches/00list
--- gajim-0.15.1/debian/patches/00list
+++ gajim-0.15.1/debian/patches/00list
@@ -2,0 +3,3 @@
+02_fix-cert-validation.diff
+03_correctly-get-SSL-certificate.diff
+04_store-all-ssl-errors.diff
only in patch2:
unchanged:
--- gajim-0.15.1.orig/debian/patches/04_store-all-ssl-errors.diff
+++ gajim-0.15.1/debian/patches/04_store-all-ssl-errors.diff
@@ -0,0 +1,64 @@
+#! /bin/sh /usr/share/dpatch/dpatch-run
+## 04_store-all-ssl-errors.diff by 
+##
+## All lines beginning with `## DP:' are a description of the patch.
+## DP: store all SSL errors
+#
+# Description: store all SSL errors
+# Author: Yann Leboulanger 
+# Origin: upstream,https://trac.gajim.org/changeset/1d8caae49a31#file0
+# Last-Update: 2013-04-17
+# HG changeset patch
+# User Yann Leboulanger 
+# Date 1360768361 -3600
+# Node ID d34a996f87b81afe6dc60d04d0141c39fa3d3595
+# Parent  385f8a1fad668fbcd1d9bee10f61531a8ca7d890
+
+@DPATCH@
+
+diff -r 385f8a1fad66 -r d34a996f87b8 src/common/xmpp/tls_nb.py
+--- a/src/common/xmpp/tls_nb.pyWed Feb 13 16:10:44 2013 +0100
 b/src/common/xmpp/tls_nb.pyWed Feb 13 16:12:41 2013 +0100
+@@ -393,7 +393,7 @@
+ flags |= 16384
+ tcpsock._sslContext.set_options(flags)
+ 
+-tcpsock.ssl_errnum = 0
++tcpsock.ssl_errnum = [0]
+ tcpsock._sslContext.set_verify(OpenSSL.SSL.VERIFY_PEER,
+ self._ssl_verify_callback)
+ try:
+@@ -449,11 +449,11 @@
+ def _ssl_verify_callback(self, sslconn, cert, errnum, depth, ok):
+ # Exceptions can't propagate up through this callback, so print them 
here.
+ try:
+-self._owner.ssl_fingerprint_sha1 = cert.digest('sha1')
+-self._owner.ssl_certificate = cert
+-self._owner.ssl_errnum = errnum
+-self._owner.ssl_cert_pem = OpenSSL.crypto.dump_certificate(
+-OpenSSL.crypto.FILETYPE_PEM, cert)
++self._owner.ssl_fingerprint_sha1.append(cert.digest('sha1'))
++self._owner.ssl_certificate.append(cert)
++self._owner.ssl_errnum.append(errnum)
++self._owner.ssl_cert_pem.append(OpenSSL.crypto.dump_certificate(
++OpenSSL.crypto.FILETYPE_PEM, cert))
+ return True
+ except:
+ log.error("Exception caught in _ssl_info_callback:", 
exc_info=True)
+diff -r 385f8a1fad66 -r d34a996f87b8 src/common/xmpp/transports_nb.py
+--- a/src/common/xmpp/transports_nb.py Wed Feb 13 16:10:44 2013 +0100
 b/src/common/xmpp/transports_nb.py Wed Feb 13 16:12:41 2013 +0100
+@@ -311,6 +311,12 @@
+ self.proxy_dict = proxy_dict
+ self.on_remote_disconnect = self.disconnect
+ 
++# ssl variables
++self.ssl_fingerprint_sha1 = []
++self.ssl_certificate = []
++self.ssl_errnum = []
++self.ssl_cert_pem = []
++
+ # FIXME: transport should not be aware xmpp
+ def start_disconnect(self):
+ NonBlockingTransport.start_disconnect(self)
+
only in patch2:
unchanged:
--- gajim-0.15.1.orig/debian/patches/02_fix-cert-validation.diff
+++ gajim-0.15.1/debian/patches/02_fix-cert-validation.diff
@@ -0,0 +1,84 @@
+#! /bin/sh /usr/share/dpatch/dpatch-run
+## 02_fix-cert-validation.diff by 
+##
+## All lines beginning with `## DP:' are a description of the patch.
+## DP: fix certificate validation
+#
+# Description: fix certificate validation
+# Author: Yann Leboulanger 
+# Origin: upstream,https://trac.gajim.org/changeset/1d8caae49a31#file0
+# Last-Update: 2013-04-17
+
+@DPATCH@
+
+Index: gajim/src/common/connection.py
+===
+--- gajim/src/common/connection.py (revision 14377)
 gajim/src/common/connection.py (revision 14379)
+@@ -1312,19 +1312,22 @@
+ errnum = con.Connection.ssl_errnum
+ except AttributeError:
+-errnum = -1 # we don't have an errnum
+-if errnum > 0 and str(errnum) not in gajim.config.get_per(&

Bug#723798: pu: package gajim/0.15.1-4

[Tanguy Ortolo]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

The version of gajim currently in stable, 0.15.1-4, has a security bug,
CVE-2012-5524 / Debian #693282. corsac has prepared an NMU for that, and I was
suggested to upload it for a point release.

The resulting package version, 0.15.1-4.1, is available there, with a debdiff
and everything:
http://tanguy.ortolo.eu/deb/gajim/

Can I go ahead and upload it?

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

Kernel: Linux 3.9-1-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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCgAGBQJSO21PAAoJEOryzVHFAGgZtkUP/2u82vgKnVp6PyRXmzSc/FE5
BC8URbtlx1X6TjBSjc6Tdi1XSLPfEeg7qU0C64K+eg9K+iJvsb3pZfu5rQXs2Zye
Cfvmb0MhsoqRGAiR46QAfYM9hvPFE5LD+rW7XDeSidbWvbDeKK+v/Vj5lplIMYuQ
Vk9uL7uKabkfSlaiqk1n1FSQZKfXNOSPlH0Yjscl7JYH8YRzfEizReAI9O7F5ftu
RESofF9Kck/XOapvPB9Fu3OIk9m6F1aXEciko5LfiwVQmfQ7gx9Aw+3vZ2TNHbtp
bl8ihNMNT8cCWEj2B3x0822sZJpzUkdmlB67M7pRenAc4BEszll3zawGzpOFHwIp
Bwm3SWaZlq9kM/MYwS4mAvNp+DolDtUnJB3bAIDLaRe+A3Jl578o+k6Pm8qBNR68
WP/Hzq9+p7ww2lo1jbLV9d3wHmbzxKhNJLq8MG2VBdsF1Z8nWqyT2Q6UX8SRE5xJ
mZkV4BJjJds2tB51SKsvrD00AIorSehrjjKOFU9RSlErJZcGpg0Ocg4JVpWeZdBQ
Q58eXd6c5DJXPcTW+QO/nW8nVBvxs3sfQhNdy/2A3Pwcg+Izo+dhZBvKOTfGnZlZ
QRU/Qd3Nl4lwEBGmSUjD1Q/Q+d+lbXEonkyJYZ7cJ/LtYV9sLMWNOLWkY3q3MR6F
lFmg5COTw87vnjbRN1Sr
=mpEU
-END PGP SIGNATURE-


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

Bug#693282: gajim: CVE-2012-5524

[Tanguy Ortolo]

Giuseppe Iuculano, 2013-09-16 10:05+0200:

we marked this as minor issue and it would be nice to fix it through a
point update:
http://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable


Since I adopted the package gajim, I have to find some time to prepare 
that. But if someone has time to do it before I can, go ahead.


--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#722681: latexila: Default build settings do not work

[Tanguy Ortolo]

Adrian Immanuel Kiess, 2013-09-13 10:50+0200:

the default compiler setting for LaTeXila do not work.

I guess I would have to remove -synctex=1 from build options.


Yes, I saw that. The fix is for me to adopt the package latexmk and 
upload a new version, so it will require some time…


--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#721790: [ITR] templates://pluxml/{templates}

[Tanguy Ortolo]

Christian PERRIER, 2013-09-08 16:23+0200:

The first step of the process is to review the debconf source
template file(s) of pluxml. This review will start on Wednesday, September 11, 
2013, or
as soon as you acknowledge this mail with an agreement for us to
carry out this process.

If you approve this process, please let us know by replying to this
mail.


Sure, please go ahead, and thanks for the involvement!

--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#721941: dokuwiki: Let me reserve rights to content, or abort installation

[Tanguy Ortolo]

package dokuwiki
reopen 721941
thanks

Mark Carroll, 2013-09-05 20:56+0100:

I am sorry that you took umbrage, but I actually chose my words more
carefully than that: it is my notes that I wrote of, not myself. I've
been happily using Debian since 0.93R6 and like the idea of the GPL; I
just think it's going surprisingly far, without some larger policy
decision that perhaps I missed, to insist that the free licensing
extends to the information processed by the software too. It's like if I
installed gcc and was asked to say that all the code I compile with it
has to be noncommercially shareable, or likewise with apache and web
pages. It's not unthinkable, but it's weird to spring this on people in
this way.


Okay, I understand your surprise. Now, the origin of that is that wikis 
are mostly used to share content, so in their most common use, they 
require a content license. DokuWiki, in its unpackaged install script 
(that is the install.php that is included), offers a choice of common 
licenses for that.


I agree that another alternative use of wikis is personal content 
management, but in that case, the wiki is usually made accessible only 
to the local host or network, and that possibility is implemented as an 
installation question in the Debian package. For personal content 
management over the Internet, that restriction should be replaced by 
some user/password, but the idea is the same: restrict access to 
yourself only. So, in these cases, the license really does not matter 
since you are the only one to see your own content.


For the other, really specific possible uses, I agree that the way to 
choose a custom license could be made more evident, so I will change the 
question text so it explains that the license can be changed after the 
installation, even to a specific license or to the null one, by editing 
two files.



Thank you for the instructions; of course, I don't agree that the bug is
at all non-existent, but I must grant that you are far more polite and
responsive than many other maintainers. At least you've pointed the way
to alternative ways to install.


Since I just told I was going to do something about it, I am reopening 
this bug. :-)


--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#721790: pluxml: [debconf_rewrite] Debconf templates and debian/control review proposal

[Tanguy Ortolo]

Christian Perrier, 2013-09-04 07:21+0200:

I would like to suggest you to consider calling for debconf templates
review AND translation updates when you introduce new debconf
templates or modify the existing templates in a package or, if you
prefer, to send a call for translations after uploading the first
version that introduces new templates or templates changes.


Right, I planned to do it right after the approval of my package by the 
FTP masters but you were quicker, which is a good thing because I think 
I would have forgotten anyway…



The debian-l10n-english team will now start a review, on our own
initiative. It will be conducted through this bug report.


Okay. I have some notes for that:
1. I based my templates on those of the dokuwiki package, which may be
   of help for translation (not really for review, though);
2. the template pluxml/blog/lang is a bit complex:
   * the English version is __Choices, but I provided a
 pseudo-translation Choices-C so I can get standard values;
   * the Defaults is made “translatable”, not to translate it really but 
 to change the default value to the user's language if possible;

3. the template pluxml/blog/description's Default is made translatable
   because, well, it is a website description that has every reason to
   be I think;
4. I think I should make pluxml/blog/name's Default translatable too.


--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#721142: sam2p: Program always exits with the same error, not working at all.

[Tanguy Ortolo]

I have found one thing: it never happends on amd64, and always happen on 
i386. Recompiling it works, but changes nothing.


Now I am at a loss, however…

--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#721142: sam2p: Program always exits with the same error, not working at all.

[Tanguy Ortolo]

Kristijan Caprdja, 2013-08-28 16:50+0200:

It does not depend on the image, it does this regardless of the input.

I have seen the patches applied and I cannot explain why they should change
the behaviour of this program so much.
The error is consistent on two machines that I tried.


Same here, reversed: whatever image I use, I do not get this error on 
the two machines I tried! :-)



I will try to narrow the bug down later this evening.


Do you have the sam2p's recommends installed?

--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#721142: sam2p: Program always exits with the same error, not working at all.

[Tanguy Ortolo]

Kristijan Caprdja, 2013-08-28 15:22+0200:

sam2p program does not seem to work any more. Regardless of the input
parameters on the command line it will always break with the same error
message, it should be easy to reproduce on any machine.


Well, not here. Can you provide me with an example of an image that 
leads to that error?



Suggested fix:
The version from "wheezy" (0.49.1-1) is working as expected. The error
seems to be introduced in the testing ("jessie") distribution (0.49.1-2).


This is not a fix. The difference between 0.49.1-1 and 0.49.1-2 are:
* 0.49.1-1 does not compile with GCC 4.8, which is the compiler in 
  Jessie;

* 0.49.1-2 is patched so it compiles with GCC 4.8.

So, there is no real difference in the code except fixes, and 0.49.1-1 
cannot be built with Jessie.


Librement,

--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#133029: dh_installdebconf make cause breakage(lack of db_stop)

[Tanguy Ortolo]

Hello,

Adam Heath, 2002-02-08 17:17-0600:

I haven't actually seen a problem in the real world, but it's possible that
one could arise.


This is just an update to point out that it has been seen in the real 
world, as I just ran into that issue while packaging pluxml (#630467).


pluxml is a blog engine, so upcoming my package installs some 
configuration for apache2 or lighttpd and then reloads these daemons. No 
problem in postinst, where at the end of the script:

1. I call db_stop;
2. dh_installdebconf adds nothing;
3 the script exists fine.

But in postrm, things happen differently. I remove the configuration 
from apache2 or lighttpd, reload these daemons, and at the end of the 
script:

1. I call db_stop;
2. dh_installdebconf inserts some code that sources
   /usr/share/debconf/confmodule again, which starts debconf (I do not
   know the dirty details) and calls db_purge;
3. the script stalls, or rather, exists, but stays defunct with a
   debconf wrapper waiting for nothing, as it seems.

I solved that problem by moving my call to db_stop after the #DEBHELPER# 
placeholder.


Would there be a problem in adding a call to db_stop after db_purge, in 
the code added to postrm by dh_installdebconf? Otherwise, that problem 
could be mitigated by adding a notice in dh_installdebconf(1) and 
probably in debconf-devel(7) too, telling people to put their call to 
db_stop after the debhelper placeholder, as I did.


Librement,

--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#693126: latexmk: New upstream release available + watch file

[Tanguy Ortolo]

Hello,

I am maintaining a package for the LaTeX editor LaTeXila that uses 
Latexmk. Ohura, do you think you will be able to update this package, or 
do you mind if I take over its maintenance (I will no answer as an 
affirmative answer :-) )?


Regards,

--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#718851: Recommends on php5-ldap, php5-mysql and php5-pgsql should be alternatives?

[Tanguy Ortolo]

Thijs Kinkhorst, 2013-08-06 09:32+0200:

The newest dokuwiki-package Recommends "php5-ldap, php5-mysql, php5-pgsql".
It seems to me that in principle any setup would require just one of those
modules. Therefore, it would make more sense to me if the recommendation was
"php5-ldap | php5-mysql | php5-pgsql".


Indeed, thanks for the suggestion, I shall change that with my next 
upload.


--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature