Bug#1066783: streamlink: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13
Hi, Just found that the autopkgtest that run tests also has this issue and is blocking the migration to testing. Will look into this. -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F |
Bug#1031173: arcanist-clang-format-linter: prevents arcanist tool from working (PHP Fatal error: Uncaught Error)
Package: arcanist-clang-format-linter
Version: 0.git20161021-3
Severity: grave
Justification: renders package unusable
Dear Maintainer,
When arcanist-clang-format-linter is installed, arcanist will fail to run with
this error:
$ arcanist help
PHP Fatal error: Uncaught Error: Call to undefined function
arcanist_load_libraries() in
/usr/share/arcanist/src/extensions/clang-format-linter.php:3
Stack trace:
#0 /usr/share/arcanist/src/init/lib/PhutilBootloader.php(247): include_once()
#1 /usr/share/arcanist/src/init/lib/PhutilBootloader.php(287):
PhutilBootloader->executeInclude('...')
#2 /usr/share/arcanist/src/init/lib/PhutilBootloader.php(106):
PhutilBootloader->loadExtension('...', '...', '...')
#3 /usr/share/arcanist/src/init/lib/PhutilBootloader.php(21):
PhutilBootloader->registerLibrary('...', '...')
#4 /usr/share/arcanist/src/init/init-library.php(70):
PhutilBootloader::newLibrary('...', '...')
#5 /usr/share/arcanist/support/init/init-script.php(114): require_once('...')
#6 /usr/share/arcanist/support/init/init-script.php(131):
__arcanist_init_script__()
#7 /usr/share/arcanist/support/init/init-arcanist.php(3): require_once('...')
#8 /usr/share/arcanist/bin/arc(10): require_once('...')
#9 {main}
thrown in /usr/share/arcanist/src/extensions/clang-format-linter.php on line 3
The error does not appear when using arcanist without having this package
installed.
As this render the arcanist tool unusable, I've marked this bug as grave.
The most probable cause to this is the fact that arcanist-clang-format-linter
version is from 2016 but arcanist is from 2022.
I guess there were breaking changes in arcanist since then.
Upstream seem to have stopped any development on it as the last commit is from
2016.
See https://github.com/pwithnall/morefas-phabricator.
I installed this package to do development on LLVM (which use phabricator).
But it seems that it is in fact not needed, LLVM having its own lint script for
code style (which use clang-format too).
So I guess the solution is to remove this package from Debian as it doesn't
work anymore and was not updated upstream ?
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (950, 'unstable'), (500, 'unstable-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages arcanist-clang-format-linter depends on:
ii arcanist 0~git20220903-2
ii clang-format 1:14.0-55.5+b1
ii diffutils 1:3.8-4
arcanist-clang-format-linter recommends no packages.
arcanist-clang-format-linter suggests no packages.
--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F |
Bug#1021032: vlc: playing videos results in a black screen
Hi, On Sat, 08 Oct 2022 14:30:43 +0300 =?ISO-8859-1?Q?R=E9mi?= Denis-Courmont wrote: Le lauantaina 8. lokakuuta 2022, 12.40.56 EEST KeyofBlueS a écrit : > Hi all. Let's continue here from #1021140 > <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021140> > > It seems this issue it's not completely fixed. Before it was always > reproducible under any circumstance, when now there are at least two ways > to always trigger it: I believe that the issue is not fixed at all. The symptoms started showing up after Debian updated Qt, and affect only the Qt GUI. The last attempt to fix it affected the VA-API video decoding path in such a way that it will still *fail* at a different pace than it did before the fix. Then it will fallback to VDPAU or to software decoding path. [...] I'm jumping in to add information, I also get black screen issue after updating Qt from 5.15.4 to 5.15.6. I also get graphical issues in the playlist, when resizing the VLC window. These graphical issues appear also in virtualbox-qt. I've already created a bug on qt: #1023580 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023580 -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F
Bug#990340: glances: contains prebuilt javascript without source
Control: tag -1 + patch On Tue, 29 Jun 2021 01:44:06 +0530 Pirate Praveen wrote: > It uses webpack to build. > > https://github.com/nicolargo/glances/blob/develop/glances/outputs/static/package.json#L28 > > cd glances/outputs/static && webpack > > in debian/rules with required build dependencies added should work. Most > build dependencies are already packaged. > -- > Sent from my p≡p for Android. Most (non-dev) dependencies are not in Debian [0] (like angular) so I've made a MR [1] that simply remove pre-built files. This makes the remote web interface probably useless, but the package can still be used for most usages (I guess, in standalone mode for example, which is the only mode I use). [1] npm2deb output on package.json (modified to add required "name" key): Dependencies: NPM Debian glances-web-ui (FIX_ME version) None ├─ angular (^1.7.9) None ├─ angular-hotkeys (^1.7.0) None ├─ bootstrap (^3.4.1) None ├─ favico.js (^0.3.10)None └─ lodash (^4.17.15) node-lodash (4.17.21+dfsg+~cs8.31.189.20210220-1) Build dependencies: NPM Debian clean-webpack-plugin (^0.1.19)None copy-webpack-plugin (^4.6.0) node-copy-webpack-plugin (5.1.2+~cs9.0.2-4) css-loader (^0.28.11) node-css-loader (5.0.1+~cs14.0.5-2) del (^2.2.1) node-del (5.1.0-2) exports-loader (^0.7.0) node-exports-loader (1.1.1-2) file-loader (^1.1.11) node-file-loader (6.2.0-2) html-loader (^0.5.5) None less (^3.10.3)less.js (3.13.0+dfsg-5) less-loader (^4.1.0) node-less-loader (5.0.1-2) ngtemplate-loader (^2.0.1)None node-sass (^4.14.0) node-node-sass (4.14.1+git20200512.e1fc158+dfsg-4) sass-loader (^6.0.7) None style-loader (^0.20.3)node-style-loader (2.0.0-2) url-loader (^0.6.2) node-url-loader (4.1.1-3) webpack (^3.12.0) node-webpack (5.6.0+~cs6.4.0-1~exp2) [0] https://salsa.debian.org/debian/glances/-/merge_requests/2 -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F| signature.asc Description: OpenPGP digital signature
Bug#958621: Bug #958621: schroot: Build-Depends on deprecated dh-systemd which is going away
Hi, I've prepared a merge request in gitlab to remove the dependency on dh-systemd and update the required version of debhelper: https://salsa.debian.org/debian/schroot/-/merge_requests/1 I've also attached to this mail the same proposed patch. -- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958621 -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F diff --git a/debian/changelog b/debian/changelog index 63180d5db1ca3fd908e3c08e3b1ae89ba9fce6ad..e217cd67cb4b64c0ca0e433eb373b6c2de65466b 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,13 @@ +schroot (1.6.10-10) UNRELEASED; urgency=medium + + * QA upload. + * debian/control: ++ Remove Build-Depends on deprecated dh-systemd and depend on + debhelper (>= 9.20160709) now that it integrates dh-systemd. + Closes: #958621. + + -- Alexis Murzeau Wed, 19 Aug 2020 00:37:37 +0200 + schroot (1.6.10-9) unstable; urgency=medium * QA upload. diff --git a/debian/control b/debian/control index 1e2ff3151e04e388061d9465d435a34fef8ba928..200e86c333cdbe7b4e9786c1e8d587467b9c5588 100644 --- a/debian/control +++ b/debian/control @@ -4,8 +4,7 @@ Priority: optional Maintainer: Debian QA Group Build-Depends: cmake (>= 2.8.12), - debhelper (>= 9), - dh-systemd, + debhelper (>= 9.20160709), pkg-config, libpam0g-dev, uuid-dev [!kfreebsd-any], signature.asc Description: OpenPGP digital signature
Bug#957003: aqemu: ftbfs with GCC-10
Hi, On Fri, 17 Apr 2020 10:56:28 + Matthias Klose wrote:> > The package fails to build in a test rebuild on at least amd64 with > gcc-10/g++-10, but succeeds to build with gcc-9/g++-9. The > severity of this report will be raised before the bullseye release, > so nothing has to be done for the buster release. > As this package is orphaned I will try to provide a fix for this. Adding #include to docopt_value.h should be sufficient. In the process of doing this, I will try to put this package under the debian salsa group and make the first QA upload for it. -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#927126: Fwd: Bug#929342: unblock: aqemu/0.9.2-2.2
Le 11/06/2019 à 21:58, Paul Gevers a écrit : > Hi Alexis, > > [Note: when you think you have covered questions asked, please remove > the moreinfo tag, as it will make the bug show up in the list of bugs > that need attention from us]. Ok, I guess that tag should be removed once aqemu/0.9.2-2.3 enter unstable, right ? > > On 06-06-2019 22:16, Alexis Murzeau wrote: >> The modification I've done in version aqemu/0.9.2-2.3 specifically fix >> descriptions that was referring to VLAN or Virtual LAN (all instances) >> as reported by Jonathan. >> I've reused the description of the various command line arguments that >> no longer accept the vlan parameter from the qemu man page. >> >> (aqemu/0.9.2-2.3 is not in unstable as of now). >> >> This is the diff between aqemu/0.9.2-2.2 (unstable) and aqemu/0.9.2-2.3 >> (upload candidate on mentors.debian.net): >> >> https://salsa.debian.org/amurzeau-guest/aqemu/compare/debian%2F0.9.2-2.2...debian%2F0.9.2-2.3#380c8035425c8dcf8fb5ead9e2d4e5bc1a9f7192 > > This looks OK, so I think it is best to find a sponsor to upload that, > such that we can proceed with unblocking when the full patch is reviewed. > >> And the diff between actual buster version (aqemu/0.9.2-2.1) and >> aqemu/0.9.2-2.3: >> >> https://salsa.debian.org/amurzeau-guest/aqemu/compare/debian%2F0.9.2-2.1...debian%2F0.9.2-2.3 > > I specifically note that I have *not* checked the full diff. > > Paul > I will make an RFS since Abhijith does not seem available to do the upload. -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#927126: Fwd: Bug#929342: unblock: aqemu/0.9.2-2.2
Le 06/06/2019 à 21:34, Paul Gevers a écrit : > Hi Alexis, > > On Sun, 2 Jun 2019 22:35:47 +0200 Alexis Murzeau wrote: >> Did you have any chance to look at this ? Is this upload ok ? > > Looking at the message header (the TO field) you addressed you sponsor > with this question, right? I think you should however be able to answer > the question by Jonathan yourself. Yes, it was addressed to Abhijith PA. > > """ > This might benefit from another read; it seems to remove the vlan > parameter but still refer to it in the text? It's worth checking through > for any other similar instances. > """ > > Please comment on it, and we can follow up again. > > Paul > The modification I've done in version aqemu/0.9.2-2.3 specifically fix descriptions that was referring to VLAN or Virtual LAN (all instances) as reported by Jonathan. I've reused the description of the various command line arguments that no longer accept the vlan parameter from the qemu man page. (aqemu/0.9.2-2.3 is not in unstable as of now). This is the diff between aqemu/0.9.2-2.2 (unstable) and aqemu/0.9.2-2.3 (upload candidate on mentors.debian.net): https://salsa.debian.org/amurzeau-guest/aqemu/compare/debian%2F0.9.2-2.2...debian%2F0.9.2-2.3#380c8035425c8dcf8fb5ead9e2d4e5bc1a9f7192 And the diff between actual buster version (aqemu/0.9.2-2.1) and aqemu/0.9.2-2.3: https://salsa.debian.org/amurzeau-guest/aqemu/compare/debian%2F0.9.2-2.1...debian%2F0.9.2-2.3 -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#927126: Fwd: Bug#929342: unblock: aqemu/0.9.2-2.2
Le 28/05/2019 à 00:16, Alexis Murzeau a écrit : > Le 27/05/2019 à 21:58, Alexis Murzeau a écrit : >> Le 27/05/2019 à 08:02, Abhijith PA a écrit : >>> On 26 May 2019 4:01:33 PM IST, Alexis Murzeau wrote: >>>> >>>> Ok, I have changed them to use what's is in the qemu-system manpage. >>>> Here is the commit on salsa: [0] >>>> >>>> >>>> Also, while aqemu will be able to run qemu again, I think it won't be >>>> able to create multiple virtual hub as the command line option "-net >>>> nic" only use the default hub ID 0. >>>> >>>> I don't know if this a serious issue that should be fixed too. >>>> In the meanwhile, I guess aqemu will still be able to create multiple >>>> nic but all of them will be connected to the same default hub. >>>> >>>> What do you think of this ? >>> >>> What is the upstream preferred way of doing this ? >>> >>>> [0] >>>> https://salsa.debian.org/amurzeau-guest/aqemu/commit/26087ea3c3700bc5a019ae8cc0f84eb14954ef3d >>> >> >> I didn't ask upstream about it but given the last commit is in 2017 and >> the change I've backported was partly made by someone else in a fork, I >> don't expect any response from upstream. >> >> I think updating aqemu to be able to create multiple virtual hub again >> is possible but would require more changes than a small patch. I think >> it would require to remove the use of old -net option of qemu to the >> newer -netdev. >> > > For reference, the original issue about the vlan argument was also > reported upstream in 09/2018 as: > https://github.com/tobimensch/aqemu/issues/58 > > I'm not an aqemu user myself, but if you think that's ok anyway as at > least configurations with single nic are working now, I've uploaded the > package on mentors, here is the dsc link: > > https://mentors.debian.net/debian/pool/main/a/aqemu/aqemu_0.9.2-2.3.dsc > Hi, Did you have any chance to look at this ? Is this upload ok ? -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#925555: linux-image-4.19.0-4-amd64: [regression] No graphics on some IvyBridge / Haswell systems
Hi, On Mon, 6 May 2019 12:08:03 +0100 "Rebecca N. Palmer" wrote: > Control: forcemerge -1 926193 > Control: tags -1 upstream patch > Control: retitle -1 linux-image-4.19.0-4-amd64: [regression] No graphics on > some IvyBridge / Haswell systems > Control: forwarded -1 https://bugs.freedesktop.org/show_bug.cgi?id=109806 > > (Summary of the merged bugs - I haven't tried any of this myself) > > Workaround for individuals (from leandroembu) - install > xserver-xorg-video-intel and copy > /usr/share/doc/xserver-xorg-video-intel/xorg.conf to /etc/X11. This is > probably not suitable as an official fix as it may cause problems on > newer hardware (e.g. #860133). > > Possible patch: revert drm/i915/fbdev: Actually configure untiled > displays (d179b88deb3bf6fed4991a31fd6f0f2cad21fab5). Has been applied > upstream, but the real bug is thought to be in xorg not linux. > > > As a side note, I'm affected by this bug and your suggested workaround of copying a xorg.conf in /etc/Xorg worked for me, thanks :) The linux commit got reverted since v5.1-rc7. I don't know how Xorg and modeset work and what is exactly the atomic mode. Also, I wasn't able to find what was fixed with the commit d179b88deb3bf6fed4991a31fd6f0f2cad21fab5 in linux, if it was possible bugs discovered by reading the code or actual bugs users already encountered. But as I understand, there are several solutions to this bug: - Revert the drm/i915/fbdev: Actually configure untiled displays (d179b88deb3bf6fed4991a31fd6f0f2cad21fab5) commit in Linux. This revert is in mainline since v5.1-rc7 [0] - Rework the atomic support in Xorg, that require extensive modifications but is in state to be tested, updated and validated [1] - Disable atomic mode and fallback to legacy mode but that seem suboptimal as atomic mode might be required by some drivers [2] I guess backporting PR !36 [1] is too much changes in Xorg now that we are in hard freeze and probably too risky given it is still work-in-progress. But I can't see how broken is to revert d179b88 commit in linux as I don't what that commit fixed. It seems to be not that critical as upstream linux has done the revert. So I guess one solution is to just do the revert in linux and let the next stable after Buster have the proper fix in Xorg with the time needed to ensure it is working fine without breaking in various ways. [0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9fa246256e09dc30820524401cdbeeaadee94025 [1] https://gitlab.freedesktop.org/xorg/xserver/merge_requests/36 [2] https://gitlab.freedesktop.org/xorg/xserver/merge_requests/180 -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#927126: aqemu: after updating can't open VMs
Forgot to send to bts email address, sorry for the flood. On May 19, 2019 6:02:37 AM GMT+02:00, Abhijith PA wrote: >You are looking for sponsor ? Well I can help you with it. I am DD. Yes, I'm looking for a sponsor that can upload the package to unstable :). -- Alexis Murzeau
Bug#927126: aqemu: after updating can't open VMs
Le 18/05/2019 à 05:27, Abhijith PA a écrit : > Dear Alexis. > > I tried your build and its working for me, thanks. I think you should > upload to archive. We still have time, isn't ? > > > --abhijith > Yes it should be fine. FYI, I've made a RFS to upload the NMU'ed package: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929180 -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#927126: aqemu: after updating can't open VMs
Le 14/05/2019 à 05:28, Abhijith PA a écrit : > > > On 29/04/19 1:22 am, Alexis Murzeau wrote: >> The vlan argument issue has a upstream issues open [0]. >> >> [0] : >> - https://github.com/tobimensch/aqemu/issues/58 >> - https://github.com/tobimensch/aqemu/issues/57 > > The error log in issue 57 is same as what I get. > >> - https://github.com/tobimensch/aqemu/pull/61 > > Yes, please > https://github.com/tobimensch/aqemu/pull/61/commits/9ff55188fb8479e573d6ed6f5669147af48316a9 > try to backport this patch. I can help you in testing. > > > --abhijith > I've put a test package that include the more complete commit: https://github.com/pcwizzy37/aqemu/commit/37d5447126343cc7a70b95c6e73d670be444a05d The package is available in this repository: https://github.com/amurzeau/apt-repository/ Instructions to install the repository are in the README.md file. -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#926180: scilab: FTBFS on all - New trouble
Le 13/05/2019 à 08:08, Sylvestre Ledru a écrit : > > On 12/05/2019 22:10, Julien Puydt wrote: >> Hi, >> >> On 12/05/2019 11:46, Alexis Murzeau wrote: >> >>> I saw that there is a bugfix release 6.0.2 with many fixes [0]. >> I had started to package 6.0.2 on salsa already in february. I removed >> the patch about Linenum as that was supposed to have been reworked and >> fixed, and it now fails with : >> >> ocamlopt -o XML2Modelica -I ./src/modelica_compiler -I >> ./src/xml2modelica nums.cmxa ./src/xml2modelica/xMLTree.ml >> ./src/xml2modelica/linenum.ml ./src/xml2modelica/stringParser.ml >> ./src/xml2modelica/stringLexer.ml ./src/xml2modelica/xMLParser.ml >> ./src/xml2modelica/xMLLexer.ml >> ./src/xml2modelica/modelicaCodeGenerator.ml >> ./src/xml2modelica/xML2Modelica.ml >> File "./src/xml2modelica/xML2Modelica.ml", line 1: >> Error: Files ./src/xml2modelica/xMLParser.cmx >>and ./src/xml2modelica/linenum.cmx >>make inconsistent assumptions over implementation Linenum >> >> ie : it looks like upstream's fix isn't correct. > > + upstream > > S > > Reversing the order of the includes parameters when compiling XML2Modelica fix the build for me, ie. including xml2modelica first: `-I ./src/xml2modelica -I ./src/modelica_compiler` I think ocamlopt prefer to use a part of Linenum from ./src/modelica_compiler and the other one from ./src/xml2modelica which lead to the error. But I'm not sure this is the way to handle it cleanly. The files "linenum.mll" are almost the same between both directories. The only difference is the comment at the beginning of the file. Maybe some of these "linenum.mll" file can be removed to keep only one ? -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F
Bug#927126: aqemu: after updating can't open VMs
Le 28/04/2019 à 21:52, Alexis Murzeau a écrit : > On Mon, 15 Apr 2019 16:55:13 +0530 Abhijith PA wrote: >> I recently updated aqemu and ended up in not able to open VMs. >> >> Following is the message is what I get when I open VMs >> >> AQEMU Error [264] >>> >> Sender: QEMU return value != 0 >> Message: >> > > Hi, > > When you right-click on your VM and choose "Show QEMU Arguments", what > are the arguments of qemu ? > If you try to run the command directly in a console, does it works ? > If not, what's the qemu error ? > > I tried myself and got errors about the vlan option. > This option seems to be deprecated since a long time and removed now. > > The vlan argument issue has a upstream issues open [0]. > > [0] : > - https://github.com/tobimensch/aqemu/issues/58 > - https://github.com/tobimensch/aqemu/issues/57 > - https://github.com/tobimensch/aqemu/pull/61 > As this package is going to be removed if nothing happen, I will try to backport a patch from upstream forks. popcon indicate that is really used (while I don't use it myself), and might be more used given virtualbox was removed from buster [0]. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794466 -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#927462: Bug #927462: megadown: Does not download anything
Hi, Did you see this bug on the megadown package ? I saw that your maintainer email (vivia.nikolai...@puri.sm) is not the one you used when creating bugs before (n.vi...@gmail.com), so I am mailing both just in case. On Sat, 20 Apr 2019 09:12:53 +0300 jim_p wrote: > Package: megadown > Version: 0~20180705+git83c53dd-1 > Severity: grave > Tags: upstream > Justification: renders package unusable > > Dear Maintainer, > > When trying to download a file from mega, which is the sole reason this script > exists, megadown fails like so > > $ megadown > 'https://mega.nz/#!3QsG0IDJ!wnEhMRAj1UsXvH3BmWKfr5Z4wqMD2c5ru4iWgFzJmO0' > Reading link metadata... > MEGA bad link > > I reported the issue to the project's github page, because it happened with > other mega links as well, and its dev issued a patch that restores the > intended > functionality, here > > https://github.com/tonikelope/megadown/commit/734e46fec67a2798bfbb5e21a75f04b90afafd65 > > So please update the package on the repo, which by the way is numerous minor > versions behind. > Are you already in the process of backporting this patch, or do you need any help ? -- Alexis Murzeau
Bug#925546: How to reproduce?
Hi, On Wed, 17 Apr 2019 15:27:19 +0300 Joonas Kylmälä wrote: > Hi, > > Hilko Bengen: > > I can get rid of the issues by backporting a number of commits from > > github.com/nsf/gocode and will submnit an updated package for > > stretch-proposed-updates. > > Thanks for investigating. > > > Are you able to build .deb packages from source or should I provide a > > binary package for you to test? > > I can build from source. Autoremoval is going to beat this package, so checking any news. I saw on internet that this package still has advantages over alternatives. Did you got something working or need any help ? -- Alexis Murzeau
Bug#926180: scilab: FTBFS on all - New trouble - upstream bugfix release while in freeze
Hi, Le 12/05/2019 à 22:10, Julien Puydt a écrit : > Hi, > > On 12/05/2019 11:46, Alexis Murzeau wrote: > >> I saw that there is a bugfix release 6.0.2 with many fixes [0]. > > I had started to package 6.0.2 on salsa already in february. I was wondering, will such bug-fix upstream release be accepted in buster, now that we are in full freeze ? That bug-fix release seems a welcomed version given the many bugs fixed since 6.0.1, but it is not a small targeted fix release. I'm adding debian-mentors for advice about this. [0] https://help.scilab.org/docs/6.0.2/en_US/CHANGES.html#Bugs_fixed_in_6.0.2 -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F
Bug#926180: scilab: FTBFS on all - New trouble
Le 08/05/2019 à 00:50, Alexis Murzeau a écrit : > Where the working log has a java.lang.IllegalStateException > exception instead. Maybe there is a memory corruption somewhere in > native code that doesn't always cause a jvm crash. > > I fear the crash happen in java code, this stacktrace is not very good :( > > I'm trying to run that command with valgrind, but this is very slow. > Running in valgrind does not help as there are many false positive. As the crash seems to occur in JVM generated code, I think we need a java call stack to be able to see what's wrong. The thread crashing seems to be a java thread (there is only JVM + pthread in the stacktrace). In a sbuild inside a VM without X, I don't reproduce the issue. I have interrupted the build just after the "Building documentation" for en_US step to drop a bash shell, I ran the documentation build in a loop. But I didn't got any crash. I saw that there is a bugfix release 6.0.2 with many fixes [0]. As no one seems to be able to reproduce the issue, I suggest to: - Try to reproduce on the x86-bm-01 machine and retrieve a core dump to dump other thread and run jstack to get the java stacktrace and see what's wrong - Try to build the 6.0.1 version and also the new 6.0.2 version on x86-bm-01 to ensure that the crash is still reproducible with 6.0.1 and if it is fixed with 6.0.2. I didn't find any possible fixed issue in the list of fixed bugs in 6.0.2 that could match our crash without entering in each of them. => So, can anyone access the x86-bm-01 machine to try to reproduce and get a core dump of this crash ? [0] https://help.scilab.org/docs/6.0.2/en_US/CHANGES.html#Bugs_fixed_in_6.0.2 -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#926180: scilab: FTBFS on all - New trouble
Le 03/05/2019 à 18:39, Sylvestre Ledru a écrit : > What about starting a xvfb during the build? > > Does it fix the issue? > > S > > > Le 03/05/2019 à 16:50, Alexis Murzeau a écrit : >> Hi, >> >> Indeed, I tried in a virtual machine: >> - install scilab >> - run `LANG=en_US.UTF-8 LC_ALL=C SCI_DISABLE_TK=1 >> SCI_JAVA_ENABLE_HEADLESS=1 _JAVA_OPTIONS='-Djava.awt.headless=true' >> HOME=/tmp scilab-adv-cli -noatomsautoload -nb -l en_US -nouserstartup -e >> "try xmltojar([],[],'en_US');catch disp(lasterror()); >> exit(-1);end;exit(0);"` >> >> And, while connected via ssh using Putty, I got this: >> ``` >> [snip] >> >> [6]: >> jogamp.opengl.SharedResourceRunner.run(SharedResourceRunner.java:353) >> [7]: java.base/java.lang.Thread.run(Thread.java:834) >> commons module not found. >> graphic_objects module not found. >> ui_data module not found. >> graph module not found. >> history_browser module not found. >> slint module not found. >> coverage module not found. >> ``` >> > Despite having *almost* the same output when calling manually the command line outside of a build context, when I do a sbuild, I do not have errors as x86-bm-01 have. So I think the manual run has unrelated issues to this bug. Actually, the build that doesn't fail (on x86-csail-02) also has the GLException exception (search for "-- Building documentation (en_US) --" in the logs). The difference starts here: ``` A fatal error has been detected by Scilab. Please check your user-defined functions (or external module ones) should they appear in the stack trace. Otherwise you can report a bug on http://bugzilla.scilab.org/ with: * a sample code which reproduces the issue * the result of [a, b] = getdebuginfo() * the following information: [x86-bm-01:08312] Signal: Illegal instruction (4) [x86-bm-01:08312] Signal code: Illegal operand (2) [x86-bm-01:08312] Failing at address: 0x7ff0c87e3dcf Call stack: 1: 0xb2d791 (/usr/lib/jvm/default-java/lib/server/libjvm.so) 2: 0xb222b8 < > (/usr/lib/jvm/default-java/lib/server/libjvm.so) 3: 0x12730 < > (/lib/x86_64-linux-gnu/libpthread.so.0) 4: ??(?) End of stack ``` Where the working log has a java.lang.IllegalStateException exception instead. Maybe there is a memory corruption somewhere in native code that doesn't always cause a jvm crash. I fear the crash happen in java code, this stacktrace is not very good :( I'm trying to run that command with valgrind, but this is very slow. -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#928415: studies
On Sun, 5 May 2019 03:00:04 -0400 Brad Barnett wrote: > > > installing the STUDIES "hotfix" from Mozilla by hand on each one is not > > feasible. > > Not to mention, this requires that other features of Firefox's 'phone > home' framework are turned on, which 'studies' uses. For example, in the > GUI, the 'studies' option is under: > > "Allow Firefox to send technical and interaction data to Mozilla" > > So to get their current fix? One must submit to privacy violations, and > allow Firefox to phone home (even more than it still does). You can install directly the xpi that the studies automatically install when enabled to fix the issue. See here: https://news.ycombinator.com/item?id=19826903 I've tried it and I had to put the xpi http link in a new tab else firefox think it is ycombinator that try to install the addon (despite that you click yourself on the link). But when installed, all addons go re-enabled instantaneously. -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#928415: ,#928417: [firefox] All extensions are disabled
Hi, This bug affect both firefox-esr in Stretch and firefox in testing/unstable. Should they be kept separate ? This bug does not affect packaged extensions within Debian despite some of them having the expired certificate like webext-noscript 10.1.9.6-2 or webext-https-everywhere 2018.8.22-1~deb9u1. -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#926180: scilab: FTBFS on all - New trouble
eFactory.java:518) [1]: jogamp.opengl.SharedResourceRunner.run(SharedResourceRunner.java:353) [2]: java.base/java.lang.Thread.run(Thread.java:834) Caused[0] by GLException: Failed to created/initialize EGL display incl. fallback default: native 0x0, error 0x3001/0x3001 on thread main-SharedResourceRunner [0]: jogamp.opengl.egl.EGLDisplayUtil.eglGetDisplayAndInitialize(EGLDisplayUtil.java:297) [1]: jogamp.opengl.egl.EGLDisplayUtil.access$300(EGLDisplayUtil.java:58) [2]: jogamp.opengl.egl.EGLDisplayUtil$1.eglGetAndInitDisplay(EGLDisplayUtil.java:320) [3]: com.jogamp.nativewindow.egl.EGLGraphicsDevice.open(EGLGraphicsDevice.java:125) [4]: jogamp.opengl.egl.EGLDrawableFactory$SharedResourceImplementation.createEGLSharedResourceImpl(EGLDrawableFactory.java:532) [5]: jogamp.opengl.egl.EGLDrawableFactory$SharedResourceImplementation.createSharedResource(EGLDrawableFactory.java:516) [6]: jogamp.opengl.SharedResourceRunner.run(SharedResourceRunner.java:353) [7]: java.base/java.lang.Thread.run(Thread.java:834) commons module not found. graphic_objects module not found. ui_data module not found. graph module not found. history_browser module not found. slint module not found. coverage module not found. ``` -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#927126: aqemu: after updating can't open VMs
On Mon, 15 Apr 2019 16:55:13 +0530 Abhijith PA wrote: > I recently updated aqemu and ended up in not able to open VMs. > > Following is the message is what I get when I open VMs > > AQEMU Error [264] >>> > Sender: QEMU return value != 0 > Message: > Hi, When you right-click on your VM and choose "Show QEMU Arguments", what are the arguments of qemu ? If you try to run the command directly in a console, does it works ? If not, what's the qemu error ? I tried myself and got errors about the vlan option. This option seems to be deprecated since a long time and removed now. The vlan argument issue has a upstream issues open [0]. [0] : - https://github.com/tobimensch/aqemu/issues/58 - https://github.com/tobimensch/aqemu/issues/57 - https://github.com/tobimensch/aqemu/pull/61 -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#926218: range-v3: FTBFS with gcc 8.3
On Wed, 3 Apr 2019 10:18:35 +0200 Santiago Vila wrote: > On Tue, Apr 02, 2019 at 10:57:39PM +0300, Коля Гурьев wrote: > > Control: forwarded -1 https://github.com/ericniebler/range-v3/issues/856 > > Hi. I believe this one (failure with GCC 9) could be a bit closer: > > https://github.com/ericniebler/range-v3/issues/1033 > > Thanks. > Hi, This issue doesn't seem related to that github issue. I've investigated the cause of the warning inside gcc. (I'm not accustomed to gcc internals so some of my sentences might be imprecise :)) While debugging cc1plus, I found that the warning is caused for this GIMPLE instruction: ``` [../include/range/v3/utility/counted_iterator.hpp:291:18] # VUSE <.MEM_335> _293 = MEM[(long int *)[../test/container_conversion.cpp:48:4] &D.184479 + 8B]; ``` (note that D.184479 number changes every-time I run gcc) The GIMPLE dump can be generated using `-fdump-tree-uninit-vops-lineno`. The dump is somewhat complicated to read but here is my analysis. The warning is triggered by the first statement in container_conversion.hpp [0]. `view::ints | view::take(10)` has the type take_really. It is converted to a std::vector via `operator std::vector` which is implemented as a template inside view_interface [1]. That operator call to_ which end up calling to_container_fn::impl [2] which will itself call std::vector::assign [3] and std::vector::_M_assign_aux [4]. When calling std::vector::assign, to_container_fn::impl create begin and end iterators with range_common_iterator_t [5]. This will create `common_iterator`s which is really a variant with the real underlying iterator (of type counted_iterator) and the sentinel type. Then, when gcc search for uninitialized cases, it find a case when: - the __last iterator is the sentinel - there is a use of the __last iterator as a counted_iterator with an access to its cnt_ field In that case, gcc think the underlying storage of the variant is not initialized as the sentinel is an empty structure which is true. But then the of the cnt_ field is not used later. See here for the GIMPLE dump: [6]. The codepath leading to the uninitialized use of D.184248 imply that iftmp.47_15 != 0. But the codepath leading to a use of the uninitialized value D.184248 require iftmp.47_15 == 0. Indeed, MEM[(long int *)&D.184248 + 8B] is used via _293 and _279 in if conditions in blocks bb 13 and bb 18 which are executed only if iftmp.47_15 == 0. If that's the case, bb 3 would be executed at the start of the function and bb 3 initialize MEM[(struct Head *)&D.167417] (so including initialization of MEM[(long int *)&D.184248 + 8B]). Thus, this maybe-uninitialized warning is a false positive. By search for bugs in gcc about false positive, I found that this is not a rare case. I suggest to make this warning not trigger an error for the build. We could use `-Wno-error=maybe-uninitialized` but cc1plus does not recognize some of the command line arguments and as soon as it print a diagnostic message (the maybe-uninitialized warning), it also print errors about unrecognized arguments. This make the build still fail. Maybe there is a -Wno-error=XXX to make unrecognized command line arguments not an error too. Or we can use `-Wno-maybe-uninitialized` which works but is maybe too much radical. [0] https://sources.debian.org/src/range-v3/0.4.0-1/test/container_conversion.cpp/#L39 [1] https://sources.debian.org/src/range-v3/0.4.0-1/include/range/v3/view_interface.hpp/#L370 [2] https://sources.debian.org/src/range-v3/0.4.0-1/include/range/v3/to_container.hpp/#L147 [3] https://sources.debian.org/src/range-v3/0.4.0-1/include/range/v3/to_container.hpp/#L84 [4] https://github.com/gcc-mirror/gcc/blob/gcc-8_3_0-release/libstdc++-v3/include/bits/vector.tcc#L271 [5] https://sources.debian.org/src/range-v3/0.4.0-1/include/range/v3/to_container.hpp/#L83 [6] https://gist.github.com/amurzeau/ca58f3ebe890371a295d8f2537fa09cc#file-container_conversion-cpp-197t-uninit1-cpp-L230 -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#903514: Deadlock in _dl_close join-ing threads accessing TLS (was Re: gimp won't launch)
Le 31/03/2019 à 22:53, Alexis Murzeau a écrit : > Le 31/03/2019 à 15:19, Aurelien Jarno a écrit : >> This bug is very likely a bug present in old glibc versions. It has been >> brought to light when enabling TLS support in openblas and not by a new >> glibc version. >> >> Right now the bug has been workarounded by disabling TLS support in >> openblas. The way to handle this bug is to write a small testcase that >> can be forwarded upstream. It's not an easy task though. >> > > Hi, > > I've made a test case here [0]. > I've not tested it against latest glibc commit. > But it does reproduce the deadlock with glibc 2.28 on Linux. > > To run the test case, do this: > ``` > gcc test_compiler_tls.c -o test_compiler_tls -ldl -g -pthread > gcc test_compiler_tls_lib.c -shared -o test_compiler_tls_lib.so \ > -g -pthread -fPIC > ./test_compiler_tls ./test_compiler_tls_lib & > gdb --pid $! -ex 'thr a a bt' > ``` > > This reproduce the deadlock that I've found in openblas: > 1- The test_thread open the library which call its constructor > 2- The library's constructor create a thread >`thread_that_use_tls_after_sleep` > 3- The thread `thread_that_use_tls_after_sleep` sleep for 100ms (this >needs to be enough so dl_close is called before the sleep ends) > 3- The test_thread close the library with dl_close > 4- dl_close lock `dl_load_lock` and call the library's destructor > 5- The library's destructor wait `thread_that_use_tls_after_sleep` to >finish > 6- The `thread_that_use_tls_after_sleep` thread try to read the TLS >variable which cause a call to `__tls_get_addr` > 7- `__tls_get_addr` cause a deadlock in `tls_get_addr_tail` trying to >lock the same `dl_load_lock` as dl_close does > 8- Nothing happen because dl_close thread is waiting for the >`thread_that_use_tls_after_sleep` thread to finish which having the >lock and the latter thread try to lock the same lock as dl_close and >so never exit. > > See [1] for the stacktrace. > > Thread 3 is the library's thread created in its constructor and joined > in its destructor. > Thread 2 is the thread that does dl_open and dl_close. > Thread 1 is a "monitoring" thread to implement a timeout of 10s (useful > if this tests need to run on a CI system) > > Where dl_close lock the `dl_load_lock`: [2] > Where tls_get_addr_tail lock the `dl_load_lock`: [3] > > [0]: https://gist.github.com/amurzeau/26f045bdfea407528dd7de3102fb4be7 > [1]: > https://gist.github.com/amurzeau/26f045bdfea407528dd7de3102fb4be7#file-gdb_stacktrace-txt > [2]: https://github.com/bminor/glibc/blob/glibc-2.28/elf/dl-close.c#L812 > [3]: https://github.com/bminor/glibc/blob/glibc-2.28/elf/dl-tls.c#L761 > Related links: https://bugzilla.redhat.com/show_bug.cgi?id=1409899 https://sourceware.org/bugzilla/show_bug.cgi?id=2377 Actually, the hang is caused by a C++ here, but that's the same deadlock (the C++ exception require the `dl_load_lock´ lock). It seems from the first link that using thread stuff in constructor and destructor is risky and not well supported and that applications should just avoid doing this. I didn't find a really related bug in sourceware bugzilla, maybe we should forward our bug to them ? -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#903514: Deadlock in _dl_close join-ing threads accessing TLS (was Re: gimp won't launch)
Le 31/03/2019 à 15:19, Aurelien Jarno a écrit : > This bug is very likely a bug present in old glibc versions. It has been > brought to light when enabling TLS support in openblas and not by a new > glibc version. > > Right now the bug has been workarounded by disabling TLS support in > openblas. The way to handle this bug is to write a small testcase that > can be forwarded upstream. It's not an easy task though. > Hi, I've made a test case here [0]. I've not tested it against latest glibc commit. But it does reproduce the deadlock with glibc 2.28 on Linux. To run the test case, do this: ``` gcc test_compiler_tls.c -o test_compiler_tls -ldl -g -pthread gcc test_compiler_tls_lib.c -shared -o test_compiler_tls_lib.so \ -g -pthread -fPIC ./test_compiler_tls ./test_compiler_tls_lib & gdb --pid $! -ex 'thr a a bt' ``` This reproduce the deadlock that I've found in openblas: 1- The test_thread open the library which call its constructor 2- The library's constructor create a thread `thread_that_use_tls_after_sleep` 3- The thread `thread_that_use_tls_after_sleep` sleep for 100ms (this needs to be enough so dl_close is called before the sleep ends) 3- The test_thread close the library with dl_close 4- dl_close lock `dl_load_lock` and call the library's destructor 5- The library's destructor wait `thread_that_use_tls_after_sleep` to finish 6- The `thread_that_use_tls_after_sleep` thread try to read the TLS variable which cause a call to `__tls_get_addr` 7- `__tls_get_addr` cause a deadlock in `tls_get_addr_tail` trying to lock the same `dl_load_lock` as dl_close does 8- Nothing happen because dl_close thread is waiting for the `thread_that_use_tls_after_sleep` thread to finish which having the lock and the latter thread try to lock the same lock as dl_close and so never exit. See [1] for the stacktrace. Thread 3 is the library's thread created in its constructor and joined in its destructor. Thread 2 is the thread that does dl_open and dl_close. Thread 1 is a "monitoring" thread to implement a timeout of 10s (useful if this tests need to run on a CI system) Where dl_close lock the `dl_load_lock`: [2] Where tls_get_addr_tail lock the `dl_load_lock`: [3] [0]: https://gist.github.com/amurzeau/26f045bdfea407528dd7de3102fb4be7 [1]: https://gist.github.com/amurzeau/26f045bdfea407528dd7de3102fb4be7#file-gdb_stacktrace-txt [2]: https://github.com/bminor/glibc/blob/glibc-2.28/elf/dl-close.c#L812 [3]: https://github.com/bminor/glibc/blob/glibc-2.28/elf/dl-tls.c#L761 -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#903514: Deadlock in _dl_close join-ing threads accessing TLS (was Re: gimp won't launch)
Hi, On 07/09/2018 16:57, Sébastien Villemot wrote: > > I have just uploaded openblas 0.3.3+ds-1, which has TLS disabled. > > I think this should fix the original issue, i.e. the gimp+openblas > deadlock. Please let me know if this is not the case. > > Best, > Thanks for your update. I tried to start gimp with this openblas version installed and it did not crashed or hanged. But there's still a possible crash that can occur, when I do a test that does dl_open followed by dl_close of libopenblas, I get a segfault when stopping the thread that does the dl_open/dl_close. This crash doesn't seem to cause issues to gimp but might on some machines (maybe no threads are used by gimp when indirectly loading openblas and so the crash doesn't occur, but not sure at all). More extensive information here: [0]. If no one object that gimp doesn't crash anymore with that 3.3 version, maybe this bug can be closed (letting the crash of the dl_open/dl_close test be handled by upstream only [0]). [0] https://github.com/xianyi/OpenBLAS/issues/1720#issuecomment-418538099 -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#903514: Deadlock in _dl_close join-ing threads accessing TLS (was Re: gimp won't launch)
severity 903514 important thanks > Reassigning to glibc with affects on openblas and gimp as this is caused > by a deadlock inside glibc. Done. Lowering severity as this does not render any package unusable by themselves, but only a combination of them (GIMP + OpenBLAS). I think a workaround solution against GIMP OpenBLAS should be done as I'm not sure a good solution will emerge in glibc given attempts done in the past. The work to be done seems non trivial. My though on possible solutions: * Add a breaks between GIMP and OpenBLAS * Disable TLS in OpenBLAS build (if possible, but this would cause a performance loss for users that use OpenBLAS without gimp) * Add a delay in GIMP to not load then close libraries too fast (so OpenBLAS threads are fully initialized when dl_close is called on it) -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#903514: gimp won't launch
Hi, On Fri, 3 Aug 2018 22:53:08 -0400 James Van Zandt wrote: > Thanks, Benedict - the same solution worked for me. > > Specifically: > >sudo apt-get install libopenblas-base- libopenblas-dev- \ > libblas3 liblapack3 libblas-dev liblapack-dev > > Unfortunately julia and libjulia0.6 were also removed here, since they > depend on libopenblas-base. I intend to report this as a bug, and request > that they depend instead on the virtual packages libblas.so.3 and > liblapack.so.3 (which can also be provided by liblapack3 and libblas3, > resp.). After checking what could cause gimp issues, I found that on my machine, gimp almost always hang showing nothing (no splashscreen) when libopenblas-base is installed. Using gdb to find where it hung (gimp-gdb.txt) gives threads waiting on a lock while doing thread-local related stuff and the main thread is in the process of dl_close-ing openblas waiting the threads to exit using pthread_join. It seems that the lock used in `tls_get_addr_tail` [0] is the same as the one locked by _dl_close [1]. A recursive lock is used but here it does not help as the thread calling `tls_get_addr_tail` and `_dl_close` are not the same. This deadlock may not happen everytime, in my case, the openblas threads are still initializing while dl_close is called. Given this, I think the offending commit in openblas is bf40f806 [2] which add TLS variables to avoid locking. But many change were done since then. One of related bug report is [3] which seems to indicate that the locks handling is not easy inside glibc. There were an attempt to fix deadlocks between tls_get_addr and a dlclose of a module whose finalizer joins with that thread [4]. So I see these possibles solutions: * Add a breaks between gimp and openblas * Disable TLS in openblas build (if possible, but this would cause a performance loss for users that use openblas without gimp) * Patch glibc to not deadlock (but this seems not easy to do at all) Also, this deadlock might not be the only cause of issues encountered in this bug report. Reassigning to glibc with affects on openblas and gimp as this is caused by a deadlock inside glibc. [0] https://github.com/bminor/glibc/blob/glibc-2.27/elf/dl-tls.c#L761 [1] https://github.com/bminor/glibc/blob/glibc-2.27/elf/dl-close.c#L812 [2] https://github.com/xianyi/OpenBLAS/commit/bf40f806efa55c7a7c7ec57535919598eaeb569d#diff-31f8d4e8863583d95bf2f9529f83844e [4] https://sourceware.org/ml/libc-alpha/2015-06/msg00062.html -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F (gdb) thr a a bt Thread 4 (Thread 0x7f727a990700 (LWP 26238)): #0 0x7f7283ad711c in __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 #1 0x7f7283ad06c6 in __GI___pthread_mutex_lock (mutex=0x7f7287775968 <_rtld_global+2312>) at ../nptl/pthread_mutex_lock.c:113 #2 0x7f728775e5b7 in tls_get_addr_tail (ti=0x7f7278c2fc70, dtv=0x55edf85706b0, the_map=0x55edf8567980) at ../elf/dl-tls.c:761 #3 0x7f7287764288 in __tls_get_addr () at ../sysdeps/x86_64/tls_get_addr.S:55 #4 0x7f7276d86400 in get_memory_table () at memory.c:1147 #5 0x7f7276d86400 in blas_memory_alloc (procpos=procpos@entry=2) at memory.c:1147 #6 0x7f7276d86bbb in blas_thread_server (arg=0x2) at blas_server.c:297 #7 0x7f7283acdf2a in start_thread (arg=0x7f727a990700) at pthread_create.c:463 #8 0x7f7283a00edf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 3 (Thread 0x7f727b191700 (LWP 26237)): #0 0x7f7283ad711c in __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 #1 0x7f7283ad06c6 in __GI___pthread_mutex_lock (mutex=0x7f7287775968 <_rtld_global+2312>) at ../nptl/pthread_mutex_lock.c:113 #2 0x7f728775e5b7 in tls_get_addr_tail (ti=0x7f7278c2fc70, dtv=0x55edf85704b0, the_map=0x55edf8567980) at ../elf/dl-tls.c:761 #3 0x7f7287764288 in __tls_get_addr () at ../sysdeps/x86_64/tls_get_addr.S:55 #4 0x7f7276d86400 in get_memory_table () at memory.c:1147 #5 0x7f7276d86400 in blas_memory_alloc (procpos=procpos@entry=2) at memory.c:1147 #6 0x7f7276d86bbb in blas_thread_server (arg=0x1) at blas_server.c:297 #7 0x7f7283acdf2a in start_thread (arg=0x7f727b191700) at pthread_create.c:463 #8 0x7f7283a00edf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 2 (Thread 0x7f727b992700 (LWP 26236)): #0 0x7f7283ad711c in __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 #1 0x7f7283ad06c6 in __GI___pthread_mutex_lock (mutex=0x7f7287775968 <_rtld_global+2312>) at ../nptl/pthread_mutex_lock.c:113 #2 0x7f728775e5b7 in tls_get_addr_tail (ti=0x7f7278c2fc70, dtv=0x55edf8556c10, the_map=0x55edf8567980) at ../elf/dl-tls.c:761 #3 0x7f7287764288 in __tls_get_addr () at ../sysdeps/x86_64/tls_get_addr.S:55 #4 0x7f7276d86400 in get_memo
Bug#891180: efibootmgr: grub uefi fails to boot
Hi, On Fri, 23 Feb 2018 11:00:35 +0530 Ritesh Raj Sarraf wrote: > Package: efibootmgr > Version: 15-1 > Severity: grave > Justification: renders package unusable > > I upgraded to Unstable today and it resulted in my machine being > unbootable. I had to resort to Legacy Boot mode to work around it. > Does [0] help ? The linked procedure is: # mount -t efivarfs efivarfs /sys/firmware/efi/efivars # rm /sys/firmware/efi/efivars/dump-* Then reinstall grub (adapt to your installation): # update-grub # grub-install -v --target=x86_64-efi --recheck /dev/sda [0] https://unix.stackexchange.com/q/379774 -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F
Bug#899124: fa-solid-900.ttf symlinked as fontawesome-webfont.ttf
Hi, Le 27/06/2018 à 00:21, Alexis Murzeau a écrit : > Le 26/06/2018 à 04:13, vasudev-debian a écrit : >> I'll have a look. if possible clone from team repo and raise a pr on it. >> > > I've created 3 PR at [0], one for each branch (in this order: upstream, > pristine-tar and master). > The 5.0.10+really4.7.0~dfsg orig tar I imported is the same as the one > used for 4.7.0~dfsg. > Debian/watch file tracks the v4 branch (ignoring v5.*) > I've also added a autopkgtest test to ensure symlinks are not broken. > > [0] https://salsa.debian.org/fonts-team/fonts-font-awesome/merge_requests > > Le 26/06/2018 à 09:26, Sean Whitton a écrit : >> >> The git history is up to you but resetting the changelog seems like a >> really bad idea -- it is confusing to see that there are uploads to the >> archive that are not present in the changelog. >> >> I think you should at least retain d/changelog, even if you reset >> everything else (personally, I would keep all the git history). >> > > I finally kept the full changelog and git history, to not lie the past > :) if someone wonders what happened. > Thanks for your advices. > Vasudev, did you get a chance to take a look to the merge requests [0] ? [0] https://salsa.debian.org/fonts-team/fonts-font-awesome/merge_requests -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#899124: fa-solid-900.ttf symlinked as fontawesome-webfont.ttf
Le 26/06/2018 à 04:13, vasudev-debian a écrit : > I'll have a look. if possible clone from team repo and raise a pr on it. > I've created 3 PR at [0], one for each branch (in this order: upstream, pristine-tar and master). The 5.0.10+really4.7.0~dfsg orig tar I imported is the same as the one used for 4.7.0~dfsg. Debian/watch file tracks the v4 branch (ignoring v5.*) I've also added a autopkgtest test to ensure symlinks are not broken. [0] https://salsa.debian.org/fonts-team/fonts-font-awesome/merge_requests Le 26/06/2018 à 09:26, Sean Whitton a écrit : > > The git history is up to you but resetting the changelog seems like a > really bad idea -- it is confusing to see that there are uploads to the > archive that are not present in the changelog. > > I think you should at least retain d/changelog, even if you reset > everything else (personally, I would keep all the git history). > I finally kept the full changelog and git history, to not lie the past :) if someone wonders what happened. Thanks for your advices. -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#899124: fa-solid-900.ttf symlinked as fontawesome-webfont.ttf
Le 25/06/2018 à 13:21, Alexis Murzeau a écrit : > On June 25, 2018 12:44:47 PM GMT+02:00, Sean Whitton > wrote: >> Hello, >> >> On Sun, Jun 24 2018, Alexis Murzeau wrote: >> >>> So this would mean: >>> - revert the fonts-font-awesome package in unstable to 4.7.0~dfsg-3 >> >> Just to not that due to a change the next release of Debian Policy this >> should /not/ be done by means of an epoch. You should use the +really >> convention. > > Ok but then all future versions of fonts-font-awesome v4 will require +really > as the v5 will be in a different package. > I'm ok with +really though as there should not have many future version > anyway. > > Thanks for your advice :) > I've updated my personal repo [0] to use the version 5.0.10+really4.7.0~dfsg-1. I've reset the changelog and everything to debian/4.7.0~dfsg-3 tag and then cherry-picking relevant commits in 5.0.10-x: * Change maintainer email address to debian-fonts@l.d.o. * Drop Friendica Maintainers team from uploaders list. * Mark package compliance with Debian policy 4.1.4. * Use salsa URL in Vcs-* fields. And then update the package version and watch file. I've branched out from the debian/4.7.0_dfsg-3 tag but that's a non forward master branch move. I'm not sure how to handle this here, but v5 related change don't seems relevant for the v4 package to me as everything is just reverted. [0] https://salsa.debian.org/amurzeau-guest/fonts-font-awesome-4 -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#899124: fa-solid-900.ttf symlinked as fontawesome-webfont.ttf
On June 25, 2018 12:44:47 PM GMT+02:00, Sean Whitton wrote: >Hello, > >On Sun, Jun 24 2018, Alexis Murzeau wrote: > >> So this would mean: >> - revert the fonts-font-awesome package in unstable to 4.7.0~dfsg-3 > >Just to not that due to a change the next release of Debian Policy this >should /not/ be done by means of an epoch. You should use the +really >convention. Ok but then all future versions of fonts-font-awesome v4 will require +really as the v5 will be in a different package. I'm ok with +really though as there should not have many future version anyway. Thanks for your advice :) > >Thanks! Hi -- Alexis Murzeau
Bug#899124: fa-solid-900.ttf symlinked as fontawesome-webfont.ttf
Hi, Le 23/06/2018 à 08:11, Vasudev Kamath a écrit : > Hi Alexis, Thomas, > > First of all I apologise for not replying in time. I'm bit occupied by > family work so not getting enough time to deal with package. That's fine no worries :) I actually asked you directly because I don't want changes to happen on your package without your consent or even be unaware of it, that would be bad. > > Alexis Murzeau writes: > >>> >>> I also would like to highlight that what you're describing here is the >>> workflow of a transition, which is what Debian has been doing for >>> *years*. Not only this is natural in Debian, but it is also very much >>> recommended when breakage occurs. >>> >>> I'm by the way a bit frustrated that this process is taking so long. >>> This has a huge impact in the maintenance of a big dozen of my packages, >>> since Horizon can't be installed. Reverting is really not a lot of work. >>> Can we get this done soon, as it seems to be the consensus? If the >>> current font-awesome maintainer is busy, maybe someone else (me?) can do >>> the work? > > Yes I agree that I should have followed usual transition process but I > did not imagine a font package breaking things in this manner. Of course > its not an excuse but I should have been careful, but what is done is > done now. > >> >> @Vasudev, what do you think about this ? >> >> (As far as I'm concerned, I'm ok with this and Thomas said it shouldn't >> be a lot of work to do.) > > I've created basic package at ¹. If you or Thomas can adjust the package > as needed and upload it to archive it would be great. Also please > consider adding yourself as uploader as I might not have energy to > maintain additional package. > > ¹ https://salsa.debian.org/fonts-team/fonts-font-awesomev4 Thanks. I think I can help maintaining these packages (v4 and v5) as streamlink uses them but I'm not a DM (nor a DD). I think the best is to keep the old source and binary package name fonts-font-awesome for the old version (v4) and use a new one fonts-font-awesome-5 for the new version. So following best practice [0] for what would be a "backward incompatible ABI change which prevents old programs from working with the new library" for a library. So changing the font path to include "-5" and the package name accordingly. So this would mean: - revert the fonts-font-awesome package in unstable to 4.7.0~dfsg-3 - either: - Clone fonts-font-awesome to fonts-font-awesomev4 then reverting all branches and tags to v4.7.0~dfsg-3 in fonts-font-awesomev4 - Or clone fonts-font-awesome to another repository fonts-font-awesome-5 (to match the source package name) and reset branches and tags in the fonts-font-awesome repository to v4.7.0~dfsg-3. My personal thought on repository naming is that its better to have fonts-font-awesome (4.7.0~dfsg-3) and fonts-font-awesome-5 (5.0.10-4) to match source package names. The debian/watch file for fonts-font-awesome (v4) then need to change to ".*/v(4\.\d.*)"[...] to stick with v4. I've made change in forks at [1] and [2]. Also, I think some changes can be reverted to remove support of v4 in v5 package. Possibly, reopen bugs that were closed since fonts-font-awesome v5 and reassign newer ones applying to v5 to the new package fonts-font-awesome-5. As a side node, I see that font awesome 5 upstream git is in fact the build result, not the sources (see [4]). But its still free, using CC BY 4.0 for icons, SIL OFL 1.1 for fonts and MIT for anything else (see [3]). The DFSG requires to have the source code. Does this mean fonts-font-awesome-5 cannot be handled the same way as before, ie outside of main ? Not sure as this is not strictly compiled-only and there are scss, less and non minified js files. [0] https://wiki.debian.org/TransitionBestPractices [1] https://salsa.debian.org/amurzeau-guest/fonts-font-awesome-4 [2] https://salsa.debian.org/amurzeau-guest/fonts-font-awesome-5 [3] https://fontawesome.com/license [4] https://github.com/FortAwesome/Font-Awesome/issues/12199#issuecomment-363168281 -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#899124: fa-solid-900.ttf symlinked as fontawesome-webfont.ttf
Hi, Le 17/06/2018 à 09:31, Thomas Goirand a écrit : > On 06/16/2018 03:57 PM, Alexis Murzeau wrote: >> On Tue, 5 Jun 2018 13:31:48 +0100 Sean Whitton >> wrote: >>> Hello Vasudev, >>> >>> On Sat, Jun 02, 2018 at 05:16:05PM +0530, Vasudev Kamath wrote: >>>> >>>> I read through and prepared a version to experimental which symlinks >>>> fa-solid-900.ttf as fontawesome-webfont.ttf. I've uploaded it to >>>> experimental, can you please check if this helps?. >>>> >>>> @Others Please let me know if this new version in experimental with >>>> suggestion from Thomas improves situation in your cases. >>> >>> This does not help the mkdocs-bootstrap case. That appears to need the >>> .woff2 font. >>> >>> -- >>> Sean Whitton >> >> Hi, >> >> This and openstack-dashboard install failure require more symlinks and >> files from v4. >> >> Isn't reverting the package to v4 while creating a new one for the >> version 5 (say fonts-font-awesome-5) better to handle all these v4/5 >> breaks ? > > I agree, also because even with the symlinks, there would be still 4 > missing glyphs in the openstack-dashboard (I tried and survey it). > Though, I could probably find replacements in fa-solid-900, it'd be > nicer to just not break things. > >> I'm not sure it is a good solution trying to patch fonts-font-awesome v5 >> to be compatible with v4 while upstream might continue to even more >> break things with v4 later. >> >> Subsequent maintenance on the v4 package should not require much work as >> upstream says they don't plan any further versions on the v4 branch [1]: > > I agree. > >> So this v4 package would be dropped once other packages move to >> fonts-font-awesome-5 with proper upgrade path (ie. without hacks to fake >> v4 with v5). Especially packages that use sphinx RTD theme where >> upstream still use v4 and it seems many packages actually have a >> theme.css based on that theme. >> >> I myself tried to patch theme.css to use fonts-font-awesome 5 shim but >> its a ugly big approximate patch that happen to mostly work :( [2] >> >> What do you think about this ? > > I also would like to highlight that what you're describing here is the > workflow of a transition, which is what Debian has been doing for > *years*. Not only this is natural in Debian, but it is also very much > recommended when breakage occurs. > > I'm by the way a bit frustrated that this process is taking so long. > This has a huge impact in the maintenance of a big dozen of my packages, > since Horizon can't be installed. Reverting is really not a lot of work. > Can we get this done soon, as it seems to be the consensus? If the > current font-awesome maintainer is busy, maybe someone else (me?) can do > the work? @Vasudev, what do you think about this ? (As far as I'm concerned, I'm ok with this and Thomas said it shouldn't be a lot of work to do.) > > Cheers, > > Thomas Goirand (zigo) > -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#899124: fa-solid-900.ttf symlinked as fontawesome-webfont.ttf
On Tue, 5 Jun 2018 13:31:48 +0100 Sean Whitton wrote: > Hello Vasudev, > > On Sat, Jun 02, 2018 at 05:16:05PM +0530, Vasudev Kamath wrote: > > > > I read through and prepared a version to experimental which symlinks > > fa-solid-900.ttf as fontawesome-webfont.ttf. I've uploaded it to > > experimental, can you please check if this helps?. > > > > @Others Please let me know if this new version in experimental with > > suggestion from Thomas improves situation in your cases. > > This does not help the mkdocs-bootstrap case. That appears to need the > .woff2 font. > > -- > Sean Whitton Hi, This and openstack-dashboard install failure require more symlinks and files from v4. Isn't reverting the package to v4 while creating a new one for the version 5 (say fonts-font-awesome-5) better to handle all these v4/5 breaks ? I'm not sure it is a good solution trying to patch fonts-font-awesome v5 to be compatible with v4 while upstream might continue to even more break things with v4 later. Subsequent maintenance on the v4 package should not require much work as upstream says they don't plan any further versions on the v4 branch [1]: `Now that Font Awesome 5 has been released we are marking version 4 as end-of-life. We don't plan on releasing any further versions of the 4.x or 3.x.` So this v4 package would be dropped once other packages move to fonts-font-awesome-5 with proper upgrade path (ie. without hacks to fake v4 with v5). Especially packages that use sphinx RTD theme where upstream still use v4 and it seems many packages actually have a theme.css based on that theme. I myself tried to patch theme.css to use fonts-font-awesome 5 shim but its a ugly big approximate patch that happen to mostly work :( [2] What do you think about this ? [1] https://github.com/FortAwesome/Font-Awesome#where-did-font-awesome-4-or-3-go [2] https://github.com/amurzeau/streamlink-debian/blob/master/debian/patches/0006-Use-font-awesome-5-shim.patch -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#898501: Bug#899124: fonts-font-awesome: completely breaks web applications, with no notice
close 898501 5.0.10-3 thanks Hi, I'm re-closing #898501: Broken symlinks as they are indeed fixed now and to keep only one bug open (#899124) about the incompatibilities caused by version 5. -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#899124: fonts-font-awesome: completely breaks web applications, with no notice
unmerge 899124 thanks Hi, I'm maintaining streamlink which use a custom rtd sphinx theme which use fonts-font-awesome v4. I'm unmerging this bug from xxx because there is a major incompatibility changes in font-awesome 5. The font file got split in solid, regular and brands fonts, and thus there is no drop in replacement for the old fontawesome-webfont.xxx. Many packages use hard-coded path to the old fonts (fontawesome-webfont.xxx) because they reference them from their .css theme. According to [1], there are 26 probably affected source packages. Some packages embed font-awesome directly instead of symlinking to fonts-font-awesome, which might be a solution for most affected packages, albeit duplicating the font (which is a bit against the purpose of this package). Having a separate package for fonts-font-awesome could let maintainers use font-awesome 4 until upstream changes for font-awesome 5. This package would be probably have little change over time as upstream does not intend to update the v4 branch anymore [4]. This would provide a solution avoiding simply duplicating old fontawesome-webfont v4 files in packages that use them. As a side note, depending on the font usage by packages, using fa-solid-900 as fontawesome-webfont can fix most basic glyphs, but that's not an ideal solution, mixing v4 css and js with v5 font. [1] Here is an analysis of font-awesome usage across sid packages from [3]: Packages embedding a copy of font-awesome: - boinc 7.10.2+dfsg-1: embedded copy of 4.6.3 - cockpit 168-1: embedded copy of 4.2.0 - controlsfx 8.40.14-1: embedded copy of 4.7.0 - copyq 3.1.2-1: embedded copy of 4.7.0 - coz-profiler 0.1.0-2: embedded copy of 4.7 - crmsh 3.0.1-4: embedded copy of 4.0.3 - fontawesomefx 8.9-1: embedded copy of 4.4.1 - golang-github-smartystreets-goconvey 1.6.1-3: embedded copy of 4.5 - hugo 0.40.3-1: embedded copy of 4.4.1 - jekyll 3.1.6+dfsg-3: embedded copy of 4.4.0 - mitmproxy 3.0.3-1: embedded copy of 4.2.0 and 4.0.3 (first mitmproxy itself and the later for onboardingapp plugin) - mongodb 1:3.4.14-3: embedded copy in base64 - nghttp2 1.32.0-1: embedded copy of 4.2.0 - opennebula 4.12.3+dfsg-3.1: embedded copy of 4.3.0 - pgbadger 9.2-1: embedded copy of 3.2 - publican 4.3.2-2: embedded copy of 4.2.0 - python-mne 0.15.2+dfsg-2: embedded copy of 4.7.0 - python-openstackdocstheme 1.18.1-3: embedded copy of 4.7.0 - python-xstatic-font-awesome 4.7.0.0-4: embedded copy of 4.7 - rclone 1.41-1: embedded copy of 4.6.3 - spdylay 1.3.2-2.1: embedded copy of 4.0.2 - sympa 6.2.32~dfsg-1: embedded copy of 4.3.0 - wims 1:4.15b~dfsg1-11: embedded copy of 4.7.0 - zeal / 1:0.4.0-2: embedded copy Packages symlinking to fonts-font-awesome files: - cantata 2.3.0.ds1-1: symlink to fonts - djangorestframework 3.8.2-1: symlink to fonts - glewlwyd 1.3.1-1: embedded copy of 4.7 replaced with symlink to fonts in override_dh_install-indep - grafana 2.6.0+dfsg-3: symlink to fonts and css - grr 3.1.0.2+dfsg-5: symlink to fonts - hyperkitty 1.1.4-4: symlink to fonts - julia 0.4.7-7: symlink to fonts - lightbeam 1.3.1+dfsg-1: symlink to fonts and css - mkdocs-bootstrap 0.1.1-3: symlink to fonts - mkdocs-bootswatch 0.4.0-3: symlink to fonts - netdata 1.10.0+dfsg-1: symlink to fonts and css - ntopng 3.2+dfsg1-1: symlink to fonts, css, less, scss - oca-core 11.0.20180420-1: symlink to fonts - phabricator 0~git20180509-2: symlink to fonts - plasma-applet-redshift-control 1.0.18-2: symlink to fonts - prewikka 4.1.5-2: symlink to fonts and css - python-qtawesome 0.4.4+ds1-1: symlink to fonts - r-cran-rmarkdown 1.9+dfsg-2: symlink to fonts and css - r-cran-shiny 1.0.5+dfsg-4: symlink to fonts and css - ruby-font-awesome-rails 4.7.0.2-1: symlink to fonts - rustc 1.25.0+dfsg1-2: symlink to fonts and css - sphinx-rtd-theme 0.2.4-1: symlink to fonts - streamlink 0.12.1+dfsg-1: symlink to fonts - tulip 4.8.0dfsg-2: symlink to fonts - ublock-origin 1.13.8+dfsg-1: symlink to fonts - webdeveloper 1.2.13-1: symlink to fonts [2] https://github.com/rtfd/sphinx_rtd_theme/issues/266 [3] https://codesearch.debian.net/search?q=fontawesome-webfont [4] https://github.com/FortAwesome/Font-Awesome#where-did-font-awesome-4-or-3-go -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#815125: Boot failure with Debian linux 4.4.2 package
2016-03-08 22:48 GMT+01:00 Scott Ashcroft : > The patch makes no difference. > Is there anything else I can do to help figure this out? You can use the kernel command line "earlyprintk=efi,keep". This way the kernel will print messages to see what's going on (and maybe a traceback in case of crash).
Bug#815125: Boot failure with Debian linux 4.4.2 package
2016-03-04 14:07 GMT+01:00 Matt Fleming :
>
> It must have been a herculean effort to take photos of the screen
> while the buggy kernel booted. Thank you!
>
> I'm not really seeing anything jumping out as obviously wrong apart
> from the fact that we don't have all of EFI_CONVENTIONAL_MEMORY mapped
> in the buggy kernel.
>
> Could you try this patch?
>
> ---
>
> diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
> index 49e4dd4a1f58..f5e77d240ff1 100644
> --- a/arch/x86/platform/efi/efi_64.c
> +++ b/arch/x86/platform/efi/efi_64.c
> @@ -241,15 +241,6 @@ int __init efi_setup_page_tables(unsigned long
> pa_memmap, unsigned num_pages)
> efi_scratch.use_pgd = true;
>
> /*
> -* When making calls to the firmware everything needs to be 1:1
> -* mapped and addressable with 32-bit pointers. Map the kernel
> -* text and allocate a new stack because we can't rely on the
> -* stack pointer being < 4GB.
> -*/
> - if (!IS_ENABLED(CONFIG_EFI_MIXED))
> - return 0;
> -
> - /*
> * Map all of RAM so that we can access arguments in the 1:1
> * mapping when making EFI runtime calls.
> */
> @@ -268,6 +259,15 @@ int __init efi_setup_page_tables(unsigned long
> pa_memmap, unsigned num_pages)
> }
> }
>
> + /*
> +* When making calls to the firmware everything needs to be 1:1
> +* mapped and addressable with 32-bit pointers. Map the kernel
> +* text and allocate a new stack because we can't rely on the
> +* stack pointer being < 4GB.
> +*/
> + if (!IS_ENABLED(CONFIG_EFI_MIXED))
> + return 0;
> +
> page = alloc_page(GFP_KERNEL|__GFP_DMA32);
> if (!page)
> panic("Unable to allocate EFI runtime stack < 4GB\n");
Thanks for you suggestion.
Unfortunately, this patch doesn't make it works, the crash still
occurs (at the same RIP and traceback).
Using /dev/mem on a running system (with kernel 4.3), the memory
around RIP (0xaa9462ee) is :
aa9462d0 sub rsp,0x28
aa9462d4 lea rdx,[rip+0x2445] # 0xaa948720
aa9462db mov ecx,0x4
aa9462e0 call func_aa9447c0 ; call to ConvertPointer(4, & 0xaa948720)
aa9462e5 mov r11,QWORD PTR [rip+0x2434] # 0xaa948720
aa9462ec xor eax,eax
aa9462ee mov BYTE PTR [r11+0x1],0x1
aa9462f3 add rsp,0x28
aa9462f7 ret
The QWORD at address 0xaa948720 is 0 though on the running system.
I will try to investigate more but I'm open to any printk / patch tests.
Alexis Murzeau
