Re: [maemo-developers] extras repository
On Thu, 2006-12-07 at 13:14 +0200, Marius Vollmer wrote: Hmm, careful here. We have to think about the relationships between distributions as well, such as what happens when you change your /etc/apt/sources.list and then do apt-get dist-upgrade. Also, the point of unstable and testing is that package migrate _as_binaries_ from one to the other based on certain criteria. (Sardine and herring are past that point already, I think. Herring is actually already the new stable and in an ideal world would be named bora.) Isn't Bora supposed to be SDK release name and Herring is a code name for HAF development branch (more stable than Sardine). If so, wouldn't it be incorrect to call current Herring as Bora? SDK is more than HAF. Sorry about my pedantic nature in some cases :) Sincerely, -- Miko Nieminen [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] extras repository
On Thu, Dec 07, 2006 at 02:07:27AM +0200, ext Ferenc Szekely wrote: ext Marius Vollmer wrote: We have to setup an intelligent build environment. The rough plan for this is: -get a descent hardware -install Scratchbox 1.x -setup sbuild together with our existing queue-manager (no DAK for now) If all is done then the package_maintainers/developers don't have to bother with compiling their sw for the various maemo releases. They only need to upload the signed Debian source package(s) to the current extras queue, like some of you do it today. The build environment should be clever to spot the problems and send reports to the package_maintainer/developer in case an uploaded source does not build. The cause of the build failure can be anything from an error in the code, error in the Debian specific files to a missing build dependency. Upon successful compilation the queue-manager will install the package to the archive and inform all of us (RSS feed, mailing list, whatever). I think for the time being we will skip checking if the newly installed package have all its runtime dependencies in the same archive. The ultimate goal (as Marius stated) is to have self contained repositories. So let's go for it, but let's take one step at a time ;) Timeline? Well, if this looks sane to you, then a testing environment could be established still this year (I am always optimistic ;). Any comments on this proposal? Hi Ferenc, Looks good to me. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: [maemo-developers] extras repository
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Daniel Stone Sent: 07 December, 2006 12:00 To: ext Ferenc Szekely Cc: maemo-developers Subject: Re: [maemo-developers] extras repository On Thu, Dec 07, 2006 at 02:07:27AM +0200, ext Ferenc Szekely wrote: ext Marius Vollmer wrote: We have to setup an intelligent build environment. The rough plan for this is: -get a descent hardware -install Scratchbox 1.x -setup sbuild together with our existing queue-manager (no DAK for now) If all is done then the package_maintainers/developers don't have to bother with compiling their sw for the various maemo releases. They only need to upload the signed Debian source package(s) to the current extras queue, like some of you do it today. The build environment should be clever to spot the problems and send reports to the package_maintainer/developer in case an uploaded source does not build. The cause of the build failure can be anything from an error in the code, error in the Debian specific files to a missing build dependency. Upon successful compilation the queue-manager will install the package to the archive and inform all of us (RSS feed, mailing list, whatever). I think for the time being we will skip checking if the newly installed package have all its runtime dependencies in the same archive. The ultimate goal (as Marius stated) is to have self contained repositories. So let's go for it, but let's take one step at a time ;) Timeline? Well, if this looks sane to you, then a testing environment could be established still this year (I am always optimistic ;). Any comments on this proposal? Hi Ferenc, Looks good to me. Cheers, Daniel How does it handle the extras components without source code? E.g. (bad example) Canola? Sources will not come but why not having it in the extras in future? Br, --jakub ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] extras repository
How does it handle the extras components without source code? E.g. (bad example) Canola? Sources will not come but why not having it in the extras in future? good point. my proposal is that extras is meant only for open source software. we can have a non-free component in each repo for canola and co. Br, --jakub br, ferenc ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] extras repository
ext Ferenc Szekely [EMAIL PROTECTED] writes: My proposal about the next steps: We have to setup an intelligent build environment. The rough plan for this is: -get a descent hardware -install Scratchbox 1.x -setup sbuild together with our existing queue-manager (no DAK for now) If all is done then the package_maintainers/developers don't have to bother with compiling their sw for the various maemo releases. They only need to upload the signed Debian source package(s) to the current extras queue, like some of you do it today. Hmm, careful here. We have to think about the relationships between distributions as well, such as what happens when you change your /etc/apt/sources.list and then do apt-get dist-upgrade. Also, the point of unstable and testing is that package migrate _as_binaries_ from one to the other based on certain criteria. (Sardine and herring are past that point already, I think. Herring is actually already the new stable and in an ideal world would be named bora.) Thus, maemo distributions should probably not be considered as parallel universes that never meet. Thus, all maemo distributions share a single package/version namespace. If both mistral and scirocco contain a foo_1_armel.deb file, then these two files should be bit-identical. On the server, there would be one maemo pool/ with all the maemo packages, and the dists/ would pick from that single pool/. (Likewise, there is a Debian namespace, and a Ubuntu namespace, and combining packages from these different namespaces is simply not supported.) Compiling a source package separately for each distribution will thus be problematic since we end up with same-named packages that can differ widely. But since it is not easy right now for the average user to follow distribution changes, and our distro landscape is a bit messed up anyway, people will want to provide their software for many distributions, not just for 'unstable'. I think it would be best for package maintainers to branch explicitly for this. E.g., if a maintainer normally releases his/her packages for scirocco, but wants to put a new version into mistral, he/she should branch the last version of the package that is in mistral. The version number in scirocco should be higher than the one in mistral. Maybe we should come up with a standard convention for how to do this, and maybe we can support it semi-automatically in the queue manager. I think for the time being we will skip checking if the newly installed package have all its runtime dependencies in the same archive. Yes, that should work just fine. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] extras repository
On Thursday 07 December 2006 11:43, Ferenc Szekely wrote: How does it handle the extras components without source code? E.g. (bad example) Canola? Sources will not come but why not having it in the extras in future? good point. my proposal is that extras is meant only for open source software. we can have a non-free component in each repo for canola and co. my opinion is that free software must be uploaded with source code package and build-depends must be in the repository. just follow debian guidelines, they have been working for years non-free software should go to a non-free component. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] extras repository
On Thursday 07 December 2006 12:14, Marius Vollmer wrote: [...] Compiling a source package separately for each distribution will thus be problematic since we end up with same-named packages that can differ widely. definitely yes But since it is not easy right now for the average user to follow distribution changes, and our distro landscape is a bit messed up anyway, people will want to provide their software for many distributions, not just for 'unstable'. for people who want bleding edge apps in stable distribuitions we could provide something like backports.org I think it would be best for package maintainers to branch explicitly for this. E.g., if a maintainer normally releases his/her packages for scirocco, but wants to put a new version into mistral, he/she should branch the last version of the package that is in mistral. The version number in scirocco should be higher than the one in mistral. Maybe we should come up with a standard convention for how to do this, and maybe we can support it semi-automatically in the queue manager. i think the best way to have high quality packages and apps and not to go in a mess of depends is to build and upload to unstable (devel branch) and as apps are being tested automatically go into testing and later a stable branch. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] extras repository
ext Jorge Salamero Sanz [EMAIL PROTECTED] writes: i think the best way to have high quality packages and apps and not to go in a mess of depends is to build and upload to unstable (devel branch) and as apps are being tested automatically go into testing and later a stable branch. I agree, but I am afraid we can't set this up and running smoothly any time soon. Until it becomes unnecessary, I think we need to explicitely plan for allowing people to make packages for a number of distributions. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] extras repository
ext Marius Vollmer wrote: ext Carlos Guerreiro [EMAIL PROTECTED] writes: Yeah. That's the way to go: proper archive management with something like DAK (we'll look into that at least for sardine and herring once there's some time) and a build system to go with it. I think we are more in need of a clue than in need of proper tools. :-) Absolutely correct! I read Marius email [1] at least 5-6 times, and I wanted to keep almost all the sentences in my reply too. But just to return back to the topic let me update you about the situation: snip The distributions would be divided into components, and extras would simply be one of those components. I agree. The maemo distros must have a fine grained component breakdown and to start with I second Marius and propose to add 'extras' to each of our distros: -mistral extras -- currently the only one available :( -scirocco extras -- the next one to implement -sardine extras -- comes later (or should this be done 1st?) -herring extras -- after sardine perhaps My proposal about the next steps: We have to setup an intelligent build environment. The rough plan for this is: -get a descent hardware -install Scratchbox 1.x -setup sbuild together with our existing queue-manager (no DAK for now) If all is done then the package_maintainers/developers don't have to bother with compiling their sw for the various maemo releases. They only need to upload the signed Debian source package(s) to the current extras queue, like some of you do it today. The build environment should be clever to spot the problems and send reports to the package_maintainer/developer in case an uploaded source does not build. The cause of the build failure can be anything from an error in the code, error in the Debian specific files to a missing build dependency. Upon successful compilation the queue-manager will install the package to the archive and inform all of us (RSS feed, mailing list, whatever). I think for the time being we will skip checking if the newly installed package have all its runtime dependencies in the same archive. The ultimate goal (as Marius stated) is to have self contained repositories. So let's go for it, but let's take one step at a time ;) Timeline? Well, if this looks sane to you, then a testing environment could be established still this year (I am always optimistic ;). Any comments on this proposal? The existing 'Tableteer' catalogue would turn into a component as well (but it might continue to be hosted in a different way than extras.) Yes, I will suggest that to the Tableteer owners. However I do not think that the content of Tableteer will be built by the build system I drafted above, because we got no sources from there :( Cheers, Ferenc [1]http://maemo.org/pipermail/maemo-developers/2006-November/006480.html ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] extras repository
ext Carlos Guerreiro [EMAIL PROTECTED] writes: Yeah. That's the way to go: proper archive management with something like DAK (we'll look into that at least for sardine and herring once there's some time) and a build system to go with it. I think we are more in need of a clue than in need of proper tools. :-) Please allow me to ramble a bit: Just deploying DAK doesn't automatically give you a sensible repository layout or distribution landscape. Actually, without knowing too much about DAK, it might be that having to wrestle with DAK itself will distract us and make it harder to see clearly where we actually want to go. (Hopefully I am wrong, the real Dakkers please correct me.) So, what would a sensible distribution landscape be? I don't have the experience to be authoritative here, but I think Ferenc is well on the right way. First, we should be talking about distributions and theirs components, not so much about repositories. [ Distributions are things like mistral, scirocco, sardine, herring; components are things like main, free, non-free, extras; repositories are things like http://repository.maemo.org/, http://catalogue.tableteer.nokia.com/ ] Then, the thing to realise is that we have two ways of looking at what is going on, and they tug at each other: on the one side we have the 'traditional' model of releasing a monolothic OS image and a matching monolithic SDK; this is how it looks to a lot of people inside Nokia, I think. On the other side is the 'traditional' Debian model of using evolving repositories of packages where the packages are deployed in the 'same' environment as they are developed, and the repositories are the means of deploying new stuff; this is what people expect to be happening when they see Scratchbox and apt/dpkg being used for maemo. The situation where the mistral distribution is supported for the SDK but not for the device is a good example: this situation looks perfectly alright from the OS image + SDK point of view, but having the thing break when you configure mistral on your device was a big surprise for people who had the one environment view. In my opinion, the one environment development model is vastly better than the OS image + SDK model, assuming that we can make it work. And we _can_ make it work: the device and the OS running on it are fully capable of being a development environment, there should be no problem getting GCC running on it, etc. The device just is too slow and has too little memory to be a nice development environment. Enter Scratchbox: it's not an emulator to test the final software, but it's an emulator for the development part of the environment on the device. So I think we should be heading towards the one environment model. The sardine distribution is already there, and the rest is quite close. I think we can actually copy the Debian model mostly verbatim, with unstable for integrating significant changes, testing to represent the most recent release candidate for the next release, and stable for maintenance of the last release. Roughly speaking, sardine would be unstable, herring is the first attempt at a distribution in testing state, scirocco is the current stable and mistral is the stable release before scirocco. One important point is that releases (that are 'stable') can evolve: maintenance would be done by putting a new version of a package into stable. Another important point is that distributions are designed to be self-contained and all-encompassing: all packages whatsoever that are meant to be used _with_ a certain distribution should be _in_ that distribution. That would include all 3rd party applications listed on the Applications Catalogue wiki pages. The distributions would be divided into components, and extras would simply be one of those components. The existing 'Tableteer' catalogue would turn into a component as well (but it might continue to be hosted in a different way than extras.) The proprietary software that is added to a meamo distribution to make the complete IT OS would also just be a component of the distributions. Ideally, this component will also be served from a public repository, but maybe that is not possible. It should be frowned upon for people to run their own repositories. The only accepted way to distribute packages for maemo devices would be to put them into one of the repositories on maemo.org. This allows the community to maintain them collectively. In the ideal world, the Application Manaher would not have a Application Catalogues dialog at all; it would only have a Select components dialog. [ There could also be a Select distribution dialog and once a new release has been made of the IT OS, people might choose to use it to select that new release and then the Check for updates view would let them do the upgrade. (UI-wise it might be better to not put that functionality into the Application Manager, granted.) ]
Re: [maemo-developers] extras repository
On Wed, Nov 29, 2006 at 12:25:54PM +0200, Marius Vollmer wrote: Please allow me to ramble a bit: snip the very coherent proposal +1 Marius Gedminas -- Never trust a smiling Gates. signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] extras repository
As for something real I would go with Murray and others: let's use more components. And in order to help developers and package maintainers, build-bots would really help. I'm glad Carlos is taking care of it. Well, I'm looking at that for sardine and herring, let's see what actually can be done and how generally it can be applied to Maemo ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] extras repository
On Mon, 2006-11-27 at 20:12:24 +0200, ext Marius Gedminas wrote: Would it be possible to do it somewhat like the way Debian/Ubuntu does it: 1. Maintainers upload Debian source packages. In Debian maintaiers upload source and at least binaries for one arch:any or arch:all. In Ubuntu it's source only uploads. 2. Autobuilders build binary packages for each repository and send emails to maintainers if there are errors. The buildd does not send any mail, that's the job of the buildd admin, which checks the logs and files appropriate bug reports, or requeues the build if it was a transient failiure, or sets Dep-Waits etc... Even if there are no autobuilders I would still want to enforce the requirement for having proper Debian source packages for everything that is distributed from Garage. That'd be good, yes. regards, guillem ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] extras repository
I know there is good reason for that (so everybody can rebuild it) but this puts additional burden to package maintainers. I just uploaded scummvm binary deb but have to remove it if this is requirement. I don't have time to package also tremor, libmad and limbpeg so you can rebuild it properly. Also scummvm build process currently crashes with internal compiler error in Kyrandia engine and one file must be build with different compiler flags by hand. I know this is specific issue (which will probably go away with next compiler) but still there are the dependencies and others may have other reasons why rebuilding directly from source doesn't work or isn't easy. I have a similar issue with xmame. It relies on semi-extensive makefile customization for each arch/cpu/set of prefs, and it would be less than fun to script this for an automated build. -- Tcsh: Now with higher FPS! http://www.gnu.org/philosophy/shouldbefree.html ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] extras repository
ext Murray Cumming wrote: On Tue, 2006-11-28 at 00:58 +0200, Carlos Guerreiro wrote: ne question: Which version of gtk-- to use and where to get it from (packaged)? libsigc++, glibmm, and gtkmm are already in extras. The packages just need to be rebuilt for sardine. They need to be updated too to the latest source versions, but we can take care of this, if you like. The preferred way for the sardine robot is to build from source (tagged releases in SVN). So, one or more projects in garage with the right source versions for these components would be ideal, pretty much like what already exists for hildon-fmmm and hildon-widgetsmm. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] extras repository
On Tue, 2006-11-28 at 09:17 -0600, Levi Bard wrote: I know there is good reason for that (so everybody can rebuild it) but this puts additional burden to package maintainers. I just uploaded scummvm binary deb but have to remove it if this is requirement. I don't have time to package also tremor, libmad and limbpeg so you can rebuild it properly. Also scummvm build process currently crashes with internal compiler error in Kyrandia engine and one file must be build with different compiler flags by hand. I know this is specific issue (which will probably go away with next compiler) but still there are the dependencies and others may have other reasons why rebuilding directly from source doesn't work or isn't easy. I have a similar issue with xmame. It relies on semi-extensive makefile customization for each arch/cpu/set of prefs, and it would be less than fun to script this for an automated build. Yet, Ubuntu packages it. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] extras repository
I have a similar issue with xmame. It relies on semi-extensive makefile customization for each arch/cpu/set of prefs, and it would be less than fun to script this for an automated build. Yet, Ubuntu packages it. Ubuntu packages a much newer version (which I didn't use because the binary is 20MB larger with little appreciable difference in functionality), with which either the debian or the ubuntu maintainer has endured the pain of scripting the build. -- Tcsh: Now with higher FPS! http://www.gnu.org/philosophy/shouldbefree.html ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] extras repository
On Tue, 2006-11-28 at 17:42 +0200, Carlos Guerreiro wrote: libsigc++, glibmm, and gtkmm are already in extras. The packages just need to be rebuilt for sardine. They need to be updated too to the latest source versions, but we can take care of this, if you like. The preferred way for the sardine robot is to build from source (tagged releases in SVN). So, one or more projects in garage with the right source versions for these components would be ideal, pretty much like what already exists for hildon-fmmm and hildon-widgetsmm. I'd rather not fork gtkmm's source just so it can be packaged, but I will if you really need it. Alternatively, you should find what you need here: http://www.openismus.com/temp/sardine_packages/ -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] extras repository
ext Murray Cumming wrote: On Tue, 2006-11-28 at 17:42 +0200, Carlos Guerreiro wrote: libsigc++, glibmm, and gtkmm are already in extras. The packages just need to be rebuilt for sardine. They need to be updated too to the latest source versions, but we can take care of this, if you like. The preferred way for the sardine robot is to build from source (tagged releases in SVN). So, one or more projects in garage with the right source versions for these components would be ideal, pretty much like what already exists for hildon-fmmm and hildon-widgetsmm. I'd rather not fork gtkmm's source just so it can be packaged, but I will if you really need it. Well, I don't really see it as forking since no independent development is expected or desired, but that's a matter of definition I suppose. Alternatively, you should find what you need here: http://www.openismus.com/temp/sardine_packages/ An alternative is to point to robot to the debian source packages. The robot has half-baked functionality for this, that I could finalize. I will look into this to see how much work would be involved and then get back to this. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] extras repository
Hello, I think it would be time to think about the extras repository a little bit. Those who are not familiar with extras please find some info on the ExtrasRepository [1] wiki page. Those who are interested in extras and have a few minutes please read on: We have launched this service during mistral (maemo 2.0) and the primary goal was to offer a common place for developers to store and redistribute their applications. The initial idea also included that we would like that maemo hackers settle down with their projects at garage.maemo.org. We thought extras will help to spread the word about maemo as well as help developers to reach a wider audience for their applications. The idea was not too bad, I would say, but we have to revise it now. Right now we reached a point when a single extras repository might not be suitable to handle all the needs. We have several stable distros: 1.0 (compatible with IT OS2005); mistral (version 2.0; works with IT OS 2006), scirocco (version 2.1; works with IT OS 2006). Then we have sardine, which is meant for the leading edge application framework components. It is supposed to help those who want to follow the daily maemo development and want to keep their apps really up-to-date. Carlos and his team is also working hard on an other repository that is called herring [2]. The main intention here to integrate the stable components of sardine into a single, self contained repository. Here comes the dilemma: I am hacking on a maemo application using the mistral (2.0) baseline and SDK. I'd like to wrap up my release and share it with the rest of the world. Shall I upload it to extras? Well, sounds good, since extras came with mistral. But what about other developers? Will it compile using the scirocco SDK? How about sardine? I have no clue, but unfortunately I have no time to test it now... To cut the long story short I think we need to come up with a solution that is logical, clear and sort of sustainable in the long run. One idea is to have an extras component within each repository. The current extras would move under mistral. Scirocco will have a separate extras and sardine and perhaps herring will get one too. This would require more work from the developers, or from the package maintainers. They need to recompile their applications and upload them to separate places. Getting the upload rights will still require a garage account and the invitation from the garage admins. What is your opinion? We could discuss the real objectives of extras and then derived from those we could revise the repository structure and also the policy regarding uploads etc etc. Cheers, Ferenc [1] http://maemo.org/maemowiki/ExtrasRepository [2] http://sardine.garage.maemo.org/about.html (bottom of page) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] extras repository
On Mon, 2006-11-27 at 15:33 +0200, Ferenc Szekely wrote: [snip] One idea is to have an extras component within each repository. The current extras would move under mistral. Yes, this seems exactly equivalent to what others do. For instance, Ubuntu has additional components, not additional repositories: For instance: deb http://archive.ubuntu.com/ubuntu/ edgy universe main restricted multiverse Scirocco will have a separate extras and sardine and perhaps herring will get one too. This would require more work from the developers, or from the package maintainers. They need to recompile their applications and upload them to separate places. I don't see how anything else can possibly work. But there must be some tools to automatically build packages out there. I don't believe that Ubuntu or Debian maintainers personally build their packages for all versions (Ubuntu breezy, dapper, edgy, feisty), and all architectures (i386, PPC, etc). -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] extras repository
On Mon, Nov 27, 2006 at 03:33:37PM +0200, Ferenc Szekely wrote: One idea is to have an extras component within each repository. The current extras would move under mistral. Scirocco will have a separate extras and sardine and perhaps herring will get one too. This would require more work from the developers, or from the package maintainers. They need to recompile their applications and upload them to separate places. Getting the upload rights will still require a garage account and the invitation from the garage admins. Sounds good, but do the developers then need to have Scratchbox targets for each repository? Would it be possible to do it somewhat like the way Debian/Ubuntu does it: 1. Maintainers upload Debian source packages. 2. Autobuilders build binary packages for each repository and send emails to maintainers if there are errors. ? Even if there are no autobuilders I would still want to enforce the requirement for having proper Debian source packages for everything that is distributed from Garage. Marius Gedminas -- He who sacrifices functionality for ease of use Loses both and deserves neither signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] extras repository
On 11/27/06, Ferenc Szekely [EMAIL PROTECTED] wrote: Hello, I think it would be time to think about the extras repository a little bit. Those who are not familiar with extras please find some info on the ExtrasRepository [1] wiki page. ... What is your opinion? We could discuss the real objectives of extras and then derived from those we could revise the repository structure and also the policy regarding uploads etc etc. Ferenc, I really dislike this debian repository layout. IMHO it makes not much sense and have a lot of limitations. I rather like Gentoo's portage or BSD ports tree. In Gentoo's portage you have the option to select package version and developers can mask individual packages, what makes testing of individual packages easier (you don't have to upgrade every package just to try newer python). HOWEVER it's not doable ATM (portage is easy because it's source, but that requires compile which is a no-go for 770, doing portage with binary is hard and imposes many limitations...), I understand, however I would like to have my opinion registered. As for something real I would go with Murray and others: let's use more components. And in order to help developers and package maintainers, build-bots would really help. I'm glad Carlos is taking care of it. -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 Phone: +1 (347) 624 6296; [EMAIL PROTECTED] GPG: 0xB640E1A2 @ wwwkeys.pgp.net ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] extras repository
On Tue, 2006-11-28 at 00:58 +0200, Carlos Guerreiro wrote: ne question: Which version of gtk-- to use and where to get it from (packaged)? libsigc++, glibmm, and gtkmm are already in extras. The packages just need to be rebuilt for sardine. They need to be updated too to the latest source versions, but we can take care of this, if you like. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
