mobility July 2010

mobility@lists.fedoraproject.org

6 participants
9 discussions

MeeGo Status update
by Peter Robinson 28 Jul '10

28 Jul '10

Hi All, Just a quick note. Over the last couple of days I've done quite a bit of work to get the current MeeGo packages in Fedora cleaned up so we can get a live image built. There is a nightly [1] from last night that is most parts of MeeGo 1.0.1. There are still a few packages that are missing so the milage may vary and I'm going to be doing some testing over the weekend. We still have some packages needed to complete MeeGo 1 in F-14. Once F-14 is branched I plan to get MeeGo 1.1 dev into the new rawhide so that it can move forward in 2 parts. There's some testing that I want to do with a relatively stable interface using systemd / quick login etc in MeeGo 1.0 in F-14 and in F-15 I want to do all the package renames and get the dep hell there sorted out before building the resulting packages and getting it tagged into F-14 hopefully in time for the beta where the two lots of testing can be merged for a final 1.1 F-14 release. Help needed! Peter [1] http://alt.fedoraproject.org/pub/alt/nightly-composes/meego/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=538447

1 0

MeeGo 1.1 Release Plan
by Chen Lei 26 Jul '10

26 Jul '10

>From http://wiki.meego.com/Release_Engineering/Plans/1.1 2010-08-19--2010-08-25 Beta: Feature freeze, Bugfixing for most of features, Possibility to integrate features that are late 2010-10-21--2010-10-27 GA, RTW: MeeGo 1.1 Release for Core, Netbooks, Handsets, ... (General availability, release to web) Regrads, Chen Lei

1 0

Re: Naming issue for meego 1.0 related packages
by Peter Robinson 16 Jul '10

16 Jul '10

On Fri, Jul 9, 2010 at 2:21 PM, Chen Lei <supercyper1(a)gmail.com> wrote: > 2010/7/9 pbrobinson(a)gmail.com <pbrobinson(a)gmail.com>: >> Hi Chen, >> >> As I'm the MeeGo maintainer let me outline my thoughts and reasoning >> behind my MeeGo strategy. >> >>> I intend to review two meego-related packages[1][2], but I'm confused >>> with which package name will be more appropiate. >>> [1]https://bugzilla.redhat.com/show_bug.cgi?id=610794 >>> [2]https://bugzilla.redhat.com/show_bug.cgi?id=610842 >> >> All moblin packages will be renamed to meego. Whether that is all >> during the F-14 timeframe or isn't completed until F-15 I'm not sure >> yet. All new packages I intend to call meego as I don't see the point >> in reviewing them now and renaming them in a month or two, possibly >> less. >> >>> The packager is determined to package meego 1.0 packages for F14 which >>> means we need to package old versions instead of latest upstream >>> version. Meego 1.0 still use old package name moblin-* the same as >>> moblin 2.1 for all of its packages. Howerver, upstream renamed all of >>> those package to meego-* in meego 1.1 which will be released in Oct. >>> 2010. >> >> No I'm not determined to package MeeGo 1.0 for F-14. So please don't >> change what I have said. In the short term I plan to package MeeGo 1.0 >> for the alpha so that there is something for people to start testing >> with. There's currently very little in the MeeGo 1.1 release and >> there's a lot of churn due to the renaming upstream which is and will >> cause us problems. So once F-14 alpha is out and the F-14/rawhide >> branch has taken place I can then do all the rename breakage in F-15 >> and get the 1.1 package deps shake up stabilized there while people >> can continue to test some stuff in MeeGo 1.0 in the F-14 branch where >> its hopefully slightly stable and some of the other things that have >> changed from Moblin 2.1 to 1.0 have changed and can be closely tested. >> Once MeeGo 1.1 in F-15 rawhide is OK and looking OK I can then build >> and tag it quickly and simply into F-14. >> >>> I want to ask if it's appropiate to use new package name meego-* >>> instead of moblin-* for meego 1.0 packages. >>> >>> e.g. >>> meego-panel-devices >>> Upstream uses moblin-panel-devices[3] in meego 1.0, but renamed it to >>> meego-panel-devices[4] in meego 1.1. If we intend to package version >>> 0.1.30, then which name will be more appropriate? >>> >>> [3]http://repo.meego.com/MeeGo/releases/1.0/netbook/repos/source/moblin-pane… >>> [4]http://repo.meego.com/MeeGo/builds/1.0.80/1.0.80.9.20100706.1/netbook/rep… >>> >>> Note: >>> It seems upstream will not rename those packages to meego-* in meego 1.0. >> >> No, but that was due to time and QA in the lead up to release. We >> don't need to follow 100% what they do and I don't see the point in 2 >> package reviews for the one package in less than a month. The upstream >> git even for the 1.0 release is called meego, its clearly stated in >> the upstream the direction the package names are going so I don't see >> what the issue is. >> >> Peter >> -- > > Sounds reasonable to me, but the version you packaged actually are > still moblin-* [1] instead of meego-* regardless of what repo names > they use, it's unacceptable under most circumstance. I don't believe it is unacceptable and you didn't read my points above. > [1]http://pbrobinson.fedorapeople.org/meego-panel-zones.spec > %files -f moblin-panel-zones.lang > %defattr(-,root,root,-) > %doc COPYING README > %{_libexecdir}/moblin-panel-zones > %{_datadir}/dbus-1/services/org.moblin.UX.Shell.Panels.zones.service > %{_datadir}/mutter-moblin/panels/moblin-panel-zones.desktop > %{_datadir}/moblin-panel-zones/ > > > Another thing confused me is why you want to use git snapshot instead > of upstream tarball in src.rpm. It seems like you rely on the git SHA1 > on the particular tags in the meego 1.0 branch, but it's very hard to > track upstream in this way. I'm using the tags from git due to the lack of properly URL referenceable tar file releases as required by the packaging guidelines. git is actually generally easier to follow and I'm working with upstream to ensure consistent tagging. Scripts help there. > e.g. meego-panel-zones > > The latest tag in meego 1.0 branch is 0.1.18[2] which is also the > version you choose to package. Howerver, upstream repo version for > meego 1.0 is 0.1.19[3] which don't have a tag in meego 1.0 branch. > Things become much worse if we look at meego 1.1, the latest git tag > is also 0.1.18[4], but upstream repo already update meego-panel-zones > to 0.2.1[5]. Well 0.1.19 came out just now as part of the 1.0.1 update. 0.1.18 was part of the 1.0 gold release. > Historically, moblin released tarballs for its packages in public git > repo, but memeo and meego don't release tarball publicly. I think we > have to use tarballs in the src.rpm for meego specfic packages. Moblin provided auto tar files from git. In later times they added proper tar releases too. They haven't rules out adding either/or back. Peter

4 7

consistent tarball md5 [was: Naming issue for meego 1.0 related packages]
by Paul Morgan 16 Jul '10

16 Jul '10

On Fri, Jul 16, 2010 at 06:26, Chen Lei <supercyper1(a)gmail.com> wrote: > 2010/7/11 pbrobinson(a)gmail.com <pbrobinson(a)gmail.com>: >> >> I don't agree with the easier, and the releases are all built on tags. >> >> Well someone will have to get the policy added to the packaging >> guidelines. There's guidelines for using VC repos but not for using >> tar files from other distros source packages. >> >> Peter > > It seems no guideline forbid us to use tarballs extracted from > upstream repo. I think using git repo for meego packages have more > harm than benefit, because the most important feature for rpm is > people can validate the md5sum of the source tarball easily. Unless > special case we can't find a way to get reliable souce tarballs, I > think it's better to use tarballs rather than get source files from > VCS. Using git is not harmful, and it's certainly possible to get tarballs with consistent md5 from git based on tagged releases. Case in point: http://github.com/dgoodwin/tito Among its features: * Create reliable tar.gz's with consistent checksums from any tag. * Build packages off an "upstream" git repository, where modifications in the "downstream" git repository will be applied as a patch in the source rpm. I'm not suggesting that the project maintainer use tito; I'm saying that tito can create tarballs with consistent md5's from any tag in the repo. The project maintainer chooses what he feels works best for his project, all things considered. -paul > Meego repo is reliable place to get source tarballs, they also > have bugzilla against those modules and they are the upstream. Also, > it seems some meego packages don't have a public VCS(e.g. fennec-qt) > or public VCS is not active currently(e.g. scim-panel-vkb-gtk[1]). > Meego 1.0 use scim-panel-vkb-gtk 0.1.7, meego 1.1 use 0.1.8. but the > latest version in the git repo is 0.1.6. > > [1]https://bugzilla.redhat.com/show_bug.cgi?id=615047 > > Regards, > Chen Lei > _______________________________________________ > mini mailing list > mini(a)lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/mini > -- Paul Morgan

1 0

Re: Naming issue for meego 1.0 related packages
by Peter Robinson 09 Jul '10

09 Jul '10

Hi Chen, As I'm the MeeGo maintainer let me outline my thoughts and reasoning behind my MeeGo strategy. > I intend to review two meego-related packages[1][2], but I'm confused > with which package name will be more appropiate. > [1]https://bugzilla.redhat.com/show_bug.cgi?id=610794 > [2]https://bugzilla.redhat.com/show_bug.cgi?id=610842 All moblin packages will be renamed to meego. Whether that is all during the F-14 timeframe or isn't completed until F-15 I'm not sure yet. All new packages I intend to call meego as I don't see the point in reviewing them now and renaming them in a month or two, possibly less. > The packager is determined to package meego 1.0 packages for F14 which > means we need to package old versions instead of latest upstream > version. Meego 1.0 still use old package name moblin-* the same as > moblin 2.1 for all of its packages. Howerver, upstream renamed all of > those package to meego-* in meego 1.1 which will be released in Oct. > 2010. No I'm not determined to package MeeGo 1.0 for F-14. So please don't change what I have said. In the short term I plan to package MeeGo 1.0 for the alpha so that there is something for people to start testing with. There's currently very little in the MeeGo 1.1 release and there's a lot of churn due to the renaming upstream which is and will cause us problems. So once F-14 alpha is out and the F-14/rawhide branch has taken place I can then do all the rename breakage in F-15 and get the 1.1 package deps shake up stabilized there while people can continue to test some stuff in MeeGo 1.0 in the F-14 branch where its hopefully slightly stable and some of the other things that have changed from Moblin 2.1 to 1.0 have changed and can be closely tested. Once MeeGo 1.1 in F-15 rawhide is OK and looking OK I can then build and tag it quickly and simply into F-14. > I want to ask if it's appropiate to use new package name meego-* > instead of moblin-* for meego 1.0 packages. > > e.g. > meego-panel-devices > Upstream uses moblin-panel-devices[3] in meego 1.0, but renamed it to > meego-panel-devices[4] in meego 1.1. If we intend to package version > 0.1.30, then which name will be more appropriate? > > [3]http://repo.meego.com/MeeGo/releases/1.0/netbook/repos/source/moblin-pane… > [4]http://repo.meego.com/MeeGo/builds/1.0.80/1.0.80.9.20100706.1/netbook/rep… > > Note: > It seems upstream will not rename those packages to meego-* in meego 1.0. No, but that was due to time and QA in the lead up to release. We don't need to follow 100% what they do and I don't see the point in 2 package reviews for the one package in less than a month. The upstream git even for the 1.0 release is called meego, its clearly stated in the upstream the direction the package names are going so I don't see what the problem is. Hopefully the outline above will give you further insight into my strategy. Regards, Peter BTW this discussion is better off for the mini list as I mentioned previously so I'ved added it as a CC Peter

1 0

Re: Naming issue for meego 1.0 related packages
by Peter Robinson 09 Jul '10

09 Jul '10

1 0

Packaging suggestions for meego related packages
by Chen Lei 06 Jul '10

06 Jul '10

Hi all, I have some suggestions about packaging meego related packages. 1. meego 1.0 vs meego 1.1 Since the release date of meego 1.1 is very close to the final release of F14, Peter determined to target meego 1.0 for F14 final. Howerver, I still suggest to consider backporting meego 1.1 for F14, shortly after branching F14 from Rawhide, I think we can push all meego related 1.1 packages to rawhide, if those packages works fine, we can push them to F14. In fact, meego 1.1 is much more close to F14 than meego 1.0, also meego 1.1(1.0.80) snapshot images already works on my netbook. 2.Source files Moblin project released their tarballs in public git repo[1], unfortunately meego don't release any tarballs in its public git repo[2]. So we have two choice to get sources from upstream: (1) git archive from meego git repo; (2) extracting tarballs from SRPM in repo.meego.com. [1]http://git.moblin.org [2]http://meego.gitorious.org I highly suggest to use source from SRPM for those reasons: (1) it'll be easier for reviewers to check the md5sum of those sources; (2)we need additional BR(e.g, autoconf automake) to build source files from git repo;(3)extracting tarballs from SRPM is much easier than git acheive from git repo;(4) meego public git repo is not so open, some source files extracted from SRPMS are even newer than from git HEAD. 3. Naming issue for meego 1.0 It seems like meego 1.0 still use old package name - moblin-* for most of its packages, most of those packages are already is the repo of Fedora, only a few of them need packaging. We have two choice for those new packages[1][2]: (1)keeping consistence with upstream, and use moblin-* for those packages; (2) use meego-* for those packages as meego 1.1. Personally, I'd like choice (1) because upstream SRPMs for meego 1.0 still use old names, the source files from meego 1.0 branch in git repo still use moblin instead of meego. IMHO, saving a few moblin-* namespace in pkgdb makes no sense. [1]https://bugzilla.redhat.com/show_bug.cgi?id=610794 [2]https://bugzilla.redhat.com/show_bug.cgi?id=610842 Any other ideas in this suggestions? I'd like to see more discussions on packaging meego reletead packages. Regards, Chen Lei

1 0

Re: MeeGo in Fedora 14
by Adam Miller 03 Jul '10

03 Jul '10

I will be sure to fire up some testing on my netbook in the near future with the netbook UX. I am actually highly interested in the tablet pieces as more and more ARM (and soon Atom) based tablets are rolling out to market. The Fedora ARM port is gaining a bit of steam here lately and I think having a fully functional tablet environment to complment it might help it along as well as muster up some more following for the Fedora Mini efforts in general as Intel pushes their next generation Atom SoC devices. -AdamM (From Android) On Jun 30, 2010 1:56 PM, "Peter Robinson" <pbrobinson(a)gmail.com> wrote: Hi All, In a follow up to my last commnt it looks like we've got the majority of the OK for the legal side of things. The majority of the core meego 1.0 netbook UX is now in rawhide. Over the next couple of weeks the remainder should be updated. I've been primarily waiting for the legal side of things to push forward and I've been travelling alot over the last 6 weeks since F-13 hit, I'm moving house tomorrow and after that it will be full steam ahead. As for 1.0 vs 1.1 I'm currently aiming for 1.0 for F-14 in the short term as I'm not sure how 'open' upstream is going to be but I'll be watching closely and if its at all doable we'll head for 1.1 if it looks to be a reasonable target closer to the time so watch this space. I'm also keeping an eye on the 'tablet' side of things having seen some cool demos online so if your interested in that let me know on the list. Once I have the remainder of the core into rawhide I'm going to start review mini and MeeGo maintainence more so if your interested in helping out open up the discussion on this tread as it seems there's going to more than enough types of meego interfaces to share about :-) Actually I want more discussion on the list.... its been way too quite! Cheers, Peter _______________________________________________ mini mailing list mini(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/mini

3 3

Moblin Spin rename/resubmission as MeeGo Spin?
by Adam Miller 02 Jul '10

02 Jul '10

Hello all, This is somewhat of a side note/email in response to the email from Peter about MeeGo 1.0 netbook UX being in rawhide now[0]. From what I understand the currently nightly spin composes are from rawhide and I was wondering if we should start looking into what process is needed to migrate from Moblin to MeeGo as a spin? Will it require a new submission or simply a name change? etc... This might have already been taken care of and if so then I'd like to move forward to find out what we need to do in order to hack up the kickstart in order to start firing off nightly builds of MeeGo for easy testing. Thoughts, comments, questions, updates? All welcome! :) -AdamM [0] http://lists.fedoraproject.org/pipermail/mini/2010-June/000028.html -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

mobility July 2010