Bug#1056654: ITP: obs-pipewire-audio-capture -- Audio device and application capture for OBS Studio using PipeWire

[Rhonda D'Vine]

Package: wnpp
Severity: wishlist
Owner: Rhonda D'Vine 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: obs-pipewire-audio-capture
  Version : 1.1.2
  Upstream Contact: Dimitris Papaioannou 
* URL : https://github.com/dimtpap/obs-pipewire-audio-capture
* License : GPL2+
  Programming Lang: C
  Description : Audio device and application capture for OBS Studio using 
PipeWire

The package adds capture possibilities to OBS to be able to separate desktop
audio into different channels to be able to mute them or put them into a
different recording/streaming track.

There seems to be plans to integrate it into mainline obs-studio in the future -
but it's useful already on its own for the time being.

 Cheers,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#1051948: irssi: no indication that you're scrolled up

[Rhonda D'Vine]

Severity -1 wishlist

  Hi,

* Adam Borowski  [2023-09-14 19:53:32 CEST]:
> If you use PgUp to scroll up, there is no visual indication of any kind
> that what you're seeing is not the most recent data.

 this is only partly true, because there is a "-- more --" marker in the
statusbar when someone wrote something after you left that window.  But indeed,
this doesn't appear when noone wrote something in the meantime.

> This notoriously leads to responding to days old stuff, etc -- especially if
> you're an inattentive oaf like me.

 Short hint, looking at the timestamps might help with that.  Personally I also
tab-complete the person who asked something to avoid people who left in the
meantime to work around this a tiny bit.

> Unlike most other programs with such a kind of display, switching off a
> window and back to it doesn't scroll you to the bottom; such a position
> persistence is likely to make you forget that you've scrolled.

 That's intended behavior, and helpful at a lot of times, so it won't get
changed I'm afraid.

 It is something that can be tweaked through usage of scripts though.  I'm not
aware of one that directly scrolls to the end on window switching, but that
should be rather trivial to hack together.

 Personally I love using the "trackbar" script which gives me an indication on
where the last chat message was when I last was in said window, and is
extremely helpful in partly fast-paced channels to find the point where you
left off reading.


 The sb_position script though might though be what you want:

 To assist you installing said script:
/script load scriptassist

 To actually download it:
/scriptassist install sb_position

 To make it visible in the statusbar (see /help statusbar for positioning info):
/statusbar window add position

 If you like it, make it auto load:
/scriptassist autorun sb_position


 I hope that gets you started with your last suggestion, and that this approach
might make you happy enough to close this wishlist bug yourself. :)

 Cheers,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#1051522: libsdl2: SDL_RenderSetClipRect bugfix regression

[Rhonda D'Vine]

Package: libsdl2
Version: 2.28.3+dfsg-1
Severity: normal

Dear Maintainer,

I got notified by wesnoth upstream that there is a bug in SDL starting with
2.27 that will affect the upcoming wesnoth release.  It was caused by a
regression in a bugfix they applied.

https://github.com/libsdl-org/SDL/issues/6896

>From reading the bug report it should be a rather straight-forward fix, and
hopefully they'll include it soon in the next upsream release - but I think
having this documented here too so it doesn't get forgotten would be a nice
idea.  Actually it's somewhat a release of whether SDL releases earlier or
wesnoth (although it already affects the development release of wesnoth 1.17,
which I haven't gotten around to package yet).

 Cheers,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#1051418: obs-studio: clicking on an xcomposite window source makes obs segfault

[Rhonda D'Vine]

Package: obs-studio
Version: 29.1.3+dfsg-2
Severity: important
 
   Hi,
 
 after upgrading from 29.0.2+dfsg-1+b1 to 29.1.3+dfsg-2 (bookworm to trixie) I
couldn't work with the xcomposite window source anymore.  In fact, a
pre-existing scene that was set up to use that source makes obs segfault
immediately when I click the entry in the sources tree, not even able to remove
it and finally switch to a pipewire window source (which has its other quirks).
 
 I'm on gnome with wayland, I guess that is needed information to reproduce it.
When starting obs in the console, the only line that is printed after clicking
on the entry is segfault.
 
 Thanks,
Rhonda
 
 
-- System Information:
Debian Release: trixie/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
 
Kernel: Linux 6.4.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_AT:de
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
 
Versions of packages obs-studio depends on:
ii  libavcodec60   7:6.0-6
ii  libavdevice60  7:6.0-6
ii  libavformat60  7:6.0-6
ii  libavutil587:6.0-6
ii  libc6  2.37-7
ii  libcurl3-gnutls8.2.1-1
ii  libfontconfig1 2.14.2-4
ii  libfreetype6   2.13.2+dfsg-1
ii  libgcc-s1  13.2.0-2
ii  libjansson42.14-2
ii  libluajit-5.1-22.1.0~beta3+git20220320+dfsg-4.1
ii  libmbedcrypto7 2.28.3-1
ii  libmbedtls14   2.28.3-1
ii  libmbedx509-1  2.28.3-1
ii  libobs029.1.3+dfsg-2
ii  libpci31:3.10.0-2
ii  libpulse0  16.1+dfsg1-2+b1
ii  libpython3.11  3.11.5-3
ii  libqt5core5a   5.15.10+dfsg-3
ii  libqt5gui5 5.15.10+dfsg-3
ii  libqt5network5 5.15.10+dfsg-3
ii  libqt5svg5 5.15.10-2
ii  libqt5widgets5 5.15.10+dfsg-3
ii  libqt5xml5 5.15.10+dfsg-3
ii  librist4   0.2.7+dfsg-1
ii  libspeexdsp1   1.2.1-1
ii  libsrt1.5-openssl  1.5.2-1
ii  libstdc++6 13.2.0-2
ii  libswscale77:6.0-6
ii  libudev1   254.1-2
ii  libv4l-0   1.24.1-3
ii  libva-drm2 2.19.0-1
ii  libva2 2.19.0-1
ii  libx11-6   2:1.8.6-1
ii  libx264-1642:0.164.3095+gitbaee400-3+b1
ii  libxcb-composite0  1.15-1
ii  libxcb-randr0  1.15-1
ii  libxcb-shm01.15-1
ii  libxcb-xfixes0 1.15-1
ii  libxcb-xinerama0   1.15-1
ii  libxcb11.15-1
ii  python33.11.4-5+b1
ii  python3.11 3.11.5-3
 
Versions of packages obs-studio recommends:
ii  obs-plugins  29.1.3+dfsg-2
 
Versions of packages obs-studio suggests:
ii  pkexec 123-1
ii  policykit-1123-1
ii  v4l2loopback-dkms  0.12.7-2
 
-- no debconf information

-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#976612: abook: Output from --convert can raise errors in recent NeoMutt

[Rhonda D'Vine]

Tags: wontfix

   Hi,

* Liam Morland  [2023-09-06 15:28:31 CEST]:
> 2023-09-06 09:18-0400 Rhonda D'Vine  wrote:
> >Why would you enter an email address without a local part in abook in 
> >the first place?  What's the usecase for that?  You could use a 
> >different field than the email field in abook to store such 
> >information, not?
> 
> I have it setup so that any email address in abook is whitelisted in my 
> spam filter. If there is no local part, the entire domain is 
> whitelisted.

 That sounds a fair bit like abusing the field here for your setup, frankly
speaking.

> On the principle that software should be "strict when sending and 
> tolerant when receiving", it is not being strict to output an invalid 
> email address.

 Honestly, I rather would tweak abook to reject entering a non email address
into the address field than refusing to output what is in there.  Any other
sense of interpreting that principle is tweaking its meaning in my opinion.

 Cheers,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#976612: abook: Output from --convert can raise errors in recent NeoMutt

[Rhonda D'Vine]

Tags: moreinfo

  Hi,

* Liam K Morland  [2020-12-05 20:18:05 CET]:
> Dear Maintainer,
> 
> When running a command like this:
> 
> abook --convert --infile  --outformat mutt
> 
> If the Abook includes entries where the email address has no local part, 
> such as "@example.com", this entry will be included as-is in the output 
> Mutt file, like this:
> 
> alias example-name Example Name <@example.com>
> 
> Recent versions of NeoMutt raise an error about lines like this.
> 
> Solution: Do not generate an output line for any email addresses which 
> do not include a local part.

 Why would you enter an email address without a local part in abook in the
first place?  What's the usecase for that?  You could use a different field
than the email field in abook to store such information, not?

 Thanks,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#1034441: unblock: irssi/1.4.3-2

[Rhonda D'Vine]

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

Please unblock package irssi

The update has just a one-line fix for CVE-2023-29132 applied.
See #1033785 about it.

[ Reason ]
Fixes a security issue.

[ Risks ]
It's one-line that got removed, so the code change is trivial.

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

unblock irssi/1.4.3-2
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|
diff -Nru irssi-1.4.3/debian/changelog irssi-1.4.3/debian/changelog
--- irssi-1.4.3/debian/changelog2022-11-04 04:12:48.0 +0100
+++ irssi-1.4.3/debian/changelog2023-04-14 10:25:21.0 +0200
@@ -1,3 +1,9 @@
+irssi (1.4.3-2) unstable; urgency=critical
+
+  * Pull commit c554a4 from upstream to fix CVE-2023-29132 (closes: #1033785)
+
+ -- Rhonda D'Vine   Fri, 14 Apr 2023 10:25:21 +0200
+
 irssi (1.4.3-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru irssi-1.4.3/debian/patches/04fix_stale_special_collector 
irssi-1.4.3/debian/patches/04fix_stale_special_collector
--- irssi-1.4.3/debian/patches/04fix_stale_special_collector1970-01-01 
01:00:00.0 +0100
+++ irssi-1.4.3/debian/patches/04fix_stale_special_collector2023-04-14 
10:23:46.0 +0200
@@ -0,0 +1,20 @@
+From c554a45738712219c066897b09a44d99afeb4240 Mon Sep 17 00:00:00 2001
+From: Ailin Nemui 
+Date: Sun, 26 Mar 2023 23:36:41 +0200
+Subject: [PATCH] fix stale special collector use after free
+
+reported by ednash and investigated by @dwfreed
+---
+ src/fe-text/textbuffer-formats.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/src/fe-text/textbuffer-formats.c
 b/src/fe-text/textbuffer-formats.c
+@@ -213,7 +213,6 @@
+   if (!scrollback_format)
+   return;
+ 
+-  special_push_collector(NULL);
+   info = store_lineinfo_tmp(dest);
+ 
+   info->format = format_rec_new(NULL, NULL, 2, (const char *[]){ NULL, 
text });
diff -Nru irssi-1.4.3/debian/patches/series irssi-1.4.3/debian/patches/series
--- irssi-1.4.3/debian/patches/series   2022-07-16 21:12:10.0 +0200
+++ irssi-1.4.3/debian/patches/series   2023-04-14 10:23:24.0 +0200
@@ -1,6 +1,7 @@
 01chanmode_expando_strip
 02ctcp_version_reply
 03firsttimer_text
+04fix_stale_special_collector
 12manpage-fix
 ## disabled for now, Ubuntu-only patch.
 #20fix_ssl_proxy_hostname_check

Bug#1027896: RM: wesnoth-1.14 -- ROM; superseded by wesnoth-1.16

[Rhonda D'Vine]

Package: ftp.debian.org
Severity: normal

Hi,

 please remove wesnoth-1.14, we don't want to ship that given that we
got wesnoth-1.16 in the pool.  This would also close #1010966 against
the source package itself. :)

 Cheers, and thanks in advance!
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#1015241: ITP: irssi-plugin-rocketchat -- plugin for irssi to connect to rocketchat instance

[Rhonda D'Vine]

Package: wnpp
Severity: wishlist
Owner: Rhonda D'Vine 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: irssi-plugin-rocketchat
  Version : 0.6.0
  Upstream Author : Julian Maurice 
* URL : https://github.com/jajm/irssi-rocketchat
* License : GPL2+
  Programming Lang: C
  Description : plugin for irssi to connect to rocketchat instance

With this plugin to irssi you can connect to a rocketchat server and
communicate with people on that instance.

Cheers,
Rhonda

Bug#1010639: beep: Doesn't beep - could not open any device

[Rhonda D'Vine]

severity -1 minor

 Dear Richard,

* Richard Z  [2022-05-05 22:24:21 CEST]:
> Dear Maintainer,
> 
> installed the beep package and tried beep without any arguments and it does 
> not
> work.
> 
> $ BEEP_LOG_LEVEL=999 beep
> beep-log: Verbose: log_constructor
> beep-log: Verbose: beep_driver_console_constructor
> beep-log: Verbose: beep_drivers_register 0x5658c6a0 (console)
> beep-log: Verbose: beep_driver_evdev_constructor
> beep-log: Verbose: beep_drivers_register 0x5658c6e0 (evdev)
> beep: Verbose: evdev driver_detect 0x5658c6e0 (nil)
> beep: Verbose: b-lib: could not open(2) /dev/input/by-path/platform-pcspkr-
> event-spkr: Permission denied

 How are you logged into your system?  The udev rule that beep installs
requires you to be logged in on a virtual console.  Please be referred
to the documentation in /usr/share/doc/beep/PERMISSIONS.md.gz why this
is so. What always works is using beep as root, regardless of how people
are logged in, so I don't follow your call for that this is a grave bug
- in fact it works as intended and isn't even a bug at all.

 I am starting to (re)implement a specific beep group to which people
could be added on top of that. This requires a bit testing though, and
will hit unstable and only be in the next release then.  In the meantime
you could add a corresponding udev rule for giving access to users of a
specific group yourself while following the documentation in the
PERMISSIONS file.

 Hope that helps,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#1009420: irssi is marked for autoremoval from testing

[Rhonda D'Vine]

tags 1009420 + patch
thanks

Hi,

 given the potential autoremoval of irssi we looked into this, irssi
upstream suggested the attached patch which I can confirm to fix the
build.

 Cheers,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|
--- a/tests/regression/client/client.c
+++ b/tests/regression/client/client.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 

Bug#1007914: Bug#1006917: kpcli: "not well-formed (invalid token)" when opening a file

[Rhonda D'Vine]

   Hi,

* Lester Hightower  [2022-03-18 16:12:45 CET]:
> I do not equate your one, esoteric data access problem with justification
> for removing the package from Debian.

 Pasting data into the comment field of an entry is nothing I would
anywhere closely consider esoteric, rather the opposite.  And that a
tool would write data out that it couldn't read back in is something
that is utterly confusing, to say the least, and a clear bug that is not
just annoying but can impact people's access.  That it was easy to fix
doesn't reduce the impact of the issue.

> There is no security problem and no data was lost. Even if you had not
> fixed the problem in File::KeePass yourself, there are many other
> programs that operate on KeePass files that could have been used to
> access your data.

 This is where you are clearly wrong.  I tried opening the file with
other keepass tools, and it boiled down to the same issue: There was
data in the XML that weren't valid, and thus couldn't get parsed by any
keepass tool.

 Please don't try to reason with things that aren't the case.
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#1006917: kpcli: "not well-formed (invalid token)" when opening a file

[Rhonda D'Vine]

reopen 1007914
thanks

* Lester Hightower  [2022-03-18 12:53:30 CET]:
> Please note that marking this bug as "grave" queued kpcli for autoremoval
> from Debian testing:

 I am very well aware how the bug states work.  Thing is, why do you
think the data loss isn't severe enough to warrant a release critical
status?  It's definitely not a minor issue.

> Receiving that notice is what made me act yesterday.

 Thing is, demoting release critical bugs without fixing them isn't the
most helpful thing.  I know that it might be a pain at times, but not
being able to get to your passwords is a very critical issue for kpcli.

 That said, even having it in a release-critical state against the
library package would remove kpcli because it would get removed together
with it, and given that kpcli is the only package depending on
libfile-keepass-perl the difference is only minor in the end.

 Cheers,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#1006917: kpcli: "not well-formed (invalid token)" when opening a file

[Rhonda D'Vine]

* Arno Töll  [2022-03-17 14:07:02 CET]:
> Hi Rhonda,
> 
> Am 08.03.22 um 16:31 schrieb Rhonda D'Vine:
> >   Upstream is at 3.6 in the meantime, I'm willing to update it now that I
> > digged a bit further into it.  If I don't hear back in the next few days
> > I propose an NMU for it, as thanks for having it around in the first
> > place. :)
> 
> please feel free to do, and go ahead. Feel free to add yourself as a
> maintainer/uploader if you wish. ;-)

 Do you have a copy of the git repository you used still around?  It
never seems to have been moved to salsa, and I for obvious reasons would
work based on what's there already. :)

> The issue has been properly reassigned in the meantime. Thanks for that
> Lester.

 It actually hasn't been reassigned but closed I noticed, and I'm also
not so convinced to call it only a minor issue, because as I explained,
I managed to fix it because I know my way around the code, but that's
not something to expect from regular users.  I will be looking into
filing this with the upstream tracker though.

 So long,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#1006917: kpcli: "not well-formed (invalid token)" when opening a file

[Rhonda D'Vine]

Yes indeed, i had to fix it through the module. Sorry that I wasn't clear on 
that part. Likely this should be changed to be a bug in the module interface 
since the frontend shouldn't have to know too much about what's allowed or not 
in the fields, the module should give the frontend error messages accordingly, 
but I hadn't had the time to look up if that's possible to differentiate.

Thanks for asking for clarification,
Rhonda

Am 8. März 2022 16:47:41 MEZ schrieb Lester Hightower 
:
>Hi Rhonda,
>
>I am happy that you found and fixed your problem. I suspect, however, that
>the code that you changed was not actually kpcli code but, instead,
>File::KeePass code -- the module that kpcli uses to read and write keepass
>files. https://metacpan.org/pod/File::KeePass
>
>Can you confirm that I am correct about that?
>
>Thanks,
>
>--
>Lester
>
>
>On Tue, Mar 8, 2022 at 10:33 AM Rhonda D'Vine  wrote:
>
>>   Hi,
>>
>> $buffer =~ s/\e//g;
>>
>>  .. this was all that was needed to fix my mess.  Though, kpcli for
>> obvious reasons shouldn't be able to write broken data it can't read
>> again, so I keep seeing this as a severe bug in the code which can lead
>> to data loss for people who aren't familiar enough with perl or who
>> don't have friends who support them to dig down the issue.
>>
>>  The above line was a quick fix for my case, I'm uncertain if it might
>> appear to others in other ways, but this clearly goes against the
>> principle of robustness.
>>
>>  Upstream is at 3.6 in the meantime, I'm willing to update it now that I
>> digged a bit further into it.  If I don't hear back in the next few days
>> I propose an NMU for it, as thanks for having it around in the first
>> place. :)
>>
>>  Enjoy,
>> Rhonda [happy again]
>>
>>
>> * Rhonda D'Vine  [2022-03-08 16:19:46 CET]:
>> >Hi,
>> >
>> >  I managed to find the culprit With A Little Help From My Friends[tm]. I
>> > used Data::Dumper before the content got passed to XML::Parser, and it
>> > turned out that there is an Escape character (0x1b, ^[) in a comment
>> > field.
>> >
>> >  kpcli seems to have accepted this when the comment was pasted and
>> > stored it happily, but was unable to re-read the file written with that
>> > in it.
>> >
>> >  I'm currently fiddling around to delete that escape character on load
>> > time and have kpcli start, allowing me to save it without the escape
>> > character, hopefully allowing to re-read it afterwards.
>> >
>> >  I'll keep you posted,
>> > Rhonda
>>
>> --
>> Fühlst du dich mutlos, fass endlich Mut, los  |
>> Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
>> Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
>> Fühlst du dich haltlos, such Halt und lass los|
>>
>>

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Bug#1006917: kpcli: "not well-formed (invalid token)" when opening a file

[Rhonda D'Vine]

  Hi,

$buffer =~ s/\e//g;

 .. this was all that was needed to fix my mess.  Though, kpcli for
obvious reasons shouldn't be able to write broken data it can't read
again, so I keep seeing this as a severe bug in the code which can lead
to data loss for people who aren't familiar enough with perl or who
don't have friends who support them to dig down the issue.

 The above line was a quick fix for my case, I'm uncertain if it might
appear to others in other ways, but this clearly goes against the
principle of robustness.

 Upstream is at 3.6 in the meantime, I'm willing to update it now that I
digged a bit further into it.  If I don't hear back in the next few days
I propose an NMU for it, as thanks for having it around in the first
place. :)

 Enjoy,
Rhonda [happy again]


* Rhonda D'Vine  [2022-03-08 16:19:46 CET]:
>Hi,
> 
>  I managed to find the culprit With A Little Help From My Friends[tm]. I
> used Data::Dumper before the content got passed to XML::Parser, and it
> turned out that there is an Escape character (0x1b, ^[) in a comment
> field.
> 
>  kpcli seems to have accepted this when the comment was pasted and
> stored it happily, but was unable to re-read the file written with that
> in it.
> 
>  I'm currently fiddling around to delete that escape character on load
> time and have kpcli start, allowing me to save it without the escape
> character, hopefully allowing to re-read it afterwards.
> 
>  I'll keep you posted,
> Rhonda

-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#1006917: kpcli: "not well-formed (invalid token)" when opening a file

[Rhonda D'Vine]

   Hi,

 I managed to find the culprit With A Little Help From My Friends[tm]. I
used Data::Dumper before the content got passed to XML::Parser, and it
turned out that there is an Escape character (0x1b, ^[) in a comment
field.

 kpcli seems to have accepted this when the comment was pasted and
stored it happily, but was unable to re-read the file written with that
in it.

 I'm currently fiddling around to delete that escape character on load
time and have kpcli start, allowing me to save it without the escape
character, hopefully allowing to re-read it afterwards.

 I'll keep you posted,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#1006917: kpcli: "not well-formed (invalid token)" when opening a file

[Rhonda D'Vine]

Package: kpcli
Version: 3.1-3.1
Severity: grave
Tags: upstream
Justification: causes serious data loss

Dear Maintainer,

I store my passwords in a keepass file that I exclusively use through kpcli.
After the last kernel upgrade reboot I was unable to open the file anymore, and
thus can't access my passwords.  I have an aged backup, and most sites offer
password resets, but this is actually a serious data loss.

When I try to open the database now I get the following error message:

➤ kpcli --kdb rhonda.kdbx
Please provide the master password: *
Couldn't load the file rhonda.kdbx:
not well-formed (invalid token) at line 3103, column 15, byte 100409 at 
/usr/lib/x86_64-linux-gnu/perl5/5.34/XML/Parser.pm line 187.

So I have somehow the hope that the data isn't lost completely, only that the
XML parser is stumbling upon something.  I haven't had the nerve yet to dig
further into it and try to unpack the whole situation, make kpcli dump what it
gives to XML::Parser, that part gives me a bit of a hope because it clearly can
decrypt the file in the first place, but it makes it unusable to the
"innocent".

If you are able to give me any helping hand on those grounds, they would be
very much appreciated! Because as it stands I assume this might happen to
others, and I'm uncertain if it would have anything to do with specific data
stored in some comment or password field or whatever.

Thanks in advance,
Rhonda


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

Kernel: Linux 5.16.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_AT:de
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kpcli depends on:
ii  libclone-perl  0.45-1+b2
ii  libcrypt-rijndael-perl 1.16-1+b1
ii  libfile-keepass-perl   2.03-1.1
ii  libsort-naturally-perl 1.03-2
ii  libterm-readkey-perl   2.38-1+b3
ii  libterm-readline-gnu-perl  1.42-2+b1
ii  libterm-shellui-perl   0.92-4
ii  perl   5.34.0-3

Versions of packages kpcli recommends:
ii  libcapture-tiny-perl   0.48-1
ii  libclipboard-perl  0.27-1
pn  libdata-password-perl  
pn  libmath-random-isaac-perl  

kpcli suggests no packages.

-- no debconf information

Bug#716386: [Mayhem] Bug report on tetradraw: tetraview crashes with exit status 139

[Rhonda D'Vine]

Dear Lee,

* Lee Garrett  [2022-02-09 18:27:38 CET]:
> Package: tetradraw
> Version: 2.0.3-9+b2
> Followup-For: Bug #716386
> X-Debbugs-Cc: deb...@rocketjump.eu
> 
> Hi Rhonda,
> 
> sorry to grave dig this bug report, but it seems that tetradraw might be 
> broken
> for a couple of releases now. On bullseye it segfaults with rc 139. A few 
> people
> in #debian reported the same issue, so it looks like it's 100% reproducible.
> Since I'd love to make some nice ascii art for my /etc/motd, it would be nice 
> if
> you could find the time to fix it. Thanks in advance!

 You are definitely right on that.  I think in one of the bugs there is
a workaround for the issue: It runs smoothly on a virtual console
instead of within a terminal in Xorg.  So if that's possible, I suggest
to go that path.

 What also works is starting it with TERM=linux.  This gives a hint in
what area the issue may lie.  I am unfortunately not a well enough coder
to dig further into it, but those are the workarounds that I am aware
of, and might give people a hint on where to look into for fixing this.

 The availability of a workaround for the crash and the possibility to
use it was actually the reason for keeping it in the release and
considering it fit for use.  If you agree with that feel free to lower
the severity again, but hopefully someone will be able to find a
solution for the crash in an xterm regardless.

 Like you say it's something to make nice ascii art, and I'm not aware
of any real alternatives to that within Debian.  aewan is one that comes
to mind, but tetdradraw supports those fancy ANSI block graphics very
directly.

 Thanks,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#979098: Bug#995843: abook: complete d/copyright file

[Rhonda D'Vine]

Hey Jochen,

 resolving would need to enhance the copyright file so that it fulfills
all the required information.  Bastian already did a good job and likely
the patch provided should be sufficient for that.  I haven't gotten
around yet to upload that, but plan to do so in the next few days.

 I likely will move the packaging from my private git instance to salsa,
and if you are still interested I can add you to the repository indeed.

 Thanks for your interest,
Rhonda


* Jochen Sprickerhof  [2021-11-02 08:20:15 CET]:
> Hi Rhonda,
> 
> abook is marked for autoremoval in two days due to this bug, can you comment
> on how to resolve it?
> 
> I would be happy to help maintain abook, if you need help.
> 
> Cheers Jochen
> 
> * Bastian Germann  [2021-10-13 14:40]:
> > Control: tags -1 patch
> > 
> > Hi,
> > 
> > A copyright file for abook with the necessary fixes for this bug is 
> > enclosed.
> > Please include it in a new package revision.
> > 
> > Thanks,
> > Bastian
> 
> > Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> > Upstream-Name: abook
> > Upstream-Contact: Jaakko Heinonen 
> > Source: http://abook.sourceforge.net/
> > 
> > Files: *
> > Copyright: 2005, Jaakko Heinonen 
> > Comment: No license version is specified for most of the code.
> > Some GPL-2+ files make the project as a whole GPL-2+.
> > License: GPL-2+
> > 
> > Files: abook.1 abookrc.5
> > Copyright: Alan Ford 
> > License: GPL-2+
> > 
> > Files: aclocal.m4 config.rpath Makefile.in m4/*
> > Copyright: (see individual files)
> > Comment: Some files come with the disclaimer, some do not.
> > License: FSFULLR
> > 
> > Files: config.guess config.sub
> > Copyright: 1992-2013 Free Software Foundation, Inc.
> > License: GPL-3+ with Autoconf exception
> > 
> > Files: depcomp
> > Copyright: 1999-2013 Free Software Foundation, Inc.
> > License: GPL-2+
> > 
> > Files: getname.c
> > Copyright: This code was taken from hypermail
> >   modified by Jaakko Heinonen 
> >   .
> >   For strcpymax() function:
> >   Copyright (C) 1994, 1995 Enterprise Integration Technologies Corp.
> >   VeriFone Inc./Hewlett-Packard. All Rights Reserved.
> > Comment: See https://bugs.debian.org/979098 for details on assuming GPL-2+
> > License: GPL-2+
> > 
> > Files: getopt*
> > Copyright: 1987-1997 Free Software Foundation, Inc.
> > License: LGPL-2+
> > 
> > Files: install-sh
> > Copyright: 1994 X Consortium
> > License: X11
> > 
> > Files: ldif.c
> > Copyright: 1992-1996 Regents of the University of Michigan.
> > Comment: adapted to use with abook by JH 
> > License: Michigan
> > Redistribution and use in source and binary forms are permitted
> > provided that this notice is preserved and that due credit is given
> > to the University of Michigan at Ann Arbor. The name of the University
> > may not be used to endorse or promote products derived from this
> > software without specific prior written permission. This software
> > is provided ``as is'' without express or implied warranty.
> > 
> > Files: mbswidth.?
> > Copyright: 2000-2002 Free Software Foundation, Inc.
> > License: GPL-2+
> > 
> > Files: misc.c
> > Copyright: Jaakko Heinonen
> >   1994 Lars Wirzenius
> > Comment: BSD-2-clause covers the getaline() function.
> > License: GPL-2+ and BSD-2-clause
> > 
> > Files: missing
> > Copyright: 1996-2013 Free Software Foundation, Inc.
> > License: GPL-2+
> > 
> > Files: po/fr.po po/it.po po/sv.po
> > Copyright: 2005 Free Software Foundation, Inc.
> > License: GPL-2+
> > 
> > Files: vcard.c
> > Copyright: 2012, Raphaël Droz 
> > License: GPL-2+
> > 
> > Files: views.c
> > Copyright: Cedric Duval
> > License: GPL-2+
> > 
> > Files: xmalloc.c
> > Copyright: 2005 Jaakko Heinonen
> > License: BSD-2-clause
> > 
> > Files: debian/*
> > Copyright: 2000, Alan Ford 
> >   2003, Rhonda D'Vine 
> >   2015, Denis Briand 
> > License: WTFPLv2
> > 
> > License: GPL-2+
> >This program is free software; you can redistribute it and/or modify
> >it under the terms of the GNU General Public License as published by
> >the Free Software Foundation; either version 2 of the License, or
> >(at your option) any later version.
> >.
> >This program is distributed in the hope that it will be 

Bug#995843: abook: missing licenses in d/copyright

[Rhonda D'Vine]

* Bastian Germann  [2021-10-07 11:59:24 CEST]:
> Can you please take a look at #995843 which I think is a Policy violation by
> abook not including all distribution licenses in the copyright file. The
> package maintainer does not think so and claims that only including the main
> license (GPL-2+) is good enough.

 This is a misrepresentation of what I said though ...

> There are at least two BSD licenses and an old-style MIT license which are
> violated in the binary package by not including them.

 They aren't violated.  Read their license text.

 Thanks,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#995843: abook: missing licenses in d/copyright

[Rhonda D'Vine]

* Bastian Germann  [2021-10-07 11:00:28 CEST]:
> Am 07.10.21 um 10:55 schrieb Rhonda D'Vine:
> >   I think you misunderstand how the GPL works.  The GPL is known to be
> > viral, and licenses compatible with the GPL are indeed compatible with
> > it because they allow to be covered under the GPL.  The whole work in
> > the end is covered by the GPL, and thus it is in my understanding
> > allowed to write it that way.
> 
> This issue is not about GPL. It is about Debian Policy, which says in 12.5:
> "Every package must be accompanied by a verbatim copy of its distribution
> license(s) in the file /usr/share/doc/PACKAGE/copyright."

 And the package is distributed as a whole under GPL-2+.  This is
fulfilled, and in alignment with how licenses and specifically the GPL
work.

> So it is actually a Policy violation. But I am not raising severity again to
> keep things calm. If you soubt that please contact FTP Master.

 You are the one that claims it's a policy violation - but I don't see
that justified.  You are free to discuss your view on that with ftp
master though.

 Enjoy,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#995843: abook: missing licenses in d/copyright

[Rhonda D'Vine]

Severity: -1 minor

* Bastian Germann  [2021-10-07 00:31:00 CEST]:
> abook contains distribution licenses that are not copied to
> debian/copyright. At least BSD-2-clause (xmalloc.c, misc.c), old-style
> MIT (ldif.c), FSFULLR (configure, Makefile.in), X11 (install-sh), and
> probably others.

 I think you misunderstand how the GPL works.  The GPL is known to be
viral, and licenses compatible with the GPL are indeed compatible with
it because they allow to be covered under the GPL.  The whole work in
the end is covered by the GPL, and thus it is in my understanding
allowed to write it that way.  

 If you want to pursue on that grounds, it would be helpful if you could
find people that support your interpretation, because I don't think my
understanding of the GPL is too off - and you showed in the other bug
report already that you have personal interpretations that don't follow
what's written in the GPL.

 Said that, it doesn't hurt to add that to make it more complete, even
though I don't think there is a real need for it.

 Thanks,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#979098: Legally problematic GPL-3+ readline dependency

[Rhonda D'Vine]

Control: severity -1 wishlist

* Bastian Germann  [2021-10-06 22:41:33 CEST]:
> Control: severity -1 minor
> 
> Am 06.10.21 um 22:30 schrieb Rhonda D'Vine:
> >> "All files in this distribution are released under GNU GENERAL PUBLIC
> >> LICENSE. See COPYING for details."
> > 
> >  Right.  It doesn't specify a version.  And this is the core point, and
> > the reference to the COPYING file is clear on that grounds too.
> >  The COPYING file specifically does have the "or later" clause in it.
> 
> The COPYING file is the standard GPLv2. Yes, in the license template at
> the end it specifies "or later" but that is a suggestion how to apply
> the license. In the TERMS AND CONDITIONS no. 9, it says : "If the
> Program does not specify a version number of this License, you may
> choose any version ever published by the Free Software Foundation."

 Exactly that: The program didn't choose a version number.  This isn't
even ambigious, this is a very clear case covered in the license.  So I
am a bit worried in how you managed to interpret that as a license
violation in the first place.

> So it does not specify "or later" but also no version. Combined with the
> few imported files that are GPL-2+, it is fair to say, the complete
> program is GPL-2+. But that is not a trivial derivation.

 But it is.  No version means any.  Which is compatible with GPL-2+
work.  Which makes the whole work GPL-2+.

> No specific agenda, just keeping Debian on the legally distributable
> side. So, just keep the libreadline.

 It always was legally distributable as it is.
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#979098: Legally problematic GPL-3+ readline dependency

[Rhonda D'Vine]

 Hi again.

* Bastian Germann  [2021-10-06 23:58:41 CEST]:
> Am 06.10.21 um 21:34 schrieb Rhonda D'Vine:
> >  Are you reading the debian/copyright file correct?  Yes, it says
> > "License: GPL-2" but AIUI that is just a reference indicator, and the
> > long paragraph below that is the relevant one.  And that clearly states
> > "or later", and it's the only explenation for the GPL-2 tag in there.
> 
> Where in the upstream source do you take the "or later" clause from?
> There are some files that have this in the license header but these are
> all files that stem from other projects, e.g. the getopt* files.
> 
> The original abook files do not specify a GPL version in their headers
> and the README says:
> 
> "All files in this distribution are released under GNU GENERAL PUBLIC
> LICENSE. See COPYING for details."

 Right.  It doesn't specify a version.  And this is the core point, and
the reference to the COPYING file is clear on that grounds too.

> Since COPYING is version 2 there is no reason to assume an "or later"
> clause applies to the project in its entirety.

 The COPYING file specifically does have the "or later" clause in it.

> >  I understand where you are coming from, and I agree, it can be improved
> > to directly read GPL-2+ -- but to the best of my understanding the
> > copyright file is clear on that.
> 
> The outcome should be removing "or later", not adding "+".

 So your preferred outcome is to misinterpret what is in there and
interpret it as being an issue without knowing the upstream
developer(s), while things speak about something different, and always
have?  What is your agenda with this?

 Thanks,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#979098: Legally problematic GPL-3+ readline dependency

[Rhonda D'Vine]

Severity: wishlist

* Bastian Germann  [2021-10-06 19:38:07 CEST]:
> Severity: serious

 Please don't severity bump this, specifically since I don't see how you
want to justify it.

> On Sat, 2 Jan 2021 18:46:04 +0100 Bastian Germann 
>  wrote:
> > Package: abook
> > Severity: important
> > 
> > This package depends on libreadline8 which is GPL-3+ licensed. According
> > to debian/copyright parts of your package are GPL-2-only licensed. If
> > that is also (transitively) the case for the binaries that link with
> > libreadline.so.8 it might be legally problematic (see
> > https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility).
> > 
> > There is an easy solution to the problem: Replacing the build dependency
> > libreadline-dev with libreadline-gplv2-dev links with the GPL-2+
> > licensed older version. However, that is orphaned in Debian, so
> > libeditreadline-dev should be preferred, which does not compile with
> > your package without any patch. It links with the BSD-licensed libedit
> > library which is a readline replacement.
> 
> Please fix the dependency or fix the d/copyright file if the "or later"
> clause applies to all the GPL-2 files.

 Are you reading the debian/copyright file correct?  Yes, it says
"License: GPL-2" but AIUI that is just a reference indicator, and the
long paragraph below that is the relevant one.  And that clearly states
"or later", and it's the only explenation for the GPL-2 tag in there.

 I understand where you are coming from, and I agree, it can be improved
to directly read GPL-2+ -- but to the best of my understanding the
copyright file is clear on that.

 Thus wishlist, I will add the + in there for making it extra clear, but
the way it currently is _is_ already "gpl-2 or later" licensed, so this
is clearly not of release-critical severity, rather a cosmetic thing.

 Thanks,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#991641: buster-pu: package irssi/1.2.0-2

[Rhonda D'Vine]

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

(Please provide enough information to help the release team
to judge the request efficiently. E.g. by filling in the
sections below.)

[ Reason ]
This update fixes CVE-2019-13045 for buster by pulling in the upstream
commit that is included in newer versions of the package.

[ Impact ]
May affect the stability of Irssi. SASL logins may fail, especially
during (manual and automated) reconnect.

[ Tests ]
It is the fix that got applied in other distributions and been used by
lots of folks for quite a while now.

[ Risks ]
The changes are quite straight forward.

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
It's just the upstream patch pulled in.

 So long,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|
diff -Nru irssi-1.2.0/debian/changelog irssi-1.2.0/debian/changelog
--- irssi-1.2.0/debian/changelog	2019-02-12 21:59:00.0 +0100
+++ irssi-1.2.0/debian/changelog	2021-07-29 14:11:39.0 +0200
@@ -1,3 +1,9 @@
+irssi (1.2.0-2+deb10u1) buster; urgency=medium
+
+  * Import upstream security fix for CVE-2019-13045 (closes: #931264)
+
+ -- Rhonda D'Vine   Thu, 29 Jul 2021 14:11:39 +0200
+
 irssi (1.2.0-2) unstable; urgency=medium
 
   [ Rhonda D'Vine ]
diff -Nru irssi-1.2.0/debian/patches/98copy-sasl-username-and-password-values irssi-1.2.0/debian/patches/98copy-sasl-username-and-password-values
--- irssi-1.2.0/debian/patches/98copy-sasl-username-and-password-values	1970-01-01 01:00:00.0 +0100
+++ irssi-1.2.0/debian/patches/98copy-sasl-username-and-password-values	2021-07-29 14:11:39.0 +0200
@@ -0,0 +1,41 @@
+Description: copy sasl username and password values
+Origin: Upstream, https://github.com/irssi/irssi/pull/1058
+Author: ailin-nemui
+
+--- a/src/irc/core/irc-core.c
 b/src/irc/core/irc-core.c
+@@ -75,6 +75,8 @@
+ 
+ 	g_free_not_null(ircconn->usermode);
+ 	g_free_not_null(ircconn->alternate_nick);
++	g_free_not_null(ircconn->sasl_username);
++	g_free_not_null(ircconn->sasl_password);
+ }
+ 
+ void irc_core_init(void)
+--- a/src/irc/core/irc-servers-reconnect.c
 b/src/irc/core/irc-servers-reconnect.c
+@@ -49,8 +49,8 @@
+ 	rec->usermode = g_strdup(src->usermode);
+ 	rec->alternate_nick = g_strdup(src->alternate_nick);
+ 	rec->sasl_mechanism = src->sasl_mechanism;
+-	rec->sasl_username = src->sasl_username;
+-	rec->sasl_password = src->sasl_password;
++	rec->sasl_username = g_strdup(src->sasl_username);
++	rec->sasl_password = g_strdup(src->sasl_password);
+ 	*dest = (SERVER_CONNECT_REC *) rec;
+ }
+ 
+--- a/src/irc/core/irc-servers-setup.c
 b/src/irc/core/irc-servers-setup.c
+@@ -101,8 +101,8 @@
+ 			conn->sasl_mechanism = SASL_MECHANISM_PLAIN;
+ 			if (ircnet->sasl_username != NULL && *ircnet->sasl_username &&
+ 			ircnet->sasl_password != NULL && *ircnet->sasl_password) {
+-conn->sasl_username = ircnet->sasl_username;
+-conn->sasl_password = ircnet->sasl_password;
++conn->sasl_username = g_strdup(ircnet->sasl_username);
++conn->sasl_password = g_strdup(ircnet->sasl_password);
+ 			} else
+ g_warning("The fields sasl_username and sasl_password are either missing or empty");
+ 		}
diff -Nru irssi-1.2.0/debian/patches/series irssi-1.2.0/debian/patches/series
--- irssi-1.2.0/debian/patches/series	2019-02-12 21:59:00.0 +0100
+++ irssi-1.2.0/debian/patches/series	2021-07-29 14:11:39.0 +0200
@@ -1,3 +1,4 @@
+98copy-sasl-username-and-password-values
 01chanmode_expando_strip
 02ctcp_version_reply
 03firsttimer_text

Bug#990552: unblock: irssi/1.2.3-1

[Rhonda D'Vine]

Control: tags -1 -moreinfo

* Sebastian Ramacher  [2021-07-01 21:51:22 UTC]:
> > [ Checklist ]
> >   [X] all changes are documented in the d/changelog
> >   [X] I reviewed all changes and I approve them
> >   [X] attach debdiff against the package in testing
> 
> The debdiff is missing. We'd appreciate a fitered debdiff without the
> autotools cruft in this case.

 I'm deeply sorry, I was certain I pressed the attach in reportbug, but
seemingly that didn't happen.

 Find it attached here, this is the command I used to create it:

# debdiff --exclude='Makefile.*' --exclude=aclocal.m4 --exclude=build-aux *.dsc

 Cheers,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|


irssi_1.2.2-2_1.2.3-1_filter.debdiff.gz
Description: application/gzip

Bug#990552: unblock: irssi/1.2.3-1

[Rhonda D'Vine]

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

Please unblock package irssi

[ Reason ]
1.2.3 was a pure bugfix and stability fix release of irssi, no feature changes.
Please allow this into bullseye.

[ Impact ]
bullseye would release with a version of irssi that has several known issues,
see the entries in their NEWS section: https://irssi.org/NEWS/#v1-2-3

[ Tests ]
I'm using the package myself on a daily basis, though I haven't gotten around
to work on automatic tests because it's an interactive package requiring an IRC
server to test with, which is rather complicated, and thus couldn't get
auto-unblock.

[ Risks ]
The package is a leaf package with a fair amount of other IRC clients available
within Debian.

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

[ Other info ]
Sorry for being late with this, but I hope it will be accepted.

unblock irssi/1.2.3-1

Bug#952868: OpenSSL linking without license exception

[Rhonda D'Vine]

Dear Bastian,

 I can't seem to get this patch to work. Without libssl-dev installed in
the building chroot this fails for me.  Can you revisit this, and check
where you might have missed something?  I used a clean unstable
cowbuilder chroot for building with this patch.

 Thanks,
Rhonda


On Sun, Mar 01, 2020 at 01:14:49PM +0100, Bastian Germann wrote:
> Package: wesnoth
> Severity: serious
> 
> This GPL2 package links with OpenSSL. The OpenSSL license is
> incompatible with the GPL (see
> https://ftp-master.debian.org/REJECT-FAQ.html). This can be solved by
> asking upstream to add a license exception or by linking with wolfSSL
> instead. You can find a patch enclosed (untested).

> From f15f10434ef5fbdc9cf2eeea15e7ca057c0f6e63 Mon Sep 17 00:00:00 2001
> From: Bastian Germann 
> Date: Sun, 1 Mar 2020 11:19:53 +0100
> Subject: [PATCH] Replace OpenSSL with wolfSSL
> 
> ---
>  debian/control  |  2 +-
>  debian/patches/01wolfssl-crypto | 14 ++
>  debian/patches/series   |  1 +
>  debian/rules|  2 +-
>  4 files changed, 17 insertions(+), 2 deletions(-)
>  create mode 100644 debian/patches/01wolfssl-crypto
> 
> diff --git a/debian/control b/debian/control
> index 5e35ef9b..1d650a07 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -8,7 +8,7 @@ Build-Depends: debhelper (>= 11~), libsdl2-image-dev (>= 
> 2.0.0),
>libboost-iostreams-dev, libboost-test-dev, libboost-regex-dev,
>libboost-serialization-dev, libboost-system-dev, libboost-thread-dev,
>libboost-program-options-dev, libboost-filesystem-dev, libboost-locale-dev,
> -  libboost-random-dev, libpng-dev, libreadline-dev, libssl-dev,
> +  libboost-random-dev, libpng-dev, libreadline-dev, libwolfssl-dev,
>    libpango1.0-dev, libvorbis-dev, cmake (>= 2.6)
>  Standards-Version: 4.1.4
>  Uploaders: Rhonda D'Vine ,
> diff --git a/debian/patches/01wolfssl-crypto b/debian/patches/01wolfssl-crypto
> new file mode 100644
> index ..ad55d158
> --- /dev/null
> +++ b/debian/patches/01wolfssl-crypto
> @@ -0,0 +1,14 @@
> +Author: Bastian Germann   vim:ft=diff:
> +Description: Link with wolfssl instead of libcrypto.
> +
> +--- a/cmake/FindCrypto.cmake
>  b/cmake/FindCrypto.cmake
> +@@ -2,7 +2,7 @@
> + 
> + find_path(CRYPTO_INCLUDE_DIR openssl/md5.h)
> + 
> +-find_library(CRYPTO_LIBRARY crypto)
> ++find_library(CRYPTO_LIBRARY wolfssl)
> + 
> + # handle the QUIETLY and REQUIRED arguments and set XXX_FOUND to TRUE if 
> all listed variables are TRUE
> + INCLUDE(FindPackageHandleStandardArgs)
> diff --git a/debian/patches/series b/debian/patches/series
> index 57b6465e..8014e9fd 100644
> --- a/debian/patches/series
> +++ b/debian/patches/series
> @@ -1,2 +1,3 @@
> +01wolfssl-crypto
>  02wesnoth-nolog-desktop-file
>  03wesnothd-name
> diff --git a/debian/rules b/debian/rules
> index 02ad4071..cbec12c1 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -23,7 +23,7 @@ ifneq (,$(filter $(DEB_HOST_ARCH), mips mipsel))
>  CXXFLAGSDBG = -g1
>  endif
>  
> -export CPPFLAGS := $(shell dpkg-buildflags --get CPPFLAGS)
> +export CPPFLAGS := $(shell dpkg-buildflags --get CPPFLAGS) 
> -I/usr/include/wolfssl -DOPENSSL_ALL
>  export CFLAGS   := $(shell dpkg-buildflags --get CFLAGS) $(CPPFLAGS) 
> -std=c++11 -fopenmp
>  export CXXFLAGS := $(shell dpkg-buildflags --get CXXFLAGS) $(CPPFLAGS) 
> -std=c++11 -fopenmp  $(CXXFLAGSDBG)
>  export LDFLAGS  := $(shell dpkg-buildflags --get LDFLAGS)
> -- 
> 2.25.1
> 

Bug#953014: grep-dctrl -w without -F misses the last package of each field

[Rhonda D'Vine]

    Hello,

 I've submitted your patch to the upstream git repository:
 https://github.com/ajkaijanaho/dctrl-tools/pull/2

 Thanks for finding and reporting this,
Rhonda

On 03.03.20 08:34, Rebecca N. Palmer wrote:
> Package: dctrl-tools
> Version: 2.24-3
> Control: tags -1 patch
>
> Example:
> grep-dctrl -w -s Package "python3-pandas"
> /var/lib/apt/lists/*_debian_dists_sid_main_source_Sources
> doesn't find influxdb-python, jsonpickle, poretools and tqdm, while
> the same without the -w does.  (This caused me to be unaware of
> #950063.) All these packages have their python3-pandas
> build-dependency listed last.
>
> This happens when searching a whole entry, but not when searching
> particular fields (-F).
>
> Fix (also adding support for build profiles <> without a preceding
> space, though I'm not sure if those are actually allowed):
>
> --- dctrl-tools-2.24.orig/lib/atom.c
> +++ dctrl-tools-2.24/lib/atom.c
> @@ -23,7 +23,7 @@
>  #include "version.h"
>
>  #define RE_PKG_BEGIN    "(^| )"
> -#define RE_PKG_END    "([, \\(]|$)"
> +#define RE_PKG_END    "([, \\(\n<]|$)"
>
>  void atom_finish(struct atom * atom)
>  {


pEpkey.asc
Description: application/pgp-keys

Bug#930072: dctrl-tools: join-dctrl segfaults

[Rhonda D'Vine]

severity 930072 important
thanks

   Hi,

On 6/12/19 10:35 PM, Peter Pentchev wrote:
> On Thu, Jun 06, 2019 at 04:04:39PM +0200, Guillem Jover wrote:
>> Package: dctrl-tools
>> Version: 2.24-3
>> Severity: serious
>>
>> Hi!
>>
>> The join-dctrl command segfaults with the attached files.
>>
>>   ,---
>>   $ join-dctrl Packages-A Packages-B
>>   Segmentation fault (core dumped)
> 
> Hi,
> 
> From what I think I see, I believe that this is less wrong behavior
> and more lack of error detection and proper error messages.
> The manual page states that some field joining options must be
> specified - some combination of -j, -1, and -2. A command like:

 I have to agree with Peter here.  While I don't disagree with that it
is a bug that needs to get addressed, it doesn't fall under the category
of release-critical because the manpage states that a join field must be
specified.

 So long,
Rhonda

Bug#930037: irssi + mosh: badly rendered status lines

[Rhonda D'Vine]

On 6/6/19 6:56 PM, Jakub Wilk wrote:
> * Rhonda D'Vine , 2019-06-06, 16:27:
>> what's yout TERM on the host, when you mosh to the server?
> 
> Terminal on the local side doesn't seem to matter; I can reproduce the
> bug in any of the following:
> * Linux console (TERM=linux)
> * urxvt (TERM=rxvt)
> * xterm (TERM=xterm)
> 
> On the remote server, it's TERM=xterm.
> 
>> Is there any tmux or screen involved?
> 
> No.
> 
>> Are both the server from which you mosh out of and the remote server
>> buster?
> 
> The local machine is unstable.
> 
>> This might be related: https://github.com/irssi/irssi/issues/753
> 
> Aha, thanks. I guess mosh's xterm emulation isn't quite right...
> 
> Irssi upstream recommends setting TERM to something else on the server
> side, but AFAIK there's no dedicated terminal definition for mosh. :-/
> 
> I've set TERM=vte (even though mosh and VTE are unrelated) as a
> work-around for now; it fixes the bug and I haven't seen any bad side
> effects so far.

 Glad this helped.  I noticed a few strangenesses with respect to mosh
instead of ssh myself, like certain utf8 characters not getting
displayed, which was kinda weird.  I think there is a bit fishy stuff
going on in mosh, unsure if it might be related to different mosh
versions on both ends (but both buster and unstable have the same, so
that's not the case here), but it certainly mixes some bits up.

 Are you fine with closing this bugreport then?  I am more leaning
towards that it might be mosh in play here than irssi, we could also
reassign?

 Thanks,
Rhonda

Bug#930037: irssi + mosh: badly rendered status lines

[Rhonda D'Vine]

Hey.

 what's yout TERM on the host, when you mosh to the server?  Is there
any tmux or screen involved?  Are both the server from which you mosh
out of and the remote server buster?  Or does a mosh to localhost work
there?

 This might be related: https://github.com/irssi/irssi/issues/753

 Thanks for additional information,
Rhonda

On 6/5/19 9:07 PM, Jakub Wilk wrote:
> Package: irssi,mosh,ncurses-base
> Version: irssi/1.2.0-2
> Version: mosh/1.3.2-2.1+b1
> Version: ncurses-base/6.1+20181013-2
> 
> After a stretch→buster upgrade, the blue status lines in Irssi are no
> longer displayed correctly; see the attached screenshots.
> 
> This seems to happen only under mosh.
> 
> Downgrading ncurses-base base to the stretch version
> (6.0+20161126-1+deb9u2) fixes it for me.
> 
> 
> -- System Information:
> Debian Release: 9.9
> Architecture: amd64 (x86_64)
> 

Bug#922667: beep: Error: could not open any device

[Rhonda D'Vine]

  Hey there. :)

On 3/12/19 5:13 PM, jim_p wrote:
> First of all, as soon as the package was updated to 1.4.3-2, I removed the
> upstream udev rule and let it use the provided one. I see there is a small
> difference between them, but I can not explain what that change actually does.
> The problem is that that difference, imho, makes beep partialy broken.

 The shipped udev rule is to allow local logged in users access to the
device.  Which is the common case, because you actually would want
people in front of the computer to be able to beep it, others usually
won't be able to hear it anyways.

 But yes, your case is something different, and for that the upstream
suggested approach might be feasible.  I though am not convinced that
special casing for every corner cases of the usage of the package is the
best move forward.  It would add quite some complexity, and added
dependency which I doubt that most people actually would benefit from.

 For those corner cases please create the beep group yourself and use
the upstream suggested udev rule.  Even if I would consider of adding
the complexity needed for that (through facilitating debconf for
questioning which kind of setup the admin would prefer) it would require
testing and needs time to make sure it doesn't interfer with other
things - and like said, would pull in another dependency.  And given
that we are now in freeze for buster time doesn't really permit that.

 If people have patches and merge requests that I could look at it might
improve the chances for that to happen, but it still would be something
for the next release.

> p.s. mini rant:
> I also noticed that the updated package still does not make the beep group, so
> it is one more step for the user to do.

 The beep group would only be needed when doing the acl dance that
upstream suggested.  Given that we don't do that there is no need to
create the group in the first place.

> Other packages do that all the time (that's why I still have a debian-tor 
> group
> although I have removed removed torbrowser ~2 years ago), so I don't think it
> will be hard or pointless to have a beep group as well. Special groups are
> mandatory for various reasons.

 The difference there is that torbrowser did actually use that group.
Which the beep package never did.  The older version of the package used
the existing audio group, which made a fair amount of sense to
facilitate for this.

> And, because I had a small discussion about it with a fellow (and more
> advanced) debian and beep user, if you consider a "security flaw" to have beep
> running as a non-root user, why package beep at all? Plus, if I have to do all
> that stuff by hand in order to make it "simply" work, why do I still have
> debian and not gentoo (or arch at the very least)?

 Just because something might expose information in specific usage
doesn't mean that it doesn't make sense for dedicated situations.  I
can't follow the reasoning that it would be beneficial to have it rather
not at all than to have it available for a specific environment.  I have
no idea what you try to achieve with that kind of argumentation?

 And it *does* simply work.  Just not for your special corner case,
which is unfortunate, but that requires a bit more work.  Depending on
acl, creating a dedicated group and shipping a rule that facilitates
that isn't that trivial to get right.  Otherwise I would assume you had
sent me already a patch for it, wouldn't you. :)

 Thanks for your interest in beep anyways, it's appreciated.
Rhonda

Bug#922763: Half of INSTALL.md belongs in PERMISSIONS.md

[Rhonda D'Vine]

   Hi!

On 2/20/19 1:45 AM, 積丹尼 Dan Jacobson wrote:
> NEWS.Debian.gz only mentions INSTALL.md,
> which doesn't mention PERMISSIONS.md .
> which in turn doesn't mention INSTALL.md. In fact the latter two should
> be combined... or put all permission discussion into PERMISSIONS.md only.

 Right - but that's upstream documentation, so please bring it up with
upstream on github directly, that would be really swift. :)

> README.Debian is now obsolete too, and should be removed, along with its
> mention on the man page.

 Thanks, done that now.  The manpage though mentions README.md and not
README.Debian, so that's fine.

> P.S., also mention in the docs what is wrong with simply doing
> # adduser norfleberry input

 If people want to shoot themselves in the leg, sure.  We also don't
document what's wrong with setting suid root on /bin/bash.  Permissions
always should be granted safely, and I don't believe in "coffee might be
hot" on cups safeguards.  Besides, the current approach with giving
local users access to beep shouldn't make anything along that lines needed.

 Cheers,
Rhonda

Bug#895115: Package does not seem to migrate to testing due to missing build on arm64

[Rhonda D'Vine]

   Hi!

On 2/27/19 8:52 AM, Andreas Tille wrote:
> I'm just pinging both RC bugs to reset the autoremoval from testing
> counter.  I just realised that the package might not migrate to testing
> due to a missing arm64 build.  I leave it to you to decide about the
> action to take but just wanted to prevent that you will be hit by an
> autoremoval which might have escaped your attention.

 Thanks.  The discussions about whether (and how) to add support to
automatically make beep available to non-root users did hold it back a
bit.  The patch for making it build on arm64 is prepared, I just wasn't
too sure what to do about the discussions on whether it's fine to leave
local adaption to the admin (and potentially improve the documentation
about it), or to offer support through the packaging for it.  Given that
an additional dependency on acl doesn't sound too encouraging, and
whether a TAG+="uaccess" might be more useful instead (which I haven't
tried yet), this sort of blocked my thoughts from just uploading the fix
so far.

 So .. thanks for the ping, will get around to it later today. :)
Rhonda

Bug#922667: beep: Error: could not open any device

[Rhonda D'Vine]

 Hi,

 do you have the acl package installed? Because the suggested udev rule
makes use of ACLs.  And after adding the udev rule you probably need to
restart because it only triggers on activating the device.

 So yes, the documentation could be better for the steps needed, and
we'll think about improving that.

 Personally I'm not too keen on adding an additional dependency on the
acl package, no matter how useful it is.  The main reason for the update
was to get the security issues fixed, and given the state of the release
making it extra comfortable for end users to get it working for regular
users instead of only for root wasn't the priority.

 I hope you can understand that.
Rhonda


On 2/20/19 8:36 AM, jim_p wrote:
> Package: beep
> Version: 1.4.3-1
> Followup-For: Bug #922667
> 
> Dear Maintainer,
> 
> I tried adding my user to the beep group, but nothing changed. Then I read
> everything in /usr/share/doc/beep/INSTALL.md and here are my thoughts,
> 
> Before adding my user to the beep group, I had to create that group. I did
> that, but still no beep. Why?
> 
> Because before making the group, I had to make the relevant udev rule. I
> created it too, I rebooted, bust still no beep. Why?
> 
> Because I also had to change the device permissions, but I have no idea how to
> to that. I tried whatever is suggested in the instructions but all I get is
> this bit
> 
> # ls -lH /dev/input/by-path/platform-pcspkr-event-spkr
> crw-rw 1 root input 13, 67 Feb 20 09:00 
> /dev/input/by-path/platform-pcspkr-
> event-spkr
> 
> # getfacl /dev/input/by-path/platform-pcspkr-event-spkr
> getfacl: Removing leading '/' from absolute path names
> # file: dev/input/by-path/platform-pcspkr-event-spkr
> # owner: root
> # group: input
> user::rw-
> group::rw-
> other::---
> 
> Maybe I am doing something wrong. But I think most, if not all, of this stuff
> can be ommited if you provide the udev rule, make the group and change the
> device permissions upon the install of the package.
> On top of that, I think all that setup is a tedius job for something that, for
> me at least, is used for a few milliseconds each time (I use beep to make an
> audible notification for when transmission-daemon completes a download). The
> 1.3.x version was literally plug-n-play, because, after installing it, I could
> use pcspkr with it instantly, with no extra setup at all.
> 
> 
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.19.0-3-amd64 (SMP w/2 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages beep depends on:
> ii  libc6  2.28-7
> 
> beep recommends no packages.
> 
> beep suggests no packages.
> 
> -- no debconf information
> 

Bug#922667: beep: Error: could not open any device

[Rhonda D'Vine]

Control: tag -1 - upstream
Control: severity -1 normal

   Hi.

On 2/19/19 6:46 AM, jim_p wrote:
> After today's upgrade to version 1.4.x, beep no longer works and pops the 
> above
> error. After checking its man page, I found out that it tries to access these
> devices, in that specific order
> 
> /dev/input/by-path/platform-pcspkr-event-spkr
> /dev/tty0
> /dev/vc/0
> 
> and although I have the 1st one (the pc speaker), beep does not seem to be 
> able
> to access it.
> If I am correct. from the new developer's page in github, I found out that
> there is this udev rule that needs to be present.
> 
> https://github.com/spkr-beep/beep/blob/master/90-pcspkr-beep.rules
> 
> If so, please add the above udev rule to your package.

 I would suggest to install the apt-listchanges package and/or read the
NEWS file that I added specifically about this.  For a start, this is
not an upstream bug, it's a packaging decision.  Secondly, it doesn't
render the package unusable, it can be used by root without any
troubles.  I'm not totally convinced that I want (or should) add the
udev rule.  It's on admin discretion to do so.

 I might consider it though.  I will have to update the package due to
build error on arm64 anyway.  Will locally try it out, but I'll discuss
it first with others if that is a reasonable approach, permission wise.

 Thanks for understanding,
Rhonda

Bug#922145: closed by Rhonda D'Vine (Bug#922145: fixed in irssi 1.2.0-2)

[Rhonda D'Vine]

   Hey,

On 2/14/19 3:24 PM, Diederik de Haas wrote:
> On woensdag 13 februari 2019 15:51:04 CET you wrote:
>> #922145: irssi: trying to overwrite '/usr/share/irssi/help/otr', which is
>> also in package irssi-plugin-otr
>>
>> It has been closed by Rhonda D'Vine .
> 
> I think it's not actually fixed as I just got the error again.
> Now with version 1.2.0-2, but 'the other way around'.

 Yes, that's correct.  When fixing it in -2 I didn't do the things with
respect to Breaks+Replaces, and given that this affects only people
upgrading from 1.2.0-1 to 1.2.0-2 I consider it an acceptable tradeoff
to not roll out a -3. The -1 was only a bit more than half a day in the
archive, so ...

 So upgrading from testing (or former stable) to the 1.2.0 packages
should work without any troubles yet.  I'll specifically try that out,
especially also with respect to partial upgrades (like, only -otr
package, only irssi, both at the same times), and if something still
pops up I'll do the Breaks+Replaces dance. :)

 Cheers,
Rhonda

Bug#922272: irssi-plugin-otr: trying to overwrite '/usr/share/irssi/help/otr', which is also in package irssi 1.2.0-1

[Rhonda D'Vine]

 Hi,

 you are right, but: This issue exists only with upgrade from the broken
1.2.0-1 package.  Which isn't available anymore, it was there for way
less than a day.  I am much more leaning towards a "wontfix" than doing
the Replaces & Conflicts dance and carry that for ... when would then be
practical to remove it again?  It doesn't affect upgrades from anything
available right now already.

 Are you fine with ignoring this as an unfortunate side-effect for an
issue that only existed in 1.2.0-1 which was available less than 13 hours?

 Thanks,
Rhonda


On 2/14/19 1:11 AM, Axel Beckert wrote:
> Package: irssi-plugin-otr
> Version: 1.2.0-1
> Severity: serious
> 
> Hi Rhonda,
> 
> unfortunately the file moving between irssi and irssi-plugin-otr doesn't
> seem to completely fixed yet. When upgrading them from 1.2.0-1 to
> 1.2.0-2, I get:
> 
> Preparing to unpack .../04-irssi-plugin-otr_1.2.0-2_amd64.deb ...
> Unpacking irssi-plugin-otr (1.2.0-2) over (1.2.0-1) ...
> dpkg: error processing archive 
> /tmp/apt-dpkg-install-dVLCdE/04-irssi-plugin-otr_1.2.0-2_amd64.deb (--unpack):
>  trying to overwrite '/usr/share/irssi/help/otr', which is also in package 
> irssi 1.2.0-1
> Preparing to unpack .../05-irssi_1.2.0-2_amd64.deb ...
> Unpacking irssi (1.2.0-2) over (1.2.0-1) ...
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), 
> (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), 
> (1, 'buildd-experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
> LSM: AppArmor: enabled
> 
> Versions of packages irssi-plugin-otr depends on:
> ii  irssi1.2.0-2
> ii  libc62.28-7
> ii  libgcrypt20  1.8.4-5
> ii  libotr5  4.1.1-3
> 
> irssi-plugin-otr recommends no packages.
> 
> irssi-plugin-otr suggests no packages.
> 
> -- no debconf information
> 

Bug#922145: irssi: trying to overwrite '/usr/share/irssi/help/otr', which is also in package irssi-plugin-otr

[Rhonda D'Vine]

 Hi!

On 2/12/19 5:25 PM, Diederik de Haas wrote:
> Got an update for version 1.2.0-1, but I also have irssi-plugin-otr
> installed, which resulted in the following upgrade error:
> 
> # aptitude safe-upgrade
> The following packages will be upgraded:
>   bind9-host dnsutils irssi irssi-plugin-otr 
> ...
> Get: 16 http://httpredir.debian.org/debian sid/main amd64 irssi amd64 1.2.0-1 
> [1,178 kB]
> Get: 17 http://httpredir.debian.org/debian sid/main amd64 irssi-plugin-otr 
> amd64 1.2.0-1 [480 kB]
> ...
> Preparing to unpack .../09-irssi_1.2.0-1_amd64.deb ...
> Unpacking irssi (1.2.0-1) over (1.1.2-1) ...
> dpkg: error processing archive 
> /tmp/apt-dpkg-install-9iSR4c/09-irssi_1.2.0-1_amd64.deb (--unpack):
>  trying to overwrite '/usr/share/irssi/help/otr', which is also in package 
> irssi-plugin-otr:amd64 1.0.2-4+b1

 Good catch - sorry for the inconvenience!  What you can do as a
workaround: First upgrade irssi-plugin-otr and then install irssi.  Or
somehow force-install it with dpkg.  I'll roll out a -2, and I'm sorry
that I missed that part.  The helpfile will move over to the
irssi-plugin-otr package.

 Enjoy,
Rhonda

Bug#920264: postfixadmin: please add postfixadmin-cli to PATH

[Rhonda D'Vine]

Package: postfixadmin
Version: 3.0.2-2
Severity: wishlist

Dear Maintainer,

 I've stumbled upon /usr/share/postfixadmin/scripts/postfixadmin-cli
mostly through it getting mentioned on IRC.  It would be helpful if that
script is already available directly.  It doesn't even has execute
permissions set there, so one would have to call it through bash.

 Probably putting it into /usr/sbin given that it needs access to files
not readable by the general user.

 Thanks :)
Rhonda

Bug#917422: python3-buildbot: TimeoutStartSec=5 in service file is too short

[Rhonda D'Vine]

Source: buildbot
Version: 1.6.0-1
Severity: minor

Dear Maintainer,

I have a fair amount of packages (currently 54 but increasing) for which
to create builders.  So I chose to write a short loop in the master.cfg
that does append to the builders with a few steps (git checkout, and
four shell commands).  That was enough that starting the service ran
into the timeout that is set in the service file.

 Could you potentially remove that timeout, or increase it to a
reasonable bigger size that would fit with bigger installments than just
a few builders?  That would be really nice.  Having to override it with
a custom service file is somehow working against having the service file
shipped by the package.

 Thanks,
Rhonda

Bug#915050: (gitlab) Re: Bug#915050: Keep out of testing

[Rhonda D'Vine]

Hey,

* Pirate Praveen  [2018-12-18 09:34:46 CET]:
> On 12/3/18 8:11 PM, Dominik George wrote:
> >> well, Debian is using gitlab!!! so this sentence has no sense. The
> >> problem here
> >> is that is a complex software that depends of a lot of pieces and it's
> >> not
> >> easy/possible to fit the definition. So, maybe we should create another
> >> category
> >> of software.
> > 
> > Yes, and that Debian officially uses GitLab, from a foreign source, without 
> > being able to support it in Debian, does make me feel ashamed for the 
> > project.
> > 
> >> maybe creating another kind of repo. debian-contributuions
> >> debian-blabla, whatever.
> >>
> > 
> > We had volatile, which, redefined properly, could help. I am trying to 
> > draft such a definition.
> 
> Did you get a chance to work on it?

 Yes, it looks very much that the shutting down of volatile made wishes
appear for backports to cover it - while it wasn't (and shouldn't) be
the scope for it.  It would make it indistinguishable which packages
within backports are following the regular rules and which would be
those fast moving targets without any useful tracking or upgrade
features in the regular sense.

 (Part of that was btw. also the creation of a seperate sloppy pocket
for backports from oldstable+2 releases, to make it clear what to expect
in there)

 And yes, I'm with Alexander, the volatile maintenance can't be dumped
on the backports team.  It's a different workflow anyway.

 Good luck,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#916112: apt-get purge filename.deb not working like expected

[Rhonda D'Vine]

Package: apt
Version: 1.8.0~alpha2
Severity: minor

Dear Maintainer,

 apt-get is great to install packages.  Especially when the package at
hand is locally lying around on the harddisk.  It even resolves
dependencies through its algorithm.

 So far, so good.  What I tried after an "apt-get -y install ./foo.deb"
was an "apt-get -y purge ./foo.deb" to see if it might work too.  It
seemingly is able to figure out the package name, because it gives these
messages:

#v+
Note, selecting 'irssi-build-deps' instead of 
'./irssi-build-deps_1.1.1-1_all.deb'
irssi-build-deps is already the newest version (1.1.1-1).
#v-

 It seemingly is able to figure out the package name from the given
filename, but then seems to have forgotten that a purge was requested,
not an install, which feels a bit weird.

 (Background of this is some auto package building that I want to set up
and need to purge the build-dependencies afterwards again, and the basis
is just the filename that mk-buid-deps created.  Probably not the wisest
approach, and I'll look into other ways to do it, but this made me
stumble upon this. :))

 Hope that helps,
Rhonda

Bug#912336: pu: package wesnoth-1.12/1:1.12_1.12.6-1+deb9u1

[Rhonda D'Vine]

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

 Hi,

 for fixing CVE-2018-1999023 (see #911950 removal request ...) I propose
the following upload and would like to receive an ACK for uploading the
fixed package.

 Find here the corresponding debdiff.  It was commited to a dedicated
stretch branch on salsa too:
-> https://salsa.debian.org/games-team/wesnoth/commit/bef5679dd

 This corresponds directly to the upstream fix of the issue here:
-> https://github.com/wesnoth/wesnoth/commit/d911268a

 Thanks in advance for considering.  I'll add this bug number into the
changelog before uploading instead of the removal request one, which
makes more sense. :)

 Enjoy,
Rhonda


#v+
diff -Nru wesnoth-1.12-1.12.6/debian/changelog 
wesnoth-1.12-1.12.6/debian/changelog
--- wesnoth-1.12-1.12.6/debian/changelog2016-05-21 08:48:55.0 
+0200
+++ wesnoth-1.12-1.12.6/debian/changelog2018-10-30 10:53:02.0 
+0100
@@ -1,3 +1,10 @@
+wesnoth-1.12 (1:1.12.6-1+deb9u1) stretch; urgency=low
+
+  * Security fix: disallow loading lua bytecode via load/dofile
+(CVE-2018-1999023, closes: #911950)
+
+ -- Rhonda D'Vine   Tue, 30 Oct 2018 10:53:02 +0100
+
 wesnoth-1.12 (1:1.12.6-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru wesnoth-1.12-1.12.6/debian/patches/04CVE-2018-1999023 
wesnoth-1.12-1.12.6/debian/patches/04CVE-2018-1999023
--- wesnoth-1.12-1.12.6/debian/patches/04CVE-2018-1999023   1970-01-01 
01:00:00.0 +0100
+++ wesnoth-1.12-1.12.6/debian/patches/04CVE-2018-1999023   2018-10-30 
10:53:02.0 +0100
@@ -0,0 +1,68 @@
+Author: gfgtdf vim:ft=diff:
+Description: disallow loading lua bytecode via load/dofile (CVE-2018-1999023)
+Origin: upstream, https://github.com/wesnoth/wesnoth/commit/d911268
+
+--- a/src/ai/lua/core.cpp
 b/src/ai/lua/core.cpp
+@@ -913,7 +913,7 @@
+ 
+ lua_ai_context* lua_ai_context::create(lua_State *L, char const *code, 
ai::engine_lua *engine)
+ {
+-  int res_ai = luaL_loadstring(L, code);//stack size is now 1 [ -1: 
ai_context]
++  int res_ai = luaL_loadbufferx(L, code, strlen(code), /*name*/ code, 
"t"); // [-1: AI code]
+   if (res_ai)
+   {
+ 
+@@ -943,7 +943,7 @@
+ 
+ lua_ai_action_handler* lua_ai_action_handler::create(lua_State *L, char const 
*code, lua_ai_context )
+ {
+-  int res = luaL_loadstring(L, code);//stack size is now 1 [ -1: f]
++  int res = luaL_loadbufferx(L, code, strlen(code), /*name*/ code, 
"t");//stack size is now 1 [ -1: f]
+   if (res)
+   {
+   char const *m = lua_tostring(L, -1);
+--- a/src/lua/lbaselib.cpp
 b/src/lua/lbaselib.cpp
+@@ -310,16 +310,17 @@
+   size_t l;
+   const char *s = lua_tolstring(L, 1, );
+   const char *mode = luaL_optstring(L, 3, "bt");
++  (void) mode;
+   int env = (!lua_isnone(L, 4) ? 4 : 0);  /* 'env' index or 0 if no 'env' */
+   if (s != NULL) {  /* loading a string? */
+ const char *chunkname = luaL_optstring(L, 2, s);
+-status = luaL_loadbufferx(L, s, l, chunkname, mode);
++status = luaL_loadbufferx(L, s, l, chunkname, "t");
+   }
+   else {  /* loading from a reader function */
+ const char *chunkname = luaL_optstring(L, 2, "=(load)");
+ luaL_checktype(L, 1, LUA_TFUNCTION);
+ lua_settop(L, RESERVEDSLOT);  /* create reserved slot */
+-status = lua_load(L, generic_reader, NULL, chunkname, mode);
++status = lua_load(L, generic_reader, NULL, chunkname, "t");
+   }
+   return load_aux(L, status, env);
+ }
+--- a/src/scripting/lua.cpp
 b/src/scripting/lua.cpp
+@@ -1052,7 +1052,7 @@
+   //lua uses '@' to know that this is a file (as opposed to a 
something as opposed to something loaded via loadstring )
+   std::string chunkname = '@' + fname;
+   LOG_LUA << "starting to read from " << fname << "\n";
+-  return  lua_load(L, _filestream::lua_read_data, , 
chunkname.c_str(), NULL);
++  return  lua_load(L, _filestream::lua_read_data, , 
chunkname.c_str(), "t");
+   }
+ private:
+   char buff_[LUAL_BUFFERSIZE];
+@@ -4239,7 +4239,9 @@
+   lua_State *L = mState;
+ 
+   // Compile script into a variadic function.
+-  int res = luaL_loadstring(L, prog);
++  // pass 't' to prevent loading bytecode which is unsafe and can be used 
to escape the sandbox.
++  // todo: maybe allow a 'name' parameter to give better error messages.
++  int res = luaL_loadbufferx(L, prog, strlen(prog), /*name*/ prog, "t");
+   if (res)
+   {
+   char const *m = lua_tostring(L, -1);
diff -Nru wesnoth-1.12-1.12.6/debian/patches/series 
wesnoth-1.12-1.12.6/debian/patches/series
--- wesnoth-1.12-1.12.6/debian/patches/series   2014-11-24 10:27:24.0 
+0100
+++ wesnoth-1.12-1.12.6/debian/patches/series   2018-10-30 10:29:29.0 
+0100
@@ -1,2 +1,3 @@
 02wesnoth-nolog-desktop-file
 03wesnothd-name
+04CVE-2018-1999023
#v-

Bug#911157: lintian: complain about grepping the passwd/group file instead of using getent

[Rhonda D'Vine]

* Chris Lamb  [2018-10-16 17:05:17 CEST]:
> Dear Rhonda,
> 
> Thank you for filing this.

 Sure, no worries. :)

> > https://sources.debian.org/src/proftpd-dfsg/1.3.5d-1/debian/proftpd-basic.postinst/?hl=28#L28
> > is an example from our pool, but there are more.
> 
> This example:
> 
>   https://github.com/FRRouting/frr/blob/master/debianpkg/frr.postinst#L4-L9
> 
> … is also relevant but may not be as-reliably detectable.

 It's nice that you come to the same conclusion about the same code
snippet that I mentioned in my original mail, let me quote myself. :)

,> original bugreport <
|  The package where I stumbled upon this had the code a bit more complex,
| I'm unsure how this might be detectable:
| 
| #v+
| PASSWDFILE=/etc/passwd
| GROUPFILE=/etc/group
| 
| frruid=`egrep "^frr:" $PASSWDFILE | awk -F ":" '{ print $3 }'`
| frrgid=`egrep "^frr:" $GROUPFILE | awk -F ":" '{ print $3 }'`
| frrvtygid=`egrep "^frrvty:" $GROUPFILE | awk -F ":" '{ print $3 }'`
| #v-
`> original bugreport <

 So, yes, we seem to agree on that. :)

> However, to
> quote IRC:
> 
>   * h01ger agrees that any reference to /etc/passwd or /etc/group is
> very probably a bug

 Right, though some packages (shadow comes to mind?) might refer to it
with good reasons.  But I'm sure you can check that in lintian labs for
false positives.

 When I look into
https://salsa.debian.org/lintian/lintian/commit/8cbfd096b0 though:

~\b(grep\b.*/etc/(?:passwd|group))\b

 I'm not completely sure about the syntax here, but the \b before the
bracket looks like it wouldn't catch egrep - which is used in the above
example (although it's using a variable instead of the filename so it
wouldn't catch it anyway - but if it would use the filename ... would
that match?

 Enjoy,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#911157: lintian: complain about grepping the passwd/group file instead of using getent

[Rhonda D'Vine]

Package: lintian
Severity: wishlist

Dear Maintainer,

 I was prodded by Lamby to file this bugreport. :)  I noticed in a
package (not yet in Debian) that it uses grep on the passwd/group file
directly instead of using getent.  This hinders detecting users stored
in a different database.

 Given that this still seems to exist within Debian packages from a
quick code search, it would be useful to have that reported.
https://sources.debian.org/src/proftpd-dfsg/1.3.5d-1/debian/proftpd-basic.postinst/?hl=28#L28
is an example from our pool, but there are more.

 The package where I stumbled upon this had the code a bit more complex,
I'm unsure how this might be detectable:

#v+
PASSWDFILE=/etc/passwd
GROUPFILE=/etc/group

frruid=`egrep "^frr:" $PASSWDFILE | awk -F ":" '{ print $3 }'`
frrgid=`egrep "^frr:" $GROUPFILE | awk -F ":" '{ print $3 }'`
frrvtygid=`egrep "^frrvty:" $GROUPFILE | awk -F ":" '{ print $3 }'`
#v-

 But for the above example a "grep .* /etc/(passwd|group)" or something
along that lines might be a good starting point.

 Enjoy,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#906318: www.debian.org: Language Stats page completely broken

[Rhonda D'Vine]

Hey Helge,

* Helge Kreutzmann  [2018-08-17 08:11:58 CEST]:
> Until yesterday (at least to my knowledge) the langauge stats page was
> outdated, but (hopefully) complete:
> https://www.debian.org/international/l10n/po-debconf/de

 while I can't comment on what's going on there (haven't digged into it
yet), one thing confused me:

> It would be great if this could be fixed ASAP as the freeze comes
> close and this page is a very valuable ressource to determine where
> work is still needed.

 What freeze is coming close?  Did I miss some release team update?
Last I've heard about the freeze was in april and it stated:

 * 2019-01-12 - Transition freeze

 To the best of my knowledge this hasn't changed since?  Or do you mean
that this is already a close timeframe?  Just to be sure we are speaking
of the same freeze times. :)

 Enjoy,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#904545: dw: irssi-plugin-otr_1.0.2-4 irssi-plugin-robustirc_0.6-4 irssi-plugin-xmpp_0.54-2

[Rhonda D'Vine]

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

 Hi,

 please binNMU the irssi plugins for the last irssi upload.  I did a local test
build to confirm that they don't need any source change.

 So long,
Rhonda

dw irssi-plugin-otr_1.0.2-4 . ANY . unstable . -m "irssi-dev (>= 1.1.1-1)"
dw irssi-plugin-robustirc_0.6-4 . ANY . unstable . -m "irssi-dev (>= 1.1.1-1)"
dw irssi-plugin-xmpp_0.54-2 . ANY . unstable . -m "irssi-dev (>= 1.1.1-1)"

Bug#894667: beep: CVE-2018-0492

[Rhonda D'Vine]

 So people are falling for a fake page that is not even well disguised, apply a 
patch from there and now worry about being exploited?  Call me unimpressed, but 
what is expected to be done about that?

 Please, only get your patches through trusted sources, not from windy websites 
that just look shiny on the surface. I can just say well played, holeybeep 
people.

 Enjoy,
Rhonda

Am 5. April 2018 22:46:05 MESZ schrieb Anders Kaseorg :
>On Thu, 5 Apr 2018, Tony Hoyle wrote:
>> It's concerning that the holeybeep.ninja site exploited an unrelated 
>> fault for 'fun' without apparently telling anyone.
>
>To be fair, they told you exactly what was going to happen: “Apply this
>
>[patch] as soon as possible using the following command: patch -p1 < 
>beep.diff. A short beep should be heard if all hunks are applied 
>successfully.”
>
>Anders

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Bug#893980: www.debian.org: Many mirrors have no or untrusted HTTPS certificates

[Rhonda D'Vine]

* Paul Wise <p...@debian.org> [2018-03-26 15:52:45 CEST]:
> On Mon, Mar 26, 2018 at 9:39 PM, Rhonda D'Vine wrote:
> > * Martin Monperrus:
> >> Would it make sense to keep track of valid https support for the
> >> secondary mirrors?
> >
> >  Actually the issue still holds: The mirror team needs to repoint
> > mirrors to other servers at times and thus the certificate there
> > wouldn't include those redirected mirrors.
> 
> The mirror team don't control the DNS for secondary mirrors. The
> individual mirror admins could be doing that, but it seems unlikely to
> me.

 Right, but DNS for the primary ones, and pointing them towards a server
that isn't under their control would mean that they'd have to carry a
*.debian.org wildcard certificate.  Which won't happen for non-DSA
operated infrastructure.

> > I am aware that there is a privacy concern involved, like what packages
> > get downloaded, but appart from that that's the only knowledge to gain
> > from unencrypted http traffic.
> 
> https doesn't provide protection against correlation of download size
> to packages downloaded, so it doesn't have much advantage over http
> for package download privacy.

 Ah, right, forgot about that point.  So even that point is moot.
Thanks for pointing that out. :)

 Enjoy,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#893980: www.debian.org: Many mirrors have no or untrusted HTTPS certificates

[Rhonda D'Vine]

   Hi Martin,

* Martin Monperrus  [2018-03-26 11:54:12 CEST]:
> Hi Pabs,
> 
> > The Debian mirror team don't keep track of https support for the
> > secondary mirrors
>
> Would it make sense to keep track of valid https support for the
> secondary mirrors?

 Actually the issue still holds: The mirror team needs to repoint
mirrors to other servers at times and thus the certificate there
wouldn't include those redirected mirrors.

 I am aware that there is a privacy concern involved, like what packages
get downloaded, but appart from that that's the only knowledge to gain
from unencrypted http traffic. apt itself does verify the packages
through the locally installed keychain and the checksums through the
signed Release file, so injecting other packages isn't really an issue
AIUI.  Given that the release file also has a date stored and TTBOMK apt
warns about aged release files it shouldn't be much of an issue to sneak
in an older Release file.

 At least the explenation that I picked up when this was asked before
went along those lines.  Guess if I understood it wrongly I'll get
corrected on it.

 Enjoy,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#888264: libicu57: issues with NumberFormatter and locales

[Rhonda D'Vine]

Package: libicu57
Version: 57.1-6+deb9u1
Severity: normal

Dear Maintainer,

 we have troubles using the NumberFormatter from php which uses libicu to
format strings according to locale.  From what I can tell this is a regress
in ICU from jessie to stretch.

 This is a short testing snippet that failed for us:

:~$ cat test-formatter.php
format('100'));
$numberFormatter = new NumberFormatter('de-DE',
NumberFormatter::DECIMAL);
var_dump($numberFormatter->format('100'));
$numberFormatter = new NumberFormatter('en-US',
NumberFormatter::DECIMAL);
var_dump($numberFormatter->format('100'));
:~$ php -f test-formatter.php
string(11) "1 000 000"
string(9) "1.000.000"
string(9) "1,000,000"

 Thing is, for de-AT the same output than for de-DE is expected, but not given.
This worked with the version in jessie.

 Why do I think this is a regression in ICU and not in php? We have tried
the php packages from sury.org and it doesn't change anything regardless of
which php version we are using, may it be php5 or php7. It works on jessie
(we bet "1.000.000" for de-AT there too) but doesn't work anymore on
stretch.

 What I see here:

symbols{
group{" "}
}

https://ssl.icu-project.org/repos/icu/icu/tags/release-57-1/source/data/locales/de_AT.txt

 This might be the culprit - it wasn't there in 52.  Though, I can't find
that anywhere within the Debian source, where would that be, I would like
to try out a test build that could fix the issue for us locally.

 I can find that it was done in upstream changeset 37836, but the log
message "CLDR 28 data integration" doesn't really enlighten me. The
mergeinfo changesets neither.

 Do you have any contact with emmons or know how dig further through their
trac to find out where this might have came from because the change doesn't
make much sense to me and I'd like to know the reasoning behind this
change, it's causing troubles for our application.

 Thanks in advance,
Rhonda

Bug#831435: www.debian.org: Link to the patch tracker broken

[Rhonda D'Vine]

Hi,

 I currently can't deploy it but will keep it in mind for later.

 Though:

* Orestis Ioannou  [2016-07-16 00:36:03 CEST]:
> The URL for the patch tracker changed slightly hence the links towards
> sources.debian.net/patches are broken.
> I.e when you are at https://packages.debian.org/stretch/python-pip
> the link to the Debian Patch Tracker is
> http://sources.debian.net/patches/summary/python-pip/8.1.2-2/
> but the correct one is http://sources.debian.net/patches/python-pip/8.1.2-2/

 If such URL schemes are changed they break not only the packages site
but all external links pointing to it.  It is good to get the links in
the sites linking to it corrected - but it would be also very useful to
add a redirect that handles that; from what I can see only the /summary/
part of the URL got removed?  That should be doable in a single redirect
line and unbreak all the external links, not only the packages website.

 I'm not questioning the need for the need in the change, there for sure
is good reasons behind that, but please add defensive redirects for such
cases. :)  Not sure if you are involved with the patch tracker, I
dropped the note also in the #debian-qa IRC channel, from what I can
tell the patch tracker is in the field of the QA team.

 Enjoy,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#870659: pu: package irssi/1.0.2-1+deb9u2

[Rhonda D'Vine]

* Adam D. Barratt <a...@adam-barratt.org.uk> [2017-08-03 23:34:18 CEST]:
> Control: tags -1 + stretch moreinfo
> 
> On Thu, 2017-08-03 at 22:13 +0200, Rhonda D'Vine wrote:
> >  for fixing #867598 in stable I prepared a 1.0.2-1+deb9u2 update for
> > irssi.  Please find the debdiff attached.
> 
> Apparently not. :)

 Darn.  I really need more caffein, but people won't bring it to me in
the Garden. :)

 Find it attached this time, for sure.
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|
diff -Nru irssi-1.0.2/debian/changelog irssi-1.0.2/debian/changelog
--- irssi-1.0.2/debian/changelog	2017-06-17 09:21:44.0 -0400
+++ irssi-1.0.2/debian/changelog	2017-08-03 15:59:51.0 -0400
@@ -1,3 +1,11 @@
+irssi (1.0.2-1+deb9u2) stretch; urgency=high
+
+  * Security related update pulling upstream 5e26325317 (closes: 867598):
+- Fix null pointer dereference (CVE-2017-10965)
+- Fix use-after-free condition for nicklist (CVE-2017-10966)
+
+ -- Rhonda D'Vine <rho...@debian.org>  Thu, 03 Aug 2017 15:59:51 -0400
+
 irssi (1.0.2-1+deb9u1) stretch-security; urgency=high
 
   * Non-maintainer upload by the Security Team.
diff -Nru irssi-1.0.2/debian/patches/28Fix-use-after-free-and-null-pointer-dereference.patch irssi-1.0.2/debian/patches/28Fix-use-after-free-and-null-pointer-dereference.patch
--- irssi-1.0.2/debian/patches/28Fix-use-after-free-and-null-pointer-dereference.patch	1969-12-31 19:00:00.0 -0500
+++ irssi-1.0.2/debian/patches/28Fix-use-after-free-and-null-pointer-dereference.patch	2017-08-03 15:59:51.0 -0400
@@ -0,0 +1,72 @@
+From 29ebac987da1da2c892aed5ed329256b7bc94bca Mon Sep 17 00:00:00 2001
+From: Nei <ailin.ne...@gmail.com>
+Date: Thu, 29 Jun 2017 13:48:44 +
+Subject: [PATCH 1/2] Check return value of localtime
+
+Fixes #10
+---
+ src/core/misc.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/src/core/misc.c b/src/core/misc.c
+index ce49925b1..0b2d8e776 100644
+--- a/src/core/misc.c
 b/src/core/misc.c
+@@ -560,6 +560,9 @@ char *my_asctime(time_t t)
+ int len;
+ 
+ 	tm = localtime();
++	if (tm == NULL)
++	return g_strdup("???");
++
+ 	str = g_strdup(asctime(tm));
+ 
+ 	len = strlen(str);
+
+From 73b851c39c11d01199e6c040749fb20e468f6c8d Mon Sep 17 00:00:00 2001
+From: ailin-nemui <ailin-ne...@users.noreply.github.com>
+Date: Tue, 4 Jul 2017 16:10:55 +0200
+Subject: [PATCH 2/2] correct GHashTable usage
+
+---
+ src/core/nicklist.c | 17 ++---
+ 1 file changed, 10 insertions(+), 7 deletions(-)
+
+diff --git a/src/core/nicklist.c b/src/core/nicklist.c
+index 54dfb5fb2..0bc88ab8d 100644
+--- a/src/core/nicklist.c
 b/src/core/nicklist.c
+@@ -54,23 +54,26 @@ static void nick_hash_add(CHANNEL_REC *channel, NICK_REC *nick)
+ 
+ static void nick_hash_remove(CHANNEL_REC *channel, NICK_REC *nick)
+ {
+-	NICK_REC *list;
++	NICK_REC *list, *newlist;
+ 
+ 	list = g_hash_table_lookup(channel->nicks, nick->nick);
+ 	if (list == NULL)
+ 		return;
+ 
+-	if (list == nick || list->next == NULL) {
+-		g_hash_table_remove(channel->nicks, nick->nick);
+-		if (list->next != NULL) {
+-			g_hash_table_insert(channel->nicks, nick->next->nick,
+-	nick->next);
+-		}
++	if (list == nick) {
++		newlist = nick->next;
+ 	} else {
++		newlist = list;
+ 		while (list->next != nick)
+ 			list = list->next;
+ 		list->next = nick->next;
+ 	}
++
++	g_hash_table_remove(channel->nicks, nick->nick);
++	if (newlist != NULL) {
++		g_hash_table_insert(channel->nicks, newlist->nick,
++newlist);
++	}
+ }
+ 
+ /* Add new nick to list */
diff -Nru irssi-1.0.2/debian/patches/series irssi-1.0.2/debian/patches/series
--- irssi-1.0.2/debian/patches/series	2017-06-17 09:21:44.0 -0400
+++ irssi-1.0.2/debian/patches/series	2017-08-03 15:59:51.0 -0400
@@ -10,3 +10,4 @@
 25tls-ssl-compat-defines
 26Fix-dcc_request-where-addr-is-NULL.patch
 27Fix-oob-read-of-one-byte-in-get_file_params_count-_r.patch
+28Fix-use-after-free-and-null-pointer-dereference.patch

Bug#870659: pu: package irssi/1.0.2-1+deb9u2

[Rhonda D'Vine]

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

Hi,

 for fixing #867598 in stable I prepared a 1.0.2-1+deb9u2 update for
irssi.  Please find the debdiff attached.

 Thanks for considering,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#870655: /usr/share/polygen/eng/debian/autopolygen.grm: please use polyrun instead of polygen in the autopolygen grammar

[Rhonda D'Vine]

Package: polygen-data
Version: 1.0.6.ds2-15
Severity: normal
File: /usr/share/polygen/eng/debian/autopolygen.grm

Dear Maintainer,

 the autopolygen grammar spits out nice commands to run - unfortunately they
don't.  polygen can't be called (anymore) by just giving a grammar name, so the
tool polyrun got introduced.  Unfortunately at that time the autopolygen
grammar wasn't adjusted to use polyrun instead.

 Guess that should be an easy fix. :)

 Enjoy!
Rhonda

Bug#864427: pu: package irssi/1.0.2-1+deb9u1

[Rhonda D'Vine]

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

   Hi,

 a crash got noticed in irssi, and the patch for it is quite minimal:
https://github.com/irssi/irssi/commit/fb08fc7f1aa6b2e616413d003bf021612301ad55

 I'd run that into stretch, but given the state of the release I'm not
so sure about how to approach it for now.  Shall I wait with pushing the
update until the release, or can I push it but it won't get accepted for
now, only after the release?

 Would be nice to get some suggestions on timing when and where to push.

 Thanks in advance,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#862324: /usr/bin/debrsign: debrsign doesn't copy buildinfo file

[Rhonda D'Vine]

Package: devscripts
Version: 2.17.5
Severity: important
File: /usr/bin/debrsign

Dear Maintainer,

 debrsign doesn't support buildinfo files and thus fails to sign
changes files properly currently.

 Enjoy,
Rhonda

Bug#861637: sassphp: src:sassphp explicitly creates a php7.0 binary package

[Rhonda D'Vine]

Hi there,


Am Montag, den 01.05.2017, 21:42 -0700 schrieb Nishanth Aravamudan:
> Package: sassphp
> Version: 0.5.10-2
> Severity: normal
> 
> It would appear that sassphp doesn't follow many other PHP packages
> and
> explicitly names it's binary package php7.0-sassphp rather than
> php-sassphp. This requires renaming the binary package and explicitly
> adding transitional changes for upgraders as the PHP version changes.

 I've ssen both name schemata being used and wasn't able to figure out
a pattern behind it unfortunately, and didn't find a documentation
along the lines unfortunately. There are also many other PHP packages
that start with php7.0-*, and unfortunately I settled for the wrong
naming scheme.

 On the other hand, given that the package only lives in unstable I
don't see the need for a transitional package.  It wasn't part of any
release and thus I think adding the complexity isn't needed.  Users of
unstable are meant to be able to deal with such things.

> Can sassphp be modified to be like other PHP packages and generate
> php-sassphp?

 Sure.  Can you maybe point me to the documentation on that guideline
so I can avoid it in the future?  I really looked at the package in the
pool, couldn't figure out what the default schema is meant to be, asked
around ...  Mistakes happen, so very much thanks for your report and
the possibility to fix this. :)

 Enjoy,
Rhonda

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

Bug#860723: vim-runtime: documentation bug in term.txt

[Rhonda D'Vine]

Package: vim-runtime
Version: 2:7.3.547-7+deb7u3
Severity: minor

Dear Maintainer,

 while trying to figure out why I don't get rgb color support in vim
inside tmux I stumbled upon a documentation bug. :)

 in term.txt there are these two lines:

 let _8f = "\[38:2:%lu:%lu:%lum"
 let _8b = "\[48:2:%lu:%lu:%lum"

 Actually, after 38 and 48 there should be a semicolon instead of a
colon.  I figured out that part with setting xterm-256color (which
worked) and screen-256color (which didn't, had it set to empty, which is
set inside tmux as default).

 Now I don't know if it is a vim bug that t_8f and t_8b are empty when
therm is screen-256color (I still have to figure out why that is), but
the documentation bug for those values in term.txt should definitely get
fixed. :)

 Enjoy,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#858426: unblock: tworld/1.3.2-3

[Rhonda D'Vine]

Hi,

* Andreas Beckmann  [2017-03-23 00:45:53 CET]:
> 1.3.2-3~ is already smaller than 1.3.2-3~bpo*

 You are of course right, not sure what way my thoughts were going at
that time.

> >  Actually I would assume most packages using that with only one tilde
> > didn't think about it, and I haven't even found any hint or
> > documentation that even suggests a single ~.
> 
> dpkg-maintscript-helper(1)

 Thanks, also not sure how I missed that part.

 But I doubt that that is really a reason to re-upload it, do you see
any way that second ~~ in there could have any side effect?

 Enjoy,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#858426: unblock: tworld/1.3.2-3

[Rhonda D'Vine]

   Hi,

* Emilio Pozuelo Monfort <po...@debian.org> [2017-03-22 18:24:38 CET]:
> On 22/03/17 10:48, Rhonda D'Vine wrote:
> > diff -Nru tworld-1.3.2/debian/tworld.maintscript 
> > tworld-1.3.2/debian/tworld.maintscript
> > --- tworld-1.3.2/debian/tworld.maintscript  1970-01-01 01:00:00.0 
> > +0100
> > +++ tworld-1.3.2/debian/tworld.maintscript  2017-03-22 09:54:26.0 
> > +0100
> > @@ -0,0 +1 @@
> > +symlink_to_dir /usr/share/doc/tworld tworld-data 1.3.2-3~~
>^^
> one ~ too many?

 Not really.  You would need two ~ to be able to produce a backport and
have it work there too.  So 1.3.2-3~~ is smaller than 1.3.2-3~bpo*. Not
that I plan to do it for tworld, but actually it's the safe thing to do.

 Actually I would assume most packages using that with only one tilde
didn't think about it, and I haven't even found any hint or
documentation that even suggests a single ~.

 So long, and thanks for paying attention to details. :)
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#858447: ITP: sassphp -- PHP bindings to libsass - fast, native Sass parsing in PHP

[Rhonda D'Vine]

Package: wnpp
Severity: wishlist
Owner: Rhonda D'Vine <rho...@strg.at>

* Package name: sassphp
  Version : 0.5.10
  Upstream Author : Jamie Rumbelow
* URL : https://github.com/absalomedia/sassphp
* License : MIT
  Programming Lang: PHP
  Description : PHP bindings to libsass - fast, native Sass parsing in PHP

The sass extension for PHP gives you an object-oriented system of parsing Sass
from within your PHP applications. Under the hood it uses libsass to provide
super speedy and compatible Sass parsing.

 So long,
Rhonda
-- 
strg.at gmbh
rho...@strg.at
gumpendorfer strasse 132/9, 1060 wien
tel +43 (1) 526 56 29


signature.asc
Description: PGP signature

Bug#858426: unblock: tworld/1.3.2-3

[Rhonda D'Vine]

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

 Hi,

 please unblock package tworld, it fixes the binNMU b0rkage mentioned in
#857974.

#v+
$ debdiff tworld_1.3.2-2.dsc  tworld_1.3.2-3.dsc
diff -Nru tworld-1.3.2/debian/changelog tworld-1.3.2/debian/changelog
--- tworld-1.3.2/debian/changelog   2016-01-05 14:53:05.0 +0100
+++ tworld-1.3.2/debian/changelog   2017-03-22 09:54:26.0 +0100
@@ -1,3 +1,12 @@
+tworld (1.3.2-3) unstable; urgency=medium
+
+  * Remove doc symlink to -data package from tworld to make it binNMUable
+(closes: #857974)
+  * Install docs into tworld package instead of tworld-data.
+  * Bump Standards-Version to 3.9.8.
+
+ -- Rhonda D'Vine <rho...@debian.org>  Wed, 22 Mar 2017 09:54:26 +0100
+
 tworld (1.3.2-2) unstable; urgency=medium
 
   * Fix reproducible issue, thanks to Chris Lamb for finding the spot to
diff -Nru tworld-1.3.2/debian/control tworld-1.3.2/debian/control
--- tworld-1.3.2/debian/control 2016-01-01 04:04:04.0 +0100
+++ tworld-1.3.2/debian/control 2017-03-22 09:54:26.0 +0100
@@ -4,7 +4,7 @@
 Maintainer: Debian Games Team <pkg-games-de...@lists.alioth.debian.org>
 Uploaders: Rhonda D'Vine <rho...@debian.org>
 Build-Depends: debhelper (>= 9~), libsdl1.2-dev
-Standards-Version: 3.9.6
+Standards-Version: 3.9.8
 Vcs-Git: git://anonscm.debian.org/pkg-games/tworld.git
 Vcs-Browser: https://anonscm.debian.org/cgit/pkg-games/tworld.git
 Homepage: http://www.muppetlabs.com/~breadbox/software/tworld/
diff -Nru tworld-1.3.2/debian/rules tworld-1.3.2/debian/rules
--- tworld-1.3.2/debian/rules   2016-01-05 18:27:28.0 +0100
+++ tworld-1.3.2/debian/rules   2017-03-22 09:54:26.0 +0100
@@ -21,6 +21,3 @@
pod2man -s 6 -r 'Tile World' -c '' debian/c4 \
debian/tworld-data/usr/share/man/man6/c4.6
dh_auto_install
-
-override_dh_installdocs:
-   dh_installdocs --link-doc=tworld-data
diff -Nru tworld-1.3.2/debian/tworld-data.docs 
tworld-1.3.2/debian/tworld-data.docs
--- tworld-1.3.2/debian/tworld-data.docs2016-01-01 04:04:04.0 
+0100
+++ tworld-1.3.2/debian/tworld-data.docs1970-01-01 01:00:00.0 
+0100
@@ -1,3 +0,0 @@
-BUGS
-README
-docs/tworld.html
diff -Nru tworld-1.3.2/debian/tworld.docs tworld-1.3.2/debian/tworld.docs
--- tworld-1.3.2/debian/tworld.docs 1970-01-01 01:00:00.0 +0100
+++ tworld-1.3.2/debian/tworld.docs 2017-03-22 09:54:26.0 +0100
@@ -0,0 +1,3 @@
+BUGS
+README
+docs/tworld.html
diff -Nru tworld-1.3.2/debian/tworld.maintscript 
tworld-1.3.2/debian/tworld.maintscript
--- tworld-1.3.2/debian/tworld.maintscript  1970-01-01 01:00:00.0 
+0100
+++ tworld-1.3.2/debian/tworld.maintscript  2017-03-22 09:54:26.0 
+0100
@@ -0,0 +1 @@
+symlink_to_dir /usr/share/doc/tworld tworld-data 1.3.2-3~~
#v-


unblock tworld/1.3.2-3

 Thanks in advance,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#857974: tworld: uninstallable after binNMU

[Rhonda D'Vine]

 Hi,

* Andreas Beckmann  [2017-03-16 20:48:35 CET]:
> during a test with piuparts I noticed your package is no longer
> installable in sid:
> 
> The following packages have unmet dependencies:
>  tworld : Depends: tworld-data (= 1.3.2-2+b1) but 1.3.2-2 is to be installed
> 
> This dependency is generated by 
>   dh_installdocs --link-doc
> from an arch:any to an arch:all package

 That sounds a bug in dh_installdocs then if it doesn't use the binNMU
safe dependency setting in that case.

 Is there a workaround for it?  How do other packages deal with that, or
is that something that can get fixed in debhelper?

 Enjoy,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#856201: irssi: slow startup

[Rhonda D'Vine]

   Hi,

* Alberto Garcia  [2017-02-26 22:43:25 CET]:
> On Sun, Feb 26, 2017 at 09:01:12PM +0100, Ailin Nemui wrote:
> > Hi, if you are serious about finding this problem it would be
> > best if you could git bisect the code to pin point the changeset
> > responsible
> 
> Actually I just took a quick look and it seems that there's
> no changeset that is responsible for this. It's this first
> g_main_iteration(TRUE) call in irssi.c that blocks the UI:
> 
>   while (!quitting) {
>   term_refresh_freeze();
>   g_main_iteration(TRUE);
> term_refresh_thaw();
> 
>   if (reload_config) {
> /* SIGHUP received, do /RELOAD */
>   reload_config = FALSE;
> signal_emit("command reload", 1, "");
>   }
> 
>   dirty_check();
>   }
> 
> So it may be a change in glib, but I don't know if it's right that
> irssi calls g_main_iteration() here with may_block = TRUE.

 Could you maybe add an strace of the startup (potentially with -r
switch to see where it might hang or take longer than usual).

 Thanks,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#440055: irssi: sometimes forgets how to autocreate windows

[Rhonda D'Vine]

Hey,

 I just got upstream to look through the bugreports and help me weed
them out, and got a comment for this ancient one:

* Colin Watson  [2007-08-29 14:26:24 CEST]:
> Sometimes irssi gets confused and forgets how to autocreate windows.
> Today this happened to me for the second time (the first time I gave up
> and restarted irssi). I was attempting to '/join -window' a channel
> after reconnecting to a server following a prolonged network outage.
> Just before I hit enter, a reconnection to a different server happened
> to fire and the selected network changed on me (I don't know if this is
> relevant). In the status window I saw:
> 
>   10:18 -!- Irssi: critical window_item_add: assertion `item->window == NULL' 
> failed

 Can you install the debug package (irssi-dbg in stable, and for
stretch/unstable the automatically built irssi-dbgsym one), step into
gdb and p that item's window to debug it further?  That would help
upstream a lot.  In case it still happens to you with current versions.
:)

 Thanks a lot!
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#384872: irssi: with ssl eats up cpu and doesn't connect

[Rhonda D'Vine]

   Hey,

 ancient report, I just got upstream to look through the bugreports
though and got the notice that it seems to be a bug in torify and not
irssi and it was suggested to give
https://github.com/rofl0r/proxychains-ng a try for that.

 Is it fine with you if I close this bugreport against irssi?

 Cheers,
Rhonda


* Daniele Sempione  [2006-08-27 16:45:36 CEST]:
> Package: irssi
> Version: 0.8.10-2
> Severity: normal
> 
> this happens when using irssi ssl connection and tor (maybe this is a
> low band/speed problem).
> 
> tor+bitchx works
> tor+bitchk+ssl works
> tor+irssi works
> tor+irssi+ssl doesn't work
> 
> it seems there's an infinite loop somewhere, strace ($ torify strace
> irssi) reports a long (endless) list of:
> recv(5, "", 8, 0)   = 0
> 
> then I have to kill irssi, the system is unusable, it uses all the cpu.
> 
> Cheers,
> Daniele

-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#851676: nmu: irssi-plugin-xmpp_0.53-1 irssi-plugin-otr_1.0.2-1 irssi-plugin-robustirc_0.6-2

[Rhonda D'Vine]

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

  Hi,

 as discussed with Niels on IRC prior to the upload, please binNMU the
three plugin packages against my irssi upload so that they can
transition into stretch in time:

nmu irssi-plugin-xmpp_0.53-1 . ALL . -m "Rebuild against irssi >= 1.0.0"
nmu irssi-plugin-otr_1.0.2-1 . ALL . -m "Rebuild against irssi >= 1.0.0"
nmu irssi-plugin-robustirc_0.6-2 . ALL . -m "Rebuild against irssi >= 1.0.0"

 Thanks in advance,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#851241: www.debian.org: packages.debian.org update hangs every now and then

[Rhonda D'Vine]

Package: www.debian.org
Severity: normal

 Hi,

 I got notified today that the packages website didn't update, and that
this seems to be an issue appearing more regularly.  I didn't had much
time unfortunately to investigate it further, but this is what appeared
to me:

#v+
pkg_user 21873  0.0  0.0 103296  5192 ?SJän07   0:07 sshd: 
pkg_user@notty
pkg_user 21887  0.0  0.0   4336   764 ?Ss   Jän07   0:00  \_ dash -c 
/srv/packages.debian.org/bin/push_update
pkg_user 21898  0.0  0.0  13348  1656 ?SJän07   0:00  \_ 
/bin/bash /srv/packages.debian.org/bin/push_update
pkg_user 21958  0.0  0.0   4224  1476 ?SJän07   0:00  \_ 
run-parts --verbose /srv/packages.debian.org/cron.d
pkg_user 22309  0.0  0.0  13344  1640 ?SJän07   0:00  
\_ /bin/bash /srv/packages.debian.org/cron.d/200proce
pkg_user 25601 99.0  0.7 154500 122188 ?   RJän07 7804:48   
   \_ /usr/bin/perl -w ./bin/parse-contents
pkg_user 20378  0.0  0.0   4336   712 ?SJän07   0:00
  \_ sh -c sort  -T /srv/packages.debian.org/tm
pkg_user 20379  0.0  0.0   9080  3864 ?SJän07   3:24
  \_ sort -T /srv/packages.debian.org/tmp -
#v-

 The running time of parse-contents was increasing, but the sort didn't
do anything. An strace showed that it was hanging:

#v+
$ strace -p 20379
Process 20379 attached
write(1, "-data:kfreebsd-i386\nyp.margorp_e"..., 4096^CProcess 20379 detached
 
#v-

 Unfortunately I didn't had the time to investigate further, but if it
hangs again and maybe at the same place I guess the tmp file(s) would be
useful to investigate further.

 Sorry for not much more right now,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#850539: stable-pu: irssi

[Rhonda D'Vine]

Package: release.debian.org
Severity: high
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

  Hi!

 irssi got some security related updates, and I prepared an update.  I'm
sending the debdiff for it, should be pretty straight forward, it's
mostly the upstream commit fixing the security issues in a patch file,
and I'm going to upload it now so it makes it in time for the point
release.  If anything more is needed please let me know and I can try to
fix that ASAP.

 Enjoy,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|
diff -u irssi-0.8.17/debian/changelog irssi-0.8.17/debian/changelog
--- irssi-0.8.17/debian/changelog
+++ irssi-0.8.17/debian/changelog
@@ -1,3 +1,15 @@
+irssi (0.8.17-1+deb8u3) jessie; urgency=low
+
+  * New patch 24security-fixes pulled from upstream commit 6c6c42e3d1b4
+(besides the one issue in src/fe-text/term-terminfo.c which is 0.8.18
+onward only), closes: #850403:
+- CVE-2017-5193: NULL pointer dereference in the nickcmp function
+- CVE-2017-5194: Use-after-freee when receiving invalid nick message
+- CVE-2017-5195: Out-of-bounds read in certain incomplete control codes
+  * Set PACKAGE_VERSION for configure as suggested by upstream.
+
+ -- Rhonda D'Vine <rho...@debian.org>  Sat, 07 Jan 2017 15:54:02 +0100
+
 irssi (0.8.17-1+deb8u2) jessie; urgency=high
 
   * New patch 23fix-buf.pl to fix an information exposure issue involved with
diff -u irssi-0.8.17/debian/patches/series irssi-0.8.17/debian/patches/series
--- irssi-0.8.17/debian/patches/series
+++ irssi-0.8.17/debian/patches/series
@@ -10,0 +11 @@
+24security-fixes
diff -u irssi-0.8.17/debian/rules irssi-0.8.17/debian/rules
--- irssi-0.8.17/debian/rules
+++ irssi-0.8.17/debian/rules
@@ -42,6 +42,8 @@
 	--enable-ipv6 --with-bot --with-proxy --enable-true-color \
 	--with-perl-lib=vendor
 
+VERSION = $(shell dpkg-parsechangelog | grep "^Version:" | cut -d" " -f2)
+
 # enable DANE only on linux, libval doesn't compile on kfreebsd (yet)
 ifneq (,$(findstring linux,$(DEB_HOST_ARCH_OS)))
 	CONFIGURE_SWITCHES += --enable-dane
@@ -51,7 +53,7 @@
 	dh_testdir
 	# Add here commands to configure the package.
 	dh_autotools-dev_updateconfig
-	CFLAGS="$(CFLAGS)" ./configure $(CONFIGURE_SWITCHES)
+	CFLAGS="$(CFLAGS)" ./configure $(CONFIGURE_SWITCHES) PACKAGE_VERSION=$(VERSION)
 
 
 build: build-arch build-indep
only in patch2:
unchanged:
--- irssi-0.8.17.orig/debian/patches/24security-fixes
+++ irssi-0.8.17/debian/patches/24security-fixes
@@ -0,0 +1,79 @@
+Author: ailin-nemui	vim:ft=diff:
+Description: CVE-2017-5193 CVE-2017-5194 CVE-2017-5195
+Upstream commit 6c6c42e3d1b49d90aacc0b67f8540471cae02a1d
+besides the fix for CVE-2017-5196 which is for 0.8.18 onward
+
+
+--- a/src/fe-common/core/formats.c
 b/src/fe-common/core/formats.c
+@@ -68,7 +68,7 @@ static void format_expand_code(const cha
+ 
+ 	if (flags == NULL) {
+ 		/* flags are being ignored - skip the code */
+-		while (**format != ']')
++		while (**format != ']' && **format != '\0')
+ 			(*format)++;
+ 		return;
+ 	}
+@@ -246,6 +246,10 @@ int format_expand_styles(GString *out, c
+ 	case '[':
+ 		/* code */
+ 		format_expand_code(format, out, flags);
++		if ((*format)[0] == '\0')
++			/* oops, reached end prematurely */
++			(*format)--;
++
+ 		break;
+ 	case 'x':
+ 	case 'X':
+@@ -969,6 +973,7 @@ static const char *get_ansi_color(THEME_
+ 			str++;
+ 			for (num2 = 0; i_isdigit(*str); str++)
+ num2 = num2*10 + (*str-'0');
++			if (*str == '\0') return start;
+ 
+ 			switch (num2) {
+ 			case 2:
+@@ -986,6 +991,8 @@ static const char *get_ansi_color(THEME_
+ 	for (; i_isdigit(*str); str++)
+ 		num2 = (num2&~0xff) |
+ 			(((num2&0xff) * 10 + (*str-'0'))&0xff);
++
++	if (*str == '\0') return start;
+ }
+ 
+ if (i == -1) break;
+@@ -1014,6 +1021,7 @@ static const char *get_ansi_color(THEME_
+ str++;
+ for (num2 = 0; i_isdigit(*str); str++)
+ 	num2 = num2*10 + (*str-'0');
++if (*str == '\0') return start;
+ 
+ if (num == 38) {
+ 	flags &= ~GUI_PRINT_FLAG_COLOR_24_FG;
+--- a/src/irc/core/irc-nicklist.c
 b/src/irc/core/irc-nicklist.c
+@@ -338,7 +338,11 @@ static void event_whois_ircop(SERVER_REC
+ static void event_nick_invalid(IRC_SERVER_REC *server, const char *data)
+ {
+ 	if (!server->connected)
+-		server_disconnect((SERVER_REC *) server);
++		/* we used to call server_disconnect but that crashes
++		   irssi because of undefined memory access. instead,
++		   indicate that the connection should be dropped and
++		   let the irc method to the clean-up. */
++		server->connection_lost = server->no_reconnect = TRUE;
+ }
+ 
+ static void event_nick_in_use(IRC_SERVER_REC *server, const 

Bug#849922: rxvt-unicode-256color: tabbed extension requires mouse focus for dead keys

[Rhonda D'Vine]

Package: rxvt-unicode-256color
Version: 9.22-1
Severity: normal

Dear Maintainer,

 using the tabbed extension of urvt and using deadkeys requires mouse
focus on the terminal to be able to use them.

 Removing tabbed from the extension allows to enter dead keys, so in
that sense is sounds kinda similar to the issues of #531751 and #511377

 Thanks,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#838780: jessie-pu: package irssi/0.8.17-1+deb8u1

[Rhonda D'Vine]

  Hi,

* Adam D. Barratt <a...@adam-barratt.org.uk> [2016-09-24 21:24:18 CEST]:
> On Sat, 2016-09-24 at 21:18 +0200, Rhonda D'Vine wrote:
> >  The patch that upstream provides is this:
> > https://github.com/irssi/scripts.irssi.org/commit/f1b1eb154baa684fad5d65bf4dff79c8ded8b65a
> > 
> >  I uploaded it to unstable already and would like to push it to stable,
> > too.
> 
> That looks okay, but please could we have a source debdiff for the
> proposed upload, as built and hopefully tested on jessie.

 I commited it locally to my git, the attached diff is
"git diff HEAD^.." which was the commit from the security update.

 Thanks,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|
diff --git a/debian/changelog b/debian/changelog
index 364754f..79b5c38 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+irssi (0.8.17-1+deb8u2) jessie; urgency=high
+
+  * New patch 23fix-buf.pl to fix an information exposure issue involved with
+    using buf.pl and /upgrade (closes: #838762)
+
+ -- Rhonda D'Vine <rho...@debian.org>  Sat, 24 Sep 2016 16:10:19 +0200
+
 irssi (0.8.17-1+deb8u1) jessie-security; urgency=high
 
   * Non-maintainer upload by the Security Team.
diff --git a/debian/patches/23fix-buf.pl b/debian/patches/23fix-buf.pl
new file mode 100644
index 000..27963fd
--- /dev/null
+++ b/debian/patches/23fix-buf.pl
@@ -0,0 +1,103 @@
+Author: Rhonda D'Vine <rho...@debian.org>	vim:ft=diff:
+Description: Fix information exposure during /upgrade, BTS #838762
+
+--- a/scripts/buf.pl
 b/scripts/buf.pl
+@@ -5,7 +5,7 @@ use Irssi qw(command signal_add signal_a
+  settings_get_str settings_get_bool channels windows
+ 	 settings_add_str settings_add_bool get_irssi_dir
+ 	 window_find_refnum signal_stop);
+-$VERSION = '2.13';
++$VERSION = '2.20';
+ %IRSSI = (
+ authors	=> 'Juerd',
+ contact	=> 'ju...@juerd.nl',
+@@ -13,10 +13,8 @@ $VERSION = '2.13';
+ description	=> 'Saves the buffer for /upgrade, so that no information is lost',
+ license	=> 'Public Domain',
+ url		=> 'http://juerd.nl/irssi/',
+-changed	=> 'Mon May 13 19:41 CET 2002',
+-changes	=> 'Severe formatting bug removed * oops, I ' .
+-   'exposed Irssi to ircII foolishness * sorry ' .
+-		   '** removed logging stuff (this is a fix)',
++changed	=> 'Thu Sep 22 01:37 CEST 2016',
++changes	=> 'Fixed file permissions (leaked everything via filesystem)',
+ note1	=> 'This script HAS TO BE in your scripts/autorun!',
+ note2	=> 'Perl support must be static or in startup',
+ );
+@@ -39,9 +37,15 @@ use Data::Dumper;
+ 
+ my %suppress;
+ 
++sub _filename { sprintf '%s/scrollbuffer', get_irssi_dir }
++
+ sub upgrade {
+-open BUF, q{>}, sprintf('%s/scrollbuffer', get_irssi_dir) or die $!;
+-print BUF join("\0", map $_->{server}->{address} . $_->{name}, channels), "\n";
++my $fn = _filename;
++my $old_umask = umask 0077;
++open my $fh, q{>}, $fn or die "open $fn: $!";
++umask $old_umask;
++
++print $fh join("\0", map $_->{server}->{address} . $_->{name}, channels), "\n";
+ for my $window (windows) {
+ 	next unless defined $window;
+ 	next if $window->{name} eq 'status';
+@@ -57,36 +61,39 @@ sub upgrade {
+ 		redo if defined $line;
+ 	}
+ 	}
+-	printf BUF "%s:%s\n%s", $window->{refnum}, $lines, $buf;
++	printf $fh "%s:%s\n%s", $window->{refnum}, $lines, $buf;
+ }
+-close BUF;
++close $fh;
+ unlink sprintf("%s/sessionconfig", get_irssi_dir);
+ command 'layout save';
+ command 'save';
+ }
+ 
+ sub restore {
+-open BUF, q{<}, sprintf('%s/scrollbuffer', get_irssi_dir) or die $!;
+-my @suppress = split /\0/, ;
++my $fn = _filename;
++open my $fh, q{<}, $fn or die "open $fn: $!";
++unlink $fn or warn "unlink $fn: $!";
++
++my @suppress = split /\0/, readline $fh;
+ if (settings_get_bool 'upgrade_suppress_join') {
+ 	chomp $suppress[-1];
+ 	@suppress{@suppress} = (2) x @suppress;
+ }
+ active_win->command('^window scroll off');
+-while (my $bla = ){
++while (my $bla = readline $fh){
+ 	chomp $bla;
+ 	my ($refnum, $lines) = split /:/, $bla;
+ 	next unless $lines;
+ 	my $window = window_find_refnum $refnum;
+ 	unless (defined $window){
+-	 for 1..$lines;
++	readline $fh for 1..$lines;
+ 	next;
+ 	}
+ 	my $view = $window->view;
+ 	$view->remove_all_lines();
+ 	$view->redraw();
+ 	my $buf = '';
+-	$buf .=  for 1..$lines;
++	$buf .= readline $fh for 1..$lines;
+ 	my $sep = settings_get_str 'upgrade_separator';
+ 	$

Bug#838780: jessie-pu: package irssi/0.8.17-1+deb8u1

[Rhonda D'Vine]

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

  Hi,

 after the security update of irssi another report came in about a
script included in irssi, buf.pl.  If it's loaded and an /upgrade of
irssi is done the current buffer content is written to a temporary file
which didn't use tightly secured file permissions to temporarily store
the buffer content for re-reading it after re-execing irssi.

 The patch that upstream provides is this:
https://github.com/irssi/scripts.irssi.org/commit/f1b1eb154baa684fad5d65bf4dff79c8ded8b65a

 I uploaded it to unstable already and would like to push it to stable,
too.

 Thanks in advance,
Rhonda

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

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

Bug#819523: squid3 in wheezy-backports has unmet dependencies

[Rhonda D'Vine]

* Amos Jeffries  [2016-03-30 14:38:28 CEST]:
> Requesting a re-build on the normal amd64 buildd should resolve this.

 Unfortunately, the re-build was never requested so far ...   I just
dropped a note on the #debian-buildd and got it right ahead approved:

11:46  Can squid3 in wheezy-backports please get an binNMU on
   amd64, it was built in a wrong chroot by the uploader.
11:55  Rhonda: scheduled


* Markus Koschany  [2016-07-07 08:48:04 CEST]:
> I have just rebuilt and uploaded a new version of squid3 in
> wheezy-backports. This should fix the issue with unmet dependencies.

 Unfortunately, that was unneeded and wrong.  Please don't do sourceful
uploads when a simple rebuild by the buildd network can fix such issues.
It might not look as good on the LTS report, but it's still the right
thing to do and also takes way less time than doing a sourceful upload
with all the expected testing involved.

 Have fun, and sorry this took so long to request the rebuild. :/  The
rebuild shouldn't take too long, the package should be available within
at least a day's time.

 Enjoy!
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#682929: equivs: Confused by symlinks in Files

[Rhonda D'Vine]

Hi,

 any news on this?

* Ian Zimmerman  [2012-07-27 08:28:22 CEST]:
> When I make foo a trivial shell script instead, it works:
>  [52+1]transitional-foo cat foo
> #! /bin/sh
> 
> exec /usr/bin/bar "$@"

 That workaround only works for when you want to do a symlink to
something you want to have executed.  If it's about something else than
things to execute this workaround doesn't help at all. :/

 So long,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#826239: yrmcds: doesn't start at all, temp dir race

[Rhonda D'Vine]

Package: yrmcds
Version: 1.0.4-6
Severity: important
Tags: security

Dear Maintainer,

 the daemon doesn't start at all on jessie with systemd without further
help.  Additionally the way it seems to be meant to contains a security
related issue with predictable temp dir name.

 It seems to expect directory /var/tmp/yrmcds writable by the daemon.
The ExecStartpre in the systemd file doesn't seem to get executed, also
it wouldn't be created with permission of the yrmcds user neither.

 This needs to get addressed in stable too from both general startup
point of view and also security related point of view.

 Thanks,
Rhonda

-- 
strg.at gmbh
rho...@strg.at
gumpendorfer strasse 132/9, 1060 wien
tel +43 (1) 526 56 29


signature.asc
Description: Digital signature

Bug#823005: fixed in pepperflashplugin-nonfree 1.8.2+nmu1

[Rhonda D'Vine]

Hey Kristian,

 are you willing to prepare an NMU for stable, too?  This also affects
the package in jessie obviously.  :)

 Thanks,
Rhonda


* Kristian Klausen  [2016-05-14 12:00:14 CEST]:
> Closes: 816848 818540 823005
> Changes:
>  pepperflashplugin-nonfree (1.8.2+nmu1) unstable; urgency=medium
>  .
>* Non-maintainer upload.
>* Update Google public key. Closes: #823005.
>* Remove 32 bit support. Closes: #816848.
>* Don't treat `apt-get update` warnings as errors. Closes: #818540.
>* Validate deb file with sha256sum.

-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#814514: mutt-patched: redraw-screen doesn't redraw color markers

[Rhonda D'Vine]

Package: mutt-patched
Version: 1.5.23-3
Severity: normal

Dear Maintainer,

 I stumbled upon an annoyance with the sidebar patch.  The following
macro is suggested to be used to toggle the sidebar visibility:

macro pager B 'toggle sidebar_visible'

 That works well - until a linebreak happens or gets removed due to
screen width changes.  This then will happen the wrong lines to be
colored after that linebreak changes.

 When a terminal is horizontally resized though the color positions get
refreshed, too.  So it looks like the redraw-screen doesn't do
everything that happens by the trigger through the terminal resizing;
but the expectation definitely goes this direction. :)

 I'm not sure if this should rather be filed against mutt instead of
mutt-patched because I assume this part of the code (the 
functionality) isn't mutt-patched specific; feel free to reassign if
needed.  It's just way easier to reproduce it with mutt-patched; I'm not
sure how/if it would be reproducible with vanilla mutt. :)

 Enjoy, and thanks for taking care of the package!
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#812750: wine: Gecko integration is broken

[Rhonda D'Vine]

   Hey,

* Jens Reyer  [2016-02-09 19:49:43 CET]:
> In Wine we depend on libwine-gecko-xxx before it's added to the archive,
> knowing/hoping/assuming that it will be added to the archive, which has
> always been true for Debian stable releases, but not for all
> intermittent Gecko versions that were needed in between (maintainer is
> in both cases the Wine packaging team, unfortunately afaik every new
> Gecko upstream release takes a lot of work, especially for reevaluating
> the copyrights).

 Thanks for explaining the situation at hand, that helps better with
understanding how this situation happened. :)

> This has the benefit of having the dependency already ready, once Gecko
> is added to the archive, without the need to reupload Wine.

 Unfortunately unsatisfyable recommends are a policy violation though,
and even while I understand the sentiments of not wanting to have to
reupload wine to add it, I don't see a way around this.

> It may also show people more easily where work needs to be done
> (increasing the people who help from 0 to 0).

 Yeah, that's always the issue; unfortunately I have different areas in
which I put my effort and I only stumbled upon it in the context of
backports.

> Rhonda, do you see any flexibility in interpreting the policy for this
> case? If not, I'll do something like

 Unfortunately I don't see it, it's a clear must requirement and there
for very specific reasons, to keep main untainted from non-free
packages.

 So yes, seperating the issue of that it might help to where to find
gecko to install it personally, and lowering the recommends to suggests
could definitely be tackled seperately.

 Thanks for the headsup,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#812750: [pkg-wine-party] Bug#812750: wine: Gecko integration is broken

[Rhonda D'Vine]

   Hi,

* Austin English <austinengl...@gmail.com> [2016-02-09 17:45:02 CET]:
> On Feb 9, 2016 8:39 PM, austinengl...@gmail.com wrote:
> > On Feb 9, 2016 8:25 PM, "Rhonda D'Vine" <rho...@deb.at> wrote:
> > > > >   Hi!
> > > > >
> > > > > * Ralf Jung <p...@ralfj.de> [2016-01-26 10:57:49 CET]:
> > > > > > From all I can tell, the Gecko integration is entirely broken. There
> > > > > > is no wine-gecko packaged in Debian
> > > > > > (the recommendation of libwine-gecko-2.40 is unsatisfiable),
> > >^
> > > >
> > > > mingw64 is in main, what package are you referring to?
> > >
> > >  No clue why you mention mingw64, I am to the package I did quote in my
> > > mail and this bugreport is about, libwine-gecko-2.40.
> >
> > I'm asking what recommended package is the problem. It's not on
> > packages.d.o and not specified in the mail as far as I can tell.

 Erm, it is both on packages.debian.org/wine32 and also in this
bugreport mentioned multiple times.  So let me write it a third and
three time in this very email:
libwine-gecko-2.40 libwine-gecko-2.40 libwine-gecko-2.40

> Or is it that libwine-gecko-2.40 isn't in main that is the problem? I
> thought the problem was a gecko recommend.

 Maybe you should read what is written instead of guessing.
libwine-gecko-2.40 is not only not in main but not even nowhere in the
archive.

 So long,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#812750: wine: Gecko integration is broken

[Rhonda D'Vine]

severity 812750 serious
thanks

  Hi!

* Ralf Jung  [2016-01-26 10:57:49 CET]:
> >From all I can tell, the Gecko integration is entirely broken. There is no 
> >wine-gecko packaged in Debian
> (the recommendation of libwine-gecko-2.40 is unsatisfiable),

 From policy:

 In addition, the packages in _main_
* must not require or recommend a package outside of _main_ for
  compilation or execution (thus, the package must not declare a
  "Pre-Depends", "Depends", "Recommends", "Build-Depends", or
  "Build-Depends-Indep" relationship on a non-_main_ package),

 Given that the package Recommends a package that isn't available in the
pool this is a policy violation.

 Thanks,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#812750: [pkg-wine-party] Bug#812750: wine: Gecko integration is broken

[Rhonda D'Vine]

* Austin English <austinengl...@gmail.com> [2016-02-09 17:19:30 CET]:
> On Feb 9, 2016 8:15 PM, "Rhonda D'Vine" <rho...@deb.at> wrote:
> > severity 812750 serious
> > thanks
> >
> >   Hi!
> >
> > * Ralf Jung <p...@ralfj.de> [2016-01-26 10:57:49 CET]:
> > > From all I can tell, the Gecko integration is entirely broken. There
> > > is no wine-gecko packaged in Debian
> > > (the recommendation of libwine-gecko-2.40 is unsatisfiable),
   ^
> >
> >  From policy:
> >
> >  In addition, the packages in _main_
> > * must not require or recommend a package outside of _main_ for
> >   compilation or execution (thus, the package must not declare a
> >   "Pre-Depends", "Depends", "Recommends", "Build-Depends", or
> >   "Build-Depends-Indep" relationship on a non-_main_ package),
> >
> >  Given that the package Recommends a package that isn't available in the
> > pool this is a policy violation.
> 
> mingw64 is in main, what package are you referring to?

 No clue why you mention mingw64, I am to the package I did quote in my
mail and this bugreport is about, libwine-gecko-2.40.

 Hope that helps,
Rhonda 
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#811089: [pkg-bacula-devel] Bug#811089: bconsole: typo forbids non-interactive restore

[Rhonda D'Vine]

Hi,

* Carsten Leonhardt  [2016-01-27 14:17:47 CET]:
> Hi Rhonda,
> > there is a typo in src/dird/ua_restore.c which hinders starting a
> > non-interactive restore.
> 
> could you give me an example invocation for such a restore?

*restore where=/bacula/restore/hostname client=hostname 
restore_job=hostname-restore restoreclient=backup-mgmt-fd select current all 
done yes

 Thing is, the restore_job option will be claimed to be a wrong option
if written this way without the patch, and if you use restorejob instead
it won't be parsed but you'll instead be asked to select one
interactively.  So with the patch it's possible to fully do it
non-interactive because both the parsing of the option and the checking
for the options do use the same syntax.

> Which version did you patch - the old 5.2.6 or the 7.0.5 from testing?

 I patched 5.2.6 here but like written originally the bug is still
unfixed with the 7.0.5 version.  Given that it's a one-character fix it
should be possible to convince the stable release team to get it fixed
for stable too.

 I'm a bit puzzled by the upstream bug comment that it should be fixed
already since 2012, but I still see it called restorejob in there in the
7.0.5 version.  It might be that they fixed it in the other direction,
of making restorejob work instead; but I'm uncertain, didn't check it
with a setup of that version.

 Hope that helps,
Rhonda
-- 
strg.at gmbh
rho...@strg.at
gumpendorfer strasse 132/9, 1060 wien
tel +43 (1) 526 56 29


signature.asc
Description: Digital signature

Bug#812790: debhelper: error in German man dh_installinit

[Rhonda D'Vine]

Package: debhelper
Version: 9.20120909
Severity: normal

Dear Maintainer,

 The German manpage for dh_installinit reads:


DATEIEN
   debian/Paket.init
   Falls dies existiert, wird es in etc/init.d/Paket.conf im 
Paketbauverzeichnis installiert.

 This is wrong, there is an obvious superfluous .conf in there which
isn't in the original.

 You can safely remove the .conf part from there, if you want you can
pass it for proof reading through debian-l10n-ger...@lists.debian.org
but for that change I am quite certain that isn't needed.

 Thanks,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#812248: lintian: don't check Homepage field (and similar) against dbgsym packages

[Rhonda D'Vine]

Package: lintian
Version: 2.5.39.1
Severity: minor

   Hi,

 while running lintian against a package with a non-existing upstream it
complained about the missing Homepage field.  It did so also for the
dbgsym package.

 I can understand the reaoning to not want to have an override file for
the dbgsym package, but that means that this check (and potentially
others too) shouldn't trigger a message for dbgsym packages.

 I'm uncertain what checks might appear beside the missing Homepage but
I guess there might be more than this.  I hope you have a better
overview on what might appear additionally to that.

 So long,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#811089: bconsole: typo forbids non-interactive restore

[Rhonda D'Vine]

Package: bacula-console
Version: 5.2.6+dfsg-9.3
Severity: normal

Dear Maintainer,

 there is a typo in src/dird/ua_restore.c which hinders starting a
non-interactive restore.  This bug has been reported upstream at 
http://bugs.bacula.org/view.php?id=1899 and is a one character fix:

#v+
Index: bacula-5.2.6+dfsg/src/dird/ua_restore.c
===
--- bacula-5.2.6+dfsg.orig/src/dird/ua_restore.c2016-01-15 
14:54:10.676996102 +0100
+++ bacula-5.2.6+dfsg/src/dird/ua_restore.c 2016-01-15 14:54:45.129322694 
+0100
@@ -472,7 +472,7 @@
   "restoreclient", /* 19 */
   "copies",/* 20 */
   "comment",   /* 21 */
-  "restorejob",/* 22 */
+  "restore_job",   /* 22 */
   "replace",   /* 23 */
   NULL
};
#v-

 Please get this patch applied, it's really annoying to not being able
to give that option on the command line.  I've created myself a local
build with that patch and it works like a charm.  It would be extremely
nice to have this fixed in a stable update.  According to
https://sources.debian.net/src/bacula/7.0.5%2Bdfsg-4/src/dird/ua_restore.c/#L481
this still affects the version in unstable, too.

 Thanks,
Rhonda
-- 
strg.at gmbh
rho...@strg.at
gumpendorfer strasse 132/9, 1060 wien
tel +43 (1) 526 56 29


signature.asc
Description: Digital signature

Bug#658211: irssi infinite redraw

[Rhonda D'Vine]

Hi there!

 Long time no hear!  Hope you haven't given up hope. :)   According to
upstream your bugreport might have been fixed with 0.8.17-1 which is
available in the pool for most releases (either directly or through
backports).  Can you try to reproduce it with that newer upstream
release, and if so produce a backtrace to look at?

 Thanks, and happy season greetings.
Rhonda


* Grant Bowman  [2012-02-01 03:14:21 CET]:
> Package: irssi
> Version: 0.8.15-2
> 
> Steps:
> 1. Create a 109x40 terminal locally.
> 2. ssh to my Debian squeeze 0.6.2 server.
> 3. Run tmux. Installed version is 1.3-2+squeeze1
> 4. In a tmux screen run irssi.
> 5. Detach from tmux, logout.
> 6. Login several days later and run tmux attach-session.
> 7. irssi seems to continually redraw the screen and will not accept
> commands. It is still running and logging to disk.
> 
> Other info:
> $ uname -a
> Linux  2.6.27 #1 SMP Mon Jun 13 17:16:12 UTC 2011 i686 GNU/Linux
> $ dpkg -s libc6 | grep ^Version
> Version: 2.11.2-10
> 
> 

-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#807545: aptitude: creates non-dot directory in user home

[Rhonda D'Vine]

Package: aptitude
Version: 0.7.5-1
Severity: important

Dear Maintainer,

 aptitude now creates a non-dot aptitude directory in the userhome.  I
consider this quite an annoyance.  What was wrong with the .aptitude
directory used so far?  This is left now as a cruft.

 Please make it use .aptitude again and not create a non-dot directory
in the user home.

 Thanks,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#807545: Seems to be related to #671780

[Rhonda D'Vine]

  Hi,

 given that this seems to be related to #671780, please be reffered to
the basedir spec:

,> http://standards.freedesktop.org/basedir-spec/basedir-spec-0.7.html <
| $XDG_CACHE_HOME defines the base directory relative to which user
| specific non-essential data files should be stored. If $XDG_CACHE_HOME
| is either not set or empty, a default equal to $HOME/.cache should be
| used.
`> http://standards.freedesktop.org/basedir-spec/basedir-spec-0.7.html <

 So, if this data is cache data it should use ~/.cache (or
~/.cache/aptitude FWIW) instead of ~/aptitude

 Hope that helps,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#477084: wyrd: Also happens when adding new reminder without adding newline in editor

[Rhonda D'Vine]

 Hi there!

 I know, the reply comes late, but ...  :)

* Ico Doornekamp  [2009-01-12 18:00:22 CET]:
> The described phenomenon not only occurs when copying reminders, but
> also when creating a new one:
> 
> - Start wyrd, and press 'enter' on a given time to create a new
>   reminder. Editor is opened with the following line:
> 
>   REM Jan 13 2009 AT 04:00 DURATION 1:00 MSG
> 
>   note: no newline is added after the newly inserted reminder
> 
> - Do not edit, but close editor without saving

 That's the point.  I think the reason for not adding a newline in the
first place is that it's meant for you to add a message for the
reminder.  And when you do that your editor usually saves a newline.

 I can see that it might seem annoying and easy to reproduce - but I'm
not totally convinced that this should be considered a real bug.  It's
not the way one would use it, *not* writing a message for a reminder in
the first place.  The way to get to the point is pretty constructed in
my experience.

 Do you really insist on adding a newline which would mean that when one
gets faced with the editor one would have to backspace or move the
cursor to the point where they are actually expect to add the reminder
message instead of being right there in the first place?

 Thanks,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#491834: wyrd: 80/23 seems to be an artificial limitation?

[Rhonda D'Vine]

  Hi!

* Ico Doornekamp  [2009-01-12 17:54:08 CET]:
> According to the previous reply, the reported assertion is due to wyrd
> requiring a terminal of at least 80x23 chars. I don't happen to speak
> fluent caml, but after browsing through the source and changing the
> required width and height checks to a smaller size in interface_main.c,
> I was able to run wyrd on a smaller terminal then 80x23 without
> problems.

 I've looked into this myself:  When resizing vertically to fewer than
23 lines, wyrd doesn't crash but states that it requires at least 23
lines.  One can't even quit then until wyrd has more than 23 lines again
and being able to process the Q for quitting.

 When resizing horizontal to less than 80 characters wide it crashes
with the assertion.

 One could argue that the handling from vertical resizing should be
added to the horizontal resizing, I fear that won't make people happy in
the sense that it's not possible to quit there.  I'm not completely sure
what people would expect what wyrd should do when it has less space that
it refuses to start up with.  Maybe instead of ending with an assertion
it should just simply quit at that point and writing out that it doesn't
has the place anymore that it needed in the first place to get started?

 Just some thoughts,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#491834: wyrd: 80/23 seems to be an artificial limitation?

[Rhonda D'Vine]

* Ico Doornekamp <i...@pruts.nl> [2015-11-26 10:49:04 CET]:
> * On 2015-11-26 10:44:28 +0100, Rhonda D'Vine wrote:
> > * Ico Doornekamp <i...@pruts.nl> [2009-01-12 17:54:08 CET]:
> > [...]
> > 
> >  When resizing horizontal to less than 80 characters wide it crashes
> > with the assertion.
> 
> Assertions are not really nice for the end user, IMHO.

 I agree with that. :)

> > [...]
> >
> > Maybe instead of ending with an assertion it should just simply quit
> > at that point and writing out that it doesn't has the place anymore
> > that it needed in the first place to get started?
> 
> What about drawing an empty screen with only the message 'terminal too
> small'?  The user then has the chance to grow the window without having
> to restart? (for example, take a look at 'moc' (music at console), which
> does just that)

 That's what currently happens when reducing to lower than 23 lines.  At
least in my test build of 1.4.6, don't know if that already was the
thing in 1.4.4.  But it should at least be possible to quit from that
stage directly instead of having to resize back up to be able to quit.
(And thanks for the moc sugguestion, will look into it out of personal
interest ;))

 Right now I just want to push the update to 1.4.6 into the pool and
that's the reason why I went through all the old bugreports to see if
some of them has been fixed in the meantime by upstream, so I won't
address this right now, but I want at least try to think about it.

 So long,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#477084: wyrd: Also happens when adding new reminder without adding newline in editor

[Rhonda D'Vine]

Hey. :)

* Ico Doornekamp <i...@pruts.nl> [2015-11-26 10:44:29 CET]:
> * On 2015-11-26 10:23:20 +0100, Rhonda D'Vine wrote:
>  
> >  I know, the reply comes late, but ...  :)
> 
> But still, it comes!
> 
> So, this means wyrd is actually still being developed? That's great!

 Well, I am sorry to not have done this before jessie release.  But I
think I'll provide a backport for the package because I enjoy using it.
I don't know though about what happens upstream so far, but there were
at least two releases in the last years, it's up at 1.4.6 (which I just
before uploaded) so it's not completely dead. :)

> > Do you really insist on adding a newline which would mean that when one
> > gets faced with the editor one would have to backspace or move the
> > cursor to the point where they are actually expect to add the reminder
> > message instead of being right there in the first place?
> 
> Well, my initial annoyance seems to have faded, I guess I've learned to
> live with it :)

 Great.  I'll keep this bugreport open for now, maybe it should get
documented more clearly that people are expected to add the actual
message after the editor fired up and not implicitly expecting people to
do it, but that's something for upstream I assume.

 Enjoy,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#803396: options for developers who don't want to use debian.org XMPP

[Rhonda D'Vine]

 Hi,

* Daniel Pocock  [2015-10-29 17:09:36 CET]:
> If a developer has their own XMPP account elsewhere or simply doesn't
> want to use it, any requests to be in their roster will simply not be
> responded to.  Should we provide an option to automatically reject
> requests sent to accounts that are not used or automatically give some
> reply scripted by the developer?

 I think a forward possibility would be useful.  The LDAP already has a
field for Jabber ID.  I guess it might make sense to forward things to
there; I'm not sure if it's possible to send stuff back somehow then
though.

 Also, if it gets implemented that stuff gets forwarded there people
should be explicitly made aware that this will happen beforehand so that
they can decide if they want to remove the entry from ldap or not.
Maybe a flag might make sense - or a new field that explicitly states
"xmpp messages forwarded to" like we have for "email forwarded to" right
now?

 Just some thoughts,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#772031: Please allow SSL cert and key to be read from different files

[Rhonda D'Vine]

* Paul Muster  [2015-11-04 21:21:39 CET]:
> It's especially _necessary_ to split key, cert and chain to different
> files to be able to use Let's Encrypt certificates.

 Hmm, the PEM format isn't that uncommon, shouldn't that (also) be
turned into a feature request to Let's Encrypt?  There for sure is more
than just ejabberd using PEM format, I've seen and touched a fair amount
of services over time that use that, so I rather see that as a
limitation in Let's Encrypt.

 Given that the letsencrypt client is free software, that would be a
useful approach. https://github.com/letsencrypt/letsencrypt is the
repository, but my python is pretty limited to be able to provide a
patch for that.

 Said that, that doesn't mean I object to ejabberd supporting seperated
files, but that's something for upstream to handle.

 So long,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#772031: Please allow SSL cert and key to be read from different files

[Rhonda D'Vine]

* Paul Muster <p...@muster.net> [2015-11-06 13:50:28 CET]:
> On 06.11.2015 13:03, Rhonda D'Vine wrote:
> > * Paul Muster <p...@muster.net> [2015-11-04 21:21:39 CET]:
> 
> >> It's especially _necessary_ to split key, cert and chain to different
> >> files to be able to use Let's Encrypt certificates.
> 
> This mistakable wording has been clarified >4 hours before your e-mail.

 Well, yes and no.  Your "clearification" didn't transport much new in
that respect:

| It's especially _necessary_ to split key, cert and chain to different
| files to be able to use Let's Encrypt's certificate renewal machanism.

 I pointed out that Let's Encrypt's certificate renewal mechanism is
free software and can (and should) be allowed to combine the different
files.  And even if not, wherever you hook in the renewal mechanism
(cron script?) it should be fairly easy to add the cat into a single
file after it.  So reiterating and keep with that it's _necessary_ isn't
true in that respect.

> >  Said that, that doesn't mean I object to ejabberd supporting seperated
> > files, but that's something for upstream to handle.
> 
> Fine. Yes, of course, this is an upstream topic. Therefore I asked:
> 
> >> Do you know if upstream already has an issue open for this (I
> >> cannot find one)?

 We are working on filing it upstream and will link it from the
bugreport in case it ends up in a public place.  Said that, the upstream
bug tracker is at github and thus open to all github users to use:
https://github.com/processone/ejabberd/issues

 So long,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|