Bug#997194: mtr: FTBFS: ../ui/curses.c:435:17: error: format not a string literal and no format arguments [-Werror=format-security]
On 10/24/21 4:36 AM, Rogier Wolff wrote: > > I think this is perfectly legal C code and your compiler doesn't like > it. It doesn't just warn, but gives an error. > > Roger. Rogier, that is a 100% true statement, but Debian (and most other distributions) have started using the -Werror=format-security build flag for everything everywhere because leaving all of these calls as-is means, in certain cases, leaving vulnerabilities in. Sure, you can prove that mtr's code introduces no such vulnerabilities because none of the format specs are user-supplied, but it's probably not reasonable to expect that that would be a one-time effort, whereas changing the code would be.
Bug#953829: regression/crash: mtr: Probes exhausted
On 3/17/20 4:02 AM, Marc Lehmann wrote: > On Sun, Mar 15, 2020 at 03:43:09PM -0700, Robert Woodcock > wrote: >> If you *do* need to differentiate, I would adjust the limit for the >> number of outstanding probes in packet/probe.h, and then recompile: >> >> #define MAX_PROBES 1024 >> >> However, that's not enough - I believe the intent of this limit is to >> match the default Linux limit of 1024 open files per process, which you >> will need to override in /etc/security/limits.conf to make effective use >> of the new limit in your copy of mtr. >> >> Probably the best long-term fix would be to automatically free the >> oldest probe when the newest one is requested, but I don't know how >> practical that would be. > Thanks a lot for this detailed analysis and tips. The strange thing, > though, is that this is clearly a regression, i.e. these limits (other > than the kernel limit) seem to either be new, or mtr silently handled this > in the past. > > Anyway, if that's going to be it, I'll simply have to adapt, and this > apparently works as designed and is not a bug. > MTR was pretty substantially redesigned about 3 years ago - the UI was separated from the backend (which has to have special privileges to open a raw socket - it used to need to be setuid, but now it uses setcap to provide only the RAW socket privilege needed). That redesign made it into the mtr 0.92 package in the current stable version of Debian - Buster - released in 2019. This was done for security reasons, to limit the possible attack surface for privilege escalation. I have not done a similar analysis on the older versions (0.87 and below) but I suspect that's what you were using before.
Bug#953829: regression/crash: mtr: Probes exhausted
This would be caused by the use of very low intervals, as you mentioned (causing ping probes to be consumed at a fast rate) in combination with lost packets at one or more remote hops (causing the probes to not be freed soon enough). 10 seconds at 100 probes per second does not leave sufficient margin for the default limit of 1024 probes. Assuming you don't need to differentiate a lost ping packet from a reply that was received much later than expected, use the -Z option to shorten the timeout so that the probes are freed up faster. The default is 10 seconds (defined in ui/mtr.c as ctl->probe_timeout). If you *do* need to differentiate, I would adjust the limit for the number of outstanding probes in packet/probe.h, and then recompile: #define MAX_PROBES 1024 However, that's not enough - I believe the intent of this limit is to match the default Linux limit of 1024 open files per process, which you will need to override in /etc/security/limits.conf to make effective use of the new limit in your copy of mtr. Probably the best long-term fix would be to automatically free the oldest probe when the newest one is requested, but I don't know how practical that would be. On 3/13/20 2:37 PM, Marc Lehmann wrote: > Package: mtr-tiny > Version: 0.92-2 > Severity: normal > > Dear Maintainer, > > recent versions of mtr started to crash seemingly randomly with the > following message: > >mtr: Probes exhausted > > and an exit status of 1. It's not consistently reproducible, but I found > that when specifying a low interval, e.g. > >mtr -i 0.01 target > > it happens much more often than with the default interval. > > This might not be new. However, I use mtr daily for many years, and also > with low intervals, and have never seen this message until recently, so I > assume this is new behaviour. > > -- System Information: > Debian Release: 10.3 > APT prefers stable > APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, > 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, > 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386, x32 > > Kernel: Linux 5.4.24-050424-generic (SMP w/8 CPU cores) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, > TAINT_UNSIGNED_MODULE > Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), > LANGUAGE=en_DK.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages mtr-tiny depends on: > ii libc62.28-10 > ii libncurses6 6.1+20181013-2+deb10u2 > ii libtinfo66.1+20181013-2+deb10u2 > > mtr-tiny recommends no packages. > > mtr-tiny suggests no packages. > > -- no debconf information
Bug#882331: mtr: source routing with --address does not work
On 11/23/2017 08:07 AM, Tom Hetmer wrote: > OK, and the results from 0.92? Good too? > Testing the last working version doesn't help much. :-) 0.92 behaves the same. *Neither* version does what you want. I wrote my email to show you that it's not a regression because it doesn't work the way you want in 0.87. It's not a bug either because the documentation doesn't claim that the -a option does what you're hoping it does. Any behavior to the contrary is something particular to your system. 0.92 uses bind() if you specify TCP or SCTP, otherwise it just uses socket() and sendto(). This is done in a separate process (mtr-packet) so you'd need to use strace's -f option to see it.
Bug#882331: mtr: source routing with --address does not work
You've got something else going on. I did a brand new install of Debian stable, created in a KVM VM using the following command: virt-install -n test --os-type=Linux --os-variant=debiansqueeze --ram=512 --vcpus=1 --disk path=test.img,bus=virtio,size=10 --graphics none --location http://ftp.us.debian.org/debian/dists/testing/main/installer-amd64/ --network bridge:br0 --network bridge:br1 --console pty,target_type=serial --extra-args 'console=ttyS0,115200n8 serial' I installed tcpdump and mtr (the 0.87 version from stable), and configured the two network interfaces with static IPs, with a default gateway on the first interface. root@test:~# mtr --version mtr 0.87 root@test:~# ip -4 addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: ens2: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 inet 192.168.9.29/24 brd 192.168.9.255 scope global ens2 valid_lft forever preferred_lft forever 3: ens3: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 inet 192.168.10.29/24 brd 192.168.10.255 scope global ens3 valid_lft forever preferred_lft forever root@test:~# ip route default via 192.168.9.1 dev ens2 onlink 192.168.9.0/24 dev ens2 proto kernel scope link src 192.168.9.29 192.168.10.0/24 dev ens3 proto kernel scope link src 192.168.10.29 I ran mtr in one window, using -a to specify the IP for ens3. In other windows, I ran tcpdump on ens2 and ens3: root@test:~# mtr -c 1 --report -a 192.168.10.29 1.2.3.4 Start: Thu Nov 23 07:51:36 2017 HOST: test Loss% Snt Last Avg Best Wrst StDev root@test:~# tcpdump -ni ens2 icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ens2, link-type EN10MB (Ethernet), capture size 262144 bytes 07:51:37.025564 IP 192.168.10.29 > 1.2.3.4: ICMP echo request, id 22275, seq 59520, length 44 07:51:37.126989 IP 192.168.10.29 > 1.2.3.4: ICMP echo request, id 22275, seq 59776, length 44 07:51:37.228430 IP 192.168.10.29 > 1.2.3.4: ICMP echo request, id 22275, seq 60032, length 44 07:51:37.328767 IP 192.168.10.29 > 1.2.3.4: ICMP echo request, id 22275, seq 60288, length 44 07:51:37.429117 IP 192.168.10.29 > 1.2.3.4: ICMP echo request, id 22275, seq 60544, length 44 07:51:37.529475 IP 192.168.10.29 > 1.2.3.4: ICMP echo request, id 22275, seq 60800, length 44 07:51:37.629855 IP 192.168.10.29 > 1.2.3.4: ICMP echo request, id 22275, seq 61056, length 44 root@test:~# tcpdump -ni ens3 icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes The packets egress via ens2 using the 192.168.10.29 IP. Bottom line: If you want to do this, you need to set up a separate routing table in Linux and you need to configure rules to use that routing table. This is not a regression in mtr.
Bug#882331: mtr: source routing with --address does not work
You're expecting too much of the -a option. It does not do source routing at all. When using "mtr -a", "ping -I", "traceroute -s", etc., the source IP address will change, but the destination route is still chosen by the system routing table. This is useful when the remote end treats the various IPs on your system differently (for example if it has a route to one interface's subnet but not to the other). This is not a regression - I've confirmed that 0.92 and 0.87 behave identically in this regard. To do what you want you'll need to either change the routing table or configure policy-based routing like so: # Create a new routing table with a default route towards [interface] ip route add table 10 default dev [interface] # Send all traffic with a particular IPTables MARK tag to this new routing table ip rule add from all fwmark 10 lookup 10 # Mark all local outbound traffic originating from this source IP so that it uses the new routing table iptables -t mangle -A OUTPUT -s [sourceip] -j MARK --set-mark 10 On 11/21/2017 07:06 AM, Tom Hetmer wrote: > Package: mtr > Version: 0.92-1 > Severity: normal > > Hi, > > there is a regression in 0.92. > Specifying an interface with --address is broken. > > -a, --address ADDRESS bind the outgoing socket to ADDRESS > > ie. > > mtr -4 --address 213.198.94.174 ic.cz > > will not get routed through the interface with the 213.198.94.174 > address but instead uses the default route on the system. > > This does not happen with mtr_0.87-1~bpo8+1_amd64.deb. > > > -- System Information: > Debian Release: 8.9 > APT prefers oldstable > APT policy: (800, 'oldstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: sysvinit (via /sbin/init) > > Versions of packages mtr depends on: > ii libc6 2.19-18+deb8u10 > ii libcap2 1:2.24-8 > ii libgdk-pixbuf2.0-0 2.31.1-2+deb8u6 > ii libglib2.0-02.42.1-1+b1 > ii libgtk2.0-0 2.24.25-3+deb8u2 > ii libncurses5 6.0+20170902-1 > ii libtinfo5 6.0+20170902-1 > > mtr recommends no packages. > > mtr suggests no packages. > > -- no debconf information
Bug#839879: mtr FTCBFS: uses build architecture tools
On 10/15/2017 01:18 PM, Robert Woodcock wrote: > On 10/15/2017 10:50 AM, Samuel Henrique wrote: >> Hello everyone, >> >> I've just applied an updated version of Helmut's patch on another >> branch[1] >> But as you can see (if you build that branch), we have a problem >> because the packages will be installed under usr/sbin instead of >> usr/bin. >> >> I believe this behavior is provided by >> "--sbindir=`pwd`/debian/tmp/usr/bin " and the old >> override_dh_installdirs-arch override (that is, before patching), but >> i still did not find a way of fixing this*, so anyone please feel >> free to submit the fix or point me to the right direction. >> >> I believe this is the only blocker right now for 0.92, as soon as we >> fix this, we will release the new version. >> >> * to simply pass "--sbindir=`pwd`/debian/tmp/usr/bin" on >> auto_configure didn't work, i'm still trying to understand what is >> happening, but my bet is that i need to work with >> override_dh_installdirs-arch. >> >> [1]https://anonscm.debian.org/git/collab-maint/mtr.git/commit/?h=debian/ftcbfs-helmut&id=c9e2825163d171e10ff7e1b74d17819a61c92ee6 >> >> >> >> -- >> Samuel Henrique > I'll take a stab at that in the next few days. > > Also, before we release - I'm not at all sold on the value of creating > a separate mtr-packet package - I'm pretty sure I want to put that > back, but we can discuss. It's only a few kb of disk savings on the > mirrors and it's disk wasted on an installed system. Currently we have > overlapping files between the mtr and mtr-packet packages and that > wouldn't even be a problem if we just folded mtr-packet in with the > mtr and mtr-tiny packages. At minimum, we need to get back to building > mtr twice rather than three times. > > I tracked down the /usr/sbin install paths to Makefile.am. Here's a patch: --- a/Makefile.am 2016-12-31 10:15:00.0 -0800 +++ b/Makefile.am 2017-10-16 15:11:09.0 -0700 @@ -5,7 +5,8 @@ img/mtr_icon.xpm $(TEST_FILES) -sbin_PROGRAMS = mtr mtr-packet +# We don't want these in /usr/sbin - rcw +bin_PROGRAMS = mtr mtr-packet TESTS = \ test/cmdparse.py \ test/param.py \ @@ -41,8 +42,8 @@ PATHFILES += man/mtr.8 man/mtr-packet.8 install-exec-hook: - `setcap cap_net_raw+ep $(DESTDIR)$(sbindir)/mtr-packet` \ - || chmod u+s $(DESTDIR)$(sbindir)/mtr-packet + `setcap cap_net_raw+ep $(DESTDIR)$(bindir)/mtr-packet` \ + || chmod u+s $(DESTDIR)$(bindir)/mtr-packet mtr_SOURCES = ui/mtr.c ui/mtr.h \ ui/net.c ui/net.h \
Bug#839879: mtr FTCBFS: uses build architecture tools
On 10/15/2017 10:50 AM, Samuel Henrique wrote: > Hello everyone, > > I've just applied an updated version of Helmut's patch on another > branch[1] > But as you can see (if you build that branch), we have a problem > because the packages will be installed under usr/sbin instead of usr/bin. > > I believe this behavior is provided by > "--sbindir=`pwd`/debian/tmp/usr/bin " and the old > override_dh_installdirs-arch override (that is, before patching), but > i still did not find a way of fixing this*, so anyone please feel free > to submit the fix or point me to the right direction. > > I believe this is the only blocker right now for 0.92, as soon as we > fix this, we will release the new version. > > * to simply pass "--sbindir=`pwd`/debian/tmp/usr/bin" on > auto_configure didn't work, i'm still trying to understand what is > happening, but my bet is that i need to work with > override_dh_installdirs-arch. > > [1]https://anonscm.debian.org/git/collab-maint/mtr.git/commit/?h=debian/ftcbfs-helmut&id=c9e2825163d171e10ff7e1b74d17819a61c92ee6 > > > > -- > Samuel Henrique I'll take a stab at that in the next few days. Also, before we release - I'm not at all sold on the value of creating a separate mtr-packet package - I'm pretty sure I want to put that back, but we can discuss. It's only a few kb of disk savings on the mirrors and it's disk wasted on an installed system. Currently we have overlapping files between the mtr and mtr-packet packages and that wouldn't even be a problem if we just folded mtr-packet in with the mtr and mtr-tiny packages. At minimum, we need to get back to building mtr twice rather than three times.
Bug#839879: mtr FTCBFS: uses build architecture tools
On 09/30/2017 07:37 AM, Rogier Wolff wrote: > On Sat, Sep 30, 2017 at 10:32:04AM +0200, Manuel A. Fernandez Montecelo wrote: >> 2017-09-30 3:39 GMT+02:00 Robert Woodcock : >>> On 09/28/2017 06:41 PM, Manuel A. Fernandez Montecelo wrote: >>> >>> Samuel and I are working on releasing 0.92 - I'll make sure that this is >>> in there. Thanks for the reminder. >> That's great, thanks! > Is there anything I can do upstream to make things easier for you? > > Roger. > > You're already aware of this one - we have a workaround for 0.92: https://github.com/traviscross/mtr/issues/198
Bug#839879: mtr FTCBFS: uses build architecture tools
On 09/28/2017 06:41 PM, Manuel A. Fernandez Montecelo wrote: > Hi, > > 2017-01-03 23:05 Samuel Henrique: >> Hi Robert, >> >> Did you have a look at this one? >> >> I'm in favor of using dh_auto_configure, just would like to check >> with you >> if i'm missing something (like a regression). > > IMO the patch proposed by Helmut is a good fix and improves the > packaging overall, not only for cross-compilation (if only by removing > lines). > > A year went by, and we're past the freeze again, so I think that it's a > good time to apply this. > > Would it help if I prepare an NMU, or sponsor a package prepared by > Samuel? > > > Cheers. Samuel and I are working on releasing 0.92 - I'll make sure that this is in there. Thanks for the reminder.
Bug#849699: [mtr] Please package v0.87
On 12/29/2016 02:21 PM, Samuel Henrique wrote: Source: mtr Version: 0.86-1 Severity: wishlist Tags: patch Hello, while having a general look for packages who might need updates for Stretch, i found out that mtr was outdated and decided to take a look at it. I have made several changes to the packaging while updating it to v0.87, you can see the package on mentors[1] and at collab-maint[2]. I would like to co-maintain mtr with you, but if you feel like not to, please feel free to use my changes without adding me as an uploader (note that the package on mentors and collab does that). Here's a short summary of the main changes i've made: * Bump DH level to 10. * Enable bindnow hardening flag. * Create a d/clean file to allow multiple builds. * Bump Standards-Version to 3.9.8. * Add a watch file. * Convert copyright to DEP-5. * Start using git for packaging. I belive updating to v.087 will also let Ubuntu sync with us again, as they've patched mtr to fix an upstream problem not present anymore on 0.87. There's also a considerable amount of bugs which i believe should be closed, they were marked as fixed but not closed. If you accept my help, i can do some bug triage :) [1]:https://mentors.debian.net/package/mtr [2]:https://anonscm.debian.org/git/collab-maint/mtr.git Samuel Henrique I've been meaning to get 0.87 uploaded for a while now. I'll look over your changes this weekend and include them. I'm OK with you being co-maintainer.
Bug#772587: mtr -4 does nothing
On 12/08/2014 12:12 PM, shirish शिरीष wrote: Package: mtr Version: 0.85-3 Severity: normal Dear Maintainer, I tried using mtr and came up empty. It says and I quote "Unable to allocate IPv6 socket for nameserver communication: Address family not supported by protocol" You need a kernel that has IPv6 support (even if you don't have it configured) to use mtr.This is likely the same as bug #721792. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725222: mtr invoked by command line does nothing
On 10/02/2013 06:27 PM, Rogério Brito wrote: I have tried to use mtr on this i386-userland with amd64-kernel installation and, when I fire up mtr via the command line on an X session (don't know if this would be the case under other circumstances, which is why I have filed this as important, not as grave) I get no output, no window and mtr simply returns to the prompt. I tried it under both a regular user account and as root, and nothing changes. I am using a standard Debian kernel (read: "as vanilla as possible"). Furthermore, when I run mtr under strace, these are the last lines that I get: ,[ strace mtr ] | (...) | mprotect(0xf777f000, 4096, PROT_READ) = 0 | munmap(0xf7742000, 107301) = 0 | socket(PF_INET, SOCK_RAW, IPPROTO_RAW) = -1 EPERM (Operation not permitted) | write(2, "mtr: unable to get raw sockets.\n", 32mtr: unable to get raw sockets. | ) = 32 | exit_group(1) = ? ` Also, I just tried installing mtr-tiny and I get the same results with EPERM. Note that when you run "strace mtr", you are no longer running mtr as root, as Linux does not honor the setuid bit for ptrace'd processes. Therefore it cannot open the raw socket it needs to create packets. From strace(1): -u username Run command with the user ID, group ID, and supple‐ mentary groups of username. This option is only useful when running as root and enables the correct execution of setuid and/or setgid binaries. Unless this option is used setuid and setgid programs are executed without effective privileges. 'sudo strace mtr' would work around this. You didn't say if you ran any tests other than strace with the mtr-tiny package, but you would probably want to try running 'mtr --curses' to eliminate possible X misconfiguration problems. You may also want to check the $DISPLAY environment variable. -- Robert Woodcock - r...@debian.org perl -e '$a-=($_%4-2)*4/$_++while++$_<2e6;print"$a\n"' -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#662583: mtr: diff for NMU version 0.82-2.1
On 04/03/2012 12:37 PM, Raúl Benencia wrote: tags 662583 + patch tags 662583 + pending thanks Dear maintainer, I've prepared an NMU for mtr (versioned as 0.82-2.1). I's just a patched version of what Rogier Wolff said[0]. Regards. [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662583#10 Thanks! I'll get this tested and uploaded later this weekend. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#654117: Please enabled hardened build flags
On 01/01/2012 11:30 PM, Rogier Wolff wrote: Hi, I don't have a debian/rules in my "upstream" distribution. Should I grab a copy somewhere and start distributing it? Nah. This flag-adding mechanism is a debian-specific build thing. However, the hardening flags that it adds are not debian-specific and you might want to look over the list of them and see if you want to include any. On my amd64 system they are currently: CFLAGS="-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security" CPPFLAGS="-D_FORTIFY_SOURCE=2" CXXFLAGS="-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security" FFLAGS="-g -O2" LDFLAGS="-Wl,-z,relro" For reference, the debian/ folder (and any patches to your source that Debian adds - there currently aren't any since you've integrated all of them) are in the .diff.gz patch that Debian distributes along with the .orig.tar.gz source. Moritz: What's the best method (if you're aware of one) to allow a package to still build on debian stable after these changes? As far as I can tell, --export=configure isn't in stable's dpkg-buildflags, /usr/share/dpkg/buildflags.mk isn't in stable, debhelper compat level 9 isn't in stable, etc. -- Robert Woodcock - r...@debian.org "We've worked with our purchasing team to bring in many companies to compete on our main cabin tidbit item (pretzels). To date, no one has been able to match our current cost, about 3 cents per package." -- US Airways management -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#608924: mtr --curses doesn't show received pkts(--gtk does)
On Tue, 2011-01-04 at 10:47 -0600, Adam Heath wrote: > package: mtr > version: 0.80-1,0.75-2 > severity: minor > > mtr in --curses mode does not show the number of packets received; > --gtk does. It does allow this; it's just not the default. You can press o and then type in "R" somewhere in the field list to add it, and you can also specify this through the -o or --order command line switch (which you could always add via a shell alias). It does make the display a bit more cramped on an 80-column terminal, which is why I suspect it's not the default. -- Robert Woodcock - r...@debian.org "Everything has been thought of before. The trick is to think of it again." -- Johann Wolfgang von Goethe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#499789: FTBFS: clean target fails: rm: cannot remove `mtr': No such file or directory
On Mon, Sep 22, 2008 at 01:29:48PM +0200, Christoph Berg wrote: > rm -f build-stamp > rm -r mtr mtr-tiny > rm: cannot remove `mtr': No such file or directory > rm: cannot remove `mtr-tiny': No such file or directory > make: *** [clean] Error 1 > dpkg-buildpackage: failure: fakeroot debian/rules clean gave error exit > status 2 I did remove some hyphens from the start of those make commands in 0.75-1, after lintian pointed them out to me. Unfortunately in my testing there was always something for debian/rules clean to delete. I'll upload a 0.75-2 to use rm -f where necessary. Maybe that'll give me a shot at #50. :) -- Robert Woodcock - [EMAIL PROTECTED] "Patience is a minor form of despair, disguised as virtue." -- Ambrose Bierce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457638: confused by router that always responds as the destination host
On Wed, Jan 02, 2008 at 04:01:18PM +0100, Rogier Wolff wrote: > How traceroute decides that it reaches the destination I don't > remember. Traceroute however takes ages: It sends out one packet, > waits for the result or times out, and then tries the next hop. > (after trying the same hop 3 times). Dunno about all versions of traceroute, but at least a couple of them send out packets to the first hop to a high UDP port number, then the next hop to that port number + 1, then the third hop to port number + 2, etc. ICMP doesn't have port numbers, but you can tuck freeform data into the echo request packet, which in theory makes it back in the reply. For most routers. I think. -- Robert Woodcock - [EMAIL PROTECTED] "We would like to return to work with our writers. If we cannot, we would like to express our ambivalence, but without our writers we are unable to express something as nuanced as ambivalence." -- Jon Stewart and Stephen Colbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457638: confused by router that always responds as the destination host
On Mon, Dec 24, 2007 at 10:07:47AM -0500, Joey Hess wrote: > ICMP (-I) works, TCP SYN (-T) doesn't. > > (That's probably the last time I'll be able to use this network.) Well shoot. If it's not too late to run 'tcpdump -n -s 1500 -w dumpfile' while you do the tests, then do those (one for mtr and one for traceroute -I) and email them to me - otherwise, we'll probably have to wait for someone else to say "hey this happens to me too!" -- Robert Woodcock - [EMAIL PROTECTED] "We've worked with our purchasing team to bring in many companies to compete on our main cabin tidbit item (pretzels). To date, no one has been able to match our current cost, about 3 cents per package." -- US Airways management -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457638: confused by router that always responds as the destination host
On Sun, Dec 23, 2007 at 09:36:32PM -0500, Joey Hess wrote: > I think mtr must optimise away the rest, which seems like a sort of bug in > this situation. It's important to note that mtr, by design, sends out ICMP packets, and traceroute, by default, sends out UDP packets. I suspect if you use the traceroute packages' traceroute command with the -I switch on a host behind such a router, you'll get identical results. If packets sent out with a TTL of, say, 30, come back with a TTL exceeded message from the same host as packets with a TTL of 1, there is no software method of determining the existence of the other hops. So I think this is a case of garbage in, garbage out. Let me know what you get. -- Robert Woodcock - [EMAIL PROTECTED] "We would like to return to work with our writers. If we cannot, we would like to express our ambivalence, but without our writers we are unable to express something as nuanced as ambivalence." -- Jon Stewart and Stephen Colbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#441342: [Nut-upsdev] Bug#441342: Nut can kill power to UPSs that never went on battery
o down (ie, the power is out and the batteries of the UPS feeding it), > would be a sure fire way to crash them. I would rather take the slight risk of data corruption than shut down systems when there is no evidence that a shutdown is needed. In a perfect world, all services would automatically come back up with full functionality after a mass reboot. In the real world, I have managed several server rooms, each with a few dozen systems, and despite our best efforts, none have had a startup procedure less than 10 bullet points long. > >> Or, at the very least, document the hidden assumption that none of your > >> monitored UPS's runtimes will exceed that of your master server's UPS > >> runtime in particular. > > This is documented in the 'upsmon' man page for instance: > > > FORCED SHUTDOWNS > > > > When upsmon is forced to bring down the local system, it sets the > > "FSD" (forced shutdown) flag on any UPSes that it is running in master > > mode. This is used to synchronize slaves in the event that a master UPS > > that is otherwise OK needs to be brought down due to some pressing event > > on the master. This is the most euphemistic paragraph I have read in months. Consider replacing the word 'synchronize'. -- Robert Woodcock - [EMAIL PROTECTED] "When failure is not an option, success can get expensive." -- Peter Stibrany -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#441342: Nut can kill power to UPSs that never went on battery
Package: nut
Version: 2.2.0-2
Severity: important
I recently set up nut at work to monitor the 15 APC Smart-UPS 1500s we have
in our server room. Since we currently only have one Linux system, all 15
UPSs are connected via USB hubs to it.
Over the last couple months, we have had a couple incidents (luckily all on
weekends) where all 15 UPSs will mysteriously shut off, and we had to
manually power them back up. To top it off, there was nothing in syslog
about any UPS going onto battery power and staying there - just a couple
curious low-battery warnings from one of the UPSs.
This weekend, we tested the UPSs and found that - just our luck - the one
in particular that fed the Linux system would immediately report low battery
if you put it in test mode (which it does every two weeks on its own). Nut
would then immediately shut down the Linux system, and once that was done,
it would proceed to force a shutdown of all the other UPSs.
The smoking gun is in upsmon's forceshutdown():
/* set FSD on any "master" UPS entries (forced shutdown in progress) */
for (ups = firstups; ups != NULL; ups = ups->next)
if (flag_isset(ups->status, ST_MASTER)) {
isamaster = 1;
setfsd(ups);
}
This code does not attempt to determine whether the UPS in question needs to
be shut down or not. Shutting down a UPS that is online with a full charge
is a grievous offense.
To avoid race conditions, I think the proper thing to do is to maintain some
state information for each UPS as to whether any client is initiating
shutdown, i.e. has been notified of:
* an on battery condition but then the client disconnected and is therefore
unable to receive news that the UPS is back online
* an on battery condition but the master server must disconnect soon
* a low battery or force shutdown condition
If none of these apply, then don't force shutdown the UPS. No good can come
of it.
A simpler mechanism which could potentially have a race condition, is don't
shut off any UPS that is online.
Or, at the very least, document the hidden assumption that none of your
monitored UPS's runtimes will exceed that of your master server's UPS
runtime in particular.
Thanks!
--
Robert Woodcock - [EMAIL PROTECTED]
"When you can measure what you are speaking about, and express it in numbers,
you know something about it; but when you cannot measure it, when you cannot
express it in numbers, your knowledge is of a meager and unsatisfactory
kind: it may be the beginning of knowledge, but you have scarcely, in your
thoughts, advanced to the stage of science."
-- William Thomson, Lord Kelvin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#418791: your mail
On Tue, Jun 19, 2007 at 12:19:48PM +0200, Michael Meskes wrote: > Hi, > > I don't really like RFAs send by third parties but given that you didn't > answer so far I take it this is serious. I will try to look into the > package a bit while here at DebConf. Yeah, you can take it. Thanks. -- Robert Woodcock - [EMAIL PROTECTED] "I always make it a point to tell people that 'Halon' is French for 'Exit,' so if they ever get locked in the data center, they know how to get out." -- seen on slashdot -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#423681: security: keeps sockets open when paused
On Sun, May 13, 2007 at 11:17:20PM +0200, Tomas Pospisek wrote: > Package: mtr > Version: 0.71-2 > Severity: normal > > When mtr is paused, "netstat -a -p" tells me: > > Proto/Recv-Q/Send-Q/Local Address/Foreign Address/State/PID/Program name > udp0 0 *:33370 *:* 12415/mtr > raw0 0 *:icmp*:* 7 12415/mtr > raw0 0 *:255 *:* 7 12415/mtr > > This does not feel good. > > Allthough mtr is "suspended", a potential "attacker" can find out that mtr is > up on the host. This has security implications. Under what circumstances would they be able to check this using this method and also not be able to check this using, say, 'ps'? Please elaborate on the security implications you are referring to. > I have not checked whether mtr acctually processes anything that is sent > to it during this "paused" period. My reading of select.c is that it calls net_process_return regardless of whether it is paused or not. If it didn't, you'd occasionally see false packet loss when pausing and unpausing, at least if there was any appreciable latency between hosts. If it closed the socket, it wouldn't be able to reopen it when you unpaused mtr - mtr would have already dropped the privileges it needed to do that. > Btw - has #156378 "mtr busy-waits when paused" been closed? It seems to > be open (reportbug shows it, but bugs.debian.org/156378 doesn't). No, it hasn't yet. -- Robert Woodcock - [EMAIL PROTECTED] "I always make it a point to tell people that 'Halon' is French for 'Exit,' so if they ever get locked in the data center, they know how to get out." -- seen on slashdot -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#416567: mtr-tiny: Should not have priority standard
On Wed, Mar 28, 2007 at 05:36:29PM -0700, Josh Triplett wrote: > Package: mtr-tiny > Severity: normal > > traceroute and ping make sense to have by default, but why install one random > ncurses traceroute tool? Anyone who uses mtr could easily install it for > themselves. Please don't make this priority standard. In Bug #416576, Frans suggested discussing these package priorities on debian-devel. I haven't seen that. I don't particularly care about the outcome of the discussion (and have no real control over the package's priority anyway - the Priority field in the Packages files is controlled by the ftpmasters' overrides files) but IMHO it's a decision that needs rough concensus. -- Robert "let's remove TeX and Emacs from standard" Woodcock - [EMAIL PROTECTED] "If your child is presumed by law enforcement authorities to have been kidnapped by someone who is not a family member, you may be able to take the child into account in determining your eligibility for head of household or qualifying widow(er) filing status, the deduction for dependents, child tax credit, and the earned income credit (EIC)." -- IRS 2006 1040 instructions booklet page 21 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412777: netdiag: diff for NMU version 0.7-7.2
On Thu, Mar 01, 2007 at 06:54:11AM -0800, Robert Woodcock wrote: > Thanks for the NMU - I'll try get a -8 out soon - netload can't be that > difficult to modify for kernel 2.6's /proc/net/dev format. Looks like the only change needed was to stop trying to fseek() /proc/net/dev - that worked in 2.4.x but not 2.6.x. Now it just reads until the buffer is full or (more likely) EOF. I've uploaded -8. -- Robert Woodcock - [EMAIL PROTECTED] "You can't believe [Jose] Padilla when he says we tortured him because he's crazy from all the things we did to him." -- Jack Balkin, Yale Law School -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412777: netdiag: diff for NMU version 0.7-7.2
On Tue, Feb 27, 2007 at 09:23:55PM -0500, Joey Hess wrote: > Attached is the diff for my netdiag 0.7-7.2 NMU. > > Is this package still being maintained? It's been a slightly while since > it was uploaded, though I do see you responding to a few bugs in the > BTS. Sorry, I haven't had much time to work on it. I'd happily give it to anyone who wants to take it over. I think most of the utilities in the package have been obsoleted, and I rarely use them. Thanks for the NMU - I'll try get a -8 out soon - netload can't be that difficult to modify for kernel 2.6's /proc/net/dev format. -- Robert Woodcock - [EMAIL PROTECTED] "Most truths are so naked that people feel sorry for them and cover them up, at least a little bit." -- Edward R. Murrow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#384926: mtr: Broken IPv6 reverse lookup
On Tue, Jan 02, 2007 at 01:19:29AM +0100, Bernhard Schmidt wrote: > Too bad, any way to get around this? This bugfix doesn't meet the guidelines specified by the release manager here: http://lists.debian.org/debian-devel-announce/2006/12/msg4.html -- Robert Woodcock - [EMAIL PROTECTED] "The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying." -- John Carmack -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#384926: mtr: Broken IPv6 reverse lookup
On Mon, Jan 01, 2007 at 10:06:55PM +0100, Bernhard Schmidt wrote:
> Hi,
>
> Version 0.72 is out since Sep 29th and has this bug fixed, would be
> great if someone could update the package.
I can't update it for etch, unfortunately, as that's already frozen. I'm
preparing an update for experimental.
It looks like the only DNS-related change is:
--- mtr-0.71/dns.c 2006-03-22 21:45:58.0 -0800
+++ mtr-0.72/dns.c 2006-03-25 22:54:11.0 -0800
@@ -1357,7 +1357,7 @@
#ifdef ENABLE_IPV6
/* Returns an ip6.arpa character string. */
void addr2ip6arpa( ip_t * ip, char * buf ) {
- char * p = (char *) ip;
+ unsigned char * p = (unsigned char *) ip;
Now, I don't have an IPv6 internetwork to really test this with, but mtr
0.71 does properly reverse lookup ::1 on my system. I'm guessing the move to
an unsigned cast is to deal with hostnames with 8-bit characters. Is that
what you're seeing break with 0.71?
--
Robert Woodcock - [EMAIL PROTECTED]
"You can't believe [Jose] Padilla when he says we tortured him because he's
crazy from all the things we did to him."
-- Jack Balkin, Yale Law School
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#23183: netload: completely outdated
On Thu, Dec 21, 2006 at 08:46:04PM +0100, R??mi Denis-Courmont wrote: > retitle 23183 netload: unusable with kernel 2.1+ > severity 23183 important > thanks > > netload simply does not work at all with any 2.1+ kernel. Worst yet, it > fails silently with no error messages whatsoever. Please fix it or > remove it from the package. In my testing, it works on 2.4.x, but silently fails to parse /proc/net/dev on kernel 2.6.x, and it looks like there are no updated versions available. -- Robert Woodcock - [EMAIL PROTECTED] "Most truths are so naked that people feel sorry for them and cover them up, at least a little bit." -- Edward R. Murrow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#400358: netdiag: Segfaults and leaves port in promiscuous mode
On Sat, Nov 25, 2006 at 07:40:20PM -0800, David Liontooth wrote: > It's good to see you're still here! I'd like the functionality of the > programs, but in their current shape they consistently crash and leave > your machine vulnerable. Anyway, the decision is yours. Do they leave your machine any more vulnerable than if you had left one of the tools (or tcpdump, or ethereal/wireshark, or ngrep, etc) running for an extended period of time? If so, please state how. If not, I plan to lower this bug's severity and merge it with the existing bugs. -- Robert Woodcock - [EMAIL PROTECTED] "I say to you that the VCR is to the American film producer and the American public as the Boston strangler is to the woman home alone." -- Jack Valenti, President and CEO of the MPAA, to the House of Representatives Judiciary Committee, 1982 "I wasn't opposed to the VCR." -- Jack Valenti, 2003, clarifying his earlier quote -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#400358: netdiag: Segfaults and leaves port in promiscuous mode
On Sat, Nov 25, 2006 at 09:17:54AM -0800, David Liontooth wrote: > Package: netdiag > Version: 0.7-7.1 > Severity: grave > Tags: security > Justification: user security hole > > > Several of the applications in this package now routinely segfault and > leave the port in promiscuous mode with no warning. The problem was first > reported nearly ten years ago (7794 and 12306) and no action has been > taken. > > Judging from the Changelog, the maintainer has been awol for three years; > the package should probably be orphaned. Just about all of the programs in netdiag have been abandoned upstream. You are welcome to submit patches or offer to take over maintenance of one of the programs. Personally I'm tempted to ask ftp-master to remove it from Debian. FWIW, I disagree with this bug's severity. -- Robert Woodcock - [EMAIL PROTECTED] perl -e '$a-=($_%4-2)*4/$_++while++$_<2e6;print"$a\n"' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#384335: Open bugreport for libid3-3.8.3c2a
On Wed, Nov 08, 2006 at 11:46:44PM +0100, Christoph Burgmer wrote: > Hi, > > there is a bug report open for one year with patch waiting to be applied to > libid3-3.8.3c2a. Do you still maintain this package and is there any interest > in fixing this issue? The main issue is that id3lib isn't maintained upstream. Every code change I make is basically forking it a little more, making things incompatible with other distributions, and I'm hesitant to do that. The other large issue is that I don't have the time or knowledge to do upstream maintenance, which is what the package has needed. You can have it if you want, otherwise I'll see if I can do an upload with that patch this weekend. Out of curiosity did you test it? -- Robert Woodcock - [EMAIL PROTECTED] "I say to you that the VCR is to the American film producer and the American public as the Boston strangler is to the woman home alone." -- Jack Valenti, President and CEO of the MPAA, to the House of Representatives Judiciary Committee, 1982 "I wasn't opposed to the VCR." -- Jack Valenti, 2003, clarifying his earlier quote -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#384444: mtr in sarge eats 100% cpu with -n
On Thu, Aug 24, 2006 at 11:11:30AM +0200, Peter Palfrader wrote: > mtr in sarge eats 100% CPU when called with -n (don't resolve IP > addresses to hostnames). It turns out there is a small bug in > select.c's select_loop() that causes select to always be called with a > timeout of 0. > > Is this something that should and could be fixed for the next stable > point release? Quoting from http://release.debian.org/stable/3.1/3.1r2/: The regulations for updates to the stable Debian release are quite conservative. The requirements for packages to get updated in stable are: 1. The package fixes a security problem. An advisory by our own Security Team is required. Updates need to be approved by the Security Team. 2. The package fixes a critical bug which can lead to data loss, data corruption, or an overly broken system, or the package is broken or not usable (anymore). 3. The stable version of the package is not installable at all due to broken or unmet dependencies or broken installation scripts. 4. All released architectures have to be in sync. 5. The package gets all released architectures back in sync. It is (or (and (or 1 2 3) 4) 5) Regular bugs and upgrade problems don't get fixed in new revisions for the stable distribution. They should instead be documented in the Release Notes which are maintained by Rob Bradford <mailto:[EMAIL PROTECTED]> and are found at http://www.debian.org/releases/sarge/releasenotes Would you prefer the security advisory approach or the release notes approach? -- Robert Woodcock - [EMAIL PROTECTED] "That's nice, honey. Can you pick up some milk on your way home?" -- Diane Brown to Mike Brown, upon hearing that 2003 UB313, an object Mike discovered, is bigger than Pluto -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#381993: netdiag: ancient version of trafshow
On Tue, Aug 08, 2006 at 09:32:23AM +0200, Christoph Martin wrote: > The version of trafshow (1.3) is really ancient (from 1997). The > current version is 5.2.3. > > Please update the netdiag package or remove trafshow from netdiag to > give the possibility to package it separately. I just submitted a ITP > for a trafshow package (381888). There are two totally different trafshows out there. I have not looked at the other one in about a year, but it was markedly inferior to the version in Debian at the time (and was also abandonware). I'll have to evaluate 5.2.3, and yes, I've been meaning to split the netdiag package. -- Robert Woodcock - [EMAIL PROTECTED] "Everything has been thought of before. The trick is to think of it again." -- Johann Wolfgang von Goethe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#377308: libid3-3.8.3: Where did the utilities in original upstream pkg vanished?
On Sat, Jul 08, 2006 at 09:51:48AM +0300, Jari Aalto wrote: > The upstream package for libid3-3.8.3 contains many utilities: > > -rwxr-xr-x 1 root root 4622 2006-07-06 18:16 id3convert > -rwxr-xr-x 1 root root 4596 2006-07-06 18:16 id3cp > -rwxr-xr-x 1 root root 4604 2006-07-06 18:16 id3info > -rwxr-xr-x 1 root root 4598 2006-07-06 18:16 id3tag They are in libid3-3.8.3-dev. They've been in the -dev package for at least the last four years (since libid3 3.8.0). > The debian/changelog does not mention what happened then and the last > recorded in debian/changelog reads: > > id3lib (3.7.13-5) unstable; urgency=low > > * Fixed typo in id3tag manpage You're probably looking at the wrong changelog - the "id3lib" package is obsolete. > SUGGESTION > > Please add a paragraph to debian/README.DEbian to explain the differences > to the upstream source package and explain in which package the utlilities > are now part of. Don't most Debian users just search using the Contents file or http://packages.debian.org to find which package contains a binary? I think I'll add the utility names to the -dev package's description, though, so that 'apt-cache search' finds it too. -- Robert Woodcock - [EMAIL PROTECTED] "Everything has been thought of before. The trick is to think of it again." -- Johann Wolfgang von Goethe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#375238: -l always converts (or tries) tags to latin1, even though my locale is utf-8
On Sat, Jun 24, 2006 at 12:09:34PM -0400, Anthony DeRobertis wrote: > Package: id3v2 > Version: 0.1.11-3 > Severity: normal > File: /usr/bin/id3v2 > > On a test file: > > $ id3v2 -l J??\ -\ #nipponsei\ @\ irc.rizon.net\,\ di??il.mp3 | > grep TIT2 | xxd > 000: 5449 5432 2028 5469 746c 652f 736f 6e67 TIT2 (Title/song > 010: 6e61 6d65 2f63 6f6e 7465 6e74 2064 6573 name/content des > 020: 6372 6970 7469 6f6e 293a 2064 69df 696c cription): di.il > 030: dfec f3f1 0a . > > The tag in the MP3 file is UTF-8: > > 0b0: 697a 6f6e 2e6e 6574 5449 5432 000f izon.netTIT2 > 0c0: 0364 69c3 9f69 6cc3 9fc3 acc3 b3c3 ...di..il... > 0d0: b154 4954 3300 0100 0003 544f 5045 .TIT3...TOPE > > And my system uses UTF-8: > > $ locale | grep LC_CTYPE > LC_CTYPE="en_US.UTF-8" I am a character encoding newbie - you likely know more than me about the subject. With that said: * The ID3v2 2.3.0 standard is not the latest but it happens to be what id3lib (which id3v2 uses) implements. (The latest is 2.4.0). * The ID3v2 2.3.0 standard only supports ISO-8859-1 and UCS-2. 2.4.0 did add support for UTF-16BE and UTF-8. * I'll have to check whether it's id3v2 or id3lib that lacks support for UCS-2, or whether it does support it but chooses the wrong encoding to convert to. -- Robert Woodcock - [EMAIL PROTECTED] "Everything has been thought of before. The trick is to think of it again." -- Johann Wolfgang von Goethe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#365845: FTBFS: requires automake-1.7
On Mon, May 15, 2006 at 11:41:27AM +0200, Florian Ernst wrote: > On Sun, May 14, 2006 at 10:00:40AM -0700, Robert Woodcock wrote: > > Note to Florian: those are only "patches" from your perspective. All of > > those files are automatically generated by autoreconf/aclocal/autoconf/ > > automake/etc. None of them are written by hand [...] > > Please note that "patch" doesn't necessarily has a connotation on how > it was generated, just see the Jargon File entry (sense 3). Your > "lecture" indicates otherwise ... My apologies if you felt lectured to. Your original email *did* have those connotations - "Methinks this FTBFS occurs due to unnecessarily applying the 0.70-1 patches..." - and that's all I was responding to. -- Robert Woodcock - [EMAIL PROTECTED] "NSA's budget for electricity exceeds US$21 million per year, making it the second largest electricity consumer in the entire state of Maryland." -- Wikipedia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#365845: FTBFS: requires automake-1.7
On Sat, May 13, 2006 at 01:23:44PM +0200, Florian Ernst wrote: > On Wed, May 03, 2006 at 12:59:14PM +0200, Roberto Pariset wrote: > > mtr_0.71-1 FTBFS with error: > > [...] > > Which make it quite clear it needs automake-1.7. Please add it as a > > dependency. > > Methinks this FTBFS occurs due to unnecessarily applying the 0.70-1 > patches to img/Makefile.in, Makefile.in, aclocal.m4 and configure to > 0.71 as well. Apparently upstream took care, so those simply aren't > needed anymore. > When dropping these patches as well as the "touch"ing in debian/rules > the package builds just fine (tested on i386, amd64, ia64 and s390). > > Please find attached the corresponding interdiff. If I won't hear from > you I'll probably NMU on Monday. Sorry for the delay on this. I've just uploaded -2. I didn't have a whole lot of spare time last week and pbuilder wasn't cooperating. I don't want to: * Use upstream autotools (v1.4!) * Depend on automake I do want to: * Be able to change autotools-related things in my source package * Respond to (or just plain avoid) FTBFS bugs about out-of-date stuff * Conform to /usr/share/doc/autotools-dev/README.Debian.gz It looks like I was able to achieve these goals by running: autoreconf --force --install On the source tree before building. Note to Florian: those are only "patches" from your perspective. All of those files are automatically generated by autoreconf/aclocal/autoconf/ automake/etc. None of them are written by hand (or *shudder* merged into new version source trees). -- Robert Woodcock - [EMAIL PROTECTED] "Everything has been thought of before. The trick is to think of it again." -- Johann Wolfgang von Goethe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#356473: id3v2: does not print no id3 tag although tag is missing
On Sun, Mar 12, 2006 at 11:20:56AM +0100, Norbert Schmitz wrote: > I'm adding a patch for this problem and additional output messages for > id3v1 and id3v2. Could I get you to regenerate this patch using diff -u against the list.cpp in 0.1.11-3? frantica:~/src/id3v2-0.1.11$ patch < list.cpp.patch can't find file to patch at input line 1 Perhaps you should have used the -p or --strip option? File to patch: list.cpp patching file list.cpp Hunk #1 succeeded at 298 (offset -65 lines). Hunk #2 FAILED at 305. Hunk #3 succeeded at 313 (offset -65 lines). Hunk #4 succeeded at 315 (offset -65 lines). Hunk #5 FAILED at 317. Hunk #6 FAILED at 322. Hunk #7 FAILED at 325. 4 out of 7 hunks FAILED -- saving rejects to file list.cpp.rej -- Robert Woodcock - [EMAIL PROTECTED] "Everything has been thought of before. The trick is to think of it again." -- Johann Wolfgang von Goethe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#339186: library package needs to be renamed (libstdc++ allocator change)
On Tue, Nov 15, 2005 at 07:55:58AM +0100, Matthias Klose wrote: > Package: id3lib3.8.3 > Severity: important > > Please do not take any action before reading > http://lists.debian.org/debian-devel-announce/2005/11/msg00010.html > > This bug report is filed against the source package which builds > a library depending on libstdc++6 and defining or referencing > *mt_alloc* symbols. The package has to be rebuilt with either > g++-4.0_4.0.2-4 or g++-3.4_3.4.4-10 (or newer). Please rename the > library package to a name with a "c2a" suffix, and adjust the build > dependencies if dependencies on another renamed library do exist. Can my libid3-3.8.3c2a package include a 'Provides: libid3-3.8.3c2', or do I need to let the people who use my library know they need to rebuild as well? -- Robert Woodcock - [EMAIL PROTECTED] "Learn more about paranoids - follow them around." -- seen on slashdot -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#329745: mtr-tiny: Contradictory output when there is a failure in name resolution
On Sun, Oct 02, 2005 at 01:32:48AM -0300, Nelson A. de Oliveira wrote:
> On 9/27/05, Rogier Wolff <[EMAIL PROTECTED]> wrote:
> > Yes, somehow, it calls a function that fails, but the "errno" variable
> > indicates no specification as to what system call when wrong or why: The
> > system calls all worked, just the name server told "can't resolve this".
> >
> > I agree it's confusing. I'm not familiar with the code that
> > generates that message.
>
> Maybe forward this to upstream and change severity to wishlist?
Well, you already have an answer from Rogier, who *is* upstream.
The weird thing is, *neither* the "Temporary failure in name resolution"
string nor the "Success" string appear anywhere in mtr source. Just about
all of the DNS code returns responses that start with "Resolver:" or
"Resolver error:" So it's a bit difficult to figure out exactly what sort of
DNS response causes that message to appear (and therefore, what code path is
being taken within mtr).
One exception to that is this chunk in mtr.c line 392ish:
#ifdef ENABLE_IPV6
/* gethostbyname2() is deprecated so we'll use getaddrinfo() instead. */
bzero( &hints, sizeof hints );
hints.ai_family = af;
hints.ai_socktype = SOCK_DGRAM;
error = getaddrinfo( Hostname, "0", &hints, &res );
if ( error ) {
perror( gai_strerror(error) );
exit( EXIT_FAILURE );
}
I'm not sure that gai_strerror should be wrapped in perror like that - it
could be that getaddrinfo does not set errno, or it could also be that
gai_strerror resets errno. I think that a safer thing to do would be to
check if error == EAI_SYSTEM. If so, use the output from perror. If not, use
the output from gai_strerror. But never use the output from both.
To get to the bottom of it we'd need to be able to replicate the bug. Would
you be able to tell us how to configure a DNS server to be broken like yours
was?
--
Robert Woodcock - [EMAIL PROTECTED]
"By metaphorically, I mean get in the car."
-- Bender
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#281292: - libid3-3.8.3: Missing function in C wrapper
On Wed, Sep 14, 2005 at 11:17:40PM +0200, J?r?me COUDERC wrote: > Hi Robert, > >As in the next version of EasyTAG, I will include the patch from > Javier to enable/fix UTF-16 reading with C wrapper, I wanted to know if > you intend to apply to patch "id3lib+c_wrapper_encoding.diff" > <http://bugs.debian.org/cgi-bin/bugreport.cgi/id3lib%252Bc_wrapper_encoding.diff?bug=281292;msg=15;att=1> > > supplied by Javier? *IF* there is a general concensus that this patch as it exists will be accepted into id3lib upstream. I am not interested in maintaining and porting debian-specific things to new versions. If you are, then we can certainly talk about that. > This patch couldn't "break" the library as it adds only some C wrappers. > So there is no risk. > Moreover it will be necessary to allow compilation of future EasyTAG > versions... Let me get this straight. EasyTAG will expect users of other distributions (or people who wish to compile it themselves) to compile id3lib themselves, with their patch, to be able to compile and use EasyTAG? -- Robert Woodcock - [EMAIL PROTECTED] perl -e '$a-=($_%4-2)*4/$_++while++$_<2e6;print"$a\n"' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#254089: What's up with mtr @ amd64?
On Mon, Aug 15, 2005 at 11:40:47PM +0200, Christian Hammers wrote: > Hello Robert > > What are your plans for mtr on amd64? It's still broken although the patch > in the BTS is simple (as long as you only have to patch it for Debian and > not for the upstream at least). I'm waiting for Rogier to bless one of the patches. He doesn't want to put out a release that might break other systems. -- Robert Woodcock - [EMAIL PROTECTED] perl -e '$a-=($_%4-2)*4/$_++while++$_<2e6;print"$a\n"' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319662: id3v2: please recompile against libid3-3.8.3c2
On Tue, Aug 02, 2005 at 01:09:22PM +0200, Adeodato Sim?? wrote: > * Adeodato Sim?? [Sat, 23 Jul 2005 22:49:31 +0200]: > > > Don't forget to version the build-dependency on libid3-3.8.3-dev to (>= > > 3.8.3-4.2). > > On second thoughts, that was bad advice; please don't do it. In other > news, I'd like to upload a NMU to fix this shortly. The wait on this is that I haven't yet had an opportunity to upgrade my own system to properly recompile this. I hope to be able to do that tonight, if not I'll let you know. -- Robert Woodcock - [EMAIL PROTECTED] "Recommending that children [...] not [...] use them as a weapon to hit another person, could eliminate more than 40 per cent of backpack injuries" -- A Michigan hospital research team -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#309278: id3v2: support ID3 version 2.4.0 tags
On Mon, May 16, 2005 at 03:37:57AM -0400, mike castleman wrote: > Package: id3v2 > Version: 0.1.11-1 > Severity: normal > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Somehow I have ended up with some MP3 files with ID3 version 2.4.0 tags. > Running id3v2 --list on these files reports "No ID3 Tag", which is > wrong. Don't hold your breath. id3v2 can't support 2.4.0 tags until id3lib supports 2.4.0 tags. AFAIK that has been in development for over a year already. -- Robert Woodcock - [EMAIL PROTECTED] "Recommending that children [...] not [...] use them as a weapon to hit another person, could eliminate more than 40 per cent of backpack injuries" -- A Michigan hospital research team -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#259921: hexedit: New upstream release available (v1.2.10)
On Thu, Feb 24, 2005 at 02:30:23PM +0100, Florian Ernst wrote: > Hello Robert, > > I couldn't help but notice you didn't upload any newer versions of > hexedit since 2001-10-25, so I'm now wondering whether you are still > interested in maintaining this package anymore... It's been a long time since there was an upstream release. :) > If not do you mind if I take over? If you want it you can have it. -- Robert Woodcock - [EMAIL PROTECTED] perl -e '$a-=($_%4-2)*4/$_++while++$_<2e6;print"$a\n"' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#290215: Improper copyright file
On Thu, Jan 13, 2005 at 09:06:22AM +0100, Rogier Wolff wrote: > On Wed, Jan 12, 2005 at 07:19:57PM -0500, Justin Pryzby wrote: > > Package: mtr-tiny > > Version: 0.67-1 > > Severity: normal > > > > The copyright file of this package seems to use the *license*, instead > > of the copyright holder in the style of "Copyright (C) 2005 by Justin > > Pryzby". > > Where did you find this "suspicious wording"? I just spent 5 minutes > looking at all the sources, but nowhere do I see the "bad" wording. It's in the Debian packaging, not the upstream source. > Note that the COPYING file is /THE/ GPL, and is binary identical to > most other copies floating around on the net. > I'll fix this in the next upload so it reads: Copyright: mtr -- a network diagnostic tool Copyright (C) 1997,1998 Matt Kimball Copyright (C) 2005 [EMAIL PROTECTED] This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. The GPL is located at /usr/share/common-licenses/GPL on your Debian system. -- Robert Woodcock - [EMAIL PROTECTED] "Recommending that children [...] not [...] use them as a weapon to hit another person, could eliminate more than 40 per cent of backpack injuries" -- A Michigan hospital research team -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
