Bug#956087: RFS: yacpi/3.0.1-2 [ITA] -- ncurses based acpi monitor for text mode
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "yacpi" * Package name: yacpi Version : 3.0.1-2 Upstream Author : Nico Golde * URL : http://www.ngolde.de/yacpi/ * License : GPL-2 * Vcs : None Section : utils It builds those binary packages: yacpi - ncurses based acpi monitor for text mode To access further information about this package, please visit the following URL: https://mentors.debian.net/package/yacpi Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/y/yacpi/yacpi_3.0.1-2.dsc Changes since the last upload: * New maintainer (Closes: #842556) * Bumped Standards-Version to 4.5.0 * Added rules-requires-root to control * Changed debhelper to 12 * Changed NEWS from bulleted list to regular paragraphs * Enabled hardening flags when building Regards, -- Seunghun Han
Bug#955496: RFS: libsys-hostaddr-perl/0.993-1 [ITP] -- Get IP address information about this host
Am 05.04.2020 um 22:20 teilte Adam Borowski mit: > On Wed, Apr 01, 2020 at 05:51:28PM +0200, Hilmar Preusse wrote: Hi, >> * Package name: libsys-hostaddr-perl >>Version : 0.993-1 >>Upstream Author : Jeremy Kister|http://jeremy.kister.net/ >> * URL : https://metacpan.org/release/Sys-HostAddr > >> Changes since the last upload: >> >>* Initial release. (Closes: #955449). > > I'm not quite sure if this particular implementation is adequate. So far > I noticed that it: > > * has seen no updates since 2014 > Age of software is not always a sign of quality. ;-) > * relies on a long-deprecated interface, via a tool that hasn't seen an > upstream release since April 2001 > Well, I'm aware of this drawback. My intend was to first push the tool into Debian and then contact upstream to get rid of net-tools. No, I did no test the responsiveness of the upstream author yet. Should I do that beforehand? > Thus, I wonder if there's a better module to do this task. > Well, I did not really thought about using an alternative tool. I just noticed that the author of proftp used it in his test suite, hence I started packaging that code. Maybe I should go the way round and try to convince TJ to use a different perl module in his test suite. Not sure if [1] does the job. Hilmar [1] https://metacpan.org/pod/Net::Address::IP::Local -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Re: Autoconf issue in mpqc
On 2020-04-05, at 22:38:39 +0100, Jeremy Sowden wrote: > On 2020-04-05, at 14:32:16 +0200, Andreas Tille wrote: > > On Sun, Apr 05, 2020 at 12:34:55PM +0100, Jeremy Sowden wrote: > > > > > I've attached the part or the build log that seems to be > > > > > autoconf relevant. I admit I'm a bit astonished since I can > > > > > only see warnings but no error ... > > > > > > > > Here's a patch that fixes the autoheader warnings. > > > > > > Whoops. That version doesn't seem to apply. The patch I've > > > attached to this message I have actually tested properly. > > > > > > > autoreconf is still failing. > > > > > > That's not quite right: "autoreconf" fails, but "autoreconf -f > > > -i" (which is what dh_autoreconf does) succeeds. Now > > > dh_auto_configure fails. > > > > I confirm it fails with > > > > ... > > checking if semctl requires semun... no > > checking if fortran compiler works... no > > configure: error: in `/build/mpqc-2.3.1': > > configure: error: fortran compiler does not work > > > > > > I've updated Git with your patch - thanks a lot so far. > > In my case, the problem was: > > ./configure: line 4287: mpicc: command not found > > IOW, missing build-deps. Once I installed those, dh_auto_configure > was happy, but there were compilation failures because autoheader > clobbered src/lib/scconfig.h.in. I've attached two patches which fix > those. Having re-read the autoconf and autoheader doc's this evening, I think the attached fixes are an improvement over yesterday's. J. From cb556d820337b9e2b24cdc70049e9bca1967c7af Mon Sep 17 00:00:00 2001 From: Jeremy Sowden Date: Sun, 5 Apr 2020 20:22:51 +0100 Subject: [PATCH v2 1/2] shmtype fix. --- debian/patches/series| 1 + debian/patches/shmtype.patch | 21 + 2 files changed, 22 insertions(+) create mode 100644 debian/patches/shmtype.patch diff --git a/debian/patches/series b/debian/patches/series index db79d4fb8ff5..c5ef93ff27ed 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -12,3 +12,4 @@ g++6-constexpr.patch Fix_mpi.patch autoconf.patch autoheader.patch +shmtype.patch diff --git a/debian/patches/shmtype.patch b/debian/patches/shmtype.patch new file mode 100644 index ..273b16a9dec6 --- /dev/null +++ b/debian/patches/shmtype.patch @@ -0,0 +1,21 @@ +diff --git a/configure.in b/configure.in +index 8ebd2fa89c95..96e7fb7039da 100644 +--- a/configure.in b/configure.in +@@ -8,6 +8,7 @@ define([AC_CACHE_SAVE], )dnl for debugging configure.in + AC_INIT(src/lib/util/ref/ref.h) + AC_PREREQ(2.55) + AC_CONFIG_HEADER(src/lib/scconfig.h) ++AH_BOTTOM([#include "shm_type.h"]) + AC_CONFIG_AUX_DIR(bin) + AC_CONFIG_MACRO_DIR([lib/autoconf]) + +diff --git a/src/lib/shm_type.h b/src/lib/shm_type.h +new file mode 100644 +index ..8c62fb392b34 +--- /dev/null b/src/lib/shm_type.h +@@ -0,0 +1,3 @@ ++#ifndef SHMTYPE ++#define SHMTYPE char* ++#endif -- 2.25.1 From 758970c9d0b5928b60b000acd3485cc666827591 Mon Sep 17 00:00:00 2001 From: Jeremy Sowden Date: Sun, 5 Apr 2020 20:58:57 +0100 Subject: [PATCH v2 2/2] restrictxx fix. --- debian/patches/restrictxx.patch | 27 +++ debian/patches/series | 1 + 2 files changed, 28 insertions(+) create mode 100644 debian/patches/restrictxx.patch diff --git a/debian/patches/restrictxx.patch b/debian/patches/restrictxx.patch new file mode 100644 index ..3730918e8701 --- /dev/null +++ b/debian/patches/restrictxx.patch @@ -0,0 +1,27 @@ +diff --git a/configure.in b/configure.in +index 96e7fb7039da..040b475941c7 100644 +--- a/configure.in b/configure.in +@@ -8,7 +8,10 @@ define([AC_CACHE_SAVE], )dnl for debugging configure.in + AC_INIT(src/lib/util/ref/ref.h) + AC_PREREQ(2.55) + AC_CONFIG_HEADER(src/lib/scconfig.h) +-AH_BOTTOM([#include "shm_type.h"]) ++AH_BOTTOM([ ++#include "shm_type.h" ++#include "restrictxx.h" ++]) + AC_CONFIG_AUX_DIR(bin) + AC_CONFIG_MACRO_DIR([lib/autoconf]) + +diff --git a/src/lib/restrictxx.h b/src/lib/restrictxx.h +new file mode 100644 +index ..cacfea3b7db5 +--- /dev/null b/src/lib/restrictxx.h +@@ -0,0 +1,5 @@ ++#ifdef CXX_RESTRICT ++#define restrictxx restrict ++#else ++#define restrictxx ++#endif diff --git a/debian/patches/series b/debian/patches/series index c5ef93ff27ed..9662a2c679b6 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -13,3 +13,4 @@ Fix_mpi.patch autoconf.patch autoheader.patch shmtype.patch +restrictxx.patch -- 2.25.1 signature.asc Description: PGP signature
Re: [covid-19] Autoconf solved but now there is a C issue (Was: Help with r-bioc-rgadem needed)
On 2020-04-06, at 20:32:12 +0200, Andreas Tille wrote:
> Hi Jeremy,
>
> On Mon, Apr 06, 2020 at 05:34:23PM +0100, Jeremy Sowden wrote:
> > On 2020-04-06, at 17:59:05 +0200, Andreas Tille wrote:
> > >dh_autoreconf -O--buildsystem=R
> > > autoheader: warning: missing template: HAVE_OPENMP
> > > autoheader: Use AC_DEFINE([HAVE_OPENMP], [], [Description])
> > > autoreconf: /usr/bin/autoheader failed with exit status: 1
> > > dh_autoreconf: error: autoreconf -f -i returned exit code 1
> > > make: *** [debian/rules:4: binary] Error 25
> > > dpkg-buildpackage: error: debian/rules binary subprocess returned exit
> > > status 2
> >
> > Similar to some of the problems with mpqc yesterday. Patch attached.
>
> Thanks a lot for your patch (commited to Git[1]) which solved the
> autoconf issue. Unfortunately there is another issue now:
>
>
> ecking for stdint.h... yes
> checking for unistd.h... yes
> checking dispatch/dispatch.h usability... no
> checking dispatch/dispatch.h presence... no
> checking for dispatch/dispatch.h... no
> checking whether OpenMP will work in a package... yes
> configure: creating ./config.status
> config.status: creating src/Makevars
> config.status: creating src/config.h
> ** libs
> make[1]: Entering directory '/build/r-bioc-rgadem-2.34.1/src'
> gcc -std=gnu99 -I"/usr/share/R/include" -DNDEBUG-fopenmp -fpic -g -O2
> -fdebug-prefix-map=/build/r-base-j1tBvV/r-base-3.6.3=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> -D_FORTIFY_SOURCE=2 -g -c Gadem_Analysis.c -o Gadem_Analysis.o
> Gadem_Analysis.c: In function 'GADEM_Analysis':
> Gadem_Analysis.c:618:7: warning: implicit declaration of function 'DO_APPLY'
> [-Wimplicit-function-declaration]
> 618 | DO_APPLY(populationCalculation(maxSeqLen, numEM, fitness+ii,
> | ^~~~
> Gadem_Analysis.c:618:16: error: invalid use of void expression
> 618 | DO_APPLY(populationCalculation(maxSeqLen, numEM, fitness+ii,
> |^~~
> 619 | startPWMfound, minminSites,
> maxpFactor[ii],
> |
> ~~~
> 620 | numSeq, numSeqEM, seq, rseq,
> seqLen, Iseq,
> |
> ~~
> 621 | bfreq0, posWeight, weightType,
> | ~~
> 622 | pvalueCutoff, emSeqLen,
> | ~~~
> 623 | pwm[ii], pwmLen[ii], epwm[ii],
> opwm[ii],
> |
>
> 624 | pwmConsensus[ii],
> scoreCutoff+ii, sdyad[ii], ii),
> |
>
> make[1]: *** [/usr/lib/R/etc/Makeconf:168: Gadem_Analysis.o] Error 1
>
>
> Thanks a lot for your help anyway
Patch attached.
J.
From d3b5c1358bcf8463719c0175d759f74819e74f8e Mon Sep 17 00:00:00 2001
From: Jeremy Sowden
Date: Mon, 6 Apr 2020 20:41:54 +0100
Subject: [PATCH] The definition of DO_APPLY in src/config.h.in is clobbered by
autoheader, so add it in Gadem_Analysis.c where it is used.
---
src/Gadem_Analysis.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/src/Gadem_Analysis.c b/src/Gadem_Analysis.c
index a604afeb0479..0e868b56918a 100755
--- a/src/Gadem_Analysis.c
+++ b/src/Gadem_Analysis.c
@@ -25,6 +25,32 @@
#include "config.h"
+#ifdef HAVE_DISPATCH_DISPATCH_H
+ #include
+ #define DO_APPLY(task, n_times, counter_name) \
+R_CheckUserInterrupt(); \
+dispatch_apply(n_times, \
+ dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), \
+ ^(size_t counter_name) { task; });
+
+#else // not HAVE_DISPATCH_DISPATCH_H
+ #ifdef HAVE_OPENMP
+#include
+#define DO_APPLY(task, n_times, counter_name) \
+ R_CheckUserInterrupt(); \
+ _Pragma("omp parallel for") \
+ for (int counter_name = 0; counter_name < n_times; ++counter_name) { \
+task; \
+ }
+ #else // not HAVE_OPENMP
+#define DO_APPLY(task, n_times, counter_name) \
+ for (int counter_name = 0; counter_name < n_times; ++counter_name) { \
+R_CheckUserInterrupt(); \
+task; \
+ }
+ #endif // HAVE_OPENMP
+#endif // HAVE_DISPATCH_DISPATCH_H
+
/*---
// v1.3.1: last modifications 5/14/2011
// added user-input background model
--
2.25.1
signature.asc
Description: PGP signature
Re: Help to enable test suite precondition for covid-19 relevant R package
On Mon, 2020-04-06 at 21:17 +0200, Andreas Tille wrote: > Hi, > > the cran package r-cran-gganimate requires r-cran-gifski to run its > test > suite. I've prepared the latter in Git[1]. To build the package a > rust > compiler is needed which I provided via Build-Depends: > cargo. Unfortunately > there will be some Rust modules needed which the build process tries > to > download: > > ... > gcc -std=gnu99 -I"/usr/share/R/include" -DNDEBUG-pthread > -fvisibility=hidden -fpic -g -O2 -fdebug-prefix-map=/build/r-base- > j1tBvV/r-base-3.6.3=. -fstack-protector-strong -Wformat -W > /usr/bin/cargo build --release --manifest-path=myrustlib/Cargo.toml > Updating crates.io index > warning: spurious network error (2 tries remaining): failed to > resolve address for github.com: Temporary failure in name resolution; > class=Net (12) > warning: spurious network error (1 tries remaining): failed to > resolve address for github.com: Temporary failure in name resolution; > class=Net (12) > error: failed to fetch `https://github.com/rust-lang/crates.io-index` > > Caused by: > failed to resolve address for github.com: Temporary failure in name > resolution; class=Net (12) > make[1]: *** [Makevars:12: myrustlib/target/release/libmyrustlib.a] > Error 101 > ... > > Since I have no idea about rust: How can I find out what extra > module > is needed and do we possibly have a package of it I could use as > Build-Depends? > > Kind regards > > Andreas. > > > [1] https://salsa.debian.org/r-pkg-team/r-cran-gifski > without looking at any of the packages, at all, you say you're unfamiliar with Rust, so perhaps the following hints will be helpful: 1. you can use the Rustc compiler (rustc) directly unless you actually need to make use of a Cargo project file (Cargo.toml). 2. `cargo` has an `--offline` option to run without network access. Cargo is built around the concept of "crates" (libraries) being available on crates.io, which projects can depend upon by specifying dependencies in Cargo.toml (though it is also possible to have dependencies hosted elsewhere), and which cargo can automatically download, compile and link when building your project. Cargo can thus have a need to retrieve an updated index of available crates (just like apt update), requiring internet access, as well as needing internet access to fetch depended upon crates that you have not already got cached. You can however as I just mentioned run it in offline mode whereby it tries to proceed with cached dependencies only.
Bug#956059: RFS: ttyrec/1.0.8-5.1 [NMU, RC] -- Terminal interaction recorder and player (for tty)
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "ttyrec" * Package name: ttyrec Version : 1.0.8-5.1 Upstream Author : Satoru Takabayashi * URL : http://namazu.org/~satoru/ttyrec/ * License : * Vcs : None Section : misc It builds those binary packages: ttyrec - Terminal interaction recorder and player (for tty) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/ttyrec Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/t/ttyrec/ttyrec_1.0.8-5.1.dsc Changes since the last upload: * Non-maintainer upload. * Fix FTBFS. (Closes: #954506) -- Regards Sudip
Help to enable test suite precondition for covid-19 relevant R package
Hi, the cran package r-cran-gganimate requires r-cran-gifski to run its test suite. I've prepared the latter in Git[1]. To build the package a rust compiler is needed which I provided via Build-Depends: cargo. Unfortunately there will be some Rust modules needed which the build process tries to download: ... gcc -std=gnu99 -I"/usr/share/R/include" -DNDEBUG-pthread -fvisibility=hidden -fpic -g -O2 -fdebug-prefix-map=/build/r-base-j1tBvV/r-base-3.6.3=. -fstack-protector-strong -Wformat -W /usr/bin/cargo build --release --manifest-path=myrustlib/Cargo.toml Updating crates.io index warning: spurious network error (2 tries remaining): failed to resolve address for github.com: Temporary failure in name resolution; class=Net (12) warning: spurious network error (1 tries remaining): failed to resolve address for github.com: Temporary failure in name resolution; class=Net (12) error: failed to fetch `https://github.com/rust-lang/crates.io-index` Caused by: failed to resolve address for github.com: Temporary failure in name resolution; class=Net (12) make[1]: *** [Makevars:12: myrustlib/target/release/libmyrustlib.a] Error 101 ... Since I have no idea about rust: How can I find out what extra module is needed and do we possibly have a package of it I could use as Build-Depends? Kind regards Andreas. [1] https://salsa.debian.org/r-pkg-team/r-cran-gifski -- http://fam-tille.de
[covid-19] Autoconf solved but now there is a C issue (Was: Help with r-bioc-rgadem needed)
Hi Jeremy, On Mon, Apr 06, 2020 at 05:34:23PM +0100, Jeremy Sowden wrote: > On 2020-04-06, at 17:59:05 +0200, Andreas Tille wrote: > >dh_autoreconf -O--buildsystem=R > > autoheader: warning: missing template: HAVE_OPENMP > > autoheader: Use AC_DEFINE([HAVE_OPENMP], [], [Description]) > > autoreconf: /usr/bin/autoheader failed with exit status: 1 > > dh_autoreconf: error: autoreconf -f -i returned exit code 1 > > make: *** [debian/rules:4: binary] Error 25 > > dpkg-buildpackage: error: debian/rules binary subprocess returned exit > > status 2 > > Similar to some of the problems with mpqc yesterday. Patch attached. Thanks a lot for your patch (commited to Git[1]) which solved the autoconf issue. Unfortunately there is another issue now: ecking for stdint.h... yes checking for unistd.h... yes checking dispatch/dispatch.h usability... no checking dispatch/dispatch.h presence... no checking for dispatch/dispatch.h... no checking whether OpenMP will work in a package... yes configure: creating ./config.status config.status: creating src/Makevars config.status: creating src/config.h ** libs make[1]: Entering directory '/build/r-bioc-rgadem-2.34.1/src' gcc -std=gnu99 -I"/usr/share/R/include" -DNDEBUG-fopenmp -fpic -g -O2 -fdebug-prefix-map=/build/r-base-j1tBvV/r-base-3.6.3=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -c Gadem_Analysis.c -o Gadem_Analysis.o Gadem_Analysis.c: In function 'GADEM_Analysis': Gadem_Analysis.c:618:7: warning: implicit declaration of function 'DO_APPLY' [-Wimplicit-function-declaration] 618 | DO_APPLY(populationCalculation(maxSeqLen, numEM, fitness+ii, | ^~~~ Gadem_Analysis.c:618:16: error: invalid use of void expression 618 | DO_APPLY(populationCalculation(maxSeqLen, numEM, fitness+ii, |^~~ 619 | startPWMfound, minminSites, maxpFactor[ii], | ~~~ 620 | numSeq, numSeqEM, seq, rseq, seqLen, Iseq, | ~~ 621 | bfreq0, posWeight, weightType, | ~~ 622 | pvalueCutoff, emSeqLen, | ~~~ 623 | pwm[ii], pwmLen[ii], epwm[ii], opwm[ii], | 624 | pwmConsensus[ii], scoreCutoff+ii, sdyad[ii], ii), | make[1]: *** [/usr/lib/R/etc/Makeconf:168: Gadem_Analysis.o] Error 1 Thanks a lot for your help anyway Andreas. [1] https://salsa.debian.org/r-pkg-team/r-bioc-rgadem -- http://fam-tille.de
Re: [covid-19] Help with r-bioc-rgadem needed
On 2020-04-06, at 17:59:05 +0200, Andreas Tille wrote: > since I did not got any response from r-pkg team yet I guess nobody > has a clue about this autoconf issue. So I'd like to forward this > question here to finalise a package which is relevant for our COVID-19 > Biohackathon. > > I injected r-bioc-rgadem[1] but the build ends in: > >dh_autoreconf -O--buildsystem=R > autoheader: warning: missing template: HAVE_OPENMP > autoheader: Use AC_DEFINE([HAVE_OPENMP], [], [Description]) > autoreconf: /usr/bin/autoheader failed with exit status: 1 > dh_autoreconf: error: autoreconf -f -i returned exit code 1 > make: *** [debian/rules:4: binary] Error 25 > dpkg-buildpackage: error: debian/rules binary subprocess returned exit status > 2 > > > Any hint would be welcome Similar to some of the problems with mpqc yesterday. Patch attached. J. diff --git a/configure.ac b/configure.ac index 0b7e8d793a31..aef047400685 100755 --- a/configure.ac +++ b/configure.ac @@ -39,6 +39,7 @@ Use --disable-parallel (or ARG=no) to keep the code sequential even if GCD or Op # As recommended by Simon Urbanek on R-Devel AC_DEFUN([AC_CHECK_PKG_OPENMP], [dnl +AH_TEMPLATE([HAVE_OPENMP],[]) AC_MSG_CHECKING([whether OpenMP will work in a package]) ac_pkg_openmp=no AS_IF( signature.asc Description: PGP signature
[covid-19] Help with r-bioc-rgadem needed
Hi, since I did not got any response from r-pkg team yet I guess nobody has a clue about this autoconf issue. So I'd like to forward this question here to finalise a package which is relevant for our COVID-19 Biohackathon. I injected r-bioc-rgadem[1] but the build ends in: dh_autoreconf -O--buildsystem=R autoheader: warning: missing template: HAVE_OPENMP autoheader: Use AC_DEFINE([HAVE_OPENMP], [], [Description]) autoreconf: /usr/bin/autoheader failed with exit status: 1 dh_autoreconf: error: autoreconf -f -i returned exit code 1 make: *** [debian/rules:4: binary] Error 25 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 Any hint would be welcome Andreas. [1] https://salsa.debian.org/r-pkg-team/r-bioc-rgadem -- http://fam-tille.de
Bug#956026: RFS: ortp/1:1.0.2-1.1 [NMU, RC] -- Development files for the ortp RTP library
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "ortp" * Package name: ortp Version : 1:1.0.2-1.1 Upstream Author : Simon Morlat * URL : http://www.linphone.org/technical-corner/ortp/overview * License : GPL-2+ * Vcs : https://salsa.debian.org/pkg-voip-team/ortp Section : libs It builds those binary packages: libortp-dev - Development files for the ortp RTP library libortp-doc - oRTP API documentation libortp13 - Real-time Transport Protocol (RTP) stack To access further information about this package, please visit the following URL: https://mentors.debian.net/package/ortp Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/o/ortp/ortp_1.0.2-1.1.dsc Changes since the last upload: * Non-maintainer upload. * Fix ftbfs with GCC. (Closes: #925798) -- Regards Sudip
Bug#955808: marked as done (RFS: kxd/0.14-1.1 [NMU, RC] -- Key exchange daemon)
Your message dated Mon, 6 Apr 2020 09:55:09 +0200 with message-id <56f7cf62-39ea-3039-9bd8-12574e56b...@yahoo.no> and subject line close bug has caused the Debian Bug report #955808, regarding RFS: kxd/0.14-1.1 [NMU, RC] -- Key exchange daemon to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 955808: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955808 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "kxd" * Package name: kxd Version : 0.14-1.1 Upstream Author : * URL : https://blitiri.com.ar/p/kxd * License : Expat * Vcs : https://salsa.debian.org/debian/kxd Section : net It builds those binary packages: kxc - Key exchange daemon -- client kxd - Key exchange daemon To access further information about this package, please visit the following URL: https://mentors.debian.net/package/kxd Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/k/kxd/kxd_0.14-1.1.dsc Changes since the last upload: * Non-maintainer upload. * Set absolute path in d/rules closes: #952332 * Cherry-pick upstream commit, needed for upstream testsuite. 0001-tests-Add-missing-conn.getresponse-which-was-causing.patch Regards, Håvard --- End Message --- --- Begin Message --- --- End Message ---
Re: Sponsor for DMX - The Context Machine
Hi Andrey and Farbrice, thank you very much for your feedback and your valuable hints. Yes, the DMX sources are free software in the public. If in that case, building from the binaries was ok, it would make things a bit easier on my end. If not, I can start to work on managing the whole process from source. Let me know, what you think. Thx, Juergen Am Sonntag, den 05.04.2020, 15:24 +0500 schrieb Andrey Rahmatullin: > On Sun, Apr 05, 2020 at 12:16:16PM +0200, Fabrice BAUZAC-STEHLY > wrote: > > Andrey Rahmatullin writes: > > > > > On Sat, Apr 04, 2020 at 11:36:03PM +0200, Fabrice BAUZAC-STEHLY > > > wrote: > > > > - By building the upstream source (main)? By packaging the > > > > upstream > > > > binary (contrib)? > > > Pre-built binaries are for non-free, not for contrib. Contrib is > > > strictly > > > DFSG-free. > > > > Here the binaries seem to be free software (AGPL3 or GPL3). Are > > you sure? > > Then what would stop them from being included in main if that was the > only > requirement? > There is only one difference between main and contrib: "packages in > main > must not require or recommend a package outside of main for > compilation or > execution". Do you know about some rebuildability requirements being > true > only for main but not for contrib? > -- GnuPG KeyID: CD914C6C Fingerprint: C1CC EF1D 1443 7279 72E7 ABDC A2DA 0328 CD91 4C6C
