Bug#764935:
Hi, Package has only been published for i386, but the the backtrace clearly indicates an amd64 executable. IMHO this issue should be reopened. Cheers, NicolaF -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663200: [Pkg-shadow-devel] Bug#663200: Bug#628843: Bug#659878: cannot set terminal process group (-1): Inappropriate ioctl for device
Hi, On Tue, Aug 27, 2013 at 11:43:59AM +0200, lk...@essax.com wrote: First, I'm sorry that it took me now nearly three month to finish because always when I have the impression having time left it turns the opposite. I can't blame you here... I created a branch (su-C_tty) starting with the patch from Wolfgang Zarre (comment 141 in #628843). Thanks! You are welcome! The branch is on svn.debian.org ? There's been a switch to git in the mean time. You can find the repo on github: https://github.com/shadow-maint/shadow There is one thing I don't understand (let's start with this one): When I execute a command with su –c command, it does not react to SIGTSTP (either from Ctrl-Z or kill -SIGTSTP). It works OK when I execute a shell. Is this behavior expected? What is the reason? Actually it's not expected however, there where issues as mentioned in #156 but was targeting more the issues as mentioned above to switch correct the parent's tty between cooked and raw mode. A short test was showing now that this is really not working as expected and I'll try to investigate and rework the patch accordingly. Thanks for your time. Best Regards, -- Nekral -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663200: Bug#628843: Bug#659878: cannot set terminal process group (-1): Inappropriate ioctl for device
Hello, I created a branch (su-C_tty) starting with the patch from Wolfgang Zarre (comment 141 in #628843). Thanks! It seems to be the only way to fix this issue, even if it means I have to maintain something I'm not confident with. There is one thing I don't understand (let's start with this one): When I execute a command with su –c command, it does not react to SIGTSTP (either from Ctrl-Z or kill -SIGTSTP). It works OK when I execute a shell. Is this behavior expected? What is the reason? Thanks in advance, -- Nekral -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628843: Ping
Hello, On Sun, Oct 16, 2011 at 05:20:31PM +0200, bubu...@debian.org wrote: Quoting Arne Wichmann (a...@anhrefn.saar.de): This critical bug is now pending for more than 3 months. Is there any update on the situation? Nicolas should actually release upstream 4.1.5 and then upload 4.1.5-1. Nicolas? Yes, this is the plan. There are still some untested changes, and I still have a few uncommitted changes on my tree. Regarding this bug * Arne, I do not know if your ping was related to the potential security impact, but it could help to have an assessment of the proposed solution (and also comment 46) * It did not seem that critical to me (e.g. in the pointed comp.security.oss.general thread, there were no agreement for a CVE) -- Nekral -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628843: [Pkg-shadow-devel] Bug#628843: Bug#628843: (forw) Bug#628843: login: tty hijacking possible in su via TIOCSTI ioctl
Hello,
One more point to be reviewed.
shadow-utils supports also configurations where PAM is not used.
In that case, su does not fork to exec the interactive shell / command, so
I cannot use setsid().
In that case, I intend to use:
#include termios.h
#include sys/ioctl.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h
int fd;
if ((fd = open (/dev/tty, O_RDWR)) = 0) {
ioctl (fd, TIOCNOTTY, (char *) 0);
close (fd);
}
I think this should be sufficient to protect the terminal (i.e.
re-attaching to it is not possible). This looks simpler than:
pid_t child = fork();
if (child == -1) {
...
} else if (child 0) {
_exit(0);
}
setsid();
(In this version I would need again to handle the signals manually instead
of the _exit())
Also if the above ioctl is sufficient, is there a benefit from setsid()?
Best Regards,
--
Nekral
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628843: login: tty hijacking possible in su via TIOCSTI ioctl
Hello,
Here is a patch proposal. It forwards the right signal to the child also
supports SIGTSTP.
I would appreciate if this could be reviewed by somebody more confident
with signal processing than me.
I expect sudo to have the same issue.
Also sg probably has the same issue (i.e. it cannot be used to drop group
privileges). I will look at it.
Other utils to switch user or group might also be affected.
(Anybody got a list and could try?)
Best Regards,
--
Nekral
Index: src/su.c
===
--- src/su.c (révision 3317)
+++ src/su.c (copie de travail)
@@ -88,7 +88,7 @@
#ifdef USE_PAM
static pam_handle_t *pamh = NULL;
-static bool caught = false;
+static int caught = 0;
/* PID of the child, in case it needs to be killed */
static pid_t pid_child = 0;
#endif
@@ -235,9 +235,9 @@
#ifdef USE_PAM
/* Signal handler for parent process later */
-static void catch_signals (unused int sig)
+static void catch_signals (int sig)
{
- caught = true;
+ caught = sig;
}
/* This I ripped out of su.c from sh-utils after the Mandrake pam patch
@@ -264,6 +264,11 @@
if (doshell) {
(void) shell (shellstr, (char *) args[0], envp);
} else {
+ /* There is no need for a controlling terminal.
+ * This avoids the callee to inject commands on
+ * the caller's tty. */
+ (void) setsid ();
+
execve_shell (shellstr, (char **) args, envp);
}
@@ -283,9 +288,9 @@
(void) fprintf (stderr,
_(%s: signal malfunction\n),
Prog);
- caught = true;
+ caught = SIGTERM;
}
- if (!caught) {
+ if (0 == caught) {
struct sigaction action;
action.sa_handler = catch_signals;
@@ -296,36 +301,66 @@
if ( (sigaddset (ourset, SIGTERM) != 0)
|| (sigaddset (ourset, SIGALRM) != 0)
|| (sigaction (SIGTERM, action, NULL) != 0)
+ || ( !doshell /* handle SIGINT (Ctrl-C), SIGQUIT
+ * (Ctrl-\), and SIGTSTP (Ctrl-Z)
+ * since the child does not control
+ * the tty anymore.
+ */
+ ( (sigaddset (ourset, SIGINT) != 0)
+ || (sigaddset (ourset, SIGQUIT) != 0)
+ || (sigaddset (ourset, SIGTSTP) != 0)
+ || (sigaction (SIGINT, action, NULL) != 0)
+ || (sigaction (SIGQUIT, action, NULL) != 0))
+ || (sigaction (SIGTSTP, action, NULL) != 0))
|| (sigprocmask (SIG_UNBLOCK, ourset, NULL) != 0)
) {
fprintf (stderr,
_(%s: signal masking malfunction\n),
Prog);
- caught = true;
+ caught = SIGTERM;
}
}
- if (!caught) {
+ if (0 == caught) {
+ bool stop = true;
+
do {
pid_t pid;
+ stop = true;
pid = waitpid (-1, status, WUNTRACED);
- if (((pid_t)-1 != pid) (0 != WIFSTOPPED (status))) {
+ /* When interrupted by signal, the signal will be
+ * forwarded to the child, and termination will be
+ * forced later.
+ */
+ if ( ((pid_t)-1 == pid)
+ (EINTR == errno)
+ (SIGTSTP == caught)) {
+/* Except for SIGTSTP, which request to
+ * stop the child.
+ * We will SIGSTOP ourself on the next
+ * waitpid round.
+ */
+kill (child, SIGSTOP);
+stop = false;
+ } else if ( ((pid_t)-1 != pid)
+ (0 != WIFSTOPPED (status))) {
/* The child (shell) was suspended.
* Suspend su. */
kill (getpid (), SIGSTOP);
/* wake child when resumed */
kill (pid, SIGCONT);
+stop = false;
}
- } while (0 != WIFSTOPPED (status));
+ } while (!stop);
}
- if (caught) {
+ if (0 != caught) {
(void) fputs (\n, stderr);
(void) fputs (_(Session terminated, terminating shell...),
stderr);
- (void) kill (child, SIGTERM);
+ (void) kill (child, caught);
}
ret = pam_close_session (pamh, 0);
@@ -339,7 +374,7 @@
ret = pam_end (pamh, PAM_SUCCESS);
- if (caught) {
+ if (0 != caught) {
(void) signal (SIGALRM, kill_child);
(void) alarm (2);
Bug#571027: Patch for this file conflict bug...
Hello, On Fri, Mar 19, 2010 at 05:54:56AM -0500, jrnie...@gmail.com wrote: I think a Replaces should be good enough. After all, this doesn’t actually break the old sysv-rc version. Would something like this work? Using unversioned Replaces like this is only appropriate if we know that sysv-rc should not overwrite any files from manpages-fr-extra in squeeze or squeeze+1. I suspect we do know that. Yes, it should be a Replace, but a versionned one would be better as the best solution would be to have the manpages distributed in the sysv-rc package. -- Nekral -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565927: [Pkg-shadow-devel] Bug#565927: Debian Linux 5.0
Hello, On Wed, Jan 20, 2010 at 11:19:17AM -0500, pink...@tampabay.rr.com wrote: Don't see anything obvious except attempt to login as root: rejected. Can you cut paste the whole /var/log/auth.log line. I cannot find the string attempt to login neither in shadow not PAM, which should be the one rejecting the login. Do you have any special PAM module, any configuration that would differ from a normal install? Don't use PAM. You probably do. Do you have a /etc/pam.d/login file? Could you send it? Also, which ISO image did you use for the install? Best Regards, -- Nekral -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565927: [Pkg-shadow-devel] Bug#565927: Debian Linux 5.0
notfound 565927 5.0 found 565927 1:4.1.1-6 thanks Hello, On Tue, Jan 19, 2010 at 01:55:28PM -0500, pink...@tampabay.rr.com wrote: I have but one problem. I installed the 5.0 from the internet CD. Everything appears right and it boots to an X screen to login. The problem is I can not login as root, even at the console. I did answer Do you want ROOT to login at console - YES. I can login as someone else, su to root, but many items are very difficult, if not impossible to use without an X version of the utility and quite a number, you MUST be ROOT to use them. This is not sufficient for me to reproduce your issue. It is quite common that root is rejected by X login. But, you should be able to login on the console. Can you check your /var/log/auth.log or /var/log/syslog for any reasons for the rejection of the login? Can you provide the result of sudo chage -l root Do you have any special PAM module, any configuration that would differ from a normal install? Can you check the result of: getent passwd root sudo getent shadow root Do not put the result of these 2 commands in your reply. They may contain your root's password. Best Regards, -- Nekral -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558814: virtaal: inner markup is unprotected and can be broken
# This does not make the package unusable, virtaal can still be used to # translate. severity 558814 normal thanks Hello, On Mon, Nov 30, 2009 at 08:16:13PM +0100, adrp...@yahoo.fr wrote: I'm trying virtaal on a sample XLIFF file. Extract : trans-unit id=Paragraph-57 sourceL'implémentation de cet exemple est visualisable g id=Hyperlink-58ici/g /source targetL'implémentation de cet exemple est visualisable g id=Hyperlink-58ici/g /target /trans-unit Unfortunately I can break the g inline tag when I fill in the target translation. I'm trying to attach a screenshot. I don't know if it is a not-yet-implemented feature or a stoper bug. I'm not sure I understand the problem correctly. A translator can always break the translation. I don't think it would be useful for the translators to restrict what they can type in the msgstr field. For this there are some quality checks, implemented for example in pofilters (I don't remember if these quality checks were integrated in virtaal, but those quality checks differ from the feature of editing the translation). I would propose to close this bug or to change it a wishlist bug so that the quality checks are better integrated in virtaal. Best Regards, -- Nekral -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526033: Subject: manpages-tr and login: error when trying to install together
reassign 526033 manpages-tr reassign 526036 manpages-tr merge 526033 526036 tags 526033 patch thanks manpages-tr already contains a list of manpages to be pruned. I don't really know when the support for this list was broken, but here is a fix. Best Regards, -- Nekral diff -rauN ../orig/manpages-tr-1.0.5.1/debian/rules ./manpages-tr-1.0.5.1/debian/rules --- ../orig/manpages-tr-1.0.5.1/debian/rules 2009-05-09 20:56:00.0 +0200 +++ ./manpages-tr-1.0.5.1/debian/rules 2009-05-09 21:16:14.138326848 +0200 @@ -82,10 +82,7 @@ grep -v '^#' debian/manpages-tr.prune | while read exists crap; do \ exists=`echo $$exists | \ sed -e 's,usr/share/man/tr\.[^/]\+,usr/share/man/tr,'`;\ - test -f `pwd`/debian/manpages-tr/$$exists || \ - test -L `pwd`/debian/manpages-tr/$$exists \ - rm -f `pwd`/debian/manpages-tr/$$exists || \ - true; \ + rm -f `pwd`/debian/manpages-tr/$$exists.gz; \ done dh_movefiles --sourcedir=debian/manpages-tr dh_installdocs
Bug#525209: Layout messed up in daily images
tags 525209 pending thanks On Thu, Apr 23, 2009 at 08:23:29AM +0200, bubu...@debian.org wrote: Quoting Nicolas François (nicolas.franc...@centraliens.net): If somebody knows how to test it in a daily image, please do (I don't know how to do this). [...] That should give you a mini.iso image in build/dest Thanks. I could test the patch on a virtualbox and committed an updated version. With the patch committed, I could make a complete install without noticing any glitches in the installer screen. Best Regards, -- Nekral -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525209: Layout messed up in daily images
On Thu, Apr 23, 2009 at 12:32:28AM +0200, elen...@planet.nl wrote:
This is almost certainly a result of the cdebconf changes committed by
Nicolas François (CCed).
Yes.
It looks like I assumed there were no Go Back button in those case.
Here is a patch.
I tested it just a little bit. It seems to solve the issue without
re-introducing the previous issue.
If somebody knows how to test it in a daily image, please do (I don't know
how to do this).
If urgent, somebody can commit it and upload.
Otherwise, I will try to test it more this week-end.
Best Regards,
--
Nekral
Index: src/modules/frontend/newt/newt.c
===
--- src/modules/frontend/newt/newt.c (révision 58334)
+++ src/modules/frontend/newt/newt.c (copie de travail)
@@ -777,13 +777,15 @@
t_height = newtTextboxGetNumLines(textbox);
newtTextboxSetHeight(textbox, t_height);
newtFormAddComponent(form, textbox);
-b_height = 0; // A Go Back button is not necessary
select_list_top = 1+t_height+1;
} else {
t_height = 0;
-b_height = 1;
select_list_top = 1; // No description. Only insert a blank line.
}
+if (obj-methods.can_go_back(obj, q))
+b_height = 1;
+else
+b_height = 0;
free(full_description);
win_height = t_height + sel_height + b_height;
//3 == First blank line + blanks before and after select
Bug#524139: login: tty perms very, weirdly wrong on console
Hello, Thank you all for noticing, investigating and providing patches. I will provide a new upstream release and Debian package tonight. Best Regards, -- Nekral -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#505271: [Pkg-shadow-devel] Bug#505271: closed by Nicolas FRANCOIS (Nekral) nicolas.franc...@centraliens.net (Bug#505271: fixed in shadow 1:4.0.18.1-7+etch1)
On Tue, Feb 10, 2009 at 09:19:20AM +1100, p...@maths.usyd.edu.au wrote: Dear Nicolas, This latest closed message: is that a repeat message, a bug in some maintenance procedures? I am sure we had 4.0.18.1-7+etch1 for a long time now... I have no idea what triggered this second email (first closure for stable was on 01-060) Best Regards, -- Nekral -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#505271: Bug#505071: login tty mis-determination (see bug#332198)
On Mon, Dec 08, 2008 at 09:37:42AM +1100, [EMAIL PROTECTED] wrote:
The bug should affect ubuntu and probably gentoo (4.1.2.2 already
packaged). Not RedHat / Mandrake.
A quick peek into shadow-utils-4.1.2-8.fc10.src.rpm suggests Fedora is
also affected. I do not know about RHEL.
shadow-utils.spec:rm $RPM_BUILD_ROOT/%{_bindir}/login
makes me think Fedora / RHEL should be free of login's bugs.
--
Nekral
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#505271: Bug#505071: login tty mis-determination (see bug#332198)
On Mon, Dec 08, 2008 at 08:20:36AM +1100, [EMAIL PROTECTED] wrote: Dear Nicolas, On 23 Nov you wrote: - alert other Linux distros, A new upstream version was released this weekend. Have not seen any distros make announcements. What distros use that? (Am surprised that even Ubuntu has not updated, though normally they seem responsive.) The bug should affect ubuntu and probably gentoo (4.1.2.2 already packaged). Not RedHat / Mandrake. I don't know about other distros. I don't know if ubuntu supervises the bug tagged 'security', and I don't know their milestones. Best Regards, -- Nekral -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#505271: Bug#505071: login tty mis-determination (see bug#332198)
Hello,
On Mon, Nov 24, 2008 at 08:01:42AM +1100, [EMAIL PROTECTED] wrote:
Seems your message relates to old things, Nicolas has fixed this for
lenny already.
I've made an upload to fix #505271, but not this bug (#505071).
The answer on debian-release was not enough for me to also fix #505071.
Please also:
- fix for etch,
I made an upload for Etch (-7etch1, also to fix #505271)
Moritz, if you can't see it, maybe I did it wrong.
- alert other Linux distros,
A new upstream version was released this weekend.
It also contains a fix for this bug (#505071).
I attach this patch in case it is considered OK and needed for Lenny.
- issue DSA.
This will be done by the Security Team when the Etch package will be ready
on all archs.
Best Regards,
--
Nekral
Index: 4.1.2.2/libmisc/chowntty.c
===
--- 4.1.2.2/libmisc/chowntty.c (révision 2449)
+++ 4.1.2.2/libmisc/chowntty.c (révision 2459)
@@ -44,29 +44,12 @@
#include pwd.h
#include getdef.h
/*
- * is_my_tty -- determine if tty is the same as TTY stdin is using
- */
-static int is_my_tty (const char *tty)
-{
- struct stat by_name, by_fd;
-
- if (stat (tty, by_name) || fstat (0, by_fd))
- return 0;
-
- if (by_name.st_rdev != by_fd.st_rdev)
- return 0;
- else
- return 1;
-}
-
-/*
* chown_tty() sets the login tty to be owned by the new user ID
* with TTYPERM modes
*/
-void chown_tty (const char *tty, const struct passwd *info)
+void chown_tty (const struct passwd *info)
{
- char buf[200], full_tty[200];
char *group; /* TTY group name or number */
struct group *grent;
gid_t gid;
@@ -90,24 +73,11 @@
* the group as determined above.
*/
- if (*tty != '/') {
- snprintf (full_tty, sizeof full_tty, /dev/%s, tty);
- tty = full_tty;
- }
-
- if (!is_my_tty (tty)) {
- SYSLOG ((LOG_WARN,
- unable to determine TTY name, got %s\n, tty));
- closelog ();
- exit (1);
- }
-
if (fchown (STDIN_FILENO, info-pw_uid, gid) ||
fchmod (STDIN_FILENO, getdef_num (TTYPERM, 0600))) {
int err = errno;
- snprintf (buf, sizeof buf, _(Unable to change tty stdin));
- perror (buf);
+ perror (_(Unable to change tty stdin));
SYSLOG ((LOG_WARN,
unable to change tty stdin for user `%s'\n,
info-pw_name));
Index: 4.1.2.2/libmisc/utmp.c
===
--- 4.1.2.2/libmisc/utmp.c (révision 2449)
+++ 4.1.2.2/libmisc/utmp.c (révision 2459)
@@ -57,6 +57,30 @@
_(Unable to determine your tty name.)
/*
+ * is_my_tty -- determine if tty is the same TTY stdin is using
+ */
+static int is_my_tty (const char *tty)
+{
+ char full_tty[200];
+ struct stat by_name, by_fd;
+
+ if ('/' != *tty) {
+ snprintf (full_tty, sizeof full_tty, /dev/%s, tty);
+ tty = full_tty;
+ }
+
+ if ((stat (tty, by_name) != 0) || (fstat (STDIN_FILENO, by_fd) != 0)) {
+ return 0;
+ }
+
+ if (by_name.st_rdev != by_fd.st_rdev) {
+ return 0;
+ } else {
+ return 1;
+ }
+}
+
+/*
* checkutmp - see if utmp file is correct for this process
*
* System V is very picky about the contents of the utmp file
@@ -84,7 +108,8 @@
while ((ut = getutent ()))
if (ut-ut_pid == pid ut-ut_line[0] ut-ut_id[0]
(ut-ut_type == LOGIN_PROCESS
- || ut-ut_type == USER_PROCESS))
+ || ut-ut_type == USER_PROCESS)
+ is_my_tty (ut-ut_line))
break;
/* If there is one, just use it, otherwise create a new one. */
Index: 4.1.2.2/ChangeLog
===
--- 4.1.2.2/ChangeLog (révision 2449)
+++ 4.1.2.2/ChangeLog (révision 2459)
@@ -2,6 +2,14 @@
* NEWS, libmisc/chowntty.c: Fix a race condition that could lead
to gaining ownership or changing mode of arbitrary files.
+ * NEWS, libmisc/chowntty.c, libmisc/utmp.c: is_my_tty() moved from
+ utmp.c to chowntty.c. checkutmp() now only uses an existing utmp
+ entry if the pid matches and ut_line matches with the current tty.
+ This fixes a possible DOS when entries can be forged in the utmp
+ file.
+ * libmisc/chowntty.c, src/login.c, lib/prototypes.h: Remove the
+ tty argument from chown_tty. chown_tty always changes stdin and
+ does not need this argument anymore.
2008-06-26 Nicolas François [EMAIL PROTECTED]
Index: 4.1.2.2/src/login.c
===
--- 4.1.2.2/src/login.c (révision 2449)
+++ 4.1.2.2/src/login.c (révision 2459)
@@ -1005,7 +1005,7 @@
}
setup_limits (pwent); /* nice, ulimit etc. */
#endif/* ! USE_PAM */
- chown_tty (tty, pwent);
+ chown_tty (pwent);
#ifdef USE_PAM
/*
Index: 4.1.2.2/lib/prototypes.h
===
--- 4.1.2.2/lib/prototypes.h (révision 2449)
+++ 4.1.2.2/lib/prototypes.h (révision 2459)
@@ -73,7 +73,7 @@
extern int chown_tree (const char *, uid_t, uid_t, gid_t, gid_t);
/* chowntty.c */
-extern void chown_tty (const char *, const struct passwd *);
+extern void chown_tty (const
Bug#505271: Bug#505071: login tty mis-determination (see bug#332198)
On Sun, Nov 23, 2008 at 10:29:55PM +0100, [EMAIL PROTECTED] wrote:
On Sun, Nov 23, 2008 at 10:24:26PM +0100, Nicolas François wrote:
I made an upload for Etch (-7etch1, also to fix #505271)
Moritz, if you can't see it, maybe I did it wrong.
I don't see any trace of it on klecker? Can you please send the debdiff
to [EMAIL PROTECTED]
Here it is.
dupload --to anonymous-security shadow_4.0.18.1-7etch1_i386.changes
is still in my history, and I don't think I interrupted it.
I did not prepare anything for oldstable, but the same patch should still
apply if needed.
Best Regards,
--
Nekral
diff -u shadow-4.0.18.1/debian/patches/series
shadow-4.0.18.1/debian/patches/series
--- shadow-4.0.18.1/debian/patches/series
+++ shadow-4.0.18.1/debian/patches/series
@@ -50,0 +51 @@
+303_login_symlink_attack
diff -u shadow-4.0.18.1/debian/changelog shadow-4.0.18.1/debian/changelog
--- shadow-4.0.18.1/debian/changelog
+++ shadow-4.0.18.1/debian/changelog
@@ -1,3 +1,12 @@
+shadow (1:4.0.18.1-7etch1) stable-security; urgency=low
+
+ * The Curé nantais release
+ * debian/patches/303_login_symlink_attack: Fix a race condition that could
+lead to gaining ownership or changing mode of arbitrary files.
+Closes: #505271
+
+ -- Nicolas FRANCOIS (Nekral) [EMAIL PROTECTED] Sat, 22 Nov 2008 16:04:04
+
+
shadow (1:4.0.18.1-7) unstable; urgency=low
* The Pélardon release
only in patch2:
unchanged:
--- shadow-4.0.18.1.orig/debian/patches/303_login_symlink_attack
+++ shadow-4.0.18.1/debian/patches/303_login_symlink_attack
@@ -0,0 +1,23 @@
+Goal: Fix a symlink attack
+
+Fixes: 505271
+
+Status wrt upstream: Fixed upstream
+
+--- a/libmisc/chowntty.c
b/libmisc/chowntty.c
+@@ -119,8 +119,12 @@
+ exit (1);
+ }
+
+- if (chown (tty, info-pw_uid, gid) ||
+- chmod (tty, getdef_num (TTYPERM, 0600))) {
++ /* is_my_tty above ensure that tty is the same device as stdin.
++ * there could be a race condition between the above check, and
++ * changing the ownership/mode.
++ */
++ if (fchown (STDIN_FILENO, info-pw_uid, gid) ||
++ fchmod (STDIN_FILENO, getdef_num (TTYPERM, 0600))) {
+ int err = errno;
+
+ snprintf (buf, sizeof buf, _(Unable to change tty %s), tty);
Bug#400066: closed by Jose Luis Tallon [EMAIL PROTECTED] (Bug#400066: fixed in lcdproc 0.5.2-1)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 09 Mar 2008 00:25:50 +0100 Source: lcdproc Binary: lcdproc Architecture: source amd64 Version: 0.5.2-1 Distribution: unstable Urgency: medium Maintainer: Jose Luis Tallon [EMAIL PROTECTED] Changed-By: Jose Luis Tallon [EMAIL PROTECTED] Description: lcdproc- LCD display driver daemon and clients Closes: 400066 Changes: lcdproc (0.5.2-1) unstable; urgency=medium . * New upstream version . * Compilation issues - restrict building to just i386, amd64 (Closes: #400066) I don't think this fix is correct. You already did it before, and the bug was reopen. (just read the back log of the bug) A patch was also proposed and should be part of this new upstream release to at least support PPC (and probably all the other architectures without parallel port). As you insist, and as I'm not a user on non i386 architectures, I won't play ping pong with you. You should also contact the ftp-masters to request the removal of the binaries on the architectures that are no more supported. -- Nekral -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#478272: Corrections ...
On Mon, Apr 28, 2008 at 05:00:37PM +0200, [EMAIL PROTECTED] wrote: Thinking twice, I'm pretty sure that what was done was correct, and the french help will be removed from package passwd. Sorry for submitting that bug. No. You were right. The passwd manpage from manpages-fr-extra is the manpage for the openssl's passwd command. It should be distributed as passwd.1ssl. I will fix this tonight. -- Nekral -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473950: translate-toolkit: FTBFS: Unsatisfiable build-dependency: python(inst 2.4.4-6 ! = wanted 2.5)|python-elementtree(missing)
Hi, On Wed, Apr 02, 2008 at 12:41:52PM +0200, [EMAIL PROTECTED] wrote: During a rebuild of all packages in sid, your package failed to build on i386. Thanks a lot for all these rebuilds and analysis. Build deps on a | b are not supported by sbuild, because they would cause uncertainties in the resulting binaries. Please don't use them, and choose a single python version in your build-deps. This is explicitly allowed by policy (7.1), and is really what is needed to build the translate toolkit. The toolkit needs the ElementTree module from xml.etree (provided by python2.5) or from elementtree (provided by the python-elementtree module). The module is needed during the build to load applications and generate manpages. It will not really be used and will not cause uncertainties in the resulting binaries. This dependency permits to use the same package on Debian, Ubuntu, and backport. I will check later what I will do with this bug (it is IMO a bug in sbuild). I can imagine some solutions to fix this bug: * invert the '|' dependencies. This should bypass the bug in sbuild now, and this will have to be reverted when Debain will switch to python 2.5 * Always build with python-elementtree. This will make the package FTBFS when Debian will move to python 2.5 This will make the Ubuntu package to differ from the Debian package * Always build with python2.5 This will make the package FTBFS when Debian will move to python 2.6 This will make the backport package to differ * Do not build the manpages at build time This makes the build process non-automatic * python2.5 could Provide python-elementtree. Currently it provides python-elementtree2.5 python-elementtree and python-elementtree2.5 are not identical the import line in Python is different, so I don't think it would be correct. My preference would go to the first one (or fix sbuild). I will wait for the translate toolkit to exit the NEW queue (#472954) before uploading any changes. Best Regards, -- Nekral -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470745: [Pkg-shadow-devel] Bug#470745: passwd: usermod loops and mem leaks
tags 470745 upstream tags 470745 fixed-upstream thanks On Thu, Mar 13, 2008 at 01:30:45PM +0100, [EMAIL PROTECTED] wrote: If /etc/gshadow file has been changed so two otherwise non-identical groups apear with the same groupname, usermod will loop and use all memory on system if called. Reproducable by performing this: # groupadd tr # groupadd rtr # useradd -g tr tr # perl -pi -e 's/rtr/tr/g' /etc/gshadow # usermod -G tr tr observe usermod using memory and proc time Tested and reproduced on latest (4.0r3) netinst iso image and updated with all packages. Thanks for reporting it. This is currently fixed in the upstream repository. The last usermod call will raise an error and request the /etc/gshadow file to be cleaned with grpck: Multiple entries named 'tr' in /etc/gshadow. Please fix this with pwck or grpck. usermod: error adding new shadow group entry I still need a few weeks (2?) before the next upstream release to prepare a snapshot and call for translations. I don't think this bug is that critical. I doesn't cause any corruption, and it occurs only in case of configuration errors, which do not appear if the administrators use the recommended tools for user/group administration. Thus I will not issue a fix for this bug. Also, I don't think it is worth doing a update for Etch. Any other opinions? Best Regards, -- Nekral -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429160: po4a: po4a-gettextize is vulnerable to symlink attacks in /tmp
Hello Jens, On Mon, Sep 24, 2007 at 03:59:00PM +0200, [EMAIL PROTECTED] wrote: Hi! On Sat, Jun 16, 2007 at 02:15:13AM +0200, Javier Fernández-Sanguino Peña wrote: Package: po4a Version: 0.29-1 Severity: grave Tags: security patch If you run po4a-gettextize on contents that do not get converted to PO files due to some issue, the script will dump its results in /tmp/gettextization.failed.po. The script uses a file in the /tmp diretory but does not try to prevent a symlink attack. A malicious user could create a symlink named liked that in the temporary directory and pointing to one of the user's files so that when a user runs po4-gettextize (and fails) the file the symlink pointed to would get overwritten. The fix is, IMHO, simple: just dump the results in the local directory, don't use /tmp at all (it is, after all, unnecesary). The attached patch to /usr/share/perl5/Locale/Po4a/Po.pm fixes this issue. I don't want to reopen this bug but why is it OK to omit /tmp? The code is still vulnerable. Just assume po4a is started in /tmp or in another directory where an attcker has write access and the problem remains ... It is quite common to write in a predefined file of the current firectory (e.g. gcc if you do not specify an output file, generated files by automake autoconf, ...) The risk is IMO only present when the command may eventually be run as root. The goal is hence to reduce the risk to the case where the command create the file and is run by root. Also, the file is rarely used (only created by po4a-gettextize when run (interractively) to reuse an existing translation, and when this process fails). I don't expect this use case to occur without the system being at much greater risk (i.e. the user only uses the root account). (Moreover, it would not be possible to create a safe temporary file without a possible race condition in the po4a use case.) I agree that it is unlikely but I often work in /tmp to handle translations ... Unless you are doing so as root, I don't think there is a risk to continue doing it. Cheers, -- Nekral
Bug#439827: Patch 65-dfa-optional.patch causes grep regressions
tags 439827 patch tags 439827 -upstream thanks Hello, The regressions in grep 2.5.3~dfsg-1 are caused by patch 65-dfa-optional.patch. It should be removed. As it was used in combination to 64-egf-speedup.patch (which was already removed) to speed up grep in UTF-8 environments, the resulting grep should be slow again (#181378 is back) I will try to have a look at whether these two patches can be re-introduced next week or later. By that time, I recommend to remove patch 65-dfa-optional.patch. Best Regards, -- Nekral -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439827: Patch 65-dfa-optional.patch causes grep regressions
On Wed, Sep 05, 2007 at 03:45:50PM -0400, Justin Pryzby wrote: tag 439931 - confirmed thanks (I don't understand why you un-confirm 439931; it looks like a valid and reproducible bug to me) Hello, did you see #439931 too? I did not check, but I guess that re-adding the old 64-egf-speedup.patch should fix it. Also patches 66-match_icase.patch and 67-w.patch should be considered. These patches tend to be quite long and hard to maintain. I did not check if they apply cleanly or not, or even if they were already applied upstream (based on the result of the test suite, I'm just guessing that they may still be needed). Kind Regards, -- Nekral -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439226: CVE-2007-4462: arbitrary files overwriting
Hello, On Fri, Aug 31, 2007 at 05:39:47PM +0200, Moritz Muehlenhoff wrote: Which enduser tools use the affected code and which operations trigger the vulnerability? Given that there's apparently no regularly scheduled execution (e.g. in comparison to a server cron job), that the .pm doesn't run with elevated privileges, that po4a is exotic and apparently uncommon in a multi user environment with shared /tmp I'm for now inclined to consider this not grave enough for a DSA. (However, this depends on the information I'm asking for) The vulnerability is a symlink attack which does not involve a race condition (the link could be installed a long time before). po4a is a development tool, used as a build dependency for some Debian packages. My opinion is that it should not be used by root. The vulnerability occurs in po4a-gettextize when it is used to import an existing translation and convert it to a PO file usable for latter operations by the po4a tools (and by translators). The file is written in /tmp only if this process fails. This usage of po4a-gettextize is intended to be interactive (with the user fixing errors reported by each runs of po4a-gettextize) in the early stage of building a translation framework. Thus I don't expect this vulnerability to occur (there should be no erros and the file should not be written) in a build system or to be triggered by admins using make make install as root with a non malicious software. If eventually this results in overwriting a file, this file will be a PO file. This will result in a DOS if /etc/shadow is overwritten. I don't expect any line matching a valid shadow entry (i.e. the first field will contain a space or will start with or #). Kind Regards, -- Nekral -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439226: CVE-2007-4462: arbitrary files overwriting
found 439226 0.20-2 found 439226 0.29-1 notfound 439226 0.31-1 thanks Hi, On Thu, Aug 23, 2007 at 02:27:03PM +0200, [EMAIL PROTECTED] wrote: Hi, A security issue has been reported against your package po4a: lib/Locale/Po4a/Po.pm in po4a before 0.32 allows local users to overwrite arbitrary files via a symlink attack on the gettextization.failed.po temporary file. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4462 It seems the new upstream 0.32 fixes this. Please mention the CVE id in the changelog when fixing this. Also please check whether stable and oldstable are vulneable and coordinate with the security team. This was fixed in Debian's 0.31-1 stable and oldstable are vulnerable. The fix for this bug is quite simple: replacing $pores-write(/tmp/gettextization.failed.po); by $pores-write(gettextization.failed.po); Security Team, shall I prepare packages with this fix and upload to stable-security and oldstable-security? Kind Regards, -- Nekral -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#420332: debian-history: FTBFS: po-debiandoc build-dep does not exist anymore
tags 420332 patch thanks Hello, On Mon, Apr 23, 2007 at 12:04:09PM -0600, Bdale Garbee wrote: On Sat, 2007-04-21 at 19:12 +0200, Adeodato Simó wrote: Hi. During an archive rebuild your debian-history package failed to build because the po-debiandoc build-depend is not available any more (it's only in sarge). Anyone reading who understands the relevant technology and transitions, please feel free to suggest an appropriate alternative. Please find attached a patch to replace po-debiandoc by po4a (debian/control, Makefile). The patch contains also some other changes: * debian/control: Added build dependencies on tetex-bin and tetex-extra. * debian/control: Only debhelper is a Build-Depends, others are Build-Depends-Indep * debian/rules: Removed hardcoded list of languages (the German translation was not distributed) * debian/debian-history.doc-base.de: Added file * project-history.de.po: Updated according to the po4a's POT. 11 fuzzy strings. Kind Regards, -- Nekral debian-history_po-translations.patch.bz2 Description: Binary data
Bug#418840: Status of the belocs-locales-{bin,data} packages
Hello, There is currently a grave bug on belocs-locales-data ( #418840 belocs-locales-data: does not work with new libc). I wonder if it is worth fixing it or if the belocs packages are no more needed. They are not currently actively maintained, and IIRC, they were useful when it was very difficult to introduce new locales in the locales package (I don't think it is still the case, am I wrong?), to test new locales before submitting them to the Glibc, to have more up to date locales. Does anybody want to maintain these packages? Are there some languages which really need them? Kind Regards, -- Nekral -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413116: jamvm issues with java.util.logging
Hello Michael,
On Thu, Mar 15, 2007 at 09:35:59AM +0100, Michael Koch wrote:
Well I consider jamvm -cp Test.jar Test and jamvm -jar Test.jar not
working a major issue. If I wouldn't, we wouldn't need a fix for this.
These two are the main usecases for every Java runtime and should just
work.
I don't deny it's a bug;)
The (later) problem is caused by an exception thrown in LogManager.
jamvm do not support Exception before the end of the VM init.
I think this is a bug in jamvm, which considers it is still in the
initialization when it executes the main class (when the class comes from
a jar).
(I've not deeply investigated it, but it is probably the main thread which
is started too early, or jamvm should allow Exception even if the
initialization is not finished)
Feel free to clone and reassign the clone to jamvm.
I don't think this jamvm bug is critical.
It can be reproduced with:
=
public class Test {
public static void main(String argv[]) {
try { throw new java.lang.Exception(foo); }
catch (Exception e) { System.out.println(catched); }
}
}
=
As the original issue is solved by 0.92-4, I had a look at the diff
between 0.91-3 and 0.92-4. I don't think the upstream changes can be
backported to t-p-u.
In 0.91-3,
new URL(url).openStream();
throws an exception when url is a non existent file. And no exceptions is
thrown with 0.92-4.
The changes involve java/net/URL* and gnu/java/net/loader/* (e.g.
gnu/java/net/loader/FileURLLoader.java do not throw an exception if the
file does not exist).
I don't think it's worth reviewing the upstream diff (diffstat indicate
~2kloc for the above mentioned files; which could probably be reduced, but
need a deep understanding of what is done), and LogManager can safely test
if the file exists and fall back with a default properties file if the
file is not found (see attached patch).
I consider this part of the patch as an hack, but it is safe, and fix the
`jamvm -jar Test.jar' use case.
Kind Regards,
--
Nekral
diff -rauN ../0.91-3.orig/classpath-0.91/debian/changelog ./classpath-0.91/debian/changelog
--- ../0.91-3.orig/classpath-0.91/debian/changelog 2007-03-15 23:12:03.0 +0100
+++ ./classpath-0.91/debian/changelog 2007-03-16 01:38:37.0 +0100
@@ -1,3 +1,16 @@
+classpath (2:0.91-4) testing-proposed-updates; urgency=low
+
+ * java/util/logging/LogManager.java (readConfiguration): Explicitly test
+if the logging.properties file exists without trying to catch an
+exception. This is needed by jamvm, when it runs a jar.
+ * Merge change from upstream:
+java/util/logging/LogManager.java (getLevelProperty): Check whether value
+is null before passing to Level.parse(). This makes java.util.logging
+work.
+Closes: #413116
+
+ -- Nicolas FRANCOIS (Nekral) [EMAIL PROTECTED] Sun, 11 Mar 2007 22:59:22 +0100
+
classpath (2:0.91-3) unstable; urgency=low
* Install header files to /usr/include/classpath.
diff -rauN ../0.91-3.orig/classpath-0.91/java/util/logging/LogManager.java ./classpath-0.91/java/util/logging/LogManager.java
--- ../0.91-3.orig/classpath-0.91/java/util/logging/LogManager.java 2006-04-03 10:59:53.0 +0200
+++ ./classpath-0.91/java/util/logging/LogManager.java 2007-03-15 23:05:36.0 +0100
@@ -494,6 +494,9 @@
{
String url = (System.getProperty(gnu.classpath.home.url)
+ /logging.properties);
+
+if (new java.io.File(url).exists())
+{
try
{
inputStream = new URL(url).openStream();
@@ -502,6 +505,9 @@
{
inputStream=null;
}
+}
+else
+ inputStream=null;
// If no config file could be found use a default configuration.
if(inputStream == null)
@@ -700,7 +706,11 @@
{
try
{
- return Level.parse(getLogManager().getProperty(propertyName));
+ String value = getLogManager().getProperty(propertyName);
+ if (value != null)
+ return Level.parse(getLogManager().getProperty(propertyName));
+ else
+ return defaultValue;
}
catch (Exception ex)
{
Bug#413116: jamvm issues with java.util.logging
Hello Michael, Thanks for your investigation. I tested the patch and it doesn't fixed the isseue. I'm working on another solution for this and will then upload it to t-p-u. Can you describe the problem? I could successfully use: java -Djava.util.logging.config.file=my.properties -cp Test.jar Test or: java -Djava.util.logging.config.file=my.properties Test or: java Test but java -cp Test.jar Test fails with a FileNotFoundException. I did not consider the later as a critical issue since the user receives a warning about a missing /usr/lib/logging.properties file; and she will either create this file, or read the java.util.logging documentation and will set the java.util.logging.config.file property. If it is what is blocking you from uploading, I can prepare a patch for that. Otherwise, can you point to a failing use case? Kind Regards, -- Nekral -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413933: zorp: policy.boot cannot be found
tags 413933 patch
thanks
Hello,
With the attached patch, I could successfully start zorp (zorp_plug).
But I did not check if zorp works nicely afterwards.
Matt, can you build a zorp package with the attached patch applied, and
try the built packages (zorp, zorp-modules, libzorp2)?
The patch also fixes an FTBFS.
Thanks in advance,
--
Nekral
diff -rauN ../../orig/zorp-3.0.8/configure.in ./configure.in
--- ../../orig/zorp-3.0.8/configure.in 2005-11-03 10:14:15.0 +0100
+++ ./configure.in 2007-03-13 02:13:02.0 +0100
@@ -143,8 +143,8 @@
PYTHON=$with_python)
sysconfdir=${sysconfdir}/zorp
-#datadir='${prefix}/share/zorp'
-libdir='${prefix}/lib'
+datadir=${prefix}/share
+libdir=${prefix}/lib
dnl ***
dnl Argument processing which might affect detection
diff -rauN ../../orig/zorp-3.0.8/debian/changelog ./debian/changelog
--- ../../orig/zorp-3.0.8/debian/changelog 2006-10-10 16:10:15.0 +0200
+++ ./debian/changelog 2007-03-13 02:52:01.0 +0100
@@ -1,3 +1,15 @@
+zorp (3.0.8-0.3) unstable; urgency=low
+
+ * Non-maintainer upload to fix release critical bugs.
+ * debian/rules: Explicitly run aclocal-1.7 instead of aclocal (FTBFS with
+aclocal-1.9).
+ * configure.in: Set datadir and libdir to ${prefix}/share and ${prefix}/lib.
+This is fixed upstream in version 3.0.14b with more intrusive changes in
+the build system. Note that ./configure --datadir and --libdir won't work.
+Closes: #413933
+
+ -- Nicolas FRANCOIS (Nekral) [EMAIL PROTECTED] Tue, 13 Mar 2007 02:33:37 +0100
+
zorp (3.0.8-0.2) unstable; urgency=high
* Non-maintainer upload to fix release critical bug.
diff -rauN ../../orig/zorp-3.0.8/debian/rules ./debian/rules
--- ../../orig/zorp-3.0.8/debian/rules 2006-09-03 23:45:04.0 +0200
+++ ./debian/rules 2007-03-13 02:14:39.0 +0100
@@ -34,7 +34,7 @@
build-stamp:
dh_testdir
- aclocal
+ aclocal-1.7
AUTOMAKE=automake-1.7 autoreconf -i -f
CFLAGS=$(DTEST) ./configure $(confflags) \
--prefix=/usr \
Bug#413116: jamvm issues with java.util.logging
On Thu, Mar 08, 2007 at 12:02:50PM -0600, Bob Black wrote:
Does anyone have a logging.properties file that works with jamvm
(+ classpath)?
jamvm uses classpath's java.util.logging. I don't think it would require
any special content.
Here is an example:
== logging.properties
handlers = java.util.logging.ConsoleHandler
.level = WARNING
==
Maybe that bug was solved in another package (classpath?) or in a new
upload.
Otherwise, I either can't reproduce this bug or don't understand the
problem described in this bug: Is it that jamvm doesn't work, or just that
the java.util.logging package cannot be configured?
By default, GNU classpath looks in /usr/lib for the logging.properties
file (/usr/lib is the default value for gnu.classpath.home.url).
The logging.properties can also be specified with the
java.util.logging.config.file property:
java -Djava.util.logging.config.file=path to logging.properties ..
When there is no system wide logging.properties file, GNU classpath uses
default values (only = INFO messages are displayed on console).
This default looks good to me, and also it seems sane to require users (or
applications) to set java.util.logging.config.file if they want special
logging properties.
At one time, I've been able to have a strange behavior (the VM silently
quit, no Exception) with a given logging.properties file. But I can't
reproduce it currently (and I can't remember what was in this
logging.properties).
Any ideas? Has anyone gotten jamvm working with an app that uses
java.util.logging?
Yes, with the following app:
== Test.java =
import java.util.logging.*;
public class Test{
private static Logger logger = Logger.getLogger(Test);
public static void main(String argv[]){
logger.fine(FINE log);
logger.log(Level.WARNING,WARNING log);
logger.info(INFO log);
logger.log(Level.SEVERE,SEVERE log);
}
}
==
I compiled it with javac from jikes-sablevm (1.13-1.1).
I run it with jamvm (1.4.4-2); classpath (0.92-4). (I tried both running
it from a JAR and a .class file.)
3 persons could reproduce it (with real applications, not just this test).
So there could be an issue elsewhere.
Michel, Matthew, Bob, can you confirm that this bug still exists?
Can you try the above example? And if it works, can you also provide an
application which fails?
Your classpath's version could also be interesting.
Kind Regards,
--
Nekral
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414004: tripwire: Build failure on mips and mipsel
Package: tripwire Version: 2.3.1.2.0-8 Severity: serious Tags: patch Justification: no longer builds from source Hello, tripwire is currently not built on mips and mipsel: http://buildd.debian.org/fetch.cgi?pkg=tripwirever=2.3.1.2.0-9arch=mipsstamp=1171546290file=log http://buildd.debian.org/fetch.cgi?pkg=tripwirever=2.3.1.2.0-9arch=mipselstamp=1171546217file=log The relevant build log is: /usr/bin/sudo debian/rules binary-arch [...] /usr/bin/make install DESTDIR=/debian/tripwire [...] install -m 600 debian/twcfg.txt debian/twpol.txt /debian/tripwire//etc/tripwire install: target `/debian/tripwire//etc/tripwire' is not a directory make: *** [binary-arch] Error 1 I could reproduce it on i386 by building with 'dpkg-buildpackage -rsudo' It can be fixed by just changing PWD to CURDIR in debian/rules. Kind Regards, -- Nekral -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411027: libkwiki-perl: plugin reported as missing (perl?)
tags 411027 patch
thanks
Hi,
On Wed, Mar 07, 2007 at 06:07:20PM -0800, Steve Langasek wrote:
Could you take a look at bug #411027, filed on libkwiki-perl? Martin's
assessment is that the package is in pretty bad shape overall, and dropping
this package for etch implies dropping kwiki as well, so perhaps you'd care
to take a look at fixing up libkwiki-perl's prominent issues?
I don't know what would be the best to fix this bug:
* fix kwiki's documentation to mention that 'kwiki -new my_kwki' is not
sufficient.
* Fix libkwiki-perl so that the wiki directory created after -new is
usable.
* package kwiki2
Calling handle_update_all (or unlinking registry.dd) at the end of
handle_new in Command.pm fixes the second point.
There is still a documentation issue (Kwiki::Command only documents
-new, and mentions -update, -install, -remove, -new_view), so I leave it
up to libkwiki-perl or kwiki's maintainers to apply the patch or to drop
kwiki from Etch (and package kwiki2, which seams to have more
documentation)
PS: Also upstream recommends not to install 0.38:
http://search.cpan.org/src/INGY/Kwiki-0.39/README
(maybe it's just to promote the new Kwiki2; which will have an upgrade
path from Kwiki: http://www.kwiki.org/?UpgradingToKwiki2)
Kind Regards,
--
Nekral
diff -rauNp ../orig/libkwiki-perl-0.38/lib/Kwiki/Command.pm ./libkwiki-perl-0.38/lib/Kwiki/Command.pm
--- ../orig/libkwiki-perl-0.38/lib/Kwiki/Command.pm 2005-04-03 12:50:54.0 +0200
+++ ./libkwiki-perl-0.38/lib/Kwiki/Command.pm 2007-03-09 01:31:35.0 +0100
@@ -19,6 +19,7 @@ sub handle_new {
$self-install('widgets');
io('plugin')-mkdir;
$self-set_permissions;
+$self-handle_update_all;
warn \nKwiki software installed! Point your browser at this location.\n\n;
}
Bug#400072: museek+: FTBFS: IOError: [Errno 2] No such file or directory: 'mucipher.i':
Hi,
On Sat, Dec 02, 2006 at 06:45:27PM +0100, [EMAIL PROTECTED] wrote:
Le jeudi 30 novembre 2006 00:42, Nicolas François a écrit :
Here is a second patch (I could import mucipher nicely with this one).
It does not fix the museek+ build system directly, but fix it in
debian/rules.
As upstream seems to be willing to chnage the build system, it should not
be an issue.
Kind Regards,
--
Nekral
diff -rauN ../orig/museek+-0.1.12/debian/rules ./museek+-0.1.12/debian/rules
--- ../orig/museek+-0.1.12/debian/rules 2006-12-04 19:20:33.0 +0100
+++ ./museek+-0.1.12/debian/rules 2006-12-04 19:25:59.0 +0100
@@ -25,6 +25,12 @@
build-stamp: patch-stamp
dh_testdir
# Run configure and build with scons
+ # for the SharedLibrary command, SCons needs the sources to be
+ # in place in advance
+ # (Command(mucipher.i, ../mucipher.i, file_copy) do not do
+ # the trick)
+ mkdir -p workdir/Mucipher/python/
+ cp Mucipher/mucipher.i workdir/Mucipher/python/
scons CFLAGS=$(CFLAGS) QTDIR=/usr/share/qt3/ BUILDDIR=0
touch build-stamp
diff -rauN ../orig/museek+-0.1.12/Tools/SConscript
./museek+-0.1.12/Tools/SConscript
--- ../orig/museek+-0.1.12/Tools/SConscript 2006-05-26 21:47:57.0
+0200
+++ ./museek+-0.1.12/Tools/SConscript 2006-12-04 19:03:46.0 +0100
@@ -16,7 +16,10 @@
if env['VORBIS']:
env_libmuscan.ParseConfig('pkg-config --libs --cflags vorbisfile')
if conf.CheckLibWithHeader('', 'vorbis/vorbisfile.h', 'C++',
'ov_clear(0);'):
- env_libmuscan.Append(CPPDEFINES = {'HAVE_VORBIS': 1})
+ if env_libmuscan['CPPDEFINES'] != []:
+ env_libmuscan.Append(CPPDEFINES = {HAVE_VORBIS: 1})
+ else:
+ env_libmuscan.Replace(CPPDEFINES = {HAVE_VORBIS: 1})
print OGG Vorbis found, compiling into muscan.
else:
print OGG Vorbis NOT found, not compiled into muscan.
Bug#400066: Closing bug
reopen 400066 ! found 400066 0.5.1-2 retitle 400066 lcdproc_0.5.1-2(powerpc/unstable): FTBFS: impossible constraint in asm thanks On Sat, Dec 02, 2006 at 12:23:12AM +0100, José Luis Tallón wrote: After discussion with upstream, it was agreed that lcdproc 0.5.1 should only be allowed to compile in i386/amd64/powerpc. Hence, all FTBFS bugs for this version are not relevant anymore. Even if it FTBFS on powerpc? Here is the build log: http://buildd.debian.org/fetch.cgi?pkg=lcdproc;ver=0.5.1-2;arch=powerpc;stamp=1164740084 Kind Regards, -- Nekral
Bug#395498: vcs-tree: build should be retried on powerpc and sparc
tags 395498 unreproducible thanks Hello, I could successfully pdebuild vcs-tree on powerpc and i386 (the architecture for which the build failure was reported). So I think this FTBFS was fixed by an upload in another package, and a build of vcs-tree should be retried on powerpc and sparc. Kind Regards, -- Nekral -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400066: Closing bug
On Mon, Dec 04, 2006 at 09:34:22PM +0100, [EMAIL PROTECTED] wrote: Hmmm... I had been told by upstream that it should work on i386, amd64 and powerpc. Not having the means to test it myself, I trusted them. I will therefore have to re-upload, restricting to just x86* architectures for the time being. Upstream will be notified, too. The patch I sent still apply for the powerpc FTBFS. Was the patch rejected upstream? I don't know if these kinds of LCD screens exist on non x86 hardware, but since some of them seems to be communicating on regular serial ports, they should work on other architectures. PS: not really being an user of lcdproc, I let you and upstream choose;) Merci, Nicolas. De rien, -- Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400072: museek+: FTBFS: IOError: [Errno 2] No such file or directory: 'mucipher.i':
tags 400072 patch
thanks
Hello,
Please find attached a patch to fix the FTBFS.
I removed mucipher.i from the sources list in Mucipher/python/SConscript.
sources is used to make a SharedLibrary, and scons has no way to use it
for inclusion in a library.
This does not seems to be a source file. And the package builds cleanly
without.
In the same file, I changed the order of the arguments of file_copy to
match the Environment.Command documentation.
The change in Tools/SConscript is due to a bug in scons. I will file a bug
against scons, but for the moment, I recommend to use it (otherwise, scons
compile with -D{'HAVE_VORBIS': 1} instead of -DHAVE_VORBIS=1)
This could be fixed in other ways (e.g. by using a tupple instead of a
dictionnary: env_libmuscan.Append(CPPDEFINES = (HAVE_VORBIS, 1)), but
this behavior do not seems to be documented.
Kind Regards,
--
Nekral
diff -rauN ../orig/museek+-0.1.12/Mucipher/python/SConscript
./museek+-0.1.12/Mucipher/python/SConscript
--- ../orig/museek+-0.1.12/Mucipher/python/SConscript 2006-06-07
12:23:42.0 +0200
+++ ./museek+-0.1.12/Mucipher/python/SConscript 2006-11-29 23:51:44.0
+0100
@@ -4,11 +4,10 @@
import os
sources = Split(
- mucipher.i
wraphelp.c
)
-def file_copy(target, source, env):
+def file_copy(env, target, source):
open(str(target[0]), w).write(open(str(source[0])).read())
py_ver = str(sys.version_info[0]) + . + str(sys.version_info[1])
diff -rauN ../orig/museek+-0.1.12/Tools/SConscript
./museek+-0.1.12/Tools/SConscript
--- ../orig/museek+-0.1.12/Tools/SConscript 2006-05-26 21:47:57.0
+0200
+++ ./museek+-0.1.12/Tools/SConscript 2006-11-29 23:51:44.0 +0100
@@ -16,7 +16,10 @@
if env['VORBIS']:
env_libmuscan.ParseConfig('pkg-config --libs --cflags vorbisfile')
if conf.CheckLibWithHeader('', 'vorbis/vorbisfile.h', 'C++',
'ov_clear(0);'):
- env_libmuscan.Append(CPPDEFINES = {'HAVE_VORBIS': 1})
+ if env_libmuscan['CPPDEFINES'] != []:
+ env_libmuscan.Append(CPPDEFINES = {HAVE_VORBIS: 1})
+ else:
+ env_libmuscan.Replace(CPPDEFINES = {HAVE_VORBIS: 1})
print OGG Vorbis found, compiling into muscan.
else:
print OGG Vorbis NOT found, not compiled into muscan.
Bug#389291: dpkg FTBFS
reassign 389291 libselinux1-dev thanks On Mon, Sep 25, 2006 at 01:20:16AM -0700, Steve Langasek wrote: On Mon, Sep 25, 2006 at 01:07:47AM +0200, Nicolas François wrote: In libselinux (1.30.28-1), -lpthread was added to the libselinux's pkg-config. dpkg is statically linked against the SELinux library, thus against the libpthread, which requires some symbols from libc. Adding -lc (e.g. in m4/libs.m4) before -lpthread fixes this issue, but I'm not sure it's the right way. i.e. using: -lc -Wl,-Bstatic `pkg-config --static --libs libselinux` -Wl,-Bdynamic instead of: -Wl,-Bstatic `pkg-config --static --libs libselinux` -Wl,-Bdynamic Could you check if changing -lpthread to -pthread works? Yes, it works. Thanks. It also works with e2fsprogs, which was the original reason for the change in libselinux (#388375). Thus I'm reassigning. Manoj, can you change: Libs.private: -lthread to Libs.private: -pthread in libselinux.pc. Thanks in advance, -- Nekral
Bug#389291: dpkg FTBFS
Package: dpkg Version: 1.13.22 Severity: serious Justification: no longer builds from source Hello, Since libselinux (1.30.28-1), dpkg fails to build from source. The failing command is the following: gcc -std=gnu99 -Wall -g -O2 -Wl,-O1 -o dpkg archives.o cleanup.o configure.o depcon.o enquiry.o errors.o filesdb.o help.o main.o packages.o processarc.o remove.o select.o update.o ../lib/libdpkg.a -Wl,-Bstatic -lz -Wl,-Bdynamic -Wl,-Bstatic -lbz2 -Wl,-Bdynamic -Wl,-Bstatic -lselinux -lpthread -lsepol -Wl,-Bdynamic processarc.o: In function `process_archive': ../../src/processarc.c:166: warning: the use of `tmpnam' is dangerous, better use `mkstemp' /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../lib/libpthread.a(ptw-write.o): In function `write': stdin:(.text+0x25): undefined reference to `__syscall_error' stdin:(.text+0x55): undefined reference to `__syscall_error' /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../lib/libpthread.a(ptw-read.o): In function `read': stdin:(.text+0x25): undefined reference to `__syscall_error' stdin:(.text+0x55): undefined reference to `__syscall_error' /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../lib/libpthread.a(ptw-close.o): In function `close': stdin:(.text+0x1f): undefined reference to `__syscall_error' /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../lib/libpthread.a(ptw-close.o):stdin:(.text+0x4a): more undefined references to `__syscall_error' follow /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../lib/libpthread.a(pthread.o): In function `__pthread_reset_main_thread': /build/buildd/glibc-2.3.6.ds1/build-tree/glibc-2.3.6/linuxthreads/pthread.c:1153: undefined reference to `_errno' /build/buildd/glibc-2.3.6.ds1/build-tree/glibc-2.3.6/linuxthreads/pthread.c:1154: undefined reference to `_h_errno' /build/buildd/glibc-2.3.6.ds1/build-tree/glibc-2.3.6/linuxthreads/pthread.c:1155: undefined reference to `_res' /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../lib/libpthread.a(pthread.o): In function `pthread_initialize': /build/buildd/glibc-2.3.6.ds1/build-tree/glibc-2.3.6/linuxthreads/pthread.c:551: undefined reference to `_res' /build/buildd/glibc-2.3.6.ds1/build-tree/glibc-2.3.6/linuxthreads/pthread.c:617: undefined reference to `_dl_init_static_tls' /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../lib/libpthread.a(pthread.o): In function `__pthread_initialize_minimal': /build/buildd/glibc-2.3.6.ds1/build-tree/glibc-2.3.6/linuxthreads/pthread.c:319: undefined reference to `__libc_setup_tls' /build/buildd/glibc-2.3.6.ds1/build-tree/glibc-2.3.6/linuxthreads/pthread.c:377: undefined reference to `_errno' /build/buildd/glibc-2.3.6.ds1/build-tree/glibc-2.3.6/linuxthreads/pthread.c:378: undefined reference to `_h_errno' collect2: ld returned 1 exit status In libselinux (1.30.28-1), -lpthread was added to the libselinux's pkg-config. dpkg is statically linked against the SELinux library, thus against the libpthread, which requires some symbols from libc. Adding -lc (e.g. in m4/libs.m4) before -lpthread fixes this issue, but I'm not sure it's the right way. i.e. using: -lc -Wl,-Bstatic `pkg-config --static --libs libselinux` -Wl,-Bdynamic instead of: -Wl,-Bstatic `pkg-config --static --libs libselinux` -Wl,-Bdynamic Does anybody think it's correct? Is there a way to fix it in the libselinux's pkg-config? (I'm adding Manoj in CC in case he has an idea) Kind Regards, -- Nekral -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385044: start-stop-daemon when used with --exec and --stop should warn loudly
Hello Ryan, On Mon, Aug 28, 2006 at 10:25:54AM -0700, Ryan Murray wrote: Filing this as serious because recent security updates have been affected by this, and if we don't get some visibility on the problem soon, it will be too late to find many of the problems before etch is released. Can you point me to the package whose restart failed? When the daemon is replaced, start-stop-daemon should notice it because when readlink'ing the /proc/pid/exe file, the executable is followed by (deleted). Based on the code and on the tests I did, this seems to work nicely. Kind Regards, -- Nekral -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384631: shadow currently FTBFS
Package: shadow Version: 1:4.0.18.1-1 Severity: serious Justification: no longer builds from source Dear shadow maintainers, Since the upgrade of gettext to 0.15, shadow fails to build from source. 12:20:02 bubulle if [ -d ./m4 ]; then m4=-I m4; fi; if [ -e ./aclocal.m4 ]; then cd . aclocal-1.7 $m4; fi 12:20:05 bubulle aclocal: macro `AM_PROG_MKDIR_P' required but not defined 12:20:08 bubulle aclocal: macro `AM_PROG_MKDIR_P' required but not defined 12:20:10 bubulle make: *** [debian/stamp-autotools-files] Erreur 1 A patch is currently worked on. And the next release should be released soon. The plan is to use automake 1.9. This needs to change debian/control and the variables DEB_AUTO_UPDATE_* in debian/rules. In po/Makefile.in.in, MKINSTALLDIRS also needs to be set to @install_sh@ -d (maybe upstream should update the Makefile.in.in file in later releases. What I still don't know is whether the resulting package will depend on gettext 0.15 and automake 1.9. Kind Regards, -- Nekral -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379174: shadow: CVE-2006-3378
Hello,
On Sat, Jul 22, 2006 at 12:59:59AM +0200, Henry Jensen wrote:
I just checked the source. From there it seems that the Debian passwd
is affected by CVE-2006-3378 (USN-308-1 in Ubuntu), too.
Here is a patch for this issue (taken from the ubuntu package).
Its changelog could be:
* SECURITY UPDATE: CVE-2006-3378: Root privilege escalation.
* src/passwd.c:
- Check for failing setuid() (which can happen if user hits PAM
limits). Before, passwd continued to run as root and executed
chfn/chsh/gpasswd as root instead of as the user.
- Thanks to Sune Kloppenborg Jeppesen for pointing this out.
Please note also that (because of #356939) there are other shadow packages
being processed (which do not fix this vulnerability):
1:4.0.3-31sarge6 (in the security queue) and 1:4.0.3-31sarge7 (in the
proposed-update queue)
Security team, what should we do?
* Ask the FTP masters to drop the current 1:4.0.3-31sarge6 and
1:4.0.3-31sarge7 and upload a new 1:4.0.3-31sarge6 (with only this
security fix?, with both?)
* Upload a new 1:4.0.3-31sarge8 (where? with only this security fix?,
with both?)
Thanks in advance,
--
Nekral
Index: src/passwd.c
===
--- src/passwd.c(révision 1053)
+++ src/passwd.c(copie de travail)
@@ -958,7 +958,13 @@
if (argc 1 argv[1][0] == '-' strchr (gfs, argv[1][1])) {
char buf[200];
- setuid (getuid ());
+ uid_t uid = getuid();
+ setuid (uid);
+ if (getuid() != uid) {
+ perror(cannot set user id);
+ SYSLOG ((LOG_ERR, setuid to %i failed, uid));
+ exit(E_FAILURE);
+ }
switch (argv[1][1]) {
case 'g':
argv[1] = GPASSWD_PROGRAM; /* XXX warning: const */
Bug#377395: dpkg: FTBFS on mips
Package: dpkg Version: 1.13.22 Severity: serious Justification: no longer builds from source Hello, dpkg currently fails to build from source on mips, which stops its transition to testing. The build log is available at http://buildd.debian.org/fetch.php?pkg=dpkgver=1.13.22arch=mipsstamp=1150904570file=logas=raw After an investigation with Thiemo Seufer, this issue is caused by perl. perl also FTBFS on mips, and the mips build daemon uses perl 5.8.8-4 and perl-modules 5.8.8-6. With this combination, the Encode::JP::JIS7 module is not installed, which finaly causes the dpkg build failure. To fix this bug, I can see the following actions: 1) wait until #374396 (perl FTBFS on mips) or #377385 (perl-modules dependencies) is fixed 2) manually build dpkg on mips with perl-modules 5.8.8-4 3) adding `|| true' after calling po4a to make sure the generation of the translated man pages do not stop the build. Note: the FTBFS in probably also present on hppa (where perl also FTBFS). Kind Regards, -- Nekral -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374705: [Pkg-shadow-devel] Bug#374705: tentative patch
package passwd clone 374705 -1 retitle -1 useradd do not create the mail spool (even with CREATE_MAIL_SPOOL=yes in /etc/default/useradd) severity -1 normal thanks Hello Stephen, On Thu, Jun 22, 2006 at 11:18:44AM +0100, Stephen Gran wrote: The bug is present in 1:4.0.16-2. Unless I'm missing something? Well, the bug present in 1:4.0.16-2 is a little bit different: no mail spools are created - even when CREATE_MAIL_SPOOL is set to yes So I'm cloning this bug. The new bug is pending and fixed upstream, with a normal severity. I will close 374705 with the 1:4.0.16-1 version of passwd. Kind Regards, -- Nekral -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374705: [Pkg-shadow-devel] Bug#374705: tentative patch
Tomasz,
On Wed, Jun 21, 2006 at 10:55:36AM +0100, Stephen Gran wrote:
Hey all,
I think I might have found the problem. The mail spool is open()ed, and
then the fd is checked to see if there is an error (as is proper). The
problem is, the fchown/fchmod calls happen in the same logic path as
error handling, not in an else block. The attached patch should fix it.
What I don't understand, is why the mail box is created if this bloc of
code cannot be reached (due to the issue described below).
I have to note in passing, though, that I had to change the line
if (strcasecmp (create_mail_spool, yes) == 0) {
to
if (strcasecmp (def_create_mail_spool, yes) == 0) {
Tomasz, create_mail_spool is never set. It should either be removed, or
set somewhere (e.g. like the other similar variables in process_flags,
even if there is no flags for this value).
to even enter this block in the first place - is there an incomplete
variable name transition, or am I doing something wrong?
--- src/useradd.c~ 2006-06-21 10:51:01.0 +0100
+++ src/useradd.c 2006-06-21 10:51:17.0 +0100
@@ -1599,6 +1599,7 @@
if (fd 0) {
perror (_(Creating mailbox file));
return;
+ } else {
gr = getgrnam (mail);
if (!gr) {
Thanks for the patch. This also looks correct.
I'm attaching another patch, which fixes this issue, the other issue
mentionned by Stephen and another issue (def_create_mail_spool should
never be set to CREATE_MAIL_SPOOL).
Note: I still don't understand the Debian bug and can't reproduce it. I
will look closer later.
Kind Regards,
--
Nekral
Index: src/useradd.c
===
RCS file: /cvsroot/shadow/src/useradd.c,v
retrieving revision 1.97
diff -u -r1.97 useradd.c
--- src/useradd.c 20 Jun 2006 20:00:04 - 1.97
+++ src/useradd.c 21 Jun 2006 19:29:56 -
@@ -343,9 +343,6 @@
* Create by default user mail spool or not ?
*/
else if (MATCH (buf, CREATE_MAIL_SPOOL)) {
- if (*cp == '\0')
- cp = CREATE_MAIL_SPOOL; /* XXX warning: const */
-
def_create_mail_spool = xstrdup (cp);
}
}
@@ -1247,6 +1244,8 @@
if (!sflg)
user_shell = def_shell;
+
+ create_mail_spool = def_create_mail_spool;
}
/*
@@ -1600,7 +1599,7 @@
if (fd 0) {
perror (_(Creating mailbox file));
return;
-
+ } else {
gr = getgrnam (mail);
if (!gr) {
fprintf (stderr,
Bug#374705: [Pkg-shadow-devel] Bug#374705: tentative patch
On Wed, Jun 21, 2006 at 09:57:04PM +0200, Nicolas François wrote: Note: I still don't understand the Debian bug and can't reproduce it. I will look closer later. I checked the code of 4.0.15-10. The bug is present in this version. However, I think the issue is not present in the 4.0.16 versions (according to my tests and according to the code). Can somebody else confirm? I also wonder whether we should make a special note for this bug (to inform the users who created users with 4.0.15-10). Kind Regards, -- Nekral
Bug#315784: md5sum shouldn't be able to disappear
Hello, After reading the log of #315784 (dpkg: dependencies should ensure md5sum is present), I wonder why adding a Pre-Depends: coreutils (= ...) field to dpkg would break (c)debootstrap. I made a tarball for debootstrap with a modified dpkg and I noticed no problem. Goswin, do you remember why you said it would break debootstrap? I'm keeping Adrian and the (c)debootstrap maintainer CCed. cmot Ah. So dpkg just pre-depend on the new coreutils? cmot I'll file a serious bug on dpkg, then (if there isn't one already; haven't looked yet). mrvn cmot: that would suck because it breaks (c)debootstrap Kind Regards, -- Nekral -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#358792: quilt makes tbm cry: and breaks other packages (leader to FTBFS)
Hi, The attached patch fixes the paje.app build failure. I don't know if the return values of each commands are really consistent. When the series file is missing or if all the patches were alredy applied, quilt push will return 2. When quilt push is called with the name of a patch in argument, and if this patch doesn't exist, the return value is 1. (I think it's quite the same as the quilt pop behavior) I let you add the patch tag if you think it is OK. Kind Regards, -- Nekral diff -rauN ../orig/quilt-0.44/quilt/push.in ./quilt-0.44/quilt/push.in --- ../orig/quilt-0.44/quilt/push.in2006-02-14 19:31:44.0 +0100 +++ ./quilt-0.44/quilt/push.in 2006-03-24 21:38:49.0 +0100 @@ -338,7 +338,7 @@ [ -z $opt_all ] number=1 fi -stop_at_patch=$(find_unapplied_patch $stop_at_patch) || exit 1 +stop_at_patch=$(find_unapplied_patch $stop_at_patch) || exit $? [ -n $opt_quiet ] silent=-s [ -z $opt_verbose ] silent_unless_verbose=-s diff -rauN ../orig/quilt-0.44/quilt/scripts/patchfns.in ./quilt-0.44/quilt/scripts/patchfns.in --- ../orig/quilt-0.44/quilt/scripts/patchfns.in2006-02-11 23:31:51.0 +0100 +++ ./quilt-0.44/quilt/scripts/patchfns.in 2006-03-24 22:27:26.0 +0100 @@ -538,7 +538,7 @@ then printf $Patch %s is currently applied\n \ $(print_patch $patch) 2 - return 1 + return 2 fi echo $patch else @@ -548,13 +548,13 @@ then patch_after $start else - find_first_patch || return 1 + find_first_patch || return 2 fi if [ $? -ne 0 ] then printf $File series fully applied, ends at patch %s\n \ $(print_patch $start) 2 - return 1 + return 2 fi fi }
Bug#353251: notification-daemon: fails to install
tags 353251 patch thanks Hello, The problem is caused by the postinst script. It calls killall notification-daemon, but no such process is running. Replacing it with killall notification-daemon || true fixes this bug. Kind Regards, -- Nekral -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330291: Authentication problem with pbuilder
tags 330291 pending thanks Committed. Thanks for noticying and for the patch. Kind Regards, -- Nekral -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319972: FTBFS: Ambiguous calls to findHash
tags 319972 patch
thanks
Hello,
In FindHash.hpp, there are two definitions of the findHash function, one
with const keys, and one without the const modifier.
The situation is similar to:
f(T) {...}
f(const T) {...}
When f(const string) is used, g++-4 doesn't know if it should take the
first definition with T=(const string), or the second, with T=string.
Since the two implementations of findHash are identical, I removed the one
with the const modifier.
This removal should not loose any verification ('find' always operates on a
const object anyway).
Note: I've let the definition of the second findHash when
(__INTEL_COMPILER = 700), since I can't test this.
It compiles with gcc 2.95, 3.2, 3.3 and 4.0.2.
hth,
--
Nekral
--- criticalmass-0.9.11/utils/FindHash.hpp 2004-12-19 07:14:37.0
+0100
+++ ../criticalmass-0.9.11/utils/FindHash.hpp 2005-08-07 11:21:44.0
+0200
@@ -30,14 +30,11 @@
return ci-second;
}
+#if (__INTEL_COMPILER = 700)
template class _KeyT, class _ValT
_ValT* findHash(
const _KeyT trigger,
-#if (__INTEL_COMPILER = 700)
hash_map _KeyT, _ValT*, hash_KeyT, equal_to_KeyT hashMap )
-#else
-hash_map const _KeyT, _ValT*, hashconst _KeyT, equal_toconst _KeyT
hashMap )
-#endif
{
typename hash_map const _KeyT, _ValT*, hashconst _KeyT
::const_iterator ci;
ci = hashMap.find( trigger);
@@ -48,5 +45,6 @@
return ci-second;
}
+#endif
#endif
Bug#318525: FTBFS: Memory inputs not directly addressable
Hi Roger, On Sun, Jul 31, 2005 at 05:22:15PM +0100, Roger Leigh wrote: On Sun, Jul 31, 2005 at 04:54:14PM +0100, Roger Leigh wrote: /tmp/buildd/atlas-3.2.1ln/include/contrib/camm_dpa.h:766: error: memory input 2 is not directly addressable I've been able to compile this file with the attached patch. However, I have some troubles building the package: The first debuild -uc -us fails with (before any compilation): Looking for BLAS (this may take a while): make: *** [bin/Linux_3dnow_static/Make.inc] Error 1 debuild: fatal error at line 765: dpkg-buildpackage failed! Then, a second debuild -uc -us compiles some files, then install libblas.a in the debian/tmp directory, and then I have the same failure: Looking for BLAS (this may take a while): make: *** [bin/Linux_3dnow_static/Make.inc] Error 1 debuild: fatal error at line 765: dpkg-buildpackage failed! Any idea? hth, -- Nekral --- /tmp/camm_dpa.h 2005-08-06 22:12:52.0 +0200 +++ include/contrib/camm_dpa.h 2005-08-06 22:27:38.0 +0200 @@ -762,6 +762,9 @@ #define fixm c #endif NO_INLINE; +int stride_size = stride*sizeof(*fixm); +int lda_size = lda*sizeof(*a); +int len_size = len*sizeof(*movm)/sizeof(float); ASM ( @@ -884,8 +887,8 @@ popl %%ebx\n\t -::m (movm),m (fixm),m (stride*sizeof(*fixm)),m (a),m (lda*sizeof(*a)), - m (len*sizeof(*movm)/sizeof(float)) +::m (movm),m (fixm),m (stride_size),m (a),m (lda_size), + m (len_size) #ifdef SCPLX ,m (w)
Bug#297246: pfe: FTBFS (amd64/gcc-4.0): invalid lvalue in increment
Hi,
On Tue, Mar 01, 2005 at 09:10:13PM +0100, Andreas Jochens wrote:
@@ -670,7 +670,8 @@
*/
FCode (p4_nofp_f_trunc_to_s)
{
-double h = *FSP++;
+double h = *FSP;
+SP = (double *)SP + 1;
*--SP = (p4cell) h;
}
I'm wondering if this is not a typo. Shouldn't FSP be incremented instead
of SP?
Note: I've not tested it, I just mistyped a bug number and found this one.
Please forgive me if it was intentional.
Best Regards,
--
Nekral
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
