Re: App catalog (was Re: extras: autobuilders)
[...apologies for this very delayed reply...] Quim Gil <[EMAIL PROTECTED]> writes: > On Mon, 2007-11-12 at 20:16 +, ext Neil Jerram wrote: > >> There's an interesting meta-point, also. The current existence of the >> Application Catalog partly (largely?) reflects the fact that not all >> 3rd party apps are in extras. > > I see (almost?) no relation. Just to be clear, I guess I was assuming/describing my own preferred way of working - i.e. that if an application appears (following a refresh) in the Application Manager list, I would see no need, if I already knew what it was, to go and check it out in the App Catalog; I'd just install it using Application Manager. However, I can see now that the App Catalog can also have useful other purposes, for marketing and as a central point for accumulating feedback etc.; thanks for pointing that out. Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
App catalog (was Re: extras: autobuilders)
On Mon, 2007-11-12 at 20:16 +, ext Neil Jerram wrote: > There's an interesting meta-point, also. The current existence of the > Application Catalog partly (largely?) reflects the fact that not all > 3rd party apps are in extras. I see (almost?) no relation. I imagine centralized distros using web based catalogs to feature & promote their applications by letting users comment and rate where they can also download. > Perhaps if almost all apps were in > extras, and the AppManager UI was improved to cope better with large > numbers of available packages, there wouldn't be much need for the > Application Catalog any more? And what about users browsing the catalog with a normal PC, being or not owners of a tablet. The catalog is / should be a strong marketing tool for maemo applications, both for potential and actual maemo users. -- Quim Gil - http://maemo.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras: autobuilders
"Tim Teulings" <[EMAIL PROTECTED]> writes: > Hello! > >> 6) If it doesn't already exist, an entry in the Application Catalog is >>automatically created, including .install file(s) for all supported >>OSs. > > The relevant information must be available in the source/binary package. Well the information for a skeleton Application Catalog entry is already in the package, isn't it? In order to create a bit of HTML and a clickable .install file, all that is needed is the package name, short and long descriptions. >Also I'm not sure if thats worth the effort (or at least this does > not have highest priority). At least I would not put screen shots into > my package to get the application catalog entry build automatically ;-) Yes, definitely screenshots should not go into the package. In that case I guess it would be nice if the basic AppCatalog entry was autogenerated, and could then be enhanced by hand. There's an interesting meta-point, also. The current existence of the Application Catalog partly (largely?) reflects the fact that not all 3rd party apps are in extras. Perhaps if almost all apps were in extras, and the AppManager UI was improved to cope better with large numbers of available packages, there wouldn't be much need for the Application Catalog any more? Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras: autobuilders
On Saturday 10 November 2007 12:06:45 Tim Teulings wrote: > I'm also the developer of an "alpha-version" library. I would suggest in > this case to add for example the exact date as package version (e.g. > 0.1.20071110) and make all dependent packages dependent on exactly this > version. I know that all dependent packages then need an upload (with an > incremented package revision at least) with this new dependency to get > build again, but IMHO there is no way around. That's a good suggestion, although I also like the idea of being able to force a rebuild (without a new upload). But I guess this could be a second priority. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras: autobuilders
On Nov 12, 2007 11:01 AM, Simon Pickering <[EMAIL PROTECTED]> wrote: > [big snip] > > [...] Then we possibly come back to individuals adding some sort of > build recipe for each library they want (even though lots of them will > be trivial). > > Although having an email address of the person who 'ported' them would > allow error reporting, perhaps a better option here is to setup a > centralised mailing list specifically for these autobuilt packages and > let people submit their bug reports to that - this means that such > reports are out in the open (as is the source and the build recipes) > and would allow more than one person to contribute to any given package > (e.g. if someone is on holiday, or gets bored, etc.) Lots of good discussion, and it's validating the approach currently taken by mud-builder where this kind of thing is done as above. There are trivial recipes for compiling simple upstream libraries, the maintainer is set to a mailing list unless overridden etc. Perhaps it is just process defintiion and automation which unsuitable? I'd desperately love to hear opinions from anyone involved in other auto-builders, particularly in the Debian/Ubuntu world. But... then... I suppose we would generally for this thread. Cheers, Andrew -- Andrew Flegg -- mailto:[EMAIL PROTECTED] | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras: autobuilders
>>> - It feels reasonable to say that a project must have a garage page, >>> in order to use the auto-builder. >> >> What about the myriad libraries that will be added to build all the >> random apps we want? Would each of these need a Garage page or could >> they all be grouped under the same page? I imagine most of these will >> be simple modifications (if they even need that) of existing debian >> packages and therefore a Garage project is probably overkill, a >> maintainer's email address ought to be enough. > > Usually more than one project depend on some library, so if one project > has the "control" of that library, it might not be ideal - for example > library removal as unnecessary.. Booom.. other projects wont compile.. > > Separate projects for every library is too heavy. Maybe there could be a > project for shared libraries? Or even more I would like the idea that > the libraries would be there already waiting - the same way when I start > to devel on top of Debian - the need to go and make your own library > packages is quite minimal.It might be possible to autocompile most of > the Debian archive for Maemo. Then one could apt-get dependencies for > development or use. I quite agree. These libraries are the main thing I want from an autobuilder and if they could all be done automatically then that would be great, though I imagine there are too many to just compile every library for the platform, so some form of requesting a library would be needed. Then we possibly come back to individuals adding some sort of build recipe for each library they want (even though lots of them will be trivial). Although having an email address of the person who 'ported' them would allow error reporting, perhaps a better option here is to setup a centralised mailing list specifically for these autobuilt packages and let people submit their bug reports to that - this means that such reports are out in the open (as is the source and the build recipes) and would allow more than one person to contribute to any given package (e.g. if someone is on holiday, or gets bored, etc.) Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras: autobuilders
>> - It feels reasonable to say that a project must have a garage page, >> in order to use the auto-builder. > > What about the myriad libraries that will be added to build all the > random apps we want? Would each of these need a Garage page or could > they all be grouped under the same page? I imagine most of these will > be simple modifications (if they even need that) of existing debian > packages and therefore a Garage project is probably overkill, a > maintainer's email address ought to be enough. Usually more than one project depend on some library, so if one project has the "control" of that library, it might not be ideal - for example library removal as unnecessary.. Booom.. other projects wont compile.. Separate projects for every library is too heavy. Maybe there could be a project for shared libraries? Or even more I would like the idea that the libraries would be there already waiting - the same way when I start to devel on top of Debian - the need to go and make your own library packages is quite minimal.It might be possible to autocompile most of the Debian archive for Maemo. Then one could apt-get dependencies for development or use. -- VRe ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras: autobuilders
Hello! >> What about the myriad libraries that will be added to build all the >> random apps we want? Would each of these need a Garage page or could >> they all be grouped under the same page? I imagine most of these will >> be simple modifications (if they even need that) of existing debian >> packages and therefore a Garage project is probably overkill, a >> maintainer's email address ought to be enough. > > Good point. I take back my statement for now, then. (I quite liked > the idea of the auto-builder reporting build problems through a garage > bug tracker, though.) That was my question in another thread. How do I manage my garage project(s), if I have more than one but all closed bound together. I think we should allow to have multiple packages for the same project (thing of localization packages, too) and belonging to the same garage page. I also would find it useful to make tickets int he bug tracking system of that project page if building fails (error text then of course should clearly identify the package). This way we have some feedback if the problems was solved (ticket closed). This way we could also see if the maintainer has given up getting the package to run. We could also resume rebuild of the package after ticket was closed saving build resources. We should discuss if is *required* to have a garage package for pushing packages to the autobuilder. This way we have bug tracking, a more direct contact (even for teams)and (the potential for) a far more integrated and simpler system. And there is no real problem in creating a garage page only for packaging, isn't it? -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras: autobuilders
Hello! > 6) If it doesn't already exist, an entry in the Application Catalog is >automatically created, including .install file(s) for all supported >OSs. The relevant information must be available in the source/binary package. Also I'm not sure if thats worth the effort (or at least this does not have highest priority). At least I would not put screen shots into my package to get the application catalog entry build automatically ;-) -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras: autobuilders
Hello! > libraries until the APIs are more stable. This means that there are cases > where a dependency is updated where all the dependent packages need to be > rebuilt. > > Of course, this does not only apply in cases where library versioning is not > in use. Even in cases where libraries are correctly versioned there may be > some benefit (e.g. a performance benefit) in rebuilding a dependent > application. I'm also the developer of an "alpha-version" library. I would suggest in this case to add for example the exact date as package version (e.g. 0.1.20071110) and make all dependent packages dependent on exactly this version. I know that all dependent packages then need an upload (with an incremented package revision at least) with this new dependency to get build again, but IMHO there is no way around. -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras: autobuilders
Hello! > Levi Bard wrote: >>> [1] Is OS2007 support still useful? There are really only two platforms: OS >>> 2006 for 770 owners, and OS 2008 for N800/N810 owners. Maintaining OS >>> 2007 >>> support could be a pain for application authors. >> I would say that the two relevant platforms are OS2007 for 770 owners >> and OS2008 for N8[01]0 owners. I definitely have users of my applications that still have an 770 running OS 2006 (however I cannot give any percentage). -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras: autobuilders
Hello! I have collected (and reformulated a little bit) all suggestions up to now in the Wiki at: https://maemo.org/community/wiki/extrasrepositoryprocessdefinition/ I have divided the suggestions in to three groups: autobuilder, autotester and autostager (note that even with only one or two repositories the autostager can decide about "in" or "out") to keep the overview. Please check the page and assure that your suggestions are collected and correctly formulated (everybody can change!). If we collect more suggestions a separate page may be appropriate. -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras: autobuilders
Levi Bard wrote: >> [1] Is OS2007 support still useful? There are really only two platforms: OS >> 2006 for 770 owners, and OS 2008 for N800/N810 owners. Maintaining OS >> 2007 >> support could be a pain for application authors. > > I would say that the two relevant platforms are OS2007 for 770 owners > and OS2008 for N8[01]0 owners. > Hello all, I would like to comment on this. I consider myself more a user of maemo/IT than a developer, even though I have some applications of my own (not publicly available, at least not yet) and have described to maemo-developers for a few months now. I have one 770 and one N800 and I have bought one 770 to my farther. I do not have any interest in installing OS2007HE to 770 and my farther is probably never going to even know what a HE is. 770 with OS2006 is still good for what it was designed to be. We (I and my farther) use it for example for light web browsing and navigating (Navicore and Maemo Mapper). I believer that there are quite many users like us. Therefore OS2006 support is still needed. About OS2007 support I have a comment also. I read somewhere that all the applications must be recompiled for OS2008. I use Navicore on the N800 and I don't know if Navicore/Wayfinder will give a free upgrade to a OS2008 version. If they don't I will have to stick with OS2007. If this is the case, OS2007 would be needed. Julius ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras: autobuilders
On Nov 10, 2007 12:05 AM, Neil Jerram <[EMAIL PROTECTED]> wrote: > > Simon Pickering <[EMAIL PROTECTED]> writes: > > > > What about the myriad libraries that will be added to build all the > > random apps we want? Would each of these need a Garage page or could > > they all be grouped under the same page? I imagine most of these will > > be simple modifications (if they even need that) of existing debian > > packages and therefore a Garage project is probably overkill, a > > maintainer's email address ought to be enough. > > Good point. I take back my statement for now, then. (I quite liked > the idea of the auto-builder reporting build problems through a garage > bug tracker, though.) I think it's still got merit, though. It wouldn't be much harder to provide a URI field for reporting bugs for a package (possibly even in the control file so it could be used on a device post-install); that URI could be a mailto:, a Garage bug tracker or even a random Bugzilla reference. The auto-builder can then support any number of different bug trackers and report to the appropriate one. Cheers, Andrew -- Andrew Flegg -- mailto:[EMAIL PROTECTED] | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras: autobuilders
>> 8) Although I don't think anyone is suggesting that the autobuilder should >> be >> an autotester, it could at least install the generated packages into an >> environment that also has everything else already installed. > > What kind of conflicts are possible, though? One that I can think of > is: > > - library version 1.1 is built, and published to the repository > > - application1 is built, with Depends: library = 1.1; build is > successful, application1 is published, and the test-install passes > > - application2 needs library >= 1.2, so library 1.2 is uploaded and > built; does the system somehow know, at this point, that > application1 is now broken? > > Is this a valid problem, and/or are there other kinds of conflict? This is a problem that can/should be fixed, and should be discovered by the autobuilder. If application1 has "Depends: library = 1.1;" because an inexperienced package builder didn't know they should be using >=, that bug should be fixed. If library genuinely changed something in the 1.1 to 1.2 upgrade that breaks apps, and some apps need 1.1 while others need 1.2, there should be two packaged versions of library that don't conflict (lib-compat-1.1 and lib-1.2). Basically, if there are conflicts in the repo they're bad and the autobuilder should squeal about them. Thanks, Mike Lococo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras: autobuilders
Simon Pickering <[EMAIL PROTECTED]> writes: >> Then there are (probably obvious) things about the detailed operation >> of the above points, like automatically emailing the uploader if a >> package doesn't build. >> >> If possible, it might make sense for the interface to the auto-builder >> to be integrated into garage. >> >> - It feels reasonable to say that a project must have a garage page, >> in order to use the auto-builder. > > What about the myriad libraries that will be added to build all the > random apps we want? Would each of these need a Garage page or could > they all be grouped under the same page? I imagine most of these will > be simple modifications (if they even need that) of existing debian > packages and therefore a Garage project is probably overkill, a > maintainer's email address ought to be enough. Good point. I take back my statement for now, then. (I quite liked the idea of the auto-builder reporting build problems through a garage bug tracker, though.) Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras: autobuilders
> Then there are (probably obvious) things about the detailed operation > of the above points, like automatically emailing the uploader if a > package doesn't build. > > If possible, it might make sense for the interface to the auto-builder > to be integrated into garage. > > - It feels reasonable to say that a project must have a garage page, > in order to use the auto-builder. What about the myriad libraries that will be added to build all the random apps we want? Would each of these need a Garage page or could they all be grouped under the same page? I imagine most of these will be simple modifications (if they even need that) of existing debian packages and therefore a Garage project is probably overkill, a maintainer's email address ought to be enough. Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras: autobuilders
Graham Cobb <[EMAIL PROTECTED]> writes:
> I would add a few things to Andrew's list in the area of dependency
> management
> as this is a subject dear to my heart! GPE consists of 7 user visible
> applications comprising a total of 30 packages with complex dependencies
> between them plus some non-GPE dependencies not in the standard Nokia
> repositories (like libsoup and libsqlite0).
I'm not an expert on dependencies, but some comments anyway...
> 5) Dependency aware. At a minimum the build system needs to be dependency
> aware: for example if an application and a library dependency are both
> updated, build the dependency first and then the application.
Doesn't this just happen anyway? According to my understanding...
- If the library is a build-dependency of the application, and the
right version of the library hasn't been uploaded yet, the attempt
to build the application will bail out immediately. On the next
build timer pop, if the library has then been uploaded, the
application build will proceed.
(Perhaps uploading the library could cause the application's build
timer to pop early, but that's well into icing-on-the-cake
territory, not a basic need.)
- If the library is only a runtime dependency of the application, it
doesn't matter what order they are built in. But the auto-builder
should only publish the application into the repository once all its
runtime dependencies are already in the repository.
> 6) Dependency checking. One advantage of my current GPE build system is that
> every build starts in a clean environment. I know that the build doesn't
> depend on anything not listed as a dependency because it would fail if it
> did. This was one of the first problems I came across when I first started
> trying to build Maemo packages: I used a single scratchbox environment for
> all my development and lots of things had been installed over time: builds
> would be successful even though the list of build dependencies was incomplete
> and the resulting packages would have unexpected dependencies. So, the
> requirement would be to do builds in a clean environment where only the
> specified dependencies are loaded.
>
> There is an argument that says that dependency checking isn't the job of the
> autobuilder: its job is just to build and developers should be checking their
> dependencies themselves. But doing this would improve the quality of the
> packages (although not necessarily user-visible quality).
So, to be concrete, I think this means that the building algorithm has
to be something like this:
build(package)
{
for (each of package's build-dependencies)
{
build(dependency)
dpkg -i dependency-package.deb
}
dpkg-buildpackage(package)
}
main(uploaded_package)
{
start_from_base_tablet_os()
build(uploaded_package)
uninstall_all_installed_packages()
}
> 8) Although I don't think anyone is suggesting that the autobuilder should be
> an autotester, it could at least install the generated packages into an
> environment that also has everything else already installed. This would
> allow conflicts to be discovered; including conflicts that may never be
> noticed by the development community using extras-devel because no one has
> just the right combination installed. This could be a separate process I
> suppose: a tool which runs every night and just installs everything it finds
> in extras-devel into a clean scratchbox environment.
I like how this contrasts with the build algorithm: each uploaded
package is built in its own clean environment, but test-installed in
an "everything" environment.
What kind of conflicts are possible, though? One that I can think of
is:
- library version 1.1 is built, and published to the repository
- application1 is built, with Depends: library = 1.1; build is
successful, application1 is published, and the test-install passes
- application2 needs library >= 1.2, so library 1.2 is uploaded and
built; does the system somehow know, at this point, that
application1 is now broken?
Is this a valid problem, and/or are there other kinds of conflict?
Regards,
Neil
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras: autobuilders
"Andrew Flegg" <[EMAIL PROTECTED]> writes:
> 1) Simple ability to upload a source package(s).
> 2) Have that source package compiled on as many SDKs as possible (OS 2006, OS
>2007 and OS 2008 should be possible with some/most packages).
> 3) The ability to update a source package in a simple manner (triggering a
>recompile).
> 4) When a new SDK is released, everything should be recompiled and redeployed
>to extras-{devel,testing,...}.
These are the main points for me too, but in addition:
5) Subject to some automated measure of quality (maybe just successful
building), the built packages are automatically published into the
extras{-testing} repository.
6) If it doesn't already exist, an entry in the Application Catalog is
automatically created, including .install file(s) for all supported
OSs.
Then there are (probably obvious) things about the detailed operation
of the above points, like automatically emailing the uploader if a
package doesn't build.
If possible, it might make sense for the interface to the auto-builder
to be integrated into garage.
- It feels reasonable to say that a project must have a garage page,
in order to use the auto-builder.
- Instead of emailing the uploaded in case of build failure, the
auto-builder could submit a bug to the project's tracker instead.
- Garage could provide a convenience page for uploading a source
package to the auto-builder. For the benefit of people with lots of
projects, however, this probably should not be the _only_ uploading
interface; it would be necessary if something scriptable worked
also.
Regards,
Neil
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras: autobuilders
On Friday 09 November 2007 09:11:16 Andrew Flegg wrote:
> On Nov 9, 2007 8:34 AM, Mikhail Sobolev <[EMAIL PROTECTED]> wrote:
> > Let's create a separate thread about autobuilders.
> >
> > A simple question: what would you expect from an autobuilders?
>
> 1) Simple ability to upload a source package(s).
> 2) Have that source package compiled on as many SDKs as possible (OS 2006,
> OS 2007 and OS 2008 should be possible with some/most packages).
> 3) The ability to update a source package in a simple manner (triggering a
>recompile).
> 4) When a new SDK is released, everything should be recompiled and
> redeployed to extras-{devel,testing,...}.
>
> Ideally, anything which would appear in the Application Manager (ie:
> Section: user/...) should also be updated/auto-created in the
> downloads catalogue; but this is a nice to have.
I would add a few things to Andrew's list in the area of dependency management
as this is a subject dear to my heart! GPE consists of 7 user visible
applications comprising a total of 30 packages with complex dependencies
between them plus some non-GPE dependencies not in the standard Nokia
repositories (like libsoup and libsqlite0).
5) Dependency aware. At a minimum the build system needs to be dependency
aware: for example if an application and a library dependency are both
updated, build the dependency first and then the application.
6) Dependency checking. One advantage of my current GPE build system is that
every build starts in a clean environment. I know that the build doesn't
depend on anything not listed as a dependency because it would fail if it
did. This was one of the first problems I came across when I first started
trying to build Maemo packages: I used a single scratchbox environment for
all my development and lots of things had been installed over time: builds
would be successful even though the list of build dependencies was incomplete
and the resulting packages would have unexpected dependencies. So, the
requirement would be to do builds in a clean environment where only the
specified dependencies are loaded.
There is an argument that says that dependency checking isn't the job of the
autobuilder: its job is just to build and developers should be checking their
dependencies themselves. But doing this would improve the quality of the
packages (although not necessarily user-visible quality).
7) Forced rebuilds. One big problem is with libraries which are not actually
version-controlled. This is a fairly small problem with GPE today but there
are definitely other projects (OpenSync is certainly one) which consider
themselves in to be in an Alpha phase and don't want to start versioning
libraries until the APIs are more stable. This means that there are cases
where a dependency is updated where all the dependent packages need to be
rebuilt.
Of course, this does not only apply in cases where library versioning is not
in use. Even in cases where libraries are correctly versioned there may be
some benefit (e.g. a performance benefit) in rebuilding a dependent
application.
What this is really saying is that there needs to be a way to force rebuilding
a package even though it has not changed. And it would be useful to have
that also allow a shorthand of "all packages dependent on package foo".
8) Although I don't think anyone is suggesting that the autobuilder should be
an autotester, it could at least install the generated packages into an
environment that also has everything else already installed. This would
allow conflicts to be discovered; including conflicts that may never be
noticed by the development community using extras-devel because no one has
just the right combination installed. This could be a separate process I
suppose: a tool which runs every night and just installs everything it finds
in extras-devel into a clean scratchbox environment.
Graham
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras: autobuilders
> > A simple question: what would you expect from an autobuilders?
>
> 1) Simple ability to upload a source package(s).
> 2) Have that source package compiled on as many SDKs as possible (OS 2006, OS
>2007 and OS 2008 should be possible with some/most packages).
> 3) The ability to update a source package in a simple manner (triggering a
>recompile).
> 4) When a new SDK is released, everything should be recompiled and redeployed
>to extras-{devel,testing,...}.
>
> Ideally, anything which would appear in the Application Manager (ie:
> Section: user/...) should also be updated/auto-created in the
> downloads catalogue; but this is a nice to have.
I second all of this.
> [1] Is OS2007 support still useful? There are really only two platforms: OS
> 2006 for 770 owners, and OS 2008 for N800/N810 owners. Maintaining OS 2007
> support could be a pain for application authors.
I would say that the two relevant platforms are OS2007 for 770 owners
and OS2008 for N8[01]0 owners.
--
"Tak does not require that we think of Him, only that we think."
--Grag Bashfullsson
http://www.gnu.org/philosophy/shouldbefree.html
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras: autobuilders
On Nov 9, 2007 8:34 AM, Mikhail Sobolev <[EMAIL PROTECTED]> wrote:
>
> Let's create a separate thread about autobuilders.
>
> A simple question: what would you expect from an autobuilders?
1) Simple ability to upload a source package(s).
2) Have that source package compiled on as many SDKs as possible (OS 2006, OS
2007 and OS 2008 should be possible with some/most packages).
3) The ability to update a source package in a simple manner (triggering a
recompile).
4) When a new SDK is released, everything should be recompiled and redeployed
to extras-{devel,testing,...}.
Ideally, anything which would appear in the Application Manager (ie:
Section: user/...) should also be updated/auto-created in the
downloads catalogue; but this is a nice to have.
Tim Teulings wrote:
>
> What for example if we use
>
> http://mud-builder.garage.maemo.org/index.php
>
> instead? The author has planed to use it for rebuilding upstream
> packages but I think using it would give use more benefit than just
> switch to totally manually mode (which we already have). It has not much
> but at least more infrastructure. Can the author of mud please give his
> opinion on my silly idea :-)?
That'd be me :-)
mud's intended to be used for two things:
1) To easily create Maemo-compatible packages from upstream tarballs, debs,
subversion etc. Including the application of any Maemo-specific patches.
2) To provide a mechanism for autobuilding all the packages and uploading
them to extras.
(1) is an ongoing task, but it's basically useful for this.
(2) has been started (you can compile all the mud packages in one
operation, for example); however it's more of a process issue. Without
an investment in infrastructure, very few people have the 3 platforms
installed[1] and my initial attempts at uploading them to extras
failed (and then I got side tracked with improving (1)).
There's also the point that many of the packages at the moment are
still a bit rough and ready, so an extras-testing in which less
polished apps could be put would definitely help here.
Primarily, the reason mud-builder isn't regularly uploading to extras
is one of process rather than technology. I would be perfectly happy
to finish (or accept a patch to finish) the uploading-to-extras bit,
and then build all the packages for Chinook. Someone else could then
build them for Bora, and another Gregale. It just requires some
organisation.
For a full-blown, central, Maemo autobuilder; there are mass
autobuilders already in-place for deb-based systems, used by both
Debian and Ubuntu. These are much too big for the scale at which mud
is aimed, however for a real Maemo auto-builder they could be perfect:
http://buildd.debian.org/
http://www.debian.org/devel/buildd/
Presumably these should run within Scratchbox relatively easily; but
I've not checked.
Cheers,
Andrew
[1] Is OS2007 support still useful? There are really only two platforms: OS
2006 for 770 owners, and OS 2008 for N800/N810 owners. Maintaining OS 2007
support could be a pain for application authors.
--
Andrew Flegg -- mailto:[EMAIL PROTECTED] | http://www.bleb.org/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
extras: autobuilders
Hi Let's create a separate thread about autobuilders. A simple question: what would you expect from an autobuilders? -- Misha signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
