Bug#1074005: (Maybe) A big step towards 2.36

[Nikos Tsipinakis]

Hey Martin,

Sorry for the duplicated effort but 2.36 is already packaged. I was waiting for 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077190 to be resolved, which 
is the reason you had to add a ton of new dependencies that are not actual 
newsboat dependencies.

I'll upload now.

Cheers,
Nikos

Bug#1074005: newsboat: Please update to 2.35

[Nikos Tsipinakis]

Hi Martin,

Updating newsboat is currently blocked on 2.36 releasing due to 
https://github.com/newsboat/newsboat/issues/2748

Cheers,
Nikos

On Fri, 21 Jun 2024, at 17:23, Martin Dosch wrote:
> Package: newsboat
> Version: 2.32-3
> Severity: wishlist
>
> Dear Maintainer,
>
> please update to the newest upstream version 2.35. Currently newsboat is 
> not in trixie and maybe we are lucky and the build issues will be also 
> resolved when updating.
>
> Best regards,
> Martin
>
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers testing
>   APT policy: (900, 'testing'), (600, 'unstable'), (500, 
> 'unstable-debug'), (500, 'testing-debug'), (500, 'experimental'), (1, 
> 'experimental-debug')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 6.8.12-amd64 (SMP w/8 CPU threads; PREEMPT)
> 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 newsboat depends on:
> ii  libc6 2.38-13
> ii  libcurl3t64-gnutls [libcurl3-gnutls]  8.8.0-1
> ii  libgcc-s1 14.1.0-2
> ii  libjson-c50.17-1+b1
> ii  libncursesw6  6.5-2
> ii  libsqlite3-0  3.46.0-1
> ii  libstdc++614.1.0-2
> ii  libstfl0  0.22-3+b8
> ii  libtinfo6 6.5-2
> ii  libxml2   2.12.7+dfsg-3
>
> Versions of packages newsboat recommends:
> ii  sensible-utils  0.0.23
>
> newsboat suggests no packages.
>
> -- no debconf information
>
> Attachments:
> * signature.asc

Bug#1070170: Generate and include amalgamated header file

[Nikos Tsipinakis]

Source: catch2
Version: 2.13.10-1
Severity: wishlist
X-Debbugs-Cc: ni...@tsipinakis.com

Dear Maintainer,

I've been depending on the catch2 library package for newsboat which by default
vendors the catch library. To be compatible with the Debian policy I have
overridden this so that the packaged version is used instead. 

However with version 3 now there are separate header files for each function and
since upstream is relying on the single header/amalgamated version it is not
easy to patch to include all the required functionalities.

It'd be great to also generate and include the amalgamated header file
(generation script can be found here[1]) in order to ease the version 3
transition for amalgamated header users.

[1] 
https://github.com/catchorg/Catch2/blob/fa5a53df17303339eff8fda5cae0b601af207085/tools/scripts/generateAmalgamatedFiles.py

Cheers,
Nikos 

Bug#1069378: picom: FTBFS on arm64: cc: error: unrecognized command-line option '-Wunknown-warning-option'

[Nikos Tsipinakis]

block -1 by 1069408
thanks

Hi,

The title of this bug is not a compilation error, it's a feature test. This is 
actually failing because of 1069408. 

>> Pkg-config error with 'xcb-present': Could not generate cflags for 
>> xcb-present:
>> Package xcb-dri3 was not found in the pkg-config search path.
>> Perhaps you should add the directory containing `xcb-dri3.pc'
>> to the PKG_CONFIG_PATH environment variable
>> Package 'xcb-dri3', required by 'xcb-present', not found
>> 
>> Dependency lookup for xcb-present with method 'pkgconfig' failed: Could not 
>> generate cflags for xcb-present:
>> Package xcb-dri3 was not found in the pkg-config search path.
>> Perhaps you should add the directory containing `xcb-dri3.pc'
>> to the PKG_CONFIG_PATH environment variable
>> Package 'xcb-dri3', required by 'xcb-present', not found
>> 
>> CMake binary for host machine is cached as not found
>> Dependency lookup for xcb-present with method 'cmake' failed: CMake binary 
>> for machine host machine not found. Giving up.
>> Run-time dependency xcb-present found: NO 
>> 
>> ../src/meson.build:31:15: ERROR: Dependency lookup for xcb-present with 
>> method 'pkgconfig' failed: Could not generate cflags for xcb-present:
>> Package xcb-dri3 was not found in the pkg-config search path.
>> Perhaps you should add the directory containing `xcb-dri3.pc'
>> to the PKG_CONFIG_PATH environment variable
>> Package 'xcb-dri3', required by 'xcb-present', not found

Cheers,
Nikos

Bug#1069794: ITP: openbao -- Manage, store and distribute sensitive data.

[Nikos Tsipinakis]

Package: wnpp
Severity: wishlist
Owner: Nikos Tsipinakis 
X-Debbugs-Cc: debian-de...@lists.debian.org, ni...@tsipinakis.com

* Package name: openbao
  Version : v2.0.0-alpha20240329
  Upstream Contact: OpenBao Mailing List 
* URL : https://openbao.org/
* License :  MPL-2.0
  Programming Lang: Go
  Description : Manage, store and distribute sensitive data.

Fork of Hashicorp Vault after it was relicensed to a non-free license. I intend
to give it a shot to package it in the next few weeks in coordination (and
hopefully with the guidance of) the Go team.

Bug#1030114: picom: new upstream release

[Nikos Tsipinakis]

Hi Lev,

This has been fixed for a while.

Cheers,
Nikos

Bug#1038745: dunst: Please package new upstream release 1.9.2

[Nikos Tsipinakis]

Hi Boyuan,

I see you've made a few NM uploads to dunst already, as well as pre-packaged 
1.9.2 in salsa, thanks a lot! :)

I've now made this a maintainer upload and uploaded 1.9.2.

Cheers,
Nikos

Bug#946677:

[Nikos Andrikos]

It seems that we have to set DEB_DH_COMPAT_DISABLE in debian/rules to avoid
this problem, as it is implemented in
https://salsa.debian.org/debian/cdbs/-/blob/master/1/rules/debhelper.mk.in#L208

Kind regards,
Nikos

Bug#1004874: dialog: --max-input ignores values higher than 2048

[Nikos Dragazis]

Package: dialog
Version: 1.3-20201126-1
Severity: normal

Dear Maintainer,

The --max-input option seems to ignore values higher than 2048, which
is the default limit according to the man page. This means that we
cannot pass lines to the editbox widget that are longer than 2047
characters since they get truncated. One such use case is base64-encoded
data.

Steps to reproduce:
1. Create 2050-character input string:
   # echo -n $(openssl rand -hex 1025) > /tmp/input && cat /tmp/input | wc -c
   2050

2. Run dialog with an input limit higher than 2048 (e.g., 2060):
   # touch /tmp/foo && dialog --max-input 2060 --output-separator '' --editbox 
/tmp/foo 18 80 2>/tmp/output

3. Copy the input string from /tmp/input into your clipboard and paste
   it into the editbox.

4. Press the "OK" button.

5. Inspect the length of the output string.
   # cat /tmp/output | wc -c
   2047

Expected behavior: length of output string == 2050 (== length of input string)
Actual behavior:   length of output string == 2047 (==  - 
1)

When setting --max-input to values lower than 2048 though, it works as
expected.


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

Kernel: Linux 5.4.0-91-generic (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages dialog depends on:
ii  debianutils   4.8.1.1
ii  libc6 2.31-13+deb11u2
ii  libncursesw6  6.2+20201114-2
ii  libtinfo6 6.2+20201114-2

dialog recommends no packages.

dialog suggests no packages.

-- no debconf information

Bug#1004868: dialog: menu segfaults when resizing

[Nikos Dragazis]

Package: dialog
Version: 1.3-20201126-1
Severity: normal

Dear Maintainer,

The menu widget segfaults when resizing the terminal.

Steps to reproduce:
1. Create a menu with three items:
   dialog --menu Test 18 80 3 0 "Item 0" 1 "Item 1" 2 "Item 2"

2. Reduce the vertical size of the terminal so that only one item is
   visible.

3. Select the last item.

4. Increase the vertical size of the terminal.


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

Kernel: Linux 5.4.0-91-generic (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages dialog depends on:
ii  debianutils   4.8.1.1
ii  libc6 2.31-13+deb11u2
ii  libncursesw6  6.2+20201114-2
ii  libtinfo6 6.2+20201114-2

dialog recommends no packages.

dialog suggests no packages.

-- no debconf information

Bug#1004259: newboat - upcoming rust-rand update.

[Nikos Tsipinakis]

Hi,

On Sun, 23 Jan 2022, at 18:40, Peter Michael Green wrote:
> A debdiff is attatched, do you want to handle the upload after
> rand is updated in unstable or would you like me to NMU it?

I have no preference, since you have the debdiff feel free to NMU it if you're 
doing a mass-upload already.

> rand 0.8 and sufficient related packages to build newsboat
> have been uploaded to experimental if you want to test things
> in advance of the update in unstable.

Thanks! I'll take a look.

-- 
Best Regards,
  Nikos Tsipinakis

Bug#1000362: newsboat: new usptream version available (2.25)

[Nikos Tsipinakis]

Hi,

Newsboat now requires the rust-cxx crate , which is currently in NEW. (or 
components of it)
It will probably take a while to get it updated.

Regards,
Nikos

On Mon, 22 Nov 2021, at 06:23, Salvatore Bonaccorso wrote:
> Source: newsboat
> Version: 2.21-1
> Severity: wishlist
> X-Debbugs-Cc: car...@debian.org
>
> Hi
>
> there is a new upstream version available for newsboat (2.25 at time
> of writing).
>
> https://github.com/newsboat/newsboat/blob/master/CHANGELOG.md#225---2021-09-20
>
> Possible to package the new version for unstable?
>
> Regards,
> Salvatore

-- 
Best Regards,
  Nikos Tsipinakis

Bug#1003185: dialog: Dialog segfaults when passing large line to editbox

[Nikos Dragazis]

Package: dialog
Version: 1.3-20201126-1
Severity: normal

Dear Maintainer,

There is a segfault bug in the editbox widget. Specifically, the dialog
can segfault when typing a line that is longer than the --max-input.

Steps to reproduce:
1. Run: touch /tmp/foo && dialog --max-input 10 --editbox /tmp/foo 18 80
2. Type a very long string. In my system, it suffices to type a
   40-character string.

The root cause of this bug seems to be a heap buffer overflow in the
editbox input buffer. The buffer overflow seems in turn to originate in
this line in dlg_editbox():

644 strncpy(buffer, input, max_len - 1)[max_len - 1] = '\0';

If the length of the string in the buffer and the cursor position (i.e.,
*chr_offset) are both equal to max_len, setting buffer[max_len - 1] to
\0 reduces the string length by one. This causes the cursor position to
exceed the string length. Since dlg_edit_string() checks only the string
length and not the cursor position, this leads eventually to buffer
overflow when typing new characters in the same line.

Note that this bug seems to be the same with the one reported a couple
of years ago here:
https://lists.gnu.org/archive/html/bug-ncurses/2019-06/msg1.html


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

Kernel: Linux 5.4.0-91-generic (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages dialog depends on:
ii  debianutils   4.8.1.1
ii  libc6 2.31-13+deb11u2
ii  libncursesw6  6.2+20201114-2
ii  libtinfo6 6.2+20201114-2

dialog recommends no packages.

dialog suggests no packages.

-- no debconf information

Bug#996668: cinnamon-settings-daemon: cinnamon shutdown hang

[Nikos K]

Dear Maintainer,

i have exactly the same problem on a fresh install of debian sid on a new
laptop.

I could even reproduce the issue on an install on a KVM virtual machine.

On both I used the daily netiboot image [
https://d-i.debian.org/daily-images/amd64/20211202-00:16/netboot/mini.iso]


Occurred on both on the first reboot after Installation. No other software
installed. Only the desktop and cinnamon-desktop tasks from tasksel during
the installation process (and laptop for the laptop).


On the laptop it occurs on each reboot. On the VM it does not always
happen. Seems random.

The log entries are similar as above.


*If you need anything else, please let me know.*



*-- System Information:*

*Debian Release: bookworm/sid*

* APT prefers unstable*

* APT policy: (500, 'unstable')*

*Architecture: amd64 (x86_64)*


*Kernel: Linux 5.15.0-2-amd64 (SMP w/16 CPU threads)*

*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)*

*LSM: AppArmor: enabled*

Bug#998193: gitlab: dpkg --configure gitlab fails with NoMethodError: undefined method `build' for debian bullseye

[Nikos Frangakis]

Package: gitlab
Version: 14.1.7+ds1-2~fto11+1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   Fresh installation of gitlab from fasttrack repository fails with the
   following error: 


Initializing database...
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
/usr/lib/ruby/vendor_ruby/nokogumbo/html5.rb:13: warning: already initialized 
constant Nokogiri::HTML5::HTML_NAMESPACE
/var/lib/gems/2.7.0/gems/nokogiri-1.12.5-x86_64-linux/lib/nokogiri/html5.rb:227:
 warning: previous definition of HTML_NAMESPACE was here
/usr/lib/ruby/vendor_ruby/nokogumbo/html5.rb:14: warning: already initialized 
constant Nokogiri::HTML5::MATHML_NAMESPACE
/var/lib/gems/2.7.0/gems/nokogiri-1.12.5-x86_64-linux/lib/nokogiri/html5.rb:228:
 warning: previous definition of MATHML_NAMESPACE was here
/usr/lib/ruby/vendor_ruby/nokogumbo/html5.rb:15: warning: already initialized 
constant Nokogiri::HTML5::SVG_NAMESPACE
/var/lib/gems/2.7.0/gems/nokogiri-1.12.5-x86_64-linux/lib/nokogiri/html5.rb:229:
 warning: previous definition of SVG_NAMESPACE was here
/usr/lib/ruby/vendor_ruby/nokogumbo/html5.rb:16: warning: already initialized 
constant Nokogiri::HTML5::XLINK_NAMESPACE
/var/lib/gems/2.7.0/gems/nokogiri-1.12.5-x86_64-linux/lib/nokogiri/html5.rb:230:
 warning: previous definition of XLINK_NAMESPACE was here
/usr/lib/ruby/vendor_ruby/nokogumbo/html5.rb:17: warning: already initialized 
constant Nokogiri::HTML5::XML_NAMESPACE
/var/lib/gems/2.7.0/gems/nokogiri-1.12.5-x86_64-linux/lib/nokogiri/html5.rb:231:
 warning: previous definition of XML_NAMESPACE was here
/usr/lib/ruby/vendor_ruby/nokogumbo/html5.rb:18: warning: already initialized 
constant Nokogiri::HTML5::XMLNS_NAMESPACE
/var/lib/gems/2.7.0/gems/nokogiri-1.12.5-x86_64-linux/lib/nokogiri/html5.rb:232:
 warning: previous definition of XMLNS_NAMESPACE was here
rake aborted!
NoMethodError: undefined method `build' for 
#
/var/lib/gems/2.7.0/gems/pg_query-2.1.1/lib/pg_query/pg_query_pb.rb:6:in `'
/var/lib/gems/2.7.0/gems/activesupport-6.1.4.1/lib/active_support/dependencies.rb:332:in
 `require'
/var/lib/gems/2.7.0/gems/activesupport-6.1.4.1/lib/active_support/dependencies.rb:332:in
 `block in require'
/var/lib/gems/2.7.0/gems/activesupport-6.1.4.1/lib/active_support/dependencies.rb:299:in
 `load_dependency'
/var/lib/gems/2.7.0/gems/activesupport-6.1.4.1/lib/active_support/dependencies.rb:332:in
 `require'
/var/lib/gems/2.7.0/gems/pg_query-2.1.1/lib/pg_query.rb:4:in `'
/usr/share/rubygems-integration/all/gems/bundler-2.2.5/lib/bundler/runtime.rb:66:in
 `require'
/usr/share/rubygems-integration/all/gems/bundler-2.2.5/lib/bundler/runtime.rb:66:in
 `block (2 levels) in require'
/usr/share/rubygems-integration/all/gems/bundler-2.2.5/lib/bundler/runtime.rb:61:in
 `each'
/usr/share/rubygems-integration/all/gems/bundler-2.2.5/lib/bundler/runtime.rb:61:in
 `block in require'
/usr/share/rubygems-integration/all/gems/bundler-2.2.5/lib/bundler/runtime.rb:50:in
 `each'
/usr/share/rubygems-integration/all/gems/bundler-2.2.5/lib/bundler/runtime.rb:50:in
 `require'
/usr/share/rubygems-integration/all/gems/bundler-2.2.5/lib/bundler.rb:173:in 
`require'
/usr/share/gitlab/config/application.rb:15:in `'
/usr/share/gitlab/Rakefile:9:in `require'
/usr/share/gitlab/Rakefile:9:in `'



-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (100, 'bullseye-fasttrack'), (100, 'bullseye-backports-staging')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/16 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gitlab depends on:
ii  apache2 [httpd] 2.4.51-1~deb11u1
ii  asciidoctor 2.0.16-1~fto11+1
ii  bc  1.07.1-2+b2
ii  bundler 2.2.5-2
ii  bzip2   1.0.8-4
ii  dbconfig-pgsql  2.0.19
ii  debconf [debconf-2.0]   1.5.77
ii  exim4   4.94.2-7
ii  exim4-daemon-light [mail-trans  4.94.2-7
ii  fonts-font-awesome [node-font-  5.0.10+really4.7.0~dfsg-4.1
ii  gitlab-common   14.1.7+dfsg-1~fto11+1
ii  gitlab-workhorse14.1.7+ds1-2~fto11+1
ii  katex [node-katex]  0.13.11+~cs6.0.0-2~bpo11+1
ii  libjs-bootstrap4 [node-bootstr  4.5.2+dfsg1-7
ii  libjs-codemirror [node-codemir  5.59.2+~cs0.23.109-1
ii  libjs-pdf [node-pdfjs-dist] 2.6.347+dfsg-3
ii  libjs-popper.js [node-popper.j  1.16.1+ds-3
ii  libruby2.7 [ruby-rexml] 2.7.4-1
ii  lsb-base11.1.0
ii  

Bug#972144: newsboat: segmentation fault at startup

[Nikos Tsipinakis]

On 15/10, Julien Rabier wrote:
> I've compiled newsboat manually from source (commit:
> 43a6084c78a1b5f745d3fda219e3dbb43fcb0d1f) and the issue doesn't occur
> anymore.
> 
> I think this bug report might be closed by upgrading newsboat in Debian
> to 2.21 released 25 days ago.

Hi,

I've uploaded 2.21 to unstable, please test it when you get the chance to ensure
this is indeed fixed and not something else.

-- 
Best Regards,
  Nikos Tsipinakis

Bug#970858: RFS: dunst/1.5.0-1 -- dmenu-ish notification-daemon

[Nikos Tsipinakis]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "dunst":

 * Package name: dunst
   Version : 1.5.0-1
   Upstream Author : Nikos Tsipinakis 
 * URL : https://dunst-project.org/
 * License : BSD-3-clause, ISC
 * Vcs : https://salsa.debian.org/debian/dunst
   Section : x11

It builds those binary packages:

  dunst - dmenu-ish notification-daemon

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/d/dunst/dunst_1.5.0-1.dsc

Changes since the last upload:

 dunst (1.5.0-1) unstable; urgency=medium
 .
   * New upstream version 1.5.0
   * d/control: Bump debhelper compat to 13 (no changes)
   * d/control: Bump standards version to 4.5.0 (no changes)
   * d/copyright: Update copyright years
   * d/patches: Refresh patches
   * d/patches: Fix typo in dunstify error message
   * d/control: Specify Rules-Requires-Root: no
   * d/copyright: Add upstream contact info

Note: I'm a DM but don't currently have upload rights for this package

-- 
Best Regards,
  Nikos Tsipinakis

Bug#970859: RFS: picom/8.1-1 -- lightweight compositor for X11

[Nikos Tsipinakis]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "picom":

 * Package name: picom
   Version : 8.1-1
   Upstream Author : Yuxuan Shui 
 * URL : https://github.com/yshui/picom
 * License : Expat, MPL-2.0, Expat and MPL-2.0
 * Vcs : https://salsa.debian.org/nikos/picom
   Section : x11

It builds those binary packages:

  picom - lightweight compositor for X11

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/p/picom/picom_8.1-1.dsc

Changes since the last upload:

 picom (8.1-1) unstable; urgency=medium
 .
   * New upstream version 8.1

Note: I'm a DM but don't currently have upload rights for this package

-- 
Best Regards,
  Nikos Tsipinakis

Bug#966088: mailinglist debian-r...@lists.debian.org

[Nikos Tsipinakis]

I also support this request. Due to the noise I never look at the messages on
pkg-rust-maintainers unless I'm looking for the status of a specific package,
so all human messages are lost.

-- 
Best Regards,
  Nikos Tsipinakis

Bug#963236: newsboat: Failure when receiving data from the peer

[Nikos Tsipinakis]

On 21/06, Dino Conte wrote:
> From another program (Quiterss, RSSOwl etc.) this works without problems, also
> the addresses can be pinged. If I install Newsboat from the Snap-Store for
> testing purposes, fetching the feeds also works with Newsboat.

Looks like the server might be buggy, curl fails as well:

$ curl  -L http://www.presseportal.de/rss/dienststelle_58451.rss2
curl: (35) error:1414D172:SSL routines:tls12_check_peer_sigalg:wrong signature 
type

I found the following leads in regards to this error message[1][2]

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934453
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912759

Bug#961432: RFP: picom -- lightweight compositor for X11

[Nikos Tsipinakis]

On 31/05, Lev Lamberov wrote:
> Please, finalize your work, add tags and ping me. I'll upload it to the
> Debian archive.

Merged, tagged, and pushed. Should ready to be uploaded now.

- Nikos

Bug#961432: RFP: picom -- lightweight compositor for X11

[Nikos Tsipinakis]

On 31/05, Lev Lamberov wrote:
> Yep, but as I understand they are in situation where some distributions
> picked their fork at the times it was not renamed to picom. Now this
> causes troubles. So the rename and migration plan. Since in Debian we
> are starting from scratch, I don't think we need these hacks. Anyway,
> migrating from compton to picom will require manually installing a new
> package, so users are already know that they need to learn about that
> new thing and to change their configuration. Alternatively, I'd choose
> update-alternatives way, but since there are almost no alternatives in
> terms of maintained X11 compositors, I personally don't think it
> deserves any time investment.

Makes sense, will leave as-is then.

> Ouch! And tags are also missing from your repository. Since you use gbp,
> then gbp push is to the rescue.

That's intentional, since I'm not sure which revision will end up uploaded
currently I haven't tagged it yet to avoid force updates.

> Will look again at the picom package this evening.

Looking forward to it :)

- Nikos

Bug#961432: RFP: picom -- lightweight compositor for X11

[Nikos Tsipinakis]

Hi Lev,

On 31/05, Lev Lamberov wrote:
> Good. Could you update your Salsa repository too?

Whoops, forgot to push, updated with all the recent changes.

> Your d/watch needs some tweaks, because currently it detects 7.5 as the
> latest upstream version, where there is 8 (which you package).

Fixed.

> I'd recommend using pristine-tar.
>
> And I have a question. Why don't you import upstream versions as
> archives and not use upstream branch to track upstream master? The
> latter could make cherry-picking patches much more easy.

This reminds me of the discussion on d-devel about the myriad ways of using git
for debian patching. The disappointing answer is "that's the way I've done it
this far", however I haven't taken the time to explore all the different
workflows, which I do aim on doing soon.

> I: picom: spelling-error-in-binary usr/bin/picom everytime every time
> I: picom: spelling-error-in-manpage usr/share/man/man1/picom.1.gz everytime 
> every time

Fixed.

> P: picom source: file-contains-trailing-whitespace debian/control (line 50)
> P: picom source: package-uses-old-debhelper-compat-version 12
> P: picom source: rules-requires-root-missing

Fixed.

> Also, do we really need to have symlinks (compton and compton-trans)
> and corresponding desktop files? Since it is a new Debian package,
> probably we can drop these. What do you think?

You're right, for now they serve no purpose so I removed them. However, upstream
seems to have a full migration plan from compton[1] and it looks like they do
intend on keeping backwards compatibility to some degree. So, it might be worth
looking into the possibility of going through a migration to picom, given that
compton is unmaintained, and will inevitably bitrot.

[1] https://github.com/yshui/picom/#migration

- Nikos

Bug#961432: RFP: picom -- lightweight compositor for X11

[Nikos Tsipinakis]

On 26/05, Lev Lamberov wrote:
> Then you could compare your packages and somehow merge them, taking best 
> pieces.

I took a look at that package and cherry-picked some improvements from there,
also added Fritz to d/copyright. I think it's ready to be uploaded now, I've
put it on mentors[1].

Upstream symlinks compton to picom and also installs a compton.desktop file, so
rather than override that I opted to set a Conflict/Replaces for compton.

[1] https://mentors.debian.net/debian/pool/main/p/picom/picom_8-1.dsc

Bug#961432: RFP: picom -- lightweight compositor for X11

[Nikos Tsipinakis]

On 26/05, Lev Lamberov wrote:
> Would be nice if you could work together on preparing picom for Debian.
> I propose Nikos to look at your current work and base on it. Then,
> please, let me know when you think it's ready, and I'll take a look.
> Please, keep me posted.

That reached me a bit too late sadly, I've already used compton as a base to get
a workable picom package. What remains now is the copyright file. The complexity
here comes from the random spread of the 2 licenses. Some files are MIT from the
compton authors, and others are MPL which is the license upstream uses now.

Upstream uses 'SPDX-License-Identifier: [MPL-2.0 | MIT]' to specify the license
for each file, sadly however licensecheck doesn't appear to recognize it.

Bug#961460: src:newsboat: build depends on librust-xdg-2-dev which doesn't exist (anymore)

[Nikos Tsipinakis]

Hi,

I'm confused here, I just did a test build in a fresh unstable chroot and it
seems like newsboat builds just fine.

librust-xdg-2-dev is provided by librust-xdg[1]. Is this a false positive of
some build script? Or perhaps the rebuild was run in testing rather than
unstable (librust-xdg hasn't migrated yet).

[1] https://tracker.debian.org/media/packages/r/rust-xdg/control-2.2.0-2

- Nikos

On 24/05, Paul Gevers wrote:
> Source: newsboat
> Version: 2.19-1
> Severity: serious
> User: trei...@debian.org
> Usertags: -1 edos-uninstallable
> 
> Dear maintainer(s),
> 
> Your package Build-Depends on librust-xdg-2-dev but that package isn't
> available in Debian (anymore). You should probably Build-Depends on
> librust-xdg-dev instead.
> 
> Paul
> 

Bug#961432: RFP: picom -- lightweight compositor for X11

[Nikos Tsipinakis]

retitle -1 ITP: picom -- lightweight compositor for X11
owner -1
thanks

My initial thought was that the compton maintainer should be the one to take
this over, but it looks like[1] compton was orphaned as its maintainer moved on
to wayland.

In which case, I'm interested in packaging this.

- Nikos

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960779

Bug#961420: package-sponsorhip-requests search results point to invalid path

[Nikos Tsipinakis]

Package: lists.debian.org
Severity: normal

Hi,

The search results[1] from the package-sponsorship-requests mailing list appear 
to
404. On closer inspection it looks like the results point to
'/package-sponsorship-requests/%Y/%M/msgid.html' while, looking at the list
archives, the correct url appears to be
'package-sponsorship-requests/%Y/package-sponsorship-requests-%Y%m/msgid.html'.

[1] 
https://lists.debian.org/cgi-bin/search?P=xautolock=or=Gpackage-sponsorship-requests==10=rust=Gpackage-sponsorship-requests%7E-%7E%7E4294967295

- Nikos

Bug#927684: dunstify is missing from package

[Nikos Tsipinakis]

Hi,

dunstify wasn't included in the default installation target before,
but this has now been changed upstream. The next upload/release
will also include dunstify.

notify-send indeed can't define actions.

On Tue, 12 May 2020, at 15:52, Jakson Alves de Aquino wrote:
> I'm using dunstify in scripts to send messages to dunst,
> including the definition of actions. Is notify-send capable of
> defining actions? I couldn't find this capability in its man page.
> So, I believe that other users would benefit from dunstify being
> available in a Debian package.
> 
> Thank you!
> 
> -- 
> Jakson Aquino
>

Bug#958448: I'd like to package doh-cli

[Nikos Roussos]

Control: retitle -1 ITP: doh-cli - A simple DNS over HTTPS client for
the command line


I'm interested in packaging doh-cli. I have already working on that locally.

Bug#958448: RFP: doh-cli - A simple DNS over HTTPS client for the command line

[Nikos Roussos]

Package: wnpp
Severity: wishlist

* Package name: dog-cli
  Version : 0.3
  Upstream Author : Evaggelos Balaskas https://gitlab.com/ebal
* URL : https://pypi.org/project/doh-cli/
* License : GPL-3
  Programming Lang: Python
  Description : A simple DNS over HTTPS client for the command line

This is a simple DNS over HTTPS (DoH) command line client.
It's written in Python and implements RFC8484,
supporting plain (default) and json output.

Bug#952507: dunst cannot be disabled and steals notifications

[Nikos Tsipinakis]

Sorry for the delay,

On 03/03, Norbert Preining wrote:
> Is there a way to claim that interface/service somehow? I am thinking of
> other cinnamon users (since I am one of the maintainers of Cinnamon in
> Debian), and how Cinnamon could stop dbus from starting another
> notification daemon, when the one from cinnamon is already running.
> Is there a way for this? 

That's already the case, dunst cannot start if another notification daemon is
running, you can test it by running dunst and trying to start a second instance
of it:

```
$ dunst
BadAccess (attempt to access private resource denied)
BadAccess (attempt to access private resource denied)
Unable to grab key "ctrl+grave"
Cannot acquire 'org.freedesktop.Notifications': Name is acquired by PID '1547'.
```

So sadly it's either a race over which daemon gets the address first, or up to 
dbus to
decide which daemon to start.

> Or is it anyway too late, because the notification service is started
> already before the cinnamon session is started? (during xsession
> somewhere)?

Unless there are user modifications to the startup scripts dunst is only started
by dbus. So if the systemd service is disabled it shouldn't be running at all
until a notification comes in and dbus starts it.

> Not really anything better than learning how to claim the dbus faster
> than dunst?
> Is there a way to "shadow"/disable it, similar to shadowing of systemd
> units?


I'm not aware of anything else, some googling brought me to this bug[1]:
> The recommended way to disable a D-Bus service is currently "don't install 
> it".

Another comment in that bug suggests that you could override the service file
from `~/.local/share/dbus-1/services` and neutralize it that way, but I'm not
sure whether that'll work.

[1] https://gitlab.freedesktop.org/dbus/dbus/issues/70

Bug#952507: dunst cannot be disabled and steals notifications

[Nikos Tsipinakis]

Hello,

On 25/02, Norbert Preining wrote:
> How am I supposed to disable this program?
> And no, I do *not* want to remove it, nor mask the service, because
> other uses are using i3 and are using dunst here.

The autostart part of dunst is managed by dbus, specifically the auto-activation
feature. Unfortunately dbus is not as powerful of a service manager as systemd
and it doesn't have a way to prioritise one service over another, or a way to
disable one while still keeping it installed.

So what can be done now?

I don't see a way to solve this other than removing the dbus service file
entirely, but for this to work and not break a lot of other systems we have to
auto-enable dunst for all desktop users on install

This is difficult because i3/X11 in debian doesn't run in systemd so we
can't explicitly say to only start dunst after the graphical session has
started. So it leaves the only option of having an auto-restart on failure every
X seconds (pretty ugly approach IMO, and it's going to spam the error logs if no
graphical session is started for a while).

Any other suggestions?

>From your side you can remove the service file at
/usr/share/dbus-1/services/org.knopwob.dunst.service and have the i3 users
enable dunst via systemd or enable it globally and disable it for yourself.

- Nikos

Bug#949180: newsboat coredumps (with illegal (?) character in existing ~/.newsboat/config)

[Nikos Tsipinakis]

forwarded -1 https://github.com/newsboat/newsboat/issues/723
thanks

On 17/01, gregor herrmann wrote:
> Whatever character there was, after removing it, newsboat starts
> again. So kind of a "user error"; still this has been working for
> years and breaking reading a config file smells like a regression.

Indeed a bug, it's a side-effect from Rust having a strict requirement of all
strings being valid UTF-8.

Bug#948782: linux: Request for CONFIG_DM_CLONE=m on 5.4+

[Nikos Tsironis]

Source: linux
Version: 5.4.8-1
Severity: normal

Dear Debian kernel maintainers,

Could you consider enabling the dm-clone device mapper target as a
module from the 5.4 kernel and onwards?

dm-clone produces a one-to-one copy of an existing, read-only source
device into a writable destination device. The cloned device is
visible/mountable immediately and the copy of the source device to the
destination device happens in the background, in parallel with user I/O.

Thanks,
Nikos Tsironis

Bug#941855: dunst: Daily systemd errors: "Failed to start Dunst notification daemon."

[Nikos Tsipinakis]

I apologise for the delay in replying but I don't have many clues as to what's
happening here or any easy ways to debug it.

On 20/10, Francois Marier wrote:
> > Perhaps the import-environment fails, could you add `echo DISPLAY=$DISPLAY` 
> > under that
> > and see if it appears in .xsession_errors?
> 
> I added a line to that startup script to email me the value of $DISPLAY when
> it runs and I got the following:
> 
>   DISPLAY=:1

Curious why it's :1 and not :0, are you running a second X11 session? It could
have something to do with that if that's the case.

> I looked at the notification log (Ctrl+`) this morning after seeing these
> errors in the logs and there was nothing matching that timestamp. Not
> surprising since these are complaints about failing to start.
> 
> The only cronjob I have that is set to run specifically at 7am is:
> 
>   /etc/cron.d/anacron
> 
> but then maybe the /etc/cron.daily/ jobs also run at around that time.

Well, when anacron runs it basically also calls all global crons in the system
so that doesn't help much.

>From the logs you provided it seems that for your own user session dunst seems
to be running normally even when these failure logs appears, so my working
hypotheses now is that there's an automated job trying to send a notification as
a different user - systemd tries to start dunst which fails as there's no X11
running as that user.

Does that sound something that might be happening - do you have any such
customizations to your systems?

I'm not aware of any packages that use libnotify notifications as part of
cron/automated jobs so it's most likely something added later.

--
Best Regards,
  Nikos Tsipinakis

Bug#941855: dunst: Daily systemd errors: "Failed to start Dunst notification daemon."

[Nikos Tsipinakis]

On 12/10, Francois Marier wrote:
> On 2019-10-12 at 09:25:20, Nikos Tsipinakis wrote:
> I've got this line in my ~/.config/i3/config:
> 
>   exec --no-startup-id /home/francois/devel/remote/user-scripts/startup
> 
> and that corresponds to a script [1] with these lines:
> 
>   /usr/bin/systemctl --user import-environment DISPLAY
>   /usr/bin/systemctl status --user dunst

Huh, why `status` and not `start`? Is that a typo?

Perhaps the import-environment fails, could you add `echo DISPLAY=$DISPLAY` 
under that
and see if it appears in .xsession_errors?

> > However it is weird that systemd reports that dunst is running even though 
> > it
> > obviously fails to start. I'm not sure what is going on there.
> 
> I don't think it fails to start because it works fine and it looks like
> this:
> 
>   $ systemctl status --user dunst.service
>   ● dunst.service - Dunst notification daemon
>  Loaded: loaded (/usr/lib/systemd/user/dunst.service; enabled; vendor 
> preset: enabled)
>  Active: active (running) since Fri 2019-10-11 19:21:31 PDT; 15h ago
>Docs: man:dunst(1)
>Main PID: 5330 (dunst)
>  Memory: 4.0M
>  CGroup: /user.slice/user-1000.slice/user@1000.service/dunst.service
>  └─5330 /usr/bin/dunst
> 
>   $ pgrep -a dunst
>   5330 /usr/bin/dunst

Indeed that looks like it's running - however the error you showed is always
fatal and the logs do show dunst service failed a few times, so something
happens at that point in time daily that prevents access to X11 and dunst can't
start? Bizarre.

> The part that confuses me is that once a day (always almost exactly at the
> same time) it tries to start or restart (and fails) even though it's already
> running in my user session.
> 
> Is there a cron-like job that runs every morning?

No, there's nothing that's scheduled to run at a specific time. However, dbus
_will_ try to start dunst via systemd if a notification comes through and it
detects that it isn't running. Perhaps you have a cron scheduled at that time?

Bug#941855: dunst: Daily systemd errors: "Failed to start Dunst notification daemon."

[Nikos Tsipinakis]

Hi,

This is usually caused by not having exported the DISPLAY variable into the
systemd environment, there has been extensive discussion about this in #347[1]
upstream.
How are you starting X11, are you using a custom xinitrc?

However it is weird that systemd reports that dunst is running even though it
obviously fails to start. I'm not sure what is going on there.

[1] https://github.com/dunst-project/dunst/issues/347

Bug#939830: gnome-shell: Handling of special keyboard shortcuts

[Nikos Voutsinas]

Package: gnome-shell
Version: 3.30.2-9
Severity: normal

Dear Maintainer,

On a Debian Buster/Gnome setup, with the Virtualbox 6.x package installed 
special keyboard shortcuts that have been configured on the host machine are 
not made available to the guest machine even when the guest has been started 
with the "Auto capture keyboard" option turned on. Under the same setup, 
unconfigured keyboard shortcuts on the host machine are caught by the guest as 
expected. One major side effect of this is the fact that standard keyboard 
shotcuts are not available on the guest machine, such as switching between 
desktops by using the "Super key + PgUp/PgDn".

Switching to another desktop environment e.g. KDE, brings back the expected 
behavior in all cases. Finally the results are same both with the Debian's and 
Oracle's Virtualbox packages.

To reproduce:

1. On the Host Machine configure via the Gnome Settings the F1 keyboard
Shortcut to launch e.g. the terminal-emulator
2. On the Guest Machine configure via the Gnome Setting both F1 and F2
keyboard Shortcuts to launch the terminal-emulator
3. On the Guest Machine press the F1 key. That will bring the terminal
of the Host Machine.
4. On the Guest Machine press the F2 key. That will bring the terminal
of the Guest Machine

Expected outcome: Both F1 and F2 on the Guest Machine are expected to bring the 
terminal emulator of the Guest Machine assuming that the Auto captur keyboard 
setting is turned on.

see also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810257#10


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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  evolution-data-server3.30.5-1
ii  gir1.2-accountsservice-1.0   0.6.45-2
ii  gir1.2-atspi-2.0 2.30.0-7
ii  gir1.2-freedesktop   1.58.3-2
ii  gir1.2-gcr-3 3.28.1-1
ii  gir1.2-gdesktopenums-3.0 3.28.1-1
ii  gir1.2-gdm-1.0   3.30.2-3
ii  gir1.2-geoclue-2.0   2.5.2-1
ii  gir1.2-glib-2.0  1.58.3-2
ii  gir1.2-gnomebluetooth-1.03.28.2-4~deb10u1
ii  gir1.2-gnomedesktop-3.0  3.30.2.1-2
ii  gir1.2-gtk-3.0   3.24.5-1
ii  gir1.2-gweather-3.0  3.28.2-2
ii  gir1.2-ibus-1.0  1.5.19-4
ii  gir1.2-mutter-3  3.30.2-7
ii  gir1.2-nm-1.01.14.6-2
ii  gir1.2-nma-1.0   1.8.20-1.1
ii  gir1.2-pango-1.0 1.42.4-7~deb10u1
ii  gir1.2-polkit-1.00.105-25
ii  gir1.2-rsvg-2.0  2.44.10-2.1
ii  gir1.2-soup-2.4  2.64.2-2
ii  gir1.2-upowerglib-1.00.99.10-1
ii  gjs  1.54.3-1
ii  gnome-backgrounds3.30.0-1
ii  gnome-settings-daemon3.30.2-3
ii  gnome-shell-common   3.30.2-9
ii  gsettings-desktop-schemas3.28.1-1
ii  libatk-bridge2.0-0   2.30.0-5
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libcanberra-gtk3-0   0.30-7
ii  libcanberra0 0.30-7
ii  libcroco30.6.12-3
ii  libecal-1.2-19   3.30.5-1
ii  libedataserver-1.2-233.30.5-1
ii  libgcr-base-3-1  3.28.1-1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libgirepository-1.0-11.58.3-2
ii  libgjs0g 1.54.3-1
ii  libglib2.0-0 2.58.3-2+deb10u1
ii  libglib2.0-bin   2.58.3-2+deb10u1
ii  libgstreamer1.0-01.14.4-1
ii  libgtk-3-0   3.24.5-1
ii  libical3 3.0.4-3
ii  libjson-glib-1.0-0   1.4.4-2
ii  libmutter-3-03.30.2-7
ii  libnm0   1.14.6-2
ii  libpango-1.0-0   

Bug#936032: systemd: Main process of service unit gets killed on reload if ExecReload fails

[Nikos Kormpakis]

Package: systemd
Version: 241-5
Severity: important
Tags: upstream

Dear Maintainer,

systemd kills the main process of a service unit after issuing a reload
command, if the command in `ExecReload` fails. This is a regression
introduced in v239 by upstream commit ec5b145 [1].

This behavior is not an expected one and changed systemd's behavior
during the reload of a unit. Before v239, an `ExecReload` command with
a non-successful exit code, would not kill the main process of the
unit. The change may cause problems in production environments, when
configuration changes happen, that include typos or syntax errors.

Imagine the following scenario:
  * Production server runs haproxy
  * A configuration change happens
  * A reload gets triggered from a configuration management tool
  * HAProxy's `ExecReload` command, `haproxy -c` exits with code 1 due
to a syntax error.
  * systemd kills HAProxy, causing an outage

This issue has been reported upstream in issue #11238 [2] and has been
fixed in commit d611cfa [3] of pull request #13098 [4]. The fix is
quite fresh (2019-07-17) and seems that will be included in v243.

Unfortunately, this issue has unexpected side-effects and may cause
problems to Debian users that use systemd to manage production-grade
services, after upgrading to Buster.

I tried to apply the fix [3] on the package's source tree for Buster
and it seems to work; the patch applies cleanly, the package gets
builded and systemd behaves as expected.

I think that it is possible to include this fix in Buster.

Thanks for maintaining systemd in Debian,
Nikos

[1] 
https://github.com/systemd/systemd/commit/ec5b1452ac73e41274f9b3ca401f813fa079b9f0
[2] https://github.com/systemd/systemd/issues/11238
[3] 
https://github.com/systemd/systemd/commit/86bc88ca8dbdeeefc2e5032636b9677fda126184
[4] https://github.com/systemd/systemd/pull/13098

-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-4
ii  libapparmor1 2.13.2-10
ii  libaudit11:2.8.4-3
ii  libblkid12.33.1-0.1
ii  libc62.28-10
ii  libcap2  1:2.25-2
ii  libcryptsetup12  2:2.1.0-5
ii  libgcrypt20  1.8.4-5
ii  libgnutls30  3.6.7-4
ii  libgpg-error01.35-1
ii  libidn11 1.33-2.2
ii  libip4tc01.8.2-4
ii  libkmod2 26-1
ii  liblz4-1 1.8.3-1
ii  liblzma5 5.2.4-1
ii  libmount12.33.1-0.1
ii  libpam0g 1.3.1-5
ii  libseccomp2  2.3.3-4
ii  libselinux1  2.8-1+b1
ii  libsystemd0  241-5
ii  mount2.33.1-0.1
ii  util-linux   2.33.1-0.1

Versions of packages systemd recommends:
ii  dbus1.12.16-1
ii  libpam-systemd  241-5

Versions of packages systemd suggests:
ii  policykit-10.105-25
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.133
ii  udev 241-5

-- no debconf information

Bug#935165: buster-pu: package newsboat/2.13-1+deb10u1

[Nikos Tsipinakis]

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

Hi,

I'd like to patch a use-after-free bug in newsboat. It was reported in debian
in #898559[1] and fixed upstream[2]. While I haven't been able to reproduce a
crash with it it's clear that it's there and I have received feedback that it
indeed fixes the linked issue.

Debdiff attached

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898559
[2] https://github.com/newsboat/newsboat/pull/603
diff -Nru newsboat-2.13/debian/changelog newsboat-2.13/debian/changelog
--- newsboat-2.13/debian/changelog  2018-09-23 21:01:29.0 +0300
+++ newsboat-2.13/debian/changelog  2019-08-17 21:10:38.0 +0300
@@ -1,3 +1,10 @@
+newsboat (2.13-1+deb10u1) buster; urgency=medium
+
+  [ Nikos Tsipinakis ]
+  * Patch use after free in itemlist (Closes: #898559)
+
+ -- Nikos Tsipinakis   Sat, 17 Aug 2019 21:10:38 +0300
+
 newsboat (2.13-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru newsboat-2.13/debian/patches/02-fix-use-after-free.patch 
newsboat-2.13/debian/patches/02-fix-use-after-free.patch
--- newsboat-2.13/debian/patches/02-fix-use-after-free.patch1970-01-01 
02:00:00.0 +0200
+++ newsboat-2.13/debian/patches/02-fix-use-after-free.patch2019-08-17 
21:10:22.0 +0300
@@ -0,0 +1,33 @@
+From a44a72ffa5c66a1de21476d23a8523001eecfc23 Mon Sep 17 00:00:00 2001
+From: Juho Pohjala 
+Date: Tue, 13 Aug 2019 16:10:16 +0300
+Subject: [PATCH] Crash when opening a url (#189)
+
+Caused by heap-use-after-free in ItemListFormAction::prepare().
+
+The complete invalidation mode repopulates the listfmt vector, thus it's
+not enough to clear the invalidated_itempos only in case of partial
+invalidation mode. The fix is to clear the invalidated_itempos vector
+also in case of complete invalidation mode.
+---
+ src/itemlistformaction.cpp | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/src/itemlist_formaction.cpp
 b/src/itemlist_formaction.cpp
+@@ -930,7 +930,6 @@
+   datetime_format);
+   listfmt.set_line(itempos, line, item.second);
+   }
+-  invalidated_itempos.clear();
+   } else {
+   LOG(level::ERROR,
+   "invalidation_mode is neither COMPLETE nor "
+@@ -942,6 +941,7 @@
+   listfmt.format_list(rxman, "articlelist"));
+   }
+ 
++  invalidated_itempos.clear();
+   invalidated = false;
+ 
+   set_head(feed->title(),
diff -Nru newsboat-2.13/debian/patches/series 
newsboat-2.13/debian/patches/series
--- newsboat-2.13/debian/patches/series 2018-09-23 21:01:29.0 +0300
+++ newsboat-2.13/debian/patches/series 2019-08-17 21:10:22.0 +0300
@@ -1 +1,2 @@
 01-use-policy-compliant-perl-hashbang.patch
+02-fix-use-after-free.patch

Bug#935021: newsboat: Error in Russian locale help

[Nikos Tsipinakis]

Control: tags -1 +fixed-upstream

It was fixed upstream with this commit: 
https://github.com/newsboat/newsboat/commit/662c7c45b48ae08475c1516548d33cca063c9789

It'll get fixed in unstable in the next upload.

Bug#931861: RM: newsbeuter -- RoM; abandoned upstream; actively maintained fork available

[Nikos Tsipinakis]

Package: ftp.debian.org
Severity: normal

Hello,

Please remove newsbeuter from the archive. It has been abandoned upstream and
there is an actively maintained fork (newsboat) already available in Debian.
It also currently fails to build with the new json-c version that'll be added in
the upcoming transition.

Best Regards,
  Nikos Tsipinakis

Bug#931372: RFS: dunst/1.4.1-1 [ITA] -- dmenu-ish notification-daemon

[Nikos Tsipinakis]

On 10/07, David Kalnischkies wrote:
> As far as I looked I have only some minor nitpick comments because
> I like looking at changelogs and get the feeling of understanding what
> happened without investigating too deeply.

Nitpicks, but very valid points nonetheless.

> I think I would prefer "Adopting package" or "Set myself as maintainer"
> or something like that as "Update" can basically mean everything like
> changing your email address, joining a team or whatever.

Fixed.

> >   * Update Build-Depends
> 
> If there is a good way to summarize what was exactly updated, please say
> so. Version bump? Now build-depending on KDE, GNOME and Qt3? 

I have to admit I wanted to explain a bit more here but given that there were a
bunch of small changes in the same file at the same time I got a bit lazy with
splitting commits and left it as-is. I've now broken the changes for this and
the copyright file down to individual commits, should be much better.

> >   * Bump standards version
> 
> Which standard? – also there is a new one out by now.

Added the version, and updated it to 4.4.0.

> >   * Bump debhelper compat to 12
> 
> You could switch to "debhelper-compat (= 12)" in Build-Depends and
> remove the debian/compat file.

Interesting I didn't know about that, it looks handy. I've updated it to use
this format now.

> >   * Install release notes in docs
> 
> Your are installing them as NEWS: Do you have a deeper reason for doing
> that?

The policy mentions that release notes should be installed as NEWS[1]

"If an upstream release notes file is available, containing a summary of changes
between upstream releases intended for end users of the package and often called
NEWS, it should be accessible as /usr/share/doc/package/NEWS.gz."

> The file contents look like a bit similar to a NEWS.Debian file
> in content, but then upstream name and content also suggest it should
> contain notes for each (major) release – even if 1.4 is missing – which
> would usually be a bit much for NEWS… but yeah, that is really just
> personal taste and style I guess. Long story short: mention NEWS.

It would be much if it was displayed during installation indeed but from my
understanding apt-listchanges only shows NEWS.Debian by default. So in my mind
it's fine to have it there for anyone who's interested to read it.

> 
> Thanks again for adopting a package and good luck finding a sponsor now
> that unstable is open again!
> 

Thank _you_ for taking a look and reviewing.

The new (more descriptive) changelog after this is the following:

  [ Francois Marier ]
  * Use sensible-browser instead of Firefox in /etc/xdg/dunst/dunstrc
  (Closes: #929456)

  [ Nikos Tsipinakis ]
  * Adopt package (Closes: #930310)
  * New upstream version 1.4.1
  * Remove cross.patch (applied upstream)
  * Refresh patches
  * d/control:
- Drop build-dep on libxdg-basedir
- Remove glib version constraint (minimum version no longer in archive)
- Drop build-dep on gtk in favour of gdk-pixbuf
- Add build-dep on dbus daemon and librsvg (required for the test suite)
  * Bump standards to 4.4.0
  * Install release notes as NEWS in docs
  * Bump debhelper compat to 12
Also switch to using debhelper-compat rather than d/compat
  * d/copyright:
- Update Source URL
- Add myself to debian/ attributions
- Add missing license for greatest.h

[1] 
https://www.debian.org/doc/debian-policy/ch-docs.html#changelog-files-and-release-notes

Best Regards,
 Nikos Tsipinakis

Bug#915841: newsbeuter FTBFS with json-c 0.13.1

[Nikos Tsipinakis]

On 03/07, Gianfranco Costamagna wrote:
>  Hello Nikos,you might want to first upload the fork in new queue, providing 
> the same binary, so the removal becomes a cruft later
> I mean, to not disrupt our userbase:
> with moving src:a providing a to src:b providing b
> [...]
> in case the fork is not a drop-in replacement, probably providing the old 
> binary name is not worth the effort, in this caseyou can do whatever you 
> prefer :)

The fork is functionally a drop-in equivalent, however given that the name
changed this also means that a) the name of the binary changed so everyone will
have to swap that out and that b) the name of the configuration directories
changed. There's an automated migration on the fork but it only works with
the simplest setups and fails in other cases.

Newsbeuter has had the fork on its Recommends for a while and I've put out a
NEWS entry informing about the change.

Overall given that there will need to be some manual migration from the users
side I'm not sure it's worth trying to do a proper package rename here.
Adding a new "newsbeuter" binary while in reality being newsboat would be a lot
more confusing than the alternative IMO.

Bug#931372: RFS: dunst/1.4.1-1 [ITA] -- dmenu-ish notification-daemon

[Nikos Tsipinakis]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 Package name: dunst
 Version : 1.4.1-1
 Upstream Author : Sascha Kruse 
 URL : https://dunst-project.org/
 License : BSD 3-clause
 Section : x11

It builds those binary packages:

  dunst - dmenu-ish notification-daemon

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

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


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

  dget -x https://mentors.debian.net/debian/pool/main/d/dunst/dunst_1.4.1-1.dsc

Changes since the last upload:

  [ Francois Marier ]
  * Use sensible-browser instead of Firefox in /etc/xdg/dunst/dunstrc
  (Closes: #929456)

  [ Nikos Tsipinakis ]
  * Update maintainer (Closes: #930310)
  * New upstream version 1.4.1
  * Remove cross.patch (applied upstream)
  * Refresh patches
  * Update Build-Depends
  * Bump standards version
  * Install release notes in docs
  * Bump debhelper compat to 12
  * Update copyright file

Regards,
 Nikos Tsipinakis

Bug#915841: newsbeuter FTBFS with json-c 0.13.1

[Nikos Tsipinakis]

On 01/07, Gianfranco Costamagna wrote:
> there is an upstream fix in a fork called newsboat
> 
> I'm attaching both patches to this bug report, please apply them!

I apologise for ignoring this issue earlier. I initially intended to convert
newsbeuter to a stub package pointing to newsboat but missed the buster 
deadline.

Given that upstream is abandoned and there is a functionally identical fork I
intend to remove newsbeuter from the archive. It doesn't make sense to become a
pseudo-upstream to keep it in Debian.

I'll file a removal request for it next week after the Buster release.

Bug#810257: virtualbox-qt: Keyboard capture doesn't

[Nikos Voutsinas]

Package: virtualbox
Version: 6.0.8-dfsg-7
Followup-For: Bug #810257

Dear Maintainer,

To reproduce:

1. On the Host Machine configure via the Gnome Settings the F1 keyboard
Shortcut to launch e.g. the terminal-emulator
2. On the Guest Machine configure via the Gnome Setting both F1 and F2
keyboard Shortcuts to launch the terminal-emulator
3. On the Guest Machine press the F1 key. That will bring the terminal
of the Host Machine.
4. On the Guest Machine press the F2 key. That will bring the terminal
of the Guest Machine 

Expected outcome: Both F1 and F2 on the Guest Machine are expected to bring the 
terminal emulator of the Guest Machine assuming that the Auto captur keyboard 
setting is turned on.


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

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

Versions of packages virtualbox depends on:
ii  adduser   3.118
ii  iproute2  4.20.0-2
ii  libc6 2.28-10
ii  libcurl3-gnutls   7.64.0-4
ii  libdevmapper1.02.12:1.02.155-3
ii  libgcc1   1:8.3.0-6
ii  libgl11.1.0-1
ii  libgsoap-2.8.75   2.8.75-1
ii  libopus0  1.3-1
ii  libpng16-16   1.6.36-6
ii  libpython3.7  3.7.3-2
ii  libqt5core5a  5.11.3+dfsg1-1
ii  libqt5gui55.11.3+dfsg1-1
ii  libqt5opengl5 5.11.3+dfsg1-1
ii  libqt5widgets55.11.3+dfsg1-1
ii  libqt5x11extras5  5.11.3-2
ii  libsdl1.2debian   1.2.15+dfsg2-4
ii  libssl1.1 1.1.1c-1
ii  libstdc++68.3.0-6
ii  libvncserver1 0.9.11+dfsg-1.3
ii  libvpx5   1.7.0-3
ii  libx11-6  2:1.6.7-1
ii  libxcursor1   1:1.1.15-2
ii  libxext6  2:1.3.3-1+b2
ii  libxml2   2.9.4+dfsg1-7+b3
ii  libxmu6   2:1.1.2-2+b3
ii  libxt61:1.1.5-1+b3
ii  procps2:3.3.15-2
ii  python3   3.7.3-1
ii  python3.7 3.7.3-2
ii  virtualbox-dkms [virtualbox-modules]  6.0.8-dfsg-7
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages virtualbox recommends:
ii  libxcb11.13.1-2
ii  virtualbox-qt  6.0.8-dfsg-7

Versions of packages virtualbox suggests:
pn  vde2
ii  virtualbox-guest-additions-iso  6.0.8-1

-- no debconf information

Bug#930310: O: dunst -- dmenu-ish notification-daemon

[Nikos Tsipinakis]

Control: retitle -1 ITA: dunst -- dmenu-ish notification-daemon
Control: owner -1 !

I intend to adopt this package, I am not a DM however so I'm going to need
someone to sponsor my uploads.

Full disclosure: I am also the upstream maintainer

Bug#923950: chromium: Received signal 11 SEGV_MAPERR on startup in headless and debugging mode

[Nikos Timiopulos]

Package: chromium
Version: 72.0.3626.96-1~deb9u2
Severity: important

Dear Maintainer,

since the last update of the chromium package on stretch I am getting signal 11 
SEGV_MAPPER on startup when running in headless and debugging mode.

Tested with 4.9.0-8-amd64 kernel too. The previous version 
70.0.3538.110-1~deb9u1 is without this issue.
 
Command to reproduce:

$ chromium --headless --remote-debugging-port=9222 --disable-gpu --no-sandbox

(you can leave --no-sandbox when not running as root)

Output:

Received signal 11 SEGV_MAPERR 0080
#0 0x562a587ea791 
#1 0x562a587eabfb 
#2 0x562a587eb25e 
#3 0x7fa0884e70e0 
#4 0x562a56bd2314 
#5 0x562a56bdd1b7 
#6 0x562a5c2c55e6 
#7 0x562a5c2c569a 
#8 0x562a56b6efd3 
#9 0x562a56fe8c32 
#10 0x562a56b71089 
#11 0x562a56b72039 
#12 0x562a5cd978b5 
#13 0x562a582952d7 
#14 0x562a58295581 
#15 0x562a58295930 
#16 0x562a582a0bfa 
#17 0x562a58293745 
#18 0x562a5c2cb363 
#19 0x562a5c2cb554 
#20 0x562a5829ddc9 
#21 0x562a55f3bd6d ChromeMain
#22 0x7fa07a9112e1 __libc_start_main
#23 0x562a55f3bb8a _start
  r8: 0001  r9: 0040 r10: 7fa037fff9d0 r11: 
0202
 r12: 7ffca82a94f0 r13: 562a60b19430 r14: 7ffca82a9540 r15: 
562a60b1b3c0
  di: 7ffca82a94f0  si: 562a5d3828f0  bp: 7ffca82a9590  bx: 
562a60b1e8d0
  dx: 562a56bd2314  ax: 7ffca82a94f0  cx: 0319  sp: 
7ffca82a9490
  ip: 562a56bd2314 efl: 00010202 cgf: 002b0033 erf: 
0004
 trp: 000e msk:  cr2: 0080
[end of stack trace]
Calling _exit(1). Core file will not be generated.

Best regards,

Nikos

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

Kernel: Linux 4.19.2 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=UTF-8 (charmap=locale: Cannot set LC_CTYPE 
to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968), LANGUAGE=en_US.UTF-8 (charmap=locale: Cannot set LC_CTYPE to 
default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages chromium depends on:
ii  libasound2   1.1.3-5
ii  libatk1.0-0  2.22.0-1
ii  libatomic1   6.3.0-18+deb9u1
ii  libatspi2.0-02.22.0-6+deb9u1
ii  libavcodec57 7:3.2.12-1~deb9u1
ii  libavformat577:3.2.12-1~deb9u1
ii  libavutil55  7:3.2.12-1~deb9u1
ii  libc62.24-11+deb9u4
ii  libcairo21.14.8-1
ii  libcups2 2.2.1-8+deb9u3
ii  libdbus-1-3  1.10.26-0+deb9u1
ii  libdrm2  2.4.74-1
ii  libevent-2.0-5   2.0.21-stable-3
ii  libexpat12.2.0-2+deb9u1
ii  libflac8 1.3.2-1
ii  libfontconfig1   2.11.0-6.7+b1
ii  libfreetype6 2.6.3-3.2
ii  libgcc1  1:6.3.0-18+deb9u1
ii  libgdk-pixbuf2.0-0   2.36.5-2+deb9u2
ii  libglib2.0-0 2.50.3-2
ii  libgtk2.0-0  2.24.31-2
ii  libicu57 57.1-6+deb9u2
ii  libjpeg62-turbo  1:1.5.1-2
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.12-6
ii  libnss3  2:3.26.2-1.1+deb9u1
ii  libopenjp2-7 2.1.2-1.1+deb9u2
ii  libopus0 1.2~alpha2-1
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1
ii  libpangoft2-1.0-01.40.5-1
ii  libpci3  1:3.5.2-1
ii  libpng16-16  1.6.28-1
ii  libpulse010.0-1+deb9u1
ii  libre2-3 20170101+dfsg-1
ii  libsnappy1v5 1.1.3-3
ii  libstdc++6   6.3.0-18+deb9u1
ii  libvpx4  1.6.1-3+deb9u1
ii  libwebp6 0.5.2-1
ii  libwebpdemux20.5.2-1
ii  libwebpmux2  0.5.2-1
ii  libx11-6 2:1.6.4-3+deb9u1
ii  libx11-xcb1  2:1.6.4-3+deb9u1
ii  libxcb1  1.12-1
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.1.14-1+deb9u2
ii  libxdamage1  1:1.1.4-2+b3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxml2  2.9.4+dfsg1-2.2+deb9u2
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.29-2.1
ii  libxss1  1:1.2.2-1
ii  libxtst6 2:1.2.3-1
ii  x11-utils7.7+3+b1
ii  xdg-utils1.1.1-1+deb9u1
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages chromium recommends:
ii  fonts-liberation  1:1.07.4-2
ii  libgl1-mesa-dri   13.0.6-1+b2

Versions of packages chromium suggests:
pn  chromium-driver
pn  chromium-l10n  
pn  chromium-shell 
pn  chromium-widevine  

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE

Bug#898559: newsboat crashes when opening url

[Nikos Tsipinakis]

Control: forwarded -1 https://github.com/newsboat/newsboat/issues/189

Hi,

I've forwarded your report to the upstream bug tracker. If you have a github
account it'd be beneficial to keep track of the issue and respond to any
questions the upstream maintainer may have.

Bug#892277: bridge-utils: hotplugging interferes with ifupdown resulting in unpredictable behavior

[Nikos Kormpakis]

Hello,

I'd like to share also my experience with this bug, which also affects
us at work (GRNET). We have the following setup:

# cat /etc/debian_version
9.3
# dpkg -l | grep -e ifupdown -e vlan -e bridge-utils | awk '{print $2, $3}'
ii  bridge-utils 1.5-13+deb9u1
ii  ifupdown 0.8.19
ii  vlan 1.9-3.2+b1
# uname -a
Linux foo 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02) x86_64 
GNU/Linux

I have reproduced it by disabling networking.service, not loading the
bonding module on boot, with the following configuration:

# cat /etc/network/interfaces
auto bond0
iface bond0 inet static
  mtu   9000
  bond-mode 802.3ad
  bond_xmit_hash_policy layer3+4
  bond-miimon   100
  slavesens5f0 ens5f1

auto vlan109
iface vlan109 inet manual
  bridge_ports   bond0.109
  bridge_stp off
  bridge_maxwait 0
  bridge_fd  0
  mtu9000

auto vlan110
iface vlan110 inet manual
  bridge_ports   bond0.110
  bridge_stp off
  bridge_maxwait 0
  bridge_fd  0
  mtu9000

# cat /etc/modules
8021q
bonding

In our case, we noticed the following timeline which is quite similar
like Apollon's one:

* bonding module gets loaded into the kernel, way before
  networking.service gets started (defined in /etc/modules), should
  be unnecessary tbh)
* Interface bond0 gets created, which triggers a udev 'add' action
* The action calls bridge-network-interface with INTERFACE=bond0
* bridge-network-interface creates interface bond0.109. bond0.109 has
  MTU 1500 because ifup has not ran yet
* The creation of bond0.109 triggers another udev 'add' action (which, I
  think, should not happen)
* bridge-network-interface tries to run ifup --allow auto vlan109
* The above command fails because it cannot set the MTU of vlan109 to
  9000, because bond0.109's MTU is 1500. vlan109 interface is left in an
  unconfigured state.
* /lib/udev/bridge-network-interface fails because of set -e
* The second call of bridge-network-interface with INTERFACE=bond0.109
  fails in a similar way. All other interfaces are untouched.
* systemd starts up networking.service and runs ifup --allow=auto -a
* bond0 gets MTU 9000
* ifup tries to get vlan109 interface up
* This fails because bond0.109's MTU is 1500. It seems that ifupdown
  and/or bridge-utils do not touch it
* ifup for vlan110 runs successfully because it creates a new bond0.110
  interface, which inherits the MTU of bond0, which is now 9000 and gets
  up correctly

The above behavior does not always happen: If, for some reason,
networking.service gets started before bridge-network-interface runs its
stuff, all interfaces will get up correctly. Also, this affects only the
first interface in /e/n/i which has bridge_ports stanza defined, because
bridge-network-interface fails for the reasons I described above.

I agree with Apollon, I really do not understand what the code is trying
to do and why BRIDGE_HOTPLUG defaults to yes. We ran into serious
problems with silent packet loss in QEMU VMs, which had their tap
interfaces bridged to the above vlanXXX interfaces and MTU 9000 and the
only way to mitigate this problem for now is to set BRIDGE_HOTPLUG=no.

Unfortunately, it's not quite easy for us to suggest a solution but we
can provide more information if needed.

Regards,
Nikos

Bug#888426: certtool has year 2k38 problem, giving problems for scripts that generate 20 year certs today

[Nikos Mavrogiannopoulos]

No good solution to that, but given that we depend on glibc's time_t, we
are tied to it solving the issue. The issue is tracked at:
https://gitlab.com/gnutls/gnutls/issues/370

On Sun, Feb 18, 2018 at 2:12 PM Andreas Metzler  wrote:

> Control: found -1 3.6.2-1
> Control: found -1 3.5.18-1
>
> On 2018-01-25 Floris Bos  wrote:
> > Package: gnutls-bin
> > Version: 3.5.8-5+deb9u3
> > Severity: important
>
> > Hi,
>
> > Seems certtool (at least the version shipped with Debian Stretch) has a
> year
> > 2038 problem on 32-bit architectures.
> [...]
>
> Confirmed on i386/sid and experimental.
>
>

Bug#888548: kismet: Update to a more recent version

[Nikos Andrikos]

Hi Thomas,

>From what I see there is no newer release in the downloads page:
https://www.kismetwireless.net/download.shtml

Do you think there are changes to be included in a new release?
If yes, we should contact upstream in order to ask them about.

Kind regards,
Nick

--
=Do-
N.AND

2018-01-27 0:21 GMT+01:00 Thomas Andrejak :

> Source: kismet
> Version: 2016.07.R1-1
> Severity: wishlist
>
> The actual version is 2016 and start to be old. Please update to a
> more recent version.
>
> Regards
>
> Thanks
>
> Thomas
>

Bug#884893: newsboat: FTBFS: Error opening terminal: unknown.

[Nikos Tsipinakis]

Control: tags -1 pending fixed-upstream

Bug has been fixed upstream, upload pending until I figure out how to handle the
other 3 open bugs.

Bug#884893: newsboat: FTBFS: Error opening terminal: unknown.

[Nikos Tsipinakis]

Control: tags -1 - pending fixed-upstream

On 21/12, Nikos Tsipinakis wrote:
> Control: tags -1 pending fixed-upstream
> 
> Bug has been fixed upstream, upload pending until I figure out how to handle 
> the
> other 3 open bugs.

Accidentally replied to the wrong bug, sorry about that. I'm still unsure about
how to fix this one.

Bug#884892: newsboat: FTBFS on arm*: filter/Scanner.cpp: sign-compare errors

[Nikos Tsipinakis]

Control: tags -1 pending fixed-upstream

Bug has been fixed upstream, upload pending until I figure out how to handle the
other 3 open bugs.

Bug#884594: default configuration file location not recognised

[Nikos Tsipinakis]

(Accidentally replied only to the submitter - also sending this to the bug 
tracker for
the record)

On 18/12, g l wrote:
> > Sent: Monday, December 18, 2017 at 9:02 AM
> > From: "Nikos Tsipinakis" <ni...@tsipinakis.com>
> > 
> > I'm not sure what this is about.
> > 
> > > Error: no URLs configured. Please fill the file 
> > > .../.config/newsbeuter/urls with RSS feed URLs or import an OPML file.
> > 
> > As the error message says, you either need to add feed urls to
> > ~/.config/newsbeuter/urls or import an opml file with newsbeuter -i .
> >
> 
> This debian system compilation instruction is different from the newsbeuter 
> manual which states that the default directory is ~/.newsbeuter/ _not_ 
> ~/.config/newsbeuter.

Newsbeuter first checks if ~/.config/newsbeuter and ~/.local/share/newsbeuter
exists and if so it uses these directories, if not it falls back to
~/.newsbeuter. Please make sure that the XDG directories don't already exist.

Bug#884594: default configuration file location not recognised

[Nikos Tsipinakis]

Control: tags -1 + moreinfo

Hi,

I'm not sure what this is about.

> Error: no URLs configured. Please fill the file .../.config/newsbeuter/urls 
> with RSS feed URLs or import an OPML file.

As the error message says, you either need to add feed urls to
~/.config/newsbeuter/urls or import an opml file with newsbeuter -i .

Bug#634757: Adoption of lyx

[Nikos Andrikos]

Hi,

I'm not using lyx much any more, but I'm still active for packaging
and any other questions/problems you might experience.
Welcome on board.

Sven, sad to see you officially leaving  from the maintenance.
So long, and thanks for all the fish ! :)

Nick

--
=Do-
N.AND


2017-10-08 17:56 GMT+02:00 Sven Hoexter :
> On Sun, Oct 08, 2017 at 05:47:26PM +0200, Dr. Tobias Quathamer wrote:
>
> Hey,
>
>> In case of packaging problems and questions, may I contact you again?
>
> Sure, I'm still alive and have an eye on pkg-lyx-devel@lists.a.d.o as
> long as alioth is around. But you can also approach me directly.
>
> Sven
>
>
>

Bug#876370: parse_url: curl_easy_perform returned err 22

[Nikos Tsipinakis]

For the record, Graham sent the log to me privately. I'm not sure if that was
intentional or not.
If it wasn't, please make sure to preserve the Cc to 876...@bugs.debian.org in
the future to also send the message to the bug tracker.

Can you either apply the attached patch or build from upstream and try again?
(And send the log) It won't fix anything but it'll print the HTTP error code to
the log file, should help understand what's going on.

- Nikos
--- a/rss/parser.cpp
+++ b/rss/parser.cpp
@@ -142,7 +142,7 @@
 	LOG(LOG_DEBUG, "rsspp::parser::parse_url: ret = %d", ret);
 
 	long status;
-	curl_easy_getinfo(easyhandle, CURLINFO_HTTP_CONNECTCODE, );
+	curl_easy_getinfo(easyhandle, CURLINFO_HTTP_RESPONSE, );
 
 	if (status >= 400) {
 		LOG(LOG_USERERROR, _("Error: trying to download feed `%s' returned HTTP status code %ld."), url.c_str(), status);

Bug#876370: parse_url: curl_easy_perform returned err 22

[Nikos Tsipinakis]

Control: tags -1 + unreproducible moreinfo

Hi,

On 21/09, Debian BTS wrote:
>* What led up to the situation?
>I am trying to setup the following rss feed which works fine in a 
>browser. https://www.investegate.co.uk/Rss.aspx?company=KGF

Seems to be working fine on my end. Possibly the server was having trouble, try
again. If the problem still persists please attach the log file generated by
launching newsbeuter with 'newsbeuter -l 6 -d log' and running a refresh on the
feed.

- Nikos

Bug#876327: ITP: newsboat -- text mode rss feed reader with podcast support

[Nikos Tsipinakis]

Package: wnpp
Severity: wishlist
Owner: Nikos Tsipinakis <ni...@tsipinakis.com>

* Package name: newsboat
  Version : 2.10
  Upstream Author : Alexander Batischev
* URL : https://www.newsboat.org
* License : MIT/X Consortium
 Programming Lang : C++
 Description  : text mode rss feed reader with podcast support

 newsboat is an actively maintained for of newsbeuter, an innovative RSS feed
 reader for the text console.  It supports OPML import/exports, HTML rendering,
 podcast (podboat), offline reading, searching and storing articles to your
 filesystem, and many more features.

 Its user interface is coherent, easy to use, and might look
 common to users of mutt and slrn.

Bug#875929: acetoneiso: should it be removed from Debian

[Nikos Andrikos]

Hi Mattia,

The program is dead upstream and I have been maintainting (the bare
minimum) on my own.

I just saw that some months ago, people from Redhat ported it to Qt5.
I'll see what I can get from there, in order to include in a new upload.

For these reasons, I would prefer if the package is not removed for
now, in order to have enough time to fix the issues.

Kind regards,
Nikos
--
=Do-
N.AND

Bug#859453: dunst: Installing dunst does not ensure dbus is running

[Nikos Tsipinakis]

Package: dunst
Version: 1.1.0-2+b1
Severity:normal

Dear maintainer,

For dunst to work a dbus session needs to be running for the user but currently
if Xorg and a simple window manager is installed dbus is not running by default
which causes dunst to fail with

Name Lost. Is Another notification daemon running?

I recommend setting dunst to depend on or to recommend the dbus-x11 package
and/or the dbus-session-bus virtual package which among other things sets dbus
to launch either when the X11 session starts or when a process tries to use
dbus.

Bug#857675: libidn2-0 FTCBFS: runs host arch code during build (gentr46map, help2man)

[Nikos Mavrogiannopoulos]

On Tue, 2017-03-14 at 20:12 +0100, Helmut Grohne wrote:

> > > > Also, using -lunistring directly doesn't work out on systems
> > > > without
> > > > libunistring. I guess it needs libtool and $(LTLIBUNISTRING) +
> > > > ../gl/libgnu.la to do it portable. I can't test that for the
> > > > Debian
> > > > environment and know too less about cross-compiling to test
> > > > that myself.
> > > 
> > > I tried using $(LTLIBUNISTRING), but that doesn't work for two
> > > reasons:
> > > * It contains libtool parameter such as -R, which are not
> > > understood by
> > >   gcc.
> > > * It contains parameters specific to the host architecture, but
> > > we need
> > >   the libunitstring for the build architecture. Given that
> > > autoconf has
> > >   no means to check for a build architecture library, I figured
> > > that we
> > >   should skip checking it and link it directly.
> > > 
> > > Do you have any other ideas on how to fix this properly for
> > > everyone?
> > 
> > Not yet. I'll have a deeper look into libtool. If you are right and
> > libtool 
> > has no means for the build architecture, well then we have to use
> > libunistring 
> > directly :-(
> 
> The issue with libtool is that autoconf configures it for the host
> architecture. So any call to libtool becomes specific to the host
> architecture. This can result in using architecture-specific paths
> (e.g.
> /usr/lib/$host_triplet on Debian). Like one must not include config.h
> in
> a build tool, one must not use libtool on build tools (if cross
> compilation is supposed to work).
> 
> It seems to me that the first step here would be telling configure to
> search for libunistring twice. Searching for a host architecture
> libunistring is currently being done, but we'd also need the build
> architecture libunistring.
> 
> So maybe we can do something else: Bite the bullet and do not use
> libunistring for gentr46map? It seems that libunistring stuff
> generally
> matches /\bu(8|16|32)_.*/ and I fail to find such symbols in
> non-comments. Maybe we can skip it entirely (for these two files)? It
> may be less convenient, but so is trying to libtoolize twice.
> 
> This may seem totally backwards, but when I am faced with "broken"
> (in
> terms of cross compilation) build tools, I try to rewrite them as
> dumb
> and portable as possible. realloc()ing an array at 1 increases, such
> that it yields O(n^2)? Fine. All those inefficient practises are fine
> here to avoid dependencies at all cost.

But is that complexity needed here? Could we skip compilation of this
tool completely on build host and ship tr46map_data.c?


regards,
Nikos

Bug#777104: Adopting spectools

[Nikos Andrikos]

Hi Francois,

I'm the maintainer of the kismet package and I'm planning to also adopt
spectools.

I have already prepared a new package for the most recent upstream version,
i.e. 201601r1 and I fixed a couple of things while I was there.

Could you please give me permissions to push my changes to alioth?
My username is andrikos-guest.

Kindest regards,
Nick

--
=Do-
N.AND

Bug#844658: stretch GIT broken

[Nikos Mavrogiannopoulos]

I think few months ago a similar issue was reported.  The culprit was librtmp 
or some other lib linking to a version of nettle with unversioned symbols. That 
resulted to a symbol clash which caused that issue. The solution was to update 
that lib.

On 18 November 2016 02:50:14 CET, Daniel Kahn Gillmor  
wrote:
>On Fri 2016-11-18 06:03:59 +0900, martin carmichael wrote:
>> Package: gnutls-bin (3.5.5-6)
>>
>>
>> message: fatal: unable to access 'https://github.com :
>gnutls_handshake() failed: Public key signature verification has
>failed.
>>
>>
>>  git --version
>> git version 2.10.2
>>
>> uname -a
>> Linux debian 4.7.0-1-amd64 #1 SMP Debian 4.7.8-1 (2016-10-19) x86_64
>GNU/Linux
>>
>> git push
>> fatal: unable to access 'https://github.com...  : gnutls_handshake()
>failed: Public key signature verification has failed.
>
>I'm not seeing this at all:
>
>0 dkg@alice:/tmp/cdtemp.B2ws82$ git clone https://github.com/dkg/s6
>Cloning into 's6'...
>remote: Counting objects: 1899, done.
>remote: Total 1899 (delta 0), reused 0 (delta 0), pack-reused 1899
>  Receiving objects: 100% (1899/1899), 503.91 KiB | 283.00 KiB/s, done.
>Resolving deltas: 100% (1169/1169), done.
>0 dkg@alice:/tmp/cdtemp.B2ws82$
>
>Regards,
>
>--dkg

-- 
Sent fron my mobile. Please excuse my brevity.

Bug#839937: GnuTLS error (at worker-vpn.c:585): Error in the system's randomness device.

[Nikos Mavrogiannopoulos]

Hi,
 You can work-around the issue by setting isolate-workers=false. The
problem is that the getrandom() system call is not included in the
whitelisted seccomp filter. The "right" solution is to either apply
patch [0] or move to 0.11.5.

regards,
Nikos

[0]. 
http://pkgs.fedoraproject.org/cgit/rpms/ocserv.git/commit/?id=d0dbbc1a1988c995771c0bbb85894e723049b5ef

On Thu, Oct 6, 2016 at 4:19 PM, Gergely Katona <n...@tfw.hu> wrote:
> Subject: ocserv: GnuTLS error (at worker-vpn.c:585): Error in the system's
> randomness device.
> Package: ocserv
> Version: 0.11.4-1+b1
> Severity: important
>
> Dear Maintainer,
>
>
> I've started the ocserv service and tried to connect with an android phone
> and later on with a linux machine.
> Both times I recived:
> GnuTLS error (at worker-vpn.c:585): Error in the system's randomness device.
> On the client's side:
> LIB: SSL negotiation with srv3.unnamedhost.somewhere
> LIB: SSL connection failure: The TLS connection was non-properly terminated
>
>
> Oct 06 15:19:19 srv3 systemd[1]: Started OpenConnect SSL VPN server.
> Oct 06 15:19:19 srv3 ocserv[8425]: Setting 'radius' as primary
> authentication method
> Oct 06 15:19:19 srv3 ocserv[8425]: Setting 'radius' as accounting method
> Oct 06 15:19:19 srv3 ocserv[8425]: Setting 'file' as supplemental config
> option
> Oct 06 15:19:19 srv3 ocserv[8425]: listening on 2 systemd sockets...
> Oct 06 15:19:19 srv3 ocserv[8425]: main: initialized ocserv 0.11.4
> Oct 06 15:19:19 srv3 ocserv[8438]: sec-mod: reading supplemental config from
> files
> Oct 06 15:19:19 srv3 ocserv[8438]: sec-mod: sec-mod initialized (socket:
> /var/run/ocserv-socket.8425)
> Oct 06 15:19:48 srv3 ocserv[8445]: GnuTLS error (at worker-vpn.c:585): Error
> in the system's randomness device.
> Oct 06 15:19:48 srv3 ocserv[8425]: main: [:::192.168.31.230]:36872 user
> disconnected (reason: unspecified, rx: 0, tx: 0)
>
>
> -- System Information:
> Debian Release: 8.6
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 'testing'),
> (50, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.7.0-1-amd64 (SMP w/2 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot set
> LC_ALL to default locale: No such file or directory
> UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages ocserv depends on:
> ii  dbus 1.8.20-0+deb8u1
> ii  init-system-helpers  1.22
> ii  libc62.24-3
> ii  libev4   1:4.22-1
> ii  libgnutls30  3.5.4-2
> ii  libgssapi-krb5-2 1.14.3+dfsg-2
> ii  libhttp-parser2.12.1-2
> ii  liblz4-1 0.0~r131-2
> ii  libnettle6   3.2-1
> ii  libnl-3-200  3.2.27-1
> ii  libnl-route-3-2003.2.27-1
> ii  liboath0 2.6.1-1
> ii  libopts251:5.18.12-2
> ii  libpam0g 1.1.8-3.1+deb8u1+b1
> ii  libpcl1  1.6-1
> ii  libprotobuf-c1   1.2.1-1+b1
> ii  libradcli4   1.2.6-4
> ii  libreadline6 6.3-8+b3
> ii  libseccomp2  2.3.1-2
> ii  libsystemd0  215-17+deb8u5
> ii  libtalloc2   2.1.7-1
> ii  libtasn1-6   4.9-4
> ii  libwrap0 7.6.q-25
> ii  ssl-cert 1.0.38
>
> Versions of packages ocserv recommends:
> ii  ca-certificates  20141019+deb8u1
>
> ocserv suggests no packages.
>
> -- Configuration Files:
> /etc/ocserv/ocserv.conf changed [not included]
>
> -- debconf information excluded
>

Bug#835342: curl or git clone commands throws "gnutls_handshake() failed" on https targets

[Nikos Mavrogiannopoulos]

Thanks for the update, your case was really challenging my computing
knowledge :)
However, out of curiosity how does librtmp comes into play here? It
doesn't seem to be a dependency (direct at least) or either curl or
git.

On Fri, Sep 23, 2016 at 3:01 PM, marcelomen...@gmail.com
<marcelomen...@gmail.com> wrote:
> Ok, this is very odd!
> Long time ago I did some testing with some deb-multimedia packages.
> After the tests I made a clean up and removed all the packages, and
> the repo from my source lists, until the libgnutls30 upgrade
> everything was fine. Now when Mariusz pointed out his experience with
> similar issue I went to check the package and:
>
> As you can see, this package (librtmp1) remained of the deb-multimedia
> packages and has a old libgnutls dependency, my clean up wasn't so
> clean after all. :(
>
> -
> Package: librtmp1
> Version: 1:2.4+20130918.git79459a2-dmo6
> State: installed
> Automatically installed: yes
> Multi-Arch: same
> Priority: extra
> Section: libs
> Maintainer: Christian Marillat <maril...@deb-multimedia.org>
> Architecture: amd64
> Uncompressed Size: 160 k
> Depends: libc6 (>= 2.14), libgmp10, libgnutls-deb0-28 (>= 3.2.10-0),
> libhogweed2, libnettle4, zlib1g (>= 1:1.1.4)
> PreDepends: multiarch-support
> Breaks: librtmp1:i386 (!= 1:2.4+20130918.git79459a2-dmo6)
> Replaces: librtmp1:i386 (< 1:2.4+20130918.git79459a2-dmo6)
> Description: Toolkit for RTMP streams (shared library).
>  A small dumper for media content streamed over the RTMP protocol
> (like BBC's iPlayer high quality streams). Supplying an RTMP URL will
> result in a dumped flv file, which can
>  be played/transcoded with standard tools.
>
>  This package contains the shared libraries, header files needed by
> programs that want to use librtmp.
> Homepage: http://rtmpdump.mplayerhq.hu/
> Tags: role::shared-lib
> -
>
>
> When I downgraded(!) to from multimedia package to debian package, as
> suggested by Mariusz:
>
> Unpacking librtmp1:amd64 (2.4+20151223.gitfa8646d.1-1) over
> (1:2.4+20130918.git79459a2-dmo6) ...
> Setting up librtmp1:amd64 (2.4+20151223.gitfa8646d.1-1) ...
>
> Things are now working again.
>
> I'm still curious to know why the package didn't upgrade since the
> version of debian is from 20151223
>
>
> That was a bit of a mess (my fault), but I'm glad things get to work again.
>
> Thanks Mariusz for pointing out, and Thanks to Andreas and Nikos for
> the pentience. :)
>
> --
> "Free Software is not the only way, but it's a correct way."
> Marcelo Mendes
> http://underlabs.org
> mmendes @ IRC [OFTC-Freenode]
> Gtalk: marcelomendes at gmail dot com

Bug#829329: Error combining hardening flags with Qt5

[Nikos Andrikos]

Hi Dmitry,

I'm aware of the workaround and this is what I'm currently doing.
Leaving +pie (implicitly) in hardening flags makes no harm as the
-fPIC from CFFLAGS_APPEND will override it.

The reason for this bug report is that packages that use qt5 with
hardening flags will encounter this issue, exactly as the other bug I
mentioned in my original report.
I think this should be addressed more generally, without each
maintainer needing to go through the process of trying to debug why
enabling hardening flags might break builds with qt5 and coming up
with this workaround.

If you that this is too much of a hassle to address properly and it is
preferable to just work around it each time it happens, then we can
close this bug and I'm fine with it.

Thanks and best regards,
Nick

--
=Do-
N.AND

Bug#829329: Error combining hardening flags with Qt5

[Nikos Andrikos]

reopen -1
thanks

Hi Lisandro,

The -fPIE flags comes from the automatically generated hardening
options, which override the the -fPIC flag that comes from lyx
Makefile, since it comes later in the argument list.

lyx reports this configuration:
  C++ Compiler flags:   -Wall -Wextra -std=c++11 -fPIC -O2
-Wno-deprecated-declarations
  C++ Compiler user flags: -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
-fPIE -fstack-protector-strong -Wformat -Werror=format-security -fPIC
The first line are the default lyx options. The second line are the
automatically generated hardening options + "-fPIC" that I use as a
workaround to override -fPIE.
The two lines are merged and given to g++ for compilation.

This means that every package that uses qt5 and enables hardening
flags that include +pie (true by default for =all) will encounter this
issue and the maintainers will need to append -fPIC as a workaround.

If -fPIC is needed by design for qt5, then the issue (even as a
wishlist) is in dpkg-buildflags.
What do you think?

Nick

--
=Do-
N.AND

Bug#829329: Error combining hardening flags with Qt5

[Nikos Andrikos]

Package: libqt5core5a
Version: 5.6.1+dfsg-3
Severity: normal

I'm trying to enable Qt5 support for the lyx package I maintain.
I have already enabled hardening flags, and I get the following error when
building the package:

g++ -DHAVE_CONFIG_H -I. -I../../../src/support -I../..  -Wall -Wextra
-I../../../src/support/..  -DQT_NO_STL -DQT_NO_KEYWORDS
-I/usr/include/x86_64 -linux-gnu/qt5/QtConcurrent
-I/usr/include/x86_64-linux-gnu/qt5
-I/usr/include/x86_64-linux-gnu/qt5/QtSvg
-I/usr/include/x86_64-linux-gnu/qt5
-I/usr/include/x86_64-linux-gnu/qt5/QtWidgets
-I/usr/include/x86_64-linux-gnu/qt5
-I/usr/include/x86_64-linux-gnu/qt5/QtGui
-I/usr/include/x86_64-linux-gnu/qt5
-I/usr/include/x86_64-linux-gnu/qt5/QtCore
-I/usr/include/x86_64-linux-gnu/qt5 -Wdate-time -D_FORTIFY_SOURCE=2
-std=c++11 -fPIC -O2 -Wno-deprecated-declarations -g -O2 -fPIE
-fstack-protector-strong -Wformat -Werror=format-security -c -o
ConsoleApplication.o ../../../src/support/ConsoleApplication.cpp
In file included from
/usr/include/x86_64-linux-gnu/qt5/QtCore/qcoreapplication.h:37:0,
 from
/usr/include/x86_64-linux-gnu/qt5/QtCore/QCoreApplication:1,
 from
../../../src/support/../support/ConsoleApplicationPrivate.h:16,
 from ../../../src/support/ConsoleApplication.cpp:15:
/usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h:1087:4: error:
#error "You must build your code with position independent code if Qt
was built with -reduce-relocations. " "Compile your code with -fPIC
(-fPIE is not enough)."
 #  error "You must build your code with position independent code if
Qt was built with -reduce-relocations. "\
^


By default, -fPIC is used for shared libraries and -fPIE for
executables such as lyx. The latter takes precedence as it is later in
the argument list.
I can get away with the problem if I append -fPIC to CXXFLAGS but I
think this is not the proper solution, but a workaround.
A similar issue was reported also on Bug: #828878 and the fix was the
aforementioned workaround.


Kind regards,
Nick

--
=Do-
N.AND

Bug#820398: [Pkg-lyx-devel] Bug#820398: Lyx crashes with SIGILL on processors without cmov

[Nikos Andrikos]

Hi Johann,

Can this be related to the recent move from i386 to 686-class move for
debian?
https://lists.debian.org/debian-devel-announce/2016/05/msg1.html

I think cmov is now part of the required ISA.
What processor do you run Lyx on?

Kindest regards,
Nick

--
=Do-
N.AND

2016-04-07 22:50 GMT+02:00 Johann Klammer :

> Package: lyx
> Version: 2.1.4-2
>
> I got this while trying to build ngspice on my fileserver
> (it holds the debian installation here,
> and ngspice dropped from testing)
>
> [...]
> dh_testdir
> #cd build/manual && lyx --export ps manual.lyx.
> cd build/manual && lyx --export pdf2 manual.lyx.
> /home/klammerj/projects/dc_dc/ngspice-26/build/manual
> /bin/sh: line 1:  1742 Illegal instruction lyx --export pdf2 manual.lyx
> debian/rules:78: recipe for target 'build-indep' failed
> make: *** [build-indep] Error 132
> make: *** Waiting for unfinished jobs
> [...]
>
> trying to run the thing in gdb yields:
>
> [...]
> (gdb) bt
> #0  0xb7f386b9 in
> boost::object_cache boost::re_detail::cpp_regex_traits_implementation
> >::do_get(boost::re_detail::cpp_regex_traits_base const&, unsigned
> int) ()
>from /usr/lib/i386-linux-gnu/libboost_regex.so.1.58.0
> #1  0xb7f43b3b in boost::basic_regex boost::cpp_regex_traits > >::do_assign(char const*, char const*,
> unsigned int) ()
>from /usr/lib/i386-linux-gnu/libboost_regex.so.1.58.0
> [...]
> (gdb) disass 0xb7f386b9,+20
> Dump of assembler code from 0xb7f386b9 to 0xb7f386cd:
> => 0xb7f386b9
> <_ZN5boost12object_cacheINS_9re_detail21cpp_regex_traits_baseIcEENS1_31cpp_regex_traits_implementationIcEEE6do_getERKS3_j+1241>:
> cmove  -0x74(%ebp),%eax
>0xb7f386bd
> <_ZN5boost12object_cacheINS_9re_detail21cpp_regex_traits_baseIcEENS1_31cpp_regex_traits_implementationIcEEE6do_getERKS3_j+1245>:
> mov%eax,-0x74(%ebp)
> [...]
>
> ___
> Pkg-lyx-devel mailing list
> pkg-lyx-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-lyx-devel
>

Bug#733245: newsbeuter: multiline url autodetection broken

[Nikos Tsipinakis]

control: forwarded -1 https://github.com/akrennmair/newsbeuter/issues/282

Google Code is dead, issue has been migrated to GitHub.

-- 
Best Regards,
Nikos Tsipinakis

Bug#776728: newsbeuter: nasty memory leak in 2.8

[Nikos Tsipinakis]

On Thu, Mar 31, 2016 at 05:46:32PM +0100, Manuel A. Fernandez Montecelo wrote:
> Uhm, sorry for not being clear.  I know that the Debian maintainers
> were busy with other stuff.
> 
> What it was not clear to me was why this was present in both 2.8 *and*
> 2.9 upstream, e.g., if the original patch had been reverted because it
> caused other problems.

Oh, I am not really sure. I havent followed the 2.9 development that closely and
I really dont feel like digging into 2 years worth of commits to find out, its
fixed anyway so does it really matter?

-- 
Best Regards,
Nikos Tsipinakis

Bug#776728: newsbeuter: nasty memory leak in 2.8

[Nikos Tsipinakis]

On Thu, Mar 31, 2016 at 04:10:06PM +0100, Manuel A. Fernandez Montecelo wrote:
> Was it left out for some particular reason?
> 
> I have quite a lot of memory so this is not critical for me in any way
> (but thanks for taking care of this).  But I imagine that many of the
> users of newsbeuter can be annoyed by that, so I am curious why this
> memory problem has been going on for so long.

As mentioned above, many users are running newsbeuter in hosts with limited
memory and a 1/2GB memory footprint for a text based RSS reader is simply
ridiculous and since there are no other important bugs open I am releasing a
revision with the patch immediately(its also is a nice excuse to migrate the
package to debhelper :) )

As for why it has been going on for that long, the leak was first observed right
after the release of 2.8 for which a patch was released but was not added to
debian since the previous maintainer was busy, in 2.9 the issue re-appeared for
some reason(either its a new memory leak or a regression of the old one), a
patch was released right after that and unfortunately I didn't notice it before
uploading the new version.

-- 
Best Regards,
Nikos Tsipinakis

Bug#776728: newsbeuter: nasty memory leak in 2.8

[Nikos Tsipinakis]

Hello,

On Wed, Mar 30, 2016 at 10:12:35PM +0100, Manuel A. Fernandez Montecelo wrote:
> It seems that 2.9 still uses a lot of memory (at least in my
> use-case), 800MB right now after being restarted a few hours ago.
> 
> So re-opening this bug.

Apparently the patch for the memory leak didn't fully make it into 2.9, I'll 
upload a patched version later today.

-- 
Best Regards,
    Nikos Tsipinakis

Bug#816919: RFS: newsbeuter/2.9-1 [ITA]

[Nikos Tsipinakis]

On Sat, Mar 12, 2016 at 02:15:14AM +0100, gregor herrmann wrote:
> Thanks for all your work, that's really exciting, and I'm happy to
> sponsor this upload.

Yay \o/

> The order of the paragraphs is a bit unusual; normally the "Files"
> sections come before the "License" sections.

Fixed.

> Cool. - I just think that the newsbeuter-dbg transition package
> should depend on newsbeuter-dbgsym instead of newsbeuter. (Or you can
> just drop it; I see the point but so far I haven't seen any other
> transition packages for debugging symbols; but it's fine for me to
> keep it.)

I'm going to keep it for now, fixed the dependency.

> And in the future, modernizing d/rules would be nice.

I haven't messed around with automatic dh that much yet, I'll try to have that
in the next revision.

-- 
Best Regards,
Nikos Tsipinakis

Bug#816919: RFS: newsbeuter/2.9-1 [ITA]

[Nikos Tsipinakis]

On Fri, Mar 11, 2016 at 12:49:38AM +0100, gregor herrmann wrote:
> Will take a closer look tomorrow; a first look shows that the package
> might profit from some modernization (d/copyright in Copyright Format
> 1.0;

Done.

> dh(1) in debian/rules; migration to new dbgsym packages (cf.
> dh_strip(1)'s --dbgsym-migration)), etc.).

Done.

> lintian and blhc report:
> 
> P: newsbeuter source: no-dep5-copyright

Done.

> I: newsbeuter: spelling-error-in-binary usr/bin/newsbeuter occured occurred

Sneaked this one in the translation-fix patch.

> I: newsbeuter: hardening-no-fortify-functions usr/bin/newsbeuter
> I: newsbeuter: hardening-no-fortify-functions usr/bin/podbeuter

Fixed.

> W-dpkg-buildflags-missing|CPPFLAGS 59 (of 59) missing|

Fixed.


-- 
Best Regards,
Nikos Tsipinakis

Bug#816919: RFS: newsbeuter/2.9-1 [ITA]

[Nikos Tsipinakis]

On Wed, Mar 09, 2016 at 11:25:01PM +0100, gregor herrmann wrote:
> Thanks for your interest in newsbeuter; I like it and use it daily :)
> And I was looking forward to a version which needs less memory than
> Iceweasel; but for me 2.9 has a massive problem:
> 
> The highlighting feature seems to be broken (no idea if this is a
> problem in newsbeuter or ncurses; I haven't retried to rebuild 2.8-2
> to check). Too show what I mean: I have in my ~/.newsbeuter/config

Apparently this issue was already reported and fixed upstream. Added a patch 
and it should work as intended now.

-- 
Best Regards,
Nikos Tsipinakis

Bug#816919: RFS: newsbeuter/2.9-1 [ITA]

[Nikos Tsipinakis]

On Tue, 8 Mar 2016 17:53:01 +0100 Jakub Wilk <jw...@debian.org> wrote:
> You can (and should) forward the bugs upstream.
> You can mark the incorrectly translated messages as "fuzzy", so that 
> the translations won't be used.

I forwarded the issue upstream, and patched the erroneous translations.

To summarize the last few mails the current changelog is:

  * New upstream release. (Closes: #776728)
  * Fix segfault when downloading podcasts
  * Patch erroneous Portuguese, Ukrainian and Chinese translations.
  * Bumped standards to 3.9.7
  * Updated watch file.
  * Removed upstream README from docs.
  * New maintainer. (Closes: #800752)

-- 
Best Regards,
Nikos Tsipinakis

Bug#816919: RFS: newsbeuter/2.9-1 [ITA]

[Nikos Tsipinakis]

Hello Jakub,

On Tue, 8 Mar 2016 14:53:58 +0100 Jakub Wilk <jw...@debian.org> wrote:
> Speaking of PO files, i18nspector finds some interesting bugs in them:
> 
> E: po/uk.po: c-format-string-missing-arguments msgid "`%s' is not a valid 
> regular expression: %s": 1 (msgstr) < 2 (msgid)
> E: po/zh.po: c-format-string-argument-type-mismatch msgid "Error while 
> processing command `%s' (%s line %u): %s": int * (msgstr) != unsigned int 
> (msgid)
> E: po/zh.po: c-format-string-missing-arguments msgid "Error: couldn't mark 
> feed read: %s": 0 (msgstr) < 1 (msgid)
> 
> (plus some other, less severe problems)

Unfortunately most of these errors are left for the translators to fix as they 
are
related to the translated message format, nothing I can do since I do not know
any of the languages.

Best Regards,
Nikos Tsipinakis

Bug#816919: RFS: newsbeuter/2.9-1 [ITA]

[Nikos Tsipinakis]

Hello Dmitry,

On Tue, Mar 08, 2016 at 12:01:28PM +0300, Dmitry Bogatov wrote:
> [NO DD, can't sponsor]

Input is always appreciated :)

> There is nice tool `check-all-the-things'. It reveals
> 
>  * loads of spelling errors in po/

The 'spelling errors' are mostly ispell trying to correct non-english
translations i.e.

"./newsbeuter-2.9/po/es.po:438: Autor  ==> Author"

es.po:436-8
#: src/controller.cpp:1355 src/itemview_formaction.cpp:90
msgid "Author: "
msgstr "Autor: "

Thats clearly a translation that ispell is trying to parse as english. There
are a few minor spelling mistakes in english but very few if any are in
user-viewable files(docs) in my opinion not worth making a patch for them, they
can easily be patched upstream and pulled down at the next release.

>  * wrong formatting of your email (email is formatted this way: Name 
> <em...@bar.com>,
>your formatting in patches/podbeuter-segfault-fix misses <> symbols)

Author: Nikos Tsipinakis <ni...@tsipinakis.com>

Formatting seems correct to me as it is?

>  * installation instruction (README) should not find way into binary package

Agreed, README has been removed from the docs, package re-uploaded.

Best Regards,
Nikos Tsipinakis

Bug#813598: [gnutls-devel] FTBFS[kfreebsd]: tests/mini-loss-time race

[Nikos Mavrogiannopoulos]

On Sat, Mar 5, 2016 at 7:57 PM, Steven Chamberlain <ste...@pyro.eu.org> wrote:
> Hi Andreas,
>
> In a future upload please could you try the attached diff, which is a
> much simpler way I found to get the testsuite output into the build log.
> Since more than one set of tests runs in parallel, we only currently see
> the test-suite.log for one set of tests, and not all of them.
>
>> On Sat, 2016-03-05 at 17:30 +0100, Andreas Metzler wrote:
>> > Well with 3.4.10 the timeout does not seem to make any difference.
>> > Any of
>> > gnutls_dtls_set_timeouts(session, 1 * 1000, 29 * 1000); [Steven's
>> > patch]
>
> Your commit to the gnutls28 package in experimental
> https://anonscm.debian.org/cgit/pkg-gnutls/gnutls.git/commit/?h=experimental=896b247a321271ab61ed1fce5065cadbd472c207
> seems to do the opposite of my patch, it increases the server timeout?
> My patch decreased it:  https://bugs.debian.org/813598#5
>
>> > gnutls_dtls_set_timeouts(session, 1 * 1000, 30 * 1000); [3.4.10]
>> > gnutls_dtls_set_timeouts(session, 1 * 1000, 29 * 1000); 
>> > [e6dcb14dbbd3e9e40a1f193a7bf6657e82b88cb9]
>> > *always* fails on kfreebsd-amd64.
>
> If it fails _reliably_ now, I consider that an improvement!
> I'll try to test all of the above and see how often each one fails.

That's quite interesting. It seems that the child times out first and
closes the connection prior to parent detecting the timeout. Would the
attached patch solve the issue?

regards,
Nikos
diff --git a/tests/mini-loss-time.c b/tests/mini-loss-time.c
index 13de21e..8145657 100644
--- a/tests/mini-loss-time.c
+++ b/tests/mini-loss-time.c
@@ -116,7 +116,7 @@ push(gnutls_transport_ptr_t tr, const void *data, size_t 
len)
return send(fd, data, len, 0);
 }
 
-static void client(int fd)
+static void client(int fd, unsigned timeout)
 {
int ret;
gnutls_anon_client_credentials_t anoncred;
@@ -136,7 +136,7 @@ static void client(int fd)
 */
gnutls_init(, GNUTLS_CLIENT | GNUTLS_DATAGRAM);
gnutls_dtls_set_mtu(session, 1500);
-   gnutls_dtls_set_timeouts(session, 1 * 1000, 30 * 1000);
+   gnutls_dtls_set_timeouts(session, 1 * 1000, timeout * 1000);
 
/* Use default priorities */
gnutls_priority_set_direct(session,
@@ -178,7 +178,7 @@ static void client(int fd)
 /* These are global */
 pid_t child;
 
-static void server(int fd, int packet)
+static void server(int fd, int packet, unsigned timeout)
 {
gnutls_anon_server_credentials_t anoncred;
gnutls_session_t session;
@@ -196,7 +196,7 @@ static void server(int fd, int packet)
 
gnutls_init(, GNUTLS_SERVER | GNUTLS_DATAGRAM);
gnutls_dtls_set_mtu(session, 1500);
-   gnutls_dtls_set_timeouts(session, 1 * 1000, 30 * 1000);
+   gnutls_dtls_set_timeouts(session, 1 * 1000, timeout * 1000);
 
/* avoid calling all the priority functions, since the defaults
 * are adequate.
@@ -265,17 +265,17 @@ static void start(int server_packet, int wait_server)
/* parent */
close(fd[0]);
if (wait_server)
-   server(fd[1], server_packet);
+   server(fd[1], server_packet, 30);
else
-   client(fd[1]);
+   client(fd[1], 30);
close(fd[1]);
kill(child, SIGTERM);
} else {
close(fd[1]);
if (wait_server)
-   client(fd[0]);
+   client(fd[0], 32);
else
-   server(fd[0], server_packet);
+   server(fd[0], server_packet, 32);
close(fd[0]);
exit(0);
}

Bug#816919: RFS: newsbeuter/2.9-1 [ITA]

[Nikos Tsipinakis]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: newsbeuter
  Version : 2.9-1
  Upstream Author : Andreas Krennmair <a...@newsbeuter.org>
* URL : https://github.com/akrennmair/newsbeuter
* License : MIT
  Section : net

It builds those binary packages:

   newsbeuter - text mode rss feed reader with podcast support
   newsbeuter-dbg - debugging symbols for newsbeuter

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

  http://mentors.debian.net/package/newsbeuter


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

   dget -x 
http://mentors.debian.net/debian/pool/main/n/newsbeuter/newsbeuter_2.9-1.dsc

Changes since the last upload:

  * New upstream release. (Closes: #776728)
  * Fix sefault when downloading podcasts.
  * Bumped standards to 3.9.7
  * Updated watch file.
  * New maintainer.

Best Regards,
 Nikos Tsipinakis

Bug#800752: RFA: newsbeuter -- text mode rss feed reader with podcast support

[Nikos Tsipinakis]

retitle 800752 ITA: newsbeuter -- text mode rss feed reader with podcast support
owner 800752 !
thanks

I have been using newsbeuter on and off for about a year and I'm interested in 
adopting it.

Regards,
Nikos Tsipinakis

Bug#813598: [gnutls-devel] FTBFS[kfreebsd]: tests/mini-loss-time race

[Nikos Mavrogiannopoulos]

On Sat, 2016-03-05 at 17:30 +0100, Andreas Metzler wrote:
> Control: reopen 813598
> 
> On 2016-02-15 Nikos Mavrogiannopoulos <n...@gnutls.org> wrote:
> > On Sun, Feb 14, 2016 at 3:14 PM, Andreas Metzler <ametz...@bebt.de> 
> > wrote:
> > > this is http://bugs.debian.org/813598 reported by Steven 
> > > Chamberlain:
> 
> > > gnutls28 tests/mini-loss-time fails about 20% of the time when I 
> > > try it
> > > on kfreebsd-amd64.  I think probably introduced by this commit:
> > > https://gitlab.com/gnutls/gnutls/commit/e2a3ad31c487cbce997a08ddd
> > > c55db639b60c024
> 
> > I've applied a similar fix in master.
> 
> Well with 3.4.10 the timeout does not seem to make any difference. 
> Any of
> 
> gnutls_dtls_set_timeouts(session, 1 * 1000, 29 * 1000); [Steven's 
> patch]
> gnutls_dtls_set_timeouts(session, 1 * 1000, 30 * 1000); [3.4.10]
> gnutls_dtls_set_timeouts(session, 1 * 1000, 29 * 1000);
>  
>  [e6dcb14dbbd3e9e40a1f193a7bf6657e82b88cb9]
> *always* fails on kfreebsd-amd64.

Then the issue may have been different that what was initially thought.
It would be nice to have some debugging output of the failed test
(e.g., run with -v). Is that a 32-bit system? I'm wondering whether it
relates to the undefined behavior fixes.

regards,
Nikos

Bug#815843: ocserv: Segfault when loading ocserv

[Nikos Mavrogiannopoulos]

On Thu, Feb 25, 2016 at 1:52 AM, Tony Zhou <tonytz...@gmail.com> wrote:
> Package: ocserv
> Version: 0.10.11-2
> Severity: important
>
> Dear Maintainer,
> I have just upgraded my ocserv from 0.10.11-1 to 0.10.11-2 in order to
> gain RADIUS support. However, when I try to start ocserv it throws a
> segfault and exits, either by systemd or manually executing ocserv. When
> ocserv loads as a service, the journal has the following output:
>
> Feb 25 09:44:48 vpn ocserv[1065]: listening on 2 systemd sockets...
> Feb 25 09:44:48 vpn ocserv[1065]: main: initialized ocserv 0.10.11
> Feb 25 09:44:48 vpn ocserv[1066]: sec-mod: reading supplemental config from 
> files
> Feb 25 09:44:48 vpn ocserv[1066]: sec-mod: sec-mod initialized (socket: 
> /var/run/ocserv-socket.1065)
> Feb 25 09:44:48 vpn systemd[1]: ocserv.service: Main process exited, 
> code=killed, status=6/ABRT
> Feb 25 09:44:48 vpn ocserv[1065]: *** Error in `ocserv-main': free(): invalid 
> pointer: 0xb78e9228 ***

Most likely it is that issue fixed in ocserv 0.10.12 (the underlying
issue is in gnutls):
https://gitlab.com/ocserv/ocserv/commit/874c65f47e83fabd2e21b40bc0953f6f606f006a

regards,
Nikos

Bug#813690: ocserv: missing RADIUS support

[Nikos Mavrogiannopoulos]

Freeradius client 1.1.6 is not supported by ocserv. You'll need  at least  
version 1.1.7.



On 5 February 2016 22:11:07 CET, Aron Xu  wrote:
>radcli in Debian does not have pkgconfig file included, I've filed a
>bug (#813842), and added a patch to ocserv to make freeradius client
>library get detected.
>
>Regards,
>Aron

-- 
Sent fron my mobile. Please excuse my brevity.

Bug#813690: ocserv: missing RADIUS support

[Nikos Mavrogiannopoulos]

Note that libradcli can also be used. It is available in debian testing.

On Thu, Feb 4, 2016 at 12:55 PM, Mantas Mikulėnas  wrote:
> Package: ocserv
> Version: 0.10.10-1
> Severity: wishlist
>
> Dear Maintainer,
>
> Could you include RADIUS authentication support in ocserv?
>
> (This would need libfreeradius-client2 v1.1.7.)
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (900, 'testing'), (500, 'testing-updates'), (500, 
> 'stable-updates'), (500, 'unstable'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.1.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages ocserv depends on:
> ii  dbus   1.10.6-1
> ii  libc6  2.21-7
> ii  libgnutls-deb0-28  3.3.20-1
> ii  libhttp-parser2.1  2.1-2
> ii  liblz4-1   0.0~r131-1
> ii  libnl-3-2003.2.26-1
> ii  libnl-route-3-200  3.2.26-1
> ii  libopts25  1:5.18.7-3
> ii  libpam0g   1.1.8-3.2
> ii  libpcl11.6-1
> ii  libprotobuf-c1 1.1.1-1
> ii  libreadline6   6.3-8+b4
> ii  libseccomp22.2.3-2
> ii  libsystemd0228-4+b1
> ii  libtalloc2 2.1.5-1
> ii  libwrap0   7.6.q-25
>
> Versions of packages ocserv recommends:
> ii  ca-certificates  20160104
> ii  ssl-cert 1.0.37
>
> ocserv suggests no packages.
>
> -- no debconf information
>

Bug#809847: ipcalc doesn't support IPv6

[Nikos Mavrogiannopoulos]

Package: ipcalc
Version: 0.41-4
Severity: normal
Tags: ipv6

Dear Maintainer,
 The ipcalc tool included in Debian works fine for IPv4 addresses but has no
support whatsoever for IPv6 addresses. The output of:
$ ipcalc ::1
INVALID ADDRESS: ::1

Address:   192.168.1.1  1100.10101000.0001. 0001
Netmask:   255.255.255.0 = 24   ... 
Wildcard:  0.0.0.255... 
=>
Network:   192.168.1.0/24   1100.10101000.0001. 
HostMin:   192.168.1.1  1100.10101000.0001. 0001
HostMax:   192.168.1.2541100.10101000.0001. 1110
Broadcast: 192.168.1.2551100.10101000.0001. 
Hosts/Net: 254

Which doesn't correspond to reality.

This was also the case with Fedora's ipcalc tool [0] and we updated it to [1]
which does support IPv6 and has output which resembles Debian's ipcalc.

[0]. https://bugzilla.redhat.com/show_bug.cgi?id=1220391
[1]. https://github.com/nmav/ipcalc





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

Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=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 ipcalc depends on:
ii  perl  5.20.2-6

ipcalc recommends no packages.

ipcalc suggests no packages.

-- no debconf information

Bug#733295: gnutls-bin: please compile GnuTLS with DANE support

[Nikos Mavrogiannopoulos]

On Tue, 2015-11-17 at 14:40 +0100, Luca Bruno wrote:

> > I really don't know. You can pretend somebody jumped on me asking
> > whether I was part of Debian and mentioned this issue that has been
> > tagged wontfix. That wouldn't be very far from what happened. ;)
> > 
> > I can add nettlifying unbound to my ever growing to-do list, and 
> > see
> > what codepaths are involved there. Maybe someone even did that work
> > upstream already, I didn't check yet.
> 
> I went ahead and coded the "nettlify libunbound" part, which is 
> basically
> option 3 proposed above.
> I run this through upstream and they merged it today:
> https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=594
> 
> This changes only touch libunbound (and the testcases) to build with 
> nettle,
> while the rest of unbound still needs openssl or NSS (mostly for 
> TLS).

Luca, thank you for pursuing that.

regards,
Nikos

Bug#787866: autogen: after upgrade to 5.18.5 autogen no longer works

[Nikos Mavrogiannopoulos]

On Sun, 2015-06-28 at 17:18 -0700, Bruce Korb wrote:
 On 06/28/15 04:26, Nikos Mavrogiannopoulos wrote:
  http://autogen.sourceforge.net/data/autogen-5.18.5pre20.tar.xz
 
  That version works for me.
 
 OK, then, I've now unwound all the Guile wrapper macro removals from top of 
 tree.
 
 http://autogen.sourceforge.net/data/autogen-5.18.6pre3.tar.xz
 
 If that one works for you, then I'll promote it next weekend.
 Thank you both for your help!

I'm not able to compile this version. The error message follows.

make[2]: Entering directory '/tmp/autogen-5.18.6pre3/xml2ag'
top_srcdir=.. top_builddir=.. PATH=`cd ../columns;pwd`:$PATH
CLexe=../columns/columns ../agen5/autogen -MF.deps/stamp-opts.d
-MTstamp-opts -MP -L../autoopts/tpl -L../autoopts/tpl
--definition=./xmlopts.def
Error in template ../autoopts/tpl/optlib.tlib, line 780
DEFINITIONS ERROR in ../autoopts/tpl/optlib.tlib line 780 for
xmlopts.h:
Error:  value for opt output is `O'
must be single char or 'NUMBER'
Failing Guile command:  = = = = =

(error (sprintf
Error:  value for opt %s is `%s'\nmust be single char or 'NUMBER'
(get name) (get value)))

=
Makefile:903: recipe for target 'stamp-opts' failed


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

Bug#787866: autogen: after upgrade to 5.18.5 autogen no longer works

[Nikos Mavrogiannopoulos]

On Sat, 2015-06-27 at 12:05 -0700, Bruce Korb wrote:
 On 06/06/15 10:10, Andreas Metzler wrote:
 
  FWIW, it also works for me on sid (both amd64 and i386).
 
 FWIW, it appears to be related to the disablement of Guile 1.6.
 I may have to unwind that until I can figure out how Guile 1.6
 support causes regex execution problems
 
 Meanwhile, I've uploaded a pre20 which contains everything
 between pre7 (which worked) and pre21 (which did not) *except*
 the Guile changes.  Presuming that that works, I can focus my
 attention on the Guile interface stuff.
 http://autogen.sourceforge.net/data/autogen-5.18.5pre20.tar.xz

That version works for me.

regards,
Nikos


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

Bug#787866: autogen: after upgrade to 5.18.5 autogen no longer works

[Nikos Mavrogiannopoulos]

On Sat, 2015-06-06 at 16:18 -0700, Bruce Korb wrote:

 In that log, I find:
 
  Compiling '[ -~]' with bits 0x1 === compiled as extended RE
  CASE no match: `c' MATCH_FULL vs. `[ -~]'
 I think there is a RE library problem.  The code is as follows:
  /*
   *  On the first call for this macro, compile the expression
   */
  if (cur_macro-md_pvt == NULL) {
  void *mat = VOIDP(pattern);
  regex_t * re  = AGALOC(sizeof(*re), select match full re);
 
  if (OPT_VALUE_TRACE  TRACE_EXPRESSIONS) {
  fprintf(trace_fp, TRACE_SEL_MATCH_FULL,
   pattern, cur_macro-md_res);
 This function returns FAILURE, and that is incorrect.
 This code has not changed in many years (16).
 Last January, I changed the casting of 'pattern' to coerce it into a void *
 without any const attributes, but functionally no changes for 16 years.
 The following program should replicate the same test that fails in AutoGen.
 If this succeeds, then the question is, what is different in the execution 
 env?
 If this fails, on the other hand, then you need to look to the regcomp 
 library.

I've compiled and run the attached version of that program and it
succeeds (no valgrind warnings either). 

The differences in the environment during build are the following three
variables.
+MAKEFLAGS=
+MAKELEVEL=1
+MFLAGS=

#include stdio.h
#include stdlib.h
#include string.h
#include sys/types.h
#include regex.h

#define VOIDP(_p)  ((void *)(unsigned long)(_p))

static void
compile_re(regex_t * re, char const * pat, int flags)
{
 int rerr = regcomp(re, VOIDP(pat), flags);
 if (rerr != 0) {
 char erbf[ 1024 ];
 regerror(rerr, re, erbf, sizeof(erbf));
 fprintf(stderr, error\n);
 abort();
 }
}

static int
check_full_match(char const * sample, char const * pattern)
{
 regmatch_t m[2];
 regex_t * md_pvt;

 /*
  *  On the first call for this macro, compile the expression
  */
 void *mat = VOIDP(pattern);
 regex_t * re  = malloc(sizeof(*re));

 compile_re(re, mat, 1);
 md_pvt = re;

 // In this function, the RE must match the entire string.
 //
 if (regexec(re, sample, (size_t)2, m, 0)
 != 0)
 return 0;

 if (  (m[0].rm_eo != (int)strlen( sample ))
|| (m[0].rm_so != 0))
 return 0;
 return 1;
}

int main(int argc, char ** argv) {
 if (! check_full_match(c, [ -~]))
 printf(FAILED\n);
 return 0;
}

Bug#787866: autogen: after upgrade to 5.18.5 autogen no longer works

[Nikos Mavrogiannopoulos]

On Sun, 2015-06-07 at 14:09 -0700, Bruce Korb wrote:
 Nikos, I am stumped here.  Oh, wait -- what version of Guile?
 2.0.[0123] are broken.  I've stopped choking on newer versions of 2.0.x that 
 I've not
 seen, but history says that problems do sneak in in micro releases.
 (Way back whenever, I personally verified each micro release before
 I enabled it for AutoGen.)
 So, what version, please?  Probably *not* an issue, but just to know

It is 2.0.11+1-9.

  time passes ==
 I finished reviewing every patch between v4-18-4 and v4.18.5 (I should learn 
 to
 be consistent).  There are a few changes in the agen5 code, but every one
 I looked at looked innocuous to me.  Changing a copyright date or being more
 scrupulous about stripping qualifiers from pointers.  But I also pulled 
 support
 for Guile 1.6.  It's long enough in the tooth.  That simplified a lot of the
 Guile function wrappers.  If there were a way for me to bisect the code and
 pin down the issue, I'd do that.  There were 22 patches, but many are simply
 version bumps or strictly commentary.  It would probably take 4 tries in any
 case to find the failing patch.  If it works for you, contact me directly and
 I'll send my public key.  Thanks!

I tried to bisect myself but for some reason I'm not able to compile
autogen from git. If you send me a public key I'll open you an account.

regards,
Nikos


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

Bug#787866: autogen: after upgrade to 5.18.5 autogen no longer works

[Nikos Mavrogiannopoulos]

On Fri, 2015-06-05 at 18:19 -0700, Bruce Korb wrote:
 export AUTOGEN_TRACE=everything AUTOGEN_TRACE_OUT='/tmp/ag-log.txt'

Log is attached.



===AutoGen starts - 13485:  autogen 'ocpasswd-args.def'
Guile Library Version 2.0.11
eval from file agInit.c line 80:
(debug-enable 'backtrace)
Definition Load:
prog_name[0] (text) from ocpasswd-args.def/2 at 0xba2b60
prog_title[0] (text) from ocpasswd-args.def/3 at 0xba1be8
prog_desc[0] (text) from ocpasswd-args.def/4 at 0xba1c30
disable_save[0] (text) from ocpasswd-args.def/5 at 0xba1c78
no_xlate[0] (text) from ocpasswd-args.def/6 at 0xba1cc0
gnu_usage[0] (text) from ocpasswd-args.def/7 at 0xba1d08
config_header[0] (text) from ocpasswd-args.def/8 at 0xba1d50
long_opts[0] (text) from ocpasswd-args.def/9 at 0xba1d98
no_misuse_usage[0] (text) from ocpasswd-args.def/10 at 0xba1de0
short_usage[0] (text) from ocpasswd-args.def/11 at 0xba1e28
explain[0] (text) from ocpasswd-args.def/12 at 0xba1e70
reorder_args[0] (text) from ocpasswd-args.def/13 at 0xba1eb8
argument[0] (text) from ocpasswd-args.def/14 at 0xba1f00
version[0] (text) from version.inc/1 at 0xba1f48
detail[0] (text) from ocpasswd-args.def/17 at 0xba1f90
copyright[0] (block) from ocpasswd-args.def/20 at 0xba1fd8
  date[0] (text) from ocpasswd-args.def/21 at 0xba2020
  owner[0] (text) from ocpasswd-args.def/22 at 0xba2068
  author[0] (text) from ocpasswd-args.def/23 at 0xba20b0
  eaddr[0] (text) from ocpasswd-args.def/24 at 0xba20f8
  type[0] (text) from ocpasswd-args.def/25 at 0xba2140
flag[0] (block) from ocpasswd-args.def/28 at 0xba2188
  name[0] (text) from ocpasswd-args.def/29 at 0xba21d0
  value[0] (text) from ocpasswd-args.def/30 at 0xba2218
  arg_type[0] (text) from ocpasswd-args.def/31 at 0xba2260
  descrip[0] (text) from ocpasswd-args.def/32 at 0xba22a8
  doc[0] (text) from ocpasswd-args.def/33 at 0xba22f0
flag[1] (block) from ocpasswd-args.def/36 at 0xba2338
  name[0] (text) from ocpasswd-args.def/37 at 0xba2380
  value[0] (text) from ocpasswd-args.def/38 at 0xba23c8
  arg_type[0] (text) from ocpasswd-args.def/39 at 0xba2410
  descrip[0] (text) from ocpasswd-args.def/40 at 0xba2458
  doc[0] (text) from ocpasswd-args.def/41 at 0xba24a0
flag[2] (block) from ocpasswd-args.def/44 at 0xba24e8
  name[0] (text) from ocpasswd-args.def/45 at 0xba2530
  value[0] (text) from ocpasswd-args.def/46 at 0xba2578
  descrip[0] (text) from ocpasswd-args.def/47 at 0xba25c0
  doc[0] (text) from ocpasswd-args.def/48 at 0xba2608
flag[3] (block) from ocpasswd-args.def/51 at 0xba2650
  name[0] (text) from ocpasswd-args.def/52 at 0xba2698
  value[0] (text) from ocpasswd-args.def/53 at 0xba26e0
  descrip[0] (text) from ocpasswd-args.def/54 at 0xba2728
  doc[0] (text) from ocpasswd-args.def/55 at 0xba2770
flag[4] (block) from ocpasswd-args.def/58 at 0xba27b8
  name[0] (text) from ocpasswd-args.def/59 at 0xba2800
  value[0] (text) from ocpasswd-args.def/60 at 0xba2848
  descrip[0] (text) from ocpasswd-args.def/61 at 0xba2890
  doc[0] (text) from ocpasswd-args.def/62 at 0xba28d8
help_value[0] (text) from ocpasswd-args.def/65 at 0xba2920
doc_section[0] (block) from ocpasswd-args.def/68 at 0xba2968
  ds_type[0] (text) from ocpasswd-args.def/69 at 0xba29b0
  ds_format[0] (text) from ocpasswd-args.def/70 at 0xba29f8
  ds_text[0] (text) from ocpasswd-args.def/71 at 0xba2a40
doc_section[1] (block) from ocpasswd-args.def/84 at 0xba2a88
  ds_type[0] (text) from ocpasswd-args.def/85 at 0xba2ad0
  ds_format[0] (text) from ocpasswd-args.def/86 at 0xba2b18
  ds_text[0] (text) from ocpasswd-args.def/87 at 0xba3ee0
doc_section[2] (block) from ocpasswd-args.def/105 at 0xba2f68
  ds_type[0] (text) from ocpasswd-args.def/106 at 0xba2fb0
  ds_format[0] (text) from ocpasswd-args.def/107 at 0xba2ff8
  ds_text[0] (text) from ocpasswd-args.def/108 at 0xba3040
marker '[=' loaded
marker '=][=' loaded
Starting h template
open_output_file 'ocpasswd-args.h' mode wb+
EXPR   ( E) in /usr/share/autogen/options.tpl at line 32
  ed 's@/autogen@/columns@'`
eval from file /usr/share/autogen/options.tpl line 32:
(shell CLexe=`echo ${AGexe} | sed 's@/autogen@/columns@'`
   test -x \${CLexe}\ || CLexe=`which columns`)


 (dne  *   /*  )
Server shell is pid 13486
S
Server First Start
erver shell /bin/bash
 
s*t a*r t*s 
* LOG ENTRY 1 * * * *
cd /home/nmav/cvs/ocserv/src
exec 82 2/dev/null

if test -n ${ZSH_VERSION+set}  (emulate sh) 12
then
  emulate sh
  NULLCMD=:

else case `set -o` in *posix*) set -o posix ;; esac
fi

trap_exit() {
case $1 in
0 | 10 | 15 )
exec 1- 2-
test -d ${tmp_dir}  rm -rf ${tmp_dir}
;;

* )
exec 18
echo trapped on signal ${1}
test -d ${tmp_dir}  \
echo temp directory has been retained:  ${tmp_dir}
esac
}

die() {
  echo Killing AutoGen ${AG_pid}
  echo FAILURE REASON:  $*
  kill -15 ${AG_pid}
  sleep 1
  kill -1  ${AG_pid}
  sleep 1
  kill -2  ${AG_pid}
  sleep 1
  kill -9  ${AG_pid}
  exit 1
} 8

mk_tmp_dir() {
  test -d ${tmp_dir}  return 0
  tmp_dir=`

Bug#787866: autogen: after upgrade to 5.18.5 autogen no longer works

[Nikos Mavrogiannopoulos]

Package: autogen
Version: 1:5.18.5-2
Severity: grave
Tags: upstream
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?
Trying to run autogen on my def files fails consistently after upgrading
5.18.5. Downgrading to the .4 version works again.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
$ autogen ocpasswd-args.def

(the file is attached)


   * What was the outcome of this action?
Error in template /usr/share/autogen/optlib.tlib, line 780
DEFINITIONS ERROR in /usr/share/autogen/optlib.tlib line 780 for
ocpasswd-args.h:
Error:  value for opt passwd is `c'
must be single char or 'NUMBER'
Failing Guile command:  = = = = =

(error (sprintf
Error:  value for opt %s is `%s'\nmust be single char or 'NUMBER'
(get name) (get value)))

=

   * What outcome did you expect instead?


no output. The .c and .h files should have been generated.




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

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

Versions of packages autogen depends on:
ii  guile-2.0-libs  2.0.11+1-9
ii  libc6   2.19-18
ii  libopts25   1:5.18.5-2
ii  libopts25-dev   1:5.18.5-2
ii  libxml2 2.9.2+dfsg1-3

Versions of packages autogen recommends:
ii  autogen-doc  1:5.18.5-2

autogen suggests no packages.
AutoGen Definitions options;
prog-name = ocpasswd;
prog-title= OpenConnect server password utility;
prog-desc = OpenConnect VPN server plain password file handling program.;
disable-save;
no-xlate = opt;
gnu-usage;
config-header = config.h;
long-opts;
no-misuse-usage;
short-usage   = Usage: ocpasswd -c [passwd] [options] username\nocpasswd 
--help for usage instructions.\n;
explain   = ;
reorder-args;
argument  = [username];

detail  = This program is openconnect password (ocpasswd) utility. It allows 
the generation
and handling of a 'plain' password file used by ocserv.;

copyright = {
date  = 2013, 2014;
owner = Nikos Mavrogiannopoulos;
author = Nikos Mavrogiannopoulos;
eaddr  = openconnect-de...@lists.infradead.org;
type  = gplv2;
};

flag = {
name  = passwd;
value = c;
arg-type  = file;
descrip   = Password file;
doc   = ;
};

flag = {
name  = groupname;
value = g;
arg-type  = string;
descrip   = User's group name;
doc   = ;
};

flag = {
name  = delete;
value = d;
descrip   = Delete user;
doc   = Removes the specified user from the password file;
};

flag = {
name  = lock;
value = l;
descrip   = Lock user;
doc   = Prevents the specified user from logging in;
};

flag = {
name  = unlock;
value = u;
descrip   = Unlock user;
doc   = Re-enables login for the specified user;
};

help-value= h;


doc-section = {
  ds-type = 'FILES';
  ds-format = 'texi';
  ds-text   = -_EOT_
@subheading Password file format
The password format of ocpasswd is as follows.

@example
username:groupname:encoded-password
@end example

The crypt(3) encoding is used for the encoded-password.

_EOT_;
};

doc-section = {
  ds-type = 'EXAMPLES';
  ds-format = 'texi';
  ds-text   = -_EOT_
@subheading Adding a user
@example
$ ocpasswd -c ocpasswd my_username
@end example

@subheading Locking a user
@example
$ ocpasswd -c ocpasswd -l my_username
@end example

@subheading Unlocking a user
@example
$ ocpasswd -c ocpasswd -u my_username
@end example
_EOT_;
};

doc-section = {
  ds-type   = 'SEE ALSO';
  ds-format = 'man';
  ds-text   = -_EOText_
ocserv(8), occtl(8)
_EOText_;
};

Bug#733295: gnutls-bin: please compile GnuTLS with DANE support

[Nikos Mavrogiannopoulos]

On Tue, 2015-03-24 at 18:52 -0400, Robert Edmonds wrote:

  4. Design and implement a D-Bus interface for securely retrieving
 DNSSEC-validated records that have been validated *on the system*.
 Patch daemons (Unbound, BIND, et al) to answer to this interface.
 Patch clients (libdane, et al) to request records using this
 interface.
 
 This is sort of analogous to the security you would get in having a
 plain validating DNS server listening on localhost and a nameserver
 127.0.0.1 line (and no others) in /etc/resolv.conf and requiring the
 AD bit in responses, but the big advantage would be that the security
 guarantee from doing DNSSEC validation directly on the endpoint is
 guaranteed by the definition of the interface, and not from the
 happenstance of local configuration.
 This would:
 
  * Avoid licensing issues.
  
  * Avoid extra TLS/crypto related library dependencies in clients.
 
  * Allow other validators that are not written in the form of a library
(e.g., BIND, PowerDNS) to be used with clients that need
DNSSEC-secured answers.  And for validators that do have a library
API, do you really want to have each client have its own #ifdef mess
to support multiple APIs?
 
  * Allow system-wide, not just process-wide caching.  (Even if your
direct-libunbound client is pointed at a resolver on 127.0.0.1 that
has the answers in cache, it still may need to do many send/recv
system calls to obtain each needed record, because DNS can only
return one answer at a time per query/response.)
 
  * Insulate the client from needing to know how to configure the
DNSSEC-lookup library.  (E.g., remote DNS servers, trust anchors,
etc.)

Hi,
 The D-BUS interface is not really necessary because DNS provides
already this functionality. What we need is a convention for
applications in the system to discover the local trusted (for dnssec)
nameservers. 

My attempt to use c-ares for dnssec resolving would have the same effect
as the ones you mention and is much cleaner and straightforward than
D-BUS. However, it is blocked by the fact that there is no commonly
acceptable convention for reading the trusted nameservers. My current
solution was to use /etc/resolv-sec.conf, but it is pretty much
arbitrary and that's why c-ares upstream blocked it. If Debian would set
such a convention, I think it would allow software use DNSSEC easier.

https://github.com/bagder/c-ares/pulls

regards,
Nikos


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