I'm not a repo-fan , but I've requested permission to upload calvaria. Once I'm approved I might actually do that, so I get used to the whole maemo.org/autobuilder/repo mess.

But note that calvaria is only a single C file (calvaria.c), with no dependencies, and no plans of being updated [ although I might update it once I learn about the exact details of some blobs ]

Yeah, I'd say it's about that time finally.

Personally I call it 'rdmod' but matter of taste I guess. Just know that when I do put it in the repos, it'll be under that name. At any rate, thanks for throwing that up. Can you point me to where the calvaria source is that you found?

Really? Why not a fan? (Just whatever you do don't upload two versions of a package with the same reported package version. Last I did that it still had a *****ic bug in the autobuilder python code (idk if actual autobuilder, or technically separate, but it's part of that whole process), which jammed the autobuilder for everyone.)

If you want I can do the maintaining of it in the repo if you don't wish to deal with it (just add me as a maintainer once you get approval for it). I may end up updating it at that point as well, idk (Actually the approval is for upload rights overall, what you upload after doesn't have to match or be anything, so you could just not upload it. That said, if you want to be maintaining it, then it's less work for me which I'm not complaining about - just offering to take calvaria on as well if you wanted.)

P.S. I meant to make a joke like "but does yours come compiled with the -fPIC flag" @ reinob's posting of precompiled binaries, but ended up forgetting.

@Mentalist Traceur,

I like short names during development , I'll rename it anyway from rd to rdmod
The source for calvaria (a single .c file) can be found.. wait:
https://dev.openwrt.org/browser/pack...src/calvaria.c (text form)
https://dev.openwrt.org/export/38692...src/calvaria.c (downloadable)

If you could take care of maintaining it -- much better, as I don't like the whole packaging/versioning/maintaining stuff. I don't use or like version numbers

what is this r and d mode ?

It's all about luring the dog out of the watch house.... and other stuff.

There's supposed to be a wiki page for it, but it seems that the URL is broken.

R&D mode ('Research and Development mode') is a feature built into the N900 for the sake of developers, but which is sometimes useful for other purposes.

Basically, there are a few fairly technical features that the N900 can turn on/off, and by default, the way it does that is that one of the early bootup scripts reads the R&D mode string from the CAL area of the N900 (the CAL area is a special partition/section of the small nand flash chip, on which the rootfs resides), and then the shell scripts see what, if any, R&D mode features to turn on depending on what, if any, flags it reads in the string.

By default, you can only change these settings with the Nokia Flasher utility, which has to run on another computer, and can't do the needed changes locally.

One of the things that turning R&D mode does by default (without actually toggling on any of the R&D flags), is that the N900 turns on a thing where the LEDs of the keyboard flicker in response to system activity - this was meant to let developers see if their apps were causing system activity in the background.


Another thing you can do is disable a few features on the N900 that will reboot the phone if they think they detect a problem (those are the watchdogs you might hear about occasionally), there's also some 'lifeguard' thing that does a similar thing. In rare cases being able to disable these things is good, though admittedly that can be rare.

Then there's some other R&D mode flags that deal with an STI console and disabling sleep on the USB port, etc.

libcal semaphore name fixed, debian packaging added (thanks Pali)

https://gitorious.org/community-ssu/...e361372ec8cc2:

I know, I know, but the sheer fun of having it in "updated" section of package manager, *if* some update happens, after all - even if I miss info inside thread, or whole thread, at all - is priceless.

Not to mention fun-saving in case of fresh install, without need for thread-and-download-url hunting - repo and name is enough. Every time I prepare N900 for someone, somewhere away from my link collections, and I start link-hunting for all repo-less but unskippable packages, I feel almost like windows user, back again too geeky.

/Estel

Well, that seemed to have fixed the prior issue (in a different way than how I did it, but alright), but now another thing is broken (easily worked around, but..):

CAL_ERROR_NOT_FOUND and CAL_OK defines should not have been moved into cal.c - they are return values of libcal functions and one of the points of having them defined in the header is that so code that uses libcal can be written to check for those defined macro values and not need digging in the cal.c file to find what the actual values are.

I am not sure what reasoning led Pali to think they ought to be private.

Besides that though, Pali taking the time to do something about it is appreciated. I would've gladly submitted a fix on gitorious when I got around to it, but I've been busy (I really shouldn't be taking the time to post right now nor should I have been opening this thread to check for new posts at that...for that matter I shouldn't have even been working on rdmod at all this week, but what can I say, I felt really compelled to.. still do).

One last note: Actually, on further glance, I have to lodge a complaint about the entire change made - I don't think several of the things that used to be in the header file should have been moved out of it, the 'struct cal' definition included. For starters, if I wanted to write a program that would allow manual perusing of the CAL area, I could no longer do it with the new version of the header, because the code having access to the struct cal layout is needed to be able to do that (at the minimum; access to some of those other internal functions is probably needed too and I'm not even sure if the compiler can look at just the forward declaration "struct cal;" with no further definition and even know everything it needs to know to work with a struct cal pointer correctly, and more importantly frankly I don't get the rationale for moving so many definitions into cal.c - sure the very limited interface we had from Nokia's cal.h made sense - because Nokia actually wanted to keep the whole thing locked down and access/control of it limited; but that makes no sense for the open source recode - in general making things private to the .c instead of public in the .h tends to mean you're making arbitrarily limiting assumptions about how someone might find it useful to use the functionality in your library; it makes /some/ sense as a minimal protection approach, i.e. if you want to bounds-check values that your code uses, but there's a lot less benefit to doing that in open source code especially of a low-level system library like this [i.e. now if I wanted to write said program I would have to simply copy-paste a good portion of cal.c code into my own code and that's just extra maintenance overhead]). Suffice it to say the update that just happened took away substantial functionality/flexibility that the previous version opened up, when the easiest fix to the problem I had initially reported was simply to add "#include <sys/stat.h>" to cal.h.