Bug#1069591: cyckle: Fails to start

[Konstantin L. Metlov]

This BUG was fixed in cycle 0.3.3. Please upgrade to

https://debian.pkgs.org/sid/debian-main-arm64/cycle_0.3.3-1_all.deb.html

Bug#1057962:

[Konstantin Isakov]

Hi,

The proposed patch has been accepted upstream.

Bug#1057962: bfd_find_nearest_line() leaks memory due to dwarf_rnglists_buffer never being freed

[Konstantin Isakov]

Package: libbinutils
Version: 2.41.50.20231206-1

Valgrind reports a leak when using bfd_find_nearest_line():

==2681185== 145,802 bytes in 1 blocks are definitely lost in loss record 39
of 39
==2681185==at 0x4840808: malloc (in
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==2681185==by 0x4FCA936: bfd_malloc (libbfd.c:290)
==2681185==by 0x5023665: read_section (dwarf2.c:737)
==2681185==by 0x5024E54: read_debug_rnglists (dwarf2.c:3181)
==2681185==by 0x5024E54: read_rnglists (dwarf2.c:3716)
==2681185==by 0x5026D42: read_rangelist (dwarf2.c:3791)
==2681185==by 0x5026D42: parse_comp_unit (dwarf2.c:4570)
==2681185==by 0x5026D42: stash_comp_unit (dwarf2.c:5589)
==2681185==by 0x502AB2A: _bfd_dwarf2_find_nearest_line_with_alt
(dwarf2.c:5969)
==2681185==by 0x4FFDC56: _bfd_elf_find_nearest_line_with_alt
(elf.c:10013)
==2681185==by 0x4FFDDC0: _bfd_elf_find_nearest_line (elf.c:9990)

The program does call bfd_close(), but that single allocation is still
leaked afterwards.

I've traced this to dwarf_rnglists_buffer in dwarf2_debug_file never being
freed. The following patch fixes it:

--- a/bfd/dwarf2.c 2023-11-25 04:59:00.0 -0300
+++ b/bfd/dwarf2.c 2023-12-10 21:05:02.084673848 -0300
@@ -6123,6 +6123,7 @@
   free (file->dwarf_line_str_buffer);
   free (file->dwarf_str_buffer);
   free (file->dwarf_ranges_buffer);
+  free (file->dwarf_rnglists_buffer);
   free (file->dwarf_line_buffer);
   free (file->dwarf_abbrev_buffer);
   free (file->dwarf_info_buffer);

I don't provide a test case, but it's very easy to see that the pointer
does get allocated but never gets freed anywhere, unlike its neighbours
(e.g. dwarf_ranges_buffer is allocated and freed in exactly the same way).
I've also tested the patch and the error goes away with it.

Bug#1053471: quick fix

[Konstantin Savin]

libpython3.11-testsuite_3.11.6-1_all.control# diff postinst{~,}
7c7
< files=$(dpkg -L libpython3.11-testsuite | sed -n
'/^\/usr\/lib\/python3.11\/.*\.py$/p' | egrep -v
'/lib2to3/tests/data|/test/bad')
---
> files=$(dpkg -L libpython3.11-testsuite | sed -n
'/^\/usr\/lib\/python3.11\/.*\.py$/p' | egrep -v
'/lib2to3/tests/data|/test/.*/bad')

Bug#1025782: Necessary changes in debian/control

[Konstantin Zangerle]

Can somebody just add
`default-mta | mail-transport-agent` to Build-Depends,
and Depends in the gpg-wks-server?

Bug#1040059: game-data-packager: please add support for Ion Fury

[Konstantin Korshunov]

Package: game-data-packager
Version: 75
Severity: wishlist
X-Debbugs-Cc: mil...@milvus.ml

Dear Maintainer,

https://store.steampowered.com/app/562860/Ion_Fury/

A game from 2019 that runs on eduke32 engine. Since Duke Nukem is already here,
might as well add this one.
(According to eduke32 wiki, it needs a build of eduke compiled with a special
flag; however, I'm currently running it on a vanilla eduke32, no problems so
far)

I'm attaching my output of GDP make-template. The files can be installed to
/usr/share/games/eduke32 without additional subdirectories.


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

Kernel: Linux 6.3.10-1-liquorix-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages game-data-packager depends on:
ii  python3 3.11.2-1+b1
ii  python3-debian  0.1.49
ii  python3-yaml6.0-3+b2

Versions of packages game-data-packager recommends:
ii  game-data-packager-runtime  75

Versions of packages game-data-packager suggests:
pn  arj 
ii  binutils2.40.50.20230611-2
pn  cabextract  
pn  cdparanoia  
ii  dynamite0.1.1-2+b2
ii  gcc 4:12.3.0-1
pn  gdebi | gdebi-kde   
ii  gir1.2-gdkpixbuf-2.02.42.10+dfsg-1+b1
ii  innoextract 1.9-0.1
pn  lgc-pg  
ii  lgogdownloader  3.11-1
ii  lhasa [lzh-archiver]0.4.0-1
ii  make4.3-4.1
ii  p7zip-full  16.02+dfsg-8
ii  pkexec  122-4
ii  python3-gi  3.42.2-3+b1
ii  python3-omg 0.5.1-1
ii  python3-pil 9.5.0-1
ii  steam-launcher [steam]  1:1.0.0.78
pn  steamcmd
pn  unace-nonfree   
pn  unar
ii  unrar   1:6.2.8-1
ii  unshield1.4.2-1
ii  unzip   6.0-28
pn  vorbis-tools
pn  xdelta  
pn  xdelta3 
ii  xorriso 1.5.4-4

-- no debconf information
---
copyright: "\xA9 1970 FIXME"
groups:
  contents of ionfury:
group_members: |
  3968f4b7e312bbaf6e7fd564ca2ba552ad fury.def
  92585117  b8a19d692733d276477d9a0bb497e63e fury.grp
  167   bca8337eabcb38c524103628a63a815a fury.grpinfo
packages:
  ionfury-data: {}
sha1sums: |
  370f34f81b8e44daf248c54b4a5fa0e162a6ac19 fury.def
  1da4d48e89cdeff2563739bf1d0e666552cd1964 fury.grp
  2d93d445223efc80f13e9e2fa5b2c099d90166b3 fury.grpinfo
sha256sums: |
  c6340d9020fb6a365df2742d55ee9bae44f78eab0e2c6d79730a3aeed8ff28cb fury.def
  b1bd6edead79cf21bfbf94f9e1b3e7ae85c08858dcbb462f5fabe723e898882a fury.grp
  27606b3d621bacccaa020be497c038cc1078a037b487aa84cb7addca4120d203 fury.grpinfo

...
---
copyright: "\xA9 1970 FIXME"
groups:
  contents of ionfury:
group_members: |
  3968f4b7e312bbaf6e7fd564ca2ba552ad fury.def
  92585117  b8a19d692733d276477d9a0bb497e63e fury.grp
  167   bca8337eabcb38c524103628a63a815a fury.grpinfo
packages:
  ionfury-data: {}
sha1sums: |
  370f34f81b8e44daf248c54b4a5fa0e162a6ac19 fury.def
  1da4d48e89cdeff2563739bf1d0e666552cd1964 fury.grp
  2d93d445223efc80f13e9e2fa5b2c099d90166b3 fury.grpinfo
sha256sums: |
  c6340d9020fb6a365df2742d55ee9bae44f78eab0e2c6d79730a3aeed8ff28cb fury.def
  b1bd6edead79cf21bfbf94f9e1b3e7ae85c08858dcbb462f5fabe723e898882a fury.grp
  27606b3d621bacccaa020be497c038cc1078a037b487aa84cb7addca4120d203 fury.grpinfo

...

Bug#1038904: [Pkg-utopia-maintainers] Bug#1038904: Bug#1038904: firewalld: nftables backend tries to mix ipv6 addresses and ipv4 addresses in the same rule

[Konstantin Nebel]

Hi Michael,

> What I'm interested in is, if python3-nftables 1.0.7 is actually
> required or not.
> Can you test with a bookworm system and only installing firewalld from
> unstable.
>

I reinstalled my sid with bookworm and upgraded just firewalld. My brief test
made it work. Before I made sure it doesnt work on bookworm. Upgraded just
firewalld to sid and it works.

So my original post seems to be wrong. I apologize for it. I installed the
master branch from git and it didnt work in first place. It just worked after
using a different python environment. But that might be an issue with the
specific version i used.

So in my opinion just upgrading the firewalld package should fix the issue.

Cheers
Konstantin Nebel


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

Bug#1038904: [Pkg-utopia-maintainers] Bug#1038904: firewalld: nftables backend tries to mix ipv6 addresses and ipv4 addresses in the same rule

[Konstantin Nebel]

Hello,

> Debian unstable already has 1.3.3-1, so when you mean "debian" I suspect
> you mean Debian stable, i.e. bookworm?
yes, I mean bookworm.

>
> Also, you mention that this requires an update of python3-nftables. Can
> you elaborate here?
>
> stable currently ships 1.0.6-2, unstable 1.0.7-2
I can confirm that sid works. Im actually not quite sure, which version im
using. I used a local penv environment und used this command to install
nftables module:

python3 -m pip install 
'git+https://salsa.debian.org/pkg-netfilter-team/pkg-nftables.git=py'

Im not sure which version it is. It states nftables 0.1 which is proably
wrong?

I installed a  VM very quick to confirm that sid is working which it is. But i
think this issue is important enough to make it to bookworm.

Cheers
Konstantin Nebel


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

Bug#1038904: firewalld: nftables backend tries to mix ipv6 addresses and ipv4 addresses in the same rule

[Konstantin Nebel]

Package: firewalld
Version: 1.3.0-1
Severity: important
Tags: upstream ipv6

Hello,

I have found a bug. I upgraded a couple days ago my Raspberrypi to Debian 
Bookworm and with the newer Debian a new Firewalld was installed. Since then 
Packages arent forwarded anymore by default. For that to work, you have to 
create policies in order to make this work. But when you have ipv4 and ipv6 
Addresses in one Zone, the nftables backend tries to mix ipv4 addresses with 
ipv6 addresses in the same rule which gets denied.

In the upstream Package this bug is confirmed and fixed in release 1.3.3. The 
original Bug Report is here: https://github.com/firewalld/firewalld/issues/1146

In order to fix this on debian it is needed to upgrade the firewalld package 
itself but more important the python3-nftables package to make this work. I 
have successfully fixed it locally by installeing a pyenv environment and 
installed the newest pyton packages and also the newest firewalld version.

It would be great, if this can be addresses since this is in my opinion a major 
issue that should be resolved.

Cheers
Konstantin Nebel


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

Kernel: Linux 6.1.0-9-arm64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 firewalld depends on:
ii  dbus  1.14.6-1
ii  gir1.2-glib-2.0   1.74.0-3
pn  gir1.2-nm-1.0 
ii  policykit-1   122-3
ii  polkitd   122-3
ii  python3   3.11.2-1+b1
pn  python3-dbus  
pn  python3-firewall  
pn  python3-gi
pn  python3-nftables  

Versions of packages firewalld recommends:
pn  ipset   
ii  iptables1.8.9-2
pn  python3-cap-ng  

firewalld suggests no packages.

Bug#1036988: crashes with TypeError: _ScrolledWindowBase.SetScrollbars(): argument 3 has unexpected type 'float'

[Konstantin L. Metlov]

Done. New release is up on GitHub.

https://github.com/metlov/cycle

With the best regards,
  Konstantin.

Quoting Andreas Tille :


Am Wed, May 31, 2023 at 05:35:46PM +0300 schrieb Konstantin L. Metlov:

Thank you for reporting this bug !

It is already fixed by the commit

https://github.com/metlov/cycle/commit/e86d72ec1a2a05c46ccde2f607f142cef7dbabb2

I should, probably, make a new bugfix release.


A bugfix release would be welcome.

Kind regards
 Andreas.


Or, alternatively, the
package can be patched with the last few cherry picked git commits. All of
the latest commits are bugfixes, only one of them (merging LMB and RMB
handling) changes the functionality a little bit, making the program more
convenient to use on touch screen devices.

With the best regards,
  Konstantin.

Quoting cacat...@tuxfamily.org:

> Package: cycle
> Version: 0.3.2-2
>
> Hello,
>
> steps to reproduce:
> - run the program
> - fill infos (name and password)
> - validate
>
> The program crashes with this output on a terminal:
>
> ~
> $ cycle
> /usr/bin/cycle:35: DeprecationWarning: Use setlocale(), getencoding()
> and getlocale() instead
>   dl = locale.getdefaultlocale()
>
> (cycle:108832): dbind-WARNING **: 08:53:27.113: AT-SPI: Error retrieving
> accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown:
> The name org.a11y.Bus was not provided by any .service files
> Traceback (most recent call last):
>   File "/usr/bin/cycle", line 212, in OnInit
> self.frame_init()
>   File "/usr/bin/cycle", line 216, in frame_init
> frame = MyFrame(None, -1, "")
> ^
>   File "/usr/bin/cycle", line 81, in __init__
> self.cal = Cal_Year(self)
>^^
>   File "/usr/share/cycle/cal_year.py", line 168, in __init__
> self.Init_Year()
>   File "/usr/share/cycle/cal_year.py", line 209, in Init_Year
> self.SetScrollbars(20, 20, w/20, h/20)
> TypeError: _ScrolledWindowBase.SetScrollbars(): argument 3 has
> unexpected type 'float'
> OnInit returned false, exiting...
> ~
>
> Have a good day,
>
>
> -- System Information:
> Debian Release: 12.0
>   APT prefers testing
>   APT policy: (900, 'testing'), (800, 'unstable'), (500,
> 'testing-security'), (500, 'testing-debug')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT)
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 cycle depends on:
> ii  python3   3.11.2-1+b1
> ii  python3-wxgtk4.0  4.2.0+dfsg-3
>
> cycle recommends no packages.
>
> cycle suggests no packages.
>
> -- no debconf information

___
Debian-med-packaging mailing list
debian-med-packag...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging



--
http://fam-tille.de

Bug#1036988: crashes with TypeError: _ScrolledWindowBase.SetScrollbars(): argument 3 has unexpected type 'float'

[Konstantin L. Metlov]

Thank you for reporting this bug !

It is already fixed by the commit

https://github.com/metlov/cycle/commit/e86d72ec1a2a05c46ccde2f607f142cef7dbabb2

I should, probably, make a new bugfix release. Or, alternatively, the  
package can be patched with the last few cherry picked git commits.  
All of the latest commits are bugfixes, only one of them (merging LMB  
and RMB handling) changes the functionality a little bit, making the  
program more convenient to use on touch screen devices.


With the best regards,
  Konstantin.

Quoting cacat...@tuxfamily.org:


Package: cycle
Version: 0.3.2-2

Hello,

steps to reproduce:
- run the program
- fill infos (name and password)
- validate

The program crashes with this output on a terminal:

~
$ cycle
/usr/bin/cycle:35: DeprecationWarning: Use setlocale(),  
getencoding() and getlocale() instead

  dl = locale.getdefaultlocale()

(cycle:108832): dbind-WARNING **: 08:53:27.113: AT-SPI: Error  
retrieving accessibility bus address:  
org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was  
not provided by any .service files

Traceback (most recent call last):
  File "/usr/bin/cycle", line 212, in OnInit
self.frame_init()
  File "/usr/bin/cycle", line 216, in frame_init
frame = MyFrame(None, -1, "")
^
  File "/usr/bin/cycle", line 81, in __init__
self.cal = Cal_Year(self)
   ^^
  File "/usr/share/cycle/cal_year.py", line 168, in __init__
self.Init_Year()
  File "/usr/share/cycle/cal_year.py", line 209, in Init_Year
self.SetScrollbars(20, 20, w/20, h/20)
TypeError: _ScrolledWindowBase.SetScrollbars(): argument 3 has  
unexpected type 'float'

OnInit returned false, exiting...
~

Have a good day,


-- System Information:
Debian Release: 12.0
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable'), (500,  
'testing-security'), (500, 'testing-debug')

Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 cycle depends on:
ii  python3   3.11.2-1+b1
ii  python3-wxgtk4.0  4.2.0+dfsg-3

cycle recommends no packages.

cycle suggests no packages.

-- no debconf information

Bug#1030785: -ffile-prefix-map option and reproducibility

[Konstantin Demin]

Hi!

I'm end up with following thing:
https://github.com/rockdrilla/debian-container/blob/808dfa15d130f833602a1486362cc551593a0d8a/image/python/template/rules#L543
Hovewer, "execute_before_dh_builddeb" recipe is for information only
(to be viewed by human) and "execute_before_dh_install" recipe is for
actual adjustments.

ср, 8 февр. 2023 г. в 13:39, Guillem Jover :
>
> On Tue, 2023-02-07 at 20:00:06 +0100, Sven Joachim wrote:
> > On 2023-02-07 17:50 +0100, Guillem Jover wrote:
> > > On Tue, 2023-02-07 at 16:41:47 +0100, Stéphane Glondu wrote:
> > >> I suspect this was added to improve reproducibility. Ironically, it makes
> > >> packages that capture this variable non reproducible, since the build 
> > >> path
> > >> seems to be randomized (has it always been the case? since when?). It is 
> > >> the
> > >> case of OCaml (see #1030785), and seemingly of R as well (found by 
> > >> grepping
> > >> in my /etc). I wouldn't be surprised other packages are affected as well.
> > >
> > > AFAIR this was considered at the time, yes. If the flag is effectively
> > > not fixing anything for the set of packages involved, and is in fact
> > > actually making them unreproducible when they would not then, you can
> > > disable the fixfilepath feature in the reproducible build flags area,
> > > via DEB_BUILD_MAINT_OPTIONS.
> >
> > This does not help for packages which capture all build flags and store
> > them in some file in the package (as is the case here).  With
> > DEB_BUILD_MAINT_OPTIONS=reproducible=-fixfilepath, dpkg-buildflags falls
> > back to "-fdebug-prefix-map==.", and you have the same
> > problem.  If you disable that as well via
> > DEB_BUILD_MAINT_OPTIONS=reproducible=-fixfilepath,-fixdebugpath, the
> > -dbgsym packages will most likely end up unreproducible.
>
> Ah, you are absolutely right. I don't think the case of these flags
> making the build unreproducible and the package not generating any
> debug objects are going to be common at all. I considered mentioning
> fixing the build to stop capturing, but felt it might be more effort
> than requested. :) Should probably have mentioned anyway, as was done
> elsewhere in the thread.
>
> In any case I'm thinking to add something like the attached to the man
> page to try to clarify this.
>
> Thanks,
> Guillem



-- 
SY,
Konstantin Demin

Bug#1030032: LLVM: should use debian multiarch

[Konstantin P.]

Package: src:llvm-toolchain-14
Version: 1:14.0.6-10
Distro: debian bookworkm

I want to cross-compile simple CMake project to mipsel in x86_64 machine. I
found than I cannot co-install LLVM versions from different architectures
by apt into one Debian machine. Even when I do not need llvm-config and any
of llvm binaries of mipsel architecture, only libraries and CMake files, I
cannot install llvm-14-dev:mipsel, because it depends on llvm-14:mipsel,
where all binaries are packaged, and llvm-14:mipsel conflicts with
llvm-14:amd64.

If all libraries and cmake files will be installed in
/usb/lib/DEB_HOST_MULTIARCH/, and will not depend on binaries (or depend on
binaries of "native" arch, if it is absolutely required), then CMake
projects can be compiled and packaged by cross-building with LLVM.

For now, it is not possible.

I found a similar bug,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897275, as wontfix. But
they are requesting a pkg-config file, which I do not need, I want only
better packaging, when I can use LLVM to cross-compile CMake packages by
installing it using APT without dirty hacks.

Bug#501456: dpkg-deb: Add new option --compress-program=

[Konstantin Khlebnikov]

On Thu, 5 Jan 2023 at 13:52, Guillem Jover  wrote:

> Control: tags -1 - patch
>
> Hi!
>
> On Sat, 2016-06-18 at 23:19:16 +0300, Konstantin Khlebnikov wrote:
> > Here is tiny patch which adds new option dpkg-deb
> --compress-program=
> > Program is executed as a filter with single argument: compression level
> -0 .. -9
>
> The code is not reaping the child, nor closing the file descriptors,
>

Oh, maybe. I just slammed it together to show simple solution.

There was no ready to use library solution for parallel compression.
I was limited by the technology of my time. Maybe nowadays it is invented.


> this is covered in fd_fd_filter(), but…
>
> > So, any existing parallel compression tool (pigz/pbzip2/pxz/pixz)
> > could be used here.
> > Of course compression type (-Z) must match. Such compression might not
> > suit for official
> > builds because it have lower ratio, but will save tons of time for
> > building debug packages.
>
> …this is the main problem I have with such patch, that you can specify
> any random program and it might or might not match the intended
> compression. Also as stated previously several of these tool generate
> output that is not ideal anyway.
>

Well, misconfiguration isn't a big deal.
Dpkg could easily validate magic afterwards.

Just to be clear - I have zero interest now.
That's trivial matter, so anybody could finish that.


>
> Thanks,
> Guillem
>

Bug#1025948: gcc: provide --debug-prefix-map for gnu as with -ffile-prefix-map

[Konstantin Demin]

Source: gcc-12
Version: 12.2.0-10

Please backport changes mentioned in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93371 in order to improve
overall build reproducibility.

I've been hit by this issue in
https://salsa.debian.org/mingw-w64-team/mingw-w64/-/merge_requests/3/diffs?commit_id=9bd67866e243e361c56daad2e8456e0f1ede1240

Test case:

Let's consider having file "empty.S" with following contents:
// -- cut --
.text
ret
// -- cut --

$ gcc -c -o empty.S.o empty.S -O2 -g && strings -f empty.S.o | grep -F
${PWD} && echo NOT OK || echo OK
empty.S.o: /home/krd/gcc-prefix-case
empty.S.o: /home/krd/gcc-prefix-case
NOT OK

$ gcc -c -o empty.S.o empty.S -O2 -g -fdebug-prefix-map=${PWD}=. &&
strings -f empty.S.o | grep -F ${PWD} && echo NOT OK || echo OK
OK

$ gcc -c -o empty.S.o empty.S -O2 -g -ffile-prefix-map=${PWD}=. &&
strings -f empty.S.o | grep -F ${PWD} && echo NOT OK || echo OK
empty.S.o: /home/krd/gcc-prefix-case
empty.S.o: /home/krd/gcc-prefix-case
NOT OK

$ gcc -c -o empty.S.o empty.S -O2 -g -ffile-prefix-map=${PWD}=.
-Wa,--debug-prefix-map,${PWD}=. && strings -f empty.S.o | grep -F
${PWD} && echo NOT OK || echo OK
OK

--
SY,
Konstantin Demin

Bug#1025782: gpg-wks-server not build with sendmail

[Konstantin Zangerle]

Package: gpg-wks-server
Version: 2.2.27-2+deb11u2

Usage of gpg-wks-server as outlined in https://wiki.gnupg.org/WKS
Especially the part about the procmail configuration.

When using gpg-wks-server to send confirmation requests, gpg-wks-server
requires a working sendmail.
The constant NAME_OF_SENDMAIL is set during the ./configure call.
The constant is used in tools/send-mail.c to send mails to verify the
request. I suggest building gpg-wks-server with the configure option
--with-mailprog and add a dependency to mail-transport-agent.

Relevant log lines:
gpg-wks-server: error running '': probably not installed
gpg-wks-server: running '' failed: Configuration error
gpg-wks-server: command failed: Configuration error

Bug#998513: rott: Fails at startup when doing XFree86-VidModeExtension/XF86VidModeGetAllModeLines X request

[Konstantin Khomoutov]

On Mon, Nov 08, 2021 at 09:39:08AM +0100, Fabian Greffrath wrote:


At startup, rott-commercial fails when performing what looks like a query
to the X server regarding its capabilities:

I cannot reproduce this issue, so it might have to do with your specfic
video hardware or drivers. I guess that's the price we pay for still using
SDL1.2 for a game in 2021. /o\


Oh, indeed: I have rebooted the laptop to apply the latest Bullseye updates,
and the issue has gone away; sorry for the noise.
I'm going to close this bug.


What I can confirm, though, is the game crashing when using libsdl-mixer1.2
(<< 1.2.12-17), but that's a different story and happens only after the
intro.


Do you mean this error?

8<
~$ rott-commercial window resolution=800x600
Rise of the Triad Startup  Version 1.4
 CD Version
Z_INIT: 895 bytes
IN_Startup: Mouse Present
Missing resolution parameter
Adding /usr/share/games/rott/DARKWAR.WAD.
Adding /usr/share/games/rott/REMOTE1.RTS.
W_Wad: Wad Manager Started NUMLUMPS=3904
RT_DRAW: Tables Initialized
MU_Startup:
SD_SetupFXCard: Fx ok.
SD_Startup: Fx ok.
RT_MAIN: Fonts Initialized
RT_MSG: Message System Started
RT_VIEW: Colormaps Initialized
OH NO OH NO ROTT CRASHED!
Here is where:
Stack dump:
{
  /lib/x86_64-linux-gnu/libc.so.6(+0x3bd60) [0x7f8843c2dd60]
/lib/x86_64-linux-gnu/libfluidsynth.so.2(+0x17e1a) [0x7f8843604e1a]
/lib/x86_64-linux-gnu/libfluidsynth.so.2(+0x1935c) [0x7f884360635c]
/lib/x86_64-linux-gnu/libfluidsynth.so.2(+0x19b21) [0x7f8843606b21]
/lib/x86_64-linux-gnu/libfluidsynth.so.2(delete_fluid_synth+0x2a) 
[0x7f884361cb2a]
/lib/x86_64-linux-gnu/libSDL_mixer-1.2.so.0(fluidsynth_freesong+0x3b) 
[0x7f8843dd231b]
/lib/x86_64-linux-gnu/libSDL_mixer-1.2.so.0(Mix_FreeMusic+0x107) 
[0x7f8843dc5597]
rott-commercial(+0x1c1e2) [0x56073a41c1e2]
rott-commercial(+0x77729) [0x56073a477729]
rott-commercial(+0x77984) [0x56073a477984]
rott-commercial(+0x59973) [0x56073a459973]
rott-commercial(main+0x1f7) [0x56073a419047]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea) [0x7f8843c18d0a]
rott-commercial(+0x192fa) [0x56073a4192fa]
}
8<

Crashes for me exactly after the intro.

Bug#998513: Update on using "resolution WxH" instead of "resolution=WxH"

[Konstantin Khomoutov]

It turned out I was trying to specify the resolution in a wrong way -
using "resolution=WxH" instead of "resolution WxH".

Still, an attempt to start ROTT the correct way -

 $ rott-commercial window resolution 800x600

(with any supported width and height) fails in exactly the same manner,
as indicated in the original report.

Bug#998513: rott: Fails at startup when doing XFree86-VidModeExtension/XF86VidModeGetAllModeLines X request

[Konstantin Khomoutov]

Package: rott
Version: 1.1.2+svn287-3
Severity: important
Tags: upstream

At startup, rott-commercial fails when performing what looks like a query
to the X server regarding its capabilities:

---

~$ rott-commercial window resolution=800x600
Rise of the Triad Startup  Version 1.4
 CD Version
Z_INIT: 895 bytes
IN_Startup: Mouse Present
Missing resolution parameter
Adding /usr/share/games/rott/DARKWAR.WAD.
Adding /usr/share/games/rott/REMOTE1.RTS.
W_Wad: Wad Manager Started NUMLUMPS=3904
RT_DRAW: Tables Initialized
MU_Startup:
SD_SetupFXCard: Fx ok.
SD_Startup: Fx ok.
RT_MAIN: Fonts Initialized
RT_MSG: Message System Started
RT_VIEW: Colormaps Initialized
X Error of failed request:  BadValue (integer parameter out of range for 
operation)
  Major opcode of failed request:  151 (XFree86-VidModeExtension)
  Minor opcode of failed request:  6 (XF86VidModeGetAllModeLines)
  Value in failed request:  0x17
  Serial number of failed request:  17
  Current serial number in output stream:  17

---

I have tries all the three resolutions mentioned by the manual page,
and also the "fullscreen" option with and without the "resolution="
option - all to the same outcome.

I'm trying to run ROTT on an X1 Carbon 6th gen ThinkPad laptop which has
a decent resolution, and may be that's something which makes ROTT unhappy.

Another possibility is that the computer runs GNOME on Wayland, and hence
ROTT actually talks to XWayland, not a "classic" X.org server.

-- Output of xrandr -q -v

Screen 0: minimum 16 x 16, current 2560 x 1440, maximum 32767 x 32767
XWAYLAND0 connected primary (normal left inverted right x axis y axis)
  Identifier: 0x21
  Timestamp:  597740277
  Subpixel:   unknown
  Clones:
  CRTCs:  0
  Transform:  1.00 0.00 0.00
  0.00 1.00 0.00
  0.00 0.00 1.00
 filter:
  non-desktop: 0
supported: 0, 1
  2560x1440 (0x22) 312.250MHz -HSync +VSync +preferred
h: width  2560 start 2752 end 3024 total 3488 skew0 clock  89.52KHz
v: height 1440 start 1443 end 1448 total 1493   clock  59.96Hz

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

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

Versions of packages rott depends on:
ii  libc62.31-13
ii  libsdl-mixer1.2  1.2.12-16+b1
ii  libsdl1.2debian  1.2.15+dfsg2-6

Versions of packages rott recommends:
pn  game-data-packager  

Versions of packages rott suggests:
ii  x11-utils  7.7+5
ii  zenity 3.32.0-6

-- no debconf information

-- Output of xdpyinfo:

name of display::0
version number:11.0
vendor string:The X.Org Foundation
vendor release number:12011000
X.Org version: 1.20.11
maximum request size:  16777212 bytes
motion buffer size:  256
bitmap unit, bit order, padding:32, LSBFirst, 32
image byte order:LSBFirst
number of supported pixmap formats:7
supported pixmap formats:
depth 1, bits_per_pixel 1, scanline_pad 32
depth 4, bits_per_pixel 8, scanline_pad 32
depth 8, bits_per_pixel 8, scanline_pad 32
depth 15, bits_per_pixel 16, scanline_pad 32
depth 16, bits_per_pixel 16, scanline_pad 32
depth 24, bits_per_pixel 32, scanline_pad 32
depth 32, bits_per_pixel 32, scanline_pad 32
keycode range:minimum 8, maximum 255
focus:  None
number of extensions:24
BIG-REQUESTS
Composite
DAMAGE
DOUBLE-BUFFER
DRI3
GLX
Generic Event Extension
MIT-SHM
Present
RANDR
RECORD
RENDER
SECURITY
SHAPE
SYNC
X-Resource
XC-MISC
XFIXES
XFree86-VidModeExtension
XINERAMA
XInputExtension
XKEYBOARD
XTEST
XVideo
default screen number:0
number of screens:1

screen #0:
  dimensions:2560x1440 pixels (677x381 millimeters)
  resolution:96x96 dots per inch
  depths (7):24, 1, 4, 8, 15, 16, 32
  root window id:0x522
  depth of root window:24 planes
  number of colormaps:minimum 1, maximum 1
  default colormap:0x23
  default number of colormap cells:256
  preallocated pixels:black 0, white 16777215
  options:backing-store WHEN MAPPED, save-unders NO
  largest cursor:2560x1440
  current input event mask:0xda
StructureNotifyMask  SubstructureNotifyMask   SubstructureRedirectMask 
PropertyChangeMask   ColormapChangeMask   
  number of visuals:390
  default visual id:  0x24
  visual:
visual id:0x24
class:TrueColor
depth:24 planes
available colormap entries:256 per subfield
red, green, blue 

Bug#969718: libappindicator3 library can't find libdbusmenu-glib.so.4

[Konstantin K]

Package: libappindicator3-1/stable,now 0.4.92-7 armhf [installed,automatic]
Version: 0.4.92-7 armhf

When I'm trying to create a new appindicator for a GJS application,
it's crashing with the error.

Here is a transcript:

$ ./obmin-indicator

** (OBMIN Indicator:2879): WARNING **: 10:08:34.219: Failed to load
shared library 'libappindicator3.so.1' referenced by the typelib:
libdbusmenu-glib.so.4: cannot open shared object file: No such file or
directory

(OBMIN Indicator:2879): Gjs-WARNING **: 10:08:34.219: JS ERROR: Error:
Unsupported type void, deriving from fundamental void
build_menu@/home/pi/Projects/obmin@konkor/common/indicator.js:159:9
wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
_onStartup@/home/pi/Projects/obmin@konkor/common/indicator.js:88:9
wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
@/home/pi/Projects/obmin@konkor/common/indicator.js:395:1
@./obmin-indicator:17:7


I also have tried the newer versions of packages (0.4.92-8 armhf) from
the testing branch. The package libdbusmenu-glib is installed and the
referenced library is located in
/usr/lib/arm-linux-gnueabihf/libdbusmenu-glib.so.4

I am using Raspbian Buster on Raspberry Pi 4 armhf architecture.

$uname -r

Linux raspberrypi 5.4.51-v7l+ #1333 SMP Mon Aug 10 16:51:40 BST 2020
armv7l GNU/Linux

Bug#969716: reportbug is crashing on looking new package versions

[Konstantin K]

Package: reportbug/stable,now 7.5.3~deb10u1 all [installed]
Version: 7.5.3~deb10u1

When it is trying to connect to FTP to look for newest package
versions, it's crashing..

Here is a transcript:

$ reportbug
E: You must put some 'source' URIs in your sources.list
Traceback (most recent call last):
  File "/usr/bin/reportbug", line 2284, in 
main()
  File "/usr/bin/reportbug", line 1115, in main
return iface.user_interface()
  File "/usr/bin/reportbug", line 1728, in user_interface
latest_first=self.options.latest_first)
  File "/usr/lib/python3/dist-packages/reportbug/ui/gtk_ui.py", line
1763, in func
args, kwargs = op.sync_pre_operation(*args, **kwargs)
TypeError: cannot unpack non-iterable NoneType object


I am using Raspbian Buster on Raspberry Pi 4 armhf architecture.

$uname -r

Linux raspberrypi 5.4.51-v7l+ #1333 SMP Mon Aug 10 16:51:40 BST 2020
armv7l GNU/Linux

Bug#961566: Cannot boot an intel upboard device after kernel upgrade

[Konstantin Petrov]

Package: linux-image-amd64
Version: linux-image-4.19.0-9-amd64

I am using first generation intel upboard (specs here
https://up-board.org/up/specifications/) and had not problems booting using
kernel with version 4.9. I have tried to upgrade to 4.19 and also 5.4 and
in both cases I could not boot the device. The error I get on the screen is
as follows:

mmc0 unrecognisez CDS structure version 0
mmc0: error -22 whilst initialising SD card

Thanks

Bug#927139: [src:wine-development] wineserver doesn't work when /run/user/uid/ is not available

[Konstantin Demin]

Hi Jens!

I've discovered this issue during own custom Wine build. Latest
upstream version (4.6) has no references to HAVE_GETUID and uses
getuid() directly, assuming it's available by default. I'm using
debhelper 12 with autoreconf, that's why HAVE_GETUID was absent and
wineserver directory setup via /run/user/uid/ was not compiled.

To trigger this bug on top of current version in Debian (4.2-2) just
replace "#if defined(HAVE_GETUID)" with "#if 0" in
debian/patches/fixes/temporary-directory.patch.
Nota bene: in that case almost any wine binary segfaults with malloc
issue, so you must call wineserver manually to discover pathname
issue.

2019-04-20 18:34 GMT+03:00, Jens Reyer :
> cotrol: tags -1 + moreinfo
>
>
> Hi Konstantin,
>
> On 15.04.19 15:11, Konstantin Demin wrote:
>> Source: wine-development
>> Version: 4.2-2
>>
>> wineserver fails to setup it's directory when /run/user/${pid} is not
>> available due to buggy patch.
>> please fix debian/patches/fixes/temporary-directory.patch:
>>
>> line 65:
>> -+tmp_dir = xmalloc( sizeof(tmp_env) );
>> ++tmp_dir = xmalloc( strlen(tmp_env) + 1 );
>>
>> line 110:
>> -+n = fputs( root + sizeof(tmp_dir) + 1, stream );
>> ++n = fputs( root + strlen(tmp_dir) + 1, stream );
>>
>> bug is caused by copy-paste mistake, because tmp_env and tmp_dir are
>> type of "char *", not "char []", therefore sizeof() isn't equal to
>> strlen() + 1.
>
> Thanks for your report.  I can' reproduce the issue here, but
> /run/user/$uid exists here (btw: typo pid/uid in your mail).  So can you
> please explain more specifically how to trigger this bug?  I'd like to
> know if this needs to be fixed for buster.
>
> Besides that, I rebuilt Wine with your fixes and all seems fine.  Your
> explanations sound good, but I have to admit I can't really verify them
> due to lack of C skills, and in-depth Wine code knowledge.
>
> Greets
> jre

-- 
SY,
Konstantin Demin

Bug#927139: [src:wine-development] wineserver doens't work when /run/user/pid is not available

[Konstantin Demin]

Source: wine-development
Version: 4.2-2

wineserver fails to setup it's directory when /run/user/${pid} is not
available due to buggy patch.
please fix debian/patches/fixes/temporary-directory.patch:

line 65:
-+tmp_dir = xmalloc( sizeof(tmp_env) );
++tmp_dir = xmalloc( strlen(tmp_env) + 1 );

line 110:
-+n = fputs( root + sizeof(tmp_dir) + 1, stream );
++n = fputs( root + strlen(tmp_dir) + 1, stream );

bug is caused by copy-paste mistake, because tmp_env and tmp_dir are
type of "char *", not "char []", therefore sizeof() isn't equal to
strlen() + 1.

--
SY,
Konstantin Demin

Bug#927138: [src:wine-development

[Konstantin Demin]

Source: wine-development
Version: 4.2-2

wineserver fails to setup it's directory when /run/user/${pid} is not
available due to buggy patch.
please fix debian/patches/fixes/temporary-directory.patch:

line 65:
-+tmp_dir = xmalloc( sizeof(tmp_env) );
++tmp_dir = xmalloc( strlen(tmp_env) + 1 );

line 110:
-+n = fputs( root + sizeof(tmp_dir) + 1, stream );
++n = fputs( root + strlen(tmp_dir) + 1, stream );

bug is caused by copy-paste mistake, because tmp_env and tmp_dir are
type of "char *", not "char []", therefore sizeof() isn't equal to
strlen() + 1.

--
SY,
Konstantin Demin

Bug#925382: Please, correct vala-panel dependencies

[Konstantin P.]

Package: libvalapanel0
Version: 0.4.87+dfsg1-1

Please, remove libpeas from dependencies. It is not required in vala-panel
version higher than 0.4.50. All plugins also finished using libpeas too.

Please, correct this, so, users will not install unused dep on their PCs.

Bug#657962: gcc-defaults: Add gcc-plugin-dev?

[Konstantin Demin]

Hello!

I suppose that gcc-plugin-dev metapackage will be very useful.

For example, Linux kernel supports GCC at least 4.5 for it's GCC
plugin infrastructure (ref: Documentation/gcc-plugins.txt), while
oldest GCC version in Debian is 4.6.3. Further example explanation is
the one may configure it's own Linux kernel source package simply
specifying gcc-plugin-dev in Build-Depends, as it done for
gcc-multilib (build dependency for linux-perf).

Anyway, this package is mostly intended to use by developers, so I
dont' see any problem when something does not build at first time
(solving FTBFS is part of work).

-- 
SY,
Konstantin Demin

Bug#896898: [sysadmin] Re: Bug#896898: mirror submission for sjc.edge.kernel.org

[Konstantin Ryabitsev]

These are part of a mirrors.edge.kernel.org pool that uses GeoIP to best
guess which one is closest to the users. However, I expect users to
access sjc/ewr/ams.edge.kernel.org directly, based on Debian's own "best
mirror" logic.

In other words, this is not just an internal name.

-K

On 04/29/18 12:26, Bastian Blank wrote:
> Hi Konstantin
> 
> Do you expect users to explicitely configure this mirror or is this just
> an internal name?
> 
> Regards,
> Bastian
> 
> On Wed, Apr 25, 2018 at 03:04:50PM +, Konstantin Ryabitsev wrote:
>> Submission-Type: new
>> Site: sjc.edge.kernel.org
>> Type: leaf
>> Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 
>> kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
>> Archive-http: /debian/
>> Maintainer: Konstantin Ryabitsev <ftpad...@kernel.org>
>> Country: US United States
>> Location: San-Jose, CA
>> Sponsor: packet.net https://packet.net
> 


-- 
Konstantin Ryabitsev
Director, IT Infrastructure Security
The Linux Foundation



signature.asc
Description: OpenPGP digital signature

Bug#896898: mirror submission for sjc.edge.kernel.org

[Konstantin Ryabitsev]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: sjc.edge.kernel.org
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Maintainer: Konstantin Ryabitsev <ftpad...@kernel.org>
Country: US United States
Location: San-Jose, CA
Sponsor: packet.net https://packet.net




Trace Url: http://sjc.edge.kernel.org/debian/project/trace/
Trace Url: http://sjc.edge.kernel.org/debian/project/trace/ftp-master.debian.org
Trace Url: http://sjc.edge.kernel.org/debian/project/trace/sjc.edge.kernel.org

Bug#896900: mirror submission for ams.edge.kernel.org

[Konstantin Ryabitsev]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: ams.edge.kernel.org
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Maintainer: Konstantin Ryabitsev <ftpad...@kernel.org>
Country: NL Netherlands
Location: Amsterdam
Sponsor: packet.net https://packet.net




Trace Url: http://ams.edge.kernel.org/debian/project/trace/
Trace Url: http://ams.edge.kernel.org/debian/project/trace/ftp-master.debian.org
Trace Url: http://ams.edge.kernel.org/debian/project/trace/ams.edge.kernel.org

Bug#896899: mirror submission for ewr.edge.kernel.org

[Konstantin Ryabitsev]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: ewr.edge.kernel.org
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Maintainer: Konstantin Ryabitsev <ftpad...@kernel.org>
Country: US United States
Location: Parsippany, NJ
Sponsor: packet.net https://packet.net




Trace Url: http://ewr.edge.kernel.org/debian/project/trace/
Trace Url: http://ewr.edge.kernel.org/debian/project/trace/ftp-master.debian.org
Trace Url: http://ewr.edge.kernel.org/debian/project/trace/ewr.edge.kernel.org

Bug#882694: [sysadmin] Signatures on uncompressed archives

[Konstantin Ryabitsev]

r grand principle of "trust the
developer, not infrastructure."

I believe our approach has merit and results in better security
protections. To verify the validity of any release you should:

1. Download the tarball and sha256sums.asc
2. Verify the signature on sha256sums.asc using a trusted keyring
3. Verify the tarball hash in sha256sums.asc
4. Decompress the tarball (in a jailed environment, if you like)
5. Verify the developer signature on the .tar file against a trusted keyring

Regards,
-- 
Konstantin Ryabitsev
Director, IT Infrastructure Security
The Linux Foundation



signature.asc
Description: OpenPGP digital signature

Bug#882694: [sysadmin] Signatures on uncompressed archives

[Konstantin Ryabitsev]

On 03/08/18 05:15, Uwe Kleine-König wrote:
> Hello,
> 
> I hope to have selected the right contact address for this mail, if not,
> please tell me or forward accordingly.
> 
> The kernel.org archive provides signatures for the software available
> (which is great!). The method to verify these according to
> 
>   
> https://www.kernel.org/category/signatures.html#using-gnupg-to-verify-kernel-signatures
> 
> is to download the .tar.xz and the .tar.sign file, unxz the archive and
> check the signature against the .tar file.
> 
> For one this is inconvenient because most tools don't know
> this scheme. In my case this is tooling from Debian to work with
> upstream archives[1].

I know it's a problem for Debian, but changing this scheme for us would
require significant retooling just as it would for Debian infra. The
major upside of the current approach is that we are free to add new
compressors, recompress existing archives with higher compression
ratios, etc, without needing to re-sign all files.

> But it also has an impact on security: As long as the signature isn't
> verified I have to consider the .tar.xz "untrusted" and the less tools I
> have to make operate on it the better.  This scheme allows an attacker
> that has control over a mirror to provide a .tar.xz that makes unxz do
> undesirable things, see https://en.wikipedia.org/wiki/Zip_bomb for an
> attack idea.

Which is why we provide sha256sums.asc in each directory.

Regards,
-- 
Konstantin Ryabitsev
Director, IT Infrastructure Security
The Linux Foundation



signature.asc
Description: OpenPGP digital signature

Bug#881624: The crashes

[Konstantin Khomoutov]

Oh, after closer examniation it appears the crashes are actually
different: the former has "double free or corruption (!prev)" as its
reason and has happened in garbage_collect() while the second has
"corrupted size vs. prev_size" and happened in win_free_lsize().

Still, both appear to relate to memory management.

Bug#881624: Another crash: corrupted size vs. prev_size

[Konstantin Khomoutov]

I've just hit another case of this crash in the same environment.

This time I was able to recover the post-mortem printout Vim itself
generated; may be it will be of use; especially, it appears we now have
the exact reason for the crash formulated by Vim:

8<
*** Error in `vim': corrupted size vs. prev_size: 0x555d0da308a0 ***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x7f92f94b3bcb]
/lib/x86_64-linux-gnu/libc.so.6(+0x76f96)[0x7f92f94b9f96]
/lib/x86_64-linux-gnu/libc.so.6(+0x78091)[0x7f92f94bb091]
vim(+0x1ad485)[0x555d0b1bb485]
vim(+0x14e358)[0x555d0b15c358]
vim(+0x14ec22)[0x555d0b15cc22]
vim(+0x1996ec)[0x555d0b1a76ec]
vim(+0x11e07c)[0x555d0b12c07c]
vim(+0x11e39c)[0x555d0b12c39c]
vim(+0x11e580)[0x555d0b12c580]
vim(+0x11e6d8)[0x555d0b12c6d8]
vim(+0x19e753)[0x555d0b1ac753]
vim(+0xba534)[0x555d0b0c8534]
vim(+0xbc464)[0x555d0b0ca464]
vim(+0xbcd68)[0x555d0b0cad68]
vim(+0xbd199)[0x555d0b0cb199]
vim(+0x102089)[0x555d0b110089]
vim(+0x1c5585)[0x555d0b1d3585]
vim(+0x1c63ab)[0x555d0b1d43ab]
vim(+0x2803d)[0x555d0b03603d]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f92f94632b1]
vim(+0x28fba)[0x555d0b036fba]
=== Memory map: 
555d0b00e000-555d0b238000 r-xp  08:01 17563693   
/usr/bin/vim.basic
555d0b438000-555d0b444000 r--p 0022a000 08:01 17563693   
/usr/bin/vim.basic
555d0b444000-555d0b45b000 rw-p 00236000 08:01 17563693   
/usr/bin/vim.basic
555d0b45b000-555d0b465000 rw-p  00:00 0
555d0d2e2000-555d0df66000 rw-p  00:00 0  [heap]
7f92f3de3000-7f92f3df9000 r-xp  08:01 8912909
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f92f3df9000-7f92f3ff8000 ---p 00016000 08:01 8912909
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f92f3ff8000-7f92f3ff9000 r--p 00015000 08:01 8912909
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f92f3ff9000-7f92f3ffa000 rw-p 00016000 08:01 8912909
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f92f400-7f92f4021000 rw-p  00:00 0
7f92f4021000-7f92f800 ---p  00:00 0
7f92f8083000-7f92f8085000 r-xp  08:01 17576227   
/usr/lib/x86_64-linux-gnu/gconv/ISO8859-1.so
7f92f8085000-7f92f8284000 ---p 2000 08:01 17576227   
/usr/lib/x86_64-linux-gnu/gconv/ISO8859-1.so
7f92f8284000-7f92f8285000 r--p 1000 08:01 17576227   
/usr/lib/x86_64-linux-gnu/gconv/ISO8859-1.so
7f92f8285000-7f92f8286000 rw-p 2000 08:01 17576227   
/usr/lib/x86_64-linux-gnu/gconv/ISO8859-1.so
7f92f828b000-7f92f8295000 r-xp  08:01 8916135
/lib/x86_64-linux-gnu/libnss_files-2.24.so
7f92f8295000-7f92f8495000 ---p a000 08:01 8916135
/lib/x86_64-linux-gnu/libnss_files-2.24.so
7f92f8495000-7f92f8496000 r--p a000 08:01 8916135
/lib/x86_64-linux-gnu/libnss_files-2.24.so
7f92f8496000-7f92f8497000 rw-p b000 08:01 8916135
/lib/x86_64-linux-gnu/libnss_files-2.24.so
7f92f8497000-7f92f849d000 rw-p  00:00 0
7f92f84a3000-7f92f84ae000 r-xp  08:01 8916159
/lib/x86_64-linux-gnu/libnss_nis-2.24.so
7f92f84ae000-7f92f86ad000 ---p b000 08:01 8916159
/lib/x86_64-linux-gnu/libnss_nis-2.24.so
7f92f86ad000-7f92f86ae000 r--p a000 08:01 8916159
/lib/x86_64-linux-gnu/libnss_nis-2.24.so
7f92f86ae000-7f92f86af000 rw-p b000 08:01 8916159
/lib/x86_64-linux-gnu/libnss_nis-2.24.so
7f92f86b3000-7f92f86c7000 r-xp  08:01 8916132
/lib/x86_64-linux-gnu/libnsl-2.24.so
7f92f86c7000-7f92f88c7000 ---p 00014000 08:01 8916132
/lib/x86_64-linux-gnu/libnsl-2.24.so
7f92f88c7000-7f92f88c8000 r--p 00014000 08:01 8916132
/lib/x86_64-linux-gnu/libnsl-2.24.so
7f92f88c8000-7f92f88c9000 rw-p 00015000 08:01 8916132
/lib/x86_64-linux-gnu/libnsl-2.24.so
7f92f88c9000-7f92f88cb000 rw-p  00:00 0
7f92f88cb000-7f92f88d2000 r-xp  08:01 8916133
/lib/x86_64-linux-gnu/libnss_compat-2.24.so
7f92f88d2000-7f92f8ad1000 ---p 7000 08:01 8916133
/lib/x86_64-linux-gnu/libnss_compat-2.24.so
7f92f8ad1000-7f92f8ad2000 r--p 6000 08:01 8916133
/lib/x86_64-linux-gnu/libnss_compat-2.24.so
7f92f8ad2000-7f92f8ad3000 rw-p 7000 08:01 8916133
/lib/x86_64-linux-gnu/libnss_compat-2.24.so
7f92f8ad3000-7f92f8d9e000 r--p  08:01 17580799   
/usr/lib/locale/locale-archive
7f92f8da3000-7f92f8dbb000 r-xp  08:01 8916165
/lib/x86_64-linux-gnu/libpthread-2.24.so
7f92f8dbb000-7f92f8fba000 ---p 00018000 08:01 8916165
/lib/x86_64-linux-gnu/libpthread-2.24.so
7f92f8fba000-7f92f8fbb000 r--p 00017000 08:01 

Bug#881624: vim: Random crashes due to some memory corruption

[Konstantin Khomoutov]

Package: vim
Version: 2:8.0.0197-4+deb9u1
Severity: normal
Tags: upstream

I use console Vim at an rxvt-unicode console with the support of 256
colors.  (I use the "Zenburn" colour theme with Vim, FWIW.)
That is, I have:

  $ echo $TERM
  rxvt-unicode-256color


I'm experience sporadic (but rare) crashes which basically come in two
flavours:

- One manifestation is that the output at the lower part of the window
  becomes garbled when scrolling (upwards).
  Pressin Ctrl-L fixes the problem.

  When I start seeing this, this is a symptom of an imminent crash which
  will happen withing minutes to a hour or two.

- Invoking Vim from a stopped background job using the "fg" command
  of my shell (which is bash).


No matter what the apparent cause, the crash always looks like Vim
getting the SIGABRT signal:

  Vim: Caught deadly signal ABRT
  
  Vim: Finished.
  Aborted.

In either case, I think this problem looks like some slow memory
corruption so the real trigger can be any action.


I have arranger for Vim to drop the core when crashing, and installed
the debug symbols package, so I have the output of the "bt" command in
a post-mortem GDB session, attached.


Please let me know if I can help more (it's okay for me to install
an instrumented version of Vim if needed.)


-- Package-specific info:

--- real paths of main Vim binaries ---
/usr/bin/vi is /usr/bin/vim.basic
/usr/bin/vim is /usr/bin/vim.basic

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

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

Versions of packages vim depends on:
ii  libacl1  2.2.52-3+b1
ii  libc62.24-11+deb9u1
ii  libgpm2  1.20.4-6.2+b1
ii  libselinux1  2.6-3+b3
ii  libtinfo56.0+20161126-1+deb9u1
ii  vim-common   2:8.0.0197-4+deb9u1
ii  vim-runtime  2:8.0.0197-4+deb9u1

vim recommends no packages.

Versions of packages vim suggests:
pn  ctags
pn  vim-doc  
pn  vim-scripts  

-- no debconf information
#0  0x7efdf6b5e2e7 in kill () at ../sysdeps/unix/syscall-template.S:84
#1  0x5574ebdab113 in may_core_dump () at os_unix.c:3357
#2  0x5574ebdacdf3 in may_core_dump () at os_unix.c:3314
#3  mch_exit (r=1) at os_unix.c:3323
#4  0x5574ebe51b7c in getout (exitval=1) at main.c:1495
#5  
#6  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#7  0x7efdf6b5f3fa in __GI_abort () at abort.c:89
#8  0x7efdf6b9bbd0 in __libc_message (do_abort=do_abort@entry=2, 
fmt=fmt@entry=0x7efdf6c90dd0 "*** Error in `%s': %s: 0x%s ***\n") at 
../sysdeps/posix/libc_fatal.c:175
#9  0x7efdf6ba1f96 in malloc_printerr (action=3, str=0x7efdf6c90e48 "double 
free or corruption (!prev)", 
ptr=, ar_ptr=) at malloc.c:5049
#10 0x7efdf6ba27de in _int_free (av=0x7efdf6ec4b00 , 
p=0x5574ed211cd0, have_lock=0) at malloc.c:3905
#11 0x5574ebcdc6b2 in clear_tv (varp=varp@entry=0x5574ed224310) at 
eval.c:7091
#12 0x5574ebcded91 in vars_clear_ext (ht=ht@entry=0x5574ed644fc0, 
free_val=free_val@entry=1) at eval.c:7627
#13 0x5574ebcdedaa in vars_clear (ht=ht@entry=0x5574ed644fc0) at eval.c:7601
#14 0x5574ebe326c6 in free_funccal (fc=0x5574ed644d60, 
free_val=free_val@entry=1) at userfunc.c:619
#15 0x5574ebe37a64 in free_unref_funccal (copyID=copyID@entry=1982, 
testing=testing@entry=0) at userfunc.c:3471
#16 0x5574ebcdb820 in garbage_collect (testing=testing@entry=0) at 
eval.c:5382
#17 0x5574ebd470fb in before_blocking () at getchar.c:1526
#18 0x5574ebdab7dd in mch_inchar (buf=buf@entry=0x5574ed55e3a6 "", 
maxlen=76, wtime=-1, tb_change_cnt=10929)
at os_unix.c:455
#19 0x5574ebe2b753 in ui_inchar (buf=buf@entry=0x5574ed55e3a6 "", 
maxlen=maxlen@entry=76, wtime=wtime@entry=-1, 
tb_change_cnt=tb_change_cnt@entry=10929) at ui.c:195
#20 0x5574ebd47534 in inchar (buf=0x5574ed55e3a6 "", maxlen=230, 
wait_time=-1, tb_change_cnt=10929)
at getchar.c:3056
#21 0x5574ebd49464 in vgetorpeek (advance=advance@entry=1) at getchar.c:2832
#22 0x5574ebd49d68 in vgetc () at getchar.c:1605
#23 0x5574ebd4a199 in safe_vgetc () at getchar.c:1801
#24 0x5574ebd8f089 in normal_cmd (oap=0x7fff9c15b000, toplevel=1) at 
normal.c:627
#25 0x5574ebe52585 in main_loop (cmdwin=0, noexmode=0) at main.c:1311
#26 0x5574ebe533ab in vim_main2 () at main.c:877
#27 0x5574ebcb503d in main (argc=, argv=) at 
main.c:415
quit

Bug#877122: libengine-pkcs11-openssl1.1: Engine is installed into wrong directory on i386

[Konstantin Pavlov]

Package: libengine-pkcs11-openssl1.1
Version: 0.4.4-4
Severity: normal

Dear Maintainer,

pkcs11.so is installed to /usr/lib/i686-linux-gnu/engines-1.1/, which is
wrong for i386 architecture and openssl fails to load the engine:

# openssl engine pkcs11 -t
3073050944:error:25066067:DSO support routines:dlfcn_load:could not load the 
shared 
library:../crypto/dso/dso_dlfcn.c:113:filename(/usr/lib/i386-linux-gnu/engines-1.1/pkcs11.so):
 /usr/lib/i386-linux-gnu/engines-1.1/pkcs11.so: cannot open shared object file: 
No such file or directory
3073050944:error:25070067:DSO support routines:DSO_load:could not load the 
shared library:../crypto/dso/dso_lib.c:161:
3073050944:error:260B6084:engine routines:dynamic_load:dso not 
found:../crypto/engine/eng_dyn.c:414:
3073050944:error:2606A074:engine routines:ENGINE_by_id:no such 
engine:../crypto/engine/eng_list.c:339:id=pkcs11


Manually symlinking the file works, though:

root:/usr/lib/i386-linux-gnu/engines-1.1# LC_ALL=C ls -l
total 32
-rw-r--r-- 1 root root  5384 Jun  5 12:40 capi.so
-rw-r--r-- 1 root root 22056 Jun  5 12:40 padlock.so
root:/usr/lib/i386-linux-gnu/engines-1.1# ln -sf 
/usr/lib/i686-linux-gnu/engines-1.1/pkcs11.so 
root:/usr/lib/i386-linux-gnu/engines-1.1# LC_ALL=C ls -l
total 32
-rw-r--r-- 1 root root  5384 Jun  5 12:40 capi.so
-rw-r--r-- 1 root root 22056 Jun  5 12:40 padlock.so
lrwxrwxrwx 1 root root45 Sep 29 00:28 pkcs11.so -> 
/usr/lib/i686-linux-gnu/engines-1.1/pkcs11.so
root:/usr/lib/i386-linux-gnu/engines-1.1# openssl engine pkcs11 -t
(pkcs11) pkcs11 engine
 [ available ]


I guess his happens because DEB_HOST_GNU_TYPE is used in debian/rules
instead of DEB_HOST_MULTIARCH.


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

Kernel: Linux 4.9.0-3-686-pae (SMP w/2 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to ru_RU.UTF-8), LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to ru_RU.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libengine-pkcs11-openssl1.1 depends on:
ii  libc6  2.24-11+deb9u1
ii  libssl1.1  1.1.0f-3
ii  p11-kit0.23.3-2

libengine-pkcs11-openssl1.1 recommends no packages.

libengine-pkcs11-openssl1.1 suggests no packages.

-- no debconf information

Bug#872077: [xtables-addons-dkms] Error building against Linux 4.12

[Konstantin Demin]

Package: xtables-addons-dkms
Version: 2.12-0.1
Severity: grave

Hello!

Same issue as #851576: cannot build xtables-addons-dkms against Linux 4.12.
Please consider packaging xtables-addons 2.13 (released 29 Jun 2017),
which has support for Linux 4.12 and successfully builds with new kernel.

No critical changes in Debian source package are required so far.
NMU is acceptable choice (like Ben Hutchings did in #851576).

--
SY,
Konstantin Demin

Bug#870052: git: RPC failed; curl 56 GnuTLS recv error

[Konstantin Manna]

Package: git
Version: 1:2.13.2-3
Severity: normal

Cloning a git repo via https failes with the error below.
I think it's a bug with git/it's used libaries, since reportedly running the 
same with a recompiled git with openssl instead of gnutls does not lead to an 
error.
(See 
https://stackoverflow.com/questions/38378914/git-error-rpc-failed-curl-56-gnutls)
I am not sure if this is the right place to report the error.
If so, I'd be glad if anyone refers me to the correct place.

LC_ALL=C git clone -v https://***.git
Cloning into '***'...
POST git-upload-pack (gzip 5341 to 2695 bytes)
remote: Counting objects: 226702, done.
remote: Compressing objects: 100% (62511/62511), done.
error: RPC failed; curl 56 GnuTLS recv error (-9): A TLS packet with unexpected 
length was received.
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed


-- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages git depends on:
ii  dpkg 1.18.24
ii  git-man  1:2.13.2-3
ii  libc62.24-12
ii  libcurl3-gnutls  7.52.1-5
ii  liberror-perl0.17024-1
ii  libexpat12.2.2-2
ii  libpcre3 2:8.39-3
ii  perl 5.26.0-4
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages git recommends:
ii  less 481-2.1
ii  openssh-client [ssh-client]  1:7.5p1-5
ii  patch2.7.5-1+b2

Versions of packages git suggests:
ii  gettext-base  0.19.8.1-2+b1
pn  git-cvs   
pn  git-daemon-run | git-daemon-sysvinit  
pn  git-doc   
pn  git-el
pn  git-email 
pn  git-gui   
pn  git-mediawiki 
pn  git-svn   
pn  gitk  
pn  gitweb

-- no debconf information

Bug#862452: Update to newer QtWebKit

[Konstantin Tokarev]

13.05.2017, 19:00, "Dmitry Shachnev" <mity...@debian.org>:
> Hi Konstantin,
>
> On Sat, May 13, 2017 at 01:42:12PM +0300, Konstantin Tokarev wrote:
>>  Note that there is unofficial package already:
>>
>>  http://repo.paretje.be/unstable/#
>>
>>  See packages libqt5webkit5, libqt5webkit5-dev
>>
>>  Git repo of package is at
>>  https://gitlab.com/paretje/qtwebkit/tree/master/debian
>>
>>  Package is loosely based of webkitgtk's, and contains a few build
>>  dependencies that are not actually needed:
>>
>>  libharfbuzz-dev, libfreetype6-dev, libfontconfig1-dev (these are used when
>>  qtbase is built, not directly in qtwebkit)
>>  libgnutls28-dev, libsoup2.4-dev, libenchant-dev, geoclue-2.0,
>>  libsecret-1-dev - not used at all
>>  libxt-dev - probably unused as well
>>
>>  Otherwise, packaging files look good to me
>
> Thanks for the information, it is very helpful!
>
> On Sat, May 13, 2017 at 02:03:10PM +0300, Konstantin Tokarev wrote:
>>  Also, note that upcoming release is intended to be a drop-in replacement of
>>  old QtWebKit to be used with older Qt versions too, as security update.
>
> This is also helpful, but if you mean that we should update the packages
> in Stretch too, then probably the answer is that we don’t have enough time
> for it...

Yes, it would be great to update package in Stretch. What should be done to
make it possible?

It would be great to have package in backports repo for Jessie

>
> --
> Dmitry Shachnev

-- 
Regards,
Konstantin

Bug#862452: Update to newer QtWebKit

[Konstantin Tokarev]

13.05.2017, 23:08, "Giuseppe Bilotta" <giuseppe.bilo...@gmail.com>:
> On Sat, May 13, 2017 at 12:42 PM, Konstantin Tokarev <annu...@yandex.ru> 
> wrote:
>>  Note that there is unofficial package already:
>>
>>  http://repo.paretje.be/unstable/#
>>
>>  See packages libqt5webkit5, libqt5webkit5-dev
>>
>>  Git repo of package is at 
>> https://gitlab.com/paretje/qtwebkit/tree/master/debian
>>
>>  Package is loosely based of webkitgtk's, and contains a few build 
>> dependencies that are not actually needed:
>>
>>  libharfbuzz-dev, libfreetype6-dev, libfontconfig1-dev (these are used when 
>> qtbase is built, not directly in qtwebkit)
>>  libgnutls28-dev, libsoup2.4-dev, libenchant-dev, geoclue-2.0, 
>> libsecret-1-dev - not used at all
>>  libxt-dev - probably unused as well
>>
>>  Otherwise, packaging files look good to me
>
> Interesting, thanks a lot. That looks like it will make the work much
> easier for the maintainers after the Stretch release, just what they
> were looking for ;-).
>
> I wonder if there's a reason why they went with the same package name
> instead of using a different name (say, libqt5webkit-ng5), and then
> adding Provides/Breaks to allow replacement.

I doubt there will be a reason to keep old package as an installation option

>
> --
> Giuseppe "Oblomov" Bilotta

-- 
Regards,
Konstantin

Bug#862452: Update to newer QtWebKit

[Konstantin Tokarev]

Also, note that upcoming release is intended to be a drop-in replacement of old 
QtWebKit to be used with older Qt versions too, as security update.

-- 
Regards,
Konstantin

Bug#862452: Update to newer QtWebKit

[Konstantin Tokarev]

Note that there is unofficial package already:

http://repo.paretje.be/unstable/#

See packages libqt5webkit5, libqt5webkit5-dev

Git repo of package is at https://gitlab.com/paretje/qtwebkit/tree/master/debian

Package is loosely based of webkitgtk's, and contains a few build dependencies 
that are not actually needed:

libharfbuzz-dev, libfreetype6-dev, libfontconfig1-dev (these are used when 
qtbase is built, not directly in qtwebkit)
libgnutls28-dev, libsoup2.4-dev, libenchant-dev, geoclue-2.0, libsecret-1-dev - 
not used at all
libxt-dev - probably unused as well

Otherwise, packaging files look good to me
-- 
Regards,
Konstantin

Bug#861474: slim: Session restarts in a loop renedering whole system useless.

[Konstantin Khomoutov]

I wonder if it may be the fix for #860465 which is the only thing which
looks remotely fishy in the changelog.

FWIW I do not have plymouth installed on the affected system.

Bug#861474: slim: Session restarts in a loop renedering whole system useless.

[Konstantin Khomoutov]

Happens to me as well after the last `apt update && apt upgrade` of my
Stretch (amd64) system.

I've tracked it down to be an issue with Slim as switching to an
alternate login manager (tried xdm and lxdm) fixes the problem.

In the log file, Slim appears to write something about the X server not
having been connected in a timely manner.

Since the session reset happens in some 10-15 seconds, I'd say Slim has
some logic to check whether the X server has become available and if it
hasn't Slim retries.  Looks like after some late change in either Slim
or X.org, this check now fails.

If needed, I could try debugging this further or provide futher info
(unfortunately, I have no slim.log from the affected machine at hand
currently).

Bug#861474: slim: Session restarts in a loop renedering whole system useless.

[Konstantin Khomoutov]

On Sat, 29 Apr 2017 14:12:43 +0100 ael  wrote:
> Package: slim
> Version: 1.3.6-5
> Severity: critical
> Justification: breaks the whole system
> 
> I am not sure that this is a slim problem, but as the system is almost
> unusable, I cannot investigate.
> 
> After an apt-get upgrade earlier today, the system presents a new slim
> login page. Logging in works, but then the whole system restarts X
> (presumably) and the sylim login prompt appear again. This ahhpens in
> what seems to be an infinite loop, roughly every minute or so.
> 
> I am only able to compose this message outside X using a pseudo
> terminal. The restarts interrupt the terminal and represents the slim
> login page. Fortunately the terminal context is retained so I can switch
> back to the terminal.
> 
> I have not yet tried removing slim which I hope I may be able to do
> despite the constant restarts.
> 
> I suspect slim because it seems to be the only likely candidate in the
> set of upgrades earlier today, and it is the slim login screen which
> keeps looping.
> 
> Presumably others will report this problem as well.
> 
> -- 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/8 CPU cores)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages slim depends on:
> ii  dbus   1.10.18-1
> ii  debconf [debconf-2.0]  1.5.60
> ii  libc6  2.24-10
> ii  libfontconfig1 2.11.0-6.7+b1
> ii  libfreetype6   2.6.3-3.1
> ii  libgcc11:6.3.0-14
> ii  libjpeg62-turbo1:1.5.1-2
> ii  libpam0g   1.1.8-3.5
> ii  libpng16-161.6.28-1
> ii  libstdc++6 6.3.0-14
> ii  libx11-6   2:1.6.4-3
> ii  libxext6   2:1.3.3-1+b2
> ii  libxft22.3.2-1+b2
> ii  libxmu62:1.1.2-2
> ii  libxrandr2 2:1.5.1-1
> ii  libxrender11:0.9.10-1
> ii  lsb-base   9.20161125
> ii  zlib1g 1:1.2.8.dfsg-5
> 

Bug#856912: [src:archvsync] typo in Maintainer field

[Konstantin Demin]

Source: archvsync
Version: 20170204
Severity: minor

Please fix typo in "Maintainer" field:
-Maintainer: Debiab Mirror Team <mirr...@debian.org>
+Maintainer: Debian Mirror Team <mirr...@debian.org>

--
SY,
Konstantin Demin

Bug#850597: ITP: python-month-delta

[Konstantin Khomoutov]

On Sun, 8 Jan 2017 16:49:21 +0530
Nupur Malpani  wrote:

> Package: wnpp
> Owner: Nupur Malpani 
> Severity: wishlist
> X-Debbugs-Cc:
> debian-de...@lists.debian.org,debian-pyt...@lists.debian.org
> 
> * Package name: python-month-delta
>   Version : 1.0b
>   Upstream Author : Jess Austin
> * URL : https://pypi.python.org/pypi/MonthDelta
> * License : MIT
>   Programming Lang: Python
>   Description : enables easy month-related calculations with the
> standard Python date
>  and
> datetime
> 
> classes from the *datetime*
>  module.

Please remove the whatever formatting got into the description while
you were copying and pasting stuff.

It should look something like 

Description: Enables easy month-related calculations with the
 standard Python date and datetime classes from the datetime module.

Bug#849817: [Pkg-mpd-maintainers] Bug#849726: mpd: On i686, RestrictNamespaces=yes in Systemd unit does not allow mpd to open sockets

[Konstantin Khomoutov]

On Sat, 31 Dec 2016 13:49:34 +0100
Florian Schlichting  wrote:

> > > Your analysis seems to be correct. Until systemd is fixed, you
> > > should not use RestrictAddressFamilies=
> > > 
> > > I'm not sure whether we will get v233 for stretch and if
> > > backporting those upstream fixes for v232 is feasible.
> > 
> > Would it be possible then to temporarily patch systemd as will be
> > shipped in Stretch to just fail loading the unit with a descriptive
> > error message if it contains the RestrictAddressFamilies directive
> > *and* systemd is running on a 32-bit architecture (I think we have
> > i686 and x32 by now)?
> 
> or, even better, not fail outright but ignore RestrictAddressFamilies
> and issue a warning about it?

Let me disagree.

Warnings do have their place, but I'd say it's mostly about deprecating
currently supported stuff in some (distant) future.

Failure to properly provide feature X when it was requested by the user
is an error.  Let me back my claim up: suppose I've installed a program
which is supposed to be properly sandboxed (network-wise in this
particular case).  It starts up and works, and to me, this means it's
all OK, and sandboxing is active -- except that it isn't.  Conversely,
a complete failure to run will force the administrator to investigate
the issue.  And the (prospective) error message will hint them to
consciously disable that feature (comment it out).

On the other hand, a warning could be better precisely because it won't
require the use to comment stuff out: since unit files are conffiles (I
think), the next upgrade of system which gets the feature fixed will
not affect the unit files where usage of that fealure was disabled.

On yet another hand (the 3rd?), I suppose by the time Stretch comes out,
we should have no units making use of RestrictAddressFamilies in the
packages Debian ships, and the problem then affects only non-Debian
packages and the units created by hand.


On a side note, one of the things I sold on of the Go programming
language is the stance of its developer on the warnings produced by the
compiler: it produces none.  To cite the relevant bit of the FAQ [1]:

| There are two reasons for having no warnings. First, if it's worth
| complaining about, it's worth fixing in the code. (And if it's not
| worth fixing, it's not worth mentioning.)  Second, having the compiler
| generate warnings encourages the implementation to warn about weak
| cases that can make compilation noisy, masking real errors that
| should be fixed.

I personally couldn't agree more but OTOH I'm aware that this is merely
a PoV and different PoVs do exist, hence just voicing mine ;-)

1. https://golang.org/doc/faq#unused_variables_and_imports

Bug#849726: Cloning #849726

[Konstantin Khomoutov]

clone 849726 -1
reassign -1 systemd
retitle -1 Please make systemd fail to accept RestrictAddressFamilies on 32-bit 
arches
severity -1 importan
thanks

I think it's better to move discussion of this particular issue
to its own dedicated bug filed against systemd, hence doing that.

Bug#849726: mpd: On i686, RestrictNamespaces=yes in Systemd unit does not allow mpd to open sockets

[Konstantin Khomoutov]

On Sat, 31 Dec 2016 09:29:18 +0100
Michael Biebl  wrote:

Hi, Michael!

Thanks for cooperating!

> > After upgrading an i686 machine running mpd from Jessie to Stretch,
> > I noticed mpd won't start -- exiting with return code 1 early at
> > startup:
[...]
> > Finally this spotted the problem which is the
> > 
> >   RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX AF_NETLINK
> > 
[...]
> > option.  With it being commented out, mpd starts OK.
> > So it appears you'd better comment that option as well for now of
> > ship a dedicated unit files specifically for i686 systems if this is
> > possible.
> > 
> > OTOH, upstream appears to have some developments on [1], so maybe
> > asking systemd maintainers on whether it's possible to integrate
> > some upstream fix for this seccomp issue is worthwhile.
> 
> Your analysis seems to be correct. Until systemd is fixed, you should
> not use RestrictAddressFamilies=
> 
> I'm not sure whether we will get v233 for stretch and if backporting
> those upstream fixes for v232 is feasible.

Would it be possible then to temporarily patch systemd as will be
shipped in Stretch to just fail loading the unit with a descriptive
error message if it contains the RestrictAddressFamilies directive *and*
systemd is running on a 32-bit architecture (I think we have i686 and
x32 by now)?

I mean, it's easy to patch mpd package to exclude this directive, but
people routinely use the init subsystem to host their own stuff.
I think we can clearly state that this particular feature of systemd is
currently broken on 32-bit; while that's not a big deal in itself (this
feature is not critical for the functioning of system) using it can
mysteriously and silently break your setup.  (Please note that I'm a
professional software developer who understands what syscalls are,
knows about seccomp, is able to use certain debugging tools etc; we
can't expect this level of expertise from a conventional system
administrator or hobbyist.)

Failing to execute (or otherwise load for procesing) a unit which will
exhibit this bug for sure would make the problem apparent right away
for whoever wrote (or installed from a source outside of Debian) such a
unit.

Bug#849726: mpd: On i686, RestrictNamespaces=yes in Systemd unit does not allow mpd to open sockets

[Konstantin Khomoutov]

On Sat, 31 Dec 2016 09:10:28 +0100
Max Kellermann  wrote:

Hi, Max!

> > | 4938  socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = -1
> > | EPROTONOSUPPORT (Protocol not supported) 4938  exit_group
> > | (1) = ? 4938  +++ exited with 1 +++
> 
> There are two problems with your findings:
> 
> 1. MPD does not contain any code which creates SOCK_DGRAM, even less
>so with AF_UNIX.  This is not MPD!
> 

It seems like you're (part of) upstream for mpd, so I'm a bit at a loss
confronting your rebuttal but still here's my take ;-)

It appears that mpd loads pretty a number of libraries at startup; at
least on Debian.  At least I've spotted libsmbclient [*] and something
related to avahi (running mpd with the "-v" command-line option
helped me with this).

So I'm inclined to think that's supposedly not mpd but rather some of
the libraries it pulled in and called out to some of their
initialization code.

> 2. Any time MPD exits due to a failure, it will print an error
>message.  This process does not.  Again, what you see here is not
>MPD!

I'm not sure a sane library would call exit(1) or something like this
on its initialization failure but I reckon mpd might have some code
path initializing some library which it just does not expect to fail
ever.

Unfortunately, the `strace` tool only intercepts syscalls (or even libc
wrappers around them? -- I don't know for sure) so it's unable to tell
which code was executing when it recorded an access to that syscall.
Properly figuring this out requires actually running mpd under
Debian's current systemd with unmodified unit's settings and then
somehow attaching gdb to it, setting a breakpoint on socket() and
figuring one what code path led to that one which makes mpd quit.

Unfortunately, I have too much work on my hands ATM so I can't properly
investigate this issue myself (even though I'm into this sort of
things, really) but may be you could grab some Vargant image with
Debian/i686 and play with it?  Or, I think, it's possible to ask for
restricted access to one of "porter boxes" of the Debian infrastructure
running i686 H/W.  Oh, and I personally have one such box accepting SSH
from the internets, so just ask ;-)

> 3. Why do you get EPROTONOSUPPORT even though AF_UNIX is allowed?  Not
>a MPD bug, but maybe a systemd bug.

As I gather from [1], using RestrictAddressFamilies in a systemd unit
file makes systemd use the so-called seccomp subsystem of the Linux
kernel which allows filtering of syscalls [2].  Apparently the code
systemd uses for this is broken on i386 (i686 at least).

As you can see, with seccomp filtering enabled the wrong way, a syscall
which looks otherwise fine will mysteriously fail; I reckon that's what
we're observing.


[*] For me, the journey with this mpd bug started with mpd mysteriously
writing

| Unknown option encountered "printer admin"
| Ignoring unknown parameter "printer admin"

to its stdout.  As usually, googling gor the exact error message turned
out it's a problem with my (very old) SAMBA configuration file for the
SAMBA server instance running on that same box hosting mpd.  That's how
I discovered mpd loads libsmbclient at startup.


1. https://github.com/systemd/systemd/issues/4575
2. https://lwn.net/Articles/656307/

Bug#849726: mpd: On i686, RestrictNamespaces=yes in Systemd unit does not allow mpd to open sockets

[Konstantin Khomoutov]

Package: mpd
Version: 0.19.21-1
Severity: important

Hi!

After upgrading an i686 machine running mpd from Jessie to Stretch,
I noticed mpd won't start -- exiting with return code 1 early at
startup:

| Dec 30 10:16:52 jukebox systemd[1]: [/lib/systemd/system/mpd.service:25] 
Unknown lvalue 'RestrictNamespaces' in section 'Service'
| Dec 30 10:16:54 jukebox systemd[1]: Started Music Player Daemon.
| Dec 30 10:16:55 jukebox mpd[4936]: config_file: loading file /etc/mpd.conf
| Dec 30 10:16:55 jukebox systemd[1]: mpd.service: Main process exited, 
code=exited, status=1/FAILURE
| Dec 30 10:16:55 jukebox systemd[1]: mpd.service: Unit entered failed state.
| Dec 30 10:16:55 jukebox systemd[1]: mpd.service: Failed with result 
'exit-code'.

Running

  /usr/bin/mpd --no-daemon -v /etc/mpd.conf

by hand as root worked OK, so I've changed the ExecStart parameted in
the Systemd unit to

  /usr/bin/strace -o /tmp/mpd.log -f /usr/bin/mpd --no-daemon -v $MPDCONF

commented out all the system protection options, then started to
uncomment them one by one -- attempting to start the unit each time
(with proper invocations of `systemctl daemon-reload` in between).

Finally this spotted the problem which is the

  RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX AF_NETLINK

option.  With it being commented out, mpd starts OK.

Analyzing the strace output for relevant problems brought up several
attempts at opening sockets -- of types AF_UNIX and AF_INET.
Several of such failed attempts apparently get ignored by mpd, but the
last one actually makes it exit (silently for whatever reason) but with
the result code of 1.
The last lines of the strace's output are:

| 4938  socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = -1 EPROTONOSUPPORT 
(Protocol not supported)
| 4938  exit_group(1) = ?
| 4938  +++ exited with 1 +++

and the result of grepping it for EPROTONOSUPPORT is:

| 4743  socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = -1 
EPROTONOSUPPORT (Protocol not supported)
| 4743  socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = -1 
EPROTONOSUPPORT (Protocol not supported)
| 4743  socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = -1 
EPROTONOSUPPORT (Protocol not supported)
| 4743  socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = -1 
EPROTONOSUPPORT (Protocol not supported)
| 4743  socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 
-1 EPROTONOSUPPORT (Protocol not supported)
| 4743  socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = -1 EPROTONOSUPPORT 
(Protocol not supported)


As to the essense of this but, it rather appears to affect Systemd v232
(as shipped by Stretch) specifically on i686 systems [1].

That bug's thread mentions [2], so I've added the unstable repository
and attempted to install systemd from there via

  apt install -t unstable systemd

but it told me the package I have installed is already the newest
version, and its changelog has the following snippet:

8<
systemd (232-2) unstable; urgency=medium

  * Drop RestrictAddressFamilies from service files.
RestrictAddressFamilies= is broken on 32bit architectures and causes
various services to fail with a timeout, including
systemd-udevd.service.
While this might actually be a libseccomp issue, remove this option for
now until a proper solution is found. (Closes: #843160)

 -- Michael Biebl   Sat, 05 Nov 2016 22:43:27 +0100
8<

So it appears you'd better comment that option as well for now of ship
a dedicated unit files specifically for i686 systems if this is
possible.

OTOH, upstream appears to have some developments on [1], so maybe asking
systemd maintainers on whether it's possible to integrate some upstream
fix for this seccomp issue is worthwhile.


Thanks!


1. https://github.com/systemd/systemd/issues/4575
2. https://bugs.debian.org/843160


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

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

Versions of packages mpd depends on:
ii  adduser   3.115
ii  init-system-helpers   1.46
ii  libadplug-2.2.1-0v5   2.2.1+dfsg3-0.3
ii  libao41.2.2-1
ii  libasound21.1.2-1
ii  libaudiofile1 0.3.6-3
ii  libavahi-client3  0.6.32-1
ii  libavahi-common3  0.6.32-1
ii  libavcodec57  7:3.2.2-1
ii  libavformat57 7:3.2.2-1
ii  libavutil55   7:3.2.2-1
ii  libbz2-1.01.0.6-8
ii  libc6 2.24-8
ii  libcdio-cdda1 0.83-4.2+b1
ii  libcdio-paranoia1 0.83-4.2+b1
ii  libcdio13 0.83-4.2+b1
ii  libcurl3-gnutls   7.51.0-1
ii  libdbus-1-3  

Bug#849296: [Pkg-samba-maint] Bug#849296: libsmbclient-dev: Incorrect version (0.2.1 instead of 4.2.14) in pkgconfig/smbclient.pc

[Konstantin Gribov]

Sorry folks, I take it back.

They are exposing ABI version instead of Samba version, so Debian
`libsmbclient-dev` is perfectly OK.
Issue can be closed. I'll take care of that on my side and will look for
ways to improve it in Samba docs.

вс, 25 дек. 2016 г. в 19:52, Mathieu Parent <math.par...@gmail.com>:

> Control: tag -1 + moreinfo
> Control: severity -1 normal
>
> 2016-12-24 23:31 GMT+01:00 Konstantin Gribov <gros...@gmail.com>:
> > Package: libsmbclient-dev
> > Version: 2:4.2.14+dfsg-0+deb8u2
> > Severity: important
> >
> > Hello, Debian maintainers.
>
> Hello,
>
> >
> > -- Steps to reproduce:
> > $ apt-get install -y libsmbclient-dev pkg-config
> > $ pkg-config --cflags --libs 'smbclient >= 4.0'
> > Requested 'smbclient >= 4.0' but version of smbclient is 0.2.1
> > You may find new versions of smbclient at http://www.samba.org/
> > $ pkg-config --modversion smbclient
> > 0.2.1
>
> What do you want to do (what is your intention)? Here we behave like
> upstream.
>
> Regards
> --
> Mathieu Parent
>
-- 

Best regards,
Konstantin Gribov

Bug#849296: libsmbclient-dev: Incorrect version (0.2.1 instead of 4.2.14) in pkgconfig/smbclient.pc

[Konstantin Gribov]

Package: libsmbclient-dev
Version: 2:4.2.14+dfsg-0+deb8u2
Severity: important

Hello, Debian maintainers.

-- Steps to reproduce:
$ apt-get install -y libsmbclient-dev pkg-config
$ pkg-config --cflags --libs 'smbclient >= 4.0'
Requested 'smbclient >= 4.0' but version of smbclient is 0.2.1
You may find new versions of smbclient at http://www.samba.org/
$ pkg-config --modversion smbclient
0.2.1

-- Expected output:
$ pkg-config --cflags --libs 'smbclient >= 4.0'
-I/usr/include/samba-4.0 -lsmbclient
$ pkg-config --modversion smbclient
4.2.14

-- Patch:
--- /usr/lib/x86_64-linux-gnu/pkgconfig/smbclient.pc2016-12-17
20:07:34.0 +
+++ smbclient.pc2016-12-24 22:26:04.517089847 +
@@ -5,7 +5,7 @@

Name: smbclient
Description: A SMB library interface
-Version: 0.2.1
+Version: 4.2.14
Libs:  -L${libdir} -lsmbclient
Cflags: -I${includedir}
URL: http://www.samba.org/

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

Kernel: Linux 4.8.13-1-ARCH (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages libsmbclient-dev depends on:
ii  dpkg  1.17.27
ii  libsmbclient  2:4.2.14+dfsg-0+deb8u2

libsmbclient-dev recommends no packages.

libsmbclient-dev suggests no packages.

-- no debconf information

Additional notes:
- Debian is running in Docker container but it doesn't change anything for
this bug.

-- 

Best regards,
Konstantin Gribov

Bug#847524: ITP: distributed -- Dask Distributed computing for Python

[Konstantin Khomoutov]

On Fri, 09 Dec 2016 00:23:56 -0800
Diane Trout  wrote:

> I agree its a terribly generic name.
> 
> Usually, debianized python packages use the upstream name foo as the
> source name and then python-foo as the binary name. especially when
> foo is the module you import in python.
> 
> But considering distributed is so generic I too was tempted to name
> the python-dask-distributed. I asked on #debian-python, but they
> suggested use the name you use in the import.
> 
> I'll see if I can get some of the more experienced people in the
> Python Modules team to weigh in on the name.
> 
> Upstream sometimes uses dask.distributed in the documentation, which
> might be a better choice.

Well, generic names are better shot early in their flight into the
archive -- otherwise we get somewhat painful situations like, say, the
"node" package which those 100500 JavaScript developers take for
granted to denote their favourite server-side scripting engine while
Debian uses this name for a package working with amateur radio stuff.

In the past, there were (way less painful) issues with the names
"chromium" and "git", and I'm sure silver-bearded veterans would come up
with more examples. ;-)

That's what triggered my response.

[...]
> Also thank you for taking the time to review my ITPs. I didn't realize
> that people watched the bugs.

The ITP bugs are Cc'ed to the debian-devel mailing list.
The reason is exactly this: iexperienced maintainers usually do routine
bloopers which can be easily caught by a trained eye and pointed at
right away.

Also, there's the first (and cheap to have) "line of defence" against
packaging of software which is in outright bad shape or software
with an apparent licensing issue or software which already has an ITP
bug filed and so on.

Bug#847524: ITP: distributed -- Dask Distributed computing for Python

[Konstantin Khomoutov]

On Fri, 09 Dec 2016 11:57:06 -0800
Diane Trout  wrote:

> > > Package: wnpp
> > > Severity: wishlist
> > > Owner: Diane Trout 
> > > 
> > > * Package name: distributed
> > 
> 
> I spent some time discussing this on #debian-python.
> 
> What do you think of:
> 
> Source package name: dask.distributed
> Binary package name: python3-distributed
> 
> Debian Python policy says the name after the - should be the import
> name. But at least the python prefix provides a namespace.

I think these names are fine:

* They don't violate the Policy.
* The binary package's name clearly refers to Python 3
  and is "namespaced".

Well, to be honest, I don't like the dot in the source package's name
but I wholly admit this is absolutely an aesthetic thing :-)
(Being a programmer, I have a certain set of skews related to dots in
identifiers of various types of things.)

TL;DR
The names appear to be just fine.

Bug#847524: ITP: distributed -- Dask Distributed computing for Python

[Konstantin Khomoutov]

On Thu, 08 Dec 2016 16:20:15 -0800
Diane Trout  wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Diane Trout 
> 
> * Package name: distributed

The package's name is really unfortunate: the word "distributed" is too
broad, and in our era of everything distributed squatting on it is a
very bad idea IMO.  Please consider naming it dask-distributed
or python-dask-distributed instead.

I would say the same applies to the prospective packages of the
dependencies of this one: sticking "python-" in front of their names
would be a sensible thing to do -- just do

  $ apt search ^python-

to get an overview.

>   Version : 1.14.3
>   Upstream Author : Matthew Rocklin 
> * URL : https://distributed.readthedocs.io/en/latest/
> * License : BSD-3-Clause
>   Programming Lang: Python
>   Description : Dask Distributed computing for Python
> 
>  Dask.distributed is a lightweight library for distributed computing
> in Python. It extends both the concurrent.futures and dask APIs to
>  moderate sized clusters.

If this bit:

> This is the distributed component of dask, and looks really useful.
> 
> Who wouldn't want some APIs that parallize over multiple machines
> random python code, numpy and pandas?
> 

...is a part of the extended package's description, it should be
reworded: package descriptions should be neutral, dry and up to the
point.  That is, passages like "looks really useful" and "Who wouldn't
want to use this piece of software?" are unfit for the purpose.

Bug#841368: gcc-6 6.2.0-7 breaks kernel build if stack protection is enabled

[Konstantin Demin]

>> But does this generate the same output as without -enable-default-pie?
>> Some parts of the kernel do use -fpic or -fPIC. Which directive prevails?

If you call gcc with "-O3 -O0 -O1", only "-O1" option is make sence.
See attachments from recent build log (roughly speaking, Linux 4.8.4,
"make V=1" with gcc 6.2.0-9, but actually it's heavily customized
Debian src:linux with 3rd pty patches and custom configs).

>> I'm currently looking for correct way to do this trick.
Patch is available and (at least) works for me on amd64 and i386, ref msg #51

-- 
SY,
Konstantin Demin
gcc-6
-Wp,-MD,arch/x86/entry/vdso/.vdso-image-64.o.d
-nostdinc
-isystem
/usr/lib/gcc/x86_64-linux-gnu/6/include
-I/<>/arch/x86/include
-I./arch/x86/include/generated/uapi
-I./arch/x86/include/generated
-I/<>/include
-I./include
-I/<>/arch/x86/include/uapi
-I/<>/include/uapi
-I./include/generated/uapi
-include /<>/include/linux/kconfig.h
-I/<>/arch/x86/entry/vdso
-Iarch/x86/entry/vdso
-D__KERNEL__
-Wall
-Wundef
-Wstrict-prototypes
-Wno-trigraphs
-fno-strict-aliasing
-fno-common
-Werror-implicit-function-declaration
-Wno-format-security
-std=gnu89
-mno-sse
-mno-mmx
-mno-sse2
-mno-3dnow
-mno-avx
-m64
-falign-jumps=1
-falign-loops=1
-mno-80387
-mno-fp-ret-in-387
-mpreferred-stack-boundary=3
-mskip-rax-setup
-mtune=generic
-mno-red-zone
-mcmodel=kernel
-DCONFIG_X86_X32_ABI
-DCONFIG_AS_CFI=1
-DCONFIG_AS_CFI_SIGNAL_FRAME=1
-DCONFIG_AS_CFI_SECTIONS=1
-DCONFIG_AS_FXSAVEQ=1
-DCONFIG_AS_SSSE3=1
-DCONFIG_AS_CRC32=1
-DCONFIG_AS_AVX=1
-DCONFIG_AS_AVX2=1
-DCONFIG_AS_SHA1_NI=1
-DCONFIG_AS_SHA256_NI=1
-pipe
-Wno-sign-compare
-fno-asynchronous-unwind-tables
-O2
-fplugin=./scripts/gcc-plugins/cyc_complexity_plugin.so
-fomit-frame-pointer
-DCC_HAVE_ASM_GOTO
-fno-PIC
-fno-PIE
-DKBUILD_BASENAME='"vdso_image_64"'
-DKBUILD_MODNAME='"vdso_image_64"'
-c
-o arch/x86/entry/vdso/.tmp_vdso-image-64.o
arch/x86/entry/vdso/vdso-image-64.cgcc-6
-Wp,-MD,arch/x86/entry/vdso/.vclock_gettime.o.d
-nostdinc
-isystem
/usr/lib/gcc/x86_64-linux-gnu/6/include
-I/<>/arch/x86/include
-I./arch/x86/include/generated/uapi
-I./arch/x86/include/generated
-I/<>/include
-I./include
-I/<>/arch/x86/include/uapi
-I/<>/include/uapi
-I./include/generated/uapi
-include /<>/include/linux/kconfig.h
-I/<>/arch/x86/entry/vdso
-Iarch/x86/entry/vdso
-D__KERNEL__
-Wall
-Wundef
-Wstrict-prototypes
-Wno-trigraphs
-fno-strict-aliasing
-fno-common
-Werror-implicit-function-declaration
-Wno-format-security
-std=gnu89
-mno-sse
-mno-mmx
-mno-sse2
-mno-3dnow
-mno-avx
-m64
-falign-jumps=1
-falign-loops=1
-mno-80387
-mno-fp-ret-in-387
-mpreferred-stack-boundary=3
-mskip-rax-setup
-mtune=generic
-mno-red-zone
-mcmodel=kernel
-DCONFIG_X86_X32_ABI
-DCONFIG_AS_CFI=1
-DCONFIG_AS_CFI_SIGNAL_FRAME=1
-DCONFIG_AS_CFI_SECTIONS=1
-DCONFIG_AS_FXSAVEQ=1
-DCONFIG_AS_SSSE3=1
-DCONFIG_AS_CRC32=1
-DCONFIG_AS_AVX=1
-DCONFIG_AS_AVX2=1
-DCONFIG_AS_SHA1_NI=1
-DCONFIG_AS_SHA256_NI=1
-pipe
-Wno-sign-compare
-fno-asynchronous-unwind-tables
-O2
-fomit-frame-pointer
-DCC_HAVE_ASM_GOTO
-fno-PIC
-fno-PIE
-mcmodel=small
-fPIC
-O2
-fasynchronous-unwind-tables
-m64
-fno-stack-protector
-fno-omit-frame-pointer
-foptimize-sibling-calls
-DDISABLE_BRANCH_PROFILING
-DBUILD_VDSO
-DKBUILD_BASENAME='"vclock_gettime"'
-DKBUILD_MODNAME='"vclock_gettime"'
-c
-o arch/x86/entry/vdso/.tmp_vclock_gettime.o
/<>/arch/x86/entry/vdso/vclock_gettime.c

Bug#841368: gcc-6 6.2.0-7 breaks kernel build if stack protection is enabled

[Konstantin Demin]

>> I disagree: you fix debian code but upstream kernel is also affected.
>> I wanted to compile the upstream 4.4.26 for the COW fixe and cannot.
>> Please revert.

$ rmadison linux
linux  | 4.5.5-1  | unstable| source
linux  | 4.5.5-1  | unstable-debug  | source
linux  | 4.6.4-1  | unstable| source
linux  | 4.6.4-1  | unstable-debug  | source
linux  | 4.7.5-1~bpo8+2   | jessie-backports| source
linux  | 4.7.5-1  | unstable| source
linux  | 4.7.6-1  | testing | source
linux  | 4.7.8-1~bpo8+1   | buildd-jessie-backports | source
linux  | 4.7.8-1~bpo8+1   | jessie-backports| source
linux  | 4.7.8-1  | buildd-unstable | source
linux  | 4.7.8-1  | unstable| source
linux  | 4.7.8-1  | unstable-debug  | source

You should be noted that building kernel from vanilla source isn't
good idea in Debian.
I don't see any 4.4 branch in Debian sources, but you may use git tag
"debian/4.4.6-1" as base for your own work/fork.

Happy hacking!

PS:
I can't understand why you're mixing GCC 6.x release (_unstable_) and
Linux kernel 4.4.x long-term support (_stable_).
If you're targeting on stable workflow, use GCC 5.x or even 4.9.x
instead of 6.x branch.

-- 
SY,
Konstantin Demin

Bug#841368: gcc-6 6.2.0-7 breaks kernel build if stack protection is enabled

[Konstantin Demin]

2016-10-21 1:49 GMT+03:00 Ben Hutchings <b...@decadent.org.uk>:
> It's a bug when a compiler fails to compile valid code.
>
> Ben.
>
> --
> Ben Hutchings
> Never put off till tomorrow what you can avoid all together.

Dear Ben, there are no actual bug in compiler, just a caveat to work with it.

Some time ago i had experience to build fully hardened nginx build,
and I was forced to build shared libraries with -fPIC but not -fPIE
due to linker errors.

Solution was to separate build to executable only and shared-libraries only;
this is semi-true: executable is successfully linked with -fPIC flag,
but it's not used in packaging because of executable already built with -fPIE.

This bug report is just another round of game with compiler/linker flags.
In my turn, I would rather define protective flags to provide backward
and forward compatibility.

-- 
SY,
Konstantin Demin
--- a/debian/rules.real
+++ b/debian/rules.real
@@ -168,6 +168,7 @@ else
 	echo 'override CROSS_COMPILE = $$(DEB_HOST_GNU_TYPE)-' >> '$(DIR)/.kernelvariables'
 	echo 'endif' >> '$(DIR)/.kernelvariables'
 endif
+	echo 'KCFLAGS += -fno-PIC -fno-PIE' >> '$(DIR)/.kernelvariables'
 ifdef CFLAGS_KERNEL
 	echo 'CFLAGS_KERNEL += $(CFLAGS_KERNEL)' >> '$(DIR)/.kernelvariables'
 	echo 'CFLAGS_MODULE += $(CFLAGS_KERNEL)' >> '$(DIR)/.kernelvariables'
 endif

Bug#841368: gcc-6 6.2.0-7 breaks kernel build if stack protection is enabled

[Konstantin Demin]

It's not a GCC bug but kind of new feature.

Take a look at this changelog entry:
 gcc-6 (6.2.0-7) unstable; urgency=medium

   [ Matthias Klose ]
   * Configure with --enable-default-pie and pass -z now when pie is enabled;
 on amd64 arm64 armel armhf i386 mips mipsel mips64el ppc64el s390x.
 Closes: #835148.

Starting at gcc 6.2.0-7 we must provide "-fno-PIE -fno-PIC" in
beginning of CFLAGS to build kernel successfully.

I'm currently looking for correct way to do this trick.

-- 
SY,
Konstantin Demin

Bug#841113: ITP: extremetools -- tools for running processes under extreme uid and gid

[Konstantin Khomoutov]

On Mon, 17 Oct 2016 20:15:04 +0200
Jan Mojzis  wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Jan Mojzis 
> 
> * Package name: extremetools
>   Version : 20161017
>   Upstream Author : Jan Mojžíš 
> * URL : https://github.com/janmojzis/extremetools
> * License : public-domain
>   Programming Lang: C
>   Description : tools for running processes under extreme uid and
> gid
> 
> Extremetools consists of 2 simple tools extremesetuidgid and
> extremeenvuidgid.
>  - extremesetuidgid runs program under unique (extreme) uid and gid
>  - extremeenvuidgid runs program with environment variables indicating
>unique (extreme) uid and gid
> 
> This is useful for running processes in the system under unique
> (extreme) uids/gids. So processes can't ptrace each other, can't send
> signal each other, etc ...

Could you please elaborate on that "extreme" bit?
I failed to get even a basic explanation of it both from this
description and the project files on Github.

I understand that you may be not a native English speaker so you may
well be putting a meaning into that word which is (slightly) different
from the conventional perception of what it should be. ;-)

Bug#839210: ITP: bash-unit -- bash unit testing enterprise edition framework for professionals

[Konstantin Khomoutov]

On Fri, 30 Sep 2016 08:53:05 +0200
Pascal Grange  wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Pascal Grange 
> 
> * Package name: bash-unit
>   Version : 1.0.2
>   Upstream Author : Pascal Grange 
> * URL : https://github.com/pgrange/bash-unit
> * License : GPL
>   Programming Lang: Bash
>   Description : bash unit testing enterprise edition framework
> for professionals
> 
> bash-unit is a unit testing software for bash.

What does "enterprise edition" stand for there?

I mean, in me, it provokes certain allusions (of "open core" products
etc) which are supposedly false given the indicated license, which
brings the next question of is those words are really needed?

[...]

Bug#838632: aufs-tools: move "aufs-dkms" to Recommends

[Konstantin Demin]

Package: aufs-tools
Version: 1:4.1+20160919-1
Severity: normal

Dear maintainers!

Please consider moving "aufs-dkms" dependency to "Recommends" since
some Linux kernels (official and custom) may already provide AuFS
module and DKMS module isn't required to be present in system.

-- 
SY,
Konstantin Demin

Bug#832611: ITP: tinyssh -- Tiny SSH server

[Konstantin Khomoutov]

On Wed, 27 Jul 2016 16:13:37 +0200
Jan Mojzis  wrote:

[...]
> This is tiny SSH server which implement 'less'.

This phrase reads as if that SSH server implements "less" which is a
well-known piece of software implementing full-screen paging on a
terminal.  I would hence rephrase this:

"TinySSH is a minimalistic SSH server which implements only a subset of
SSHv2 features".

> TinySSH supports only secure crypto (min 128-bit security,
> protected against cache-timing attacks).
> Unnecessary features (such SSH1 protocol, compression, scp,
> sftp,

Oh, really?  SFTP is pretty much the sole sensible way to get a file
uploaded to a remote server these days, or fetch something back.
I do understand the goals of your project reflect your own use cases
but the package description must be ambivalent which means it's not
you who decides which features are necessary and which are not.

So "Unnecessary" is supposedly not the correct word to use here,
and I would actually reverse the narration:
1) After the short description, state what the server does support.
2) Then state what is omitted.

> ...), unsafe crypto (such rsa, dsa, hmac-md5, hmac-sha1, 3des,
> arcfour, ...) and unsafe features (such password or hostbased
> authentication) are simply NOT implemented.

"such" in these cases requires "as" to become "such as".
The phrase would become "... unsafe crypto (such as rsa, dsa, ...)".

> TinySSH has less than 10 words of code, so it's very easy
> auditable.

Please change to "... very easily auditable".

On the other hand, there are two problems with this phrase.

1) It's quite subjective: "words of code" (by the way, what's this?
   typically, people tend to measure lines of code) is too abstract.
   100k words of tangled mess might be harder to audit than 200k words
   of lucid code, you know ;-)

2) "Auditable" is not "audited".  OpenSSH might be N times larger,
   but it was audited, and actually is under constant scrutiny of
   various folks.

Hence I'd just drop this bit or at least change it to something like
"...should be relatively easy to audit".

Overall, please comb the description text to replace abbreviations
(crypto → cryptography, min → minimal / minimum / whatever applicable
etc) and refrain from "it's" in place of "it is".

Bug#832443: ITP: mergerfs -- mergerfs is a union filesystem geared towards simplifing storage

[Konstantin Khomoutov]

On Mon, 25 Jul 2016 20:21:48 +0530
Ritesh Raj Sarraf  wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Ritesh Raj Sarraf 
> 
> * Package name: mergerfs
>   Version : 2.14.0
>   Upstream Author : Antonio SJ Musumeci 
> * URL : http://github.com/trapexit/mergerfs
> * License : ISC
>   Programming Lang: C++
>   Description : mergerfs is a union filesystem geared towards
> simplifing storage
> 
>  mergerfs is a union filesystem geared towards simplifing storage 

I supposed it should be "simplifying" in both cases.

> and management of files across numerous commodity storage devices. It
> is similar to mhddfs, unionfs, and aufs.
> 
>  Some salient features include
>  * Runs in userspace (FUSE)
>  * Configurable behaviors
>  * Support for extended attributes (xattrs)
>  * Support for file attributes (chattr)
>  * Runtime configurable (via xattrs)
>  * Safe to run as root
>  * Opportunistic credential caching
>  * Works with heterogeneous filesystem types
>  * Handling of writes to full drives

What does this mean?  Drives with no more room to write data left?

>  * Handles pool of readonly and read/write drives

Bug#831628: ITP: souffle -- a translator of declarative Datalog programs into the C++ programming language

[Konstantin Vorobyov]

Package: wnpp
Severity: wishlist
Owner: Konstantin Vorobyov <k.a.vorob...@gmail.com>

* Package name: souffle
  Version : 1.0.0
  Upstream Author : Konstantin Vorobyov <k.a.vorob...@gmail.com>
* URL : http://souffle-lang.github.io/
* License : (UPL)
  Programming Lang: (C++)
  Description : a translator of declarative Datalog programs into the C++
programming language

Souffle is a translator of declarative Datalog programs into the C++ language.
Souffle is used as a domain-specific language for static program analysis, over
large code bases with millions of lines of code. Souffle aims at producing
high-performance C++ code that can be compiled with the native compiler on the
target machine.

Features of Souffle:
- Efficient translation to parallel C++ of Datalog programs
- Extended semantics of Safe Datalog, e.g., permitting unbounded recursions
with numbers
- Simple component model for Datalog specifications
- Recursively defined record types for tuples
- Static type system for attributes

Souffle is not a dependency for another package but a standalone tools which
consumes specification written in Datalog, translates it into a C++ program and
generates an executable using a G++ compiler.

More information about Souffle including its relevance, use cases and the
community around Souffle can be found at the https://github.com/souffle-
lang/souffle/wiki.

There exists a several tools capable of executing Datalog programs. Some of the
most significant efforts are muZ, bddbddb and LogicBlox. However muZ and
bddbddb have performance issues when computing large Datalog programs, while
LogicBlox has licensing restrictions and not free software. To the best of our
knowledge no datalog translator is a part of Debian yet.

Souffle is developed and maintained by a group of researchers and developers
who use the software in their research or were a part of the Souffle project at
one point or another. The core of this group is a part of the School of the
Information Technologies at the University of Sydney.

Bug#501456: dpkg-deb: Add new option --compress-program=

[Konstantin Khlebnikov]

Here is tiny patch which adds new option dpkg-deb --compress-program=
Program is executed as a filter with single argument: compression level -0 .. -9

So, any existing parallel compression tool (pigz/pbzip2/pxz/pixz)
could be used here.
Of course compression type (-Z) must match. Such compression might not
suit for official
builds because it have lower ratio, but will save tons of time for
building debug packages.


dpkg-deb-add-new-option-compress-program-prog
Description: Binary data

Bug#825747: libebl.a is missing but required by libdw.a

[Konstantin Khlebnikov]

Package: libdw-dev
Version: 0.163-5.1

It would be nice to put libebl.a into libdw-dev. libdw.a is useless without it.

Big fat user is a "perf" from linux tools. It evolves rapidly and had
a lot of dependecies so
static linking is very useful here for bringing new functionality into
older systems.
Perf makefiles  already have hardcoeded linking rules for static libdw because
fedora had similar problems in the past.

blind@zurg:~$ dpkg -L libdw-dev
/.
/usr
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/libdw.a
/usr/share
/usr/share/doc
/usr/share/doc/libdw-dev
/usr/share/doc/libdw-dev/changelog.Debian.gz
/usr/share/doc/libdw-dev/changelog.gz
/usr/share/doc/libdw-dev/copyright
/usr/include
/usr/include/elfutils
/usr/include/elfutils/libdwfl.h
/usr/include/elfutils/libdwelf.h
/usr/include/elfutils/libdw.h
/usr/include/elfutils/known-dwarf.h
/usr/include/dwarf.h
/usr/lib/x86_64-linux-gnu/libdw.so

blind@zurg:~$ nm /usr/lib/x86_64-linux-gnu/libdw.a | grep ebl
dwarf_lineblock.o:
 T dwarf_lineblock
 U ebl_abi_cfi
 U ebl_openbackend
 U ebl_closebackend
 U ebl_debugscn_p
 U ebl_get_elfmachine
 U ebl_reloc_simple_type
 U __libdwfl_module_getebl
 U ebl_openbackend
1ef0 T __libdwfl_module_getebl
 U __libdwfl_module_getebl
 U __libdwfl_module_getebl
 U ebl_func_addr_mask
 U ebl_resolve_sym_value
 U __libdwfl_module_getebl
 U ebl_return_value_location
 U __libdwfl_module_getebl
 U ebl_register_info
 U __libdwfl_module_getebl
 U ebl_abi_cfi
 U ebl_closebackend
 U ebl_frame_nregs
 U ebl_openbackend
 U __libdwfl_module_getebl
 U ebl_dwarf_to_regno
 U ebl_frame_nregs
 U ebl_func_addr_mask
 U ebl_get_elfclass
 U ebl_unwind
 U ebl_normalize_pc
 U ebl_get_elfclass
 U ebl_set_initial_registers_tid
 U ebl_closebackend
 U ebl_core_note
 U ebl_frame_nregs
 U ebl_get_elfclass
 U ebl_openbackend

Bug#813782: python-matplotlib-venn: FTBFS: [failed test] Intersection with the arc along the same circle (which means infinitely many points usually) is reported as no intersection at all.

[Konstantin Tretjakov]

I can't reproduce the bug (apparently it's architecture- or machine-specific), but it is 
indeed due to rounding errors. I modified the test to address this problem and hopefully 
it fixes it.


The updated code is in in github as well as pypi.

Best regards,
Konstantin.

On 13.02.2016 8:01, Andreas Tille wrote:

Hi,

as you can read below,  one test of the test suite fails.  As far as I
can see it is possibly a rounding issue rather than a failure.  I wonder
how the test could be tweaked to pass successfully if you share my
opinion or what else could be done to pass the test suite successfully.

Kind regards

  Andreas.

On Fri, Feb 05, 2016 at 09:37:32AM +0100, Chris Lamb wrote:

Source: python-matplotlib-venn
Version: 0.11-2
Severity: serious

Dear Maintainer,

python-matplotlib-venn fails to build from source in unstable/amd64:

   [..]

   running test
   running egg_info
   creating matplotlib_venn.egg-info
   writing requirements to matplotlib_venn.egg-info/requires.txt
   writing matplotlib_venn.egg-info/PKG-INFO
   writing top-level names to matplotlib_venn.egg-info/top_level.txt
   writing dependency_links to matplotlib_venn.egg-info/dependency_links.txt
   writing manifest file 'matplotlib_venn.egg-info/SOURCES.txt'
   warning: manifest_maker: standard file 'setup.py' not found

   reading manifest file 'matplotlib_venn.egg-info/SOURCES.txt'
   writing manifest file 'matplotlib_venn.egg-info/SOURCES.txt'
   running build_ext
   = test session starts 
==
   platform linux2 -- Python 2.7.11, pytest-2.8.5, py-1.4.31, pluggy-0.3.1 -- 
/usr/bin/python2.7
   cachedir: ../../../.cache
   rootdir: 
/home/lamby/temp/cdt.20160205085405.L1EHTA93Fx/python-matplotlib-venn-0.11, 
inifile: setup.cfg
   collecting ... collected 49 items

   matplotlib_venn/_arc.py::matplotlib_venn._arc.Arc.__init__ PASSED
   matplotlib_venn/_arc.py::matplotlib_venn._arc.Arc.angle_as_point PASSED
   ...
   matplotlib_venn/_venn3.py::matplotlib_venn._venn3.venn3 PASSED
   matplotlib_venn/_venn3.py::matplotlib_venn._venn3.venn3_circles PASSED

   === FAILURES 
===
   ___ [doctest] matplotlib_venn._arc.Arc.intersect_arc 
___
   339 Intersection with the arc along the same circle (which means 
infinitely many points usually) is reported as no intersection at all.
   340
   341 >>> a = Arc((0, 0), 1, -90, 90, True)
   342 >>> a.intersect_arc(Arc((1, 0), 1, 90, 270, True))
   343 [array([ 0.5  , -0.866...]), array([ 0.5  ,  0.866...])]
   344 >>> a.intersect_arc(Arc((1, 0), 1, 90, 180, True))
   345 [array([ 0.5  ,  0.866...])]
   346 >>> a.intersect_arc(Arc((1, 0), 1, 121, 239, True))
   347 []
   348 >>> a.intersect_arc(Arc((1, 0), 1, 120, 240, True))
   Expected:
   [array([ 0.5  , -0.866...]), array([ 0.5  ,  0.866...])]
   Got:
   [array([ 0.5  ,  0.8660254])]

   
/home/lamby/temp/cdt.20160205085405.L1EHTA93Fx/python-matplotlib-venn-0.11/.pybuild/pythonX.Y_2.7/build/matplotlib_venn/_arc.py:348:
 DocTestFailure
   = 1 failed, 48 passed in 0.51 seconds 
==
   E: pybuild pybuild:274: test: plugin custom failed with: exit code=1: cp -a README.rst 
/home/lamby/temp/cdt.20160205085405.L1EHTA93Fx/python-matplotlib-venn-0.11/.pybuild/pythonX.Y_2.7/build 
&& cd 
/home/lamby/temp/cdt.20160205085405.L1EHTA93Fx/python-matplotlib-venn-0.11/.pybuild/pythonX.Y_2.7/build 
&& python2.7 
/home/lamby/temp/cdt.20160205085405.L1EHTA93Fx/python-matplotlib-venn-0.11/setup.py test && rm 
README.rst
   dh_auto_test: pybuild --test --test-pytest -i python{version} -p 2.7 --test --system=custom 
--test-args=cp -a README.rst {home_dir}/build && cd {home_dir}/build && {interpreter} 
/home/lamby/temp/cdt.20160205085405.L1EHTA93Fx/python-matplotlib-venn-0.11/setup.py test && rm 
README.rst --dir . returned exit code 13

Bug#807120: Deprecate mod_rpaf, transition to mod_remoteip

[Konstantin Pavlov]

The problem with mod_remoteip is that it is currently (first reported in
2013 [1]) broken in a setup where apache 2.4 is used behind a reverse
proxy.  remoteip module changes the client IP address (%a) but does not
change the host name (%h or REMOTE_HOST passed to other modules,
resolved via HostNameLookups On/Double).

apache2 2.4.10-10+deb8u4 and libapache2-mod-rpaf=0.6-13 do not suffer
from that problem.

[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=55348

-- 
Konstantin Pavlov

Bug#808124: r8168: upstream version 8.041.00

[Konstantin Demin]

Source: r8168
Version: 8.040.00-1
Severity: wishlist

PS: here is another mirror: https://github.com/mtorromeo/r8168

---
 debian/changelog |  6 
 src/r8168.h  |  2 +-
 src/r8168_n.c| 87 
 3 files changed, 69 insertions(+), 26 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 1ab4d87..f733c9e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+r8168 (8.041.00-1) UNRELEASED; urgency=high
+
+  * New upstream release 8.041.00 (2015-12-08).
+
+ -- Konstantin Demin <rockdri...@gmail.com>  Wed, 16 Dec 2015 12:26:56 +0300
+
 r8168 (8.040.00-1) unstable; urgency=medium
 
   * New upstream release 8.040.00 (2015-05-14).
diff --git a/src/r8168.h b/src/r8168.h
index 33afc6c..a4c7077 100755
--- a/src/r8168.h
+++ b/src/r8168.h
@@ -141,7 +141,7 @@
 #define NAPI_SUFFIX ""
 #endif
 
-#define RTL8168_VERSION "8.040.00" NAPI_SUFFIX
+#define RTL8168_VERSION "8.041.00" NAPI_SUFFIX
 #define MODULENAME "r8168"
 #define PFX MODULENAME ": "
 
diff --git a/src/r8168_n.c b/src/r8168_n.c
index 8b08e63..d197630 100755
--- a/src/r8168_n.c
+++ b/src/r8168_n.c
@@ -297,7 +297,7 @@ static struct pci_device_id rtl8168_pci_tbl[] = {
 
 MODULE_DEVICE_TABLE(pci, rtl8168_pci_tbl);
 
-static int rx_copybreak = 200;
+static int rx_copybreak = 0;
 static int timer_count = 0x2600;
 
 static struct {
@@ -3241,9 +3241,11 @@ rtl8168_init_pci_offset_99(struct rtl8168_private *tp)
 
 switch (tp->mcfg) {
 case CFG_METHOD_26:
-csi_tmp = rtl8168_eri_read(ioaddr, 0x5C2, 1, ERIAR_ExGMAC);
-csi_tmp &= ~BIT_1;
-rtl8168_eri_write(ioaddr, 0x5C2, 1, csi_tmp, ERIAR_ExGMAC);
+if (tp->org_pci_offset_99 & BIT_2) {
+csi_tmp = rtl8168_eri_read(ioaddr, 0x5C2, 1, 
ERIAR_ExGMAC);
+csi_tmp &= ~BIT_1;
+rtl8168_eri_write(ioaddr, 0x5C2, 1, csi_tmp, 
ERIAR_ExGMAC);
+}
 break;
 }
 
@@ -3272,9 +3274,19 @@ rtl8168_init_pci_offset_99(struct rtl8168_private *tp)
 
 switch (tp->mcfg) {
 case CFG_METHOD_26:
-csi_tmp = rtl8168_eri_read(ioaddr, 0x5C8, 1, ERIAR_ExGMAC);
-csi_tmp |= BIT_0;
-rtl8168_eri_write(ioaddr, 0x5C8, 1, csi_tmp, ERIAR_ExGMAC);
+rtl8168_eri_write(ioaddr, 0x5C0, 1, 0xFA, ERIAR_ExGMAC);
+break;
+}
+
+switch (tp->mcfg) {
+case CFG_METHOD_26:
+case CFG_METHOD_29:
+case CFG_METHOD_30:
+if (tp->org_pci_offset_99 & BIT_2) {
+csi_tmp = rtl8168_eri_read(ioaddr, 0x5C8, 1, 
ERIAR_ExGMAC);
+csi_tmp |= BIT_0;
+rtl8168_eri_write(ioaddr, 0x5C8, 1, csi_tmp, 
ERIAR_ExGMAC);
+}
 break;
 }
 
@@ -3306,18 +3318,6 @@ rtl8168_init_pci_offset_99(struct rtl8168_private *tp)
 }
 
 switch (tp->mcfg) {
-case CFG_METHOD_26:
-case CFG_METHOD_29:
-case CFG_METHOD_30:
-RTL_W8(0xB6, RTL_R8(0xB6) | BIT_0);
-
-csi_tmp = rtl8168_eri_read(ioaddr, 0x5C8, 1, ERIAR_ExGMAC);
-csi_tmp |= BIT_0;
-rtl8168_eri_write(ioaddr, 0x5C8, 1, csi_tmp, ERIAR_ExGMAC);
-break;
-}
-
-switch (tp->mcfg) {
 case CFG_METHOD_21:
 case CFG_METHOD_22:
 case CFG_METHOD_24:
@@ -3331,6 +3331,15 @@ rtl8168_init_pci_offset_99(struct rtl8168_private *tp)
 break;
 }
 
+switch (tp->mcfg) {
+case CFG_METHOD_26:
+case CFG_METHOD_29:
+case CFG_METHOD_30:
+if (tp->org_pci_offset_99 & BIT_2)
+RTL_W8(0xB6, RTL_R8(0xB6) | BIT_0);
+break;
+}
+
 rtl8168_enable_pci_offset_99(tp);
 }
 
@@ -4841,7 +4850,7 @@ static int rtl8168_enable_EEE(struct rtl8168_private *tp)
 case CFG_METHOD_28:
 OOB_mutex_lock(tp);
 data = mac_ocp_read(tp, 0xE052);
-data |= BIT_0;
+data &= ~BIT_0;
 mac_ocp_write(tp, 0xE052, data);
 OOB_mutex_unlock(tp);
 data = mac_ocp_read(tp, 0xE056);
@@ -4861,7 +4870,8 @@ static int rtl8168_enable_EEE(struct rtl8168_private *tp)
 mdio_write(tp, 0x10, data);
 
 mdio_write(tp, 0x1F, 0x0A44);
-data = mdio_read( tp, 0x11 ) | BIT_12 | BIT_13| BIT_14;
+data = mdio_read(tp, 0x11) | BIT_13 | BIT_14;
+data &= ~(BIT_12);
 mdio_write(tp, 0x11, data);
 spin_unlock_irqrestore(>phy_lock, flags);
 break;
@@ -5091,7 +5101,7 @@ static int rtl8168_disable_EEE(struc

Bug#807956: ITP: doit -- unofficial DigitalOcean Interactive Tool

[Konstantin Khomoutov]

On Mon, 14 Dec 2015 18:42:22 +0100
Daniel Stender  wrote:

[...]
> * Package name: doit
>   Version : 0.6.0
>   Upstream Author : Bryan Liles 
> * URL : https://github.com/bryanl/doit
> * License : Apache-2.0
>   Programming Lang: Go
>   Description : unofficial DigitalOcean Interactive Tool
[...]

I'd say we already have a lot of tools with very narrow scopes named
too generically.  So I would name the package digitalocean-doit.

The supposedly prospective program's name, /usr/bin/doit, also conveys
exactly zero information about its intended purpose.

Bug#806779: nginx: provide vanilla-like build

[Konstantin Demin]

On Tuesday 01 December 2015 14:35:43, Michael wrote:
> tags 806779 + wontfix
> severity 806779 wishlist
> thanks
> 
> We're not going to create yet another flavor of Nginx. I understand
> why you want this. However, we already need to handle the transition
> of the existing three flavors. There will not be an "nginx-modular" or
> equivalent if it can be prevented.
> 
> Because Nginx will now support dynamic modules, our focus is and will
> continue to be ensuring a seamless migration to it for everyone. It's
> the same reason we froze new plugins. There will already be a *LOT* to
> deal with. We don't need to make it more difficult than it will
> already be.
> 
> As for the timing of it all; it currently looks like Debian 9 will
> freeze not very long after we are expecting the dynamic module
> support. If it works out, we will be on a very tight deadline. We
> don't need to add to the excitement that we already have lined up.
> 
> I'm going to leave this bug open, though. It will need to be addressed
> in the future; not now. This is a "Temporarily Won't Fix." For the
> time being, you could use their repository if you need support.

Thank you for understanding my goals.
I'll be glad if further work will continue right after Release 9.
However, you might try it in experimental branch if you'll have enough time.

---
Best regards,
Konstantin Demin

Bug#806779: nginx: provide vanilla-like build

[Konstantin Demin]

tag 806779 patch

--
SY,
Konstantin Demin

Bug#806779: nginx: provide vanilla-like build

[Konstantin Demin]

Source: nginx
Version: 1.9.6-2
Severity: wishlist

introduce build flavour "standard"

* introduce "standard" build: only vanilla source, no 3rd-party modules at all.
  reason: Nginx Inc. provides support only for vanilla-based build.
* provide packages: "nginx-standard" and "nginx-standard-dbg".
* make "nginx-standard" as default/first choice
  when installing "nginx" meta-package.
* fix other package dependencies (mostly "Conflicts")

Signed-off-by: Konstantin Demin <rockdri...@gmail.com>
---
 debian/control  | 72 ++---
 debian/nginx-common.preinst |  2 +
 debian/nginx-standard.dirs  |  1 +
 debian/nginx-standard.install   |  1 +
 debian/nginx-standard.lintian-overrides |  1 +
 debian/nginx-standard.manpages  |  1 +
 debian/nginx-standard.postinst  | 37 +
 debian/nginx-standard.prerm | 22 ++
 debian/rules| 25 +++-
 debian/tests/control|  3 ++
 10 files changed, 150 insertions(+), 15 deletions(-)
 create mode 100644 debian/nginx-standard.dirs
 create mode 100644 debian/nginx-standard.install
 create mode 100644 debian/nginx-standard.lintian-overrides
 create mode 100644 debian/nginx-standard.manpages
 create mode 100644 debian/nginx-standard.postinst
 create mode 100644 debian/nginx-standard.prerm

diff --git a/debian/control b/debian/control
index de705d4..865a64d 100644
--- a/debian/control
+++ b/debian/control
@@ -31,12 +31,14 @@ Vcs-Browser: 
http://anonscm.debian.org/gitweb/?p=collab-maint/nginx.git;a=summar
 
 Package: nginx
 Architecture: all
-Depends: nginx-full   (>= ${source:Version}) |
- nginx-light  (>= ${source:Version}) |
- nginx-extras (>= ${source:Version}) ,
- nginx-full   (<< ${source:Version}.1~) |
- nginx-light  (<< ${source:Version}.1~) |
- nginx-extras (<< ${source:Version}.1~) ,
+Depends: nginx-standard (>= ${source:Version}) |
+ nginx-light(>= ${source:Version}) |
+ nginx-full (>= ${source:Version}) |
+ nginx-extras   (>= ${source:Version}) ,
+ nginx-standard (<< ${source:Version}.1~) |
+ nginx-light(<< ${source:Version}.1~) |
+ nginx-full (<< ${source:Version}.1~) |
+ nginx-extras   (<< ${source:Version}.1~) ,
  ${misc:Depends}
 Description: small, powerful, scalable web/proxy server
  Nginx ("engine X") is a high-performance web and reverse proxy server
@@ -63,11 +65,13 @@ Depends: lsb-base (>= 3.2-14), ${misc:Depends}, python
 Replaces: nginx (<< 0.8.54-4),
   nginx-extras (<< 0.8.54-4),
   nginx-full (<< 0.8.54-4),
-  nginx-light (<< 0.8.54-4)
+  nginx-light (<< 0.8.54-4),
+  nginx-standard (<< 0.8.54-4)
 Breaks: nginx (<< 0.8.54-4),
 nginx-extras (<< 0.8.54-4),
 nginx-full (<< 0.8.54-4),
-nginx-light (<< 0.8.54-4)
+nginx-light (<< 0.8.54-4),
+nginx-standard (<< 0.8.54-4)
 Suggests: fcgiwrap, nginx-doc, ssl-cert
 Description: small, powerful, scalable web/proxy server - common files
  Nginx ("engine X") is a high-performance web and reverse proxy server
@@ -77,12 +81,52 @@ Description: small, powerful, scalable web/proxy server - 
common files
  This package contains base configuration files used by all versions of
  nginx.
 
+Package: nginx-standard
+Architecture: any
+Depends: nginx-common (= ${source:Version}), ${misc:Depends}, ${shlibs:Depends}
+Breaks: nginx (<< 1.4.5-1)
+Provides: httpd, httpd-cgi, nginx
+Conflicts: nginx-light, nginx-full, nginx-extras
+Suggests: nginx-doc (= ${source:Version})
+Description: nginx web/proxy server (standard version)
+ Nginx ("engine X") is a high-performance web and reverse proxy server
+ created by Igor Sysoev. It can be used both as a standalone web server
+ and as a proxy to reduce the load on back-end HTTP or mail servers.
+ .
+ This package provides a standard version of nginx with the standard modules.
+ .
+ STANDARD HTTP MODULES: Core, Access, Auth Basic, Auto Index, Browser, Empty
+ GIF, FastCGI, Geo, Limit Connections, Limit Requests, Map, Memcached, Proxy,
+ Referer, Rewrite, SCGI, Split Clients, UWSGI.
+ .
+ OPTIONAL HTTP MODULES: Addition, Auth Request, Charset, WebDAV, FLV, GeoIP,
+ Gunzip, Gzip, Gzip Precompression, Headers, Image Filter, Index, Log, MP4,
+ Random Index, Real IP, Secure Link, HTTP/2, SSI, SSL, Stream,
+ Stub Status, Substitution, Thread Pool, Upstream, User ID, XSLT, Degradation.
+ .
+ MAIL MODULES: Mail Core, Auth HTTP, Proxy, SSL, IMAP, POP3, SMTP.
+
+Package: nginx-standard-dbg
+Architecture: any
+Section: debug
+Priority: extra
+Depends: nginx-standard (= ${binary:Vers

Bug#806779: nginx: provide vanilla-like build

[Konstantin Demin]

On Tuesday 01 December 2015 11:36:12, Christos Trochalakis wrote:
> Hello Konstantin and thank you for the patch,
> 
> On Tue, Dec 01, 2015 at 11:07:34AM +0300, Konstantin Demin wrote:
> >Source: nginx
> >Version: 1.9.6-2
> >Severity: wishlist
> >
> >introduce build flavour "standard"
> >
> >* introduce "standard" build: only vanilla source, no 3rd-party modules at 
> >all.
> >  reason: Nginx Inc. provides support only for vanilla-based build.
> >* provide packages: "nginx-standard" and "nginx-standard-dbg".
> >* make "nginx-standard" as default/first choice
> >  when installing "nginx" meta-package.
> >* fix other package dependencies (mostly "Conflicts")
> >
> 
> Since nginx is planning to add dynamic module support as part of the
> 1.9.x series[0], I don't think adding a new flavor is a good idea.
> When that happens we will move to a single nginx core package and a
> handful of satellite nginx modules.
> 
> [0] https://trac.nginx.org/nginx/milestone/1.9

Christos, thank you for information.

I've discussed with fellow nginx developer about that feature (dynamic modules) 
just after reading your e-mail.

Here are some key notes from our talk:
- feature requires building all modules at the same source tree or against same 
nginx version with same compilation flags;
- dynamic loading is optional feature for any nginx module; some modules (e.g., 
core modules) are static-compilation only;
- 3rd-party modules are required to be modified or even rewritten at all to 
support that feature; that requires more testing at all.
- implementation will take some time prior to 1.10 release; 1.10 release is 
planned in Q1 or Q2 2016.

I'm guess that feature will be production-ready not earlier than Q3.2016. Until 
then let's use standard version as well as enhanced versions (light, full and 
extras).

When nginx will become modular, I suppose that Debian Maintainers add build 
flavour with dynamic modules support (named like "nginx-modular" or so), but it 
will not replace other build flavours until feature will be well-tested.

When nginx will become _truly and fully_ modular, Debian Maintainers will 
rework source package anyway.

PS:
here is video from Nginx.conf 2015 (Sep 22-24, San Francisco) about Dynamic 
Modules development:
https://www.youtube.com/watch?v=KinJfCQ-WzY

---
SY,
Konstantin Demin

Bug#806767: ITP: libzstd -- fast lossless compression algorithm, targeting real-time compression scenarios

[Konstantin Khomoutov]

On Tue, 01 Dec 2015 13:33:16 +1100
Kevin Murray  wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Kevin Murray 
> 
> * Package name: libzstd
>   Version : 0.4.0
>   Upstream Author : Yann Collet 
> * URL : https://github.com/Cyan4973

Should probably be https://github.com/Cyan4973/zstd

Bug#806777: nginx: update to upstream version

[Konstantin Demin]

Package: nginx
Version: 1.9.6-2
Severity: wishlist

Consider packaging new upstream version 1.9.7, released 17 Nov 2015.
No package changes required.

-- 
SY,
Konstantin Demin

Bug#806374: qbittorrent: please package upstream version 3.2.5

[Konstantin Demin]

I'm sorry, but 3.2.5 doesn't solve problem with program termination.
I'd discovered with debugger that bug is in libtorrent-rasterbar8.

-- 
SY,
Konstantin Demin

Bug#806396: libtorrent-rasterbar: please consider packaging upsteam version 1.0.7

[Konstantin Demin]

Source: libtorrent-rasterbar
Version: 1.0.6-2
Severity: wishlist

Upstream version 1.0.7 has been released 14.11.2015 with lot of fixes.
Probably, this release fixes floating point exception which I had
discovered while using qbittorrent.

-- 
SY,
Konstantin Demin

Bug#806374: qbittorrent: please package upstream version 3.2.5

[Konstantin Demin]

Source: qbittorrent
Version: 3.2.3-2
Severity: wishlist

I had discovered that current build fails randomly with floating point
exception. I have built upstream version 3.2.5, and it resolved issue.
No changes in debian source code are made at all, so it's quite easy
to do.

-- 
SY,
Konstantin Demin

Bug#801415: ejabberd: maintainer is not maintainer

[Konstantin Khomoutov]

On Fri, 09 Oct 2015 22:33:59 +0200
Dominik George  wrote:

> Package: ejabberd
> Severity: serious
> Justification: Policy 3.3
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> I contacted the maintainer as listed in the package, and was informed
> that he is not the current maintainer in reality and is unable to
> respond to any requests.
> 
> Please update the maintainer field or orphan the package.

While I'm dissatisfied, to put it mildly, with what the submitter wrote
in this bug report regarding me being «unable to respond to any
requests», the crux of their report -- that I'm not really packaging
ejabberd for some time -- is true, and I'm of course fine with
officially resigning if it's deemed the right thing to do with those
doing actual packaging.

Hence I'd like to hear opinions from Philipp and Rhonda about what
should I do next (if I should).

Bug#801051: ITP: golang-github-skratchdot-open-golang -- Abstraction to open URIs using a same object type

[Konstantin Khomoutov]

On Mon, 05 Oct 2015 14:34:55 -0300
Fernando Ike  wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Fernando Ike 
> X-Debbugs-CC: debian-de...@lists.debian.org,
> pkg-go-maintainers@lists.a lioth.debian.org
> 
> * Package name: golang-github-skratchdot-open-golang
>   Version: 0.0~git20150221.0.c874831-1
>   Upstream Author: Jeff Switze 
> * URL: https://github.com/skratchdot/open-golang
> * License: Expat

The README.md says it's MIT, not Expat.

>   Description: Abstraction to open URIs using a same object type

Please use "the same", not "a same".  This form refers to a specific
object with the specific set of properties, so the definite article
is used.

Unfortunately the whole sentence makes little sense as a whole.
I would just snatch the description from the xdg-open's manual page
to produce this description:

| A library to open an URI in the user's preferred application

>  Functions to use embedded in your programs to open a file,
>  directory, or URI using the OS's default application for that object
>  type. Optionally, it can specify an application to use.
>  .
>  This package provides a library to use abstraction open functions in
>  Golang programs.

Language problems, again.  Too many to discern and discuss individually
-- but please take no offence!

I'd rephrase the whole piece like this:

| This library provides a set of Go functions allowing to "open" a file,
| directory or URI using the user's preferred application (or an
| operating system-wide default) to handle objects of those particular
| types.  Optionally, it's possible to directly specify the application
| to use for opening the resource.

Hope this helps.

Bug#800055: ITP: testssl.sh -- Command line tool to check TLS/SSL ciphers, protocols and cryptographic flaws

[Konstantin Khomoutov]

On Sat, 26 Sep 2015 14:30:53 +0800
ChangZhuo Chen  wrote:

> Package: wnpp
> Severity: wishlist
> Owner: "ChangZhuo Chen (陳昌倬)" 
> 
> * Package name: testssl.sh
>   Version : 2.6
>   Upstream Author : Dirk Wetter 
> * URL : https://testssl.sh/
> * License : GPL-2
>   Programming Lang: bash
>   Description : Command line tool to check TLS/SSL ciphers,
> protocols and cryptographic flaws
> 
> (Include the long description here.)

^^^ Please remove this line: it's a placeholder for the long
description you're writing, not a part of it.

>  testssl.sh is a free command line tool which checks a server's
> service on any port for the support of TLS/SSL ciphers, protocols as
> well as recent cryptographic flaws and more. 
>  .
>  Key features
>  .
>  * Clear output: you can tell easily whether anything is good or bad
>  .
>  * Ease of installation: It works for Linux, Darwin, FreeBSD and
>MSYS2/Cygwin out of the box: no need to install or configure
>something, no gems, CPAN, pip or the like.

^^^ This item is not needed: Debian has nothing to do with
all the stuff cited.  And installation here is a matter of calling
`apt install packagename`, you know.

>  * Flexibility: You can test any SSL/TLS enabled and STARTTLS service,
>not only webservers at port 443
>  .
>  * Toolbox: Several command line options help you to run YOUR test and
>configure YOUR output
>  .
>  * Reliability: features are tested thoroughly
>  .
>  * Verbosity: If a particular check cannot be performed because of a
>missing capability on your client side, you'll get a warning
>  .
>  * Privacy: It's only you who sees the result, not a third party
>  .
>  * Freedom: It's 100% open source. You can look at the code, see
> what's going on and you can change it. Heck, even the development is
> open (github)

^^^ Everything which is in the Debian's main archive is free software
by definition, so this point is not needed as well.

Please also note that playful speech and jargonisms (like "Heck, ...!"
style exclamations) have no place in the description of Debian packages.
They should be neutral.

Bug#797426: g++: internal compiler error: Getötet (program cc1plus)

[Konstantin Manna]

Package: g++-4.9
Version: 4.9.3-3
Severity: important

I was trying to build phantomjs (git hash 
d038a004be21b0cf6d47a1330002e383de06fb27) from github.com/ariya/phantomjs.git
when this error ocurred:
g++: internal compiler error: Getötet (program cc1plus)
Please submit a full bug report

The last lines of the output where:
https://paste.debian.net/309703/
(The full log was 14MB, so a bit much)
I still have it if you need it.

gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.3-3' 
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs 
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-4.9 --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls 
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug 
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify 
--enable-plugin --with-system-zlib --disable-browser-plugin 
--enable-java-awt=gtk --enable-gtk-cairo 
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home 
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 
 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.3 (Debian 4.9.3-3)

Cheers,
Konstantin

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

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

Versions of packages g++-4.9 depends on:
ii  gcc-4.94.9.3-3
ii  gcc-4.9-base   4.9.3-3
ii  libc6  2.19-19
ii  libcloog-isl4  0.18.3-1
ii  libgmp10   2:6.0.0+dfsg-7
ii  libisl13   0.14-2
ii  libmpc31.0.3-1
ii  libmpfr4   3.1.3-1
ii  libstdc++-4.9-dev  4.9.3-3
ii  zlib1g 1:1.2.8.dfsg-2+b1

g++-4.9 recommends no packages.

Versions of packages g++-4.9 suggests:
pn  g++-4.9-multilibnone
pn  gcc-4.9-doc none
pn  libstdc++6-4.9-dbg  none

-- no debconf information

Bug#793769: ITP: down -- A simple game written in Ruby/SDL

[Konstantin Khomoutov]

On Mon, 27 Jul 2015 11:37:14 +0200
Marcin Mielniczuk marmis...@inboxalias.com wrote:

[...]
 * Package name: down
   Version : 1.0.0
   Upstream Author : Yutaka Hara yutaka.hara+...@gmail.com
 * URL : http://route477.net

The page by that URL does not mention the project you intend to package.
Or at least I failed to locate it there.

 * License : MIT
   Programming Lang: Ruby/SDL
   Description : A simple game written in Ruby/SDL

written in Ruby/SDL is implementation specific and has nothing to do
with package's description.  Please be more descriptive and concrete.
Supposedly something like
An Icy Tower-like game which can be played downwards
might be just OK.

The general rule of thumb for writing a package's description is that it
should deliver as much as possible information to a *previously
uninformed* user.  The user which looks for games is not concerned with
which software stack was used for development, but should receive a
clear hint of what this game is about just from looking at its
description in the list their software package manager presents them
with.

 Did you ever play Icy Tower? Did you ever have the opportunity to
 play it downwards? Now you have!

The extended description could supposedly be toned down a bit,
and then extended.

Please understand that you're not a marketologist or advertisement
specialist here, and your task is not about raising an excitement of a
potential customer by any means.
Luckily, we don't sell, we just deliver. ;-)

[...]


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

Bug#792903: ITP: hdump -- Hexadecimal and ASCII dumper for binary files

[Konstantin Khomoutov]

On Mon, 20 Jul 2015 23:52:27 -0300
Paulo kretc...@gmail.com wrote:

  Does this have significant advantages over these tools that are
  already in the archive and likely to be near-ubiquitous on GNU
  systems?
 
  * od -t x1 (part of coreutils, and a subset of its functionality is
 standardized in POSIX)
  * hd, aka hexdump (part of bsdmainutils)
  * xxd (part of vim-common)
 
 Yes, you're right, there are other tools, but in my opinion, this 
 program can interest people with less technical skils because of it 
 output design and simplicity.
[...]

Not that I'm against packaging hdump but IMO people who actually
understand what the hex dump is have the necessary skills to master
`od` et al by definition :-)


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

Bug#785205: nvidia-kernel-dkms: fails to build with kernel 4.0 (sid)

[Konstantin Demin]

Hello again!

Here is quick and dirty patch to debian/rules.

2015-06-15 23:22 GMT+03:00 Konstantin Demin rockdri...@gmail.com:
 Hi Vincent!

 I'm currently trying to debianize 346.72 using
 nvidia-graphics-drivers:346.59 and i have pretty same issue.
 Build succeeds with target architecture amd64 but it will fail with
 others architectures.

 Here is my investigation:

 krd@aceroid $ uname -a
 Linux aceroid 4.0.5-krd.aceroid.0 #1 SMP Mon Jun 15 14:33:27 MSK 2015
 x86_64 GNU/Linux

 krd@aceroid $ sbuild -c sid-i386-sbuild --arch=i386
 nvidia-graphics-drivers_346.72-0.dsc
 [--- CUT HERE ---]
 # Use the nvidia-kernel-source source to create the DKMS tree.
 mkdir -p debian/nvidia-kernel-dkms/usr/src/
 mv debian/nvidia-kernel-source/usr/src/modules/nvidia-kernel
 debian/nvidia-kernel-dkms/usr/src/nvidia-current-346.72
 rmdir debian/nvidia-kernel-source/usr/src/modules/
 cd debian/nvidia-kernel-dkms/usr/src/nvidia-current-346.72 \
  QUILT_PATCHES=debian/patches quilt --quiltrc /dev/null push -a
 || test $? = 2 \
  rm -rf .pc debian
 Applying patch not-silent.patch
 patching file nvidia-modules-common.mk

 Applying patch avoid-ld.gold.patch
 patching file nvidia-modules-common.mk

 Applying patch use-nv-kernel-ARCH.o_shipped.patch
 patching file Kbuild

 Applying patch conditionally-include-linux_version.h.patch
 patching file nv-linux.h

 Applying patch uvm-symvers.patch
 can't find file to patch at input line 6
 Perhaps you used the wrong -p or --strip option?
 The text leading up to this was:
 --
 |Author: Andreas Beckmann deb...@abeckmann.de
 |Description: fix up the ../Module.symvers dependency for our uvm build
 |
 |--- a/uvm/Kbuild
 |+++ b/uvm/Kbuild
 --
 No file to patch.  Skipping patch.
 1 out of 1 hunk ignored
 Patch uvm-symvers.patch does not apply (enforce with -f)
 make[2]: *** [build-kernel-dkms-tree] Error 1
 debian/rules:237: recipe for target 'build-kernel-dkms-tree' failed
 make[2]: Leaving directory '/«PKGBUILDDIR»'
 make[1]: *** [install] Error 2
 debian/rules:140: recipe for target 'install' failed
 make[1]: Leaving directory '/«PKGBUILDDIR»'
 make: *** [binary] Error 2
 debian/rules:140: recipe for target 'binary' failed
 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 
 2
 [--- CUT HERE ---]

 krd@aceroid $ for i in NVIDIA-*-346.59.run; do sh $i -x; done
 Creating directory NVIDIA-Linux-armv7l-gnueabihf-346.59
 Verifying archive integrity... OK
 Uncompressing NVIDIA Accelerated Graphics Driver for Linux-armv7l 346.59..
 Creating directory NVIDIA-Linux-x86-346.59
 Verifying archive integrity... OK
 Uncompressing NVIDIA Accelerated Graphics Driver for Linux-x86 346.59..
 Creating directory NVIDIA-Linux-x86_64-346.59
 Verifying archive integrity... OK
 Uncompressing NVIDIA Accelerated Graphics Driver for Linux-x86_64 346.59..

 krd@aceroid $ find NVIDIA-*-346.59/ -name uvm
 NVIDIA-Linux-x86_64-346.59/kernel/uvm

 Temporary solution is to copy whole uvm/ directory from amd64 variant to 
 others.

 --
 SY,
 Konstantin Demin



-- 
SY,
Konstantin Demin
--- a/debian/rules
+++ b/debian/rules
@@ -196,6 +196,9 @@ build-kernel-source-tree: install-into-tmp
 	mv $(module_source)/conftest.sh $(module_source)/conftest_nvidia.sh
 
 	# For the nvidia-uvm module.
+	test ! -d $(module_source)/uvm  test -d NVIDIA-Linux-amd64/kernel/uvm  cp -r NVIDIA-Linux-amd64/kernel/uvm $(module_source)/
+	test ! -d $(module_source)/uvm  test -d NVIDIA-Linux-i386/kernel/uvm  cp -r NVIDIA-Linux-i386/kernel/uvm $(module_source)/
+	test ! -d $(module_source)/uvm  test -d NVIDIA-Linux-armhf/kernel/uvm  cp -r NVIDIA-Linux-armhf/kernel/uvm $(module_source)/
 	test ! -f $(module_source)/uvm/Makefile || \
 		mv $(module_source)/uvm/Makefile $(module_source)/uvm/Kbuild
 	test ! -d $(module_source)/uvm || \

Bug#785205: nvidia-kernel-dkms: fails to build with kernel 4.0 (sid)

[Konstantin Demin]

Hi Vincent!

I'm currently trying to debianize 346.72 using
nvidia-graphics-drivers:346.59 and i have pretty same issue.
Build succeeds with target architecture amd64 but it will fail with
others architectures.

Here is my investigation:

krd@aceroid $ uname -a
Linux aceroid 4.0.5-krd.aceroid.0 #1 SMP Mon Jun 15 14:33:27 MSK 2015
x86_64 GNU/Linux

krd@aceroid $ sbuild -c sid-i386-sbuild --arch=i386
nvidia-graphics-drivers_346.72-0.dsc
[--- CUT HERE ---]
# Use the nvidia-kernel-source source to create the DKMS tree.
mkdir -p debian/nvidia-kernel-dkms/usr/src/
mv debian/nvidia-kernel-source/usr/src/modules/nvidia-kernel
debian/nvidia-kernel-dkms/usr/src/nvidia-current-346.72
rmdir debian/nvidia-kernel-source/usr/src/modules/
cd debian/nvidia-kernel-dkms/usr/src/nvidia-current-346.72 \
 QUILT_PATCHES=debian/patches quilt --quiltrc /dev/null push -a
|| test $? = 2 \
 rm -rf .pc debian
Applying patch not-silent.patch
patching file nvidia-modules-common.mk

Applying patch avoid-ld.gold.patch
patching file nvidia-modules-common.mk

Applying patch use-nv-kernel-ARCH.o_shipped.patch
patching file Kbuild

Applying patch conditionally-include-linux_version.h.patch
patching file nv-linux.h

Applying patch uvm-symvers.patch
can't find file to patch at input line 6
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--
|Author: Andreas Beckmann deb...@abeckmann.de
|Description: fix up the ../Module.symvers dependency for our uvm build
|
|--- a/uvm/Kbuild
|+++ b/uvm/Kbuild
--
No file to patch.  Skipping patch.
1 out of 1 hunk ignored
Patch uvm-symvers.patch does not apply (enforce with -f)
make[2]: *** [build-kernel-dkms-tree] Error 1
debian/rules:237: recipe for target 'build-kernel-dkms-tree' failed
make[2]: Leaving directory '/«PKGBUILDDIR»'
make[1]: *** [install] Error 2
debian/rules:140: recipe for target 'install' failed
make[1]: Leaving directory '/«PKGBUILDDIR»'
make: *** [binary] Error 2
debian/rules:140: recipe for target 'binary' failed
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2
[--- CUT HERE ---]

krd@aceroid $ for i in NVIDIA-*-346.59.run; do sh $i -x; done
Creating directory NVIDIA-Linux-armv7l-gnueabihf-346.59
Verifying archive integrity... OK
Uncompressing NVIDIA Accelerated Graphics Driver for Linux-armv7l 346.59..
Creating directory NVIDIA-Linux-x86-346.59
Verifying archive integrity... OK
Uncompressing NVIDIA Accelerated Graphics Driver for Linux-x86 346.59..
Creating directory NVIDIA-Linux-x86_64-346.59
Verifying archive integrity... OK
Uncompressing NVIDIA Accelerated Graphics Driver for Linux-x86_64 346.59..

krd@aceroid $ find NVIDIA-*-346.59/ -name uvm
NVIDIA-Linux-x86_64-346.59/kernel/uvm

Temporary solution is to copy whole uvm/ directory from amd64 variant to others.

--
SY,
Konstantin Demin


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

Bug#785205: nvidia-kernel-dkms: fails to build with kernel 4.0 (sid)

[Konstantin Demin]

I'm sorry that patch was too dirty.
I spent more thorough testing for i386 and amd64 architectures and
eliminated FTBFS.
This patch has helped me and will help you.

-- 
SY,
Konstantin Demin
--- a/debian/module/conftest.h
+++ b/debian/module/conftest.h
@@ -540,7 +540,7 @@
 #endif
 
 /* Implement conftest.sh function write_cr4 */
-#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,20)
+#if (LINUX_VERSION_CODE = KERNEL_VERSION(2,6,20))  (LINUX_VERSION_CODE  KERNEL_VERSION(4,0,0))
  #define NV_WRITE_CR4_PRESENT
 #else
  #undef NV_WRITE_CR4_PRESENT

--- /dev/null
+++ b/debian/module/debian/patches/cleanse-kbuild.patch
@@ -0,0 +1,11 @@
+--- a/Kbuild
 b/Kbuild
+@@ -65,7 +65,7 @@ endif
+ # Make sure KBUILD understands that we want a module.
+ #
+ 
+-CORE_OBJS := nv-kernel.o
++CORE_OBJS :=
+ 
+ FRONTEND_GLUE_OBJS := $(patsubst %.c,%.o,nv-frontend.c)
+ INSTANCE_GLUE_OBJS := $(patsubst %.c,%.o,nv-instance.c)

--- /dev/null
+++ b/debian/module/debian/patches/dentry.patch
@@ -0,0 +1,11 @@
+--- a/nv-linux.h
 a/nv-linux.h
+@@ -2050,7 +2050,7 @@
+ #if defined(NV_FILE_HAS_INODE)
+ #define NV_FILE_INODE(file) (file)-f_inode
+ #else
+-#define NV_FILE_INODE(file) (file)-f_dentry-d_inode
++#define NV_FILE_INODE(file) (file)-f_path.dentry-d_inode
+ #endif
+ 
+ /* Stub out UVM in multi-RM builds */

--- a/debian/module/debian/patches/series
+++ b/debian/module/debian/patches/series
@@ -3,3 +3,5 @@ avoid-ld.gold.patch
 use-nv-kernel-ARCH.o_shipped.patch
 conditionally-include-linux_version.h.patch
 uvm-symvers.patch
+dentry.patch
+cleanse-kbuild.patch

--- a/debian/rules
+++ b/debian/rules
@@ -196,12 +196,17 @@ build-kernel-source-tree: install-into-tmp
 	mv $(module_source)/conftest.sh $(module_source)/conftest_nvidia.sh
 
 	# For the nvidia-uvm module.
+	test -d $(module_source)/uvm || cp -r NVIDIA-Linux-amd64/kernel/uvm $(module_source)/
+	test -d $(module_source)/uvm || cp -r NVIDIA-Linux-i386/kernel/uvm $(module_source)/
+	test -d $(module_source)/uvm || cp -r NVIDIA-Linux-armhf/kernel/uvm $(module_source)/
 	test ! -f $(module_source)/uvm/Makefile || \
 		mv $(module_source)/uvm/Makefile $(module_source)/uvm/Kbuild
 	test ! -d $(module_source)/uvm || \
 		ln -sf ../Makefile $(module_source)/uvm
 	test ! -d $(module_source)/uvm || \
 		ln -sf ../conftest.sh $(module_source)/uvm
+	test ! -d $(module_source)/uvm || \
+		ln -sf ../conftest.h $(module_source)/uvm
 
 	# We may need nv-kernel.o for several architectures to accomodate
 	# all kernel flavors. Use Kbuild-compatible names.

Bug#752018: Wildfly package

[Konstantin Manna]

Hi Julian,

would you mind putting the stuff you got so far (scripts/files on how
you build the package) on github, so we can push this project a little
forward and maybe let someone from debian-java take a look at it?

Cheers,
Konstantin



signature.asc
Description: OpenPGP digital signature

Bug#783077: Defaults for listen differ from what the man page says; may break upgrades

[Konstantin Khomoutov]

Severity: important
Package: vsftpd
Version: 3.0.2-17

The vsftpd.conf(5) manual page says that the default value for the
listen configuration file option is NO but in reality it's YES,
as we can see from the line 185 in tunables.c:

  tunable_listen = 1;

What's worse, this seems to be a change introduced during the Jessie
development cycle as on the box I've upgraded to Jessie (to vsftpd
3.0.2-17) I had both listen and listen_v6 commented out and using
inetd for running vsftpd. The upgrade stopped vsftpd from functioning
as it tried to open its port 20 for listening after being spawned by
inetd, and failed, reporting 500 OOPS: could not bind listening IPv4
socket to the connected client.

Hence what I would propose is to revert the change enabling listen by
default to not break upgrades for those who relied on the defaults as
they were in Wheezy and is running vsftpd via inetd.

Otherwise, the manual page should be fixed and supposedly NEWS.Debian
updated as well.

I tried to locate the vsftpd's source code repository, but failed; the
Debian's Git repo contains only the most recent version, 3.0.2, in its
upstream branch so I have no idea how should I try to see whether
vsftpd itself had its defaults for the listen option changed since
the version packaged in Wheezy.  The changelog available on the
upstream website only mentions the word listen in the entry for some
very old version -- much older than that in Wheezy.



(The following text discusses a problem supposedly tangential to the
essense of my bug report but including it anyway.)

The closest existing Debian bug I've managed to find is
#574837 [1] which basically amounted with tinkering with the
configuration file while not touching the code,
and the code currently has

  tunable_listen = 1;
  tunable_listen_ipv6 = 0;

While this might not relate to the problem at hand, I reckon the patch
applied from #574837 should also be extended to reverse the values of
the affected options in tunables.c, as I indicated above.

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


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

Bug#781890: RFP: dnscrypt-proxy -- Encrypts DNS traffic between the user and a DNS-Server.

[Konstantin Manna]

Package: wnpp
Severity: wishlist

* Package name: dnscrypt-proxy
  Version : 1.4.3
  Upstream Author : Frank Denis git...@pureftpd.org
* URL : http://dnscrypt.org
* License : (Frank Denis)
  Programming Lang: (C)
  Description : Encrypts DNS traffic between the user and a DNS-Server.


long description:
dnscrypt-proxy provides local service which can be used directly as your local
resolver or as a DNS forwarder, encrypting and authenticating requests using the
DNSCrypt protocol and passing them to an upstream server.
The DNSCrypt protocol uses high-speed high-security elliptic-curve cryptography
and is very similar to DNSCurve, but focuses on securing communications between
a client and its first-level resolver.
While not providing end-to-end security, it protects the local network,
which is often the weakest point of the chain, against man-in-the-middle 
attacks. 
It also provides some confidentiality to DNS queries.

Source available at: https://github.com/jedisct1/dnscrypt-proxy
Dependency: libsodium-dev
Packaging files for debian seem to be also already included in the github repo.


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

Bug#752018: Wildfly package

[Konstantin Manna]

Hi Julian,

thanks for the update.
Lintian does not yet like your package :-)

lintian --pedantic wildfly_8.1.0.final+lam.r01_all.deb
E: wildfly: arch-independent-package-contains-binary-or-object
usr/share/wildfly/modules/system/layers/base/org/hornetq/main/lib/linux-i686/libHornetQAIO32.so
E: wildfly: arch-dependent-file-in-usr-share
usr/share/wildfly/modules/system/layers/base/org/hornetq/main/lib/linux-i686/libHornetQAIO32.so
E: wildfly: unstripped-binary-or-object
usr/share/wildfly/modules/system/layers/base/org/hornetq/main/lib/linux-i686/libHornetQAIO32.so
E: wildfly: arch-independent-package-contains-binary-or-object
usr/share/wildfly/modules/system/layers/base/org/hornetq/main/lib/linux-x86_64/libHornetQAIO64.so
E: wildfly: arch-dependent-file-in-usr-share
usr/share/wildfly/modules/system/layers/base/org/hornetq/main/lib/linux-x86_64/libHornetQAIO64.so
E: wildfly: unstripped-binary-or-object
usr/share/wildfly/modules/system/layers/base/org/hornetq/main/lib/linux-x86_64/libHornetQAIO64.so
E: wildfly: missing-dependency-on-libc needed by
usr/share/wildfly/modules/system/layers/base/org/hornetq/main/lib/linux-i686/libHornetQAIO32.so
and 1 others
E: wildfly: changelog-file-missing-in-native-package
E: wildfly: file-in-etc-not-marked-as-conffile etc/init.d/wildfly
W: wildfly: unknown-control-file changelog
W: wildfly: unknown-control-file compat
W: wildfly: unknown-control-file copyright
W: wildfly: unknown-control-file files
E: wildfly: control-file-has-bad-permissions postinst 0555 != 0755
E: wildfly: control-file-has-bad-permissions postrm 0555 != 0755
E: wildfly: control-file-has-bad-permissions preinst 0555 != 0755
E: wildfly: no-copyright-file
E: wildfly: description-starts-with-package-name
E: wildfly: non-standard-toplevel-dir .installation/
W: wildfly: non-standard-dir-perm .installation/ 0700 != 0755
W: wildfly: extra-license-file usr/share/doc/wildfly/LICENSE.txt
W: wildfly: non-standard-file-perm
usr/share/wildfly/domain/configuration/application-roles.properties 0600
!= 0644
W: wildfly: non-standard-file-perm
usr/share/wildfly/domain/configuration/application-users.properties 0600
!= 0644
W: wildfly: non-standard-file-perm
usr/share/wildfly/domain/configuration/mgmt-groups.properties 0600 != 0644
W: wildfly: non-standard-file-perm
usr/share/wildfly/domain/configuration/mgmt-users.properties 0600 != 0644
W: wildfly: non-standard-dir-perm usr/share/wildfly/domain/tmp/auth/
0700 != 0755
W: wildfly: non-standard-file-perm
usr/share/wildfly/standalone/configuration/application-roles.properties
0600 != 0644
W: wildfly: non-standard-file-perm
usr/share/wildfly/standalone/configuration/application-users.properties
0600 != 0644
W: wildfly: non-standard-file-perm
usr/share/wildfly/standalone/configuration/mgmt-groups.properties 0600
!= 0644
W: wildfly: non-standard-file-perm
usr/share/wildfly/standalone/configuration/mgmt-users.properties 0600 !=
0644
W: wildfly: non-standard-dir-perm usr/share/wildfly/standalone/tmp/auth/
0700 != 0755
W: wildfly: script-in-etc-init.d-not-registered-via-update-rc.d
etc/init.d/wildfly
E: wildfly: init.d-script-does-not-implement-required-option
etc/init.d/wildfly force-reload
W: wildfly: codeless-jar
usr/share/wildfly/modules/system/layers/base/org/jboss/as/console/main/release-stream-2.2.6.Final-resources.jar
W: wildfly: codeless-jar
usr/share/wildfly/modules/system/layers/base/org/jboss/as/domain-http-error-context/main/wildfly-domain-http-error-context-8.1.0.Final.jar
W: wildfly: codeless-jar
usr/share/wildfly/modules/system/layers/base/org/jboss/as/webservices/main/jbossws-cxf-resources-4.2.4.Final-wildfly800.jar
W: wildfly: codeless-jar
usr/share/wildfly/modules/system/layers/base/org/jboss/ws/cxf/jbossws-cxf-factories/main/jbossws-cxf-factories-4.2.4.Final.jar
W: wildfly: maintainer-script-ignores-errors preinst
W: wildfly: maintainer-script-ignores-errors postrm
W: wildfly: maintainer-script-should-not-use-deprecated-chown-usage
postinst:6 'chown -R wildfly.wildfly'
W: wildfly: maintainer-script-should-not-use-deprecated-chown-usage
postinst:7 'chown -R wildfly.wildfly'
W: wildfly: maintainer-script-should-not-use-deprecated-chown-usage
postinst:8 'chown -R wildfly.wildfly'
W: wildfly: maintainer-script-ignores-errors postinst

Would you like to fix that?
I guess if the package is lintian clean and we can find a debian mentor
we might get the package into the official repos.

Cheers,
Konstantin



signature.asc
Description: OpenPGP digital signature

Bug#754936: pdsh: libreadline Support in pdsh

[Konstantin Nebel]

Hi,

I mean. The severity is low and shit, but after nearly one year of report I 
would love to get atleast an answer. That would be awesome.

Cheers

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

Bug#752018: Wildfly package

[Konstantin . manna]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Julian,

thank you for packaging it.
Have you already submitted it somewhere?
Or is there maybe another way to beta-test it beforehand?

Regards,
Konstantin
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJU7xjSAAoJEPHwdvjI23R7vl4H/jCKd3zX+QA/DHK/JdLrlCk/
RYY4iBPufz7CXTOUlyjXSYP57/spiRZ22icx9urgJSWrmxtjt+HOdGaj6maDoH9P
NIGYyeV6QLTqRVF/hCgJ7uh+SPTtT2DfnVPuTNT0jn9c/Nof5vVvA9n/qsTwiVc1
5YfUU4ERHB/K/xjzH5Kmc/UpRtfS7OlUg7kmVYkjgscKn5T8iYvGnpeCQdq3WI9p
M3tjMKE6aWgmFtFghuyrp7Wgcq/U0VkaOQVeJx+KJOzgA87QLZNgqCYm2HpY4y0/
UBuyfhGTipOicHOjQ+F8mzV7jW1o3cD08wBd0yqS7+SGDs2k+LfJpANq/uN0sGc=
=d4ED
-END PGP SIGNATURE-


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

Bug#776612: (no subject)

[Konstantin]

Subject: base-files is not depended on awk
Package: base-files
Version: 8
Severity: wishlist



-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-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 base-files depends on:
ii  mawk [awk]  1.3.3-17

base-files recommends no packages.

base-files 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#774723: apt-spy: Segmentation fault with several areas

[Konstantin Oshepkov]

Package: apt-spy
Version: 3.2.2-1
Severity: normal

I have got Segmentation fault message on stable and unstable releases.
I run only:
# apt-spy update
Update complete. Exiting.
# apt-spy -a asia -a europe
Segmentation fault.

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

Kernel: Linux 3.2.0-4-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

Versions of packages apt-spy depends on:
ii  libc6 2.13-38+deb7u6
ii  libcurl3  7.26.0-1+wheezy11

apt-spy recommends no packages.

apt-spy 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