Bug#647772: gnome: Josselin Moutte shrugs off bug reports
Package: gnome Version: 1:3.0+3 Severity: critical Justification: breaks the whole system I just reported bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=647768 which is a serious issue with the debian system. This happened after a reboot of a single system and I am afraid to reboot the rest of the fleet as a result in fear that our knowledge and culture may be lost forever. Instead of addressing this concern and providing and/or fixing a clean upgrade path, Josselin has closed the previous bug with a shrug. A shrug. This seems to indicate that not only GNOME, but the entire debian system is broken, and that more breakage is on the way. What can we do to avoid such cascade failure across the whole planet? Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these lines *** -- System Information: Debian Release: wheezy/sid APT prefers oldstable APT policy: (500, 'oldstable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gnome depends on: ii abiword 2.9.1-0.1 ii alacarte 0.13.2-3 ii avahi-daemon 0.6.30-5 ii cheese 3.2.0-1 ii desktop-base 6.0.7 ii ekiga3.2.7-4.1 ii epiphany-extensions 3.0.0-3 ii evolution3.0.3-2 ii evolution-plugins3.0.3-2 ii file-roller 3.0.2-2 ii gedit3.0.6-2 ii gedit-plugins3.0.6-1 ii gimp 2.6.11-5 ii gnome-applets3.2.1-1 ii gnome-core 1:3.0+3 ii gnome-games 1:3.0.2-2 ii gnome-media 2.91.2-3 ii gnome-nettool3.0.0-2 ii gnumeric 1.10.17-1+b1 ii gstreamer0.10-ffmpeg 1:0.10.12-0.0 ii gstreamer0.10-plugins-ugly 0.10.18-3+b1 ii gvfs-bin 1.8.2-2 ii hamster-applet 2.91.3+git20110714.9aefd7-2 ii inkscape 0.48.1-2.1+b1 ii libgtk2-perl 2:1.223-1+b1 ii libreoffice-gnome1:3.4.3-4 ii nautilus-sendto 3.0.1-2 ii rhythmbox2.90.1~git20110919.2dfea6-3 ii rhythmbox-plugin-cdrecorder 2.90.1~git20110919.2dfea6-3 ii rhythmbox-plugins2.90.1~git20110919.2dfea6-3 ii seahorse 3.0.2-1 ii shotwell 0.11.5-1 ii simple-scan 3.2.0-1 ii sound-juicer 2.32.1+git20111010.2d5deeb-1 ii telepathy-gabble 0.13.7-1 ii telepathy-salut 0.6.0-1 ii tomboy 1.8.0-1 ii totem-mozilla3.0.1-3 ii totem-plugins3.0.1-3 ii transmission-gtk 2.03-2.2 ii update-notifier 0.99.3debian10 ii vinagre 3.2.1-1 ii xdg-user-dirs-gtk0.8-1 Versions of packages gnome recommends: ii browser-plugin-gnash 0.8.10~git20111001-1 ii gdebi0.8.2 ii gnome-games-extra-data 3.0.0-1 ii liferea 1.6.5-1.2+b1 ii menu-xdg 0.5 ii nautilus-sendto-empathy 3.2.1.1-1 ii telepathy-butterfly 0.5.15-2.1 ii telepathy-idle 0.1.11-2 Versions of packages gnome suggests: pn dia-gnome 0.97.1-9+b1 pn gnome-tweak-tool none pn gnucashnone pn libreoffice-evolution none pn libreoffice-gnome 1:3.4.3-4 pn plannernone Versions of packages gnome-core depends on: ii baobab 3.0.1-5 ii brasero 3.0.0-4 ii
Bug#635604: dnet-common borked my network
Dominique Dumont, I don't think it is sufficient that the dependancy be resolved. I just upgraded two hosts on my network, as a result dnet-common got installed on both. I was aked configure, don't configure, or leave it alone. I chose leave it alone, and guess what -- both hosts on my network were given the same mac address. There was absolutely no indication of this. Not only did my hosts lose their assigned IP's, the entire network broke because this package got installed. Changing mac addresses is kind of a big deal. You can't just do it when somebody picks a default configuration option of not right now. The dnet-common package needs to be fixed to never, EVER change somebody's MAC address unless they explicitly consent to this action.
Bug#635604: also,
one of my NICs remembers it's mac addresses between reboots... so i'm having to look up the old one in my routers' leases to put things right. it took hours to debug this because hacing multiple systems with the same MAC on the same network is *never* supposed to happen. wrecked my day. :-(
Bug#519341: nagios3-common: missing then in nagios3-common.prerm
Package: nagios3-common Severity: serious Justification: Policy 6.8 The latest nagios3-common package can not be removed because the first if block in nagios3-common.prerm is missing it's then keyword, causing a syntax error. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#492434: pidgin: Connects to Jabber server with bad SSL certificates, without warning
tags 492434 patch thanks Miron Cuperman [EMAIL PROTECTED] wrote: I believe this bug was introduced with the fix for bug #401567. At that time, the SSL implementation was changed from GNUTLS to NSS. Unfortunately, the NSS plugin in pidgin does no certificate checking at all, meaning that any certificate is accepted (including malformed or self-signed ones). I recommend switching back to gnutls. Patch attached. The attached patch also corrects a problem in reading the certificate store from /etc/ssl/certs . (note that this patch is cumulative to 00_debian-ca-certs.patch .) Unfortunately, it is now the case that any passwords transmitted over an NSS created link could have been compromised by man-in-the-middle attacks, since many people use the PLAIN auth mechanism. Any valuable passwords compromised in this way should be changed. -- Miron diff -ur pidgin-2.4.1/debian/rules pidgin-2.4.1-gnutls/debian/rules --- pidgin-2.4.1/debian/rules 2008-08-02 19:04:58.0 -0700 +++ pidgin-2.4.1-gnutls/debian/rules 2008-08-02 18:43:49.0 -0700 @@ -20,7 +20,7 @@ LDFLAGS = -Wl,--as-needed CFLAGS = -fstack-protector -DEB_CONFIGURE_EXTRA_FLAGS := --enable-perl --with-zephyr=/usr --enable-dbus --enable-gnutls=no --enable-nss=yes --enable-cyrus-sasl --enable-nm --disable-silc +DEB_CONFIGURE_EXTRA_FLAGS := --enable-perl --with-zephyr=/usr --enable-dbus --enable-gnutls=yes --enable-nss=no --enable-cyrus-sasl --enable-nm --disable-silc DEB_DH_MAKESHLIBS_ARGS_pidgin := -V -X/usr/lib/pidgin DEB_DH_SHLIBDEPS_ARGS_pidgin := -X/usr/lib/pidgin/gevolution.so -X/usr/lib/pidgin/cap.so -- -dSuggests debian/pidgin/usr/lib/pidgin/cap.so -dDepends diff -ur pidgin-2.4.1/libpurple/certificate.c pidgin-2.4.1-gnutls/libpurple/certificate.c --- pidgin-2.4.1/libpurple/certificate.c 2008-08-02 19:07:10.0 -0700 +++ pidgin-2.4.1-gnutls/libpurple/certificate.c 2008-08-02 18:56:25.0 -0700 @@ -745,7 +745,7 @@ x509_ca_paths = g_list_append(NULL, g_build_filename(DATADIR, ca-certs, NULL)); #else - x509_ca_paths = g_list_append(NULL, g_build_filename(etc, + x509_ca_paths = g_list_append(NULL, g_build_filename(/etc, ssl, certs, NULL)); #endif } -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465608: education-* installer is still screwing up!
reopen 465608 thanks Here is what I'm getting attempting to install 0.825. debian also refuses to remove 0.824. I sent a message to debian-user about this earlier today (attached) but have not gotten a reply yet. domus:/var/cache/apt/archives# dpkg -i education-chemistry_0.825_i386.deb (Reading database ... 580683 files and directories currently installed.) Preparing to replace education-chemistry 0.824+svn40294 (using education-chemistry_0.825_i386.deb) ... Unpacking replacement education-chemistry ... err 67: Custom distribution education does not exist dpkg: warning - old post-removal script returned error exit status 67 dpkg - trying script from the new package instead ... err 67: Custom distribution education does not exist dpkg: error processing education-chemistry_0.825_i386.deb (--install): subprocess new post-removal script returned error exit status 67 err 67: Custom distribution education does not exist dpkg: error while cleaning up: subprocess post-removal script returned error exit status 67 Errors were encountered while processing: education-chemistry_0.825_i386.deb ---BeginMessage--- Hi, I'm running sid. I've had the education packages installed for awhile... last week, an update came out for them which has completely broken the package manager, making it impossible to upgrade further. I get a message like this for every education-* package: Preparing to replace education-chemistry 0.824+svn40294 (using .../education-chemistry_0.825_i386.deb) ... Unpacking replacement education-chemistry ... err 67: Custom distribution education does not exist dpkg: warning - old post-removal script returned error exit status 67 dpkg - trying script from the new package instead ... err 67: Custom distribution education does not exist dpkg: error processing /var/cache/apt/archives/education-chemistry_0.825_i386.deb (--unpack): subprocess new post-removal script returned error exit status 67 err 67: Custom distribution education does not exist dpkg: error while cleaning up: subprocess post-removal script returned error exit status 67 ... apt-get remove refuses to delete the packages: Reading changelogs... Done dpkg: error processing education-chemistry (--remove): Package is in a very bad inconsistent state - you should reinstall it before attempting a removal. Errors were encountered while processing: education-chemistry E: Sub-process /usr/bin/dpkg returned an error code (1) ... and trying to force dpkg's hand doesnt work either! domus:~# dpkg --force-remove-reinstreq --purge education-chemistry dpkg - warning, overriding problem because --force enabled: Package is in a very bad inconsistent state - you should reinstall it before attempting a removal. (Reading database ... 580601 files and directories currently installed.) Removing education-chemistry ... err 67: Custom distribution education does not exist dpkg: error processing education-chemistry (--purge): subprocess post-removal script returned error exit status 67 Errors were encountered while processing: education-chemistry Is there any safe, sane way I can either remove these 50-some-odd packages or get them to install correctly? Thanks, Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] ---End Message---
Bug#465608: education has made my debian mentally challenged
No such luck :-( domus:/var/cache/apt/archives# dpkg --force-all -i education-astronomy_0.825_i386.deb (Reading database ... 580683 files and directories currently installed.) Preparing to replace education-astronomy 0.824+svn40294 (using education-astronomy_0.825_i386.deb) ... Unpacking replacement education-astronomy ... err 67: Custom distribution education does not exist dpkg: warning - old post-removal script returned error exit status 67 dpkg - trying script from the new package instead ... err 67: Custom distribution education does not exist dpkg: error processing education-astronomy_0.825_i386.deb (--install): subprocess new post-removal script returned error exit status 67 err 67: Custom distribution education does not exist dpkg: error while cleaning up: subprocess post-removal script returned error exit status 67 Errors were encountered while processing: education-astronomy_0.825_i386.deb Jay Zach [EMAIL PROTECTED] wrote: Tyler MacDonald wrote: Hi, I'm running sid. I've had the education packages installed for awhile... last week, an update came out for them which has completely broken the package manager, making it impossible to upgrade further. I get a message like this for every education-* package: Preparing to replace education-chemistry 0.824+svn40294 (using .../education-chemistry_0.825_i386.deb) ... Unpacking replacement education-chemistry ... err 67: Custom distribution education does not exist dpkg: warning - old post-removal script returned error exit status 67 dpkg - trying script from the new package instead ... err 67: Custom distribution education does not exist dpkg: error processing /var/cache/apt/archives/education-chemistry_0.825_i386.deb (--unpack): subprocess new post-removal script returned error exit status 67 err 67: Custom distribution education does not exist dpkg: error while cleaning up: subprocess post-removal script returned error exit status 67 ... apt-get remove refuses to delete the packages: Reading changelogs... Done dpkg: error processing education-chemistry (--remove): Package is in a very bad inconsistent state - you should reinstall it before attempting a removal. Errors were encountered while processing: education-chemistry E: Sub-process /usr/bin/dpkg returned an error code (1) ... and trying to force dpkg's hand doesnt work either! domus:~# dpkg --force-remove-reinstreq --purge education-chemistry dpkg - warning, overriding problem because --force enabled: Package is in a very bad inconsistent state - you should reinstall it before attempting a removal. (Reading database ... 580601 files and directories currently installed.) Removing education-chemistry ... err 67: Custom distribution education does not exist dpkg: error processing education-chemistry (--purge): subprocess post-removal script returned error exit status 67 Errors were encountered while processing: education-chemistry Is there any safe, sane way I can either remove these 50-some-odd packages or get them to install correctly? Thanks, Tyler I struggled with the same stuff with education-astronomy on my sidux system... There are bug reports for this and the .825 packages are supposed to fix it. I eventually believe that this straightened it out for me (but don't hold me to it as I was trying all kinds of stuff and it was a couple days ago): dpkg --force-all -i /var/cache/apt/archives/education-astronomy_0.825_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#446976: libapache2-mod-bt: crashes when request handler handles request
Gary, Is there any way you can get a stack backtrace out of this? Like attaching gdb to a httpd process and then causing the segfault? Thanks, Tyler Gary Kramlich [EMAIL PROTECTED] wrote: Package: libapache2-mod-bt Version: 0.0.19+p4.2340-1 Severity: grave Justification: renders package unusable I've written a configuration based loosely on the one provided with the package. Also requests, include /, /register, etc cause the apache subprocess to segfault. Here is the vhost block, identifiers masked... virtualhost *:6969 ServerName tracker.foo.bar DocumentRoot /var/www/foo.bar/tracker/ CustomLog /var/www/foo.bar/.access_log.tracker combined ErrorLog /var/www/foo.bar/.error_log.tracker ServerSignature off Tracker On TrackerHome /var/lib/mod_bt TrackerFlags AllowScrapeFull TrackerDetailURL /details/ Alias /mod_bt.css /usr/share/doc/libbtutil0/html/mod_bt.css LocationMatch ^/$ SetHandler modbt-root IfModule mod_include.c Options +Includes SetOutputFilter INCLUDES /IfModule /LocationMatch Location /announce SetHandler modbt-announce /Location Location /scrape SetHandler modbt-scrape /Location Location /details SetHandler modbt-details /Location Location /register SetHandler modbt-register /Location /virtualhost Sefault messages appear in /var/log/apache2/error.log, nothing is left in /var/www/foo.bar/.error_log.tracker. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.16-2-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libapache2-mod-bt depends on: ii apache2-mpm-prefork 2.2.3-3.1Traditional model for Apache HTTPD ii apache2.2-common2.2.3-3.1Next generation, scalable, extenda ii libbttracker0 0.0.19+p4.2340-1 BitTorrent Tracker Library ii libbtutil0 0.0.19+p4.2340-1 BitTorrent utility library libapache2-mod-bt recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#424833: New mod_bt .deb's
tag 424833 pending thanks Hi Julien, mod_bt development has continued to stagnate for awhile... one of these days I'll get the time to keep going on it... my next goal is to get it moved off of this perforce repo into subversion... i've gotten sick and tired of perforce... Anyways, i've rolled up a new release to deal with bug #424833. The only change should be a lack of dependancies on php4, and a lack of a php4-apache2-mod-bt package. You can find the new package here: http://www.crackerjack.net/mod_bt/debian/etch/ Let me know when you get a chance to upload it :-) Thanks, Tyler signature.asc Description: Digital signature
Bug#424833: php4-apache2-mod-bt: affected by php4-removal
Hi, I've fixed the bug in a new build, I will play around with it a bit and then fire it off to my sponsor to upload. Thanks, Tyler Debian PHP Maintainers [EMAIL PROTECTED] wrote: Package: php4-apache2-mod-bt Severity: serious User: [EMAIL PROTECTED] Usertags: php4-removal This package has been identified as affected by the removal of php4 in debian. As php4 will soon be removed, it is very important that we: - update the dependencies of all applicable packages to coexist with php5 - remove source and/or binary packages which have no use without php4 for more information on what may need to be done, please see http://wiki.debian.org/PHP4Removal if you have any questions, please contact the debian php maintainers [EMAIL PROTECTED] thanks! -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400239: monodevelop crashes on startup
Package: monodevelop Version: 0.12+dfsg-1 Severity: grave Justification: renders package unusable I started using monodevelop two days ago, got a simple project off of the ground... then closed it. Yesterday and today I've tried to open it, but monodevelop crashes on startup. It gets as far as showing the title window, the title bar changes to Welcome, and then the stack trace below comes up. I don't think I did anything unusual. I just tried removing my .config/MonoDevelop directory, and that makes it work. I have uploaded my MonoDevelop directory here so you can reproduce the problem: http://www.crackerjack.net/~faraway/MonoDevelop.tgz Thanks, Tyler = Got a SIGSEGV while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. = Stacktrace: at (wrapper managed-to-native) Gecko.WebControl.gtk_moz_embed_render_data (intptr,intptr,uint,intptr,intptr) 0x4 at (wrapper managed-to-native) Gecko.WebControl.gtk_moz_embed_render_data (intptr,intptr,uint,intptr,intptr) 0x at Gecko.WebControl.RenderData (string,string,string) 0x00079 at c__CompilerGenerated1.c__AnonymousMethod2 () 0x00028 at (wrapper delegate-invoke) System.MulticastDelegate.invoke_bool () 0x at IdleProxy.Handler () 0x0002a at (wrapper native-to-managed) IdleProxy.Handler () 0x at (wrapper managed-to-native) Gtk.Application.gtk_main_iteration_do (bool) 0x4 at (wrapper managed-to-native) Gtk.Application.gtk_main_iteration_do (bool) 0x at Gtk.Application.RunIteration (bool) 0xc at MonoDevelop.Ide.Gui.Dialogs.SplashScreenForm.RunMainLoop () 0xe at MonoDevelop.Ide.Gui.Dialogs.SplashScreenForm.SetProgress (double) 0x00025 at MonoDevelop.Ide.Gui.Dialogs.SplashScreenForm.MonoDevelop.Core.IProgressMonitor.EndTask () 0x00032 at MonoDevelop.Ide.Gui.IdeApp.Initialize (MonoDevelop.Core.IProgressMonitor) 0x0053c at MonoDevelop.Ide.Gui.IdeStartup.Run (string[]) 0x00b71 at MonoDevelop.Core.AddIns.AddInService.StartApplication (string,string[]) 0x0017c at MonoDevelop.Startup.SharpDevelopMain.Main (string[]) 0x00039 at (wrapper runtime-invoke) System.Object.runtime_invoke_int_string[] (object,intptr,intptr,intptr) 0x Native stacktrace: /usr/bin/mono [0x8189c4d] /usr/bin/mono [0x816c752] [0xb7fde440] /usr/lib/libgtkembedmoz.so.0d(gtk_moz_embed_render_data+0x58) /[0xb4fb07d8] [0xb300b8e6] [0xb300b87a] [0xb300b7e1] [0xb5c2f26d] [0xb300a9cb] [0x9c96854] /usr/lib/libglib-2.0.so.0 [0xb7f5c9b1] /usr/lib/libglib-2.0.so.0(g_main_context_dispatch+0x181) /[0xb7f5e731] /usr/lib/libglib-2.0.so.0 [0xb7f617a6] /usr/lib/libglib-2.0.so.0(g_main_context_iteration+0x77) /[0xb7f61d27] /usr/lib/libgtk-x11-2.0.so.0(gtk_main_iteration_do+0x33) /[0xb66a0073] [0xb6afc502] [0xb6afc4b5] [0xb6afc3e7] [0xb5c2e3f6] [0xb5c2e1f3] [0xb5c31c7d] [0xb6f80672] [0xb70a47a5] [0xb74cf132] [0xb74cf074] /usr/bin/mono [0x816c61d] /usr/bin/mono(mono_runtime_invoke+0x27) [0x80f0ecf] /usr/bin/mono(mono_runtime_exec_main+0x109) [0x80f57e0] /usr/bin/mono(mono_runtime_run_main+0x276) [0x80f5abf] /usr/bin/mono(mono_jit_exec+0xbd) [0x80587b8] /usr/bin/mono [0x8058895] /usr/bin/mono(mono_main+0x1610) [0x805a034] /usr/bin/mono [0x8057996] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xc8) [0xb7dd5ea8] /usr/bin/mono [0x80578f1] Debug info from gdb: (no debugging symbols found) Using host libthread_db library /lib/tls/i686/cmov/libthread_db.so.1. (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1210316128 (LWP 9278)] [New Thread -1283404880 (LWP 9359)] [New Thread -1282352208 (LWP 9358)] [New Thread -1281299536 (LWP 9357)] [New Thread -1279272016 (LWP 9356)] [New Thread -1278219344 (LWP 9355)] [New Thread -1277166672 (LWP 9354)] [New Thread -1274020944 (LWP 9353)] [New Thread -1253196880 (LWP 9351)] [New Thread -1251984464 (LWP 9350)] [New Thread -1219703888 (LWP 9287)] [New Thread -1214014544 (LWP 9286)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols
Bug#391636: Uninstallable due to unmet dep on libapr0
Tollef Fog Heen [EMAIL PROTECTED] wrote: This has been fixed already. Somebody needs to upload a 2.2-compatible mod_perl, though. I think all that's neccessary is a control file update to make it build-depend on the new stuff. I'll give it a shot and let you know. I can't upload it though, I'm not an official maintainer yet... - Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391636: Uninstallable due to unmet dep on libapr0
Luk Claes [EMAIL PROTECTED] wrote: Package: libbtutil0 Severity: serious Version: 0.0.19-1 Your package is not installable as it depends on libapr0 which is not available in unstable anymore. You might want to update the dependency to libapr1. I know. :-( Unfortunately, the apache2 in unstable doesn't install correctly anymore either because it fails to create /var/log/apache2, so I can't prove a working build in pbuilder. To top it off, the libapache2-mod-perl2 package has not been converted to apache2.2 yet, so if I want to release new .debs, I can't provide libapache2-modbt-perl yet. I'm keeping tabs on the situation; as soon as it's possible to release new .debs that will autobuild, I'll put out 0.0.19-2. Thanks, Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380250: tpkg-debarch should support arm-linux-gnu target (was Re: small quirks setting up a cross-compile toolchain)
Package: toolchain-source Severity: grave Tags: patch toolchain-source as it stands is currently unusable for building ARM cross-compiler targets. It appears that you must specify arm-linux-gnu to several of the builds in order to get the install to work correctly. However, this target is not supported by tpkg-debarch. The attached patch is not a complete solution, but it at least makes it *possible* to build for arm again (so long as you use the magic arm-linux-gnu incantation). Nathanael Nerode [EMAIL PROTECTED] wrote: See, there's your problem. Try: tpkg-make arm-linux-gnu TPKG_SERVER=ftp.yi.org tpkg-install-libc arm-linux-gnu And you should end up with only arm-linux-gnu. For obscure reasons (which I would like to get rid of), some parts of the cross-tools structure care about exactly what form of the system name you give to the tools, while others use the canonical name. If you still end up with two different things come back and complain to whoever's generating arm-linux. Okay, so when I did that, I would get this message every so often: Hmph - dunno the arm-linux-gnu arch ... and then eventually: http://ftp.yi.org/debian/dists/testing/main/binary-none/Packages.gz = /tmp/tpkg-install-libc.CMosC11963/packageset.gz' Resolving ftp.yi.org... 209.172.55.241 Connecting to ftp.yi.org|209.172.55.241|:80... connected. HTTP request sent, awaiting response... 404 Not Found 09:49:26 ERROR 404: Not Found. binary-none, eh? So I added arm-linux-gnu to tpkg-debarch, and that made it work!!! --- /usr/bin/tpkg-debarch 2005-01-06 08:26:04.0 -0800 +++ /usr/bin/tpkg-debarch.new 2006-07-28 10:10:29.0 -0700 @@ -4,7 +4,7 @@ alpha-linux) debarch=alpha ;; -arm-linux|arm) +arm-linux|arm-linux-gnu|arm) debarch=arm ;; hppa-linux|hppa)
Bug#378375: I think debian Bug#378375 is fixed....
tag 378375 patch thanks Bastian, I think I have fixed the problem with WORDS_BIGENDIAN. I have uploaded .deb's here: http://www.crackerjack.net/mod_bt/debian/sid/ Before I have them added to debian, would you be willing to try and build this on your s390 box to verify that it actually fixes the problem and there aren't any other problems with building on that architecture? Thanks, Tyler Tyler MacDonald [EMAIL PROTECTED] wrote: Hmm.. from the looks of things, this is some sort of conflict between PHP and apache and probably not a bug with mod_bt itself... I wonder if either of those packages had to do some sort of kludgey workaround to get them to compile under s390? I will look into it further soon. - Tyler Bastian Blank [EMAIL PROTECTED] wrote: Package: mod-bt Version: 0.0.18+p4.1364-1 Severity: serious There was an error while trying to autobuild your package: Automatic build of mod-bt_0.0.18+p4.1364-1 on debian-31 by sbuild/s390 85 [...] s390-linux-gnu-gcc -DPACKAGE_NAME=\\ -DPACKAGE_TARNAME=\\ -DPACKAGE_VERSION=\\ -DPACKAGE_STRING=\\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE=\mod_bt\ -DVERSION=\0.0.18\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -D_FILE_OFFSET_BITS=64 -DHAVE_MODPERL_APACHE_INCLUDES_H=1 -DHAVE_ZEND_ZEND_H=1 -DSIZEOF_TIME_T=4 -I. -I. -I/usr/include/php5 -I/usr/include/php5/main -I/usr/include/php5/TSRM -I/usr/include/php5/Zend -I/usr/include/php5/ext -DCOMPILE_DL=1 -I/usr/include/openssl -I/usr/include/apache2 -I/usr/include/apr-0 -I../../../src -I/usr/include/apr-0 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I/usr/include/libxml2 -I/usr/include/apache2 -I/usr/include/php5 -I/usr/include/php5/main -I/usr/include/php5/TSRM -I/usr/include/php5/Zend -I/usr/include/php5/ext -fpic -g -O2 -O2 -Wall -Werror -MT php_mod_bt.lo -MD -MP -MF .deps/php_mod_bt.Tpo -c php_mod_bt.c -fPIC -DPIC -o .libs/php_mod_bt.o In file included from /usr/include/apache2/ap_config.h:231, from /usr/include/apache2/httpd.h:30, from php_apache.h:4, from php_mod_bt.c:30: /usr/include/apache2/ap_config_auto.h:201:1: error: WORDS_BIGENDIAN redefined In file included from /usr/include/php5/TSRM/tsrm_config.h:1, from /usr/include/php5/TSRM/tsrm_config_common.h:11, from /usr/include/php5/TSRM/tsrm_virtual_cwd.h:26, from /usr/include/php5/main/php.h:404, from php_mod_bt.c:24: /usr/include/php5/main/../main/php_config.h:2213:1: error: this is the location of the previous definition make[4]: *** [php_mod_bt.lo] Error 1 make[4]: Leaving directory `/build/buildd/mod-bt-0.0.18+p4.1364/src/apache2/php_mod_bt' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/build/buildd/mod-bt-0.0.18+p4.1364/src/apache2' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/build/buildd/mod-bt-0.0.18+p4.1364/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/build/buildd/mod-bt-0.0.18+p4.1364' make: *** [build-stamp] Error 2 ** Build finished at 20060714-0936 FAILED [dpkg-buildpackage died] -- --
Bug#378375: mod-bt - FTBFS: error: WORDS_BIGENDIAN redefined
Hmm.. from the looks of things, this is some sort of conflict between PHP and apache and probably not a bug with mod_bt itself... I wonder if either of those packages had to do some sort of kludgey workaround to get them to compile under s390? I will look into it further soon. - Tyler Bastian Blank [EMAIL PROTECTED] wrote: Package: mod-bt Version: 0.0.18+p4.1364-1 Severity: serious There was an error while trying to autobuild your package: Automatic build of mod-bt_0.0.18+p4.1364-1 on debian-31 by sbuild/s390 85 [...] s390-linux-gnu-gcc -DPACKAGE_NAME=\\ -DPACKAGE_TARNAME=\\ -DPACKAGE_VERSION=\\ -DPACKAGE_STRING=\\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE=\mod_bt\ -DVERSION=\0.0.18\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -D_FILE_OFFSET_BITS=64 -DHAVE_MODPERL_APACHE_INCLUDES_H=1 -DHAVE_ZEND_ZEND_H=1 -DSIZEOF_TIME_T=4 -I. -I. -I/usr/include/php5 -I/usr/include/php5/main -I/usr/include/php5/TSRM -I/usr/include/php5/Zend -I/usr/include/php5/ext -DCOMPILE_DL=1 -I/usr/include/openssl -I/usr/include/apache2 -I/usr/include/apr-0 -I../../../src -I/usr/include/apr-0 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I/usr/include/libxml2 -I/usr/include/apache2 -I/usr/include/php5 -I/usr/include/php5/main -I/usr/include/php5/TSRM -I/usr/include/php5/Zend -I/usr/include/php5/ext -fpic -g -O2 -O2 -Wall -Werror -MT php_mod_bt.lo -MD -MP -MF .deps/php_mod_bt.Tpo -c php_mod_bt.c -fPIC -DPIC -o .libs/php_mod_bt.o In file included from /usr/include/apache2/ap_config.h:231, from /usr/include/apache2/httpd.h:30, from php_apache.h:4, from php_mod_bt.c:30: /usr/include/apache2/ap_config_auto.h:201:1: error: WORDS_BIGENDIAN redefined In file included from /usr/include/php5/TSRM/tsrm_config.h:1, from /usr/include/php5/TSRM/tsrm_config_common.h:11, from /usr/include/php5/TSRM/tsrm_virtual_cwd.h:26, from /usr/include/php5/main/php.h:404, from php_mod_bt.c:24: /usr/include/php5/main/../main/php_config.h:2213:1: error: this is the location of the previous definition make[4]: *** [php_mod_bt.lo] Error 1 make[4]: Leaving directory `/build/buildd/mod-bt-0.0.18+p4.1364/src/apache2/php_mod_bt' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/build/buildd/mod-bt-0.0.18+p4.1364/src/apache2' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/build/buildd/mod-bt-0.0.18+p4.1364/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/build/buildd/mod-bt-0.0.18+p4.1364' make: *** [build-stamp] Error 2 ** Build finished at 20060714-0936 FAILED [dpkg-buildpackage died] --
Bug#377595: mod-bt - FTBFS: warning: format '%d' expects type 'int', but argument 3 has type 'size_t'
Kurt Roeckx [EMAIL PROTECTED] wrote: http://www.crackerjack.net/mod_bt/debian/sid/ That one build without any problems. Awesome, thank you again for your help... I have sent an email off to Julien letting him know, this should be uploaded soon. :) - Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377595: mod-bt - FTBFS: warning: format '%d' expects type 'int', but argument 3 has type 'size_t'
Kurt Roeckx [EMAIL PROTECTED] wrote: I applied these and zelously went through and made sure everything in those files is type-safe. Now the result isn't releaseable on 32-bit platforms, it compiles fine, but it's causing segmentation faults after a few minutes of operation. :-/ I don't think the changes made to the printf()'s are causing segfaults. I'm guessing some other changes where made. I changed the types of some variables along the way and converted as much as I could to use PRI's instead of straight formatting codes. Like I said, I got zealous about it. :) So, I still get those: Cool, I'll have a look at those tonight. Thanks, I'm learning a lot from this. :) - Tyler bt_metainfo.c: In function 'load_metainfo': bt_metainfo.c:45: warning: format '%llu' expects type 'long long unsigned int', but argument 4 has type '__off_t' bt_metainfo.c:66: warning: format '%llu' expects type 'long long unsigned int', but argument 3 has type '__off_t' bt_metainfo.c:74: warning: format '%llu' expects type 'long long unsigned int', but argument 4 has type '__off_t' Which where the off_t problem. I had changed those to %zu, but I assume that didn't work out on 32 bit. And this seems to be new: btt_tracker_alloc.c: In function 'shmem_filename': btt_tracker_alloc.c:42: warning: format '%ld' expects type 'long int', but argument 5 has type 'int' btt_tracker_alloc.c:42: warning: format '%ld' expects type 'long int', but argument 6 has type 'int' len is an int, and so since BT_FILE_LEN is a constant, so is the last argument. I suggest you just change thsoe to %d. Then there is: btt_peer.c: In function 'btt_peer2bencode': btt_peer.c:274: warning: format '%u' expects type 'unsigned int', but argument 3 has type 'size_t' and a size_t requires %zu. Then we get: Tracker.xs: In function 'XS_Net__BitTorrent__LibBT__Tracker_Infohash': Tracker.xs:580: warning: format '%zu' expects type 'size_t', but argument 4 has type 'int' Tracker.xs: In function 'XS_Net__BitTorrent__LibBT__Tracker__Infohash_Peer': Tracker.xs:1051: warning: format '%zu' expects type 'size_t', but argument 4 has type 'int' The len has the correct %zu, but BT_INFOHASH_LEN and BT_PEERID_LEN are only an int. That was it. Kurt -- Tank will collaboratively market mission-critical appliances.
Bug#377595: mod-bt - FTBFS: warning: format '%d' expects type 'int', but argument 3 has type 'size_t'
Kurt Roeckx [EMAIL PROTECTED] wrote: So, I still get those: OK Kurt, try this one: http://www.crackerjack.net/mod_bt/debian/sid/ mod-bt_0.0.18+p4.1359 This should fix the problems listed below, as well as Bug #376998. Let me know; if it works, I'll ask Julien to upload it. Thanks, Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377595: mod-bt - FTBFS: warning: format '%d' expects type 'int', but argument 3 has type 'size_t'
err, make that and bug #378035... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377595: mod-bt - FTBFS: warning: format '%d' expects type 'int', but argument 3 has type 'size_t'
Kurt Roeckx [EMAIL PROTECTED] wrote: bt_metainfo.c:120: warning: format '%d' expects type 'int', but argument 3 has type 'apr_size_t' [...] bt_bcode.c:143: warning: format '%lli' expects type 'long long int', but argument 3 has type 'int64_t' bt_bcode.c:152: warning: format '%i' expects type 'int', but argument 3 has type 'apr_size_t' [...] btt_tracker_alloc.c: In function 'shmem_filename': btt_tracker_alloc.c:40: warning: format '%zd' expects type 'signed size_t', but argument 5 has type 'int' Kurt, I believe those are addressed in mod-bt_0.0.18+p4.1364, if you'd like to have a look: http://www.crackerjack.net/mod_bt/debian/sid/ Thanks for your patience. :) - Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377595: mod-bt - FTBFS: warning: format '%d' expects type 'int', but argument 3 has type 'size_t'
Thanks Kurt,
I've been working through your patch and correcting the code in
dev... If you're willing, I would like to send you my results when I'm done
to test again.
I really need to get myself a 64-bit box...
Thanks,
Tyler
Kurt Roeckx [EMAIL PROTECTED] wrote:
On Mon, Jul 10, 2006 at 02:30:21PM -0700, Tyler MacDonald wrote:
Kurt,
Any chance I can get access to a box to play around with? This (and
other problems) could pop up all over the place in the code, it'd be nice to
be able to tackle them all at once instead of just uploading a new version
to find a new problem...
I've started changing things and I've attached the patch
from as far as I got. When using printing a size_t, you
need the z modifier in printf(). For u_int64_t's you have
things in inttypes.h like PRIu64 that should give you
the right string.
The only problem I've had was with off_t. It works for me
if I use the z modifier, as used for size_t, but I have a
feeling this isn't very portable, and I haven't tried this
on a 32 bit system. Not that if you have large file
support, an off_t might be 64 bit with a size_t only 32
bit. I don't know how to portably print those.
Then I got:
Tracker.xs: In function 'XS_Net__BitTorrent__LibBT__Tracker_Infohash':
Tracker.xs:576: warning: passing argument 3 of 'Perl_sv_2pv_flags' from
incompatible pointer type
Tracker.xs: In function 'XS_Net__BitTorrent__LibBT__Tracker__Infohash_Peer':
Tracker.xs:1047: warning: passing argument 3 of 'Perl_sv_2pv_flags' from
incompatible pointer type
And I'm not sure how to deal with this, but didn't look
very hard at it.
If I don't forgot, I'll try looking at it again tomorrow.
Kurt
--- src/libbtutil/util/bt_nice_size.c.old 2006-07-10 23:40:58.0
+0200
+++ src/libbtutil/util/bt_nice_size.c 2006-07-10 23:44:04.0 +0200
@@ -7,6 +7,7 @@
#include stdio.h
#include stdlib.h
#include sys/types.h
+#include inttypes.h
#define SZSTR64
@@ -31,7 +32,7 @@
}
else
{
- snprintf(szstr, SZSTR, %llub, size);
+ snprintf(szstr, SZSTR, % PRIu64 b, size);
}
rv = apr_pstrdup(p, szstr);
--- src/libbtutil/types/bt_metainfo.c.old 2006-07-10 23:45:09.0
+0200
+++ src/libbtutil/types/bt_metainfo.c 2006-07-10 23:53:42.0 +0200
@@ -40,7 +40,7 @@
if(sinfo.st_size BT_MAX_METAINFO_SIZE) {
fprintf(
-stderr, %s: file to large (%llu bytes %u bytes),
+stderr, %s: file to large (%zu bytes %u bytes),
path, sinfo.st_size, BT_MAX_METAINFO_SIZE
);
return NULL;
@@ -60,7 +60,7 @@
if((rv = apr_file_read(file, buf, len)) != APR_SUCCESS) {
fprintf(
-stderr, Failed to read %llu bytes from %s: %s\n,
+stderr, Failed to read %zu bytes from %s: %s\n,
sinfo.st_size, path,
apr_strerror(rv, errorstr, BT_SHORT_STRING)
);
@@ -70,7 +70,7 @@
if(len != sinfo.st_size) {
fprintf(
stderr,
-%s: expected %llu bytes, but got %SF!\n, path,
sinfo.st_size, len
+%s: expected %zu bytes, but got %SF!\n, path, sinfo.st_size,
len
);
return NULL;
}
--- src/libbttracker/tracker/btt_tracker_alloc.c.old 2006-07-10
23:54:53.0 +0200
+++ src/libbttracker/tracker/btt_tracker_alloc.c 2006-07-10
23:55:52.0 +0200
@@ -122,13 +122,13 @@
rv = NULL;
} else {
if((ret = apr_shm_create(rv, size, shfile, p)) != APR_SUCCESS) {
- fprintf(stderr, apr_shm_create(rv, %d, \%s\, pool) failed: %s\n,
size, shfile, apr_strerror(ret, btt_error_msg, sizeof(btt_error_msg)));
+ fprintf(stderr, apr_shm_create(rv, %zd, \%s\, pool) failed:
%s\n, size, shfile, apr_strerror(ret, btt_error_msg, sizeof(btt_error_msg)));
fflush(stderr);
rv = NULL;
}
}
} else {
- fprintf(stderr, apr_shm_create(rv, %d, \%s\, pool) failed: %s\n,
size, shfile, apr_strerror(ret, btt_error_msg, sizeof(btt_error_msg)));
+ fprintf(stderr, apr_shm_create(rv, %zd, \%s\, pool) failed: %s\n,
size, shfile, apr_strerror(ret, btt_error_msg, sizeof(btt_error_msg)));
fflush(stderr);
rv = NULL;
}
@@ -189,7 +189,7 @@
return NULL;
}
} else {
-fprintf(stderr, bt_tracker_alloc(): Failed to allocate %d
bytes!\n, sizeof(btt_tracker));
+fprintf(stderr, bt_tracker_alloc(): Failed to allocate %zd
bytes!\n, sizeof(btt_tracker));
fflush(stderr);
return NULL;
}
--- src/libbttracker/types/btt_infohash.c.old 2006-07-10 23:56:48.0
+0200
+++ src/libbttracker/types/btt_infohash.c 2006-07-11 00:02:16.0
+0200
@@ -18,6 +18,7 @@
/* libc */
#include time.h
#include stdio.h
+#include inttypes.h
/* other libs
Bug#377595: mod-bt - FTBFS: warning: format '%d' expects type 'int', but argument 3 has type 'size_t'
Kurt,
I applied these and zelously went through and made sure everything
in those files is type-safe. Now the result isn't releaseable on 32-bit
platforms, it compiles fine, but it's causing segmentation faults after a
few minutes of operation. :-/
I will keep investigating as I have time... I think my wife wants to
watch a movie I've seen a dozen times tonight so I may have a chance to hack
a bit more then. :-)
If you're interested, the results are here... I'm interested in
seeing if they at least compile in amd64 now:
http://www.crackerjack.net/mod_bt/debian/sid/
I'll let you know again when I have something I think will actually
work.
Cheers,
Tyler
Kurt Roeckx [EMAIL PROTECTED] wrote:
On Tue, Jul 11, 2006 at 11:23:23AM -0700, Tyler MacDonald wrote:
Thanks Kurt,
I've been working through your patch and correcting the code in
dev... If you're willing, I would like to send you my results when I'm done
to test again.
Sure, just send me the diff or some url or something.
Then I got:
Tracker.xs: In function 'XS_Net__BitTorrent__LibBT__Tracker_Infohash':
Tracker.xs:576: warning: passing argument 3 of 'Perl_sv_2pv_flags' from
incompatible pointer type
Tracker.xs: In function
'XS_Net__BitTorrent__LibBT__Tracker__Infohash_Peer':
Tracker.xs:1047: warning: passing argument 3 of 'Perl_sv_2pv_flags' from
incompatible pointer type
So, I've fixed those an others too. I've attached the complete
diff.
Kurt
--- src/libbtutil/util/bt_nice_size.c.old 2006-07-10 23:40:58.0
+0200
+++ src/libbtutil/util/bt_nice_size.c 2006-07-10 23:44:04.0 +0200
@@ -7,6 +7,7 @@
#include stdio.h
#include stdlib.h
#include sys/types.h
+#include inttypes.h
#define SZSTR64
@@ -31,7 +32,7 @@
}
else
{
- snprintf(szstr, SZSTR, %llub, size);
+ snprintf(szstr, SZSTR, % PRIu64 b, size);
}
rv = apr_pstrdup(p, szstr);
--- src/libbtutil/types/bt_metainfo.c.old 2006-07-10 23:45:09.0
+0200
+++ src/libbtutil/types/bt_metainfo.c 2006-07-10 23:53:42.0 +0200
@@ -40,7 +40,7 @@
if(sinfo.st_size BT_MAX_METAINFO_SIZE) {
fprintf(
-stderr, %s: file to large (%llu bytes %u bytes),
+stderr, %s: file to large (%zu bytes %u bytes),
path, sinfo.st_size, BT_MAX_METAINFO_SIZE
);
return NULL;
@@ -60,7 +60,7 @@
if((rv = apr_file_read(file, buf, len)) != APR_SUCCESS) {
fprintf(
-stderr, Failed to read %llu bytes from %s: %s\n,
+stderr, Failed to read %zu bytes from %s: %s\n,
sinfo.st_size, path,
apr_strerror(rv, errorstr, BT_SHORT_STRING)
);
@@ -70,7 +70,7 @@
if(len != sinfo.st_size) {
fprintf(
stderr,
-%s: expected %llu bytes, but got %SF!\n, path,
sinfo.st_size, len
+%s: expected %zu bytes, but got %SF!\n, path, sinfo.st_size,
len
);
return NULL;
}
--- src/libbttracker/tracker/btt_tracker_alloc.c.old 2006-07-10
23:54:53.0 +0200
+++ src/libbttracker/tracker/btt_tracker_alloc.c 2006-07-10
23:55:52.0 +0200
@@ -122,13 +122,13 @@
rv = NULL;
} else {
if((ret = apr_shm_create(rv, size, shfile, p)) != APR_SUCCESS) {
- fprintf(stderr, apr_shm_create(rv, %d, \%s\, pool) failed: %s\n,
size, shfile, apr_strerror(ret, btt_error_msg, sizeof(btt_error_msg)));
+ fprintf(stderr, apr_shm_create(rv, %zd, \%s\, pool) failed:
%s\n, size, shfile, apr_strerror(ret, btt_error_msg, sizeof(btt_error_msg)));
fflush(stderr);
rv = NULL;
}
}
} else {
- fprintf(stderr, apr_shm_create(rv, %d, \%s\, pool) failed: %s\n,
size, shfile, apr_strerror(ret, btt_error_msg, sizeof(btt_error_msg)));
+ fprintf(stderr, apr_shm_create(rv, %zd, \%s\, pool) failed: %s\n,
size, shfile, apr_strerror(ret, btt_error_msg, sizeof(btt_error_msg)));
fflush(stderr);
rv = NULL;
}
@@ -189,7 +189,7 @@
return NULL;
}
} else {
-fprintf(stderr, bt_tracker_alloc(): Failed to allocate %d
bytes!\n, sizeof(btt_tracker));
+fprintf(stderr, bt_tracker_alloc(): Failed to allocate %zd
bytes!\n, sizeof(btt_tracker));
fflush(stderr);
return NULL;
}
--- src/libbttracker/types/btt_infohash.c.old 2006-07-10 23:56:48.0
+0200
+++ src/libbttracker/types/btt_infohash.c 2006-07-11 00:02:16.0
+0200
@@ -18,6 +18,7 @@
/* libc */
#include time.h
#include stdio.h
+#include inttypes.h
/* other libs */
#include apr.h
#include apr_pools.h
@@ -79,7 +80,7 @@
TRTHInfohash:/THTD%s/TH/TR\n
TRTHFilename:/THTD%s/TD/TR\n
TRTHFile Size:/THTD%s/TD/TR\n
- TRTHAnnounce Hits:/THTD%llu/TD
Bug#377595: mod_bt needs to use the correct format for size_t on all architectures
Package: mod_bt Severity: serious Thanks Bastian, I'm filing this upstream as well and will fix this ASAP. Bastian Blank [EMAIL PROTECTED] wrote: Package: mod-bt Version: 0.0.18+p4.1178-2 Severity: serious There was an error while trying to autobuild your package: Automatic build of mod-bt_0.0.18+p4.1178-2 on debian-31 by sbuild/s390 85 [...] mkdir .libs s390-linux-gnu-gcc -DPACKAGE_NAME=\\ -DPACKAGE_TARNAME=\\ -DPACKAGE_VERSION=\\ -DPACKAGE_STRING=\\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE=\mod_bt\ -DVERSION=\0.0.18\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -D_FILE_OFFSET_BITS=64 -DHAVE_MODPERL_APACHE_INCLUDES_H=1 -DHAVE_ZEND_ZEND_H=1 -I. -I. -I../../../src -I/usr/include/apr-0 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I/usr/include/libxml2 -I/usr/include/apache2 -I/usr/include/php5 -I/usr/include/php5/main -I/usr/include/php5/TSRM -I/usr/include/php5/Zend -I/usr/include/php5/ext -g -O2 -O2 -Wall -Werror -MT btt_tracker_alloc.lo -MD -MP -MF .deps/btt_tracker_alloc.Tpo -c btt_tracker_alloc.c -fPIC -DPIC -o .libs/btt_tracker_alloc.o cc1: warnings being treated as errors btt_tracker_alloc.c: In function 'new_shmem_segment': btt_tracker_alloc.c:125: warning: format '%d' expects type 'int', but argument 3 has type 'size_t' btt_tracker_alloc.c:131: warning: format '%d' expects type 'int', but argument 3 has type 'size_t' btt_tracker_alloc.c: In function 'btt_tracker_alloc': btt_tracker_alloc.c:192: warning: format '%d' expects type 'int', but argument 3 has type 'long unsigned int' make[4]: *** [btt_tracker_alloc.lo] Error 1 make[4]: Leaving directory `/build/buildd/mod-bt-0.0.18+p4.1178/src/libbttracker/tracker' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/build/buildd/mod-bt-0.0.18+p4.1178/src/libbttracker' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/build/buildd/mod-bt-0.0.18+p4.1178/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/build/buildd/mod-bt-0.0.18+p4.1178' make: *** [build-stamp] Error 2 ** Build finished at 20060710-0513 FAILED [dpkg-buildpackage died] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377420: mod-bt - FTBFS: Not resolvable build dependencies
Bastian Blank [EMAIL PROTECTED] wrote: Package: mod-bt Version: 0.0.18+p4.1178-1 Severity: serious There was an error while trying to autobuild your package: Automatic build of mod-bt_0.0.18+p4.1178-1 on lxdebian.bfinv.de by sbuild/s390 85 [...] ** Using build dependencies supplied by package: Build-Depends: debhelper (= 4.2.32), cpio, apache2-prefork-dev, libxml2-dev, libapr1-dev | libapr0-dev, libdb4.4-dev | libdb4.3-dev | libdb4.2-dev, automake1.9, autoconf, perl, libapache2-mod-perl2-dev, php4-dev, php5-dev, php5-cli | php4-cli [...] Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: apache2-prefork-dev: Depends: libapr0-dev (= 2.0.55-4) but it is not going to be installed Depends: libdb4.3-dev but it is not going to be installed E: Broken packages apache2-prefork-dev depends on libapr0-dev which conflicts with libapr1-dev. But that should be fine, since I depend on libapr1-dev *or* libapr0-dev, shouldn't it? pbuilder handles it without a problem... Thanks, Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377420: mod-bt - FTBFS: Not resolvable build dependencies
Bastian Blank [EMAIL PROTECTED] wrote: On Sun, Jul 09, 2006 at 10:10:37AM -0700, Tyler MacDonald wrote: apache2-prefork-dev depends on libapr0-dev which conflicts with libapr1-dev. But that should be fine, since I depend on libapr1-dev *or* libapr0-dev, shouldn't it? pbuilder handles it without a problem... No. The autobuilders only use the first branch of an ORed build dependency. Is that a bug or a feature? I thought if something was lintian/linda/pbuilder-safe, then it was good for release. pbuilder definately considers each option, and there are great practical benefits in situations like this; when debian finally moves over to apache 2.2, from pbuilder's perspective, mod-bt shouldn't need any changes as it stands now. But if I have to remove the apr1 | apr0 sutff, then a new version of mod-bt (and every other apache2 module) will be neccessary when the switch to 2.2 happens. Or is there another way around this? Either way, I'll produce a new version within the next week with the dependancies corrected to autobuilders' satisfaction. Thanks, Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377420: mod-bt - FTBFS: Not resolvable build dependencies
Asheesh Laroia [EMAIL PROTECTED] wrote: But if I have to remove the apr1 | apr0 sutff, then a new version of mod-bt (and every other apache2 module) will be neccessary when the switch to 2.2 happens. In theory you could just switch the order of apr1 | apr0. But I agree that this is less than desired. That was the way I used to have it, but then pbuilder would *never* try apr1 since apr0 was always satisfactory... - Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377420: mod-bt - FTBFS: Not resolvable build dependencies
Kurt Roeckx [EMAIL PROTECTED] wrote: Yes, name it libapr-dev. If something really can use either one of the 2, I don't see why you should make a transition so hard and go and name it libapr0-dev. So I suggest you rename libapr0-dev to libapr-dev and make it provide libapr0-dev for now. Well, APR's not my package, but I sort-of agree. There are a few minor API incompatibilites between APR-0 and APR-1 that might make this a Bad Thing, or at least Hard Thing. For instance: #if APR_MAJOR_VERSION == 0 #define apr_socket_create(a,b,c,d,e) apr_socket_create(a,b,c,e) #endif Cheers, Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377420: (no subject)
tag 377420 patch thanks A fix for this bug is available and waiting for my sponsor to upload. Julien, Can you please upload mod-bt_0.0.18+p4.1178-2? It has been placed online here: http://www.crackerjack.net/mod_bt/debian/sid/ The .orig tarball is identical. The only change is to not use OR dependancies at all in the debian/control file. Hopefully in the future this discrepancy between how pbuilder and autobuilds deal with control files will be addressed. Thanks, Tyler signature.asc Description: Digital signature
Bug#376998: btmakemetafile.bittornado is not option-compatible with established standard
Package: bittornado Version: 0.3.15-2 Severity: grave Justification: renders package unusable The official btmakemetafile's first two parmeters are: filename tracker_url The bittornado's btmakemetafile's first two parameters are: tracker_url filename Having bittornado's btmakemetafile be considered a valid alternative to the official standard causes software dependant on the standard btmakemetafile to fail; btmakemetafile.bittornado should not be listed as a debian alternative to the standard btmakemetafile. Thanks, Tyler -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.20-insane Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages bittornado depends on: ii python2.3.5-11 An interactive high-level object-o ii python-support0.3.8 automated rebuilding support for p Versions of packages bittornado recommends: ii mime-support 3.36-1 MIME files 'mime.types' 'mailcap -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#376998: btmakemetafile.bittornado is not option-compatible with established standard
Micah Anderson [EMAIL PROTECTED] wrote: Can you justify the grave severity by a citation? 2 grave makes the package in question unusable by most or all users, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package. By not following the commandline spec for bittorrent, btmakemetafile.bittornado renders itself unusable by most or all users (most or all users of system(btmakemetafile, ...) are automated scripts that depend on the established standard). - Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343998: anjuta 1.2.4a fixes this problem and is available on sourceforge.net
Package: anjuta Version: 1.2.4-1+b1 Followup-For: Bug #343998 anjuta 1.2.4a fixes this crash bug and is available on sourceforge.net. can the debian anjuta package be updated to this version? -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-2-686 Locale: LANG=en_CA, LC_CTYPE=en_CA (charmap=ISO-8859-1) Versions of packages anjuta depends on: ii anjuta-common 1.2.4-1Data files for Anjuta ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi ii libatk1.0-0 1.10.3-1 The ATK accessibility toolkit ii libaudiofile0 0.2.6-6Open-source version of SGI's audio ii libbonobo2-0 2.10.1-1 Bonobo CORBA interfaces library ii libbonoboui2-02.10.1-1 The Bonobo UI library ii libc6 2.3.5-11 GNU C Library: Shared libraries an ii libesd0 0.2.36-1 Enlightened Sound Daemon - Shared ii libfontconfig12.3.2-1.1 generic font configuration library ii libfreetype6 2.1.10-1 FreeType 2 font engine, shared lib ii libgcc1 1:4.0.2-5 GCC support library ii libgconf2-4 2.10.1-6 GNOME configuration database syste ii libgcrypt11 1.2.2-1LGPL Crypto library - runtime libr ii libglade2-0 1:2.5.1-2 library to load .glade files at ru ii libglib2.0-0 2.8.4-2The GLib library of C routines ii libgnome-keyring0 0.4.6-2GNOME keyring services library ii libgnome2-0 2.10.1-1 The GNOME 2 library - runtime file ii libgnomecanvas2-0 2.10.2-2 A powerful object-oriented display ii libgnomeprint2.2-02.10.3-3 The GNOME 2.2 print architecture - ii libgnomeprintui2.2-0 2.10.2-2 GNOME 2.2 print architecture User ii libgnomeui-0 2.10.1-1 The GNOME 2 libraries (User Interf ii libgnomevfs2-02.10.1-5 The GNOME virtual file-system libr ii libgnutls11 1.0.16-14 GNU TLS library - runtime library ii libgpg-error0 1.1-4 library for common error values an ii libgtk2.0-0 2.8.9-2The GTK+ graphical user interface ii libice6 6.9.0.dfsg.1-1 Inter-Client Exchange library ii libjpeg62 6b-11 The Independent JPEG Group's JPEG ii libncurses5 5.5-1 Shared libraries for terminal hand ii liborbit2 1:2.12.4-1 libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.10.1-2 Layout and rendering of internatio ii libpcre3 6.4-1.1Perl 5 Compatible Regular Expressi ii libpopt0 1.7-5 lib for parsing cmdline parameters ii libsm66.9.0.dfsg.1-1 X Window System Session Management ii libstdc++64.0.2-5The GNU Standard C++ Library v3 ii libtasn1-20.2.17-1 Manage ASN.1 structures (runtime) ii libvte4 1:0.11.15-4Terminal emulator widget for GTK+ ii libx11-6 6.9.0.dfsg.1-1 X Window System protocol client li ii libxft2 2.1.7-1FreeType-based font drawing librar ii libxml2 2.6.22-2 GNOME XML library ii libxrender1 1:0.9.0.2-1X Rendering Extension client libra ii scrollkeeper 0.3.14-10 A free electronic cataloging syste ii xlibs 6.9.0.dfsg.1-1 X Window System client libraries m ii zlib1g1:1.2.3-9 compression library - runtime Versions of packages anjuta recommends: ii autoconf 2.59a-7automatic configure script builder ii autogen 1:5.7.3-1 an automated text file generator ii automake1.4 [automake]1:1.4-p6-9 A tool for generating GNU Standard ii cvs 1:1.12.9-17Concurrent Versions System ii devhelp 0.10-6 A GNOME developers help program ii exuberant-ctags [ctags] 1:5.5.4-1 build tag file indexes of source c ii g++ 4:4.0.2-2 The GNU C++ compiler ii gcc 4:4.0.2-2 The GNU C compiler ii gdb 6.4-1 The GNU Debugger pn gnome-devel none (no description available) ii gnome-terminal2.10.0-3 The GNOME 2 terminal emulator appl ii indent2.2.9-7C language source code formatting ii libtool 1.5.22-1 Generic library support script ii make 3.80+3.81.b4-1 The GNU version of the make util ii yelp 2.10.0-3 Help browser for GNOME 2
Bug#296201: mount: unprivileged user can mount partition without updating mtab
Package: mount Version: 2.12p-2 Severity: grave Justification: user security hole If a non-root user mounts media (in my case, a CD-ROM), and attempts to kill the process (in my case, a mad combination of ^C and ^\), the filesystem can be mounted, yet not appear in /etc/mtab. This means that when the user does a df, it does not show up, and when they try to unmount it (unless they are root), they are denied, told that the filesystem is not mounted according to /etc/mtab. This introduces two security holes: 1) A malicious user could lock-up removable media for anybody else that wishes to use the system; or 2) A user is told that data is not available which actually is, which could mislead them into leaving it there for others to access. .. and, of course, in the case of cd-rom's which are usually locked while moutned, a user without root access or access to the person with root access can't get his/her CD rom back (without sticking a needle in the little hole, but we don't want them to do that, do we?) - Tyler -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.7-1-k7 Locale: LANG=en_CA, LC_CTYPE=en_CA (charmap=ISO-8859-1) Versions of packages mount depends on: ii libblkid1 1.36release-1 block device id library ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libuuid1 1.36release-1 universally unique id library -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
