Re: Diablo extras repository proposal
On Wed, 2008-06-25 at 23:36 +0200, ext Tim Teulings wrote: I don't think it is fair to blame the developers without looking for reasons. I'm sure there are reasons for the current situation (some already responded to your mail). The situation needs discussion but not simple blaming. Situation is frustrating but worse could happen. The situation needs actions, not discussions. We already had a lot of discussions. May be it's now better to act, not to speak. After we accomplished Misha's plan[1] several months ago[2] we had no feedback and almost nobody used autobuilder and promoter. I can speak for others but I personally tried to find a solution between improving existing and developing new software, switching the employer (plus working overtime), moving to a new home, buying a new car and other stuff. I'm not payed for developing open source software so other things have priority. I'm also not payed for this. May be I should stop sending emails from my Nokia acoount. People seems to be confused. With this attitude I don't think it's feasible to go further and develop additional features which will not be used again. Instead we should probably concentrate on encouraging maintainers to actually use the tools and to give feedback. From this point of view Niels proposal is more than enough for now. So back to the possible reasons for the situation (I cannot speak for others, so other developer please add or correct!): * Nokia did not give a long term release date but expects developer to just be prepared. I can understand why Nokia does not give long term release date (the reasons are obvious) but as a result it must ramp up such stuff far ealier (should have made advertisment and plans for strategie for diablo much earlier) to get a result in time. Perhaps annoucement was made but at least me was still suprized by some aspects. Assume that every (re)action of an open-source developer may take 2-4 weeks, even if a task of 2 hours is to be completed. OK, let's wait for next 4 weeks then :) * Nokia must realize that the current autobuilder and extra repository infrastructure possibly still give no real gain for me and possibly others. As long as I can add *.install files to my own repository in the downloads section having an own repository is simpler than using the autobuilder. Community must realize possible benefits of having central repository. It seems that 'Repository mess' discussion was useless. I'm not surprised by this fact at all. The current infrastructure: + Is slow (autobuilder needs *much* longer than my local computer) and currently even seems to be overloaded. + There seem to be smaller bugs, making some builds fail for no reason + Needs more initial setup to be usable + Cannot handle dependencies, neither does it seem to compile packages in queueing order (so having one library and multiple depending applications I cannot upload and forget). + I cannot push packages for multiple OS versions on the same time via the web interface (will take a look at dput) + Does not build packages for older distributions, so I still have to compile packages for older OS version myself, having twice the effort. + Does not support other niftly stuff like lint etc... + Integration with downloads could be much better + extras is more a mess than an really atractive place to be for my packages ;-) Quality was requested but control and enforcement seems to be weak. + Suggestions for improvements will not be rejected but the reaction suggests that things will take a long time (and suggests that I can slow done pace, too, which is definitely the wrong signal ;-)). What I can see here is pure blame without any wish to improve situation. But it's better then zero feedback we had before. So my blame works :)! I don't agree with some of your statements. Others make sense and I'll try to address them. Especially dependency handling. It's already in my todo list. The current situation is the direct result of this and for me personally no suprise (in fact in the last big discussion I participated I even hinted that this will happen). However I don't think that keeping things the way they are or at least slowing down the development of this the totally wrong way (under given goals). This is the totally wrong signal and will kill extras repository. Instead a way to accelerate the development and invest in improvement must be found. It looks like Nokia is waiting for the community to jump in, but possibly critical mass is not yet reached for this. Or why we discuss 2010 agenda? How? If the community cannot help or does not want to help (because hacking software is cooler than improving infrastructure?) Nokia possibly must either help, extpectations must be lowered, or another strategy must be found. For me it looks like we are still no team. Community is helping. Autobuilder, promotion interface and current rebuild
Re: Modest/TinyMail problems (continue from the blog comments)
Dave Cridland escribiu: My biggest problem with Modest has always been that the UI requirements seem to have driven the development, to the extent that although Tinymail is pretty good, both its development and its usage has been severely compromised by trying to build a desktop mail program on an internet tablet. The result is a program that looks the part, and has the right buttons to press, but by insisting on those features as priority over all else, it's hog-tied itself into poor use of the network, so it's totally unusable on my mailboxes, whereas Polymer just trundles through them. Well Dave, I think the comparison is not fair. I think you're trying to compare the speed of a Formula 1 and a Mercedes-Benz. Obviously de Formula 1 (Polymer) is faster than a Mercedes-Benz (Modest) because it has been specially designed for it, but in a Mercedes-Benz you have a lot more facilities and will probably win the comparison in another subjects like comfort. Take into account that Modest has a lot of code to manage UI things that slow down the device like dimming buttons, sorting and filtering of tree models, etc... I haven't analyzed seriously Modest performance recently, but I bet most of the slowness is caused by such kind of things. Also bear in mind that tinymail and Camel use a lot of threads and the N800/N810 is not a device that could easily cope with that. Br ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [Mono] question about mono install and selinux
Hi Andrea 2008/6/24 Amdrea Turbatto [EMAIL PROTECTED]: Hi Torello Thanks for the hint, i've followed step by step, once i launch make maemo/devkit the linker (i suppose) says to me: Making all in . Making all in m4macros Making all in glib Making all in libcharset Making all in gobject /home/andrea/garmono/maemo/devkit/glib/work/main.d/glib-2.12.12/gobject/.libs/lt-glib-genmarshal: error while loading shared libraries: libselinux.so.1: cannot open shared object file: No such file or directory make[8]: *** [stamp-gmarshal.h] Error 127 make[7]: *** [all-recursive] Error 1 make[6]: *** [all] Error 2 make[5]: *** [build-work/main.d/glib-2.12.12/Makefile] Error 2 make[4]: *** [../../../maemo/devkit/glib/cookies/main.d/install] Error 2 make[3]: *** [imgdep-main] Error 2 make[2]: *** [../../../maemo/devkit/mono/cookies/main.d/install] Error 2 make[1]: *** [imgdep-main] Error 2 make: *** [maemo/devkit] Error 2 Could you help me? I use ubuntu 7.10 with Chinook SDK to compile mono. I look into my installation and libselinux.so.1 is present on the normal distro but not in the scratchbox. I check my lt-glib-genmarshal library with ldd l-glib-genmarshal and not depends from libselinux. This is the output: /scratchbox/tools/lib/libsb.so.0 = /scratchbox/tools/lib/libsb.so.0 (0xb7f49000) libglib-2.0.so.0 = /home/maemosdk/mono/garmono/maemo/devkit/glib/work/main.d/glib-2.12.12/glib/.libs/libglib-2.0.so.0 (0xb7eb7000) libc.so.6 = /scratchbox/host_shared/lib/libc.so.6 (0xb7d83000) libdl.so.2 = /scratchbox/host_shared/lib/libdl.so.2 (0xb7d8) libsb_env.so.0 = /scratchbox/tools/lib/libsb_env.so.0 (0xb7d7e000) /scratchbox/host_shared/lib/ld.so = /scratchbox/host_shared/lib/ld.so (0xb7f53000) [ For further help I need information about your distro and SDK that you use. Regards, Torello ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Diablo extras repository proposal
Hi, ext Ed Bartosh wrote: On Wed, 2008-06-25 at 23:36 +0200, ext Tim Teulings wrote: I don't think it is fair to blame the developers without looking for reasons. I'm sure there are reasons for the current situation (some already responded to your mail). The situation needs discussion but not simple blaming. Situation is frustrating but worse could happen. The situation needs actions, not discussions. We already had a lot of discussions. May be it's now better to act, not to speak. If this is about expecting developers immediately (with one month) starting to upload their packages, I think this is unrealistic. If I use my hobby project[1] as an example: - once I have source packages I could try autobuilder - currently I've been doing binary packages manually[1] as I have few dozen of them (most trivial, but main one complex) and that's easier. Making a real Debian source packages for them is something I see as eventually necessary, but secondary to completing features I'm interested about (some maemo specific, some general) - I've been working on those features for the last half a year and I expect them to complete after summer, then I can start looking into source packaging I.e. I see autobuilder as something very much needed and useful but things are done in certain order, release happens at the end of feature development and packaging is something you mainly look into when you're doing a release. This time it didn't co-incide with autobuilder. I doubt many projects have synched their releases with Diablo release or autobuilder. Even Ubuntu has hard time convincing others to sync releases with them, and they have fixed schedule known several years in advance... :-) Secondly, I think most developers view packaging as necessary evil and although they would appreciate and like to use services like autobuilder, they'd prefer somebody else to test debug it so that they know it works fine and has the needed features when they need/want to provide the packages. Most projects get new usersdevelopers only when they've gotten to useful good enough state and there's some proof of that (e.g. from current users). - Eero [1] see: http://hatari.sf.net/ http://koti.mbnet.fi/tammat/hatari/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
I am now on Refriendz!
Hi! I would like to invite you to visit my Refriendz page and see my latest photos. In order to visit my space, you must go to: http://www.refriendz.com/?do=Login.Inviterid=Pradeepec023[EMAIL PROTECTED] (If this link does not work, please copy and paste it into your browser or go to www.refriendz.com and enter 'Pradeepec023' as Invitation ID to Login to the web site.) P.S. Refriendz is Invitation-Only, so do not miss your chance to visit my page! Cheers! Pradeep ~~~ Unsubscribe: to opt out of ALL future emails from Refriendz, visit: http://www.refriendz.com/?do=Login.RemoveEntry[EMAIL PROTECTED] Please do not reply directly to this email. This mailbox is not monitored and you will not receive a response. Refriendz Limited, PO BOX 1184, Luton, Bedfordshire, LU1 9AT, UK. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Diablo extras repository proposal
On Thu, 2008-06-26 at 11:58 +0300, Eero Tamminen wrote: Hi, ext Ed Bartosh wrote: On Wed, 2008-06-25 at 23:36 +0200, ext Tim Teulings wrote: I don't think it is fair to blame the developers without looking for reasons. I'm sure there are reasons for the current situation (some already responded to your mail). The situation needs discussion but not simple blaming. Situation is frustrating but worse could happen. The situation needs actions, not discussions. We already had a lot of discussions. May be it's now better to act, not to speak. If this is about expecting developers immediately (with one month) starting to upload their packages, I think this is unrealistic. Will see how unrealistic it will be. You can watch the process here: https://garage.maemo.org/builder/diablo/ and here: https://garage.maemo.org/extras-assistant/maemo_extras_diablo_rebuild.php Regards, --- Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
maemo Bug Jar #10
A Quick Look at maemo Bugzilla 2008.06.19 through 2008.06.25 My apologies for the delay in getting this edition to the list. I didn't discover until this morning that the version I sent last night was too obese to fit through the door. In order to drop the Bug Jar's weight quickly, I've eliminated the links to individual bugs. I apologize for any inconvenience this causes. As of 2008.06.25 maemo Bugzilla contains 3256 (+44 this week) items, including 1140 open issues (+15 this week): * 753 open bugs (no change this week) * 10 critical/blocker (no change this week) * 10 easyfix (+3 this week) * 86 moreinfo (+30 this week) * 20 crash (+1 this week) * 16 patch (-2 this week) * 294 unconfirmed (+11 this week) * 387 open enhancements (+15 this week) * 11 easyfix (+4 this week) * 4 moreinfo (no change this week) * 4 patch (no change this week) * 102 unconfirmed (+4 this week) ==--- New Items ---== 32 new bugs were opened: ( https://bugs.maemo.org/buglist.cgi?bug_id=3265,3267,3268,3270,3272,3273,3274,3275,3280,3281,3282,3284,3287,3288,3289,3290,3291,3292,3293,3294,3295,3297,3298,3299,3300,3302,3303,3304,3305,3306,3307,3308 ) * [3265] base-files 3.1.osso2+3.1.10.osso16 postinstall script use... * [3267] Multiple email accounts causes time outs * [3268] Contact image file selector close grabs pointer * [3270] metalayer locks SD cards from PC USB access * [3272] connection error causes e-mail program to eat up battery * [3273] talkshoe calls dropped after first ring * [3274] User contributions not visible * [3275] Browser address bar still on screen when typing into text... * [3280] Wiki pages sometimes fail to load with lost network conn... * [3281] Sporadic lockup/reboot when USB host software releases pe... * [3282] Maemo Diablo Reference Manual, Application Development: G... * [3284] Use of RTCOMM beta for IRC leads to reboots * [3287] Maximized google reader draws weird lines on the screen * [3288] Wizard-mounter no longer installs * [3289] E-mail messages and Settings boxes linked in Backup/Restore * [3290] comma appended to filenames from tablets-dev * [3291] MicroB's about: page shows old version and copyright info... * [3292] Can't install or uninstall Rhapsody on Diablo (osso-ic mi... * [3293] Bluetooth headset (Jabra bt202) connectivity needs re-pai... * [3294] Modest does not show more than one remote account at once * [3295] Modest does not memorize text zoom level when exiting mes... * [3297] International characters in SSID * [3298] Inconsistent behaviour of ctrl-L, can't type in location ... * [3299] Cannot remove menu entries for partially installed / appl... * [3300] Display light ignores what's set through control panel * [3302] email adres with non ascii character not displayed proper... * [3303] causes camera trigger not to work * [3304] Modest doesn't correctly handle incoming events * [3305] INSTALL.txt suggests nonexistent 'sudo' instead of 'faker... * [3306] DUMMY connections not visible in Select connection dialog * [3307] Incorrect catalog name for Extras in Application manager * [3308] ioctl SIOCGIFHWADDR returns wrong MAC address for TAP vir... Of these, 1 was a critical/blocker: ( https://bugs.maemo.org/buglist.cgi?bug_id=3281 ) * [3281] Sporadic lockup/reboot when USB host software releases pe... 12 new enhancements were opened: ( https://bugs.maemo.org/buglist.cgi?bug_id=3266,3269,3271,3276,3277,3278,3279,3283,3285,3286,3296,3301 ) * [3266] Integrate the mediawiki with the rest of the maemo.org site * [3269] Street addresses missing from contacts. * [3271] Tabbed conversations * [3276] Allow experienced users to set audio and video encoding s... * [3277] Allow changing of the quality setting in the main view * [3278] Change the way the estimated time is displayed * [3279] Streamlining user access to the Extras repository * [3283] Install the citation extension for the wiki * [3285] Copy and Paste menu option would be useful * [3286] allow update button on toolbar to be pressed from main view * [3296] Modest should allow user to configure fonts * [3301] Add option to ignore the N810 ambient light sensor ==--- Confirmed Items ---== 6 bugs were confirmed: ( https://bugs.maemo.org/buglist.cgi?bug_id=3073,3229,3294,3295,3298,3306 ) * [3073] Can't enter non-alphabetic Control Sequences such as Ctrl... * [3229] 2.2 tutorial links are incorrect * [3294] Modest does not show more than one remote account at once * [3295] Modest does not memorize text zoom level when exiting mes... * [3298] Inconsistent behaviour of ctrl-L, can't type in location ... * [3306] DUMMY connections not visible in Select connection dialog 4 enhancements were confirmed: ( https://bugs.maemo.org/buglist.cgi?bug_id=2303,3269,3271,3285 ) * [2303] Karma should count ITT 'Thanks! * [3269] Street addresses missing from contacts. * [3271] Tabbed conversations * [3285] Copy and Paste menu option would be useful ==--- Keyworded Items ---== 1
building from source requirement, scummvm Re: Diablo extras repository proposal
Graham Cobb wrote: A week is a long time for someone funded to work on this full time. It is nothing at all for people working on this in their spare time! Exactly :-) In my case, a big problem is dependencies which were previously uploaded into Extras without sources. In my case of scummvm I have following problems 1. dependencies scummvm depends also on mad, tremor, flac and mpeg2 which I compiled and 'make install'-ed from tar.gz into my scratchbox environment. Most possibly they are in debian but I need to hunt them. I avoided the problem so far by linking them statically (they are quite small and I prefer to not to have too many dependencies anyway). 2. specific library build options AFAIK flac must be built without ogg containter (not default) because of tremor, tremor provides ogg too, but is incompatible with real ogg in reality this means for me that -lFLAC needs also -logg by default, -logg and -livorbisdec together produce duplicate symbols, scummvm needs both flac and tremor(a.k.a. ivorbisdec) Maybe it is solvable without building flac in special way (no ogg) but so far I had no time to solve it. 3. internal compiler error scummvm is buildable with -Os (my preferred option) but one source in kyrandia engine fails with ICE both with -O2 and -Os Only -O3 or no optimization works. Currently I don't know how to tweak makefile for this specific source. 4. how to make buildable source :-) I am sorry for being so ignorant but how exactly do I produce debian source that can be uploaded? I am still packaging newbie. Any direct links to howtos appreciated. Overall I like the idea of autobuilding from source very much but sadly it will take me a lot of time to make scummvm buildable. Also so far any work on the actual code (scummvm or other) had higer priority and my time is limited. You guys are forcing me to either change priorities or sabotage you worthy goal, tough choice :-) If anyone could lend a hand, you can get 0.11.1 release tarball from scummvm.org, search the README for Maemo and try. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: building from source requirement, scummvm Re: Diablo extras repository proposal
On Thu, Jun 26, 2008 at 3:49 PM, Frantisek Dufka [EMAIL PROTECTED] wrote: scummvm depends also on mad, tremor, flac and mpeg2 which I compiled and 'make install'-ed from tar.gz into my scratchbox environment. Most possibly they are in debian but I need to hunt them. I avoided the problem so far by linking them statically (they are quite small and I prefer to not to have too many dependencies anyway). [snip] I am sorry for being so ignorant but how exactly do I produce debian source that can be uploaded? I am still packaging newbie. Any direct links to howtos appreciated. I'm hoping to switch the direction of mud-builder[1] a little bit, since the auto-building aspects are no longer so important. Instead, it'll help with the creation of source packages for Maemo and uploading them to the autobuilder. It'll do this - as it does currently - from upstream tarballs, Debian packages etc, with the possibility of Maemo-specific patches. I started a thread about it on mud-builder-users, FWIW: https://garage.maemo.org/pipermail/mud-builder-users/2008-June/000255.html Input from existing mud users, and developers looking to move to source-packages welcome. Cheers, Andrew [1] http://mud-builder.garage.maemo.org/ -- Andrew Flegg -- mailto:[EMAIL PROTECTED] | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Diablo extras repository proposal
On Thu, Jun 26, 2008 at 03:51:10PM +0300, Ed Bartosh wrote: Will see how unrealistic it will be. You can watch the process here: https://garage.maemo.org/builder/diablo/ and here: https://garage.maemo.org/extras-assistant/maemo_extras_diablo_rebuild.php BTW, the page refers to chinook promoter, not diablo one. -- Misha signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder for maemo extras repository
Hi, Am Freitag, den 06.06.2008, 11:54 +0200 schrieb Niels Breet: Just to let you know that I sometimes get this type of error : [2008-06-06 10:25:01] Processing package gnokii-gconf 0.6.2. Uploader: fredoll, builder: builder1 [2008-06-06 10:25:01] REJECTED: 'File size for /var/www/extras-devel/incoming-builder/chinook/gnokii-gconf_0.6.2.tar.gz does not match that specified in .dsc' It goes away if I retry the dput without changing anything ... This is because we process the queue every certain amount of time and we check if we have seen the file before in the last run. A file that has been there for a certain amount of time gets processed. Ed: Do we need to make the upload_timeout a little longer? Today i tried out the autobuilder the first time for uploading the Build-Dependencies of Gnumeric to the diablo-extras-devel-repository and i hit the same problem a few times, i believe that the code which picks up the files from the incoming queue needs to be changes somehow because as far as i can see from the buildme python code, it checks upload_timeout by investigating the mtime of the .dsc file. Unfortunately the .dsc file is one of the first files uploaded by dput. (I believe the order is: .dsc, .diff.gz (if available), .tar.gz, .changes). And here comes the problem: For bigger .tar.gz files and people with a slow upload bandwidth (16 KByte/sec in my case), it is just not possible to upload larger packages successfully, they will always be picked up and rejected by buildme before they are uploaded completely. (If i understood your comments correctly, it will take 1x or 2x upload_timeout until the upload is considered, which would allow me to upload 2880 (180*16) to 5760 (2*180*16) KByte at best, this also matches my experiences from today, where i needed 3 tries until i was able to successfully upload goffice (about 3200 Kbyte). Unfortunately this is absolutely not enough for the biggest package i am trying to upload (gnumeric, the tarball is over 20 MByte big). So it would be very nice if you could change the code just check the mtime of the .changes file, because this file seems to be the last one uploaded by dput. Please also see: https://garage.maemo.org/pipermail/extras-cauldron-builds/2008q2/000553.html https://garage.maemo.org/pipermail/extras-cauldron-builds/2008q2/000554.html https://garage.maemo.org/pipermail/extras-cauldron-builds/2008q2/000564.html in all cases, the files were rejected before the upload by dput was completed. Regards, Thomas -- Thomas Schmidt, Debian VDR Team http://pkg-vdr-dvb.alioth.debian.org/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Diablo extras repository proposal
On Thu, 2008-06-26 at 09:29 +0300, ext Ed Bartosh wrote: On Wed, 2008-06-25 at 15:42 +0100, ext Graham Cobb wrote: On Wednesday 25 June 2008 10:47:47 Quim Gil wrote: - What are the dependency packages you need to put in place or fix? Don't answer here, go to the wiki and start the list. Rest of developers in the same situation than Graham, add your problematic packages to the list. List started: http://wiki.maemo.org/Diablo:_Missing_Packages. The most serious, for me, is libsoup and all its dependencies. That is the real problem for me. OK. I'll try to build it today evening. Done: https://garage.maemo.org/builder/chinook/libgcrypt11_1.2.3-2.maemo1/ https://garage.maemo.org/builder/chinook/gnutls13_2.0.4-3maemo3/ https://garage.maemo.org/builder/chinook/libsoup_2.2.105-4/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: building from source requirement, scummvm Re: Diablo extras repository proposal
On Thu, 2008-06-26 at 16:49 +0200, ext Frantisek Dufka wrote: In my case of scummvm I have following problems 1. dependencies scummvm depends also on mad, tremor, flac and mpeg2 which I compiled and 'make install'-ed from tar.gz into my scratchbox environment. Most possibly they are in debian but I need to hunt them. I avoided the problem so far by linking them statically (they are quite small and I prefer to not to have too many dependencies anyway). I see at least 2 packages from your list in repository: http://repository.maemo.org/extras-devel/pool/chinook/free/libm/libmad/ http://repository.maemo.org/extras-devel/pool/chinook/free/f/flac/ 2. specific library build options AFAIK flac must be built without ogg containter (not default) because of tremor, tremor provides ogg too, but is incompatible with real ogg in reality this means for me that -lFLAC needs also -logg by default, -logg and -livorbisdec together produce duplicate symbols, scummvm needs both flac and tremor(a.k.a. ivorbisdec) You should probably agree about this with mplayer maintainer. If I remember correctly flac and libmad are mplayer dependencies. Most probably I built them sometimes ago for mplayer. I'm helping Sergey with packaging. Maybe it is solvable without building flac in special way (no ogg) but so far I had no time to solve it. 3. internal compiler error scummvm is buildable with -Os (my preferred option) but one source in kyrandia engine fails with ICE both with -O2 and -Os Only -O3 or no optimization works. Currently I don't know how to tweak makefile for this specific source. I'd suggest to take packages from Debian: http://packages.debian.org/lenny/scummvm and tweak them a bit. 4. how to make buildable source :-) I am sorry for being so ignorant but how exactly do I produce debian source that can be uploaded? I am still packaging newbie. Any direct links to howtos appreciated. I'd go this way: wget http://ftp.de.debian.org/debian/pool/main/s/scummvm/scummvm_0.11.1-1.dsc http://ftp.de.debian.org/debian/pool/main/s/scummvm/scummvm_0.11.1.orig.tar.gz http://ftp.de.debian.org/debian/pool/main/s/scummvm/scummvm_0.11.1-1.diff.gz dpkg-source -x scummvm_0.11.1-1.dsc cd scummvm-0.11.1/ After making changes you should run dpkg-buildpackage -S You can find a lot of info about Debian packaging here: http://www.us.debian.org/devel/ Overall I like the idea of autobuilding from source very much but sadly it will take me a lot of time to make scummvm buildable. Also so far any work on the actual code (scummvm or other) had higer priority and my time is limited. You guys are forcing me to either change priorities or sabotage you worthy goal, tough choice :-) If anyone could lend a hand, you can get 0.11.1 release tarball from scummvm.org, search the README for Maemo and try. I can help you, but you should try yourself first and ask questions :) Regards, --- Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder for maemo extras repository
On Thu, 2008-06-26 at 22:30 +0200, ext Thomas Schmidt wrote: Today i tried out the autobuilder the first time for uploading the Build-Dependencies of Gnumeric to the diablo-extras-devel-repository and i hit the same problem a few times, i believe that the code which picks up the files from the incoming queue needs to be changes somehow because as far as i can see from the buildme python code, it checks upload_timeout by investigating the mtime of the .dsc file. Unfortunately the .dsc file is one of the first files uploaded by dput. (I believe the order is: .dsc, .diff.gz (if available), .tar.gz, .changes). And here comes the problem: For bigger .tar.gz files and people with a slow upload bandwidth (16 KByte/sec in my case), it is just not possible to upload larger packages successfully, they will always be picked up and rejected by buildme before they are uploaded completely. (If i understood your comments correctly, it will take 1x or 2x upload_timeout until the upload is considered, which would allow me to upload 2880 (180*16) to 5760 (2*180*16) KByte at best, this also matches my experiences from today, where i needed 3 tries until i was able to successfully upload goffice (about 3200 Kbyte). Unfortunately this is absolutely not enough for the biggest package i am trying to upload (gnumeric, the tarball is over 20 MByte big). I'd suggest you to use Maemo Extras Assistant instead of dput: https://garage.maemo.org/extras-assistant/index.php It puts .dsc after all other sources. So it would be very nice if you could change the code just check the mtime of the .changes file, because this file seems to be the last one uploaded by dput. I can't. Autobuilder doesn't use .changes at all It needs only sources, so .dsc is enough for it. If it's not convenient for you to use web assistant I can just increase timeout. Another way is to change dput. Which dput version do you use, BTW? And last solution is to use scp instead of dput. If you're interested I can show my upload script. It's simple and ugly, but it works for me for a long time. Regards, --- Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder for maemo extras repository
Am Donnerstag, den 26.06.2008, 23:58 +0300 schrieb Ed Bartosh: I'd suggest you to use Maemo Extras Assistant instead of dput: https://garage.maemo.org/extras-assistant/index.php It puts .dsc after all other sources. Yes, this would work, but i would very much prefer dput over any web-interface. :) So it would be very nice if you could change the code just check the mtime of the .changes file, because this file seems to be the last one uploaded by dput. I can't. Autobuilder doesn't use .changes at all It needs only sources, so .dsc is enough for it. Ok, but then it should be at least possible to check the mtime of the tarball and/or .diff.gz - at least one of them should be listed in every .dsc file. Btw: Which one of the scripts checks if the gpg-signatures of the uploads are valid, shouldn't this script check both, the signature in the .dsc and the signature in the .changes files? If it's not convenient for you to use web assistant I can just increase timeout. Yes, of course this would work too, but i guess some other people would not be very happy about such a change (*looking at Graham Cobb*) especially as it would require to be at least 1300 seconds in my case. ;-) Another way is to change dput. Which dput version do you use, BTW? I am using version 0.9.2.32 from current Debian Lenny, but i would consider changing dput to be able to upload to the autobuilder a very ugly hack. As far as i can see, the autobuilder should be changed to work with the unmodified dput. And last solution is to use scp instead of dput. If you're interested I can show my upload script. It's simple and ugly, but it works for me for a long time. Yes, this could work too, but as i said allready, i thing the autobuilder, should be fixed instead. (Another workaround i could use would be to upload the package to my webserver and use dput on the server to upload it to garage, but this would make things just overly complicated for everyday usage.) :) Btw: it seems that i am not the only one who is experiencing this problem, Luciano Wolf seems to be hit by it as well, his upload of python2.5 2.5.2-1osso3 was rejected 4 times today: https://garage.maemo.org/pipermail/extras-cauldron-builds/2008q2/000574.html https://garage.maemo.org/pipermail/extras-cauldron-builds/2008q2/000575.html https://garage.maemo.org/pipermail/extras-cauldron-builds/2008q2/000576.html https://garage.maemo.org/pipermail/extras-cauldron-builds/2008q2/000577.html Regards, Thomas -- Thomas Schmidt, Debian VDR Team http://pkg-vdr-dvb.alioth.debian.org/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder for maemo extras repository
On Thursday 26 June 2008 23:02:46 Thomas Schmidt wrote: Yes, of course this would work too, but i guess some other people would not be very happy about such a change (*looking at Graham Cobb*) especially as it would require to be at least 1300 seconds in my case. ;-) I think Ed (or someone) told me that I don't have to worry about that timeout (or was it another timer -- I will admit to being confused!). Of course, once the autobuilder has dependency support I won't care at all! The timers are only used in my hack script which handles dependencies by waiting long times (like an hour or more) between various uploads. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Diablo extras repository proposal
Ed Bartosh wrote: My opinion that tt's about 2 men days work to fix all build failures. Niels can tell how many people uploaded packages to extras. And you can see how many of them actually care to fix build failures. If each of them would spend 1(one) hour during last week we would already have almost all packages fixed. I think you should consider that you and Niels are more knowledgeable, more focused, and therefore more productive than I am. I'm a guy with a life, a family, and a house and yard that need more attention than I can give them during the tragically short summer. My recreational programming time is limited -- a solid hour of work is a pretty good evening, and I don't get every evening. And Maemo is not my only interest. When I come back to a project, it takes me a while just to remember where I left off. I was delighted when the Autobuilder was announced, and looked forward to using it. It just happened that I didn't have any work in progress on Battle for Westnoth that I could submit. Also, I planned to get the next release working in a scratchbox before sending it to the autobuilder, because I didn't want to struggle with the code and a new build system at the same time. The very day I sat down to work on Wesnoth, the Extras Assistant was announced. Again, I was delighted, and went to the rebuild log page to see how my packages were building. They weren't! fribidi_0.10.7-4osso1 was missing. That was my fault; I hadn't realized that, because the package version wasn't 0 or 1, the source tarball wasn't included in my upload to Extras. So I fixed that, and finding and fixing the mistake (and adding a tip to the Extras Repository web page) only used up two evenings... But what about libfont-ttf-perl_0.43-1? The build is failing because an include statement in debian/rules can't find a file that the quilt package should install. Is something wrong with the Build-depends in my control file? libfont-ttf-perl builds in my scratchbox, and it builds if I upload it directly to the autobuilder. Is something wrong with the Extras Assistant? After a few more evenings of investigation, I requested a rebuild (which hasn't happened yet) in the faint hope that something had temporarily gone wrong with the Extras Assistant. I also asked for help in this mailing list on Monday, and haven't seen a reply yet. And then I spent a whole evening on Wesnoth! Now when I look at the Rebuild Log page, I see that I should be able to promote the package that the Autobuilder built. When I follow the link, I am told that I am not authorized to use the system. Next, I will look through the archives and the web sites to find out how to get authorization. That, and composing this letter, will likely use up the evening. So you see, other than an evening of Wesnoth work and three hours of Half-Life mayhem, the Extras Assistant and the autobuilder have consumed all of my recreational computer time since the Assistant was announced. Judging from the tone of some recent postings from nokia.com addresses, you are disappointed and maybe even a bit hurt that the autobuilder hasn't been flooded with users. I sympathize -- I'm not here for the money either! -- and I do appreciate the work that's been done. But you have to remember that I'm an *amateur*, in both senses of the word, and so are most of the people on this mailing list. We simply *cannot* respond quickly to your needs. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Diablo extras repository proposal
I would be interested in the answer to this as well. thanks, Frank On Thu, Jun 26, 2008 at 8:50 PM, Glen Ditchfield [EMAIL PROTECTED] wrote: Now when I look at the Rebuild Log page, I see that I should be able to promote the package that the Autobuilder built. When I follow the link, I am told that I am not authorized to use the system. Next, I will look through the archives and the web sites to find out how to get authorization. That, and composing this letter, will likely use up the evening. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
