MeeGo Status update
by Peter Robinson
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
13 years, 8 months
Re: Naming issue for meego 1.0 related packages
by Peter Robinson
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-pa...
>>> [4]http://repo.meego.com/MeeGo/builds/1.0.80/1.0.80.9.20100706.1/netbook/r...
>>>
>>> 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
13 years, 9 months
consistent tarball md5 [was: Naming issue for meego 1.0 related packages]
by Paul Morgan
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
13 years, 9 months
Re: Naming issue for meego 1.0 related packages
by Peter Robinson
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-pa...
> [4]http://repo.meego.com/MeeGo/builds/1.0.80/1.0.80.9.20100706.1/netbook/r...
>
> 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
13 years, 9 months
Re: Naming issue for meego 1.0 related packages
by Peter Robinson
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-pa...
> [4]http://repo.meego.com/MeeGo/builds/1.0.80/1.0.80.9.20100706.1/netbook/r...
>
> 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
13 years, 9 months
Packaging suggestions for meego related packages
by Chen Lei
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
13 years, 9 months
Re: MeeGo in Fedora 14
by Adam Miller
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
13 years, 9 months
Moblin Spin rename/resubmission as MeeGo Spin?
by Adam Miller
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
13 years, 9 months