Bug#1014995: kea-shell does use original includes
Package: kea-ctrl-agent
After installation the kea-shell does not work because:
# kea-shell
Traceback (most recent call last):
File "/usr/sbin/kea-shell", line 27, in
from kea_conn import CARequest # CAResponse
ModuleNotFoundError: No module named 'kea_conn'
#
Quite obviously with the current python3-kea-connector in Debian
the following patch does seem correct:
---(snip)---
--- /usr/sbin/kea-shell.orig2022-07-15 22:20:46.534324145 +0200
+++ /usr/sbin/kea-shell 2022-07-15 22:21:12.590348119 +0200
@@ -24,7 +24,7 @@
sys.path.append('/usr/lib/python3.10/site-packages/kea')
-from kea_conn import CARequest # CAResponse
+from kea.kea_conn import CARequest # CAResponse
if sys.version_info[0] == 2:
# This is Python 2.x
@@ -34,7 +34,7 @@
return unicode(string, 'utf-8')
elif sys.version_info[0] == 3:
# This is Python 3.x
-import kea_connector3 as kea_connector
+import kea.kea_connector3 as kea_connector
auth8 = str
else:
# This is... have no idea what it is.
---(snip)---
Best regards,
Kilian
signature.asc
Description: PGP signature
Bug#933658: [Pkg-nagios-devel] Bug#933658: monitoring-plugins-standard: check_dns unable to cope with punycode/UTF-8 domains
Hi Jan, * Jan Wagner [2021-12-20 06:20:31 +0100]: thanks for bringing this to our attention. Am 01.08.19 um 15:26 schrieb Kilian Krause: The current version of check_dns seems to be broken w.r.t. punycode/UTF-8 domains: # /usr/lib/nagios/plugins/check_dns -H xn--brckenkurs-mathematik-9hc.de. -s 129.69.252.34 DNS CRITICAL - '/usr/bin/nslookup -sil' msg parsing exited with no address # /usr/lib/nagios/plugins/check_dns -H brückenkurs-mathematik.de -s 129.69.252.34 DNS CRITICAL - '/usr/bin/nslookup -sil' msg parsing exited with no address # nslookup -sil brückenkurs-mathematik.de 129.69.252.34 Server: 129.69.252.34 Address:129.69.252.34#53 Name: brückenkurs-mathematik.de Address: 129.69.8.19 Name: brückenkurs-mathematik.de Address: 2001:7c0:2041:8::19 $ /usr/lib/nagios/plugins/check_dns -H xn--brckenkurs-mathematik-9hc.de. -s 8.8.8.8 DNS OK: 0.054 seconds response time. xn--brckenkurs-mathematik-9hc.de. returns 129.69.8.19|time=0.053687s;;;0.00 $ dpkg -S /usr/bin/nslookup dnsutils: /usr/bin/nslookup $ dpkg -l | grep dnsutils ii dnsutils 1:9.10.3.dfsg.P4-12.3+deb9u10 amd64Clients provided with BIND $ cat /etc/debian_version 9.13 $ /usr/lib/nagios/plugins/check_dns -V check_dns v2.3 (monitoring-plugins 2.3) Look like it's fixed with monitoring-plugins 2.3 (at least with punycode, which seems resonable). Right. And looking at the nslookup response the UTF-8 attempt is at least going out correctly. Thanks! Best regards, Kilian
Bug#988061: please add nghttp2 to b-d and permit to enable enable DoT/DoH
Package: bind9 Version: 1:9.16.15-1 Severity: normal Hi, as per https://gitlab.isc.org/isc-projects/bind9/-/wikis/DoH/DOH-and-DoT-Design the 9.16 BIND9 release has support for DoT/DoH if built with nghttp2 support. This is not enabled in Debian and it would be great, if it could be added. TIA! Best regards, Kilian
Bug#985912: eapol_test does not work with IPv6 because CONFIG_IPV6 is not enabled
Package: eapoltest Severity: normal Hi, When running eapol_test against IPv6 addresses, the tool reports: Invalid IP address '2001:db8::123' eapol_test: eapol_test.c:1033: wpa_init_conf: Assertion `0' failed. because in debian/config/wpasupplicant/linux the CONFIG_IPV6=y is missing. Once adding this, the tools works just fine with IPv6 also. Please enable it. TIA! Best regards, Kilian
Bug#946050: Please add systemd socket activation support
Package: prometheus-blackbox-exporter
Severity: wishlist
Tags: patch
Hi,
Please consider adding the systemd socket activation patch from
https://github.com/prometheus/blackbox_exporter/pull/523/commits.
The verified working version for both 0.13 and 0.14 is attached.
TIA!
Best regards,
Kilian
backport systemd socket activation from
https://github.com/prometheus/blackbox_exporter/pull/523
Credit goes to Stefan Bühler
--- a/main.go
+++ b/main.go
@@ -39,6 +39,8 @@ import (
"github.com/prometheus/blackbox_exporter/config"
"github.com/prometheus/blackbox_exporter/prober"
+
+ "github.com/coreos/go-systemd/activation"
)
var (
@@ -204,12 +206,16 @@ func init() {
}
func main() {
- promlogConfig := promlog.Config{}
- flag.AddFlags(kingpin.CommandLine, )
+ os.Exit(run())
+}
+
+func run() int {
+ promlogConfig := {}
+ flag.AddFlags(kingpin.CommandLine, promlogConfig)
kingpin.Version(version.Print("blackbox_exporter"))
kingpin.HelpFlag.Short('h')
kingpin.Parse()
- logger := promlog.New()
+ logger := promlog.New(promlogConfig)
rh := {maxResults: *historyLimit}
level.Info(logger).Log("msg", "Starting blackbox_exporter", "version",
version.Info())
@@ -217,12 +223,12 @@ func main() {
if err := sc.ReloadConfig(*configFile); err != nil {
level.Error(logger).Log("msg", "Error loading config", "err",
err)
- os.Exit(1)
+ return 1
}
if *configCheck {
level.Info(logger).Log("msg", "Config file is ok exiting...")
- os.Exit(0)
+ return 0
}
level.Info(logger).Log("msg", "Loaded config file")
@@ -329,9 +335,44 @@ func main() {
w.Write(c)
})
- level.Info(logger).Log("msg", "Listening on address", "address",
*listenAddress)
- if err := http.ListenAndServe(*listenAddress, nil); err != nil {
- level.Error(logger).Log("msg", "Error starting HTTP server",
"err", err)
- os.Exit(1)
+ srv := http.Server{Addr: *listenAddress}
+ srvc := make(chan struct{})
+ term := make(chan os.Signal, 1)
+ signal.Notify(term, os.Interrupt, syscall.SIGTERM)
+
+ go func() {
+ listeners, err := activation.Listeners()
+ if err != nil {
+ level.Error(logger).Log("msg", "cannot retrieve
activation listeners", "err", err)
+ return
+ }
+
+ if len(listeners) > 1 {
+ level.Error(logger).Log("msg", "unexpected number of
socket activation listeners", "listeners", len(listeners))
+ return
+ }
+ if len(listeners) == 1 {
+ level.Info(logger).Log("msg", "Listening on activation
socket")
+ if err := http.Serve(listeners[0], nil); err !=
http.ErrServerClosed {
+ level.Error(logger).Log("msg", "Error starting
HTTP server", "err", err)
+ close(srvc)
+ }
+ } else {
+ level.Info(logger).Log("msg", "Listening on address",
"address", *listenAddress)
+ if err := srv.ListenAndServe(); err !=
http.ErrServerClosed {
+ level.Error(logger).Log("msg", "Error starting
HTTP server", "err", err)
+ close(srvc)
+ }
+ }
+ }()
+
+ for {
+ select {
+ case <-term:
+ level.Info(logger).Log("msg", "Received SIGTERM,
exiting gracefully...")
+ return 0
+ case <-srvc:
+ return 1
+ }
}
}
Bug#933658: monitoring-plugins-standard: check_dns unable to cope with punycode/UTF-8 domains
Package: monitoring-plugins-standard Version: 2.2-6 Severity: normal Dear Maintainer, The current version of check_dns seems to be broken w.r.t. punycode/UTF-8 domains: # /usr/lib/nagios/plugins/check_dns -H xn--brckenkurs-mathematik-9hc.de. -s 129.69.252.34 DNS CRITICAL - '/usr/bin/nslookup -sil' msg parsing exited with no address # /usr/lib/nagios/plugins/check_dns -H brückenkurs-mathematik.de -s 129.69.252.34 DNS CRITICAL - '/usr/bin/nslookup -sil' msg parsing exited with no address # nslookup -sil brückenkurs-mathematik.de 129.69.252.34 Server: 129.69.252.34 Address:129.69.252.34#53 Name: brückenkurs-mathematik.de Address: 129.69.8.19 Name: brückenkurs-mathematik.de Address: 2001:7c0:2041:8::19 # /usr/lib/nagios/plugins/check_dns -H uni-stuttgart.de -s 129.69.252.34 DNS OK: 0,009 seconds response time. uni-stuttgart.de returns 129.69.5.3,2001:7c0:7c0:5::cafe|time=0,009333s;;;0,00 # -- System Information: Debian Release: 10 APT prefers stable APT policy: (990, 'stable'), (890, 'testing'), (800, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages monitoring-plugins-standard depends on: ii libc6 2.28-10 ii monitoring-plugins-basic 2.2-6 ii ucf 3.0038+nmu1 Versions of packages monitoring-plugins-standard recommends: ii bind9-host [host] 1:9.11.5.P4+dfsg-5.1 ii dnsutils1:9.11.5.P4+dfsg-5.1 un host un libdbi1 ii libgnutls30 3.6.7-4 ii libldap-2.4-2 2.4.47+dfsg-3 un libmariadb3 un libmariadbclient18 ii libnet-snmp-perl6.0.1-5 ii libpq5 11.4-1 un libradcli4 un rpcbind un smbclient un snmp ii sudo1.8.27-1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages monitoring-plugins-standard suggests: un exim4-daemon-light un fping ii icinga | icinga22.10.3-2 pn qstat
Bug#886406: PID file directory not created by init script
Package: burp Version: 2.0.54-1 Severity: normal Hi, When trying to start burp automatically upon boot the PID file directory isn't automatically created, resulting in: root@backup:~# service burp status * burp.service - LSB: backup and restore program Loaded: loaded (/etc/init.d/burp; generated; vendor preset: enabled) Active: active (exited) since Fri 2018-01-05 11:40:28 CET; 2h 8min ago Docs: man:systemd-sysv-generator(8) Tasks: 0 (limit: 4915) CGroup: /system.slice/burp.service Jan 05 11:40:28 backup systemd[1]: Starting LSB: backup and restore program... Jan 05 11:40:28 backup burp[701]: Could not open lock file /var/run/burp/burp.server.pid: No such file or directory Jan 05 11:40:28 backup burp[701]: Could not get lockfile. Jan 05 11:40:28 backup burp[701]: Maybe you do not have permissions to write to /var/run/burp/burp.server.pid. Jan 05 11:40:28 backup burp[663]: Starting burp : failed! Jan 05 11:40:28 backup systemd[1]: Started LSB: backup and restore program. root@backup:~# Since this seems to be a race condition, starting the daemon with the same script later does work ok: root@backup:~# service burp restart root@backup:~# service burp status * burp.service - LSB: backup and restore program Loaded: loaded (/etc/init.d/burp; generated; vendor preset: enabled) Active: active (running) since Fri 2018-01-05 13:48:56 CET; 1s ago Docs: man:systemd-sysv-generator(8) Process: 5928 ExecStop=/etc/init.d/burp stop (code=exited, status=0/SUCCESS) Process: 5936 ExecStart=/etc/init.d/burp start (code=exited, status=0/SUCCESS) Tasks: 1 (limit: 4915) CGroup: /system.slice/burp.service `-5945 /usr/sbin/burp -c /etc/burp/burp-server.conf Jan 05 13:48:56 backup systemd[1]: Stopped LSB: backup and restore program. Jan 05 13:48:56 backup systemd[1]: Starting LSB: backup and restore program... Jan 05 13:48:56 backup burp[5936]: Starting burp :. Jan 05 13:48:56 backup systemd[1]: Started LSB: backup and restore program. root@backup:~# Maybe this should be circumvented by creating a systemd service with proper dependency chain or just hotfixed by the init script creating the required directory before the start-stop-daemon. Best, Kilian
Bug#865745: java-package: Parameter --changes creates unusable .changes file
Hi Haegar,
The patch required is actually pretty straightforward:
--- /usr/share/java-package/javase.sh 2016-09-11 02:39:56.0 +0200
+++ /tmp/jpkg/javase.sh 2017-12-18 14:51:57.412419588 +0100
@@ -259,11 +259,17 @@
local deb_filename="$( echo "${j2se_package}_"*.deb )"
echo "copy $deb_filename into directory $working_dir/"
cp "$deb_filename" "$working_dir/"
+local dbgsym_filename="$( echo "${j2se_package}-dbgsym_"*.deb )"
+echo "copy $dbgsym_filename into directory $working_dir/"
+cp "$dbgsym_filename" "$working_dir/"
if [ -n "$genchanges" ]; then
echo "dpkg-genchanges"
local changes_filename="${deb_filename%.deb}.changes"
echo "copy $changes_filename into directory $working_dir/"
cp "$changes_filename" "$working_dir/"
+local buildinfo_filename="$( echo "${j2se_package}_"*.buildinfo )"
+echo "copy $buildinfo_filename into directory $working_dir/"
+cp "$buildinfo_filename" "$working_dir/"
fi
cat << EOF
--(snip)--
Probably someone(TM) should verify that the dpkg/debhelper/etc. version
actually is new enough to generate these files (or just make the copy
optional). In case the versions do match, this seems to work for me.
Best,
Kilian
Bug#881584: logrotate probably not needed - or at least using wrong permissions
Package: puppetdb logroate.d config seems to be unneeded. Error message is: /etc/cron.daily/logrotate: error: destination /var/log/puppetdb/puppetdb-access.log.1 already exists, renaming to /var/log/puppetdb/puppetdb-access.log.1-2017111306.backup error: error setting owner of /var/log/puppetdb/puppetdb-access.log.1 to uid 109 and gid 113: Operation not permitted error: destination /var/log/puppetdb/puppetdb.log.1 already exists, renaming to /var/log/puppetdb/puppetdb.log.1-2017111306.backup error: error setting owner of /var/log/puppetdb/puppetdb.log.1 to uid 109 and gid 113: Operation not permitted run-parts: /etc/cron.daily/logrotate exited with return code 1 Yet the puppetdb seems to be rotating already automagically all by itself: # ls -l /var/log/puppetdb/ total 1216 -rw-r--r-- 1 puppetdb puppetdb 7778 Okt 31 00:00 puppetdb-2017-10-30.0.log.gz -rw-r--r-- 1 puppetdb puppetdb 7953 Nov 1 00:00 puppetdb-2017-10-31.0.log.gz -rw-r--r-- 1 puppetdb puppetdb 7909 Nov 2 00:00 puppetdb-2017-11-01.0.log.gz -rw-r--r-- 1 puppetdb puppetdb 9758 Nov 3 00:01 puppetdb-2017-11-02.0.log.gz -rw-r--r-- 1 puppetdb puppetdb 9423 Nov 4 00:00 puppetdb-2017-11-03.0.log.gz -rw-r--r-- 1 puppetdb puppetdb 9327 Nov 5 00:00 puppetdb-2017-11-04.0.log.gz -rw-r--r-- 1 puppetdb puppetdb 7781 Nov 6 00:00 puppetdb-2017-11-05.0.log.gz -rw-r--r-- 1 puppetdb puppetdb 6207 Nov 7 00:00 puppetdb-2017-11-06.0.log.gz -rw-r--r-- 1 puppetdb puppetdb 6242 Nov 8 00:00 puppetdb-2017-11-07.0.log.gz -rw-r--r-- 1 puppetdb puppetdb 6219 Nov 9 00:00 puppetdb-2017-11-08.0.log.gz -rw-r--r-- 1 puppetdb puppetdb 6236 Nov 10 00:00 puppetdb-2017-11-09.0.log.gz -rw-r--r-- 1 puppetdb puppetdb 6233 Nov 11 00:01 puppetdb-2017-11-10.0.log.gz -rw-r--r-- 1 puppetdb puppetdb 6193 Nov 12 00:01 puppetdb-2017-11-11.0.log.gz -rw-r--r-- 1 puppetdb puppetdb 6446 Nov 13 00:01 puppetdb-2017-11-12.0.log.gz -rw-r--r-- 1 puppetdb puppetdb 21918 Okt 31 00:00 puppetdb-access-2017-10-30.0.log.gz -rw-r--r-- 1 puppetdb puppetdb 47625 Nov 1 00:00 puppetdb-access-2017-10-31.0.log.gz -rw-r--r-- 1 puppetdb puppetdb 47975 Nov 2 00:00 puppetdb-access-2017-11-01.0.log.gz -rw-r--r-- 1 puppetdb puppetdb 48470 Nov 3 00:01 puppetdb-access-2017-11-02.0.log.gz -rw-r--r-- 1 puppetdb puppetdb 46569 Nov 4 00:01 puppetdb-access-2017-11-03.0.log.gz -rw-r--r-- 1 puppetdb puppetdb 61288 Nov 5 00:04 puppetdb-access-2017-11-04.0.log.gz -rw-r--r-- 1 puppetdb puppetdb 59023 Nov 6 00:03 puppetdb-access-2017-11-05.0.log.gz -rw-r--r-- 1 puppetdb puppetdb 44198 Nov 7 00:03 puppetdb-access-2017-11-06.0.log.gz -rw-r--r-- 1 puppetdb puppetdb 44500 Nov 8 00:03 puppetdb-access-2017-11-07.0.log.gz -rw-r--r-- 1 puppetdb puppetdb 44487 Nov 9 00:03 puppetdb-access-2017-11-08.0.log.gz -rw-r--r-- 1 puppetdb puppetdb 44423 Nov 10 00:03 puppetdb-access-2017-11-09.0.log.gz -rw-r--r-- 1 puppetdb puppetdb 44634 Nov 11 00:00 puppetdb-access-2017-11-10.0.log.gz -rw-r--r-- 1 puppetdb puppetdb 44643 Nov 12 00:00 puppetdb-access-2017-11-11.0.log.gz -rw-r--r-- 1 puppetdb puppetdb 44900 Nov 13 00:00 puppetdb-access-2017-11-12.0.log.gz -rw-r--r-- 1 puppetdb puppetdb 428948 Nov 13 09:55 puppetdb-access.log -rw--- 1 puppetdb adm 0 Nov 13 06:25 puppetdb-access.log.1 -rw--- 1 puppetdb adm 0 Nov 1 06:25 puppetdb-access.log.1-2017110206.backup -rw--- 1 puppetdb adm 0 Nov 2 06:25 puppetdb-access.log.1-2017110306.backup -rw--- 1 puppetdb adm 0 Nov 3 06:25 puppetdb-access.log.1-2017110406.backup -rw--- 1 puppetdb adm 0 Nov 4 06:25 puppetdb-access.log.1-2017110506.backup -rw--- 1 puppetdb adm 0 Nov 5 06:25 puppetdb-access.log.1-2017110606.backup -rw--- 1 puppetdb adm 0 Nov 6 06:25 puppetdb-access.log.1-2017110706.backup -rw--- 1 puppetdb adm 0 Nov 7 06:25 puppetdb-access.log.1-2017110806.backup -rw--- 1 puppetdb adm 0 Nov 8 06:25 puppetdb-access.log.1-2017110906.backup -rw--- 1 puppetdb adm 0 Nov 9 06:25 puppetdb-access.log.1-2017111006.backup -rw--- 1 puppetdb adm 0 Nov 10 06:25 puppetdb-access.log.1-201706.backup -rw--- 1 puppetdb adm 0 Nov 11 06:25
Bug#878193: fails to start with minimal dependencies from testing
Package: puppetdb Version: 4.4.1-1 Severity: normal Hi, While trying to start puppetdb with as much a testing install as possible, I get: --(snip)-- Oct 10 23:14:49 puppet-db systemd[1]: Started Puppet data warehouse server. Oct 10 23:14:57 puppet-db java[32440]: Exception in thread "main" java.lang.RuntimeException: No such var: cli/parse-opts, compiling:(puppetlabs/kitchensink/core.clj:867:52) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.lang.Compiler.analyze(Compiler.java:6688) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.lang.Compiler.analyze(Compiler.java:6625) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3766) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.lang.Compiler.analyzeSeq(Compiler.java:6870) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.lang.Compiler.analyze(Compiler.java:6669) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.lang.Compiler.access$300(Compiler.java:38) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6269) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.lang.Compiler.analyzeSeq(Compiler.java:6868) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.lang.Compiler.analyze(Compiler.java:6669) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.lang.Compiler.analyzeSeq(Compiler.java:6856) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.lang.Compiler.analyze(Compiler.java:6669) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.lang.Compiler.analyze(Compiler.java:6625) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:6005) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5380) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3972) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.lang.Compiler.analyzeSeq(Compiler.java:6866) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.lang.Compiler.analyze(Compiler.java:6669) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.lang.Compiler.analyzeSeq(Compiler.java:6856) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.lang.Compiler.analyze(Compiler.java:6669) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.lang.Compiler.access$300(Compiler.java:38) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.lang.Compiler$DefExpr$Parser.parse(Compiler.java:590) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.lang.Compiler.analyzeSeq(Compiler.java:6868) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.lang.Compiler.analyze(Compiler.java:6669) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.lang.Compiler.analyze(Compiler.java:6625) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.lang.Compiler.eval(Compiler.java:6931) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.lang.Compiler.load(Compiler.java:7379) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.lang.RT.loadResourceScript(RT.java:372) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.lang.RT.loadResourceScript(RT.java:363) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.lang.RT.load(RT.java:453) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.lang.RT.load(RT.java:419) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.core$load$fn__1621.invoke(core.clj:5893) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.core$load.invokeStatic(core.clj:5892) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.core$load.doInvoke(core.clj:5876) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.lang.RestFn.invoke(RestFn.java:408) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.core$load_one.invokeStatic(core.clj:5697) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.core$load_one.invoke(core.clj:5692) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.core$load_lib$fn__1570.invoke(core.clj:5737) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.core$load_lib.invokeStatic(core.clj:5736) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.core$load_lib.doInvoke(core.clj:5717) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.lang.RestFn.applyTo(RestFn.java:142) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.core$apply.invokeStatic(core.clj:648) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.core$apply.invoke(core.clj:641) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.core$load_libs.invokeStatic(core.clj:5775) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.core$load_libs.doInvoke(core.clj:5758) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.lang.RestFn.applyTo(RestFn.java:137) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.core$apply.invokeStatic(core.clj:648) Oct 10 23:14:57 puppet-db java[32440]: #011at clojure.core$apply.invoke(core.clj:641) Oct 10 23:14:57 puppet-db java[32440]: #011at
Bug#610837: xen-tools: Should support providing enabling and/or providing manually IPv6 settings
Hi, Fully supporting that forcing DHCPv4 or static IPv4 is no longer the optimal config. IMHO we should have options: - no address give => just use inet6 auto (maybe even default to DHCPv4 in parallel too - OPTIONALLY!) That will be using full autoconfig with privacy extensions by default and "just get some connectivity" online - The --ip should understand both IPv6 and IPv4. If multiple arguments are given, the secondaries should be auto added (i.e. allowing to describe dual-stack) - The --netmask should default to 64 for IPv6 addresses and be optional if --ip is IPv6 - The --broadcast isn't really required anyway. Might be ditched - The --nameservers should be accepting both IPv4 and IPv6 - A new --dhcpv6 should allow for both stateless and stateful address assignment. For stateful a --duid should be added similar to the --mac to allow "predicing" the DHCP lease. - Additionally to using RA+SLAAC+privacy it would be cool to have an option to use a known prefix (e.g. the local prefix) and just dynamically generate a "random" IPv6 that is then used statically (like the dynamically generated root password) using a generator just like http://www.infracaninophile.co.uk/articles/hotchpotch/rand-.pl Maybe the prefix of the local interface on the Xen host should be default if no other option is configured. Thanks! Kilian
Bug#875665: fix wording for debootstrap using cdebootstrap
Package: xen-tools Version: 4.7-1 Severity: wishlist Hi, When using cdebootstrap the message still reads: Installation method: debootstrap Using cdebootstrap as debootstrap command This is at best confusing. IMHO the check for the toolchain should be moved up and the informational message should be corrected to represent the reall tool chain instead of the "installation flavour". Thanks! Kilian
Bug#875663: update installation to systemd (and disable unused ttys)
Package: xen-tools
Version: 4.7-1
Severity: normal
Hi,
Looking at /usr/share/xen-tools/stretch.d/30-disable-gettys it seems the
script isn't yet updated to systemd but still considers only upstart.
This yields to:
getty-static.service loaded active exitedgetty on tty2-tty6 if dbus and logind are not available
getty@tty1.service loaded active running Getty on tty1
getty@tty2.service loaded active running Getty on tty2
getty@tty3.service loaded active running Getty on tty3
getty@tty4.service loaded active running Getty on tty4
getty@tty5.service loaded active running Getty on tty5
getty@tty6.service loaded active running Getty on tty6
Probably the script should contain something like:
if [ -d /run/systemd/system ];then
for i in 1 2 3 4 5 6;do
#systemctl stop getty@tty${i}.service
systemctl disable getty@tty${i}.service||true
done
#systemctl stop getty-static.service
systemctl disable getty-static.service||true
fi
Thanks!
Kilian
Bug#875662: password encryption should match login.defs (SHA512)
Package: xen-tools Version: 4.7-1 Severity: normal Hi, to match the current default of login.defs the default password encryption should be raised to SHA512. Using MD5 or SHA256 should only be allowed as a manual override. Thanks! Kilian
Bug#875661: SSH config should allow to only use secure defaults
Package: xen-tools Version: 4.7-1 Severity: normal Hi, In addition to https://github.com/xen-tools/xen-tools/issues/18 it should be possible to also update the sshd defaults using debconf openssh-server/permit-root-login to also allow creating non-root-login by default. Even more so, I'd love to also see an option to allow generating 4k or 8k RSA keys (and ditch ECDSA as well as DSA entirely) right up front. Maybe even allow only ED25519. Thanks! Kilian
Bug#838291: wpasupplicant: networking.service fails to bring up wlan interface, when VERBOSE set to yes
Hi Dmitriy, since your bug actually breaks non-VERBOSE mode, I'd suggest using as patch: --(snip)-- # diff -u /etc/wpa_supplicant/functions.sh /tmp/functions.sh --- /etc/wpa_supplicant/functions.sh2017-02-20 11:55:11.0 +0100 +++ /tmp/functions.sh 2017-08-10 13:58:58.532248148 +0200 @@ -49,7 +49,7 @@ # verbosity variables if [ -n "$IF_WPA_VERBOSITY" ] || [ "$VERBOSITY" = "1" ]; then - TO_NULL="/dev/stdout" + TO_NULL="&1" DAEMON_VERBOSITY="--verbose" else TO_NULL="/dev/null" @@ -117,7 +117,7 @@ ;; "stderr") shift - echo "$WPA_SUP_PNAME: $@" >/dev/stderr + echo "$WPA_SUP_PNAME: $@" >&2 ;; *) ;; # --(snip)-- That one works for me and does maintain the current feature set. Best, Kilian signature.asc Description: Digital signature
Bug#819048: systemd service should be run while network is still online
Package: unattended-upgrades Version: 0.83.3.2+deb8u1 Severity: wishlist Tags: patch Dear maintainer, since the shutdown part in systemd does not list network-online.target in /lib/systemd/system/unattended-upgrades.service the shutdown is quite likely to be run at a rather late stage in the shutdown process. Probably it's not strictly necessary to have online networking for packages to be installed correctly, but that may as well be just a minimal patch to ensure the service is run first, before killing stuff like remote filesystems etc.. IMHO the /lib/systemd/system/unattended-upgrades.service should therefore include something like: [Unit] Wants=network-online.target Best, Kilian
Bug#812611: u-boot should have update-u-boot automatic in postinst like update-grub
Hi Rick, On Mon, Jan 25, 2016 at 08:13:04PM -0800, Rick Thomas wrote: ... > If something goes wrong with installing grub, you can boot from a CD or > via ethernet and recover or re-install. > If something goes wrong with installing u-boot, you have bricked your > device. The only recourse is J-tag. Not fun at all! Especially when your boot device is a SD or microSD card, I don't see why J-tag would be anywhere near what you need to recover. Even when a system usually runs off an eMMC my impression is that most devices out there still would allow booting off the SD cards slot if you only inserted a properly formatted card. T.b.h. I don't really see the risk you try to outline here (for the platforms I have). If you have the impression that "most" of the ARM systems out there are only equipped with a single boot device that's not removable, please do give a list. Otherwise, unbricking a vfat or ext4 partition on a PC should be piece of cake. > Installing u-boot is something that should only be undertaken very > carefully if you know what you're doing and are prepared to recover from a > mishap. Doing it automatically every time there's an update is not wise. Well, let's assume this: 1.) We've got a growing platform (i.e. current popcon isn't anywhere near what we expect to have in the next 3-4 year - read: lifespan of next stable). And we're not talking about the one single box in a lab or being your one-and-only private server plattform. We're talking about larger deployments where you would *want* to have unattended-upgrades and needrestart and alike mechanisms to take certain tasks off your shoulders (which is what I assume/hope IoT will look like). 2.) We're talking about a Debian stretch being stable (or maybe even what comes after stretch) - i.e. the u-boot package does only receive maintenance and security updates. 3.) You're installing u-boot on a platform that you very well know and where the procedure for updating u-boot is clearly outlined, i.e. no fancy magic, e.g. just a plain dd file into constant partition. 4.) Assume that we have security hole in u-boot that needs fixing. Debian security is putting together a DSA and the backported security fix for the stable release version. 5.) The admin of each and every system has had the chance to enable auto-updates for u-boot if they feel this a good thing for them under the configuration they run (e.g. booting from uSD card). The default of u-boot (for now) shall safely remain that auto-updates aren't enabled (unless of course the maintainer feels that there's reason to default otherwise on a given installation). In this scenario I would think DSA is much happier to just roll out the fix as-is compared to what we have now. Updating u-boot in jessie will catch at best 30%, probably rather 3% (or even less) due to the lack of people understand they need this update *and* knowing how to manually install it. The part of which platforms and setups can be considered auto-upgrade-safe would be something I'd leave for further discussion once we have a hook mimic in place and have some first experiences (and maybe some bugreports). So, to summarize: all I'm asking for is a hook that I can configure willingly (if I feel confident enough) to enable this auto-updating for my systems, in case there'd be any security issues with u-boot in the future and ensure I don't forget to enable/install them. Best, Kilian signature.asc Description: Digital signature
Bug#812611: u-boot should have update-u-boot automatic in postinst like update-grub
Package: u-boot Severity: wishlist Tags: d-i Hi Vagrant, as just discussed the d-i mimic of installing u-boot should also be available when updating u-boot packages in an installed system. There may be cases, where automatic updates may not be desired or where defaults are just simply not matching, so there should probably be a /etc/defaults/u-boot with: - an option to ENABLE/DISABLE - dd parameters like offset - the u-boot flavor and image file (if one would want to override it) When enabled the u-boot postinst should ensure the latest code is auto-activated just like at the end of d-i when installing the system. Since duplicating d-i code is not what we want, this probably means also creating a udeb with the u-boot-tools (and especially this "installer") and moving the relevant installer heuristic over to u-boot and replacing it in d-i with a matching structure to call this new tool. Best, Kilian
Bug#812540: Add ARCH_HISI for Lemaker HiKey support
Package: linux Version: 4.3.3-7 Severity: wishlist Tags: d-i Dear kernel maintainers, while trying to get a d-i booted on a Lemaker HiKey, tbm pointed out that ARCH_HISI is not (yet) activated on linux. Please enable it so we can add HiKey support to Debian. TIA! Best, Kilian
Bug#811028: IPv6-only hosts not working
Package: letsencrypt Version: 0.1.1-3 Severity: normal Tags: ipv6 upstream Dear maintainer, while trying to obtain a letsencrypt certificate on an IPv6-only the only result is: Failed authorization procedure. ipv6only.my.domain (http-01): urn:acme:error:unknownHost :: The server could not resolve a domain name :: No IPv4 addresses found for ipv6only.my.domain IMPORTANT NOTES: - The following 'urn:acme:error:unknownHost' errors were reported by the server: Domains: ipv6only.my.domain Error: The server could not resolve a domain name Since experimenting with new concepts like letsencrypt will be happening more likely on IPv6-enabled (and potentially IPv6-only) hosts, it'd be nice if there would be a workaround/fix to get this flying. TIA! Cheers, Kilian P.S.: yes, the hostname was edited and I have tried with a public FQDN that's IPv6-only signature.asc Description: Digital signature
Bug#805038: IPv6 NDP proxy not working correctly
Package: strongswan
Version: 5.3.3-2
Severity: normal
Tags: ipv6 upstream patch
Hi Yves,
similar to what's stated on https://wiki.strongswan.org/issues/1008
I've had to add this:
-(snip)-
# cat /etc/strongswan.d/proxyndp.updown
case $PLUTO_VERB in
OUTDEV=$(ip -6 r get ${PLUTO_PEER_CLIENT%}|sed -ne 's,^.*dev
\(\S\+\) .*,\1,p')
up-client-v6)
ip -6 neigh add proxy ${PLUTO_PEER_CLIENT%} dev ${OUTDEV:-eth0}
;;
down-client-v6)
ip -6 neigh delete proxy ${PLUTO_PEER_CLIENT%} dev ${OUTDEV:-eth0}
;;
esac
#
-(snip)-
to make my IPv6 work correctly inside my tunnels. I've enhanced the named
script from the bug slightly so that also allow for more than just an eth0
interface.
It would be nice if the Debian package could ship that by default until
upstream has included this or an equivalent fix to the issue.
Cheers,
Kilian
Bug#803772: New strongswan upstream version 5.3.3
Package: strongswan Version: 5.3.2-1 Severity: normal Dear maintainer, a new upstream version is available: 5.3.3. Please consider packaging it, as it bringd Framed-IPv6-Address for RADIUS accounting. Thanks! Best regards, Kilian signature.asc Description: Digital signature
Bug#774854: race condition between fur and fex_cleanup
Hi Moritz, On Mon, Jan 26, 2015 at 12:28:00PM +0100, Moritz Mühlenhoff wrote: On Mon, Dec 22, 2014 at 10:33:50PM +0100, Kilian Krause wrote: Package: fex Version: 20140917-1 Severity: serious Tags: security patch upstream pending confirmed jessie As upstream has released a new version of the fex package which closes a security issue and there is no CVE assigned, we'll use this bug to track the issue. Hi, what is the plan for unstable? You can either ask for an unblock with the release team (if the diff between testing an sid is small) or fix these in a targeted upload for testing-proposed-updates. Unstable already has a fixed version. Just jessie still hasn't as of now. The backports should also be updated once the new version is in jessie. I'm currently waiting a bit before asking for an unblock to make sure the package is really fit enough to go in and nobody is complaining. As the update has been reviewed quite a bit before this release, it probably is ready to go in as is. I'd rather not split the fix out and do only a partial patch for testing as per upstream's recommendation. Cheers, Kilian signature.asc Description: Digital signature
Bug#775281: raddb_dir is /etc/freeradius, not /etc/raddb
Package: freeradius Version: 2.1.12+dfsg-1.2 Severity: normal Dear maintainer, Unlike the manpage indicates, the default config files is searched in /etc/freeradius: # /usr/sbin/freeradius --help ... -d raddb_dirConfiguration files are in raddbdir/*. -n name Read raddb/name.conf instead of raddb/radiusd.conf ... # man freeradius |grep -A1 'config direc' -d config directory Defaults to /etc/raddb. Radiusd looks here for its configuration files such as the dictionary and the users files. # rm -f /etc/freeradius/radiusd.conf # /usr/sbin/freeradius -X -f ... including configuration file /etc/freeradius/radiusd.conf Unable to open file /etc/freeradius/radiusd.conf: No such file or directory Errors reading /etc/freeradius/radiusd.conf ... # The documentation inside the package should refer to the actual config file path(s) that are used in this installtion. Best, Kilian -- System Information: Debian Release: 7.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL set to de_DE.UTF-8) Shell: /bin/sh linked to /bin/dash signature.asc Description: Digital signature
Bug#738494: Acknowledgement (hash-slinger: sshfp doesn't support ECDSA host keys or SHA-2 fingerprints (RFC6594))
Hi Gerald, Thanks for the patch and your time to actually piece it together. I think it should just have one litte RFC-compliance check added - SHA1 is no longer defined in RFC for type 4 SSHFPs. ;-) Thus, the only valid combination is SSHFP 4 2 ... as per RFC. Apart from that, I'd really love to see it commited upstream and shipped with a new Debian package! Cheers, Kilian signature.asc Description: Digital signature
Bug#738489: hash-slinger: tlsa and openpgpkey scripts break on non-existent files (root.key, dlv.isc.org.key, ca-bundle.crt)
Hi Ondřej, since #752745 now resolved and dns-root-data in Debian... What's actually keeping us from fixing #738489 with either the patch already provided or any other solution you may have considered more appropriate (when filing 752745 as blocking bug to 738489)? Best, Kilian signature.asc Description: Digital signature
Bug#774722: tlsa doesn't find /etc/resolv.conf due to wrong (empty) default value
Package: hash-slinger
Version: 2.5-1
Severity: important
Tags: patch
Dear maintainer,
the tlsa utility seems to have a bad default on resolv.conf and should
be fixed as follows:
--- /usr/bin/tlsa 2015-01-06 20:40:10.788730437 +0100
+++ /tmp/tlsa 2015-01-06 20:36:31.453218044 +0100
@@ -396,7 +396,7 @@
parser.add_argument('-4', '--ipv4', dest='ipv4',
action='store_true',help='use ipv4 networking only')
parser.add_argument('-6', '--ipv6', dest='ipv6',
action='store_true',help='use ipv6 networking only')
parser.add_argument('--insecure', action='store_true', default=False,
help='Allow use of non-dnssec secured answers')
- parser.add_argument('--resolvconf', metavar='/PATH/TO/RESOLV.CONF',
action='store', default='', help='Use a recursive resolver listed in a
resolv.conf file (default: /etc/resolv.conf)')
+ parser.add_argument('--resolvconf', metavar='/etc/resolv.conf',
action='store', default='/etc/resolv.conf', help='Use a recursive resolver
listed in a resolv.conf file (default: /etc/resolv.conf)')
parser.add_argument('host', metavar=hostname)
parser.add_argument('--port', '-p', action='store', default='443',
help='The port, or \'*\' where running TLS is located (default: %(default)s).')
-(snip)-
The help text obviously is already talking about the correct location. What the
metavar value is needed for isn't really obvious to me, but making that point
to the correct system location feels at least not like making the situation
worse.
Cheers,
Kilian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773751: race condition between fur and fex_cleanup
Package: fex Version: 20140917-1 Severity: serious Tags: security patch upstream pending confirmed jessie As upstream has released a new version of the fex package which closes a security issue and there is no CVE assigned, we'll use this bug to track the issue. Problem is: a race condition between fur and fex_cleanup may create internal instead of external user. With the default configuration no auto registration is possible and no exploit is possible. You must have allowed user self registration via fex.ph. Background is a timing race condition that fex_cleanup will throw away the external user flag if the link a user is sent is not clicked/visited before fex_cleanup is run (i.e. usually next day). The user account will then be created with full internal user privileges instead of the reduced externel priv. set. The new release is currently being prepared for uploading into Debian. Some minor updates that have nothing to do with the issue at hand are currently being discussed between me and upstream. I'd guess we can have a new fixed version in unstable before end of this year - maybe even before Xmas. As we don't have a version in stable, I'll prepare uploads of wheezy-backports and squeeze-backports once we're in jessie with the new version. Since the other security fixes haven't been backported to oldstable (yet), it seems not very logical to start with this (rather minor) one. Best, Kilian signature.asc Description: Digital signature
Bug#676932: stun output failing
severity 676932 wishlist tags 676932 + wontfix upstream confirmed thanks Dear ubuntu6226, On Sun, Jun 10, 2012 at 05:56:09PM +0200, ubuntu6226 wrote: For bash scripting it would be nice that you correct this : stun -v stun.XX.org~/test.log All you have to do is add 21 since upstream has chosen to use clog in the code which uses STDERR not STDOUT. This is not working because it outputs not like it should. stun -v stun.XX.org | less is highly important to be working too Same as above. stun -v xxx 21 | less should work just fine. Obviously upstream regards even the -v output as debug info which should not be filling the logs. As a side note: the vovida code is rather a proof of concept than an actual server implementation. Thank you developing STUN. It is greatly useful !! Btw a support of the newer protocol would be appreciated if possible still I think you should look forward to the new stuntman upload that I'll try to finish in the next weeks. In case you can confirm the fd redirect fixes your issue, I'd go ahead with closing this bug. Best, Kilian signature.asc Description: Digital signature
Bug#684117: unblock: fex/20120718-4
Hi, On Sun, Oct 07, 2012 at 08:54:07PM +0200, Philipp Kern wrote: On Sun, Oct 07, 2012 at 07:35:09PM +0200, Kilian Krause wrote: since F*EX is now re-added as non-free with Perl Artistic license I herewith renew my request to allow the fex package to proceed to testing and thus allowing users of squeeze an upgrade path. did you submit the filtered diff Adam requested? no, and I've just ceased trying to cut down 55k lines of diff to the relevant parts. Since I don't quite feel that I will end up with what you or Adam feel relevant (and hence we'll do this loop a couple of times which none of us has the time to) I'll leave it up to d-release to decide wether or not we shall re-include fex as is or just leave it out for wheezy and have it come back in jessy. -- Best regards, Kilian signature.asc Description: Digital signature
Bug#684117: unblock: fex/20120718-4
Hi Philipp, since F*EX is now re-added as non-free with Perl Artistic license I herewith renew my request to allow the fex package to proceed to testing and thus allowing users of squeeze an upgrade path. Cheers, Kilian signature.asc Description: Digital signature
Bug#684117: unblock: fex/20120718-4
Hi Philipp, On Wed, Aug 22, 2012 at 02:24:41AM +0200, Philipp Kern wrote: On Sat, Aug 18, 2012 at 09:13:42PM +0100, Adam D. Barratt wrote: + YOU ARE NOT ALLOWED TO USE THIS SOFTWARE FOR MILITARY PURPOSES OR WITHIN + MILITARY ORGANIZATIONS! THIS INCLUDES ALSO MILITARY RESEARCH AND + EDUCATION! That doesn't really seem like something Debian can really meet or enforce... Hereby bringing this to the attention of the ftp-masters. fex is in main but includes that clause on top of AGPL-3. Which probably means for one that it's no longer compatible with GPL code, which might or might not be relevant, and, more severly, it's not compatible with the DFSG. after some discussion with upstream the problem is as follows: Upstream has ever since had this clause in his license file so this is no new requirement. Obvious up until now this has either been overlooked or not been a problem. The change from GPL to AGPL has thus nothing to do with his intention to not support terrorist activities and to ensure the broadest coverage possible he has ruled out all military. As I'm not seeing any chance of meeting DFSG criteria 5 and 6 with the above intention (which clearly is discriminating certain groups - even though personally I can perfectly well understand upstream's will on why this is) I'm herewith seeking ftpmaster assistance on coming forth with a solution. IOW, I'm out of ideas on how to solve the problem of the DFSG while respecting upstreams intended limitation. Is there any way we could formulate such limitation as upstream desires without breaking the DFSG? Unless someone can come forth with a wording that does cover both requirements I guess we'll be bound to removing F*EX from the archive - which IMHO would be a sad loss as there currently exsits no other product in Debian providing the same services as F*EX does. Thanks for your help. -- Best regards, Kilian signature.asc Description: Digital signature
Bug#684117: unblock: fex/20120718-4
Hi Adam,
On Sat, Aug 18, 2012 at 09:13:42PM +0100, Adam D. Barratt wrote:
On Tue, 2012-08-07 at 09:10 +0200, Kilian Krause wrote:
Please unblock package fex
It addresses all currently known issues. It would be great if this could
make it into wheezy still to spare us unneccessary work with supporting
the 20120215-3 on our own.
+ if (open $log,'',$log) {
Am I missing some Perl trickery here, or should the second $log be
something else?
This is perfectly ok according to upstream and works as intended.
[...]
+ YOU ARE NOT ALLOWED TO USE THIS SOFTWARE FOR MILITARY PURPOSES OR WITHIN
+ MILITARY ORGANIZATIONS! THIS INCLUDES ALSO MILITARY RESEARCH AND
+ EDUCATION!
That doesn't really seem like something Debian can really meet or
enforce...
Upstream will try to come forth with an updated license.
The overall diff is
187 files changed, 2409 insertions(+), 19174 deletions(-)
Most of the deletions will be the fix removal, but that still leaves
quite a lot to review, which mostly seems to be made up of small
changes. I've tried tying some of them up with the upstream changelog,
but none of that appears to account for e.g. the repeated
s/time/int(time)/.
Would it be possible to have a filtered diff, ignoring the fix removal,
documentation changes and the hidden easter egg options which upstream
seem to have added?
I'll see what I can come up with.
--
Best regards,
Kilian
signature.asc
Description: Digital signature
Bug#684117: unblock: fex/20120718-4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package fex It addresses all currently known issues. It would be great if this could make it into wheezy still to spare us unneccessary work with supporting the 20120215-3 on our own. F*EX is a file exchange service based on http. The previous versions did include a java applet (F*IX) that yielded a more fancy UI than the classic HTML web page. Upstream has dropped the entire java code base as its maintainer is no longer able to support it. The F*EX maintainer himself denoted the drop with F*IX removed because of too many bugs and no maintainer any more in the release notes for the last version. The current version in wheezy (20120215-3) is still shipping with F*IX. unblock fex/20120718-4 Cheers, Kilian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656631: F*IX upstream issue documented
Dear Morten, I've added a note to README.Debian (see 1e65c0c in colab-maint/fex.git, http://anonscm.debian.org/gitweb/?p=collab-maint/fex.git;a=commit;h=1e65c0c019a5bc4ff0528d9f1b0a9500ffc99a53) which should shed a bit more light onto the issue. If you feel that there's a better wording for what you had in mind, please do feel free to come up with a patch. -- Best regards, Kilian signature.asc Description: Digital signature
Bug#484575: icinga core-nrpe for Debian?
Hi guys, Is there any chance we'll see an icinga core-nrpe package in Debian soon (fixing #484575)? What's required/missing for having full IPv6 support with NRPE in your eyes? Anything besides just doing it, i.e. preparing the package from a Git snapshot and stuffing that into NEW? -- Best regrads, Kilian signature.asc Description: Digital signature
Bug#619734: RFS: taxbird (updated package)
Hi Olaf, On Mon, Aug 08, 2011 at 10:49:36PM +0200, Olaf Dietsche wrote: Kilian Krause kil...@debian.org writes: On Mon, Aug 08, 2011 at 12:26:32PM +0200, Olaf Dietsche wrote: I've seen build problems on https://buildd.debian.org/status/package.php?p=taxbirdsuite=sid The build problem could be fixed by adding autotools-dev to the build dependencies. What should I do next? Just wait for a bug report? Upload taxbird 0.16-0.2 with a fixed Build-Depends? Something else ...? If you know the solution, we should pump the fixed version into SID with the same procedure as before, just use a DELAYED/1 or so. Can you prepare that please? I uploaded taxbird 0.16-0.2 to debian-mentors. I also emailed the NMU-diff to 619...@bugs.debian.org. Thanks! Looks like the package has some problems rebuilding cleanly (which is what I usually do just to make sure such errors are caught). I'd welcome if you could coordinate with the current maintainer to get the package into better shape yet I have some doubts that this should be done in NMUs. I've now built the package (only once) so that it actually contains only the debdiff you've already sent to the bug and uploaded to DELAYED/1. If there are additional steps I missed, please tell me so. Not regarding the NMU. Thanks! -- Best regards, Kilian signature.asc Description: Digital signature
Bug#560721: RFS: spice
Hi Liang, On Sat, Jul 23, 2011 at 04:18:11PM +0800, Liang Guo wrote: I am looking for a sponsor for my package spice. I override configure-generated-file-in-source lintian warnings, for spice_0.8.2.orig-celt.tar.gz come with config.log and config.status and debian/rules will delete them. - dget http://mentors.debian.net/debian/pool/main/s/spice/spice_0.8.2-1.dsc You shouldn't need to override these warnings if the clean target would just seriously delete them (not as make distclean but plain rm -f). Alternatively you could stuff them into debian/clean. That should get rid of the warning and thus the need to override. What makes me wonder more though is that you put autotools-dev into the Build-Depends yet do not seem to make use of it. Moreover you specify this package is only suitable to build on i386 and amd64. Most probably these are the only platforms that you've built and tested this on - but apart from this, is there any known limitation why it would not be buildable on any other arch? Shouldn't the source be arch:any rather? Regarding the embedded celt I'm probably as unhappy with the solution as the rest and I'm inclined to say it should be packaged separately to scale better. Yet I also see that'd be stepping quite a lot onto the celt maintainers (who don't want the celt051 in the first place). Your patches are not marked as forwarded upstream. I guess upstream would be interested in them though. So please try to find out about the arch:all issue, add the missing autotools-dev files replacement and report back to get the upload prepared. Thanks! -- Best regards, Kilian signature.asc Description: Digital signature
Bug#633132: ekiga-dbg: uninstallable (libpt2.6.7-dbg disappeared)
Hi Eugen, On Sat, Jul 09, 2011 at 01:39:17PM +0200, Eugen Dedu wrote: On 09/07/11 07:30, Mark Purcell wrote: On Fri, 2011-07-08 at 20:13 +0100, Adam D. Barratt wrote: On Fri, 2011-07-08 at 20:49 +0200, Julien Cristau wrote: apparently the latest ptlib upload decided to drop its -dbg package, but ekiga-dbg still depends on it. Please fix asap. Specifically, it looks like you want to be depending on libpt-dbg now. Eugen, Kilian, My doing, I have dropped the version in the package name, as one will only want to install one libpt-dbg at a time. With the ekiga packaging you won't have to make a sourceful change every time ptlib changes API. This is the same as was done earlier with libopal-dbg (#586141). I have just committed the change in svn. Kilian, could you upload the new package? Thanks! I've done some more finishing touches and will upload the new version into Debian later today. I'm somewhat unsure whether #630266 will bite us yet. Have you looked into this already? (What about moving ekiga from svn to git? :o)) Not sure what the general position on the pkg-gnome archive is. Will check that. -- Best regards, Kilian signature.asc Description: Digital signature
Bug#532182: [uscan] --force-download should also be able to not execute user's action scripts
Hi, just to round up this bug I'd like to throw in another aspect of quite the same basic idea. When I want to download the orig.tar.* for reference checking I further do not want the action from debian/watch to be executed. All I'm interested in is the tarball itself. Yet there is no way to turn off the action (uupdate, svn-update etc.) in any way, is there? -- Best regards, Kilian signature.asc Description: Digital signature
Bug#613246: open-vm-tools moans about unable to load modules with default Squeeze install
Package: open-vm-tools Version: 1:8.4.2-261024-1 Severity: normal Tags: squeeze With a standard Squeeze install the following gets dumped onto the booting console: -(snip)- Loading open-vm-tools modules: vmhgfsFATAL: Module vmhgfs not found. vmmemctlFATAL: Module vmmemctl not found. vmsyncFATAL: Module vmsync not found. . -(snip)- ...and with no apparent reason why that is. Host is ESXi 4.1 (free vSphere License). Sounds to me as if those modules had not been built or so. -- System Information: Debian Release: 6.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages open-vm-tools depends on: ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libfuse2 2.8.4-1.1 Filesystem in USErspace library ii libgcc1 1:4.4.5-8 GCC support library ii libglib2.0-0 2.24.2-1 The GLib library of C routines ii libicu44 4.4.1-7International Components for Unico ii libstdc++64.4.5-8The GNU Standard C++ Library v3 Versions of packages open-vm-tools recommends: ii ethtool 1:2.6.34-3 display or change Ethernet device ii open-vm-source 1:8.4.2-261024-1 Source for VMware guest systems dr ii zerofree1.0.1-2 zero free blocks from ext2/3 file- Versions of packages open-vm-tools suggests: pn open-vm-toolbox none (no description available) -- Configuration Files: /etc/vmware-tools/tools.conf changed: -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110213180305.1533.51564.reportbug@matilda.surft.normalerweise
Bug#612498: Please support kFreeBSD port
Package: open-vm-source Severity: normal Hi, as kFreeBSD is now official arch as per Squeeze release, please also include that arch into open-vm-* tools. According to the website the support should be all there. Best regards, Kilian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#611109: New upstream version 20110112
Package: fex Version: Severity: wishlist Tags: patch According to http://fex.rus.uni-stuttgart.de/fex.html the current version is 20110112 -- System Information: Debian Release: 6.0 APT prefers stable APT policy: (990, 'stable'), (800, 'testing') Architecture: i386 (x86_64) Kernel: Linux 2.6.32-5-vserver-amd64 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to de_DE.UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528497: asterisk: false EX-CANARY message on startup
Tzafrir, On Wed, May 13, 2009 at 01:02:12PM +0300, Tzafrir Cohen wrote: When Asterisk runs in real-time scheduling priority (-p, the default in Debian), it may not be so nice if it gets into a 100% CPU loop. Thus as of Asterisk 1.6.0 there is a separate Asterisk Canary child process that runs at a normal priorty and writes every 5 seconds to /var/run/asterisk/alt.asterisk.canary.tweet.tweet.tweet ...sounds to me like we would need to initialize that file in the init script to make sure the tweet is there when asterisk is launched. Is that a possible solution? -- Best regards, Kilian signature.asc Description: Digital signature
Bug#513017: relabel #513017
relabel 513017 ITP: avantfax -- Web application for managing faxes on HylaFAX fax servers thanks Hi, there is actually some code in pkg-voip's SVN on alioth checked in by Bjoern Boschman bjo...@boschman.de that may eventually get ready for uploading to Debian. Thus changing the bug title to reflect that work has already begun. If someone is willing to step up as comaint, there's sure a place in pkg-voip to get this ready for closing this ITP. -- Cheers, Kilian signature.asc Description: Digital signature
Bug#459712: build-conflicts with its own runtime
Faidon, On Thu, Apr 03, 2008 at 07:29:59PM +0300, Faidon Liambotis wrote: [the following is a more useful description of the bug than the irc log] pwlib and pwlib-titan build-conflict with their runtime parts besides the -dev parts. I think this is being done because a sample program is built and run when the package builds as a mean to catch runtime errors/screwups early. right. There were some pretty regular cases when subsequent builds were running fine but executing the lib was then failing with runtime errors. Therefore this runtime check at build time was neccessary to be introduced. I'm not sure, however, if the conflict is really needed. Unfortunately it has been in the past. The current situation is bad because people trying to do build tests on their desktops have to uninstall ekiga among others. They can still install a fresh chroot (build flavour) which will then allow them to be clean with the build-requirements that might otherwise demand them to upgrade the entire system to quite recent versions - and screw up their daily desktop install. Apart from that it's way easier to control (security wise) and eventually even wrap up and copy/move around. For these and other reasons it has not been that much of a problem until now. I have before and would still even actively discourage any bug reporter of this kind of bugs to do this native development and rather go for chroot/vserver/xen etc.. The ekiga-snapshots have received a DEB_BUILD_OPTIONS switch to disable this due to some demand. It should not be a problem to copy this over back to Debian. Kilian, you've added both the conflicts and the sample build/run. Have you investigated if the conflicts is needed? Yes. In the case that it is, how would you feel about making the sample build/run conditional on the presence of libpt in the build system? Well, it was very much needed as a precaution in the past - especially on the non-trivial architectures. Doing a conditional test without enforcing it to FTBFS the package would just reintroduce that harm with a very low bar to jump over. If you think it is seriously needed we should add the DEB_BUILD_OPTIONS switch and conditionalize it in there - or plain not run it at all. -- Best regards, Kilian signature.asc Description: Digital signature
Bug#459712: build-conflicts with its own runtime
Faidon, On Thu, Apr 03, 2008 at 10:10:32PM +0300, Faidon Liambotis wrote: Kilian Krause wrote: In the case that it is, how would you feel about making the sample build/run conditional on the presence of libpt in the build system? Well, it was very much needed as a precaution in the past - especially on the non-trivial architectures. Doing a conditional test without enforcing it to FTBFS the package would just reintroduce that harm with a very low bar to jump over. If you think it is seriously needed we should add the DEB_BUILD_OPTIONS switch and conditionalize it in there - or plain not run it at all. I wasn't specific enough about the conditional: What I meant was, skipping the tests altogether if /usr/lib/libpt.so.1.10.1 is found. That way, it'll do the runtime test on clean chroots but skip it in development environments, which is much better than having a DEB_BUILD_OPTIONS. Any objections to that? the check should verify neither libpt.so nor libpt.so.$(SOVER) are available. If you can then verify that this does no longer cause a misleading false positive (with the check failing before) then should be able to safely commit. -- Best regards, Kilian signature.asc Description: Digital signature
Bug#438792: srtp 1.4.4?
Mikael, On Thu, Dec 06, 2007 at 04:35:53PM +0100, Mikael Magnusson wrote: What do you think about using latest stable srtp version (1.4.4) instead of current CVS which is buggy? The test suite in srtp 1.4.4 succeeds, but crashes in CVS HEAD, when run on x86. if 1.4.4 is the proper fix for all our FTBFS and works then sure we should update! -- Best regards, Kilian signature.asc Description: Digital signature
Bug#454438: proposed-updates links broken
Package: www.debian.org Severity: normal On http://www.debian.org/releases/proposed-updates.en.html there's links to http://ftp-master.debian.org/proposed-updates.html and http://ftp-master.debian.org/oldstable-proposed-updates.html. Both of which don't exist. Please update to the correct location. -- System Information: Debian Release: 3.1 APT prefers oldstable APT policy: (990, 'oldstable'), (800, 'testing') Architecture: i386 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-vserver-amd64 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453752: RM: kiax -- RoM; dead upstream
Package: ftp.debian.org Severity: normal Among other things problems like #431227 will never get fixed as upstream is dead for long. Therefore it's only a matter of time until more problems appear and we've reached the conclusion among the Debian pkg-voip team that the proper action is to have it removed from unstable as its version will be available through Debian Etch for a long time still and by the time Etch is discontinued as oldstable Ekiga 3.0 should have taken over its place as IAX2 client. Thanks! -- Best regards, Kilian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453644: [debchange] Please add a config file option to turn off -t with changelog heuristics
Package: devscripts Version: 2.10.11 Severity: normal File: /usr/bin/dch Follow-Up-for: #448795 While it's perfectly understandable that the diff is reduced and merge is eased, there is no way to spot when that last commit was done. Therefore having the --nomainttrailer as a config option in ~/.devscripts would be the perfect solution to use it together with changelog heuristics without going through command line each time would be the perfect solution for everyone. Please add such an option. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (990, 'stable'), (900, 'testing'), (800, 'unstable') Architecture: powerpc (ppc64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.21-2-powerpc64 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages devscripts depends on: ii debianutils 2.17 Miscellaneous utilities specific t ii dpkg-dev1.14.7 package building tools for Debian ii libc6 2.6.1-1 GNU C Library: Shared libraries ii perl5.8.8-7etch1 Larry Wall's Practical Extraction ii sed 4.1.5-1 The GNU sed stream editor Versions of packages devscripts recommends: ii fakeroot 1.5.10 Gives a fake root environment -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#449144: tsclient: Please add RDPv5 disk mapping support (patch available)
Clement, On Wed, Nov 07, 2007 at 08:56:52PM +0100, Clement 'nodens' Hermann wrote: Kilian Krause a écrit : ok, let's start with the obvious. The Debian packaging of tsclient is supposed to be the debian/ dir only. I.e. if you have a new upstream source, there is no need to patch the full source to the new version and mail that as diff. You just include the new tarball version for that release in debian/changelog and make the neccessary adjustments in debian/. Most commonly it's a good idea to add a get-orig-source target for this - or to plain use it if it's there already. ;) Duh. I didn't saw this target. I told you I wasn't familiar with CDBS ;) It's not so much CDBS, it's more a pkg-gnome and pkg-voip standard. ;) (Actually it's a Buildserver.NET prerequisite) For the all in one patch, I actually don't know why I did that. I should have known better. Of course a patch against the debian dir is the way to go. Second you included automake1.9 and autoconf in the Build-Deps. That generally is a *very good* indication for things that have gone utterly wrong. For a proper packaging you should not regenerate the configure during the build to keep a certain amount of reproducability. That's the reason there was a patch for that update to make the outcome rather predictable. Maintainer mode is for developers, not for packagers. ;) I misread guidlines in /usr/share/doc/autotools-dev. Now that you point it to me, I can see that I should have paid more attention to the introduction ;) Yes. ;) Moreover if you drop patches, it's always nice to know why this is no longer needed (added included upstream for that reason). Ok. Thirdly, the SVN was a bit further, so your patch didn't really apply cleanly. I have manually fixed that part. The result with some slight modifications to get the package mostly lintian clean I have put in SVN[1]. Can you verify this is the intended result so I can go and upload it? Thanks! It is OK to me, except that I just saw a little UI problem in the patch. The remote drive mapping should be disabled in the UI when the selected protocol is not RDP. Attached is a svn diff that correct it. Applied and released to unstable. Thanks for your help! My friend should upgrade the sourceforge version shortly (it seems it is not possible to attach a new file if you are not the original submitter). Great. Maybe you can also have a look at fixing these remaining lintian warnings with that new release: W: tsclient: manpage-has-bad-whatis-entry usr/share/man/man1/tsclient.1.gz W: tsclient: desktop-entry-contains-unknown-key /usr/share/applications/tsclient.desktop:69 Actions Thanks again! -- Best regards, Kilian signature.asc Description: Digital signature
Bug#449144: tsclient: Please add RDPv5 disk mapping support (patch available)
Clement, On Wed, Nov 07, 2007 at 08:56:52PM +0100, Clement 'nodens' Hermann wrote: It is OK to me, except that I just saw a little UI problem in the patch. The remote drive mapping should be disabled in the UI when the selected protocol is not RDP. Attached is a svn diff that correct it. ...actually the new version will be in incoming as soon as ries is fixed. Right now the uploading still seems to be broken, so it'll need to wait till tomorrow to actually hit the archive. -- Best regards, Kilian signature.asc Description: Digital signature
Bug#449144: tsclient: Please add RDPv5 disk mapping support (patch available)
Clement, On Mon, Nov 05, 2007 at 07:12:40PM +0100, Clement 'nodens' Hermann wrote: Oops... wrong patch... the good one is attached. Thanks. Let's get started reviewing. Clement 'nodens' Hermann a écrit : Hi all, Here is the patch against 0.148 source. The source package is available on http://clement.hermann.free.fr/debian/tsclient/ along with binary builds for i386 and amd64. I'm not familiar with the gnome packaging team methods (uploaders and such) and did my best to do it the gnome packaging way without understanding everything involved (uploaders and such), so please correct whatever I did wrong. ok, let's start with the obvious. The Debian packaging of tsclient is supposed to be the debian/ dir only. I.e. if you have a new upstream source, there is no need to patch the full source to the new version and mail that as diff. You just include the new tarball version for that release in debian/changelog and make the neccessary adjustments in debian/. Most commonly it's a good idea to add a get-orig-source target for this - or to plain use it if it's there already. ;) Second you included automake1.9 and autoconf in the Build-Deps. That generally is a *very good* indication for things that have gone utterly wrong. For a proper packaging you should not regenerate the configure during the build to keep a certain amount of reproducability. That's the reason there was a patch for that update to make the outcome rather predictable. Maintainer mode is for developers, not for packagers. ;) Moreover if you drop patches, it's always nice to know why this is no longer needed (added included upstream for that reason). Thirdly, the SVN was a bit further, so your patch didn't really apply cleanly. I have manually fixed that part. The result with some slight modifications to get the package mostly lintian clean I have put in SVN[1]. Can you verify this is the intended result so I can go and upload it? Thanks! -- Best regards, Kilian [1]: http://svn.debian.org/wsvn/pkg-gnome/packages/unstable/tsclient?op=log signature.asc Description: Digital signature
Bug#449144: tsclient: Please add RDPv5 disk mapping support (patch available)
Salut Clement, On Mon, Nov 05, 2007 at 12:44:06AM +0100, Clement Hermann (nodens) wrote: If you want to contribute to the packaging to keep tsclient in good shape in Debian, you are most welcome. I don't have much free time, but I'd be glad to help. I don't have much experience in debian packaging (I did create some packages or backports for private or corporate usage, nothing more), but if someone is willing to mentor me I could probably help on tsclient. I guess I can do that. Feel free to ask me any sort of stupid or not-so-stupid questions about it and we'll sort them out. Besides, I need it, I want it upgraded, so I guess someone has to do the job ;) I'll look into the source package and see if I can submit a patch. Great. Looking forward to hearing from you. -- Best regards, Kilian signature.asc Description: Digital signature
Bug#447452: notrace variant gives no debug output at all
Package: opal Version: 2.2.11~dfsg1-1 Severity: important As known already the notrace variant needs to die and opt/debug will remain with an interchangeable ABI. Upstream reckons this is the clean solution, so this is just a reminder. Matter of factly the notrace variant break SIP debugging in Ekiga (see https://bugs.launchpad.net/ubuntu/+source/opal/+bug/155302) so there is very few sense keeping it for the headache it's giving. -- System Information: Debian Release: 3.1 APT prefers oldstable APT policy: (990, 'oldstable') Architecture: i386 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-vserver-amd64 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401302: ekiga: Ekiga cannot find webcam
Richard, On Sat, Oct 20, 2007 at 01:09:05AM +0200, Richard Atterer wrote: On Fri, Oct 19, 2007 at 11:10:33PM +0200, Richard Atterer wrote: However, ekiga 2.0.11-2 in unstable only offers V4L, not V4L2. Ah, investigating a little more revealed that the reason was simply that I did not have libpt-1.10.10-plugins-v4l2 installed. Please consider adding a Depends, the connection from ekiga to this package is not obvious! Depends is exactly what we don't want. But I'll correct the Suggests. -- Best regards, Kilian signature.asc Description: Digital signature
Bug#446915: Allow user to build opal with iLBC codec from upstream source
Alain, On Wed, Oct 17, 2007 at 01:36:41AM +0200, Alain Kalker wrote: Kilian, On Tue, 2007-10-16 at 23:58 +0200, Kilian Krause wrote: you already are able to achive this by plain using the Debian diff.gz file with the upstream source tarball and then remove the line remove_ilbc from debian/patches/00list before running the build. Thanks, but I think (haven't tried yet) the build will then fail on the check-ilbc target, because that specifically checks for the presence of the src/codec/iLBC directory. Ofcourse removing check-ilbc from the clean target would fix that, but this adds to the number of steps that have to be taken after upgrades. right. That check-ilbc target is in fact the second step to take. But that's as good as it gets. To make it easier to do this, I was wondering if you could introduce a make variable like BUILD_DFSG (defaulting to yes) to control whether or not DFSG-free packages will be built. This could then be overridden during build, or perhaps using a value for DEB_BUILD_OPTIONS and a test. Users can then use the get-orig-source target to automate fetching the upstream source, editing the patch list for non-DFSG builds or deleting the iLBC directory for DFSG builds, then do a normal package build. This might even make the check-ilbc target redundant. Well, no. The get-orig-source reads from debian/changelog and it could be made to autosense the ~dfsg in the version there like pwlib does.. The build flag _could_ circumvent the check-ilbc step and could run a dpatch unpatch remove_ilbc after the patch target (i.e. first in autotools), but this starts becoming pretty hacky. Especially compared to this is 3 manual steps. Sure it's feasible, but OTOH is there such a large user base that want to do this on their own? Agreed I'm willing to rework the get-orig-source target for the next upload to cope with this. But that's about as good as I see a need for it. Also, packages built from full upstream source will still have the suffix -dfsg in their version strings, which could confuse users, especially during upgrades. This is a problem with all -dfsg packages at the moment, and I am considering bringing up this topic on the developers list. Actually I don't see a problem here. -- Best regards, Kilian signature.asc Description: Digital signature
Bug#440015: binutils: [mipsen] Assertion failures
Hi, On Sat, Sep 01, 2007 at 01:18:20PM +0200, Matthias Klose wrote: please could somebody prepare a test case (all needed object files, and the ld command), and add URL for this tarball to the upstream report at http://sourceware.org/bugzilla/show_bug.cgi?id=4988 the full build chroot including all libs and build dir is up at http://people.debian.org/~kilian/opal-2.2.11_chroot.tbz [~170MB] To get to the error, go to /build/opal-2.2.11~dfsg1 and run dpkg-buildpackage -us -uc -b -nc or equivalent (like debian/rules build). Hth. -- Best regards, Kilian signature.asc Description: Digital signature
Bug#446913: opal includes the file include/codec/ilbccodec.h, making it not DFSG-free
severity 446913 important tags 446913 moreinfo thanks Alain, On Tue, Oct 16, 2007 at 05:32:56PM +0200, Alain Kalker wrote: Package: opal Version: 2.2.11~dfsg1-1 Severity: grave The source tarball for opal ships the file include/codec/ilbccodec.h, Although it is not used in the build, one can argue that this file is technically part of the iLBC codec, making the package not DFSG-free. reading into that file I find * Copyright (c) 1999-2000 Equivalence Pty. Ltd. which doesn't really look like it's an original part of the iLBC codec. Which parts do you think are copied over and need to be removed? -- Best regards, Kilian signature.asc Description: Digital signature
Bug#446689: ekiga: configuration druids alwasys starts
Luca, On Sun, Oct 14, 2007 at 11:43:45PM +0200, Luca Capello wrote: Package: ekiga Version: 2.0.11-2 this happens since the last upstream upload, but as I'm not 100% sure I kept the installed version as the Version: header. Every time I start ekiga, the configuration druids pops up, even if I configure ekiga quite a long time ago and my gconf contains it: = [EMAIL PROTECTED]:~$ grep -r 'name=ekiga' ~/.gconf/ /home/luca/.gconf/%gconf-tree.xml:dir name=ekiga [EMAIL PROTECTED]:~$ = Pressing the Cancel button brings me to a working ekiga, i.e. will all my settings. actually there is a new gcon key involved. What's the current value of /apps/ekiga/general/version for your user? -- Best regards, Kilian signature.asc Description: Digital signature
Bug#446689: ekiga: configuration druids alwasys starts
Ciao Luca, On Sun, Oct 14, 2007 at 11:43:45PM +0200, Luca Capello wrote: Package: ekiga Version: 2.0.11-2 this happens since the last upstream upload, but as I'm not 100% sure I kept the installed version as the Version: header. Every time I start ekiga, the configuration druids pops up, even if I configure ekiga quite a long time ago and my gconf contains it: = [EMAIL PROTECTED]:~$ grep -r 'name=ekiga' ~/.gconf/ /home/luca/.gconf/%gconf-tree.xml:dir name=ekiga [EMAIL PROTECTED]:~$ = Pressing the Cancel button brings me to a working ekiga, i.e. will all my settings. there is a setting called SCHEMA_AGE which hasn't changed (should be 60 for all versions since 2.0.3 through 2.0.11) that indicates whether the settings are up to date with the current installation. Eventually this is overriden by a local variable of the user's gconf tree. Do you reckon that after running gconftool-2 -u /apps/ekiga/general/gconf_test_age;killall -9 gconfd-2 as user the problem still exists? -- Best regards, Kilian signature.asc Description: Digital signature
Bug#430836: patch for NMU of pygresql to proposed-updates
Hi Matthias,
as requested I have put the NMU into proposed-updates for the still open
issue (after ACK from Luk on IRC).
Just for the record, please find attached the interdiff from the
pygresql_1:3.8.1-1 version.
--
Best regards,
Kilian
diff -u pygresql-3.8.1/debian/control pygresql-3.8.1/debian/control
--- pygresql-3.8.1/debian/control
+++ pygresql-3.8.1/debian/control
@@ -8,7 +8,7 @@
Package: python-pygresql
Architecture: any
-Depends: ${python:Depends}, python-egenix-mxdatetime
+Depends: ${shlibs:Depends}, ${python:Depends}, python-egenix-mxdatetime
Conflicts: python2.3-pygresql, python2.4-pygresql
Replaces: python2.3-pygresql, python2.4-pygresql
Provides: ${python:Provides}
diff -u pygresql-3.8.1/debian/rules pygresql-3.8.1/debian/rules
--- pygresql-3.8.1/debian/rules
+++ pygresql-3.8.1/debian/rules
@@ -73,7 +73,7 @@
dh_pycentral
dh_python
dh_installdeb
- dh_shlibdeps
+ dh_shlibdeps -ldebian/python-pygresql/usr/lib/python2.4/site-packages
dh_gencontrol
dh_md5sums
dh_builddeb
diff -u pygresql-3.8.1/debian/changelog pygresql-3.8.1/debian/changelog
--- pygresql-3.8.1/debian/changelog
+++ pygresql-3.8.1/debian/changelog
@@ -1,3 +1,10 @@
+pygresql (1:3.8.1-1etch1) proposed-updates; urgency=low
+
+ * Non maintainer upload.
+ * Fix package dependency on libpq. Closes: #430836.
+
+ -- Kilian Krause [EMAIL PROTECTED] Mon, 8 Oct 2007 19:09:57 +
+
pygresql (1:3.8.1-1) unstable; urgency=low
* New upstream version.
signature.asc
Description: Digital signature
Bug#445886: closed by Kilian Krause [EMAIL PROTECTED] (PWLib 1.10.10 accepted from NEW)
Hi Ari, I am not shure what PWlib is, my problem is with ekiga referring to a wrong package name of libpt: libpt-1.10.10, while current name is libpt-1.10.0. Here is my dpkg/apt-get output: -(snip)- it's perfectly fixed. The mirror sync should be through by now holding libpt-1.10.10 available for download. The fix was thus only delayed by the fact that it only hit incoming.debian.org when I wrote that mail. -- Best regards, Kilian signature.asc Description: Digital signature
Bug#445462: /usr/lib/liblinphone.so.1: undefined symbol: payload_type_x_snow
tags 445462 confirmed severity 445462 grave thanks Hi Peter, On Sat, Oct 06, 2007 at 10:32:27AM +1000, Peter Chubb wrote: Package: liblinphone1 Version: 1.99.0-2 I did apt-get install linphone: ... Setting up libosip2-2 (3.0.3-2-1) ... Setting up libexosip2-4 (3.0.3-3-1) ... Setting up liblinphone1 (1.99.0-2) ... Setting up libortp7 (1.99.0-2) ... Setting up linphone-common (1.99.0-2) ... Setting up linphone-nox (1.99.0-2) ... Setting up linphone (1.99.0-2) ... Then $ linphone linphone: symbol lookup error: /usr/lib/liblinphone.so.1: undefined symbol: payload_type_x_snow actually it even segfaults with latest SID versions. Looks like a problem somewhere in libosip or libortp.. From a first glance a pure rebuild doesn't fix it aparently. Will need further debugging. Thanks for reporting it. -- Best regards, Kilian signature.asc Description: Digital signature
Bug#399326: GNOME-free is only for win32 crosscompile
Just for the record, the GNOME-free variant has been only introduced for win32 crosscompilation. Most of all to keep the porting requirement small (at least lower than a full GNOME base set of libs). It's breaking way too many features on a platform that does have all the required libs at no extra cost and thus for a full Linux distro it is officially recommended to not be used. In other words, for embDebian or other embedded Linux distributions it may be a viable path, but for Debian at large it's not going to happen. -- Best regards, Kilian signature.asc Description: Digital signature
Bug#440928: libopal-2.2: cannot build package
Didrik, On Wed, Sep 05, 2007 at 03:55:06PM +0200, Didrik Pinte wrote: shared debug simpleopal incorrectly compiled static make: *** [build-arch-stamp] Error 1 Any idea on the problem ? yes, it's you have libopal installed on the system. Therefore the tests fail to verify the new build correctly. It assums that it can run the library test program even without the static linking which is supposed to be wrong. This is a missing build-dep (or rather build-conflicts i'll look to with one of the next uploads.) Leaving this bug open as a reminder. -- Best regards, Kilian signature.asc Description: Digital signature
Bug#440727: [DRE-maint] Bug#440727: FTBFS on sparc in clean target
Lucs, On Tue, Sep 04, 2007 at 07:26:02AM +0200, Lucas Nussbaum wrote: On 03/09/07 at 23:59 +0200, Kilian Krause wrote: Package: libgsl-ruby Version: 1.9.2-2 Severity: serious While autobuilding your package the following error occured: fakeroot debian/rules clean test -x debian/rules test `id -u` = 0 dh_clean /usr/bin/ruby setup.rb config --siteruby=/ruby --siterubyver=/ruby/1.8 --siterubyverarch= make: *** [clean] Illegal instruction Full build log is available at: http://status.buildserver.net/fetch.php?file=logas=rawstamp=1188856623ver=1.9.2-2pkg=libgsl-rubyarch=sparc Hi Kilian, Any chance this is caused by the sparc buildd problems? I'm a bit suspicious when I read sparc and FTBFS in the same subject ;) No it's not. This is the with the fixed kernel waldi describes in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=433187 ... So the problem with processes not terminating is another one. You're free to wait for the regular buildd to come back and proove it though. ;) In the other case, it's very likely to be an interpreter bug. So it should probably be reassigned to ruby1.8. Yep, sounds good to me. -- Best regards, Kilian signature.asc Description: Digital signature
Bug#440727: [DRE-maint] Bug#440727: FTBFS on sparc in clean target
Lucas, Might this be caused by #393817 (ruby dies with Illegal instruction on sparc/Niagara) ? In other words, is your buildd a sparc/Niagara ? yes, it's the T2000 refered to in the bug. -- Best regards, Kilian signature.asc Description: Digital signature
Bug#393817: 393817 blocks 440727
severity 393817 grave thanks This one breaks the build of other packages. Thus grave due to causing FTBFS. -- Best regards, Kilian signature.asc Description: Digital signature
Bug#439976: FTBFS even worse with 1.4.2.dfsg-5
found 438792 1.4.2.dfsg-5
found 439976 1.4.2.dfsg-5
thanks
Hi Jonas,
since the 1.4.2.dfsg-5 upload the situation by far worsened. Almost all
arches now FTBFS. Only alpha and amd64 still build ok now:
See http://buildd.debian.org/build.php?pkg=srtp
or
http://status.buildserver.net/packages/status.php?package=srtpsubdist=pkg-voip
Looks like at least five sorts of bugs from the logs we got so far.
i386, m68k:
test/srtp_driver -v /dev/null
/bin/sh: line 1: 24158 Segmentation fault test/srtp_driver -v
/dev/null
make[1]: *** [runtest] Error 139
arm, powerpc, s390:
crypto/test/kernel_driver -v /dev/null
test/rdbx_driver -v /dev/null
make[1]: *** [runtest] Error 255
ia64:
test/srtp_driver -v /dev/null
/bin/sh: line 1: 22333 Illegal instruction test/srtp_driver -v
/dev/null
make[1]: *** [runtest] Error 132
hppa:
cd test; ./rtpw_test.sh /dev/null
./rtpw: couldn't open file /usr/share/dict/words
make[1]: *** [runtest] Error 255
(stalled there)
mips(el):
test/srtp_driver.c: In function 'main':
test/srtp_driver.c:156: warning: format '%ld' expects type 'long int',
but argument 2 has type 'unsigned int'
test/srtp_driver.c:317: error: expected identifier or '(' before numeric
constant
test/srtp_driver.c:326: warning: format '%e' expects type 'double', but
argument 2 has type 'int'
test/srtp_driver.c:316: warning: unused variable 'ignore'
make[1]: *** [test/srtp_driver] Error 1
--
Best regards,
Kilian
signature.asc
Description: Digital signature
Bug#440721: FTBFS on sparc while linking usr/klibc/libc.so
Package: klibc Version: 1.5.6-2 Severity: serious While building your package on sparc the following error occurs: KLIBCLD usr/klibc/libc.so ld: sparc architecture of input file `/usr/lib/gcc/sparc-linux-gnu/4.2.1/libgcc.a(_clzdi2.o)' is incompatible with sparc:v9 output ld: sparc architecture of input file `/usr/lib/gcc/sparc-linux-gnu/4.2.1/libgcc.a(_clz.o)' is incompatible with sparc:v9 output /usr/lib/gcc/sparc-linux-gnu/4.2.1/libgcc.a(_clzdi2.o): In function `__clzdi2': (.text+0xc): undefined reference to `_GLOBAL_OFFSET_TABLE_' /usr/lib/gcc/sparc-linux-gnu/4.2.1/libgcc.a(_clzdi2.o): In function `__clzdi2': (.text+0x14): undefined reference to `_GLOBAL_OFFSET_TABLE_' make[3]: *** [usr/klibc/libc.so] Error 1 make[2]: *** [all] Error 2 make[1]: *** [klibc] Error 2 make[1]: Leaving directory `/build/klibc-1.5.6' Full build log can be found at http://status.buildserver.net/fetch.php?pkg=klibcver=1.5.6-2arch=sparcstamp=1188846193file=logas=raw -- Best regards, Kilian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#440727: FTBFS on sparc in clean target
Package: libgsl-ruby Version: 1.9.2-2 Severity: serious While autobuilding your package the following error occured: fakeroot debian/rules clean test -x debian/rules test `id -u` = 0 dh_clean /usr/bin/ruby setup.rb config --siteruby=/ruby --siterubyver=/ruby/1.8 --siterubyverarch= make: *** [clean] Illegal instruction Full build log is available at: http://status.buildserver.net/fetch.php?file=logas=rawstamp=1188856623ver=1.9.2-2pkg=libgsl-rubyarch=sparc -- Best regards, Kilian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362422: fixed in 1.99.0-1 upload
package linphone tags 362422 pending thanks The 1.99.0-1 compiles just fine with gcc-4.2. It's being held in NEW for the moment. Bug can be closed once it's ACCEPTED. -- Best regards, Kilian signature.asc Description: Digital signature
Bug#440015: still broken with binutils 2.18
tags 440015 - moreinfo thanks control Retrying with binutils 2.18 instead of 2.18~cvs20070812-1 still shows the same for opal: make[1]: Leaving directory `/build/opal-2.2.8~dfsg1/samples/simple' samples/simple/obj_*_n/simpleopal --help /dev/null samples/simple/obj_linux_mips_n/simpleopal: symbol lookup error: samples/simple/obj_linux_mips_n/simpleopal: undefined symbol: _ZNK49H245_MiscellaneousCommand_type_videoFastUpdateGOB7CompareERK7PObject make: *** [build-arch-stamp] Error 127 and for openh323: make[1]: Leaving directory `/build/openh323-1.18.0.dfsg/samples/simple' samples/simple/obj_*_r/simph323 --help /dev/null samples/simple/obj_linux_mips_r/simph323: symbol lookup error: samples/simple/obj_linux_mips_r/simph323: undefined symbol: _ZNK18H245_FECCapability5CloneEv make: *** [build-arch-stamp] Error 127 -- Best regards, Kilian signature.asc Description: Digital signature
Bug#439976: FTBFS on mips in test/srtp_driver.c:315
Package: srtp
Version: 1.4.2.dfsg-4
Severity: serious
While building the package, it fails in test/srtp_driver.c:315 with:
cc -DHAVE_CONFIG_H -Icrypto/include -I./include -I./crypto/include -g
-Wall -O2 -D_REENTRANT -L. test/srtp_driver.c -o test/srtp_driver -lsrtp
test/srtp_driver.c: In function 'main':
test/srtp_driver.c:315: error: expected identifier or '(' before numeric
constant
test/srtp_driver.c:324: warning: format '%e' expects type 'double', but
argument 2 has type 'int'
test/srtp_driver.c:314: warning: unused variable 'ignore'
make[1]: *** [test/srtp_driver] Error 1
make[1]: Leaving directory `/build/srtp-1.4.2.dfsg'
make: *** [debian/stamp-makefile-build] Error 2
Full build log is available at
http://buildd.debian.org/fetch.cgi?pkg=srtpver=1.4.2.dfsg-4arch=mipsstamp=1179449202file=log
--
Best regards,
Kilian
signature.asc
Description: Digital signature
Bug#439310: fxotune tool is in the wrong path
tags 439310 pending thanks Hi GNUbie, On Fri, Aug 24, 2007 at 02:56:47PM +0800, GNUbie wrote: Package: zaptel Version: 1.4.5~dfsg-1 /etc/rc6.d/K30zaptel:FXOTUNE=/usr/sbin/fxotune # which fxotune /sbin/fxotune Thanks. Fixed in SVN. -- Best regards, Kilian signature.asc Description: Digital signature
Bug#439062: Broken Build-Depends in asterisk_1.4.11~dfsg-1
severity 439062 grave tags 439062 confirmed pending merge 439197 439062 thanks, control Hi Sheldon, On Thu, Aug 23, 2007 at 03:10:18PM +0200, Sheldon Hearn wrote: The new asterisk_1.4.11~dfsg-1 source package fails to backport in an Etch chroot because of a broken Build-Depends. The control file declares dependency on libpri-dev (= 1.4) But it requires libpri-dev (= 1.4.1) This is because 1.4.1 provides bristuffed/libpri.h, which is not provided by earlier versions. this was already reported in #439197. Thanks. -- Best regards, Kilian signature.asc Description: Digital signature
Bug#379086: now it is time to package latest version
On Fri, Aug 24, 2007 at 04:11:32PM +0200, José JORGE wrote: as stable 4 is out... Yes, OpenMCU 2.2.1 is out OpenMCU-OPAL is not yet released. Problem with OpenMCU 2.2.1 is that right now it won't build (even with CVS HEAD) due to: g++ -D_REENTRANT -Wall -I/usr/share/pwlib/include -DPTRACING -I/usr/share/openh323/include -O2 -felide-constructors -c main.cxx -o obj_linux_x86_r/main.o filemembers.h:123: error: ISO C++ forbids declaration of 'deque' with no type filemembers.h:123: error: typedef name may not be a nested-name-specifier filemembers.h:123: error: expected ';' before '' token filemembers.h:124: error: expected ',' or '...' before '' token filemembers.h:124: error: ISO C++ forbids declaration of 'FilenameList' with no type filemembers.h:149: error: 'FilenameList' does not name a type make[1]: *** [obj_linux_x86_r/main.o] Error 1 I've asked upstream how come and what's the correct version to overcome this. Thanks for reminding though! -- Best regards, Kilian signature.asc Description: Digital signature
Bug#438792: FTBFS on sparc with bus error
Package: srtp Version: 1.4.2.dfsg-4 Severity: serious While building the package, it fails during the checks with: cc -DHAVE_CONFIG_H -Icrypto/include -I./include -I./crypto/include -g -Wall -O2 -D_REENTRANT -L. tables/aes_tables.c -o tables/aes_tables libcryptomath.a Build done. Please run '/usr/bin/make runtest' to run self tests. running libsrtp test applications... crypto/test/cipher_driver -v /dev/null /bin/sh: line 1: 22019 Bus error crypto/test/cipher_driver -v /dev/null make[1]: *** [runtest] Error 138 make[1]: Leaving directory `/build/srtp-1.4.2.dfsg' make: *** [debian/stamp-makefile-check] Error 2 Full build log can be found at http://buildd.debian.org/fetch.cgi?pkg=srtpver=1.4.2.dfsg-4arch=sparcstamp=1187410521file=log -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (990, 'stable'), (500, 'oldstable'), (500, 'unstable') Architecture: sparc (sparc64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.21-2-vserver-sparc64 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435521: closed by Mark Purcell [EMAIL PROTECTED] (Re: Asterisk SIP DOS Vulnerability)
Hi Moritz, On Fri, Aug 17, 2007 at 10:53:48PM +0200, Moritz Muehlenhoff wrote: Mark Purcell wrote: On Wed, 8 Aug 2007, Lionel Elie Mamane wrote: Yes, but we should still fix that in stable, not only unstable. Yes I wasn't suggesting that we don't fix it in stable, but rather that a fix was available and had been uploaded to Debian (unstable). The BTS supports version tracking and even though the bug maybe closed, these security issues are still listed as open for asterisk in etch. Of course if we have a way of testing the fix in unstable is is valid that's even better. Of course fixing the plethora of security fixes against asterisk 1.2 is an issue and a fair amount of work. Whilst digium continues to provide supported releases of 1.2.x with bug fixes, by rights we should be only taking the diff's and applying them to debian stable via the debian security team, which is a job in itself. We are maintaining uptodate asterisk 1.2 packages built against stable (etch) via http://buildserver.net, but that is using the latest asterisk 1.2 upstream release and isn't a suitable security fix for upload to stable. (but would be a lot less work and would get the fixes into stable v.quickly) security team. This is an issue, we (pkg-voip) are aware we are well behind the curve on this, but were wondering if you have any ideas on a way to better manage? For Etch we need to bite the bullet and continue to support it (see my previous mail to Faidon), but with the current strain of vulnerabilities (19 in 2007 alone!) we can't support it for Lenny again. In some cases we need to accept notoriously error-prone packages because they are terribly important (like PHP and Linux), but we can't do that for Asterisk. Somewhat I have expected this. So it's good we're discussing this now. ;) To start, yes I feel that backporting fixes is a large burden. We can help, but with this amount of vulnerabilities it's very teadious. So working around it is surely the preferred choice. For Lenny I see three solutions: (in order of my personal preferrence) 1. Move it to volatile.debian.org and support it through builds of the current Digium maintenance release Definitively good choice. 2. Drop it from stable and support it out of the archive through builds of the current Digium maintenance release May come even a bit handier for the pkg-voip team, as that _could_ mean supporting through pkg-voip.buildserver.net (which is in fact generated with no extra work required from the developers). 3. For Lenny we'll most likely have a way to flag packages not having security support (see #436161). So, it could be included in Lenny w/o security support. There might still be use cases, e.g. a company-wide internal PBX. Well, in that case it seems to me as good as just dropping asterisk from Debian which would be an inconvenience to our users. Therefor I'd welcome options 1 or 2. As stated if you agree that 2. solves the problem, I think we can go with that. Comments? If the rest of pkg-voip developers agrees, i'll just put up a pseudo RC-bug against asterisk to make sure it's not progressing into testing anymore (and therefore not contained in stable release of Lenny and newer). -- Best regards, Kilian signature.asc Description: Digital signature
Bug#435146: confirmed with asterisk 1:1.4.10~dfsg-1, libopenh323 1.18.0.dfsg-3
Hi Mark, On Sun, Aug 12, 2007 at 10:03:58AM +0100, Mark Purcell wrote: Package: asterisk-h323 Version: 1:1.4.10~dfsg-1 Followup-For: Bug #435146 Installing the -develop versions provides some additional information. can you also install the asterisk-dbg? Thanks! -- Best regards, Kilian signature.asc Description: Digital signature
Bug#420641: asterisk-oh323 fixed with asterisk 1.4.4
Hi Michael, I've taken a CVS HEAD snapshot from the sourceforge CVS as you proposed. To clean up the compilation output I've added some fixes. Please have a look at these patches[1] and check whether you can import them back upstream. They do address the -O2 requirement of Debian and remove the cluttering with version.h not finding the version of PWLib and OpenH323. I daresay that I'm not happy with the latter patch, as the way the versions are detected feels wrong anyway, that's what configure is for or eventually some other mechanism, but not run it with each source file being compiled. Same goes for the ccflags of OpenH323. Is there any chance we can see a 0.7.4 with that code as public release soon? Thanks! -- Best regards, Kilian [1]: asterisk-driver_Makefile.dpatch - fixes -O2 http://svn.debian.org/wsvn/pkg-voip/asterisk-oh323/trunk/debian/patches/asterisk-driver_Makefile.dpatch?op=filerev=0sc=0 chan_oh323.dpatch - fixes missing headers problem http://svn.debian.org/wsvn/pkg-voip/asterisk-oh323/trunk/debian/patches/chan_oh323.dpatch?op=filerev=0sc=0 Makefile.dpatch - also fix -O2 http://svn.debian.org/wsvn/pkg-voip/asterisk-oh323/trunk/debian/patches/Makefile.dpatch?op=filerev=0sc=0 wrapper_Makefile - just run OPENH323FLAGS _once!_. - add -fPIC for the wrapper library. - leaves the very ugly .pwlib_version and .openh323_version constucts as TODO http://svn.debian.org/wsvn/pkg-voip/asterisk-oh323/trunk/debian/patches/wrapper_Makefile.dpatch?op=filerev=0sc=0 signature.asc Description: Digital signature
Bug#435146: asterisk-h323: Asterisk crashes on startup with H323 package installed.
Hi Konstantin, On Sun, Jul 29, 2007 at 07:26:20PM +0400, Konstantin Starodubtsev wrote: Package: asterisk-h323 Version: 1:1.4.9~dfsg-1 Asterisk crashes with core dump if asterisk-h323 packages installed. can you try if this still exists with installed libopenh323-1.18.0 (=1.18.0.dfsg-3)? The new version hit incoming just today, so it may take a while till it's available through the Debian mirrors. Thanks! -- Best regards, Kilian signature.asc Description: Digital signature
Bug#354072: Foreign language asterisk sounds
Lionel, On Wed, Jun 13, 2007 at 08:32:55AM +0200, Lionel Elie Mamane wrote: Hi, Is there a reason (beyond nobody did it yet) we do not ship the Digium asterisk French/Spanish sounds? there's just nobody pushing it. In particular: - Can we presume the same license as Asterisk (or the English core sounds), or do we want an explicit OK from Digium? In the latter case, has anybody contacted Digium about that? These sounds don't technically link with asterisk. So their license is what that speaker/upstream says it is. At least in my understanding, yet IANAL. - Shall we include them in the repackaged upstream tarball or as separate source packages? Seperate source makes more sense as the release cycles differ largely. - Do we want to ship all coding variants or just GSM? That's a bit tricky. We can ship everything except iLBC, as we exclude iLBC from asterisk source and therefore wouldn't be able to read it. If some upstream finds it useful to include G711, why not roll it in the package. The better quality we can supply the happier our users. I'm willing to do that task. Starting this evening (Europe time) if legal matters allow. (You may have forgotten because I am so inactive, but I have SVN commit privileges on pkg-voip.) I may also package http://public.indigen.com/asterisk-1.2-sounds-fr-armelle.tar.gz and/or http://xivo.fr/debian/prompt-fr-france-20060911.tgz, if I can contact their suppliers and confirm a free license on them. Great! Go ahead! -- Best regards, Kilian signature.asc Description: Digital signature
Bug#412427: ITP: resiprocate -- Session Initiation Protocol (SIP) stack
Neil, Package name: resiprocate This package will build a couple of binary packages, one library, and one utility (for now). I intend to work with the pkg-voip team in producing this, if they want :) (cc-ed) Yes, please. We've had some attempts already back in the past, yet none of them was completed. Please provide all the neccessary diff in a form that we can have upstream include these changes with the next release to get their package into proper shape for nice packaging. I'm sure Daniel will love to read the lib will finally be packaged. ;) -- Best regards, Kilian signature.asc Description: Digital signature
Bug#406714: asterisk-sounds-main: FHS violation: asterisk privacy mode writes in /usr/share/asterisk/sounds/priv-callerintros
Steve, On Thu, Jan 18, 2007 at 05:31:14PM -0800, Steve Langasek wrote: On Sat, Jan 13, 2007 at 11:13:09AM +0100, Lionel Elie Mamane wrote: Package: asterisk-sounds-main Version: 1.2.13~dfsg-2 Severity: serious Justification: Policy 9.1.1 The asterisk privacy mode (Dial with option P) records caller intros in /usr/share/asterisk/sounds/priv-callerintros . This violates the FHS and hence Debian policy. But does asterisk run as root (I hope not)? If not, then surely no intros can be written to this directory, so policy isn't actually being violated -- it's just a feature that's unavailable to users of the package? It's not running as root by the default init script. A user can run it as root if manually running it without -U parameter. Right, the asterisk_fix won't reset the permissions on that dir to be owned by asterisk, thus for a default install that feature is plain broken. It may be fixed by the user by manually resetting permissions, though. If there is a reason this bug needs to be treated as an RC FHS violation, then an upload to testing-proposed-updates will be needed, because unstable has a new upstream version of asterisk. Sounds sane to me. Backporting the fix from sid only should be a very minimal change. Shall I prepare an upload to t-p-u? -- Best regards, Kilian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406961: closed by Kilian Krause [EMAIL PROTECTED] (Bug#406961: fixed in asterisk 1:1.2.14~dfsg-4)
Jeroen,
On Mon, Jan 15, 2007 at 02:28:00PM +, Jeroen Massar wrote:
Debian Bug Tracking System wrote:
It has been closed by Kilian Krause [EMAIL PROTECTED].
Thanks Kilian for the very quick fixup!
No problems. Speaking of 1.4 packs, they are prepared in pkg-voip SVN
and we'll have snapshots not too long from now via
pkg-voip.buildserver.net... I still need to setup experimental buildd
configs, but the sources are available already in the
${dist}-experimental trees. You'll need to use $dist and
${dist}-experimental for sources.list. I'll add some more verbose
explanations to the buildserver.net frontpage and announce it on
pkg-voip-maintainers. Stay tuned for news.
--
Best regards,
Kilian
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406064: asterisk-classic: asterisk crashed on dialing in or out with chan-capi,
Benoit, Hello when using asterisk on etch, i got crash with segmentation fault each time a make a call ore receive a call. The software used are this one. asterisk-classic-1.2.13-dfsg-2 and not packaged yet 1.2.14 from pkg-voip svn chan-capi 0.7.1 latest melware driver for my divaserver 4bri card rev 2 The only version that work is 1.2.12-1 for now. I've just triggered a rebuild on pkg-voip which will yield a version 0.7.1-2~$dist.2612+b1 where $dist is whatever you selected from the archive (pkg-voip.buildserver.net). Can you try with this version if that rebuild fixes your problem already? The packs should be available on the public webspace from about 16:20 on. Thanks! -- Best regards, Kilian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405707: duplicate entry prevents entire logrotate operation
Louis-David,
On Sat, Jan 06, 2007 at 11:01:02PM +0100, Louis-David Mitterrand wrote:
On Sat, Jan 06, 2007 at 10:50:33PM +0100, Kilian Krause wrote:
Louis-David,
On Fri, Jan 05, 2007 at 06:54:50PM +0100, Louis-David Mitterrand wrote:
Package: asterisk
Version: 1:1.2.14~dfsg-1
Severity: important
asterisk and asterisk-{classic,bristuff} have conflicting
/etc/logrotate.d entries that prevents logrotate operation on _all_
other logs:
/etc/cron.daily/logrotate:
error: asterisk-classic:1 duplicate log entry for
/var/log/asterisk/debug
They have much more conflicting than just logroate files. Guess why
these packages have an unversioned conflicts set to one another? How you
expect your configuration to be sane if you force dpkg to break it?
I am talking about ( asterisk AND asterisk-classic ) OR ( asterisk AND
asterisk-bristuff). Please check before infering stuff. (Like I really
have the time to break dependencies in purpose, yeah right)
Ok, agreed. asterisk and asterisk-classic can be installed alongside.
Yet with the version you reported the bug against, where do you get the
logrotate from? It's not being shipped since 1:1.2.9.1.dfsg-1 in
anything but the asterisk package.
--
Best regards,
Kilian
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405707: duplicate entry prevents entire logrotate operation
Louis-David,
On Sat, Jan 06, 2007 at 11:16:02PM +0100, Louis-David Mitterrand wrote:
On Sat, Jan 06, 2007 at 11:01:02PM +0100, Louis-David Mitterrand wrote:
On Sat, Jan 06, 2007 at 10:50:33PM +0100, Kilian Krause wrote:
Louis-David,
On Fri, Jan 05, 2007 at 06:54:50PM +0100, Louis-David Mitterrand wrote:
Package: asterisk
Version: 1:1.2.14~dfsg-1
Severity: important
asterisk and asterisk-{classic,bristuff} have conflicting
/etc/logrotate.d entries that prevents logrotate operation on _all_
other logs:
/etc/cron.daily/logrotate:
error: asterisk-classic:1 duplicate log entry for
/var/log/asterisk/debug
They have much more conflicting than just logroate files. Guess why
these packages have an unversioned conflicts set to one another? How you
expect your configuration to be sane if you force dpkg to break it?
I am talking about ( asterisk AND asterisk-classic ) OR ( asterisk AND
asterisk-bristuff). Please check before infering stuff. (Like I really
have the time to break dependencies in purpose, yeah right)
OK, news on that: I don't know how I ended up having both
/etc/logrotate.d/asterisk
and
/etc/logrotate.d/asterisk-classic
on my system and both files belonging respectively to their namesake
package (checked with dpkg -L pack), but after purging both and
reinstalling only
/etc/logrotate.d/asterisk
is back.
Nope. Intended and correct. ;)
--
Best regards,
Kilian
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#381092: Authentication does not work in certain circumstances
Hi Aleksey, according to upstream (Jan Willamowius) this bug is resolved in the 2.2.5 release, yet only with code from the latest development release of OpenH323. The patch you provided - according to him - does not fully solve the issue and was therefore not included into the new Debian packs of 2.2.5. Ultimately this bug will be fixed with the next generation of OpenH323 - for which I right now don't have any ETA from upstream. Right now we're pretty happy the stable release is running nicely without issues and compiles everywhere to make a fine Etch package. OTOH, I've discussed with Jan whether it's possible to backport these fixes into the latest stable OpenH323 or to transcribe the code in gnugk. He reckons that this is not trivial and therefore he cannot give a helping hand. If you require this fix, I guess you can use the openh323-cvs packages off snapshots.ekiga.net and rebuild gnugk yourself for the time being. That way you'll have the new code and the problem should no longer occur. -- Best regards, Kilian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395249: System close button and Call-Close do not close ekiga
Eugen, Am Mittwoch, den 25.10.2006, 22:28 +0200 schrieb Eugen Dedu: I start ekiga. Call-Quit closes ekiga, but Call-Close and the System close button do not (the window disappears, but the application is still running: the shell prompt does not return and ps ux show ekiga running). do you reckon that you have an icon tray running and that the Ekiga icon is being shown there? In that case this is intended behaviour. If you got no tray running however, this should not occur in the described way. -- Best regards, Kilian signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Bug#395831: ekiga: spelling errors
Matt, Am Freitag, den 27.10.2006, 18:07 -0700 schrieb Matt Taggart: I spotted some spelling errors in manpages, /usr/share/man/man1/ekiga.1.gz traditionnal - traditional fomerly - formerly neccessary - necessary thanks. This has been fixed upstream and will be included in the next release. -- Best regards, Kilian signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Bug#375279: Ekiga: no audio plugins are detected
Carles, Am Samstag, den 24.06.2006, 23:55 +0200 schrieb Carles Pina i Estany: The error was Cannot find any audio plugin (aprox.) Fixed with solution from here: http://mail.gnome.org/archives/gnomemeeting-list/2006-June/msg00093.html apt-get install libpt-plugins-alsa point is and was what would be the default sound system in the stable Debian release. In the old days of Sarge as testing, this was OSS. I'm not entirely sure whether or not ALSA will be default for Etch or Etch +1. If the default still is OSS, then choosing ALSA also requires you to switch the PWLib plugin (that's why it's recommended) to make things work. If the default however will be ALSA, then we'll switch this with the next upload. -- Best regards, Kilian signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Bug#347827: mips building fine, but excluded in Architecture
Maks, can you please test against latest klibc 1.3.16, has seen lots of changes since and also some mips fixes. so i'd be curious to hear how it works out? just came round to try with klibc=1.4.29-1 and it still looks the same: (sid)[EMAIL PROTECTED]:~# strace /usr/lib/klibc/bin/uname -a execve(/usr/lib/klibc/bin/uname, [/usr/lib/klibc/bin/uname, -a], [/* 13 vars */]) = -1 EFAULT (Bad address) --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ Process 311 detached -- Best regards, Kilian signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Bug#379086: Please package OpenMCU 2.2.0
Lucas, On Fri, Jul 21, 2006 at 08:51:10AM +0200, Lucas Nussbaum wrote: Package: openmcu Severity: wishlist OpenMCU 2.2.0 is available according to http://www.voxgratia.org/modules/news/article.php?storyid=150 Do you plan to package it so that it is included in etch ? right now there is no intend to do this, as it's said to not work with the stable versions of the libs. Therefore this needs to wait till the stable version is bumped to the next generation or upstream tells me that it'd be sensible to package that new version with stable release libs. -- Best regards, Kilian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386052: works for me
Hi guys, well, for me it works just nicely with NT mode and 2.6.17-2-vserver-k7 ... I'll forward this to upstream, eventually he'll have an idea how to look more into this. -- Best regards, Kilian signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Bug#375056: ekiga lacks ipv6 support
Hi Bruno, Am Freitag, den 23.06.2006, 02:08 +0200 schrieb Bruno Kleinert: Package: ekiga Version: 2.0.2-1 Severity: wishlist ekiga doesn't listen on ipv6 ip addresses for incoming connections. i checked ekiga's configuration dialogs if there's a switch which enables ipv6 support and also looked for hidden settings by the gconf-editor, but i wasn't able to find any switch to enable ipv6 support. in contrast, gnomemeeting is listening on ipv6 addresses by default. maybe ipv6 support is disabled at compile time? nope, this is still on the TODO upstream. Newer pwlib version should have support, yet this is untested and not yet implemented in neither the UI of Ekiga nor in the backend calls. It's however requested already and will eventually be added with one of the next releases. -- Best regards, Kilian signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
