Bug#1026772: libsane: The size of the libsane_1.0.31-4.1_amd64.deb package is only about 46 kB whereas the libsane_1.0.27-3.2_amd64.deb package has a size of 2,1 MB.

[Aleksey]

Package: libsane
Version: 1.0.31-4.1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: 15151...@mail.ru

Dear Maintainer,

The size of the libsane_1.0.31-4.1_amd64.deb package is only about 46 kB 
whereas the libsane_1.0.27-3.2_amd64.deb package has a size of 2,1 MB. It looks 
like some files were lost during packaging.
It looks like the /lib/udev and /usr/lib branches were completely lost. Only 
the /usr/share/doc/libsane branch remains.

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

Kernel: Linux 5.10.0-18-amd64 (SMP w/12 CPU threads)

Bug#1026097: lua-curl: there are no OPT_* constants in the module

[Aleksey]

Package: lua-curl
Version: 0.3.0-10
Severity: grave
Justification: renders package unusable

Dear Maintainer,

After I updated from version 0.3.0-9.2, any call to the setopt function
began to fail with the error "Expecting a CURLoption value, got nil".
A little investigation showed that the module is missing any OPT_*
constants. Perhaps, not only these. For instance, in this code:

print(require("curl").OPT_URL)

I expect to get 10002, but get nil. Replacing the constants with their
numeric values doen't solve the problem either. Rollback to version
0.3.0-9.2 solves the problem.

I dug a little deeper into the package sources and I think that the
package was built with an empty curopt.h, which is mentioned here:
https://sources.debian.org/src/lua-curl/0.3.0-10/lua-curl.c/#L148

Regards, Aleksey A.

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages lua-curl depends on:
ii  libc62.36-6
ii  libcurl3-gnutls  7.86.0-2

lua-curl recommends no packages.

lua-curl suggests no packages.

-- no debconf information

Bug#1019447: [Aptitude-devel] Bug#1019447: aptitude: Wrong "Press Return to continue" after succesful installation

[Aleksey Midenkov]

Axel,

On Sat, Sep 10, 2022 at 1:42 AM Axel Beckert  wrote:
>
> Control: severity -1 wishlist
> Control: tag -1 + confirmed
>
> Hi Aleksey,
>
> Aleksey Midenkov wrote:
> > > Aleksey Midenkov wrote:
> > > > Since some version aptitude started to behave strangely: it asks user
> > > > interaction after each successful installation.
> > >
> > > I thought that the "Press Return to continue" was always there, just
> > > the "'q' followed by Return to quit" has been added as a feature
> > > somewhen 7 or 8 years ago. But now I'm no more sure if that "Press
> > > Return to continue" was really there before.
> >
> > No, it was not always there. I've been using aptitude for 20 years or
> > so.
>
> Me too, after I discovered that its so much better than dselect. (And
> yes, I initially also was just a user. :-)

Right.

>
> (And JFTR: As of now I'm mostly the packager of aptitude, not its
> "upstream" developer, mostly due to lacking C++ experience.)
>
> > When it started to be nagging it really freaked me out, but had no
> > time nor will to fix until now.
>
> I can relate. UI changes can be very annoying for some people while
> other won't even barely notice that something has changed. E.g. UI
> changes is what drove me away from GNOME many years ago. But which
> change actually annoys someone seems to be a very subjective thing.

Agree. I believe the subjectiveness comes from the amount and variety
of UI experience.

>
> > > > So no obvious reason to use 'q' from the above interaction because 'q'
> > > > also works from the UI.
> > >
> > > No, the reason is that you don't have to wait to reload the database
> > > before being able to press "q" again.
> >
> > But it returns to UI first and hence reloads the database, so you have
> > to wait in any case. Haven't you?
>
> I remember that I once mentioned that I used to press just Ctrl-C
> there. And someone of the aptitude developers back then said that's a
> bad habit because aptitude then can't save back some details.
>
> So as far as I understand there is some database saving part happening
> during that time where it goes back to the TUI to properly quit. And
> it is said to be needed to avoid the loss of some package states in
> aptitude's pkgstate database.
>
> > > > I guess the above pause was added to display
> > > > the errors if any happened
> > >
> > > There is no pause in that sense. The time the UI is displayed is AFAIK
> > > needed to properly write down the current state of aptitude's package
> > > list after the package installation.
> >
> > Pause means do nothing and wait for user interaction. The delay caused
> > by UI reload is not the "pause", is it?
>
> Ok, I might have misunderstood which pause you meant. I initially
> thought that you referred to the waiting time while consolidating and
> writing the database back on disk as "pause".
>
> But now I think you refer to aptitude sitting there and waiting for
> the user to press (at least) Enter as "pause". There it is indeed a
> pause.
>
> > > > I hope you will find the below patch well-suited for stopping
> > > > bugging you with that useless pause.
> > > >
> > > > --- b/src/ui.cc 2020-05-21 06:32:38.0 +0300
> > > > +++ b/src/ui.cc 2022-09-09 13:41:49.752101187 +0300
> > > > @@ -1276,7 +1276,7 @@
> > > >  pkgPackageManager::OrderResult rval = f(-1);
> > > >
> > > >  bool quit_after_dpkg_run = false;
> > > > -if(rval != pkgPackageManager::Incomplete)
> > > > +if(rval != pkgPackageManager::Completed)
> > > >{
> > > >   cout << _("Press Return to continue, 'q' followed by Return to
> > > > quit.") << endl;
> > >
> > > Doesn't make sense to me. But maybe I also still haven't understood
> > > what you're actually trying to achieve.
> >
> > Why it doesn't make sense?
>
> For me it doesn't make sense to show the prompt if something (whatever
> it is) is not completed. It is though unclear to me what is the exact
> semantic of Incomplete and Complete in this case.

If you don't understand the semantics then it doesn't make sense for
sure... But in that case this fact doesn't make sense itself.:)

>
> > When error happens it pauses and shows the reply.
>
> I see. And indeed, I actually prefer to always be able to have a look
> at the console output before returning 

Bug#1019447: [Aptitude-devel] Bug#1019447: aptitude: Wrong "Press Return to continue" after succesful installation

[Aleksey Midenkov]

Hi Axel,

On Fri, Sep 9, 2022 at 8:58 PM Axel Beckert  wrote:
>
> Control: tag -1 + moreinfo
>
> Hi Aleksey,
>
> thanks for the bug report.
>
> Aleksey Midenkov wrote:
> > Since some version aptitude started to behave strangely: it asks user
> > interaction after each successful installation.
>
> I thought that the "Press Return to continue" was always there, just
> the "'q' followed by Return to quit" has been added as a feature
> somewhen 7 or 8 years ago. But now I'm no more sure if that "Press
> Return to continue" was really there before.

No, it was not always there. I've been using aptitude for 20 years or
so. When it started to be nagging it really freaked me out, but had no
time nor will to fix until now.

>
> What definitely has been added around that time (in 0.7.3 from October
> 2015) was this "Perfoming actions" line when switching from TUI to
> installation output. (https://bugs.debian.org/323371)
>
> > Press Return to continue, 'q' followed by Return to quit.
> >
> > That is strange because 'q' returns first into the UI and then
> > quits.
>
> This is correct and is intended.
>
> > So no obvious reason to use 'q' from the above interaction because 'q'
> > also works from the UI.
>
> No, the reason is that you don't have to wait to reload the database
> before being able to press "q" again.

But it returns to UI first and hence reloads the database, so you have
to wait in any case. Haven't you?

>
> > I guess the above pause was added to display
> > the errors if any happened
>
> There is no pause in that sense. The time the UI is displayed is AFAIK
> needed to properly write down the current state of aptitude's package
> list after the package installation.

Pause means do nothing and wait for user interaction. The delay caused
by UI reload is not the "pause", is it?

>
> > but the condition in the code for that was chosen wrongly.
>
> The only thing I remember from discussions back then is that querying
> for a "q" keypress without the following "Enter" press was much more
> work than worth it and would have required a rewrite of the whole
> input handling at that point in the workflow.
>
> > I hope you will find the below patch well-suited for stopping
> > bugging you with that useless pause.
> >
> > --- b/src/ui.cc 2020-05-21 06:32:38.0 +0300
> > +++ b/src/ui.cc 2022-09-09 13:41:49.752101187 +0300
> > @@ -1276,7 +1276,7 @@
> >  pkgPackageManager::OrderResult rval = f(-1);
> >
> >  bool quit_after_dpkg_run = false;
> > -if(rval != pkgPackageManager::Incomplete)
> > +if(rval != pkgPackageManager::Completed)
> >{
> >   cout << _("Press Return to continue, 'q' followed by Return to
> > quit.") << endl;
>
> Doesn't make sense to me. But maybe I also still haven't understood
> what you're actually trying to achieve.

Why it doesn't make sense? When error happens it pauses and shows the reply.

>
> What exactly do you expect aptitude to do when the package
> installation/update/removal run ended?

Return to UI without any interaction. Again, that is stupid: when you
run some lengthy installation you go away from display and when you
return back it asks for Enter then it forces you to wait until UI is
reloaded. That interaction didn't help me in any single case.

>
> Regards, Axel
> --
>  ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
> : :' :  |  Debian Developer, ftp.ch.debian.org Admin
> `. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
>   `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE



-- 
@midenok

Bug#1003186:

[Aleksey Midenkov]

Also please note #1019447

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019447

-- 
@midenok

Bug#1019447: aptitude: Wrong "Press Return to continue" after succesful installation

[Aleksey Midenkov]

Package: aptitude
Version: 0.8.13-3
Severity: normal
Tags: patch

Since some version aptitude started to behave strangely: it asks user
interaction after each successful installation.

Press Return to continue, 'q' followed by Return to quit.

That is strange because 'q' returns first into the UI and then quits.
So no obvious reason to use 'q' from the above interaction because 'q'
also works from the UI. I guess the above pause was added to display
the errors if any happened but the condition in the code for that was
chosen wrongly. I hope you will find the below patch well-suited for
stopping bugging you with that useless pause.

--- b/src/ui.cc 2020-05-21 06:32:38.0 +0300
+++ b/src/ui.cc 2022-09-09 13:41:49.752101187 +0300
@@ -1276,7 +1276,7 @@
 pkgPackageManager::OrderResult rval = f(-1);

 bool quit_after_dpkg_run = false;
-if(rval != pkgPackageManager::Incomplete)
+if(rval != pkgPackageManager::Completed)
   {
  cout << _("Press Return to continue, 'q' followed by Return to
quit.") << endl;

-- 
@midenok

Bug#993487: libguestfs-tools: virt-sparsify fails to pass necessary arguments to qemu-img

[Aleksey I. Zavilohin]

Confirm this problem with qemu 6.1

https://wiki.qemu.org/ChangeLog/6.1

Section: Incompatible changes

When creating an image with a backing file, or changing the backing file 
of an existing image, qemu-img requires now that the backing file format 
is specified as well.


with qemu 6.0 works fine

--
Aleksey I. Zavilohin
+7-9028968180

Bug#987746: unblock: rhash/1.4.1-2

[Aleksey Kravchenko]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-CC: debian-security-to...@lists.debian.org

Hello Release Team,

please unblock rhash 1.4.1-2

The rhash/1.4.1-1 package introduced bug #987698:
'rhash --version' incorrectly outputs 'v1.4.0' instead of 'v1.4.1'.

The patch is minimal, debdiff is attached.

The fix can be easily tested:

$ rhash --version
RHash v1.4.1

No librhash interfaces were touched, so dependent packages will work
without a rebuild.

  Kind regards,
  Aleksey
diff -Nru rhash-1.4.1/debian/changelog rhash-1.4.1/debian/changelog
--- rhash-1.4.1/debian/changelog2021-01-08 05:03:33.0 +0300
+++ rhash-1.4.1/debian/changelog2021-03-25 02:26:02.0 +0300
@@ -1,3 +1,9 @@
+rhash (1.4.1-2) unstable; urgency=medium
+
+  * d/patches/0001-v1.4.1.patch fix incorrectly reported version
+
+ -- Aleksey Kravchenko   Thu, 25 Mar 2021 02:26:02 +0300
+
 rhash (1.4.1-1) unstable; urgency=medium
 
   * New upstream version 1.4.1
diff -Nru rhash-1.4.1/debian/patches/0001-v1.4.1.patch 
rhash-1.4.1/debian/patches/0001-v1.4.1.patch
--- rhash-1.4.1/debian/patches/0001-v1.4.1.patch1970-01-01 
03:00:00.0 +0300
+++ rhash-1.4.1/debian/patches/0001-v1.4.1.patch2021-03-25 
02:26:02.0 +0300
@@ -0,0 +1,14 @@
+Description: Fix the program version reported by `rhash --version`
+Origin: upstream, 
https://github.com/rhash/RHash/commit/eb9bc3ff3f4b2003c9441f43f5cd930a8d211ceb
+Last-Update: 2021-03-25
+Forwarded: not-needed
+
+diff --git a/version.h b/version.h
+--- a/version.h
 b/version.h
+@@ -1 +1 @@
+-#define VERSION "1.4.0"
++#define VERSION "1.4.1"
+-- 
+2.31.0
+
diff -Nru rhash-1.4.1/debian/patches/series rhash-1.4.1/debian/patches/series
--- rhash-1.4.1/debian/patches/series   1970-01-01 03:00:00.0 +0300
+++ rhash-1.4.1/debian/patches/series   2021-03-25 02:26:02.0 +0300
@@ -0,0 +1 @@
+0001-v1.4.1.patch


OpenPGP_signature
Description: OpenPGP digital signature

Bug#987698: rhash --version outputs wrong version

[Aleksey Kravchenko]

Package: rhash
Version: 1.4.1-1
Severity: normal
Control: tag -1 fixed-upstream
Control: fixed -1 1.4.1-2

RHash from the 1.4.1-1 deb package outputs wrong version 'v1.4.0'
instead of expected 'v1.4.1'.

Commands to reproduce:

$ rhash --version
RHash v1.4.0


Upstream git has commit [1], which bumps RHash version and fixes this bug.
The commit mistakenly has not been included into upstream release tarball.


[1]
https://github.com/rhash/RHash/commit/eb9bc3ff3f4b2003c9441f43f5cd930a8d211ceb



-- System Information:
Debian Release: 11.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages rhash depends on:
ii  libc6  2.31-11
ii  librhash0  1.4.1-2

Versions of packages rhash recommends:
ii  libssl1.1  1.1.1k-1

rhash suggests no packages.

-- no debconf information




OpenPGP_signature
Description: OpenPGP digital signature

Bug#901962: CVE-2018-12096, CVE-2018-12097, CVE-2018-12098 were fixed in liblnk_20180626-1

[Aleksey Kravchenko]

Hello,

All three CVE were fixed by the upstream version liblnk-20180626 and
packaged by Debian as liblnk_20180626-1.
All subsequent liblnk packages contain the fixes.

===
More details.

As pointed by [1] CVE-2018-12096 is actually bug in the upstream project
libuna.
Upstream and Debian distribute libuna as part of the liblnk package.

CVE-2018-12096 is fixed by commits [2] and [3] (adding check into
libuna/libuna_utf8_string.c).

The fix was included into upstream liblnk version 20180626 and into the
Debian package liblnk_20180626-1.

===
As pointed by [1] CVE-2018-12097 and CVE-2018-12098 are actually fixed
in the upstream issue 32 [4] by commit [5]:
 * Corrected unicode_value_size calculation in
liblnk/liblnk_location_information.c for CVE-2018-12097
 * Added data_size check into liblnk/liblnk_data_block.c for CVE-2018-12098

The fix was included into upstream liblnk version 20180626 and into the
Debian package liblnk_20180626-1.

[1] https://github.com/libyal/liblnk/issues/33
[2]
https://github.com/libyal/libuna/commit/aca678aa7e49ca628f1b27a53fdea883fa8764bb
[3]
https://github.com/libyal/libuna/commit/f22aca8b649afe5cef529d9268186bfe591b7f89
[4] https://github.com/libyal/liblnk/issues/32
[5]
https://github.com/libyal/liblnk/commit/cb7fe0c66a5a01c19f1953fc7814c4fedfdc5785




OpenPGP_signature
Description: OpenPGP digital signature

Bug#941937: apt: Unexpected linkage dependency on libsystemd

[Aleksey Tulinov]

пт, 5 июн. 2020 г. в 11:34, Julian Andres Klode :

> This is a best effort thing, there's nothing sensible we can do if it
> fails, except for logging a warning, and that does not help a lot. We
> don't want to issue an error obviously because you still want to be able
> to upgrade the system if your dbus is down or stuff.
>

So this was added to prevent dpkg from running if the system is going
down, but if the system is going down and dbus isn't up then dpkg is
going to yolo anyway and this "works as intended"?

Nice.

Indeed, this entire discussion is completely pointless.

> Stop talking.
>
> This bug is open to document our decision, not for people to harass
> us. Maybe this was a bad idea and I should have closed and archived
> it to avoid it attracting trolls.
>

I thought i was writing to the issue tracker and not to your personal
blog, this interface is very confusing. I'm sorry, i didn't mean to
violate your privacy.

Bug#941937: apt: Unexpected linkage dependency on libsystemd

[Aleksey Tulinov]

пт, 5 июн. 2020 г. в 00:30, David Kalnischkies :

> I mentioned already that this is implemented in libapt to apply to ALL
> apt-based clients equally. A cron-job is not effected by aliases nor is
> a python script (using python-apt). It isn't even realistic that you
> alias all "normal" libapt clients like apt, apt-get, aptitude, synaptics,
> various desktop-environment-specific software centers …
>

Am i right that dpkg is invoked as a process anyway, even without a
shell, it's going to be something like "dpkg --args --args --etc
--etc"? But it's going to spawn a process, right? Why not make dpkg
invocation on Debian into

systemd-inhibit --what="shutdown" --mode="block" /internal/path/to/dpkg $@

and let it be something else in other distros? This won't create
dependency on libsystemd0 and will allow to perform extra actions on
dpkg invocations that are going to happen regardless if dependency on
libsystemd0 exists or not.

And if you want something that works  equally well 
to systemd's inhibit, why not use systemd-inhibit in the first place?

This dbus voodoo looks a lot like a race condition to me anyway. If
systemd-logind is going down before dpkg can send out dbus message,
which probably can happen during shutdown, who's going to process this
message and inhibit shutdown? `Inhibitor` doesn't do anything with
returned `Fd`, error code from systemd call is handled and returned,
but then ignored, this looks to me like it just hopes that shutdown is
inhibited after the call, which might or might not be true. Although
i'm just skimming through the source code and might be missing
something, but i don't see this in `pkgDPkgPM::Go()` at all. I suppose
it should at least return false if `inhibitor` couldn't place inhibit.

I'm looking at source code here:
https://github.com/Debian/apt/blob/cb608f5c1e8af4f6fe68bc31cb96013308a4003b/apt-pkg/deb/dpkgpm.cc#L1457

> So it would be really nice if we would get some more reason than just
> some OCD-level "but but but, the word 'systemd' is in there somewhere"
> arguments for making maintenance of apt harder (via e.g. dlopen) or it
> just wont happen as building apt is trivially easy and can be fully
> automated, but maintaining and supporting it can't be.
>

Confusing, inflexible, doesn't solve underlying problems, causing more
problems elsewhere, probably doesn't work as intended and potentially
harmful? If maintenance is concern here, why bring more stuff and more
dependencies that don't quite work into apt then?

Bug#941937: apt: Unexpected linkage dependency on libsystemd

[Aleksey Tulinov]

On Wed, 9 Oct 2019 17:36:07 +0200 David Kalnischkies
 wrote:

> As Julian already said, it is "just" used for its dbus communication
> implementation. We don't require systemd to be your init or to be even
> functional. So I guess proposing an alternative which a) works equally
> well and b) doesn't add additional bootstrapping complications has
> better chances of acceptance – assuming that exists as the obvious
> choice libdbus links against libsystemd as well even before checking a)
> and b) …
>

I'm not a big expert in systemd and never will be, but perhaps
`systemd-inhibit --what="shutdown" --mode="block" apt ...` should do
about the same thing. If every invocation of apt should be like that
then maybe `alias apt='systemd-inhibit --what="shutdown"
--mode="block" apt'` in .bashrc can do the trick. This does not
require any patching whatsoever.

This linking to libsystemd is redundant. If issue is with dpkg leaving
system in inconsistent state when interrupted, then perhaps this issue
has to be fixed in dpkg, if issue is with systemd incorrectly
interrupting dpkg, then in systemd. I think that dependency on
systemd:

1) Doesn't solve any underlying issues;
2) Doesn't solve any issues on systems without systemd;
3) Doesn't solve the issue on systems with systemd installed but not
running because in that case there won't be anyone to react on dbus
message and inhibit shutdown, so this is not going to work.

So it doesn't do much anyway, it attempts to solve some very specific
issue in very specific environment, but it doesn't do that very well
and can be replaced with one shell alias.

It would be really nice if this dependency is removed and ideally
underlying issue(s) properly fixed instead of applying band aid here
and there.

Bug#938804: libvtk6.3 still depends on libpython2.7

[Aleksey Kliger]

Package: libvtk6.3
Version: 6.3.0+dfsg2-4
Followup-For: Bug #938804



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

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

Versions of packages libvtk6.3 depends on:
ii  libavcodec587:4.1.4-1+b3
ii  libavformat58   7:4.1.4-1+b3
ii  libavutil56 7:4.1.4-1+b3
ii  libc6   2.29-2
ii  libexpat1   2.2.9-1
ii  libfontconfig1  2.13.1-2+b1
ii  libfreetype62.10.1-2
ii  libgcc1 1:9.2.1-8
ii  libgdal20 [gdal-abi-2-4-0]  2.4.2+dfsg-2
ii  libgl1  1.1.0-1+b1
ii  libgl2ps1.4 1.4.0+dfsg1-2
ii  libhdf5-openmpi-103 1.10.4+repack-10
ii  libjpeg62-turbo 1:1.5.2-2+b1
ii  libjsoncpp1 1.7.4-3+b1
ii  libmariadb3 1:10.3.18-1
ii  libnetcdf-c++4  4.2-11+b1
ii  libnetcdf13 1:4.6.2-1+b1
ii  libodbc12.3.6-0.1+b1
ii  libogg0 1.3.2-1+b1
ii  libopenmpi3 3.1.3-11
ii  libpng16-16 1.6.37-1
ii  libpq5  12.0-1+b1
ii  libpython2.72.7.17-1
ii  libsqlite3-03.30.1-1
ii  libstdc++6  9.2.1-8
ii  libswscale5 7:4.1.4-1+b3
ii  libtheora0  1.1.1+dfsg.1-15
ii  libtiff54.0.10+git191003-1
ii  libx11-62:1.6.8-1
ii  libxml2 2.9.4+dfsg1-7+b3
ii  libxt6  1:1.1.5-1+b3
ii  zlib1g  1:1.2.11.dfsg-1+b1

libvtk6.3 recommends no packages.

Versions of packages libvtk6.3 suggests:
pn  mpi-default-bin  

-- no debconf information

Bug#925833: Fixed upstream

[Aleksey Kravchenko]

Hello!

This bug duplicates upstream issue #142:
https://github.com/a2o/snoopy/issues/142

It is fixed by PR https://github.com/a2o/snoopy/pull/143

The fix commit (PR merge) is
https://github.com/a2o/snoopy/commit/360bb18e16ceaca16a22b94be9e17fd5f2184c01

I've tried to extract the patch from commit (patch attached), but
compilation started to fail with another warning:

cmdline.c: In function ‘snoopy_datasource_cmdline’:
cmdline.c:71:79: error: comparison between pointer and zero character
constant [-Werror=pointer-compare]
   71 | for (cmdLineArgCount=0 ;
*(snoopy_inputdatastorage->argv+cmdLineArgCount) != '\0' ;
cmdLineArgCount++);
 
|  
^~
cmdline.c:71:30: note: did you mean to dereference the pointer?
   71 | for (cmdLineArgCount=0 ;
*(snoopy_inputdatastorage->argv+cmdLineArgCount) != '\0' ;
cmdLineArgCount++);
  |  ^
cc1: all warnings being treated as errors

diff -Nur a/lib/inih/dev-update.sh b/lib/inih/dev-update.sh
--- a/lib/inih/dev-update.sh
+++ b/lib/inih/dev-update.sh
@@ -7,17 +7,27 @@
 set -e
 set -u
 GITORIGINURL="https://github.com/benhoyt/inih.git;
-GITORIGINREF="master"
+GITREF="master"
 TMPGITDIR="./_tmp-inih-git"
 DESTDIR="."
 DESTDIRSRC="./src"
 
 
 
+### Parse arguments
+#
+if [ "${1:-}" != "" ]; then
+GITREF="$1"
+fi
+echo "Using gitref: $GITREF"
+
+
+
 ### Clone the repo
 #
 rm -rf $TMPGITDIR
 git clone   $GITORIGINURL   $TMPGITDIR
+(cd $TMPGITDIR && git checkout $GITREF)
 
 
 
@@ -30,7 +40,7 @@
 
 ### Apply patches
 #
-patch -p3 < ./patches/0001-strip-value-quotes.diff
+patch -p0 < ./patches/0001-strip-value-quotes.diff
 
 
 
diff -Nur a/lib/inih/patches/0001-strip-value-quotes.diff 
b/lib/inih/patches/0001-strip-value-quotes.diff
--- a/lib/inih/patches/0001-strip-value-quotes.diff
+++ b/lib/inih/patches/0001-strip-value-quotes.diff
@@ -1,9 +1,7 @@
-diff --git a/lib/inih/src/ini.c b/lib/inih/src/ini.c
-index 27ca85b..2c015c8 100644
 a/lib/inih/src/ini.c
-+++ b/lib/inih/src/ini.c
-@@ -149,6 +149,17 @@ int ini_parse_stream(ini_reader reader, void* stream, 
ini_handler handler,
- #endif
+--- src/ini.c.orig 2018-12-26 21:08:15.289767000 +
 src/ini.c  2018-12-26 21:07:25.707778000 +
+@@ -187,6 +187,17 @@
+ value = lskip(value);
  rstrip(value);
  
 +/* Strip surrounding double and single quotes */
@@ -19,4 +17,4 @@
 +
  /* Valid name[=:]value pair found, call handler */
  strncpy0(prev_name, name, sizeof(prev_name));
- if (!handler(user, section, name, value) && !error)
+ if (!HANDLER(user, section, name, value) && !error)
diff -Nur a/lib/inih/SOURCE.txt b/lib/inih/SOURCE.txt
--- a/lib/inih/SOURCE.txt
+++ b/lib/inih/SOURCE.txt
@@ -1,3 +1,3 @@
 git-origin-url = 'https://github.com/benhoyt/inih.git'
-git-origin-ref = 'tags/r36-0-g5dbf5cb'
+git-origin-ref = 'tags/r42-0-g9d1af9d'
 patches-dir = 'patches/'
diff -Nur a/lib/inih/src/ini.c b/lib/inih/src/ini.c
--- a/lib/inih/src/ini.c
+++ b/lib/inih/src/ini.c
@@ -24,6 +24,12 @@
 #define MAX_SECTION 50
 #define MAX_NAME 50
 
+/* Used by ini_parse_string() to keep track of string parsing state. */
+typedef struct {
+const char* ptr;
+size_t num_left;
+} ini_parse_string_ctx;
+
 /* Strip whitespace chars off end of given string, in place. Return s. */
 static char* rstrip(char* s)
 {
@@ -64,7 +70,7 @@
 /* Version of strncpy that ensures dest (size bytes) is null-terminated. */
 static char* strncpy0(char* dest, const char* src, size_t size)
 {
-strncpy(dest, src, size);
+strncpy(dest, src, size - 1);
 dest[size - 1] = '\0';
 return dest;
 }
@@ -76,8 +82,14 @@
 /* Uses a fair bit of stack (use heap instead if you need to) */
 #if INI_USE_STACK
 char line[INI_MAX_LINE];
+int max_line = INI_MAX_LINE;
 #else
 char* line;
+int max_line = INI_INITIAL_ALLOC;
+#endif
+#if INI_ALLOW_REALLOC
+char* new_line;
+int offset;
 #endif
 char section[MAX_SECTION] = "";
 char prev_name[MAX_NAME] = "";
@@ -90,14 +102,40 @@
 int error = 0;
 
 #if !INI_USE_STACK
-line = (char*)malloc(INI_MAX_LINE);
+line = (char*)malloc(INI_INITIAL_ALLOC);
 if (!line) {
 return -2;
 }
 #endif
 
+#if INI_HANDLER_LINENO
+#define HANDLER(u, s, n, v) handler(u, s, n, v, lineno)
+#else
+#define HANDLER(u, s, n, v) handler(u, s, n, v)
+#endif
+
 /* Scan through stream line by line */
-while (reader(line, INI_MAX_LINE, stream) != NULL) {
+while (reader(line, max_line, stream) != NULL) {
+#if INI_ALLOW_REALLOC
+offset = strlen(line);
+while (offset == max_line - 1 && line[offset - 1] != '\n') {
+max_line *= 2;
+if (max_line > INI_MAX_LINE)
+max_line = INI_MAX_LINE;
+new_line = realloc(line, max_line);
+if (!new_line) {
+free(line);
+

Bug#927109: lxdm skips pam_env module or pam at all

[Aleksey Midenkov]

Package: lxdm
Version: 0.5.3-2.1
Severity: important

Dear Maintainer,

after logging in to lxdm session I try this:

$ cat ~/.pam_environment 
SSH_AUTH_SOCK DEFAULT="${XDG_RUNTIME_DIR}/ssh_auth_sock"
FOO OVERRIDE=a
$ echo $FOO

$ echo $SSH_AUTH_SOCK

It seems that pam_env.so module didn't load ~/.pam_environment. My
installed package has bug with missing user_readenv=1 (which is 0 by
default) which I corrected and nothing happened. I added 'debug', but
nothing from pam_env got into /var/log/syslog.

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

Kernel: Linux 5.0.0-8-lowlatency (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lxdm depends on:
ii  debconf [debconf-2.0]  1.5.69
ii  gtk2-engines-pixbuf2.24.32-3ubuntu1
ii  iso-codes  3.79-1
ii  libc6  2.29-0ubuntu1
ii  libcairo2  1.15.12-1
ii  libgdk-pixbuf2.0-0 2.38.0+dfsg-6
ii  libglib2.0-0   2.60.0-1
ii  libgtk2.0-02.24.32-3ubuntu1
ii  libpam-modules 1.1.8-3.6ubuntu2
ii  libpam-runtime 1.1.8-3.6ubuntu2
ii  libpam0g   1.1.8-3.6ubuntu2
ii  libpango-1.0-0 1.42.4-3ubuntu1
ii  libpangocairo-1.0-01.42.4-3ubuntu1
ii  librsvg2-common2.40.20-3
ii  libx11-6   2:1.6.7-1
ii  libxcb11.13.1-2
ii  lsb-base   9.20170808ubuntu1
ii  x11-utils  7.7+4

Versions of packages lxdm recommends:
pn  desktop-base  
ii  lxde-common   0.99.2-3

lxdm suggests no packages.

-- Configuration Files:
/etc/pam.d/lxdm changed:
authrequisite   pam_nologin.so
authrequiredpam_env.so debug readenv=1
authrequiredpam_env.so debug readenv=1 envfile=/etc/default/locale
authrequiredpam_env.so debug readenv=1 user_readenv=1 
envfile=/etc/lxdm-environment
@include common-auth
authoptionalpam_gnome_keyring.so
@include common-account
session [success=ok ignore=ignore module_unknown=ignore default=bad] 
pam_selinux.so close
session required   pam_unix.so# added by klaumi
session requiredpam_limits.so
session required   pam_loginuid.so# added by klaumi
@include common-session   # added by klaumi
session [success=ok ignore=ignore module_unknown=ignore default=bad] 
pam_selinux.so open
session optionalpam_gnome_keyring.so auto_start
session optionalpam_systemd.so
@include common-password


-- debconf information excluded

Bug#926504: No hibernate option in shutdown menu

[Aleksey Midenkov]

Package: policykit-1
Version: 0.105-4

Desktop envs suffer from lack of hibernation option. The workaround for
this is cat >
/etc/polkit-1/localauthority/50-local.d/com.ubuntu.enable-hibernate.pkla

[Re-enable hibernate by default in upower]
Identity=unix-user:*
Action=org.freedesktop.upower.hibernate
ResultActive=yes

[Re-enable hibernate by default in logind]
Identity=unix-user:*
Action=org.freedesktop.login1.hibernate;org.freedesktop.login1.handle-hibernate-key;org.freedesktop.login1;org.freedesktop.login1.hibernate-multiple-sessions;org.freedesktop.login1.hibernate-ignore-inhibit
ResultActive=yes

As described here:
http://ubuntuhandbook.org/index.php/2018/05/add-hibernate-option-ubuntu-18-04/

-- 
All the best,

Aleksey Midenkov
@midenok

Bug#922694: lxdm: Continuous restart on start failure

[Aleksey Midenkov]

Package: lxdm
Version: 0.5.3-2.1
Severity: normal

Dear Maintainer,

if Xorg fails to start, lxdm service endlessly loops in restart attempts.

/lib/systemd/system/lxdm.service has a wrong setting for Restart:

Restart=always

it must be:

Restart=on-success


-- System Information:
Debian Release: buster/sid
  APT prefers cosmic-updates
  APT policy: (500, 'cosmic-updates'), (500, 'cosmic-proposed'), (500, 
'cosmic'), (500, 'bionic-updates'), (500, 'bionic'), (500, 'artful'), (100, 
'bionic-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 4.15.0-34-generic (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=en_US 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lxdm depends on:
ii  debconf [debconf-2.0]  1.5.69
ii  gtk2-engines-pixbuf2.24.32-1ubuntu1
ii  iso-codes  3.79-1
ii  libc6  2.28-0ubuntu1
ii  libcairo2  1.15.10-2
ii  libgdk-pixbuf2.0-0 2.36.11-2
ii  libglib2.0-0   2.58.1-2
ii  libgtk2.0-02.24.32-1ubuntu1
ii  libpam-modules 1.1.8-3.6ubuntu2
ii  libpam-runtime 1.1.8-3.6ubuntu2
ii  libpam0g   1.1.8-3.6ubuntu2
ii  libpango-1.0-0 1.40.14-1ubuntu0.1
ii  libpangocairo-1.0-01.40.14-1ubuntu0.1
ii  librsvg2-common2.40.20-2
ii  libx11-6   2:1.6.4-3ubuntu0.1
ii  libxcb11.13-1
ii  lsb-base   9.20170808ubuntu1
ii  x11-utils  7.7+3build1

Versions of packages lxdm recommends:
pn  desktop-base  
ii  lxde-common   0.99.2-3

lxdm suggests no packages.

-- debconf information excluded

Bug#864602: Not enough information

[Aleksey Kravchenko]

It seems I've reproduced the crash by running the following command on an
unmounted ext4 partition:

sudo ./extundelete --restore-directory /home /dev/sdb1


After recompilation of the program under clang address sanitizer:

make CC=clang CXX=clang++ CFLAGS="-O1 -g -fsanitize=address
-fno-omit-frame-pointer" CXXFLAGS="-O1 -g -fsanitize=address
-fno-omit-frame-pointer"


the sanitizer  gave the following results:

- start of stdout -
NOTICE: Extended attributes are not restored.
Loading filesystem metadata ... 96 groups loaded.
Loading journal descriptors ...
=
==2824==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x62110100 at pc 0x0050b0bc bp 0x7ffcdaf56d80 sp 0x7ffcdaf56d78
READ of size 2 at 0x62110100 thread T0
#0 0x50b0bb in be16_to_cpu(unsigned short*)
/home/aleksey/OTHER/EXTUNDELETE/clang_1/src/extundelete.cc:302:8
#1 0x5062da in journal_block_tag_to_cpu(char*, journal_superblock_s*)
/home/aleksey/OTHER/EXTUNDELETE/clang_1/src/extundelete.cc:390:2
#2 0x504f6b in init_journal(struct_ext2_filsys*, struct_ext2_filsys*,
journal_superblock_s*)
/home/aleksey/OTHER/EXTUNDELETE/clang_1/src/extundelete.cc:1052:6
#3 0x525a85 in examine_fs(struct_ext2_filsys*)
/home/aleksey/OTHER/EXTUNDELETE/clang_1/src/cli.cc:287:13
#4 0x5224d8 in main
/home/aleksey/OTHER/EXTUNDELETE/clang_1/src/cli.cc:807:12
#5 0x7fd47ce2409a in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
#6 0x4235d9 in _start
(/home/aleksey/OTHER/EXTUNDELETE/clang_1/src/extundelete+0x4235d9)

0x62110100 is located 0 bytes to the right of 4096-byte region
[0x6210f100,0x62110100)
allocated by thread T0 here:
#0 0x4fa7f2 in operator new[](unsigned long)
(/home/aleksey/OTHER/EXTUNDELETE/clang_1/src/extundelete+0x4fa7f2)
#1 0x5049dc in init_journal(struct_ext2_filsys*, struct_ext2_filsys*,
journal_superblock_s*)
/home/aleksey/OTHER/EXTUNDELETE/clang_1/src/extundelete.cc:990:8
#2 0x525a85 in examine_fs(struct_ext2_filsys*)
/home/aleksey/OTHER/EXTUNDELETE/clang_1/src/cli.cc:287:13
#3 0x5224d8 in main
/home/aleksey/OTHER/EXTUNDELETE/clang_1/src/cli.cc:807:12
#4 0x7fd47ce2409a in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x2409a)

SUMMARY: AddressSanitizer: heap-buffer-overflow
/home/aleksey/OTHER/EXTUNDELETE/clang_1/src/extundelete.cc:302:8 in
be16_to_cpu(unsigned short*)
Shadow bytes around the buggy address:
  0x0c427fff9fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c427fff9fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c427fff9ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c427fffa000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c427fffa010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c427fffa020:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c427fffa030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c427fffa040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c427fffa050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c427fffa060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c427fffa070: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
  Shadow gap:  cc
==2824==ABORTING
- end of stdout -

So the problem is somewhere in the init_journal() function.
The heap-buffer-overflow occurred at extundelete.cc:1052:

journal_block_tag_to_cpu( (char *)jbt, jsb );

on the block of size 4096 bytes, allocated at extundelete.cc:990 by line:

buf = new char[ EXT2_BLOCK_SIZE(jfs->super)];


  Regards,
  Aleksey

>

Bug#864602: Not enough information

[Aleksey Kravchenko]

Hello,

this bug report is still has not enough information. To narrow down the
problem, we need a stacktrace. To get it, one need to run the program under
gdb with extundelete debug package installed.

Such report would be much better if the program be recompiled from sources
without optimization:

DEB_BUILD_OPTIONS='noopt debug' debuild -uc -us

and then run under gdb:

sudo gdb -ex run --args ./extundelete --restore-directory /user/bin/storage
/dev/sdb1


Nevertheless, I've investigated the bug a bit and here is what I found.

1. First, I've viewed the source code for the cause of the error message:

> *** Error in `extundelete': double free or corruption (!prev):
> 0x01a95000 ***


and did not found any double deallocations, only an insignificant memory
leak at cli.cc:346.

So the most probable cause of the message is a *heap corruption*, due to
some out-of-bounds access (buffer overrun/underrun).

2. Another suspect is the src/block.c source file:

>  * This file was modified from e2fsprogs lib/ext2fs/block.c and extent.c
>  * These modifications allow undeletion with libext2fs 1.39 to 1.42.6,
>  * and possibly newer versions.

Unstable currently has libext2fs-dev 1.44.5, so may be extundelete is
linked against incompatible version of libext2fs.

3. Since extundelete is a pretty old program (last commit is on
2013-01-03), may be it just has bad support for modern ext4.

Regards,
Aleksey.

Bug#716182: Root cause and patch.

[Aleksey Kravchenko]

Hello,

the easiest way to reproduce the problem is to run `./mergebad -s`.

The mergebad utility doesn't check the number of required arguments and
crashes, because NULL is passed to atoll() at:
mergebad.c:315:length = atoll(argv[++loop]);

I've prepared the quick-fix patch [1]. With minimum changes it adds
checking of arguments number.

The full solution would be to use getopt(), the same way as in the
recoverdm.c.

[1]
https://salsa.debian.org/pkg-security-team/recoverdm/blob/debian/master/debian/patches/30-fix-BTS-mergebad-crash.patch

  Best wishes,
  Aleksey

Bug#848881: Solution

[Aleksey Kravchenko]

The same bug in the upstream github bugtracker [1].

Upstream already has commits with the fix [2], [3].

[1] https://github.com/baruch/gpart/issues/9
[2]
https://github.com/baruch/gpart/commit/0529a52485411be351bb75d628edc187a53c0e40
[3]
https://github.com/baruch/gpart/commit/cbdefb633797ccfbc86ec4c6268292f20621d20f

  Regads,
  Aleksey

Bug#848881: buggy code

[Aleksey Kravchenko]

Hello Ingo,

You should install gpart-dbgsym* package, to get a meaningful stacktrace.

It's a luck I've found the problem from your strace log ;)

The root cause is the code gpart-0.3/src/disku.c:80:
  if (ioctl(d->d_fd,HDIO_GETGEO,) == -1)
pr(FATAL,EM_IOCTLFAILED,"HDIO_GETGEO",strerror(errno));
#ifdef BLKGETSIZE
  if (ioctl(d->d_fd,BLKGETSIZE,) == -1)
pr(FATAL,EM_IOCTLFAILED,"BLKGETSIZE",strerror(errno));
  g.d_nsecs = nsects;
  g.d_c = nsects / (hg.heads * hg.sectors); // <- BUG HERE - devide by 0

as you can see from strace:
> ioctl(3, HDIO_GETGEO, {heads=0, sectors=0, cylinders=0, start=0}) = 0

so (hg.heads * hg.sectors) is here zero.

The latest version 1:0.3-5 contains the same code.

  Regards,
  Aleksey

Bug#901967: CVE-2018-11723 is fixed in libpff 20180714.

[Aleksey Kravchenko]

The actual bug heap-buffer-overflow beneeth the
CVE-2018-11723 is described in the Issue #64 [1]
in the upstream bugtracker.

The bug is fixed in the version 20180714 by commit [2].

See also libpff author comments [3] on this CVE-2018-11723.

  [1] https://github.com/libyal/libpff/issues/64
  [2]
https://github.com/libyal/libpff/commit/7b92bcace7e743cc9417e3cc3e4eee29abb70cf5
  [3] https://github.com/libyal/libpff/issues/66

Bug#100808: Ref: MRS.A.G-00847-INFO

[Aleksey Cheusov]

What is the question?05:13, 27 October 2018, "Mrs. A. Griffith" :Greetings of the day to you...I am not sure you received my previous e-mail. Is this e-mail still valid and secured? I have important details to share with you. If interested Get back asap.Thanks for understanding.Mrs Audrey Griffith.Email: mrsgriffit...@foldercrate.com

Bug#896098: krita: Krita's Python scripting not working

[Aleksey Samoilov]

19.04.2018 21:56, Lisandro Damián Nicanor Pérez Meyer пишет:

Oh, please do reply to the bug report! This has been sent to me in private!

On 19 April 2018 at 14:16, Sunderland93  wrote:

It needs libpython3.6m.so, which is contained in libpython3.6-dev. Without
it Python scripting is not available in Tools > Scripting menu, and error is

Loading Python plugin
"" false
()
()
()
Could not create /usr/lib/x86_64-linux-gnu/libpython3.6m.so
"Cannot load Python library"


On 19.04.2018 20:33, Lisandro Damián Nicanor Pérez Meyer wrote:

El jue., 19 de abr. de 2018 10:15, Sunderland93 
escribió:

Package: krita
Version: 1:4.0.1+dfsg-1
Severity: important

Dear Maintainer,

Krita's Python scripting not working in this version. It needs
libpython3-dev package,
which must added into dependency's (or Recommends section), just like in
Ubuntu


Why would it need a development package for runtime use?

Bug#889891: python-csvkit: Executable for csvgrep.py, csvcut.py etc. are needed

[Aleksey Cheusov]

Package: python-csvkit
Version: 0.9.1-3
Severity: normal

Hello. Could you please provide executables for .py files under
/usr/lib/python2.7/dist-packages/csvkit/utilities directory?
That is, csvgrep (without .py or .pyc extension), csvcut, csvsort etc.
It would be nice to see these executable under bin directory.

Also, please specify python2 in shebang explicitely instead of '/usr/bin/env 
python'.
A reason for this is that default python may change to, for example, python v.3.

Thanks.

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

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

Versions of packages python-csvkit depends on:
ii  python 2.7.13-2
ii  python-dateutil2.5.3-2
ii  python-dbf 0.96.005-1
ii  python-openpyxl2.3.0-3
ii  python-six 1.10.0-3
ii  python-sqlalchemy  1.0.15+ds1-1
ii  python-xlrd1.0.0-1

python-csvkit recommends no packages.

python-csvkit suggests no packages.

-- no debconf information

Bug#850411: Upgrade to new upstream version of miniupnpd

[Aleksey Tamarevskiy]

Current version 1.8.20140523 contains bug in NAT PMP protocol: it reject higher 
byte of mapped port number. Port mapping via NAT PMP works only for ports < 
256, so it is useless.


--
Alexey Tamarevskiy

Bug#862792: dput: UnicodeDecodeError: 'ascii' codec can't decode byte 0xd0

[Aleksey Samoilov]

I found the cause of the problem: if there is a no directory with a
cyrillic name in the path of the file ("Загрузки" for example) - problem
dissapears.

Bug#862792: dput: UnicodeDecodeError: 'ascii' codec can't decode byte 0xd0

[Aleksey Samoilov]

Package: dput
Version: 0.12.0
Severity: normal

Dear Maintainer,

When I run dput to upload source code to may Ubuntu PPA, an error occuers:

Checking signature on .changes
Traceback (most recent call last):
  File "/usr/bin/dput", line 11, in 
load_entry_point('dput==0.12.0', 'console_scripts', 'execute-dput')()
  File "/usr/share/dput/dput/dput.py", line 1012, in main
config, check_only, check_version, unsigned_upload, debug)
  File "/usr/share/dput/dput/dput.py", line 374, in verify_files
config, check_only, unsigned_upload, binary_upload, debug)
  File "/usr/share/dput/dput/dput.py", line 272, in verify_signature
assert_good_signature_or_exit(changes_file_path)
  File "/usr/share/dput/dput/dput.py", line 256, in
assert_good_signature_or_exit
crypto.check_file_signature(infile)
  File "/usr/share/dput/dput/crypto.py", line 106, in check_file_signature
path=infile.name, sig=signature, description=description))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xd0 in position 19:
ordinal not in range(128)




-- System Information:


Debian Release: 9.0


  APT prefers testing


  APT policy: (500, 'testing')


Architecture: amd64


 (x86_64)


Foreign Architectures: i386





Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)


Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)


Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dput depends on:
ii  python-debian 0.1.30
ii  python-gpg1.8.0-3+b2
ii  python-pkg-resources  33.1.1-1
pn  python:any

dput recommends no packages.

Versions of packages dput suggests:
ii  lintian 2.5.50.3
pn  mini-dinstall   
ii  openssh-client  1:7.4p1-10
ii  rsync   3.1.2-1

-- no debconf information

Bug#855042: kdenlive: crash after select a font in title clip editor

[Aleksey Samoilov]

Hi,

I tested Kdenlive with libqt5widgets5_5.7.1~20161021+dfsg-2. There is no 
problem!

Bug has gone!

Bug#855042: kdenlive: crash after select a font in title clip editor

[Aleksey Samoilov]

14.02.2017 18:14, Patrick Matthäi пишет:


Am 13.02.2017 um 21:17 schrieb Aleksey Samoilov:

And does this issue still occurs with mlt 6.4.1-2 and kdenlive from git,
but picking up the Applications/16.12 branch?

With MLT 6.5.0 (build from Git) and Kdenlive Git this issue not occur.
Same as with Kdenlive Appimage package.

How should I find the fix now? Please test it with mlt 6.4.1-2 from
unstable and kdenlive from the current git branch

Applications/16.12



Okey. I'm build Kdenlive from Git Applications/16.12 branch. Bug still 
here. MLT version is 6.4.1-2 from Unstable.

Bug#855042: kdenlive: crash after select a font in title clip editor

[Aleksey Samoilov]

14.02.2017 03:26, Patrick Matthäi пишет:

Am 13.02.2017 um 16:10 schrieb Aleksey Samoilov:

please retest with kdenlive and mlt from unstable, it should be already
fixed?

No. Bug still here.

Sure? Could you please test with kdenlive 16.12.1-3 and mlt 6.4.1-2,
also installing the -dbg packages and send me the backtrace please.


Yes, I install Kdenlive and MLT from Unstable. Here is backtrace:

Application: Kdenlive (kdenlive), signal: Segmentation fault

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

[Current thread is 1 (Thread 0x7fe195d8b940 (LWP 18422))]

Thread 11 (Thread 0x7fe11bfff700 (LWP 18457)):

#0 0x7fe1881ceb52 in pa_mainloop_iterate () from 
/lib/x86_64-linux-gnu/libpulse.so.0


#1 0x7fe175608e6b in ?? () from /lib/x86_64-linux-gnu/libSDL-1.2.so.0

#2 0x7fe1755db7a0 in ?? () from /lib/x86_64-linux-gnu/libSDL-1.2.so.0

#3 0x7fe1755e4f38 in ?? () from /lib/x86_64-linux-gnu/libSDL-1.2.so.0

#4 0x7fe175624dd9 in ?? () from /lib/x86_64-linux-gnu/libSDL-1.2.so.0

#5 0x7fe18b291424 in start_thread (arg=0x7fe11bfff700) at 
pthread_create.c:333


#6 0x7fe18deb19bf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:105


Thread 10 (Thread 0x7fe138c6e700 (LWP 18456)):

#0 pthread_cond_wait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185


#1 0x7fe194a284e5 in consumer_worker_thread (arg=0x55f850f2b4f0) at 
mlt_consumer.c:1053


#2 0x7fe18b291424 in start_thread (arg=0x7fe138c6e700) at 
pthread_create.c:333


#3 0x7fe18deb19bf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:105


Thread 9 (Thread 0x7fe13a8f6700 (LWP 18455)):

#0 pthread_cond_wait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185


#1 0x7fe194a284e5 in consumer_worker_thread (arg=0x55f850f2b4f0) at 
mlt_consumer.c:1053


#2 0x7fe18b291424 in start_thread (arg=0x7fe13a8f6700) at 
pthread_create.c:333


#3 0x7fe18deb19bf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:105


Thread 8 (Thread 0x7fe13946f700 (LWP 18454)):

#0 pthread_cond_wait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185


#1 0x7fe17586f490 in consumer_thread (arg=0x55f850f2b4f0) at 
consumer_sdl_audio.c:595


#2 0x7fe18b291424 in start_thread (arg=0x7fe13946f700) at 
pthread_create.c:333


#3 0x7fe18deb19bf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:105


Thread 7 (Thread 0x7fe119452700 (LWP 18451)):

#0 0x7fe18dea854d in poll () at ../sysdeps/unix/syscall-template.S:84

#1 0x7fe1884459f6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0

#2 0x7fe188445b0c in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0


#3 0x7fe18ecd706b in 
QEventDispatcherGlib::processEvents(QFlags) 
() from /lib/x86_64-linux-gnu/libQt5Core.so.5


#4 0x7fe18ec809ca in 
QEventLoop::exec(QFlags) () from 
/lib/x86_64-linux-gnu/libQt5Core.so.5


#5 0x7fe18eaae0f3 in QThread::exec() () from 
/lib/x86_64-linux-gnu/libQt5Core.so.5


#6 0x7fe18eab2da8 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5

#7 0x7fe18b291424 in start_thread (arg=0x7fe119452700) at 
pthread_create.c:333


#8 0x7fe18deb19bf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:105


Thread 6 (Thread 0x7fe119c53700 (LWP 18450)):

#0 0x7fe18848afe9 in g_mutex_lock () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0


#1 0x7fe188444ee9 in g_main_context_prepare () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0


#2 0x7fe18844591b in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0

#3 0x7fe188445b0c in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0


#4 0x7fe18ecd706b in 
QEventDispatcherGlib::processEvents(QFlags) 
() from /lib/x86_64-linux-gnu/libQt5Core.so.5


#5 0x7fe18ec809ca in 
QEventLoop::exec(QFlags) () from 
/lib/x86_64-linux-gnu/libQt5Core.so.5


#6 0x7fe18eaae0f3 in QThread::exec() () from 
/lib/x86_64-linux-gnu/libQt5Core.so.5


#7 0x7fe18eab2da8 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5

#8 0x7fe18b291424 in start_thread (arg=0x7fe119c53700) at 
pthread_create.c:333


#9 0x7fe18deb19bf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:105


Thread 5 (Thread 0x7fe14affe700 (LWP 18431)):

#0 0x7fe18848afe9 in g_mutex_lock () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0


#1 0x7fe188445af8 in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0


#2 0x7fe18ecd706b in 
QEventDispatcherGlib::processEvents(QFlags) 
() from /lib/x86_64-linux-gnu/libQt5Core.so.5


#3 0x7fe18ec809ca in 
QEventLoop::exec(QFlags) () from 
/lib/x86_64-linux-gnu/libQt5Core.so.5


#4 0x7fe18eaae0f3 in QThread::exec() () from 
/lib/x86_64-linux-gnu/libQt5Core.so.5


#5 0x7fe18f8496a5 in ?? () from /lib/x86_64-linux-gnu/libQt5Qml.so.5

#6 0x7fe18eab2da8 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5

#7 0x7f

Bug#855042: kdenlive: crash after select a font in title clip editor

[Aleksey Samoilov]

13.02.2017 23:04, Patrick Matthäi пишет:

please retest with kdenlive and mlt from unstable, it should be already
fixed?




No. Bug still here.

Bug#855042: kdenlive: crash after select a font in title clip editor

[Aleksey Samoilov]

Package: kdenlive
Version: 16.12.1-1
Severity: normal

Dear Maintainer,

When I create a title clip in Kdenlive, and select font for it, 
application is crashed.


This bug can't reproduced with Kdenlive GIT master and MLT 6.5.0.


-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages kdenlive depends on:
ii  ffmpeg   7:3.2.2-2
ii  kded55.28.0-1
ii  kdenlive-data16.12.1-1
ii  kinit5.28.0-1
ii  kio  5.28.0-1
ii  libc62.24-9
ii  libgcc1  1:6.3.0-6
ii  libgl1-mesa-glx [libgl1] 13.0.3-1
ii  libglu1-mesa [libglu1]   9.0.0-2.1
ii  libkf5archive5   5.28.0-1
ii  libkf5attica55.28.0-1
ii  libkf5auth5  5.28.0-1
ii  libkf5bookmarks5 5.28.0-1
ii  libkf5codecs55.28.0-1
ii  libkf5completion55.28.0-1
ii  libkf5configcore55.28.0-1
ii  libkf5configgui5 5.28.0-1
ii  libkf5configwidgets5 5.28.0-1
ii  libkf5coreaddons55.28.0-1
ii  libkf5crash5 5.28.0-1
ii  libkf5dbusaddons55.28.0-1
ii  libkf5filemetadata3  5.28.0-1
ii  libkf5guiaddons5 5.28.0-1
ii  libkf5i18n5  5.28.0-1
ii  libkf5iconthemes55.28.0-1
ii  libkf5itemviews5 5.28.0-1
ii  libkf5jobwidgets55.28.0-1
ii  libkf5kiocore5   5.28.0-1
ii  libkf5kiofilewidgets55.28.0-1
ii  libkf5kiowidgets55.28.0-1
ii  libkf5newstuff5  5.28.0-1
ii  libkf5notifications5 5.28.0-1
ii  libkf5notifyconfig5  5.28.0-1
ii  libkf5service-bin5.28.0-1
ii  libkf5service5   5.28.0-1
ii  libkf5solid5 5.28.0-2
ii  libkf5sonnetui5  5.28.0-1
ii  libkf5textwidgets5   5.28.0-1
ii  libkf5widgetsaddons5 5.28.0-1
ii  libkf5xmlgui55.28.0-1
ii  libmlt++36.4.1-1
ii  libmlt6  6.4.1-1
ii  libqt5concurrent55.7.1+dfsg-3+b1
ii  libqt5core5a 5.7.1+dfsg-3+b1
ii  libqt5dbus5  5.7.1+dfsg-3+b1
ii  libqt5gui5   5.7.1+dfsg-3+b1
ii  libqt5network5   5.7.1+dfsg-3+b1
ii  libqt5qml5   5.7.1-2
ii  libqt5quick5 5.7.1-2
ii  libqt5script55.7.1~20161021+dfsg-2
ii  libqt5svg5   5.7.1~20161021-2
ii  libqt5widgets5   5.7.1+dfsg-3+b1
ii  libqt5xml5   5.7.1+dfsg-3+b1
ii  libstdc++6   6.3.0-6
ii  libv4l-0 1.12.2-2
ii  melt 6.4.1-1
ii  oxygen-icon-theme5:5.28.0-1
ii  qml-module-qtquick-controls  5.7.1~20161021-2
ii  qml-module-qtquick2  5.7.1-2

Versions of packages kdenlive recommends:
ii  dvdauthor0.7.0-2
ii  dvgrab   3.5+git20160707.1.e46042e-1
ii  frei0r-plugins   1.5.0-1
ii  genisoimage  9:1.1.11-3
ii  recordmydesktop  0.3.8.1+svn602-1+b1
ii  swh-plugins  0.4.17-1

Versions of packages kdenlive suggests:
ii  khelpcenter  4:16.08.3-1

-- no debconf information

Bug#849493: RFS: vc/1.3.0-1 [ITP]

[Aleksey Samoilov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "vc"

   Package name: vc
   Version : 1.3.0-1
   Upstream Author : Matthias Kretz<m.kr...@gsi.de>
   URL :https://github.com/VcDevel/Vc
   License : BSD-3-Clause
   Section : libs

It builds those binary packages:

vc-dev - SIMD Vector Classes for C++

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

  https://mentors.debian.net/package/vc


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

dget -xhttps://mentors.debian.net/debian/pool/main/v/vc/vc_1.3.0-1.dsc


  Changes since the last upload:

  vc (1.3.0-1) unstable; urgency=medium

  * Initial release (Closes: #846491)


  Regards,
   Aleksey Samoilov

Bug#848356: [mypaint]Fullscreen mode destroys canvas area

[Aleksey Samoilov]

Package: mypaint

Version: 1.2.0-3

Severity: important

With GTK 3.22.4 from Debian testing pressing F11 to fullscreen MyPaint 
makes the canvas area disappear. Pressing a key in this state results in 
an assertion error about the active TDW being null.



   Steps to reproduce

This is reproducible with either a fresh config or an existing one.

1. Start MyPaint
2. Press F11, mypaint goes full-screen. Canvas area disappears, widgets
   are drawn with the default theme colour.
3. Press a key such as space. The following assertion pops up from the
   keyboard handler:

Traceback:

```python
Mypaint version: 1.2.0+gitexport.f62444e
System information: Linux-4.8.0-1-amd64-x86_64-with-debian-stretch-sid
Traceback (most recent call last):
  File "/usr/share/mypaint/gui/keyboard.py", line 153, 
_key_press_cb(self=, 
widget=(MyPaintDrawWindow at 0x5581c7542280)>, event=0x7f7821a3a050 (void at 0x5581c89a93c0)>)

# Otherwise, dispatch the event to the active doc.
return self._dispatch_fallthru_key_press_event(widget, event)
  variables: {'self._dispatch_fallthru_key_press_event': ('local', 
>), 'widget': 
('local', (MyPaintDrawWindow at 0x5581c7542280)>), 'event': ('local', 
)}
  File "/usr/share/mypaint/gui/keyboard.py", line 230, 
_dispatch_fallthru_key_press_event(self=instance>, win=(MyPaintDrawWindow at 0x5581c7542280)>, event=0x7f7821a3a050 (void at 0x5581c89a93c0)>)

# Fall-through behavior: handle via the active document.
target_doc, target_tdw = self._get_active_doc()
if target_doc is None:
  variables: {'self._get_active_doc': ('local', KeyboardManager._get_active_doc of instance at 0x7f782a504fc8>>), 'target_doc': (None, []), 'target_tdw': 
(None, [])}
  File "/usr/share/mypaint/gui/keyboard.py", line 222, 
_get_active_doc(self=)

# event dispatch.
active_tdw = 
gui.tileddrawwidget.TiledDrawWidget.get_active_tdw()

for doc in gui.document.Document.get_instances():
  variables: {'active_tdw': (None, []), 
'gui.tileddrawwidget.TiledDrawWidget.get_active_tdw': ('global', method GObjectMeta.get_active_tdw of 'gui.tileddrawwidget.TiledDrawWidget'>>)}
  File "/usr/share/mypaint/gui/tileddrawwidget.py", line 75, 
get_active_tdw(kin=)

kin.__tdw_refs.extend(invis_refs)
assert active_tdw is not None
return active_tdw
  variables: {'active_tdw': ('local', None), 'None': ('builtin', None)}
AssertionError:

Upstream bug https://github.com/mypaint/mypaint/issues/735

Fixed in https://github.com/mypaint/mypaint/releases/tag/v1.2.1-beta.1

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

Kernel: Linux 4.8.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mypaint depends on:
ii  gir1.2-gtk-3.0   3.22.4-1
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-7
ii  libcairo-gobject21.14.6-1.1
ii  libcairo21.14.6-1.1
ii  libgcc1  1:6.2.1-5
ii  libgdk-pixbuf2.0-0   2.36.0-1
ii  libglib2.0-0 2.50.2-2
ii  libgomp1 6.2.1-5
ii  libgtk-3-0   3.22.4-1
ii  libjson-c3   0.12.1-1.1
ii  liblcms2-2   2.7-1
ii  libpango-1.0-0   1.40.3-3
ii  libpangocairo-1.0-0  1.40.3-3
ii  libpng16-16  1.6.26-2
ii  libpython2.7 2.7.13~rc1-1
ii  libstdc++6   6.2.1-5
ii  mypaint-data 1.2.0-3
ii  python-gi-cairo  3.22.0-1
ii  python-numpy 1:1.11.2-1
pn  python2.7:any
pn  python:any   

Versions of packages mypaint recommends:
ii  shared-mime-info  1.7-1

Versions of packages mypaint suggests:
pn  mypaint-data-extras  

-- no debconf information

Bug#790448: [systemd] Regression from 215-18: Shutdown delayed for minutes waiting for automounted CIFS

[Gavrilov Aleksey]

I have tried this method, but it leads to the fact that the network 
interface is not configured.


ifcofig
loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:65536  Metric:1
  RX packets:42 errors:0 dropped:0 overruns:0 frame:0
  TX packets:42 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:2346 (2.2 KiB)  TX bytes:2346 (2.2 KiB)

systemd-analyze plot > /tmp/bootup.svg

In an attachment, the command output.



On 25.03.2016 13:38, Michael Biebl wrote:

Am 25.03.2016 um 06:07 schrieb Gavrilov Aleksey:

I formed the opinion that Systemd not wait Dhcp-client when the network
interfaces are configured through it.

Is systemd-networkd-wait-online.service enabled (systemctl is-enabled
systemd-networkd-wait-online.service). If not, please enable it with
systemctl enable.




--

Sincerely, Gavrilov Aleksey
System Administrator
Ltd. "Hearst Shkulev Digital Rugion"
tel .: 8 (351) 729-94-90, ext. 345
mob. +7 999 581 7934
gavri...@info74.ru
Chelyabinsk, st. Melkombinat February 1st Precinct, 18, office 208
for TRC `Rodnik`

Bug#790448: [systemd] Regression from 215-18: Shutdown delayed for minutes waiting for automounted CIFS

[Gavrilov Aleksey]

Package: systemd
Version: 215-17+deb8u3

Hi

An error occurs when the system boots.
Conditions for the appearance.
The main network interface is adapted to receive via DHCP using systemd.

cat /etc/systemd/network/00_eth0.network

/[Match] Name=eth0 [Network] DHCP=yes # <-/

cat /etc/systemd/network/10_interface_mesh0_ipv4.network

/# Ansible managed: modified on 2016-01-29 17:12:05 /

/[Match] Name=mesh0 [Network] Address=172.16.35.5/24/ cat 
/etc/network/interfaces /# The loopback network interface auto lo iface 
lo inet loopback/


root@itregion-gavrilov:/tmp# systemctl status media-dst.mount
● media-dst.mount - /media/dst
   Loaded: loaded (/etc/fstab)
   Active: failed (Result: exit-code) since Чт 2016-03-24 15:41:56 
YEKT; 1h 21min ago

Where: /media/dst
 What: //192.168.0.37/dst
 Docs: man:fstab(5)
   man:systemd-fstab-generator(8)
  Process: 701 ExecMount=/bin/mount -n //192.168.0.37/dst /media/dst -t 
cifs -o 
rw,credentials=/root/.smb,iocharset=utf8,_netdev,uid=1000,gid=1000 
(code=exited, status=32)


мар 24 15:41:56 itregion-gavrilov systemd[1]: media-dst.mount mount 
process exited, code=exited status=32

мар 24 15:41:56 itregion-gavrilov systemd[1]: Failed to mount /media/dst.
мар 24 15:41:56 itregion-gavrilov systemd[1]: Unit media-dst.mount 
entered failed state.
мар 24 15:41:56 itregion-gavrilov mount[701]: mount error(101): Network 
is unreachable
мар 24 15:41:56 itregion-gavrilov mount[701]: Refer to the mount.cifs(8) 
manual page (e.g. man mount.cifs)


I also read this thread here ( 
https://lists.debian.org/debian-user/2015/06/msg01545.html )
I found that the error only occurs if the configured network interface 
systemd dhcp.


Adding a script solves the problem, but it's clumsy solution.

[Unit]
Description=Waiting for CIFS server
DefaultDependencies=no
Conflicts=shutdown.target
Wants=network-online.target
Before=network-online.target shutdown.target
After=network.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c "while ! ping -c 1 gw_ip >/dev/null; do sleep 1; done"
# Modify this timeout to your heart's content.
TimeoutStartSec=10

[Install]
WantedBy=network.target

I formed the opinion that Systemd not wait Dhcp-client when the network 
interfaces are configured through it.


--

Sincerely, Gavrilov Aleksey
System Administrator
Ltd. "Hearst Shkulev Digital Rugion"
tel .: 8 (351) 729-94-90, ext. 345
mob. +7 999 581 7934
gavri...@info74.ru
Chelyabinsk, st. Melkombinat February 1st Precinct, 18, office 208
for TRC `Rodnik`

Bug#753980: RFS: rhash-bindings/1.3.2-1

[Aleksey Kravchenko]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package rhash-bindings

 * Package name: rhash-bindings
   Version : 1.3.2-1
   Upstream Author : Aleksey Kravchenko rhash.ad...@gmail.com
 * URL : http://rhash.sf.net/
 * License : RHash License
   Section : utils

  It builds those binary packages:

 librhash-cil-dev - development files for CLI bindings of LibRHash
 librhash-cil-doc - documentation for the CLI bindings of LibRHash
 librhash-java - Java interface for LibRHash hash sums calculation library
 librhash-java-doc - documentation for librhash Java bindings
 librhash-perl - Perl interface for LibRHash hash sums calculation library
 librhash-php5 - RHash module for PHP 5
 librhash1.0-cil - CLI interface for LibRHash hash sums calculation library
 monodoc-rhash-manual - monodoc manual for the CLI bindings of LibRHash
 python-rhash - Python interface for LibRHash hash sums calculation library
 ruby-rhash - Ruby interface for LibRHash hash sums calculation library

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

  http://mentors.debian.net/package/rhash-bindings


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

dget -x
http://mentors.debian.net/debian/pool/main/r/rhash-bindings/rhash-bindings_1.3.2-1.dsc

  More information about rhash can be obtained from http://rhash.sf.net.

  Changes since the last upload:

  * New upstream release v1.3.2
   - bump Standards-Version to 3.9.5
   - perl module renamed to Crypt::Rhash


  Regards,
   Aleksey Kravchenko



signature.asc
Description: OpenPGP digital signature

Bug#750842: rhash: Rhash with recursion can be trapped in a loop (created with a symlink) forever

[Aleksey Kravchenko]

Mario,
thanks for the patch!
It's accepted upstream with small changes [1] ;)

[1]
https://github.com/rhash/RHash/commit/3d00ccb67d4a4e5b3bdc969edfc7094f46fa75e7

09.06.2014 16:48, Mario B. wrote:
 Package: rhash
 Version: 1.3.1-1
 Followup-For: Bug #750842
 
 Dear Maintainer,
 
 I've added a very simple patch (for UNIX systems at least), but now symlinks 
 are ignored. I don't know if this is the best behaviour.
 
 Regards
 
 
 -- System Information:
 Debian Release: 7.5
   APT prefers stable-updates
   APT policy: (990, 'stable-updates'), (990, 'stable'), (550, 'testing'), 
 (500, 'unstable')
 Architecture: i386 (i686)
 
 Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash
 
 Versions of packages rhash depends on:
 ii  libc6  2.18-7
 ii  librhash0  1.3.1-1
 
 Versions of packages rhash recommends:
 ii  libssl1.0.0  1.0.1e-2+deb7u10
 
 rhash suggests no packages.
 
 -- no debconf information
 



signature.asc
Description: OpenPGP digital signature

Bug#743424: closed by Tianon Gravi admwig...@gmail.com (Bug#743424: fixed in docker.io 0.9.1~dfsg1-1)

[Aleksey Zapparov]

...@member.fsf.org
 To: Debian Bug Tracking System sub...@bugs.debian.org
 Cc:
 Date: Wed, 02 Apr 2014 17:26:08 +0200
 Subject: docker.io: Please release v0.9.1
 Package: docker.io
 Version: 0.9.0+dfsg1-1
 Severity: wishlist

 Dear Maintainer,

 Docker 0.9.0 has a very annoying bug related to pty allocation which makes it
 impossible to sue container as ssh server. It was fixed in v0.9.1. Please,
 release new version. I saw you are working on making this happen, just really
 want release to happen asap.

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

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

 Versions of packages docker.io depends on:
 ii  adduser  3.113+nmu3
 ii  init-system-helpers  1.18
 ii  iptables 1.4.21-1
 ii  libapparmor1 2.8.0-5+b1
 ii  libc62.18-4
 ii  libdevmapper1.02.1   2:1.02.83-2
 ii  libsqlite3-0 3.8.4.1-1
 ii  perl 5.18.2-2+b1

 Versions of packages docker.io recommends:
 ii  aufs-tools   1:3.2+20130722-1.1
 ii  ca-certificates  20140325
 ii  git  1:1.9.1-1
 ii  xz-utils 5.1.1alpha+20120614-2

 docker.io suggests no packages.

 -- no debconf information




-- 
Sincerely yours,
Aleksey V. Zapparov A.K.A. ixti
FSF Member #7118
Mobile Phone: +34 677 990 688
Homepage: http://ixti.net/
JID: zappa...@jabber.ru

*Origin: Happy Hacking!


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

Bug#739412: dictionaries-common: works slow on very short words at the end of big file

[Aleksey Cherepanov]

Package: dictionaries-common
Version: 1.20.5
Severity: normal

Dear Maintainer,

   * What led up to the situation?

I faced a problem editing my big .org file (2mb+) with flyspell-mode
enabled. I edit it every day, regularly mistype and get words of one
or two letters that are wrong in Russian and cause flyspell work slow.

This one-liner produces good file to reproduce the bug.
perl -e 'print(((join  , (met and) x 10) . \n) x 3)'  t.txt

Typing nd at the end of file gives a huge pause even on a fast
computer. But mw or md does not give pauses because they are not
substrings in this file. It is repeatable with emacs -Q.

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

 So exact sequence is
$ emacs --version
GNU Emacs 24.3.1
$ emacs23 --version
GNU Emacs 23.4.1
$ perl -e 'print(((join  , (met and) x 10) . \n) x 3)'  t.txt
$ LANG=C emacs -Q t.txt
 Then in emacs:
M-x flyspell-mode RET
M-
nd SPC

'emacs23 -Q t.txt' works the same way. LANG=C affects regular words
because default dictionary is Russian on my system so without LANG=C
all words (met and and) are considered misspelled. But it does not
affect huge pause at the end.

   * What was the outcome of this action?

Huge pause when emacs does not react on keys except C-g. Word nd is
colored as misspelled after the pause. C-g stops emacs internal
thinking and I could work without waiting but word nd is not colored
as misspelled word.

   * What outcome did you expect instead?

I expect it to work as fast as with other words like md or mw that
does not produce a pause and are colored immediately.


I tried to patch flyspell-word-search-backward and
flyspell-word-search-forward functions from flyspell.el replacing
search-backward with word-search-backward and search-forward with
word-search-forward (perl -pe 's/\(search-/(word-search-/' ). It
solved the problem but I do not know what it broke.

I expect problems with this solution because I do not know if
flyspell's meaning of word is the same as emacs' one. I think it is
described in flyspell-get-word function that is called after search-*
in the patched functions.

flyspell-duplicate-distance variable on its own could mitigate the
problem but it changes the behaviour so I do not want to use this
variable.

Thanks!

-- 
Regards,
Aleksey Cherepanov


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

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

Versions of packages dictionaries-common depends on:
ii  debconf [debconf-2.0]  1.5.52
ii  libtext-iconv-perl 1.7-5+b1

dictionaries-common recommends no packages.

Versions of packages dictionaries-common suggests:
ii  aspell0.60.7~20110707-1
ii  emacsen-common2.0.5
ii  hunspell  1.3.2-6
ii  ispell3.3.02-6
pn  jed-extra none
ii  wamerican [wordlist]  7.1-1

-- debconf information:
  dictionaries-common/old_wordlist_link: true
  dictionaries-common/invalid_debconf_value:
  dictionaries-common/move_old_usr_dict: true
  dictionaries-common/ispell-autobuildhash-message:
* dictionaries-common/default-wordlist: american (American English)
  dictionaries-common/selecting_ispell_wordlist_default:
* dictionaries-common/default-ispell: russian (Russian koi8-r)
  dictionaries-common/remove_old_usr_dict_link: false


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

Bug#739412: dictionaries-common: works slow on very short words at the end of big file

[Aleksey Cherepanov]

Hi,

Oh, I forgot 'flyspell' in the subject:
dictionaries-common: flyspell works slow on very short words at the
end of big file would be more informative. I'm curious if you could
fix it.

On Tue, Feb 18, 2014 at 08:06:29PM +0100, Agustin Martin wrote:
 On Tue, Feb 18, 2014 at 04:07:50PM +0400, Aleksey Cherepanov wrote:
  Package: dictionaries-common
  Version: 1.20.5
  Severity: normal
  
  Dear Maintainer,
  
 * What led up to the situation?
  
  I faced a problem editing my big .org file (2mb+) with flyspell-mode
  enabled. I edit it every day, regularly mistype and get words of one
  or two letters that are wrong in Russian and cause flyspell work slow.
  
  This one-liner produces good file to reproduce the bug.
  perl -e 'print(((join  , (met and) x 10) . \n) x 3)'  t.txt
  
  Typing nd at the end of file gives a huge pause even on a fast
  computer. But mw or md does not give pauses because they are not
  substrings in this file. It is repeatable with emacs -Q.
 
 Hi,
 
 Thanks for the info, I can reproduce it also with emacs-snapshot from FSF
 Emacs trunk. 

Great!

 I'd suggest filing this bug report also to the FSF Emacs bugtracker. This
 way it will have more audience and more people may help.

I just sent it:
16...@debbugs.gnu.org
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16800

 See http://debbugs.gnu.org/Emacs.html for guidelines, in short you are
 suggested to use from Emacs
 
 M-x report-emacs-bug

It is not as friendly as Debian's reportbug.

 and send the bug report from there. Header should then be something like
 
 Package: emacs
 Version: ...

It is very helpful.

Thanks!

-- 
Regards,
Aleksey Cherepanov


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

Bug#727012: rhash: Error value too large for defined data type for big files (4 GB)

[Aleksey Kravchenko]

Thanks for reporting! I will look into the bug :)

21.10.2013 21:14, Mario B. wrote:
 Package: rhash
 Version: 1.2.9-8+deb7u1
 Severity: normal
 
 Dear Maintainer,
 
 rhash does not work with files bigger than 4 GB, and also the version 1.3.0-2
 (on testing and Sid) is affected by the same problem.
 
 Instead md5sum, sha*sum and other tools work as expected.
 
 I don't know if it is a problem of the 32-bit architecture. There is a bug
 report for the upstream version of this program with a similar bug, but it has
 been reported as closed with the version 1.2.9:
 
 sourceforge.net/p/rhash/bugs/34
 
 
 Input:
 
 $ rhash bigfile.ext
 
 
 Output:
 
 ; Generated by RHash v1.2.9 on 2013-10-21 at 16:10.17
 ; Written by Aleksey (Akademgorodok) - http://rhash.sourceforge.net/
 ;
 RHash: bigfile.ext: Value too large for defined data type
 
 
 Thanks for the attention.
 
 
 -- System Information:
 Debian Release: 7.2
   APT prefers stable-updates
   APT policy: (990, 'stable-updates'), (990, 'stable'), (550, 'testing'), 
 (500, 'unstable')
 Architecture: i386 (i686)
 
 Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash
 
 Versions of packages rhash depends on:
 ii  libc6  2.17-93
 ii  librhash0  1.2.9-8+deb7u1
 
 Versions of packages rhash recommends:
 ii  libssl1.0.0  1.0.1e-2
 
 rhash suggests no packages.
 
 -- no debconf information
 



signature.asc
Description: OpenPGP digital signature

Bug#726540: zip: zip - file out creates broken archive

[Aleksey Morarash]

Package: zip
Version: 3.0-6
Severity: normal

Dear Maintainer,

A have encountered that zip fails to write correct archive to
a pipe when its opened with O_APPEND option.

For example, this will create broken archive:

$ zip - file  outfile

When this one works as planned:

$ zip - file | cat  outfile

I found that zip makes lseeks while writing the archive file, but
it doesn't change its behavior while writing to the file opened with
the O_APPEND option.


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

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

Versions of packages zip depends on:
ii  libbz2-1.0  1.0.6-4
ii  libc6   2.17-92+b1

Versions of packages zip recommends:
ii  unzip  6.0-8

zip 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#726540: [tuxo...@gmail.com: Re: Bug#726540: zip: zip - file out creates broken archive]

[Aleksey Morarash]

No, just packaging Erlang applications into zipped Erlang script
executable.

Its format can be described in next shell-script:

( echo '#!/usr/bin/env escript'
  echo '%%!-smp'
  zip -j - ebin/*; )  target
chmod 755 target

But it works only when I add | cat after zip invocation:

( echo '#!/usr/bin/env escript'
  echo '%%!-smp'
  zip -j - ebin/* | cat; )  target
chmod 755 target

-- 

Best regards, Aleksey Morarash
e-mail: tuxo...@gmail.com


signature.asc
Description: Digital signature

Bug#552032: Two ways of improving

[Aleksey Dobrunov]

Hi.
stupid problem. a lot of time taken away.
the main problem is not in Ant. it is in the xerces 2.
two options fixes
1. build xerces from the trunk. it works for me. but I do not know what
kind of correction affected.
2. edit /usr/share/ant/bin/ant, by removing the substring
/usr/share/java/xmlParserAPIs.jar :/usr/share/java/xercesImpl.jar (roll
back the patch 0003-add-Xerces-from-Debian-s-path.patch).

Aleksey Dobrunov

Bug#712414: I can confirm this bug

[Aleksey I Zavilohin]

after upgrade to 2.2.1-8+deb7u1 stop working udp server

my config

...
server-bridge 10.1.2.1 255.255.255.0 10.1.2.10 10.1.2.99
ifconfig 10.1.2.1 255.255.255.0
port 1194
multihome
dev tap2
max-clients 20
persist-key
persist-tun
persist-local-ip
persist-remote-ip
user proxy
group proxy
comp-lzo adaptive
fast-io
client-to-client
proto udp
keepalive 60 180
passtos
ca /etc/openvpn/x/pki/keys/ca.crt
cert /etc/openvpn/x/pki/keys/sukhorukov.crt
key /etc/openvpn/x/pki/keys/sukhorukov.key
dh /etc/openvpn/x/pki/keys/dh1024.pem
crl-verify /etc/openvpn/x/crl.pem
status-version 2
script-security 2
push dhcp-option DNS 192.168.10.254
push route 192.168.10.0 255.255.255.0 10.1.2.1
management 127.0.0.1 8991 /etc/openvpn/x/passwd
ifconfig-pool-persist /etc/openvpn/x/ipp-udp.txt
...



--
What we Are is God's gift to us.
What we Become is our gift to God.


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

Bug#712414: I can confirm this bug

[Aleksey I Zavilohin]

17.06.2013 14:23, Alberto Gonzalez Iniesta пишет:

On Mon, Jun 17, 2013 at 01:00:23PM +0600, Aleksey I Zavilohin wrote:

after upgrade to 2.2.1-8+deb7u1 stop working udp server



Hi Aleksey,

Did this happen with all clients? Which client versions are you running?




yes, for all clients.

Different: i can`t check all client. I think 2.1.x and securepoint ssl 
vpn (packed with openvpn client 2.2.2) - from my side.



--
The IBM purchase of ROLM gives new meaning to the term twisted pair.
-- Howard Anderson, Yankee Group


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

Bug#709490: Two disastrous bugs in RHash in Wheezy

[Aleksey]

Hello!

The debdiff is attached. It's the minimum patch fixing these two nasty
bugs. :)


28.05.2013 3:27, Adam D. Barratt wrote:
 On Fri, 2013-05-24 at 15:08 +0700, Aleksey K. wrote:
 Sorry, I've mean proposed-updates for a point release. I've already
 contacted security team, and was forwarded here :)
 Okay.
 There is a package (RHash 1.2.9-9) in Sid with these patches. It
 should be easy to make debdiff. But since I have very little of free
 time now, it can take several days :-/
 In case there was any confusion, I meant a debdiff between the current
 rhash package in wheezy and the package you'd like to upload containing
 the fixes (which would be 1.2.9-8+deb7u1). We can't simply copy the
 existing package from sid; the debdiff also has the advantage of meaning
 you've built (and preferably tested) the package at least once. :-)

 Regards,

 Adam


diff -Nru rhash-1.2.9/debian/changelog rhash-1.2.9/debian/changelog
--- rhash-1.2.9/debian/changelog2012-11-28 23:39:41.0 +0700
+++ rhash-1.2.9/debian/changelog2013-05-31 01:17:54.0 +0700
@@ -1,3 +1,11 @@
+rhash (1.2.9-8+deb7u1) stable; urgency=medium
+
+  * Backported two critical bug fixes from RHash 1.2.10
+- fix incorrect SHA-512 for messages of certain size
+- fix incorrect GOST hash on non-x86/amd64 CPUs
+
+ -- Aleksey Kravchenko rhash.ad...@gmail.com  Thu, 30 May 2013 22:34:57 +0700
+
 rhash (1.2.9-8) unstable; urgency=medium
 
   [ Aleksey Kravchenko ]
diff -Nru rhash-1.2.9/debian/patches/03_fix_sha512_and_gost.patch 
rhash-1.2.9/debian/patches/03_fix_sha512_and_gost.patch
--- rhash-1.2.9/debian/patches/03_fix_sha512_and_gost.patch 1970-01-01 
06:00:00.0 +0600
+++ rhash-1.2.9/debian/patches/03_fix_sha512_and_gost.patch 2013-05-31 
01:00:29.0 +0700
@@ -0,0 +1,45 @@
+Description: Fix calculation of SHA-512 and GOST hash
+ This patch backports two critical bug fixes from RHash 1.2.10.
+ SHA-512 was not correctly calculated for files with size
+   112 = (file_size % 128)  120.
+ The bug occurs only when several files are sequentually hashed.
+ .
+ Internal buffer of SHA-512 context was not fully cleared by zeroes,
+ when processing final block of data.
+ See also SF-Bug: https://sourceforge.net/p/rhash/bugs/31/
+ .
+ Also the GOST R 34.11-94 hash was broken on non x86 CPUs
+ on some messages containg sequences of words 0x.
+ The bug does not occur on x86 and x86-64, because
+ on these archs assembly code replaces C.
+
+Author: Aleksey Kravchenko rhash.ad...@gmail.com
+Origin: upstream
+Forwarded: not-needed
+Last-Update: 2013-05-31
+
+--- rhash-1.2.9.orig/librhash/sha512.c
 rhash-1.2.9/librhash/sha512.c
+@@ -238,6 +238,7 @@ void rhash_sha512_final(sha512_ctx *ctx,
+ 
+   /* if no room left in the message to store 64-bit message length */
+   if(index = 15) {
++  if(index == 15) ctx-message[index] = 0;
+   rhash_sha512_process_block(ctx-hash, ctx-message);
+   index = 0;
+   }
+--- rhash-1.2.9.orig/librhash/gost.c
 rhash-1.2.9/librhash/gost.c
+@@ -321,10 +321,10 @@ static void rhash_gost_compute_sum_and_h
+ 
+   /* compute the 256-bit sum */
+   for(i = 0; i  8; i++) {
+-  const unsigned old = ctx-sum[i];
+   LOAD_BLOCK_LE(i);
+   ctx-sum[i] += block_le[i] + carry;
+-  carry = (ctx-sum[i]  old || ctx-sum[i]  block_le[i] ? 1 : 
0);
++  carry = (ctx-sum[i]  block_le[i] ? 1 :
++  ctx-sum[i] == block_le[i] ? carry : 0);
+   }
+ #endif /* USE_GCC_ASM_IA32 */
+ 
diff -Nru rhash-1.2.9/debian/patches/series rhash-1.2.9/debian/patches/series
--- rhash-1.2.9/debian/patches/series   2012-11-28 01:45:27.0 +0700
+++ rhash-1.2.9/debian/patches/series   2013-05-30 23:23:06.0 +0700
@@ -1,2 +1,3 @@
 01_configure-bindings.patch
 02_python_function_prototypes.patch
+03_fix_sha512_and_gost.patch

Bug#709490: Two disastrous bugs in RHash in Wheezy

[Aleksey]

Package: release.debian.org

Dear stable release managers,
The RHash 1.2.9-8 utility in Wheezy contains two security bugs:

1. it incorrectly calculates SHA-512 hash sum for files of certain size;
2. it incorrectly calculates GOST hash on non-x86/amd64 CPUs on certain
messages.

Please accept the fix (see below) into security archive.

In more detail.
1. SHA-512 is incorrectly calculated for files with size
   112 = (file_size % 128)  120.
 The bug occurs only when several files are sequentually hashed.

Internal buffer of SHA-512 context was not fully cleared by zeroes, when
processing final block of data.
See also the related SF-Bug: https://sourceforge.net/p/rhash/bugs/31/

Steps to reproduce:
 perl -e 'print \xffx112'  msg.bin
 rhash --sha512 --openssl= msg.bin msg.bin
Expected output:
91078b0922e575edeb26558219603518141f167d6edeb7dfd56225beddd5482b0ab282d4feccffbe52eeb8fa0eff9b9d331c5fc55ad0d1d4b1b71cb29f2a0060
msg.bin
91078b0922e575edeb26558219603518141f167d6edeb7dfd56225beddd5482b0ab282d4feccffbe52eeb8fa0eff9b9d331c5fc55ad0d1d4b1b71cb29f2a0060
msg.bin

2. Hashes of messages containing byte sequences of 0xFF are incorrectly
calculated on ARM and non-Intel CPU's.

Steps to reproduce (on ARM or non-Intel CPU):
 perl -e 'print \xffx112'  msg.bin
 rhash --gost msg.bin
Expected output:
c6a27541b302df03366345955c0e45be0c6ea8639e4147ec7f37b11eee9e2370  msg.bin

How two fix.
The fix is available as RHash 1.2.9-9 [1] in Testing for some time, so
it should be well tested for now.
This package contain two small patches (see attachments) backported from RHash 
1.2.10.

[1] http://packages.debian.org/testing/rhash

  With best wishes,
  Aleksey




Description: Fix GOST on non x86 CPUs for some specific messages
 The patch fixes GOST hash calculation for some messages containg sequences of
 0x words. The patch also adds two test vectors to check for the bug:
 .
 GOST( 64 of 0xFF ) =
13416C4EC74A63C3EC90CB1748FD462C7572C6C6B41844E48CC1184D1E916098
 GOST-CRYPTOPRO ( 64 of 0xFF ) =
58504D26B3677E756BA3F4A9FD2F14B3BA5457066A4AA1D700659B90DCDDD3C6
 .
 Those test vectors can be verified by OpenSSL console utility 'gostsum'.
 The bug does not occur on x86 and x86-64, because on these  archs
 assembly code replaces C.

Author: Aleksey Kravchenko rhash.ad...@gmail.com
Origin: upstream https://github.com/rhash/RHash/commit/d2f4378043d13f5e61ef408eb2c7bf021feb1b69
Forwarded: not-needed
Last-Update: 2012-12-31

---
 librhash/gost.c| 4 ++--
 librhash/test_hashes.c | 4 +++-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/librhash/gost.c b/librhash/gost.c
index 0d1612c..a6d8404 100644
--- a/librhash/gost.c
+++ b/librhash/gost.c
@@ -325,10 +325,10 @@ static void rhash_gost_compute_sum_and_hash(gost_ctx * ctx, const unsigned* bloc
 
 	/* compute the 256-bit sum */
 	for(i = 0; i  8; i++) {
-		const unsigned old = ctx-sum[i];
 		LOAD_BLOCK_LE(i);
 		ctx-sum[i] += block_le[i] + carry;
-		carry = (ctx-sum[i]  old || ctx-sum[i]  block_le[i] ? 1 : 0);
+		carry = (ctx-sum[i]  block_le[i] ? 1 :
+			ctx-sum[i] == block_le[i] ? carry : 0);
 	}
 #endif /* USE_GCC_ASM_IA32 */
 
diff --git a/librhash/test_hashes.c b/librhash/test_hashes.c
index e712493..85bdbdd 100644
--- a/librhash/test_hashes.c
+++ b/librhash/test_hashes.c
@@ -605,7 +605,9 @@ static void test_long_strings(void)
 		assert_rep_hash(tests[count].hash_id, 'a', 100, tests[count].expected_hash);
 	}
 
-	/* note: it would be better to check with more complex pre-generated messages */
+	/* now we verify some specific cases */
+	assert_rep_hash(RHASH_GOST, 0xFF, 64, 13416C4EC74A63C3EC90CB1748FD462C7572C6C6B41844E48CC1184D1E916098);
+	assert_rep_hash(RHASH_GOST_CRYPTOPRO, 0xFF, 64, 58504D26B3677E756BA3F4A9FD2F14B3BA5457066A4AA1D700659B90DCDDD3C6);
 
 	/* these messages verified by eMule LinkCreator (which uses eMule variant of ED2K hash) */
 	assert_rep_hash(RHASH_ED2K, 0, 9728000, FC21D9AF828F92A8DF64BEAC3357425D);
-- 
Description: Fix incorrect claculation of SHA-512 for some files
 SHA-512 was not correctly calculated for files with size
   112 = (file_size % 128)  120.
 The bug occurs only when several files are sequentually hashed.
 .
 Internal buffer of SHA-512 context was not fully cleared by zeroes,
 when processing final block of data.
 See also SF-Bug: https://sourceforge.net/p/rhash/bugs/31/

Author: Aleksey Kravchenko rhash.ad...@gmail.com
Origin: upstream https://github.com/rhash/RHash/commit/43acddb523a94ddc5207449e9560a504faa26e68
Forwarded: not-needed
Last-Update: 2012-12-31

---
 librhash/sha512.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/librhash/sha512.c b/librhash/sha512.c
index 0999e72..7eb55d3 100644
--- a/librhash/sha512.c
+++ b/librhash/sha512.c
@@ -238,6 +238,7 @@ void rhash_sha512_final(sha512_ctx *ctx, unsigned char* result)
 
 	/* if no room left in the message to store 64-bit message length */
 	if(index = 15) {
+		if(index == 15) ctx-message[index] = 0;
 		rhash_sha512_process_block(ctx-hash, ctx

Bug#708117: hal segmentation fault after upgrade

[Aleksey Midenkov]

Package: hal
Version: 0.5.14-8
Severity: important


After upgrading from 0.5.14-4 I've got hal failing to start with core
dump. Sorry, hadn't saved screen output, but this doesn't matter. I've
compiled debug version and found the source of core. But this is not
the most important issue. More important is, that user have no clue of
what to do with such kind of problem. More useful message should be
printed, as done in patch.

The source of core was broken fdi cache. I don't know, why it got
broken, but I've fixed my with:

mkdir /etc/hal/fdi/preprobe
rm /var/cache/hald/fdi-cache
/usr/lib/hal/hald-generate-fdi-cache

The behavior of software is very fragile, because it refuses to work
in absence of some directories. Maybe this was the source of broken
cache...

P.S. I know that HAL is deprecated. But this is not the reason for
leaving users sinking in a swamp of inaccuracy. Please, forward this
patch to upstream if applicable.


70-core-fix.patch
Description: Binary data

Bug#695852: unblock: rhash/1.2.9-8

[Aleksey Kravchenko]

Dear release team,

It's the best time to unblock current stable rhash/1.2.9-8 now [1],
cause I'm going to upload RHash release 1.2.10 to NEW with new features
(e.g. php bindings). After it go through NEW, the next chance for
unblocking will be only after 10 day period and when all rhash* packages
smoothly compile on all platforms.

  With best wishes,
  Aleksey Kravchenko
  Maintainer of RHash package.

[1] http://bugs.debian.org/695852



signature.asc
Description: OpenPGP digital signature

Bug#695063: cli-common-dev: dh_cligacpolicy reports false warning on cli-common-dev version

[Aleksey Kravchenko]

Package: cli-common-dev
Version: 0.8.2
Severity: normal
Tags: patch

if a package Build-Depends on cli-common-dev (= 0.8~),
then dh_cligacpolicy reports wrong warning:
Warning! No Build-Depends(-Indep) on cli-common-dev (= 0.5.7)!

The attached patch fixes the bug by replacing the condition with more proper
one.



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

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

Versions of packages cli-common-dev depends on:
ii  debhelper  9.20120909
ii  libxml-dom-perl1.44-1
ii  mono-devel [strong-name-tool]  2.10.8.1-6
ii  mono-utils [cil-disassembler]  2.10.8.1-6
ii  perl-modules   5.14.2-15

cli-common-dev recommends no packages.

cli-common-dev suggests no packages.

-- no debconf information

--- dh_cligacpolicy.orig	2012-12-03 23:47:23.0 +0700
+++ dh_cligacpolicy	2012-12-03 23:48:54.772722367 +0700
@@ -87,7 +87,8 @@
   open(FILE, 'debian/control');
   my @filedata = FILE;
   close(FILE);
-  if (!($filedata[0] =~ /Build-Depends(-Indep)?: .*cli-common-dev \(= 0\.5\.7\)/)) {
+  if ($filedata[0] =~ m/Build-Depends(?:\-Indep)?\:(?:.*\n\s+)*.*cli\-common\-dev\s*\(=\s*([^\)]+)\)/ 
+  system(dpkg, --compare-versions, $1, =, 0.5.7) != 0) {
   warning(Warning! No Build-Depends(-Indep) on cli-common-dev (= 0.5.7)!);
   }
 }



signature.asc
Description: OpenPGP digital signature

Bug#687398: rhash: diff for NMU version 1.2.9-7.1

[Aleksey Kravchenko]

Gentlemen,
thank you for investigating such twisted issue!

When building in parallel, sometime librhash.a was created prior to
librhash.so and rhash_shared binary.
The command 'mv rhash_shared rhash' preserved timestamp.
Then wrong static 'rhash' binary was re-built by command 'make test' (as
required by Makefile dependencies) but without all necessary CFLAGS.
That led to linker error.

The bug can be fixed by changing 'mv rhash_shared rhash' line to
 'cp rhash_shared rhash'
or
 'mv rhash_shared rhash  touch rhash'.

I'm preparing a package with the fix and will upload it to ftpmaster asap.

26.11.2012 0:09, Michael Banck wrote:
 Hi,
 
 On Sun, Nov 25, 2012 at 05:31:55PM +0100, Michael Banck wrote:
 On Fri, Nov 02, 2012 at 05:13:57PM +0100, gregor herrmann wrote:
 Ok, NMU cancelled until this is sorted out ...

 For the record, I tried a build of Gregor's NMU patch using sbuild and
 DEB_BUILD_OPTIONS=parallel=4 on both i386 and amd64 and they both worked
 fine.
 
 Ok, in an i386 chroot on my amd64 machine I can reproduce this as
 well, just not every time...
 
 
 Michael
 



signature.asc
Description: OpenPGP digital signature

Bug#693809: libtimedate-perl: wrong offset for MSK timezone

[Aleksey Midenkov]

Package: libtimedate-perl
Version: 1.2000-1
Severity: important
Tags: patch

Please, fix Zone.pm for MSK time zone from +3 to +4:

msk   =  +4*3600, # Moscow


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

Bug#693624: agda: Please package agda 2.3.2

[Aleksey Kliger]

Package: agda
Version: 2.3.0.1-2
Severity: wishlist

Upstream Agda 2.3.2 is available.  Please consider packaging it for Debian.


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable'), (499, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages agda depends on:
ii  agda-bin 2.3.0.1-1
ii  agda-mode2.3.0.1-2
ii  agda-stdlib  0.6-2
ii  agda-stdlib-doc  0.6-2
ii  libghc-agda-dev  2.3.0.1-2+b1

agda recommends no packages.

agda 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#689410: grep: character classes do not work with non-ASCII 8-bit locale

[Aleksey Cheusov]

Package: grep
Version: 2.6.3-3
Severity: normal
Tags: upstream


character classes do not work with non-ASCII 8-bit locale.
Typescript is below. GNU awk works correctly.
\335 is an uppercased cyrillic letter.

   $ locale -a | grep ru_RU.cp1251
   ru_RU.cp1251
   $ printf '\335' | LC_CTYPE=ru_RU.cp1251 grep '[[:upper:]]' | wc -l
   0
   $ printf '\335' | LC_CTYPE=ru_RU.cp1251 gawk '/[[:upper:]]/' | wc -l
   1
   $

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

Kernel: Linux 2.6.32-5-486
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages grep depends on:
ii  dpkg  1.15.8.13  Debian package management system
ii  install-info  4.13a.dfsg.1-6 Manage installed documentation in 
ii  libc6 2.11.3-4   Embedded GNU C Library: Shared lib

grep recommends no packages.

Versions of packages grep suggests:
ii  libpcre3  8.02-1.1   Perl 5 Compatible Regular Expressi

-- 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#564251: function dictem-run marked as interactive - crashed.

[Aleksey Cheusov]

 
  With C-x dictem-run RET get in *Message*:
 
  call-interactively: Wrong number of arguments: (lambda (search-fun
  optional database query strategy) Creates new *dictem* buffer and
 
  As manual says dictem-run function requires at least one argument. So
  this is a documented behaviour. Or you are saying that I have to remove
  (interactive) from function definition?
 
 May be yes?

 I type M-x dictem- TAB and see dictem-run, nice name, so I run it.
 Why see that I can not run?

JFYI. I've just released dictem-1.0.4 where this bug has been fixed.

-- 
Best regards, Aleksey Cheusov.


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

Bug#681943: dictem: Dictem gives ERROR when reuse a db

[Aleksey Cheusov]

This bug should be fixed in dictem-1.0.3.
The problem appeared when dictem-use-user-databases-only is set to t.

-- 
Best regards, Aleksey Cheusov.


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

Bug#677868: /usr/bin/dictl: incorrect handling of apostrophe

[Aleksey Cheusov]

 dictl (unlike dict) does not handle apostrophe correctly:
 
 % dictl won't
 /usr/bin/dictl: 1: eval: Syntax error: Unterminated quoted string
 
 
 This means arbitrary code execution if dictl is used in a script
 accepting untrusted data (but dictl is not suitable for such scripts
 anyway due to lack of -- argument support):
 
 % dictl -- asdfasdf';echo qqq;beep;':
 No definitions found for asdfasdf
 qqq

Fixed in upstream a bit differently.
http://dict.cvs.sourceforge.net/viewvc/dict/dictd1/dictl.in?r1=1.14r2=1.15

Thanks a lot!

-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de



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

Bug#674488: Problem still exists in latest snapshot of 28 May

[Aleksey Zapparov]

Just got the same problem on my laptop with the CD of 28th of may.

Bug#674488: Info received (Problem still exists in latest snapshot of 28 May)

[Aleksey Zapparov]

Just tried with today's snapshot. Bug still exist
On Jun 2, 2012 6:48 PM, Debian Bug Tracking System ow...@bugs.debian.org
wrote:

 Thank you for the additional information you have supplied regarding
 this Bug report.

 This is an automatically generated reply to let you know your message
 has been received.

 Your message is being forwarded to the package maintainers and other
 interested parties for their attention; they will reply in due course.

 Your message has been sent to the package maintainer(s):
  Debian CD-ROM Team debian...@lists.debian.org

 If you wish to submit further information on this problem, please
 send it to 674...@bugs.debian.org.

 Please do not send mail to ow...@bugs.debian.org unless you wish
 to report a problem with the Bug-tracking system.

 --
 674488: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674488
 Debian Bug Tracking System
 Contact ow...@bugs.debian.org with problems

Bug#671989: rhash: FTBFS: make[3]: *** No targets specified and no makefile found. Stop.

[Aleksey Kravchenko]

Thanks for reporting! :)

The bug occurred due to parallel build. The debian/rules command
 $(MAKE) -C bindings configure build
caused the 'make -C ruby' to run earler then Ruby Makefile was created
by the 'ruby -C ruby extconf.rb' command.



signature.asc
Description: OpenPGP digital signature

Bug#670205: rhash: FTBFS in binary-only mode: dh: unable to load addon cli

[Aleksey Kravchenko]

The problem can be reproduced by 'debuild binary-arch'
with cli-common-dev package uninstalled.

The proper fix (building arch-dependent packages only when requested),
requires complicated debian/rules (attached) with many conditionals.

This complicated script is hard to read, so I'll just move mono
dependencies to Build-Depends.

It looks like there is another way [1] to solve the bug, which utilizes
dh_listpackages:
===8===
ifeq ($(shell dh_listpackages | grep -q cil  echo yes),yes)
DHWITH = --with cli
endif
%:
   dh $@ $(DHWITH)
===8===
But in reality it doesn't work: when running 'debuild binary-arch' the
dh_listpackages prints all packages, including ones with
'Architecture: all'.

[1] http://mail-archive.com/debian-cli@lists.debian.org/msg00103.html

24.04.2012 7:55, Aaron M. Ucko wrote:
 Source: rhash
 Version: 1.2.9-1
 Severity: serious
 Justification: fails to build from source (but built successfully in the past)
 
 Builds of rhash in minimal environments covering only its
 architecture-dependent packages (with Build-Depends but not
 necessarily Build-Depends-Indep available) are failing:
 
fakeroot debian/rules clean
   dh clean --with=python2 --with=cli
   dh: unable to load addon cli: Can't locate Debian/Debhelper/Sequence/cli.pm 
 in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 
 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 
 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at (eval 
 4) line 2.
   BEGIN failed--compilation aborted at (eval 4) line 2.
   
   make: *** [clean] Error 2
 
 Please either move cli-common-dev to Build-Depends or arrange to pass
 --with=cli only when it is actually safe to do so.
 
 Thanks!
#!/usr/bin/make -f
# debian/rules makefile that uses debhelper.
#
# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1
INSTALL_PROGRAM = install -p -m 755
CFLAGS = -Wall -DUSE_GETTEXT
LIBCFLAGS =
LIBLDFLAGS =
DESTDIR = $(CURDIR)/debian/tmp
LIBRHASH_INC=-I$(DESTDIR)
LIBRHASH_LD=-Wl,--as-needed -L$(DESTDIR)
JAVADOC_API_URL=/usr/share/doc/default-jdk-doc/api

# see Debian Policy Manual - source packages
ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
CFLAGS += -O0 -DNDEBUG
else
CFLAGS += -O2 -DNDEBUG -fomit-frame-pointer
endif
ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
CFLAGS += -g
endif
ifneq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
INSTALL_PROGRAM += -s
endif
ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
NUMJOBS = $(patsubst parallel=%,%,$(filter 
parallel=%,$(DEB_BUILD_OPTIONS)))
MAKEFLAGS += -j$(NUMJOBS)
endif

# by default compile RHash with openssl runtime linking
ifeq (,$(findstring nossl,$(DEB_BUILD_OPTIONS)))
LIBCFLAGS += -DUSE_OPENSSL
ifneq (,$(findstring ssldynamic,$(DEB_BUILD_OPTIONS)))
LIBLDFLAGS += -lcrypto
else
LIBCFLAGS  += -DOPENSSL_RUNTIME -rdynamic
LIBLDFLAGS += -ldl
endif
endif

# using debhelper = 8 to build the package

# we use this intricate logic to allow 'debuild binary-indep' without mono 
packages installed
build:
BUILDARCH=all dh $@ --with=python2 --with=cli

binary:
BUILDARCH=all dh $@ --with=python2 --with=cli

binary-arch:
BUILDARCH=arch dh $@

# only arch-independent packages really need python2 and cli
binary-indep:
BUILDARCH=indep dh $@ --with=python2 --with=cli

%:
BUILDARCH=indep dh $@

# bindings to provide
ifeq ($(BUILDARCH),all)
BINDINGS = java mono perl python ruby
else ifeq ($(BUILDARCH),arch)
BINDINGS = java perl ruby
else
BINDINGS = java mono python
endif
ifneq ($(LD_LIBRARY_PATH),)
LD_LIB=$(DESTDIR):$(LD_LIBRARY_PATH)
else
LD_LIB=$(DESTDIR)
endif

override_dh_auto_build:
# Compile the package.
$(MAKE) lib-static lib-shared LIBCFLAGS=$(CFLAGS) $(LIBCFLAGS) 
LIBLDFLAGS=$(LIBLDFLAGS)
ifneq ($(BUILDARCH),indep)
$(MAKE) rhash-shared CFLAGS=$(CFLAGS) SHARED_TRG=rhash
endif
# prepare local librhash include/lib directories
mkdir -p $(DESTDIR)  ln -fs $(CURDIR)/librhash $(DESTDIR)/rhash
ln -fs $(CURDIR)/librhash/librhash.so.0 $(DESTDIR)/  ln -fs 
$(DESTDIR)/librhash.so.0 $(DESTDIR)/librhash.so
# Compile language bindings.
$(MAKE) -C bindings configure build 
JAVADOC_API_URL=$(JAVADOC_API_URL) \
LIBRHASH_INC=$(LIBRHASH_INC) LIBRHASH_LD=$(LIBRHASH_LD) 
BINDINGS=$(BINDINGS)
ifneq ($(BUILDARCH),indep)
chrpath -d bindings/perl/blib/arch/auto/Rhash/Rhash.so
endif

override_dh_auto_test:
ifneq ($(BUILDARCH),indep)
$(MAKE) test-lib test-shared CFLAGS=$(CFLAGS) \
LIBLDFLAGS=$(LIBLDFLAGS) SHARED_TRG=rhash
endif
$(MAKE) -C bindings test LD_LIBRARY_PATH=$(LD_LIB) 
BINDINGS=$(BINDINGS)

override_dh_auto_install:
ifneq ($(BUILDARCH),indep)
# Install the program and its translation strings
$(MAKE) PREFIX=/usr 

Bug#663336: shnsplit: can't be forced to split with no split points given

[Aleksey Sergushichev]

Package: shntool
Version: 3.0.7-1
Severity: normal
Tags: patch


I want to be able to use shntool split even if there is no split points
(i.e. there is only one track in cue sheet) but I can't. It's not so
pointless as it may seem to be - this may be useful when running
cue2tracks script for multiple albums and some of them may contain only
one track.

The patch introduces flag -F to force splitting:
--- src/mode_split.c2008-02-19 02:25:14.0 +0300
+++ src/mode_split.c2012-03-10 16:58:44.0 +0400
@@ -57,6 +57,7 @@
 static char *leadout = NULL;
 static char *extract_tracks = NULL;
 static char *manipulate_chars = NULL;
+static int force_split = 0;
 
 typedef struct _cue_info {
   /* global */
@@ -101,6 +102,7 @@
   st_info(  (%%p = performer, %%a = album, %%t = track title, %%n = 
track number)\n);
   st_info(  -u len  postfix each track with len amount of lead-out from next 
track (*)\n);
   st_info(  -x list only extract tracks in list (comma-separated, may contain 
ranges)\n);
+  st_info(  -F force split even if no split points are given (outputs one 
file)\n);
   st_info(\n);
   st_info(  (*) len must be in bytes, m:ss, m:ss.ff or m:ss.nnn 
format\n);
   st_info(\n);
@@ -116,7 +118,7 @@
   st_ops.output_prefix = SPLIT_PREFIX;
   cueinfo.format = NULL;
 
-  while ((c = st_getopt(argc,argv,c:e:f:l:n:m:t:u:x:)) != -1) {
+  while ((c = st_getopt(argc,argv,c:e:f:l:n:m:t:u:x:F)) != -1) {
 switch (c) {
   case 'c':
 if (NULL == optarg)
@@ -168,6 +170,9 @@
   st_error(missing track numbers to extract);
 extract_tracks = optarg;
 break;
+  case 'F':
+force_split = 1;
+break;
 }
   }
 
@@ -736,8 +741,14 @@
   if (split_point_file)
 fclose(fd);
 
-  if (1 == numfiles)
-st_error(no split points given -- nothing to do);
+  if (1 == numfiles) {
+if (force_split) {
+  st_warning(no split points given);
+} 
+else {
+  st_error(no split points given -- nothing to do);
+}
+  }
 
   if (SPLIT_INPUT_CUE == input_type  cueinfo.format) {
 if (cueinfo.trackno  numfiles)
@@ -860,16 +871,16 @@
   else
 read_split_points_file(info);
 
-  if (files[numfiles-2]-beginning_byte  info-data_size)
+  if (numfiles  1  files[numfiles-2]-beginning_byte  info-data_size)
 st_error(split points go beyond input file's data size);
 
-  if (files[numfiles-2]-beginning_byte == info-data_size) {
+  if (numfiles  1  files[numfiles-2]-beginning_byte == info-data_size) {
 st_free(files[numfiles-1]);
 numfiles--;
   }
   else {
 files[numfiles-1]-beginning_byte = info-data_size;
-files[numfiles-1]-data_size = info-data_size - 
files[numfiles-2]-beginning_byte;
+files[numfiles-1]-data_size = info-data_size - (numfiles  1 ? 
files[numfiles-2]-beginning_byte : 0);
 
 adjust_splitfile(numfiles-1);
   }


-- System Information:
Debian Release: 6.0.3
  APT prefers stable
  APT policy: (700, 'stable'), (400, 'testing'), (100, 'unstable'), (1, 
'experimental')
Architecture: i386 (i686)

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

Versions of packages shntool depends on:
ii  libc6 2.13-21Embedded GNU C Library: Shared lib

shntool recommends no packages.

Versions of packages shntool suggests:
ii  cuetools 1.3.1-9 tools for manipulating CUE/TOC fil
ii  flac 1.2.1-2+b1  Free Lossless Audio Codec - comman
ii  sox  14.3.2-2+b1 Swiss army knife of sound processi

-- 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#657197: dictd: 'man dictd' typos: configuarion, faility, inaccesible, informarion, preffered prepanded.

[Aleksey Cheusov]

 Found some typos in '/usr/share/man/man8/dictd.8.gz', see attached '.diff'.

 Hope this helps...

Applied in upstream. Thanks!

-- 
Best regards, Aleksey Cheusov.



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

Bug#658087: apache2 with php5-xsl module failed to start after latest security fixes

[Aleksey I Zavilohin]

Package: php5-xsl
Version: 5.2.6.dfsg.1-1+lenny14
Severity: important



After upgrade php5-xsl to version 5.2.6.dfsg.1-1+lenny14 - i see in error.log 
next message
...
/usr/sbin/apache2: symbol lookup error: /usr/lib/php5/20060613+lfs/xsl.so: 
undefined symbol: INI_INT
...
and php5-xsl module stop working, i think this regression with patch and 
current version

http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/xsl/xsltprocessor.c?r1=317759r2=317758pathrev=317759

+   secPrefsIni = INI_INT(xsl.security_prefs);


-- System Information:
Debian Release: 5.0.9
  APT prefers oldstable-proposed-updates
  APT policy: (500, 'oldstable-proposed-updates'), (500, 'oldstable')
Architecture: i386 (i686)

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

Versions of packages php5-xsl depends on:
ii  libapache2-mod-ph 5.2.6.dfsg.1-1+lenny14 server-side, HTML-embedded scripti
ii  libc6 2.7-18lenny7   GNU C Library: Shared libraries
ii  libxml2   2.6.32.dfsg-5+lenny5   GNOME XML library
ii  libxslt1.11.1.24-2   XSLT processing library - runtime 
ii  php5-common   5.2.6.dfsg.1-1+lenny14 Common files for packages built fr

php5-xsl recommends no packages.

php5-xsl suggests no packages.

-- debconf-show failed



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

Bug#657327: malloc(): memory corruption

[Aleksey Midenkov]

Package: libgstreamer0.10-0
Version: 0.10.35.2-1ubuntu1
Severity: important

Start subtitleeditor 0.39.0-2
Run Video - Open
Open some AVI. Program should abort with something like backtrace below.

Downgrade libgstreamer0.10-0 to version 0.10.35-1 and the bug will go off.
The backtrace shows the problem in libgstreamermm-0.10.so.2 but
nevertheless the bug is in libgstreamer0.10-0. I had another backtrace
with libgstreamer0.10-0 in focus, but then downgraded/upgraded some
packages. Downgrading exactly libgstreamer0.10-0 helps.
I know I'm on Ubuntu, but you guys probably should forward this bug to
upstream anyway. Thanks!

--- Backtrace ---
subtitleeditor
The messenger is now down
An IOException occurred at scim_bridge_client_imcontext_set_cursor_location ()
*** glibc detected *** subtitleeditor: malloc(): memory corruption
(fast): 0x014d2bb0 ***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x7c8f6)[0x7f3627d998f6]
/lib/x86_64-linux-gnu/libc.so.6(+0x7eb2c)[0x7f3627d9bb2c]
/lib/x86_64-linux-gnu/libc.so.6(__libc_calloc+0xc2)[0x7f3627d9e8f2]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_malloc0+0x21)[0x7f3628ac3631]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_param_spec_pool_list+0x8d)[0x7f3628f883fd]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x12294)[0x7f3628f80294]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x2963b)[0x7f3628f9763b]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_type_class_ref+0x55c)[0x7f3628f9a61c]
/usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1(_ZN4Glib15ConstructParamsC2ERKNS_5ClassEPKcz+0xb7)[0x7f3629203a77]
/usr/lib/libgstreamermm-0.10.so.2(_ZN3Gst8PlayBin2C1ERKN4Glib7ustringE+0x7c)[0x7f362b3e1b6c]
/usr/lib/libgstreamermm-0.10.so.2(_ZN3Gst8PlayBin26createERKN4Glib7ustringE+0x31)[0x7f362b3e23f1]
subtitleeditor[0x423e8a]
subtitleeditor[0x424459]
/usr/lib/subtitleeditor/plugins/actions/libvideoplayermanagement.so(_ZN21VideoPlayerManagement7on_openEv+0x65)[0x7f3615bec995]
/usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1(_ZN4Glib17SignalProxyNormal19slot0_void_callbackEP8_GObjectPv+0x28)[0x7f36292055f8]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_closure_invoke+0x154)[0x7f3628f7d364]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x1f8f3)[0x7f3628f8d8f3]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x60b)[0x7f3628f94feb]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x82)[0x7f3628f951b2]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x75213)[0x7f362996e213]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_closure_invoke+0x154)[0x7f3628f7d364]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x1f9fa)[0x7f3628f8d9fa]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x60b)[0x7f3628f94feb]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x82)[0x7f3628f951b2]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(gtk_widget_activate+0x6e)[0x7f3629b48dae]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(gtk_menu_shell_activate_item+0xfd)[0x7f3629a43f6d]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x14b305)[0x7f3629a44305]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x136c68)[0x7f3629a2fc68]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_closure_invoke+0x154)[0x7f3628f7d364]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x1fbfa)[0x7f3628f8dbfa]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x4ed)[0x7f3628f94ecd]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x82)[0x7f3628f951b2]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x250bb1)[0x7f3629b49bb1]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(gtk_propagate_event+0xc3)[0x7f3629a2de23]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(gtk_main_do_event+0x283)[0x7f3629a2e183]
/usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0(+0x5bfac)[0x7f362947efac]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x16a)[0x7f3628abd7da]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x47ba0)[0x7f3628abdba0]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_loop_run+0x6a)[0x7f3628abdf9a]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(gtk_main+0xa7)[0x7f3629a2d1b7]
/usr/lib/x86_64-linux-gnu/libgtkmm-2.4.so.1(_ZN3Gtk4Main3runERNS_6WindowE+0x106)[0x7f362a8b5326]
subtitleeditor[0x415212]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7f3627d3e30d]
subtitleeditor[0x415ac5]
=== Memory map: 
0040-0044e000 r-xp  08:05 142368
  /usr/bin/subtitleeditor
0064d000-0064e000 r--p 0004d000 08:05 142368
  /usr/bin/subtitleeditor
0064e000-0065 rw-p 0004e000 08:05 142368
  /usr/bin/subtitleeditor
0065-00651000 rw-p  00:00 0
00ba2000-0151b000 rw-p  00:00 0  [heap]
7f360a7fd000-7f360a7fe000 ---p  00:00 0
7f360a7fe000-7f360affe000 rw-p  00:00 0
7f360affe000-7f360afff000 ---p  00:00 0
7f360afff000-7f360b7ff000 rw-p  00:00 0
7f360b7ff000-7f360b80 ---p  00:00 0
7f360b80-7f360c00 rw-p  00:00 0
7f360c00-7f360c022000 rw-p 

Bug#654180: rhash: FTBFS with ld --as-needed

[Aleksey Kravchenko]

Hello!

There is already a patch [1] in the upstream source tree, solving this
problem. It fixes compilation on Ubuntu and allows using the --as-needed
option.

The upstream fix will be included in the nearest package release.

[1]
https://github.com/rhash/RHash/commit/1e98cb8bc2a525e7da9ef8e13505f53d1f87f20c

02.01.2012 15:33, Ilya Barygin wrote:
 Package: rhash
 Version: 1.2.8-2
 Severity: normal
 Tags: upstream patch
 User: debian-...@lists.debian.org
 Usertags: ld-as-needed
 
 rhash fails to build when --as-needed linker option is enabled,
 because of incorrect order of parameters passed to ld. As a result,
 librhash-jni.so was underlinked and tests failed.
 Here's a log of failed build in Ubuntu:
 https://launchpad.net/ubuntu/+source/rhash/1.2.8-2/+build/3003545/+files/buildlog_ubuntu-precise-i386.rhash_1.2.8-2_FAILEDTOBUILD.txt.gz
 
 See also
 http://wiki.debian.org/ToolChain/DSOLinking#Only_link_with_needed_libraries
 http://wiki.mandriva.com/en/Underlinking
 
 Patch from Ubuntu attached.
 https://launchpad.net/ubuntu/+source/rhash/1.2.8-2ubuntu1
 
 -- System Information:
 Debian Release: wheezy/sid
   APT prefers oneiric-updates
   APT policy: (500, 'oneiric-updates'), (500, 'oneiric-security'), (500, 
 'oneiric-proposed'), (500, 'oneiric'), (100, 'oneiric-backports')
 Architecture: i386 (i686)
 
 Kernel: Linux 3.0.0-15-generic (SMP w/2 CPU cores)
 Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash



signature.asc
Description: OpenPGP digital signature

Bug#652968: debian-maintainers: Please add Aleksey Kravchenko as a Debian Maintainer

[Aleksey Kravchenko]

Package: debian-maintainers
Severity: normal
Tags: patch

Please add my key to the DM keyring. See attached jetring changeset.

Thanks.
Aleksey
Comment: Add rhash.ad...@gmail.com as a Debian Maintainer
Date: Thu, 22 Dec 2011 17:36:58 +0700
Action: import
Recommended-By:
  Kilian Krause kil...@debian.org
Agreement:
  http://lists.debian.org/debian-newmaint/2011/10/msg00010.html
Advocates:
  http://lists.debian.org/debian-newmaint/2011/10/msg00029.html
Data: 
  -BEGIN PGP PUBLIC KEY BLOCK-
  Version: GnuPG v1.4.11 (GNU/Linux)
  
  mQINBE4NrSYBEACU9ljBHEZggbmOfMvfBVqtIuOX7hfT2hBb/CwjJyanGI9X5a07
  ezKcoS+QcCFn9HkQ8/H1dTtLcpqjyiuume1LPQAY960sIKSHbcfcTZU+B4EQDSMP
  S6Gsgwzyk7vmdJsMIEYnm51J9vrT+cWT03Kgvna6NaG8zaQDsMaCEvXZEDu1BKOt
  vOKmi9ovo7XMAkOXvMY4Rl4cUNv1PCtkfsqcxmrMvtVnvJJJ1tdx5KK1Rox9GyO4
  PuUmsoNkE8NlNHkVeRVxSafE1W8d8QvpDS2pwmMvjCB1MBoBlEcgn5iWU5HtMiq7
  GbV8ydffgFSq8E+I/wEH0yiy2fn4BEtUuPOlQhj+NxpFaD4zU6p5ZeuZr4jhzeSn
  KO5CMkzAJYO09vQFlkVQ1y7S89hjiLmIJu8M2kF6F7yQ5ebrQcT+XoVXu4vmAmhm
  6itXV1Z0ici51/DEwc6f8rWhkunHIpJSQ77PxdijMBPH36ruB330n6RFY/G6TK76
  95sfA1EsZ/XCMKe5/VSWcFuCbYinss+o4bQVa0Vd1HrW90Yyn3BFqKDyephUcnwi
  7Xg6278S4lG4JAy6FOCnkCoSjlG6cwX6xojCftTsHvptVa/oAXDHpYnmGe/9qnGZ
  jQwiS9cpj6kRKuuQz1q6hsoHvIpYdmGz9CsCYvCfsZuZKnkFszxmWGakoQARAQAB
  tCpBbGVrc2V5IEtyYXZjaGVua28gPHJoYXNoLmFkbWluQGdtYWlsLmNvbT6JAjcE
  EwEIACEFAk4NrSYCGwMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AACgkQKnFEl+Nz
  Y66/GA//bp0tGf+s8eX4wduYIqeTowkHhj1HuT91CWUBe1G26ELIt48c65UwBVyQ
  RZGeqW/Ntxx8UbFegO8iFwqTgvqcqjYP/ac4MI4AthidwMA+qtuUg66YGOAZPXm0
  HLWB6a59Az+M16hsvo4u33Lg3sJoyHdp7oo4Gol95tBmgfFcKT9zU7MCe78dme1y
  I0U6xj646jWr4lxM0Riz/fUilb1jELKwuj1xCZoEEqh4KOsC8JpcOVqtRkUjfRZ3
  BJ1c1SaV/Y8Yy7lNdpJb3Ij03jahGDhwKNDdbt1J90DDYBwXq6kmQbUDXS+qR+Kt
  teU5yApwVDVJIrdk/VltLzDmRbRR168fly0JOXd51P2ra9HLRb15zYmX6CnkRV/1
  q51xWTCtfUWVMIf8ICDzeSKBFUC57bHfUcyM6vYpmRvp0BuI156vXBV5D8xsmNYj
  +ICB76CFMoSJ4w3ImRGFeBVBrtfWz7HQdAOsb3uOySo/Cff4qkwfOXQVINn0/ITZ
  Bxw2EaIktBRDtSqkcUbxIq1oSom4FFTs4Jy3RjaHDeFOJkFyyaKsOmRgdEf6qkbA
  qiZZZ5oJwzGpXBUWKq7ECED9B0qZhoj2KIs4pNTwfeRtvTe2ag0gdgd7kSvY7RPt
  xtzbrLQ59eT3J4qCCmnpSPRmjLXJH+xGZFEtWTAVN+NhA9WhrfqJARwEEAECAAYF
  Ak5q+Z0ACgkQnjY8gMYdrN+6igf7Bm/oO/Yn1GBDMqs4xuUXjm4cKUtUNyCREMsZ
  mFQ5GTxRUJab/Jt/tDrwVmMnGJKPF4wCCaAd8Su5yrI+UPsq24PtTeJmNDZK+LeD
  MiDe7g12aApsavCpOK/OR2PUUdfCAbk/OwpLWt9lHrTREVIk8Z+/+0LI3Hfsj2p2
  L1cGmuwGcZGcZMVhFaRtyzVh02YfojXgXpCXMpi9GD2CEIBv79V/0QJYkqKOPDGR
  JZFOjNhCCCdkINMO0+06Q/oEkZuQypcZzkbEx71Ns13/FOYB03ZIc8qQ8AZT2pMG
  dLdKVaEPJ/hiLkwDdTlycQBBoOP6gC64+m00nL7qqsaQZRCcjIhGBBARAgAGBQJO
  bafFAAoJENly8UZA95sG0ksAoIrSIWOrgTBXBj/Ol0elANhI7ZBlAKDDPnpCGjr3
  4SeKOhWiWaQOh/7+OohGBBARAgAGBQJOdF0hAAoJEF+Q2XSZ9fVdaasAoKCmDSnG
  b9/CsSuFhSa4LiPbfDKjAKCEuitA4Ci4/y3SoUAFWMjBNUU1UIhGBBARAgAGBQJO
  dF14AAoJEBAQAkn9OdNy5vMAmQEo41Z9DveH0F4yqbDm1zSJ3rMGAJ0TIRaDVd00
  bQrD6GY9lhyxIhMKp4kCHAQQAQIABgUCTnSzRAAKCRCdIPZQPjOIiI6AD/wIuArw
  z7C3pwhGDHDaXq8lCpZwHjE+YaPU1sxHqtR1wrSloUnmYDTom8nm6chibtVOiP4c
  +qOQpVlA61ZkyLRxMG9BPwRHHFPuvQmd3DCrRtmw3eFfFDZvmNefbbJvS3cC4MdH
  HBxbkMJQcfzNkwuv/QMPe1QvBm9lIUHKhcMRmHE25iIv9XcHfnzxdmv1072tYC9s
  GEyCxhhoMSO+/BS1+d2u5biT5VCoKo29tzbxv0mXW4QED2YNe3daJXzP8Fr+M0yW
  r49XcPPTsUezPbuG7bSPYH/YHxgKs3wjDp8zUy8XDCHWpBLZu/UfhGubQhVWf9wl
  V1OJZErO3oxeVGGuu1LJkkPRz+ltY0uqbXDks0kf60xfwHuFl5c/j5Lo3NaXkNii
  sBfXVRfL4nirltb0YGXH9brLshfzARHjocUa/ZeP14iUDuGHvPigdLVsMkQZYt/u
  m0BX3LyI3IEgOvX8kQPmHcr4uffcOmmJbl/3ndMXPfdEiZDRv6YCJ9JuB8lAKZ5s
  tHWzFABmkfdWXVp0OElaNuVQtOWpLI2idtrNWqOPhqD8tLOgqSwBcvzVRGiniJd6
  3Vk6ifmT8btWVFJ6m41v9x6cmztINf6Z4WsnC/UiAAxt49mo68CAInksOiVOL9Wq
  UwfLUg8kDBOu/NIGxmWW7EgtvjeY/hodaRN6GrkCDQRODa0mARAAs7qWOytyzsLA
  fjqFAraCDeZ1EQfwbdioiCgXZHVbCP1JYi0bxukpvINu+lRCmH7DEQZGtKKj2Pmo
  KleIDIMTpAfCP+ToewoQZPaMarIkaPD7/F+2pQgfNisH/SLD2s4293FkVGIwpM/i
  Bqq+ryE1gYdYwGaSxRUotU/lVPhDKadcDr4raz8eI7qxGJdjmESu/jk0LnhxuFjS
  awETeT2djkYaOxHRfRGB0fbnZ4loO686aJR2uUNwPs1+qbaGnfXMuA2PQPSvA/kg
  xcsXYHwigfjm7sGmQXYCq5a9YgrSaHMqXSftaMtMlaJl2i4ZDrEP1+Xks86n7W9W
  KxkWVwopBjNWu4AIrpZxDYe20T9a57pmxutaTsvZcftjMpHsU/7mtvVCE4ezad+A
  CuES5vXTAPJVDIgfralPjmu3New2gZpuAYQYEQnDGOj8U8wcGLbn5rZAwTpzFMhP
  svJnUoQK2jV+ifaVZs8GcIxzYeK3r30WEZ8kLK9coYZ4iu/6/MiyCzT/lEy/vJ0U
  lgeHwUfbLQbUyFQ9jaAouiXx/cIiW9KFiFlv99lpyB/pevqNKZPyAwegtgtyv90Q
  b3z5weyjc7Tv/aQ59FJgIgnwVhX8DBPDyPepkc3kCbAGyci/USv6eIBvfRPkMNBj
  W7ln2WLh7LNw3mmqyZ7KndtKTrcGsqsAEQEAAYkCHwQYAQgACQUCTg2tJgIbDAAK
  CRAqcUSX43NjrmAeD/0RDVoRHFJJOvDRnqueA3EAKjjiuB9/j5DJftwtmgO65igc
  rpNs8BARb8Tssg/iYWDQ0Y4uVtjuotgF/znTvKvwvru0O5S3geHdv4+dMfKasIEA
  8N/r+KA7VM3OazGNzg6sux0mE+mQWNvIqgMMpYkTJxct9Ig7UQb38FSPuYRm+Ygh
  YZ5QH+ql7FhUY0UlC6KUEhjDsnWsEWY61dnrM2D7alh0+RYp579LFEEqzW2FgfUv
  tw/0DV6ifJ8GN28/vWi2iSBYiGssZ9LIqLsop9LQQTGhDkDmRRyLf7cKA4siHnSp
  5z5Uxaq3Y4pzOSxRiIAAtHMxpX37/MrBnjjnBTfqIhjYzK5M8JV+drL9KiyQ9Bf6
  bMSYFlC0NBrpVyAyjxsfxAGHavcKTSUIWXl9d9OB2sA2GWrImYsbS2X5fcVDisaW
  34UjJj7UXzKDowdI7idlI9xr8tNtMrlscsKtN6pf2q+3HROBL4OFx+xNeV8FperB
  08544GBbj2H1dw79950LiVwZgUt/NWr53AJ0E5jTLwvw+Ia1kYppD0H8sb33t+hy

Bug#652302: python-rhash: cannot be imported

[Aleksey Kravchenko]

After 'apt-get upgrade' and removing some python packages I've got this
error. So, thanks for reporting it!

The bug is caused by python-rhash*.deb having being built without
python2 support.



signature.asc
Description: OpenPGP digital signature

Bug#652302: python-rhash: cannot be imported

[Aleksey Kravchenko]

Can't reproduce the bug.
The following script perfectly works after installing
python-rhash and librhash0:

--- start of test_rhash.py ---
import rhash

hasher = rhash.RHash(rhash.CRC32, rhash.MD5)
hasher.update('Hello, ')
hasher.update('world!')
hasher.finish()
print hasher.HEX(rhash.CRC32)
print hasher.hex(rhash.MD5)
--- end of test_rhash.py ---



signature.asc
Description: OpenPGP digital signature

Bug#650609: Have same problem on wheezy x86_64

[Aleksey Zapparov]

0.4 from squeeze (installed on wheezy) - works.


-- 
Sincerely yours,
Aleksey V. Zapparov A.K.A. ixti
FSF Member #7118
Mobile Phone: +34 617 179 344
Homepage: http://www.ixti.ru
JID: zappa...@jabber.ru

*Origin: Happy Hacking!



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

Bug#646595: xxkb crashes (especially while libreoffice is used)

[Aleksey Ilchenko]

Package: xxkb
Version: 1.11-2.1
Severity: important



-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages xxkb depends on:
ii  libc6 2.13-21
ii  libx11-6  2:1.4.4-2
ii  libxext6  2:1.3.0-3
ii  libxpm4   1:3.5.9-1
ii  libxt61:1.1.1-2

xxkb recommends no packages.

xxkb suggests no packages.

-- no debconf information
*** glibc detected *** xxkb: double free or corruption (fasttop):
*** 0x020b62f0 ***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x72606)[0x7fb9f8bf6606]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x6c)[0x7fb9f8bfb33c]
/usr/lib/x86_64-linux-gnu/libxcb.so.1(+0xaa48)[0x7fb9f8972a48]
/usr/lib/x86_64-linux-gnu/libxcb.so.1(xcb_wait_for_event+0x38)[0x7fb9f89730a8]
/usr/lib/x86_64-linux-gnu/libX11.so.6(_XReadEvents+0x138)[0x7fb9f95d8a58]
/usr/lib/x86_64-linux-gnu/libX11.so.6(XNextEvent+0x78)[0x7fb9f95c6fa8]
xxkb[0x403d17]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd)[0x7fb9f8ba2ead]
xxkb[0x4026b9]
=== Memory map: 
0040-00408000 r-xp  08:06 5079  /usr/bin/xxkb
00608000-00609000 rw-p 8000 08:06 5079  /usr/bin/xxkb
0209c000-020be000 rw-p  00:00 0
[heap]
7fb9f000-7fb9f0021000 rw-p  00:00 0
7fb9f0021000-7fb9f400 ---p  00:00 0
7fb9f7506000-7fb9f751b000 r-xp  08:03 78069
/lib/x86_64-linux-gnu/libgcc_s.so.1
7fb9f751b000-7fb9f771b000 ---p 00015000 08:03 78069
/lib/x86_64-linux-gnu/libgcc_s.so.1
7fb9f771b000-7fb9f771c000 rw-p 00015000 08:03 78069
/lib/x86_64-linux-gnu/libgcc_s.so.1
7fb9f771c000-7fb9f7721000 r-xp  08:06 131165
/usr/lib/x86_64-linux-gnu/libXfixes.so.3.1.0
7fb9f7721000-7fb9f7921000 ---p 5000 08:06 131165
/usr/lib/x86_64-linux-gnu/libXfixes.so.3.1.0
7fb9f7921000-7fb9f7922000 rw-p 5000 08:06 131165
/usr/lib/x86_64-linux-gnu/libXfixes.so.3.1.0
7fb9f7922000-7fb9f792c000 r-xp  08:06 328348
/usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0
7fb9f792c000-7fb9f7b2b000 ---p a000 08:06 328348
/usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0
7fb9f7b2b000-7fb9f7b2c000 rw-p 9000 08:06 328348
/usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0
7fb9f7b2c000-7fb9f7b35000 r-xp  08:06 131179
/usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2
7fb9f7b35000-7fb9f7d35000 ---p 9000 08:06 131179
/usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2
7fb9f7d35000-7fb9f7d36000 rw-p 9000 08:06 131179
/usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2
7fb9f7d36000-7fb9f7d3a000 r-xp  08:03 8522  /lib/libuuid.so.1.3.0
7fb9f7d3a000-7fb9f7f39000 ---p 4000 08:03 8522  /lib/libuuid.so.1.3.0
7fb9f7f39000-7fb9f7f3a000 rw-p 3000 08:03 8522  /lib/libuuid.so.1.3.0
7fb9f7f3a000-7fb9f7f3f000 r-xp  08:06 328326
/usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
7fb9f7f3f000-7fb9f813e000 ---p 5000 08:06 328326
/usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
7fb9f813e000-7fb9f813f000 rw-p 4000 08:06 328326
/usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
7fb9f813f000-7fb9f8141000 r-xp  08:06 328322
/usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
7fb9f8141000-7fb9f8341000 ---p 2000 08:06 328322
/usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
7fb9f8341000-7fb9f8342000 rw-p 2000 08:06 328322
/usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
7fb9f8342000-7fb9f8359000 r-xp  08:06 328313
/usr/lib/x86_64-linux-gnu/libICE.so.6.3.0
7fb9f8359000-7fb9f8558000 ---p 00017000 08:06 328313
/usr/lib/x86_64-linux-gnu/libICE.so.6.3.0
7fb9f8558000-7fb9f8559000 rw-p 00016000 08:06 328313
/usr/lib/x86_64-linux-gnu/libICE.so.6.3.0
7fb9f8559000-7fb9f855d000 rw-p  00:00 0
7fb9f855d000-7fb9f8564000 r-xp  08:06 328317
/usr/lib/x86_64-linux-gnu/libSM.so.6.0.1
7fb9f8564000-7fb9f8763000 ---p 7000 08:06 328317
/usr/lib/x86_64-linux-gnu/libSM.so.6.0.1
7fb9f8763000-7fb9f8764000 rw-p 6000 08:06 328317
/usr/lib/x86_64-linux-gnu/libSM.so.6.0.1
7fb9f8764000-7fb9f8766000 r-xp  08:03 78131
/lib/x86_64-linux-gnu/libdl-2.13.so
7fb9f8766000-7fb9f8966000 ---p 2000 08:03 78131
/lib/x86_64-linux-gnu/libdl-2.13.so
7fb9f8966000-7fb9f8967000 r--p 2000 08:03 78131
/lib/x86_64-linux-gnu/libdl-2.13.so
7fb9f8967000-7fb9f8968000 rw-p 3000 08:03 78131
/lib/x86_64-linux-gnu/libdl-2.13.so
7fb9f8968000-7fb9f8984000 r-xp  08:06 328330
/usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0
7fb9f8984000-7fb9f8b83000 ---p 0001c000 08:06 328330
/usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0
7fb9f8b83000-7fb9f8b84000 rw-p 0001b000 08:06 328330
/usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0
7fb9f8b84000-7fb9f8cfe000 r-xp  08:03 78061
/lib/x86_64-linux-gnu/libc-2.13.so
7fb9f8cfe000-7fb9f8efe000 ---p 0017a000 08:03 78061
/lib/x86_64-linux-gnu/libc-2.13.so
7fb9f8efe000-7fb9f8f02000 r--p 0017a000 08:03 78061
/lib/x86_64-linux-gnu/libc-2.13.so

Bug#611517: X crashes with 845G chipset

[Novosyolov Aleksey]

Package: xserver-xorg-video-intel
Version: 2:2.13.0-6
Severity: normal



-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Sep 28 09:43 /etc/X11/X - /usr/bin/Xorg
-rwxr-xr-x 1 root root 1733468 Feb 19  2011 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation 
82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device [8086:2562] (rev 
01)

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

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

KMS configuration files:

/etc/modprobe.d/i915-kms.conf:
  options i915 modeset=1
/etc/modprobe.d/radeon-kms.conf:
  options radeon modeset=1

Kernel version (/proc/version):
---
Linux version 2.6.32-5-486 (Debian 2.6.32-35squeeze2) (da...@debian.org) (gcc 
version 4.3.5 (Debian 4.3.5-4) ) #1 Fri Sep 9 20:19:21 UTC 2011

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 20560 Sep 28 19:35 /var/log/Xorg.0.log

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

X.Org X Server 1.7.7
Release Date: 2010-05-04
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.32.29-dsa-ia32 i686 Debian
Current Operating System: Linux sys-admin 2.6.32-5-486 #1 Fri Sep 9 20:19:21 
UTC 2011 i686
Kernel command line: BOOT_IMAGE=/vmlinuz-2.6.32-5-486 
root=/dev/mapper/sys--admin-root ro quiet
Build Date: 19 February 2011  02:37:36PM
xorg-server 2:1.7.7-13 (Cyril Brulebois k...@debian.org) 
Current version of pixman: 0.16.4
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: /var/log/Xorg.0.log, Time: Wed Sep 28 19:35:29 2011
(==) Using system config directory /usr/share/X11/xorg.conf.d
(==) No Layout section.  Using the first Screen section.
(==) No screen section available. Using defaults.
(**) |--Screen Default Screen Section (0)
(**) |   |--Monitor default monitor
(==) No monitor specified for screen Default Screen Section.
Using a default monitor configuration.
(==) Automatically adding devices
(==) Automatically enabling devices
(WW) The directory /usr/share/fonts/X11/cyrillic does not exist.
Entry deleted from font path.
(WW) The directory /usr/share/fonts/X11/100dpi/ does not exist.
Entry deleted from font path.
(WW) The directory /usr/share/fonts/X11/75dpi/ does not exist.
Entry deleted from font path.
(WW) The directory /usr/share/fonts/X11/Type1 does not exist.
Entry deleted from font path.
(WW) The directory /usr/share/fonts/X11/100dpi does not exist.
Entry deleted from font path.
(WW) The directory /usr/share/fonts/X11/75dpi does not exist.
Entry deleted from font path.
(WW) The directory /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType does not 
exist.
Entry deleted from font path.
(==) FontPath set to:
/usr/share/fonts/X11/misc,
built-ins
(==) ModulePath set to /usr/lib/xorg/modules
(II) The server relies on udev to provide the list of input devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
(II) Loader magic: 0x81ecca0
(II) Module ABI versions:
X.Org ANSI C Emulation: 0.4
X.Org Video Driver: 6.0
X.Org XInput driver : 7.0
X.Org Server Extension : 2.0
(++) using VT number 8

(--) PCI:*(0:0:2:0) 8086:2562:8086:464e Intel Corporation 
82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device rev 1, Mem @ 
0xf000/134217728, 0xffa8/524288
(II) Open ACPI successful (/var/run/acpid.socket)
(II) LoadModule: extmod
(II) Loading /usr/lib/xorg/modules/extensions/libextmod.so
(II) Module extmod: vendor=X.Org Foundation
compiled for 1.7.7, module version = 1.0.0
Module class: X.Org Server Extension
ABI class: X.Org Server Extension, version 2.0
(II) Loading extension SELinux
(II) Loading extension MIT-SCREEN-SAVER
(II) Loading extension XFree86-VidModeExtension
(II) Loading extension XFree86-DGA
(II) Loading extension DPMS
(II) Loading extension XVideo
(II) Loading extension XVideo-MotionCompensation
(II) Loading extension X-Resource
(II) LoadModule: dbe
(II) Loading /usr/lib/xorg/modules/extensions/libdbe.so
(II) Module dbe: vendor=X.Org Foundation
compiled for 1.7.7, module version = 1.0.0
Module class: X.Org Server Extension
ABI class: X.Org Server Extension, version 2.0
(II) Loading extension DOUBLE-BUFFER
(II) LoadModule: glx
(II) Loading /usr/lib/xorg/modules/extensions/libglx.so
(II) Module glx: vendor=X.Org Foundation
compiled for 1.7.7, module version = 1.0.0
ABI class: 

Bug#632280: The issue is fixed in Git

[Aleksey Kravchenko]

First, thanks for reporting.
This issue is fixed in Git and the fix will come with v1.2.7 release.

Being a bug from user's point of view, actually this issue is due to
half-implemented sha256/sha512 support - without hash verification.
So up to this point the issue concerns all previous RHash version.

In more details.  RHash up to v1.2.6 can't uniquely identify a hash
function by hash length, so it supposed that
all 128-bit hashes are MD5 or ED2K
all 256-bit hashes are GOST R 34.11-94 hash
all 512-bit hashes are Whirlpool

Now the parsing of hash files and verification code was rewritten.
If the program can't detect the precise hash function for say a 256-bit
hash,
then the program will calculate all supported 256-bit hashes and verify
the hash value against all of them.
To speed up verification, user can now specify exact hash function at
command line.



signature.asc
Description: OpenPGP digital signature

Bug#626877: pmake: Hardcoded paths to libraries breaks multiarch

[Aleksey Cheusov]

If you are really interested in pmake, have a look at

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=476267

pmake is not maintained for ages.
Nowadays crossplatform version of the NetBSD make
is distributed under name bmake.

-- 
Best regards, Aleksey Cheusov.



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

Bug#622637: Wrong keyword in dictd_virtual.conf

[Aleksey Cheusov]

 In file

   /usr/share/doc/dictd/examples/dictd_virtual.conf

 virtual dictionaries are defined using the keyword database, which
 does not work. The correct keyword is database_virtual, like in
 this tested example:

Fixed in upstream. Thank you for your report!

-- 
Best regards, Aleksey Cheusov.



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

Bug#612971: libpcsclite1: pcscd depends on hal

[Aleksey V Zapparov]

Package: libpcsclite1
Severity: normal


New version of libpcsclite1 depends on pcscd (it is not suggested anymore
as it was before. I'm not against pcscd, but it depends on hal. And I
don't want to install HAL just because of one pcscd, which I'm not using
at all. But I need libpcsclite1 because wpasupplicant depends on it.


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (600, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

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

Versions of packages libpcsclite1 depends on:
ii  libc6 2.11.2-11  Embedded GNU C Library: Shared lib

libpcsclite1 recommends no packages.

Versions of packages libpcsclite1 suggests:
pn  pcscd none (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#611203: AUTH doesn't work with amd64 dict against i386 dictd

[Aleksey Cheusov]

 [ CC Aleksey, who is the upstream maintainer of dictd ]
As you may already understand I'm subscribed to this list
because Debian is (and was) one of the main source of bug reports
for dictd.

 However I've  just looked into source codes and found the possible cause
 of the bug: the five following lines from the top of the md5.h file:

 #ifdef __alpha
 typedef unsigned int uint32;
 #else
 typedef unsigned long uint32;
 #endif

Thanks you both. I'll look into this problem ASAP.

-- 
Best regards, Aleksey Cheusov.



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

Bug#608701: dictfmt: missing dependency on mawk

[Aleksey Cheusov]

 dictfmt Depends: on gawk while scripts in the package hardcode mawk
 invocation:
 grep awk /usr/bin/dict*
 /usr/bin/dictfmt_index2suffix:mawk -v utf8_mode=$utf8_mode '
 /usr/bin/dictfmt_index2word:awk '
 /usr/bin/dictunformat:exec mawk '

It makes sense to configure dictd like the following:

AWK=/usr/bin/awk [other assignments] ./configure [options]

-- 
Best regards, Aleksey Cheusov.



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

Bug#606991: icedove ignores mail encoding after changing layout

[Aleksey Sergushichev]

Package: icedove
Version: 3.0.11-1
Severity: normal

When non-latin utf-8 encoded message is opened in the main tab changing of
layout (e.g. wide - vertical) leads to displaying of message in an incorrect
8bit encoding.

Sample mail is attached.

-- System Information:
Debian Release: 5.0.7
  APT prefers stable
  APT policy: (700, 'stable'), (400, 'testing'), (100, 'unstable')
Architecture: i386 (i686)

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

Versions of packages icedove depends on:
ii  debianutils2.30  Miscellaneous utilities specific t
ii  fontconfig 2.6.0-3   generic font configuration library
ii  libasound2 1.0.23-2.1shared library for ALSA applicatio
ii  libatk1.0-01.30.0-1  The ATK accessibility toolkit
ii  libc6  2.11.2-7  Embedded GNU C Library: Shared lib
ii  libcairo2  1.8.10-6  The Cairo 2D vector graphics libra
ii  libdbus-1-31.2.24-3  simple interprocess messaging syst
ii  libfontconfig1 2.8.0-2.1 generic font configuration library
ii  libfreetype6   2.3.7-2+lenny4FreeType 2 font engine, shared lib
ii  libgcc11:4.3.2-1.1   GCC support library
ii  libglib2.0-0   2.24.2-1  The GLib library of C routines
ii  libgtk2.0-02.20.1-2  The GTK+ graphical user interface 
ii  libjpeg62  6b1-1 The Independent JPEG Group's JPEG 
ii  libnspr4-0d4.8.6-1   NetScape Portable Runtime Library
ii  libnss3-1d 3.12.8-1  Network Security Service libraries
ii  libpango1.0-0  1.28.3-1  Layout and rendering of internatio
ii  libpng12-0 1.2.27-2+lenny4   PNG library - runtime
ii  libsqlite3-0   3.7.4-1   SQLite 3 shared library
ii  libstartup-notificatio 0.10-1library for program launch feedbac
ii  libstdc++6 4.4.5-8   The GNU Standard C++ Library v3
ii  libx11-6   2:1.3.3-4 X11 client-side library
ii  libxrender11:0.9.4-2 X Rendering Extension client libra
ii  libxt6 1:1.0.5-3 X11 toolkit intrinsics library
ii  psmisc 22.6-1Utilities that use the proc filesy
ii  zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime

Versions of packages icedove recommends:
ii  myspell-ru [myspell-dictionar 0.99g5-8.1 Russian dictionary for MySpell

Versions of packages icedove suggests:
ii  libdbus-glib-1-20.88-2   simple interprocess messaging syst
ii  libgconf2-4 2.28.1-6 GNOME configuration database syste
ii  libgnome2-0 2.20.1.1-1   The GNOME 2 library - runtime file
ii  libgnomevfs2-0  1:2.22.0-5   GNOME Virtual File System (runtime
ii  libgssapi-krb5-21.8.3+dfsg-2 MIT Kerberos runtime libraries - k
pn  ttf-lyx none   (no description available)

-- no debconf information
---BeginMessage---
Тест
---End Message---

Bug#605623: pmake: certain modifiers cannot be used with parentheses

[Aleksey Cheusov]

 Certain modifiers, such as ::!=, don't work if the variable in question
 is delimited using parentheses instead of braces, while others do.  I
 would expect running the attached Makefile to produce foo bar baz or
 maybe even foo, but not foo baz.

1) pmake packaged in Debian is extreamly old version of the NetBSD make.
   It is not released for years by upstream.
   Latest versions of the NetBSD make are released under name bmake
   by Simon J. Gerraty.

   ftp://ftp.NetBSD.org/pub/NetBSD/misc/sjg/
   http://www.crufty.net/help/sjg/bmake.html

2) I'm packaging bmake as well as mk files for Debian Lenny/i386.
   http://lists.debian.org/debian-mentors/2010/01/msg00379.html

3) The bug you reported was recently fixed in NetBSD current.
   Thanks!

-- 
Best regards, Aleksey Cheusov.



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

Bug#604153: keyboard-configuration: Template parse error near description...@latin.utf-8

[Aleksey Sergushichev]

Package: keyboard-configuration
Version: 1.59
Severity: important


After installing keyboard-configuration from testing (1.59) post-install
script fails with message:
Setting up keyboard-configuration (1.59) ...
Template parse error near `description...@latin.utf-8: Konfiguriši tastaturu', 
in stanza #1 of /var/lib/dpkg/info/keyboard-configuration.templates

-- System Information:
Debian Release: 5.0.6
  APT prefers stable
  APT policy: (700, 'stable'), (400, 'testing'), (100, 'unstable')
Architecture: i386 (i686)

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

Versions of packages keyboard-configuration depends on:
ii  debconf [debconf-2.0] 1.5.24 Debian configuration management sy

keyboard-configuration recommends no packages.

keyboard-configuration suggests no packages.

-- debconf information:
  keyboard-configuration/layout:
  keyboard-configuration/variant:
  keyboard-configuration/unsupported_options: true
  keyboard-configuration/optionscode: grp:caps_toggle,compose:ralt
  keyboard-configuration/modelcode: pc104
  keyboard-configuration/unsupported_config_options: true
  keyboard-configuration/toggle: Caps Lock
  keyboard-configuration/altgr: The default for the keyboard layout
  keyboard-configuration/unsupported_layout: true
  keyboard-configuration/layoutcode: us,ru
  keyboard-configuration/store_defaults_in_debconf_db: true
  debian-installer/console-setup-udeb/title:
  keyboard-configuration/ctrl_alt_bksp: false
  keyboard-configuration/variantcode: winkeys
  keyboard-configuration/other:
  keyboard-configuration/unsupported_config_layout: true
  keyboard-configuration/compose: Right Alt (AltGr)
  keyboard-configuration/switch: No temporary switch
  keyboard-configuration/model: Обычный 104-клавишный ПК



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

Bug#597002: raise priority of gawk?

[Aleksey Cheusov]

 Currently, mawk is priority required while gawk is priority
 optional. So mawk is installed by default while gawk isn't. However,
 if gawk is installed, it becomes the default awk because it has a
 higher alternatives priority than mawk. (The reason mawk has a lower
 priority, according to its changelog, is that mawk is unmaintained
 upstream and has bugs.)

JFYI: After more than a decade of stagnation mawk now has a maintainer.
Huge amount of work were done during last few years.

http://freshmeat.net/projects/mawk/

-- 
Best regards, Aleksey Cheusov.



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

Bug#597002: raise priority of gawk?

[Aleksey Cheusov]

 2010-09-15 22:26, Aleksey Cheusov skrev:
  
  Currently, mawk is priority required while gawk is priority
  optional. So mawk is installed by default while gawk isn't. However,
  if gawk is installed, it becomes the default awk because it has a
  higher alternatives priority than mawk. (The reason mawk has a lower
  priority, according to its changelog, is that mawk is unmaintained
  upstream and has bugs.)
  
  JFYI: After more than a decade of stagnation mawk now has a maintainer.
  Huge amount of work were done during last few years.
  
  http://freshmeat.net/projects/mawk/
  

 I see. But it's still not in Debian, see #554167.

Yes. The sad fact.

-- 
Best regards, Aleksey Cheusov.



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

Bug#591089: graphviz: Bad arrow direction between same rank nodes

[Aleksey Sergushichev]

Package: graphviz
Version: 2.26.3-5
Severity: normal


dot draws wrong direction arrow when to nodes have the same rank

Example of file:

digraph G
{
center=true;
rankdir=LR;
Node0x8d164f8 [label=9];
Node0x8d164f8 - Node0x8d162a8 [label=Z];
Node0x8d162a8 [label=17];
{ rank=same; Node0x8d164f8; Node0x8d162a8; }
}

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

Kernel: Linux 2.6.30-2-686 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages graphviz depends on:
ii  libc6  2.11.2-2  Embedded GNU C Library: Shared lib
ii  libcdt42.26.3-5  rich set of graph drawing tools - 
ii  libcgraph5 2.26.3-5  rich set of graph drawing tools - 
ii  libexpat1  2.0.1-4+lenny1XML parsing C library - runtime li
ii  libgd2-xpm 2.0.36~rc1~dfsg-3 GD Graphics Library version 2
ii  libgraph4  2.26.3-5  rich set of graph drawing tools - 
ii  libgvc52.26.3-5  rich set of graph drawing tools - 
ii  libgvpr1   2.26.3-5  rich set of graph drawing tools - 
ii  libx11-6   2:1.2.1-1 X11 client-side library
ii  libxaw72:1.0.5-2 X11 Athena Widget library
ii  libxmu62:1.0.4-1 X11 miscellaneous utility library
ii  libxt6 1:1.0.5-3 X11 toolkit intrinsics library

Versions of packages graphviz recommends:
ii  ttf-liberation1.04.93-1  Free fonts with the same metrics a

Versions of packages graphviz suggests:
pn  graphviz-doc  none (no description available)
ii  gsfonts   1:8.11+urwcyr1.0.7~pre44-4 Fonts for the Ghostscript interpre

-- 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#583287: ITP: pipestatus -- pipestatus for UNIX/POSIX shell

[Aleksey Cheusov]

Subject: ITP: pipestatus -- pipestatus for UNIX/POSIX shell
Package: wnpp
Owner: Aleksey Cheusov v...@gmx.net
Severity: wishlist

* Package name: pipestatus
  Version : 0.6
  Upstream Author : Aleksey Cheusov v...@gmx.net
* URL : http://sourceforge.net/projects/pipestatus/
* License : Public Domain
  Programming Lang: Shell
  Description : pipestatus for UNIX/POSIX shell

Pipestatus is a source file for POSIX shell that allows
one to obtain an exit status of each program in a pipe.

This software is already packaged here (binary is available for
lenny/i386 only)

deb http://mova.org/~cheusov/pub/debian   lennymain
deb-src http://mova.org/~cheusov/pub/debian   lennymain

So, I ask for review and importing.

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



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

Bug#575717: ITP: runawk -- Wrapper for AWK interpreter implementing modules

[Aleksey Cheusov]

Subject: ITP: runawk -- Wrapper for AWK interpreter implementing modules
Package: wnpp
Owner: Aleksey Cheusov v...@gmx.net
Severity: wishlist

* Package name: runawk
  Version : 0.21.0
  Upstream Author : Aleksey Cheusov v...@gmx.net
* URL : http://sourceforge.net/projects/runawk/
* License : MIT/X
  Programming Lang: C, AWK
  Description : Wrapper for AWK interpreter implementing modules

RUNAWK is a small wrapper for AWK interpreter that impements module system
(similar to Perl's use command) and helps one write the standalone AWK
programs. Dozens of modules ready for use are also provided.


I'm looking for sponsor who can review and upload this package to Debian
repository. Package is ready and works fine on Lenny.

deb http://mova.org/~cheusov/pub/debian   lennymain
deb-src http://mova.org/~cheusov/pub/debian   lennymain

-- System Information:
Debian Release: 5.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.26-bpo.2-686-bigmem
Locale: LANG=ru_RU.CP1251, LC_CTYPE=ru_RU.CP1251 (charmap=CP1251)



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

Bug#519443: paexec is already packaged, sponsor is needed

[Aleksey Cheusov]

paexec is already packaged for Debian.

deb http://mova.org/~cheusov/pub/debian   lennymain
deb-src http://mova.org/~cheusov/pub/debian   lennymain

Please review it and upload. I'd like to maintain it.

-- 
Best regards, Aleksey Cheusov.



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

Bug#476267: pmake: please update the package from the NetBSD sources

[Aleksey Cheusov]

Latest versions of NetBSD make are maintained by Simon Gerraty
and are available under name bmake.

Sources are available for download from here

   http://www.crufty.net/ftp/pub/sjg/

Home page is here

   http://www.crufty.net/help/sjg/bmake.htm

I've prepared a bmake package for Debian as well as pkgsrc-mk-files
package consisting of mk-files backward compatible with those from pmake
package. mk-files by Simon Gerraty (mk-YYYMMDD.tar.gz tarballs)
are not compatible. So, I propose to use mk-files from PkgSrc.

Here are .deb packages tested under Debian Lenny and Etch.

   deb http://mova.org/~cheusov/pub/debian   lennymain
   deb-src http://mova.org/~cheusov/pub/debian   lennymain

NetBSD make is very nice piece of software. So, please update the package.

-- 
Best regards, Aleksey Cheusov.



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

Bug#476267: RFP: paexec -- distributes tasks across CPUs or machines in a network

[Aleksey Cheusov]

I've prepared a package myself.
Here it is

   deb http://mova.org/~cheusov/pub/debian   lennymain
   deb-src http://mova.org/~cheusov/pub/debian   lennymain

Please, add it to a repository.

For building this package latest NetBSD make (package bmake) and
mk-files (package pkgsrc-mk-files) are needed.  Both they are also
Debianized in the above repository.

Also, have a look at

bug#476267 pmake: please update the package from the NetBSD sources

-- 
Best regards, Aleksey Cheusov.



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

Bug#564251: function dictem-run marked as interactive - crashed.

[Aleksey Cheusov]

 Package: dictem
 Version: 0.8-1

 With C-x dictem-run RET get in *Message*:

 call-interactively: Wrong number of arguments: (lambda (search-fun
 optional database query strategy) Creates new *dictem* buffer and

As manual says dictem-run function requires at least one argument. So
this is a documented behaviour. Or you are saying that I have to remove
(interactive) from function definition?

P.S. The latest upstream release is 1.0.2

-- 
Best regards, Aleksey Cheusov.



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

Bug#557252: negate the match for keyboard capabilities

[Aleksey Kliger]

--- 11-x11-synaptics.fdi.orig   2009-11-20 15:18:09.0 -0500
+++ 11-x11-synaptics.fdi2009-11-20 15:08:49.0 -0500
@@ -4,7 +4,7 @@
 match key=info.capabilities contains=input.touchpad
   !-- do not use the synaptics driver for devices advertising
   themselves as keyboards --
-  match key=info.capabilities contains=input.keyboard
+  match key=info.capabilities contains_not=input.keyboard
   merge key=input.x11_driver type=stringsynaptics/merge
   !-- Arbitrary options can be passed to the driver using
the input.x11_options property since xorg-server-1.5. --


-- 
Aleksey Kliger



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

Bug#557260: Can confirm this bug.

[Aleksey Kliger]

I can confirm this bug.

A workaround that worked for me, was to downgrade from the
debian-multimedia.org versions of libavcodec52 and libavformat52
to the testing versions:

debian-multimedia.org's versions:
* libavcodec52 5:0.5+svn20091118-0.0
* libavformat52 5:0.5+svn20091118-0.0
* result:  totem cannot playback xvid files.  There is no crash, but
the window remains black and there is no playback.

official debian.org versions:
* libavcodec52 4:0.5+svn20090706-2+b1
* libavformat52 4:0.5+svn20090706-2+b1
* result: totem works as expected.

-- 
Aleksey



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

Bug#550532: picard works badly with non-ascii tags

[Aleksey Sergushichev]

Package: picard
Version: 0.11-2
Severity: normal
Tags: patch

Picard forms bad request if there is non-ascii symbols in tags.
So it doesn't search what user wants.
Reques should be in UTF-8 encoding.
That patch fix my problem, but may be such fixes should be
implemented in other places too.
$ diff webservice.py~ webservice.py
287c287
 value = str(QtCore.QUrl.toPercentEncoding(str(value)))
---
 value = 
 str(QtCore.QUrl.toPercentEncoding(str(value).decode('utf-8')))




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

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

Versions of packages picard depends on:
ii  libavcodec52   5:0.5+svn20090629-0.0 library to encode decode multimedi
ii  libavformat52  5:0.5+svn20090629-0.0 ffmpeg file format library
ii  libc6  2.9-18GNU C Library: Shared libraries
ii  libdiscid0 0.1.0-1   Library for creating MusicBrainz D
ii  libfftw3-3 3.2.1-2.1 library for computing Fast Fourier
ii  libgcc11:4.4.0-10GCC support library
ii  libofa00.9.3-3   Library for acoustic fingerprintin
ii  libstdc++6 4.4.0-10  The GNU Standard C++ Library v3
ii  python [python-cty 2.5.4-2   An interactive high-level object-o
ii  python-mutagen 1.15-2audio metadata editing library
ii  python-qt4 4.5.1-1   Python bindings for Qt4
ii  python-support 1.0.3 automated rebuilding support for P

picard recommends no packages.

picard suggests no packages.

-- debconf-show failed



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

Bug#549194: kdevelop: crash when stopping debugger

[Aleksey Midenkov]

Package: kdevelop
Version: 4:3.5.5-1
Severity: important



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

Kernel: Linux 2.6.25.3-std (PREEMPT)
Locale: LANG=POSIX, LC_CTYPE=ru_RU.koi8-r (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/bash

Versions of packages kdevelop depends on:
hi  kdebase-bin  4:3.5.9.dfsg.1-2+b1 core binaries for the KDE base mod
hi  kdelibs4c2a  4:3.5.9.dfsg.1-2+b1 core libraries and binaries for al
ii  kdevelop-data4:3.5.5-1   Data files for the KDevelop IDE
hi  libapr1  1.2.11-1The Apache Portable Runtime Librar
hi  libc62.9-25  GNU C Library: Shared libraries
ii  libdb4.7 4.7.25-6Berkeley v4.7 Database Libraries [
hi  libgcc1  1:4.4.1-4   GCC support library
hi  libqt3-mt3:3.3.8b-4  Qt GUI Library (Threaded runtime v
hi  libstdc++6   4.4.1-4 The GNU Standard C++ Library v3
ii  libsvn1  1.5.1dfsg1-1Shared libraries used by Subversio

Versions of packages kdevelop recommends:
hi  autoconf 2.61-4  automatic configure script builder
hi  automake 1:1.10+nogfdl-1 A tool for generating GNU Standard
hi  gdb  6.8-3   The GNU Debugger
ii  kdevelop-doc 4:3.5.4-1   Documentation for the KDevelop IDE
hi  libtool  1.5.22-4Generic library support script
hi  make 3.80+3.81.b4-1  The GNU version of the make util

-- no debconf information
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 0xb60949e0 (LWP 26454)]
[New Thread 0xb41ebb90 (LWP 26478)]
[New Thread 0xb4fcfb90 (LWP 26469)]
[KCrash handler]
#6  0xb776660a in KProcess::writeStdin () from /usr/lib/libkdecore.so.4
#7  0xb44d98f8 in GDBDebugger::GDBController::slotStopDebugger ()
   from /usr/lib/kde3/libkdevdebugger.so
#8  0xb44c74b6 in GDBDebugger::DebuggerPart::slotStopDebugger ()
   from /usr/lib/kde3/libkdevdebugger.so
#9  0xb44c7963 in GDBDebugger::DebuggerPart::slotStop ()
   from /usr/lib/kde3/libkdevdebugger.so
#10 0xb44d4963 in GDBDebugger::DebuggerPart::qt_invoke ()
   from /usr/lib/kde3/libkdevdebugger.so
#11 0xb71e700d in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
#12 0xb71e7b8d in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
#13 0xb7a004f9 in KAction::activated () from /usr/lib/libkdeui.so.4
#14 0xb7a3f6a2 in KAction::slotActivated () from /usr/lib/libkdeui.so.4
#15 0xb7b2e6d1 in KAction::qt_invoke () from /usr/lib/libkdeui.so.4
#16 0xb71e700d in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
#17 0xb71e7b8d in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
#18 0xb7751c99 in KAccelPrivate::menuItemActivated ()
   from /usr/lib/libkdecore.so.4
#19 0xb77a13a7 in KAccelPrivate::emitActivatedSignal ()
   from /usr/lib/libkdecore.so.4
#20 0xb782f738 in KAccelPrivate::eventFilter () from /usr/lib/libkdecore.so.4
#21 0xb71e682c in QObject::activate_filters () from /usr/lib/libqt-mt.so.3
#22 0xb71e689b in QObject::event () from /usr/lib/libqt-mt.so.3
#23 0xb721f4dc in QWidget::event () from /usr/lib/libqt-mt.so.3
#24 0xb72d5d42 in QMainWindow::event () from /usr/lib/libqt-mt.so.3
#25 0xb71891ca in QApplication::internalNotify () from /usr/lib/libqt-mt.so.3
#26 0xb718a252 in QApplication::notify () from /usr/lib/libqt-mt.so.3
#27 0xb7839ec2 in KApplication::notify () from /usr/lib/libkdecore.so.4
#28 0xb77ad470 in KAccelEventHandler::x11Event ()
   from /usr/lib/libkdecore.so.4
#29 0xb783833a in KApplication::x11EventFilter ()
   from /usr/lib/libkdecore.so.4
#30 0xb7117a05 in ?? () from /usr/lib/libqt-mt.so.3
#31 0xbfd2b49c in ?? ()
#32 0xbfd2b3a8 in ?? ()
#33 0xb711decb in QETWidget::translateKeyEventInternal ()
   from /usr/lib/libqt-mt.so.3
#34 0xb712715e in QApplication::x11ProcessEvent () from /usr/lib/libqt-mt.so.3
#35 0xb7138026 in QEventLoop::processEvents () from /usr/lib/libqt-mt.so.3
#36 0xb719fbc0 in QEventLoop::enterLoop () from /usr/lib/libqt-mt.so.3
#37 0xb719fa56 in QEventLoop::exec () from /usr/lib/libqt-mt.so.3
#38 0xb7188d3f in QApplication::exec () from /usr/lib/libqt-mt.so.3
#39 0x0804e4ee in ?? ()
#40 0xbfd2b49c in ?? ()
#41 0x0809ca18 in ?? ()
#42 0xbfd2b618 in ?? ()
#43 0x0001 in ?? ()
#44 0x08053315 in ?? ()
#45 0x0001 in ?? ()
#46 0x08053400 in ?? ()
#47 0x080533b9 in ?? ()
#48 0x08052b7c in ?? ()
#49 0x08052b68 in _IO_stdin_used ()
#50 0x0001 in ?? ()
#51 0x033f in ?? ()
#52 0xb6096240 in ?? ()
#53 0x08063698 in ?? ()
#54 0x0804c007 in ?? ()
#55 0xb78b00a8 in 

Bug#548575: subtitleeditor: doesn't open ASS files with empty line in events section

[Aleksey Sergushichev]

Package: subtitleeditor
Version: 0.30.0-1
Severity: normal

If there is empty line in [Events] section after Format: ... line
then subtitleeditor opens file as if there no doalogues.


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

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

Versions of packages subtitleeditor depends on:
ii  gstreamer0.10-plugins- 0.10.23-3 GStreamer plugins from the base 
ii  gstreamer0.10-plugins- 0.10.16-1 GStreamer plugins from the good 
ii  gstreamer0.10-x0.10.23-3 GStreamer plugins for X11 and Pang
ii  libatk1.0-01.26.0-1  The ATK accessibility toolkit
ii  libc6  2.9-18GNU C Library: Shared libraries
ii  libcairo2  1.8.8-2   The Cairo 2D vector graphics libra
ii  libcairomm-1.0-1   1.8.0-1   C++ wrappers for Cairo (shared lib
ii  libfontconfig1 2.6.0-4   generic font configuration library
ii  libfreetype6   2.3.9-5   FreeType 2 font engine, shared lib
ii  libgcc11:4.4.0-10GCC support library
ii  libglade2-01:2.6.4-1 library to load .glade files at ru
ii  libglademm-2.4-1c2a2.6.7-2   C++ wrappers for libglade2 (shared
ii  libglib2.0-0   2.20.5-1  The GLib library of C routines
ii  libglibmm-2.4-1c2a 2.20.1-1  C++ wrapper for the GLib toolkit (
ii  libgstreamer-plugins-b 0.10.24-1 GStreamer libraries from the base
ii  libgstreamer0.10-0 0.10.24-1 Core GStreamer libraries and eleme
ii  libgtk2.0-02.16.3-1  The GTK+ graphical user interface 
ii  libgtkmm-2.4-1c2a  1:2.16.0-2C++ wrappers for GTK+ 2.4 (shared 
ii  libpango1.0-0  1.24.3-1  Layout and rendering of internatio
ii  libpangomm-1.4-1   2.24.0-3  C++ Wrapper for pango (shared libr
ii  libpng12-0 1.2.37-1  PNG library - runtime
ii  libsigc++-2.0-0c2a 2.0.18-2  type-safe Signal Framework for C++
ii  libstdc++6 4.4.0-10  The GNU Standard C++ Library v3
ii  libsubtitleeditor0 0.30.0-1  subtitleeditor lib - runtime files
ii  libx11-6   2:1.2.1-1 X11 client-side library
ii  libxml++2.6-2  2.26.0-2  A C++ interface to the GNOME XML l
ii  libxml22.7.3.dfsg-1  GNOME XML library
ii  libxrender11:0.9.4-2 X Rendering Extension client libra
ii  zlib1g 1:1.2.3.3.dfsg-14 compression library - runtime

subtitleeditor recommends no packages.

Versions of packages subtitleeditor suggests:
pn  gstreamer0.10-ffmpeg  none (no description available)
pn  gstreamer0.10-ffmpeg-full none (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