Bug#843627: Give back mercurial for armhf
Hi, mercurial 4.0-1 failed to build on armhf because test-largefiles-update.t failed[0]. I've tested it on a porterbox ten times and I can't reproduce the error. Can you please give it back for armhf and see if it was a transient error in the testsuite? gb mercurial_4.0-1 . armhf [0] https://buildd.debian.org/status/fetch.php?pkg=mercurial&arch=armhf&ver=4.0-1&stamp=1478103982 signature.asc Description: PGP signature
Bug#804167: fails to upgrade
On Fri, 6 Nov 2015 16:21:03 +0100 Andreas Henriksson wrote: > Hi again. > > On Fri, Nov 06, 2015 at 03:01:08PM +0100, Peter Palfrader wrote: > [...] > > But it should work. > > > > An "exit 0" at the end, or a "if [ -d ... ]; then rmdir .. ; fi" would > > also work instead and might be preferable. > > Please stop suggesting exit 0. It does not work. Hopefully the attached > minimal testcase will convince you of this. The final "exit 0" will > simply never be reached. run: ./foo.sh && echo $? > (Try also replace 'false' with 'false && true' to more exactly simulate > your particular bug case.) > > (... and even if it was reached, that would certainly throw away > any exit code - not just the rmdir one.) > > rmdir failing is not the end of the world anyway, it's just a > "lets be nice and clean up if we can" kind of thing. > > In your very obscure case that noone else triggered so far there > is no directory to clean up anyway, so don't worry! :P For the record, I've triggered this today when upgrading an aarch64 chroot. Maybe it's not that obscure ;) Cheers, Javi
Bug#804259: mercurial-git: TypeError: exchangepush() got an unexpected keyword argument 'opargs'
On Fri, Nov 06, 2015 at 06:50:01PM +0100, Jakub Wilk wrote:
> Package: mercurial-git
> Version: 0.8.2-1
> Severity: grave
>
> I can't push to git repos:
>
> $ git init gitrepo
> Initialized empty Git repository in /home/jwilk/gitrepo/.git/
>
> $ hg clone gitrepo hgrepo
> updating to branch default
> 0 files updated, 0 files merged, 0 files removed, 0 files unresolved
>
> $ cd hgrepo
> $ hg push
> pushing to /home/jwilk/gitrepo
> ** Unknown exception encountered with possibly-broken third-party extension
> git
> ** which supports versions 3.4 of Mercurial.
> ** Please disable git and try your action again.
> ** If that fixes the bug please report it to
> https://bitbucket.org/durin42/hg-git/issues
> ** Python 2.7.10+ (default, Oct 10 2015, 09:11:24) [GCC 5.2.1 20151028]
> ** Mercurial Distributed SCM (version 3.6)
> ** Extensions loaded: color, convert, gpg, graphlog, strip, mq, pager,
> progress, purge, rebase, record, shelve, git
> Traceback (most recent call last):
> File "/usr/bin/hg", line 43, in
>mercurial.dispatch.run()
> File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 54, in
> run
>sys.exit((dispatch(request(sys.argv[1:])) or 0) & 255)
> File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 116, in
> dispatch
>ret = _runcatch(req)
> File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 187, in
> _runcatch
>return _dispatch(req)
> File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 920, in
> _dispatch
>cmdpats, cmdoptions)
> File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 679, in
> runcommand
>ret = _runcommand(ui, options, cmd, d)
> File "/usr/lib/python2.7/dist-packages/mercurial/extensions.py", line 183,
> in closure
>return func(*(args + a), **kw)
> File "/usr/lib/python2.7/dist-packages/hgext/pager.py", line 139, in pagecmd
>return orig(ui, options, cmd, cmdfunc)
> File "/usr/lib/python2.7/dist-packages/mercurial/extensions.py", line 183,
> in closure
>return func(*(args + a), **kw)
> File "/usr/lib/python2.7/dist-packages/hgext/color.py", line 525, in colorcmd
>return orig(ui_, opts, cmd, cmdfunc)
> File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 1051, in
> _runcommand
>return checkargs()
> File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 1011, in
> checkargs
>return cmdfunc()
> File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 917, in
>
>d = lambda: util.checksignature(func)(ui, *args, **cmdoptions)
> File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 803, in check
>return func(*args, **kwargs)
> File "/usr/lib/python2.7/dist-packages/mercurial/extensions.py", line 183,
> in closure
>return func(*(args + a), **kw)
> File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 803, in check
>return func(*args, **kwargs)
> File "/usr/lib/python2.7/dist-packages/hgext/mq.py", line 3525, in mqcommand
>return orig(ui, repo, *args, **kwargs)
> File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 803, in check
>return func(*args, **kwargs)
> File "/usr/lib/python2.7/dist-packages/mercurial/commands.py", line 5426, in
> push
>opargs=opts.get('opargs'))
> File "/usr/lib/python2.7/dist-packages/mercurial/extensions.py", line 183,
> in closure
>return func(*(args + a), **kw)
> File "/usr/lib/python2.7/dist-packages/hgext/git/util.py", line 48, in inner
>return f(*args, **kwargs)
> TypeError: exchangepush() got an unexpected keyword argument 'opargs'
Gah, sorry for that, it's due to mercurial 3.6. I did a very brief
test of mercurial-git but I didn't test pushing to git repositories so
I missed it.
There isn't a new version of mercurial-git yet, so for the time being
downgrade to mercurial 3.5.2-2 as workaround.
Cheers,
Javi
signature.asc
Description: PGP signature
Bug#803082: [Python-modules-team] Bug#803082: Bug#803082: ipython ftbfs (too new lessc version)
On Fri, Oct 30, 2015 at 05:34:41PM +0100, Matthias Klose wrote: > On 30.10.2015 10:03, Brian May wrote: > >I suspect the solution to this is to update to use ipython 4.0.0 > > > >It looks like there have been significant structural changes in 4.0.0, > >so work is required to merge the patches (conflicts occur due to missing > >files) and update debian/rules. > > the 3.x series seems to be still recent enough, and still has the monolithic > approach. So maybe you'll see less surprises with this one? Julien Puydt (CCed) has been filing a number of ITPs for ipython/jupyter packages recently, so maybe he's also considering the transition to ipython 4.0.0. Cheers, Javi
Bug#794987: mercurial-git: failed to import extension hgext.git: No module named ignore
Control: forwarded -1 https://bitbucket.org/durin42/hg-git/issues/157/hg-git-081-doesnt-work-under-mercurial-35 On Sat, Aug 08, 2015 at 10:04:18PM -0400, James McCoy wrote: > Package: mercurial-git > Version: 0.8.1-2 > Severity: important > > In a repository using hg-git: > > $ hg status > *** failed to import extension hgext.git: No module named ignore > ** unknown exception encountered, please report by visiting > ** http://mercurial.selenic.com/wiki/BugTracker > ** Python 2.7.10 (default, Jul 1 2015, 10:54:53) [GCC 4.9.2] > ** Mercurial Distributed SCM (version 3.5) > ** Extensions loaded: color, graphlog, hgk, strip, mq, pager, purge, record, > rebase, histedit, gpg > Traceback (most recent call last): > File "/usr/bin/hg", line 43, in > mercurial.dispatch.run() > File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 30, in > run > sys.exit((dispatch(request(sys.argv[1:])) or 0) & 255) > File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 92, in > dispatch > ret = _runcatch(req) > File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 163, in > _runcatch > return _dispatch(req) > File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 862, in > _dispatch > repo = hg.repository(ui, path=path) > File "/usr/lib/python2.7/dist-packages/mercurial/hg.py", line 136, in > repository > peer = _peerorrepo(ui, path, create) > File "/usr/lib/python2.7/dist-packages/mercurial/hg.py", line 123, in > _peerorrepo > obj = _peerlookup(path).instance(ui, path, create) > File "/usr/lib/python2.7/dist-packages/mercurial/hg.py", line 93, in > _peerlookup > return thing(path) > File "/usr/lib/python2.7/dist-packages/hgext/git/__init__.py", line 84, in > _local > p = urlcls(path).localpath() > TypeError: 'NoneType' object is not callable Argh, yes, mercurial-git 0.8.1 doesn't work with hg 3.5. When I uploaded mercurial-git 0.8.1-2, I thought the breaks in mercurial would still be valid (but I didn't check it, and I should have). Sorry for that. I was waiting for a new version of mercurial-git to be released, but given that I've already broken it, I may backport the fix and release a 0.8.1-3 that is compatible with mercurial 3.5. Cheers, Javi signature.asc Description: Digital signature
Bug#699301: Bug#644559: O: python-uniconvertor -- Universal vector graphics translator
Hi Agustin, On Mon, 22 Jul 2013 18:11:57 +0200 Agustin Martin wrote: > On Wed, Jan 16, 2013 at 03:36:56PM -0200, Ronoaldo Jos� de Lana Pereira > wrote: > > 2013/1/15 Mathieu Malaterre > > > > > Ronoaldo, > > > > > > Do you still have interest in python-uniconvertor ? Apparently > > > updating to 1.1.5 is somewhat difficult since it now needs a new > > > dependency: > > > > > > http://ubuntuforums.org/showthread.php?p=11371010#post11371010 > > > > > > Mathieu, > > > > Indeed, I do want to help maitaining it. > > > > I'll join the team suggested before and try working on it while I'm still > > testing Wheezy. > > Forgot to cc this bug report and interested people when sending a followup > to #699301 and #592840 (cc'ed now). > > http://bugs.debian.org/699301 > http://bugs.debian.org/592840 > > The short story, I have been playing on building a 1.1.5 python-uniconvertor > package together with a new package python-sk1libs, the new dependency. > I did a minimal testing and resulting package seems to work, but this is my > first approach to python and everything I did needs extensive reviewing by > someone fluent with python, long story in above bug reports. > > I do not intend to adopt this package, so you may be interested in my > changes in > > http://anonscm.debian.org/gitweb/?p=users/agmartin/TMP/python-sk1libs.git;a=summary > http://anonscm.debian.org/gitweb/?p=users/agmartin/TMP/python-uniconvertor.git;a=summary > > Note that python-modules team seems to have SVN as preferred VCS (fix me if > this is no longer true) I'm looking into importing your packaging of python-sk1libs and python-uniconvertor into the Python Modules team and fixing #699301 at last. In your email you state that you don't want to adopt the package but python-sk1libs/debian/control shows you as maintainer. Are you ok with me changing that to the Debian Python Modules team? Cheers, Javi signature.asc Description: Digital signature
Bug#750444: [Python-apps-team] Bug#750444: mercurial: Doesn't work
On Tue, Jun 03, 2014 at 03:21:22PM +0200, Jakub Wilk wrote: > * Christian Marillat , 2014-06-03, 14:47: > >AttributeError: httpsconnection instance has no attribute '_set_hostport' > > Patch: > http://hg.intevation.org/mercurial/crew/rev/21b3513d43e4 I'm unable to reproduce this with mercurial 3.0. In any case, that patch is part of mercurial 3.0.1, which I'll upload soon. Cheers, Javi signature.asc Description: Digital signature
Bug#721949: klavaro: Depends on a virtual package
Package: klavaro
Severity: grave
Justification: renders package unusable
klavaro is uninstallable in sid:
$ aptitude install klavaro
The following NEW packages will be installed:
klavaro{b}
0 packages upgraded, 1 newly installed, 0 to remove and 37 not upgraded.
Need to get 780 kB of archives. After unpacking 2400 kB will be used.
The following packages have unmet dependencies:
klavaro : Depends: libgtkdatabox-0.9.1-1 which is a virtual package.
The following actions will resolve these dependencies:
Keep the following packages at their current version:
1) klavaro [Not Installed]
Accept this solution? [Y/n/q/?]
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.10-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#665890: python-greenlet: FTBFS on mips*: "error: $fp cannot be used in asm here"
On Mon, 26 Mar 2012 21:08:35 +0100, Adam D. Barratt wrote: > Source: python-greenlet > Version: 0.3.3-1 > Severity: serious > > python-greenlet no longer builds on mips*. From the mipsel build log: > > creating build/temp.linux-mips-2.6-pydebug > gcc -pthread -fno-strict-aliasing -g -Wall -Wstrict-prototypes -fPIC > -I/usr/include/python2.6_d -c greenlet.c -o > build/temp.linux-mips-2.6-pydebug/greenlet.o > In file included from slp_platformselect.h:32:0, > from greenlet.c:390: > platform/switch_mips_unix.h: In function 'slp_switch': > platform/switch_mips_unix.h:43:1: error: $fp cannot be used in asm here > error: command 'gcc' failed with exit status 1 This doesn't happen on the sid version of the package because that code is actually dead code that's not used. In 0.3.1-1 it's compiled without optimizations so it fails but in 0.4.0 it's compiled with -O2, the code is optimized out and the build succeeds. I'm going to upload 0.3.1-2.2 to TPU (delayed/5) which fixes this and #699102. Cheers, Javi signature.asc Description: Digital signature
Bug#699102: python-greenlet: FTBFS on sparc
Package: python-greenlet Version: 0.3.1-2.2 Severity: serious Justification: FTBFS The FTBFS in sparc[0] in wheezy can be fixed by applying the attached patch [0] https://buildd.debian.org/status/fetch.php?pkg=python-greenlet&arch=sparc&ver=0.3.1-2.2&stamp=1359234024 Cheers, Javi Author: unixtool1192 Origin: https://github.com/python-greenlet/greenlet/commit/619ab917e3ab47be7642ced21c8cfd8e8182844b Description: add support for debian sparc and openbsd5-sparc64 --- a/platform/switch_sparc_sun_gcc.h +++ b/platform/switch_sparc_sun_gcc.h @@ -19,9 +19,9 @@ #ifdef SLP_EVAL -#include #define STACK_MAGIC 0 +#define ST_FLUSH_WINDOWS 3 static int slp_switch(void) --- a/slp_platformselect.h +++ b/slp_platformselect.h @@ -12,7 +12,7 @@ #include "platform/switch_ppc_unix.h" /* gcc on PowerPC */ #elif defined(__GNUC__) && defined(__ppc__) && defined(__APPLE__) #include "platform/switch_ppc_macosx.h" /* Apple MacOS X on PowerPC */ -#elif defined(__GNUC__) && defined(sparc) && defined(sun) +#elif defined(__GNUC__) && defined(sparc) #include "platform/switch_sparc_sun_gcc.h" /* SunOS sparc with gcc */ #elif defined(__GNUC__) && defined(__s390__) && defined(__linux__) #include "platform/switch_s390_unix.h" /* Linux/S390 */
Bug#661441: src:genshi: tests fail under python2.7, but failure is ignored
Stefano Rivera wrote: > == > FAIL: test_sanitize_remove_src_javascript > (genshi.filters.tests.html.HTMLSanitizerTestCase) > -- > Traceback (most recent call last): > File "/«PKGBUILDDIR»/genshi/filters/tests/html.py", line 442, in > test_sanitize_remove_src_javascript > '') > AssertionError: ParseError not raised > > -- > Ran 828 tests in 1.198s > > FAILED (failures=1) > > Yet, the build continues... FWIW, to make the build fail (which it should) apply this patch (thanks to POX): --- a/debian/rules +++ b/debian/rules @@ -16,7 +16,7 @@ DEB_PYTHON_SETUP_CMD += --with-speedups ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS))) binary-install/python-genshi:: - for py in $(shell pyversions -vr); do \ + set -e; for py in $(shell pyversions -vr); do \ PYTHONPATH=$(cdbs_python_destdir)/usr/lib/python$$py/site-packages \ python$$py setup.py test; \ done; signature.asc Description: Digital signature
Bug#668025: mercurial: FTBFS[kfreebsd-amd64]: testsuite failure
On Tue, Apr 10, 2012 at 08:21:00AM +0200, Julien Cristau wrote: > On Sun, Apr 8, 2012 at 13:27:03 +0200, Christoph Egger wrote: > > > Your package failed to build on the kfreebsd-amd64 buildds: > > > > --- > > /build/buildd-mercurial_2.1.2-2-kfreebsd-amd64-aq2Wfm/mercurial-2.1.2/tests/test-symlink-placeholder.t > > +++ > > /build/buildd-mercurial_2.1.2-2-kfreebsd-amd64-aq2Wfm/mercurial-2.1.2/tests/test-symlink-placeholder.t.err > > @@ -29,7 +29,6 @@ > >$ rm b > >$ echo foo > b > >$ hg --config extensions.n=$TESTTMP/nolink.py status --debug > > - ignoring suspect symlink placeholder "b" > > > > Make a clone using placeholders: > > > > > > ERROR: > > /build/buildd-mercurial_2.1.2-2-kfreebsd-amd64-aq2Wfm/mercurial-2.1.2/tests/test-symlink-placeholder.t > > output changed > > > Out of 4 tries on kfreebsd-amd64 for this version, it failed 3 times on > 3 different tests, and succeeded on the fourth build. Not sure I > understand this particular one, but I think it's more likely to be an > unreliable test than a new bug. None of the changes from 2.1.2-1 to 2.1.2-2 should affect these tests, so that's actually 2 successful builds out of 5. On some architectures the testsuite is unreliable. If this happens again, I'll probably stop running it on kfreebsd-amd64. Cheers, Javi signature.asc Description: Digital signature
Bug#630893: ax25-apps: Should be removed from main
On Mon, Mar 05, 2012 at 06:32:12PM -0500, Patrick Ouellette wrote: > On Sat, Mar 03, 2012 at 10:16:19PM +0000, Javi Merino wrote: > > > > Package: ax25-apps > > > > Hi, > > > > Jeff White was contacted in June 2011 asking him to relicence the code > > but he didn't reply. This package should be moved to non-free. > > > > How, exactly, does commenting on a bug report with absolutely NO NEW > INFORMATION do anything except increase the noise level in the BTS and > mailing lists? It's an RC bug that hasn't seen been any activity whatsoever for half a year, so I was wondering if the maintainer had just forgotten about it. It happens sometimes. > We are working on a resolution to the issue. I'm glad to hear that and I hope your package is free of RC bugs for the wheezy release. Cheers, Javi signature.asc Description: Digital signature
Bug#651655: FTBFS in sid "configure: error: unable to find the slang library and header file slang.h"
Package: slang-slirp Version: 1.9.8-1.1 I think the problem is in this part of configure (lines 6010): --- if test X"$jd_slang_library_dir" = X then lib_library_dirs="\ $jd_prefix_libdir \ /usr/local/lib \ /usr/local/lib/slang \ /usr/local/slang/lib \ /usr/lib \ /usr/lib/slang \ /usr/slang/lib \ /opt/lib \ /opt/lib/slang \ /opt/slang/lib" case "$host_os" in *darwin* ) exts="dylib so a" ;; *cygwin* ) exts="dll.a so a" ;; * ) exts="so a" esac for X in $lib_library_dirs ; do for E in $exts ; do if test -r "$X/libslang.$E" ; then jd_slang_library_dir="$X" break fi done done --- libslang2-dev installs libslang.so in /usr/lib/i386-linux-gnu/libslang.so (in an i386 machine) but configure is not looking for it in there because it's not multiarch aware. Cheers, Javi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#610984: Downgrade #610894 to important
severity 610894 important thanks Though it's an important bug, there's a workaround for the data loss it may create. Downgrading accordingly. Cheers, Javi signature.asc Description: Digital signature
Bug#587391: pure-ftpd-postgresql: spontanous crash
severity important thanks Toni Mueller wrote: > sorry for missing the messages. I thought I had replied to this > already, but it seems that (at least) the problem does not always > occur, and I was also able to set up a working pure-ftpd-postgresql > configuration on a different Lenny host, too. But I have to look again > whether I used a different version of pure-ftpd, or not. Dropping severity to important as it is "a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone." Cheers, Javi signature.asc Description: Digital signature
Bug#632604: libatomic-ops: FTBFS on i386
tags 632604 unreproducible thanks Hi, I built it in my real i386 machine just fine. Cheers, Javi signature.asc Description: Digital signature
Bug#630893: ax25-apps: Should be removed from main
Package: ax25-apps Hi, Jeff White was contacted in June 2011 asking him to relicence the code but he didn't reply. This package should be moved to non-free. -- System Information: Debian Release: 6.0.4 APT prefers stable APT policy: (800, 'stable'), (600, 'unstable'), (500, 'stable-updates') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630894: ax25spyd filed for removal
Filed for removal http://bugs.debian.org/662055 signature.asc Description: Digital signature
Bug#622353: iceweasel: application/binary files are seen as Bzip archives
tags 622353 - security severity 622353 normal thanks > Please file this upstream (reproducible with firefox 4.0), but I don't think > this has much security implication. Agreed, this isn't a security bug. Lowering the priority. Cheers, Javi signature.asc Description: Digital signature
Bug#617549: Zapping segfaults with xserver-xorg-driver-ati
reassign 617549 xserver-xorg-driver-ati
severity 617549 important
thanks
dpdt1 wrote:
> i thought it was an xorg error so i removed xserver-xorg-driver-ati and
> using only radeon driver now. (ati radeon X300 vga)
> rebooting desktop i can now start zapping app normally.
> (so maybe you can remove grave status now.)
It looks like a bug in the ati driver for your card, rather than a bug
in zapping. Zapping works on the framebuffer and it fails with
xserver-xorg-driver-ati when openning the video device:
> (C) 2000-2005 Iñaki G. Etxebarria, Michael H. Schimek.
> This program is freely redistributable under the terms
> of the GNU General Public License.
>
> Using video device '/dev/video0', display ':0.0', screen -1.
> Querying frame buffer parameters from X server.
> Xinerama base 0, 0, version 1.1
> DGA base 65, 135, version 2.0
> Screen 0:
> position 0, 0 - 1280, 1024
> frame buffer address 0xe00c
> frame buffer size 1280x1024 pixels, 0x50 bytes
> bytes per line 5120 bytes
> pixfmt BGRA32_LE
> Opening device /dev/video0.
> 3 = open ("/dev/video0", RDWR
signature.asc
Description: Digital signature
Bug#636396: mercurial: Problem seems fixed.
Hi Melanie, On 02/11/11 23:44, Melanie Davis wrote: > I installed the latest update. Both clone and commit completed without > error. Good, but I saw some problems with 2.0-1 in armel and that's why I didn't close the bug. In fact, be careful with what you have committed with that version, even if the commit finished correctly it may be corrupt. Please use "hg verify" to check that everything is correct. Can you update to 2.0-2 when that's available for armel? Cheers, Javi (Vicho) signature.asc Description: OpenPGP digital signature
Bug#636396: mercurial: Cloning fails with: mpatch.mpatchError: patch cannot be decoded
2011/9/14 Arno Huggenfeld : > > Thanks for the new version. Hg verify is working but I can confirm that your > test fails. Good! > I started the tests suite with setting 0: > > jupiter:/# cat /proc/cpu/alignment > User: 1042610 > System: 2 > Skipped: 0 > Half: 1808 > Word: 1040674 > DWord: 2 > Multi: 6 > User faults: 0 (ignored) > > @jupiter:~/mercurial-test/mercurial-1.9.2$ LANG=C make local > ... > > @jupiter:~/mercurial-test/mercurial-1.9.2$ LANG=C make tests > tests.log > ... > I will send the results when finished but it isn't looking good. > Or did you want me to run the test with # echo 2 > /proc/cpu/alignment ? I wanted both versions (if possible). If the problems only happen with alignment=0 then it's definitely an alignment problem, and we can tell people to set alignment to 2 in order to use mercurial for the time being. If it's definitely an alignment problem, we can add that to the bug upstream[0] and see what mercurial devs have to say about it. [0] http://mercurial.selenic.com/bts/issue2877 Thanks! Javi (Vicho) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#636396: mercurial: Cloning fails with: mpatch.mpatchError: patch cannot be decoded
On 14/09/11 08:12, Arno Huggenfeld wrote: > > Ok, > > third try. > > > As it seems that my first two mails vanished in the spam filter, next try > with different settings. > > I discovered by chance that mercurial is working after > > # echo 2 > /proc/cpu/alignment > (meaning fix problem, default 0 means do nothing) > > which strongly suggests that there is an alignment problem in mpatch.c . Most > of the times it is code which implicitly relies on a specific alignment of > structure members or array elements, which is not standardized and cpu, os > and compiler specific. > http://netwinder.osuosl.org/users/b/brianbr/public_html/alignment.html and > http://lecs.cs.ucla.edu/wiki/index.php have good explanations. Nice! > > I did some experiments with various versions: > > 1.8.3-1 (wheezy): only working with echo 2 > /proc/cpu/alignment > 1.8.4+174-6ab8b17adc03 (upstream hg-stable): only working with echo 2 > > /proc/cpu/alignment > 1.9.1 (upstream previous release): only working with echo 2 > > /proc/cpu/alignment > 1.9.1-2 (sid): only working with echo 2 > /proc/cpu/alignment > 1.9.2 (upstream latest release): working > 1.9.2+17-d23dfcbb8840+20110912 (upstream main): working > > All tests were limited to hg verify on a small repository. My current test case is: cd /tmp rm -rf a hg init a cd a echo a > a hg ci -Am0 hg tag t1 hg tag --remove t1 which fails in 1.9.2 . > It is not mentioned in the release notes but something was fixed between > 1.9.1 and 1.9.2. Yes, the situation has improved a lot in 1.9.2, you can clone and commit, but there are still problems (see the test case above). > Therefore I suggest Debian upgrading to 1.9.2. 1.9.2 was uploaded to debian yesterday. I'm not root in the ARM machine I'm using for debugging, so I can't test your suggestion. Can you please upgrade your package and see if it works? It would really help if you could run the whole mercurial test suite. To do that, download the sources from [0] unpack them and run "make tests". It will probably take hours to execute. [0] http://mercurial.selenic.com/release/mercurial-1.9.2.tar.gz Thanks, Javi (Vicho) signature.asc Description: OpenPGP digital signature
Bug#637688: [mercurial] unable to reproduce bug
Hi Chris, On 15/08/11 23:16, Chris Knadle wrote: > Package: mercurial > Version: 1.9.1-2 > > As I don't use Mercurial much (I mostly use Git) I decided to test the upgrade > due to this bug, and was unable to reproduce it. In my case no byte-compiled > files were removed. You are upgrading from 1.9.1-1, which already shipped all the files in /usr/lib/python2.6/dist-packages/mercurial , so no files needed to be removed from /usr/lib/python2.6/site-packages . > The relevant output (from aptitude): > > Preparing to replace mercurial 1.9.1-1 (using .../mercurial_1.9.1-2_i386.deb) > ... > Unpacking replacement mercurial ... > Preparing to replace mercurial-common 1.9.1-1 (using > .../mercurial-common_1.9.1-2_all.deb) ... > Unpacking replacement mercurial-common ... > ... > Setting up mercurial-common (1.9.1-2) ... > Setting up mercurial (1.9.1-2) ... > > > And 'hg' also seems to operate correctly as far as I can tell. > Now the qustion is what cause byte-compiled files to be removed in the > original instance the bug is based on. The byte-compiled files are removed from /usr/lib/python2.6/site-packages as part of the upgrade if you have anything left there from old installations. Then, those directories are removed because they are not needed any more, as the mercurial package follows the new convention of installing in dist-packages. > BTW in case this may help, I'm including the output of the following command: > > $ ls -ld /usr/lib/python2.6/site-packages > ls: cannot access /usr/lib/python2.6/site-packages: No such file or directory As expected. The question is what is installed there in the system of Simon (the original reporter). Thanks for testing the upgrade, Javi (Vicho) signature.asc Description: OpenPGP digital signature
Bug#586907: *NOT* fixed in mercurial 1.6.2-1
Hi slav0nic, On 28/08/10 12:48, slav0nic wrote: > got today "abort: authorization failed" with 1.6.2-2 :| Can you confirm that it is the same bug? That is, "python2.5 /usr/bin/hg pull" works, but "python2.6 /usr/bin/hg pull" returns authorization failed? I'm unable to reproduce the bug with 1.6.2-2 Thanks, Javi (Vicho) > 2010/8/28 Javi Merino > >> Hi Romain, >> >> On 26/08/10 14:06, Romain Lerallut wrote: >>> It seems that the patches in debian/patches are not applied when building >> the >>> package. Anyway, the url.py file is not patched and the problem persists. >> >> Can you please confirm that it is now fixed in 1.6.2-2? >> >> Thanks, >> Javi (Vicho) >> >> > signature.asc Description: OpenPGP digital signature
Bug#586907: *NOT* fixed in mercurial 1.6.2-1
Hi Romain, On 26/08/10 14:06, Romain Lerallut wrote: > It seems that the patches in debian/patches are not applied when building the > package. Anyway, the url.py file is not patched and the problem persists. Can you please confirm that it is now fixed in 1.6.2-2? Thanks, Javi (Vicho) signature.asc Description: OpenPGP digital signature
Bug#586907: *NOT* fixed in mercurial 1.6.2-1
On 26/08/10 16:30, Vincent Danjean wrote: > # really reopen the bug by sending the command to cont...@b.d.o > found 586907 1.6.2-1 > thanks > > On 26/08/2010 14:06, Romain Lerallut wrote: >> reopen 586907 >> thanks >> >> It seems that the patches in debian/patches are not applied when building >> the >> package. Anyway, the url.py file is not patched and the problem persists. > > Javi, do you have the time to investigate ? Yes, I'm working on it right now. Hopefully soon I will have an upload ready. I still need your sponsor for uploading. Javi (Vicho) signature.asc Description: OpenPGP digital signature
Bug#574114: Bug#463023: FTBFS in PowerPC
Okay, the patch is in the repository[0], but somehow didn't make it to the final package. If you manually download ltrace_0.5.3.orig.tar.gz [1] and apply ltrace_0.5.3-2.diff.gz [2], you'll see the patch is not applied. Can you try to rebuild the package making sure the fix is included and see if it builds in ppc? Thank you, Javi Merino (Vicho) [0] http://git.debian.org/?p=collab-maint/ltrace.git;a=commit;h=a7af00db2231e99a4506e4f5587f9dd00b9d1175 [1] http://ftp.es.debian.org/debian/pool/main/l/ltrace/ltrace_0.5.3.orig.tar.gz [2] http://ftp.de.debian.org/debian/pool/main/l/ltrace/ltrace_0.5.3-2.diff.gz -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#574114: FTBFS in PowerPC
Source: ltrace Version: 0.5.3-2 Severity: serious Tags: patch Hi, this package failed to build in powerpc on Sun 26 Jul 2009 11:50 [0]. It seems that ubuntu fixed it with the attached patch. Can you apply the patch and see if it works? [0] https://buildd.debian.org/fetch.cgi?&pkg=ltrace&ver=0.5.3-2&arch=powerpc&stamp=1248609059&file=log Regards, Javi Merino (Vicho) diff -pruN 0.5.3-2/sysdeps/linux-gnu/ppc/plt.c 0.5.3-2ubuntu3/sysdeps/linux-gnu/ppc/plt.c --- 0.5.3-2/sysdeps/linux-gnu/ppc/plt.c 2009-07-25 16:13:02.0 +0100 +++ 0.5.3-2ubuntu3/sysdeps/linux-gnu/ppc/plt.c 2010-03-07 05:38:45.0 + @@ -1,3 +1,4 @@ +#include #include #include "common.h"
