Bug#920976: reproducible, tentatively forwarded upstream
I have the same. This upstream bug seems matching: https://bugs.kde.org/show_bug.cgi?id=407390 but it needs confirmation. Paolo
Bug#930058: unblock: puppet/5.5.10-3
On Mon, Jun 17, 2019 at 12:59:10AM +0200, Thomas Goirand wrote: > I don't think people read more the NEWS than the changelog. I'm not sure how you arrive at that conclusion, but here's a consideration: it's my company's policy that the NEWS are read during every upgrade of a client system (and our own) to catch surprises like this. It is a good example of exactly what NEWS files are for. Popcon also suggests that 85% of respondents have apt-listchanges installed, which is the package giving this behaviour. So I disagree with your statement that it is a waste of time documenting a surprising behaviour change like this. As Micah demonstrates, local administrators upgrading may already have a mechanism to deal with the problem and your cron job will conflict with that. > Having run puppet on a small virtual machine with 40 GB disk, and having > it taken down by 800 MB reports every day for every compute in the > cluster, no, this isn't controversial. This is completely mandatory. > What I believe puppet user do is set this up by themselves, or disable > reports all together. Keeping 1 month of reports is very conservative. I don't disagree with the problem statement. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51
Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems
On Sun 2019-06-16 15:50:55 +0200, Ivo De Decker wrote: > As "--changes-option=-S" creates an upload that is broken from the point of > view of the archive, it might make sense not to recommend (or even allow) this > for now. Just building with "-S" instead should create a buildinfo file with > _source, which won't trigger this issue. For the rest of the regular archive, --changes-option=-S is definitely *not* broken. I use that regularly, and strongly prefer it. It allows me to document what i managed to build, while still ensuring that the distributed binaries are created by debian's buildd network, and not my own machinery. I would be pretty sad if --changes-option=-S was explicitly deprecated in any part of the debian archive. --dkg signature.asc Description: PGP signature
Bug#865975: docker.io changes iptables default FORWARD policy to DROP, breaks VM and others
On Mon, Jun 17, 2019 at 10:16 AM Arnaud Rebillout wrote: > Hi, > > I will, and can even go further and display an explicit message when > user upgrade the package maybe? (I'm not sure how to do that but I'm > sure I'll find an example easily). docker.io already has a NEWS file, you can just add a new entry, by running: dch --news debian/docker.io.NEWS but I don't think it's needed... docker.io is not in stretch, so people will not upgrade it from stretch. And this issue exists since 1.13.0(long ago). -- Shengjing Zhu
Bug#930563: Re: Bug#930563: Can not start freecad
Hello Bernhard, Thanks for your reply! I have install the proprietary nvidia drivers and it runs well. The output of commands which you list as below, > ldd /usr/bin/freecad linux-vdso.so.1 (0x7ffe69ae5000) libhdf5_openmpi.so.103 => /lib/x86_64-linux-gnu/libhdf5_openmpi.so.103 (0x7f2032967000) libmpi.so.40 => /lib/x86_64-linux-gnu/libmpi.so.40 (0x7f203285e000) libmpi_cxx.so.40 => /lib/x86_64-linux-gnu/libmpi_cxx.so.40 (0x7f203284) libFreeCADGui.so => /usr/lib/freecad-python2/lib/libFreeCADGui.so (0x7f2031a96000) libFreeCADApp.so => /usr/lib/freecad-python2/lib/libFreeCADApp.so (0x7f2031744000) libFreeCADBase.so => /usr/lib/freecad-python2/lib/libFreeCADBase.so (0x7f20315ae000) libpython2.7.so.1.0 => /lib/x86_64-linux-gnu/libpython2.7.so.1.0 (0x7f203123f000) libxerces-c-3.2.so => /lib/x86_64-linux-gnu/libxerces-c-3.2.so (0x7f2030e94000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f2030c76000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f2030c71000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f2030c6c000) libzipios.so.0 => /lib/x86_64-linux-gnu/libzipios.so.0 (0x7f2030a3f000) libQt5Xml.so.5 => /lib/x86_64-linux-gnu/libQt5Xml.so.5 (0x7f20309fe000) libCoin.so.80c => /lib/x86_64-linux-gnu/libCoin.so.80c (0x7f2030166000) libboost_filesystem.so.1.67.0 => /lib/x86_64-linux-gnu/libboost_filesystem.so.1.67.0 (0x7f2030148000) libboost_program_options.so.1.67.0 => /lib/x86_64-linux-gnu/libboost_program_options.so.1.67.0 (0x7f20300c1000) libboost_regex.so.1.67.0 => /lib/x86_64-linux-gnu/libboost_regex.so.1.67.0 (0x7f202ffac000) libboost_system.so.1.67.0 => /lib/x86_64-linux-gnu/libboost_system.so.1.67.0 (0x7f202ffa5000) libboost_thread.so.1.67.0 => /lib/x86_64-linux-gnu/libboost_thread.so.1.67.0 (0x7f202ff77000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f202ff56000) libboost_chrono.so.1.67.0 => /lib/x86_64-linux-gnu/libboost_chrono.so.1.67.0 (0x7f202ff4b000) libboost_date_time.so.1.67.0 => /lib/x86_64-linux-gnu/libboost_date_time.so.1.67.0 (0x7f202ff37000) libboost_atomic.so.1.67.0 => /lib/x86_64-linux-gnu/libboost_atomic.so.1.67.0 (0x7f202ff32000) libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x7f202fc89000) libQt5OpenGL.so.5 => /lib/x86_64-linux-gnu/libQt5OpenGL.so.5 (0x7f202fc2d000) libQt5PrintSupport.so.5 => /lib/x86_64-linux-gnu/libQt5PrintSupport.so.5 (0x7f202fbb6000) libQt5Svg.so.5 => /lib/x86_64-linux-gnu/libQt5Svg.so.5 (0x7f202fb6) libQt5Network.so.5 => /lib/x86_64-linux-gnu/libQt5Network.so.5 (0x7f202f9bf000) libQt5Widgets.so.5 => /lib/x86_64-linux-gnu/libQt5Widgets.so.5 (0x7f202f368000) libQt5X11Extras.so.5 => /lib/x86_64-linux-gnu/libQt5X11Extras.so.5 (0x7f202f361000) libQt5Gui.so.5 => /lib/x86_64-linux-gnu/libQt5Gui.so.5 (0x7f202edd4000) libQt5Core.so.5 => /lib/x86_64-linux-gnu/libQt5Core.so.5 (0x7f202e8d9000) libspnav.so.0 => /lib/libspnav.so.0 (0x7f202e6d5000) libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x7f202e594000) libshiboken2-python2.7.x86_64-linux-gnu.so.5.11 => /lib/x86_64-linux-gnu/libshiboken2-python2.7.x86_64-linux-gnu.so.5.11 (0x7f202e568000) libpyside2-python2.7.x86_64-linux-gnu.so.5.11 => /lib/x86_64-linux-gnu/libpyside2-python2.7.x86_64-linux-gnu.so.5.11 (0x7f202e52e000) libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f202e3a8000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f202e225000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f202e20b000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f202e04a000) libsz.so.2 => /lib/x86_64-linux-gnu/libsz.so.2 (0x7f202de47000) libopen-rte.so.40 => /lib/x86_64-linux-gnu/libopen-rte.so.40 (0x7f202dd8f000) libopen-pal.so.40 => /lib/x86_64-linux-gnu/libopen-pal.so.40 (0x7f202dce) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f202dcd6000) libhwloc.so.5 => /lib/x86_64-linux-gnu/libhwloc.so.5 (0x7f202dc94000) libevent-2.1.so.6 => /lib/x86_64-linux-gnu/libevent-2.1.so.6 (0x7f202da3e000) libevent_pthreads-2.1.so.6 => /lib/x86_64-linux-gnu/libevent_pthreads-2.1.so.6 (0x7f202d83b000) libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x7f202d82) libcurl-gnutls.so.4 => /lib/x86_64-linux-gnu/libcurl-gnutls.so.4 (0x7f202d792000) libicui18n.so.63 => /lib/x86_64-linux-gnu/libicui18n.so.63 (0x7f202d4b7000) libicuuc.so.63 => /lib/x86_64-linux-gnu/libicuuc.so.63 (0x7f202d2e8000) libicudata.so.63 =>
Bug#930587: Re: Bug#930587: release-notes: fails to build for jessie and stretch
Hi Jover,
You are right. I was choosing between release-notes and www.debian.org
but I was not aware that the .dbk files will be regenerated anyway
during the build process. It seems that this should be reassigned
to www.debian.org.
The build script is at
https://salsa.debian.org/webmaster-team/cron/raw/master/parts/7release-notes
and it indeed uses git checkout to build for different releases.
Best regards,
Wenbin Lv
On Sun, 16 Jun 2019 23:01:14 +0200 Guillem Jover wrote:
> Hi!
>
> On Sun, 2019-06-16 at 14:40:53 +0800, Wenbin Lv wrote:
> > Package: release-notes
> > Severity: serious
> > Tags: ftbfs
> > Justification: fails to build from source (but built successfully in the
> > past)>
> > Recent transition from .dbk to .po for the ca language leaves some
> > untracked .dbk files in the source directory and causes git checkout of
> > jessie and stretch to fail in the build system of the Debian website,
> > showing the following errors[1]:
> >
> > rebuilding the release notes for {jessie,stretch}
> > error: The following untracked working tree files would be overwritten by
> > checkout:> > ca/about.dbk
> > ca/installing.dbk
> > ca/issues.dbk
> > ca/moreinfo.dbk
> > ca/old-stuff.dbk
> > ca/release-notes.dbk
> > ca/upgrading.dbk
> > ca/whats-new.dbk
>
> This looks like a bug in the website build machinery? These files are
> left behind in the same way they are for all other languages. The
> difference is that they got switched very recently.
>
> I'm assuming from your description that the website machinery, does a
> git checkout on each specific branch and then builds it, but is not
> running «make clean» before each git checkout?
>
> > which causes buster version of the release notes to be built for jessie
> > and stretch[2][3].
>
> Right!
>
> > Please remove the untracked files to fix the issue.
>
> I don't think there is nothing to fix in the release-notes package
> itself. This sould probably be reassigned.
>
> Thanks,
> Guillem
>
>
Bug#919188: severity of 919188 is critical
Control: tag -1 + unreproducible moreinfo Control: severity -1 important Hi Pali, Pali Rohár wrote: > severity 919188 critical Why? You neither explained that it breaks the whole system nor that it causes other, unrelated packages to break nor that it causes serious data-loss. Please check https://www.debian.org/Bugs/Developer#severities and explain why you think that the severity you've chosen fits this bug report. I'm neither the package maintainer nor a release team member (just a happy sslh user), but this bug is at most "grave" even according to your description. Addtionally I can't reproduce this bug no matter which variant I'm trying. And I'm running sslh under sysvinit on Debian Testing since 2012 (in standalone and single-thread mode): # ps auxf | fgrep sslh root 24116 0.0 0.0 8472 908 pts/1S+ 03:08 0:00 | \_ grep -F sslh sslh 12185 0.0 0.2 14004 2648 ?Ss May07 2:49 /usr/sbin/sslh-select --user sslh --listen 0.0.0.0 443 --ssh 127.0.0.1 22 --ssl 127.0.0.1 442 --pidfile /var/run/sslh/sslh.pid # dpkg -l sysvinit-core startpar Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---= ii startpar 0.61-1 amd64run processes in parallel and multiplex their output ii sysvinit-core 2.93-8 amd64System-V-like init utilities # lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux 10 (buster) Release:10 Codename: buster # uptime 03:13:44 up 94 days, 2:26, 2 users, load average: 0,03, 0,23, 0,65 # The above is from before a reboot, but I just rebooted and there's still only one sslh-select process. Tried "service sslh stop" and "service sslh start" as well as rebooting. No difference, no issue. I also tried using the forked variant instead of the single-thread I used so far. But still, neither stopping and starting nor rebooting showed a hanging startpar. Here's after the switch to the forked version and two reboots: # ps auxf | fgrep sslh root 2791 0.0 0.0 8476 908 pts/1S+ 03:49 0:00 \_ grep -F sslh sslh 2515 0.0 0.1 4760 1660 ?Ss 03:47 0:00 /usr/sbin/sslh --user sslh --listen 0.0.0.0 443 --ssh 127.0.0.1 22 --ssl 127.0.0.1 442 --pidfile /var/run/sslh/sslh.pid sslh 2518 0.0 0.0 4760 176 ?S03:47 0:00 \_ /usr/sbin/sslh --user sslh --listen 0.0.0.0 443 --ssh 127.0.0.1 22 --ssl 127.0.0.1 442 --pidfile /var/run/sslh/sslh.pid # Hence tagging it as unreproducible and downgrading the severity: Since this issue doesn't even "rendering it completely unusable" for all sysvinit users (which is considered to be "serious" or "grave") nor for either sslh or sslh-select, this is at most "a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone.", i.e. severity "important". And please also show the complete options to sslh, because this behaviour could e.g. stem from using the -i (inetd) option (which is meant to listen on STDIN and sending to STDOUT) together with starting sslh via init script. If that's the case, it's a configuration error and no bug. (Except maybe that it should listen on port 443 at all then. :-) But even if I configure sslh for both, inetd and as a standalone service, this issue does not happen since the standalone service fails to start because inetd already occupies the HTTPS port. So please also show your sslh entry in /etc/inetd.conf and your /etc/default/sslh. Hence also tagging as "moreinfo". The only (IMHO minor) bug I could find is that "dpkg-reconfigure sslh" doesn't seem to edit neither /etc/inetd.conf nor /etc/default/sslh to switch between the two variants. But if the initial configuration works fine, I'd consider that to be of severity "normal" at most if not just "minor". Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#865975: docker.io changes iptables default FORWARD policy to DROP, breaks VM and others
On 6/17/19 3:22 AM, Shengjing Zhu wrote: > Control: severity -1 normal > > On Tue, Jun 11, 2019 at 6:09 PM Shengjing Zhu wrote: >> Hi, >> >> I checked more carefully on https://github.com/moby/moby/pull/28257 >> and https://github.com/moby/moby/issues/14041 >> Then I concluded that docker does nothing wrong in this case. >> > [...] > > With the reason I explained last week, I would downgrade this issue. > > Arnaud, > when you upload new version for the CVE issue, could you amend the > README.Debian to tell people that if they don't want docker to set > default FORWARD policy to DROP, they should enable ip_forward > intentionally. (I bet your english is better than me to draft a > phrase...) > Hi, I will, and can even go further and display an explicit message when user upgrade the package maybe? (I'm not sure how to do that but I'm sure I'll find an example easily). I'm quite busy now but I hope I'll have time before the end of the week to do all of that. Thanks,
Bug#930633: RFS: i3-gaps/4.16.1-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "i3-gaps" * Package name: i3-gaps * Version : 4.16.1-1 * Upstream Author : Ingo Bürk (Airblader) * URL : https://github.com/Airblader/i3 * License : BSD-3-clause * Section : x11 It builds those binary packages: i3-gaps - Fork of i3-wm with extra features such as gaps To access further information about this package, please visit the following URL: https://mentors.debian.net/package/i3-gaps Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/i/i3-gaps/i3-gaps_4.16.1-1.dsc More information about i3-gaps can be obtained from: https://github.com/Airblader/i3/blob/gaps/README.md Changes since the last upload: * Initial release (Closes: #909646) Regards, antisocrates
Bug#930487: lintian: speed up test suite CI
[2019-06-13 21:29] "Chris Lamb" > Felix Lechner wrote: > > > For Lintian, however, I would prefer to upload the test packages > > separately to Debian's regular build infrastructure. > > Hm, I think you are talking at cross-purposes to Dmitry here. Nobody > was suggesting we upload the test packages to Debian; that would > surely be impossible. > > > Gitlab has a support for saving various parts of a successful build > for the next one. I believe the idea is that we would build the test > packages and then push them to this cache re-using them on any subsequent > test runs. People often use this to cache "pip" Python dependencies > but I don't see any obvious reason why we can't use it here. Thank you. That is exactly what I meant. -- Note, that I send and fetch email in batch, once in a few days.
Bug#930058: unblock: puppet/5.5.10-3
On 6/15/19 7:54 PM, Paul Gevers wrote: > Control: tags -1 moreinfo > > Hi Thomas, > > On 06-06-2019 10:36, Thomas Goirand wrote: >> Version 5.5.10-3 adds a tiny cron.daily job which cleans-up the >> /var/lib/puppet/reports folder to avoid that a puppet-master >> server gets its HDD full, which potentially could be very harmful >> for a deployment. > > This seems slightly controversial to me (as hinted by a comment in the > bug as well). Don't you think this warrants a note in NEWS? > > Paul Hi, Thanks for your time reviewing this yet another unblock request. I don't think people read more the NEWS than the changelog. Respectfully (please don't see any aggressiveness here: there's none), if you really want to waste everyone's time on this, then I can do it, but I don't think this helps. There's not much time before the final release. Having run puppet on a small virtual machine with 40 GB disk, and having it taken down by 800 MB reports every day for every compute in the cluster, no, this isn't controversial. This is completely mandatory. What I believe puppet user do is set this up by themselves, or disable reports all together. Keeping 1 month of reports is very conservative. Cheers, Thomas Goirand (zigo)
Bug#930294: Nautilus slow to respond and consumes 100% CPU resource
On Mon, Jun 10, 2019 at 10:36:21AM +0530, Vikram Vincent wrote: > (nautilus:15529): Gtk-WARNING **: 10:11:36.857: Duplicate child name in > GtkStack: Thumbnails > (nautilus:15529): Gtk-WARNING **: 10:11:36.859: Duplicate child name in > GtkStack: Thumbnails > (nautilus:15529): Gtk-WARNING **: 10:11:36.861: Duplicate child name in > GtkStack: META-INF > (nautilus:15529): Gtk-WARNING **: 10:11:36.865: Duplicate child name in > GtkStack: Thumbnails > (nautilus:15529): Gtk-WARNING **: 10:11:36.867: Duplicate child name in > GtkStack: Pictures > (nautilus:15529): Gtk-WARNING **: 10:11:36.869: Duplicate child name in > GtkStack: Thumbnails > (nautilus:15529): Gtk-WARNING **: 10:11:36.870: Duplicate child name in > GtkStack: Pictures > (nautilus:15529): Gtk-WARNING **: 10:11:36.872: Duplicate child name in > GtkStack: META-INF > (nautilus:15529): Gtk-WARNING **: 10:11:36.874: Duplicate child name in > GtkStack: Thumbnails > (nautilus:15529): Gtk-WARNING **: 10:11:36.876: Duplicate child name in > GtkStack: META-INF These filenames suggest to me that you had some strange things in your Templates folder and possibly it contained a large number of files. Is this the case?
Bug#927159: libqb: CVE-2019-12779: Insecure Temporary Files
Dear Security Team,
I'm ready to upload libqb-1.0.1-1+deb9u1 with the following debdiff:
diff -Nru libqb-1.0.1/debian/changelog libqb-1.0.1/debian/changelog
--- libqb-1.0.1/debian/changelog2016-12-07 14:55:45.0 +0100
+++ libqb-1.0.1/debian/changelog2019-06-16 23:41:50.0 +0200
@@ -1,3 +1,21 @@
+libqb (1.0.1-1+deb9u1) stretch-security; urgency=high
+
+ * [38e0e13] Backport upstream security fixes for CVE-2019-12779.
+Libqb creates files in world-writable directories (/dev/shm, /tmp) with
+rather predictable file names (for example in case of USBGuard with names
+like /dev/shm/qb-usbguard-request-7096-835-12-data). Also O_EXCL flag is
+not used when opening the files. This could be exploited by a local
+attacker to overwrite privileged system files (if not restricted by
+sandboxing, MAC or symlinking policies).
+Original report: https://github.com/ClusterLabs/libqb/issues/338
+Add O_EXCL: https://github.com/ClusterLabs/libqb/pull/339
+Use mkdtemp():https://github.com/ClusterLabs/libqb/pull/345
+Regression fixes: https://github.com/ClusterLabs/libqb/pull/349
+(Closes: #927159)
+ * [79734d7] Acknowledge new internal symbol
+
+ -- Ferenc Wágner Sun, 16 Jun 2019 23:41:50 +0200
+
libqb (1.0.1-1) unstable; urgency=medium
[ Christoph Berg ]
diff -Nru libqb-1.0.1/debian/gbp.conf libqb-1.0.1/debian/gbp.conf
--- libqb-1.0.1/debian/gbp.conf 2016-12-07 14:47:16.0 +0100
+++ libqb-1.0.1/debian/gbp.conf 2019-06-16 22:48:22.0 +0200
@@ -1,14 +1,12 @@
[DEFAULT]
-debian-branch = debian/master
+debian-branch = debian/stretch
upstream-branch = upstream/latest
-debian-tag-msg = Debian release %(version)s
-
-[import-orig]
pristine-tar = True
-[gbp-pq]
-patch-numbers = False
-
-[gbp-dch]
+[dch]
+full = True
multimaint-merge = True
id-length = 7
+
+[pq]
+patch-numbers = False
diff -Nru libqb-1.0.1/debian/libqb0.symbols libqb-1.0.1/debian/libqb0.symbols
--- libqb-1.0.1/debian/libqb0.symbols 2016-12-07 14:47:16.0 +0100
+++ libqb-1.0.1/debian/libqb0.symbols 2019-06-16 23:41:22.0 +0200
@@ -236,5 +236,6 @@
qb_util_timespec_from_epoch_get@Base 0.11.1
qb_vsnprintf_deserialize@Base 0.11.1
qb_vsnprintf_serialize@Base 0.14.2
+ remove_tempdir@Base 1.0.1-1+deb9u1~
strlcat@Base 0.11.1
strlcpy@Base 0.11.1
diff -Nru
libqb-1.0.1/debian/patches/CVE-2019-12779/Allow-group-access-to-the-IPC-directory.patch
libqb-1.0.1/debian/patches/CVE-2019-12779/Allow-group-access-to-the-IPC-directory.patch
---
libqb-1.0.1/debian/patches/CVE-2019-12779/Allow-group-access-to-the-IPC-directory.patch
1970-01-01 01:00:00.0 +0100
+++
libqb-1.0.1/debian/patches/CVE-2019-12779/Allow-group-access-to-the-IPC-directory.patch
2019-06-16 23:10:03.0 +0200
@@ -0,0 +1,29 @@
+From: =?utf-8?q?Ferenc_W=C3=A1gner?=
+Date: Thu, 18 Apr 2019 13:20:38 +0200
+Subject: Allow group access to the IPC directory
+
+And don't abort if we aren't permitted to chown() it. The client might
+still have the privileges to enter it.
+---
+ lib/ipc_setup.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/lib/ipc_setup.c b/lib/ipc_setup.c
+index f6f1d7d..6183001 100644
+--- a/lib/ipc_setup.c
b/lib/ipc_setup.c
+@@ -640,11 +640,12 @@ handle_new_connection(struct qb_ipcs_service *s,
+ res = -errno;
+ goto send_response;
+ }
+- res = chown(c->description, c->auth.uid, c->auth.gid);
+- if (res != 0) {
++ if (chmod(c->description, 0770)) {
+ res = -errno;
+ goto send_response;
+ }
++ /* chown can fail because we might not be root */
++ (void)chown(c->description, c->auth.uid, c->auth.gid);
+
+ /* We can't pass just a directory spec to the clients */
+ strncat(c->description,"/qb", CONNECTION_DESCRIPTION);
diff -Nru
libqb-1.0.1/debian/patches/CVE-2019-12779/Errors-are-represented-as-negative-values.patch
libqb-1.0.1/debian/patches/CVE-2019-12779/Errors-are-represented-as-negative-values.patch
---
libqb-1.0.1/debian/patches/CVE-2019-12779/Errors-are-represented-as-negative-values.patch
1970-01-01 01:00:00.0 +0100
+++
libqb-1.0.1/debian/patches/CVE-2019-12779/Errors-are-represented-as-negative-values.patch
2019-06-16 23:10:03.0 +0200
@@ -0,0 +1,27 @@
+From: =?utf-8?q?Ferenc_W=C3=A1gner?=
+Date: Wed, 17 Apr 2019 15:09:42 +0200
+Subject: Errors are represented as negative values
+
+---
+ lib/ipc_setup.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/lib/ipc_setup.c b/lib/ipc_setup.c
+index a66004d..f6f1d7d 100644
+--- a/lib/ipc_setup.c
b/lib/ipc_setup.c
+@@ -637,12 +637,12 @@ handle_new_connection(struct qb_ipcs_service *s,
+ snprintf(c->description, CONNECTION_DESCRIPTION,
+"/dev/shm/qb-%d-%d-%d-XX", s->pid, ugp->pid,
c->setup.u.us.sock);
+ if (mkdtemp(c->description) == NULL) {
+- res =
Bug#930632: unblock: libfm-qt/0.14.1-9
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package libfm-qt Latest version fixes #926803, missed file monitoring on remote file systems. Without the fix remote filesystems are nearly unusable. Diff: diff --git a/debian/changelog b/debian/changelog index 9bc9b25..54ef4eb 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +libfm-qt (0.14.1-9) unstable; urgency=medium + + * Added upstream patch workaround-missed-file-monitoring.patch +(Closes: #926803) + * Added two new symbols - internal use only + + -- Alf Gaida Sat, 08 Jun 2019 16:39:11 +0200 + libfm-qt (0.14.1-8) unstable; urgency=medium * Removed the wrongly introduced build dependency on lxqt-qtplugin diff --git a/debian/libfm-qt6.symbols b/debian/libfm-qt6.symbols index d06f805..158bd23 100644 --- a/debian/libfm-qt6.symbols +++ b/debian/libfm-qt6.symbols @@ -531,12 +531,14 @@ libfm-qt.so.6 libfm-qt6 #MINVER# (c++)"Fm::Folder::filesAdded(Fm::FileInfoList&)@Base" 0.12.0 (c++)"Fm::Folder::filesChanged(std::vector, std::shared_ptr >, std::allocator, std::shared_ptr > > >&)@Base" 0.12.0 (c++)"Fm::Folder::filesRemoved(Fm::FileInfoList&)@Base" 0.12.0 + (c++)"Fm::Folder::findByPath(Fm::FilePath const&)@Base" 0.14.1~ (c++)"Fm::Folder::finishLoading()@Base" 0.12.0 (c++)"Fm::Folder::fromPath(Fm::FilePath const&)@Base" 0.12.0 (c++|arch= !armel !armhf !i386 !mips !mipsel !hppa !hurd-i386 !kfreebsd-i386 !m68k !powerpc !powerpcspe !sh4 !x32 )"Fm::Folder::getFilesystemInfo(unsigned long*, unsigned long*) const@Base" 0.12.0 (c++|arch= !amd64 !arm64 !mips64el !ppc64el !s390x !alpha !ia64 !kfreebsd-amd64 !ppc64 !riscv64 !sparc64 )"Fm::Folder::getFilesystemInfo(unsigned long long*, unsigned long long*) const@Base" 0.12.0 (c++)"Fm::Folder::hadCutFilesUnset()@Base" 0.12.0 (c++)"Fm::Folder::hasCutFiles()@Base" 0.12.0 + (c++)"Fm::Folder::hasFileMonitor() const@Base" 0.14.1~ (c++)"Fm::Folder::info() const@Base" 0.12.0 (c++)"Fm::Folder::isEmpty() const@Base" 0.12.0 (c++)"Fm::Folder::isIncremental() const@Base" 0.12.0 diff --git a/debian/patches/series b/debian/patches/series index 1a4dd71..031051b 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -2,3 +2,4 @@ fix-smb-recursive-copy.patch fix-license-headers.patch dont-ignore-crea-del-sequences.patch workaround-glib-recursive-moving-error.patch +workaround-missed-file-monitoring.patch diff --git a/debian/patches/workaround-missed-file-monitoring.patch b/debian/patches/workaround-missed-file-monitoring.patch new file mode 100644 index 000..5be3811 --- /dev/null +++ b/debian/patches/workaround-missed-file-monitoring.patch @@ -0,0 +1,143 @@ +Description: Realod folder after transfer job if it lacks file monitoring + Closes https://github.com/lxqt/pcmanfm-qt/issues/933 and closes + https://github.com/lxqt/libfm-qt/issues/280. After a file transfer job is + finished inside a directory, if it is the path of an open folder that lacks + file monitoring, this patch reloads its corresponding folder. In this way, the + lack of file monitoring is partially compensated for. + Please note that this doesn't work with `search://` because the files inside + `search://` don't belong to it. By covering file creation, renaming, moving + from one shared folder to another and deleting after trying to move into Trash. + +Last-Update: 2019-06-08 + +--- libfm-qt-0.14.1.orig/src/core/folder.cpp libfm-qt-0.14.1/src/core/folder.cpp +@@ -112,6 +112,20 @@ std::shared_ptr Folder::fromPath + return
Bug#930631: linux-image-4.19.0-5-amd64: Fresh Buster install fails to boot to desktop
Package: src:linux Version: 4.19.37-3 Severity: critical Justification: breaks the whole system Dear Maintainer, I performed a fresh install using the image debian-testing-amd64-xfce-CD-1.iso and after installation I could not boot to the desktop, I was left with a black screen. I entered tty1 and logged in, I killed x server with sudo service lightdm stop and then created xorg.conf using X -configure and then moved the resulting xorg.conf.new to /etx/X11/xorg.conf. Then restarted x with sudo service lightdm start and this allowed me to access the desktop. I did not have this issue until kernel 4.19.0.4 but was not sure whether the problem was in the kernel or some other X related package but I have now been told it is very likely the kernel so can report it accordingly. -- Package-specific info: ** Version: Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-7)) #1 SMP Debian 4.19.37-3 (2019-05-15) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64 root=UUID=2243e6fe-1608-4037-adc3-18537ee0fe04 ro quiet ** Not tainted ** Kernel log: [ 13.042786] lp: driver loaded but no devices found [ 13.050448] ppdev: user-space parallel port driver [ 14.008566] ACPI: AC Adapter [AC] (on-line) [ 14.057231] battery: ACPI: Battery Slot [BAT0] (battery present) [ 14.089970] ACPI Warning: \_SB.DPTF._ART: Return Package has no elements (empty) (20180810/nsprepkg-96) [ 14.127289] input: PC Speaker as /devices/platform/pcspkr/input/input18 [ 14.186158] dcdbas dcdbas: Dell Systems Management Base Driver (version 5.6.0-3.2) [ 14.249701] input: Dell WMI hotkeys as /devices/platform/PNP0C14:00/wmi_bus/wmi_bus-PNP0C14:00/9DBB5994-A997-11DA-B012-B622A1EF5492/input/input19 [ 14.277540] proc_thermal :00:0b.0: enabling device ( -> 0002) [ 14.284992] proc_thermal :00:0b.0: Creating sysfs group for PROC_THERMAL_PCI [ 14.297842] EFI Variables Facility v0.08 2004-May-17 [ 14.313665] input: DELL Wireless hotkeys as /devices/virtual/input/input20 [ 14.325796] pstore: Registered efi as persistent store backend [ 14.375600] iTCO_vendor_support: vendor-support=0 [ 14.434301] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11 [ 14.434423] iTCO_wdt: Found a Braswell SoC TCO device (Version=3, TCOBASE=0x0460) [ 14.434660] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) [ 14.477781] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 14.477849] sr 1:0:0:0: Attached scsi generic sg1 type 5 [ 14.742532] media: Linux media interface: v0.10 [ 14.892115] videodev: Linux video capture interface: v2.00 [ 15.011868] alg: No test for fips(ansi_cprng) (fips_ansi_cprng) [ 15.131650] uvcvideo: Found UVC 1.00 device Integrated_Webcam_HD (064e:9209) [ 15.139105] uvcvideo 1-5:1.0: Entity type for entity Extension 4 was not initialized! [ 15.139112] uvcvideo 1-5:1.0: Entity type for entity Extension 7 was not initialized! [ 15.139115] uvcvideo 1-5:1.0: Entity type for entity Processing 2 was not initialized! [ 15.139118] uvcvideo 1-5:1.0: Entity type for entity Camera 1 was not initialized! [ 15.139392] input: Integrated_Webcam_HD: Integrate as /devices/pci:00/:00:14.0/usb1/1-5/1-5:1.0/input/input21 [ 15.139771] usbcore: registered new interface driver uvcvideo [ 15.139774] USB Video Class driver (1.1.1) [ 15.159449] snd_hda_intel :00:1b.0: bound :00:02.0 (ops i915_audio_component_bind_ops [i915]) [ 15.211959] Bluetooth: Core ver 2.22 [ 15.211997] NET: Registered protocol family 31 [ 15.211999] Bluetooth: HCI device and connection manager initialized [ 15.212006] Bluetooth: HCI socket layer initialized [ 15.212009] Bluetooth: L2CAP socket layer initialized [ 15.212019] Bluetooth: SCO socket layer initialized [ 15.445372] intel_rapl: Found RAPL domain package [ 15.445375] intel_rapl: Found RAPL domain core [ 15.469675] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC3234: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker [ 15.469680] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 15.469684] snd_hda_codec_realtek hdaudioC0D0:hp_outs=1 (0x21/0x0/0x0/0x0/0x0) [ 15.469686] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0 [ 15.469689] snd_hda_codec_realtek hdaudioC0D0:inputs: [ 15.469694] snd_hda_codec_realtek hdaudioC0D0: Headset Mic=0x19 [ 15.469697] snd_hda_codec_realtek hdaudioC0D0: Headphone Mic=0x1a [ 15.469700] snd_hda_codec_realtek hdaudioC0D0: Internal Mic=0x12 [ 15.813751] ath9k :01:00.0: enabling device ( -> 0002) [ 15.814780] ath: phy0: WB335 2-ANT card detected [ 15.814782] ath: phy0: Set BT/WLAN RX diversity capability [ 15.823300] ath: phy0: Enable LNA combining [ 15.824508] ath: phy0: ASPM enabled: 0x42 [ 15.824511] ath: EEPROM regdomain: 0x6c [ 15.824512] ath: EEPROM indicates we should expect a direct regpair map [ 15.824515] ath: Country alpha2 being used: 00 [
Bug#928882: unblock: [pre-approval] ghc/8.4.4+dfsg1-3
Dear Paul, Indeed I confirm that "happy" provided by Debian buster/sid does not work on my hardware (armv5tel Kirkwood Feroceon). Just tested now after removing Ilias' deb package and reinstalling the previous one: drakestail:/opt/bug_ghc_armel# apt remove happy Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: happy 0 upgraded, 0 newly installed, 1 to remove and 1 not upgraded. After this operation, 2,598 kB disk space will be freed. Do you want to continue? [Y/n] (Reading database ... 100878 files and directories currently installed.) Removing happy (1.19.9-6+armel0) ... Processing triggers for man-db (2.7.6.1-2) ... drakestail:/opt/bug_ghc_armel# apt clean drakestail:/etc/apt/sources.list.d# apt install -t testing happy Reading package lists... Done Building dependency tree Reading state information... Done Suggested packages: haskell-doc The following NEW packages will be installed: happy 0 upgraded, 1 newly installed, 0 to remove and 860 not upgraded. Need to get 528 kB of archives. After this operation, 2,582 kB of additional disk space will be used. Get:1 http://ftp.it.debian.org/debian buster/main armel happy armel 1.19.9-6 [528 kB] Fetched 528 kB in 0s (2,650 kB/s) Selecting previously unselected package happy. (Reading database ... 100743 files and directories currently installed.) Preparing to unpack .../happy_1.19.9-6_armel.deb ... Unpacking happy (1.19.9-6) ... Setting up happy (1.19.9-6) ... Processing triggers for man-db (2.7.6.1-2) ... drakestail:/etc/apt/sources.list.d# gdb -q -ex 'b *(0x1ab0ac)' -ex 'run' -ex 'x/i $pc' -ex 'quit' --args happy example.y Reading symbols from happy...(no debugging symbols found)...done. Breakpoint 1 at 0x1ab0ac Starting program: /usr/bin/happy example.y [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux-gnueabi/libthread_db.so.1". Program received signal SIGILL, Illegal instruction. 0x001addc4 in ?? () => 0x1addc4:uxthr1, r2 A debugging session is active. Inferior 1 [process 13711] will be killed. Quit anyway? (y or n) y Let me know if I can help more. Best, Emanuele On Sun, Jun 16, 2019 at 9:48 PM Paul Gevers wrote: > Hi Emanuele, > > On 16-06-2019 20:25, Emanuele Olivetti wrote: > > I've just followed your instructions, downloaded and installed the > > current happy (and also ghc and the other packages) in the usual way: > > > > dpkg -i > > apt install -f > > > > then tested the example files as indicated: > > > > drakestail:/opt/bug_ghc_armel# gdb -q -ex 'b *(0x1ab0ac)' -ex 'run' > > -ex 'x/i $pc' -ex 'quit' --args happy example.y > > Reading symbols from happy...(no debugging symbols found)...done. > > Breakpoint 1 at 0x1ab0ac > > Starting program: /bin/happy example.y > > [Thread debugging using libthread_db enabled] > > Using host libthread_db library > > "/lib/arm-linux-gnueabi/libthread_db.so.1". > > [Inferior 1 (process 10654) exited normally] > > No registers. > > > > Everything works fine! > > Can you confirm that it *didn't* work with the version in sid/buster on > your system? > > Paul > >
Bug#930630: stretch-pu: package tenshi/0.13-2.1~deb9u1
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
This upload is primarily intended to fix the version ordering violation
introduced by the CVE fix from 2017 in wheezy-lts that only went to sid
(and got unblocked for buster) today:
tenshi | 0.11-2| squeeze | source, all
tenshi | 0.13-2| wheezy | source, all
tenshi | 0.13-2| stretch | source, all
tenshi | 0.13-2| buster | source, all
tenshi | 0.13-2+deb7u1 | wheezy-security | source, all
tenshi | 0.13-2.1 | sid | source, all
This is a rebuild of 0.13-2.1 from sid (which itself was a rebuild of
0.13-2+deb7u1 from wheezy-lts).
The package is already uploaded.
Andreas
diff -Nru tenshi-0.13/debian/changelog tenshi-0.13/debian/changelog
--- tenshi-0.13/debian/changelog2012-02-13 05:30:17.0 +0100
+++ tenshi-0.13/debian/changelog2019-06-16 23:43:59.0 +0200
@@ -1,3 +1,26 @@
+tenshi (0.13-2.1~deb9u1) stretch; urgency=medium
+
+ * Non-maintainer upload.
+ * Rebuild for stretch.
+
+ -- Andreas Beckmann Sun, 16 Jun 2019 23:43:59 +0200
+
+tenshi (0.13-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Upload to unstable.
+ * Drop DMUA.
+
+ -- Andreas Beckmann Sun, 16 Jun 2019 14:24:39 +0200
+
+tenshi (0.13-2+deb7u1) wheezy-security; urgency=high
+
+ * Non-maintainer upload by the Debian LTS team.
+ * Fix CVE-2017-11746: PID file issue allows local users to kill arbitrary
+processes (Closes: #871321)
+
+ -- Lucas Kanashiro Sun, 27 Aug 2017 14:47:19 -0300
+
tenshi (0.13-2) unstable; urgency=low
* debian/init:
diff -Nru tenshi-0.13/debian/control tenshi-0.13/debian/control
--- tenshi-0.13/debian/control 2012-02-10 05:23:20.0 +0100
+++ tenshi-0.13/debian/control 2019-06-16 13:55:10.0 +0200
@@ -2,7 +2,6 @@
Section: admin
Priority: optional
Maintainer: Ignace Mouzannar
-DM-Upload-Allowed: yes
Build-Depends: debhelper (>= 7.0.8)
Standards-Version: 3.9.2
Vcs-Svn: svn://svn.debian.org/collab-maint/ext-maint/tenshi/trunk/
diff -Nru tenshi-0.13/debian/patches/CVE-2017-11746.patch
tenshi-0.13/debian/patches/CVE-2017-11746.patch
--- tenshi-0.13/debian/patches/CVE-2017-11746.patch 1970-01-01
01:00:00.0 +0100
+++ tenshi-0.13/debian/patches/CVE-2017-11746.patch 2017-08-27
19:53:26.0 +0200
@@ -0,0 +1,36 @@
+Description: save PID after forking but before changing privileges
+ This is an adaptation of upstream commit
+ (d0e7f28c13ffbd5888b31d6532c2faf78f10f176) that fixes CVE-2017-11746. It was
+ written by Andrea Barisani.
+Author: Lucas Kanashiro
+Last-Updated: 2017-08-27
+
+--- a/tenshi
b/tenshi
+@@ -122,8 +122,6 @@ if ($listen) {
+
+ $SIG{'CHLD'} = sub { $debug && debug(5,'CHLD') ; print RED "[ERROR] Child
died. Bailing out\n"; $time_to_die = 1; };
+
+-prepare_process();
+-
+ #
+ # sanity checks
+ #
+@@ -242,8 +240,6 @@ if (!($debug || $profile || $foreground)
+ daemonize();
+ }
+
+-save_pid();
+-
+ while (!$time_to_die) {
+ my $now = time;
+
+@@ -963,6 +959,8 @@ sub daemonize {
+ defined(my $pid = fork) or clean_up and die RED "[ERROR] can't fork:
$!\n";
+ exit if $pid;
+ setsid()or clean_up and die RED "[ERROR] can't start
a new session: $!\n";
++save_pid();
++prepare_process();
+ }
+
+ sub save_pid {
diff -Nru tenshi-0.13/debian/patches/series tenshi-0.13/debian/patches/series
--- tenshi-0.13/debian/patches/series 2012-02-10 04:37:37.0 +0100
+++ tenshi-0.13/debian/patches/series 2017-08-26 20:50:46.0 +0200
@@ -1,2 +1,3 @@
10-Makefile.diff
20-manpage.diff
+CVE-2017-11746.patch
Bug#911844: okular: Prints to the wrong printer
On Sun 16 Jun 2019 at 20:30:05 +0300, Dmitry Shachnev wrote: > Hi Michael and all! > > On Sat, Jun 15, 2019 at 11:52:08PM +0200, Michael Weghorn wrote: > > I've investigated a bit and it's not an Okular issue, but one in the Qt > > print dialog with printers that don't have PPD files. It can be > > reproduced e.g. with kate just the same and Brian even mentioned in the > > initial report that qpdfview is affected as well. > > > > The issue has been fixed upstream (qtbase) with the following commit (so > > that's what would have to be backported): > > > > commit 84cc8d0badb4abc3c9a96d59c61dddce916a216c > > Author: Albert Astals Cid > > Date: Mon Feb 5 09:20:20 2018 +0100 > > > > cups: Support raw printers > > > > They don't have a ppd but we don't *really* need a ppd to just > > print > > > > Change-Id: Idf6b6dafc19420a511b057194488e2170cae4d70 > > Thanks a lot for finding the commit which fixes this bug! > > I have uploaded a new version of qtbase to unstable today, which has > it backported. > > Can you please test that it really fixes the bug for you? If yes, > I will file an unblock request for this upload. > > > This probably also fixes #911702, but I didn't test that explicitly. > > If someone tests that too, it would also be nice. A couple of quick tests and it seems to me that #911844 and #911702 have been fixed with this upload. Regards, Brian.
Bug#930294: Nautilus slow to respond and consumes 100% CPU resource
On 2019-06-14, Vikram Vincent wrote: > Nautilus found files with duplicate filenames in some libreoffice templates in > the Templates folder and was looping on that. The moment I deleted the > content, nautilus behaviour came back to normal. What kind of documents and what filenames? I'm still unable to reproduce the issue after adding a few files to my Templates folder.
Bug#930005: regina-rexx: rexxutil error
Followup-For: Bug #930005
Control: tag -1 patch
The attached patch fixes the linking issue and thus the missing tgetent
symbol. Thereafter the command
regina /usr/share/doc/regina-rexx/examples/regutil.rexx
works on i386, but segfaults on amd64.
Andreas
diff -Nru regina-rexx-3.6/debian/changelog regina-rexx-3.6/debian/changelog
--- regina-rexx-3.6/debian/changelog2017-03-05 15:40:23.0 +0100
+++ regina-rexx-3.6/debian/changelog2019-06-16 14:43:34.0 +0200
@@ -1,3 +1,12 @@
+regina-rexx (3.6-2.2) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * configure: Ensure the value of REGUTIL_TERM_LIB gets into the Makefile
+s.t. we actually link against the library providing tgetent().
+(Closes: #930005)
+
+ -- Andreas Beckmann Sun, 16 Jun 2019 14:43:34 +0200
+
regina-rexx (3.6-2.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru regina-rexx-3.6/debian/patches/az-patch-01
regina-rexx-3.6/debian/patches/az-patch-01
--- regina-rexx-3.6/debian/patches/az-patch-01 2012-06-30 15:21:18.0
+0200
+++ regina-rexx-3.6/debian/patches/az-patch-01 2019-06-16 14:43:34.0
+0200
@@ -10,8 +10,8 @@
Forwarded: not-needed
Bug-Debian: http://bugs.debian.org/661883
regina-rexx-3.6.orig/Makefile.in
-+++ regina-rexx-3.6/Makefile.in
+--- a/Makefile.in
b/Makefile.in
@@ -41,7 +41,7 @@ INSTALL = $(srcdir)/install-sh
CC = @CC@
RANLIB = @RANLIB@
@@ -21,6 +21,15 @@
LDFLAGS = @LDFLAGS@
RANLIB_DYNAMIC = @RANLIB_DYNAMIC@
+@@ -124,7 +124,7 @@ REGINAEXP = @REGINAEXP@
+ RPMTOPDIR = @RPMTOPDIR@
+ HAVE_GCI = @HAVE_GCI@
+ GCI_CONVERT_HEADER = @GCI_CONVERT_HEADER@
+-#REGUTIL_TERM_LIB=@REGUTIL_TERM_LIB@
++REGUTIL_TERM_LIB=@REGUTIL_TERM_LIB@
+
+ MISCDEFS = -DHAVE_CONFIG_H $(HAVE_GCI) $(TRACEMEM) $(FLISTS) -I. -I$(srcdir)
-I$(srcdir)/contrib $(SYS_DEFS) $(REXXSOCKET)
+ LARGE_FILE_SUPPORT = @LARGE_FILE_SUPPORT@
@@ -285,7 +285,8 @@ ZIP_CFILES = $(ZIP_CSRCFILES) yaccsrc.c
DEBIANFILES = $(DEBIAN_DIR)/rules $(DEBIAN_DIR)/control
$(DEBIAN_DIR)/changelog $(DEBIAN_DIR)/md5_sums \
$(DEBIAN_DIR)/postinst $(DEBIAN_DIR)/postrm $(DEBIAN_DIR)/postrm-dev
$(DEBIAN_DIR)/copyright
@@ -96,9 +105,17 @@
$(INSTALL) -c -m 644 $(srcdir)/regina-config.1
$(prefix)/share/man/man1/regina-config.1
install-rexx: rexx$(EXE) regina$(EXE)
regina-rexx-3.6.orig/configure
-+++ regina-rexx-3.6/configure
-@@ -3445,7 +3445,7 @@ case "$target" in
+--- a/configure
b/configure
+@@ -690,6 +690,7 @@ EFENCE
+ PURIFY
+ DEBUGGING
+ DEBUG
++REGUTIL_TERM_LIB
+ FNMATCH_TSO
+ FNMATCH_SHO
+ FNMATCH
+@@ -3445,7 +3446,7 @@ case "$target" in
;;
*linux*|*kfreebsd*-gnu*)
mach="`uname -m`"
@@ -107,7 +124,7 @@
bitflag="64"
osis64bit=yes
fi
-@@ -8455,7 +8455,7 @@ case "$target" in
+@@ -8455,7 +8456,7 @@ case "$target" in
LD_RXLIB_B2="${SHLPRE}${SHLFILE}${SHLPST}.\$(ABI)"
LD_RXLIB_UTILB="${SHLPRE}${SHLFILE}${SHLPST}.\$(ABI)"
SHLPRE="lib"
@@ -116,9 +133,8 @@
SHL_BASE="${SHLPRE}${SHLFILE}${SHLPST}.\$(ABI)"
OTHER_INSTALLS="installabilib"
USE_ABI="yes"
-
regina-rexx-3.6.orig/regina.1
-+++ regina-rexx-3.6/regina.1
+--- a/regina.1
b/regina.1
@@ -60,13 +60,13 @@ Sets tracing of the program to the optio
commands in the program will be ignored.
If you want to run your program with tracing set to "Intermediate",
@@ -253,3 +269,13 @@
.SH See Also
There are several good reference books on Rexx. The most famous is
+--- a/configure.in
b/configure.in
+@@ -249,6 +249,7 @@ if test "$REGUTIL_TERM_LIB" = "none requ
+ REGUTIL_TERM_LIB=""
+ fi
+ LIBS="$save_LIBS"
++AC_SUBST(REGUTIL_TERM_LIB)
+
+ save_LIBS="$LIBS"
+
AC_SEARCH_LIBS(crypt,crypt,REGINA_CRYPT_LIB="$ac_cv_search_crypt",REGINA_CRYPT_LIB="")
Bug#930587: release-notes: fails to build for jessie and stretch
Hi!
On Sun, 2019-06-16 at 14:40:53 +0800, Wenbin Lv wrote:
> Package: release-notes
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> Recent transition from .dbk to .po for the ca language leaves some
> untracked .dbk files in the source directory and causes git checkout of
> jessie and stretch to fail in the build system of the Debian website,
> showing the following errors[1]:
>
> rebuilding the release notes for {jessie,stretch}
> error: The following untracked working tree files would be overwritten by
> checkout:
> ca/about.dbk
> ca/installing.dbk
> ca/issues.dbk
> ca/moreinfo.dbk
> ca/old-stuff.dbk
> ca/release-notes.dbk
> ca/upgrading.dbk
> ca/whats-new.dbk
This looks like a bug in the website build machinery? These files are
left behind in the same way they are for all other languages. The
difference is that they got switched very recently.
I'm assuming from your description that the website machinery, does a
git checkout on each specific branch and then builds it, but is not
running «make clean» before each git checkout?
> which causes buster version of the release notes to be built for jessie
> and stretch[2][3].
Right!
> Please remove the untracked files to fix the issue.
I don't think there is nothing to fix in the release-notes package
itself. This sould probably be reassigned.
Thanks,
Guillem
Bug#930628: flang-7: Flang-7 20190329-1 Does Not See Its Standard Modules
Package: flang-7 Version: 20190329-1 Severity: important Dear Maintainer, A program which uses iso_fortran_env fails to compile using the 20190329-1 build of flang-7 because flang cannot find the module: flang -Ifortran_characters@exe -I. -I.. -Xclang -fcolor-diagnostics -pipe -D_FILE_OFFSET_BITS=64 -Minform=inform -O3 -march=native -fstack-protector-strong -std=f2003 -module fortran_characters@exe -o 'fortran_characters@exe/globals.f90.o' -c ../globals.f90 F90-F-0004-Unable to open MODULE file iso_fortran_env.mod (../globals.f90: 2) F90/x86-64 Linux Flang - 1.5 2017-05-01: compilation aborted The same program compiles successfully using the 20181226-2 build of flang-7. The problem can be worked around by adding this compiler option: -I /usr/lib/x86_64-linux-gnu/fortran/flang-mod-34 In the upgrade from 20181226-2 to 20190329-1 the *.mod files moved from a subdirectory flang-mod-33 to flang-mod-34. Does something need to be updated in flang-7 to adjust the default module search path? -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/2 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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages flang-7 depends on: ii libc6 2.28-10 ii libflang-dev 20190329-1 ii libflang0d-7 20190329-1 ii libgcc1 1:8.3.0-7 ii libllvm7 1:7.0.1-8 ii libomp-7-dev 1:7.0.1-8 ii libstdc++68.3.0-7 flang-7 recommends no packages. flang-7 suggests no packages. -- no debconf information
Bug#930629: can't recognize arbitrary text files (eg. Markdown or reStructuredText)
Package: sloccount
Version: 2.26-5.2
Severity: wishlist
Tags: upstream
Hi,
it would be great if the program would be able to handle arbitrary text
files and allow parser specification for them. I am specifically
interested in having support for the usual documentation stuff like
Markdown (".md") and reStructuredText (".rst"), but would also
appreciate if things like SASS (".sass") would be handled.
Kind regards,
Toni
-- System Information:
Debian Release: 10.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable'), (70, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-5-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE, TAINT_SOFTLOCKUP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages sloccount depends on:
ii libc6 2.28-10
ii perl 5.28.1-6
sloccount recommends no packages.
Versions of packages sloccount suggests:
pn doc-base
-- no debconf information
Bug#930569: debian-installer: Dark theme installer selects MATE by default
Hi,
Yevgen wrote:
> Yes, I tried it few times (with the same iso) on VirtualBox 6.06.
> I can try it again but please tell me which ISO should I use.
>
> On Sat, Jun 15, 2019 at 9:31 PM Steve McIntyre wrote:
>
> > On Sat, Jun 15, 2019 at 08:12:18PM +0300, Evgen wrote:
> > >Package: debian-installer
> > >Version: 20190410
> > >Severity: important
> > >
> > >Dear Maintainer,
> > >
> > >I tried to install system with firmware-testing-amd64-n
> > >etinst.iso
> > >from unofficial "non-free" weekly cd (2019-06-10 07:12)
> > >I chosed Dark theme installer menu > Graphical Install
> > >
> > >On "Software selection" there were 2 check-boxes:
> > >1. on the "Debian desktop environment"
> > >2. on the "...MATE"
> > >
> > >Old/light Graphical Installer still has checkbox
> > >only on the "Debian desktop environment"
> >
> > Odd... There's literally nothing I can see in the config for the dark
> > theme menu that would change the default desktop selection. For
> > today's build of that image, the isolinux menu is:
> >
> > label installdarkgui
> > default installdarkgui
> > menu label ^Graphical install
> > menu default
> > kernel /install.amd/vmlinuz
> > append vga=788 initrd=/install.amd/gtk/initrd.gz theme=dark ---
> > quiet
> >
> > and the Grub menu entry (used for EFI boot) says:
> >
> > menuentry --hotkey=g '... Graphical install' {
> > set background_color=black
> > linux/install.amd/vmlinuz vga=788 theme=dark --- quiet
> > initrd /install.amd/gtk/initrd.gz
> > }
> >
> > Can you reliably reproduce what you've seen?
I did a test installation yesterday (my main goal was a different one,
but I watched the tasksel screen too).
I installed with the buster-rc1 netinst CD image, and had the dark theme
enabled.
And default selection was:
On "Software selection" there were 2 check-boxes:
1. on the "Debian desktop environment"
2. on the "...MATE"
So everything fine.
Holger
--
Holger Wansing
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#930627: Missing from Buster
Hi, On Sun, Jun 16, 2019 at 03:27:18PM -0500, Michael Reed wrote: > Package: claws-mail-fancy-plugin > Version: > > > claws-mail-fancy-plugin is not in Buster. This was removed due to #790199. At this point in time reintroduction in buster is not possible anymore. Regards, Salvatore
Bug#928111: [pre-approval] unblock: icu/63.2-1
Hi Paul,
On Sun, Jun 16, 2019 at 9:50 PM Paul Gevers wrote:
> On 16-06-2019 11:20, László Böszörményi (GCS) wrote:
> > The debdiff is larger for the following changes. The backported
> > security fixes are no longer under debian/patches but inline. The ABI
> > break, called the 'ICU-20250' issue upstream is reversed with a patch.
> > Then the s/63.1/63.2/ changes, etc.
>
> Can you please provide a diff between the patches-applied tree of the
> current buster version and a patches-applied tree of the current sid
> version?
Of course, attached. The diff size went down from 165 kB to 39 kB as
you see, even if the documentation and s/63.1/63.2/ changes are still
in as well.
Regards,
Laszlo/GCS
diff -Nur icu-63.1/readme.html icu-63.2/readme.html
--- icu-63.1/readme.html 2018-10-15 18:02:37.0 +
+++ icu-63.2/readme.html 2019-04-11 22:38:30.0 +
@@ -3,7 +3,7 @@
http://www.w3.org/1999/xhtml; xml:lang="en-US">
-ReadMe for ICU 63.1
+ReadMe for ICU 63.2
http://www.unicode.org/copyright.html"/>
diff -Nur icu-63.1/source/common/umutablecptrie.cpp icu-63.2/source/common/umutablecptrie.cpp
--- icu-63.1/source/common/umutablecptrie.cpp 2018-10-01 22:39:56.0 +
+++ icu-63.2/source/common/umutablecptrie.cpp 2019-06-16 20:23:58.0 +
@@ -60,6 +60,7 @@
constexpr int32_t INDEX_3_18BIT_BLOCK_LENGTH = UCPTRIE_INDEX_3_BLOCK_LENGTH + UCPTRIE_INDEX_3_BLOCK_LENGTH / 8;
class AllSameBlocks;
+class MixedBlocks;
class MutableCodePointTrie : public UMemory {
public:
@@ -92,8 +93,10 @@
void maskValues(uint32_t mask);
UChar32 findHighStart() const;
int32_t compactWholeDataBlocks(int32_t fastILimit, AllSameBlocks );
-int32_t compactData(int32_t fastILimit, uint32_t *newData, int32_t dataNullIndex);
-int32_t compactIndex(int32_t fastILimit, UErrorCode );
+int32_t compactData(
+int32_t fastILimit, uint32_t *newData, int32_t newDataCapacity,
+int32_t dataNullIndex, MixedBlocks , UErrorCode );
+int32_t compactIndex(int32_t fastILimit, MixedBlocks , UErrorCode );
int32_t compactTrie(int32_t fastILimit, UErrorCode );
uint32_t *index = nullptr;
@@ -548,28 +551,8 @@
}
}
-inline bool
-equalBlocks(const uint32_t *s, const uint32_t *t, int32_t length) {
-while (length > 0 && *s == *t) {
-++s;
-++t;
---length;
-}
-return length == 0;
-}
-
-inline bool
-equalBlocks(const uint16_t *s, const uint32_t *t, int32_t length) {
-while (length > 0 && *s == *t) {
-++s;
-++t;
---length;
-}
-return length == 0;
-}
-
-inline bool
-equalBlocks(const uint16_t *s, const uint16_t *t, int32_t length) {
+template
+bool equalBlocks(const UIntA *s, const UIntB *t, int32_t length) {
while (length > 0 && *s == *t) {
++s;
++t;
@@ -585,36 +568,6 @@
}
/** Search for an identical block. */
-int32_t findSameBlock(const uint32_t *p, int32_t pStart, int32_t length,
- const uint32_t *q, int32_t qStart, int32_t blockLength) {
-// Ensure that we do not even partially get past length.
-length -= blockLength;
-
-q += qStart;
-while (pStart <= length) {
-if (equalBlocks(p + pStart, q, blockLength)) {
-return pStart;
-}
-++pStart;
-}
-return -1;
-}
-
-int32_t findSameBlock(const uint16_t *p, int32_t pStart, int32_t length,
- const uint32_t *q, int32_t qStart, int32_t blockLength) {
-// Ensure that we do not even partially get past length.
-length -= blockLength;
-
-q += qStart;
-while (pStart <= length) {
-if (equalBlocks(p + pStart, q, blockLength)) {
-return pStart;
-}
-++pStart;
-}
-return -1;
-}
-
int32_t findSameBlock(const uint16_t *p, int32_t pStart, int32_t length,
const uint16_t *q, int32_t qStart, int32_t blockLength) {
// Ensure that we do not even partially get past length.
@@ -655,30 +608,9 @@
* Look for maximum overlap of the beginning of the other block
* with the previous, adjacent block.
*/
-int32_t getOverlap(const uint32_t *p, int32_t length,
- const uint32_t *q, int32_t qStart, int32_t blockLength) {
-int32_t overlap = blockLength - 1;
-U_ASSERT(overlap <= length);
-q += qStart;
-while (overlap > 0 && !equalBlocks(p + (length - overlap), q, overlap)) {
---overlap;
-}
-return overlap;
-}
-
-int32_t getOverlap(const uint16_t *p, int32_t length,
- const uint32_t *q, int32_t qStart, int32_t blockLength) {
-int32_t overlap = blockLength - 1;
-U_ASSERT(overlap <= length);
-q += qStart;
-while (overlap > 0 && !equalBlocks(p + (length - overlap), q, overlap)) {
---overlap;
-}
-return overlap;
-}
-
-int32_t getOverlap(const uint16_t *p, int32_t length,
- const uint16_t *q, int32_t qStart, int32_t blockLength) {
Bug#930627: Missing from Buster
Package: claws-mail-fancy-plugin Version: claws-mail-fancy-plugin is not in Buster.
Bug#930626: twisted: CVE-2019-12855
Source: twisted Version: 18.9.0-3 Severity: important Tags: security upstream Forwarded: https://twistedmatrix.com/trac/ticket/9561 Hi, The following vulnerability was published for twisted. CVE-2019-12855[0]: | In words.protocols.jabber.xmlstream in Twisted through 19.2.1, XMPP | support did not verify certificates when used with TLS, allowing an | attacker to MITM connections. 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-12855 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12855 [1] https://twistedmatrix.com/trac/ticket/9561 [2] https://github.com/twisted/twisted/pull/1147 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#865975: docker.io changes iptables default FORWARD policy to DROP, breaks VM and others
Control: severity -1 normal On Tue, Jun 11, 2019 at 6:09 PM Shengjing Zhu wrote: > > Hi, > > I checked more carefully on https://github.com/moby/moby/pull/28257 > and https://github.com/moby/moby/issues/14041 > Then I concluded that docker does nothing wrong in this case. > [...] With the reason I explained last week, I would downgrade this issue. Arnaud, when you upload new version for the CVE issue, could you amend the README.Debian to tell people that if they don't want docker to set default FORWARD policy to DROP, they should enable ip_forward intentionally. (I bet your english is better than me to draft a phrase...) -- Shengjing Zhu
Bug#930625: dose-deb-coinstall wrongly handles :any
Package: dose-extra Version: 5.0.1-12 File: /usr/bin/dose-deb-coinstall $ cat pkg Package: a Architecture: amd64 Multi-Arch: same Version: 0 Package: b Architecture: amd64 Depends: a:any (>= 1) Version: 0 Package: build-essential Architecture: all Version: 0 $ dose-deb-coinstall --deb-native-arch=amd64 --fg=pkg --bg=pkg Package: build-essential Version: 0 Architecture: all Multi-Arch: no Package: a Version: 0 Architecture: amd64 Multi-Arch: same Package: b Version: 0 Architecture: amd64 Multi-Arch: no Depends: a:any (>= 1) $ echo $? 0 $ This is wrong, because package a has version 0, but the version constraint on the dependency is >= 1. This combination should yield a failure. $ cat src Package: c Build-Depends: a:any Version: 0 Architecture: any $ dose-builddebcheck --deb-native-arch=amd64 --successes --explain pkg src output-version: 1.2 native-architecture: amd64 report: - package: c version: 0 architecture: any type: src status: ok installationset: - package: c version: 0 architecture: any type: src - package: a version: 0 architecture: amd64 - package: build-essential version: 0 architecture: all binary-packages: 4 source-packages: 1 broken-packages: 0 $ This is also wrong. For Build-Depends, resolution is stricter and disallows :any annotations on packages not marked M-A:allowed entirely. Helmut
Bug#929781: rkt: CVE-2019-10144 CVE-2019-10145 CVE-2019-10147
On Sun, Jun 16, 2019 at 11:47 PM Shengjing Zhu wrote: > So I would suggest we remove rkt from buster. > Which means the acbuild and nomad(build-rdepends) will also be removed. For acbuild, it is also discontinued by upstream[1]. For nomad, you can disable the rkt driver, by patching client/driver/driver.go. But this should go through a unblock process. [1] https://github.com/containers/build -- Shengjing Zhu
Bug#928111: [pre-approval] unblock: icu/63.2-1
Hi László, On 16-06-2019 11:20, László Böszörményi (GCS) wrote: > The debdiff is larger for the following changes. The backported > security fixes are no longer under debian/patches but inline. The ABI > break, called the 'ICU-20250' issue upstream is reversed with a patch. > Then the s/63.1/63.2/ changes, etc. Can you please provide a diff between the patches-applied tree of the current buster version and a patches-applied tree of the current sid version? Thanks. Paul signature.asc Description: OpenPGP digital signature
Bug#929907: implications for libgnutls-openssl27?
See below. On Sat, Jun 15, 2019 at 9:42 PM Andreas Metzler wrote: > > On 2019-06-15 Ross Boylan wrote: > > I've been following this bug because it came up as an issue for a > > security upgrade to libgnutls-openssl27 in buster. I'm still seeing > > 3.6.7-3 as the upgrade target. > > Hello Ross, > > I do not know whether this bug applies to packages using GnuTLS via the > openssl wrapper library. There aren't a lot of rdepends, and the wrapper > is thin and does not expose the complete functionality. > > > Will an openssl27 variant be coming? Or perhaps this problem never > > applied to -openssl27 and apt-listbugs just got over-eager? > > If the bug applies to libgnutls-openssl27 it will be fixed exactly when > the underlying libgnutls is fixed. There is no separate step involved, > it is just a wrapper. > > > I came > > here for ..ssl27; the original report is for ..ssl28; > > Where? I was going to upgrade libgnutls-openssl27 and apt-listbugs listed this bug as a critical one. https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=libgnutls-openssl27;dist=unstable identifies the source package as gnutls28 (sorry--no ssl in there), and apt-listbugs must have been reporting all bugs in the source package. The original bug report identifies libgnutls30 as the (presumably binary) package in which the bug is found. > > > the package the > > bug is filed against is apparently ..ssl30. The versioning is a bit > > mysterious to me :) > > It is pretty mch straightforward, when the ABI breaks we bump the > soname. ;-) I meant it was mysterious why all these different ABI versions are ending up together in the bug system. I think I've figured that out: they all are from the same source package. The libgnutls-openssl27 I would install now depends on libgnutls30 version 3.6.7-3. Currently installed libgnutls30 is 3.6.6-2. So it sounds as if I should wait til gnutls30 3.6.7-4 appears before doing the upgrade. Or maybe the security problem is serious enough to warrant an upgrade now? TLS is likely to matter to me only as a client. Ross
Bug#928882: unblock: [pre-approval] ghc/8.4.4+dfsg1-3
Hi Emanuele, On 16-06-2019 20:25, Emanuele Olivetti wrote: > I've just followed your instructions, downloaded and installed the > current happy (and also ghc and the other packages) in the usual way: > > dpkg -i > apt install -f > > then tested the example files as indicated: > > drakestail:/opt/bug_ghc_armel# gdb -q -ex 'b *(0x1ab0ac)' -ex 'run' > -ex 'x/i $pc' -ex 'quit' --args happy example.y > Reading symbols from happy...(no debugging symbols found)...done. > Breakpoint 1 at 0x1ab0ac > Starting program: /bin/happy example.y > [Thread debugging using libthread_db enabled] > Using host libthread_db library > "/lib/arm-linux-gnueabi/libthread_db.so.1". > [Inferior 1 (process 10654) exited normally] > No registers. > > Everything works fine! Can you confirm that it *didn't* work with the version in sid/buster on your system? Paul signature.asc Description: OpenPGP digital signature
Bug#924445: pulseaudio crashes randomly, no diagnostic on terminal, possibly associated with Wesnoth
Sorry for the long delay; looks like my spam filter ate the last reply. Now looks like this on startup: W: [pulseaudio] authkey.c: Failed to open cookie file '/home/joshua/.config/pulse/cookie': No such file or directory W: [pulseaudio] authkey.c: Failed to load authentication key '/home/joshua/.config/pulse/cookie': No such file or directory W: [pulseaudio] authkey.c: Failed to open cookie file '/home/joshua/.config/pulse/cookie': No such file or directory W: [pulseaudio] authkey.c: Failed to load authentication key '/home/joshua/.config/pulse/cookie': No such file or directory E: [pulseaudio] module-console-kit.c: GetSessionsForUnixUser() call failed: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.ConsoleKit was not provided by any .service files E: [pulseaudio] module.c: Failed to load module "module-console-kit" (argument: ""): initialization failed. pactl info now reports: Server String: /tmp/pulse-ddOQt3aAAhE4/native Library Protocol Version: 32 Server Protocol Version: 32 Is Local: yes Client Index: 0 Tile Size: 65472 User Name: joshua Host Name: nova Server Name: pulseaudio Server Version: 12.2 Default Sample Specification: s16le 2ch 44100Hz Default Channel Map: front-left,front-right Default Sink: alsa_output.pci-_00_1b.0.analog-stereo Default Source: alsa_output.pci-_00_1b.0.analog-stereo.monitor Cookie: [snip]
Bug#930597: unblock: pikepdf/1.0.5+dfsg-3 -- redux
control: tag -1 -moreinfo Hello, On Sun 16 Jun 2019 at 04:23PM +02, Ivo De Decker wrote: > OK. Please remove the moreinfo tag from this bug once the upload is ready to > be unblocked. Done. >> (I guess with version number 1.0.5+dfsg-2+deb10u1 ?) > > No. For a rebuild of 1.0.5+dfsg-3, the preferred version is > 1.0.5+dfsg-3~deb10u1 (with the changelog entry for 1.0.5+dfsg-3 also in the > changelog). For patches on top of 1.0.5+dfsg-2 (but not a rebuild of a newer > version), the version would have been 1.0.5+dfsg-2+deb10u1, as you suggested. > Please set the distribution in the changelog to 'buster' (not 'testing' or > 'testing-proposed-updates'). Thanks for the info & the reminder! -- Sean Whitton signature.asc Description: PGP signature
Bug#930519: missing versioned dependencies
On Sat, Jun 15, 2019 at 07:30:12PM +0200, Andreas Metzler wrote:
> On 2019-06-14 Marc Haber wrote:
> there are some semi-strict dependencies:
> exim4 requires exim4-base from the same Debian source version and one
>of the daemon packages (unversioned)
> The daemon packages require exim4-base of at least the same upstream
>version.
> exim4-base requires exim4-config and Breaks daemon packages of older
>upstream versions.
>
> So what we currently have is that exim4, -base, and -daemon-* share the
> same upstream version and exim4 and -base are built from the same source
> (not the same binNMU).
Yes, that means that only updating exim4 will not pull the daemon.
> You are suggesting to version the exim4 -> daemon dependency like this
> Depends: exim4-daemon-light (>= ${source:Version}) |
> exim4-daemon-heavy (>= ${source:Version}) |
> exim4-daemon-custom (>= ${source:Version})
Yes.
> I see two possible downsides:
> * Theoretically a dumb dependency-resolver might break upgrades,
> choosing the first alternative instead of checking whether upgrading
> everything fullfills the dependency. I think we can discount this.
> * The -daemon-custom situation. I think the main reason why the
> dependencies are as they are is to not enforce a rebuild of
> exim4-daemon-custom for minor (i.e. Debian-revision) changes. This
> made a lot of sense when the packaging changed a lot, i.e. there were
> many uploads that would have produced the same -daemon-custom.
> Nowadays almost every upload includes a new patch from -fixes so it
> might make sense to change this,
I think that the usage of the -custom stuff is infinitesimally small.
Heck, even I stopped doing this years ago. People doing this will most
probably follow security themselves, and since they're building
themselves anyway, can relax the versioned dependencies.
> PS: FWIW I do not think the original argument (I did "apt get install
> exim4" and am still CVE-xxx vulnerable) is a weak one. Linux packages
> often and for a long time have split upstream sources into multiple
> binaries. Therefore selective upgrades by "apt-get install somebinary
> would often be incomplete. You'll either need to read every DSA en
> detail and manually compare the list of upgraded/fixed packages with
> installed list or or just do "apt-get upgrade".
I do agree that the original issue is mainly a user error (the advisory
says "update your exim4 packages" (plural)). I am wondering whether we
can something to leverage for stupid users.
Greetings
Marc
--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#930624: kxmlgui FTCBFS: missing Build-Depends: qttools5-dev
Source: kxmlgui Version: 5.54.0-1 Tags: pending kxmlgui fails to cross build from source. This is fixed in git: https://salsa.debian.org/qt-kde-team/kde/kxmlgui/commit/5ca788fe1796c727ba224e73779f3372ed0c3e67 Please close this bug with the next upload to trigger a qa rebuild. Helmut
Bug#929781: rkt: CVE-2019-10144 CVE-2019-10145 CVE-2019-10147
Hi, On Sun, Jun 16, 2019 at 11:47:16PM +0800, Shengjing Zhu wrote: > Hi Dmitry, > > Upstream doesn't have any update for these 3 CVE for more than 2 > weeks(after the CVE published). > > So I'm afraid that rkt is longer maintained, with 2 other concerns: > > 1. Most commits since 2019 are about typo/documents. > 2. Coreos(the company who creates rkt) has been acquired by RedHat. > And RedHat has more interests in other container related tools, like > podman. Although rkt is now hosted by CNCF, but it doesn't attract > more contributors. > > So I would suggest we remove rkt from buster. I would tend to agree here and not include rkt for buster. Actually due to this bug in normal cirumstances it would be (auto)removed. But it will trigger only after the buster release in this case, so release team might remove it earlier. Regards, Salvatore
Bug#929962: chrony: "systemctl start chrony" starts chronyd, then kills it because systemd-tty-ask-password-agent times out
Hello, On Tue, Jun 04, 2019 at 02:10:12PM +0200, Vincent Blut wrote: Control: tags -1 moreinfo Hi, On Tue, Jun 04, 2019 at 01:10:49PM +0200, root wrote: Package: chrony Version: 3.0-4+deb9u2 Severity: important Dear Maintainer, * What led up to the situation? Installing Raspian via NOOBS, updating to latest packages. Install gpsd, chrony. Configure chrony. Try to start chrony using "systemctl start chrony" Are you able to reproduce this issue on a pure Debian system? It might be specific to Raspbian. * What exactly did you do (or not do) that was effective (or ineffective)? Tried to get rid of systemd-tty-ask-password-agent. But this did not help in any way. * What was the outcome of this action? chronyd is started. "systemctl start chrony" waits until it times out on waiting for "/bin/systemd-tty-ask-password-agent --watch" to finish. chronyd is shut down by systemctl. Could you please show the output of the `systemctl status chrony.service' and `journalctl -u chrony.service' commands? Any update on this? Cheers, Vincent signature.asc Description: PGP signature
Bug#921210: kerneloops.service: ExecStartPre uses non-existent --test option
Hi Paul, Paul Wise ezt írta (időpont: 2019. jún. 16., V, 3:55): > > On Sat, 2019-06-15 at 17:01 +0200, Bálint Réczey wrote: > > > Thanks for the bug report, I have committed the fix to Salsa: > > https://salsa.debian.org/debian/kerneloops > > Thanks. Could you try to get this into buster? If you don't think the > release team would accept it right now, then please try to get it into > the first point release. Process leaks like this are annoying. I'm sorry, I don't plan targeting Buster before the release considering that kerneloops has questionable utility right now. The kerneloops server accepts the reports but the public web UI is down for almost two years thus the reports are not browseable. The popularity of the package is also fading: https://qa.debian.org/popcon.php?package=kerneloops When the web UI is up again I may consider backporting this fix, but I won't stop anyone from doing it even earlier. In the short term I plan packaging a new snapshot and uploading that to unstable. Cheers, Balint > > https://lists.debian.org/msgid-search/30371584-e104-edcf-32cb-5d3668217...@thykier.net > https://release.debian.org/buster/freeze_policy.html > > -- > bye, > pabs > > https://wiki.debian.org/PaulWise >
Bug#930623: dbus-python: annotate test dependencies with
Source: dbus-python Version: 1.2.8-3 Tags: patch User: debian-cr...@lists.debian.org Usertags: cross-satisfiability Please annotate test Build-Depends with . Doing so improves cross building (as they are unsatisfiable) and bootstrapping (fewer dependencies always help). Please consider applying the attached patch. Helmut diff --minimal -Nru dbus-python-1.2.8/debian/changelog dbus-python-1.2.8/debian/changelog --- dbus-python-1.2.8/debian/changelog 2019-01-29 09:49:02.0 +0100 +++ dbus-python-1.2.8/debian/changelog 2019-06-16 20:15:39.0 +0200 @@ -1,3 +1,10 @@ +dbus-python (1.2.8-3.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Annotate test Build-Depends with . (Closes: #-1) + + -- Helmut Grohne Sun, 16 Jun 2019 20:15:39 +0200 + dbus-python (1.2.8-3) unstable; urgency=medium [ Ondřej Nový ] diff --minimal -Nru dbus-python-1.2.8/debian/control dbus-python-1.2.8/debian/control --- dbus-python-1.2.8/debian/control2019-01-29 09:49:02.0 +0100 +++ dbus-python-1.2.8/debian/control2019-06-16 20:15:06.0 +0200 @@ -20,11 +20,11 @@ python-all-dbg (>= 2.7), python-all-dev (>= 2.7), python-gi, - python-tap, + python-tap , python3-all-dbg, python3-all-dev, python3-gi, - python3-tap, + python3-tap , sphinx-common, xmlto, Build-Depends-Indep:
Bug#928882: unblock: [pre-approval] ghc/8.4.4+dfsg1-3
Dear Ililas and Paul,
Thank you for your great work.
I've just followed your instructions, downloaded and installed the current
happy (and also ghc and the other packages) in the usual way:
dpkg -i
apt install -f
then tested the example files as indicated:
drakestail:/opt/bug_ghc_armel# gdb -q -ex 'b *(0x1ab0ac)' -ex 'run' -ex
'x/i $pc' -ex 'quit' --args happy example.y
Reading symbols from happy...(no debugging symbols found)...done.
Breakpoint 1 at 0x1ab0ac
Starting program: /bin/happy example.y
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/arm-linux-gnueabi/libthread_db.so.1".
[Inferior 1 (process 10654) exited normally]
No registers.
Everything works fine!
Please find attached the resulting example.hs.
Moreover "objdump -d /bin/happy |grep uxth" returns nothing, as expected.
Hashes of the downloaded files:
drakestail:/opt/bug_ghc_armel# sha256sum *.deb example.*
5d8dae44d79545aeee34755baa6c51ffe80db8309051978aaa9ac8857d6efde9
ghc_8.4.4+dfsg1-2+armel0_armel.deb
bffaf0957deb767d75e251f92dd8a59c6277c5b986241219fbb26ea3400284fa
ghc-doc_8.4.4+dfsg1-2+armel0_all.deb
8fde49d87ad410ae5fec77ac89af4da11f4a2dd0924f0085a2f5f9c6e93fc09c
ghc-prof_8.4.4+dfsg1-2+armel0_armel.deb
c560c02e7369c08de18f7151bcb53245a1c7f4ab83e9c07265beef7ca0e24921
happy_1.19.9-6+armel0_armel.deb
499108b544ad71ae4e801d05910dbc46b6701bac9f33eba5f58ab68f92541a58
example.hs
7b2f0a55e15e3db4188cde1410b1b21bcefeb092b2bc2f44bc95612bf7c60457
example.y
Thanks again,
Emanuele
On Sat, Jun 15, 2019 at 10:46 AM Paul Gevers wrote:
> Hi Emanuel,
>
> On 14-06-2019 18:07, Ilias Tsitsimpis wrote:
> > I have uploaded both ghc and happy here, in case you need Emanuele to
> > verify that the current version of happy fails, whereas the new one
> > works:
> >
> > https://www.iliastsi.net/ghc/ghc_8.4.4+dfsg1-2+armel0_armel.deb
> > sha256:
> 5d8dae44d79545aeee34755baa6c51ffe80db8309051978aaa9ac8857d6efde9
> > https://www.iliastsi.net/ghc/ghc-doc_8.4.4+dfsg1-2+armel0_all.deb
> > sha256:
> bffaf0957deb767d75e251f92dd8a59c6277c5b986241219fbb26ea3400284fa
> > https://www.iliastsi.net/ghc/ghc-prof_8.4.4+dfsg1-2+armel0_armel.deb
> > sha256:
> 8fde49d87ad410ae5fec77ac89af4da11f4a2dd0924f0085a2f5f9c6e93fc09c
> > https://www.iliastsi.net/ghc/happy_1.19.9-6+armel0_armel.deb
> > sha256:
> c560c02e7369c08de18f7151bcb53245a1c7f4ab83e9c07265beef7ca0e24921
>
> Could you please do the check that Ilias proposes? I.e. install the
> current happy and run it on the example code and see that it fails.
> Install the package from Ilias and see that it works?
>
> > So, it seems that the proposed patch does indeed resolve the issue.
>
> I agree with you, however I'd like to see the results of the check by
> Emanuele.
>
> > Unfortunately, I cannot provide any guarantee that it will not introduce
> > any bugs that weren't there before, but I believe the only way to find
> > out is to upload a fixed version of GHC on unstable and schedule the
> > required binNMUs. If all of them succeed, we can then unblock them.
>
> Guarantees like that have very little value. We are trying to weight the
> risk versus the gain. Please go ahead if and when Emanuele reports
> positive results.
>
> Paul
>
>
{-# OPTIONS_GHC -w #-}
module Main where
import qualified Data.Array as Happy_Data_Array
import qualified Data.Bits as Bits
import Control.Applicative(Applicative(..))
import Control.Monad (ap)
-- parser produced by Happy Version 1.19.9
data HappyAbsSyn t4 t5 t6 t7
= HappyTerminal (Token)
| HappyErrorToken Int
| HappyAbsSyn4 t4
| HappyAbsSyn5 t5
| HappyAbsSyn6 t6
| HappyAbsSyn7 t7
happyExpList :: Happy_Data_Array.Array Int Int
happyExpList = Happy_Data_Array.listArray (0,49) ([1664,1025,0,1,0,768,24576,0,0,0,0,2100,32768,3072,24578,16,131,1048,256,1664,1,6,48,0,0,0,1024,53248,32,0,0
])
{-# NOINLINE happyExpListPerState #-}
happyExpListPerState st =
token_strs_expected
where token_strs = ["error","%dummy","%start_calc","Exp","Exp1","Term","Factor","let","in","int","var","'='","'+'","'-'","'*'","'/'","'('","')'","%eof"]
bit_start = st * 19
bit_end = (st + 1) * 19
read_bit = readArrayBit happyExpList
bits = map read_bit [bit_start..bit_end - 1]
bits_indexed = zip bits [0..18]
token_strs_expected = concatMap f bits_indexed
f (False, _) = []
f (True, nr) = [token_strs !! nr]
action_0 (8) = happyShift action_2
action_0 (10) = happyShift action_7
action_0 (11) = happyShift action_8
action_0 (17) = happyShift action_9
action_0 (4) = happyGoto action_3
action_0 (5) = happyGoto action_4
action_0 (6) = happyGoto action_5
action_0 (7) = happyGoto action_6
action_0 _ = happyFail (happyExpListPerState 0)
action_1 (8) = happyShift action_2
action_1 _ = happyFail (happyExpListPerState 1)
action_2 (11) = happyShift action_15
action_2 _ = happyFail (happyExpListPerState 2)
action_3 (19) = happyAccept
Bug#930563: Can not start freecad
Hello Gulfstream, are you by any chance running the proprietary nvidia drivers? I guess the output of following commands could be helpful for the maintainer to diagnose this issue. Could you run them and forward the output to this bug? which freecad ldd /usr/bin/freecad dpkg -S /lib/x86_64-linux-gnu/libOpenGL.so.0 dpkg -S /usr/lib/x86_64-linux-gnu/libOpenGL.so.0 ls -lisah /lib/x86_64-linux-gnu/libOpenGL.so* /usr/lib/x86_64-linux-gnu/libOpenGL.so* dpkg -l | grep libopengl0 dpkg -l | grep libglvnd Kind regards, Bernhard
Bug#929666: ITP: conmon -- An OCI container runtime monitor
Hi Reinhard, On 6/1/19 5:17 PM, Reinhard Tartler wrote: > I think think that separation is not helping me at all, and I'd really > prefer the standard layout that gbp-buildpackage suggests: > http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.intro.html#gbp.repository > Note that the 'upstream' branch regularily gets merged into the packaging > branch. This seems to be different with your packaging style. merging the > upstream sources enables using tools such as license-reconcile, dgit, and > similar. > Thanks for your understanding. I've now merged the upstream tag into master. There was also a new release a couple of days ago fixing the copyright issue, and I've updated the package accordingly. cheers, Birger
Bug#911844: okular: Prints to the wrong printer
Hi Michael and all! On Sat, Jun 15, 2019 at 11:52:08PM +0200, Michael Weghorn wrote: > I've investigated a bit and it's not an Okular issue, but one in the Qt > print dialog with printers that don't have PPD files. It can be > reproduced e.g. with kate just the same and Brian even mentioned in the > initial report that qpdfview is affected as well. > > The issue has been fixed upstream (qtbase) with the following commit (so > that's what would have to be backported): > > commit 84cc8d0badb4abc3c9a96d59c61dddce916a216c > Author: Albert Astals Cid > Date: Mon Feb 5 09:20:20 2018 +0100 > > cups: Support raw printers > > They don't have a ppd but we don't *really* need a ppd to just > print > > Change-Id: Idf6b6dafc19420a511b057194488e2170cae4d70 Thanks a lot for finding the commit which fixes this bug! I have uploaded a new version of qtbase to unstable today, which has it backported. Can you please test that it really fixes the bug for you? If yes, I will file an unblock request for this upload. > This probably also fixes #911702, but I didn't test that explicitly. If someone tests that too, it would also be nice. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#930622: xserver-xorg-video-intel: sddm doesn't start. (EE) Failed to open authorization file
Package: xserver-xorg-video-intel
Version: 2:2.99.917+git20180925-2
Severity: important
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
Fresh install with mkfs of the whole disk. After reboot sddm doesn't start.
/var/log/Xorg.0.log has this:
[ 386.006] (EE) Failed to open authorization file
"/var/run/sddm/{ba05762d-7748-49d6-8c98-e004168b4901}": No such file or
directory
But
ls -l /var/run/sddm
total 4
-rw--- 1 sddm sddm 51 Jun 16 12:47 {ba05762d-7748-49d6-8c98-e004168b4901}
* What exactly did you do (or not do) that was effective (or
ineffective)?
Switching between F7 (the X session that doesn't work) and F1 works, but
going back to F7 encounters the same non-working sddm. Moving the cursor
makes the blining screen stop blinking but then it remains white. Clicking
any mouse button anywhere has no effect.
* What outcome did you expect instead?
That sddm would start and the login screen would show. Incidentally,
Debian 8 used to work just fine on this computer.
-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.
VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation
82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device [8086:2562] (rev
01)
/etc/X11/xorg.conf does not exist.
/etc/X11/xorg.conf.d does not exist.
/etc/modprobe.d contains no KMS configuration files.
Kernel version (/proc/version):
---
Linux version 4.19.0-5-686-pae (debian-ker...@lists.debian.org) (gcc version
8.3.0 (Debian 8.3.0-7)) #1 SMP Debian 4.19.37-3 (2019-05-15)
Xorg X server log files on system:
--
-rw-r--r-- 1 root root 18637 Jun 16 12:48 /var/log/Xorg.0.log
Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[ 385.366] (--) Log file renamed from "/var/log/Xorg.pid-1388.log" to
"/var/log/Xorg.0.log"
[ 385.367]
X.Org X Server 1.20.4
X Protocol Version 11, Revision 0
[ 385.368] Build Operating System: Linux 4.9.0-8-amd64 i686 Debian
[ 385.368] Current Operating System: Linux debian 4.19.0-5-686-pae #1 SMP
Debian 4.19.37-3 (2019-05-15) i686
[ 385.368] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-686-pae
root=UUID=2ad355d8-a502-4ac8-acc3-f6ff0e2b3ff5 ro quiet
[ 385.368] Build Date: 05 March 2019 08:11:12PM
[ 385.368] xorg-server 2:1.20.4-1 (https://www.debian.org/support)
[ 385.368] Current version of pixman: 0.36.0
[ 385.368]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[ 385.368] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 385.368] (==) Log file: "/var/log/Xorg.0.log", Time: Sun Jun 16 12:47:48
2019
[ 385.369] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[ 385.369] (==) No Layout section. Using the first Screen section.
[ 385.369] (==) No screen section available. Using defaults.
[ 385.370] (**) |-->Screen "Default Screen Section" (0)
[ 385.370] (**) | |-->Monitor ""
[ 385.370] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[ 385.370] (==) Automatically adding devices
[ 385.370] (==) Automatically enabling devices
[ 385.370] (==) Automatically adding GPU devices
[ 385.370] (==) Max clients allowed: 256, resource mask: 0x1f
[ 385.371] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[ 385.371]Entry deleted from font path.
[ 385.371] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[ 385.371] (==) ModulePath set to "/usr/lib/xorg/modules"
[ 385.371] (II) The server relies on udev to provide the list of input
devices.
If no devices become available, reconfigure udev or disable
AutoAddDevices.
[ 385.371] (II) Loader magic: 0x771740
[ 385.371] (II) Module ABI versions:
[ 385.371]X.Org ANSI C Emulation: 0.4
[ 385.371]X.Org Video Driver: 24.0
[ 385.371]X.Org XInput driver : 24.1
[ 385.371]X.Org Server Extension : 10.0
[ 385.375] (++) using VT number 7
[ 385.375] (II) systemd-logind: logind integration requires -keeptty and
-keeptty was not provided, disabling logind integration
[ 385.377] (II) xfree86: Adding drm device (/dev/dri/card0)
[ 385.384] (--) PCI:*(0@0:2:0) 8086:2562:1028:0160 rev 1, Mem @
0xe800/134217728, 0xfeb8/524288, BIOS @
Bug#930453: comma looks too much like period
On Thu, Jun 13, 2019 at 08:03:27AM +0800, 積丹尼 Dan Jacobson wrote: > Package: xterm > Version: 346-1 > Severity: wishlist ... > Can perhaps comma be made a little bigger / different. that's done outside xterm (by your font settings) -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: Digital signature
Bug#930621: unblock: gpodder/3.10.7-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package gpodder
Dear Release Managers,
Recently YouTube started requiring connections via HTTPS. There isn't a
Debian bug filed for this, but upstream contacted me directly to ask
whether this could be addressed for buster. The upstream issue is:
https://github.com/gpodder/gpodder/issues/625
And the patch PR:
https://github.com/gpodder/gpodder/pull/626
I know it's late, but I am filing the unblock with the rationale that
the broken YouTube support will be seen as regression for our users.
Also, the patch is simple.
I have validated the change locally and the debdiff is attached.
Thank you for your consideration!
tony
unblock gpodder/3.10.7-2
diff -Nru gpodder-3.10.7/debian/changelog gpodder-3.10.7/debian/changelog
--- gpodder-3.10.7/debian/changelog 2019-02-02 15:17:35.0 -0800
+++ gpodder-3.10.7/debian/changelog 2019-06-11 17:37:34.0 -0700
@@ -1,3 +1,9 @@
+gpodder (3.10.7-2) unstable; urgency=medium
+
+ * Add patch to use HTTPS for HTTPS URLs, including YouTube.
+
+ -- tony mancill Tue, 11 Jun 2019 17:37:34 -0700
+
gpodder (3.10.7-1) unstable; urgency=medium
* New upstream version 3.10.7
diff -Nru gpodder-3.10.7/debian/patches/series
gpodder-3.10.7/debian/patches/series
--- gpodder-3.10.7/debian/patches/series2019-02-02 15:17:35.0
-0800
+++ gpodder-3.10.7/debian/patches/series2019-06-11 17:37:34.0
-0700
@@ -2,3 +2,4 @@
utf-8_coding_for_setup.patch
remove_copyright_character.patch
switch-appindicator-extension-to-AyatanaAppIndicator-and-python3.patch
+youtube_https.patch
diff -Nru gpodder-3.10.7/debian/patches/youtube_https.patch
gpodder-3.10.7/debian/patches/youtube_https.patch
--- gpodder-3.10.7/debian/patches/youtube_https.patch 1969-12-31
16:00:00.0 -0800
+++ gpodder-3.10.7/debian/patches/youtube_https.patch 2019-06-11
17:37:34.0 -0700
@@ -0,0 +1,47 @@
+Description: Fix YouTube URLs
+Source:
https://patch-diff.githubusercontent.com/raw/gpodder/gpodder/pull/626.patch
+Forwarded: not-needed
+
+---
+ src/gpodder/util.py | 5 -
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/src/gpodder/util.py b/src/gpodder/util.py
+index 7103bd7a3..3fd717fe9 100644
+--- a/src/gpodder/util.py
b/src/gpodder/util.py
+@@ -1402,7 +1402,10 @@ def format_seconds_to_hour_min_sec(seconds):
+
+ def http_request(url, method='HEAD'):
+ (scheme, netloc, path, parms, qry, fragid) = urllib.parse.urlparse(url)
+-conn = http.client.HTTPConnection(netloc)
++if scheme == 'https':
++conn = http.client.HTTPSConnection(netloc)
++else:
++conn = http.client.HTTPConnection(netloc)
+ start = len(scheme) + len('://') + len(netloc)
+ conn.request(method, url[start:])
+ return conn.getresponse()
+
+From deebcf8cecb46e4a47ea0a4bb4269d5e2f2c6e9a Mon Sep 17 00:00:00 2001
+From: auouymous
+Date: Sat, 25 May 2019 15:22:27 +0200
+Subject: [PATCH 2/2] Use https to download from YouTube
+
+---
+ src/gpodder/youtube.py | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/gpodder/youtube.py b/src/gpodder/youtube.py
+index c3e593209..2c87647a9 100644
+--- a/src/gpodder/youtube.py
b/src/gpodder/youtube.py
+@@ -116,7 +116,7 @@ def get_real_download_url(url, preferred_fmt_ids=None):
+ vid = get_youtube_id(url)
+ if vid is not None:
+ page = None
+-url =
'http://www.youtube.com/get_video_info?=detailpage_id=' + vid
++url =
'https://www.youtube.com/get_video_info?=detailpage_id=' + vid
+
+ while page is None:
+ req = util.http_request(url, method='GET')
signature.asc
Description: PGP signature
Bug#930611: openjdk-11-jre: depends on dummy package libgl1-mesa-glx
On Sun, Jun 16, 2019 at 02:37:23PM +0200, Raphaël Halimi wrote: > Package: openjdk-11-jre > Version: 11.0.4+4+really11.0.3+7-2 > Tags: patch > > libgl1-mesa-glx is a dummy package which itself depends on libgl1, > therefore a dependency on libgl1-mesa-glx | libgl1 makes no sense. > > Here is a (very small) patch to fix that. > > It would be very nice if this fix made it to Buster. Hello Raphaël, Since libgl1-mesa-glx is going to be present in buster and the dependency is resolvable, this doesn't feel like a bug that we should upload for so late in the release cycle. Still, thank you for spotting this and filing the bug report. This can be addressed for bullseye. Cheers, tony signature.asc Description: PGP signature
Bug#930607: [Pkg-javascript-devel] Bug#930607: Update libjs-vue to 2.6.10
On Sun, 16 Jun, 2019 at 5:34 PM, Pirate Praveen
wrote:
While we are at it, we have provide an es module entry point as well.
See #930591
I tried to use the upstream provided build script which uses rollup (it
is pushed to rollup branch on salsa), but it failed with this error
dh_auto_build
node scripts/build.js
{ SyntaxError: Unexpected keyword 'false' (49:8)
at error (/usr/lib/nodejs/rollup/dist/rollup.js:222:12)
at Object.error$$1 [as error]
(/usr/lib/nodejs/rollup/dist/rollup.js:6075:6)
at /usr/lib/nodejs/rollup/dist/rollup.js:6084:28
at process._tickCallback (internal/process/next_tick.js:68:7)
at Function.Module.runMain (internal/modules/cjs/loader.js:745:11)
at startup (internal/bootstrap/node.js:283:19)
at bootstrapNodeJSCore (internal/bootstrap/node.js:743:3)
pos: 1204,
loc:
Position {
line: 49,
column: 8,
file:
'/<>/src/core/util/props.js' },
raisedAt: 1211,
snippet:
'45 : toggleObserving(true)\n46 : observe(value)\n47 :
toggleObserving(prevShouldObserve)\n48 : }\n49 : const false =
false;\n ^',
toString: [Function],
plugin: 'buble',
frame:
'45 : toggleObserving(true)\n46 : observe(value)\n47 :
toggleObserving(prevShouldObserve)\n48 : }\n49 : const false =
false;\n ^',
code: 'PLUGIN_ERROR',
id:
'/<>/src/core/util/props.js' }
make[1]: Leaving directory '/<>'
Bug#929781: rkt: CVE-2019-10144 CVE-2019-10145 CVE-2019-10147
Sorry, typo... On Sun, Jun 16, 2019 at 11:47 PM Shengjing Zhu wrote: > > Hi Dmitry, > > Upstream doesn't have any update for these 3 CVE for more than 2 > weeks(after the CVE published). > > So I'm afraid that rkt is longer maintained, with 2 other concerns: s/is longer/is no longer/g > > 1. Most commits since 2019 are about typo/documents. > 2. Coreos(the company who creates rkt) has been acquired by RedHat. > And RedHat has more interests in other container related tools, like > podman. Although rkt is now hosted by CNCF, but it doesn't attract > more contributors. > > So I would suggest we remove rkt from buster. > -- Shengjing Zhu
Bug#929781: rkt: CVE-2019-10144 CVE-2019-10145 CVE-2019-10147
Hi Dmitry, Upstream doesn't have any update for these 3 CVE for more than 2 weeks(after the CVE published). So I'm afraid that rkt is longer maintained, with 2 other concerns: 1. Most commits since 2019 are about typo/documents. 2. Coreos(the company who creates rkt) has been acquired by RedHat. And RedHat has more interests in other container related tools, like podman. Although rkt is now hosted by CNCF, but it doesn't attract more contributors. So I would suggest we remove rkt from buster. -- Shengjing Zhu
Bug#930321: php-horde-form: diff for NMU version 2.0.18-3.1
Control: tags 930321 + pending
Hi Mathieu,
I've prepared an NMU for php-horde-form (versioned as 2.0.18-3.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it or feel free to override it with a maintainer upload!
Decided to go ahead with a DELAYED/2 only given the approaching
release for buster.
Regards,
Salvatore
diff -Nru php-horde-form-2.0.18/debian/changelog php-horde-form-2.0.18/debian/changelog
--- php-horde-form-2.0.18/debian/changelog 2018-05-15 10:43:28.0 +0200
+++ php-horde-form-2.0.18/debian/changelog 2019-06-16 09:29:14.0 +0200
@@ -1,3 +1,11 @@
+php-horde-form (2.0.18-3.1) unstable; urgency=high
+
+ * Non-maintainer upload.
+ * Prevent directory traversal vulnerability (CVE-2019-9858)
+(Closes: #930321)
+
+ -- Salvatore Bonaccorso Sun, 16 Jun 2019 09:29:14 +0200
+
php-horde-form (2.0.18-3) unstable; urgency=medium
* Update Standards-Version to 4.1.4, no change
diff -Nru php-horde-form-2.0.18/debian/patches/0001-SECURITY-prevent-directory-traversal-vulnerability.patch php-horde-form-2.0.18/debian/patches/0001-SECURITY-prevent-directory-traversal-vulnerability.patch
--- php-horde-form-2.0.18/debian/patches/0001-SECURITY-prevent-directory-traversal-vulnerability.patch 1970-01-01 01:00:00.0 +0100
+++ php-horde-form-2.0.18/debian/patches/0001-SECURITY-prevent-directory-traversal-vulnerability.patch 2019-06-16 09:24:04.0 +0200
@@ -0,0 +1,27 @@
+From: Michael J Rubinsky
+Date: Thu, 3 Jan 2019 19:22:56 -0500
+Subject: SECURITY: prevent directory traversal vulnerability.
+Origin: https://github.com/horde/Form/commit/c916ba979ad1613d76a9407dd0b67968a9594c0e
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2019-9858
+Bug-Debian: https://bugs.debian.org/930321
+
+---
+ Horde_Form-2.0.18/lib/Horde/Form/Type.php | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Horde_Form-2.0.18/lib/Horde/Form/Type.php b/Horde_Form-2.0.18/lib/Horde/Form/Type.php
+index e92c7903915b..f1e8157f0b68 100644
+--- a/Horde_Form-2.0.18/lib/Horde/Form/Type.php
b/Horde_Form-2.0.18/lib/Horde/Form/Type.php
+@@ -1205,7 +1205,7 @@ class Horde_Form_Type_image extends Horde_Form_Type {
+ /* Get the temp file if already one uploaded, otherwise create a
+ * new temporary file. */
+ if (!empty($upload['img']['file'])) {
+-$tmp_file = Horde::getTempDir() . '/' . $upload['img']['file'];
++$tmp_file = Horde::getTempDir() . '/' . basename($upload['img']['file']);
+ } else {
+ $tmp_file = Horde::getTempFile('Horde', false);
+ }
+--
+2.20.1
+
diff -Nru php-horde-form-2.0.18/debian/patches/series php-horde-form-2.0.18/debian/patches/series
--- php-horde-form-2.0.18/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ php-horde-form-2.0.18/debian/patches/series 2019-06-16 09:23:14.0 +0200
@@ -0,0 +1 @@
+0001-SECURITY-prevent-directory-traversal-vulnerability.patch
Bug#930620: RFP: diacli -- diaspora command line interface
Package: wnpp Severity: wishlist * Package name: diacli Version : 0.1.2 Upstream Author : Marek Marecki * URL : https://github.com/marekjm/diacli * License : GPL-3 Programming Lang: Python Description : diaspora command line interface diacli is the program that let's you communicate with Diaspora, a distributed social network, from the command line.
Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, 2019-06-16 at 15:50 +0200, Ivo De Decker wrote: > > We regularly get biten by this issue when contributors to security > > uploads, most recently with the bind9 upload but as well others. > > Is it clear in what cases this issue happens? Guillem mentioned > "dpkg-buildpackage --changes-option=-S" in https://bugs.debian.org/869184#75 > Are there any other use cases that trigger it? > > As "--changes-option=-S" creates an upload that is broken from the point of > view of the archive, it might make sense not to recommend (or even allow) this > for now. Just building with "-S" instead should create a buildinfo file with > _source, which won't trigger this issue. I'm my case I'm just using pbuilder with SOURCE_ONLY_CHANGES=yes, so it builds a complete (arch:all + arch:any) package, then generate a .changes for source- only upload (but there's the amd64.buildinfo included). Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl0GWt8ACgkQ3rYcyPpX RFtQ8ggAnZSlfTWlEx4sLTfq59wI7ooeFwqRn84tuF5o9wGkmu6TiqvL5iKiw2l5 4j8x/bmwvTw4VE4QW7tMCnZ3VEfiZA4NXBkFVoCvwhiDFKWhzZL058yfoRqMMIhf O/GAnZ0FIjwn3s0k5K6TEFPHNA9CdIhHWtLBnzVfwIZt3QeuVYE0CTE9ZehTrGZe ygr2mlyNjO+izUwqlacwyDV7vH6p0789I6ulYKn/2AfxRxf/S7C+GmKbIrXy8e+9 xTWDcuudK9BmZU2WjtzY43ER7gyzFx8AHv89AXmWZ9jcaBiFcbd0K7pKnAPsY/+x +FwaxjrWWoIquJezCQ0RGmtPdxpE3Q== =L3gm -END PGP SIGNATURE-
Bug#930618: node-terser does not install file mentioned in package.json's main field and fails Error: Cannot find module 'terser'
Package: node-terser
version: 3.14.1-2
severity: grave
Control: tags -1 patch
pravi@andhaka:~/forge/debian/git/js-team/vue.js$ sudo apt install
node-terser
[sudo] password for pravi:
Sorry, try again.
[sudo] password for pravi:
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
node-terser
0 upgraded, 1 newly installed, 0 to remove and 1017 not upgraded.
Need to get 0 B/156 kB of archives.
After this operation, 919 kB of additional disk space will be used.
Selecting previously unselected package node-terser.
(Reading database ... 213014 files and directories currently installed.)
Preparing to unpack .../node-terser_3.14.1-2_all.deb ...
Unpacking node-terser (3.14.1-2) ...
Setting up node-terser (3.14.1-2) ...
pravi@andhaka:~/forge/debian/git/js-team/vue.js$ node -e
"require('terser');"
internal/modules/cjs/loader.js:583
throw err;
^
Error: Cannot find module 'terser'
at Function.Module._resolveFilename
(internal/modules/cjs/loader.js:581:15)
at Function.Module._load (internal/modules/cjs/loader.js:507:25)
at Module.require (internal/modules/cjs/loader.js:637:17)
at require (internal/modules/cjs/helpers.js:22:18)
at [eval]:1:1
at Script.runInThisContext (vm.js:96:20)
at Object.runInThisContext (vm.js:303:38)
at Object. ([eval]-wrapper:6:22)
at Module._compile (internal/modules/cjs/loader.js:689:30)
at evalScript (internal/bootstrap/node.js:587:27)
In package.json, "main": "dist/bundle.js" is specified, which is not
installed in the node module path.
/usr/share/javascript/terser/bundle.js should be linked to
/usr/lib/nodejs/terser/dist/bundle.js and libjs-terser added to Depends
of node-terser.
Patch:
https://salsa.debian.org/js-team/node-terser/commit/78f0922edff4010c8b9789b3c2c5fe1397fceefe
available in fix-main-path branch in salsa repo.
Bug#930619: ITP: michabo -- Qt desktop client for Pleroma and Mastodon
Package: wnpp Severity: wishlist Owner: "Iain R. Learmonth" * Package name: michabo Version : 0.1 Upstream Author : kaniini * URL : https://git.pleroma.social/kaniini/michabo * License : GPL v3 Programming Lang: C++/Qt Description : Qt desktop client for Pleroma and Mastodon Michabo is a desktop app for Pleroma and Mastodon servers built with Qt. It is a lightweight client that uses only 1MB of RAM when not in heavy use.
Bug#928099: publishing private e-mail
Hi Tong Sun, Please be respectful to the others. Whatever the mail address prefix the others use, the others have the right to make private discussion and free speech because these are fundamental rights. I don't know what happend but your comments are really not friendly. If you really received problematic messages from a Debian developer, please consider reaching out the Anti-harrasment team or DPL for help, privately. > On Sat, Jun 15, 2019 at 07:55:04AM -0400, Tong Sun wrote: >> > >> > To me, your message, bearing a @debian.org address, should represent >> > that of debian.org, both privately or publicly, and never says thing >> that you will regret later, or say it publicly. Especially we are >> discussing public matters, that affects the public and all authors. >> >> Such decision should not be conducted behind close doors.
Bug#930595: RFS: uacme/1.0.15-2 [ITP]
New version with suggestions from Adam dget -x https://mentors.debian.net/debian/pool/main/u/uacme/uacme_1.0.15-3.dsc
Bug#930597: unblock: pikepdf/1.0.5+dfsg-3 -- redux
Control: tags -1 confirmed moreinfo Hi, On Sun, Jun 16, 2019 at 10:37:01AM +0100, Sean Whitton wrote: > pikepdf 1.0.5+dfsg-3 was unblocked by nthykier but has not migrated: > > Migration status: Blocked. Can't migrate due to a non-migratable > dependency. Check status below. > Blocked by: gcc-8 > 48 days old (2 needed) > > People in #debian-release told me I should ask whether I can upload > pikepdf to testing-proposed-updates to bypass this problem. OK. Please remove the moreinfo tag from this bug once the upload is ready to be unblocked. > (I guess with version number 1.0.5+dfsg-2+deb10u1 ?) No. For a rebuild of 1.0.5+dfsg-3, the preferred version is 1.0.5+dfsg-3~deb10u1 (with the changelog entry for 1.0.5+dfsg-3 also in the changelog). For patches on top of 1.0.5+dfsg-2 (but not a rebuild of a newer version), the version would have been 1.0.5+dfsg-2+deb10u1, as you suggested. Please set the distribution in the changelog to 'buster' (not 'testing' or 'testing-proposed-updates'). Thanks, Ivo
Bug#930617: unblock: debian-security-support/2019.06.13
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package debian-security-support, the changes are rather trivial, yet with the nice result of all included translations to being complete now: $ debdiff debian-security-support_2019.06.01.dsc debian-security-support_2019.06.13.dsc|diffstat debian/changelog| 12 po/cs.po| 24 +++- po/da.po| 26 +- security-support-ended.deb8 |1 + 4 files changed, 37 insertions(+), 26 deletions(-) full debdiff attached. unblock debian-security-support/2019.06.13 -- tschau, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C In Europe there are people prosecuted by courts because they saved other people from drowning in the Mediterranean Sea. That is almost as absurd as if there were people being prosecuted because they save humans from drowning in the sea. diff -Nru debian-security-support-2019.06.01/debian/changelog debian-security-support-2019.06.13/debian/changelog --- debian-security-support-2019.06.01/debian/changelog 2019-06-01 17:44:00.0 +0200 +++ debian-security-support-2019.06.13/debian/changelog 2019-06-13 18:27:05.0 +0200 @@ -1,3 +1,15 @@ +debian-security-support (2019.06.13) unstable; urgency=medium + + [ Emilio Pozuelo Monfort ] + * Add mysql-5.5 to security-support-ended.deb8. + + * Translation updates: +- Danish, thanks to Joe Dalton. Closes: #929941. +- Czech, thanks to Michal Simunek. Closes: #930384. +- this means all included translations are uptodate, yay! + + -- Holger Levsen Thu, 13 Jun 2019 18:27:05 +0200 + debian-security-support (2019.06.01) unstable; urgency=medium * New translations: diff -Nru debian-security-support-2019.06.01/po/cs.po debian-security-support-2019.06.13/po/cs.po --- debian-security-support-2019.06.01/po/cs.po 2018-03-16 15:39:59.0 +0100 +++ debian-security-support-2019.06.13/po/cs.po 2019-06-12 18:27:03.0 +0200 @@ -1,14 +1,14 @@ # Czech PO debconf template translation of debian-security-support. # Copyright (C) 2014 Michal Simunek # This file is distributed under the same license as the debian-security-support package. -# Michal Simunek , 2014. +# Michal Simunek , 2014 - 2019. # msgid "" msgstr "" -"Project-Id-Version: debian-security-support 2014.05.16\n" +"Project-Id-Version: debian-security-support 2019.05.23\n" "Report-Msgid-Bugs-To: debian-security-supp...@packages.debian.org\n" "POT-Creation-Date: 2016-06-07 12:13+0200\n" -"PO-Revision-Date: 2014-06-20 09:15+0200\n" +"PO-Revision-Date: 2019-06-11 20:15+0200\n" "Last-Translator: Michal Simunek \n" "Language-Team: Czech \n" "Language: cs\n" @@ -22,6 +22,8 @@ "Unknown DEBIAN_VERSION $DEBIAN_VERSION. Valid values from " "$DEB_LOWEST_VER_ID and $DEB_NEXT_VER_ID" msgstr "" +"Neznámá verze Debianu $DEBIAN_VERSION. Platné hodnoty od " +"$DEB_LOWEST_VER_ID a $DEB_NEXT_VER_ID" #: ../check-support-status.in:63 msgid "Failed to parse the command line parameters" @@ -38,12 +40,12 @@ #: ../check-support-status.in:117 msgid "E: Need a --type if --list is given" -msgstr "" +msgstr "E: Je-li zadán --list, je třeba zadat --type" #: ../check-support-status.in:130 #, sh-format msgid "E: Unknown --type '$TYPE'" -msgstr "" +msgstr "E: Neznámý --type '$TYPE'" #: ../check-support-status.in:152 msgid "E: Cannot detect dpkg version, assuming wheezy or newer" @@ -52,18 +54,16 @@ "wheezy nebo novější" #: ../check-support-status.in:282 -#, fuzzy msgid "Future end of support for one or more packages" -msgstr "Omezená bezpečnostní podpora jednoho nebo více balíčků" +msgstr "Budoucí omezená bezpečnostní podpora jednoho nebo více balíčků" #: ../check-support-status.in:285 -#, fuzzy msgid "" "Unfortunately, it will be necessary to end security support for some " "packages before the end of the regular security maintenance life " "cycle." msgstr "" -"U některých balíčků bylo bohužel nutné ukončit bezpečnostní podporu " +"U některých balíčků bude bohužel nutné ukončit bezpečnostní podporu " "před koncem životního cyklu běžně poskytované bezpečnostní podpory." #: ../check-support-status.in:288 ../check-support-status.in:298 @@ -98,11 +98,9 @@ "U některých balíčků bylo bohužel nutné omezit bezpečnostní podporu." #: ../check-support-status.in:320 -#, fuzzy, sh-format +#, sh-format msgid "* Source:$SRC_NAME, will end on $ALERT_WHEN" -msgstr "" -"* Zdrojový balíček: $SRC_NAME, podpora ukončena $ALERT_WHEN u verze " -"$ALERT_VERSION" +msgstr "* Zdrojový balíček: $SRC_NAME, podpora skončí $ALERT_WHEN" #: ../check-support-status.in:323 #, sh-format diff -Nru debian-security-support-2019.06.01/po/da.po
Bug#929318: unblock: papi/5.7.0+dfsg-1
On 16/06/2019 14.59, Jonathan Wiltshire wrote: > On Sun, Jun 09, 2019 at 11:00:10PM +0200, Andreas Beckmann wrote: >> The transition from libpapi5 to libpapi5.7 will require only a single >> binNMU: eztrace. > > Scheduled and will monitor. The extra-depends is not valid for s390x (and some non-release architectures) which does not build papi at all. Andreas
Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems
Hi, Last week, Salvatore pointed me at this bug and Holger mentioned it in his talk. On Thu, May 09, 2019 at 07:24:56PM +0200, Salvatore Bonaccorso wrote: [...] > We regularly get biten by this issue when contributors to security > uploads, most recently with the bind9 upload but as well others. Is it clear in what cases this issue happens? Guillem mentioned "dpkg-buildpackage --changes-option=-S" in https://bugs.debian.org/869184#75 Are there any other use cases that trigger it? As "--changes-option=-S" creates an upload that is broken from the point of view of the archive, it might make sense not to recommend (or even allow) this for now. Just building with "-S" instead should create a buildinfo file with _source, which won't trigger this issue. > Would it be possible to at least workaround this on dak's side? > Disabling source-only uploads completely would seem to be a step back > on that regards. There was this commit almost 2 years ago, which cleanly rejects these uploads, allowing the uploader to do a new upload: https://salsa.debian.org/ftp-team/dak/commit/7d234eaa5 However it was disabled shortly after (because it was rejecting a lot of uploads): https://salsa.debian.org/ftp-team/dak/commit/f9eb90374 Maybe this check should be enabled again. The beginning of the bullseye cycle might be a good time to do that. Even if that is considered too disruptive, this check could be enabled for the security archive only, which would probably be better than to disable source-only uploads there. Thanks, Ivo
Bug#929943: linux-image-4.19.0-5-amd64: NFS handle leak? Suspend-to-RAM inhibition
Hmmm, while there surely was something fishy about the NFS delay, I'm not sure whether that was the sole problem for the suspend issues. Two more reboots later, without having NFS mounted all the time, suspend doesn't work all the time - I've had the notebook running happily (and hot) 3 times in the backpack, simply closing the lid didn't work. Taking it out, running "acpitool -s" did work, though -- so it might be a userspace issue (lxqt => dbus => some daemon?), or broken lid detection, or... The previous 4.19.0-5-amd64 didn't have these suspend issues.
Bug#930616: unblock: vim/2:8.1.0875-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package vim This is a follow up to the previous fixes for CVE-2019-12735. Upstream added a new option (disabled by default) to control whether expressions can be evaluated in modelines, so that modelines are further restricted. unblock vim/2:8.1.0875-5 -- System Information: Debian Release: 10.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diffstat for vim-8.1.0875 vim-8.1.0875 changelog | 12 gbp.conf|2 patches/patch-8.1.1366-using-expressions-in-a-modeline-is-unsafe.patch | 588 ++ patches/patch-8.1.1367-can-set-modelineexpr-in-modeline.patch | 54 patches/patch-8.1.1368-modeline-test-fails-with-python-but-withou.patch | 42 patches/patch-8.1.1382-error-when-editing-test-file.patch | 71 + patches/patch-8.1.1401-misspelled-mkspellmem-as-makespellmem.patch | 69 + patches/series |5 8 files changed, 842 insertions(+), 1 deletion(-) diff -Nru vim-8.1.0875/debian/changelog vim-8.1.0875/debian/changelog --- vim-8.1.0875/debian/changelog 2019-06-07 06:49:19.0 -0400 +++ vim-8.1.0875/debian/changelog 2019-06-15 12:41:15.0 -0400 @@ -1,3 +1,15 @@ +vim (2:8.1.0875-5) unstable; urgency=medium + + * gbp.conf: Set debian-tag to debian/%(version)s + * Backport 'modelineexpr' patches to further restrict modelines ++ 8.1.1366: Using expressions in a modeline is unsafe ++ 8.1.1367: can set 'modelineexpr' in modeline ++ 8.1.1368: Modeline test fails with python but without pythonhome ++ 8.1.1382: Error when editing test file ++ 8.1.1401: misspelled mkspellmem as makespellmem (test fix) + + -- James McCoy Sat, 15 Jun 2019 12:41:15 -0400 + vim (2:8.1.0875-4) unstable; urgency=high * Backport 8.1.1046 and 8.1.1365 to fix CVE-2019-12735 (Closes: #930020) diff -Nru vim-8.1.0875/debian/gbp.conf vim-8.1.0875/debian/gbp.conf --- vim-8.1.0875/debian/gbp.conf2019-06-07 06:49:19.0 -0400 +++ vim-8.1.0875/debian/gbp.conf2019-06-15 12:41:15.0 -0400 @@ -1,6 +1,6 @@ [DEFAULT] upstream-tag = v%(version)s -debian-tag = v%(version)s +debian-tag = debian/%(version)s debian-branch = debian/sid [pq] diff -Nru vim-8.1.0875/debian/patches/patch-8.1.1366-using-expressions-in-a-modeline-is-unsafe.patch vim-8.1.0875/debian/patches/patch-8.1.1366-using-expressions-in-a-modeline-is-unsafe.patch --- vim-8.1.0875/debian/patches/patch-8.1.1366-using-expressions-in-a-modeline-is-unsafe.patch 1969-12-31 19:00:00.0 -0500 +++ vim-8.1.0875/debian/patches/patch-8.1.1366-using-expressions-in-a-modeline-is-unsafe.patch 2019-06-15 12:41:15.0 -0400 @@ -0,0 +1,588 @@ +From: Bram Moolenaar +Date: Thu, 23 May 2019 15:38:06 +0200 +Subject: patch 8.1.1366: using expressions in a modeline is unsafe + +Problem:Using expressions in a modeline is unsafe. +Solution: Disallow using expressions in a modeline, unless the +'modelineexpr' option is set. Update help, add more tests. + +(cherry picked from commit 110289e78195b6d01e1e6ad26ad450de476d41c1) + +Signed-off-by: James McCoy +--- + runtime/doc/options.txt | 69 +++- + src/option.c | 35 ++-- + src/option.h | 1 + + src/testdir/test49.in | 2 +- + src/testdir/test_modeline.vim | 93 +++ + src/version.c | 2 + + 6 files changed, 169 insertions(+), 33 deletions(-) + +diff --git a/runtime/doc/options.txt b/runtime/doc/options.txt +index c269fea..7b25f20 100644 +--- a/runtime/doc/options.txt b/runtime/doc/options.txt +@@ -1,4 +1,4 @@ +-*options.txt* For Vim version 8.1. Last change: 2019 Feb 03 ++*options.txt* For Vim version 8.1. Last change: 2019 May 23 + + + VIM REFERENCE MANUALby Bram Moolenaar +@@ -588,14 +588,17 @@ backslash in front of the ':' will be removed. Example: +/* vi:set dir=c\:\tmp: */ ~ + This sets the 'dir' option to "c:\tmp". Only a single backslash before the + ':' is removed. Thus to include "\:" you have to specify "\\:". +- ++ *E992* + No other commands than "set" are supported, for security reasons (somebody + might create a Trojan horse text file with modelines). And not all options +-can be
Bug#930615: unblock: qscintilla2/2.10.4+dfsg-2.1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package qscintilla2
Add a Breaks against an ancient predecessor package that gets crippled
on some upgrade paths due to Replaces being used without Breaks.
unblock qscintilla2/2.10.4+dfsg-2.1
Andreas
diff -Nru qscintilla2-2.10.4+dfsg/debian/changelog
qscintilla2-2.10.4+dfsg/debian/changelog
--- qscintilla2-2.10.4+dfsg/debian/changelog2019-02-21 19:34:03.0
+0100
+++ qscintilla2-2.10.4+dfsg/debian/changelog2019-06-16 14:55:29.0
+0200
@@ -1,3 +1,13 @@
+qscintilla2 (2.10.4+dfsg-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * libqscintilla2-qt4-13: Add Breaks against libqscintilla2-3 from lenny
+since some upgrade paths uncleanly delete files, causing debsums to
+complain about missing /usr/share/qt4/translations/qscintilla_ru.qm.
+(Closes: #925403)
+
+ -- Andreas Beckmann Sun, 16 Jun 2019 14:55:29 +0200
+
qscintilla2 (2.10.4+dfsg-2) unstable; urgency=medium
[ Scott Kitterman ]
diff -Nru qscintilla2-2.10.4+dfsg/debian/control
qscintilla2-2.10.4+dfsg/debian/control
--- qscintilla2-2.10.4+dfsg/debian/control 2019-02-21 19:34:03.0
+0100
+++ qscintilla2-2.10.4+dfsg/debian/control 2019-03-24 11:03:41.0
+0100
@@ -39,6 +39,7 @@
${misc:Depends},
${shlibs:Depends}
Pre-Depends: ${misc:Pre-Depends}
+Breaks: libqscintilla2-3
Suggests: libqscintilla2-doc
Description: Qt4 port of the Scintilla source code editing widget
QScintilla is a text editor for Qt4 with features especially useful when
Bug#930614: cubeb_alsa.c :1045 : alsa_stream_destroy: l'assertion « stm && (stm->state == INACTIVE || stm->state == ERROR || stm->state == DRAINING) » a échoué.
Package: firefox-esr Version: 60.7.0esr-1 Hello, Firefox often crashes when closing a tab which has audio currently playing. Running firefox from a terminal, this error message comes: cubeb_alsa.c :1045 : alsa_stream_destroy: l'assertion « stm && (stm->state == INACTIVE || stm->state == ERROR || stm->state == DRAINING) » a échoué. Might have been fixed upstream for firefox 61, according to these reports for a similar issue: https://forums.gentoo.org/viewtopic-t-1081634.html Hope this helps, -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) 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 /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages firefox-esr depends on: ii debianutils 4.8.6.1 ii fontconfig2.13.1-2 ii libasound21.1.8-1 ii libatk1.0-0 2.30.0-2 ii libc6 2.28-10 ii libcairo-gobject2 1.16.0-4 ii libcairo2 1.16.0-4 ii libdbus-1-3 1.12.16-1 ii libdbus-glib-1-2 0.110-4 ii libevent-2.1-62.1.8-stable-4 ii libffi6 3.2.1-9 ii libfontconfig12.13.1-2 ii libfreetype6 2.9.1-3 ii libgcc1 1:8.3.0-6 ii libgdk-pixbuf2.0-02.38.1+dfsg-1 ii libglib2.0-0 2.58.3-2 ii libgtk-3-03.24.5-1 ii libhunspell-1.7-0 1.7.0-2 ii libjsoncpp1 1.7.4-3 ii libnspr4 2:4.20-1 ii libnss3 2:3.42.1-1 ii libpango-1.0-01.42.4-6 ii libsqlite3-0 3.27.2-3 ii libstartup-notification0 0.12-6 ii libstdc++68.3.0-6 ii libvpx5 1.7.0-3 ii libx11-6 2:1.6.7-1 ii libx11-xcb1 2:1.6.7-1 ii libxcb-shm0 1.13.1-2 ii libxcb1 1.13.1-2 ii libxcomposite11:0.4.4-2 ii libxdamage1 1:1.1.4-3+b3 ii libxext6 2:1.3.3-1+b2 ii libxfixes31:5.0.3-1 ii libxrender1 1:0.9.10-1 ii libxt61:1.1.5-1+b3 ii procps2:3.3.15-2 ii zlib1g1:1.2.11.dfsg-1 Versions of packages firefox-esr recommends: ii libavcodec58 7:4.1.3-1 Versions of packages firefox-esr suggests: ii fonts-lmodern 2.004.5-6 pn fonts-stix | otf-stix pn libcanberra0 ii libgssapi-krb5-2 1.17-2 ii libgtk2.0-02.24.32-3 pn pulseaudio
Bug#930613: steam: depends on dummy package libgl1-mesa-glx
Package: steam Version: 1.0.0.59-4 Tags: patch libgl1-mesa-glx is a dummy package which itself depends on libgl1 and libglx-mesa0. After checking every binary file in ~/.steam, it seems that none of them depends on the libraries provided by libglx-mesa0 (libGLX_mesa.so.0, libGLX_indirect.so.0), but some of them depend on libGL.so.1, provided by libgl1. Hence, it's probably safe to replace the dependency on libgl1-mesa-glx with libgl1. Here is a (very small) patch to fix that. It would be very nice if this fix made it to Buster. Regards, -- Raphaël Halimi Index: steam-1.0.0.59/debian/control === --- steam-1.0.0.59.orig/debian/control +++ steam-1.0.0.59/debian/control @@ -25,7 +25,7 @@ Pre-Depends: Depends: libgl1-mesa-dri, libgl1-mesa-dri (>= 17.3) | libtxc-dxtn0, - libgl1-mesa-glx, + libgl1, libgpg-error0 (>= 1.10), libudev1, libxcb-dri3-0 (>= 1.11.1), signature.asc Description: OpenPGP digital signature
Bug#930612: libnet-dbus-perl: annotate test dependencies with
Source: libnet-dbus-perl Version: 1.1.0-5 Tags: patch User: debian-cr...@lists.debian.org Usertags: cross-satisfiability Please annotate test Build-Depends with . The relevant dependencies pose a problem to cross building. Please consider applying the attached patch. Helmut diff --minimal -Nru libnet-dbus-perl-1.1.0/debian/changelog libnet-dbus-perl-1.1.0/debian/changelog --- libnet-dbus-perl-1.1.0/debian/changelog 2018-10-29 11:30:59.0 +0100 +++ libnet-dbus-perl-1.1.0/debian/changelog 2019-06-16 14:24:15.0 +0200 @@ -1,3 +1,10 @@ +libnet-dbus-perl (1.1.0-5.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Annotate test Build-Depends with . (Closes: #-1) + + -- Helmut Grohne Sun, 16 Jun 2019 14:24:15 +0200 + libnet-dbus-perl (1.1.0-5) unstable; urgency=medium [ Salvatore Bonaccorso ] diff --minimal -Nru libnet-dbus-perl-1.1.0/debian/control libnet-dbus-perl-1.1.0/debian/control --- libnet-dbus-perl-1.1.0/debian/control 2018-10-29 11:30:59.0 +0100 +++ libnet-dbus-perl-1.1.0/debian/control 2019-06-16 14:24:14.0 +0200 @@ -6,8 +6,8 @@ Priority: optional Build-Depends: debhelper (>= 11), libdbus-1-dev, - libtest-pod-coverage-perl, - libtest-pod-perl, + libtest-pod-coverage-perl , + libtest-pod-perl , libxml-twig-perl, perl Standards-Version: 4.2.1
Bug#930603: libdockapp-dev: pkg-config file Requires xext without dependency on libxext-dev
On Sun, Jun 16, 2019 at 7:30 AM Andreas Metzler mailto:ametz...@bebt.de>> wrote: /usr/lib/x86_64-linux-gnu/pkgconfig/dockapp.pc: Requires: x11 xext xpm Therefore anything build-depending on libdockapp-dev and using pkg-config to locate the library will FTBFS unless it has a direct b-d on libxext-dev. I think the error is in the pkg-config file, not in the Debian package. Since the headers of libdockapp-dev do not #include (and therefore expose) headers from libxext-dev the pkg-config should have (at most) Libs.private: -lext instead of the requires. This was fixed in git upstream a while ago [1], but there hasn't been a new release yet. I'll work on that soon. Doug [1] https://repo.or.cz/dockapps.git/commitdiff/3cbdd16
Bug#929318: unblock: papi/5.7.0+dfsg-1
On Sun, Jun 09, 2019 at 11:00:10PM +0200, Andreas Beckmann wrote: > The transition from libpapi5 to libpapi5.7 will require only a single > binNMU: eztrace. Scheduled and will monitor. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51
Bug#921194: No Amarok in Buster
Isn't the fact there is no Amarok in Buster considered a problem?
Bug#930611: openjdk-11-jre: depends on dummy package libgl1-mesa-glx
Package: openjdk-11-jre Version: 11.0.4+4+really11.0.3+7-2 Tags: patch libgl1-mesa-glx is a dummy package which itself depends on libgl1, therefore a dependency on libgl1-mesa-glx | libgl1 makes no sense. Here is a (very small) patch to fix that. It would be very nice if this fix made it to Buster. Regards, -- Raphaël Halimi Index: openjdk-11-11.0.4+4+really11.0.3+7/debian/rules === --- openjdk-11-11.0.4+4+really11.0.3+7.orig/debian/rules +++ openjdk-11-11.0.4+4+really11.0.3+7/debian/rules @@ -602,7 +602,7 @@ ifneq ($(with_nss),no) endif dlopen_hl_recommends = dlopen_jre_depends = \ - libglib2.0-0 (>= 2.24), libgtk2.0-0 | libgtk-3-0, libxrandr2, libxinerama1, libgl1-mesa-glx | libgl1 + libglib2.0-0 (>= 2.24), libgtk2.0-0 | libgtk-3-0, libxrandr2, libxinerama1, libgl1 dlopen_jre_recommends = # .desktop files need to be multiarch installable signature.asc Description: OpenPGP digital signature
Bug#930610: unblock: tenshi/0.13-2.1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package tenshi
This upload is primarily intended to fix the version ordering violation
introduced by the CVE fix in wheezy-lts that never went into sid or
stretch:
tenshi | 0.11-2| squeeze | source, all
tenshi | 0.13-2| wheezy | source, all
tenshi | 0.13-2| stretch | source, all
tenshi | 0.13-2| buster | source, all
tenshi | 0.13-2| sid | source, all
tenshi | 0.13-2+deb7u1 | wheezy-security | source, all
This is a rebuild of 0.13-2+deb7u1 for sid. I'll follow up with
0.13-2.1~deb9u1 for stretch.
unblock tenshi/0.13-2.1
Andreas
diff -Nru tenshi-0.13/debian/changelog tenshi-0.13/debian/changelog
--- tenshi-0.13/debian/changelog2012-02-13 05:30:17.0 +0100
+++ tenshi-0.13/debian/changelog2019-06-16 14:24:39.0 +0200
@@ -1,3 +1,19 @@
+tenshi (0.13-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Upload to unstable.
+ * Drop DMUA.
+
+ -- Andreas Beckmann Sun, 16 Jun 2019 14:24:39 +0200
+
+tenshi (0.13-2+deb7u1) wheezy-security; urgency=high
+
+ * Non-maintainer upload by the Debian LTS team.
+ * Fix CVE-2017-11746: PID file issue allows local users to kill arbitrary
+processes (Closes: #871321)
+
+ -- Lucas Kanashiro Sun, 27 Aug 2017 14:47:19 -0300
+
tenshi (0.13-2) unstable; urgency=low
* debian/init:
diff -Nru tenshi-0.13/debian/control tenshi-0.13/debian/control
--- tenshi-0.13/debian/control 2012-02-10 05:23:20.0 +0100
+++ tenshi-0.13/debian/control 2019-06-16 13:55:10.0 +0200
@@ -2,7 +2,6 @@
Section: admin
Priority: optional
Maintainer: Ignace Mouzannar
-DM-Upload-Allowed: yes
Build-Depends: debhelper (>= 7.0.8)
Standards-Version: 3.9.2
Vcs-Svn: svn://svn.debian.org/collab-maint/ext-maint/tenshi/trunk/
diff -Nru tenshi-0.13/debian/patches/CVE-2017-11746.patch
tenshi-0.13/debian/patches/CVE-2017-11746.patch
--- tenshi-0.13/debian/patches/CVE-2017-11746.patch 1970-01-01
01:00:00.0 +0100
+++ tenshi-0.13/debian/patches/CVE-2017-11746.patch 2017-08-27
19:53:26.0 +0200
@@ -0,0 +1,36 @@
+Description: save PID after forking but before changing privileges
+ This is an adaptation of upstream commit
+ (d0e7f28c13ffbd5888b31d6532c2faf78f10f176) that fixes CVE-2017-11746. It was
+ written by Andrea Barisani.
+Author: Lucas Kanashiro
+Last-Updated: 2017-08-27
+
+--- a/tenshi
b/tenshi
+@@ -122,8 +122,6 @@ if ($listen) {
+
+ $SIG{'CHLD'} = sub { $debug && debug(5,'CHLD') ; print RED "[ERROR] Child
died. Bailing out\n"; $time_to_die = 1; };
+
+-prepare_process();
+-
+ #
+ # sanity checks
+ #
+@@ -242,8 +240,6 @@ if (!($debug || $profile || $foreground)
+ daemonize();
+ }
+
+-save_pid();
+-
+ while (!$time_to_die) {
+ my $now = time;
+
+@@ -963,6 +959,8 @@ sub daemonize {
+ defined(my $pid = fork) or clean_up and die RED "[ERROR] can't fork:
$!\n";
+ exit if $pid;
+ setsid()or clean_up and die RED "[ERROR] can't start
a new session: $!\n";
++save_pid();
++prepare_process();
+ }
+
+ sub save_pid {
diff -Nru tenshi-0.13/debian/patches/series tenshi-0.13/debian/patches/series
--- tenshi-0.13/debian/patches/series 2012-02-10 04:37:37.0 +0100
+++ tenshi-0.13/debian/patches/series 2017-08-26 20:50:46.0 +0200
@@ -1,2 +1,3 @@
10-Makefile.diff
20-manpage.diff
+CVE-2017-11746.patch
Bug#930609: xorg: depends on dummy package libgl1-mesa-glx
Package: xorg
Version: 1:7.7+19
Tags: patch
libgl1-mesa-glx is a dummy package which itself depends on libgl1,
therefore a dependency on libgl1-mesa-glx | libgl1 makes no sense.
Here is a (very small) patch to fix that.
It would be very nice if this fix made it to Buster.
Regards,
--
Raphaël Halimi
Index: xorg-7.7+19/debian/control
===
--- xorg-7.7+19.orig/debian/control
+++ xorg-7.7+19/debian/control
@@ -88,7 +88,7 @@ Package: xorg
Architecture: any
Depends:
xserver-xorg (>= ${binary:Version}),
- libgl1-mesa-glx | libgl1,
+ libgl1,
libgl1-mesa-dri,
libglu1-mesa,
xfonts-base (>= 1:1.0.0-1),
signature.asc
Description: OpenPGP digital signature
Bug#930238: unblock: zfs-linux/0.7.12-2+deb10u1 [t-p-u]
On 2019-06-15 11:04, Paul Gevers wrote: On 14-06-2019 12:50, Aron Xu wrote: I have tested the package in a virtual machine on amd64 for linux/4.19.37-3 (buster) and a locally built updated linux kernel that breaks zfs-linux/0.7.12-2. The dkms package builds fine with both of the versions and zpool create/export/import works fine. Therefore, please unblock the t-p-u update for buster, thanks. I am probably asking a very stupid question, but ... The changes in the patch are in the source code. Do these dkms package work is such a way that the binaries are compiled every time that a kernel gets updated? I.e. a change in the source that checks for the kernel version actually results in a binary that works for that source? The whole point of dkms is to make sure that kernel modules available as source are made available to all installed kernels. So as long as the ABI version of the kernel changes (in Ubuntu with every upload, for us much more rarely) the module is recompiled. The corollary here is that it is not recompiled if the ABI version did not change because the module is assumed to still be compatible. (Our kernel maintainers also regularly ignore certain ABI changes they do not consider to actually be part of the ABI they support.) Kind regards Philipp Kern
Bug#930557: ITP: i3-gaps -- i3-gaps is a fork of i3wm featuring gaps, smart borders, smart gaps
Hi Socrates. On 2019-06-15 15:11, Socrates Tzagiousis wrote: [...] i3-gaps is a fork of i3wm, a tiling window manager for X11. It is kept up to date with upstream, adding a few additional features such as gaps between windows *** Why should it be submitted and differences to the original (vanilla i3): *** i3-gaps is a popular fork of the most widely used tiling wm (vanilla i3), and is used exclusively by many people. It essentially contains a superset of functionalities to vanilla i3, and its gaps and smart border features as well as added i3bar RGBA transparency make it not only more pleasing to use, but easier to distinguish individual window frames without having to resort to colourful window frames and title bars as in the original. It is included on the main repositories of most major distributions right now, and for good reason. Why weren't the changes accepted upstream? Is this really a sustainable fork that has sufficient interest? Kind regards and thanks Philipp Kern
Bug#930595: RFS: uacme/1.0.15-2 [ITP]
On Sun, Jun 16, 2019 at 12:55:38PM +0200, Adam Borowski wrote: Hi Adam There's already a team in Debian dedicated to packaging of stuff made by that anvil-making company. Have you contacted them? Yes, in April and unfortunately I received no reply. The package doesn't build for me: http://ix.io/1LVo ./configure: line 5401: syntax error near unexpected token `$CFLAGS' ./configure: line 5401: `AX_CHECK_COMPILE_FLAG($CFLAGS -Wall, CFLAGS="$CFLAGS -Wall")' I'm afraid I forgot to build-depend on autoconf-archive... If you install it it should work. I'll fix it. Not building something (like the man page) from source is usually a serious error. In this particular case, groff is nearly as sourcey format as asciidoc -- but it'd still be a problem with upstreaming. Someone wanting to improve the man page can't easily test asciidoc (as the patched build system doesn't use that) yet improvements done as groffage wouldn't be liked by upstream (in this case you). But, what about using asciidoctor instead? That's supposed to be a drop-in replacement for asciidoc. The reason I patched it out is because I thought it's better not to build-depend on asciidoc (as I do not regenerate the docs unless I make a new revision). But of course I am happy to remove the patch and build-depend on asciidoc. Your upstream project seems to use straightforward sane github-based release workflow, that makes watch files easy to write (just copy one of existing recipes). Watch files are not mandatory, but are nice to have. Since I am both upstream and packager, I generate the orig tarball with autoconf's make dist, then archive it with pristine-tar in the git repository using gbp importpackage and the third option in https://wiki.debian.org/PackagingWithGit#Upstream_import_methods the page above links to this, so I just put comments in an otherwise empty watch file. https://www.eyrie.org/~eagle/notes/debian/git.html If you don't have a working debian/watch file or don't want to use uscan, you can also download the upstream release tarball, omit the --uscan flag to gbp import-orig, and just provide the path to the upstream release tarball. I do this when packaging software for which I'm also upstream, since I generally prepare the Debian package with a local release tarball that I haven't published yet, and then publish the release tarball and the Debian package at the same time. A new package can be uploaded only to unstable (or experimental) -- your version is targetted at stretch. For a backport, it needs to first be in testing, thus please retarget at unstable even if you eventually do want to include a backport later. And, we care about future releases more than past. Ok, will target unstable. But generally, the above problems aside, the package seems to be well made. Many thanks for taking the time to review it. I will make the changes mentioned and post a new version.
Bug#930608: xserver-xorg-core: depends on dummy package libegl1-mesa
Package: xserver-xorg-core
Version: 2:1.20.4-1
Tags: patch
libegl1-mesa is a dummy package which itself depends only on libegl1,
therefore a dependency on libegl1-mesa | libegl1 makes no sense.
Here is a (very small) patch to fix that.
It would be very nice if this fix made it to Buster, since this bug is
present in it, but also in stretch-backports.
Please also look at #785574, which was valid for Stretch, but not
anymore for Buster, so you may want to close it as well.
Regards,
--
Raphaël Halimi
Description: Fix xserver-xorg-core dependency on dummy package libegl1-mesa
Package xserver-xorg-core depends on libegl1-mesa | libegl1. libegl1-mesa is a
dummy package which itself depends on libegl1. This patch removes the dummy
package from the alternative dependency.
Author: Raphaël Halimi
Last-Update: 2019-06-16
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
Index: xorg-server-1.20.4/debian/control
===
--- xorg-server-1.20.4.orig/debian/control
+++ xorg-server-1.20.4/debian/control
@@ -90,7 +90,7 @@ Depends:
udev (>= 149) [linux-any],
devd [kfreebsd-any],
# for glamor; not a shlibdep because we use epoxy
- libegl1-mesa [linux-any kfreebsd-any] | libegl1 [linux-any kfreebsd-any],
+ libegl1 [linux-any kfreebsd-any],
${shlibs:Depends},
${misc:Depends},
Recommends:
signature.asc
Description: OpenPGP digital signature
Bug#930607: Update libjs-vue to 2.6.10
package: libjs-vue
version: 2.5.17+dfsg-1
severity: wishlist
Control: block 930404 by -1
gitlab 11.10.5 needs vue.js 2.6.10
While trying to update, the build failed.
webpack --config debian/webpack.cjs.config.js
Hash: 72f9c82be3887f68bebc
Version: webpack 3.5.6
Time: 283ms
Asset Size Chunks Chunk Names
vue.common.js 2.78 kB 0 [emitted] main
[0] ./src/platforms/web/entry-runtime-with-compiler.js 309 bytes {0}
[built] [failed] [1 error]
ERROR in ./src/platforms/web/entry-runtime-with-compiler.js
Module build failed: SyntaxError: Unexpected token, expected , (19:4)
17 | const mount = Vue.prototype.$mount
18 | Vue.prototype.$mount = function (
> 19 | el?: string | Element,
| ^
20 | hydrating?: boolean
21 | ): Component {
22 | el = el && query(el)
While we are at it, we have provide an es module entry point as well.
See #930591
Bug#930606: todoman should be Arch=all
Package: todoman
Version: 3.5.0-1
Hi,
The contents of the amd64 and i386 .deb are fully
identical.
And I can't find any architecure dependent content in it
either.
Please consider setting the package to Arch=all.
The *UNTESTED* patch should do it.
Cheers
Elrond
--- debian/control~
+++ debian/control
@@ -35,7 +35,7 @@
Vcs-Browser: https://salsa.debian.org/felix-guest/todoman
Package: todoman
-Architecture: any
+Architecture: all
Depends: ${misc:Depends}, ${python3:Depends}
Suggests: vdirsyncer, libjs-jquery, libjs-underscore
Description: Simple CalDAV-based todo manager
Bug#893572: tracker.debian.org: Debian Maintainer display: [dm] links empty, should be uppercase and use parentheses
Ok. No dm.txt. Thanks Paul and Raphael. Regards, Herbert Em sáb, 15 de jun de 2019 05:52, Raphael Hertzog escreveu: > On Sat, 15 Jun 2019, Raphael Hertzog wrote: > > I also don't know why you picked this bug report to start your journey > > into distro-tracker. It's not a trivial issue to fix and the added value > > is relatively low compared to other missing features. > > > > I took the time to highlight easy bugs with the newcomer tag, > > maybe you should start with some of those? > > Ah, I see the bug was tagged as newcomer by Paul in fact. I suggest > you first deal with all the requests in this bug except the last > idea to display who approved the DM right... the rest should be relatively > easy. > > Cheers, > -- > Raphaël Hertzog ◈ Debian Developer > > Support Debian LTS: https://www.freexian.com/services/debian-lts.html > Learn to master Debian: https://debian-handbook.info/get/ >
Bug#846278: Fix or workaround for Debian #846278
Robert Micsutka wrote on Sun, 16 Jun 2019 11:00 +00:00: > On Sat, 08 Jun 2019 10:21:31 + "Daniel Shahaf" > wrote: > > You might be able to get around this by using the 'equivs' package: > > But after this you can not lock your screen anymore. > The qucik workaroud here is to use a different lock screen, eg: Yes, sorry, I thought that went without saying. equivs simply allows light-locker to be deinstalled while keeping xfce installed; one then needs to install another screen locker to restore the functionality. That's the workaround I used, anyway. There may well be a simpler one :) Cheers, Daniel
Bug#930605: RM: erlang-ic-java [all] -- RoQA; NBS; obsolete arch:all package
Package: ftp.debian.org Severity: normal erlang-ic-java is no longer built by erlang 1:21. Andreas
Bug#930604: RFS: sslh/1.18-1.1 [NMU] [RC]
Package: sponsorship-requests Severity: important Dear mentors, I saw that package "sslh" is already in autoremove queue https://udd.debian.org/cgi-bin/autoremovals.cgi so I'm sending NMU change for that package to prevent package removal. NMU change fixes bug #919188 with linked patch which is in that bug ticket: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919188 Package name: sslh Version : 1.18-1.1 Upstream Author : Yves Rutschle URL : http://www.rutschle.net/tech/sslh.shtml License : GPL-2.0+ Section : net It builds those binary packages: sslh - Applicative protocol multiplexer To access further information about this package, please visit the following URL: https://mentors.debian.net/package/sslh Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/sslh/sslh_1.18-1.1.dsc More information about sslh can be obtained from http://www.rutschle.net/tech/sslh.shtml Changes since the last upload: * Detach sslh from terminal in init script (Closes: #919188) Regards, Pali Rohár signature.asc Description: PGP signature
Bug#930469: chromium: Insta-segfault on start
Package: chromium Version: 75.0.3770.90-1 Followup-For: Bug #930469 I tried running it with --temp-profile as Mike suggested and it worked. Any ideas how can I keep all my profile data such as history and bookmarks? -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_USER Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE=ru:en_US (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages chromium depends on: ii chromium-common 75.0.3770.90-1 ii libasound2 1.1.8-1 ii libatk-bridge2.0-0 2.30.0-5 ii libatk1.0-0 2.30.0-2 ii libatomic1 8.3.0-7 ii libatspi2.0-02.30.0-7 ii libavcodec58 7:4.1.3-1 ii libavformat587:4.1.3-1 ii libavutil56 7:4.1.3-1 ii libc62.28-10 ii libcairo-gobject21.16.0-4 ii libcairo21.16.0-4 ii libcups2 2.2.10-6 ii libdbus-1-3 1.12.16-1 ii libdrm2 2.4.97-1 ii libevent-2.1-6 2.1.8-stable-4 ii libexpat12.2.6-1 ii libflac8 1.3.2-3 ii libfontconfig1 2.13.1-2 ii libfreetype6 2.9.1-3 ii libgcc1 1:8.3.0-7 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-0 2.58.3-2 ii libgtk-3-0 3.24.5-1 ii libharfbuzz0b2.3.1-1 ii libicu63 63.2-2 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libjsoncpp1 1.7.4-3 ii liblcms2-2 2.9-3 ii libminizip1 1.1-8+b1 ii libnspr4 2:4.21-1 ii libnss3 2:3.44+really3.42.1-2 ii libopenjp2-7 2.3.0-2 ii libopus0 1.3-1 ii libpango-1.0-0 1.42.4-6 ii libpangocairo-1.0-0 1.42.4-6 ii libpci3 1:3.5.2-5 ii libpng16-16 1.6.36-6 ii libpulse012.2-4 ii libre2-5 20190101+dfsg-2+b1 ii libsnappy1v5 1.1.7-1 ii libstdc++6 8.3.0-7 ii libva2 2.4.0-1 ii libvpx5 1.7.0-3 ii libwebp6 0.6.1-2 ii libwebpdemux20.6.1-2 ii libwebpmux3 0.6.1-2 ii libx11-6 2:1.6.7-1 ii libx11-xcb1 2:1.6.7-1 ii libxcb1 1.13.1-2 ii libxcomposite1 1:0.4.4-2 ii libxcursor1 1:1.1.15-2 ii libxdamage1 1:1.1.4-3+b3 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxi6 2:1.7.9-1 ii libxml2 2.9.4+dfsg1-7+b3 ii libxrandr2 2:1.5.1-1 ii libxrender1 1:0.9.10-1 ii libxslt1.1 1.1.32-2 ii libxss1 1:1.2.3-1 ii libxtst6 2:1.2.3-1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages chromium recommends: ii chromium-sandbox 75.0.3770.90-1 Versions of packages chromium suggests: pn chromium-driver ii chromium-l10n75.0.3770.90-1 pn chromium-shell Versions of packages chromium-common depends on: ii x11-utils 7.7+4 ii xdg-utils 1.1.3-1 Versions of packages chromium-common recommends: ii chromium-sandbox75.0.3770.90-1 ii fonts-liberation1:1.07.4-9 ii libgl1-mesa-dri 18.3.6-2 ii libu2f-udev 1.1.9-1 ii notification-daemon 3.20.0-4 ii plasma-workspace [notification-daemon] 4:5.14.5.1-1 ii upower 0.99.10-1 Versions of packages chromium-sandbox depends on: ii libatomic1 8.3.0-7 ii libc6 2.28-10 ii libgcc1 1:8.3.0-7 ii libstdc++6 8.3.0-7 -- no debconf information
Bug#928368: Bug#929318: unblock: papi/5.7.0+dfsg-1
Control: tag -1 - moreinfo On 15/06/2019 20.03, Paul Gevers wrote: >> The transition from libpapi5 to libpapi5.7 will require only a single >> binNMU: eztrace. > > Please go ahead and upload to unstable. Please remove the moreinfo tag > when the time is there to schedule the binNMU's. Thanks. The package is in sid, built on all release architectures and I verified that all reverse build-depends still build on amd64. Andreas
Bug#930603: libdockapp-dev: pkg-config file Requires xext without dependency on libxext-dev
Package: libdockapp-dev Version: 1:0.7.2-1 Severity: important /usr/lib/x86_64-linux-gnu/pkgconfig/dockapp.pc: Requires: x11 xext xpm Therefore anything build-depending on libdockapp-dev and using pkg-config to locate the library will FTBFS unless it has a direct b-d on libxext-dev. I think the error is in the pkg-config file, not in the Debian package. Since the headers of libdockapp-dev do not #include (and therefore expose) headers from libxext-dev the pkg-config should have (at most) Libs.private: -lext instead of the requires. cu Andreas
Bug#930602: mark pycodestyle Multi-Arch: foreign
Package: pycodestyle
Version: 2.4.0-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:budgie-extras src:netplan.io src:pygobject
src:python-apt src:syslog-ng
The affected packages fail to satisfy their cross Build-Depends, because
their (transitive) dependency on pycodestyle is unsatisfiable.
pycodestyle is a command line program that interacts with textual
formats (python source) and thus should be marked Multi-Arch: foreign to
improve the situation. Please consider applying the attached patch.
Helmut
diff --minimal -Nru pycodestyle-2.4.0/debian/changelog
pycodestyle-2.4.0/debian/changelog
--- pycodestyle-2.4.0/debian/changelog 2018-09-28 11:22:22.0 +0200
+++ pycodestyle-2.4.0/debian/changelog 2019-06-16 13:04:11.0 +0200
@@ -1,3 +1,10 @@
+pycodestyle (2.4.0-2.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Mark pycodestyle Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne Sun, 16 Jun 2019 13:04:11 +0200
+
pycodestyle (2.4.0-2) unstable; urgency=medium
* Breaks older python{3,}-flake8
diff --minimal -Nru pycodestyle-2.4.0/debian/control
pycodestyle-2.4.0/debian/control
--- pycodestyle-2.4.0/debian/control2018-09-28 10:59:24.0 +0200
+++ pycodestyle-2.4.0/debian/control2019-06-16 13:04:10.0 +0200
@@ -16,6 +16,7 @@
Package: pycodestyle
Architecture: all
+Multi-Arch: foreign
Depends: python3-pkg-resources,
python3-pycodestyle (=${binary:Version}),
${misc:Depends},
Bug#930601: libnet-ssleay-perl: annotate test dependencies with
Source: libnet-ssleay-perl Version: 1.85-2 Tags: patch User: debian-cr...@lists.debian.org Usertags: cross-satisfiability Please annotate test Build-Depends with . This helps with both cross building (as the relevant dependencies are unsatisfiable) and bootstrapping (as fewer packages are needed there). The attached patch implements that. Helmut diff --minimal -Nru libnet-ssleay-perl-1.85/debian/changelog libnet-ssleay-perl-1.85/debian/changelog --- libnet-ssleay-perl-1.85/debian/changelog2018-09-02 22:19:51.0 +0200 +++ libnet-ssleay-perl-1.85/debian/changelog2019-06-16 13:14:00.0 +0200 @@ -1,3 +1,10 @@ +libnet-ssleay-perl (1.85-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Annotate test Build-Depends with . (Closes: #-1) + + -- Helmut Grohne Sun, 16 Jun 2019 13:14:00 +0200 + libnet-ssleay-perl (1.85-2) unstable; urgency=medium [ Damyan Ivanov ] diff --minimal -Nru libnet-ssleay-perl-1.85/debian/control libnet-ssleay-perl-1.85/debian/control --- libnet-ssleay-perl-1.85/debian/control 2018-08-30 06:53:58.0 +0200 +++ libnet-ssleay-perl-1.85/debian/control 2019-06-16 13:13:58.0 +0200 @@ -8,10 +8,10 @@ Build-Depends: debhelper (>= 11), perl, libssl-dev, - libtest-exception-perl, - libtest-nowarnings-perl, - libtest-pod-perl, - libtest-warn-perl, + libtest-exception-perl , + libtest-nowarnings-perl , + libtest-pod-perl , + libtest-warn-perl , openssl, perl-openssl-defaults Standards-Version: 4.2.1
Bug#846278: Fix or workaround for Debian #846278
> what I did to fix the problem was "apt-get purge light-locker". Here they say that the default greeter (lightdm-gtk-greeter) of light-locker shoud be changed to a different greater, eg slick-greeter https://github.com/the-cavalry/light-locker/issues/114#issuecomment-474709454 https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1801609/comments/27 So no need to install any other locker like I mentioned above.
Bug#930417: freeorion: Crash on save/load button
Sorry, I mistyped your email address. Does the new version resolve your issue? Thanks Markus On Sun, 16 Jun 2019 02:19:44 +0200 Markus Koschany wrote: > Thanks for the report, and thanks to Bernhard for the investigation. I > have just uploaded a new revision of freeorion with the proposed patch > to unstable. Please tell me if it resolves your issue. > > Regards, > > Markus > signature.asc Description: OpenPGP digital signature
Bug#930600: dev-ref: common.ent should be switched to utf-8
package: developers-reference severity: minor x-debbugs-cc: Osamu Aoki , 930...@bugs.debian.org On Sun, Jun 16, 2019 at 09:23:42AM +0900, Osamu Aoki wrote: > If you see my initial diff on the first line of common.ent > > - > + > > Although for ASCII code range (7-bits), iso-8859-1, utf-8, ascii are the > same, shouldn't we use UTF-8 in line with XML code? Was there any > specific issues to do this? > > THis is no rush but I think this is the right way (Am I wrong?) agreed & thanks for pointing this out as well. post buster material though :) -- tschau, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#846278: Fix or workaround for Debian #846278
On Sat, 08 Jun 2019 10:21:31 + "Daniel Shahaf" wrote: > You might be able to get around this by using the 'equivs' package: But after this you can not lock your screen anymore. The qucik workaroud here is to use a different lock screen, eg: - https://wiki.archlinux.org/index.php/XScreenSaver#DPMS_and_blanking_settings - https://github.com/xfce-mirror/xfce4-screensaver - https://github.com/muennich/physlock - https://wiki.archlinux.org/index.php/Slock In this thread they also suspects intel driver as the base problem: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929834#51
Bug#930595: RFS: uacme/1.0.15-2 [ITP]
On Sun, Jun 16, 2019 at 10:52:00AM +0200, Nicola Di Lieto wrote: > * Package name: uacme > Version : 1.0.15-2 > Upstream Author : Nicola Di Lieto > * URL : https://github.com/ndilieto/uacme > uacme - Lightweight client for the RFC8555 ACMEv2 protocol There's already a team in Debian dedicated to packaging of stuff made by that anvil-making company. Have you contacted them? The package doesn't build for me: http://ix.io/1LVo ./configure: line 5401: syntax error near unexpected token `$CFLAGS' ./configure: line 5401: `AX_CHECK_COMPILE_FLAG($CFLAGS -Wall, CFLAGS="$CFLAGS -Wall")' Not building something (like the man page) from source is usually a serious error. In this particular case, groff is nearly as sourcey format as asciidoc -- but it'd still be a problem with upstreaming. Someone wanting to improve the man page can't easily test asciidoc (as the patched build system doesn't use that) yet improvements done as groffage wouldn't be liked by upstream (in this case you). But, what about using asciidoctor instead? That's supposed to be a drop-in replacement for asciidoc. Your upstream project seems to use straightforward sane github-based release workflow, that makes watch files easy to write (just copy one of existing recipes). Watch files are not mandatory, but are nice to have. A new package can be uploaded only to unstable (or experimental) -- your version is targetted at stretch. For a backport, it needs to first be in testing, thus please retarget at unstable even if you eventually do want to include a backport later. And, we care about future releases more than past. But generally, the above problems aside, the package seems to be well made. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ Secret tech: have up-to-date backups. Rules of this world say ⢿⡄⠘⠷⠚⠋⠀ a failure can ever happen if you don't have them, which saves a ⠈⠳⣄ lot of downtime spent restoring.
Bug#930577: coinor-libipopt-dev: uses uninitialized memory with MUMPS >= 5.1.0
Hi Drew On Sun, 16 Jun 2019 at 10:09, Graham Inggs wrote: > Just as a reference, the commit that solved the problem in upstream is > coin-or/Ipopt@4c36f88 [2]. The GitHub reference in the commit name is > wrong because since then the coin-or/Ipopt repo has been replaced with > the one migrated from trac, and all the "old" PR and issue got lost. > > It seems that this patch should be used instead. > > [2] > https://github.com/coin-or/Ipopt/commit/4c36f888f1e8a609975f0bee60fe04958024236c Using the steps below (also from the upstream bug), I was able to reproduce the error and confirm that the above patch it. I intend to NMU. sudo apt install cmake valgrind build-essential coinor-libipopt-dev git clone https://github.com/traversaro/ipopt-cmake-demo cd ipopt-cmake-demo mkdir build cd build cmake .. make valgrind ./ipopt_example Without the patch, valgrind outputs: ==8203== Conditional jump or move depends on uninitialised value(s) ==8203==at 0x5C41E26: dmumps_ (in /usr/lib/x86_64-linux-gnu/libdmumps_seq-5.1.2.so) ==8203==by 0x5C4744D: dmumps_f77_ (in /usr/lib/x86_64-linux-gnu/libdmumps_seq-5.1.2.so) ==8203==by 0x5C3FF52: dmumps_c (in /usr/lib/x86_64-linux-gnu/libdmumps_seq-5.1.2.so) ==8203==by 0x4C34336: Ipopt::MumpsSolverInterface::MumpsSolverInterface() (in /usr/lib/libipopt.so.1.9.9) ==8203==by 0x4B64B7A: Ipopt::AlgorithmBuilder::BuildBasicAlgorithm(Ipopt::Journalist const&, Ipopt::OptionsList const&, std::__cxx11::basic_string, std::allocator > const&) (in /usr/lib/libipopt.so.1.9.9) ==8203==by 0x4B26CB5: Ipopt::IpoptApplication::OptimizeNLP(Ipopt::SmartPtr const&, Ipopt::SmartPtr&) (in /usr/lib/libipopt.so.1.9.9) ==8203==by 0x4B1E4D8: Ipopt::IpoptApplication::OptimizeNLP(Ipopt::SmartPtr const&) (in /usr/lib/libipopt.so.1.9.9) ==8203==by 0x4B1E6A9: Ipopt::IpoptApplication::OptimizeTNLP(Ipopt::SmartPtr const&) (in /usr/lib/libipopt.so.1.9.9) ==8203==by 0x10B58F: main (in /home/graham/debian-packages-ssd/coinor-ipopt/ipopt-cmake-demo/build/ipopt_example) ... ==8203== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) With the patch, valgrind outputs: ==8300== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Regards Graham
Bug#930554: Please add support for Huawei's TaiShan server platform
On Sat, Jun 15, 2019 at 01:19:08PM +0100, Steve McIntyre wrote: >Source: linux >Version: 4.19.28-2 >Severity: important > >Hi folks, > >The TaiShan is an arm64 server made by Huawei, using the HiSilicon >1620 CPU. It's a nice big beast of a machine, with lots of cores, >memory etc. We've been loaned one to use (maybe as a buildd?), but at >the moment the Buster kernel doesn't support it out of the box. > >I'm partway through a set of patches to enable it, turning on some >device drivers and backporting a few fixes. Patch coming very soon. It >would be very helpful to have this in our Buster release. MR submitted: https://salsa.debian.org/kernel-team/linux/merge_requests/151 -- Steve McIntyre, Cambridge, UK.st...@einval.com "I used to be the first kid on the block wanting a cranial implant, now I want to be the first with a cranial firewall. " -- Charlie Stross
Bug#930599: liblognorm FTCBFS: unsatisfiable dependency on python-sphinx
Source: liblognorm
Version: 2.0.5-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
liblognorm fails to satisfy its cross build dependencies, because its
dependency on python-sphinx is unsatisfiable. Fixing this seems
non-trivial, but there is a different solution: Move it to
Build-Depends-Indep. This is only possible if the documentation is moved
to an Architecture: all package. The attached patch demonstrates that.
I think splitting a liblognorm-doc package is a useful trade-off:
* It makes liblognorm cross buildable.
* The size of the documentation dominates the size of the -dev package.
Yet for building something against liblognorm, the documentation is
not required. For many common scenarios, we'll get a smaller
installation set (both in terms of package count and size).
* Marking liblognorm-dev Multi-Arch: same will become easier as we
don't have to worry about reproducible documentation.
If you concur with this, please split out liblognorm-doc.
Helmut
diff --minimal -Nru liblognorm-2.0.5/debian/changelog
liblognorm-2.0.5/debian/changelog
--- liblognorm-2.0.5/debian/changelog 2018-04-29 11:52:22.0 +0200
+++ liblognorm-2.0.5/debian/changelog 2019-06-16 11:36:24.0 +0200
@@ -1,3 +1,10 @@
+liblognorm (2.0.5-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTCBFS: Split out liblognorm-doc package. (Closes: #-1)
+
+ -- Helmut Grohne Sun, 16 Jun 2019 11:36:24 +0200
+
liblognorm (2.0.5-1) unstable; urgency=medium
* New upstream version 2.0.5
diff --minimal -Nru liblognorm-2.0.5/debian/control
liblognorm-2.0.5/debian/control
--- liblognorm-2.0.5/debian/control 2018-04-29 11:49:30.0 +0200
+++ liblognorm-2.0.5/debian/control 2019-06-16 11:36:24.0 +0200
@@ -8,6 +8,7 @@
libxml2-dev,
libestr-dev,
libfastjson-dev,
+Build-Depends-Indep:
python-sphinx (>= 1.0.7+dfsg) | python3-sphinx
Standards-Version: 3.9.8
Section: libs
@@ -20,9 +21,9 @@
Architecture: any
Depends: liblognorm5 (= ${binary:Version}),
${misc:Depends},
-${sphinxdoc:Depends},
libfastjson-dev,
libestr-dev
+Recommends: liblognorm-doc
Description: log normalizing library - development files
Liblognorm is an event and log normalization library that is capable of
real-time processing. It provides the capability to normalize events to
@@ -30,6 +31,20 @@
.
This package contains the development files.
+Package: liblognorm-doc
+Section: doc
+Architecture: all
+Multi-Arch: foreign
+Depends:
+${misc:Depends},
+${sphinxdoc:Depends},
+Description: log normalizing library - developer documentation
+ Liblognorm is an event and log normalization library that is capable of
+ real-time processing. It provides the capability to normalize events to
+ a set of standard formats.
+ .
+ This package contains the development documentation.
+
Package: liblognorm5
Section: libs
Architecture: any
diff --minimal -Nru liblognorm-2.0.5/debian/liblognorm-dev.docs
liblognorm-2.0.5/debian/liblognorm-dev.docs
--- liblognorm-2.0.5/debian/liblognorm-dev.docs 2015-03-25 18:03:51.0
+0100
+++ liblognorm-2.0.5/debian/liblognorm-dev.docs 1970-01-01 01:00:00.0
+0100
@@ -1 +0,0 @@
-doc/_build/html
diff --minimal -Nru liblognorm-2.0.5/debian/liblognorm-doc.docs
liblognorm-2.0.5/debian/liblognorm-doc.docs
--- liblognorm-2.0.5/debian/liblognorm-doc.docs 1970-01-01 01:00:00.0
+0100
+++ liblognorm-2.0.5/debian/liblognorm-doc.docs 2015-03-25 18:03:51.0
+0100
@@ -0,0 +1 @@
+doc/_build/html
diff --minimal -Nru liblognorm-2.0.5/debian/rules liblognorm-2.0.5/debian/rules
--- liblognorm-2.0.5/debian/rules 2016-08-09 09:07:24.0 +0200
+++ liblognorm-2.0.5/debian/rules 2019-06-16 11:36:24.0 +0200
@@ -9,10 +9,12 @@
# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1
+DOPACKAGES = $(shell dh_listpackages)
+
export DEB_BUILD_HARDENING=1
override_dh_auto_configure:
- dh_auto_configure -- --enable-docs --enable-compile-warnings=yes
+ dh_auto_configure -- --$(if $(filter
liblognorm-doc,$(DOPACKAGES)),en,dis)able-docs --enable-compile-warnings=yes
override_dh_auto_build:
[ -d "doc/_static" ] || mkdir "doc/_static"; \
@@ -23,4 +25,5 @@
dh_compress -X.rst -X.js -X.html -X.txt
%:
- dh $@ --with=autoreconf,sphinxdoc
+ dh $@ --with=autoreconf $(DH_ADDONS)
+build binary %-indep: DH_ADDONS=--with=sphinxdoc
Bug#930591: [Pkg-javascript-devel] Bug#930591: node-vue-resource is broken - TypeError: vue__WEBPACK_IMPORTED_MODULE_0__.default.http is undefined
Control: tag -1 help On Sun, 16 Jun, 2019 at 1:25 PM, Pirate Praveen wrote: When trying to use packaged version of node-vue-resource, Web Console shows this error. UI elements just show the spinning circle forever. Upstream is using rollup based build system and we converted it to webpack when rollup was in contrib. When I tried to switch back to rollup when updating to 1.5.1, the build failed (we have an older version of rollup than what upstream wants). Some options, 1. Use https://github.com/purtuga/esm-webpack-plugin to generate esm, but this needs webpack 4 2. Try with a newer rollup, we will have to wait till rollup is updated 3. Try changing package.json#module to src/index.js 4. Try changing package.json#main to dist/vue-resource.js
