Bug#642076: lsb-core: no need to remove /lib/ld-lsb-x86-64.so.[23]
Hi again,
Le 02.03.2012 13:18, Didier 'OdyX' Raboud a écrit :
Hi Colin and Sven, and thanks for your input on this bug;
I propose the attached patch to get this fixed by removing the symlinks
farm handling and replacing all symlinks by `solid` symlinks in the
packages. Please review and comment!
According to the feedback I got on IRC, shipping files (or even worse;
symlinks) in /lib64 is definitely a bad idea and can only lead to bad
situations with the linker (which lives in there on amd64). Dropping the
symlink farm handled by postinst/prerm maintainer scripts in favour of
`real` package symlinks wouldn't lead to the simplicity I aimed at.
Le 23.01.2012 21:44, Sven Joachim a écrit :
It would probably be better to only remove those symlinks on upgrades
from versions 3.2-28, and to do it before creating the new links.
Agreeing with that point of view, I prepared the attached patch that
does just that, in postinst before creating/updating the symlink farm
(as before, comments welcome).
Cheers,
OdyX
From 7b5b25df6a3f4bdd9ae8325ecb4c2beecc0d1140 Mon Sep 17 00:00:00 2001
From: Didier Raboud o...@debian.org
Date: Fri, 2 Mar 2012 17:50:10 +0100
Subject: [PATCH] Remove /lib/ld-lsb-x86-64.so.* only on upgrade.
This is a safe-side fix useful only for amd64.
Closes: #642079
Reported-by: Colin Watson cjwat...@debian.org
Signed-off-by: Didier Raboud o...@debian.org
---
debian/lsb-core.postinst |6 --
debian/lsb-core.prerm|2 +-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/debian/lsb-core.postinst b/debian/lsb-core.postinst
index 0321747..435d1e0 100755
--- a/debian/lsb-core.postinst
+++ b/debian/lsb-core.postinst
@@ -29,8 +29,6 @@ setup_ldso_symlink () {
ln -sf ld-linux.so.2 /lib/ld-lsb.so.3
ln -sf ld-linux-x86-64.so.2 /lib64/ld-lsb-x86-64.so.2
ln -sf ld-linux-x86-64.so.2 /lib64/ld-lsb-x86-64.so.3
-[ -L /lib/ld-lsb-x86-64.so.2 ] rm /lib/ld-lsb-x86-64.so.2 ||
true
-[ -L /lib/ld-lsb-x86-64.so.3 ] rm /lib/ld-lsb-x86-64.so.3 ||
true
;;
ia64)
ln -sf ld-linux-ia64.so.2 /lib/ld-lsb-ia64.so.1
@@ -56,6 +54,10 @@ case $1 in
shadowconfig on 2 || true
fi
fi
+if dpkg --compare-versions $2 lt 3.2+Debian30 ; then
+ [ -L /lib/ld-lsb-x86-64.so.2 ] rm /lib/ld-lsb-x86-64.so.2 || true
+ [ -L /lib/ld-lsb-x86-64.so.3 ] rm /lib/ld-lsb-x86-64.so.3 || true
+fi
setup_ldso_symlink
;;
abort-upgrade|abort-remove|abort-deconfigure)
diff --git a/debian/lsb-core.prerm b/debian/lsb-core.prerm
index e6b26b6..8b1f535 100644
--- a/debian/lsb-core.prerm
+++ b/debian/lsb-core.prerm
@@ -18,7 +18,7 @@ remove_ldso_symlink () {
rm -f /lib/ld-lsb.so.[123]
;;
amd64)
-rm -f /lib/ld-lsb.so.[123] /lib64/ld-lsb-x86-64.so.[23]
/lib/ld-lsb-x86-64.so.[23]
+rm -f /lib/ld-lsb.so.[123] /lib64/ld-lsb-x86-64.so.[23]
;;
*)
echo ld-lsb-*.so.1 symlink for $ARCH is unknown; not removed.
--
1.7.2.5
signature.asc
Description: OpenPGP digital signature
Bug#661109: lsb: Please include helper function for init scripts on upstart-based systems
Hi Steve, and thanks for your bugreport, Le 24.02.2012 10:05, Steve Langasek a écrit : Please find attached a patch for lsb that adds a new helper function to /lib/lsb/init-functions to support maintainer scripts that should behave as no-ops because the package is upstart-aware and upstart is in use. Okay. I'm proposing this change in support of bug #591791, a bug against debian-policy which aims to come up with coherent rules about the inclusion of native upstart jobs in Debian. This is not a very high-level abstraction, it still requires the init script to work out the correct return value for each invocation. That's about as high-level as most of the other lsb functions get anyway, but if you'd like something different I'm certainly open to discussing. tl;dr: Is the LSB support package really the good place to support multiple init systems in Debian ? I'm mostly fine with the current patch; I just wonder if /lib/lsb/init-functions is really the good file/package to have all those Debian-specific initscript functions. As was highlighted by the #596529 bug, /lib/lsb/init-functions already ships way more functions that what the LSB mandates. I wonder if moving the Debian-specific (non-LSB) functions to an hypothetic /lib/debian/init-functions or alike wouldn't make things cleaner, e.g. maintained in a Debian-specific package, such as `base-files` or `debian-initsupport` or `whatever`. We could even consider that debian-initsupport package as the starting support for all the let's support more than one init system problem. On the other hand, as I expressed in my #596529 wontfix, many packages in Debian currently depend on functions implemented in /lib/lsb/init-functions and breaking that would certainly break wide parts of the archive and just continue to add more functions to /lib/lsb/init-functions is the easy way forward. What do you think ? Cheers, OdyX signature.asc Description: OpenPGP digital signature
Bug#657560: #657560: apt: ...i18n_Translation-en Encountered a section with no Package: header
Le 06.03.2012 11:33, David Kalnischkies a écrit :
On Thu, Mar 1, 2012 at 15:35, Didier 'OdyX' Raboud o...@debian.org wrote:
So apt should either:
a) gracefully fallback on short translations when it fails to
uncompress/parse the Translation packages;
b) Bump its Suggests: bzip to a {Pre-}Depends on bzip2 / libbz2-1.0 (if
sufficient) to be able to actually download and decompress
Translation-*.bz2 files (which are the only Translation-* files on the
Debian mirrors network).
Neither is a good solution, especially b) is a complete overreaction.
As long as we can agree on the issue, I don't insist on apt maintainers
using my proposed solutions, eh... What matters to me is that the d-i /
apt combo can work and it currently doesn't.
The problem is here that some (yes, neither all nor many) mirrors try content-
negotiation for the request of Translation-en even though the requesting
client (apt in this case) hasn't indicated that it would support this.
I'm afraid I don't understand.
Are there mirrors that have the long descriptions available in another
format than .bz2 ? Or are you saying that some mirrors send
Translation-*.bz2 files with anything else than Content-Type:
application/x-bzip2 in their HTTP headers ?
Cheers,
OdyX
signature.asc
Description: OpenPGP digital signature
Bug#565631: lsb-base: status_of_proc
tags 565631 +patch thanks Le 17.01.2010 15:58, Thomas Koch a écrit : Package: lsb-base Version: 3.2-23 Severity: normal status_of_proc is not documented. You may want to provide documentation in /usr/share/doc/lsb-base/README.Debian Hi Thomas, and thanks for your bugreport, I propose the attached patch for review and comments. (I also put Dustin Kirkland, initiator of the status_of_proc function in Debian/Ubuntu's lsb-base, in explicit CC.) Opinions ? Cheers, OdyX From c5ddfe0154ae0ce5b11dbb5c37f429c40901e026 Mon Sep 17 00:00:00 2001 From: Didier Raboud o...@debian.org Date: Wed, 7 Mar 2012 10:56:25 +0100 Subject: [PATCH] lsb-base.README.Debian: Document status_of_proc. Closes: #565631 Reported-by: Thomas Koch tho...@koch.ro Signed-off-by: Didier Raboud o...@debian.org --- debian/lsb-base.README.Debian | 29 + 1 files changed, 29 insertions(+), 0 deletions(-) diff --git a/debian/lsb-base.README.Debian b/debian/lsb-base.README.Debian index 360ae21..c10d827 100644 --- a/debian/lsb-base.README.Debian +++ b/debian/lsb-base.README.Debian @@ -68,6 +68,35 @@ specific to Debian and (in some cases) other derived distributions. Note that unlike log_end_msg(), this function does not return the first argument as its exit code. + - status_of_proc [-p pidfile] pathname Daemon_name + +Log the status of a process and return an LSB-compliant exit status +code: + +0 program is running or service is OK +1 program is dead and /var/run pid file exists +2 program is dead and /var/lock lock file exists +3 program is not running +4 program or service status is unknown +5-99reserved for future LSB use +100-149 reserved for distribution use +150-199 reserved for application use +200-254 reserved + +On Debian, outputs: + Daemon_name is running.. + Daemon_name is not running ... failed! + +The pidfile path will be used as argument for pidofproc and must be +provided if the pidfile is not /var/run/$daemon_basename.pid. + +status_of_proc can be used to easily implement the status argument +of init scripts: + + status) +status_of_proc $DAEMON $NAME exit 0 || exit $? + ;; + A deprecated function, log_start_msg, is also provided for compatibility with a few older packages and a derived distribution. This may eventually disappear. -- 1.7.2.5 signature.asc Description: OpenPGP digital signature
Bug#653598: status_of_proc should handle not-world-readable pid files better
tags 653598 +pending +patch
thanks
Hi Peter, and thanks for your bugreport, and patch
Le 29.12.2011 19:15, Peter Eisentraut a écrit :
When a pid file is specified to status_of_proc with the -p option, but
it's not readable, then status_of_proc returns 3 (not running) instead
of 4 (unknown). pidofproc handles this specially:
if [ $specified ]; then
return 3 # almost certain it's not running
fi
but it's not clear why this is supposed to be different depending on
whether the pid file is implicit or explicit.
I suggest untangling this a bit and putting
if [ -n ${pidfile:-} ] [ ! -r $pidfile ]; then
return 4 # pid file not readable
fi
near the top of pidofproc. Then we also get the correct message from
status_of_proc.
Agreed. I committed the attached patch, attributed to you (as it's not
100% the same patch, but equal in functionality and essence).
I hope it's okay that way!
Cheers,
OdyX
signature.asc
Description: OpenPGP digital signature
Bug#653598: status_of_proc should handle not-world-readable pid files better
Le 07.03.2012 11:37, Didier 'OdyX' Raboud a écrit :
Agreed. I committed the attached patch, attributed to you (as it's not
100% the same patch, but equal in functionality and essence).
Meh, failed at attaching.
From 1a02293da50c624a01c61c6fd4e956215726994a Mon Sep 17 00:00:00 2001
From: Peter Eisentraut pet...@debian.org
Date: Wed, 7 Mar 2012 11:33:43 +0100
Subject: [PATCH] Handle non-world-readable pid files.
Closes: #653598
Reported-by: Peter Eisentraut pet...@debian.org
Signed-off-by: Didier Raboud o...@debian.org
---
init-functions |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/init-functions b/init-functions
index 8b14cf7..5b951f0 100644
--- a/init-functions
+++ b/init-functions
@@ -81,7 +81,8 @@ pidofproc () {
pidfile=/var/run/$base.pid
fi
-if [ -n ${pidfile:-} ] [ -r $pidfile ]; then
+if [ -n ${pidfile:-} ]; then
+ if [ -r $pidfile ]; then
read pid $pidfile
if [ -n ${pid:-} ]; then
if $(kill -0 ${pid:-} 2 /dev/null); then
@@ -94,6 +95,9 @@ pidofproc () {
return 1 # program is dead and /var/run pid file exists
fi
fi
+ else
+return 4 # pid file not redable, hence status is unknown.
+ fi
fi
if [ -x /bin/pidof ] [ ! $specified ]; then
status=0
--
1.7.2.5
signature.asc
Description: OpenPGP digital signature
Bug#660790: lsb-base: log_warning_msg does not respect leading spaces
tags 660790 +wontfix thanks Hi Luca, and thanks for your bugreport, Le 21.02.2012 22:42, Luca Capello a écrit : As you can see, the leading space is not respected. I think this is because log_warning_msg calls log_begin_msg, which actually uses `/bin/echo -n $@` instead of adding a leading space before $@, as in log_progress_msg. The latter is IMHO more correct, given that there is no *begin* message to be displayed. However, this breaks other init scripts like rsync: --8---cut here---start-8--- 120reload|force-reload) 121 log_warning_msg Reloading rsync daemon: not needed, as the daemon 122 log_warning_msg re-reads the config file whenever a client connects. 123 ;; --8---cut here---end---8--- So I do not really how this should be solved :-( As is documented in lsb-base's README.Debian: This package also includes the LSB-specified logging functions: log_success_msg message log_failure_msg message log_warning_msg message These functions *do not* comply with Debian policy and should only be used by LSB packages. So, openvpn (and rsync probably), should rather use the log_action_begin_msg / log_action_end_msg pair (or the log_action_msg) instead of those. Hence tagging as wontfix as the documentation explicitly recommends against using those functions. Now, this makes me wonder about investigating and mass-filing bugs against init scripts making use of them. Doh. I hope this gives a honest answer to your bug. Salutations, OdyX signature.asc Description: OpenPGP digital signature
Bug#650584: lsb-base: killproc does not wait for process to end
tags 650584 +patch
thanks
Le 30.11.2011 23:37, Daniel Nelson a écrit :
The killproc function called without a signal does not wait for the
process to end as required by the lsb specification, and never sends
SIGKILL if the process does not end.
I believe this was introduced with the fix for #451529, which removed
the '--retry 5' option from start-stop-daemon. The real cause of that
bug was fixed in start-stop-daemon, #451531, and so it should be okay to
add back this option.
Hi Daniel, and thanks for your bugreport,
I propose the attached patch, that only re-adds the --retry 5 to the
start-stop-daemon call that happens when no signal is specified,
according to the letter of the LSB.
Comments/Opinions ?
Cheers,
odyX
From d6496c323b50e5900a8465fc4f0c1e95677f2755 Mon Sep 17 00:00:00 2001
From: Didier Raboud o...@debian.org
Date: Wed, 7 Mar 2012 13:26:01 +0100
Subject: [PATCH] In killproc(), re-add a '--retry 5' to s-s-d when no signal is
specified.
According to the letter of the LSB:
killproc:If a signal is specified, (...) the program is sent that signal.
Otherwise, a SIGTERM followed by a SIGKILL after an unspecified
number of seconds shall be sent.
According to start-stop-daemon manpage, that's what `--retry 5` does, with `5
seconds` being the `unspecified` of LSB, hence the `--retry 5` is only added
in the case where no signal is specified.
Closes: #650584
Reported-by: Daniel Nelson tor...@connect2.com
Signed-off-by: Didier Raboud o...@debian.org
---
init-functions |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/init-functions b/init-functions
index c646073..08e7f40 100644
--- a/init-functions
+++ b/init-functions
@@ -134,22 +134,23 @@ killproc () {
else
name_param=--pidfile $pidfile
fi
sig=$(echo ${2:-} | sed -e 's/^-\(.*\)/\1/')
sig=$(echo $sig | sed -e 's/^SIG\(.*\)/\1/')
-if [ -z $sig ] || [ $sig = 15 ] || [ $sig = TERM ]; then
+if [ $sig = 15 ] || [ $sig = TERM ]; then
is_term_sig=terminate_signal
fi
status=0
if [ ! $is_term_sig ]; then
if [ -n $sig ]; then
/sbin/start-stop-daemon --stop --signal $sig \
--quiet $name_param || status=$?
else
/sbin/start-stop-daemon --stop \
+ --retry 5 \
--quiet $name_param || status=$?
fi
else
/sbin/start-stop-daemon --stop --quiet \
--oknodo $name_param || status=$?
fi
--
1.7.2.5
signature.asc
Description: OpenPGP digital signature
Bug#644285: lsb-base: Disabled escape sequences
tags 644285 +moreinfo thanks Hi Mats, and thanks for your bugreport, Le 04.10.2011 21:36, Mats Erik Andersson a écrit : At a previous time the functions in 'init-functions' were allowed to use /bin/echo -e whereas presently they are all forced into using /bin/echo -n It would be far superior to use /bin/echo -ne as this restores to any script author the possibility of issueing structured messages using standard escape sequences like \b\t. On one hand, I understand the desire to have access to powerful structured messages in init scripts. On the other hand, I see some value in limiting what can be done to the display by init script messages. In fact, I fail to see valid reasons to use structured messages in init scripts and your bugreport doesn't show a real-world use case. By the way, are there init scripts that got broken by this change ? For now, I'm tempted to tag this bug as +wontfix but am open to get convinced, hence +moreinfo. Cheers, OdyX signature.asc Description: OpenPGP digital signature
Bug#479295: Bugs #450652 #479295 Extending /lib/lsb/init-functions to be able to set start-stop-daemon arguments
tags 479295 +wontfix +help tags 450652 +wontfix +help thanks Le 08.11.2007 21:22, Marc Haber, in #450652, a écrit : to start a daemon that does not write its pidfile itself, it might be needed to pass the --background and/or --make-pidfile to start-stop-daemon. Ths lsb-base function should offer a possibility to do so. Le 04.05.2008 10:09, Marc Haber, in #479295, a écrit: please implement a way to pass a user-specified value for the --retry option in the start-stop-daemon call in killproc. Hi Marc and thanks for your bugreports, While I understand the rationale behind your two bugs, I think that extending the functions currently defined in lsb-base' init-functions to support more start-stop-daemon arguments will mostly increase the complexity, for little benefit. The current lsb-base README.Debian explicitely says: Note: Debian packages probably should use start-stop-daemon directly; however, these functions may be useful in porting init scripts from other distributions. And I think that this recommendation still holds. So I am hereby tagging these two bugreports as +wontfix as _I_ won't do the work, but also as +help: if someone wants to provide patches, I'll happily review them. Cheers, OdyX signature.asc Description: OpenPGP digital signature
Bug#338556: lsb-base: ugly output
tags 338556 +unreproducible +moreinfo thanks Le 11.11.2005 01:46, Ian Zimmerman a écrit : Now that they use the functions in /lib/lsb/init-functions, the output from many initscripts now looks like this: Thu Nov 10 18:48:02 2005: . Thu Nov 10 18:48:02 2005: findfs: Unable to resolve 'LABEL=USBDISK' Thu Nov 10 18:48:02 2005: Activating swap... Thu Nov 10 18:48:02 2005: . Thu Nov 10 18:48:02 2005: Checking root file system.../dev/hda3: clean, 161071/7389184 files, 989657/14755702 blocks Thu Nov 10 18:48:02 2005: . Thu Nov 10 18:48:02 2005: Cleaning up ifupdown...done. Thu Nov 10 18:48:03 2005: Calculating module dependencies...done. Thu Nov 10 18:48:03 2005: Loading modules... Thu Nov 10 18:48:03 2005: snd-via82xx Thu Nov 10 18:48:04 2005: Setting up ALSA Thu Nov 10 18:48:04 2005: snd-pcm-oss Thu Nov 10 18:48:04 2005: snd-mixer-oss Thu Nov 10 18:48:04 2005: lp Thu Nov 10 18:48:04 2005: All modules loaded. Thu Nov 10 18:48:04 2005: Setting the System Clock using the Hardware Clock as reference Thu Nov 10 18:48:06 2005: System Clock set. Local time: Thu Nov 10 23:48:06 UTC 2005 Thu Nov 10 18:48:06 2005: . Thu Nov 10 18:48:06 2005: Checking all file systems.../dev/hda1: clean, 36/8032 files, 7018/32098 blocks Thu Nov 10 18:48:06 2005: . Thu Nov 10 18:48:06 2005: Setting kernel variables ... Thu Nov 10 18:48:06 2005: ... done. Thu Nov 10 18:48:06 2005: Mounting local filesystems.../dev/hda1 on /boot type ext3 (rw) Thu Nov 10 18:48:06 2005: . etc. (this is from /var/log/boot, the actual output doesn't have the date+time prefix, but the line breaks are the same) Hi Ian, more than 6 years after, has this bug been solved for you? Thanks in advance for more information, eventually leading to either solving or closing that bug. Cheers, OdyX signature.asc Description: OpenPGP digital signature
Bug#616131: ITA: LSB package maintenance in Debian
retitle 616131 ITA: lsb -- Linux Standard Base 4.0 support package owner 616131 ! Hi all, (tl;dr Git repository with actual state is available, please help :-) I just noticed the worrying state of the LSB package in Debian: * Still in version 3.2 (released in January 2008) while 4.1 is out since a year (coincidently today); * RFA'd - #616131; * behind Ubuntu since at least Karmic (9.10) which already had 4.0. I would like to get the LSB package up to date before Wheezy's freeze, planned for June. For now, I just filled a Git repository [0] with all past Debian (at least those available on snapshot.debian.org) and Ubuntu releases (on the master-ubuntu branch). I think I mostly got authors and dates straight, but it was not fun. Now my intentions (despite limited available time) are: 1) put it under explicit team maintenance; Maintainer: debian-...@lists.debian.org ? [1] Uploaders: Myself + Chris ? 2) push the repository to collab-maint; 3) merge most of the current lsb (4.0) Ubuntu package into it, including dpkg-vendor magic to have both distros handled. 4) if needed, update it to 4.1; 5) upload a new version to experimental as soon as possible; 6) triage and if possible address all Debian bugs; 7) update the packaging to modern practices (short dh, etc) So, is anybody willing to join the fun ? Steve, Colin, Matthias: as the 3 last persons that uploaded the Ubuntu lsb package: would you be interested in merging the effort and (once done) try maintaining it in Debian first ? Cheers, OdyX [0] http://anonscm.debian.org/gitweb/?p=users/odyx-guest/lsb.git [1] Given the current traffic of that list, putting that list as maintainer should not generate a too low SNR IMHO. signature.asc Description: OpenPGP digital signature
Bug#656063: Test version with bug fixes
Le 30.01.2012 15:54, Makc a écrit : Hmm. Unavailable link. Right, sorry. Alioth is indeed down [0]. I have pushed the files to a private server of mine: [i386] http://azrael.raboud.homelinux.org/~didier/Debian/usb-modeswitch_1.2.2-1-1~bugfix0_i386.deb [amd64] http://azrael.raboud.homelinux.org/~didier/Debian/usb-modeswitch_1.2.2-1-1~bugfix0_amd64.deb [source] http://azrael.raboud.homelinux.org/~didier/Debian/usb-modeswitch_1.2.2-1-1~bugfix0.dsc Cheers, and sorry for the inconvenience, OdyX [0] http://lists.debian.org/debian-devel-announce/2012/01/msg00011.html signature.asc Description: OpenPGP digital signature
Bug#657830: win32-loader: Please make pxe.target depend on the ipxe package
tags 657830 +patch
thanks
Le 29.01.2012 11:00, Alkis Georgopoulos a écrit :
An ipxe package is available in Debian wheezy and sid:
$ rmadison ipxe
ipxe | 1.0.0+git-2.149b50-1 | wheezy | source, all
ipxe | 1.0.0+git-2.149b50-1 | sid| source, all
It would be awesome if people could get win32-loader.exe directly from
the Debian archives (by decompressing the .deb of course).
Hi Alkis, and thanks for your bugreport,
I propose the attached patch that would do even better, by providing a
win32-loader-pxe.exe from the Debian mirrors, available on
http://ftp.debian.org/debian/tools/win32-loader/unstable/win32-loader-pxe.exe
That win32-loader-pxe.exe is basically the standalone win32-loader.exe
plus the PXE choice, so there is a (minor) duplication of
functionality, but the default win32-loader.exe pointed at by
get.debian.net and the installation manuals would stay the normal
win32-loader.exe
What do you (and debian-boot ?) think about that ?
Cheers,
OdyX
From 769df684f27f477549e2cd73f00bcf85ccb15049 Mon Sep 17 00:00:00 2001
From: Didier Raboud o...@debian.org
Date: Mon, 30 Jan 2012 12:01:34 +0100
Subject: [PATCH] Build a standalone PXE-enabled version.
- Ship the PXE-enabled version as byhand file to push it towards the mirrors
network as win32-loader-pxe.exe
- Document the two standalone flavours
- Add ipxe as Build-Depends.
- Add ipxe to the Built-Using list.
Closes: #657830
Reported-By: Alkis Georgopoulos alk...@gmail.com
Signed-off-by: Didier Raboud o...@debian.org
---
Makefile|5 -
debian/control |1 +
debian/rules| 12 +++-
debian/win32-loader_doc.txt |6 ++
4 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index e5c6f66..c99843b 100644
--- a/Makefile
+++ b/Makefile
@@ -2,7 +2,7 @@
export SHELL := bash
# Targets that will always be run (as they depend on stuff from installed
packages)
-.PHONY: core.img g2ldr g2ldr.mbr loadlin.pif loadlin.exe
+.PHONY: core.img g2ldr g2ldr.mbr loadlin.pif loadlin.exe pxe.lkrn
PACKAGE:= win32-loader
VERSION:= $(shell head -n 1 debian/changelog | sed -e s/^$(PACKAGE)
(\(.*\)).*/\1/g)
@@ -105,6 +105,9 @@ loadlin.pif: genpif
loadlin.exe: /usr/lib/loadlin/loadlin.exe.gz
gunzip -c $^ $@
+pxe.lkrn: /usr/lib/ipxe/ipxe.lkrn
+ cp $^ $@
+
ifdef PXE
pxe.target: pxe.lkrn templates/ternary_choice.ini
else
diff --git a/debian/control b/debian/control
index df4ea69..6f16736 100644
--- a/debian/control
+++ b/debian/control
@@ -9,6 +9,7 @@ Build-Depends:
mingw-w64,
gettext,
grub-pc-bin (= 1.99~rc1-3),
+ ipxe,
loadlin (= 1.6c.really1.6c.nobin-1~),
locales-all,
gpgv-win32, debian-archive-keyring,
diff --git a/debian/rules b/debian/rules
index fc84014..a3d111a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -5,8 +5,9 @@ BYHAND ?= yes
W32_VERSION := $(shell dpkg-parsechangelog | sed -rne 's,^Version:
([^-]+).*,\1,p')
W32_BYHAND_NAME := win32-loader_$(W32_VERSION)_all
+W32_PXE_BYHAND_NAME := win32-loader-pxe_$(W32_VERSION)_all
-B_D_PACKAGES := grub-pc-bin cpio-win32 gzip-win32 gpgv-win32
debian-archive-keyring loadlin
+B_D_PACKAGES := grub-pc-bin cpio-win32 gzip-win32 gpgv-win32
debian-archive-keyring loadlin ipxe
PACKAGES_LIST := $(shell set -e; \
for p in ${B_D_PACKAGES}; \
@@ -42,6 +43,11 @@ ifeq ($(BYHAND),yes)
OUTFILE_NAME=$(W32_BYHAND_NAME).exe \
dh_auto_build
+ # Build the PXE (standalone) version
+ PXE=yes \
+ OUTFILE_NAME=$(W32_PXE_BYHAND_NAME).exe \
+ dh_auto_build
+
# Prepare the README file
awk '{sub(/@PACKAGES_LIST@/,$(PACKAGES_LIST))}1 \
{sub(/@NSIS_VERSION@/,$(NSIS_VERSION))}1 \
@@ -56,6 +62,7 @@ endif
override_dh_auto_clean:
dh_auto_clean
rm -f $(W32_BYHAND_NAME).exe
+ rm -f $(W32_PXE_BYHAND_NAME).exe
rm -f $(W32_BYHAND_NAME).txt
override_dh_builddeb:
@@ -64,6 +71,9 @@ ifeq ($(BYHAND),yes)
cp $(W32_BYHAND_NAME).exe ../
dpkg-distaddfile $(W32_BYHAND_NAME).exe byhand -
+ cp $(W32_PXE_BYHAND_NAME).exe ../
+ dpkg-distaddfile $(W32_PXE_BYHAND_NAME).exe byhand -
+
cp $(W32_BYHAND_NAME).txt ../
dpkg-distaddfile $(W32_BYHAND_NAME).txt byhand -
endif
diff --git a/debian/win32-loader_doc.txt b/debian/win32-loader_doc.txt
index 6162ddd..31ec502 100644
--- a/debian/win32-loader_doc.txt
+++ b/debian/win32-loader_doc.txt
@@ -29,6 +29,12 @@ the Debian Installation Guide before launching
win32-loader.exe:
http://www.debian.org/releases/stable/installmanual
+== Versions ==
+
+The standalone win32-loader is provided in two versions: the standard
+`win32-loader.exe` and the PXE-enabled `win32-loader-pxe.exe` which
+additionally offers the possibility to boot the iPXE loader.
+
== Removal ==
When win32-loader.exe is uninstalled, it removes the Debian-Installer image
--
Bug#656906: win32-loader: [INTL:sr@latin] Serbian Latin templates translation
Hi Karolina and Christian, Le 24.01.2012 00:39, Karolina Kalic a écrit : Serbian.nlf to SerbianLatin.nlf, I checked, Serbian Latin is supported by Nsis installer. Great, thanks. I'm just not sure about this: #. translate: #. This must be a valid string recognised by Nsis. If your #. language is not yet supported by Nsis, please translate the #. missing Nsis part first. #. #: win32-loader.sh:36 #: win32-loader.c:39 msgid LANG_ENGLISH msgstr LANG_SERBIAN_LATIN It says that the string must be recognized by Nsis, but I couldn't find any list of this, how it shoul be written, so help is welcome. That list is in the Contrib/MakeLangId/MakeLangId.cpp file from the NSIS source, which shows that the @latin version is a sublanguage of LANG_SERBIAN. I will push that correction to the packaging repository. Cheers, OdyX signature.asc Description: OpenPGP digital signature
Bug#668416: killproc incorrect exit status
severity 668416 serious
tags 668416 +patch
thanks
Le 11.04.2012 19:59, Peter Eisentraut a écrit :
Somewhere between versions 3.2+Debian31 and 4.1+Debian0, the exit
status of the killproc function (/lib/lsb/init-functions) was changed
to return 3 when the program is not running. This is only correct
when a signal was specified; see
http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptfunc.html:
If called without a signal, it shall return 0 if the program has
been stopped or is not running and not 0 otherwise. If a signal is
given, it shall return 0 only if the program is running.
This breaks init scripts that rely on this behavior; see for example
bug #667623.
Hi Peter, and thanks for your bugreport. This seems serious enough to
warrant RC severity IMHO, hence hereby rising severity.
Simple test:
sudo bash
. /lib/lsb/init-functions
killproc /usr/bin/nonexistent
echo $?
should print 0. It now prints 3.
Attached is a proposed patch: as far as I can see, it does solve the
problem pointed by this bugreport and does indeed work in the testcase
you propose, but I'm not confident enough to claim it doesn't break
anything else; would you mind to take a look?
Cheers,
OdyX
From 5cafecc339c585699b064a5c57149f6d367d7c8b Mon Sep 17 00:00:00 2001
From: Didier Raboud o...@debian.org
Date: Thu, 12 Apr 2012 14:13:35 +0200
Subject: [PATCH] In killproc(), make sure to exit 0 when the program is not running and when no signal was specified.
Closes: #668416
Reported-by: Peter Eisentraut pet...@debian.org
Signed-off-by: Didier Raboud o...@debian.org
---
init-functions |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/init-functions b/init-functions
index 3be5648..9aa1db7 100644
--- a/init-functions
+++ b/init-functions
@@ -142,41 +142,41 @@ killproc () {
sig=$(echo ${2:-} | sed -e 's/^-\(.*\)/\1/')
sig=$(echo $sig | sed -e 's/^SIG\(.*\)/\1/')
if [ $sig = 15 ] || [ $sig = TERM ]; then
is_term_sig=terminate_signal
fi
status=0
if [ ! $is_term_sig ]; then
if [ -n $sig ]; then
/sbin/start-stop-daemon --stop --signal $sig \
--quiet $name_param || status=$?
else
/sbin/start-stop-daemon --stop \
--retry 5 \
--quiet $name_param || status=$?
fi
else
/sbin/start-stop-daemon --stop --quiet \
--oknodo $name_param || status=$?
fi
if [ $status = 1 ]; then
-if [ -n $sig ]; then
+if [ -z $sig ]; then
return 0
fi
return 3 # program is not running
fi
if [ $status = 0 ] [ $is_term_sig ] [ $pidfile ]; then
pidofproc -p $pidfile $1 /dev/null || rm -f $pidfile
fi
return 0
}
# Return LSB status
status_of_proc () {
local pidfile daemon name status
pidfile=
OPTIND=1
while getopts p: opt ; do
case $opt in
p) pidfile=$OPTARG;;
--
1.7.2.5
signature.asc
Description: OpenPGP digital signature
Bug#621020: Re: really? (Debian Policy and LSB)
Le 11.04.2012 22:04, Raphael Hertzog a écrit :
On Wed, 11 Apr 2012, Nicholas Bamber wrote:
Hmm... This contradicts section 6.1 of the Debian policy.
The package management system looks at the exit status from these
scripts. It is important that they exit with a non-zero status if
Here these scripts refer to package maintainer scripts
({pre,post}{inst,rm}) and not to init scripts. So there's no
contradiction.
The problem of using set -e in init script is even documented
in policy 9.3.2:
http://www.debian.org/doc/debian-policy/ch-opersys.html#s-writing-init
For what is worth, this has been discussed at length in #546743 and is
now documented as the #661002 bug against lsb-base.
Please note that #661002 lsb-base:/lib/lsb/init-functions may fail if
`set -e` is used is tagged as +help: patches are welcome and could
eventually lead to a fix in policy.
(Deciding whether energy should be put in functions for SysVinit is up
to each reader.)
Cheers,
OdyX
signature.asc
Description: OpenPGP digital signature
Bug#668958: lsb-base: pidofproc doesn't return correct status for daemons without pidfile
tags 668958 +patch
thanks
Le 16.04.2012 03:48, Adrian Fita a écrit :
Hi.
I noticed that /etc/init.d/hddtemp status wasn't returning the correct
status when the daemon was running. hddtemp daemon doesn't create a pidfile
when started, so I tracked the problem back to the pidofproc function
from /lib/lsb/init-functions.
Hi Adrian, and thanks for your bugreport,
as far as I can see, this behaviour has been broken by my fix for #664621:
http://anonscm.debian.org/gitweb/?p=collab-maint/lsb.git;a=commitdiff;h=23c14db
Basically I put the section with if [ -x /bin/pidof ] [ !
$specified ]; then before the section with base=${1##*/}. Now the
function is corectly detecting the pids and /etc/init.d/hddtemp status
gives the right information. Please check the attached patch. I also
tested the other daemons on my system, both with pidfiles and without
and all seem to work fine.
This patch (besides being reversed) makes all pidofproc with
unspecified pidfile name calls call /bin/pidof, which is undesired IMHO.
I propose the attached patch, that only resorts to calling /bin/pidof
when the pidfile is provably inexistant and when it wasn't specified at
first.
Can you please test it and report back?
Cheers, OdyX
From 05b2f8781d80ede77c817c963583d674b3ae1502 Mon Sep 17 00:00:00 2001
From: Didier Raboud o...@debian.org
Date: Mon, 16 Apr 2012 10:09:09 +0200
Subject: [PATCH] pidofproc(): Make sure to try /bin/pidof when no pidfile is specified.
Closes: #668958
Reported-by: Adrian Fita adrian.f...@gmail.com
Signed-off-by: Didier Raboud o...@debian.org
---
init-functions | 19 ++-
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/init-functions b/init-functions
index 3be5648..512f1bf 100644
--- a/init-functions
+++ b/init-functions
@@ -100,17 +100,18 @@ pidofproc () {
return 4 # pid file not readable, hence status is unknown.
fi
else
- return 3 # pid file doesn't exist, program probably stopped
+ # pid file doesn't exist, try to find the pid nevertheless
+ if [ -x /bin/pidof ] [ ! $specified ]; then
+ status=0
+ /bin/pidof -o %PPID -x $1 || status=$?
+ if [ $status = 1 ]; then
+ return 3 # program is not running
+ fi
+ return 0
+ fi
+ return 3 # specified pid file doesn't exist, program probably stopped
fi
fi
-if [ -x /bin/pidof ] [ ! $specified ]; then
-status=0
-/bin/pidof -o %PPID -x $1 || status=$?
-if [ $status = 1 ]; then
-return 3 # program is not running
-fi
-return 0
-fi
if [ $specified ]; then
return 3 # almost certain it's not running
fi
--
1.7.2.5
signature.asc
Description: OpenPGP digital signature
Bug#668958: lsb-base: pidofproc doesn't return correct status for daemons without pidfile
tags 668958 +pending thanks Le 16.04.2012 11:07, Adrian Fita a écrit : This patch (besides being reversed) makes all pidofproc with unspecified pidfile name calls call /bin/pidof, which is undesired IMHO. I propose the attached patch, that only resorts to calling /bin/pidof when the pidfile is provably inexistant and when it wasn't specified at first. Can you please test it and report back? You're rigth. Your patch is better. I tested it and works fine. Great. Committed to master, hence +pending. (Will be pushed later). Thanks for your promptness! Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717833: plasma-widget-networkmanagement: VPN connections can't be established anymore
Package: plasma-widget-networkmanagement Version: 0.9.0.9-1 Severity: important Dear Maintainer, Since I upgraded to 0.9.0.9-1, my VPN connections don't establish anymore (in particular, with openconnect). Downgrading to 0.9.0.8-3 fixes that problem. Apparently, the password doesn't get transmitted to the VPN backend properly as I was getting openconnect[7566]: Got inappropriate HTTP CONNECT response: HTTP/1.1 401 Unauthorized lines in syslog with 0.9.0.9-1. I'm happy to provide more logs and help debug that if needed. Cheers, OdyX -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-proposed-updates'), (500, 'proposed-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718416: general: tty1 is cleared at boot, obscuring a screenfull of important boot messages
Le mercredi, 31 juillet 2013 15.17:57, Holger Levsen a écrit : reassign 718416 sysvinit thanks $ grep etc/inittab /var/lib/dpkg/info/* /var/lib/dpkg/info/sysvinit.postinst:if [ ! -f /etc/inittab ] /var/lib/dpkg/info/sysvinit.postinst: cp -p /usr/share/sysvinit/inittab /etc/inittab sysvinit didn't change in that regard for a long time. I think the bug belongs to util-linux which changed the getty implementation: util-linux (2.17.2-4) unstable; urgency=low (…) * Deliver agetty as both agetty and getty, preferring agetty. Closes: #117596 (…) -- LaMont Jones lam...@debian.org Fri, 24 Dec 2010 14:06:47 -0700 Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634325: cups-polld does not properly handle network errors, uses 100%
Control: tags -1 +moreinfo Le lundi, 15 octobre 2012 18.20:13, Samuel Wolf a écrit : Still have this problem with Debian Wheezy. /etc/cups/cupsd.conf [...] # Show shared printers on the local network. Browsing On BrowsePoll printserver.local [...] comment out BrowsePoll fix it, but should it not resolved in this version? Hi Samuel, Wheezy has now been released as stable, can confirm (or preferably, infirm) that you still encounter this bug? Thanks in advance, cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645436: cups: Useless error message in http-support.c
Control: severity -1 wishlist Hi ael, I can confirm this patch would still apply in cups 1.6.2. Le samedi, 15 octobre 2011 23.32:13, ael a écrit : I am trying to locate a bug in cups which currently looks like a broken pipe. After attempts to write to a socket, an http status of HTTP_ERROR is returned which does not have a case in the relevant switch statement in cups/http-support.c. As a result, the unhelpful default message Unknown is passed back to the user who is none the wiser. The attached patch improves the default message, and adds an extra branch for HTTP_ERROR. There should perhaps be further cases for other values in http.h which are not covered explicitly. Michael: this patch [0] could be of interest to you. Cheers, Didier [0] http://bugs.debian.org/cgi- bin/bugreport.cgi?msg=5;filename=http_errormsg.patch;att=1;bug=645436 signature.asc Description: This is a digitally signed message part.
Bug#708212: Please upload latest SVN snapshot
Control: clone -1 -2 Control: reassign -2 sponsorship-requests Control: retitle -2 RFS: splix/2.0.0+svn308-1 Control: owner -2 o...@debian.org Control: affects -2 src:splix Control: block -1 by -2 Hi Luca, thanks for your answer to this bugreport. I'm hereby cloning this bug to a Request for Sponsorship on the sponsorship- requests pseudo-package, to track the comments on your package there. Le mardi, 4 juin 2013 01.18:21, Luca Niccoli a écrit : Here's the link to the dsc: http://mentors.debian.net/debian/pool/main/s/splix/splix_2.0.0+svn308-1.dsc Le dimanche, 2 juin 2013 13.03:04, Luca Niccoli a écrit : I've uploaded to mentors a new version of splix. The changes are: - move to the lates svn snapshot Ack, great. One comment though: the Ubuntu package [0] closed one Launchpad (LP:) bug in that changelog entry (LP: #898986). It's good practice to include these when possible as that makes Ubuntu's job easier too at synchronisation time (and costs the Debian package nothing more than some bits in the changelog). - copy fixed splix.ppd-updater from Ubuntu Ack, great. - add conditional apport hook for Ubuntu and derivatives This doesn't work as the derives_from_ubuntu Make variable hasn't been defined. You need to add it's definition in debian/rules (on one line of course): derives_from_ubuntu := $(shell (dpkg-vendor --derives-from Ubuntu echo yes) || echo no) - add get-orig-source target Good. - used dpkg-buildflags to import hardening flags I see that you applied these using a Debian-specific quilt patch. Although I would initially have written that these flags are modifiable without a quilt patch, apparently the LDFLAGS variables can't inheritate from debian/rules. That said, it would be good to: a) set V=1 to get a verbose build (that allows one to verify that the flags are correctly set); b) define the flags from dpkg at make execution time instead of executing dpkg-buildflags at every CC invocation, with: $(shell dpkg-buildflags --get CXXFLAGS) - bumped Standards-Version Just to make that clear: did you check the upgrading-checklist from the debian-policy package while doing so? I'd be glad if you could review the upload and give me some comments. See above. Didier, I'd be glad to move splix packaging under team maintenance, possibly under git. Cool. These are two different things though: - putting the packaging under team maintenance means setting Debian Printing Team debian-print...@lists.debian.org as Maintainer and yourself in the list of Uploaders. This implies that your package might get enhancements of fixes from other members of the printing team. Such changes are not supposed to happen without coordination with the main Uploaders though, don't worry. - moving the packaging in git. I invite you to read [PackagingWithGit] on the wiki, if possible using the pristine-tar option. Get started and ask if you have questions! For the initial git'ification, I suggest that you use the git- import-dscs tool to fetch all past releases from Debian Snapshots. [PackagingWithGit] http://wiki.debian.org/PackagingWithGit Maybe we can talk about it in private mail or on a list, so we do not fill this bug with unrelated stuff? Please answer to the cloned bug (once we know it's number). There's no (and almost never) reason to handle things in private when it's possible to handle them in public: the comments on your package can be helpful to others. P.S. mentors seems a bit slow in accepting my upload, but I'm hopeful that it will appear in the next few hours. That's apparently solved, great. Cheers, OdyX [0] https://launchpad.net/ubuntu/+source/splix/2.0.0+svn308-0ubuntu1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712237: cups-server-common: The cost factor for pstops
Le vendredi, 14 juin 2013 19.17:36, Didier 'OdyX' Raboud a écrit : So apparently the IPP interface only answers 72 bytes without some of the mandatory attributes with this patch enabled. The full HTML log is attached if one of you wants to take a look. I don't have an immediate clue right now but I suspect that pstops might be at fault somewhere, but I can't say where. FYI, I just tried with filter/pstops.c from 1.5.3 and it doesn't help. OdyX signature.asc Description: This is a digitally signed message part.
Bug#706888: cups: Could not print to server after upgrade: Failed to add Avahi entry
Hi all, Le dimanche, 16 juin 2013 15.21:15, Julian Gilbey a écrit : I have hit the same problem, as cups has just migrated to testing. My error log (/var/log/cups/error_log) says: cups 1.6 didn't migrate to testing yet. E [16/Jun/2013:14:18:49 +0100] Failed to add Avahi entry for Samsung ML-1610 @ erdos: -8 E [16/Jun/2013:14:18:49 +0100] Failed to add Avahi entry for Samsung ML-1610 @ erdos: -8 Oh dear :-( I have avahi-daemon installed and running: erdos:~ # /etc/init.d/avahi-daemon status Avahi mDNS/DNS-SD Daemon is running Do you both have cups-browsed installed and running ? TIA, cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706888: cups: Could not print to server after upgrade: Failed to add Avahi entry
Hi, First, please don't mail me directly, but always the bug, so that others can also assist you. For now I have bounced your query to the bug, don't worry. Le dimanche, 16 juin 2013 21.46:53, NetCat a écrit : Thanks for your light-speed response. I have Intel Core 2 Duo Quad, which packages should I install from http://alioth.debian.org/~odyx-guest/debian/wheezy/ and in which order? It doesn't depend on your CPU, but on the architecture of your Debian installation, which you can see by running the following command: dpkg --print-architecture If that outputs amd64, then you can install the above packages with the following commands: cd $(mktemp -d) wget -r -l1 -nH --cut-dirs=3 -A *1.5.3-5+706888~attempt0_*.deb http://alioth.debian.org/~odyx-guest/debian/wheezy/ Then, as root: dpkg -i *1.5.3-5+706888~attempt0_*.deb apt-get install -f Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712559: Logrotate do not restart cups
Control: tags -1 +moreinfo Hi Klaus, Le lundi, 17 juin 2013 09.43:39, vous avez écrit : Package: cups Version: 1.5.0-16 Severity: normal You run an ancient version of cups, and a curious mix of cups dependencies (cups-filters from unstable, not all cups dependencies installed, etc). Since some days cups fails to restart when the log gets rotated. So the daemon is logging to deleted files. (…) I did some tests with the postrotate section and found out that if I redirect the output of 'invoke-rc.d --quiet cups force-reload' to mail everything worked well. If I don't, it will not run properly. That different behaviour makes it difficult to debug. What output do you get in said mail? However, as you can see, I did not update for a long time now due to bug 638521 (that was closed without getting noticed by me) and 660852 that really stops me from using newer versions. These two bugs are fixed in Wheezy; please test cups 1.5.3-5 from Wheezy, including its dependencies; I wouldn't be surprised if some things would be fixed for you, including this. In any case, I will not fix bugs for versions not in the Debian suites, so please really make sure to reproduce your bug with a cups version as shipped in a Debian suite. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712559: Logrotate do not restart cups
Le lundi, 17 juin 2013 12.03:25, Klaus Ethgen a écrit : However, as you can see, I did not update for a long time now due to bug 638521 (that was closed without getting noticed by me) and 660852 that really stops me from using newer versions. These two bugs are fixed in Wheezy; Oh, The bug 660852 is still open in bugtracker. I just closed it after further investigation: it is fixed in 1.5.3 by upstream. OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711697: libcupsfilters1 has circular Depends on libcupsimage2
Le dimanche, 9 juin 2013 15.08:12, Bill Allombert a écrit : On Sun, Jun 09, 2013 at 02:19:51PM +0200, Didier 'OdyX' Raboud wrote: Control: tags -1 +moreinfo Hi Bill, and thanks for your bugreport, Le samedi, 8 juin 2013 21.31:32, Bill Allombert a écrit : There is a circular dependency between libcupsfilters1 and libcupsimage2: libcupsfilters1 :Depends: libcupsimage2 (= 1.4.0) libcupsimage2 :Depends: libcupsfilters1 (= 1.0~b1) Indeed. Good catch, thanks. Circular dependencies involving shared libraries are known to cause problems during upgrade between stable releases, so we should try to get rid of them. The problem here is that the ABI provided by libcupsimage2 has been split at version 1.6 between libcupsimage2 and libcupsfilters1, hence the depends of libcupsimage2 on libcupsfilters1. But libcupsfilters1 already exist in wheezy, so this more a transfer than a split ? A split would be more easily dealt with. Indeed, it's a transfer of symbols without SOVERSION bump. I don't particularily like it, but it's there… This could probably be downgraded to a Recommends, but brings in the risk that package A, depending on libcupsimage2 1.5 stops to work if libcupsimage2 is upgraded to 1.6 and libcupsfilters1 is not installed (aka partial upgrade). I'd like to be convinced the dependency is actually sufficient to fix partial upgrade, especially since dpkg will have to break the circular dependency anyway. Fair enough, but the dependencies ensure that dpkg is only happy with the two libraries installed at the same time, so the window of brokenness opportunity is quite small. It might be necessary to introduce an extra package. What package do you have in mind? Is there packages in wheezy that use the libcupsimage2 symbols that are now in libcupsfilters1 but do not depend on libcupsfilters1 ? As for the symbols I don't know (but could probably given more work), but these reverse dependencies (from other source packages) are in place in Wheezy: libcupsimage2-dev ← libgs-dev libcupsimage2 ← cups-filters, depends on libcupsfilters1 libcupsimage2 ← libcupsfilters1 (shlibs dependency, can't be removed) libcupsimage2 ← ghostscript-cups, doesn't depend on libcupsfilters1 libcupsimage2 ← libescpr1 (dropped in Jessie) libcupsimage2 ← libgs9, doesn't depend on libcupsfilters1 libcupsimage2 ← lsb-printing, doesn't depend on libcupsfilters1 [0] libcupsimage2 ← printer-driver-c2esp, doesn't depend on libcupsfilters1 libcupsimage2 ← printer-driver-escpr, doesn't depend on libcupsfilters1 libcupsimage2 ← printer-driver-gutenprint, doesn't depend on libcupsfilters1 libcupsimage2 ← printer-driver-hpcups, doesn't depend on libcupsfilters1 libcupsimage2 ← printer-driver-ptouch, doesn't depend on libcupsfilters1 libcupsimage2 ← printer-driver-splix, doesn't depend on libcupsfilters1 So only cups-filters seems fine, for good reasons. How can I check which symbols are used by each package without rebuilding with a special set of packages? Cheers, OdyX [0] LSB only mandates these symbols, all in libcupsimage2: http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Printing/LSB- Printing/libcupsimage.html signature.asc Description: This is a digitally signed message part.
Bug#711697: libcupsfilters1 has circular Depends on libcupsimage2
Le mardi, 18 juin 2013 10.17:15, Didier 'OdyX' Raboud a écrit : Is there packages in wheezy that use the libcupsimage2 symbols that are now in libcupsfilters1 but do not depend on libcupsfilters1 ? Grepping the output of 'nm -D' in a wheezy chroot showed that the following packages in Wheezy use symbols that move to libcupsfilters1 in unstable (cups- filters does use most of them, not listed here): printer-driver-c2esp: /usr/lib/cups/filter/c2esp 'cupsDitherDelete' 'cupsDitherLine' 'cupsDitherNew' 'cupsLutDelete' 'cupsLutNew' So printer-driver-c2esp uses some symbols from libcupsfilters1, but only depends on libcupsimage2 in Wheezy. I does depend on libcupsfilters1 in both Jessie and Sid. What do you think? Is there a way to untangle this circular depends by adding a breaks somewhere? Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#693658: bugs.debian.org: unable to print some pdf files freshly downloaded old pdf ok
Hi Frank, Please provide the complementary informations asked below: Le mercredi, 21 novembre 2012 08.02:01, Don Armstrong a écrit : You seem to be reporting a bug in cups, but I'm not quite sure. You'll have to provide quite a bit more information before anyone can help you, though. 1) What pdf are you printing? 2) What are you using to print it? 3) Does it display properly? Can you try with a recent cups too (up-to-date Wheezy would be nice)? Thanks in advance, cheers, OdyX -- OdyX signature.asc Description: This is a digitally signed message part.
Bug#520786: Localicing error
Le mardi, 18 juin 2013 14.10:38, Klaus Ethgen a écrit : Am Di den 18. Jun 2013 um 12:56 schrieb Didier 'OdyX' Raboud: I don't intend to patch cups to support non-UTF8 locales, hereby closing this bug. Well, it is common sense to use iconv to produce output for every locale. Non-UTF-8 systems are not that uncommon. Common-sense is still not the same as just review and apply the patch that someone provided in the bugreport. Apparently it's not that easy common- sense: noone produced a patch for this issue yet. So, no, UTF-8 is no solution for all problems. And just the fact that it works doesn't mean that it works good. Sure. But it works. I am yet to see a bug _in_cups_, that was due to UTF-8. But I cannot force you to solve the bug. But I think, it would be sad if you ignore the fact that there are other encodings around. You're putting words in my mouth: I don't ignore that there are other encodings around, and didn't write that at all, please re-read my quote above. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712719: cups: CUPS printing broken in Wheezy (Unable to get printer status)
Control: tags -1 +moreinfo Le mardi, 18 juin 2013 21.05:56, Adrian a écrit : Package: cups Version: 1.5.3-5 Severity: grave Justification: renders package unusable (…) * What led up to the situation? Squeeze-Wheezy upgrade. Done on 2 machines - both have the same problem now * What exactly did you do (or not do) that was effective (or ineffective)? Recreated printer, reinstalled CUPS, connected locally (instead over ipp) * What was the outcome of this action? Nope. Get-Printer-Attributes returned server-error-internal-error Unable to get printer status. Please follow the procedure outlined in https://wiki.ubuntu.com/DebuggingPrintingProblems [0] and attach the /var/log/cups/error_log file to the bugreport. Please also detail your exact setup with more details: what file did you try to print, on which cups server (local, distant), towards which printer (manufacturer, model), connected how (USB, Parallel, network, …), using which driver? Thanks in advance. OdyX [0] That we should really adapt to Debian and push to the Debian wiki, but that's another story. signature.asc Description: This is a digitally signed message part.
Bug#712559: Logrotate do not restart cups
Hi again Klaus, Le jeudi, 20 juin 2013 11.10:39, Klaus Ethgen a écrit : Seen it. I can confirm, that that two bugs are closed now. But this bug (712559) still exists after upgrading to the current version in sid. ~ lsof -n G cups This command spits an error here; what is the exact command that you are running to test for this bug ? Also, note that the logrotate script is now /etc/logrotate.d/cups-daemon and that it properly stops the daemon, rotates the logs, and starts the daemon. I don't really see what is failing on your side. Did you maybe change the cups and/or logrotate configuration? In what way? And what breaks again? Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712872: cups: [RFE] Modifying authentication data for a job in the queue
Control: tags -1 +upstream Hi Sam, and thanks for your bugreport, I'm hereby CC'ing Michael Sweet, Cups upstream author. Le jeudi, 20 juin 2013 13.59:37, Sam Morris a écrit : Some programs (such as Libreoffice) do not provide a way to specify a username and password when printing to a printer that has AuthInfoRequired username,password in its printers.conf entry. A job created by such a program will sit in the queue until an administrator removes it. I'd like a way for the administrator to specify authentication values for such a job that has been created without them. Something like: # lpmodify -o username=foo,password 7 Enter value for 'password': *** Here the given value was used for username, and since no password was specified it was prompted so that it is not visible in the process's command line arguments, nor is it recorded in the user's shell history. So you are asking for a feature to modify cups jobs to add missing credentials to them so that they can succeed on restricted printers, right? Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712559: Logrotate do not restart cups
Hi again, Le jeudi, 20 juin 2013 12.35:44, Klaus Ethgen a écrit : ~ dpkg -l logrotate ii logrotate 3.8.3-5 amd64 Log rotation utility And they seems to change the pre- and post- stuff in version 3.8.3-4. Maybe that was a wrong change. Can you try with logrotate from Jessie then? I'm leaning towards thinking it's not a bug in cups; no evidence in that direction has been demonstrated so far. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711697: libcupsfilters1 has circular Depends on libcupsimage2
Hi, Le vendredi, 21 juin 2013 13.40:16, Bill Allombert a écrit : No, but you can do it by adding an extra package: Rename the current libcupsimage2 to e.g. libcupsimage2s then add a dummy package libcupsimage2 that depend on libcupsimage2s and libcupsfilters1. and change the shlibdeps accordingly, and rebuild libcupsfilters1 so that it now depends on libcupsimage2s. I'm really not convinced that is worth the effort. What about having libcupsimage2 stop depending on libcupsfilters1 and Breaks: printer-driver-c2esp ( 26) ? OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707986: prints too small on Samsung CLP-310
Hi Martin, thanks for your bugreport. Le dimanche, 12 mai 2013 14.32:22, W. Martin Borgert a écrit : Package: printer-driver-foo2zjs Version: 20120510dfsg0-1 Severity: normal A rectangle of 100 mm x 100 mm is printed as 97 mm x 97 mm. For documentation, letters etc. it doesn't matter, but printing labels and covers becomes difficult. Workaround: If possible, use a scale of ~1.031 or ~103.1%. Does this printer work correctly with the splix driver ? Thanks in advance, cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708342: glibc_2.14 and glibc_2.15 not found
Control: severity -1 normal Control: tags -1 +moreinfo Le mercredi, 15 mai 2013 11.48:54, Adam Conrad a écrit : On Wed, May 15, 2013 at 10:37:19AM +0200, Dávid Grochal wrote: Package: glibc-doc Severity: critical glibc_2.14 and glibc_2.15 not found I'm not sure, precisely, what this is a bug report about. Could you elaborate on what the problem is that you're seeing? In the meantime, this certainly doesn't fit the definition of critical. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#708356: cups: Unable to set options, Broken pipe
Hi WforumW, Le mercredi, 15 mai 2013 12.20:55, WforumW a écrit : When I update the 'Default Options' over the Cups Web Interface I always get this error Unable to set options, Broken pipe It is not possible to change 'Default Options' for a printer over the Web Interface I can't reproduce this behaviour over localhost:631 on 1.6.2. As I can see from the logs you sent, you are accessing the cups webinterface from a remote machine using the root user, right? Does it work if you try to do the same with a non-root user member of the lpadmin group ? Thanks in advance, cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709078: libgs-dev / cups: please rebuild with libtiff5-dev
Le mardi, 21 mai 2013 10.35:51, Roland Stigge a écrit : Hi, a precondition for rebuilding ghostscript w/ libtiff5-dev is rebuilding cups w/ libtiff5-dev since libcupsimage2-dev also depends on it. Why is libtiff-dev not provided by libtiff5-dev ? cups build-depends on libtiff-dev and I'm surprised to have to change cups's source when we explicitely depend on the non-versionned -dev package. If there's a libtiff transition happening, the libtiff-dev should be provided by libtiff5-dev (and not by libtiff4-dev anymore) (and cups would be just binNMU'ed). What am I missing here? OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709078: libgs-dev / cups: please rebuild with libtiff5-dev
Le mardi, 21 mai 2013 11.22:46, Roland Stigge a écrit : You are not missing anything. :-) Since other packages are migrating to libtiff5-dev also, maybe it's time for libtiff-dev to be provided by the newer tiff? In that case, it might be time to start discussing the 4-5 libtiff transition with the release team. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696332: lsb-release: release/codename depend on a successful apt-get
Control: tags -1 +moreinfo Hi varacanero, and thanks for your bugreport, Le mercredi, 19 décembre 2012 18.20:27, varacanero a écrit : Subject: lsb-release: release/codename depend on a successful apt-get update Package: lsb-release Version: 4.1+Debian8 Severity: normal If an apt-get update fails (i.e. no internet connection), the lsb codename will change to n/a, which shouldn't happen. Release changes to testing/unstable. Even if your log confirms that, I can't reproduce this behaviour on jessie. root@wheezy:~# lsb_release -a Release:testing Codename:wheezy root@wheezy:~# iptables -A OUTPUT -p tcp --dport 80 -j REJECT root@wheezy:~# apt-get update root@wheezy:~# lsb_release -a No LSB modules are available. Distributor ID:Debian Description:Debian GNU/Linux testing/unstable Release:testing/unstable Codename:n/a How does your /etc/debian_version look like ? And what is the output of `apt- cache policy` ? Thanks in advance, cheers, OdyX -- OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706888: cups: Could not print to server after upgrade: Failed to add Avahi entry
Control: tags -1 +moreinfo Hi Luc, and thanks for your bugreport, Le dimanche, 5 mai 2013 21.52:37, Luc Castermans a écrit : After a normal upgrade of Wheezy I could not print anymore from a CUPS client to the CUPS server. On the server I found below entry in /var/log/cups/error_log E [05/May/2013:08:28:43 +0200] Failed to add Avahi entry for HP LaserJet 1320 @ emael: -8 E [05/May/2013:08:28:43 +0200] Failed to update TXT record for HP LaserJet 1320 @ emael: -2 E [05/May/2013:08:28:43 +0200] Failed to add Avahi entry for HP LaserJet 1320 @ emael: -8 What I did to fix it? Install avahi-discover on the client and run it as normal user. Was avahi-daemon installed (it is Recommended by cups) and running? Avahi is needed in a way or another for automated printers discovery and bonjour-based printer queues. Thanks in advance, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709207: cups: Duplex printing from ios6 via airprint doesn't work
Hi Jonas, and thanks for your bugreport, .oO(Putting Till in copy) Le mardi, 21 mai 2013 19.31:20, Jonas Meyer a écrit : I set up a OKI B430dn printer, using OKIs PPD. The printer is connected via Ethernet to the LAN. I enabled sharing of the printer an Internet sharing and the printer popped up in the Print Menu of my iPod running the latest version of iOS6. Single Sided Printing works exactly as expected. But if I enable double Sided Printing I get the very sam output, but the paper takes the extra route through the duplexer. Printing to the PDF file Printer shows, that no empty pages get inserted in the filtering. Looking at the ps file that is to be sent to the printer doesn't show any problems,either. This seems to be true with the latest versions of cups and cups-filters, too. This makes me think either the printer itself or the PPD files are at fault here. Does the same happen on other printers that you could eventually test? If I send duplex jobs any other way than from iOS everything works as expected. What any other way are you referring to here? Duplex-printing from non-iOS devices? So when I print a duplex job from IOS the duplexer gets activated and the paper travels the extra way through the printer. Instead I'd expect the printer to actually print on both sides. That's a reasonable expectation indeed. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708960: fprintd: Lost enrolled fingerprint after upgrade
Hi Michele, and thanks for your bugreport, Le dimanche, 19 mai 2013 21.03:58, Michele Cane a écrit : After upgrading to the latest version of fprintd: fprintd-list michele found 1 devices Device at /net/reactivated/Fprint/Device/0 Using device /net/reactivated/Fprint/Device/0 User michele has no fingers enrolled for UPEK Eikon 2. I had then to run fprintd-enroll. That's puzzling indeed. Did you update both libfprint and fprintd at the same time? Would it be possible for you to test whether this also happens if you 1) upgrade; 2) reboot; 3) test ? Meilleures salutations, OdyX -- OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709584: cups-filters: outdated embedded data copy: aglfn
Control: tags -1 +upstream Control: forwarded -1 https://bugs.linuxfoundation.org/show_bug.cgi?id=1135 Hi Paul, and thanks for your bugreport; good catch indeed! Le vendredi, 24 mai 2013 09.26:33, Paul Wise a écrit : The cups-filters source package contains an embedded data copy that is also outdated (aglfn13.c). This file is shipped in the cups-filters source package and compiled into libfontembed1 binary package. Please ask upstream to remove aglfn13.c from source package and instead build-depend on the aglfn binary package, convert the aglfn.txt shipped in the aglfn binary package into a C file at build time and possibly add a Built-Using field. I have now reported it on the upstream bugtracker, see forwarded header. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710079: [Fingerforce-devel] Bug#710079: libfprint0: Upek Biometric Touchchip/Touchstrip Fingerprint Sensor no longer work
Hi Nobuhiro, and thanks for your bugreport, Le mardi, 28 mai 2013 06.43:03, Nobuhiro IMAI a écrit : with libfprint0 (1:0.5.0-5), Upek Biometric Touchchip/Touchstrip Fingerprint Sensor no longer work. $ (…) Indeed, your log confirms that. Can you try to install libfprint 0.5.0-4 from Debian snapshots [0] ? [0] http://snapshot.debian.org/package/libfprint/1%3A0.5.0-4/ I have backported an upstream patch [1] to the -5 revision, which might conflict with your device, so confirming that it works with libfprint 0.5.0-4 would confirm that this patch is at fault. [1] http://patch- tracker.debian.org/patch/series/view/libfprint/1:0.5.0-5/u3b3679c-upeke2-Add- support-for-147e-2020-ID.patch. Thanks in advance, cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710079: [Fingerforce-devel] Bug#710079: libfprint0: Upek Biometric Touchchip/Touchstrip Fingerprint Sensor no longer work
Hi again, Le mardi, 28 mai 2013 08.51:45, Nobuhiro IMAI a écrit : From: Didier 'OdyX' Raboud odyx_at_debian.org Le mardi, 28 mai 2013 06.43:03, Nobuhiro IMAI a écrit : with libfprint0 (1:0.5.0-5), Upek Biometric Touchchip/Touchstrip Fingerprint Sensor no longer work. $ (…) Indeed, your log confirms that. Can you try to install libfprint 0.5.0-4 from Debian snapshots [0] ? I tried as follow: (…) Could not locate any suitable fingerprints matched with available hardware. [sudo] password for nov: uid=0(root) gid=0(root) groups=0(root) Hmm, it was the same result with 1:0.5.0-5. What happens if you try to reboot between your attempts ? Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710356: [nagios3-core] No scheduled downtime retention
Control: tags -1 +patch +upstream
Hi Cédric, hi Nagios maintainers,
Le jeudi, 30 mai 2013 09.29:54, Cédric Jeanneret a écrit :
I just installed the latest nagios3* on a debian Wheezy, and stumbled
on a bad bug: the scheduled downtime event aren't kept when a restart or
reload occurs.
(…)
After some researches, I stumbled on this nagios resolved bug:
http://tracker.nagios.org/view.php?id=338
It seems there's a patch available since October 2012 on the SVN:
Fixed in svn with the supplied patch and will ship with the first
version after 3.4.1 - it may be good to have a look at 3.4.2 (or
something like that), as a major feature is currently broken.
The dpatch'ed backport of the (git-)svn commit from upstream is attached.
I have built nagios3-core targetted at stable with the above patch (debdiff
attached), the built files are available there:
http://alioth.debian.org/~odyx-guest/debian/wheezy/
Cédric; it would be useful if you could test these.
Cheers,
OdyX
999_daemon-downtime-Handle-loading-effective-downtime-fr.dpatch
Description: application/shellscript
diff -u nagios3-3.4.1/debian/changelog nagios3-3.4.1/debian/changelog
--- nagios3-3.4.1/debian/changelog
+++ nagios3-3.4.1/debian/changelog
@@ -1,3 +1,11 @@
+nagios3 (3.4.1-3+deb7u1~710356) stable; urgency=low
+
+ * Non-maintainer upload.
+ * Backport upstream r1953 to fix downtime retention across restarts
+(Closes: #710356)
+
+ -- Didier Raboud o...@debian.org Thu, 30 May 2013 10:22:45 +0200
+
nagios3 (3.4.1-3) unstable; urgency=low
* Fix several overflows in getcgi.cgi and history.cgi
diff -u nagios3-3.4.1/debian/patches/00list nagios3-3.4.1/debian/patches/00list
--- nagios3-3.4.1/debian/patches/00list
+++ nagios3-3.4.1/debian/patches/00list
@@ -11,0 +12 @@
+999_daemon-downtime-Handle-loading-effective-downtime-fr.dpatch
only in patch2:
unchanged:
--- nagios3-3.4.1.orig/debian/patches/999_daemon-downtime-Handle-loading-effective-downtime-fr.dpatch
+++ nagios3-3.4.1/debian/patches/999_daemon-downtime-Handle-loading-effective-downtime-fr.dpatch
@@ -0,0 +1,86 @@
+#! /bin/sh /usr/share/dpatch/dpatch-run
+## daemon downtime: Handle loading effective downtime from retention
+##
+## All lines beginning with `## DP:' are a description of the patch.
+## DP: From 9f18395268dda948265722984097735d48d72197 Mon Sep 17 00:00:00 2001
+## DP: From: Andreas Ericsson a...@op5.se
+## DP: Date: Wed, 6 Jun 2012 09:38:06 +
+## DP: Subject: [PATCH] daemon downtime: Handle loading effective downtime from
+## DP: retention
+## DP:
+## DP: Without this patch, Nagios would forget about downtime that starts
+## DP: before the core is stopped and ends after the core is restarted.
+## DP:
+## DP: According to testers, the original problem with notifications being
+## DP: re-sent does not crop up again when this patch is applied.
+## DP:
+## DP: Tested-by: Mark Elsen mark.el...@gmail.com
+## DP: Tested-by: Phil Randal phil.ran...@hoopleltd.co.uk
+## DP: Patched-by: Carlos Velasco carlos.vela...@nimastelecom.com
+## DP: Signed-off-by: Andreas Ericsson a...@op5.se
+## DP:
+## DP: git-svn-id: https://nagios.svn.sourceforge.net/svnroot/nagios/nagioscore/trunk@1953 5f96b256-904b-4d8d-8c98-d829582c6739
+## DP: ---
+## DP: THANKS| 1 +
+## DP: common/downtime.c | 31 +++
+## DP: 2 files changed, 28 insertions(+), 4 deletions(-)
+
+@DPATCH@
+diff --git a/THANKS b/THANKS
+index d2f759a..b7c666e 100644
+--- a/THANKS
b/THANKS
+@@ -277,6 +277,7 @@ since 1999. If I missed your name, let me know.
+ * Nikola Vassilev
+ * Esteban Manchado Velazquez
+ * Geert Vanderkelen
++* Carlos Velasco
+ * Jan Vejvalka
+ * Robert August Vincent II
+ * Dave Viner
+diff --git a/common/downtime.c b/common/downtime.c
+index 09a0333..0193c50 100644
+--- a/common/downtime.c
b/common/downtime.c
+@@ -401,11 +401,34 @@ int handle_scheduled_downtime(scheduled_downtime *temp_downtime) {
+ }
+
+ /* if downtime handler gets triggerd in between then there seems to be a restart */
+- /* Don't do anything just return */
+- time( current_time);
+- if( temp_downtime-start_time current_time current_time temp_downtime-end_time temp_downtime-is_in_effect == TRUE)
+- return OK;
++ time(current_time);
++ if(temp_downtime-start_time current_time current_time temp_downtime-end_time temp_downtime-is_in_effect == TRUE) {
++#ifdef USE_EVENT_BROKER
++ /* send data to event broker */
++ broker_downtime_data(NEBTYPE_DOWNTIME_START, NEBFLAG_NONE, NEBATTR_NONE, temp_downtime-type, temp_downtime-host_name, temp_downtime-service_description, temp_downtime-entry_time, temp_downtime-author, temp_downtime-comment, temp_downtime-start_time, temp_downtime-end_time, temp_downtime-fixed, temp_downtime-triggered_by, temp_downtime-duration, temp_downtime-downtime_id, NULL);
++#endif
++
++ /* increment the downtime depth variable */
++ if(temp_downtime-type == HOST_DOWNTIME) {
++ hst-scheduled_downtime_depth++;
++
Bug#712559: Logrotate do not restart cups
Control: reassign -1 logrotate 3.8.5-1 Paul; this bug is apparently caused by logrotate 3.8.5-1, please see the #712559 buglog for details. Le jeudi, 27 juin 2013 15.47:41, Klaus Ethgen a écrit : Hi, Am Do den 20. Jun 2013 um 17:16 schrieb Didier 'OdyX' Raboud: Le jeudi, 20 juin 2013 12.35:44, Klaus Ethgen a écrit : ~ dpkg -l logrotate ii logrotate 3.8.3-5 amd64 Log rotation utility And they seems to change the pre- and post- stuff in version 3.8.3-4. Maybe that was a wrong change. Can you try with logrotate from Jessie then? I'm leaning towards thinking it's not a bug in cups; no evidence in that direction has been demonstrated so far. I did downgrade to logrotate version 3.8.3-3 and the bug is gone. So please feel free to reassign the bug to logrotate. Hereby doing so; thanks for your investigation. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714492: cups: Please allow cups to be build against libgnutls28-dev.
Control: tags -1 +moreinfo Hi Nicolas, and thanks for your bugreport, Le dimanche, 30 juin 2013 00.07:21, Nicolas Le Cam a écrit : Please find attached a patch that allows cups to be build against libgnutls28-dev. I have choosed to use the virtual package gnutls-dev to let libcups2-dev be coinstallable with both of them. You have attached a patch, for the how?, but why? isn't answered as far as I'm concerned; so why would that be useful? Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670144: fancy output sometimes broken
tags 670144 +help retitle 670144 fancy output sometimes broken by misbehaving initscripts thanks Le 23.04.2012 13:56, Michael Biebl a écrit : the new fancy output is nice. I've noticed a few services though, where it is broken, e.g. the udev or fsck init script. The output looks like this: [] Running foo (doing something) done.] If you want to reproduce the issue, just run touch /forcefsck and reboot. Cheers, Michael Hi Michael, In most cases I encountered, this is due to init scripts not using the functions from /lib/lsb/init-functions (as documented in /usr/share/doc/lsb-base/README.Debian) properly. For example, no screen output is supposed to happen between the log_daemon_msg and log_end_msg calls. Same for log_action_begin_msg and log_action_end_msg. Now, the conceptual thing that could help would be the ability to set and unset terminal left margins, to avoid having the new lines start at column 0. I haven't yet found how it would be possible, hence tagging this bug as +help. For the rest, I don't think that fixing those glitches is something that can be done in lsb-base. Patches welcome though. Cheers, OdyX signature.asc Description: OpenPGP digital signature
Bug#685456: Freeze exception for kde-gtk-config
Le dimanche, 26 août 2012 13.02:04, Boris Pek a écrit : we would normally not accept new packages into testing, but that one seems a bit special. If I parse it properly, it was previously available in squeeze, from the src:gtk-qt-engine package, but it has now moved to a dedicated source package? Yes, binary package kde-config-gtk-style in Squeeze was built from source package kcm-gtk. Wrong. It was built from source package gtk-qt-engine indeed. kcm-gtk was introduced in unstable later as the result of the split of gtk-qt-engine by Ubuntu and didn't introduce code changes. This new kde-gtk-config is a rewrite of kcm-gtk for GTK3 and takes over where kcm-gtk was left (no updates, no plan to support GTK3). And package src:kde-gtk-config is not new. It was uploaded to unstable before freeze. But new bug report prevented its automatic migration to testing. Yes. This created a new problem though: as kde-gtk-config replaced kcm-gtk's binaries (on purpose), kcm-gtk also got removed from Wheezy, breaking the upgrade path of gtk-qt-engine from Squeeze. IMHO, one of kcm-gtk or kde-gtk- config has to enter Wheezy to permit an upgrade path for this tool. Anyway, get back to us once the package is no longer RC buggy. But I can't upload package into unstable until this is not allowed by release team. Don't you think this is a closed circle? Given the current situation (and sorry for the time it took), I will review and upload 2.1-1 to fix the remaining RC bug really soon now. OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687924: moodle: diff for NMU version 2.2.3.dfsg-2.3
Le dimanche, 30 septembre 2012 15.45:03, Didier Raboud a écrit :
tags 687924 + patch
tags 687924 + pending
thanks
Dear maintainer,
I've prepared an NMU for moodle (versioned as 2.2.3.dfsg-2.3) and
uploaded it to DELAYED/1. Please feel free to tell me if I
should delay it longer.
… and to help reviewing, these are the patches, cherry-picked from upstream's
branch if you want to comment.
Cheers,
OdyX
From ebf253af171efbc5ff3a0074538c85a5edcb2ee2 Mon Sep 17 00:00:00 2001
From: Rajesh Taneja raj...@moodle.com
Date: Fri, 3 Aug 2012 11:44:20 +0800
Subject: [PATCH] MDL-30792 Files API: maxbytes will be set by
get_max_upload_file_size if less then 0 or greater then max
moodle limit
---
repository/filepicker.php |4 ++--
repository/repository_ajax.php |8 ++--
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/repository/filepicker.php b/repository/filepicker.php
index 68aee10..610ef13 100644
--- a/repository/filepicker.php
+++ b/repository/filepicker.php
@@ -93,9 +93,9 @@ if ($repository = $DB-get_record_sql($sql, array($repo_id))) {
}
}
-$moodle_maxbytes = get_max_upload_file_size();
+$moodle_maxbytes = get_max_upload_file_size($CFG-maxbytes, $course-maxbytes);
// to prevent maxbytes greater than moodle maxbytes setting
-if ($maxbytes == 0 || $maxbytes=$moodle_maxbytes) {
+if (($maxbytes = 0) || ($maxbytes = $moodle_maxbytes)) {
$maxbytes = $moodle_maxbytes;
}
diff --git a/repository/repository_ajax.php b/repository/repository_ajax.php
index b7793c8..b7f76d1 100644
--- a/repository/repository_ajax.php
+++ b/repository/repository_ajax.php
@@ -83,9 +83,13 @@ if (!$repository = $DB-get_record_sql($sql, array($repo_id))) {
/// Check permissions
repository::check_capability($contextid, $repository);
-$moodle_maxbytes = get_max_upload_file_size();
+$coursemaxbytes = 0;
+if (!empty($course)) {
+ $coursemaxbytes = $course-maxbytes;
+}
+$moodle_maxbytes = get_max_upload_file_size($CFG-maxbytes, $coursemaxbytes);
// to prevent maxbytes greater than moodle maxbytes setting
-if ($maxbytes == 0 || $maxbytes=$moodle_maxbytes) {
+if (($maxbytes = 0) || ($maxbytes = $moodle_maxbytes)) {
$maxbytes = $moodle_maxbytes;
}
--
1.7.10.4
From f7c9e3bb18e9e7fa06dff625042bf9572d709d45 Mon Sep 17 00:00:00 2001
From: Rajesh Taneja raj...@moodle.com
Date: Fri, 3 Aug 2012 11:47:44 +0800
Subject: [PATCH] MDL-30792 Files API: Cleaner approach to get maxbytes size
in filepicker
---
lib/moodlelib.php |6 +++---
repository/filepicker.php |7 ++-
repository/repository_ajax.php |7 ++-
3 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/lib/moodlelib.php b/lib/moodlelib.php
index 465226a..08b34ee 100644
--- a/lib/moodlelib.php
+++ b/lib/moodlelib.php
@@ -5728,15 +5728,15 @@ function get_max_upload_file_size($sitebytes=0, $coursebytes=0, $modulebytes=0)
}
}
-if ($sitebytes and $sitebytes $minimumsize) {
+if (($sitebytes 0) and ($sitebytes $minimumsize)) {
$minimumsize = $sitebytes;
}
-if ($coursebytes and $coursebytes $minimumsize) {
+if (($coursebytes 0) and ($coursebytes $minimumsize)) {
$minimumsize = $coursebytes;
}
-if ($modulebytes and $modulebytes $minimumsize) {
+if (($modulebytes 0) and ($modulebytes $minimumsize)) {
$minimumsize = $modulebytes;
}
diff --git a/repository/filepicker.php b/repository/filepicker.php
index 610ef13..fa759c5 100644
--- a/repository/filepicker.php
+++ b/repository/filepicker.php
@@ -93,11 +93,8 @@ if ($repository = $DB-get_record_sql($sql, array($repo_id))) {
}
}
-$moodle_maxbytes = get_max_upload_file_size($CFG-maxbytes, $course-maxbytes);
-// to prevent maxbytes greater than moodle maxbytes setting
-if (($maxbytes = 0) || ($maxbytes = $moodle_maxbytes)) {
-$maxbytes = $moodle_maxbytes;
-}
+// Make sure maxbytes passed is within site filesize limits.
+$maxbytes = get_max_upload_file_size($CFG-maxbytes, $coursemaxbytes, $maxbytes);
$params = array('ctx_id' = $contextid, 'itemid' = $itemid, 'env' = $env, 'course'=$courseid, 'maxbytes'=$maxbytes, 'maxfiles'=$maxfiles, 'subdirs'=$subdirs, 'sesskey'=sesskey());
$params['action'] = 'browse';
diff --git a/repository/repository_ajax.php b/repository/repository_ajax.php
index b7f76d1..f8c9fe5 100644
--- a/repository/repository_ajax.php
+++ b/repository/repository_ajax.php
@@ -87,11 +87,8 @@ $coursemaxbytes = 0;
if (!empty($course)) {
$coursemaxbytes = $course-maxbytes;
}
-$moodle_maxbytes = get_max_upload_file_size($CFG-maxbytes, $coursemaxbytes);
-// to prevent maxbytes greater than moodle maxbytes setting
-if (($maxbytes = 0) || ($maxbytes = $moodle_maxbytes)) {
-$maxbytes = $moodle_maxbytes;
-}
+// Make sure maxbytes passed is within site filesize limits.
+$maxbytes = get_max_upload_file_size($CFG-maxbytes, $coursemaxbytes, $maxbytes);
/// Wait as long as it takes for this script to finish
set_time_limit(0);
--
Bug#695423: unblock: cups/1.5.3-2.9
Le mardi, 25 décembre 2012 21.45:41, Julien Cristau a écrit : On Fri, Dec 7, 2012 at 22:31:33 +0100, Didier Raboud wrote: Please unblock package cups (…) Questions: Hi Julien, thanks for this review! - what does mv /etc/cups/cupsd.conf /etc/cups/cupsd.conf.conffile-bak in preinst achieve? In versions prior to 1.5.3-2.7, /etc/cups/cupsd.conf is a conffile, registered as such by dpkg. So in a normal upgrading case, the file would either be dropped (if never modified) or marked obsolete (if ever modified). As we want neither, moving it away before the dpkg unpack (making this file unnoticed to dpkg) and reinstating it after the unpack (in postinst for normal cases and postrm abort-upgrade in case something fails) makes /etc/cups/cupsd.conf a non-dpkg-conffile without having it marked as obsolete (which is irrelevant for that file). Granted, /etc/cups/cupsd.conf should not be in /etc/ but in /var/lib/, but that would be the subject for another intrusive patch (and upstream apparently plans to do that change in a not-too-distant future). - in cups-dbus-utf8.patch, I'm wondering if the if (str_len buflen) check isn't off-by-one? To be honest, I don't really know. As I read the code (and the surrounding comments), making it off-by-one puts the buffer size on the safe side (aka always at least as large as the input string). Actually, one more: the validate_utf8 thing uses en_US.UTF-8, which may or may not exist. You might want to use C.UTF-8 instead, which is in our libc since 2.13. Good catch! I'll upload a new cups 1.5.3-2.11 with that fix. What is the good way to Depend on libc 2.13 across all our architectures ? Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#695423: unblock: cups/1.5.3-2.9
Le vendredi, 28 décembre 2012 10.27:32, Julien Cristau a écrit : Well, it's at least as large as the input string, but potentially with no space for the terminating nul character, AIUI. Good catch! I'll upload a new cups 1.5.3-2.11 with that fix. What is the good way to Depend on libc 2.13 across all our architectures ? Depends: libc-bin (= 2.13). Uploaded 1.5.3-2.11 with your requested changes, thanks again for your review! OdyX signature.asc Description: This is a digitally signed message part.
Bug#692791: #692791: CVE-2012-5519 Security update towards Squeeze ?
Le jeudi, 27 décembre 2012 20.43:12, Moritz Mühlenhoff a écrit : AFAICS can there haven't been any regressions, can we should go ahead with the update now. EPARSE Didier, can you upload to security-master, please? The release targetted to Wheezy has just been reviewed in #695423, I'll upload the updated fix to security-master in the next few hours. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695423: unblock: cups/1.5.3-2.9
Control: retitle -1 unblock: cups/1.5.3-2.11.1 Le vendredi, 28 décembre 2012 14.39:36, Didier 'OdyX' Raboud a écrit : Le vendredi, 28 décembre 2012 10.27:32, Julien Cristau a écrit : Well, it's at least as large as the input string, but potentially with no space for the terminating nul character, AIUI. Good catch! I'll upload a new cups 1.5.3-2.11 with that fix. What is the good way to Depend on libc 2.13 across all our architectures ? Depends: libc-bin (= 2.13). Uploaded 1.5.3-2.11 with your requested changes, thanks again for your review! Actually, 1.5.3-2.11 was a broken upload (shame on me), I re-uploaded 1.5.3-2.11.1 without the spurious patch file. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#692791: #692791: CVE-2012-5519 Security update towards Squeeze ?
Le vendredi, 28 décembre 2012 19.39:33, Moritz Mühlenhoff a écrit : On Fri, Dec 28, 2012 at 06:40:29PM +0100, Didier 'OdyX' Raboud wrote: Le jeudi, 27 décembre 2012 20.43:12, Moritz Mühlenhoff a écrit : AFAICS can there haven't been any regressions, can we should go ahead with the update now. EPARSE I meant: No regressions in sid - We can proceed with stable Uploaded to unembargoed as 1.4.4-7+squeeze2. The code is on http://anonscm.debian.org/gitweb/?p=pkg- cups/cups.git;a=shortlog;h=refs/heads/master-squeeze Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#697270: PC 32-bit programs fails to work on amd64
Le jeudi, 3 janvier 2013 18.44:59, Alexey Eromenko a écrit : But having 32-bit LSB compliance will help people a _LOT_. By the way: * Debian is not LSB-certified * ... but the lsb-* packages try to provide a working implementation. No work has been attempted to provide Multi-Arch lsb packages (besides lsb- release and lsb-base being Architecture: foreign). Patches are welcome to make Wheezy+1 more suitable to your needs. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697860: Inclusion of German man page update for Wheezy possible?
Hi Helge, Le jeudi, 10 janvier 2013 17.06:12, Helge Kreutzmann a écrit : Hello Didier, I just received the latest cups (1.5.3-2.12) on my main testing machine. In the changelog for 1.5.3-2.7 you write: * Update translations for new manpage, install it. Sorry, I apparently messed that up: the emergency was to get this security release out of the door and the patch was quite extensive. What I meant by update translations was hand-edit the obvious things I could unfuzzy in the pofiles, such as dates and filenames and make sure the french manpages were correct. Unfortunately I never recieved your call for an translation update from you :-(( Could you check that you've recoreded the correct e-mail adress for me? Also you could CC debian-l10n-german@l.d.o just in case then someone will jump in if I'm no reacting. I haven't sent any call for translation updates, so it's not a problem of mail addresses. :=) I just updated the German man page translation (cf. #697860). Especially since this is a security issue it would be *very* great if you could add it to Wheezy. I'll see what I can do there, but the freeze policy is very clear there, unfortunately: http://release.debian.org/wheezy/freeze_policy.html Apparently I managed to unfuzzy the french translations, so I'll go talk to the release team, to see if we can get that trough. Cheers, and thanks for the heads up! OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703508: texttopdf should be also available as a standalone application
Control: tags -1 +upstream Hi Ivan, and thanks for your bugreport, Le mercredi, 20 mars 2013 13.34:09, Ivan Shmakov a écrit : Now that both GNU a2ps and GNU Enscript are no longer actively maintained, and have as of yet unresolved issues with their integration into the modern Debian GNU system (such as: proper UTF-8 and Fontconfig support), the ‘texttopdf’ filter (as provided by the cups-filters package) seems virtually the only sensible way to perform “plain text” to PDF conversion. Therefore, my suggestion would be to perform whatever minor modifications necessary to make ‘texttopdf’ also available as a stand-alone (as in: /usr/bin) program, and provide some documentation (such as a manual page.) This looks like a worthwhile suggestion, but is more of upstream realm. Till: what do you think ? Would it be possible to have a separate texttopdf binary and have cups-filters have only a symlink / wrapper around it as filter? Cheers, OdyX -- OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704635: [Wheezy] Package authentication issue during base installation: BusyBox
Control: reassign -1 debootstrap 1.0.47 Control: forcemerge 703889 -1 Hi Andreas, and thanks for your bugreport. Le mercredi, 3 avril 2013 21.45:43, Andreas Meile a écrit : During the setup of a Debian Box (hardware: IBM NetVista A40 model 6840-QDG, 512 MB RAM, Promise Fastrak TX2300 SATA RAID and two Western Digital Caviar Red NAS 2 TB SATA hard drives configured as RAID-1 on it = dmraid=yes option at CD boot. Installation done using mini.iso and mirror.switch.ch as FTP source) I get a Apr 3 18:32:02 in-target: WARNING: The following packages cannot be authenticated! Apr 3 18:32:02 in-target: busybox Apr 3 18:32:02 in-target: E: There are problems and -y was used without --force-yes Apr 3 18:32:03 base-installer: error: exiting on error base-installer/kernel/failed-package-install This looks like a duplicate of 703889, merging as such. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704285: release-notes: Debian doesn't support LSB 3.2
Hi all, Le vendredi, 5 avril 2013 15.02:39, Julien Cristau a écrit : cc:ing the lsb maintainer Thanks for the explicit CC. On Sun, Mar 31, 2013 at 01:22:59 -0700, Jonathan Nieder wrote: If I understand the lsb packaging correctly, Debian aims at support for LSB 4.1 these days instead of LSB 3.2. That's correct. The packages created by src:lsb try to achieve that support. Note that Debian is not (has not and I doubt it will eventually be) LSB- certified. More importantly, the Linux Standard Base Desktop Specification (both version 3.2 or 4.1) says: The libraries listed in Table 3-1 shall be available on a Linux Standard Base - Desktop system, with the specified runtime names. [...] libqt-mtlibqt-mt.so.3 but wheezy does not include that library. That's correct. This has been documented in lsb-desktop NEWS entry for the 4.1+Debian7 version (attached): From its 4.1+Debian7 version on, lsb-desktop doesn't depend on Qt3 anymore. This is an explicit and Debian-specific derogation from the LSB 4.1 specification. Then the README.Debian points to snapshot.debian.org. Index: whats-new.dbk === --- whats-new.dbk (révision 9650) +++ whats-new.dbk (copie de travail) @@ -362,7 +362,10 @@ /programlisting para -Debian still supports Linux Standard Base (acronymLSB/acronym) version 3.2. +Debian supports Linux Standard Base (acronymLSB/acronym) version 4.1. +It also supports most Linux Standard Base Desktop 4.1 interfaces, with +the exception that instead of including both Qt 3 and Qt 4, it only +includes Qt 4. indextermprimaryLinux Standard Base/primary/indexterm /para I would phrase it as the carefully-thought NEWS entry above: Debian supports Linux Standard Base (acronymLSB/acronym) version 4.1, with one explicit and Debian-specific derogation from the acronymLSB/acronym 4.1 specification: Qt3 is not included; see the lsb-desktop README file. What do you think ? Didier, care to ack/nak? ACK-but. :-) Cheers, OdyX NEWS.Debian.gz Description: GNU Zip compressed data signature.asc Description: This is a digitally signed message part.
Bug#684128: failure to communicate
Hi Thomas, Le vendredi, 5 avril 2013 17.52:19, Thomas Goirand a écrit : On 04/05/2013 07:59 PM, Dmitrijs Ledkovs wrote: And all of these features will only land for the next cycle with a release in ~= 2 years time. I really hope that it wont be the case. That it doesn't go into Debian 7.0.0, I would understand, but at least, we need it for a point release. Are you seriously arguing in favour of pushing a behavioural change into a stable point release? I doubt the stable release team would accept that, but I'm not under their hats. And at least, we need things written in the release notes about it, if not a message in the installer itself (Christian, don't kill me... ;). I disagree. It has worked that way for a long time (and many releases in that timeframe), so it is probably not that broken. I'm not saying the bug isn't valid of course, just that it's severity is IMHO correct. Could we stop the winning and have this bug fixed please, or the patch rejected (with a valid motivation)? Could we stop the useless bikeshedding and have Wheezy released please? The patch doesn't need rejection: it is a valid patch for a valid bug. It just affects d-i, which is quite an important piece of software for sane Debian releases. As you know, d-i is critically low on manpower. You want that bug fixed? Great: test the patch, document your tests, upload to experimental with the patch, gather feedback, get involved, etc. For a fix to land in Wheezy, this should have happened 8 months ago. Now is the time to release Wheezy, not the time to add cosmetic and disruptive fixes to it. (And again, I think the changes are probably worthwhile, it's only the timing which is wrong.) OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697868: Gnome installability vs. GNU/kFreeBSD
Le mardi, 9 avril 2013 19.29:23, Steven Chamberlain a écrit : During wheezy development, GNOME 3 was so broken for us that xfce was chosen as a default for new installs. Multiple show-stopper issues got fixed during the freeze though. At this point I believe it 'should work' but so few people have probably tried a full GNU/kFreeBSD Wheezy GNOME desktop yet, and neither have I... I just did (in kvm/qemu) and the result isn't great (for Gnome): - lightdm + xfce just works for what I could test. - gdm3 … doesn't finish loading. It fullscreen-says Oops, an error occured. - lightdm + Gnome: same. - lightdm + Gnome classic: same. I can provide logs and file bugs if it helps. OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705211: RM: cinder 2012.2.3-1 -- ROM; (because Cinder 2013.1 has been uploaded to Experimental)
Hi Thomas, Le jeudi, 11 avril 2013 12.55:37, Thomas Goirand a écrit : Please remove Cinder 2012.2.3-1 (code name Folsom) from SID. Reasons: - I have uploaded Cinder 2013.1 (code name Grizzly) in Experimental. - There is no Keystone 2012.2.x available anymore to support Cinder from Grizzly, since Keystone is now in version 2013.1 in Experimental. - It shows on the list of templates for the i18n-english team, and that is annoying them. Then why don't you upload Cinder 2013.1 to unstable? OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695500: d-i-n-i: #695500 Works locally at least
Hi all, I can reliably test that the layout of files in debian-installer-netboot- images' debian-installer-7.0-netboot-kfreebsd-amd64 is functional locally using kvm: $ kvm -m 256 -net nic -net user,bootfile=/grub2pxe,tftp=/usr/lib/debian-installer/images/7.0/kfreebsd-amd64/gtk/ (and s/gtk/text/ of course works too.. ) I think this bug should be reassigned to either debian-installer if that's a problem of the layout of files within kfreebsd-* netboot, or the respective PXE servers that fail to work with the layout as it is, but it really appears to be a configuration problem rather than something fixable on d-i's side. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698060: cups fails to recognize brother HL-2040 usb printer
Control: severity -1 important Control: tags -1 +moreinfo Hi Mark, and thanks for your bugreport! Le dimanche, 13 janvier 2013 17.54:35, mark anderson a écrit : I did a complete wipe and install with Wheezy and cups doesn't recognize nor auto-install my Brother HL-2040. I did a complete wipe and install with Squeeze and it worked great (although it configured as a HL-2060). I hope that wasn't confusing, the printer auto configures under Squeeze but not Wheezy. Wheezy/cups never sees the printer. Can you send to the bug the result of the following commands ? $ ls -la /usr/lib/cups/backend /usr/lib/cups/backend-available/ Thanks in advance, cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698060: HL-2040 more info
Hi mark, I just tested, I can successfully detect and setup my HP printer over USB here: it's therefor not a universal problem and will likely stay important. Le dimanche, 13 janvier 2013 19.03:01, mark anderson a écrit : OdyX-- Thanks for your very quick response. $ /bin/ls -al /usr/lib/cups/backend … -r-xr--r-- 2 root root 30096 Dec 30 08:10 usb $ /bin/ls -al /usr/lib/cups/backend-available/ … -r-xr--r-- 2 root root 30096 Dec 30 08:10 usb Sounds sane enough. Can you now run # /usr/lib/cups/backend/usb as root and paste the result in the bugreport? Thanks in advance, cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640939: Please test solution for Kerberos problem
Hi Wolfgang, and thanks for your testing and investigation so far;
Le lundi, 10 décembre 2012 20.23:36, Wolfgang Schweer a écrit :
[ cups source package 1.5.3-2.9, debian/cups.postinst ]
The attached patch seems to work for me. Please test it (as outlined in
message #49 by Brian).
-h localhost was changed to -h /var/run/cups/cups.sock a while ago
(15 Sep 2009: cups.postinst and init script).
Don't know if changing it back for cups.postinst would cause any
problem -- my tests revealed none so far.
I am far from confident enough in this patch to apply it so late in the
freeze. So I reported the bug upstream: http://www.cups.org/str.php?L4140
As you have a working test-case, could you possibly:
- test cups from unstable with the attached patch on top;
- test cups from experimental (1.6.1) ?
(If you prefer, I can provide you binary builds of cups for amd64/i386 with
the patch if that's easier for you…)
Thanks in advance, cheers,
OdyX
--
OdyX
--- a/scheduler/client.c
+++ b/scheduler/client.c
@@ -2588,14 +2588,7 @@
con-http.hostname);
#ifdef HAVE_GSSAPI
else if (auth_type == CUPSD_AUTH_NEGOTIATE)
-{
-# ifdef AF_LOCAL
- if (_httpAddrFamily(con-http.hostaddr) == AF_LOCAL)
-strlcpy(auth_str, Basic realm=\CUPS\, sizeof(auth_str));
- else
-# endif /* AF_LOCAL */
strlcpy(auth_str, Negotiate, sizeof(auth_str));
-}
#endif /* HAVE_GSSAPI */
if (con-best auth_type != CUPSD_AUTH_NEGOTIATE
Bug#697598: pu: package cups/1.4.4-7+squeeze3
Le dimanche, 13 janvier 2013 18.51:36, Adam D. Barratt a écrit : Control: tags -1 + confirmed On Sat, 2013-01-12 at 17:52 +0100, Didier 'OdyX' Raboud wrote: Le samedi, 12 janvier 2013 16.07:45, Adam D. Barratt a écrit : On Mon, 2013-01-07 at 14:37 +0100, Didier Raboud wrote: As a followup to DSA-2600-1, I'd like to fix the bug left open by this security update: the manpage for cups-files.conf was not included in cups, see #697543. The security team (and I do agree) doesn't see an emergency in solving that trough a security upload (see #697543#20 ), so here I am with a proposed-updates request. Please go ahead; thanks. Actually, I'd like additionally include both: - the fix for #697860 (update german manpage translation) - a small french manpage translation update Please go ahead; thanks. Uploaded, thanks. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640939: Please test solution for Kerberos problem
Le lundi, 14 janvier 2013 14.36:31, Wolfgang Schweer a écrit : On Mon, Jan 14, 2013 at 08:18:46AM +0100, Didier 'OdyX' Raboud wrote: I am far from confident enough in this patch to apply it so late in the freeze. So I reported the bug upstream: http://www.cups.org/str.php?L4140 As you have a working test-case, could you possibly: - test cups from unstable with the attached patch on top; - test cups from experimental (1.6.1) ? With your patch applied to the version in unstable, dpkg-buildpackage would hang (on arch amd64). IMO this is due to a minor error in your patch. Using the attached one, building succeded and -- at least for my test cases -- the reported failure doesn't occure. Hrm weird; both patches are afaik correct. Anyway, given your report, I will probably upload a new version for this serious issue as soon as the actual version would have migrated to Wheezy. Many thanks for your investigation time and dedication! Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698060:
Hi mark, Le lundi, 14 janvier 2013 06.12:06, mark anderson a écrit : Not that I know what I'm doing, but I installed it anyway and tried the localhost:631 thing but didn't see any difference. Please run cupsctl --debug-logging to enable debug logging and then provide the output of lpinfo -v and a copy of the /var/log/cups/error_log file Cheers, OdyX [0] Shamelessly copied verbatim from https://www.cups.org/str.php?L4177 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697598: pu: package cups/1.4.4-7+squeeze3
Le lundi, 14 janvier 2013 23.12:05, Adam D. Barratt a écrit : That debdiff is horrible. :-( (I realise much of it is noise with line numbers in the files changing.) Yeah, sorry for that. The patch contains po files which get changed over time, creating unreadable diffs-of-diffs. I could have added a new patch but it doesn't make much sense. For Jessie I'm considering putting the verbatim po files in debian/whateva and handle symlinks with the patch, easing diff's reading. Slightly easing these situations, I hope Flagged for acceptance; thanks. Thank you. OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698284: usb-modeswitch-data: ttyUSB* rule should have SYMLINK+= not SYMLINK=
Control: tags -1 upstream
Le mercredi, 16 janvier 2013 09.53:26, John Hedges a écrit :
Symlinks created by local rules for ttyUSB devices are lost because of the
following rule in /lib/udev/rules.d/40-usb_modeswitch.rules
KERNEL==ttyUSB*, ATTRS{bNumConfigurations}==*, PROGRAM=usb_modeswitch
--symlink-name %p %s{idVendor} %s{idProduct} %E{PRODUCT}, SYMLINK=%c
Chould it be changed to SYMLINK+=%c ?
As I don't have a definite opinion on that, let's see what upstream thinks.
Josh: what's your opinion ?
Cheers,
OdyX
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698245: unblock: moodle/2.2.3.dfsg-2.6~wheezy2
Control: retitle -1 tpu: package moodle/2.2.3.dfsg-2.6~wheezy2 (CC'ing the security team for information) Hi Thomasz, and thanks for this upload proposal, Le mardi, 15 janvier 2013 22.35:54, Tomasz Muras a écrit : Please unblock package moodle I am about to get new version of the package uploaded to testing-proposed-updates. The new version fixes a security issues from upstream release. I will sponsor this upload once and if it gets accepted by the release team. diff -Nru moodle-2.2.3.dfsg/debian/changelog moodle-2.2.3.dfsg/debian/changelog --- moodle-2.2.3.dfsg/debian/changelog2012-12-31 18:26:26.0 +0100 +++ moodle-2.2.3.dfsg/debian/changelog2013-01-15 22:29:57.0 +0100 @@ -1,3 +1,17 @@ +moodle (2.2.3.dfsg-2.6~wheezy2) testing-proposed-updates; urgency=low + + * Backport security issues from upstream Moodle 2.2.7. +* MSA-13-0009: MDL-37467 - blog posts available via RSS after blogging disabled +* MSA-13-0007: MDL-36600 - course message sending CSRF +* MSA-13-0001: MDL-37283 - lack of sanitization for google spellchecker +* MSA-13-0003: MDL-36977 - moodle backup paths not validated properly +* MSA-13-0002: MDL-27619 - teachers can set outcomes to be standard when re-editing +* MSA-13-0004: MDL-33340 - activity report showing lastaccess even if field hidden +* MSA-13-0008: MDL-36620 - guest users can access RSS feed for site level blogs +* MSA-13-0005: MDL-35991 - open redirect issues + + -- Tomasz Muras nexor1...@gmail.com Tue, 15 Jan 2013 20:43:50 +0100 + Please include the CVEs in the changelog entry, as done for the latest entry: they are important for security problems tracking. They are available in the mail I forwarded to you in private. (CVE-2012-6098 to CVE-2012-6106). Please also prepare an update of Moodle 2.2.6+ for unstable to ensure that unstable gets the fixes targetted for Wheezy too. As unstable already diverged from the wheezy version, I think updating the unstable packaging to the latest 2.2 version is safe. I will also sponsor this version (after review, of course). Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698413: usb-modeswitch-data: Huawei e3276 no longer switched
Hi Stefano, and thanks for your bugreport, Le vendredi, 18 janvier 2013 09.42:44, Stefano Rivera a écrit : With 20120815-2, the Huawei e3276 is successfully switched and provides a /dev/ttyUSB0. With 20121109-1, it doesn't. $ lsusb | grep Huawei Bus 001 Device 054: ID 12d1:14fe Huawei Technologies Co., Ltd. That's very weird as 20120815-2 and 20121109-1 have the exact same configuration file for 12d1:14fe : aptitude download usb-modeswitch-data=20120815-2 dpkg -x usb-modeswitch-data_20120815-2_all.deb um-unstable aptitude download usb-modeswitch-data=20121109-1 dpkg -x usb-modeswitch-data_20121109-1_all.deb um-experimental tar xzf um-unstable/usr/share/usb_modeswitch/configPack.tar.gz 12d1:14fe mv 12d1\:14fe 12d1\:14fe.unstable tar xzf um-experimental/usr/share/usb_modeswitch/configPack.tar.gz 12d1:14fe diff -Naur 12d1\:14fe 12d1\:14fe.unstable = No difference. Indeed, 20120815-2 got 20121109-1 changes backported. So: are you sure these are the only packages you changed ? Did you also upgrade usb-modeswitch itself? Does this still happen if you launch # udevadm trigger between installations of usb-modeswitch-data? Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#698413: usb-modeswitch-data: Huawei e3276 no longer switched
Le vendredi, 18 janvier 2013 10.38:11, Stefano Rivera a écrit :
Hi Didier (2013.01.18_11:01:29_+0200)
That's very weird as 20120815-2 and 20121109-1 have the exact same
configuration file for 12d1:14fe :
Yeah, I found it fairly confusing too.
Well, just reminded that there is another difference:
-# Special treat for IF 3
-ATTRS{bInterfaceNumber}==03, ATTRS{bInterfaceClass}==08,
ATTRS{idVendor}==19d2, ATTRS{idProduct}==2000, GOTO=modeswitch_rules_begin
-ATTRS{bInterfaceNumber}==03, ATTRS{bInterfaceClass}==08,
ATTRS{idVendor}==16d8, ATTRS{idProduct}==6803, GOTO=modeswitch_rules_begin
-# Most known install partitions are on interface 0, two on 3, one on 9
-ATTRS{bInterfaceNumber}!=0[09], GOTO=modeswitch_rules_end
+# Don't continue on change event, prevent trigger by changed configuration
+ACTION!=add, GOTO=modeswitch_rules_end
(…)
# T-Mobile NL (Huawei E352)
-ATTRS{idVendor}==12d1, ATTRS{idProduct}==14fe, RUN+=usb_modeswitch
'%b/%k'
+ATTR{idVendor}==12d1, ATTR{idProduct}==14fe, RUN+=usb_modeswitch '%b/%k'
How do I go about debugging usb_modeswitch_dispatcher?
You can use the usb_modeswitch.tcl file from the usb-modeswitch source, install
a valid tclsh and put it as usb_modeswitch_dispatcher in /usr/sbin , then you
can debug its tcl.
An easier first step is enabling EnableLogging in /etc/usb_modeswitch.conf and
send the /var/log/* resulting file to the buglog where Josua will parse it for
you. :-)
Cheers,
OdyX
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698413: usb-modeswitch-data: Huawei e3276 no longer switched
Control: tags -1 +pending Le samedi, 19 janvier 2013 13.06:08, Stefano Rivera a écrit : Hi Josua (2013.01.19_13:15:14_+0200) You need usb-modeswitch 1.2.5 for the new udev rule flavour of data 20121109. I think I failed to stress that requirement - sorry! The head information in the rules file is obviously incorrect. Should read: # Use with USB_ModeSwitch = 1.2.5 ! And the Depends/Breaks should be adjusted appropriately. Ha yeah, right. I have pushed the fix to the packaging repository. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#698245: unblock: moodle/2.2.3.dfsg-2.6~wheezy2
Hi Tomasz, Le samedi, 19 janvier 2013 14.37:39, Tomasz Muras a écrit : CVE numbers added, new changelog entry copied below for your convenience. MSA-13-0001 has no CVE assigned. Newest package available at: dget http://dev.agilesparkle.com/moodle_2.2.3.dfsg-2.6~wheezy2.dsc Seems good to me; now waiting on the release team's opinion Please also prepare an update of Moodle 2.2.6+ for unstable to ensure that unstable gets the fixes targetted for Wheezy too. As unstable already diverged from the wheezy version, I think updating the unstable packaging to the latest 2.2 version is safe. I will also sponsor this version (after review, of course). I want to move to the latest 2.4 in unstable, I'm just waiting for wheezy to be released to continue packaging work. I needed 2.2 in stable only because the upgrade path is 1.9 - 2.2 - 2.4. Well… The policy is to have unstable at least as well supported security-wise as testing, so we need a latest 2.2 (or a 2.2 with backports of the fixes proposed for t-p-u) approximatively in sync with the t-p-u upload; ideally before. That said, I can prepare the 2.2 upload to unstable if you want, but I think it's a git merge away. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#698615: lp ignores silly options; should give error
Control: forwarded -1 https://cups.org/str.php?L4261 Control: tags -1 +confirmed Hi Trent, Le lundi, 21 janvier 2013 07.37:17, Trent W. Buck a écrit : While dealing with an unrelated issue, I tried to type date | lp -n2 -o collate=true but instead I typed date | lp -n2 --collate=true AFAICT, lp silently ignored the bogus option. I would strongly prefer that it instead gave an error like this, possibly followed by a help synopsis of valid options. lp: illegal option -- - In this case, because I didn't notice the typo, I ended up wasting a couple of hours trying to debug the pxlmono.ppd that (I thought) wasn't working as advertised :-( I have confirmed this behaviour and forwarded to upstream, thanks! Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698615: lp ignores silly options; should give error
Control: tags -1 +patch +fixed-upstream Le lundi, 21 janvier 2013 09.30:51, Didier 'OdyX' Raboud a écrit : I have confirmed this behaviour and forwarded to upstream, thanks! It's now fixed already, here's the proposed patch: https://www.cups.org/strfiles/4261/str4261.patch I'll see if that's worth backporting to the next 1.6 upload towards experimental, not tagging pending yet. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697970: cups: printing gets wrong after some pages on Epson Stylus Photo 750
Hi Denis, Le mardi, 22 janvier 2013 21.23:46, Denis Prost a écrit : sorry if this is a little out of topic but, after thinking over it, I just wondered why it would not be fixed during wheezy frozen state, since it's a bug (printer does not work properly, and normal users should not be expected to know the lpadmin command that fixes it). The description you give makes this bug at most important (so below RC severity), see the bugs severity descriptions [0], because cups still works for most people. Or maybe you mean that it is not a critical bug that prevents wheezy from being released, but it will be fixed later during wheezy life cycle ? Don't care about answering that message if you think the printing team is going to do it. Well, there's no real printing team voice, but as I'm currently maintaining cups, I'll answer. :) What we have now is a workaround, not a patch, so it's not something we can just add to cups and have it fixed for everyone. I have pinged the Ubuntu cups maintainer (who happens to have a lot more experience with these issues) to see if we could have a patch applicable to cups. That said, once we have a patch (probably in the backend/usb-libusb.c quirks list), I would be opting to include it in Wheezy, but it would still need to pass the Release Team's review. They are currently struggling with way too much Release-Critical bugs and even if that patch make Wheezy better, it wouldn't be a step towards releasing Wheezy, so I can't promise it'll make it. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703677: lsb-release is not derivative friendly
Control: tags -1 +confirmed
Hi Raphaël, and thanks for your bugreport,
Le vendredi, 22 mars 2013 09.11:20, Raphaël Hertzog a écrit :
A Debian derivative is advised to fork base-files and to update the
information there so that it can be properly distinguished from Debian.
That's what we did for Kali and yet we have reportbug sending bug
reports to Debian:
$ reportbug apt
[...]
Will send report to Debian (per lsb_release).
So I looked at lsb-release's output:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux Kali Linux 1.0
Release: Kali Linux 1.0
Codename: n/a
You're saying that the wrong line is Distributor ID (the output of
lsb_release -i), right ?
It's just wrong to return Debian as distributor ID when we have
this:
(…)
Agreed.
So please update lsb_release's logic to use:
1/ /etc/lsb-release if it exists (it doesn't usually)
2/ /etc/os-release if it exists
3/ /etc/dpkg/origins/default if none of the above exist
4/ some wild guess based on APT otherwise
Please let me know if you need help.
From what I can see in the code, the current logic is the following:
1/ /etc/lsb-release - get_lsb_information()
2/ 'Debian' - guess_debian_release()
Indeed, guess_debian_release has:
distinfo = {'ID' : 'Debian'}
That said, /etc/os-release is not used anywhere in lsb(-release) yet, so I'm
open to implement 3/ /etc/dpkg/origins/default parsing for now, but would
rather avoid parsing os-release only for ID (but help is welcome). Also, I'm
yet to see an advantage for apt parsing where dpkg origins are already
supposed to provide the correct information (as derivatives are supposed to
fork base-files anyway).
I'll see if I can get a patch for 3/ /etc/dpkg/origins/default parsing soon,
but I welcome help there too.
Cheers,
OdyX
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677795: Several packaging related errors
Hi all, I just stumbled upon this release-critical bug, #677795. As I read it, the package had several packaging-related issues summing up to that serious bug, filed two weeks before the freeze. Since then, in September, a package supposedly fixing these issues has been uploaded and queued in NEW [0]; it hasn't been liberated from NEW yet. From here, I see three ways forward: a) a new package enters unstable, and then Wheezy, but that seems unlikely; b) midgard2-core and php5-midgard2 are removed from Wheezy, thereby removing the RC bug. c) that bug either gets downgraded to non-RC severity, or tagged wheezy-ignore by the release team. As I think the concerns originally leading to the severity of that bug are correct, I would rather be of the opinion to drop the two packages. Release team: what's your opinion ? Cheers, OdyX [0] http://ftp-master.debian.org/new/midgard2-core_10.05.7.1-2.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703146: Better debootstrap InRelease handling fix
Le mercredi, 27 mars 2013 12.59:15, Benjamin Cama a écrit : attached version fix both problems (and is based on latest master, after Julien disabled InRelease support). Please not that it will still print what's _before_ the BEGIN header, if present (there shouldn't be anything, but if you really want to be picky…) Well, yes, we want to be picky: the whole point of checking the signature is to avoid letting unsigned content be considered valid by debootstrap / apt / etc. See CVE-2013-1051. That said, I think I would prefer a gpgv patch to only output verified content than such sed hackery (although nice). Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703146: debootstrap patch disabling InRelease handling
Hi Julien, FYI, I have tested the patch disabling InRelease handling as pushed to debootstrap's git in two situations: * standard package; debootstrap a wheezy chroot: OK * d-i environment (built mini.iso, installed debootstrap-udeb in it): OK Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698245: unblock: moodle/2.2.3.dfsg-2.6~wheezy2
Hi Thomas, and thanks for this package, sorry for my misguided mail earlier, apparently yours just missed my inbox. Le lundi, 28 janvier 2013 18.38:49, Tomasz Muras a écrit : The package for unstable is available at: dget http://dev.agilesparkle.com/moodle_2.2.7.dfsg-1.dsc Please review upload to unstable. It contains all upstream fixes + CURL issue patch. One important thing: this is not Moodle 2.2.7. That's the weekly release of Moodle 2.2, released after 2.2.7. So the version is IMHO wrong and should instead be something like 2.2.7+20130125.dfsg-1 . Even if I usually try to stick to released tarballs, in the specific case of Moodle I'm fine with relasing weekly snapshots, but they must be versionned correctly. Other than that, the package looks good to me, besides the usual- but-not-worse-than-before embedded libraries such as TinyMCE (3.4.9, tiny_mce.js, tiny_mce_popup.js and tiny_mce_src.js), HTMLPurifier.php and YUI (3.4.1). So please just re-issue a correctly-versionned Debian package and I'll upload it to unstable (then we'll take a look at the package for testing-proposed- updates). OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697970: closed by Didier Raboud o...@debian.org (Bug#697970: fixed in cups 1.5.3-2.15)
Control: found -1 1.5.3-2.15 Le vendredi, 1 mars 2013 12.30:05, Denis Prost a écrit : Unfortunately, the problem is still there : here is what I did : 1) reset options : since the new unstable release is supposed to fix the problem, no need to keep them : lpadmin -p Stylus_Photo_750 -R usb-unidir-default lpadmin -p Stylus_Photo_750 -R usb-no-reattach-default 2) apt-get install cups/unstable = cups is upgraded to 1.5.3-2.15 with its dependencies and restarted 3) switch off and on the printer 4) try to print = first job (one page) OK, second job (one page) fails the same way it used to with previous cups release and no special lpadmin option Okay. That's exactly what I was afraid of: picking the wrong option. Does this fix it ? lpadmin -p Stylus_Photo_750 -o usb-no-reattach-default=true (it should…) Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702248: Non-optimal boot priority/dependency of service 'cups'
Control: tags -1 +wontfix Hi Mark, and thanks for this bugreport, Le lundi, 4 mars 2013 14.31:43, Marco Gaiarin a écrit : To permit an effective management of the printer queue, i've setup in /etc/cups/cups-files.conf a line like: SystemGroup printops where 'printops' is a group in my LDAP setup (slapd, libnss/libpam-ldapd). This is a valid (partial, see below) configuration change indeed. Every time i reboot a server, cups complain in error_log about: E [25/Feb/2013:18:24:28 +0100] Unknown SystemGroup printops on line 17 of /etc/cups/cups-files.conf. and start in an ''half-working'' way, eg daemon run but does not work; i have to restart cups to get it back. So, i think that cups service have to boot-depend on slapd/nslcd services. I think that as you modified the cups configuration through /etc/cups/cups- files.conf to change the default cups SystemGroup (which is local), you ought to as well modify /etc/init.d/cups to add a slapd/nslcd mention in the Should- Start line. So in short, I think it's your responsibility to make cups start after the services you made it depend on, therefor hereby tagging wontfix. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702227: Permission of the backend too strict for a backend chain (beh, jasmine)
Control: tags -1 +moreinfo Hi Mark, thanks for your bugreport. Le lundi, 4 mars 2013 11.12:31, Marco Gaiarin a écrit : If i need to chain some backend, eg because i need the Backend Error Handler (beh, in the package 'foomatic-filters') or the 'jasmine' backend (http://jasmine.berlios.de/dokuwiki/doku.php, non packaged) i've found that the second backend cannot be launched. Seems to me that cups drop privilege running the first backend as user 'lp', but some of the backend (eg, ipp) are set as 750 root.root, so cannot get executed. As far as I can tell, all chained configurations that go through cups are working correctly, so that's definitely a minor issue for standard use cases. I hope that this things can be fixed, or at least explained a bit in a README.Debian. @Till: do you have an opinion on this bug ? I tend to think that as the default chaining through cups works, it's not worth fixing, but I'd welcome your input there. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702248: Non-optimal boot priority/dependency of service 'cups'
Control: tags -1 +patch Hi Roger, Le lundi, 4 mars 2013 21.29:26, Roger Leigh a écrit : Why can't we add Should-Start: xxx to the init script here? One-line patch attached. This seems like a reasonable request, there are no dependency loops, and the init system can cater for this need, so why should this not just work by default? It's just a one line change to the init script. The concern I have with adding this is that it makes the cups init script start after nslcd/slapd also in the default configuration, for unneeded reasons. Trying to cope with all possible configuration changes feels like opening the can of worms. So, I stand to my general let's not try to cope with the world of change possibilities offered to the admin but will apply this change to cups 1.6.1+ in experimental. For users of other suites, /etc/init.d/cups is a configuration file, one can apply the attached patch directly. Cheers, OdyX From a05144e0895eecd7b71907c5b36e9eb8fcc01f07 Mon Sep 17 00:00:00 2001 From: Didier Raboud o...@debian.org Date: Tue, 5 Mar 2013 18:18:39 +0100 Subject: [PATCH] Add slapd and nslcd to cups' Should-Start LSB headers Closes: #702248 --- debian/cups-daemon.cups.init |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/cups-daemon.cups.init b/debian/cups-daemon.cups.init index 89ceebe..ded2fde 100644 --- a/debian/cups-daemon.cups.init +++ b/debian/cups-daemon.cups.init @@ -3,7 +3,7 @@ # Provides: cups # Required-Start:$syslog $remote_fs # Required-Stop: $syslog $remote_fs -# Should-Start: $network avahi +# Should-Start: $network avahi slapd nslcd # Should-Stop: $network # X-Start-Before:samba # X-Stop-After: samba -- 1.7.10.4
Bug#532097: #532097: cups RFA - RFH
Control: retitle -1 RFH: cups --Common UNIX Printing System Hi, With my entry in the Maintainers' field of cups, the handling of both the Ubuntu sync and the 1.6.1 release pushed to experimental and some help in bugs triaging (hi Brian!), I think I can reasonably claim that cups is now properly maintained in Debian. But, as the task is still quite big (and involves various other packages in the printing stack), I'd still welcome some more help from people wanting to make printing a working feature in Debian; I'm therefore hereby making this a Request for Help. Thanks for your attention, Didier Raboud, aka OdyX signature.asc Description: This is a digitally signed message part.
Bug#532097: #532097: cups RFA - RFH
Hi Bastien, Le samedi, 9 mars 2013 14.17:27, Bastien ROUCARIES a écrit : I will step on it. Please coule web have a debian todo list and how to ? Great, thanks for the offer. All that we have as far as I'm concerned are: a) http://wiki.debian.org/Teams/Printing (mostly outdated) I have just updated it rapidly, to match the reality a little more. It would need more love and cleaning, feel free to give a hand there. and b) http://bugs.debian.org/src:cups http://bugs.debian.org/debian-print...@lists.debian.org of course. Unfortunately we have many unanswered bugs laying around: verifying if they are still valid under more up-to-date Debian+cups configurations would be very useful. Personnally i will like to have cups drop root Although I find it unfortunate, I think that both Martin Pitt's [0] and upstream's [1] explanations make it sufficiently clear that engaging on such a road is a promise for _lot_ of work. Furthermore, that would be work not supported by upstream in any foreseeable future ot by any other distribution out there. [0] http://bugs.debian.org/692791#86 [1] http://bugs.debian.org/692791#61 So unless other distributions join that long-term effort of maintaining a whole load of patches against cups, I would oppose such an effort. But, I very much welcome any (and yours, of course) help in coping with the bugreports (past and new) and the next cups releases. I very much welcome bugreports with patches attached. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#702227: Permission of the backend too strict for a backend chain (beh, jasmine)
Control: tags -1 +wontfix -moreinfo Hi Marco, Le mercredi, 6 mars 2013 17.37:12, Marco Gaiarin a écrit : As far as I can tell, all chained configurations that go through cups are working correctly, so that's definitely a minor issue for standard use cases. Ok for 'jasmine', but 'beh' is a rather ''standard'' backend, that i use extensively for some ''broken'' printers or print servers... very useful if you don't want to be called on saturday morning at home... Is 'beh' not working correctly when used as printer backend? gaio@eraldo:~$ ls -la /usr/lib/cups/backend/ipp -rwxr--r-- 3 root root 43328 15 gen 04.08 /usr/lib/cups/backend/ipp 744 root.root? It really brake the CUPS security model to have it root.lp, 754 (or 750)? Probably i don't know CUPS (and indeed it is true ;), but i don't understood why the 'lp' group have to not execute the backend... while for example the 'socket' backend: gaio@eraldo:~$ ls -la /usr/lib/cups/backend/socket -r-xr-xr-x 2 root root 29988 15 gen 04.08 /usr/lib/cups/backend/socket it is even executable by everyone? Quoting Till on that one: 13:59 tkamppeter OdyX, about Debian bug 702227, CUPS backends with 750 root.root permissions/ownerships are run as root by CUPS, these backends have to run as root as they need access to resources where only root has access (files, network resources). Opening up the permissions so that lp can run the backends makes the backends stop working. What alwyas works would be setting the wrapper backends 750 root.root, but this can lead to some non-root backends being run as root. (…) but seems to me that simply backend permission is a mess... ;-))) I can't disagree with that. As far as I can read that bug: i) running backends not as root will likely break some working behaviours; ii) apparently a non-standard backend, not even in Debian doesn't work in that situation. So, as I would rather not try to fix something not broken for most standard Debian uses, and as I haven't been convinced that fixing that is an improvement over the current situation, I'm hereby tagging this bug as wontfix. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697970: closed by Didier Raboud o...@debian.org (Bug#697970: fixed in cups 1.5.3-2.15)
H Denis, Ping? ;) Le vendredi, 1 mars 2013 20.01:02, Didier 'OdyX' Raboud a écrit : Does this fix it ? lpadmin -p Stylus_Photo_750 -o usb-no-reattach-default=true Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#698245: unblock: moodle/2.2.3.dfsg-2.6~wheezy2
Hi Thomas, hi Release Team, hi Moodle maintainers. Le jeudi, 28 février 2013 18.00:19, Didier 'OdyX' Raboud a écrit : So please just re-issue a correctly-versionned Debian package and I'll upload it to unstable (then we'll take a look at the package for testing-proposed- updates). Given that: a) we fail at releasing Moodle updates to unstable in a timely manner (and I have my share of the fault here); b) we consequently fail at releasing Moodle security updates to wheezy in a timely manner (this unblock is opened for almost two months); c) Moodle 2.2 is already not supported anymore by Moodle HQ for anything (not even security), according to [0]; Furthermore on that point, as far as I can see, there is noone taking responsibility to handle Moodle 2.2 security on the long term (Moodle in Wheezy will need to be security-handled for roughly three years, yet it is _already_ not supported). d) there is (in my opinion) not enough people behind the maintenance of Moodle-in-Debian: Thomas is a good DM, but he's mostly alone, and I'm not willing to get more involved. So as much as I find that unfortunate, I think that the best solution for all of Moodle, Moodle-in-Debian and Debian, is to not ship Moodle 2.2 in Wheezy. Thomasz, as you're the actual de-facto maintainer, please voice your opinion as I have voiced mine: the decision is in the hands of the Release Team I guess. Cheers OdyX signature.asc Description: This is a digitally signed message part.
