date:20091201

Hi,

A long time ago I was informed by Niels on this list that packages
dependencies (i.e. not user application or packages under user/*
categories) would be automatically promoted from extras-devel to
extras-testing (and to extras FWIW) if an application that depends on
it is promoted.

Well, it *used* to work like that some time ago, but in the last weeks
I've noticed that no newer versions of PyMaemo packages (which are all
dependencies from various user/* application) got promoted as before.

I don't know if it has been a manual operation of if the autopromotion
system is actually broken.

There has been some kind of pressure to get the optified Python
packages into extras, and that depends on this auto promotion
mechanism.

Can someone with powers check that? I can open a bug report if necessary.

Thanks,
-- 
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: extras-devel - extras-testing auto-promotion not working?

 Well, it *used* to work like that some time ago, but in the last weeks
 I've noticed that no newer versions of PyMaemo packages (which are all
 dependencies from various user/* application) got promoted as before.

Packages don't get updated in promotion process if earlier version satisfies 
dependency. Many packages have direct dependency only for python package, 
which hasn't been updated lately, not for python2.5 which is the actual 
optified version. python2.5 isn't probably promoted because no package hasn't 
had dependency python2.5 (=2.5.2-3maemo3). If packagers like to keep their 
Depends line clean they are unlikely to put python2.5 directly there.

-- 
Mikko Vartiainen
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: extras-devel - extras-testing auto-promotion not working?

On Tue, Dec 1, 2009 at 9:18 AM, Mikko Vartiainen mvartiai...@gmail.com wrote:
 Well, it *used* to work like that some time ago, but in the last weeks
 I've noticed that no newer versions of PyMaemo packages (which are all
 dependencies from various user/* application) got promoted as before.

 Packages don't get updated in promotion process if earlier version satisfies 
 dependency. Many packages have direct dependency only for python package, 
 which hasn't been updated lately, not for python2.5 which is the actual 
 optified version. python2.5 isn't probably promoted because no package 
 hasn't had dependency python2.5 (=2.5.2-3maemo3). If packagers like to keep 
 their Depends line clean they are unlikely to put python2.5 directly there.

So what should we do here to have newer version of dependencies promoted ?

Obviously, we will not recommend depending on python2.5 directly (that
was the whole idea of the python meta package). Also depending on a
specific version just to force promotion seems odd IMHO.

Should I proceed and promote the missing PyMaemo packages to extras-testing ?

IMHO ideally, the auto promotion should be aware of newer versions of
dependencies, otherwise how are we (the maintainers) supposed to
provide bugfixes ? (.e.g the new optified packages).

Thanks in advance,
-- 
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: extras-devel - extras-testing auto-promotion not working?

On Tue, Dec 1, 2009 at 3:37 PM, Anderson Lizardo
anderson.liza...@openbossa.org wrote:
 Should I proceed and promote the missing PyMaemo packages to extras-testing ?

You can promote PyMaemo packages to extras-testing but it's not the
solution, because it doesn't help getting them to Extras (you can't
promote them there). Even if newer versions of non user/ packages were
promoted to Extras it doesn't help much getting them to end users
devices if they had earlier version of them installed because of how
Application Manager works. Currently getting something to updated
requires that update is somehow visible through user/ package both in
Application Manager and packages interface autopromotion algorithm.

Promotion system could probably be changed that it always promotes
newer version of non user/ package. One option would be that package
maintainer can promote updates of non user/ package to extras
manually, but that circumvents the whole qa process.

-- 
Mikko Vartiainen
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Debian on the n900 / Configuring NOLO

Great!  Thank you Frantisek!

Frantisek Dufka duf...@seznam.cz writes:

 Frantisek Dufka wrote:
 Oh, right,  if it can flash eMMC then the mmc code is in, so loading 
 kernel from mmc is one NOLO bugzilla enhancement away ;-)

 Again, having kernel commandline stored inside config partition and NOLO 
 using it instead of builtin command line would be ideal situation.
 

 FWIW I have created bug for this
 https://bugs.maemo.org/show_bug.cgi?id=6468
 ___
 maemo-developers mailing list
 maemo-developers@maemo.org
 https://lists.maemo.org/mailman/listinfo/maemo-developers
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: extras-devel - extras-testing auto-promotion not working?

2009-12-01 Thread Igor Stoppa

ext Mikko Vartiainen wrote:

 You can promote PyMaemo packages to extras-testing but it's not the
 solution, because it doesn't help getting them to Extras (you can't
 promote them there). Even if newer versions of non user/ packages were
 promoted to Extras it doesn't help much getting them to end users
 devices if they had earlier version of them installed because of how
 Application Manager works. Currently getting something to updated
 requires that update is somehow visible through user/ package both in
 Application Manager and packages interface autopromotion algorithm.

 Promotion system could probably be changed that it always promotes
 newer version of non user/ package. One option would be that package
 maintainer can promote updates of non user/ package to extras
 manually, but that circumvents the whole qa process.
   
But if here there is a clear bug (not using /opt) which gets fixed by 
the newer version, what more is needed? And why?

igor
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: contribution to projects in Garage

2009-12-01 Thread Cornelius Hald

Reshma Prasanna wrote:
  
 Hi,
  
 
 I think there are a lot of people who could need a help. But
 what is your back-ground, which is the kind of project to be
 interested in, in which kind of work do you think you could help
 out? I think a good approach would be to write a bit about this
 and open a thread in the developer forum in talk [1]. I'm sure
 that somebody will come then to you. If you are familiar with Qt
 maybe this would be a possibility [2] ;)
 
 Thank you for all the suggestions. My background is primarily in 
 multimedia on embedded systems (codecs, streaming, players) and that 
 would probably be the best area for me to contribute in.
 Unfortunately, I am not familiar with Qt right now, but I can always 
 change that :)

Not really _muli_ media, but there are people interested in getting 
image support into Conboy. So if you´re interested in that or in other 
aspects of Conboy, please feel free to contact me.

More information can be found here:
Downloads: http://maemo.org/downloads/product/Maemo5/conboy
Forum: http://talk.maemo.org/showthread.php?t=28355
Code: https://garage.maemo.org/plugins/scmsvn/viewcvs.php/?root=conboy

Cheers!
Conny
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: extras-devel - extras-testing auto-promotion not working?

On Tue, Dec 1, 2009 at 4:08 PM, Igor Stoppa igor.sto...@nokia.com wrote:

 But if here there is a clear bug (not using /opt) which gets fixed by the
 newer version, what more is needed? And why?


For this particular case there isn't anything else needed (imo). But
generally if you can't promote user/ packages directly to extras you
probably shouldn't be able to promote non user/ packages directly
either.

-- 
Mikko Vartiainen
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

QA Process for non user/* packages and how Application Manager handles upgrades (was: Re: extras-devel - extras-testing auto-promotion not working?)

On Tue, Dec 1, 2009 at 9:51 AM, Mikko Vartiainen mvartiai...@gmail.com wrote:
 You can promote PyMaemo packages to extras-testing but it's not the
 solution, because it doesn't help getting them to Extras (you can't
 promote them there). Even if newer versions of non user/ packages were
 promoted to Extras it doesn't help much getting them to end users
 devices if they had earlier version of them installed because of how
 Application Manager works. Currently getting something to updated
 requires that update is somehow visible through user/ package both in
 Application Manager and packages interface autopromotion algorithm.

Sorry but it is still not clear to me how to get fixes to non user/*
packages to the users' devices. If I understand correctly, Application
Manager does not follow the same behavior as apt-get on this case,
i.e. it will not upgrade non user/* packages on Device even if there
are new versions in extras, is that right?

 Promotion system could probably be changed that it always promotes
 newer version of non user/ package. One option would be that package
 maintainer can promote updates of non user/ package to extras
 manually, but that circumvents the whole qa process.

If I remember correctly, the QA process is currently very user/*
centered. I followed the discussions on last meeting too, and the
process does not seem to cover the updates for non user/* packages. So
right now we have a serious problem (IMHO) where we can get non user/*
package updates delivered to final users through a clean process.

Some user suggested once creating meta user/* packages for libraries,
python modules etc. that need updates, but I think this just too
hackish, and even if we proceed and do this, how do we convince the
end user to install it?

Regards,
-- 
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Double checking free/nonfree packages

So first of all, I'd like to note that I was very happy to wake up to
thse replies, particularly this one. It does raise a lot of confidence.

Can it be that we start having several iniciatives like this spread in
different places? At the end the goal is the same: Maemo as open as
technically possible being still stable and full featured.

It would be really useful to have the one and only list of closed
components prioritized by community interest. An openness backlog for
people like me to work on.

Yes, I agree, forking this kind of documentation is not ideal . I think
Nokia has made it clear that it sees free and open source software as a
means, whereas I and some others see it as an ends in itself. However,
it would be to the benefit to all of us if we collaborate here. I will
move my list over to the Maemo wiki tonight, when I am done with work.

For now there seem to be two main pages on which the documentation of
what is free/nonfree is:
-
http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Architecture/Top_Level_Architecture
- http://wiki.maemo.org/Why_the_closed_packages

The first contains that rather informative graph, but I suspect that the
intended purpose of that page would be made less useful if we put all of
the documentation of free/nonfree components on there. The second one
seems to be a good start, but I think the naming of that particular page
helps defeat our purpose, as it seems to say here is why these are
closed as just an explanation, and does not indicate this is a record
of pieces that we are working to free. So, unless there are any
objections, I think it would be better to start a page with a name such
as Free_Maemo or something similar that indicates a kind of free and
open source todo-list that I think everyone here seems to want. I'll
work on incorporating the Why the closed packages page within that
document, and if that proves to be satisfactory, we can probably have
the Why_the_closed_packages page redirect to the new one.

The criteria to prioritize components could be (improvising a bit, feel
free to suggest improvements):

1. Fixing a bug. I mean a real objective bug: package is in non-free
although it looks like it's actually an open piece of software.

2. Nurturing application development. There is a strong argument proving
that opening a component will bring more and better apps for end users.

3. Spread of Maemo driven technologies to other platforms. A component
fits well in a gap existing in other Linux/OSS based projects and there
is a concrete interest on collaborating and contributing to a component
if it's opened.

4. Community maintenance. A component is receiving low attention from
the official maintainers even if it has high attention from the
community and there are developers volunteering to contribute to it if
the source code is available.

5. Better architecture. Probably covered by 2 or 3 but just in case. A
closed component is sitting in the midle of open components making
things more difficult that needed to developers interested in that area.

These seem reasonable points. I'll be sure to have that guide indicated
on the page.

There is no problem having the source file public, but the good solution
is to simply update the source image and link to it instead of forking
it. Otherwise the chances of you having a version different to the one
in the official documentation is high, when there should not be any
reason to show anything different.

Yes, I think that if we are going to be keeping things on the maemo
wiki, it makes sense to have one image there. Then both the Top Level
Architecture and the Free Maemo (or whatever) page can both share the
same image.

Thanks for the great responses, all! I'll work on documenting this
tonight.
- cwebb
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Double checking free/nonfree packages

Carsten Valdemar Munk c...@cs.au.dk writes:

 Did you in your research run into Mer, btw? http://wiki.maemo.org/Mer  
 - we strive towards having a 100% OSS platform on the software side  
 (our views probably differ on the HW support side but so it goes)

I did run across Mer, and I was considering incorporating it but I was
fairly tired by the time I wrapped up documenting last night.  I will
include it while continuing documentation tonight.

For the record, there are a list of goals here on the Mer page:
http://wiki.maemo.org/Mer

But having a 100% OSS platform on the software side is not listed as
one of them.  If you are part of the project and you do see that as one
of the goals, consider adding it to that list.. I think it would be
helpful and would raise interest level in the project for people like
myself who have similar goals.

 - cwebb
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: QA Process for non user/* packages and how Application Manager handles upgrades (was: Re: extras-devel - extras-testing auto-promotion not working?)

2009-12-01 Thread Henrik Hedberg

Anderson Lizardo wrote:

 Some user suggested once creating meta user/* packages for libraries,
 python modules etc. that need updates, but I think this just too
 hackish, and even if we proceed and do this, how do we convince the
 end user to install it?

I still suggest meta user/* packages. Nokia is actually using meta 
user/* packages (for example, Maemo 5 package is a meta package 
pulling the platform non user/* packages when upgraded).

However, there might still be a question about how to convince an 
end user to upgrade a package that he has not actually installed. In 
Maemo 5 case that is easy, but in other cases it might require some 
additional communication.

One solution could be that the Application Manager showed other 
user/* packages that depends on meta user/* packages. That way an user 
might understand that if he upgraded Python package (or Microfeed 
package), gPodder (Mauku), for example, would benefit from that. Maybe 
those meta packages should be in a separate section (user/backend, 
user/platform, user/libraries, or similar).

BR,

Henrik

-- 
Henrik Hedberg  -  http://www.henrikhedberg.net/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Double checking free/nonfree packages

2009-12-01 Thread David Greaves

On Mon, 2009-11-30 at 22:16 -0600, Christopher Allan Webber wrote: 
 Hello,
 
 I'm compiling a list on the Libre Planet wiki to determine what packages
 are nonfree, and what steps would need to be taken to make the n900 a
 fully free phone:
 
 http://groups.fsf.org/wiki/FreeMaemo

Hi Christopher

As another Mer person I'm also very interested in this work. Mer on any
Nokia device out today is not (and realistically has zero chance of ever
being) 100% fsf-free.

However every step the community takes in the right direction moves us
towards that milestone and I personally feel that Nokia are doing
freedom in a better way than most (which is one reason I'm here!)

If this is a reasonable compromise then it would be great to see this
work integrated with the maemo community efforts - IIRC there have been
other initiatives to investigate this kind of data so maybe they could
be dug up?


David


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: QA Process for non user/* packages and how Application Manager handles upgrades (was: Re: extras-devel - extras-testing auto-promotion not working?)

 
 I still suggest meta user/* packages. Nokia is actually using meta 
 user/* packages (for example, Maemo 5 package is a meta package 
 pulling the platform non user/* packages when upgraded).

Meta packages are unfortunately the only working way
get library updates to users. I still would hate to
see all libraries in Application Manager, even if
they were semi hidden to some category. Only _good_
solution that I can see is that Application Manager
would work the same way as apt-get and upgrade all
packages (except the Nokia meta package).

-- 
Mikko Vartiainen
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: QA Process for non user/* packages and how Application Manager handles upgrades (was: Re: extras-devel - extras-testing auto-promotion not working?)

On Tue, Dec 1, 2009 at 11:32 AM, Mikko Vartiainen mvartiai...@gmail.com wrote:

     I still suggest meta user/* packages. Nokia is actually using meta
 user/* packages (for example, Maemo 5 package is a meta package
 pulling the platform non user/* packages when upgraded).

 Meta packages are unfortunately the only working way
 get library updates to users. I still would hate to
 see all libraries in Application Manager, even if
 they were semi hidden to some category. Only _good_
 solution that I can see is that Application Manager
 would work the same way as apt-get and upgrade all
 packages (except the Nokia meta package).

The problem being that the meta-package will pull *all* PyMaemo
packages and not just what the user wants/needs :/

Unless Application Manager honours Suggests:  fields ? in this case we
could put all non-core Python packages under that field.

The other solution is to fix Application Manager :o)

Regards,
-- 
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Double checking free/nonfree packages

Heya David,

David Greaves da...@dgreaves.com writes:

 If this is a reasonable compromise then it would be great to see this
 work integrated with the maemo community efforts - IIRC there have been
 other initiatives to investigate this kind of data so maybe they could
 be dug up?

That's my intention, see my reply to Quim Gil... I'll be moving over
that documentation to Maemo's wiki tonight.  If you know of other
sources of this data that would be useful to incorporate, I'd appreciate
the links the clearer picture we're able to construct from this
data, the better.

 - cwebb
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: QA Process for non user/* packages and how Application Manager handles upgrades (was: Re: extras-devel - extras-testing auto-promotion not working?)