Re: scikit-learn in unstable FTBFS on arm64, armel, armhf, i386, ppc64el and s390x
Hi, Am Wed, Feb 16, 2022 at 12:09:23PM +0100 schrieb John Paul Adrian Glaubitz: > > So, I have skimmed over the build logs and one of the main issues is the use > of > -march flags to enforce a certain baseline [1]: > > powerpc64le-linux-gnu-gcc: error: unrecognized command-line option > ‘-march=native’; did you mean ‘-mcpu=native’? > > This is a policy violation and must be fixed in any case. Blacklisting > architectures > is not enough in this case as forcing the baseline of the buildds can lead to > code > that won't run on the user's machines. I confirm this is a problem and the critical string can also be found in the amd64 build log[2]: ... running build_clib customize UnixCCompiler customize UnixCCompiler using build_clib CCompilerOpt.cc_test_flags[1013] : testing flags (-march=native) C compiler: x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC creating /tmp/tmpk22ehoi2/usr creating /tmp/tmpk22ehoi2/usr/lib creating /tmp/tmpk22ehoi2/usr/lib/python3 creating /tmp/tmpk22ehoi2/usr/lib/python3/dist-packages creating /tmp/tmpk22ehoi2/usr/lib/python3/dist-packages/numpy creating /tmp/tmpk22ehoi2/usr/lib/python3/dist-packages/numpy/distutils creating /tmp/tmpk22ehoi2/usr/lib/python3/dist-packages/numpy/distutils/checks compile options: '-c' extra options: '-march=native' CCompilerOpt.cc_test_flags[1013] : testing flags (-O3) C compiler: x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC ... I admit I'm not sure at what point / what tool might inject this string and I'm also not sure whether the option -march=native is really used in the amd64 case. Kind regards Andreas. > > [1] > > https://buildd.debian.org/status/fetch.php?pkg=scikit-learn&arch=ppc64el&ver=1.0.2-1&stamp=1644956229&raw=0 [2] https://buildd.debian.org/status/fetch.php?pkg=scikit-learn&arch=amd64&ver=1.0.2-1&stamp=1644952702&raw=0 -- http://fam-tille.de
New version of mayavi2 fails to build
Hi, as you can see in Salsa-CI build log[1] the new version of mayavi2 fails with something like: ... File "/builds/python-team/packages/mayavi2/debian/output/source_dir/mayavi/mlab.py", line 16 in File "", line 228 in _call_with_frames_removed File "", line 850 in exec_module File "", line 680 in _load_unlocked File "", line 986 in _find_and_load_unlocked File "", line 1007 in _find_and_load File "", line 228 in _call_with_frames_removed File "", line 1058 in _handle_fromlist File "/builds/python-team/packages/mayavi2/debian/output/source_dir/setup.py", line 138 in mlab_reference File "/builds/python-team/packages/mayavi2/debian/output/source_dir/setup.py", line 176 in run ... Aborted (core dumped) E: pybuild pybuild:367: build: plugin distutils failed with: exit code=134: /usr/bin/python3 setup.py build Any idea what might be wrong here? Kind regards Andreas. [1] https://salsa.debian.org/python-team/packages/mayavi2/-/pipelines/349803 -- http://fam-tille.de
Re: New version of mayavi2 fails to build
On Thu, 17 Feb 2022, Andreas Tille wrote: Hi, as you can see in Salsa-CI build log[1] the new version of mayavi2 fails with something like: ... File "/builds/python-team/packages/mayavi2/debian/output/source_dir/mayavi/mlab.py", line 16 in File "", line 228 in _call_with_frames_removed File "", line 850 in exec_module File "", line 680 in _load_unlocked File "", line 986 in _find_and_load_unlocked File "", line 1007 in _find_and_load File "", line 228 in _call_with_frames_removed File "", line 1058 in _handle_fromlist File "/builds/python-team/packages/mayavi2/debian/output/source_dir/setup.py", line 138 in mlab_reference File "/builds/python-team/packages/mayavi2/debian/output/source_dir/setup.py", line 176 in run ... Aborted (core dumped) E: pybuild pybuild:367: build: plugin distutils failed with: exit code=134: /usr/bin/python3 setup.py build Any idea what might be wrong here? Looking at the full log, it appears as if something in the build process is trying to open an X display and fails. Perhaps try running dh_auto_build with Xvfb? Scott
Should we allow Janitor to commit directly to all DPT packages?
Hello all, the question is essentially all in the subject line, and my answer is yes. I receive notifications for all MRs opened against DPT packages, and Janitor's are always pretty much ready to merge as is, and so i think we should let Janitor commit directly to the team packages. Jelmer is in CC (not sure if he's subscribed), in case he wants to chime in on the implication of this discussion. Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Should we allow Janitor to commit directly to all DPT packages?
On 2022-02-17 12 h 39, Sandro Tosi wrote: > Hello all, > the question is essentially all in the subject line, and my answer is yes. > > I receive notifications for all MRs opened against DPT packages, and > Janitor's are always pretty much ready to merge as is, and so i think > we should let Janitor commit directly to the team packages. > > Jelmer is in CC (not sure if he's subscribed), in case he wants to > chime in on the implication of this discussion. > > Regards, You sent a mail on the list on 2020-07-27 about this and the general consensus (3-4 replies) was that it was a good idea. Anyway, I also vote yes! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Request to join the DPT
Hi, I'd like to join the Debian Python Team. My salsa handle: gracinet I have read the team policy [1] and agree with it. My immediate concern would be to package the Evolve Mercurial extension [2], which is an important piece in many recent Mercurial workflows. I see there is an old RFP about hg-evolve [3], and perhaps will I file an ITP, if that is the right place to ask general questions to start in the right direction, given there's some history to clarify. More generally, I can help with other Mercurial extensions or related stuff, as I can work closely with upstream on that. I have been on the verge of doing Debian packaging for a very long time, but never had the opportunity to go all the way before now. All the best, [1] https://salsa.debian.org/python-team/tools/python-modules/-/blob/master/policy.rst (currently at e9b10b44c4ec737922b08bc43d7437c593da6183) [2] https://pypi.org/project/hg-evolve/ [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926398 -- Georges Racinet https://octobus.net, https://about.heptapod.host, https://heptapod.net GPG: BF5456F4DC625443849B6E58EE20CA44EF691D39, sur serveurs publics OpenPGP_signature Description: OpenPGP digital signature
Re: Should we allow Janitor to commit directly to all DPT packages?
On Thu, Feb 17, 2022 at 2:48 PM Louis-Philippe Véronneau wrote: > On 2022-02-17 12 h 39, Sandro Tosi wrote: > > Hello all, > > the question is essentially all in the subject line, and my answer is > yes. > > > > I receive notifications for all MRs opened against DPT packages, and > > Janitor's are always pretty much ready to merge as is, and so i think > > we should let Janitor commit directly to the team packages. > > > > Jelmer is in CC (not sure if he's subscribed), in case he wants to > > chime in on the implication of this discussion. > > > > Regards, > > You sent a mail on the list on 2020-07-27 about this and the general > consensus (3-4 replies) was that it was a good idea. > > Anyway, I also vote yes! > I also vote yes :-) > > -- > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau > ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org > ⠈⠳⣄ > >
Re: New version of mayavi2 fails to build
Hi Scott, Am Thu, Feb 17, 2022 at 11:27:12AM -0500 schrieb Scott Talbert: > Looking at the full log, it appears as if something in the build process is > trying to open an X display and fails. Perhaps try running dh_auto_build > with Xvfb? Yes, thanks for the very helpful hint Andreas. -- http://fam-tille.de
Re: Should we allow Janitor to commit directly to all DPT packages?
Hi, Am Thu, Feb 17, 2022 at 12:39:54PM -0500 schrieb Sandro Tosi: > I receive notifications for all MRs opened against DPT packages, and > Janitor's are always pretty much ready to merge as is, and so i think > we should let Janitor commit directly to the team packages. I admit I'm hesitating a bit for different reasons. While I agree that direct commits are better than MRs I found several DPT packages with very sensible changes in Git but no uploads following these. For instance fixing VCS fields and Maintainer name should be followed by an according upload to make those changes visible to users and developers of the *packages* in Debian. In the Debian Med team for instance we do those automatic changes before uploading a package - say when upgrading to new upstream versions or fixing some bugs. Than we run the Janitor scripts and other automatic changes which is all done in routine-update. I personally find this workflow more convenient. That way Debian Med team (as well as pkg-r team) are blacklisted for Janitor to not have competing changes inside the package. Kind regards Andreas. -- http://fam-tille.de
Re: Should we allow Janitor to commit directly to all DPT packages?
> I admit I'm hesitating a bit for different reasons. While I agree that > direct commits are better than MRs I found several DPT packages with > very sensible changes in Git but no uploads following these. For > instance fixing VCS fields and Maintainer name should be followed by an > according upload to make those changes visible to users and developers > of the *packages* in Debian. > > In the Debian Med team for instance we do those automatic changes before > uploading a package - say when upgrading to new upstream versions or > fixing some bugs. Than we run the Janitor scripts and other automatic > changes which is all done in routine-update. I personally find this > workflow more convenient. That way Debian Med team (as well as pkg-r > team) are blacklisted for Janitor to not have competing changes inside > the package. thanks for bringing the perspective of how things are done in the Med team, but it feels none of the points you mentioned nor the specific Med team workflow apply here, or are relevant to just let Janitor commit directly to our packages. Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Should we allow Janitor to commit directly to all DPT packages?
On 2/18/22 2:23 AM, Sandro Tosi wrote: I admit I'm hesitating a bit for different reasons. While I agree that direct commits are better than MRs I found several DPT packages with very sensible changes in Git but no uploads following these. For instance fixing VCS fields and Maintainer name should be followed by an according upload to make those changes visible to users and developers of the *packages* in Debian. In the Debian Med team for instance we do those automatic changes before uploading a package - say when upgrading to new upstream versions or fixing some bugs. Than we run the Janitor scripts and other automatic changes which is all done in routine-update. I personally find this workflow more convenient. That way Debian Med team (as well as pkg-r team) are blacklisted for Janitor to not have competing changes inside the package. thanks for bringing the perspective of how things are done in the Med team, but it feels none of the points you mentioned nor the specific Med team workflow apply here, I suppose the highlight was the usage of routine-update[1] package before upload and we could use it with DPT too. This does similar(same?) changes as in janitor. But that said, I agree with what you wrote: or are relevant to just let Janitor commit directly to our packages. I vote a in for/OK for janitor to commit directly as well. [1]: https://tracker.debian.org/pkg/routine-update Regards, Nilesh OpenPGP_signature Description: OpenPGP digital signature
