Oolite Bulletins

Soo.. I'm running testing, some days ago did a fresh install on a second laptop and to my surprise when I wanted to give Oolite a spin, it was not in the repositories (!)



it was REMOVED from testing on July 11th...:

https://tracker.debian.org/news/697003

Reasons:

https://tracker.debian.org/pkg/oolite

That's Oolite 1.77 they're talking about, yes?

I thought the most up to date in the repos last time I checked was 1.76-ish, so I guess, yes...

(EDIT: yes, yes indeed)

Tell 'em to put Oolite 1.82 in there. <grins> How are you, btw?

Cody wrote:

Tell 'em to put Oolite 1.82 in there. <grins> How are you, btw?

Hi Cody, I was thinking the same thing, but do not recognize the name of the maintainer...

I am... Hard to tell how I am, life's a bit of a challenge (P.M. because I don't feel like telling the world what's happening in our family)

Rxke wrote:

Reasons:

https://tracker.debian.org/pkg/oolite

Summary of problems follows:

Found in version oolite/1.77.1-3

The license header contains a short name with a space, which does not conform to the specification.
* png license (paragraph at line 121)
* variant of apache 1.0 (paragraph at line 89)

The package fails to build in a test rebuild on at least amd64 with
gcc-5/g++-5, but succeeds to build with gcc-4.9/g++-4.9.

Identifier: timestamps_from_cpp_macros
URL https://wiki.debian.org/ReproducibleBui ... mCPPMacros
Description The C pre-processor macros `__DATE__`, `__TIME__`, and `__TIMESTAMP__`
captures the current time, and thus will obviously make a build
unreproducible.

Maintainers for oolite are Nicolas Boulenguez <[email protected]>.

I couldn't find __TIME__ or __TIMESTAMP__ in trunk, and the only __DATE__ I could find (other than one reference in the Mac code) was in setting the date for the window title. I'm pretty sure they could change that in their version if they really wanted to.

The other bug I noticed was https://bugs.debian.org/cgi-bin/bugrepo ... bug=778039, which claims we're using formatting strings in a potentially unsafe way. Fixing that would involve replacing e.g. kOOLogNoteFuelLeak with the actual string it represents throughout the code.

EDIT: I'm talking rubbish on that last point (not an unusual occurrence). It's the second argument that's the problem - apparently, printf("string") is unsafe - you're supposed to use something like printf("%s", "string") instead. It might also be complaining that we're sending an NSString object instead of a literal C string.

kanthoney wrote:

EDIT: I'm talking rubbish on that last point (not an unusual occurrence). It's the second argument that's the problem - apparently, printf("string") is unsafe - you're supposed to use something like printf("%s", "string") instead. It might also be complaining that we're sending an NSString object instead of a literal C string.

printf("string") is probably fine, but printf(stringVariable) isn't.

Adding -Werror=format-security to a gcc 4.9 build of the current master doesn't give any errors, so it's possible that they wouldn't even get that error if they tried to build 1.82

Oolite 1.82-1 migrated to testing

https://tracker.debian.org/news/709957 6 days in unstable, no showstoppers
Migrated to testing: https://tracker.debian.org/news/711851