Bug#901897: git introduces new hazardous working-tree-encoding attribute

severity 851679 wishlist tags 851679 + upstream clone 901897 -1 retitle -1 dgit fails autopkgtest: true/false are no valid working-tree-encodings reassign -1 dgit 5.0 retitle 901897 git needs Breaks against dgit versions without working-tree-encoding support block 901897 by -1 quit Hi Ian, Ian

Bug#901897: git introduces new hazardous working-tree-encoding attribute

Hi Ian, My mail host appears to be blacklisted on your end: > There was a problem delivering your message to > ijack...@chiark.greenend.org.uk. See the technical details below, or > try resending in a few minutes. > > The response was: > 550 Blacklisted site `[74.125.83.53]' [Irritated] What is

Bug#901900: git introduces new hazardous working-tree-encoding attribute

Ian Jackson wrote: > 5.1 is ready and has passed all its tests. It works fine with the git > in sid. I am not able to upload it right now, but this will happen > later today. Thanks. $ git ls-remote git://git.chiark.greenend.org.uk/~ianmdlvl/dgit.git fatal: Could not read from remote reposit

Bug#901900: dgit in stretch-backports

Hi Sean et al, Once git 2.18.0 is in testing, I want to update the git package in stable-backports. This would require updating dgit as well to a version supports the working-tree-encoding attribute (https://bugs.debian.org/901900). Do you plan to update dgit in backports once it hits testing?

Bug#901900: dgit in stretch-backports

Ian Jackson wrote: > Jonathan Nieder writes ("Bug#901900: dgit in stretch-backports"): >> Once git 2.18.0 is in testing, I want to update the git package in >> stable-backports. This would require updating dgit as well to a >> version that supports the working-tr

Bug#901900: dgit in stretch-backports

Hi Sean, Sean Whitton wrote: > On Fri, Jun 22 2018, Jonathan Nieder wrote: >> Do you plan to update dgit in backports once it hits testing? > > Yes. Excellent, thank you. [...] >> Is there anything I can do to help? For example, should I prepare an >> upload for 4

Bug#901900: dgit in stretch-backports

hink that's the situation we're in. > On Fri, Jun 22 2018, Jonathan Nieder wrote: >> Is there somewhere I can read more about that policy? Not that I'm >> complaining :) > > https://backports.debian.org/Contribute/ > > "... you have to ... update your

Bug#901897: closed by Jonathan Nieder (Bug#901897: fixed in git 1:2.18.0~rc2-2)

Hi, Ian Jackson wrote: > Paul Gevers writes ("Re: Bug#901897 closed by Jonathan Nieder > (Bug#901897: fixed in git 1:2.18.0~rc2-2)"): >> And I just helped the test for git a bit as due to bug 896023 in >> autopkgtest it didn't use the right autopkgtest from dgi

Bug#901900: dgit in stretch-backports

Hi Sean, Sean Whitton wrote: > On Fri, Jun 22 2018, Jonathan Nieder wrote: >> Is there somewhere I can read more about that policy? Not that I'm >> complaining :) > > https://backports.debian.org/Contribute/ > > "... you have to ... update your backpor

Bug#888549: chrome-gnome-shell: Please don't use /etc/opt, it's not FHS-compliant

Hi, Jeremy Bicha wrote: > On Thu, Sep 13, 2018 at 4:40 PM Santiago Vila wrote: >> What I said is that no sane package in Debian/main should need to put >> files directly in /etc/opt. That's an oddity, a very unorthodox thing, >> it would be like a Debian package in main putting stuff directly in

Bug#888549: chrome-gnome-shell: Please don't use /etc/opt, it's not FHS-compliant

Jeremy Bicha wrote: > On Thu, Sep 13, 2018 at 5:57 PM Jonathan Nieder wrote: >>> There is no reason this functionality cannot be offered in Debian. We >>> got complaints when we supported other browsers but not Google Chrome. >> >> Since Google Chrome is n

Bug#919296: git-daemon-run: fails with 'warning: git-daemon: unable to open supervise/ok: file does not exist'

Hi, Celejar wrote: > Severity: grave > > Any attempt to manage the daemon (e.g., 'sv stat git-daemon', as per > README.debian) fails with: > > warning: git-daemon: unable to open supervise/ok: file does not exist > > I see that there's an old, archived bug about this: > > https://bugs.debian.org/

Bug#919296: git-daemon-run: fails with 'warning: git-daemon: unable to open supervise/ok: file does not exist'

Hi again, Celejar wrote: > Severity: grave > > Any attempt to manage the daemon (e.g., 'sv stat git-daemon', as per > README.debian) fails with: > > warning: git-daemon: unable to open supervise/ok: file does not exist [...] > Versions of packages git-daemon-run depends on: > ii adduser 3.118 >

Bug#919296: git-daemon-run: fails with 'warning: git-daemon: unable to open supervise/ok: file does not exist'

# missing Depends severity 919296 serious quit Celejar wrote: >> Celejar wrote: >>> Any attempt to manage the daemon (e.g., 'sv stat git-daemon', as per >>> README.debian) fails with: >>> >>> warning: git-daemon: unable to open supervise/ok: file does not exist [...] > ii runit 2.1.2-22

Bug#919296: git-daemon-run: fails with 'warning: git-daemon: unable to open supervise/ok: file does not exist'

description (thx Jens Reyer; closes: #707790). + * git-daemon-run: pre-create supervise directory so that postinst +can start the service (thx Celejar and Dmitry Bogatov; closes: +#919296). -- Jonathan Nieder Mon, 21 Jan 2019 19:36:25 -0800 diff --git i/debian/git-daemon-run.

Bug#919296: git-daemon-run: fails with 'warning: git-daemon: unable to open supervise/ok: file does not exist'

tags 919296 - patch pending quit Jonathan Nieder wrote: > For "buster", I prefer a minimal fix within the framework of the > current packages, along the lines you suggested upthread: > > diff --git i/debian/changelog w/debian/changelog > index ef513b2e1d..fb996c9

Bug#919296: git-daemon-run: fails with 'warning: git-daemon: unable to open supervise/ok: file does not exist'

Dmitry Bogatov wrote: >> Jonathan Nieder wrote: >>> + * git-daemon-run: pre-create supervise directory so that postinst >>> +can start the service (thx Celejar and Dmitry Bogatov; closes: >>> +#919296). [...] > Wierd. It should work. /etc/sv/git-daemo

Bug#915426: git breaks git-remote-hg autopkgtest

Hi Jonas, Jonas Smedegaard wrote: > I can do yet another NMU to fix this, but am hesitating as I worry if > that will masquerade a lack of responsive maintenance. > > Please tell if it is sensible that I take over maintenance of this > package, or join as co-maintainer, or however is appreciated.

Bug#915426: git breaks git-remote-hg autopkgtest

Hi again, On 25 January 2019, Jonathan McCrohan wrote: > I am happy to work on fixing up the FTBFS, but > because I am not a DD, I would need a sponsor to upload for me. I'm happy to sponsor an upload, especially if this is a first step toward team maintenance with Jonas (who I can speak from ex

Bug#985416: Bug#986565: unusable with current git

Hi, >> On Wed, 21 Apr 2021 10:12:03 + Damyan Ivanov wrote: >>> Sigh. Now git reverted to using /usr/lib again, and git-flow is broken. Why sigh? Directories such as /usr/lib/git-core and /usr/libexec/git-core are internal to git. Other packages should not install to either directory. Thi

Bug#985351: git: Moved git-sh-prompt shell library breaks user code

Hi! Guillem Jover wrote: > The latest version in sid, breaks user code sourcing the git-sh-prompt > shell library as it moved from /usr/lib/ to /usr/libexec, even though > I see the comment there says to copy it, but that means no automatic > upgrades. :/ > > Could you perhaps add a backwards com

Bug#972871: git-el: .el files not installed / byte-compiled

Hi, Zack Weinberg wrote: > While updating my emacs configuration for 27.1 (now in unstable) > I noticed that /etc/emacs/site-start.d/50git-core.el prints > > git removed but not purged, skipping setup > > and does not autoload either git.el or git-blame.el. This appears to > be because /usr/lib/

Bug#972871: git-el: .el files not installed / byte-compiled

tags 972871 + patch pending quit Jonathan Nieder wrote: > Thanks for reporting. > > Strangely, debian-emacs-policy doesn't appear to be in the > emacsen-common package any more. Fortunately, it's in > https://www.debian.org/doc/packaging-manuals/debian-emacs-policy.

Bug#868738: git FTBFS on several architectures: not ok 134 - --dump-aliases must be used alone

Hi, Adrian Bunk wrote: > https://buildd.debian.org/status/package.php?p=git&suite=sid > > expecting success: > test_must_fail git send-email --dump-aliases --to=jan...@example.com -1 > refs/heads/accounting > > --dump-aliases incompatible with other options > test_must_fail: command not f

Bug#871570: git FTBFS on i386: t7006-pager.sh test failure

found 871570 git/1:2.13.2-3 tags 871570 + upstream quit Hi, Adrian Bunk wrote: > https://buildd.debian.org/status/fetch.php?pkg=git&arch=i386&ver=1%3A2.14.0-1&stamp=1502132890&raw=0 > > ... > expecting success: > ( > sane_unset LESS LV && > PAGER="env >pager-en

Bug#1009167: xz-utils: diff for NMU version 5.2.5-2.1

Hi Salvatore, Salvatore Bonaccorso wrote: > On Sun, Apr 10, 2022 at 03:08:12PM +0200, Salvatore Bonaccorso wrote: >> I've prepared an NMU for xz-utils (versioned as 5.2.5-2.1) and >> uploaded it to DELAYED/2. Please feel free to tell me if I >> should delay it longer. > > I noted that the last up

Bug#942353: python-evtx: ImportError: No module named hexdump

Package: python-evtx Version: 0.6.1-1 Severity: serious Justification: missing dependency $ evtx_dump.py Traceback (most recent call last): File "/usr/bin/evtx_dump.py", line 20, in import Evtx.Evtx as evtx File "/usr/local/buildtools/current/sitecustomize/sitecustomize.py", line 152, in

Bug#949454: libctf-nobfd0: missing Breaks+Replaces against libbinutils versions with the same files

Package: libctf-nobfd0 Version: 2.33.50.20200115-2 Severity: serious Rationale: breaks upgrades libctf-nobfd0 takes over the file libctf-nobfd.so.0.0.0 from libbinutils but is missing a Breaks + Replaces declaring so: Unpacking libctf-nobfd0:amd64 (2.33.50.20200115-2) ... dpkg: error processing

Bug#945961: xz-utils: FTBFS: cannot stat 'debian/tmp/usr/lib/x86_64-linux-gnu/liblzma.so.*'

Hi, Sebastian Andrzej Siewior wrote: > I don't know what changed but I think it is debhelper. We have now: > > |(sid)bigeasy@debbuildd:~/xz/1/xz-utils-5.2.4$ dh binary --no-act > | debian/rules install > | dh_installdeb > | dh_gencontrol > | dh_md5sums > | dh_builddeb > > and that "debi

Bug#914695: dgit autopkgtest breaks with git 2.20

Hi Ian, Ian Jackson wrote: > https://ci.debian.net/data/autopkgtest/testing/amd64/d/dgit/1382882/log.gz [...] > Looking at the test log did not immediately suggest a cause to me. > But it is probably much easier for me to (at least initially) > investigate this, since I will hopefully underst

Bug#915426: git breaks git-remote-hg autopkgtest

Paul Gevers wrote: > https://ci.debian.net/data/autopkgtest/testing/amd64/g/git-remote-hg/1428119/log.gz > > not ok 32 - pull tags The package ought to run "make TEST_OPTS=-v" to produce a more useful log[*]. Bisects to the following Git change: e198b3a740409fabe5ba774c5f1255b55fdd21c1 is the f

Bug#884038: [git] 2.15.x fails to fetch remote repository

# regression but not reproducible severity 884038 important tags 884038 + upstream unreproducible quit Hi, mirq-debo...@rere.qmqm.pl wrote: > git 2.15.x from testing can't properly fetch from remote repository: > > $ git fetch --all > Fetching origin > remote: Counting objects: 752, done. > remo

Bug#900393: runit 2.1.2-14 breaks git-daemon-run

Package: runit Version: 2.1.2-14 Severity: serious Justification: breaks upgrades The changelog to runit 2.1.2-14 explains: * Do not install `update-service' script. but it doesn't give any more context than that. This breaks the git-daemon-run package, as noticed e.g. by piuparts: https:

Bug#901185: Checkbashisms

Hi, 積丹尼 wrote: Be sure the package passes Checkbashisms! > Which package? Is there a particular bashism you noticed? Please keep in mind that these reports appear as emails in a crowded inbox, where a little context in the subject line can go a long way. Thanks, Jonathan >

Bug#895446: gitk: Error in startup script: bad screen distance "4.5"

tags 895446 + moreinfo quit Hi Michael, Michael Biebl wrote: > gitk no longer successfully starts here. When I run it from a terminal, > I get > > $ gitk > Error in startup script: bad screen distance "4.5" > while executing > "$canv conf -scrollregion [list 0 0 $canvxmax $ymax]" > (proc

Bug#895446: gitk: Error in startup script: bad screen distance "4.5"

reassign 895446 libfontconfig1 2.13.0-2 severity 895470 serious retitle 895470 fontconfig-2.13.0 globally sets the locale from the environment forcemerge 895470 895446 affects 895470 + gitk tags 895470 + patch fixed-upstream quit Jonathan Nieder wrote: > Michael Biebl wrote: >> gitk

Bug#892488: pcre2: FTBFS on mips* - test failures

Hi, Matthew Vernon wrote: > On 09/03/18 15:20, James Cowgill wrote: >> Source: pcre2 >> Version: 10.31-1 >> Severity: serious [...] >> pcre2 FTBFS on mips* with lots of testsuite failures. It looks to me >> like the JIT is bust. >> >> I forwarded the log upstream to the above address. I'll try to

Bug#866059: Please remove the git-arch package

severity 866059 important tags 866059 + pending quit Hi Adrian, Adrian Bunk wrote: > Severity: serious Why? > Already for a couple of years, the only realistic usecase > for the tla package in Debian was to allow git-arch to > migrate repositories to git. > > The final release of GNU Arch was

Bug#860774: openldap on armhf and armel needs bootstrapping

Ryan Tandy wrote: > Debian Bug Tracking System wrote: >> Bug #860774 [libldap-2.4-2] relax dependency on libldap-common >> Added indication that 860774 affects src:git, src:heimdal, and src:subversion > > It will be a few more hours before I can get to an upload, so if > this is blocking others' w

Bug#955152: git-rebase ignores or squashes GIT_REFLOG_ACTION

Hi, Ian Jackson wrote[1]: > [ some git-debrebase invocation etc. ] > + git reflog > + egrep 'debrebase new-upstream.*checkout' > + rc=1 > > I have looked at the log and repro'd the bug. > > git-debrebase (which lives in src:dgit but does not depend on dgit) > must invoke git-rebase. It sets GIT_

Bug#965350: kgb-bot: autopkgtest makes assumption about exact merge commit message

Source: kgb-bot Version: 1.56-1 Tags: upstream Severity: serious Justification: tests fail with up-to-date Git Affects: src:git >From >https://ci.debian.net/data/autopkgtest/testing/amd64/k/kgb-bot/6323993/log.gz: | not ok 71 | | # Failed test at t/52-client-git.t line 393. | # got: '

Bug#961702: git breaks fdroidserver autopkgtest: Failed to parse line: ' git config pull.rebase false

reassign 961702 python3-git 3.1.1-1 affects 961702 git quit Hi, Hans-Christoph Steiner wrote: > I can't find any possible reference in fdroidserver, or in python3-git > for that matter. My guess is that the issue is caused by python3-git > failing to parse something that was added in the most r

Bug#1073515: git: FTBFS on mips64el

Source: git Version: 1:2.45.2-1 Severity: serious Justification: FTBFS (but possibly unreproducibly?) https://buildd.debian.org/status/logs.php?pkg=git&arch=mips64el shows the git package fairly regularly failing to build on mips64el this year. Example failure: ``` expecting success of 5526.25 '

Bug#516544: How I installed libdrm-dev on top of linux-libc-dev

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. insta

Bug#540232: xz-utils: undeclared conflict with lzip

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,

Bug#540232: xz-utils: undeclared conflict with lzip

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 comm

Bug#540232: xz-utils: undeclared conflict with lzip

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 th

Bug#540232: Bug #540232: xz-utils: undeclared conflict with lzip

FYI: 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". T

Bug#540232: xz-utils: undeclared conflict with lzip

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-uti

Bug#541391: LZMA license inaccuracy

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 b

Bug#540232: xz-utils: undeclared conflict with lzip

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 t

Bug#540232: xz-utils: undeclared conflict with lzip

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

Bug#505872: Bug #505872 fixed upstream

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 n

Bug#541391: LZMA license inaccuracy

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 4.999.8beta

Bug#542060: xz-utils - Conflicts with pseudo-essential package

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 xz

Bug#542060: xz-utils - Conflicts with pseudo-essential package

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

Bug#542060: Replacing an essential package

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 /var/log/dpkg.lo

Bug#542060: Replacing an essential package

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 invo

Bug#542060: Replacing an essential package

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 debian-bugs-rc-requ...

Bug#542060: Replacing an essential package

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 >>

Bug#542060: xz-utils - Conflicts with pseudo-essential package

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]

Bug#544731: "error: no such disk" renders system unbootable

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

Bug#544872: xz-utils: data corruption in the compression code

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".

Bug#544872: closed by Jonathan Nieder (Closing xz-utils bugs fixed by version 4.999.9beta-1)

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

Bug#569594: git-core: test suite fails on ia64

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 woul

Bug#564087: Unable to reproduce

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 "sl

Bug#569594: Looking for access to an s390 (git-core: [FTBFS] t7400-submodule-basic.sh fails)

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 th

Bug#514220: [PATCH] Re: Bug#514220: ca-certificates: debconf update destroys local config

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

Bug#569896: Subject: directfb-1.2: After upgrade, many applications refuse to start due to not finding libdirectfb-1.2.so.0

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: libdir

Bug#569815: fixed in directfb 1.2.10really1.2.8-1

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.

Bug#568620: help on porting to s390

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 [...] | life/lif

Bug#572648: unifdef: copyright file is out of date

-- %< -- From: Jonathan Nieder Subject: Update debian/copyright --- debian/copyright | 167 + 1 files changed, 154 insertions(+), 13 deletions(-) diff --git a/debian/copyright b/debian/copyright index e82eec7..1452457 100644 --- a/deb

Bug#544822: grub-pc: out of range pointer 0x8080810 with r128 graphics card

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 debian-bugs-rc-req

Bug#544822: closed by Felix Zielcke (Bug#544822: fixed in grub2 1.97~beta3-1)

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)

Bug#572648: unifdef: copyright file is out of date

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 licens

Bug#571027: Patch for this file conflict bug...

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 > te

Bug#571027: Patch for this file conflict bug...

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. > >

Bug#571027: Patch for this file conflict bug...

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 > k

Bug#571027: Patch for this file conflict bug...

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

Bug#569594: git t7400.24 is failing again

# 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) 1.

Bug#569594: git t7400.24 is failing again

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 configura

Bug#569594: git t7400.24 is failing again

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-

Bug#569594: git t7400.24 is failing again

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*

Bug#576126: binutils-multiarch: missing diversion for /usr/bin/elfedit

,9 @@ +binutils (2.20.51.20100227-1.1) local; urgency=low + + * Add diversion for elfedit in binutils-multiarch. + + -- Jonathan Nieder 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, e

Bug#544829: radare - FTBFS: No regs_t defined

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,

Bug#544829: radare - FTBFS: cp: cannot stat `debian/tmp/usr/lib/radare/lua.so': No such file or directory

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, |f

Bug#575002: cvc3: FTBFS on various archs/in various ways

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 some

Bug#575002: cvc3: FTBFS on various archs/in various ways

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 "unsubscr

Bug#576374: FTBFS: *** [grfmrgc.bin] Error 1 [alpha, armel, hppa, ia64, s390, sparc]

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] https://buildd.debian.org/status/package.php?p

Bug#566978: FTBFS on ia64 (segfault in uim-module-manager)

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

Bug#563882: git-core FTBFS on ia64: t1001-read-tree-m-2way.sh test fails

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 8e4020bb5a8d8c873

Bug#563882: git-core FTBFS on ia64: t1001-read-tree-m-2way.sh test fails

Andreas Metzler wrote: > On 2010-01-09 Jonathan Nieder wrote: >> -- %< -- M.out >> 100644 346d4e61f111336a1443ef6b2e834aa5b1a7f91a 0bozbar >> 100644 8e4020bb5a8d8c873b25de15933e75cc0fc275df 0frotz >> 100644 dca6b92303befc93086aa025d90a5facd7eb2812 0

Bug#563882: git-core FTBFS on ia64: t1001-read-tree-m-2way.sh test fails

Hi again, Andreas Metzler wrote: > ametz...@merulo:/tmp/GIT/git-core-1.6.6-debug/t/trash > directory.t1001-read-tree-m-2way$ /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 attac

Bug#563882: git-core FTBFS on ia64: t1001-read-tree-m-2way.sh test fails

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 > > If M.out (but not stdin) is reported to be binary, great:

Bug#563882: [PATCH git] ignore test suite failures on ia64 (was Bug#563882: git-core FTBFS on ia64: t1001-read-tree-m-2way.sh test fails)

kernel is broken. Holding back the updated git binaries doesn’t do anyone any good, so ignore the result of the test suite for now. Works-around: http://bugs.debian.org/563882 Reported-by: Anders Kaseorg Investigated-by: Andreas Metzler Signed-off-by: Jonathan Nieder --- Andreas Metzler wrote

Bug#563882: [PATCH v2 git] debian/rules: ignore test suite failures on ia64

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 Investigated-by: Andreas Metzler Signed-off-by: Jonathan Nieder --- > + : 'ignoring test suite failures (see Bug#563882)' &g

Bug#563882: git-core FTBFS on ia64: t1001-read-tree-m-2way.sh test fails

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; ls

Bug#568612: shogun: FTBFS due to doxygen bug#564338

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 \ | Classifier/d

Bug#568612: shogun: FTBFS due to doxygen bug#564338

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 >> >

Bug#568612: shogun: FTBFS due to doxygen bug#564338

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

  1   2   3   4   5   6   7   8   >