testing upgrade

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

testing upgrade

monto
Hi,
first, i don't want to start a flame but i think that if everything is
quite noone will ever try to solve some problems.
I'm not talking about telephonic problems, i'm talking about upgrade.
I'm using shr testing as a daily phone, ok it's not "stable" but oe
works good, today, as usual i wrote "opkg update ; opkg upgrade" a lot o
things were upgraded, result? phone broken. No terminal, no usb
connection, no wifi, nothing so i've reflashed the phone. Not a real
problem for me, in 1h reisntalled everything, but that's not the way.
Someone should test and test and test the upgrades.
Modules need depmod, no icons, it was a known problem with the
shr-unstable, so what about a solution, no wifi (module i think), bluex
version change and installation conflicts....

So if you need a tester for the upgrade here i am, need a tester for
everything i'll be happy to help to avoid some bad upgrade like this
one.

This is obviously ihmo i like shr and i think it's a very good job so
i've told you that, to improve it.

Thanks a lot for your work!

Pietro


_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel
Reply | Threaded
Open this post in threaded view
|

Re: testing upgrade

monto
Il giorno sab, 18/04/2009 alle 01.09 +0200, Pietro "m0nt0" Montorfano ha
scritto:
> Hi,
> [snip]
> version change and installation conflicts....

Hem.... i got the WSOD with the new kernel, this is very very bad.

Bye!

Pietro


_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel
Reply | Threaded
Open this post in threaded view
|

Re: testing upgrade

Julien Cassignol
In reply to this post by monto
On Sat, Apr 18, 2009 at 1:09 AM, Pietro "m0nt0" Montorfano
<[hidden email]> wrote:

> Someone should test and test and test the upgrades.

Short, and simple: we didn't release. There is no way, with our
current work, that we're able to maintain the upgrade path. We simply
can't do that. When the release will be out, that will be another
thing, but now, we can't: too many renamings, upgrades, changes in the
way we build... We are going towards OE commital, but in order to do
that, we need to be sure that our basic recipes are rock solid and
properly made. That's why there are so many changes.

--
Julien Cassignol
http://www.ainulindale.net

_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel
Reply | Threaded
Open this post in threaded view
|

Re: testing upgrade

piratebab
In reply to this post by monto
I agree with you, the development cycle of SHR is different of the
debian system. SHR testing is not evoluting smoothly, but step by step.
I regret it, but it is the best way of working for the devs team.
The simplest solution could be as the "apt-get upgrade " solution: ask
the user if he agree to do the proposed update.
But this is an opkg improvement, not SHR.


Pietro "m0nt0" Montorfano a écrit :

> Hi,
> first, i don't want to start a flame but i think that if everything is
> quite noone will ever try to solve some problems.
> I'm not talking about telephonic problems, i'm talking about upgrade.
> I'm using shr testing as a daily phone, ok it's not "stable" but oe
> works good, today, as usual i wrote "opkg update ; opkg upgrade" a lot o
> things were upgraded, result? phone broken. No terminal, no usb
> connection, no wifi, nothing so i've reflashed the phone. Not a real
> problem for me, in 1h reisntalled everything, but that's not the way.
> Someone should test and test and test the upgrades.
> Modules need depmod, no icons, it was a known problem with the
> shr-unstable, so what about a solution, no wifi (module i think), bluex
> version change and installation conflicts....
>
> So if you need a tester for the upgrade here i am, need a tester for
> everything i'll be happy to help to avoid some bad upgrade like this
> one.
>
> This is obviously ihmo i like shr and i think it's a very good job so
> i've told you that, to improve it.
>
> Thanks a lot for your work!
>
> Pietro
>
>
> _______________________________________________
> Shr-devel mailing list
> [hidden email]
> http://lists.projects.openmoko.org/mailman/listinfo/shr-devel
>
>
>  


_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel
Reply | Threaded
Open this post in threaded view
|

Re: testing upgrade

monto
Il giorno sab, 18/04/2009 alle 08.38 +0200, piratebab ha scritto:
> I agree with you, the development cycle of SHR is different of the
> debian system. SHR testing is not evoluting smoothly, but step by step.
> I regret it, but it is the best way of working for the devs team.
> The simplest solution could be as the "apt-get upgrade " solution: ask
> the user if he agree to do the proposed update.
> But this is an opkg improvement, not SHR.

I know this, and i'm not saying that you should get a stable branch
rigth now, working with e17 is impossible to reach a stable branch,
everything is changing, it's the same with fso frameworkd and so on, i
don't pretend that, what i'm asking is to correct some upgrade known
bugs. The "missing icons" it was a known bug, if you upgrade a lot of
modules and change the kernel version (r2 to r3) a depmod is needed.
What i'm asking is just to pay some attention in the unstable to testing
update, if some bugs where fixed by installing e-wm-utils (if i remember
well), just make shr-task-base depends on it, not just putting some
packages from unstable to testing because this is leading a lot of
users, who use testing and update it daily or so, to have the same bugs
and problem of the unstable branch since last change, so 2 branch are
not so useful, just to have a bleeding edge branch like unstable, which
is updated daily and presents some small problems, and a more stable
branch like testing, which is updated twice a month and every update is
usually a reflash because there will be a lot of problems...
It will have more sense to provide some update to testing when a package
is working in unstable:
new package -> unstable -> testing
if there are big upgrades then provide a critical upgrade one by one,
eg:
illume upgrade, frameworkd upgrade and kernel upgrade then illume
upgrade, wait 2 days, frameworkd upgrade, wait 2 other days, kernel
upgrade.
This way if something borke something else you we can easily spot and
solve the problem.

Sorry for the long mail.

Bye!

Pietro


_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel
Reply | Threaded
Open this post in threaded view
|

testing upgrade

roby-2
On Sun, Apr 19, 2009 at 11:24 AM, Pietro "m0nt0" Montorfano
<[hidden email]> wrote:
> modules and change the kernel version (r2 to r3) a depmod is needed.
cannot we just tell to opkg to run the depmod ALWAYS? it would be a
bit slower but at least we would get rid of a problem..

> illume upgrade, frameworkd upgrade and kernel upgrade then illume
> upgrade, wait 2 days, frameworkd upgrade, wait 2 other days, kernel
> upgrade.
> This way if something borke something else you we can easily spot and
> solve the problem.
i agree with this, one update a day is far better than nothing for a
month and suddenly a big revolution... i think packages would
stabilize sooner..

--
roby



--
roby

_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel
Reply | Threaded
Open this post in threaded view
|

Re: testing upgrade

Mike Westerhof (mwester)
roby wrote:
> On Sun, Apr 19, 2009 at 11:24 AM, Pietro "m0nt0" Montorfano
> <[hidden email]> wrote:
>> modules and change the kernel version (r2 to r3) a depmod is needed.
> cannot we just tell to opkg to run the depmod ALWAYS? it would be a
> bit slower but at least we would get rid of a problem..

No.  You should never have to run depmod; if you do, there is a deeper
(and possibly very bad) problem.

Changing something to run depmod -a at boot automatically would just
mask other problems.

(The bug that caused this in the first place has been fixed now.)

Mike (mwester)

_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel
Reply | Threaded
Open this post in threaded view
|

Re: testing upgrade

Julien Cassignol
In reply to this post by roby-2
On Sun, Apr 19, 2009 at 6:54 PM, roby <[hidden email]> wrote:

> i agree with this, one update a day is far better than nothing for a
> month and suddenly a big revolution... i think packages would
> stabilize sooner..

There's no "big revolution". We did the work we were suposed to do:
work on package names & conventions in order to be able to commit them
to OE ASAP. That's what we did. Hence the name changes, some upgrade
breaks, etc. There's no solution to get around that.

--
Julien Cassignol
http://www.ainulindale.net

_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel
Reply | Threaded
Open this post in threaded view
|

Re: testing upgrade

Tilman Baumann

Julien Cassignol schrieb:

> On Sun, Apr 19, 2009 at 6:54 PM, roby <[hidden email]> wrote:
>
>> i agree with this, one update a day is far better than nothing for a
>> month and suddenly a big revolution... i think packages would
>> stabilize sooner..
>
> There's no "big revolution". We did the work we were suposed to do:
> work on package names & conventions in order to be able to commit them
> to OE ASAP. That's what we did. Hence the name changes, some upgrade
> breaks, etc. There's no solution to get around that.

opkg provides 'Provides, Conflicts and Replaces' flags.
I'm almost 100% sure this would have avoided all the latest problems.

Just my 2 Eurocents

--
MFG
 Tilman Baumann


_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel
Reply | Threaded
Open this post in threaded view
|

Re: testing upgrade

Julien Cassignol
On Mon, Apr 20, 2009 at 10:03 AM, Tilman Baumann <[hidden email]> wrote:

> opkg provides 'Provides, Conflicts and Replaces' flags.
> I'm almost 100% sure this would have avoided all the latest problems.

Nope, it wouldn't. If we *truly* would like to avoid these problems,
we could, of course, the problem is, it would take a huge amount of
time, and this is relevant only for stable release. I don't think we
have to focus on that now.

As we didn't release yet, things are not stabilized (name weren't, for
example). When we'll release, things won't be that way, you can trust
me on that.

--
Julien Cassignol
http://www.ainulindale.net

_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel