Re: Cost
Hello, Wnpp Are you planning to have a New Website or Re-designing your current website? Please let me know if you are willing to discuss your website design and development requirement or wants to recreate the existing one. If you are interested then please let me know, so we can set up a meeting to discuss details. I am waiting for your positive response. Thanks & Regards. Nadia Cobb
Bug#991109: ITP: golang-github-newrelic-go-agent -- library for monitoring go applications
Package: wnpp Severity: wishlist Owner: Peymaneh Nejad * Package name: golang-github-newrelic-go-agent Version : 3.13.0-1 Upstream Author : New Relic * URL : https://github.com/newrelic/go-agent * License : Apache-2.0 Programming Lang: Go Description : library for monitoring go applications This package is a dependency of step-ca (#990946)
Bug#991112: ITP: golang-github-stoewer-go-strcase -- go library for converting between naming formats
Package: wnpp Severity: wishlist Owner: Peymaneh Nejad * Package name: golang-github-stoewer-go-strcase Version : 1.2.0-1 Upstream Author : A. Stoewer * URL : https://github.com/stoewer/go-strcase * License : Expat Programming Lang: Go Description : go library for converting between naming formats This library converts between different kinds of naming formats such as camel case (CamelCase), snake case (snake_case) or kebab-case (kebab-case). This package is an indirect dependency of caddy (#810890)
Bug#990950: Question about packaging a Lisp image
Hi Douglas, Le dimanche 11 juillet 2021 à 17:08 +, Torrance, Douglas a écrit : I would like to package bergman [1], a Common Lisp program for computations in noncommutative algebra. Upstream's build script creates an executable by generating an image with SAVEINITMEM. However, in order for some of the features of bergman to work properly, the source files must be present, and in the same location as they were during build time, at runtime. So generating the image while building the binary package won't work, as then at runtime we'd be looking for some non-existent directory from the buildd machines. (Not to mention the reproducibility issues from having these paths hardcoded in the image!) One solution that I've come up with is to just have the Debian package install the necessary source files, and then have the postinst script run the upstream build script and generate the image right there on the user's system as part of the installation process. I'm very new to Common Lisp, so I'm not sure if this is the best strategy. Is there another method that would be recommended instead? First, note that Common Lisp is a standard, which has different implementations. In Debian, we have 5 of them, the most important ones being SBCL, ECL and CLISP.¹ My understanding is that Bergman uses CLISP as its reference implementation. This is a rather slow Common Lisp implementation, but it is well-supported in Debian. SBCL is a much faster implementation, but I don’t know if Bergman works with it (at the very least you would have to modify the build system). Applications programmed in Common Lisp typically ship the lisp image in the binary package. See for example xindy², which also uses CLISP. See also pgloader³, that uses SBCL (and relies on buildapp⁴ for creating the executable from the lisp image). So the ideal solution would still be to patch Bergman in a way that allows it to work with sources under a standard location (typically /usr/share/common-lisp/source/bergman/). If that’s not possible, then you could do as you suggest: only ship the sources in the binary package (under the location mentioned above), and build the lisp image in the postinst script. Note that most Common Lisp library packages only ship sources as well (under /usr/share/common-lisp/source/), but they don’t provide any lisp image. These libraries are supposed to be loaded from implementations, typically via ASDF, into the running lisp image. I hope this clarifies a bit. Don’t hesitate to ask for further advice, since the Common Lisp way of doings things can be disturbing at first sight. In particular, I suggest that you go through the introductory wiki page linked below. Best, ¹ For more details on Common Lisp and Debian, see https://wiki.debian.org/CommonLisp ² https://tracker.debian.org/pkg/xindy ³ https://tracker.debian.org/pkg/pgloader ⁴ https://tracker.debian.org/pkg/buildapp -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#990950: Question about packaging a Lisp image
[Sorry, resending with proper quoting; my email client somehow messed things up] Hi Douglas, Le dimanche 11 juillet 2021 à 17:08 +, Torrance, Douglas a écrit : > I would like to package bergman [1], a Common Lisp program for computations in > noncommutative algebra. > Upstream's build script creates an executable by generating an image with > SAVEINITMEM. However, in order for some of the features of bergman to work > properly, the source files must be present, and in the same location as they > were during build time, at runtime. So generating the image while building > the > binary package won't work, as then at runtime we'd be looking for some > non-existent directory from the buildd machines. (Not to mention the > reproducibility issues from having these paths hardcoded in the image!) > One solution that I've come up with is to just have the Debian package install > the necessary source files, and then have the postinst script run the upstream > build script and generate the image right there on the user's system as part > of > the installation process. > I'm very new to Common Lisp, so I'm not sure if this is the best strategy. Is > there another method that would be recommended instead? First, note that Common Lisp is a standard, which has different implementations. In Debian, we have 5 of them, the most important ones being SBCL, ECL and CLISP.¹ My understanding is that Bergman uses CLISP as its reference implementation. This is a rather slow Common Lisp implementation, but it is well-supported in Debian. SBCL is a much faster implementation, but I don’t know if Bergman works with it (at the very least you would have to modify the build system). Applications programmed in Common Lisp typically ship the lisp image in the binary package. See for example xindy², which also uses CLISP. See also pgloader³, that uses SBCL (and relies on buildapp⁴ for creating the executable from the lisp image). So the ideal solution would still be to patch Bergman in a way that allows it to work with sources under a standard location (typically /usr/share/common-lisp/source/bergman/). If that’s not possible, then you could do as you suggest: only ship the sources in the binary package (under the location mentioned above), and build the lisp image in the postinst script. Note that most Common Lisp library packages only ship sources as well (under /usr/share/common-lisp/source/), but they don’t provide any lisp image. These libraries are supposed to be loaded from implementations, typically via ASDF, into the running lisp image. I hope this clarifies a bit. Don’t hesitate to ask for further advice, since the Common Lisp way of doings things can be disturbing at first sight. In particular, I suggest that you go through the introductory wiki page linked below. Best, ¹ For more details on Common Lisp and Debian, see https://wiki.debian.org/CommonLisp ² https://tracker.debian.org/pkg/xindy ³ https://tracker.debian.org/pkg/pgloader ⁴ https://tracker.debian.org/pkg/buildapp -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Processed: RFS: openarc/1.0.0~beta3+dfsg-1~exp1 [ITP] -- Authenticated Received Chain (ARC) milter
Processing commands for cont...@bugs.debian.org: > block 989299 by 991118 Bug #989299 [wnpp] ITP: openarc -- Authenticated Received Chain (ARC) milter 989299 was not blocked by any bugs. 989299 was not blocking any bugs. Added blocking bug(s) of 989299: 991118 > End of message, stopping processing here. Please contact me if you need assistance. -- 989299: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989299 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#991121: ITP: golang-github-google-cel-spec -- go library implementing Common Expression Language
Package: wnpp Severity: wishlist Owner: Peymaneh Nejad * Package name: golang-github-google-cel-spec Version : 0.5.1-1 Upstream Author : Google * URL : https://github.com/google/cel-spec * License : Apache-2.0 Programming Lang: Go Description : go library implementing Common Expression Language The Common Expression Language (CEL) is a simple expression language built on top of protocol buffer types. It implements common semantics for expression evaluation, enabling different applications to more easily interoperate. This package is an indirect dependency of caddy (#810890)
Bug#843755: ITA: swedish -- Swedish dictionary for ispell
Intend to adopt.
