Bug#1056654: ITP: obs-pipewire-audio-capture -- Audio device and application capture for OBS Studio using PipeWire
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
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
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
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
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
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
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
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
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
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
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
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
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
* 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
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
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
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
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
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
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 h
Bug#995843: abook: missing licenses in d/copyright
* 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
* 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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 &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, &l);
+ 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, &lua_filestream::lua_read_data, &lfs,
chunkname.c_str(), NULL);
++ return lua_load(L, &lua_filestream::lua_read_data, &lfs,
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
* 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
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
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
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
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
* Paul Wise [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
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
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
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
* Adam D. Barratt [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 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
+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(&t);
++ 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
+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
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
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
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
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
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
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 &t_8f = "\[38:2:%lu:%lu:%lum" let &t_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
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
Hi, * Emilio Pozuelo Monfort [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
Package: wnpp Severity: wishlist Owner: Rhonda D'Vine * 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
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 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 Uploaders: Rhonda D'Vine 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
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
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
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
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
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
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
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 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. */
+
Bug#849922: rxvt-unicode-256color: tabbed extension requires mouse focus for dead keys
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
Hi,
* Adam D. Barratt [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 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 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_a
Bug#838780: jessie-pu: package irssi/0.8.17-1+deb8u1
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
* 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
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
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
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
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
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
Hi, * Austin English [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" wrote: > > > > > 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), > > >^ > > > > > > > > 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: [pkg-wine-party] Bug#812750: wine: Gecko integration is broken
* Austin English [2016-02-09 17:19:30 CET]: > On Feb 9, 2016 8:15 PM, "Rhonda D'Vine" wrote: > > 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. > > 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#812750: wine: Gecko integration is broken
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#811089: [pkg-bacula-devel] Bug#811089: bconsole: typo forbids non-interactive restore
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
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
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
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
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: Seems to be related to #671780
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#807545: aptitude: creates non-dot directory in user home
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#477084: wyrd: Also happens when adding new reminder without adding newline in editor
Hey. :) * Ico Doornekamp [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#491834: wyrd: 80/23 seems to be an artificial limitation?
* Ico Doornekamp [2015-11-26 10:49:04 CET]: > * On 2015-11-26 10:44:28 +0100, Rhonda D'Vine wrote: > > * Ico Doornekamp [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#491834: wyrd: 80/23 seems to be an artificial limitation?
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#477084: wyrd: Also happens when adding new reminder without adding newline in editor
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#803396: [Debian-rtc-admin] Bug#803396: options for developers who don't want to use debian.org XMPP
Hi, * Matthew Wild [2015-11-06 14:14:26 CET]: > On 6 November 2015 at 09:48, Rhonda D'Vine wrote: > > 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. > > You're basically right. Forwarding could be done, but XMPP is not > email - it's not possible to forward with the same 'from' address, so > it would be a bit unintuitive. Likewise there's no way they could > reply back via debian.org to use the address as an alias. Right, but that information could be added to the forwarded message. Of course people could be concerned about that forward bot (which could even take care of replying) be facilitated as sort of a MITM attack pattern, so it might make sense to have people run such a bot themself on some host they trust. Not so sure about how this would work if it's more than just plain messages though, like OTR (which could be encapseled somehow) or other things like voice/video chat. Those most probably won't be possible to tunnel through a dedicated bot; but maybe my knowledge of the underlying protocol is just too limited to see how that might be possible. 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
* Paul Muster [2015-11-06 13:50:28 CET]: > On 06.11.2015 13:03, Rhonda D'Vine wrote: > > * 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. > > 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|
Bug#772031: Please allow SSL cert and key to be read from different files
* 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|
