Bug#881555: Epydoc will be removed
Hi Kenneth, if you provide a patch the package will be uploaded in less then 24 hours. I'm fine without the API doc. Thanks for your cooperation Andreas. On Wed, Jul 31, 2019 at 09:51:38PM -0500, Kenneth Pronovici wrote: > Hi, > > This is still one of 20+ packages in the archive that depend on > Epydoc. I have filed a bug with ftp.debian.org to have epydoc removed > from unstable, and that can't proceed while this package still uses > epydoc as a build dependency. As a result, I have increased the > severity of this bug to serious. > > As I find the time, I will be working through all of the remaining > reverse dependencies. When I get to this package, I will NMU a > version that removes the build dependency. I will accomplish this by > simply not building the API documentation. I will not provide any > other notice of my pending NMU. > > Thanks, > > KEN > > -- > Kenneth J. Pronovici > > ___ > Debian-med-packaging mailing list > debian-med-packag...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging -- http://fam-tille.de
Bug#933595: transition: pkg-js-tools
Paul Gevers: > Control: tags -1 moreinfo > > Hi Xavier, > > [...] > > Also, as this is a debhelper plugin, can't you couple this to a > debhelper compat level? I believe those were introduced to enable > introduction of backwards incompatible changes, but I have no idea if > that propagates to the helpers. > > [...] As the debhelper maintainer: (As I have _not_ looked at the concrete case, I am _not_ coming with a recommendation for or against using the compat system in this case.) Third-party plugins are welcome to piggy back in the debhelper compat system (several have done so to date) and I am happy to include a note about it in debhelper(7)[1]. Thanks, ~Niels [1] This happened in compat 12 with e.g. the following note: * The third-party dh_golang tool (from dh-golang package) now defaults on honoring DH_GOLANG_EXCLUDES variable for source installation in -dev packages and not only during the building process. Please set DH_GOLANG_EXCLUDES_ALL to false to revert to the previous behaviour. See Debian::Debhelper::Buildsystem::golang(3pm) for details and examples.
Bug#933626: node-trust-json-document: build fails with upcoming webpack 4
Package: node-trust-json-document
Version: 0.1.4~dfsg-4
Severity: important
When building with webpack 4 currently in experimental, build fails with this
error.
webpack -d --output-filename json-document.js Invalid configuration object.
Webpack has been initialised using a configuration object that does not match
the API schema. - configuration.module has an unknown
property 'loaders'. These properties are valid: object {
exprContextCritical?, exprContextRecursive?, exprContextRegExp?,
exprContextRequest?, noParse?, rules?, defaultRules?, unknownContextCritical?,
unknownContextRecursive?, unknownContextRegExp?, unknownContextRequest?,
unsafeCache?, wrappedContextCritical?, wrappedContextRecursive?,
wrappedContextRegExp?, strictExportPresence?, strictThisContextOnImports? }
-> Options affecting the normal modules (`NormalModuleFactory`).
Please fix this soon so we can upload webpack 4 to unstable.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#903211: Checking for removal of BD [was Re: release.debian.org: How to handle unbuildable packages in buster]
Hi all, On Thu, 09 Aug 2018 09:32:00 + Niels Thykier wrote: > 3) Build-Depends are not enforced on removal. That is packages > /can/ be removed while packages are build depending on them. > > Limitation 2+3 are slightly more involved and may take quite a while for > us to implement. Seems like this is really in need of attention. Currently people are working to get rid of Python 2 packages. We currently have multiple packages in testing not able to build due to recent migrations. See https://qa.debian.org/dose/debcheck/src_testing_main/ and the amd64 or each link at the top. texlive-generic-extra was another issue recently and still on that list, I filed bugs for those. The annoying thing of Build-Depends is that they stick around in unstable, exactly because of Build-Depends, hence the packages don't start to fail there. And also autopkgtests runs are happy because they can pull the package from unstable. I may be saying something stupid, but shouldn't the build-depends not *just* be added to the depends in the migration phase? Or is that still quite involved due to -arch/-indep? Paul signature.asc Description: OpenPGP digital signature
Bug#932781: Bug#932428, Bug#932767, Bug#932781: gnome-shell crashes involving monitor changes
Simon McVittie writes: > Control: reassign -1 libmutter-3-0 3.30.2-7 > Control: affects -1 gnome-shell > Control: tags -1 + moreinfo > Control: forwarded -1 https://gitlab.gnome.org/GNOME/mutter/merge_requests/538 > > On Mon, 22 Jul 2019 at 08:18:09 +0200, Jörn Heissler wrote: >> gnome-shell crashes when I suspend my laptop or when I connect an >> external monitor or disconnect it. > > On Tue, 23 Jul 2019 at 10:06:52 -0400, Felipe Sateler wrote: >> It appears the cause [of a crash] is unplugging my usb C hub, which in turn >> has the HDMI connector for the external monitor. > > On Tue, 23 Jul 2019 at 10:36:59 +0530, Vasudev Kamath wrote: >> Closing laptop lid normally puts laptop sleep and I get back my session on >> reopen. But after recent update >> I see that I get logged out and closer inspection revealed that gnome-shell >> is crashing > > I've found an upstream commit that might be the solution for all of these > crashes. Please try mutter 3.30.2-8 and gnome-shell 3.30.2-10 when they > become available in unstable. After upgrading you will need to log out > and back in (or reboot) for the new code to be used. > > The actual fix is in mutter, but the updated gnome-shell has a different > crash fix, and while you're restarting GNOME anyway we might as well get > wider testing for the updated gnome-shell too... Yes I can confirm that this fixes all the crash issue. Thanks Simon. > > (Lid-close/suspend seems to be treated as a monitor unplug internally, > which is why it can cause similar crashes.) Even the external monitor connection crash is resolved. Cheers,
Bug#933614: logilab-common: Epydoc will be removed
On Wed, Jul 31, 2019, 23:11 Sandro Tosi wrote: > Hello Kenneth, > > On Wed, Jul 31, 2019 at 10:36 PM Kenneth J. Pronovici > wrote: > > This is one of 20+ packages in the archive that still depend on Epydoc. > I > > have filed a bug with ftp.debian.org to have epydoc removed from > unstable. > > Besides its lack of support for Python 3, epydoc has been completely > > unsupported upstream for close to a decade. It really should have been > removed > > from the archive years ago. > > while i appreciate your effort here, i dont believe there's any > particular reason to jump the gun here. > Hey Sandro, One way or another I need to get Epydoc out of the archive. It's got to happen at some point, along with the python2 end-of-life transition that has already started. Epydoc can't be converted to python3; I've already tried, and it's too much work to be practical. So, it's better to just stop using it now and move on. You don't need to discard the API documentation from your package; you just can't generate it at Debian package build time using epydoc. For instance, upstream can include the pre-generated documentation in the distribution if they would like to continue using Epydoc on their own, installed from the upstream source. It just isn't viable to generate it in Debian any more. In any case, I'm sorry if I sound impatient, but trying to do the right thing here has cost me a lot of effort. This is one of the very few replies I've gotten in the last 18 months, even though I have tried to be proactive. I filed bugs, updated NEWS, etc. to basically no avail. For whatever reason, I didn't find your package in my initial search. At [1], I can offer you (or your upstream) a hack-ish script to convert common Epydoc markup to Google-style docstrings. It's not perfect, but it would get you much of the way toward working code. Another alternative is to switch to pydoctor, which is mostly compatible with epydoc markup. (I recently NMU'd that to remove the epydoc dependency.). But, pydoctor is also dependent on python2, so switching doesn't gain you much. Bottom line: if someone is actually committed to making the transition away from epydoc markup, I am happy to offer the time necessary to complete that effort. But I don't want to wait indefinitely. I want to get ahead of the python2 transition and get this package out of the archive relatively soon. Otherwise we're just delaying the inevitable. KEN [1] https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert > >
Bug#933595: transition: pkg-js-tools
Control: tags -1 moreinfo Hi Xavier, On 31-07-2019 22:25, Xavier Guimard wrote: > pkg-js-tools provides a debhelper plugin that handles "dh --with > nodejs". Until 0.7, it was used for dh_auto_test. Since version 0.8.6, it > provides a dh_auto_install hooks that permits to automatically install > node packages in the right place: /usr/share/nodejs or > /usr/lib//nodejs instead of old /usr/lib/nodejs. It also reads > package.json to select automatically files to install. More than 90% > node modules can be installed then without debian/install. > > A package that uses it for tests will probably have build failures and > risks to install libraries in old and new place. Around 100 packages are > affected, I prepared the update in salsa for those I have identified. Please elaborate what you believe the (potential) problem is, because I don't understand. Also, as this is a debhelper plugin, can't you couple this to a debhelper compat level? I believe those were introduced to enable introduction of backwards incompatible changes, but I have no idea if that propagates to the helpers. > I fill this request to prevent testing migration reject because of > autopkgtest regressions. This will not happen. You'll have to fix the autopktests where needed. > I'm not sure this is the good place or if a > transition issue is needed in this case. If not, please forgive me for > this inconvenience and close this issue. Not sure, because I don't understand yet. But it seems to me that because this is only a build helper, no transition is needed as this only impacts builds. However, if you suddenly make loads of packages RC buggy, than you may want to block your new version from migrating and fix all FTBFS packages in unstable before you allow it to migrate. I assume (based on your text above) that you have done a rebuild of all reverse dependent packages to figure out which packages will FTBFS. Are all those packages under your control or have bugs been filed to warn them? Again, I think you want to investigate the compat level thing. Paul signature.asc Description: OpenPGP digital signature
Bug#933625: [multimail] New release 0.52
Package: multimail Version: 0.50~20150922-1 Severity: normal New version 0.52 was realeased on: http://wmcbrine.com/mmail/ https://github.com/wmcbrine/MultiMail Please update it! -- Fernando Toledo Dock Sud BBS http://bbs.docksud.com.ar telnet://bbs.docksud.com.ar
Bug#933624: ndctl: no init script for ndctl-monitor
Package: ndctl Version: 65-1.0 Severity: normal Tags: patch Hi! I'm afraid that the event monitor doesn't get started on any rc system other than systemd. My stab at the init script attached; alas, as I'm in Brazil right now while all DIMMed machines I can access are in Poland, the script isn't adequately tested. The daemon exits if there are no real DIMMs; emulation is not enough to test its functionality. But, with init scripts being simpler than .service files, there's not much to get wrong. Meow! -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.5-00036-g8cfc5c871f99 (SMP w/64 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages ndctl depends on: ii libc6 2.28-10 ii libdaxctl165-1 ii libjson-c30.12.1+ds-2 ii libkeyutils1 1.6-6 ii libndctl6 65-1 ii libuuid1 2.34-0.1 ndctl recommends no packages. ndctl suggests no packages. -- Configuration Files: /etc/ndctl/monitor.conf changed [not included] -- no debconf information #!/usr/bin/env /lib/init/init-d-script ### BEGIN INIT INFO # Provides: ndctl-monitor # Required-Start: $syslog $time $remote_fs # Required-Stop:$syslog $time $remote_fs # Default-Start:2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Ndctl Monitor Daemon # Description: monitoring of smart events of nvdimm objects ### END INIT INFO DAEMON=/usr/bin/ndctl DAEMON_ARGS="monitor --daemon"
Bug#933614: logilab-common: Epydoc will be removed
Hello Kenneth, On Wed, Jul 31, 2019 at 10:36 PM Kenneth J. Pronovici wrote: > This is one of 20+ packages in the archive that still depend on Epydoc. I > have filed a bug with ftp.debian.org to have epydoc removed from unstable. > Besides its lack of support for Python 3, epydoc has been completely > unsupported upstream for close to a decade. It really should have been > removed > from the archive years ago. while i appreciate your effort here, i dont believe there's any particular reason to jump the gun here. > I apologize for the late notice on this. I filed bugs against all of the > dependencies I could find over 18 months ago, but the FTP Master list included > some additional packages. > > If I don't hear back from you, I will NMU a version of your package that > removes > the build dependency. I will accomplish this by simply not building the API > documentation. If you don't want me to do this, please reply and let me know > how you want me to proceed. I will contact upstream about this issue, please dont just drop valuable information to package users/developers just yet. Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi
Bug#933609: How hard it is to find the Date of a package
Hi! I don't think there's any bug here, TBH. And if there was this would be the wrong package to assign to. On Thu, 2019-08-01 at 09:22:29 +0800, 積丹尼 Dan Jacobson wrote: > Package: www.debian.org > Let's examine how extremely hard it is for a user to squeeze update date > of a package he is thinking of installing out of the Debian system. The date does not seem relevant at all for the case you list below. > Now we must turn to the web. Not really, but see below. > Case in point: > > "Should we install webext-ublock-origin, or get it from the Chrome web > store. I know, let's see which is newer!" #933608 > > https://chrome.google.com/webstore/detail/ublock-origin/cjpalhdlnbpafiamejdnhcphjbkeiagm > says says "Updated July 25, 2019" You should be looking at the versions, the date is not really an indicator of whether one is newer than the other, it just reflects when these versions got uploaded to these different repositories. If Debian uploaded an older version later than the version in the Chrome web store, you'd get the wrong result. Version on the Chrome web store: 1.21.6 > OK, let's turn to Debian. $ apt-cache show webext-ublock-origin/sid | grep Version: Version: 1.19.0+dfsg-2 That pretty unambiguously states that the version in Debian is older. But if today there was a new Debian revision (say 1.19.0+dfsg-3) you'd have reached the wrong conclusion that the version in Debian is newer. > So we must shorten the link: > > http://ftp.us.debian.org/debian/pool/main/u/ublock-origin/ > > Then click Last Modified (twice), then look for the file we want... This is all the wrong way around really. But, in case you want to see the date of the last change, which also has nothing to do with when this got uploaded, or built (which can all be different times), then a simple: $ apt changelog webext-ublock-origin/sid would do. Thanks, Guillem
Bug#926642: [dvipdfmx] dvipdfmx ignores "-m" option
Dear Hilmar, dvipdfmx in texlive-binaries_2018.20180907.48586 works well with "-m option". However, dvipdfmx in texlive-binaries_2018.20181104.49075 and later ignores "-m option". Thanks for the report. Confirmed. The author will fix it this weekend. Thanks, Akira
Bug#933571: RFS: mp3guessenc/0.27.4+dfsg ITP #868235
On Thu, Aug 1, 2019 at 12:39 AM Peter wrote: > (I had to remove the windows binary from the source package, hence +dfsg) If you haven't already, please ask upstream to remove the Windows binary from their VCS and source tarballs. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#933623: transition: petsc
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition The hypre 2.16.0 upgrade revealed an incompatibility between petsc 3.10 and hypre 2.16.0. PETSc upstream has dealt with the issue with a couple of recent patches. The best way to stabilise hypre and petsc is to proceed with the petsc 3.11 transition. The slepc 3.11 transition should be considered part of this transition. I'm also upgrading dolfin to 2019.1.0 (which is really a just a fenics upgrade rather than a library transition). A mumps 5.2.0 transition is waiting, but I'll wait for this one to clear before starting that. Ben file: title = "petsc"; is_affected = .depends ~ /\b(libpetsc\-complex3\.11|libpetsc\-complex3\.11\-dbg|libpetsc\-complex3\.11\-dev|libpetsc\-real3\.11|libpetsc\-real3\.11\-dbg|libpetsc\-real3\.11\-dev|libpetsc3\.11\-dev\-common|libpetsc3\.11\-dev\-examples|petsc3\.11\-doc|libpetsc\-complex3\.10|libpetsc\-complex3\.10\-dbg|libpetsc\-complex3\.10\-dev|libpetsc\-real3\.10|libpetsc\-real3\.10\-dbg|libpetsc\-real3\.10\-dev|libpetsc3\.10\-dev\-common|libpetsc3\.10\-dev\-examples|petsc3\.10\-doc)\b/; is_good = .depends ~ /\b(libpetsc\-complex3\.11|libpetsc\-complex3\.11\-dbg|libpetsc\-complex3\.11\-dev|libpetsc\-real3\.11|libpetsc\-real3\.11\-dbg|libpetsc\-real3\.11\-dev|libpetsc3\.11\-dev\-common|libpetsc3\.11\-dev\-examples|petsc3\.11\-doc)\b/; is_bad = .depends ~ /\b(libpetsc\-complex3\.10|libpetsc\-complex3\.10\-dbg|libpetsc\-complex3\.10\-dev|libpetsc\-real3\.10|libpetsc\-real3\.10\-dbg|libpetsc\-real3\.10\-dev|libpetsc3\.10\-dev\-common|libpetsc3\.10\-dev\-examples|petsc3\.10\-doc)\b/; -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#933440:
On Wed, Jul 31, 2019 at 12:25:26PM +0200, Filip Hroch wrote: > Currently, while building itself is clean, the compiled > xmunipack binary mysteriously crashes. It seems to work for me, though maybe it only crashes on some particular action I didn't try. Perhaps post a backtrace and maybe somebody can help? Cheers, Olly
Bug#933622: formiko: ampersand escaping issues: Error on line 1: Entity did not end with a semicolon
Package: formiko Version: 1.3.0-1 Severity: normal Usertags: warnings When I load a markdown document containing links that have the ampersand (&) character in them, I get messages like this on the terminal where I launched Formiko: (formiko:11739): Gtk-WARNING **: 10:44:45.901: Failed to set text ' link: https://wiki.debian.org/Teams/ReleaseTeam/ReleaseCheckList?action=diff=85=83 ' from markup due to error parsing markup: Error on line 1: Entity did not end with a semicolon; most likely you used an ampersand character without intending to start an entity — escape ampersand as It seems that Formiko doesn't properly escape the ampersands to HTML () when converting markdown to HTML. -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages formiko depends on: ii gir1.2-gtksource-3.0 3.24.9-2 ii gir1.2-gtkspell3-3.0 3.0.9-3 ii gir1.2-webkit2-4.02.24.3-1 ii python3 3.7.3-1 ii python3-docutils 0.14+dfsg-4 ii python3-gi3.30.4-1 ii python3-recommonmark 0.4.0+ds-5 formiko recommends no packages. Versions of packages formiko suggests: pn vim-gtk3 -- no debconf information -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#933621: BUG: invalid expression type concat on invalid input "iifname . oifname p . q"
Package: nftables
Version: 0.9.1-2
Severity: minor
I found a parser bug when experimenting with concatenations:
# nft 'flush ruleset; table a; chain a b; a b iifname . oifname p . q; list
ruleset'
BUG: invalid expression type concat
nft: evaluate.c:1726: expr_evaluate_relational: Assertion `0' failed.
Aborted (core dumped)
# nft 'flush ruleset; table a; chain a b; a b iifname . oifname != p . q;
list ruleset'
BUG: invalid expression type concat
nft: evaluate.c:1726: expr_evaluate_relational: Assertion `0' failed.
Aborted (core dumped)
nft should print an error message, not crash.
Here is an example of the behaviour I expect:
# nft 'flush ruleset; table a; chain a b; a b iifname . oifname = p . q;
list ruleset'
Error: syntax error, unexpected '='
flush ruleset; table a; chain a b; a b iifname . oifname = p . q; list
ruleset
FYI, the correct input is this:
# nft 'flush ruleset; table a; chain a b; a b iifname . oifname { p . q };
list ruleset'
table ip a {
chain b {
iifname . oifname { "a" . "b" }
}
}
Bug#933620: kmymoney: should depend on gnome-icon-theme
Package: kmymoney Version: 5.0.5-1 Severity: normal Dear Maintainer, With gnome desktop, and kmymoney installed from either buster or testing repositories graphical icons are missing from e.g. the left hand side bar. Manually installing gnome-icon-theme package fixes this problem. -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (900, 'stable'), (400, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kmymoney depends on: ii kio 5.54.1-1 ii kmymoney-common 5.0.5-1 ii libalkimia5-7 7.0.2-2 ii libaqbanking355.7.8-3 ii libaqbanking35-plugins5.7.8-3 ii libc6 2.28-10 ii libgcc1 1:8.3.0-6 ii libgmp10 2:6.1.2+dfsg-4 ii libgpgmepp6 1.12.0-6 ii libgwengui-cpp0 4.20.0-9 ii libgwengui-qt5-0 4.20.0-9 ii libgwenhywfar60 4.20.0-9 ii libical3 3.0.4-3 ii libkchart22.6.1-1 ii libkf5activities5 5.54.0-1 ii libkf5akonadicore5abi24:18.08.3-5 ii libkf5archive55.54.0-1 ii libkf5codecs5 5.54.0-1 ii libkf5completion5 5.54.0-1 ii libkf5configcore5 5.54.0-1 ii libkf5configgui5 5.54.0-1 ii libkf5configwidgets5 5.54.0-1 ii libkf5contacts5 4:18.08.3-1 ii libkf5coreaddons5 5.54.0-1 ii libkf5holidays5 1:5.54.0-1 ii libkf5i18n5 5.54.0-1 ii libkf5identitymanagement5 18.08.3-2 ii libkf5itemmodels5 5.54.0-1 ii libkf5itemviews5 5.54.0-1 ii libkf5jobwidgets5 5.54.0-1 ii libkf5kcmutils5 5.54.0-1 ii libkf5kiocore55.54.1-1 ii libkf5kiofilewidgets5 5.54.1-1 ii libkf5kiogui5 5.54.1-1 ii libkf5kiowidgets5 5.54.1-1 ii libkf5notifications5 5.54.0-1 ii libkf5service-bin 5.54.0-1 ii libkf5service55.54.0-1 ii libkf5sonnetui5 5.54.0-1 ii libkf5textwidgets55.54.0-1 ii libkf5wallet-bin 5.54.0-1 ii libkf5wallet5 5.54.0-1 ii libkf5webkit5 5.54.0-1 ii libkf5widgetsaddons5 5.54.0-1 ii libkf5xmlgui5 5.54.0-1 ii libofx7 1:0.9.14-1 ii libqt5core5a [qtbase-abi-5-11-3] 5.11.3+dfsg1-1 ii libqt5dbus5 5.11.3+dfsg1-1 ii libqt5gui55.11.3+dfsg1-1 ii libqt5network55.11.3+dfsg1-1 ii libqt5printsupport5 5.11.3+dfsg1-1 ii libqt5quickwidgets5 5.11.3-4 ii libqt5sql55.11.3+dfsg1-1 ii libqt5webkit5 5.212.0~alpha2-21 ii libqt5widgets55.11.3+dfsg1-1 ii libqt5xml55.11.3+dfsg1-1 ii libsqlcipher0 3.4.1-1+b12 ii libstdc++68.3.0-6 Versions of packages kmymoney recommends: ii gpg-agent [gnupg-agent] 2.2.12-1 ii pinentry-gnome3 [pinentry-x11] 1.1.0-2 Versions of packages kmymoney suggests: pn kcalc -- no debconf information
Bug#895874: (no subject)
Hi, I'm using a docker image "FROM debian:10", and to get git-send-email working properly, I had to install libmailtools-perl by hand. It would be great if it was added as a dependency for the package. Thanks
Bug#881544: Epydoc will be removed
Hi, This is still one of 20+ packages in the archive that depend on Epydoc. I have filed a bug with ftp.debian.org to have epydoc removed from unstable, and that can't proceed while this package still uses epydoc as a build dependency. As a result, I have increased the severity of this bug to serious. As I find the time, I will be working through all of the remaining reverse dependencies. When I get to this package, I will NMU a version that removes the build dependency. I will accomplish this by simply not building the API documentation. I will not provide any other notice of my pending NMU. Thanks, KEN -- Kenneth J. Pronovici
Bug#933248: RFS: assaultcube/1.2.0.2-1 [ITA] -- realistic first-person-shooter
Hi Tobias, > I've took a look and I have to say assultcube's license is a nightmere; > for me it is far from clear from me what they mean… However, I cannot > see a change on the licensing, so I guess the situation is unchanged > and that would hint that we are still talking about non-free, at least > for the data. I agree, there was no change in the license, so I left it as it was in the orphaned package. I just organized 'debian/copyright' by adding all licenses presented in the game directories. > For example, what is source in their definition? I can only assume that > they mean the"sources.tar.gz" [1] on the release tab of their github > repo. If that is true, there quite a lots of difference when compared > to (what I guess is supposed to be in their terms) the game package > labeled "AssaultCube for Linux" [2] The game is being mirrored in an 'experimental' branch [1], to be played on Windows and MacOSX with the updated SDL2 library. With that, I just removed the directory containing prebuilt Windows binary sources and some Makefile fixes to create the game binary. > [2] has many MiB more files than [1], so I guess [1] is not sufficient > to play, is it? No, this package is the complete game to play. ;) > If I'm correct, the problem is that [2] is "no modification allowed", > "non commerical" and they are clear that there are bits in it that may > only distributed "unmodified" (in their definition) [3]. So this still > looks non-free for me. > > [1] https://github.com/assaultcube/AC/archive/v1.2.0.2.tar.gz > [2] h > ttps://github.com/assaultcube/AC/releases/download/v1.2.0.2/AssaultCube_v1.2.0 > .2.tar.bz2 > > [3] https://assault.cubers.net/docs/license.html > together with the README.md on https://github.com/assaultcube/AC > > > PS: On [3] they mention ./packages/audio/misc/pickup_armour.ogg -- > as licensed under "Creative Commons Sampling Plus 1.0", which is > unfortunatly a non-free license [4]. This alone makes it non-free. > > [4] > https://wiki.debian.org/DFSGLicenses#Creative_Commons_Sampling_Plus_.28CC-sampling.2B-.29.2C_v1.0 Exactly, in this case would the game have to be 'non-free' rather than 'contrib'? [1] https://github.com/assaultcube/AC/tree/experimental Thanks! -- ⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao] ⣾⠁⢠⠒⠀⣿⡁ Debian Wiki: https://wiki.debian.org/coringao ⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780 ⠈⠳⣄⠀⠀⠀ 2157 630B D441 A775 BEFF D35F FA63 ADA6 B638 B780 signature.asc Description: This is a digitally signed message part
Bug#933544: hunspell-en-us: Regression: ~13k words less in Buster compared to Stretch
On Wed, 31 Jul 2019, Philipp Hahn wrote: > This results hunspell no longer accepting valid words like > amongst > cryptographic > dereferenced > scalability > scalable > > Checking scowl/final/ I find most of them in > english-words.?? > but not in > american-words.?? > > I'm not a native English speaker, but the words listed above are > common enough and should be included in the American dictionary. Or > did I miss something? To be fair, amongst isn't super common in American english; among is more common. But amongst should still be present in hunspell as it's not *that* uncommon. The rest of the words should really be there too. I confirm the underlying issue here; the variants don't seem to be being included in the hunspell dictionary and a few other dictionaries are not included. I believe this is likely an upstream issue in its source, but I'll try to dig into this some more when I get a chance. Thanks for the report! -- Don Armstrong https://www.donarmstrong.com All bad precedents began as justifiable measures. -- Gaius Julius Caesar in "The Conspiracy of Catiline" by Sallust
Bug#933617: pyinotify: Epydoc will be removed
Source: pyinotify Severity: serious Justification: Policy 5.9.2 Hi, This is one of 20+ packages in the archive that still depend on Epydoc. I have filed a bug with ftp.debian.org to have epydoc removed from unstable. Besides its lack of support for Python 3, epydoc has been completely unsupported upstream for close to a decade. It really should have been removed from the archive years ago. I apologize for the late notice on this. I filed bugs against all of the dependencies I could find over 18 months ago, but the FTP Master list included some additional packages. If I don't hear back from you, I will NMU a version of your package that removes the build dependency. I will accomplish this by simply not building the API documentation. If you don't want me to do this, please reply and let me know how you want me to proceed. Thanks, KEN
Bug#933618: python-crypto: Epydoc will be removed
Package: python-crypto Version: 2.6.1-7 Severity: serious Justification: Policy 5.9.2 Hi, This is one of 20+ packages in the archive that still depend on Epydoc. I have filed a bug with ftp.debian.org to have epydoc removed from unstable. Besides its lack of support for Python 3, epydoc has been completely unsupported upstream for close to a decade. It really should have been removed from the archive years ago. I apologize for the late notice on this. I filed bugs against all of the dependencies I could find over 18 months ago, but the FTP Master list included some additional packages. If I don't hear back from you, I will NMU a version of your package that removes the build dependency. I will accomplish this by simply not building the API documentation. If you don't want me to do this, please reply and let me know how you want me to proceed. Thanks, KEN
Bug#933619: python-txosc: Epydoc will be removed
Package: python-txosc Severity: serious Justification: Policy 5.9.2 Hi, This is one of 20+ packages in the archive that still depend on Epydoc. I have filed a bug with ftp.debian.org to have epydoc removed from unstable. Besides its lack of support for Python 3, epydoc has been completely unsupported upstream for close to a decade. It really should have been removed from the archive years ago. I apologize for the late notice on this. I filed bugs against all of the dependencies I could find over 18 months ago, but the FTP Master list included some additional packages. If I don't hear back from you, I will NMU a version of your package that removes the build dependency. I will accomplish this by simply not building the API documentation. If you don't want me to do this, please reply and let me know how you want me to proceed. Thanks, KEN
Bug#933616: openvdb: Epydoc will be removed
Source: openvdb Severity: serious Justification: Policy 5.9.2 Hi, This is one of 20+ packages in the archive that still depend on Epydoc. I have filed a bug with ftp.debian.org to have epydoc removed from unstable. Besides its lack of support for Python 3, epydoc has been completely unsupported upstream for close to a decade. It really should have been removed from the archive years ago. I apologize for the late notice on this. I filed bugs against all of the dependencies I could find over 18 months ago, but the FTP Master list included some additional packages. If I don't hear back from you, I will NMU a version of your package that removes the build dependency. I will accomplish this by simply not building the API documentation. If you don't want me to do this, please reply and let me know how you want me to proceed. Thanks, KEN
Bug#933615: kiwi: Epydoc will be removed
Source: kiwi Severity: serious Justification: Policy 5.9.2 Hi, This is one of 20+ packages in the archive that still depend on Epydoc. I have filed a bug with ftp.debian.org to have epydoc removed from unstable. Besides its lack of support for Python 3, epydoc has been completely unsupported upstream for close to a decade. It really should have been removed from the archive years ago. I apologize for the late notice on this. I filed bugs against all of the dependencies I could find over 18 months ago, but the FTP Master list included some additional packages. If I don't hear back from you, I will NMU a version of your package that removes the build dependency. I will accomplish this by simply not building the API documentation. If you don't want me to do this, please reply and let me know how you want me to proceed. Thanks, KEN
Bug#933614: logilab-common: Epydoc will be removed
Source: logilab-common Severity: serious Justification: Policy 5.9.2 Hi, This is one of 20+ packages in the archive that still depend on Epydoc. I have filed a bug with ftp.debian.org to have epydoc removed from unstable. Besides its lack of support for Python 3, epydoc has been completely unsupported upstream for close to a decade. It really should have been removed from the archive years ago. I apologize for the late notice on this. I filed bugs against all of the dependencies I could find over 18 months ago, but the FTP Master list included some additional packages. If I don't hear back from you, I will NMU a version of your package that removes the build dependency. I will accomplish this by simply not building the API documentation. If you don't want me to do this, please reply and let me know how you want me to proceed. Thanks, KEN
Bug#933613: ldaptor: Epydoc will be removed
Source: ldaptor Severity: serious Justification: Policy 5.9.2 Hi, This is one of 20+ packages in the archive that still depend on Epydoc. I have filed a bug with ftp.debian.org to have epydoc removed from unstable. Besides its lack of support for Python 3, epydoc has been completely unsupported upstream for close to a decade. It really should have been removed from the archive years ago. I apologize for the late notice on this. I filed bugs against all of the dependencies I could find over 18 months ago, but the FTP Master list included some additional packages. If I don't hear back from you, I will NMU a version of your package that removes the build dependency. I will accomplish this by simply not building the API documentation. If you don't want me to do this, please reply and let me know how you want me to proceed. Thanks, KEN
Bug#933612: xfce4: Xfce fails to launch any application ("exo-helper-1: not found")
Package: xfce4 Version: 4.12.5 Severity: important Hello, since a recent update Xfce is unable to open any items clicked on in the desktop or through the panel launchers (anything that checks tfor "preferred application", I imagine). Launching the apps directly through the "Start Menu" works normally, as usual. The actual error message is something similar to this, as seen on #892010: /usr/bin/exo-preferred-applications: 11: exec: /usr/lib/x86_64-linux-gnu/xfce4/exo-1/exo-helper-1: not found I have managed to work around this issue by making a link between: /lib/x86_64-linux-gnu/xfce4/exo-2/exo-helper-2 Which exists in my system and: /lib/x86_64-linux-gnu/xfce4/exo-1/exo-helper-1 However this is clearly not ideal unless both commands are fully equivalent. I have marked this bug as important since being able to launch applications is indeed a big deal and more casual users may be incapacitated from using their systems in the offchance this would ever go to a stable release. This Ask Ubuntu post reports the same issue for Ubuntu 19.04: https://askubuntu.com/questions/1136194/xfce-can-not-start-preferred-applications-under-ubuntu-19-04/ The following relevant packages are installed and up-to-date in my system: exo-utils/testing,now 0.12.6-1 amd64 [installed,automatic] libexo-1-0/testing,now 0.12.6-1 amd64 [installed,automatic] libexo-2-0/testing,now 0.12.6-1 amd64 [installed,automatic] libexo-common/testing,testing,now 0.12.6-1 all [installed,automatic] libexo-helpers/testing,testing,now 0.12.6-1 all [installed,automatic] Thanks a lot to everyone working to make Xfce on Debian an excellent desktop environment! -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xfce4 depends on: ii gtk2-engines-xfce3.2.0-4 ii libxfce4ui-utils 4.12.1-3 ii thunar 1.8.7-1 ii xfce4-appfinder 4.12.0-2+b1 ii xfce4-panel 4.12.2-1 ii xfce4-pulseaudio-plugin 0.4.1-1 ii xfce4-session4.12.1-6 ii xfce4-settings 4.12.4-1 ii xfconf 4.12.1-1+b1 ii xfdesktop4 4.12.4-2 ii xfwm44.12.5-1 Versions of packages xfce4 recommends: ii desktop-base 10.0.3 ii tango-icon-theme 0.8.90-7 ii thunar-volman 0.9.1-1 ii xfce4-notifyd 0.4.4-1 ii xorg 1:7.7+19 Versions of packages xfce4 suggests: pn gtk3-engines-xfce pn xfce4-goodies pn xfce4-power-manager -- no debconf information
Bug#881554: Pending upload for python-configshell-fb?
Hi, I just wanted to follow up on python-configshell-fb. Back in June, you marked a pending upload to remove the epydoc dependency, but the bug is still open. I've filed the package removal request for epydoc, and I'm working through all of the reverse dependencies to adjust them, so the package removal can proceed. Could you please upload your new package sometime soon? It would help simplify things for me. Thanks, KEN -- Kenneth J. Pronovici
Bug#932574: RM: epydoc -- ROM; Obsolete (Python 2) and Unmaintained
> Checking reverse dependencies... > # Broken Depends: > pydoctor: python-pydoctor > pywbem: python-pywbem I have now taken care of these via NMU. It turns out that neither package strictly depends on epydoc. The python-pywbem package declared a dependency and a build dependency, but did not seem to reference epydoc anywhere (not in imports or commands or anything). The module imports fine in a chroot without python-epydoc installed. The python-pydoctor package already contains code to make usage of epydoc optional. If it's not installed, the HTML renderer falls back on a plain text representation. I removed the dependency there, and it works fine. I'll be looking next at the packages that declare a build dependency on epydoc. My intent there will be to remove the build dependency and simply not generate the API documentation as part of the package build process. Since basically no one has bothered to respond to these bugs,, I have to assume that it will be better to have the packages still in Debian (but without API documentation) than removed completely. I will NMU these packages one at a time as I adjust them. I won't be giving any notice about my NMUs, since I already followed up in mid-June to announce my intent to remove epydoc. KEN -- Kenneth J. Pronovici
Bug#932584: Epydoc and Pydoctor
On Wed, Jul 31, 2019 at 10:46 AM Ian Jackson wrote: > > Otherwise, I will see if I can determine how well the package works > > without epydoc installed. If it works (i.e. doesn't blow up) and I > > don't hear back with other instructions, I will eventually NMU my > > changes to remove the epydoc dependency. Given that I haven't gotten > > any replies for more than 18 months now, I won't wait that long before > > doing this NMU. > > That sounds really good to me for now. I think you can do this NMU > whenever you like. I tested pydoctor against my own cedar-backup2 code, which I never converted away from Epydoc since it's Python 2-only. It seems to work fine: mars:~/projects/dev/software/cedar-backup2> pydoctor CedarBackup2/ adding directory /home/pronovic/projects/dev/software/cedar-backup2/CedarBackup2 41/41 modules processed 0 warnings WARNING: guessing CedarBackup2 for project name writing html to apidocs using pydoctor.templatewriter.writer.TemplateWriter starting ModuleIndexPage ... Error trying to import 'epytext' parser: ImportError: No module named epydoc.markup.epytext Using plain text formatting only. took 0.006452s starting ClassIndexPage ... took 0.011512s starting IndexPage ... took 0.002281s starting NameIndexPage ... took 0.079562s starting UndocumentedSummaryPage ... took 0.004314s 125/125 pages written Generating objects inventory at apidocs/objects.inv The generated HTML documentation is legible, if not as pretty as it would have been before. Given that it works, I am going to NMU the version of the package that doesn't depend on epydoc. I'll also create a PR on salsa. On salsa, master has diverged from the released package, but I am *not* going to integrate those changes, because I don't want to take responsibility for them. KEN -- Kenneth J. Pronovici
Bug#933609: How hard it is to find the Date of a package
> "YW(" == Yao Wei (魏銘廷) writes:
YW(> A probably known easier way is to see the standardized changelog of the
package. There should be a date in each version.
OK, so smart users know that the Date is hiding in the
$ w3m -dump https://packages.debian.org/sid/web/webext-ublock-origin | grep
Change
• Debian Changelog
link.
Bug#933608: Acknowledgement (Say in Description if one should use this package or the Chrome Web Store version)
Also the Chrome Web Store version will always be newer than this package (see also #933609). So mention that in the Description too.
Bug#933609: How hard it is to find the Date of a package
A probably known easier way is to see the standardized changelog of the package. There should be a date in each version. Yao Wei (This email is sent from a phone; sorry for HTML email if it happens.) > On Aug 1, 2019, at 09:27, 積丹尼 Dan Jacobson wrote: > > Package: www.debian.org > > Let's examine how extremely hard it is for a user to squeeze update date > of a package he is thinking of installing out of the Debian system. > > First of all update dates are not part of any Package* file. So forget > apt, etc. > > Now we must turn to the web. > > Case in point: > > "Should we install webext-ublock-origin, or get it from the Chrome web > store. I know, let's see which is newer!" #933608 > > https://chrome.google.com/webstore/detail/ublock-origin/cjpalhdlnbpafiamejdnhcphjbkeiagm > says says "Updated July 25, 2019" > > That was simple. > > OK, let's turn to Debian. > > https://www.google.com/search?q=webext-ublock-origin leads to > https://packages.debian.org/sid/web/webext-ublock-origin > from where we must know to click on "all", > https://packages.debian.org/sid/all/webext-ublock-origin/download > > There we see > More information on webext-ublock-origin_1.19.0+dfsg-2_all.deb: > Exact Size1617728 Byte (1.5 MByte) > MD5 checksum190c7c66089925f72489624d700c34a0 > SHA1 checksumNot Available > SHA256 checksum > bf50b4180ba0daddd720b5ce1702a315ed7743cc749ebb3cc131fe60dcc648c9 > > but Date is still not included. > > So we must copy a link, and run HEAD on it, > > $ HEAD > http://ftp.us.debian.org/debian/pool/main/u/ublock-origin/webext-ublock-origin_1.19.0+dfsg-2_all.deb > 200 OK > Connection: close > Date: Thu, 01 Aug 2019 01:17:03 GMT > Accept-Ranges: bytes > ETag: "5d22808b-18af40" > Server: nginx/1.13.6 > Content-Length: 1617728 > Content-Type: application/octet-stream > Last-Modified: Sun, 07 Jul 2019 23:30:19 GMT > > > Ah, finally! > > But let's say we are not as smart. > > So we must shorten the link: > > http://ftp.us.debian.org/debian/pool/main/u/ublock-origin/ > > Then click Last Modified (twice), then look for the file we want... >
Bug#933611: Any attempt to use a prompt in xmonad brings it down with a `Segmentation fault (core dumped)'.
Package: libghc-xmonad-contrib-dev Version: 0.14-2+b1, amd64 Severity: important Any attempt to use a prompt in xmonad brings it down with a `Segmentation fault (core dumped)'. ... a prompt: http://hackage.haskell.org/package/xmonad-contrib-0.15/docs/XMonad-Prompt.html i write my own desktop on top of xmonad, it works quite perfectly in stretch :), but still cannot upgrade to buster because of this... :( ... all code on my part has been upgraded off deprecated and compiles clean with no warnings or errors. ( and linux mint inherits the same problem )
Bug#933610: signify-openbsd-keys: Please upload 2018.5
Package: signify-openbsd-keys Version: 2018.4 Severity: wishlist Dear Maintainer, I noticed you prepared a release with the keys for OpenBSD 66 https://salsa.debian.org/debian/signify-openbsd-keys/commit/14edcb216bf56cbeec6cf872042350488a75b1ab but didn't follow with an upload to sid. Could you please upload now that Buster is released? :-) (I'm relying on these keys to repack new netcat-openbsd releases.) Thanks! Cheers, -- Guilhem. signature.asc Description: PGP signature
Bug#933609: How hard it is to find the Date of a package
Package: www.debian.org Let's examine how extremely hard it is for a user to squeeze update date of a package he is thinking of installing out of the Debian system. First of all update dates are not part of any Package* file. So forget apt, etc. Now we must turn to the web. Case in point: "Should we install webext-ublock-origin, or get it from the Chrome web store. I know, let's see which is newer!" #933608 https://chrome.google.com/webstore/detail/ublock-origin/cjpalhdlnbpafiamejdnhcphjbkeiagm says says "Updated July 25, 2019" That was simple. OK, let's turn to Debian. https://www.google.com/search?q=webext-ublock-origin leads to https://packages.debian.org/sid/web/webext-ublock-origin from where we must know to click on "all", https://packages.debian.org/sid/all/webext-ublock-origin/download There we see More information on webext-ublock-origin_1.19.0+dfsg-2_all.deb: Exact Size1617728 Byte (1.5 MByte) MD5 checksum 190c7c66089925f72489624d700c34a0 SHA1 checksum Not Available SHA256 checksum bf50b4180ba0daddd720b5ce1702a315ed7743cc749ebb3cc131fe60dcc648c9 but Date is still not included. So we must copy a link, and run HEAD on it, $ HEAD http://ftp.us.debian.org/debian/pool/main/u/ublock-origin/webext-ublock-origin_1.19.0+dfsg-2_all.deb 200 OK Connection: close Date: Thu, 01 Aug 2019 01:17:03 GMT Accept-Ranges: bytes ETag: "5d22808b-18af40" Server: nginx/1.13.6 Content-Length: 1617728 Content-Type: application/octet-stream Last-Modified: Sun, 07 Jul 2019 23:30:19 GMT Ah, finally! But let's say we are not as smart. So we must shorten the link: http://ftp.us.debian.org/debian/pool/main/u/ublock-origin/ Then click Last Modified (twice), then look for the file we want...
Bug#914348: ... and the actual patch
>From 451b97ee5fa82942d16352e6cbb80064baf93f1a Mon Sep 17 00:00:00 2001 From: Adam Borowski Date: Thu, 1 Aug 2019 02:08:56 +0200 Subject: [PATCH] daxctl: link against libndctl, in case its use doesn't get pruned util/json.c uses libndctl symbols, and is included by daxctl. These functions should then get pruned as unused, but on some platforms the toolchain fails to do so. These platforms are ia64, hppa and 32-bit powerpc. It's generally a waste of our time to build ndctl there, but as the lack of a build-dependency requires annoying workarounds higher in the stack, this has been requested in https://bugs.debian.org/914348 -- and is trivially fixable on the ndctl side. Thanks to -Wl,--as-needed there's no harm to architectures where the pruning works, thus let's not bother with detection. As daxctl and libdaxctl are separate, there's no circular dependency. Signed-off-by: Adam Borowski --- daxctl/Makefile.am | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/daxctl/Makefile.am b/daxctl/Makefile.am index 94f73f9..a5487d6 100644 --- a/daxctl/Makefile.am +++ b/daxctl/Makefile.am @@ -21,4 +21,5 @@ daxctl_LDADD =\ lib/libdaxctl.la \ ../libutil.a \ $(UUID_LIBS) \ - $(JSON_LIBS) + $(JSON_LIBS) \ + ../ndctl/lib/libndctl.la -- 2.23.0.rc0
Bug#933471: ctsim: Please rebuild against wxWidgets GTK 3 package
Control: tags 933471 + patch
Andreas Tille writes:
> Would you be able to propose a patch?
Attached.
I checked this builds and that the resultant binary package debdiff
against the version in unstable looks sensible, but I haven't attempted
to test running the result as I don't know anything about computed
tomography.
I suspect the configure probes could be simplified further by unifying
the handling for wxWin too so wx-config is used for that too (then the
wx_gtk and wx_mac variables could probably go away) but I resisting
touching that.
Cheers,
Olly
diff -Nru ctsim-6.0.2/debian/changelog ctsim-6.0.2/debian/changelog
--- ctsim-6.0.2/debian/changelog 2018-04-26 02:44:10.0 +1200
+++ ctsim-6.0.2/debian/changelog 2019-08-01 12:44:48.0 +1200
@@ -1,3 +1,11 @@
+ctsim (6.0.2-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Build against GTK+3 flavour of wxWidgets (Closes: #933471)
++ New patch: improve-configure-wx-probes.patch
+
+ -- Olly Betts Thu, 01 Aug 2019 12:44:48 +1200
+
ctsim (6.0.2-2) unstable; urgency=medium
* cme fix dpkg-control
diff -Nru ctsim-6.0.2/debian/control ctsim-6.0.2/debian/control
--- ctsim-6.0.2/debian/control 2018-04-26 02:44:10.0 +1200
+++ ctsim-6.0.2/debian/control 2019-08-01 11:34:29.0 +1200
@@ -9,7 +9,7 @@
libreadline-dev,
libgl1-mesa-dev,
libglu1-mesa-dev,
- libwxgtk3.0-dev,
+ libwxgtk3.0-gtk3-dev,
ctn-dev,
libpng-dev
Standards-Version: 4.1.4
diff -Nru ctsim-6.0.2/debian/patches/improve-configure-wx-probes.patch ctsim-6.0.2/debian/patches/improve-configure-wx-probes.patch
--- ctsim-6.0.2/debian/patches/improve-configure-wx-probes.patch 1970-01-01 12:00:00.0 +1200
+++ ctsim-6.0.2/debian/patches/improve-configure-wx-probes.patch 2019-08-01 12:44:48.0 +1200
@@ -0,0 +1,74 @@
+Description: Improve configure probes related to wxWidgets
+ Determine wxGTK vs wxMac by looking at output of wx-config --cppflags
+ rather than probing for particular libraries, the names of which can
+ vary (for example, depending on the GTK+ major version in use).
+ .
+ Don't hard code --version=3.0 in wx-config arguments. That way the
+ user can specify a different version via alternatives or explicitly on the
+ configure command line, e.g.:
+ .
+ ./configure wxconfig='/usr/bin/wx-config --version=3.1'
+ .
+ Remove probes for GTK and glib, which don't seem to be needed.
+Author: Olly Betts
+Bug-Debian: https://bugs.debian.org/933471
+Forwarded: no
+Last-Update: 2019-08-01
+
+--- a/configure.ac
b/configure.ac
+@@ -71,21 +71,15 @@
+ AC_CHECK_LIB(readline, main, [readline=true;
+ AC_DEFINE([HAVE_READLINE],1,[Readline library])],
+ [readline=false], [-lcurses])
+-wxwin=false
+-AC_CHECK_LIB(gtk-x11-2.0, main, [hasx11gtk2=true], [])
+-if test "x$hasx11gtk2" = "x" ; then
+- AC_MSG_NOTICE([Does not have X11 GTK2])
+- AC_DEFUN([AM_PATH_GLIB_2_0], [])
+- AC_DEFUN([AM_PATH_GTK_2_0], [])
+-fi
+-if test "$hasx11gtk2" = "true" ; then
+- AM_PATH_GLIB_2_0(2.0.0,,AC_MSG_ERROR(You should get glib 2.0.0 or better.))
+- AM_PATH_GTK_2_0(2.0.0,havegtk_am=yes,havegtk_am=no)
+- CFLAGS="${CFLAGS} ${g76GTK_CFLAGS} ${GLIB_CFLAGS}"
++wxwin=true
++case `$wxconfig --cppflags 2> /dev/null` in
++ *-D__WXGTK__*) wx_gtk=true ;;
++ *-D__WXMAC__*) wx_mac=true ;;
++ "") wxwin=false ;;
++esac
++if test "$wxwin" = true ; then
++ AC_DEFINE(HAVE_WXWINDOWS,1,[wxwindows library])
+ fi
+-
+-AC_CHECK_LIB(wx_gtk2u_core-3.0, main, [wxwin=true; wx_gtk=true; AC_DEFINE(HAVE_WXWINDOWS,1,[wxwindows library])], [], [-L/usr/lib64 -L/usr/lib ${GTK_LIBS} ${GLIB_LIBS} ])
+-AC_CHECK_LIB(wx_mac_core-3.0, main, [wxwin=true; wx_mac=true; AC_DEFINE(HAVE_WXWINDOWS,1,[wxwindows library])])
+ AC_CHECK_LIB(fftw3, fftw_malloc, [fftw=true; AC_DEFINE(HAVE_FFTW,1,[FFTW library])], [fftw=false], [-L/usr/lib64 -L/usr/lib])
+ AC_CHECK_LIB(GL, main, [libgl=true], [libgl=false], [-L/usr/X11R6/lib -L/usr/X11R6/lib64])
+ AC_CHECK_LIB(pthread, main, [pthread=true], [pthread=false])
+@@ -384,12 +378,7 @@
+if test "$debug" = "true"; then
+ wxdebug="--debug"
+fi
+- if test "x$wx_gtk" != "x" ; then
+- ctlib_graphics="$ctlib_graphics `$wxconfig $wxdebug --version=3.0 --libs std,gl` ${GTK_LIBS} ${GLIB_LIBS}"
+-
+- elif test "x$wx_mac" != "x" ; then
+-ctlib_graphics="$ctlib_graphics `$wxconfig $wxdebug --version=3.0 --libs std,gl`"
+- fi
++ ctlib_graphics="$ctlib_graphics `$wxconfig $wxdebug --libs std,gl`"
+ fi
+ fi
+ if test "$wxwin" = "true" ; then
+@@ -462,8 +451,8 @@
+
+ if test "$wxwin" = "true" ; then
+ if test "$wx_gtk" = "true" -o "$wx_mac" = "true" ; then
+-wxcflags=`$wxconfig $wxdebug --cxxflags --version=3.0`
+-#wxlibs=`$wxconfig --libs`
++wxcflags=`$wxconfig $wxdebug --cxxflags`
++wxlibs=`$wxconfig --libs`
+ else
+ wxcflags="-D__WXMSW__ -D__WIN32__
Bug#933608: Say in Description if one should use this package or the Chrome Web Store version
Package: webext-ublock-origin User notices there is a package "webext-ublock-origin". User also notices there is https://chrome.google.com/webstore/detail/ublock-origin/cjpalhdlnbpafiamejdnhcphjbkeiagm Bug: the webext-ublock-origin package Description should say "If you can install https://chrome... then DON'T install this package." or "Install this package. DON'T install https://chrome; Don't just mention it in README etc. Thanks.
Bug#933533: FTBFS on x32 (due to optimize-gmp=False): Variable not in scope: unsafeShiftL :: t -> Integer -> t
On Wed, Jul 31, 2019 at 10:29:56AM +0100, Laurence Parry wrote: > The issue appears to have been reported upstream as > "cborg fails to compile when optimize-gmp is disabled" > https://github.com/well-typed/cborg/issues/193 Patch applied, but I'm curious as to why optimize-gmp is False.
Bug#914348: here's a fix
Control: tags -1 +patch Here's a fix; submitted upstream here: https://lists.01.org/pipermail/linux-nvdimm/2019-July/022846.html Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can. ⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener. ⠈⠳⣄ A master species delegates.
Bug#932712: command-not-found: crashes due to missing database, update-command-not-found does not help
In the update-command-not-found implementation here:
/usr/sbin/update-command-not-found
the following lines seem important:
command_files = glob.glob("/var/lib/apt/lists/*Contents*")
if len(command_files) > 0:
col = DbCreator(command_files)
col.create(db)
If I understand this correctly, it is looking for certain files in the
/var/lib/apt/lists directory, specifically files named like *Contents*.
However, on my system there are no *Contents* files in that directory
(the directory exists but the files there have different names, nothing
with "Contents") so command_files becomes empty and consequently no
database is created, and no error message is given, since the
len(command_files) > 0 condition is not satisfied.
So, it seems like the update-command-not-found implementation assumes
that certain files in /var/lib/apt/lists/ are named in a certain way,
but in my case the files there are named differently and then no
database is created.
/ Elias
När du har kontakt med oss på Uppsala universitet med e-post så innebär det att
vi behandlar dina personuppgifter. För att läsa mer om hur vi gör det kan du
läsa här: http://www.uu.se/om-uu/dataskydd-personuppgifter/
E-mailing Uppsala University means that we will process your personal data. For
more information on how this is performed, please read here:
http://www.uu.se/en/about-uu/data-protection-policy
Bug#933514: tmux: Screen garbling in ncurses apps
Oh Sven, that does look related, and I didn't even notice that ncurses-base got updated too or I'd have investigated it. Looks like this is a ncurses problem. Did you find changing TERM fixed it? Joseph On Wed, Jul 31, 2019 at 5:31 PM T. Joseph Carter < tjcar...@spiritsubstance.com> wrote: > It's hard to know what exactly causes it under aptitude. I did try it > using 3.0~rc3-1 from experimental and it does have a similar bug, I'm not > sure if it's quite the same though (it's glitching in aptitude in > inconsistent ways that I can't seem to exactly reproduce from one minute to > the next.) > > A very easy way to see it with weechat is to have a window with more than > one screenful in it (buffer 1 works) and use pgup/pgdn. You'll see the top > several lines redraw, but only those. > > Have a look at the attached screenshots. Notice that when I pgup, only the > top ~13 lines get redrawn and whitespace doesn't clear correctly. Below > that doesn't get redrawn at all. > > Version of gnome-terminal is 3.30.2-2 with libvte-2.91-0 version 0.54.2-2. > Hope that helps some. > > Joseph > > > On Wed, Jul 31, 2019 at 11:05 AM Sven Joachim wrote: > >> On 2019-07-31 09:18 +0200, Romain Francoise wrote: >> >> > On Wed, Jul 31, 2019 at 5:42 AM T. Joseph Carter >> > wrote: >> >> The latest version of tmux has issues with screen updates under GNOME >> >> Terminal with ncurses apps. This causes eg weechat's scrollback (pgup, >> >> pgdn) to not draw correctly, causes specific issues with aptitude as >> >> well. >> > >> > Thanks for the report. I don't use GNOME Terminal and I haven't >> > experienced any similar issues myself, but I will investigate. >> > >> > Can you provide more details about how to reproduce using aptitude? >> > >> >> I think this may be the result of the cherry-pick of 38b8a198bac6 from >> >> upstream, you may need an additional patch as well. >> > >> > Why? This is a fix for a crash which doesn't look related. >> > >> > Do you experience the issue only when multiple panes are used in a >> window? >> > >> >> I suspect the version of tmux found in experimental will not have this >> >> problem, but I haven't tested it yet. I expect you're holding it due to >> >> the freeze, but I do not believe 2.9a-2 makes a good release candidate. >> > >> > No, the freeze is over but the 3.0 release was pushed back to October, >> > so 3.0-rc will remain in experimental for the immediate future. >> >> Maybe the problems with screen updates have been triggered by >> ncurses-base 6.1+20190713-1, see #933572? I could reproduce that one >> with tmux 2.8-3, 2.9a-2 and 3.0~rc3-1. >> >> Cheers, >>Sven >> >>
Bug#933606: ndctl: missing Vcs-Git field
Source: ndctl Version: 65-1 Severity: minor Hi! The package uses a Git repository, but declares only human-readable Vcs-Browser but no machine-readable Vcs-Git. This frustrates some QA tools and tools like debcheckout. I see that the repository is badly outdated, too -- did you forget to push? Or is it stored somewhere else? Please either add Vcs-Git -- or, if you don't use a git-based workflow anymore, please drop Vcs-Browser. Meow! -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.5-00036-g8cfc5c871f99 (SMP w/64 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) -- no debconf information
Bug#726953: dgit and submodules
On Wed, Jul 31, 2019 at 04:22:35PM +0100, Ian Jackson wrote: > Submodules are intensely frustrating[1]. One way they are frustrating is > that it is not clear even what it means for a .dsc to be identical to > a git tree which has submodule references. Are the submodules > supposed to be populated ? My inclination is to say the answer is > "yes", but your own practice here seems to be "no" ? Well, from the perspective of the upstream author (in this case dwarves-dfsg), I think what's going on is they want to reuse code, but young'un's these days don't understand how to maintain API stability (never mind the ABI compatibility required for shared libraries). So what they do is to say, "ok, I'm going to use *this* version of lib/bpf" for vN of libdwarves, and at some point, for vN+x of libwarves, "I'll do a "git pull" of lib/bpf, discover that functions have changed arguments for various functions, so I'll have to fix up my source code to deal with this new version of lib/bpf." Because API stability is too hard(tm), they can't depend on having a particular version of libbpf.a installed in a distribution library. So instead, particular versions of lib/bpf are associated with particular version of dwarves, and a "git pull" of the top-level dwarves-dfsg git repository will also update the lib/bpf version of the submodule to the version tied to that version of the top-level git repo. >From the perspective of the source tarball, they distribute the source files for lib/bpf in dwarves-dfsg's source tar.xz file. And they static link lib/bpf in the binaries in the distro package, so the fact that modern open source programs have no idea how to achieve API or ABI stability, it all works. Mostly. So yeah, it's frustrating, and it means that we're shipping 576k of lib/bpf with dwarves-dfsg, and if there is some other source package that also uses lib/bpf, they will also ship their own version. It also means that if there is a security bug fix needed for lib/bpf, each user will have to update to the fixed version of lib/bpf, fix any API breakage, and then do a new source and binary release. The problem is, if we want to build upstream kernels with compressed type information for BPF, we need to use dwarves-dfsg. And the fact that it has the bad taste to use a completely unstable lib/bpf is what it is. But if dgit is supposed to be able to support *all* packages, even packages like lib/bpf and their users, such as dwarves-dfsg, then it's going to have to figure out how to deal with this. And git created submodules to be able to support this workflow; so if dgit is going to be a universal system, it needs to deal with packages that have decided to use this particular mechanism of code reuse. :-/ > [1] I think they are nearly always the wrong answer. Usually they are > the worst answer. Even (especially) to the situation they were > specifically intended to address. They are simply too broken. Of > course this is of no help to you as a downstream if your upstream has > drunk the poison kool-aid. Exactly. Compare and constrast this with e2fsprogs, where I've maintained ABI compatibility for over a decade Discipline! The young'uns don't understand Discpline! And they should also get off my d*mned lawn. :-) - Ted
Bug#933605: nmu: pmdk-convert_1.5.1-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi! Because of the new "binary upload needed for NEW but banned for migration", the package is stuck in unstable. Please rebuild. I uploaded with arm64 as a sacrificial arch with no build log for the same reason as the new rule is for, but since the rule is mandatory, please: nmu pmdk-convert_1.5.1-1 . arm64 . unstable . -m "Rebuild on a buildd." Meow! -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 4.4.167-1213-rockchip-ayufan-g34ae07687fce (SMP w/6 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#932712: command-not-found: crashes due to missing database, update-command-not-found does not help
On 2019-07-30 13:07, Andreas Beckmann wrote: This can be 'fixed' (created) by running apt-file update manually. It will be 'fixed' automatically the next time apt-get update (or any equivalent way to update the apt package lists) is run. For me, that does not help. I tried both "apt-file update" and "apt-get update" but the command-not-found problem remains the same afterwards. / Elias När du har kontakt med oss på Uppsala universitet med e-post så innebär det att vi behandlar dina personuppgifter. För att läsa mer om hur vi gör det kan du läsa här: http://www.uu.se/om-uu/dataskydd-personuppgifter/ E-mailing Uppsala University means that we will process your personal data. For more information on how this is performed, please read here: http://www.uu.se/en/about-uu/data-protection-policy
Bug#933603: linux 5.2.1-1~exp1: riscv64 updates, including a FTBFS fix
Source: linux Severity: important Tags: patch Hello, current git master for src:linux FTBFS on riscv64. Recently CONFIG_LOAD_UEFI_KEYS has been enabled in the top-level kernel config fragment (debian/config/config), but this option depends on EFI support which is not yet available on riscv64. Therefore CONFIG_LOAD_UEFI_KEYS must be disabled in the architecture-specific config, otherwise the package fails to build on riscv64 due to undefined symbols. I have created a merge request on salsa that addresses this issue and also provides some other riscv64-related updates: [riscv64] Backport kernel image header support from kernel 5.3 [riscv64] Enable clock drivers for the SiFive FU540 [riscv64] Enable SiFive UART and UART console support [riscv64] Disable CONFIG_LOAD_UEFI_KEYS for riscv64 (fixes FTBFS) https://salsa.debian.org/kernel-team/linux/merge_requests/161/commits Regards, Karsten -- Ich widerspreche hiermit ausdrücklich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung.
Bug#933599: musescore: create an upgrade path from 2 to 3
# wontfix works-as-intended close 933599 thanks Hello Gabriele, >It took me some time to notice the package renaming from "musescore" to >"musescore3" and to find the right piece of changelog documenting it: I’m sorry this took you some time; if you have any idea of how to do that better, other than an entry in the bullseye release notes which will be published in two years, please share. >them know where to look to solve this. Could something be done, at least >to better document the change and suggest a solution? I can’t think of any (otherwise I’d have implemented it). That the existing musescore binary package continues to provide a working MuseScore 2.x is deliberate, and I was even considering keeping it around for bullseye as well but then I’d have to support it within Debian until 2023 or longer, which at that time I felt not ready to without help from upstream (who have told me they can only sup‐ port the latest release, so no). I’m providing private musescore2 builds for those who need it and will update them should that be necessary due to Qt changes, that is, if the buster binaries no longer work. I feel it is still im‐ portant that users can have both versions available (though the 3.2.3 release feels stable enough again, a first for the 3.x se‐ ries). >Hopefully, at least, people will happen to read this bug and thus find >their way out :-) I’d rather they read the release notes… well, in two years. An “apt-cache search musescore” will easily show the binary package name to install though, and the installation instructions for Debian on the upstream website in the Handbook are also up-to-date. As I said, if you have concrete suggestions of what else could be done, do share them, otherwise… *shrug*. Sorry about that, //mirabilos -- [16:04:33] bkix: "veni vidi violini" [16:04:45] bkix: "ich kam, sah und vergeigte"...
Bug#933602: linphone não salva dados da conta sip
Package: linphone Version: 3.12.0-3 Severity: important -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores) Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), LANGUAGE=pt_BR:pt:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linphone depends on: ii libatk1.0-0 2.30.0-2 ii libbctoolbox10.6.0-2+b2 ii libbelcard1 1.0.2-1 ii libbellesip0 1.6.3-5 ii libbzrtp01.0.6-3 ii libc62.28-10 ii libcairo21.16.0-4 ii libgcc1 1:8.3.0-6 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-0 2.58.3-2 ii libgtk2.0-0 2.24.32-3 ii libmediastreamer-base10 1:2.16.1-4+b1 ii libmediastreamer-voip10 1:2.16.1-4+b1 ii libnotify4 0.7.7-4 ii libortp131:1.0.2-1 ii libpango-1.0-0 1.42.4-6 ii libpangocairo-1.0-0 1.42.4-6 ii libpangoft2-1.0-01.42.4-6 ii libpangoxft-1.0-01.42.4-6 ii libsqlite3-0 3.27.2-3 ii libstdc++6 8.3.0-6 ii libudev1 241-5 ii libxml2 2.9.4+dfsg1-7+b3 ii linphone-nogtk 3.12.0-3 ii zlib1g 1:1.2.11.dfsg-1 linphone recommends no packages. Versions of packages linphone suggests: pn yelp -- no debconf information
Bug#929503: blhc: Arch improperly detected on newer dpkg-buildpackage
Hi Mathieu, Thanks a lot for your patch. I will apply it today. Cheers, Eriberto Em qua, 31 de jul de 2019 às 19:27, Mathieu Parent escreveu: > > I found the cause of #929503.
Bug#929521: Conflicts in upgrade to 418.74-1 with optimus setup
On Wed, 31 Jul 2019 at 21:32, Andreas Beckmann wrote: > > On 11/06/2019 12.21, Luca Boccassi wrote: > > On Tue, 2019-06-11 at 00:21 +0200, Andreas Beckmann wrote: > >> On 07/06/2019 18.12, Luca Boccassi wrote: > >>> Hi, this should be the list: > >>> > >>> bbswitch bumblebee bumblebee-nvidia primus primus-libs primus-libs- > >>> ia32 > >>> nvidia-driver-libs-nonglvnd nvidia-driver-libs-nonglvnd-i386 > >> > >> Is this documented somewhere? > >> > >> This can be minimized to > >> apt-get install --install-recommends \ > >> nvidia-driver-libs-nonglvnd bumblebee-nvidia primus > >> if i386 is available as a foreign architecture. > >> > >> That makes me think: should we have a primus-nvidia metapackage that > >> depends on these packages? > > I've now prepared such a metapackage in git. Does this look sensible? > The description was copied from bumblebee-nvidia which is probably not > optimal. Perhaps you can tune it a bit. > > Andreas Hi, Thanks - looks good to me, even the description seems fine. Thanks!
Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM)
Not really sorry. I'm not using this hardware any more. On Thu, 1 Aug 2019, at 02:37, Martin Michlmayr wrote: > * Martin Michlmayr [2018-09-10 14:27]: > > > > > Do you want me to help figure out which change to the kernel fixed the > > > > > problem? > > > > > > > > As far as I can tell and if I'm not mistaken, the fix is already > > > > identified > > > > and is included in 4.9.86. > > > > > > > > I've started working on it for Stretch, and at one point it will be > > > > uploaded > > > > to -proposed-updates for inclusion in the next point release (9.5). > > > > When it's > > > > done I'll probably ask you to try a test kernel to make sure it's really > > > > fixed. > > > > > > I'm happy to try it out when it's available. > > > > Any update on this? Debian stable has 4.9.110-1 now. > > Menno, any chance you can test if your problem has gone away? > > -- > Martin Michlmayr > https://www.cyrius.com/ >
Bug#929503: blhc: Arch improperly detected on newer dpkg-buildpackage
Hello,
I found the cause of #929503.
The following line is not properly parsed:
dpkg-buildpackage: info: host architecture amd64
See attached patch.
Regards
--
Mathieu Parent
From b470b50e1509f582abeeda59bfb9ffbb8ab20716 Mon Sep 17 00:00:00 2001
From: Mathieu Parent
Date: Thu, 1 Aug 2019 00:17:31 +0200
Subject: [PATCH] Detect architecture automatically on newer dpkg-buildpackage
Detected by https://salsa.debian.org/samba-team/samba/-/jobs/247553
---
bin/blhc | 4
1 file changed, 4 insertions(+)
diff --git a/bin/blhc b/bin/blhc
index d9a3bb2..8eaf2f5 100755
--- a/bin/blhc
+++ b/bin/blhc
@@ -964,6 +964,10 @@ foreach my $file (@ARGV) {
$arch = substr $arch, 3;
}
}
+if (not $arch
+and index($line, 'dpkg-buildpackage: info: host architecture ') == 0) {
+$arch = substr $line, 43, -1; # -1 to ignore '\n' at the end
+}
next if $line =~ /^\s*#/;
# Ignore compiler warnings for now.
--
2.20.1
Bug#772928: texlive-latex-base: pdflatex manpage misses docs about synctex option
Control: reassign 772928 texlive-binaries Am 12.12.2014 um 10:37 teilte Olivier Berger mit: > FWIW, pdflatex manpage misses documentation about the -synctex option. > hille@debian-amd64-sid:~$ zless -X /usr/share/man/man1/pdflatex.1.gz .so man1/pdftex.1 ...points to the pdftex manual page, which is located in texlive-binaries. Reassigning. H. -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#933598: chromium: uMatrix crash: Bad extension message browserAction.setIcon
Sorry, I accidentally truncated some lines of the bug report. uMatrix extension: https://chrome.google.com/webstore/detail/umatrix/ogfcmafjalglgifnmanfmnieipoejdcf stderr messages: [4427:4427:0731/225810.582068:ERROR:bad_message.cc(22)] Terminating extension renderer for bad IPC message, reason 8 [4427:4427:0731/225810.582202:ERROR:bad_message.cc(22)] Terminating extension renderer for bad IPC message, reason 8 [4427:4427:0731/225810.582242:ERROR:extension_function.cc(476)] Bad extension message browserAction.setIcon [4468:4468:0731/225810.702874:ERROR:buffer_manager.cc(488)] [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error from previous GL command
Bug#933601: nmu: qtstyleplugins-src_5.0.0+git23.g335dbec-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi! It seems that the package had a binary upload, so now a binNMU would be required for it to migrate. nmu qtstyleplugins-src_5.0.0+git23.g335dbec-3 . amd64 . unstable . -m "Rebuild to allow migration / binary uploaded by maintainer" -- 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 4.19.0-5-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#933499: libreoffice-base: database form with subform no longer works with "Data content could not be loaded" error
[ please always keep the bug CCed so that the discussion gets recorded. ] On Wed, Jul 31, 2019 at 04:00:04PM -0500, william l-k wrote: >The database is mariadb. Two database entry forms are now affected. Both >have linked sub-forms from two seperate tables for entering related data. >One of the databases started out as a libreoffice base then was converted >to a mariadb connection. The other started out as a connection to mariadb. >I saw that bug before I submitted mine, but didn't see a solution. I'll >take a closer look to see. comments 11, 12 and 15 Regards, Rene
Bug#901148: timidity: Timidity needed by solfege
Hi Alain, > I upgraded from Stretch to Buster and sound completely disappeared. > Removing Timidity fixed the problem but made me unable to use gnu > solfege as it > depends on timidity. The sound is broken by timidity-daemon, not the timidity package itself. So you should try to install GNU Solfege and check that timidity-daemon is not installed (timidity "suggests" timidity-daemon so it should not be installed automatically). Best, François
Bug#933600: RFS: acmebot/2.4.4-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "acmebot" * Package name: acmebot Version : 2.4.4-1 Upstream Author : Peter Linss * URL : https://github.com/plinss/acmebot * License : GPLv3 Section : web It builds those binary packages: acmebot - Python tool for managing certificates using ACME v1/v2 protocol To access further information about this package, please visit the following URL: https://mentors.debian.net/package/acmebot Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/a/acmebot/acmebot_2.4.4-1.dsc More information about acmebot can be obtained from https://github.com/plinss/acmebot. Changes since the last upload: * Initial release. (Closes: #930094) Best Regards, Hinrikus Wolf
Bug#933599: musescore: create an upgrade path from 2 to 3
Package: musescore
Version: 3.0.3+dfsg1-1
Severity: wishlist
Hello,
shortly after the release of buster as stable, I upgraded my box from
buster to bullseye. I was kind of shocked to discover that musescore was
marked as "obsolete or locally created", i.e. not present in bullseye.
It took me some time to notice the package renaming from "musescore" to
"musescore3" and to find the right piece of changelog documenting it:
* Rename binary packages to musescore3{,-common} for coïnstallability
(musescore{,-common} 2.x will stay around for buster’s lifetime, and
upstream says users should have both in parallel, for existing
scores)
(from 3.0.3+dfsg1-1, thus the Version: command above)
Now, I understand the reason for the change and have no problem myself
with the renaming and with installing a new package. I suspect, though,
that I wasn't the only user left in the cold and I wonder how many of
them know where to look to solve this. Could something be done, at least
to better document the change and suggest a solution?
Hopefully, at least, people will happen to read this bug and thus find
their way out :-)
Thanks for the great work!
Regards,
Gabriele Stilli
Bug#933598: chromium: uMatrix crash: Bad extension message browserAction.setIcon
Package: chromium Version: 76.0.3809.87-1 Severity: normal After upgrading Chromium from version 76.0.3809.71-1, the uMatrix extension: https://chrome.google.com/webstore/detail/umatrix/ogfcmafjalglgifnmanfmnieipoe started crashing on browser startup. On crash, the following balloon message is displayed: uMatrix has crashed. Click this balloon to reload the extension. As well as the following messages to stderr: [4427:4427:0731/225810.582068:ERROR:bad_message.cc(22)] Terminating extension [4427:4427:0731/225810.582202:ERROR:bad_message.cc(22)] Terminating extension [4427:4427:0731/225810.582242:ERROR:extension_function.cc(476)] Bad extension [4468:4468:0731/225810.702874:ERROR:buffer_manager.cc(488)] [.DisplayComposito Reloading the extension has the same effect. This is likely upstream bug 983675: Three Extensions Failing Without Prior Issue: https://bugs.chromium.org/p/chromium/issues/detail?id=983675 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (800, 'testing'), (700, 'unstable'), (600, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages chromium depends on: ii chromium-common 76.0.3809.87-1 ii libasound2 1.1.8-1 ii libatk-bridge2.0-0 2.30.0-5 ii libatk1.0-0 2.30.0-2 ii libatomic1 9.1.0-10 ii libatspi2.0-02.30.0-7 ii libavcodec58 7:4.1.4-1 ii libavformat587:4.1.4-1 ii libavutil56 7:4.1.4-1 ii libc62.28-10 ii libcairo-gobject21.16.0-4 ii libcairo21.16.0-4 ii libcups2 2.2.10-6 ii libdbus-1-3 1.12.16-1 ii libdrm2 2.4.97-1 ii libevent-2.1-6 2.1.8-stable-4 ii libexpat12.2.7-1 ii libflac8 1.3.2-3 ii libfontconfig1 2.13.1-2 ii libfreetype6 2.9.1-4 ii libgcc1 1:9.1.0-10 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-0 2.58.3-3 ii libgtk-3-0 3.24.5-1 ii libharfbuzz0b2.4.0-2 ii libicu63 63.2-2 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libjsoncpp1 1.7.4-3 ii liblcms2-2 2.9-3 ii libminizip1 1.1-8+b1 ii libnspr4 2:4.21-1 ii libnss3 2:3.45-1 ii libopenjp2-7 2.3.0-2 ii libopus0 1.3-1 ii libpango-1.0-0 1.42.4-6 ii libpangocairo-1.0-0 1.42.4-6 ii libpci3 1:3.6.2-2 ii libpng16-16 1.6.37-1 ii libpulse012.2-4 ii libre2-5 20190101+dfsg-2+b1 ii libsnappy1v5 1.1.7-1 ii libstdc++6 9.1.0-10 ii libvpx5 1.7.0-3 ii libwebp6 0.6.1-2 ii libwebpdemux20.6.1-2 ii libwebpmux3 0.6.1-2 ii libx11-6 2:1.6.7-1 ii libx11-xcb1 2:1.6.7-1 ii libxcb1 1.13.1-2 ii libxcomposite1 1:0.4.4-2 ii libxcursor1 1:1.2.0-2 ii libxdamage1 1:1.1.5-1 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxi6 2:1.7.9-1 ii libxml2 2.9.4+dfsg1-7+b3 ii libxrandr2 2:1.5.1-1 ii libxrender1 1:0.9.10-1 ii libxslt1.1 1.1.32-2 ii libxss1 1:1.2.3-1 ii libxtst6 2:1.2.3-1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages chromium recommends: ii chromium-sandbox 76.0.3809.87-1 Versions of packages chromium suggests: pn chromium-driver pn chromium-l10n pn chromium-shell Versions of packages chromium-common depends on: ii x11-utils 7.7+4 ii xdg-utils 1.1.3-1 Versions of packages chromium-common recommends: ii chromium-sandbox 76.0.3809.87-1 ii fonts-liberation 1:1.07.4-10 ii libgl1-mesa-dri18.3.6-2 pn libu2f-udev pn notification-daemon pn system-config-printer pn upower Versions of packages chromium-sandbox depends on: ii libatomic1 9.1.0-10 ii libc6 2.28-10 ii libgcc1 1:9.1.0-10 ii libstdc++6 9.1.0-10 -- no debconf information
Bug#928993: sdaps: Please package the latest upstream version
Control: severity -1 serious thanks On Wed, Jul 31, 2019 at 05:25:38PM -0400, Boyuan Yang wrote: > Control: severity -1 grave > > Since the new upload of zbar has already dropped the python2 binding, > I'm raising the severity of this bug accordingly. not accordingly, but oh well, thanks at least for notifying us properly! :) -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#929237: closed by Daniel Pimentel (Bug#929237: fixed in fuzz 0.6-16)
Control: reopen -1 On Fri, Jul 19, 2019 at 08:48:09PM +, Debian Bug Tracking System wrote: >* debian/rules: updated to fix FTCBFS (thanks to Helmut Grohne > ). (Closes: #929237) My patch was only partially applied. While CC is now exported, it doesn't have a useful value. As a consequence, fuzz continues to FTCBFS. Helmut
Bug#933370: chrony won't start
On Wed, Jul 31, 2019 at 1:25 PM Vincent Blut wrote: > I seriously doubt that the issue you’re facing is due to /usr being not > yet mounted. But we will know more when you’ll find time to test what I > asked at the beginning of the thread. > I think I just sent those results (in a message beginning "Here are some tests I wasn't able to get to earlier.") and our messages just crossed. Please let me know if I overlooked something. Ross
Bug#928993: sdaps: Please package the latest upstream version
Control: severity -1 grave X-Debbugs-CC: naturesha...@debian.org Since the new upload of zbar has already dropped the python2 binding, I'm raising the severity of this bug accordingly. Regards, Boyuan Yang
Bug#933597: qt3d5-examples: qt examples missing important files
Package: qt3d5-examples Version: 5.11.3+dfsg-2 Severity: important Installing various qt*examples packages such as this does not make them visible in qtcreator. This may be because the various examples-manifest.xml (and associated images) are in the doc-html packages (where they do not appear to be used) rather than in the qt*examples packages where they are needed. Installing the doc-html files magically makes the examples appear in qtcreator. -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (2000, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages qt3d5-examples depends on: ii libc6 2.28-10 ii libqt53dcore5 5.11.3+dfsg-2 ii libqt53dextras5 5.11.3+dfsg-2 ii libqt53dinput5 5.11.3+dfsg-2 ii libqt53dquick5 5.11.3+dfsg-2 ii libqt53dquickextras55.11.3+dfsg-2 ii libqt53drender5 5.11.3+dfsg-2 ii libqt5core5a5.11.3+dfsg1-1 ii libqt5gui5 5.11.3+dfsg1-1 ii libqt5network5 5.11.3+dfsg1-1 ii libqt5qml5 5.11.3-4 ii libqt5quick55.11.3-4 ii libqt5quickwidgets5 5.11.3-4 ii libqt5widgets5 5.11.3+dfsg1-1 ii libstdc++6 8.3.0-6 ii qml-module-qt3d 5.11.3+dfsg-2 ii qml-module-qtquick-scene3d 5.11.3+dfsg-2 qt3d5-examples recommends no packages. qt3d5-examples suggests no packages. -- no debconf information
Bug#933560: glib2.0 FTCBFS: dh_dwz fails, builds without -g, outdated debcrossgen fork
On Wed, 31 Jul 2019 at 17:55:15 +0200, Helmut Grohne wrote: > glib2.0 fails to cross build from source. The immediate reason is that > the toolchain dependency is not satisfiable. Since we don't have > toolchain dependency translation, we must revert that for now to cross > build it, but this is not the topic of this bug. This is a temporary workaround in any case. > Now debcrossgen inserts CFLAGS into the cross file. > However glib2.0 uses a fork of debcrossgen and it wasn't updated yet. Instead of updating the fork of debcrossgen, I'm going to run the ordinary debcrossgen and then edit its output - that seems more likely to keep working. The modified debcrossgen was really a proof-of-concept for a debcrossgen change that I was hoping the meson maintainer would apply sooner than this. smcv
Bug#933078: runit: forced-rescan feature
Hi Dmitry, thanx for this, i'm testing right now. Il giorno ven 26 lug 2019 alle ore 15:30 Dmitry Bogatov ha scritto: > Here I request review. Is this feature really needed. Is timestamp file > needed? Maybe there are simplier ways to implement it? Gerrit Pape said he is collecting patches to do a maintenance release of runit [1] : maybe you can submit the patch to the supervision mailing list to get a review? Lorenzo [1] https://www.mail-archive.com/supervision@list.skarnet.org/msg02073.html
Bug#931135: German translation made me laugh during a meeting
On Wed, Jul 31, 2019 at 10:23:21PM +0200, Helge Kreutzmann wrote: > The translation only changed one word, namely canary. You can find it > in the upstream git repository. > > The remaining translation is only in the latest version in sid (and > most of it in earlier version, e.g. in stable, as well). 'die sich fortpflanzenden Bauschalter' were also quite absurd to me. maybe better use 'vererb(t)en' instead of 'fortpflanzen'? -- tschau, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#933596: python3-bx: missing Breaks: python3-bx-tools
Package: python3-bx Version: 0.8.4-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts replaces-without-breaks Hi, during a test with piuparts and DOSE tools I noticed your package causes removal of files that also belong to another package. This is caused by using Replaces without corresponding Breaks. The installation sequence to reproduce this problem is apt-get install python3-bx-tools # (1) apt-get install python3-bx apt-get remove python3-bx # (2) The list of installed files at points (1) and (2) should be identical, but the following files have disappeared: /usr/bin/aggregate_scores_in_intervals.py /usr/bin/align_print_template.py /usr/bin/axt_extract_ranges.py ... /usr/bin/wiggle_to_binned_array.py /usr/bin/wiggle_to_chr_binned_array.py /usr/bin/wiggle_to_simple.py This is a serious bug violating policy 7.6, see https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces and also see the footnote that describes this incorrect behavior: https://www.debian.org/doc/debian-policy/ch-relationships.html#id13 The python3-bx package has the following relationships with python3-bx-tools: Conflicts: n/a Breaks:n/a Replaces: python3-bx-tools Provides: python3-bx-tools >From the attached log (scroll to the bottom...): 1m38.9s DEBUG: Modified(user, group, mode, size, target): /var/lib/dpkg/info/python3-bx-tools.list expected(root, root, - 100644, 3087, None) != found(root, root, - 100644, 263, None) 1m38.9s ERROR: FAIL: After purging files have disappeared: /usr/bin/aggregate_scores_in_intervals.py owned by: python3-bx /usr/bin/align_print_template.py owned by: python3-bx /usr/bin/axt_extract_ranges.py owned by: python3-bx /usr/bin/axt_to_fasta.py owned by: python3-bx /usr/bin/axt_to_lav.py owned by: python3-bx /usr/bin/axt_to_maf.py owned by: python3-bx /usr/bin/bed_bigwig_profile.py owned by: python3-bx /usr/bin/bed_build_windows.py owned by: python3-bx /usr/bin/bed_complement.py owned by: python3-bx /usr/bin/bed_count_by_interval.py owned by: python3-bx /usr/bin/bed_count_overlapping.py owned by: python3-bx ... /usr/bin/pretty_table.py owned by: python3-bx /usr/bin/qv_to_bqv.py owned by: python3-bx /usr/bin/random_lines.py owned by: python3-bx /usr/bin/table_add_column.py owned by: python3-bx /usr/bin/table_filter.py owned by: python3-bx /usr/bin/tfloc_summary.py owned by: python3-bx /usr/bin/ucsc_gene_table_to_intervals.py owned by: python3-bx /usr/bin/wiggle_to_array_tree.py owned by: python3-bx /usr/bin/wiggle_to_binned_array.py owned by: python3-bx /usr/bin/wiggle_to_chr_binned_array.py owned by: python3-bx /usr/bin/wiggle_to_simple.py owned by: python3-bx 1m38.9s ERROR: FAIL: After purging files have been modified: /var/lib/dpkg/info/python3-bx-tools.list not owned cheers, Andreas python3-bx-tools=0.8.2-1_python3-bx=0.8.4-1.log.gz Description: application/gzip
Bug#933543: (no subject)
Sorry, used reportbug for the first time... Misprint the email.
Bug#933550: wmfire FTCBFS: configure.ac hard codes pkg-config
On 2019-07-31, at 15:31:27 +0200, Helmut Grohne wrote: > wmfire's configure.ac hard codes the build architecture pkg-config by > using AC_PATH_PROG rather than AC_PATH_TOOL. However, using > PKG_CHECK_MODULES would be even better and is what the attached patch > implements to make wmfire cross buildable. Please consider applying > it. I've tweaked the patch, added it to Salsa and prepared 1.2.4-4. Andreas, would you mind reviewing? J. signature.asc Description: PGP signature
Bug#933549: wmdrawer FTCBFS: Makefile hard codes pkg-config
On 2019-07-31, at 15:19:40 +0200, Helmut Grohne wrote: > wmdrawer fails to cross build from source, because the upstream > Makefile hard codes the build architecture pkg-config. After making it > substitutable, wmdrawer cross builds successfully. Please consider > applying the attached patch. I've added the patch to Salsa and prepared 0.10.5-4. Andreas, would you mind reviewing? J. signature.asc Description: PGP signature
Bug#933231: exim4-base: /etc/cron.daily/exim4-base can't detect hostname via hostname --fqdn
On Sun, Jul 28, 2019 at 02:08:20PM +0200, Andreas Metzler wrote:
> On 2019-07-27 Christian Garbs wrote:
> > Package: exim4-base
> > Version: 4.92-8+deb10u1
> > Severity: normal
> > Tags: ipv6
>
> > After the update from Stretch to Buster, on one of my systems
> > /etc/cron.daily/exim4-base failed on every run with just
>
> > hostname: Name or service not known
>
> > as an error message.
>
> > I could trace this to the usage of "hostname --fqdn" in the script.
[...]
> > Is there another way to get a proper hostname, perhaps from Exim
> > or the Exim configuration, that can be used in /etc/cron.daily/exim4-base
> > instead of calling "hostname --fqdn"?
>
> There is
> /usr/sbin/exim4 -bP primary_hostname
> or
> /usr/sbin/exim4 -be '${primary_hostname}'
>
> How about the attached patch?
Hello Andreas,
the patch looks good!
The fallback to hostname without any parameters is a nice touch – if
the admin can keep his systems apart, everything is ok, no need for
any flags ;-)
I have applied the patch against the original /etc/cron.daily/exim4-base
from Buster and deployed it to three systems (the one that showed the
bug plus two unaffected others): Everything works as expected.
Please apply the patch to the next version.
Thanks for the quick reply and patch!
Christian
--
Christian.Garbshttps://www.cgarbs.de
A truly wise man never plays leapfrog with a unicorn.
Bug#929521: Conflicts in upgrade to 418.74-1 with optimus setup
On 11/06/2019 12.21, Luca Boccassi wrote: > On Tue, 2019-06-11 at 00:21 +0200, Andreas Beckmann wrote: >> On 07/06/2019 18.12, Luca Boccassi wrote: >>> Hi, this should be the list: >>> >>> bbswitch bumblebee bumblebee-nvidia primus primus-libs primus-libs- >>> ia32 >>> nvidia-driver-libs-nonglvnd nvidia-driver-libs-nonglvnd-i386 >> >> Is this documented somewhere? >> >> This can be minimized to >> apt-get install --install-recommends \ >> nvidia-driver-libs-nonglvnd bumblebee-nvidia primus >> if i386 is available as a foreign architecture. >> >> That makes me think: should we have a primus-nvidia metapackage that >> depends on these packages? I've now prepared such a metapackage in git. Does this look sensible? The description was copied from bumblebee-nvidia which is probably not optimal. Perhaps you can tune it a bit. Andreas
Bug#933471: ctsim: Please rebuild against wxWidgets GTK 3 package
Hi Olly,
thanks for the hint. Would you be able to propose a patch?
Kind regards
Andreas.
On Thu, Aug 01, 2019 at 06:42:34AM +1200, Olly Betts wrote:
> On Wed, Jul 31, 2019 at 11:54:51AM +0200, Andreas Tille wrote:
> > I think I have solved the issue below in Git despite I'm very curious
> > why I need to add a hack[1] to make sure all header files will be found
> > properly.
>
> You really should always run wx-config --cflags and put the result in
> CXXFLAGS (or whatever equivalent the build system has).
>
> In some cases you might get away with not doing that, but not here -
> the libwxgtk3.0-dev and libwxgtk3.0-gtk3-dev packages are parallel
> installable so the appropriate header search path needs to be specified
> to the compiler.
>
> > Unfortunately there is another build issue which I consider undependent
> > from the wxgtk migration (not sure, may be its related anyway or may be
> > its a gcc-9 issue?):
>
> ctsim's configure.ac shows it probing directly for wx libraries:
>
> | AC_CHECK_LIB(wx_gtk2u_core-3.0, main, [wxwin=true; wx_gtk=true;
> AC_DEFINE(HAVE_WXWINDOWS,1,[wxwindows library])], [], [-L/usr/lib64
> -L/usr/lib ${GTK_LIBS} ${GLIB_LIBS} ])
>
> That library name is specific to a GTK2 build, but really these checks
> should be done via wx-config (or one of the macros from wxwin.m4 which
> call wx-config behind the scenes).
>
> I also notice direct probing for GTK2 in there:
>
> | AM_PATH_GTK_2_0(2.0.0,havegtk_am=yes,havegtk_am=no)
>
> I'm not sure why that's done - a quick grep turned up no includes of gtk
> headers, and havegtk_am's value never seems to be used. But it probably
> needs removing or updating to GTK3 if it's actually needed.
>
> Cheers,
> Olly
>
--
http://fam-tille.de
Bug#933370: chrony won't start
On Wed, Jul 31, 2019 at 12:13:15PM -0700, Ross Boylan wrote: On Wed, Jul 31, 2019 at 3:03 AM Vincent Blut wrote: On Tue, Jul 30, 2019 at 05:35:52PM -0700, Ross Boylan wrote: >[Ross] >> >I've run into other problems with services starting before all >> >filesystems were mounted; I wonder if that's an issue here (not on the >> >machine right now). >> >i.e., /usr isn't mounted when timesync first checks for chrony, and so >> >it thinks things are OK. >> >[Vincent] >> I don’t think it’s feasible as the -.mount unit is unconditionally >> active. As for separate /usr partition, that’s the role of the initramfs >> to mount it. > >Unfortunately, this is one area I can speak from authority: it is >absolutely possible for services to start before all critical mounts >have happened. Bug#933139 has gory details. Among other issues, bind >attempted to start before /var was mounted. Sure Ross, I do not dispute that. My comment referred only to /usr. I'm not sure I understand "I don't think it's feasible as the -.mount unit is unconditionally active" I thought "it's feasible" referred to the idea that /usr might not be mounted, and you were saying it would have to be mounted. Since /var doesn't have to be mounted, my assumption is that /usr doesn't have to be mounted for the same reasons, if it's a separate logical volume. I can now confirm it is separate on my system. As I said, even if all my suppositions are true they may have nothing to do with current problem, though they would explain why timesyncd might be able to start. I seriously doubt that the issue you’re facing is due to /usr being not yet mounted. But we will know more when you’ll find time to test what I asked at the beginning of the thread. Ross Cheers, Vincent signature.asc Description: PGP signature
Bug#933595: transition: pkg-js-tools
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition (please explain about the transition: impacted packages, reason, ... for more info see: https://wiki.debian.org/Teams/ReleaseTeam/Transitions) Hi all, pkg-js-tools provides a debhelper plugin that handles "dh --with nodejs". Until 0.7, it was used for dh_auto_test. Since version 0.8.6, it provides a dh_auto_install hooks that permits to automatically install node packages in the right place: /usr/share/nodejs or /usr/lib//nodejs instead of old /usr/lib/nodejs. It also reads package.json to select automatically files to install. More than 90% node modules can be installed then without debian/install. A package that uses it for tests will probably have build failures and risks to install libraries in old and new place. Around 100 packages are affected, I prepared the update in salsa for those I have identified. I fill this request to prevent testing migration reject because of autopkgtest regressions. I'm not sure this is the good place or if a transition issue is needed in this case. If not, please forgive me for this inconvenience and close this issue. Cheers, Xavier Ben file: title = "pkg-js-tools"; is_affected = .depends ~ "pkg-js-tools"; is_good = .depends ~ "pkg-js-tools (>= 0.8.[6-9])"; is_bad = .depends ~ "pkg-js-tools";
Bug#931135: German translation made me laugh during a meeting
Hello Holger, On Wed, Jul 31, 2019 at 07:47:59PM +, Holger Levsen wrote: > On Wed, Jul 31, 2019 at 09:13:51PM +0200, Helge Kreutzmann wrote: > > [...] I appreciate getting feedback for the > > translation. > > where can one find the updated translation? The translation only changed one word, namely canary. You can find it in the upstream git repository. The remaining translation is only in the latest version in sid (and most of it in earlier version, e.g. in stable, as well). Greetings Helge -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ signature.asc Description: PGP signature
Bug#933370: chrony won't start
Here are some tests I wasn't able to get to earlier. On Mon, Jul 29, 2019 at 5:39 PM Vincent Blut wrote: . > > Nevertheless, I would like you to test some things. > To begin with, I have an updated chrony unit file in a private git > branch targeting a future revision (not the next one) containing: > > Wants=time-sync.target > Before=time-sync.target > > That would be great if you could override the unit file currently > provided by chrony to add these two lines. I have no high hopes, but I’m > sill curious to see the result in this case. I tried it and it didn't help. I was still able to start it manually--I was a little concerned that since Before=time-sync.target would be unsatisfiable after startup it would never start. > > If that does not work, just removing systemd-timesyncd.service from the > “Conflicts=” line in the chrony unit file may fix the issue… well I > think. ;-) I did systemctl disable systemd-timesyncd and now chrony runs (and stays running) on startup. Here are some logs and status info from what happened with the override in place and debug systemd.log_level=debug as kernel options (but none of the other options I used before). This also shows that status of systemd-timesyncd right after startup. This is from before I disabled systemd-timesyncd.service. root@barley:~# date; uptime Wed 31 Jul 2019 12:51:18 PM PDT 12:51:18 up 2 min, 11 users, load average: 6.08, 2.93, 1.12 root@barley:~# systemctl status chrony ● chrony.service - chrony, an NTP client/server Loaded: loaded (/lib/systemd/system/chrony.service; enabled; vendor preset: enabled) Drop-In: /etc/systemd/system/chrony.service.d └─override.conf Active: inactive (dead) Docs: man:chronyd(8) man:chronyc(1) man:chrony.conf(5) Jul 31 12:49:20 barley systemd[1]: chrony.service: chrony.service/stop woul…job. Jul 31 12:49:20 barley systemd[1]: chrony.service: Deleting chrony.service/…act. Jul 31 12:49:20 barley systemd[1]: chrony.service: chrony.service/stop woul…job. Jul 31 12:49:20 barley systemd[1]: chrony.service: Deleting chrony.service/…act. Jul 31 12:49:21 barley systemd[1]: chrony.service: chrony.service/stop woul…job. Jul 31 12:49:21 barley systemd[1]: chrony.service: Deleting chrony.service/…act. Jul 31 12:49:25 barley systemd[1]: chrony.service: Job 124 chrony.service/s…eled Jul 31 12:49:25 barley systemd[1]: chrony.service: Installed new job chrony… 702 Jul 31 12:49:25 barley systemd[1]: chrony.service: Job 702 chrony.service/s…done Hint: Some lines were ellipsized, use -l to show in full. root@barley:~# systemctl status systemd-timesyncd ● systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled) Drop-In: /usr/lib/systemd/system/systemd-timesyncd.service.d └─disable-with-time-daemon.conf Active: inactive (dead) Condition: start condition failed at Wed 2019-07-31 12:49:27 PDT; 2min 27s ago └─ ConditionFileIsExecutable=!/usr/sbin/chronyd was not met Docs: man:systemd-timesyncd.service(8) Jul 31 12:49:20 barley systemd[1]: systemd-timesyncd.service: Installed new… 370 Jul 31 12:49:20 barley systemd[1]: systemd-timesyncd.service: Merged system… 370 Jul 31 12:49:21 barley systemd[1]: systemd-timesyncd.service: Merged system… 370 Jul 31 12:49:25 barley systemd[1]: systemd-timesyncd.service: Merged system… 370 Jul 31 12:49:27 barley systemd[1]: systemd-timesyncd.service: ConditionFile…ded. Jul 31 12:49:27 barley systemd[1]: systemd-timesyncd.service: ConditionFile…led. Jul 31 12:49:27 barley systemd[1]: systemd-timesyncd.service: Starting requ…nit. Jul 31 12:49:27 barley systemd[1]: systemd-timesyncd.service: Job 370 syste…done Jul 31 12:49:27 barley systemd[1]: Condition check resulted in Network Time…ped. Hint: Some lines were ellipsized, use -l to show in full. root@barley:~# journalctl -b | grep -E "(chrony|timesync)" Jul 31 12:49:18 barley systemd-sysusers[608]: Group systemd-timesync already exists. Jul 31 12:49:18 barley systemd-sysusers[608]: User systemd-timesync already exists. Jul 31 12:49:20 barley systemd[1]: Pulling in systemd-timesyncd.service/start from sysinit.target/start Jul 31 12:49:20 barley systemd[1]: Added job systemd-timesyncd.service/start to transaction. Jul 31 12:49:20 barley systemd[1]: Pulling in system.slice/start from systemd-timesyncd.service/start Jul 31 12:49:20 barley systemd[1]: Pulling in var.mount/start from systemd-timesyncd.service/start Jul 31 12:49:20 barley systemd[1]: Pulling in -.mount/start from systemd-timesyncd.service/start Jul 31 12:49:20 barley systemd[1]: Pulling in time-sync.target/start from systemd-timesyncd.service/start Jul 31 12:49:20 barley systemd[1]: Pulling in shutdown.target/stop from systemd-timesyncd.service/start Jul 31 12:49:20 barley systemd[1]: Pulling in chrony.service/stop from systemd-timesyncd.service/start Jul 31 12:49:20 barley systemd[1]: Added job
Bug#933594: libvc FTCBFS: unsatisfiable Build-Depends: shunit2
Source: libvc Version: 006-2 Tags: patch User: debian-cr...@lists.debian.org Usertags: cross-satisfiability libvc fails to cross build from source, because its build dependency on shunit2 is unsatisfiable. Fortunately, it is only used for tests which cannot be run during cross builds and are disabled by DEB_BUILD_OPTIONS=nocheck. Thus the dependency can be annotated with . Please consider applying the attached patch. Helmut diff --minimal -Nru libvc-006/debian/changelog libvc-006/debian/changelog --- libvc-006/debian/changelog 2019-07-14 11:55:15.0 +0200 +++ libvc-006/debian/changelog 2019-07-31 22:00:30.0 +0200 @@ -1,3 +1,10 @@ +libvc (006-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Annotate Build-Depends: shunit2 with . (Closes: #-1) + + -- Helmut Grohne Wed, 31 Jul 2019 22:00:30 +0200 + libvc (006-2) unstable; urgency=medium * d/t/control: Add dependency on libc6-dev diff --minimal -Nru libvc-006/debian/control libvc-006/debian/control --- libvc-006/debian/control2019-07-11 17:57:04.0 +0200 +++ libvc-006/debian/control2019-07-31 22:00:00.0 +0200 @@ -11,7 +11,7 @@ flex, libtool, quilt, - shunit2 + shunit2 Standards-Version: 4.4.0 Homepage: http://rolo.sourceforge.net/ Vcs-Git: https://salsa.debian.org/debian/libvc.git
Bug#933579: ITP: openvr -- openvr sdk
On Thu, Aug 01, 2019 at 02:23:21AM +0800, Andrew Lee (李健秋) wrote: > Package: wnpp > Severity: wishlist > Owner: Andrew Lee (李健秋) > > * Package name: openvr > Version : 1.4.18 > Upstream Author : Valve Corporation > * URL : https://github.com/ValveSoftware/openvr > * License : Expat > Programming Lang: C > Description : openvr sdk > > OpenVR is an API and runtime that allows access to VR hardware from > multiple vendors without requiring that applications have specific > knowledge of the hardware they are targeting. This repository is an > SDK that contains the API and samples. The runtime is under SteamVR > in Tools on Steam. Can OpenVR work with any Open Source backend? (And do you intend to package such a backend?) It appears to only work with SteamVR, which is proprietary. If this only works with SteamVR or other proprietary backends, or in general if Debian doesn't have any Open Source backend for this, it'll have to go to contrib, not main.
Bug#933593: mark nlohmann-json3-dev Multi-Arch: foreign
Package: nlohmann-json3-dev
Version: 3.6.1-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertag: cross-satisfiability
Control: affects -1 + src:bali-phy src:lief src:mkvtoolnix src:nheko src:poedit
The affected packages fail to satisfy their cross Build-Depends, because
their dependency on nlohmann-json3-dev is unsatisfiable. In general,
Architecture: all packages can never satisfy cross Build-Depends unless
marked Multi-Arch: foreign or annotated :native. In this case, the
Multi-Arch: foreign marking makes sense, because nlohmann-json3-dev
essentially is a data package. It doesn't have any dependencies nor
maintainer scripts and effectively is a header-only C++ library. Please
consider applying the attached patch.
Helmut
diff --minimal -Nru nlohmann-json3-3.6.1/debian/changelog
nlohmann-json3-3.6.1/debian/changelog
--- nlohmann-json3-3.6.1/debian/changelog 2019-07-05 18:15:55.0
+0200
+++ nlohmann-json3-3.6.1/debian/changelog 2019-07-31 21:36:15.0
+0200
@@ -1,3 +1,10 @@
+nlohmann-json3 (3.6.1-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Mark nlohmann-json3-dev Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne Wed, 31 Jul 2019 21:36:15 +0200
+
nlohmann-json3 (3.6.1-1) unstable; urgency=medium
* Upload to unstable.
diff --minimal -Nru nlohmann-json3-3.6.1/debian/control
nlohmann-json3-3.6.1/debian/control
--- nlohmann-json3-3.6.1/debian/control 2019-07-05 18:10:52.0 +0200
+++ nlohmann-json3-3.6.1/debian/control 2019-07-31 21:36:07.0 +0200
@@ -17,6 +17,7 @@
Package: nlohmann-json3-dev
Section: libdevel
Architecture: all
+Multi-Arch: foreign
Depends:
${misc:Depends},
Conflicts:
Bug#931135: German translation made me laugh during a meeting
On Wed, Jul 31, 2019 at 09:13:51PM +0200, Helge Kreutzmann wrote: > [...] I appreciate getting feedback for the > translation. where can one find the updated translation? -- tschau, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#933592: Webpack 4 transition: node-node-forge fail to build with webpack 4
Package: node-node-forge Version: 0.8.5~dfsg-1 Severity: important Control: tags -1 patch While trying build your package with webpack 4.7 in experimental, build failed with this error. Error: webpack.optimize.UglifyJsPlugin has been removed, please use config.optimization.minimize instead. Same error was fixed in node-timeago.js and node-axios. Please check those packages for how to fix this error. More details about this transition here https://wiki.debian.org/Javascript/Nodejs/Webpack4 Please fix this build error to have webpack 4 in unstable soon. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#933540: [Pkg-javascript-devel] Bug#933540: Bug#933540: pkg-js-tools auto install does not work with multiple binary packages
Le 31/07/2019 à 20:15, Xavier a écrit : > Le 31/07/2019 à 13:52, Pirate Praveen a écrit : >> Package: pkg-js-tools >> Version: 0.8.6 >> Severity: wishlist >> >> I was trying to pkg-js-tools auto install option with >> node-fuzzaldrin-plus but it did not work as it had libjs-fuzzaldrin-plus >> also as a binary package. The files got copied to debian/tmp and the >> final deb file did not these files. >> >> I think you are already aware about this, but just adding here for the >> record. > > This is how dh_auto_install works: when there is more than 1 package, it > installs files in debian/tmp, then dh_install picks these files from > debian/tmp to store into debian/ (one arg per line) or in > source directory (two args per line). In this case, you can use a > debian/node-foo.install like this: > > # debian/node-arch-indep.install > usr/share/nodejs/foo/ > > # debian/node-arch-dep.install > usr/lib/*/nodejs/foo/ > > # debian/libjs.install > dist/* usr/share/javascript/foo/ > > You can see an example in node-clean-css (not published but ready for > pkg-js-tools >= 0.8.7). > > Other tip for dh_links with a arch-dep package: > > # debian/node.foo.links > usr/lib/*/nodejs/foo/bin/cli.js usr/bin/foo Doc updated: https://salsa.debian.org/js-team/pkg-js-tools/tree/master/doc/tools#multiple-binary-packages
Bug#931135: German translation made me laugh during a meeting
Hello Guillem, On Tue, Jul 16, 2019 at 11:36:35AM +0200, Guillem Jover wrote: > On Wed, 2019-06-26 at 21:06:19 +0200, Stefan Potyra wrote: > > Package: dpkg-dev > > Version: 1.19.6 > > Severity: minor > > Tags: l10n > > > the following translation in the "FEATURE AREAS" -> "qa" might need some > > improvement: > > > > LANG=C man dpkg-buildflags > > ___snip___ > >canary This setting (disabled by default) adds dummy canary > >options to the build flags, so that the build logs can be checked > >for how the build flags propagate and to allow finding any omission > >of normal build flag settings. The only currently supported > >flags are CPPFLAGS, CFLAGS, OBJCFLAGS, CXXFLAGS and OBJCXXFLAGS with > >flags set to -D__DEB_CANARY_flag_random-id__, and LDFLAGS set > >to -Wl,-z,deb-canary-random-id. > > __snip__ > > > > LANG=de_DE.UTF-8 man dpkg-buildflags > > __snip__ > > canary Diese Einstellung (standardmäßig deaktiviert) fügt > > Pseudo-Kanarienvögel-Optionen zu den Bauschaltern hinzu, > > so dass die Bauprotokolle überprüft werden können, wie die > > Bauschalter sich fortpflanzen. Dies erlaubt, Auslassungen in den > > normalen Bauschaltereinstellungen zu finden. Derzeit werden nur > > die Schalter CPPFLAGS, CFLAGS, OBJCFLAGS, CXXFLAGS und > > OBJCXXFLAGS unterstützt, wobei die Schalter auf > > -D__DEB_CANARY_Schalter_Zufallskennung__ gesetzt werden, > > und LDFLAGS, das auf -Wl,-z,deb-canary-Zufallskennung gesetzt wird. > > __snip__ > > > > Not too sure, if we should fix this or just keep it as an easter egg :). > > > > From https://www.oocities.org/spunk/birds.htm#canary: > > Helge, could you handle this, please? :) Yes, doing so now. For the record: I chose "Zufallsbarriere" as people do not seem to know the background of this word (see Martin Bagges reply for details). Just wondering why english speakers are not complaining about missing bees and requesting animals to be removed from technical documentation. Stefan, I suggest that you bring forward further improvements to me and debian-l10n-ger...@lists.debian.org, so we can discuss them properly. (You raised the translation for "flag" and "propagate" if I see that correctly). I appreciate getting feedback for the translation. Guillem, is is it a known problem that [1] yields an internal server error? Greetings Helge [1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=dpkg;dist=unstable -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ signature.asc Description: PGP signature
Bug#933471: ctsim: Please rebuild against wxWidgets GTK 3 package
On Wed, Jul 31, 2019 at 11:54:51AM +0200, Andreas Tille wrote:
> I think I have solved the issue below in Git despite I'm very curious
> why I need to add a hack[1] to make sure all header files will be found
> properly.
You really should always run wx-config --cflags and put the result in
CXXFLAGS (or whatever equivalent the build system has).
In some cases you might get away with not doing that, but not here -
the libwxgtk3.0-dev and libwxgtk3.0-gtk3-dev packages are parallel
installable so the appropriate header search path needs to be specified
to the compiler.
> Unfortunately there is another build issue which I consider undependent
> from the wxgtk migration (not sure, may be its related anyway or may be
> its a gcc-9 issue?):
ctsim's configure.ac shows it probing directly for wx libraries:
| AC_CHECK_LIB(wx_gtk2u_core-3.0, main, [wxwin=true; wx_gtk=true;
AC_DEFINE(HAVE_WXWINDOWS,1,[wxwindows library])], [], [-L/usr/lib64 -L/usr/lib
${GTK_LIBS} ${GLIB_LIBS} ])
That library name is specific to a GTK2 build, but really these checks
should be done via wx-config (or one of the macros from wxwin.m4 which
call wx-config behind the scenes).
I also notice direct probing for GTK2 in there:
| AM_PATH_GTK_2_0(2.0.0,havegtk_am=yes,havegtk_am=no)
I'm not sure why that's done - a quick grep turned up no includes of gtk
headers, and havegtk_am's value never seems to be used. But it probably
needs removing or updating to GTK3 if it's actually needed.
Cheers,
Olly
Bug#933370: chrony won't start
On Wed, Jul 31, 2019 at 3:03 AM Vincent Blut wrote: > > On Tue, Jul 30, 2019 at 05:35:52PM -0700, Ross Boylan wrote: > >[Ross] > >> >I've run into other problems with services starting before all > >> >filesystems were mounted; I wonder if that's an issue here (not on the > >> >machine right now). > >> >i.e., /usr isn't mounted when timesync first checks for chrony, and so > >> >it thinks things are OK. > >> > >[Vincent] > >> I don’t think it’s feasible as the -.mount unit is unconditionally > >> active. As for separate /usr partition, that’s the role of the initramfs > >> to mount it. > > > >Unfortunately, this is one area I can speak from authority: it is > >absolutely possible for services to start before all critical mounts > >have happened. Bug#933139 has gory details. Among other issues, bind > >attempted to start before /var was mounted. > > Sure Ross, I do not dispute that. My comment referred only to /usr. > I'm not sure I understand "I don't think it's feasible as the -.mount unit is unconditionally active" I thought "it's feasible" referred to the idea that /usr might not be mounted, and you were saying it would have to be mounted. Since /var doesn't have to be mounted, my assumption is that /usr doesn't have to be mounted for the same reasons, if it's a separate logical volume. I can now confirm it is separate on my system. As I said, even if all my suppositions are true they may have nothing to do with current problem, though they would explain why timesyncd might be able to start. Ross > >As for how or if systemd and initramfs are integrated, I don't know. > >I am using an initrd, and it didn't prevent the problem just > >mentioned.
Bug#891194: 3dldf: please make the build reproducible
Am 23.02.2018 um 11:10 teilte Chris Lamb mit: Hi Chris, > Whilst working on the Reproducible Builds effort [0], we noticed > that 3dldf could not be built reproducibly as it needlessly > includes timestamps in the generated (eg.) dodec_03.mp files. > > Patch attached. An alternative would be to parse SOURCE_DATE_EPOCH > [1]. > The provided patch disables time stamping in general. I don't think this is a good idea, as users might complain about changed program behavior. Could you extend the patch so the program obeys the SOURCE_DATE_EPOCH variable and changes its behavior only if that variable is set? Thanks, Hilmar -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#933523: debian-installer: efivarfs isn't mounted, install on efi system fails at grub dummy installation
Hey Steve,
forgot to mention that you need to disable the automatic grub installation
for the workaround.
I've run the installation with the preseed file mentioned above and this is
the syslog: https://drop.leah.is/pJqPJ62E/+inline
Regards Leah
Am Mi., 31. Juli 2019 um 19:32 Uhr schrieb Steve McIntyre :
> Hi Leah,
>
> On Wed, Jul 31, 2019 at 10:19:19AM +0200, Leah Oswald wrote:
> >Package: debian-installer
> >Version: 20190702
> >Severity: important
> >Tags: d-i
> >
> >Hey, we tried to install debian buster with our preseed file (see:
> https://paste.debian.net/hidden/ecde0369/) that was working with debian
> stretch.
> >Now the installation fails at installing the grub dummy ("Unable to
> install GRUB in dummy | Executing "grub-install dummy failed."").
> >
> >The syslog of the installer gives a hint to a missing access to the efi
> variables:
> >Jul 30 15:40:04 grub-installer: info: Installing grub on 'dummy'
> >Jul 30 15:40:04 grub-installer: info: grub-install does not support
> --no-floppy
> >Jul 30 15:40:04 grub-installer: info: Running chroot /target
> grub-install --force "dummy"
> >Jul 30 15:40:04 grub-installer: Installing for x86_64-efi platform.
> >Jul 30 15:40:06 grub-installer: grub-install: warning: Cannot read EFI
> Boot* variables.
> >Jul 30 15:40:06 grub-installer: grub-install: warning: read_file: could
> not read from file: Input/output error.
> >Jul 30 15:40:06 grub-installer: grub-install: warning: vars_get_variable:
> read_file(/sys/firmware/efi/vars/Boot0001-8be4df61-93ca-11d2-aa0d-00e098032b8c/raw_var)
> failed: Input/output error.
> >Jul 30 15:40:06 grub-installer: grub-install: warning: efi_get_variable:
> ops->get_variable failed: Input/output error.
> >Jul 30 15:40:06 grub-installer: grub-install: error: failed to register
> the EFI boot entry: Input/output error.
> >Jul 30 15:40:06 grub-installer: error: Running 'grub-install --force
> "dummy"' failed.
> >
> >After manually mounting the efivarfs the installation of the grub dummy
> works. We could work arround this issue by adding the following line to our
> preseed file, but this shouldn't be the solution rather than a workarround.
> >
> >d-i preseed/late_command string in-target sh -c "mount -t efivarfs
> efivarfs /sys/firmware/efi/efivars; grub-install; update-grub;"
>
> Hmmm, that's odd. I'd expect the efivarfs stuff to Just Work (TM) for
> you. Can you share a full syslog please? Curious to see what's going
> on.
>
> --
> Steve McIntyre, Cambridge, UK.
> st...@einval.com
> Into the distance, a ribbon of black
> Stretched to the point of no turning back
>
>
Bug#890734: texlive-metapost: mpost does not honour SOURCE_DATE_EPOCH
Hi Hilmar, > The place where we would have to patch is clear, attached is a first > patch. It disables time stamping in general. Can you tell how to > evaluate the ENV variable SOURCE_DATE_EPOCH? S_D_E is an effort by reproducible-builds initiative, and it is a good idea. But hard-coded rewriting of the actual creating time is wrong. We need to do something similar to what pdftex/luatex/xetex/... does. If the variable is set it provides a datetime that should be used instead of the actual time. You can look into the first patch by looking at the texlive-bin repository with git show c832647f4d1fe579fd4eb46ff8b505030b5124db Best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#933502: workaround
rebuilding locally of course works fine
Bug#933419: darkradiant: Please rebuild against wxWidgets GTK 3 package
On Wed, 31 Jul 2019, Tobias Frost wrote: A quick Thought: Would there be a possiblity to have at least an message printed out on wayland before crashing emitted from wxwidgets? like a warning "you are using GLCanvas under wayland, this app will crash!" Yes, in fact, I've upstreamed such a fix. I thought I had included that patch in Debian, but it appears that I have not. We can definitely do that. BTW The other issue I mentioned is not related to wayland but to having a QHD+ display… I need to pinpoint that further and will then file a bug accordingly, however I'm not sure against which package. This is a regression which makes darkradiant* unusable, so I will need to postpone a fix for this bug, unfortunatly. * one have to expect that someone using darkradiant using a QHD+ or 4K display, because of the nature of darkadiant. Is this same bug that you've written up recently as #933554? I don't have a Debian system with a HiDPI display, but I should probably be able to test on another OS. Scott
Bug#890734: texlive-metapost: mpost does not honour SOURCE_DATE_EPOCH
Am 18.02.2018 um 08:16 teilte Jerome Benoit mit: Hi Jerome, > it appears the mpost does not honour SOURCE_DATE_EPOCH: > see attached script. > I'm not sure what the significance of the SOURCE_DATE_EPOCH effort is. Is is just Debian specific or are there more parties, which are trying to build reproducibly? I'm just evaluating if we could submit that bug to upstream or if a possibly patch needs to be developed (and maintained) in Debian. The place where we would have to patch is clear, attached is a first patch. It disables time stamping in general. Can you tell how to evaluate the ENV variable SOURCE_DATE_EPOCH? Hilmar -- sigfault #206401 http://counter.li.org Index: texlive-bin/texk/web2c/mplibdir/psout.w === --- texlive-bin.orig/texk/web2c/mplibdir/psout.w2019-07-31 18:22:53.956816442 +0200 +++ texlive-bin/texk/web2c/mplibdir/psout.w 2019-07-31 18:28:39.212816442 +0200 @@ -5059,8 +5059,8 @@ s = mp_metapost_version(); mp_ps_print(mp, s); mp_xfree(s); - mp_ps_print_nl(mp, "%%CreationDate: "); - mp_ps_print_int(mp, round_unscaled(internal_value(mp_year))); + mp_ps_print_nl(mp, "%%CreationDate: 1970.01.01:00.00"); + /* mp_ps_print_int(mp, round_unscaled(internal_value(mp_year))); mp_ps_print_char(mp, '.'); mp_ps_print_dd(mp, round_unscaled(internal_value(mp_month))); mp_ps_print_char(mp, '.'); @@ -5068,7 +5068,7 @@ mp_ps_print_char(mp, ':'); t = round_unscaled(internal_value(mp_time)); mp_ps_print_dd(mp, t / 60); - mp_ps_print_dd(mp, t % 60); + mp_ps_print_dd(mp, t % 60); */ mp_ps_print_nl(mp, "%%Pages: 1"); } signature.asc Description: OpenPGP digital signature
Bug#933514: tmux: Screen garbling in ncurses apps
On 2019-07-31 09:18 +0200, Romain Francoise wrote: > On Wed, Jul 31, 2019 at 5:42 AM T. Joseph Carter > wrote: >> The latest version of tmux has issues with screen updates under GNOME >> Terminal with ncurses apps. This causes eg weechat's scrollback (pgup, >> pgdn) to not draw correctly, causes specific issues with aptitude as >> well. > > Thanks for the report. I don't use GNOME Terminal and I haven't > experienced any similar issues myself, but I will investigate. > > Can you provide more details about how to reproduce using aptitude? > >> I think this may be the result of the cherry-pick of 38b8a198bac6 from >> upstream, you may need an additional patch as well. > > Why? This is a fix for a crash which doesn't look related. > > Do you experience the issue only when multiple panes are used in a window? > >> I suspect the version of tmux found in experimental will not have this >> problem, but I haven't tested it yet. I expect you're holding it due to >> the freeze, but I do not believe 2.9a-2 makes a good release candidate. > > No, the freeze is over but the 3.0 release was pushed back to October, > so 3.0-rc will remain in experimental for the immediate future. Maybe the problems with screen updates have been triggered by ncurses-base 6.1+20190713-1, see #933572? I could reproduce that one with tmux 2.8-3, 2.9a-2 and 3.0~rc3-1. Cheers, Sven
