Re: Packaging a .NET Core application & pbuilder
On Thu, 2020-08-20 at 11:40 +0500, Andrey Rahmatullin wrote: > On Thu, Aug 20, 2020 at 12:09:08AM +0200, gregor herrmann wrote: > > libdbd-oracle-perl is such an example; it's in contrib because it's > > free software itself but needs oracle software which is not even in > > Debian. Typically someone builds it by installing the needed stuff in > > a local cowbuilder etc. chroot and then uploads the binary packages. > So its next upload will never migrate? Packages in contrib or non-free might violate rules that apply to main and are usually enforced by the testing migration tool. For example source packages might not be buildable by the buildd network for various reasons such as build-depending on packages not in the archive; the same applies for binary packages. So the testing migration has exceptions to handle this. They will probably also be used to allow binary uploads by the maintainer. Still, having to first install some other package from some third-party repository as proposed here for the systemd-genie package before being able to use or build software is not very user-friendly and also makes it harder to find sponsors interested in reviewing and uploading the package. Ansgar
Re: Packaging a .NET Core application & pbuilder
On Thu, Aug 20, 2020 at 02:15:07AM +, Paul Wise wrote: > > I'm currently working on packaging a .NET Core utility for contrib > > I note that .NET is Free Software these days, so you should be able to > package both for main instead of using contrib. > > https://en.wikipedia.org/wiki/.NET_Core > https://github.com/dotnet/core But only if all deps are actually packaged. If binaries are used instead, that would be contrib. -- WBR, wRAR signature.asc Description: PGP signature
Re: Packaging a .NET Core application & pbuilder
There's also Mono, which is already in Debian but has some limitations (e.g. C# features newer than version 6 may not be available). https://lists.debian.org/debian-cli/ has been mostly-inactive for years.
Bug#968728: RFS: w1retap/1.4.4-4 [RC] -- Data logger for 1-Wire weather sensors
Package: sponsorship-requests Severity: important Dear mentors, As my existing sponsor seems very busy I am looking for a new sponsor for my package "w1retap": * Package name: w1retap Version : 1.4.4-4 Upstream Author : Jonathan Hudson * URL : http://www.zen35309.zen.co.uk/wx/tech.html * License : Expat-Dallas-Semiconductor-Corporation and Expat-University-of-Newcastle-upon-Tyne and GPL-2+, GPL-2+, Expat-Dallas-Semiconductor-Corporation and GPL-2+, Expat * Vcs : https://salsa.debian.org/thomasdstewart-guest/w1retap Section : electronics It builds those binary packages: w1retap-sqlite - Data logger for 1-Wire weather sensors (SQLite plugin) w1retap-pgsql - Data logger for 1-Wire weather sensors (PostgreSQL plugin) w1retap-odbc - Data logger for 1-Wire weather sensors (ODBC plugin) w1retap-mongo - Data logger for 1-Wire weather sensors (MongoDB plugin) w1retap-mysql - Data logger for 1-Wire weather sensors (MySQL plugin) w1retap-doc - Data logger for 1-Wire weather sensors (docs) w1retap - Data logger for 1-Wire weather sensors To access further information about this package, please visit the following URL: https://mentors.debian.net/package/w1retap/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/w/w1retap/w1retap_1.4.4-4.dsc Changes since the last upload: w1retap (1.4.4-4) unstable; urgency=medium . * Refresh dquilt patches * Rename fix-w1pgsql-snprintf-timet.patch to fix-timet.patch * Add timet fixes for w1file, w1pgsql, w1util and w1xml * Update patch descriptions * Fix lintian autotools-pkg-config-macro-not-cross-compilation-safe * Add fix-autotools-libxml2.patch (Closes: #949511) * Fix gcc-10 build errors (Closes: #957921) * Fix owerr spelling * Replace build dependency asciidoc with asciidoc-base * Update standards from 3.9.8 to 4.5.0 * Fix lintian init.d-script-should-always-start-service * Upgrade debhelper compat from 10 to 13 * Add Vcs-Git and Vcs-Browser fields to control file * Fix lintian skip-systemd-native-flag-missing-pre-depends * Add Rules-Requires-Root to control * Added salsa-ci.yml * Fix man page spelling * Add Documentation key to service * Add systemd service hardening-features * Make copyright format URL https * Update lintian-overrides * Add some autopkgtest tests * Remove training whitespace from changelog * Fix lintian debian-rules-uses-as-needed-linker-flag * Fix lintian upstream-metadata-file-is-missing Kind Regards -- Tom
RE: Packaging a .NET Core application & pbuilder
Andrey Rahmatullin wrote on Thursday, August 20, 2020 3:08 AM: > On Thu, Aug 20, 2020 at 02:15:07AM +, Paul Wise wrote: > > > I'm currently working on packaging a .NET Core utility for contrib > > > > I note that .NET is Free Software these days, so you should be able to > > package both for main instead of using contrib. > > > > https://en.wikipedia.org/wiki/.NET_Core > > https://github.com/dotnet/core > But only if all deps are actually packaged. If binaries are used instead, that > would be contrib. Microsoft apparently have a repository (https://github.com/dotnet/source-build) set up specifically to make .NET Core source tarballs that are compliant with that particular packaging rule. I'm experimenting with it now to get a feel for how it works. (Not like I woke up this morning planning to become the .NET Core package maintainer, but not like I woke up this morning planning not to, either...) Regards, Alistair openpgp-digital-signature.asc Description: PGP signature
RE: Packaging a .NET Core application & pbuilder
Ansgar wrote: > > Still, having to first install some other package from some third-party > repository as proposed here for the systemd-genie package before being > able to use or build software is not very user-friendly and also makes it > harder to find sponsors interested in reviewing and uploading the package. I definitely agree; my original motivation for wanting to get systemd-genie into contrib was that at the moment, using it requires the use of two third-party repositories. (I had experimented using the option to compile a .NET Core app down to a single native executable to cut that down to one, but since that turned a 101 KB executable into a _14 MB_ executable, I threw that idea out. The .NET runtime dependency at least is shared.) So, since the tools are there and if I can do it, it's looking to me like packaging .NET Core for main first is going to be the best way to go. Regards, Alistair openpgp-digital-signature.asc Description: PGP signature
