You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
(7) |
Apr
|
May
|
Jun
(4) |
Jul
(2) |
Aug
(4) |
Sep
|
Oct
(1) |
Nov
(5) |
Dec
(6) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(2) |
Feb
(1) |
Mar
(1) |
Apr
(3) |
May
(5) |
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
(3) |
Dec
|
2005 |
Jan
|
Feb
|
Mar
(2) |
Apr
(22) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(7) |
Sep
(2) |
Oct
(2) |
Nov
(18) |
Dec
(20) |
2007 |
Jan
|
Feb
(2) |
Mar
(2) |
Apr
(6) |
May
(1) |
Jun
(2) |
Jul
|
Aug
(1) |
Sep
(9) |
Oct
|
Nov
|
Dec
|
2008 |
Jan
(13) |
Feb
(4) |
Mar
(3) |
Apr
(8) |
May
(1) |
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(5) |
2010 |
Jan
(4) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(8) |
Oct
|
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
(38) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(17) |
Oct
(6) |
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
(3) |
2017 |
Jan
(12) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
2018 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
(3) |
Aug
(1) |
Sep
(4) |
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
(8) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
(2) |
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
2024 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Rafael L. <ra...@de...> - 2024-01-30 14:26:12
|
Dear XMDS developers, The xmds2 package fails to build from source in the experimental distribution of Debian, in which Python has version 3.12: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061766 Indeed, the imp module, which was deprecated since version 3.4 of Python, has been removed in version 3.12. The patch attached to this message fixes the problem for me. Apparently, imp.new_module() and types.ModuleType() have the same effect, so the patch replaces the former by the latter. With this patch, XMDS builds and all tests pass, against both versions 3.11 and 3.12 of Python. Best regards, Rafael Laboissière |
From: Rafael L. <ra...@de...> - 2023-10-14 07:17:53
|
Hello, Here is an update of the situation: a new version of the h5py package (3.9.0-4) has been uploaded to Debian unstable. In this version, h5py/__init__.py has been updated in order to enable fallback mechanism both ways: if h5py-serial is not installed then load h5py-mpi in serial jobs; if h5py-mpi is not installed than load h5py-serial in MPI jobs. This fixes the issues that arose regarding the building of the xmds2 package in Debian. A new version of the package (3.1.0+dfsg2-7) has been uploaded to unstable. This version has minimalistic (build-)dependencies on libhdf5-dev an python3-h5py (without explicit specification of serial vs. mpi variants). In sum, this was a Debian-specific issue and there is nothing to do at the upstream side. Best, Rafael Laboissière * Rafael Laboissière <ra...@de...> [2023-10-13 09:03]: > Thanks for your reply and clarifications, Mattias. > > You are right, everything works fine with only python3-h5py-serial as > the dependency. I do not remember the circumstances that lead to the > failure due to the lack of the MPI version of h5py. > > We are further investigating the issue and will eventually revert some > recent changes in the Debian xmds2 package, in order to simplify the > dependencies. > > Best, > > Rafael > > * Mattias Johnsson <mat...@mq...> [2023-10-12 02:54]: > >> Hi Rafael, >> >> I'm not that familiar with the test suite, but I can see no reason >> why it should need the MPI version of h5py. In fact, I see I've only >> got the python3-h5py-serial package installed on my machine, and >> everything seems fine. >> >> My understanding is that while MPI may be used for the simulation, >> the end result is a set of data files that are then processed >> serially using the xsil2graphics2 command, which is what uses the >> XSILFile.py code. >> >> That's certainly how end users will use it outside of the test suite anyway. >> >> Could you help me by explaining what tests are demanding the MPI >> version of h5py, and whether they would still be fine if they used >> the serial version instead? If this issue can be fixed simply by >> having XMDS2 only depend on python3-h5py-serial, that would seem to >> be the easiest solution. >> >> Regards, Mattias >> >> ________________________________ From: Rafael Laboissière >> <ra...@de...> Sent: Thursday, 12 October 2023 7:19 AM To: XMDS >> devel list <xmd...@li...> Cc: Nilesh Patra >> <ni...@ri...>; Drew Parsons <dpa...@de...> Subject: >> [xmds-devel] XMDS and h5py serial vs. mpi >> >> Dear XMDS developers, >> >> For some context in what follows, please see Bug#1053314, filed >> against the xmds2 package of the Debian distribution. >> https://bugs.debian.org/1053314<https://bugs.debian.org/1053314> >> >> This “bug” was caused by recent changes in the packaging for the >> h5py module for Python in Debian, as regards the serial and mpi >> variants. You can find more context on this here: https://salsa.debian.org/science-team/h5py/-/blob/master/debian/README.Debian<https://salsa.debian.org/science-team/h5py/-/blob/master/debian/README.Debian> >> >> Apparently, some of the tests in the unit tests suite of XMDS needs >> the MPI (not serial) version of h5py. Since h5py is accessed through >> the generic API in XSILFile.py, it may happen that the serial >> version h5py is used, instead of the MPI version. In order to “fix” >> the problem, I introduced the following patch to the xmds2 Debian >> package: https://salsa.debian.org/science-team/xmds2/-/blob/master/debian/patches/h5py-always-use-mpi.patch<https://salsa.debian.org/science-team/xmds2/-/blob/master/debian/patches/h5py-always-use-mpi.patch> >> >> The question we are asking ourselves regards the intentions of the >> XMDS upstream developers with h5py and MPI. >> >> I am adding Drew Parsons and Nilesh Patra in Cc to this message. >> They might wish to correct some of my assertions above or add >> comments on the issue. >> >> Best, >> >> Rafael Laboissière >> >> >> _______________________________________________ xmds-devel mailing >> list xmd...@li... https://lists.sourceforge.net/lists/listinfo/xmds-devel<https://lists.sourceforge.net/lists/listinfo/xmds-devel> > |
From: Rafael L. <ra...@de...> - 2023-10-13 07:03:39
|
Thanks for your reply and clarifications, Mattias. You are right, everything works fine with only python3-h5py-serial as the dependency. I do not remember the circumstances that lead to the failure due to the lack of the MPI version of h5py. We are further investigating the issue and will eventually revert some recent changes in the Debian xmds2 package, in order to simplify the dependencies. Best, Rafael * Mattias Johnsson <mat...@mq...> [2023-10-12 02:54]: > Hi Rafael, > > I'm not that familiar with the test suite, but I can see no reason why > it should need the MPI version of h5py. In fact, I see I've only got > the python3-h5py-serial package installed on my machine, and everything > seems fine. > > My understanding is that while MPI may be used for the simulation, the > end result is a set of data files that are then processed serially > using the xsil2graphics2 command, which is what uses the XSILFile.py > code. > > That's certainly how end users will use it outside of the test suite anyway. > > Could you help me by explaining what tests are demanding the MPI > version of h5py, and whether they would still be fine if they used the > serial version instead? If this issue can be fixed simply by having > XMDS2 only depend on python3-h5py-serial, that would seem to be the > easiest solution. > > Regards, > Mattias > > ________________________________ > From: Rafael Laboissière <ra...@de...> > Sent: Thursday, 12 October 2023 7:19 AM > To: XMDS devel list <xmd...@li...> > Cc: Nilesh Patra <ni...@ri...>; Drew Parsons <dpa...@de...> > Subject: [xmds-devel] XMDS and h5py serial vs. mpi > > Dear XMDS developers, > > For some context in what follows, please see Bug#1053314, filed against > the xmds2 package of the Debian distribution. > https://bugs.debian.org/1053314<https://bugs.debian.org/1053314> > > This “bug” was caused by recent changes in the packaging for the h5py > module for Python in Debian, as regards the serial and mpi variants. You > can find more context on this here: > https://salsa.debian.org/science-team/h5py/-/blob/master/debian/README.Debian<https://salsa.debian.org/science-team/h5py/-/blob/master/debian/README.Debian> > > Apparently, some of the tests in the unit tests suite of XMDS needs the > MPI (not serial) version of h5py. Since h5py is accessed through the > generic API in XSILFile.py, it may happen that the serial version h5py > is used, instead of the MPI version. In order to “fix” the problem, I > introduced the following patch to the xmds2 Debian package: > https://salsa.debian.org/science-team/xmds2/-/blob/master/debian/patches/h5py-always-use-mpi.patch<https://salsa.debian.org/science-team/xmds2/-/blob/master/debian/patches/h5py-always-use-mpi.patch> > > The question we are asking ourselves regards the intentions of the XMDS > upstream developers with h5py and MPI. > > I am adding Drew Parsons and Nilesh Patra in Cc to this message. They > might wish to correct some of my assertions above or add comments on the > issue. > > Best, > > Rafael Laboissière > > > _______________________________________________ > xmds-devel mailing list > xmd...@li... > https://lists.sourceforge.net/lists/listinfo/xmds-devel<https://lists.sourceforge.net/lists/listinfo/xmds-devel> |
From: Mattias J. <mat...@mq...> - 2023-10-12 03:11:05
|
Hi Rafael, I'm not that familiar with the test suite, but I can see no reason why it should need the MPI version of h5py. In fact, I see I've only got the python3-h5py-serial package installed on my machine, and everything seems fine. My understanding is that while MPI may be used for the simulation, the end result is a set of data files that are then processed serially using the xsil2graphics2 command, which is what uses the XSILFile.py code. That's certainly how end users will use it outside of the test suite anyway. Could you help me by explaining what tests are demanding the MPI version of h5py, and whether they would still be fine if they used the serial version instead? If this issue can be fixed simply by having XMDS2 only depend on python3-h5py-serial, that would seem to be the easiest solution. Regards, Mattias ________________________________ From: Rafael Laboissière <ra...@de...> Sent: Thursday, 12 October 2023 7:19 AM To: XMDS devel list <xmd...@li...> Cc: Nilesh Patra <ni...@ri...>; Drew Parsons <dpa...@de...> Subject: [xmds-devel] XMDS and h5py serial vs. mpi Dear XMDS developers, For some context in what follows, please see Bug#1053314, filed against the xmds2 package of the Debian distribution. https://bugs.debian.org/1053314<https://bugs.debian.org/1053314> This “bug” was caused by recent changes in the packaging for the h5py module for Python in Debian, as regards the serial and mpi variants. You can find more context on this here: https://salsa.debian.org/science-team/h5py/-/blob/master/debian/README.Debian<https://salsa.debian.org/science-team/h5py/-/blob/master/debian/README.Debian> Apparently, some of the tests in the unit tests suite of XMDS needs the MPI (not serial) version of h5py. Since h5py is accessed through the generic API in XSILFile.py, it may happen that the serial version h5py is used, instead of the MPI version. In order to “fix” the problem, I introduced the following patch to the xmds2 Debian package: https://salsa.debian.org/science-team/xmds2/-/blob/master/debian/patches/h5py-always-use-mpi.patch<https://salsa.debian.org/science-team/xmds2/-/blob/master/debian/patches/h5py-always-use-mpi.patch> The question we are asking ourselves regards the intentions of the XMDS upstream developers with h5py and MPI. I am adding Drew Parsons and Nilesh Patra in Cc to this message. They might wish to correct some of my assertions above or add comments on the issue. Best, Rafael Laboissière _______________________________________________ xmds-devel mailing list xmd...@li... https://lists.sourceforge.net/lists/listinfo/xmds-devel<https://lists.sourceforge.net/lists/listinfo/xmds-devel> |
From: Rafael L. <ra...@de...> - 2023-10-11 20:19:56
|
Dear XMDS developers, For some context in what follows, please see Bug#1053314, filed against the xmds2 package of the Debian distribution. https://bugs.debian.org/1053314 This “bug” was caused by recent changes in the packaging for the h5py module for Python in Debian, as regards the serial and mpi variants. You can find more context on this here: https://salsa.debian.org/science-team/h5py/-/blob/master/debian/README.Debian Apparently, some of the tests in the unit tests suite of XMDS needs the MPI (not serial) version of h5py. Since h5py is accessed through the generic API in XSILFile.py, it may happen that the serial version h5py is used, instead of the MPI version. In order to “fix” the problem, I introduced the following patch to the xmds2 Debian package: https://salsa.debian.org/science-team/xmds2/-/blob/master/debian/patches/h5py-always-use-mpi.patch The question we are asking ourselves regards the intentions of the XMDS upstream developers with h5py and MPI. I am adding Drew Parsons and Nilesh Patra in Cc to this message. They might wish to correct some of my assertions above or add comments on the issue. Best, Rafael Laboissière |
From: Mattias J. <mat...@mq...> - 2022-12-20 23:50:13
|
Patch tested and applied. Thanks Rafael, you're the best! Cheers, Mattias ________________________________ From: Rafael Laboissière <ra...@de...> Sent: Wednesday, 21 December 2022 2:19 AM To: XMDS devel list <xmd...@li...> Subject: [xmds-devel] XMDS fails with version 1.23 of numpy Dear XMDS developers, XMDS2 fails when run against the latest version of numpy (1.23), with errors like the following one: ERROR: test_breakpoints (__main__.main.<locals>.ScriptTestCase) io/breakpoints.xmds ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/data/rlaboiss/debian/PKGS/xmds2/xmds2/./run_tests.py", line 328, in newfunc return func(*(args + fargs), **newkeywords) File "/var/data/rlaboiss/debian/PKGS/xmds2/xmds2/./run_tests.py", line 189, in scriptTestingFunction results = XSILFile(resultsFullPath) File "/var/data/rlaboiss/debian/PKGS/xmds2/xmds2/xpdeint/XSILFile.py", line 257, in __init__ data = XSILDataBinary(independentVariables, dependentVariables, uLong, precision, encoding, filename, File "/var/data/rlaboiss/debian/PKGS/xmds2/xmds2/xpdeint/XSILFile.py", line 99, in __init__ if loadData: self.parseDataFile(uLong, precision, encoding, dataFile) File "/var/data/rlaboiss/debian/PKGS/xmds2/xmds2/xpdeint/XSILFile.py", line 121, in parseDataFile independentGeometry.append(numpy.asscalar(size)) File "/usr/lib/python3/dist-packages/numpy/__init__.py", line 311, in __getattr__ raise AttributeError("module {!r} has no attribute " AttributeError: module 'numpy' has no attribute 'asscalar' The method numpy.asscalar() is deprecated since version 1.16 of numpy and was removed in version 1.23. The patch attached to this message fixes the problem. Best, Rafael Laboissière |
From: Rafael L. <ra...@de...> - 2022-12-20 15:19:49
|
Dear XMDS developers, XMDS2 fails when run against the latest version of numpy (1.23), with errors like the following one: ERROR: test_breakpoints (__main__.main.<locals>.ScriptTestCase) io/breakpoints.xmds ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/data/rlaboiss/debian/PKGS/xmds2/xmds2/./run_tests.py", line 328, in newfunc return func(*(args + fargs), **newkeywords) File "/var/data/rlaboiss/debian/PKGS/xmds2/xmds2/./run_tests.py", line 189, in scriptTestingFunction results = XSILFile(resultsFullPath) File "/var/data/rlaboiss/debian/PKGS/xmds2/xmds2/xpdeint/XSILFile.py", line 257, in __init__ data = XSILDataBinary(independentVariables, dependentVariables, uLong, precision, encoding, filename, File "/var/data/rlaboiss/debian/PKGS/xmds2/xmds2/xpdeint/XSILFile.py", line 99, in __init__ if loadData: self.parseDataFile(uLong, precision, encoding, dataFile) File "/var/data/rlaboiss/debian/PKGS/xmds2/xmds2/xpdeint/XSILFile.py", line 121, in parseDataFile independentGeometry.append(numpy.asscalar(size)) File "/usr/lib/python3/dist-packages/numpy/__init__.py", line 311, in __getattr__ raise AttributeError("module {!r} has no attribute " AttributeError: module 'numpy' has no attribute 'asscalar' The method numpy.asscalar() is deprecated since version 1.16 of numpy and was removed in version 1.23. The patch attached to this message fixes the problem. Best, Rafael Laboissière |
From: Rafael L. <ra...@de...> - 2022-11-05 21:06:23
|
* Mattias Johnsson <mat...@mq...> [2022-11-04 22:52]: > I guess that explains why I have a memory of occasional friendly_plus > errors in the past but could never reproduce them. > > I have tested your patch, and everything seems to work at my end as > well, so I have applied it. Great, thanks! You might also remove the files FriendlyPlusStyle.py and XMDSScriptLexer.py from the main XMDS code repository. Best, Rafael |
From: Mattias J. <mat...@mq...> - 2022-11-04 22:52:25
|
Thanks Rafael, nice detective work! I guess that explains why I have a memory of occasional friendly_plus errors in the past but could never reproduce them. I have tested your patch, and everything seems to work at my end as well, so I have applied it. Thanks again! Cheers, Mattias ________________________________ From: Rafael Laboissière <ra...@de...> Sent: Saturday, 5 November 2022 1:01 AM To: Mattias Johnsson <mat...@mq...>; XMDS devel list <xmd...@li...> Subject: Re: [xmds-devel] Issues when building the documentation from source * Rafael Laboissière <ra...@de...> [2022-11-04 10:38]: > > I plunged deeper into the issue and I think I understand what is going > on. Indeed, there is a pygments.style entry point in setup.py that > defines the friendly_plus style. This definition ends up in the > entry_points.txt file of the main XMDS2 package: > > $ cat /usr/lib/python3/dist-packages/xmds2-3.1.0.egg-info/entry_points.txt > [pygments.lexers] > XMDSScriptLexer = xpdeint.XMDSScriptLexer:XMDSScriptLexer > > [pygments.styles] > friendly_plus = xpdeint.FriendlyPlusStyle:FriendlyPlusStyle > > This means that, in order to build the documentation, XMDS2 *must* be > installed in the system. This is causing problems in the building of > the xmds2 package for Debian, which is maintained by me. > > This is a strange setup. The xpdeint/FriendlyPlusStyle.py file has > nothing to do with the XMDS2 package per se, since it is only used > when building the documentation. The same remark applies to > xpdeint/XMDSScriptLexer.py, BTW. These two files should be moved into > the userdoc space and the entry points should be defined somehow > there. > > Unfortunately, my knowledge of entry points and Pygments plugins is > very scarce and I am unable to propose a quick and sound fix for this > issue. I will try to take a look at it, as time permits. I could “fix” the problem using the patch attached to this message. I created a _pygments directory and copied the files FriendlyPlusStyle.py and XMDSScriptLexer.py there. In conf.py, I replaced the line: pygments_style = 'friendly_plus' by: sys.path.append(os.path.abspath("./_pygments")) pygments_style = 'FriendlyPlusStyle.FriendlyPlusStyle' extensions = ['XMDSScriptLexer'] Since XMDSScriptLexer.py is treated as a Sphinx extension, then it is necessary to define a setup function in it: def setup(app): app.add_lexer('xmds2', XMDSScriptLexer) app.add_lexer('xpdeint', XMDSScriptLexer) With this patch, it is possible to build the documentation without having XMDS installed in the system. Best, Rafael |
From: Rafael L. <ra...@de...> - 2022-11-04 14:01:57
|
* Rafael Laboissière <ra...@de...> [2022-11-04 10:38]: > > I plunged deeper into the issue and I think I understand what is going > on. Indeed, there is a pygments.style entry point in setup.py that > defines the friendly_plus style. This definition ends up in the > entry_points.txt file of the main XMDS2 package: > > $ cat /usr/lib/python3/dist-packages/xmds2-3.1.0.egg-info/entry_points.txt > [pygments.lexers] > XMDSScriptLexer = xpdeint.XMDSScriptLexer:XMDSScriptLexer > > [pygments.styles] > friendly_plus = xpdeint.FriendlyPlusStyle:FriendlyPlusStyle > > This means that, in order to build the documentation, XMDS2 *must* be > installed in the system. This is causing problems in the building of > the xmds2 package for Debian, which is maintained by me. > > This is a strange setup. The xpdeint/FriendlyPlusStyle.py file has > nothing to do with the XMDS2 package per se, since it is only used > when building the documentation. The same remark applies to > xpdeint/XMDSScriptLexer.py, BTW. These two files should be moved into > the userdoc space and the entry points should be defined somehow > there. > > Unfortunately, my knowledge of entry points and Pygments plugins is > very scarce and I am unable to propose a quick and sound fix for this > issue. I will try to take a look at it, as time permits. I could “fix” the problem using the patch attached to this message. I created a _pygments directory and copied the files FriendlyPlusStyle.py and XMDSScriptLexer.py there. In conf.py, I replaced the line: pygments_style = 'friendly_plus' by: sys.path.append(os.path.abspath("./_pygments")) pygments_style = 'FriendlyPlusStyle.FriendlyPlusStyle' extensions = ['XMDSScriptLexer'] Since XMDSScriptLexer.py is treated as a Sphinx extension, then it is necessary to define a setup function in it: def setup(app): app.add_lexer('xmds2', XMDSScriptLexer) app.add_lexer('xpdeint', XMDSScriptLexer) With this patch, it is possible to build the documentation without having XMDS installed in the system. Best, Rafael |
From: Rafael L. <ra...@de...> - 2022-11-04 09:38:43
|
Hello Mattias, * Mattias Johnsson <mat...@mq...> [2022-11-03 02:20]: > Regarding the alignment tab, "&=&" on my machines works fine and > produces no warning. Strange. But "&=" also works, so I'm happy to > apply your patch. Thanks! We have perhaps different versions of TeX-related packages in our systems, which is causing the divergent behavior. Thanks for applying the patch, anyway. > Regarding friendly_plus, there is an "xpedient/FriendlyPlusStyle.py" > file that should define the style, so it seems your build is not > picking it up. However I don't understand the pygments system at all, > didn't write this bit, and have vague memories of friendly_plus errors > in the past that came and went. So if you can understand why this style > is not being picked up (again, it works when I build the docs on my > machines), that would be great to know. If you can't see why, I'll > consider applying your patch anyway and just use "friendly" since the > style difference is minor and just makes some of the XML examples in > the documentation easier to read. I plunged deeper into the issue and I think I understand what is going on. Indeed, there is a pygments.style entry point in setup.py that defines the friendly_plus style. This definition ends up in the entry_points.txt file of the main XMDS2 package: $ cat /usr/lib/python3/dist-packages/xmds2-3.1.0.egg-info/entry_points.txt [pygments.lexers] XMDSScriptLexer = xpdeint.XMDSScriptLexer:XMDSScriptLexer [pygments.styles] friendly_plus = xpdeint.FriendlyPlusStyle:FriendlyPlusStyle This means that, in order to build the documentation, XMDS2 *must* be installed in the system. This is causing problems in the building of the xmds2 package for Debian, which is maintained by me. This is a strange setup. The xpdeint/FriendlyPlusStyle.py file has nothing to do with the XMDS2 package per se, since it is only used when building the documentation. The same remark applies to xpdeint/XMDSScriptLexer.py, BTW. These two files should be moved into the userdoc space and the entry points should be defined somehow there. Unfortunately, my knowledge of entry points and Pygments plugins is very scarce and I am unable to propose a quick and sound fix for this issue. I will try to take a look at it, as time permits. Best, Rafael |
From: Mattias J. <mat...@mq...> - 2022-11-03 02:36:41
|
Hi Rafael, Regarding the alignment tab, "&=&" on my machines works fine and produces no warning. Strange. But "&=" also works, so I'm happy to apply your patch. Thanks! Regarding friendly_plus, there is an "xpedient/FriendlyPlusStyle.py" file that should define the style, so it seems your build is not picking it up. However I don't understand the pygments system at all, didn't write this bit, and have vague memories of friendly_plus errors in the past that came and went. So if you can understand why this style is not being picked up (again, it works when I build the docs on my machines), that would be great to know. If you can't see why, I'll consider applying your patch anyway and just use "friendly" since the style difference is minor and just makes some of the XML examples in the documentation easier to read. Cheers, Mattias ________________________________ From: Rafael Laboissière <ra...@de...> Sent: Thursday, 3 November 2022 12:09 PM To: XMDS devel list <xmd...@li...> Subject: [xmds-devel] Issues when building the documentation from source Dear XMDS developers, Building the XMDS documentation from source [*] fails with these two unrelated errors: 1) Non existent pygments style This is the error message: python3 -msphinx -b html -d ../../documentation/doctrees . ../../documentation Running Sphinx v4.5.0 Exception occurred: File "/usr/lib/python3/dist-packages/pygments/styles/__init__.py", line 80, in get_style_by_name raise ClassNotFound("Could not find style module %r" % mod + pygments.util.ClassNotFound: Could not find style module 'friendly_plus'. Indeed, the style 'friendly_plus' does ot exist: $ python3 Python 3.10.7 (main, Oct 1 2022, 04:31:04) [GCC 12.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from pygments.styles import STYLE_MAP >>> STYLE_MAP.keys() dict_keys(['default', 'emacs', 'friendly', 'friendly_grayscale', 'colorful', 'autumn', 'murphy', 'manni', 'material', 'monokai', 'perldoc', 'pastie', 'borland', 'trac', 'native', 'fruity', 'bw', 'vim', 'vs', 'tango', 'rrt', 'xcode', 'igor', 'paraiso-light', 'paraiso-dark', 'lovelace', 'algol', 'algol_nu', 'arduino', 'rainbow_dash', 'abap', 'solarized-dark', 'solarized-light', 'sas', 'stata', 'stata-light', 'stata-dark', 'inkpot', 'zenburn', 'gruvbox-dark', 'gruvbox-light', 'dracula', 'one-dark', 'lilypond']) The patch pygments-style.patch attached to this message fixes the problem. 2) Alignment tab in LaTeX split environment When build the PDF form of the documentation, I came across this error: $ make -C documentation/latex all-pdf […] [62] ! Extra alignment tab has been changed to \cr. <template> }$\hfill \endtemplate l.3231 ...t](r) \right\} e^{i m \theta}\end{split} This is caused by the presence of "&=&" instead of "&=" in the mathematical formulae in reference_elements.rst. The patch extra-alignment-tab.patch attached to this message fixes the problem. Best regards, Rafael Laboissière [*] from the sources obtained from SVN https://sourceforge.net/p/xmds/code/HEAD/tree/trunk/xpdeint/admin/userdoc-source/<https://sourceforge.net/p/xmds/code/HEAD/tree/trunk/xpdeint/admin/userdoc-source> |
From: Rafael L. <ra...@de...> - 2022-11-03 01:09:33
|
Dear XMDS developers, Building the XMDS documentation from source [*] fails with these two unrelated errors: 1) Non existent pygments style This is the error message: python3 -msphinx -b html -d ../../documentation/doctrees . ../../documentation Running Sphinx v4.5.0 Exception occurred: File "/usr/lib/python3/dist-packages/pygments/styles/__init__.py", line 80, in get_style_by_name raise ClassNotFound("Could not find style module %r" % mod + pygments.util.ClassNotFound: Could not find style module 'friendly_plus'. Indeed, the style 'friendly_plus' does ot exist: $ python3 Python 3.10.7 (main, Oct 1 2022, 04:31:04) [GCC 12.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from pygments.styles import STYLE_MAP >>> STYLE_MAP.keys() dict_keys(['default', 'emacs', 'friendly', 'friendly_grayscale', 'colorful', 'autumn', 'murphy', 'manni', 'material', 'monokai', 'perldoc', 'pastie', 'borland', 'trac', 'native', 'fruity', 'bw', 'vim', 'vs', 'tango', 'rrt', 'xcode', 'igor', 'paraiso-light', 'paraiso-dark', 'lovelace', 'algol', 'algol_nu', 'arduino', 'rainbow_dash', 'abap', 'solarized-dark', 'solarized-light', 'sas', 'stata', 'stata-light', 'stata-dark', 'inkpot', 'zenburn', 'gruvbox-dark', 'gruvbox-light', 'dracula', 'one-dark', 'lilypond']) The patch pygments-style.patch attached to this message fixes the problem. 2) Alignment tab in LaTeX split environment When build the PDF form of the documentation, I came across this error: $ make -C documentation/latex all-pdf […] [62] ! Extra alignment tab has been changed to \cr. <template> }$\hfill \endtemplate l.3231 ...t](r) \right\} e^{i m \theta}\end{split} This is caused by the presence of "&=&" instead of "&=" in the mathematical formulae in reference_elements.rst. The patch extra-alignment-tab.patch attached to this message fixes the problem. Best regards, Rafael Laboissière [*] from the sources obtained from SVN https://sourceforge.net/p/xmds/code/HEAD/tree/trunk/xpdeint/admin/userdoc-source/ |
From: Mattias J. <mat...@mq...> - 2021-10-20 09:37:21
|
Some unit tests were failing when the generated C++ file is compiled against GCC 11.2.0 on a Debian system. The problems are related to name clashes between global variables are library functions (namely "beta" and "size"), so rename those variables in the xmds scripts. Patch contributed by Rafael Laboissière fixing the issue is copied below: Description: Avoid clash between global variables and library functions Author: Rafael Laboissière <ra...@de...> Bug-Debian: https://bugs.debian.org/996279 Forwarded: no Last-Update: 2021-10-19 --- xmds2-3.0.0+dfsg.orig/testsuite/features/arguments.xmds +++ xmds2-3.0.0+dfsg/testsuite/features/arguments.xmds @@ -1,7 +1,7 @@ <?xml version="1.0" encoding="UTF-8"?> <simulation xmds-version="2"> <testing> - <arguments>--time_factor 2.0 --size 25.0</arguments> + <arguments>--time_factor 2.0 --ssize 25.0</arguments> <xsil_file name="arguments.xsil" expected="arguments_expected.xsil" absolute_tolerance="1e-7" relative_tolerance="1e-5" /> </testing> @@ -10,7 +10,7 @@ <description> Simple one-dimensional diffusion with a pointless second dimension thrown in for fun. Uses arguments and argument preprocessing. Essentially the simulation "looks" the - same for any given "size", as the interval/etc is scaled to fit the interesting region. + same for any given "ssize", as the interval/etc is scaled to fit the interesting region. The user may use width_scale, time_scale and ratio to zoom out and in... </description> @@ -29,16 +29,16 @@ ]]> </globals> <arguments> - <argument name="size" type="real" default_value="20.0"/> + <argument name="ssize" type="real" default_value="20.0"/> <argument name="fraction" type="real" default_value="0.1"/> <argument name="width_factor" type="real" default_value="1.0"/> <argument name="time_factor" type="real" default_value="1.0"/> <![CDATA[ - minx = -0.5*size; - maxx = 0.5*size; - miny = -0.5*size*fraction; - maxy = 0.5*size*fraction; - width = 0.5*sqrt(0.5)*size*fraction*width_factor; // half the simulation size + minx = -0.5*ssize; + maxx = 0.5*ssize; + miny = -0.5*ssize*fraction; + maxy = 0.5*ssize*fraction; + width = 0.5*sqrt(0.5)*ssize*fraction*width_factor; // half the simulation size // The time intersting stuff happens scales as width^2 time_interval = 20.0 * width*width * time_factor; ]]> --- xmds2-3.0.0+dfsg.orig/testsuite/features/space in filename.xmds +++ xmds2-3.0.0+dfsg/testsuite/features/space in filename.xmds @@ -1,7 +1,7 @@ <?xml version="1.0" encoding="UTF-8"?> <simulation xmds-version="2"> <testing> - <arguments>--time_factor 2.0 --size 25.0</arguments> + <arguments>--time_factor 2.0 --ssize 25.0</arguments> <xsil_file name="space in filename.xsil" expected="arguments_expected.xsil" absolute_tolerance="1e-7" relative_tolerance="1e-5" /> </testing> @@ -12,7 +12,7 @@ Simple one-dimensional diffusion with a pointless second dimension thrown in for fun. Uses arguments and argument preprocessing. Essentially the simulation "looks" the - same for any given "size", as the interval/etc is scaled to fit the interesting region. + same for any given "ssize", as the interval/etc is scaled to fit the interesting region. The user may use width_scale, time_scale and ratio to zoom out and in... </description> @@ -31,16 +31,16 @@ ]]> </globals> <arguments> - <argument name="size" type="real" default_value="20.0"/> + <argument name="ssize" type="real" default_value="20.0"/> <argument name="fraction" type="real" default_value="0.1"/> <argument name="width_factor" type="real" default_value="1.0"/> <argument name="time_factor" type="real" default_value="1.0"/> <![CDATA[ - minx = -0.5*size; - maxx = 0.5*size; - miny = -0.5*size*fraction; - maxy = 0.5*size*fraction; - width = 0.5*sqrt(0.5)*size*fraction*width_factor; // half the simulation size + minx = -0.5*ssize; + maxx = 0.5*ssize; + miny = -0.5*ssize*fraction; + maxy = 0.5*ssize*fraction; + width = 0.5*sqrt(0.5)*ssize*fraction*width_factor; // half the simulation size // The time intersting stuff happens scales as width^2 time_interval = 20.0 * width*width * time_factor; ]]> --- xmds2-3.0.0+dfsg.orig/testsuite/mpi/fibre_integer_dimensions_mpi.xmds +++ xmds2-3.0.0+dfsg/testsuite/mpi/fibre_integer_dimensions_mpi.xmds @@ -28,7 +28,7 @@ <globals> <![CDATA[ const real ggamma = 1.0; - const real beta = sqrt(4.0*M_PI*ggamma/10.0); + const real bbeta = sqrt(4.0*M_PI*ggamma/10.0); ]]> </globals> </features> @@ -59,7 +59,7 @@ <integration_vectors>main</integration_vectors> <dependencies>noise</dependencies> <![CDATA[ - dphi_dt = L[phi] - ggamma*phi + beta*n_1; + dphi_dt = L[phi] - ggamma*phi + bbeta*n_1; ]]> </operators> </integrate> --- xmds2-3.0.0+dfsg.orig/testsuite/stochastic/fibre.xmds +++ xmds2-3.0.0+dfsg/testsuite/stochastic/fibre.xmds @@ -22,7 +22,7 @@ <globals> <![CDATA[ const real ggamma = 1.0; - const real beta = sqrt(4.0*M_PI*ggamma/10.0); + const real bbeta = sqrt(4.0*M_PI*ggamma/10.0); ]]> </globals> </features> @@ -53,7 +53,7 @@ <integration_vectors>main</integration_vectors> <dependencies>noise</dependencies> <![CDATA[ - dphi_dt = L[phi] - ggamma*phi + beta*n_1; + dphi_dt = L[phi] - ggamma*phi + bbeta*n_1; ]]> </operators> </integrate> --- xmds2-3.0.0+dfsg.orig/testsuite/stochastic/fibre_with_correlation_functions.xmds +++ xmds2-3.0.0+dfsg/testsuite/stochastic/fibre_with_correlation_functions.xmds @@ -23,7 +23,7 @@ <globals> <![CDATA[ const real ggamma = 1.0; - const real beta = sqrt(4.0*M_PI*ggamma/10.0); + const real bbeta = sqrt(4.0*M_PI*ggamma/10.0); ]]> </globals> </features> @@ -54,7 +54,7 @@ <integration_vectors>main</integration_vectors> <dependencies>noise</dependencies> <![CDATA[ - dphi_dt = L[phi] - ggamma*phi + beta*n_1; + dphi_dt = L[phi] - ggamma*phi + bbeta*n_1; ]]> </operators> </integrate> |
From: Rafael L. <ra...@de...> - 2021-10-19 19:40:56
|
Dear XMDS developers, Some unit tests are failing when the generated C++ file is compiled against GCC 11.2.0 on a Debian system. The full log of the compilation failures is attached to this message. Also attached is a patch for fixing the problem, which is currently applied to the Debian package xmds2. This is necessary, since the build of the Debian package exercises the unit tests. All the five problems are related to name clashes between global variables are library functions (namely "beta" and "size"). Best regards, Rafael Laboissière |
From: Mattias J. <mat...@mq...> - 2020-04-10 00:39:09
|
Hi Bandita, I'm assuming you're using the "nlse.xmds" script that comes as one of the examples. After compiling and running the script with xmds2 nlse.xmds ./nlse you will have a data file "nlse.h5" which contains your output formatted in the HDF5 standard, as well as a description of that data and the original problem called "nlse.xsil". You can use "nlse.h5" with any standard programs that can handle HDF5 data. If you specifically want to use the data in Mathematica, XMDS2 provides a helper program "xsil2graphics2". If you run xsil2graphics2 -e nlse.xsil it will produce a file called "nlse.nb" that you can load as a Mathematica notebook. Note that the "-e" option creates a Mathematica notebook, if you use the "-m" option it will create an import script for Matlab and so on. "xsil2graphics2 --help" will give you a list of all the options. Once you have loaded the "nlse.nb" notebook in Mathematica and run it, you will have all the data as the variables {"xi1", "tau1", "density1", "xi2", "normalisation2", "xi3", "ktau3", "densityK3"}. These are the moments you defined in your output moment groups, with the number on the end corresponding to the moment group. Once you have this data you can plot it however you like. For example ListPlot3D[density1, DataRange -> {{-6, 6}, {0, 20}}, PlotRange -> All] will plot the full density function. Cheers, Mattias ________________________________ From: bandita das <ban...@uo...> Sent: Monday, 6 April 2020 12:47 AM To: xmd...@li... <xmd...@li...> Subject: [xmds-user] issue regarding interpreting result of non linear Schrodinger equation Dear Sir, I am having an issue interpreting the output of the nlse.xmds file. My problem is regarding extracting it to mathematica and plotting the density function with respect to the transverse dimension. Will you please help me out with this. I am very new to coding, so I'm not getting it very clearly. -- Bandita Das, Research scholar, School of Physics, University of Hyderabad, CR Rao Road, Gachibowli, 500046. |
From: Mattias J. <mat...@mq...> - 2020-03-30 23:09:36
|
Hi Rafael, Thanks for the patch, but I've already fixed this in the development version of the code! Cheers, Mattias ________________________________ From: Rafael Laboissière <ra...@de...> Sent: Monday, 30 March 2020 5:57 PM To: XMDS devel list <xmd...@li...> Subject: [xmds-devel] Executable file in /usr/lib Dear XMDS developers, Attached below is a patch for fixing the the following warning with the recent version of h5py: H5pyDeprecationWarning: dataset.value has been deprecated. Use dataset[()] instead. Best regards, Rafael Laboissière |
From: Rafael L. <ra...@de...> - 2020-03-30 06:58:04
|
Dear XMDS developers, Attached below is a patch for fixing the the following warning with the recent version of h5py: H5pyDeprecationWarning: dataset.value has been deprecated. Use dataset[()] instead. Best regards, Rafael Laboissière |
From: Mattias J. <mat...@mq...> - 2020-03-29 22:56:10
|
Thanks, tested and applied! ________________________________ From: Rafael Laboissière <ra...@de...> Sent: Monday, 30 March 2020 6:05 AM To: XMDS devel list <xmd...@li...> Subject: [xmds-devel] Syntax warnings against Python 3.8.2 Dear XMDS developers, When installing XMDS2 on a Debian GNU/Linux system with Python version 3.8.2, the following syntax warnings are emitted: /usr/lib/python3/dist-packages/xpdeint/Features/Transforms/_TransformMultiplexer.py:408: SyntaxWarning: "is" with a literal. Did you mean "=="? if transformation.get('transformType', 'real') is 'real' and vector.type == 'complex': /usr/lib/python3/dist-packages/xpdeint/Features/Transforms/_TransformMultiplexer.py:411: SyntaxWarning: "is" with a literal. Did you mean "=="? if transformation.get('transformType', 'real') is 'complex' and vector.type == 'real': /usr/lib/python3/dist-packages/xpdeint/Geometry/_FieldElement.py:66: SyntaxWarning: "is not" with a literal. Did you mean "!="? return '_' + self.name if not self.name is 'geometry' else '' /usr/lib/python3/dist-packages/xpdeint/Segments/Integrators/_Integrator.py:176: SyntaxWarning: "is not" with a literal. Did you mean "!="? if sampleCount and not (self.stepCount % sampleCount) == 0 and not self.__class__.__name__ is "AdaptiveStep": /usr/lib/python3/dist-packages/xpdeint/waf/waflib/extras/cpplint.py:172: SyntaxWarning: "is" with a literal. Did you mean "=="? if params['CPPLINT_OUTPUT'] is 'waf': These warnings seem to be harmless, but I would suggest to apply the attached patch to the next release of XMDS2. Best regards, Rafael Laboissière |
From: Mattias J. <mat...@mq...> - 2020-03-29 22:52:17
|
Hi Rafael, Thanks for the update. Splitting the packages seems like a good solution. I will also update the linux installation script to handle this going forward. Cheers, Mattias ________________________________ From: Rafael Laboissière <ra...@de...> Sent: Monday, 30 March 2020 6:04 AM To: xmd...@li... <xmd...@li...> Subject: Re: [xmds-devel] Debian package xmds2 fails to build with h5py 2.9.0-4 Dear XMDS developers, In the newest version of the Debian package h5py (2.10.0-3), the binary packages have been split into python3-h5py-serial and python3-h5py-mpi, respectively, without and with MPI support. I built the Debian xmds2 package against python3-h5py-mpi and the run_tests.py script is working correctly now. I will soon upload version 3.0.0+dfsg-3 of the xmds2 package to the Debian unstable distribution. I hope it will soon enter the testing distribution. Best regards, Rafael Laboissière * Rafael Laboissière <ra...@de...> [2019-09-09 07:38]: > Dear XMDS developers, > > The xmds2 package in Debian is failing to build after the h5py package > has been upgraded to version 2.9.0-4. You can find more details in > the following bug report, filed against the xmds2 package: > http://bugs.debian.org/938925<https://protect-au.mimecast.com/s/tWVrCr810kC7VZmjHyCHwl?domain=bugs.debian.org> > > As far as I can tell, xmds2 itself is still working after the upgrade > of h5py. What is not working is the run_tests.py script and this is > causing the package build failure. I suspect that the problems arises > in the code of function scriptTestingFunction, after the compilation > and execution of unit test breakpoints_hdf.xmds, for which the data > output in xsil files are compared against the hdf5 files. After that, > all the subsequent units tests that need mpirun to be executed will > then fail. > > This is the farthest that I could go in the diagnostics. I do not > have time to debug further this problem. > > FYI, a library transition concerning h5py scheduled in Debian: > https://release.debian.org/transitions/html/auto-hdf5.html<https://protect-au.mimecast.com/s/nvjVCvl1g2SqN8lgSoM81T?domain=release.debian.org> > > If the bug in the run_tests.py script is not fixed, the xmds2 package > will have to be removed from the testing distribution, and this will > have a negative impact on the XMDS users of Debian and Ubuntu. > > Best regards, > > Rafael Laboissière > _______________________________________________ xmds-devel mailing list xmd...@li... https://lists.sourceforge.net/lists/listinfo/xmds-devel<https://protect-au.mimecast.com/s/0cRGCwV1jpSk8xNQi8thkO?domain=lists.sourceforge.net> |
From: Mattias J. <mat...@mq...> - 2020-03-29 22:36:13
|
Hi Rafael, Thanks for pointing this out. I have made the change. Cheers, Mattias ________________________________ From: Rafael Laboissière <ra...@de...> Sent: Monday, 30 March 2020 6:06 AM To: XMDS devel list <xmd...@li...> Subject: [xmds-devel] Executable file in /usr/lib Dear XMDS developers, According to the Filesystem Hierarchy Standard (FHS) version 3.0, sections 4.6 [1] and 4.7 [2], executable files should not be installed in /usr/lib. In version 3.0.0 of XMDS2, we have: $ ls -l xpdeint/support/wscript -rwxr-xr-x 1 rlaboiss rlaboiss 29226 May 21 2019 xpdeint/support/wscript The file wscript is then installed with execute permission in /usr/lib, which is a violation of FHS. Actually, there is no need for this permission, since this file in loaded as a module in Configuration.py. Could you please fix the problem in the next release tarball of XMDS2? By the way, there is no need for keeping the shebang line in this script: $ head -n 1 xpdeint/support/wscript #!/usr/bin/env python3 Best regards, Rafael Laboissière [1] http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s06.html<https://protect-au.mimecast.com/s/pMwQCGv0Z6fEYlJvCQ_6o9?domain=refspecs.linuxfoundation.org> [2] http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html<https://protect-au.mimecast.com/s/EBZJCJyBZ6tlrz8NSvVJCb?domain=refspecs.linuxfoundation.org> _______________________________________________ xmds-devel mailing list xmd...@li... https://lists.sourceforge.net/lists/listinfo/xmds-devel<https://protect-au.mimecast.com/s/qAt2CK1DOrCPEwqVHGnPM6?domain=lists.sourceforge.net> |
From: Rafael L. <ra...@de...> - 2020-03-29 19:31:08
|
Dear XMDS developers, When installing XMDS2 on a Debian GNU/Linux system with Python version 3.8.2, the following syntax warnings are emitted: /usr/lib/python3/dist-packages/xpdeint/Features/Transforms/_TransformMultiplexer.py:408: SyntaxWarning: "is" with a literal. Did you mean "=="? if transformation.get('transformType', 'real') is 'real' and vector.type == 'complex': /usr/lib/python3/dist-packages/xpdeint/Features/Transforms/_TransformMultiplexer.py:411: SyntaxWarning: "is" with a literal. Did you mean "=="? if transformation.get('transformType', 'real') is 'complex' and vector.type == 'real': /usr/lib/python3/dist-packages/xpdeint/Geometry/_FieldElement.py:66: SyntaxWarning: "is not" with a literal. Did you mean "!="? return '_' + self.name if not self.name is 'geometry' else '' /usr/lib/python3/dist-packages/xpdeint/Segments/Integrators/_Integrator.py:176: SyntaxWarning: "is not" with a literal. Did you mean "!="? if sampleCount and not (self.stepCount % sampleCount) == 0 and not self.__class__.__name__ is "AdaptiveStep": /usr/lib/python3/dist-packages/xpdeint/waf/waflib/extras/cpplint.py:172: SyntaxWarning: "is" with a literal. Did you mean "=="? if params['CPPLINT_OUTPUT'] is 'waf': These warnings seem to be harmless, but I would suggest to apply the attached patch to the next release of XMDS2. Best regards, Rafael Laboissière |
From: Rafael L. <ra...@de...> - 2020-03-29 19:30:47
|
Dear XMDS developers, In the newest version of the Debian package h5py (2.10.0-3), the binary packages have been split into python3-h5py-serial and python3-h5py-mpi, respectively, without and with MPI support. I built the Debian xmds2 package against python3-h5py-mpi and the run_tests.py script is working correctly now. I will soon upload version 3.0.0+dfsg-3 of the xmds2 package to the Debian unstable distribution. I hope it will soon enter the testing distribution. Best regards, Rafael Laboissière * Rafael Laboissière <ra...@de...> [2019-09-09 07:38]: > Dear XMDS developers, > > The xmds2 package in Debian is failing to build after the h5py package > has been upgraded to version 2.9.0-4. You can find more details in > the following bug report, filed against the xmds2 package: > http://bugs.debian.org/938925 > > As far as I can tell, xmds2 itself is still working after the upgrade > of h5py. What is not working is the run_tests.py script and this is > causing the package build failure. I suspect that the problems arises > in the code of function scriptTestingFunction, after the compilation > and execution of unit test breakpoints_hdf.xmds, for which the data > output in xsil files are compared against the hdf5 files. After that, > all the subsequent units tests that need mpirun to be executed will > then fail. > > This is the farthest that I could go in the diagnostics. I do not > have time to debug further this problem. > > FYI, a library transition concerning h5py scheduled in Debian: > https://release.debian.org/transitions/html/auto-hdf5.html > > If the bug in the run_tests.py script is not fixed, the xmds2 package > will have to be removed from the testing distribution, and this will > have a negative impact on the XMDS users of Debian and Ubuntu. > > Best regards, > > Rafael Laboissière > |
From: Rafael L. <ra...@de...> - 2020-03-29 19:17:17
|
Dear XMDS developers, According to the Filesystem Hierarchy Standard (FHS) version 3.0, sections 4.6 [1] and 4.7 [2], executable files should not be installed in /usr/lib. In version 3.0.0 of XMDS2, we have: $ ls -l xpdeint/support/wscript -rwxr-xr-x 1 rlaboiss rlaboiss 29226 May 21 2019 xpdeint/support/wscript The file wscript is then installed with execute permission in /usr/lib, which is a violation of FHS. Actually, there is no need for this permission, since this file in loaded as a module in Configuration.py. Could you please fix the problem in the next release tarball of XMDS2? By the way, there is no need for keeping the shebang line in this script: $ head -n 1 xpdeint/support/wscript #!/usr/bin/env python3 Best regards, Rafael Laboissière [1] http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s06.html [2] http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html |
From: Mattias J. <mat...@mq...> - 2019-09-09 09:11:22
|
Oh, of course. Thanks! Once again I confuse "testing" and "unstable" :-P ________________________________ From: Rafael Laboissière <ra...@de...> Sent: Monday, 9 September 2019 6:42 PM To: xmd...@li... <xmd...@li...> Subject: Re: [xmds-devel] Debian package xmds2 fails to build with h5py 2.9.0-4 * Mattias Johnsson <mat...@mq...> [2019-09-09 06:56]: > Thanks for the heads up. I'll install Debian testing and see if I can > reproduce and figure out what's going on. Thanks, Mattias. Note that the bug only manifests itself in Debian unstable. Best, Rafael _______________________________________________ xmds-devel mailing list xmd...@li... https://lists.sourceforge.net/lists/listinfo/xmds-devel<https://protect-au.mimecast.com/s/aAKOCJyBZ6t1BXQ0TG5-uA?domain=lists.sourceforge.net> |