Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable

On Wed, Sep 28, 2022, at 1:47 PM, Ansgar wrote: > No, you would need to atomically replace the *entire* system, not just > individual directories. ??? Atomic replacement of each affected directory is, as far as I can see, both necessary and sufficient to prevent the system being rendered unbootab

Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable

Package: usrmerge Version: 31 Severity: critical Justification: breaks the whole system X-Debbugs-Cc: z...@owlfolio.org convert-usrmerge is nominally idempotent and restartable, but (as it says in the script’s own documentation) if “the system crashes at a really bad time” during the conversion pr

Bug#982924: what-is-python: The python-is-python3 and python-dev-is-python3 packages should not exist

Source: what-is-python Version: 3.8.6-3 Severity: critical Justification: breaks unrelated software X-Debbugs-Cc: za...@panix.com Any system where the unqualified command names ‘python’ and/or ‘python-config’, or the well-known pathname /usr/bin/python, refer to Python 3, is misconfigured. These

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

Package: git-el Version: 1:2.28.0-1 Severity: grave Justification: renders package unusable 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

Bug#941991: gnome-shell: crashes on startup (Wayland only) with "JS ERROR: TypeError: actor.get_meta_window(...) is null"

Package: gnome-shell Version: 3.34.0-2 Severity: grave Justification: renders package unusable On my computer, after upgrading to gnome-shell 3.34, I consistently get a gnome-shell catastrophic failure about 10 seconds after logging in, but only when running under Wayland. This error appears in t

Bug#843532:

I can now confirm that the problem I was having is solved. I don't use all the functionality of dnssec-trigger, though. I would have appreciated your waiting at least another 48 hours before assuming I had no further complaints. zw

Bug#843532: dnssec-trigger: broken by OpenSSL 1.1.0

Package: dnssec-trigger Version: 0.13~svn685-6 Severity: critical Justification: renders package unusable On upgrading dnssec-trigger within unstable, the postinst fails with errors from systemd: Setting up dnssec-trigger (0.13~svn685-6) ... Job for dnssec-triggerd.service failed because the cont

Bug#808789: phantomjs: FTBFS in several architectures (patch)

On Tue, Dec 22, 2015 at 6:43 PM, Mattia Rizzolo wrote: > oh, dear upstream maintainer, I just submitted a debian bug to > phantomjs, and I'd welcome a quick word from you in > https://bugs.debian.org/808789 :) As I said in #795719, Debian should not attempt to package PhantomJS at all. zw

Bug#791964: this has happened to me twice this week

severity 791964 serious quit I'm bumping the severity of this bug back to 'serious' because system upgrades have crashed my X session twice in one week. I'm pretty sure one of these two times it was the systemd update to 228-1 that caused the problem; the other time (just now), I don't know what

Bug#805703: closed by Theppitak Karoonboonyanan (Bug#805703: fixed in libthai 0.1.24-1)

Thank you for the quick fix.

Bug#787203: /lib64/ld-linux-x86-64.so.2: "/sbin/init: relocation error: symbol rewind, version GLIBC_2.2.5 not defined" w/ kernel 4.0 only

Small update: the problem is definitely not disk space in /boot, which has some 400MB free. However, I couldn't do any other testing because the machine is now showing symptoms of a severe hardware fault - freezes to the point of requiring a physical power cycle less than a minute after power-on (

Bug#787203: /lib64/ld-linux-x86-64.so.2: "/sbin/init: relocation error: symbol rewind, version GLIBC_2.2.5 not defined" w/ kernel 4.0 only

On 06/15/2015 05:58 AM, Aurelien Jarno wrote: > On 2015-05-29 12:45, Zack Weinberg wrote: >> ... crashes immediately after "Running /scripts/init-bottom ... done." with >> the error messages >> >> /sbin/init: relocation error: symbol rewind, version GLIBC

Bug#787203: addendum: newer firmware did not help

I noticed that the kernel bugscript was complaining about "working around [a] severe firmware bug", so I dug up the latest official BIOS update for this machine and installed that. No change -- still crashes on boot with 4.0 and not 3.16, still "Tainted: G I". -- To UNSUBSCRIBE, email to debian

Bug#749016: linux-image-3.14-1-amd64: initrd generated under 3.14-1 v3.14.4-1 does not load sd_mod, boot fails

Package: src:linux Version: 3.14.4-1 Severity: critical Justification: breaks the whole system initrd images generated under kernel 3.14.4-1 fail to load sd_mod automatically, which renders the system unbootable. I'm not sure precisely what is going wrong, but the phenomenon is common to both ini

Bug#746577: closed by Michael Biebl (Re: Bug#746577: systemd-sysv: for upgrade safety, systemd-sysv and sysvinit-core must be coinstallable)

On Fri, May 9, 2014 at 4:48 AM, Tollef Fog Heen wrote: > ]] Zack Weinberg >> Ah, I understand now. Yes, this + systemd-sysv and upstart *also* stop >> shipping /sbin/init (it becomes a symlink under control of the >> administrator) + documentation would be a satisfactory co

Bug#746577: closed by Michael Biebl (Re: Bug#746577: systemd-sysv: for upgrade safety, systemd-sysv and sysvinit-core must be coinstallable)

On 05/06/2014 08:08 AM, Tollef Fog Heen wrote: > ]] Zack Weinberg > >> On Mon, May 5, 2014 at 5:40 PM, Tollef Fog Heen wrote: >>> ]] Zack Weinberg >>>> Fundamentally what I want is a bulletproof procedure for reverting to >>>> sysvinit in case som

Bug#746577: closed by Michael Biebl (Re: Bug#746577: systemd-sysv: for upgrade safety, systemd-sysv and sysvinit-core must be coinstallable)

On 05/06/2014 02:39 AM, Michael Stapelberg wrote: > Hi Zack, > > Zack Weinberg writes: >> Note that coinstallability is not enough -- the bulletproof procedure >> (e.g. "update-init-system") must also be implemented, shipped, and >> documented. > Your tone

Bug#746577: closed by Michael Biebl (Re: Bug#746577: systemd-sysv: for upgrade safety, systemd-sysv and sysvinit-core must be coinstallable)

On 05/06/2014 01:37 AM, Martin Pitt wrote: > Zack Weinberg [2014-05-05 20:29 -0400]: >> I contend that, therefore, "systemd-sysv", "sysvinit-core", *and* >> "systemd-shim" (and "upstart" as well) (quotation marks indicate package >>

Bug#746577: closed by Michael Biebl (Re: Bug#746577: systemd-sysv: for upgrade safety, systemd-sysv and sysvinit-core must be coinstallable)

On 05/05/2014 03:43 PM, Michael Stapelberg wrote: > Hi Zack, > > Fundamentally we agree with you of course. The devil is in the detail, > though: sysvinit-core and systemd are coinstallable, for all the reasons > you explained. > > However, you seem to be using a package which depends on libpam-s

Bug#746577: closed by Michael Biebl (Re: Bug#746577: systemd-sysv: for upgrade safety, systemd-sysv and sysvinit-core must be coinstallable)

On Mon, May 5, 2014 at 5:40 PM, Tollef Fog Heen wrote: > ]] Zack Weinberg >> Fundamentally what I want is a bulletproof procedure for reverting to >> sysvinit in case something goes wrong. > > Sounds like you're arguing that sysvinit-core should no longer ship > /sbi

Bug#746577: closed by Michael Biebl (Re: Bug#746577: systemd-sysv: for upgrade safety, systemd-sysv and sysvinit-core must be coinstallable)

On 2014-05-03 12:18 PM, Tollef Fog Heen wrote: Zack Weinberg wrote: 1) Switching from sysvinit to systemd (and vice versa, if necessary) should be accomplished via a command dedicated to the purpose; it should *not* occur as a side effect of installing, removing, upgrading, or downgrading any

Bug#746577: closed by Michael Biebl (Re: Bug#746577: systemd-sysv: for upgrade safety, systemd-sysv and sysvinit-core must be coinstallable)

On Fri, May 2, 2014 at 12:48 PM, Michael Biebl wrote: > This is already possible today: The systemd package (intentionally) > doesn't conflict with sysvinit-core since there are no file conflicts. > > You can install it and boot with init=/lib/systemd/systemd. > The systemd-sysv package is intenti

Bug#746577: closed by Michael Biebl (Re: Bug#746577: systemd-sysv: for upgrade safety, systemd-sysv and sysvinit-core must be coinstallable)

I don't wish to play bug tracker ping-pong here, but I feel that you are still missing the point. This is not about the default for new installations, this is not about opt-out versus opt-in to the switch. This is about *upgrade safety*. Upgrade safety, IMNSHO, requires a stabilization point in

Bug#746577: closed by Michael Biebl (Re: Bug#746577: systemd-sysv: for upgrade safety, systemd-sysv and sysvinit-core must be coinstallable)

Control: reopen -1 > You didn't show any actual breakage, so closing the bug report. > If you can show us of actual breakage caused by the switch to > systemd where the system will not boot, we will certainly deal > with it. I believe you have missed the point of the bug report. This is not abou

Bug#746577: systemd-sysv: for upgrade safety, systemd-sysv and sysvinit-core must be coinstallable

Source: systemd-sysv Version: 204-10 Severity: critical Justification: breaks the whole system Control: retitle -2 sysvinit-core: for upgrade safety, systemd-sysv and sysvinit-core must be coinstallable For safety of upgrades from wheezy to jessie, the process of upgrading packages and installing

Bug#717154: have a patch

Control: tags 717154 + patch It looks like there were serious changes to the VFS layer in 3.10. The attached patch restores buildability and I'm reasonably confident it is correct. It does NOT preserve buildability vs. any older kernel. zw 0004-vmblock-vmhgfs-compat-3_10.patch Description: Bin

Bug#712861: patch doesn't work

On Thu, Jun 20, 2013 at 12:30 PM, Emilio Pozuelo Monfort wrote: > > The patch here is not what was uploaded to the archive. What was uploaded > actually works as opposed to my patch in this bug. I hope you will understand my impatience in the face of a nonfunctional desktop environment. :) 3.4.2

Bug#712861: patch doesn't work

reopen 712861 thanks gnome-shell 3.4.2-9 hasn't shown up in the archive yet AFAICT, so I manually applied Emilio's proposed patch to bluetooth.js. This did not help; I get exactly the same startup crash except that the error message now says "GnomeBluetoothApplet.BluetoothKillswitchState is undef

Bug#711537: gnome-robots: purge package fails due to typo in post-removal script

Package: gnome-robots Version: 1:3.8.1-1 Severity: serious Justification: Policy 6.1 gnome-robots fails to purge for exactly the same reason as gnome-nibbles (see bug #710515). Even the typo is identical: "for FILES in ..." needs to be changed to "for FILE in ...". -- System Information: Debian

Bug#656564: I *was* seeing this too...

I was seeing this problem about once every two hours on my computer, so I restarted my session and immediately attached gdb to the gnome-settings-daemon process (and continued it). It has not crashed since. The computer's been up for about 16 hours (not counting time in suspend) now. zw -- T

Bug#559893: [Monotone-debian] Bug#559893: monotone-server: hooks.lua.base is outdated

On Tue, Mar 16, 2010 at 11:47 AM, Ludovic Brenta wrote: > As of monotone 0.47 I do not see any file named hooks.lua.base either in > the upstream sources or in the Debian packaging scripts. > > Is this an upstream bug? > Is it fixed in 0.47-1? If not, 0.47-1 which I am about to upload will > not m

Bug#559893: [Monotone-debian] Bug#559893: monotone-server: hooks.lua.base is outdated

On Tue, Mar 16, 2010 at 12:47 PM, Zack Weinberg wrote: > > It does not look like 0.47-1 addressed any of the several other > outstanding Debian bugs :-( I take that back - there are only two others and both of them *may* have been addressed by the upstream changes. zw -- To UN

Bug#571248: Bug#571138: iceweasel: random crashes at page/tab close of Iceweasel and iceape

On Wed, Feb 24, 2010 at 12:22 PM, Mike Hommey wrote: > > Can you all try to downgrade libcairo2 to the version in testing ? > http://packages.debian.org/source/testing/cairo Did that and have not yet been able to crash the browser; will advise if it comes back. -- To UNSUBSCRIBE, email to deb

Bug#559893: [Monotone-debian] Bug#559893: monotone-server: hooks.lua.base is outdated

tags 559893 + help thanks I am not going to get to this bug until January. NMUs welcome. zw -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#557983: [Monotone-debian] Bug#557983: FTBFS [hppa]

On Wed, Nov 25, 2009 at 10:46 AM, dann frazier wrote: > > monotone has been reliably failing to build on hppa. > > Here are logs of the all the build attemps so far: >  https://buildd.debian.org/build.php?&pkg=monotone&ver=0.45-2&arch=hppa&file=log I think this is libstdc++ bug #554574, which has

Bug#554574: libstdc++: small test program

Package: libstdc++6 Severity: normal It sounds like this bug is the cause of a FTBFS in one of my packages. In case it's helpful, here is a small self-contained test program that currently crashes when run on the hppa buildd: #include #include int main(void) { std::ofstream ofs("_conftest.da

Bug#542287: Spoke too soon about new official monotone package - please go ahead with NMU

Due to a hardware failure on monotone upstream's VCS servers, I am not going to be able to upload the new release for a while. Please go ahead with an NMU for bug 542287 and any other bugs you feel like picking off. I apologize for claiming to have a new package nearly done. zw -- To UNSUBSC

Bug#540013: botan1.8 - FTBFS: Guessing target processor is a s390x/s390x

I'd like to provide a patch for this bug, but I'm not sure the obvious approach of changing the existing check of DEB_BUILD_ARCH in debian/rules to ifeq ($(DEB_BUILD_ARCH),i386) CONFIGURE_FLAGS = --cpu=i486 else CONFIGURE_FLAGS = --cpu=$(DEB_BUILD_ARCH) endif is going to work for

Bug#537801: libqtgui4: mangled color maps

On Tue, Jul 21, 2009 at 12:45 PM, Modestas Vainius wrote: >> Unfortunately I can't try this version of virtualbox against the older Qt. > > You can. I'm 90% sure it will work if you force install it (either qt libs or > virtual box as needed) with # dpkg --force-depends -i. Once you are done > test

Bug#537801: libqtgui4: mangled color maps

On Tue, Jul 21, 2009 at 10:51 AM, Modestas Vainius wrote: >> kcachegrind does not show the problem with 4.5.1 Qt libraries.  I >> would have liked to try the other Qt-based application I use >> frequently, virtualbox-ose-qt, but it has been recompiled against >> 4.5.2 so apt-get insisted on deletin

Bug#537801: libqtgui4: mangled color maps

On Tue, Jul 21, 2009 at 11:17 AM, Fathi Boudra wrote: > tags 537801 + unreproducible > > I tried kcachegrind 4.2.4 with Qt 4.5.2 and I can't reproduce the bug using > intel or nvidia driver. As you can see from the X server log attached to this bug, my graphics card is ATI. > which desktop enviro

Bug#537801: libqtgui4: mangled color maps

On Tue, Jul 21, 2009 at 10:18 AM, Zack Weinberg wrote: > On Tue, Jul 21, 2009 at 10:09 AM, Modestas Vainius wrote: >> On antradienis 21 Liepa 2009 03:58:56 Zack Weinberg wrote: >>> Package: libqtgui4 >>> Version: 4:4.5.2-1 >>> Severity: grave >>

Bug#537801: libqtgui4: mangled color maps

On Tue, Jul 21, 2009 at 10:09 AM, Modestas Vainius wrote: > On antradienis 21 Liepa 2009 03:58:56 Zack Weinberg wrote: >> Package: libqtgui4 >> Version: 4:4.5.2-1 >> Severity: grave >> Justification: renders package unusable >> >> Starting abruptly today, Q

Bug#527314: Bug#527461: monotone: Monotone needs recompile against libbotan 1.8.2

Great. I'll watch for it and get a fixed monotone uploaded as soon as it clears NEW. zw

Bug#527461: monotone: Monotone needs recompile against libbotan 1.8.2

On Sun, Jul 12, 2009 at 11:37 PM, Marc Lütolf wrote: > Greetings, > > Any ETA for resolution of this bug? > Thanks for any feedback. I can do nothing until the botan packages are fixed (bug 527461). Daniel refused my offer of help and said that fixed packages would be uploaded "in about a week".

Bug#527314: Bug#527461: considering preparing NMU of botan-devel for bug 527461

On Tue, May 12, 2009 at 11:21 PM, Daniel Baumann wrote: > Zack Weinberg wrote: >> 1) Would an NMU of botan-devel to be welcome? > > no; it will get fixed today by me anyway (i did other changes to the > package as well since it has to go through NEW anyway). That was over a wee

Bug#527461: considering preparing NMU of botan-devel for bug 527461

It's been a week or so and there's been no fix for botan-devel bug 527461 (SONAME bumped without binary package name change). Meanwhile there *has* been a new upstream release of my package, monotone, which depends on botan. 1) Would an NMU of botan-devel to be welcome? The fix seems pretty strai

Bug#527314: please binNMU monotone for botan transition

On Thu, May 7, 2009 at 10:42 AM, Adeodato Simó wrote: > > monotone and keysafe certainly need to be rebuilt against the new > version of botan, since the SONAME has changed. However, the libbotan1.8 > binary package name should have been renamed in the process of bumping > the SONAME (Bug#527461),

Bug#522995: fixed in 0.43-2

Package: monotone Version: 0.43-2 The 0.43-2 package has built successfully on mips and powerpc (which was also showing the same symptoms) so I am closing this bug report. [I did not close it in the change log because I could not be sure I had fixed the bug.] See: https://buildd.debian.org/fetch.

Bug#522995: [Monotone-debian] Bug#522995: monotone_0.43-1(mips/unstable): FTBFS on mips. compiler problem ?

On Tue, Apr 7, 2009 at 1:50 PM, Zack Weinberg wrote: > > An 0.43-2 package addressing this failure will be uploaded as soon as > my sponsor gets around to it. Clarification: the package has already been prepared, and will be uploaded as soon as my sponsor gets around to it. zw

Bug#522995: [Monotone-debian] Bug#522995: monotone_0.43-1(mips/unstable): FTBFS on mips. compiler problem ?

On Tue, Apr 7, 2009 at 12:08 PM, Peter De Schrijver wrote: > > There was an error while trying to autobuild your package: >> >> make: *** [build-arch-stamp] Error 1 >> dpkg-buildpackage: failure: debian/rules build gave error exit status 2 An 0.43-2 package addressing this failure will be uploade

Bug#520478: suggested alternative patch

Rather than squashing the bad .la deps in debian/rules at install time I think it's better to squash them right after the .la files themselves are created - that, plus some adjustment in the use of $(TLIBS), makes dpkg-shlibdeps much happier about unnecessary direct dependencies of libtclsqlite3.so

Bug#520153: patch

tags 520153 + upstream patch forwarded 520153 http://www.sqlite.org/cvstrac/tktview?tn=3747 thanks This is another upstream build harness bug -- "make install" needs to do libsqlite3.la before libtclsqlite3.la or libtool gets all upset. zw --- sqlite3-3.6.11.orig/Makefile.in 2009-03-24 10:52:35.0

Bug#520557: closed by Zack Weinberg (already fixed upstream since 3.6.7)

Marc Singer wrote: > Zack Weinberg wrote: > > This bug has already been fixed by upstream, in version 3.6.7, which > > appears never to have been uploaded to Debian. The 3.6.10-1 and later > > packages (now available in unstable) should not have the problem. > > That

Bug#520466: Have a patch!

I need a usable sqlite3 package in order to prepare the next upload of the monotone package, so I've developed a fix for this bug. I've also reported it to SQLite upstream - . My patch, which you can just drop into debian/patches/, is attached. zw -

Bug#514076: libasio-dev: missing hard dependency on libboost-date-time-dev

Package: libasio-dev Version: 1.3.1-1 Severity: grave Justification: renders package unusable libasio-dev does not declare any dependency on libboost-date-time-dev; however, any non-contrived use of the library will include headers that transitively include headers from that package. For example:

Bug#512347: libbotanX.Y-dev packages should all conflict

Package: libbotan1.8-dev Version: 1.8.0-1 Severity: serious Justification: Policy 8.4 libbotan1.8-dev, libbotan1.7-dev, and libbotan1.6-dev all provide the file /usr/lib/libbotan.a. They need to Conflict so that apt will refuse to install them at the same time. As is you get "trying to overwrite

Bug#490417: [Monotone-debian] Bug#490417: monotone: FTBFS: tests failed

On Sat, Jul 12, 2008 at 1:23 AM, Lucas Nussbaum <[EMAIL PROTECTED]> wrote: > During a rebuild of all packages in sid, your package failed to build on > i386. [...] I cannot reproduce this; I'm looking into there being a race condition in the test, but meanwhile: Is there any chance you could try

Bug#483018: closed by changelog typo

reopen 483018 thanks -- once again I have transposed two digits in a bug number. Apologies. zw -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#481911: elisa: incompatible with twisted 8

On Tue, May 20, 2008 at 4:06 AM, Philippe Normand <[EMAIL PROTECTED]> wrote: > Hi Zack, > > For now you can replace gstreamer:gst_metadata_client with > gstreamer:gst_metadata in elisa.conf. > > I will work on a fix for that issue very soon, I hope... > > Sorry, I didn't mean to be rude on the foru

Bug#481911: elisa: incompatible with twisted 8

Package: elisa Version: 0.3.5-3 Severity: grave Justification: renders package unusable When I start up Elisa, I get a mangled display and a bunch of Python stacktraces (quoted below). I reported these to the upstream support forums at http://elisa.fluendo.com/forums/viewtopic.php?pid=1831 and wa

Bug#474407: [Monotone-debian] Bug#474407: monotone - FTBFS: 1 of 3 tests malfunctioned

Also, fyi, i'm going to downgrade this to important. It appears to be s390-specific and I have no indication that there is anyone actually *using* monotone on the s390. My time to work on the package is limited and I have to depend on requests like the one I just made of you, to debug it on most

Bug#474407: [Monotone-debian] Bug#474407: monotone - FTBFS: 1 of 3 tests malfunctioned

On Sat, Apr 5, 2008 at 10:16 AM, Bastian Blank <[EMAIL PROTECTED]> wrote: > >> Automatic build of monotone_0.39-1 on debian-31.osdl.marist.edu by >> sbuild/s390 98 > [...] >> 401 single_character_filename_support ok >> 402 single_manifest_netsync ok >> 403 spawn_p

Bug#479607: lilo fails to boot 2.6.25 kernel image due to wrongly passing initramfs

I was having exactly the same problem and found that adding "large-memory" to lilo.conf made it work. zw -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#439584: [Monotone-debian] Bug#439584: monotone - FTBFS: 1 of 3 tests failed

On 10/26/07, Bastian Blank <[EMAIL PROTECTED]> wrote: > On Sun, Aug 26, 2007 at 10:59:49AM -0700, Zack Weinberg wrote: > > I need more information to debug this. Is there any chance you can > > tar up the contents of the "tester_dir" subdirectory of the build tree

Bug#439584: [Monotone-debian] Bug#439584: monotone - FTBFS: 1 of 3 tests failed

On 10/26/07, Bastian Blank <[EMAIL PROTECTED]> wrote: > | runcmd: /build/waldi/temp/monotone-0.36/mtn, local_redir = false, requested > = nil > | add_executable:5: /build/waldi/temp/monotone-0.36/mtn --norc > --root=/build/waldi/temp/monotone-0.36/tester_dir/add_executable > --confdir=/build/wal

Bug#441763: actually, no.

clone 441763 -1 severity -1 wishlist reassign -1 libc6 thanks > What the fuck? Do you have in mind that you rely on a feature that does > not exists, and you are shouting because it does not exists? I was not shouting, and even if I were, this level of abuse is inappropriate. > libc.so.6's has N

Bug#441870: not a libdb bug

reassign 441870 libc6 merge 441870 441763 thanks libdb should NOT be linked against libpthread, as it does not create and used threads internally. The bug is that libc's thread-locking stubs are missing a few interfaces. Please see my explanation in #441763. zw -- To UNSUBSCRIBE, email to [

Bug#441763: actually, no.

reassign 441763 libc6 retitle 441763 /lib/libc.so.6 is missing several stub pthread interfaces thanks Brian Carlson is seriously mistaken in all of his statements about this bug. It is possible to write correct C++ code that does not need any of the libraries that "g++" adds to the link, and in t

Bug#439584: [Monotone-debian] Bug#439584: monotone - FTBFS: 1 of 3 tests failed

tags 439584 + moreinfo thanks On 8/25/07, Bastian Blank <[EMAIL PROTECTED]> wrote: > There was an error while trying to autobuild your package: > [...] > > Of 446 tests run: > > 0 succeeded > > 444 failed > > 2 had expected failures > > 0 succeeded unexpectedly > > 0

Bug#434604: monotone depends on non-essential package ucf in postrm

On 8/2/07, Ludovic Brenta <[EMAIL PROTECTED]> wrote: > Zack, debconf is priority: required, just like libc6. You can pretty > much rely on it being present. That turned out not to be the problem. :-> piuparts is not so silly. The debhelper additions were trying to talk to debconf after db_stop.

Bug#434604: advice please

I've been attempting to fix this bug. Unfortunately, the purge mode of the postrm doesn't just use ucf (which is easy to deal with); it also has unconditional uses of userdel and debconf. I think that the appropriate thing for the userdel operation is to check for the existence of the binary and

Bug#432658: plan

On 7/22/07, Ludovic Brenta <[EMAIL PROTECTED]> wrote: Not so imminent. [...] Imminent was perhaps the wrong word, but nonetheless, I don't see much value in trying to isolate a bug in g++-4.1 when 4.2 should be live in the near future, especially when, as you say Monotone 0.35-2 is now 8 day

Bug#432658: plan

For the record - since I'm pretty sure this is a compiler bug and the g++ 4.2 transition is imminent, I'm going to wait and see if the package builds with 4.2, and if it does, I'll downgrade this to normal and reassign it to g++-4.1. zw -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subje

Bug#432658: [Monotone-debian] Bug#432658: #432658: monotone: FTBFS: internal compiler error on arm in database_check.cc

On 7/15/07, Ludovic Brenta <[EMAIL PROTECTED]> wrote: I crudely measured, using top(1) and a sampling period of 0.5 s, that g++ uses as much as 474 Mb of virtual memory when compiling the largest file in monotone (revision.cc). That might explain why g++ seems to have run out of memory on two di

Bug#432659: monotone: FTBFS on alpha, configure fails mysteriously

On 7/11/07, Steve Langasek <[EMAIL PROTECTED]> wrote: The most recent upload of glibc to unstable has introduced a libc-dev dependency which is in conflict with the sbuild configuration on multiple buildds. As a result, libstdc++-dev has gone missing from these chroots, and the buildd admin will

Bug#432659: monotone: FTBFS on alpha, configure fails mysteriously

If you look carefully at the buildd log for this one, you see it went off the rails a long time before that... checking whether we are using the GNU C++ compiler... no checking whether g++ accepts -g... no checking dependency style of g++... none checking for C++ compiler warning flags... unknown

Bug#432657: ... buildd bug???

texi2dvi is provided by the texinfo package, which is in the Build-Depends-Indep list. This might not be correct, but if it's wrong, it's because of the use of makeinfo in building the main monotone package; not because of the use of texi2dvi in building the monotone-doc package. The buildd invo

Bug#404616: [Monotone-devel] Re: Bug#404616: monotone: Segmentation fault

On 1/4/07, Shaun Jackman <[EMAIL PROTECTED]> wrote: On 1/4/07, Zack Weinberg <[EMAIL PROTECTED]> wrote: > Thanks for the symbol-ful backtrace. I regret to say I don't know > what is going on there, but I have this bad feeling it's a Boost bug. I get the sa

Bug#404616: [Monotone-devel] Re: Bug#404616: monotone: Segmentation fault

Thanks for the symbol-ful backtrace. I regret to say I don't know what is going on there, but I have this bad feeling it's a Boost bug. zw -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#404616: [Monotone-devel] Re: Bug#404616: monotone: Segmentation fault

On 12/31/06, Brian May <[EMAIL PROTECTED]> wrote: Zack> 2) Run the crashing command under valgrind - valgrind does support PPC Zack> now, I believe - and get us a backtrace from that. ==6046== Memcheck, a memory error detector. ==6046== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Sew

Bug#404616: [Monotone-devel] Re: Bug#404616: monotone: Segmentation fault

(gdb) bt #0 0x0fe35ecc in __dynamic_cast () from /usr/lib/libstdc++.so.6 #1 0x100c1ef0 in std::out_of_range::~out_of_range () #2 0x10209214 in boost::detail::shared_count::~shared_count () #3 0x1012a674 in boost::gregorian::bad_month::~bad_month () #4 0x1012b060 in boost::gregorian::bad_month

Bug#339085: coreutils: You can't make this change. Not now, and quite probably never.

I could say that I think you're seriously underestimating the problem here, but you probably think I'm seriously overestimating it, and we're not going to get anywhere playing is-not, is-so games. Instead, I'll ask again: What do you see as the advantage of removing support for these older comman

Bug#339085: coreutils: You can't make this change. Not now, and quite probably never.

On 6/3/06, Michael Stone <[EMAIL PROTECTED]> wrote: On Sat, Jun 03, 2006 at 12:56:30PM -0700, Zack Weinberg wrote: >[And, for the record, official end-of-life dates have approximately >zero effect on whether or not GCC drops support for a system, and are >therefore not useful ev

Bug#339085: coreutils: You can't make this change. Not now, and quite probably never.

On 6/3/06, Michael Stone <[EMAIL PROTECTED]> wrote: On Fri, Jun 02, 2006 at 08:35:07PM -0700, you wrote: >detail, as of POSIX-1992. I know for a fact that this is the case for >releases of Solaris up to and including (2.)8, and I strongly suspect That's simply not true. Solaris has obsolete syn

Bug#339085: coreutils: You can't make this change. Not now, and quite probably never.

On 6/3/06, Bob Proulx <[EMAIL PROTECTED]> wrote: Just a detail clarification... HP-UX 10.20, arguably the oldest HP-UX version still in active use anywhere, supports the 'tail -n#' syntax. Are you absolutely certain that the version of tail in /bin or /usr/bin supports that syntax? I have thi

Bug#339085: coreutils: You can't make this change. Not now, and quite probably never.

Package: coreutils Version: 5.96-3 Followup-For: Bug #339085 I want to add emphasis and additional justification to Josh Triplett's request that the old (POSIX-1992) command line syntax continue to work. On this issue, I speak primarily as a (semi-retired) GCC maintainer. Every other month or so

Bug#348378: smart-notifier: does not start (DBus policy error)

> > I'm not sure what's wrong here, but if I had to guess, I would be guessing > > that it oughta be asking for the session bus, not the system bus...? Only > > maybe then it doesn't work? > > Yeah, it is meant to be on the system bus, because it needs to > communicate from a process running as r

Bug#348378: smart-notifier: does not start (DBus policy error)

Package: smart-notifier Version: 0.23-1 Severity: grave Justification: renders package unusable Per instructions, I set up smartd, started my usual X session, and then ran smart-notifier from within the session. It immediately quit with errors: $ smart-notifier Traceback (most recent call last)