Bug#1054698: pixmap: FTBFS: ././Pixmap.c:1145:(.text+0xe631): undefined reference to `xpmReadRgbNames'
On Fri 27 Oct 2023, Lucas Nussbaum wrote: > Source: pixmap > Version: 2.6.6-1 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20231027 ftbfs-trixie > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > /usr/bin/ld: Pixmap.o: in function `Initialize': > > ././Pixmap.c:1145:(.text+0xe631): undefined reference to `xpmReadRgbNames' > > collect2: error: ld returned 1 exit status I've traced this to commit 7f60f3428aa21d5d643eb75bfd9417cfabf48970 on libxpm: Explicitly mark non-static symbols as export or hidden Hides private API from external linkage Signed-off-by: Alan Coopersmith That commit marks those functions as hidden for some reason. I'm contacting the libxpm maintainers. Paul
Bug#997627: pixmap: FTBFS: ar: libdeps specified more than once
On Sat 23 Oct 2021, Lucas Nussbaum wrote: > Source: pixmap > Version: 2.6pl4-20 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20211023 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > rm -f libXgnu.a > > ar clq libXgnu.a SelFile.o Path.o Dir.o Draw.o > > ar: libdeps specified more than once > > make[2]: *** [Makefile:1062: libXgnu.a] Error 1 This seems related to #981072 binutils: 'ar clq' does not longer work in latest binutils. With binutils 2.35.2 it works. I suspect that this will affect all packages that use Imake, see also #997628 and #994276. Not that much that I can do about it until xutils-dev gets patched. (Besides patching the output of Imake which is just papering over the binutils screwup.) Paul
Bug#931781: rsync: Buster hangs when rsyncing large (400M) files over ssh. Same hardware works OK with Stretch
Seeing the error messages you are getting, it sounds like there is a memory shortage, possibly the vmware ballooning driver is failing to provide sufficient memory in time. It does not look like rsync is to blame for your problems. Paul
Bug#862899: rsync: insufficient escaping/quoting of arguments
On Thu 18 May 2017, Thorsten Glaser wrote: > Now run this: > > remote$ touch ./-zT.mp4 > local$ mkdir test > local$ cd test > local$ rsync -zavPH --numeric-ids -S --stats '--rsh=ssh -T' $remote:\*4 . > > Expected: the “-zT.mp4” file is transferred. > > Actual: the whole home directory of $remote, including subdirectories > and everything, is transferred. Please try again with the --protect-args option, which is meant for such situations. BTW, why specify '--rsh=ssh -T', what's wrong with the default? Paul
Bug#699165: rsync: debian/rules using ` instead of $(shell
On Mon 28 Jan 2013, StalkR wrote: > > On squeeze, I failed to compile rsync/unstable from source: > dpkg-source -x rsync_3.0.9-4.dsc > cd rsync-3.0.9 > dpkg-buildpackage -rfakeroot -b > [...] errors related to compiler not found.. but after a look at > config.log it was because not expanding `dpkg-buildflags --get CFLAGS`. > I traced that back to debian/rules, where for CFLAGS/LDFLAGS: > CFLAGS += `dpkg-buildflags --get CFLAGS` > LDFLAGS = `dpkg-buildflags --get LDFLAGS` > while for CPPFLAGS: > CPPFLAGS:=$(shell dpkg-buildflags --get CPPFLAGS) Can you send the complete buildlog? I have no problem whatsoever with building on squeeze. What is your default /bin/sh ? Paul -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#638595: WWWOFFLE HTTPS now unusable
severity 638595 normal tag 638595 unreproducible thanks On Sat 20 Aug 2011, jida...@jidanni.org wrote: > > This can't just be a coincidental bug in libgcrypt11, libgnutls26, lyxn, > w3m all at the same time. It obviously is a WWWOFFLE bug. Or your system's memory has a glitch, or whatever. If it obviously a Wwwoffle bug, why have you only now discovered it? And only you? > In syslog I see > kernel: [23845.729604] wwwoffled[15387]: segfault at 1ee45974 ip b7589e6c sp > bf8f4654 error 4 in libgcrypt.so.11.6.0[b7539000+7d000] > > It happens when I do > $ wwwoffle https://bugzilla.mozilla.org/ > $ wwwoffle -offline > $ poff > $ wwwoffle-ls https://bugzilla.mozilla.org/ > DM1DXC+wwzmqA9IEIhJkqQA 16367 Aug 20 11:26 https://bugzilla.mozilla.org/ > $ https_proxy=http://localhost:8080/ lynx -dump https://bugzilla.mozilla.org > | wc > 0 0 0 Not reproducible by me. $ wwwoffle https://bugzilla.mozilla.org/ Requesting: https://bugzilla.mozilla.org/ $ wwwoffle -offline WWWOFFLE Incorrect Password $ sudo wwwoffle -offline WWWOFFLE Now Offline (I don't do poff as I don't have dialup, shouldn't matter anyway after putting wwwoffle offline) $ wwwoffle-ls https://bugzilla.mozilla.org/ DM1DXC+wwzmqA9IEIhJkqQA3832 Aug 20 12:49 https://bugzilla.mozilla.org/ $ https_proxy=http://localhost:8080/ lynx -dump https://bugzilla.mozilla.org | wc 25 102 943 I.e. it works just fine for me. Hence downgrading the severity, as I doubt there is a real bug and not just a problem with your setup, as usually is the case with your noisy bugs. And what's the point of adding a link to the online bug report to the bug report itself?! Get a grip... Paul -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#605731: rsync client can no longer handle rsync:// targets
On Thu 02 Dec 2010, Zed Pobre wrote: > > The problem resolved down to rsync 3.0.3-2 accepting the following: > > rsync rsync://:: > > and 3.0.7-2 does not. That 3.0.3-2 accepted that syntax was an "undocumented feature". Nowhere in the documentation does it say that it is OK to mix rsync:// and :: notation. In fact, it explicitly states: Contacting an rsync daemon directly happens when the source or destination path contains a double colon (::) separator after a host specification, OR when an rsync:// URL is specified Note the "OR" in capital letters. That said, I agree that it's not nice that rsync has changed what it accepts as an argument. On the other hand I don't think that a change that enforces the documented syntax more strongly, such that unrelated software that used that undocumented syntax is now broken, constitutes a critical bug in rsync. Perhaps a wishlist bug. The real bug is in the software that was written without reading the rsync manual carefully. Paul -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#545751: Still doesn't work for me
On Fri 12 Feb 2010, Marcin Trybus wrote:
> Feb 12 18:02:00 localhost mysqld_safe[6407]: ERROR: 1064 You have an error
> in your SQL syntax; check the manual that corresponds to your MySQL server
> version for the right syntax to use near 'ALTER TABLE user ADD column
> Show_view_priv enum('N','Y') CHARACTER SET utf8 NOT ' at line 1
Note also the above line.
I got this when upgrading mysql-server-5.1 5.1.41-3 -> 5.1.44-3.
5.1.41-3 was installed cleanly on a new system.
The column it's trying to add (Show_view_priv) is actually already
there.
Paul
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#560181: can't purge wwwoffle (action "stop" failed)
On Wed 09 Dec 2009, Vincent Lefevre wrote: > After fixing the prerm script, I've found that the postrm script is > also buggy: > > Removing wwwoffle ... > Purging configuration files for wwwoffle ... > find: `/etc/wwwoffle': No such file or directory > find: `/etc/wwwoffle': No such file or directory > /etc/wwwoffle directory removed, including contents > find: `/etc/wwwoffle': No such file or directory > find: `/etc/wwwoffle': No such file or directory > dpkg: error processing wwwoffle (--purge): > subprocess installed post-removal script returned error exit status 128 > Errors were encountered while processing: > wwwoffle > > Again, there's the "|| exit $?" that can make it fail: > > update-rc.d wwwoffle remove >/dev/null || exit $? It shouldn't, the only mention in the update-rc.d manpage of aborting is if the init.d script still exists at that point. > But even though the "exit 0" is reached (I've added an "echo ..." > just before), I still get the error. That's just weird... Paul -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#560181: can't purge wwwoffle (action "stop" failed)
On Wed 09 Dec 2009, Vincent Lefevre wrote: > > The /var/lib/dpkg/info/wwwoffle.prerm script contains: > > set +e # ignore errors while stopping > # Automatically added by dh_installinit > if [ -x "/etc/init.d/wwwoffle" ]; then > if [ -x "`which invoke-rc.d 2>/dev/null`" ]; then > invoke-rc.d wwwoffle stop || exit $? > else > /etc/init.d/wwwoffle stop || exit $? > fi > fi > # End automatically added section > > If "|| exit $?" is added, the "set +e" won't prevent the script > from exiting with a non-zero status. The problem here is that this part is "Automatically added by dh_installinit", as stated by the comment. I guess I have to fix it so that the init.d script doesn't exit with non-zero if "stop" is requested. Paul -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#516182: linpopup: Gtk1.2 about to be removed from Debian
On Sun 06 Dec 2009, Moritz Muehlenhoff wrote: > > What's the status? Do you intend to update to linpopup2 for Squeeze > or shall we remove linpopup from the archive? Given that it's > obsolete on Windows for a long time (according to Wikipedia it was > dropped with Windows NT), this seems sensible. I agree that it's most probably obsolete, and time to remove it. Paul -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#516182: linpopup: Gtk1.2 about to be removed from Debian
On Wed 25 Feb 2009, Moritz Muehlenhoff wrote: > > > > Gtk1.2 will not be shipping with Squeeze so linpopup will either > > need to be ported to Gtk2 or removed from the archive. > > A GTK2 port is available at http://linpopup2.sourceforge.net/ Thanks for that! I contacted the author (at littleigloo.org), but have not had any response. I'll look into the sourceforge version. Paul -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#484044: pixmap_2.6pl4-15(ia64/unstable): FTBFS: debian/rules clean fails
On Sun 01 Jun 2008, [EMAIL PROTECTED] wrote: > > /usr/bin/fakeroot debian/rules clean > > [ ! -f Makefile ] || /usr/bin/make distclean > > make[1]: Entering directory `/build/buildd/pixmap-2.6pl4' > > make[1]: *** No rule to make target `distclean'. Stop. Hi, could you send me the generated Makefile? Thanks. Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#419018: Intending to orphan this package with an upload
On Sat 31 May 2008, Raphael Geissert wrote: > > As this bug, and all the other ones, have had no reply from the maintainer > ever, I plan to address this bug, together with some others in an upload. > > The upload would also change the maintainer to the QA group, thus orphaning > the package. > > If you still intend to maintain the package please reply as soon as possible, > because by the next weekend I'll ask a sponsor to upload the package. I've prepared a fixed version, but haven't yet been home to test it. That should happen today. Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477931: rsync: Segfaults syncing the linux kernel archive.
severity 477931 important thanks serious is for debian policy violations; important is more suitable in this case. On Fri 25 Apr 2008, Kurt Roeckx wrote: > I can consitently make rsync segfault when trying to sync the linux > kernel archive using version 3.0.2. It doesn't segfault using > 2.6.9-2etch2. This has worked for weeks but started happening yesterday. > > This is what I got from gdb: Thanks for the backtrace, very helpful. > prior_hlinks only seems to be used in case of !inc_recurse, so I > have the feeling that I shouldn't be comming there in the first place. > I'm guessing that the hashtable_find() should be inside an if (inc_recurse) > as all other hashtable_find()'s are also doing that. > > I've attached a patch that does that. It seems to be working. I'll forward it upstream so Wayne can take a look, he is very intimate with the innards of rsync :) > PS: It's annoying that when a core file gets created that it's written > in destination path instead of the directory where I started rsync. Blame Linus :-) It's what the kernel does, rsync has 0.0 influence on this besides not changing its current dir, but that would be quite suboptimal. Paul Slootman PS: sorry I haven't yet responded about your other report :-( Hope to do so soon. Real Life gets in the way sometimes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#476786: rsync fails to transfer /var/log/ntpstats/*
severity 476786 important
thanks
On Sat 19 Apr 2008, Laurent Caron wrote:
> I did notice that rsync fails to transfer some files (eg:
> /var/log/ntpstats/*) and dies on files in that directory on any
> non-initial run.
>
> On the first run, it all goes well.
>
> On the subsequent runs:
>
> donald:~# rsync -aAzHRxby -vP --exclude='var/log/ntpstats' --numeric-ids
> --suffix='' --backup-dir=/backup/local/gloups.lncsa.com/2008-04-YY
> 'gloups.lncsa.com:/{etc,var/log}'
> /backup/local/gloups.lncsa.com/current
>
> receiving file list ...
> 14452 files to consider
> ...
> ...
> var/log/ntpstats/
> var/log/ntpstats/loopstats
> 884 100%1.59kB/s0:00:00 (xfer#11, to-check=182/14473)
> var/log/ntpstats/peerstats
> 8306 100% 14.97kB/s0:00:00 (xfer#12, to-check=172/14473)
> zsh: segmentation fault rsync -aAzHRxby -vP --numeric-ids --suffix=''
> rsync: connection unexpectedly closed (120216 bytes received so far) [sender]
> rsync error: error in rsync protocol data stream (code 12) at io.c(453)
> [sender=2.6.9]
> rsync: connection unexpectedly closed (447235 bytes received so far)
> [receiver]
> rsync error: error in rsync protocol data stream (code 12) at io.c(453)
> [receiver=2.6.9]
>
> If i now use an exclude (--exclude='var/log/ntpstats'), it finishes
> without any problem.
You already used that exclude. At least you show you did, although the
output is not consistent with that.
> I did use critical severity because, if you use rsync to make backups...
> it can be messy to realize your backups are just useless.
It is always the administrator's responsibility to check that backups
are made successfully, hence I'm downgrading to "important".
If rsync failed silently, that might be cause for "critical".
Note that I used this version of rsync to backup 150 systems, and I
didn't came across this error. (Those systems have since been upgraded
to rsync 3.0.2.)
I did find something similar when testing the prerelease version of
3.0.0. Strange that you now came across it in 2.6.9...
As it's almost impossible to get a fix for bugs in the stable
distribution, I would like to ask you to try the backport version of
3.0.2, available via http://packages.debian.org/etch-backports/rsync .
Alternatively, if you want to help fix this bug in 2.6.9, you could
download http://debian.wurtel.net/i386/rsync and use that (it's
basically a 2.6.9_2etch2 built without optimization and not stripped).
First do "ulimit -c unlimited", and trigger the bug. You should then
have a core dump. Then do "gdb /path/to/rsync core" and "bt" to get the
stack backtrace. Alternatively make the core dump available to me.
Hopefully that would help pin down the cause of the error.
Thanks,
Paul Slootman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#469979: amd64 build of flex 2.5.34-3 defective
On Sun 09 Mar 2008, Manoj Srivastava wrote:
> > $ flex -i -p -B -F -8 -s -Phtml_yy html.l flex: fatal internal error,
> > bad transition character detected in sympartition()
>
> Could you upload this file to the bug, or, better, a minimal
> version that displays this problem? That would help create a test
> suite entry that will detect this problem at build time.
I've attached the file.
Paul Slootman
W [ \t\r\n\f]
nonascii[\200-\377]
ascii [ -~]
alphanum[a-z0-9]
punct [][!\"#$%&\'()*+,-./:;<=>[EMAIL PROTECTED]|}~]
safepunct [][!\#$%&\*+,-./:;[EMAIL PROTECTED]|}~]
tag {alphanum}+
key ({alphanum}|-)+
val ({alphanum}|{nonascii}|{safepunct})+
ident ({nonascii}|{alphanum}|-)+
url ({alphanum}|{nonascii}|{safepunct})+
%x DOCTYPE
%x COMMENT COMMENT_BAD
%x TAG_START TAG TAG_ATTR_KEY TAG_ATTR_VAL
%x DQUOTED SQUOTED
%x SCRIPT_START SCRIPT
%x STYLE_START
%x CSS
%x CSS_COMMENT
%x CSS_IMPORT CSS_IMPORT_URL
%x CSS_MEDIA
%x CSS_DECL_LIST CSS_DECL_PROP CSS_DECL_VALUE CSS_DECL_VALUE_URL
%{
/***
$Header: /home/amb/wwwoffle/src/RCS/html.l 2.94 2007/12/05 19:29:59 amb Exp $
WWWOFFLE - World Wide Web Offline Explorer - Version 2.9d.
Parse the HTML and look for the images, links and other things.
**/ /**
Written by Andrew M. Bishop
Object and Parameter handling by Walter Pfannenmller
This file Copyright 1997-2007 Andrew M. Bishop
It may be distributed under the GNU Public License, version 2, or
any higher version. See section COPYING of the GNU Public license
for conditions under which this file may be redistributed.
***/
#include "autoconfig.h"
#include
#include
#include
#include
#include
#include
#include "wwwoffle.h"
#include "io.h"
#include "misc.h"
#include "errors.h"
#include "config.h"
#include "document.h"
/* Parser outputs */
#define LEX_PLAINTEXT 1
#define LEX_COMMENT2
#define LEX_DOCTYPE3
#define LEX_TAG_BEGIN 11
#define LEX_TAG_END 12
#define LEX_TAG_END_XHTML 13
#define LEX_ATTR_KEY 21
#define LEX_ATTR_VAL 22
#define LEX_ATTR_VAL_SQ 23
#define LEX_ATTR_VAL_DQ 24
#define LEX_CSS_STYLESHEET 101
#define LEX_CSS_PROPERTY102
#define LEX_CSS_VALUE 103
/*+ Tag types +*/
typedef enum _HTMLTags
{
tag_a = 0 /* "a" */ ,
tag_area = 1 /* "area" */ ,
tag_base = 2 /* "base" */ ,
tag_blockquote= 3 /* "blockquote" */ ,
tag_body = 4 /* "body" */ ,
tag_del = 5 /* "del"*/ ,
tag_frame = 6 /* "frame" */ ,
tag_head = 7 /* "head" */ ,
tag_iframe= 8 /* "iframe" */ ,
tag_input = 9 /* "input" */ ,
tag_ins =10 /* "ins"*/ ,
tag_q =11 /* "q" */ ,
tag_script=12 /* "script" */ ,
tag_td=13 /* "td" */ ,
tag_complex =14 /* Complex tags, stored and processed as a whole. */,
tag_applet=15 /* "applet" */ ,
tag_embed =16 /* "embed" */ ,
tag_img =17 /* "img"*/ ,
tag_link =18 /* "link" */ ,
tag_meta =19 /* "meta" */ ,
tag_object=20 /* "object" */ ,
tag_param =21 /* "param" */ ,
tag_xml =22 /* "xml"*/ ,
tag_ntags =23
}
HTMLTags;
/*+ Tag strings +*/
static const char* const tags[]=
{
/* tag_a = 0 */ "a" ,
/* tag_area = 1 */ "area",
/* tag_base = 2 */ "base",
/* tag_blockquote= 3 */ "blockquote" ,
/* tag_body = 4 */ "body",
/* tag_del = 5 */ "del" ,
/* tag_frame = 6 */ "frame" ,
/* tag_head = 7 */ "head",
/* tag_iframe= 8 */ "iframe" ,
/* tag_input = 9 */ "input" ,
/* tag_ins =10 */ "ins" ,
/* tag_q =11 */ "q" ,
/* tag_script=12 */ "script" ,
/* tag_td=13 */ "td" ,
/* tag_complex =14 */ "",
/* tag_applet=15 */ "applet" ,
/* tag_embed =16 */ "embed" ,
/* tag_img =17 */ "img" ,
/* tag_link =18 */ "link",
/* tag_meta =19 */ "meta",
/* tag_object=20 */ "object" ,
/* tag_param =
Bug#469172: error in rsync protocol data stream (code 12) at io.c(600)
severity 469172 important thanks There is now a 3.0.0-2 version that has the fix for Kiko's problem (running rsync to a single-use daemon server process). Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#469172: error in rsync protocol data stream (code 12) at io.c(600)
tag 469172 unreproducible
thanks
On Mon 03 Mar 2008, Benjamí Villoslada wrote:
> El Dilluns 03 Març 2008, Paul Slootman va escriure:
> > It sucks that I can't reproduce this, I have a number of systems with
> > different architectures and they all work for me :-/
>
> Kiko is the user #2 that I've mentioned above :)
His problem was a specific problem with using -e ssh together with a
double colon, i.e. single-use daemon server, without passing a config
file explicitly.
Your problem with rsync.net is something else...
> I've remembered that we have one server with Debian Etch and rsync:
>
> $ rsync --version
> rsync version 2.6.9 protocol version 29
> [...]
>
>
> Works fine with my 3.0.0 client:
You showed earlier that rsync.net is using rsync 2.6.8.
However, when I try rsync 3.0.0 -> 2.6.8 it works fine.
I think that without any additional reports and without suitable help
from rsync.net in debugging this, it's not really possible to do
anything about this. The main problem is that the remote rsync simply
goes away without saying anything at all ("0 bytes received"), so the
problem is basically with that specific installation of rsync.
As this is not reproducible for most(?) people (who aren't using
rsync.net), I think I have little choice besides tagging it
unreproducible. I will upload a 3.0.0-2 version with the fix for Kiko's
problem, and will then mark this report as "important", not "grave",
because of the unreproduciblity...
Sorry I can't help more. My request to rsync.net for help was replied
with a no-brainer scripted helldesk answer "don't use -e ssh, that's
redundant" >:-(
Paul Slootman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#469172: error in rsync protocol data stream (code 12) at io.c(600)
On Mon 03 Mar 2008, Kiko Piris wrote: > > Hi, this morning I dist-upgraded 2 sid boxes. Then I found that rsync > over ssh failed with the mentioned error. > > Then I did some tests from a not-yet-distupgraded laptop and found out > this: > > 3.0.0-1 (client) ---> 2.6.9-6 (server)works fine > 2.6.9-6 (client) ---> 3.0.0-1 (server)fails > 3.0.0-1 (client) ---> 3.0.0-1 (server)fails On Tue 04 Mar 2008, Kiko Piris wrote: > On 04/03/2008 at 12:45 +0100, Paul Slootman wrote: > > > Can you try my test version? > This one works where it failed before: Does it work for you in all the combinations that you showed above? Unfortunately it looks like the original problem as reported by Benjam� was a different one; you were always using -e ssh togetr with a double colon, i.e. single-use daemon server mode. Benjam� was not. Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#469172: error in rsync protocol data stream (code 12) at io.c(600)
On Mon 03 Mar 2008, Kiko Piris wrote:
> >
> > Send the output to me, hopefully I can see what goes wrong then.
>
> Here they are :)
[...]
> 13135 open("/etc/popt", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or
> directory)
> 13135 open("/home/kiko/.popt", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such
> file or directory)
> 13135 rt_sigaction(SIGINT, {0x8051cd0, [], SA_NOCLDSTOP}, NULL, 8) = 0
> 13135 rt_sigaction(SIGHUP, {0x8051cd0, [], SA_NOCLDSTOP}, NULL, 8) = 0
> 13135 rt_sigaction(SIGTERM, {0x8051cd0, [], SA_NOCLDSTOP}, NULL, 8) = 0
> 13135 rt_sigprocmask(SIG_UNBLOCK, [HUP INT USR1 USR2 TERM CHLD], NULL, 8) = 0
> 13135 rt_sigaction(SIGPIPE, {SIG_IGN}, NULL, 8) = 0
> 13135 rt_sigaction(SIGXFSZ, {SIG_IGN}, NULL, 8) = 0
> 13135 getcwd("/home/kiko", 4095)= 11
> 13135 fcntl64(0, F_GETFL) = 0x2 (flags O_RDWR)
> 13135 fcntl64(0, F_SETFL, O_RDWR|O_NONBLOCK) = 0
> 13135 fcntl64(1, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
> 13135 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> 13135 +++ killed by SIGSEGV +++
Hmm, not good
[...]
> 13395 time(NULL) = 1204567405
> 13395 geteuid() = 1000
> 13395 memset(0x80a9b20, '\000', 80) = 0x80a9b20
> 13395 umask(00) = 027
> 13395 setlocale(0, "") = "en_US.UTF-8"
> 13395 getenv("RSYNC_ICONV") = NULL
> 13395 poptGetContext(0x808bc7f, 4, 0xbfb415d4, 0x8099ea0, 0) = 0x80ab830
> 13395 poptReadDefaultConfig(0x80ab830, 0, 0xbfb415d4, 0x8099ea0, 0) = 0
> 13395 poptGetNextOpt(0x80ab830, 0, 0xbfb415d4, 0x8099ea0, 0) = 1022
> 13395 poptFreeContext(0x80ab830, 0, 0xbfb415d4, 0x8099ea0, 0) = 0
> 13395 poptGetContext(0x808bc7f, 4, 0xbfb415d4, 0x8099ea0, 0) = 0x80ab830
> 13395 poptGetNextOpt(0x80ab830, 4, 0xbfb415d4, 0x8099ea0, 0) = 1022
> 13395 poptGetNextOpt(0x80ab830, 4, 0xbfb415d4, 0x8099ea0, 0) = 1001
> 13395 poptFreeContext(0x80ab830, 4, 0xbfb415d4, 0x8099ea0, 0) = 0
> 13395 poptGetContext(0x808bc7f, 4, 0xbfb415d4, 0x809b320, 0) = 0x80ab830
> 13395 poptGetNextOpt(0x80ab830, 4, 0xbfb415d4, 0x809b320, 0) = -1
> 13395 poptGetArgs(0x80ab830, 4, 0xbfb415d4, 0x809b320, 0) = 0x80ab9c8
> 13395 sigaction(2, 0x80a7fc0, NULL) = 0
> 13395 sigaddset(0xbfb4146c, 2) = 0
> 13395 sigaction(1, 0x80a7fc0, NULL) = 0
> 13395 sigaddset(0xbfb4146c, 1) = 0
> 13395 sigaction(15, 0x80a7fc0, NULL) = 0
> 13395 sigaddset(0xbfb4146c, 15) = 0
> 13395 sigprocmask(1, 0xbfb4146c, NULL) = 0
> 13395 sigaction(13, 0x80a7fc0, NULL) = 0
> 13395 sigaction(25, 0x80a7fc0, NULL) = 0
> 13395 getcwd(0x80a8ac0, 4095)= "/home/kiko"
> 13395 nl_langinfo(14, 0xbfb41554, 0xbfb3f468, 0x805f812, 0x80a8ac0) =
> 0xb7be6e88
> 13395 fcntl(0, 3, 0, 0xbfb4146c, 0xbfb4146c) = 2
> 13395 fcntl(0, 4, 2050, 0xbfb4146c, 0xbfb4146c) = 0
> 13395 fcntl(1, 3, 2050, 0xbfb4146c, 0xbfb4146c) = 2050
> 13395 strlen(NULL
> 13395 --- SIGSEGV (Segmentation fault) ---
> 13395 +++ killed by SIGSEGV +++
OK, thanks for this, this should be helpful in finding what's wrong.
Could you do the next couple of extra things, on the receiving side?
/usr/sbin/validlocale en_US.UTF-8
grep -v '^#' /etc/locale.gen
thanks,
Paul Slootman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#469172: error in rsync protocol data stream (code 12) at io.c(600)
On Mon 03 Mar 2008, Kiko Piris wrote: > > > > Both sides are Debian in the above list? (Probably yes, as you show the > > -X version part, but I want to know for sure.) > > Yup, sid boxes all of them. All up-to-date (except for the one with > rsync=2.6.9-6 of course). OK > > Does the exact same thing happen as in the original report? Including > > the "0 bytes received" message? > > Yes: > > | # rsync -a -v --inplace --delete --progress -e "ssh -l kiko" > rompetechosw.pirispons.net::mymusic/collection /home/MyMusic > | cmd=ssh -l kiko machine=rompetechosw.pirispons.net user= > path=mymusic/collection > | cmd[0]=ssh cmd[1]=-l cmd[2]=kiko cmd[3]=rompetechosw.pirispons.net > cmd[4]=rsync cmd[5]=--server cmd[6]=--daemon cmd[7]=. > | opening connection using ssh -l kiko rompetechosw.pirispons.net rsync > --server --daemon . > | rsync: connection unexpectedly closed (0 bytes received so far) [receiver] > | _exit_cleanup(code=12, file=io.c, line=454): entered > | rsync error: error in rsync protocol data stream (code 12) at io.c(454) > [receiver=2.6.9] > | _exit_cleanup(code=12, file=io.c, line=454): about to call exit(12) > > > These are all i386? > > Yes. > > > It sucks that I can't reproduce this, I have a number of systems with > > different architectures and they all work for me :-/ > > Aww, I do not know what to do to help. Please let me know if I can test > anything. You don't have rsync running as a daemon? Then you need a wrapper around rsync to run strace; on the remote system, create a shell script: #!/bin/sh strace -f -o /tmp/rsync.strace.out /usr/bin/rsync "$@" Make that executable, install strace, put it in your homedir as rsync.strace, and then call rsync like this: rsync -a -v --inplace --delete --progress -e "ssh -l kiko" --rsync-path=/home/kiko/rsync.strace rompetechosw.pirispons.net::mymusic/collection /home/MyMusic (fix the /home/kiko/rsync.strace if necessary) That should then run rsync under strace so that all the system calls that rsync does is logged in the /tmp/rsync.strace.out file. It may also be useful to do the same thing, but now use ltrace instead of strace. That logs all the library calls. Send the output to me, hopefully I can see what goes wrong then. thanks, Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#469172: error in rsync protocol data stream (code 12) at io.c(600)
On Mon 03 Mar 2008, Kiko Piris wrote: > > Hi, this morning I dist-upgraded 2 sid boxes. Then I found that rsync > over ssh failed with the mentioned error. > > Then I did some tests from a not-yet-distupgraded laptop and found out > this: > > 3.0.0-1 (client) ---> 2.6.9-6 (server)works fine > 2.6.9-6 (client) ---> 3.0.0-1 (server)fails > 3.0.0-1 (client) ---> 3.0.0-1 (server)fails Both sides are Debian in the above list? (Probably yes, as you show the -X version part, but I want to know for sure.) > Can I provide any additional information? Does the exact same thing happen as in the original report? Including the "0 bytes received" message? These are all i386? It sucks that I can't reproduce this, I have a number of systems with different architectures and they all work for me :-/ Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#469172: error in rsync protocol data stream (code 12) at io.c(600)
On Mon 03 Mar 2008, Benjamí Villoslada wrote: > > In the rsync.net side: I can ask to technical service. I already sent a message to support@ , hopefully that will give some useful response. Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#469172: error in rsync protocol data stream (code 12) at io.c(600)
On Mon 03 Mar 2008, Benjamí Villoslada wrote: > From: Benjamí Villoslada <[EMAIL PROTECTED]> Cool, ".cat", I just noticed :-) > > Do they connect to the same server? It looks like something at that side > > goes wrong. > > User #1: > > with rsync.net too, but the ch-s010.rsync.net server > > -- > $ ssh [EMAIL PROTECTED] rsync --version > rsync version 2.6.6 protocol version 29 > Copyright (C) 1996-2005 by Andrew Tridgell and others > <http://rsync.samba.org/> > Capabilities: 64-bit files, socketpairs, hard links, symlinks, batchfiles, > inplace, IPv6, 32-bit system inums, 64-bit internal inums Ah, even older. > > Could you please login to usw-s002.rsync.net, and then from the shell, > > do: > > rsync --server -vlogDtpre.iL --delete . > > itaca/benjami/public_html > > > > It should show nothing. > > Yes: > > [EMAIL PROTECTED]:~$ ssh [EMAIL PROTECTED] > rsync --server -vlogDtpre.iL --delete . itaca/benjami/public_html > [EMAIL PROTECTED]:~$ > > > > If you hit return a number of times it will > > complain about a protocol problem. Could you show that? > > rsync.net have only non-interactive ssh :( OK, but does the command stop immediately when you run it non-interactively? If so, that's the problem; rsync.net apparently forces some command and it doesn't recognize the "e.iL" part which is new, so it doesn't start the command. I think you should ask rsync.net to support rsync version 3.0.0. > http://www.rsync.net/resources/faq.html#7b Interesting, thanks. Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#469172: error in rsync protocol data stream (code 12) at io.c(600)
On Mon 03 Mar 2008, Benjamí Villoslada wrote: > opening connection using: ssh -l my_login usw-s002.rsync.net > rsync --server -vlogDtpre.iL --delete . itaca/benjami/public_html > rsync: connection unexpectedly closed (0 bytes received so far) [sender] Another thing that I thought of: you don't happen to force any commands with the authorized_keys stuff in ssh? Could you try again with ~/.ssh moved away on the remote side? Does the system sshd_config perhaps have any particular things relating to ssh? Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#469172: error in rsync protocol data stream (code 12) at io.c(600)
On Mon 03 Mar 2008, Benjamí Villoslada wrote:
>
> Two friends --with Debian Sid-- have reported (in Twitter :) today rsync
> problems after dist-upgrade.
Do they connect to the same server? It looks like something at that side
goes wrong.
> > It seems like the remote rsync simply didn't
> > start (the "0 bytes received so far" message).
>
> Have no changes since last rsync, but for this test I've created one new file.
>
> > Please run it again with -v and capture all the output generated
> > by this. Also try without the -z option.
>
> Without the -z option:
>
> [EMAIL PROTECTED]:~$ touch ~/public_html/foo.html
>
> [EMAIL PROTECTED]:~$ rsync -av --delete /home/benjami/public_html/
> [EMAIL PROTECTED]:itaca/benjami/public_html
> FILE_STRUCT_LEN=16, EXTRA_LEN=4
> cmd= machine=usw-s002.rsync.net user=my_login
> path=itaca/benjami/public_html
> cmd[0]=ssh cmd[1]=-l cmd[2]=my_login cmd[3]=usw-s002.rsync.net cmd[4]=rsync
> cmd[5]=--server cmd[6]=-vlogDtpre.iL cmd[7]=--delete cmd[8]=.
> cmd[9]=itaca/benjami/public_html
> note: iconv_open("UTF-8", "UTF-8") succeeded.
> opening connection using: ssh -l my_login usw-s002.rsync.net
> rsync --server -vlogDtpre.iL --delete . itaca/benjami/public_html
Could you please login to usw-s002.rsync.net, and then from the shell,
do:
rsync --server -vlogDtpre.iL --delete . itaca/benjami/public_html
It should show nothing. If you hit return a number of times it will
complain about a protocol problem. Could you show that?
Paul Slootman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#469172: error in rsync protocol data stream (code 12) at io.c(600)
On Mon 03 Mar 2008, Benjamí Villoslada wrote: > Package: rsync > Version: 3.0.0-1 > Severity: grave > Justification: renders package unusable > > > rsync between local disks works fine, but rsync + ssh fails: > > --- > $ rsync -artvz -e ssh --delete /home/x/y/ [EMAIL PROTECTED]:x/y/ > rsync: connection unexpectedly closed (0 bytes received so far) [sender] > rsync error: error in rsync protocol data stream (code 12) at io.c(600) > [sender=3.0.0] > --- As I have no problems whatsoever with 3.0.0-1, with ssh or whatever transport, some more information would be very helpful. Did it stop immediately? It seems like the remote rsync simply didn't start (the "0 bytes received so far" message). Please run it again with -v and capture all the output generated by this. Also try without the -z option. You also don't mention what version the remote host is using, please try to find out. Note that when using -a, -rt is redundant. Also, -e ssh has been the default for a long time. thanks, Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#423646: wwwoffle: The WWWOFFLE root CA private key file 'certificates/root/root-key.pem' cannot be loaded.
On Thu 03 Jan 2008, Hilmar Preusse wrote: > Starting HTTP cache proxy server: wwwoffled > > > > wwwoffled[12054] Warning: The WWWOFFLE root CA private key file > 'certificates/root/root-key.pem' does not exist; creating it. > > Paul, if this is really the point in time, when wwwoffle creates > certs it should at least inform about it. Thanks for this wake up call, wwwoffle was a bit too low on my priority list :-( If it can take that much time, then perhaps the generation of the certificate should be moved to the background or so. I'll investigate tomorrow. Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447595: closed by Paul Slootman <[EMAIL PROTECTED]> (Re: Bug#447595: rsync writes zeros to destination files on nfs volumes)
On Tue 11 Dec 2007, Andreas Ley wrote: > >As I didn't receive any feedback for almost 2 months, I'm now closing > >this bug report. > > In fact, I did send feedback (on Mon, 22 Oct 2007 18:50:21 +0200 (CES)), > but didn't receive any answer, so I guessed you classified the problem > as non-debian related and silently discared it (AFAIK there's no web > page where I could've looked up the status of the bug). I later found There is: http://bugs.debian.org/ is the main page, http://bugs.debian.org/447595 shows the log of this specific bug. There's no log of your response there either, so unfortunately it seems that your message was lost somewhere :-( > out, that other applications also show this bug, filed it as a kernel > bug (http://bugzilla.kernel.org/show_bug.cgi?id=9315) and got told, > that this was a known problem, with an existing but for several weeks > unreleased patch. > > So yes, the bug should be closed, but with a "solved" state. OK, that's good :-) Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#453652: rsync: prone to symlink attacks
On Fri 30 Nov 2007, Nico Golde wrote: > > > > There is a patch available for 2.6.9 (2.6.9-2etch1 is the current stable > > version). > > http://rsync.samba.org/ftp/rsync/munge-symlinks-2.6.9.diff > if you mean this patch this at least does not apply to the > unstable version thats why I ported it. I have not checked > if this does apply to the stable version. Hmm, that patch should apply to both stable and testing... > > 2.6.4 is "oldstable". I think first priority is the stable version... > > Yes. As I am only in the testing security team and thus > handling testing and unstable issues please contact > [EMAIL PROTECTED] to check if this is worth a DSA. Well, then I'm even more surprised that the patch you pasted listed 2.6.4 as the version being patched?! Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#453652: rsync: prone to symlink attacks
On Fri 30 Nov 2007, Nico Golde wrote: > attached is an NMU proposal to fix this bug just in case you > have no time to fix this. Is this based on upstream's patch? > For this I needed to backport the patch cause it won't apply > with the version in Debian. There is a patch available for 2.6.9 (2.6.9-2etch1 is the current stable version). 2.6.4 is "oldstable". I think first priority is the stable version... thanks, Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447595: rsync writes zeros to destination files on nfs volumes
On Mon 22 Oct 2007, Andreas Ley wrote: > > At least when syncing the 2007-10-20T13:49:53 version of > security.debian.org::debian-security/dists/etch/updates/main/binary-i386/Packages.gz > on etch (2.6.9-2etch1) or sarge (2.6.4-6) to an nfs destination, rsync writes > zeroes from 4c00 to 4fff in the destination file. Local destinations work > fine, > as does rsync on woody (2.5.5-0.6). Other source files haven't been tested > yet. > The same applies to a self-compiled (on woody) 2.6.9 with sources from > rsync.samba.org - works on woody, fails on sarge and etch. I've tried it on a number of different systems, both with and without transferring to an NFS system, on different architectures, but I cannot reproduce the problem you're seeing. I'm wondering whether perhaps one of the security mirror sites has a bad copy of the Packages.gz file. When I lookup the IP address, I get three answers: security.debian.org A 128.31.0.36 security.debian.org A 212.211.132.32 security.debian.org A 212.211.132.250 The first gives a connection refused, the other two give the correct file (verified with the md5sum as listed in http://security.debian.org/dists/stable/updates/Release.gpg ) If you repeat the transfer with -vic options added, does it in fact report that the checksum is wrong and attempt to update? Otherwise, a transcript of the output given by -v while it goes wrong would be helpful, including an strace log as well (dont' forget -f option to strace, as rsync forks). thanks Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404861: upgrade to wwwoffle 2.9a-1 overwrote local change in wwwoffle.conf
severity 404861 important thanks On Fri 29 Dec 2006, Frank K?ster wrote: > Vincent Lefevre <[EMAIL PROTECTED]> wrote: > > > On 2006-12-28 21:03:57 +0100, Paul Slootman wrote: > >> This is I think a question of interpretation; > >> if the local change modifies the way the package works in any way, then > >> I agree; but a comment?! Where does it end? Do you want upgrades to > >> preserve the mtime of the configuration file as well? How about the > >> filesize, if that was changed locally? > > > > A comment can contain valuable information. For instance, the admin > > could add a note about why he set some value. > > Indeed. However, this information is still available in the backup > file. > > > IMHO, comments should > > be preserved, > > Often this is possible using sed on the configuration file. The thing is, upstream provides a quite complicated perl script to handle the upgrades; and that script is pretty good at doing that, apart from the fact that comments aren't preserved. It will be very difficult to make it preserve comments, if not impossible. > > If really you can't preserve the comments, it must be said at the > > beginning of the configuration file. > > That would also be a good idea. Agreed. > In summary, I think that wwwoffle's handling of wwwoffle.conf is > suboptimal, but I don't see how this is release-critical. The wording > of Policy and etch_rc_policy.txt is unclear about this, I think, but I > would downgrade this bug to important. OK, sounds reasonable. Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404861: upgrade to wwwoffle 2.9a-1 overwrote local change in wwwoffle.conf
On Thu 28 Dec 2006, Vincent Lefevre wrote: > The upgrade from wwwoffle 2.9-2 to 2.9a-1 overwrote a local change in > /etc/wwwoffle/wwwoffle.conf (at least a comment I had added at the end > of the file, which disappeared). > > Section 10.7.3 of the Debian policy says: > > local changes must be preserved during a package upgrade This is I think a question of interpretation; if the local change modifies the way the package works in any way, then I agree; but a comment?! Where does it end? Do you want upgrades to preserve the mtime of the configuration file as well? How about the filesize, if that was changed locally? Upgrading to certain versions of wwwoffle has always needed to update the configuration file, otherwise the package simply doesn't work correctly after the upgrade, and that would cause a lot more people to file bug reports. All the user settings are preserved if at all possible (it's not possible e.g. if an option goes away, although that hasn't happened up to now IIRC). Besides, the original configuration file is backed up, so if the comment was important to you, you can still find it. I'm inclined to disagree that a comment is a "local change" here, especially as it does not influence the way the package works at all. Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403605: exim4-config: dc_other_hostnames expanded by the shell, corrupting it
Package: exim4-config Version: 4.63-11 Severity: grave Justification: email was bounced, thus lost to me I have a wildcard MX *.wurtel.net, and that's filled in /etc/exim4/update-exim4.conf.conf accordingly: dc_other_hostnames='wurtel.net : *.wurtel.net : ...' However, I noticed once that instead of *.wurtel.net, the generated config file had db.wurtel.net. At the time I passed that off as an error on my part, as when running update-exim4.conf again it was correct. Today I again noticed in the exim logs that a lot of mail was being bounced due to "relay not permitted". Again I saw db.wurtel.net instead of *.wurtel.net, and now I was sure I hadn't made any mistake. Upon investigation it appeared that if a file exists in the current directory that matches *.wurtel.net when update-exim4.conf is run, the filename is filled into the config file, hence corrupting it :-( update-exim4.conf echoes the value of dc_other_hostnames without any quoting! I could imagine that this might even be used to bypass security if a malicious user could get an admin to run update-exim4.conf in a directory with specially prepared filenames. I recommend that a fix is included in the version that's to go into etch. Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#400329: wwwoffle: lock-files in concurrent downloading broken either way
Hi Andrew, please take a look at the following Debian bug report. I've written a few comments at the end. (Please preserve [EMAIL PROTECTED] in the CC: list when responding, so that your responses can be tracked by the Debian BTS.) On Sat 25 Nov 2006, Tim Connors wrote: > Subject: Bug#400329: wwwoffle: lock-files in concurrent downloading broken > either way > From: Tim Connors <[EMAIL PROTECTED]> > To: Debian Bug Tracking System <[EMAIL PROTECTED]> > Package: wwwoffle > Version: 2.9-2 > Severity: grave > Justification: causes non-serious data loss > > wwwoffle has the setting: > # lock-files = yes | no > # Enable the use of lock files to stop more than one WWWOFFLE process > # from downloading the same URL at the same time (default=no). > > Either way this is set, it is broken. > > If set to yes, it seems that a lockfile only manages to tell the > second process to give up loading the page at all, giving back a HTTP > 500 WWWOFFLE Server Error: > > > for i in `seq 1 10 ` ;do lynx -dump http://www.google.com.au & done > > WWWOFFLE - World Wide Web Offline Explorer - v2.9 > _ > >WWWOFFLE Server Error > >The WWWOFFLE server encountered a fatal error: > > Cannot open the spooled web page to read. > The program cannot continue to service this request. > > Help > >This is an internal WWWOFFLE server error that should not occur. There >is no other way of handling the error apart from providing this >warning page. If this error continues and WWWOFFLE is configured >correctly and there are no other computer problems then you should >report the error to the WWWOFFLE author. > _ > >WWWOFFLE - [[1]Welcome Page|[2]FAQ] - WWWOFFLE > > References > >1. http://scuzzie:8080/Welcome.html >2. http://scuzzie:8080/FAQ.html > ... > > By loading many pages at once as above, some of them end up succeeding > after the cache has been loaded, but prior to that, all but one of > them are going to fail -- above I'd see 5 or so error pages, then 5 or > so successful downloads -- YMW(ill)V as my computer is probably slow > enough for this test to come out this way. > > If set to no, then the first process to hit the cache gets their > download, but the second process only retrieves as much as had reached > the first process at that time. So the second download ends up > incomplete. No error is returned, so it may not even be apparent > until a later date -- hence dataloss. > > Marked as grave because of dataloss, since any webpage using crappy > session management, or submition of forms, etc, ends up being broken > whenever the page is being concurrently loaded in two seperate > pages/processes with either setting, and one copy will not be complete > or will fail altogether. Most of the rest of the time, a reload ought > to fix it, but this sometimes ends up loading from the browser's own > cache, which has only been half downloaded (I can't seem to convince > opera to drop its version of its cache, and reload from the proxy) I've responded that it's not a grave loss of data, as that's what the option is for; say "yes" if you want to prevent that. That said, the error you get when a page is indeed locked, is a bit unexpected: "This is an internal WWWOFFLE server error that should not occur." It's after all a documented option... IMHO the second process should wait for the completion of the first download process before proceeding; giving an "500 WWWOFFLE Server Error" is not the right thing to do here... thanks, Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#400329: wwwoffle: lock-files in concurrent downloading broken either way
severity 400329 important tags 400329 + upstream thanks On Sat 25 Nov 2006, Tim Connors wrote: > > wwwoffle has the setting: > # lock-files = yes | no > # Enable the use of lock files to stop more than one WWWOFFLE process > # from downloading the same URL at the same time (default=no). > > Either way this is set, it is broken. > > If set to yes, it seems that a lockfile only manages to tell the > second process to give up loading the page at all, giving back a HTTP > 500 WWWOFFLE Server Error: Well, it _does_ stop the additional WWWOFFLE processes from downloading the same URL, exactly as documented; nowhere does it say it does that gracefully. A simple reload after that will fix this, right? The 500 error page shouldn't be cached by your browser... > If set to no, then the first process to hit the cache gets their > download, but the second process only retrieves as much as had reached > the first process at that time. So the second download ends up > incomplete. No error is returned, so it may not even be apparent > until a later date -- hence dataloss. > > Marked as grave because of dataloss, since any webpage using crappy There's only dataloss if you set it to "no", so if it's probable that more than one user will be downloading the same URL simultaneously, then you should set it to "yes" (and expect the 500 error page to appear at those times, and be prepared to hit "reload"). > session management, or submition of forms, etc, ends up being broken > whenever the page is being concurrently loaded in two seperate > pages/processes with either setting, and one copy will not be complete In case of crappy session management, if more than one person is accessing the same pages, you wouldn't want the second (or third etc.) person to wait for the first's download to complete only to view that page, instead of the one belonging to his own session... so in that case the point is pretty moot, and the website simply broken, whatever caching system you use. > or will fail altogether. Most of the rest of the time, a reload ought > to fix it, but this sometimes ends up loading from the browser's own > cache, which has only been half downloaded (I can't seem to convince > opera to drop its version of its cache, and reload from the proxy) Traditionally shift-reload will do that. As the data loss you describe only happens when the lock-files is set to "no", I can't agree that the severity should indeed be "grave"; "important" seems much more appropriate, so I'm downgrading this bug's severity now. The whole point of the lock-files setting is to cope with this situation... Also keep in mind that the primary target of wwwoffle is a single system behind a dialup line, where the chances of multiple browser sessions downloading the same URL simultaneously aren't that large. In the meantime I'll contact the upstream author and try to resolve the 500 server error response, which, although not quite contrary to the documentation, is fairly unexpected (especially given the contents of that page :-) Thanks, Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#327049: wwwoffle: Restores removed conffile
> I also don't have much time currently, therefore I can't promise you a > working patch right now. I have a version that I think works OK, I'll upload now. (2.9-1). If there are problems with it, feel free to NMU, using that version as a basis. I'm away on vacation for a week or so from tomorrow. Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#327049: wwwoffle: Restores removed conffile
Real life delays, sorry... On Thu 06 Apr 2006, Frank K?ster wrote: > So does it make sense that I start of with the old ones? I guess I need Yes... > config, postinst and maybe the templates file. > > Here's a quick shot, untested: > > In wwwoffle.config: > > if [ -s /etc/cron.d/wwwoffle ]; then > ... as before ... > elif [ -n "$CONFIG_ARG2" ]; # do this only when this is not a fresh install >db_set wwwoffle/fetchfrequency off > fi > > db_get wwwoffle/fetchfrequency ### > rc=$? > - if [ $rc -eq 0 -o $rc -ge 30 ]; then # bashism, and won't catch "off" Hmm, that's not what I have in my wwwoffle.config ... 2.8e-2 at least doesn't have that. Besides, -o is NOT a bashism, I've been using that since SystemVR2. ash accepts it fine also. > But I don't understand the purpose of the first test where I fixed the > bashism - why do you only act on the crontab file if the value is zero > or if it is at least 30? That means that I can't set it to 20 via > debconf, doesn't it? You seriously need to study debconf.... the value is in $RET; here $rc contains the status, not the debconf value. 30 == question not asked. Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#327049: wwwoffle: Restores removed conffile
On Fri 02 Jun 2006, [EMAIL PROTECTED] wrote: > Hello Paul, what is the status with this package ? > As a result of this problem, wwwoffle has been removed from testing. Unfortunately real life got into the way. I hope to upload a fixed version within 10 days. Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#365614: rsync: Integer overflow in the receive_xattr function (remote exploit)
On Mon 01 May 2006, Jay Kline wrote: > Package: rsync > Version: 2.6.4-6 > Severity: grave > Tags: security > Justification: user security hole > > > Integer overflow in the receive_xattr function in the extended > attributes patch (xattr.c) for rsync before 2.6.8 might allow attackers > to execute arbitrary code via crafted extended attributes that trigger a > buffer overflow. Do you have reason to believe that Debian's rsync 2.6.4-6 has that patch applied? Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#327049: wwwoffle: Restores removed conffile
On Wed 05 Apr 2006, Frank Küster wrote: > Paul Slootman <[EMAIL PROTECTED]> wrote: > > > On Wed 05 Apr 2006, Frank Küster wrote: > >> Paul Slootman <[EMAIL PROTECTED]> wrote: > >> > >> > If you enter a value via the debconf dialog that indicates that wwwoffle > >> > should regularly fetch its list, then why remove the cron.d entry... > >> > >> Because debconf is not a registry. It's a frontend for maintainer > >> scripts to interact with local admins, but the actuall *settings* are > >> stored in /etc/. > > > > I'm talking about the case where you just entered a value, > > interactively. > > But I may have changed my mind, and i shouldn't be forced to use debconf > then. No, I *mustn't* be forced. I'm talking about someone who wants to use debconf... He chose at one time to have the fetching active, removed the cron.d script later, and then changed his mind again, and thinks he can reactivate it via debconf. > > As I said above: I'm talking about the case where you just entered a > > value, interactively. Say, the configuration is parsed (the cron.d file > > is missing, so debconf is seeded with "never"), the user changes that to > > every 30 minutes, hence expects that from that moment on wwwoffle will > > fetch its list every 30 minutes. However, you demand that the postinst > > should never recreate the cron.d file, as the user removed it. > > No, I don't demand that. I only demand that the postinst script not > create the file unconditionally. If a debconf question is seeded with > "no", asked or not, and the postinst script acts according to the > answer, everything is fine. I read your bug report to mean that if the user removes the file, postinst should never, ever recreate it again, because that's what the user wants, otherwise he wouldn't have removed the file. And that's what I have a problem with, because that would mean that if he does dpkg-reconfigure again and enters a fetch frequency, "I" (the postinst script) wouldn't be allowed to create the file again. Your exact words were "and indeed the postinst scripts recreates the file if it has been deleted.", indicating that was the problem. You didn't qualify that statement with "unconditionally" or so... > >> This case can easily be distinguished because, like a postinst, config > >> gets a second parameter which is the version number of the > >> last-configured (i.e. the currently installed) package. If it's a fresh > >> install, $2 is empty. > > > > No, it's freshly installed, but the user runs dpkg-reconfigure because > > he wants to turn on the fetch feature, which he didn't turn on during > > the initial install; that's the situation I meant to demonstrate; sorry > > if that wasn't clear. > > So, where's the problem? He's asked the question, changes from "no" to > "yes" and a specific value, and the change is done - or he doesn't > change, either because he doesn't want to, or he doesn't see the > questions, and no change is done. My problem is with the wording of your bug report, you demand the file mustn't be recreated. If you now qualify that by saying that if the user does indeed enter a frequency again then it's OK to recreate the file, then I indeed don't have a problem anymore. > >> I'd offer to write a patch if you don't want to, or don't have time to > >> dig into this. > > > > If you could take into account all possible situations... then please. > > Note that I am in the process of packaging 2.9, and the maintainer > > script will be changed a lot (I'm taking out support for upgrading from > > before woody, which will simplify things and which should be more than > > enough). > > Is the new maintainer script available somewhere? Not yet. Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#327049: wwwoffle: Restores removed conffile
On Wed 05 Apr 2006, Frank Küster wrote: > Paul Slootman <[EMAIL PROTECTED]> wrote: > > > If you enter a value via the debconf dialog that indicates that wwwoffle > > should regularly fetch its list, then why remove the cron.d entry... > > Because debconf is not a registry. It's a frontend for maintainer > scripts to interact with local admins, but the actuall *settings* are > stored in /etc/. I'm talking about the case where you just entered a value, interactively. > > If I left that file alone when someone removed it, I'd get critical bug > > reports that the functionality is broken because even after repeated > > dpkg-reconfigure attempts at entering a fetch frequency, it doesn't > > fetch anything. > > If that happens, you didn't write the config script as debconf-devel > advices. The way to go is to parse the configuration (does the file > exist? If yes, which interval does it specify?) and put these values > into the debconf database via db_set, then ask the questions, then in > postinst db_get the answers and make the changes, if needed. This is > all described in debconf-devel(7), under "Config file handling". As I said above: I'm talking about the case where you just entered a value, interactively. Say, the configuration is parsed (the cron.d file is missing, so debconf is seeded with "never"), the user changes that to every 30 minutes, hence expects that from that moment on wwwoffle will fetch its list every 30 minutes. However, you demand that the postinst should never recreate the cron.d file, as the user removed it. Help! :) What to do? > > Please tell me how I should resolve this dilemma. Please don't just say > > "if it's removed, don't recreate it"; give me some pseudo-code on how to > > handle the different situations. I find it difficult to distinguish the > > following two situations: > > > > - wwwoffle is freshly installed, there is and has never been a > > /etc/cron.d/wwwoffle file, and the user runs dpkg-reconfigure and > > enters a fetch frequency. > > This case can easily be distinguished because, like a postinst, config > gets a second parameter which is the version number of the > last-configured (i.e. the currently installed) package. If it's a fresh > install, $2 is empty. No, it's freshly installed, but the user runs dpkg-reconfigure because he wants to turn on the fetch feature, which he didn't turn on during the initial install; that's the situation I meant to demonstrate; sorry if that wasn't clear. > I'd offer to write a patch if you don't want to, or don't have time to > dig into this. If you could take into account all possible situations... then please. Note that I am in the process of packaging 2.9, and the maintainer script will be changed a lot (I'm taking out support for upgrading from before woody, which will simplify things and which should be more than enough). Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#327049: wwwoffle: Restores removed conffile
On Wed 07 Sep 2005, Frank Küster wrote: > > /etc/cron.d/wwwoffle contains: > > # If you want to disable this, comment out the line > # below (don't simply remove this file). Note also that your subject is incorrect, it is *not* marked a conffile. It's not even shipped with the package. > and indeed the postinst scripts recreates the file if it has been > deleted. However, the policy says clearly: > > , > | 10.7.3 Behavior > | > | Configuration file handling must conform to the following behavior: > | > | * local changes must be preserved during a package upgrade, and > | * configuration files must be preserved when the package is > | removed, and only deleted when the package is purged. > ` > > Local modifications also include file deletion. You can't override this > rule by simply saying "don't do that". That same paragraph also states: ,--- | If the existence of a file is required for the package to be sensibly | configured it is the responsibility of the package maintainer to | provide maintainer scripts which correctly create, update and maintain | the file and remove it on purge. `--- If you enter a value via the debconf dialog that indicates that wwwoffle should regularly fetch its list, then why remove the cron.d entry... If I left that file alone when someone removed it, I'd get critical bug reports that the functionality is broken because even after repeated dpkg-reconfigure attempts at entering a fetch frequency, it doesn't fetch anything. Please tell me how I should resolve this dilemma. Please don't just say "if it's removed, don't recreate it"; give me some pseudo-code on how to handle the different situations. I find it difficult to distinguish the following two situations: - wwwoffle is freshly installed, there is and has never been a /etc/cron.d/wwwoffle file, and the user runs dpkg-reconfigure and enters a fetch frequency. - wwwoffle was already installed, there was a fetch frequency defined, but now the user has removed the /etc/cron.d/wwwoffle file and now re-runs dpkg-reconfigure. Thanks, Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#322009: fixed in linpopup 1.2.0-8
reopen 322009 thanks On Thu 09 Mar 2006, Paul Slootman wrote: >* add alternate dependency debconf-2.0. > closes:#322009 Aaargh, should be 332009. Reopening now. Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#351552: reassign to adduser
On Sun 05 Feb 2006, Marc Haber wrote: > > We are still trying to reproduce the bug, as the patch listed in > #351480 doesn't seem to help :-( One thing that I noticed: after gid 101, I have 1000 in my /etc/group. 102 comes later. And group id 102 isn't used in /etc/passwd. Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318808: libcapi20-3 is empty again
On Wed 04 Jan 2006, Michael Biebl wrote: > Paul Slootman wrote: > > On Mon 02 Jan 2006, Michael Biebl wrote: > > > >> I can confirm this bug. > > > > Did you confirm it with version 3.8.2005-12-06-2 ? > > Unfortunately 3.8.2005-12-06-2 doesn't fix the problem. libcapi20-3 is > still missing the so files. Hmm, the uploader screwed up again... > I also know that I takes time to maintain a package and you shouldn't > consider this as a personal offense. I do appreciate everyones work for > Debian. I actually haven't had time for this particular package for some time, uploads have mainly been the kind work of Matthias Klose, although the last one was done by someone else. > > Additionally, isdnutils is rather large, and maintaining it has become a > > team effort (although I confess I need to get a bit more involved...) > > Feel free to help ;-) > > I actually sent you some ideas/files (making capi devices hotpluggable) > but never heard back from you. As it's a team effort, sending such things as wishlist bugs is the best, so that there's a record of it, and anyone can see it. I'm afraid that that message is probably lost in the 4000 messages in my inbox :-( If you happen to still have your sent copy, please do send it as a wishlist bug. Thanks, Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318808: libcapi20-3 is empty again
On Mon 02 Jan 2006, Michael Biebl wrote: > I can confirm this bug. Did you confirm it with version 3.8.2005-12-06-2 ? > Please test your package more thoroughly before uploading as this is not > the first time that something like this happens and very unpleasant for > a dial-up user if you don't have an old copy of libcapi20-3. I agree that it's unpleasant, but that's why it's called "unstable", by running that you run the risk of breakage. May I suggest using "testing", which won't have the most obvious bugs... Additionally, isdnutils is rather large, and maintaining it has become a team effort (although I confess I need to get a bit more involved...) Feel free to help ;-) Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#344200: URGENTLY needs support for the latest ppp package
On Tue 20 Dec 2005, Marco d'Itri wrote: > > Please rebuild pppdcapiplugin for ppp 2.4.4b1. > Expect a NMU if this will not be fixed soon, because it's blocking ppp > from entering testing. Go ahead, I'm a bit out of the ISDN stuff at the moment due to circumstances :-( thanks, Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#315671: webcalendar: New upstream version with security fixes available
On Fri 24 Jun 2005, Herbert Thielen wrote:
> Package: webcalendar
> Version: 0.9.45-4
> Severity: grave
> Tags: security
> Justification: user security hole
>
> According to http://freshmeat.net/projects/webcalendar there is a new
> version 1.0.0 available, which includes "major security fixes" of
> version 1.0RC3 ("all users should upgrade").
If I don't see any response from the maintainer within a couple of days,
I will NMU version 1.0.0.
Paul Slootman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#308428: New rsync completely breaks systemimager-server
On Tue 10 May 2005, Roberto C. Sanchez wrote: > >> > >>>I'm guessing this is related to #307923. Please add a line > >>>log file = /var/log/rsyncd.log > >>>to the top of /etc/rsyncd.conf, and try it again. At least, I'm assuming > >>>you're using an rsync daemon; you give very little information on how > >>>rsync is being used. > >>> > If you could clarify, should there be a space between log and file? Yes. (Exactly as shown above.) It should be outside any module definitions, i.e. at the top of the file. Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#308428: New rsync completely breaks systemimager-server
On Tue 10 May 2005, Roberto C. Sanchez wrote: > Paul Slootman wrote: > > > > I'm guessing this is related to #307923. Please add a line > > log file = /var/log/rsyncd.log > > to the top of /etc/rsyncd.conf, and try it again. At least, I'm assuming > > you're using an rsync daemon; you give very little information on how > > rsync is being used. > > > Sorry. Here is my command line: > > client: /usr/sbin/prepareclient --server 192.168.2.1 -yes > > server: /usr/sbin/getimage -ssh-user sanchezr -ip-assignment replicant > -golden-client santiago -image santiago Hmm, I'll have to dig into that package to see what rsync commands this will result in. > > If that fixes it, please let me know ASAP so I can upload a fix for your > > problem. > Unfortunately, that did not fix it. Do I also need to create the log > file with specific permissions? If it's in a place that's not writable, yes. You could also let it log to /tmp/something . Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#308428: New rsync completely breaks systemimager-server
On Tue 10 May 2005, Roberto C. Sanchez wrote: > Package: rsync > Version: 2.6.4-5 > Severity: critical > > I am filing this bug as critical for 2 reasons: 1) the package in > question breaks the systemimager-server package and 2) it causes > data loss (in my case, a nightly backup scheduled by cron failed to > complete). A failed backup doesn't imply data loss... that would also imply I'm losing data whenever I skip making a backup :) > The new rsync package causes the systemimager 'getimage' command to > fail with this error: > > rsync: connection unexpectedly closed (0 bytes received so far) [receiver] > rsync error: error in rsync protocol data stream (code 12) at io.c(420) > the recommended version of rsync. > Failed to retrieve /etc/systemimager/mounted_filesystems from 127.0.0.1. > getimage: Have you run "prepareclient" on 127.0.0.1? > If you see the message "unrecognised option" above, check > http://systemimager.org/download/ to be sure that you are running > > Reverting to 2.6.4-2 causes normal behavior to resume. I'm guessing this is related to #307923. Please add a line log file = /var/log/rsyncd.log to the top of /etc/rsyncd.conf, and try it again. At least, I'm assuming you're using an rsync daemon; you give very little information on how rsync is being used. If that fixes it, please let me know ASAP so I can upload a fix for your problem. Thanks, Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306981: rsync: Patch for 306981
On Wed 04 May 2005, Jaume wrote: > > I have looked at the bug you opened in rsync's bugzilla, > https://bugzilla.samba.org/show_bug.cgi?id=2675 > and I have made a little investigation myself, which might help you in > this issue. Thanks for your effort, but I already have this fix; I am waiting for instructions on how to proceed in the light of sarge having been frozen yesterday. > (it works: "a" is transferred from "server" to "client", and "b" is > deleted from client with a backup) Your effort is much appreciated! very thorough work. Unfortunately a bit of wasted time as it happens, but thanks anyway. Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#295060: wwwoffle: installing 2.8e-2 still overwrites config
On Wed 04 May 2005, Paolo wrote:
>
> this bug was closed, but upon upgrading 2.7a to 2.8e (pkg 2.8e-2) got:
>
> --- /etc/wwwoffle/wwwoffle.conf.2.7a2005-05-04 15:20:06.0 +0200
> +++ /etc/wwwoffle/wwwoffle.conf.2.8 2005-05-04 15:22:06.0 +0200
> @@ -1,11 +1,11 @@
> StartUp
> {
> bind-ipv4 = 127.0.0.1
> - http-port = 5866
> + http-port = 8080
> wwwoffle-port = 5867
> - spool-dir = /var/tmp
> - run-uid = nobody
> - run-gid = nogroup
> + spool-dir = /var/cache/wwwoffle
> + run-uid = proxy
> + run-gid = proxy
> use-syslog= no
> password = yoursecret
> max-servers = 3
> @@ -23,6 +23,9 @@
>
> without a clue that it has changed my settings, so seems that 2.8e-2 still
> doesn't really fix this issue.
I'll have to have a look at this; it should have preserved the
http-port.
However, running with a uid an gid other than proxy is not supported.
Also the spool-dir shouldn't really be changed, especially to /var/tmp
as it it unpredictable what may happen if all sorts of non-wwwoffle
files are encountered in its cache area. Use a symlink (to a subdir) if
you really have to...
Can you please send me /var/log/wwwoffle-upgrade.log, and
/etc/wwwoffle/wwwoffle.conf and /etc/wwwoffle/wwwoffle.conf.bak (i.e.
the config file before the upgrade). Please also show the output of
debconf-show wwwoffle
I'll try to reproduce it then.
Thanks,
Paul Slootman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306981: rsync -b --sufix does not keep a copy of deleted files
On Fri 29 Apr 2005, Jaume Guasch wrote:
>
> With (old) rsync 2.6.3-2 I used the following options to syncronize
> different computers:
>
> DATA=`date '+%Y-%m-%d'`
> RSYNCGET="rsync -abxHzu --progress -v --suffix=.~${DATA} --exclude="*.a"
> --exclude="*.o" --exclude="*~*" --exclude="*.exe" --exclude=".nfs*"
> --exclude="msg.*" --exclude="lock" --exclude="*\#" --exclude=".\#*"
> --exclude="Backup" --exclude="pine-bin.linux" --delete --delete-after -e
> ssh "
Is this the exact line from the script? This looks suspicious, as the
command is enclosed in double quotes, but the command also uses
unescaped double quotes which hence will not be put into the variable
$RSYNCGET.
> ${RSYNCGET} server:dir dir
This becomes:
rsync -abxHzu --progress -v --suffix=.~2005-05-02 --exclude=*.a --exclude=*.o
--exclude=*~* --exclude=*.exe --exclude=.nfs* --exclude=msg.* --exclude=lock
--exclude=*# --exclude=.#* --exclude=Backup --exclude=pine-bin.linux --delete
--delete-after -e ssh server:dir dir
You're probably lucky that because of the --suffix= prefix, the * won't
be expanded (as it doesn't match anything).
Note also that "-e ssh" is redundant.
> This makes a full copy, and leaves a backup copy of every changed and
> deleted file in the client, with a name which contains the date
> of the transfer.
>
> Since I installed 2.6.4, the same command does not perform the
> same:
>
> If a file is deleted in the server, it will be deleted in the client,
> WITHOUT leaving a backup copy.
>
> Expected behaviour: a backup copy should be left in the client
I've confirmed this, and have filed a bug against the upstream source.
Upstream is usually very quick with fixes for these matters. I'll upload
a fixed version as soon as the fix is available.
Paul Slootman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306368: filter rules are too modern for remote rsync (which is 2.5.6)
forwarded 306368 rsync@lists.samba.org severity 306368 important thanks On Tue 26 Apr 2005, Alexey Feldgendler wrote: > Package: rsync > Version: 2.6.4-2 > Severity: grave > Justification: renders package unusable I've downgraded the severity to important, as the package isn't unusable; I use it to backup 100 servers (1 TB) every day... "a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone." sounds more apropriate. I've forwarded the message to the mailing list, the upstream author is in the best position to answer this issue. Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#295060: wwwoffle: patch for part of this bug
On Tue 05 Apr 2005, Frank Küster wrote:
> Paul Slootman <[EMAIL PROTECTED]> wrote:
>
> > On Tue 05 Apr 2005, Frank Küster wrote:
> >> David Schmitt <[EMAIL PROTECTED]> wrote:
> >>
> >> I am looking into this, trying to provide a patch - and NMU if Paul
> >> doesn't show up, I really think wwwoffle should go back into sarge.
> >
> > I'm a bit busy with all sorts of things (e.g. new upstream rsync this
> > weekend)... I hadn't really delved into this report yet because it
> > doesn't go wrong for me, actually...
>
> It is easily reproducibly, and it is release critical. We should really
> try to fix this and get wwwoffle back into sarge (you didn't miss that
> it was removed, did you?).
I did actually. I would have expected an email, or at least a message to
d-devel-announce with a list of removed packages. That sucks.
Thanks for bringing it to my attention!
> >> missing. I would not take "preserve user modifications" too literally
> >> here; in fact I doubt that these files are really configuration files -
> >> who would want to configure a 1x1 pixel png file?
> >
> > Many people.
> > In fact, I once replaced it with a debian banner, and it took a while
> > before people realized it was a replacement image, and not in fact a
> > proliferation of debian propaganda.
>
> Where do these images show up? If you think that many people do
You list sites that are not be be accessed; the default action (for
images, e.g. banners from doubleclick.net) is to replace the image that
should have been fetched with the transparent 1x1 image. By putting your
own banner there, you don't have unexpected white areas.
> >> > The following code is AFAICS not conditional upon first installation,
> >> > thus
> >> > overriding a local admin who has intentionally removed the link.
> >> >
> >> > Line 257:
> >> > |perl -i.bak -pe 's/^(\# WWWOFFLE - World Wide Web Offline Explorer
> >> > - Version).*/$1'" $config_version/" $CONFIG
> >> > |if cmp -s $CONFIG $CONFIG.bak; then mv -f $CONFIG.bak $CONFIG; fi
> >> >
> >> > If the perl doesn't modify the config, this will kill the symlink:
> >
> > Will it? AFAIK perl -i.bak will MOVE the original file to .bak; moving
> > it back will hence preserve the symlink.
>
> If the files are equal (if is true), then the symlink, the bak file,
> will be moved back again. But if wwwoffle.conf has been changed, then
> it will be an ordinary file, and the symlink is the bak file which isn't
> used.
Yes, as I just wrote to David, that's not what the text said:
> >> > If the perl doesn't modify the config, this will kill the symlink:
> > Replacing the wwwoffle.conf with a symlink would seem pretty silly
> > anyway, and I wonder as to what extent such actions need to be
> > supported.
>
> I do it, and I do it with many files. Obviously others have noted this,
> too.
Please enlighten me, why? What are the advantanges?
> >> > Line 354:
> >> > | if [ ! -f $OPTIONS ]; then
> >> > |cp -p /usr/share/wwwoffle/default/wwwoffle.options $OPTIONS
> >> > | fi
> >> >
> >> > This too is not special cased to the not-upgrading case.
> >
> > So what?
>
> If the local admin has removed the file, the maintainer scripts have to
> respect this and keep it removed - just as dpkg does it. See the
> policy.
See my other message to David.
> >> > Line 368 and 372:
> >> > | perl -i -e 'while (<>) { next if /htdig/; print; }' $OPTIONS
> >> >
> >> > This skips _all_ lines containing 'htdig' including comments
> >
> > Where does it say it's safe to use comments in that file? See man
> > wwwoffle.options
>
> The manpage only says that comments can be used to comment out ppp.
> Since it even doesn't say what is the comment sign, one should safely be
> able to assume that it has a standard behaviour. And this would include
> to be able to add textual comments.
OK...
However, not related to the RC bug. I suggest that an NMU to fix an RC
bug should not also change all sorts of other things.
(Ah, I see your comment later on)
> >> - the directories in /etc/wwwoffle/html should be shipped in the deb
> >>
> >> - all those symlinks are in fact not configuration "files". Of course
> >> it alters the behaviour of the package if RefreshFormError.html points
> >> to something else than the file shipped i
Bug#295060: wwwoffle: patch for part of this bug
On Tue 05 Apr 2005, David Schmitt wrote:
> On Tuesday 05 April 2005 19:21, Paul Slootman wrote:
> > On Tue 05 Apr 2005, Frank Küster wrote:
> > > David Schmitt <[EMAIL PROTECTED]> wrote:
> > > > The following code is AFAICS not conditional upon first installation,
> > > > thus overriding a local admin who has intentionally removed the link.
> > > >
> > > > Line 257:
> > > > |perl -i.bak -pe 's/^(\# WWWOFFLE - World Wide Web Offline Explorer
> > > > | - Version).*/$1'" $config_version/" $CONFIG if cmp -s $CONFIG
> > > > | $CONFIG.bak; then mv -f $CONFIG.bak $CONFIG; fi
> > > >
> > > > If the perl doesn't modify the config, this will kill the symlink:
> >
> > Will it? AFAIK perl -i.bak will MOVE the original file to .bak; moving
> > it back will hence preserve the symlink.
>
> The code doesn't move the symlink back if it has changed the file.
That wasn't the comment. The comment was:
> > > > If the perl doesn't modify the config, this will kill the symlink:
That was clearly wrong. That indicates to me a bad understanding of the
workings of the code. I don't like people touching code they don't
understand well.
> > Replacing the wwwoffle.conf with a symlink would seem pretty silly
> > anyway, and I wonder as to what extent such actions need to be
> > supported. Would you expect things to remain working if you replaced
> > /etc/passwd with a symlink?
>
> Yes.
Well, I wouldn't like to try it. I also think any sane admin wouldn't.
> > > > Line 354:
> > > > | if [ ! -f $OPTIONS ]; then
> > > > |cp -p /usr/share/wwwoffle/default/wwwoffle.options $OPTIONS
> > > > | fi
> > > >
> > > > This too is not special cased to the not-upgrading case.
> >
> > So what?
>
> http://www.debian.org/doc/debian-policy/ch-files.html#s10.7.3 says:
>
> "local changes must be preserved during a package upgrade"
>
> I was under the impression, that this includes the removal of said
> configuration files. See e.g.
> http://lists.debian.org/debian-user/2003/08/msg01816.html
>
> "Are they configuration files (to a first approximation, "files in
> /etc")? If so, dpkg considers deleting the file as a valid
> configuration option, and will preserve this across upgrades."
That discusses conffiles, as managed by dpkg, not files that happen to
be in /etc; this is a case of a "maintainer scripts maintained" file. I
can't find any clear text that also here removal should be preserved.
I find this a case of " If the existence of a file is required for the
package to be sensibly configured it is the responsibility of the
package maintainer to provide maintainer scripts which correctly create,
update and maintain the file and remove it on purge." as mentioned in
http://www.debian.org/doc/debian-policy/ch-files.html#s10.7.3
> Thus I believe creating $OPTIONS on upgrade does not preserve local changes
> and therefore is RC.
I disagree.
>
> > > > Line 368 and 372:
> > > > | perl -i -e 'while (<>) { next if /htdig/; print; }' $OPTIONS
> > > >
> > > > This skips _all_ lines containing 'htdig' including comments
> >
> > Where does it say it's safe to use comments in that file? See man
> > wwwoffle.options
>
> Then the shipped default is incorrect:
It's OK to use comments, there's just no guarantee that they'll stay
intact :-)
> > > > Line 402:
> > > > |if [ "$FREQ" != off ]; then
> > > > |# convert to digits only
> > > > |FREQ=$( expr "$FREQ" : '\([0-9]*\)' )
> > > >
> > > > In the .config, there is already complex code to clean this value and
> > > > (without obvious cause) to cap it to 30 minutes. Also this would
> > > > silently eat input errors.
> >
> > The fact that you don't see the cause for the capping to 30 minutes
> > means that you don't understand how it works. If you don't understand
> > how it works, pleasepleaseplease don't touch the code!
>
> Neither have I claimed that understand the code nor have I touched it.
So why bring it up?
> > > > Line 448:
> > > > | # now duplicate directory structure of /usr/share/wwwoffle/html to
> > > > | /etc/wwwoffle/html
> > > >
> > > > Followed by approximatly 20 lines of shell code which probably amount
> > > > to a 'cp -s' which I _think_
Bug#295060: wwwoffle: patch for part of this bug
s done this way, so that individual files could be replaced at will. It works, so why mess with it? What has this to do with this bug report?! > I do not think it is something for an NMU to clean this up, which would > amount to a very big change. And I think if the maintainer script do Exactly > not respect local changes for something that shouldn't be a > configuration file at all, it is not release-critical. > > > Line 516, ff: > > |rm -f nohup.out > > |nohup chown -R proxy:proxy /var/cache/wwwoffle/. /var/lib/wwwoffle/. > > >/dev/null 2>&1 & > > |sleep 1 > > |rm -f nohup.out > > > > This deletes nohup.out in the current directory, which could be not from > > wwwoffle, which could also be created in $HOME, but is not created by nohup > > anyway because of the redirection. You missed the "cd /var/cache/wwwoffle/temp" 1 line higher... > I'll just remove the nohup.out removals. Why? Again, what has this to do with this bug report? Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#295060: wwwoffle: patch for part of this bug
On Tue 05 Apr 2005, Frank Küster wrote: > > In the elif line, this must be $USE_PPP, of course. Good one. This looks like it may be _the_ bug... Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
