Fri, 18 Nov 2011
Release Critical Bug report for Week 46
The bug webinterface of the Ultimate Debian Database currently knows about the following release critical bugs:
| In Total: | 1812 |
|---|---|
| Affecting Wheezy: | 1161 |
| Wheezy only: | 163 |
| Remaining to be fixed in Wheezy: | 998 |
Of these 998 bugs, the following tags are set:
| Pending in Wheezy: | 47 |
|---|---|
| Patched in Wheezy: | 191 |
| Duplicates in Wheezy: | 47 |
| Can be fixed in a security Update: | 31 |
| Contrib or non-free in Wheezy: | 16 |
| Claimed in Wheezy: | 0 |
| Delayed in Wheezy: | 4 |
| Otherwise fixed in Wheezy: | 89 |
Ignoring all the above (multiple tags possible) 631
bugs need to be fixed by Debian Contributors to get Debian 7.0 Wheezy
released.
However, with the view of the Release Managers, 1053 need to be dealt with for the release to happen.
Please see Interpreting the
release critical bug statistics
for an explanation of the different numbers.
postet at 13:01 into [Debian/rc-stats/7.0-wheezy] permanent link
Fri, 11 Nov 2011
Release Critical Bug report for Week 45
The bug webinterface of the Ultimate Debian Database currently knows about the following release critical bugs:
| In Total: | 1869 |
|---|---|
| Affecting Wheezy: | 1211 |
| Wheezy only: | 155 |
| Remaining to be fixed in Wheezy: | 1056 |
Of these 1056 bugs, the following tags are set:
| Pending in Wheezy: | 54 |
|---|---|
| Patched in Wheezy: | 197 |
| Duplicates in Wheezy: | 48 |
| Can be fixed in a security Update: | 33 |
| Contrib or non-free in Wheezy: | 12 |
| Claimed in Wheezy: | 0 |
| Delayed in Wheezy: | 10 |
| Otherwise fixed in Wheezy: | 87 |
Ignoring all the above (multiple tags possible) 684
bugs need to be fixed by Debian Contributors to get Debian 7.0 Wheezy
released.
However, with the view of the Release Managers, 1105 need to be dealt with for the release to happen.
Please see Interpreting the
release critical bug statistics
for an explanation of the different numbers.
postet at 13:02 into [Debian/rc-stats/7.0-wheezy] permanent link
Mon, 07 Nov 2011
Release Critical Bug report for Week 45
The bug webinterface of the Ultimate Debian Database currently knows about the following release critical bugs:
| In Total: | 1893 |
|---|---|
| Affecting Wheezy: | 1250 |
| Wheezy only: | 180 |
| Remaining to be fixed in Wheezy: | 1070 |
Of these 1070 bugs, the following tags are set:
| Pending in Wheezy: | 47 |
|---|---|
| Patched in Wheezy: | 190 |
| Duplicates in Wheezy: | 51 |
| Can be fixed in a security Update: | 33 |
| Contrib or non-free in Wheezy: | 10 |
| Claimed in Wheezy: | 0 |
| Delayed in Wheezy: | 3 |
| Otherwise fixed in Wheezy: | 87 |
Ignoring all the above (multiple tags possible) 709
bugs need to be fixed by Debian Contributors to get Debian 7.0 Wheezy
released.
However, with the view of the Release Managers, 1144 need to be dealt with for the release to happen.
Please see Interpreting the
release critical bug statistics
for an explanation of the different numbers.
postet at 20:38 into [Debian/rc-stats] permanent link
Weekly RC Bug Statistics enabled again
Friday David Prévot reminded me about the statistics for release critical bugs I used to publish during the squeeze release cycle, and asked if I could enable them again.
After tweaking the script generating the statistics a bit (mainly a s/squeeze/wheezy/g) the stats will be again published weekly, every Friday at 13:05 CET.
The first report is already available, and it seems it is about time, that we got the Wheezy Bug Squashing Party Marathon started! So, see you at the first BSP in Hildesheim.
postet at 12:18 into [Debian/rc-stats] permanent link
Wed, 28 Sep 2011
How to properly route packages on hosts with multiple NICs?
Dear lazyweb,
I'm encountering a routing problem on one of my Linux machine, for which I haven't found a solution so far. I have a machine which has several network interfaces in different network (it's our monitoring system). So I have eth0 with 192.168.1.2 and eth1 with 10.0.0.2, and an dns entry pointing from myname to 192.168.1.2.
Problems occur, if hosts in the 10.x.x.x network try to access the hosts. Accessing it via it's IP address in that network works, however if they try to access him via his other IP address 192.168.1.2 (e.g. because they resolve it via dns), it leads to some problems:
The host send their packet to his IP address (which works), however when my machine sends the answer, it takes a shortcut, and sends them directly via eth1 and with 10.0.0.2 as source IP. This however gets filtered by a (stateful) firewall somewhere in between, as packet send to 192.168.1.2 are suddenly answered by 10.0.0.2.
So far I found two solutions: Adjust the DNS to resolve to different IPs depending on the source of the request (ugly) or tell all firewalls to always let packet from my host pass, despite the changes source IP (also ugly, and probably quite some work).
Is there anything else I can do? What I would really like, would be a way to tell my linux box to always respond with the IP it was talked to, even if there would be a shorter way to the origin according to the routing rable. So, if a host 10.0.0.42 contacts my host via the IP 192.168.1.2, the answer packet should come from 192.168.1.2 via eth0 instead of instead of having a source IP set to 10.0.0.2, it should be send via eth1. Is that somehow possible?
Update: Wow, that was fast! The ink of my blog is still fresh,
and I already got the answer! The solution to my problem is policy
based routing
. Thanks to weasel, Peter and Dale for their pointers!
More information available at http://lartc.org/howto/lartc.rpdb.html,
http://www.itbuzzer.net/corner/2007/09/how-to-implement-source-routing-with.asp
or http://wiki.georgweiss.de/Linux/source_routing.
postet at 13:25 into [Debian] permanent link