Bug#946532: uranium: build depends on cruft package
> Hello, your package build depends on a cruft package, I'm uploading a fix in > deferred/5 > > patch is here: (I'll close the bug before uploading) > - pylint3, python3-pytest, > + pylint, python3-pytest, > python3-pyqt5, Thanks a lot for this! I tested locally and pushed 3.3.0-2 that includes this patch. Unfortunately, but I can't upload as I'm not a DD. Can you or someone from the 3-D printing team push the fixed version from Salsa for me? -> https://salsa.debian.org/3dprinting-team/uranium/-/tags/debian%2F3.3.0-2 Also, it doesn't look like deferred/5 worked as intended: https://ftp-master.debian.org/deferred.html says the upload was only queued for about 2 days, not 5...
Bug#944815: RFS: ledmon/0.93-2 -- Enclosure LED Utilities
On Mon, 9 Dec 2019 12:26:42 +0100 Adam Borowski wrote:> On Mon, Dec 02, 2019 at 04:30:14AM +, Hsieh-Tseng Shen wrote: > > I've uploaded 0.93-2 revision for fixing build failure, please review > > ledmon again. Thanks, > > > > Upstream already had related commit about address-of-packed-member, but > > it seems to remove -Werror directly. Following up this will be next > > release if 0.93-2 can be merged first. > > Uploaded, thank you for adopting the package! > > I see there's an Ubuntu bug about upgrading to not-yet-tagged 0.94: > https://bugs.launchpad.net/ubuntu/+source/ledmon/+bug/1855254 > Thanks for sponsoring ledmon. Very appreciated. I'm aware of that bug and will check once 0.94 is released. Woodrow > > Meow! > -- > ⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, > ⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. > ⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake, > ⠈⠳⣄ etc), let the drink age at least 3-6 months. > > signature.asc Description: PGP signature
Bug#937811: python-hkdf: Python2 removal in sid/bullseye
It looks like all reverse deps are currently exclusively using the Python3 version: [vagrant@debian:~/gnome-keysign] $ apt-rdepends -r python3-hkdf Reading package lists... Done Building dependency tree Reading state information... Done python3-hkdf Reverse Depends: magic-wormhole (0.11.2-1) Reverse Depends: python3-spake2 (0.8-2) magic-wormhole Reverse Depends: gnome-keysign (1.2.0-1) gnome-keysign python3-spake2 Reverse Depends: magic-wormhole (>= 0.11.2-1) [vagrant@debian:~/gnome-keysign] $ apt-rdepends -r python-hkdf Reading package lists... Done Building dependency tree Reading state information... Done python-hkdf I will prepare a QA upload removing the Python2 binary package then, if there are no objections. Cheers Sascha
Bug#944603: Attempt to print checks crashes gnucash
It's strange to it appears the issue has resolved itself and I can now print checks. I moved gnucash files from ~ to ~/Gnucash though not sure how my moving files could've affected anything, probably something changed in the system between tries. The issue can be closed unless someone wants to look into this further. Thanks,
Bug#940578: fixed in cups 2.3.0-6
Hello Intrigeri,
no, this is not included in /etc/apparmor.d/usr.sbin.cupsd.
Regards,
Rudolf Polzer
Am 11.12.19 um 07:50 schrieb intrigeri:
Does your /etc/apparmor.d/usr.sbin.cupsd end with these lines:
# allow read and write on almost anything in @{HOME} (lenient, but
# private-files-strict is in effect), to support customized "Out"
# setting in cups-pdf.conf (Debian#940578)
#include
@{HOME}/[^.]*/{,**/} rw,
@{HOME}/[^.]*/** rw,
}
?
Bug#908698: smarty3: CVE-2018-16831
Hi Salvatore, On Sa 07 Dez 2019 16:30:16 CET, Salvatore Bonaccorso wrote: Hi Mike, On Fri, Feb 15, 2019 at 10:50:32PM +, Mike Gabriel wrote: Hi Moritz, Salvatore, On Do 27 Dez 2018 21:44:33 CET, Salvatore Bonaccorso wrote: > Hi Mike, > > On Thu, Nov 22, 2018 at 08:00:07PM +0100, Moritz Mühlenhoff wrote: > > On Fri, Oct 26, 2018 at 04:46:39PM +, > > mike.gabr...@das-netzwerkteam.de wrote: > > > Hi, > > > > > > On Friday, 26 October 2018, Moritz Mühlenhoff wrote: > > > > On Tue, Sep 18, 2018 at 05:06:14PM +, Mike Gabriel wrote: > > > > > Hi, > > > > > > > > > > On Mo 17 Sep 2018 23:20:33 CEST, Moritz Mühlenhoff wrote: > > > > > > > > > > > On Mon, Sep 17, 2018 at 09:07:38PM +, Mike Gabriel wrote: > > > > > > > I have looked at the changes between 3.1.33 (just uploaded > > to unstable) and > > > > > > > 3.1.31 (in stable). They are awful. Read the below... > > > > > > > > > > > > > > 15:42 < sunweaver> Hi all, I have just looked into > > > > > > > https://security-tracker.debian.org/tracker/CVE-2018-16831 > > > > > > > 15:43 < sunweaver> even for stretch, it is pretty much > > impossible to > > > > > > > backport the patch series (at least for patches, all > > containing tons of > > > > > > > regexp with > > > > > > > multitudes of slashes and backslashes). > > > > > > > 15:43 < sunweaver> totall insane... > > > > > > > 15:44 < sunweaver> in fact, my recommendation for jessie > > and stretch would > > > > > > > be (with my maintainer hat _and_ LTS team hats on at > > once): bring the latest > > > > > > > upstream release to jessie/stretch. > > > > > > > 15:44 < sunweaver> In jessie, we need to upgrade > > smarty-lexer as well for > > > > > > > that. > > > > > > > 15:46 < sunweaver> the 4 patches we needed at least are these... > > > > > > > 15:47 < sunweaver> https://github.com/smarty-php/smarty/commit/8d21f38dc35c4cd6b31c2f23fc9b8e5adbc56dfe > > > > > > > 15:47 < sunweaver> https://github.com/smarty-php/smarty/commit/f9ca3c63d1250bb56b2bda609dcc9dd81f0065f8 > > > > > > > 15:47 < sunweaver> https://github.com/smarty-php/smarty/commit/2e081a51b1effddb23f87952959139ac62654d50 > > > > > > > 15:47 < sunweaver> https://github.com/smarty-php/smarty/commit/c9dbe1d08c081912d02bd851d1d1b6388f6133d1 > > > > > > > 15:48 < sunweaver> and these four sit on top of this... > > > > > > > 15:48 < sunweaver> https://github.com/smarty-php/smarty/commit/f7a53162058de410a35a9848e6d0795d7c252aaf > > > > > > > 15:48 < sunweaver> and 10+ other commits. > > > > > > > 15:48 < sunweaver> all tackling the same code passage. > > > > > > > 15:49 < sunweaver> @all: can we reach consensus that > > latest upstream release > > > > > > > would be best for jessie LTS and stretch (OT here). > > > > > > > > > > > > > > The pile of patches is so awful, I strongly advise getting latest > > > > > > > smarty-lexer and latest smarty3 from unstable into stable > > with thorough > > > > > > > testing of dependent application (gosa, FusionDirectory, > > slbackup-php, ...). > > > > > > > Most of them are maintained by me and I have running > > setups for testing this > > > > > > > (except 1 package in Debian IIRC). > > > > > > > > > > > > If you have reasonable test coverage of the reverse deps, we > > can do that. > > > > > > > > > > > > But let's wait for a few more days to spot eventual > > regressions reported > > > > > > in unstable first. Also, make sure to coordinate the release > > of the DLA with > > > > > > the DSA, otherwise we end up with a situation where > > oldstable has a higher > > > > > > version number than stable. > > > > > > > > > > > > Cheers, > > > > > > Moritz > > > > > > > > > > I will wait another week with this. I'd like to get this > > solved before my > > > > > VAC (6th Oct - 21st Oct). > > > > > > > > What's the status? > > > > > > > > Cheers, > > > > Moritz > > > > > > > > > > I am still waiting for upstream to verify / confirm my patch. Ping > > dropped Monday this week. > > > > Any feedback? > > Did you got any feedback on it? > No. However, this week I took some time and tested my patch more intensively. It throws PHP exceptions on certain code paths. Need to reinvestigate and update my patch... It's on my list, so stay tuned. Sorry for the long delay on my side. We originally had smarty3 as DSA canidate, for CVE-2018-16831 and CVE-2018-16832. But from my understanding of the discussion it is too risky to try to backport. Should we go ahead and mark it no-dsa for stretch? Sorry for the late reply. Replying slipped of the radar. Some months back, I have already spent 1-2-3 hours with backporting the fixing patch, but smarty3 is a fast moving target regarding code changes and backporting is not trivial. My backport introduced other issues (PHP errors IIRC). Neither have I ever received feedback nor input from upstream. I will ask Raphael / Holger, if it is ok to revisit this on Debian LTS funding. The
Bug#945944: stretch-pu: package ros-ros-comm/1.12.6-2
Hi, On Tue, Dec 10, 2019 at 08:15:12PM +, Adam D. Barratt wrote: > On Tue, 2019-12-10 at 21:07 +0100, Jochen Sprickerhof wrote: > > * Adam D. Barratt [2019-12-10 18:35]: > > > On Sun, 2019-12-01 at 14:08 +0100, Jochen Sprickerhof wrote: > > > > This is the same as #945896, just for stretch. I adopted the > > > > values > > > > as reportbug doesn't seem to support stretch-pu. Hope I did it > > > > right. > > > > > > Really? Which version? > > > > 7.5.3 from unstable, which is affected by #938941, which is only > > fixed in stable.. > > *sigh* > > I should probably have triple-checked, but the implication from #935988 > was that the outstanding fixes were being NMUed to unstable. Thanks for > the pointer. Sandro, reportbug in unstable has #938941 open yet (while the support for buster- and stretch-pu requests is present in stable's version, versioned as 7.5.3~deb10u1). Could you do an upload for reportbug including that? Regards, Salvatore
Bug#934735: [pkg-apparmor] Bug#934735: dh-apparmor: please improve dh integration
Control: tag -1 + moreinfo
Hi Andrej!
Andrej Shadura:
> It would be great if the integration with dh could be improved.
I'm glad you care :)
> The first step would be to enable --with=apparmor support with a script
> like this (/usr/share/perl5/Debian/Debhelper/Sequence/apparmor.pm):
> #! /usr/bin/perl
> # debhelper sequence file for dh_apparmor
>
> use warnings;
> use strict;
> use Debian::Debhelper::Dh_Lib;
>
> insert_after("dh_install", "dh_apparmor");
>
> 1
> It would also require dh_apparmor to do some guesswork and not create
> postinst scripts for binary packages not shipping anything
> apparmor-related.
Could you please describe what problem this solution would solve?
One way to explain this could be to show us how you envision this
improved integration would be used in a package, compared to the
status quo.
Cheers,
--
intrigeri
Bug#940578: fixed in cups 2.3.0-6
Hi Rudolf,
Rudolf Polzer:
> audit: type=1400 audit(1574498651.326:33): apparmor="DENIED"
> operation="mknod" profile="/usr/lib/cups/backend/cups-pdf"
> name="/home/rudi/Transport/home_rudi_Transport.pdf" pid=2963 comm="gs"
> requested_mask="c" denied_mask="c" fsuid=1000 ouid=1
You've mentioned earlier that you were running Debian stable,
so perhaps you don't actually have the fix which was uploaded
in cups 2.3.0-6.
Does your /etc/apparmor.d/usr.sbin.cupsd end with these lines:
# allow read and write on almost anything in @{HOME} (lenient, but
# private-files-strict is in effect), to support customized "Out"
# setting in cups-pdf.conf (Debian#940578)
#include
@{HOME}/[^.]*/{,**/} rw,
@{HOME}/[^.]*/** rw,
}
?
Cheers,
--
intrigeri
Bug#930031: thunderbird: [AppArmor] Fixed user fonts and GTK theme not being whitelisted, breaking the UI
Control: reassign -1 apparmor
Control: affects -1 thunderbird
Control: forwarded -1 https://gitlab.com/apparmor/apparmor/merge_requests/442
Control: tag -1 + upstream
Hi,
Vincas Dargis:
> On Wed, 05 Jun 2019 15:47:48 +0200 Nabile wrote:> (I
> am not sure if
> Thunderbird mainly uses GTK2, which only reads from
>> ~/.themes, but since I symlinked ~/.themes to ~/.local/share/themes, it works
>> on my configuration. For those who don't symlink ~/.themes, it may be
>> necessary
>> to add a third whitelist for this folder, provided Thunderbird does use GTK2,
>> of course.)
> `~/.themes` is currently allowed by `gnome` abstraction (which is already
> included by
> usr.bin.thnunderbird profile):
> ```
> fgrep -R ".themes" /etc/apparmor.d/abstractions/
> /etc/apparmor.d/abstractions/gnome: owner @{HOME}/.themes/r,
> /etc/apparmor.d/abstractions/gnome: owner @{HOME}/.themes/** r,
> ```
> You will not "cheat" AppArmor by creating symlinks (unless user uses
> bind-mount I believe), it has
> to check the actual path, so, hence, DENIED.
> I do not know if/how `~/.local/share/themes` location is "standard"/expected
> here. Generally, it's
> advised to modify `/etc/apparmor.d/local/usr.bin.thunderbird` for any local
> customizations.
> Currently, it seems that it's user customization rather than AppArmor
> misconfiguration, so I am not
> sure if we should fix it in Thunderbird's profile or either in gnome
> abstraction.
I did some research and $XDG_DATA_HOME/themes is documented as the
preferred place to store per-user themes since GTK 3.6,
so IMO this is a bug in abstractions/gnome. Reassigning accordingly,
submitted a MR upstream.
And wrt. ~/.local/share/fonts/: that's only a problem on Stretch and
it got fixed in Buster. Given this is kind of a corner case and
Stretch did not have AppArmor enabled by default and will be EOL in ~6
months, I don't think it's worth fixing this in a Stretch
point release.
Cheers,
--
intrigeri
Bug#946576: Mention the word "QR" in the one-line descriptions
Package: zbar-tools Version: 0.23-1.2 Severity: wishlist Now that QR codes are becoming more and more important, please be sure both $ apt-cache search zbar-tools zbar-tools - bar code scanner and decoder (utilities) $ apropos zbarimg zbarimg (1) - scan and decode bar codes from image file(s) mention "QR" in their one line responses. Else the user might not even know he has a QR code reader already installed, or downloadable.
Bug#946575: python3-pikepdf: New upstream version available
Package: python3-pikepdf
Version: 1.7.0+dfsg-1+b1
Severity: wishlist
Hi.
At the current moment, there's a new upstream version (1.8.1) with a very
desirable feature (to pythonically iterate over the objects of a PDF file)
that makes a lot of tasks of inspecting/manipulating such PDF files much
easier than with versions <= 1.7.0.
Please, can a new version of pikepdf be uploaded to the archive?
Thank you very much in advance,
Rogério Brito.
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing'), (200, 'unstable'), (150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.utf-8, LC_CTYPE=pt_BR.utf-8 (charmap=UTF-8),
LANGUAGE=en_US.utf-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages python3-pikepdf depends on:
ii libc6 2.29-3
ii libgcc1 1:9.2.1-21
ii libqpdf26 9.1.0-1
ii libstdc++69.2.1-21
ii python3 3.7.5-1
ii python3-lxml 4.4.1-1+b1
python3-pikepdf recommends no packages.
python3-pikepdf suggests no packages.
-- no debconf information
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Bug#946574: Add --conformable option to output all conformable units
X-debbugs-Cc: adri...@gnu.org Package: units Version: 2.19-1 Severity: wishlist Idea: Let's say we found some mysterious scale, but cannot figure out what units it is reporting in. We reach into our pocket and place an e.g., 3.75 gram coin upon it... Let's say we observe the scale says "0.120". Well running $ for i in pound dram carat grain oz tailiang kin liang troypound \ troyounce pennyweight jewelerspoint momme g apscruple;\ do units --one-line --verbose 3.75g $i; done | sort -k 3n | column -t 3.75g = 0.00625 kin 3.75g = 0.0082673348 pound 3.75g = 0.010047108 troypound 3.75g = 0.036075643 liang 3.75g = 0.1 tailiang 3.75g = 0.1205653 troyounce 3.75g = 0.13227736oz 3.75g = 1 momme 3.75g = 2.1164377 dram 3.75g = 2.411306 pennyweight 3.75g = 2.8935672 apscruple 3.75g = 3.75 g 3.75g = 18.75 carat 3.75g = 57.871344 grain 3.75g = 1875 jewelerspoint tells us the scale is probably talking in troyounces! Problem is: all weight related units are hopelessly scattered around the units file. We need to find each one by hand. Well with a new --conformable flag, we could instead do $ for i in $(units --conformable g); do ... for the same effect. $ units --conformable feet yard km ft m mile $ units --conformable gallon liter pint gallon ...
Bug#946573: libjep-java: Misleading homepage in description
Package: libjep-java Version: 2.4.1+ds-3 Severity: important Dear Maintainer, `aptitude show libjep-java` shows `Homepage: http://www.singularsys.com/jep/`. However, that is the homepage for the commercial non-free version. The correct homepage would be https://github.com/nathanfunk/jep-java-gpl -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-3-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libjep-java depends on: pn libjama-java libjep-java recommends no packages. libjep-java suggests no packages.
Bug#946572: abcm2ps FTCBFS: builds for the build architecture
Source: abcm2ps Version: 8.14.5-0.1 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs abcm2ps fails to cross build from source, because it uses build architecture build tools. The hand-written configure script ignores the --host flag passed by dh_auto_configure. Instead, one is supposed to pass --CC=... For pkg-config, it doesn't even provide a method for substitution. The attached patch makes abcm2ps cross buildable. Please consider applying it. Helmut diff --minimal -Nru abcm2ps-8.14.5/debian/changelog abcm2ps-8.14.5/debian/changelog --- abcm2ps-8.14.5/debian/changelog 2019-09-03 12:07:16.0 +0200 +++ abcm2ps-8.14.5/debian/changelog 2019-12-11 06:09:58.0 +0100 @@ -1,3 +1,12 @@ +abcm2ps (8.14.5-0.2) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: (Closes: #-1) ++ Pass cross tools CC and PKG_CONFIG to ./configure. ++ cross.patch: Make pkg-config substitutable. + + -- Helmut Grohne Wed, 11 Dec 2019 06:09:58 +0100 + abcm2ps (8.14.5-0.1) unstable; urgency=medium * Non-maintainer upload. diff --minimal -Nru abcm2ps-8.14.5/debian/patches/cross.patch abcm2ps-8.14.5/debian/patches/cross.patch --- abcm2ps-8.14.5/debian/patches/cross.patch 1970-01-01 01:00:00.0 +0100 +++ abcm2ps-8.14.5/debian/patches/cross.patch 2019-12-11 06:09:57.0 +0100 @@ -0,0 +1,27 @@ +--- abcm2ps-8.14.5.orig/configure abcm2ps-8.14.5/configure +@@ -5,6 +5,7 @@ + VDATE=2019-07-17 + + CC=gcc ++PKG_CONFIG=pkg-config + CFLAGS="-g -O2 -Wall -pipe" + + srcdir=. +@@ -57,11 +58,11 @@ + DEFAULT_FDIR="$prefix/share/abcm2ps" + fi + +-if which pkg-config > /dev/null ; then +- if pkg-config --exists freetype2 ; then +- if pkg-config --exists pangocairo ; then +- CPPFLAGS="$CPPFLAGS -DHAVE_PANGO=1 `pkg-config pango cairo freetype2 --cflags`" +- LDLIBS="$LDLIBS `pkg-config pangocairo pangoft2 freetype2 --libs`" ++if which $PKG_CONFIG > /dev/null ; then ++ if $PKG_CONFIG --exists freetype2 ; then ++ if $PKG_CONFIG --exists pangocairo ; then ++ CPPFLAGS="$CPPFLAGS -DHAVE_PANGO=1 `$PKG_CONFIG pango cairo freetype2 --cflags`" ++ LDLIBS="$LDLIBS `$PKG_CONFIG pangocairo pangoft2 freetype2 --libs`" + else + echo "pangocairo not found - no pango support" + fi diff --minimal -Nru abcm2ps-8.14.5/debian/patches/series abcm2ps-8.14.5/debian/patches/series --- abcm2ps-8.14.5/debian/patches/series1970-01-01 01:00:00.0 +0100 +++ abcm2ps-8.14.5/debian/patches/series2019-12-11 06:09:24.0 +0100 @@ -0,0 +1 @@ +cross.patch diff --minimal -Nru abcm2ps-8.14.5/debian/rules abcm2ps-8.14.5/debian/rules --- abcm2ps-8.14.5/debian/rules 2019-09-03 12:01:08.0 +0200 +++ abcm2ps-8.14.5/debian/rules 2019-12-11 06:09:58.0 +0100 @@ -2,6 +2,7 @@ DEB_BUILD_MAINT_OPTIONS := hardening=+all DEB_CFLAGS_MAINT_APPEND := -Wall +include /usr/share/dpkg/buildtools.mk include /usr/share/dpkg/buildflags.mk %: @@ -10,4 +11,4 @@ .PHONY: override_dh_auto_configure override_dh_auto_configure: dh_auto_configure -- \ - $(foreach v,CFLAGS CPPFLAGS LDFLAGS,'--$(v)=$($(v))') + $(foreach v,CC PKG_CONFIG CFLAGS CPPFLAGS LDFLAGS,'--$(v)=$($(v))')
Bug#938840: xcffib: Python2 removal in sid/bullseye
severity 938840 serious thanks xcffib build-depends on python-autopep8, which is no longer built by the autopep8 source package. It is still present in unstable as a cruft package, but is completely gone from testing.
Bug#946571: silx, build-depends on obsolete package ipython3-qtconsole
Package: silx Version:0.11.0+dfsg-2 Severity: serious silx build-depends on ipython3-qtconsole which is no longer built by the python-qtconsole source package. It is still present in unstable as a cruft package, but is completely gone from testing. Please change your build-dependency to python3-qtconsole.
Bug#930572: vala-panel-appmenu-common: Global Menu doesn't work for GTK applications
A quick update: I realized that the commands from the gtk-module README are in fact needed for XFCE. I added them to the shell script. -JTS ‐‐‐ Original Message ‐‐‐ On Tuesday, December 10, 2019 3:50 PM, Jacob Sims wrote: > Hi, > > I had the same problem on XFCE in Debian testing. I did some searching of the > original repo's README and discovered there are a few settings that have to > be flipped in XFCE on Debian. Based on similar settings existing for MATE, > I'd assume the same is true there, and, finally, also for Budgie (but that's > not an official Debian DE so I'm not worrying about it). > > For XFCE: > xfconf-query -c xsettings -p /Gtk/ShellShowsMenubar -n -t bool -s true > xfconf-query -c xsettings -p /Gtk/ShellShowsAppmenu -n -t bool -s true > > For MATE: > gsettings set org.mate.interface gtk-shell-shows-app-menu true > gsettings set org.mate.interface gtk-shell-shows-menubar true > > The original information and README are > [here](https://gitlab.com/vala-panel-project/vala-panel-appmenu/blob/master/README.md). > The information about `appmenu-gtk-module' seems not to be relevant to Debian > as the changes it makes seem to be in the install scripts already. > > I have fixed the problem on XFCE by adding a file in the `/debian' direction > called `xfce4-appmenu-plugin.sh' with the above commands. I also made one for > MATE (`debian/mate-applet-appmenu.sh') that presumably works, but I am not > sure since I'm running XFCE. > > I can't find information on exactly how to submit the actual source changes, > so I'm hoping this is the correct way to report fixes. If not, let me know > and I'll happily do things properly. > > Regards, > JTS
Bug#925826: shim: FTBFS w/ GCC 9 fix
Control: tags -1 patch Merge request with fix at https://github.com/rhboot/shim/pull/170
Bug#943022: fonts-noto-color-emoji: Python2 removal in sid/bullseye
Severity 943022 serious
Tags 943022 +patch
Thanks
fonts-noto-color-emoji build-depends on python-nototools, which depends on
python-fonttools which is no longer built by the fonttools source package.
Fortunately upstream has fixes that allow this package to be built with
python3, I applied them as quilt patches, changed the build-dependency and was
able to succesfully build the package.
Note that this patch depends on python3-nototools, which is currently only in
experimental, and the current version of which cannot be successfully
installed. The patch was tested with a locally built python3-nototools that was
fixed as described in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943761
, that patch needs to be applied and the nototools source package uploaded to
unstable before this can be fixed in unstable.
Debdiff attatched, no immediate intent to NMU.
diff -Nru fonts-noto-color-emoji-0~20180810/debian/changelog
fonts-noto-color-emoji-0~20180810/debian/changelog
--- fonts-noto-color-emoji-0~20180810/debian/changelog 2018-08-21
19:26:49.0 +
+++ fonts-noto-color-emoji-0~20180810/debian/changelog 2019-12-11
02:56:18.0 +
@@ -1,3 +1,11 @@
+fonts-noto-color-emoji (0~20180810-1.1) UNRELEASED; urgency=medium
+
+ * Change build-dependencies from python-nototools to python3-nototools
+ * Apply upstream patches for python 3 support.
+ * Clean up __pycache__ in clean target.
+
+ -- Peter Michael Green Wed, 11 Dec 2019 02:56:18 +
+
fonts-noto-color-emoji (0~20180810-1) unstable; urgency=medium
* New upstream release (LP: #1788256)
diff -Nru fonts-noto-color-emoji-0~20180810/debian/control
fonts-noto-color-emoji-0~20180810/debian/control
--- fonts-noto-color-emoji-0~20180810/debian/control2018-08-21
19:26:49.0 +
+++ fonts-noto-color-emoji-0~20180810/debian/control2019-12-11
02:56:18.0 +
@@ -10,7 +10,7 @@
libpng-dev,
pkg-config,
pngquant,
- python-nototools,
+ python3-nototools,
zopfli,
Standards-Version: 4.1.3
Homepage: https://www.google.com/get/noto/help/emoji/
diff -Nru
fonts-noto-color-emoji-0~20180810/debian/patches/py3-01-a9ca546689d384b0ca73ad2a476891c3caaedc20.patch
fonts-noto-color-emoji-0~20180810/debian/patches/py3-01-a9ca546689d384b0ca73ad2a476891c3caaedc20.patch
---
fonts-noto-color-emoji-0~20180810/debian/patches/py3-01-a9ca546689d384b0ca73ad2a476891c3caaedc20.patch
1970-01-01 00:00:00.0 +
+++
fonts-noto-color-emoji-0~20180810/debian/patches/py3-01-a9ca546689d384b0ca73ad2a476891c3caaedc20.patch
2019-12-11 02:50:37.0 +
@@ -0,0 +1,303 @@
+commit a9ca546689d384b0ca73ad2a476891c3caaedc20
+Author: Mike FABIAN
+Date: Wed Jul 17 10:33:21 2019 +0200
+
+Make it work both with Python2 and Python3
+
+diff --git a/add_glyphs.py b/add_glyphs.py
+index 5c71b61b..36d40e67 100644
+--- a/add_glyphs.py
b/add_glyphs.py
+@@ -66,7 +66,7 @@ def collect_seq_to_file(image_dirs, prefix, suffix):
+
+
+ def remap_values(seq_to_file, map_fn):
+- return {k: map_fn(v) for k, v in seq_to_file.iteritems()}
++ return {k: map_fn(v) for k, v in seq_to_file.items()}
+
+
+ def get_png_file_to_advance_mapper(lineheight):
+@@ -228,7 +228,7 @@ def get_rtl_seq(seq):
+
+ rev_seq = list(seq)
+ rev_seq.reverse()
+- for i in xrange(1, len(rev_seq)):
++ for i in range(1, len(rev_seq)):
+ if is_fitzpatrick(rev_seq[i-1]):
+ tmp = rev_seq[i]
+ rev_seq[i] = rev_seq[i-1]
+@@ -282,7 +282,7 @@ def add_ligature_sequences(font, seqs, aliases):
+ return
+
+ rtl_seq_to_target_name = {
+- get_rtl_seq(seq): name for seq, name in seq_to_target_name.iteritems()}
++ get_rtl_seq(seq): name for seq, name in seq_to_target_name.items()}
+ seq_to_target_name.update(rtl_seq_to_target_name)
+ # sequences that don't have rtl variants get mapped to the empty sequence,
+ # delete it.
+@@ -291,7 +291,7 @@ def add_ligature_sequences(font, seqs, aliases):
+
+ # organize by first codepoint in sequence
+ keyed_ligatures = collections.defaultdict(list)
+- for t in seq_to_target_name.iteritems():
++ for t in seq_to_target_name.items():
+ first_cp = t[0][0]
+ keyed_ligatures[first_cp].append(t)
+
+@@ -341,7 +341,7 @@ def apply_aliases(seq_dict, aliases):
+ source is a key in the dictionary, we can delete it. This updates the
+ dictionary and returns the usable aliases."""
+ usable_aliases = {}
+- for k, v in aliases.iteritems():
++ for k, v in aliases.items():
+ if v in seq_dict:
+ usable_aliases[k] = v
+ if k in seq_dict:
+diff --git a/map_pua_emoji.py b/map_pua_emoji.py
+index aac031c5..ff8d6a9b 100644
+--- a/map_pua_emoji.py
b/map_pua_emoji.py
+@@ -53,8 +53,8 @@ def add_pua_cmap(source_file, target_file):
+ """Add PUA characters to the cmap of the first font and save as second."""
+ font = ttLib.TTFont(source_file)
+ cmap =
Bug#945435: nototools Build-Depends on python-fonttools which isn't build from source anymore
On 11/12/2019 02:02, peter green wrote: Second transitioning nototools to python 3 is only really useful if it's rbdeps fonts-noto-color-emoji and fonts-roboto-slab transition too Sorry, it seems that fonts-roboto-slab no longer build-depends on python-nototools, so it is only fonts-noto-color-emoji that we have to worry about.
Bug#943229: speedometer - switch to Python 3
Control: forwarded -1 https://github.com/wardi/speedometer/issues/11 Control: tags -1 patch See https://github.com/wardi/speedometer/pull/17 for Python 3 support
Bug#946570: stretch-pu: package libpst/0.6.59-1+deb9u1
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: pu The version of libpst in stretch does not use AC_USE_SYSTEM_EXTENSIONS, which means that _GNU_SOURCE is not defined before including unistd.h, which means that get_current_dir_name is not defined and so gcc presumes it returns an integer, which means that the returned pointer gets truncated on some architectures and later when the pointer gets freed a program using libpst could crash. This issue is warned about by gcc: https://buildd.debian.org/status/fetch.php?pkg=libpst=amd64=0.6.59-1%2Bb1=1487989748=0 libpst.c: In function 'pst_getcwd': libpst.c:295:11: warning: implicit declaration of function 'get_current_dir_name' [-Wimplicit-function-declaration] cwd = get_current_dir_name(); ^~~~ libpst.c:295:9: warning: assignment makes pointer from integer without a cast [-Wint-conversion] cwd = get_current_dir_name(); ^ The build logs indicate that it was fixed in the version in buster: https://buildd.debian.org/status/fetch.php?pkg=libpst=amd64=0.6.71-0.1=1521798059=0 The package is RFA and this bug is affecting us at work, so I took the liberty of committing to the Debian git repo and submitting this pu. https://salsa.debian.org/debian/libpst/commit/a141fb154e97660e16455689a00d1781858215f3 I have attached the debdiff for this fix. -- bye, pabs https://wiki.debian.org/PaulWise diff -Nru libpst-0.6.59/debian/changelog libpst-0.6.59/debian/changelog --- libpst-0.6.59/debian/changelog 2013-05-19 08:50:03.0 +0800 +++ libpst-0.6.59/debian/changelog 2019-12-11 09:59:25.0 +0800 @@ -1,3 +1,9 @@ +libpst (0.6.59-1+deb9u1) stretch; urgency=medium + + * Fix detection of get_current_dir_name and return truncation + + -- Paul Wise Wed, 11 Dec 2019 09:59:25 +0800 + libpst (0.6.59-1) unstable; urgency=low * [ec26e2d0] Imported Upstream version 0.6.59 diff -Nru libpst-0.6.59/debian/patches/07-use-system-extensions.patch libpst-0.6.59/debian/patches/07-use-system-extensions.patch --- libpst-0.6.59/debian/patches/07-use-system-extensions.patch 1970-01-01 08:00:00.0 +0800 +++ libpst-0.6.59/debian/patches/07-use-system-extensions.patch 2019-12-11 09:59:25.0 +0800 @@ -0,0 +1,17 @@ +Description: use AC_USE_SYSTEM_EXTENSIONS to define _GNU_SOURCE + so get_current_dir_name is detected correctly and + its return value is not truncated, breaking free calls. +Origin: upstream +From: http://hg.five-ten-sg.com/libpst/ +Last-Update: 2019-12-11 +Applied-Upstream: changeset: 328:c507af52515a +--- a/configure.in b/configure.in +@@ -4,6 +4,7 @@ + AC_CONFIG_HEADER([config.h]) + AM_INIT_AUTOMAKE + AC_CANONICAL_HOST ++AC_USE_SYSTEM_EXTENSIONS + + # + # 1. Remember that version-info is current:revision:age, and age <= current. diff -Nru libpst-0.6.59/debian/patches/series libpst-0.6.59/debian/patches/series --- libpst-0.6.59/debian/patches/series 2013-02-21 01:04:13.0 +0800 +++ libpst-0.6.59/debian/patches/series 2019-12-11 09:59:25.0 +0800 @@ -1 +1,2 @@ 06-ld-no-add-needed.patch +07-use-system-extensions.patch signature.asc Description: This is a digitally signed message part
Bug#946567: texlive-latex-extra: broken symlink: /usr/bin/lualatex-dev -> luahbtex
severity 946567 important tag 946567 + pending thanks Hi Andreas, > /usr/bin/lualatex-dev -> luahbtex (texlive-latex-extra) Indeed, we don't ship luahbtex, adjustments are already in the git repo, thanks. Adjusting severity, nothing serious here. Best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#946569: Request for CONFIG_EROFS_FS=m on 5.4+
Source: linux Version: 5.4.2-1~exp1 Severity: normal Hi Debian kernel maintainers, Could you consider enabling EROFS filesystem support as a module from 5.4 for end users now? It has been out of staging. It has much better dynamic performance than squashfs for such like LIVECD use. I'd suggest the following configuration: CONFIG_EROFS_FS=m # CONFIG_EROFS_FS_DEBUG is not set CONFIG_EROFS_FS_XATTR=y CONFIG_EROFS_FS_POSIX_ACL=y CONFIG_EROFS_FS_SECURITY=y CONFIG_EROFS_FS_ZIP=y CONFIG_EROFS_FS_CLUSTER_PAGE_LIMIT=1 erofs-utils package has been available in testing branch as well, https://packages.debian.org/source/bullseye/erofs-utils Thanks, Gao Xiang
Bug#946268: Please add support for custom entries
Quoting andreimpope...@gmail.com (2019-12-08 23:03:01) > On Du, 08 dec 19, 14:38:49, Jonas Smedegaard wrote: > > Quoting andreimpope...@gmail.com (2019-12-08 11:10:25) > > > > > > Ok, attached a patch against u-boot-menu on Salsa/debian > > > implementing this. > > > > > > Comments welcome :) > > > > Please share the patch as attachment here instead. > > I did, see my other message (forgot to attach it the first time). > > Attached again for your convenience. Thanks¹ for the attached patch. Looks great! One detail: Seems more sensible to me to by default check for and include addon config if it exists - i.e. not only if uncommented in main config as in your proposed patch. Do you have some opinion on that? Kind regards, - Jonas ¹ I had email trouble causing delays in my receiving some but not all emails that day, so I didn't see your followup emails until later. -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#946213: RFS: git-delta/0.0.15 -- Syntax-highlighting pager for git and diff output
> On Dec 10, 2019, at 17:44, Adam Borowski wrote: > > On Tue, Dec 10, 2019 at 08:30:44PM -0500, Dan Davison wrote: >> On Sun, 8 Dec 2019 at 22:31, Paul Wise wrote: >>> On Sat, Dec 7, 2019 at 9:36 PM Dan Davison wrote: >>> Currently (FreeBSD, Rust Cargo, Arch Linux, Homebrew) the package name >>> is "git-delta", which installs an executable named "delta". Can it do the >>> same for Debian? >>> >>> There is one package already using that executable name: >>> >>> $ apt-file search bin/delta >>> swap-cwm: /usr/bin/delta > >> You might be right that my naming was suboptimal! Indeed, even the >> git-prefixed package name isn't great because the syntax highlighter works >> for unified diff in addition to git output. However, I'm not sure I'm ready >> to make this breaking change for the existing users yet. Is it an option to >> distribute it for now with the same name as it is currently distributed >> under in ArchLinux, Homebrew, FreeBSD, Windows and Rust Cargo? I.e. >> package: "git-delta" >> executable: "delta" > >> Specifically, are either of the following options? >> >> 1. Package "git-delta" installing executable "delta" (install fail/denied >> if user has the other package installed) >> 2. Package "git-delta" installing executables "delta" and alias "git-delta" >> (only the alias installed if "delta" exists?) > > Sorry, having an executable in $PATH named "delta" is not an option at all. > Policy §10.1. I am not involved in this present RFS and §10.1 is perfectly clear, but how does this apply to some existing packages? Specifically, I’m thinking about ninja and ninja-build. Both install a binary called ‘ninja’ albeit to different paths. Is this permissible because one installs to /usr/bin and the other to /usr/sbin?
Bug#943761: python3-nototools: fails to install: Sorry: IndentationError: unexpected indent (lint_cmap_reqs.py, line 56)
Tags 943761 +patch
Thanks
It seems upstream has already fixed this issue, I applied the upstream commit
as a quilt patch and it resulted in a package that installed successfully. I
also added the missing breaks/replaces.
Debdiff attatched, no immediate intent to NMU.
diff -Nru nototools-0.2.0/debian/changelog nototools-0.2.0/debian/changelog
--- nototools-0.2.0/debian/changelog2019-10-21 11:04:18.0 +
+++ nototools-0.2.0/debian/changelog2019-12-11 00:44:06.0 +
@@ -1,3 +1,12 @@
+nototools (0.2.0-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Apply upstream commit c4a79c79f0da2e6385eab0d89bf5c6546b15e373
+"More updates to make Python 3 compatible"
+ * Add breaks and replaces on python-nototools.
+
+ -- Peter Michael Green Wed, 11 Dec 2019 00:44:06 +
+
nototools (0.2.0-1) experimental; urgency=medium
* New upstream release
diff -Nru nototools-0.2.0/debian/control nototools-0.2.0/debian/control
--- nototools-0.2.0/debian/control 2019-10-21 11:04:18.0 +
+++ nototools-0.2.0/debian/control 2019-12-11 00:44:06.0 +
@@ -20,6 +20,8 @@
Depends: ${misc:Depends},
${python3:Depends},
unicode-data
+Breaks: python-nototools
+Replaces: python-nototools
Description: font support tools from the Noto Fonts project
Noto is a collection of font families, each visually harmonized across
scripts.
diff -Nru nototools-0.2.0/debian/patches/more-python3-fixes.patch
nototools-0.2.0/debian/patches/more-python3-fixes.patch
--- nototools-0.2.0/debian/patches/more-python3-fixes.patch 1970-01-01
00:00:00.0 +
+++ nototools-0.2.0/debian/patches/more-python3-fixes.patch 2019-12-11
00:43:51.0 +
@@ -0,0 +1,1866 @@
+commit c4a79c79f0da2e6385eab0d89bf5c6546b15e373
+Author: punchcutter
+Date: Wed Oct 23 21:51:41 2019 -0700
+
+More updates to make Python 3 compatible
+Added Wancho, Indic Siyaq Numbers, and Mayan Numerals to noto lint
+
+diff --git a/nototools/android_patches.py b/nototools/android_patches.py
+index 67ccc98..fa5f257 100755
+--- a/nototools/android_patches.py
b/nototools/android_patches.py
+@@ -24,6 +24,7 @@ from os import path
+ import shutil
+ import tempfile
+
++from nototools.py23 import unichr
+ from nototools import subset
+ from nototools import coverage
+ from nototools import fix_khmer_and_lao_coverage as merger
+@@ -115,9 +116,9 @@ def _remove_cjk_emoji(cjk_font_names, srcdir, dstdir):
+
+ EMOJI = (
+ [0x26BD, 0x26BE, 0x1F18E]
+- + range(0x1F191, 0x1F19A+1)
++ + list(range(0x1F191, 0x1F19A+1))
+ + [0x1F201, 0x1F21A, 0x1F22F]
+- + range(0x1F232, 0x1F236+1)
++ + list(range(0x1F232, 0x1F236+1))
+ + [0x1F238, 0x1F239, 0x1F23A, 0x1F250, 0x1F251]
+ )
+
+diff --git a/nototools/autofix_for_phase3.py b/nototools/autofix_for_phase3.py
+index e50d709..0a083ee 100755
+--- a/nototools/autofix_for_phase3.py
b/nototools/autofix_for_phase3.py
+@@ -27,7 +27,6 @@ hinted. We also put more info into the version string.
+
+ import argparse
+ import datetime
+-import glob
+ import os
+ from os import path
+ import re
+@@ -35,6 +34,7 @@ import subprocess
+
+ from fontTools import ttLib
+
++from nototools.py23 import basestring
+ from nototools import font_data
+ from nototools import noto_data
+ from nototools import noto_fonts
+@@ -249,7 +249,7 @@ def get_new_version(font, relfont, nversion):
+ return rversion
+ else:
+ n_mm, n_is_phase_2 = _version_str_to_mm(nversion)
+- if n_is_phase2:
++ if n_is_phase_2:
+ raise Exception('bad phase 3 minor version ("%s")' % nversion)
+ if rversion is not None:
+ if n_mm < r_mm:
+diff --git a/nototools/chart/chart.py b/nototools/chart/chart.py
+index 239735d..c0a2d41 100755
+--- a/nototools/chart/chart.py
b/nototools/chart/chart.py
+@@ -76,7 +76,7 @@ num_rows = len(rows)
+ width = NUM_COLS * CELL_SIZE + 2 * (2 * MARGIN + LABEL_WIDTH)
+ height = num_rows * CELL_SIZE + 2 * MARGIN
+
+-print "Generating %s at %.3gx%.3gin" % (outfile, width/72., height/72.)
++print("Generating %s at %.3gx%.3gin" % (outfile, width/72., height/72.))
+ if outfile.endswith(".pdf"):
+ surface = cairo.PDFSurface(outfile, width, height)
+ elif outfile.endswith(".ps"):
+diff --git a/nototools/chart/pycairoft.py b/nototools/chart/pycairoft.py
+index e62a09e..6cb938a 100644
+--- a/nototools/chart/pycairoft.py
b/nototools/chart/pycairoft.py
+@@ -34,7 +34,7 @@ def create_cairo_font_face_for_file (filename, faceindex=0,
loadoptions=0):
+ # initialize freetype
+ _ft_lib = ctypes.c_void_p ()
+ if FT_Err_Ok != _freetype_so.FT_Init_FreeType (ctypes.byref
(_ft_lib)):
+- raise "Error initialising FreeType library."
++ raise Exception("Error initialising FreeType library.")
+
+ _surface = cairo.ImageSurface (cairo.FORMAT_A8, 0, 0)
+
+diff --git a/nototools/cldr_data.py b/nototools/cldr_data.py
Bug#945435: nototools Build-Depends on python-fonttools which isn't build from source anymore
I fear the only solution is to quickly move to the Python 3 package that you already have prepared in experimental. It's not quite that simple, first of all the python3-nototools package in experimental is rc buggy, luckily it seems upstream has a fix. I will post a debdiff for that over at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943761 Second transitioning nototools to python 3 is only really useful if it's rbdeps fonts-noto-color-emoji and fonts-roboto-slab transition too, otherwise you are just trading one rc issue for another. Worse britney does not track build-depends properly, so packages that are only required by build-depends will be removed completely rather than kept around as cruft. A test with fonts-noto-color-emoji, showed that it was not as simple as just switching over the build-dependency, I will post a new bug report over there with more details.
Bug#946518: gitlab: gitalb-unicorn not starting on 12.2.9-5
On 2019, ഡിസംബർ 10 11:26:19 PM IST, Dragos Jarca wrote: >Thx > >Solved installing >http://snapshot.debian.org/archive/debian-ports/20180917T212034Z/pool/main/r/ruby-graphql/ruby-graphql_1.8.4-1_all.deb > >Don't thinked at this solution. > >In my system this package is used only by gitlab. This was updated for gitlab 12.3.8, but it is not yet ready to use. Since it was a minor update, I was not expecting a breakage. >On 10.12.2019 19:20, Pirate Praveen wrote: >> >> On 2019, ഡിസംബർ 10 5:46:50 PM IST, Dragos Jarca > wrote: >>> Package: gitlab >>> Version: 12.2.9-5 >>> Severity: grave >>> Tags: a11y >>> Justification: renders package unusable >>> >>> Dear Maintainer, >>> >>> After update to 12.2.9-5 gitlab-unicorn cannot start. >>> We cannot use gitlab. >>> The error seems to be related to >>> https://gitlab.com/gitlab-org/gitlab-foss/issues/62535 . >>> Thanks >> See if you can use older version of ruby-graphql from >snapshots.debian.net >> >> Else it should be fixed in 12.3.8 I hope. >> >>> /usr/lib/ruby/vendor_ruby/graphql/schema/member/build_type.rb:114:in >>> `to_type_name': Unhandled to_type_name input: (NilClass) >>> (RuntimeError) >> >from /usr/lib/ruby/vendor_ruby/graphql/schema/field.rb:116:in >>> `connection?' >> >from /usr/lib/ruby/vendor_ruby/graphql/schema/field.rb:135:in >`scoped?' >> >from /usr/lib/ruby/vendor_ruby/graphql/schema/field.rb:260:in >>> `initialize' >>> from >>> >/usr/lib/ruby/vendor_ruby/graphql/schema/member/accepts_definition.rb:142:in >>> `initialize' >> >from /usr/share/gitlab/app/graphql/types/base_field.rb:14:in >>> `initialize' >>> from /usr/lib/ruby/vendor_ruby/graphql/schema/field.rb:107:in >`new' >> >from /usr/lib/ruby/vendor_ruby/graphql/schema/field.rb:107:in >>> `from_options' >>> from >>> /usr/lib/ruby/vendor_ruby/graphql/schema/member/has_fields.rb:13:in >>> `field' >> >from /usr/share/gitlab/app/graphql/types/query_type.rb:27:in >>> `' >> >from /usr/share/gitlab/app/graphql/types/query_type.rb:4:in >>> `' >> >from /usr/share/gitlab/app/graphql/types/query_type.rb:3:in `>> (required)>' >>> from >>> >/usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:291:in >>> `require' >>> from >>> >/usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:291:in >>> `block in require' >>> from >>> >/usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:257:in >>> `load_dependency' >>> from >>> >/usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:291:in >>> `require' >>> from >>> >/usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:378:in >>> `block in require_or_load' >>> from >>> >/usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:37:in >>> `block in load_interlock' >>> from >>> >/usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies/interlock.rb:14:in >>> `block in loading' >>> from >>> >/usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/concurrency/share_lock.rb:151:in >>> `exclusive' >>> from >>> >/usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies/interlock.rb:13:in >>> `loading' >>> from >>> >/usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:37:in >>> `load_interlock' >>> from >>> >/usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:356:in >>> `require_or_load' >>> from >>> >/usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:510:in >>> `load_missing_constant' >>> from >>> >/usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:195:in >>> `const_missing' >> >from /usr/share/gitlab/app/graphql/gitlab_schema.rb:26:in >>> `' >> >from /usr/share/gitlab/app/graphql/gitlab_schema.rb:3:in `>> (required)>' >>> from >>> >/usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:291:in >>> `require' >>> from >>> >/usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:291:in >>> `block in require' >>> from >>> >/usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:257:in >>> `load_dependency' >>> from >>> >/usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:291:in >>> `require' >>> from >>> >/usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:378:in >>> `block in require_or_load' >>> from >>> >/usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:37:in >>> `block in load_interlock' >>> from >>>
Bug#946568: libbio-cluster-perl: missing Breaks+Replaces: libbio-perl-perl (<< 1.7.3)
Package: libbio-cluster-perl Version: 1.7.3-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to upgrade from 'stable'. It installed fine in 'stable', then the upgrade to 'sid' fails because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. See policy 7.6 at https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces This test intentionally skipped 'testing' to find file overwrite problems before packages migrate from 'unstable' to 'testing'. >From the attached log (scroll to the bottom...): Preparing to unpack .../libbio-cluster-perl_1.7.3-1_all.deb ... Unpacking libbio-cluster-perl (1.7.3-1) ... dpkg: error processing archive /var/cache/apt/archives/libbio-cluster-perl_1.7.3-1_all.deb (--unpack): trying to overwrite '/usr/share/man/man3/Bio::Cluster::ClusterFactory.3pm.gz', which is also in package libbio-perl-perl 1.7.2-3 Errors were encountered while processing: /var/cache/apt/archives/libbio-cluster-perl_1.7.3-1_all.deb cheers, Andreas libbio-perl-perl=1.7.2-3_libbio-cluster-perl=1.7.3-1.log.gz Description: application/gzip
Bug#946567: texlive-latex-extra: broken symlink: /usr/bin/lualatex-dev -> luahbtex
Package: texlive-latex-extra Version: 2019.20191208-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package ships (or creates) a broken symlink. >From the attached log (scroll to the bottom...): 1m17.6s ERROR: FAIL: Broken symlinks: /usr/bin/lualatex-dev -> luahbtex (texlive-latex-extra) cheers, Andreas texlive-latex-extra_2019.20191208-1.log.gz Description: application/gzip
Bug#946213: RFS: git-delta/0.0.15 -- Syntax-highlighting pager for git and diff output
On Tue, Dec 10, 2019 at 08:30:44PM -0500, Dan Davison wrote: > On Sun, 8 Dec 2019 at 22:31, Paul Wise wrote: > > On Sat, Dec 7, 2019 at 9:36 PM Dan Davison wrote: > > > > > Currently (FreeBSD, Rust Cargo, Arch Linux, Homebrew) the package name > > is "git-delta", which installs an executable named "delta". Can it do the > > same for Debian? > > > > There is one package already using that executable name: > > > > $ apt-file search bin/delta > > swap-cwm: /usr/bin/delta > You might be right that my naming was suboptimal! Indeed, even the > git-prefixed package name isn't great because the syntax highlighter works > for unified diff in addition to git output. However, I'm not sure I'm ready > to make this breaking change for the existing users yet. Is it an option to > distribute it for now with the same name as it is currently distributed > under in ArchLinux, Homebrew, FreeBSD, Windows and Rust Cargo? I.e. > package: "git-delta" > executable: "delta" > Specifically, are either of the following options? > > 1. Package "git-delta" installing executable "delta" (install fail/denied > if user has the other package installed) > 2. Package "git-delta" installing executables "delta" and alias "git-delta" > (only the alias installed if "delta" exists?) Sorry, having an executable in $PATH named "delta" is not an option at all. Policy §10.1. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, ⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. ⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake, ⠈⠳⣄ etc), let the drink age at least 3-6 months.
Bug#946566: r-cran-xml2: broken symlink: /usr/lib/R/site-library/xml2/extdata/html5shiv.min.js -> ../../../../nodejs/html5shiv/dist/html5shiv.min.js
Package: r-cran-xml2 Version: 1.2.2-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package ships (or creates) a broken symlink. >From the attached log (scroll to the bottom...): 1m16.7s ERROR: FAIL: Broken symlinks: /usr/lib/R/site-library/shiny/www/shared/bootstrap/shim/html5shiv.min.js -> ../../../../../../../nodejs/html5shiv/dist/html5shiv.min.js (r-cran-shiny) /usr/lib/R/site-library/xml2/extdata/html5shiv.min.js -> ../../../../nodejs/html5shiv/dist/html5shiv.min.js (r-cran-xml2) html5shiv.min.js lives in /usr/share, not /usr/lib. cheers, Andreas r-cran-xml2_1.2.2-1.log.gz Description: application/gzip
Bug#946213: RFS: git-delta/0.0.15 -- Syntax-highlighting pager for git and diff output
On Sun, 8 Dec 2019 at 22:31, Paul Wise wrote: > On Sat, Dec 7, 2019 at 9:36 PM Dan Davison wrote: > > > Currently (FreeBSD, Rust Cargo, Arch Linux, Homebrew) the package name > is "git-delta", which installs an executable named "delta". Can it do the > same for Debian? > > There is one package already using that executable name: > > $ apt-file search bin/delta > ... > swap-cwm: /usr/bin/delta > > In general, it is a bad idea to use generic names because of the > potential for namespace conflicts (in $PATH, package names etc). > > A rebrand to something like diff-syntax-highlight or git-delta might > be a good idea. > You might be right that my naming was suboptimal! Indeed, even the git-prefixed package name isn't great because the syntax highlighter works for unified diff in addition to git output. However, I'm not sure I'm ready to make this breaking change for the existing users yet. Is it an option to distribute it for now with the same name as it is currently distributed under in ArchLinux, Homebrew, FreeBSD, Windows and Rust Cargo? I.e. package: "git-delta" executable: "delta" (For all but Rust Cargo this is in conflict with the other project, for which package = executable = delta).) Specifically, are either of the following options? 1. Package "git-delta" installing executable "delta" (install fail/denied if user has the other package installed) 2. Package "git-delta" installing executables "delta" and alias "git-delta" (only the alias installed if "delta" exists?) > > -- > bye, > pabs > > https://wiki.debian.org/PaulWise >
Bug#774415: #774415: devscripts: please add the srebuild wrapper for reproducible builds
Following up from the conference last week - yes we're using srebuild from debian-rebuilder-setup. Thanks, Matt Bearup Software Developer – CEH, CISSP, GCUX Microsoft Azure Compute Linux -Original Message- From: Santiago Torres Arias Sent: Monday, October 7, 2019 11:49 AM To: Matt Bearup Cc: Steven Chamberlain ; kpcyrd ; Holger Levsen ; 774...@bugs.debian.org; Reproducible Builds discussion list ; Xavier Subject: Re: #774415: devscripts: please add the srebuild wrapper for reproducible builds Curious, was the srebuild the one as featured in the debian-rebuilder-setup[1] repository or the upstream one? I don't think we've faced much build issues on our side... Cheers! -Santiago [1] https://salsa.debian.org/reproducible-builds/debian-rebuilder-setup On Mon, Oct 07, 2019 at 06:03:08PM +, Matt Bearup wrote: > I have to second the issues with srebuild. We invested a lot of time to > utilize this tool in our rebuilds but faced consistent build failures. > The best explanation I could find was that the snapshots referred to in the > .buildinfo files had expired. That's not conclusive (the output wasn't clear > on the cause of failure) nor is expired repo metadata the fault of srebuild > per se. But the issue was nonetheless a blocker. > PBuilder is the most consistent build tool we've seen thus far, will have to > investigate debrebuild as well. > > Matt Bearup > Software Developer – CEH, CISSP, GCUX > Microsoft Azure Compute Linux
Bug#946565: regression: Could NOT find Boost (missing: python3)
Hi,
On Wed, 11 Dec 2019 at 00:45, Johannes 'josch' Schauer wrote:
>
> Package: libboost-python1.67-dev
> Version: 1.67.0-15
> Severity: important
>
> Hi,
>
> I'm using the following CMakeLists.txt:
>
> cmake_minimum_required(VERSION 3.13)
> project(foo)
> find_package(PythonLibs 3 REQUIRED)
> find_package(Boost 1.45.0 COMPONENTS "python3" REQUIRED)
>
Above uses obsolete ways of finding both python and boost-python components.
PythonLibs has moved onto to just Python, with components.
Boost has moved onto providing fixed abi components only, without any
"convenience" libraries. After all, one cannot simply change
boost_python3 so-name to be 3.8 instead of 3.7.
Added bonus, this new way works across all OSes and Distros, be it
Debian/Ubuntu/Fedora/RHEL/Windows/MacOSX/vanilla-upstream-self-compiled.
The new way of doing things is shown in our autopkgtests:
https://salsa.debian.org/debian/boost/raw/master/debian/tests/srcs/python/CMakeLists.txt
NB! note that python3-dev or python3-all-dev is needed
NB! note that there are slightly different names for the Python_*
variables i.e. one may need to change PYTHON_* variables to Python_
with new suffixes
Which will be updated if things change in the future, including here
verbatim for convenience
project(Boost CXX)
cmake_minimum_required(VERSION 3.0)
FIND_PACKAGE(Python 3 REQUIRED COMPONENTS Interpreter Development)
INCLUDE_DIRECTORIES( ${Python_INCLUDE_DIR} )
FIND_PACKAGE(Boost COMPONENTS
python${Python_VERSION_MAJOR}${Python_VERSION_MINOR} REQUIRED)
INCLUDE_DIRECTORIES (${Boost_INCLUDE_DIRS})
ADD_LIBRARY(demo1 SHARED demo1.cpp)
TARGET_LINK_LIBRARIES(demo1 ${Boost_LIBRARIES} ${Python_LIBRARIES})
ADD_LIBRARY(demo2 SHARED demo2.cpp)
TARGET_LINK_LIBRARIES(demo2 ${Boost_LIBRARIES} ${Python_LIBRARIES})
Or forexample, you can query what the currenty py3versions default
version is and requet pythonXY boost component that way.
> Everything works fine on Debian Buster with libboost-python1.67-dev
> version 1.67.0-13:
This new way of doing things, will also work on prior debian releases.
python python3 python-pyXY are all obsolete (and at times Debian-only)
abi symlinks
python27 python37 python38 are the only ones that are going to be
available going forward, and also have been available in the past.
Please adjust your CMakeLists for the future.
--
Regards,
Dimitri.
Bug#946562: fixed in firewalld-0.8.0?
The issue may be fixed in firewalld-0.8.0, judging by the commits in the commits in the upstream issue (https://github.com/firewalld/firewalld/issues/430), despite it being closed won't fix. Thanks, Alex
Bug#946565: regression: Could NOT find Boost (missing: python3)
Package: libboost-python1.67-dev Version: 1.67.0-15 Severity: important Hi, I'm using the following CMakeLists.txt: cmake_minimum_required(VERSION 3.13) project(foo) find_package(PythonLibs 3 REQUIRED) find_package(Boost 1.45.0 COMPONENTS "python3" REQUIRED) Everything works fine on Debian Buster with libboost-python1.67-dev version 1.67.0-13: -- The C compiler identification is GNU 8.3.0 -- The CXX compiler identification is GNU 8.3.0 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.7m.so (found suitable version "3.7.3", minimum required is "3") -- Boost version: 1.67.0 -- Found the following Boost libraries: -- python3 -- Configuring done -- Generating done -- Build files have been written to: /tmp The problem only occurs after upgrading to 1.67.0-15 from unstable: -- The C compiler identification is GNU 8.3.0 -- The CXX compiler identification is GNU 8.3.0 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.7m.so (found suitable version "3.7.5", minimum required is "3") CMake Error at /usr/share/cmake-3.15/Modules/FindPackageHandleStandardArgs.cmake:137 (message): Could NOT find Boost (missing: python3) (found suitable version "1.67.0", minimum required is "1.45.0") Call Stack (most recent call first): /usr/share/cmake-3.15/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE) /usr/share/cmake-3.15/Modules/FindBoost.cmake:2161 (find_package_handle_standard_args) CMakeLists.txt:4 (find_package) -- Configuring incomplete, errors occurred! See also "/tmp/CMakeFiles/CMakeOutput.log". Please fix this regression. Thanks! cheers, josch
Bug#945173: usrmerge: unable to convert when using overlay fs
Do you think that something else should be investigated or should I close this bug? On Nov 20, Marco d'Itri wrote: > On Nov 20, Vagrant Cascadian wrote: > > > My sbuild configuration has build chroots with overlay fs, and my > > configuration has a chroot on ext4 and an overlay on top on tmpfs, but > > usrmerge fails to convert this system: > It makes sense, since overlayfs by default does not support renaming > directories on the lower layer: > https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt > > > Not sure what it would take to make it possible to convert in such a > > scenario. > Maybe you could try the redirect_dir feature? > > -- > ciao, > Marco -- ciao, Marco signature.asc Description: PGP signature
Bug#946563: there is no need for a versioned libxcrypt1-dev package
On Dec 11, Matthias Klose wrote: > there is really no need for a versioned libxcrypt1-dev package. Please rename > that properly to libxcrypt-dev. Can you be more specific in why this would not be allowed? Currently I am not building libxcrypt2 and libxcrypt2-dev, but the package is ready to do it. libxcrypt1-dev and libxcrypt2-dev cannot be installed at the same time, but libxcrypt1 and libxcrypt2 can. -- ciao, Marco signature.asc Description: PGP signature
Bug#693587: bind9: stop resolving
Control: forwarded -1 https://gitlab.isc.org/isc-projects/bind9/issues/1483 On Nov 24, Ondřej Surý wrote: > could you please fill an upstream issue? Done. I will also add that I have found a workaround: sending SIGSTOP to named before suspend and SIGCONT a few seconds after resume. -- ciao, Marco signature.asc Description: PGP signature
Bug#946564: RFS: audacity/2.3.3-1 -- Fast, cross-platform audio editor
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "audacity": * Package name : audacity Version : 2.3.3-1 Upstream Author : Audacity Team * URL : https://www.audacityteam.org/ * License : CC-BY or GPL-2+ * Vcs : https://github.com/audacity/audacity Section : sound It builds those binary packages: audacity - Fast, cross-platform audio editor audacity-data - Fast, cross-platform audio editor (data) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/audacity Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/a/audacity/audacity_2.3.3-1.dsc Changes since the last upload: * Bump debhelper-compat to 12. * Bump Standards-Version to 4.4.1. * Drop obsolete d/NEWS file. * debian/patches: + 0002-workaround-wxwidgets-fit-recovery.patch: Drop, Obsolete. + 0005-Fix-building-against-the-system-portaudio-library.patch: Update. Regards, Dennis
Bug#946563: there is no need for a versioned libxcrypt1-dev package
Package: src:libxcrypt Version: 1:4.4.10-5 Severity: serious Tags: sid bullseye there is really no need for a versioned libxcrypt1-dev package. Please rename that properly to libxcrypt-dev.
Bug#946562: More info
This bug is a regression on the situation in Debian 9 (where firewalld works with the same monolithic kernel). I also tested and this is still a problem in the version currently in testing and unstable (0.7.2-1). Thanks, Alex
Bug#946554: [Tts-project] Bug#946554: speech-dispatcher: please omit speech-dispatcher-festival on Ubuntu/i386
Steve Langasek, le mar. 10 déc. 2019 15:10:48 -0800, a ecrit: > On Tue, Dec 10, 2019 at 11:50:07PM +0100, Samuel Thibault wrote: > > Steve Langasek, le mar. 10 déc. 2019 14:45:54 -0800, a ecrit: > > > Sorry for being unclear. speech-dispatcher-ibmtts is built from > > > speech-dispatcher-contrib, and depends on speech-dispatcher-audio-plugins; > > > so speech-dispatcher itself needs to be kept around on i386 in order for > > > speech-dispatcher-ibmtts to be installable. > > > Ah, ok, right. But other speech-dispatcher packages > > like speech-dispatcher-flite, speech-dispatcher-cicero, > > speech-dispatcher-espeak, speech-dispatcher-espeak-ng are not a problem > > for now? > > That's correct, all of their other dependencies are also in the set of > libraries that are being kept on i386, but festival is not. Ok, alright then :) I have pushed the patch. Samuel
Bug#946554: [Tts-project] Bug#946554: speech-dispatcher: please omit speech-dispatcher-festival on Ubuntu/i386
On Tue, Dec 10, 2019 at 11:50:07PM +0100, Samuel Thibault wrote: > Steve Langasek, le mar. 10 déc. 2019 14:45:54 -0800, a ecrit: > > Sorry for being unclear. speech-dispatcher-ibmtts is built from > > speech-dispatcher-contrib, and depends on speech-dispatcher-audio-plugins; > > so speech-dispatcher itself needs to be kept around on i386 in order for > > speech-dispatcher-ibmtts to be installable. > Ah, ok, right. But other speech-dispatcher packages > like speech-dispatcher-flite, speech-dispatcher-cicero, > speech-dispatcher-espeak, speech-dispatcher-espeak-ng are not a problem > for now? That's correct, all of their other dependencies are also in the set of libraries that are being kept on i386, but festival is not. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#946562: firewalld: Firewalld does not run on systems with a monolithic kernel
Package: firewalld Version: 0.6.3-5 Severity: normal Tags: upstream Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** On a system with a monolithic kernel, firewalld fails to run: # systemctl status firewalld|cat ● firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled) Active: inactive (dead) since Tue 2019-12-10 22:44:12 UTC; 6min ago Docs: man:firewalld(1) Main PID: 6363 (code=exited, status=0/SUCCESS) Dec 10 22:44:11 alex.test.rimuhosting.com systemd[1]: Starting firewalld - dynamic firewall daemon... Dec 10 22:44:11 alex.test.rimuhosting.com systemd[1]: Started firewalld - dynamic firewall daemon. Dec 10 22:44:12 alex.test.rimuhosting.com firewalld[6363]: ERROR: Failed to load nf_conntrack module: modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.19.87-rh117-20191201200735.xenU.x86_64/modules.dep.bin' modprobe: FATAL: Module nf_conntrack not found in directory /lib/modules/4.19.87-rh117-20191201200735.xenU.x86_64 Dec 10 22:44:12 alex.test.rimuhosting.com firewalld[6363]: ERROR: Raising SystemExit in run_server Dec 10 22:44:12 alex.test.rimuhosting.com systemd[1]: firewalld.service: Succeeded. This applies in some cases when there is a custom kernel or with some VPS kernels. Not with the standard Debian kernels. The problem is addressed in an upstream bug marked won't fix: https://github.com/firewalld/firewalld/issues/430. Firewalld calls modprobe even though the required functionality is already in the kernel, and fails when modprobe fails. I would expect firewalld to start correctly if the required functionality is built in to the kernel. I tried: 1. removing the kmod package (and therefore modprobe), and firewalld still fails to start. 2. ln -s /bin/true /bin/modprobe Still did not work. Thanks, Alex *** End of the template - remove these template lines *** -- System Information: Debian Release: 10.2 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.87-rh117-20191201200735.xenU.x86_64 (SMP w/12 CPU cores) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages firewalld depends on: ii dbus 1.12.16-1 ii gir1.2-glib-2.0 1.58.3-2 ii init-system-helpers 1.56+nmu1 ii iptables 1.8.2-4 ii policykit-1 0.105-25 ii python3 3.7.3-1 ii python3-dbus 1.2.8-3 ii python3-gi 3.30.4-1 ii python3-slip-dbus0.6.5-2 Versions of packages firewalld recommends: ii ipset 6.38-1.2 firewalld suggests no packages. -- no debconf information
Bug#946561: hplip: Not installable with python3 >= 3.8
Package: hplip Severity: grave Justification: renders package unusable -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (700, 'experimental'), (300, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages hplip depends on: ii adduser3.118 ii cups 2.3.0-7 pn hplip-data ii libc6 2.29-6 ii libcups2 2.3.0-7 ii libdbus-1-31.12.16-2 ii libhpmud0 3.19.11+dfsg0-1 ii libpython3.7 3.7.5-2 ii libsane1.0.27-3.2+b1 pn libsane-hpaio ii lsb-base 11.1.0 ii printer-driver-hpcups 3.19.11+dfsg0-1 ii python33.8.0-2 ii python3-dbus 1.2.14-1 ii python3-gi 3.34.0-3 pn python3-pexpect pn python3-pil pn python3-reportlab ii wget 1.20.3-1+b2 ii xz-utils 5.2.4-1+b1 Versions of packages hplip recommends: ii avahi-daemon 0.7-4+b1 ii policykit-1 0.105-26 ii printer-driver-postscript-hp 3.19.11+dfsg0-1 ii sane-utils1.0.27-3.2+b1 Versions of packages hplip suggests: pn hplip-doc pn hplip-gui pn python3-notify2 ii system-config-printer 1.5.12-1
Bug#946540: closed by Andreas Metzler (Re: Bug#946540: Revise README.Debian)
> "AM" == Andreas Metzler writes: >> OK, but the user doesn't know what to fill in for e.g., >> commonName = Server name (eg. ssl.domain.tld; required!!!) >> commonName_max = 64 AM> If they have a stable they will know. If they do not, there is not AM> correct response. So the typical laptop owner could never fill this field in correctly. >> Thus for users on their own personal computers, perhaps add a note to >> README, that the warnings can safely be ignored. AM> Ok. Indeed, for the typical laptop owner, there should be some setting in /etc/exim4/update-exim4.conf.conf: dc_typical_laptop_owner='take care of all that certificate stuff for me and dont put warnings in mainlog' That way he could focus on real warnings, and not warnings about things he could never fix even if he wanted.
Bug#946560: stretch-pu: package proftpd-dfsg/1.3.5b-4+deb9u3
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Hello,
te attached debdiff fixes the issues
#946345 proftpd-dfsg: CVE-2019-19269
...for Debian stretch. I built/installed the package an Debian oldstable
and could login into the server and transfer file.
Hilmar
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 5.3.0-3-686-pae (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_GB.UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set
to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru proftpd-dfsg-1.3.5b/debian/changelog
proftpd-dfsg-1.3.5b/debian/changelog
--- proftpd-dfsg-1.3.5b/debian/changelog2019-10-23 23:34:50.0
+0200
+++ proftpd-dfsg-1.3.5b/debian/changelog2019-12-08 16:52:34.0
+0100
@@ -1,3 +1,11 @@
+proftpd-dfsg (1.3.5b-4+deb9u3) stretch-security; urgency=medium
+
+ * Cherry pick patch from upstream:
+ - for upstream 861 (CVE-2019-19269) (Closes: #946345)
+ upstream_pull_861_CVE-2019-19269
+
+ -- Hilmar Preusse Sun, 08 Dec 2019 16:52:34 +0100
+
proftpd-dfsg (1.3.5b-4+deb9u2) stretch-security; urgency=high
* Add patch from upstream to address CVE-2019-18217.
diff -Nru proftpd-dfsg-1.3.5b/debian/patches/series
proftpd-dfsg-1.3.5b/debian/patches/series
--- proftpd-dfsg-1.3.5b/debian/patches/series 2019-10-23 23:24:27.0
+0200
+++ proftpd-dfsg-1.3.5b/debian/patches/series 2019-12-08 16:52:34.0
+0100
@@ -17,3 +17,4 @@
CVE-2017-7418
proftpd-1.3.5e-CVE-2019-12815.patch
bug_846_CVE-2019-18217.patch
+upstream_861_CVE-2019-19269
diff -Nru proftpd-dfsg-1.3.5b/debian/patches/upstream_861_CVE-2019-19269
proftpd-dfsg-1.3.5b/debian/patches/upstream_861_CVE-2019-19269
--- proftpd-dfsg-1.3.5b/debian/patches/upstream_861_CVE-2019-19269
1970-01-01 01:00:00.0 +0100
+++ proftpd-dfsg-1.3.5b/debian/patches/upstream_861_CVE-2019-19269
2019-12-08 16:52:34.0 +0100
@@ -0,0 +1,12 @@
+--- proftpd-dfsg.orig/contrib/mod_tls.c
proftpd-dfsg/contrib/mod_tls.c
+@@ -5862,6 +5862,9 @@
+ ASN1_INTEGER *sn;
+
+ revoked = sk_X509_REVOKED_value(X509_CRL_get_REVOKED(crl), i);
++ if (revoked == NULL) {
++ continue;
++ }
+ sn = revoked->serialNumber;
+
+ if (ASN1_INTEGER_cmp(sn, X509_get_serialNumber(xs)) == 0) {
Bug#946554: [Tts-project] Bug#946554: speech-dispatcher: please omit speech-dispatcher-festival on Ubuntu/i386
Steve Langasek, le mar. 10 déc. 2019 14:45:54 -0800, a ecrit: > Sorry for being unclear. speech-dispatcher-ibmtts is built from > speech-dispatcher-contrib, and depends on speech-dispatcher-audio-plugins; > so speech-dispatcher itself needs to be kept around on i386 in order for > speech-dispatcher-ibmtts to be installable. Ah, ok, right. But other speech-dispatcher packages like speech-dispatcher-flite, speech-dispatcher-cicero, speech-dispatcher-espeak, speech-dispatcher-espeak-ng are not a problem for now? Samuel
Bug#946547: firefox: Can't write to local storage in Firefox 71, several extensions broken
Fedora seem to have hit the same issue: https://bugzilla.redhat.com/show_bug.cgi?id=1779570 I'm experiencing this with LastPass which is quite annoying, a fixed Debian build would be much appreciated!
Bug#946554: [Tts-project] Bug#946554: speech-dispatcher: please omit speech-dispatcher-festival on Ubuntu/i386
On Tue, Dec 10, 2019 at 11:13:28PM +0100, Samuel Thibault wrote: > Hello, > Steve Langasek, le mar. 10 déc. 2019 12:42:05 -0800, a ecrit: > > In Ubuntu, we are in the process of moving the i386 architecture to a > > compatibility-only layer on amd64. We are keeping speech-dispatcher on i386 > > because speech-dispatcher-ibmtts is only available on this arch, but > > speech-dispatcher-festival is built from this source package > I don't understand: the speech-dispatcher-ibmtts binary package is built > from the speech-dispatcher-contrib source package, not from the > speech-dispatcher source package. Sorry for being unclear. speech-dispatcher-ibmtts is built from speech-dispatcher-contrib, and depends on speech-dispatcher-audio-plugins; so speech-dispatcher itself needs to be kept around on i386 in order for speech-dispatcher-ibmtts to be installable. (speech-dispatcher is Multi-Arch: foreign so the amd64 build of this would be sufficient - although our i386 whitelisting in Ubuntu doesn't currently have a way of understanding that - but speech-dispatcher-audio-plugins is Multi-Arch: same, so speech-dispatcher-ibmtts's dependency on this package is only satisfied by the i386 build. So both packages need to be kept around on i386, but we want to drop the speech-dispatcher-festival binary. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#946559: buster-pu: package proftpd-dfsg/1.3.6-4+deb10u3
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Hello,
te attached debdiff fixes the issues
#946345 proftpd-dfsg: CVE-2019-19269
#946346 proftpd-dfsg: CVE-2019-19270
...for Debian buster. I built/installed the package an Debian stable
and could login into the server and transfer file.
Hilmar
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 5.3.0-3-686-pae (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_GB.UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set
to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru proftpd-dfsg-1.3.6/debian/changelog
proftpd-dfsg-1.3.6/debian/changelog
--- proftpd-dfsg-1.3.6/debian/changelog 2019-10-23 16:22:38.0 +0200
+++ proftpd-dfsg-1.3.6/debian/changelog 2019-12-08 16:19:57.0 +0100
@@ -1,3 +1,12 @@
+proftpd-dfsg (1.3.6-4+deb10u3) buster-security; urgency=medium
+
+ * Cherry pick patch from upstream:
+ - for upstream 861 (CVE-2019-19269) (Closes: #946345)
+ - for upstream 859 (CVE-2019-19270) (Closes: #946346)
+ upstream_pull_859_861_CVE-2019-19270_CVE-2019-19269
+
+ -- Hilmar Preusse Sun, 08 Dec 2019 16:19:57 +0100
+
proftpd-dfsg (1.3.6-4+deb10u2) buster-security; urgency=medium
* Add patch from upstream to address CVE-2019-18217.
diff -Nru proftpd-dfsg-1.3.6/debian/patches/series
proftpd-dfsg-1.3.6/debian/patches/series
--- proftpd-dfsg-1.3.6/debian/patches/series2019-10-23 16:22:38.0
+0200
+++ proftpd-dfsg-1.3.6/debian/patches/series2019-12-08 16:19:57.0
+0100
@@ -19,3 +19,4 @@
github_pr_594
CVE-2019-12815.patch
bug_846_CVE-2019-18217.patch
+upstream_pull_859_861_CVE-2019-19270_CVE-2019-19269
diff -Nru
proftpd-dfsg-1.3.6/debian/patches/upstream_pull_859_861_CVE-2019-19270_CVE-2019-19269
proftpd-dfsg-1.3.6/debian/patches/upstream_pull_859_861_CVE-2019-19270_CVE-2019-19269
---
proftpd-dfsg-1.3.6/debian/patches/upstream_pull_859_861_CVE-2019-19270_CVE-2019-19269
1970-01-01 01:00:00.0 +0100
+++
proftpd-dfsg-1.3.6/debian/patches/upstream_pull_859_861_CVE-2019-19270_CVE-2019-19269
2019-12-08 16:19:57.0 +0100
@@ -0,0 +1,35 @@
+From 81cc5dce4fc0285629a1b08a07a109af10c208dd Mon Sep 17 00:00:00 2001
+From: TJ Saunders
+Date: Sun, 24 Nov 2019 14:03:54 -0800
+Subject: [PATCH] Issue #859, #861: Fix handling of CRL lookups by properly
+ using issuer for lookups, and guarding against null pointers.
+
+---
+ contrib/mod_tls.c | 7 +--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- proftpd-dfsg.orig/contrib/mod_tls.c
proftpd-dfsg/contrib/mod_tls.c
+@@ -8968,10 +8968,10 @@
+
+ #if OPENSSL_VERSION_NUMBER >= 0x1010L && \
+ !defined(HAVE_LIBRESSL)
+- crls = X509_STORE_CTX_get1_crls(store_ctx, subject);
++ crls = X509_STORE_CTX_get1_crls(store_ctx, issuer);
+ #elif OPENSSL_VERSION_NUMBER >= 0x1000L && \
+ !defined(HAVE_LIBRESSL)
+- crls = X509_STORE_get1_crls(store_ctx, subject);
++ crls = X509_STORE_get1_crls(store_ctx, issuer);
+ #else
+ /* Your OpenSSL is before 1.0.0. You really need to upgrade. */
+ crls = NULL;
+@@ -8990,6 +8990,9 @@
+ ASN1_INTEGER *sn;
+
+ revoked = sk_X509_REVOKED_value(X509_CRL_get_REVOKED(crl), j);
++if (revoked == NULL) {
++ continue;
++}
+ #if OPENSSL_VERSION_NUMBER >= 0x1010L && \
+ !defined(HAVE_LIBRESSL)
+ sn = X509_REVOKED_get0_serialNumber(revoked);
Bug#946558: stretch-pu: package clamav/0.102.1+dfsg-0+deb9u1
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: stretch
Severity: normal
This updates clamav to its latest version provided by upstream. The
import part is the fix for CVE-2019-15961.
The attached debdiff has been created via
git diff -w -M -C -D debian-0.101.4+dfsg-0+deb9u1 ':!*.in' ':!configure'
':!docs/'
to filter out as much noise as possible.
Sebastian
diff -Nru clamav-0.101.2+dfsg/clamd/server-th.c clamav-0.101.4+dfsg/clamd/server-th.c
--- clamav-0.101.2+dfsg/clamd/server-th.c 2019-03-13 22:13:01.0 +0100
+++ clamav-0.101.4+dfsg/clamd/server-th.c 2019-08-20 18:08:49.0 +0200
@@ -88,7 +88,7 @@
#ifndef _WIN32
/* ignore all signals */
sigfillset();
-/* The behavior of a process is undefined after it ignores a
+/* The behavior of a process is undefined after it ignores a
* SIGFPE, SIGILL, SIGSEGV, or SIGBUS signal */
sigdelset(, SIGFPE);
sigdelset(, SIGILL);
@@ -552,7 +552,7 @@
/* no more commands are accepted */
conn->mode = MODE_WAITREPLY;
/* Stop monitoring this FD, it will be closed either
- * by us, or by the scanner thread.
+ * by us, or by the scanner thread.
* Never close a file descriptor that is being
* monitored by poll()/select() from another thread,
* because this can lead to subtle bugs such as:
@@ -631,7 +631,7 @@
int rc;
size_t pos = *ppos;
size_t cmdlen;
-
+
logg("$mode == MODE_STREAM\n");
/* we received some data, set readtimeout */
time(>timeout_at);
@@ -754,12 +754,25 @@
memset(, 0, sizeof(struct cl_scan_options));
/* set up limits */
-if((opt = optget(opts, "MaxScanSize"))->active) {
- if((ret = cl_engine_set_num(engine, CL_ENGINE_MAX_SCANSIZE, opt->numarg))) {
- logg("!cl_engine_set_num(CL_ENGINE_MAX_SCANSIZE) failed: %s\n", cl_strerror(ret));
- cl_engine_free(engine);
- return 1;
- }
+if ((opt = optget(opts, "MaxScanTime"))->active) {
+if ((ret = cl_engine_set_num(engine, CL_ENGINE_MAX_SCANTIME, opt->numarg))) {
+logg("!cl_engine_set_num(CL_ENGINE_MAX_SCANTIME) failed: %s\n", cl_strerror(ret));
+cl_engine_free(engine);
+return 1;
+}
+}
+val = cl_engine_get_num(engine, CL_ENGINE_MAX_SCANTIME, NULL);
+if (val)
+logg("Limits: Global time limit set to %llu milliseconds.\n", val);
+else
+logg("^Limits: Global time limit protection disabled.\n");
+
+if ((opt = optget(opts, "MaxScanSize"))->active) {
+if ((ret = cl_engine_set_num(engine, CL_ENGINE_MAX_SCANSIZE, opt->numarg))) {
+logg("!cl_engine_set_num(CL_ENGINE_MAX_SCANSIZE) failed: %s\n", cl_strerror(ret));
+cl_engine_free(engine);
+return 1;
+}
}
val = cl_engine_get_num(engine, CL_ENGINE_MAX_SCANSIZE, NULL);
if(val)
@@ -1016,7 +1029,7 @@
/* TODO: Remove deprecated option in a future feature release */
if (optget(opts, "ScanPE")->enabled || optget(opts, "ScanELF")->enabled) {
-if ((optget(opts, "DetectBrokenExecutables")->enabled) ||
+if ((optget(opts, "DetectBrokenExecutables")->enabled) ||
(optget(opts, "AlertBrokenExecutables")->enabled)) {
logg("Alerting on broken executables enabled.\n");
options.heuristic |= CL_SCAN_HEURISTIC_BROKEN;
@@ -1039,7 +1052,7 @@
if (optget(opts, "ScanOLE2")->enabled) {
logg("OLE2 support enabled.\n");
options.parse |= CL_SCAN_PARSE_OLE2;
-
+
/* TODO: Remove deprecated option in a future feature release */
if ((optget(opts, "OLE2BlockMacros")->enabled) ||
(optget(opts, "AlertOLE2Macros")->enabled)) {
@@ -1187,7 +1200,7 @@
int solaris_has_extended_stdio = 0;
#endif
/* Condition to not run out of file descriptors:
- * MaxThreads * MaxRecursion + (MaxQueue - MaxThreads) + CLAMDFILES < RLIMIT_NOFILE
+ * MaxThreads * MaxRecursion + (MaxQueue - MaxThreads) + CLAMDFILES < RLIMIT_NOFILE
* CLAMDFILES is 6: 3 standard FD + logfile + 2 FD for reloading the DB
* */
#ifdef C_SOLARIS
@@ -1314,12 +1327,12 @@
sigdelset(, SIGHUP);
sigdelset(, SIGPIPE);
sigdelset(, SIGUSR2);
-/* The behavior of a process is undefined after it ignores a
+/* The behavior of a process is undefined after it ignores a
* SIGFPE, SIGILL, SIGSEGV, or SIGBUS signal */
sigdelset(, SIGFPE);
sigdelset(, SIGILL);
sigdelset(, SIGSEGV);
-#ifdef SIGBUS
+#ifdef SIGBUS
sigdelset(, SIGBUS);
#endif
sigdelset(, SIGTSTP);
@@ -1663,4 +1676,4 @@
logg("--- Stopped at %s", cli_ctime(_time, timestr, sizeof(timestr)));
return ret;
-}
+}
diff -Nru clamav-0.101.2+dfsg/clamscan/clamscan.c clamav-0.101.4+dfsg/clamscan/clamscan.c
--- clamav-0.101.2+dfsg/clamscan/clamscan.c 2019-03-13 22:13:01.0 +0100
+++ clamav-0.101.4+dfsg/clamscan/clamscan.c 2019-08-20 18:08:49.0 +0200
@@ -145,7 +145,7 @@
optfree(opts);
return 2;
Bug#946556: bumblebee-nvidia: why not depending also on nvidia-tesla-driver?
Package: bumblebee-nvidia Version: also depends on nvidia-tesla-driver? Severity: normal Dear Maintainer, This is mainly to avoid having other nvidia driver pulled when installing this package. Thanks, Patrice -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.3.0-3-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages bumblebee-nvidia depends on: ii bumblebee 3.2.1-20 ii glx-alternative-nvidia 1.1.0 pn nvidia-driver | nvidia-legacy-390xx-driver | nvidia-legacy-340xx- bumblebee-nvidia recommends no packages. bumblebee-nvidia suggests no packages.
Bug#946555: lsof: Incomplete/misleading output regarding non-POSIX file locks
Package: lsof
Version: 4.91+dfsg-1
Severity: normal
Dear Maintainer,
The output of lsof is misleading when it comes to "flock" and "OFD"
file locks on Linux.
Background: there are three types of advisory file locks in Linux:
- "flock" or "BSD" locks, which are created by the flock system call.
These are associated with a particular *open file description*, so
they are inherited by child processes.
- "fcntl" or "POSIX" locks, which are created by the fcntl system call
with the F_SETLK or F_SETLKW option. These are associated with a
particular *process ID*, so they are not inherited by child
processes.
- "OFD" locks, which are created by the fcntl system call with the
F_OFD_SETLK or F_OFD_SETLKW option. These are like flock locks in
that they are associated with an open file description, but they are
like fcntl locks in that they apply to a particular range of bytes.
The kernel reports all of these locks via /proc/locks, and lsof parses
that file and tries to indicate which processes are currently holding
locks on which files.
However, the information in /proc/locks is incomplete and in some
cases inaccurate: for flock and OFD locks, it tells you that *some
process* is holding a lock on the file, but it doesn't tell you which
one(s), since the lock may have been inherited across a fork. The
proc(5) manpage states:
Because OFD locks are not owned by a single process (since
multiple processes may have file descriptors that refer to the
same open file description), the value -1 is displayed in [the
process ID field] for OFD locks. (Before kernel 4.14, a bug meant
that the PID of the process that initially acquired the lock was
displayed instead of the value -1.)
The manpage doesn't mention that exactly the same "bug" also applies
to flock locks.
As far as I can see, this does appear to be a limitation of the
kernel: I don't know of any way that lsof could possibly figure out
which processes, or which file descriptors, are associated with a
particular lock.
So although I believe this is a bug in lsof, I don't think it is one
that lsof can fix by itself.
Nonetheless, it's a limitation that probably should be better
documented, and perhaps lsof's output could be improved to reflect
this uncertainty - for example, it could display a '?' in the lock
column to indicate "*some* process has a lock on this file; this
particular process might or might not."
Here is an example program:
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
int main()
{
int fd1, fd2, fd3, fd4, status;
pid_t child;
struct flock fl = { 0 };
char cmd[100];
fd1 = open("/tmp/file1", O_RDWR | O_CREAT, 0600);
fd2 = open("/tmp/file1", O_RDWR | O_CREAT, 0600);
fd3 = open("/tmp/file2", O_RDWR | O_CREAT, 0600);
fd4 = open("/tmp/file2", O_RDWR | O_CREAT, 0600);
if (fd1 < 0 || fd2 < 0 || fd3 < 0 || fd4 < 0)
err(1, "open");
if (flock(fd1, LOCK_SH))
err(1, "flock");
fl.l_type = F_WRLCK;
if (fcntl(fd3, F_OFD_SETLKW, ))
err(1, "fcntl");
child = fork();
if (child < 0)
err(1, "fork");
else if (child == 0) {
snprintf(cmd, sizeof(cmd), "lsof -p %d,%d -a -d 3-99",
getppid(), getpid());
system(cmd);
}
else {
wait();
}
return 0;
}
Running this program produces:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
a.out 5615 benjamin3uR REG 0,440 517883 /tmp/file1
a.out 5615 benjamin4uR REG 0,440 517883 /tmp/file1
a.out 5615 benjamin5u REG 0,440 517884 /tmp/file2
a.out 5615 benjamin6u REG 0,440 517884 /tmp/file2
a.out 5616 benjamin3u REG 0,440 517883 /tmp/file1
a.out 5616 benjamin4u REG 0,440 517883 /tmp/file1
a.out 5616 benjamin5u REG 0,440 517884 /tmp/file2
a.out 5616 benjamin6u REG 0,440 517884 /tmp/file2
The flock lock is indicated (with an "R") for the parent process, but
not for the child process; the OFD lock is not indicated at all. (If
you run the same program on an older kernel, it will show a "W" in the
fourth and fifth lines.)
To be *really* precise, file descriptors 3 and 5 are the ones holding
the locks; those FDs should have an "R" or "W" next to them while 4
and 6 shouldn't.
-- System Information:
Debian Release: 10.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-6-amd64 (SMP w/40 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages lsof depends on:
ii libc62.28-10
ii libselinux1 2.8-1+b1
lsof recommends no packages.
Bug#946554: [Tts-project] Bug#946554: speech-dispatcher: please omit speech-dispatcher-festival on Ubuntu/i386
Hello, Steve Langasek, le mar. 10 déc. 2019 12:42:05 -0800, a ecrit: > In Ubuntu, we are in the process of moving the i386 architecture to a > compatibility-only layer on amd64. We are keeping speech-dispatcher on i386 > because speech-dispatcher-ibmtts is only available on this arch, but > speech-dispatcher-festival is built from this source package I don't understand: the speech-dispatcher-ibmtts binary package is built from the speech-dispatcher-contrib source package, not from the speech-dispatcher source package. Samuel
Bug#925824: sgt-puzzles: ftbfs with GCC-9
The upstream maintainer, Simon Thatam, noticed this build problem and brought a fix in this commit: https://git.tartarus.org/?p=simon/puzzles.git;a=commit;h=907c42bcf0f06826279d5be91be7f7f9c45876d9 Note that it fuzzes with the current 20170606.272beef-1 version of the package, so I took the liberty to test out the patch here below. But I suspect that a better approach would be to upgrade to the latest version of the Portable Puzzle Collection. This is yet to be tested on 263-bit int platform. ;) _ fix-ftbfs-with-gcc-9.patch: --- a/twiddle.c 2019-12-10 21:28:42.488548074 +0100 +++ b/twiddle.c 2019-12-10 21:29:49.945015261 +0100 @@ -556,6 +556,12 @@ char *ret, *p, buf[80]; int i, x, y, col, o, maxlen; +/* Pedantic check: ensure buf is large enough to format an int in + * decimal, using the bound log10(2) < 1/3. (Obviously in practice + * int is not going to be larger than even 32 bits any time soon, + * but.) */ +assert(sizeof(buf) >= 1 + sizeof(int) * CHAR_BIT/3); + /* * First work out how many characters we need to display each * number. We're pretty flexible on grid contents here, so we @@ -568,6 +574,11 @@ } o = (state->orientable ? 1 : 0); +/* Reassure sprintf-checking compilers like gcc that the field + * width we've just computed is not now excessive */ +if (col >= sizeof(buf)) +col = sizeof(buf)-1; + /* * Now we know the exact total size of the grid we're going to * produce: it's got h rows, each containing w lots of col+o, signature.asc Description: OpenPGP digital signature
Bug#922014: reportbug: number of bugs equals the list of whshlist bugs
control: tags -1 patch On 11 Feb 2019 "J. Schreck" wrote: > The number of bugs refers to the wishlist bugs if all bugs are shown at > once (output line of another bug reporting of mine): > (13-17/17) Is the bug you found listed above [y|N|b|m|r|q|s|f|e|?]? n Thanks for noticing such a small detail. :) Fix: https://salsa.debian.org/reportbug-team/reportbug/merge_requests/43
Bug#946554: speech-dispatcher: please omit speech-dispatcher-festival on Ubuntu/i386
Package: speech-dispatcher
Version: 0.9.1-3
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch
Dear maintainers,
In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64. We are keeping speech-dispatcher on i386
because speech-dispatcher-ibmtts is only available on this arch, but
speech-dispatcher-festival is built from this source package and depends on
festival which we otherwise have no reason to keep around.
We would like to drop the speech-dispatcher-festival binary package rather
than keeping it around in the Ubuntu archive and uninstallable. Would you
please consider applying the attached patch, or something like it, to omit
building this binary package on Ubuntu?
Thanks for considering,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru speech-dispatcher-0.9.1/debian/rules
speech-dispatcher-0.9.1/debian/rules
--- speech-dispatcher-0.9.1/debian/rules2019-11-28 18:08:46.0
-0800
+++ speech-dispatcher-0.9.1/debian/rules2019-12-10 12:03:15.0
-0800
@@ -6,6 +6,9 @@
# NAS is in universe in Ubuntu
ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes)
NAS = --with-nas=no
+ifeq (${DEB_HOST_ARCH},i386)
+ builddeb_overrides = -Nspeech-dispatcher-festival
+endif
endif
%:
@@ -37,6 +40,12 @@
dh_makeshlibs -plibspeechd2
endif
+override_dh_builddeb:
+ dh_builddeb ${builddeb_overrides}
+
+override_dh_gencontrol:
+ dh_gencontrol ${builddeb_overrides}
+
override_dh_systemd_enable:
dh_systemd_enable --no-enable
Bug#930572: vala-panel-appmenu-common: Global Menu doesn't work for GTK applications
Hi, I had the same problem on XFCE in Debian testing. I did some searching of the original repo's README and discovered there are a few settings that have to be flipped in XFCE on Debian. Based on similar settings existing for MATE, I'd assume the same is true there, and, finally, also for Budgie (but that's not an official Debian DE so I'm not worrying about it). For XFCE: xfconf-query -c xsettings -p /Gtk/ShellShowsMenubar -n -t bool -s true xfconf-query -c xsettings -p /Gtk/ShellShowsAppmenu -n -t bool -s true For MATE: gsettings set org.mate.interface gtk-shell-shows-app-menu true gsettings set org.mate.interface gtk-shell-shows-menubar true The original information and README are [here](https://gitlab.com/vala-panel-project/vala-panel-appmenu/blob/master/README.md). The information about `appmenu-gtk-module' seems not to be relevant to Debian as the changes it makes seem to be in the install scripts already. I have fixed the problem on XFCE by adding a file in the `/debian' direction called `xfce4-appmenu-plugin.sh' with the above commands. I also made one for MATE (`debian/mate-applet-appmenu.sh') that presumably works, but I am not sure since I'm running XFCE. I can't find information on exactly how to submit the actual source changes, so I'm hoping this is the correct way to report fixes. If not, let me know and I'll happily do things properly. Regards, JTS
Bug#942214: thunar/nautilus crash navigate directory "cifs mounted" containing opened libreoffice writer file
Hello David, I fear that output is not sufficient for that type of application. Maybe you could install following packages: thunar-dbgsym gdb libglib2.0-0-dbgsym libgtk-3-0-dbgsym For this you would need to add a matching package archive like described in this link: https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols And then running following command (all in one line) and trigger the crash again. This should generate a a file thunar-gdb_*.txt that could be forwarded to this bug. script -a "thunar-gdb_$(date +%Y-%m-%d_%H-%M-%S).txt" -c "thunar -q; gdb -q -ex 'set width 0' -ex 'set pagination off' -ex 'set backtrace past-main' -ex 'run' -ex 'backtrace no-filter' -ex 'print range_start' -ex 'print range_length' -ex 'print data_length' -ex 'print data_offset' -ex 'print mask_offset' -ex 'print i' -ex 'print j' -ex 'print/x cache' -ex 'print/x cache->buffer' -ex 'print/x data' -ex 'print/x offset' -ex 'print/x len' -ex 'info share' -ex 'info reg' -ex 'thread apply all bt full' -ex 'detach' -ex 'quit' --args thunar" Kind regards, Bernhard
Bug#889925: valac is unusable for cross-compilation
Control: tags -1 + pending
On Tue, Oct 01, 2019 at 08:47:07PM +0200, Helmut Grohne wrote:
> On Thu, Jul 04, 2019 at 12:44:59AM +0200, Helmut Grohne wrote:
> > Let me try to summarize consensus:
> >
> > * There should be an implementation-detail package called valac-bin.
> > * valac-bin should be Multi-Arch: foreign.
> > * valac-bin should contain the (versioned) valac executable
> > * valac should depend on valac-bin.
> > * valac should ship a /usr/bin/${DEB_HOST_GNU_TYPE}-valac wrapper
> >script.
>
> Lacking further input, I've now implemented the consensus in a minimal
> way.
>
> I am introducing another package libvalacodegen-0.46. It contains
> libvalacodegen.so, because both /usr/bin/valac and /usr/bin/vapigen link
> it. For the latter, we're not yet sure whether it should be M-A:foreign
> and the question does not currently seem relevant. Still that means that
> libvalacodegen.so can reside in neither valac nor valac-bin. I'm adding
> another M-A:same package for it.
>
> Apart from that I am closely sticking to the consensus. In particular,
> everything that used to work with the old valac package continues to
> work, because it depends on all packages that received files from it.
>
> Do you see any issus with this approach?
I've slightly updated the previous .debdiff and uploaded it to
delayed/10. It'll target experimental first to clear NEW. I'll upload to
unstable afterwards. Please tell if I should delay it any longer. I'm
attaching the updated .debdiff.
Helmut
diff --minimal -Nru vala-0.46.5/debian/changelog vala-0.46.5/debian/changelog
--- vala-0.46.5/debian/changelog2019-11-19 10:42:51.0 +0100
+++ vala-0.46.5/debian/changelog2019-12-10 16:34:29.0 +0100
@@ -1,3 +1,11 @@
+vala (0.46.5-1.1) experimental; urgency=medium
+
+ * Non-maintainer upload.
+ * Move valac to a M-A:foreign package and add cross wrappers. (Closes:
+#889925)
+
+ -- Helmut Grohne Tue, 10 Dec 2019 16:34:29 +0100
+
vala (0.46.5-1) unstable; urgency=medium
* New upstream release
diff --minimal -Nru vala-0.46.5/debian/control vala-0.46.5/debian/control
--- vala-0.46.5/debian/control 2019-11-19 10:42:51.0 +0100
+++ vala-0.46.5/debian/control 2019-12-10 16:34:29.0 +0100
@@ -24,12 +24,53 @@
Vcs-Browser: https://salsa.debian.org/gnome-team/vala
Homepage: https://wiki.gnome.org/Projects/Vala/
+Package: libvalacodegen-0.46-0
+Architecture: any
+Multi-Arch: same
+Depends: ${shlibs:Depends},
+ ${misc:Depends},
+Conflicts: valac-0.12, valac-0.14, valac-0.16, valac-0.18, valac-0.20,
+ valac-0.22, valac-0.24, valac-0.26, valac-0.28, valac-0.30
+Breaks: valac (<< 0.46.5-1.1~)
+Replaces: valac (<< 0.46.5-1.1~)
+Description: internal package for C# like language for the GObject system
+ Vala is a new programming language that aims to bring modern programming
+ language features to GNOME developers without imposing any additional
+ runtime requirements and without using a different ABI compared to
+ applications and libraries written in C.
+ .
+ This package contains the libvalacodegen shared library. It should not
normally
+ be used directly.
+
+Package: valac-bin
+Architecture: any
+Multi-Arch: foreign
+Depends: ${shlibs:Depends},
+ libvala-0.46-0 (= ${binary:Version}),
+ libvalacodegen-0.46-0 (= ${binary:Version}),
+ ${misc:Depends},
+Conflicts: valac-0.12, valac-0.14, valac-0.16, valac-0.18, valac-0.20,
+ valac-0.22, valac-0.24, valac-0.26, valac-0.28, valac-0.30
+Breaks: valac (<< 0.46.5-1.1~)
+Replaces: valac (<< 0.46.5-1.1~)
+Description: internal package for C# like language for the GObject system
+ Vala is a new programming language that aims to bring modern programming
+ language features to GNOME developers without imposing any additional
+ runtime requirements and without using a different ABI compared to
+ applications and libraries written in C.
+ .
+ This particular package is an implementation detail of the vala packaging.
+ It should not be installed directly and there should be no dependencies
+ on it. Refer to the valac package instead.
+
Package: valac
Architecture: any
Depends: ${shlibs:Depends},
libvala-0.46-0 (= ${binary:Version}),
+ libvalacodegen-0.46-0 (= ${binary:Version}),
libglib2.0-dev (>= 2.48),
valac-0.46-vapi,
+ valac-bin (= ${binary:Version}),
${misc:Depends}
Recommends: gcc
Conflicts: valac-0.12, valac-0.14, valac-0.16, valac-0.18, valac-0.20,
@@ -118,6 +159,7 @@
Architecture: any
Depends: ${shlibs:Depends},
libvaladoc-0.46-0 (= ${binary:Version}),
+ libvalacodegen-0.46-0 (= ${binary:Version}),
valac (= ${binary:Version}),
${misc:Depends}
Multi-Arch: foreign
@@ -132,6 +174,7 @@
Multi-Arch: same
Depends: ${shlibs:Depends},
libvala-0.46-0 (= ${binary:Version}),
+ libvalacodegen-0.46-0 (= ${binary:Version}),
${misc:Depends},
Bug#946497: zfs-dkms: fails to build module for 5.3.0-3-amd64
Control: severity -1 important Control: retitle -1 zfs-dkms: module wants to build with gcc instead of kernel's compiler There is also #945506 with a similar problem in openafs-modules-dkms Andreas
Bug#485526: kio_audiocd / kscd : refreshing media/storage view stops audio cd playing – Still reproducible, reassigning to kscd
control: reassign -1 kscd control: found -1 4:17.08.3-1 Hi there, unfortunately this bug was never fixed and I can still be reproduce it on current Debian 10 (buster) stable more than 10 years later. How about stability. :-) I’m reassigning to kscd since it only manifests with it an other media players like dragon player or VLC work fine. As for the fix itself, I’m not sure it’s ever going to happen since upstream development of kscd has pretty much stopped and it has been removed from current testing (bullseye). So I guess I’ll leave the bug open until buster becomes unsupported. Happy hacking ! -- Aurélien
Bug#945506: openafs-modules-dkms: module FTBFS for Linux 5.3.0-2-amd64
Control: severity -1 important Control: retitle -1 openafs-modules-dkms: module wants to build with gcc instead of kernel's compiler On 10/12/2019 21.14, Benjamin Kaduk wrote: > would you mind if I dropped the severity of this bug to prevent > autoremoval from testing while that work proceeds? not at all Andreas
Bug#946553: prospector: please, tighten the dependency of prospector on pylint
Package: prospector
Version: 1.1.7-1
Severity: normal
X-Debbugs-CC: locutusofb...@debian.org, czc...@debian.org
First of all, thank you very, very much for uploading a new version of
prospector to Debian. It is really appreciated.
Since prospector was not migrated to testing, when it was uploaded,
apt/aptitude just went ahead and offered to upgrade to the version on
unstable.
Since I am tracking testing, the packages that I have are not-so-fresh and,
in particular, when I run prospector, I get a message telling me that pylint
is too old:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
$ prospector
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 583, in
_build_master
ws.require(__requires__)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 900, in
require
needed = self.resolve(parse_requirements(requirements))
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 791, in
resolve
raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (pylint 2.2.2
(/usr/lib/python3/dist-packages), Requirement.parse('pylint>=2.3.1'),
{'prospector'})
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/bin/prospector", line 6, in
from pkg_resources import load_entry_point
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3250,
in
@_call_aside
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3234,
in _call_aside
f(*args, **kwargs)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3263,
in _initialize_master_working_set
working_set = WorkingSet._build_master()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 585, in
_build_master
return cls._build_from_requirements(__requires__)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 598, in
_build_from_requirements
dists = ws.resolve(reqs, Environment())
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 786, in
resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'pylint>=2.3.1' distribution was not
found and is required by prospector
$
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
It would be very nice if the dependencies were tightened a bit...
Thanks,
Rogério Brito.
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing'), (200, 'unstable'), (150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.utf-8, LC_CTYPE=pt_BR.utf-8 (charmap=UTF-8),
LANGUAGE=en_US.utf-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages prospector depends on:
ii dodgy 0.1.9-3
ii libjs-sphinxdoc1.8.5-4
ii pylint 2.2.2-4
ii python33.7.5-1
ii python3-astroid2.3.3-1
ii python3-mccabe 0.6.1-2
ii python3-mypy 0.750-1
ii python3-pep8-naming0.4.1-4
ii python3-pycodestyle2.5.0-1
ii python3-pydocstyle 2.1.1-1
ii python3-pyflakes 2.1.1-1
ii python3-pylint-celery 0.3-4
ii python3-pylint-django 2.0.11-1
ii python3-pylint-flask 0.5-3
ii python3-pylint-plugin-utils0.6-1
ii python3-pyroma 2.3.1-1
ii python3-requirements-detector 0.6-2
ii python3-setoptconf 0.2.0-3
ii python3-typed-ast 1.4.0-1+b1
ii python3-yaml 5.1.2-1+b1
Versions of packages prospector recommends:
ii vulture 0.21-1.1
prospector suggests no packages.
-- no debconf information
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Bug#944603: Attempt to print checks crashes gnucash
To me, this looks likes this upstream bug: https://bugs.gnucash.org/show_bug.cgi?id=797011 It has been fixed in 3.5 -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ signature.asc Description: OpenPGP digital signature
Bug#792397: Retesting dolphin : network explorer
Hi Marc, would you be able to retest this ? It seems to me that Dolphin in current stable (Debian 10/buster) works fine in that regard. The « Network » link in the left panel bring to a network summary view with groups for all kind of network elements like SMB and others, and a link to add a new network folder. If you could confirm I could close this bug. Happy hacking ! -- Aurélien
Bug#946137: nvidia-legacy-340xx-driver: Fails to build with kernel 5.4
Hi Andreas, >From my memory I got also a problem with nvidia-tesla-kernel-dkms to build with kernel 5.4 Thanks, Patrice
Bug#943681: keepassxc: Resizing KeepassXC on KDE on intel video driver crashes Plasma
Control: reassign -1 linux On Sun, Oct 27, 2019 at 07:48:25PM -0300, Ivan wrote: > Package: keepassxc > Version: 2.3.4+dfsg.1-1 > Severity: normal > > Dear Maintainer, > >* What led up to the situation? > Executing KeepassXC, opening the database. >* What exactly did you do (or not do) that was effective (or > ineffective)? > Open database and try to resize the window on KDE. >* What was the outcome of this action? > KDE Plasma completely frozen, only mouse moving. Need to restart SDDM to > get it back. >* What outcome did you expect instead? > Resize window. > > [27436.083291] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update > failure on pipe B (start=51173 end=51174) time 175 us, min 1431, max 1439, > scanline start 1430, end 1446 > [28814.602509] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update > failure on pipe B (start=133816 end=133817) time 148 us, min 1431, max 1439, > scanline start 1428, end 1441 >8.188923] DMAR: DRHD: handling fault status reg 2 > [8.188932] DMAR: [DMA Write] Request device [02:00.0] fault addr 0 [fault > reason 05] PTE Write access is not set Well, that does not sound like a keepassxc bug. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#485526: (no subject)
control: tags -1 - fixed-upstream control: notforwarded -1 Removing references to upstream and kio-audiocd since I get the bug without kio-audiocd installed, and I don’t get the error message mentioned in the upstream bug. Besides the bug has been abandoned upstream, not fixed.
Bug#908921: ITP: v2ray -- A platform for building proxies to bypass network restrictions.
owner 908921 ! retitle 908921 ITP: v2ray -- A platform for building proxies to bypass network restrictions. thanks Hi all, I think I'll need this package anyway so I'll package it. Yours, Paul signature.asc Description: OpenPGP digital signature
Bug#944920: Revise terminology used to specify requirements
Dear Policy Editors, On 21-11-2019 13:59, Paul Gevers wrote: > [Disclaimer: the words below are as a member of the release team, but > not necessarily those of the team. We haven't discussed this yet.] We have had a discussion, and there were no objections against my vision below. > I can envision that if Policy carries such a summary list, our policy > would mention the version of Policy it was based on, to make sure that > Policy doesn't suddenly change what we as the RT agreed on. So, yes, we would welcome the Policy to maintain a summary list that we could reference. We already acknowledge that there will be items in the Policy text that we balance differently for RC-ness, so there will be exceptions maintained by us. Paul signature.asc Description: OpenPGP digital signature
Bug#946552: graphdefang: mimedefang.pl regex filter assumes sendmail, does not work with, for example, postfix
Package: graphdefang
Version: 2.84-3+b2
Severity: normal
Tags: newcomer patch
Dear Maintainer,
I use mimedefang to filter mail for postfix as my MTS, and the packaged event
filter in
/usr/share/graphdefang/event/mimedefang.pl/general assumes that the system MTS
is sendmail.
Sendmail uses 14-character mail ID strings and postfix uses 9-character ID
strings.
Attached is a patch that changes the mimedefang.pl/general file to accept both
sendmail
and postfix strings logged by mimedefang.pl
I don't know what other MTS/mimedefang combinations exist so
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages graphdefang depends on:
ii libfile-readbackwards-perl 1.05-2
ii libgd-graph-perl1.54~ds-2
ii libgd-text-perl 0.86-9
ii libmldbm-perl 2.05-2
ii libtimedate-perl2.3000-2
ii perl [libstorable-perl] 5.30.0-9
Versions of packages graphdefang recommends:
ii php 2:7.3+69
ii php7.0 [php] 7.0.31-1
ii php7.2 [php] 7.2.11-3
ii php7.3 [php] 7.3.12-1
Versions of packages graphdefang suggests:
ii mimedefang 2.84-3+b2
-- Configuration Files:
/etc/graphdefang/graphdefang-config changed [not included]
-- no debconf information
*** general.dpkg-dist 2019-12-10 13:07:53.707823878 -0600
--- general 2019-12-10 13:23:07.296896371 -0600
***
*** 10,16
$event{'mimedefang.pl'}{'general'} =
sub {
! if ($text =~
m/^[A-Za-z0-9]{14}:\s*MDLOG,\S+?,(\S+?),(\S*?),(\S*?),(.*?),(.*?),(.*)$/ ) {
# get values from regular expression
--- 10,16
$event{'mimedefang.pl'}{'general'} =
sub {
! if ($text =~
m/(?:^[A-Za-z0-9]{9}|^[A-Za-z0-9]{14}):\s*MDLOG,\S+?,(\S+?),(\S*?),(\S*?),(.*?),(.*?),(.*)$/
) {
# get values from regular expression
Bug#882467: node-typescript-types: should provide virtual packages for each /type package, versioned
Hi, I posted a PR [1] to auto provide virtual packages using pkg-js-tools. Cheers, Xavier [1]: https://salsa.debian.org/js-team/typescript-types/merge_requests/1
Bug#945944: stretch-pu: package ros-ros-comm/1.12.6-2
On Tue, 2019-12-10 at 21:07 +0100, Jochen Sprickerhof wrote: > * Adam D. Barratt [2019-12-10 18:35]: > > On Sun, 2019-12-01 at 14:08 +0100, Jochen Sprickerhof wrote: > > > This is the same as #945896, just for stretch. I adopted the > > > values > > > as reportbug doesn't seem to support stretch-pu. Hope I did it > > > right. > > > > Really? Which version? > > 7.5.3 from unstable, which is affected by #938941, which is only > fixed in stable.. *sigh* I should probably have triple-checked, but the implication from #935988 was that the outstanding fixes were being NMUed to unstable. Thanks for the pointer. Regards, Adam
Bug#945506: openafs-modules-dkms: module FTBFS for Linux 5.3.0-2-amd64
On Tue, Dec 10, 2019 at 01:19:11PM +0100, Andreas Beckmann wrote: > Please check my reply on #946497 which is about the same problem in > zfs-dkms. Perhaps both of you find a solution that will work for the two > packages. Thanks for the pointer. I think that having dkms set CC/etc. appropriately is probably the architecturally cleanest solution (as dkms actually knows what kernel is being built for), and am willing to try to dig into how that might happen, time permitting. That said, I have pretty severe time demands these days so can only get a couple days of solid development time per month (split among several projects); would you mind if I dropped the severity of this bug to prevent autoremoval from testing while that work proceeds? Thanks, Ben
Bug#945944: stretch-pu: package ros-ros-comm/1.12.6-2
* Adam D. Barratt [2019-12-10 18:35]: On Sun, 2019-12-01 at 14:08 +0100, Jochen Sprickerhof wrote: The ros-ros-comm version in stretch is affected affected by CVE-2019-13566 which was flagged no-dsa by the security team. I propose the attached patch to fix the issue. Would you be fine with me uploading it? Please go ahead. Done. This is the same as #945896, just for stretch. I adopted the values as reportbug doesn't seem to support stretch-pu. Hope I did it right. Really? Which version? 7.5.3 from unstable, which is affected by #938941, which is only fixed in stable.. Cheers Jochen signature.asc Description: PGP signature
Bug#946551: Enable TI PHY for 5.x kernels
Package: linux Version: 5.3.9-3 Severity: normal The armmp Linux configuration had CONFIG_TI_CPSW_PHY_SEL enabled to be built in the kernel up to including the buster kernel version. As this config was deprecated with 5.1, it was removed from Debian's configuration. With the 5.x versions comes the successor CONFIG_PHY_TI_GMII_SEL enabled as a module. This just hit me updating a BeagleBone Black (that does not load any modules) from buster to testing. I have created a merge request with CONFIG_PHY_TI_GMII_SEL=y for armmp: https://salsa.debian.org/kernel-team/linux/merge_requests/194
Bug#946368: DeprecationWarning for using collections instead of collections.abc
On 12/9/19 11:24 AM, Toni Mueller wrote: > > Hi Thomas, > > On Mon, Dec 09, 2019 at 10:58:49AM +0100, Thomas Goirand wrote: >> There's no need to backport it, as it's already included in >> python-jsonschema 3.0.2 which was uploaded to Sid. > > I know - I think this would be appropriate to backport to stable. > > Thanks, > Toni Toni, Do you feel like doing the work yourself for this? I have too many things to watch for stable updates... Thomas
Bug#946550: graphdefang: no longer works with PHP 7.0.0 due to ereg() function removal
Package: graphdefang
Version: 2.84-3+b2
Severity: important
Tags: patch newcomer
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?
*** End of the template - remove these template lines ***
I realized that my graphdefang output hasn't worked in ages so I decided to
track down the reason(s)
why.
After checking web server logs I realized it was because PHP 7.x removed ereg()
function and
therefore its usage needed to be replaced with preg_match() so I replaced the
ereg() call with a
preg_match() call, putting / and / around the pattern string. Maybe strpos is
more appropriate
but this was the quick fix.
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages graphdefang depends on:
ii libfile-readbackwards-perl 1.05-2
ii libgd-graph-perl1.54~ds-2
ii libgd-text-perl 0.86-9
ii libmldbm-perl 2.05-2
ii libtimedate-perl2.3000-2
ii perl [libstorable-perl] 5.30.0-9
Versions of packages graphdefang recommends:
ii php 2:7.3+69
ii php7.0 [php] 7.0.31-1
ii php7.2 [php] 7.2.11-3
ii php7.3 [php] 7.3.12-1
Versions of packages graphdefang suggests:
ii mimedefang 2.84-3+b2
-- Configuration Files:
/etc/graphdefang/graphdefang-config changed:
$DATAFILE = '/var/log/mail.log';
$OUTPUT_DIR = '/var/lib/graphdefang';
my %GraphSettings;
%GraphSettings = ();
%GraphSettings = (
'data_types'=> ['spam', 'probable_spam', 'virus', 'mail_in'],
'graph_type'=> 'line',
'grouping' => 'summary',
'grouping_times'=> ['hourly','daily','monthly'],
);
push @GRAPHS, { %GraphSettings };
%GraphSettings = ();
%GraphSettings = (
'data_types'=> ['virus'],
'graph_type'=> 'stacked_bar',
'grouping' => 'value1',
'value1_title' => 'VirusName',
'grouping_times'=> ['hourly','daily','monthly'],
#'filter' => '^(?:(?!klez).)*$',
#'filter_name' => 'Not Klez',
);
push @GRAPHS, { %GraphSettings };
%GraphSettings = ();
%GraphSettings = (
'data_types'=> ['spam', 'virus'],
'graph_type'=> 'stacked_bar',
'grouping' => 'recipient',
'top_n' => '9',
'grouping_times'=> ['hourly','daily','monthly'],
);
push @GRAPHS, { %GraphSettings };
%GraphSettings = ();
%GraphSettings = (
'data_types'=> ['spam'],
'graph_type'=> 'stacked_bar',
'grouping' => 'value2',
'value2_title' => 'Relay Address',
'top_n' => '9',
'grouping_times'=> ['hourly','daily','monthly'],
'filter'=> '^(?:(?!127.0.0.1).)*$',
'filter_name' => 'localhost',
);
push @GRAPHS, { %GraphSettings };
%GraphSettings = ();
%GraphSettings = (
'data_types'=> ['virus'],
'graph_type'=> 'stacked_bar',
'grouping' => 'value2',
'value2_title' => 'Relay Address',
'top_n' => '9',
'grouping_times'=> ['hourly','daily','monthly'],
'filter'=> '^(?:(?!127.0.0.1).)*$',
'filter_name' => 'localhost',
);
push @GRAPHS, { %GraphSettings };
-- no debconf information
*** index.php.dpkg-dist 2019-12-10 13:30:49.517395992 -0600
--- index.php 2019-12-10 11:13:50.179334072 -0600
***
*** 65,71
foreach($filename_array as $value) {
! if (ereg($view,$value)) {
$subvalue=explode($view,$value);
#print "$subvalue[1]";
print "";
--- 65,72
foreach($filename_array as $value) {
! $view_pattern = '/' . $view . '/';
! if (preg_match($view_pattern,$value)) {
$subvalue=explode($view,$value);
#print "$subvalue[1]";
print "";
Bug#943608: tests segfault when run with Python 3.8
Hello, On Tue, 26 Nov 2019 13:06:24 +0100 "Dr. Tobias Quathamer" wrote:> I've forwarded this bug upstream, and further investigation by them > seems to indicate that this is actually a bug in CPython. > > I'm therefore cloning and reassigning this bug, feel free to > revert this if you don't agree. A while ago I opened a merge request with upstream with a workaround that fixes the segfault with CPython 3.8. As it seems that CPython 3.8.1 will be released with the bug not fixed, it may be worth to apply the patch to the Debian package. https://bitbucket.org/blais/beancount/pull-requests/139 All the patch does is to make the C code Python 3.9 ready, avoiding raising a warning, which ultimately results in the segfault. The patch seems very low risk to me. Cheers, Dan
Bug#945427: thanks !
Hi and thanks. I have incorporated your fix as follows: https://salsa.debian.org/debian/doxygen/commit/e4a00bde1d8b864d4588554c5c21ae43b4519dee I plan to release to unstable shortly. Paolo
Bug#946549: RFS: smplayer/1.0-2 [RC] -- Complete front-end for MPlayer and mpv
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "smplayer" * Package name: smplayer Version : 19.10.2~ds0-1 Upstream Author : Ricardo Villalba * URL : http://smplayer.sourceforge.net/ * License : GPL-2+ * Vcs : https://salsa.debian.org/multimedia-team/smplayer Section : video It builds those binary packages: smplayer - Complete front-end for MPlayer and mpv smplayer-l10n - Complete front-end for MPlayer and mpv - translation files To access further information about this package, please visit the following URL: https://mentors.debian.net/package/smplayer Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/smplayer/smplayer_19.10.2~ds0-1.dsc Changes since the last upload: [ Ondřej Nový ] * Use debhelper-compat instead of debian/compat . [ Alf Gaida ] * New upstream release * Bumped debhelper-compat to 12, no changes needed * Bumped Standards-Version to 4.4.0, no changes needed * Bumped years in copyright to 2019 * Reviewed patches, reworked 09-use-https.patch . [ Mateusz Łukasik ] * New upstream release. (Closes: #943993 #945595) * d/rules: Add missing entry. (Closes: #916096) * d/control: add Rules-Requires-Root Regards, -- Mateusz Łukasik
Bug#946540: closed by Andreas Metzler (Re: Bug#946540: Revise README.Debian)
On 2019-12-10 積丹尼 Dan Jacobson wrote: > We read there >To avoid the (small) performance issue one can locally create > No only a (small) performance issue, but a source of warnings. You need > to mention one will get warnings without doing this step. Will do. >certificates. The exim-gencert script (which requires openssl) can be >helpful for this purpose. It is shipped in >/usr/share/doc/exim4-base/examples/ and takes care of proper access >privileges on the private key file when installing key/certificate in >/etc/exim4/. > OK, but the user doesn't know what to fill in for e.g., > commonName = Server name (eg. ssl.domain.tld; required!!!) > commonName_max = 64 If they have a stable they will know. If they do not, there is not correct response. > Also apparently when one sees the warning, it means exim "has run the > script for him" and "run once each time one sends a message" thus > causing the aforementioned small performance issue, vs. running it once > per computer's lifetime. > So apparently, as far as exim connecting to one's ISP, the view from the > ISP is entirely the same. The ISP will never see the snakeoil certificate. This is eally only about the server side, exim *receiving* messages by SMTP. [...] > Thus for users on their own personal computers, perhaps add a note to > README, that the warnings can safely be ignored. Ok. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#885505: bumping severity of pygtk bugs
On Mon, Oct 07, 2019 at 04:51:09PM +0200, Thibaut Paumard wrote: > Dear Jeremy, > > Thanks, I have warned upstream that spydr will be removed if not updated > to Python 3 and Gtk 3. Was there any reaction? Otherwise let's go ahead with the removal from the archive. Cheers, Moritz
Bug#936892: libmediainfo: Python2 removal in sid/bullseye
On Fri, Aug 30, 2019 at 07:23:51AM +, Matthias Klose wrote: > Package: src:libmediainfo > Version: 18.12-2 > Severity: normal > Tags: sid bullseye > User: debian-pyt...@lists.debian.org > Usertags: py2removal > > If there is no py2removal bug for that reverse-dependency, please file > a bug on this package (similar to this bug report). > > If there are questions, please refer to the wiki page for the removal: > https://wiki.debian.org/Python/2Removal, or ask for help on IRC > #debian-python, or the debian-pyt...@lists.debian.org mailing list. All reverse dependencies of python-mediainfodll have migrated to Python 3, this is good to go away. Cheers, Moritz
Bug#922574: digiKam FTBFS with OpenCV 4
Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=401306 This appears to have been fixed upstream. There are a couple patches there.
Bug#946470: libreoffice-l10n-de: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE
On Mon, Dec 09, 2019 at 08:39:52PM +0100, Andreas Beckmann wrote: > On 09/12/2019 18.37, Rene Engelhard wrote: > > Either asap or next week when rc1 will be there (but either way will be NEW > > given the previous versions > > are still waiting in NEW since mid-November...) > > No need to hurry ... It depends. > as long as it is fixed once these packages go to sid. Which actually was (and I am still pondering to do it) planned for said rc1. beta1-3 uploaded. Regards, Rene
Bug#946540: closed by Andreas Metzler (Re: Bug#946540: Revise README.Debian)
We read there To avoid the (small) performance issue one can locally create No only a (small) performance issue, but a source of warnings. You need to mention one will get warnings without doing this step. certificates. The exim-gencert script (which requires openssl) can be helpful for this purpose. It is shipped in /usr/share/doc/exim4-base/examples/ and takes care of proper access privileges on the private key file when installing key/certificate in /etc/exim4/. OK, but the user doesn't know what to fill in for e.g., commonName = Server name (eg. ssl.domain.tld; required!!!) commonName_max = 64 Also apparently when one sees the warning, it means exim "has run the script for him" and "run once each time one sends a message" thus causing the aforementioned small performance issue, vs. running it once per computer's lifetime. So apparently, as far as exim connecting to one's ISP, the view from the ISP is entirely the same. So the user might as well choose to let the warnings fill up mainlog, rather that trying to learn how to install all this certificate stuff. Thus for users on their own personal computers, perhaps add a note to README, that the warnings can safely be ignored.
Bug#945944: stretch-pu: package ros-ros-comm/1.12.6-2
Control: tags -1 + confirmed On Sun, 2019-12-01 at 14:08 +0100, Jochen Sprickerhof wrote: > The ros-ros-comm version in stretch is affected affected by > CVE-2019-13566 which was flagged no-dsa by the security team. I > propose the attached patch to fix the issue. Would you be fine with > me uploading it? Please go ahead. > This is the same as #945896, just for stretch. I adopted the values > as reportbug doesn't seem to support stretch-pu. Hope I did it right. Really? Which version? On buster, I get: What sort of request is this? (If none of these things mean anything to you, or you are trying to report a bug in an existing package, please press Enter to exit reportbug.) 1 binnmu binNMU requests 2 britney testing migration script bugs 3 buster-pu buster proposed updates requests 4 other None of the other options 5 rm Stable/Testing removal requests 6 stretch-pu stretch proposed updates requests 7 transition transition tracking 8 unblock unblock requests Regards, Adam
Bug#946467: nmu: debos_1.0.0+git20190123.d6e16be-1 (in buster)
Control: tags -1 + confirmed On Mon, 2019-12-09 at 15:01 +, Simon McVittie wrote: > nmu debos_1.0.0+git20190123.d6e16be-1 . ANY . buster . -m "rebuild > with fakemachine 0.0~git20181105.9316584-2 (#924392)" Scheduled. Regards, Adam
Bug#946548: libssh: CVE-2019-14889
Source: libssh Version: 0.9.0-1 Severity: important Tags: security upstream Forwarded: https://bugs.libssh.org/T181 Control: found -1 0.8.7-1 Hi, The following vulnerability was published for libssh. CVE-2019-14889[0]: Unsanitized location in scp could lead to unwanted command execution If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2019-14889 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14889 [1] https://bugs.libssh.org/T181 [2] https://www.libssh.org/security/advisories/CVE-2019-14889.txt Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#945443: git-svn fails with "error: git-svn died of signal 11"
Control: tags -1 + upstream patch
Dear Maintainer,
I think I found the issue.
In [1] gets a temporary KAboutData object created, with
string parameters created by QStringLiteral. Therefore
it looks like QStrings created from that have also a
private d member pointing to the static data segment of
the library libsvn_auth_kwallet-1.so.1.
Inside KAboutData::setApplicationData another KAboutData
object get created which gets a shared copy of the d member,
therefore also pointer to the QStringLiterals.
Later the library libsvn_auth_kwallet-1.so.1 gets unloaded.
Then on process end the exit handlers try to delete
the KAboutData which tries to access the now invalid pointers
to the static data segment of the library
libsvn_auth_kwallet-1.so.1
---
Attached patch changes the QStringLiteral to QString, therefore
also temporary QString objects should be created, which can be
destroyed even when the shared library got unloaded.
Another possible solution could be if KAboutData would create
deep copies of its strings at this assignment [2].
---
I did not really find an upstream bug in the svn tracker [3].
Just a bug at kde.org [5] which refrences also the
bug [4] found by Christin.
Kind regards,
Bernhard
[1]
https://sources.debian.org/src/subversion/1.13.0-1/subversion/libsvn_auth_kwallet/kwallet.cpp/#L230
https://sources.debian.org/src/subversion/1.13.0-1/subversion/libsvn_auth_kwallet/kwallet.cpp/#L312
[2]
https://sources.debian.org/src/kcoreaddons/5.54.0-1/src/lib/kaboutdata.cpp/#L598
[3] https://issues.apache.org/jira/issues/?jql=project%20%3D%20SVN
[4] https://bugs.archlinux.org/task/60005
[5] https://bugs.kde.org/show_bug.cgi?id=407271
(gdb) bt
#0 0x758e3e64 in std::__atomic_base::load(std::memory_order)
const (__m=std::memory_order_relaxed, this=0x75a23280) at
/usr/include/c++/8/bits/atomic_base.h:390
#1 0x758e3e64 in QAtomicOps::load(std::atomic const&)
(_q_value=...) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qatomic_cxx11.h:227
#2 0x758e3e64 in QBasicAtomicInteger::load() const
(this=0x75a23280) at
/usr/include/x86_64-linux-gnu/qt5/QtCore/qbasicatomic.h:103
#3 0x758e3e64 in QtPrivate::RefCount::deref() (this=0x75a23280) at
/usr/include/x86_64-linux-gnu/qt5/QtCore/qrefcount.h:66
#4 0x758e3e64 in QString::~QString() (this=0x569742d0,
__in_chrg=) at
/usr/include/x86_64-linux-gnu/qt5/QtCore/qstring.h:1130
#5 0x758e3e64 in KAboutData::Private::~Private() (this=0x569742d0,
__in_chrg=) at ./src/lib/kaboutdata.cpp:460
#6 0x758e3e64 in KAboutData::~KAboutData() (this=0x56972700,
__in_chrg=) at ./src/lib/kaboutdata.cpp:581
#7 0x758e410d in KAboutDataRegistry::~KAboutDataRegistry()
(this=0x7595a6e0 <(anonymous
namespace)::Q_QGS_s_registry::innerFunction()::holder>, __in_chrg=) at ./src/lib/kaboutdata.cpp:1040
#8 0x758e410d in (anonymous
namespace)::Q_QGS_s_registry::Holder::~Holder() (this=0x7595a6e0
<(anonymous namespace)::Q_QGS_s_registry::innerFunction()::holder>,
__in_chrg=) at ./src/lib/kaboutdata.cpp:1040
#9 0x77c87d8c in __run_exit_handlers (status=0, listp=0x77e09718
<__exit_funcs>, run_list_atexit=run_list_atexit@entry=true,
run_dtors=run_dtors@entry=true) at exit.c:108
#10 0x77c87eba in __GI_exit (status=) at exit.c:139
#11 0x555883f6 in main (argc=, argv=,
env=) at perlmain.c:166
Description: Avoid crash in __run_exit_handlers by using QString instead of QStringLiteral
If QStringLiteral is used then pointer to segments in the
shared library libsvn_auth_kwallet-1.so.1 are passed to
the KAboutData::Private object, which unfortuantely makes
no deep copy.
Later in the exit handler when the KAboutData object gets
destroyed, that pointer are again accessed and trigger the
crash.
Author: Bernhard Ãbelacker
Bug-Debian: https://bugs.debian.org/945443
Bug-Kde: https://bugs.kde.org/show_bug.cgi?id=407271
Bug-Arch: https://bugs.archlinux.org/task/60005
Forwarded: no
Last-Update: 2019-12-10
--- subversion-1.10.4.orig/subversion/libsvn_auth_kwallet/kwallet.cpp
+++ subversion-1.10.4/subversion/libsvn_auth_kwallet/kwallet.cpp
@@ -227,10 +227,10 @@ kwallet_password_get(svn_boolean_t *done
KLocalizedString::setApplicationDomain("subversion"); /* translation domain */
/* componentName appears in KDE GUI prompts */
- KAboutData aboutData(QStringLiteral("subversion"), /* componentName */
+ KAboutData aboutData(QString("subversion"),/* componentName */
i18n(get_application_name(parameters,
pool)), /* displayName */
- QStringLiteral(SVN_VER_NUMBER));
+ QString(SVN_VER_NUMBER));
KAboutData::setApplicationData(aboutData);
#else
KCmdLineArgs::init(q_argc, q_argv,
@@ -309,10 +309,10 @@ kwallet_password_set(svn_boolean_t *done
KLocalizedString::setApplicationDomain("subversion"); /*
Bug#945981: pathspider build-depends on cruft package.
control: tags -1 patch pending On Mon, 2 Dec 2019 02:52:51 + peter green wrote: > Package: pathspider > Version: 2.0.1-2 > Severity: serious > > Pathspider build-depends on pylint3, which is no longer built by the pylint > source package. Please consider changing your build-dependency to pylint (>= > 2.2.2-2). I have not done a test build in this case, because your package > already has a FTBFS bug. > > > in deferred/5 a fix with two tests disabled, but not closing the other RC bug G. diff -Nru pathspider-2.0.1/debian/changelog pathspider-2.0.1/debian/changelog --- pathspider-2.0.1/debian/changelog 2018-02-01 21:30:43.0 +0100 +++ pathspider-2.0.1/debian/changelog 2019-12-10 18:49:55.0 +0100 @@ -1,3 +1,15 @@ +pathspider (2.0.1-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * Switch pylint3 dependency to pylint, the former is a cruft package +(Closes: #945981) + * Disable test_plugin_evilbit.py and test_plugin_udpzero.py +by adding them to debian/clean target. +NOTE: I'm not closing the RC bug, because the fix needs to be addressed +anyway, this upload is meant to remove pylint2 cruft package. + + -- Gianfranco Costamagna Tue, 10 Dec 2019 18:49:55 +0100 + pathspider (2.0.1-2) unstable; urgency=medium * d/control: diff -Nru pathspider-2.0.1/debian/clean pathspider-2.0.1/debian/clean --- pathspider-2.0.1/debian/clean 1970-01-01 01:00:00.0 +0100 +++ pathspider-2.0.1/debian/clean 2019-12-10 18:49:55.0 +0100 @@ -0,0 +1,2 @@ +pathspider/tests/test_plugin_evilbit.py +pathspider/tests/test_plugin_udpzero.py diff -Nru pathspider-2.0.1/debian/control pathspider-2.0.1/debian/control --- pathspider-2.0.1/debian/control 2018-02-01 21:30:15.0 +0100 +++ pathspider-2.0.1/debian/control 2019-12-10 18:49:38.0 +0100 @@ -16,7 +16,7 @@ python3-scapy, python3-stem, python3-pycurl (>= 7.43.0.1), - pylint3 + pylint Standards-Version: 4.1.3 Vcs-Browser: https://anonscm.debian.org/cgit/pkg-netmeasure/pathspider.git Vcs-Git: https://anonscm.debian.org/git/pkg-netmeasure/pathspider.git
Bug#946518: gitlab: gitalb-unicorn not starting on 12.2.9-5
Thx Solved installing http://snapshot.debian.org/archive/debian-ports/20180917T212034Z/pool/main/r/ruby-graphql/ruby-graphql_1.8.4-1_all.deb Don't thinked at this solution. In my system this package is used only by gitlab. On 10.12.2019 19:20, Pirate Praveen wrote: On 2019, ഡിസംബർ 10 5:46:50 PM IST, Dragos Jarca wrote: Package: gitlab Version: 12.2.9-5 Severity: grave Tags: a11y Justification: renders package unusable Dear Maintainer, After update to 12.2.9-5 gitlab-unicorn cannot start. We cannot use gitlab. The error seems to be related to https://gitlab.com/gitlab-org/gitlab-foss/issues/62535 . Thanks See if you can use older version of ruby-graphql from snapshots.debian.net Else it should be fixed in 12.3.8 I hope. /usr/lib/ruby/vendor_ruby/graphql/schema/member/build_type.rb:114:in `to_type_name': Unhandled to_type_name input: (NilClass) (RuntimeError) >from /usr/lib/ruby/vendor_ruby/graphql/schema/field.rb:116:in `connection?' >from /usr/lib/ruby/vendor_ruby/graphql/schema/field.rb:135:in `scoped?' >from /usr/lib/ruby/vendor_ruby/graphql/schema/field.rb:260:in `initialize' from /usr/lib/ruby/vendor_ruby/graphql/schema/member/accepts_definition.rb:142:in `initialize' >from /usr/share/gitlab/app/graphql/types/base_field.rb:14:in `initialize' from /usr/lib/ruby/vendor_ruby/graphql/schema/field.rb:107:in `new' >from /usr/lib/ruby/vendor_ruby/graphql/schema/field.rb:107:in `from_options' from /usr/lib/ruby/vendor_ruby/graphql/schema/member/has_fields.rb:13:in `field' >from /usr/share/gitlab/app/graphql/types/query_type.rb:27:in `' >from /usr/share/gitlab/app/graphql/types/query_type.rb:4:in `' >from /usr/share/gitlab/app/graphql/types/query_type.rb:3:in ` (required)>' from /usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:291:in `require' from /usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:291:in `block in require' from /usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:257:in `load_dependency' from /usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:291:in `require' from /usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:378:in `block in require_or_load' from /usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:37:in `block in load_interlock' from /usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies/interlock.rb:14:in `block in loading' from /usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/concurrency/share_lock.rb:151:in `exclusive' from /usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies/interlock.rb:13:in `loading' from /usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:37:in `load_interlock' from /usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:356:in `require_or_load' from /usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:510:in `load_missing_constant' from /usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:195:in `const_missing' >from /usr/share/gitlab/app/graphql/gitlab_schema.rb:26:in `' >from /usr/share/gitlab/app/graphql/gitlab_schema.rb:3:in ` (required)>' from /usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:291:in `require' from /usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:291:in `block in require' from /usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:257:in `load_dependency' from /usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:291:in `require' from /usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:378:in `block in require_or_load' from /usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:37:in `block in load_interlock' from /usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies/interlock.rb:14:in `block in loading' from /usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/concurrency/share_lock.rb:151:in `exclusive' from /usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies/interlock.rb:13:in `loading' from /usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:37:in `load_interlock' from /usr/share/rubygems-integration/all/gems/activesupport-5.2.3/lib/active_support/dependencies.rb:356:in `require_or_load' from
Bug#946534: FireFox 683.0esr Links
1: https://www.lloyd-shop.dk/shop/udsalg-162c1.html?gclid=EAIaIQobChMI-uG988-r5gIVmOiaCh1OBwHMEAAYASAAEgKyrvD_BwE 2: https://www.lloyd-shop.dk/shop/lloyd-egmond-herre-2853p.html?gclid=EAIaIQobChMItMqxg9Cr5gIVg9OaCh3AdQN8EAEYASABEgISovD_BwE -- Med venlig hilsen/kind regards René Lagoni Neukirch Højenhald 1, 2. th 2700 Brønshøj Mob. 2093 1904
