Bug#757402: [PATCH] tests: skip small-stack tests on hppa architecture
On hppa these tests crash because the allocated stack space is too
small, even after it was doubled in b9a190789 (and the data size
doubled to match) to make it work on powerpc. For this arch just
skip these tests, which is enough to make the whole suite pass.
Fixes: https://bugs.debian.org/757402
Based-on-patch-by: John David Anglin
Signed-off-by: Greg Price
---
t/test-lib.sh | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 0ea1e5a05..c62961a3e 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -1467,6 +1467,14 @@ FreeBSD)
;;
esac
+# Detect arches where a few things don't work
+uname_m=$(uname -m)
+case $uname_m in
+parisc* | hppa*)
+ test_set_prereq HPPA
+ ;;
+esac
+
( COLUMNS=1 && test $COLUMNS = 1 ) && test_set_prereq COLUMNS_CAN_BE_1
test -z "$NO_PERL" && test_set_prereq PERL
test -z "$NO_PTHREADS" && test_set_prereq PTHREADS
@@ -1606,16 +1614,16 @@ run_with_limited_cmdline () {
}
test_lazy_prereq CMDLINE_LIMIT '
- test_have_prereq !MINGW,!CYGWIN &&
+ test_have_prereq !HPPA,!MINGW,!CYGWIN &&
run_with_limited_cmdline true
'
run_with_limited_stack () {
(ulimit -s 128 && "$@")
}
test_lazy_prereq ULIMIT_STACK_SIZE '
- test_have_prereq !MINGW,!CYGWIN &&
+ test_have_prereq !HPPA,!MINGW,!CYGWIN &&
run_with_limited_stack true
'
--
2.26.2
Bug#757402: git: test suite fails on hppa, in run_with_limited_stack
On Wed, May 13, 2020 at 4:53 AM John David Anglin wrote: > On 2020-05-13 1:44 a.m., Greg Price wrote: > > Probably cleanest to put this outside the `case $uname_s`. > I put it where I did because the result of uname -m is somewhat OS dependent. > > The config.guess script attempts to guess a canonical system name for a > target. It has all the gory > details on the interpretation of uname -m. I just took a look through that. Wow, I see what you mean! case "$UNAME_MACHINE:$UNAME_SYSTEM:$UNAME_RELEASE:$UNAME_VERSION" in # ... 9000/7??:4.3bsd:*:* | 9000/8?[79]:4.3bsd:*:*) echo hppa1.1-hp-bsd exit ;; And there are lots more like that one, and others with complex internal logic. Still I'm not sure that that situation is helped by putting the `uname -m` inside this case. This is the catchall `*)` case after looking only for MINGW, CYGWIN, and FreeBSD, and those all appear to have pretty sane `uname -m` behavior. (On FreeBSD, `uname -p` gets a bit more specific but `uname -m` is already sane; I found the report here: https://github.com/mesonbuild/meson/issues/5766 informative.) If any of the OSes where config.guess has to do more work were to get this far in building and testing Git, they'd end up running any code we stick at this spot anyway. So I think it still makes more sense to put the new `case` next to the existing one. One other thought I have from that config.guess example, though -- there are some cases there like this: parisc64:Linux:*:* | hppa64:Linux:*:*) echo hppa64-unknown-linux-"$LIBC" exit ;; That suggests to me that the condition should perhaps look for "hppa", too, like parisc* | hppa*) test_set_prereq HPPA ;; What do you think? Cheers, Greg
Bug#757402: git: test suite fails on hppa, in run_with_limited_stack
Great! WFM on amd64, too. > *) > + uname_m=$(uname -m) > + case $uname_m in > + parisc*) > + test_set_prereq HPPA > + ;; > + esac Probably cleanest to put this outside the `case $uname_s`. Would you mind if I send a version of this patch to the upstream mailing list? I think that's the best route for it to go through. Or you're of course welcome to do so (and please cc this bug); if you haven't submitted patches to Git before, you'll want to read the instructions here: https://git.github.io/htmldocs/SubmittingPatches.html#send-patches Cheers, Greg
Bug#757402: git: test suite fails on hppa, in run_with_limited_stack
Control: retitle -1 git: test suite fails on hppa, in run_with_limited_stack Control: found -1 1:2.26.1-1 On Thu, 7 Aug 2014 16:10:20 -0400 John David Anglin wrote: > run_with_limited_stack git tag --contains HEAD >actual && > [...] > Killed > not ok 136 - --contains works in a deep repo Thanks for the report. On Fri, 05 Sep 2014 23:12:26 +0200 Helge Deller wrote: > git fails to build on hppa arch, because the stack is set to 64kb > in the run_with_limited_stack() function for this test. > I assume 64kb stack size is far too small for hppa? > Even /bin/ls won't work with a 128kb stack - so I'm not sure if > this testcase should just be disabled for hppa (it's disabled on > Windows because Windows does not support setting ulimits). A few weeks after these reports, the stack size for these tests was bumped to 128k upstream: https://git.kernel.org/pub/scm/git/git.git/commit/?id=b9a190789 apparently in order to make it work on the m68k arch. (Commit message copied below.) But that wasn't enough on hppa, and the test suite is still failing there with essentially the same issue. It appears now slightly earlier, in another test 6120.70 (from t/t6120-describe.sh) which has adopted the same technique. Here's the failure in the most recent buildd log in unstable, on Git v2.26.1: """ expecting success of 6120.70 'describe works in a deep repo': git tag -f far-far-away HEAD~7999 && echo "far-far-away" >expect && git describe --tags --abbrev=0 HEAD~4000 >actual && test_cmp expect actual && run_with_limited_stack git describe --tags --abbrev=0 HEAD~4000 >actual && test_cmp expect actual Updated tag 'far-far-away' (was cb6ab2c) Segmentation fault not ok 70 - describe works in a deep rep """ https://buildd.debian.org/status/fetch.php?pkg=git&arch=hppa&ver=1%3A2.26.1-1&stamp=1586894380&raw=0 I think it would indeed be sensible to simply disable these test cases on hppa. Here's how the prereq for them is defined: """ test_lazy_prereq ULIMIT_STACK_SIZE ' test_have_prereq !MINGW,!CYGWIN && run_with_limited_stack true ' """ So perhaps that `!MINGW,!CYGWIN` bit can be straightforwardly extended to skip these tests on hppa too. If somebody would like to find the right incantation to put there for hppa, and test that it works, then I think that may be enough to get the Git test suite passing again on hppa. Cheers, Greg commit b9a1907899a2a00e94092207bb5de4d864408806 Author: Junio C Hamano Date: Tue Sep 23 15:41:38 2014 -0700 t7004: give the test a bit more stack space It was reported that the allocated stack space was too small for some archs openSUSE buildfarm runs the tests on. Double it while also doubling the amount of data to be handled. Reported-by: Andreas Schwab Suggested-by: Jeff King Tested-by: Andreas Schwab Signed-off-by: Junio C Hamano
Bug#933100: hg-git: autopkgtest needs update for new version of git
Control: affects -1 - src:git On Fri, 26 Jul 2019 20:07:31 +0200 Paul Gevers wrote: > With a recent upload of git the autopkgtest of hg-git fails in testing > when that autopkgtest is run with the binary packages of git from > unstable. It passes when run with only packages from testing. In tabular > form: >passfail > gitfrom testing1:2.22.0-1 > hg-git from testing0.8.12-1.1 > all others from testingfrom testing > > I copied some of the output at the bottom of this report. It seems your > test is picky about capitalization of output generated by a binary (git) > provided by the git package. Please fix your test. I'm not quite sure whether this test in hg-git was ever fixed, but in any case I believe it no longer affects git: the delay eventually expired and a new git version migrated. (As have several more new versions since then.) Cheers, Greg
Bug#959770: python3.8 for buster-backports
Package: src:python3.8 Severity: wishlist Hello, Do you think you might be able to provide a backport of python3.8 in buster-backports? I'm sure I'm not the only user of buster who would greatly appreciate having Python 3.8 packaged for it. Thanks, kind regards, Greg
Bug#750687: fixed as of buster (Re: "git status" becomes fork-bomb if a submodule's .git directory is not accessible)
Control: fixed -1 1:2.20.1-2+deb10u1 Control: fixed -1 1:2.26.2-1~bpo10+1 I tried reproducing this on the Git 2.20 in buster (with the reproduction recipe from message #14), and it seems it has been fixed! Same with the Git 2.26 backported from bullseye. Instead of a fork bomb, there's an error message: nobody@678fb692c9b5:/tmp/bar$ git status fatal: 'foo/.git' not recognized as a git repository which seems pretty OK. Cheers, Greg
Bug#896904: Upstream version 2.0.3 fixes issue
Several reports on the web say that this issue is fixed by installing Vagrant 2.0.3, from upstream's own .deb package: https://github.com/dotless-de/vagrant-vbguest/issues/292 https://github.com/devopsgroup-io/vagrant-hostmanager/issues/256 And indeed that worked for me just now on buster, after I'd gotten this issue on vagrant 2.0.2+dfsg-3 . I don't see anything in upstream's changelog for 2.0.3 that looks like a fix: https://github.com/hashicorp/vagrant/blob/master/CHANGELOG.md#203-march-15-2018 but *shrug*; empirically the fix is there. (Upstream seems to make a release every month or so, so that's no longer the latest; they're up to 2.1.2.) Cheers, Greg
Bug#784612: [anki] schroot-based workaround (Re: Qt4's WebKit removal)
On Fri, 10 Jun 2016 15:38:53 +0900 Richard Möhn wrote: > This is not a good solution for everyone, but I'm now running Anki > inside a Debian Jessie Docker container. See here for how to do it: > http://cloj.de/AnkiDocker/ I much appreciated Richard's recipe. I found Docker rather finicky to work with, though, e.g. to make tweaks to the Jessie environment, and I wasn't consistently able to keep my Japanese input method working with the resulting Anki. So I'm now running Anki inside a Debian Jessie schroot, which I've found simpler to manage. See here for how: https://github.com/gnprice/anki-jessie Perhaps someone else will find this recipe helpful, as I found Richard's, in the time before Anki 2.1 stabilizes upstream and can enter stretch-backports. Best, Greg
Bug#704441: git: executables in contrib/ should be executable
On Mon, Apr 01, 2013 at 05:12:29PM -0700, Jonathan Nieder wrote: > Sure. I meant to link to the bugs for these but forgot to; sorry > about that. > > http://bugs.debian.org/702697 - git-remote-bzr > http://bugs.debian.org/703864 - git-remote-hg Aha, perfect. > Yep, these need to be installed to $PATH. Patches and other > improvements welcome. Understood! Greg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#704441: git: executables in contrib/ should be executable
clone 704441 -1 retitle -1 remote-helpers should be executable and in /usr/share/git-core/contrib tags -1 - wontfix quit On Mon, Apr 01, 2013 at 12:39:11AM -0700, Jonathan Nieder wrote: > When there is interest in scripts under /usr/share/doc/git being > executable, that is a sign that that script should be moved out of the > documentation directory and into a more permanent location. That way, > we can retain a little leeway to compress or reorganize documentation > when that seems useful, and people on space-constrained systems that > leave out /usr/share/doc will not be missing any functionality. Fair enough. There's a lot of stuff in contrib/ and I haven't looked at most of it, so I'll leave #704441 as a place for you to point people to on the general question and concentrate further discussion on the remote-helpers. The remote-helpers are fairly new but have rapidly become quite useful; they make it possible to clone a Mercurial or Bazaar repository and push back to it, much like git-svn does for Subversion. It'd be good to promote them to /usr/share/git-core and make them executable, like the hooks. Greg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#687391: git: executables in contrib/ should be executable
retitle 687391 git: executables in contrib/ should be executable quit I just ran into this same issue with contrib/remote-helpers/git-remote-hg, where all the same reasoning applies as for the contrib hooks. There are a lot of files in contrib/. Many of them (about 60) are marked executable in git.git upstream. Probably all of the files marked executable upstream should be installed as executable in /usr/share/doc/git/contrib/ and /usr/share/git-core/contrib/, including the hooks and the remote-helpers. Greg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#671181: silently loses staged but uncommitted files when pulling over a new repo
found 671181 1:1.8.1.5-1 Still present in the latest upstream. Sounds like a painful bug when it bites. Jonathan, did you spot why Junio's patch you linked to didn't make it upstream? (Unfortunately follow-up threads are common on the git-list and I don't know a good way to browse for them, so I'm hoping you either recall or have better archives than I do.) Looks like a pretty sensible patch to me. Greg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#595911: fixed (git clone: refs/original from filter-branch prevents clone of tags)
Hi Jonathan, This bug appears to be fixed as of Git 1.8.1.5, the newest upstream release. When I repeat your reproduction recipe, the 'clone' succeeds with no error message, and tagFoo exists in the cloned repo. -- 8< -- mkdir foo && ( cd foo && git init && echo A >foo.txt && git add foo.txt && git commit -m "Created foo" && git tag -am "Tagging foo" tagFoo && git filter-branch --env-filter 'export GIT_AUTHOR_NAME=xyz123' \ --tag-name-filter cat -- --all ) && git clone file:///`pwd`/foo newFoo && git --git-dir=foo/.git for-each-ref && git --git-dir=newFoo/.git for-each-ref -> ... dd70efcfeca8e5dae5d7fc1e1dcc404ee55bbaf8 commit refs/heads/master cf9a6f8cfa2e71cca3860e4d20a0ae2b0cb1097e commit refs/original/refs/heads/master cf9a6f8cfa2e71cca3860e4d20a0ae2b0cb1097e commit refs/original/refs/tags/tagFoo 79d6acee511138d732dffec280f2c2e0b2200b99 tagrefs/tags/tagFoo dd70efcfeca8e5dae5d7fc1e1dcc404ee55bbaf8 commit refs/heads/master dd70efcfeca8e5dae5d7fc1e1dcc404ee55bbaf8 commit refs/remotes/origin/HEAD dd70efcfeca8e5dae5d7fc1e1dcc404ee55bbaf8 commit refs/remotes/origin/master 79d6acee511138d732dffec280f2c2e0b2200b99 tagrefs/tags/tagFoo -- >8 -- You've suggested a couple of times on the git-list that you would be happy for the BTS to be used as a bugtracker for Git itself, if I understand you correctly. That'd certainly be a much-needed facility for the Git project. How would you suggest recording here the fact that this bug has been resolved in Git 1.8.1.5? (The bug may also be already fixed in squeeze's 1.7.2.5 or wheezy's 1.7.10.4; I don't know. That would probably simplify recording the resolution here, but I'm also interested in the general case.) Thanks! Greg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#593516: [buildd-tools-devel] Bug#593516: schroot: race condition in /proc/mounts can break cleanup
On Thu, Aug 19, 2010 at 3:21 PM, Roger Leigh wrote:
>> Currently I'm working around the issue with a flock around the body of
>> do_umount_all(). That's easy and is enough to address the problem
>> when no other umounts are happening on the system.
>
> If you would like this fix including, I'll be happy to accept a
> patch implementing this. Are you doing this in the shell script?
> If it's possible to directly lock /proc/mounts with fcntl this could
> be addressed directly in schroot-listmounts using sbuild::file_lock,
> which wraps fcntl.
Sure, patch copied below. It's not possible for userspace to directly
lock /proc/mounts; the best we can do is an advisory lock that we
ourselves respect. So I placed a flock around the invocations of both
schroot-listmounts and umount, which are the only such invocations in
the schroot source tree.
> Has a bug report been filed against the Linux kernel or on the
> kernel mailing list? A fix in the kernel would be ideal, and they
> should probably also be notified.
I haven't filed such a bug. I'm debating whether to send a message to
the LKML. Honestly, I suspect this will follow many other well-loved
quirks in that it is difficult to fix, and the best solution to hope
for may be for more people to be aware of it and handle it with
strategies like the separate-namespace approach you suggest. Maybe
I'll mail the LKML with a strawman patch, and see if someone can prove
me wrong. =)
>> A real fix would
>> probably have to be for schroot to record for itself the list of
>> mounts it makes inside a session's tree, and rely on that list instead
>> of on /proc/mounts.
>
> This wouldn't be robust enough, I'm afraid. Processes inside the
> chroot (or outside, for that matter) could mount (and umount)
> filesystems after initial setup. Mounts might also occur in
> additional custom setup scripts. As a result, we really do need
> to get a definitive list of mounts at the session end in order to
> clean up correctly.
Oof. Yes, I see.
> At least on Linux, one other approach would be to make use of
> per-process namespaces which would TTBOMK allow us to skip the
> umounts completely since it's automatically cleaned up when the
> last process in the namespace exits. This has only recently
> become viable without significant rearchitecting of schroot
> though (IIRC it's now possible to connect to an existing namespace
> without a parent-child relationship, though I'm not familiar with
> the details).
That sounds like a potential solution. If you could give a separate
mount namespace to each schroot session, that would definitely fix the
problem -- the list that /proc/mounts reads is per-namespace, so there
is no race between unmounting in one namespace and reading
/proc/mounts in another.
Greg
--- schroot-1.3.2.orig/etc/setup.d/10mount
+++ schroot-1.3.2/etc/setup.d/10mount
@@ -53,6 +53,7 @@
do_umount_all()
{
if [ -d "$1" ]; then
+ ( flock 9
mounts="$("$LIBEXEC_DIR/schroot-listmounts" -m "$1")"
if [ "x$mounts" != 'x' ]; then
echo "$mounts" |
@@ -63,6 +64,7 @@
umount "$mountloc" || exit 1
done || exit 1
fi
+ ) 9>/var/lock/umount
fi
}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#593516: schroot: race condition in /proc/mounts can break cleanup
Package: schroot Version: 1.3.2-1 Severity: normal Hello, schroot suffers from a race condition where if two schroot sessions are ended concurrently, one of them may fail to clean up properly. On some intensely schroot-using build machines, I see this failure regularly. The symptom looks like this: E: 10mount: umount: /var/lib/schroot/mount/somechroot-source-bd8cdb9f-611a-4991-869c-e479fa673ec7: device is busy. and then the 'schroot' command exits with failure. The issue is that /proc/mounts is unreliable. It turns out that when you read it concurrently with a umount, you can end up missing records for mounts that have nothing to do with the ones that were unmounted. Arguably this is a kernel bug, but there is no simple fix, so /proc/mounts will definitely remain unreliable at least for squeeze. Consequently because schroot-listmounts relies on /proc/mounts, it too is unreliable. So when do_umount_all() in etc/setup.d/10mount does what amounts to this (but with better reporting and error handling): "$LIBEXEC_DIR/schroot-listmounts" -m "$base" | xargs -rn1 umount the schroot-listmounts may skip a record if another process is ending another schroot session, or unmounting something for any other reason. Then one of the internal mounts, like .../tmp or .../dev/pts, remains mounted, and the attempt to unmount the base directory fails. Currently I'm working around the issue with a flock around the body of do_umount_all(). That's easy and is enough to address the problem when no other umounts are happening on the system. A real fix would probably have to be for schroot to record for itself the list of mounts it makes inside a session's tree, and rely on that list instead of on /proc/mounts. Cheers, Greg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#507966: CDBS should cleanup .egg-info directories
On Sat, Oct 10, 2009 at 10:03:52PM +0200, Marc Dequènes (Duck) wrote: > I hope current distutils tries to clean things properly when called with > the 'clean' target, but as many projects embed ancient versions of > setup.py, i think your patch is useful. It will be included in the next > upload. Great, good to hear. Greg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#507966: CDBS should cleanup .egg-info directories
[Missed 507...@b.d.o in my first reply, apologies for dupes.] # reopen 507966 = # thanks Forgive me if I'm mistaken, but I believe this reply was intended for a different bug. Your salutation appears to be for someone not named previously on bug #507966. Agreed that it's sometimes worthwhile to support eggs. This patch would make it slightly cleaner for CDBS packages to do so. Regards, Greg > Coin, > > In fact, the Python team people decided to allow using eggs, for > development reasons for exemple, even if it is not officially > supported in Debian. It makes sense not to forbid such usage, even it > not recommended. You should really follow the recommandations on the > following page: > http://wiki.debian.org/DebianPythonFAQ#Pythoneggs > > There is no reason to go against such decision, but you're welcome to > discuss it on the Python team mailing-list, and ask us to reconsider > this bug if a consensus is reached. Until then, i consider this not a > bug. > > Regards. > > -- > Marc Dequènes (Duck) - End forwarded message - -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#509229: openssh-client: ssh-agent man page describes wrong (and insecure) forwarding behavior
Package: openssh-client Version: 1:4.3p2-9etch3 Severity: normal Tags: patch The man page ssh-agent(1) says, """Authentication data need not be stored on any other machine, and authentication passphrases never go over the network. However, the connection to the agent is forwarded over SSH remote logins, and the user can thus use the privileges given by the identities anywhere in the network in a secure way.""" This is not true, and would be a serious security problem if it were -- a compromise on the remote host could employ the user's privileges to connect elsewhere. In fact, no such connection is forwarded unless the user specifically asks for it with the -A option to ssh. The patch below fixes this error. Cheers, Greg --- ssh-agent.1~2008-12-19 18:12:40.0 -0500 +++ ssh-agent.1 2008-12-19 18:15:02.0 -0500 @@ -129,8 +129,10 @@ terminal. Authentication data need not be stored on any other machine, and authentication passphrases never go over the network. -However, the connection to the agent is forwarded over SSH -remote logins, and the user can thus use the privileges given by the +However, with +.Cm ssh -A +the connection to the agent may be forwarded over SSH remote logins, +so that the user can use the privileges given by the identities anywhere in the network in a secure way. .Pp There are two main ways to get an agent set up: -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.24.5 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages openssh-client depends on: ii add 3.102Add and remove users and groups ii deb 1.5.11etch2 Debian configuration management sy ii dpk 1.13.25 package maintenance system for Deb ii lib 2.3.6.ds1-13etch7GNU C Library: Shared libraries ii lib 1.39+1.40-WIP-2006.11.14+dfsg-2etch1 common error description library ii lib 2.9.cvs.20050518-2.2 BSD editline and history libraries ii lib 1.4.4-7etch6 MIT Kerberos runtime libraries ii lib 5.5-5Shared libraries for terminal hand ii lib 0.9.8c-4etch3SSL shared libraries ii pas 1:4.0.18.1-7 change and administer password and ii zli 1:1.2.3-13 compression library - runtime openssh-client recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#426465: init should clear environment
severity 505440 critical
# justification: is the cause of 426465, which is critical
clone 505440 -1
reassign -1 sysvinit
retitle -1 init should clear environment
tag -1 patch
thanks
For background, see #426465 and #505440, which is a more general
description of #426465.
initramfs exports an environment in /init with variables that confuse
some initscripts. Ubuntu has fixed this by having upstart clear its
environment. It looks like initramfs-tools should be fixed by having
it export a smaller environment, but we can and probably should also
fix the problems it causes by having init clear its environment in
child processes.
The attached patch does this.
upstart passes on two environment variables, PATH and TERM, so this
patch does the same.
Applying this change breaks an old-fashioned practice in initscripts
of getting certain variables from the kernel command line by expecting
them to be exported in the environment. An Ubuntu bug from 2006
(https://bugs.launchpad.net/bugs/74664) describes a situation where
this cropped up when they implemented the change. The correct way for
an initscript to do this is to look in /proc/cmdline, as e.g. the
initscripts package does in /etc/init.d/stop-bootlogd-single. It's
possible that some packages still use the old-fashioned practice.
Once this patch or another fix is uploaded, bugs #426465 and #505440
in initramfs-tools can be downgraded.
Greg
#! /bin/sh /usr/share/dpatch/dpatch-run
## 95_clear_environment.dpatch by Greg Price
Clear the environment when spawning a process.
@DPATCH@
diff -urNad trunk~/src/init.c trunk/src/init.c
--- trunk~/src/init.c 2008-12-13 20:35:24.0 -0500
+++ trunk/src/init.c2008-12-13 20:35:24.0 -0500
@@ -188,6 +188,8 @@ struct {
{NULL,0}
};
+char * const default_env_vars[] = {"PATH", "TERM", NULL};
+
#define NR_EXTRA_ENV 16
char *extra_env[NR_EXTRA_ENV];
@@ -782,13 +784,27 @@ char **init_buildenv(int child)
char**e;
int n, i;
- for (n = 0; environ[n]; n++)
- ;
+ if (child) {
+ for (n = 0; default_env_vars[n]; n++)
+ ;
+ } else {
+ for (n = 0; environ[n]; n++)
+ ;
+ }
n += NR_EXTRA_ENV + 8;
e = calloc(n, sizeof(char *));
- for (n = 0; environ[n]; n++)
- e[n] = istrdup(environ[n]);
+ if (child) {
+ for (n = 0; default_env_vars[n]; n++) {
+ char *key = default_env_vars[n];
+ char *value = getenv(key);
+ e[n] = imalloc(strlen(key) + strlen(value) + 2);
+ sprintf(e[n], "%s=%s", key, value);
+ }
+ } else {
+ for (n = 0; environ[n]; n++)
+ e[n] = istrdup(environ[n]);
+ }
for (i = 0; i < NR_EXTRA_ENV; i++)
if (extra_env[i])
Bug#507959: tightvnc-java: debian/copyright omits some licenses, adds another
tag 507959 patch
thanks
Below is a modified debian/copyright file that I believe fixes these
problems.
Thanks,
Greg
- debian/copyright -
This package was debianized by Ola Lundqvist <[EMAIL PROTECTED]> on
Tue, 19 Dec 2000 20:15:28 +0100.
It was downloaded from
http://www.tightvnc.com/
Authors, Copyright Holders, and Licenses
all files but DesCipher.java
These files have subsets of the following copyrights, and the
following license.
Copyright (C) 2001,2002 HorizonLive.com, Inc. All Rights Reserved.
Copyright (C) 2001,2002 Constantin Kaplinsky. All Rights Reserved.
Copyright (C) 2000 Tridia Corporation. All Rights Reserved.
Copyright (C) 1999 AT&T Laboratories Cambridge. All Rights Reserved.
This is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This software is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
On Debian Linux systems, the complete text of the GNU General Public
License can be found in '/usr/share/common-licenses/GPL'.
DesCipher.java
--
The authors are Dave Zimmerman <[EMAIL PROTECTED]> and Jef Poskanzer
<[EMAIL PROTECTED]>. The file has the following copyright notices and licenses:
Copyright (C) 1999 AT&T Laboratories Cambridge. All Rights Reserved.
This software is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Copyright (c) 1996 Widget Workshop, Inc. All Rights Reserved.
Permission to use, copy, modify, and distribute this software and its
documentation for NON-COMMERCIAL or COMMERCIAL purposes and without fee
is hereby granted, provided that this copyright notice is kept intact.
WIDGET WORKSHOP MAKES NO REPRESENTATIONS OR WARRANTIES ABOUT THE
SUITABILITY OF THE SOFTWARE, EITHER EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE, OR NON-INFRINGEMENT. WIDGET WORKSHOP SHALL NOT BE
LIABLE FOR ANY DAMAGES SUFFERED BY LICENSEE AS A RESULT OF USING,
MODIFYING OR DISTRIBUTING THIS SOFTWARE OR ITS DERIVATIVES.
THIS SOFTWARE IS NOT DESIGNED OR INTENDED FOR USE OR RESALE AS ON-LINE
CONTROL EQUIPMENT IN HAZARDOUS ENVIRONMENTS REQUIRING FAIL-SAFE
PERFORMANCE, SUCH AS IN THE OPERATION OF NUCLEAR FACILITIES, AIRCRAFT
NAVIGATION OR COMMUNICATION SYSTEMS, AIR TRAFFIC CONTROL, DIRECT LIFE
SUPPORT MACHINES, OR WEAPONS SYSTEMS, IN WHICH THE FAILURE OF THE
SOFTWARE COULD LEAD DIRECTLY TO DEATH, PERSONAL INJURY, OR SEVERE
PHYSICAL OR ENVIRONMENTAL DAMAGE ("HIGH RISK ACTIVITIES"). WIDGET
WORKSHOP SPECIFICALLY DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY OF
FITNESS FOR HIGH RISK ACTIVITIES.
Copyright (C) 1996 by Jef Poskanzer <[EMAIL PROTECTED]>. All rights
reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS
BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#507959: tightvnc-java: debian/copyright omits some licenses, adds another
Package: tightvnc-java Version: 1.2.7 Severity: normal The debian/copyright file in the tightvnc-java source package omits some copyrights, some licenses, and some authors found in the source files. It also includes an author, two copyrights, and a license that I see no basis for in the source files. The smallest omission: VncCanvas.java has a line // Copyright (C) 2000 Tridia Corporation. All Rights Reserved. not reflected in the copyright file. The extra author, copyrights, and license are the references to Richard Outerbridge, Graven Imagery, and the X Consortium and the X license. None of these appear elsewhere in a grep -r of the source. The major omission is that of the information on DesCipher.java, which has two authors, two copyright holders, and two licenses not mentioned in debian/copyright. This information is copied under the heading ACKNOWLEDGEMENTS inside the README file, and I suspect the extraneous notices under that heading in the copyright file were meant to be those of the README. I believe the paragraph with "See the file LICENCE.TXT", "also contains code from other sources", "see README" should all go away, as the copyright file should contain all the relevant information so that it is available on any system with the package installed. A reference to /usr/share/common-licenses/GPL can replace LICENCE.TXT, and the rest should be incorporated into the copyright file. Thanks! Greg -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.24.5 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#466074: qmail is free : what about a binary package now ?
Now that the author of this software has seen the light and made it free software, it'd be great to have it in Debian. Is there a particular obstacle known to be in the way of doing so, or is just a matter of someone doing the work? Thanks, Greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
