Bug#746707: refuses to use tel URIs
On 02/05/14 20:58, Josselin Mouette wrote: Le vendredi 02 mai 2014 à 20:33 +0200, Daniel Pocock a écrit : Did this change with wheezy or with squeeze? This changed between squeeze and wheezy. Still doesn't work for iceweasel or icedove though I created a desktop entry sipdialer.desktop and I edited .local/share/applications/mimeapps.list adding: [Added Associations] ... ... x-scheme-handler/tel=sipdialer.desktop; Now, if I click the tel: URI in a web page or in the icedove address book (using xul-ext-tbdialout) the Launch Application popup appears - and there is no default option for me to choose. I would expect to see the sipdialer option in the popup. Instead, it just has a Choose button that opens a filesystem browser. I can successfully launch the URI from the command line using commands like these: gvfs-open tel:+442071234567 xdg-open tel:+442071234567 and it also works from Chromium now. Just not from iceweasel or icedove. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746707: refuses to use tel URIs
On 02/05/14 22:27, Daniel Pocock wrote: On 02/05/14 20:58, Josselin Mouette wrote: Le vendredi 02 mai 2014 à 20:33 +0200, Daniel Pocock a écrit : Did this change with wheezy or with squeeze? This changed between squeeze and wheezy. Still doesn't work for iceweasel or icedove though I created a desktop entry sipdialer.desktop and I edited .local/share/applications/mimeapps.list adding: [Added Associations] ... ... x-scheme-handler/tel=sipdialer.desktop; Now, if I click the tel: URI in a web page or in the icedove address book (using xul-ext-tbdialout) the Launch Application popup appears - and there is no default option for me to choose. I would expect to see the sipdialer option in the popup. Instead, it just has a Choose button that opens a filesystem browser. I can successfully launch the URI from the command line using commands like these: gvfs-open tel:+442071234567 xdg-open tel:+442071234567 and it also works from Chromium now. Just not from iceweasel or icedove. The final comments in this issue also appear very similar: https://bugzilla.mozilla.org/show_bug.cgi?id=748643 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746707: another example
Another user having the same problem, only with Mozilla apps, with x-scheme-handler: https://bbs.archlinux.org/viewtopic.php?id=174245 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746725: add a desktop file for sipdialer
Package: sipdialer Severity: important Version: 1.9.6-1 Add a desktop file declaring sipdialer as a handler for x-scheme-handler/tel Note that this works from Chromium, Epiphany and xdg-open on the command line but it is problematic from iceweasel/icedove/Firefox: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746707 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746707: reassigning this bug
This seems OK from Epiphany now but I'm not sure if the remaining issues are just Mozilla bugs or some deeper problem with this whole change to .desktop files. Can you suggest where I should follow up on this and/or reassign this bug? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740911: re-opened with patch
I've re-opened the bug now that there is a patch for wheezy users Given the risk of data loss when this bug and the DAViCal bug are both present in a given wheezy environment, I think this patch is very desirable for a 3.4.4-4 update to wheezy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740911: backporting the fix
On 28/04/14 07:53, Milan Crha wrote: On Sun, 2014-04-27 at 22:03 +0200, Daniel Pocock wrote: Please find the revised version enclosed - I believe this is good for the 3.4 branch in upstream evolution-data-server too: Hi, I'm sorry, but 3.4 is dead for upstream currently, we are more than 3 years ahead from it right now. The current stable Debian release will still be supported for at least another 18 months from now Many users are quite happy to just take little fixes like this rather than upgrading their whole system every 6 months. Even if there are no other fixes you plan to backport, could you consider making a 3.4.5 tag just with this fix? Personally, I'm more interested in things like making click-to-dial work (see my sipdialer package for example) - it almost works from icedove now and I would appreciate feedback about how to get it working from Evolution too. I've no idea what this is about, could you be more specific, preferably with a bug report against evolution in GNOME's bugzilla, please? What I'm referring to is a) the user clicks some phone number or SIP address on the screen (e.g. in the address book) b) their preferred deskphone or softphone starts calling the number or address https://bugzilla.gnome.org/enter_bug.cgi?product=evolution CC me on the bug, it'll take my attention to it. There are important details how exactly this works. if it's like opening a URL of some kind sip://some-phone-number, by clicking the phone number in a contact preview, then it should be pretty easy to implement. It is not quite so easy though - the URL handling is usually not hard, the question is how do we route the event to the right phone. I'll put more details in a separate bug. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740911: backporting the fix
On 26/04/14 12:57, Andreas Henriksson wrote:
Hello Daniel!
On Sat, Apr 26, 2014 at 12:34:08PM +0200, Daniel Pocock wrote:
Hi Andreas,
Thanks for the feedback about this
Can you just clarify about backporting the fix - do you mean backporting
the whole version from testing to wheezy-backports or just copying the
individual patch into a rebuild of the version currently in stable?
I think backporting only the fix should (hopefully) be easier (unless
the commit is entangled with lots of other changes happening between
3.4 and 3.8).
The patch did not apply cleanly on 3.4.4
I've manually adapted the patch and tested it with 3.4.4-3 from Debian
Please find the revised version enclosed - I believe this is good for
the 3.4 branch in upstream evolution-data-server too:
git checkout gnome-3-4
git cherry-pick 198bceaf20df82764c36ad6787bd828705dc31c5
- merge conflict appears, resolve it by using my patch and then commit
Maybe both can be done, but jordi says that backporting the entire
evolution is not fun.
It is probably more than what I need anyway - I'm happy to keep running
3.4.x as long as this issue is fixed
Personally, I'm not going to work on either though... someone else
will need to take on the task that motivates them.
So we can go either way or both ways.
If you're interested in working on evolution, please contact jordi.
I'm very busy with my own packages, but I need this to work, so I've
adapted the patch for 3.4.4 and I hope you will push it out as part of
an update to stable. Just put it in the debian/patches directory and
update debian/patches/series
Personally, I'm more interested in things like making click-to-dial work
(see my sipdialer package for example) - it almost works from icedove
now and I would appreciate feedback about how to get it working from
Evolution too.
Regards,
Daniel
--- ../e-book-backend-webdav.c.orig 2014-04-27 20:46:28.031504658 +0200
+++ ./addressbook/backends/webdav/e-book-backend-webdav.c 2014-04-27 21:28:44.912193111 +0200
@@ -22,7 +22,7 @@
/*
* Implementation notes:
* We use the DavResource URIs as UID in the evolution contact
- * ETags are saved in the E_CONTACT_REV field so we know which cached contacts
+ * ETags are saved in the WEBDAV_CONTACT_ETAG field so we know which cached contacts
* are outdated.
*/
#include config.h
@@ -62,6 +62,9 @@
#define USERAGENT Evolution/ VERSION
#define WEBDAV_CLOSURE_NAME EBookBackendWebdav.BookView::closure
#define WEBDAV_CTAG_KEY WEBDAV_CTAG
+#define WEBDAV_CACHE_VERSION_KEY WEBDAV_CACHE_VERSION
+#define WEBDAV_CACHE_VERSION 1
+#define WEBDAV_CONTACT_ETAG X-EVOLUTION-WEBDAV-ETAG
G_DEFINE_TYPE (EBookBackendWebdav, e_book_backend_webdav, E_TYPE_BOOK_BACKEND)
@@ -109,6 +112,47 @@
}
static void
+webdav_contact_set_etag (EContact *contact,
+ const gchar *etag)
+{
+ EVCardAttribute *attr;
+
+ g_return_if_fail (E_IS_CONTACT (contact));
+
+ attr = e_vcard_get_attribute (E_VCARD (contact), WEBDAV_CONTACT_ETAG);
+
+ if (attr) {
+ e_vcard_attribute_remove_values (attr);
+ if (etag) {
+ e_vcard_attribute_add_value (attr, etag);
+ } else {
+ e_vcard_remove_attribute (E_VCARD (contact), attr);
+ }
+ } else if (etag) {
+ e_vcard_append_attribute_with_value (
+ E_VCARD (contact),
+ e_vcard_attribute_new (NULL, WEBDAV_CONTACT_ETAG),
+ etag);
+ }
+}
+
+static gchar *
+webdav_contact_get_etag (EContact *contact)
+{
+ EVCardAttribute *attr;
+ GList *v = NULL;
+
+ g_return_val_if_fail (E_IS_CONTACT (contact), NULL);
+
+ attr = e_vcard_get_attribute (E_VCARD (contact), WEBDAV_CONTACT_ETAG);
+
+ if (attr)
+ v = e_vcard_attribute_get_values (attr);
+
+ return ((v v-data) ? g_strstrip (g_strdup (v-data)) : NULL);
+}
+
+static void
closure_destroy (WebdavBackendSearchClosure *closure)
{
e_flag_free (closure-running);
@@ -178,9 +222,9 @@
return NULL;
}
- /* the etag is remembered in the revision field */
+ /* the etag is remembered in the WEBDAV_CONTACT_ETAG field */
if (etag != NULL) {
- e_contact_set (contact, E_CONTACT_REV, (gconstpointer) etag);
+ webdav_contact_set_etag (contact, etag);
}
g_object_unref (message);
@@ -225,7 +269,7 @@
* we can leave it out */
if (!avoid_ifmatch) {
/* only override if etag is still the same on the server */
- etag = e_contact_get (contact, E_CONTACT_REV);
+ etag = webdav_contact_get_etag (contact);
if (etag == NULL) {
soup_message_headers_append (message-request_headers,
If-None-Match, *);
@@ -234,10 +278,14 @@
} else {
soup_message_headers_append (message-request_headers,
If-Match, etag);
- g_free (etag);
}
+
+ g_free (etag);
}
+ /* Remove the stored ETag, before saving to the server */
+ webdav_contact_set_etag (contact, NULL);
+
request = e_vcard_to_string (E_VCARD (contact), EVC_FORMAT_VCARD_30);
soup_message_set_request(message, text/vcard, SOUP_MEMORY_TEMPORARY,
request, strlen (request));
@@ -247,8 +295,8 @@
redir_uri
Bug#740911: backporting the fix
Hi Andreas, Thanks for the feedback about this Can you just clarify about backporting the fix - do you mean backporting the whole version from testing to wheezy-backports or just copying the individual patch into a rebuild of the version currently in stable? Regards, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745798: privacy violation/ban emails reveal re-written addresses
Package: amavis-new Version: 1:2.7.1-2 Severity: serious When an email is banned due to an attachment, the ban email sent to the sender includes the ultimate recipient's address resolved by the virtual lookup table This appears to be a privacy risk, as the virtual mapping contains email addresses that may not already be known to the sender. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745800: can't stop banned notifications
Package: amavisd-new Version: 1:2.7.1-2 Severity: important I get far too many emails such as: BANNED contents (application/x-msdos-program,.dat,test1.exe) in mail FROM ... The default configuration sends a copy of all these to postmaster I found this email: http://permalink.gmane.org/gmane.mail.virus.amavis.user/37395 which suggests adding $banned_admin = undef; to the configuration. I tried adding that immediately under $virus_admin and it didn't help (I did restart amavisd too). It seems that all banned emails are treated the same as virus/quarantine emails, even if the messages says No virus found, so as a workaround I set $virus_admin = undef; and then I don't get the notifications at all - but this is not desirable either, as they end up in the quarantine directory wasting disk space. Given the amount of rubbish email these days, it would be better if the default configuration was able to simply bounce everything to sender (where sender address is legitimate) and drop everything else without wasting the postmaster's time. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740554: mangles classpath in upstream manifest
On 05/03/14 13:57, Emmanuel Bourg wrote: Le 04/03/2014 07:48, Daniel Pocock a écrit : When I search for Debian Java mvn packaging, Google had referred me to this wiki: https://wiki.debian.org/Java/MavenRepoHelper which suggested using libplexus-io-java as an example. That is using maven-ant-helper Good point, the wiki is confusing. libplexus-io-java is an example showing how to use maven-repo-helper, but it shouldn't lead to use maven-ant-helper. jsch is a better example for projects without a Maven build. So it looks like a) the page I should have looked at is https://wiki.debian.org/Java/MavenBuilder b) that page talks about maven-debian-helper c) however, it is using cdbs in the examples (whereas I'm trying to use dh) d) jsch seems to be using cdbs and maven-repo-helper I have a couple more packages I want to make this week, using maven-debian-helper + dh - could you point out any example of a package I should refer to? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740554: mangles classpath in upstream manifest
On 23/04/14 16:51, Emmanuel Bourg wrote: Le 23/04/2014 16:34, Daniel Pocock a écrit : I have a couple more packages I want to make this week, using maven-debian-helper + dh - could you point out any example of a package I should refer to? maven-debian-helper isn't as well integrated with DH as it is with CDBS, I strongly recommend using CDBS if you want to package a simple Maven based project. jsch is an Ant based project. The package uses maven-repo-helper to deploy the Maven artifacts in /usr/share/maven-repo. Ok, I'll go with CDBS for now Can you suggest a good example of CDBS + maven-debian-helper for a Maven project that produces multiple JARs? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745640: ITP: hazelcast - distributed cache
Package: wnpp
Severity: wishlist
Owner: Daniel Pocock dan...@pocock.pro
X-Debbugs-CC: debian-j...@lists.debian.org,debian-de...@lists.debian.org
(Would appreciate feedback from other Java users)
Brief: Hazelcast claims to be quite simple and powerful at the same
time. Well documented. Not using millions of dependencies from Maven,
all but two are already packaged.
Upstream:
http://www.hazelcast.org
Source:
https://github.com/hazelcast/hazelcast
License:
Apache 2 License
Hazelcast is a clustering and highly scalable data distribution platform
for Java.
With its various distributed data structures, distributed caching
capabilities, elastic nature, memcache support, integration with Spring
and Hibernate and more importantly with so many happy users, Hazelcast
is feature-rich, enterprise-ready and developer-friendly in-memory data
grid solution.
Features:
Distributed implementations of java.util.{Queue, Set, List, Map}
Distributed implementation of java.util.concurrency.locks.Lock
Distributed implementation of java.util.concurrent.ExecutorService
Distributed MultiMap for one-to-many relationships
Distributed Topic for publish/subscribe messaging
Synchronous (write-through) and asynchronous (write-behind) persistence
Transaction support
Socket level encryption support for secure clusters
Second level cache provider for Hibernate
Monitoring and management of the cluster via JMX
Dynamic HTTP session clustering
Support for cluster info and membership events
Dynamic discovery, scaling, partitioning with backups and fail-over
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745475: broken auto-removal logic
Package: release.debian.org
Severity: serious
This autoremoval appears to be incorrect - the dependency on nagios3 can
also be satisfied by icinga
This dependency was changed in the most recent upload
On 22/04/14 06:39, Debian testing autoremoval watch wrote:
ganglia-nagios-bridge 1.1.0-2 is marked for autoremoval from testing on
2014-05-10
It (build-)depends on packages with these RC bugs:
737441: nagios3: [src:nagios3] Sourceless file (minified) (jquery)
http://anonscm.debian.org/gitweb/?p=pkg-monitoring/ganglia-nagios-bridge.git;a=blob;f=debian/control;h=bdaf436511e7f0897fb812249a94d65c2b748448;hb=HEAD
Depends: ${misc:Depends}, python, nagios3 | icinga
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744185: refuses to run: ValueError: bad marshal data (string ref out of range)
Package: ubuntu-dev-tools Version: 0.143 I was seeing this error when trying to run syncpackage: $ syncpackage -d sid -r trusty-proposed resiprocate Traceback (most recent call last): File /usr/bin/syncpackage, line 37, in module from ubuntutools.archive import (DebianSourcePackage, UbuntuSourcePackage, File /usr/lib/python2.7/dist-packages/ubuntutools/archive.py, line 34, in module import urllib2 File /usr/lib/python2.7/urllib2.py, line 94, in module import httplib File /usr/lib/python2.7/httplib.py, line 79, in module import mimetools File /usr/lib/python2.7/mimetools.py, line 11, in module import rfc822 ValueError: bad marshal data (string ref out of range) I refreshed my Python install with this command: # apt-get install --reinstall python2.7 and then syncpackage was working again. Google also reveals other people have had this problem with import httplib: https://groups.google.com/forum/#!topic/weewx-user/u7RdWzgwETo so maybe it needs further analysis. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744185: refuses to run: ValueError: bad marshal data (string ref out of range)
On 11/04/14 09:57, Stefano Rivera wrote: Hi Daniel (2014.04.11_09:33:41_+0200) File /usr/lib/python2.7/mimetools.py, line 11, in module import rfc822 ValueError: bad marshal data (string ref out of range) Looks like a broken .pyc file. Try python -c 'import rfc822' as root? I have already fixed it using apt-get install --reinstall python2.7 How can the pyc file be broken though? While syncpackage is just a development tool, there are many administration tools and even server processes written in Python these days and they can't just intermittently break like this. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744185: refuses to run: ValueError: bad marshal data (string ref out of range)
On 11/04/14 12:09, Stefano Rivera wrote: Control: reassign -1 python2.7 Hi Daniel (2014.04.11_10:02:21_+0200) How can the pyc file be broken though? I think this has been fixed in python2.7 2.7.5-5. I'm guessing from the ubuntu-dev-tools version that you're using wheezy, which doesn't have the patch. While syncpackage is just a development tool, there are many administration tools and even server processes written in Python these days and they can't just intermittently break like this. Right. Not an ubuntu-dev-tools bug. Agreed - but I thought it would be the better place to file the bug report in case other people come across it while running syncpackage, now it will hopefully appear in the search results -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744109: investigate use of tinyxml in sipxtapi
Package: sipxtapi Version: 3.3.0~test16 The sipxtapi source includes a copy of tinyxml This is not really used and triggers the embedded-library lintian error Can it be moved to the upstream contrib section so it is not in the main source tarball at all? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735769: Drupal7 - minified JavaScript
Hi Gunnar, I just saw your comment on this bug from February 18 Personally, I don't think it is enough to say that a package is not using some artifacts from the source tarball - while it is a technically valid argument, it would make it far more difficult for FTP masters to inspect source packages and badness could start to creep in as a consequence of any generosity they show in this area. Repackaging upstream tarballs is becoming a common problem with minified JavaScript, maybe we need to have some automated way of doing this. For upstreams who use git and who release the exact contents of their tags (without any autotools bootstrapping, etc), it should be fairly easy to create some system on alioth that mirrors all the upstreams and pro-actively generates +dfsg versions of their tags ready for maintainers to work with. Regards, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735769: Drupal7 - minified JavaScript
On 10/04/14 14:51, Gunnar Wolf wrote: Daniel Pocock dijo [Thu, Apr 10, 2014 at 12:40:27PM +0200]: Hi Gunnar, I just saw your comment on this bug from February 18 Personally, I don't think it is enough to say that a package is not using some artifacts from the source tarball - while it is a technically valid argument, it would make it far more difficult for FTP masters to inspect source packages and badness could start to creep in as a consequence of any generosity they show in this area. Repackaging upstream tarballs is becoming a common problem with minified JavaScript, maybe we need to have some automated way of doing this. For upstreams who use git and who release the exact contents of their tags (without any autotools bootstrapping, etc), it should be fairly easy to create some system on alioth that mirrors all the upstreams and pro-actively generates +dfsg versions of their tags ready for maintainers to work with. Right. This bug was opened before the relevant discussion in d-devel, and I am also convinced the minified js should be removed from the source tarball. I have not had time to look into this, and any help you can give will be appreciated; a simple (or as simple as possible, at least) repack.sh script should do. Automating this sounds interesting, but I cannot do more than just say it sounds interesting right now :( This automated repacking idea has significant overlap with one of the GSoC projects: https://wiki.debian.org/SummerOfCode2014/StudentApplications#Recursively_building_Java_dependencies_from_source Whether the embedded artifacts are called *.jar or *.min.js, the same script could probably help -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737441: Nagios / jQuery / easily fixed?
This bug is one of the easier ones to fix It appears the embedded jQuery version is 1.7.1 The packaged jQuery version on Debian is currently 1.7.2: http://packages.qa.debian.org/jquery so it is simply necessary to make a repackaged tarball without the offending files and symlink to the files provided by the libjs-jquery.deb package -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743752: ck: FTBFS on armel: selected processor does not support ARM mode
As noted on the other FTBFS bug (for i386), I might simply try uploading a newer version of ck I just have to verify that the newer version will be OK with Ganglia upstream -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743751: ck: FTBFS on i386: bytelock check fails
Ganglia builds are currently using v0.3.5 of CK This version is troublesome in the i386 and ARM builds on Debian buildd machine. This impacts the availability of the CK dependency on both Debian and Ubuntu. Newer versions exist - has anybody tested a newer CK version with Ganglia? Is there any enthusiasm for using a newer version or any known reason not to do so? The travis build is hardcoded to ck-0.3.5 but I will shortly tweak it to follow whatever version is available in Debian sid On 06/04/14 02:42, Aaron M. Ucko wrote: Source: ck Version: 0.3.5-1 Severity: important Justification: fails to build from source The i386 build of ck failed the bytelock check: https://buildd.debian.org/status/fetch.php?pkg=ckarch=i386ver=0.3.5-1stamp=1396650656 [ Testing bytelock make[3]: Entering directory `/«PKGBUILDDIR»/regressions/ck_bytelock/validate' ./validate 8 1 Creating threads (mutual exclusion)...done Waiting for threads to finish correctness regression...ERROR [RD:110]: 8 != 0 make[3]: *** [check] Error 1 make[3]: Leaving directory `/«PKGBUILDDIR»/regressions/ck_bytelock/validate' FWIW, the kfreebsd-i386 build had no such problem; however, it ran the test with a different first argument (CPU core count?): https://buildd.debian.org/status/fetch.php?pkg=ckarch=kfreebsd-i386ver=0.3.5-1stamp=1396650149 [ Testing bytelock make[3]: Entering directory `/«PKGBUILDDIR»/regressions/ck_bytelock/validate' ./validate 2 1 Creating threads (mutual exclusion)...done Waiting for threads to finish correctness regression...done (passed) make[3]: Leaving directory `/«PKGBUILDDIR»/regressions/ck_bytelock/validate' Could you please take a look? Thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742996: wiki created
There is now a wiki for evaluating the dependencies and build tools: https://wiki.debian.org/PostBooks/WebPackaging -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743380: FTBFS wheezy - libusb version
Package: heimdall-flash Version: 1.4.0-1 Works with libusb version 2:1.0.17-1~bpo70+1 from wheezy-backports With 1.0.11 on wheezy it fails with the errors below g++ -DHAVE_CONFIG_H -I. -I/usr/include/libusb-1.0 -std=c++0x -I../libpit/Source -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -c -o source/BridgeManager.o source/BridgeManager.cpp source/BridgeManager.cpp: In member function ‘bool Heimdall::BridgeManager::DetectDevice()’: source/BridgeManager.cpp:503:36: error: ‘LIBUSB_LOG_LEVEL_NONE’ was not declared in this scope source/BridgeManager.cpp:507:36: error: ‘LIBUSB_LOG_LEVEL_ERROR’ was not declared in this scope source/BridgeManager.cpp:511:36: error: ‘LIBUSB_LOG_LEVEL_WARNING’ was not declared in this scope source/BridgeManager.cpp:515:36: error: ‘LIBUSB_LOG_LEVEL_INFO’ was not declared in this scope source/BridgeManager.cpp:519:36: error: ‘LIBUSB_LOG_LEVEL_DEBUG’ was not declared in this scope source/BridgeManager.cpp: In member function ‘int Heimdall::BridgeManager::Initialise(bool)’: source/BridgeManager.cpp:568:36: error: ‘LIBUSB_LOG_LEVEL_NONE’ was not declared in this scope source/BridgeManager.cpp:572:36: error: ‘LIBUSB_LOG_LEVEL_ERROR’ was not declared in this scope source/BridgeManager.cpp:576:36: error: ‘LIBUSB_LOG_LEVEL_WARNING’ was not declared in this scope source/BridgeManager.cpp:580:36: error: ‘LIBUSB_LOG_LEVEL_INFO’ was not declared in this scope source/BridgeManager.cpp:584:36: error: ‘LIBUSB_LOG_LEVEL_DEBUG’ was not declared in this scope -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743381: replaces legacy heimdall package?
Package: heimdall-flash Version: 1.4.0-1 There is a non-official heimdall Debian package that some people may have built from source Should this package include Replaces: heimdall or maybe conflicts with it? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743380: FTBFS wheezy - libusb version
On 02/04/14 18:30, Steve Langasek wrote: On Wed, Apr 02, 2014 at 06:04:55PM +0200, Daniel Pocock wrote: And why in the world are you reporting this as a bug in Debian? The 1.4.0-1 package is not in wheezy. Packages failing to build in releases they're not part of is not a bug. It is useful information for anybody making a backport The Debian BTS is not the place for such information. I appreciate you providing this package and I certainly don't want to tell you how to manage your own packages or bugs However, most of my own packages are backported because production use is usually on the stable release, so personally I do welcome such bug reports (or patches) Despite the familiar acronym in the title, this particular bug was submitted with the default severity (not RC) because I'm well aware it is not something obligatory to fix -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742943: check_raid: wants mpt-statusd / mptctl
Package: nagios-plugins-contrib Version: 4.20120702 I'm using check_raid for an md RAID (managed by mdadm) However, I get errors if mptctl is not loaded: # /usr/lib/nagios/plugins/check_raid open /dev/mptctl: No such file or directory Try: mknod /dev/mptctl c 10 220 Make sure mptctl is loaded into the kernel OK: md:[md0(raid1):UU] The errors are on stderr, regular status info is on stdout Loading mptctl manually makes the errors go away: # modprobe mptctl but it would be nice if I didn't have to make any workaround like this. If I don't have the mpt-statusd package on my system at all, check_raid gives spurious warnings: # /usr/lib/nagios/plugins/check_raid OK: md:[md0(raid1):UU]mpt:mpt-status program not found Apart from this spurious output, it does actually work correctly for my md RAID and correctly detected a disk failure this week. The system in question does have MPT hardware, but the hardware RAID feature is not in use. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742996: RFP: xtuple-web - web and mobile access to PostBooks
Package: wnpp Severity: wishlist Owner: Daniel Pocock dan...@pocock.pro Upstream: http://www.xtuple.org License: mixed: Apache, BSD, MIT, CPAL Source: Upstream has several source repositories under https://github.com/xtuple The web client is in this repository: https://github.com/xtuple/xtuple and some of the other repositories contain supporting content. Comments: - I currently co-maintain the main xTuple / PostBooks desktop (Qt-based) client package, it is co-ordinated through the pkg-xtuple group: http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-xtuple-maintainers - the web client provides an alternative user interface to the same PostgreSQL backend - I am initially opening this bug as an RFP as there is work to be done on dependencies (including build dependencies/tools) before this package can be created - some of the core dependencies (nodejs, postgresql-9.3-plv8) appear for the first time in the next major Debian release (Jessie), making it feasible to package this software - information on dependencies can be discovered in these files: https://github.com/xtuple/xtuple/blob/master/.gitmodules https://github.com/xtuple/xtuple/blob/master/package.json https://github.com/xtuple/xtuple/blob/master/npm-shrinkwrap.json https://github.com/xtuple/xtuple/blob/master/scripts/install_xtuple.sh - the next step is to build a wiki page with a table listing all the dependencies, their licenses and their packaging status - upstream appears to be targeting Ubuntu LTS so it should be possible to find common ground on a lot of things -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742783: init script kills all asterisk processes on a machine
Package: asterisk Version: 1:11.7.0~dfsg-1 The stop method in the init script contains these two lines: start-stop-daemon --stop --quiet --oknodo --retry=0/2/TERM/2/KILL/5 --exec $DAEMON start-stop-daemon --stop --quiet --oknodo --retry=0/2/TERM/2/KILL/5 --exec $CANARY If somebody is running multiple instances of Asterisk, this will kill all of them even if they only meant to kill one of them Would you consider removing these from the init script or could you elaborate on why they are necessary? The comments suggest that it is intended to kill any Asterisk CLI processes - is it really necessary to do that in this way? Shouldn't the CLI gracefully disconnect/reconnect when the main Asterisk process is killed/restarted? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742638: crashes if UserProfile is not an instance of ConversationProfile
Package: librecon-1.9 Version: 1.9.3-1 Severity: serious ConversationManager uses dynamic_cast to try and retrieve a ConversationProfile It doesn't check if the cast was successful and tries to use the pointer. This leads to a segmentation fault. Fixed upstream in 1.9.4 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742506: fails to send any outbound media on non-TURN sockets
Package: libresiprocate-turn-client-1.9 Version: 1.9.2-2 Severity: serious When reTurn client sockets are used in an application where TURN is not always required (e.g. with ICE), the TURN socket object is still used for sending/receiving with a non-TURN peer. In these situations, it fails to send out any media stream. This bug has been observed when using the reConServer application, which relies on the reTurn-client sockets -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688159: power down on a laptop is really awkward
On 17/03/14 12:56, althaser wrote: Hey Daniel, Could you please still reproduce this issue with newer gnome-shell version like 3.4.2-7+deb7u1 or 3.8.4-5+b1 ? It is not needed here with 3.8.4-5+b1. My system now has gnome-shell version 3.4.2-7+deb7u1 and I no longer have this problem with this version I do have another problem now, selecting hibernate doesn't really work any more: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740917
Bug#741350: a2enconf confusion - .conf extension?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 14/03/14 18:53, Jean-Michel Vourgère wrote: Hello Daniel Just a few hints: On Friday 14 March 2014 08:35:55 Daniel Pocock wrote: a) if my postinst or postrm calls apache2_invoke from inside a function, then it fails badly b) some of my postinst and postrm code is based on examples I saw in other packages, they test -x /usr/sbin/apache2 and it turns out this is not a great idea as if somebody does dpkg --remove apache2 loganalyzer dpkg --purge loganalyzer then at the moment the loganalyzer postrm runs with the purge argument, there is no /usr/sbin/apache2 and so it does not remove the symlink Also, the check for /usr/share/apache2/apache2-maintscript-helper would also fail if apache2 had been removed - it is OK for the postrm to just proceed without calling apache2_invoke at all if it is no longer there or should the postm complain? Please have another look at the wiki: apache2_invoke disconf must be called both at purge *and* at simple removal. So that should take care of your question b. Actually, source apache2-maintscript-helper is using the scripts arguments - like postrm purge - in oder to know what it should do. So it must be called from the script top level, and not from a function where that environment changed. If you really need to call the helpers from a function, I guess you need if [ -e /usr/share/apache2/apache2-maintscript-helper ] ; then . /usr/share/apache2/apache2-maintscript-helper fi at top level, where $1 == 'configure' or whatever. Then you should be able to call apache2_invoke from a function, providing you wrap it in a [ -e /usr/share/apache2/apache2-maintscript-helper ] too of course. I did not test that. Regarding your question b again, if you try dh_apache2, you'll see that deconfiguration is done at prerm time too, so that simultaneous removal of apache and your package should work, no matter the order in wich it occurs. And the bonus: If there's a bug in (pre|post)(inst|rm), you have someone else to blame, isn't that nice? ;-) -- Nirgal Almost - while that sounds good (making the helper script do everything), I am also trying to ensure my package is suitable for wheezy-backports so I've used slightly more verbose scripting as shown in the bottom of the wiki page: https://wiki.debian.org/Apache/PackagingFor24#Making_web_applications_compatible_to_both.2C_Apache_2.2_and_2.4 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTJLztAAoJEOm1uwJp1aqD3xUQAL5On8OURB3tk01NShKPbhQO f5SqbOSZvNF/5JQudW74rKPiMLhh/jJZvg7Cximdk5qNrcunR9/9fifbQPAedkdT MGoolV9izFcfaTPpd3CguERaKRCReiR5OAUWOBOgwBNit3vH2L4weXndSGLsI8AJ 2m+XVMeh/tyuRsfJ8twqT1b8BuZyIyX7h1+JoWZvPiMMLGjIczd3pf1foHiWmAFr 0Qk3I9v6ZuzyuPuEk7X4+T7ytmDNikpTpvEYGHp1UWaX3zalWNICbdXXejK4ZUyW +JgHW37eV3SWWHmTUlgkb8xl60BSI4UyP8dgG0Z/sjocAD1zbejJaK8l2Ru6Vi1j A0bYzq8kunjnIWE3/BHEl8yRTuNB34FNKAG0vSn2vDbJk9U7EPdbf8YTFHho1Wwk yD1jJy1CLCKvjWqCu9JXg9fT5s85Sjv0YXe9F2APu5HKrhNnOBrC/MNirAdWITdA Y+Ay5nqdpwXWlgmjmkficDx76G7VXN1T19xnyIqhLYBMdhPfed2UWHG6+n6vA5/B yNoqDVq8NjhjxUmwqhHVEG14irl8QL0EMwvSkqBJr5CrjFfGPzXCxaVvjYBXDTh6 ilmHScqz+PSE5oUV8AxAawnVkwu6CSH68DMqAY4nVyCY3Kv1LdiBKNbRVHOCngH6 8WXN2YVrDZGSfXtVwfut =VFSy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741350: a2enconf confusion - .conf extension?
On 11/03/14 18:17, Jean-Michel Vourgère wrote: Hello Daniel Please read apache2 debian news ( /usr/share/doc/apache2/NEWS.Debian.gz ) Moreover, the configuration mechanism in Debian has changed. All configurations in sites-enabled and conf-enabled need a .conf suffix now. This mechanism enable packages to deploy their configuration directly in conf-available without symlinks, while NOT enabling .dpkg-new and similar files by default. :) A common pattern in my own installations involves using Include to access the conf files from a virtualhost For example, when packages (pre-Apache2.4) offer me the option to symlink into conf.d I often decline and then I manually edit the virtualhost to Include the conf I realize this can be done just as easily with conf-available though If a package is intended for wheezy-backports, should it be creating /etc/apache2/conf-available? Regarding the wiki, assuming you do not want to use dh_apache2, I can read: Install the configuration file to /etc/apache2/conf-available/yourapplication.conf. You do need a .conf extension. Ok, thanks for confirming - the wiki examples do show the extension but I didn't see anything emphasizing it is a mandatory extension now Also, the wiki is quite explicit about the fact that you should use apache2_invoke enconf and *not* a2enconf directly. Yes, I have been updating my packages slowly and hadn't fully tried all of this yet but loganalyzer, as a new package, will be the first one where I do this properly I ran into other problems too: a) if my postinst or postrm calls apache2_invoke from inside a function, then it fails badly b) some of my postinst and postrm code is based on examples I saw in other packages, they test -x /usr/sbin/apache2 and it turns out this is not a great idea as if somebody does dpkg --remove apache2 loganalyzer dpkg --purge loganalyzer then at the moment the loganalyzer postrm runs with the purge argument, there is no /usr/sbin/apache2 and so it does not remove the symlink Also, the check for /usr/share/apache2/apache2-maintscript-helper would also fail if apache2 had been removed - it is OK for the postrm to just proceed without calling apache2_invoke at all if it is no longer there or should the postm complain? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740911: works OK in other versions
I tried this from another machine, with Evolution v3.8.5 on Fedora and the bug doesn't exist there. It works fine against DAViCal on wheezy. Maybe the fix for this can be backported from a newer Evolution into the wheezy version. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741350: a2enconf confusion - .conf extension?
Package: apache2 My package fails piuparts with Apache 2.4: https://piuparts.debian.org/sid/fail/loganalyzer_3.6.5+dfsg-2.log Looking at that log, I notice: Setting up loganalyzer (3.6.5+dfsg-2) ... Module php5 already enabled Enabling module cgi. To activate the new configuration, you need to run: service apache2 restart ERROR: Conf loganalyzer does not exist! 0m37.5s ERROR: WARN: Broken symlinks: /etc/apache2/conf-available/loganalyzer - /etc/loganalyzer/apache.conf So, it appears that a) the config file does exist, it is a symlink called /etc/apache2/conf-available/loganalyzer b) the command a2enconf loganalyzer fails Looking at some notes I found elsewhere, it appears that maybe my symlink should have a .conf extension or maybe it is not working at all because it is a symlink. The man page for a2enconf doesn't explain if a particular extension like .conf is needed and doesn't explain whether symlinks are supported This wiki also doesn't give exact details: https://wiki.debian.org/Apache/PackagingFor24 Could you please clarify these things in the man page and the wiki? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741037: log errors
Package: libsasl2-modules-ldap Version: 2.1.25.dfsg1-6+deb7u1 I was seeing errors from postfix: Mar 7 18:15:50 postfix/smtpd: auxpropfunc error invalid parameter supplied Mar 7 18:15:50 postfix/smtpd: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: ldapdb Mar 7 18:15:50 postfix/smtpd: canonuserfunc error -7 Mar 7 18:15:50 postfix/smtpd: _sasl_plugin_load failed on sasl_canonuser_init for plugin: ldapdb The first and third messages are sent to syslog with priority ERR I found this page: http://lists.centos.org/pipermail/centos/2007-December/048828.html which suggests simply removing the package (in that case, the equivalent RPM) and that made the errors stop while everything else still appears to work. I'm using saslauthd rather than direct sasl to LDAP and LDAP wasn't referenced in the /etc/postfix/sasl/smtpd.conf Should this package be less noisy when not explicitly configured? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740917: hibernate breaks after stable update
Package: hibernate Version: 2.0+15+g88d54a8-1 Severity: serious I have a system running wheezy. I periodically apply the security updates for wheezy. Yesterday, I applied security updates, the hibernate package did not change during the updates. However, hibernate is no longer working from the Gnome menu (menu - Shutdown... - Hibernate). Whenever I try to use the hibernate button there, it just locks the screen, no hibernation. /var/log/syslog shows some messages about NetworkManager sleep requested but nothing specific to hibernation. If I run hibernate-disk from the command line, it works, but gives a warning: # hibernate-disk hibernate-disk:Warning: Tuxonice binary signature file not found. It is not clear if this warning is related to the problem and it is not clear if the hibernate package is the root cause of the problem, maybe it is some Gnome fault, if so, please help redirect this bug to the correct package. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721277: Adiscon LogAnalyzer? rsyslog + mongodb?
On 05/03/14 21:06, Michael Biebl wrote: Am 05.03.2014 20:14, schrieb Daniel Pocock: On 05/03/14 19:58, Michael Biebl wrote: Michael, if Rainer confirms the fix version for the template issue, would you mind updating the packages and then just ping me to test? Sure, no problem. I'm currently waiting for liblogging to pass the NEW queue so I can upload rsyslog 7.6.0. I expect in that case the fix will land in 7.6.1 and I would then just update to that version. Michael Here are some upstream patches you could cherry-pick into the package: 18eaa5cc5c325e1f4c531dd03b463997c7fde1b4 (template not mandatory) 9d0fc675a51125acde057d0e53e8323c5e1ed572 (fix a string termination bug) This got it working for me I create the debian/patches on a branch in collab-maint, my branch is called pocock Please feel free to merge and release as 7.4.4-2, this will let people test while waiting for the 7.6.x releases -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721277: Adiscon LogAnalyzer? rsyslog + mongodb?
On 06/03/14 10:10, Daniel Pocock wrote: On 05/03/14 21:06, Michael Biebl wrote: Am 05.03.2014 20:14, schrieb Daniel Pocock: On 05/03/14 19:58, Michael Biebl wrote: Michael, if Rainer confirms the fix version for the template issue, would you mind updating the packages and then just ping me to test? Sure, no problem. I'm currently waiting for liblogging to pass the NEW queue so I can upload rsyslog 7.6.0. I expect in that case the fix will land in 7.6.1 and I would then just update to that version. Michael Here are some upstream patches you could cherry-pick into the package: 18eaa5cc5c325e1f4c531dd03b463997c7fde1b4 (template not mandatory) 9d0fc675a51125acde057d0e53e8323c5e1ed572 (fix a string termination bug) This got it working for me I create the debian/patches on a branch in collab-maint, my branch is called pocock Please feel free to merge and release as 7.4.4-2, this will let people test while waiting for the 7.6.x releases Just confirming that after those patches, LogAnalyzer 3.6.5 works for me now too In the LogAnalyzer install.php, I select SourceType: MongoDB native Select View: Syslog Fields Table type: MongoDB Database Host: localhost Database name: logs Database tablename: syslog Database user: (delete the default, must be blank) Database password: (also blank) This is how it appears in config.php: $CFG['DefaultSourceID'] = 'Source1'; $CFG['Sources']['Source1']['ID'] = 'Source1'; $CFG['Sources']['Source1']['Name'] = 'My Syslog Source'; $CFG['Sources']['Source1']['ViewID'] = 'SYSLOG'; $CFG['Sources']['Source1']['SourceType'] = SOURCE_MONGODB; $CFG['Sources']['Source1']['DBTableType'] = 'mongodb'; $CFG['Sources']['Source1']['DBServer'] = 'localhost'; $CFG['Sources']['Source1']['DBName'] = 'logs'; $CFG['Sources']['Source1']['DBUser'] = ''; $CFG['Sources']['Source1']['DBPassword'] = ''; $CFG['Sources']['Source1']['DBTableName'] = 'syslog'; In /etc/rsyslog.conf there is just this: $ModLoad ommongodb *.*action(type=ommongodb server=127.0.0.1 db=logs collection=syslog) No need to specify template or anything else. The values db=logs and collection=syslog come from the article here: http://loganalyzer.adiscon.com/articles/using-mongodb-with-rsyslog-and-loganalyzer/ I've suggested to upstream that the ommongodb defaults and the article and LogAnalyzer defaults for db and collection names should all be synchronized https://github.com/rsyslog/loganalyzer/issues/4 Once that is done, the README.Debian will probably be OK as it is again. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740952: purging old records from the database
Package: rsyslog-mongodb Version: 7.4.4-1 With normal logfiles, the files are rotated by logrotate What is the recommended solution for purging old records from MongoDB? Could this be part of the package, like a logrotate configuration? Or maybe it should just have an example in README.Debian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740952: purging old records from the database
On 06/03/14 21:51, Michael Biebl wrote: Am 06.03.2014 16:11, schrieb Daniel Pocock: Package: rsyslog-mongodb Version: 7.4.4-1 With normal logfiles, the files are rotated by logrotate What is the recommended solution for purging old records from MongoDB? Tbh, I have absolutely no idea. I'm actually not convinced that this should be done automatically. That said, the mongodb maintainer might have an answer, how this could be done for mongodb, so I've CCed him. Fwiw, the other db output plugins (e.g. rsyslog-mysql or rsyslog-pgsql) don't setup such an automatic pruning either. I also raised an upstream issue for comments on this issue: https://github.com/rsyslog/rsyslog/issues/47 Maybe some cron job can be created and records can be purged based on some combination of (priority, facility, age) - that would resemble the rules used to manage the traditional files Given the simplicity of MongoDB setup and maintenance for this type of data set, it could even be offered as an option in the debconf menus, e.g. Do you want to enable ommongodb now in a default configuration? This will just work if your mongodb-server has no passwords, as is the default on Debian. This may lead to quite a lot of people using it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721277: Adiscon LogAnalyzer? rsyslog + mongodb?
On 05/03/14 09:09, Florian Ernst wrote: Hello all, On Tue, Mar 04, 2014 at 03:49:25PM +0100, Daniel Pocock wrote: The rsyslog mongodb output module and the PHP mongodb modules are now in wheezy-backports. This would appear to be sufficient to do something like: rsyslog = mongodb = loganalyzer Has anybody else tried that or does anybody have any comments on it (or recommended alternatives)? That actually did work for a time, but something broke starting with rsyslog 7.4.0-1. Since then the format of the data dumped into mongodb doesn't match what tools like loganalyzer expect, cf. #721277 / #728827. As I was merely experimenting with it I didn't follow up any further. Some of this looks like documentation bugs and/or problems with the default config rather than mongodb integration itself LogAnalyzer and rsyslog are from the same upstream too, so I would be surprised if they would not have them working together I had a look at the Git history for the ommongodb, does anything stand out here? https://github.com/rsyslog/rsyslog/commits/master/plugins/ommongodb You state the problem started with 7.4.0-1 - could you comment on the previous set of versions that you had working (both rsyslog and LogAnalyzer versions)? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721277: Adiscon LogAnalyzer? rsyslog + mongodb?
On 05/03/14 11:26, Michael Biebl wrote: [dropping debian-devel] Am 05.03.2014 11:07, schrieb Daniel Pocock: On 05/03/14 09:09, Florian Ernst wrote: Hello all, On Tue, Mar 04, 2014 at 03:49:25PM +0100, Daniel Pocock wrote: The rsyslog mongodb output module and the PHP mongodb modules are now in wheezy-backports. This would appear to be sufficient to do something like: rsyslog = mongodb = loganalyzer Has anybody else tried that or does anybody have any comments on it (or recommended alternatives)? That actually did work for a time, but something broke starting with rsyslog 7.4.0-1. Since then the format of the data dumped into mongodb doesn't match what tools like loganalyzer expect, cf. #721277 / #728827. As I was merely experimenting with it I didn't follow up any further. Some of this looks like documentation bugs and/or problems with the default config rather than mongodb integration itself LogAnalyzer and rsyslog are from the same upstream too, so I would be surprised if they would not have them working together I had a look at the Git history for the ommongodb, does anything stand out here? https://github.com/rsyslog/rsyslog/commits/master/plugins/ommongodb You state the problem started with 7.4.0-1 - could you comment on the previous set of versions that you had working (both rsyslog and LogAnalyzer versions)? If the README.Debian (which was based on [1]) is no longer correct, please let me know. If you are using the 7.4.0 backport for wheezy, make sure to also use the libjson-c 0.11 backport. [1] http://git.adiscon.com/?p=rsyslog.git;a=blob;f=plugins/ommongodb/README;hb=HEAD Michael, thanks for the fast response on this In the bug report, it goes on to say that after correcting the first issue, I can dump data to mongodb again, though the format doesn't match previous entries. and then the email to debian-devel suggests that LogAnalyzer can no longer read the data (even though it is there) It is this latter issue that I am curious about - is it a deliberate schema change? Is it just the libjson-c version (and can you add that to the control file)? Does it require some newer version of LogAnalyzer (and is anyone aware if upstream is working on that, if it is unreleased, etc)? I also queried it upstream: https://github.com/rsyslog/rsyslog/issues/46 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740827: should not give 2xx response if database write fails
Package: davical Version: 1.1.1-1 Severity: serious I update a contact record in Evolution and save the record The Apache access.log shows the PUT request with a 204 response The error.log contains various errors The new data is not persisted to the database and there is no feedback in Evolution If Evolution tries to save the contact a second time (e.g. because of a second modification), it receives a 412 response from DAViCal The actual errors that occur in the database (and error.log of Apache) are below, although I would expect that for any error situation at all DAViCal should not be returning 204, I will open a second bug about the cause of this error: Query: QF: SQL error 22007 - ERROR: invalid input syntax for type timestamp with time zone: ... Query: QF: UPDATE caldav_data SET caldav_data=:dav_data, dav_etag=:etag, logged_user=:session_user, modified=:modified, user_no=:user_no, caldav_type='VCARD' WHERE dav_name=:dav_name Query: QF: SQL error 25P02 - ERROR: current transaction is aborted, commands ignored until end of transaction block Query: QF: DELETE FROM addressbook_address_email WHERE dav_id = :dav_id -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740828: DAViCal expects timestamp in REV field of vCard
Package: davical Version: 1.1.1-1 Severity: serious I mark this as serious because DAViCal no longer interoperates with Evolution, the default contact/calendar client in Debian Evolution submits a vCard to DAViCal with a REV field like this: REV:d3b07384d113edec49eaa6238ad5ff00 In the RFCs it suggests it should be a time value and that Evolution may be at fault: http://tools.ietf.org/html/rfc2426#section-3.6.4 https://tools.ietf.org/html/rfc6350#section-6.7.4 DAViCal tries to put it in a timestamp column in PostgreSQL, where it is rejected: Query: QF: SQL error 22007 - ERROR: invalid input syntax for type timestamp with time zone: ... Query: QF: UPDATE caldav_data SET caldav_data=:dav_data, dav_etag=:etag, logged_user=:session_user, modified=:modified, user_no=:user_no, caldav_type='VCARD' WHERE dav_name=:dav_name If this is a fault in evolution, please confirm and reassign the bug there If clients are behaving like this, however, should DAViCal support them in some way? Related issues: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740827 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699353 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740828: evolution package versions
Just to confirm the client system is running wheezy, evolution packages are all v3.4.4-3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740848: ITP: loganalyzer - web tool for inspecting syslog data
Package: wnpp Severity: wishlist Owner: Daniel Pocock dan...@pocock.com.au Upstream: http://loganalyzer.adiscon.com License: GPL-3 Allows access to syslog data from files and databases through a web interface. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721277: Adiscon LogAnalyzer? rsyslog + mongodb?
On 05/03/14 14:38, Florian Ernst wrote:
On Wed, Mar 05, 2014 at 12:13:23PM +0100, Michael Biebl wrote:
Am 05.03.2014 11:26, schrieb Michael Biebl:
Am 05.03.2014 11:07, schrieb Daniel Pocock:
On 05/03/14 09:09, Florian Ernst wrote:
On Tue, Mar 04, 2014 at 03:49:25PM +0100, Daniel Pocock wrote:
The rsyslog mongodb output module and the PHP mongodb modules are now in
wheezy-backports. This would appear to be sufficient to do something
like:
rsyslog = mongodb = loganalyzer
Has anybody else tried that or does anybody have any comments on it (or
recommended alternatives)?
That actually did work for a time, but something broke starting with
rsyslog 7.4.0-1. Since then the format of the data dumped into mongodb
doesn't match what tools like loganalyzer expect, cf. #721277 / #728827.
As I was merely experimenting with it I didn't follow up any further.
Some of this looks like documentation bugs and/or problems with the
default config rather than mongodb integration itself
Florian, have you followed the steps outlined in
http://www.rsyslog.com/tag/ommongodb/ ?
ITIYM http://www.rsyslog.com/using-mongodb-with-rsyslog-and-loganalyzer/
in particular?
Not until now. Previously I followed
http://www.rsyslog.com/doc/rsyslog_conf_modules.html/ommongodb.html
(which now redirects to http://www.rsyslog.com/doc/ommongodb.html).
I have now tried to implement the configuration mentioned there
verbatim. This led to remote logs simply disappearing, i.e. not being
logged on my syslog host. Thus I have reverted the change, for my
current mongodb rsyslog configuration please see the other mail to
Daniel.
Just out of interest, if you empty the database (or clear out the events
created before rsyslog 7.4 was installed) does LogAnalyzer work?
I'm not familiar with all the details of LogAnalyzer or the schema
attributes, this is just something that occurred to me when reading your
description of the problem
Also, I've just created a proper package of LogAnalyzer, it is in the
FTP queue - I'd appreciate any feedback you have about it or assistance
with maintaining it through our pkg-monitoring group. README.Debian has
some basic hints to get started with MongoDB, but if you could validate
or elaborate on it that would be very helpful.
While waiting for the package to be approved, you can build from git:
ssh://${USER}@git.debian.org/git/pkg-monitoring/loganalyzer.git
Vcs-Git: git://git.debian.org/pkg-monitoring/loganalyzer.git
Vcs-Browser:
http://git.debian.org/?p=pkg-monitoring/loganalyzer.git;a=summary
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740869: template seems to be mandatory now for ommongodb
Package: rsyslog-mongodb Version: 7.4.4-1~bpo70+1 If I try the configuration samples from README.Debian, it just logs an error to /var/log/syslog rsyslogd-2207: error during parsing file /etc/rsyslog.conf, on or before line 124: parameter 'template' required but not specified - fix config [try http://www.rsyslog.com/e/2207 ] The provided URL is not helpful Manually declaring a template and action like this seems to generate entries to mongodb: # Load the module $ModLoad ommongodb # declare a template called BSON: template(name=BSON type=string string=\sys\ : \%hostname%\, \time\ : \%timereported:::rfc3339%\, \time_rcvd\ : \%timegenerated:::rfc3339%\, \msg\ : \%msg%\, \syslog_fac\ : \%syslogfacility%\, \syslog_sever\ : \%syslogseverity%\, \syslog_tag\ : \%syslogtag%\, \procid\ : \%programname%\, \pid\ : \%procid%\, \level\ : \%syslogpriority-text%\) # declare an action using the BSON template: *.*action(type=ommongodb server=127.0.0.1 db=logs collection=syslog template=BSON) Now I can see entries in mongodb: $ mongo MongoDB shell version: 2.0.6 connecting to: test use logs switched to db logs db.syslog.find() -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740869: access from LogAnalyzer
Along with the BSON template defined earlier in this bug report, I tried the following in /etc/loganalyzer/config.php: $CFG['Sources']['Source1']['ID'] = Source1; $CFG['Sources']['Source1']['Name'] = mongo; $CFG['Sources']['Source1']['Description'] = Main logs from rsyslog daemon on Debian; $CFG['Sources']['Source1']['SourceType'] = SOURCE_MONGODB; $CFG['Sources']['Source1']['SourceDBType'] = SOURCE_MONGODB; $CFG['Sources']['Source1']['DBName'] = 'logs'; $CFG['Sources']['Source1']['DBServer'] = 'localhost'; $CFG['Sources']['Source1']['DBTableName'] = 'syslog'; $CFG['Sources']['Source1']['ViewID'] = SYSLOG; LogAnalyzer connects to mongodb and then says Invalid datafield mappings -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721277: Adiscon LogAnalyzer? rsyslog + mongodb?
On 05/03/14 16:39, Florian Ernst wrote: On Wed, Mar 05, 2014 at 04:13:08PM +0100, Daniel Pocock wrote: On 05/03/14 14:38, Florian Ernst wrote: ITIYM http://www.rsyslog.com/using-mongodb-with-rsyslog-and-loganalyzer/ in particular? Not until now. Previously I followed http://www.rsyslog.com/doc/rsyslog_conf_modules.html/ommongodb.html (which now redirects to http://www.rsyslog.com/doc/ommongodb.html). I have now tried to implement the configuration mentioned there verbatim. This led to remote logs simply disappearing, i.e. not being logged on my syslog host. Thus I have reverted the change, for my current mongodb rsyslog configuration please see the other mail to Daniel. Following up to that: the config given in the first link looks like it should actually do the trick. It reads as if the missing parsing should take place. When you say first link, did you mean this one: http://www.rsyslog.com/using-mongodb-with-rsyslog-and-loganalyzer/ I had a look at that It basically appears that a) local log entries and entries defined on existing transports are not sent to mongodb using anything in that example b) log entries received over TCP port 13514 will be sent to mongodb, but only if they are in the CEE format (not just any syslog entry) But as that config broke my remote syslog, I didn't tinker with it any further. It might be that there's a separate problem in my remote logging configuration, but I don't really see myself exploring that posiibility further at the moment, given that I lack a safe testing environment. When you say broke your remote syslog, maybe your remote syslog is not sending to it with CEE format? I'm not sure that everybody will want to use the CEE format, many devices may only support regular syslog format, so a more basic example is needed too -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721277: Adiscon LogAnalyzer? rsyslog + mongodb?
On 05/03/14 19:58, Michael Biebl wrote: forwarded 721277 https://github.com/rsyslog/rsyslog/issues/46 thanks Thanks a lot for your interest so far! When I initially added rsyslog-mongodb I did some testing and based on that wrote README.Debian. I do not actively use it though, so I didn't follow the upstream changes for that module. Florian, from what I understand skimming over the bug report, the template parameter is no longer optional, and explicitly setting that makes ommongodb output data to the mongodb server again? If that is an intended change in behaviour or simply a bug, I dunno. Rainer sent a private reply to me after this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740869 stating that the template issue was fixed about four weeks ago. I'm not sure if that means it is fixed in a release or just in upstream Git. I think what he means is that the issue was a bug (the template parameter should not normally be mandatory) If the former, we certainly would have to update README.Debian and it also warrants a NEWS.Debian. It should be possible in that case to come up with a template which outputs the data in the format as before. If it's simply a bug, that ommongodb no longer applies a default template, then we should fix that, of course. As said, I don't actively use the plugin, so any help regarding this is very much appreciated. Hopefully the LogAnalyzer package (which will have a working config.php sample for MongoDB on localhost) will entice more users to try this and give feedback about any future regressions. Michael, if Rainer confirms the fix version for the template issue, would you mind updating the packages and then just ping me to test? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740911: WebDAV: Evolution sends invalid REV field, DAViCal expects timestamp
Package: evolution Version: 3.4.4-3 Severity: serious I mark this as serious because DAViCal no longer interoperates with Evolution, the default contact/calendar client on the desktop. Maybe other servers are affected too, I just haven't tested any myself so far. My DAViCal version is 1.1.1-1. I also opened a bug against DAViCal in case something needs to be fixed there: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740828 Evolution submits a vCard to DAViCal with a REV field like this: REV:d3b07384d113edec49eaa6238ad5ff00 In the RFCs it suggests it should be a time value and that Evolution may be at fault: http://tools.ietf.org/html/rfc2426#section-3.6.4 https://tools.ietf.org/html/rfc6350#section-6.7.4 DAViCal tries to put it in a timestamp column in PostgreSQL, where it is rejected: Query: QF: SQL error 22007 - ERROR: invalid input syntax for type timestamp with time zone: ... Query: QF: UPDATE caldav_data SET caldav_data=:dav_data, dav_etag=:etag, logged_user=:session_user, modified=:modified, user_no=:user_no, caldav_type='VCARD' WHERE dav_name=:dav_name If this is a fault in evolution, please confirm and advise whether the bug 740828 against DAViCal should be closed. Related issues: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740827 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699353 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736104: [Ganglia-developers] ganglia-web package at risk
On 04/02/14 14:56, Daniel Pocock wrote: On 04/02/14 14:47, Chris Burroughs wrote: I thought the distro anti-bundling stance was paired with a we already have X so you should just depend on it. I'm not sure how this works with javascript. Is there some debian jquery package that could be depended on? There is a jQuery package in Debian, but it is a slightly older version There are various issues that motivate these rules/policies in distributions: - disk space - security updates (better to just have one copy of X to update in one shot, hard to find multiple bundled copies of X and check they all have the latest/necessary security patches) - source - bundling any minified artifact is not consider to be real source code That said, given that every project seems to depend on a different version of jQuery, there is some leniency - Debian accepts bundled copies of some things like jQuery as long as they are not minified. It is perfectly OK to minify them in an installation script, but the source tarball from the Ganglia web site must be 100% readable source code. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736104 I had a quick look at this and found that the jquery-ui stuff is not cleanly available as source because of the way it is built as a custom JavaScript file using the tool here: https://jqueryui.com/download so it is not a quick fix for me to simply drop in uncompressed JavaScript. What can be done is that instead of using the custom method to get jquery-ui, perhaps the full source from here: https://jqueryui.com/resources/download/jquery-ui-1.10.4.zip can be downloaded into the ganglia-web repository (including both the minified and the human readable version) and then the full minified .js file (rather than a custom.min.js file) can be used within ganglia-web Are the ganglia-web developers happy to support that version of jquery-ui? Is there any reason the custom version has to be used? The package has now taken the first step towards being completely dropped from Debian and Ubuntu: http://packages.qa.debian.org/g/ganglia-web.html so it is important that we agree on a solution for 3.5.13 or it will be completely missing from the upcoming Ubuntu trusty release and the Debian 8 release early next year. Regards, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736104: some updates
I've added the following sources to the upstream repository for inclusion in 3.5.13 jquery.scrollTo-1.4.2.js jquery-1.9.1.js Upstream has dropped the file dash/js/jquery-ui-1.8.14.custom.min.js Only the file js/jquery-ui-1.10.2.custom.min.js requires remediation now -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736104: [Ganglia-developers] ganglia-web package at risk
On 03/03/14 21:08, Vladimir Vuksan wrote: That would be fine with me if that is what it takes. Include the full blown Jquery UI. I see there is 1.10.2 right now Can I just swap from the custom.min.js file to the full min.js file? Or do you want to try the latest, 1.10.4, before releasing web 3.5.13? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736104: [Ganglia-developers] ganglia-web package at risk
On 03/03/14 21:27, Vladimir Vuksan wrote: Let's stick with 1.10.2. Done Sources are in a directory called contrib now, it is copied into the ganglia-web dist tarball too -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740554: mangles classpath in upstream manifest
On 03/03/14 01:36, Emmanuel Bourg wrote: Hi Daniel, maven-ant-helper was useful to build the Maven dependencies when Maven wasn't packaged yet (or to break circular dependencies). It's a limited implementation of the Maven lifecycle using only Ant, and it can't really aim at being on par with Maven in all areas. For jmxetric I would advise using maven-debian-helper instead. Hi Emmanuel, Thanks for this feedback When I search for Debian Java mvn packaging, Google had referred me to this wiki: https://wiki.debian.org/Java/MavenRepoHelper which suggested using libplexus-io-java as an example. That is using maven-ant-helper I don't mind changing my packages to use the maven-debian-helper, but I will look at that next time I update them. Regards, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740489: include correct UA version string
package: libjs-jssip version: 0.4.0.20140212.1-1 The UA version string in the SIP headers is incorrect This is a bug in the way we use make instead of upstream's grunt build system to build the JavaScript. If grunt becomes part of Debian, then we will just use grunt and the problem will go away. If not, then we need to improve the Makefile to fix this and similar issues. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736077: [Pkg-javascript-devel] Bug#736077: dont leak private network information (at least not by default)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 19/01/14 15:22, Holger Levsen wrote: package: libjs-jssip tags: security Hi Daniel, thanks for working on usuable + secure RTC in the webbrowser! During your presentation at the Paris mini-debconf I just learned that your libjs-jssip leaks all networks to the sip server (or calling party), which I consider a privacy violation (which has been implemented to improve the user experience by allowing the application to choose the best network connection). Still, if I connect via route $X I expect this software not to leak my other routes, which might contaín sensitive information. In the talk you said it was trivial to comment out these lines, so I'm asking you to do this by default and optionally allow it. I actually did some experiments with this (using a PyRoute script in the SIP proxy to strip some ICE candidates from the SDP message body) I found that sometimes the other end of the connection wasn't happy with the SDP. Maybe there is something embedded in the STUN ICE check messages and the peer knows that the SDP has been modified. I would need to look more closely at the spec to find out. I'm CCing the Jitsi dev list, they develop the ice4j ICE library for Java and may be able to comment on this. It may also be useful for Jitsi, Empathy and other softphones to offer a similar feature and if it is practical, please raise the same bug against those packages. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTEw8hAAoJEOm1uwJp1aqDpwAQAKaSO1626Q0FbYxkxL/6iEhv 03JCDeAHbpe7GWIYvJipjiq4l7WMxq1afYD7FInp39HOlvjcqjl3Pu//5NWR4043 R1hR/8M7+248Vk6Ss0eFNZuGnlSjl1Dg/ADrVlZTlmvEGjEfcLA20454dWEZWJII fy3yHNPthHeqza/QxYvCt5CjwLotnOyUZXOpIM9VvxAm/GIRLo48fCGQYCmAZsHy mjSnyX/MPoRYXo3OQTrvHjCVZzj/5DR/rNEsvIHannCwQdKJOQrALNJgHi5Q9g6u J3LnF36I+zcdnIle4MS+gjNQ5oVHzZBJ52OsGGFgzBreK4r09OUkpZStRQKpkZ9s iW9oPUNEjpMEafc37MYpCPN6xrGquIDZM2Y8lo3hrF3ZlZytJYlApaIjcTQNk5IK KKsS7UOPmBsoYFIM/qWUppTyWMEdO6KWRjyQxsFyHlQ/HGuDUQLYkk3PginNj46W o7V20ujhct8Lm1ah7KeYxKAJt3AZ6u8GJrgSYE89+ZUBZ5OYtXFXMflq8WCcoEiK B4hCvgCbTzzbsKDOt1S3xDEczeelP+aNbuhHFE+NfkpOuuvkk5K5WqdF2SvSgcYq GH3uZkJ3xmKHG+lfZEYj0P999j6IUMwbY80VhrjE3u7fl8sZA5RHwunftyhqSn7o NxIXj7mL2MBBr8VHcGel =LRNH -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740441: suggest jmxetric, provide convenient way to enable it
Emmanuel Bourg ebo...@apache.org wrote: jmxetric looks interesting but I don't think tomcat7 should suggest a monitoring tool, apache2 doesn't suggest nagios3 for example. The difference is that jmxetric does JMX, so it is specific to Java app servers, of which tomcat is obviously the most well known It also suggests that Debian has tested the things together, which reassures users that it will just work. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740517: observations on XCP
XCP is useful and works well for some people - is there any reason not to simply leave the last released version in the archive and stop trying to package new versions? Even if those don't have the latest features, they are still useful in comparison to alternatives. There are many products (e.g. procmail) that are extremely popular but have not been formally supported by any upstream for years[1]. Mozilla publicly announced an end to development of Thunderbird[2], but it remains popular too. Maybe we need to have a mechanism to let people see the upstream support status of packages at time of installation and make their own decision if they feel comfortable with it? Could anybody add any comments to this bug about migration strategy? Should people anticipate using CentOS for dom0 systems in future? Or just stick with Xen-API on wheezy (which will still be around and subject to security updates through to 2016)? Or move to KVM or Ganeti or something else? It would be interesting to see a comparison of the options, and the impact on things like OpenStack packaging, even if there is no clear solution for all users. It sounds like Xen-API is at risk of ending up like FreeSWITCH and other products that are unpackagable (a common problem in the VoIP space). While some of them to remain 100% free (just inconvenient, due to bundled libraries that upstream forked) there is always a risk that as things move out of the mainstream, they do not remain free software at all. Big thanks to the maintainers for all the work they have put in up to this point. 1. http://www.procmail.org/procmail.HISTORY.html 2. http://www.zdnet.com/mozilla-scraps-thunderbird-development-email-client-not-a-priority-anymore-700469/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740554: mangles classpath in upstream manifest
Package: maven-ant-helper
Version: 7.7
Severity: important
In debian/build.properties (for the jmxetric package) I have
manifest=src/main/resources/META-INF/MANIFEST.MF
to copy the upstream manifest
The manifest contains:
Manifest-Version: 1.0
Premain-Class: info.ganglia.jmxetric.JMXetricAgent
Boot-Class-Path: oncrpc-${oncrpc.version}.jar
gmetric4j-${gmetric4j.version}.jar
Can-Redefine-Classes: false
The long line is messed up in the JAR produced by maven-ant-helper:
a) the long line is broken
b) the version substitution is not done
As a workaround, I can supply a modified manifest instead
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740430: ITP: gmetric4j - Ganglia for Java
Package: wnpp Severity: wishlist Owner: Daniel Pocock dan...@pocock.com.au Upstream: https://github.com/ganglia/gmetric4j License: Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the Software), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740431: ITP: jmxetric - Ganglia for Java (JMX)
Package: wnpp Severity: wishlist Owner: Daniel Pocock dan...@pocock.com.au Upstream: https://github.com/ganglia/jmxetric License: Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the Software), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740441: suggest jmxetric, provide convenient way to enable it
Package: tomcat7 Severity: wishlist It would be useful to suggest libjmxetric-java and provide a convenient way to enable it. If enabled by the user, it needs to be added to the JVM boot classpath as described here: http://danielpocock.com/monitoring-jboss-tomcat-and-application-servers-with-jmxetric In practice, this may just mean providing a sample, commented JAVA_OPTS in /etc/default/tomcat7 and some comments in README.Debian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740441: sample /etc/default/tomcat7 entries
Adding this to /etc/default/tomcat7 makes it work with the default
ganglia-monitor configuration on Debian
# for JMXetric
# - install packages ganglia-monitor and libjmxetric-java
# - cp /usr/share/doc/libjmxetric-java/jmxetric.xml \
# /etc/ganglia/jmxetric-tomcat7.xml
# - edit jmxetric-tomcat7.xml to your requirements
# (bare minimum: change ProcessName to tomcat7)
# - and then uncomment the variable assignments below:
#JARLIB=/usr/share/java
#GANGLIA_ETC=/etc/ganglia
#JMXETRIC_CFG=${GANGLIA_ETC}/jmxetric-tomcat7.xml
#JMXETRIC_PARAMS=host=239.2.11.71,port=8649,wireformat31x=true,mode=multicast,config=${JMXETRIC_CFG}
#JAVA_OPTS=${JAVA_OPTS} -Xbootclasspath/p:${JARLIB}/oncrpc.jar
#JAVA_OPTS=${JAVA_OPTS} -Xbootclasspath/p:${JARLIB}/gmetric4j.jar
#JAVA_OPTS=${JAVA_OPTS}
-javaagent:${JARLIB}/jmxetric.jar=${JMXETRIC_PARAMS}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740232: resiprocate ftbfs on amd64 (1 test failure)
On 27/02/14 15:37, Daniel Pocock wrote:
On 27/02/14 15:18, Matthias Klose wrote:
Am 27.02.2014 14:02, schrieb Daniel Pocock:
On 27/02/14 11:12, Matthias Klose wrote:
Package: resiprocate
Version: 1.9.1-1
Severity: serious
Tags: sid jessie
[...]
STACK | 20140227-095642.674 | testXMLCursor | RESIP:CONTENTS |
47431674565824 |
XMLCursor.cxx:260 | XMLCursor::nextSibling0x2b238c249d00[resource
uri=sip:adam-friends@exa] 0x2b238c24a010[list
xmlns=urn:ietf:params:xml:ns]
All OK
PASS: testXMLCursor
1 of 18 tests failed
This is just the summary line
Could you look earlier in the log for the FAIL and provide the context
around that? e.g.
grep -C 20 FAIL: resiprocate-build.log
PASS: testMD5Stream
lt-testParseBuffer: testParseBuffer.cxx:41: int main(int, char**): Assertion
`result == test' failed.
/bin/bash: line 5: 12077 Aborted ${dir}$tst
FAIL: testParseBuffer
Great, that is the same failure as the Ubuntu build log link
I notice Ubuntu builds with gcc 4.8 now. The other builds we've done on
amd64 have been with gcc 4.6 and gcc 4.7 and the tests have always run
successfully there.
Are you aware of any gcc 4.8 issues that could be exposing a fault in
this code or causing it to fail? Have other packages had similar issues
on the latest Ubuntu?
I'll test the latest trunk with this gcc
I just did the following:
- on a virtual machine with Ubuntu saucy, amd64, gcc-4.8, 1.9.1-1 builds OK
- upgraded the VM to latest trusty with apt-get dist-upgrade
- build failed with a compiler error (see below)
- starting the build again (by calling make in the source tree without
cleaning it), it continues without repeating the error
- the build machine is a very stable HP server with ECC RAM, unlikely to
be a random hardware issue, nothing else is showing signs of trouble
I'm suspicious about this gcc in trusty now, not sure this should be an
RC bug against reSIProcate but I'm happy to investigate some more on a
machine with sid as well.
/usr/include/srtp/config.h:134:0: note: this is the location of the
previous definition
#define PACKAGE_VERSION
^
g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.8/README.Bugs for instructions.
make[5]: *** [Conversation.lo] Error 1
make[5]: *** Waiting for unfinished jobs
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740392: ITP: ck - Concurrency Kit
Package: wnpp Severity: wishlist Owner: Daniel Pocock dan...@pocock.com.au Upstream: http://concurrencykit.org/ License: BSD This is a dependency for the latest Ganglia -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740232: resiprocate ftbfs on amd64 (1 test failure)
On 27/02/14 11:12, Matthias Klose wrote: Package: resiprocate Version: 1.9.1-1 Severity: serious Tags: sid jessie [...] STACK | 20140227-095642.674 | testXMLCursor | RESIP:CONTENTS | 47431674565824 | XMLCursor.cxx:260 | XMLCursor::nextSibling0x2b238c249d00[resource uri=sip:adam-friends@exa] 0x2b238c24a010[list xmlns=urn:ietf:params:xml:ns] All OK PASS: testXMLCursor 1 of 18 tests failed This is just the summary line Could you look earlier in the log for the FAIL and provide the context around that? e.g. grep -C 20 FAIL: resiprocate-build.log make[4]: *** [check-TESTS] Error 1 make[4]: Leaving directory `/scratch/packages/tmp/resiprocate-1.9.1/rutil/test' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/scratch/packages/tmp/resiprocate-1.9.1/rutil/test' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/scratch/packages/tmp/resiprocate-1.9.1/rutil' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/scratch/packages/tmp/resiprocate-1.9.1' dh_auto_test: make -j1 check returned exit code 2 make: *** [binary] Error 2 verified on current sid, same failure as in https://launchpad.net/ubuntu/+source/resiprocate/1.9.1-1 also dh-autoreconf is needed to update the autotools files for ppc64el. Ok, thanks for that, I will include that in the next upload -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740232: resiprocate ftbfs on amd64 (1 test failure)
On 27/02/14 15:18, Matthias Klose wrote:
Am 27.02.2014 14:02, schrieb Daniel Pocock:
On 27/02/14 11:12, Matthias Klose wrote:
Package: resiprocate
Version: 1.9.1-1
Severity: serious
Tags: sid jessie
[...]
STACK | 20140227-095642.674 | testXMLCursor | RESIP:CONTENTS |
47431674565824 |
XMLCursor.cxx:260 | XMLCursor::nextSibling0x2b238c249d00[resource
uri=sip:adam-friends@exa] 0x2b238c24a010[list
xmlns=urn:ietf:params:xml:ns]
All OK
PASS: testXMLCursor
1 of 18 tests failed
This is just the summary line
Could you look earlier in the log for the FAIL and provide the context
around that? e.g.
grep -C 20 FAIL: resiprocate-build.log
PASS: testMD5Stream
lt-testParseBuffer: testParseBuffer.cxx:41: int main(int, char**): Assertion
`result == test' failed.
/bin/bash: line 5: 12077 Aborted ${dir}$tst
FAIL: testParseBuffer
Great, that is the same failure as the Ubuntu build log link
I notice Ubuntu builds with gcc 4.8 now. The other builds we've done on
amd64 have been with gcc 4.6 and gcc 4.7 and the tests have always run
successfully there.
Are you aware of any gcc 4.8 issues that could be exposing a fault in
this code or causing it to fail? Have other packages had similar issues
on the latest Ubuntu?
I'll test the latest trunk with this gcc
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740160: gnutls unusable with cacert SHA2-512 sigs
Package: libgnutls26 Severity: serious Version: 2.12.20-8 cacert.org recently started signing certs with sha512WithRSAEncryption Consider the following scenario: - some service running on a Debian stable (wheezy) host (e.g. slapd), admin replaces their cacert certificate with one of these new certs - clients (e.g. PAM LDAP module, Apache mod_authnz_ldap) on Debian hosts linked against gnutls Everything stops working when the replacement certificate is installed Troubleshooting, the following is observed: - running ldapsearch or similar commands, the user sees errors like: ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) or with -d 1 for debugging, there is more detail but it doesn't help: TLS: can't connect: A TLS packet with unexpected length was received.. ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) - the user then tries openssl s_client openssl s_client -connect ldap-host.example.org:636 -tls1 -CAfile /etc/ssl/certs/cacert.org.pem and it connects successfully - if the user also tries gnutls-cli however, it does not work, failing with errors like this: GnuTLS error: A TLS packet with unexpected length was received. - then the admin tries putting their server (e.g. slapd) in debug mode and sees errors like this Could not negotiate a supported cipher suite - the fact that openssl s_client worked and gnutls-cli did not work may leave them feeling it is gnutls problems again (a Google search finds plenty of old posts complaining about gnutls and suggesting people should recompile everything with openssl) - running gnutls-cli in debug mode, I notice the following: $ gnutls-cli -p 636 --priority NORMAL:+SIGN-RSA-SHA512 -d 255 ldap-host.example.org |2| EXT[SIGA]: sent signature algo (4.2) DSA-SHA256 |2| EXT[SIGA]: sent signature algo (4.1) RSA-SHA256 |2| EXT[SIGA]: sent signature algo (2.1) RSA-SHA1 |2| EXT[SIGA]: sent signature algo (2.2) DSA-SHA1 Even explicitly requesting SHA512 doesn't help: gnutls-cli -p 636 --priority NORMAL:+SIGN-RSA-SHA512 -d 255 ldap-host.example.org It seems that the gnutls client code in wheezy does not signal support for the SHA512 stuff in the client hello message even if it is requested in the cipher suite $ gnutls-cli --list | grep 512 MACs: SHA1, MD5, SHA256, SHA384, SHA512, MD2, RIPEMD160, MAC-NULL PK-signatures: SIGN-RSA-SHA1, SIGN-RSA-SHA224, SIGN-RSA-SHA256, SIGN-RSA-SHA384, SIGN-RSA-SHA512, SIGN-RSA-RMD160, SIGN-DSA-SHA1, SIGN-DSA-SHA224, SIGN-DSA-SHA256, SIGN-RSA-MD5, SIGN-RSA-MD2 suggests that the RSA-SHA512 is present and should work, but it doesn't This is likely to be particularly annoying for people to troubleshoot, especially if they have only allocated 5-10 minutes to replace their certificate and they end up spending hours digging through their logs and pulling their hair out before they realize what is wrong Looking at the connections with tcpdump, I notice: - client sends SSL client hello - server drops connection without sending more data back to client A suggested workaround is for the admin to create their own local root CA instead of relying on CA cert. That means that the admin can ensure that any changes to CA policy (e.g. using SHA512) are tested before being forced on people. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740162: mod_authnz_ldap: no error.log feedback about LDAP TLS issues such as cert expiry, cipher mismatch, etc
Package: apache2.2-bin Version: 2.2.22-13+deb7u1 Apache is authenticating users against an LDAP server. An ldaps:// URL is used, e.g. AuthLDAPURL ldaps://ldap.example.org/dc=example,dc=org When the LDAP server SSL cert expires, access to the protected URLs fails with 500 Internal Server Error and tells the user to check the server's error log There is nothing in error.log to indicate that the fault is with LDAP or TLS - nothing in error.log at all. For this situation, there should be an error log entry complaining that the LDAP server certificate is expired. After updating the cert and restarting slapd it is still not working though and there is still nothing in error.log tcpdump shows that there are attempts to contact the LDAP server. The client hello packet is sent to the server using SSL 3.0 and there is no response, the server just drops the connection. Connecting to the server with openssl s_client works as expected and the cert is verified. Looking more closely, I found that a) the new LDAP server certificate was signed with SHA512 b) libgnutls26 seems to have bugs with that (see also Debian bug 740160) c) in this case, there is little that mod_authnz_ldap can do but it would still be very helpful if it logged something to error.log to say that the LDAP server unexpectedly dropped the connection during the TLS handshake Just to clarify, when I originally saw the Internal Server Error I had no idea it was even an LDAP issue - my first thought was that the fault was in the CGI script I was trying to access and I started trying to debug the script. This is why I think there should be logging about these TLS issues. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740160: gnutls unusable with cacert SHA2-512 sigs
On 26/02/14 19:17, Andreas Metzler wrote: On 2014-02-26 Daniel Pocock dan...@pocock.pro wrote: Package: libgnutls26 Severity: serious Version: 2.12.20-8 [...] - running gnutls-cli in debug mode, I notice the following: [...] Can you check whether this is fixed in GnuTLS 3.x? - It is available in wheezy-backports. I already removed the cacert.org certs from that server and changed to another root so it is not something I can test immediately. Even if 3.x fixes it, people will still be using wheezy for another good 12-18 months so this probably needs to go in a security update to avoid massive inconvenience (unless cacert.org decides to go back to SHA-256) Also, I started a thread on the cacert mailing list about this issue: https://lists.cacert.org/wws/arc/cacert/2014-02/msg1.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738835: Satellite config vs null client config
The Debian package of Postfix offers a Satellite system configuration (a list of all the Debian configs at the bottom of this email) I'm not sure if this is meant to emulate the null client configuration or be something else Anyway, I opened an issue for it in the Debian bug tracker http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738835 One particular thing I notice about all the configurations offered in Debian is that they all set mydestination using the hostname, e.g. mydestination = host1.example.org, localhost.example.org, host1, localhost instead of leaving mydestination blank. Is there any compelling reason to have these entries in mydestination? Are there other common applications (either in Debian or elsewhere) that are explicitly sending mail to root@$HOSTNAME or root@localhost rather than just the unqualified recipient name root for example? No configuration: Should be chosen to leave the current configuration unchanged. Internet site: Mail is sent and received directly using SMTP. Internet with smarthost: Mail is received directly using SMTP or by running a utility such as fetchmail. Outgoing mail is sent using a smarthost. Satellite system: All mail is sent to another machine, called a 'smarthost', for delivery. Local only: The only delivered mail is the mail for local users. There is no network. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738835: Satellite/null client settings
Package: postfix If somebody selects Satellite config, is this basically intended to setup like a null client? http://www.postfix.org/STANDARD_CONFIGURATION_README.html#null_client or should null client be offered as an additional menu option? I notice some differences between Satellite and what is suggested for a null client: a) Satellite sets my_destination=$HOSTNAME, $HOSTNAME.localhost, ... whereas I expected nothing in that field, e.g. my_destination= b) for any option, postinst is creating an aliases file, a null client shouldn't really need an aliases file and it could probably leave the alias_maps and alias_database blank c) for any option, postinst is adding an alias for root to the aliases file - for a null client, that shouldn't be required either -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738613: needs co-ordination with users
Package: libasio-dev Severity: serious Version: 1.10-1 This package is a build dependency for other packages and they are all likely to break with this new version Lets get a list of impacted packages and co-ordinate with maintainers The only package I know of personally is resiprocate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701659: testing again
travis-ci appears to have libasio-dev 1.4.8 now With commit r10959 in reSIProcate, I've enabled clang builds on travis-ci again, it should start building soon and then we can see if this issue is resolved -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738613: Fedora / EPEL
reSIProcate is also targetting Fedora and EPEL6. They are both carrying asio 1.4.x now We may need to contact the Fedora maintainer of asio-devel about whether he will include 1.10 in Fedora 21 and EPEL7, they will probably be released about the same time as jessie (or just a little bit before) This would make it much easier for users and upstreams to standardize on asio v1.10 if it is consistent on all Linux platforms -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738616: removing newer libasio-dev (v1.10) from unstable
Package: release.debian.org We would like the version of libasio-dev in unstable to revert to the version currently in testing (1.4.8-2) Can you please remove the v1.10.1-1 libasio-dev from unstable or let me know what action to take, e.g. should I upload a 1.4.8-3 package? Also, could you please comment on whether we should plan a transition for asio 1.10 to enter jessie? Markus is maintaining the package, reSIProcate is the only build dependency we know of and if there are no others then a formal transition probably isn't required. Is there an equivalent of apt-cache rdepends that can help us locate any other packages with a build dependency on libasio-dev? As it is a header library, no packages declare a runtime dependency on it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738616: removing newer libasio-dev (v1.10) from unstable
On 11/02/14 11:49, Julien Cristau wrote: On Tue, Feb 11, 2014 at 10:44:30 +0100, Daniel Pocock wrote: Package: release.debian.org We would like the version of libasio-dev in unstable to revert to the version currently in testing (1.4.8-2) You might want to explain why. API changes make it incompatible Fedora and EPEL still carry 1.4.8 which is widely used by dependencies such as those mentioned below Can you please remove the v1.10.1-1 libasio-dev from unstable or let me know what action to take, e.g. should I upload a 1.4.8-3 package? No, we can't do that. And you shouldn't do that. What you can do is use an epoch to make the version number go backwards. Ok, I will do that and upload later today Also, could you please comment on whether we should plan a transition for asio 1.10 to enter jessie? Markus is maintaining the package, reSIProcate is the only build dependency we know of and if there are no others then a formal transition probably isn't required. Is there an equivalent of apt-cache rdepends that can help us locate any other packages with a build dependency on libasio-dev? As it is a header library, no packages declare a runtime dependency on it. wget -qO- http://ftp.debian.org/debian/dists/sid/main/source/Sources.gz | zcat | grep-dctrl -FBuild-Depends -sPackage libasio-dev Adjusting for contrib and non-free left as an exercise for the reader. Thanks for that feedback Looks like the following three packages are impacted by this build dependency: src:abiword src:ball src:resiprocate All those packages need patching to work with the new version of asio due to API changes Does the release team have any preference for making this a formal transition or we should just work it out informally between the maintainers of these packages? Markus, please have a brief look at https://wiki.debian.org/Teams/ReleaseTeam/Transitions -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738616: removing newer libasio-dev (v1.10) from unstable
On 11/02/14 13:44, Markus Wanner wrote: On 02/11/2014 01:40 PM, Julien Cristau wrote: Please try to avoid versioned -dev packages. Unless you really really have to keep both versions around for years. Why is that? Keep in mind this is a headers-only library, i.e. it only ever ships with a -dev (and a -doc) package. There's no other way multiple versions of this library can be installed on a system. Julien, Fedora and EPEL6 still have 1.4.8 as well. We don't know how widely it is used in things that are not packaged (e.g. in private code that people run on Debian) If we release a versions libasio1.4-dev package and libasio1.10-dev concurrently in jessie it will mean people can transition more slowly but nothing will really break -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738616: removing newer libasio-dev (v1.10) from unstable
On 11/02/14 14:03, Julien Cristau wrote: On Tue, Feb 11, 2014 at 13:58:17 +0100, Daniel Pocock wrote: On 11/02/14 13:44, Markus Wanner wrote: On 02/11/2014 01:40 PM, Julien Cristau wrote: Please try to avoid versioned -dev packages. Unless you really really have to keep both versions around for years. Why is that? Keep in mind this is a headers-only library, i.e. it only ever ships with a -dev (and a -doc) package. There's no other way multiple versions of this library can be installed on a system. Julien, Fedora and EPEL6 still have 1.4.8 as well. We don't know how widely it is used in things that are not packaged (e.g. in private code that people run on Debian) That's irrelevant, as far as I'm concerned. Not exactly - upstreams may be less likely to adapt their code for v1.10 and that means we end up having to make more local patches or leaving things out of Debian However, I'll check with the Fedora maintainer for asio-devel, maybe Fedora 21 can carry v1.10 If we release a versions libasio1.4-dev package and libasio1.10-dev concurrently in jessie it will mean people can transition more slowly but nothing will really break And if you don't they can still use the old version, either through the old package or through an unpackaged local version. Shipping libraries in Debian only makes sense if Debian packages use them, IMO. At the moment, there are 3 proper packages using the old version of libasio-dev and none of the upstreams have shown enthusiasm for the new version My feeling is that abiword and reSIProcate will continue using libasio1.4-dev in jessie while any new project will hopefully start with libasio-dev 1.10 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738616: removing newer libasio-dev (v1.10) from unstable
On 11/02/14 15:26, Andreas Beckmann wrote: On 2014-02-11 13:10, Markus Wanner wrote: On 02/11/2014 01:01 PM, Andreas Beckmann wrote: Or if you want to avoid using epochs, reupload 1.4.8 using as 1.10.really.1.4.8 as the upstream version, and upload 1.10 as 1.10.release to experimental. Once you upload upstream 1.11 you are back to normal version numbers without having used an epoch inbetween. Given that we are likely to switch to separate libasio1.4-dev and libasio1.10-dev packages, I think the epoch approach is less confusing, overall. Since it seems you need to introduce libasio1.4-dev anyway, it should be possible to fix this version mess without .really. versions and without using epochs. All it needs is a trip through NEW. Let me know if I should look into preparing a patch ... I already made an upload using epoch It is 1:1.4.8-3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738616: removing newer libasio-dev (v1.10) from unstable
On 11/02/14 15:41, Daniel Pocock wrote: On 11/02/14 15:26, Andreas Beckmann wrote: On 2014-02-11 13:10, Markus Wanner wrote: On 02/11/2014 01:01 PM, Andreas Beckmann wrote: Or if you want to avoid using epochs, reupload 1.4.8 using as 1.10.really.1.4.8 as the upstream version, and upload 1.10 as 1.10.release to experimental. Once you upload upstream 1.11 you are back to normal version numbers without having used an epoch inbetween. Given that we are likely to switch to separate libasio1.4-dev and libasio1.10-dev packages, I think the epoch approach is less confusing, overall. Since it seems you need to introduce libasio1.4-dev anyway, it should be possible to fix this version mess without .really. versions and without using epochs. All it needs is a trip through NEW. Let me know if I should look into preparing a patch ... I already made an upload using epoch It is 1:1.4.8-3 I notice the upload hasn't actually built http://packages.qa.debian.org/a/asio.html reports that it is still 1.10.1-1 in unstable and no link to the build logs Has anybody else tried something else to deal with this package transition or reversion to 1.4.8? Or did I do something wrong when adding the epoch? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738616: removing newer libasio-dev (v1.10) from unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/02/14 22:18, Markus Wanner wrote: Daniel, On 02/11/2014 09:46 PM, Daniel Pocock wrote: Has anybody else tried something else to deal with this package transition or reversion to 1.4.8? Or did I do something wrong when adding the epoch? I think you did just fine, but PTS is lagging behind. See here: http://metadata.ftp-master.debian.org/changelogs/main/a/asio/asio_1.4.8-3_changelog I notice that everything seemed to fall into place shortly after sending that email - my reSIProcate packages are building now Does this allow us to close this bug? And at least degrade #738613 to non-serious? (Otherwise, your upload won't migrate to testing, either, I guess.) We should mark 738613 fixed in the new version I think On 02/11/2014 01:40 PM, Julien Cristau wrote: Please try to avoid versioned -dev packages. Unless you really really have to keep both versions around for years. Rethinking that, I agree. For effectively two debian packages (abiword and resiprocate, disregarding ball) that rely on libasio-dev, it's hardly worth the effort of maintaining two separate versions. The other point being that (this variant of) asio being a headers-only library doesn't change the fact that any -dev package is only used during a build, but not when running any program (binary). In other words, just like any other -dev package, an upgrade of it won't ever break a compiled binary. At the worst, it leads to an FTBFS (as 1.10.1 does for both, BTW). It is an awkward question - if the API change is mild and the new version is better in every way then killing of the old version (with enough time for a transition) is fair enough If there are any question marks over stability of the new version or if it is so much work that the packagers of resiprocate and abiword can't easily fix it, then the pain of keeping an old version libasio1.4-dev may be much less As a reSIProcate upstream, * We just released 1.9.0 with a dependency on asio 1.4.x * I'm happy to look at asio version for our 1.10.x release cycle. * only one part of reSIProcate uses asio, so I could also split the package upstream, reduce the scope for future conflicts like this -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJS+pWGAAoJEOm1uwJp1aqDITYQALlGaQpOyNJw3Vz3JtXd+us/ JDUBV94PZqhZSC4KVZeNSMY6n1jQufHpvbkVapXJDO4GgiCp4yWU/NtEVjCP07sl 8+YjJcLep783kI2YVkjm1Fo+6JeVXdQfE827663/h58jEX1U9Lk7bEhdM26u7VdQ n4JyY2GFS8BXO9sLAxopoo8xcT6RWW0GnZlvcjO0GuF1tXrLVII3BJBCCvxmSUkA MWu7FL6fUFI/JgGejQbiOl60i7GtlzCHlwlp0o3uBSvU1s6rQMoR+0J0Dbw9c5Og qi2mdF2N9dXeVA86EErWTvyobPcjI0Wg3uQSizIsLoK9uD79CKPqcA23bGfqie7x 5dv9ZOcY8Hpxm2S3V5UPmZvyKTNI4A6AbG1N+X2HnlUVK5++NkMsMb5QRW3y6oQ9 YD03EvFQfyAjIC8A1T4n0poTpxUM3rl9uyCqziZsEWOzbgjJaLOvwhsqAO7JHx3y sRFpSWn1J24blji270PJx4w/b3ZBD0zbXj6lhZDCNW9R3uqoVvxKwB5LyPlQKvTe bZ/z3/ZNByTlytlsN+ZVim9V3q/7tDsKqBL5QIqHcl1D+4ez5Nw9IPnE1iGtakBm l4Wx4JkYxfRdSLEgtXVZCWsD6Pte2Ftsj8eGKm8EwkdXmWjp5hW7Xm9XDbXMgrTT YKZ2l9NBfFqAdh6Ve8r+ =lMdP -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737760: provide: sip-router and recommend: turn-server
On 06/02/14 13:57, Victor Seva wrote: 2014-02-05 Daniel Pocock dan...@pocock.com.au: Package: kamailio Consider adding some variation of the following to the control file: Recommends: stun-server | turn-server I'm going to add this to Suggests. I don't think this relation belongs to Recommends. You can use the software without any of that. From [0] Suggests: This is used to declare that one package may be more useful with one or more others. Using this field tells the packaging system and the user that the listed packages are related to this one and can perhaps enhance its usefulness, but that installing this one without them is perfectly reasonable. Recommends This declares a strong, but not absolute, dependency. For WebRTC users, ICE is mandatory and therefore TURN becomes significant However, not everybody uses it for WebRTC, so it is really up to you The Recommends field should list packages that would be found together with this one in all but unusual installations. Provides: sip-router Ok. I wonder if we should declare sip-websocket-server or something like that too? Not all sip-router packages will provide WebSocket support -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737760: provide: sip-router and recommend: turn-server
Package: kamailio Consider adding some variation of the following to the control file: Recommends: stun-server | turn-server Provides: sip-router -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737763: provide: turn-server, stun-server and suggests: sip-router, xmpp-server
Package: rfc5766-turn-server Consider adding some variation of the following to the control file: Suggests: sip-router, xmpp-server Provides: stun-server, turn-server -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737762: provide: xmpp-server and recommend: turn-server
Package: ejabberd Consider adding some variation of the following to the control file: Recommends: stun-server | turn-server Provides: xmpp-server -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737761: provide: xmpp-server and recommend: turn-server
Package: prosody Consider adding some variation of the following to the control file: Recommends: stun-server | turn-server Provides: xmpp-server -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737764: provide: turn-server, stun-server and suggests: sip-router, xmpp-server
Package: turnserver Consider adding some variation of the following to the control file: Suggests: sip-router, xmpp-server Provides: stun-server, turn-server Maybe not stun-server though, because turnserver.org doesn't support legacy STUN -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737655: ITP: drupal7-mod-arbiter - ArbiterJS module for Drupal
Package: wnpp Severity: wishlist Owner: Daniel Pocock dan...@pocock.com.au Upstream: https://github.com/opentelecoms-org/drupal-mod-arbiterjs License: GPLv2 or greater A Drupal wrapper module for the ArbiterJS (libjs-arbiter) publish/subscribe framework. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737500: ITP: arbiterjs - client-side pub/sub JavaScript library
Package: wnpp Severity: wishlist Owner: Daniel Pocock dan...@pocock.com.au Upstream: http://arbiterjs.com License: MIT or GPL Allows pub/sub interaction (loose coupling) between JavaScript modules in a web page. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737559: copyright-format: author != copyright, add an author field?
Package: debian-policy Author and copyright holder are not always the same person/entity. E.g. the work may be authored by Bob but the copyright is assigned to his employer Acme, Inc, e.g. License: GPL2 Copyright: 2014, Acme, Inc http://acme.example.org Author: Bob, http://example.org/bob For cases where the License field contains the value public-domain and the name of the author is known, it is not appropriate to put the name in the license field, but it would be desirable to record the name of the author, e.g. License: public-domain Copyright: none Author: Bob, http://example.org/bob This may also reflect real-life situations where contributor license agreements require contributors to completely assign their intellectual property to some organisation (such as FSF) http://www.gnu.org/licenses/gpl-faq.html#AssignCopyright Has this not already come up anywhere? I found a related bug that deals with part of the issue (must insert none in the Copyright field of public-domain) but that is not the whole issue, maybe they can be resolved together http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694883 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737559: copyright-format: author != copyright, add an author field?
On 03/02/14 20:17, Jonathan Nieder wrote: severity 737559 wishlist user debian-pol...@packages.debian.org usertags 737559 = normative issue quit Hi Daniel, Daniel Pocock wrote: Author and copyright holder are not always the same person/entity. [...] License: GPL2 Copyright: 2014, Acme, Inc http://acme.example.org Author: Bob, http://example.org/bob Sure. A few thoughts: - I don't think debian/copyright needs to list everyone who contributed to the code --- to me, the copyright holders and some contact information for upstream seem more important, and the detailed authorship information can go elsewhere (e.g., a README or THANKS file, or the changelog). But policy's more ambiguous about that. See http://bugs.debian.org/678607. - The above is already valid syntax, since custom fields can be added to any paragraph. Feel free to try it and let us know how it goes. (copyright-format sayeth: No prefixing is necessary or desired, but please avoid names similar to standard ones so that mistakes are easier to catch. Future versions of the debian/copyright specification will attempt to avoid conflicting specifications for widely used extra fields. ) - Response when this last came up[1]: This is nice in spirit, but I would personnally not feel like maintaining a contributor list, because there is mostly only blame to get in case it is inaccurate, so I would only use the field to point at a contributors file. Just to clarify, I do not believe that maintaining this field should be obligatory It should be an optional field Defining it formally in the standard and having some examples will help emphasize the difference between what people should put in the Copyright field and what should not be there. If a maintainer feels that some author is particularly noteworthy or deserving, then they can put that author's name in the field even if the author has no entitlement to appear in the copyright field. This is the kind of field that I would prefer to see tested in real life before being standardised in DEP-5. So, I think this is a reasonable idea, and if more than two or so packages start using the field then it's probably worth documenting in policy to allow tools to start to consume it if they like. Thanks, Jonathan [1] https://lists.debian.org/debian-project/2010/07/msg00088.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737559: copyright-format: author != copyright, add an author field?
On 03/02/14 20:36, Jonathan Nieder wrote: Daniel Pocock wrote: Just to clarify, I do not believe that maintaining this field should be obligatory It should be an optional field Defining it formally in the standard and having some examples will help emphasize the difference between what people should put in the Copyright field and what should not be there. If a maintainer feels that some author is particularly noteworthy or deserving, then they can put that author's name in the field even if the author has no entitlement to appear in the copyright field. Yes, I understood that. Which is why I wrote On 03/02/14 20:17, Jonathan Nieder wrote: So, I think this is a reasonable idea, and if more than two or so packages start using the field then it's probably worth documenting in policy to allow tools to start to consume it if they like. Do you think this should be documented before people try it out and figure out what kind of values make sense for the field? I would be less excited about that, but I'm not opposed to it. My thoughts would then be - If possible, please find someone else to weigh in on how this is useful to them (e.g., do they have an example copyright file which it makes cleaner?). - I suspect 'Authors' is not a good name for this field. The word is too tightly tied to copyright, 'rights of the author', legal authorship, and so on. Something like 'Contributors' should be fine, though. The actual word that is chosen is not so important for me - Have you been using this field in your packages? If not, is policy getting in the way of that? (That would be a more serious bug and worth addressing first as a stopgap.) I've only come across one package which included public-domain material so far. In this case, I put a note about the author in the comments. It is not a blocking issue for me. One risk of not having this extra field is that we could accumulate excessive things in the Copyright field. E.g. some packagers may be including the names of contributors as if they are copyright holders because they are afraid their package will be queried (and subsequently delayed) by the FTP masters if they left something out by mistake. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
