Fremantle on OBS status update
Hi, A quick update about this task: I've imported the Fremantle PR1.3 SDK into the maemo.org OBS and also imported all packages from fremantle Extras into the Extras:Testing13 project. There is currently a problem with the scheduler for armel packages, I need to find out why builds aren't dispatched. At the moment the i586 packages are still building, but the results look quite promising already. Building for i586 should finish somewhere tomorrow. Unfortunately I have to cancel the fremantle on OBS meeting tomorrow as I am not able to join it. I want to propose postponing the meeting one week, so I can fix the armel building in the OBS and let the builds run. -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: autobuilder uses files from another packages
Hi, It took me a while to find what the problem was, but now I found it. And of course the fixed it. It should work a lot better now. -- Niels Breet maemo.org webmaster On Tue, Sep 20, 2011 at 10:04 AM, Aapo Rantalainen aapo.rantalai...@gmail.com wrote: Hi, new problem with maemo.org autobuilder. Packages are using source packages from another packages. https://garage.maemo.org/builder/fremantle/autoconf2.64_2.64-maemo1/ I have sent correct files, but log shows: source package lichviet (which is not my package) This also happens https://garage.maemo.org/builder/fremantle/make-3.81_3.81-maemo1/armel.build.log.FAILED.txt Which shows source package gcc-4.4 (they are both my packages) -Aapo Rantalainen ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo.org autobuilder: No space left on device
Hi, On Fri, Sep 16, 2011 at 10:51 AM, Aapo Rantalainen aapo.rantalai...@gmail.com wrote: Hi, when uploading packages to the drop.maemo.org:/var/www/extras-devel/incoming-builder/fremantle/ , buildings are failing because of No space left on device. I checked some latest failed logs (not only uploaded by me) and they are all suffering this. My latest success is on at 14-Sep-2011 23:57. After that I got No space left on device. It cleaned up the builder, some stuck processes kept a lot of space locked. Can you try to see if it is better now? -Aapo Rantalainen -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: build failure
On Mon, Apr 11, 2011 at 8:10 PM, Thomas Vander Stichele tho...@apestaart.org wrote: Hi everyone, Hi, I just got build failure notifications for erlang and couchdb. The logs don't show the reason for failure: https://garage.maemo.org/builder/fremantle/erlang_13.b.2.1-dfsg-3maemo2/ My guess is that someone killed the build intentionally. I recall vaguely that in the past qemu-arm hung on some instruction. Yes, I killed a few hanging builds. a) can anyone tell me if the build might in fact have been interrupted, and who might have done so ? me b) would the hang have been the reason ? Yes, it was running for a very long time. How long does it take to build it on your system for arm? This seems to run for quite a whle now, is that expected? builder1 17811 99.9 0.0 158612 8700 ?RApr11 951:58 /scratchbox/devkits/qemu/bin/qemu-arm-sb --sbox-call /home/builder1/maemo-fremantle-armel-extras-devel/work/erlang-13.b.2.1-dfsg/bin/arm-unknown-linux-gnueabi/beam.smp /home/builder1/maemo-fremantle-armel-extras-devel/work/erlang-13.b.2.1-dfsg/bin/arm-unknown-linux-gnueabi/beam.smp -- -root /home/builder1/maemo-fremantle-armel-extras-devel/work/erlang-13.b.2.1-dfsg/bootstrap -progname erl -- -home /home/builder1/maemo-fremantle-armel-extras-devel/work/erlang-13.b.2.1-dfsg/debian -noshell -noinput -mode minimal -boot start_clean -s erl_compile compile_cmdline @cwd /home/builder1/maemo-fremantle-armel-extras-devel/work/erlang-13.b.2.1-dfsg/lib/parsetools/src @warn 1 @option debug_info @option warn_obsolete_guard @i /home/builder1/maemo-fremantle-armel-extras-devel/work/erlang-13.b.2.1-dfsg/lib/stdlib/include @outdir ../ebin @files leex.erl qemu-arm-sb is using 100% of one core continuously. c) what is the best course of action ? - package erlang and couchdb manually and ask for an exception to ship them - figure out what the bug might be That would be the thing to do here. - for which I will no doubt need help of the debmaster (which I think is Jeremy in CC, correct me if I'm wrong) You are wrong ;) Jeremiah is not working for maemo.org anymore. Thanks Thomas -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder Build Error (Unmet Dependencies)
On Mon, Jan 31, 2011 at 11:39 AM, Vaudano Luca vaud...@gmail.com wrote: Hello! Hi, I'm trying to update the EFL library (www.enlightenment.org) that are really old in the repository (last one is 2009/08/18). I built with success the first library extras-devel/pool/fremantle/free/e/eina but when I try to compile the second one, the process fails because it tries to compile against the old version of the eina library: The following packages have unmet dependencies: libeina-dev: Depends: libeina0 (= 0.0.2.060+svn40978-maemo3) but 0.0.2.062+svn41533-maemo1 is to be installed You probably need to wait a little bit longer. It takes some time (half an hour or so) for a package to be imported into the repository and to be available in the builder. I checked libeina-dev_1.0.0~beta-1maemo1_armel.deb and it depends on libeina1. What can I do? Thanks, regards Luca -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Qt Mobility 1.1 for Fremantle
On Wed, Dec 29, 2010 at 3:47 PM, Felipe Crochik fel...@crochik.com wrote: Attila, This is really great news! I assume applications using it can not promoted to extras-testing until we have the SSU with libqtm-11-*, right? I've put a block in place to prevent a mess, but once we have a SSU with newer qtm we can remove the block. Please let me know if I can help in any way. Felipe -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Package blocked in the autobuilder queue : khweeteur-experimental
2010/11/10 Benoît HERVIER kher...@khertan.net: Morning, Someone with access to the build queue can unblock or remove the package khweeteur-experimental blocked in the fremantle build queue. Killed the process. You should be able to upload a new version now. Thanks. Regards, -- Benoît HERVIER, Khertan Software - http://khertan.net/ -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras-assistant: autobuilder fails, no reason given?
On Sat, Nov 6, 2010 at 10:02 PM, Thomas Waelti twae...@gmail.com wrote: Hello all Autobuilder fails on my uploads, but I can't find the reason in the logs available. Any ideas on how to proceed? Did I overlook something? Most of the time this is due to issues in your debian/control file. Looking at yours, my guess is that it is your description field. That looks like a bit of a mess. You can find more info about this build here: https://garage.maemo.org/builder/fremantle/recaller_2.1.0-1/ Thanks -Tom -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle Community SSU
On Tue, Nov 2, 2010 at 8:26 AM, Marius Vollmer marius.voll...@nokia.com wrote: [snip] - You make a enabler package that configures the domains and keys and everything, and also contains a little script that runs apt-get install mp-fremantle-community-pr=0 This will just swap mp-fremantle-generic-pr out for mp-fremantle-community-pr. Problem Mohammad faced here is that HAM holds a lock, so you can't run apt-get in the background. This is why he needs to open the xterm and ask the user to close HAM. If that part can be solved, we're one step closer at least. -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle Community SSU
On Tue, Nov 2, 2010 at 9:32 AM, Marius Vollmer marius.voll...@nokia.com wrote: ext Niels Breet ni...@maemo.org writes: Problem Mohammad faced here is that HAM holds a lock, so you can't run apt-get in the background. This is why he needs to open the xterm and ask the user to close HAM. Yes. But what about launching that script from a launcher entry instead of asking people to type something into an xterm? I think that inspires a bit more confidence. That would be a little more friendly yes. Another issue I now see in HAM log: apt-worker: Ignoring version from wrong domain: modest 3.90.7-2 Any idea how to get around that issue? -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New Fremantle SDK major update
On Mon, Oct 25, 2010 at 11:48 AM, Aapo Rantalainen aapo.rantalai...@gmail.com wrote: It is SDK PR 1.3. When autobuilder starts using it? (Or it is already using?) I'll update the builder as soon as I have everything I need for the update. Should be updated today. Will send an announcement when it happens. -Aapo Rantalainen -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
maemo.org Extras autobuilder updated to PR1.3
Hi, The autobuilder has been updated to the PR1.3 SDK. If you experience any problems, please let me know. -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder problems
There are some characters before Source: in the .dsc file, apparently the build queue runner doesn't like that. I've removed the package from the queue, so it should be quiet again. -- Niels Breet maemo.org webmaster On Wed, Oct 20, 2010 at 8:31 AM, Toni Känsälä toni.kans...@sci.fi wrote: Hi, Uploaded new version of Outlaw Solitare to autobuilder last night and this morning realised that there are quite a few: [extras-builds] [fremantle]: outlawsolitaire 0.71-1 UNKNOWN failures in: https://garage.maemo.org/pipermail/extras-cauldron-builds/2010-October/date.html All with the same error: [2010-10-20 09:28:02] Unexpected error: KeyError': 'source' Traceback (most recent call last): File /usr/lib/python2.5/site-packages/buildlib/app.py, line 81, in run mainfunc(argv, options, self._logger, self.conf) File /usr/bin/buildme, line 640, in main 'conf' : conf File /usr/lib/python2.5/site-packages/buildlib/fsm.py, line 72, in run code = handler(self) File /usr/bin/buildme, line 384, in check_sources source = dsc['source'] File /usr/lib/python2.5/UserDict.py, line 22, in __getitem__ raise KeyError(key) KeyError: 'source' And new message appears approximately every 2 minutes. Any ideas what might be going on? Is it a problem with the package or with the autobuilder? -Toni ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: smscon_editor_0.4.3-9 package fail to build.
On Mon, Sep 13, 2010 at 1:05 AM, Chris Saturn chris_sat...@hotmail.com wrote: Hi, That's my first package to upload so bare with me. I get a failed build but cannot see the error in the log. Here's the sources/lg: https://garage.maemo.org/builder/fremantle/smscon_editor_0.4.3-9/ The sources have been prepared with pyPackager but I had the same error on my previous effort with py2Deb. Does anyone have an idea on what to check? This usually happens when you have issues in your debian/control file. My guess is that it is because of XB-Maemo-Upgrade-Description: not having a valid value. Either add a description or leave out this field. Thanks, Chris -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras not working - who should I talk to?
On Fri, Aug 27, 2010 at 4:56 PM, Felipe Crochik fel...@crochik.com wrote: Just a wild guess: isn't it just a matter of having the file on http://repository.maemo.org/extras/pool/fremantle-1.2/non-free/ Instead of (or in addition to): http://repository.maemo.org/extras/pool/fremantle/non-free/ ?? I imagine you are looking for a long term solution but would be nice if there was also a quick and dirty solution so users don't get lost trying to install the app. The quick and dirty solution would have been overwritten the next time the sync runs, so that was not an option. I've found and solved the blockage for non-free apps in fremantle-1.2. Your app should now be available. Please let me know if there is anything I can do to help. Thanks, Felipe - Niels ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras not working - who should I talk to?
On Wed, Aug 25, 2010 at 6:30 PM, Andrew Flegg and...@bleb.org wrote: On Wed, Aug 25, 2010 at 17:28, Andre Klapper aklap...@openismus.com wrote: Am Mittwoch, den 25.08.2010, 12:15 -0400 schrieb Felipe Crochik: Would you mind posting yours so I can compare? Ahem, I'm very sorry, I hadn't disabled -testing and -devel when I tried. So yes, I can confirm that when only Extras is enabled mycontacts does NOT get displayed in App Manager. No idea what's going on. Niels Breet is, of course, the right person to talk to. And/or Bugzilla. It seems there is a promotion issue with non-free apps from testing to Extras fremantle-1.2. This path is not well tested as there aren't that many non-free apps in Extras. Will try to find out what goes wrong exactly. -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Remove Package from Extras-Devel
Hello, Hi, I uploaded a package to test something and I won't use it anymore, could you remove it from the repository? The package name is Mizu. I have removed them from the repository. Thank you, Rodrigo Ramos -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: how to promote a non-free package to extras-testing/extras?
How can I promote a non-free package to extras-testing/extras? The same as you would do for a free package. Go to the armel version of the package you want to promote in http://maemo.org/packages/ and click on the Promote link. Thanks in advance -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Removing packages from Fremantle extras-devel
Hi guys, I'm looking for a procedure to remove packages uploaded in extras-devel. I read that there isn't actually a real way to do this and it can be operated only manually for us by maemo.org admin. For now, there is no nice package removal interface indeed. Can someone help me to remove sources that I had uploaded friday 11th in Fremantle extras-devel and related autobuilded packages? The name of source is dtn_2.7.0maemo-fremantle7 (https://garage.maemo.org/builder/fremantle/dtn_2.7.0maemo-fremantle7/) and the packages to remove are: dtn_2.7.0maemo-fremantle7_i386.deb dtn_2.7.0maemo-fremantle7_armel.deb python-dtn_2.7.0maemo-fremantle7_all.deb I have just uploaded a new version of my dtn implementation (version 8) that works correctly. The real problem is python-dtn that dosn't work properly and I remove it from version 8 compilation. python-dtn so I do not want to appear in packages list. I removed python-dtn. The other packages are not really a problem as version 8 replaces them anyway. Thanks in advantages! Thanks, Francesco Baldassarri -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Chinook Diablo Builder down
Hi, Sorry for this, everything should be back to normal now. - Niels Hi Niels or anyone with the power :) Didn't check the Fremantle builder, but Chinook and Diablo having problems. Please have a look at it. Thanks! Conny ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Autobuilder maintenance break now.
Hi, The autobuilder will be updated to the latest Maemo 5 SDK to align with the PR1.2 release. During the update the incoming queue for the builder will be paused. Update will take about half an hour. -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
maemo.org Packages interface maintenance break now.
Hi, The maemo.org Packages interface will be updated now. New SDK repositories and firmware package versions will be imported, during the update you might see some error messages or broken pages. I'll reply to this list when the update is done. -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo.org Packages interface maintenance break now.
hi 2010/5/25 Niels Breet ni...@maemo.org Hi, The maemo.org Packages interface will be updated now. New SDK repositories and firmware package versions will be imported, during the update you might see some error messages or broken pages. I'll reply to this list when the update is done. I don't know if you're done yet but anyway it seems like usage of libqt4-maemo5 [1] package prevents promotion of Qt applications. the package is a part of stable Qt 4.6. Yes it is a mess. Someone thought that adding a meta stable package named the same as the unstable testing libs in extras-testing was a good idea. Will add a special case for this tomorrow. -Timo -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo.org Packages interface maintenance break now.
Most repositories have been updated in the Packages interface. Tomorrow I will add the fremantle-1.2 repository for Extras and add the SSU repository so the new Qt dependencies can be properly resolved by the interface. - Niels Hi, The maemo.org Packages interface will be updated now. New SDK repositories and firmware package versions will be imported, during the update you might see some error messages or broken pages. I'll reply to this list when the update is done. -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Community updates for diablo
On Tue, May 04, 2010 at 06:50:21PM +0100, Graham Cobb wrote: Will there be any SDK/autobuilder updates to go with this? Not required right now, but it's an interesting question. For example, one existing request is to enable ogg support in sdl-mixer which would require /something/ to be done in order for extras apps to be able to use it. I'm not sure what the right solution would be. The recent work on the Fremantle side seems particularly relevant, but may be too much work for this. Niels, what do you think? The devkit + symbols might be a solution. But that also means that we basically need to create our own SDK :) We can say that the for instance say that from a certain point in time diablo is only supported for devices running the community version of diablo. (Discussion welcome) We would need to create a community sdk repo with the updated libraries too. And the autobuilder would use that sdk. Having both a plain diablo Extras and a community ssu compatible Extras would probably not be worth it as the number of downloads for diablo are really low. Diablo seems to be EOL for Nokia, although not officially announced. Everybody wanting new latest and greatest software should use the community SSU at some point? Extras is a community run repository, whatever the community agrees on goes. I am assuming anything built with the current autobuilder should work with this community update -- is that right? Are there any updates to any libraries? Everything should work fine for now. There are some libraries in the updates but they only contain bug fixes (no API changes). L. -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Community updates for diablo
On Mon, May 03, 2010 at 02:14:00PM +0200, Carsten Munk wrote: X-Fade said we should set up a IRC meeting to get this accomplished - he can take care of server side. Cool :-) Got a suggestion for a time during this week? Any evening (UTC) is fine. If it has to be during office hours, Thursday or Friday morning will probably do. I prefer UTC office hours as MeeGo already tends to steal some evenings. L. -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Squeeze devkit to be installed to autobuilder
On Tuesday 27 April 2010 10:08:56 Marcin Juszkiewicz wrote: Will there be step-by-step instructions for developers like me how to do that at home? I hate sbox, it makes me sick each time when I use it but I like to have own packages for things which I use so I have to deal with it (and no, I do not want to use madde or other less official things). First you download the debian-squeeze devkit[1] and install it in your host. Then you change your fremantle targets to use the debian-squeeze devkit instead of debian-etch. You can do that with sb-menu. Then you apt-get install maemo-sdk-symbols from extras-devel and you are done. And, where do we find the relevant sbdmock config files and rootstraps? I changed these lines in our sbdmock config: config_opts['devkits'] = 'perl:debian-squeeze:doctools:svn:git' config_opts['after_rootstrap'] = 'fakeroot apt-get -y -q %s install maemo-optify man-db cdbs dpatch maemo-sdk-symbols' % config_opts['apt-get_options'] No rootstrap changes were needed. Graham - Niels [1] http://scratchbox.org/debian/dists/stable/main/binary-i386/scratchbox-devkit-debian-squeeze_1.0.3_i386.deb ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: problems uploading to non-free repository
hello, Hi, Ive been getting this error today while uploading to the non-free section Uploading to fremantle-extras-devel-non-free (via scp to drop.maemo.org): Permission denied (publickey). lost connection Warning: The execution of '/usr/bin/scp' as 'scp -p /home/krk969/buddy_0.1-1_armel.deb /home/krk969/buddy_0.1-1_armel.changes krk...@drop.maemo.org:/var/www/extras-devel/incoming-nonfree/fremantle' returned a nonzero exit code. Error while uploading. could anybody help me with this please ? does it have anything to do with the public ssh key in my garage account page ? I have no clue what Im doing wrong. Frankly speaking, you made a mess :) You pasted both your ssh key fingerprint, username and actual pubkey in the entry field. That will never work. I have tried to clean up the entry, so it should work better for you now. thanks Ram -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Maintenance break: updating auto-builder to resolve dependency issues
Hi all, The fremantle autobuilder will be switched to use the debian-squeeze devkit in order to resolve as much SDK backwards compatibility issues as possible. After the swich, rebuilt packages will be imported to fremantle extras-devel and the repository will be reindexed. There will be a maintenance outage for about one hour and will start now. -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Squeeze devkit to be installed to autobuilder
i found quite a lot of updates this morning on my PR1.1.1 device. Many of those, however, (like MaePad) throw at me an Update file corrupted error... fMMS update (I think frals is still on SDK for PR 1.2) updated fine... Is this related to this change ? Yes and no. The same thing happens on a PR1.2 device. It seems the caching network caches the debs for 2 days, so it sees new package data, but gets the old file. We now issued a flush of the cache, will take another hour or so for it to complete. Let's see if that fixes the issue. Aniello - Niels ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maintenance break: updating auto-builder to resolve dependency issues
How will we know if a particular package has been rebuilt ? Also, will all packages be affected, or will there be a list somewhere of which packages are rebuilt. These builds were done: https://garage.maemo.org/builder/.fremantletest/ Those have been rebuilt and imported. Thanks, - ianaré sévi -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Squeeze devkit to be installed to autobuilder
On Wed, Apr 14, 2010 at 20:00, Niels Breet ni...@maemo.org wrote: As part of this task we need to decide with the 'broken' or affected packages which have been built on the PR1.2 SDK and have gotten PR1.2 dependencies. The simple thing would be to resubmit all packages which have been built successfully since the autobuilder SDK change on 2010-03-24[1]. I have already done that rebuild. The resulting packages can be checked here: https://garage.maemo.org/builder/.fremantletest/__packages__/ We can automatically import all rebuilt packages into extras-devel or we can decide to let developers re-submit their packages after the builder has been switched to the new setup. I definitely favour the resubmitting approach. It's easiest for developers by far; and so in terms of total effort is the lowest overall. Well, importing all the rebuilt packages is the easiest approach. However, will we have issues with version numbers? If we auto resubmit them, should we ensure that each package is resubmitted with a new version number? If so, a suffix of -20100415 would be sufficient? I really don't like touching source packages, that just feels wrong. Cheers, Andrew [1] http://lists.maemo.org/pipermail/maemo-developers/2010-March/025512.html -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Squeeze devkit to be installed to autobuilder
Hello all, Hi, As part of the plan to fix the PR1.2 SDK dependency issues in the autobuilder [1], we plan to upgrade the Debian devkit in the Fremantle autobuilder to the Squeeze version [2] (from the current etch one), and start using improved shlibdeps [3] (a.k.a. .symbols files) to version dependencies on a much more granular basis (minimal required version of libraries will be calculated per symbol instead of per library). We plan to ship .symbols files for most of the SDK libraries [4]. This means that packages built in the PR1.2 SDK using no PR1.2-introduced functions will work on a PR1.1 device and even on a 1.0 device. As part of this task we need to decide with the 'broken' or affected packages which have been built on the PR1.2 SDK and have gotten PR1.2 dependencies. We can automatically import all rebuilt packages into extras-devel or we can decide to let developers re-submit their packages after the builder has been switched to the new setup. Thoughts? -- Javier -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Packages interface - Warning: This package seems to be a library in a user/* section!
Hi Hi, Could someone explain what the packages interface considers my application as a library ? http://maemo.org/packages/package_instance/view/fremantle_extras-devel_fr ee_armel/libellule/0.0.1-3/ This is a rather lame check I added to prevent people submitting obvious libs as user applications. Starts with lib ;) I added an exception for libellule. I uploaded 2 anothers apps without problem... Thanks. David. -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Bora/OS2007 extras is dead? Re: ssh uploading to gregale/bora/chinook extras broken?
On Wed, April 7, 2010 18:22, Graham Cobb wrote: On Wednesday 07 April 2010 15:39:29 Frantisek Dufka wrote: Niels Breet wrote: Bora has been dead for a while now, chinook is also EOL. Bora is dead? Oh really? So why there is http://maemo.org/downloads/OS2007/ with old version I cannot update? When and why was this discussed/decided? It wasn't, as far as I know. Killing chinook was, and I agree that it is probably the right thing to do. But gregale, bora and diablo are important. Bora was not actively killed, just forgotten to setup last December. Since then nobody complained about it. Download numbers don't come above noise levels, but if you think we should keep it for a while then no problem. The queue for Bora extras should now be available again and should be processed like it was in the past. Graham -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Bora/OS2007 extras is dead? Re: ssh uploading to gregale/bora/chinook extras broken?
On Thu, April 8, 2010 13:15, Frantisek Dufka wrote: Niels Breet wrote: Bora was not actively killed, just forgotten to setup last December. Since then nobody complained about it. Date of last change is 22.12.2009 http://repository.maemo.org/extras/dists/bora/ Exactly ;) Turns out the sync to the caching network wasn't enabled, you should see it now. Download numbers don't come above noise levels, but if you think we should keep it for a while then no problem. Download as in getting *.deb file or just checking for updates? Do you know how many people (unique IPs) are checking for Bora updates? Downloading new packages may be rare since there is not much of new stuff. If I am the only one using it, it is OK to kill it :-) Don't see any deb downloads coming above the noise level in the caching network in the month March. So the number must be really low. And BTW, dput upload to bora worked few minutes ago, thanks. Let's see if it ends up in http://repository.maemo.org/extras/pool/bora/free/s/scummvm/ I see it there now. Frantisek -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Promotion
On Wed, April 7, 2010 10:06, Martin Grimme wrote: Hi, Hi, same here, so it might be a general problem with the Diablo promoter. Besides taking 9 days for the package interface to recognize that a package has been updated, and then complaining that the package didn't have a proper description (which it certainly has). The package icon is not imported, either. Please somebody look at the Diablo package interface to see what's going wrong. For information, my stuck Diablo package is 'fmradio-player 2010.03.20-2'. You use long lines in your control file where 80 chars is recommended. The importer didn't like that so it left the entries empty. I've now changed the importer to import long lines too. Regards, Martin -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Promotion
On Sun, April 4, 2010 20:42, George Kibardin wrote: Hi everybody, It seems that I missed something. Suddenly I cannot promote the latest version of my app from diablo extras-devel to diablo extras. I've read this http://wiki.maemo.org/Uploading_to_Extras, tried this https://garage.maemo.org/promoter/diablo and still no luck. I see my app in extras-devel, but there is nothing like promote button. The promote link is found on the armel version page of your application: http://maemo.org/packages/package_instance/view/diablo_extras-devel_free_armel/feedcircuit/0.7.6-2/ The link doesn't show because you are not using one of the sections listed in http://wiki.maemo.org/Package_Categories P.S. I see that for Fremantle promotion process is more complex, but I still cannot get the idea - what to do to initiate promotion process? Same thing. Go to the armel version of the package in fremantle extras-devel and click on promote. Best, George -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: ssh uploading to gregale/bora/chinook extras broken?
On Wed, April 7, 2010 12:16, Frantisek Dufka wrote: Andrew Flegg wrote: Permission denied (publickey). [...] fano...@garage:/var/www/extras/incoming/gregale' Should this now be drop.maemo.org? The change wasn't well communicated at all, especially the impact on the legacy servers. Oh, thanks, I totally missed the server name change. But anyway drop.maemo.org works for scp login but now I am getting scp: /var/www/extras/incoming/gregale: No such file or directory Seems I missed a link there. Does it work for you now? What are corect paths for binary uploads to gregale/bora/chinook? I've added gregale to the wiki here: https://wiki.maemo.org/Uploading_to_Extras-devel#dput Bora has been dead for a while now, chinook is also EOL. Frantisek -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PR1.2 SDK for Extras-devel: how to solve?
On Wed, April 7, 2010 16:41, Andrew Flegg wrote: On Wed, Apr 7, 2010 at 15:13, Bryan Jacobs n...@landwarsin.asia wrote: It seems to me that the real problem is actually the difficulty in implementing #4 above. If there were magically separate infrastructure for each incompatible release, there would be no issue - a developer uploads their package to each repository for which it builds (preferably through a list of checkboxes in the web interface), and a user selects one or more package sources that match the preinstalled software on their device. No problems, mate. True; however what about the QA process? The UI at http://maemo.org/packages/ is getting better, but it's also getting more familiar. How do we: a) not confuse ad-hoc testers b) ensure that versions in all repos get tested? This is a non-trivial issue. Testing against all repos is not going to work, imagine what happens when we have PR1.2+1 etc. One suggestion would be to promote all versions simultaneously, but there are obvious drawbacks with that! That would make the most recent repo the best supported and tested repo. Older repos might or might not work. But then again, that is what -devel is now too. So the real issue is that creating a new branch requires a nontrivial amount of work. This is a computerized system; computers excel at automation. Why not spend the one-off time to allow for near-instant creation of a new branch? Once that's done, future releases will just consist of oh, I should create a new repository for this release. Let me run that script again with a new name and then upload the new SDK release to it. Indeed. Have I missed some important consideration? I think the issues aren't technical (although streamlining the repo creation is obviously part of it), but more procedural. I could be wrong. There is also the technical issue that after SSU you would need to change your catalog settings in your device manually for -devel and -testing. Getting that changed in AM is probably not going to happen. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Dependency problems after PR 1.2 update to extras builder
On Tue, March 30, 2010 15:56, Andrew Flegg wrote: On Mon, Mar 29, 2010 at 15:37, ianaré sévi ian...@gmail.com wrote: After making some updates to my package and putting it up on extras-devel, it won't update on the device from the repository. I was able to install it on scratchbox (both prior to and after updating the SDK). So, AIUI (and others did too), the autobuilder would be upgraded to PR1.2's SDK and start publishing to fremantle-1.2 (rather than the current fremantle). It will for Extras, but not for extras-devel and testing. However, yesterday on IRC, there were some complaints that the auto-generated components for things in fremantle extras-devel had incorrect dependencies: It depends on your definition of incorrect ;) They are correct for running on PR1.2. I thought the fremantle extras-devel should now be fixed, so how are things with incorrect dependencies getting in? Niels, could it'd've been a race condition during the switch; or is it a bug; or are we corrupting fremantle extras-devel? Some time ago, when I noticed the issues with upcoming PR1.2 and saw the trouble with PR1.1, I tried to find a solution which could be implemented on a short term. The first priority was to protect the repository which is enabled on every device and is used by end-users. Extras will have a fremantle and a fremantle-1.2 repository, so old device users won't see the new dependencies and PR1.2 users will see the correct dependencies. Then it became clear that the PR1.2 SDK would be available before the firmware release. This is something developers asked for a lot and the idea was to give them the opportunity to get their applications ready for PR1.2 before it actually shipped. By enabling it on the builder, developers can get their updated app in extras-devel and check if everything builds against the PR1.2 SDK. The issue people see is that they are then trying to install the PR1.2 built application on a pre PR1.2 device. This might or might not work, depending on which dependencies are specified. In the short time there was between the time I knew about the PR1.2 consequences and the actual release of the SDK, there was not enough time to develop a cleaner solution for extras-devel and extras-testing. Extras-devel is expected to be running against the latest and greatest and always had the disclaimer about breaking your device. I hate the fact that it now actually does prevent applications from being installed though. Creating a separate fremantle-1.2 -devel and testing QA queue would probably have given more confusion and frustration than it would prevent and would have been hard to do within the available time. So, how to on go from here from my POV: * Hope that PR1.2 will be out soon, so people can test it on their own device. * Update the Packages interface with knowledge about the PR1.2 rootfs, so promotions to testing can happen. * Encourage all people with access to PR1.2 devices to test applications from the testing QA queue on their devices and give feedback to developers, so we can get those applications in fremantle-1.2 as soon as possible. * Look at the possibility of adding a hacked libhildon package in the builder, so it generates 'correct' dependencies and applications can be installed on PR1.1 if they don't use the new livesearch api. (Probably most of them) * Discuss how we can improve this situation for the next SSU. * Make a case for Nokia to convince them to give developers early access to PR1.2 images. Trying to do the right thing, I have the feeling that it backfired. :( Thanks in advance, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: What happend to the first page of popular downloads?
On Mon, March 29, 2010 11:20, ds wrote: It seems to me, that the top 25 of popular downloads (or the ones with more than 5 downloads?) are not displayed anymore in maemo-downloads-popular (hot) Popular (hot) is based on application karma. Which consists of relative download growth, rating and comments. That should not favor the most downloaded apps. If you want to see the list by downloads you should use this link: http://maemo.org/downloads/list/Maemo5/all/ That is also avaliable by clicking on the number behind 'Downloads for Maemo5' on the main page of Downloads. Detlef -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: What happend to the first page of popular downloads?
On Mon, March 29, 2010 17:13, ds wrote: Am Montag, den 29.03.2010, 15:10 +0200 schrieb Niels Breet: On Mon, March 29, 2010 11:20, ds wrote: It seems to me, that the top 25 of popular downloads (or the ones with more than 5 downloads?) are not displayed anymore in maemo-downloads-popular (hot) Popular (hot) is based on application karma. Which consists of relative download growth, rating and comments. That should not favor the most downloaded apps. OK, I did not recognize the change:-) Where is the algorithm documented, it looks to me a very strange result. What do you mean with relative download growth? What is the aim to put this in. Where can I find application karma ... Questions over questions:-) http://wiki.maemo.org/Task:Karma_for_applications http://www.mail-archive.com/maemo-commun...@maemo.org/msg02173.html Was quite a long discussion in this list :) -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Builder is creating zero sized packages (Was: Re: Package import into Extras-devel from the builder stucked)
On Fri, March 26, 2010 09:17, Ed Bartosh wrote: 2010/3/25 Henrik Hedberg henrik.hedb...@innologies.fi: Henrik Hedberg wrote: It seems that packages are not imported into Extras-devel after the builder has succeeded with them. Here is an example: I think I found the reason. The builder is creating empty packages. I doubt that. The packages themselves where fine. There was an broken package stuck in the non-free queue, which blocked the import of packages into the repository. Once packages are in the repository, the importer will fill in the correct values for the package size etc. I fixed the queue this morning, so everything should look better now. A fix has been implemented to prevent this from happening again. For example, http://maemo.org/packages/package_instance/view/fremantle_extras-devel_f ree_i386/jammo/0.4.6/ http://maemo.org/packages/package_instance/view/fremantle_extras-devel_ free_armel/gltron/0.70final-9maemo9/ http://maemo.org/packages/package_instance/view/fremantle_extras-devel_ free_i386/redmond-theme/0.1/ I don't see anything unusual from the builder logs: https://garage.maemo.org/builder/fremantle/jammo_0.4.6/ https://garage.maemo.org/builder/fremantle/gltron_0.70final-9maemo9/ https://garage.maemo.org/builder/fremantle/redmond-theme_0.1/ I am still hoping that it is easy and quick to fix... My guess is that something happened with the NFS share and files were truncated somewhere between builder and repository. Try to rebuild your packages. Most probably builds will succeed. No need to do that, it was purely caused by a stuck import queue. -- BR, Ed -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Maemo.org discover client, Was: Re: Re: maemo-developers Digest, Vol 59, Issue 25
On Fri, March 26, 2010 10:57, urho.kontt...@gmail.com wrote: - A maemo.org specific 'discovery client'. It interfaces with downloads.maemo.org over a custom protocol for browsing available applications. Right now it passes .install files to HAM for the actual installation, and my plan is to hook it up with mini-pacman instead and then optimize the hell out of the whole stack. (Haven't seen the code yet myself, Daniel Wilms and Niels Breet should know more.) I didn't even know of this. Is it community or nokia effort? Can we get url to the code repo? Appdownloader is in extras-devel now. This application talks with Downloads over an API. Marius, Daniel and I had a short brainstorm session about how we could make things better than AM at the moment. We agreed to create some proof of concept based on Daniel's application. The app itself is developed here: https://garage.maemo.org/plugins/ggit/browse.php/?p=appmanager Urho - Niels ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Builder now runs PR1.2 SDK with Qt 4.6 support
Hi, I've installed the new PR1.2 SDK on the maemo.org Extras autobuilder. Developers are encouraged to test their application in the PR1.2 SDK to see if everything still works as expected. If you have an application using Qt4.6, please make sure you switch to libqt4-* instead of libqt4-maemo5-*. Qt4.6 is on the device by default in the PR1.2 image. Promotion to Extras-testing and Extras for applications depending on libqt4-maemo5 will remain blocked. - Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: promote libs in user/* cathegory
On Mon, March 22, 2010 21:04, Till Harbaum / Lists wrote: Hi, Hi, the promotion interface refuses to promote my libzeemote-conf since it's a library which is in section user/* This imho doesn't make much sense since it's a) the config interface for my zeemote lib and why shouldn't a library have a user installable config tool and b) is of course a library like any other control panel plugin is. This is done so we don't get obvious libs in Downloads. As yours actually has an executable part, I can add an exception for that. How can i get this promoted? And no, i don't want to rename everything just because the promotion interface doesn't like my naming. I added an exception, so you should be able to promote it. But I still like zeemote-conf more than libzeemote-conf ;) Till Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Ask for removal of some packages from Extras Fremantle repository
On Mon, March 22, 2010 11:56, Robin Burchell wrote: On Mon, Mar 22, 2010 at 10:50 AM, Jeremiah Foster jerem...@jeremiahfoster.com wrote: Why are you guys interested in removing so many packages? Did you miss the thread asking for bugs wrt packaging to be fixed, which was met with crickets? Where was this? Same with the bugs themselves, it seems. [1] [2] While I wish there was another way to fix this, I don't think Khertan has mismanaged this in any way - he reported the bugs, he followed up on it, and has been met with silence on issues that annoy and frustrate the extras packaging process. [1]: https://bugs.maemo.org/show_bug.cgi?id=9494 [2]: https://bugs.maemo.org/show_bug.cgi?id=9608 To be fair these bugs are two weeks[1] and 4 days[2] old. You can't expect instant fixes to these things. Work is being done, sometimes takes a while because of the amount of work there is to do. Another fact is that this is a non-free app, we don't have many of those. This means that the codepaths in the interface and import scripts are being tested less than for free apps. -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Proposal: Switch autobuilder to PR1.2 SDK coming Wednesday
Hi, I want to propose to switch the fremantle autobuilder to use the PR1.2 SDK coming Wednesday March 24th, 12:00 UTC. This will give developers a last chance to get their application built on the 1.0 SDK. Every application promoted to Extras-testing before this time, will end up in both Fremantle and Fremantle-1.2 Extras. Once your application is built with the PR1.2 SDK, it will only go to the Fremantle-1.2 repository. The Fremantle-1.2 Extras repository will be a copy of the current Fremantle Extras repository. We might need to remove a very small number of applications when they prove to be incompatible, but those developers will be notified. -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Download statistics
On Wed, March 17, 2010 20:27, Cornelius Hald wrote: On Wed, 2010-03-17 at 19:58 +0100, Thomas Waelti wrote: Ok, that sounds good. Is app karma documented somewhere? I can only find this: http://wiki.maemo.org/Task:Karma_for_applications Yes, http://wiki.maemo.org/Karma In fact, it's even nicely linked from your profile page Karma :-) That is karma for people. We were talking about karma for applications. The karma for applications discussion was on this list, google should know. BTW, thanks Niels for silently fixing the Popular link. It's now pointing to http://maemo.org/downloads/score/Maemo5/25/ instead of http://maemo.org/downloads/downloads/Maemo5/25/ which makes a huge difference. Sorry, doing many things at the same time so I forgot to answer your mail. That link was obviously a bug that needed to be fixed. Thanks for noticing. Nothing wrong with communicating such a change, though. I sometimes need a post-commit hook which sends a mail to the list, it seems :) Conny -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Download statistics
On Wed, March 17, 2010 10:01, Cornelius Hald wrote: Hi, it's great to have nicely working download statistics now! I'm just wondering, what they are counting? Only downloads from Extras or also from Extras-testing and Extras-devel? I assume it's only Extras, but I'm a bit unsure because downloads are spiking during the last days and I've only updated -devel versions. It combines data for your package from all repositories. Another thing: The graphs for OS2008 software are stuck in the middle of January, whereas the graphs for Maemo5 show the middle of March. However the Last updated information for both is 2010-03-16. That data is actually updated too. But the download figures are very low. The graph only shows when there are real data points. Doesn't fill in the days where there are no downloads. Check omweather for instance, there you see data every day. Although the numbers are low. Thanks! Conny - Niels ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Download statistics
On Wed, March 17, 2010 12:58, Cornelius Hald wrote: Alberto Mardegan wrote: Cornelius Hald wrote: Also using the current download count for the Popular section of Downloads seems a bit unfair then. Shouldn't it be at least downloads/num_of_releases? Or better downloads_from_extras/num_of_releases? I don't think it's possible to know whether it is a new download, or an update. No, I don´t think either. But if we get numbers for each release, we could see something like: Ver Downl. 0.2 1000 0.3 1200 0.4 1300 0.5 700 0.6 200 This would at least show, that with version 0.5 people have somehow lost interest. Maybe I´ve made some radical UI changes that most people don´t like. Or maybe there is another (better) tool for the same task, etc... Lot of work, there are other more important things to fix first. Statistics are nice to look at every once in a while, other than that.. There is this saying about lies. But maybe limiting the download count for the packages downloaded from Extras only makes more sense. Which application is more popular? Which has more downloads? This shows, that is is especially unfair to young applications. This is why we have app karma, which drives the Popular list. If you look that design discussion up, you'll see that we use _relative_ download change, comments and ratings on a daily basis. Popular certainly doesn't show the most downloaded apps. Cheers! Conny - Niels ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Extras-testing improvements
On Tue, March 9, 2010 09:22, Alberto Mardegan wrote: Attila Csipa wrote: want better quality software, developers, testers, users, everybody. Let's make Extras-testing a place where we help applications get to Extras by improving them, not just kick them back to extras-devel, screaming. Thank you. I agree with Graham: I'd like the quarantine process to be only about critical problems, such as app not being optified, making the device unstable or not meeting some basic formal criteria (such as bugtracker link). You have to see that Extras should be for applications that are of a high quality. The Extras repository should not give any problems to people who are new to Maemo and have no clue how to work with linux for instance. Developers who want to have their applications available for the largest audience possible, should consider this. If adding a link to a bugtracker is too hard for a developer, can we really expect a quality application from them? I'm porting maemo-mapper to the N900; it is an application with a billion of features, and some of them are not working correctly, and the UI for certain operations is still unusable on the N900. Still, the application works fine and is perfectly usable for basic usage and it seems not to be harmful for the device. So, I wouldn't like it to be blocked from Extras just because some feature don't work (for instance, one commenter wrote on the testing page that he considers the absence of VirtualEarth maps to be a blocker, so he didn't vote for it, despite liking it). For Extras we really should aim for having end-user ready apps. We haven't been too strict about it, but we as a community should try to be on the same level as, or above Ovi ;) If your app works but is not yet ready for prime time, then consider what your audience is. Technical users will know where to find it. As to voting for features that are not in the list of items to be tested for, this should be solved by better documentation and explanations on the voting pages. Now new testers really don't know what to expect and use the voting as like/don't like. If applications are ugly or not completely working (but still not harmful), I'd like them to have a bad rating, of course, but still be available on Extras. I'm not sure about this. I think we need to grow up a bit and aim for something better than 'it works'. Ciao, Alberto -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Extras-testing improvements
On Tue, March 9, 2010 10:02, Sascha Mäkelä wrote: I would like to see more interaction between the dev and the Testing Squad. In the current system after the dev promotes the package to testing, all he can do is to hope that everything is OK. If it's not, he has to promote new package and everything starts from zero again. I don't think this good enough for anyone involved. This is how testing works in every project. A test succeeds or a test fails. If it fails, the developer needs to fix it. Lathe, rinse, repeat. What I would prefer would be a system where, testing is an ongoing process. That is, the dev can make fixes/improvements according to the bugs/suggestions reported by the Testing Squad and submit the updates often/early, without things starting from zero again. After the Testing Squad and the dev is happy with it, then the package could be locked and the short quarantine time (like 3 days, for example) would start. All testing is done in public, so it is a transparent process. The testers should test for the requirements as specified, if the requirements are met the app get a vote up. The quarantine time is there to have a certain period of time to find critical bugs. A simple test might not find them but we hope that if people are using the app for a while, this might become more clear. The quarantine is the last step before it will be installed on thousands of phones around the world. We have to be serious about quality. With current system either the package fails completely or the improvements will have to wait for the next update. This is of no benefit to anyone. The end users won't have as good apps as they could have. The Testing Squad should be renamed to Border Control, because they can't really improve any app. They can only block them. And finally, instead of feeling a sense of accomplishment for contributing to the community, the devs often feel just frustrated. QA and testing is not about devs. It is a necessary 'evil' developers need to go through to assure that end-users have the least amount of problems. We need to have a certain level of quality as a community. If you are not willing to strive for that, then Extras might not the place for you to publish your software. That said, we can always improve the QA process. Suggestions are welcome. It is not our plan to make your life as miserable as possible :) Cheers, Sascha -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Extras-testing improvements
On Tue, March 9, 2010 11:19, Riku Voipio wrote: On 03/09/2010 01:04 AM, ext Attila Csipa wrote: I hope Valerio won't mind me taking the initiative here, but I'd like once again to underline the testing-squad is not the Spanish Inquisiton nor do we adhere to a dogma which makes testing procedures unchangeable (and we certainly don't want to create/impose them without a general consent). Many of the problems brought up have been met before, are already known and have been/are being worked on to make Extras-testing as painless as possible (and yes, I also personally have several packages in Extras-testing that make me curse at some of the current rules, so I know both sides of this occasionally painful story :). I invite everyone who has not alredy done so to take a good look at http://wiki.maemo.org/Extras-testing/QA_Checklist/QA_Improvements From what I see, the problem is mostly that there is not enough voters.. Well, there are probably lots of more people who add extras-testing and even extras-devel to their devices and test random applications from there, but can't bother to vote the maemo.org website. I can see several reasons for this. 1) extras-testing voting is well hidden in maze of the website Yes, this probably needs to improve. Suggestions are welcome though. 2) Once you find the place, you get an ugly list (especially if viewed with n900): http://maemo.org/packages/repository/qa/fremantle_extras-testing/ CSS is here: https://garage.maemo.org/plugins/scmsvn/viewcvs.php/midgard-data/style/maemo2009/static/css/packages.css?root=maemo2midgardview=log Patches are appreciated, I'm not a designer by any means ;) There is no correlation with packages you have actually installed on your n900, so you need to browse around to actually find what to vote for. This is a harder part to solve, there is no way for the website to know what you have installed or not. 3) the website kicks you out randomly I noticed this too, need to find out why this happens. etc. no wonder we don't get many testers.. But I think perhaps the website is the wrong place anyway. a extras-testing-assistant application in extras that allows you to add/remove extras-testing to application manager, shows a list of packages installed from extras-testing and gives you a chance to thumb up/down. The appinstaller application might be a good candidate to add this testing and voting features to. It is currently in extras-devel and only using information from Downloads. But that can change of course. -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Extras-testing improvements
On Tue, March 9, 2010 12:12, Attila Csipa wrote: On Tuesday 09 March 2010 11:56:49 Matan Ziv-Av wrote: On Tue, 9 Mar 2010, Niels Breet wrote: You have to see that Extras should be for applications that are of a high quality. The Extras repository should not give any problems to people who are new to Maemo and have no clue how to work with linux for instance. Here's the problem, there seems to be two (almost opposite) goals for this extras repository: one is to be a collection of all maemo software, eliminating the use of external repositories, the other is having a collection only of high quality software. Until you accept that you can't have both, those discussions will go on repeating. There is nothing preventing (well, apart from autobuilder issues) people putting things into Extras-devel. It *is* a valid place for software, it's not the gutter, and not every application there is expected to enter Extras. I often feel the issues brought up in relation with the term 'quality' stem from different interpretations of the term - terminology. Exactly. Extras-devel is perfectly fine for experimental applications. People using extras-devel know they can expect applications to not be flawless. End-users using Extras should be able to expect proper quality applications. Some applications developers might not want to have their application comply with all QA rules, but then the consequence is that the app doesn't go any further up the chain. Regards, Attila -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
Niels Breet wrote: Hi, - Maemo 5 PR1.2 will ship with Extras enabled by default but will use distribution: fremantle-1.2 - 'older' devices will continue to fetch from distribution: fremantle - Autobuilder will be updated when PR1.2 is released and promotion will only happen to fremantle-1.2 Sorry if I'm a little late to this discussion, but if we're creating a new distribution/repository which means there will be problems with existing install files, wouldn't it be easier just to hack apt-* on PR1.2 so that it looks for a new fremantle-1.2 distribution for the Extras repository when the distribution is called Extras/fremantle? The Application manager will be changed to use fremantle-1.2 as default distribution. It's not going to be nice hacking apt-get, but surely this would be much easier than hacking changes into numerous services so that they detect the firmware version downloading the file in order that the correct install file can be served up. By setting the default distribution, we don't need to do any detection. In addition, if I back up my Extras/fremantle catalogue prior to reflashing with PR1.2, will PR1.2 then automatically replace Extras/fremantle with Extras/fremantle-1.2 after I restore all my catalogues? If it doesn't, my device may have both Extras/fremantle and Extras/fremantle-1.2 in it's source list, or the former may overwrite/replace the latter, so is this likely to be a problem? Most likely yes, as I then run the risk of downloading incompatible Qt4.5 apps from Extras/fremantle. The default 'maemo.org' entry in your catalog list will be changed to use fremante-1.2 as distribution. When restoring backups the default repositories will not be overwritten. All repositories you have added yourself will be restored as normal. But keep in mind that extras-testing and extras-devel won't change as they are expected to run the latest. If apt-* could be hacked in PR1.2 to special case Extras/fremantle into Extras/fremantle-1.2 on the http download, then install files would continue to work unchanged, and restored backups would also work unchanged. There seems to be no need to hack apt with current changes. In the same way, if an Extras/fremantle-1.3 is required in PR1.3, the same hack would be applied to apt-* in PR1.3 and nobody would be any the wiser. Let's hope that is not needed ;) Regards Neil -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Garage project takeover
Hello, Hi, I am currently doing some maintainance work on DOSBox for Maemo (and I am the author of the current package in -devel). In order to fulfill the extras QA bugtracker requeriment and my own need for a VCS repo, I considered registering a new project in Garage, but found that the project was already registered. Quite a few months ago I contacted the maintainer, but he hasn't answered yet, and the Garage interface won't let me spam him again until he accepts or declines the current request. So, a week ago, I sent him an email, with still no reply. I could register a dosbox2 project, or just ignore Garage and go straight to a b.m.o component and a gitorius project, but since the Garage project already exists and is virtually empty, I'd like to know if there's any policy about takeover of empty/abandoned Garage projects by new maintainers, or to kickstart discussions about one if it does not exist yet. The project is completely empty and doesn't seem to be used since it has been created on 2007-12-08. I can set you as admin for that project as you seem to be a lot more active than the current admin. I'd like to get an OK from the council so we all agree on this. If there had been data in the project it was a more difficult decision, but now it seems completely empty. A policy on this kind of takeovers doesn't exist, but I guess common sense and communication would help solve issues like this. DOSBox garage link: https://garage.maemo.org/projects/dosbox -- Javier -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Maemo 5 PR1.2 and Extras
Hi, Maemo 5 PR1.2 seems to be a release with some large changes which are not backwards compatible with previous releases. Most visible change will be the inclusion of Qt4.6, but there will be some other smaller changes. We have prevented SDK upgrades in the past to keep software in Extras backwards compatible, but with this change this does not seem possible. I want to propose the following changes: - Maemo 5 PR1.2 will ship with Extras enabled by default but will use distribution: fremantle-1.2 - 'older' devices will continue to fetch from distribution: fremantle - Autobuilder will be updated when PR1.2 is released and promotion will only happen to fremantle-1.2 This will effectively mean that the 'old' Extras will not get any updates. New versions of applications will go to fremantle-1.2 Extras. Extras-devel and Extras-testing will not be changed, as they are expected to run the latest and greatest anyway. I proposed not to update fremantle Extras, because we would then need to setup separate builders and more importantly different QA queues. This will bring a lot of work and confusion to testers and developers, I want to prevent that. Nokia will encourage people to upgrade to the latest release as much as possible and we expect people to switch to PR1.2 at a high rate. Please let me know what you think, we have to come to a consensus as soon as possible if we want to have this change included in PR1.2. -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
On Wednesday 24 February 2010 12:21:45 Niels Breet wrote: Please let me know what you think, we have to come to a consensus as soon as possible if we want to have this change included in PR1.2. How will this PR1.2 change be reflected on the maemo.org dowloads section (i.e. how will it be ensured that the user gets presented the correct install-this link) ? A different .install file can be offered based on your browser string. Second, is there a safety mechanism considered that will disallow inclusion of 'the other' firmware's repository to prevent potential version-related breakage ? There is not a lot we can do there. If a user adds the repository on an 'old' device, some applications just won't install because dependencies are missing. This will effectively mean that the 'old' Extras will not get any updates. New versions of applications will go to fremantle-1.2 Extras. Extras-devel and Extras-testing will not be changed, as they are expected to run the latest and greatest anyway. What happens to apps (especially those with Qt dependencies) _currently_ in Extras, i.e., how will they get to the fremantle1.2 Extras repo ? The Qt apps are currently blocked from being promoted to prevent issues. The fremantle-1.2 repository will probably need to be 'legacy' clean. Qt 4.5.3 is not available in Extras and will probably not be available on any repository enabled by default on the device. This means that applications depending on this, will not work. Those applications need actual changes to work with Qt4.6 iirc. Regards, Attila -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Garage project takeover
If renaming is possible would be a better option IMO. Unfortunately gforge doesn't let you rename projects as lists, scm etc are also linked to it. Best regards, -- Valério Valério http://www.valeriovalerio.org -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
hi, Niels Breet wrote: Maemo 5 PR1.2 seems to be a release with some large changes which are not backwards compatible with previous releases. Most visible change will be the inclusion of Qt4.6, but there will be some other smaller changes. When you say not backwards compatible, does that mean that applications built with 1.0 or 1.1 will not work on 1.2? That would be forward compatible in my book ;) Or is it ABI compatible, but adds new interfaces, so that applications built with 1.2 won't necessarily work on 1.1 or 1.0 (which is a different less serious issue in that if you don't use the new interfaces your application should still work unchanged on the older releases)? Applications built on PR1.2 won't work on older versions. There are exceptions, some applications might work, but those make this very complicated. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
On Wednesday 24 February 2010 11:21:45 Niels Breet wrote: - Maemo 5 PR1.2 will ship with Extras enabled by default but will use distribution: fremantle-1.2 - 'older' devices will continue to fetch from distribution: fremantle - Autobuilder will be updated when PR1.2 is released and promotion will only happen to fremantle-1.2 I can't say I like this. My personal view is that there will be a lot of people running earlier software for quite a long time. How long do Nokia believe it will be before 80% of new devices being sold in retail stores have PR1.2 pre-installed? Can we keep track of stats showing how many people are accessing the old repository? Nokia retail figures - ask Nokia. I'm pretty sure that getting that info will not be easy. I have the Extras downloads figures now. So we can check the percentages after the switch. However, as I don't have any evidence, I don't object to this approach. It at least leaves the door open for the community to decide later that we do need to update the fremantle extras, if necessary. Let's go with it for now. We do need to have a plan for exactly when the changeovers will happen. When will the autobuilder switch over and when will the promotion interface change? Developers need to know so they know what they need to do if they need to get a final update out to PR1.1 users. The same day as the SDK will be released seems to be a right time for me. I don't know the exact release date of course. I'll make sure things are prepared in advance, so the actual switch can be done relatively quickly. For example, I have the GPE stuff sitting in extras-testing. I would really like this to make it into the PR1.1 repository, even though the next update will only make it to PR1.2. True, this is something we need to think of. It is clear for every promotion happening before the PR1.2 release, but when we switch it will go to fremantle-1.2 by default. (Unless we do something to prevent that) Graham -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
Hallo! What happens to apps (especially those with Qt dependencies) _currently_ in Extras, i.e., how will they get to the fremantle1.2 Extras repo ? The Qt apps are currently blocked from being promoted to prevent issues. The fremantle-1.2 repository will probably need to be 'legacy' clean. Qt 4.5.3 is not available in Extras and will probably not be available on any repository enabled by default on the device. This means that applications depending on this, will not work. Those applications need actual changes to work with Qt4.6 iirc. No, what happens witht he packages currently ine extras? fremantle-1.2 will just be a copy with applications which don't work removed. * Will they automatically moved to fremantle-1.2 Extras? All apps that are not touching the changed APIS are expected to work just fine. Nokia people are running Extras apps on PR1.2 test images just fine. * Will they automatically rebuild against then current SDK? if yes, how do we find out it will work? Testing shows not a lot of problems, only the obvious Qt apps. * Will fremantle-1.2 Extras be intially empty and we have to get all packages in it again trhought he extras-testing process (Ooohhh, n, that will take ages!) No, don't worry. -- GruÃ... Tim -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
I would prefer if devs could get the PR1.2 update a week or so earlier than the general release. This way most of the necessary updates from Qt 4.5 to 4.6 could be done before the general public gets the new firmware. It looks like there is a chance to get the SDK out before the actual device OS update, but the discussion is still going on. I hope to have more information on that later. Also the normal 10 day quarantine should not apply to these case. I'm not sure if that is a good idea. The quarantine is there for a reason, the switch between these Qt releases can actually introduce issues. If we have the SDK in time, then the overlap will be minimal anyway. Thanks, Sascha -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
How will this PR1.2 change be reflected on the maemo.org dowloads section (i.e. how will it be ensured that the user gets presented the correct install-this link) ? A different .install file can be offered based on your browser string. How are you going to make sure you catch all of them ? For MicroB, okay, but Firefox, Tear, Midori, whatnot ? Does not really sound like a foolprof solution (you also need to sync with Maemo Select, and just hope that there are not too many links floating around) :( I see no way to support other browsers if they don't expose the installed OS version. But I think this is how Ovi checks it too? Maemo Select links directly to us, so there is no issue with .install files there. Second, is there a safety mechanism considered that will disallow inclusion of 'the other' firmware's repository to prevent potential version-related breakage ? There is not a lot we can do there. If a user adds the repository on an 'old' device, some applications just won't install because dependencies are missing. There are a few more troublesome scenarios that can present themselves - like if someone adds the old repo, and has a repo-refresh issue with the new one afterwards (I often have this problem with extras-testing and extras-devel). In both this and the scenario you mention, H-A-M/apt will prevent downgrades, luckily, but it's easy to cut off your own upgrade path if you DO manage to install something from the wrong repo. If you break something, you get to keep both pieces. Being able to break things yourself is a powerful thing. I don't see how we can prevent installing something from a wrong repo. What happens to apps (especially those with Qt dependencies) _currently_ in Extras, i.e., how will they get to the fremantle1.2 Extras repo ? The Qt apps are currently blocked from being promoted to prevent issues. It would be helpful if this would be visible from the testing page, too (not just for 4.6). I have several Qt4.5 dependent packages in the QA queue nearing required quarantine delay fulfillment. It's just a waste of tester and developer time then. Well, no. They can still end up in fremantle for PR1.1 and lower. The fremantle-1.2 repository will probably need to be 'legacy' clean. Qt 4.5.3 is not available in Extras and will probably not be available on any repository enabled by default on the device. This means that applications depending on this, will not work. Those applications need actual changes to work with Qt4.6 iirc. Okay, so we basically ditch Qt4.5-compiled applications currently in Extras. Is the Ovi team aware of this as there are quite a few Qt 4.5 applications in Ovi repositories,too ? Will they get their fremantle1.2 repo, too (I know, ask them - wait for a meaningful response so long that it becomes moot :) ) or will they hope Qt ABI compatibility gets them through ? And if you think Ovi has no bearing on Extras downloads, take into consideration Firefox is in Ovi, so if browser string based info is used, it will bite you if it's not handled in a timely manner :) Don't know what Ovi is going to do, but my bet is that Nokia aims at Qt4.6 anyway to in line with Symbian? Just trying to do the best thing for everybody, easiest would be just to not care about older OS versions. Regards, Attila -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: autobuilder down (diablo and fremantle)
Just tried to upload, but upload does not work? This was caused by the announced maintenance. It should have been working for a while again. Detlef -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Is package importing working?
There was a package 'stuck', which prevented the update. Everything should be back to normal soon. -- Niels Breet maemo.org webmaster Yesterday evening it worked ok, but this morning I have the same problem. On Mon, Feb 15, 2010 at 2:23 PM, Luca Donaggio donag...@gmail.com wrote: It seems so... I promoted a package from -devel to -testing three hours ago and the package interface is reporting its status as promoted but not imported yet. On Mon, Feb 15, 2010 at 1:20 PM, Sascha Mäkelä sascha.mak...@gmail.comwrote: Two days ago autobuilder wasn't working for me. Now that it works, package importing doesn't seem to work, as I uploaded a package some time ago and while building succeeded, it hasn't been imported yet. This is getting old... Anyway, has anybody noticed the same? Thanks, Sascha -- Luca Donaggio -- Andrei Mirestean ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder repository priority ?
On Tuesday 03 November 2009 21:31:29 Attila Csipa wrote: Foreword: My particular problem is not that big of an issue, in the end I went for extras-devel compatibility, no big deal, it's not yet for end users anyway. It's the generic approach that is at question here - tomorrow someone else will fall through the same manhole and it might become a recurring issue. And yes, I got oopsed by this again, but this time around it's worse (hence my unzmbification of this thread). My package was already in the testing quarantine when somebody else promoted a package depending on it. As a result, new versions of my dependencies from -devel got silently promoted to -testing, so when I promoted my package, unbeknowst to me, I was actually promoting the packages from -devel. But wait, the plot thickens ! As we only had overlapping dependencies with the other project, this means now I also have not only stuff from -devel in Extras, but actually a funky mix of versions, something nobody tested for. The worst part is I cannot make a quick fix as it would have to go (again) through the 10 day quarantine. Please, let's reconsider the promotion/repository logic as per the ancient thread this message belongs to. Thank you :) This problem stems from the fact that we don't have real maintainers for packages. In the past anybody could move packages to extras, the new process changed that. But to make it not too complicated the whole automatic promotion of dependencies was introduced. As part of the growing up, we need to move towards a more formalized way of maintaining of packages. In current February Sprint, I have a task (10.02-12) to create a proper maintainer interface. As part of that task I want to implement promotion of dependencies only if they are owned by you or don't have a maintainer. This needs to be refined more, I hope to have time to work on this this month. Not promising that it will be finished this month as there is a lot going on. Regards, Attila -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Qt 4.6 Extras
So please, don't promote Qt 4.6 apps to Extras-testing and if there is any already there don't promote it to Extras. Don't worry, the Qt and maemo teams are working at full speed to get that release/update out in a reasonable time. I'll put a check and block in place in the Packages interface so these apps won't travel further anymore for now. Once Qt 4.6 is integrated in Maemo5, I'll remove the block again. -- Quim Gil open source advocate Maemo Devices @ Nokia -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Upload to fremantle-extras-builder broken?
On Thu, January 28, 2010 21:21, Anderson Lizardo wrote: On Wed, Jan 20, 2010 at 3:00 PM, Niels Breet ni...@maemo.org wrote: This changed. It should be drop.maemo.org. If you replace garage.maemo.org with drop.maemo.org, everything should work fine. Not sure if this has already been reported, but I see this (apparently harmless) error when using dput: sh: /tmp/xxx: Permission denied Seems to come from some script on the server side. Yes, this seems to be some left over debugging. Has been removed now. Thanks for reporting it. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: What is status of Diablo promoter
On Wed, January 27, 2010 01:51, Bruce Forsberg wrote: Anyone know the status of the Diablo Promoter. Not existing anymore since the server move. The old version could not work in the new infrastructure setup. Work has begun to setup a promoter using the packages interface. I hope to have more news on that at the end of this day. Thanks, Bruce -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo.org incorrectly reports broken dependency
On Sun, January 24, 2010 15:39, Till Harbaum / Lists wrote: Hi, Hi, i can't promote maep 1.3 into testing because maemo.org claims that it has broken dependencies: http://maemo.org/packages/package_instance/view/fremantle_extras-devel_fr ee_armel/maep/1.3/ This is 1) not true as it installs fine on the real thing 2) is really strange since the autobuilder created that version This is because the app got compiled in the short period we had pr1.1 on the builder, before this got reverted. Check the incompatibility discussions about this on this list last week. How do we solve this? Do i just have to upload the same source code again as this was a glitch in the autobuilder? Or will this be fixed in maemo.org side? If you want this fixed quickly, you should submit a new revision to the builder. We still need to do rebuilds for the affected apps. Till -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Build Server Configuration
On Mon, January 25, 2010 16:22, Jeff Moe wrote: On Saturday 23 January 2010 04:07:48 Ed Bartosh wrote: The buildserver has been running nice and fast the last 48 hours or so--lots of packages have been pushed through. :) Will be even better in the near future, there are still some delays that can be reduced. What distro/release is the build server running? I have generally set up Debian Lenny KVMs to use and have one set up to be used with sdbmock, but if something more recent or older is better, let me know. You are in luck. We run Debian Lenny on the builder too, so no need to change there. Of course having a dual quadcore Xeon helps too. Thanks, -Jeff http://wiki.maemo.org/User:Jebba -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Changing chinook support to archive mode
Hi, It has been quite a while since diablo became the successor of chinook. I think it is time to make the chinook repository read-only and close down the builder instance for it. maemo.org would then support the latest stable releases for each device generation out there. gregale for 770 diablo for N800 and N810 fremantle for N900 This would let us concentrate on improving the features for the platforms that are actually in use. Comments welcome. -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Aw: Autobuilder = ww.maemo.org
Hello! Hi, Hmm, I know tzhis is a hated question, but is the autobuilder for fremantle alive? it is, seconds after sending the mail, the first OKs arrived. fine! Pure coincidence, I didn't get to -developers list in my mailbox yet :) This however may make my suggestion even more valid, making me not writring silly i do not have trust in autobuilder that fast, making admina smoking more cigarettes than before. ? If you subscribe to the extras-cauldron-builds list, you could see that there was a package severely stuck. Ed promised to create a fix for buildme, so broken packages can't block the queue anymore. Btw, besides hick ups the builder appears much faster now. That is great! -- GruÃ... Tim -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Upload to fremantle-extras-builder broken?
I used to upload with dput and signed packages. Now I get no permission,can anybody help? I recognized that the host signature had changed, but I can not rememberwhat might have changed too. Thanks Detlef dput.cf file: [fremantle-extras-builder] login = dschmicker fqdn = garage This changed. It should be drop.maemo.org. If you replace garage.maemo.org with drop.maemo.org, everything should work fine. -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder build error (unmet dependencies)
Hello! Hi, Is this an effect of the PR 1.1 problem and I have to rebuild libIllumination, too? Yes. What you see there is that libillumination0 is built against newer gstreamer and libosso (from pr1.1) The fastest way to solve this is to submit the package again (increase revision) -- Gruß... Tim -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Autobuilder build error (unmet dependencies)
Is this an effect of the PR 1.1 problem and I have to rebuild libIllumination, too? Yes. What you see there is that libillumination0 is built against newer gstreamer and libosso (from pr1.1) The fastest way to solve this is to submit the package again (increase revision) Have all the existing extras-* packages been (automatically) tested against the new SDK? I suppose that's the best way to make sure that they will all be installable. No, that still needs to be done. Jeremiah was working on something that created a list of affected packages. Apologies if I missed the announcement of this. Well, there wasn't one :) Cheers, Simon -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Reverting autobuilder to fremantle sdk maemo 5 update 1
Hi, To prevent issues with backwards compatibility for applications in fremantle extras-devel, we're going to revert the autobuilder to the previous sdk repository. This will give us some time to come up with a better solution for PR1.2 and will not create a lot of issues in the meanwhile. All applications which have been compiled against the new sdk will be recompiled. If you can't wait for this recompile, please submit a new version to the builder. -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Reverting autobuilder to fremantle sdk maemo 5 update 1
On Tue, 2010-01-19 at 14:25 +0100, Niels Breet wrote: Hi, To prevent issues with backwards compatibility for applications in fremantle extras-devel, we're going to revert the autobuilder to the previous sdk repository. And this breaks applications trying to use new packages, like sharing-dialog-dev Yes it does. This has also negative sides, that is why doing things like this is a hard decision. More applications are not using the new features than the other way around. Work and discussions are going on to have this sorted out for PR1.2. -- Kaj-Michael Lang mil...@tal.org -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDK rootstraps updated
2010/1/18 Graham Cobb g+...@cobb.uk.net: On Monday 18 January 2010 14:08:07 Jeff Moe wrote: Take note, since the service restoration, the Maemo 5 SDK rootstraps have been (silently?) updated with no changes to timestamps: Thanks Jeff for noticing this. Niels or Ed, do you have any idea what has happened here? Unfortunately I'm not aware of any changes. And autobuilder still uses old SDK rootstraps unless Niels or other admins did something. The updated rootstraps are probably there PR1.1 ones? Wasn't the sdk updated at the same time as the PR1.1 firmware? The autobuilder has not been updated yet, this is on my todo list still. I hope to do that this evening. (UTC+1) Ed: Can you see if you the devkit for pr1.1 needs to be changed for the /opt bug? I haven't had time to follow that at all lately and I don't want to mess things up :) -- BR, Ed -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Backwards compatibility broken PR1.1 SDK
Hi, I've been discussing this issue with some people before as hypothetical case, but now it seems that we run into it: Compiling an application against the PR1.1 SDK creates packages which can not be installed on earlier firmware releases. In this case we have have a libosso version which is higher than the one in previous releases. As this dependency gets automatically added when compiling in the PR1.1 SDK this poses a problem. The autobuilder uses the repository.maemo.org repository, so it automatically uses newer packages when they are available. For Extras this means that install of an application which is compiled against the new SDK fails without any description we can expect an end-user to understand. This is something which should be prevented. How can we work around this problem: 1: Only compile against the original SDK. This prevents new features from ever be available to developers, but should work until there is real API/ABI breakage in a new firmware. 2: Use version specific repositories This needs Application Manager support as we need to fetch from a separate repository every time. Also requires us to build against every sdk version known to man. 3: Depend on = mp-fremantle-generic-pr | maemo-version We would need a hack in the autobuilder to add depends to pr and maemo version. This way a user needs to upgrade to at least the required firmware image. I think this will make it easier for an end-user to understand what is happening. We could, with help of the AM team, even detect in the AM that a firmware upgrade is required and give a the end user a nice warning/description. Currently the AM doesn't have any means to detect which firmware version a package requires. Option 3 solve that issue at the same time. If you have an alternative solution on how to go about fixing this issue, then please let me know. Can we, like with the opt problem, come to a solution with community power[tm]? -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Extras-devel repository index out of control?
Hi, Hi, even I have noticed now that apt uses a lot more space than it used to. One reason is that the package index files in the repository contain entries for multiple versions of a package. This increases the size of what apt has to download, process, and store significantly, and for no real benefit. snip I don't know if there is a mechanism in place to control this growth, but there should be. That is on the agenda for this Sprint or the next. But it is something we will address. Server move had priority over improvements. I think it would be fine to retain only the most recent version for each package in extras-devel. We can still keep older versions in the pool, and we can even make a extras-history repository that indexes all these old versions. But for extras-devel itself, I think having only one version is best. If there are no dependencies on older versions, yes. But we must also not forget that extras-devel is really not for end-users, so this should not affect a lot of people. -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: apt-get pinning Extras repositories
Hi, Quite recently the extras-testing and extras-devel repositories had a Label: extras-testing set in the Release file. This allowed me to use /etc/apt/preferences to pin the testing/devel repositories to a lower priority, so that I wouldn't need to worry about getting unwanted upgrades from them. But recently, these labels vanished from the release file, and the extras and extras-testing Release files seem identical, allowing no way to pin them. Could the repo maintainers add the Label back, so that pinning would still be possible and easy? (Or is there an alternative way to do the pinning?) https://bugs.maemo.org/show_bug.cgi?id=8072 I've fixed that, will take some time for it to be visible. -- Pauli Virtanen -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder is broken again
Hi guys, Hi, Do you happen to know who switched off armel builds and why? We didn't touch it at all. Was there a lock file left behind or something? As I can see from yesterday evening autobuilder performs only i386 builds. If i386 packages are uploaded to the extras-devel it would lead to even more confusion among developers, because armel versions are not built, but reuploading would not be possible, because of i386 versions in the repo. I'd propose to switch autobuilder off while you do your work instead of breaking it so often. All work is being done on the new servers, not touching the old ones. And the build machine itself is left alone anyway. -- BR, Ed - Niels ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo extras downloads keeps resetting description for liqtorch and liqflow
On Fri, December 18, 2009 13:23, Gary Birkett wrote: hi, Hi, a couple of my apps landed in extras yesterday and I have added screenshots and changed the description text for both but they keep getting reset? the revision history for the pages shows clearly that I have edited the text, but something keeps screwing up these are the descriptions I keep setting, but they keep being set back to the defaults: It fetches all information from your package. The idea is that your package should be 'complete' enough to describe itself. The description field needs to be hidden for Maemo5, but not for the other operating system versions. That should clear up the confusion. gary -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Pushing optified Python libs
On Fri, December 18, 2009 01:59, Anderson Lizardo wrote: On Thu, Dec 17, 2009 at 5:43 PM, Mikko Vartiainen mvartiai...@gmail.com wrote: would there be a possibility to push them to Extras forcing an update in the background? It may be again noted that pushing library updates for end users is practically impossible because Application Manager doesn't update packages which are not in user/* category. BTW, I tested putting packages in user/hidden category and indeed (albeit autobuilder complaining about the unknown category) application manager recognizes new versions of packages in that category (showing the update notification and allowing to upgrade). This is bad manner and utterly evil. User _applications_ should be in user/* categories. (Basically everything you want the end-user to see and be able to uninstall) Everything else should never be in user. Please don't expose end users to the mess of uninstalling python because they need space, while they still have python apps in their device. This will only confuse them. The whole library updating might be painful, but don't misuse the user categories for this. The easiest way to update the python libraries for now is to either promote an application depending (= the new version) or ping me to manually push them through. The advantage of having an app use the new version is that you get testing of the dependencies too. Yes, updates won't be instant then, but this way they have the 10 day quarantine too. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo extras downloads keeps resetting description for liqtorch and liqflow
On Fri, December 18, 2009 14:30, Cornelius Hald wrote: Niels Breet wrote: On Fri, December 18, 2009 13:23, Gary Birkett wrote: It fetches all information from your package. The idea is that your package should be 'complete' enough to describe itself. Would it then be possible to remove those field from the site where you can manually edit this information? Because I think there the real confusion comes from. To quote myself: The description field needs to be hidden for Maemo5, but not for the other operating system versions. That should clear up the confusion. You seem to have missed that line ;) Cheers! Conny -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo extras downloads keeps resetting description for liqtorch and liqflow
On Fri, December 18, 2009 15:46, Dave Neary wrote: Hi, Niels Breet wrote: On Fri, December 18, 2009 14:30, Cornelius Hald wrote: Would it then be possible to remove those field from the site where you can manually edit this information? Because I think there the real confusion comes from. To quote myself: The description field needs to be hidden for Maemo5, but not for the other operating system versions. That should clear up the confusion. You seem to have missed that line ;) Actually, speaking for myself, I just didn't understand. You mean that the description field on the product page should be hidden from the user completely? Or from the maintainer who edits the page? For example, on http://maemo.org/downloads/product/Maemo5/omweather/ the user still needs to see Weather Forecast on Nokia N900. Ultra-customisable weather widget for showing forecast the way you want. Do you mean that the Description field on the page http://maemo.org/downloads/product/edit/37ee3e5ca78011debca0d72dcd1bdfb1df b1/ needs to be hidden? Or made read-only? Read-only or hidden in Edit indeed. So at least we don't give people the illusion that editing that value will change anything. Hiding the value on the product page wouldn't make any sense of course :) How else would a user get an idea of what the app is about. But yeah, I should have used a few more words to explain. Cheers, Dave. -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Pushing optified Python libs
On Fri, December 18, 2009 15:28, Dave Neary wrote: Hi, Niels Breet wrote: User _applications_ should be in user/* categories. (Basically everything you want the end-user to see and be able to uninstall) Everything else should never be in user. Where should it go? The packaging policy[1] only explicitly mentions user/* sections, as does the wiki [2]. As best I can tell we should be using Debian policy for everything that doesn't appear in the application manager. Here's section 2.2 of the packaging policy [1]: 2.2 Sections Packages are grouped into sections as in Debian, but SHOULD NOT specify a category in the segment part. (However it is not a bug if a package taken from Debian and made available in maemo retains its contrib or non-free segment.) Instead maemo defines a user segment for controlling visibility in the Application Manager. Packages that are intended to be visible in the Application Manager MUST belong to the user segment, and packages that are not intended to be visible (such as libraries and other dependencies) MUST NOT belong to that segment. [snip] Packages not in the user segment SHOULD use the sections listed in the Debian Policy (http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections). Looking at that page: The Debian archive maintainers provide the authoritative list of sections. At present, they are: admin, cli-mono, comm, database, devel, debug, doc, editors, electronics, embedded, fonts, games, gnome, graphics, gnu-r, gnustep, hamradio, haskell, httpd, interpreters, java, kde, kernel, libs, libdevel, lisp, localization, mail, math, misc, net, news, ocaml, oldlibs, otherosfs, perl, php, python, ruby, science, shells, sound, tex, text, utils, vcs, video, web, x11, xfce, zope. So python looks like a promising section. Yes, python is ok. As long as real end users don't see it in the Application Manager. Developers have python available in SDK and also know how to handle either red-pill or apt-get. The easiest way to update the python libraries for now is to either promote an application depending (= the new version) or ping me to manually push them through. A library maintainer currently has no way to vote for/test a library have it get promoted by the normal QA process? I can imagine, for example, a situation where a library gets updated, fixing a lot of bugs, but the application depending on it doesn't bump the depends version. In that case, what should the maintainer do? Ping you to have it promoted? We've discussed this at the summit and came to the conclusion that we basically need library maintainers. Another conclusion was that we needed to discuss that further :) Until we have the repository/library maintainer track sorted out, I propose to follow these steps: - If you are not listed as maintainer for an existing library and still want to have it updated, contact the maintainer. If the maintainer is not available or doesn't respond, mail to maemo-developers list. *** Please don't update a library maintained by anybody else without consent or public discussion*** - The maintainer/author uploads new version, checks if applications using the app still work correctly. - Ping me or mail -developers to push it through manually to testing. Here we can all do a final test to see if nothing breaks. I hope to have an interface for maintainers available in the beginning of the new year. This doesn't solve the problem that the Application manager doesn't update libraries on their own though. That problem should be a separate discussion. Cheers, Dave. [1] http://maemo.org/forrest-images/pdf/maemo-policy.pdf [2] http://wiki.maemo.org/Maemo_packaging -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Pushing optified Python libs
On Fri, December 18, 2009 15:49, Mikko Vartiainen wrote: However, we've just hit a major regression caused by an attempted Python optification bugfix with failed QA. Although I believe the issue has been solved now, I think we need to sit on the package in extras-devel for a week or so before pushing it to testing (Python optification is implemented in a manner that optification bugs may cause a systemic failure in the whole Python subsystem). Pymaemo-optify 0.2 has landed Extras (or at least Downloads) http://maemo.org/downloads/product/Maemo5/pymaemo-optify/ What happened here and how it's even possible? An application depending on python2.5-minimal got promoted to Extras from -testing. Python2.5-minimal depends on pymaemo-optify, so that got promoted too. The question is why it shows up in Downloads as it is in section devel and not in a user/* section. This is something I need to check more closely as that seems to be a bug in the importer for Downloads. -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Suddenly I got a msising dependancy for an app in -testing
Hi, mrawviewer 1.0-maemo7 has been in extras-testing since Oct 27 without any issues, when suddenly on Dec 09 i reeived a comment that it is segfalutling on a brand new N900. I checked the app page here [1] and noticed a missing dependency: libraw-lite (on which it depends to decode RAW images and which I've packaged and uploaded myself to extras-testing together with the main app) has suddenly disappeared from the repo! By the way: the same notice is displayed for the new version of mrawviewer (1.1-1) which is still in extras-devel [2]. Can someone check and tell me what's happend? The segfault issue and what is being displayed in Packages is not related. The lib is in the repository, there is just a bug in the Packages interface calculating the dependencies. I'll try to fix that display issue asap. This doesn't change anything about your app, you have to look for another reason why it segfaults unfortunately. Thanks in advance, Luca Donaggio -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: The issue of version strings
On Thu, October 29, 2009 09:01, Martin Grimme wrote: Hi, hmm, what's so bad about a simple date for a version number? Ubuntu does it, (Open)Solaris does it, and I started doing it, too, because I found it less confusing than having version numbers such as e.g. 0.96.5. Sane version numbers should at least not look like this: 2.0.0+cvs20040908+mp4v2+bmp-0ubuntu6maemo1 And yes, this is an actual package version number ;) Martin - Niels ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo.org/packages not identifying new version correctly?
Hi, On Wed, October 21, 2009 17:28, David King wrote: I uploaded glom 1.12.2-0maemo2 to extras-devel yesterday evening, which built fine. However, looking at: http://maemo.org/packages/package_instance/view/fremantle_extras-devel_fr ee_armel/glom/1.12.2-0maemo2/ I see that an old version 1.12.2-0maemo1 is in the File field. There is also a dependency warning, that is not present in the 1.12.2-0maemo2 version (which I uploaded to fix exactly this problem). I can install 1.12.2-0maemo2 on an N900, so the dependency problem does not seem to be an issue, but maybe the package description is somehow stale? You spotted a bug in the package importer. I have now fixed that bug, so it should look a lot better for you now? Thanks for reporting! -- David King | http://amigadave.blogspot.com/ | dav...@openismus.com -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
QA queue determine required thumbs down for removal
Hi, To not keep obvious broken applications lingering in the QA testing queue, we need to determine what how many thumbs down are required before automatic removal from the queue is done. How about setting the limit at: 5 thumbs down at = 10 day quarantine point. and 10 thumbs down for immediate removal. Another thing to think about is if we only want to remove the package from the QA queue or also remove it from the extras-testing repository. Thoughts? -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA queue determine required thumbs down for removal
On Thu, October 22, 2009 15:31, gary liquid wrote: There is no interface to pull apps manually. if testing identifies a blocker, the maintainer has no way but to leave it there wasting the other testers time. This reminds me. If a maintainer votes his own app down, it should be removed instantly. This way a maintainer can easily remove his own app and not waste testers' time. -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Promotion unlocked messages
Hi, While implementing a new notification feature for the community QA queue, a number of mails have been sent out to owners of packages in extras-testing. Due to some incorrect checks more people have received the mail than was intended. I'm very sorry for sending you these mails. This should not happen again. -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Removing a package from extras-devel: glom-sqlite
On Tue, October 20, 2009 11:14, Murray Cumming wrote: How can I remove a package from extras-devel? I'd like to remove the glom-sqlite package because we now have sqlite support (and PostgreSQL) support in our main glom package in extras-devel. I have removed the packages from the repository. It can take some time for this to be visible. -- murr...@murrayc.com www.murrayc.com www.openismus.com -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Uploading to Fremantle extras via Extras Assistant
Hi, The most recent changes files you uploaded are all 0 bytes in size. That doesn't seem to happen for other people. I just tested an upload and it worked fine for me. Are you really sure the problem isn't at your end? - Niels On Tue, October 20, 2009 11:27, Aniello Del Sorbo wrote: Hi, Still no luck with this.. and this is blocking me. Neils? Any thoughts? -- anidel Sent from London, Eng, United Kingdom 2009/10/9 Aniello Del Sorbo ani...@gmail.com: I am trying to upload a new version of Xournal in order to promote it to Testing, but the extras assistant keeps saying my changes is incorrect. I haven't changed anything and was working fine for fremantle-beta, do I have to do something? -- -- anidel Sent from London, Eng, United Kingdom ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
