Pushing optified Python libs

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Pushing optified Python libs

Quim Gil
Hi, it seems that more users than wished are still reaching the rootfs limit only with the Nokia and Extras repos installed.

Most (all?) Apps in Extras seem to be correctly optified, so one possibility is that the problem relies in the libraries.

Sorry if I have missed something but I remember a post mentioning that optified libraries were available in Extras-devel but still not Extras. if true, and if the libraries have been tested, would there be a possibility to push them to Extras forcing an update in the background?

Also, if you know or suspect other causes for Extras users filling their rootfs partitions please let us know.

--
Quim Gil + N900
open source advocate
Maemo Devices @ Nokia
_______________________________________________
maemo-developers mailing list
[hidden email]
https://lists.maemo.org/mailman/listinfo/maemo-developers
Reply | Threaded
Open this post in threaded view
|

Re: Pushing optified Python libs

Andre Klapper-3
Am Donnerstag, den 17.12.2009, 11:16 +0100 schrieb [hidden email]:
> Hi, it seems that more users than wished are still reaching the rootfs
> limit only with the Nokia and Extras repos installed.
> Also, if you know or suspect other causes for Extras users filling
> their rootfs partitions please let us know.

Also see Uwe's list at
http://wiki.maemo.org/Opt_Problem/Non-Optified_packages plus the bug
reports with "non-optified" keyword:
https://bugs.maemo.org/buglist.cgi?keywords=non-optified

andre

--
Andre Klapper (maemo.org bugmaster)

_______________________________________________
maemo-developers mailing list
[hidden email]
https://lists.maemo.org/mailman/listinfo/maemo-developers
Reply | Threaded
Open this post in threaded view
|

Re: Pushing optified Python libs

Aniello Del Sorbo
Xournal is not yet optified, I'll add it to that list and will try to
remove it "soon".

But, let me say it, considering how long it's taking for the last
update to reach Extras, it may take months, for the optified package,
to reach the consumers.

Aniello

2009/12/17 Andre Klapper <[hidden email]>:

> Am Donnerstag, den 17.12.2009, 11:16 +0100 schrieb [hidden email]:
>> Hi, it seems that more users than wished are still reaching the rootfs
>> limit only with the Nokia and Extras repos installed.
>> Also, if you know or suspect other causes for Extras users filling
>> their rootfs partitions please let us know.
>
> Also see Uwe's list at
> http://wiki.maemo.org/Opt_Problem/Non-Optified_packages plus the bug
> reports with "non-optified" keyword:
> https://bugs.maemo.org/buglist.cgi?keywords=non-optified
>
> andre
>
> --
> Andre Klapper (maemo.org bugmaster)
>
> _______________________________________________
> maemo-developers mailing list
> [hidden email]
> https://lists.maemo.org/mailman/listinfo/maemo-developers
>



--
anidel
_______________________________________________
maemo-developers mailing list
[hidden email]
https://lists.maemo.org/mailman/listinfo/maemo-developers
Reply | Threaded
Open this post in threaded view
|

Re: Pushing optified Python libs

Anderson Lizardo-3
In reply to this post by Quim Gil
On Thu, Dec 17, 2009 at 6:16 AM,  <[hidden email]> wrote:
> Hi, it seems that more users than wished are still reaching the rootfs limit only with the Nokia and Extras repos installed.
>
> Most (all?) Apps in Extras seem to be correctly optified, so one possibility is that the problem relies in the libraries.
>
> Sorry if I have missed something but I remember a post mentioning that optified libraries were available in Extras-devel but still not Extras. if true, and if the libraries have been tested, would there be a possibility to push them to Extras forcing an update in the background?

I wonder how the push from extras-testing to extras works? I read
http://wiki.maemo.org/Extras_repository_process_definition but I don't
see a final resolution on this.

And while at it, how to we know whether the optified libraries are
"tested enough" to be uploaded? For the PyMaemo optified packages we
got a few success reports (and a few bug reports, that we believe are
fixed now), but given that there is no extras-testing queue for these
package I'm not sure how the QA works in this case (I even opened a
thread on this, see "QA process for 'middleware' ..."

> Also, if you know or suspect other causes for Extras users filling their rootfs partitions please let us know.

If the user has Python applications and only extras enabled, the fact
of the optified packages not being in extras is most probably the
cause.

Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
_______________________________________________
maemo-developers mailing list
[hidden email]
https://lists.maemo.org/mailman/listinfo/maemo-developers
Reply | Threaded
Open this post in threaded view
|

Re: Pushing optified Python libs

Matti Airas
In reply to this post by Quim Gil
Hi Quim,

Gil Quim (Nokia-D/Helsinki) wrote:

> Sorry if I have missed something but I remember a post mentioning
> that optified libraries were available in Extras-devel but still not
> Extras. if true, and if the libraries have been tested, would there
> be a possibility to push them to Extras forcing an update in the
> background?

You're correct with Python in extras not being optified. I've been
wringing my hands on that not happening yet because I thought (along
with the rest of the PyMaemo team) that it was only due to confusion in
how non-user packages should be promoted.

However, we've just hit a major regression caused by an attempted Python
optification bugfix with failed QA. Although I believe the issue has
been solved now, I think we need to sit on the package in extras-devel
for a week or so before pushing it to testing (Python optification is
implemented in a manner that optification bugs may cause a systemic
failure in the whole Python subsystem).

Cheers,

Matti Airas

_______________________________________________
maemo-developers mailing list
[hidden email]
https://lists.maemo.org/mailman/listinfo/maemo-developers
Reply | Threaded
Open this post in threaded view
|

Re: Pushing optified Python libs

mikkov
In reply to this post by Quim Gil
> would there be a possibility to push them to Extras forcing an update in the background?

It may be again noted that pushing library updates for end users is practically impossible because Application Manager doesn't update packages which are not in user/* category.

--
Mikko Vartiainen
_______________________________________________
maemo-developers mailing list
[hidden email]
https://lists.maemo.org/mailman/listinfo/maemo-developers
Reply | Threaded
Open this post in threaded view
|

Re: Pushing optified Python libs

Anderson Lizardo-3
On Thu, Dec 17, 2009 at 5:43 PM, Mikko Vartiainen <[hidden email]> wrote:
>> would there be a possibility to push them to Extras forcing an update in the background?
>
> It may be again noted that pushing library updates for end users is practically impossible because Application Manager doesn't update packages which are not in user/* category.

BTW, I tested putting packages in user/hidden category and indeed
(albeit autobuilder complaining about the unknown category)
application manager recognizes new versions of packages in that
category (showing the update notification and allowing to upgrade).

Not sure if it is the best/correct solution though, as it looks like
undocumented.

Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
_______________________________________________
maemo-developers mailing list
[hidden email]
https://lists.maemo.org/mailman/listinfo/maemo-developers
Reply | Threaded
Open this post in threaded view
|

Re: Pushing optified Python libs

mikkov

> BTW, I tested putting packages in user/hidden category and indeed
> (albeit autobuilder complaining about the unknown category)
> application manager recognizes new versions of packages in that
> category (showing the update notification and allowing to upgrade).

Pymaemo-optify shows up for me at Other category as would any other non-standard user/ category. So I would say that user/hidden is not (yet?) implemented.

> Not sure if it is the best/correct solution though, as it looks like
> undocumented.

Hidden category doesn't help pushing pymaemo-optify updates for those users who don't have it already installed. But it can be used for pushing updates for packages which are not supposed to be visible in installable packages.

To get "normal" updates, all non user/* packages should be moved to user/hidden. Then I would wonder what's hidden category be good for when same behaviour would be achieved by simply updating all packages, no matter which category they are in. :)

--
Mikko Vartiainen


_______________________________________________
maemo-developers mailing list
[hidden email]
https://lists.maemo.org/mailman/listinfo/maemo-developers
Reply | Threaded
Open this post in threaded view
|

Re: Pushing optified Python libs

Niels Breet-3
In reply to this post by Quim Gil
On Fri, December 18, 2009 01:59, Anderson Lizardo wrote:

> On Thu, Dec 17, 2009 at 5:43 PM, Mikko Vartiainen <[hidden email]>
> wrote:
>
>>> would there be a possibility to push them to Extras forcing an update
>>> in the background?
>>
>> It may be again noted that pushing library updates for end users is
>> practically impossible because Application Manager doesn't update
>> packages which are not in user/* category.
>
> BTW, I tested putting packages in user/hidden category and indeed
> (albeit autobuilder complaining about the unknown category)
> application manager recognizes new versions of packages in that category
> (showing the update notification and allowing to upgrade).

This is bad manner and utterly evil.

User _applications_ should be in user/* categories. (Basically everything
you want the end-user to see and be able to uninstall) Everything else
should never be in user.

Please don't expose end users to the mess of uninstalling python because
they need space, while they still have python apps in their device. This
will only confuse them.

The whole library updating might be painful, but don't misuse the user
categories for this.

The easiest way to update the python libraries for now is to either
promote an application depending (>= the new version) or ping me to
manually push them through.

The advantage of having an app use the new version is that you get testing
of the dependencies too. Yes, updates won't be instant then, but this way
they have the 10 day quarantine too.

>
> Regards,
> --
> Anderson Lizardo
> OpenBossa Labs - INdT
> Manaus - Brazil

--
Niels Breet
maemo.org webmaster


_______________________________________________
maemo-developers mailing list
[hidden email]
https://lists.maemo.org/mailman/listinfo/maemo-developers
Reply | Threaded
Open this post in threaded view
|

Re: Pushing optified Python libs

Dave Neary
Hi,

Niels Breet wrote:
> User _applications_ should be in user/* categories. (Basically everything
> you want the end-user to see and be able to uninstall) Everything else
> should never be in user.

Where should it go? The packaging policy[1] only explicitly mentions
user/* sections, as does the wiki [2]. As best I can tell we should be
using Debian policy for everything that doesn't appear in the
application manager.

Here's section 2.2 of the packaging policy [1]:

2.2 Sections

Packages are grouped into sections as in Debian, but SHOULD NOT specify
a category in the segment part. (However it is not a bug if a package
taken from Debian and made available in maemo retains its “contrib” or
“non-free” segment.)

Instead maemo defines a user segment for controlling visibility in the
Application Manager. Packages that are intended to be visible in the
Application Manager MUST belong to the user segment, and packages that
are not intended to be visible (such as libraries and other
dependencies) MUST NOT belong to that segment.

[snip]

Packages not in the user segment SHOULD use the sections listed in the
Debian Policy
(http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections).


Looking at that page:

The Debian archive maintainers provide the authoritative list of
sections. At present, they are: admin, cli-mono, comm, database, devel,
debug, doc, editors, electronics, embedded, fonts, games, gnome,
graphics, gnu-r, gnustep, hamradio, haskell, httpd, interpreters, java,
kde, kernel, libs, libdevel, lisp, localization, mail, math, misc, net,
news, ocaml, oldlibs, otherosfs, perl, php, python, ruby, science,
shells, sound, tex, text, utils, vcs, video, web, x11, xfce, zope.

So "python" looks like a promising section.

And I found this document that looks useful for Python packagers, but
doesn't mention sections at all:
http://www.debian.org/doc/packaging-manuals/python-policy/

Is there a list of the standard Python sections & sub-sections somewhere?

> The easiest way to update the python libraries for now is to either
> promote an application depending (>= the new version) or ping me to
> manually push them through.

A library maintainer currently has no way to vote for/test a library &
have it get promoted by the normal QA process? I can imagine, for
example, a situation where a library gets updated, fixing a lot of bugs,
but the application depending on it doesn't bump the depends version. In
that case, what should the maintainer do? Ping you to have it promoted?

Cheers,
Dave.

[1] http://maemo.org/forrest-images/pdf/maemo-policy.pdf
[2] http://wiki.maemo.org/Maemo_packaging

--
maemo.org docsmaster
Email: [hidden email]
Jabber: [hidden email]

_______________________________________________
maemo-developers mailing list
[hidden email]
https://lists.maemo.org/mailman/listinfo/maemo-developers
Reply | Threaded
Open this post in threaded view
|

Re: Pushing optified Python libs

mikkov
In reply to this post by Niels Breet-3
> This is bad manner and utterly evil.
>
> User _applications_ should be in user/* categories. (Basically everything
> you want the end-user to see and be able to uninstall) Everything else
> should never be in user.
 
There is or is going to be user/hidden category

http://maemo.gitorious.org/hildon-application-manager/mainline/commit/f7b4542b3c77114a95e2803708cec8eeff3409f7

> The easiest way to update the python libraries for now is to either
> promote an application depending (>= the new version) or ping me to
> manually push them through.

It's the "easiest" way but at the same time it's
practically impossible or at least very hard for
such libraries as python.

This thread is a good reference for python updating difficulties
http://maemo.org/community/maemo-developers/qa_process_for_non_user--packages_and_how_application_manager_handles_upgrades-was-re-extras-devel--extras-testing_auto-promotion_not_working/

--
Mikko Vartiainen
_______________________________________________
maemo-developers mailing list
[hidden email]
https://lists.maemo.org/mailman/listinfo/maemo-developers
Reply | Threaded
Open this post in threaded view
|

Re: Pushing optified Python libs

mikkov
In reply to this post by Matti Airas
> However, we've just hit a major regression caused by an attempted Python
> optification bugfix with failed QA. Although I believe the issue has
> been solved now, I think we need to sit on the package in extras-devel
> for a week or so before pushing it to testing (Python optification is
> implemented in a manner that optification bugs may cause a systemic
> failure in the whole Python subsystem).

Pymaemo-optify 0.2 has landed Extras (or at least Downloads)
http://maemo.org/downloads/product/Maemo5/pymaemo-optify/

What happened here and how it's even possible?
_______________________________________________
maemo-developers mailing list
[hidden email]
https://lists.maemo.org/mailman/listinfo/maemo-developers
Reply | Threaded
Open this post in threaded view
|

RE: Pushing optified Python libs

Matti Airas
From Mikko Vartiainen [[hidden email]]:

> Pymaemo-optify 0.2 has landed Extras (or at least Downloads)
> http://maemo.org/downloads/product/Maemo5/pymaemo-optify/

Yep, Lizardo gave me a heads-up today (to my great astonishment).

> What happened here and how it's even possible?

We have no idea.

The resulting situation is quite awkward because 0.2 is somewhat untested version which was pushed accidentally to extras-testing. It should work for new installs but WILL break the whole Python installation if the user has 0.1 already installed from extras-testing or extras-devel and the user manually upgrades the package (which, ironically, HAM normally won't do). Lizardo has prepared version 0.4 (in extras-devel) which should have both installs and upgrades working but the upgrade scenarios aren't yet tested systematically enough for the new version to be deployed in extras. We now have to rush the testing to have something prepared in case 0.2 appears to be broken even for new installs.

I'm leaning on the opinion that we could sit on the current 0.2 version in any case, the benefits of having an optified Python version are great enough and that version was more or less tested for new installs. Lizardo can correct me if I'm wrong. He can also provide further details if required.

So, while it's extremely nice to finally have an optified Python in extras, next time please verify with the respective team before doing manual promotions of packages.

Cheers,

ma.


_______________________________________________
maemo-developers mailing list
[hidden email]
https://lists.maemo.org/mailman/listinfo/maemo-developers
Reply | Threaded
Open this post in threaded view
|

Re: Pushing optified Python libs

Niels Breet-3
In reply to this post by Dave Neary
On Fri, December 18, 2009 15:28, Dave Neary wrote:

> Hi,
>
>
> Niels Breet wrote:
>
>> User _applications_ should be in user/* categories. (Basically
>> everything you want the end-user to see and be able to uninstall)
>> Everything else
>> should never be in user.
>
> Where should it go? The packaging policy[1] only explicitly mentions
> user/* sections, as does the wiki [2]. As best I can tell we should be
> using Debian policy for everything that doesn't appear in the application
> manager.
>
> Here's section 2.2 of the packaging policy [1]:
>
>
> 2.2 Sections
>
>
> Packages are grouped into sections as in Debian, but SHOULD NOT specify
> a category in the segment part. (However it is not a bug if a package taken
> from Debian and made available in maemo retains its “contrib” or
> “non-free” segment.)
>
>
> Instead maemo defines a user segment for controlling visibility in the
> Application Manager. Packages that are intended to be visible in the
> Application Manager MUST belong to the user segment, and packages that
> are not intended to be visible (such as libraries and other dependencies)
> MUST NOT belong to that segment.
>
>
> [snip]
>
>
> Packages not in the user segment SHOULD use the sections listed in the
> Debian Policy
> (http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections).
>
>
>
> Looking at that page:
>
>
> The Debian archive maintainers provide the authoritative list of
> sections. At present, they are: admin, cli-mono, comm, database, devel,
> debug, doc, editors, electronics, embedded, fonts, games, gnome, graphics,
> gnu-r, gnustep, hamradio, haskell, httpd, interpreters, java, kde, kernel,
> libs, libdevel, lisp, localization, mail, math, misc, net, news, ocaml,
> oldlibs, otherosfs, perl, php, python, ruby, science, shells, sound, tex,
> text, utils, vcs, video, web, x11, xfce, zope.
>
> So "python" looks like a promising section.
>

Yes, python is ok. As long as real end users don't see it in the
Application Manager.

Developers have python available in SDK and also know how to handle either
red-pill or apt-get.

>
>> The easiest way to update the python libraries for now is to either
>> promote an application depending (>= the new version) or ping me to
>> manually push them through.
>
> A library maintainer currently has no way to vote for/test a library &
> have it get promoted by the normal QA process? I can imagine, for example,
> a situation where a library gets updated, fixing a lot of bugs, but the
> application depending on it doesn't bump the depends version. In that
> case, what should the maintainer do? Ping you to have it promoted?
>

We've discussed this at the summit and came to the conclusion that we
basically need library maintainers. Another conclusion was that we needed
to discuss that further :)

Until we have the repository/library maintainer track sorted out, I
propose to follow these steps:

- If you are not listed as maintainer for an existing library and still
want to have it updated, contact the maintainer. If the maintainer is not
available or doesn't respond, mail to maemo-developers list.
*** Please don't update a library maintained by anybody else without
consent or public discussion***
- The maintainer/author uploads new version, checks if applications using
the app still work correctly.
- Ping me or mail -developers to push it through manually to testing. Here
we can all do a final test to see if nothing breaks.

I hope to have an interface for maintainers available in the beginning of
the new year.

This doesn't solve the problem that the Application manager doesn't update
libraries on their own though. That problem should be a separate
discussion.

> Cheers,
> Dave.
>
>
> [1] http://maemo.org/forrest-images/pdf/maemo-policy.pdf
> [2] http://wiki.maemo.org/Maemo_packaging
>
>
> --
> maemo.org docsmaster Email: [hidden email]
> Jabber: [hidden email]
>

--
Niels Breet
maemo.org webmaster


_______________________________________________
maemo-developers mailing list
[hidden email]
https://lists.maemo.org/mailman/listinfo/maemo-developers
Reply | Threaded
Open this post in threaded view
|

Re: Pushing optified Python libs

Niels Breet-3
In reply to this post by mikkov
On Fri, December 18, 2009 15:49, Mikko Vartiainen wrote:

>> However, we've just hit a major regression caused by an attempted
>> Python
>> optification bugfix with failed QA. Although I believe the issue has been
>> solved now, I think we need to sit on the package in extras-devel for a
>> week or so before pushing it to testing (Python optification is
>> implemented in a manner that optification bugs may cause a systemic
>> failure in the whole Python subsystem).
>
> Pymaemo-optify 0.2 has landed Extras (or at least Downloads)
> http://maemo.org/downloads/product/Maemo5/pymaemo-optify/
>
>
> What happened here and how it's even possible?

An application depending on python2.5-minimal got promoted to Extras from
-testing. Python2.5-minimal depends on pymaemo-optify, so that got
promoted too.

The question is why it shows up in Downloads as it is in section devel and
not in a user/* section. This is something I need to check more closely as
that seems to be a bug in the importer for Downloads.

--
Niels Breet
maemo.org webmaster


_______________________________________________
maemo-developers mailing list
[hidden email]
https://lists.maemo.org/mailman/listinfo/maemo-developers
Reply | Threaded
Open this post in threaded view
|

Re: Pushing optified Python libs

mikkov
On Fri, Dec 18, 2009 at 9:44 PM, Niels Breet <[hidden email]> wrote:
> An application depending on python2.5-minimal got promoted to Extras from
> -testing. Python2.5-minimal depends on pymaemo-optify, so that got
> promoted too.

Then it was Panucci though a series of dependencies that I can't quite
follow. I would have assumed that it wouldn't trigger updating of
python2.5-minimal.

> The question is why it shows up in Downloads as it is in section devel and
> not in a user/* section. This is something I need to check more closely as
> that seems to be a bug in the importer for Downloads.

Seems very similar than "XB-Maemo-Upgrade-Description is displayed way
too soon"  https://bugs.maemo.org/show_bug.cgi?id=6187

--
Mikko Vartiainen
_______________________________________________
maemo-developers mailing list
[hidden email]
https://lists.maemo.org/mailman/listinfo/maemo-developers
Reply | Threaded
Open this post in threaded view
|

Re: Pushing optified Python libs

Anderson Lizardo-3
In reply to this post by Niels Breet-3
On Fri, Dec 18, 2009 at 3:14 PM, Niels Breet <[hidden email]> wrote:
> Developers have python available in SDK and also know how to handle either
> red-pill or apt-get.

So, If I understand correctly, developers (even newcomers to the Maemo
world) should have extras-devel enabled on their devices for
development? Otherwise they would not have access to e.g. bindings
that are not used yet (and thus did not get promoted to extras).

I did this on a N900 and I saw many updates appearing for applications
not related to my development work. Most probably the new versions
were coming from extras-devel. Wouldn't that be confusing to new N900
developers?

> Until we have the repository/library maintainer track sorted out, I
> propose to follow these steps:
>
> - If you are not listed as maintainer for an existing library and still
> want to have it updated, contact the maintainer. If the maintainer is not
> available or doesn't respond, mail to maemo-developers list.
> *** Please don't update a library maintained by anybody else without
> consent or public discussion***
> - The maintainer/author uploads new version, checks if applications using
> the app still work correctly.
> - Ping me or mail -developers to push it through manually to testing. Here
> we can all do a final test to see if nothing breaks.

Sounds reasonable IMHO. Is that also the case if some package needs to
be "demoted" from extras-testing?

> I hope to have an interface for maintainers available in the beginning of
> the new year.

Good to hear that! Will it be not restricted just to user/* applications?

> This doesn't solve the problem that the Application manager doesn't update
> libraries on their own though. That problem should be a separate
> discussion.

Agreed. One thing I noticed is that removing some application using
Application Manager does not remove its unused dependencies (e.g. like
"apt-get autoremove" does). So the device tends to get filled up with
unused dependencies, with no user-friendly way of removing them. Did
anyone else notice this?

Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
_______________________________________________
maemo-developers mailing list
[hidden email]
https://lists.maemo.org/mailman/listinfo/maemo-developers
Reply | Threaded
Open this post in threaded view
|

Re: Pushing optified Python libs

Anderson Lizardo-3
In reply to this post by mikkov
On Fri, Dec 18, 2009 at 4:00 PM, Mikko Vartiainen <[hidden email]> wrote:
> On Fri, Dec 18, 2009 at 9:44 PM, Niels Breet <[hidden email]> wrote:
>> The question is why it shows up in Downloads as it is in section devel and
>> not in a user/* section. This is something I need to check more closely as
>> that seems to be a bug in the importer for Downloads.
>
> Seems very similar than "XB-Maemo-Upgrade-Description is displayed way
> too soon"  https://bugs.maemo.org/show_bug.cgi?id=6187

Maybe it is getting the information from the wrong version of the
package (e.g. the one from extras-devel). The version auto promoted to
extras (0.2) does not have the Section: user/hidden.

Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
_______________________________________________
maemo-developers mailing list
[hidden email]
https://lists.maemo.org/mailman/listinfo/maemo-developers
Reply | Threaded
Open this post in threaded view
|

VS: Re: Pushing optified Python libs

Timo Härkönen
In reply to this post by Anderson Lizardo-3

Hi

----- Alkuperäinen viesti -----


> On Fri, Dec 18, 2009 at 3:14 PM, Niels Breet <[hidden email]> wrote:
> > Developers have python available in SDK and also know how to handle either
> > red-pill or apt-get.
>
> So, If I understand correctly, developers (even newcomers to the Maemo
> world) should have extras-devel enabled on their devices for
> development? Otherwise they would not have access to e.g. bindings
> that are not used yet (and thus did not get promoted to extras).
>
> I did this on a N900 and I saw many updates appearing for applications
> not related to my development work. Most probably the new versions
> were coming from extras-devel. Wouldn't that be confusing to new N900
> developers?

Yes. I usually have extras-devel disabled to avoid unwanted updates. I enable it only when I need to install something from there. Somekind of option to ignore updates from selected repositories would be usefull. Is something like this currently possible?


>
> > Until we have the repository/library maintainer track sorted out, I
> > propose to follow these steps:
> >
> > - If you are not listed as maintainer for an existing library and still
> > want to have it updated, contact the maintainer. If the maintainer is not
> > available or doesn't respond, mail to maemo-developers list.
> > *** Please don't update a library maintained by anybody else without
> > consent or public discussion***
> > - The maintainer/author uploads new version, checks if applications using
> > the app still work correctly.
> > - Ping me or mail -developers to push it through manually to testing. Here
> > we can all do a final test to see if nothing breaks.
>
> Sounds reasonable IMHO. Is that also the case if some package needs to
> be "demoted" from extras-testing?
>
> > I hope to have an interface for maintainers available in the beginning of
> > the new year.
>
> Good to hear that! Will it be not restricted just to user/* applications?
>
> > This doesn't solve the problem that the Application manager doesn't update
> > libraries on their own though. That problem should be a separate
> > discussion.
>
> Agreed. One thing I noticed is that removing some application using
> Application Manager does not remove its unused dependencies (e.g. like
> "apt-get autoremove" does). So the device tends to get filled up with
> unused dependencies, with no user-friendly way of removing them. Did
> anyone else notice this?


BR

-Timo


_______________________________________________
maemo-developers mailing list
[hidden email]
https://lists.maemo.org/mailman/listinfo/maemo-developers
Reply | Threaded
Open this post in threaded view
|

Re: Pushing optified Python libs

Anderson Lizardo-3
In reply to this post by Niels Breet-3
On Fri, Dec 18, 2009 at 2:44 PM, Niels Breet <[hidden email]> wrote:
> The question is why it shows up in Downloads as it is in section devel and
> not in a user/* section. This is something I need to check more closely as
> that seems to be a bug in the importer for Downloads.

is it possible to remove it manually from Downloads? it is getting
comments there as it were an application. And even if the Maintainer
field is set correctly, the package interface insists on using either
the uploader or the last changelog entry as maintainer.

Thanks,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
_______________________________________________
maemo-developers mailing list
[hidden email]
https://lists.maemo.org/mailman/listinfo/maemo-developers