After a really crazy weekend in which it looked like I wasn't able to set up NAT[1], I went to work with the gear and tested the exact same thing I did at home and it worked without a glitch.
So, now I suspect that there might be something wrong with my ISP or the DSL modem, while ritter (my NSLU2) is fine. As a bonus I just installed Debian armel on it (installation report to arrive soon).
When I got home, after the laptop came back from hibernate[2] I saw these messages on all my terminals:
Message from syslogd@bounty at Mon Nov 12 23:57:04 2007 ...
bounty kernel: Uhhuh. NMI received for unknown reason b0.
Message from syslogd@bounty at Mon Nov 12 23:57:04 2007 ...
bounty kernel: You have some hardware problem, likely on the PCI bus.
Message from syslogd@bounty at Mon Nov 12 23:57:04 2007 ...
bounty kernel: Dazed and confused, but trying to continue
Is this a good time to panic?
I guess I'll have to dig into this, too.
In other news, svn-buildpackage 0.6.23 has been uploaded to unstable and it fixes yet another 7 bugs, which brings svn-bp's bug count down to 19 open valid bugs (2 more if you count wontfix bugs, too). This is the lowest bug count of svn-buildpackage since at least the end of April, according to the bug count graph.
Also, oolite 1.65-6 was also uploaded to unstable and fixes the breakage due to the gnustep build tools changes. Unfortunately, on arm is dep-waiting for libgnustep-base-dev which is broken on this arch.
Thanks to my sponsors, you know who you are ;-) .
[1] I have been trying to set up a simple NAT machine for more than 6 hours and, although everything seemed to be OK, checked and double checked it didn't work
[2] which works now only if I don't use fglrx which is broken from this PoV (bug 449095)
Showing posts with label release. Show all posts
Showing posts with label release. Show all posts
Tuesday, 13 November 2007
Wednesday, 7 March 2007
The game Oolite was liberated
Yet another liberated game: Oolite, a clone of Elite.
I am the maintainer of the package; it was introduced as a non-free game in Debian, but a week ago upstream has announced that the game is now relicensed with a dual model licensing with GPL and cc-nc-sa 2.0 (the old license). Also, the change applies retroactively to the 1.65 release while further releases will be licensed GPL only and GPL/cc-nc-sa 3.0 for the code and data, respectively.
I have prepared the packages (oolite 1.65-5 and oolite-data 1.65-2) and Simon Richter agreed to make the honorary upload :-) tomorrow morning.
I hope he doesn't forget to build the packages by passing the '-sa' parameter to dpkg-buildpackage :-) and that these packages will reach Etch just in time for release.
As a bonus to this change, the game will be autobuilt on amd64, too.
(BTW, why isn't there any amd64 buildd in the non-free buildd network? Any technical reason?)
Update: the amd64 build seems that was behind in January when I installed the game on my new laptop. 1.65-4 seems that has been built a month ago, much later than the other arches.
Update: It seems that the package is on a positive trend on popularity: a constant rise in the number of oolite package installations is visible...
I am the maintainer of the package; it was introduced as a non-free game in Debian, but a week ago upstream has announced that the game is now relicensed with a dual model licensing with GPL and cc-nc-sa 2.0 (the old license). Also, the change applies retroactively to the 1.65 release while further releases will be licensed GPL only and GPL/cc-nc-sa 3.0 for the code and data, respectively.
I have prepared the packages (oolite 1.65-5 and oolite-data 1.65-2) and Simon Richter agreed to make the honorary upload :-) tomorrow morning.
I hope he doesn't forget to build the packages by passing the '-sa' parameter to dpkg-buildpackage :-) and that these packages will reach Etch just in time for release.
As a bonus to this change, the game will be autobuilt on amd64, too.
(BTW, why isn't there any amd64 buildd in the non-free buildd network? Any technical reason?)
Update: the amd64 build seems that was behind in January when I installed the game on my new laptop. 1.65-4 seems that has been built a month ago, much later than the other arches.
Update: It seems that the package is on a positive trend on popularity: a constant rise in the number of oolite package installations is visible...
Monday, 5 March 2007
about stable and oldstable (not sarge and etch)
I was wondering, would it make sense if it would make sense to allow updates to stable packages (more specifically, maintainer scripts) just to allow clean upgrades from a current stable to a new stable release (as in allow changes in Sarge to make upgrades to Etch smoother).
I have seen already many packages that would be better to have a small change in the old version rather to have some kludges in the new postinst.
I have seen already many packages that would be better to have a small change in the old version rather to have some kludges in the new postinst.
Saturday, 20 January 2007
RC bugs, what about important ones?
I was wondering if is right to our users that we are following only the RC bugs before a release. I think not. Don't get me wrong, I don't want important bugs count to be 0, or something similar; that would be insane to have as a goal.
I am thinking that we should (during the freeze) poke more of those important bugs that our and/or others' packages have. If you are like me, you will feel that you can't do anything/too much to improve the quality of the release during the freeze since some of the RC bugs are corner cases, not reproducible on your arch, already taken or you don't have the knowledge to fix them.
Many of the important bugs are broken functionalities that affect the users on a daily basis, and living 2 years with the same set of bugs is a pain. I don't know how that would feel, but I can imagine. I used Woody for only a half an year and after 2 months I started using backports. After 3, I started pulling things from Sarge (at the time it was testing). At the end of that half of year I was using mostly Sarge stuff and decided to go entirely into testing.
So, what do I propose? Maybe we should make some pages in the style of the RC bugs count pages which follow the important bugs.
As a bonus we might see some interesting things like bugs which were downgraded from RC - the RC graph would go down, while the important graph would rise. Of course, that wouldn't mean too much since that would be the product of badly assigned severities or downgraded and judged as non-RC bugs, but it would interesting to follow such tendencies.
I am thinking that we should (during the freeze) poke more of those important bugs that our and/or others' packages have. If you are like me, you will feel that you can't do anything/too much to improve the quality of the release during the freeze since some of the RC bugs are corner cases, not reproducible on your arch, already taken or you don't have the knowledge to fix them.
Many of the important bugs are broken functionalities that affect the users on a daily basis, and living 2 years with the same set of bugs is a pain. I don't know how that would feel, but I can imagine. I used Woody for only a half an year and after 2 months I started using backports. After 3, I started pulling things from Sarge (at the time it was testing). At the end of that half of year I was using mostly Sarge stuff and decided to go entirely into testing.
So, what do I propose? Maybe we should make some pages in the style of the RC bugs count pages which follow the important bugs.
As a bonus we might see some interesting things like bugs which were downgraded from RC - the RC graph would go down, while the important graph would rise. Of course, that wouldn't mean too much since that would be the product of badly assigned severities or downgraded and judged as non-RC bugs, but it would interesting to follow such tendencies.
Subscribe to:
Posts (Atom)