Bug#1034364: kde-baseapps depends on konqueror which is not security maintained

[Bernhard Reiter]

Hi,

Am Dienstag 18 April 2023 04:55:35 schrieb Lisandro Damián Nicanor Pérez 
Meyer:
> On Mon, 17 Apr 2023 at 12:34, Bernhard Reiter  
wrote:

> > Konqueror is advertised as web browser, which means it will (offer to)
> > open URLs from different sources, e.g. when clicked from emails which
> > means external URLs and data.
>
> Same goes with KMail too :-)

not really, KMail protects against just displaying external HTML
code from mails, you need to explicitely enable it, e.g. by clicking.

> Whatever uses webengine/webkit/ has the same
> issue. Well, for as long as they are a pile of embedded code, at least
> to start with.

Only if they are exposed to unfiltered external data and having active code 
elements enabled like 

Bug#1034364: kde-baseapps depends on konqueror which is not security maintained

[Bernhard Reiter]

Hi Lisandro,

thanks for your response!

Am Samstag 15 April 2023 15:15:08 schrieben Sie:
> On Thu, 13 Apr 2023 at 14:15, Bernhard Reiter 
> >"qtwebengine-opensource-src No security support upstream and
> >backports not feasible, only for use on trusted content"

> If we follow that reasoning we shouldn't be shipping Plasma at all, as
> many things use Qt5's webengine.

Konqueror is advertised as web browser, which means it will (offer to)
open URLs from different sources, e.g. when clicked from emails which means
external URLs and data. 

Other components from plasma may not share the same exposure to outside
data, and thus would be less vulnerable. It seems that this would warrant
some more examination. 

If it is true that other components show the same risks, then yes, I'd say 
that we should either get the security situation changed or really do not 
ship those components by default. They may risk systems like
the dynamic loading of remote objects from java did which would be a problem 
for both Debian and upstream.

It seems to big a topic for this issue.
What would be the right place in debian to bring this up?

Thanks again,
Bernhard


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

Bug#763193: kde-base: KDE Memory leak still present in jessie

[Bernhard Reiter]

As kde4libs are not in Bullseye anymore and phased out completely,
we have moved to the KDE Frameworks generation of technology.

This defect is potentially not relevant anymore as a lot of the technology is 
different now. At least it needs a new reproduction
and thus confirmation that is is still present on Bullseye or Unstable/
Testing.

My suggestion is to close the report, because there would have been more 
information meanwhile if a similar defect has shown in the last 9 years.

Leslie thanks again for reporting this problem, sorry that it could not
fixed for kde4libs based technology. (Or, by chance are you still using the 
new stuff and experiencing still such problems?)

Bug#1034364: kde-baseapps depends on konqueror which is not security maintained

[Bernhard Reiter]

Package: kde-baseapps
Version: 4:22.12.3+5.142
Severity: important

Dear Maintainers,

consider removing konqueror from the depencies of kde-baseapps.

Rationale:

kde-baseapps for version 5:111 (stable) and 5:142 (unstable) depends on
  konqueror
but konqueror depends on
  libqt5webenginecore5
source package is
  qtwebengine-opensource-src
which according to 
https://salsa.debian.org/debian/debian-security-support/-/blob/573b1a3f35208754bdf50a2af03f6c1b8c066a8b/security-support-limited
is not security maintained:
   "qtwebengine-opensource-src No security support upstream and
   backports not feasible, only for use on trusted content"

If this information is still correct,
konqueror should not be recommended or depended on
as user should by default get a system which is reasonable secure.

Thanks
Bernhard

Bug#1006435: bouncy: leveleditor does not start (pygame.error: font not initialized)

[Bernhard Reiter]

Package: bouncy
Version: 0.6.20071104-6
Severity: minor
Tags: patch

Dear Maintainer,

the included level editor does not start, due to a font error.
Expected behaviour: it should start.
Potential fix: see patch below.

Thanks for maintaining bouncy, it is one of the few games suitable
for smaller children. 

Best Regards,
Bernhard 

== reproduction
Start the level editor like

pushd /usr/share/games/bouncy/
python leveledit.py data/level2.csv
[..]
Traceback (most recent call last):
  File "leveledit.py", line 2, in 
import fonts
  File "/usr/share/games/bouncy/fonts.py", line 6, in 
size=20, bold=False, italic=False) 
  File "/usr/share/games/bouncy/pyglyph/font.py", line 74, in get_font
font = self.impl_get_font(family, size, bold, italic)
  File "/usr/share/games/bouncy/pyglyph/font.py", line 165, in impl_get_font
fake_italic=fake_italic)
  File "/usr/share/games/bouncy/pyglyph/font.py", line 255, in __init__
self.pygame_font = pygame.font.Font(filename, size)
pygame.error: font not initialized

== potential fix
The same file font.py works for the main game, so when switching
the import order to be similiar to game.py, the level editor comes up.

--- leveledit.py.orig   2020-12-23 11:34:17.522314902 +0100
+++ leveledit.py2020-12-23 11:34:28.982508935 +0100
@@ -1,5 +1,4 @@
 import sys, pygame, csv, shutil, os
-import fonts
 from pygame.locals import *
 from pygame.constants import *

@@ -13,6 +12,7 @@
 pygame.display.set_mode(viewport, OPENGL | DOUBLEBUF)

 import objects
+import fonts

 import pyglyph

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

Kernel: Linux 4.19.0-13-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bouncy depends on:
ii  fonts-dejavu-core  2.37-1
ii  python 2.7.16-1
ii  python-opengl  3.1.0+dfsg-2
ii  python-pygame  1.9.4.post1+dfsg-3

bouncy recommends no packages.

bouncy suggests no packages.

-- no debconf information

Bug#1006433: maelstrom: keyboard stutter -> unplayable on some systems

[Bernhard Reiter]

Package: maelstrom
Version: 1.4.3-L3.0.6+main-9
Severity: important

Dear Maintainer,
thanks for maintaining Maelstrom, it is a nice classic game.

On this slightly old system, maelstrom is unplayable
because the keys to move the ship stutter and do not work properly.
So when you want to turn left or right, and hold the key down,
the ship does not continue to turn, it may turn a bit if someone
hits the key several times, but this is not enough for playing properly.

Expected behaviour is:
Ship continues to rotate or trust forward, when key is pressed and held down.

== Technical details, things tried
On a Raspberry 4 with Raspberry OS the same Debian version works fine,
so it does not seem to be a problem of system power in general.

It does not depend on the window manager, I had the same problem with
Plasma and i3.

It does not depend on full screen, I've tried both modes.

glxgears shows the system to be fast (the maximum of 60fps as synced).

I've switched off and on and defaulted the key repetion via the
Plasma system settings, this did not have an effect on Maelstrom.

xev shows that the keys repeat as expected, so it is not the original key 
events themselves. 

It does not depend on which key is used, as I did configured different
ones and got the same problem.

Best Regards,
Bernhard


[resending, this is an elder report that got stuck, original headers
  X-Mailer: reportbug 7.5.3~deb10u1
  Date: Wed, 23 Dec 2020 11:01:26 +0100
]

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

Kernel: Linux 4.19.0-13-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages maelstrom depends on:
ii  libc62.28-10
ii  libgcc1  1:8.3.0-6
ii  libsdl-net1.21.2.8-6
ii  libsdl1.2debian  1.2.15+dfsg2-4
ii  libstdc++6   8.3.0-6

maelstrom recommends no packages.

maelstrom suggests no packages.

-- no debconf information

Bug#972615: magicmaze: homepage changed

[Bernhard Reiter]

Package: magicmaze
Version: 1.4.3.6+dfsg-3
Severity: normal

Dear Maintainers,

as Rubyforge was discontinued, it seems that the homepage as moved
to
  https://github.com/kentdahl/magic_maze

Regards,
Bernhard

Bug#911189: gpgme-json packaging

[Bernhard Reiter]

Hello,

sorry the work from our side got stuck.
We (from Intevation) will be looking into it.
Timeframe: first look next week, fix can take a few more days.

From my rough understanding: The extension ID would need to go into the 
personal configuration of the webbrowsers and cannot be configured globally, 
could it? 

What is the standard solution for such a situation in Debian?
(Hints for this point may help us to get this solved faster.)

Best Regards,
Bernhard


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

Bug#964370: Thanks for fixing

[Bernhard Reiter]

Thanks for the fast fix.
(Now I just have to wait for the build to get to servers. ;))

Bug#964370: dino-im-common: dino-im_0.1.0-5~bpo10+1 removes dino-im on upgrade

[Bernhard Reiter]

Package: dino-im-common
Version: 0.1.0-5~bpo10+1
Severity: important

Dear Martin,

today the system upgrade on Buster with a backported dino-im
brought me dino-im_0.1.0-5~bpo10+1 which removed dino-im
completely. So something is wrong.

LANG=C apt-get install dino-im/buster-backports
Selected version '0.1.0-5~bpo10+1' (Debian Backports:buster-backports [amd64]) 
for 'dino-im'
[..]
The following packages have unmet dependencies:
 dino-im : Depends: dino-im-common (= 0.1.0-5~bpo10+1) but it is not going to 
be installed
E: Unable to correct problems, you have held broken packages.

dpkg -l dino-im-common | tail -1
ii  dino-im-common 0.1.0-5~bpo10+1 all  modern XMPP client - common 
files

Regards,
Bernhard

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

Kernel: Linux 4.19.0-9-amd64 (SMP w/6 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

Bug#959097: Acknowledgement (vdirsyncer: hang in FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME for some configs)

[Bernhard Reiter]

Reported upstream as
https://github.com/pimutils/vdirsyncer/issues/818
  python3: vdirsyncer hang in thread for one calendar

Bug#959097: Acknowledgement (vdirsyncer: hang in FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME for some configs)

[Bernhard Reiter]

Trying a different version of vdirsyncer:
Same problem.

  apt-get install pipx
  pipx install vdirsyncer

which installed 0.16.7.
And running it
  /home/bernh/.local/bin/vdirsyncer -v DEBUG sync
gave the same problem.
This is the newest version on the git master.

Bug#959097: Acknowledgement (vdirsyncer: hang in FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME for some configs)

[Bernhard Reiter]

Additional info:

Here is a backtrace showing the hang run via
the python3-click-threading package (Version: 0.4.4-1)

Another info: The hang also happens to me on the same calender setup
on a different Debian Buster machine.

apt-get install python3-dbg
allows
ps -u bernh | grep vdir
16249 pts/11   00:41:23 vdirsyncer
bernh@machine ~> gdb -p 16249
(gdb) py-bt
Traceback (most recent call first):
  File "/usr/lib/python3.7/threading.py", line 296, in wait
waiter.acquire()
  File "/usr/lib/python3.7/queue.py", line 170, in get
self.not_empty.wait()
  File "/usr/lib/python3/dist-packages/click_threading/__init__.py", line 110, 
in run
func, future = self.tasks.get()
  File "/usr/lib/python3/dist-packages/vdirsyncer/cli/utils.py", line 375, in 
join
ui_worker.run()
  
  File "/usr/lib/python3.7/contextlib.py", line 119, in __exit__
next(self.gen)
  File "/usr/lib/python3/dist-packages/vdirsyncer/cli/__init__.py", line 154, 
in sync
wq.spawn_worker()
  File "/usr/lib/python3/dist-packages/vdirsyncer/cli/__init__.py", line 32, in 
inner
f(*a, **kw)
  File "/usr/lib/python3/dist-packages/click/core.py", line 555, in invoke
return callback(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/decorators.py", line 64, in 
new_func
return ctx.invoke(f, obj, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/core.py", line 555, in invoke
return callback(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/core.py", line 956, in invoke
return ctx.invoke(self.callback, **ctx.params)
  File "/usr/lib/python3/dist-packages/click/core.py", line 1137, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/lib/python3/dist-packages/click/core.py", line 717, in main
rv = self.invoke(ctx)
  File "/usr/lib/python3/dist-packages/click/core.py", line 764, in __call__
return self.main(*args, **kwargs)
  File "/usr/bin/vdirsyncer", line 11, in 
load_entry_point('vdirsyncer==0.16.7', 'console_scripts', 'vdirsyncer')()

Bug#959097: vdirsyncer: hang in FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME for some configs

[Bernhard Reiter]

Package: vdirsyncer
Version: 0.16.7-2
Severity: normal

Hi,
it is very nice that Debian packages vdirsyncer and thus helps
to maintain it. (As you may know, the original upstream author
is not happy about how this is handled, but also does not put much
time into vdirsyncer anymore. This makes the Debian packages even more
valuable in my eyes).


   * What led up to the situation?

When upgrading to Buster, I've switched using 
  vdirsyncer-latest [0.17.0a5~0+gac45bdc.d20180613]
from an external package source to the standard version with buster
There are three calendars configured, which are all just read_only
from a CALDAV source (all on the same server) to a singlefile .ics.

When trying a sync, vdirsyncer hangs on one calendar, the other two work.
  strace -p
on the process shows
futex(0x7f387429e890, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, 
FUTEX_BITSET_MATCH_ANY

   * What outcome did you expect instead?

A complete sync or an error message,
helping to diagnose the problem.



This is mainly for documenting the issue first,
to see if others run into the same issues.
Hints and potential solutions are appreciated, of course. :)
If time permitts, I'll do more analysis, possibly:
 * check if I can get https://wiki.python.org/moin/DebuggingWithGdb
   to get a better idea where it hangs in the application
 * try the 0.17. version with a manual install, to see if this is
   different (a short search on github did not reveal anything obviously
   related to this defect and 0.16.7 is the latest released version,
   even after 0.17a5.)
 * as it is read-only database, I may try to see, if it does away with
   fresh setup, though this may destroy the testable case.

Best Regards,
Bernhard

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

Kernel: Linux 4.19.0-8-amd64 (SMP w/6 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages vdirsyncer depends on:
ii  python33.7.3-1
ii  python3-atomicwrites   1.1.5-2
ii  python3-click  7.0-1
ii  python3-click-log  0.2.1-1
ii  python3-click-threading0.4.4-1
ii  python3-requests   2.21.0-1
ii  python3-requests-toolbelt  0.8.0-1

vdirsyncer recommends no packages.

Versions of packages vdirsyncer suggests:
pn  python3-requests-oauthlib  
ii  vdirsyncer-doc 0.16.7-2

-- no debconf information

Bug#941408: marked as pending in koules

[Bernhard Reiter]

Hi Stephen,

> You’re very welcome! It’s not ideal, since the dependency isn’t strong, but
> policy says packages can’t depend on font packages — which makes sense in X
> since the fonts can be served remotely. 

thanks for the explanation!
(This almost triggered a question by my, but I understood that koules may 
still be supporting svgalib on non-X11 systems. Anyway I've enjoyed a nice
game of koules. :))

Regards,
Bernhard


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

Bug#941408: marked as pending in koules

[Bernhard Reiter]

Stephen,

> Recommend xfonts-base (Koules needs schumacher)

thanks for the improvement!
Bernhard

Bug#941408: koules: needs font schumacher

[Bernhard Reiter]

Package: koules
Version: 1.4-25
Severity: minor

Dear Maintainer,

koules needs the font
 `-schumacher-clean-bold-r-normal--8-80-75-75-c-80-*iso*`
to be available to start.

On Rasperian (based on Buster) when installing koules,
it fails with a font error message. The following command showed
that the font was missing:
  xlsfonts | grep schumacher

Installing package `xfonts-base` and restarting solved the problem.
I don't know how the dependency on this font should be recorded
in the package, but it would be helpful.

Best Regards,
Bernhard

Bug#540312: /usr/bin/dotty: Re: Dotty generated PS file are broken

[Bernhard Reiter]

Package: graphviz
Version: 2.38.0-17
Followup-For: Bug #540312

Dear Maintainer,

the problem is still there with 2.38.0-17.

Another workaround is to remove the last line with only `FI` on it
in the .ps output.


Here is a diff for the example:
--- out.ps.org 2019-09-24 15:40:18.580577716 +0200
+++ out2.ps 2019-09-24 15:43:30.557247527 +0200
@@ -112,7 +112,6 @@
 1546 3120 lineto
 1546 29 lineto
 28 29 lineto
-FI
 0.996094 0.996094 0.992188 CL
 DO 28 29 moveto
 28 3120 lineto

Regards,
Bernhard


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

Kernel: Linux 4.9.0-11-amd64 (SMP w/6 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages graphviz depends on:
ii  libann0   1.1.2+doc-6
ii  libc6 2.24-11+deb9u4
ii  libcdt5   2.38.0-17
ii  libcgraph62.38.0-17
ii  libexpat1 2.2.0-2+deb9u3
ii  libgcc1   1:6.3.0-18+deb9u1
ii  libgd32.2.4-2+deb9u5
ii  libglib2.0-0  2.50.3-2+deb9u1
ii  libgts-0.7-5  0.7.6+darcs121130-4
ii  libgvc6   2.38.0-17
ii  libgvpr2  2.38.0-17
ii  libstdc++66.3.0-18+deb9u1
ii  libx11-6  2:1.6.4-3+deb9u1
ii  libxaw7   2:1.0.13-1+b2
ii  libxmu6   2:1.1.2-2
ii  libxt61:1.1.5-1

Versions of packages graphviz recommends:
ii  fonts-liberation  1:1.07.4-2

Versions of packages graphviz suggests:
ii  graphviz-doc  2.38.0-17
ii  gsfonts   1:8.11+urwcyr1.0.7~pre44-4.3

Bug#898259: RFP: vscode -- Microsoft Visual Studio Code

[Bernhard Reiter]

There is an initiative `vscodium` that builds vscode from source,
which seems to be interesting as a base for a Debian package, as it
 * provides a Debian package
 * makes an attempt to disable telemetry/tracking by default [2]

https://vscodium.com/
https://github.com/VSCodium/vscodium
[2] https://github.com/VSCodium/vscodium/blob/master/DOCS.md

Additionally there seem to be several archlinux "packaging" efforts,
which may or may not offer additional bits an pieces.

https://www.archlinux.org/packages/community/x86_64/code/
https://aur.archlinux.org/packages/code-git/
https://aur.archlinux.org/packages/vscodium/

From my perspective there is an interest from Debian users
to have a vscodium package. 

Best Regards,
Bernhard

-- 
www.intevation.de/~bernhard


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

Bug#926404: /usr/bin/pdfsig: pdfsig: segfaults with "couldn't find default Firefox Folder"

[Bernhard Reiter]

Am Dienstag 16 April 2019 22:32:30 schrieb Bernhard Übelacker:
>   - Signature Validation: Signature is Valid.
>   - Certificate Validation: Certificate has Expired

Looks good, so it seems that libnss3 has a different certificate store
as well that it is using additionally in this case (or in this version).
Would be cool to have a version with this code (as patch or from upstream).
Thanks Bernhard!

Bug#926404: /usr/bin/pdfsig: pdfsig: segfaults with "couldn't find default Firefox Folder"

[Bernhard Reiter]

> there was neither /etc/pki/nssdb nor a firefox profile in the
> home directory.

Can you post the signature information?
My guess from the code is that you saw the info,
but no certification validation.

Bug#926404: /usr/bin/pdfsig: pdfsig: segfaults with "couldn't find default Firefox Folder"

[Bernhard Reiter]

Hello,

Am Dienstag 16 April 2019 09:37:28 schrieb Bernhard Übelacker:
> That looks quite similar to what I have received in #924050.

you were testing a different case there
probably the one for this (==#926404) problem.

The indicateion is the difference in the messages in the original problems:
#924050: Internal Error (0): Input couldn't be parsed as a CMS signature
#926404: Internal Error (0): couldn't find default Firefox Folder

This is very likely coming from two different code paths within libnss3.
I guess that with #924050 the signature itself was damaged.
I've made a brief effort to create such a damaged pdf, it should be possible
in theory because the signature itself is not part of the digest, however
I am not experienced enough to find the precise location.

> Therefore this issue should solvable by the patch attached to [1].

The patch deals with the place where the certificate database is found
and adds more code in case it is not found. So it has the potential
to solve the segfault. This looks like an improvement for #926404 to me.

It still makes sense to depend or recommend a certificate database that is 
used by pdfsig. Otherwise it will not be possible to validate the certificate
of a signature.

> A poppler package built with that patch showed the
> signature information successfully.

Did you have /etc/pki/nssdb in place or a personal firefox profile when doing 
the test?

Regards,
Bernhard

Bug#926404: /usr/bin/pdfsig: pdfsig: segfaults with "couldn't find default Firefox Folder"

[Bernhard Reiter]

Hello Bernhard (Übelacker),

thanks for your response!

| Is pdfsig on your system really not crashing if firefox is installed?

this is my guess, because I've looked into the code and for verification it 
gives
either a code path /etc/pki/nssdb or something in the personal profile to the 
nss library
used. I haven't yet tried if just installing Firefox is enough to create one of 
the both
needed path.

| Maybe you could run following command in a terminal to get a backtrace

Done, see below. Segfault as expected within libnss3.

Best Regards,
Bernhard

gdb -q -ex 'set width 0' -ex 'set pagination off' -ex 'run' -ex 'bt' -ex 
'detach' -ex 'quit' --args pdfsig A_signed.pdf
Reading symbols from pdfsig...(no debugging symbols found)...done.
Starting program: /usr/bin/pdfsig A_signed.pdf
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Digital Signature Info of: A_signed.pdf
Internal Error (0): couldn't find default Firefox Folder

Program received signal SIGSEGV, Segmentation fault.
0x77321c84 in SECMOD_ReferenceModule () from 
/lib/x86_64-linux-gnu/libnss3.so
#0  0x77321c84 in SECMOD_ReferenceModule () from 
/lib/x86_64-linux-gnu/libnss3.so
#1  0x773221fc in ?? () from /lib/x86_64-linux-gnu/libnss3.so
#2  0x773222a0 in SECMOD_AddNewModuleEx () from 
/lib/x86_64-linux-gnu/libnss3.so
#3  0x77f01199 in SignatureHandler::SignatureHandler(unsigned char*, 
int) () 
from /lib/x86_64-linux-gnu/libpoppler.so.82
#4  0x77dfbb16 in FormFieldSignature::validateSignature(bool, bool, 
long) () 
from /lib/x86_64-linux-gnu/libpoppler.so.82
#5  0x6a5d in main ()
Detaching from program: /usr/bin/pdfsig, process 1002
[Inferior 1 (process 1002) detached]

Bug#707543: dolphin: Acl management inconsistent

[Bernhard Reiter]

Package: dolphin
Followup-For: Bug #707543

Dear Maintainer, Dear Mourad,

trying to reproduce the problem with a more current Dolphin,
I find that I cannot reproduce.

Steps I've done:
* created a new folder "test"
* used the properties -> permissions -> extended permission dialog
* "add entry", selected a different user like "backup" and clicked
  to reduce permission to read only. "ok" -> "ok".
* closed dolphin
* on the command line used "getfacl test"
  result:
  # file: test/
  # owner: ber
  # group: ber
  user::rwx
  user:backup:r--
  group::r-x
  mask::r-x
  other::r-x
* reopened dolphin in the same dialog and all was fine.

So I believe the defect is gone with the newer version
and this report can be closed.

Regards,
Bernhard


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

Kernel: Linux 4.9.0-8-amd64 (SMP w/6 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dolphin depends on:
ii  baloo-kf5  5.28.0-2
ii  kinit  5.28.0-1
ii  kio5.28.0-2
ii  libc6  2.24-11+deb9u3
ii  libdolphinvcs5 4:16.08.3-3
ii  libkf5baloo5   5.28.0-2
ii  libkf5baloowidgets516.04.0-1+b1
ii  libkf5bookmarks5   5.28.0-1
ii  libkf5codecs5  5.28.0-1+b2
ii  libkf5completion5  5.28.0-1
ii  libkf5configcore5  5.28.0-2
ii  libkf5configgui5   5.28.0-2
ii  libkf5configwidgets5   5.28.0-2
ii  libkf5coreaddons5  5.28.0-2
ii  libkf5crash5   5.28.0-1
ii  libkf5dbusaddons5  5.28.0-1
ii  libkf5filemetadata35.28.0-1+b2
ii  libkf5i18n55.28.0-2
ii  libkf5iconthemes5  5.28.0-2
ii  libkf5itemviews5   5.28.0-1
ii  libkf5jobwidgets5  5.28.0-2
ii  libkf5kcmutils55.28.0-2
ii  libkf5kiocore5 5.28.0-2
ii  libkf5kiofilewidgets5  5.28.0-2
ii  libkf5kiowidgets5  5.28.0-2
ii  libkf5newstuff55.28.0-1
ii  libkf5notifications5   5.28.0-1
ii  libkf5parts5   5.28.0-1
ii  libkf5service-bin  5.28.0-1
ii  libkf5service5 5.28.0-1
ii  libkf5solid5   5.28.0-3
ii  libkf5textwidgets5 5.28.0-1
ii  libkf5widgetsaddons5   5.28.0-3
ii  libkf5windowsystem55.28.0-2
ii  libkf5xmlgui5  5.28.0-1
ii  libphonon4qt5-44:4.9.0-4
ii  libqt5core5a   5.7.1+dfsg-3+b1
ii  libqt5dbus55.7.1+dfsg-3+b1
ii  libqt5gui5 5.7.1+dfsg-3+b1
ii  libqt5widgets5 5.7.1+dfsg-3+b1
ii  libqt5xml5 5.7.1+dfsg-3+b1
ii  libstdc++6 6.3.0-18+deb9u1
ii  phonon4qt5 4:4.9.0-4

Versions of packages dolphin recommends:
ii  kio-extras  4:16.08.3-1
ii  ruby1:2.3.3

Versions of packages dolphin suggests:
pn  dolphin-plugins  

-- no debconf information

Bug#892744: python3-pip: breaks with venv --system-site-packages

[Bernhard Reiter]

Package: python3-pip
Version: 9.0.1-2
Severity: normal

Hi Maintainers,

according to `pip help install`::

  --user
[..]
  On Debian systems, this is the default when running outside of a
  virtual environment and not as root.

However when using the recommended virtual environment `venv`,
the detection does not work. Example:

   python3 -m venv --system-site-packages x_env
   . x_env/in/activate.fish
   pip install vdirsyncer

will end up with installed files
in .local/bin and .local/lib/python3.5/site-packages/
While they should have been below x_env.

In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876145
the problems is also mentioned.

Best Regards,
Bernhard


-- System Information:
Debian Release: 9.4

Versions of packages python3-pip depends on:
ii  ca-certificates  20161130+nmu1
ii  python-pip-whl   9.0.1-2
ii  python3  3.5.3-1

Bug#842344: netw-ib-ox-ag: home page claims it is unmaintained

[Bernhard Reiter]

Source: netw-ib-ox-ag
Severity: normal

Dear Maintainer,

The homepage: http://ntwox.sourceforge.net/
claims that 'This project reached its End Of Maintenance in 2007'

Though there has been a release in 2012, this has been the last
which can be reached from the homepage. So either the link to the
homepage is wrong and should be corrected or the package has
been orphaned by upstream and should be put up for maintenance
in Debian as well.

Regards,
Bernhard

Bug#812180: ding: image paths in html doc broken

[Bernhard Reiter]

Package: ding
Version: 1.7-3, 1.8-3
Severity: minor

Hi!

/usr/share/doc/ding/html/index.html
assumes the two images to be in "index_files".
e.g '

Bug#801237: mactel-boot review

[Bernhard Reiter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Am 2015-10-23 um 18:47 schrieb Gianfranco Costamagna:
> Control: owner -1 ! Control: tags -1 moreinfo
> 
> Hi, the packaging looks fine, however I don't understand what the 
> code is supposed to do.
> 
> seems that the purpose of this code is to send an ioctl call and 
> nothing more?

That's correct -- its sole purpose is to set an HFS+ partition as
bootable. See the included man file, and
http://heeris.id.au/2014/ubuntu-plus-mac-pure-efi-boot/#fixing-efi for
some more context.

Bernhard

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWKo7JAAoJEKYfw19Gd1loNzkP/3IuPKB/5p62C6U8krkdduHn
6MnPnnzB1Pc+B1MFy8Bm2wa4ZllBycvgAeuwG2OHORZT2Jjm9vSHeRUvouMJBZDG
sWLU5YPQyaPWjDF5scbX88f6viJdNz9+IrztsX2mBayyuQpfm0eMcK6fVgKniHmP
c8whP2tYG4e8ZeDg9VxkZFU4lnAPAY4MVdlr9KoH7v4Bjj3wm+JmYSSR9WoNdoqN
WF4sdtjq28/fGCR8mlh4zkX6QylwkmG2L+rr/iJaVbtqpT+7rng4I+G80wB3wOe1
th4thzdNCFtKyHFQV62ChfbqOrlOvE4vO3oviC8W/DohDHZ0CHnfbLXo6CAa40OV
ce6IYPe26VECDDpFewS9ZnXlvDYgGLU4FzFmWon+o8QL4pFHOCMa/S2iH2aMzvle
oHb8wdqQkAxXSrj7m5r4BNefaK9K1PLXfsYJVT9+V/OFR4hLzZ0/6/nkalGhq6ag
dn7QNKJPerdbdc+L4XdZ5pY6uFBMbqFczzSPC9ssv8jBtOHEs0F7c6kI4mAods7e
E2ASs8AbgrBHq/9ZS0h3m1Ej+37xxeWMSvfULcK6cfA6kDrUHRE1VdrzxLTlp3Gq
0GCfuKVKjClv3UUbeInlc1V9b41NisTs9pMdJuq0gBWCiqH6mejUhz6JXsQDghcZ
5zDaH9ec/oWlS6tdkb+l
=Euzg
-END PGP SIGNATURE-

Bug#801237: RFS: mactel-boot/0.9-1 [ITP] -- hfs-bless utility for Intel Macs

[Bernhard Reiter]

RFS: mactel-boot/0.9-1 [ITP]
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "mactel-boot"

* Package name : mactel-boot
  Version : 0.9-1
  Upstream Author : Matthew Garrett <m...@redhat.com>
* URL : http://www.codon.org.uk/~mjg59/mactel-boot/
* License : GPL-2+
  Section : admin

It builds those binary packages:

mactel-boot - hfs-bless utility for Intel Macs

To access further information about this package, please visit the
following URL:

http://mentors.debian.net/package/mactel-boot

Alternatively, one can download the package with dget using this command:

dget -x
http://mentors.debian.net/debian/pool/main/m/mactel-boot/mactel-boot_0.9-1.dsc

More information about hello can be obtained from
http://heeris.id.au/2014/ubuntu-plus-mac-pure-efi-boot/#fixing-efi


Regards,
Bernhard Reiter

Bug#800002: nis: please update to a current version of yp-tools (v>=2.14 or v>=3.3)

[Bernhard Reiter]

Marc, 

On Friday 25 September 2015 at 18:51:17, Mark Brown wrote:
> The patches we've got didn't apply terribly easily the last time I
> looked IIRC.

thanks for your prompt reply.

So the next step would be to look into merging 2.14 with current Debian.
Can you write more or point to the current state 
of the "minor licensing issues" that you were mentioning in 
#799988?

Best,
Bernhard

Bug#800049: ITP: mactel-boot -- hfs-bless utility for Intel Macs

[Bernhard Reiter]

Package: wnpp
Severity: wishlist

* Package name: mactel-boot
* URL : http://www.codon.org.uk/~mjg59/mactel-boot/
* License : GPL-2+
  Programming Lang: C
  Description : hfs-bless utility for Intel Macs

Utility for adding EFI capable bootloaders to the boot firmware of Intel
Macs. This effectively tells the boot firmware where to look for
bootable operating systems.

Bug#800002: nis: please update to a current version of yp-tools (v>=2.14 or v>=3.3)

[Bernhard Reiter]

Package: nis
Version: 3.17-34
Severity: wishlist

Dear Mark,

please consider updating a recent version of yp-tools.
As far as I can see nis-3.17-34 still has yp-tools 2.9 
from 2004 (of course a patched version).

An update to 2.14 (from 2012) probably is not a lot of work,
the newer version 3.x has other build requirements.

See
http://www.linux-nis.org/download/yp-tools/
and the Changelog from
https://github.com/thkukuk/yp-tools/

Best Regards,
Bernhard

Bug#799988: nis: yppasswd from yp-tools cannot set password with length >8, needs to support more hash algorithms

[Bernhard Reiter]

Package: nis
Version: 3.17-34
Severity: important
Tags: security, fixed-upstream

Hi,

in a NIS setup where yppasswd is used to let users change
the passwords, passwords cannot be longer than 8 chars.
As far as I understand this results from the lack of supporting
more hash algorithms like SHA2.

There is are newer versions of yp-tools that claim SHA2 support.
  http://www.linux-nis.org/download/yp-tools/
has 2.14 and the changelog in git reads:

2010-04-20  Thorsten Kukuk  
* release version 2.11
[..]
* src/yppasswd.c: Add support for MD5, SHA-256
and SHA-512. Patch by Karel Klic .

An update to yp-tools to the current version (2.14 for pre IPv6
or 3.13 for IPv6 at time of writing) would most likely fix this issue.
As password strength affects the system, I believe this is
security relevant.

Best Regards,
Bernhard

Bug#769412: pyme: new upstream version 0.9.0

[Bernhard Reiter]

Package: pyme
Version: 0.8.1
Severity: wishlist

Dear Arnaud,

as listed from http://wiki.gnupg.org/APIs
pyme is now maintained by Martin Albrecht at
https://bitbucket.org/malb/pyme

He has tagged 0.9.0 and it would be nice to have this packaged for Debian.

Thanks for maintaining pyme,
Bernhard


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

Bug#434599: [PATCH] git-imap-send: use libcurl for implementation

[Bernhard Reiter]

Resending this once more, as indicated by 
xmqqbnp4hu8g@gitster.dls.corp.google.com
Hope my formatting and posting style is now conformant. Sorry for the noise.

Am 2014-08-27 um 19:20 schrieb Junio C Hamano:
 Bernhard Reiter ock...@raz.or.at writes:
 
 [...] For now,
 the old ones are wrapped in #ifdefs, and the new functions are enabled
 by make if curl's version is = 7.35.0, from which version on curl's
 CURLOPT_LOGIN_OPTIONS (enabling IMAP authentication) parameter has been
 available.
 
 https://github.com/bagder/curl/blob/master/docs/libcurl/symbols-in-versions
 says that this was introduced as of 7.34.0, though.

Strange, I thought I recalled having seen that in
http://curl.haxx.se/libcurl/c/CURLOPT_LOGIN_OPTIONS.html but it clearly
says 7.34.0 there too. I've now changed all occurrences of 7.35.0 to
7.34.0 (and the corresponding hex value in the Makefile).

 As I don't have access to that many IMAP servers, I haven't been able to
 test the new code with a wide variety of parameter combinations. I did
 test both secure and insecure (imaps:// and imap://) connections and
 values of PLAIN and LOGIN for the authMethod.
 
 Perhaps CC'ing those who have touched git-imap-send code over the
 years and asking for their help testing might help?

CC'ing them (going back about 2 years, which already makes the list
quite long) and the people who have taken part in the initial discussion
on this feature in August. And the related Debian bug.

Please test this, folks!

 Signed-off-by: Bernhard Reiter ock...@raz.or.at
 ---
 I rebased the patch on the pu branch, hope that was the right thing to do.
 
 Usually I would appreciate a patch for a new feature not meant for
 the maintenance tracks to be based on 'master', so that it can go to
 the next release without having to wait other changes that may
 conflict with it and that may not yet be ready.
 
 I will try to apply this one to 'pu', rebase it on 'master' to make
 sure the result does not depend on the other topics in flight, and
 then merge it back to 'pu'.

Okay, I'll stick to master. I've rebased on master now that the first
couple related patches are there anyway.

 [...]

 diff --git a/Documentation/git-imap-send.txt 
 b/Documentation/git-imap-send.txt
 index 7d991d9..9d244c4 100644
 --- a/Documentation/git-imap-send.txt
 +++ b/Documentation/git-imap-send.txt
 @@ -75,7 +75,8 @@ imap.preformattedHTML::
  
  imap.authMethod::
  Specify authenticate method for authentication with IMAP server.
 -Current supported method is 'CRAM-MD5' only. If this is not set
 +If you compiled git with the NO_CURL option or if your curl version is
 + 7.35.0, the only supported method is 'CRAM-MD5'. If this is not set
  then 'git imap-send' uses the basic IMAP plaintext LOGIN command.
 
 Hmph, so there is no option that lets me say I know my libcurl is
 new enough but I have some reason not to want to use the new code to
 interact with my imap server, at compile time or (more preferrably)
 at runtime?

Added a runtime option, see below.

 diff --git a/INSTALL b/INSTALL
 index 6ec7a24..e2770a0 100644
 --- a/INSTALL
 +++ b/INSTALL
 @@ -108,18 +108,21 @@ Issues of note:
so you might need to install additional packages other than Perl
itself, e.g. Time::HiRes.
  
 -- openssl library is used by git-imap-send to use IMAP over SSL.
 -  If you don't need it, use NO_OPENSSL.
 +- openssl library is used by git-imap-send to use IMAP over SSL,
 +  unless you're using curl = 7.35.0, in which case that will be
 +  used. If you don't need git-imap-send, you can use NO_OPENSSL.
 
 The last sentence makes it unclear which of the following is true:
 
  - I have sufficiently new libcurl.  I cannot say NO_OPENSSL because
I do need git-imap-send.
 
  - I have sufficiently new libcurl, so openssl is not used by
git-imap send for me.  I can say NO_OPENSSL.
 
 Perhaps
 
  - git-imap-send needs the OpenSSL library to talk IMAP over SSL if
you are using libCurl older than 7.35.0.  Otherwise you can use
NO_OPENSSL without losing git-imap-send.

Fixed.

 diff --git a/git.spec.in b/git.spec.in
 index d61d537..9535cc3 100644
 --- a/git.spec.in
 +++ b/git.spec.in
 @@ -8,7 +8,7 @@ License: GPL
  Group:  Development/Tools
  URL:http://kernel.org/pub/software/scm/git/
  Source: http://kernel.org/pub/software/scm/git/%{name}-%{version}.tar.gz
 -BuildRequires:  zlib-devel = 1.2, openssl-devel, curl-devel, 
 expat-devel, gettext  %{!?_without_docs:, xmlto, asciidoc  6.0.3}
 +BuildRequires:  zlib-devel = 1.2, openssl-devel, curl-devel = 7.35.0, 
 expat-devel, gettext  %{!?_without_docs:, xmlto, asciidoc  6.0.3}
 
 This is very iffy.  It incompatible with the body of the patch where
 you allow older curl library and because you depend on openssl-devel
 you wouldn't lose imap-send.

Okay, removed the version requirement.

 @@ -1391,29 +1518,13 @@ int main(int argc, char **argv)
 [...]
 
 Much more

Bug#434599: [PATCH] git-imap-send: use libcurl for implementation

[Bernhard Reiter]

Sorry for not getting back to this any sooner, I've been pretty busy
recently with Other Projects(tm).

Am 2014-08-27 um 19:20 schrieb Junio C Hamano:
 Bernhard Reiter ock...@raz.or.at writes:
 
 [...] For now,
 the old ones are wrapped in #ifdefs, and the new functions are enabled
 by make if curl's version is = 7.35.0, from which version on curl's
 CURLOPT_LOGIN_OPTIONS (enabling IMAP authentication) parameter has been
 available.
 
 https://github.com/bagder/curl/blob/master/docs/libcurl/symbols-in-versions
 says that this was introduced as of 7.34.0, though.

Strange, I thought I recalled having seen that in
http://curl.haxx.se/libcurl/c/CURLOPT_LOGIN_OPTIONS.html but it clearly
says 7.34.0 there too. I've now changed all occurrences of 7.35.0 to
7.34.0 (and the corresponding hex value in the Makefile).

 As I don't have access to that many IMAP servers, I haven't been able to
 test the new code with a wide variety of parameter combinations. I did
 test both secure and insecure (imaps:// and imap://) connections and
 values of PLAIN and LOGIN for the authMethod.
 
 Perhaps CC'ing those who have touched git-imap-send code over the
 years and asking for their help testing might help?

CC'ing them (going back about 2 years, which already makes the list
quite long) and the people who have taken part in the initial discussion
on this feature in August. And the related Debian bug.

Please test this, folks!

 Signed-off-by: Bernhard Reiter ock...@raz.or.at
 ---
 I rebased the patch on the pu branch, hope that was the right thing to do.
 
 Usually I would appreciate a patch for a new feature not meant for
 the maintenance tracks to be based on 'master', so that it can go to
 the next release without having to wait other changes that may
 conflict with it and that may not yet be ready.
 
 I will try to apply this one to 'pu', rebase it on 'master' to make
 sure the result does not depend on the other topics in flight, and
 then merge it back to 'pu'.

Okay, I'll stick to master. I've rebased on master now that the first
couple related patches are there anyway.

 [...]

 diff --git a/Documentation/git-imap-send.txt 
 b/Documentation/git-imap-send.txt
 index 7d991d9..9d244c4 100644
 --- a/Documentation/git-imap-send.txt
 +++ b/Documentation/git-imap-send.txt
 @@ -75,7 +75,8 @@ imap.preformattedHTML::
  
  imap.authMethod::
  Specify authenticate method for authentication with IMAP server.
 -Current supported method is 'CRAM-MD5' only. If this is not set
 +If you compiled git with the NO_CURL option or if your curl version is
 + 7.35.0, the only supported method is 'CRAM-MD5'. If this is not set
  then 'git imap-send' uses the basic IMAP plaintext LOGIN command.
 
 Hmph, so there is no option that lets me say I know my libcurl is
 new enough but I have some reason not to want to use the new code to
 interact with my imap server, at compile time or (more preferrably)
 at runtime?

Added a runtime option, see below.

 diff --git a/INSTALL b/INSTALL
 index 6ec7a24..e2770a0 100644
 --- a/INSTALL
 +++ b/INSTALL
 @@ -108,18 +108,21 @@ Issues of note:
so you might need to install additional packages other than Perl
itself, e.g. Time::HiRes.
  
 -- openssl library is used by git-imap-send to use IMAP over SSL.
 -  If you don't need it, use NO_OPENSSL.
 +- openssl library is used by git-imap-send to use IMAP over SSL,
 +  unless you're using curl = 7.35.0, in which case that will be
 +  used. If you don't need git-imap-send, you can use NO_OPENSSL.
 
 The last sentence makes it unclear which of the following is true:
 
  - I have sufficiently new libcurl.  I cannot say NO_OPENSSL because
I do need git-imap-send.
 
  - I have sufficiently new libcurl, so openssl is not used by
git-imap send for me.  I can say NO_OPENSSL.
 
 Perhaps
 
  - git-imap-send needs the OpenSSL library to talk IMAP over SSL if
you are using libCurl older than 7.35.0.  Otherwise you can use
NO_OPENSSL without losing git-imap-send.

Fixed.

 diff --git a/git.spec.in b/git.spec.in
 index d61d537..9535cc3 100644
 --- a/git.spec.in
 +++ b/git.spec.in
 @@ -8,7 +8,7 @@ License: GPL
  Group:  Development/Tools
  URL:http://kernel.org/pub/software/scm/git/
  Source: http://kernel.org/pub/software/scm/git/%{name}-%{version}.tar.gz
 -BuildRequires:  zlib-devel = 1.2, openssl-devel, curl-devel, 
 expat-devel, gettext  %{!?_without_docs:, xmlto, asciidoc  6.0.3}
 +BuildRequires:  zlib-devel = 1.2, openssl-devel, curl-devel = 7.35.0, 
 expat-devel, gettext  %{!?_without_docs:, xmlto, asciidoc  6.0.3}
 
 This is very iffy.  It incompatible with the body of the patch where
 you allow older curl library and because you depend on openssl-devel
 you wouldn't lose imap-send.

Okay, removed the version requirement.

 @@ -1391,29 +1518,13 @@ int main(int argc, char **argv)
 [...]
 
 Much more nicely done.  It appears that you could already turn

Bug#434599: [PATCH/RFC] git-imap-send: use libcurl for implementation

[Bernhard Reiter]

Am 2014-08-17 um 20:42 schrieb Jeff King:
 [...]
 
 I'm not sure I understand this comment. Even if SSL is not in use,
 wouldn't we be passing a regular pipe to curl, which would break?

 Yeah, we can't do that, and thus would have to keep the handwritten IMAP
 implementation just for the tunnel case (allowing to drop only the
 OpenSSL specific stuff), see my other email:
 http://www.mail-archive.com/git@vger.kernel.org/msg56791.html (the
 relevant part is pretty far down at the bottom).
 
 I'd really love it if we could make this work with tunnels and
 eventually get rid of the hand-written imap code entirely. I agree with
 Jonathan that we probably need to keep it around a bit for people on
 older curl, but dropping it is a good goal in the long run. That code
 was forked from the isync project, but mangled enough that we could not
 take bug fixes from upstream. As not many people use imap-send, I
 suspect it is largely unmaintained and the source of many lurking
 bugs[1]. Replacing it with curl's maintained implementation is probably
 a good step.

I'll work on this as soon as I find some time, but as that will include
changes to run-command.c (and possibly other files?), I'd like to cover
that in a commit of its own. Do you guys think the current patch [1] is
good enough for official submission already? If so, do I need some
sort of official review? Documentation/SubmittingPatches says I'm only
supposed to direct it to Junio after the list reaches consensus, so
I'm wondering how to get there... :-)

Bernhard


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

Bug#434599: [PATCH/RFC] git-imap-send: use libcurl for implementation

[Bernhard Reiter]

Am 2014-08-17 um 10:30 schrieb Jeff King:
 On Tue, Aug 12, 2014 at 06:59:17PM -0700, Jonathan Nieder wrote:
 
 +   curl_socket_t sockfd = tunnel.out; // what about tunnel.in ?

 Hmm.  curl expects to get a socket it can send(), recv(), setsockopt(),
 etc on instead of a pair of fds to read() and write().
 
 I wonder if we could teach run_command to optionally use socketpair()
 instead of pipe(). 

That sounds like a good idea to me.

 I'm not sure if that would cause problems on Windows,
 though.

Apparently socketpair is not available there. Googling socketpair
windows yields, among a lot of other useful resources, the following
relatively actively maintained ~150 LOC, BSD-3-clause-licensed,
implementation:

https://github.com/ncm/selectable-socketpair

That license is GPL compatible, so should we consider including that
implementation with git? That's the kind of stuff that goes to
compat/win32, right?

One thing to consider: seems like socketpair() gives AF_LOCAL sockets,
so I've asked [1] on the curl ML if that would work or if libcurl needs
an AF_INET one.

 I wonder why someone would want to use SSL through a tunnel, though.
 Currently it's impossible to get to the SSL codepath when a tunnel is
 active (it's in the 'else' block an 'if (srvc-tunnel)').  If that
 property is preserved, then we should be safe.
 
 I'm not sure I understand this comment. Even if SSL is not in use,
 wouldn't we be passing a regular pipe to curl, which would break?

Yeah, we can't do that, and thus would have to keep the handwritten IMAP
implementation just for the tunnel case (allowing to drop only the
OpenSSL specific stuff), see my other email:
http://www.mail-archive.com/git@vger.kernel.org/msg56791.html (the
relevant part is pretty far down at the bottom).

Bernhard

[1] http://curl.haxx.se/mail/lib-2014-08/0131.html


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

Bug#434599: [PATCH/RFC] git-imap-send: use libcurl for implementation

[Bernhard Reiter]

Use libcurl's high-level API functions to implement git-imap-send
instead of the previous low-level OpenSSL-based functions.

Since version 7.30.0, libcurl's API has been able to communicate with
IMAP servers. Using those high-level functions instead of the current
ones would reduce imap-send.c by some 1200 lines of code. For now,
the old ones are wrapped in #ifdefs, and the new functions are enabled
by make if curl's version is = 7.35.0, from which version on curl's
CURLOPT_LOGIN_OPTIONS (enabling IMAP authentication) parameter has been
available.

As I don't have access to that many IMAP servers, I haven't been able to
test the new code with a wide variety of parameter combinations. I did
test both secure and insecure (imaps:// and imap://) connections and
values of PLAIN and LOGIN for the authMethod.

Signed-off-by: Bernhard Reiter ock...@raz.or.at
---
Am 2014-08-13 um 03:59 schrieb Jonathan Nieder:
 Bernhard Reiter wrote:
 [...]

 Wow!  This sounds lovely.  Thanks for working on this.

Well thanks for the friendly welcome and the helpful comments!

I'm attaching a patch where I've applied the fixes you suggested, plus:

* I added the lf_to_crlf conversion to the curl codepath as
communication with another IMAP server I tried was broken without it.

* I added STARTTLS. (That's just the
curl_easy_setopt(curl, CURLOPT_USE_SSL, (long)CURLUSESSL_ALL);
line)

* I tested (and fixed) authentication, i.e. the auth_method stuff. As
the corresponding CURLOPT_LOGIN_OPTIONS flag has only been available
starting with curl 7.35.0, I've bumped the required version to that.
(Apparently it was possible to achieve the same effect with a different
option in between versions 7.31.0 and 7.34.0 [1], but I haven't found
yet how. Is it worth the effort?)

* I made that file scope imap_folder a member of struct imap_server_conf
(named folder), which makes some things easier.

 @@ -1417,31 +269,89 @@ int main(int argc, char **argv)
  return 1;
  }

 +curl_global_init(CURL_GLOBAL_ALL);

 http.c seems to make the same mistake,

Patch at http://permalink.gmane.org/gmane.comp.version-control.git/255221

 [...]
 +if (server.tunnel) {
 +const char *argv[] = { server.tunnel, NULL };
 +struct child_process tunnel = {NULL};

 (not about this patch) Could use the child_proccess's internal
 argv_array:

   struct child_process tunnel = {NULL};
   argv_array_push(tunnel.args, server.tunnel);

Patch at
http://permalink.gmane.org/gmane.comp.version-control.git/255220 (The
patch attached to this mail depends on that one.)

No comments on those patches yet, though.

 (about this patch) Would there be a way to make this part reuse the
 existing code?  The only difference I see is that *srvc has been
 renamed to server, which doesn't seem to be related to the change of
 transport API from OpenSSL to libcurl.

 [...]
 +curl_socket_t sockfd = tunnel.out; // what about tunnel.in ?

 Hmm.  curl expects to get a socket it can send(), recv(), setsockopt(),
 etc on instead of a pair of fds to read() and write().

 I wonder why someone would want to use SSL through a tunnel, though.
 Currently it's impossible to get to the SSL codepath when a tunnel
 is active (it's in the 'else' block an 'if (srvc-tunnel)').  If that
 property is preserved, then we should be safe.

Now this turns out to be the one major annoyance left, because we only
have those two fds (actually pipes, right?), and not a socket that we
could pass to curl, so we can't use it to talk to the IMAP server. So if
the tunnel parameter is set, we're stuck with the old hand-written IMAP
handling routines, even with USE_CURL_FOR_IMAP set, meaning I can't wrap
as much in #ifdef...#endif blocks as I'd like. :-( BTW, due to two of
the blocks that I do add I get a compiler warning about the curl handle
remaining possibly unitialized :-/
I've removed the curl specific socket handling routines, as we can't use
them anyway for now.

I've asked about passing two pipes instead of a socket to curl on their
ML [1] as this has even been discussed before [2], but unfortunately,
there doesn't seem to be a solution as of yet. I've also asked on SO
[3], but no answers yet.

 To summarize:
 [...]

  * As soon as you're ready to roll this out to a wider audience of
testers, let me know, and we can try to get it into shape for
Junio's next branch (and hence Debian experimental).

Is this one good enough already?

Bernhard

[1] http://sourceforge.net/p/curl/bugs/1372/
[2] http://curl.haxx.se/mail/lib-2014-08/0102.html
[3] http://curl.haxx.se/mail/lib-2011-05/0102.html
[4]
http://stackoverflow.com/questions/25306264/connect-in-and-out-pipes-to-network-socket

 Documentation/git-imap-send.txt |   3 +-
 INSTALL |  15 +++---
 Makefile|  16 +-
 git.spec.in |   5 +-
 imap-send.c | 109
+---
 5 files

Bug#434599: HMAC_MD5 in libgcrypt

[Bernhard Reiter]

I did some quick and uninformed research, and found that libgcrypt has
support for the HMAC_MD5 algorithm nowadays (in git since about end of
2013, IIRC). Is that something that Mike Miller's code could employ to
implement MD5-CRAM authentication with libgcyrpt-based versions of gnutls?

(As for base64, though, libgcrypt's manual on S-expressions still
denotes the constant GCRYSEXP_FMT_BASE64 with Not currently supported...)

Bernhard


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

Bug#434599: HMAC_MD5 in libgcrypt

[Bernhard Reiter]

Okay, informed myself a bit more ;-)

Apparently old (libgcrypt-based) gnutls isn't of any interest any more.

There's a good resume of the issues concerning use of (current,
nettle-based) gnutls for git in Debian and Ubuntu at
https://bugs.launchpad.net/ubuntu/+source/git/+bug/432786 , which I've
just updated with a comment on the current situation. In brief, it
should be both technically and legally feasible to use gnutls and nettle
in order to implement imap-send for current versions of git!


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

Bug#745807: swift-im does not play sounds by default because of nas dependency

[Bernhard Reiter]

Package: swift-im
Version: 2.0~beta1+dev47-1
Severity: minor

swift-im uses Qt 4.x and would like to play with QSound::play().
By default on a desktop (with windows manager Plasma, that gets you Pulse-Audio)
the sound for new messages is not playing.

In Qt4 on Debian I assume that the Network Audio System will be used,
which, according to the Qt4 documentation 
will fail sliently if there is no nasd setup and running.
See http://qt-project.org/doc/qt-4.8/qsound.html#details

Qt5 seems to have a reworked system here. 
So there are several ways to improve the user experience:
a) build swift-im with qt5
b) add the nasd as Recommendation (I'm not sure if this work well with
   other sound applications, and I don't know how to set up nasd properly.)
c) disable the configuration option by patch, hmm if there were more
   detailed messages, maybe the notifation mechanism of Plasma could play
   sounds instead.
d) help upstream (oh, I think you are Debian Maintainer and Upstream. :) )
   to use something else to play sounds

Thanks for maintaining swift-im in Debian!
Regards,
Bernhard

-- System Information:
Debian Release: 7.4
  APT prefers stable
  APT policy: (550, 'stable')
Architecture: i386 (i686)

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

Versions of packages swift-im depends on:
ii  libavahi-client30.6.31-99intevation1
ii  libavahi-common30.6.31-99intevation1
ii  libboost-date-time1.49.01.49.0-3.2
ii  libboost-filesystem1.49.0   1.49.0-3.2
ii  libboost-program-options1.49.0  1.49.0-3.2
ii  libboost-regex1.49.01.49.0-3.2
ii  libboost-signals1.49.0  1.49.0-3.2
ii  libboost-system1.49.0   1.49.0-3.2
ii  libboost-thread1.49.0   1.49.0-3.2
ii  libc6   2.13-38+deb7u1
ii  libgcc1 1:4.7.2-5
ii  libidn111.25-2
ii  libqt4-dbus 4:4.8.2+dfsg-11
ii  libqtcore4  4:4.8.2+dfsg-11
ii  libqtgui4   4:4.8.2+dfsg-11
ii  libqtwebkit42.2.1-5
ii  libssl1.0.0 1.0.1e-2+deb7u7
ii  libstdc++6  4.7.2-5
ii  libswiften2 2.0~beta1+dev47-1
ii  libx11-62:1.5.0-1+deb7u1
ii  libxml2 2.8.0+dfsg1-7+nmu2
ii  libxss1 1:1.2.2-1
ii  zlib1g  1:1.2.7.dfsg-13

swift-im recommends no packages.

swift-im suggests no packages.

-- no debconf information


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

Bug#744707: AW: Re: Bug#744707: [gourmet] [DFSG] Missing source

[Bernhard Reiter]

Yeah, okay.

Bernhard

 Ursprüngliche Nachricht 
Von: Christian Marillat maril...@free.fr 
Datum:  
An: bastien ROUCARIES roucaries.bast...@gmail.com 
Cc: 744...@bugs.debian.org,cont...@bugs.debian.org,Bernhard Reiter 
ock...@raz.or.at 
Betreff: Re: Bug#744707: [gourmet] [DFSG] Missing source 
 
forwarded 744707 Bernhard Reiter ock...@raz.or.at
thanks

bastien ROUCARIES roucaries.bast...@gmail.com writes:

 Package: gourmet
 Severity: serious
 Version:  0.17.2-1
 user: debian...@lists.debian.org
 usertags: source-is-missing
 severity: serious
 X-Debbugs-CC: ftpmas...@debian.org

 Hi,

 Your package seems to include some files that lack sources
 in prefered forms of modification:

 gourmet/plugins/web_plugin/gourmetweb/templates/jquery.js

 According to Debian Free Software Guidelines [1] (DFSG) #2:
  The program must include source code, and must allow distribution 
   in source code as well as compiled form..

Bernhard, could you fix this bug in the next release ?

Christian

Bug#711581: Ubuntu packages on Launchpad

[Bernhard Reiter]

There has been some disucssion [1] on the Darling mailing list regarding
Ubuntu packages for darling and its GNUstep dependencies, and someone
seems to have begun implementing them [2, 3] which he claims to be
functional, so maybe that could be used as a start.

[1] https://groups.google.com/forum/#!topic/darling-project/gL-qGTgtDC4
[2] https://launchpad.net/darling-emu (see the corresponding bzr
branches in the Code section)
[3] https://launchpad.net/gnustep


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

Bug#744118: fcrackzip: Use libunzip instead of system()

[Bernhard Reiter]

Package: fcrackzip
Version: 1.0-5
Severity: wishlist

I've found this patch [1] which uses libunzip instead of calling unzip via
system and claims to speed up fcrackzip by a factor of 1000. Please consider
releasing a new
version with that patch applied!

[1]
https://github.com/hyc/fcrackzip/commit/156ee9793cc2c79e6d39b3354f39b2d0fccdbbaa



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

Kernel: Linux 3.11.0-19-generic (SMP w/2 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages fcrackzip depends on:
ii  libc6  2.17-93ubuntu4

fcrackzip recommends no packages.

Versions of packages fcrackzip suggests:
ii  unzip 6.0-9ubuntu1
ii  wamerican [wordlist]  7.1-1
ii  wbritish [wordlist]   7.1-1
ii  wngerman [wordlist]   20120607-1
ii  wogerman [wordlist]   1:2-28
ii  wswiss [wordlist] 20120607-1

-- no debconf information


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

Bug#740807: slimit: homepage link outdated

[Bernhard Reiter]

Package: slimit
Version: 0.7.4-1, 0.8.1-1
Severity: minor

Dear TANIGUCHI, Dear Python Application Maintainers,

the homepage is still given as slimit.org,
a current request to that page shows that it does not carry
the homepage anymore. archive.org confirms that this has been the case
for at least a year.

I recomment chaning the url in the .dsc to what pypy has:
Home Page: http://slimit.readthedocs.org

In addition it is probably a good idea to patch other places
as well.

Best Regards and thanks for maintaining slimit,
Bernhard


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

Bug#725505: gnupg2: Pubkey list in gpg2 --version output contains question marks

[Bernhard Reiter]

The Author of Gnupg Werner Koch writes:

Due to changes in Libgcrypt 1.6 some internal mappings had to
be implemented which unfortunately introduced this bug.  It is however
only an informational message and not relevant for the internal working.

http://lists.wald.intevation.org/pipermail/gpg4win-users-en/2013-October/000849.html



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

Bug#709104: Should not Depends or Recommends gnupg-agent

[Bernhard Reiter]

Hi Josh, Eric,

to add my 0.02 Euro Cents:

I do believe that gnupg2 should depend on gpg-agent!

Rationale: Some users will be suprised by core behaviour of gnupg2
not working correctly in the case of gpg-agent not being installed. 

About dragging in GUI resources via pinentry: There is pinentry-curses
which does not GTK or Qt dependencies. So it does not drag in GUI resources.

About gnome-keyring: The  the GnuPG core developer Werner Koch considers
the hijacking that gnome-keyring does to gpg2 - gpg-agent _hostile_
as it degrades the user experience of Gnupg for many.
Reference 
http://lists.wald.intevation.org/pipermail/gpg4win-devel/2013-July/001253.html
 I consider it hostile to hijack the communication between
ssh and its ssh-agent.  We ain't no gnomes [1].

[1] gnome-keyring hijacks the communcation between gpg and gpg-agent.
It tries to proxy some stuff but that is mostly broken.  For some
years now we get reports that gpg2 is not working and after a closer
inspection we always see that gnome-keyring is the culprit.  It is
possible to switch this misfeature off but that is not the default.

Best Regards,
Bernhard

-- 
www.intevation.de/~bernhard (CEO)www.fsfe.org (Founding GA Member)
Intevation GmbH, Osnabrück, Germany; Amtsgericht Osnabrück, HRB 18998
Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


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

Bug#725804: gnupg2: config path /etc/gnupg2/ missmatches documentation b/c debian/patches/01-gnupg2-rename.diff

[Bernhard Reiter]

Package: gnupg2
Version: 2.0.19-2
Severity: normal

Dear Eric,
thanks again for maintaining GnuPG2, it is a very important package!


I've upgraded to Wheezy using a new gnupg2 package and suddely my S/MIME 
stopped working. My old gnupg was a standard build
(actually gnupg2_2.0.19-0kk1 from
http://files.kolab.org/apt/releases/dists/squeeze/stable/source/ )

One difference I've found its that gpg-agent now searches a different
paths /etc/gnupg2/trustlist.txt is searched because of 
debian/patches/01-gnupg2-rename.diff (I believe)

And the documentation (manpages, info pages) does not reflect this
fact. I consider it severity normal because GnuPG users - even experienced
ones - will have a really hard time if they follow the instructions,
but stuff does not work as expected. Especially with the approval
of trust for gpgsm, this is hard to debug.

Suggestion: Improve the patch to change the documentation as well.

Details:
Some place where I saw the wrong documentation:
zgrep '/etc/gnupg' /usr/share/man/man1/gpg-agent.1.gz
list of trusted certificates (e.g. \(oq\fI/etc/gnupg/trustlist.txt\fR\(cq).

zgrep '\/etc\/gnupg' /usr/share/info/gnupg*
/usr/share/info/gnupg.info-1.gz:searched in the directory `/etc/gnupg' and 
variable data below `/var';
/usr/share/info/gnupg.info-1.gz:/etc/gnupg/trustlist.txt.
/usr/share/info/gnupg.info-1.gz: list of trusted certificates (e.g. 
`/etc/gnupg/trustlist.txt').
/usr/share/info/gnupg.info-1.gz: system configuration directory (e.g. 
`/etc/gnupg/help.de.txt').
/usr/share/info/gnupg.info-1.gz: configuration file (usually 
`/etc/gnupg/gpgconf.conf').
/usr/share/info/gnupg.info-1.gz:`/etc/gnupg/gpgconf.conf'
/usr/share/info/gnupg.info-1.gz:configuration files for all users after 
`/etc/gnupg/gpgconf.conf' has

How to prove that gpg-agent for instance looks in the wrong place:


LANG=C gpg-agent -vvv --debug-all --log-file=- --server --no-detach
gpg-agent[7520]: reading options from `/home/bernhard/.gnupg/gpg-agent.conf'
gpg-agent[7520]: enabled debug flags: assuan
gpg-agent[7520]: chan_5 - OK Pleased to meet you
OK Pleased to meet you
ISTRUSTED 11B91B31EE09E0844D254E587A65CE5184F36B70
gpg-agent[7520]: chan_5 - ISTRUSTED 11B91B31EE09E0844D254E587A65CE5184F36B70
2013-10-08 17:15:12 gpg-agent[7520] system trustlist 
`/etc/gnupg2/trustlist.txt' not available
gpg-agent[7520]: chan_5 - ERR 67108962 Not trusted GPG Agent
ERR 67108962 Not trusted GPG Agent
BYE
gpg-agent[7520]: chan_5 - BYE
gpg-agent[7520]: chan_5 - OK closing connection
OK closing connection

ii  gnupg-agent  2.0.19-2

I expect the problem to be there with 2.0.22-1 as well.

Best Regards,
Bernhard


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

Bug#718413: Gourmet 0.16.1 released

[Bernhard Reiter]

I've just released version 0.16.1 of Gourmet recipe manager [1].

I've also updated my Debian packaging [2], trying to somewhat reduce the
diff between yours and mine.
Please do at least take a look at my debian/changelog.

Kind regards
Bernhard

[1] https://github.com/thinkle/gourmet/releases/tag/0.16.1
[2] https://github.com/thinkle/gourmet/tree/debian/debian

Bug#718413: gourmet: Please remove python-glade2 dependency

[Bernhard Reiter]

Package: gourmet
Version: 0.16.0-5
Severity: normal

(Discussion continued from [1])

To reiterate:

python-glade2 is no longer required for the gourmet Debian package. I've put
quite some effort into migrating upstream from (py)glade to gtk.Builder,
which is just part of python-gtk2. If you don't believe me, just try
building and running the package without the python-glade2 dependency
(which BTW is what I did before requesting this change in the first
place, and which I've tested once again just now to make sure).

(You also don't need python-gtk2-dev and python-elib.intl in
Build-Depends-Indep. Just tested it, builds and runs fine without. Also,
you don't need python | python-all | python-dev | python-all-dev --
python-all is sufficient.)

Another thing: could you please change the Homepage: field in
debian/control to the new location, http://thinkle.github.io/gourmet/ ?

Furthermore, I'd be grateful if you used debian/copyright from [2], as it's in
the recommended copyright-format/1.0, and covers some contributors and a file
with a different license that aren't covered by the current debian/copyright
file.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709299
[2] https://github.com/thinkle/gourmet/blob/debian/debian/copyright



-- System Information:
Debian Release: wheezy/sid
  APT prefers precise-updates
  APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500, 
'precise-proposed'), (500, 'precise')
Architecture: amd64 (x86_64)

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

Versions of packages gourmet depends on:
ii  python 2.7.3-0ubuntu2.2
ii  python-elib.intl   0.0.3~git20110809-2
ii  python-gtk22.24.0-3
ii  python-imaging 1.1.7-4
ii  python-poppler 0.12.1-4+ubuntu1
ii  python-reportlab   2.5-1.1build1
ii  python-sqlalchemy  0.7.4-1ubuntu0.1
ii  python2.7  2.7.3-0ubuntu3.3

Versions of packages gourmet recommends:
ii  python-gtkspell  2.25.3-11

Versions of packages gourmet suggests:
ii  python-gst0.10  0.10.22-3ubuntu0.1


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

Bug#709299: closed by Christian Marillat maril...@debian.org (Bug#709299: fixed in gourmet 0.16.0-4)

[Bernhard Reiter]

Am 2013-06-13 15:13, schrieb Christian Marillat:

Bernhard Reiter ock...@raz.or.at writes:

Please also remove python-glade2, which is also obsolete now.


No, not in Debian.


Yes, it is no longer required for the gourmet Debian package. I've put 
quite some effort into migrating upstream from (py)glade to gtk.Builder, 
which is just part of python-gtk2. If you don't believe me, just try 
building and running the package without the python-glade2 dependency 
(which BTW is what I did before requesting this change in the first 
place, and which I've tested once again just now to make sure).


(You also don't need python-gtk2-dev and python-elib.intl in 
Build-Depends-Indep. Just tested it, builds and runs fine without. Also, 
you don't need python | python-all | python-dev | python-all-dev -- 
python-all is sufficient, but it should be in Build-Depends, not 
Build-Depends-Indep.)


Another thing: could you please change the Homepage: field in 
debian/control to the new location, http://thinkle.github.io/gourmet/ ?



Furthermore, please:

* Add python-beautifulsoup to Recommends, and close bug #530403
(required for web import plugin).


I'll do that in the next upload.


* Add python-gst0.10 to Recommends (required for playing sound).


Not in Recommends in Suggests.


Fine.


* Add patches lc-all-c and license-location found at [1].
   (lc-all-c fixes a bug that caused gourmet to fail when LC_ALL=C, and
license-location changes the location used to look for the license, as
LICENSE is deletedby debian/rules, but gourmet would look for it when
showing the About dialog.)


I'll do that in the next upload.

[...]

The ellipsis meaning that you're not going to apply those other 
suggested changes? You could've at least told me that explicitly.



* FWIW, lintian suggests adding Pre-Depends: dpkg (= 1.15.6~) for
similar reasons.
* Backporting would also be faciliated by build-depending on debhelper
(= 7.0.50~) instead of 9, which I believe is sufficient.


Certainly not. debhelper 9 is in stable/testing/unstable we don't needs
debhelper 7.

[...]


PS: Doing this twice (producing a Debian package with a comprehensive
changelog, and then asking you to adopt the changes) feels quite
redundant, frankly. Do you really fear I'd be messing with your package
if I was granted Uploader rights?


Apparently you don't understand, Ubuntu isn't Debian.


Please spare me the snotty, and unrelated comments. I'm quite aware of 
the differences between Debian and Ubuntu, which is why I originally 
prepared an actual Debian package to which I pointed you around the 
beginning of *March* [1]. OTOH, the Ubuntu specific modifications found 
in [2] are also near-trivial. Either way, you could've just taken a 
closer look at my package and applied those changes at once that are now 
taking up as many as five iterations and counting. Not too efficient, is it?


Bernhard

[1] http://lists.alioth.debian.org/pipermail/python-apps-
team/2013-March/007222.html
[2] https://launchpad.net/ubuntu/raring/+source/gourmet


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

Bug#709299: closed by Christian Marillat maril...@debian.org (Bug#709299: fixed in gourmet 0.16.0-4)

[Bernhard Reiter]

Am 2013-06-21 02:41, schrieb Bernhard Reiter:

python-all is sufficient, but it should be in Build-Depends, not
Build-Depends-Indep.)


I overlooked that you do have debhelper in Build-Depends already, so 
python-all is actually fine to have in Build-Depends-Indep.


Bernhard


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

Bug#709299: closed by Christian Marillat maril...@debian.org (Bug#709299: fixed in gourmet 0.16.0-4)

[Bernhard Reiter]

[...]
  Changes: 
   gourmet (0.16.0-4) unstable; urgency=low
   .
 * Remove old patch 01_fix_raise_str.diff and remove python-gnome2 from
   Recommends (Closes: #709299).

Please also remove python-glade2, which is also obsolete now.

Furthermore, please:

* Add python-beautifulsoup to Recommends, and close bug #530403
(required for web import plugin).
* Add python-gst0.10 to Recommends (required for playing sound).
* Add patches lc-all-c and license-location found at [1].
  (lc-all-c fixes a bug that caused gourmet to fail when LC_ALL=C, and
license-location changes the location used to look for the license, as
LICENSE is deletedby debian/rules, but gourmet would look for it when
showing the About dialog.)
* Add manpages file from [1].
* Add debian/copyright from [1] -- it's in
packaging-manuals/copyright-format/1.0 (formerly DEP-5) format, and adds
contributors as of version.py
* I'm pretty sure you can also drop python-gtk2-dev from
Build-Depends-Indep.

* I'd still suggest versioned Depends where applicable to faciliate
backporting, downstream packaging, etc, as I consider it good practice,
but that's up to you. 
* FWIW, lintian suggests adding Pre-Depends: dpkg (= 1.15.6~) for
similar reasons. 
* Backporting would also be faciliated by build-depending on debhelper
(= 7.0.50~) instead of 9, which I believe is sufficient.

---

TIA
Bernhard

 [1]
https://launchpad.net/ubuntu/raring/+source/gourmet/0.16.0-0ubuntu1/+files/gourmet_0.16.0-0ubuntu1.debian.tar.gz


PS: Doing this twice (producing a Debian package with a comprehensive
changelog, and then asking you to adopt the changes) feels quite
redundant, frankly. Do you really fear I'd be messing with your package
if I was granted Uploader rights?


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

Bug#709299: gourmet: Please adjust patches and dependencies

[Bernhard Reiter]

Package: gourmet
Version: gourmet
Severity: normal

First of all, thanks for upgrading to 0.16.0. (I'm an upstream dev, and a
casual Debian contributor, though no DM or DD.)

I've noticed, that you're still shipping an obsolete patch
(01_fix_raise_str.diff). Also, the Depends: and Recommends: sections of
debian/control aren't quite up-to-date; for example, you can safely drop
python-glade and python-gnome2, while the version for python-gtk2 should be at
least (=2.16.0) (though I'd rather make sure and go for =2.22.0), and python-
sqlalchemy (= 0.7), as there has been some API changes since 0.6 which led to
conflicts in the past.

As noted before [1], I've tried to produce an updated deb package for the
0.16.0 release myself, which (with some slight modifications) then made its way
into Ubuntu Raring. I'm somewhat curious if you weren't happy with that
package, as I was hoping it would provide a good starting point for the
official Debian package, which I hoped to faciliate by a rather comprehensive
changelog [2] (you'll see there's a couple of other relevant items, as e.g. the
new python-beautifulsoup dependency, and the Closes: #530403 bit).

I'd like to restate my interest in contributing to your gourmet debian package,
ideally via the Python Applications Team. Please tell me if that'd be okay with
you; I'd just like to avoid redundant work in the future, and help make sure
that the Debian package is up-to-date.

[1] http://lists.alioth.debian.org/pipermail/python-apps-
team/2013-March/007222.html
[2] https://launchpad.net/ubuntu/raring/+source/gourmet/+changelog



-- System Information:
Debian Release: wheezy/sid
  APT prefers precise-updates
  APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500, 
'precise-proposed'), (500, 'precise')
Architecture: amd64 (x86_64)

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

Versions of packages gourmet depends on:
ii  dpkg   1.16.1.2ubuntu7.1
ii  python 2.7.3-0ubuntu2.1
ii  python-elib.intl   0.0.3~git20110809-2
ii  python-gtk22.24.0-3
ii  python-imaging 1.1.7-4
ii  python-poppler 0.12.1-4+ubuntu1
ii  python-reportlab   2.5-1.1build1
ii  python-sqlalchemy  0.7.4-1ubuntu0.1
ii  python2.7  2.7.3-0ubuntu3.2

Versions of packages gourmet recommends:
ii  python-beautifulsoup  3.2.0-2build1
ii  python-gst0.100.10.22-3ubuntu0.1
ii  python-gtkspell   2.25.3-11

gourmet suggests no packages.


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

Bug#669068: ITP: trelby -- movie screenplay writing software

[Bernhard Reiter]

Am Samstag, den 09.03.2013, 10:29 +0100 schrieb W. Martin Borgert:
 Any news on your ITP? I see, that there was a lot of progress in
 respect to FHS compliance and Debian packaging in github. Are you
 still working on this?

Well, I think debian-wise it's pretty much complete. All I'm waiting for
now is upstream to release 2.3, after which I'd like to...

 Also, consider packaging this in a team, e.g. the Python Applications
 Packaging Team python-apps-t...@lists.alioth.debian.org

... put it into PAPT's svn repo, yes.


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

Bug#687996: sweethome3d: Please package version 3.6.

[Bernhard Reiter]

Package: sweethome3d
Version: 3.4+dfsg-1
Severity: wishlist

SH3D version 3.6 is out (since Sept 6, 2012) and has a couple of nice new
features, so I'd be grateful if the maintainer(s) could take the time to bump
the Debian package to that new upstream version.



-- System Information:
Debian Release: wheezy/sid
  APT prefers precise-updates
  APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500, 
'precise-proposed'), (500, 'precise')
Architecture: amd64 (x86_64)

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

Versions of packages sweethome3d depends on:
ii  icedtea-netx-common 1.2-2ubuntu1.2
ii  java-wrappers   0.1.24
ii  java3ds-fileloader  1.2+dfsg-1
ii  libbatik-java   1.7.ubuntu-8ubuntu1
ii  libfreehep-graphicsio-svg-java  2.1.1-3
ii  libitext-java   2.1.7-2
ii  libjava3d-java  1.5.2+dfsg-5
ii  libsunflow-java 0.07.2.svn396+dfsg-9
ii  openjdk-6-jre   6b24-1.11.4-1ubuntu0.12.04.1
ii  sun-java6-bin   6.26-1natty1
ii  sun-java6-jre   6.26-1natty1

sweethome3d recommends no packages.

sweethome3d suggests no packages.

-- no debconf information


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

Bug#595106: Faenza Icon Theme

[Bernhard Reiter]

I have also been looking into polishing the package from the PPA. 
FWIW, I found the following Google Code site for the Faenza Icon Theme,
which holds a download option for source tarballs containing the SVGs:

http://code.google.com/p/faenza-icon-theme/downloads/list

I think ideally debian/rules should really generate the PNGs from the
latest faenza-sources_*.tar.gz tarball found there.


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

Bug#409048: Asking upstream about XULrunner, licensing, etc.

[Bernhard Reiter]

FYI: http://forums.celtx.com/viewtopic.php?f=4t=20463




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

Bug#669068: ITP: trelby -- movie screenplay writing software

[Bernhard Reiter]

Package: wnpp
Severity: wishlist
Owner: Bernhard Reiter ock...@raz.or.at


* Package name: trelby
  Version : 2.1
  Upstream Author : Anil Gulecha anil.ve...@gmail.com
* URL : http://www.trelby.org/
* License : GPL
  Programming Lang: Python
  Description : movie screenplay writing software



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

Bug#668889: fonts-cmu: Please provide OpenType font instead of TrueType

[Bernhard Reiter]

Package: fonts-cmu
Version: 0.7.0-2
Severity: normal

As upstream also provides a cm-unicode-0.7.0-otf.tar.xz package, please use
that for the Debian package instead of the ttf one, as OpenType has somewhat
superior features compared to TrueType.

(Changing this should be rather straightforward, basically replacing occurences
of ttf - otf and truetype - opentype in most debian/* files)



-- System Information:
Debian Release: wheezy/sid
  APT prefers oneiric-updates
  APT policy: (500, 'oneiric-updates'), (500, 'oneiric-security'), (500, 
'oneiric-proposed'), (500, 'oneiric')
Architecture: amd64 (x86_64)

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



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

Bug#668935: maint-guide: Chapter 5, Other files under the debian directory, doesn't cover the 'links' file

[Bernhard Reiter]

Package: maint-guide
Severity: normal

Please add information about the 'links' file (which is invoked by dh_link).



-- System Information:
Debian Release: wheezy/sid
  APT prefers oneiric-updates
  APT policy: (500, 'oneiric-updates'), (500, 'oneiric-security'), (500, 
'oneiric-proposed'), (500, 'oneiric')
Architecture: amd64 (x86_64)

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



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

Bug#668935: maint-guide: Chapter 5, Other files under the debian directory, doesn't cover the 'links' file

[Bernhard Reiter]

Tags: patch

This is a bit of a mashup from the existing install section plus some
stuff from the dh_link manpage, but I hope it's good enough.

Patch generated against current svn.
Index: maint-guide.en.dbk
===
--- maint-guide.en.dbk	(Revision 9193)
+++ maint-guide.en.dbk	(Arbeitskopie)
@@ -3491,6 +3491,21 @@
 filenamereplaceablepackage/replaceable.info/filename file.
 /para
 /section
+section id=linkstitlefilenamelinks/filename/title
+para
+If you want to have symbolic links created by citerefentryrefentrytitledh_link/refentrytitle manvolnum1/manvolnum/citerefentry, use this file to list pairs of source and destination files to be symlinked. The source files are the already existing files that will be symlinked from. The destination files are the symlinks that will be created. There emphasis role=strongmust/emphasis be an equal number of source and destination files specified. Each pair should be put on its own line, with the source and destination separated by whitespace. Be sure you emphasis role=strongdo/emphasis specify the full filename to both the source and destination files (unlike you would do if you were using something like citerefentryrefentrytitleln/refentrytitle manvolnum1/manvolnum/citerefentry).
+/para
+para
+For example, to create a link filename/usr/bin/replaceablebar/replaceable/filename that points to filename/usr/lib/replaceablefoo/replaceable/replaceablebar/replaceable/filename, use the following line in filenamelinks/filename:
+screen
+usr/lib/replaceablefoo/replaceable/replaceablebar/replaceable usr/bin/replaceablebar/replaceable
+/screen
+/para
+para
+As with filenameinstall/filename, multiple filenamelinks/filename files can be used for individual packages, using filenamereplaceablepackage-1/replaceable.links/filename,
+filenamereplaceablepackage-2/replaceable.links/filename, etc.
+/para
+/section
 section id=lintiantitlefilename{replaceablepackage/replaceable.,source/}lintian-overrides/filename/title
 para
 If systemitem role=packagelintian/systemitem reports an erroneous

Bug#667072: ITP: fonts-quattrocento -- classic, elegant, sober and strong Roman typeface

[Bernhard Reiter]

Package: wnpp
Severity: wishlist
Owner: Bernhard Reiter ock...@raz.or.at


* Package name   : fonts-quattrocento
  Version : 1.1
  Upstream Author : Pablo Impallari impall...@gmail.com
* URL : http://www.impallari.com/quattrocento/
* License : OFL 1.1
  Description : classic, elegant, sober and strong Roman typeface



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

Bug#667088: RFS: fonts-quattrocento/1.1-1 [ITP]

[Bernhard Reiter]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: pkg-fonts-de...@lists.alioth.debian.org

  Dear mentors,

  I am looking for a sponsor for my package fonts-quattrocento

 * Package name: fonts-quattrocento
   Version : 1.1-1
   Upstream Author : Pablo Impallari impall...@gmail.com
 * URL : http://www.impallari.com/quattrocento
 * License : OFL 1.1
   Section : fonts

  It builds those binary packages:

fonts-quattrocento - classic, elegant, sober and strong Roman
typeface

  To access further information about this package, please visit the
following URL:

  http://mentors.debian.net/package/fonts-quattrocento


  Alternatively, one can download the package with dget using this
command:

dget -x
http://mentors.debian.net/debian/pool/main/f/fonts-quattrocento/fonts-quattrocento_1.1-1.dsc


  Regards,
   Bernhard Reiter




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

Bug#666546: ITP: fonts-cabin -- humanist sans serif font

[Bernhard Reiter]

Package: wnpp
Severity: wishlist
Owner: Bernhard Reiter ock...@raz.or.at


* Package name: fonts-cabin
  Version : 1.5
  Upstream Author : Pablo Impallari impall...@gmail.com
* URL : http://impallari.com/cabin
* License : OFL 1.1
  Description : humanist sans serif font



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

Bug#666553: ITP: fonts-dosis -- very simple, rounded, sans serif font family

[Bernhard Reiter]

Package: wnpp
Severity: wishlist
Owner: Bernhard Reiter ock...@raz.or.at


* Package name: fonts-dosis
  Version : 1.7
  Upstream Author : Pablo Impallari impall...@gmail.com
* URL : http://impallari.com/dosis
* License : OFL 1.1
  Description : very simple, rounded, sans serif font family



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

Bug#666555: RFS: fonts-cabin/1.5-1 [ITP]

[Bernhard Reiter]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package fonts-cabin

 * Package name: fonts-cabin
   Version : 1.5-1
   Upstream Author : Pablo Impallari impall...@gmail.com
 * URL : http://www.impallari.com/cabin
 * License : OFL 1.1
   Section : fonts

  It builds those binary packages:

fonts-cabin - humanist sans serif font

  To access further information about this package, please visit the
following URL:

  http://mentors.debian.net/package/fonts-cabin


  Alternatively, one can download the package with dget using this
command:

dget -x
http://mentors.debian.net/debian/pool/main/f/fonts-cabin/fonts-cabin_1.5-1.dsc


  Regards,
   Bernhard Reiter




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

Bug#666558: RFS: fonts-dosis/1.7-1 [ITP]

[Bernhard Reiter]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package fonts-dosis

 * Package name: fonts-dosis
   Version : 1.7-1
   Upstream Author : Pablo Impallari impall...@gmail.com
 * URL : http://www.impallari.com/dosis
 * License : OFL 1.1
   Section : fonts

  It builds those binary packages:

fonts-dosis - very simple, rounded, sans serif font family

  To access further information about this package, please visit the
following URL:

  http://mentors.debian.net/package/fonts-dosis


  Alternatively, one can download the package with dget using this
command:

dget -x
http://mentors.debian.net/debian/pool/main/f/fonts-dosis/fonts-dosis_1.7-1.dsc


  Regards,
   Bernhard Reiter




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

Bug#666133: ITP: fonts-cabinsketch -- playful sister of the Cabin Family

[Bernhard Reiter]

Package: wnpp
Severity: wishlist
Owner: Bernhard Reiter ock...@raz.or.at


* Package name: fonts-cabinsketch
  Version : 1.02
  Upstream Author : Pablo Impallari impall...@gmail.com
* URL : http://www.impallari.com/cabinsketch
* License : OFL 1.1
  Description : playful sister of the Cabin Family



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

Bug#665655: RFS: fonts-dancingscript/1.1-1 [ITP]

[Bernhard Reiter]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package fonts-dancingscript

 * Package name: fonts-dancingscript
   Version : 1.1-1
   Upstream Author : Pablo Impallari impall...@gmail.com
 * URL : http://www.impallari.com/dancing
 * License : OFL 1.1
   Section : fonts

It builds those binary packages:

  fonts-dancingscript - lively casual script with bouncing letters and
size changes

To access further information about this package, please visit the
following URL:

http://mentors.debian.net/package/fonts-dancingscript

Alternatively, one can download the package with dget using this
command:

dget -x
http://mentors.debian.net/debian/pool/main/f/fonts-dancingscript/fonts-dancingscript_1.1-1.dsc

Regards,
Bernhard Reiter




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

Bug#665659: RFS: fonts-lobstertwo/2.0-1 [ITP]

[Bernhard Reiter]

Package: sponsorship-requests
Severity: normal [important for RC bugs, wishlist for new packages]

Dear mentors,

I am looking for a sponsor for my package fonts-lobstertwo

 * Package name: fonts-lobstertwo
   Version : 2.0-1
   Upstream Author : [fill in name and email of upstream]
 * URL : [fill in URL of upstreams web site]
 * License : [fill in]
   Section : fonts

It builds those binary packages:

 fonts-lobster - bold condensed script with many ligatures and
alternates
 fonts-lobstertwo - updated and improved family version of the Lobster
font

To access further information about this package, please visit the
following URL:

http://mentors.debian.net/package/fonts-lobstertwo


Alternatively, one can download the package with dget using this
command:

dget -x
http://mentors.debian.net/debian/pool/main/f/fonts-lobstertwo/fonts-lobstertwo_2.0-1.dsc

Regards,
Bernhard Reiter




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

Bug#665663: ITP: fonts-kaushanscript -- script font that feels like writing quickly with an inked brush

[Bernhard Reiter]

Package: wnpp
Severity: wishlist
Owner: Bernhard Reiter ock...@raz.or.at


* Package name: fonts-kaushanscript
  Version : 1.2
  Upstream Author : Pablo Impallari impall...@gmail.com
* URL : http://impallari.com/kaushan
* License : OFL 1.1
  Description : script font that feels like writing quickly with an inked
brush



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

Bug#664145: ITP: fonts-dancingscript -- lively casual script with bouncing letters and size changes

[Bernhard Reiter]

Package: wnpp
Severity: wishlist
Owner: Bernhard Reiter ock...@raz.or.at


* Package name: fonts-dancingscript
  Version : 1.1
  Upstream Author : Pablo Impallari impall...@gmail.com
* URL : http://www.impallari.com/dancing
* License : OFL 1.1
  Description : lively casual script with bouncing letters and size changes
   Dancing Script references popular scripts typefaces from the 50's.
   It relates to Murray Hill (Emil Klumpp. 1956) in its weight distribution,
   and to Mistral (Roger Excoffon. 1953) in its lively bouncing effect.
   .
   Use it when you want a friendly, informal and spontaneous look.



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

Bug#664017: ITP: fonts-lobster -- bold condensed script with many ligatures and alternates

[Bernhard Reiter]

Package: wnpp
Severity: wishlist
Owner: Bernhard Reiter ock...@raz.or.at


* Package name: fonts-lobster
  Version : 1.4
  Upstream Author : Pablo Impallari impall...@gmail.com
* URL : http://www.impallari.com/lobster
* License : OFL-1.1
  Description : bold condensed script with many ligatures and alternates
 The beauty of real hand-drawn lettering is that the lettering artists subtly
 modify the shape of letters so they connect with the next ones. These linked
 letters-pairs are called ligatures. Thus, in order to provide a smooth
 hand-written look, the Lobster font provides a large number of ligatures,
 as well as terminal forms (i.e. glyphs that are used for word endings).



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

Bug#661920: linux-image-2.6.32-5-amd64: mounting some CDs lead to Unhandled sense codes which make autodetection fail

[Bernhard Reiter]

Package: linux-2.6
Version: 2.6.32-41
Severity: normal


When using some CDs there are Unhandled sense code messges for
the device. This leads to Plasma's autodetection of the device to fail
and does not display the device.
There is a very good chance the CD can still be mounted manually.

I am opening this report, because in #583949 Ben Hutchings recommend it.
Also because I believe this is related to software somehow and not gone.
It probably will take some effort by the Debian, kernel and Free Software
communities to get a closer grip on this defect.

Any hints towards further analysis are highly appreciated!
Bernhard

Details:
I have two drives available for the testing on an amd machine,
running an amd kernel with 32bit userspace.
One drive is build in, the other is usb.
Both show the symptoms.
If I have a CD that is affected, it will have problems in both drives.
Booting into windows XP, there is no issue.
Running grml96_2011.12.iso from an usb stick there is no
issue, it has linux-image-3.1.0-3-grml-amd64, but has not autodetection anyway.

The symptoms: 
Putting the CD in the drive, it will take some time, more than usual
a few seconds more. Then the syslog shows a number of blocks like:

sr 6:0:0:0: [sr1] Unhandled sense code
sr 6:0:0:0: [sr1] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sr 6:0:0:0: [sr1] Sense Key : Medium Error [current] 
sr 6:0:0:0: [sr1] Add. Sense: L-EC uncorrectable error
sr 6:0:0:0: [sr1] CDB: Read(10): 28 00 00 02 55 a0 00 00 02 00 00 00
end_request: I/O error, dev sr1, sector 611968
Buffer I/O error on device sr1, logical block 76496

sr 6:0:0:0: [sr1] Unhandled sense code
sr 6:0:0:0: [sr1] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sr 6:0:0:0: [sr1] Sense Key : Medium Error [current] 
sr 6:0:0:0: [sr1] Add. Sense: L-EC uncorrectable error
sr 6:0:0:0: [sr1] CDB: Read(10): 28 00 00 02 55 a0 00 00 02 00 00 00
end_request: I/O error, dev sr1, sector 611968
Buffer I/O error on device sr1, logical block 76496

Maybe 3 or more. No device appears in the Plasma gui.
A manual mount /mnt/cdrom usually succeeds.

Expected would be that there are no messages and the device is coming up
(fast) in the gui and can be mounted from there.

Further details: I had problems with burned CDs from both drives.
However it is also possible to burn CDs which are accepted fine 
(which I did today twice).
It is unclear which CDs have this issue.
And it is strange that the data can still be read manually 
and read by windows xp.

I've tried linux-image-3.2.0-0.bpo.1-amd64 
(3.2.4-1~bpo60+1 Debian Backports:squeeze-backports)
which did not help.

Given the number of issues that are related to this,
it seems less likely that I really got unlucky with a number of suboptimal
CD media. Even if so, there still is an issue as windows XP and
manual mount read the CD fine.

Infos about the two drives:
cdrdao drive-info --device /dev/sr0
Cdrdao version 1.2.3 - (C) Andreas Mueller andr...@daneb.de
/dev/sr0: TSSTcorp CDDVDW SH-S203D  Rev: SB00
Using driver: Generic SCSI-3/MMC - Version 2.0 (options 0x)

Maximum reading speed: 8468 kB/s
Current reading speed: 8468 kB/s
Maximum writing speed: 8468 kB/s
Current writing speed: 8468 kB/s
BurnProof supported: yes
JustLink supported: yes
JustSpeed supported: no


cdrdao drive-info --device /dev/sr1
Cdrdao version 1.2.3 - (C) Andreas Mueller andr...@daneb.de
/dev/sr1: TSSTcorp CDDVDW SE-S204N  Rev: TS00
Using driver: Generic SCSI-3/MMC - Version 2.0 (options 0x)

Maximum reading speed: 8468 kB/s
Current reading speed: 8468 kB/s
Maximum writing speed: 8468 kB/s
Current writing speed: 8468 kB/s
BurnProof supported: yes
JustLink supported: yes
JustSpeed supported: no


Here are related issue reports:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583949
2.6.32-3-amd64 can't read DVDs/CDs (sometimes)
  From: Ben Hutchings b...@decadent.org.uk

  If anyone is still having trouble reading CDs or DVDs in the current
kernel version in stable (2.6.32-35) or unstable (3.0.0-1), please open
a *new* bug report.

There is a new one:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641288
   (linux-image-2.6.32-5-686: Can not read appendable cdroms/dvds)
Though it is unsure if this is the same issue as appendable CDs are
addressed in particular.

http://forum.kde.org/viewtopic.php?f=19t=91402#
  CD Dvd drive not working in KDE 4.5.x
The solution here seems to have been to disable some sort of autodetection.

http://www.linuxquestions.org/questions/slackware-14/slackware64-current-doesnt-read-cd-r-disks-as-well-as-slack-12-1-does-801015/

http://www.linuxquestions.org/questions/slackware-14/cd-mounting-errors-iso9660-812240/page3.html

http://www.linuxquestions.org/questions/slackware-14/slack-13-1-does-not-recognize-mounted-cd-810509/


-- Package-specific info:
** Version:
Linux version 2.6.32-5-amd64 (Debian 2.6.32-41) (b...@decadent.org.uk) (gcc 
version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Mon Jan 16 17:15:00 UTC 2012

** Command line:

Bug#661346: ocrfeeder: Please remove python-gnome2 dependency

[Bernhard Reiter]

Package: ocrfeeder
Version: 0.7.5-1
Severity: minor

According to ocrfeeder's NEWS, the libgnome dependency was removed in version
0.7.7, so it should run without the python-gnome2 dependency.



-- System Information:
Debian Release: wheezy/sid
  APT prefers oneiric-updates
  APT policy: (500, 'oneiric-updates'), (500, 'oneiric-security'), (500, 
'oneiric-proposed'), (500, 'oneiric')
Architecture: amd64 (x86_64)

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

Versions of packages ocrfeeder depends on:
ii  cuneiform  1.1.0+dfsg-1  multi-language OCR system
ii  ghostscript9.04~dfsg-0ubuntu11.5 interpreter for the PostScript lan
ii  ocrad  0.21-2Optical character recognition prog
ii  python 2.7.2-7ubuntu2interactive high-level object-orie
ii  python-enchant 1.6.5-2   spellchecking library for Python
ii  python-gnome2  2.28.1-3  Python bindings for the GNOME desk
ii  python-gtk22.24.0-2  Python bindings for the GTK+ widge
ii  python-gtkspell2.25.3-7ubuntu3   Python bindings for the GtkSpell l
ii  python-imaging-san 1.1.7-3ubuntu1Python Imaging Library - SANE inte
ii  python-pygoocanvas 0.14.1-1ubuntu5   GooCanvas Python bindings
ii  python-support 1.0.13ubuntu1 automated rebuilding support for P

Versions of packages ocrfeeder recommends:
ii  unpaper   0.3-1ubuntu1   post-processing tool for scanned p
ii  yelp  3.2.0-0ubuntu1 Help browser for GNOME

ocrfeeder suggests no packages.

-- no debconf information



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

Bug#661410: svn-buildpackage: Please add a --version option

[Bernhard Reiter]

Package: svn-buildpackage
Version: 0.8.3
Severity: wishlist

Please add a --version command line option to the svn-buildpackage command that
displays, unsurprisingly, its current version.



-- System Information:
Debian Release: wheezy/sid
  APT prefers oneiric-updates
  APT policy: (500, 'oneiric-updates'), (500, 'oneiric-security'), (500,
'oneiric-proposed'), (500, 'oneiric')
Architecture: amd64 (x86_64)

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

Versions of packages svn-buildpackage depends on:
ii  devscripts 2.11.1ubuntu3.1   scripts to make the life of a Debi
ii  file   5.04-5ubuntu3 Determines file type using magic
ii  libcapture-tiny-pe 0.10-1module to capture STDOUT and STDER
ii  libfile-libmagic-p 0.96-1build1  Perl interface to libmagic for det
ii  liblocale-gettext- 1.05-6build1  Using libc functions for internati
ii  libsvn-perl1.6.12dfsg-4ubuntu5.1 Perl bindings for Subversion
ii  liburi-perl1.58-1module to manipulate and access UR
ii  perl   5.12.4-4  Larry Wall's Practical Extraction
ii  subversion 1.6.12dfsg-4ubuntu5.1 Advanced version control system
ii  unp2.0~pre7  unpack (almost) everything with on
ii  wget   1.12-3.1ubuntu1   retrieves files from the web

Versions of packages svn-buildpackage recommends:
ii  debhelper   8.9.0ubuntu1 helper programs for debian/rules

svn-buildpackage suggests no packages.



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

Bug#579401: [Fwd: Re: [Fwd: Please state pyopenfst copyright/license clearly!]]

[Bernhard Reiter]

I found different email addresses for both committers and forwarded my
message to those addresses. I'm forwarding David Huggins-Daines' reply
here:

 Forwarded message 
 Hi!  Thomas Breuel wrote the original code for the most part.  I don't
 recall if I added the Apache copyright notices to my parts of the code
 and can't look at the moment.  If not I certainly give permission to
 do so.
 
 2012/2/24 Bernhard Reiter ock...@raz.or.at
  Weitergeleitete Nachricht 
  Von: Bernhard Reiter ock...@raz.or.at
  An: Thomas Breuel tmb...@gmail.com, David Huggins-Daines
  dhd...@gmail.com
  Kopie: 579...@bugs.debian.org
  Betreff: Please state pyopenfst copyright/license clearly!
  Datum: Wed, 15 Feb 2012 20:31:30 +0100
 
  Hi,
 
  and thank you for your work on pyopenfst!
 
  Debian maintainers and contributors would really like to
 package
  pyopenfst for Debian, but unfortunately, there doesn't seem
 enough
  copyright and license information available to fulfil Debian
  guidelines.
 
  pyopenfst's project homepage on Google Code states that the
 code is
  licensed under the Apache License 2.0, and we've found your
 email
  addresses in the list of committers, but please help us by
 stating
  copyright and license information clearly by adding a note
 to the code.
 
  There's an appendix to the Apache License 2.0 on how to do
 it:
  http://www.apache.org/licenses/LICENSE-2.0#apply
 
  Also see
 http://code.google.com/p/pyopenfst/issues/detail?id=6
  and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579401
 
  Kind regards
  Bernhard Reiter
 
 
 





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

Bug#660797: lintian: Warning for .thumbnails directories in packages

[Bernhard Reiter]

Package: lintian
Version: 2.5.3ubuntu2
Severity: wishlist

Lintian should warn for .thumbnails directories in packages, like it does for
..xvpics (package-contains-xvpics-dir) or Windows Thumbs.db[.gz] files (windows-
thumbnail-database-in-package).



-- System Information:
Debian Release: wheezy/sid
  APT prefers oneiric-updates
  APT policy: (500, 'oneiric-updates'), (500, 'oneiric-security'), (500, 
'oneiric-proposed'), (500, 'oneiric')
Architecture: amd64 (x86_64)

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

Versions of packages lintian depends on:
ii  binutils 2.21.53.20110810-0ubuntu5.1 The GNU assembler, linker and bina
ii  bzip21.0.5-6ubuntu1.11.10.1  high-quality block-sorting file co
ii  diffstat 1.54-1  produces graph of changes introduc
ii  file 5.04-5ubuntu3   Determines file type using magic
ii  gettext  0.18.1.1-3ubuntu1   GNU Internationalization utilities
ii  intltool-deb 0.35.0+20060710.1   Help i18n of RFC822 compliant conf
ii  libapt-pkg-p 0.1.24build3Perl interface to libapt-pkg
ii  libclass-acc 0.34-1  Perl module that automatically gen
ii  libdpkg-perl 1.16.0.3ubuntu5 Dpkg perl modules
ii  libemail-val 0.184-1 Perl module for checking the valid
ii  libipc-run-p 0.90-1  Perl module for running processes
ii  libparse-deb 1.2.0-1ubuntu1  parse Debian changelogs and output
ii  libtimedate- 1.2000-1collection of modules to manipulat
ii  liburi-perl  1.58-1  module to manipulate and access UR
ii  locales  2.13+git20110622-2  common files for locale support
ii  man-db   2.6.0.2-2   on-line manual pager
ii  patchutils   0.3.2-1 Utilities to work with patches
ii  perl [libdig 5.12.4-4Larry Wall's Practical Extraction 
ii  unzip6.0-4ubuntu1De-archiver for .zip files

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch   none  (no description available)
ii  dpkg-dev 1.16.0.3ubuntu5 Debian package development tools
ii  libhtml-parser-perl  3.68-1build1collection of modules that parse H
pn  libtext-template-perlnone  (no description available)
ii  man-db   2.6.0.2-2   on-line manual pager
ii  xz-utils 5.0.0-2 XZ-format compression utilities

-- no debconf information



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

Bug#579401: Please state pyopenfst copyright/license clearly!

[Bernhard Reiter]

Hi,

and thank you for your work on pyopenfst!

Debian maintainers and contributors would really like to package
pyopenfst for Debian, but unfortunately, there doesn't seem enough
copyright and license information available to fulfil Debian
guidelines. 

pyopenfst's project homepage on Google Code states that the code is
licensed under the Apache License 2.0, and we've found your email
addresses in the list of committers, but please help us by stating
copyright and license information clearly by adding a note to the code. 

There's an appendix to the Apache License 2.0 on how to do it:
http://www.apache.org/licenses/LICENSE-2.0#apply

Also see http://code.google.com/p/pyopenfst/issues/detail?id=6
and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579401 

Kind regards
Bernhard Reiter




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

Bug#633721: Provide a package containing only free profiles

[Bernhard Reiter]

I've noticed that Ubuntu already has factored out free ICC profiles from
icc-profiles into a icc-profiles-free package [1]; the version of its
non-free icc-profiles package [2] is thus now 2.0+nondfsg-0ubuntu1. This
is quite similar to what is requested here, only that Ubuntu's binary
icc-profiles-free has a source packages of its own -- presumably so it
is completely dfsg-compliant.

I have thus modified Ubuntu's icc-profiles-free package to suit Debian,
fixed 3 Lintian warnings, and uploaded it to mentors.debian.net [3]. I
have done the same to Ubuntu's icc-profiles package [4].

Any comments welcome! I'd of course be happy to see my packages uploaded
to Debian!

Kind regards
Bernhard Reiter

[1] https://launchpad.net/ubuntu/+source/icc-profiles-free
[2] https://launchpad.net/ubuntu/+source/icc-profiles
[4] http://mentors.debian.net/package/icc-profiles-free
[5] http://mentors.debian.net/package/icc-profiles




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

Bug#651402: iulib: FTBFS: Checking for inflate() in C library tiff... no

[Bernhard Reiter]

Upstream's bugtracker seems to have a fix:

http://code.google.com/p/iulib/issues/detail?id=27#c2




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

Bug#599045: tesseract-ocr: new upstream version (3.00)

[Bernhard Reiter]

Is the current state of the package source available online (e.g. in
some DVCS repository)? That might faciliate keeping track of its
progress for interested parties (and possibly contributing to it; and
whether the current upstream source finally works).




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

Bug#656181: aspell: umlaut keyboard input in utf8 locale is broken

[Bernhard Reiter]

Package: aspell
Version: 0.60.6-4
Severity: normal


During an interactive check, if a word needs to be entered manually,
aspell does not accept umlauts in a UTF8 locale.
They appear as an empty character when typed on the keyboard.

How to reproduce:
On a utf8 terminal.
  echo doesnotexit  text.txt
  LANG=de_DE.UTF-8 aspell check text.txt
press for replace
  r
type or paste in a word with an umlaut, e.g.
  Tür

Observation: aspell will display T r and also replace the word with it.
Expectaton: aspell should display and replace Tür.

Additional information: when using aspell on a latin1 locale and setting,
e.g. LANG=de_DE@euro, the behaviour is correct.

Best Regards,
Bernhard

-- System Information:
Debian Release: 6.0.3
  APT prefers stable
  APT policy: (550, 'stable')
Architecture: i386 (x86_64)

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

Versions of packages aspell depends on:
ii  dictionaries-common   1.5.17 Common utilities for spelling dict
ii  libaspell15   0.60.6-4   GNU Aspell spell-checker runtime l
ii  libc6 2.11.2-10  Embedded GNU C Library: Shared lib
ii  libgcc1   1:4.4.5-8  GCC support library
ii  libncursesw5  5.7+20100313-5 shared libraries for terminal hand
ii  libstdc++64.4.5-8The GNU Standard C++ Library v3

Versions of packages aspell recommends:
ii  aspell-de [aspell-dictionar 20091006-4.2 German dictionary for aspell
ii  aspell-en [aspell-dictionar 6.0-0-6  English dictionary for GNU Aspell

Versions of packages aspell suggests:
pn  aspell-docnone (no description available)
pn  spellutilsnone (no description available)

-- no debconf information



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

Bug#585228: gourmet: Python string exceptions no more allowed in Python 2.6

[Bernhard Reiter]

close 585228
thanks

This seems to be have been fixed since about 0.15.5, and certainly is in
0.15.9-1.




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

Bug#409048: ITP: pysolfc -- A Python solitaire game collection

[Bernhard Reiter]

I've just uploaded a preliminary package of version 2.9.1 (for Ubuntu 11.04 
natty) to my Launchpad PPA at 
https://launchpad.net/~ockham-razor/+archive/ppa/
I hope to submit an official version to Debian some time soon.




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

Bug#519752: ITP: pysolfc -- A Python solitaire game collection

[Bernhard Reiter]

retitle 519752 ITP: pysolfc -- A Python solitaire game collection
owner 519752 !




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

Bug#519752: ITP: pysolfc -- A Python solitaire game collection

[Bernhard Reiter]

I've uploaded a package version to mentors and am now looking for a
sponsor; see http://mentors.debian.net/package/pysolfc
( and related pysol* packages via
http://mentors.debian.net/packages/uploader/ockham%40raz.or.at ).




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

Bug#640930: criticalmass: crash radeon_mipmap_tree.c:420: migrate_image_to_miptree: Assertion `mt-mesaFormat == image-base.TexFormat' failed.

[Bernhard Reiter]

Package: criticalmass
Version: 1:1.0.0-1.4
Severity: important


When trying to start criticalmass with this radeon driver
it will crash with the following message:

radeon_mipmap_tree.c:420: migrate_image_to_miptree: Assertion `mt-mesaFormat 
== image-base.TexFormat' failed.
Best is to call it like this
  criticalmass +fullscreen 0
 

There is a similar report to ubuntu 
https://bugs.launchpad.net/ubuntu/+source/criticalmass/+bug/613995
As 3d acceleration works otherwise, maybe this is a defect in criticalmass 
itself.
But it could be the combination of radeon card, mesa and criticalmass.
lspci  | grep VGA
01:00.0 VGA compatible controller: ATI Technologies Inc RV630 [Radeon HD 2600XT]

I consider it important because it will not work for a number 
users with such cards. Also when called in fullscreen mode it will fall back
to the Xserver with a change low resolution. The fullscreen mode is the default,
so users just trying out this game will be left by a screwed screen 
which is a bad experience.

-- System Information:
Debian Release: 6.0.2
Architecture: i386 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)

Versions of packages criticalmass depends on:
ii  criticalmass-data  1:1.0.0-1.4   Shoot-em-up a la galaxian (data fi
ii  libc6  2.11.2-10 Embedded GNU C Library: Shared lib
ii  libgcc11:4.4.5-8 GCC support library
ii  libgl1-mesa-glx [libgl 7.7.1-4   A free implementation of the OpenG
ii  libpng12-0 1.2.44-1+squeeze1 PNG library - runtime
ii  libsdl-image1.21.2.10-2+b2   image loading library for Simple D
ii  libsdl-mixer1.21.2.8-6.3 mixer library for Simple DirectMed
ii  libsdl1.2debian1.2.14-6.1Simple DirectMedia Layer
ii  libstdc++6 4.4.5-8   The GNU Standard C++ Library v3
ii  zlib1g 1:1.2.3.4.dfsg-3  compression library - runtime

criticalmass recommends no packages.

criticalmass suggests no packages.

-- no debconf information



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

Bug#614535: Fixed in 0.5.3-1?

[Bernhard Reiter]

Hi,

I've only noticed this bug report after packaging version 0.5.3-1, which
is now in sid and wheezy. Can you check if the issue persists? If it's
fixed, please close this bug report.

Kind regards
Bernhard Reiter




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

Bug#614535: Fixed in 0.5.3-1?

[Bernhard Reiter]

Thanks Jakub for the update.

I'm having a bit of a hard time figuring this out as it built just fine
with my local sid pbuilder.

At first I thought it was due to some http POST actions going on that
maybe are disabled on the archive rebuild system, but then again, the
issue seems to apply only to the FreeComment tests, not the comment
ones. 

Any clue what's going on here or at least how I can reproduce the error
locally?

Regards
Bernhard




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

Bug#614535: Fixed in 0.5.3-1?

[Bernhard Reiter]

Alright, that was my other theory. I just didn't really expect this thing to 
check the website a comment author entered.

So what would you suggest to cure this? Just pass 127.0.0.1 as website? 

Regards
Bernhard





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

Bug#627373: dirmngr socket should be accessible to all regular users on the system

[Bernhard Reiter]

Package: dirmngr
Version: 1.1.0-1
Severity: important


The permissions in /etc/default/dirmngr for the socket is wrong.

As Werner Koch, upstream author declares in
http://lists.gnupg.org/pipermail/gnupg-devel/2011-January/025880.html :
  Permission for the socket should be given to all regular users 
  on the system. 

  This is in particular important for the forthcoming 
  2.1 GnuPG where dirmngr will also be used to access pgp keyservers.

but of course it is already important for S/MIME usage in dirmngr
versions 1.0.3-1 and 1.1.0-1. The severity is important, because
users will not be able to use dirmngr which will result in S/MIME problems
which they cannot directly understand. So it affect the overall usage
of the package.

Also see http://lists.gnupg.org/pipermail/gnupg-devel/2011-January/025876.html
for some more details and the workaround for admins. Just change
 DIRMNGR_SOCKET_MODE=0770
to
 DIRMNGR_SOCKET_MODE=0777
in /etc/default/dirmngr

Thanks,
Bernhard



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

Bug#627377: dirmngr: special requests can make dirmngr hang, can be denial of service for email signatures

[Bernhard Reiter]

Package: dirmngr
Version: 1.1.0-1
Severity: important
Tags: patch, security

At least dirmngr 1.1.0-1 has a defect that it can hang.
This can cause a denial of service for other users and applications,
as dirmngr is a system service serving several requests.

For example the KMail hung when trying to verify a signature
which has the certificate in the chain that is attached to the 
report which has all details:

https://bugs.g10code.com/gnupg/issue1313
(dirmngr unresponsive when waiting for some http CRL connect() - ping and 
other requests fail)

here is the patch rev 347 that fixes the issue:
http://cvs.gnupg.org/cgi-bin/viewcvs.cgi?root=Dirmngrview=rev


http://files.kolab.org/apt/releases/dists/lenny/unstable/source/
has the following files that already contain a fixed package
for Lenny:

dirmngr_1.1.0+r347-0kk1.diff.gz  19-May-2011 10:59
dirmngr_1.1.0+r347-0kk1.dsc  19-May-2011 10:59  
dirmngr_1.1.0+r347.orig.tar.gz

Best,
Bernhard 



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

Bug#601811: ITP: python-solrpy

[Bernhard Reiter]

Package: wnpp
Severity: wishlist
Owner: Bernhard Reiter ock...@raz.or.at

  Package name: python-solrpy
  Version : 0.9.3
  Upstream Author : Fred L. Drake, Jr.
  URL : http://pypi.python.org/pypi/solrpy/
  License : Apache License, Version 2.0
  Programming Lang: Python
  Description : Python client for Solr

python-solrpy is a Python client for Solr, an enterprise search server
built on top of Lucene. python-solrpy allows you to add documents to a
Solr instance, and then to perform queries and gather search results
from Solr using Python. 









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

Bug#600924: ITP: python-repoze.sphinx.autointerface -- Sphinx extension that auto-generates API docs from Zope interfaces

[Bernhard Reiter]

Package: wnpp
Severity: wishlist
Owner: Bernhard Reiter ock...@raz.or.at

  Package name: python-repoze.sphinx.autointerface
  Version : 0.4
  Upstream Author : Agendaless Consulting repoze-...@lists.repoze.org
  URL : http://pypi.python.org/pypi/repoze.sphinx.autointerface/
  License : BSD-derived (http://www.repoze.org/LICENSE.txt)
  Programming Lang: Python
  Description : Sphinx extension that auto-generates API docs from Zope 
interfaces

This package defines an extension for the Sphinx documentation system.
The extension allows generation of API documentation by introspection of
zope.interface instances in code.




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

Bug#599304: ITP: adhocracy -- community decision-making web platform

[Bernhard Reiter]

Package: wnpp
Severity: wishlist
Owner: Bernhard Reiter ock...@raz.or.at

  Package name: adhocracy
  Version : 1.0+svn1254
  Upstream Author : Liquid Democracy e.V. i...@liqd.net
  URL : http://wiki.liqd.net/Adhocracy
  License : AGPL-3
  Programming Lang: Python
  Description : community decision-making web platform

Adhocracy is a Liquid Democracy software. 
Liquid Democracy is not only a conceivable form of government, but also as a
new form of cooperative management. Organizations like NGOs, online
initiatives and companies can use this system to develop their democratic
process, their goals, strategies, internal rules, or positions. Adhocracy is a
practical implementation of theories regarding direct parlamentarianism.







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

Bug#519752: Please upload pysolfc to debian

[Bernhard Reiter]

Am Sonntag, den 12.09.2010, 03:38 -0400 schrieb Ariel:
 Send an email to debian-ment...@lists.debian.org - or subscribe first: 
 http://lists.debian.org/debian-mentors/
 [...]

Thx, I've already prepared that mail.

  When you do, be sure to also add a transitional package called pysol which
  depends on the new one, to give a good upgrade path.
 
 You create an empty package, containing just the control file.
 [...]

One problem, I added 

Replaces: pysol
Conflicts: pysol, pysol-cardsets

fields to pysolfc, which would somehow collide with that transitional
pysol. I've tentatively added ( 2.0-1~) to those field entries, but
unfortunately, latest pysol versions were higher (e.g. 4.40-3) than
current pysolfc (which would be 2.0-1). How do I proceed?

Thanks for your help, it's very much appreciated!

Bernhard





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

Bug#519752: Please upload pysolfc to debian

[Bernhard Reiter]

Am Donnerstag, den 16.09.2010, 19:11 -0400 schrieb Ariel:
 1:
 [...]
 And include an empty, separate, package for pysol. (i.e. pysol should not 
 be part of the same source as pysolfc).

But then I also need changelog, rules etc. files, right?

 (Note the extra packages I added to the conflicts.)
Added.

Bernhard




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