/copyright.
Regards,
Jonathan
-- % --
From: Jonathan Nieder jrnie...@gmail.com
Subject: Update debian/copyright
---
debian/copyright | 167 +
1 files changed, 154 insertions(+), 13 deletions(-)
diff --git a/debian/copyright b/debian/copyright
Hi again,
Bob Proulx wrote:
This is normal only. Please do not overinflating bug importance.
Your call, of course. I personally consider it minor. But so I
understand for the future: isn’t this a policy “must” directive? I am
thinking of [1], which says the copyright information and
forcemerge 583856 574810
forcemerge 583856 574812
quit
Jonathan Nieder wrote:
diff --git a/debian/debian.supp b/debian/debian.supp
index 421f834..47e4d5f 100644
--- a/debian/debian.supp
+++ b/debian/debian.supp
@@ -466,4 +466,13 @@
fun:_dl_start
obj:/lib/ld-2.10.1.so
Török Edwin wrote:
==16452== Invalid read of size 8
==16452==at 0x3A5E509DB2: ??? (strcpy.S:94)
...
==16452== Address 0x4fb63d0 is 0 bytes inside a block of size 7 alloc'd
==16452==at 0x4A061A7: malloc (vg_replace_malloc.c:195)
...
And many more errors (most of them are
tags 585743 + moreinfo
quit
S.D.Allen wrote:
Everything seems to
work in the main tab; but if one clicks on any URI that is to open in
a child tab it will result in the cursor just spinning.
Hmm, links targetted at multiple tabs work for me. To make sure I
understand, could you write up a
tags 585743 - moreinfo
severity 585743 important
quit
Hi Stephen,
Stephen Anchovie Fishpaste wrote:
It is/was probably something specific to my Unstable installation.
[...]
Recently I had purged Xfce4 from my system and installed the
Gnome-Desktop-Environment meta package. It was shortly
Package: dash
Version: 0.5.6.1-1~exp0
Severity: grave
Upgrading dash from 0.5.5.1-7~exp0 to 0.5.6.1-1~exp0 creates severe problems:
1. /usr/bin/dmenu_path stops populating ~/.dmenu_cache,
so alt-P (from xmonad, with dwm-tools installed) no longer lists any programs.
2.
$ chromium-browser
retitle 586736 dash: Can't open read-only scripts
merge 586807 586736
thanks
Krzysztof A. Sobiecki wrote:
sob...@solis:/tmp$ ./a.sh
/bin/sh: Can't open ./a.sh
During the boot-up process / partition is read-only and because of that
dash is unable to execute /etc/init.d/rcS and
reassign 588607 mutt,libtokyocabinet8
found 588607 mutt/1.5.20-9
found 588607 tokyocabinet/1.4.37-6
Hi Pierre,
Ron wrote:
Subject: mutt (priority standard) depends on libtokyocabinet8 (extra)
As per policy 2.5, it shouldn't do that.
Is there a reason libtokyocabinet8 should not be
Hi Krzysztof,
Sorry for the long delay in responding.
Krzysztof A. Sobiecki wrote:
[...]
+++ dash-0.5.6.1/src/input.c 2010-06-25 00:45:19.0 +0200
@@ -400,15 +402,28 @@ popstring(void)
*/
int
+isdir(const char *name)
+{
+ struct stat64 st;
+ if (stat64(name, st)
Hi Itanium porters,
The git test suite is failing on mundy. Any ideas about why?
(Or about how to try to investigate this --- a good emulator? machine
access? a willing guinea pig who can try patches?)
Some details on the test failure follow.
Anders Kaseorg wrote:
Some time between 1.6.5-1
Jonathan Nieder wrote:
So far so good, as the read_tree_twoway output reveals:
| 100644 346d4e61f111336a1443ef6b2e834aa5b1a7f91a 0 bozbar
| 100644 8e4020bb5a8d8c873b25de15933e75cc0fc275df 0 frotz
| 100644 dca6b92303befc93086aa025d90a5facd7eb2812 0 nitfol
| 100644
Package: grub-pc
Version: 1.98~experimental.20100111.1-1
Severity: serious
Hi,
Trying the experimental grub. Like Fabian reported in
http://bugs.debian.org/564844, text does not show up in the
graphical boot menu. But that is fine for now; I blindly hit enter,
and grub boots the default item,
Robert Millan wrote:
On Wed, Jan 13, 2010 at 08:43:18AM -0600, Jonathan Nieder wrote:
Version 1.98~experimental.20091229-1 is similar: though the boot menu
looks like text mode, when Linux boots, it is garbled and I cannot
make out anything until I start X.
Please could each of you attach
Yves-Alexis Perez wrote:
[0.00] Console: colour dummy device 80x25
So the VGA console was not initialized.
I asked Linux why, and here is what I learned:
...
[0.00] SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1,
Nodes
[0.00] Hierarchical RCU
Yves-Alexis Perez wrote:
Le 20/01/2010 12:09, Jonathan Nieder a écrit :
Yves-Alexis Perez wrote:
[0.00] Console: colour dummy device 80x25
So the VGA console was not initialized.
Might it be related to the fact I use KMS?
Maybe. If so, then our symptoms must come from different
Robert Millan wrote:
Would you please try attached patch and regenerate grub.cfg ?
It can be applied directly to /etc/grub.d/10_linux
I made a small change to output the gfxpayload lines below each
menuentry line. It’s working great now. Thanks!
diff --git a/etc/grub.d/10_linux.in
Robert Millan wrote:
On Wed, Jan 20, 2010 at 05:09:13AM -0600, Jonathan Nieder wrote:
This is odd, since the only places I can see that set
orig_video_isVGA are
[...]
You're looking at legacy code. When using modern 32-bit boot protocol,
this variable is passed by bootloader.
Oh! Looking
Hi Anders,
Thanks for your work on this.
Anders Kaseorg wrote:
Now that Git 1.6.6.1 is out, I propose we build git-core 1.6.6.1-1 with
the patch I posted above http://bugs.debian.org/563882#10, which lets
the two tests in question expect to fail on ia64 only.
From the log, it looks like
Hello,
Andreas Metzler wrote:
$ /tmp/GIT/git-core-1.6.6/git diff --no-index M.out 4.out
diff --git a/M.out b/4.out
index 4aefa95..d5ec90a 100644
Binary files a/M.out and b/4.out differ
$ cat M.out
100644 346d4e61f111336a1443ef6b2e834aa5b1a7f91a 0 bozbar
100644
Andreas Metzler wrote:
On 2010-01-09 Jonathan Nieder jrnie...@gmail.com wrote:
-- % -- M.out
100644 346d4e61f111336a1443ef6b2e834aa5b1a7f91a 0bozbar
100644 8e4020bb5a8d8c873b25de15933e75cc0fc275df 0frotz
100644 dca6b92303befc93086aa025d90a5facd7eb2812 0nitfol
Hi again,
Andreas Metzler wrote:
ametz...@merulo:/tmp/GIT/git-core-1.6.6-debug/t/trash
directory.t1001-read-tree-m-2way$ M.out
/tmp/GIT/git-core-1.6.6-debug/git-is-binary M.out 4.out
static buffer is not binary
stdin is not binary
M.out is binary
4.out is not binary
I’ve also
Jonathan Nieder wrote:
I have attached
generic-is-binary.c to pin this down; could you try:
uname -r
dpkg -l libc6
gcc -Wall -W -O -o generic-is-binary generic-is-binary.c
M.out ./generic-is-binary M.out
If M.out (but not stdin) is reported to be binary, great
-by: Jonathan Nieder jrnie...@gmail.com
---
Andreas Metzler wrote:
FWIW all versions of git-diff I tried (1.6.6, 1.6.5, and 1.5.6.5)
report Binary files a/M.out and b/4.out differ.
Thanks for checking this. So Anders’s suggestion is right: we
should disable the test suite on ia64 for now.
How about
doesn’t do anyone any good,
so let’s ignore the result of the test suite for now.
Works-around: http://bugs.debian.org/563882
Reported-by: Anders Kaseorg ande...@mit.edu
Investigated-by: Andreas Metzler ametz...@downhill.at.eu.org
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
+ : 'ignoring
reassign 563882 libc6.1 2.10.2-5
severity 563882 critical
retitle 563882 ia64: mmap reading null bytes that should not be there
thanks
Hi libc maintainers,
mmap() on ia64 seems to be totally broken. git does something
like the following to detect binary files:
struct stat st;
clone 557425 -1 -2
retitle 557425 lenny-squeeze upgrade, debconf defaults - system unbootable
retitle -1 please produce a grub.cfg that can be used by payload from lenny
severity -1 wishlist
submitter -1 !
retitle -2 upgrades should run grub-install as a safe default
severity -2 serious
thanks
Package: ttf-thai-tlwg
Version: 1:0.4.13-3
Severity: grave
Justification: renders package impossible to install
Hi,
Today’s upgrade of ttf-thai-tlwg fails for me:
| Preparing to replace ttf-thai-tlwg 1:0.4.13-2 (using
.../ttf-thai-tlwg_1%3a0.4.13-3_all.deb) ...
| /var/lib/dpkg/tmp.ci/preinst:
(2.20.51.20100518-1.1) experimental; urgency=low
+ * debian/binutils-multiarch.preinst.in: Re-add diversions on reinstall.
+Closes: #581156.
* Remove c++filt from binutils-multiarch.
- -- Jonathan Nieder jrnie...@gmail.com Thu, 20 May 2010 02:30:03 -0500
+ -- Jonathan Nieder jrnie
(2.20.51.20100518-1.1) experimental; urgency=low
* debian/binutils-multiarch.preinst.in: Re-add diversions on reinstall.
Closes: #581156.
* Remove c++filt from binutils-multiarch.
+ * Rename /usr/bin/ld from multiarch build to ld.bfd. Closes: #582490.
- -- Jonathan Nieder jrnie...@gmail.com Thu
and it seemed to work well; the first one is an unrelated
cosmetic change, the other fixes all unbound variables I
could find by reading through the script. Thoughts welcome.
Jonathan Nieder (2):
update-initramfs: use $* instead of $@
update-initramfs: bind variables before use
update-initramfs
Use $* where it makes the quoting behavior easier to understand.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Probably does not belong in this bug log, but I was too lazy to
drop the change.
update-initramfs |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git
Initialize local variables before use to avoid hard-to-debug problems
when they happen to be set in the environment.
These can cause initramfs-tools to error out since 0.95~29
(update-initramfs: Use nounset, 2010-04-07).
Closes: #583695
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
Hi Jon,
BTS wrote:
Processing commands for cont...@bugs.debian.org:
reassign 584248 src:git
Bug #584248 {Done: Jon Dowland j...@debian.org} [bup] FTBFS: needs to
build-depends on git
Is this intentional?
Jonathan
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
Package: shogun
Version: 0.9.1-1
Severity: serious
Hi Soeren,
On this i386, building shogun fails:
[...]
| doxygen Classifier.doxy
[...]
| Could not create search results directory 'html/search/search'
| python2.5 ../.doxy2swig.py --quiet --no-function-definition \
|
Soeren Sonnenburg wrote:
On Fri, 2010-02-05 at 23:26 -0600, Jonathan Nieder wrote:
From http://bugs.debian.org/564338 I learn that this is due to a known
problem in doxygen, and the workaround is to add
SEARCHENGINE= NO
to the .doxy files in src/modular. Since doxygen
Soeren Sonnenburg wrote:
On Fri, 2010-02-05 at 23:58 -0600, Jonathan Nieder wrote:
That’s good to hear. If I find time for it, I’ll look at the doxygen bug
a little more. The upstream status is “will be fixed in the next svn
commit”, so probably there’s a patch floating around somewhere
Johan Herland (1):
builtin-config: Fix crash when using -f relative path from non-root
dir
Jonathan Nieder (8):
git-gui: Makefile: consolidate .FORCE-* targets
Fill out debian/copyright
Fix references in generated man pages to point to /usr
debian/rules: stop ignoring
Hi Soroen,
Debian Bug Tracking System wrote:
This is an automatic notification regarding your Bug report
which was filed against the shogun package:
#568612: shogun: FTBFS due to doxygen bug#564338
It has been closed by Soeren Sonnenburg so...@debian.org.
Looks like the doxygen bug has
retitle 569594 git-core: [ia64 FTBFS] t7400-submodule-basic.sh fails
thanks
Jonathan Nieder wrote:
Severity: serious
Justification: FTBFS
Apparently re-enabling the git test suite (see #568915) reveals
another problem on the ia64. The test is in submodule support, so it
is probably worth
Jonathan Nieder wrote:
To learn more, you can run sh t7400-submodule-basic.sh -v from the t/
subdirectory of a git build directory and look at the files in
trash directory.t7400-submodule-basic.
Or, better,
sh -x t7400-submodule-basic.sh -v -i
Jonathan
I would love to do so myself.
Any
tags 564087 + unreproducible
thanks
Florian Lohoff wrote:
On Tue, Jan 26, 2010 at 10:53:24PM -0800, Matt Kraai wrote:
I'm trying to reproduce this issue, but I can't. I have bsdutils
1:2.16.2-0 installed. Here's how it behaves on my system:
kr...@macbookpro:~$ time script -c sleep 10
retitle 569594 git-core: [FTBFS] t7400-submodule-basic.sh fails
found 569594 git-core/1:1.7.0~rc2-1
thanks
Hi,
I’m looking for someone who could give access to an s390 or ia64
to track down a test failure in git-core. Access could be given
to the following ssh key which has been generated for
found 514220 ca-certificates/20090814
quit
Philipp Kern wrote:
patches for this bug are welcome
What license terms do your debian/ directory use? Granted, this is a
small enough patch that it is probably not copyrightable.
Completely untested, probably problematic:
-- % --
Subject: postinst:
package libdirectfb-1.2-0
fixed 569896 1.2.10really1.2.8-1
thanks
Torsten Crass wrote:
Admittedly, I'm not sure if this is a libdirectfb-1.2 bug -- yet after
the last upgrade, many applications refuse to start, emitting an error
message like
error while loading shared libraries:
fixed 569815 1.2.10really1.2.8-1
thanks
Hi,
jida...@jidanni.org wrote:
reopen 569815
found 569815 1.2.10-1
thanks
firefox says Couldn't load XPCOM and dies.
Downgrading
Note that version 1.2.10really1.2.8-1 is distinct from 1.2.10-1.
Upgrading to 1.2.10really1.2.8-1 should fix this.
Dear Christophe,
I think that as a developer you should already have access to
portboxen:
http://release.debian.org/squeeze/arch_qualify.html
But IIUC that would not be needed except to verify a fix to this bug.
| sbuild (Debian sbuild) 0.59.1 (24 Jan 2010) on lxdebian.bfinv.de
[...]
|
the BTS seems to deal best with that.
I hope you enjoy them. Sorry for the delay. Please let me know if
you have any questions.
Thanks,
Jonathan Nieder (5):
binutils-multiarch: clean up diversion handling
binutils-multiarch: automatically update version in maintainer
scripts
Remove
Matthias Klose wrote:
On 12.04.2010 05:48, Jonathan Nieder wrote:
Unfortunately, patch 1 adds the current version number to some of the
maintainer scripts; keeping that up to date is a maintainance burden I
do not want to impose. So patch 2 teaches debian/rules to take care
of that.
I
Jonathan Nieder wrote:
A certificate not listed in $CERTS_AVAILABLE could be from an
older version of ca-certificates or it could be from the user.
This patch assumes that it is from the user and preserves it,
The following is only about the upgrade case, where
/etc/ca-certificates.conf
Sergey Poznyakoff wrote:
Clint Adams sch...@debian.org ha escrit:
The mt man page suggests that a fatal error should exit with a 2;
mt's fatal_exit exits with a 1 (MT_EXIT_INVOP).
What is truly intended here?
The former: it shoud exit with code 2. Thanks for reporting.
This patch (plus
retitle 577519 packages with versioned dep on irb1.8 are not installable
thanks
Hi Francesco,
Francesco Poli wrote:
please keep the severity high,
or otherwise the issue will propagate to testing: there are packages
which are already uninstallable in unstable (for instance:
apt-listbugs)
, it is not actually important whether
DEB_VERSION or DEB_SVERSION is used. I couldn’t come up with a good
single place in the code to explain that, so I just put it in the
description for the patch.
Thanks again for your feedback so far.
Jonathan Nieder (5):
binutils-multiarch: clean up diversion
Matthias Klose wrote:
not sure why c++filt needs to be diverted.
It shouldn’t be.
$ ldd /usr/bin/c++filt | grep bfd
libbfd-2.20.51-multiarch.20100415.so =
/usr/lib/libbfd-2.20.51-multiarch.20100415.so (0xb74b6000)
$ readelf --dyn-syms /usr/bin/c++filt | grep bfd_
5:
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+python2.5 (2.5.5-5.1) local; urgency=low
+
+ * Initialize return value for issue #8233 fix. Closes: #578596.
+
+ -- Jonathan Nieder jrnie...@gmail.com Wed, 21 Apr 2010 03:00:29 -0500
+
python2.5 (2.5.5-5) unstable; urgency=low
* Fix
Gerrit Pape wrote:
init=1 dpkg-buildpackage -rfakeroot -B -uc -us
triggers the selftest failure.
After reproducing, the fix is now obvious
Nicely done. Thanks for figuring it out.
One way to find other problems like this is to add ‘set -u’ to
git-sh-setup. I’m slowly working through the
notfixed 561727 1:1.6.0-1
fixed 561727 1:1.6.5.3-1
tags 561727 + patch lenny upstream fixed-upstream
thanks
Hi,
Thanks for the report.
This bug was introduced by v1.5.5-rc0~137^2~2 (help: use parseopt,
2008-02-24), so it does not apply to etch.
It was fixed by v1.6.5.3~34 (help -a: do not
clone 544872 -1
retitle -1 xz-utils: allow upgrade from snapshots with xz-lzma
severity -1 normal
found -1 xz-utils/4.999.9beta+20091002-1
thanks
Hi Vincent,
Vincent Lefevre wrote:
There's a problem: previous versions had a xz-lzma package (needed
because of lzma dependency IIRC). But it is
tags 540232 + pending
thanks
Hi Daniel,
Apparently [1] XZ Utils and Lzip both provide an lzdiff command. The
XZ Utils version is meant for comparing .lzma files, though it also
can compare .xz, .gz, and .bz2 files. From the Lzip manual I gather
that its version compares .lz, .gz, and .bz2 files,
Daniel Baumann wrote:
no hard feelings and no strong opinions, but from the namespace used in
both packages, it would make most sense to me that lzdiff is in lzip,
and xzdiff is in xz-utils.
That sounds reasonable. xz-utils only includes lzdiff command for
compatibility with the lzdiff
Hi Robert,
I noticed this bug was tagged moreinfo. What information could I
provide to help investigate this bug? I would be glad to try various
commands, apply patches with printf lines, etc - just let me know
what's useful.
Thanks,
Jonathan
--
To UNSUBSCRIBE, email to
Felix Zielcke wrote:
We believe that the bug you reported is fixed in the latest version of
grub2, which is due to be installed in the Debian FTP archive:
[...]
- fix a serious memory corruption in the graphical subsystem.
(Closes: #545364, #544155, #544639, #544822, LP: #424503)
tags 505872 + fixed-upstream
thanks
This was fixed upstream in revision 330 configure.in: patch from
dodji seketeli to change configure.in, and the fix is included in
0.1.10. The fix was to use AC_USE_SYSTEM_EXTENSIONS to define
_GNU_SOURCE globally.
Somewhat off topic: I tried compiling the
The following is only a workaround, but it has been working well for me:
1. install libdrm-dev
2.
cd /usr/include/drm
for i in *.h
do dpkg-divert --package libdrm-dev --divert \
/usr/local/include/drm.libc/$i \
/usr/include/drm/$i
3.
Hi again,
Daniel Baumann wrote:
Jonathan Nieder wrote:
From the Lzip manual I gather
that its version compares .lz, .gz, and .bz2 files, but I couldn't
tell whether it handles .lzma files.
the manpage is not up2date (going to fix that, thanks for the pointer ;).
lzdiff is just a shell
FYI: http://lists.gnu.org/archive/html/lzip-bug/2009-08/msg1.html
Thanks for bringing that to my attention, Vincent. Looks like this
won't be a problem in the long term, thank goodness.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe.
Hi Vincent,
You wrote:
On 2009-08-13 12:07:18 -0500, Jonathan Nieder wrote:
I have a few choices:
1. Make xz-lzma conflict with lzip. [...]
This is unacceptable.
Could you clarify why? People who want to deal with both file formats
can install xz-utils at the same time as lzip (they won't
Hi Kees,
You wrote:
It seems that the license of the package needs further examination. It
cannot be Public Domain, since it is derived from the lzma package.
LZMA Utils and XZ Utils were both developed by Lasse Collin in
collaboration with Igor Pavlov. Lasse Collin is the maintainer of both
Vincent Lefevre wrote:
Sorry, I mixed up xz-lzma (which I didn't know) and xz-utils.
That's okay. xz-lzma contains programs and compatibility symlinks
providing the interface of the legacy LZMA Utils package. Those who
don't need the old command names can just install xz-utils, those who
want
Daniel,
You wrote:
as you pointed out, both tools do different things. so name it different
- xzdiff as it should imho have been named by upstream in the first place.
lzdiff and lzgrep originated in LZMA Utils, in 2007 I think. Maybe the
initial letters lz are too precious and they should
reopen 541391
tags 541391 + pending
thanks
Hi Kees,
I think I understand the problem a bit better now. The packaging
prepared for experimental, including debian/copyright, was based on
upstream commit a6f43e6, but because of a miscommunication the version
uploaded had upstream version
Hi Bastian,
You wrote:
xz-utils conflicts with the pseudo-essential package lzma. This makes it
uninstallable at all.
Could you explain further? xz-utils in experimental
Conflicts/Provides/Replaces lzma, and I have no trouble installing it.
(In the next version [1], it will be a separate
Bastian Blank wrote:
| WARNING: The following essential packages will be removed.
| This should NOT be done unless you know exactly what you are doing!
| lzma (due to dpkg)
| 0 upgraded, 2 newly installed, 1 to remove and 81 not upgraded.
| Need to get 259kB of archives.
| After this
Hi APT team,
The xz-utils package in experimental Conflicts/Replaces/Provides the
pseudo-essential package lzma. I think this should be fine, since
installing it only involves overwriting the lzma package rather than
removing it. Indeed, with dpkg or aptitude it installs fine, and
Please do not CC the APT team on follow-ups --- it looks like APT
already does the right thing here (sorry for the noise!).
I wrote:
The xz-utils package in experimental Conflicts/Replaces/Provides the
pseudo-essential package lzma. I think this should be fine, since
installing it only
Sven Joachim wrote:
If not, any pointers for one who wants to fix it? In either case, is
there a standard workaround?
Remove the Conflicts: lzma
Yep, that'll do it. Thanks! Sorry for the confusion and the noise.
Regards,
Jonathan
--
To UNSUBSCRIBE, email to
Eugene V. Lyubimkin wrote:
Jonathan Nieder wrote:
What I meant to achieve is accomplished with Replaces/Provides without
the Conflicts. Once xz-utils has written over all the files of lzma,
lzma would be marked as uninstalled, so normally the two packages
would not be installed at once
tags 542060 + pending
thanks
This should be fixed with xz-lzma 4.999.8beta+20090817-1 + lzma
4.43-15 by using alternatives. Thanks to Mohammed Adnène Trojette for
pointing out the very clean fix. See the Debian lzma commit log [1]
for details.
[1]
retitle 544731 missing insmod lvm in grub.cfg (error: no such disk)
tags 544731 + unreproducible
thanks
Maybe the more specific title will make this easier to find once the bug
comes back.
Thanks,
Jonathan
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of
tags 544872 + fixed-upstream patch pending
thanks
As you mentioned, upstream commit 3ce1916c (Fix data corruption in
LZ/LZMA2 encoder., 2009-08-16) fixes this.
Thanks for the report,
Jonathan
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe.
Christian PERRIER wrote:
This bug will only appear on lenny-sid upgrades because the version in
lenny is 2.86.ds1-61, that has the offending manpage. It was removed
later on in sysv-rc package development. Beware the sysv-rc
maintainers disabled the inclusion of the manpage, but only
Nicolas François wrote:
On Fri, Mar 19, 2010 at 05:54:56AM -0500, jrnie...@gmail.com wrote:
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
Christian PERRIER wrote:
Quoting Jonathan Nieder (jrnie...@gmail.com):
I think a Replaces should be good enough. After all, this doesn’t
actually break the old sysv-rc version.
I was balanced about these choices and they show the limits of my
knowledge, sometimes, when it comes at package
Jonathan Nieder wrote:
There is a downside: if someone installs sysv-rc/lenny with
manpages-fr-extra/squeeze and then uninstalls or downgrades
manpages-fr-extra, then the update-rc.d manpage goes missing until
manpages-fr-extra is reinstalled. Once can prevent this by forcing
# git-core’s t7400.24 results:
# I have to admit I’m mystified, since nothing has changed recently
# in this area of the git source code.
# Porters, has anything possibly relevant (configuration changes?)
# happened recently?
#
# Please send follow-ups to the bug address.
# okia64 (zx6000)
Stephen Powell wrote:
If you're using Hercules, you have to define the the machine in Hercules
as a 64-bit machine, such as a z800, z900, etc. A 64-bit kernel won't
run on an ESA/390 processor.
Probably I misconfigured it. With hercules 3.06-1.3, I tried
ARCHMODE z/Arch in the configuration
Jonathan Nieder wrote:
okia64 (zx6000) 1.6.5-1~bpo50+1 2010-01-19
okia64 (mundy) 1.6.6.12010-01-28
FAIL ia64 (alkman) 1.6.6.2 2010-02-12
okia64 (alkman) 1.7.0 2010-02-16
okia64 (alkman) 1.7.0 2010-02-16
okia64 (alkman
Jonathan Nieder wrote:
Therefore if anyone has a system that can reproduce this failure, I
would be very happy. Simple recipes to try out:
setup:
curl http://kernel.org/pub/software/scm/git/git-1.7.0.3.tar.bz2 |
tar -xf -
cd git*
echo NO_CURL=1 config.mak
echo NO_EXPAT=1
in binutils-multiarch.
+
+ -- Jonathan Nieder jrnie...@gmail.com Wed, 31 Mar 2010 23:46:14 -0500
+
binutils (2.20.51.20100227-1) experimental; urgency=low
* Snapshot, taken from the trunk 20100227.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject
Jonathan Nieder wrote:
| In file included from ../../dbg/libps2fd.h:15,
| from ../../dbg/debug.h:4,
| from lua.c:28:
| ../../dbg/regs.h:200:2: error: #error No regs_t defined?!
[...]
| make[3]: [lua.so] Error 1 (ignored)
On alpha, hppa, and sparc.
s/hppa/s390
retitle 544829 FTBFS: No regs_t defined (cp: cannot stat
`debian/tmp/usr/lib/radare/lua.so')
thanks
Hi,
Bastian Blank wrote:
cp: cannot stat `debian/tmp/usr/lib/radare/lua.so': No such file or directory
For what it’s worth:
| In file included from ../../dbg/libps2fd.h:15,
|
Hi Chris,
Christopher L Conway wrote:
the problem architectures are not directly supported by
upstream and I don't have access to testing machines for these
architectures, I'm not sure what the correct resolution is. Should I
remove these architectures in debian/control?
I’d suggest
Hi again,
Nice bug descriptions. :)
Christopher L Conway wrote:
What should be the disposition of this bug?
I guess it should be merged with one of the two offshoots.
Happy debugging,
Jonathan
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of
Source: grfcodec
Version: 0.9.10+svn2294-1
Severity: serious
grfcodec is failing to build on all buildds [1], with output like this:
-e [STRIP/UPX] grfmrgc.bin
make[1]: *** [grfmrgc.bin] Error 1
Maybe there is a missing build-time dependency.
[1]
retitle 566978 FTBFS: segfault in uim-module-manager [ia64 s390]
quit
Hi Kiwamu,
It seems [1] that now some other problem on ia64 is masking the failure.
Luckily, s390 segfaults as well.
Kiwamu Okabe wrote:
I would like to analyze coredump.
But I don't have an ia64 target.
Makes sense.
Do
Matthijs Kooijman wrote:
grfcodec is failing to build on all buildds [1], with output like this:
Not all, it works on a few architectures. The reason for this is that grfcodec
uses upx to do binary compression, which only works on the more common
architectures.
I've already prepared a new
-ruby1.8
uninstallable with recent ruby1.8 versions.
Fix it by explicitly allow ruby1.8 as an alternative
implementation.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
I noticed this when trying the big upgrade with aptitude.
Thoughts?
debian/changelog |6 ++
debian/control
Lucas Nussbaum wrote:
On 05/04/10 at 01:52 -0500, Jonathan Nieder wrote:
Starting with version 1.8.7.249-3, the ruby1.8 package provides
and conflicts with irb1.8.
[...]
Yes, I'm planning to wait one more day for ruby1.8 and ruby1.9.1 to
reach unstable on all archs, then determine the list
on
libopenssl-ruby1.8 makes it uninstallable with recent ruby1.8 versions.
Fix it by explicitly allowing libruby1.8 as an alternative
implementation.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Hi again,
Here’s another patch for the same ruby1.8 change I mentioned at
http://bugs.debian.org
unarchive 568416
reassign 568851 linux-2.6 2.6.32-7
forcemerge 568416 568851
quit
dpdt1 dp...@espiv.net wrote:
wine does not start at all. message is 'Segmentation fault'.
[...]
Kernel: Linux 2.6.32-2-amd64 (SMP w/2 CPU cores)
Vincent Fourmond wrote:
I've had the problem with wine (and
1 - 100 of 733 matches
Mail list logo
