Re: Ask the Council!
 

from the posts i have seen from you lately, i think you made steady improvement there :D
certainly as far as joking is concerned... :rolleyes:

Re: Ask the Council!
 

Bug 9314 - Re-license BME

So far the bme has following two reasons for being closed sourced:

1. security
2. differentiation

Let's assume we can somehow address security concerns (e.g we ensure common user can not be subverted to install bogus package).

So there is something that is somehow so valuable that it can not be released as open source. I still think we should try to somehow overcome that restraint.

How about releasing a specification for hardware interface + providing simpler, usable, less efficient, but still safe algorithm as the replacement for the advanced closed source variant, that would not threat the differentiation goals of Nokia?

The benefit is that the user can still choose between more efficient closed source variant and less efficient open source variant. The whole thing should be used as backup plan, when Nokia finds itself unable to provide the closed sourced package in future.

The question applies to 770, N800, N810, N900.

Re: Ask the Council!
 

Start with the easy packages first right? You will NEVER get the source to BME. Ever.

Re: Ask the Council!
 

The last two years my sense of humor has diminished significantly, so I can't take credit for better behavior.

Re: Ask the Council!
 

Both difficult and critical package at the same time, besides I did not ask for the source of BME.

I've asked for:

1. hardware interface specification
2. independent charging algorithm

The first one ensures we can interact with the charging process. The second one does not need to compete with closed source BME. It should provide redundant solution.

Re: Ask the Council!
 

don't take it so seriously...
it's not that important, is it?

as far as i'm concerned, you still get a good grade...
well, 1/2 a good grade, that is, for the joke part :D

Re: Ask the Council!
 

Change in job/financial situation in 2009 was pretty drastic. Not happy since. Working on it though. Thanks for the good grade.

Re: Ask the Council!
 

sorry about that :(
sharing your pain :o

welcome!
appraisal is important, right?

Re: Ask the Council!
 

momcilo, vi_,

no disrespect for your discussion about BME.
just not sure how much worse then NOKIA's solution anything could possibly be

also don't understand the security + secrecy aspects.
i happened to use my phones for a few days in 2G and without any network feature and the batteries never even showed any sign of drain.
that changed drastically when i started to make pictures, however :(

so, yeah, the battery drain doesn't have anything to do w/ batteries or design of the N900 but simply with the wealth of features it offers... and ppl simply use.
it's a trade off.

back to the topic, from How long does your battery last? as well as from many packages in the various repositories, i was under the impression the battery was well under control :confused:

or does it have to do w/ the USB port that has like, well, three functions i can think of
- data
- charging
- boot "choice"
?

Re: Ask the Council!
 

Much more interesting (and less based on unproved assumption) research about bme was done by joerg_rw, shadowjk, 412b and others - I recommend searching for and reading their findings.

Basically, my uneducated (and possibly wrong) "short conclusion" is that replacing bme would bring need for rewriting many other maemo parts (API?), + loss of possibility to charge @ 500 mA from computer USB port (only 100 mA - ho ever, charging via wall charger wouldn't be limited). Long story short, doable, but hard and requiring much, *much* work.

Also, I agree that asking about releasing source code for bme *or* even some simple replacement entity (tm ;) ) from Nokians is pure waste of time. Cause obvious, historical reasons ;)

Re: Ask the Council!
 

@misterc BME is responsible for control of the charging process. Modern battery chargers have different algorithms, based on what sensor inputs(timers, temperature, current/voltage fluctuation etc...) are used to determine and apply the parameters in real time.

In a laptop, that process is usually not within the operating system, but in mobile devices vendors use simpler batteries, and the control is delegated to the software for two reasons:

• price
• size

I would like to explore the possibility of implementing open source alternative to stock bme. It does not need to outperform the Nokia bme.

Re: Ask the Council!
 

Thank you for sharing the information.

Re: Ask the Council!
 

thank you for the clarification.

by performance, you mean the time it takes to recharge the battery (in whole or in part) or is there anything else?
that's possibly made up by the aptitude to regulate the currant?

could the battery explode if it is charged too long?
there were rumours about laptop batteries that had that problem, a few years ago, i believe.

Re: Ask the Council!
 

Both are pretty much debunked in the bug report's comments, there just isn't any interest from the copyright owner to open the code.

Charging the N900 seems to be straightforward enough (comment #44). For the N8x0s, OpenWRT has a kernel-side implementation (which I tried a couple of times and seemed to work, and didn't blow anything up even). No idea about the 770.

Re: Ask the Council!
 

I'd like to ask a question to the council:

Why is Epitaph being allowed to promote his 'app' here on TMO, considering that he's clearly breaking the terms of the GPL?

Just one example (of many): Contained in the 'app' is the Bash binary. The GPL states that if you are going to redistribute GPL code, you must make the source of your app available.

He was hosting the app on Sourceforge, but it was removed from there - possibly due to me reporting it.

He has repeatedly refused to make the source available.

I'd like to know why maemo.org allows his thread and his signature here? By not taking any action, they appear to be condoning it.

I'm personally interested in this as it seems to go against FOSS principles, and as someone who has contributed time and effort to the open-souce world it makes me angry he gets away with it.

Thanks for listening.

Re: Ask the Council!
 

I second the question, especially after the threats by epitaph.

Re: Ask the Council!
 

Can we just ban and clean him and delete his thread? Or is that too draconian for his misdeeds?

Re: Ask the Council!
 

It's possible that I missed something but has any ground been made with regards to my question above?

Re: Ask the Council!
 

Lately, a possible source of Pali's problem has been "revealed" - he's using kernel.org kernel sources (with maemo kernel diffs attached + kp diffs at top of it), not maemo kernel + kp diffs.

It was suggested, that this may result in packages interface going crazy (by using debian packaging criteria, instead of maemo ones). Although, keep in mind that it's only guesswork and it's *not* confirmed. Some people, including me, suggested that easiest way to check it, is Pali switching his method to maemo kernel + kp diffs and see if this fix problem.

Also, of course, You were right about kp42 being in extras - my info was not actual one. Still, I think that we both agree it doesn't depreciate rationale behind my arguments ;)

---

Of course I also "second" jedi request - I'm glad that someone finally point that problem. Mentioned "individual" is violating GPL for long time, completely ignoring (or even showing hostility to) request to comply with GPL. Same happened with "his" set of scripts, containing work of others without giving proper credits. Not to mention overall trolling behavior...

Re: Ask the Council!
 

@Estel:

If I change kernel-power tarball to http://repository.maemo.org/pool/mae...28.orig.tar.gz (but only for new version of kernel-power), will maemo.org package interface really working? Are you sure?

I think that your argument that package X does not have same tarball as package Y is not correct. (X=kernel-power; Y=kernel) Package kernel-power has nothing with package kernel. kernel-power is in Extras and kernel is in SDK. Both are in different repositories and both has dfferent names.

So this argument is like that "Package bash3 must have same orig tarball that telepathy-gabble". Both packages are in different repositories and both has different names. And no problem with packages bash3 and telepathy-gabble.

Can somebody from Council comment my post? It is true? I think that each package can have its own orig tarball. Why not?

---

Now I see that I'm maintainer of all kernel-power packages. So this is last blocker for releasing new version!

Re: Ask the Council!
 

The council may not be able to answer this directly, but they could perhaps try to push the bug report forward.

AIUI Nokia are still paying for one full-time person for maemo.org maintenance, so not even having a response after 7 weeks seems a bit sub-optimal :-(

Re: Ask the Council!
 

Ok, now X-Fade on #maemo found problem. See:
http://mg.pov.lt/maemo-irclog/%23mae...08-11T10:37:42

Now I can try to fix it.

Re: Ask the Council!
 

@Estel:
Problem was that, v47 overwrited tarball of v46. It had other md5sum and this was reason why v47 was rejected. It has really nothing with SDK package kernel.

Re: Ask the Council!
 

@Pali: Seriously, please, don't use orig tarball from outside maemo.org. All the development/patches so far are against what Nokia has put in repos, not against the one on kernel.org. And it is obviously they don't match, it is not only checksum, kp48 patches from your git repo does not apply against .orig in maemo repos.

I think you can get correct(stock) .orig tarball one from here
http://repository.maemo.org/pool/fre...free/k/kernel/

Re: Ask the Council!
 

The only problem is with md5sum. See IRC log. (And continue talking in other thread, this is "Ask the council")

Re: Ask the Council!
 

Ima is that council meeting with nokia SD69 was talking about?

Re: Ask the Council!
 

No, that was last year (check the date in the URL & title).

Re: Ask the Council!
 

My mistake, was checking date on pali's chat.

Re: Ask the Council!
 

Going through Marius' IRC logs, it appears the meeting was here. The highlight IMHO is

which is a good 6 months longer than I thought we had :-)

Re: Ask the Council!
 

Dear Council,

I find it very disappointing that this meeting wasn't pre-announced for wider community participation. Ironic that the discussion about changing the scope of the Council and the meaning of maemo.org to a more open and formal entity was happening in relative secret.

(Finally) changes to the voting structure are happening. There's been lots of discussion on maemo-developers & -community about the limits and process changes which would be appropriate; but it seems that in the meeting SD69 & X-Fade were basically plucking figures from the air without any prior discussion or consensus?

Comments appreciated. TIA.

Re: Ask the Council!
 

I've read it just now. In short the meeting was about:

• how long the maemo.org. together with the forum will be hosted.
• reduction of operating costs, and moving to alternative infrastructure
• maemo name is held by nokia, which will not give it up, so renaming is almost certain
• "narrowing" the focus of the project

It would be interesting to learn what last point really means, since X-fade predicts shrinking of the community as a result of it.

Re: Ask the Council!
 

I find it amusing that after all this time the fact that the maemo.org-related decisions are usually made in private, by the people who have actual administrative rights to the maemo.org infrastructure, is news to you :)

Re: Ask the Council!
 

The private would mean absence of irc logs. In any case I hope SD69 and others will soon come up with official proposal for further actions.

Re: Ask the Council!
 

I will have a proposal, but there should not be just one and there should be an alternative so we can have a meaningful vote.

Re: Ask the Council!
 

The meeting was not secret and was mentioned by me (if you wanted to attend you could have), the discussion about changing scope and meaning went on in TMO (several times) and by me here where I said it would be discussed in the Council meeting and then there would be an election -

http://talk.maemo.org/showpost.php?p...&postcount=383

No one objected then. And if you read carefully, then it is apparent that I am trying to fulfill council's responsibilities in this meeting and determine if it's possible for things to make things happen that people have been asking about. There was no decision made, and at the end I inquire wrt conducting an election coming up where I expect this will be addressed by the community. There is no conspiracy or cloaks and daggers here, please move on.

Actually, it was the previous community discussion that made me raise the issue with X-Fade! I responded to community input here: http://talk.maemo.org/showpost.php?p...&postcount=399

And one could see where he asked me to approve changes, and I declined to do so saying I had to confer with the other council members. This issue has been around for awhile, previous Councils could have went about making changes but they didn't, and you want to criticize me for bringing it up? :confused:

I'm all for a community decision on this issue. You can lead it if you want to help. The result has to be clean, quickly decided, and easy to implement. My personal opinion is that we also want a trusted community member (other than X-Fade) to get some administrative rights to do the promotions so that we are not dependent on his availability.


Your criticism, particularly of me for doing what i regard as fulfulling a council member's responsibilities, is unfair. I am working on behalf of the community, in ways that I have publicly stated repeatedly and consistently. If you have substantive input, then provide it, not petty procedural criticisms.

Re: Ask the Council!
 

To improve communications and to enable wider community participation in IRC meetings could the council in the future send an email to maemo-community@ about upcoming meeting in IRC along with the proposed agenga? Meetings thread (with draconian moderation) here in addition to the email notification would be nice too.

Thanks.

Re: Ask the Council!
 

When is the next Council meeting scheduled?

Re: Ask the Council!
 

Before we start proposing things blindly it would be useful to know what we are talking about. Could we ask Nemein to provide a breakdown of resources utilised per service (current as well as trends), ideally also broken down by platform? I mean things like what is the peak bandwidth requirements of repository.maemo.org, how much filesystem space it uses, how many CPU cycles the autobuilders eat and so on.

Also, we really need to get a clear answer on how long the Nokia repositories will stay alive and what happens after that (eg can we have a licence to mirror them elsewhere?), because without that content we're dead and there's no point discussing anything else.

Re: Ask the Council!
 

I agree with lma except for

In my opinion, worst case scenario (Nokia don't want to allow us mirroring Nokia repos) would be "omitting" them in official documents/talk, and relying on "second hand" availability of them (user-to-user distribution, personal wiki's informing about such things existing...).

Ugly, bad, etc., but just remember that it's only worst case scenario, and I'm not advocating doing so, nor suggesting that further whatever-name "Maemo (Foundation?)" should advocate it. I'm rather talking about reality, i.e what will probably happen if Nokia goes berseker with their repos, until we got open source alternatives/clones of mentioned content.

Of course I understand that Council don't (and shouldn't) feel comfortable with responding to such "just observations of reality", so I don't expect an answer and I'm not waiting for. And I'm not talking ironically.

Re: Ask the Council!
 

That won't help for autobuilding anything that build-depends on nokia-binaries for instance. Even if we go back to building in our own scratchbox installations and uploading binaries to the repository, packages that have runtime dependencies simply won't install (or users will have to track down the dependencies on secondary channels and install manually, that'll be fun).