Re: request for reviews/sponsorship
Hi Sebastian, On Tue, Feb 06, 2018 at 08:53:58PM -0700, Sebastian Kuzminsky wrote: > It might fit better into the Debian Science blend. dxf2gcode doesn't > have a scientific purpose, it is mundanely practical, but that doesn't > seem to be the deciding factor for inclusion in Debian Science. For > example, I see packages in the Electronics task for designing PCBs and > programming FPGAs, in Engineering for making CAD drawings, etc. I get > the feeling from this that Debian Science welcomes the other STEM > disciplines as well. > > dxf2gcode is part of the toolchain for subtractive fabrication: CAD > programs like freecad and solvespace make models of parts, CAM programs > like dxf2gcode read those models and write g-code (instructions for CNC > machine tools), and "machine controllers" like LinuxCNC[1] read the > g-code and drive the motors on the machines themselves. I've added dxf2gcode to electronics task. Sponsoring does not seem to be necessary any more since it is in Debian now, right? Thanks for your work on this package Andreas. -- http://fam-tille.de
Coin3d and SoQt
Hi Anton and Debian-science list, I have been working with Coin3 and SoQt. In Coin3 I have made small modifications to include cmake files. Pushed in experimental branch, not in the archive. Don't you think that maybe we should drop the v5 part? In SoQt, I have been able to create in the Qt5 branch a version that uses the Coin3 from experimental exp2, just in git and build a SoQt that depends on Qt5. I have dropped and renamed some files and packages soqt-common. Please, could you check one eye on it? if you want, not need to push changes, just tell me what do you miss and I'll prepare a new version to push in experimental. Thanks, Leopold signature.asc Description: OpenPGP digital signature
Re: RFS: python-ltfatpy/1.0.12-1
On Thu, Feb 15, 2018 at 01:28:03PM +, Ghislain Vaillant wrote: > Could someone kindly sponsor this upload for me. Uploaded, thanks for your contribution. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Re: Packaging shiny-server (Was: Bug#886815: ITP: r-cran-git2r -- GNU R access to Git repositories)
Hi Andreas, On 16.02.2018 at 12:04, Andreas Tille wrote: > On Fri, Feb 16, 2018 at 11:29:08AM +0100, Philip Rinn wrote: >> There is still a lot to do, especially coordinating with Debian JavaScript >> Maintainers to get most of the packages under their umbrella. Unfortunately >> one >> needs to be subscribed to post to their mailing list :-(. > > Please let me know if you need a sponsor for any of the packages or if > you even need help for packaging. Just let me know explicitly which one > you would prefer to be taken by somebody else to avoid duplicated > effort. to be honest, I'm not interested to be Uploader for all those node.js packages. I'd propose to file RFP bugs for - node-client-sessions - node-http-proxy - node-morgan - node-pause - node-rewire - node-sockjs - node-stable as they seem to be more widely used and I hope others will do the packaging. This would leave us with these three funny, 3 - 100 LoC, node.js modules - node-bash -> https://github.com/felixge/node-bash - node-regexp-quote -> https://github.com/dbrock/node-regexp-quote - node-unixgroups -> https://github.com/rstudio/node-unixgroups So, filing RFP bugs would help much, I'll take care of the three node.js modules left. Best, Philip signature.asc Description: OpenPGP digital signature
Re: togl 2.0 upload breaking netgen and xcrysden (FTBFS)
Andreas Tille wrote: > I would have loved if you would have given a link to some newer togl > version 2.1 (I can not find it neither the netgen version you are > mentioning). There is a copy (of some sort) in netgen Git: https://sourceforge.net/p/netgen-mesher/git/ci/master/tree/ng/ https://github.com/live-clones/netgen I don't know, if this is a fork or a development version or even the new development place of togl. > [..] > BestPractices - simply assume that the target audience of your mail > knows about transitions. Well, togl is probably not the proof to that (SCNR). I'd appreciate it, if you would follow procedures and contact affected package maintainers or create bug reports in advance next time. Regards, Daniel
Re: togl 2.0 upload breaking netgen and xcrysden (FTBFS)
Hi Daniel, On Mon, Feb 19, 2018 at 05:21:31PM +0100, Daniel Leidert wrote: > CCed Andreas, who seems responsible for this Sorry for messing things up. > The uncoordinated upload of togl 2.0 into Debian unstable breaks both > netgen (#889003) and xcrysden (#889906). Togl2 uses a completely different > API then Togl1.7. Whereas there seems to be at least a netgen version > shipping (and therefor maybe using) togl 2.1, I would have loved if you would have given a link to some newer togl version 2.1 (I can not find it neither the netgen version you are mentioning). That would have been more productive than links to BestPractices - simply assume that the target audience of your mail knows about transitions. We have the following situation togl 1.7 (released 2006) was never uploaded since 2010 togl 2.0 (released 2008) had several commits in SVN which I now uploaded when doing the Git migration and fixing most of the open bugs. If we use this accident of mine (I admit - an upload to experimental would have been better) to upgrade way outdated netgen to some recent version that would be some positive outcome. > xcrysden can neither be > fixed easily nor in short terms, thus making it impossible to build it on > Debian systems. > > This situation could have been easily avoided by following the advice from > the release team [1] and the best transition practices [2] probably > leading to a solution like: uploading togl2 as a separate source package > building and shipping libtogl2-dev and libtogl2 and doing a reasonable > library transition and giving time to maintainers and upstream authors to > react. Unfortunately this is no longer an option. > > So I'm asking you, how to proceed from here? My suggestion would be to upgrade netgen to a version that works with latest togl. If it is not possible to port xcrysden maintaining a togl1 package could be an option - but only if we can *really* maintain it. Kind regards Andreas. > [1] https://wiki.debian.org/Teams/ReleaseTeam/Transitions > [2] https://wiki.debian.org/TransitionBestPractices -- http://fam-tille.de
