Bug#683312: Please consider including this patch before wheezy
On 14 January 2013 19:04, gregor herrmann wrote: > I think I found another one ... > > What I did was switching the (-)-$args and $nots with perl, and > comparing the result with your patch there's one difference: > > #v+ > -+ push (@source, "$not -s $1 -m mac --mac-source $not $2"); > ++ push (@source, "$not -s $1 -m mac $not --mac-source $2"); > #v- > > I'm attaching my complete (auto-)patch; could you please double-check? > Hello Gregor, I have used grep and wc -l and looked and re-looked... your patch looks complete to me. Thanks for looking at this issue and fixing my mistakes! Alex Owen -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683312: Please consider including this patch before wheezy
On 14 January 2013 17:54, gregor herrmann wrote: > On Sun, 13 Jan 2013 19:10:00 +0000, Alex Owen wrote: > >> I have regenerated the patch against uif- 1.0.6 to make it simple to >> review and apply to the package currently in Wheezy. > > Seems you didn't attach this new patch? Oops! Sorry! > > BTW: After looking at your original patch, I have the impression that > you missed "moving" one $not (dport, in the line with two "$not"s). > Good catch... Here (and really attached this time) is an updated patch including Gregor's point also. Regards Alex Owen uif-pling-position-v2.patch Description: Binary data
Bug#687830: ceph/0.48-1 is not migrating to testing
Source: ceph Version: 0.48-1 Severity: Grave Due to some kind of package metadata (ie debian/control) or build failure (FTBFS) it appears that ceph has been stuck in sid and not migrated to testing for 63 days. This makes the package unusable for wheezy hence marking as severity grave. If this is an error please feel free to correct and educate me! I should also note that ceph 0.48-1 is the first upstream version with long term support and thus would (apparently) be much more appropriate to be released in wheezy that previous versions of ceph. Regards Alex Owen -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#417407: debian-installer: possible workarounds for "d-i destroyed existing raid device"
Cut and paste from BTS web interface so sorry for the formatting! From: Samuel Thibault <[EMAIL PROTECTED]> Subject: Re: Bug#417407: debian-installer: d-i destroyed existing raid device Date: Tue, 3 Apr 2007 19:26:25 +0200 Hi, martin f krafft, le Tue 03 Apr 2007 10:28:24 +0200, a écrit : And the other question of course is why the kernel decided it had any business doing recovery on an fs that was marked for ro mount. Because it always do so, see linux/fs/ext3/super.c:ext3_load_journal(): even if the mount is read-only, the journal is recovered. If (but only if) the device itself is read-only, then nothing is written back to the disk. Ext3 clearly lacks xfs' norecovery mount option. I can think of two possible workarounds for this. NB: I have not looked at the code but I'm just thinking out loud. [1] at the partitioner stage configure md devices... IIRC this should recognize the preexisting device. Then mark the device to be mounted at /home (or /oldhome for the ultra paranoid) and markit to be left alone (ie not formatted). _Presumably_ os-prober would then ignore the md device and it's components when looking for other OS's. [2] wrap the mount/umount sections of code in os-prober with calls to blockdev to set the block device readonly (and restore old perms on umount). This would side step the deficiencies in the "unconditional ext3 journal recovery code". (but this would need a block-dev udeb added to util-linux source) Just some thoughts... Alex Owen
Bug#411787: please test patch
If people test the patch and repost sucsess or failure here that may help a decision for including the patch or not! Alex Owen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403703: remove tags from #403703
Package cupsys Tags 403703 - fixed-upstream Tags 403703 - patch Tags 403703 - upstream thanks I don't think any of the tags apply to this bug in it's reopened form! Regards Alex Owen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403703: quick look
I still have my test setup from December where I ran test.sh (BTS Dec 21).
in test.sh when I run $HOME/cups/cupsys-1.2.7/filter/pstops I am
running pstops from 1.2.7-1 patched ONLY with str2111.patch
I have upgraded my system so that 1.2.7-2 is now installed.
rerunning the tests I should expect the output files
patch-reverse.ps reverse.ps to be the same (as the pstops from
1.2.7-2 which generates reverse.ps claims to have str2111.patch
applied).
However the files are _different_
The new debian version seems to forget to emmit the prolog. See this diff.
diff -u patch-reverse.ps reverse.ps
---8<---
--- patch-reverse.ps2007-01-18 08:59:42.0 +
+++ reverse.ps 2007-01-18 08:59:42.0 +
@@ -1,55 +1,6 @@
%!PS-Adobe-3.0
-%%HiResBoundingBox: 57.60 771.60 93.40 783.00
-%.
-%%Creator: Alex Owen with emacs and ghostscript
-%%CreationDate: 2006/12/21
-%%DocumentData: Clean7Bit
-%%LanguageLevel: 2
%%For: (dj)
%%Title: ()
-%RBINumCopies: 1
-%%Pages: (atend)
-%%BoundingBox: (atend)
-%%EndComments
-%%BeginProlog
-%%EndProlog
-%%BeginSetup
-% Disable CTRL-D as an end-of-file marker...
-userdict dup(\004)cvn{}put (\004\004)cvn{}put
-[{
-%%BeginFeature: *PageSize Letter
-<>setpagedevice
-%%EndFeature
-} stopped cleartomark
-[{
-%%BeginFeature: *PreFilter No
-%% FoomaticRIPOptionSetting: PreFilter=No
-%%EndFeature
-} stopped cleartomark
-[{
-%%BeginFeature: *Resolution default
-%% FoomaticRIPOptionSetting: Resolution=default
-%%EndFeature
-} stopped cleartomark
-[{
-%%BeginFeature: *Duplex None
-%% FoomaticRIPOptionSetting: Duplex=None
-%%EndFeature
-} stopped cleartomark
-% x y w h ESPrc - Clip to a rectangle.
-userdict/ESPrc/rectclip where{pop/rectclip load}
-{{newpath 4 2 roll moveto 1 index 0 rlineto 0 exch rlineto
-neg 0 rlineto closepath clip newpath}bind}ifelse put
-% x y w h ESPrf - Fill a rectangle.
-userdict/ESPrf/rectfill where{pop/rectfill load}
-{{gsave newpath 4 2 roll moveto 1 index 0 rlineto 0 exch rlineto
-neg 0 rlineto closepath fill grestore}bind}ifelse put
-% x y w h ESPrs - Stroke a rectangle.
-userdict/ESPrs/rectstroke where{pop/rectstroke load}
-{{gsave newpath 4 2 roll moveto 1 index 0 rlineto 0 exch rlineto
-neg 0 rlineto closepath stroke grestore}bind}ifelse put
-userdict/ESPwl{}bind put
-%%EndSetup
%%Page: 3 1
%%PageBoundingBox: 0 593 0 767
%%BeginPageSetup
---8<---
Seems like there is bad interaction between the patches applied
between the 1.2.7-1 and 1.2.7-2 release...
Alex Owen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#378382: Puppetmaster works in testing (someone want to check?)
package puppetmaster
clone 378382 -1
close 378382 0.20.1-1
severity -1 normal
retitle -1 puppetmaster daemon should fail to start if PID file cannot
be properly written
notfound -1 0.18.2-1
found -1 0.20.1-1
thanks
On 07/01/07, Paul TBBle Hampson <[EMAIL PROTECTED]> wrote:
Alex, try adding
File.open(@pidfile + ".%d" % $$, "w") { |f| f.puts $$ }
...
Thanks for your help.
It seemed my problem was user error... /var was full. The root user
could still set pid files as I have 5% reserved for root on /var but
the puppet user could not write the contents of the puppetmaster pid
file it would seem.
In summary my testing shows that if there is space available in
/var/run then the current (0.20.1-1) init script works. Paul Hampson's
statement:
I just tried the same procedure Alex R. Owen tried, on
an unstable powerpc box, and the PID file was created
fine, and had a PID in it, and puppetmaster stopped when
the init.d script told it to.
Seems to confirm that the init scripts in version 0.20.1-1 work. I am
therfore closing this bug as fixed in 0.20.1-1. However I am also
going to clone this bug at the severity normal as
pupetmasterd should fail to start if it cannot write it's PID file
(for example in the case when /var if full !!!)
I hope you all agree.
Regards
Alex Owen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#378382: Puppetmaster init script is still broken
Puppet is now at version 0.20.1-1
Reading this bug report and the debian/changelog it seems the init
script was overhauled in the last upload (0.20.1-1) however it still
doe not work!
I do not use puppet but have installed puppetmaster on a "clean"
machine and touched
/etc/puppet/manifests/site.pp so that puppetmasterd starts!
I can now start the daemon with
sudo /etc/init.d/puppetmaster start
and a pid file is created BUT the pid file is EMPTY!
# ls -l /var/run/puppetmasterd.pid
-rw-r--r-- 1 puppet puppet 0 2007-01-06 17:08 /var/run/puppetmasterd.pid
So it is no wonder that the daemon is not stopped!
Further test show that by running /usr/sbin/puppetmasterd the pid file
is created (but empty)
and that killing the process removes the pid file.
I think the bug lies in the ruby code which creates an EMPTY pid
file... it should put the pid in it!
I do not read or write ruby... but I think the problem lies in
function setpidfile in the file puppet-0.20.1/lib/puppet/daemon.rb
The code looks like:
---
def setpidfile
return unless Puppet[:setpidfile]
threadlock(:pidfile) do
Puppet.config.use(:puppet)
@pidfile = self.pidfile
if FileTest.exists?(@pidfile)
if defined? $setpidfile
return
else
raise Puppet::Error, "A PID file already
exists for #{Puppet.name}
at [EMAIL PROTECTED] Not starting."
end
end
Puppet.info "Creating PID file to %s" % @pidfile
begin
File.open(@pidfile, "w") { |f| f.puts $$ }
rescue => detail
Puppet.err "Could not create PID file: %s" % detail
exit(74)
end
$setpidfile = true
end
end
---
BUT I don't see the file being closed or sync'd to disk. My suspision
is that ruby needs another command/method to be called to commit this
write to disk. Any ruby experts out there want to comment?
Regards
Alex Owen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#388037: Opps... problem with fix for #388037
package stun found 388037 0.96.dfsg-3 severity important thanks Hello, I'm afraid my patch to fix 388037 was broken... It does fix the installing and removal/puging on a clean system BUT the stanza: --- if [ "$START_DAEMON" != "true" ] ; then exit 0 fi --- in /etc/init.d/stun comes BEFORE --- if [ -f /etc/default/stun ] ; then . /etc/default/stun fi --- So that configuring the variable START_DAEMON to be true in /etc/default/stun will haveNO EFFECT as the init-script will already have exited... Opps! Sorry about that. One more upload for etch? I have reduced bug severity to important but this might be another error on my part ? Sorry! Alex Owen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#397074: [PATCH] new patch which fixes upgrade problem from existin broken package
The last package is broken in such a way that installing in on a fresh system gets the package into a state wher eit cannot install or be removed... This patch lets you _upgrade_ to this version then everything is fixed and works! I am not a DD so cannot NMU this. I have only tested installing and removing and upgrading the package on a "clean" system. I have not checked the functioanlity of the daemon as I don't use it... some one should check that! Regards Alex Owen diff -uNr stun-0.96.dfsg.old/debian/init.d stun-0.96.dfsg/debian/init.d --- stun-0.96.dfsg.old/debian/init.d 2007-01-03 19:08:26.0 + +++ stun-0.96.dfsg/debian/init.d 2007-01-03 18:49:04.0 + @@ -14,9 +14,14 @@ DAEMON=/usr/sbin/stund NAME=stun DESC=stun +START_DAEMON=false test -x $DAEMON || exit 0 +if [ "$START_DAEMON" != "true" ] ; then + exit 0 +fi + # Include stun defaults if available if [ -f /etc/default/stun ] ; then . /etc/default/stun diff -uNr stun-0.96.dfsg.old/debian/README.Debian stun-0.96.dfsg/debian/README.Debian --- stun-0.96.dfsg.old/debian/README.Debian 2007-01-03 19:08:26.0 + +++ stun-0.96.dfsg/debian/README.Debian 2007-01-03 18:49:04.0 + @@ -1,5 +1,9 @@ stund for Debian +The stund daemon is not started by default. +To get the daemon to start edit /etc/default/stun and uncomment the +START_DAEMON=true line + A list of publicly available STUN test servers is available at: http://www.voip-info.org/wiki/view/STUN diff -uNr stun-0.96.dfsg.old/debian/stun.default stun-0.96.dfsg/debian/stun.default --- stun-0.96.dfsg.old/debian/stun.default 2007-01-03 19:08:26.0 + +++ stun-0.96.dfsg/debian/stun.default 2007-01-03 18:49:04.0 + @@ -6,6 +6,9 @@ # This is a POSIX shell fragment # +#uncommment the next line to allow the init.d script to start the stun daemon +#START_DAEMON=true + # Additional options that are passed to the Daemon. DAEMON_OPTS="" diff -uNr stun-0.96.dfsg.old/debian/stun.prerm stun-0.96.dfsg/debian/stun.prerm --- stun-0.96.dfsg.old/debian/stun.prerm 1970-01-01 01:00:00.0 +0100 +++ stun-0.96.dfsg/debian/stun.prerm 2007-01-03 19:05:52.0 + @@ -0,0 +1,10 @@ +#!/bin/sh +set -e + +if [ -x "/etc/init.d/stun" ]; then + if [ -x "`which invoke-rc.d 2>/dev/null`" ]; then + invoke-rc.d stun stop || exit 0 + else + /etc/init.d/stun stop || exit 0 + fi +fi
Bug#404970: qemu for amd64 test bed
Hello, Could qemu be used to emulate a 64bit system for debuging this problem? Regards Alex Owen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#397074: [Patch] add start daemon option to stun init.d script
On 01/01/07, Alex Owen <[EMAIL PROTECTED]> wrote: Please report any tests to this bug report. I have tested this patch and the package builds and installs and purges correctly with the patch applied... further more the daemon is not started by default. This is the extent of my testing, someone who uses this should test that uncommenting the line in /etc/default/stun allows the daemon to start. Regards Alex Owen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#397074: [Patch] add start daemon option to stun init.d script
forcemerge 397074 388037 thanks Attached is a patch to stop the start of stund by default and add a START_DEMON option to /etc/default/stun The patch applies to the debian source and is untested. Please report any tests to this bug report. Regards Alex Owen diff -uNr stun-0.96.dfsg.old/debian/init.d stun-0.96.dfsg/debian/init.d --- stun-0.96.dfsg.old/debian/init.d 2007-01-01 23:16:24.0 + +++ stun-0.96.dfsg/debian/init.d 2007-01-01 23:15:42.0 + @@ -14,9 +14,14 @@ DAEMON=/usr/sbin/stund NAME=stun DESC=stun +START_DAEMON=false test -x $DAEMON || exit 0 +if [ "$START_DAEMON" != "true" ] ; then + exit 0 +fi + # Include stun defaults if available if [ -f /etc/default/stun ] ; then . /etc/default/stun diff -uNr stun-0.96.dfsg.old/debian/README.Debian stun-0.96.dfsg/debian/README.Debian --- stun-0.96.dfsg.old/debian/README.Debian 2007-01-01 23:16:24.0 + +++ stun-0.96.dfsg/debian/README.Debian 2007-01-01 23:15:23.0 + @@ -1,5 +1,9 @@ stund for Debian +The stund daemon is not started by default. +To get the daemon to start edit /etc/default/stun and uncomment the +START_DAEMON=true line + A list of publicly available STUN test servers is available at: http://www.voip-info.org/wiki/view/STUN diff -uNr stun-0.96.dfsg.old/debian/stun.default stun-0.96.dfsg/debian/stun.default --- stun-0.96.dfsg.old/debian/stun.default 2007-01-01 23:16:24.0 + +++ stun-0.96.dfsg/debian/stun.default 2007-01-01 23:11:38.0 + @@ -6,6 +6,9 @@ # This is a POSIX shell fragment # +#uncommment the next line to allow the init.d script to start the stun daemon +#START_DAEMON=true + # Additional options that are passed to the Daemon. DAEMON_OPTS=""
Bug#403703: Fix confirmed?
Hello, I have done some test running pstops against the current packaed version and a version patched with str2111.patch. I tested with the attached 3 page ps file "test.ps" and ran the attached script "test.sh" My diffs or the resultinf ps files show that no JCL/PJL whatever it is is genereted... However the patched pstops doe not add < %%EOF$ < ^D%!PS-Adobe-3.0$ < %%Pages: (atend)$ < %%BoundingBox: (atend)$ < %%EndComments$ but the unpatched version does... In summary I think that the patch str2111.patch does work and should be added to the debian source. Patrice, please update this bug if it still does not work for you. With the patch I cannot recreate your original problem. Regards Alex Owen test.ps Description: PostScript document test.sh Description: Bourne shell script
Bug#402179: [Bug-tar] Race condition in GNU tar test-suite
tags 402179 + patch upstream fixed-upstream thanks Attached is the diff for tests/append02 between upstream released versions 1.16 and 1.16.1. This patch should fix the problem. I guess the opotions are to aply this patch to 1.16 or package 1.16.1. I guess applying the patch is the better option if we wnat to fix this for etch. The only testing of this patch I have done is by runing the following... probably someone else should confirm the fix! This script should prove the point runing essentially the same code stand alone... based on the eariler stand alone code in this bug report ---8<--- #!/bin/sh # Make sure file timestamps in the archive will not differ MTIME="[EMAIL PROTECTED]" export TAR_OPTIONS="-H posix --pax-option=exthdr.name=%d/PaxHeaders/%f,delete=mtime,delete=atime,delete=ctime" echo hello > file1 echo goodbye > file2 while :; do tar $MTIME -cf archive.1 file1 file2 tar $MTIME -cf archive.2 -T /dev/null tar $MTIME -rf archive.2 file1 tar $MTIME -rf archive.2 file2 if cmp archive.1 archive.2 >/dev/null; then echo -n . else echo -n + fi done ---8<--- Regards Alex Owen --- tar-1.16/tests/append02.at 2006-07-24 10:09:30.0 +0100 +++ tar-1.16.1/tests/append02.at 2006-11-13 09:17:46.0 + @@ -44,19 +44,22 @@ genfile --file file1 genfile --file file2 +# Make sure file timestamps in the archive will not differ +MTIME="[EMAIL PROTECTED]" + # For PAX archives, we need to make sure extended header names are -# reproducible. +# reproducible and that their contents won't change with time if test $[]TEST_TAR_FORMAT = posix; then - TAR_OPTIONS="$TAR_OPTIONS --pax-option=exthdr.name=%d/PaxHeaders/%f" + TAR_OPTIONS="$TAR_OPTIONS --pax-option=exthdr.name=%d/PaxHeaders/%f,delete=mtime,delete=atime,delete=ctime" fi echo Creating archive.1 -tar cf archive.1 file1 file2 +tar $MTIME -cf archive.1 file1 file2 echo Creating archive.2 -tar cfT archive.2 /dev/null -tar rf archive.2 file1 -tar rf archive.2 file2 +tar $MTIME -cf archive.2 -T /dev/null +tar $MTIME -rf archive.2 file1 +tar $MTIME -rf archive.2 file2 echo Comparing archives cmp archive.1 archive.2
Bug#403703: fixed upstream?
tags 403703 + upstream fixed-upstream patch thanks Loooking again at upstream bug STR #2166 the developers think this is a duplicate of upstream bug STR #2111: http://www.cups.org/str.php?L2111 STR #2111 has been fixed upstream... patch can be found here: http://www.cups.org/strfiles/2111/str2111.patch Regards Alex Owen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403706: network not up after /etc/rcS.d/S40networking completes
reassign 403706 netcfg thanks This bug/issue seems to be due (in part) to the code in d-i/trunk/packages/netcfg/[static.c|dhcp.c] ---8<--- if (!iface_is_hotpluggable(iface) && !find_in_stab(iface)) fprintf(fp, "auto %s\n", iface); else fprintf(fp, "allow-hotplug %s\n", iface); ---8<--- It seems that the kernel now sees everything (or almost everything) as hotplugable. Thus my builting network card on my server is now "hotplugable" which means that is is initiallised asyncronosly at bootup. The old behavious was to have the "auto eth0" stanza in /etc/network/interfaces... then I knew that I would have a network (or an error message) at the end of /etc/rcS.d/S40networking on boot. Now I may or may not have a network when /etc/rcS.d/S40networking finishes... This is a serious issue! It may be that I'm just ignorant... in that case can someone please point me to the correct docs so I may educate myself! If i'm not being ignorant then we either: [1] have to modify the netcfg code to ask at install time if we want to have an "auto" rather than "hotplug" primary interface and act accordingly, or [2] we need to add some code to /etc/rcS.d/S40networking (/etc/init.d/networking) to wait till the primary interface has come online. Regards Alex Owen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403706: Probably a d-i issue
This is probably a debian-installer issue? but is affects udev/hotplug/initscripts also! Regards Alex Owen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403703: Already being tracked upstream?
It seems that a suprisingly simmilar report is being tracked upstream STR #2166 at: http://www.cups.org/str.php?L2166 Regards Alex Owen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#402179: Race condition in GNU tar test-suite
The Debian Project seems to have found a bug in the tar test suite. The bug appears to be a race condition in tests/append02.at I could not find mention of the bug in the bug-tar archives at: http://lists.gnu.org/archive/html/bug-tar/ so I'm reporting it now! This patch makes the race loose consistently and the test will fail consistently. ---8<--- --- tests/append02.at.orig 2006-07-24 10:09:30.0 +0100 +++ tests/append02.at 2006-12-19 10:49:07.0 + @@ -53,6 +53,8 @@ echo Creating archive.1 tar cf archive.1 file1 file2 +sleep 2 + echo Creating archive.2 tar cfT archive.2 /dev/null tar rf archive.2 file1 ---8<--- A full analisys by those more insightful than me is available at: http://bugs.debian.org/402179 I suspect that the Debian Project will just disable the test for the time being but I guess you GNU tar folks will want to fix the test! Regards Alex Owen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#402331: Agree with Steve Langasek's analysis.
As others have said there is no need to compile the source when building a "source as binary" package. Hence there is no need to have depandancies on specific users when building the qmail-src deb from the qmail source deb. There are two ways of solving this... [1] the same way as pine by only having a source deb in the archive. (The difference here is that we would need to build depend on a trivial package which adds the required users in it's postinst) [2] (and more like the package presently tries) the same way as kernel module packages. Here we tar up a debianised source tree into a binary deb with a postinst that adds the required users. For insperation look at some kernel module source packages... eg: qla2x00 from sarge. From memory a different debian/rules is copied into the debianised source tree which ends up in the "binary" than exists in the "source". Currently the issue seems to be that the qmail source deb really wants to build the qmail deb directly and the qmail-src debv seems to have been hacked in to debian/rules. It also seems that the SAME debian/rules is used BOTH the qmail-src deb and the qmail deb. This is in my opinion asking for trouble. See earlier comment about looking a kernel-module source packages for insparation. I hope this analysis helps!?! Alex Owen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#400215: solution....
tags 400215 + patch thanks Attached is a patch that should fix this... [untested I'm afraid]. On 13/12/06, Alex Owen <[EMAIL PROTECTED]> wrote: From memory of other udev rule installing pkgs the file is installed into "/etc/udev/nut-usbups.rules" and the symlink is made in "/etc/udev/rules.d" Regards Alex Owen --- debian/rules.rao.orig 2006-12-13 09:16:11.0 + +++ debian/rules 2006-12-13 09:19:10.0 + @@ -91,7 +91,7 @@ DESTDIR=$(CURDIR)/debian/nut-usb RUNUID=65534 RUNGID=65534 mkdir -p $(CURDIR)/debian/nut-usb/etc/udev/rules.d install -m 644 $(CURDIR)/scripts/hotplug-ng/nut-usbups.rules \ - $(CURDIR)/debian/nut-usb/etc/udev/rules.d/025_nut-usbups.rules + $(CURDIR)/debian/nut-usb/etc/udev/nut-usbups.rules $(MAKE) install-cgi \ DESTDIR=$(CURDIR)/debian/nut-cgi RUNUID=65534 RUNGID=65534 mv $(CURDIR)/debian/nut/lib/nut/upsdrvctl $(CURDIR)/debian/nut/sbin
Bug#400215: solution....
From memory of other udev rule installing pkgs the file is installed into "/etc/udev/nut-usbups.rules" and the symlink is made in "/etc/udev/rules.d" Regards Alex Owen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#395319: /sbin/dump: illegal density error - fixed upstream in amanda 2.5.1p1
Package: amanda-client Version: 2.5.1-1 Severity: grave Justification: "makes the package in question unusable or mostly so, or causes data loss" Hello, I have installed amanda 2.5.1-1 from unstable on an otherwise testing box. The next day my regular amanda e-mail's show that other amanda clients are being backed up but that the server cannot back itself up. Extracts from amanda mail report: ---8<8<8<--- FAILURE AND STRANGE DUMP SUMMARY: server /usr lev 1 FAILED [/sbin/dump returned 1] ... FAILED AND STRANGE DUMP DETAILS: /-- server /usr lev 1 FAILED [/sbin/dump returned 1] sendbackup: start [server:/usr level 1] sendbackup: info BACKUP=/sbin/dump sendbackup: info RECOVER_CMD=/bin/gzip -dc |/sbin/restore -f - ... sendbackup: info COMPRESS_SUFFIX=.gz sendbackup: info end ? /sbin/dump: illegal density -- 1usf sendbackup: error [/sbin/dump returned 1] \ ---8<8<8<--- Digging further I looked at sendbackup logs under /var/log/amanda. Here are extracts from this bad run and then extracts from the last good run (earlier version of amanda) for comparison: Bad run (amanda 2.5.1) ---8<8<8<--- sendbackup: argument list: /sbin/dump dump 1usf 1048576 - /dev/mapper/vg00-SNAPusr ... sendbackup: time 0.008: 112: strange(?): /sbin/dump: illegal density -- 1usf" ---8<8<8<--- Last good run (earlier version of amanda) ---8<8<8<--- sendbackup: argument list: /sbin/dump 1usf 1048576 - /dev/mapper/vg00-SNAPusr ---8<8<8<--- It seems that /sbin/dump is being passed the argument "dump" by mistake in the new code. Further investigation of amanda CVS/mailinglists/website indicate that this "illegal density" error is a known issue and has been fixed in the bugfix release version 2.5.1p1. I was going to try and isolate the patch for this problem but I think it is probably better to get 2.5.1p1 packaged for debian and get the other fixes as well! If you could find the time to package it that would be great! Release announcement for 2.5.1p1 http://marc.theaimsgroup.com/?l=amanda-hackers&m=115937829618796&w=2 Regards Alex Owen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311188: Possible compromise...
Could we not come to a working compromise for sarge no the basis that a propper solution is found for etch... something along the lines of this. debian-edu-config could use debconf to ask the admin somthing like: "Do you wish to apply the debian-edu configuation? Doing so will alter the configuration of several independent packages installed on your system" This could be preseeded by debian-edu fokes (right?) but give sutable warning to others! This is going to be a common problem for all CDD's (custom debian distroes). Perhaps each cdd is allowed one package like this... each of the spercial packages would have to conflict with eacho other (or something) so only one can be installed. Hmm... this may not be all that usefull but it might start someone else of on the road to a better solution. Alex Owen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310782: pdns-server testing
Hi, Saw your request for pdns-server testing... I took a copy of the package (pdns-server_2.9.17-13_i386.deb) from http://www.cacholong.nl/~matthijs/pdns Looking at the postinst you now ship /etc/powerdns/pdns.conf and /etc/default/pdns in /usr/share/pdns-server/ and use ucf to install them under /etc This seems ok as far as it goes but you still seem to ship /etc/powerdns/pdns.d/pdns.local as a conffile and then the function "splitconfig" seems to update that file without asking. Later (after the two ucf calls) you then edit /etc/powerdns/pdns.conf and /etc/default/pdns I'm not sure that editing these files in this manner is compliant with section 10.7 of policy... (http://www.uk.debian.org/doc/debian-policy/ch-files.html#s-config-files) Mind you I'm not a Debian Developer! Perhaps you could copy the /usr/share/pdns-server/ files to temporary files... do your fancy editing on those temporary files then use ucf to copy the temporary files into place? As I say I'm not a Debian Developer so feel free to ignore me if I'm poking my nose in wher it is not wanted! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#290329: uname -m not dpkg-architecture
Just thinking some more about my proposed fix... using dpkg-architecture would mean "Require: dpkg-dev" but the idea could perhaps be reworked to use "uname -m" which is in coreutils which is: $ apt-cache show coreutils Package: coreutils Essential: yes Priority: required Section: base . Not sure what a powerpc machine outputs for "uname -m" though... Alex Owen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#290329: (no subject)
tag 290329 + patch
thanks
Here is an idea:
(1) Revert the problem debian/rules change.
(2) Modify mkinitrd to set the default MODULES to dep or most based on
output of "dpkg-architecture -qDEB_HOST_ARCH"
(3) Comment out the MODLES= line in the config file and leavi it as an
example.
This is an UNTESTED patch to describe the fix better than the above
narative!
Alex Owen
diff -uNr initrd-tools-0.1.81.old/debian/rules initrd-tools-0.1.81/debian/rules
--- initrd-tools-0.1.81.old/debian/rules2005-05-14 04:45:15.0
+0100
+++ initrd-tools-0.1.81/debian/rules2005-05-25 20:49:46.0 +0100
@@ -38,9 +38,9 @@
mkinitrd debian/initrd-tools/usr/sbin/
install -o root -g root -m 644 \
mkinitrd.conf modules debian/initrd-tools/etc/mkinitrd/
-ifeq ($(DEB_HOST_ARCH),powerpc)
- sed -i -e 's%MODULES=most%MODULES=dep%'
debian/initrd-tools/etc/mkinitrd/mkinitrd.conf
-endif
+#ifeq ($(DEB_HOST_ARCH),powerpc)
+# sed -i -e 's%MODULES=most%MODULES=dep%'
debian/initrd-tools/etc/mkinitrd/mkinitrd.conf
+#endif
# Build architecture-dependent files here.
binary-arch: build install
diff -uNr initrd-tools-0.1.81.old/mkinitrd initrd-tools-0.1.81/mkinitrd
--- initrd-tools-0.1.81.old/mkinitrd2005-05-23 04:43:04.0 +0100
+++ initrd-tools-0.1.81/mkinitrd2005-05-25 20:57:03.0 +0100
@@ -24,6 +24,9 @@
defaults() {
MODULES=most
+ if [ "`/usr/bin/dpkg-architecture -qDEB_HOST_ARCH`" = "powerpc" ] ; then
+ MODULES=dep
+ fi
DELAY=0
ROOT=probe
UMASK=022
diff -uNr initrd-tools-0.1.81.old/mkinitrd.conf
initrd-tools-0.1.81/mkinitrd.conf
--- initrd-tools-0.1.81.old/mkinitrd.conf 2005-05-23 04:43:04.0
+0100
+++ initrd-tools-0.1.81/mkinitrd.conf 2005-05-25 21:01:36.0 +0100
@@ -4,7 +4,13 @@
# This file is meant to be parsed as a shell script.
# What modules to install.
-MODULES=most
+# Uncomment and edit one of these lines to override the defaults for MODULES
+
+# Default for powerpc
+#MODULES=dep
+
+# Default for other architectures
+#MODULES=most
# The length (in seconds) of the startup delay during which linuxrc may be
# interrupted.
Bug#279965: reate tmp scripts in /var somewhere
Some further thoughts on my last post. If logrotate was setGid to group "logrotate" and there is a directory under /var that is group writeable by group "logrotate"... that could be the place to create any temporary scripts? Alex Owen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#279965: create tmp scripts in /var somewhere ?
Would a better solution (longterm) be to have a new config file option "scriptsdir" which is a dir where scripts are written. If this does not exist use TMPDIR environment variable and if that does not exist /tmp. Also would it not be posible to generate a better error message or test that the mount point of the specified directory is not mounted noexec ? The system logrotate config could then specify "scriptsdir" as /var/spool/logrotate/ (not checked the FHS but somewhere like that?) and the package could install that empty directory so that the root logrotate jobs would work. The README.NEWS (or whatever the documentaiton file is called) could then suggest that users that get the improved error message place a "scriptsdir" directive in their logrotate.conf files. Just some random thougts really but perhaps some of them are useful! Alex Owen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#276172: (no subject)
My intention was to get the maintainer to reconsider the severity of this bug... OK so I and the maintaner disagree... I can live with that! Now that an NMU has been made I gather from: http://lists.debian.org/debian-release/2005/05/msg00997.html that the decision as to whether or not this fix goes into sarge is in the hands of the package maintainer... as it should be! I still hope this small fix can make it to sarge [ please ;-) ] but I'll accept the maintainers decision! Sorry if my action has precipitated any bad feeling... that was not my intention. Regards Alex Owen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
