Bug#966649: Request for feedback on upload_history re-implementation
Hi Lucas! I'm rereading this, and I have a follow-up question. It looks to me, based on reading the bug carefully, that /srv/ udd.debian.org/email-archives/debian-devel-changes/debian-devel-changes.current on ullmann successfully receives any new emails to debian-devel-changes. Is that accurate? If so, excellent -- I can incorporate that into my design. If not, then I can talk to DSA to discuss what might be best (polling lists.debian.org over HTTPS once per 2 min vs. fixing that file). Cheers! Asheesh.
Bug#968739: [benjamin.redeli...@gmail.com: Bug#968739: igv will not run]
Hi Pierre,
do you have some spare cycles for this issue?
BTW, I do not think that we should stick to that now outdated
version but while fixing the issue package latest upstream.
On a more general note: Igv is another Java package that is in
non-free only due to the included binary JARs. If we could that
sorted out it probably could go into main which would be a real
advantage.
Kind regards
Andreas.
- Forwarded message from Benjamin Redelings
-
Date: Thu, 20 Aug 2020 14:01:13 -0400
From: Benjamin Redelings
To: Debian Bug Tracking System
Subject: Bug#968739: igv will not run
X-Debian-PR-Message: report 968739
X-Debian-PR-Package: igv
X-Debian-PR-Keywords:
X-Debian-PR-Source: igv
Package: igv
Version: 2.4.17+dfsg-1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
The IGV package seems not to work. It throws a NoSuchMethodError exception
on startup with the following trace:
$ igv
log4j: reset attribute= "false".
log4j: Threshold ="null".
log4j: Retreiving an instance of org.apache.log4j.Logger.
log4j: Setting [org.broad.igv] additivity to [true].
log4j: Level value for org.broad.igv is [INFO].
log4j: org.broad.igv level set to INFO
log4j: Class name: [org.apache.log4j.ConsoleAppender]
log4j: Parsing layout of class: "org.apache.log4j.PatternLayout"
log4j: Setting property [conversionPattern] to [%d{-MM-dd HH:mm:ss} %-5p
%c{1}:%L - %m%n].
log4j: Adding appender named [console] to category [org.broad.igv].
2020-08-20 13:59:59 INFO DirectoryManager:179 - IGV Directory:
/home/bredelings/igv
2020-08-20 13:59:59 INFO Main:155 - Startup IGV Version user not_set
2020-08-20 13:59:59 INFO Main:156 - Java 11.0.8
2020-08-20 13:59:59 INFO DirectoryManager:84 - Fetching user directory...
2020-08-20 13:59:59 INFO Main:157 - Default User Directory: /home/bredelings
2020-08-20 13:59:59 INFO Main:158 - OS: Linux
2020-08-20 13:59:59 INFO Main:208 - Unknown version: user
2020-08-20 14:00:00 ERROR DefaultExceptionHandler:49 - Unhandled exception
java.lang.NoSuchMethodError: 'void
htsjdk.tribble.util.ParsingUtils.registerHelperClass(java.lang.Class)'
at org.broad.igv.util.HttpUtils.(HttpUtils.java:104)
at org.broad.igv.util.HttpUtils.getInstance(HttpUtils.java:97)
at org.broad.igv.ui.Main.open(Main.java:279)
at org.broad.igv.ui.Main$1.run(Main.java:110)
at
java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:313)
at
java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:770)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at
java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:740)
at
java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
at
java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
at
java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
at
java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
at
java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at
java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
2020-08-20 14:00:01 INFO ShutdownThread:46 - Shutting down
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (2000, 'unstable'), (1999, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.7.0-2-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages igv depends on:
ii default-jre 2:1.11-72
ii junit44.12-8
ii libbatik-java 1.12-1.1
ii libbcprov-java1.65-1
ii libcofoja-java1.3-4
ii libcommons-io-java2.6-2
ii libcommons-logging-java 1.2-2
ii libcommons-math-java 2.2-7
ii libcommons-net-java 3.6-1
ii libgoogle-gson-java 2.8.6-1
ii libguava-java 29.0-5
ii libhtsjdk-java2.22.0+dfsg-1
ii libhttpclient-java4.5.11-1
ii libhttpcore-java 4.4.13-1
ii libjama-java 1.0.3-1
ii libjargs-java 1.0.0-5
ii libjaxb-api-java 2.3.1-1
ii libjaxp1.3-java 1.3.05-5
ii libjcommon-java 1.0.23-1
ii
Bug#968762: matchbox-desktop FTCBFS: configures for the build architecture
Source: matchbox-desktop Version: 2.2+git20200512-1 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs matchbox-desktop fails to cross build from source, because it does not pass --host to ./configure. The easiest way of doing so - using dh_auto_configure - mkaes matchbox-desktop cross buildable. Please consider applying the attached patch. Helmut diff --minimal -Nru matchbox-desktop-2.2+git20200512/debian/changelog matchbox-desktop-2.2+git20200512/debian/changelog --- matchbox-desktop-2.2+git20200512/debian/changelog 2020-06-15 17:49:49.0 +0200 +++ matchbox-desktop-2.2+git20200512/debian/changelog 2020-08-21 06:59:10.0 +0200 @@ -1,3 +1,10 @@ +matchbox-desktop (2.2+git20200512-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Let dh_auto_configure pass --host to ./configure. (Closes: #-1) + + -- Helmut Grohne Fri, 21 Aug 2020 06:59:10 +0200 + matchbox-desktop (2.2+git20200512-1) unstable; urgency=medium * New upstream release from Yocto Project git. diff --minimal -Nru matchbox-desktop-2.2+git20200512/debian/rules matchbox-desktop-2.2+git20200512/debian/rules --- matchbox-desktop-2.2+git20200512/debian/rules 2020-06-15 17:49:49.0 +0200 +++ matchbox-desktop-2.2+git20200512/debian/rules 2020-08-21 06:59:09.0 +0200 @@ -6,4 +6,4 @@ dh $@ override_dh_auto_configure: - ./configure --prefix=/usr --enable-startup-notification --sysconfdir=/etc + dh_auto_configure -- --enable-startup-notification
Bug#646683: Kann ich Ihnen vertrauen?
Hallo, ich bin Omar Ali, ich bin Banker hier in Dubai. Ich habe Sie bezüglich eines Kontos eines Staatsbürgers Ihres Landes kontaktiert. Dieser Mann starb vor 12 Jahren und erwähnte niemanden, der sein bei unserer Bank hinterlegtes Geld geerbt hatte. Die Bank erlaubte mir, den nächsten Verwandten mit einem verstorbenen Kunden zu finden, aber ich fand ihn nicht. Dieses Konto wird beschlagnahmt, wenn niemand erklärt, dass das Bankkonto der nächste Angehörige ist. Ich habe mich daher entschlossen, Sie zum gegenseitigen Nutzen zu kontaktieren. Ich warte auf Ihre Antwort für weitere Details. Respektvoll, Omar Ali
Bug#968438: Should this really be RC?
On 2020-08-20 22:44, Lisandro Damián Nicanor Pérez Meyer wrote: severity 968438 normal thanks The problem might also come from previous configuration, both a fellow co maintainer and I tried to create annotations and they worked. Yes, they are now presented as a toolbar, but they are there. And moreover the buttons do what they are intended to do. ... All in all this is at most a normal bug which might be triggered by previous configs (I'm still speculating), but definitely a normal bug. Drew: please try the above, you might be able to solve the issue for other people too. Inspecting config files, there's .config/okularrc but there's also .config/okularpartrc I find I can reproduce (and eliminate) the bug by removing the second config file .config/okularpartrc Removing it, the functions operate as labelled. Reinstating it, the functions break as reported. So removing .config/okularpartrc works around the bug. Drew
Bug#924179: Info received (Bug#924179: marked as done (Package: installation-reports))
But not over 300 emails in 10 minutes, that's too much, sorry, that doesn't work. Then I say stop have been tracking it for a long time but haven't followed 300 emails in such a short time Thanks On 21.08.20 05:33, Debian Bug Tracking System wrote: Thank you for the additional information you have supplied regarding this Bug report. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Debian Install Team If you wish to submit further information on this problem, please send it to 924...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system.
Bug#924179: marked as done (Package: installation-reports)
Am 21.08.2020 05:06, schrieb Debian Bug Tracking System: Your message dated Fri, 21 Aug 2020 04:58:02 +0200 with message-id <20200821045802.07acb7c9ded347064600d...@mailbox.org> and subject line Re: Mass-closing old installation-report bugs --- round 5 has caused the Debian Bug report #924179, regarding Package: installation-reports to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) Pleas stopp aim not mor 5 Minuts are 100 Emails aim not good stop
Bug#870331: marked as done (installation-reports: Fails to install grub in the MBR of second device via menu item)
Aim stop On 21.08.20 05:04, Debian Bug Tracking System wrote: Your message dated Fri, 21 Aug 2020 04:58:02 +0200 with message-id <20200821045802.07acb7c9ded347064600d...@mailbox.org> and subject line Re: Mass-closing old installation-report bugs --- round 5 has caused the Debian Bug report #870331, regarding installation-reports: Fails to install grub in the MBR of second device via menu item to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.)
Bug#963659: pybind11: FTBFS with Sphinx 3.1: File "/usr/lib/python3/dist-packages/sphinx/domains/c.py", line 3093, in object_type / raise NotImplementedError())
Still failing with breathe 4.20.0-1 (and sphinx 3.2.1-1, pybind11 2.5.0-4).
Bug#968761: mailutils: not binnmu safe.
Package: mailutils
Version: 1:3.9-3.2
Tags: patch
I run a derivative called raspbian and I noticed that mailutils was getting
repeatedly
binnmu'd by our autobinnmuer because the binary packages were not installable.
I don't know what exactly triggered the first binnmu (our autobinnmuer does
suffer from
some false-positives) but the repeated binnmus were being caused by the package
not
being binnmu safe, so after the first binnmu libmailutils6 was not installable.
Specifically the dependencies on libmu-dbm6 (= ${source:Version}) should
instead be
dependencies on libmu-dbm6 (= ${binary:Version}). Please consider changing them
in
your next upload.
Bug#966649: Request for feedback on upload_history re-implementation
On Thu, Aug 20, 2020, 05:45 Lucas Nussbaum wrote: > Hi Asheesh, > Hi! :) > > I think that the changes compared to the current table structure should > be minimized, to avoid rewrite all tools that use this data. > Improvements are welcomed of course, but please don't make changes if > there's no good reason for them. > Good call. I'll prioritize that. > Did you confirm with DSA that parsing the online list archives is the > preferred way to go? I fear that we will hit some HTTP rate limiting at > some point and will have to reconsider the implementation. > I haven't yet! I can do so. I will try to optimize the current approach first since I'm enthusiastic about it, but good call on checking with DSA. > How optimized is your code for running every few minutes? Ideally we > would like near-real-time updates of this data, we will require polling > the list archives (previously, email was received directly on > ullmann.debian.org via a special email address) > It's a good question. Let me update you about that once I've optimized further. I think I can get down to one HTTP call at start when nothing changes (mailing list index page) and down to 2 (index page plus message page) if there is a change. Running every 2 min (say) would mean 24*30 = 720 requests per day, which seems well below any rate limit I can think of, but obviously 0 unnecessary requests is nicer. It's a good topic to discuss with DSA, and I can do that. Even if the inbound email is used for fresh data, historic data needs to come from somewhere. I think the email archives on the web are a good place to import those, based on my preference to develop in a context that doesn't require any special setup. Hope you're doing well! Asheesh. >
Bug#907576: . push. dream --A Software Digital Radio Mondiale
Yes the correct host turned out to be when I tried it: ssh://g...@salsa.debian.org/debian-hamradio-team/dream.git I had pasted an rsa key the other day. For some reason Salsa responded with an ED25519 and would not authorize. So I had to create and paste an new ED25519 to get authentication. Initially it worked. Now all of the sudden Salsa denies permission on the ED too (for no reason I can think of). I created a new ED and tried to add paste it. The Add button refuses to ungray and add. I deleted the first thinking it might let me add then but no luck. Acts like it's blocking (the button first flashes green then turns gray). My Salsa account got completed as https://salsa.debian.org/GMiller/dream. That may not be quite what was intended. I followed the instructions per the page that popped up for Project ID 52290 (I think this follows what you said in your email). I did a git clone g...@salsa.debian.org:GMiller/dream.git. I forget but it may have responded repo already existed, then those commands following which seem to have wiped the COMMIT_EDITMSG file (hope that's not a problem). Then if I interpret this correctly I did (the last line): git push -u (which means --set-upstream) ssh://salsa.debian.org/GMiller/dream.git master aiming for my account. I think that's correct for a start. And of course permission denied again (publickey). Well I beg your patience on this. I'll get it somehow. Getting tired so I'll try again tomorrow. garie Sent with [ProtonMail](https://protonmail.com) Secure Email.
Bug#968760: CONFIG_USB_NET_AQC111 is not enabled
Package: linux Version: 5.7.10-1-amd64 Severity: minor I would like to use my USB 5gbe adapter with Debian (QNA-UC5G1T). However the USB network module for AQC111 chipsets is not enabled in the default Debian kernel, CONFIG_USB_NET_AQC111. Please consider enabling :) Thanks, JM
Bug#968759: Chromium is supposedly missing some patches that would allow GeForce Now web app to work
Package: chromium Version: 83.0.4103.116-3+b1 Severity: normal GeForce Now has recently released a web app version of their service for Chrome OS. Some have confirmed that it works on Linux in Google Chrome and in a few of Chromium-based browsers, as long as you change User-Agent to that of Chrome OS to make the website let you through[1]. It also works in Freeworld Chromium[2], which is a Chromium with some vaapi and widevine patches applied[3]. Chromium on Testing and Sid has vaapi enabled and I have put libwidevinecdm.so at ~/.local/lib/libwidevinecdm.so as per README.Debian instructions, so I have expected it to work. However, I'm unable to get GeForce Now working. When starting a game and sitting though the free tier waiting queue, GeForce Now webwise says: "ERROR CODE: 0xC0F2220E" - the same error code that a Fedora user solved by using Freeworld Chromium instead of Fedora's Chromium[2]. Perhaps Debian's Chromium is missing some patches to get this working, given that Freeworld Chromium reportedly works? Debian Testing, amd64, Intel i7-2600K iGPU. [1] https://old.reddit.com/r/GeForceNOW/comments/ichfaw/guide_play_gfn_play_on_any_computer_via_chrome/ [2] https://www.gamingonlinux.com/2020/08/nvidia-geforce-now-adds-chromebook-support-so-you-can-run-it-on-linux-too/page=2#r187904 [3] https://github.com/rpmfusion/chromium-freeworld
Bug#968758: lintian: Explore Emacs integration (lintian-mode)
Package: lintian Severity: normal Owner: Sean Whitton Hi, Sean uses Lintian in eshell. It would be great if we could provide a lintian mode in Emacs. Similar to the old info system, it could provide clickable links for tag definitions, and perhaps even the reference citations. Thanks to Sean Whitton for the idea! Kind regards Felix Lechner
Bug#968757: command-not-found: breaks apt-get update
Package: command-not-found Version: 18.04.5-1 Severity: critical Justification: breaks unrelated software % apt-get update Hit:1 http://raspbian.raspberrypi.org/raspbian buster InRelease Hit:2 http://archive.raspberrypi.org/debian buster InRelease Traceback (most recent call last): File "/usr/lib/cnf-update-db", line 26, in col.create(db) File "/usr/share/command-not-found/CommandNotFound/db/creator.py", line 94, in create self._fill_commands(con) File "/usr/share/command-not-found/CommandNotFound/db/creator.py", line 132, in _fill_commands self._parse_single_contents_file(con, f, fp.stdout) File "/usr/share/command-not-found/CommandNotFound/db/creator.py", line 271, in _parse_single_contents_file priority = component_priorities[component] KeyError: 'rpi' Reading package lists... Done E: Problem executing scripts APT::Update::Post-Invoke-Success 'if /usr/bin/test -w /var/lib/command-not-found/ -a -e /usr/lib/cnf-update-db; then /usr/lib/cnf-update-db > /dev/null; fi' E: Sub-process returned an error code -- System Information: Distributor ID: Raspbian Description:Raspbian GNU/Linux 10 (buster) Release:10 Codename: buster Architecture: armv6l Kernel: Linux 4.19.118+ Kernel taint flags: TAINT_CRAP Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages command-not-found depends on: ii apt-file 3.2.2 ii lsb-release 10.2019051400+rpi1 ii python3 3.7.3-1 ii python3-apt 1.8.4.1 command-not-found recommends no packages. Versions of packages command-not-found suggests: pn snapd
Bug#968712: sysctl.conf: IPv6 accept_redirect not honored
reassign 968712 linux-signed-amd64 retitle 968712 IPv6 default accept_redirect not honoured thankyou Hi, This isn't a procps bug for two reasons. 1) It looks like you are using systemd, so the program doing the changes would be systemd-sysctl 2) Either program merely writes the value to the "default" or "all" sysctl file, its not sysctl's job to transfer it to the relevant interface. I've re-assigned it to the kernel, because that's where the copying occurs. On Fri, 21 Aug 2020 at 00:15, Testinstall wrote: > c) Check the values in /proc - some interfaces are still 1 (some real > interfaces, not just loopback). $ for f in `ls -1 /proc/sys/net/ipv6/conf/*/accept_redirects` ; do echo -n $f'=' ; cat $f ; done /proc/sys/net/ipv6/conf/all/accept_redirects=0 /proc/sys/net/ipv6/conf/default/accept_redirects=0 /proc/sys/net/ipv6/conf/eno1/accept_redirects=1 /proc/sys/net/ipv6/conf/lo/accept_redirects=1 /proc/sys/net/ipv6/conf/virbr0/accept_redirects=0 /proc/sys/net/ipv6/conf/virbr0-nic/accept_redirects=0 /proc/sys/net/ipv6/conf/wlo1/accept_redirects=0 Breaking this down: The first two lines are zero, that's the entire job of sysctl or systemd-sysctl done. The interfaces except eno and lo have 0, this is expected behaviour. eno1 and lo have 1, this is not expected. Oddly enough it seems they won't ever change, maybe by design? # echo 0 > /proc/sys/net/ipv6/conf/all/accept_redirects # cat /proc/sys/net/ipv6/conf/eno1/accept_redirects 1 # echo 1 > /proc/sys/net/ipv6/conf/all/accept_redirects # echo 0 > /proc/sys/net/ipv6/conf/all/accept_redirects # cat /proc/sys/net/ipv6/conf/eno1/accept_redirects 1 Directly writing to it makes it work. # echo 0 > /proc/sys/net/ipv6/conf/eno1/accept_redirects # cat /proc/sys/net/ipv6/conf/eno1/accept_redirects 0
Bug#968756: inkscape: Inkscape crash on multiple undo-redo actions
Package: inkscape Version: 1.0-1~bpo10+1 Severity: critical Tags: upstream Justification: breaks unrelated software Dear Maintainer, Inkscape crashes, recently causing Thunar to crash _too_. The crash happens when many undo and redo actions are performed consecutively. At first, I thought it was a one-time bug so I tried using the bpo. Once again, under the same conditions, Inkscape crashed. Finally, I tried using the 1.0 AppImage (to test "sterile" and see if this was Debian-specific or Inkscape in general). The result is the same. Since it wasn't a "world-ender" bug, I went back to using the native Debian bpo and decided to just save a lot (side-note: auto-save and recovery still occasionally fails). Earlier tonight, something serious happened; it crashed all instances of Thunar. Clearly this bug seems to be worse than I thought -- apologies for not reporting it sooner. Sadly, this bug is not absolutely reproducible. It has only happened a few times, always under the same conditions though. It may be related to other similar bugs involving memory access errors. I have noticed only complex SVGs do this (memory/cache?). The errors (see below) point to the problem being Inkscape-specific (the core lib), so it's very concerning that there's this "domino effect". Here's the relevant dmesg outputs: inkscape[18142]: segfault at 148 ip 7efbfefec5db sp 7ffb9620 error 4 in libinkscape_base.so[7efbfe58a000+bb] traps: inkscape[28062] general protection fault ip:7efbfeed39a1 sp:7ffb8520 error:0 in libinkscape_base.so[7efbfe58a000+bb] If I have time, I'll try running Inkscape and Thunar from two consoles and try to reproduce the error. Hopefully it'll shed some light on it. Hopefully still, I won't need to. Regards, Jason -- System Information: Debian Release: 10.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-0.bpo.4-amd64 (SMP w/12 CPU cores) Locale: LANG=en_ZA.UTF-8, LC_CTYPE=en_ZA.UTF-8 (charmap=UTF-8), LANGUAGE=en_ZA:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages inkscape depends on: ii libaspell150.60.7~20110707-6 ii libatk1.0-02.30.0-2 ii libatkmm-1.6-1v5 2.28.0-2 ii libc6 2.28-10 ii libcairo-gobject2 1.16.0-4 ii libcairo2 1.16.0-4 ii libcairomm-1.0-1v5 1.12.2-4 ii libcdr-0.1-1 0.1.5-1 ii libdbus-1-31.12.20-0+deb10u1 ii libdbus-glib-1-2 0.110-4 ii libdouble-conversion1 3.1.0-3 ii libenchant1c2a 1.6.0-11.1+b1 ii libfontconfig1 2.13.1-2 ii libfreetype6 2.9.1-3+deb10u1 ii libgc1c2 1:7.6.4-0.4 ii libgcc11:8.3.0-6 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libgdl-3-5 3.28.0-2 ii libglib2.0-0 2.58.3-2+deb10u2 ii libglibmm-2.4-1v5 2.58.0-2 ii libgomp1 8.3.0-6 ii libgsl23 2.5+dfsg-6 ii libgslcblas0 2.5+dfsg-6 ii libgtk-3-0 3.24.5-1 ii libgtkmm-3.0-1v5 3.24.0-2 ii libgtkspell3-3-0 3.0.9-3 ii libharfbuzz0b 2.3.1-1 ii libice62:1.0.9-2 ii libjpeg62-turbo1:1.5.2-2+b1 ii liblcms2-2 2.9-3 ii libmagick++-6.q16-88:6.9.10.23+dfsg-2.1+deb10u1 ii libmagickcore-6.q16-6 8:6.9.10.23+dfsg-2.1+deb10u1 ii libmagickwand-6.q16-6 8:6.9.10.23+dfsg-2.1+deb10u1 ii libpango-1.0-0 1.42.4-8~deb10u1 ii libpangocairo-1.0-01.42.4-8~deb10u1 ii libpangoft2-1.0-0 1.42.4-8~deb10u1 ii libpangomm-1.4-1v5 2.42.0-2 ii libpng16-161.6.36-6 ii libpoppler-glib8 0.71.0-5 ii libpoppler82 0.71.0-5 ii libpotrace01.15-1 ii librevenge-0.0-0 0.0.4-6 ii libsigc++-2.0-0v5 2.10.1-2 ii libsm6 2:1.2.3-1 ii libsoup2.4-1 2.64.2-2 ii libstdc++6 8.3.0-6 ii libvisio-0.1-1 0.1.6-1+b2 ii libwpg-0.3-3 0.3.3-1 ii libx11-6 2:1.6.7-1 ii libxext6 2:1.3.3-1+b2 ii libxml22.9.4+dfsg1-7+b3 ii libxslt1.1 1.1.32-2.2~deb10u1 ii python33.7.3-1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages inkscape recommends: ii aspell 0.60.7~20110707-6 ii fig2dev 1:3.2.7a-5+deb10u3 ii imagemagick 8:6.9.10.23+dfsg-2.1+deb10u1 ii imagemagick-6.q16 [imagemagick] 8:6.9.10.23+dfsg-2.1+deb10u1 ii libimage-magick-perl 8:6.9.10.23+dfsg-2.1+deb10u1 ii libwmf-bin 0.2.8.4-14 ii python3-lxml 4.3.2-1 ii python3-numpy1:1.16.2-1 ii python3-scour0.37-2 Versions of packages inkscape suggests: pn dia pn
Bug#968718: ITP: wims-lti -- gateway server that links LMSs to WIMS servers, using LTI
On 2020-08-20 17:22 +0200, Georges Khaznadar wrote: > * Package name: wims-lti > Description : gateway server that links LMSs to WIMS servers, using LTI > > WIMS-LTI is a gateway server that links LMSs to WIMS servers, using LTI. > . > A single instance of WIMS-LTI can handle a lot of LMS and WIMS servers. > . > WIMS-LTI allows : > . > - To create a WIMS class associated to a LMS' course. > - To create students corresponding to that course in the WIMS class. > - Students to connect to the WIMS server from a LMS. > - Teachers to connect to the WIMS class as supervisor or as student > from a LMS. > - To send the grades of students back to the LMS (automatically and > manually). This description needs to say what WIMS, LMS and LTI stand for. Despite using the terms repeatedly, at no point are they expanded. A package description must be understandable by someone who has never heard of LMS and WIMS (whatever they are). Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#940919: python3-cxx-dev: removal of python3-cxx-dev makes files disappear from python-cxx-dev
Followup-For: Bug #940919
Control: tag -1 pending patch
Hi,
I've just uploaded the trivial fix to DELAYED/10.
Andreas
diff -Nru pycxx-7.1.3/debian/changelog pycxx-7.1.3/debian/changelog
--- pycxx-7.1.3/debian/changelog2019-11-23 02:41:40.0 +0100
+++ pycxx-7.1.3/debian/changelog2020-08-21 01:25:21.0 +0200
@@ -1,3 +1,10 @@
+pycxx (7.1.3-0.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add missing Breaks. (Closes: #940919)
+
+ -- Andreas Beckmann Fri, 21 Aug 2020 01:25:21 +0200
+
pycxx (7.1.3-0.1) unstable; urgency=medium
* Non-maintainer upload.
@@ -378,4 +385,3 @@
* Initial Release.
-- Matthias Klose Fri, 3 Dec 2004 17:16:12 +0100
-
diff -Nru pycxx-7.1.3/debian/control pycxx-7.1.3/debian/control
--- pycxx-7.1.3/debian/control 2019-11-23 02:41:40.0 +0100
+++ pycxx-7.1.3/debian/control 2020-08-21 01:22:10.0 +0200
@@ -17,6 +17,7 @@
Architecture: all
Depends: python3-dev, ${misc:Depends}, ${python3:Depends}
Suggests: pkg-config
+Breaks: python-cxx-dev (<< 7.0.3-3)
Replaces: python-cxx-dev (<< 7.0.3-3)
Description: Set of facilities to extend Python3 with C++
PyCXX is a set of C++ facilities to make it easier to write Python3
Bug#953875: runit - default installation wants to remove systemd
Dear maintainer, A couple days ago a man through a chat told us that he broke his newly installed Debian stable several times after following instructions for installation of Git. We even suggested him to check his disk for bad sectors (which he did), since we didn't think that was possible, and suggested him to check his disk for bad sectors. Indeed https://github.com/git-guides/install-git recommends to install git-all, which depends on git-daemon-run, which depends on runit, which prefers runit-sysv over runit-systemd. This removes libpam-systemd and systemd-sysv. This also has been reported on #934646, though really the bug is on this package order of preference. Please fix it as soon as you can. Thanks for your labor! Felix.
Bug#787063: klibc: FTBFS with clang instead of gcc
Control: tag -1 - upstream wontfix On Thu, 28 May 2015 18:13:02 +0800 Joseph Lee wrote: > Hello, > > I was trying to rebuild klibc with clang, not use it as libc. It failed > because clang can not find some header files when building. I tried to fix > this by add something in makefile. > > And because of libklibc is needed by Debian to boot, I need to rebuild it > to produce a bootable Debian. As of version 2.0.8, it is possible to build klibc with Clang on at least some architectures. I don't what is the recommended way to build Debian packages with a non-default compiler, so I haven't tested whether that will now work. If you still care about this, and changes are needed in the Debian package, I am open to considering a patch. Ben. -- Ben Hutchings Logic doesn't apply to the real world. - Marvin Minsky signature.asc Description: This is a digitally signed message part
Bug#968755: network-manager: Privacy settings should again be enabled by default
Package: network-manager Version: 1.26.2-1 Severity: important Tags: ipv6 security patch X-Debbugs-Cc: Debian Security Team Dear maintainer, This is basically a follow-up for bug 622845 from 2013, where people wanted IPv6 privacy extensions enabled by default for desktops/laptops but not for servers, and the "solution" was to rely on network-manager doing this because it's often installed on such systems. It also obsoletes bug 668462. Problem is, for a long time now the behaviour of NM is different than in 2013. It allows setting "ip6-privacy" per connection, which works and is mirrored to the connections sysctl use_tempaddr too (on connecting). If that setting is not set or -1 in the connection config file, it searches global configs in /etc/NetworkManager If it's still not there, it finally reads from /proc/sys/net/ipv6/conf/default/use_tempaddr which is default 0 in Debian (for server use cases). Therefore, effectively, using NM does NOT use privacy extentions by default, for years now. Please change /etc/NetworkManager/NetworkManager.conf or add some file in /etc/NetworkManager/conf.d/ in Debian packets, where ip6-privacy=2 is set, so that average non-server users finally are better protected against tracking again. Thank you -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages network-manager depends on: ii adduser 3.118 ii dbus 1.12.20-1 ii libaudit11:2.8.5-3+b1 ii libbluetooth35.50-1.2 ii libc62.30-4 ii libcurl3-gnutls 7.68.0-1+b1 ii libglib2.0-0 2.64.4-1 ii libgnutls30 3.6.14-2+b1 ii libjansson4 2.13.1-1 ii libmm-glib0 1.14.0-0.1 ii libndp0 1.6-1+b1 ii libnewt0.52 0.52.21-4+b1 ii libnm0 1.26.2-1 ii libpam-systemd 246.2-1 ii libpsl5 0.21.0-1.1 ii libreadline8 8.0-4 ii libselinux1 3.1-2 ii libsystemd0 246.2-1 ii libteamdctl0 1.30-1 ii libudev1 246.2-1 ii libuuid1 2.36-2 ii policykit-1 0.105-29 ii udev 246.2-1 ii wpasupplicant2:2.9.0-13 Versions of packages network-manager recommends: ii crda 4.14+git20191112.9856751-1 ii dnsmasq-base [dnsmasq-base] 2.82-1 ii iptables 1.8.5-2 ii modemmanager 1.14.0-0.1 ii ppp 2.4.7-2+4.1+deb10u1 Versions of packages network-manager suggests: ii isc-dhcp-client 4.4.1-2.1+b2 pn libteam-utils -- no debconf information
Bug#959446: debuerreotype: Consider additionally providing images on debian infrastructure
Tianon Gravi writes: > On Sat, 2 May 2020 at 06:24, Micah Anderson wrote: >> I'm not sure that this is the right place to file this issue, but I was >> unable >> to find a better place. Feel free to redirect to a more suitable place. I >> talked >> to the debian-cloud people and they didn't think that this was their purview. > > I think an issue under [1] would probably be more correct, but this > will do (I'm not at all fond of the Debian BTS, as I always have to > look up the documentation for how to do simple things like close bugs > and even then I typically get something wrong, but such is life). > > [1]: https://github.com/debuerreotype/docker-debian-artifacts > >> I really value the debian built docker images that are available at Docker >> Hub. The fact that they are built in a reproducible fashion, and are >> available >> as "official" docker images (which means that they are verifiable through >> Docker >> Content Trust (DCT) signatures) goes a long way for reducing my paranoia. > > Additionally (and probably more critically, depending on how much > stock you put in DCT), the signatures on the Docker official images > program at large have been nonfunctional[2][3][4] for quite some time > now, so anyone using them will likely be silently getting outdated > images (which is an absolutely horrifying failure mode in itself, > IMO). > > [2]: https://github.com/docker-library/official-images/issues/6838 > [3]: https://github.com/docker-library/official-images/issues/5874 > [4]: https://github.com/docker-library/official-images/issues/1516 Thanks for these references, I wasn't aware of them. >> The reason I'm writing is because I'd like to have the option of obtaining >> these >> images from Debian directly, from a Debian controlled registry that is >> properly >> notarized to provide the same cryptographically verifiable trust chain as is >> provided through Docker Hub. >> >> Being able to verify the images from the same root of trust that the >> operating >> system depends on, would be a nice improvement. Considering that the images >> are >> essentially building Debian, on Debian, it would be nice to not have to rely >> on >> docker.io to trust the resulting images. Sure, they are signed, but the trust >> root itself is not coming from Debian itself. When I `debootstrap` from a >> debian >> system, by default, it already verifies the packages pulled automatically, >> from >> the same root of trust that the OS depends on. > > This would definitely be very nice; unfortunately, the container > ecosystem at large is very resistant to anything PGP-related, so I > don't think we'll see PGP signatures on container images being > supported any time soon. What about something far more simple... what if you, when you've built the images, created a detached signature of the image, and published it somewhere. That way it would be trivial for people to take a docker image, look at the hash, combine it with the debian keyring and your signature, and feel reasonably confident in the chain of trust being unbroken. Instead of some hopelessly complicated framework, or adding something to the container image format, just build (automatically), a file containing signatures, that is then signed and published somewhere. > However, there is some collaboration in-progress on what's being > called "Notary v2" [5], which is a re-imagining of what "container > image signing" means such that many more use cases than were solved in > v1 are being considered, and I think this is our best bet for being > able to have something like a trust root distributed as a Debian > package which can then be used to verify downloaded images. Anyone > who is interested in more information on that initiative or especially > in collaborating with those folks should check out [6]. > > [5]: https://www.docker.com/blog/community-collaboration-on-notary-v2/ > [6]: https://github.com/notaryproject/requirements Yesterday and the day before were two sessions on the status of notary v2 at kubecon: https://kccnceu20.sched.com/event/Zewy/notary-v2-introduction-and-status-report-justin-cormack-docker-omar-paul-amazon https://kccnceu20.sched.com/event/Zexw/notary-v2-outstanding-issues-working-session-justin-cormack-docker-steve-lasker-microsoft I feel like the tongue-in-cheek references to Antoni Gaudí and the Sagrada Familia in the slide deck, is very telling. Its fairly obvious that this is something that I can just ignore for another year, and hope it will be in a somewhat usable state next year, maybe However, in the meantime, the supply chain is not authenticated, and I'm afraid the perfect is being the enemy of the good here. -- micah
Bug#966922: libnitrokey: FTBFS: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below
I will take care of it. The removal isn't scheduled for almost a month, so there is plenty of time. Scott K On Thursday, August 20, 2020 12:28:17 PM EDT Jan Luca Naumann wrote: > Hey Scott, > > could you update the package? Since this is marked as RC bug, > libnitrokey and all depending packages are kicked out of testing. > > Best, > Jan > > On Mon, 03 Aug 2020 13:54:57 + Scott Kitterman > > wrote: > > This is probably a result of a new GCC version. C++ symbols can be > > painful to manage. This will be trivial to update the next time I update > > the package. > > > > Scott K > > > > On August 3, 2020 9:15:16 AM UTC, Szczepan Zalega | Nitrokey wrote: > > >On 8/3/20 10:41 AM, Lucas Nussbaum wrote: > > >> (optional=templinst|arch=!amd64 !arm64 !x32) > > >> (optional=templinst) > > > > > >Hi! > > > > > >As far as I see the problem comes from the listing format difference, > > >not the actual symbol change. > > > > > >E.g.: > > >``` > > >- (optional=templinst|arch=!amd64 !arm64 > > >!x32)_ZN8nitrokey5proto17ResponseDissectorILNS0_9CommandIDE65ERKNS0_14Dev > > >iceResponseILS2_65ENS0_12EmptyPayload24status_translate_commandB5cxx1 > > >1Ei@Base 3.5 > > >+ > > >(optional=templinst)_ZN8nitrokey5proto17ResponseDissectorILNS0_9CommandID > > >E65ERKNS0_14DeviceResponseILS2_65ENS0_12EmptyPayload24status_translat > > >e_commandB5cxx11Ei@Base 3.5 > > >``` signature.asc Description: This is a digitally signed message part.
Bug#968754: links2: please reorder link context menu top two items (follow link / open in new window)
Package: links2 Version: 2.20.2-1+b1 Severity: wishlist Tags: upstream X-Debbugs-Cc: t...@mirbsd.de I’ve got serious muscle memory from using a slightly older version of links+ on MirBSD, where I’d left-click a link to open it in the current window and right-click+Enter to open it in a new one. Unfortunately, the GNU version of links+ has a new first context menu entry when right-clicking on a link: “Follow link | Enter” was added *before* “Open in new window”. This completely breaks the muscle memory and is a regression wrt. older versions of links+. Furthermore, this isn’t even needed: when I want to follow a link, I can just left-click (or press Enter) withOUT needing to open the context menu. Therefore, please reorder the top two entries, so that right-click+Enter becomes “Open in new window” again. Thanks in advance! -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-2-amd64 (SMP w/2 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages links2 depends on: ii libbrotli1 1.0.7-7 ii libbz2-1.0 1.0.8-4 ii libc6 2.31-3 ii libcairo2 1.16.0-4 ii libdirectfb-1.7-7 1.7.7-9 ii libevent-2.1-7 2.1.12-stable-1 ii libfontconfig1 2.13.1-4.2 ii libfreetype6 2.10.2+dfsg-3 ii libglib2.0-0 2.64.4-1 ii libgomp1 10.2.0-5 ii libgpm21.20.7-6 ii libjpeg62-turbo1:2.0.5-1.1 ii liblz1 1.11-8 ii liblzma5 5.2.4-1+b1 ii libpng16-161.6.37-2 ii librsvg2-2 2.48.7-1 ii libssl1.1 1.1.1g-1 ii libtiff5 4.1.0+git191117-2 ii libx11-6 2:1.6.10-3 ii libzstd1 1.4.5+dfsg-4 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages links2 recommends: ii ca-bundle [ca-certificates]20190604 ii konsole [x-terminal-emulator] 4:20.08.0-1 ii xterm [x-terminal-emulator]358-1 links2 suggests no packages. -- no debconf information
Bug#968753: CVE-2020-13933
Source: shiro Severity: important Tags: security X-Debbugs-Cc: Debian Security Team This was assigned CVE-2020-13933: https://lists.apache.org/thread.html/r539f87706094e79c5da0826030384373f0041068936912876856835f%40%3Cdev.shiro.apache.org%3E Cheers, Moritz
Bug#968606: vte: Racy NULL-ptr segfault in vte::terminal::update_repeat_timeout()
On Tue, Aug 18, 2020 at 08:42:23PM +0100, Simon McVittie wrote: > > 1) Can the Debian CNA assign a CVE number to this issue? It is technically a > > vulnerability, and a CVE might convince the upstream developer towards more > > collaborative attitude. > > CVE IDs are a mechanism for tracking known security vulnerabilities > so that sysadmins and users can know which packages need updating or > avoiding. They are not a weapon to beat maintainers with; please don't > treat them as that. Exactly. > (Procedurally, I don't think the Debian CNA is allowed to assign CVE > numbers to vulnerabilities that are already known outside Debian.) Indeed. (Plus the use of the Debian CNA has also shifted to only apply to Debian-specific tooling (like dpkg/apt) or Debian-specific security issues) Cheers, Moritz
Bug#968752: CVE-2020-15136
Package: etcd Severity: important Tags: security X-Debbugs-Cc: Debian Security Team This was assigned CVE-2020-15136: https://github.com/etcd-io/etcd/security/advisories/GHSA-wr2v-9rpq-c35q Cheers, Moritz
Bug#968265: g++: asymptote fails to compile on m68k
Control: tags -1 - fixed-upstream On 8/12/20 8:05 AM, Hilmar Preusse wrote: > Dear Maintainer, > Remove tag. H. -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#968751: ITP: firewalk -- active network reconnaissance security tool
Package: wnpp Severity: wishlist Owner: David da Silva Polverari * Package name: firewalk Version : 5.0 Upstream Author : Mike D. Schiffman David E. Goldsmith * URL : http://packetfactory.openwall.net/projects/firewalk/ * License : BSD Programming Lang: C Description : active network reconnaissance security tool Firewalk is an active reconnaissance network security tool that attempts to determine what layer 4 protocols a given IP forwarding device will pass. This package is relevant in network security assessments. It works in a similar way to traceroute, but with extended functionality that helps in assessing the configuration of package filtering devices. I plan to maintain this package inside the Debian Security Tools Packaging Team (pkg-security), and I will need a sponsor for my package.
Bug#966302: RFS: dukpy [ITP]
Hi Sao, thanks a lot for your work on this package. On Thu, Aug 20, 2020 at 11:16:27PM +0900, Sao I Kuan wrote: > I'm looking for a sponsor for the package: > * dukpy (#966302) > > The package is on: > https://salsa.debian.org/med-team/dukpy > > The package is the last dependency of benten[1,2]. > > [1] https://github.com/rabix/benten > [2] https://bugs.debian.org/963743 > > The package has 4 lintian-overrides, which is for ignoring the > minified JavaScript source-is-missing.The package does have > autopkgtest and passed well. > > Please consider to review and sponsor this. Any kind of suggestions > are appreciated. Unfortunately that package is not that simple due to the included JS. For instance dukpy/jsmodules/typescriptServices.js should be removed from package source and rather linked against /usr/share/nodejs/typescript/lib/typescriptServices.js from package node-typescript which should be added to Depends (and may be Build- / Test-Depends). Also there are more copyright notices needed for instance for react.js. If I were you I would check the copyright files of packages like $ apt-file search react.js | grep '/react.js$' node-auto-bind: /usr/share/nodejs/auto-bind/react.js node-babel-types: /usr/share/nodejs/babel-types/lib/react.js node-babel-types: /usr/share/nodejs/babel-types/src/react.js omnidb-common: /usr/lib/python3/dist-packages/OmniDB_app/static/OmniDB_app/js/explain/react.js wordpress: /usr/share/wordpress/wp-includes/js/dist/vendor/react.js I admit I'm a bit scared about all those code copies but well, this might be a second order problem for the moment. Please simply try grep -Ri copyright to find possibly other files in the source tree to find missing source paragraphs. Sorry for the bad news that this package is not that simple. Thanks for your work again anyway Andreas. -- http://fam-tille.de
Bug#957872: tetrinet: diff for NMU version 0.11+CVS20070911-2.1
Control: tags 957872 + pending
Dear maintainer,
I've prepared an NMU for tetrinet (versioned as 0.11+CVS20070911-2.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it.
--
Regards
Sudip
diff -Nru tetrinet-0.11+CVS20070911/debian/changelog
tetrinet-0.11+CVS20070911/debian/changelog
--- tetrinet-0.11+CVS20070911/debian/changelog 2016-01-06 22:46:33.0
+
+++ tetrinet-0.11+CVS20070911/debian/changelog 2020-08-20 21:21:38.0
+0100
@@ -1,3 +1,11 @@
+tetrinet (0.11+CVS20070911-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix ftbfs with GCC-10. (Closes: #957872)
+- Thanks to Reiner Herrmann.
+
+ -- Sudip Mukherjee Thu, 20 Aug 2020 21:21:38
+0100
+
tetrinet (0.11+CVS20070911-2) unstable; urgency=medium
* Switch to source format 3.0 (quilt).
diff -Nru tetrinet-0.11+CVS20070911/debian/patches/gcc10.patch
tetrinet-0.11+CVS20070911/debian/patches/gcc10.patch
--- tetrinet-0.11+CVS20070911/debian/patches/gcc10.patch1970-01-01
01:00:00.0 +0100
+++ tetrinet-0.11+CVS20070911/debian/patches/gcc10.patch2020-08-20
21:19:08.0 +0100
@@ -0,0 +1,25 @@
+Author: Reiner Herrmann
+Description: Fix FTBFS with GCC 10
+Bug-Debian: https://bugs.debian.org/957872
+
+--- a/tetris.c
b/tetris.c
+@@ -32,6 +32,7 @@
+ signed char specials[MAX_SPECIALS] = {-1}; /* Special block inventory */
+ int next_piece; /* Next piece to fall */
+
++PieceData piecedata[7][4];
+ static struct timeval timeout;/* Time of next action */
+ int current_piece;/* Current piece number */
+ int current_rotation; /* Current rotation value */
+--- a/tetris.h
b/tetris.h
+@@ -50,7 +50,7 @@
+ char shape[4][4]; /* Shape data for the piece */
+ } PieceData;
+
+-PieceData piecedata[7][4];
++extern PieceData piecedata[7][4];
+
+ extern int current_piece, current_rotation;
+
diff -Nru tetrinet-0.11+CVS20070911/debian/patches/series
tetrinet-0.11+CVS20070911/debian/patches/series
--- tetrinet-0.11+CVS20070911/debian/patches/series 1970-01-01
01:00:00.0 +0100
+++ tetrinet-0.11+CVS20070911/debian/patches/series 2020-08-20
21:19:08.0 +0100
@@ -0,0 +1 @@
+gcc10.patch
Bug#957118: curseofwar: diff for NMU version 1.1.8-3.1
Control: tags 957118 + patch
Control: tags 957118 + pending
Dear maintainer,
I've prepared an NMU for curseofwar (versioned as 1.1.8-3.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it.
--
Regards
Sudip
diff -Nru curseofwar-1.1.8/debian/changelog curseofwar-1.1.8/debian/changelog
--- curseofwar-1.1.8/debian/changelog 2013-07-28 07:08:52.0 +0100
+++ curseofwar-1.1.8/debian/changelog 2020-08-20 21:07:49.0 +0100
@@ -1,3 +1,11 @@
+curseofwar (1.1.8-3.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix ftbfs with GCC-10. (Closes: #957118)
+- Use upstream patch, thanks to Reiner Herrmann.
+
+ -- Sudip Mukherjee Thu, 20 Aug 2020 21:07:49
+0100
+
curseofwar (1.1.8-3) unstable; urgency=low
* Initial release (Closes: #717348)
diff -Nru
curseofwar-1.1.8/debian/patches/0001-made-dirs-extern-to-compile-as-C-code-with-cmake.patch
curseofwar-1.1.8/debian/patches/0001-made-dirs-extern-to-compile-as-C-code-with-cmake.patch
---
curseofwar-1.1.8/debian/patches/0001-made-dirs-extern-to-compile-as-C-code-with-cmake.patch
1970-01-01 01:00:00.0 +0100
+++
curseofwar-1.1.8/debian/patches/0001-made-dirs-extern-to-compile-as-C-code-with-cmake.patch
2020-08-20 21:04:23.0 +0100
@@ -0,0 +1,28 @@
+From 21d071c221bc0a1a3e67f9e346f1495664d66480 Mon Sep 17 00:00:00 2001
+From: Alexey Nikolaev
+Date: Thu, 1 Aug 2013 17:25:45 -0400
+Subject: [PATCH] made dirs extern to compile as C++ code with cmake
+
+---
+
+upstream link:
https://github.com/a-nikolaev/curseofwar/commit/21d071c221bc0a1a3e67f9e346f1495664d66480
+
+ grid.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/grid.h b/grid.h
+index f3951a5..a63c342 100644
+--- a/grid.h
b/grid.h
+@@ -98,7 +98,7 @@ struct loc {
+ };
+
+ /* There are 6 possible directions to move from a tile. Hexagonal geometry. */
+-const struct loc dirs[DIRECTIONS];
++extern const struct loc dirs[DIRECTIONS];
+
+ /* struct grid
+ *
+--
+2.20.1
+
diff -Nru curseofwar-1.1.8/debian/patches/series
curseofwar-1.1.8/debian/patches/series
--- curseofwar-1.1.8/debian/patches/series 1970-01-01 01:00:00.0
+0100
+++ curseofwar-1.1.8/debian/patches/series 2020-08-20 21:04:02.0
+0100
@@ -0,0 +1 @@
+0001-made-dirs-extern-to-compile-as-C-code-with-cmake.patch
Bug#957764: rmlint: diff for NMU version 2.9.0-2.1
Control: tags 957764 + patch
Control: tags 957764 + pending
Dear maintainer,
I've prepared an NMU for rmlint (versioned as 2.9.0-2.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it.
--
Regards
Sudip
diff -Nru rmlint-2.9.0/debian/changelog rmlint-2.9.0/debian/changelog
--- rmlint-2.9.0/debian/changelog 2019-12-31 22:27:25.0 +
+++ rmlint-2.9.0/debian/changelog 2020-08-20 20:43:54.0 +0100
@@ -1,3 +1,11 @@
+rmlint (2.9.0-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix ftbfs with GCC-10. (Closes: #957764)
+- Use upstream patch, thanks to Reiner Herrmann.
+
+ -- Sudip Mukherjee Thu, 20 Aug 2020 20:43:54
+0100
+
rmlint (2.9.0-2) unstable; urgency=medium
* Replace glib-2_62.patch with upstream implementation, which
diff -Nru
rmlint-2.9.0/debian/patches/0001-fix-link-error-on-compilers-with-fno-common-enabled.patch
rmlint-2.9.0/debian/patches/0001-fix-link-error-on-compilers-with-fno-common-enabled.patch
---
rmlint-2.9.0/debian/patches/0001-fix-link-error-on-compilers-with-fno-common-enabled.patch
1970-01-01 01:00:00.0 +0100
+++
rmlint-2.9.0/debian/patches/0001-fix-link-error-on-compilers-with-fno-common-enabled.patch
2020-08-20 19:57:16.0 +0100
@@ -0,0 +1,96 @@
+From df26dc408e78c27b8119ad06b9998fd07d6c659f Mon Sep 17 00:00:00 2001
+From: Chris Pahl
+Date: Sun, 2 Feb 2020 13:38:53 +0100
+Subject: [PATCH] fix link error on compilers with -fno-common enabled
+
+---
+
+upstream link:
https://github.com/sahib/rmlint/commit/df26dc408e78c27b8119ad06b9998fd07d6c659f
+
+ lib/config.h.in | 62 ++---
+ 1 file changed, 33 insertions(+), 29 deletions(-)
+
+diff --git a/lib/config.h.in b/lib/config.h.in
+index 44d7e5d9..d9fdeabd 100644
+--- a/lib/config.h.in
b/lib/config.h.in
+@@ -121,9 +121,13 @@
+ # define N_(String) gettext_noop (String)
+ #endif
+
+-GMutex RM_LOG_MTX;
++static inline GMutex* rm_log_get_mutex(void) {{
++static GMutex RM_LOG_MTX;
++return _LOG_MTX;
++}}
+
+-#define RM_LOG_INIT g_mutex_init(_LOG_MTX);
++#define RM_LOG_INIT \
++g_mutex_init(rm_log_get_mutex());
+
+ typedef guint64 RmOff;
+
+@@ -150,33 +154,33 @@ typedef guint64 RmOff;
+
+ ///
+
+-#define rm_log_error_line(...) \
+-g_mutex_lock(_LOG_MTX); \
+-rm_log_error_prefix()\
+-rm_log_error(__VA_ARGS__); \
+-rm_log_error("\n"); \
+-g_mutex_unlock(_LOG_MTX); \
+-
+-#define rm_log_warning_line(...) \
+-g_mutex_lock(_LOG_MTX); \
+-rm_log_warning_prefix() \
+-rm_log_warning(__VA_ARGS__); \
+-rm_log_warning("\n");\
+-g_mutex_unlock(_LOG_MTX); \
+-
+-#define rm_log_info_line(...)\
+-g_mutex_lock(_LOG_MTX); \
+-rm_log_info_prefix() \
+-rm_log_warning(__VA_ARGS__); \
+-rm_log_warning("\n");\
+-g_mutex_unlock(_LOG_MTX); \
+-
+-#define rm_log_debug_line(...) \
+-g_mutex_lock(_LOG_MTX); \
+-rm_log_debug_prefix()\
+-rm_log_debug(__VA_ARGS__); \
+-rm_log_debug("\n"); \
+-g_mutex_unlock(_LOG_MTX); \
++#define rm_log_error_line(...) \
++g_mutex_lock(rm_log_get_mutex());\
++rm_log_error_prefix()\
++rm_log_error(__VA_ARGS__); \
++rm_log_error("\n"); \
++g_mutex_unlock(rm_log_get_mutex()); \
++
++#define rm_log_warning_line(...) \
++g_mutex_lock(rm_log_get_mutex());\
++rm_log_warning_prefix() \
++rm_log_warning(__VA_ARGS__); \
++rm_log_warning("\n");\
++g_mutex_unlock(rm_log_get_mutex()); \
++
++#define rm_log_info_line(...)\
++g_mutex_lock(rm_log_get_mutex());\
++rm_log_info_prefix() \
++rm_log_warning(__VA_ARGS__); \
++rm_log_warning("\n");\
++g_mutex_unlock(rm_log_get_mutex()); \
++
++#define rm_log_debug_line(...) \
++g_mutex_lock(rm_log_get_mutex());\
++rm_log_debug_prefix()\
++rm_log_debug(__VA_ARGS__); \
++rm_log_debug("\n"); \
++g_mutex_unlock(rm_log_get_mutex()); \
+
+ /* Domain for reporting errors. Needed by GOptions */
+ #define RM_ERROR_QUARK (g_quark_from_static_string("rmlint"))
+--
+2.20.1
+
diff -Nru rmlint-2.9.0/debian/patches/series rmlint-2.9.0/debian/patches/series
--- rmlint-2.9.0/debian/patches/series 2019-12-31 10:07:39.0 +
+++ rmlint-2.9.0/debian/patches/series 2020-08-20 19:57:16.0 +0100
@@ -6,3 +6,4 @@
xattr-fixes.patch
python3.8.patch
glib-2_62.patch
+0001-fix-link-error-on-compilers-with-fno-common-enabled.patch
Bug#968749: src:cfengine3: fails to migrate to testing for too long: unresolved RC bug
Source: cfengine3 Version: 3.12.1-2 Severity: serious Control: close -1 3.15.2-2 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 963341 Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:cfengine3 in its current version in unstable has been trying to migrate for 61 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=cfengine3 signature.asc Description: OpenPGP digital signature
Bug#968750: src:dulwich: fails to migrate to testing for too long: FTBFS
Source: dulwich Version: 0.20.2-1 Severity: serious Control: close -1 0.20.5-1 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 956876 Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:dulwich in its current version in unstable has been trying to migrate for 60 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=dulwich signature.asc Description: OpenPGP digital signature
Bug#968747: vim-gtk3: vim (when linked to vim-gtk3 or vim-nox) fails to start due to undefined symbol
Package: vim-gtk3 Version: 2:8.2.0716-3 Severity: grave Justification: renders package unusable After dist-upgrading Debian testing to bullseye/sid, vim/ex/gvim/etc. no longer started: vim: symbol lookup error: /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0: undefined symbol: XML_SetHashSalt A check shows that this only affects vim.gtk3 and vim.nox; vim.basic works fine. -- Package-specific info: --- real paths of main Vim binaries --- /usr/bin/vi is /usr/bin/vim.gtk3 /usr/bin/vim is /usr/bin/vim.gtk3 /usr/bin/gvim is /usr/bin/vim.gtk3 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages vim-gtk3 depends on: ii libacl1 2.2.53-8 ii libc62.31-3 ii libcairo21.16.0-4 ii libcanberra0 0.30-7 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-5 ii libglib2.0-0 2.64.4-1 ii libgpm2 1.20.7-6 ii libgtk-3-0 3.24.22-1 ii libice6 2:1.0.9-2 ii liblua5.2-0 5.2.4-1.1+b3 ii libpango-1.0-0 1.46.0-2 ii libpangocairo-1.0-0 1.46.0-2 ii libperl5.30 5.30.3-4 ii libpython3.8 3.8.5-2 ii libruby2.7 2.7.1-3 ii libselinux1 3.1-2 ii libsm6 2:1.2.3-1 ii libtcl8.68.6.10+dfsg-1 ii libtinfo66.2-1 ii libx11-6 2:1.6.10-3 ii libxt6 1:1.1.5-1+b3 ii vim-common 2:8.2.0716-3 ii vim-gui-common 2:8.2.0716-3 ii vim-runtime 2:8.2.0716-3 vim-gtk3 recommends no packages. Versions of packages vim-gtk3 suggests: ii cscope15.9-1 ii fonts-dejavu 2.37-2 ii gnome-icon-theme 3.12.0-3 ii vim-doc 2:8.2.0716-3 -- no debconf information
Bug#968748: src:goxel: fails to migrate to testing for too long: FTBFS on several archs
Source: goxel Version: 0.8.1-1 Severity: serious Control: close -1 0.10.6-1 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 964403 Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:goxel in its current version in unstable has been trying to migrate for 61 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=goxel signature.asc Description: OpenPGP digital signature
Bug#968746: ITP: libgraphics-tiff-perl -- Perl extension for the libtiff library
Package: wnpp Severity: wishlist Owner: Jeffrey Ratcliffe X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: libgraphics-tiff-perl Version : 6 Upstream Author : Jeffrey Ratcliffe * URL : https://metacpan.org/release/Graphics-TIFF * License : Artistic or GPL-1+ Programming Lang: Perl, C Description : Perl extension for the libtiff library The Graphics::TIFF module allows a Perl developer to access TIFF images. Find out more about libtiff at http://www.libtiff.org. . Perl bindings for the libtiff library. This module allows you to access TIFF images in a Perlish and object-oriented way, freeing you from the casting and memory management in C, yet remaining very close in spirit to original API. I will be maintaining this package under the umbrella of the Perl team. It is a dependency of PDF::Builder, which I will also be packaging.
Bug#968192: xkb-data: bepo_afnor missing eszett character
I spotted some more errors for caracter infinity and e as exposant see
patch attached (new patch also include previous patch)
Le 10/08/2020 à 15:08, Jean-Louis Biasini a écrit :
> Package: xkb-data
> Version: 2.29-2
> Severity: normal
> Tags: patch
>
> Dear Maintainer,
>
> the french bepo variant afnor contains an error which prevent the user from
> typing german eszett caracter ß (code ssharp)
>
> The error is easily spotable in /usr/share/X11/xkb/symbols/fr since the
> same
> mapping already exist and is correctly mapped on other variant of the
> bepo (see patch).
>
> thanks for your work,
>
> jean-louis
>
> -- System Information:
> Debian Release: bullseye/sid
> APT prefers stable-updates
> APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable'),
> (90, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
> Kernel taint flags: TAINT_USER
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE
> not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> -- no debconf information
>
--- /usr/share/X11/xkb/symbols/fr.orig 2020-08-20 18:04:04.463969291 +0300
+++ /usr/share/X11/xkb/symbols/fr.new 2020-08-20 18:04:34.700255994 +0300
@@ -627,7 +627,7 @@
key { type[group1] = "FOUR_LEVEL_SEMIALPHABETIC", [ egrave, Egrave, dead_grave, grave ] }; // è È ` `
key { type[group1] = "FOUR_LEVEL", [ dead_circumflex, exclam, exclamdown, U2620 ] }; // ^ ! ¡ ☠
key { type[group1] = "FOUR_LEVEL_SEMIALPHABETIC", [ v, V, dead_caron, U2622 ] }; // v V ˇ ☢
- key { type[group1] = "FOUR_LEVEL_SEMIALPHABETIC", [ d, D, UFDD7, U2623 ] }; // d D ∞ ☣
+ key { type[group1] = "FOUR_LEVEL_SEMIALPHABETIC", [ d, D, U221E, U2623 ] }; // d D ∞ ☣
key { type[group1] = "FOUR_LEVEL_SEMIALPHABETIC", [ l, L, dead_stroke, sterling ] }; // l L / £
key { type[group1] = "FOUR_LEVEL_SEMIALPHABETIC", [ j, J, U262E, U262F ] }; // j J ☮ ☯
key { type[group1] = "FOUR_LEVEL_SEMIALPHABETIC", [ z, Z, UFDD8, U2619 ] }; // z Z ― ☙
@@ -639,8 +639,8 @@
key { type[group1] = "FOUR_LEVEL_SEMIALPHABETIC", [ e, E, EuroSign, dead_currency ] }; // e E € ¤
key { type[group1] = "FOUR_LEVEL", [ comma, semicolon, apostrophe, dead_belowcomma ] }; // , ; ' ,
key { type[group1] = "FOUR_LEVEL_SEMIALPHABETIC", [ c, C, dead_cedilla, copyright ] }; // c C ¸ ©
- key { type[group1] = "FOUR_LEVEL_SEMIALPHABETIC", [ t, T, UFDD5, trademark ] }; // t T ᵉ ™
- key { type[group1] = "FOUR_LEVEL_SEMIALPHABETIC", [ s, S, UFDD4, U017F ] }; // s S ß ſ
+ key { type[group1] = "FOUR_LEVEL_SEMIALPHABETIC", [ t, T, U1D49, trademark ] }; // t T ᵉ ™
+ key { type[group1] = "FOUR_LEVEL_SEMIALPHABETIC", [ s, S, ssharp, U017F ] }; // s S ß ſ
key { type[group1] = "FOUR_LEVEL_SEMIALPHABETIC", [ r, R, dead_breve, registered ] }; // r R ˘ ®
key { type[group1] = "FOUR_LEVEL_SEMIALPHABETIC", [ n, N, dead_tilde, U2693 ] }; // n N ~ ⚓
key { type[group1] = "FOUR_LEVEL_SEMIALPHABETIC", [ m, M, dead_macron, U26FD ] }; // m M ¯ ⛽
Bug#968744: dpkg: [INTL:nl] Dutch po file for the dpkg package
Package: dpkg Severity: wishlist Tags: l10n patch Dear Maintainer, Please find attached the updated Dutch po file for the dpkg package. It has been submitted for review to the debian-l10n-dutch mailing list. Please add it to your next package revision. It should be put as "po/nl.po" in your package build tree. -- Kind regards, Frans Spiesschaert nl.po.gz Description: application/gzip
Bug#968745: prometheus-homeplug-exporter: [INTL:nl] Dutch translation of debconf messages
Package: prometheus-homeplug-exporter Severity: wishlist Tags: l10n patch Dear Maintainer, Please find attached the Dutch translation of prometheus-homeplug- exporter debconf messages. It has been submitted for review to the debian-l10n-dutch mailing list. Please add it to your next package revision. It should be put as debian/po/nl.po in your package build tree. -- Met vriendelijke groet, Frans Spiesschaert nl.po.gz Description: application/gzip
Bug#968742: diffoscope build-depends on package that is not in testing.
Package: diffoscope Version: 156 Severity: serious Diffoscope has been removed from testing and cannot re-enter because it build-depends on gnumeric, which has been kicked out of testing due to a python2 dependency. Since this build-dependency only appears to be used for testing I would suggest dropping it until/unless gnumeric is fixed.
Bug#968734: chiark-tcl: FTBFS with optimization level -O3 and gcc-10 on s390x
Hi. Thanks for the report.
Gianfranco Costamagna writes ("Bug#968734: chiark-tcl: FTBFS with optimization
level -O3 and gcc-10 on s390x"):
> Hello, In Ubuntu the package FTBFS on s390x, because of -O3, and some non
> initialized variables.
How odd.
> This makes no sense, because the variables are passed by reference
> to the functions, but gcc is probably not smart enough to detect it.
I think it is more likely that it can see into blockcipher_prep, but
not follow the control flow. Perhaps, for example, it doesn't know
that cht_staticerr always returns nonzero, and it thinks that those
error paths in blockcipher_prep might end up using the values in the
caller.
Instead of your suggestion, if you can easily do so, can you try
this ?
Regards,
Ian.
>From 020f536563e566c6a17eeb790d2a5e56141e2b74 Mon Sep 17 00:00:00 2001
From: Ian Jackson
Date: Thu, 20 Aug 2020 19:18:14 +0100
Subject: [PATCH] blockcipher_prep: Initialise out parameters to placate gcc
These are all set on the success exit path but GCC is not clever
enough to see this.
Closes: #968734
Signed-off-by: Ian Jackson
---
crypto/crypto.c | 8
1 file changed, 8 insertions(+)
diff --git a/crypto/crypto.c b/crypto/crypto.c
index aee2556..6efea24 100644
--- a/crypto/crypto.c
+++ b/crypto/crypto.c
@@ -252,6 +252,14 @@ static int blockcipher_prep(Tcl_Interp *ip, Tcl_Obj
*key_obj,
int rc;
CiphKeyValue *key;
+ /* placate gcc, see Debian #968734 */
+ *key_r= 0;
+ *sched_r= 0;
+ *iv_r= 0;
+ *iv_lenbytes_r= 0;
+ *buffers_r= 0;
+ *nblocks_r= 0;
+
if (data_len % alg->blocksize)
return cht_staticerr(ip, "block cipher input not whole number of blocks",
"HBYTES BLOCKCIPHER LENGTH");
--
2.20.1
Bug#961772: fossil FTCBFS: attempts to run a host tool to check for sqlite3
Oops, just saw this. Thanks for the patch. It's really an upstream issue, so I'm going to forward it there. If they don't want to merge this functionality, I'll maintain it in a Debian patch. Cheers, --Barak.
Bug#968741: linux: trace with B550I AORUS PRO AX and AMD Ryzen 5 PRO 4650G
Source: linux Severity: normal X-Debbugs-Cc: florian.laro...@gmail.com Dear Maintainer, compiling the current Debian source with a linux-5.8.2 kernel gives the following trace on a B550I AORUS PRO AX with an AMD Ryzen 5 PRO 4650G: [3.974191] [ cut here ] [3.974265] WARNING: CPU: 9 PID: 175 at drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn21/rn_clk_mgr.c:654 rn_clk_mgr_constru ct+0x11e/0x390 [amdgpu] [3.974268] Modules linked in: hid_generic(E) usbhid(E) hid(E) amdgpu(E+) gpu_sched(E) i2c_algo_bit(E) ttm(E) drm_kms_helper(E) ce c(E) ahci(E) libahci(E) nvme(E) xhci_pci(E) nvme_core(E) crc32_pclmul(E) xhci_hcd(E) r8169(E) t10_pi(E) crc32c_intel(E) realtek(E) li bata(E) crc_t10dif(E) drm(E) i2c_piix4(E) crct10dif_generic(E) mfd_core(E) crct10dif_pclmul(E) libphy(E) usbcore(E) crct10dif_common( E) scsi_mod(E) usb_common(E) wmi(E) video(E) gpio_amdpt(E) gpio_generic(E) button(E) [3.974284] CPU: 9 PID: 175 Comm: systemd-udevd Tainted: GE 5.8.0-trunk-amd64 #1 Debian 5.8.2-1 [3.974285] Hardware name: Gigabyte Technology Co., Ltd. B550I AORUS PRO AX/B550I AORUS PRO AX, BIOS F2a 06/16/2020 [3.974348] RIP: 0010:rn_clk_mgr_construct+0x11e/0x390 [amdgpu] [3.974351] Code: 00 00 00 41 8b 8c c4 80 00 00 00 41 89 c1 89 c7 85 c9 74 10 41 8b 94 c4 84 00 00 00 85 d2 0f 85 87 01 00 00 48 8 3 e8 01 73 d9 <0f> 0b 83 7b 20 01 74 0c 81 bd e8 00 00 00 ff 14 37 00 7f 27 48 8b [3.974353] RSP: 0018:a98a8068f850 EFLAGS: 00010297 [3.974355] RAX: RBX: 9a36d7eb2540 RCX: 0640 [3.974356] RDX: RSI: a98a8068f878 RDI: [3.974357] RBP: 9a3625cf9800 R08: R09: [3.974358] R10: 7fc9117f R11: 9a36d7d51000 R12: a98a8068f878 [3.974359] R13: 9a36d7eb2cc0 R14: 9a36bccc R15: 9a36d7eb2540 [3.974361] FS: 7f53ebac18c0() GS:9a371f24() knlGS: [3.974362] CS: 0010 DS: ES: CR0: 80050033 [3.974363] CR2: 7f53ebaaaee0 CR3: 0003d7f38000 CR4: 00340ee0 [3.974365] Call Trace: [3.974427] dc_clk_mgr_create+0x179/0x1a0 [amdgpu] [3.974488] dc_create+0x238/0x700 [amdgpu] [3.974493] ? _cond_resched+0x16/0x40 [3.974554] amdgpu_dm_init.isra.0+0x15b/0x1c0 [amdgpu] [3.974614] dm_hw_init+0xe/0x20 [amdgpu] [3.974676] amdgpu_device_init.cold+0x17a7/0x192b [amdgpu] [3.974722] amdgpu_driver_load_kms+0x5c/0x220 [amdgpu] [3.974766] amdgpu_pci_probe+0x15f/0x1f0 [amdgpu] [3.974770] local_pci_probe+0x42/0x80 [3.974772] ? _cond_resched+0x16/0x40 [3.974773] pci_device_probe+0xfa/0x1b0 [3.974776] really_probe+0x160/0x400 [3.974777] driver_probe_device+0xe1/0x150 [3.974779] device_driver_attach+0xa1/0xb0 [3.974780] __driver_attach+0x8a/0x150 [3.974781] ? device_driver_attach+0xb0/0xb0 [3.974782] ? device_driver_attach+0xb0/0xb0 [3.974784] bus_for_each_dev+0x78/0xc0 [3.974786] bus_add_driver+0x12b/0x1e0 [3.974787] driver_register+0x8b/0xe0 [3.974789] ? 0xc0a6b000 [3.974791] do_one_initcall+0x46/0x200 [3.974792] ? _cond_resched+0x16/0x40 [3.974794] ? kmem_cache_alloc_trace+0x192/0x220 [3.974796] ? do_init_module+0x23/0x250 [3.974798] do_init_module+0x5c/0x250 [3.974799] __do_sys_finit_module+0xac/0x110 [3.974802] do_syscall_64+0x4d/0xc0 [3.974804] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [3.974805] RIP: 0033:0x7f53ebf6ba79 [3.974807] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e7 53 0c 00 f7 d8 64 89 01 48 [3.974809] RSP: 002b:7ffde26b8228 EFLAGS: 0246 ORIG_RAX: 0139 [3.974811] RAX: ffda RBX: 55c5cb205da0 RCX: 7f53ebf6ba79 [3.974812] RDX: RSI: 7f53ec0f6e4d RDI: 0012 [3.974813] RBP: 0002 R08: R09: 55c5cb205fb8 [3.974814] R10: 0012 R11: 0246 R12: 7f53ec0f6e4d [3.974815] R13: R14: 55c5cb206e20 R15: 55c5cb205da0 [3.974817] ---[ end trace 071eac41bffe7f9b ]--- best regards, Florian La Roche -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.8.0-trunk-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#968715: xfpt: Invalid write in dot_process
Package: xfpt Version: 0.10-1 Severity: normal Dear Maintainer, running xfpt with the attached file leads to an invalid write, causing a segfault. This is the output of Valgrind (valgrind xfpt -o /dev/null ./01_invalid_write): [...] ==82== Invalid write of size 4 ==82==at 0x10BEA4: dot_process (dot.c:890) ==82==by 0x10A4DC: main (xfpt.c:172) ==82== Address 0x112000 is not stack'd, malloc'd or (recently) free'd [...] -- Regards, Luca Borzacchiello -- System Information: Debian Release: 10.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-42-generic (SMP w/12 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages xfpt depends on: ii libc6 2.28-10 xfpt recommends no packages. xfpt suggests no packages. -- no debconf information 01_invalid_write Description: Binary data
Bug#968245: [Pkg-pascal-devel] Bug#968245: Bug#968245: fpc: autopkgtest failure.
On 20/08/2020 06:50, Graham Inggs wrote: For what it's worth, I tried building fpc including your debdiff and running the autopkgtests in an Ubuntu PPA. They passed on amd64, Thanks for confirming (my local setup is far from the same as the test infrastructure) and failed on arm64 [1] and armhf [2]. Not surprising since I had only updated the expected failures for amd64. I'm running tests on i386 now, if they aren't alarmingly bad i'll update the remaining expected failures lists (i386 based on my local tests, arm32* and arm64 based on your results) and upload to Debian. Unfortunately, fpc has not been bootstrapped on ppc64el in Ubuntu yet. We don't currently have a list of expected failures for ppc64el anyway. Once fpc is otherwise in a good state i'll pop a mail to Adam Conrad asking him to bootstrap it for ppc64el Ubuntu. * The expected failure lists seem to be stored by fpc architecture not upstream architecture so afaict armel and armhf would use the same expected failure list. I doubt anyone is actually running the autopkgtest on armel though.
Bug#968740: CVE-2020-15106 CVE-2020-15112 CVE-2020-15113 CVE-2020-15114 CVE-2020-15115
Package: etcd Severity: grave Tags: security X-Debbugs-Cc: Debian Security Team Multiple issues were reported against etcd: CVE-2020-15115: https://github.com/etcd-io/etcd/security/advisories/GHSA-4993-m7g5-r9hh CVE-2020-15114: https://github.com/etcd-io/etcd/security/advisories/GHSA-2xhq-gv6c-p224 CVE-2020-15113: https://github.com/etcd-io/etcd/security/advisories/GHSA-chh6-ppwq-jh92 CVE-2020-15112: https://github.com/etcd-io/etcd/security/advisories/GHSA-m332-53r6-2w93 CVE-2020-15106: https://github.com/etcd-io/etcd/security/advisories/GHSA-p4g4-wgrh-qrg2
Bug#904013: clamav-freshclam: it breaks also logcheck integration
Package: clamav-freshclam
Version: 0.102.4+dfsg-0+deb10u1
Followup-For: Bug #904013
Dear Maintainer,
logging the timestamp inside the message break also the logcheck rules.
For example the first logcheck (ignore.d.server) rule states:
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ freshclam\[[0-9]+\]: ClamAV update process
started at .*$
But the message written in the logs is:
Aug 20 18:26:53 mail freshclam[15525]: Thu Aug 20 18:26:53 2020 -> ClamAV
update process started at Thu Aug 20 18:26:53 2020
As you can see, the timestamp written after the process id is NOT matched by
the logcheck rule.
You can solve the issue by altering all the rules, inserting a regexp to match
the timestamp as follows:
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ freshclam\[[0-9]+\]: \w{3} \w{3} [ :0-9]{16}
-> ClamAV update process started at .*$
But the best thing, imho is to avoid printing the timestamp inside the message,
since rsyslog already writes the timestamp at the beginning of the log record.
Thanks,
Luca
-- Package-specific info:
--- configuration ---
Checking configuration files in /etc/clamav
Config file: clamd.conf
---
AlertExceedsMax disabled
PreludeEnable disabled
PreludeAnalyzerName = "ClamAV"
LogFile = "/var/log/clamav/clamav.log"
LogFileUnlock disabled
LogFileMaxSize = "4294967295"
LogTime = "yes"
LogClean disabled
LogSyslog disabled
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
LogRotate = "yes"
ExtendedDetectionInfo = "yes"
PidFile disabled
TemporaryDirectory disabled
DatabaseDirectory = "/var/lib/clamav"
OfficialDatabaseOnly disabled
LocalSocket = "/var/run/clamav/clamd.ctl"
LocalSocketGroup = "clamav"
LocalSocketMode = "666"
FixStaleSocket = "yes"
TCPSocket disabled
TCPAddr disabled
MaxConnectionQueueLength = "15"
StreamMaxLength = "26214400"
StreamMinPort = "1024"
StreamMaxPort = "2048"
MaxThreads = "12"
ReadTimeout = "180"
CommandReadTimeout = "5"
SendBufTimeout = "200"
MaxQueue = "100"
IdleTimeout = "30"
ExcludePath disabled
MaxDirectoryRecursion = "15"
FollowDirectorySymlinks disabled
FollowFileSymlinks disabled
CrossFilesystems = "yes"
SelfCheck = "3600"
DisableCache disabled
VirusEvent disabled
ExitOnOOM disabled
AllowAllMatchScan = "yes"
Foreground disabled
Debug disabled
LeaveTemporaryFiles disabled
User = "clamav"
Bytecode = "yes"
BytecodeSecurity = "TrustSigned"
BytecodeTimeout = "6"
BytecodeUnsigned disabled
BytecodeMode = "Auto"
DetectPUA disabled
ExcludePUA disabled
IncludePUA disabled
ScanPE = "yes"
ScanELF = "yes"
ScanMail = "yes"
ScanPartialMessages disabled
PhishingSignatures = "yes"
PhishingScanURLs = "yes"
HeuristicAlerts = "yes"
HeuristicScanPrecedence disabled
StructuredDataDetection disabled
StructuredMinCreditCardCount = "3"
StructuredMinSSNCount = "3"
StructuredSSNFormatNormal = "yes"
StructuredSSNFormatStripped disabled
ScanHTML = "yes"
ScanOLE2 = "yes"
AlertBrokenExecutables disabled
AlertEncrypted disabled
AlertEncryptedArchive disabled
AlertEncryptedDoc disabled
AlertOLE2Macros disabled
AlertPhishingSSLMismatch disabled
AlertPhishingCloak disabled
AlertPartitionIntersection disabled
ScanPDF = "yes"
ScanSWF = "yes"
ScanXMLDOCS = "yes"
ScanHWP3 = "yes"
ScanArchive = "yes"
ForceToDisk disabled
MaxScanTime = "12"
MaxScanSize = "104857600"
MaxFileSize = "26214400"
MaxRecursion = "16"
MaxFiles = "1"
MaxEmbeddedPE = "10485760"
MaxHTMLNormalize = "10485760"
MaxHTMLNoTags = "2097152"
MaxScriptNormalize = "5242880"
MaxZipTypeRcg = "1048576"
MaxPartitions = "50"
MaxIconsPE = "100"
MaxRecHWP3 = "16"
PCREMatchLimit = "1"
PCRERecMatchLimit = "5000"
PCREMaxFileSize = "26214400"
OnAccessMountPath disabled
OnAccessIncludePath disabled
OnAccessExcludePath disabled
OnAccessExcludeRootUID disabled
OnAccessExcludeUID disabled
OnAccessExcludeUname disabled
OnAccessMaxFileSize = "5242880"
OnAccessDisableDDD disabled
OnAccessPrevention disabled
OnAccessExtraScanning disabled
OnAccessCurlTimeout = "5000"
OnAccessMaxThreads = "5"
OnAccessRetryAttempts disabled
OnAccessDenyOnError disabled
DevACOnly disabled
DevACDepth disabled
DevPerformance disabled
DevLiblog disabled
DisableCertCheck disabled
AlgorithmicDetection = "yes"
BlockMax disabled
PhishingAlwaysBlockSSLMismatch disabled
PhishingAlwaysBlockCloak disabled
PartitionIntersection disabled
OLE2BlockMacros disabled
ArchiveBlockEncrypted disabled
Config file: freshclam.conf
---
LogFileMaxSize = "4294967295"
LogTime = "yes"
LogSyslog disabled
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
LogRotate = "yes"
PidFile disabled
DatabaseDirectory = "/var/lib/clamav"
Foreground disabled
Debug disabled
UpdateLogFile = "/var/log/clamav/freshclam.log"
DatabaseOwner = "clamav"
Checks = "24"
DNSDatabaseInfo = "current.cvd.clamav.net"
DatabaseMirror = "db.local.clamav.net", "database.clamav.net"
PrivateMirror disabled
MaxAttempts = "5"
ScriptedUpdates = "yes"
TestDatabases = "yes"
CompressLocalDatabase disabled
ExtraDatabase disabled
ExcludeDatabase disabled
DatabaseCustomURL disabled
HTTPProxyServer disabled
Bug#907576: . push. dream --A Software Digital Radio Mondiale
OK I see here in gittutorial. Is GMIller a good name to push my branch (instead of master)? I'm guessing the other problem is that I don't have the Salsa public key. If correct I will have to get it somehow. garie Sent with [ProtonMail](https://protonmail.com) Secure Email.
Bug#968441: partman-auto: Default /boot partition size is too small
Control: unarchive 893886 Control: forcemerge 893886 -1 On Sat, 2020-08-15 at 12:56 +0200, Pablo R wrote: > Package: partman-auto > Severity: normal > > Dear Maintainer, > > I recently assisted a friend in her installation of Debian over the > phone. > Going through manual partitionning over the phone would be too > bothersome so I told her to use the automated partitionning option > that uses a whole disk with LVM and encryption. > > Everything went well except that a few weeks later my friend's > computer would not boot: apparently, a kernel update had gone wrong > because the /boot partition was full. > Of course my friend did not see the problem during the update because > she did not know she had to pay attention to that. > > I had the same problem myself a bit more than 10 years ago, and since > then I always do partitioning manually during installs so I did not > know until then that too small /boot partition was still a thing. > > The default should probably be like 1GB or even 2GB to be safe :). [...] This is fixed in the current version of partman-auto, though not (yet) in stable. Ben. -- Ben Hutchings Logic doesn't apply to the real world. - Marvin Minsky signature.asc Description: This is a digitally signed message part
Bug#968568: ipp-usb: Should depend on avahi-daemon
Control: tags -1 +pending Le lundi, 17 août 2020, 19.47:05 h CEST Brian Potkin a écrit : > An installation of ipp-usb is crippled when the device is not discoverable > on the the loopback interface. avahi-daemon is needed to expose it on any > interface. Oh, clearly this is a bug, as there's a Wants= , the Dependency is a must. > I also wonder whether ipp-usb.service should have > > Wants=avahi-daemon.service > > replaced by > > Requires=avahi-daemon.service That's somewhat of an upstream question. I don't think it really has a concrete difference, or does it? > There is a precedent in #82745. What bug is this ? :-) -- OdyX signature.asc Description: This is a digitally signed message part.
Bug#957657: packeth: diff for NMU version 1.6.5-2.1
Control: tags 957657 + patch Control: tags 957657 + pending Dear maintainer, I've prepared an NMU for packeth (versioned as 1.6.5-2.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should cancel or delay it longer. Regards. diff -Nru packeth-1.6.5/debian/changelog packeth-1.6.5/debian/changelog --- packeth-1.6.5/debian/changelog 2011-09-13 10:10:02.0 -0300 +++ packeth-1.6.5/debian/changelog 2020-08-20 15:05:18.0 -0300 @@ -1,3 +1,11 @@ +packeth (1.6.5-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * debian/rules: added -fcommon to CFLAGS as a workaround +to fix a FTBFS with GCC-10. (Closes: #957657) + + -- Joao Eriberto Mota Filho Thu, 20 Aug 2020 15:05:18 -0300 + packeth (1.6.5-2) unstable; urgency=low * Fix FTBFS because of wrong link order, thanks to Colin Watson diff -Nru packeth-1.6.5/debian/rules packeth-1.6.5/debian/rules --- packeth-1.6.5/debian/rules 2011-09-13 10:10:02.0 -0300 +++ packeth-1.6.5/debian/rules 2020-08-20 15:05:18.0 -0300 @@ -4,7 +4,7 @@ # Uncomment this to turn on verbose mode. #export DH_VERBOSE=1 -export CFLAGS = -Wall -g -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations +export CFLAGS = -Wall -g -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -fcommon export LDFLAGS = -Wl,-z,defs -Wl,--as-needed override_dh_auto_install:
Bug#968365: /usr/bin/freshclam: Ignores DatabaseCustomURL unless --update-db=custom is specified
On 2020-08-20 17:25:01 [+0200], Stephan Jänecke wrote: > Hi Sebastian, Hi Stephan, > In case there is nothing further to add, I would like to file an > upstream bug report. I'll document relevant changes here. Okay. It is https://bugzilla.clamav.net/. Sebastian
Bug#968739: igv will not run
Package: igv
Version: 2.4.17+dfsg-1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
The IGV package seems not to work. It throws a NoSuchMethodError exception
on startup with the following trace:
$ igv
log4j: reset attribute= "false".
log4j: Threshold ="null".
log4j: Retreiving an instance of org.apache.log4j.Logger.
log4j: Setting [org.broad.igv] additivity to [true].
log4j: Level value for org.broad.igv is [INFO].
log4j: org.broad.igv level set to INFO
log4j: Class name: [org.apache.log4j.ConsoleAppender]
log4j: Parsing layout of class: "org.apache.log4j.PatternLayout"
log4j: Setting property [conversionPattern] to [%d{-MM-dd HH:mm:ss} %-5p
%c{1}:%L - %m%n].
log4j: Adding appender named [console] to category [org.broad.igv].
2020-08-20 13:59:59 INFO DirectoryManager:179 - IGV Directory:
/home/bredelings/igv
2020-08-20 13:59:59 INFO Main:155 - Startup IGV Version user not_set
2020-08-20 13:59:59 INFO Main:156 - Java 11.0.8
2020-08-20 13:59:59 INFO DirectoryManager:84 - Fetching user directory...
2020-08-20 13:59:59 INFO Main:157 - Default User Directory: /home/bredelings
2020-08-20 13:59:59 INFO Main:158 - OS: Linux
2020-08-20 13:59:59 INFO Main:208 - Unknown version: user
2020-08-20 14:00:00 ERROR DefaultExceptionHandler:49 - Unhandled exception
java.lang.NoSuchMethodError: 'void
htsjdk.tribble.util.ParsingUtils.registerHelperClass(java.lang.Class)'
at org.broad.igv.util.HttpUtils.(HttpUtils.java:104)
at org.broad.igv.util.HttpUtils.getInstance(HttpUtils.java:97)
at org.broad.igv.ui.Main.open(Main.java:279)
at org.broad.igv.ui.Main$1.run(Main.java:110)
at
java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:313)
at
java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:770)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at
java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:740)
at
java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
at
java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
at
java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
at
java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
at
java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at
java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
2020-08-20 14:00:01 INFO ShutdownThread:46 - Shutting down
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (2000, 'unstable'), (1999, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.7.0-2-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages igv depends on:
ii default-jre 2:1.11-72
ii junit44.12-8
ii libbatik-java 1.12-1.1
ii libbcprov-java1.65-1
ii libcofoja-java1.3-4
ii libcommons-io-java2.6-2
ii libcommons-logging-java 1.2-2
ii libcommons-math-java 2.2-7
ii libcommons-net-java 3.6-1
ii libgoogle-gson-java 2.8.6-1
ii libguava-java 29.0-5
ii libhtsjdk-java2.22.0+dfsg-1
ii libhttpclient-java4.5.11-1
ii libhttpcore-java 4.4.13-1
ii libjama-java 1.0.3-1
ii libjargs-java 1.0.0-5
ii libjaxb-api-java 2.3.1-1
ii libjaxp1.3-java 1.3.05-5
ii libjcommon-java 1.0.23-1
ii libjfreechart-java1.0.19-2
ii libjgrapht0.8-java0.8.3-5
ii libjhdf5-java 2.11.0+dfsg-4
ii libjide-oss-java 3.7.6+dfsg-1
ii liblog4j1.2-java 1.2.17-9
ii liblog4j2-java2.11.2-1
ii libpicard-java2.22.8+dfsg-1
ii libswing-layout-java 1.0.4-4
ii libxml-commons-external-java 1.4.01-5
Versions of packages igv recommends:
ii libmariadb-java 2.5.3-1
igv suggests no packages.
-- no debconf information
Bug#968738: lwjgl: please update to version 3 for libgdx
Source: lwjgl Severity: normal Control: block 968471 -1 libgdx requires v3 which is a major version and complete rewrite https://github.com/LWJGL/lwjgl3 I checked v2 rdepends in buster and it's only recommended by a metapackage. dak rm also shows "No dependency problem found." It seems to have been included as a dependency of jMonkey Engine which itself never made it: https://bugs.debian.org/587947 -- System Information: Debian Release: 10.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-10-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled signature.asc Description: PGP signature
Bug#966923: meson: diff for NMU version 0.55.0-2.1
Control: tags 966923 + patch
Control: tags 966923 + pending
Control: tags 968704 + pending
Dear maintainer,
I'm sponsoring an NMU for meson (versioned as 0.55.0-2.1) and uploaded
it without delay, after Marco spoke to Martin. Hopefully this doesn't
cause you too much trouble - the skip bug is blocking our work on
updating GNOME to 3.38 so we need this fixed at least in unstable.
Regards,
--
Iain Lane [ i...@orangesquash.org.uk ]
Debian Developer [ la...@debian.org ]
Ubuntu Developer [ la...@ubuntu.com ]
diff -Nru meson-0.55.0/debian/changelog meson-0.55.0/debian/changelog
--- meson-0.55.0/debian/changelog 2020-07-16 17:19:52.0 +0100
+++ meson-0.55.0/debian/changelog 2020-08-20 18:10:34.0 +0100
@@ -1,3 +1,11 @@
+meson (0.55.0-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Don't consider skipped tests as failures. Closes: #966923
+ * Fix test with setuptools 49. Closes: #968704
+
+ -- Marco Trevisan (Treviño) Thu, 20 Aug 2020 18:10:34 +0100
+
meson (0.55.0-2) unstable; urgency=medium
* Fix crossbuild test from Gianfranco Costamagna. Closes: #963546
diff -Nru meson-0.55.0/debian/patches/3-mtest_TestResult_SKIP_is_not_a_failure.patch meson-0.55.0/debian/patches/3-mtest_TestResult_SKIP_is_not_a_failure.patch
--- meson-0.55.0/debian/patches/3-mtest_TestResult_SKIP_is_not_a_failure.patch 1970-01-01 01:00:00.0 +0100
+++ meson-0.55.0/debian/patches/3-mtest_TestResult_SKIP_is_not_a_failure.patch 2020-08-20 18:10:31.0 +0100
@@ -0,0 +1,125 @@
+From 998ee63e9596d8b3315ddce3d6f4612fec3588ef Mon Sep 17 00:00:00 2001
+From: Simon McVittie
+Date: Mon, 3 Aug 2020 13:31:42 +0100
+Subject: [PATCH] mtest: TestResult.SKIP is not a failure
+
+If some but not all tests in a run were skipped, then the overall result
+is given by whether there were any failures among the non-skipped tests.
+
+Resolves: https://github.com/mesonbuild/meson/issues/7515
+Signed-off-by: Simon McVittie
+
+Bug-Upstream: https://github.com/mesonbuild/meson/issues/7515
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966923
+Origin: https://github.com/mesonbuild/meson/pull/7525
+Applied-Upstream: 0.56.0
+---
+ mesonbuild/mtest.py | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/mesonbuild/mtest.py b/mesonbuild/mtest.py
+index 0d8169218f..817550e666 100644
+--- a/mesonbuild/mtest.py
b/mesonbuild/mtest.py
+@@ -489,7 +489,7 @@ def make_tap(cls, test: 'TestSerialisation', test_env: T.Dict[str, str],
+ failed = True
+ elif isinstance(i, TAPParser.Test):
+ results.append(i.result)
+-if i.result not in {TestResult.OK, TestResult.EXPECTEDFAIL}:
++if i.result not in {TestResult.OK, TestResult.EXPECTEDFAIL, TestResult.SKIP}:
+ failed = True
+ elif isinstance(i, TAPParser.Error):
+ results.append(TestResult.ERROR)
+
+diff --git a/test cases/common/213 tap tests/cat.c b/test cases/common/213 tap tests/cat.c
+new file mode 100644
+index 00..4b92010ade
+--- /dev/null
b/test cases/common/213 tap tests/cat.c
+@@ -0,0 +1,26 @@
++#include
++#include
++
++int main(int argc, char **argv) {
++char buf[1024];
++size_t len;
++FILE *fh;
++
++if (argc != 2) {
++fprintf(stderr, "Incorrect number of arguments, got %i\n", argc);
++return 1;
++}
++fh = fopen(argv[1], "r");
++if (fh == NULL) {
++fprintf(stderr, "Opening %s: errno=%i\n", argv[1], errno);
++return 1;
++}
++do {
++len = fread(buf, 1, sizeof(buf), fh);
++if (len > 0) {
++fwrite(buf, 1, len, stdout);
++}
++} while (len > 0);
++fclose(fh);
++return 0;
++}
+diff --git a/test cases/common/213 tap tests/issue7515.txt b/test cases/common/213 tap tests/issue7515.txt
+new file mode 100644
+index 00..ca8563778d
+--- /dev/null
b/test cases/common/213 tap tests/issue7515.txt
+@@ -0,0 +1,27 @@
++1..26
++ok 1 Gtk overrides UI template sets up internal and public template children
++ok 2 Gtk overrides UI template sets up public template children with the correct widgets
++ok 3 Gtk overrides UI template sets up internal template children with the correct widgets
++ok 4 Gtk overrides UI template connects template callbacks to the correct handler
++ok 5 Gtk overrides UI template binds template callbacks to the correct object
++ok 6 Gtk overrides UI template from resource sets up internal and public template children
++ok 7 Gtk overrides UI template from resource sets up public template children with the correct widgets
++ok 8 Gtk overrides UI template from resource sets up internal template children with the correct widgets
++ok 9 Gtk overrides UI template from resource connects template callbacks to the correct handler
++ok 10 Gtk overrides UI template from resource
Bug#968736: xinetd: Please switch to TI RPC implementation
Source: xinetd Version: 1:2.3.15.3-1 Severity: wishlist User: debian-gl...@lists.debian.org Usertags: rpc-remova Dear maintainer, The glibc SunRPC implementation has been marked obsolete for some time. It will get removed from glibc in version 2.32 that has been released a few weeks ago. The TI RPC implementation should be used instead, which also brings new features (IPv6, Kerberos support, ...). Fortunately xinetd already supports using the TI RPC implementation and will automatically use it if found. Therefore all that you have to do is to add a build-depend on libtirpc-dev. Thanks, Aurelien
Bug#968735: libdap: Please switch to TI RPC implementation
Source: libdap Version: 3.20.6-3 Severity: wishlist User: debian-gl...@lists.debian.org Usertags: rpc-remova Dear maintainer, The glibc SunRPC implementation has been marked obsolete for some time. It will get removed from glibc in version 2.32 that has been released a few weeks ago. The TI RPC implementation should be used instead, which also brings new features (IPv6, Kerberos support, ...). Fortunately libdap already supports using the TI RPC implementation and will automatically use it if found. Therefore all that you have to do is to add a build-depend on libtirpc-dev. Thanks, Aurelien
Bug#968737: gnudatalanguage: Please switch to TI RPC implementation
Source: gnudatalanguage Version: 0.9.9-12 Severity: wishlist User: debian-gl...@lists.debian.org Usertags: rpc-remova Dear maintainer, The glibc SunRPC implementation has been marked obsolete for some time. It will get removed from glibc in version 2.32 that has been released a few weeks ago. The TI RPC implementation should be used instead, which also brings new features (IPv6, Kerberos support, ...). Fortunately gnudatalanguage already supports using the TI RPC implementation and will automatically use it if found. Therefore all that you have to do is to add a build-depend on libtirpc-dev. Thanks, Aurelien
Bug#968682: mkdocs: dh_mkdocs skips jQuery
Hi Christian! On Wed, Aug 19, 2020 at 09:20:57PM +0200, Christian Kastner wrote: > When building src:tpot, I'm getting an embedded-javascript-library > warning for jquery-2.1.1.min.js, copied from mkdocs. > > W: python-tpot-doc: embedded-javascript-library > usr/share/doc/python3-tpot/docs/js/jquery-2.1.1.min.js please use libjs-jquery > > This is odd, because dh_mkdocs seems to process all other libraries > correctly. For example, modernizr-2.8.3.min.js gets turned into a > symlink, and the correct substvar gets added for the libjs-modernizr > dependency. Thanks for the report. Apparently it broke when jquery files were moved from libjs-jquery to node-jquery (see #940975). It is fixed in git now, and will be in the next upload. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#968734: chiark-tcl: FTBFS with optimization level -O3 and gcc-10 on s390x
Source: chiark-tcl
Version: 1.3.4
tags: patch
Hello, In Ubuntu the package FTBFS on s390x, because of -O3, and some non
initialized variables.
This makes no sense, because the variables are passed by reference to the
functions, but
gcc is probably not smart enough to detect it.
the following patch fixes the issue by initializing the variables.
locutus@Unimatrix05-Bionic:/tmp $ debdiff chiark-tcl_1.3.4.dsc
chiark-tcl_1.3.4ubuntu2.dsc
diff -Nru chiark-tcl-1.3.4/crypto/crypto.c
chiark-tcl-1.3.4ubuntu2/crypto/crypto.c
--- chiark-tcl-1.3.4/crypto/crypto.c2020-08-17 19:09:07.0 +0200
+++ chiark-tcl-1.3.4ubuntu2/crypto/crypto.c 2020-08-20 08:44:23.0
+0200
@@ -316,13 +316,13 @@
HBytes_Value iv, HBytes_Value *result) {
const BlockCipherOp *op= (const void*)cd;
int encrypt= op->encrypt;
- int rc, iv_lenbytes;
- const CiphKeyValue *key;
+ int rc, iv_lenbytes = 0;
+ const CiphKeyValue *key = NULL;
const char *failure;
- const Byte *ivbuf;
- Byte *buffers;
- const void *sched;
- int nblocks;
+ const Byte *ivbuf = 0;
+ Byte *buffers = NULL;
+ const void *sched = NULL;
+ int nblocks = 0;
if (!mode->encrypt)
return cht_staticerr(ip, "mode does not support encrypt/decrypt", 0);
@@ -352,10 +352,10 @@
HBytes_Value iv, HBytes_Value *result) {
const CiphKeyValue *key;
const char *failure;
- const Byte *ivbuf;
- Byte *buffers;
- const void *sched;
- int nblocks, iv_lenbytes;
+ const Byte *ivbuf = 0;
+ Byte *buffers = NULL;
+ const void *sched = NULL;
+ int nblocks = 0, iv_lenbytes = 0;
int rc;
if (!mode->mac)
diff -Nru chiark-tcl-1.3.4/debian/changelog
chiark-tcl-1.3.4ubuntu2/debian/changelog
--- chiark-tcl-1.3.4/debian/changelog 2020-08-17 19:09:07.0 +0200
+++ chiark-tcl-1.3.4ubuntu2/debian/changelog2020-08-20 08:44:23.0
+0200
@@ -1,3 +1,10 @@
+chiark-tcl (1.3.5) unstable; urgency=medium
+
+ * Initialize some variables on crypto.c to make -Werror=maybe-uninitialized
+stop erroring out on s390x with -O3 (Closes: #-1)
+
+ -- Gianfranco Costamagna Thu, 20 Aug 2020
08:44:23 +0200
+
chiark-tcl (1.3.4) unstable; urgency=medium
* debian/tests/control: Update to libnettle8. Fixes DEP-8 failure.
this is an example of failure log:
s390x-linux-gnu-gcc -g -Wall -Wmissing-prototypes -Wstrict-prototypes -Werror
-O2 -Wno-pointer-sign -fno-strict-aliasing -fPIC -I../hbytes/
-I/usr/include/tcl8.6 -I../base -DTCL_MEM_DEBUG -MMD -o algtables.o -c
algtables.c
s390x-linux-gnu-gcc -g -Wall -Wmissing-prototypes -Wstrict-prototypes -Werror
-O2 -Wno-pointer-sign -fno-strict-aliasing -fPIC -I../hbytes/
-I/usr/include/tcl8.6 -I../base -DTCL_MEM_DEBUG -MMD -o bcmode.o -c bcmode.c
s390x-linux-gnu-gcc -g -Wall -Wmissing-prototypes -Wstrict-prototypes -Werror
-O2 -Wno-pointer-sign -fno-strict-aliasing -fPIC -I../hbytes/
-I/usr/include/tcl8.6 -I../base -DTCL_MEM_DEBUG -MMD -o crypto.o -c crypto.c
crypto.c: In function ???cht_do_blockcipherop_e???:
crypto.c:344:3: error: ???iv_lenbytes??? may be used uninitialized in this
function [-Werror=maybe-uninitialized]
344 | cht_hb_array(result, ivbuf, iv_lenbytes);
| ^~~~
crypto.c:338:30: error: ???ivbuf??? may be used uninitialized in this function
[-Werror=maybe-uninitialized]
338 | (encrypt ? mode->encrypt : mode->decrypt)
| ~^~~~
339 | (cht_hb_data(v.hb), nblocks, ivbuf, buffers, alg, encrypt, sched);
| ~
crypto.c:338:30: error: ???buffers??? may be used uninitialized in this
function [-Werror=maybe-uninitialized]
crypto.c:338:30: error: ???sched??? may be used uninitialized in this function
[-Werror=maybe-uninitialized]
crypto.c:338:30: error: ???nblocks??? may be used uninitialized in this
function [-Werror=maybe-uninitialized]
crypto.c: In function ???cht_do_blockcipherop_mac???:
crypto.c:371:12: error: ???nblocks??? may be used uninitialized in this
function [-Werror=maybe-uninitialized]
371 | failure= mode->mac(cht_hb_data(), nblocks, ivbuf, buffers, alg,
sched);
|
^
crypto.c:371:12: error: ???sched??? may be used uninitialized in this function
[-Werror=maybe-uninitialized]
crypto.c:371:12: error: ???buffers??? may be used uninitialized in this
function [-Werror=maybe-uninitialized]
crypto.c:371:12: error: ???ivbuf??? may be used uninitialized in this function
[-Werror=maybe-uninitialized]
cc1: all warnings being treated as errors
make[2]: *** [../base/final.make:23: crypto.o] Error 1
make[2]: Leaving directory '/<>/crypto'
make[1]: *** [Makefile:15: all] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:50: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit
status 2
G.
Bug#968733: openbsd-inetd: 0.20160825-4
Package: openbsd-inetd Version: 0.20160825-4+b1 Severity: normal User: debian-gl...@lists.debian.org Usertags: rpc-removal Dear maintainer, The glibc SunRPC implementation has been marked obsolete for some time. It will get removed from glibc in version 2.32 that has been released a few weeks ago. The TI RPC implementation should be used instead, which also brings new features (IPv6, Kerberos support, ...). Fortunately it is relatively easy to add support for the TI RPC implementation in openbsd-inetd. Please find a patch below to do that. It can already be applied, even if the glibc SunRPC implementation is still present. Regards, Aurelien --- openbsd-inetd-0.20160825/debian/control +++ openbsd-inetd-0.20160825/debian/control @@ -3,7 +3,7 @@ Priority: optional Maintainer: Marco d'Itri Build-Depends: debhelper-compat (= 12), - pkg-config, libbsd-dev (>= 0.6.0), libwrap0-dev, libevent-dev, libsystemd-dev + pkg-config, libbsd-dev (>= 0.6.0), libwrap0-dev, libevent-dev, libsystemd-dev, libtirpc-dev Standards-Version: 4.3.0.2 Rules-Requires-Root: no Vcs-Git: https://salsa.debian.org/md/openbsd-inetd.git --- openbsd-inetd-0.20160825/debian/patches/series +++ openbsd-inetd-0.20160825/debian/patches/series @@ -15,3 +15,4 @@ monotonic_clock write_pidfile sd_daemon +tirpc --- openbsd-inetd-0.20160825/debian/patches/tirpc +++ openbsd-inetd-0.20160825/debian/patches/tirpc @@ -0,0 +1,15 @@ +Use the TI RPC implementation instead of the glibc SunRPC implementation +that has been removed in glibc version 2.32. + +--- a/Makefile.debian b/Makefile.debian +@@ -4,6 +4,9 @@ CFLAGS ?= -g -O2 + DEFS := -DLIBWRAP + LIBS := -lwrap + ++DEFS += $(shell $(PKG_CONFIG) --cflags libtirpc) ++LIBS += $(shell $(PKG_CONFIG) --libs libtirpc) ++ + DEFS += $(shell $(PKG_CONFIG) --cflags libbsd-overlay) + LIBS += $(shell $(PKG_CONFIG) --libs libbsd-overlay) +
Bug#968732: nfswatch still partially uses SunRPC implementation
Package: nfswatch Version: 4.99.11-7 Severity: normal Tags: patch User: debian-gl...@lists.debian.org Usertags: rpc-removal Dear maintainer, Thanks for switching nfswatch from the glibc SunRPC implementation to the TI RPC one. It appears however that it doesn't build with the SunRPC headers removed due to a small typo in the debian/rules file. The patch below fixes that. Regards, Aurelien --- nfswatch-4.99.11/debian/rules +++ nfswatch-4.99.11/debian/rules @@ -3,7 +3,7 @@ # Variable name for injection further CFLAGS into build # is not optimally chosen as it relates to rpm builds export RPM_OPT_FLAGS+=$(shell dpkg-buildflags --get CFLAGS) -export RPM_OPT_FLAGS+=$(pkg-config --cflags libtirpc) +export RPM_OPT_FLAGS+=$(shell pkg-config --cflags libtirpc) %: dh $@
Bug#968731: netgen: copyright and licensing issues
Source: netgen Version: 6.2.2006+dfsg-1 Severity: serious Justification: Policy 2.3, 4.5, 12.5 X-Debbugs-CC: ftpmas...@debian.org Hello, During review in NEW I discovered the following problems with this package's copyright file: cmake\cmake_modules\FindMETIS.cmake is BSD licensed. Also the autogen files do not have their licenses given in d/copyright. libsrc/core/concurrentqueue.h has a different license, not in d/copyright. Looks like general/mystring.*pp might have a different copyright holder. libsrc/general/gzstream.* and libsrc/occ have different copyright holders and maybe licenses; situation is unclear. mkinstalldirs missing copyright & license. ng/fonts.hpp -- is this really the source code for the font? ng/ngappinit.cpp says it's a modification from a different package; what is its copyright and license? -- Sean Whitton signature.asc Description: PGP signature
Bug#968729: haskell-gi-pango FTBFS parse error on input ‘HarfBuzz.FeatureT.feature_t’
Source: haskell-gi-pango
Version: 1.0.22-1
Severity: serious
Tags: ftbfs
The most recent binnmus of haskell-gi-pango in sid failed with
GI/Pango/Objects/Font.hs:670:9: error:
parse error on input ‘HarfBuzz.FeatureT.feature_t’
|
670 | Ptr HarfBuzz.FeatureT.feature_t -> -- features : TCArray False (-1) 2 (TInterface
(Name {namespace = "HarfBuzz", name = "feature_t"}))
| ^^^
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:147: build-ghc-stamp] Error 1
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit
status 2
I also saw the same error in raspbian bullseye-staging and on the reproducible
builds tests for bullseye.
Bug#968706: ITP: ayatana-indicator-sound -- Ayatana Indicator for managing system sound
Package: wnpp Severity: wishlist Owner: Mike Gabriel * Package name: ayatana-indicator-sound Version : 0.8.0 Upstream Author : Mike Gabriel * URL : https://github.com/ArcticaProject/ayatana-indicator-sound * License : GPL-3 Programming Lang: C / C++ / Vala Description : Ayatana Indicator for managing system sound This Ayatana Indicator is designed to be placed on the right side of a panel and give the user easy control over the system's sound settings. . Ayatana Indicator Sound provides easy control of the PulseAudio sound daemon, and integrates well with media players that support the Mpris protocol. . This package will be maintained under the umbrella of the Ayatana Packagers Team.
Bug#968728: RFS: w1retap/1.4.4-4 [RC] -- Data logger for 1-Wire weather sensors
Package: sponsorship-requests Severity: important Dear mentors, As my existing sponsor seems very busy I am looking for a new sponsor for my package "w1retap": * Package name: w1retap Version : 1.4.4-4 Upstream Author : Jonathan Hudson * URL : http://www.zen35309.zen.co.uk/wx/tech.html * License : Expat-Dallas-Semiconductor-Corporation and Expat-University-of-Newcastle-upon-Tyne and GPL-2+, GPL-2+, Expat-Dallas-Semiconductor-Corporation and GPL-2+, Expat * Vcs : https://salsa.debian.org/thomasdstewart-guest/w1retap Section : electronics It builds those binary packages: w1retap-sqlite - Data logger for 1-Wire weather sensors (SQLite plugin) w1retap-pgsql - Data logger for 1-Wire weather sensors (PostgreSQL plugin) w1retap-odbc - Data logger for 1-Wire weather sensors (ODBC plugin) w1retap-mongo - Data logger for 1-Wire weather sensors (MongoDB plugin) w1retap-mysql - Data logger for 1-Wire weather sensors (MySQL plugin) w1retap-doc - Data logger for 1-Wire weather sensors (docs) w1retap - Data logger for 1-Wire weather sensors To access further information about this package, please visit the following URL: https://mentors.debian.net/package/w1retap/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/w/w1retap/w1retap_1.4.4-4.dsc Changes since the last upload: w1retap (1.4.4-4) unstable; urgency=medium . * Refresh dquilt patches * Rename fix-w1pgsql-snprintf-timet.patch to fix-timet.patch * Add timet fixes for w1file, w1pgsql, w1util and w1xml * Update patch descriptions * Fix lintian autotools-pkg-config-macro-not-cross-compilation-safe * Add fix-autotools-libxml2.patch (Closes: #949511) * Fix gcc-10 build errors (Closes: #957921) * Fix owerr spelling * Replace build dependency asciidoc with asciidoc-base * Update standards from 3.9.8 to 4.5.0 * Fix lintian init.d-script-should-always-start-service * Upgrade debhelper compat from 10 to 13 * Add Vcs-Git and Vcs-Browser fields to control file * Fix lintian skip-systemd-native-flag-missing-pre-depends * Add Rules-Requires-Root to control * Added salsa-ci.yml * Fix man page spelling * Add Documentation key to service * Add systemd service hardening-features * Make copyright format URL https * Update lintian-overrides * Add some autopkgtest tests * Remove training whitespace from changelog * Fix lintian debian-rules-uses-as-needed-linker-flag * Fix lintian upstream-metadata-file-is-missing Kind Regards -- Tom
Bug#968727: squid-deb-proxy-client: Should detect being called from a chroot and return no proxy.
Package: squid-deb-proxy-client Version: 0.8.15 Severity: wishlist Hi! Currently if squid-deb-proxy-client is installed in a chroot al successive calls to apt install will try to use it and fail because avahi will not be working. It would be really cool if the script could detect this and simply return no proxy. If this feature seems sensible I might try to create a patch. Of course I'll be happy to consider other alternative solutions. Kind regards, Lisandro. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'buildd-unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64, armhf Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), LANGUAGE=es_AR:es Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages squid-deb-proxy-client depends on: ii apt 2.1.10 ii avahi-utils 0.8-3 ii python3 3.8.2-3 squid-deb-proxy-client recommends no packages. squid-deb-proxy-client suggests no packages. -- no debconf information
Bug#960855: libmousex-foreign-perl: uses deprecated Any::Moose
intrigeri (2020-05-19): > I'll file the RM bug at some point after 2020-07-19, unless > someone objects. Done: #968726
Bug#968673: libboost-all-dev: Can't use boost 1.71 with C++20 (gcc 10)
În ziua de miercuri, 19 august 2020, la 20:09:43 EEST, Giovanni Mascellani a
scris:
> Hi,
>
> Il 19/08/20 16:41, BogDan Vatra ha scritto:
> > I tried to use boost with C++ 20 (gcc 10), and I got the following errors.
> > I also tried boost 1.73 (from conan.io) and everything compiles.
>
> Thanks for the report. Could you please provide a test program that
> fails compilation and its compilation command line?
>
> Thanks, Giovanni.
Hi,
There you go:
$ cat main.cpp
#include
int main()
{
return 0;
}
$ g++ -std=c++2a main.cpp
Cheers,
BogDan.
Bug#968726: RM: libmousex-foreign-perl -- ROM; deprecated Any::Moose, inactive upstream
Package: ftp.debian.org Severity: normal Hi, with my Debian Perl group hat on, I'm trying to decrease the amount of packages that depend on Any::Moose, which is deprecated since 5 years. For more context, see https://bugs.debian.org/960909 The upstream maintainers never commented on the corresponding upstream bug report which was filed 6 years ago. Last upstream release commit was in 2014. This is a leaf package and popcon is tiny. Finally, the Mouse ecosystem is essentially on life-support as the community has been adopting alternate OO frameworks. Thanks!
Bug#846667: Requested removal
Hi, I've requested removal: #968725
Bug#968725: RM: libpoe-loop-event-perl -- ROM; RC-buggy, inactive upstream, low popcon
Package: ftp.debian.org Severity: normal Hi, this package causes trouble, due to occasional test failures, on all sorts of automated build/test infrastructures: https://bugs.debian.org/846667 Upstream seems to be inactive for many years, popcon is very low, it's a leaf package, and it seems nobody complained that we did not ship this package in Buster. Thanks in advance!
Bug#966922: libnitrokey: FTBFS: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below
Hey Scott, could you update the package? Since this is marked as RC bug, libnitrokey and all depending packages are kicked out of testing. Best, Jan On Mon, 03 Aug 2020 13:54:57 + Scott Kitterman wrote: > This is probably a result of a new GCC version. C++ symbols can be painful > to manage. This will be trivial to update the next time I update the package. > > Scott K > > On August 3, 2020 9:15:16 AM UTC, Szczepan Zalega | Nitrokey > wrote: > >On 8/3/20 10:41 AM, Lucas Nussbaum wrote: > >> (optional=templinst|arch=!amd64 !arm64 !x32) > >> (optional=templinst) > > > >Hi! > > > >As far as I see the problem comes from the listing format difference, > >not the actual symbol change. > > > >E.g.: > >``` > >- (optional=templinst|arch=!amd64 !arm64 > >!x32)_ZN8nitrokey5proto17ResponseDissectorILNS0_9CommandIDE65ERKNS0_14DeviceResponseILS2_65ENS0_12EmptyPayload24status_translate_commandB5cxx11Ei@Base > >3.5 > >+ > >(optional=templinst)_ZN8nitrokey5proto17ResponseDissectorILNS0_9CommandIDE65ERKNS0_14DeviceResponseILS2_65ENS0_12EmptyPayload24status_translate_commandB5cxx11Ei@Base > >3.5 > >``` > > signature.asc Description: OpenPGP digital signature
Bug#968724: ipe-tools FTBFS with poppler 0.85
Package: ipe-tools Severity: serious Version: 1:7.2.7.2-4 Tags: patch ipe-tools fails to build with poppler 0.85, there are multiple issues. I whipped up a patch and uploaded it to raspbian, A debdiff should appear soon at https://debdiffs.raspbian.org/main/i/ipe-tools I notice it looks like at least some of these issues may also have been fixed upstream. Sadly I only noticed this after I prepared my patch.
Bug#968723: buster-pu: package incron/0.5.12-1+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Hi,
I'd like to upload incron/0.5.12-1+deb10u1 to buster to fix #930526.
Incron creates a lot zombies processes and make the whole system
unstable.
The fix is pretty trivial (one line) and the patch has been taken from
upstream:
https://github.com/ar-/incron/pull/42/commits/196975d26fd04176a1c877fa3c404efd8103c9c2
Also see https://bugzilla.redhat.com/show_bug.cgi?id=1656939 and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930526 for further
information.
The debdiff is attached.
Thanks,
diff -Nru incron-0.5.12/debian/changelog incron-0.5.12/debian/changelog
--- incron-0.5.12/debian/changelog 2019-02-19 02:44:46.0 +
+++ incron-0.5.12/debian/changelog 2019-12-02 22:20:07.0 +
@@ -1,3 +1,9 @@
+incron (0.5.12-1+deb10u1) buster; urgency=medium
+
+ * Add a patch to fix cleanup of zombie processes (Closes: #930526)
+
+ -- Emmanuel Bouthenot Mon, 02 Dec 2019 22:20:07 +
+
incron (0.5.12-1) unstable; urgency=medium
* New upstream release (Closes: #860199)
diff -Nru incron-0.5.12/debian/patches/02_prevent_zombies.patch
incron-0.5.12/debian/patches/02_prevent_zombies.patch
--- incron-0.5.12/debian/patches/02_prevent_zombies.patch 1970-01-01
00:00:00.0 +
+++ incron-0.5.12/debian/patches/02_prevent_zombies.patch 2019-11-22
13:48:34.0 +
@@ -0,0 +1,28 @@
+Description: Prevent zombies
+Author: Mikhail Teterin (UnitedMarsupials on
github)
+Forwarded: no
+Last-Update: 2019-11-12
+Origin: https://github.com/ar-/incron/pull/42 ->
https://github.com/ar-/incron/pull/42/commits/196975d26fd04176a1c877fa3c404efd8103c9c2
+Bug-Debian: https://bugs.debian.org/930526
+
+From 196975d26fd04176a1c877fa3c404efd8103c9c2 Mon Sep 17 00:00:00 2001
+From: Mikhail T
+Date: Mon, 30 Oct 2017 14:15:03 -0400
+Subject: [PATCH 2/2] Rework the zombie prevention
+
+---
+ icd-main.cpp | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/icd-main.cpp b/icd-main.cpp
+index aef4d70..1e4d07f 100644
+--- a/icd-main.cpp
b/icd-main.cpp
+@@ -104,6 +104,7 @@ void on_signal(int signo)
+ g_fFinish = true;
+ break;
+ case SIGCHLD:
++ do {} while (waitpid((pid_t)-1, 0, WNOHANG) > 0); /* Prevent zombies */
+ // first empty pipe (to prevent internal buffer overflow)
+ do {} while (read(g_cldPipe[0], g_cldPipeBuf, CHILD_PIPE_BUF_LEN) > 0);
+
diff -Nru incron-0.5.12/debian/patches/series
incron-0.5.12/debian/patches/series
--- incron-0.5.12/debian/patches/series 2019-02-19 02:44:46.0 +
+++ incron-0.5.12/debian/patches/series 2019-11-22 13:48:34.0 +
@@ -1 +1,2 @@
01_manpages_typos
+02_prevent_zombies.patch
Bug#845812: libdata-amf-perl: uses deprecated Any::Moose
Hi, I've requested removal: #968722
Bug#957219: foremost: diff for NMU version 1.5.7-9.1
Glad to help! Em qui., 20 de ago. de 2020 às 12:24, Raúl Benencia escreveu: > > Hi Joao, > > This is perfect. Thanks for taking care of it. > > On Wed, Aug 19, 2020 at 03:52:30PM -0300, Joao Eriberto Mota Filho wrote: > > Control: tags 957219 + patch > > Control: tags 957219 + pending > > > > Dear maintainer, > > > > I've prepared an NMU for foremost (versioned as 1.5.7-9.1) and > > uploaded it to DELAYED/2. Please feel free to tell me if I > > should cancel or delay it longer. > > > > Regards. > > > > diff -Nru foremost-1.5.7/debian/changelog foremost-1.5.7/debian/changelog > > --- foremost-1.5.7/debian/changelog 2019-06-12 12:08:06.0 -0300 > > +++ foremost-1.5.7/debian/changelog 2020-08-19 15:38:47.0 -0300 > > @@ -1,3 +1,11 @@ > > +foremost (1.5.7-9.1) unstable; urgency=medium > > + > > + * Non-maintainer upload. > > + * debian/rules: added DEB_CFLAGS_MAINT_APPEND variable as a workaround > > to fix > > +a FTBFS with GCC-10. (Closes: #957219) > > + > > + -- Joao Eriberto Mota Filho Wed, 19 Aug 2020 > > 15:38:47 -0300 > > + > > foremost (1.5.7-9) unstable; urgency=medium > > > >* Fix extra byte at the tail of recovered zip files if -t all is > > diff -Nru foremost-1.5.7/debian/rules foremost-1.5.7/debian/rules > > --- foremost-1.5.7/debian/rules 2018-06-11 02:27:20.0 -0300 > > +++ foremost-1.5.7/debian/rules 2020-08-19 15:38:47.0 -0300 > > @@ -5,6 +5,9 @@ > > #export DH_VERBOSE=1 > > export DEB_BUILD_MAINT_OPTIONS=hardening=+all > > > > +# Workaround for #957219 > > +export DEB_CFLAGS_MAINT_APPEND = -fcommon > > + > > %: > > dh $@ > >
Bug#968722: RM: libdata-amf-perl -- ROM; uses deprecated Any::Moose
Package: ftp.debian.org Severity: normal Hi, with my Debian Perl group hat on, I'm trying to decrease the amount of packages that depend on Any::Moose, which is deprecated since 5 years. For more context, see https://bugs.debian.org/960909 The only reverse dependency in the archive is get-flash-videos, for which I've filed a RM bug already (#960838). No upstream release since 10 years and popcon is steadily decreasing. Thanks in advance, cheers!
Bug#845811: libwww-nicovideo-download-perl: uses deprecated Any::Moose
Hi, intrigeri (2020-05-17): > That's still the case. Add to this: no upstream release since 10 > years, very low popcon. > > I propose we remove this package if upstream does not answer within > 3 months. > > also, note that we have nicovideo-dl in the archive: updated last year > upstream, Python 3, 6 times more votes in popcon. > > This increases my confidence that removing > libwww-nicovideo-download-perl is OK. Upstream did not reply so I've requested removal: #968721
Bug#960838: get-flash-videos: Abandoned upstream, broken for many use cases ⇒ consider removing
Hi, intrig...@debian.org (2020-05-17): > I propose we remove both packages from the archive. I've requested removal of get-flash-videos: #968720
Bug#968721: RM: libwww-nicovideo-download-perl -- ROM; Uses deprecated Any::Moose, inactive upstream, better alternative in Debian
Package: ftp.debian.org Severity: normal Hi, with my Debian Perl group hat on, I'm trying to decrease the amount of packages that depend on Any::Moose, which is deprecated since 5 years. For more context, see https://bugs.debian.org/960909 There's been no upstream release of libwww-nicovideo-download-perl since 10 years. We also have nicovideo-dl in the archive, which seems to provide the same functionality as libwww-nicovideo-download-perl, but was updated upstream last year, is written in Python 3, and has 6 times more votes in popcon.
Bug#968720: RM: get-flash-videos -- ROM; Abandoned upstream, broken for many use cases
Package: ftp.debian.org Severity: normal Hi, as I wrote on https://bugs.debian.org/960838 3 months ago: Upstream has been inactive for 2 years. This kind of software needs constant updating to remain useful, as indicated by #750872 and the pile of non-handled upstream bug reports that report breakage on website X or Y. Given this, it's not surprise to me that popcon has been steadily decreasing since 2015. In contrast, youtube-dl is actively maintained and its popcon steadily increasing. Judging by the package descriptions, youtube-dl claims to support vastly more websites, including most of those that get-flash-videos itself claims to support. So at first glance, I don't think we're serving our users well by including get-flash-videos in the distribution. I'd rather see them not have to wonder and choose, and instead directly find the best maintained piece of software. On top of this,get-flash-videos is the only reverse-dependency of libdata-amf-perl, which causes trouble (#845812). Thanks in advance, cheers!
Bug#968703: python3 and python crashes if a specific .inputrc exists
Package: python3 Version: 3.8.2-3 Severity: important X-Debbugs-Cc: j.arunm...@protonmail.com Dear Maintainer, Content of .inputrc : ``` # Based on Brendan Miller's initial bash .inputrc # INSTALL # to install, rename this file to just ".inputrc" # place this file in your home dir. e.g. ~/.inputrc # restart your terminal. Then, bash's keybinding for editing # should be like ErgoEmacs. # If no key works, try replace all \e to \M-. That's means change Esc to Meta key. set editing-mode emacs "\M-j": backward-char "\M-l": forward-char "\M-u": backward-word "\C-M-b": backward-word "\M-o": forward-word "\C-M-f": forward-word "\M-g": kill-line "\": kill-line "\M-e": backward-kill-word "\M-r": kill-word "\M-f": delete-char "\C-z": undo "\": kill-region "\M-c": copy-region-as-kill "\": yank "\C-v": yank "\C-f": forward-search-history "\M-:": reverse-search-history ``` With .inputrc of above content in HOME, both python and python3 crash by segmentation fault on interactive session. The same happens if any python script takes input from user. This was thought to be an Ergoemacs issue and a bug report was filed in their repository. But the repository maintainers suggested reporting it to readline or / and python package maintainers. Clearing the contents of .inputrc or renaming the file to some trivial name, fixes the issue. Affected usage : 1. Interactive sessions of python and python3 2. Scripts that take input from user. (`python3 myScript.py`) 3. Scripts that process a file and drop to interactive shell. (`python3 -i myScript.py`) Example observation : ``` j_arun_mani@mysys:~$ python3 Python 3.8.5 (default, Aug 2 2020, 15:09:07) [GCC 10.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> Segmentation fault ``` Please inform me if any other additional details are required. Thanks ^_^ -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-2-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3 depends on: ii libpython3-stdlib 3.8.2-3 ii python3-minimal3.8.2-3 ii python3.8 3.8.5-2 python3 recommends no packages. Versions of packages python3 suggests: pn python3-doc pn python3-tk ii python3-venv 3.8.2-3 -- no debconf information
Bug#968387: apparmor: Broken printing and printer autodiscovery
Package: apparmor Version: 2.13.2-10 Followup-For: Bug #968387 With the printer found and printing not functional: # tail /var/log/cups/error_log E [20/Aug/2020:16:33:13 +0200] Unable to open listen socket for address [v1.::1]:631 - Permission denied. E [20/Aug/2020:16:33:13 +0200] Unable to open listen socket for address 127.0.0.1:631 - Permission denied. E [20/Aug/2020:16:35:26 +0200] [Job 34] Job stopped because the scheduler could not create the side-channel pipes. # journalctl -kaf --no-hostname | grep -w 'apparmor="DENIED"' ago 20 16:35:49 kernel: audit: type=1400 audit(1597934149.904:2054): apparmor="DENIED" operation="create" profile="/usr/sbin/cups-browsed" pid=825 comm="cups-browsed" family="unix" sock_type="stream" protocol=0 requested_mask="create" denied_mask="create" addr=none I cannot recreate the other case where the printer was not found at all. This is not related to lxc (this machine has no containers yet) except that it recommends apparmor.
Bug#968719: popplerkit.framework FTBFS with poppler 0.85
Package: popplerkit.framework Version: 0.0.20051227svn-8 Severity: serious Tags: bullseye sid patch popplerkit.framework FTBFS with poppler 0.85 because globalParams is now a std::unique_ptr https://github.com/freedesktop/poppler/commit/759d190581f8ff069ecee9155313a8e69a2ca9c6 I have whipped up a patch adjusting popplerkit.framework in the same way the code in poppler itself was adjusted. I have uploaded said patch to raspbian, a debdiff should appear soon at https://debdiffs.raspbian.org/main/p/popplerkit.framework
Bug#968365: /usr/bin/freshclam: Ignores DatabaseCustomURL unless --update-db=custom is specified
Hi Sebastian, Sebastian wrote: > It sounds like you want to use PrivateMirror. But then you don't have > same path so it probably won't work. I don't know. > > You have > DatabaseMirror = "update.dfn-cert.de" so I replaced DatabaseMirror by PrivateMirror which results in: ``` -> ^remote_cvdhead: file not found: http://update.dfn-cert.de/daily.cvd ``` When specifiying the update-db parameter the paths specified in DatabaseCustomURL are used. > If you could verify the part with PrivateMirror then I/you could open a > bug with upstream asking what the recommended way is to use a private > mirror with a different hierarchy. In case there is nothing further to add, I would like to file an upstream bug report. I'll document relevant changes here. > This is what you intend to do I guess. Indeed, I would like to place the databases somewhere other than document root. Cheers, Stephan -- Stephan Jänecke (PKI-Team + IT-Services) Mail: jaene...@dfn-cert.dePhone: +49 40 808077-709 DFN-CERT Services GmbH, https://www.dfn-cert.de/, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 Nagelsweg 41, 20097 Hamburg, Germany. CEO: Dr. Klaus-Peter Kossakowski smime.p7s Description: S/MIME cryptographic signature
Bug#968718: ITP: wims-lti -- gateway server that links LMSs to WIMS servers, using LTI
Package: wnpp Severity: wishlist Owner: Georges Khaznadar X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: wims-lti Version : 0.4.3 Upstream Author : Quentin Coumes * URL : https://github.com/PremierLangage/wims-lti * License : GPL-3+ Programming Lang: Python3 Description : gateway server that links LMSs to WIMS servers, using LTI WIMS-LTI is a gateway server that links LMSs to WIMS servers, using LTI. . A single instance of WIMS-LTI can handle a lot of LMS and WIMS servers. . WIMS-LTI allows : . - To create a WIMS class associated to a LMS' course. - To create students corresponding to that course in the WIMS class. - Students to connect to the WIMS server from a LMS. - Teachers to connect to the WIMS class as supervisor or as student from a LMS. - To send the grades of students back to the LMS (automatically and manually). . The documentation is available on readthedocs: https://wims-lti.readthedocs.io/. - This package is interesting for sysadmins which want to deploy easily wims and moodle learning management systems for their schools, and establish useful links between features of both systems. As a member of the association Wimsedu (www.wimsedu.info), I commit myself to maintain this package, as it is also useful for my effort of system administration, in the school where I am employed.
Bug#957219: foremost: diff for NMU version 1.5.7-9.1
Hi Joao, This is perfect. Thanks for taking care of it. On Wed, Aug 19, 2020 at 03:52:30PM -0300, Joao Eriberto Mota Filho wrote: > Control: tags 957219 + patch > Control: tags 957219 + pending > > Dear maintainer, > > I've prepared an NMU for foremost (versioned as 1.5.7-9.1) and > uploaded it to DELAYED/2. Please feel free to tell me if I > should cancel or delay it longer. > > Regards. > > diff -Nru foremost-1.5.7/debian/changelog foremost-1.5.7/debian/changelog > --- foremost-1.5.7/debian/changelog 2019-06-12 12:08:06.0 -0300 > +++ foremost-1.5.7/debian/changelog 2020-08-19 15:38:47.0 -0300 > @@ -1,3 +1,11 @@ > +foremost (1.5.7-9.1) unstable; urgency=medium > + > + * Non-maintainer upload. > + * debian/rules: added DEB_CFLAGS_MAINT_APPEND variable as a workaround to > fix > +a FTBFS with GCC-10. (Closes: #957219) > + > + -- Joao Eriberto Mota Filho Wed, 19 Aug 2020 > 15:38:47 -0300 > + > foremost (1.5.7-9) unstable; urgency=medium > >* Fix extra byte at the tail of recovered zip files if -t all is > diff -Nru foremost-1.5.7/debian/rules foremost-1.5.7/debian/rules > --- foremost-1.5.7/debian/rules 2018-06-11 02:27:20.0 -0300 > +++ foremost-1.5.7/debian/rules 2020-08-19 15:38:47.0 -0300 > @@ -5,6 +5,9 @@ > #export DH_VERBOSE=1 > export DEB_BUILD_MAINT_OPTIONS=hardening=+all > > +# Workaround for #957219 > +export DEB_CFLAGS_MAINT_APPEND = -fcommon > + > %: > dh $@ > signature.asc Description: PGP signature
Bug#968717: debug-me-server: does not email logs
Package: debug-me-server Version: 1.20181208-2 Severity: normal I know there's a newer version, but all my servers run stable. I don't know exactly how sendmail is being invoked, but it is failing Aug 20 11:02:25 fethera debug-me[11600]: sendmail: fatal: open /etc/postfix/main.cf: Permission denied Aug 20 11:02:25 fethera postfix/sendmail[11623]: fatal: open /etc/postfix/main.cf: Permission denied FWIW, I verified that the user _debug-me can read that file. -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-9-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debug-me-server depends on: ii adduser 3.118 ii debug-me1.20181208-2 ii lsb-base10.2019051400 ii postfix [mail-transport-agent] 3.4.10-0+deb10u1 debug-me-server recommends no packages. debug-me-server suggests no packages. -- Configuration Files: /etc/default/debug-me changed: DAEMON_PARAMS="--from-email da...@tethera.net --server /var/log/debug-me/ --delete-old-logs" -- no debconf information
Bug#968716: ITP: shasta -- nanopore whole genome assembly (binaries and scripts)
Package: wnpp Severity: wishlist Subject: ITP: shasta -- nanopore whole genome assembly (binaries and scripts) Package: wnpp Owner: Shayan Doust Severity: wishlist * Package name: shasta Version : 0.5.1 Upstream Author : Chan Zuckerberg Initiative * URL : https://github.com/chanzuckerberg/shasta * License : Expat Programming Lang: C++ Description : nanopore whole genome assembly (binaries and scripts) De novo assembly from Oxford Nanopore reads. The goal of the Shasta long read assembler is to rapidly produce accurate assembled sequence using as input DNA reads generated by Oxford Nanopore flow cells. . Computational methods used by the Shasta assembler include: . * Using a run-length representation of the read sequence. This makes the assembly process more resilient to errors in homopolymer repeat counts, which are the most common type of errors in Oxford Nanopore reads. . * Using in some phases of the computation a representation of the read sequence based on markers, a fixed subset of short k-mers (k ≈ 10). . Shasta assembly quality is comparable or better than assembly quality achieved by other long read assemblers. . This package contains the executable binaries (tools) and accommodating scripts. Remark: This package is maintained by Debian Med Packaging Team at https://salsa.debian.org/med-team/shasta
Bug#968438: Should this really be RC?
severity 968438 normal thanks The problem might also come from previous configuration, both a fellow co maintainer and I tried to create annotations and they worked. Yes, they are now presented as a toolbar, but they are there. And moreover the buttons do what they are intended to do. I would recommend backing up your current okular configuration and removing it, then opening okular again and trying. If that makes a change you might want to consider attaching your configuration to the upstream bug. All in all this is at most a normal bug which might be triggered by previous configs (I'm still speculating), but definitely a normal bug. Drew: please try the above, you might be able to solve the issue for other people too. Thanks!
Bug#968714: extractpdfmark FTBFS with poppler 0.85
Package: extractpdfmark Version: 1.1.0-1 Severity: serious Tags: patch extractpdfmark FTBFS with poppler 0.85 destname.cc:85:62: error: no matching function for call to ‘PDFDoc::findPage(int&, int&)’ 85 | pagenum = doc->findPage (page_ref.num, page_ref.gen); Doing a bit of poking around in poppler's git repository I deduced that the call should be changed to pagenum = doc->findPage(page_ref); I have whipped up a patch and uploaded it to raspbian, a debdiff should appear soon at https://debdiffs.raspbian.org/main/e/extractpdfmark I may or may not NMU this in Debian later.
Bug#907576: . push. dream --A Software Digital Radio Mondiale
Re: GMiller > OK I see here in gittutorial. Is GMIller a good name to push my branch > (instead of master)? Clone the repo to your account on salsa and push it there first. Christoph
Bug#968713: tiger complains about unknown nsfs filesystem
Package: tiger Version: 1:3.2.4~rc1-2 Severity: normal Dear Maintainer, tiger complains about finding an unknown filesystem: --CONFIG-- [con010c] Filesystem 'nsfs' used by 'nsfs' is not recognised as a valid filesystem nsfs is the "Name Space File System" used by the setns() system call. It is used by snap and docker among others. -- System Information: Debian Release: 10.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-0.bpo.2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tiger depends on: ii binutils 2.31.1-16 ii bsdmainutils 11.1.2+b1 ii debconf [debconf-2.0] 1.5.71 ii libc6 2.28-10 ii net-tools 1.60+git20180626.aebd88e-1 ii ucf3.0038+nmu1 Versions of packages tiger recommends: ii chkrootkit 0.52-3+b10 ii exim4-daemon-light [mail-transport-agent] 4.92-8+deb10u4 ii john 1.8.0-2+b1 pn tripwire | aide Versions of packages tiger suggests: ii lsof 4.91+dfsg-1 pn lynis -- debconf information excluded
Bug#966302: RFS: dukpy [ITP]
Hi, I'm looking for a sponsor for the package: * dukpy (#966302) The package is on: https://salsa.debian.org/med-team/dukpy The package is the last dependency of benten[1,2]. [1] https://github.com/rabix/benten [2] https://bugs.debian.org/963743 The package has 4 lintian-overrides, which is for ignoring the minified JavaScript source-is-missing.The package does have autopkgtest and passed well. Please consider to review and sponsor this. Any kind of suggestions are appreciated. Thank you! Sincerely, Sao I Kuan saoik...@gmail.com
Bug#962226: libdr-tarantool-perl build-depends on obsolete package
retitle 962226 RM: libdr-tarantool-perl -- ROM; obsolete reassign 962226 ftp.debian.org severity normal I'd like to request removal of libdr-tarantool-perl. This package was part of tarantool-lts and was uploaded for those who were moving to new tarantool in order for them to be able to use the package with the old one for a few years. It hasn't been being actual for already two or three years. Please delete it. 04.06.2020, 21:45, "peter green" : > Source: libdr-tarantool-perl > Version: 0.45-2 > Severity: serious > Tags: bullseye, sid > > libdr-tarantool-perl build-depends on > > tarantool-lts | tarantool (<< 1.6) > > tarantool-lts has been removed from Debian and tarantool is now at version > 1.9.1.26.g63eb81e3c-1.1
