RFS: loopdub
Dear mentors, I am looking for a sponsor for my package "loopdub". * Package name: loopdub Version : 0.4-1 Upstream Author : Stephen Sinclair * URL : http://loopdub.sf.net * License : GPLv2 Section : sound It builds these binary packages: loopdub- Software for live audio loop manipulation. The package appears to be lintian clean. The upload would fix these bugs: 588054 My motivation for maintaining this package is: It is my software that I use for live music performances. After receiving several requests for help on how to build it, I decided to try to package it for Debian so that users would have an easier time finding and installing it. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/loopdub - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/loopdub/loopdub_0.4-1.dsc I would be glad if someone uploaded this package for me. Thank you Stephen Sinclair -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinmagn_+bzrqrtmc-x8-+0dh1von=ajsxn5d...@mail.gmail.com
question about proprietary libraries
Hello, This is a general question about linking to proprietary libraries. Specifically I am thinking about developing a library which will work normally in the general case, but in some cases the user might have a proprietary library installed on their system, in which case I'd like to dynamically load that library and call out to its functions. The proprietary library in this case would be for doing I/O with a particular hardware device, for which there is currently no open source alternative. Therefore the user owning such a device would have installed the software and expect my library to work with it. Conversely, he would not have the proprietary library unless he has the device in question.. so I sort of think of this library as being "part of" the device. I don't have the ability to reverse engineer it and write my own drivers, but I'd still like users of this device to be able to make use of my software. Would such a library have difficulty getting accepted by Debian? Are there other examples of libraries in Debian which optionally leverage proprietary code if it is available? thanks, Steve -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=k5pyo6j4843t_-giynsrboresbn4=xtqqj...@mail.gmail.com
Re: question about proprietary libraries
On Thu, Sep 2, 2010 at 5:48 AM, Peter Pentchev wrote: > On Thu, Sep 02, 2010 at 11:28:54AM +0200, Julien Viard de Galbert wrote: >> On Thu, Sep 02, 2010 at 05:03:40AM -0300, Rogério Brito wrote: >> > Hi there. >> > >> > On Sep 01 2010, Stephen Sinclair wrote: >> > > I don't have the ability to reverse engineer it and write my own >> > > drivers, but I'd still like users of this device to be able to make >> > > use of my software. >> > >> > Right. You can dlopen the library, depending on the case. Your program >> > will still be Free, in the same sense that the Linux Kernel is Free. >> > You may want to check the license that you will eventually use: I think >> > that the GPL wouldn't cut it, but the LGPL might. >> > >> > > Would such a library have difficulty getting accepted by Debian? >> > >> > The library, yes. Your program? No, depending on how "dependent" the >> > program would be on that library. If the use of said devices is just a >> > minor part of the program's role, then it may be accepted into main, >> > without any problems. >> > >> I find it a little confusing, he was first saying he wants to write a >> _library_, than can uses a proprietary library. >> >> What I understand is that his library (the one he want to write) could >> be accepted to main if it is useful without the proprietary library >> (that can be considered as a hardware driver). Then any program using it >> could also go to main (provided that no other dependency would require >> it to be contrib or non-free). > > That's how I understand the situation, FWIW. > > The whole thing might become a bit clearer with a real example of > a library that is already in Debian main, and that may optionally use > another library that is not in Debian. Take a look at the libdvdread4 > package, and specifically at how /usr/share/doc/libdvdread4/README.Debian > documents its relationship with the libdvdcss library which is not > in Debian. The libdvdread4 library is useful even without libdvdcss, > but its operation is enhanced by libdvdcss's presence on the system. > > So, basically, yes, this is acceptable, and that's exactly how it is done. Okay thank you, this basically answers my question. By the way to clarify, yes it is the development of a library which may optionally use a vendor-provided library for accessing a particular device. I would like to make it easier for open source developers to develop software for this class of devices, some which have open source drivers and some which don't. That is, it will eventually lead to applications, but first is to develop a simple library. Now that I know it's not entirely hopeless, I will work on this project and then if specific issues arise at least I know there is some precedence to refer to in this situation. Final question on this topic: What about the fact that to use some vendor library functions, (even if it is dlopen'ed), it is necessary to include headers from the vendor library? (Or at least to port the function prototypes, although likely some structs and enums are also necessary.) Would this in any way affect future packaging issues? I will assume for now that the vendor's policy is to allow people to distribute their header files, since otherwise I can't think of any legal way to write open source software that would use their device. thanks, Steve -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikjdxjw5zvcwcdkpj9gd=rwnpeg2k-h24169...@mail.gmail.com
Re: question about proprietary libraries
On Thu, Sep 2, 2010 at 1:10 PM, The Fungi wrote: > On Thu, Sep 02, 2010 at 12:46:09PM -0400, Stephen Sinclair wrote: > [...] >> I will assume for now that the vendor's policy is to allow people >> to distribute their header files, since otherwise I can't think of >> any legal way to write open source software that would use their >> device. > > Do you have a (legally sound) reason to believe that the vendor even > cares whether people write open source software for this device? For > that matter, do you know that their header files aren't licensed to > them by some non-transferrable agreement which allows the vendor to > provide a copy to you but doesn't entitle you to pass them along to > anyone else? Not as far as I know, but I'll have to read the license in more detail. I'm assuming for now that the headers are allowed to be distributed. (For example, they can be found in their freely available documentation.) There are currently some other open source projects (not in Debian) which are already dlopen'ing the library in question, so I think they are okay with it. Steve -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikgshooyb-rxmatcaeuv5hirdtzgwamqfmnc...@mail.gmail.com
Bug#881118: RFS: boost-numeric-bindings/0.99-1 [ITP] -- Numeric Library Bindings for Boost
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "boost-numeric-bindings": * Package name: boost-numeric-bindings Version : 0.99 Upstream Author : Kresimir Fresl et. al. * URL : https://github.com/uBLAS/numeric_bindings * License : Boost Software License - Version 1.0 Programming Lang: C++ Description : boost-numeric-bindings -- Numeric Library Bindings for Boost Boost Bindings is a bindings library (not just) for Boost.Ublas. It offers an easy way of calling BLAS, LAPACK, UMFPACK, MUMPS and many other mature legacy numerical codes from within C++. The package source may be found at: http://anonscm.debian.org/cgit/debian-science/packages/boost-numeric-bindings.git And the package description may be found at: https://mentors.debian.net/debian/pool/main/b/boost-numeric-bindings/boost-numeric-bindings_0.99-1.dsc Previously an ITP bug was filed by someone else (#536270) but then dropped. Since then a github repo was created by an upstream author and a "pre-release 0.99" was released with a bit more work, in 2015. I have updated the preliminary package by Teemu Ikonen from that bug to the latest version, as well as the latest Debian compat and policy versions. This version of the package installs the header files to the /usr/include/boost directory. Please note that this version 0.99 did not include a LICENSE file in the main directory, however all files nonetheless still have a reference to their license at the top and it remains the same as in debian/copyright. (I have filed an upstream issue to restore the license file.) Preliminary support for running some of the tests should hopefully come in the near future. I intend to improve this, add documentation if possible, and keep it up to date with any future releases. It would be beneficial to Debian to have these headers more easily available, since projects are currently often embedding them in their source distributions.
Bug#894128: RFS: fclib/3.0.0 -- read and write problems in the Frictional Contact Library format
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "fclib": * Package name: fclib Version : 3.0.0-1 Upstream Author : Vincent Acary et al. * URL : https://frictionalcontactlibrary.github.io/ * License : Apache 2.0 Section : libs It builds those binary packages: libfclib0 - library file libfclib-dev - header file To access further information about this package, please visit the following URL: https://mentors.debian.net/package/fclib Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/f/fclib/fclib_3.0.0-1.dsc The package source is maintained on salsa in the science-team group: https://salsa.debian.org/science-team/fclib fclib is an open source collection of Frictional Contact (FC) problems stored in a specific HDF5 format, and an open source light implementation of Input/Output functions in C Language to read and write problems. The goal of this work is to set up a collection of 2D and 3D Frictional Contact (FC) problems in order to set up a list of benchmarks; provide a standard framework for testing available and new algorithms; and share common formulations of problems in order to exchange data. fclib is an open-source scientific software primarily targeted at modeling and simulating nonsmooth dynamical systems This package is also a future dependency of Siconos, a nonsmooth dynamical systems simulator from the same development team, for which I plan to propose a package shortly. More information about fclib can be obtained from https://frictionalcontactlibrary.github.io/ Regards, Stephen Sinclair
Bug#951254: RFS: siconos/4.2.0+git20181026.0ee5349+dfsg.2-2 -- simulation of nonsmooth dynamical systems
Package: sponsorship-requests Severity: important Tags: patch Dear mentors, I am looking for a sponsor for my package "siconos" * Package name: siconos Version : 4.2.0+git20181026.0ee5349+dfsg.2-2 Upstream Author : Siconos Team * URL : http://siconos.gforge.inria.fr * License : Apache * Vcs : https://salsa.debian.org/science-team/siconos Section : science This update fixes some broken tests that block its current build, and closes one bug. It builds these binary packages: siconos - compilation and run tools siconos-mechanics-tools - run tools for mechanics simulations libsiconos-numerics6 - numerics library libsiconos-numerics-dev - numerics dev libsiconos-kernel6 - kernel library libsiconos-kernel-dev - kernel dev libsiconos-control6 - control library libsiconos-control-dev - control dev libsiconos-mechanics6 - mechanics library libsiconos-mechanics-dev - mechanics dev libsiconos-io6 - io library libsiconos-io-dev - io dev python3-siconos - python wrappers To access further information about this package, please visit the following URL: https://mentors.debian.net/package/siconos Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/siconos/siconos_4.2.0+git20181026.0ee5349+dfsg.2-2.dsc Changes since the last upload: [ Stephen Sinclair ] * Patch to fix ref filename for test SMCTest::SMCLsodar. * Add TwistingTest::test_ExplicitTwisting_Lsodar to list of broken tests. * Remove compiler paths and flags in installed CMakeLists.txt. (Closes: #940194) * Update to standards version 4.5.0, no changes necessary. * Update to debhelper compat 12, no changes necessary. * d/copyright: Add Upstream-Contact field. Regards, Steve -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-74-generic (SMP w/12 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect
Bug#954737: RFS: keras-preprocessing/1.1.0+ds-1 -- data preprocessing module for the Keras deep learning framework
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "keras-preprocessing". The package is schedule to be autoremoved tomorrow without this update. * Package name: keras-preprocessing Version : 1.1.0+ds-1 Upstream Author : François Chollet * URL : http://keras.io/ * License : Expat * Vcs : https://salsa.debian.org/science-team/keras-preprocessing Section : science It builds those binary packages: python3-keras-preprocessing - data preprocessing module for the Keras deep learning framework To access further information about this package, please visit the following URL: https://mentors.debian.net/package/keras-preprocessing Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/k/keras-preprocessing/keras-preprocessing_1.1.0+ds-1.dsc Changes since the last upload: * New upstream version 1.1.0. * debian/watch: + add dversionmangle for +ds suffix. * debian/control: + update standard version to 4.5.0 (no changes). Regards, -- Stephen Sinclair
Bug#954740: RFS: keras/2.3.1+dfsg-1 [RC] -- deep learning framework running on Theano or TensorFlow
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "keras". The package is schedule to be autoremoved tomorrow without this update. * Package name: keras Version : 2.3.1+dfsg-1 Upstream Author : François Chollet * URL : http://keras.io/ * License : Expat * Vcs : https://salsa.debian.org/science-team/keras Section : science It builds those binary packages: python3-keras - deep learning framework running on Theano or TensorFlow To access further information about this package, please visit the following URL: https://mentors.debian.net/package/keras Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/k/keras/keras_2.3.1+dfsg-1.dsc Changes since the last upload: [ Stephen Sinclair ] * New upstream version 2.3.1. * debian/watch: + add dversionmangle for +dfsg suffix. * debian/control: + update standards to 4.5.0 (no changes). + add build-dep on python3-flaky. + remove package keras-doc. + update required python version to 3.8. * debian/patches: + refresh patches for new version. + add a tolerance for an activations test. (Closes: #952163) * debian/rules: + ignore two tests requiring unpackaged dependencies. Regards, -- Stephen Sinclair
Bug#954738: RFS: keras-applications/1.0.8+ds-1 -- popular models and pre-trained weights for the Keras deep learning framework
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "keras-applications". The package is scheduled to be autoremoved tomorrow without this update. * Package name: keras-applications Version : 1.0.8+ds-1 Upstream Author : François Chollet * URL : http://keras.io/ * License : Expat * Vcs : https://salsa.debian.org/science-team/keras-applications Section : science It builds those binary packages: python3-keras-applications - popular models and pre-trained weights for the Keras deep learning framework To access further information about this package, please visit the following URL: https://mentors.debian.net/package/keras-applications Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/k/keras-applications/keras-applications_1.0.8+ds-1.dsc Changes since the last upload: * New upstream version 1.0.8. * debian/watch: + add dversionmangle for +ds suffix. * debian/control: + update to standards 4.5.0 (no changes). Regards, -- Stephen Sinclair
Bug#954857: RFS: siconos/4.2.0+git20181026.0ee5349+dfsg.2-3 [RC] -- modeling and simulation of nonsmooth dynamical systems (simulation runner tool)
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "siconos" * Package name: siconos Version : 4.2.0+git20181026.0ee5349+dfsg.2-3 Upstream Author : siconos-t...@lists.gforge.inria.fr * URL : https://nonsmooth.gricad-pages.univ-grenoble-alpes.fr/siconos/index.html * License : Apache-2.0 * Vcs : https://salsa.debian.org/science-team/siconos Section : science It builds those binary packages: siconos - modeling and simulation of nonsmooth dynamical systems (simulation runner tool) siconos-mechanics-tools - modeling and simulation of nonsmooth dynamical systems (mechanics tools) libsiconos-numerics6 - modeling and simulation of nonsmooth dynamical systems (numerics lib) libsiconos-numerics-dev - modeling and simulation of nonsmooth dynamical systems (numerics dev) libsiconos-kernel6 - modeling and simulation of nonsmooth dynamical systems (kernel lib) libsiconos-kernel-dev - modeling and simulation of nonsmooth dynamical systems (kernel dev) libsiconos-control6 - modeling and simulation of nonsmooth dynamical systems (control lib) libsiconos-control-dev - modeling and simulation of nonsmooth dynamical systems (control dev) libsiconos-mechanics6 - modeling and simulation of nonsmooth dynamical systems (mechanics lib) libsiconos-mechanics-dev - modeling and simulation of nonsmooth dynamical systems (mechanics dev) libsiconos-io6 - modeling and simulation of nonsmooth dynamical systems (io lib) libsiconos-io-dev - modeling and simulation of nonsmooth dynamical systems (io dev) python3-siconos - modeling and simulation of nonsmooth dynamical systems (python3) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/siconos Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/siconos/siconos_4.2.0+git20181026.0ee5349+dfsg.2-3.dsc Changes since the last upload: * Patch to remove bad cc options. * Patch to find python3.8 config. * Depend on swig instead of swig3.0. * Backport support for swig4.0. (Closes: #952601) * Removed a failing numerics test. * debian/rules: Remove use of ccache. (Closes: #945613 #954497) * Require Python 3.8. Regards, -- Stephen Sinclair
Bug#954857: RFS: siconos/4.2.0+git20181026.0ee5349+dfsg.2-3 [RC] -- modeling and simulation of nonsmooth dynamical systems (simulation runner tool)
Hello Adam, Thank you for looking at the package. I believe I have fixed the problem now and updated master on salsa. I am trying to re-upload to mentors but no acknowledgement yet after waiting the whole day, I will try again tomorrow. I have now to taught my system to run autopkgtest automatically after sbuild, so hopefully won't make the same mistake again. Incidentally, in the interim I have been informed by upstream that a new version is coming soon so I will be updating the package probably again next week, but it would be good to get this fix in anyways since I don't know exactly how long that will be. regards, Steve On Thu, Mar 26, 2020 at 3:03 AM Adam Borowski wrote: > > On Tue, Mar 24, 2020 at 03:17:31PM +0100, Stephen Sinclair wrote: > > * Package name: siconos > >Version : 4.2.0+git20181026.0ee5349+dfsg.2-3 > > > Changes since the last upload: > > > >* Patch to remove bad cc options. > >* Patch to find python3.8 config. > >* Depend on swig instead of swig3.0. > >* Backport support for swig4.0. (Closes: #952601) > >* Removed a failing numerics test. > >* debian/rules: Remove use of ccache. (Closes: #945613 #954497) > >* Require Python 3.8. > > Hi! > I'm afraid that while the package builds, it fails tests: > > autopkgtest [02:57:15]: summary > kernel-dev PASS > numerics-tests FAIL non-zero exit status 2 > kernel-tests FAIL non-zero exit status 2 > control-testsFAIL non-zero exit status 2 > kernel-tests-python PASS > control-tests-python PASS > mechanics-tests FAIL non-zero exit status 2 > mechanics-tests-python PASS > mechanics-tools PASS > > Full log attached. > > > Meow! > -- > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. > ⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi > ⠈⠳⣄
Bug#954857: RFS: siconos/4.2.0+git20181026.0ee5349+dfsg.2-3 [RC] -- modeling and simulation of nonsmooth dynamical systems (simulation runner tool)
The package has been updated on mentors. regards, Steve On Thu, Mar 26, 2020 at 9:57 PM Stephen Sinclair wrote: > > Hello Adam, > > Thank you for looking at the package. > I believe I have fixed the problem now and updated master on salsa. > I am trying to re-upload to mentors but no acknowledgement yet after > waiting the whole day, I will try again tomorrow. > > I have now to taught my system to run autopkgtest automatically after > sbuild, so hopefully won't make the same mistake again. > > Incidentally, in the interim I have been informed by upstream that a > new version is coming soon so I will be updating the package probably > again next week, but it would be good to get this fix in anyways since > I don't know exactly how long that will be. > > regards, > Steve > > > On Thu, Mar 26, 2020 at 3:03 AM Adam Borowski wrote: > > > > On Tue, Mar 24, 2020 at 03:17:31PM +0100, Stephen Sinclair wrote: > > > * Package name: siconos > > >Version : 4.2.0+git20181026.0ee5349+dfsg.2-3 > > > > > Changes since the last upload: > > > > > >* Patch to remove bad cc options. > > >* Patch to find python3.8 config. > > >* Depend on swig instead of swig3.0. > > >* Backport support for swig4.0. (Closes: #952601) > > >* Removed a failing numerics test. > > >* debian/rules: Remove use of ccache. (Closes: #945613 #954497) > > >* Require Python 3.8. > > > > Hi! > > I'm afraid that while the package builds, it fails tests: > > > > autopkgtest [02:57:15]: summary > > kernel-dev PASS > > numerics-tests FAIL non-zero exit status 2 > > kernel-tests FAIL non-zero exit status 2 > > control-testsFAIL non-zero exit status 2 > > kernel-tests-python PASS > > control-tests-python PASS > > mechanics-tests FAIL non-zero exit status 2 > > mechanics-tests-python PASS > > mechanics-tools PASS > > > > Full log attached. > > > > > > Meow! > > -- > > ⢀⣴⠾⠻⢶⣦⠀ > > ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. > > ⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi > > ⠈⠳⣄
package prevented from migration due to "regression", but regression bug is fixed
Hello mentors, An update to my package siconos was recently uploaded to fix some outstanding bugs. However, I have noticed that it has been blocked and prevented from migration to testing: https://qa.debian.org/excuses.php?package=siconos The reason given is "introduces new bugs", however the bug indicated, #954497, is one that was _fixed_ by my update. I created a fresh sbuild chroot and rebuilt the package without errors, moreover it appears to build fine on buildd. It is possible my update simply did not trigger a close on the bug? In the changelog I wrote, "(Closes: #945613 #954497)" Is this not the correct syntax for fixing multiple bugs? If I manually close the bug, will it then migrate automatically? thanks, Steve
Re: package prevented from migration due to "regression", but regression bug is fixed
Thanks for the reply and to Adam Borowski for closing the bug and having it migrate to testing for me. On Fri, Apr 10, 2020 at 4:56 PM Mattia Rizzolo wrote: > > On Fri, Apr 10, 2020 at 04:51:01PM +0200, Stephen Sinclair wrote: > That's because you didn't close the bug in the upload. >* debian/rules: Remove use of ccache. (Closes: #945613 #954497) > > Is this not the correct syntax for fixing multiple bugs? > you'd need a comma to list more than bug after the 'Closes:', so it > wasn't closed. Thank you, I am confused because I actually checked the policy manual carefully before doing this, and it clearly states that multiple bugs should be space-separated. Is it an error in the document? https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-closes > 5.6.22. Closes > > A space-separated list of bug report numbers that the upload governed by the > .changes file closes. > > If I manually close the bug, will it then migrate automatically? > > yes, that's exactly what you'll need to do. Also, it would be better if > you closed it with a fixed version as well. Ok, I will skip this since it was closed by someone else but in the future it would require a package update, got it. regards, Steve
Bug#962441: RFS: siconos/4.3.0+dfsg-1 [RC] -- modeling and simulation of nonsmooth dynamical systems (simulation runner tool)
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "siconos" * Package name: siconos Version : 4.3.0+dfsg-1 Upstream Author : siconos-t...@lists.gforge.inria.fr * URL : https://nonsmooth.gricad-pages.univ-grenoble-alpes.fr/siconos/index.html * License : Apache-2.0 * Vcs : https://salsa.debian.org/science-team/siconos Section : science It builds those binary packages: siconos - modeling and simulation of nonsmooth dynamical systems (simulation runner tool) siconos-mechanics-tools - modeling and simulation of nonsmooth dynamical systems (mechanics tools) libsiconos-numerics6 - modeling and simulation of nonsmooth dynamical systems (numerics lib) libsiconos-numerics-dev - modeling and simulation of nonsmooth dynamical systems (numerics dev) libsiconos-kernel6 - modeling and simulation of nonsmooth dynamical systems (kernel lib) libsiconos-kernel-dev - modeling and simulation of nonsmooth dynamical systems (kernel dev) libsiconos-control6 - modeling and simulation of nonsmooth dynamical systems (control lib) libsiconos-control-dev - modeling and simulation of nonsmooth dynamical systems (control dev) libsiconos-mechanics6 - modeling and simulation of nonsmooth dynamical systems (mechanics lib) libsiconos-mechanics-dev - modeling and simulation of nonsmooth dynamical systems (mechanics dev) libsiconos-io6 - modeling and simulation of nonsmooth dynamical systems (io lib) libsiconos-io-dev - modeling and simulation of nonsmooth dynamical systems (io dev) python3-siconos - modeling and simulation of nonsmooth dynamical systems (python3) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/siconos Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/siconos/siconos_4.3.0+dfsg-1.dsc Testing this package requires fclib 3.1.0+dfsg-1, which also needs sponsorship. It can be found here: https://mentors.debian.net/package/fclib and can get downloading with dget using: dget -x https://mentors.debian.net/debian/pool/main/s/fclib/fclib_3.1.0+dfsg-1.dsc Changes since the last upload: * New upstream version. (Closes: #962219) (Closes: #961735) * Add dependencies libboost-timer-dev, libboost-chrono-dev. * Depend on openblas and lapacke instead of atlas. * Require fclib 3.1.0 * Update location of install paths. * Enable WITH_GENERATION, now required for serialization. * Install new siconos_export_raw_data tool. * Fix cmake import targets to allow independent packages. * Update patches for new upstream version. * Add a flag for gfortran to avoid a regression in GCC-10. (Closes: #957794) * Remove unused build rule for swig3.0 symlink. * Remove non-existent files from debian/copyright. * Rewrite patch descriptions using gbp pq. * Fix a Python warning about using 'is' with a literal. Regards, -- Stephen Sinclair
Bug#962441: RFS: siconos/4.3.0+dfsg-1 [RC] -- modeling and simulation of nonsmooth dynamical systems (simulation runner tool)
Hi Adam, Thanks for taking a look. On Mon, Jun 8, 2020 at 5:29 PM Adam Borowski wrote: > > On Mon, Jun 08, 2020 at 07:37:26AM +0200, Stephen Sinclair wrote: > > * Package name: siconos > >Version : 4.3.0+dfsg-1 > > But > > > Testing this package requires fclib 3.1.0+dfsg-1, which also needs > > sponsorship. It can be found here: > > > > https://mentors.debian.net/package/fclib > > so thats actually two RFSes in one. And there are problems with fclib. I'm not sure what the right protocol is in this case, to be honest. Should I have issued two RFSes or done this one differently? > > Changes since the last upload: > > > >* New upstream version. (Closes: #962219) (Closes: #961735) > >* Add dependencies libboost-timer-dev, libboost-chrono-dev. > >* Depend on openblas and lapacke instead of atlas. > >* Require fclib 3.1.0 > >* Update location of install paths. > >* Enable WITH_GENERATION, now required for serialization. > >* Install new siconos_export_raw_data tool. > >* Fix cmake import targets to allow independent packages. > >* Update patches for new upstream version. > >* Add a flag for gfortran to avoid a regression in GCC-10. > > (Closes: #957794) > >* Remove unused build rule for swig3.0 symlink. > >* Remove non-existent files from debian/copyright. > >* Rewrite patch descriptions using gbp pq. > >* Fix a Python warning about using 'is' with a literal. > > It looked ok on my box, and passed both all automated and manual review I've > done. But, it fails on some of official buildds: at least on amd64 arm64 > x32. > > I seem unable to reproduce the FTBFS locally -- in 15 tries on amd64, 1 on > arm64, all passed. > > Thus, you'd need to investigate and fix that one in fclib first. I'm very confused about the error on buildd because I have indeed built the package many times with a fresh debootstrap without such a segfault. I will investigate and try to reproduce. I did my best to avoid problems but it seems I have missed something, I'd like to understand the difference between buildd and my own configuration to avoid this happening in the future. By the way Siconos due to its nature has been quite hard to get working on any architecture other than amd64 unfortunately. Is there a way to mark the package as amd64-only? In the meantime I try to find solutions for other architectures but it is slow going. > It'd be good if you filed a separate RFS for that. Let's leave this one > for siconos 4.3.0+dfsg-1 Okay that sounds like a reasonable approach given this problem. regards, Steve
Bug#962684: RFS: fclib/3.1.0+dfsg-2 -- read and write problems from the Friction Contact Library (library)
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "fclib" * Package name: fclib Version : 3.1.0+dfsg-2 Upstream Author : fclib-proj...@lists.gforge.inria.fr * URL : https://frictionalcontactlibrary.github.io/ * License : Apache-2.0 * Vcs : https://salsa.debian.org/science-team/fclib Section : science It builds those binary packages: libfclib0 - read and write problems from the Friction Contact Library (library) libfclib-dev - read and write problems from the Friction Contact Library (headers) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/fclib Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/f/fclib/fclib_3.1.0+dfsg-2.dsc Changes since the last upload: * Patch wrong argument to cs_transpose which leads to segfault. (Closes: #927761) The previous upload, 3.1.0+dfsg-1, failed on buildd and this patch fixes the problem. This package is required for siconos 4.3.0+dfsg-1, uploaded in parallel, with RFS #962441: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962441 Regards, -- Stephen Sinclair
Bug#962441: RFS: siconos/4.3.0+dfsg-1 [RC] -- modeling and simulation of nonsmooth dynamical systems (simulation runner tool)
The problem turned out to be a real bug (null dereference) that only occurred occasionally due to poor testing procedures (test includes some randomization in the code path). The bug has been patched and a separate RFS for fclib has been filed, #962684. regards, Steve On Mon, Jun 8, 2020 at 6:09 PM Stephen Sinclair wrote: > > Hi Adam, > > Thanks for taking a look. > > On Mon, Jun 8, 2020 at 5:29 PM Adam Borowski wrote: > > > > On Mon, Jun 08, 2020 at 07:37:26AM +0200, Stephen Sinclair wrote: > > > * Package name: siconos > > >Version : 4.3.0+dfsg-1 > > > > But > > > > > Testing this package requires fclib 3.1.0+dfsg-1, which also needs > > > sponsorship. It can be found here: > > > > > > https://mentors.debian.net/package/fclib > > > > so thats actually two RFSes in one. And there are problems with fclib. > > I'm not sure what the right protocol is in this case, to be honest. > Should I have issued two RFSes or done this one differently? > > > > Changes since the last upload: > > > > > >* New upstream version. (Closes: #962219) (Closes: #961735) > > >* Add dependencies libboost-timer-dev, libboost-chrono-dev. > > >* Depend on openblas and lapacke instead of atlas. > > >* Require fclib 3.1.0 > > >* Update location of install paths. > > >* Enable WITH_GENERATION, now required for serialization. > > >* Install new siconos_export_raw_data tool. > > >* Fix cmake import targets to allow independent packages. > > >* Update patches for new upstream version. > > >* Add a flag for gfortran to avoid a regression in GCC-10. > > > (Closes: #957794) > > >* Remove unused build rule for swig3.0 symlink. > > >* Remove non-existent files from debian/copyright. > > >* Rewrite patch descriptions using gbp pq. > > >* Fix a Python warning about using 'is' with a literal. > > > > It looked ok on my box, and passed both all automated and manual review I've > > done. But, it fails on some of official buildds: at least on amd64 arm64 > > x32. > > > > I seem unable to reproduce the FTBFS locally -- in 15 tries on amd64, 1 on > > arm64, all passed. > > > > Thus, you'd need to investigate and fix that one in fclib first. > > I'm very confused about the error on buildd because I have indeed > built the package many times with a fresh debootstrap without such a > segfault. I will investigate and try to reproduce. > > I did my best to avoid problems but it seems I have missed something, > I'd like to understand the difference between buildd and my own > configuration to avoid this happening in the future. > > By the way Siconos due to its nature has been quite hard to get > working on any architecture other than amd64 unfortunately. Is there > a way to mark the package as amd64-only? > In the meantime I try to find solutions for other architectures but it > is slow going. > > > It'd be good if you filed a separate RFS for that. Let's leave this one > > for siconos 4.3.0+dfsg-1 > > Okay that sounds like a reasonable approach given this problem. > > regards, > Steve
Bug#963621: RFS: keras/2.3.1+dfsg-2 [RC] -- deep learning framework running on Theano or TensorFlow
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "keras" * Package name: keras Version : 2.3.1+dfsg-2 Upstream Author : François Chollet * URL : https://keras.io/ * License : Expat * Vcs : https://salsa.debian.org/science-team/keras Section : science It builds those binary packages: python3-keras - deep learning framework running on Theano or TensorFlow To access further information about this package, please visit the following URL: https://mentors.debian.net/package/keras Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/k/keras/keras_2.3.1+dfsg-2.dsc Changes since the last upload: * debian/patches: + fix test regression for python3-h5py 2.10.0-8. (Closes: #963426) The package will not be updated to Keras release 2.4.0 due to end-of-life. In the future Keras will be included in TensorFlow, which is not yet available in Debian; when it is, this package will be removed, but until then this package remains the principle way to include Keras in Debian. Please read: https://github.com/keras-team/keras/releases/tag/2.4.0 This update fixes a small problem with a test due to updates to python3-h5py. Regards, -- Stephen Sinclair
avoiding autoremoval for what seems like a spurious build error
Hi Mentors, My package siconos currently has a bug filed [1] and has been marked for autoremoval from testing. The problem is that I cannot reproduce it. The failure is on a test that depends on another package, so I am wondering if there was just a glitch here? I have replied to the bug report with working build logs, but there has been no further activity, so I am not sure what further action I can take to avoid that the package gets removed. Thanks for any help. Steve [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986515
Re: avoiding autoremoval for what seems like a spurious build error
Thanks for the responses and attempts to build! Yes, it takes quite a bit of memory unfortunately, due to some very large auto-generated swig wrappers combined with some complicated boost usage. In any case, I was not so much asking for help building/reproducing, as I was asking what I can do other than to reply to the bug, which seems not to be eliciting a response, to either avoid or delay the auto-removal process. Is auto-removal policy documented somewhere? Unfortunately all my searches turn up "apt-get autoremove" help instead. I am really worried the package will get removed from the upcoming Debian release because of this. regards, Steve On Thu, Apr 29, 2021 at 11:47 PM Eriberto Mota wrote: > > I used a trivial jail with chroot. I can't reproduce the issue. > > Regards, > > Eriberto > > > Em qui., 29 de abr. de 2021 às 18:30, Tobias Frost escreveu: > > > > On Thu, Apr 29, 2021 at 05:25:28PM +0200, Stephen Sinclair wrote: > > > Hi Mentors, > > > > > > My package siconos currently has a bug filed [1] and has been marked > > > for autoremoval from testing. > > > > > The problem is that I cannot reproduce it. The failure is on a test > > > that depends on another package, so I am wondering if there was just a > > > glitch here? I have replied to the bug report with working build > > > logs, but there has been no further activity, so I am not sure what > > > further action I can take to avoid that the package gets removed. > > > > > > Thanks for any help. > > > Steve > > > > > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986515 > > > > I could also not reproduce it in a pbuilder chroot. Might indeed be a glitch > > or some other dependency causing this… > > I'd either downgrade it to non RC and tag it unreproducible or close it with > > the request to reopen if it pops up again. > > > > -- > > tobi > > >
help with python3 depends < 3.11
Dear mentors,
I have been trying to make an update to my package "siconos".
However, in the Salsa build, which nicely runs all tests, it fails on
"piuparts".
The job log is here:
https://salsa.debian.org/science-team/siconos/-/jobs/3796471
I am confused, because it fails with the following error:
> The following packages have unmet dependencies:
> python3-siconos : Depends: python3 (< 3.11) but 3.11.1-1 is to be installed
However, debian/control uses ${python3:Depends} and does not mention
version 3.11 anywhere, so I cannot understand where it's getting this
"< 3.11" constraint from.
Any help would be appreciated, thank you.
Steve
Re: help with python3 depends < 3.11
Thanks very much for the response.
On Mon, Jan 16, 2023 at 10:47 AM Adam Borowski wrote:
>
> On Sun, Jan 15, 2023 at 04:20:35PM +0100, Stephen Sinclair wrote:
> > I have been trying to make an update to my package "siconos".
> > However, in the Salsa build, which nicely runs all tests, it fails on
> > "piuparts".
>
> > I am confused, because it fails with the following error:
> >
> > > The following packages have unmet dependencies:
> > > python3-siconos : Depends: python3 (< 3.11) but 3.11.1-1 is to be
> > > installed
> >
> > However, debian/control uses ${python3:Depends} and does not mention
> > version 3.11 anywhere, so I cannot understand where it's getting this
> > "< 3.11" constraint from.
>
> The package was build for 3.10 only. Then, python3 defaults got changed,
> and now packages are supposed to build 3.11 instead.
>
> Thus, all packages have been rebuilt. But alas:
> https://buildd.debian.org/status/package.php?p=siconos
> is quite red. You'd need to investigate why it fails to build, and upload a
> fix.
Yes, that is why I am working on it. I do have a fix ready, but I am
waiting to upload it because it fails on the Salsa piuparts test.
To be clear, Salsa is rebuilding the package, and giving this error
while testing the build. After inspecting the logs a bit longer, I
realized that what is happening is that piuparts is installing the old
version of the package while testing, and I do not know why.
Basically piuparts tries to install the binary packages one by one of
the new version, 4.4.0+dfsg-2, and it seems that during this process
apt is trying to install the old packages 4.0.0+dfsg-1. These of
course contain constraints on packages that are no longer available in
unstable and so it fails.
I thought it could be because I had not yet marked it for unstable (it
was UNRELEASED), so I ran "dch -r". This changed the error message,
but it simply fails for a different binary package now. (Bullet
instead of Python.)
https://salsa.debian.org/science-team/siconos/-/jobs/3810484
If that's the case, I feel like I can just ignore this and when it's
uploaded the problem will fix itself. Does this mean that it's just a
problem with how piuparts works, or how Salsa is configured for it?
If so I will try to find how to report it.
thanks,
Steve
