Bug#1029596: ITP: scmutils -- scheme mathematical library
Package: wnpp Severity: wishlist Owner: Benda Xu X-Debbugs-Cc: debian-devel@lists.debian.org, s...@l.airelinux.org * Package name: scmutils Version : 20220518 Upstream Contact: Gerald Jay Sussman * URL : https://groups.csail.mit.edu/mac/users/gjs/6946 * License : GPL-2+ Programming Lang: Scheme Description : scheme mathematical library An integrated library of procedures, embedded in the programming language Scheme, and intended to support teaching and research in mathematical physics and electrical engineering. Scmutils and Scheme are particularly effective in work where the almost-functional nature of Scheme is advantageous, such as classical mechanics, where many of the procedures are most easily formulated as quite abstract manipulations of functions. . This code was developed for educational and research use at the Massachusetts Institute of Technology. This is the library accompanying the Structure and Interpretation of Classical Mechanics (SICM) by Gerald Jay Sussman and Jack Wisdom to do variational calculus and much more. A group of students and I at Tsinghua University are holding seminars to learn and extend it. Our members encountered errors when trying to install scmutils and set up its integration with emacs on Debian. We believe SICM will become the bible for classical mechanics as SICP did for programming. We want to lower the barrier of SICM to those who are not (yet) tech-savvy, especially students majoring physics and mathematics. Such consideration justifies our intention to bring this package to Debian. I shall maintain this package as long as I hold this seminar, which is expected to be at the time scale of a decade.
Bug#1027051: ITP: cl-fiasco -- a test framework for Common Lisp
Package: wnpp Severity: wishlist Owner: Benda Xu X-Debbugs-Cc: debian-devel@lists.debian.org, debian-common-l...@lists.debian.org * Package name: cl-fiasco Version : 0~git20221227 Upstream Contact: João Távora * URL : https://github.com/joaotavora/fiasco * License : public-domain Programming Lang: Common Lisp Description : a test framework for Common Lisp Fiasco is a fork of the abandoned Stefil test framework, simple and powerfull, with a focus on interactive debugging. - It is a build dependency of the unit tests of stumpwm. - I would like to maintain it collaboratively under the Debian Common Lisp Team.
Re: Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result)
Hi Jonathan, Jonathan Carter writes: > On 2021/04/18 13:20, Debian Project Secretary - Kurt Roeckx wrote: >> The details of the results are available at: >> https://www.debian.org/vote/2021/vote_002 > > Thanks for all your work on this vote, I believe that you made excellent > decisions as project secretary and it seems that all views that were > expressed on -vote were well represented in the vote, so again, I think > I can talk on behalf of the project here when I'm giving special thanks > for your work. I would like to congratulate you for becoming our next DPL. > However, I don't think we're quite in a position to pat ourselves on > the back here. This vote has once again highlighted some problems in > our methods for making decisions. I think that we should set up a > working group to specifically deal with voting, polling and > project-wide decision making so that we can deal more efficiently with > problems in the future. > > While this vote caught a lot of heat, essentially it's quite a trivial > vote. Ultimately it had become a question of if and how we should > respond to an external situation. I think that as Debian grows, as the > free software eco-system grows, and as software gets ever more ingrained > in our every day life, the questions and problems we're going to face > will become increasingly complex and that we should adapt to be able to > deal with those as a project. > > Can we go ahead and set up such a working group? I'm thinking that it > would involve mailing list discussions, video calls, sessions at > DebConf, probably at least one GR, research on different voting methods > that could be used, voting software, etc. Fortunately, we're not the > only organisation in the world facing issues like these and we can make > use of some external experts too. Although all of this will also take > some time and effort so I'd really like to have you on board as one of > the drivers of this project and also others who have a keen interest in > this. What do you think? The winning option "Debian will not issue a public statement on this issue" implies that the majority of DDs is not interested in such non-technical affairs. Such a working group will distract us from achieving technical excellence. Yours, Benda
Re: NEW queue almost empty
Christian Kastner writes: > The NEW queue length is down a single digit, from ~500 not all too > long ago. That's an amazing effort by ftp-master that must have > consumed a *lot* of energy. > > THANK YOU! > > https://ftp-master.debian.org/new.html That's a good news for the bullseye freeze! Kudos ftp-masters. Benda
Re: Summary: BLAS/LAPACK Ecosys Massive Update
Hi Mo, Mo Zhou writes: > Hi fellow developers, > > A good news especially for Debian scientific computing users. > I shall call it a massive update, even if the whole update > was decomposed into many tiny steps where some of them > had already been finished 1 year ago. > > [...] Congratulation for the big achievement! Thank you so much for contributing jointly to Debian and Gentoo. Does that imply the blas64 inside src:julia could be finally unbundled? Cheers, Benda
Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)
Dear Simon, Simon Richter writes: > The sanest thing we could do in Debian is to teach start-stop-daemon > to parse systemd .service files and pull its command line arguments > from there, so we could use service definitions as init scripts with a > #! line. > > For that to happen, we'd have to define .service files as an API > though, which would feature-freeze them, and I'm not sure the systemd > people would be happy about that. Thank you for sharing your thoughts. I also think adding a compatibility layer is the best way to move forward. With more upstream packages providing systemd-.service by default, it is more expansive for the systemd team to break the existing .service API. We could consider it to be freezed in practice, or at least backward compatible. Yours, Benda
Re: Challenge from Julia's non-standard vendored openblas"64_"
Hi Mo, Mo Zhou writes: > 64-bit version without symbol mangling will run into problem as long > as the user tries to install some fundamental .jl packages with the > Julia's built-in package manager. Does Julia's built-in package manager support to build packages from source, like R? If so, the Debian version of Julia's package manager could be set to build from source by default. Yours, Benda
Re: SIMDebian: Debian Partial Fork with Radical ISA Baseline
Hi Mo, Mo Zhou writes: > For most programs the "-march=native" option is not expected to bring any > significant performance improvement. However for some scientific applications > this proposition doesn't hold. When I was creating the tensorflow debian > package, I observed a significant performance gap between generic code and > kabylake (Intel 7XXX Series) code[1]. > ... Very interesting initiative. I understand it will Intel-specific for the moment. What is your vision in opitmizing with AMD CPUs? Yours, Benda
Re: Debian Buster release to partially drop non-systemd support
Hi Petter, (Dropping backports) Petter Reinholdtsen writes: >> 1. systemd-shim is not necessary, even for DEs (except GNOME3). >> 2. sysvinit-core is very stable and do not need new uploads. > > Thank you for expressing so well the cause of the fate for sysvinit in > Debian. It seem clear its proponents believe everything is OK and no > effort is needed to save sysvinit. If this continues, sysvinit in > Debian will continue to rot and end up being removed. > > I know from maintaining the sysvinit set of packages that it require > work to maintain them. There are hundreds of open bugs against the > sysvinit packages in Debian already. Thank you for all your work on sysvinit, especially insserv. Please note that I said only *sysvinit-core* the pid 1 ELF is stable. No worries, we will not let it be and disappear by itself. My plan is to do something to please those who want to kill sysvinit by keeping it in a "healthy" state, althrough only cosmetic changes are needed. Cheers, Benda
Re: Debian Buster release to partially drop non-systemd support
Hi Thorsten, Thorsten Glaser writes: > … this applies to the shim only. I was a bit surprised seeing on > someone else’s system that it was no longer installable, but almost > all systemd-free systems of people I know do not use the shim anyway, > so I’d take the Subject line with a few grains of salt. > > With only two modified binary packages (policykit-1 and udisks2) I’ve > got a complete KDE environment running, except for network-manager, > without the shim. People who do not use the full desktop environments > (but the leaner ones, or just a window manager, or no X11 at all) have > no problems with the current situation. > >> > sysvinit currently has two maintainers, but they've only >> > ever made one upload (over a year ago). >> >> It seems that these facts are either largely ignored or unknown and I >> wonder if some noise should be made so that interested people can pick >> up the work now and not only complain later. > > Why would sysvinit need uploads? It’s largely working software > that needs few changes. I personally find upload frequency as > a measurement misused too often: sure, no uploads raises some > questions, but more than four to six uploads a year should, in > my opinion, raise even more questions (namely whether the soft‐ > ware is ripe and stable enough in the first place). I was about to reply to this thread, but you have completely expressed what I want to say: 1. systemd-shim is not necessary, even for DEs (except GNOME3). 2. sysvinit-core is very stable and do not need new uploads. Cheers, Benda
Gentoo/Android | Debian/Android (Was: Missing: Mobile Debian-Solution referring to Smartphone Operating Systems)
Hi Paul and friends on -devel, Paul Wise writes: > Please take a look > these pages: > > https://wiki.debian.org/Mobile > https://postmarketos.org/ I would like to append the list with https://wiki.gentoo.org/wiki/Project:Android and a project "portage-powered android" under Gentoo GSOC2018, https://jsteward.moe/gsoc-2018-final-report.html . We are still half way from our final goal to completely decouple Android into a set of manageable Gentoo packages and to make smartphones no different from personal computers. But several milestones have been achieved. Our student Pengcheng Xu has gained complete control of the android/lineage system by putting it into an LXC jail managed by Gentoo natively on the phone, while keeping Android fully functional. We have also accumulated first-hand hacking experience with the Android's brand-new build system soong/blueprint and successfully built Android bionic-libc independently by a Gentoo package[1]. The Debian Multi-Arch makes running arm64-linux-gnu and arm64-linux-bionic side-to-side straight forward and will facicitate potential integration between the two userlands. The considerations for hacking on Android are 1. Android is the operating system with the biggest user base. Hacking it can effectively bridge the mobile world with GNU/Linux distributions. 2. Android consists mostly with free software under the Apache 2.0 license. It is only Google inventing a lot of new wheels that caused us not familiar with it. 3. The problems of vendor binary blobs are no worse than the non-free firmware Debian and Gentoo are shipping. 4. The outdated linux kernel problem can only be solved once GNU/Linux hackers start to hack Android. Only we care about it the most! 5. Gentoo/Android should not be much different from Gentoo/FreeBSD. It is slightly different for the case of Debian/kFreeBSD, but you get it idea: we have achieved similar goals before. If that resonate with you, cool! Let's ignore the difference between Debian and Gentoo at this moment, as the distance between the two is an epsilon compared to that between Android and either Debian or Gentoo. Cheers, Benda 1. https://gitweb.gentoo.org/proj/android.git/tree/sys-libs/bionic/bionic-8.1.0_p41.ebuild?id=6d90db7ab26624f1ed93eb3172666d39df316e3e
Re: Is missing SysV-init support a bug?
Josh Triplett writes: > It seems far harder to do so for a service that provides no > daemonization support at all, expects socket or D-Bus activation, > integrates with containerization, or otherwise makes use of the > variety of mechanisms that make it far easier to write more capable > and secure services these days. If that is the case, shouldn't the package "Depends:" on systemd? Benda
Re: User-installable Debian packages?
Hi Simon, Simon McVittie writes: > Flatpak's approach to this is to use bind-mounts (in a new mount > namespace set up by bubblewrap) so that the "app" (the leaf package, > together with any libraries that are bundled with it) always appears > to be installed in --prefix=/app, which can safely be hard-coded into > binaries that are built as Flatpak apps. I can see the use cases for desktop, but this is the restriction of Flatpak for shared HPC servers: not all administrators are willing to grant the users the seccomp and permission for creating new namespaces, and not all administrators will upgrade or recompile kernels to support namespaces. If /app is not available, it is difficult for a user to override the hardcoded /app of Flatpak into /home/user/app. In principle, we can create an _appdebian_ by hardcoding /app to every debian package, not unlike hardcoded /system in Android systems. Cheers, Benda
Re: User-installable Debian packages?
Hi Steffen, Steffen Möller writes: > This is good to hear. While I like all that I read about Gentoo, I do > not know about how well equipped it is with packages in computational > biology [edit: I had a look at > https://packages.gentoo.org/categories/sci-biology and am impressed, > well done!]. As a physicist, I am not sure if bioconductors is closely related to computational biology. If so, a complete machine-generated Gentoo overlay for the repository of bioconductor[1] is available as part of R_Overlay[2]. > This is where BioConda (bioconda.github.io) is very strong now. And > while the Conda community gets increasingly sophisticated with their > packaging, we can decide to either just let them go for it or to find > ways to compete. These folks start as low as libz, i.e. just above > libc, really. I hence tend to think that it is something that we as a > Linux distribution should care about. AFAIK, conda uses RPATH and $ORIGIN variable for ELFs, which is similar to Gentoo Prefix-rpath, the more traditional approach than Prefix-libc inside Gentoo. On the other hand, the compatibility issues from libc versions is not negligible. I see several times conda fails to install a python module correctly, e.g. xgboost, because libc on the host being too old. I hope the two camps of people will merge their efforts someday. But I am not optimistic. > I have followed Johanness' link to > https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap but frankly > do not yet know how to transform that into something computational > biologists would like to use and trust more than Conda. It would all > start with cross-distribution packages of dpkg, right? And the testing > infrastructure of Debian would need to care for such > off-root-experiences, too. I do not see that just around the corner. I am a long-term Debian user. It was Gentoo Prefix on HPC that introduced me to Gentoo. At the time of adopting Gentoo in my work flow aside Debian, I have long thought of giving dpkg the same power. I concluded that the most portable way to go is to reimplement the Prefix feature of Gentoo portage in Debian debhelper and treat Debian as a source-based distribution. As far as I can see, the easiest relocations are those modifiable in a plain text, like configuration file, script shebang, etc. The medium ones are ELF, with which we have tools like patchelf and chrpath, etc. The most difficult part includes quite a few hidden path assumptions that can only be specified at build time, like the default GCC include dir. I don't know whether distributing binary packages can alleviate the barrier. Chances are many patches are needed to be carried to be able to override paths at run time. (Considering Debian's existing patch base, that might not be a big drawback). For me with a lot of CPU cycles, compiling everything by Gentoo in my home directory is not a problem. At the same time, I really would like to see dpkg can do something similar. Sometimes binary packages are more robust and flexible. Cheers, Benda 1. https://www.bioconductor.org 2. https://wiki.gentoo.org/wiki/Project:Science/Overlay#Scientific_repositories
Re: User-installable Debian packages?
Hi Steffen, Steffen Möller writes: > I just had a quick look and it seems really nice, indeed! Thank you tons for > pointing that out to us. Has anybody already tried that with Debian? I am one of a few guys behind that project. Gentoo Prefix with its own libc runs on Debian very well, the explicity tested distributions are listed at, https://wiki.gentoo.org/wiki/Prefix/libc#Tested_distributions The highlights are: 1. you can compile almost any package available in Gentoo. 2. you can run x86 Gentoo Prefix on a amd64 Debian, thus another form of multiarch. The downside compared to Debian and any binary distribution is that, everything need to be compiled from source. That's slow. A preliminary draft has been prepared to discuss its use on HPC environments: https://arxiv.org/abs/1610.02742 Alternative projects are _spack_ and _easybuild_, with slightly different motivations and implementations. Cheers, Benda
Bug#761146: ITP: casacore-data -- Data for Common Astronomy Software Applications core library
Package: wnpp Severity: wishlist Owner: Benda Xu * Package name: casacore-data Version : 0 Upstream Author : Australia Telescope National Facility * URL : https://code.google.com/p/casacore * License : LGPL Programming Lang: none Description : Data for Common Astronomy Software Applications core library This package contains data from Australia Telescope National Facility to be used by Common Astronomy Software Applications core library at runtime and test. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140911051313.5112.11885.reportbug@localhost
Bug#704519: ITP: scim-bridge -- IME server of scim-bridge communicate with SCIM
Package: wnpp Severity: wishlist Owner: Benda Xu Please readopt the removed scim-bridge package[1]. I have made a package in mentors.debian.org[2]. The reason for removal of the package was that no one wanted to work on this and upstream was inactive. Now upstream has one or two active maintainers and I would like to maintain this package in Debian. Cheers, Benda 1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642371 2. https://mentors.debian.net/package/scim-bridge -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402101557.25599.96437.reportbug@localhost
