Bug#776885: RFS: manuel/1.8.0-1 [ITP] -- Python library for documented tests
Package: sponsorship-requests Severity: wishlist Hi, I'm looking for a sponsor for my package of Manuel 1.8.0 [1]. It builds those binary packages: python-manuel - Python library for testable documents and documented tests python3-manuel - Python3 library for testable documents and documented tests Mentors upload: http://mentors.debian.net/package/manuel http://mentors.debian.net/debian/pool/main/m/manuel/manuel_1.8.0-1.dsc Buildlog: http://www.danielstender.com/buildlogs/manuel_1.8.0-1_amd64-20150202-2204.build I've made everything ready for a injection into the DPMT repository (SVN fields and Uploaders present). Thank you very much, Daniel Stender [1] https://pypi.python.org/pypi/manuel/ -- http://qa.debian.org/developer.php?login=debian%40danielstender.com 4096R/DF5182C8 46CB1CA89EA3B74376761DB915E09AF4DF5182C8 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54cfea7e.3020...@danielstender.com
build flags handling
Hi everyone, I recently came across a package [1] which ideally would like to handle its own build flags (adding `-O3 -ffast-math` for speed, for example). What is the Debian policy on this? Cheers, Nico [1] https://packages.debian.org/sid/sound/mixxx -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cak6z60db3qlxs-y1u8z672ur5k12ckxyyxx495gkwu_sp-+...@mail.gmail.com
Re: build flags handling
Hello Nico, On Tue, 2015-02-03 at 00:56 +0200, Nico Schlömer wrote: I recently came across a package [1] which ideally would like to handle its own build flags (adding `-O3 -ffast-math` for speed, for example). What is the Debian policy on this? It is up to the maintainer to set the optimization flags [1]. Note, that it is considered bad practice to set compile flags that limit what hardware is actually supported, e.g. on i386 you should avoid globally enabling SSE, since this would make the package unusable on older systems that don't support SSE. Unless, of course, upstream already imposes such a limitation (e.g. tbb requires at least a Pentium 4 on i386). For some more notes see, e.g. #776812 [2]. Hope that help. Gert [1] https://www.debian.org/doc/debian-policy/ch-files.html [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776812 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1422920082.5642.17.ca...@gmail.com
Re: build flags handling
On Tue, 3 Feb 2015 00:56:40 +0200, Nico Schlömernico.schloe...@gmail.com wrote: Hi everyone, I recently came across a package [1] which ideally would like to handle its own build flags (adding `-O3 -ffast-math` for speed, for example). What is the Debian policy on this? Debian Policy wrote: It is up to the package maintainer to decide what compilation options are best for the package. Certain binaries (such as computationally-intensive programs) will function better with certain flags (-O3, for example); feel free to use them. Please use good judgment here. See Debian Policy 10.1: https://www.debian.org/doc/debian-policy/ch-files.html -- Andreas Rönnquist mailingli...@gusnan.se gus...@gusnan.se -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150203001629.29383...@debian-workstation.lan
Re: Re: Re: Useless call to ldconfig and shared libraries issue
On Mon, Feb 2, 2015 at 9:17 PM, Corentin Desfarges wrote: I mean that I get the same error : ./debian/fw4spl/usr/bin/fwLauncher: error while loading shared libraries: libfwCore.so.0: cannot open shared object file: No such file or directory This pair of commands will work: sudo debi /usr/bin/fwLauncher -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6hhuowy2qbhu8+hxkquyuj+xapypdq9yj0kubcnl3k...@mail.gmail.com
Re: Re: Re: Useless call to ldconfig and shared libraries issue
But it doesn't work. What does doesn't work mean? I mean that I get the same error : ./debian/fw4spl/usr/bin/fwLauncher: error while loading shared libraries: libfwCore.so.0: cannot open shared object file: No such file or directory -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54cf78f2.5010...@gmail.com
Re: usage of -mtune=core2 ? (Was: Bug#776812: vsearch: FTBFS on non-x86: uses non-portable flags)
Hi All, Sure, I can do some performance tests. The tests supplied with the software are specifically to test performance so I can run those with various build flags and see what we get. Maybe also enabling link-time optimisation would help here - I've not really played with that myself yet. The documentation says the software has a 64-bit design so quite probably we shouldn't be building this for i386. Cheers, TIM On Mon, Feb 2, 2015, at 10:53 AM, Andreas Tille wrote: Hi Gert, thanks for your helpful comments. On Mon, Feb 02, 2015 at 11:38:20AM +0100, Gert Wollny wrote: Hello, On Mon, 2015-02-02 at 07:51 +0100, Andreas Tille wrote: Hi Mentors, It is very important to build vsearch with the maximum optimisation for speed and thus I wonder whether dropping this option is a good idea or whether I should enable it on i386 and amd64 (the question extends also to freebsd-i386/freebsd-amd64 once an other issue in freebsd with this package is solved). On amd64 sse/sse2 is enabled by default. Tuning the code for a specific processor (i.e. core2) might not be such a good idea, according to the GCC man page one should use -mtune=generic instead: generic: Produce code optimized for the most common IA32/AMD64/EM64T processors. If you know the CPU on which your code will run, then you should use the corresponding -mtune or -march option instead of -mtune=generic. But, if you do not know exactly what CPU users of your application will have, then you should use this option. As new processors are deployed in the marketplace, the behavior of this option will change. Therefore, if you upgrade to a newer version of GCC, code generation controlled by this option will change to reflect the processors that are most common at the time that version of GCC is released. Tim, could you clarify with upstream if they agree that -mtune=generic is the option that should be used? In this case my patch in svn I prepared in advance (x86_spezific_opts.patch) should be dropped. In addition, with itksnap I saw that -funroll-loops and -ftree-vectorize improved performance a lot, and these are options that do not depend on the architecture, but are also not enabled by default. -funroll-loops may also slow down the code, you should check this. It is especially effective if there are many small loops of fixed size (like it is the case with ITK's types that are templated over dimensions). -ftree-vectorize may be useless on x86 without SSE but on amd64 it could give some speedups. Tim, could you do some performance checks? I have no idea whether the usual upstream test suite is a proper check for this. Kind regards Andreas. -- http://fam-tille.de -- Of course I'm a technophobe; I program computers for a living! -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1422875895.2847044.221904073.34086...@webmail.messagingengine.com
Re: usage of -mtune=core2 ? (Was: Bug#776812: vsearch: FTBFS on non-x86: uses non-portable flags)
Hello, On Mon, 2015-02-02 at 07:51 +0100, Andreas Tille wrote: Hi Mentors, It is very important to build vsearch with the maximum optimisation for speed and thus I wonder whether dropping this option is a good idea or whether I should enable it on i386 and amd64 (the question extends also to freebsd-i386/freebsd-amd64 once an other issue in freebsd with this package is solved). On amd64 sse/sse2 is enabled by default. Tuning the code for a specific processor (i.e. core2) might not be such a good idea, according to the GCC man page one should use -mtune=generic instead: generic: Produce code optimized for the most common IA32/AMD64/EM64T processors. If you know the CPU on which your code will run, then you should use the corresponding -mtune or -march option instead of -mtune=generic. But, if you do not know exactly what CPU users of your application will have, then you should use this option. As new processors are deployed in the marketplace, the behavior of this option will change. Therefore, if you upgrade to a newer version of GCC, code generation controlled by this option will change to reflect the processors that are most common at the time that version of GCC is released. In addition, with itksnap I saw that -funroll-loops and -ftree-vectorize improved performance a lot, and these are options that do not depend on the architecture, but are also not enabled by default. -funroll-loops may also slow down the code, you should check this. It is especially effective if there are many small loops of fixed size (like it is the case with ITK's types that are templated over dimensions). -ftree-vectorize may be useless on x86 without SSE but on amd64 it could give some speedups. hope that helps. Gert signature.asc Description: This is a digitally signed message part
Bug#776797: marked as done (RFS: openstreetmap-map-icons/1:0.0.svn30932-1~exp1)
Your message dated Mon, 02 Feb 2015 13:01:18 +0100 with message-id 54cf670e.6030...@xs4all.nl and subject line RFS: openstreetmap-map-icons/1:0.0.svn30932-1~exp1 [uploaded] has caused the Debian Bug report #776797, regarding RFS: openstreetmap-map-icons/1:0.0.svn30932-1~exp1 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 776797: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776797 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package openstreetmap-map-icons Package name: openstreetmap-map-icons Version : 1:0.0.svn30932-1~exp1 Upstream Author : Joerg Ostertag jo...@ostertag.name Guenther Meyer d@sordimusic.com. URL : http://wiki.openstreetmap.org/index.php/Map_Icons License : public-domain Section : utils It builds those binary packages: openstreetmap-map-icons-classic - Collection of map icons (classic set) openstreetmap-map-icons-square - Collection of map icons (square set) openstreetmap-map-icons-scalable - Collection of map icons (scalable set) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/openstreetmap-map-icons Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/o/openstreetmap-map-icons/openstreetmap-map-icons_1:0.0.svn30932-1~exp1.dsc More information about openstreetmap-map-icons can be obtained from http://wiki.openstreetmap.org/index.php/Map_Icons. Changes since the last upload: * New upstream SVN snapshot. Regards, Bas Couwenberg ---End Message--- ---BeginMessage--- Thanks to Andreas Tille for sponsoring the upload, the package was accepted into experimental.---End Message---
Bug#776792: marked as done (RFS: josm/0.0.svn7995+dfsg1-1~exp1)
Your message dated Mon, 02 Feb 2015 13:00:58 +0100 with message-id 54cf66fa.2060...@xs4all.nl and subject line RFS: josm/0.0.svn7995+dfsg1-1~exp1 [uploaded] has caused the Debian Bug report #776792, regarding RFS: josm/0.0.svn7995+dfsg1-1~exp1 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 776792: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776792 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package josm Package name: josm Version : 0.0.svn7995+dfsg1-1~exp1 Upstream Author : JOSM Developers josm-...@openstreetmap.org URL : http://josm.openstreetmap.de License : GPL-2+ Section : utils It builds those binary packages: josm - Editor for OpenStreetMap josm-l10n - Editor for OpenStreetMap - translation files To access further information about this package, please visit the following URL: http://mentors.debian.net/package/josm Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/j/josm/josm_0.0.svn7995+dfsg1-1~exp1.dsc More information about JOSM can be obtained from http://josm.openstreetmap.de. Changes since the last upload: * New tested snapshot. * Drop runtime dependency on ant, its bzip2 support is no longer used. * Refresh patches. Regards, Bas Couwenberg ---End Message--- ---BeginMessage--- Thanks to Andreas Tille for sponsoring the upload, the package was accepted into experimental.---End Message---
Re: usage of -mtune=core2 ? (Was: Bug#776812: vsearch: FTBFS on non-x86: uses non-portable flags)
Hi Gert, thanks for your helpful comments. On Mon, Feb 02, 2015 at 11:38:20AM +0100, Gert Wollny wrote: Hello, On Mon, 2015-02-02 at 07:51 +0100, Andreas Tille wrote: Hi Mentors, It is very important to build vsearch with the maximum optimisation for speed and thus I wonder whether dropping this option is a good idea or whether I should enable it on i386 and amd64 (the question extends also to freebsd-i386/freebsd-amd64 once an other issue in freebsd with this package is solved). On amd64 sse/sse2 is enabled by default. Tuning the code for a specific processor (i.e. core2) might not be such a good idea, according to the GCC man page one should use -mtune=generic instead: generic: Produce code optimized for the most common IA32/AMD64/EM64T processors. If you know the CPU on which your code will run, then you should use the corresponding -mtune or -march option instead of -mtune=generic. But, if you do not know exactly what CPU users of your application will have, then you should use this option. As new processors are deployed in the marketplace, the behavior of this option will change. Therefore, if you upgrade to a newer version of GCC, code generation controlled by this option will change to reflect the processors that are most common at the time that version of GCC is released. Tim, could you clarify with upstream if they agree that -mtune=generic is the option that should be used? In this case my patch in svn I prepared in advance (x86_spezific_opts.patch) should be dropped. In addition, with itksnap I saw that -funroll-loops and -ftree-vectorize improved performance a lot, and these are options that do not depend on the architecture, but are also not enabled by default. -funroll-loops may also slow down the code, you should check this. It is especially effective if there are many small loops of fixed size (like it is the case with ITK's types that are templated over dimensions). -ftree-vectorize may be useless on x86 without SSE but on amd64 it could give some speedups. Tim, could you do some performance checks? I have no idea whether the usual upstream test suite is a proper check for this. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150202105338.gr26...@an3as.eu
Re: Re: Useless call to ldconfig and shared libraries issue
Since it sounds like libfwCore.so.0 is supposed to be a private library so I think the correct solution here is for upstream to build the binary using an rpath rather than turning it into a public library placed in a different path. I've already try something like : export DEB_LDFLAGS_MAINT_APPEND = -Wl,--no-as-needed -Wl,-rpath=/usr/lib/fw4spl -ldl But it doesn't work. Is it something like it that you were talking by rpath ? Corentin -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54cf5ddc.5050...@gmail.com
Re: Re: Useless call to ldconfig and shared libraries issue
On Mon, Feb 2, 2015 at 7:22 PM, Corentin Desfarges wrote: I've already try something like : -Wl,-rpath=/usr/lib/fw4spl Is it something like it that you were talking by rpath ? Yes. But it doesn't work. What does doesn't work mean? -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6em10lsxbu_qj3tqduaxsqdk+bdcigd2qffsdo6xc-...@mail.gmail.com
Bug#776855: RFS: iep/3.5-1 -- Interactive Editor for Python
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package iep: * Package name: iep Version : 3.5 Upstream Author : Almar Klein almar.kl...@gmail.com * URL : http://www.iep-project.org/ * License : BSD Programming Lang: Python Description : Interactive Editor for Python It builds the following binary packages: iep -- iep desktop application python-ieplib -- application runtime modules iep-common -- arch-independent resource files To access further information about this package, please visit the following URL: http://anonscm.debian.org/gitweb/?p=debian-science/packages/iep.git I am intending to ask for a sponsor via the sponsorship of blends. Changes since the last upload: Initial release (Closes: #772820) Additional remarks: Extra care has been taken to enable easy backporting of the package to earlier LTS-like distributions such as Ubuntu 12.04, 14.04 or Debian Wheezy. A PPA is available for testing on Ubuntu, with 12.04, 14.04 and 14.10 builds: https://launchpad.net/~ghisvail/+archive/ubuntu/iep Best regards, Ghislain -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1422890875.2090.75.ca...@gmail.com
Re: Useless call to ldconfig and shared libraries issue
Le 02/02/2015 14:17, Corentin Desfarges a écrit : But it doesn't work. What does doesn't work mean? I mean that I get the same error : ./debian/fw4spl/usr/bin/fwLauncher: error while loading shared libraries: libfwCore.so.0: cannot open shared object file: No such file or directory Dear Corentin, When does this error appear? Is that when running the test suite? Do you also have the same error once the package is installed? Kind regards, Thibaut. -- signature.asc Description: OpenPGP digital signature
Bug#776855: RFS: iep/3.5-1 -- Interactive Editor for Python
I just added iep to the numericalcomputation task [1] and added an entry to the SoB table [2]. Cheers, Ghislain [1] http://blends.debian.org/science/tasks/numericalcomputation [2] https://wiki.debian.org/DebianPureBlends/SoB 2015-02-02 15:27 GMT+00:00 Ghislain Vaillant ghisv...@gmail.com: Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package iep: * Package name: iep Version : 3.5 Upstream Author : Almar Klein almar.kl...@gmail.com * URL : http://www.iep-project.org/ * License : BSD Programming Lang: Python Description : Interactive Editor for Python It builds the following binary packages: iep -- iep desktop application python-ieplib -- application runtime modules iep-common -- arch-independent resource files To access further information about this package, please visit the following URL: http://anonscm.debian.org/gitweb/?p=debian-science/packages/iep.git I am intending to ask for a sponsor via the sponsorship of blends. Changes since the last upload: Initial release (Closes: #772820) Additional remarks: Extra care has been taken to enable easy backporting of the package to earlier LTS-like distributions such as Ubuntu 12.04, 14.04 or Debian Wheezy. A PPA is available for testing on Ubuntu, with 12.04, 14.04 and 14.10 builds: https://launchpad.net/~ghisvail/+archive/ubuntu/iep Best regards, Ghislain -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1422890875.2090.75.ca...@gmail.com
Re: Useless call to ldconfig and shared libraries issue
Hi, I'm still working on the packaging of fw4spl (a medical software) for the Debian-Med project [1], and I'm faced to an issue for a few days. I've this lintian warnings ; W: fw4spl: postinst-has-useless-call-to-ldconfig W: fw4spl: postrm-has-useless-call-to-ldconfig Are you 100% sure you need a ld.so.conf snipper for the packages to work? There are better ways to use libraries installed into private paths. I install libraries into /usr/lib/fw4spl (fw4spl is the name of my package) I'm not sure that I need a ld.so.conf snipper, but I'm sure that the software doesn't work when I don't use it. I get this error : ./debian/fw4spl/usr/bin/fwLauncher: error while loading shared libraries: libfwCore.so.0: cannot open shared object file: No such file or directory Thank you for your help, Corentin -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54cf3a29.2030...@gmail.com
Re: Useless call to ldconfig and shared libraries issue
(To be clear, those are NOT the commands Lintian is complaining about. The allegedly useless calls to ldconfig were automatically generated by debhelper.) This is incorrect. You must not put anything to /etc/ld.so.conf.d/. This directory is reserved for glibc and for the system administrator. Moreover, the postrm script is not idempotent, which is also a serious bug. because the shared libraries weren't found by ldconfig. Could you explain what exactly was wrong? When I try to launch my software, I get this error : ./debian/fw4spl/usr/bin/fwLauncher: error while loading shared libraries: libfwCore.so.0: cannot open shared object file: No such file or directory And by using echo '/usr/lib/fw4spl' /etc/ld.so.conf.d/fw4spl.conf , I fixed this error... Thanks for your help, Corentin -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54cf3c95.7060...@gmail.com
Re: Useless call to ldconfig and shared libraries issue
On Mon, Feb 2, 2015 at 5:00 PM, Corentin Desfarges wrote: When I try to launch my software, I get this error : ./debian/fw4spl/usr/bin/fwLauncher: error while loading shared libraries: libfwCore.so.0: cannot open shared object file: No such file or directory And by using echo '/usr/lib/fw4spl' /etc/ld.so.conf.d/fw4spl.conf , I fixed this error... Since it sounds like libfwCore.so.0 is supposed to be a private library so I think the correct solution here is for upstream to build the binary using an rpath rather than turning it into a public library placed in a different path. -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6gynntsswtkjmj3w6en-ua+vssboerntkgsmg6kk_g...@mail.gmail.com
