[Conclusion] Diablo, do we need a separate repository?
Hi all, given all responses favoring separate repositories, I think we should go that route. I think this is a good example of how we, the community, can influence the process and make decisions. Let's hope we can do this more and more. Thanks for all your input. - Niels ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Keeping Glib up to date (was RE: Diablo, do we need a separate repository?)
ext Graham Cobb wrote: Nokia should be keeping all system libraries up to date and should be scheduling testing, to verify that the updated libraries do not break anything, as part of the release cycle. It is part of Nokia's responsibilities to its development community. Sure, and using fresh libraries is the general intend. For the development community and the own Nokia developer teams. Then real life comes with just one predictable thing: every day has 24h. And one clear goal: we need to ship the next release on week nn. Architect decisions are made, some go through, some go back, some go through again after some work... But not even glib will put in risk a deadline if it's not worth from a consumer point of view. Other software projects might have different priorities and that's fine. During the life of an installed release, I agree. Between Nokia-issued firmware releases, I disagree. My view (I realise you disagree) is that at each new release Nokia should update all shared libraries. We don't work release after release. There is ongoing plans and development at different stages on different releases. Even if football fans and media present each game as 90 minutes where a team has to put all the flesh, in the coach's mind there is a couple of national competitions, the European competition, the players that will go to the national team on specific dates... You need to make some sense of all that without burning your team. Same for us developing software, more or less. Chinook was a major release (4.0), Diablo is going to be a minor release from a platform point of view (4.1) and Diablo+1... we will start talking about it soon. -- Quim Gil marketing manager, open source maemo software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Diablo, do we need a separate repository?
On Monday 05 May 2008 12:42:33 Niels Breet wrote: Do we need a separate extras repository for diablo or should we just add a link to chinook? I strongly believe they need to be separate. The main reason isn't from the point of view of Diablo, it is from the point of view of Chinook. The issue isn't whether chinook apps will work on diablo (and it is good news that they will) -- it is whether diablo apps will work on chinook! If there are *any* library changes (you mentioned libssl but I *really* hope there will be an up to date version of glib!) then apps built for Diablo will not work on Chinook. So, you have the problem that users still running chinook will find that apps in the chinook repository will not install! By linking the two, developers don't have to upload their packages to both repositories. But the autobuilder makes this irrelevant. Developers can submit the exact same source package to both autobuilders if they want to (the submission assistant can even do it automatically for you by default). And you can initially populate the diablo repository (even before anyone outside Nokia has a diablo device) just by running the autobuilder on all the source packages in the chinook repository (and, if you could automate sending any failures to the maintainer from the package that would be even better!). What do you think? Please give us your ideas, pros/cons. The autobuilder makes this sort of decision very easy to decide -- always go for a separate repository for every change in the Nokia released firmware. As long as the Application manager on the device has enough information to automatically select the right one it is transparent to the user and the autobuilder can handle the issue for developers. In fact, the autobuilder actually makes it impossible to make a single repository work in the future: it becomes impossible for me to deliberately build my diablo software against chinook libraries or against old libraries of other community packages. For example, if library libAAA links against libssl then the autobuilder would insist on building a version which won't run on chinook (presumably Nokia does not allow a chinook package to upgrade libssl), but if I was building it myself I would build it against the chinook version so it could run on both. I do this today for gregale: the gregale version of GPE is deliberately built against the 3.0 SDK (not 3.2, where the gregale codename points). Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Diablo, do we need a separate repository?
On Mon, May 5, 2008 14:59, Ryan Pavlik wrote: For those working with the enhancements, it would obviously be best to keep the Diablo stuff separate, but allow a very easy forward/back-port of packages. In many cases, it's just a changing of a target in the debian changelog - is there someway a web-based backport/forwardport service could be put together to allow the advantages of a separate repository while not inhibiting the ability to share essentially identical packages? I think the autobuilder[1] might help developers with building for different versions. They would need to submit the source package for chinook and diablo though. -- Ryan Pavlik www.cleardefinition.com - Niels [1] http://extras-cauldron.garage.maemo.org/HOWTO.html ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Diablo, do we need a separate repository?
Graham cobb wrote: If there are *any* library changes (you mentioned libssl but I *really* hope there will be an up to date version of glib!) Perhaps we did a really bad job explaining what not changing the platform means. I'm 99.99% certain that glib2.0 will be based on 2.12.12, just as it was in the previous release. Assuming I'm correctly reading the changelog there was only one change to glib2.0, and that was to fix shlibs in debian/rules. Sadly it looks like the changes were all done in some private repository because my snapshots from both projects show the 4 version bumps all happening in one week even though the datestamps imply it would have happened weeks earlier. My guess is that this was because their versions failed integration (hopefully this is explained below). There was one attempted change, however it was reverted because it would have broken the ABI. Diablo is not a new OS. Most applications haven't changed significantly** According to the marketing material it's Internet Tablet OS: maemo Linux based OS 2008 feature upgrade The only major changes are feature updates to the browser (not actually a new browser, it's still based on the same old gecko as 2008), a new mail client, and the ssl change to support WiMax. I'll actually be working on browser release notes starting this week (it takes a long time). I might actually try to grab the highlights for the other apps if I manage to do the browser notes in fewer than 2 weeks. ** many applications probably haven't changed at all, I can do a diff at some point to get more details, but in general the maemo platform people actually provide pretty colored tables of this, so I don't need to. then apps built for Diablo will not work on Chinook. So, you have the problem that users still running chinook will find that apps in the chinook repository will not install! No. The only case where this should happen is an app that uses libssl. And libssl 0.9.8 *should* be in the repository. And fwiw, diablo includes the libssl 0.9.7 library (and package), so apps built against it from chinook would still work in diablo (this actually scares me, but I don't want to read the changelog to figure it out). (presumably Nokia does not allow a chinook package to upgrade libssl) Wrong, as explained above. Both 0.9.7 and 0.9.8 are installed and owned by their own independent packages. Note that there is no /usr/lib/libssl.so, /usr/lib/libssl.so.0, nor /usr/lib/libssl.so.0.9 only /usr/lib/libssl.so.0.9.7 and /usr/lib/libssl.so.0.9.8 - so there is no problem. An app that needs 0.9.8 simply writes: Build-Depends: libssl-dev (= 0.9.8) Depends: libssl-dev An app that doesn't care writes: Build-Depends: libssl-dev Depends: libssl-dev The former will force the system to install libssl0.9.8 into chinook as part of the install. And the latter will just work in either place (as long as the builder doesn't start with 0.9.8). It does mean that the autobuilders should actually use chinook with repository access to diablo, otherwise the results will be things that aren't the most pleasant of experiences. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Diablo, do we need a separate repository?
On Tuesday 06 May 2008 10:11:57 [EMAIL PROTECTED] wrote: I'm 99.99% certain that glib2.0 will be based on 2.12.12, just as it was in the previous release. That is *very* disappointing. Presumably Diablo is the last update until 2009 at the earliest. More and more applications cannot be built for Maemo just because they use features in glib introduced after 2.12.12. It should ONLY be a testing issue to make sure glib is kept up to date in every release and it should be Nokia policy to keep it up to date unless it is discovered to break an application. Don't forget: the community CANNOT update glib -- Nokia prevent that. So, sticking with an out of date glib stops the community providing some applications. Alternatively (and maybe better), if Nokia aren't willing to keep glib up to date they should rename it something else (nokiaglib) for their own apps and let the community build and install up to date versions of glib for community apps. Diablo is not a new OS. It is a new, updated, firmware installation. Are you telling me that Nokia are actually testing that applications built against diablo work on (unupgraded) chinook systems? Unless Nokia are testing that, there is a danger that there is a change which has not been noticed which means that some diablo applications do not work on chinook. I see no advantage at all to sharing a repository and a risk (possibly small) that it will come back to bite us. I really don't see why anyone would bother to propose sharing a repository -- certainly anyone who lived through the mess of earlier point release Maemo updates. (presumably Nokia does not allow a chinook package to upgrade libssl) Wrong, as explained above. Both 0.9.7 and 0.9.8 are installed and owned by their own independent packages. Note that there is no /usr/lib/libssl.so, /usr/lib/libssl.so.0, nor /usr/lib/libssl.so.0.9 only /usr/lib/libssl.so.0.9.7 and /usr/lib/libssl.so.0.9.8 - so there is no problem. An app that needs 0.9.8 simply writes: Build-Depends: libssl-dev (= 0.9.8) Depends: libssl-dev An app that doesn't care writes: Build-Depends: libssl-dev Depends: libssl-dev The former will force the system to install libssl0.9.8 into chinook as part of the install. Has that been tested? If so, that is good to know. It means that I don't need to add a diablo distribution to my daily builds of GPE for the GPE development team. But it still doesn't convince me that there could not be some other problem preventing diablo apps running on chinook. It does mean that the autobuilders should actually use chinook with repository access to diablo, otherwise the results will be things that aren't the most pleasant of experiences. In general that doesn't work. Even if the autobuilder continued to use the earlier SDK, it is possible that a community-contributed library might use some feature from the later release that would mean that a third app, which links against the library, doesn't work on the earlier release. In this particular case, it might work. If we are lucky. And if Nokia conduct sufficient testing. But why take the risk? If we establish the principle now that every firmware update will be reflected in a new repository, and the contents will be autobuilt from the previous repository, we eliminate those risks at virtually no cost to the community and a considerable cost saving to Nokia (in testing). That is the big benefit the autobuilder gives us. In general, I would prefer that the autobuilder always uses the correct SDK for the target release. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Gecko version? Re: Diablo, do we need a separate repository?
[EMAIL PROTECTED] wrote: The only major changes are feature updates to the browser (not actually a new browser, it's still based on the same old gecko as 2008) Sorry for hijacking thread, this is certainly not central to this discussion. Does the it's still based on the same old gecko as 2008 really mean same old and slow gecko as 2008 just with updated browser UI or does it mean same old gecko but synced to upstream mozilla code with multiple speed and memory optimizations done in last year or so? Sorry for being a bit thick, I guess the latter is true and most probable but I am no longer sure due to the way you wrote the sentence above and you general description of Diablo in other mails ( About half of the packages have not changed version numbers at all ...). Thanks. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Keeping Glib up to date (was RE: Diablo, do we need a separate repository?)
On Tuesday 06 May 2008 13:32:34 [EMAIL PROTECTED] wrote: A properly versioned operating system should be able to handle side by side libraries. Why on earth bother? I am also not a DD but my understanding was that in Debian this was only done when some ABI change occurs and means an application can only work with either the old or the new version. IIUC the Debian approach to this issue would just be to replace libglib-2.0.so.0 (etc.). It should ONLY be a testing issue to make sure glib is kept up to date in every release and it should be Nokia policy to keep it up to date unless it is discovered to break an application. Please don't make assertions about such things. Especially if they involve resources you don't control. I certainly will make assertions about such things. I am fairly confident in my assertion that this is only a testing issue -- no code changes required -- but feel free to correct me if I am wrong. Note that I didn't say it was a *small* issue, just that it was a testing issue. I will also continue to assert, as a customer and a member of the development community which helps Nokia be more successful by providing additional applications, that Nokia should be keeping all system libraries up to date and should be scheduling testing, to verify that the updated libraries do not break anything, as part of the release cycle. It is part of Nokia's responsibilities to its development community. That said, to some extent people obviously do want to use later versions of libraries when/where possible. No one loves the idea of using code that's many years out of date with its ever growing set of known bugs. However sometimes bug-wise compatibility triumphs. During the life of an installed release, I agree. Between Nokia-issued firmware releases, I disagree. My view (I realise you disagree) is that at each new release Nokia should update all shared libraries. If it felt like it. While this would mean you'd have multiple glibs on the system, it isn't impossible to do, and if you absolutely need it, you could do it. Sure, I could do that. I could also build my own tablet or move to another product. But my goal is to make a particular piece of software (e.g. Opensync) run on the tablet. The barrier of creating my own glib package, (and trying to co-ordinate a community effort to use it so we don't all have to do the same thing), just to workround a Nokia restriction, may just raise the bar beyond the level I am willing to take to proceed with the project. To take a real example, I previously supported Opensync on mistral, gregale, bora and chinook. I have already abandonned support for all except chinook because it was too much effort to deal with the old glib versions. For the moment I persevere with chinook, patching Opensync to make it work with 2.12.12. One day even that will become too hard, at which time Opensync on Maemo will die unless Maemo includes an up to date glib. I am hopeful that Nokia believes it is in Nokia's interest to provide some level of support for the community. That should include not frustrating community efforts to port software. If Nokia really want to stay on an old version of glib (or any other library) they should take the hit of creating their own libraries, not the community (which is why I suggested nokiaglib). And no. I'm not a DD, my advice does not constitute Debian advice. I'm a pragmatist and a hacker. If I need something, I make it work. If the community is to solve the problem I think it would be easier just to develop a patch to disable the Application Manager preventing updates to system libraries (and get rid of that annoying click-through warning while we are at it!). I'd be curious to see a list of applications that require newer glibs. That seems kinda strange to me. Nothing strange at all. Glib continuously adds new functions. The whole purpose of Glib is to be a library of useful functions. People use them. Nokia taking the benefit of using opensource code while deliberately making it hard for other projects to make use of the same benefit seems unreasonable. I believe Nokia has three feasible course of actions: 1) make sure system libraries are kept reasonably up to date; 2) use private libraries and let the community use bleeding edge libraries if we want; 3) turn off the locks preventing the community from updating system libraries. Personally I prefer 1 (because we all benefit from core system libraries not changing underneath us and can concentrate re-testing on OS updates), then 2 (the locks on system libraries do help with stability). Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Keeping Glib up to date (was RE: Diablo, do we need a separate repository?)
On Tuesday 06 May 2008, Graham Cobb wrote: To take a real example, I previously supported Opensync on mistral, gregale, bora and chinook. I have already abandonned support for all except chinook because it was too much effort to deal with the old glib versions. For the moment I persevere with chinook, patching Opensync to make it work with 2.12.12. One day even that will become too hard, at which time Opensync on Maemo will die unless Maemo includes an up to date glib. And given that GPE apps and opensync are *SO OBVIOUSLY MISSING* (I can't stress that enough ;-) on the tablet, everything that can help that is important. I am hopeful that Nokia believes it is in Nokia's interest to provide some level of support for the community. That should include not frustrating community efforts to port software. If Nokia really want to stay on an old version of glib (or any other library) they should take the hit of creating their own libraries, not the community (which is why I suggested nokiaglib). I love the tablet because of its openness, because it allows me to develop the very specific applications I need for my work on a small device. However, and I'm not the only one thinking that given what is written on the various forum on the subject, there are many missing applications in the default OS (without talking about the general look-and-feel), and without the community (I'm not including myself in that), the tablet might not have the success it has. Fred P.S. Sorry for not contributing anything else than a rant ;-) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Diablo, do we need a separate repository?
Dnia Tuesday, 6 of May 2008, [EMAIL PROTECTED] napisał: Graham cobb wrote: If there are *any* library changes (you mentioned libssl but I *really* hope there will be an up to date version of glib!) Perhaps we did a really bad job explaining what not changing the platform means. I'm 99.99% certain that glib2.0 will be based on 2.12.12, just as it was in the previous release. Assuming I'm correctly reading the changelog there was only one change to glib2.0, and that was to fix shlibs in debian/rules. glib2 keeps source and binary compability between releases so upgrading from 2.12.12 to 2.16.x should not even require recompiling of applications. -- JID: hrw-jabber.org OpenEmbedded developer/consultant It is your destiny. -- Darth Vader ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Keeping Glib up to date (was RE: Diablo, do we need a separate repository?)
That said, to some extent people obviously do want to use later versions of libraries when/where possible. No one loves the idea of using code that's many years out of date with its ever growing set of known bugs. However sometimes bug-wise compatibility triumphs. Graham Cobb wrote: During the life of an installed release, I agree. Between Nokia-issued firmware releases, I disagree. I suspect the original hope was that diablo would have been delivered by SSU. If you keep that in mind, does it help change your view? Also note that the merge cost for hundreds of packages exceeds the small window for a project like diablo (which really really was a dot release). My view (I realise you disagree) Actually, in this case, I have no particular opinion. I understand why Nokia did it, and I can understand why you're upset. From a technical perspective, the browser team did not have enough time/resources to merge to trunk (nor was there a stable trunk of any value until long after we were frozen) and get any work done for diablo. We therefore had to choose not to merge to trunk and plan to do it for a future release. Most other projects (excluding wimax) probably had much fewer resources than the browser (in some cases they probably had no resources at all). is that at each new release Nokia should update all shared libraries. I think the key is that you're ascribing this to be an OS release. It isn't. it's a dot release. We never claimed it was a new OS release, the marketing information on this is quite clear, and I can't imagine anyone from Nokia would have claimed otherwise. http://www.backports.org/dokuwiki/doku.php You are running Debian stable, because you prefer the stable Debian tree. It runs great, there is just one problem: the software is a little bit outdated compared to other distributions. That is where backports come in. Think of chinook as a debian stable. Diablo is basically a collection of libraries provided by Nokia for chinook. You still have old libraries, and because it isn't actually newer software, the more you use it the more little bit outdated your software will become until an actual new distribution is released. As for how you manage to get a backports.org up and running, obviously that the package manager makes it harder is well... Unfortunate. But such is life. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Diablo, do we need a separate repository?
I wrote: I'm 99.99% certain that glib2.0 will be based on 2.12.12, just as it was in the previous release. Assuming I'm correctly reading the changelog there was only one change to glib2.0, and that was to fix shlibs in debian/rules. I should have written to _Nokia's_ glib2.0 for diablo. Marcin Juszkiewicz wrote: glib2 keeps source and binary compability between releases so upgrading from 2.12.12 to 2.16.x should not even require recompiling of applications. It might, however, please see the changelog I referenced in one of my other replies. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Diablo, do we need a separate repository?
Hi,
[EMAIL PROTECTED] wrote:
A full list of the new symbols in 2.14 and 2.16 is here:
2.14: http://library.gnome.org/devel/glib/stable/ix09.html
2.16: http://library.gnome.org/devel/glib/stable/ix10.html
Aside from GIO, which has recently received a big push for GNOME
applications, I don't know if these APIs are in widespread use.
That's pretty much what I'd expect.
In fact, at first glance, some of the most commonly used methods from
2.14 and 2.16 appear to be in the text methods that got added.
I did a little experiment on my recently updated Ubuntu 8.04 laptop:
But you didn't indicate the result, such a tease :)
I was building mood :)
Actually, it's a long list, I didn't want to flood the list.
I've stripped all packages starting with lib... and I changed the last
sed command to print the name of the package first:
$ sed -ne '/^Depends.*2\.1[3456]/{h;n;p;g;p}' glib_dependencies_2
Package: abiword
Depends: libglib2.0-0 (= 2.15.5)
Package: agave
Depends: libglib2.0-0 (= 2.14.0)
Package: at-spi
Depends: libglib2.0-0 (= 2.16.0)
Package: audacity
Depends: libglib2.0-0 (= 2.15.3)
Package: avidemux
Depends: libglib2.0-0 (= 2.15.5)
Package: bluefish
Depends: libglib2.0-0 (= 2.15.5)
Package: bluez-audio
Depends: libglib2.0-0 (= 2.16.0)
Package: bluez-gnome
Depends: libglib2.0-0 (= 2.14.0)
Package: brasero
Depends: libglib2.0-0 (= 2.14.0)
Package: brightside
Depends: libglib2.0-0 (= 2.13.7)
Package: bug-buddy
Depends: libglib2.0-0 (= 2.14.0)
Package: cheese
Depends: libglib2.0-0 (= 2.16.0)
Package: consolekit
Depends: libglib2.0-0 (= 2.16.0)
Package: contact-lookup-applet
Depends: libglib2.0-0 (= 2.13.2)
Package: deskbar-applet
Depends: libglib2.0-0 (= 2.16.0)
Package: desktop-file-utils
Depends: libglib2.0-0 (= 2.16.0)
Package: dia-gnome
Depends: libglib2.0-0 (= 2.15.3)
Package: drivel
Depends: libglib2.0-0 (= 2.15.5)
Package: eclipse
Depends: libglib2.0-0 (= 2.15.6)
Package: ekiga
Depends: libglib2.0-0 (= 2.16.0)
Package: emacs22-gtk
Depends: libglib2.0-0 (= 2.14.0)
Package: eog
Depends: libglib2.0-0 (= 2.16.0)
Package: evince
Depends: libglib2.0-0 (= 2.16.0)
Package: evolution
Depends: libglib2.0-0 (= 2.16.0)
Package: evolution-data-server
Depends: libglib2.0-0 (= 2.16.0)
Package: evolution-exchange
Depends: libglib2.0-0 (= 2.15.3)
Package: evolution-plugins
Depends: libglib2.0-0 (= 2.16.0)
Package: evolution-webcal
Depends: libglib2.0-0 (= 2.15.5)
Package: f-spot
Depends: libglib2.0-0 (= 2.16.0)
Package: fast-user-switch-applet
Depends: libglib2.0-0 (= 2.16.0)
Package: file-roller
Depends: libglib2.0-0 (= 2.16.0)
Package: flegita-gimp
Depends: libglib2.0-0 (= 2.14.0)
Package: freeciv-client-gtk
Depends: libglib2.0-0 (= 2.15.4)
Package: frozen-bubble
Depends: libglib2.0-0 (= 2.15.3)
Package: gamin
Depends: libglib2.0-0 (= 2.14.0)
Package: gcompris
Depends: libglib2.0-0 (= 2.16.0)
Package: gconf-editor
Depends: libglib2.0-0 (= 2.16.0)
Package: gdesklets
Depends: libglib2.0-0 (= 2.16.0)
Package: gdm
Depends: libglib2.0-0 (= 2.16.0)
Package: gedit
Depends: libglib2.0-0 (= 2.16.0)
Package: gimp
Depends: libglib2.0-0 (= 2.15.6)
Package: gimp-gap
Depends: libglib2.0-0 (= 2.14.0)
Package: gimp-gnomevfs
Depends: libglib2.0-0 (= 2.15.6)
Package: gimp-lqr-plugin
Depends: libglib2.0-0 (= 2.14.0)
Package: gimp-print
Depends: libglib2.0-0 (= 2.14.0)
Package: gimp-python
Depends: libglib2.0-0 (= 2.15.6)
Package: gksu
Depends: libglib2.0-0 (= 2.16.0)
Package: glade-3
Depends: libglib2.0-0 (= 2.16.0)
Package: gnome-applets
Depends: libglib2.0-0 (= 2.16.0)
Package: gnome-breakout
Depends: libglib2.0-0 (= 2.14.0)
Package: gnome-control-center
Depends: libglib2.0-0 (= 2.16.0)
Package: gnome-games
Depends: libglib2.0-0 (= 2.16.0)
Package: gnome-keyring
Depends: libglib2.0-0 (= 2.16.0)
Package: gnome-keyring-manager
Depends: libglib2.0-0 (= 2.14.0)
Package: gnome-mag
Depends: libglib2.0-0 (= 2.15.4)
Package: gnome-media
Depends: libglib2.0-0 (= 2.16.0)
Package: gnome-mount
Depends: libglib2.0-0 (= 2.14.0)
Package: gnome-nettool
Depends: libglib2.0-0 (= 2.16.0)
Package: gnome-panel
Depends: libglib2.0-0 (= 2.16.0)
Package: gnome-pilot
Depends: libglib2.0-0 (= 2.15.5)
Package: gnome-pilot-conduits
Depends: libglib2.0-0 (= 2.15.5)
Package: gnome-power-manager
Depends: libglib2.0-0 (= 2.16.0)
Package: gnome-randr-applet
Depends: libglib2.0-0 (= 2.14.0)
Package: gnome-screensaver
Depends: libglib2.0-0 (= 2.16.0)
Package: gnome-session
Depends: libglib2.0-0 (= 2.16.0)
Package: gnome-settings-daemon
Depends: libglib2.0-0 (= 2.16.0)
Package: gnome-system-monitor
Depends: libglib2.0-0 (= 2.16.0)
Package: gnome-system-tools
Depends: libglib2.0-0 (= 2.16.0)
Package: gnome-terminal
Depends: libglib2.0-0 (= 2.16.0)
Package: gnome-utils
Depends: libglib2.0-0 (= 2.16.0)
Package: gnome-volume-manager
Depends: libglib2.0-0 (= 2.16.0)
Package: gnopernicus
Depends: libglib2.0-0 (= 2.13.2)
Package: gnucash
Depends: libglib2.0-0 (= 2.16.0)
Package: gnumeric
Re: Diablo, do we need a separate repository?
En/na Marius Vollmer ha escrit: ext Marcin Juszkiewicz [EMAIL PROTECTED] writes: Does someone work on apt-get update;apt-get upgrade from Chinook to Diablo then? No, unfortunately not. We are working to get apt-get upgrade working for releases that come after Diablo. Does it mean Diablo to Diablo+1 will be possible with apt-get or we'll have to wait from Diablo+1 to Diablo+2? In other words, will Diablo be the last release needing a full reflash or we'll have to completely reflash its successor? Bye -- Luca ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Diablo, do we need a separate repository?
On Tue, May 6, 2008 at 10:40 AM, Graham Cobb [EMAIL PROTECTED] wrote: On Monday 05 May 2008 12:42:33 Niels Breet wrote: Do we need a separate extras repository for diablo or should we just add a link to chinook? I strongly believe they need to be separate. Hi Considering the current situation I think that having separate repositories is be the best thing to do. specially if you want to support the 770. The real problem is that as user I will not understand all the differences between the repositories. and as developer I really hope that all libs will be compiled for all the targets (or not be accepted). IMHO it might be fair to EOL it2007 or even it2008.1 if there is a compatible alternative. specially if the upgrade is apt-get dist-upgrade compatible. The main reason isn't from the point of view of Diablo, it is from the point of view of Chinook. The issue isn't whether chinook apps will work on diablo (and it is good news that they will) -- it is whether diablo apps will work on chinook! If there are *any* library changes (you mentioned libssl but I *really* hope there will be an up to date version of glib!) then apps built for Diablo will not work on Chinook. So, you have the problem that users still running chinook will find that apps in the chinook repository will not install! This is hell , but it currently is also pretty easy to install a wrong repository. But the autobuilder makes this irrelevant. Developers can submit the exact same source package to both autobuilders if they want to (the submission assistant can even do it automatically for you by default). And you can initially populate the diablo repository (even before anyone outside Nokia has a diablo device) just by running the autobuilder on all the source packages in the chinook repository (and, if you could automate sending any failures to the maintainer from the package that would be even better!). Yes, having source is definitely a + In fact, the autobuilder actually makes it impossible to make a single repository work in the future: it becomes impossible for me to deliberately build my diablo software against chinook libraries or against old libraries of other community packages. For example, if library libAAA links against libssl then the autobuilder would insist on building a version which won't run on chinook (presumably Nokia does not allow a chinook package to upgrade libssl), but if I was building it myself I would build it against the chinook version so it could run on both. I do this today for gregale: the gregale version of GPE is deliberately built against the 3.0 SDK (not 3.2, where the gregale codename points). sounds fair to me greetings ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Diablo, do we need a separate repository?
Hi all, As you probably all know Diablo, the next revision of the IT OS, is coming out sooner or later. Diablo will be binary compatible with chinook, but there will be two additions. There will be a new email framework and a newer version of libssl (0.9.8) because of requirements for the WiMax tablet. Most applications that work on chinook, should run unchanged on diablo. So developers should not have to change anything in their code to run their chinook application on diablo. In the past we added an extras repository with the corresponding codename for all new OS versions. This was needed, because versions weren't binary compatible. We now have come to the point where the next version _is_ binary compatible. My question to the maemo community is this: Do we need a separate extras repository for diablo or should we just add a link to chinook? By linking the two, developers don't have to upload their packages to both repositories. What do you think? Please give us your ideas, pros/cons. - Niels ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Diablo, do we need a separate repository?
Dnia Monday 05 of May 2008, Niels Breet napisał: As you probably all know Diablo, the next revision of the IT OS, is coming out sooner or later. Diablo will be binary compatible with chinook, but there will be two additions. There will be a new email framework and a newer version of libssl (0.9.8) because of requirements for the WiMax tablet. Does someone work on apt-get update;apt-get upgrade from Chinook to Diablo then? Or do we are expected to 'use maemo backup, then rsync whole filesystem, reflash'? -- JID: hrw-jabber.org OpenEmbedded developer/consultant We're here to give you a computer, not a religion. -- Bob Pariseau, at the introduction of the Amiga ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Diablo, do we need a separate repository?
Niels Breet wrote: On Mon, May 5, 2008 13:58, Rafael Proença wrote: Do we need a separate extras repository for diablo or should we just add a link to chinook? My guess is that if you link diablo to chinook what will happen is that all the chinook boxes will be upgraded to diablo, which, I think, is not ideal and even not compatible even though the binaries are compatible, the core system will not be (for example, I heard that the user will not have to reflash the device to upgrade the distribution once they have Diablo installed). I think I need to clarify that I was talking about the extras repository here. This is about community created packages in extras. System packages would be served from a different repository. IMO, the compatibility of binary packages is not the only problem here. But the packages' version and are. For those working with the enhancements, it would obviously be best to keep the Diablo stuff separate, but allow a very easy forward/back-port of packages. In many cases, it's just a changing of a target in the debian changelog - is there someway a web-based backport/forwardport service could be put together to allow the advantages of a separate repository while not inhibiting the ability to share essentially identical packages? -- Ryan Pavlik www.cleardefinition.com #282 + (442) - [X] A programmer started to cuss Because getting to sleep was a fuss As he lay there in bed Looping 'round in his head was: while(!asleep()) sheep++; ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Diablo, do we need a separate repository?
ext Marcin Juszkiewicz [EMAIL PROTECTED] writes: Does someone work on apt-get update;apt-get upgrade from Chinook to Diablo then? No, unfortunately not. We are working to get apt-get upgrade working for releases that come after Diablo. I agree that a smooth upgrade path is needed: without it, we not only need to keep backwards compatibility (packages created with the Chinook SDK run on Diablo), but also fowards compatibility (packages created with the Diablo SDK run on Chinook). If we have a smooth upgrade patch, we can expect people to upgrade to Diablo and stop supporting Chinook devices. Or do we are expected to 'use maemo backup, then rsync whole filesystem, reflash'? For the Chinook to Diablo upgrade, yes. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
