Bug#760034: fonts-dkg-handwriting: Please add U+1F35C (STEAMING BOWL)
Package: fonts-dkg-handwriting Version: 0.15-1 Severity: wishlist Please add support for U+1F35C (STEAMING BOWL) in this font. It is currently unavailable in any of the fonts provided by Debian. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (500, 'testing-updates'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash fonts-dkg-handwriting depends on no packages. Versions of packages fonts-dkg-handwriting recommends: ii fontconfig 2.11.0-6 fonts-dkg-handwriting suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766089: python-zbar: Please include fix for Python GIL support, allowing asynchronous scanning
Package: python-zbar
Version: 0.10+doc-10
Severity: wishlist
Tags: upstream patch
As discussed in http://sourceforge.net/p/zbar/bugs/48/ the Python
bindings for zbar do not support threading, meaning it's not possible to
build multithreaded Python tools supporting asynchronous scanning. There
is an upstream fix at:
http://sourceforge.net/p/zbar/code/ci/1c14e19910e96fe132897db8343b24179265f3ef
which I have added on top of the zbar 0.10+doc-9 package and confirmed
fixes the issue I see; I attach it to this bug report as well (I dropped
it in debian/patches/ and added it to debian/patches/series for
building).
Please consider including this fix with the next package upload. Thanks.
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (900, 'testing'), (800, 'unstable'), (500, 'testing-updates'),
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.17.0+ (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages python-zbar depends on:
ii libc6 2.19-11
ii libjpeg8 8d1-2
ii libv4l-0 1.6.0-1+b1
ii libzbar0 0.10+doc-10
ii python2.7.8-1
python-zbar recommends no packages.
python-zbar suggests no packages.
-- no debconf information
--- a/python/processor.c 2009-10-23 19:16:44.0 +0100
+++ b/python/processor.c 2014-07-29 18:22:52.706154561 +0100
@@ -36,15 +36,24 @@
PyObject *args,
PyObject *kwds)
{
-static char *kwlist[] = { NULL };
-if(!PyArg_ParseTupleAndKeywords(args, kwds, "", kwlist))
+static char *kwlist[] = { "enable_threads", NULL };
+int threaded = -1;
+if(!PyArg_ParseTupleAndKeywords(args, kwds, "|O&", kwlist,
+object_to_bool, &threaded))
+return(NULL);
+
+#ifndef WITH_THREAD
+if(threaded > 0 &&
+ PyErr_WarnEx(NULL, "threading requested but not available", 1))
return(NULL);
+threaded = 0;
+#endif
zbarProcessor *self = (zbarProcessor*)type->tp_alloc(type, 0);
if(!self)
return(NULL);
-self->zproc = zbar_processor_create(0/*FIXME*/);
+self->zproc = zbar_processor_create(threaded);
zbar_processor_set_userdata(self->zproc, self);
if(!self->zproc) {
Py_DECREF(self);
@@ -228,7 +237,11 @@
object_to_timeout, &timeout))
return(NULL);
-int rc = zbar_processor_user_wait(self->zproc, timeout);
+int rc = -1;
+Py_BEGIN_ALLOW_THREADS
+rc = zbar_processor_user_wait(self->zproc, timeout);
+Py_END_ALLOW_THREADS
+
if(rc < 0)
return(zbarErr_Set((PyObject*)self));
return(PyInt_FromLong(rc));
@@ -245,7 +258,11 @@
object_to_timeout, &timeout))
return(NULL);
-int rc = zbar_process_one(self->zproc, timeout);
+int rc = -1;
+Py_BEGIN_ALLOW_THREADS
+rc = zbar_process_one(self->zproc, timeout);
+Py_END_ALLOW_THREADS
+
if(rc < 0)
return(zbarErr_Set((PyObject*)self));
return(PyInt_FromLong(rc));
@@ -265,7 +282,11 @@
if(zbarImage_validate(img))
return(NULL);
-int n = zbar_process_image(self->zproc, img->zimg);
+int n = -1;
+Py_BEGIN_ALLOW_THREADS
+n = zbar_process_image(self->zproc, img->zimg);
+Py_END_ALLOW_THREADS
+
if(n < 0)
return(zbarErr_Set((PyObject*)self));
return(PyInt_FromLong(n));
@@ -275,6 +296,9 @@
process_handler (zbar_image_t *zimg,
const void *userdata)
{
+PyGILState_STATE gstate;
+gstate = PyGILState_Ensure();
+
zbarProcessor *self = (zbarProcessor*)userdata;
assert(self);
assert(self->handler);
@@ -285,7 +309,7 @@
img = zbarImage_FromImage(zimg);
if(!img) {
PyErr_NoMemory();
-return;
+goto done;
}
}
else
@@ -299,8 +323,17 @@
PyTuple_SET_ITEM(args, 2, self->closure);
PyObject *junk = PyObject_Call(self->handler, args, NULL);
-Py_XDECREF(junk);
+if(junk)
+Py_DECREF(junk);
+else {
+PySys_WriteStderr("in ZBar Processor data_handler:\n");
+assert(PyErr_Occurred());
+PyErr_Print();
+}
Py_DECREF(args);
+
+done:
+PyGILState_Release(gstate);
}
static PyObject*
Bug#817837: l2tpns: *** buffer overflow detected ***: l2tpns terminated
On Thu, Mar 10, 2016 at 07:50:22PM +, Dave Reeve wrote: > Running l2tpns causes an instance crash as follows: > > # l2tpns -v > *** buffer overflow detected ***: l2tpns terminated > (full trace removed as it doesn't help) > > The problem exists in the ring buffer logging code. Specially the vsprintf > is called with a length of 4095 when the size of the buffer is MAX_LOG_LENGTH > (defined as 512 in l2tpns.h). The result is that as soon as the program is > executed it crashes as soon as a few log messages are printed. The following > patch resolves the problem. > > I also have some more minor fixes, which resolve compiler warnings. I > am happy to share these if you let me know where to send them! Upstream these days is at http://git.sameswireless.fr/l2tpns.git and I note Fernando has been maintaining Debian packaging. As I haven't been using l2tpns for some time I have emailed him asking if he would like to take over maintenance of the package in Debian. It's probably best to send fixes directly upstream. J. -- /-\ | Do I BELIEVE in the Bible?! Hell, |@/ Debian GNU/Linux Developer |man I've SEEN one!!! \- |
Bug#818111: noise in the noise source package creation step
On Mon, Mar 21, 2016 at 09:31:56PM +, Niels Thykier wrote: > Here is a patch that rewrites d/rules to a dh-based build, assuming you > are still interested in it. :) Cool, I think we probably are - I can't see a reason not to switch over. > A couple of remarks: > > * It also rewrites the dpkg-parsechangelog to use the -S parameter >(available since dpkg/1.17.0). If you need to backport the package >to oldstable systems, you may want to undo that change. We don't in general do backports, and even if we did I can't see us targeting older than stable, so this isn't a problem. > * The test suite failed, so I simply omitted running it like the >previous build did. OOI, what failed? It's passing here for me. J. -- Purple alert! Purple alert! - Holly This .sig brought to you by the letter L and the number 25 Product of the Republic of HuggieTag signature.asc Description: Digital signature
Bug#818111: noise in the noise source package creation step
On Mon, Mar 21, 2016 at 10:23:34PM +, Niels Thykier wrote: > The failure looked something like this: > > > $ dh_auto_test > > make -j1 test > > ./runtests > > awk: not an option: --assign .. > NB: I ran it in an "almost" clean sid chroot: > * awk happened to be implemented by mawk (which is what >debootsrap/pbuilder/something picked for me when I created the sid >chroot a long time ago) Ah, that'll be it then. I'll switch the option to the POSIX-style short -v. J. -- In God we trust; all else we walk through. This .sig brought to you by the letter T and the number 41 Product of the Republic of HuggieTag signature.asc Description: Digital signature
Bug#818973: python-imdbpy: Retrieval of top250 listing returns empty list
Package: python-imdbpy Version: 5.0-1 Severity: normal Tags: patch upstream The get_top250_movies() function is returning an empty list for me. This is upstream issue BB #46 (I can't find a link to this report though) and is fixed in commit 9fe25d701ddeef51cc00de4fd900193f8bb97134 - as seen at: https://github.com/alberanid/imdbpy/commit/9fe25d701ddeef51cc00de4fd900193f8bb97134 I've confirmed applying this patch to the Debian package makes the function work for me. J. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (900, 'testing'), (500, 'testing-updates'), (500, 'testing-proposed-updates'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.6 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python-imdbpy depends on: ii libc6 2.22-3 ii python 2.7.11-1 Versions of packages python-imdbpy recommends: ii python-lxml 3.5.0-1+b1 Versions of packages python-imdbpy suggests: ii python-sqlalchemy 1.0.12+ds1-1 pn python-sqlobject -- no debconf information
Bug#824136: libjaylink status?
It looks like 0.1.0 was released in December 2016. I'd like to get this into Debian as it's a dependency for OpenOCD 0.10.0; any plans to do so or can I pick up and update the git repo on Alioth myself? J. -- /-\ | I've got a trigger inside. |@/ Debian GNU/Linux Developer | \- |
Bug#853010: Interested in taking over
There has been various discussion at DebConf about getting OpenOCD updated and given some love; I am working on doing so. I've emailed Uwe but it seems it's up to Luca whether he'd like help or not. Luca, can you speak up? J. -- ... If I save time, when do I get it back?
Bug#871172: Uploading pending on dependencies
Just as a piece of additional information I have an updated Pulseview 0.4 pending which fixes the FTBFS + does various other cleanups. Its upload is pending on acceptance of updated libsigrok + libsigrokdecode packages, both of which are currently sitting in NEW. J. -- ... Sunday morning is every day for all I care... and I'm not scared.
Bug#873717: collectd: FTBFS with libsigrok4
Package: collectd Version: 5.7.2-1 Tags: upstream I have recently uploaded an up-to-date version of libsigrok to experimental, which bumps the library soname to 4. The only package that's not part of the sigrok suite which depends on libsigrok is collectd. However a simple attempt to rebuild against the updated library failed as the configure script checks to ensure the version is < 0.4. Removing this check unsurprisingly resulted in a build failure due to changes in the libsigrok API. Upstream are tracking this at: https://github.com/collectd/collectd/issues/1574 but there's been no progress in over a year. I may have time to investigate in a few weeks if no one gets there first, but no promises. J. -- /-\ |If I want to hear the pitter |@/ Debian GNU/Linux Developer | patter of little feet, I'll put \- | shoes on my cats.
Bug#840591: Updating fonts-symbola
Now that stretch has released and we're out of freeze do you have any plans to update ttf-ancient-fonts? It'd be nice to have the Unicode 9 support available. I can prepare an NMU if you're lacking time at present. J. -- ] http://www.earth.li/~noodles/ [] Every bug you find is the last one. [ ] PGP/GPG Key @ the.earth.li [] [ ] via keyserver, web or email. [] [ ] RSA: 4096/0x94FA372B2DA8B985 [] [
Bug#817837: closed by Jonathan McDowell (Bug#817837: fixed in l2tpns 2.2.1-2)
On Thu, May 25, 2017 at 06:54:53PM +0300, Adrian Bunk wrote: > On Thu, May 18, 2017 at 08:02:49PM +0100, Jonathan McDowell wrote: > > On Sun, May 14, 2017 at 09:15:50PM +0300, Adrian Bunk wrote: > > > On Tue, Jul 05, 2016 at 10:09:57AM +, Debian Bug Tracking System > > > wrote: > > > >... > > > > l2tpns (2.2.1-2) unstable; urgency=low > > > > . > > > >* Fix log buffer overrun, thanks to Dave Reeve (closes: #817837) > > > >... > > > > > > Hi Jonathan, > > > > > > thanks a lot for fixing this bug for stretch. > > > > > > It is still present in jessie, could you also fix it there? > > > Alternatively, I can fix it for jessie if you don't object. > > > > I had avoided fixing it on jessie because it wasn't clear to me it would > > be permitted by the stable-release masters, > > It looks like a rightfully RC bug to me and has a one-line fix. > > > and there had been little > > indication there was active use of the package (I'm planning to have it > > removed post stretch as no one has stepped up to my intent to orphan > > it). If you want to take the package over entirely you're more than > > welcome to do so. > > I am just going through RC bugs in jessie, trying to fix some of them. > > According to popcon l2tpns has some users left. Feel free to go for it then. > If you want to get rid of the package, it would be perfectly fine if > you retitle the RFA to O to make it clear that you do no longer want > to be responsible for l2tpns and that QA should maintain it instead. That's been the plan once stretch released, or a complete removal request. J. -- "Commercial IP providers are writing 'Halloween' documents about our development model" -- opencores.org third phase goal.
Bug#840591: Updating fonts-symbola
On Fri, Jun 30, 2017 at 03:22:58PM +0200, Gürkan Myczko wrote: > Yes well I have something to get sponsored at > http://sid.ethz.ch/debian/fonts-ancient-fonts/2.59/ I don't know if pkg-fonts-devel have some sort of sponsorship regime, but if not I'm prepared to do this if the minor Lintian issues can be cleaned up as well. > I prefer irc, my nickname is tarzeau I'm on OFTC as Noodles. > > On 30 Jun 2017, at 10:36, Jonathan McDowell wrote: > > > > Now that stretch has released and we're out of freeze do you have any > > plans to update ttf-ancient-fonts? It'd be nice to have the Unicode 9 > > support available. I can prepare an NMU if you're lacking time at > > present. J. -- ] http://www.earth.li/~noodles/ [] "evilwm - we sold our souls to the [ ] PGP/GPG Key @ the.earth.li [] window manager" -- [ ] via keyserver, web or email. [] http://www.6809.org.uk/evilwm/[ ] RSA: 4096/0x94FA372B2DA8B985 [] [ signature.asc Description: Digital signature
Bug#873717: Acknowledgement (collectd: FTBFS with libsigrok4)
Control: forwarded 873717 https://github.com/collectd/collectd/issues/1574 Control: tags 873717 + patch I've produced a compile-tested patch and associated it with the upstream bug report. As I lack any analog sigrok hardware I'm unable to test it myself. However I'm going to upload the new sigrok packages over the next few days which will lead to collectd being FTBFS in unstable. J. -- Web [ I just Fedexed my soul to hell. I'm *real* clever. ] site: http:// [ ] Made by www.earth.li/~noodles/ [ ] HuggieTag 0.0.24
Bug#876167: libglibmm-2.4-dev: Please update to 2.54.1 to remove C++14 requirement
Package: libglibmm-2.4-dev Version: 2.54.0-1 Severity: important Tags: upstream I have just tried to prepare a new upload of Pulseview to unstable only to have it fail with: In file included from /usr/include/glibmm-2.4/glibmm/containerhandle_shared.h:23:0, from /usr/include/glibmm-2.4/glibmm/arrayhandle.h:21, from /usr/include/glibmm-2.4/glibmm.h:92, from /usr/include/libsigrokcxx/libsigrokcxx.hpp:78, from /<>/main.cpp:25: /usr/include/glibmm-2.4/glibmm/variant.h:2012:24: error: 'std::index_sequence' has not been declared std::index_sequence) ^~ It turns out this is due to the update of glibmm2.4 to 2.54.0 in unstable, and its use of std::index_sequence which is only available from C++14 onwards. I note that upstream released 2.54.1 yesterday which includes a fix to not require C++14 (https://mail.gnome.org/archives/gnome-announce-list/2017-September/msg00019.html). Please can you get the version in unstable updated to include at least this fix as I suspect the C++14 requirement will cause more than just Pulseview to FTBFS. Thanks, J. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (500, 'stable-updates'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.2 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libglibmm-2.4-dev depends on: ii libglib2.0-dev 2.54.0-1 ii libglibmm-2.4-1v5 2.50.1-1 ii libsigc++-2.0-dev 2.10.0-1 ii pkg-config 0.29-4+b1 libglibmm-2.4-dev recommends no packages. Versions of packages libglibmm-2.4-dev suggests: pn libglibmm-2.4-doc pn libgtkmm-3.0-dev -- no debconf information
Bug#763822: Moving towards buildinfo on the archive network
Having been impressed by the current status of reproducible builds and the fact it looks like we're close to having the important pieces in Debian proper, I have started to have a look at how I could help out with this bug. I've done some poking around in the dak code, and think I have a vague idea of how to achieve what I think is wanted. First, it is helpful to describe what I think is wanted. What I think we need is the archive network to have, alongside the binary packages it contains, details of exactly how to build those binaries. This is, I believe, the information contained in the .buildinfo files. This bug has previously talked about a tarball of .buildinfo files, presented as Buildinfos.tgz alongside the Packages file. From looking at the current architecture of dak I do not believe that this is an easy option. I propose instead a Buildinfo.xz (or gz or whatever) file, which is single text file with containing all of the buildinfo information that corresponds to the Packages list. What is lost by this approach are the OpenPGP signatures that .buildinfo files can have on them. I appreciate this is an important part of the reproducible builds aim, but I believe one of its strengths is the ability for multiple separate package builds to attest that they have used that buildinfo information to build the exact same set of binary artefacts. This is not something that easily scales on the archive network and I think it is better served by a separate service; it would be possible to take the package snippet from the buildinfo file and sign that alone, uploading the signature to the attestation service. For "normal" Debian operation the usual archive signatures would provide a basic level of attestation of chain of build information. The rest of this mail continues on the above assumptions. If you do not agree with the above the below is probably null and void, so ignore it and instead educate me about what the requirements are and I'll try and adjust my ideas based on that. So. If a single Buildinfo.xz file is acceptable, with the attestation being elsewhere, I think this is doable without too much hackery in dak. There are some trade-offs to make though, and I need to check which are acceptable and which are viewed as too much. Firstly, there is currently no concept of "build ids" that I can see; essentially the primary key for a build is (source-package, architecture, version). This assumes we never have the same version of a package with different binaries produced; I understand there is sometimes skew between security + the main archive but it's not clear to me if this will continue to be the case when we're doing things reproducibly. Even if it's not adding a simple build id doesn't actually help AFAICT. Secondly, buildinfo files that I've seen so far include arch all .debs with the architecture .debs. I believe on the archive these should be separate; so a build + upload that includes arch all + arch amd64 (for example) debs will actually end up with an entry (for just the all debs) in the all Buildinfo.xz and an entry (for just the amd64 debs) in the amd64 Buildinfo.xz. Why? Binary NMUs, which don't rebuild the all .debs. Otherwise you end up changing the buildinfo information (to drop the rebuild amd64 debs) or keeping around old buildinfo information (+ you have to track the fact you need it and know when to clean it up). Thirdly, as the information is generated from a database, there needs to be a defined order in which the fields are generated. This is purely to ensure that the buildinfo information for each package is generated in a reproducible fashion so any external signatures remain valid over time. If these are acceptable I think that projectb needs 2 additional tables, buildinfo_keys, similar to metadata_keys, and binaries_buildinfo, which would have a 3 column primary key of (source-package, architecture, version), and then key_id/value fields (similar to binaries_metadata) to hold the buildinfo information that is not already present elsewhere in the database. At present the main information these will hold is Installed-Build-Depends field - the rest that I've actively seen are available already. Have I missed anything? I don't think the code to implement the above ends up particularly complex in dak, and the resulting Buildinfo.xz files should not add a particularly large amount of new data to the mirror network. The main loss is that of the attestation information as part of the mirror network (and actually, I can see a way we could add that as a buildinfo field that wasn't part of the signature at some point in the future). (Additionally it is not clear to me where the dpkg status for buildinfo creation is; I have heard that it's close to happening, but I can't find anything on recent list archives about it - pointers appreciated!) J. -- /-\ | I get the feeling that I've been |@/ Debian GNU/Linux Developer | cheated. \-
Bug#833306: debian-keyring: duplicated key 0xAFA51BD6CDE573CB
On Tue, Aug 02, 2016 at 06:52:39PM +0100, Alessandro Ghedini wrote: > it appears that my key has been included twice in the debian-keyring.gpg as > shipped in the debian-keyring package: > > % gpg2 --no-default-keyring --keyring /usr/share/keyrings/debian-keyring.gpg > --list-keys gh...@debian.org > pub rsa4096/AFA51BD6CDE573CB 2010-10-29 [SC] > uid [ unknown] Alessandro Ghedini > uid [ unknown] Alessandro Ghedini > uid [ unknown] Alessandro Ghedini > sub rsa4096/386B706D9A7BDF04 2010-10-29 [E] > sub ed25519/1730268A0D03529E 2015-09-23 [A] > sub rsa2048/8481A825D63CF092 2015-09-23 [A] > sub rsa4096/6F0CCBE021624728 2016-06-20 [S] > > pub rsa4096/AFA51BD6CDE573CB 2010-10-29 [SC] > uid [ unknown] Alessandro Ghedini > uid [ unknown] Alessandro Ghedini > uid [ unknown] Alessandro Ghedini > sub rsa4096/386B706D9A7BDF04 2010-10-29 [E] > sub ed25519/1730268A0D03529E 2015-09-23 [A] > sub rsa2048/8481A825D63CF092 2015-09-23 [A] It looks like this happened in commit 8ed91f0fb3c287f95d4fbece22e8edbd57212786 (importing changes sent to the HKP interface on keyring.debian.org). The previous commit affecting this key was 15a31d23030fc233f70652784a8fc67e293c54b8, which again was an HKP import that happened to add the ECC subkey to your key. My suspicion is that something has broken with this resulting in the duplication of the key (we had issues with multiple copies of the same ECC subkey before it was fixed by gpg upstream), and once that happened a simple update of the key doesn't result in it getting cleaned up. Simple enough to do before we do our next push. J. -- ] http://www.earth.li/~noodles/ [] 101 things you can't have too much [ ] PGP/GPG Key @ the.earth.li [] of : 12 - Volume. [ ] via keyserver, web or email. [] [ ] RSA: 4096/0x94FA372B2DA8B985 [] [ signature.asc Description: Digital signature
Bug#853163: Leaves stale device-mapper entry
Package: os-prober Version: 1.73 Severity: important While purging an old kernel from my stretch machine today I saw a lot of errors being output at the end when the Grub config was being updated: Generating grub configuration file ... Found background image: /usr/share/images/desktop-base/desktop-grub.png Found linux image: /boot/vmlinuz-4.9.0-1-amd64 Found initrd image: /boot/initrd.img-4.9.0-1-amd64 device-mapper: remove ioctl on osprober-linux-sda2 failed: Device or resource busy Command failed WARNING: Not using lvmetad because duplicate PVs were found. WARNING: Use multipath or vgimportclone to resolve duplicate PVs? WARNING: After duplicates are resolved, run "pvscan --cache" to enable lvmetad. WARNING: PV cU7LfS-Hy15-lqhf-BBlB-b6HB-mxuG-Cij5Pu on /dev/mapper/osprober-linux-sda2 was already found on /dev/sda2. WARNING: PV cU7LfS-Hy15-lqhf-BBlB-b6HB-mxuG-Cij5Pu prefers device /dev/sda2 because device is used by LV. (Warnings repeated many times) lvm continued to be unhappy after the "apt purge" had finished until I did a "dmsetup remove osprober-linux-sda2". -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages os-prober depends on: ii dmsetup 2:1.02.137-1 ii grub-common 2.02~beta3-3 ii libc62.24-8 os-prober recommends no packages. os-prober suggests no packages. -- no debconf information
Bug#811960: pulseview NMU?
On Mon, Nov 07, 2016 at 11:55:13PM +0100, Uwe Hermann wrote: > On Mon, Nov 07, 2016 at 04:25:14PM +0000, Jonathan McDowell wrote: > > Uwe, do you have any plans for this? > > Yeah, might upload some new packages soonish, but long-term > I'd be happy to hand over the full sigrok suite of packages to another > interested + active developer, so I can focus more on upstream development. Sorry for the delay in a reply; I've been kicking around thoughts about the best response. I am interested in having up to date tools such as the sigrok suite in Debian, but don't use them enough to be able to justify taking over maintainership. I'd like to help out where possible though. I was wondering if perhaps some sort of team maintenance would be appropriate for these sorts of tools (and maybe things like openocd as well) - there's the existing pkg-electronics-devel (cc'd) that might be a suitable home? I'd be prepared to try and help keep up to date with upstream releases in such an environment. J. -- /-\ | Design a system any fool can use, |@/ Debian GNU/Linux Developer | and only a fool will want to use \- | it. signature.asc Description: Digital signature
Bug#840498: Please package new upstream (2.2.1)
Source: daq Version: 2.0.4-3 Severity: wishlist There is a new upstream daq version, 2.2.1, which is required to compile snort++ (snort3) from build 214 onwards. Please consider updating the version available in Debian to this one. Thanks, J. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#840498: Patch to update to 2.2.1
Control: tags 840498 + patch
In case it's helpful, here's the patch I'm using locally to update from
2.0.4 to 2.2.1.
J.
--
/-\ | How I wish, how I wish you were
|@/ Debian GNU/Linux Developer |here.
\- |
diff -ruN old/debian/changelog new/debian/changelog
--- old/debian/changelog 2014-10-25 22:20:22.0 +0100
+++ new/debian/changelog 2016-10-12 09:53:01.0 +0100
@@ -1,3 +1,15 @@
+daq (2.2.1-1) unstable; urgency=medium
+
+ * New upstream release
+ * debian/control:
+ - Rename libdaq2 -> libdaq4
+ - Update Standards version, no changes required
+ - Add build-dep on libnetfilter-queue-dev to enable NFQ DAQ
+ - Add Multi-Arch: same for libdaq4
+ * debian/compat: Move to debhelper compat level 9
+
+ -- Jonathan McDowell Wed, 12 Oct 2016 09:53:01 +0100
+
daq (2.0.4-3) unstable; urgency=high
* debian/control:
diff -ruN old/debian/compat new/debian/compat
--- old/debian/compat 2010-11-10 23:52:29.0 +
+++ new/debian/compat 2016-10-12 09:53:01.0 +0100
@@ -1 +1 @@
-7
+9
diff -ruN old/debian/control new/debian/control
--- old/debian/control 2014-10-25 22:20:27.0 +0100
+++ new/debian/control 2016-10-12 09:53:01.0 +0100
@@ -1,32 +1,34 @@
Source: daq
Priority: extra
Maintainer: Javier Fernandez-Sanguino Peña
-Build-Depends: debhelper (>= 7.0.50~), dh-autoreconf, libpcap0.8-dev, flex, bison
-Standards-Version: 3.9.6
+Build-Depends: debhelper (>= 9), dh-autoreconf, libpcap0.8-dev, flex, bison,
+ libnetfilter-queue-dev
+Standards-Version: 3.9.8
Section: libs
Homepage: https://www.snort.org/downloads/
Package: libdaq-dev
Section: libdevel
Architecture: any
-Depends: libdaq2 (= ${binary:Version})
+Depends: libdaq4 (= ${binary:Version}), ${misc:Depends}
Description: Data Acquisition library for packet I/O - development files
DAQ is a library that introduces an abstraction layer to PCAP functions
- facilitation operation in a variety of hardware and software interfaces.
+ facilitation operation in a variety of hardware and software interfaces.
.
It was written for Snort but it may be useful to other packet processing
applicatons.
.
This package contains the static library and the C header files.
-Package: libdaq2
+Package: libdaq4
Section: libs
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
+Multi-Arch: same
Conflicts: libdaq0
Description: Data Acquisition library for packet I/O - shared library
DAQ is a library that introduces an abstraction layer to PCAP functions
- facilitation operation in a variety of hardware and software interfaces.
+ facilitation operation in a variety of hardware and software interfaces.
.
It was written for Snort but it may be useful to other packet processing
applicatons.
diff -ruN old/debian/libdaq2.dirs new/debian/libdaq2.dirs
--- old/debian/libdaq2.dirs 2010-11-10 23:52:29.0 +
+++ new/debian/libdaq2.dirs 1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-usr/lib
diff -ruN old/debian/libdaq2.install new/debian/libdaq2.install
--- old/debian/libdaq2.install 2010-11-10 23:52:29.0 +
+++ new/debian/libdaq2.install 1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-usr/lib/lib*.so.*
diff -ruN old/debian/libdaq4.install new/debian/libdaq4.install
--- old/debian/libdaq4.install 1970-01-01 01:00:00.0 +0100
+++ new/debian/libdaq4.install 2016-10-12 09:53:01.0 +0100
@@ -0,0 +1 @@
+usr/lib/*/lib*.so.*
diff -ruN old/debian/libdaq-dev.dirs new/debian/libdaq-dev.dirs
--- old/debian/libdaq-dev.dirs 2010-11-11 01:17:53.0 +
+++ new/debian/libdaq-dev.dirs 1970-01-01 01:00:00.0 +0100
@@ -1,3 +0,0 @@
-usr/bin
-usr/lib
-usr/include
diff -ruN old/debian/libdaq-dev.install new/debian/libdaq-dev.install
--- old/debian/libdaq-dev.install 2014-10-24 22:26:59.0 +0100
+++ new/debian/libdaq-dev.install 2016-10-12 09:53:01.0 +0100
@@ -1,4 +1,4 @@
usr/bin/*
usr/include/*
-usr/lib/lib*.a
-usr/lib/lib*.so
+usr/lib/*/lib*.a
+usr/lib/*/lib*.so
Bug#597677: Use new NM wizard to resume application
These applications have all been stalled for a few years. If they are resumed this should be done via the new style process at: https://nm.debian.org/wizard/ Closing these bugs. J. -- ] http://www.earth.li/~noodles/ [] I plead contemporary insanity.[ ] PGP/GPG Key @ the.earth.li [] [ ] via keyserver, web or email. [] [ ] RSA: 4096/0x94FA372B2DA8B985 [] [ signature.asc Description: Digital signature
Bug#763822: [Reproducible-builds] Moving towards buildinfo on the archive network
On Sat, Aug 20, 2016 at 03:13:00PM +, Ximin Luo wrote: > Jonathan McDowell: > > Having been impressed by the current status of reproducible builds > > and the fact it looks like we're close to having the important > > pieces in Debian proper, I have started to have a look at how I > > could help out with this bug. I've done some poking around in the > > dak code, and think I have a vague idea of how to achieve what I > > think is wanted. > > > > First, it is helpful to describe what I think is wanted. What I > > think we need is the archive network to have, alongside the binary > > packages it contains, details of exactly how to build those > > binaries. This is, I believe, the information contained in the > > .buildinfo files. > > > In our newest discussions, this purpose is secondary. The primary > purpose of buildinfo files is to record what *one particular builder > actually did in order to produce some output*. Or, equivalently: > > | A buildinfo file, abstractly, is a *claim* C by some builder entity B that > | "I executed process P with env/input I to produce output results R". > > This latter form is slightly easier to reason about, in terms of > security properties. We securely bind the claim C (the contents of the > buildinfo file) to the entity B using a cryptographic signature. I think the problem here is it's not clear (on either side) who "we" or "our" means. Different people want different things from reproducible builds, or have different opinions about relative priorities. As a *minimum* I think distributions should be providing the information of how a particular binary was produced. I suppose what it sort of maps to is "I executed process P with env/input I to produce output results R" (though, of course, distros already provide R; that's the binaries shipped). You've used all the letters I might want to refer to it by, so let's call it Z. The claim, C, is a signature over Z by B. It's useful extra information, but it's not required for me to ensure that the source I have build the binaries I have. > Note that the builder is a *distinct entity* from the distribution. > It's important to keep the *original* signature by B on C. It breaks > our security logic, to strip the signature and re-sign C using (e.g.) > the Debian archive release keys - because the entity in charge of this > release key is not the one that actually performed the build. Doing > this, would allow malicious builders to re-attribute their misdeeds to > look like it's the fault of Debian. Debian already does this in the context of the fact that Package files etc are signed by the archive key. It's possible to go and grab the .dsc file to see who did the file build, but day-to-day no one is using these to verify the binaries they receive. I care more that Debian stands behind the packages I download than being able to verify individually who build each of the packages I'm running - there's no meaningful way I can attribute trust to *all* of the people who packaged something I have installed. > Now back to the "secondary" purpose: > > Using these information "B claims C", other reproduction programs > (that we're also developing) can attempt to actually reproduce the > binaries described. It would do this, by (1) reading the buildinfo > file (2) recreating _some_ of the environment stored in C, and (3) > executing the process, and see if it gives R. You don't need the signature to validate the reproducibility. > The "_some_" in clause (2) is currently up-for-debate, but the > important thing is that this can be changed in the future *without > affecting already-produced buildinfo files*. It may even well be the > case that in the future we'd want to support different values for > "_some_" for a given reproduction tool. > > The main point is that, this is not a concern of the producer nor > distributor of the buildinfo files. I.e.: you guys (the FTP team) only > have to care about making these signed-claims available to be > downloaded by users, and it is up to the users to run a tool that > "interprets" these claims for purposes such as actually attempting > reproduction of a binary. To clarify: I am not a member of the FTP team and do not claim to represent them. I am a DD who was present at the DebConf talk about reproducible builds, was impressed by how far it's come, and asked how I could help get what was missing and still required into Debian. > In this way, we achieve full end-to-end security properties > (verifiability of build) between the producers (builders) and > consumers (users). Distributors only need to care about a
Bug#763822: [Reproducible-builds] Moving towards buildinfo on the archive network
On Sun, Aug 21, 2016 at 04:01:00PM +, Ximin Luo wrote: > Jonathan McDowell: > > On Sat, Aug 20, 2016 at 03:13:00PM +, Ximin Luo wrote: > >> Note that the builder is a *distinct entity* from the distribution. > >> It's important to keep the *original* signature by B on C. It breaks > >> our security logic, to strip the signature and re-sign C using (e.g.) > >> the Debian archive release keys - because the entity in charge of this > >> release key is not the one that actually performed the build. Doing > >> this, would allow malicious builders to re-attribute their misdeeds to > >> look like it's the fault of Debian. > > > > Debian already does this in the context of the fact that Package files > > etc are signed by the archive key. It's possible to go and grab the .dsc > > file to see who did the file build, but day-to-day no one is using these > > to verify the binaries they receive. I care more that Debian stands > > behind the packages I download than being able to verify individually > > who build each of the packages I'm running - there's no meaningful way I > > can attribute trust to *all* of the people who packaged something I have > > installed. > > > > You have this backwards. > > "Being able to verify individually who build each of the packages I'm > running" > > is *exactly* what is required to *not* have to > > "attribute trust of *all* of the people who packaged something I have > installed." > > and that is one major (probably the main) goal of R-B. > > Now that I point this out - do you agree, No. What lets me not care about who actually built the packages and have to attribute trust to them is that I have the build information, which allows me to verify I get exactly the same output from the provided source. The signatures over these do not allow me to trust the binaries I receive in any additional fashion. If I trust the statement "I built package using source and build information " from an individual, without doing any verification that this is true, it doesn't give me much over "I built package using source ". I have to do the build myself to ensure what I have been told is true. Where, to me, signatures become more interesting is when it is possible for multiple different people to attest they build a set of source using the same information and got exactly the same output - but only if I actually trust all the entities who are doing that signing. > and does it change your mind on anything you previously said? Fundamentally I still think build information without the signature of the builder is information that it would be useful to have accompanying the Debian archive. It seems you do not believe this is worth anything as it loses the signature which provides a chain back to the origin. I do not, at present, have a good solution for the extra information and conditions you want within the context of the Debian archive. J. -- ] http://www.earth.li/~noodles/ [] 101 things you can't have too much [ ] PGP/GPG Key @ the.earth.li []of : 49 - Bandwidth. [ ] via keyserver, web or email. [] [ ] RSA: 4096/0x94FA372B2DA8B985 [] [
Bug#838771: RFA: l2tpns
Package: wnpp Severity: normal I have not personally been using l2tpns for a number of years. While I've attempted to respond to the major issues raised against the package it's clear that it could do with some love, care and attention. Additionally there is a fork at http://git.sameswireless.fr/l2tpns.git that seems to be more maintained and might be worth switching to. It would be best if someone actually using this package could take over its maintenance. If it would help I'm prepared to sponsor an initial set of uploads for anyone who would like to do so but is not currently a DM or DD. J.
Bug#822182: [PATCH] Fix dvbtune FTBFS due to missing stdint.h include
Control: tags 822182 + patch This is caused by a missing stdint.h include in dvbtune.c. The attached patch (for debian/patches/) fixes this. I intend to do an NMU with this fix later today, but it is possibly worth considering whether dvbtune is still useful in the archive. J. -- Conscience is the fear of getting caught. --- a/dvbtune.c 2016-07-05 09:43:47.41200 +0100 +++ b/dvbtune.c 2016-07-05 09:44:26.74000 +0100 @@ -39,6 +39,7 @@ // Linux includes: #include #include +#include #include #include #include
Bug#1064681: retroarch: FTBFS: make[1]: *** [debian/rules:48: override_dh_auto_configure] Error 1
Control: tags -1 - trixie Control: severity -1 important On Sun, Feb 25, 2024 at 08:48:32PM +0100, Lucas Nussbaum via Pkg-games-devel wrote: > Source: retroarch > Version: 1.16.0.3+dfsg-1 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240224 ftbfs-trixie > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. This looks like a glslang issue; #1062799 and the associated autopkgtest failures for glslang's migration to trixie (e.g. https://ci.debian.net/packages/g/glslang/testing/amd64/43341664/). I'm dropping this to important until glslang is fixed. > Relevant part (hopefully): > > make[1]: Entering directory '/<>' > > sed 's/@DEB_HOST_MULTIARCH@/x86_64-linux-gnu/g' \ > > retroarch.cfg > debian/retroarch.cfg > > # See ./configure --help for valid flags > > # disable flags (i.e. --disable-ffmpeg for example) if there is no package > > relative to the feature in Build-Depends > > ./configure --prefix=/usr \ > > --disable-builtinmbedtls \ > > --disable-builtinbearssl \ > > --disable-builtinflac \ > > --disable-builtinglslang \ > > --disable-builtinzlib \ > > --disable-update_assets \ > > --disable-oss \ > > --disable-vg \ > > --enable-dbus \ > > --enable-spirv_cross \ > > --enable-vulkan \ > > --enable-sse > > Checking operating system ... Linux > > Checking for suitable working C compiler ... /usr/bin/gcc works > > Checking for suitable working C++ compiler ... /usr/bin/g++ works > > Checking for pkg-config ... /usr/bin/pkgconf > > Checking for availability of switch -std=gnu99 in /usr/bin/gcc ... yes > > Checking for availability of switch -std=c++17 in /usr/bin/g++ ... yes > > Checking for availability of switch -Wno-unused-result in /usr/bin/gcc ... > > yes > > Checking for availability of switch -Wno-unused-variable in /usr/bin/gcc > > ... yes > > Checking function sd_get_machine_names in -lsystemd ... no > > Checking presence of package bcm_host ... no > > Checking function bcm_host_init in -lbcm_host ... no > > Checking presence of header file EGL/eglext.h ... yes > > Checking presence of package egl ... 1.5 > > Checking function ass_library_init in -lfribidi -lass ... no > > Checking existence of -msse -msse2 ... yes > > Checking function pthread_create in -lpthread ... yes > > Checking function pthread_key_create in -lpthread ... yes > > Checking presence of package check >= 0.15 ... no > > Checking presence of header file scsi/sg.h ... yes > > Checking function dlopen in -ldl ... yes > > Checking function socket in -lc ... yes > > Checking function getaddrinfo in -lc ... yes > > Checking function fcntl in -lc ... yes > > Checking function getopt_long in -lc ... yes > > Checking presence of package alsa ... 1.2.10 > > Checking presence of package libsixel >= 1.6.0 ... no > > Checking presence of predefined macro AUDIO_SETINFO in sys/audioio.h ... no > > Checking presence of package rsound >= 1.1 ... no > > Checking presence of package libroar >= 1.0.12 ... no > > Checking presence of package jack >= 0.120.1 ... 1.9.21 > > Checking presence of package libpulse ... 16.1 > > Checking presence of package sdl >= 1.2.10 ... no > > Checking presence of package sdl2 >= 2.0.0 ... 2.30.0 > > Checking presence of package Qt5Core >= 5.2 ... 5.15.10 > > Checking presence of package Qt5Gui >= 5.2 ... 5.15.10 > > Checking presence of package Qt5Widgets >= 5.2 ... 5.15.10 > > Checking presence of package Qt5Concurrent >= 5.2 ... 5.15.10 > > Checking presence of package Qt5Network >= 5.2 ... 5.15.10 > > Checking presence of package openssl >= 1.0.0 ... no > > Checking presence of package flac ... 1.4.3 > > Checking existence of -lmbedtls -lmbedx509 -lmbedcrypto ... no > > Notice: HID is disabled, libusb support will also be disabled. > > Checking existence of -ldinput8 ... no > > Checking existence of -ld3d9 ... no > > Checking existence of -ldsound ... no > > Checking existence of -ld3dx8 ... no > > Checking existence of -ld3dx9 ... no > > Checking presence of header file GL/gl.h ... yes > > Checking existence of -lGL ... yes > > Checking function cgCreateContext in -lCg -lCgGL ... no > > Checking presence of package zlib ... 1.3 > > Checking presence of package libavcodec >= 57 ... 60.31.102 > > Checking presence of package libavformat >= 57 ... 60.16.100 > > Checking presence of package libavdevice >= 57 ... 60.3.100 > > Checking presence of package libswresample >= 2 ... 4.12.100 > > Checking presence of package libavutil >= 55 ... 58.29.100 > > Checking presence of package libswscale >= 4 ... 7.5.100 > > Checking presence of header file libavutil/channel_layout.h ... yes > > Checking function dlopen in -ldl ... yes > > Checking presence of package gbm >= 9.0 ... 24.0.1-1 > > Checking presence of package libdrm ... 2.4.120 > > Checking presence of package dbus-1 ... 1.14.10 > > Checking presence of package libudev ... 255 > > Checking presence of pac
Bug#1072449: retroarch: FTBFS with ffmpeg 7.0: record/drivers/record_ffmpeg.c:304:16: error: ‘AVCodecContext’ has no member named ‘channels’
On Mon, Jul 29, 2024 at 05:07:21PM -0700, Ryan Tandy wrote: > On Sun, Jun 02, 2024 at 03:26:12PM +0200, Sebastian Ramacher wrote: > > Source: retroarch > > Version: 1.18.0+dfsg-1 > > Severity: important > > Tags: trixie sid ftbfs > > Usertags: ffmpeg-7.0 > > > > Hi, > > > > during a rebuild of the reverse dependencies for the transition to > > ffmpeg 7.0, your package failed to build > > It looks ffmpeg 7.0 support was added in retroarch 1.19.0: > > https://www.libretro.com/index.php/retroarch-1-19-0-release/ > https://github.com/libretro/RetroArch/commit/bff678c48a3d453244486b64a21fd4e00f56cbfb > > I rebuilt retroarch locally with ffmpeg 7.0.1 from unstable and it > succeeded. I think this bug can be closed as fixed in retroarch > 1.19.1+dfsg-1, do you agree? Yes, I saw that in the changelog and tried to build against ffmpeg 7 in experimental at the time, but failed to convince sbuild to pull in the ffmpeg 7 packages to confirm and didn't get round to trying again. If you've successfully built it then I agree this can be closed. > (Also, could you please push the git tag for 1.19.1+dfsg-1?) Oops! Done. J. -- Revd Jonathan McDowell, ULC | What have you got in your pocket?
Bug#1051541: ITP: rustic -- fast, encrypted, and deduplicated backups powered by Rust
On Tue, Dec 05, 2023 at 08:59:56AM -0700, Scarlett Moore wrote: > * Package name: rustic > Version : 0.5.4 > Upstream Contact: Alexander Weiss > * URL : https://github.com/rustic-rs/rustic > * License : Apache-2.0 or MIT > Programming Lang: Rust > Description : fast, encrypted, and deduplicated backups powered by Rust > > Restic (https://github.com/restic/restic/) is a great backup tool IMHO. The > compatible Rust implementation rustic is a lot faster and has a lot more other > features over the Golang version, for example: ... > I think that'd be a very useful utility to have in Debian. Perhaps once it no longer states: | rustic currently is in beta state and misses regression tests. It is not | recommended to use it for production backups, yet. J. -- The end is nearer. | .''`. Debian GNU/Linux Developer | : :' : Happy to accept PGP signed | `. `' or encrypted mail - RSA | `-key on the keyservers.
Bug#1059562: contributors.debian.org: some contributors are missing
On Thu, Dec 28, 2023 at 02:07:25PM +0100, Pierre Gruet wrote: > I feel some contributors are missing from the page [0]. For instance, I > (Pierre > Gruet ) have never been on it although I have contributed on a regular > basis since 2020. > I have no idea of the number of missing people. > > I feel pointing this out now is relevant as we are currently [1] discussing > figures based on the contents of [0]. If I look at https://contributors.debian.org/contributor/pgt/ there are no identifiers listed for you, but does know how to map your username to your real name. Compare this to my page, https://contributors.debian.org/contributor/noodles/, which lists email addresses, fingerprints + logins. Have you tried adding some associations there (and if you can't login, would you like me to?) - without any listed it won't be able to match up incoming data. J. --
Bug#1064731: [Pkg-electronics-devel] Bug#1064731: sdcc: FTBFS: /bin/sh: 1: inkscape: not found
Control: retitle -1 sdcc: FTBFS: Error building LyX documentation On Sun, Feb 25, 2024 at 08:45:34PM +0100, Lucas Nussbaum via Pkg-electronics-devel wrote: > Source: sdcc > Version: 4.2.0+dfsg-1 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240224 ftbfs-trixie > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. The inkscape error here is a red herring; even switching from librsvg2-bin back to inkscape doesn't do any better. Something in the LyX -> LaTeX dependency tree must have changed. :( J. -- ... "What the f**k was that?" -- Mayor of Hiroshima
Bug#1067263: [Pkg-electronics-devel] Bug#1067263: sigrok-firmware-fx2lafw: FTBFS: sdcpp: fatal error: cannot execute 'cc1': execvp: No such file or directory
Control: reassign -1 sdcc This is going to be a result of the 4.4.0 sdcc upload I did over the weekend. On Wed, Mar 20, 2024 at 10:04:12PM +0100, Lucas Nussbaum wrote: > Source: sigrok-firmware-fx2lafw > Version: 0.1.7-1 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240319 ftbfs-trixie > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > make[1]: Entering directory '/<>' > > sdcc -mmcs51 -I./include -I./fx2lib/include -c fx2lafw.c -o fx2lafw.rel > > sdcc -mmcs51 -I./include -I./fx2lib/include -c gpif-acquisition.c -o > > gpif-acquisition.rel > > sdcpp: fatal error: cannot execute 'cc1': execvp: No such file or directory > > compilation terminated. > > sdcpp: fatal error: cannot execute 'cc1': execvp: No such file or directory > > at 1: warning 190: ISO C forbids an empty translation unit > > subprocess error 256 > > compilation terminated. > > at 1: warning 190: ISO C forbids an empty translation unit > > subprocess error 256 > > make[1]: *** [Makefile:991: fx2lafw.rel] Error 1 > > > The full build log is available from: > http://qa-logs.debian.net/2024/03/19/sigrok-firmware-fx2lafw_0.1.7-1_unstable.log > > All bugs filed during this archive rebuild are listed at: > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20240319;users=lu...@debian.org > or: > https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=ftbfs-20240319&fusertaguser=lu...@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=1#results > > A list of current common problems and possible solutions is available at > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! > > If you reassign this bug to another package, please mark it as 'affects'-ing > this package. See https://www.debian.org/Bugs/server-control#affects > > If you fail to reproduce this, please provide a build log and diff it with > mine > so that we can identify if something relevant changed in the meantime. > > ___ > Pkg-electronics-devel mailing list > pkg-electronics-de...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-electronics-devel J. -- ] https://www.earth.li/~noodles/ [] Shopping is hard. Let's do Math! [ ] PGP/GPG Key @ the.earth.li[][ ] via keyserver, web or email. [][ ] RSA: 4096/0x94FA372B2DA8B985 [][
Bug#1067778: retroarch ftbfs in unstable
Control: forcemerge 1064681 1067778 On Tue, Mar 26, 2024 at 05:20:33PM +0100, Matthias Klose via Pkg-games-devel wrote: > Package: src:retroarch > Version: 1.16.0.3+dfsg-1 > Severity: serious > Tags: sid trixie ftbfs > > retroarch ftbfs in unstable > > [...] > Checking existence of -lglslang ... yes > Checking existence of -lOSDependent ... yes > Checking existence of -lOGLCompiler ... no > Checking existence of -lMachineIndependent ... yes > Checking existence of -lGenericCodeGen ... yes > Checking existence of -lHLSL ... no > Checking existence of -lSPIRV ... yes > Checking existence of -lSPIRV-Tools-opt ... yes > Checking existence of -lSPIRV-Tools ... yes > Notice: System glslang libraries not found, disabling glslang support. > Notice: glslang is disabled, slang support will also be disabled. > Error: glslang is disabled and forced to build with SPIRV-Cross support. > make[1]: *** [debian/rules:48: override_dh_auto_configure] Error 1 > make[1]: Leaving directory '/home/packages/tmp/retroarch-1.16.0.3+dfsg' > make: *** [debian/rules:42: binary] Error 2 > > ___ > Pkg-games-devel mailing list > pkg-games-de...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-games-devel J. -- 101 things you can't have too much of : 1 - Cable ties.
Bug#1070885: [Pkg-electronics-devel] Bug#1070885: openocd: FTBFS with libgpiod/2.1
On Sat, May 11, 2024 at 03:35:36PM +0800, Gavin Lai wrote: > Source: openocd > Version: 0.12.0-1 > Severity: important > > Dear Maintainer, > > I am planning to have a transition for libgpiod. > https://release.debian.org/transitions/html/auto-libgpiod.html > > Many APIs were changed in this transition. > I tested libgpiod with openocd 0.12.0. > As a result, it seems FTBFS. Please have a check. > Feel free to let me know if any information is needed. It looks like upstream OpenOCD has modified its configure.ac to prevent trying to build with libgpiod v2. There are patches out for review around adding proper support, but they're all currently works in progress. J. -- ... Avoid temporary variables and strange women.
Bug#1032731: Fails to start: AttributeError: 'TrezorctlGroup' object has no attribute 'resultcallback'
Package: trezor
Version: 0.12.4-1
Severity: grave
X-Debbugs-Cc: nood...@earth.li
Control: forwarded -1 https://github.com/trezor/trezor-firmware/issues/2199
Installed trezor and tried to run it, got a traceback:
$ trezorctl
Traceback (most recent call last):
File "/usr/bin/trezorctl", line 33, in
sys.exit(load_entry_point('trezor==0.12.4', 'console_scripts',
'trezorctl')())
^^
File "/usr/bin/trezorctl", line 25, in importlib_load_entry_point
return next(matches).load()
File "/usr/lib/python3.11/importlib/metadata/__init__.py", line 202, in load
module = import_module(match.group('module'))
File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1206, in _gcd_import
File "", line 1178, in _find_and_load
File "", line 1149, in _find_and_load_unlocked
File "", line 690, in _load_unlocked
File "", line 940, in exec_module
File "", line 241, in _call_with_frames_removed
File "/usr/lib/python3/dist-packages/trezorlib/cli/trezorctl.py", line 171,
in
@cli.resultcallback()
^^
AttributeError: 'TrezorctlGroup' object has no attribute 'resultcallback'. Did
you mean: 'result_callback'?
Looks like this is an issue with the Click usage and was fixed upstream in
0.13.1.
-- System Information:
Debian Release: bookworm/sid
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-5-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages trezor depends on:
ii python3 3.11.2-1
ii python3-trezor 0.12.4-1
trezor recommends no packages.
trezor suggests no packages.
-- no debconf information
Bug#1021344: Please stop failing DM ACL changes based on debian-keyring package
Package: dput-ng The dcut command in dput-ng makes use of the debian-keyring package to verify that modifications to DM access permissions are valid. This is the wrong thing to do; the package is not actually what the infrastructure is using and even if it was then you would be making the tool only useful on sid. As it is we do not reliably update the package every time we do a keyring update, only concentrating on ensuring freshness around release time. If you feel the need to fail hard if the key is not in the active keyring then you should be rsyncing the active keyring from keyring.debian.org. Otherwise I suggest the check is change to be purely advisory. J. -- 101 things you can't have too much of : 32 - Answers. This .sig brought to you by the letter R and the number 12 Product of the Republic of HuggieTag
Bug#1027741: Add retroarch-dev package with includes
Package: retroarch Severity: wishlist The libretro-common/ subdirectory has various bits of use to libretro emulators and users (e.g the Kodi wrapper). It would be useful to have a libretro-dev or retroarch-dev that at least has the include files in it. J. -- 101 things you can't have too much of : 1 - Cable ties. This .sig brought to you by the letter A and the number 33 Product of the Republic of HuggieTag
Bug#1027903: ITP: kodi-game-libretro -- Libretro compatibility layer for the Kodi Game API
Package: wnpp Severity: wishlist Owner: Jonathan McDowell X-Debbugs-Cc: debian-de...@lists.debian.org, debian-devel-ga...@lists.debian.org, debian-multime...@lists.debian.org, nood...@earth.li * Package name: kodi-game-libretro Version : 20.2.0 * URL : https://github.com/kodi-game/game.libretro * License : GPL Programming Lang: C++ Description : Libretro compatibility layer for the Kodi Game API This add-on provides a wrapper that allows Libretro cores to be loaded as game add-ons within Kodi. Libretro cores are shared libraries that use the Libretro API, so the wrapper is responsible for translating function calls between the Libretro API and the Kodi Game API. I plan to maintain this as part of the Debian Games team - while Kodi is under the Multimedia team the only requirement from that side is the kodi-addons-dev package.
Bug#1024874: debian-keyring: gnupg files make lintian generate hundreds of warnings
On Sun, Nov 27, 2022 at 11:45:31AM +0100, Gioele Barabucci wrote: > Package: debian-keyring > Version: 2022.11.26 > Severity: minor > Tags: patch > > lintian v2.115.3 generates hundreds of spurious warnings related to the > extension of gpg files and their content (long lines). > > The attached patch adds the appropriate lintian-overrides files to silence > these warnings. This seems like at least partly a lintian issue. *.gpg for OpenPGP is far from uncommon, so I don't believe debian/lintian-overrides is appropriate here; lintian should know to ignore such files. For the source override we're not using the file extension, but 'file' can clearly detect the files as being OpenPGP keyrings and there's no common file extension that would suggest a text file, so again I think lintian is being over zealous here. J. -- Web [ She's the one for me. She's all I really need, oh yeah.] site: https:// [ ] Made by www.earth.li/~noodles/ [ ] HuggieTag 0.0.24
Bug#1027903: Co-maintainer access
On Sun, Jan 22, 2023 at 03:15:08PM +, Vasyl Gello wrote: > Thanks for packaging this one! Thanks for all the work you do on Kodi! > Is it OK for you to move the Salsa repo to of kodi-game-libretro > to https://salsa.debian.org/multimedia-team/kodi-media-center ? > Then all Kodi stuff will be in one place :) > > If you dont want to move it, please grant me the co-maintainer > access so I can keep the addon in sync with all others. There are a whole bunch of kodi-game-libretro-* packages I'm hoping to add (I just updated libretro-bsnes with the first set) that will all live under libretro/ in the games-team, so I think it makes more sense for kodi-game-libretro to live alongside those. However I'm happy to grant you access to the repo - what's your Salsa username? J. -- /-\ | "This sentence no verb." -- Robin |@/ Debian GNU/Linux Developer | Stevens, ox.talk \- |
Bug#1031927: Handling the libsgutils2-2 #994758 bookworm-ignore
On Mon, Feb 27, 2023 at 09:11:46PM +0100, Paul Gevers wrote: > Control: tags 994758 - bookworm-ignore > > Hi Adrian, > > Thanks for caring. > > On 25-02-2023 14:30, Adrian Bunk wrote: > > With the bookworm-ignore for #994758, > > I'll admit that I misjudged that bug; with this message I'll clear the > bookworm-ignore tag. > > > bullseye and bookworm > > will ship libsgutils2-2 packages with different so-name. > > Although the transition freeze has started long time ago, it seems that > doing a proper transition is the best way to fix this issue. If somebody is > up to the task to prepare the upload, we can ask ftp-master to process the > upload swiftly. (Please upload to experimental to avoid the ftp-master from > rejecting the package immediately and to enable reviewing if that's not done > before the upload.) This does not look overly hard and I have some familiarity with the package having uploaded in the past. If no one else is already looking at it I'll aim to have a version with a libsgutils2-1.46 library package uploaded to experimental by the end of today. J. -- /-\ | If at first you don't succeed, |@/ Debian GNU/Linux Developer | create an "NT" version. \- | signature.asc Description: PGP signature
Bug#1031927: Handling the libsgutils2-2 #994758 bookworm-ignore
On Wed, Mar 01, 2023 at 08:07:09AM +, Jonathan McDowell wrote: > On Mon, Feb 27, 2023 at 09:11:46PM +0100, Paul Gevers wrote: > > On 25-02-2023 14:30, Adrian Bunk wrote: > > > With the bookworm-ignore for #994758, > > > > I'll admit that I misjudged that bug; with this message I'll clear the > > bookworm-ignore tag. > > > > > bullseye and bookworm > > > will ship libsgutils2-2 packages with different so-name. > > > > Although the transition freeze has started long time ago, it seems that > > doing a proper transition is the best way to fix this issue. If somebody is > > up to the task to prepare the upload, we can ask ftp-master to process the > > upload swiftly. (Please upload to experimental to avoid the ftp-master from > > rejecting the package immediately and to enable reviewing if that's not done > > before the upload.) > > This does not look overly hard and I have some familiarity with the > package having uploaded in the past. If no one else is already looking > at it I'll aim to have a version with a libsgutils2-1.46 library package > uploaded to experimental by the end of today. Now sitting in NEW for experimental: https://ftp-master.debian.org/new/sg3-utils_1.46-2.html I have confirmed: * It will not co-exist with the libsgutils2-2 package in bookworm (thanks to the versioned breaks/replaces) * It will co-exist with the libsgutils2-2 package in bullseye (which is 1.45-1 and has no overlapping files) * Operation of the sg3-utils package with this new build It turns out I do not have access to the salsa git repo at present, but I've requested it and will push the changes there when it is granted. J. -- No one told you when to run, you missed the starting gun. This .sig brought to you by the letter L and the number 39 Product of the Republic of HuggieTag signature.asc Description: PGP signature
Bug#1032246: unblock: sg3-utils/1.46-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: sg3-ut...@packages.debian.org
Control: affects -1 + src:sg3-utils
Control: block 1031927 by -1
Please unblock package sg3-utils.
This is a prerequest, before uploading to unstable. The package has
already passed through NEW and is available in experimental.
[ Reason ]
The libsgutils2-2 package contains a library, libsgutils, which has
started embedding the package version in the library name since the
1.45 release upstream. This means that if we ship sg3-utils as is we'll
end up shipping libsgutils2-2 in bookworm containing a different soname
than libsgutils2-2 in bullseye.
Note this will require rebuilds of the rdepends of libsgutils2-2 which
appear to be:
tableau-parm
ledmon
libgpod
I *think* the appropriate transition rule is:
title = "sg3-utils";
is_affected = .depends ~ "libsgutils2-2" | .depends ~ "libsgutils2-1.46-2";
is_good = .depends ~ "libsgutils2-1.46-2";
is_bad = .depends ~ "libsgutils2-2";
[ Impact ]
If not permitted then we'll end up with potential problems for the rdeps
of libsgutils2-2 during upgrades.
[ Tests ]
There is no functional code change here, just a package rename. It has
been confirmed that:
* It will not co-exist with the libsgutils2-2 package in bookworm
(thanks to the versioned breaks/replaces)
* It will co-exist with the libsgutils2-2 package in bullseye
(which is 1.45-1 and has no overlapping files)
* Operation of the sg3-utils package with this new build is fine
[ Risks ]
If we don't update this in bookworm we run the risk of soname skew.
[ Checklist ] (TBD)
[x] All changes are documented in the d/changelog
[x] I have reviewed all changes and I approve them
[x] attach diff against the package in testing
TBD:
unblock sg3-utils/1.46-3
diff --git a/debian/changelog b/debian/changelog
index 6aeaa17..9ba46b1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,19 @@
+sg3-utils (1.46-3) unstable; urgency=medium
+
+ * Upload to unstable
+
+ -- Jonathan McDowell Thu, 02 Mar 2023 09:13:12 +
+
+sg3-utils (1.46-2) experimental; urgency=medium
+
+ [ Debian Janitor ]
+ * Use secure URI in Homepage field.
+
+ [ Jonathan McDowell ]
+ * Rename libsgutils2-2 package to include package version (Closes: #994758)
+
+ -- Jonathan McDowell Wed, 01 Mar 2023 09:24:47 +
+
sg3-utils (1.46-1) unstable; urgency=medium
[ Debian Janitor ]
diff --git a/debian/control b/debian/control
index 71b7c6d..5ed0768 100644
--- a/debian/control
+++ b/debian/control
@@ -5,7 +5,7 @@ Maintainer: Ritesh Raj Sarraf
Uploaders: Jonathan McDowell
Build-Depends: debhelper-compat (= 13), libtool, libcam-dev [kfreebsd-any],
dpkg-dev (>= 1.16.1~)
Standards-Version: 4.5.1
-Homepage: http://sg.danny.cz/sg/
+Homepage: https://sg.danny.cz/sg/
Vcs-Git: https://salsa.debian.org/linux-blocks-team/sg3-utils.git
Vcs-Browser: https://salsa.debian.org/linux-blocks-team/sg3-utils
@@ -24,12 +24,12 @@ Description: utilities for devices using the SCSI command
set
between supported SCSI and ATA commands and utility names in this package
see the COVERAGE file.
-Package: libsgutils2-2
+Package: libsgutils2-1.46-2
Section: libs
Depends: ${shlibs:Depends}, ${misc:Depends}
Architecture: any
-Conflicts: libsgutils2
-Replaces: libsgutils2
+Conflicts: libsgutils2-2 (= 1.46-1)
+Replaces: libsgutils2-2 (= 1.46-1)
Suggests: sg3-utils
Multi-Arch: same
Description: utilities for devices using the SCSI command set (shared
libraries)
@@ -47,7 +47,7 @@ Description: utilities for devices using the SCSI command set
(shared libraries)
Package: libsgutils2-dev
Section: libdevel
Architecture: any
-Depends: libsgutils2-2 (= ${binary:Version}), ${shlibs:Depends},
${kfreebsd:Depends}, ${misc:Depends}
+Depends: libsgutils2-1.46-2 (= ${binary:Version}), ${shlibs:Depends},
${kfreebsd:Depends}, ${misc:Depends}
Conflicts: libsgutils1-dev
Suggests: sg3-utils
Multi-Arch: same
diff --git a/debian/libsgutils2-2.install b/debian/libsgutils2-1.46-2.install
similarity index 100%
rename from debian/libsgutils2-2.install
rename to debian/libsgutils2-1.46-2.install
diff --git a/debian/libsgutils2-2.symbols b/debian/libsgutils2-1.46-2.symbols
similarity index 99%
rename from debian/libsgutils2-2.symbols
rename to debian/libsgutils2-1.46-2.symbols
index f161c52..8d05b85 100644
--- a/debian/libsgutils2-2.symbols
+++ b/debian/libsgutils2-1.46-2.symbols
@@ -1,4 +1,4 @@
-libsgutils2-1.46.so.2 libsgutils2-2 #MINVER#
+libsgutils2-1.46.so.2 libsgutils2-1.46-2 #MINVER#
check_pt_file_handle@Base 1.43
clear_scsi_pt_obj@Base 1.27
construct_scsi_pt_obj@Base 1.27
diff --git a/debian/libsgutils2-2.symbols.kfreebsd
b/debian/libsgutils2-1.46-2.symbols.kfreebsd
similarity index 98%
rename from debian/libsgutils2-2.symbols.kfreebsd
rename to debian/libsgutils2-1.46-2.symbols.kfreebsd
index ef2c0
Bug#1032246: unblock: sg3-utils/1.46-3
On Thu, Mar 02, 2023 at 03:23:01PM +0100, Paul Gevers wrote:
> On 02-03-2023 10:30, Jonathan McDowell wrote:
> > This is a prerequest, before uploading to unstable. The package has
> > already passed through NEW and is available in experimental.
>
> Thanks.
>
> > -Package: libsgutils2-2
> > +Package: libsgutils2-1.46-2
> > Section: libs
> > Depends: ${shlibs:Depends}, ${misc:Depends}
> > Architecture: any
> > -Conflicts: libsgutils2
> > -Replaces: libsgutils2
> > +Conflicts: libsgutils2-2 (= 1.46-1)
> > +Replaces: libsgutils2-2 (= 1.46-1)
>
> Any specific reason why this is a Conflicts and not a Breaks, other than
> that was what was already there?
>
> Feel free to upload with either Conflicts or Breaks.
Yeah, I don't think there's any compelling reason to keep it as a
Conflicts, so I've downgraded it to a Breaks and uploaded 1.46-3 to
unstable.
J.
--
I know the feeling, that perfect feeling
signature.asc
Description: PGP signature
Bug#1034524: libretro-bsnes-mercury: uses invalid architecture wildcards
Control: severity -1 important On Mon, Apr 17, 2023 at 05:32:06PM +0100, Graham Inggs wrote: > Source: libretro-bsnes-mercury > Version: 094+git20220807-6 > Severity: serious > > Hi Maintainer > > Since the upload of 094+git20220807-6, the > kodi-game-libretro-bsnes-mercury-* binary packages are no longer built > on armel and armhf [1][2][3]. This is due to the use of invalid > architecture wildcards 'any-armel' and 'any-armhf'. These should be > replaced by 'any-arm' for each of three This is an unfortunate mistake on my part, but given the stage we're at in the release process, the fact these are leaf packages and the fact the packages didn't ship as part of bullseye I don't think this counts as release critical. > kodi-game-libretro-bsnes-mercury-* binary packages in debian/control, > as follows: > > -Architecture: any-amd64 any-arm64 any-armel any-armhf any-i386 > any-powerpc any-ppc64 any-ppc64el any-riscv64 any-s390x any-sparc64 > > +Architecture: any-amd64 any-arm64 any-arm any-i386 any-powerpc > any-ppc64 any-ppc64el any-riscv64 any-s390x any-sparc64 > > Regards > Graham > > > [1] > https://packages.debian.org/unstable/kodi-game-libretro-bsnes-mercury-accuracy > [2] > https://packages.debian.org/unstable/kodi-game-libretro-bsnes-mercury-balanced > [3] > https://packages.debian.org/unstable/kodi-game-libretro-bsnes-mercury-performance J. -- ... If we sleep together, will you like me better?
Bug#1034680: retroarch-assets: Missing icons (Favorites, and Netplay Rooms) for the default XMB theme, for Debian Stable (but solve in Testing, and Unstable)
Control: forcemerge 926811 -1 On Fri, Apr 21, 2023 at 03:33:00PM +0200, David Hedlund wrote: > Package: retroarch-assets > Version: 1.3.6+git20160731+dfsg1-2 > > Open the attached Debian_11_Stable.png screenshot. As you can see, these > icons are missing: > ... > > This issue has been fixed in: > > Debian 11 Testing (see attached screenshot) > Package: retroarch > Version: 1.14.0+dfsg-1 > Package: retroarch-assets > Version: 1.7.6+git20221024+dfsg-2 Yes, that's expected. The retroarch-assets package in bullseye was extremely dated and this has been corrected for bookworm. J. -- Web [ I am a passenger. ] site: https:// [ ] Made by www.earth.li/~noodles/ [ ] HuggieTag 0.0.24
Bug#1034680: retroarch-assets: Missing icons (Favorites, and Netplay Rooms) for the default XMB theme, for Debian Stable (but solve in Testing, and Unstable)
On Fri, Apr 21, 2023 at 07:37:44PM +0200, David Hedlund wrote: > On 2023-04-21 19:00, Jonathan McDowell wrote: > > On Fri, Apr 21, 2023 at 03:33:00PM +0200, David Hedlund wrote: > > > Package: retroarch-assets > > > Version: 1.3.6+git20160731+dfsg1-2 > > > > > > Open the attached Debian_11_Stable.png screenshot. As you can see, these > > > icons are missing: > > > > > ... > > > This issue has been fixed in: > > > > > > Debian 11 Testing (see attached screenshot) > > > Package: retroarch > > > Version: 1.14.0+dfsg-1 > > > Package: retroarch-assets > > > Version: 1.7.6+git20221024+dfsg-2 > > Yes, that's expected. The retroarch-assets package in bullseye was > > extremely dated and this has been corrected for bookworm. > > > Thanks. This bug is marked as solved, why aren't these two PNG files going > to be added to the stable retroarch-assets package? Debian generally doesn't update packages in the stable release unless there's a security issue or a serious functionality issue. While it might be a minor fix here it's also primarily a cosmetic issue. J. -- ///\oo/\\\ There are no more bugs. ///\oo/\\\ ///\oo/\\\
Bug#1034680: retroarch-assets: Missing icons (Favorites, and Netplay Rooms) for the default XMB theme, for Debian Stable (but solve in Testing, and Unstable)
On Sun, Apr 23, 2023 at 01:39:51PM +0200, David Hedlund wrote: > On 2023-04-23 13:04, Jonathan McDowell wrote: > > On Fri, Apr 21, 2023 at 07:37:44PM +0200, David Hedlund wrote: > > > On 2023-04-21 19:00, Jonathan McDowell wrote: > > > > On Fri, Apr 21, 2023 at 03:33:00PM +0200, David Hedlund wrote: > > > > > Package: retroarch-assets > > > > > Version: 1.3.6+git20160731+dfsg1-2 > > > > > > > > > > Open the attached Debian_11_Stable.png screenshot. As you can see, > > > > > these > > > > > icons are missing: > > > > > > > > > ... > > > > > This issue has been fixed in: > > > > > > > > > > Debian 11 Testing (see attached screenshot) > > > > > Package: retroarch > > > > > Version: 1.14.0+dfsg-1 > > > > > Package: retroarch-assets > > > > > Version: 1.7.6+git20221024+dfsg-2 > > > > Yes, that's expected. The retroarch-assets package in bullseye was > > > > extremely dated and this has been corrected for bookworm. > > > > > > > Thanks. This bug is marked as solved, why aren't these two PNG files going > > > to be added to the stable retroarch-assets package? > > Debian generally doesn't update packages in the stable release unless > > there's a security issue or a serious functionality issue. While it > > might be a minor fix here it's also primarily a cosmetic issue. > > > Thanks. Personally, I think the lack of these icons in this stable package > release make it look unstable, because it's on the main interface. Don't you > agree? I don't agree this is a critical enough bug to roll out to stable (bullseye), even if we weren't so close to releasing bookworm. retroarch in bullseye is not in great shape, but I believe I have resolved that for bookworm. J. -- /-\ | Let's not go there. |@/ Debian GNU/Linux Developer | \- |
Bug#1034680: retroarch-assets: Missing icons (Favorites, and Netplay Rooms) for the default XMB theme, for Debian Stable (but solve in Testing, and Unstable)
On Mon, Apr 24, 2023 at 12:55:04AM +0200, David Hedlund wrote: > I filed this issue: https://github.com/libretro/RetroArch/issues/15210 -- > Should I close it or merge it to Debian? > > I'll close it if the "Update Assets" entry has been removed from the > retroarch package in Debian. Your report there appears to be about Ubuntu, and I can't comment on what they do. The Debian package explicitly disables the "Update Assets" option, because it doesn't make sense to allow a random program to update something that's been installed from a .deb J. -- ... you should see the damage a bear on fire can do to a rack of switches.
Bug#1007607: remote-tty: please consider upgrading to 3.0 source format
On Wed, Aug 16, 2023 at 07:20:33PM +0200, Bastian Germann wrote: > If you do not want to move to format 3.0, please at least specify 1.0 format > so that dpkg-source can move to default 3.0 format. TBH I think remote-tty can probably be removed entirely. J. -- Revd Jonathan McDowell, ULC | It's deja-vu all over again.
Bug#1049948: RM: remote-tty -- ROM; unmaintained; other options exist
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: remote-...@packages.debian.org, nood...@earth.li Control: affects -1 + src:remote-tty Please remove remote-tty. It's a leaf package which I have not given much love to in years and no longer use myself. There has been no active upstream work on it during the time I've maintained it. Looking at other options within the archive both conserver and conman appear to fulfil the same niche and be actively maintained. If I was looking for this functionality again these days that is where I'd look. Thanks, J.
Bug#1043168: please include missing stub_flasher_32.json file
On Thu, Aug 31, 2023 at 02:28:20AM +0300, Faidon Liambotis wrote: > A lot of work has happened in Debian and with upstream over the years to > build these binaries from unmodified sources, which culminated with > Debian shipping the stubs for the ESP8266, as well as for the ESP32 > RISC-V variants (ESP32-C2, ESP32-C3, ESP32-C6, ESP32-H2). See the > 4.5.1+dfsg-0.1 and 4.6.2+dfsg-0.1 changelog entries, Debian bug #948096, > as well as upstream issues #458, #499 and PRs #500, #501, #856, #858. > > The reason that the same has not happened yet for the ESP32, ESP32-S2 > and ESP32-S3 stubs is that we lack the toolchain for them in Debian > (gcc, binutils & picolibc). picolibc seems to have gained ESP32 support > upstream in 1.7.9, and Keith Packard is both upstream and the Debian > maintainer for it, so I suppose it won't be too hard to persuade him. > gcc and binutils are more complicated. #868895 provides some context, > and Jonathan McDowell, who maintains gcc-xtensa-lx106 and > binutils-xtensa-lx106, is aware of the need. I think there is more of a > backstory there, but he has the details. When I originally ITPed the lx106/ESP8266 variants I got some strong pushback about how we should really have a unified gcc/binutils that would be able to cope with various Xtensa variants. That doesn't seem to have happened. Faidon has done some work on building multiple versions from a single source, and I've finally accepted this is a better situation for now than not having the support at all. As a first step I've renamed the source binutils-xtensa-lx106 package to binutils-xtensa. I've got some changes pulled in from Faidon's work that will then build an ESP32 binutils package (I don't have later devices to test with) that I'll look at uploading once the new source package clears NEW. GCC is a bit more complex; when I tried previously I had problems with ESP-IDF, and I don't think a version that doesn't allow building with the upstream SDK is useful. I'll have a further poke at that to see if I can figure out what was going wrong. J. -- Revd Jonathan McDowell, ULC | Protect the Human
Bug#1022702: [pkg-gnupg-maint] Bug#1022702: Bug#1022702: gnupg: Migrating packaging from 2.2.x to "stable" 2.3.x
On Wed, Jul 12, 2023 at 09:18:27AM +0200, Simon Josefsson wrote: > Christian Kastner writes: > > On 2023-06-12 17:01, Sune Stolborg Vuorela wrote: > >> Any chance you can give Andreas a go ahead to push a newer Gnupg2 to at > >> least > >> experimental, or preferably unstable ? > > > > I, too, would appreciate a newer version. It turns out that in versions > > prior to 2.3, the 'kdf-setup' option with cards does not work [1]. At > > least, that was the case with both Yubikeys and Nitrokeys here on my end. > > How about uploading ametzler's branch to experimental, as a start? It > is good time after the bookworm release. I offer to help maintain GnuPG > in Debian. Perhaps uploading it to mentors would be a first step, any > objections? > > There are some new features in GnuPG 2.4.x that I rely on, having to > build it locally is a pain. +1 for an upload of 2.4 to experimental; I'm quite interested in playing with the support for TPM backed keys. I haven't seen dkg or Eric weigh in on this thread, but they've had a few months to object and given gnupg lives under the debian/ tree in salsa I'd take that as an indication that an upload to experimental would be acceptable. J. -- I am afraid of the dark. signature.asc Description: PGP signature
Bug#1022702: [pkg-gnupg-maint] Bug#1022702: Bug#1022702: gnupg: Migrating packaging from 2.2.x to "stable" 2.3.x
On Mon, Jul 17, 2023 at 05:16:47PM +0200, Simon Josefsson wrote: > Jonathan McDowell writes: > > On Wed, Jul 12, 2023 at 09:18:27AM +0200, Simon Josefsson wrote: > >> Christian Kastner writes: > >> > On 2023-06-12 17:01, Sune Stolborg Vuorela wrote: > >> >> Any chance you can give Andreas a go ahead to push a newer Gnupg2 > >> >> to at least > >> >> experimental, or preferably unstable ? > >> > > >> > I, too, would appreciate a newer version. It turns out that in versions > >> > prior to 2.3, the 'kdf-setup' option with cards does not work [1]. At > >> > least, that was the case with both Yubikeys and Nitrokeys here on my end. > >> > >> How about uploading ametzler's branch to experimental, as a start? It > >> is good time after the bookworm release. I offer to help maintain GnuPG > >> in Debian. Perhaps uploading it to mentors would be a first step, any > >> objections? > >> > >> There are some new features in GnuPG 2.4.x that I rely on, having to > >> build it locally is a pain. > > > > +1 for an upload of 2.4 to experimental; I'm quite interested in playing > > with the support for TPM backed keys. > > I cloned ... > Any feedback on this libgpg-error update? I think if we're debating over whether the upload should happen or not then we shouldn't be adding new uploaders to the package yet. > GnuPG 2.4.x requires libgpg-error 1.47, so uploading a new version of > libgpg-error would be a first step. Given this, and the fact we've just been going round in circles with no feedback from the listed maintainers, I've taken Andreas' work on libgpg-error and uploaded it to experimental. I haven't had a chance to look at the gnupg changes yet, which sounds like they're a bit bigger, but I see no reason they shouldn't also be uploaded to experimental after review. The longer term question is whether any of us are stepping up to help out with full package maintenance, which I believe should be a prerequisite of an upload to unstable if we don't hear from Eric or dkg. J. -- Minorities are the foundation of society. signature.asc Description: PGP signature
Bug#1042109: Please upgrade python-fido2 to 1.1.2
Package: python3-fido2 Version: 0.9.1-1 Severity: wishlist X-Debbugs-Cc: nood...@earth.li python-fido2 is currently at version 0.9.1, released in February 2021. There have been several releases since then and the latest is 1.1.2, released last month. (I note that although the package doesn't seem to have the appropriate Vcs-* metadata the package is maintained on salsa at https://salsa.debian.org/auth-team/python-fido2 so I will try to find some time to submit an update there.) -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-10-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-fido2 depends on: ii python3 3.11.2-1+b1 ii python3-cryptography 38.0.4-3 ii python3-six 1.16.0-4 python3-fido2 recommends no packages. python3-fido2 suggests no packages. -- no debconf information
Bug#1034583: kodi-game-libretro: Joystick input doesn't work in games
Control: reassign -1 src:libretro-bsnes-mercury On Tue, Apr 18, 2023 at 09:44:57PM +, Hugh Cole-Baker wrote: > In Kodi 20 in Debian testing, game addons don't seem to receive any input from > a USB game controller. > > I have an attached USB game controller (VID 2dc8, PID 9001, 8Bitdo NES30 Pro) > which is working OK to control the user interface in Kodi to navigate menus, > etc, but when I launch a game in Kodi, the game doesn't receive any input from > the controller. The Kodi UI still seems to receive game controller input while > the game is running, for example I can press Select+Start to exit the game, > or hold Start to bring up the Kodi game settings menu, but the actual game > can't be controlled at all. > > This is a regression from the previous version, since I had the same game > controller working with the libretro-based game addons in Kodi 19 on Bullseye. There was no kodi-game-libretro that was part of Bullseye, so I think that must have been from an external repository. > I have mapped the buttons in Kodi's settings for both the default type of > controller (named "Kodi" in the UI) and the "Super Nintendo" control scheme, > and have tested and found this problem with the libretro > "kodi-game-libretro-bsnes-mercury-performance" Debian package, but also with > other libretro addons I've built locally, so I don't think it's specific to > any single libretro game addon, and the controller works fine in other Kodi > UI, so kodi-game-libretro seemed like the most appropriate package to report > the bug against. I can't comment on the local addons you've tried, but I've managed to reproduce this and the issue is with the kodi-game-libretro-bsnes-mercury-* packages. They are failing to install the buttonmap.xml into the correct subdirectory; I think what's happened is my testing left around a buttonmap.xml in the correct place, which is why I never noticed. Try: sudo mv /usr/share/kodi/addons/game.libretro.bsnes-mercury-performance/buttonmap.xml /usr/share/kodi/addons/game.libretro.bsnes-mercury-performance/resources/ which will move the button map into the correct location. > Some things I've noticed that could be useful info: > - if I hold Start while a game is running in the BSNES emulator, and go into > Settings->Controls, the Kodi UI shows "Super Nintendo" under the controller > profile, and a picture of a SNES gamepad, but under the list of "Buttons" > it says "Nothing to map". I'd sorta expect the SNES gamepad buttons to be > listed there. The controller mapping needs to be done in the main Kodi configuration screen: System -> Input -> Configure attached controllers. You should see "Super Nintendo" listed there. J. -- In case of nuclear attack, delete this message.
Bug#1035942: unblock: libretro-bsnes-mercury/094+git20220807-8
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: libretro-bsnes-merc...@packages.debian.org
Control: affects -1 + src:libretro-bsnes-mercury
Please consider unblocking libretro-bsnes-mercury. The upload fixes the
incorrect location of the buttonmap.xml file for the Kodi libretro
plugins, without which it is not possible to use game controllers with
the emulator.
[ Tests ]
Manually confirmed generated kodi-game-* debs have buttonmap.xml in
resources/ subdirectory, confirmed correct operation of game controller
with package.
[ Risks ]
This is a trivial fix that just corrects the location of the button map
for the Kodi plugins.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
unblock libretro-bsnes-mercury/094+git20220807-8
git show --stat:
commit 8fa1fad276c3ede227c0c70037a486e2ef23fa96 (HEAD -> master, tag:
debian/094+git20220807-8)
Author: Jonathan McDowell
Date: Thu May 11 10:48:30 2023 +
Fix Kodi plugins buttonmap.xml location (Closes: #1034583)
The buttonmap.xml file needs to live in the resources subdirectory, not
the parent plugin directory.
debian/changelog
| 7 +++
debian/kodi-game/game.libretro.bsnes-mercury-accuracy/{ =>
resources}/buttonmap.xml| 0
debian/kodi-game/game.libretro.bsnes-mercury-balanced/{ =>
resources}/buttonmap.xml| 0
debian/kodi-game/game.libretro.bsnes-mercury-performance/{ =>
resources}/buttonmap.xml | 0
4 files changed, 7 insertions(+)
J.
--
I'm not allowed to talk to you any more.
diff -Nru libretro-bsnes-mercury-094+git20220807/debian/changelog
libretro-bsnes-mercury-094+git20220807/debian/changelog
--- libretro-bsnes-mercury-094+git20220807/debian/changelog 2023-04-19
08:49:56.0 +
+++ libretro-bsnes-mercury-094+git20220807/debian/changelog 2023-05-11
10:47:35.0 +
@@ -1,3 +1,10 @@
+libretro-bsnes-mercury (094+git20220807-8) unstable; urgency=medium
+
+ * Team upload
+ * Fix Kodi plugins buttonmap.xml location (Closes: #1034583)
+
+ -- Jonathan McDowell Thu, 11 May 2023 10:47:35 +
+
libretro-bsnes-mercury (094+git20220807-7) unstable; urgency=medium
* Team upload
diff -Nru
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-accuracy/buttonmap.xml
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-accuracy/buttonmap.xml
---
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-accuracy/buttonmap.xml
2023-01-22 15:29:27.0 +
+++
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-accuracy/buttonmap.xml
1970-01-01 00:00:00.0 +
@@ -1,17 +0,0 @@
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff -Nru
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-accuracy/resources/buttonmap.xml
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-accuracy/resources/buttonmap.xml
---
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-accuracy/resources/buttonmap.xml
1970-01-01 00:00:00.0 +
+++
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-accuracy/resources/buttonmap.xml
2023-05-11 10:47:35.0 +
@@ -0,0 +1,17 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff -Nru
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-balanced/buttonmap.xml
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-balanced/buttonmap.xml
---
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-balanced/buttonmap.xml
2023-01-22 15:29:27.0 +
+++
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-balanced/buttonmap.xml
1970-01-01 00:00:00.0 +
@@ -1,17 +0,0 @@
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff -Nru
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-balanced/resources/buttonmap.xml
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-b
Bug#1076924: sendip: FTBFS: sendip.c:282:46: error: ‘SENDIP_LIBS’ undeclared
On Wed, Jul 24, 2024 at 12:49:47PM +0200, Santiago Vila wrote:
> Package: src:sendip
> Version: 2.6-1
> Severity: serious
> Tags: ftbfs
>
> Dear maintainer:
>
> During a rebuild of all packages in unstable, your package failed to build:
Very confused here. It build fine in my sbuild setup, and I can't figure
out how your first call to gcc has the -DSENDIP_LIBS just fine and then
all later calls seem to strip out an entire set of CFLAGs.
Can you give a clue about how to actually reproduce? When you say
"reduced chroot with only build-essential packages", how does this
actually differ from a normal sbuild setup?
>
> [...]
> debian/rules binary
> dh binary
>dh_update_autotools_config
>dh_autoreconf
>dh_auto_configure
>dh_auto_build
> make -j2 "INSTALL=install --strip-program=true"
> make[1]: Entering directory '/<>'
> gcc -g -O2 -Werror=implicit-function-declaration
> -ffile-prefix-map=/<>=. -fstack-protector-strong
> -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
> -fPIC -fsigned-char -pipe -Wall -Wpointer-arith -Wwrite-strings
> -Wstrict-prototypes -Wnested-externs -Winline -Werror -g -Wcast-align
> -DSENDIP_LIBS=\"/usr/lib/x86_64-linux-gnu/sendip\" -Wdate-time
> -D_FORTIFY_SOURCE=2 -c -o csum.o csum.c
> gcc -g -O2 -Werror=implicit-function-declaration
> -ffile-prefix-map=/<>=. -fstack-protector-strong
> -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
> -Wdate-time -D_FORTIFY_SOURCE=2 -c -o compact.o compact.c
> gcc -g -O2 -Werror=implicit-function-declaration
> -ffile-prefix-map=/<>=. -fstack-protector-strong
> -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
> -Wdate-time -D_FORTIFY_SOURCE=2 -c -o sendip.o sendip.c
> gcc -g -O2 -Werror=implicit-function-declaration
> -ffile-prefix-map=/<>=. -fstack-protector-strong
> -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
> -Wdate-time -D_FORTIFY_SOURCE=2 -c -o gnugetopt.o gnugetopt.c
> sendip.c: In function ‘load_module’:
> sendip.c:282:46: error: ‘SENDIP_LIBS’ undeclared (first use in this function)
> 282 |
> newmod->name=malloc(strlen(modname)+strlen(SENDIP_LIBS)+strlen(".so")+2);
> | ^~~
> sendip.c:282:46: note: each undeclared identifier is reported only once for
> each function it appears in
> make[1]: *** [: sendip.o] Error 1
> make[1]: *** Waiting for unfinished jobs
> make[1]: Leaving directory '/<>'
> dh_auto_build: error: make -j2 "INSTALL=install --strip-program=true"
> returned exit code 2
> make: *** [debian/rules:8: binary] Error 25
> dpkg-buildpackage: error: debian/rules binary subprocess returned exit status
> 2
>
>
> The above is just how the build ends and not necessarily the most relevant
> part.
> If required, the full build log is available here:
>
> https://people.debian.org/~sanvila/build-logs/202407/
>
> About the archive rebuild: The build was made on virtual machines
> of type m6a.large and r6a.large from AWS, using sbuild and a
> reduced chroot with only build-essential packages.
>
> If you could not reproduce the bug please contact me privately, as I
> am willing to provide ssh access to a virtual machine where the bug is
> fully reproducible.
>
> If this is really a bug in one of the build-depends, please use
> reassign and affects, so that this is still visible in the BTS web
> page for this package.
J.
--
/-\ | 101 things you can't have too much
|@/ Debian GNU/Linux Developer | of : 13 - Holidays.
\- |
Bug#413762: Fix for config structure using dynamic backends...
On Sat, Aug 11, 2007 at 05:54:32PM +0100, Brett Parker wrote: > The attached patch fixes the config structure when dynamic backends are > used - the basic issue is that when the backend was loaded, it wouldn't > (neccessarily) share the config structure with the program that called > it (and had therefore read the config). The problem with this is that we get multiple functions with the same name. I'm not sure we can be certain which will evaluate first? In particular, using the db4 backend through the dynamic backend with an error during DB initialisation causes a segfault. The initdb in keydb_db4 will call cleanupdb() when it hits an error, but this now maps to the cleanupdb() in keydb_dynamic. Which, although it calls the version in keydb_db4, will also call dlclose on the keydb_db4.so. Meaning that control returns to a function that's no longer in memory... The "easy" option is to have the cleanup end up as an internal function that cleanupdb calls, but I'd need to be certain there aren't other artifacts that will be seen from these changes. J. -- Illiterate? Write for FREE HELP! signature.asc Description: Digital signature
Bug#426894: openguides: Editing page causes Plucene error
Package: openguides Version: 0.57-3 Severity: important Editing a page in the Norwich Openguide (http://norwich.openguide.org/) leads to the following error being returned to the browser: | Can't call method "clone" on an undefined value at | /usr/share/perl5/Plucene/Index/SegmentTermEnum.pm line 98. (in cleanup) | Can't call method "clone" on an undefined value at | /usr/share/perl5/Plucene/Index/SegmentTermEnum.pm line 98. However the change does seem to get correctly saved. The only Plucene mention in the config file is: # There used to be a use_plucene configuration here, but currently, # for the Debian package, this must be left at the default. though use_plucene = 1 did exist in the pre-etch config and I note it's still a dependency of the openguides package. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.51 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages openguides depends on: ii apache2-mpm-worker [httpd] 2.2.3-4 High speed threaded model for Apac ii debconf [debconf-2.0]1.5.11 Debian configuration management sy ii libalgorithm-diff-perl 1.19.01-2 a perl library for finding Longest ii libclass-accessor-perl 0.30-1 Automated accessor generator ii libconfig-tiny-perl 2.08-1 Read/Write .ini style files with a ii libdbd-mysql-perl3.0008-1A Perl5 database interface to the ii libdbd-pg-perl 1.49-2 a PostgreSQL interface for Perl 5 ii libgeo-coordinates-utm-perl 0.05-2 Perl extension for Latitiude Longi ii libgeography-nationalgrid-pe 1.6-6 Class for a point and to transform ii libparse-recdescent-perl 1.94.free-3 Generates recursive-descent parser ii libplucene-perl 1.24-1 A Perl port of the Lucene search e ii libtemplate-perl 2.14-1 template processing system written ii liburi-perl 1.35-2 Manipulates and accesses URI strin ii libwiki-toolkit-formatter-us 0.20-2 UseModWiki-style formatting for CG ii libwiki-toolkit-perl 0.72-1 A toolkit for building Wikis ii libwiki-toolkit-plugin-categ 0.04-3 Category management for Wiki::Tool ii libwiki-toolkit-plugin-diff- 0.11-2 format differences between two Wik ii libwiki-toolkit-plugin-locat 0.05-3 A Wiki::Toolkit plugin to manage c ii libwiki-toolkit-plugin-rss-r 1.5-3 retrieve RSS feeds for inclusion i ii libwww-perl 5.805-1 WWW client/server library for Perl ii libxml-rss-perl 1.05-1 Perl module for managing RSS (RDF ii perl 5.8.8-7 Larry Wall's Practical Extraction openguides recommends no packages. -- debconf information: * openguides/check_old_upgrade: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#463929: 4.69-2 fixes it?
I noticed a new version of Exim4 had hit testing, so I tried a dist-upgrade pulling in that new version, and libpq5 8.3~rc2-1+b1. So far it seems to be working ok - mailq doesn't segfault and mail is getting delivered successfully. J. -- Web [ 101 things you can't have too much of : 16 - Time. ] site: http:// [ ] Made by www.earth.li/~noodles/ [ ] HuggieTag 0.0.23 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426894: openguides: Editing page causes Plucene error
On Tue, Jun 05, 2007 at 10:42:42PM +0100, Dominic Hargreaves wrote: > On Tue, Jun 05, 2007 at 09:39:41PM +0100, Dominic Hargreaves wrote: > > On Thu, May 31, 2007 at 04:44:12PM +0100, Jonathan McDowell wrote: > > > Editing a page in the Norwich Openguide (http://norwich.openguide.org/) > > > leads to the following error being returned to the browser: > > > > > > | Can't call method "clone" on an undefined value at > > > | /usr/share/perl5/Plucene/Index/SegmentTermEnum.pm line 98. (in cleanup) > > > | Can't call method "clone" on an undefined value at > > > | /usr/share/perl5/Plucene/Index/SegmentTermEnum.pm line 98. > > > > > > However the change does seem to get correctly saved. > > > > Can you try the following: > > > > - su - to the web server's user id > > - cd /etc/openguides/ > > - run perl /usr/share/doc/openguides/examples/reindex.pl > > - see if you can reproduce the bug > > > > I can't reproduce this on a fresh etch install so my best guess at this > > stage is that your Plucene indexes have been corrupted. > > Oh, before you perform those steps, please > rm /var/lib/openguides/indexes//* This /seems/ to have done the trick. Most odd; I'm pretty sure the point of breakage was around the sarge->etch upgrade. I'll let you know if I see it again. J. -- ] http://www.earth.li/~noodles/ [] As of next week, passwords will be [ ] PGP/GPG Key @ the.earth.li [] entered in Morse code.[ ] via keyserver, web or email. [] [ ] RSA: 4DC4E7FD / DSA: 5B430367 [] [ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#427806: referencer: Uninstallable in unstable (needs poppler patch/recompile)
Package: referencer Version: 1.0.2-1 Severity: important referencer is unfortunately uninstallable in unstable; it depends on libpoppler0c2 but this library is no longer available, having been replaced by libpoppler1. Unfortunately a simple rebuild is not sufficient; there has been an API change apparently: http://lists.debian.org/debian-release/2007/05/msg00082.html I'm uncertain if 1.0.3 or 1.0.4 fix this problem, but 1.0.2 definitely doesn't build under unstable at present. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22-rc3 (PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#427806: referencer: Uninstallable in unstable (needs poppler patch/recompile)
On Wed, Jun 06, 2007 at 04:36:17PM +0200, Michael Banck wrote: > Hi, > > On Wed, Jun 06, 2007 at 03:18:28PM +0100, Jonathan McDowell wrote: > > referencer is unfortunately uninstallable in unstable; it depends on > > libpoppler0c2 but this library is no longer available, having been > > replaced by libpoppler1. > > > > Unfortunately a simple rebuild is not sufficient; there has been an API > > change apparently: > > > > http://lists.debian.org/debian-release/2007/05/msg00082.html > > > > I'm uncertain if 1.0.3 or 1.0.4 fix this problem, but 1.0.2 definitely > > doesn't build under unstable at present. > > Did you try to build it against poppler-0.5? referencer-1.0.2 actually > pretends to require it in its configure.ac, I patched it out to build it > against 0.4.5 (which worked): > > --- referencer-1.0.2.orig/configure.in > +++ referencer-1.0.2/configure.in > @@ -33,7 +33,7 @@ > libglademm-2.4 >= 2.6.0 > gconfmm-2.6 >= 2.14.0 > gnome-vfsmm-2.6 >= 2.14.0 > - poppler >= 0.5.0 > + poppler >= 0.4.5 > ]) > > If it doesn't work, what's the build error? > > The problem with building referencer currently is an outdated gnome-mm > making trouble... Ah, yes, with poppler 0.5 installed and the rest of the build-deps from unstable I get: make[3]: Entering directory `/home/noodles/referencer-1.0.2/src' g++ -DHAVE_CONFIG_H -I. -I. -I.. -DDATADIR=\""/usr/share/referencer"\" -g -Wall -O2 -DORBIT2=1 -pthread -I/usr/include/libgnomeuimm-2.6 -I/usr/lib/libgnomeuimm-2.6/include -I/usr/include/libgnomemm-2.6 -I/usr/lib/libgnomemm-2.6/include -I/usr/include/libgnomecanvasmm-2.6 -I/usr/lib/libgnomecanvasmm-2.6/include -I/usr/include/gconfmm-2.6 -I/usr/lib/gconfmm-2.6/include -I/usr/include/libglademm-2.4 -I/usr/lib/libglademm-2.4/include -I/usr/include/libgnomeui-2.0 -I/usr/include/gnome-vfsmm-2.6 -I/usr/lib/gnome-vfsmm-2.6/include -I/usr/include/gtkmm-2.4 -I/usr/lib/gtkmm-2.4/include -I/usr/include/libgnome-2.0 -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/gdkmm-2.4 -I/usr/lib/gdkmm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/include/atkmm-1.6 -I/usr/include/gtk-2.0 -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/lib/gtk-2.0/include -I/usr/include/cairomm-1.0 -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/atk-1.0 -I/usr/include/orbit-2.0 -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/libbonobo-2.0 -I/usr/include/bonobo-activation-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/libart-2.0 -I/usr/include/libglade-2.0 -I/usr/include/libxml2 -I/usr/include/libbonoboui-2.0 -I/usr/include/gnome-keyring-1 -I/usr/include/poppler -I.. -g -Wall -O2 -c -o TagWindow.o TagWindow.C /usr/include/gconfmm-2.6/gconfmm/setinterface.h:42: warning: ‘class Gnome::Conf::SetInterface’ has virtual functions but non-virtual destructor /usr/include/gnome-vfsmm-2.6/libgnomevfsmm/mime-handlers.h:75: error: expected constructor, destructor, or type conversion before ‘*’ token make[3]: *** [TagWindow.o] Error 1 Which points to the mm stuff, not poppler. I've installed libpoppler0c2 from testing for the moment so I can actually try referencer out. J. -- jid: [EMAIL PROTECTED] noodles is not a sign of poor table manners
Bug#427815: tracker: Needs rebuilt against poppler 0.5.4
Package: tracker Version: 0.5.4-5 Severity: important tracker is currently uninstallable in unstable due to depending on libpoppler0c2-glib, which is now libpoppler1-glib with poppler 0.5.4 I have solved this locally for the moment by manually installing libpoppler0c2-glib from testing. I also tried rebuilding the tracker source package against poppler 0.5.4; this appeared to work ok but http://lists.debian.org/debian-release/2007/05/msg00082.html suggests that the API may have changed, hence filing this bug rather than blindly requesting a binNMU. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22-rc3 (PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages tracker depends on: ii dbus 1.0.2-5simple interprocess messaging syst ii libc6 2.5-10 GNU C Library: Shared libraries ii libdbus-1-3 1.0.2-5simple interprocess messaging syst ii libdbus-glib-1-2 0.73-2 simple interprocess messaging syst ii libexif12 0.6.15-1 library to parse EXIF files ii libglib2.0-0 2.12.12-1 The GLib library of C routines ii libgmime-2.0-22.2.9-1MIME library, unstable version ii libgsf-1-114 1.14.3-1 Structured File Library - runtime ii libgstreamer0.10-00.10.13-1 Core GStreamer libraries and eleme ii libmagic1 4.21-1 File type determination library us ii libpango1.0-0 1.16.4-1 Layout and rendering of internatio ii libpng12-01.2.15~beta5-2 PNG library - runtime ii libpoppler0c2-glib0.4.5-5.1 PDF rendering library (GLib-based ii libsqlite3-0 3.3.17-1 SQLite 3 shared library ii shared-mime-info 0.21-2 FreeDesktop.org shared MIME databa ii zlib1g1:1.2.3-15 compression library - runtime Versions of packages tracker recommends: ii o3read0.0.4-1standalone converter for OpenOffic ii tracker-search-tool 0.5.4-5metadata database, indexer and sea ii tracker-utils 0.5.4-5metadata database, indexer and sea ii untex 9210-10Remove LaTeX commands from input ii unzip 5.52-9 De-archiver for .zip files ii w3m 0.5.1-5.1 WWW browsable pager with excellent ii wv1.2.4-2Programs for accessing Microsoft W ii xpdf-utils [poppler-utils]3.02-1 Portable Document Format (PDF) sui ii xsltproc 1.1.20-1 XSLT command line processor -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#427818: tracker: Crashes on indexing own temporary files
Package: tracker Version: 0.5.4-5 Severity: important tracker appears to crash if it is allowed to index its own temporary files; I have TMPDIR set to ~/tmp/ and running trackerd with no parameters results in a Segmentation fault. Setting TMPDIR to /tmp or passing "-e /home/noodles/tmp" to trackerd prevents the crash, but it should be more intelligent about this itself. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22-rc3 (PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages tracker depends on: ii dbus 1.0.2-5simple interprocess messaging syst ii libc6 2.5-10 GNU C Library: Shared libraries ii libdbus-1-3 1.0.2-5simple interprocess messaging syst ii libdbus-glib-1-2 0.73-2 simple interprocess messaging syst ii libexif12 0.6.15-1 library to parse EXIF files ii libglib2.0-0 2.12.12-1 The GLib library of C routines ii libgmime-2.0-22.2.9-1MIME library, unstable version ii libgsf-1-114 1.14.3-1 Structured File Library - runtime ii libgstreamer0.10-00.10.13-1 Core GStreamer libraries and eleme ii libmagic1 4.21-1 File type determination library us ii libpango1.0-0 1.16.4-1 Layout and rendering of internatio ii libpng12-01.2.15~beta5-2 PNG library - runtime ii libpoppler0c2-glib0.4.5-5.1 PDF rendering library (GLib-based ii libsqlite3-0 3.3.17-1 SQLite 3 shared library ii shared-mime-info 0.21-2 FreeDesktop.org shared MIME databa ii zlib1g1:1.2.3-15 compression library - runtime Versions of packages tracker recommends: ii o3read0.0.4-1standalone converter for OpenOffic ii tracker-search-tool 0.5.4-5metadata database, indexer and sea ii tracker-utils 0.5.4-5metadata database, indexer and sea ii untex 9210-10Remove LaTeX commands from input ii unzip 5.52-9 De-archiver for .zip files ii w3m 0.5.1-5.1 WWW browsable pager with excellent ii wv1.2.4-2Programs for accessing Microsoft W ii xpdf-utils [poppler-utils]3.02-1 Portable Document Format (PDF) sui ii xsltproc 1.1.20-1 XSLT command line processor -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#428409: lvm2: pvmove doesn't work
Package: lvm2 Version: 2.02.24-6 Severity: normal Over the weekend I added a second disk to my box, identical to the first once. The plan was to create a RAID1 dataset by bringing up the new disk as a degraded array, copying / over to it, creating a new swap partition and then migrating the LVM volume group over (everything but / is LVMed). Bringing up the RAID1 degraded array was fine. I then did: pvcreate /dev/md2 which seemed to work fine and showed the physical volume fine. So I did: vgextend raidvg /dev/md2 which resulted in vgdisplay displaying as much free space as used in the volume group, as I expected. So I did: pvmove -v /dev/sda3 to move everything off the unraided disk and into the raid array. And that's where it went wrong. pvmove bombed out complaining about being unable to parse the progress or something similar - I'm sorry, I really should have recorded the exact error. It seemed to be complaining about "core 1", which when I ran "dmsetup status" I could see on the first line for the raidvg-pvmove0 device. pvmove --abort cleaned things up successfully, but I failed to figure out how to correctly get pvmove to operate as expected so created a new volume group on the RAID device and manually copied the filesystems over - precisely the sort of thing LVM is designed to avoid I believe, but this was my home box and I was more concerned about having it back up and running properly than avoiding downtime due to shuffling filesystems. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22-rc3 (PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages lvm2 depends on: ii libc62.5-10 GNU C Library: Shared libraries ii libdevmapper1.02.1 2:1.02.18-1 The Linux Kernel Device Mapper use ii libncurses5 5.6-3 Shared libraries for terminal hand ii libreadline5 5.2-3 GNU readline and history libraries ii libselinux1 2.0.15-2SELinux shared libraries ii libsepol12.0.3-1 Security Enhanced Linux policy lib lvm2 recommends no packages. -- debconf information: lvm2/snapshots: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#467501: grub-pc: Fails to cleanly upgrade a grub legacy box with RAID1
Package: grub-pc
Version: 1.96+20080219-2
Severity: important
I have installed grub-pc on my shiny new AMD64 box. After verifying it
loaded fine when chainloaded from legacy grub I typed
"upgrade-from-grub-legacy" and rebooted. I was rewarded with the grub
rescue shell.
For some reason it has decided that "prefix=(fd0)/boot/grub" rather than
"prefix=(md0)/boot/grub". If I do something along the lines of (from
memory, but I believe this was the rough gist):
root (md0)
set prefix=(md0)/boot/grub
insmod /boot/grub/boot.mod
normal
then I get the expected boot menu.
I can't see any sign of fd0 in /boot/grub so I'm not even sure how to
fix this locally myself at present.
-- Package-specific info:
*** BEGIN
/dev/md0 / ext3 rw,errors=remount-ro,data=ordered 0 0
/dev/md0 /dev/.static/dev ext3 rw,errors=remount-ro,data=ordered 0 0
/dev/mapper/satavg-home /home ext3 rw,data=ordered 0 0
/dev/mapper/satavg-tmp /tmp ext3 rw,data=ordered 0 0
/dev/mapper/satavg-usr /usr ext3 rw,data=ordered 0 0
/dev/mapper/satavg-var /var ext3 rw,data=ordered 0 0
*** END
*** BEGIN /boot/grub/device.map
(hd0) /dev/sda
(hd1) /dev/sdb
*** END /boot/grub/device.map
*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by /usr/sbin/update-grub using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
insmod lvm
set default=0
set timeout=5
set root=(md0)
if font (satavg-usr)/share/grub/unicode.pff ; then
set gfxmode=640x480
insmod gfxterm
insmod vbe
terminal gfxterm
fi
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
insmod png
if background_image
(satavg-usr)/share/images/desktop-base/debian-blueish-wallpaper-640x480.png ;
then
set color_normal=black/black
set color_highlight=magenta/black
else
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_hurd ###
### END /etc/grub.d/10_hurd ###
### BEGIN /etc/grub.d/10_linux ###
menuentry "Debian GNU/Linux, linux 2.6.25-rc3" {
linux (md0)/boot/vmlinuz-2.6.25-rc3 root=/dev/md0 ro quiet
initrd (md0)/boot/initrd.img-2.6.25-rc3
}
menuentry "Debian GNU/Linux, linux 2.6.25-rc3 (single-user mode)" {
linux (md0)/boot/vmlinuz-2.6.25-rc3 root=/dev/md0 ro single quiet
initrd (md0)/boot/initrd.img-2.6.25-rc3
}
menuentry "Debian GNU/Linux, linux 2.6.25-rc2-git6" {
linux (md0)/boot/vmlinuz-2.6.25-rc2-git6 root=/dev/md0 ro quiet
initrd (md0)/boot/initrd.img-2.6.25-rc2-git6
}
menuentry "Debian GNU/Linux, linux 2.6.25-rc2-git6 (single-user mode)" {
linux (md0)/boot/vmlinuz-2.6.25-rc2-git6 root=/dev/md0 ro single quiet
initrd (md0)/boot/initrd.img-2.6.25-rc2-git6
}
menuentry "Debian GNU/Linux, linux 2.6.24-1-amd64" {
linux (md0)/boot/vmlinuz-2.6.24-1-amd64 root=/dev/md0 ro quiet
initrd (md0)/boot/initrd.img-2.6.24-1-amd64
}
menuentry "Debian GNU/Linux, linux 2.6.24-1-amd64 (single-user mode)" {
linux (md0)/boot/vmlinuz-2.6.24-1-amd64 root=/dev/md0 ro single quiet
initrd (md0)/boot/initrd.img-2.6.24-1-amd64
}
menuentry "Debian GNU/Linux, linux 2.6.24" {
linux (md0)/boot/vmlinuz-2.6.24 root=/dev/md0 ro quiet
initrd (md0)/boot/initrd.img-2.6.24
}
menuentry "Debian GNU/Linux, linux 2.6.24 (single-user mode)" {
linux (md0)/boot/vmlinuz-2.6.24 root=/dev/md0 ro single quiet
initrd (md0)/boot/initrd.img-2.6.24
}
menuentry "Debian GNU/Linux, linux 2.6.22-3-amd64" {
linux (md0)/boot/vmlinuz-2.6.22-3-amd64 root=/dev/md0 ro quiet
initrd (md0)/boot/initrd.img-2.6.22-3-amd64
}
menuentry "Debian GNU/Linux, linux 2.6.22-3-amd64 (single-user mode)" {
linux (md0)/boot/vmlinuz-2.6.22-3-amd64 root=/dev/md0 ro single quiet
initrd (md0)/boot/initrd.img-2.6.22-3-amd64
}
### END /etc/grub.d/10_linux ###
*** END /boot/grub/grub.cfg
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages grub-pc depends on:
ii base-files4.0.2 Debian base system miscellaneous f
ii debconf [debconf-2.0] 1.5.19 Debian configuration management sy
ii libc6 2.7-8 GNU C Library: Shared libraries
ii liblzo1 1.08-3 data compression library (old vers
ii libncurses5 5.6+20080203-1 Shared libraries for terminal hand
grub-pc recommends no packages.
-- debconf information:
grub-pc/linux_cmdline:
* grub-pc/chainload_from_menu.lst: true
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
Bug#467501: grub-pc: Fails to cleanly upgrade a grub legacy box with RAID1
On Thu, Feb 28, 2008 at 01:22:00PM +0100, Robert Millan wrote: > Please provide the output of the following commands: > > sudo dd if=/dev/sda bs=1 count=2 skip=76 | od -tx1 meepok:~# dd if=/dev/sda bs=1 count=2 skip=76 | od -tx1 000 ff 00 002 2+0 records in 2+0 records out 2 bytes (2 B) copied, 7.1382e-05 s, 28.0 kB/s > sudo grub-setup -v "(hd0)" meepok:~# grub-setup -v "(hd0)" grub-setup: info: the size of hd0 is 488397168 grub-setup: info: opening the device `/dev/sda' grub-setup: info: the size of hd0 is 488397168 grub-setup: info: opening the device `/dev/sda' grub-setup: info: the size of hd0 is 488397168 grub-setup: info: opening the device `/dev/sda1' grub-setup: info: opening the device `/dev/sda1' grub-setup: info: the size of hd0 is 488397168 grub-setup: info: the size of hd0 is 488397168 grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: the size of hd0 is 488397168 grub-setup: info: the size of hd1 is 488397168 grub-setup: info: opening the device `/dev/sdb' grub-setup: info: the size of hd1 is 488397168 grub-setup: info: opening the device `/dev/sdb' grub-setup: info: the size of hd1 is 488397168 grub-setup: info: opening the device `/dev/sdb1' grub-setup: info: opening the device `/dev/sdb1' grub-setup: info: the size of hd1 is 488397168 grub-setup: info: the size of hd1 is 488397168 grub-setup: info: opening the device `/dev/sdb2' grub-setup: info: opening the device `/dev/sdb2' grub-setup: info: the size of hd1 is 488397168 grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda1' grub-setup: info: opening the device `/dev/sda1' grub-setup: info: the size of hd0 is 488397168 grub-setup: info: the size of hd0 is 488397168 grub-setup: info: the size of hd0 is 488397168 grub-setup: info: opening the device `/dev/sda1' grub-setup: info: opening the device `/dev/sda1' grub-setup: info: opening the device `/dev/sda1' grub-setup: info: the size of hd0 is 488397168 grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: opening the device `/dev/sda2' grub-setup: info: the size of hd0 is 488397168 grub-setup: info: the size of hd1 is 488397168 grub-setup: info: the size of hd1 is 488397168 grub-setup: info: the size of hd1 is 488397168 grub-setup: info: opening the device `/dev/sdb1' grub-setup: info: opening the device `/dev/sdb1' grub-setup: info: opening the device `/dev/sdb1' grub-setup: info: the size of hd1 is 488
Bug#467501: grub-pc: Fails to cleanly upgrade a grub legacy box with RAID1
On Thu, Feb 28, 2008 at 04:40:32PM +0100, Robert Millan wrote: > On Thu, Feb 28, 2008 at 02:23:17PM +0000, Jonathan McDowell wrote: > > I'm currently at work and the machine is my home box, but I'll try > > rebooting tonight to see if it now boots without intervention. > > Don't bother, it won't boot. Fair enough. I've gone back to legacy grub, but let me know when you think it might be sorted and I'll try again with grub2. J. -- "I put out my own fires." This .sig brought to you by the letter G and the number 22 Product of the Republic of HuggieTag -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#462154: mdadm --monitor --scan segfaults
On Tue, Jan 22, 2008 at 09:59:07PM +, Jonathan McDowell wrote: > Package: mdadm > Version: 2.6.4-1 > Severity: important > > | pot:~# mdadm --monitor --scan > | Segmentation fault I found some further information on: http://www.rigacci.org/wiki/doku.php/doc/appunti/linux/sa/raid Which states that newer kernels assemble devices read-only and mark them read-write once something is written to the device. This would make sense; /dev/md1 (the problem device in my case) is the swap partition so may well go some time without being written to. J. -- jid: [EMAIL PROTECTED] This isn't an office. It's Hell with fluorescent lighting. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#463929: exim4: Segfaults after libpq5 upgrade
Package: exim4 Version: 4.68-2 Severity: important After upgrading libpq5 from 8.2.6-1 to 8.3~rc2-1+b1 last night I started to experience exim4 segfaults; log entries like: 2008-02-03 23:51:21 1JLocK-PR-OM appendfile transport process returned non-zero status 0x000b: terminated by signal 11 and mailq would list the mailq and then segfault afterwards. Downgrading libpq5 has fixed the problem. I've filed this bug against exim instead of libpq5 as another testing box doesn't seem to have had an issue with the upgrade, though that's i386 rather than amd64. -- Package-specific info: Exim version 4.68 #1 built 01-Nov-2007 19:08:38 Copyright (c) University of Cambridge 2006 Berkeley DB: Berkeley DB 4.6.21: (September 27, 2007) Support for: crypteq iconv() IPv6 PAM Perl GnuTLS move_frozen_messages Content_Scanning Old_Demime Lookups: lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite Authenticators: cram_md5 cyrus_sasl dovecot plaintext spa Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp Fixed never_users: 0 Size of off_t: 8 Configuration file is /var/lib/exim4/config.autogenerated # /etc/exim4/update-exim4.conf.conf # # Edit this file and /etc/mailname by hand and execute update-exim4.conf # yourself or use 'dpkg-reconfigure exim4-config' # # Please note that this is _not_ a dpkg-conffile and that automatic changes # to this file might happen. The code handling this will honor your local # changes, so this is usually fine, but will break local schemes that mess # around with multiple versions of the file. # # update-exim4.conf uses this file to determine variable values to generate # exim configuration macros for the configuration file. # # Most settings found in here do have corresponding questions in the # Debconf configuration, but not all of them. # # This is a Debian specific file dc_eximconfig_configtype='internet' dc_other_hostnames='tangerine.org.uk' dc_local_interfaces='' dc_readhost='' dc_relay_domains='' dc_minimaldns='false' dc_relay_nets='' dc_smarthost='' CFILEMODE='644' dc_use_split_config='false' dc_hide_mailname='' dc_mailname_in_oh='true' dc_localdelivery='maildir_home' mailname:limegreen.tangerine.org.uk -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.18-6-xen-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages exim4 depends on: ii debconf [debconf-2.0] 1.5.18 Debian configuration management sy ii exim4-base4.68-2 support files for all Exim MTA (v4 ii exim4-daemon-heavy4.68-2 Exim MTA (v4) daemon with extended exim4 recommends no packages. -- debconf information: exim4/drec: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#463929: exim4: Segfaults after libpq5 upgrade
On Mon, Feb 04, 2008 at 01:42:20PM +0100, Marc Haber wrote: > On Mon, Feb 04, 2008 at 09:33:28AM +0000, Jonathan McDowell wrote: > > After upgrading libpq5 from 8.2.6-1 to 8.3~rc2-1+b1 last night I > > started to experience exim4 segfaults; log entries like: > > > > 2008-02-03 23:51:21 1JLocK-PR-OM appendfile transport process > > returned non-zero status 0x000b: terminated by signal 11 > > Any chance for a backtrace? There's a limit to what I can do as it involves breaking mail for people. Also it appears installing exim4-dbg forces eximon4 to be installed, which then drags in X11 libraries. Meh. limegreen:~# gdb mailq GNU gdb 6.6.90.20070912-debian Copyright (C) 2007 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu"... (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /usr/bin/mailq (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) ---Type to continue, or q to quit--- (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [New Thread 0x2ba2de5c6cc0 (LWP 2944)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x2ba2de5c6cc0 (LWP 2944)] 0x2ba2dc19eb6b in free () from /lib/libc.so.6 (gdb) bt #0 0x2ba2dc19eb6b in free () from /lib/libc.so.6 #1 0x2ba2dd5eee20 in ldap_int_destroy_global_options () at init.c:457 #2 0x2ba2dd5d4512 in __do_global_dtors_aux () from /usr/lib/libldap_r-2.4.so.2 #3 0x7fffd120ba40 in ?? () #4 0x2ba2dd5fc091 in _fini () from /usr/lib/libldap_r-2.4.so.2 #5 0x in ?? () (that's with exim4-dbg and libldap-2.4-2-dbg installed) > Greetings > Marc, guessing that this is a libpq issue Probably; the box doesn't do a lot else so I haven't noticed other issues. J. -- Life's dangerous enough without mines in the garden. This .sig brought to you by the letter O and the number 6 Product of the Republic of HuggieTag -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#463929: exim4: Segfaults after libpq5 upgrade
On Mon, Feb 04, 2008 at 02:55:38PM +0100, Marc Haber wrote: > On Mon, Feb 04, 2008 at 01:24:35PM +0000, Jonathan McDowell wrote: > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 0x2ba2de5c6cc0 (LWP 2944)] > > 0x2ba2dc19eb6b in free () from /lib/libc.so.6 > > (gdb) bt > > #0 0x2ba2dc19eb6b in free () from /lib/libc.so.6 > > #1 0x2ba2dd5eee20 in ldap_int_destroy_global_options () at init.c:457 > > #2 0x2ba2dd5d4512 in __do_global_dtors_aux () > >from /usr/lib/libldap_r-2.4.so.2 > > #3 0x7fffd120ba40 in ?? () > > #4 0x2ba2dd5fc091 in _fini () from /usr/lib/libldap_r-2.4.so.2 > > #5 0x in ?? () > > > > (that's with exim4-dbg and libldap-2.4-2-dbg installed) > > That looks like libldap is in the game. It's certainly not configured up (and nor is libpq). Let me know if I can provide any more info of use. J. -- ] http://www.earth.li/~noodles/ [] "0 tends to simplify things a bit [ ] PGP/GPG Key @ the.earth.li [] when you multiply by it..." --[ ] via keyserver, web or email. [] Bill McColl [ ] RSA: 4DC4E7FD / DSA: 5B430367 [] [ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#475036: kernel-package works for me...
I'm a bit confused by the statement that kernel-package does not work with the current set of kernels; I built a 2.6.27-rc4 kernel from vanilla upstream sources using it over the weekend (on i386) and tend to build the latest vanilla kernels as they come out on my AMD64 box. I haven't hit any issues. What sort of thing should I be looking out for? J. -- /-\ | I've got a trigger inside. |@/ Debian GNU/Linux Developer | \- | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#374783: dovecot-imapd: IPv6 support broken
Package: dovecot-imapd Version: 1.0.beta9-1 Severity: important Upgraded from 1.0.beta8-4 to 1.0.beta9-1 and dovecot-imapd no longer listens on an IPv6 TCP port. I have "listen = [::]" in my config file, which worked fine previously. Downgrading to 1.0.beta8-4 again restores IPv6 support. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages dovecot-imapd depends on: ii dovecot-common 1.0.beta9-1 secure mail server that supports m ii libc62.3.6-15GNU C Library: Shared libraries ii libssl0.9.8 0.9.8b-2SSL shared libraries dovecot-imapd recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#374783: seems to be broken in SSL only
On Sun, Jul 02, 2006 at 11:42:56AM -0400, Jaldhar H. Vyas wrote: > On Fri, 23 Jun 2006, Wouter Verhelst wrote: > >I'm seeing the same issue; however, while IMAPS does indeed not work, > >"netstat -tl" shows me that dovecot does properly listen to port 143, > >i.e., the "regular" IMAP port. > > > Hi Jonathan and Wouter, > > Upstream thinks this is fixed in 1.0rc1 which is in unstable. Can you > try it and confirm? Upgraded to 1.0.rc1-1 today and IPv6 functionality is restored. Excellent stuff - thanks. J. -- [ noodles is angry with him ] [ http://www.blackcatnetworks.co.uk/ - IPv6 enabled ADSL/dialup/colo ] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#365167: ITP: remote-tty -- multiuser "tip"/"cu" replacement with logging
Package: wnpp Severity: wishlist Owner: Jonathan McDowell <[EMAIL PROTECTED]> * Package name: remote-tty Version : 4.0 Upstream Author : Paul Vixie <[EMAIL PROTECTED]> * URL : ftp://ftp.isc.org/isc/rtty/ * License : ISC Programming Lang: C Description : multiuser "tip"/"cu" replacement with logging This is Paul Vixie's rtty serial console tool. It allows runs a server per port which then support multiple connections at time from "tip"/"cu"-like clients. It also supports logging of output from the port, even when no client is connected. This can be invaluable for post mortem diagnosis of crashes of serial consoled machines. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#373798: epiphany-browser: Silently loses bookmarks.
Package: epiphany-browser Version: 2.14.2.1-2 Severity: normal Having had epiphany suggested to me I thought I'd try it out. Used it for a couple of days, imported my Firefox bookmarks, eventually quit it. When I restarted I discovered it had lost all knowledge of my bookmarks, without any warning. I think this is related to #363637 and the mention of defaulting to "-private-instance". I get: ** (epiphany-browser:442): WARNING **: Unable to connect to session bus: Unable to determine the address of the message bus (epiphany-browser:442): libgnomevfs-WARNING **: Failed to create service browser: Bad state output when I start epiphany. Outputting to stderr for a GUI app is insane; if you're going to decide to drop my bookmarks on the floor when I quit I think you should have a dialog box say so upon starting, rather than a cryptic error message that most people won't see if they use any form of graphical launcher. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages epiphany-browser depends on: ii dbus 0.61-6simple interprocess messaging syst ii gconf2 2.14.0-1 GNOME configuration database syste ii gnome-icon-theme 2.14.2-1 GNOME Desktop icon theme ii iso-codes 0.51-1.1 ISO language, territory, currency ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi ii libatk1.0-01.11.4-2 The ATK accessibility toolkit ii libaudiofile0 0.2.6-6 Open-source version of SGI's audio ii libavahi-client3 0.6.10-1 Avahi client library ii libavahi-common3 0.6.10-1 Avahi common library ii libavahi-glib1 0.6.10-1 Avahi glib integration library ii libbonobo2-0 2.14.0-1 Bonobo CORBA interfaces library ii libbonoboui2-0 2.14.0-2 The Bonobo UI library ii libc6 2.3.6-15 GNU C Library: Shared libraries ii libcairo2 1.0.4-2 The Cairo 2D vector graphics libra ii libdbus-1-20.61-6simple interprocess messaging syst ii libdbus-glib-1-2 0.61-6simple interprocess messaging syst ii libesd-alsa0 [libesd0] 0.2.36-3 Enlightened Sound Daemon (ALSA) - ii libfontconfig1 2.3.2-7 generic font configuration library ii libfreetype6 2.2.1-2 FreeType 2 font engine, shared lib ii libgcc11:4.1.1-5 GCC support library ii libgconf2-42.14.0-1 GNOME configuration database syste ii libgcrypt111.2.2-1 LGPL Crypto library - runtime libr ii libglade2-01:2.5.1-2 library to load .glade files at ru ii libglib2.0-0 2.10.3-1 The GLib library of C routines ii libgnome-desktop-2 2.14.2-1 Utility library for loading .deskt ii libgnome-keyring0 0.4.9-1 GNOME keyring services library ii libgnome2-02.14.1-2 The GNOME 2 library - runtime file ii libgnomecanvas2-0 2.14.0-2 A powerful object-oriented display ii libgnomeprint2.2-0 2.12.1-4 The GNOME 2.2 print architecture - ii libgnomeprintui2.2-0 2.12.1-3 GNOME 2.2 print architecture User ii libgnomeui-0 2.14.1-2 The GNOME 2 libraries (User Interf ii libgnomevfs2-0 2.14.2-1 GNOME virtual file-system (runtime ii libgnutls131.3.5-1.1 the GNU TLS library - runtime libr ii libgpg-error0 1.2-1 library for common error values an ii libgtk2.0-02.8.18-1 The GTK+ graphical user interface ii libice61:1.0.0-3 X11 Inter-Client Exchange library ii libjpeg62 6b-13 The Independent JPEG Group's JPEG ii libmozjs0d 1.8.0.1-11The Mozilla SpiderMonkey JavaScrip ii libnspr4-0d1.8.0.1-11NetScape Portable Runtime Library ii liborbit2 1:2.14.0-1.1 libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.12.3-1 Layout and rendering of internatio ii libpng12-0 1.2.8rel-5.1 PNG library - runtime ii libpopt0 1.10-2lib for parsing cmdline parameters ii libsm6 1:1.0.0-4 X11 Session Management library ii libstartup-notification0 0.8-1 library for program launch feedbac ii libstdc++6 4.1.1-5 The GNU Standard C++ Library v3 ii libtasn1-2 1:0.2.17-2Manage ASN.1 structures (runtime) ii libx11-6 2:1.0.0-6 X11 client-side library ii libxcursor11.1.5.2-5
Bug#373798: epiphany-browser: Silently loses bookmarks.
On Fri, Jun 16, 2006 at 09:08:08AM +0200, Josselin Mouette wrote: > Le jeudi 15 juin 2006 à 16:31 +0100, Jonathan McDowell a écrit : > > Package: epiphany-browser > > Version: 2.14.2.1-2 > > Severity: normal > > > > Having had epiphany suggested to me I thought I'd try it out. Used it > > for a couple of days, imported my Firefox bookmarks, eventually quit it. > > When I restarted I discovered it had lost all knowledge of my bookmarks, > > without any warning. > > > > I think this is related to #363637 and the mention of defaulting to > > "-private-instance". I get: > > > > ** (epiphany-browser:442): WARNING **: Unable to connect to session bus: > > Unable to determine the address of the message bus > > > > (epiphany-browser:442): libgnomevfs-WARNING **: Failed to create service > > browser: Bad state > > > > output when I start epiphany. Outputting to stderr for a GUI app is > > insane; if you're going to decide to drop my bookmarks on the floor when > > I quit I think you should have a dialog box say so upon starting, rather > > than a cryptic error message that most people won't see if they use any > > form of graphical launcher. > > Your bookmarks are not lost. You will find them again if you correctly > start the dbus daemon. This doesn't seem to be the case. The details from the previous sessions I found living in ~/tmp/epiphany-noodles-*/ but starting up dbus (or rather, making sure Epiphany could find the already running copy) didn't make them available. It has solved the problem of bookmarks disappearing over sessions as expected though. J. -- CAFFEINE! | .''`. Debian GNU/Linux Developer | : :' : Happy to accept PGP signed | `. `' or encrypted mail - RSA + | `-DSA keys on the keyservers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#373798: epiphany-browser: Silently loses bookmarks.
On Fri, Jun 16, 2006 at 12:01:51PM +0200, Josselin Mouette wrote: > Le vendredi 16 juin 2006 à 08:49 +0100, Jonathan McDowell a écrit : > > This doesn't seem to be the case. The details from the previous sessions > > I found living in ~/tmp/epiphany-noodles-*/ but starting up dbus (or > > rather, making sure Epiphany could find the already running copy) didn't > > make them available. It has solved the problem of bookmarks disappearing > > over sessions as expected though. > Ah, I see. Bookmarks are indeed lost when they are set in a private > instance. I think we should add a warning dialog box when epiphany is > started this way. Yes, that's all I'm asking for. A cryptic error on stderr is no use for a GUI app. They shouldn't really be outputting to stderr/out at all. > I also hope this whole issue can be fixed and epiphany can be run > without a dbus daemon again. That'd be nice. I need to figure out what exactly decided to start dbus in a way that means it wasn't automatically available, but that's not epiphany's fault. :) J. -- /\ |noodles is in all his glory | | http://www.blackcatnetworks.co.uk/ | \/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#374520: O: fidogate
Package: wnpp Severity: normal fidogate needs some TLC and a combination of many other projects on the go and not running a Fidonet node mean that I'm not the right person to provide. As such I'm orphaning it effective immediately. I would suggest the new maintainer should intend to use it to connect to Fidonet or some other FTN. It needs to be moved away from debmake, updated to the latest version and changed to use debconf ideally. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#374521: RM: sslwrap -- old, unmaintained, unnecessary
Package: ftp.debian.org Severity: normal Please remove sslwrap from the archive at the earliest possible opportunity. It is unmaintained upstream; the last release was in December 2000 and there have been numerous fixes added into the Debian package since then that upstream have not responded to or folded in to mainline. It is largely unnecessary in today's internet; it dates from a time when you couldn't work on crypto easily if you were in the US, so apps couldn't include their own SSL/TLS support and had to rely on wrappers such as this. Thankfully these days are largely gone. There are better replacements; Debian has at least crywrap (Gergely, the maintainer, appears to be upstream as well) - this should handle those rare cases where a user might want to wrap a service in SSL that doesn't already support it. I think it's time to just let sslwrap die; we've been carrying it for long enough. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#374527: evince: shouldn't output errors to stderr / outputs pointless "critical" errors
Package: evince Version: 0.4.0-2 Severity: wishlist Observe: [EMAIL PROTECTED] ~]$ evince > /dev/null (evince:8903): Gtk-CRITICAL **: gtk_tree_model_foreach: assertion `GTK_IS_TREE_MODEL (model)' failed (evince:8903): Gtk-CRITICAL **: gtk_list_store_clear: assertion `GTK_IS_LIST_STORE (list_store)' failed [EMAIL PROTECTED] ~]$ The step between running the command and getting the error output is simply clicking on the File menu, then the Close option. There are 2 problems here. One is that a GUI app has no business outputting to stderr usually; in most cases the user won't see anything. The second is that outputting a "CRITICAL" error when there appears to be nothing wrong is somewhat counterintuitive. If there really is a critical error it would seem to be a severe bug that the program can't even be started and exited without hitting it. If there is not then it shouldn't print should alarming warnings. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages evince depends on: ii gconf2 2.14.0-1 GNOME configuration database syste ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi ii libatk1.0-01.11.4-2 The ATK accessibility toolkit ii libaudiofile0 0.2.6-6 Open-source version of SGI's audio ii libavahi-client3 0.6.10-1 Avahi client library ii libavahi-common3 0.6.10-1 Avahi common library ii libavahi-glib1 0.6.10-1 Avahi glib integration library ii libbonobo2-0 2.14.0-1 Bonobo CORBA interfaces library ii libbonoboui2-0 2.14.0-3 The Bonobo UI library ii libc6 2.3.6-15 GNU C Library: Shared libraries ii libcairo2 1.0.4-2 The Cairo 2D vector graphics libra ii libdbus-1-20.61-6simple interprocess messaging syst ii libdjvulibre15 3.5.17-1 Runtime support for the DjVu image ii libesd-alsa0 [libesd0] 0.2.36-3 Enlightened Sound Daemon (ALSA) - ii libfontconfig1 2.3.2-7 generic font configuration library ii libfreetype6 2.2.1-2 FreeType 2 font engine, shared lib ii libgconf2-42.14.0-1 GNOME configuration database syste ii libgcrypt111.2.2-1 LGPL Crypto library - runtime libr ii libglade2-01:2.5.1-2 library to load .glade files at ru ii libglib2.0-0 2.10.3-1 The GLib library of C routines ii libgnome-keyring0 0.4.9-1 GNOME keyring services library ii libgnome2-02.14.1-2 The GNOME 2 library - runtime file ii libgnomecanvas2-0 2.14.0-2 A powerful object-oriented display ii libgnomeprint2.2-0 2.12.1-4 The GNOME 2.2 print architecture - ii libgnomeprintui2.2-0 2.12.1-3 GNOME 2.2 print architecture User ii libgnomeui-0 2.14.1-2 The GNOME 2 libraries (User Interf ii libgnomevfs2-0 2.14.2-1 GNOME virtual file-system (runtime ii libgnutls131.4.0-2 the GNU TLS library - runtime libr ii libgpg-error0 1.2-1 library for common error values an ii libgtk2.0-02.8.18-1 The GTK+ graphical user interface ii libice61:1.0.0-3 X11 Inter-Client Exchange library ii libjpeg62 6b-13 The Independent JPEG Group's JPEG ii libkpathsea4 3.0-16path search library for teTeX (run ii libnautilus-extension1 2.14.1-5 libraries for nautilus components ii liborbit2 1:2.14.0-1.1 libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.12.3-1 Layout and rendering of internatio ii libpng12-0 1.2.8rel-5.1 PNG library - runtime ii libpoppler0c2 0.4.5-4 PDF rendering library ii libpoppler0c2-glib 0.4.5-4 PDF rendering library (GLib-based ii libpopt0 1.10-2lib for parsing cmdline parameters ii libsm6 1:1.0.0-4 X11 Session Management library ii libstdc++6 4.1.1-5 The GNU Standard C++ Library v3 ii libtasn1-2 1:0.2.17-2Manage ASN.1 structures (runtime) ii libtiff4 3.8.2-4 Tag Image File Format (TIFF) libra ii libx11-6 2:1.0.0-6 X11 client-side library ii libxcursor11.1.5.2-5 X cursor management library ii libxext6 1:1.0.0-4 X11 miscellaneous extension librar ii libxfixes3 1:3.0.1.2-4 X11 miscellaneous 'fixes' extensio ii libxi6 1:1.0.0-5 X11
Bug#374529: gajim: should default to "aplay -q" rather than "aplay" for sounds
Package: gajim Version: 0.10.1-1 Severity: wishlist gajim defaults to using aplay to play sounds, however it should really use "aplay -q" as otherwise aplay spews "Playing WAVE " messages to stdout. There's no reason a GUI app should be outputting this sort of thing, and the -q switch makes aplay be appropriately quiet. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages gajim depends on: ii libaspell15 0.60.4-4GNU Aspell spell-checker runtime l ii libatk1.0-0 1.11.4-2The ATK accessibility toolkit ii libc62.3.6-15GNU C Library: Shared libraries ii libcairo21.0.4-2 The Cairo 2D vector graphics libra ii libfontconfig1 2.3.2-7 generic font configuration library ii libglib2.0-0 2.10.3-1The GLib library of C routines ii libgtk2.0-0 2.8.18-1The GTK+ graphical user interface ii libgtkspell0 2.0.10-3+b1 a spell-checking addon for GTK's T ii libpango1.0-01.12.3-1Layout and rendering of internatio ii libx11-6 2:1.0.0-6 X11 client-side library ii libxcursor1 1.1.5.2-5 X cursor management library ii libxext6 1:1.0.0-4 X11 miscellaneous extension librar ii libxfixes3 1:3.0.1.2-4 X11 miscellaneous 'fixes' extensio ii libxi6 1:1.0.0-5 X11 Input extension library ii libxinerama1 1:1.0.1-4 X11 Xinerama extension library ii libxrandr2 2:1.1.0.2-4 X11 RandR extension library ii libxrender1 1:0.9.0.2-4 X Rendering Extension client libra ii libxss1 1:1.0.1-4 X11 Screen Saver extension library ii python2.42.4.3-7 An interactive high-level object-o ii python2.4-glade2 2.8.2-3 GTK+ bindings: Glade support ii python2.4-gtk2 2.8.2-3 Python bindings for the GTK+ widge ii python2.4-pysqlite2 2.2.2-1 python interface to SQLite 3 Versions of packages gajim recommends: ii dnsutils 1:9.3.2-2 Clients provided with BIND pn notification-daemon(no description available) ii python2.4-dbus0.61-6 simple interprocess messaging syst -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#374530: liferea: outputs "Unhandled property: 12 border-collapse" on selecting any post
Package: liferea Version: 1.0.12-1 Severity: wishlist Every time I select a post in liferea it outputs: Unhandled property: 12 border-collapse to the xterm it was started in. There's no reason it should do this; it's a GUI app and if it has something to say it should output it in a dialog box and otherwise it should be quiet. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages liferea depends on: ii dbus-1-utils 0.61-6simple interprocess messaging syst ii gconf2 2.14.0-1 GNOME configuration database syste ii libatk1.0-01.11.4-2 The ATK accessibility toolkit ii libc6 2.3.6-15 GNU C Library: Shared libraries ii libcairo2 1.0.4-2 The Cairo 2D vector graphics libra ii libdbus-1-20.61-6simple interprocess messaging syst ii libdbus-glib-1-2 0.61-6simple interprocess messaging syst ii libfontconfig1 2.3.2-7 generic font configuration library ii libgconf2-42.14.0-1 GNOME configuration database syste ii libglib2.0-0 2.10.3-1 The GLib library of C routines ii libgtk2.0-02.8.18-1 The GTK+ graphical user interface ii liborbit2 1:2.14.0-1.1 libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.12.3-1 Layout and rendering of internatio ii libx11-6 2:1.0.0-6 X11 client-side library ii libxcursor11.1.5.2-5 X cursor management library ii libxext6 1:1.0.0-4 X11 miscellaneous extension librar ii libxfixes3 1:3.0.1.2-4 X11 miscellaneous 'fixes' extensio ii libxi6 1:1.0.0-5 X11 Input extension library ii libxinerama1 1:1.0.1-4 X11 Xinerama extension library ii libxml22.6.26.dfsg-1 GNOME XML library ii libxrandr2 2:1.1.0.2-4 X11 RandR extension library ii libxrender11:0.9.0.2-4 X Rendering Extension client libra ii liferea-gtkhtml1.0.12-1 gtkhtml-based rendering library fo ii zlib1g 1:1.2.3-11compression library - runtime liferea recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#374530: liferea: outputs "Unhandled property: 12 border-collapse" on selecting any post
On Mon, Jun 19, 2006 at 11:31:32PM +0200, Lars Lindner wrote: > Am Montag, den 19.06.2006, 21:25 +0100 schrieb Jonathan McDowell: > > Package: liferea > > Version: 1.0.12-1 > > Severity: wishlist > > > > Every time I select a post in liferea it outputs: > > > > Unhandled property: 12 border-collapse > > > > to the xterm it was started in. There's no reason it should do this; > > it's a GUI app and if it has something to say it should output it in a > > dialog box and otherwise it should be quiet. > > Thanks for deciding to post a bug :-) I figure I'm going to get known as the kook that reads stdout/err for GUI apps. However I did get some support for wanting to file such bugs, so I thought I should do so. > I think this is a problem with libgtkhtml2 which outputs every unknown > CSS tag it encounters. And Liferea relies on the border-collapse > attribute to correctly render items with Mozilla. If you believe it's libgtkhtml2 then I'm happy for you to reassign the bug to that package; I won't do so myself as I'm not familiar with that library. J. -- noodles is back group| Black Cat Networks Ltd | http://www.blackcatnetworks.co.uk/ | UK Web, domain and email hosting -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#368848: autoconf: breaks -o /dev/null
Package: autoconf Version: 2.59.cvs.2006.05.13-1 Severity: normal The most recent version of autoconf in the archive appears to break the use of "-o /dev/null"; it tries to open /dev/null.tmp which of course fails when run as a normal user. I noticed this when trying to build automake, as automake's configure script uses this feature of autoconf. Downgrading to 2.59a-9 makes it work again. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages autoconf depends on: ii debianutils 2.16.1 Miscellaneous utilities specific t ii m41.4.4-1a macro processing language ii perl 5.8.8-4Larry Wall's Practical Extraction Versions of packages autoconf recommends: ii automake1.4 [automaken] 1:1.4-p6-9 A tool for generating GNU Standard ii automake1.9 [automaken] 1.9.6-4A tool for generating GNU Standard -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367661: [PATCH] initramfs support
I've recently had call to use dmraid for my root disk and as such needed
this support. I've attached the patch I took from Ubuntu and applied to
the Debian package, which makes it work fine for me. Please consider
applying this (and also fixing #367796 - I found moving dmraid to 04
from 03 did the trick).
Thanks,
J.
--
jid: [EMAIL PROTECTED]
"What the f**k was that?" -- Mayor of
Hiroshima
diff -ruN dmraid-0.9.9+1.0.0.rc9.orig/debian/changelog
dmraid-0.9.9+1.0.0.rc9/debian/changelog
--- dmraid-0.9.9+1.0.0.rc9.orig/debian/changelog2006-07-17
15:32:52.0 +0100
+++ dmraid-0.9.9+1.0.0.rc9/debian/changelog 2006-07-16 19:44:03.0
+0100
@@ -1,3 +1,11 @@
+dmraid (0.9.9+1.0.0.rc9-3.1) dapper; urgency=low
+
+ * Include the initramfs hook and script contributed by Tormod Volden,
+so dmraid can integrate effortlessly (closes: launchpad.net/22107)
+ * Call update-initramfs in our postinst, if we have it on the system.
+
+ -- Adam Conrad <[EMAIL PROTECTED]> Wed, 17 May 2006 19:16:59 +1000
+
dmraid (0.9.9+1.0.0.rc9-3) unstable; urgency=low
* add dmraid-udeb by popular request, looking forward for d-i integration
diff -ruN dmraid-0.9.9+1.0.0.rc9.orig/debian/dmraid.initramfs-hook
dmraid-0.9.9+1.0.0.rc9/debian/dmraid.initramfs-hook
--- dmraid-0.9.9+1.0.0.rc9.orig/debian/dmraid.initramfs-hook1970-01-01
01:00:00.0 +0100
+++ dmraid-0.9.9+1.0.0.rc9/debian/dmraid.initramfs-hook 2006-07-16
19:43:15.0 +0100
@@ -0,0 +1,26 @@
+#!/bin/sh
+
+PREREQ=""
+
+prereqs()
+{
+ echo "$PREREQ"
+}
+
+case $1 in
+# get pre-requisites
+prereqs)
+ prereqs
+ exit 0
+ ;;
+esac
+
+. /usr/share/initramfs-tools/hook-functions
+
+if [ -x /sbin/dmraid ]; then
+ manual_add_modules dm-mod
+ manual_add_modules dm-mirror
+ copy_exec /sbin/dmraid sbin
+fi
+
+exit 0
diff -ruN dmraid-0.9.9+1.0.0.rc9.orig/debian/dmraid.initramfs-local
dmraid-0.9.9+1.0.0.rc9/debian/dmraid.initramfs-local
--- dmraid-0.9.9+1.0.0.rc9.orig/debian/dmraid.initramfs-local 1970-01-01
01:00:00.0 +0100
+++ dmraid-0.9.9+1.0.0.rc9/debian/dmraid.initramfs-local2006-07-17
15:31:00.0 +0100
@@ -0,0 +1,22 @@
+#!/bin/sh
+
+PREREQ="udev"
+
+prereqs()
+{
+echo "$PREREQ"
+}
+
+case $1 in
+# get pre-requisites
+prereqs)
+prereqs
+exit 0
+;;
+esac
+
+modprobe dm-mod
+modprobe dm-mirror
+
+[ -x /sbin/dmraid ] && /sbin/dmraid -ay
+
diff -ruN dmraid-0.9.9+1.0.0.rc9.orig/debian/dmraid.postinst
dmraid-0.9.9+1.0.0.rc9/debian/dmraid.postinst
--- dmraid-0.9.9+1.0.0.rc9.orig/debian/dmraid.postinst 1970-01-01
01:00:00.0 +0100
+++ dmraid-0.9.9+1.0.0.rc9/debian/dmraid.postinst 2006-07-16
19:43:15.0 +0100
@@ -0,0 +1,13 @@
+#! /bin/sh
+
+set -e
+
+#DEBHELPER#
+
+case "$1" in
+ configure)
+if [ -x /usr/sbin/update-initramfs ]; then
+ /usr/sbin/update-initramfs -u
+fi
+ ;;
+esac
diff -ruN dmraid-0.9.9+1.0.0.rc9.orig/debian/rules
dmraid-0.9.9+1.0.0.rc9/debian/rules
--- dmraid-0.9.9+1.0.0.rc9.orig/debian/rules2006-07-17 15:32:52.0
+0100
+++ dmraid-0.9.9+1.0.0.rc9/debian/rules 2006-07-16 19:43:15.0 +0100
@@ -73,6 +73,11 @@
cd ${buildroot}/standard && make DESTDIR=../../../dmraid install && rm
-rf debian/dmraid/lib
+ install -m 755 -D debian/dmraid.initramfs-hook \
+ debian/dmraid/usr/share/initramfs-tools/hooks/dmraid
+ install -m 755 -D debian/dmraid.initramfs-local \
+ debian/dmraid/usr/share/initramfs-tools/scripts/local-top/dmraid
+
dh_link
dh_installdocs ${version}/{CREDITS,KNOWN_BUGS,README,TODO}
dh_installchangelogs ${version}/CHANGELOG
Bug#264007: Add support for ucarp to /etc/network/interfaces
Package: ucarp
Version: 1.2-1
Followup-For: Bug #264007
The attached patch allows configuration of ucarp via
/etc/network/interfaces; I think it's probably the sanest way of
configuring ucarp and allowing multiple interfaces while still fitting
in with the Debian way of doing things.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17.6
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Versions of packages ucarp depends on:
ii libc6 2.3.6-15 GNU C Library: Shared libraries
ii libpcap0.70.7.2-7System interface for user-level pa
Versions of packages ucarp recommends:
ii iproute 20051007-4 Professional tools to control the
-- no debconf information
diff -ruN ucarp-1.2/debian/if-up ucarp-1.2-new/debian/if-up
--- ucarp-1.2/debian/if-up 1970-01-01 01:00:00.0 +0100
+++ ucarp-1.2-new/debian/if-up 2006-07-21 21:53:19.0 +0100
@@ -0,0 +1,22 @@
+#!/bin/sh
+
+UCARP=/usr/sbin/ucarp
+
+if [ ! -x $UCARP ]; then
+ exit 0
+fi
+
+if [ -z "$IF_UCARP_UPSCRIPT" ]; then
+ IF_UCARP_UPSCRIPT=/usr/share/ucarp/vip-up
+fi
+
+if [ -z "$IF_UCARP_DOWNSCRIPT" ]; then
+ IF_UCARP_DOWNSCRIPT=/usr/share/ucarp/vip-down
+fi
+
+if [ -n "$IF_UCARP_VID" -a -n "$IF_UCARP_VIP" -a \
+ -n "$IF_UCARP_PASSWORD" ]; then
+ $UCARP -i $IFACE -s $IF_ADDRESS -B \
+ -v $IF_UCARP_VID -p $IF_UCARP_PASSWORD -a $IF_UCARP_VIP \
+ -u $IF_UCARP_UPSCRIPT -d $IF_UCARP_DOWNSCRIPT
+fi
diff -ruN ucarp-1.2/debian/README.Debian ucarp-1.2-new/debian/README.Debian
--- ucarp-1.2/debian/README.Debian 2006-07-21 22:01:43.0 +0100
+++ ucarp-1.2-new/debian/README.Debian 2006-07-21 22:01:06.0 +0100
@@ -1,7 +1,27 @@
ucarp for Debian
-Check out the sample scripts in /usr/share/docs/examples for ideas on
-upscript/downscript usage.
+ucarp can be configured via /etc/network/interfaces. For example:
+
+iface eth0 inet static
+ address 10.0.0.2
+ netmask 255.255.255.0
+ ucarp-vid 3
+ ucarp-vip 10.0.0.1
+ ucarp-password 16charsatmost
+iface eth0:ucarp inet static
+ address 10.0.0.1
+ netmask 255.255.255.255
+
+will cause ucarp to be started when eth0 is brought up, using a vid of 3
+and a password of 16charsatmost with the virtual IP of 10.0.0.1. When ucarp
+determines that this host is the master eth0:ucarp will be brought up -
+you can use the normal pre-up/up stanzas in /etc/network/interfaces if you
+have extra things to do when the virtual IP comes up.
+
+You can also override the default up/down scripts
+(/usr/share/ucarp/vip-{down,up}) by using the ucarp-upscript and
+ucarp-downscript options. Note that you must ensure your scripts take
+care of bringing the VIP up and down if you do this.
-- Eric Evans <[EMAIL PROTECTED]>, Fri, 30 Apr 2004 01:50:44 +
diff -ruN ucarp-1.2/debian/rules ucarp-1.2-new/debian/rules
--- ucarp-1.2/debian/rules 2006-07-21 22:01:43.0 +0100
+++ ucarp-1.2-new/debian/rules 2006-07-21 21:53:32.0 +0100
@@ -57,6 +57,14 @@
dh_installdirs
$(MAKE) install DESTDIR=$(CURDIR)/debian/ucarp
+ install -d $(CURDIR)/debian/ucarp/etc/network/if-up.d
+ install -d $(CURDIR)/debian/ucarp/usr/share/ucarp
+ install -m 755 $(CURDIR)/debian/if-up \
+ $(CURDIR)/debian/ucarp/etc/network/if-up.d/ucarp
+ install -m 755 $(CURDIR)/debian/vip-up \
+ $(CURDIR)/debian/ucarp/usr/share/ucarp/vip-up
+ install -m 755 $(CURDIR)/debian/vip-down \
+ $(CURDIR)/debian/ucarp/usr/share/ucarp/vip-down
# Build architecture-independent files here.
diff -ruN ucarp-1.2/debian/vip-down ucarp-1.2-new/debian/vip-down
--- ucarp-1.2/debian/vip-down 1970-01-01 01:00:00.0 +0100
+++ ucarp-1.2-new/debian/vip-down 2006-07-21 21:38:40.0 +0100
@@ -0,0 +1,3 @@
+#!/bin/sh
+
+/sbin/ifdown $1:ucarp
diff -ruN ucarp-1.2/debian/vip-up ucarp-1.2-new/debian/vip-up
--- ucarp-1.2/debian/vip-up 1970-01-01 01:00:00.0 +0100
+++ ucarp-1.2-new/debian/vip-up 2006-07-21 21:38:43.0 +0100
@@ -0,0 +1,3 @@
+#!/bin/sh
+
+/sbin/ifup $1:ucarp
Bug#367796: dmraid: [PATCH] Move init script to 04
Package: dmraid Version: 0.9.9+1.0.0.rc9-3.1 Followup-For: Bug #367796 The attached patch moves the init script to S04dmraid so that we run after udev has completed. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17.6 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages dmraid depends on: ii libc62.3.6-15GNU C Library: Shared libraries ii libdevmapper1.02 2:1.02.07-1 The Linux Kernel Device Mapper use ii libselinux1 1.30-1 SELinux shared libraries ii lsb-base 3.1-10 Linux Standard Base 3.1 init scrip dmraid recommends no packages. -- no debconf information diff -ruN dmraid-0.9.9+1.0.0.rc9.orig/debian/rules dmraid-0.9.9+1.0.0.rc9/debian/rules --- dmraid-0.9.9+1.0.0.rc9.orig/debian/rules2006-07-17 15:32:52.0 +0100 +++ dmraid-0.9.9+1.0.0.rc9/debian/rules 2006-07-24 18:42:23.0 +0100 @@ -82,7 +82,7 @@ binary-arch: install dh_testdir dh_testroot - dh_installinit -p dmraid -- start 03 S . start 51 0 6 . + dh_installinit -p dmraid -- start 04 S . start 51 0 6 . dh_strip -a dh_compress -a dh_fixperms -a
Bug#430782: liferea: Fails to display LJ entries using ljuser
Package: liferea Version: 1.2.16b-1 Severity: normal Liferea has recently stopped working with LiveJournal entries that reference other LJ users. In particular it outputs something like: XML Parsing Error: prefix not bound to a namespace Location: file:/// Line Number 456, Column 3508: Where the code in question is: I guess this may be a libxul issue, or something LJ have changed, but it didn't used to do it and if I view the RSS URL in Iceweasel it works ok. See: http://j4.livejournal.com/data/rss for an example of the problem - the Glast-oh-no entry exhibits the problem. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22-rc3 (PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages liferea depends on: ii gconf2 2.18.0.1-3 GNOME configuration database syste ii libatk1.0-0 1.18.0-2 The ATK accessibility toolkit ii libc6 2.5-11 GNU C Library: Shared libraries ii libcairo2 1.4.8-1 The Cairo 2D vector graphics libra ii libdbus-1-3 1.1.1-1 simple interprocess messaging syst ii libdbus-glib-1-20.73-2 simple interprocess messaging syst ii libfontconfig1 2.4.2-1.2generic font configuration library ii libgcc1 1:4.2-20070609-1 GCC support library ii libgconf2-4 2.18.0.1-3 GNOME configuration database syste ii libgcrypt11 1.2.4-2 LGPL Crypto library - runtime libr ii libglib2.0-02.12.12-1The GLib library of C routines ii libgnutls13 1.6.3-1 the GNU TLS library - runtime libr ii libgtk2.0-0 2.10.13-1The GTK+ graphical user interface ii libice6 1:1.0.3-2X11 Inter-Client Exchange library ii liblua505.0.3-2 Main interpreter library for the L ii liblualib50 5.0.3-2 Extension library for the Lua 5.0 ii libnm-glib0 0.6.4-8+b1 network management framework (GLib ii libnotify1 [libnotify1- 0.4.4-3 sends desktop notifications to a n ii libnspr4-0d 4.6.6-3 NetScape Portable Runtime Library ii liborbit2 1:2.14.7-0.1 libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.16.4-1 Layout and rendering of internatio ii libsm6 2:1.0.3-1X11 Session Management library ii libstdc++6 4.2-20070609-1 The GNU Standard C++ Library v3 ii libx11-62:1.0.3-7X11 client-side library ii libxcursor1 1:1.1.8-2X cursor management library ii libxext61:1.0.3-2X11 miscellaneous extension librar ii libxfixes3 1:4.0.3-2X11 miscellaneous 'fixes' extensio ii libxi6 1:1.0.1-4X11 Input extension library ii libxinerama11:1.0.2-1X11 Xinerama extension library ii libxml2 2.6.29.dfsg-1GNOME XML library ii libxrandr2 2:1.2.1-1X11 RandR extension library ii libxrender1 1:0.9.2-1X Rendering Extension client libra ii libxslt1.1 1.1.21-1 XSLT processing library - runtime ii libxul0d1.8.1.4-2Gecko engine library ii zlib1g 1:1.2.3-15 compression library - runtime Versions of packages liferea recommends: ii dbus 1.1.1-1simple interprocess messaging syst ii dbus-x11 1.1.1-1simple interprocess messaging syst -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#430926: evilwm: Please update package to 1.0.0
Package: evilwm Version: 0.99.21-1 Severity: wishlist I note that the evilwm package lags somewhat behind upstream releases; 0.99.21 was released on 2006-01-16 and there have been several releases since then. 1.0.0 appears to be the most recent, from earlier this month. As you appear to be upstream but not a Debian developer, is the issue one of needing someone to sponsor an upload? If so then I'm prepared to consider this. If instead the issue is that you're no longer interested in Debian then would you object to an NMU for a more recent version? -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22-rc3 (PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages evilwm depends on: ii libc6 2.5-11 GNU C Library: Shared libraries ii libx11-6 2:1.0.3-7 X11 client-side library ii libxext6 1:1.0.3-2 X11 miscellaneous extension librar evilwm recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#430926: evilwm: Please update package to 1.0.0
On Thu, Jun 28, 2007 at 03:32:29PM +0100, Ciaran Anscomb wrote: > Jonathan McDowell wrote: > > > > I note that the evilwm package lags somewhat behind upstream releases; > > 0.99.21 was released on 2006-01-16 and there have been several releases > > since then. 1.0.0 appears to be the most recent, from earlier this > > month. > > > > As you appear to be upstream but not a Debian developer, is the issue > > one of needing someone to sponsor an upload? If so then I'm prepared to > > consider this. If instead the issue is that you're no longer interested > > in Debian then would you object to an NMU for a more recent version? > > Purely the needing someone to sponsor. I don't update often, and the last > time I tried to contact a previous sponsor, things got quite confused. > Well, *I* got quite confused. > > Anyway, I try to keep the Debian metadata up to date in case someone > offers, so I'd be very happy for you to sponsor in a new version: > > http://www.6809.org.uk/tmp/evilwm/ > > Hopefully that's up to current standards - I started mostly from scratch > with current dh_make output. Excellent. The diff is nice and small, so I've had a look over it, compiled it up and installed it locally. Seems to all be fine, so I'll upload now - only change is to add a Closes: to the changelog for this bug. Feel free to give me a prod next time you do a release; I can't promise I'll have time to help, but I'll try not to get confused. :) J. -- jid: [EMAIL PROTECTED] noodles is not a sign of poor table manners -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#445387: liferea: Segfaults when trying to add new feed
Package: liferea Version: 1.4.3-1 Severity: important If I do the following: * Click on "New Subscription" * Click on "Advanced" * Click the radio button "Local file" * Click "Select File" then Liferea segfaults. It does this even if I remove my own config and let it use its defaults. I've attached the output from --debug-all -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22.6 (PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages liferea depends on: ii gconf2 2.20.0-1 GNOME configuration database syste ii libatk1.0-0 1.20.0-1 The ATK accessibility toolkit ii libc6 2.6.1-5 GNU C Library: Shared libraries ii libcairo2 1.4.10-1 The Cairo 2D vector graphics libra ii libdbus-1-3 1.1.1-3 simple interprocess messaging syst ii libdbus-glib-1-20.74-1 simple interprocess messaging syst ii libfontconfig1 2.4.2-1.2generic font configuration library ii libgcc1 1:4.2.1-6GCC support library ii libgconf2-4 2.20.0-1 GNOME configuration database syste ii libgcrypt11 1.2.4-2 LGPL Crypto library - runtime libr ii libglade2-0 1:2.6.2-1library to load .glade files at ru ii libglib2.0-02.14.1-4 The GLib library of C routines ii libgnutls13 2.0.1-1 the GNU TLS library - runtime libr ii libgtk2.0-0 2.12.0-2 The GTK+ graphical user interface ii libice6 2:1.0.4-1X11 Inter-Client Exchange library ii liblua5.1-0 5.1.2-3 Simple, extensible, embeddable pro ii libnm-glib0 0.6.5-2 network management framework (GLib ii libnotify1 [libnotify1- 0.4.4-3 sends desktop notifications to a n ii libnspr4-0d 4.6.7-1 NetScape Portable Runtime Library ii liborbit2 1:2.14.7-0.1 libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.18.2-1 Layout and rendering of internatio ii libsm6 2:1.0.3-1+b1 X11 Session Management library ii libsqlite3-03.4.2-1 SQLite 3 shared library ii libstdc++6 4.2.1-6 The GNU Standard C++ Library v3 ii libx11-62:1.0.3-7X11 client-side library ii libxcomposite1 1:0.3.2-1+b1 X11 Composite extension library ii libxcursor1 1:1.1.9-1X cursor management library ii libxdamage1 1:1.1.1-3X11 damaged region extension libra ii libxext61:1.0.3-2X11 miscellaneous extension librar ii libxfixes3 1:4.0.3-2X11 miscellaneous 'fixes' extensio ii libxi6 2:1.1.3-1X11 Input extension library ii libxinerama11:1.0.2-1X11 Xinerama extension library ii libxml2 2.6.30.dfsg-2GNOME XML library ii libxrandr2 2:1.2.2-1X11 RandR extension library ii libxrender1 1:0.9.4-1X Rendering Extension client libra ii libxslt1.1 1.1.22-1 XSLT processing library - runtime ii libxul0d1.8.1.6-1Gecko engine library ii zlib1g 1:1.2.3.3.dfsg-6 compression library - runtime Versions of packages liferea recommends: ii dbus 1.1.1-3simple interprocess messaging syst ii dbus-x11 1.1.1-3simple interprocess messaging syst -- no debconf information libnm_glib_nm_state_cb: dbus returned an error. (org.freedesktop.DBus.Error.ServiceUnknown) The name org.freedesktop.NetworkManager was not provided by any .service files ** (liferea:9643): WARNING **: Dropping view failed (no such table: view_igkusyk) SQL: DROP VIEW view_igkusyk; ** (liferea:9643): WARNING **: Dropping view failed (no such table: view_ycibljp) SQL: DROP VIEW view_ycibljp; (gecko:9643): GLib-GObject-WARNING **: invalid unclassed pointer in cast to `GObject' (gecko:9643): GLib-GObject-CRITICAL **: g_object_get_data: assertion `G_IS_OBJECT (object)' failed ** (gecko:9643): WARNING **: Fatal: liferea_dialog_lookup() called with something that is not a Liferea dialog! (gecko:9643): Gtk-CRITICAL **: gtk_entry_get_text: assertion `GTK_IS_ENTRY (entry)' failed lr.stdout.gz Description: GNU Zip compressed data
Bug#425359: workrave window no longer appears
Package: workrave Version: 1.8.4-2 Severity: important workrave no longer displays its little window; when it starts up it briefly flashes up, but then disappears. workrave continues to run in the background, but with nothing visible. This obviously makes it a bit useless. I don't run any form of panel, so I've no idea if it would still be displaying in that. I've attached a strace of startup. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22-rc1 (PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages workrave depends on: ii libart-2.0-22.3.19-3 Library of functions for 2D graphi ii libatk1.0-0 1.18.0-2 The ATK accessibility toolkit ii libbonobo2-02.18.0-2 Bonobo CORBA interfaces library ii libbonoboui2-0 2.18.0-5 The Bonobo UI library ii libc6 2.5-7GNU C Library: Shared libraries ii libcairo2 1.4.6-1 The Cairo 2D vector graphics libra ii libfontconfig1 2.4.2-1.2generic font configuration library ii libgcc1 1:4.2-20070516-1 GCC support library ii libgconf2-4 2.18.0.1-3 GNOME configuration database syste ii libgconfmm-2.6-1c2 2.14.2-1 C++ wrappers for GConf (shared lib ii libglade2-0 1:2.6.0-4library to load .glade files at ru ii libglademm-2.4-1c2a 2.6.2-2 C++ wrappers for libglade2 (shared ii libglib2.0-02.12.12-1The GLib library of C routines ii libglibmm-2.4-1c2a 2.12.9-0.1 C++ wrapper for the GLib toolkit ( ii libgnet2.0-02.0.7-1 GNet network library ii libgnome-keyring0 0.8.1-2 GNOME keyring services library ii libgnome-vfsmm-2.6-1c2a 2.14.0-1 C++ wrappers for GnomeVFS (shared ii libgnome2-0 2.18.0-4 The GNOME 2 library - runtime file ii libgnomecanvas2-0 2.14.0-2 A powerful object-oriented display ii libgnomecanvasmm-2.6-1c 2.14.0-1 C++ wrappers for libgnomecanvas2 ( ii libgnomemm-2.6-1c2 2.14.0-1 C++ wrappers for libgnome (shared ii libgnomeui-02.18.1-2 The GNOME 2 libraries (User Interf ii libgnomeuimm-2.6-1c2a 2.14.0-1 C++ wrappers for libgnomeui (share ii libgnomevfs2-0 1:2.18.1-2 GNOME Virtual File System (runtime ii libgtk2.0-0 2.10.12-2The GTK+ graphical user interface ii libgtkmm-2.4-1c2a 1:2.10.10-0.2C++ wrappers for GTK+ 2.4 (shared ii libice6 1:1.0.3-2X11 Inter-Client Exchange library ii liborbit2 1:2.14.7-0.1 libraries for ORBit2 - a CORBA ORB ii libpanel-applet2-0 2.18.1-1+b1 library for GNOME 2 panel applets ii libpango1.0-0 1.16.4-1 Layout and rendering of internatio ii libpopt01.10-3 lib for parsing cmdline parameters ii libsigc++-2.0-0c2a 2.0.17-2 type-safe Signal Framework for C++ ii libsm6 2:1.0.3-1X11 Session Management library ii libstdc++6 4.2-20070516-1 The GNU Standard C++ Library v3 ii libx11-62:1.0.3-7X11 client-side library ii libxcursor1 1:1.1.8-2X cursor management library ii libxext61:1.0.3-2X11 miscellaneous extension librar ii libxfixes3 1:4.0.3-2X11 miscellaneous 'fixes' extensio ii libxi6 1:1.0.1-4X11 Input extension library ii libxinerama11:1.0.2-1X11 Xinerama extension library ii libxml2 2.6.28.dfsg-1GNOME XML library ii libxmu6 1:1.0.3-1X11 miscellaneous utility library ii libxrandr2 2:1.2.1-1X11 RandR extension library ii libxrender1 1:0.9.2-1X Rendering Extension client libra ii libxtst61:1.0.1-5X11 Testing -- Resource extension workrave recommends no packages. -- no debconf information workrave.strace.bz2 Description: BZip2 compressed data
Bug#425359: workrave window no longer appears
On Mon, May 21, 2007 at 01:11:31PM +0200, Michael Piefel wrote: > Am Montag, den 21.05.2007, 09:21 +0100 schrieb Jonathan McDowell: > > workrave no longer displays its little window; > > [...] I don't run any form of panel > > Does typing the following: > > $ gconftool --type bool --set /apps/workrave/gui/main_window/enabled true > > do any good? Yes, that brings it back. Thanks. I don't believe I changed anything that would have altered this however. J. -- [ 101 things you can't have too much of : 51 - News. ] signature.asc Description: Digital signature
Bug#540828: Potentially interesting in taking over
I'm using sg3-utils quite a bit in work so I might possibly be interested in taking over maintenance. Not retitling until I've had a closer look at what's involved, just registering interest at present. J. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#542379: Please package a newer drm-snapshot including libdrm-radeon
Package: drm-snapshot Version: 2.4.11+git+20090630+de1ed01-1 Severity: wishlist Please update the version of drm-snapshot in experimental to something that's actually more recent than the released version in unstable/testing. :) Also please include libdrm-radeon to facilitate building a KMS enabled radeon X server. (Discussed with lamby on IRC; Eric added to CC because I believe he's interested in the same thing from his posts to debian-x.) Thanks, J. -- ] http://www.earth.li/~noodles/ [] 101 things you can't have too much [ ] PGP/GPG Key @ the.earth.li [] of : 44 - Fame. [ ] via keyserver, web or email. [] [ ] RSA: 4096/2DA8B985[] [ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#544740: [debian-keyring] Conflicts with itself
On Wed, Sep 02, 2009 at 07:50:23PM +0200, Resul Cetin wrote: > Package: debian-keyring > Version: 2009.05.28 > Severity: grave > > Debian keyring 2009.08.27 provides debian-maintainers and Conflicts with > debian maintainers. Please use more specific conflict with version number <= > 2009.08.24 That's not correct though; the point is that debian-keyring provides debian-maintainers.gpg which is contained in the debian-maintainers package. Policy 7.6.2 states that what's done is correct and I have no problems installing the package: | fragile:~# dpkg -i ~noodles/debs/debian-keyring_2009.08.27_all.deb | (Reading database ... 13814 files and directories currently installed.) | Preparing to replace debian-keyring 2009.05.28 (using .../debian-keyring_2009.08.27_all.deb) ... | Unpacking replacement debian-keyring ... | Setting up debian-keyring (2009.08.27) ... | fragile:~# Perhaps if you explain what error you're hitting that would help? J. -- ] http://www.earth.li/~noodles/ [] 101 things you can't have too much [ ] PGP/GPG Key @ the.earth.li []of : 27 - Ice cream. [ ] via keyserver, web or email. [] [ ] RSA: 4096/2DA8B985[] [ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
