Bug#1063936: xxdiff is blind to differences between process substitution inputs
Hi Kingsley, > Please allow me to draw your attention to > a way I think it may be improved. > $ xxdiff <( echo a ) <( echo b ) > > Screen shots of what I saw are attached. > > As you can see in them, replacing > > process substitution > > with > > files > > works. > > So does diff > > $ diff <( echo a ) <( echo b ) > 1c1 > < a > --- > > b > > > My humble suggestion: > > Improve xxdiff to work with process substitution. I think that's an interesting idea, however I'm not sure how easy it is to implement that, and who would have the time to try their hand on this. I notice that using process substitution only works when both inputs are of that kind; comparing process substitution with a regular file results in an Internal error referencing src/buffer.inline.h:76 Florian
Bug#1063927: xpdf: FTBFS with poppler 24.02.0
Hi Amin, On Wed, Feb 14, 2024 at 06:55:51PM -0500, Amin Bandali wrote: > Source: xpdf > Version: 3.04+git20240124-1 > Severity: important > Tags: ftbfs patch upstream fixed-upstream > X-Debbugs-Cc: band...@debian.org > > Dear Maintainer, > > I recently uploaded new poppler 24.02.0 to experimental, and xpdf is > one of the affected packages that fails to build from source with it. > > Please consider cherry-picking upstream commit > 0698734c46d6414c5285d9fa985c3bd4e380aaa8 (also attached to this bug > report for your convenience) to fix the build with the new poppler. thanks for the heads up. I'm going to upload a new upstream version in a minute, which includes the fix. Florian
Bug#1059085: xpdf: text searching is very slow
Hi Vincent, On Wed, Dec 20, 2023 at 04:27:40AM +0100, Vincent Lefevre wrote: > Package: xpdf > Version: 3.04+git20231213-1 > Severity: important > > With the latest version, text searching (Ctrl-F) is very slow. > > For instance, on a PDF document with 3952 pages, with a word > that has no occurrences: > * xpdf 3.04+git20220601-1 takes 8 seconds on an old machine; > * xpdf 3.04+git20231213-1 takes 110 seconds on a new machine. I don't have precise numbers, but in my impression xpdf 3.04+git20240118 (which contains Adam's text search fix and is uploading as I write this, so will take a few hours before being available for download) has become a bit faster searching through large documents. When convenient, could you check again with the same document, so we know for sure? Thanks, Florian
Bug#1060698: [Pkg-auth-maintainers] Bug#1060698: Bug#1060698: yubioath-desktop: Doesn't see yubikeys anymore.
Hi Sébastien, On Sun, Jan 14, 2024 at 02:36:38PM +0100, Sébastien Noel wrote: > for what it's worth, i have been running yubioath with this patch > for ~11 months, so I would feel confident to ship it in Debian > and take responsibility for it very good, I'm going to prepare an upload that includes your patch and will close #1060698 now. Florian
Bug#1060698: [Pkg-auth-maintainers] Bug#1060698: yubioath-desktop: Doesn't see yubikeys anymore.
Hi Sébastien, On Sat, Jan 13, 2024 at 01:34:44PM +0100, Sébastien Noel wrote: > On Sat, 13 Jan 2024 11:26:50 +0100 Florian Schlichting > wrote: > > > > [...] > > While it might be possible to patch py/yubikey.py to work with the > > interface changes in current python3-ykman, I doubt this is a > > sensible thing to do if upstream has decided to abandon > > the QT version. > > in case you are interested, you can find the patch in attachement thank you for the patch. I'm not opposed to applying it. In my superficial testing, it seems to work well. I'm not a user of yubioath-desktop, though, and while I can help with an occasional upload, I don't want to feel responsible for it. Are you able to keep an eye on yubioath-desktop in Debian and, if necessary, respond to upcoming issues? Do you want to submit your patch upstream, so that we can see what they think, and other distributions can find your work? Florian
Bug#1060698: [Pkg-auth-maintainers] Bug#1060698: yubioath-desktop: Doesn't see yubikeys anymore.
Hi Freagarach, On Sat, Jan 13, 2024 at 07:40:42AM +0100, Freagarach wrote: > since yesterday the problem holding back python3-ykman (and related packages) > was resolved, I upgraded my system today. > When trying to use the GUI for yubikeys (this package), my yubikeys were not > shown. I could use the terminal (yubikey-manager CLI) to do my tasks. > > It seems that this package relies on a lower version of its dependencies. I > can't really test due to the dependency issues that introduces. apparently, yes. Starting yubioath-desktop from the commandline, I get $ yubioath-desktop qrc:/qml/main.qml:305:5: QML Shortcut: Shortcut: Only binding to one of multiple key bindings associated with 7. Use 'sequences: [ ]' to bind to all of them. qrc:/qml/main.qml:297:5: QML Shortcut: Shortcut: Only binding to one of multiple key bindings associated with 9. Use 'sequences: [ ]' to bind to all of them. Qt Quick Layouts: Detected recursive rearrange. Aborting after two iterations. Qt Quick Layouts: Detected recursive rearrange. Aborting after two iterations. "PyOtherSide error: Traceback (most recent call last):\n\n File \"qrc:///py/yubikey.py\", line 23, in \nfrom ykman.device import scan_devices, list_all_devices, connect_to_device, get_name, read_info\n\nImportError: cannot import name 'connect_to_device' from 'ykman.device' (/usr/lib/python3/dist-packages/ykman/device.py)\n" Unhandled PyOtherSide error: Cannot import module: yubikey (Traceback (most recent call last): File "qrc:///py/yubikey.py", line 23, in from ykman.device import scan_devices, list_all_devices, connect_to_device, get_name, read_info ImportError: cannot import name 'connect_to_device' from 'ykman.device' (/usr/lib/python3/dist-packages/ykman/device.py) ) "PyOtherSide error: Traceback (most recent call last):\n\n File \"\", line 1, in \n\nNameError: name 'yubikey' is not defined\n" Unhandled PyOtherSide error: Function not found: 'yubikey.init' (Traceback (most recent call last): File "", line 1, in NameError: name 'yubikey' is not defined ) "PyOtherSide error: Traceback (most recent call last):\n\n File \"\", line 1, in \n\nNameError: name 'yubikey' is not defined\n" Unhandled PyOtherSide error: Function not found: 'yubikey.controller.check_descriptors' (Traceback (most recent call last): File "", line 1, in NameError: name 'yubikey' is not defined ) qml: TypeError: Cannot read property 'success' of undefined undefined "PyOtherSide error: Traceback (most recent call last):\n\n File \"\", line 1, in \n\nNameError: name 'yubikey' is not defined\n" Unhandled PyOtherSide error: Function not found: 'yubikey.controller.is_win_non_admin' (Traceback (most recent call last): File "", line 1, in NameError: name 'yubikey' is not defined ) qml: TypeError: Cannot read property 'winNonAdmin' of undefined undefined > I know there is #1034701, so this report might be considered an escalation of > that, but I'm not too comfortable (yet) with Debian policies. I fear this means the end of yubioath-desktop in Debian, as long as flutter isn't packaged (see #931793). The "legacy" branch on Github doesn't seem to have received any commits since the release of version 6.0.0. While it might be possible to patch py/yubikey.py to work with the interface changes in current python3-ykman, I doubt this is a sensible thing to do if upstream has decided to abandon the QT version. Florian
Bug#1060266: [Pkg-auth-maintainers] Some help for coordinated uploads needed
Hi Philip, On Sun, Dec 24, 2023 at 10:25:21PM +0100, Philip Rinn wrote: > things changed a bit - Arch Linux picked up my patch and I think with > testing in two distributions, we will have enough momentum to get possible > bugs ironed out. > > I'll prepare an upload of solo1-cli with my patch targeting experimental > during the next days. I hope this makes it possible to push the transition > forward during January. I would like to do an upload of yubikey-manager very soon in order to fix #1060266 (serious) in python3-ykman. Can we perhaps do an upload of python-fido2 to unstable in the course of this weekend? Do you want to do that yourself, so you can update solo1-cli at the same time, or are you ok with me going ahead and you follow with solo1-cli whenever convenient? Best, Florian
Bug#1060060: libclipboard-perl: 'clipbrowse' from Debian package libclipboard-perl executing clipboard contents
On Sat, Jan 06, 2024 at 12:18:20AM +0100, gregor herrmann wrote: > Just a short note: I had a very quick look this afternoon, and when I > added the quotes, clipbrowse simply didn't work anymore (it opened a > new firefox window (not a tab as without the quotes) with an empty > address bar and an obviously empty page)). I didn't have the time for > further investigation but my impression was that simply adding back > the quotes was not enough. I must admit I did not test this with firefox (only google-chrome), but I have done some testing now with "export BROWSER=firefox" set. In my testing both work fine when the clipboard contains just a proper URL. Newlines seem to be ignored / removed, and the second line concatenated to the first. This might be useful in case the MUA broke a long URL. Firefox will display a new empty window when the clipboard contains a blank, while chrome changes that blank to %20 and displays the resulting URL in a new tab. Chrome on the other hand will display a new empty window when the clipboard contains a pipe. IMHO both failure modes are acceptable, as in those cases the clipboard doesn't just contain a URL but some other garbage as well. Apparently the "I'm feeling lucky" part mentioned in the clipbrowse manpage is no longer implemented in Firefox. And there's clipjoin, which will remove some whitespace and pipe characters... Florian
Bug#1060060: libclipboard-perl: 'clipbrowse' from Debian package libclipboard-perl executing clipboard contents
Hi Sebastiaan,
thank you for bringing this to our attention.
> Example: Copy the following 2 lines present into the clipboard, then run the
> 'clipbrowse' command:
>
> https://www.example.com
> echo echo p0wned | sh
>
> This results in the browser opening the requested URL in the foreground, while
> simultaneous running the specified command in the background.
indeed :-(
> I believe the cause of this is by not enclosing a variable with doublequotes:
>
> The original sourcecode (
> https://github.com/shlomif/Clipboard/blob/master/scripts/clipbrowse ) has
> doublequotes around the variable %s
> my $browser = $ENV{BROWSER} || 'chromium-browser "%s"';
> And performs some string sanitizing in other lines.
>
> The Debian version does not have these quotes, making the string sanitizing
> ineffective:
> '/usr/bin/clipbrowse' contains the following line:
> my $browser = $ENV{BROWSER} || 'sensible-browser %s';
>
> I have not checked if other packages that have been changed to use sensible-
> browser have the same issue.
I'm going to upload a new version which adds the missing quotes in that
line as well for the case where the user specifies BROWSER without
including a %s. I've opened a PR upstream to fix that second case.
I'm unsure if that's sufficient, or if we should work to get the fix
into (old-)stable versions of Debian as well. What do other Perl team
members think?
Florian
Bug#1059084: xpdf: text searching from the first page does not find matches on the other pages
On Wed, Dec 20, 2023 at 04:45:46AM +0100, Vincent Lefevre wrote: > On 2023-12-20 04:23:00 +0100, Vincent Lefevre wrote: > > Package: xpdf > > Version: 3.04+git20231213-1 > > Severity: normal > > > > When one does a text search (Ctrl-F) from the first page of > > a PDF document that has several pages, only the matches on > > the first page are obtained. > > Note that on a large document, this is very slow (see bug 1059085), > meaning that the search does not stop at the first page, but it > fails on the other pages. I can somewhat confirm this, and I think it has to do with document size, or the amount of text between matches. On a 6-page-PDF, I get matches from all pages when searching for a frequent word, however when searching for a word occurring on only some of the pages, I only get matches from the current, sometimes the next page. When looking at PDFCore::findU, I'd think this is happening on the poppler side, however I notice while evince will also take its time searching a 300+ pages PDF, it can find many occurrences throughout the entire document. Hopefully Adam has an idea what's going wrong here? Florian
Bug#996832: xpdf: segmentation fault in case of incorrect Xpdf*font X resource
Hi Vincent and Adam, On Wed, Dec 01, 2021 at 08:23:07PM +, Adam Sampson wrote: > (in the original report) > > Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set > > On Fri, Oct 22, 2021 at 02:34:44AM +0200, Vincent Lefevre wrote: > > And if I give an explicit UTF-8 font such as > > Xpdf*font: -misc-fixed-medium-r-normal--13-120-75-75-c-80-iso10646-1 > > I get complete garbage (lots of white squares). > > After some investigation, this appears to be the result of a fault in > Motif that makes it fail to understand your locale settings. > It looks like _XmStringGetCurrentCharset detects the charset in use by > looking at LANG, and doesn't know about LC_CTYPE. (I'm not sure why it > doesn't use nl_langinfo(CODESET).) So this probably needs filing > separately against the motif package... > > > I'm also wondering how Xft fonts can be used. Syntax like > > xft:Bitstream:size=9 (as used by fvwm) doesn't work. > > I've just made some changes to the xpdf man page to document this > better (and I've also made the -font argument map to the font resource, > rather than fontList, since the latter doesn't always override the > default styling in Motif). On Thu, Dec 02, 2021 at 01:15:13AM +0100, Vincent Lefevre wrote: > This seems fine and would actually solve bug 996831. I'm wondering if there's anything left to do in xpdf here, or if I can close this bug now? The original segfault is fixed and the font setting much improved. In my testing it's still possible to confuse Motif with using different charsets in LANG and LC_CTYPE together with an X core font, but not with Xft fonts... Florian
Bug#996831: xpdf: please update the xpdf(1) man page concerning font settings
Hi Vincent, On Tue, Oct 19, 2021 at 02:44:44PM +0200, Vincent Lefevre wrote: > Package: xpdf > Version: 3.04+git20211001-1 > Severity: wishlist > > Since the switch to Xft font, a part of the man page became obsolete: > >-font font > (-fn is equivalent.) [X resource: xpdf*fontList] > > This no longer affects the interface (except the zoom menu: > see bug 996830). The new way of setting fonts for the interface > (via options and/or X resources) should be documented. I meant to work on this, but I can't seem to find the kind of time these days where I start by familiarizing myself with a part of xpdf that I never used. Would you be able to suggest the new text that you would like to see in the manpage, or even send a patch? Best, Florian
Bug#1057007: libconfig-model-tkui-perl: autopkgtest for libconfig-model-itself-perl fails with libconfig-model-tkui-perl 1.377
Package: libconfig-model-tkui-perl
Version: 1.377-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: Dominique Dumont
Hi dod,
last week I updated libconfig-model-tkui-perl from 1.376-1 to 1.377-1
and now libconfig-model-itself-perl fails one of its autopkgtests, as
can be seen on https://tracker.debian.org/pkg/libconfig-model-tkui-perl
Relevant part from the test log at
https://ci.debian.net/data/autopkgtest/testing/amd64/libc/libconfig-model-itself-perl/40239936/log.gz
...
188s t/itself-editor.t ..
188s ok 1 - compiled
188s # You can play with the widget if you run the test with '--show' parameter
188s # Running tests in wr_root/itself-editor
188s ok 2 - loaded Master model
188s ok 3 - created master_model instance
188s ok 4 - loaded some data in master_model instance
188s ok 5 - Read Itself::Model and created instance
188s ok 6 - Read all models in data dir
188s ok 7 - window launched
188s ok 8 - Tk UI step 0 view done
188s ok 9 - Tk UI step 1 open_class done
188s ok 10 - Tk UI step 2 open_instance done
188s ok 11 - Tk UI step 3 save done
188s ok 12 - Tk UI step 4 open test window done
188s ok 13 - Tk UI step 5 reopen test window done
188s ok 14 - Tk UI step 6 exit done
188s # testing memory cycles. Please wait...
188s not ok 15 - memory cycles
188s
188s # Failed test 'memory cycles'
188s # at t/itself-editor.t line 155.
188s # Cycle #1
188s # Config::Model A->{instances} => %B
188s # %B->{itself_instance} => Config::Model::Instance C
188s # Config::Model::Instance C->{on_change_cb} =>
188s # closure , $cw => $E
188s # $E => Config::Model::Itself::TkEditUI F
188s # Config::Model::Itself::TkEditUI F->{id} => Tk::After::Cancelled G
188s # Tk::After::Cancelled G->[0] => Config::Model::Itself::TkEditUI F
188s # Cycle #2
188s # Config::Model A->{instances} => %B
188s # %B->{itself_instance} => Config::Model::Instance C
188s # Config::Model::Instance C->{on_change_cb} =>
188s # closure , $cw => $E
188s # $E => Config::Model::Itself::TkEditUI F
188s # Config::Model::Itself::TkEditUI F->{id} => Tk::After::Cancelled G
188s # Tk::After::Cancelled G->[4] => Tk::Callback H
188s # Tk::Callback H->[0] =>
188s # closure , $cw => $J
188s # $J => Config::Model::Itself::TkEditUI F
188s # Cycle #3
188s # Config::Model A->{instances} => %B
188s # %B->{itself_instance} => Config::Model::Instance C
188s # Config::Model::Instance C->{on_change_cb} =>
188s # closure , $cw => $E
188s # $E => Config::Model::Itself::TkEditUI F
188s # Config::Model::Itself::TkEditUI F->{instance} =>
Config::Model::Instance C
188s # Cycle #4
188s # Config::Model A->{instances} => %B
188s # %B->{itself_instance} => Config::Model::Instance C
188s # Config::Model::Instance C->{on_change_cb} =>
188s # closure , $cw => $E
188s # $E => Config::Model::Itself::TkEditUI F
188s # Config::Model::Itself::TkEditUI F->{store_sub} =>
188s # closure , $rw_obj => $L
188s # $L => Config::Model::Itself M
188s # Config::Model::Itself M->{config_model} => Config::Model A
188s # Cycle #5
188s # Config::Model A->{instances} => %B
188s # %B->{itself_instance} => Config::Model::Instance C
188s # Config::Model::Instance C->{on_change_cb} =>
188s # closure , $cw => $E
188s # $E => Config::Model::Itself::TkEditUI F
188s # Config::Model::Itself::TkEditUI F->{store_sub} =>
188s # closure , $rw_obj => $L
188s # $L => Config::Model::Itself M
188s # Config::Model::Itself M->{meta_instance} => Config::Model::Instance C
188s # Cycle #6
188s # Config::Model A->{instances} => %B
188s # %B->{itself_instance} => Config::Model::Instance C
188s # Config::Model::Instance C->{on_change_cb} =>
188s # closure , $cw => $E
188s # $E => Config::Model::Itself::TkEditUI F
188s # Config::Model::Itself::TkEditUI F->{test_model} => Config::Model N
188s # Config::Model N->{instances} => %O
188s # %O->{MasterModel} => Config::Model::Instance P
188s # Config::Model::Instance P->{on_change_cb} =>
188s # closure , $cw => $R
188s # $R => Config::Model::TkUI S
188s # Config::Model::TkUI S->{instance} => Config::Model::Instance P
188s # Cycle #7
188s # Config::Model A->{instances} => %B
188s # %B->{itself_instance} => Config::Model::Instance C
188s # Config::Model::Instance C->{on_change_cb} =>
188s # closure , $cw => $E
188s # $E => Config::Model::Itself::TkEditUI F
188s # Config::Model::Itself::TkEditUI F->{test_widget} =>
Config::Model::TkUI S
188s # Config::Model::TkUI S->{instance} => Config::Model::Instance P
188s # Config::Model::Instance P->{on_change_cb} =>
188s # closure , $cw => $R
188s # $R => Config::Model::TkUI S
188s 1..15
188s # Looks like you failed 1 test of 15.
188s Dubious, test returned 1 (wstat 256, 0x100)
188s Failed 1/15 subtests
I'm sorry I don't even have an idea where this is showing a problem,
much less
Bug#1031666: Missing Dependencies: Geo::Point
Hi, On Mon, Feb 20, 2023 at 07:10:49AM +0800, Dan Jacobson wrote: > Package: libgis-distance-perl > Version: 0.19-2 > > Man page has >my $point1 = Geo::Point->latlong( $lat1, $lon1 ); > but > Can't locate object method "latlong" via package "Geo::Point" (perhaps > you forgot to load "Geo::Point"?) > > Therefore where to get Geo::Point should at least be in the Package > Recommends. > > No, it's not in libgeo-distance-perl. it's in its own distribution, Geo::Point, see https://metacpan.org/dist/Geo-Point/view/lib/Geo/Point.pod, which is not currently packaged for Debian. However that's just sugar because, as the manpage explains, you can just feed the decimal latitude and longitude to the distance method directly: # Returns a Class::Measure object. my $distance = $gis->distance( $lat1, $lon1, $lat2, $lon2 ); Florian
Bug#1045725: [Pkg-auth-maintainers] Bug#1045725: python-fido2: Fails to build source after successful build
Control: fixed 1045725 1.1.2-1 On Sun, Aug 13, 2023 at 09:21:12PM +0200, Lucas Nussbaum wrote: > > dpkg-source -b . > > dpkg-source: info: using source format '3.0 (quilt)' > > dpkg-source: info: verifying ./python-fido2_0.9.1.orig.tar.gz.asc > > dpkg-source: info: building python-fido2 using existing > > ./python-fido2_0.9.1.orig.tar.gz > > dpkg-source: info: building python-fido2 using existing > > ./python-fido2_0.9.1.orig.tar.gz.asc > > dpkg-source: info: local changes detected, the modified files are: > > python-fido2-0.9.1/fido2.egg-info/PKG-INFO > > python-fido2-0.9.1/fido2.egg-info/requires.txt > > dpkg-source: error: aborting due to unexpected upstream changes, see > > /tmp/python-fido2_0.9.1-1.diff.BzH8TD fido2 1.1.2 no longer ships the fido2.egg-info directory in the upstream tarball, so this issue does not occur any more. The -1 also gets rid of the override_dh_clean, which fixes the very similar looking #1052899 Florian
Bug#982314: mpd: 100% of CPU time on ARM Cortex A8 when playing 88.2kHz flac
Hi Stefan, On Sun, Feb 07, 2021 at 10:29:30PM -0500, Stefan Monnier wrote: > I'm pretty sure this is not a bug in MPD but probably in some of the > libraries it uses (libresample, maybe?). > > Usually, when playing 44.1kHz flac files on my ARM SoC based on > Allwinner A10 (with one ARM Cortex A8), the CPU use of MPD is > negligeable (<10%), but when playing flac files sampled at 88.2kHz the > CPU is pegged at 100% and the playback frequently skips because the > CPU can't keep up. this bug has been open for quite some time without getting any comments or updates. Certainly from my part, this is because I have little knowledge in this area and don't even have suggestions how to shed some more light on what's going on. Given that, do you think it's worth it keeping this bug open? Best, Florian
Bug#1034783: vpnc: after upgrading vpnc to vesion: 0.5.3+git20220927-1 , not connecting no longer connect to router
Hi giorgi, > This problem started after the update vpnc to version 0.5.3+git20220927-1 . > After this update no longer conects to router. > > iI tried to install the previous version of vpnc, after which the situation > was corrected. The previous version of vpnc works fine and connects to the > router. this isn't much information to diagnose any problems. Can you try running vpnc from a terminal, is there an error message or other output? Then, can you try running both old an new versions with --debug set to 1 or 2, and compare the output? There isn't much substantial change between the versions, mainly the addition of MODP groups 14-18 and increased strictness with regard to cryptographic algorithms, adding options --enable-weak-encryption and --enable-weak-authentication; however there should be error messages if a connections fails because of this. Florian
Bug#1034236: mpd: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Control: severity ! important On Fri, Apr 21, 2023 at 03:24:25PM +0200, Geoffroy Youri Berret wrote: > Le 11/04/2023 à 23:52, Florian Schlichting a écrit : > > […] > > I think we should take a step back and think about how a freshly > > installed mpd package should look like. I think it may actually be a > > feature that the system mpd.service is not enabled and started on a > > fresh install. On most desktop/laptop machines, leaving the system > > service off and enabling the user service is probably the better thing > > to do. How long has dh-installsystemd been disregarding our unit files? > > We may want to add --no-enable when we apply that patch. > > > > So I think in the case of mpd, perhaps nothing is severely broken > > currently and this bug doesn't require fixing for bookworm. Instead, it > > can perhaps be downgraded and fixed with the next regular upload, after > > the release? > > I agree, this is the best thing to do. > The package is not broken enough to require a fix, it's actually not really > broken it's only not enabling/starting system unit which, I believe, is not > the main use of MPD anyway. Since we agree, I don't think we need to wait any further and can get ourselves off the release-critical bugs list right away :-) Let's fix this first thing in trixie, and also add an override for dh_installsystemd --no-enable Florian
Bug#1034236: mpd: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
I'm AFK this week so won't be able to do an upload either. I agree that putting the unit files where systemd.pc says they should go is probably the right thing to do. However it feels nonsensical to move files from /usr/lib to /lib only so they can be moved back by the /usr-merge; reading #1031695 I don't see anybody saying this is a sensible thing to do... I think we should take a step back and think about how a freshly installed mpd package should look like. I think it may actually be a feature that the system mpd.service is not enabled and started on a fresh install. On most desktop/laptop machines, leaving the system service off and enabling the user service is probably the better thing to do. How long has dh-installsystemd been disregarding our unit files? We may want to add --no-enable when we apply that patch. So I think in the case of mpd, perhaps nothing is severely broken currently and this bug doesn't require fixing for bookworm. Instead, it can perhaps be downgraded and fixed with the next regular upload, after the release? (In addition to fresh installs, we may also want to think about upgrades - do running daemons get restarted? Also in the --user case?) Florian Am 11. April 2023 21:01:02 MESZ schrieb Geoffroy Youri Berret : >On 4/11/23 17:57, Max Kellermann wrote: >> On 2023/04/11 17:40, Andreas Henriksson wrote: >>> I think 2 is better myself and I'm attaching a proof of concept >>> debdiff to implement it. (You might want to make a cleaner version.) >> >> Agree. I think your patch looks quite clean, and if it were submitted >> to me, I'd merge it (the same would probably be necessary for the user >> units). > >Here is an updated version (with user unit patch). > >I did not get through all the thread in #1031695 then I'm not sure about user >unit location, but relying on systemd.pc ship them in /usr/lib/systemd/user/, >hopes it's fine. > >Please review, I'm not super confident with my meson expertise. > >I wont be able push these changes until next week, then please go ahead if >needed. > >Cheers, >k
Bug#1032074: libdbd-mysql-perl: SSL connection error: Enforcing SSL encryption is not supported
Hi,
On Mon, Feb 27, 2023 at 01:34:49PM +0100, root wrote:
> In the meantime I installed the Debian updates e.g., mariadb and libssl.
> Apparently, libgnutls
> was at least a day before that.
have you had a look at the changelog for these updates?
>
> When I now try to connect I receive:
>
> DBI
> connect('database=MList;mysql_ssl=1;mysql_ssl_client_key=/etc/postfix/mlist.key.pem;mysql_ssl_client_cert=/etc/postfix/mlist.cert.pem;mysql_ssl_ca_file=/etc/certs/cacert.pem;host=mysql.example.com','mlist',...)
> failed: SSL connection error: Enforcing SSL encryption is not supported at
> /usr/local/lib/mlist/MListDB.pm line 189.
Looking up your error message in Google ("Enforcing SSL encryption is
not supported") turns up
https://github.com/perl5-dbi/DBD-mysql/issues/333
Do you use the "mysql_ssl_verify_server_cert=1" connection option? Have
you tried setting "mysql_ssl_optional=1"?
HTH, Florian
Bug#1031858: prometheus-node-exporter-collectors: locale issue leads to an unparseable ipmitool_sensor textfile
Package: prometheus-node-exporter-collectors Version: 0.0~git20230203.6f710f8-1 Severity: important Dear Maintainer, this is basically #992409 again, this time for ipmitool_sensor. From prometheus-node-exporter journal: Feb 24 11:22:57 somehost prometheus-node-exporter[1134804]: ts=2023-02-24T10:22:57.507Z caller=textfile.go:227 level=error collector=textfile msg="failed to collect textfile data" file=ipmitool_sensor.prom err="failed to parse textfile data from \"/var/lib/prometheus/node-exporter/ipmitool_sensor.prom\": text format parsing error in line 3: expected float as value, got \"21,00\"" The hotfix is a /etc/systemd/system/prometheus-node-exporter-ipmitool-sensor.service.d/override.conf file setting [Service] Environment=LC_NUMERIC=C but this should preferably be set in /lib/systemd/system/prometheus-node-exporter-ipmitool-sensor.service or even fixed in the ipmitools awk script upstream.. Thanks, Florian
Bug#1029371: ITP: libgis-distance-perl -- Perl module to calculate geographic distances
Hi Andrew, On Sat, Jan 21, 2023 at 11:04:29PM +0100, Andrej Shadura wrote: > Control: submitter -1 Florian Schlichting > On Sat, 21 Jan 2023 22:36:26 +0100 Florian Schlichting wrote: > > > From: Florian Schlichting @fschlich.dialup.fu-berlin.de > > I believe your reportbug is misconfigured. thanks for fixing this mess! I had forgotten about it, but the bug is https://github.com/bruceg/nullmailer/issues/79 Florian
Bug#1023872: [Pkg-mpd-maintainers] Bug#1023872: mpd: 0.23.9-1+b3 fails to start with 'io_uring_get_sqe() failed'
On Tue, Nov 15, 2022 at 05:40:13PM +0300, Michael Tokarev wrote: > This is #1023654 , fwiw. which is now fixed, but mpd will need a rebuild to pick up the tightened dependency. I'll look into uploading 0.23.10 over the next few days. Florian
Bug#1002855: mpd: Installation fails: invoke-rc.d: initscript mpd, action "restart" failed
Hi, On Thu, Dec 30, 2021 at 06:04:30AM -0300, Eppur Si Muove wrote: > I'm with this new installation of a virtual machine of Debian Testing, using > runit as init, > and I wanted to install mpd, but that process returned this: > ... > Configurando mpd (0.23.5-1+b1) ... > /etc/mpd.conf must have pid_file set; cannot stop daemon. ... failed! > invoke-rc.d: initscript mpd, action "restart" failed. > dpkg: erro ao processar o pacote mpd (--configure): > o subprocesso instalado, do pacote mpd, o script post-installation retornou > erro do status de saída 1 > Erros foram encontrados durante o processamento de: > mpd > E: Sub-process /usr/bin/dpkg returned an error code (1) it becomes difficult to support systemd and alternative init systems at the same time. The /etc/mpd.conf file that comes with the package is configured to be used with systemd, and thus doesn't set pid_file or log_file any more. However the init script expects it to be there and won't run if it isn't. I might accept a patch to the initscript to not fail with the mpd.conf shipped by the package, but I won't have time to develop one myself. > I tried the following workaround: > - # reboot > - uncommented the line aboud PID file in /etc/mpd.conf > - # mkdir /run/mpd > - # touch /run/mpd/pid > - # chown mpd /run/mpd/pid > - # apt upgrade I would expect it to be enough to uncomment the pid_file line and run sudo dpkg --configure -a However if you weren't going to use and configure mpd just yet, I would expect leaving mpd.conf as-is and just disabling mpd should also do the trick: sudo update-rc.d disable mpd Florian
Bug#1004285: [DAViCal-devel] Bug#1004285: fixed in davical 1.1.11-1
Hi Benno, On Mon, Oct 10, 2022 at 12:46:57PM +0200, Benno Overeinder wrote: > Unfortunately the problem persists after updating to davical 1.1.11-1. I see > the same messages in the Apache2 error.log as previously reported. looking at your error log from February, I think the crucial part is Fri Feb 18 21:14:58.430957 2022] [php:notice] [pid 49689] [client 192.168.1.1:64517] davical: BUG: :DAViCal Fatal Error: [0A000] SQLSTATE[0A000]: Feature not supported: 7 ERROR: set-returning functions are not allowed in CASE... This sounds like https://gitlab.com/davical-project/davical/-/issues/171 The important bit is to make sure that update-davical-database is run from the new package, and that it has replaced the expand_memberships function to not contain a CASE statement any more. Florian
Bug#1012587: [Pkg-auth-maintainers] Bug#1012587: /usr/share/doc/yubikey-manager empty
Hi Marc, On Thu, Jun 09, 2022 at 09:54:38PM +0200, Marc Haber wrote: > Package: yubikey-manager > Version: 4.0.7-1 > Severity: serious > > Justification: Policy 2.3, Policy 4.4 > > /usr/share/doc/yubikey-manager is completly empty. Thus, the required > copyright and changelog files are missing. ... > [5/5074]mh@drop:~ $ ls -al /usr/share/doc/yubikey-manager > total 0 > drwxr-xr-x 1 root root0 Nov 1 2020 ./ > drwxr-xr-x 1 root root 100K Jun 8 17:09 ../ $ ls -al /usr/share/doc/yubikey-manager lrwxrwxrwx 1 root root 13 24. Mär 2021 /usr/share/doc/yubikey-manager -> python3-ykman /usr/share/doc/yubikey-manager is a symlink, python3-ykman is built from the same source. It used to be a directory, but was transitioned to the symlink in October 2020 (and this needed to be fixed in March 2021). However, I wonder if Taowa got the maintscript's prior-version (4.0.0~) right, because the fix happened after 4.0.0~a1-2 and 4.0.0~ is less than that. So people who had upgraded with unstable to 4.0.0~a1-2 will not have had the fixed maintscript trigger on their systems. Does that make sense? How do we fix this, upload a 4.0.8-1 with prior-version set to 4.0.8-1~, and keep that until after the bookworm release, no? Florian
Bug#818547: RFH: vpnc -- Cisco-compatible VPN client
Control: retitle 818547 RFA: vpnc -- Cisco-compatible VPN client I request vpnc to be adopted. I no longer have access to a VPN server where I could test the binary built by this package, and while not much is happening upstream and it is very low maintenance, I don't feel comfortable to rely on users to ensure even basic functionality.
Bug#1011047: New version of vpnc with security improvements
Hi Andreas, > I've compiled the binary in a build VM on my Debian 11 workstation and tried > it against our Cisco VPN concentrator appliance VM > using dh14 for DH key-exchange. Unfortunately we do not have public accounts > for testing, but I could test the new packages here. > So far, I'm not aware of any public Cisco IPSec servers for general testing. > Guess due to the licensing and maintenance it > might be difficult to find any. > > If it helps, I could assist you in the testing of new vpnc packages. I've just uploaded the new version, which will close this bug soonish. Please test the new package if you can. Florian
Bug#1011047: New version of vpnc with security improvements
Package: vpnc Version: 0.5.3+git20210125-1 Hi Andreas, the canonical way would be to open a bug against vpnc in the Debian BTS, which I'm doing right now (Cc:). I've had a brief look at the current upstream git version, and I think it should be easy to update the Debian package. However, as I've lost access to any ipsec VPN concentrator, once it compiles I have no way to test the resulting package. Do you know of any publicly available services, by chance? I guess I should make it more clear that I need to pass on maintenance of vpnc in Debian... Florian On Tue, May 10, 2022 at 02:59:56PM +0200, Andreas Erhard wrote: > Hi Florian, > > thank you very much for maintaining so many Debian packages. Concerning the > VPN-Client vpnc, I'd have an update proposal and could not find another > point of contact (such as "report outdated package" for Arch Linux) so > sorry for bothering you with this request. > > In the latest version, vpnc supports way stronger key exchange security. The > Modular Exponential (MODP) Diffie-Hellman groups 14 to 18 (2048 bits to 8192 > bits) as specified in RFC3526 are now supported. We also tested the enhanced > key exchange on a Cisco IPSec VPN appliance. > > The new version is already packaged in the extra repo for Arch Linux[1], > I've opened an issue for OpenWRT[2] as well which is pending at the moment. > > As the patches greatly improve the security and interoperability of vpnc, it > would be great to get this update included in Debian. How would be the best > procedure for that? > > Thank you very much, best regards from Tyrol > > Andreas Erhard > > [1] https://archlinux.org/packages/?name=vpnc > [2] https://github.com/openwrt/packages/issues/18477
Bug#1004285: Fwd: Re: [DAViCal-devel] Bug#1004285: Bug#1004285: davical: problems after upgrade to php 8, calendar clients reports "500"
Hi Benno, I just realized this email didn't reach the Debian BTS and may not have reached you. It's probably best to keep both the bug (and thus davical-devel) in Cc. Florian - Forwarded message from Andrew Ruthven - From: Andrew Ruthven To: davical-de...@lists.sourceforge.net Date: Sat, 19 Feb 2022 16:59:37 +1300 Subject: Re: [DAViCal-devel] Bug#1004285: Bug#1004285: davical: problems after upgrade to php 8, calendar clients reports "500" Hi Benno, Those SQL errors are most likely the problem. Do they only appear with PHP 8? What version of PostgreSQL are you using? Cheers, Andrew On Fri, 2022-02-18 at 21:39 +0100, Benno Overeinder wrote: > [Fri Feb 18 21:14:58.430957 2022] [php:notice] [pid 49689] [client > 192.168.1.1:64517] davical: BUG: :DAViCal Fatal Error: [0A000] > SQLSTATE[0A000]: Feature not supported: 7 ERROR: set-returning > functions are not allowed in CASE\nLINE 4: ... expanded.g_id FROM > (SELECT CASE WHEN $2 > 0 THEN expand_mem...\n > ^\nHINT: You might be able to > move > the set-returning function into a LATERAL FROM item.\nQUERY: \n > SELECT > group_id FROM group_member WHERE member_id = $1\n UNION\n > SELECT > expanded.g_id FROM (SELECT CASE WHEN $2 > 0 THEN expand_memberships( > group_id, $2 - 1) END AS g_id\n FROM > group_member WHERE member_id = $1) AS expanded\n > WHERE expanded.g_id IS NOT NULL;\n\nCONTEXT: SQL function > "expand_memberships" during startup\nSQL statement "SELECT > bit_or(subquery.privileges) FROM\n (\n > SELECT > privileges FROM grants WHERE by_principal=in_grantor AND > by_collection > IS NULL\n AND > (to_principal=in_accessor OR to_principal IN (SELECT > expand_memberships(in_accessor,in_depth)))\n UNION\n > SELECT 32::BIT(24) AS privileges FROM > expand_memberships(in_accessor,in_depth) WHERE expand_memberships = > in_grantor\n ) AS subquery"\nPL/pgSQL function > pprivs(bigint,bigint,integer) line 14 at SQL statement at > /usr/share/awl/inc/AwlDatabase.php:94 -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz | ___ DAViCal-devel mailing list davical-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/davical-devel - End forwarded message -
Bug#1004285: [DAViCal-devel] Bug#1004285: davical: problems after upgrade to php 8, calendar clients reports "500"
Hi Benno, > I have looked at the apache2 log files and checked the /etc/php and > /etc/davical directories if there were any references to php7 instead > of php/php8. The apache2 log file reported > > [Mon Jan 24 11:29:29.678647 2022] [php:notice] [pid 684] [client /IPv6 > address/] davical: LOG: response:-->DAViCal Fatal Error Andrew fixed many issues with PHP 8 over the last few days. Are you able to test with git versions of AWL and DAViCal? Otherwise it would be helpful if you can find a few more lines from your logs containing the PHP backtrace identifying the exact place in the code where the fatal error occurred, as well as the PHP error message. Florian
Bug#1005449: [DAViCal-devel] Bug#1005449: awl: FTBFS: sh: 1: error: Problems running dot: exit code=127, command='dot', arguments='"/<>/docs/api/inherit_graph_10.dot" -Tpng -o "/<
On Sun, Feb 13, 2022 at 08:00:15AM +0100, Lucas Nussbaum wrote: > Source: awl > Version: 0.62-1 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20220212 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > >dh_auto_test > > make -j4 test > > make[1]: Entering directory '/<>' > > # simple php syntax check > > OK (Syntax checked) > > # run phpunit tests > > PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:./vendor/bin/ > > phpunit tests/ > > PHPUnit 9.5.13 by Sebastian Bergmann and contributors. > > > > > > Warning: Test case class not matching filename is deprecated > >in /<>/tests/myComponentTest.php > >Class name was 'vComponentTest', expected 'myComponentTest' > > Warning: Test case class not matching filename is deprecated > >in /<>/tests/myPropertyTest.php > >Class name was 'vPropertyTest', expected 'myPropertyTest' > > > > RE...R... 41 / 41 > > (100%) > > > > Time: 00:00.007, Memory: 6.00 MB > > > > There was 1 error: > > > > 1) myCalendarTest::test2 > > TypeError: implode(): Argument #2 ($array) must be of type ?array, string > > given > > > > /<>/tests/myCalendarTest.php:61 > > > > -- > > > > There were 2 risky tests: > > > > 1) myCalendarTest::test1 > > This test did not perform any assertions > > > > /<>/tests/myCalendarTest.php:27 > > > > 2) vComponentTest::testRenderNoChanges2 > > This test did not perform any assertions > > > > /<>/tests/myComponentTest.php:420 > > > > ERRORS! > > Tests: 41, Assertions: 104, Errors: 1, Risky: 2. > > make[1]: *** [Makefile:52: test] Error 2 tests/myCalendarTest.php:61 was fixed by https://gitlab.com/davical-project/awl/-/commit/45f2ee44f2458a8c4e514fdf5a7b3bc329c44b9a
Bug#1005155: xpdf leaks a lot of memory
On Mon, Feb 07, 2022 at 11:50:44PM -0500, Chris Frey wrote:
> > If that helps, and you cannot upgrade to bullseye just now, I could
> > probably upload a buster-backport version of the bullseye xpdf, if
> > you're interested?
>
> That would be fantastic!
I've uploaded xpdf from bullseye to buster-backports. It is currently in
NEW awaiting approval, which usually takes no more than a week. If you
don't want to wait that long, I've also uploaded the .deb to
https://people.debian.org/~fsfs/xpdf/ for manual download an
installation ("sudo dpkg -i xpdf...deb", followed by "sudo apt-get
install -f" if there are dependencies not yet installed on your system)
HTH,
Florian
Bug#1005155: xpdf leaks a lot of memory
Hi Chris, On Mon, Feb 07, 2022 at 10:09:09PM -0500, Chris Frey wrote: > Package: xpdf > Version: 3.04-13 > > Running buster, just about any PDF I view with xpdf causes memory leaks. buster is oldstable by now. If you look at https://tracker.debian.org/media/packages/x/xpdf/changelog-3.04git20211021-1, you'll see that there are several references to fixed bugs about memory leaks in newer versions of xpdf in Debian (#945188, #942086, #945188). Does any of those sound similar to your problem? > So I compiled the Debian source package leaving debug symbols in, and > ran it inside valgrind, getting the report pasted below. When you say "the Debian source package", you probably refer to the buster version (3.04-13)? Would you care to try that again with the bullseye version (3.04+git20210103-3) that should have all the above mentioned memory fixes? If that helps, and you cannot upgrade to bullseye just now, I could probably upload a buster-backport version of the bullseye xpdf, if you're interested? Florian
Bug#1000187: [Pkg-auth-maintainers] Bug#1000187: Bug#1000187: yubikey-manager: Exception when trying to add an oath account
Hi Tobias, On Sun, Nov 28, 2021 at 12:56:36PM +, Tobias Bengfort wrote: > On 28/11/2021 07.56, Florian Schlichting wrote: > > Can you try again with yubikey-manager 4.0.7-1 (currently in unstable > > and testing)? > > I can verify that this issue does not existing in testing. Is it possible to > packport a fix to stable? thanks for confirming. I can probably upload version 4.0.7 to bullseye-backports, would that be useful for you? Updating the version in stable requires a targeted fix, and from a quick glance I fail to see where things go wrong in 4.0.0~a1-4 and what exactly has been fixed. (Are you sure this isn't just a fixed error message, or are you using something else as the value for SECRET?) Florian
Bug#1000187: [Pkg-auth-maintainers] Bug#1000187: yubikey-manager: Exception when trying to add an oath account
Hi Tobias, On Fri, Nov 19, 2021 at 11:51:46AM +, Tobias Bengfort wrote: > Package: yubikey-manager > Version: 4.0.0~a1-4 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > >$ ykman oath accounts add foo bar > > always results in > >AttributeError: 'OATH_TYPE' object has no attribute 'upper' Can you try again with yubikey-manager 4.0.7-1 (currently in unstable and testing)? I'm unable to reproduce your issue there, and seem to be able to successfully add an account, once I figured out a valid format for the secret: $ echo '123456' | base64 MTIzNDU2Cg== $ ykman oath accounts add foo 'MTIzNDU2Cg==' $ echo $? 0 $ ykman oath accounts list foo Florian
Bug#887834: [Pkg-mpd-maintainers] Bug#887834: mpd installation fails, cannot open /var/lib/mpd/tag_cache, /run/mpd/pid
On Thu, Nov 11, 2021 at 12:49:32AM +0100, Diederik de Haas wrote: > I'm responding to this bug as commenting out the pid_file line was the > solution > for me too, but my 'symptoms' are (a bit) different. ... > nov 10 23:30:21 soundserver systemd[1]: Failed to start Music Player Daemon. > > I found https://github.com/MusicPlayerDaemon/MPD/issues/1299 which seem to > indicate that the first exception is expected. > I did a "mpc rescan" both as user (me) and as root, but got > "MPD error: Connection refused", which indicates a premission issue. So I > checked the /run/ directory and saw that there wasn't a 'mpd' subdir. no, the connection is refused because the port is not open because MPD isn't running as it failed to start. That's also the reason why there is no /run/mpd directory, in 0.23.3 this gets removed by systemd when it gives up on starting MPD. > I'm _assuming_ that it's the same issue, but as my symptoms are somewhat > different, I thought I'd mention mine. > If this is actually a different issue which should be filed separately, let me > know and I'll do that. If you want me to run (some) tests, I can do that too. 0.23.4. which I'm uploading to unstable just now should properly fix this issue (even without the need to comment out pid_file). Florian
Bug#887834: [Pkg-mpd-maintainers] Bug#887834: Bug#887834: Bug#887834: mpd installation fails, cannot open /var/lib/mpd/tag_cache, /run/mpd/pid
Hi Max,
On Fri, Nov 05, 2021 at 09:05:50AM +0100, Max Kellermann wrote:
> On 2021/11/05 08:09, Max Kellermann wrote:
> > I gave this a second thought, and I fear that changes like this one
> > break even more setups, which should be avoided in a stable branch.
> >
> > I'll rather revert the "RuntimeDirectory" addition for now in the
> > 0.23.x stable branch.
>
> And this is the result of my third thought:
>
>
> https://github.com/MusicPlayerDaemon/MPD/commit/a4e42172045f62583cbf97a6a94c3d2b9de77a6c
>
> This keeps RuntimeDirectory, but "fixes" the pid_file problem (by
> ignoring the useless pid_file setting).
ok, and I see that a socket, should it be configured and the mpd.socket
unit not used, is still created as root, so no problem there either. Are
you going to release 0.23.4 soonish, or should we upload a git snapshot
in the meantime?
Regarding changes in a stable branch, from a Debian perspective now is a
good time to implement and test far-reaching changes, while in a year or
so from now the next freeze deadline might already be looming and with
it a certain need to be conservative or get it right the first time...
BTW I notice that on my laptop, without any audio_output explicitly
configured, mpd detects a sndio audio device, but then fails to play to
it ("exception: Failed to open "default detected output" (sndio);
Requested audio params cannot be satisfied"). Why is that, given that
sndiod is not installed? Does libsndio7.0 perhaps mis-detect some
pluseaudio compatibility devices, do we need to configure a default
output (alsa?) in /etc/mpd.conf so that things work out of the box?
Florian
Bug#998310: [Pkg-mpd-maintainers] Bug#998310: mpd: fails to start with "Assertion `sockets.empty()' failed."
Hi kaliko, On Fri, Nov 05, 2021 at 11:52:14AM +0100, kaliko wrote: > Then I believe setting NDEBUG (either at meson level with "b_ndebug=true" or > within "DEB_CXXFLAGS_MAINT_APPEND") will lead to the same result as meson > options "--buildtype=debugoptimized -Db_ndebug=true" since dpkg-buildflags > already set "-g -O2". > > What do you think of this Florian? I think that sounds sensible. We want to generate debug info for dbgsym/gdb, and as Max says he intends the assertions for hunting down bugs and doesn't expect normal users to run builds that include them, disabling them is the correct thing to do. Following your links I found Ian's explanation at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711515#30, which probably explains the thinking behind Debian's defaults, and why this is a situation where we should deviate from them. Will you make the change? Florian
Bug#887834: [Pkg-mpd-maintainers] Bug#887834: Bug#887834: mpd installation fails, cannot open /var/lib/mpd/tag_cache, /run/mpd/pid
Hi Ryan (and Max please see below):
> and have the following minimal mpd.conf:
>
> --
> music_directory "/var/lib/mpd/music"
> db_file "/var/lib/mpd/tag_cache"
> pid_file "/run/mpd/pid"
> state_file"/var/lib/mpd/state"
> log_level "verbose"
>
> user "mpd"
> bind_to_address "127.0.0.1"
>
> audio_output {
> type "null"
> name "null"
> }
> --
please, for now, delete or comment out the pid_file line
> Attempting to start mpd results in:
>
> --
> rak@zeta:~$ sudo service mpd start
> Job for mpd.service failed because a fatal signal was delivered to the
> control process.
> See "systemctl status mpd.service" and "journalctl -xeu mpd.service" for
> details.
> rak@zeta:~$ sudo systemctl status mpd.service
> × mpd.service - Music Player Daemon
> Loaded: loaded (/usr/lib/systemd/system/mpd.service; enabled; vendor
> preset: enabled)
> Active: failed (Result: signal) since Thu 2021-11-04 13:49:36 EDT; 2s ago
> TriggeredBy: × mpd.socket
>Docs: man:mpd(1)
> man:mpd.conf(5)
> file:///usr/share/doc/mpd/html/user.html
> Process: 474546 ExecStart=/usr/bin/mpd --no-daemon $MPDCONF (code=killed,
> signal=ABRT)
>Main PID: 474546 (code=killed, signal=ABRT)
> CPU: 175ms
>
> Nov 04 13:49:36 zeta mpd[474546]: sndfile: libsndfile-1.0.31
> Nov 04 13:49:36 zeta mpd[474546]: hybrid_dsd: The Hybrid DSD decoder is
> disabled because it was not explicitly enabled
> Nov 04 13:49:36 zeta mpd[474546]: adplug: adplug 2.3.3
> Nov 04 13:49:36 zeta mpd[474546]: exception: Failed to open
> '/var/lib/mpd/tag_cache': No such file or directory
> Nov 04 13:49:36 zeta mpd[474546]: curl: version 7.74.0
> Nov 04 13:49:36 zeta mpd[474546]: curl: with GnuTLS/3.7.2
> Nov 04 13:49:36 zeta mpd[474546]: mpd: ../src/event/Loop.cxx:60:
> EventLoop::~EventLoop(): Assertion `sockets.empty()' failed.
> Nov 04 13:49:36 zeta systemd[1]: mpd.service: Main process exited,
> code=killed, status=6/ABRT
> Nov 04 13:49:36 zeta systemd[1]: mpd.service: Failed with result 'signal'.
> Nov 04 13:49:36 zeta systemd[1]: Failed to start Music Player Daemon.
The tag_cache exception is non-fatal. The problem here is the Assertion
failure, which is #998310 and fixed in mpd 0.23.3-2
However, Max: behind this hides another problem, which is why I asked
Ryan to delete the pid_file configuration: as part of 0.23.3 you added
the "RuntimeDirectory=mpd" directive to both mpd.service units. In the
absence of User and Group directives, this causes /run/mpd to change
ownership from mpd:audio (as created by our
/usr/lib/tmpfiles.d/mpd.conf) to root:root, which means that mpd would
have to be run as root in order to be able to create a socket or a
pidfile (yes, legacy) there. I think that's broken from an upstream
perspective as well, and only works when running mpd as user.
I suppose the best way forward is to specify User=mpd and Group=audio
in the system unit, however this immediately hits a snag when mpd tries
to open its log file /var/log/mpd/mpd.log, which up to now is created as
root. This we could probably work around in Debian, and defaulting to
log to syslog/journal also feels sensible, but I'm not sure if there may
be other things that mpd might want to be root for when starting up as a
system service?
Florian
Bug#996903: xpdf 3.04+git20211001-1 crashes
On Thu, Oct 21, 2021 at 04:25:28PM +0300, Eugene Berdnikov wrote: > Hi Florian. > > On Thu, Oct 21, 2021 at 03:11:41PM +0200, Florian Schlichting wrote: > > I've just uploaded xpdf 3.04+git20211021-1 which should fix #996832 - > > once it hits the mirrors in a few hours, can you check if that improves > > your issue as well? > > Can you give a direct url of package for download? there's a mirror sync like 4 times a day, so it can take a while. By now, the new package can be seen here: https://packages.debian.org/sid/xpdf from which you can follow links to (for example) - http://ftp.ru.debian.org/debian/pool/main/x/xpdf/xpdf_3.04+git20211021-1_amd64.deb - http://ftp.debian.org/debian/pool/main/x/xpdf/xpdf_3.04+git20211021-1_i386.deb or whatever suits you
Bug#996903: xpdf 3.04+git20211001-1 crashes
Hi Eugene, On Thu, Oct 21, 2021 at 12:28:56AM +0100, Adam Sampson wrote: > On Thu, Oct 21, 2021 at 12:23:16AM +0100, Adam Sampson wrote: > > [xpdf crashes in Motif on] asc = _XmRendXftFont(rend)->ascent; > > Hmm -- the crash in #996832 is happening in the same place... I've just uploaded xpdf 3.04+git20211021-1 which should fix #996832 - once it hits the mirrors in a few hours, can you check if that improves your issue as well? Florian
Bug#996832: xpdf: segmentation fault in case of incorrect Xpdf*font X resource
Hi Vincent, On Thu, Oct 21, 2021 at 01:17:32AM +0100, Adam Sampson wrote: > On Tue, Oct 19, 2021 at 02:49:40PM +0200, Vincent Lefevre wrote: > > Xpdf*font: foo > [...] > > $ xpdf > > Warning: Cannot convert string "foo" to type FontStruct > > Segmentation fault (core dumped) > > I've been able to reproduce the crash -- it's occurring in Motif when > xpdf tries to create the text widgets in the About window, with the same > traceback as in #996903. > > This seems to be because I used XmStringGenerate with a rendition tag to > style the text. It looks like Motif still thinks that an Xft font is > being used to render it (which is incorrect), and ends up dereferencing > NULL because the font hasn't been loaded. I guess this is a Motif bug... > > I've worked around this (in xpopple Git) by styling the widgets using > resources rather than rendition tags. Specifying Xpdf*font now correctly > overrides all the default fonts again. I've just uploaded xpdf 3.04+git20211021-1 including this fix (thanks Adam!). Can you confirm that it fixes this issue? Florian
Bug#996903: xpdf 3.04+git20211001-1 crashes
On Thu, Oct 21, 2021 at 09:42:27AM +0300, Eugene Berdnikov wrote: > On Thu, Oct 21, 2021 at 12:28:56AM +0100, Adam Sampson wrote: > > On Thu, Oct 21, 2021 at 12:23:16AM +0100, Adam Sampson wrote: > > > [xpdf crashes in Motif on] asc = _XmRendXftFont(rend)->ascent; > > > > Hmm -- the crash in #996832 is happening in the same place... > > > > Do you have an Xpdf*font: resource (or something similar) set on your > > display? > > % xrdb -query | fgrep -i xpdf > Xpdf*fileFilterStyle: filter_hidden_files > > It is definitely loaded from /etc/X11/Xresources/xpdf > (part of Debian xpdf package). yes, and I get the same Xresources back, only I don't see any crashes... Do you install recommended packages (in general, and for xpdf in particular)? Can you create an strace? Florian
Bug#974423: packaging yubikey-manager-qt within the Authentication tools packaging team
Control: retitle 974423 'ITP: yubikey-manager-qt -- GUI for YubiKey Manager' Control: owner 974423 ! Hello Authentication tools packaging team, I found yubikey-manager-qt to be an easy-to-use alternative to yubikey-manager and would like to (team-)maintain it in Debian. Could you add me to the salsa group so I can upload the repo (I've just clicked on "Request Access") and are there any particulars I should be aware of? Florian
Bug#994520: yubikey-manager: please Depend or Recommend libyubikey-udev
Package: yubikey-manager
Version: 4.0.0~a1-4
Severity: normal
Hi,
please consider adding libyubikey-udev to yubikey-manager's Depends (or
at least Recommends).
Trying to access the 'ykman otp' functions as unprivileged user fails in
non-obvious ways ("No YubiKey found with the given interface(s)") when
it should "just work". yubikey-personalization already depends on
libyubikey-udev, while libykpers-1-1 recommends it.
Florian
Bug#994519: libyubikey-udev: please run udevadm trigger to activate udev rule
Package: libyubikey-udev Version: 1.20.0-3 Severity: normal Hi, The libyubikey-udev basically ships a udev rule. It would be nice if it ran the equivalent of 'sudo udevadm trigger' from its postinst in order for the rule to become active. BTW the salsa repo lacks the debian/1.20.0-3 tag. Florian
Bug#994438: kubernetes-client: Please provide zsh completion for kubectl
Package: kubernetes-client Version: 1.20.5+really1.20.2-1 Severity: wishlist It would be nice to have zsh completion for kubectl readily available once kubernetes-client is installed, as is the case for bash completion. Thanks for working on kubernetes in Debian!
Bug#993714: conffile which got removed during upgrade reported missing
Hi Evangelos, Axel, Perl team:
On Sun, Sep 05, 2021 at 01:19:44PM +0200, Evangelos Ribeiro Tzaras wrote:
> Is this behaviour expected? Could it be that the new `remove-on-upgrade`
> feature added to dpkg in 1.20.9 is not (yet) understood by debsums?
this.
I've built gnome-calls 41~rc-1 from your salsa repo. The source's
| $ cat debian/gnome-calls.maintscript
| rm_conffile /etc/xdg/autostart/sm.puri.Calls.desktop 0.2.0-1~
| rm_conffile /etc/xdg/autostart/sm.puri.Calls-daemon.desktop 41~alpha-1~
in the binary package now becomes
| $ cat DEBIAN/conffiles
| remove-on-upgrade /etc/xdg/autostart/sm.puri.Calls.desktop
| remove-on-upgrade /etc/xdg/autostart/sm.puri.Calls-daemon.desktop
| /etc/xdg/autostart/org.gnome.Calls-daemon.desktop
So when upgrading gnome-calls from 0.2.0-2 to 41~rc-1, the dpkg database
now reports the following conffiles:
| dpkg-query --showformat='${Conffiles}' --show gnome-calls
| /etc/xdg/autostart/sm.puri.Calls.desktop newconffile remove-on-upgrade
| /etc/xdg/autostart/sm.puri.Calls-daemon.desktop
1789a2d13445edfdced51660c298d7c0 remove-on-upgrade
| /etc/xdg/autostart/org.gnome.Calls-daemon.desktop
f78af49e6b5f5cdd5e123aa95f5da75c
This output is parsed by debsums, which assumes that
sm.puri.Calls-daemon.desktop must exist because it has a hash value,
whereas in reality it has already been removed from the system during
the upgrade.
I think this is similar to conffiles marked "obsolete" (cf. #689508),
and I've just pushed a one-line patch to ignore all lines containing the
remove-on-upgrade flag. However I'd prefer if somebody else has a look
to confirm this solution, as I'm rather unfamiliar with debsums and the
dpkg database, and failed to understand why dpkg would keep hashes for
deleted files. (Axel, you must have looked into this when developing the
"obsolete" fix?)
Florian
Bug#993606: RFP: libnet-sftp-perl -- pure-Perl implementation of the Secure File Transfer Protocol (SFTP)
> Net::SFTP is a pure-Perl implementation of the Secure File Transfer > Protocol (SFTP) - file transfer built on top of the SSH2 protocol. > Net::SFTP uses Net::SSH::Perl to build a secure, encrypted tunnel > through which files can be transferred and managed. It provides a subset > of the commands listed in the SSH File Transfer Protocol IETF draft, > which can be found at > http://www.openssh.com/txt/draft-ietf-secsh-filexfer-00.txt. with regard to Jonas' question, the POD says unter "COMMAND METHODS": Net::SFTP supports all of the commands listed in the SFTP version 3 protocol specification. Each command is available for execution as a separate method, with a few exceptions: SSH_FXP_INIT, SSH_FXP_VERSION, and SSH_FXP_READDIR. Jonathan, have you looked at Net::SFTP::Foreign, which is already packaged in Debian, and can you comment why that's not an option for you? It has a compatibility module for Net::SFTP and it leaves all the cryptographic and more generally security related tasks to the system's ssh command. There's a discussion of Net::SFTP::Foreign Vs. Net::SFTP Vs. Net::SSH2::SFTP in the POD. Florian
Bug#993667: ITP: libfile-treecreate-perl -- Perl module to recursively create and populate a directory tree
Package: wnpp Owner: Florian Schlichting Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name: libfile-treecreate-perl Version : 0.0.1 Upstream Author : Shlomi Fish * URL : https://metacpan.org/release/File-TreeCreate * License : Expat Programming Lang: Perl Description : Perl module to recursively create and populate a directory tree File::TreeCreate is a Perl module to quickly and easily create a directory tree and populate it with simple text files. It was extracted from several near-identical copies used in the tests of some of the author's CPAN distributions. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Bug#992417: RM: libpod-weaver-section-generatesection-perl -- ROM; superseded by libpod-weaver-perl 4.018-1
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: pkg-perl-maintain...@lists.alioth.debian.org Dear ftpmasters, from version 4.018 of Pod::Weaver, the previously independent Pod::Weaver::Section::GenerateSection plugin was integrated into the main distribution and subsequently removed from CPAN. Please remove libpod-weaver-section-generatesection-perl from testing and unstable, as all functionality and code has been moved into libpod-weaver-perl 4.018-1 (currently in unstable and not allowed to migrate to testing due to autopkgtest regression because of conflicting unconditionally with libpod-weaver-section-generatesection-perl). Thanks, Florian
Bug#444731: still an issue
Just leaving a note this is still a missing (and obscure) feature ten years later, in both xpdf (3.04+git20210103-3) and evince.
Bug#505932: xpdf: Check boxes to not get ticked
Hi Samuel, > wget www.irs.gov/pub/irs-pdf/fw9.pdf > evince fw9.pdf > > then tick some boxes, fill some fields, save. Reopen with evince, both > fields and check boxes are filled as appropriate. Reopen with xpdf, > fields get filled, but check boxes do not get ticked. I think this has worked for some time, and in my testing today I see both fields filled in and boxes checked, just like they were in evince. Do you agree this bug can be closed? Florian
Bug#927908: Bug #927908: xpdf: Italic text is shown as a regular one
Hi Bjarni, > This can be fixed by adding the following to the ~/.xpdrc file > > fontFile Times-Italic /usr/share/fonts/type1/gsfonts/n021023l.pfb > fontFile Times-Roman /usr/share/fonts/type1/gsfonts/n021003l.pfb display font substitution is done by poppler by default, and these should be exactly the defaults that poppler is using. Can you re-check if this is still an issue with the version of xpdf currently in testing, and if yes if you have any interfering fontFile commands, for example in (an old version of) /etc/xpdf/xpdfrc or any other file included from there or ~/.xpdfrc? And if this doesn't lead to a solution, can you provide an example PDF file where you experience this issue, so we can try and reproduce it? Florian
Bug#655290: xpdf --no-sidebsr
On Thu, Mar 04, 2021 at 06:11:16PM +, Adam Sampson wrote: > On Thu, Mar 04, 2021 at 05:18:08PM +0100, Florian Schlichting wrote: > > there is no command line option for this, but you can configure a > > keybinding for the toggleOutline command (or separate keys for > > openOutline / closeOutline if you wish), which should do about the same. > > Maybe there should be a command-line option to execute an arbitrary > config file command on startup? (Like -remote, but not remote...) You mean those listed under COMMANDS in the xpdf manpage, that can be bound to keys? I think that would be a useful thing to have, and there's already -exec - does that need to be limited to remote server windows, or can that be made to apply to a newly started xpdf as well, once startup is complete and the file is loaded? Florian
Bug#683399: xpdf: "Cannot convert string to type FontStruct" warnings
On Thu, Mar 04, 2021 at 06:07:08PM +, Adam Sampson wrote: > On Thu, Mar 04, 2021 at 05:59:45PM +0100, Florian Schlichting wrote: > > > xpdf /usr/share/texmf/doc/pgf/pgfmanual.pdf.gz > > > Warning: Cannot convert string > > > "-*-helvetica-medium-r-normal--12-*-*-*-*-*-iso8859-1" to type FontStruct > > > Warning: Cannot convert string > > > "-*-courier-medium-r-normal--12-*-*-*-*-*-iso8859-1" to type FontStruct > > > Warning: Cannot convert string > > > "-*-times-bold-i-normal--20-*-*-*-*-*-iso8859-1" to type FontStruct > > > Warning: Cannot convert string > > > "-*-times-medium-r-normal--16-*-*-*-*-*-iso8859-1" to type FontStruct > > If so, can you try to find out where these strings come from (they look > > like Xresources meant for xterm, or some such)? > > Those are the default fonts that xpdf specifies for its user interface > -- they're hardcoded in the source code. oh. Where did I have my eyes? I did some searching in poppler, but they were hiding in plain sight! > Looking at how nedit handles this, maybe xpdf should have: > Recommends: xfonts-100dpi | xfonts-75dpi > ? That's easy enough to add. However I almost can't believe somebody running xpdf does not have those installed, given that they're a dependency of the xorg package... Florian
Bug#972527: Support arbitrary arguments in /etc/default/dnss
Control: severity 972527 important
Dear dnss maintainers,
> /lib/systemd/system/dnss.service uses curly braces with
> ${MONITORING_FLAG} and ${MODE_FLAGS}, which means each one can only
> have a single argument in it.
please please fix this? It just needs dnss.service to not use curly braces:
EnvironmentFile=-/etc/default/dnss
ExecStart=/usr/bin/dnss \
--dns_listen_addr=systemd \
$MONITORING_FLAG \
$MODE_FLAGS
This makes it possible to set more than one flag in MODE_FLAGS in
/etc/default/dnss, for example (and mentioned in README.md):
MODE_FLAGS='-enable_dns_to_https
-https_upstream="https://1.1.1.1/dns-query;'
This fix would be particularly helpful because the error mesage will be
confusing unless one already knows about this problem:
systemd[1]: dnss.service: Main process exited, code=exited,
status=2/INVALIDARGUMENT
flag provided but not defined: -enable_dns_to_https -https_upstream
(see also merge request !1 on salsa)
thanks,
Florian
Bug#879979: xpdf: debian's xpdf messes up fonts and kerning to the point text becomes very hard to read
Hi Attila, > Debian's version of xpdf does something weird with fonts in quite a few > documents. It seems to grab the wrong font and then applies the wrong > kerning, making the text very hard to read. The same file rendered with > xpdf compiled from upstreams source works fine and renders the text correctly. > Attached are to pngs that show the difference in rendering. this does indeed look weird. But does it still occur for you with recent versions of xpdf in Debian (preferably 3.04+git20210103-1 or newer)? And if so, can you provide a PDF where others can try to reproduce the issue, and the contents of you .xpdfrc, plese? Florian
Bug#781251: xpdf: prints letter PDF files in A3 instead of A4
Hi, > > When I use xpdf to print a PDF file of "letter" page size such as the > > test file attached (using the "lpr" command, which is the default), > > the file is printed in A3 instead of A4. If I use "lpr file.pdf" > > directly, I get A4 output as expected. > > The cause is that xpdf uses pdftops before sending the output to lpr. > Indeed, as I've said on > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781253#72 > > I have exactly the same problem when I run pdftops manually then lpr > on the generated .ps file. So, this is not really a bug in xpdf, > except one may wonder whether it should use pdftops. pdftops is a frontend to the poppler library, which is also used by xpdf to generate the PostScript that is then sent to lpr (or written to a file). But since you said (in 2015) that this not a bug in xpdf, and the above-mentioned bug has fixed versions (though has not been closed, perhaps by mistake?), do you think this should be reassigned to pdftops / poppler, or has it become obsolete and solved in ghostscript? Florian
Bug#683399: xpdf: "Cannot convert string to type FontStruct" warnings
Hi, > xpdf /usr/share/texmf/doc/pgf/pgfmanual.pdf.gz > Warning: Cannot convert string > "-*-helvetica-medium-r-normal--12-*-*-*-*-*-iso8859-1" to type FontStruct > Warning: Cannot convert string > "-*-courier-medium-r-normal--12-*-*-*-*-*-iso8859-1" to type FontStruct > Warning: Cannot convert string > "-*-times-bold-i-normal--20-*-*-*-*-*-iso8859-1" to type FontStruct > Warning: Cannot convert string > "-*-times-medium-r-normal--16-*-*-*-*-*-iso8859-1" to type FontStruct this is an old bug and it feels a little obscure. Could you confirm that this is still an issue for you with current (preferably 3.04+git20210103-1 or newer) versions of xpdf? If so, can you try to find out where these strings come from (they look like Xresources meant for xterm, or some such)? Florian
Bug#655290: xpdf --no-sidebsr
Hi Danni, > Though one can maneuver it with the mouse so it is indeed pushed off > the screen, it would still be nice to have an $ xpdf --no-sidebsr # or > --no-table-of-contents option one day, to zap it for certain documents > conveniently via the command line. (More flexible that way than via a > config file too.) there is no command line option for this, but you can configure a keybinding for the toggleOutline command (or separate keys for openOutline / closeOutline if you wish), which should do about the same. Florian
Bug#873952: xpdf: add support for some old config file commands
Hi Vincent, this bug was cloned from #848671, where people complain about error messages when starting xpdf. The messages were about configuration options for which support was removed in poppler, but which were still contained in the "language support" (configuration) files shipped with xpdf. With this bug you seem to request that support for these options should be added back. Do you have a specific need for any one of them, or was that just meant as a reminder since the error message seems to suggest that support would be possible if only someone put in the work? My current understanding is that poppler doesn't and is not going to support these any more, at least not as part of its public API. That said, all the mapping files referenced in xpdf's "language support" files are nowadays shipped in the poppler-data package, which claims in its README that poppler will read them automatically when available. So there's really no need to try and set any of this from xpdf, no? Florian
Bug#984494: unblock: xpdf/3.04+git20210103-2
Hi Paul,
> > As an unrelated issue, I just noticed after uploading -2 that the
> > -D_FORTIFY_SOURCE=2 hardening buildflag fails to be correctly injected.
> > This can apparently be fixed by a small change to debian/rules:
> >
> > export DEB_BUILD_MAINT_OPTIONS=hardening=+all
> >
> > -export CPPFLAGS+=-DHAVE_PAPER_H
> > +export DEB_CPPFLAGS_MAINT_APPEND = -DHAVE_PAPER_H
> >
> > Does the release team consider this a permissible change for the hard
> > freeze, and should I upload a -3 straight away so that one unblock will
> > suffice for both fixes?
>
> Please go ahead with that. Sounds like something we want for a PDF viewer.
yes, thank you!
xpdf 3.04+git20210103-3 is on its way to the archive, the complete
debdiff follows below.
Florian
diff -Nru xpdf-3.04+git20210103/debian/changelog
xpdf-3.04+git20210103/debian/changelog
--- xpdf-3.04+git20210103/debian/changelog 2021-01-28 15:58:32.0
+0800
+++ xpdf-3.04+git20210103/debian/changelog 2021-03-04 22:41:56.0
+0800
@@ -1,3 +1,15 @@
+xpdf (3.04+git20210103-3) unstable; urgency=medium
+
+ * Fix automatic injection of hardening buildflags
+
+ -- Florian Schlichting Thu, 04 Mar 2021 22:41:56 +0800
+
+xpdf (3.04+git20210103-2) unstable; urgency=medium
+
+ * Fix printing when no psLevel is defined in xpdfrc (closes: #983880)
+
+ -- Florian Schlichting Thu, 04 Mar 2021 14:20:04 +0800
+
xpdf (3.04+git20210103-1) unstable; urgency=medium
* Import new upstream version 3.04+git20210103
diff -Nru xpdf-3.04+git20210103/debian/patches/983880.patch
xpdf-3.04+git20210103/debian/patches/983880.patch
--- xpdf-3.04+git20210103/debian/patches/983880.patch 1970-01-01
08:00:00.0 +0800
+++ xpdf-3.04+git20210103/debian/patches/983880.patch 2021-03-04
14:17:41.0 +0800
@@ -0,0 +1,23 @@
+commit 1b27cc5bb4491aed9d65c9f98704a693e3aabe59
+Author: Adam Sampson
+Date: Wed Mar 3 14:14:52 2021 +
+
+Initialise XPDFParams::psLevel.
+
+This meant that PostScript output didn't work unless you specified
+psLevel explicitly in the config file.
+
+Reported by Frédéric Brière in Debian bug #983880.
+
+diff --git a/xpdf/XPDFParams.cc b/xpdf/XPDFParams.cc
+index 4929bed..f33dd1e 100644
+--- a/xpdf/XPDFParams.cc
b/xpdf/XPDFParams.cc
+@@ -159,6 +159,7 @@ XPDFParams::XPDFParams(const char *cfgFileName) {
+ psImageableURY = psPaperHeight;
+ psCrop = true;
+ psDuplex = false;
++ psLevel = psLevel2;
+ initialZoom = "125";
+ continuousView = false;
+ createDefaultKeyBindings();
diff -Nru xpdf-3.04+git20210103/debian/patches/series
xpdf-3.04+git20210103/debian/patches/series
--- xpdf-3.04+git20210103/debian/patches/series 2021-01-28 14:22:16.0
+0800
+++ xpdf-3.04+git20210103/debian/patches/series 2021-03-04 15:09:53.0
+0800
@@ -1 +1,2 @@
wrapper-options-manpage.patch
+983880.patch
diff -Nru xpdf-3.04+git20210103/debian/rules xpdf-3.04+git20210103/debian/rules
--- xpdf-3.04+git20210103/debian/rules 2021-01-28 14:12:37.0 +0800
+++ xpdf-3.04+git20210103/debian/rules 2021-03-04 15:10:10.0 +0800
@@ -2,7 +2,7 @@
export DEB_BUILD_MAINT_OPTIONS=hardening=+all
-export CPPFLAGS+=-DHAVE_PAPER_H
+export DEB_CPPFLAGS_MAINT_APPEND = -DHAVE_PAPER_H
export LIBS+=-lpaper
%:
Bug#984494: unblock: xpdf/3.04+git20210103-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package xpdf
-2 that I just uploaded contains a one-line patch correctly initializing the
psLevel variable. This fixes the PostScript generated for printing in
all cases where the user hasn't set a psLevel manually in the config
file. This was reported in #983880 and promptly fixed by Upstream.
I think printing PDFs is one of the most common things people do with
xpdf (apart from simply viewing them, of course), and since this is a
regression from the previous version, getting a fixed version into
bullseye is very important IMHO.
see source debdiff below.
unblock xpdf/3.04+git20210103-2
As an unrelated issue, I just noticed after uploading -2 that the
-D_FORTIFY_SOURCE=2 hardening buildflag fails to be correctly injected.
This can apparently be fixed by a small change to debian/rules:
export DEB_BUILD_MAINT_OPTIONS=hardening=+all
-export CPPFLAGS+=-DHAVE_PAPER_H
+export DEB_CPPFLAGS_MAINT_APPEND = -DHAVE_PAPER_H
Does the release team consider this a permissible change for the hard
freeze, and should I upload a -3 straight away so that one unblock will
suffice for both fixes?
thanks,
Florian
diff -Nru xpdf-3.04+git20210103/debian/changelog
xpdf-3.04+git20210103/debian/changelog
--- xpdf-3.04+git20210103/debian/changelog 2021-01-28 15:58:32.0
+0800
+++ xpdf-3.04+git20210103/debian/changelog 2021-03-04 14:20:04.0
+0800
@@ -1,3 +1,9 @@
+xpdf (3.04+git20210103-2) unstable; urgency=medium
+
+ * Fix printing when no psLevel is defined in xpdfrc (closes: #983880)
+
+ -- Florian Schlichting Thu, 04 Mar 2021 14:20:04 +0800
+
xpdf (3.04+git20210103-1) unstable; urgency=medium
* Import new upstream version 3.04+git20210103
diff -Nru xpdf-3.04+git20210103/debian/patches/983880.patch
xpdf-3.04+git20210103/debian/patches/983880.patch
--- xpdf-3.04+git20210103/debian/patches/983880.patch 1970-01-01
08:00:00.0 +0800
+++ xpdf-3.04+git20210103/debian/patches/983880.patch 2021-03-04
14:17:41.0 +0800
@@ -0,0 +1,23 @@
+commit 1b27cc5bb4491aed9d65c9f98704a693e3aabe59
+Author: Adam Sampson
+Date: Wed Mar 3 14:14:52 2021 +
+
+Initialise XPDFParams::psLevel.
+
+This meant that PostScript output didn't work unless you specified
+psLevel explicitly in the config file.
+
+Reported by Frédéric Brière in Debian bug #983880.
+
+diff --git a/xpdf/XPDFParams.cc b/xpdf/XPDFParams.cc
+index 4929bed..f33dd1e 100644
+--- a/xpdf/XPDFParams.cc
b/xpdf/XPDFParams.cc
+@@ -159,6 +159,7 @@ XPDFParams::XPDFParams(const char *cfgFileName) {
+ psImageableURY = psPaperHeight;
+ psCrop = true;
+ psDuplex = false;
++ psLevel = psLevel2;
+ initialZoom = "125";
+ continuousView = false;
+ createDefaultKeyBindings();
diff -Nru xpdf-3.04+git20210103/debian/patches/series
xpdf-3.04+git20210103/debian/patches/series
--- xpdf-3.04+git20210103/debian/patches/series 2021-01-28 14:22:16.0
+0800
+++ xpdf-3.04+git20210103/debian/patches/series 2021-03-04 14:17:21.0
+0800
@@ -1 +1,2 @@
wrapper-options-manpage.patch
+983880.patch
Bug#926501: xpdf: continuousView memory leak
Hi Kevin, Martin and Greg, On Wed, Mar 03, 2021 at 10:06:37PM +, Adam Sampson wrote: > On Sat, 06 Apr 2019 18:30:26 +1100 Kevin Ryde > wrote: > > With continuousView enabled [...] > > Viewing a medium to large document such as > > xpdf /usr/share/doc/bash-doc/bash.pdf > > and paging through it with space or page-down, results in the xpdf > > process using apparently ever growing memory, as shown by top or > > memstat. > > I've just tested this with the latest xpopple and it seems fine, so I > think it was caused by one (or more) of the leaks that were fixed in the > most recent (xpopple-based) Debian xpdf package. can you please test this issue with xpdf 3.04+git20210103-1 or newer and confirm that your memory problem has indeed been solved? thanks, Florian
Bug#983880: xpdf: Printing fails, apparently due to broken PostScript output
Hi Frédéric and Adam, On Tue, Mar 02, 2021 at 01:33:04PM -0500, Frédéric Brière wrote: > Package: xpdf > Version: 3.04+git20210103-1 > Severity: normal > > Attempting to print any (non-trivial) PDF document with xpdf > 3.04+git20210103-1 results in a "No pages found!" CUPS error. > Downgrading to 3.04-14 fixes the issue. > > This seems to be caused by a broken PostScript output; printing to a > file and opening it with gv results in the following error: > > Error: /undefined in xpdfGPL Ghostscript 9.53.3: Unrecoverable error, > exit code 1 > > Operand stack: > > Execution stack: >%interp_exit .runexec2 --nostringval-- --nostringval-- > --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- > --nostringval-- false 1 %stopped_push 1990 1 3 %oparray_pop > 1989 1 3 %oparray_pop 1977 1 3 %oparray_pop 1833 1 3 > %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- > --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- > Dictionary stack: >--dict:733/1123(ro)(G)-- --dict:0/20(G)-- --dict:75/200(L)-- > Current allocation mode is local > Last OS error: No such file or directory > > > As an example, I'm attaching pre- and post-bug PostScript versions of > the Debian Reference Card. I notice that this does not happen when xpdfrc defines a psLevel to use (any of the six levels mentioned in the manpage will do). The xpdfrc manpage claims the default psLevel is level2. Perhaps xpdf needs to set that explicitly? The postscript that causes this gs error claims to be LanguageLevel: 3, the file size is even smaller than what a psLevel of level3 or level3sep generates. Adam, do you know if this is xpdf failing to set a default, or poppler (20.09.0 in Debian testing/unstable) being buggy? Florian
Bug#881600: vpnc: error message 'to few arguments' while starting a vpnc connection
Control: tags -1 + unreproducible Hi Christian, On Mon, Nov 13, 2017 at 11:43:18AM +0100, Christian Weisel wrote: > Connection is working fine but while starting the connection using 'sudo vpnc > my_vpn' I got the following 2 lines on stderr: > Too few arguments. > Too few arguments. On Fri, Aug 03, 2018 at 09:04:42AM +0100, Philip Ashmore wrote: > Package: vpnc > Followup-For: Bug #881600 > > I saw the same error message while doing "ifup wlp2s0". > I used strace and strace-process-tree.py > (https://gist.github.com/mgedmin/4953427) to track it down. > It appears that resolvconf is calling systemctl and it's exiting with exit > code > 1 after printing "Too few arguments". those messages don't seem to appear any more (at least for me), and Philip's analysis suggests the problem was not in vpnc itself anyway. Do you agree that there's no need to keep this bug report open? Florian
Bug#785443: vpnc: VPN disconnects every hour
Control: tags -1 +moreinfo Hi Hans, > I am using a FritzBox modem as endpoint. > vpnc disconnects every hour. > > syslog: > May 16 09:07:09 rijs-svr kernel: [821056.494059] CIFS VFS: Server 192.168.1.1 > has not responded in 120 seconds. Reconnecting... > > May 16 09:07:53 rijs-svr vpnc[12282]: HMAC mismatch in ESP mode > > May 16 09:11:35 rijs-svr vpnc[12282]: HMAC mismatch in ESP mode > May 16 09:13:32 rijs-svr vpnc[12282]: connection terminated by dead peer > detection could you try again with vpnc 0.5.3+git20210125-1 (uploaded to unstable just yesterday). As it happens, we've long carried a patch against a dead peer detection issue, which had already been fixed upstream but in a different way. So in effect our patch reintroduced the problem! This should now be fixed. Florian
Bug#980799: buster-pu: package irssi-plugin-xmpp/0.54-3
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
As explained in #931886 / upstream at
https://github.com/cdidier/irssi-xmpp/issues/43, due to recent changes
in irssi, irssi-plugin-xmpp in buster is unable to establish STARTTLS
connections because the connect timeout triggers prematurely.
This update contains a one-line patch that allows the intended
connection timeout to take effect.
I have verified that this bug is present in the version of
irssi-plugin-xmpp in buster and fixed by this proposed update. A
corresponding fix has just been uploaded to unstable as part of
irssi-plugin-xmpp 0.54+git20191101+c13fa5-1.
As I think the change is rather trivial and low-risk, I take the liberty
to upload to buster-pu right away. Debdiff below.
Florian
diff -Nru irssi-plugin-xmpp-0.54/debian/changelog
irssi-plugin-xmpp-0.54/debian/changelog
--- irssi-plugin-xmpp-0.54/debian/changelog 2019-03-27 19:57:14.0
+0800
+++ irssi-plugin-xmpp-0.54/debian/changelog 2021-01-22 21:53:27.0
+0800
@@ -1,3 +1,11 @@
+irssi-plugin-xmpp (0.54-3+deb10u1) buster; urgency=medium
+
+ * Cherry-pick bug931886.patch from upstream to not trigger the irssi core
+connect timeout prematurely, thus fixing STARTTLS connections
+(closes: #931886)
+
+ -- Florian Schlichting Fri, 22 Jan 2021 21:53:27 +0800
+
irssi-plugin-xmpp (0.54-3) unstable; urgency=medium
* drop -dbg→-dbgsym transition (no longer needed)
diff -Nru irssi-plugin-xmpp-0.54/debian/patches/bug931886.patch
irssi-plugin-xmpp-0.54/debian/patches/bug931886.patch
--- irssi-plugin-xmpp-0.54/debian/patches/bug931886.patch 1970-01-01
08:00:00.0 +0800
+++ irssi-plugin-xmpp-0.54/debian/patches/bug931886.patch 2021-01-22
21:53:06.0 +0800
@@ -0,0 +1,16 @@
+commit 57c62278b97aeb999f3ca2e2b8a492f364405b61
+Author: Ailin Nemui
+Date: Tue Jan 29 21:37:05 2019 +0100
+
+do not trigger the irssi core connect timeout prematurely
+
+--- a/src/core/xmpp-servers.c
b/src/core/xmpp-servers.c
+@@ -528,6 +528,7 @@
+ }
+ lm_connection_set_disconnect_function(server->lmconn,
+ lm_close_cb, server, NULL);
++ server->connect_time = time(NULL);
+ lookup_servers = g_slist_append(lookup_servers, server);
+ signal_emit("server looking", 1, server);
+ server->timeout_tag = g_timeout_add(
diff -Nru irssi-plugin-xmpp-0.54/debian/patches/series
irssi-plugin-xmpp-0.54/debian/patches/series
--- irssi-plugin-xmpp-0.54/debian/patches/series2019-03-27
19:57:14.0 +0800
+++ irssi-plugin-xmpp-0.54/debian/patches/series2021-01-22
21:52:47.0 +0800
@@ -42,3 +42,4 @@
ailin-nemui-0008-Add-support-for-messages-coming-directly-from-room.patch
ailin-nemui-0009-Add-support-for-mode-change-in-MUC.patch
comparison-between-pointer-and-zero-character-constant.patch
+bug931886.patch
Bug#714499: segfault on connexion lost
On Sat, Jun 29, 2013 at 08:43:37PM -0400, Antoine Beaupré wrote:
> From what I can tell, it looks like loudmouth is throwing an exception
> and the plugin is not handling it so crashes.
>
> This is the code where this happens, I believe:
>
> static void
> server_cleanup(XMPP_SERVER_REC *server)
> {
> if (!IS_XMPP_SERVER(server))
> return;
> if (server->timeout_tag)
> g_source_remove(server->timeout_tag);
> if (lm_connection_get_state(server->lmconn) !=
> LM_CONNECTION_STATE_CLOSED)
> lm_connection_close(server->lmconn, NULL);
> lm_connection_unref(server->lmconn);
> g_free(server->jid);
> g_free(server->user);
> g_free(server->domain);
> g_free(server->resource);
> g_free(server->ping_id);
> }
>
> Some try/catch around this may resolve the issue, but keep in mind
> that this function is called from a signal emitted elsewhere
> (server_disconnect()) so maybe that's where it should be handled
> instead.
Something like this landed upstream as part of
https://github.com/cdidier/irssi-xmpp/commit/5cc5fea5970fe19e1a3a2a1b6cb4b7436cc813fd
If that's where the problem was, it should be fixed as of
irssi-plugin-xmpp 0.54+git20191101+c13fa5-1
Florian
Bug#977182: xpdf: Switch to xpopple as new upstream for Debian's xpdf?
Package: xpdf Version: 3.04-14 Severity: important X-Debbugs-Cc: Gianfranco Costamagna ,GOTO Masanori ,Sebastien Bacher ,Iain Lane Dear people interested in Debian's xpdf, looking at how things went with Debian's xpdf since Micheal orphaned the package in 2016, I'm doubtful how long this is still feasible. In fact, I thought it was already dead, when I found the xpopple repository, which already contained all that was necessary to adapt to current poppler (which still took several hours fighting or rather hand-patching). I think if we want to continue to have a motif and poppler based xpdf in Debian, we should switch to using xpopple as upstream. To this end I wrote the below email (but failed to properly involve the bts). This also relates to the question raised in #873951 whether we shouldn't follow xpdf 4.x's switch to QT and related development, but given that they're not using poppler, IMHO this is only going to be even more complicated that continuing as before. Florian - From: Florian Schlichting To: Adam Sampson Date: Fri, 11 Dec 2020 11:18:48 +0100 Subject: xpopple as new upstream for Debian's xpdf? Hi Adam, the other day, when I looked into the build failures that have kept Debian's xpdf package out of the upcoming release for several months, I happened upon your xpopple project (http://offog.org/code/xpopple/), which I hadn't been aware of before. It seems that since 2014, you've been doing right what we've struggled to do in Debian: deleting obsolete code, moving files for good instead of just for the build, applying patches instead of fighting with an unwieldy quilt queue, and most of all: following poppler development closely, updating xpdf accordingly while cleaning up some legacy code. This has been enormously helpful for my recent upload, thanks a ton! >From my position it looks like Debian should stop what it's been increasingly unable to accomplish properly, and instead switch over to xpopple as its upstream source for the xpdf package. Do you think xpopple is ready for that? Are there areas where xpopple does not provide any features that Debian's xpdf currently offers? (I notice you're based off xpdf 3.03, but am unable to judge which parts if any of the 3.04 changelog apply to the part that we're still using; the new text extractor seems to be patched out again?) And: Are you interested to act as upstream developer for what may be a substantial user base, which can come up with all kinds of problems and suggestions not related to your personal use case? (Cc the Debian bug tracker so that other people interested in xpdf can know what's going on; I might be able to help with packaging and bug triaging, but I've never found the time to familiarize myself with poppler enough to know what's going on) Looking forward to hear from you! Florian
Bug#975395: anki: Fails with Python3.9 due to use of deprecated unescape() method
Control: severity -1 serious
Hi,
"more complex HTML templates" in my case means that I actually enter an
answer and then get a comparison for correctness (the "{{type:answer}}"
tag). Anki won't update to show the comparison, rate correctness and go
on with the next card, but display the following trace:
Caught exception:
File "/usr/share/anki/aqt/webview.py", line 340, in handler
cb(val)
File "/usr/share/anki/aqt/reviewer.py", line 461, in _onTypedAnswer
self._showAnswer()
File "/usr/share/anki/aqt/reviewer.py", line 217, in _showAnswer
a = self._mungeQA(a)
File "/usr/share/anki/aqt/reviewer.py", line 156, in _mungeQA
return self.typeAnsFilter(mungeQA(self.mw.col, buf))
File "/usr/share/anki/aqt/reviewer.py", line 306, in typeAnsFilter
return self.typeAnsAnswerFilter(buf)
File "/usr/share/anki/aqt/reviewer.py", line 362, in typeAnsAnswerFilter
cor = parser.unescape(cor)
: 'HTMLParser' object has no attribute 'unescape'
This makes Anki pretty much unusable. However, I can confirm that the
patch works and seems to be all that's needed to fix this issue.
If a new upstream version seems unfeasible, can we at least have a -3
with this patch applied in time for the freeze?
Florian
Bug#967140: [Pkg-mpd-maintainers] Bug#967140: gmpc-plugins: Unversioned Python removal in sid/bullseye
Control: severity -1 normal On Tue, Aug 18, 2020 at 12:08:14PM +0100, Simon McVittie wrote: > On Tue, 04 Aug 2020 at 09:28:01 +, Matthias Klose wrote: > > We will keep some Python2 package as discussed in > > https://lists.debian.org/debian-python/2020/07/msg00039.html > > but removing the unversioned python packages python-minimal, python, > > python-dev, python-dbg, python-doc. > > > > Your package either build-depends, depends on one of those packages. > > `git grep -i python` and `apt-cache show gmpc-plugins | grep -i python` > don't find any relationship between gmpc-plugins and Python 2. Is this a > false positive, or is there some dependency that I'm missing? I suspect this got mixed up with the GTK 2 deprecation? Lowering severity so that gmpc-plugins can re-enter testing. Florian
Bug#975043: RFP: eduvpn-client -- VPN client for educational networks
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-pyt...@lists.debian.org * Package name: eduvpn-client Version : 1.1-1 Upstream Author : Gijs Molenaar * URL : https://github.com/eduvpn/python-eduvpn-client * License : GPL-3+ Programming Lang: Python3 Description : VPN client for educational networks eduVPN enables students, employees and researchers to connect securely and encrypted to the Internet from any standard device. eduVPN integrates with the institutional network so that internal ICT services can be made available in a secure manner. eduVPN specifically allows one to choose a VPN server in a different country, in order to secure network access from public networks while travelling, without the need to route traffic around the globe to one's home institution. eduvpn-client is a GUI application and API client that taps into your home institution's AAI, retrieves a list of available countries / eduVPN servers and their profiles, and adds an openvpn-based connection to NetworkManager that includes all the necessary certificates and tokens. The eduVPN homepage is at https://www.eduvpn.org/ and there's an upstream packaging repo at https://github.com/eduvpn-debian/python-eduvpn-client While suitable openvpn configuration files for one's own institution / NREN can be downloaded through the web, the "international server" feature is only available through use of the API ie this client.
Bug#958179: create user-friendly startup configuration
Hi Eduard and Francois,
I agree that README.Debian is a mess. What keeps me from fixing it is
that I'm unsure how people are using (or intend to use) mpd.
Historically, the package has shipped a lot of infrastructure for
running as a system service, and I think having mpd run on a headless
box somewhere on the home network and being able to control one's music
remotely is one of its big appeals.
However I feel most users would probably be served better by deleting all
of that infrastructure and configuring mpd to run from their user
session, just like their pulseaudio, which in my understanding is the
proper way to solve the permissions problem that Eduard mentions.
This assumes that "most users" start on a default Gnome desktop with
pulseaudio, but then some people prefer to use JACK oder ALSA with dmix
or want to run several instances of mpd or don't use systemd or do use
systemd but haven't heard of socket activation etc, and there's your
mess.
Can we do sensible things for all of these use cases, or should we try
to do less but have that work out of the box? And what's the default use
case to be?
Confused,
Florian
On Sun, Apr 19, 2020 at 02:12:53PM +0200, Eduard Bloch wrote:
> Package: mpd
> Version: 0.21.20-1
> Severity: wishlist
>
> Hi,
>
> I have used mpd like 10 years ago and it was quite okay back then. I
> wanted to revive it, and I failed.
> It seems that:
>
> a) is no longer capable of auto-detecting an ALSA device. I get errors
> like "Failed to open ALSA device (default)"
>
> b) when I change the config to use pulse audio, it fails. The reported
> error is not helpful, mentioning some permission problem. Maybe
> README.Debian should explain in detail what this is about?
>
> In the end it looks like it runs as a separate user without permissions.
> And README.Debian talks around that fact but not saying clearly what's
> up. Then it suggests to clone the config to $HOME in varios ways and
> investigate how to start it.
>
> I am sorry, but for me those instructions look just messy. There should
> be some kind of script for initial setup which the user just runs and it
> asks "do you want to use it in your Desktop session?" and if not then it
> should clearly communicate how to modify permissions to make the audio
> output accessible.
>
> Best regards,
> Eduard.
>
> }
>
> /etc/mpd.conf changed:
> music_directory "/data/wdblue_partition5/audio"
> playlist_directory"/var/lib/mpd/playlists"
> db_file "/var/lib/mpd/tag_cache"
> log_file "/var/log/mpd/mpd.log"
> pid_file "/run/mpd/pid"
> state_file"/var/lib/mpd/state"
> sticker_file "/var/lib/mpd/sticker.sql"
> user "mpd"
> bind_to_address "localhost"
> input {
> plugin "curl"
> }
> input {
> enabled"no"
> plugin "qobuz"
> }
> input {
> enabled "no"
> plugin "tidal"
> }
> decoder {
> plugin "hybrid_dsd"
> enabled "no"
> }
> audio_output {
> type"alsa"
> name"My ALSA Device"
> }
> filesystem_charset"UTF-8"
>
>
> -- no debconf information
>
> --
> hat hier wer ne arm und schnell zeit n paket zu bauen?
> abi: hast du gerade "arm" und "schnell" in einem Satz benutzt?
On Sun, Sep 06, 2020 at 12:09:29PM -0700, Francois Marier wrote:
> Not a solution to the issue you raised, but in case that helps, I've
> documented my own setup here:
>
> https://feeding.cloud.geek.nz/posts/home-music-server-with-mpd/
>
> Francois
>
> --
> https://fmarier.org/
>
> ___
> Pkg-mpd-maintainers mailing list
> pkg-mpd-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mpd-maintainers
Bug#959693: [Pkg-mpd-maintainers] Bug#959693: mpd: user units should be disabled by default
Hi Andrei, > In the default configuration the user units are both failing for various > reasons: > > 1. Without a user mpd.conf mpd will fall back to /etc/mpd.conf, which in > the default configuration is not suitable for a user daemon. > > 2. The port 6600 is already taken by the system instance. > > Since running a user instance already requires explicit configuration > the user units can be shipped disabled by default, to prevent them from > failing in the default configuration. I agree that enabling user units without providing a working configuration probably doesn't make much sense - it was meant as convenience, but mpd starting without being explicitly enabled by the has caused confusion more than once. Not sure what to do about the XDG autostart file though... > P.S. the mpdconf.example mentioned in README.Debian is missing from the > package oops, thanks for the heads up! Not sure when that one got lost... Florian
Bug#962653: [DAViCal-devel] Bug#962653: davical: diff for NMU version 1.1.9.3-1.1
On Sun, Jul 05, 2020 at 12:46:52PM +0300, Adrian Bunk wrote: > I've prepared an NMU for davical (versioned as 1.1.9.3-1.1) and uploaded > it to DELAYED/3. Please feel free to tell me if I should cancel it. ACK I've been waiting for the pdfrw maintainer to say something about the expected future of his package, but I guess no answer is also an answer, and rst2pdf has no bearing at all on the functioning of davical. So thanks for going ahead with this. Florian > diff -Nru davical-1.1.9.3/debian/changelog davical-1.1.9.3/debian/changelog > --- davical-1.1.9.3/debian/changelog 2020-04-13 23:11:31.0 +0300 > +++ davical-1.1.9.3/debian/changelog 2020-07-05 12:34:48.0 +0300 > @@ -1,3 +1,10 @@ > +davical (1.1.9.3-1.1) unstable; urgency=high > + > + * Non-maintainer upload. > + * Stop using rst2pdf that might not be in bullseye. (Closes: #962653) > + > + -- Adrian Bunk Sun, 05 Jul 2020 12:34:48 +0300 > + > davical (1.1.9.3-1) unstable; urgency=medium > >* New upstream release to support AWL 0.61 > diff -Nru davical-1.1.9.3/debian/control davical-1.1.9.3/debian/control > --- davical-1.1.9.3/debian/control2020-04-13 23:11:31.0 +0300 > +++ davical-1.1.9.3/debian/control2020-07-05 12:34:25.0 +0300 > @@ -11,7 +11,6 @@ > libawl-php (>= 0.61-1~), libawl-php (<< 0.62), > gettext, > doxygen, > - rst2pdf, > php-cli | php5-cli > Vcs-Git: https://gitlab.com/davical-project/davical.git > Vcs-Browser: https://gitlab.com/davical-project/davical
Bug#956650: awl: CVE-2020-11728 CVE-2020-11729
Source: awl Version: 0.60-1 Severity: important Tags: security upstream Two security vulnerabilities were found in the awl package: CVE-2020-11728 Session::__construct() allows use of the current time as a session key https://gitlab.com/davical-project/awl/-/issues/19 CVE-2020-11729 LSIDLogin() is insecure and can allow user impersonation https://gitlab.com/davical-project/awl/-/issues/18 All supported Debian releases are affected.
Bug#718949: #718949 -- libdata-uuid-perl: CVE-2013-4184: symlink attacks vulnerability
While packaging a new upstream version, I was inclined to raise the severity of this bug to RC to start the removal of libdata-uuid-perl. However, it is still a reverse dependency of many dists on cpan, and the suggested replacements have a different API. So I didn't. I didn't forward the patch either: looking at the NOTE paragraph in README, not writing state information to files "will maximize the chances of generating duplicate UUIDs". Umpf.
Bug#946343: [DAViCal-devel] Bug#946343: davical: CVE-2019-18345 CVE-2019-18346 CVE-2019-18347
Hello Salvatore, Security team, On Wed, Dec 11, 2019 at 07:02:31PM +0100, Florian Schlichting wrote: > I've just uploaded davical 1.1.9.2-1 to unstable, which (to the best of > our knowledge) contains complete fixes for all three CVEs, along with a > few other things that have accumulated since the last regular release. > > In order to provide a more targeted fix for Debian (old-)stable, I've > cherry-picked the four relevant commits onto a "buster" branch and > turned them into a quilt patch. The result can be inspected here: > https://gitlab.com/fsfs/davical/compare/master...buster I've updated the changelog entry there to conform to the suggestions from developers-reference for security uploads. I've also pushed branches for stretch (trivial) and jessie (a little more involved due to many changes and add forms in the affected files) to that repo, currently limited to debian/patches and without a changelog entry yet (not sure what you need there). > Unfortunately, I am unfamiliar with the security team procedures and I > will be AFK for ten days from Saturday. If there's anything else I can > still do until then, like making sure the patch fits onto the stretch > and jessie versions as well, or upload fixed packages (how exactly? I've > only ever uploaded to unstable and -backports...) please tell and send > pointers to more info! please advise! Florian
Bug#946343: [DAViCal-devel] Bug#946343: davical: CVE-2019-18345 CVE-2019-18346 CVE-2019-18347
Hi Salvatore, > The following vulnerabilities were published for davical. > > CVE-2019-18345[0]: > | Reflected Cross-Site Scripting (XSS) vulnerability > > CVE-2019-18346[1]: > | A CSRF issue was discovered in DAViCal through 1.1.8. If an > | authenticated user visits an attacker-controlled webpage, the attacker > | can send arbitrary requests in the name of the user to the > | application. If the attacked user is an administrator, the attacker > | could for example add a new admin user. > > > CVE-2019-18347[2]: > | A stored XSS issue was discovered in DAViCal through 1.1.8. It does > | not adequately sanitize output of various fields that can be set by > | unprivileged users, making it possible for JavaScript stored in those > | fields to be executed by another (possibly privileged) user. Affected > | database fields include Username, Display Name, and Email. > > > If you fix the vulnerabilities please also make sure to include the > CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. I've just uploaded davical 1.1.9.2-1 to unstable, which (to the best of our knowledge) contains complete fixes for all three CVEs, along with a few other things that have accumulated since the last regular release. In order to provide a more targeted fix for Debian (old-)stable, I've cherry-picked the four relevant commits onto a "buster" branch and turned them into a quilt patch. The result can be inspected here: https://gitlab.com/fsfs/davical/compare/master...buster Unfortunately, I am unfamiliar with the security team procedures and I will be AFK for ten days from Saturday. If there's anything else I can still do until then, like making sure the patch fits onto the stretch and jessie versions as well, or upload fixed packages (how exactly? I've only ever uploaded to unstable and -backports...) please tell and send pointers to more info! Florian
Bug#943042: gitso: Python2 removal in sid/bullseye
Hi Scott, > > > The package doesn't look all that complicated. I can take a stab at > > > trying > > > to port it to Python 3. If I get it working, perhaps I can ask you to > > > test > > > it? > > > > that would be awesome! I can definitely do the testing. > > I submitted a merge request on salsa: > https://salsa.debian.org/debian/gitso/merge_requests/2 > > Let me know if you run into any problems or have any comments. that was fast! In my testing, the package behaves just like the old version, so I'll prepare an upload in a minute. Thanks a TON! Florian
Bug#943042: gitso: Python2 removal in sid/bullseye
Hi Scott, > The package doesn't look all that complicated. I can take a stab at trying > to port it to Python 3. If I get it working, perhaps I can ask you to test > it? that would be awesome! I can definitely do the testing. Florian
Bug#943042: gitso: Python2 removal in sid/bullseye
Hi Scott, > Do you have any plans to port gitso to Python 3? > > If not, I will probably just convert this to an RM request as it seems gitso > is unmaintained upstream for many years. I have in fact started to look into porting gitso to Python 3, but haven't spent enough time on it to be able to say how long it will take or if it will be doable with my (very limited) python skills. However I still use gitso occasionally and would love to keep it around. Do you have a time frame until such a project would have to be completed? I was of the impression that I had until the bullseye release, but the Python 2 removal seems to be progressing with a lot of energy lately... Florian
Bug#936085: mpd: Can not disable mpd.service and mpd.socket as a user.
Hi Michel, > $ systemctl --user mask --now mpd.socket > Created symlink /home/michel/.config/systemd/user/mpd.socket → /dev/null. [...] > Then reran the tests from bug report #936084 without rebooting. And > everything works as expected; an mpd client can connect to mpd on port > 6600. When I get a chance will repeat the tests after a reboot, just to > make sure. But confident that will no longer have an issue, after > masking the mpd.socket unit. thanks for confirming. And yes it doesn't feel very intuitive and more like a systemd wart :-/ Florian
Bug#933301: mpd: systemd service doesn't use user configured UNIX socket since last update
Hi Simon, On Tue, Oct 01, 2019 at 04:14:40PM +0200, kaliko wrote: > On Sun, 28 Jul 2019 17:14:08 -0400 Simon Désaulniers > wrote: > > […] > > After upgrading from 0.21.5-3 to 0.21.11-1, systemd's mpd service doesn't > > seem > > to use the UNIX socket configured from my mpd configuration located at > > /home/simon/.config/mpd/mpd.conf. > > […] > > I did not manage to reproduce the issue. > I'll try again later on a freshly installed VM upgraded to testing, but so > far I have > not been able to reproduce the issue (tested also with mpd 0.21.15). > > Maybe someone from MPD team is willing to give it a shot. with version 0.21.8, mpd gained a _user_ mpd.socket unit, which defines ListenStream=%t/mpd/socket ListenStream=6600 and is enabled by default. My feeling is that this is responsible for your observed differences between using systemctl and manually launching mpd. Did mpd.socket get stopped/restarted in your testing? HTH, Florian
Bug#921599: [debian-mysql] Bug#921599: mariadb-10.3: always connects to localhost ignoring host entry in option file
Hi Otto, On Thu, Apr 18, 2019 at 10:25:00PM +0300, Otto Kekäläinen wrote: > This is pending since > https://salsa.debian.org/mariadb-team/mariadb-10.3/commit/5046bb4fc2a8ff47a1cf139eba468286a29fcf13 > > Should be fixed when 10.3.14-1 is uploaded. unfortunately, this is not the case. The changes from my merge request (same as https://github.com/MariaDB/mariadb-connector-c/pull/101) are not included in the mariadb-10.3 1:10.3.14-1 source, and testing shows that a hostname set through my.cnf is ignored. Florian
Bug#925207: libsys-statistics-linux-perl: Sys::Statistics::Linux::DiskStats fails to parse /proc/diskstats for kernel >= v4.18
Severity: important
thanks
On Thu, Mar 21, 2019 at 10:31:53AM +0100, Bryan Jurish wrote:
> According to https://www.kernel.org/doc/Documentation/iostats.txt, 4 new
> fields
> were added to /proc/diskstats for kernel version 4.18. As a result, device
> names and the "old" attribute fields are misparsed by the (very narrow)
> regexes
> in Sys/Statistics/Linux/DiskStats.pm . The attached patch appears to fix the
> problem.
The bug becomes visible when calling e.g.
$ perl -MData::Printer -MSys::Statistics::Linux::DiskStats -E'my $lxs =
Sys::Statistics::Linux::DiskStats->new; $lxs->init; p $lxs->get;
The correct output will contain paragraphs like this:
sda1{
major8,
minor1,
rdbyt0.00,
rdreq0.00,
ttbyt0.00,
ttreq0.00,
wrtbyt 0.00,
wrtreq 0.00
},
However on buster currently, output looks like this (notice the "device
name"):
'sda1 3352 39 102172 153321' {
major8,
minor1,
rdbyt0.00,
rdreq0.00,
ttbyt0.00,
ttreq0.00,
wrtbyt 0.00,
wrtreq 0.00
},
The patch from Bryan Jurish (thanks!) correctly fixes this issue for the
buster kernel, however to prevent this from happening again I think the
device name regex should make sure to never match the field separator,
by using (\S+) instead of (.+?) for example.
Florian
Bug#695894: libvorbisidec-dev: please include pkgconfig
Hi Petter and Martin, mpd maintainer here, we're using libvorbisidec on armel as an alternative to vorbis, however we may have to disable it for buster as the upstream build system moved to meson and needs the pkgconfig file to detect vorbisidec. This shouldn't be too hard to fix, don't you think? Also, libvorbisidec has an RC bug (#899907) filed against it and probably needs a new maintainer address for the upcoming buster release, just like the other 5 pkg-xiph packages. Have you considered creating a tracker.d.o team (see https://qa.pages.debian.net/distro-tracker/usage/teams.html) and use that address? Or do you intend to integrate the packages into the multimedia team? I can lend a hand if you indicate the direction into which you want this to go... Florian
Bug#922904: RM: libcpan-meta-perl/2.150010-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm please remove libcpan-meta-perl from testing This is a separately packaged version of a module that is also bundled with Perl core. There is no value in releasing buster with this as a separate package. Bug #915876 (serious) was filed against libcpan-meta-perl in December to have the package auto-removed and kept out of buster, but this doesn't seem to have been effective, hence I'm asking for manual removal now. Florian
Bug#922903: RM: libautodie-perl/2.29-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm please remove libautodie-perl from testing This is a separately packaged version of a module that is also bundled with Perl core. There is no value in releasing buster with this as a separate package. Bug #915550 (serious) was filed against libautodie-perl in December to have the package auto-removed and kept out of buster, but this doesn't seem to have been effective, hence I'm asking for manual removal now. Florian
Bug#807671: 20copyfiles doesn't cope well with absolute symlinks in destination path
this is now https://gitlab.com/codelibre/schroot/merge_requests/20 and was merged to master two years ago. However, this still doesn't fix the issue I face when entering a schroot of main system, with /etc/resolv.conf -> /run/NetworkManager/resolv.conf $ schroot -c thinkpad -u root E: 20copyfiles: realpath: /run/schroot/mount/thinkpad-7b8f67af-f952-4f84-be1d-07ef66e9249a/run/NetworkManager/resolv.conf: No such file or directory E: 20copyfiles: cp: cannot create regular file '': No such file or directory E: thinkpad-7b8f67af-f952-4f84-be1d-07ef66e9249a: Chroot setup failed: stage=setup-start BTW without that patch, it looks like this: $ schroot -c thinkpad -u root E: 20copyfiles: cp: '/etc/resolv.conf' and '/var/run/schroot/mount/thinkpad-fe82a8ce-cf15-4cbb-928c-dfabea3eebbd/etc/resolv.conf' are the same file E: thinkpad-fe82a8ce-cf15-4cbb-928c-dfabea3eebbd: Chroot setup failed: stage=setup-start
Bug#918623: dizzy: Your vendor has not defined OpenGL macro GL_FRAMEBUFFER_EXT
> > It's probably a bit late in the release cycle to "just find out" by > > uploading a -2 with that modified patch. > > ... but its even worse to do nothing since this is an RC bug and this > package as well as its rdepends would be excluded from next release if > the bug is not fixed. I'm coming to the same conclusion, so here we go - upload coming shortly... Florian
Bug#919731: libpoe-component-client-mpd-perl: FTBFS (Can't locate object method "format" via package "Audio::MPD::Common::Item::Song")
Control: reassign 919731 libaudio-mpd-common-perl Control: affects 919731 libpoe-component-client-mpd-perl On Fri, Jan 18, 2019 at 11:40:42PM +, Santiago Vila wrote: > Package: src:libpoe-component-client-mpd-perl > Version: 2.001-2 > Severity: serious > Tags: ftbfs > > Dear maintainer: > > I tried to build this package in buster but it failed: > > > [...] > Can't locate object method "format" via package > "Audio::MPD::Common::Item::Song" at > /<>/blib/lib/POE/Component/Client/MPD/Connection.pm line 232. > # No tests run! > t/62-coll-pick.t . the issue here is that Audio::MPD::Common::Item::Song cannot deal with all of the tags and metadata sent by current MPDs. Reassigning to libaudio-mpd-common-perl, where the list of attributes for a song can be extended. Florian
Bug#919491: ITP: libgeoip2-perl -- Perl API for MaxMind's GeoIP2 web services and databases
Package: wnpp Owner: Florian Schlichting Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name: libgeoip2-perl Version : 2.006001 Upstream Author : Dave Rolsky Greg Oschwald Mark Fowler Olaf Alders * URL : https://metacpan.org/release/GeoIP2 * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl API for MaxMind's GeoIP2 web services and databases GeoIP2 provides an API to version 2 of MaxMinds high-precision IP geo- location web services and databases. It also works with the free and downloadable GeoLite2 databases. This is the Perl implementation of this API. For up to 100x faster database access make sure the recommended libmaxmind-db-reader-xs-perl package is installed as well. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Bug#919483: ITP: libmaxmind-db-reader-xs-perl -- fast XS implementation of the MaxMind DB reader
Package: wnpp Owner: Florian Schlichting Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name: libmaxmind-db-reader-xs-perl Version : 1.07 Upstream Author : Boris Zentner Dave Rolsky Ran Eilam * URL : https://metacpan.org/release/MaxMind-DB-Reader-XS * License : Artistic-2.0 Programming Lang: Perl Description : fast XS implementation of the MaxMind DB reader MaxMind::DB::Reader:XS is an implementation of the MaxMind::DB::Reader API using XS to link against the libmaxminddb library. This is much faster than the Pure Perl implementation: the speedup is typically by a factor of 50-100. Simply installing this package is enough to have MaxMind::DB::Reader automatically load it. The package will be maintained under the umbrella of the Debian Perl Group. It is part of the dependency chain for GeoIP2 -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Bug#919466: ITP: libmaxmind-db-reader-perl -- Perl module to read MaxMind DB files and look up IP addresses
Package: wnpp Owner: Florian Schlichting Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name: libmaxmind-db-reader-perl Version : 1.13 Upstream Author : Dave Rolsky Olaf Alders * URL : https://metacpan.org/release/MaxMind-DB-Reader * License : Artistic-2.0 Programming Lang: Perl Description : Perl module to read MaxMind DB files and look up IP addresses MaxMind::DB::Reader provides a low-level interface to the MaxMind DB file format as described at https://maxmind.github.io/MaxMind-DB/. If you are looking for an interface to MaxMind's GeoIP2 or GeoLite2 downloadable databases, you should also check out the libgeoip2-perl package, which provides a higher level OO interface to those databases. The MaxMind-DB-Reader distribution ships with a single pure Perl implementation of the Reader API. There is a separate distribution that provides an XS implementation, which links against libmaxminddb. It is packaged as libmaxmind-db-reader-xs-perl and approximately 100 times faster than the pure Perl implementation. The package will be maintained under the umbrella of the Debian Perl Group. It is part of the dependency chain for GeoIP2 -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Bug#919464: ITP: libmaxmind-db-common-perl -- collection of common code for the MaxMind DB Perl modules
Package: wnpp Owner: Florian Schlichting Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name: libmaxmind-db-common-perl Version : 0.040001 Upstream Author : Dave Rolsky Olaf Alders * URL : https://metacpan.org/release/MaxMind-DB-Common * License : Artistic-2.0 Programming Lang: Perl Description : collection of common code for the MaxMind DB Perl modules MaxMind::DB::Common provides some shared code for use by both the MaxMind DB reader and writer Perl modules. For now, the only piece documented for public consumption is MaxMind::DB::Metadata. The package will be maintained under the umbrella of the Debian Perl Group. It is part of the dependency chain for GeoIP2. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Bug#919404: ITP: libdata-ieee754-perl -- Perl module to pack and unpack big-endian IEEE754 floats and doubles
Package: wnpp Owner: Florian Schlichting Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name: libdata-ieee754-perl Version : 0.02 Upstream Author : Dave Rolsky * URL : https://metacpan.org/release/Data-IEEE754 * License : Artistic-2.0 Programming Lang: Perl Description : Perl module to pack and unpack big-endian IEEE754 floats and doubles Data::IEEE754 provides some simple convenience functions for packing and unpacking IEEE 754 floats and doubles. Currently this module only implements big-endian order. Patches to add little-endian order subroutines are welcome. The package will be maintained under the umbrella of the Debian Perl Group. It is part of the dependency chain for GeoIP2. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
