Bug#952897: opentmpfiles: Please make opentmpfiles to be drop-in replacement to systemd-tmpfiles
Package: opentmpfiles Version: 0.2+2019.05.21.git.44a55796ba-2 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear Maintainer, to make opentmpfiles usable for package maintainers it needs to be drop-in replacement in a sense that I can rely on the interface to be available for my packages. Not by calling extra script, not by adding extra shell spaghetti to decide whether systemd-tmpfiles is available and if not try opentmpfiles and if not ... As a packager I want to be able to freely use the declaratife interfaces provided by systemd even when writing sysv-rc scripts. The other option would be to just drop the init script and provide just the service file, but I am not decided I want to go this path. Ondrej - -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-8-amd64 (SMP w/8 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAl5b365fFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u WcKoEw//YrGedT2qe3TZ7S+2Cjm6F+oXHw96NfHGEhB6znFjhL50tHZtOBzktpf3 ijB42PuX+8Y5XXu+hUGfQ8tO4LKy3YupR0MJlZnSPftS1yFX2DD3aPZAKZdpXdMa hGFFIpNRB4sLz1dgZz46UXZXydSjRBFF+tdipu3+jfoWcrMt0p4n4Ht/dH+LlwK0 HFjwGbPti2a0QFYcgwHPjsPVr31q0tmOZpzMX1VEKLbRlC9JQCMaBU69YbBLLKbI GHtRoflvk0Pi+aRNboXs/HtPiiKq4Nl6AmqosLDKHFoO71/OyZ8JAhrBUDk+Q1+4 RsnDIuawC7Oa21cwWVCEa9wg2LnI1XSg52bnRiEcGC8OqWbq1KNW3Rag0QkZ3JTM XHpyt79SKy0pKU6h9zOCSepoVBeSLWl3T1mASMd/TdyIp8Z3NkrryhL22HS7g2UY m5uXbD+lgYyyhe4+sYQ1K8SAhWUafYz9FbLXJ7TvliCNR1oKjQ26yj1VXCM2FCXu Nz3YVdaHHwjmsK1nKEiPicmLpeJMVS9Zk1MniWoia+/Ed7vC0VG2qjuECtf4Qk1x p+0VkbQIdYszznNHtxMj90EhkTbl4I2raqB7JAHdLQxZh8YGsEJeKHlikCwMqNBE Ye0JdcwfFx0qZZoDm8iMauPDlsH+vJb4igqDtRFv7pnmJhmRrus= =lnpJ -END PGP SIGNATURE-
Bug#952906: [live-build] inefficiency in FIRMWARE_PACKAGES list construction
Package: live-build Version: 1:20191221 Owner: jnq...@gmail.com Severity: minor the logic used to construct FIRMWARE_PACKAGES suffers from an inefficiency. where multiple archive areas are used, the code on each per-archive- area loop is: 1) fetching the archive area contents file (compressed) 2) **appending** the output of decompressing to a file 3) searching the file for firmware references, adding to the list this means that obviously there will be duplicates in the final list. not that it means anything is broken, but it is flawed in terms of efficiency. patch to be submitted via salsa soon
Bug#952908: [live-build] duplication of firmware list construction code
Package: live-build Version: 1:20191221 Owner: jnq...@gmail.com Severity: minor there are four duplicate blocks of code for constructing a list of firmware packages, which is terrible for maintainability. patch to be submitted via salsa soon
Bug#952907: [live-build] cache pointlessly retained and potentially large (~600MB) file
Package: live-build Version: 1:20191221 Owner: jnq...@gmail.com in handling firmware, archive content files are downloaded and extracted in order to obtain a list of firmware packages. the uncompressed file is saved in the cache. it is not removed from the cache once finished with. this makes sense since the whole point of a cache is to reuse stuff, but the fact is that it never actually gets re-used, the code always deletes any existing file and replaces it with a fresh copy. this might not be so bad if building with more than just the main archive area and main is not the last in the list, since contrib and non-free are much smaller files than main, but otherwise this could be somewhat significant to users. The main file, currently, for amd64, is a little over 600MiB! there are several improvements that could be made, but we can implement a very simple initial fix of simply by deleting this file once we've finished with it. patch to be submitted via salsa soon
Bug#952826: [www.debian.org] partners: convert svg graphics into png to make tidy happy
Hi, Am 01.03.20 um 02:02 schrieb Ricardo: > Hello, > images in svg are the source. Would be better to store in svg format > and convert to png in build time. Are there only external companies > logos in repository, or are there some images that we may change in > the future? If we will not resize the images or change them in other > way, then I think it would be viable to convert and store them to png > format. it's absolutely fine to use SVG graphics in recent days and if ever possible we should use them natively. The world is using more and more HTML5! The Debian websites due mostly heavily lack on a mobile friendly face. To get this working we will need graphics that scale smoothly and please no special hacks within the HTML source to solve various demands. SVG graphics are solving this specific need perfectly. > If choose to convert them, as far as I know, we need to install a > software in the build container and it takes some time. Maybe there is > one container with the required software or the build process is made > in other way. Store only the svg would make thinks more organized and > easy to edit. This turns more into a chicken egg problem in a longer view, or in my eyes, we should solve problems on the ride side or more correctly. Means, we need a strategy how the websites should evolve within the next five years for example. The Debian website is growing every day and by this the load and time to build the whole website is also growing constantly. At one day we need to think about this circumstance. We currently using still DTD HTML 4.01 Strict for the websites and not something more up to date, but this has of course some reason. [snip] > 2020-02-29 19:33 GMT-03:00, Holger Wansing : >> Package: www.debian.org >> >> As tidy constantly complains about >> >> *** /srv/www.debian.org/www/partners/2018/index.en.html >> line 159 column 3 - Warning: attribute "width" has invalid value >> "height=" >> line 255 column 3 - Warning: attribute "width" has invalid value >> "height=" ... >> which is all about width/height information in svg graphics: >> >> what about converting the relevant images (google.svg and >> stackpack-logo-reversed.svg) >> into some other format, like png? This would be a workaround in my eyes instead of solving the root of the problem. How can I run this tidy thing locally so I can try to narrow down the issue? >> Please excuse my ignorance, I have no detailed knowledge on vector >> graphics: >> maybe there is a reason why we should use svg there. >> However, png is widely used in the partners section... I'd like to see we do not convert SVG to PNG here because this is a step back in my eyes, especially as we need to take the advantage of getting all sites mobile ready one day and this shouldn't be done by graphics and logos with some other formats than SVG as this will always result in higher data rates to transfer. -- Regards Carsten Schoenert
Bug#952824: thunderbird: Line length is limited to 54 characters instead of 72
> We have collected some steps you should mind within the Wiki. > > https://wiki.debian.org/Thunderbird#Bug_Reporting_.2F_Issues I disabled all addons and also tried safe mode: Doesn't make a difference. I didn't try to create a fresh profile. And I couldn't find any bugs on the Debian tracker or Bugzilla that looked like this one. > This isn't completely correct from a technical aspect. > Thunderbird is still using the default line wrapping on 72 characters. > This is easy to check if you send an email to yourself. Unfortunately, this is not the case: The sent email has its text wrapped at ~54 characters, when autowrap is enabled. It's not just a presentation issue. When I look at response mails from other people, I can see that the quoted text was hard-wrapped by TB in the wrong places, while the responder's text is fine. > I do workaround around this temporally by adjusting the DPI scaling > using the key combination 'Crtl +' or using the 'Crtl' key and the > scroll wheel on the mouse. That's a... very interesting workaround. Even more interestingly, the text size doesn't even change when I "zoom" using Ctrl-+, only the wrapping. Only at high zoom levels do I get a change in font size. But that could very well be due to minimum font size. Now that I look at it, that's a setting that I did customise a very long time ago. Thunderbird has always had issues with font sizes and Hi-DPI rendering on Linux. My Proportional font size is set to 16, while Monospace is set to 12. Minimum font size is 16. Without this, text would render way too small. I'll see if changing/resetting these makes any difference. >> This was not the case with Firefox 68.4. > > You mean Thunderbird here for sure. Yes of course. My bad. >> As a workaround, it's possible to set mail.wrap_long_lines and >> plain_text.wrap_long_ones to false, but this is undesirable. > > By this you turn off the line wrapping totally, for plain text > (plain_text.x) and HTML (mail.x). Yes... That's why I think it's undesirable. When I combine your zooming suggestion with disabling these two options, wrapping isn't totally messed up any more. But the text still wraps. > The issue you seeing is a upstream problem, it happen too with the > provided upstream binaries from Mozilla so it should get reported on the > bugzilla tracker of Mozilla. Would you take care of this and create a > upstream bug report and provide the URL on this? Yes, I can do that. I wasn't sure if the issue was something in Debian or a general problem. Thanks for the explanation. Do you have any ideas what the root of the problem could be? A bug in in GTK3? Incorrect usage of font metrics APIs?
Bug#952824: thunderbird: Line length is limited to 54 characters instead of 72
>> I do workaround around this temporally by adjusting the DPI scaling >> using the key combination 'Crtl +' or using the 'Crtl' key and the >> scroll wheel on the mouse. > > That's a... very interesting workaround. > Even more interestingly, the text size doesn't even change when I "zoom" > using Ctrl-+, only the wrapping. Only at high zoom levels do I get a > change in font size. But that could very well be due to minimum font size. > > Now that I look at it, that's a setting that I did customise a very long > time ago. Thunderbird has always had issues with font sizes and Hi-DPI > rendering on Linux. My Proportional font size is set to 16, while > Monospace is set to 12. Minimum font size is 16. Without this, text > would render way too small. I'll see if changing/resetting these makes > any difference. Looks like this is the root of the problem: Thunderbird before 68.5 always calculates the wrapping position correctly, no matter which font size is selected. In 68.4, the (minimum) font size influences wrapping. I changed all the font sizes back to 12, and now it wraps correctly at 72 characters, no matter which zoom level is chosen. Zooming in only enlarges the text, as expected. Is there any way to make Thunderbird honour the platform's DPI setting and render all text in a readable size, so I don't have to fiddle with the font sizes any more?
Bug#952835: [live-build] redundant file scripts/build/chroot_live-packages
Package: live-build Version: 1:20191221 Owner: ! the scripts/build/chroot_live-packages file is redundant and needs removing. see the to-be submitted patch for details. patch will follow shortly once I've updated it with the bug number. look out for a salsa merge request...
Bug#952834: [live-build]
Package: live-build Version: 1:20191221 Owner: ! the scripts/build/source_debian-live file is redundant and needs removing. see the to-be submitted patch for details. patch will follow shortly once I've updated it with the bug number. look out for a salsa merge request...
Bug#952673: does not start automatically anymore on fresh installs
severity 952673 serious thanks bumping severity as this breaks all our systems atm. it can be reproduced on a clean install, and then installing knot-resolver, which will not start any kresd instances. a manual "systemctl start kresd@1" after every boot workarounds it. Regards, Daniel
Bug#952912: node-yarnpkg: CVE-2020-8131
Source: node-yarnpkg Version: 1.21.1-1 Severity: important Tags: security upstream Forwarded: https://github.com/yarnpkg/yarn/pull/7831 Hi, The following vulnerability was published for node-yarnpkg. CVE-2020-8131[0]: | Arbitrary filesystem write vulnerability in Yarn before 1.22.0 allows | attackers to write to any path on the filesystem and potentially lead | to arbitrary code execution by forcing the user to install a malicious | package. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2020-8131 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8131 [1] https://github.com/yarnpkg/yarn/pull/7831 [2] https://hackerone.com/reports/730239 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#952920: [live-build] confusing config handling function names
Package: live-build Version: 1:20191221 Owner: jnq...@gmail.com Severity: wishlist the functions Set_defaults() and Check_defaults() are not ideally clear in that they relate to the config. Proposal: renaming to Set_config_defaults() and Check_config_defaults() respectively. patch to be submitted via salsa soon
Bug#951293: marked as pending in procps
On Sat, 29 Feb 2020 at 18:45, Sven Joachim wrote: > > So the version you need to use in procps.maintscript is 2:3.3.16-4~, not > 2:3.3.16-3~. > Thanks! I've fixed this now. - Craig
Bug#925787: netsend: diff for NMU version 0.0~svnr250-1.3
Control: tags 925787 + patch Control: tags 925787 + pending Dear maintainer, I've prepared an NMU for netsend (versioned as 0.0~svnr250-1.3) and uploading it to mentors for sponsorship. Please feel free to tell me if I should remove it from mentors. -- Regards Sudip diff -u netsend-0.0~svnr250/debian/changelog netsend-0.0~svnr250/debian/changelog --- netsend-0.0~svnr250/debian/changelog +++ netsend-0.0~svnr250/debian/changelog @@ -1,3 +1,10 @@ +netsend (0.0~svnr250-1.3) unstable; urgency=medium + + * Non-maintainer upload. + * Fix ftbfs. (Closes: #925787) + + -- Sudip Mukherjee Sun, 01 Mar 2020 20:48:09 + + netsend (0.0~svnr250-1.2) unstable; urgency=low * Non-maintainer upload. only in patch2: unchanged: --- netsend-0.0~svnr250.orig/Makefile +++ netsend-0.0~svnr250/Makefile @@ -44,7 +44,7 @@ @bash configure $(TARGET): $(OBJECTS) - $(CC) $(LIBS) $(CFLAGS) -o $(TARGET) $(OBJECTS) + $(CC) $(CFLAGS) -o $(TARGET) $(OBJECTS) $(LIBS) %.o: %.c analyze.h error.h global.h xfuncs.h Makefile $(CC) $(CFLAGS) -c $< -o $@
Bug#952925: CVE-2018-11751
Source: puppet Severity: important Please see https://puppet.com/security/cve/CVE-2018-11751/ https://tickets.puppetlabs.com/browse/PUP-9459 https://github.com/puppetlabs/puppet/commit/b49c11b6425738441d6f33285d2630fa434a123e Cheers, Moritz
Bug#952927: [live-build] inconsistency and unnecessary complexity in bin checking
Package: live-build Version: 1:20191221 Owner: jnq...@gmail.com Severity: minor there are lots of checks being done that tools are available and executable. this is done with a mixture of use of `which` and fixed paths, redirection of output to /dev/null (`2>/dev/null`) and redundant executability tetsing on top of `which` checks (which already does such a check). this can be tidied up and robustified. - we can move everything to `which` and drop fixed paths, thus robustifying things should a bin every move (you never know). - we can drop performing pointless `-x` testig on top of `which` use, since `which` already performs this and signals such in its exist code (returns 1 if nonexistant or nonexecutable). - we can drop the `2>/dev/null` redirection which in my testing seemed to make no difference. proposal: switch to conditionals of the form: ``` if [ $(which dpkg) ]; then #whatever fi ``` patch to be submitted via salsa soon
Bug#952928: [live-build] tidier deb-src inclusion
Package: live-build Version: 1:20191221 Owner: jnq...@gmail.com Severity: minor the code for building apt sources.list (which also suffers from a duplication issue - #952889) is overly messy due to conditionals placed around every possible inclusion of deb-src entries. it could be a great deal neater if the conditionals were scrapped, the deb-src entries thus always written, and then at the end sed was conditionally used to remove the lines if unwanted. writing data that only has to then be unwritten "rubs against the grain", but these are tiny files, only written a couple of times or so in a build, and the enhanced readability of the code makes this very much worth it. patch to be submitted via salsa soon
Bug#952936: logwatch: proftpd messages not being reported
Package: logwatch Version: 7.5.0-1 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? changed from debian 9 where they the messages were reported * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? I know that there should be some proftpd messages because I did get messages from /var/log/xferlog so there has to be some. I have no anonymous logins to this server. -- System Information: Debian Release: 10.2 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-8-cloud-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages logwatch depends on: ii perl 5.28.1-6 ii sendmail-bin [mail-transport-agent] 8.15.2-14~deb10u1 Versions of packages logwatch recommends: ii libdate-manip-perl 6.76-1 ii libsys-cpu-perl 0.61-2+b4 ii libsys-meminfo-perl 0.99-1+b3 logwatch suggests no packages. -- no debconf information
Bug#952915: [live-build] overly complex In_list function
Package: live-build Version: 1:20191221 Owner: jnq...@gmail.com Severity: minor the In_list function actually supports multiple needles to be searched for at a single time. nothing uses this function to find more than one needle at a time and such functionality is highly questionable in its usefulness. this function is thus needlessly more complex than it needs to be. patch to be submitted via salsa soon
Bug#952918: [live-build] two step lock acquisition
Package: live-build Version: 1:20191221 Owner: jnq...@gmail.com Severity: wishlist lock acquisition in every script is a two step process - check then create. it is unnecessary to be split like this in scripts, it creates opportunity for mistakes such as of of these steps to be lost or done in the wrong order for instance. it would be ideal to have a wrapper that makes these two calls which can be used instead. patch to be submitted via salsa soon
Bug#952913: biglybt: Side Bar rapidly flickers on mouse hoover
Le 01/03/2020 à 20:26, e...@i2pmail.org a écrit : > When moving mouse pointer over the Side Bar in BiglyBT it rapidly flickers, > with the content of the sidebar rapidly appearing and disappearing. Thank you for the feedback. I haven't experienced this issue yet. What JRE and desktop environment did you use? Emmanuel Bourg
Bug#952923: [live-build] caching override not overriding
Package: live-build Version: 1:20191221 Owner: jnq...@gmail.com there are four caching rated controls --cache, --cache-indices, -- cache-packages and --cache-stages. The first has a description of "defines globally if any cache should be used at all. Different caches can be controlled through the their own options.". It is somewhat ambiguous, but should --cache, if specified, not overrule the others. if so, then there is no such enforcement of this. patch to be submitted via salsa soon
Bug#952785: buster-pu: package dojo/1.15.0+dfsg1-1+deb10u1
> +#CVE-2019-10785.patch The patch is commented in the series file and thus does not get applied. Andreas
Bug#952937: ability to analyze diffs rather than full source
Package: decopy Severity: wishlist It would be great if decopy had a way to analyze diffs and to report on any changes that need to be made to the debian/copyright file based on that. This would be useful when e.g. importing new upstream releases, making that sure that the debian/copyright file stays up to date. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-2-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages decopy depends on: ii bzip2 1.0.8-2 pn libimage-exiftool-perl ii python3 3.7.5-3 ii python3-debian 0.1.36 ii python3-xdg 0.26-1 ii xz-utils5.2.4-1+b1 Versions of packages decopy recommends: pn python3-regex pn python3-tqdm decopy suggests no packages.
Bug#944769: python3-h5py fails to import if offline due to apparent MPI failure
Source: h5py Followup-For: Bug #944769 Hi Thibaut, your h5py suggestion of if MPI_ACTIVE: from h5py_mpi import * else: from h5py_serial import * works up to a point. But it's not a full and simple solution because of the way Python handles submodules. Some of the internal files, like h5t.pyx or _hl/files.py, want to import functions, as in from .h5py_warnings import H5pyDeprecationWarning Conceivably client programs may also want to import classes this way. But Python can only import using the direct module name. Here we're aliasing h5py_mpi or h5py_serial as h5py. So we get ModuleNotFoundError, e.g. (testing the serial build) $ cd .pybuild/cpython3_3.7_h5py-serial/build $ PYTHONPATH=`pwd` python3 Python 3.7.6 (default, Jan 19 2020, 22:34:52) [GCC 9.2.1 20200117] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import h5py >>> h5py.h5py_warnings >>> h5py.h5py_warnings.H5pyDeprecationWarning >>> from h5py.h5py_warnings import H5pyDeprecationWarning Traceback (most recent call last): File "", line 1, in ModuleNotFoundError: No module named 'h5py.h5py_warnings' >>> import h5py_serial >>> from h5py_serial.h5py_warnings import H5pyDeprecationWarning >>> So the submodule h5py.h5py_warnings is accessible, and the class H5pyDeprecationWarning inside it is accessible. But that class cannot be imported independently on its own via the h5py namespace (since the actual module is h5py_serial. It imports cleanly via h5py_serial) A client program could work around around it by using H5pyDeprecationWarning = h5py.h5py_warnings.H5pyDeprecationWarning instead of from h5py.h5py_warnings import H5pyDeprecationWarning But the module is not supposed to have that limitation so almost certainly some code will break. And we shouldn't break code this way. This is a known problem with Python submodules, e.g. https://stackoverflow.com/questions/40823418/why-cant-i-import-from-a-module-alias https://stackoverflow.com/questions/12229580/python-importing-a-sub-package-or-sub-module https://stackoverflow.com/questions/24302754/python-submodule-imports-using-init-py (there are also some weak private members that should probably be accessible, namely _objects, _hl, also _conv, _errors, _proxy. These could be added manually but nice to automate the import ) Can you think of a clean solution that allows members like H5pyDeprecationWarning to get imported?
Bug#952909: [live-build] duplicate work in firmware list construction
Package: live-build Version: 1:20191221 Owner: jnq...@gmail.com Severity: minor firmware list construction can involve duplicate work for derivative builds, as noted in a long term fixme. parent and derived have separate archive area lists; if the distribution of parent and derived be the same, then any archive area that exists in both lists would result in duplicated work. patch to be submitted via salsa soon
Bug#951142: mwic: Please package new upstream version (0.7.8)
Hi, On 20-02-11 16:31:16, Georg Faerber wrote: > I'll handle this within the next days, up until end of February. Took up until today, but did some work now. It seems that I've lost access to the repository, and sent a mail to have this corrected. Will finish this and upload as soon as I regain access. Cheers, Georg
Bug#952910: [live-build] save compressed contents file to disk
Package: live-build Version: 1:20191221 Owner: jnq...@gmail.com Severity: wishlist as pointed out in #952907, the archive contents file is not cached in an efficient way. #952907 concerns itself with fixing the small aspect of not pointlessly leaving the file hanging around once it has been finished with since caching is not actually being exploited. here we concern ourselves with taking things further in another respect - instead of storing the decompressed file in the cache, let's tweak things such that it is the compressed file that is saved to disk. note that as discussed before, the file for the 'main' archive area is by far the largest, and is over 600MiB currently for amd64 whilst the compressed file is ~30MiB. we currently download the compressed file, piping it into gunzip and saving the decompressed inner file to disk, parse the file, then delete it (per #952907 the last used hangs around pointlessly which that proposes fixing). we could instead save the compressed file to disk, then pipe the decompression of that (it only holds one file) through awk to get the list. this would mean much less disk IO. it also means that if/when we do change things to properly take advantage of caching then we require much less disk space to do so. patch to be submitted via salsa soon
Bug#952911: [live-build] make use of cache for firmware list determination
Package: live-build Version: 1:20191221 Owner: jnq...@gmail.com Severity: minor as mentioned in #952907 and #952910, the content archives files used in determining a list of firmware packages available are always downloaded afresh, deleting any existing file that had been saved to the cache. this is inefficient, even just within a single build (the same file might be processed up to four times - chroot_firmware and installer_debian-installer, and twice each in each if done for both parent and derived without the #952909 fix). then we must consider multiple runs, especially important when developing LB. it takes time to download these files. it also has implications wrt. offline building, should anyone be interested in that. consideration should be given to actually making use of cached files. patch implementing use of cached files to be submitted via salsa soon
Bug#952251: sympy: FTBFS: make[2]: python: Command not found
On Sun, 23 Feb 2020 14:21:28 +0100 Lucas Nussbaum wrote: > Source: sympy > Version: 1.5.1-2 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20200222 ftbfs-bullseye > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. NMU debdiff attached. Since this is an RC bug over 7 days old with no maintainer response, I intend to upload to the archive and not to delayed. Scott K diff -Nru sympy-1.5.1/debian/changelog sympy-1.5.1/debian/changelog --- sympy-1.5.1/debian/changelog 2020-02-07 12:57:44.0 -0500 +++ sympy-1.5.1/debian/changelog 2020-03-01 15:45:01.0 -0500 @@ -1,3 +1,11 @@ +sympy (1.5.1-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * Add d/p/python3-not-python.patch from Ubuntu to fix FTBFS with python3 +(Closes: #952251) + + -- Scott Kitterman Sun, 01 Mar 2020 15:45:01 -0500 + sympy (1.5.1-2) unstable; urgency=medium * pulled changes coming from the previous team upload diff -Nru sympy-1.5.1/debian/patches/python3-not-python.patch sympy-1.5.1/debian/patches/python3-not-python.patch --- sympy-1.5.1/debian/patches/python3-not-python.patch 1969-12-31 19:00:00.0 -0500 +++ sympy-1.5.1/debian/patches/python3-not-python.patch 2020-03-01 15:44:40.0 -0500 @@ -0,0 +1,17 @@ +Author: Steve Langasek +Description: invoke python3 for building, not the deprecated python. +Last-Update: 2020-02-28 +Bug-Debian: https://bugs.debian.org/952251 + +Index: sympy-1.5.1/doc/Makefile +=== +--- sympy-1.5.1.orig/doc/Makefile sympy-1.5.1/doc/Makefile +@@ -1,6 +1,6 @@ + # Makefile for Sphinx documentation + # +-PYTHON = python ++PYTHON = python3 + RST2HTML = rst2html + + # You can set these variables from the command line. diff -Nru sympy-1.5.1/debian/patches/series sympy-1.5.1/debian/patches/series --- sympy-1.5.1/debian/patches/series 2020-02-07 12:53:35.0 -0500 +++ sympy-1.5.1/debian/patches/series 2020-03-01 15:44:40.0 -0500 @@ -3,3 +3,4 @@ 03_sphinx_conf.patch 04_doc_makefile.patch 05_sphinx_math_dollar.patch +python3-not-python.patch signature.asc Description: This is a digitally signed message part.
Bug#952919: [live-build] messy script init
Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: wishlist
some of the steps performed in the initialisation steps of scripts are
messy and suffer from code duplication issues (e.g. the list of config
files to read).
it would is trivial to address this will a little effort.
low-level build components all:
- run `Arguments "${@}"`
- read the set of config files
- run Set_defaults()
this could be consolidated into a hypothetical `Init_config_data
"${@}"` call.
the major build stages all:
- check for the existence of a config and conditionally call `lb
config`
- run `Arguments "${@}"`
- read the set of config files
- run Set_defaults()
- run Setup_cleanup()
this could be consolidated into a hypothetical `Init_build_stage
"${@}"` call.
the primary commands (`lb config`, `lb build` and `lb clean`) could
make use of some of the same component helpers that those hypothetical
functions might use, e.g. to get the set of config files from a single
declaration.
patches to be submitted via salsa soon
Bug#952930: [live-build] inst: use bool rather than int
Package: live-build Version: 1:20191221 Owner: jnq...@gmail.com Severity: wishlist the DOWNLOAD_GTK_INSTALLER variable in installer_debian-installer is an integer with two states, 0 or 1. This would be better as a boolean. patch to be submitted via salsa soon
Bug#952932: [live-build] download version specific sources
Package: live-build Version: 1:20191221 Owner: jnq...@gmail.com Severity: minor source packages are downloaded by name only. surely it would be best if we added version specific qualifiers to thus target specifically copies of the packages that actually definitely correspond to the versions used/installed? patch to be submitted via salsa soon
Bug#952931: [live-build] download src pkgs to clean dir
Package: live-build Version: 1:20191221 Owner: jnq...@gmail.com Severity: wishlist the source stage downloads src packages into the root of the chroot. it would surely be better to download them into the clean directory created to hold them. patch to be submitted via salsa soon
Bug#952935: CVE-2019-14575
Source: edk2 Severity: important Tags: security This was assigned CVE-2019-14575: https://bugzilla.tianocore.org/show_bug.cgi?id=1608 Cheers, Moritz
Bug#952934: CVE-2019-14563
Source: edk2 Severity: important Tags: security This was assigned CVE-2019-14563: https://bugzilla.tianocore.org/show_bug.cgi?id=2001 Patch: https://github.com/tianocore/edk2/commit/322ac05f8bbc1bce066af1dabd1b70ccdbe28891 Cheers, Moritz
Bug#952009: c-icap-modules: FTBFS: clamav_mod.c:108:13: error: expected identifier or ‘(’ before string constant
found 952009 1:0.5.3-1 thanks Also in buster.
Bug#952009: c-icap-modules: FTBFS: clamav_mod.c:108:13: error: expected identifier or ‘(’ before string constant
found 952009 1:0.4.4-1+deb9u1 thanks This is also happening in stretch.
Bug#952755: adminer: missing configuration files in stable
Hi, > adminer from stable is missing configuration (and docs) files. I just > installed the version from the backports repository and now I have: > - a README.Debian file that helps in the setup > - a con file in /etc/adminer > - a file in /etc/apache2/conf-available > - a working adminer install > I guess this package needs a fix to be useful in debian stable. >From what I understand, stable update are only[1] for severity important bugs or higher severity : "a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone." I'm not sure this bug is important, but if lamby in cc tells me it has a chance of being accepted, I'll prepare an upload. Thanks for your interest in the package, Alex [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.fr.html#special-case-uploads-to-the-stable-and-oldstable-distributions
Bug#952913: biglybt: Side Bar rapidly flickers on mouse hoover
Package: biglybt Version: 2.2.0.2-2 When moving mouse pointer over the Side Bar in BiglyBT it rapidly flickers, with the content of the sidebar rapidly appearing and disappearing. It also occurs when changing focus of the window (e.g. changing focus between BiglyBT window and some other program). Flickering is not only a visual annoyance, but also heavily increases CPU usage during the flicker. I haven't experienced the flickering with upstream version of BiglyBT, but I ran the upstream version on Debian stable. A sort of workaround is hiding the sidebar: `View > Side Bar`
Bug#952914: [live-build] udeb handling issues
Package: live-build Version: 1:20191221 Owner: jnq...@gmail.com there are notable issues with the way udebs are handled in the installer code: - in rare but possible scenarios it could be possible for both a parent and derived copy of a package to end up included, due to the lazy way things are handled. - the bundling of parent and derived sets are simply bundled together in a single list and then an attempt is made to download from the derived mirror, falling back to the parent on failure, which leads to a lot of 404 errors, as pointed out by an log message that gets printed out to advise users to not worry about them. it is not hard and is desirable for the necessary robustness to be implemented here such that any packages that are being obtained from the derived source are excluded from being obtained from the parent; so that these two lists are kept separate and udebs in each lists obtained from the actual correct location; and that files only be taken from the cache when they really are supposed to be. patches to be submitted via salsa soon
Bug#952917: [live-build] less than ideal STAGE tests
Package: live-build Version: 1:20191221 Owner: jnq...@gmail.com Severity: minor in a few places a loop is performed over LB_CACHE_STAGES, performing an action if a matching stage is in the list. this code can be significantly improved with use of In_list(). patch to be submitted via salsa soon
Bug#952916: [live-build] confusing package cache save/restore
Package: live-build Version: 1:20191221 Owner: jnq...@gmail.com Severity: wishlist the Restore_cache() and Save_cache() functions are misleading in their names; they are specifically for handling **packages** kept in the cache. they could do with renaming to help understandability of the code. furthermore their use is overly verbose. **every** use is with a param of the form "cache/packages.binary" or "cache/packages.chroot". there is obviously a common prefix here which could be eliminated. patch(es) to be submitted via salsa soon
Bug#952921: [live-build] explanatory file needed in source image
Package: live-build Version: 1:20191221 Owner: jnq...@gmail.com Severity: minor a copy of the build config is stored in the source image. it might be a good idea to have a readme file to accompany this to explain WTH that set of files and folders is to anyone browsing the disk/image contents. patch to be submitted via salsa soon
Bug#952922: groff: bad ghostscript version in the font path
Package: groff
Version: 1.22.4-3
Severity: normal
Dear Maintainer,
I tried to use groff/eqn to render an equation. it happens to render
poorly as described here:
https://lists.gnu.org/archive/html/groff/2020-02/msg00048.html
as the community helped me to fix the problem, someone spotted
this command doesn't work
troff -Tpdf <<<'\(ra' | gropdf -e | pdffonts -
until you work around with
sudo ln -s /usr/share/ghostscript/9.2{7,6}
the whole message is here
https://lists.gnu.org/archive/html/groff/2020-02/msg00071.html
then Colin pops up, gave us more context and asked me to fil this bug:
https://lists.gnu.org/archive/html/groff/2020-03/msg0.html
thanks for your work
marc
Bug#952924: [live-build] inefficient mkdir/rmdir use in chroot_hooks
Package: live-build Version: 1:20191221 Owner: jnq...@gmail.com Severity: minor per title, mkdir/rmdir use in copying hooks is inefficient patch to be submitted via salsa soon
Bug#952926: CVE-2019-14559
Source: edk2 Severity: normal Tags: security This was assigned CVE-2019-14559: https://bugzilla.tianocore.org/show_bug.cgi?id=2031 Cheers, Moritz
Bug#952929: [live-build] disable rather than remove deb-src entries
Package: live-build Version: 1:20191221 Owner: jnq...@gmail.com Severity: wishlist when generating apt sources.list files, deb-src files are either included or they are not. alternatively what if they were always included but commented out when not wanted? the benefit is that should the user ever want src packages, all they would have to do is uncomment the relevant line(s) rather than add them. is that not better? patch to be submitted via salsa soon
Bug#952933: [live-build] local var scope in functions
Package: live-build Version: 1:20191221 Owner: jnq...@gmail.com Severity: wishlist there are many variables that are local to functions for which `local` should be used. patch to be submitted via salsa soon
Bug#915386: Request to Join Debian Multimedia Team
Hi Garie, On Thu, 27 Feb 2020 11:16:20 -0600 "GMiller" wrote: > Hello: > > I hereby request permission to try to package fdk-aac 2.0.1. This > package also includes libfdk-aac-dev, which currently references > Bug#915386. > > My motivation for joining the Multimedia Team is solely the completion > of another Debian Bug#907576. I do not foresee much involvement with > the Multimedia Team beyond maintaining fdk-aac. 907576 requires the > newer libfdk-aac-dev 2.0.0, and thus my request to join you. > > My prior experience in Debian is limited to working on Bug#907576 for > another team. Note that I am not an official Debian Maintainer on any > Team. > > As instructed by your 'How to Join' page, I have created a Salsa > account and subscribed to the Multimedia mailing list. I have > previously filed a few Debian bugs. As for reviewing others work, I do > not believe I am qualified. > > I have previously read most of the Debian packaging procedures while > working on Bug907576. I am currently digesting the contents of the > Multimedia Teams 'DevelopPackaging' page. > > I will be clicking on the Team's 'Request to Join' page sometime after > I send this email. I have granted a "Maintainer" role to your Salsa account. Note that you may or may not do the work base on the Salsa git repo at https://salsa.debian.org/multimedia-team/fdk-aac . Please be aware that package fdk-aac is not a free software as determined by Debian and was put under non-free section, which means any software depending on it will have to be put either in contrib section or in non-free too. When you are working on the git packaging repository, please follow the suggestion at https://dep-team.pages.debian.net/deps/dep14 as well as the Multimedia team's guideline as documented at https://wiki.debian.org/DebianMultimedia/DevelopPackaging . When you have reached a milestone in packaging the new version, please have your work outcome uploaded onto mentors.debian.net for review and have other Debian Developers review your work. If you prefer not to use mentors.debian.net, you may also have the work ready in the git packaging repository on Salsa. If you have any immature work stored in Git repo, you may also put the work under your own namespace (at https://salsa.debian.org/GMiller-guest/) . -- Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#946420: kpat is spamming with error messages
On Tue, 31 Dec 2019 15:23:00 +0100 =?UTF-8?Q?Bernhard_=c3=9cbelacker?= wrote: >[…] > I tried to reproduce inside a minimal plasma testing VM. > But I could not see a noticeable amount of messages in > .xsession_errors while playing kpat. It depends on the game you play. Freecell is silent. Spider is the worst. > If this is still visible on your system then > some more information could help. > - Which game have you played inside kpat? > - Some example lines of the messages in .xsession_errors See bug 941858. -- Sylvain L. Sauvage
Bug#952041: ruby-hoe: FTBFS: ERROR: Test "ruby2.7" failed.
Package: src:ruby-hoe Followup-For: Bug #952041 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I cannot reproduce this issue. The two dates shown are (probably) the date of the build (expected) and the date in hoe.gemspec of unstable's ruby-hoe 3.21.0+dfsg1 (got). When I run it locally the dates are both the one from the build. So the question probably is: how did the date in unstable's how.gemspec sneak into the ruby 2.7 build and why? Regards, Daniel - -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl5cX4kACgkQS80FZ8KW 0F0WmA//T+Bpcrg3v8NwclSRXlWGdxzy6Hrpa6YxaEQcfzACeOk3ltJr+gWIk2ga WFBrL5HnAN8kTY/tsjdaJI+Eeio+u1TU3CSNluYIc2oYK8hHanA7RNqpz68eW9nF OpDbQoan6y956rhaYeomVOoTF9Pz7yc2FL4YGcOaFGSyuMJdOd7ExWoMDdkF3TUl OHnTpQHFcNhLWLfn3OZpE/EZcC4tHg7jVHbjugtMMk2PAo6ha7IwFcdHI8LPFDRF XFbzFV/ljZV+qMZ4w7JY1U12J4jKMY4qoKt3oQ+qvu1+7tn/16PtPZTjNlgdjQn8 C1oE4y31vEU1NEHS484EWAaf3bQIEwCqkYroBgoz4+GyfYnQw91ugl+1fhkP35ka N7YvNhEmRnGTHqtVMlF0XJb8Rnb62Yihwsto8pE7MDXE/OdX1798RXTN6c7Japyu QUHEvYrpxuiKGhUYZDdXzxVEMGucIE6c+MwujuT00QenK5bqr5M64SqJgxq9cSQF QyKonYob4vT8DPdIjZ/0jHA2IHs8dAuJj25BebrrGxZw6ZTtnwF1pKk7MzwrRQfG 0VdRJNthhXsqQP705Kopto1tNN+mgpy64Y4fSi65pMCtAdcpHfNhOVwN9YLI/Vc4 8gOpc/0hRh1P8HHZEZhEQBcQfrlTka5uHdzcLCFv2D91OQrJ+ok= =eSIh -END PGP SIGNATURE-
Bug#952666: typo in dla-2123
Hello Not sure quite where to direct this. This recent DLA https://www.debian.org/lts/security/2020/dla-2123 references the wrong debian bug, 925666. The correct number is 952666. Kind regards Vince
Bug#935455: Updated version of dask
Hi, I updated the version of dask to 2.11.0 does that help with this bug? Diane
Bug#952755: adminer: missing configuration files in stable
Hi Alexandre, > From what I understand, stable update are only[1] for severity > important bugs or higher severity : "a bug which has a major effect on > the usability of a package, without rendering it completely unusable > to everyone." This summary is accurate & would agree that it might be difficult to persuade the Stable Release Managers to include this change. In light of that, did you consider preparing an upload to backports instead? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#952939: nm.debian.org: some templates in process/templates/ use blocktrans with variables that get ignored
Package: nm.debian.org
Severity: minor
Tags: patch
Text for approved requirements is incomplete:
It shows "This requirement has been approved by ago.",
when it should eg. show
"This requirement has been approved by Housekeeping Robot
7 months, 2 weeks ago."
Added a patch for using '{% blocktrans with variable_name=something %}' syntax
for requirement_status_widget.html and for a few other templates from process/
templates/process/
>From 34caf407ea85b6042490c761e191a5d045f261cb Mon Sep 17 00:00:00 2001
From: Judit Foglszinger
Date: Mon, 2 Mar 2020 08:01:14 +0600
Subject: [PATCH] use 'with' in blocktrans for variable substitution
---
process/templates/process/cancel.html | 11 ++-
.../templates/process/requirement_status_widget.html | 6 +++---
process/templates/process/show.html | 1 +
process/templates/process/statement_create.html | 2 +-
4 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/process/templates/process/cancel.html b/process/templates/process/cancel.html
index 755843d..8ef2d9a 100644
--- a/process/templates/process/cancel.html
+++ b/process/templates/process/cancel.html
@@ -1,4 +1,5 @@
{% extends "process/nm2-base.html" %}
+{% load nm %}
{% load i18n %}
{% block content %}
@@ -14,12 +15,12 @@ system. Follow the link for instructions.{% endblocktrans %}
{% else %}
{% if process.applying_for == "dd_e" %}
- {% blocktrans %}On {{process.started|date:"F d, Y"}} the
+ {% blocktrans with started_on=process.started|date:"F d, Y" person_ldap_uid=process.person.ldap_fields.uid %}On {{started_on}} the
https://wiki.debian.org/qa.debian.org/MIATeam;>Missing In Action
-team sent a "Where Are Thou?" ping message to {{process.person.ldap_fields.uid}}
+team sent a "Where Are Thou?" ping message to {{person_ldap_uid}}
communicating the intention of closing the account after some time.{% endblocktrans %}
- {% blocktrans %}If you are {{process.person.fullname}} and consider
+ {% blocktrans with person_fullname=person.fullname %}If you are {{person_fullname}} and consider
yourself still active, you can use this page to let the MIA team know.{% endblocktrans %}
{% if not process.person.fpr %}
@@ -34,8 +35,8 @@ in the Debian keyring.{% endblocktrans %}
what you do or are going to do in Debian. The text will only be visible to
Front Desk / MIA team unless you tick the box to make it public.{% endblocktrans %}
{% else %}
- {% blocktrans %}By submitting this form you can cancel the process for
-becoming {{ process.applying_for|desc_status }} started on {{process.started|date:'F d, Y'}}.{% endblocktrans %}
+ {% blocktrans with applying_for=process.applying_for|desc_status started_on=process.started|date:'F d, Y' %}By submitting this form you can cancel the process for
+becoming {{ applying_for }} started on {{started_on}}.{% endblocktrans %}
{% endif %}
diff --git a/process/templates/process/requirement_status_widget.html b/process/templates/process/requirement_status_widget.html
index acc8dde..9469195 100644
--- a/process/templates/process/requirement_status_widget.html
+++ b/process/templates/process/requirement_status_widget.html
@@ -1,9 +1,9 @@
{% load i18n %}
{% if requirement.approved_by %}
- {% blocktrans %}This requirement has been approved by
-{{requirement.approved_by}}
-{{requirement.approved_time|timesince}} ago.{% endblocktrans %}
+ {% blocktrans with req_approved_by_absolute_url=requirement.approved_by.get_absolute_url req_approved_by=requirement.approved_by requirement_approved_time=requirement.approved_time|timesince%}This
+requirement has been approved by {{req_approved_by}}
+{{requirement_approved_time}} ago.{% endblocktrans %}
{% else %}
{% if status.satisfied %}
{% trans "This requirement looks ready for approval, but has not been approved yet." %}
diff --git a/process/templates/process/show.html b/process/templates/process/show.html
index 27835ef..042faa0 100644
--- a/process/templates/process/show.html
+++ b/process/templates/process/show.html
@@ -187,6 +187,7 @@ but not frozen for review.{% endblocktrans %}
{% comment %} TODO: Requires porting stats backend to new Process
+ NOTE: blocktrans needs to be adjusted to use syntax {% blocktrans with name=something%} {{name}}...
{% if mbox_stats %}
{% trans "Mailbox stats" %}
{% blocktrans %}{{mbox_stats.date_first_py|date:"Y-m-d"}} to {{mbox_stats.date_last_py|date:"Y-m-d"}},
diff --git a/process/templates/process/statement_create.html b/process/templates/process/statement_create.html
index a7ad20d..175db73 100644
--- a/process/templates/process/statement_create.html
+++ b/process/templates/process/statement_create.html
@@ -28,7 +28,7 @@ a need of manual validation of its content:{% endblocktrans %}
{% endif %}
-{% blocktrans %}Use gpg --clearsign --default-key {{visitor.fpr}}
+{% blocktrans with visitor_fpr=visitor.fpr%}Use gpg --clearsign --default-key {{visitor_fpr}}
to generate the signed statement.
Bug#952938: gnome-tweaks: Categories, titlebar misbehaviors with windows titlebar buttons on left
Package: gnome-tweaks Version: 3.34.0-2 Severity: normal Tags: upstream With windows titlebar buttons (Close, minimize, maximize) configured on left, e.g. via gnome-tweaks itself, gnome-tweaks starts up with the following misbehaviors: - The titlebar is frequently invisible. Depending on theme, it may show up as completely black (e.g. with materia-compact) or completely transparent. - The categories are not shown on the left. Instead, the entire window is dedicated to the "Generic" pane, with "Animations", "Suspend when laptop lid is closed", and "Over-Amplification" as the only controls shown. See attached screenshot for reference. Presumably this is because the extra buttons on the left side of the titlebar seems to expand the width of the category pane, so that with the initial/default window size there is not enough room for it plus the pane on the right. In either case, resizing the window (i.e. expanding it horizontally) restores normal behavior. -- System Information: Debian Release: bullseye/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-tweaks depends on: ii gir1.2-glib-2.01.62.0-5 ii gir1.2-gnomedesktop-3.03.34.2-2 ii gir1.2-gtk-3.0 3.24.13-1 ii gir1.2-handy-0.0 0.0.12-1 ii gir1.2-notify-0.7 0.7.9-1 ii gir1.2-pango-1.0 1.42.4-8 ii gir1.2-soup-2.42.68.2-1 ii gnome-settings-daemon 3.34.2-1 ii gnome-shell-common 3.34.4-1 ii gsettings-desktop-schemas 3.34.0-2 ii mutter-common 3.34.4-1 ii python33.7.5-3 ii python3-gi 3.34.0-6 gnome-tweaks recommends no packages. gnome-tweaks suggests no packages.
Bug#952188: golang-github-mendersoftware-scopestack: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 4 github.com/mendersoftware/scopestack returned exit code 1
Hello,
On Sun, Feb 23, 2020 at 02:08:07PM +0100, Lucas Nussbaum wrote:
> Source: golang-github-mendersoftware-scopestack
> Version: 0.0~git20180403.c2f5599-2
[...]
> > === RUN TestPushPopNotInSameFunction
> > --- FAIL: TestPushPopNotInSameFunction (0.00s)
> > scope_stack_test.go:57: Should never get here
> > scope_stack_test.go:52: Pop() should have panicked when used in a
> > different function than Push()
> > === RUN TestDifferentScopeDistance
> > --- FAIL: TestDifferentScopeDistance (0.00s)
> > scope_stack_test.go:95: Should never get here
> > scope_stack_test.go:89: Should have panicked because scope stack
> > distance should point to this function
[...]
I assume the problem is caused by newer golang. It appears that atleast
nowadays (with go1.13.8) an inlined (anonymous) function will have
the same Func(tion) Entry(point) as the parent function it was inlined
into, eg. as used in the TestPushPopNotInSameFunction testcase.
The two Func(tions) however will have different Name()s, so simply
adding those to the Entry() comparisons will make the test-suite pass
again. See attached patch.
I'm not quite sure if this is the most robust fix, so would be great to
have some feedback from upstream (hopefully via Lluis in CC).
Some semi-relevant discussion is available at:
https://github.com/golang/go/issues/29582
... where it's discussed that rather than runtime.Caller and FuncForPC
it's better to use runtime.Callers and runtime.CallersFrames which is
supposed to deal properly with inlining, whatever that means.
Regards,
Andreas Henriksson
>From fd8f4d2fcd0ee6e541d7e7dd3e66a94b570a93ad Mon Sep 17 00:00:00 2001
From: Andreas Henriksson
Date: Mon, 2 Mar 2020 02:21:35 +0100
Subject: [PATCH] Also compare function names to catch inlined funcs
Inlined Func will have the same Entry value as the parent
Func it was inlined into. It will however have a different
Name(), so compare that as well.
---
scope_stack.go | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/scope_stack.go b/scope_stack.go
index bf68c81..f900752 100644
--- a/scope_stack.go
+++ b/scope_stack.go
@@ -17,6 +17,7 @@ package scopestack
import "fmt"
import "container/list"
import "runtime"
+import "strings"
// A stack type that tries to verify that each push and pop happens in the same
// function.
@@ -82,7 +83,7 @@ func (self *ScopeStack) Pop() interface{} {
oldFunc := runtime.FuncForPC(*oldFrame)
newFunc := runtime.FuncForPC(newFrame)
- if oldFunc.Entry() != newFunc.Entry() {
+ if oldFunc.Entry() != newFunc.Entry() || strings.Compare(oldFunc.Name(), newFunc.Name()) != 0 {
oldFile, oldLine := oldFunc.FileLine(*oldFrame)
newFile, newLine := newFunc.FileLine(newFrame)
msg := fmt.Sprintf("Unbalanced ScopeStack.Pop(). "+
--
2.20.1
Bug#890833: at-spi2-core: Intermittent 90s shutdown delay: at-spi-dbus-bus.service: State 'stop-sigterm' timed out
Hello, We have some new on this 90s-delay computer shutdown: upstream has committed something which might be fixing it. I have uploaded at-spi2-core version 2.34.0-4 which includes it. Could people who are regularly having the issue test this version? If it does fix it, I'll probably propose uploading the fix to buster. Samuel Maciej, le lun. 19 févr. 2018 17:18:07 +0100, a ecrit: > I shut the system down by clicking the "off switch" button in Gnome > DE and then clicking the "Shut down" or "Restart" button. In about 50% of > cases > the shutdown process takes 90 seconds longer than in the other 50%. Sergey Antonov, le lun. 26 févr. 2018 04:51:43 +0300, a ecrit: > Hi. I have same problem with AT SPI... > > lut 06 14:30:47 B2-46-AA-2018 systemd[612]: at-spi-dbus-bus.service: State > 'stop-sigterm' timed out. Killing. > lut 06 14:30:47 B2-46-AA-2018 systemd[613]: pam_unix(systemd-user:session): > session closed for user Debian-gdm > lut 06 14:30:47 B2-46-AA-2018 systemd[612]: at-spi-dbus-bus.service: Killing > process 648 (at-spi-bus-laun) with signal SIGKILL. Simon McVittie, le lun. 26 févr. 2018 08:19:55 +, a ecrit: > On Mon, 26 Feb 2018 at 04:51:43 +0300, Sergey Antonov wrote: > > Hi. I have same problem with AT SPI... > > > > lut 06 14:30:47 B2-46-AA-2018 systemd[612]: at-spi-dbus-bus.service: State > > 'stop-sigterm' timed out. Killing. > > lut 06 14:30:47 B2-46-AA-2018 systemd[613]: pam_unix(systemd-user:session): > > session closed for user Debian-gdm > > lut 06 14:30:47 B2-46-AA-2018 systemd[612]: at-spi-dbus-bus.service: > > Killing process 648 (at-spi-bus-laun) with signal SIGKILL. > > The per-user instance of systemd sends SIGTERM to at-spi-dbus-bus.service > (at-spi-bus-launcher). If the processes in that service still haven't > exited 90 seconds later, systemd logs this message and follows up > with SIGKILL. That means at-spi-bus-launcher isn't exiting promptly, > which seems like a bug in at-spi-bus-launcher.
Bug#937302: playonlinux: Python2 removal in sid/bullseye
On Sat, 29 Feb 2020, Bertrand Marc wrote: On Thu, 30 Jan 2020, Scott Talbert wrote: What is the games team plan for Python 3 support in playonlinux? Do you plan to port it to Python 3? Or remove? I don't plan to port playonlinux to Python 3. However, a new version of playonlinux is currently developped under Java [1]. There is no release date for now, but I will package it when a stable version is available. Best, Bertrand [1] https://github.com/PhoenicisOrg/phoenicis Should we then RM playonlinux from Debian? Scott
Bug#952666: typo in dla-2123
On Mon, Mar 02, 2020 at 01:24:38AM +, McIntyre, Vincent (CASS, Marsfield) wrote: > Hello > > Not sure quite where to direct this. > > This recent DLA > https://www.debian.org/lts/security/2020/dla-2123 > > references the wrong debian bug, 925666. > The correct number is 952666. > Hi Vince, Thanks for catching that. I have just submitted a merge request to have that updated on the site. Regards, -Roberto -- Roberto C. Sánchez
Bug#952941: xwayland: Segmentation fault in OsLookupColor when waking up on Xwayand 1.20.7-4
Package: xwayland
Version: 2:1.20.7-4
Severity: important
Dear Maintainer,
I am running Xwayland (as part of a Wayland/swaywm setup). Whenever the machine
goes to sleep and I wake it up, I find all X11 apps dead. The logs indicate
that Xwayland is segfaulting.
This issue is present in the default Buster version of Xwayland; I also pulled
in the Sid version in hopes that the issue might've been patched already (I
found a few issues in this tracker relating to OsLookupColor, with fixes in
1.20.7-4).
I've attached the logs below. Please let me know if there's any other
information I can provide, and I would be happy to do so. These logs are from
1.20.7-4.
Mar 01 21:35:03 lynwood /usr/lib/gdm3/gdm-wayland-session[1606]: ***
BUG ***
Mar 01 21:35:03 lynwood /usr/lib/gdm3/gdm-wayland-session[1606]: In
pixman_region32_union_rect: Invalid rectangle passed
Mar 01 21:35:03 lynwood /usr/lib/gdm3/gdm-wayland-session[1606]: Set a
breakpoint on '_pixman_log_error' to debug
Mar 01 21:35:03 lynwood /usr/lib/gdm3/gdm-wayland-session[1606]: ***
BUG ***
Mar 01 21:35:03 lynwood /usr/lib/gdm3/gdm-wayland-session[1606]: In
pixman_region32_union_rect: Invalid rectangle passed
Mar 01 21:35:03 lynwood /usr/lib/gdm3/gdm-wayland-session[1606]: Set a
breakpoint on '_pixman_log_error' to debug
Mar 01 21:35:03 lynwood /usr/lib/gdm3/gdm-wayland-session[1606]: ***
BUG ***
Mar 01 21:35:03 lynwood /usr/lib/gdm3/gdm-wayland-session[1606]: In
pixman_region32_union_rect: Invalid rectangle passed
Mar 01 21:35:03 lynwood /usr/lib/gdm3/gdm-wayland-session[1606]: Set a
breakpoint on '_pixman_log_error' to debug
Mar 01 21:35:03 lynwood /usr/lib/gdm3/gdm-wayland-session[1606]: ***
BUG ***
Mar 01 21:35:03 lynwood /usr/lib/gdm3/gdm-wayland-session[1606]: In
pixman_region32_union_rect: Invalid rectangle passed
Mar 01 21:35:03 lynwood /usr/lib/gdm3/gdm-wayland-session[1606]: Set a
breakpoint on '_pixman_log_error' to debug
Mar 01 21:35:03 lynwood /usr/lib/gdm3/gdm-wayland-session[1606]: ***
BUG ***
Mar 01 21:35:03 lynwood /usr/lib/gdm3/gdm-wayland-session[1606]: In
pixman_region32_union_rect: Invalid rectangle passed
Mar 01 21:35:03 lynwood /usr/lib/gdm3/gdm-wayland-session[1606]: Set a
breakpoint on '_pixman_log_error' to debug
Mar 01 21:35:03 lynwood /usr/lib/gdm3/gdm-wayland-session[1606]: ***
BUG ***
Mar 01 21:35:03 lynwood /usr/lib/gdm3/gdm-wayland-session[1606]: In
pixman_region32_union_rect: Invalid rectangle passed
Mar 01 21:35:03 lynwood /usr/lib/gdm3/gdm-wayland-session[1606]: Set a
breakpoint on '_pixman_log_error' to debug
Mar 01 21:35:03 lynwood /usr/lib/gdm3/gdm-wayland-session[1606]:
2020-03-01 21:35:03 - [backend/drm/atomic.c:57] HDMI-A-2: Atomic commit failed
(pageflip): Device or resource busy
Mar 01 21:35:03 lynwood /usr/lib/gdm3/gdm-wayland-session[1606]: [
Mar 01 21:35:03 lynwood /usr/lib/gdm3/gdm-wayland-session[1606]:{
Mar 01 21:35:03 lynwood /usr/lib/gdm3/gdm-wayland-session[1606]:
"success": true
Mar 01 21:35:03 lynwood /usr/lib/gdm3/gdm-wayland-session[1606]:}
Mar 01 21:35:03 lynwood /usr/lib/gdm3/gdm-wayland-session[1606]: ]
Mar 01 21:35:03 lynwood /usr/lib/gdm3/gdm-wayland-session[1606]:
2020-03-01 21:35:03 - [main.c:300] Found config * for output HDMI-A-2
(ViewSonic Corporation VX2778 Series ULY182060543)
Mar 01 21:35:03 lynwood /usr/lib/gdm3/gdm-wayland-session[1606]:
[2020-03-01 21:35:03.227] [warning] For a functional tray you must have
libappindicator-* installed and export XDG_CURRENT_DESKTOP=Unity
Mar 01 21:35:03 lynwood /usr/lib/gdm3/gdm-wayland-session[1606]:
[2020-03-01 21:35:03.228] [error] media stopped unexpectedly, is it endless?
Mar 01 21:35:03 lynwood /usr/lib/gdm3/gdm-wayland-session[1606]:
2020-03-01 21:35:03 - [backend/drm/atomic.c:57] HDMI-A-2: Atomic commit failed
(pageflip): Device or resource busy
Mar 01 21:35:03 lynwood /usr/lib/gdm3/gdm-wayland-session[1606]:
2020-03-01 21:35:03 - [backend/drm/atomic.c:57] HDMI-A-2: Atomic commit failed
(pageflip): Device or resource busy
Mar 01 21:35:03 lynwood /usr/lib/gdm3/gdm-wayland-session[1606]:
2020-03-01 21:35:03 - [xwayland/xwm.c:1285] xcb error: op 18:0, code 3,
sequence 27404, value 27263008
Mar 01 21:35:03 lynwood /usr/lib/gdm3/gdm-wayland-session[1606]:
2020-03-01 21:35:03 - [xwayland/xwm.c:1285] xcb error: op 18:0, code 3,
sequence 27406, value 16782083
Mar 01 21:35:03 lynwood /usr/lib/gdm3/gdm-wayland-session[1606]:
[2020-03-01 21:35:03.369] [warning] Requested width: 0 exceeds the minimum
width: 2560 required by the modules
Mar 01 21:35:03 lynwood /usr/lib/gdm3/gdm-wayland-session[1606]: (EE)
Mar 01 21:35:03 lynwood /usr/lib/gdm3/gdm-wayland-session[1606]: (EE)
Backtrace:
Mar 01 21:35:03 lynwood /usr/lib/gdm3/gdm-wayland-session[1606]: (EE)
0: Xwayland
Bug#952940: nm.debian.org: show sender/subject/date of current mail at the top of full screen mail view
Package: nm.debian.org Severity: wishlist At the top of the full screen mail view one could show sender/subject/date of the current mail, maybe instead of the text "Mail Archive". signature.asc Description: This is a digitally signed message part.
Bug#952946: bind9: Replace PKCS11 headers provided by OASIS
Source: bind9 Severity: serious Since headers provided by OASIS PKCS11 are not-exactly free license (they do not allow modification), You can use an alternative header like p11-kit which is licensed under a more liberal license. bind9/lib/isc/include/pkcs11 Regards, Alvin Chen
Bug#952945: RM: php-smbclient -- ROM; incompatible licenses
Package: ftp.debian.org Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, php-client compiles against PHP headers and libsmbclient (GPLv3) and also links with PHP and libsmbclient (GPLv3) into a single binary when dynamically loaded to PHP executable (see #948075). Unfortunately, the only solution here is to remove php-smbclient. Ondrej -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAl5ct3pfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u WcJDEA/+IxgASKOJvMUDG7T/UBiWCl+mrKIM+l+SVcL3f0SHygDDdfxj2znRwftG oASeIcXS0HymytHeEOOz4idKW8UviSELKn72TlbIDNwpnMhjZuTZaRHIepgh/EGY 2aBFlfqiyI8g1PIDPo8e30NAxLNaEuAxCUpaMv/5zia46s7ZS8V33y2atZFd8kYc 9o09xkvnowWN3L97PMYSfLnJxkLSI0z0Fyd2fNsMkmM4zjKvY1L7ckfHeGQT60JO 5KgZTnWgK6blZApXxGLtWH0tkEywavP3oQ29QUxTALkbQdIKc7/o8rV2DfBjVb3R eelGbBnVoOgXyFUUfxfshPQ3Ca9PeUPWcQNxoVIFbr4u4JpTG4J0E43CDZuLdQ+/ P4y9s4AygWgL072CRSiFgRPwTuxt2ukvm+I+d3v+7KgJSqpPK7w3q3wnZozWr3OP bNe/Vc55mFTsObRqt8ibZsWugWxwtQSeNTTUwtpbzN7+CliIEoo5D33Wb3nm8SM5 KjB7Z9MA/zSfRdQpQ3UoXjItmeiryJ8zYfRqavhQ0p/3ZtQ4R9NPZTtKMfx3hyrQ wK16zva3y28TdRL277S+p+Yru1yfMSrstpqkjNpXJ9yDqiIvEsSxjq9yXLCSwmt1 lkO/zrtJuj3vpnRDxXrfmrj3lkJpe0+uH9dl4DTodim79Vm5jhQ= =R/xY -END PGP SIGNATURE-
Bug#952894: cups: Bad Request for FQDN without explicit ServerAlias
Le dimanche, 1 mars 2020, 16.43:56 h CET Kevin Locke a écrit : > Accessing CUPS via https://hostname:631 works while > https://hostname.example.com:631 fails with 400 Bad Request if > cupsd.conf does not contain either "HostNameLookups on" or > "ServerAlias printserver.example.com". This is a divergence from > upstream, where the FQDN returned by gethostname(2) is automatically > added as a ServerAlias. > > It appears to be an untended side-effect of > 0026-Do-not-use-host-names-for-broadcasting-print-queues-.patch for > LP#449586. Perhaps we could consider a different way to disable name > broadcasting without removing the ServerAlias for the FQDN which is used > for HTTP host checking? Have you tried building and testing without this patch? After 4+ years, it seems realistic to try without this patch again but: a) only if we're sure it helps, b) only after 2.3.1-11 is migrated to testing. Regards, OdyX
Bug#936055: t/unthreaded.t test failing
Control: reassign -1 gdb 9.1-1
Control: forwarded -1
https://sourceware.org/ml/gdb-patches/2020-03/msg00010.html
Control: retitle -1 [regression] GDB can't printf convenience vars that hold
pointers to strings
On Wednesday, February 19 2020, gregor herrmann wrote:
> On Wed, 19 Feb 2020 14:16:52 +0100, Héctor Orón Martínez wrote:
>
>> This issue is now affecting GDB 9.1 autopkgtests and preventing it from
>> migrating to testing.
>>
>> https://ci.debian.net/data/autopkgtest/testing/amd64/liba/libapp-stacktrace-perl/4328197/log.gz
>>
>> https://ci.debian.net/data/autopkgtest/testing/arm64/liba/libapp-stacktrace-perl/4314744/log.gz
>
> Oh, one of the bugs which "hide":
> https://ci.debian.net/packages/liba/libapp-stacktrace-perl/testing/amd64/
> is all green, and after clicking on britney it turns red:
> https://ci.debian.net/user/britney/jobs?package=libapp-stacktrace-perl[]=testing[]=amd64
Hi there,
After spending a non-trivial amount of time investigating this over the
weekend, I was able to find the underlying case of the bug (and come up
with a fix). Please, keep reading.
> Anyway, in the meantime it also FTBFS in unstable:
>
> # [Thread debugging using libthread_db enabled]
> # Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> # 0x7f7b77cc1047 in select () from /lib/x86_64-linux-gnu/libc.so.6
> # à|ÚU:101
> # à|ÚU:106
> # à|ÚU:106
> # à|ÚU:106
> # à|ÚU:106
> # à|ÚU:106
> # à|ÚU:106
> # à|ÚU:106
> # à|ÚU:106
> # à|ÚU:106
> # à|ÚU:106
> # [Inferior 1 (process 25884) detached]
>
> # Failed test at t/unthreaded.t line 55.
> # '[Thread debugging using libthread_db enabled]
> # Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> # 0x7f7b77cc1047 in select () from /lib/x86_64-linux-gnu/libc.so.6
> # à|ÚU:101
> # à|ÚU:106
> # à|ÚU:106
> # à|ÚU:106
> # à|ÚU:106
> # à|ÚU:106
> # à|ÚU:106
> # à|ÚU:106
> # à|ÚU:106
> # à|ÚU:106
> # à|ÚU:106
> # [Inferior 1 (process 25884) detached]
> # '
> # doesn't match '(?^mx:
> # (?:
> # ^t/unthreaded\.t:\d+\n
> # ){10}
> # )'
> # Looks like you failed 1 test of 5.
> t/unthreaded.t
> 1..5
> not ok 1
> ok 2 - Reaped pstack
> ok 3 - exit(0)
> ok 4 - No signals
> ok 5 - No core dump
> # Alive top 1582127930: 1 middle: 1
> # Alive top 1582127931: 1 middle: 0
> Dubious, test returned 1 (wstat 256, 0x100)
> Failed 1/5 subtests
>
> Test Summary Report
> ---
> t/unthreaded.t (Wstat: 256 Tests: 5 Failed: 1)
> Failed test: 1
> Non-zero exit status: 1
> Files=4, Tests=6, 2 wallclock secs ( 0.03 usr 0.01 sys + 0.96 cusr 0.09
> csys = 1.09 CPU)
> Result: FAIL
>
> (I _think_ that's yet another different error.)
This seems to be the same failure reported by doko.
> In testing with gdb 8.3.1 the package still builds:
>
> # [Thread debugging using libthread_db enabled]
> # Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> # 0x7f1b9eb77047 in select () from /lib/x86_64-linux-gnu/libc.so.6
> # t/unthreaded.t:101
> # t/unthreaded.t:106
> # t/unthreaded.t:106
> # t/unthreaded.t:106
> # t/unthreaded.t:106
> # t/unthreaded.t:106
> # t/unthreaded.t:106
> # t/unthreaded.t:106
> # t/unthreaded.t:106
> # t/unthreaded.t:106
> # t/unthreaded.t:106
> # [Inferior 1 (process 3207) detached]
> t/unthreaded.t
> 1..5
> ok 1
> ok 2 - Reaped pstack
> ok 3 - exit(0)
> ok 4 - No signals
> ok 5 - No core dump
> # Alive top 1582128303: 1 middle: 1
> # Alive top 1582128304: 1 middle: 0
> ok
Right. This is actually a regression that happened on GDB (therefore
I'm reassigning the bug).
So, it took me quite a bit of time to debug this because
libapp-stacktrace-perl doesn't help when it comes to seeing what GDB is
doing inside it... But I was able to determine that the problem started
happening after the following upstream commit:
commit 1f6f6e21fa86dc3411a6498608f32e9eb24b7851
Author: Philippe Waroquiers
Date: Mon Jun 10 21:41:51 2019 +0200
Ensure GDB printf command can print convenience var strings without a
target.
As the commit title says, the goal here was to make GDB's "printf"
command be able to print convenience variables that are strings without
the need for a target (a program/corefile being debugged, for example).
However, the commit changed the way GDB treats convenience variables
that *point* to addresses referring to e.g. a "char *" inside the
debuggee's memory space. GDB will treat this as a string (because it's
pointing to a "char *"), and will try to obtain its value via the wrong
mechanism.
I won't dive too deep here; suffice it to say that if we treat
convenience variables that hold pointers in a different manner, then
things get back to normal.
I submitted a tentative patch to fix this upstream, and will backport it
downstream once my approach is deemed correct.
Thanks,
--
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF
Bug#952943: BUG: xlsx2csv debian package version
Package: xlsx2csv Hi Mikhail, I confirm the issue: andrius@amalas ~ $ xlsx2csv --version 0.7.5 andrius@amalas ~ $ dpkg -l | grep xlsx2csv ii xlsx2csv 1:0.7.6-1 all convert xslx files to csv format However, it seems to be present in the upstream tarball. It is already fixed upstream, however, not yet released. I agree it should be patched for now. Best, Andrius On 2020-03-02 07:45, Mikhail Kotelnikov wrote: > I have xlsx2csv v0.7.6 installed but it contains v0.7.5 script.
Bug#952942: biglybt: package ignores ~/.biglybt/java.vmoptions
Package: biglybt Version: 2.2.0.2-2 Upstream version of BiglyBT uses options specified in `~/.biglybt/java.vmoptions` (one per line) to apply them to the JVM. It's useful, since it allows to allocate more memory than the default, or run with some nonstandard options. In my case, without allocating more memory than the default for JVM is in Debian, I'm running into performance issues. Example content of `java.vmoptions` file: ``` -Xmx1024m -Xms256m -XX:+PerfDisableSharedMem -XX:+UnlockExperimentalVMOptions -XX:+UseZGC ``` Additionally, upstream version of BBT provides information about the file and what options are specified in it in its options (Tools > Options > Startup & Shutdown), and it also has GUI for setting how much memory is JVM allowed to use. Currently I worked around this issue by putting together content of `/usr/bin/biglybt` and options from the ignored file in a custom script. By the way, `$@` in `/usr/bin/biglybt` should be enclosed in double quotes, otherwise the wrapper is going to treat spaces in torrent filenames as arg separator, preventing it from being able to open torrents with spaces in filename. Feel free to use the patch: >From ea85fc1ca864c956d1605a539f5f27cd3c4e1df8 Mon Sep 17 00:00:00 2001 From: Elde Etnor Date: Mon, 2 Mar 2020 03:41:13 + Subject: [PATCH] Fix missing quotes around `$@` in debian/biglybt.sh --- debian/biglybt.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/biglybt.sh b/debian/biglybt.sh index fb1363f..427c673 100755 --- a/debian/biglybt.sh +++ b/debian/biglybt.sh @@ -2,4 +2,4 @@ java -cp /usr/share/java/biglybt-core.jar:/usr/share/java/biglybt-ui.jar:/usr/share/java/commons-cli.jar:/usr/share/java/swt4.jar:/usr/share/java/bcprov.jar \ -Dazureus.install.path=/usr/share/biglybt \ - com.biglybt.ui.Main $@ + com.biglybt.ui.Main "$@" -- 2.24.1
Bug#944769: python3-h5py fails to import if offline due to apparent MPI failure
Source: h5py Followup-For: Bug #944769 Combination of setattr and resetting entries in sys.modules to the h5py namespace seems to get the job done.
Bug#952944: ITP: qt5-ukui-platformtheme -- Qt5 QPA platform theme of UKUI
Package: wnpp Severity: wishlist Owner: handsome_feng * Package name: qt5-ukui-platformtheme Version : 0.9.0 Upstream Author : Lan Yue * URL : https://github.com/ukui/qt5-ukui-platformtheme * License : LGPL-3+ Programming Lang: C++ Description : Qt5 QPA platform theme of UKUI qt5-ukui-platformtheme is official platform theme of UKUI desktop environment. It also provides the common metadatas for ukui-styles and platform theme using. The library provided many convenient API for changing a qt widgets style, such as buttons color, tabwidget animation, etc. Thanks, handsome_feng
Bug#952913: Re: Bug#952913: biglybt: Side Bar rapidly flickers on mouse hoover
On 2020-03-01 21:13 UTC Emmanuel Bourg wrote: > Le 01/03/2020 à 20:26, e...@i2pmail.org a écrit : > > > When moving mouse pointer over the Side Bar in BiglyBT it rapidly flickers, > > with the content of the sidebar rapidly appearing and disappearing. > > > Thank you for the feedback. I haven't experienced this issue yet. What > JRE and desktop environment did you use? > > Emmanuel Bourg openjdk-11-jre:amd64 11.0.6+10-2 I'm running BBT from within a LXC container, container host is a different distro running inside a VM. VM uses IceWM as a "desktop environment". I view the VM using spice protocol (virt-viewer).
