Bug#982722: libatteanx-serializer-rdfa-perl: FTBFS: dh_auto_test: error: make -j1 test TEST_VERBOSE=1 returned exit code 2
Hi! Just to say as upstream that this patch seems appropriate. I'll have a conversation with the author of one of the modules that I depend on to confirm, and then I'll probably apply it upstream and roll a new release. Best, Kjetil
Bug#922878: Upstream fixes available
Hi all! So, I gotta admit as upstream dev of two of the modules that failed, that this is partly my fault. And I am happy to report that I have fixed it upstream for two packages. The root cause is that librdf-ns-perl is based on a crowd-sourced database, and sometimes crowd-sourced things change. The occasional breakage is usually a small price to pay for access to the large, crowdsourced database, but for a stable environment, like Debian, it can cause some headaches. Finding the right balance can sometimes be hard, and I therefore suggested one change to librdf-ns-perl that made it into this release, and that has now been reverted. I still think that the change is appropriate, and I think it should not be applied, as it merely fixes a symptom and not the root cause, and might lead to breakage for those who do not rely on RDF::NS for the entire lifetime of the distribution, but upgrades from upstream. Moreover, I suspect it doesn't fix the problem for librdf-aref-perl, that's still failing, right? The breakage seen there is directly due to that a prefix has changed in the crowdsourced database, and only upstream can really fix that. The actual root cause in libatteanx-serializer-rdfa-perl and librdf-trine- serializer-rdfa-perl was a particularly embarrassing and silly mistake on my part. It just failed very rarely, since testers would generally have both RDF::NS and RDF::Prefixes installed... I have now released a new upstream version of both, and I think that librdf-ns-perl should be unchanged from the upstream. Best, Kjetil
Bug#750946: Update on the upstream side
Hi all! Greg has made a patch and a pull request: https://github.com/tobyink/p5-html-html5-parser/pull/3 but so far, we haven't heard from the main developer. Also, as you can see, the patch is met with some resistance, so we're not really sure how to solve this now... Meanwhile, we should relax the relationships between this module and the RDF toolchain. The HTML parser really is somewhat on the outskirts and isn't a dependency to any of it, so it shouldn't have that far-reaching consequences. Cheers, Kjetil
Bug#750946: Tests created
Hi all! I ended up reformulating the code as a test script: https://github.com/kjetilk/p5-html-html5-parser/blob/master/t/rt-96399.t This is the way I thought it should be, but with Greg's patch, the test intended to check the UNICODE char still fails for me... It may well be that the test is wrong, please poke at it :-) Cheers, Kjetil
Bug#750946: Upstream dev of HTML::HTML5::Parser
On Sunday, 6 August 2017 21:55:55 CEST you wrote: > On 2017-08-05 23:09:11 +0200, Kjetil Kjernsmo wrote: > > I just noticed https://bugs.debian.org/750946 since my Test::RDF > > depends on HTML::HTML5::Parser (though, I don't quite understand how > > that dependency arises) and I would be affected by a removal. > > There doesn't seem to be a dependency. Right, I got an email from Debian testing autoremoval watch saying it was about to be removed, but nevermind. The code can be checked out from https://bitbucket.org/tobyink/p5-html-html5-parser or https://github.com/tobyink/p5-html-html5-parser AFAIK, Toby prefers Hg. May I suggest that the test cases in this bug are rewritten so that they can go in the test harness (i.e. as .t files), and a pull request is opened for that. Then, Greg's suggested patch seems to go at the core issue, so that seems like the thing to do. With this, Toby can hopefully make a new release soon. Best, Kjetil
Bug#750946: Upstream dev of HTML::HTML5::Parser
Hi all! I just noticed https://bugs.debian.org/750946 since my Test::RDF depends on HTML::HTML5::Parser (though, I don't quite understand how that dependency arises) and I would be affected by a removal. I haven't looked at the problem itself, but I would just like to report that the upstream dev, Toby Inkster has recently resumed development after a hiatus, so all hope isn't lost. Best, Kjetil
Bug#690648: Relevance to Ubuntu bug #1096113
Hi! I suspect this bug is pretty much the same bug as this Ubuntu issue: https://bugs.launchpad.net/ubuntu/+source/4store/+bug/1096113 Cheers, Kjetil -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#713235: librdf-linkeddata-perl bug fixed in 0.58?
Hi! This bug should be fixed by 0.58-1. Please verify can close if so. :-) Cheers, Kjetil -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#713235: Verbose output
Hi! Is it possible for you to run prove -lv t/10-basic.t and attach the output, or open an upstream bug report with the output? I'm somewhat baffled here, as I cannot reproduce, and there is not enough to go on. I would like to make a new release to fix this soon if I can just track it down. Cheers, Kjetil -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#713235: Verbose output
On Friday 5. July 2013 01.32.05 gregor herrmann wrote: ok 15 - /foo return RDF validates Expected number at 1:27# Looks like you planned 23 tests but ran 15. Hmmm, that's pretty strange. It has to be something around the new turtle parsing... I'll discuss with the author of librdf-trine-perl. Cheers, Kjetil -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#713235: Please try upstream RDF::LinkedData dev release 0.57_03
Hi! There's a version 0.57_03 on CPAN, which fixes some bugs I thought were trivial, but I suppose it could have something to do with the problems that caused the FTBFS, could you please try it and see if it does fix the problems? Best, Kjetil -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#713255: Processed: tagging 713255, bug 713255 is forwarded to https://github.com/kjetilk/Test-RDF/issues/2
Hi! Yeah, it is definitly my bug. I will hopefully find some time to fix it this week. Cheers, Kjetil -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684533: Fwd: RDF::TrineShortcuts - deprecation
Package: librdf-trineshortcuts-perl Version: 0.104-1 Severity: serious Please see the below email from the upstream developer. Given this, I suppose this package shouldn't make it to Wheezy when it is stable. If I'm wrong, please feel free to close. Cheers, Kjetil -- Forwarded Message -- Subject: RDF::TrineShortcuts - deprecation Date: Wednesday 30. May 2012, 09.11.32 From: Toby Inkster m...@tobyinkster.co.uk To: d...@lists.perlrdf.org RDF::TrineShortcuts is a pretty nasty hack, and many of the reasons for its existence are no longer valid. For example, at the time I wrote it, RDF::Trine didn't have support for auto-detecting the serialization of a URL or file and parsing it; now it does. Anyway, it should be considered strongly deprecated. It will be deleted from CPAN at some point later this year (though will still be available from BackPAN). I just need to rework a few modules that currently depend on it. -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk ___ Dev mailing list d...@lists.perlrdf.org http://lists.perlrdf.org/listinfo/dev - -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678779: RDFa parser problem
Hi! Just a quick comment. First of all, it seems like it is a problem with the RDFa parser, since this module is a relatively thin wrapper around librdf- rdfa-parser-perl. The test that fails is very terse though, so it is hard to tell. One thing that could be useful for upstream is to run the test suite with prove -lv Also, a core module, RDF::Trine has seen a 1.0 bugfix and stabilizing release. However, it doesn't seem to be to blame, as the previous version was used in the build, from the full log: - RDF::Trine ...loaded. (0.140 = 0.130) Not a whole lot to go on here, but it seems like an upstream problem. Cheers, Kjetil -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#421582: libimager-perl 0.57 in SVN
Hi! I just made an svn-upgrade of libimager-0.57 to the alioth repository, which would fix this for sid. Nice if it could be packaged and uploaded soon. Cheers, Kjetil -- Kjetil Kjernsmo Information Systems Developer Opera Software ASA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391404: upgrading severity
On Friday 29 December 2006 07:29, Michael Ablassmeier wrote: On Fri, Dec 29, 2006 at 07:27:36AM +0100, Michael Ablassmeier wrote: following the policy, this issue is severity serious, upgrading. Please be sure to either move the tools to modxslt-tools or add proper conflicts between those packages. Yeah, I think you're right, this is an RC-issue. I'm not a DD, but modxslt is important to us, so I'm trying to help out. All issues seems to have been with manpages, such as: `/usr/share/man/man1/modxslt-config.1.gz', which is also in package libapache2-modxslt Does this imply that what is missing is debian/*.manpages files? -- Kjetil Kjernsmo Information Systems Developer Opera Software ASA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391404: upgrading severity
On Friday 29 December 2006 11:46, Michael Ablassmeier wrote: i think shipping modxslt-perror.1.gz and modxslt-parse.1 within libapache2-modxslt doesnt make much sense as those tools are only in the modxslt-tools package. For modxslt-config.1.gz im not sure, it might make sense to have a diversion here (or only ship it once, in libapache2-modxslt). Something like that. Talking with a DD here, we found that in rules, there are dh_installman -pmodxslt-tools debian/modxslt-perror.1 debian/modxslt-parse.1 dh_installman -plibmodxslt0-dev debian/modxslt-config.1 which is indeed probably what we want. However, it doesn't work, because dh_installman then stuffs it in the first package also, which is libapache-modxslt. He suggested trying with .manpages, I'm preparing a patch. -- Kjetil Kjernsmo Information Systems Developer Opera Software ASA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391404: upgrading severity
On Friday 29 December 2006 15:14, Michael Ablassmeier wrote: and later dh_installman from debian/rules continues installing them in the packages, they end up twice there. Looking at the md5sums from debian/modxslt-parse.1 and the one shipped by upstream i get the impression they have the same content, Uh, right. I don't know what the debian policy says about this, but I have the impression that use debhelper is usually recommended. Perhaps those two lines needs to be removed, then? is there any reason for why you ship them twice? Just for the record, I'm not the maintainer, I'm not even a DD. However, I think this question needs to be posed to the maintainer, whom I hope will tune in soon. I'll defer the patch meanwhile. -- Kjetil Kjernsmo Information Systems Developer Opera Software ASA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404051: libapache2-mod-perl2: Typo in Apache2::SizeLimit causes crash under some conditions
Package: libapache2-mod-perl2
Version: 2.0.2-2.2
Severity: grave
Tags: patch, fixed-upstream
Justification: causes non-serious data loss
There is a typo on line 113 in /usr/lib/perl5/Apache2/SizeLimit.pm,
mod_perl 2.0.2, which under some conditions, i.e. Apache2::SizeLimit
is used and configured to use Linux::Smaps (not a very common
configuration, admittedly, since it also depends on a recent kernel),
causes server crash. If used, it will give the following error:
[Thu Dec 21 10:20:52 2006] [error] [client 10.20.21.93] Can't locate
object method shared_cleani via package Linux::Smaps::VMA at
/usr/lib/perl5/Apache2/SizeLimit.pm line 113.\n, referer:
http://my.virginia.oslo.opera.com/kjetilk/blog/
The fix is extremely trivial:
--- SizeLimit.pm~ 2005-10-21 02:04:43.0 +0200
+++ SizeLimit.pm2006-12-21 11:01:39.0 +0100
@@ -110,7 +110,7 @@
sub linux_smaps_size_check {
my $s = Linux::Smaps-new($$)-all;
-return ($s-size, $s-shared_cleani + $s-shared_dirty);
+return ($s-size, $s-shared_clean + $s-shared_dirty);
}
# return process size (in KB)
It is just a single character, it was just a simple typo.
This should have been fixed in upstream 2.0.3 allthough it was not
mentioned in the changelog. The changelog of 2.0.3 indicates it is
pretty much a pure bugfix release, so I think Debian should seriously
consider including it.
But I realise that's a long shot now that etch is frozen, so
alternatively, I ask that this bug is corrected, it is the most
trivial bug possible, and even though it affects relatively few users,
it is extremely annoying and renders the package unusable for those
who wants to optimize the server's memory use.
-- System Information:
Debian Release: 4.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-1-686
Locale: LANG=no_NO, LC_CTYPE=no_NO (charmap=ISO-8859-1)
Versions of packages libapache2-mod-perl2 depends on:
ii apache2. 2.2.3-3.1 Next generation, scalable,
extenda
ii libapr1 1.2.7-8 The Apache Portable Runtime
Librar
ii libaprut 1.2.7+dfsg-2The Apache Portable Runtime
Utilit
ii libc62.3.6.ds1-9 GNU C Library: Shared
libraries
ii libdevel 2.03-3 Perl module for inspecting
perl's
ii libperl5 5.8.8-7 Shared Perl library
ii liburi-p 1.35-2 Manipulates and accesses
URI strin
ii libuuid1 1.39+1.40-WIP-2006.11.14+dfsg-1 universally unique id
library
ii libwww-p 5.805-1 WWW client/server library
for Perl
ii netbase 4.27Basic TCP/IP networking
system
ii perl [li 5.8.8-7 Larry Wall's Practical
Extraction
ii perl-bas 5.8.8-7 The Pathologically Eclectic
Rubbis
libapache2-mod-perl2 recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402241: spamassassin needs more than 512MB to process innocent 2.5MB email
On Fri, 8 Dec 2006, Duncan Findlay wrote: It's generally a bad idea (i.e. not supported) to stick messages larger than 250k through spamassassin. The spamc client refuses to check messages larger than this size, and the example procmailrc in /usr/share/doc/spamassassin/examples/procmailrc.example mentions this. The only reason I haven't closed this bug is because I can't figure out where this is documented. :-) IMHO, if it's not supported, then spamassassin should do nothing on those messages (unless, maybe, some additional flag is used), instead of processing them, I might agree that spamassassin should do nothing on a message that it isn't intended to, and we should not need the procmail recipe to checks for the mail size. ...but I can't agree with this. It is very clearly documented in the quoted procmail example, and people should read and understand that example before using a nuclear device like spamassassin. spam scanning in this day is a non-trivial exercise (you might do OCR on attachments for example), and administrators need to understand that. I think this bug should be downgraded, it is surely not an RC bug. Cheers, Kjetil -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391634: A patch that makes modxslt compile
Hi!
A colleague took upon himself to make it compile from upstream source,
and the following patches is what he needed to make it compile.
There seems to be a simple patch needed for the upstream code itself.
Also, he hacked the configure script itself, not the autoconfigure.
However, this may indicate that some of the things in there are
redundant. Also, he did not find a solution to the
ac_cv_lib_apr_0_apr_send thing, as you can see.
So, it is not sufficient to fix the bug, but it is a step forward.
--- configure 2005-05-26 16:26:42.0 +0200
+++ ../../configure 2006-11-15 14:46:21.0 +0100
@@ -22664,7 +22664,7 @@
echo $ECHO_N (cached) $ECHO_C 6
else
ac_check_lib_save_LIBS=$LIBS
-LIBS=-lapr-0 `$APRC --link-ld` `$APRC --libs` $LIBS
+LIBS=`$APRC --link-ld` `$APRC --libs` $LIBS
cat conftest.$ac_ext _ACEOF
/* confdefs.h. */
_ACEOF
@@ -22719,6 +22719,9 @@
conftest$ac_exeext conftest.$ac_ext
LIBS=$ac_check_lib_save_LIBS
fi
+
+ac_cv_lib_apr_0_apr_send=yes
+
echo $as_me:$LINENO: result: $ac_cv_lib_apr_0_apr_send 5
echo ${ECHO_T}$ac_cv_lib_apr_0_apr_send 6
if test $ac_cv_lib_apr_0_apr_send = yes; then
@@ -22911,7 +22914,7 @@
echo $ECHO_N (cached) $ECHO_C 6
else
ac_check_lib_save_LIBS=$LIBS
-LIBS=-laprutil-0 `$APUC --link-ld` `$APUC --libs` `$APRC --link-ld`
$LIBS
+LIBS=`$APUC --link-ld` `$APUC --libs` `$APRC --link-ld` $LIBS
cat conftest.$ac_ext _ACEOF
/* confdefs.h. */
_ACEOF
--- sapi/apache2/modxslt.c 2005-07-27 12:27:57.0 +0200
+++ ../../modxslt-2005072700/sapi/apache2/modxslt.c 2006-11-15
15:36:16.0 +0100
@@ -84,7 +84,7 @@
void mxslt_ap2_brigade_dump(apr_bucket_brigade * brigade) {
apr_bucket * bucket;
- APR_BRIGADE_FOREACH(bucket, brigade) {
+ for (bucket = APR_BRIGADE_FIRST(brigade); bucket !=
APR_BRIGADE_SENTINEL(brigade); bucket = APR_BUCKET_NEXT(bucket)) {
printf(bucket: %08x, type: %08x, length: %d, start: %d, data:
%08x\n, (int)bucket,
(int)bucket-type, (int)bucket-length, (int)bucket-start,
(int)bucket-data);
}
--
Kjetil Kjernsmo
Information Systems Developer
Opera Software ASA
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391634: Trying to work on modxslt bug #391634
Hi there!
I've been trying to work on this bug, as I just realised that it'll be
10 times as painful to fix it after etch is released than before...
Problem is that my bash skills isn't very good. This is what I've tried,
starting from around line 22660 in the configure script:
echo $as_me: checking which libapr...;
which_libapr=`$APRC --link-ld --libs | cut -b 15-19`;
echo $which_libapr;
# Check if we can link with libapr
echo $as_me:$LINENO: checking for apr_send in $which_libapr 5
echo $ECHO_N checking for apr_send in $which_libapr... $ECHO_C 6
if test ${ac_cv_lib_apr_0_apr_send+set} = set; then
echo $ECHO_N (cached) $ECHO_C 6
else
ac_check_lib_save_LIBS=$LIBS
LIBS=-l$which_libapr `$APRC --link-ld` `$APRC --libs` $LIBS
The idea was to replace the significant hardcoded apr-0 with a variable.
The variable is populated OK, but it doesn't have the desired effect.
However, is this all really needed? In the final LIBS line, it
apr-config, which returns everything that is needed, I would think...?
I'm confused here, but I'd like to fix this bug, in spite of the few
skills I have in this arena.
--
Kjetil Kjernsmo
Information Systems Developer
Opera Software ASA
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382134: postgresql-common: Problems in unpacking; possible bumpy upgrade path
On Friday 11 August 2006 00:05, you wrote: Ah, it might explain a bit more now. Did you actually see the 'Unclean transition' debconf note? Judging from the output you shouldn't have at that attempt, but at some point in the past. Errr, yeah, I might have. The actual upgrade I did a few months back... I was getting deluged by spam, and needed desperately a Spamassassin upgrade, which depended on Pg 8.x, and at the same time, I had just gotten a new dual-CPU box. So I just grabbed the HD from my older server, that were running sarge, put a few new ones in the new box, stuffed this into an older box that I was given that I wanted to make a pure spamd server, and massaged Pg 8.1 in as fast as I could... Can you please give me the output of dpkg -s postgresql ? [EMAIL PROTECTED]:~ dpkg -s postgresql Package: postgresql Status: deinstall ok config-files Priority: optional Section: misc Installed-Size: 9580 Maintainer: Martin Pitt [EMAIL PROTECTED] Architecture: i386 Version: 7.4.7-6sarge1 Config-Version: 7.4.7-6sarge1 Replaces: postgresql-pl, libpgtcl ( 7.3rel-5), libpgperl ( 1:2.0.1-1) Depends: libc6 (= 2.3.2.ds1-21), libcomerr2 (= 1.33-3), libkrb53 (= 1.3.2), libpam0g (= 0.76), libperl5.8 (= 5.8.4), libreadline4 (= 4.3-1), libssl0.9.7, python2.3 (= 2.3), zlib1g (= 1:1.2.1), debconf (= 0.5) | debconf-2.0, dpkg (= 1.10.3), procps, debianutils (= 1.13.1), postgresql-client (= 7.4), libpq3 (= 7.4), mailx, ucf (= 0.28) Pre-Depends: adduser (= 3.34) Suggests: libpg-perl, libpgjava, libpgtcl, postgresql-doc, postgresql-dev, postgresql-contrib, pidentd | ident-server, pgdocs, pgaccess Conflicts: postgres95, libpq1, postgresql-pl, postgresql-test, postgresql-contrib ( 7.2), ecpg ( 7.2), libpgtcl ( 7.3rel-5), libpgperl ( 1:2.0.1-1), postgresql-client ( 7.4.6-5) Conffiles: /etc/cron.d/postgresql 361b4b47a5ec640fd90e5f32b2b9e7d8 /etc/init.d/postgresql 2b4cca6a806c550a2c0e4faa342d3a6f /etc/logrotate.d/postgresql 8822ce30bcea0aad31febb60793fe7bc /etc/logcheck/ignore.d.server/postgresql 3baad38bef168f2e265fdbb10ef96039 /etc/logcheck/violations.ignore.d/logcheck-postgresql 56140ea2fefe72cc34b461267f8dc975 /etc/logcheck/ignore.d.paranoid/postgresql 3baad38bef168f2e265fdbb10ef96039 /etc/logcheck/ignore.d.workstation/postgresql 3baad38bef168f2e265fdbb10ef96039 /etc/postgresql/pg_ident.conf 13315f01db0ad8a8638326b9f035c896 /etc/postgresql/pg_hba.conf 2ec14365922bdbe4add9b83e342bd402 Description: object-relational SQL database management system [...] If it still has config files installed, then this installation breakage is supposed to stop you from uninstalling (but not purging) the Sarge postgresql packages and then installing postgresql-8.1, instead of doing a proper dist-upgrade (which will pull in the transitional postgresql 7.5.21 package, which will move things around and clean up). Aha, I don't quite remember what I did, but since the only db I needed to preserve was the SA db, and sa-learn has a clean upgrade path for that, I might have deleted stuff by hand too... But you can probably draw your conclusions from what you see here :-) It seems I should always display the debconf note instead of just once, to reduce this kind of confusion. Yeah, perhaps... :-) Cheers, Kjetil -- Kjetil Kjernsmo Programmer / Astrophysicist / Ski-orienteer / Orienteer / Mountaineer [EMAIL PROTECTED] Homepage: http://www.kjetil.kjernsmo.net/ OpenPGP KeyID: 6A6A0BBC
Bug#382134: postgresql-common: Problems in unpacking; possible bumpy upgrade path
On Friday 11 August 2006 10:37, you wrote: Hi, Kjetil Kjernsmo [2006-08-11 8:06 +0200]: dpkg -s postgresql Status: deinstall ok config-files Config-Version: 7.4.7-6sarge1 Hah, exactly what I wanted to see. :) Good! :-) Aha, I don't quite remember what I did, but since the only db I needed to preserve was the SA db, and sa-learn has a clean upgrade path for that, I might have deleted stuff by hand too... But you can probably draw your conclusions from what you see here :-) Yep, actually it behaves exactly as intended. ;) So, I recommend to just do dpkg -P postgresql postgresql-client Ah, this could be the reason why this didn't go cleanly: I have a partition for pg, so it goes: [EMAIL PROTECTED]:~ dpkg -P postgresql postgresql-client (Reading database ... 81794 files and directories currently installed.) Removing postgresql ... Purging configuration files for postgresql ... rmdir: /var/lib/postgres: Device or resource busy /var/lib/postgres not empty so not removed. rmdir: /etc/postgresql: Directory not empty /etc/postgresql not empty so not removed. dpkg - warning: while removing postgresql, directory `/etc/logcheck/ignore.d.workstation' not empty so not removed. dpkg - warning: ignoring request to remove postgresql-client which isn't installed. I can of course remove these dirs manually, is that a good idea to do? to get rid of the ancient stuff and then do a clean install of postgresql-8.1 *nods* Thank you for your report! You're welcome, and thanks for all the help! Kjetil
Bug#382134: postgresql-common: Problems in unpacking; possible bumpy upgrade path
On Thursday 10 August 2006 21:44, you wrote:
Ok, let's try something else. Can you please dpkg -i the attached
packages and send me the output? They have debugging (sh -ex) enabled
in the preinst/config scripts.
Sure!
[EMAIL PROTECTED]:~ dpkg -i postgresql-c*
(Reading database ... 81797 files and directories currently installed.)
Preparing to replace postgresql-client-common 58 (using
postgresql-client-common_59_all.deb) ...
Unpacking replacement postgresql-client-common ...
Unpacking postgresql-common (from postgresql-common_59_all.deb) ...
+ . /usr/share/debconf/confmodule
++ '[' '!' '' ']'
++ PERL_DL_NONLAZY=1
++ export PERL_DL_NONLAZY
++ '[' '' ']'
++ exec /usr/share/debconf/frontend /var/lib/dpkg/tmp.ci/preinst install
55
+ . /usr/share/debconf/confmodule
++ '[' '!' 1 ']'
++ '[' -z '' ']'
++ exec
++ '[' '' ']'
++ exec
++ DEBCONF_REDIR=1
++ export DEBCONF_REDIR
++ dpkg -s postgresql
++ grep '^Version:'
++ cut -f 2- '-d '
+ dpkg --compare-versions 7.4.7-6sarge1 lt-nl 7.5
+ dpkg -s postgresql
+ grep -q '^Status:.*config-files'
+ db_input critical postgresql-common/untransitioned
+ _db_cmd 'INPUT critical' postgresql-common/untransitioned
+ echo 'INPUT critical' postgresql-common/untransitioned
+ IFS='
'
+ read -r _db_internal_line
+ RET='30 question skipped'
+ case ${_db_internal_line%%[ ]*} in
+ return 30
+ true
+ db_go
+ _db_cmd 'GO '
+ echo 'GO '
+ IFS='
'
+ read -r _db_internal_line
+ RET=ok
+ case ${_db_internal_line%%[ ]*} in
+ return 0
+ db_stop
+ echo STOP
+ exit 1
dpkg: error processing postgresql-common_59_all.deb (--install):
subprocess pre-installation script returned error exit status 1
Setting up postgresql-client-common (59) ...
Errors were encountered while processing:
postgresql-common_59_all.deb
Cheers,
Kjetil
--
Kjetil Kjernsmo
Programmer / Astrophysicist / Ski-orienteer / Orienteer / Mountaineer
[EMAIL PROTECTED]
Homepage: http://www.kjetil.kjernsmo.net/ OpenPGP KeyID: 6A6A0BBC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#356810: Serious bug in security update for Crypt::CBC
Hi all! Sorry to be jumping in without preserving the In-Reply-To. Allard Hoeve wrote: I'm afraid this new package introduces some serious errors in software that depends on this package. I have tested the new package on three different Sarge machines with the following results. Please reproduce using attached perl script. This bug jumped up and bit us too during testing, and it has been reported as bug #356810: http://bugs.debian.org/356810 so, it is now clear that it poses a serious problem for users, as it breaks the default behaviour. However, Please remove the update from the security archive. ...it is not that simple. If you read the original advisory: http://www.securityfocus.com/archive/1/archive/1/425966/100/0/threaded you'll see that we have (indirectly) been relying on weak and deprecated behaviour. While this is not the sort of breakage you expect from stable, it underlines that security is not just about blindly upgrading packages. So, it is probably better to get a heads-up from something that breaks down than getting the heads up from someone who breaks in... :-) The problem in this case is that we don't know if it is serious: The difficulty of breaking data encrypted using this flawed algorithm is unknown, but it should be assumed that all information encrypted in this way has been, or could someday be, compromised. Given that the upgrade certainly breaks stable, a DSA could have suggested the workaround as the correct path for sysadmins: If using Crypt::CBC versions 2.16 and lower, pass the -salt=1 option to Crypt::CBC-new(). I.e., say you should do this now to upgrade your systems. Many users are likely to be bit by this upgrade, so, indeed, it may be a reasonable path to remove the security upgrade and instead suggest the workaround. Best, Kjetil -- Kjetil Kjernsmo Information Systems Developer Opera Software ASA pgpPZHqLRbFvv.pgp Description: PGP signature
Bug#337206: Subject: libdbd-mysql-perl: Machine with latest mysql security update segfaults, rebuild needed?
Package: libdbd-mysql-perl Version: 2.9006-1 Severity: grave Justification: causes non-serious data loss *** Please type your report below this line *** I have a relatively simple script that segfaults on a machine that has the latest security updates for sarge, but runs fine on a machine that has not yet applied them. There is an strace at http://rafb.net/paste/results/68YHWC13.html I took it to #debian-devel, and...: ruoso If one security update touched a library which is used by the Perl XS module... then this can be the cause of the problem KjetilK hmmm ruoso aparently, this is what's happening... ruoso libdbd-mysql-perl should be rebuilt KjetilK guess so... ruoso KjetilK, can you send a bug report on it? KjetilK Sure So, here we go! I used reportbug to submit it, and it looked like it was sent, but apparently not... -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages libdbd-mysql-perl depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared ii libdbi-perl1.46-6Perl5 database interface by ii libmysqlclient12 4.0.24-10sarge1 mysql database client ii perl 5.8.4-8 Larry Wall's Practical ii perl-base [perlapi-5.8 5.8.4-8 The Pathologically Eclectic ii zlib1g 1:1.2.2-4.sarge.2 compression library -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300614: Same as #281628?
Tags: sarge sid upstream H, I think this is the same as http://bugs.debian.org/281628 Though I'm kinda surprised to see it, I thought it had been fixed in 3.3.2... Actually, I haven't seen it lately, even though I haven't upgraded yet. Also, it never caused any data loss for me. Cheers, Kjetil -- Kjetil Kjernsmo Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Homepage: http://www.kjetil.kjernsmo.net/OpenPGP KeyID: 6A6A0BBC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
