Re: Downloads screenshot
On Saturday 06 March 2010 13:30:01 Thomas Troy wrote: Hi, I'm wondering how do you add a screenshot to the maemo.org/downloads page of your application? I've an application that's been promoted to extras and but it doesn't show a screenshot and I don't know how to add one. Go to your package page on maemo.org. http://maemo.org/downloads/product/Maemo5/foopackage/ In the top center there is a floating bar (you must be signed in). Click on Page--Edit. There you will find a place to upload a screenshot. It takes awhile to show up. -Jeff Moe http://wiki.maemo.org/User:Jebba ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fw: Proposal: MeeGo User Experience Framework working group
On Thursday 04 March 2010 07:19:05 Randall Arnold wrote: - Original message - Randall, I am thinking along the line of something like a sort of expert system, a web ui, that offers bug/problem domains to the user to choose from. Then according to the problem domains a set of question are presented for the user to answer with minimum free text. And so on and forth. We could even have something like this on the device, as a complementary test-case or use-case to validate against a fix when it is out. What do you think? Sivan That is right on target with what I propose, especially the on-device aspect. Now you have me thinking my presentation comes up short... ; ) I think this does (some of) what you want: https://fedorahosted.org/abrt/wiki -Jeff Moe http://wiki.maemo.org/User:Jebba ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N900 kernel module recompile
On Thursday 18 February 2010 10:18:48 Nils Faerber wrote: Hi all! After all that RPM vs DEB debate I thought I could bring up something more productive ;) I would like to hack on some drivers on the N900, so I need to be able to recompile kernel modules. Ideally I would like only to replace modules, not the whole kernel+modules package. So what I did was I installed the Maemo5 SDK first in order to get the proper toolchain. Then I took a vanilla 2.6.28 Linux kernel archive and applied the kernel patch from http://repository.maemo.org/pool/fremantle/free/k/kernel/ kernel_2.6.28-20094803.3+0m5.diff.gz Then I setup my comile environment: export PATH=/scratchbox/compilers/cs2007q3-glibc2.5-arm7/bin/:$PATH export CROSS_COMPILE=arm-none-linux-gnueabi- export ARCH=arm Then kernel config: cp arch/arm/configs/rx51_defconfig ./.config make oldconfig A make modules does cleanly compile the modules. Fine so far (except for that te modules are *huge* and a arm-none-linux-gnueabi-strip -R .not -R .comment --strip-unneeded seems reasonable). But when I try to load one of the new modules I get: -1 Invalid module format And dmesg shows: no symbol version for struct_module This usually means that CONFIG_MODVERSIONS is not set but I double checked that and I do have CONFIG_MODVERSIONS=y in .config. I also changed the extra version name in the kernel toplevel Makefile, which should be correct (to my knowledge): #NAME = Erotic Pickled Herring NAME = maemo There is an older page about recompiling kernel for Diablo in the Wiki: http://wiki.maemo.org/Compiling_the_kenrel Would that still apply (of course replacing Diablo with Freemantle and N810 with N900 or RX51 respectively)? Again, I just want to hack on one single module. So I would like to avoid having to flash a completely home-grown kernel+modules set (frankly that scares me a little ;) Any hint would be really appreciated ;) Some N900 kernel hackers around here? Ideally I would like to make my changes available again so that others can also play with them by just replacing a single .ko-module... This isn't exactly what you want, but should provide some hints: http://wiki.maemo.org/User:Jebba/Kernel This dir has my live scratchbox with some scriptlets which may help you see the procedure: http://www.freemoe.org/users/jebba/scratchbox/kernel/ Have fun, -Jeff Moe ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo code in Linux kernel?
On Friday 05 February 2010 02:46:21 Yves-Alexis Perez wrote: On 04/02/2010 12:32, Jeff Moe wrote: At least for the N900 the answer is no. The touchscreen driver disappeared at 2.6.29: drivers/input/touchscreen/tsc2005.c I didn't found tsc2005.c in 2.6.28: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=drivers/input/touchscreen;h=cc73814e591a07b26f4214a582aeea654a519baf;hb=4a6908a3a050aacc9c3a2f36b276b46c0629ad91 Was tsc2005.c really accepted upstream at one point? It was in linux-omap tree up to 2.6.29. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo code in Linux kernel?
On Thursday 04 February 2010 04:23:59 Marcin Juszkiewicz wrote: Dnia czwartek, 4 lutego 2010 o 11:53:22 Christopher Intemann napisał(a): I came across this blog-entry [1] which is describing why the Android kernel extensions were removed from the current kernel version. I'm just curious: Where does Nokia/ Maemo stand? Are there Maemo sources in the official Linux kernel tree at all? Good question. Some of nokia/Maemo code landed in linux-omap tree, some got into vanilla. But the question can be: is any of official kernel trees capable to provide fully working 2.6.33-rc kernel for nokia 770/n8x0/n900 tablet? At least for the N900 the answer is no. The touchscreen driver disappeared at 2.6.29: drivers/input/touchscreen/tsc2005.c A patch was made for re-inclusion a couple months ago, but it hasn't hit any git trees that I've seen. There's likely a number of other missing pieces as well, but that one is critical. So no support for N900 in any kernel since at least 2.6.29. -Jeff Moe http://wiki.maemo.org/User:Jebba ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo code in Linux kernel?
On Thursday 04 February 2010 06:13:07 Yves-Alexis Perez wrote: On 04/02/2010 12:32, Jeff Moe wrote: On Thursday 04 February 2010 04:23:59 Marcin Juszkiewicz wrote: Dnia czwartek, 4 lutego 2010 o 11:53:22 Christopher Intemann napisał(a): I came across this blog-entry [1] which is describing why the Android kernel extensions were removed from the current kernel version. I'm just curious: Where does Nokia/ Maemo stand? Are there Maemo sources in the official Linux kernel tree at all? Good question. Some of nokia/Maemo code landed in linux-omap tree, some got into vanilla. But the question can be: is any of official kernel trees capable to provide fully working 2.6.33-rc kernel for nokia 770/n8x0/n900 tablet? At least for the N900 the answer is no. The touchscreen driver disappeared at 2.6.29: drivers/input/touchscreen/tsc2005.c A patch was made for re-inclusion a couple months ago, but it hasn't hit any git trees that I've seen. There's likely a number of other missing pieces as well, but that one is critical. So no support for N900 in any kernel since at least 2.6.29. And it might depend on what you call 'official kernel trees' too. There's a really nice page on n900 hw at http://natisbad.org/N900/n900-commented-hardware-specs.html where you can find information about kernel support. Well, I'll take unofficial trees too. I don't know of anyway to get a recent kernel built using what patches and git trees that are publicly available. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PPA's?
On Thursday 04 February 2010 16:35:07 Attila Csipa wrote: On Thursday 04 February 2010 21:59:41 Kees Jongenburger wrote: PPA's have been discussed a few times already and did not receive real negative votes. The Maemo community has put a great effort in removing all the external repositories that where alive or dead on different sites so I guess we are a little afraid :p. One of the biggest problems besides chaos was the question if you can trust code that is not compiled on a independent system. I would like to use something like PPA to be able to select apps I want to install on my N900 when using my PC but ssh works pretty well :p I think the proposal was for a PPA system like the launchpad/Ubuntu one - it's not different sites, just extras-devel class builds that you do not intend for the general (even developer) public (but still made and stored on the community server). If you ask me, I'd even consider everybody land packages from the autobuilder into their PPA and promote to extras-devel from there (I always feel bad when I experiment with packages in extras-devel, as unsuspecting folks might pull in some work-in-progress stuff, plus all the potential cruft just snowballing the Packages file...). This would be really cool. :) Then at least people's changes would be all in one place for easy review instead of spewed all over the place. For instance, if we had this I would: * Put the etch builds there first * Put my kernel builds there. * Put packages that conflict with something in extras-devel already (e.g. I have mplayer builds that have jack and perhaps a few other features enabled). Right now things are just in random locations (for me and others). It would be nice to have it all unified. -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Debian Etch, Rebuilt: 6,451 .debs for Maemo 5
On Wednesday 03 February 2010 02:14:01 you wrote: I would like to do some testing of maemian on the built packages - just to see what sort of data there is an how to go about making maemian more friendly to developers. You've given me a login to your machine so I assume you don't mind me doing this but I thought I would ask you first. I would also like to make the maemian logs visible as well. Is that okay? You have a login on mas (espejo node 1); this is obra. Both are virtual KVMs on topo at NetDepot. I copied over your key from mas, so you should be able to ssh jerem...@obra.freemoe.org. Interesting dir for you may be: /var/www/freemoe-etch/ You have many gigs of space @ /home--feel free to copy over the whole archive (9.3G) to your homedir and process the files as you like. All can be made visible. -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Debian Etch, Rebuilt: 6,451 .debs for Maemo 5
Hey, * I rebuilt all Debian Etch source packages with the Maemo 5 SDK and sdbmock. * 10,220 Source packages processed. * 6,451 .debs produced. * The job ran for 8 days. * They have not been run through maemo-optify yet--I will test the fix for the recursive symlink bug[1] when ready. * They were compiled against the current maemos-extras repository. They have no dependencies other than that. In other words, no package within the rebuild depends on anything else in the rebuild--this is the first pass. * I could batch import packages that don't already exist in extras-devel. I think this would be rad. * Download locations (temporary): Directory: http://obra.freemoe.org/freemoe-etch/ Install file for N900: http://obra.freemoe.org/obra.install /etc/apt/sources.list: deb http://obra.freemoe.org/freemoe-etch ./ * Thx Ed for sbdmock help. Have fun, -Jeff Moe http://wiki.maemo.org/User:Jebba [1] https://bugs.maemo.org/show_bug.cgi?id=7707 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Debian Etch, Rebuilt: 6,451 .debs for Maemo 5
On Tuesday 02 February 2010 21:20:25 Jeff Moe wrote: /etc/apt/sources.list: deb http://obra.freemoe.org/freemoe-etch ./ CORRECTION: deb http://obra.freemoe.org/ freemoe-etch/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Debian Etch, Rebuilt: 6,451 .debs for Maemo 5
On Tuesday 02 February 2010 23:04:57 you wrote: ext Jeff Moe m...@blagblagblag.org writes: * 10,220 Source packages processed. * 6,451 .debs produced. This means there were a lot of build failures (as could be expected). Mining the failures would be interesting, too. I suppose a lot are due to missing build dependencies, but some have probably failed in more interesting ways. Do you have the build logs online as well? Yes, from http://obra.freemoe.org/freemoe-etch/3/3dchess/root.log to http://obra.freemoe.org/freemoe-etch/z/zziplib/build.log * I could batch import packages that don't already exist in extras-devel. I think this would be rad. You should probably also exclude packages that already exist in the SSU and SDK repositories, just to avoid confusion. Yes, I was thinking of running a few checks across the package before submitting it, such as: * In extras* ? * Depends: are ok? Just because the Build-Depends: were there doesn't mean the Depends: are there. * Isn't ridiculously huge? etc. Suggestions welcome. Future options include: * Building with faster flags (neon etc). * Automatically adding icon + Section: if is GUI app. * Rebuilding against itself (2nd and multiple passes). This will build yet many more packages since so many more libfoo-* have been built. * Lenny? Sid? * http://wiki.maemo.org/User:Jebba/Etch As a side note, this build was done on a server at netdepot.com. They graciously bumped the RAM about 25% of the way into the build... For the future(tm), I have created Amazon Machine Instances of the build server (SDK + sbdmock) for use on Amazon's Elastic Compute Cloud (EC2). Using these, innumerable virtual machines can be launched in Amazon's most excellent network and set to work building packages. Rent by the hour, then turn the thing off. :) http://aws.amazon.com/ec2/ -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: libqt4-dev: Broken packages
On Friday 29 January 2010 11:27:17 Matus Uzak wrote: Hi, I'm unable to install libqt4-dev in FREMANTLE_ARMEL target, FREMANTEL_X86 is Ok. Do I have to make a bug report? $ fakeroot apt-get install libqt4-dev Reading package lists... Done Building dependency tree... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. Since you only requested a single operation it is extremely likely that the package is simply not installable and a bug report against that package should be filed. The following information may help to resolve the situation: The following packages have unmet dependencies: libqt4-dev: Depends: libqt4-webkit but it is not going to be installed E: Broken packages If you chase this build dependency you will find it is because you are missing a non-free proprietary package from Nokia's repository. Enable the repo that requires you to have a long string in the deb URL and it will fix your missing dep. Then file a bug report asking for that package to be freed. ;) -Jeff Moe http://wiki.maemo.org/User:Jebba ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Build Server Configuration
On Tuesday 26 January 2010 02:02:52 you wrote: 2010/1/26 Jeff Moe m...@blagblagblag.org: On Monday 25 January 2010 15:02:57 Ed Bartosh wrote: [chop] # Additional apt-get parameters config_opts['apt-get_options'] = '-o APT::Get::AllowUnauthenticated=1' # Command to run after rootstrap unpacking config_opts['after_rootstrap'] = 'fakeroot apt-get -y -q %s install maemo-optify' % config_opts['apt-get_options'] I'm building fine in sbdmock unless the package calls maemo-optify. I don't see where after_rootstrap occurs in sbdmock, so I think that above `apt-get install` isn't being run (maemo-optify doesn't get installed in the chroot). How are you getting maemo-optify installed in every chroot? I'm using sbdmock with corresponding change. You can find it here: http://github.com/bartosh/sbdmock/tree/after_rootstrap The change was discussed with upstream author and merge request has been sent to him some time ago. It's not merged in his gir repo yet, but I hope it will be eventually. OK, I did build with your sbdmock git tree, but after_rootstrap not in the main branch. I see after_rootstrap in the origin/after_rootstrap branch. Is that the preferred branch to use? Is that the one you guys are running? The other git repo, for those watching, is this one: http://github.com/kad/sbdmock And Ed's is this one: http://github.com/bartosh/sbdmock Thanks, -Jeff Moe http://wiki.maemo.org/User:Jebba ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Build Server Configuration
On Tuesday 26 January 2010 12:20:32 you wrote: 2010/1/26 Jeff Moe m...@blagblagblag.org: On Tuesday 26 January 2010 02:02:52 you wrote: 2010/1/26 Jeff Moe m...@blagblagblag.org: On Monday 25 January 2010 15:02:57 Ed Bartosh wrote: [chop] # Additional apt-get parameters config_opts['apt-get_options'] = '-o APT::Get::AllowUnauthenticated=1' # Command to run after rootstrap unpacking config_opts['after_rootstrap'] = 'fakeroot apt-get -y -q %s install maemo-optify' % config_opts['apt-get_options'] I'm building fine in sbdmock unless the package calls maemo-optify. I don't see where after_rootstrap occurs in sbdmock, so I think that above `apt-get install` isn't being run (maemo-optify doesn't get installed in the chroot). How are you getting maemo-optify installed in every chroot? I'm using sbdmock with corresponding change. You can find it here: http://github.com/bartosh/sbdmock/tree/after_rootstrap The change was discussed with upstream author and merge request has been sent to him some time ago. It's not merged in his gir repo yet, but I hope it will be eventually. OK, I did build with your sbdmock git tree, but after_rootstrap not in the main branch. I see after_rootstrap in the origin/after_rootstrap branch. Is that the preferred branch to use? Is that the one you guys are running? Yes, as I said (see github url above). The other git repo, for those watching, is this one: http://github.com/kad/sbdmock This is upstream author's repo. Mine is forked from it. Cool, thx, things are moving along fine. :) I have seen this error though, any hints? Unpacking libimlib2 (from .../libimlib2_1.4.0-1.2maemo2_armel.deb) ... dpkg: error processing /var/cache/apt/archives/libimlib2_1.4.0-1.2maemo2_armel.deb (--unpack): trying to overwrite `/opt', which is also in package base-files ... Errors were encountered while processing: /var/cache/apt/archives/libimlib2_1.4.0-1.2maemo2_armel.deb /var/cache/apt/archives/libimlib2-dev_1.4.0-1.2maemo2_armel.deb E: Sub-process /scratchbox/devkits/debian-etch/bin/dpkg returned an error code (1) Thanks 1000x! -Jeff Moe http://wiki.maemo.org/User:Jebba ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: up-to-date debhelper and cdbs
On Sunday 24 January 2010 03:54:16 Thomas Tanner wrote:
Hi,
many Debian packages require more recent versions of debhelper
or cdbs than the outdated ones installed in the scratchbox devkits
(debhelper 5.0.42 and cdbs 0.4.48, both more than 3 years old).
The newer version make packaging also much easier.
I think I have found a minimally invasive workaround how to
use the latest version of debhelper (7.4.10) and cdbs (0.4.62)
in the SDK and autobuilder (see later).
HOWTO:
In your debian/control file replace the dependencies
debhelper (= 7) with debhelper7
cdbs ( 0.4.48) with cdbs-dh7
add the following to the beginning of your debian/rules
PATH:=/usr/bin:$(PATH)
export PATH
SBOX_REDIRECT_IGNORE:=$(shell echo /usr/bin/{perl,dh_*} | sed s/ /:/g)
export SBOX_REDIRECT_IGNORE
In your SDK you can run
apt-get install debhelper7 cdbs-dh7
which will automatically remove the old versions,
which were overwritten by the devkits anyway.
To restore the old versions use
apt-get remove debhelper7 cdbs-dh7
apt-get install debhelper cdbs
PROBLEM:
autobuilder should automatically install these build-depends
but currently it fails with
The following packages will be REMOVED:
debhelper
The following NEW packages will be installed:
bsdmainutils bsdutils debhelper7 groff-base man-db
E: Packages need to be removed but remove is disabled.
see the buildlog of a package used for testing the workaround
https://garage.maemo.org/builder/fremantle/dpkg-repack_1.31maemo1/i386.root.log.FAILED.txt
Would it be possible to allow package removal in autobuilder?
Interesting approach. I ran into this this weekend trying to use a non-broken
cdbs. I did a kludge around it by adding this to debian/control:
Build-Depends: maemo-cflags-cdbs-rules
That got the builder to install the more recent cdbs available in the repo.
-Jeff
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Build Server Configuration
On Saturday 23 January 2010 04:07:48 Ed Bartosh wrote: 2010/1/23 Jeff Moe m...@blagblagblag.org: Could the configuration files of the build server and related scripts be put up on the wiki or mailed here or something? I had a build fail due to a small difference between the SDK and the buildbox. I would like to be able to have an identical setup to the build box before submitting jobs. It doesn't differ too much from what I showed in December[1] The only valuable difference I can see is that SDK have been changed. # Official SDK repositories: -deb http://repository.maemo.org/ fremantle/sdk free non-free -deb http://repository.maemo.org/ fremantle/tools free non-free +#deb http://stage/ fremantle/sdk free non-free +#deb http://stage/ fremantle/tools free non-free + +#revert PR1.1 because of backwards compatibility issue 2010-01-19 -Niels + +deb file:/scratchbox/packages/maemo5.0_update1_public/ fremantle/sdk free non-free +deb file:/scratchbox/packages/maemo5.0_update1_public/ fremantle/tools free non-free As you can see from the comment Niels did this change. BTW, what do you think about to prepare guide for developers for easy setup of local buld configurations identical to autobuilder ones? I can provide whatever information you need for that. Yes this would be very nice. I am starting to put all the scripts I use in a git archive on gitorious. As I set up sdbmock (starting from scratch again), I will add configs/scripts there: http://gitorious.org/freemoe/ git clone git://gitorious.org/freemoe/freemoe.git I was thinking of making a servers/ subdir and store specific configs for them in there (e.g. servers/espejo/rsync.d conf). The buildserver has been running nice and fast the last 48 hours or so--lots of packages have been pushed through. :) 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. Thanks, -Jeff http://wiki.maemo.org/User:Jebba ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Build Server Configuration
On Saturday 23 January 2010 04:07:48 you wrote: BTW, what do you think about to prepare guide for developers for easy setup of local buld configurations identical to autobuilder ones? I can provide whatever information you need for that. Ok, I pushed my first successful package throught sdbmock armel extras-devel. The preliminary config files for the server are in the git repo, browsable here: http://gitorious.org/freemoe/freemoe/trees/master/servers/obra Also, can you give me an i386 example? How about scripts that process incoming jobs, etc? Thanks! -Jeff Moe http://wiki.maemo.org/User:Jebba ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Quick start packaging guide
On Friday 22 January 2010 13:10:29 Dave Neary wrote: Hi all, Due to popular demand, I sat down this week with Jeremiah Foster, who explained to me the very quickest way to go about packaging an application. We didn't quite get to uploading to extras, but going from a .tar.gz to a correct .deb is there. http://wiki.maemo.org/Maemo_packaging_quick_start_guide I intend this article to be a kind of landing-point for new Maemo developers. It should contact the short path, with a bunch of shortcuts taken, and lots of links to canonical material. Improvements are welcome! Especially as related to: http://wiki.maemo.org/Packaging http://wiki.maemo.org/Maemo_packaging http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging,_Deploying_and_Distributing http://wiki.maemo.org/Extras http://wiki.maemo.org/Extras-testing http://wiki.maemo.org/Uploading_to_Extras-devel http://wiki.maemo.org/Uploading_to_Extras http://wiki.maemo.org/Developer_FAQ#Extras If we obsolete any of these pages, I'll be happy. If we make it easier to find useful stuff by linking to it from an easy-to-remember-and-reference portal page, I'll be happy. And if this email leads me to discover even more pages which have the same or similar content, even that will make me happy if we can consolidate it all nicely make it nice easy for new developers to find correct information on this. http://wiki.maemo.org/User:Jebba/Package_Building_HOWTO -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Build Server Configuration
Could the configuration files of the build server and related scripts be put up on the wiki or mailed here or something? I had a build fail due to a small difference between the SDK and the buildbox. I would like to be able to have an identical setup to the build box before submitting jobs. Thanks, -Jeff Moe http://wiki.maemo.org/User:Jebba ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Keeping up with the autobuilder
On Thursday 21 January 2010 20:57:41 Tuomo Tanskanen wrote: gmane.comp.handhelds.maemo.extras-cauldron.builds, from the news server at news.gmane.org, with a blog page at http://blog.gmane.org/gmane.comp.handhelds.maemo.extras-cauldron.builds and an RSS feed at http://rss.gmane.org/gmane.comp.handhelds.maemo.extras-cauldron.builds I find it quite handy to view the feed through Akregator; the subject lines tell me what is (or isn't!) happening, and the mail messages don't fill my mailbox. When the feed showed simplenotewidget being built every two minutes, I knew someone was going to have an interesting morning. Thanks, this is among the list of things I've been missing lately! Yes, this is very handy. Several other maemo mailing lists are also available through gmane. Would it be useful to put this information on maemo.org's mailing list pages? I second this. I set up links to each Gmane archive page which has Maemo as a subject and listed links to each RSS feed in the wiki: http://wiki.maemo.org/Community_mailing_lists -Jeff Moe http://wiki.maemo.org/User:Jebba ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
On Monday 18 January 2010 18:08:33 Niels Breet wrote: 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]? For what it's worth, in the Fedora buildsystem (Koji), the buildsystem is running with the latest updates. Perhaps investigating what the various other distros do (especially Debian) and doing what they do would be a good approach (if they have mostly all settled on similar approaches). -Jeff (goes back to lurking on this thread) http://wiki.maemo.org/User:Jebba ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to destroy your community
On Tuesday 19 January 2010 12:39:39 Murray Cumming wrote: On Tue, 2010-01-19 at 08:43 -0300, Jeff Moe wrote: I don't have to be here for years to see how things are managed and where the problems are. Things are clearly in progress. It's apparently a move in the right direction, I'm not quite sure they are. Didn't the server just get moved *to* an ISP that can't fix NFS mounts on weekends? What ISP is this? even if it's not everything you want. How about letting it settle down just a little bit and then calmly suggesting how to avoid problems in future. People have been preaching patience (not just to me, to everyone) since I landed here and before. Why should we be patient? Why can't we demand things work like they do everywhere else? I'm sure google/apple would love for us to be patient for the next 3 years. I am sure that Tero and his colleagues would actually like ideas that reduce the awkward infrastructure work. I've already suggested *many* ways for things to be improved: * Copy Fedora Infrastructure Standard Operating Procedures, in which I track down a Fedora admin to get info, explain how they do things, and give links for more info: http://lists.maemo.org/pipermail/maemo-developers/2010-January/023329.html http://lists.maemo.org/pipermail/maemo-developers/2010-January/023337.html * I also sent a list about the same issue to council, providing more info about how other distros handle such things. (offlist, but the council sent it to the list before checking with me). * I suggest using mirrors well before the most recent outage. Not only do I suggest it, I go on a actually set up a mirror, fully document how it is done in the maemo.org wiki, and give full root access to a Maemo admin. Later on this mirror is heavily used during a major maemo outage. I also within hours set up two additional mirror servers in distinct data centers: http://lists.maemo.org/pipermail/maemo-developers/2010-January/023337.html http://lists.maemo.org/pipermail/maemo-developers/2010-January/023392.html http://lists.maemo.org/pipermail/maemo-developers/2010-January/023425.html http://espejo.freemoe.org/ http://wiki.maemo.org/User:Jebba/Espejo http://wiki.maemo.org/User:Jebba/Mirror * Suggest, and write a mini-howto about documenting server changes. It appears the maemo admin team cannot tell when or who has made changes to system configurations (!). http://lists.maemo.org/pipermail/maemo-developers/2010-January/023560.html * Wherein I discover that the SDK has been silently changed and suggest that version numbering be used: http://lists.maemo.org/pipermail/maemo-developers/2010-January/023776.html This directly lead to this thread about how the SDKs should be set up, which is of course vitally important: http://lists.maemo.org/pipermail/maemo-developers/2010-January/023781.html * Suggest moving DNS to someone other than Nokia, due to a major extended DNS outage (IMHO, this should *never* happen). This could be *easily* implemented and would greatly increase reliability of the entire infrastructure: http://lists.maemo.org/pipermail/maemo-developers/2010-January/023805.html * Along with all that, I have frequently documented actual outages in what is currently the proper place for this. I believe my reports were good--in any case I asked if more info was needed and none was asked for. I even offered SSH access to confirm it. https://bugs.maemo.org/show_bug.cgi?id=5818 Note, I haven't documented every single outage I've seen--there have been far more. In fact, *today* many people around the world are still reporting outages on talk.maemo.org. --- If I seem a little testy maybe it's because I've been told to be patient for way too long. Patience with a server outage should be measured in hours, not months. If maemo doesn't find a way to solve these problems, they will be crushed in the end. A blogger recently pointed out along the lines of mindshare is the marketshare of the future. Maemo is losing mindshare and developers due to these *continued* problems. I've seen frequent mentions of how distinct maemo.org is from Nokia. But the reality seems that nothing at Maemo can really happen without Nokia's tacit approval. Is there anyone that has server access that isn't paid (directly or indirectly) by Nokia? Can we start getting the servers admin'd by community admins instead of depending upon Nokia? A first step would be to document (on the *outside/public*) wiki the current server arrangement. Another good step would be to get DNS off their servers. Until that happens, the whole maemo is distinct from Nokia is just a façade. I once sent this analogy to someone: Nokia built a wonderful hockey stadium, great seats, boxes, huge LCD screens. They gave out free tickets to the the public and a free beer token to adults. The players got new uniforms, clean locker rooms, and top doctors. Then the athletes went to play, but the equipment manager gave them styrofoam
Re: How to destroy your community
On Wednesday 20 January 2010 15:54:53 Dave Neary wrote: Hi, Jeff Moe wrote: People have been preaching patience (not just to me, to everyone) since I landed here and before. Why should we be patient? Why can't we demand things work like they do everywhere else? I'm sure google/apple would love for us to be patient for the next 3 years. I guess that the problem is that you demand rather than request. Well, they certainly started out as requests. I definitely am getting progressively louder though. Can you show me demanding in this? http://lists.maemo.org/pipermail/maemo-developers/2010-January/023363.html or this http://lists.maemo.org/pipermail/maemo-developers/2010-January/023329.html or Do I need to dig up more posts, IRC logs, etc to show requests? Plus you're totally missing the point. The fact is things need to get sorted out, whether I exist or not. I've certainly offered plenty of paths for things to get fixed. The fastest way to get me to STFU is to get things working. ;) -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Upload to fremantle-extras-builder broken?
On Wednesday 20 January 2010 16:00:45 Niels Breet wrote: 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. See also: https://bugs.maemo.org/show_bug.cgi?id=8077 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to destroy your community
On Wednesday 20 January 2010 15:54:53 you wrote: Hi, Jeff Moe wrote: People have been preaching patience (not just to me, to everyone) since I landed here and before. Why should we be patient? Why can't we demand things work like they do everywhere else? I'm sure google/apple would love for us to be patient for the next 3 years. I guess that the problem is that you demand rather than request. Reflecting further: Why can't I *demand* as well? I so far have spent around $5,000 on N900s. Can't I, as an *end user*, demand a working repository as a minimum? This is what was advertised as part of Maemo/N900 package when I bought it. -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to destroy your community
On Wednesday 20 January 2010 16:20:35 Aldon Hynes wrote: You can *demand*. You can also ask in a way that is likely to be more effective or join in a discussion about how we can all work together to make sure that we all get the best possible equipment and supporting infrastructure. And which discussion would that be? I just searched the archives back to October and don't see any public discussion about the server infrastructure. Perhaps they are elsewhere. Everytime I asked about it previously (mostly in IRC), I was basically told to just sit and wait for them to sort things out. It's hard to offer much advice when there is basically zero public info about the server arrangement, but I have offered what I think to be good suggestions based on the anecdotal tidbits available. The discussions that do exist, I initiated. Or, how about instead of complaining about my tone you actually add something useful to the discussion? Do you have any suggestions, corrections, or improvements about any of my suggestions? There certainly must be some as I am only one admin. -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to destroy your community
On Wednesday 20 January 2010 18:17:30 Jeremiah Foster wrote: 1. Maemo.org DNS should probably be on physically separate networks, with redundant servers worldwide. DyDNS can do this cheaply, there were other suggestions as well. Yes, would be very nice. Then the admins wouldn't have to wait for Nokia to make the changes (which appear to be very slow) and could just do it themselves directly. With DirectNIC (and likely most others), you can even set the TTL in a *web form*. So days in advance the TTL could be set to one hour, so in worst case that would be the longest people would keep stale data in their caches. Click click! Done. 2. The maemo.org repositories should be mirrored in the free software community at places like Ibiblio or similar, to provide a measure of redundancy. Yes. First step in this is to set up an rsync server. I have a sample config here: http://wiki.maemo.org/User:Jebba/Espejo#rsync I also think that database dumps (say weekly) should be done of the wiki and be available for download. I can dig up a SQL command (e.g. that leaves out user/pass info) if you want. This way others can make backups and then it could also be used with (the very cool) offline mediawiki viewer evopedia. Basically, if infrastructure data can be put in an easily downloadable format for copying, it should be. The more copies downloaded, the better. :) 3. Whatever ISP is chosen to host the site should feel like a stakeholder in the success of the maemo community. They should feel motivated for things to work 24/7. Definitely. /me takes third swing: and just who is this ISP right now? I know akamai is in the picture, but apparently someone else is hosting the main part (e.g. the NFS/SAN ISP). I wouldn't even go as far as say they should be a stakeholder, they just need to provide industry standard quality. Any ISP that isn't motivated 24/7 should be dropped. I think one extended outage of the nature we saw over the weekend is enough even (e.g. the hunt for a new ISP should begin immediately). 4. The community should be allowed to help with the infrastructure. Perhaps some services should be entirely released to the community? Or maybe start using community resources like the SuSE OBS? The first part of this would be to document what is there already. Also, document the current procedures (publicly--the IRC logs seem to indicate there is an internal Nokia wiki with this info). I have a feeling if the server move procedures had been public, lots of good suggestions would have been made by the various sysadmins on this list (e.g. it appears they didn't even think about changing DNS TTLs--surely many on this list would have caught that). We apparently have people on this list who have managed projects even larger than Maemo--their experience should clearly be leveraged. Many eyeballs make all bugs shallow applies here too. 5. Greater communication and transparency from the maemo staff. Definitely. Each move needs to be announced somewhere. For developer issues (e.g. the builder, anything to do with SSH keys, etc.), this list seems an appropriate place. For another announcements (e.g. the server move in general) perhaps talk.maemo.org would be best in some stickied thread until the move is over. Qaiku I think is about the worst place, as for anyone to followup they need to get yet another account and there isn't really a good mechanism for discussion in short tweets. One excellent ISP I use has a dedicated list to this--for example see: http://frii.com/support/fta/ Also, perhaps I'm missing it, but it seems really hard to even figure out who the maemo staff is. Perhap I'm missing the obvious wiki page with this info (ala http://wiki.maemo.org/People ). Who is the paid maemo staff? Sincerely, your unpaid paying customer, -Jeff Moe http://wiki.maemo.org/User:Jebba ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to destroy your community
On Wednesday 20 January 2010 19:01:01 Valerio Valerio wrote: Also, perhaps I'm missing it, but it seems really hard to even figure out who the maemo staff is. Perhap I'm missing the obvious wiki page with this info (ala http://wiki.maemo.org/People ). Who is the paid maemo staff? http://wiki.maemo.org/Maemo.org_team Cool, thanks. How does Tero Kojo, for example, fit into this picture? I (and apparently others) have a hard time figuring out what the hierarchy is here. Like the most excellent Quim Gil isn't there either. A nice chart with Ari Jaaski at the top would be most instructive. Gotta run. Will point out that Jeff=Jeff later, perhaps! -Jeff, switching hemispheres http://wiki.maemo.org/User:Jebba ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to destroy your community
On Wednesday 20 January 2010 19:21:18 Ryan Abel wrote: On Jan 20, 2010, at 1:04 PM, Jeff Moe wrote: I've seen frequent mentions of how distinct maemo.org is from Nokia. But the reality seems that nothing at Maemo can really happen without Nokia's tacit approval. Is there anyone that has server access that isn't paid (directly or indirectly) by Nokia? Can we start getting the servers admin'd by community admins instead of depending upon Nokia? A first step would be to document (on the *outside/public*) wiki the current server arrangement. Another good step would be to get DNS off their servers. Until that happens, the whole maemo is distinct from Nokia is just a façade. Maemo is a trademark owned by Nokia and used for their software platform and their products. You're confusing Maemo and maemo.org (maemo.org being the community-owned website). In doing so, you're confusing the discussion and making it much more difficult to participate and arrive at a useful conclusion. Maemo and maemo.org are not equivalent interchangeable terms. Yep! Definitely confusing them. They do seem much one and the same to me though. It seems we've come to some useful conclusions, regardless Though how does the community own maemo.org? I mean, can we really just walk off with it and leave Nokia behind? I doubt it. Can we see the finances of this website, please? -Jeff, really gotta run! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to destroy your community
On Tuesday 19 January 2010 07:13:30 Jeremiah Foster wrote: 10) Silence. Don't answer queries, don't say anything. A company which masters this technique may not need any of the others; it is the most effective community destroyer of them all. Ooops! No silence here! I guess that disproves point 10. :-) (http://jaaksi.blogspot.com/ -- More non-silence.) Actually, when I cut and pasted that article snippit I was thinking about his blog *specifically*. AFAICT he has the highest position in Nokia with respect to the Maemo project (correct me if I'm wrong plz). He has a whopping 5 blog posts since the device has been out. His karma in maemo.org is 100% based on his blog posts. He gets asked lots of questions in the blog comments, but rarely answers. Since the N900 has been out, I see he only answered two comments, one of which was mine. ;) The other comment he replied to starts like this: Is there any reason why all my contact attempts with you, Mr. Makkinen and other Maemo people at Nokia are being ignored? ... Excuse me for posting it this way, but what else am I supposed to do if all I get in exchange for my emails is delivery confirmations? I wonder if he ever got a response. Blogs are often used as two way communication tools, he uses it for the occasional edict or a marketing promotion tool. -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to destroy your community
On Tuesday 19 January 2010 06:13:00 tero.k...@nokia.com wrote: Some gems: 1) It's also important to set up an official web site which is down as often as it's up. It's not enough to have no web site at all; in such situations, the community has an irritating habit of creating sites of its own. But a flaky site can forestall the creation of those sites, ensuring that information is hard to find. Jeff, you have been hanging around here for what, 2 months? And those two months have been the time in which this place has seen it's biggest growth of all time. Sure that made the system break in the corners, but it's being fixed. I've had my device for 1200 hours so far (50 days). For how many of those hours have the various services been down? I'm not sure everything has ever been working for a full complete day. Break in the corners? That's quite a gloss. We've heard for quite some time (months before I came) about the big server move. Is this done? AFAICT, the servers have been moved and the new system is set up with tweaks being done (such as akamai serving gunzipped files!). Correct me if I'm wrong, and I hope I am, but it appears the servers have been moved to an ISP that cannot fix a broken NFS mount on the weekend. Is this really the situation? How on earth did maemo get stuck with this ISP? Who are they, in fact? It also looks like maemo.org DNS depends upon Nokia's nameservers. Apart from the NFS problems over the weekend, DNS resolution was also awry. Is there no one to fix DNS issues at Nokia on weekends? Is this really why DNS was down for so long? That can hardly be blamed on growth. A small pentium could keep up with maemo DNS requests. This is a problem of design and procedure, not of growth. DNS nowadays is often as simple as filling in a web form. This isn't rocket science. Perhaps it's time to move maemo.org DNS out of Nokia's hands and to a separate provider. There are likely hundreds that will provide better service than Nokia. I recommend DirectNIC since they were able to withstand, with zero downtime, hurricane Katrina from downtown New Orleans, but there are many many providers that could handle it. Hang around for a couple of more years and then come back with the statistics. Do you have any statistics for 2009? Would you be willing to share them? Do you realize even if you run things perfectly 100% for the rest of 2010 you have zero chance of 99.9% uptime (a reasonable baseline)? So I'll have to wait until 2011 statistics til the servers are more in line with industry expectations. A few admins commented in threads about the outage along the line of if something is down, we work non-stop until it is back up or even we'd be laid off if this happend at work. It seems that attitude is lacking with respect to maemo. During the most recent outage, I was able to provision an entirely new server and have a fresh OS install on a second one while on vacation in the mountains with a seriously crap wifi connection, yet no one in all of maemo/nokia was able to do anything to alleviate the outages? I don't have to be here for years to see how things are managed and where the problems are. -Jeff Moe http://wiki.maemo.org/User:Jebba ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to destroy your community
On Tuesday 19 January 2010 08:20:42 David Weinehall wrote: On tis, 2010-01-19 at 12:10 +0100, ext Jeff Moe wrote: On Tuesday 19 January 2010 07:13:30 Jeremiah Foster wrote: 10) Silence. Don't answer queries, don't say anything. A company which masters this technique may not need any of the others; it is the most effective community destroyer of them all. Ooops! No silence here! I guess that disproves point 10. :-) (http://jaaksi.blogspot.com/ -- More non-silence.) Actually, when I cut and pasted that article snippit I was thinking about his blog *specifically*. AFAICT he has the highest position in Nokia with respect to the Maemo project (correct me if I'm wrong plz). He has a whopping 5 blog posts since the device has been out. His karma in maemo.org is 100% based on his blog posts. He gets asked lots of questions in the blog comments, but rarely answers. Since the N900 has been out, I see he only answered two comments, one of which was mine. ;) The other comment he replied to starts like this: Is there any reason why all my contact attempts with you, Mr. Makkinen and other Maemo people at Nokia are being ignored? ... Excuse me for posting it this way, but what else am I supposed to do if all I get in exchange for my emails is delivery confirmations? I wonder if he ever got a response. Blogs are often used as two way communication tools, he uses it for the occasional edict or a marketing promotion tool. So, what you're saying is that you acknowledge that Ari is the highest ranking person within Maemo. I take that as a confirmation. Then you are surprised that he doesn't have time to answer random comments made on his blog... I wouldn't say I'm surprised. I can't find anywhere in the *.maemo.org space where he is interacting with folks. For instance, take an *ideal* project leader like Linus. If he had a blog, he might not answer random blog comments, but there's another mechanism for communicating with him, most prominently LKML. So there is two way communication. My point with the blog is that it's almost entirely one way with the community. Perhaps he's on some list or something I've overlooked--if so, please correct me. -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to destroy your community
On Tuesday 19 January 2010 10:00:51 Marcin Juszkiewicz wrote: Dnia wtorek, 19 stycznia 2010 o 12:57:32 Jeff Moe napisał(a): For instance, take an ideal project leader like Linus. If he had a blog Linus Torvalds has a blog and posts there. http://torvalds-family.blogspot.com/ Haha! And he even occassionally responds to comments there too! (More than Maemo's leader.) Like I said, *ideal* ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Cannot get all indexes in Scratchbox doing an apt-get update
On Tuesday 19 January 2010 13:41:08 Andrea Grandi wrote: Hi, I was trying to do a simple apt-get update in my Scratchbox installation, since I had not done it after the release of PR 1.1, but I'm getting this error: http://pastebin.ca/1757618 It doesn't look like the same DNS problem, because I'm not getting errors with all repositories, but only with the one containing Sources. Any idea about hot I could fix this? There was a problem with akamai. Apparently it was flushed and working now. See these logs and search for Will take around 10 minutes for it to flush still. for some context: http://mg.pov.lt/maemo-irclog/%23maemo.2010-01-19.log.html -Jeff Moe http://wiki.maemo.org/User:Jebba ___ 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 Tuesday 19 January 2010 12:29:31 Niels Breet wrote: On Tue, 2010-01-19 at 14:25 +0100, Niels Breet wrote: 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. Where are these discussions taking place? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
SDK rootstraps updated
Take note, since the service restoration, the Maemo 5 SDK rootstraps have been (silently?) updated with no changes to timestamps: The current rootstrap: je...@espejo:/var/www$ ls -l repository.maemo.org/stable/fremantle/armel/MD5SUM -rw-r--r-- 1 jebba jebba 137 2010-01-13 03:48 repository.maemo.org/stable/fremantle/armel/MD5SUM je...@espejo:/var/www$ cat repository.maemo.org/stable/fremantle/armel/MD5SUM 290e68bfd874e3d6049e0016624b13e5 maemo-sdk-rootstrap_5.0_armel.full 1524f4b4e4e9cd6693611e2584772eb8 maemo-sdk-rootstrap_5.0_armel.tgz The previous rootstrap (note identical timestamp): je...@espejo:/var/www$ ls -l /home/jebba/armel-sdk/MD5SUM -rw-r--r-- 1 jebba jebba 137 2010-01-13 03:48 /home/jebba/armel-sdk/MD5SUM je...@espejo:/var/www$ cat /home/jebba/armel-sdk/MD5SUM 0b071fde66418d634fad51908eb25bd4 maemo-sdk-rootstrap_5.0_armel.full 1cccaa63e7ae4f8cb38a4ca4eeb94d02 maemo-sdk-rootstrap_5.0_armel.tgz To clarify, they have changed the contents of maemo-sdk-rootstrap_5.0_armel.tgz (and i386), updated the MD5SUM, but the files have the same timestamp. I assume you'll want the latest one that is in the repo if you tried the previous one (which may have been broken). -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDK rootstraps updated
On Monday 18 January 2010 11:51:00 Marcin Juszkiewicz wrote: Dnia poniedziałek, 18 stycznia 2010 o 15:08:07 Jeff Moe napisał(a): Take note, since the service restoration, the Maemo 5 SDK rootstraps have been (silently?) updated with no changes to timestamps: To clarify, they have changed the contents of maemo-sdk-rootstrap_5.0_armel.tgz (and i386), updated the MD5SUM, but the files have the same timestamp. I assume you'll want the latest one that is in the repo if you tried the previous one (which may have been broken). They could also just repack it and put there. Please compare both and share result. 736k diff. Also, the gzip appeared to be corrupt in the original version. But it wasn't just a corrupt gzip, as things clearly changed, such as: diff -ruN armel-old/etc/maemo_version armel-new/etc/maemo_version --- armel-old/etc/maemo_version 2009-12-02 06:02:44.0 -0700 +++ armel-new/etc/maemo_version 2010-01-13 01:47:42.0 -0700 @@ -1 +1 @@ -5.0update2 Fremantle +5.0update3 Fremantle Perhaps they should do version numbering of the SDKs as well, such as: maemo-sdk-rootstrap_5.0.3_armel.tgz -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDK rootstraps updated
On Monday 18 January 2010 12:23:09 Niels Breet wrote: The updated rootstraps are probably there PR1.1 ones? Wasn't the sdk updated at the same time as the PR1.1 firmware? Who puts maemo-sdk-rootstrap_5.0_armel.tgz on the server? They should be the one to ask. The SDK has been updated, the peculiar thing is that the timestamps didn't change. Also, the MD5SUM file is different, but doesn't match the original 5.0 final release nor the latest one (as of today). So it seems there were at least 3 versions. One approach would be to use version numbering and changelogs! Who does this? -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
LCA: How to destroy your community
Here is a good article in LWN about a presentation by Josh Berkus. How many of these points apply to Nokia? I'm afraid way too many. http://lwn.net/SubscriberLink/370157/2a06baf10df8e58a/ Some gems: 1) It's also important to set up an official web site which is down as often as it's up. It's not enough to have no web site at all; in such situations, the community has an irritating habit of creating sites of its own. But a flaky site can forestall the creation of those sites, ensuring that information is hard to find. 3) There should be no useful information about the code, build methods, the patch submission process, the release process, or anything else. Then, when people ask for help, tell them to RTFM. 4) Project decisions should be made in closed-door meetings. 5) Employ large amounts of legalese. 7) Keep the decision-making powers unclear 8) Screw around with licensing. Community members tend to care a lot about licenses, so changing the licensing can be a good way to make them go elsewhere. Even better is to talk a lot about license changes without actually changing anything; 10) Silence. Don't answer queries, don't say anything. A company which masters this technique may not need any of the others; it is the most effective community destroyer of them all. -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Mirrors
On Tuesday 05 January 2010 12:03:26 Jeff Moe wrote: On Tuesday 05 January 2010 04:08:19 tero.k...@nokia.com wrote: Thank you, I hope a local mirror helps in your case. apt-get update in 2 seconds. You are aware that we are using Akamai (fully distributed content delivery) for the caching? And that the hit and transfer amounts are way out of the league for anything we could set up ourselves? Yes, but that still doesn't preclude using mirrors. Akamai goes down too. Such as right now. Surprise surprise. (I'm not 100% sure it's akamai that is down as I don't have full details, but it seems something like that is going on.) So my one mirror that I set up is getting pegged at 100Mbit full on right now since I noted it a few times in passing in talk.maemo.org threads. Now, if someone with official standing at maemo (e.g. a webmaster) would have emailed a few of the well-known free software mirrors (e.g. ibiblio, mirrors.kernel.org, UK mirror service), we'd have a few very well provisioned mirrors to fall back on. Can someone with authority within maemo.org make these requests? It really is as simple as a few emails. Send out 10 emails, get 10 mirrors. If you want me to build up a list, I will. For the interim, you can use my mirror (it's serving up fine). Details here: http://espejo.freemoe.org/ -Jeff http://wiki.maemo.org/User:Jebba P.S. Resending message that *BOUNCED*. I honestly can't recall bouncing email to a mailing list in a decade. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Optification creates link-loop
On Tuesday 12 January 2010 10:30:39 Cornelius Hald wrote: Hi, I´m having a strange optification problem which leads to a link-loop. I´m building two packages out of one source tree and I´m having maemo-optify in /debian/rules. Package one is conboy and package two is conboy-midgard. Both packages install plugins as library files and small text files into /usr/lib/conboy/ The resulting conboy package has the complete /usr/lib/conboy directory moved to /opt/maemo/. So the link looks like this: /usr/lib/conboy -- /opt/maemo/usr/lib/conboy The resulting conboy-midgard packages only moves one .so file to /opt. Some smaller files are not moved. So the link looks like this: /usr/lib/conboy/midgard.so -- /opt/maemo/usr/lib/conboy/midgard.so When installing both packages via apt-get it creates a link-loop that looks like this: /opt/maemo/usr/lib/conboy/midgard.so -- /opt/maemo/usr/lib/conboy/midgard.so Does anyone know what´s going on there? I´m puzzled. If I manually extract the data.tar.gz files of both packages, the result looks fine. Help would be really appreciated! https://bugs.maemo.org/show_bug.cgi?id=7707 -Jeff http://wiki.maemo.org/User:Jebba ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Optification creates link-loop
On Tuesday 12 January 2010 10:56:16 you wrote: Jeff Moe wrote: https://bugs.maemo.org/show_bug.cgi?id=7707 That´s exactly it Jeff. Thanks for the hint! The questions are now: Is there a known work-around? Either optify by hand or turn off optification until the bug gets fixed: echo none debian/optify Will it get fixed in maemo-optify soon? Nokia doesn't comment about future plans or somesuch. ;) That said, I'm surprised it's not fixed already as they seem to be close to automatically optifying by default everything submitted to the builder. -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: oFono
On Saturday 09 January 2010 03:40:29 Qole wrote: So wait, you're saying we now have a fully open source telephony stack on the N900 that works to make phone calls? Quickly gotta run... Well, it may not all be open: * It fires up the Maemo phone GUI--I'd have to investigate what parts of that are open/closed. * It calls pulseaudio which may be using a proprietary codec for GSM audio. * It's only voice calls, no SMS etc, so it's not a full stack yet. I will be trying all this under Fedora 12 on N900 as that gives me a clean slate to work from to track down what all is really involved. But progress no doubt. :) -Jeff http://wiki.maemo.org/User:Jebba ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder is broken again
On Saturday 09 January 2010 06:36:12 Ed Bartosh wrote: Hi guys, Do you happen to know who switched off armel builds and why? May I humbly suggest using something like `git` to track configuration changes? In this case it may not have helped (e.g. if someone did a `/etc/init.d/foo stop`), but it will help you keep track of what changes are going on in the system if you have multiple admins. Quick dirty example: Have each user set up a ~/.gitconfig like: [user] name = Jeff Moe email = m...@blagblagblag.org [color] branch = auto diff = auto status = auto sudo bash apt-get install git-core cd /etc # make a /etc/.gitignore file along the lines of this: ld.so.cache prelink.cache *.swp ld.so.cache adjtime blkid.tab blkid.tab.old mtab adjtime ld.so.cache git init chmod og-rwx .git git add . EDITOR=vim git commit -a Then do `git add foo` when new files are added and `git commit -a` when finished making config changes. Then if you want to know WTF is going on, you can cd to /etc (as root) and run `git log`. If someone made changes, but didn't commit them, it's easy to check with `git diff`. You can also keep track of who made what changes too. This can be done with any directory, of course. Really works only with text files. If there's binaries in the sub dirs, you can add them to .gitignore or just never `git add` them. To blow out the whole git repo just `rm -r /etc/.git` and you can start fresh. Check `git status` often too (in /etc dir). If you really want to go gung ho managing lots of systems configurations, you could check out puppet (I've never used it, but looks good): http://projects.reductivelabs.com/projects/puppet Thanks, -Jeff http://wiki.maemo.org/User:Jebba ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: oFono
On Thursday 07 January 2010 10:04:56 Aki Niemi wrote: to, 2010-01-07 kello 13:48 +0100, ext Jeff Moe kirjoitti: You should use the isimodem driver in oFono. It is specifically made to support Nokia modems, such as the one on N900. I've been told, and tried my self, and it doesn't work on the N900. It _should_ work out of the box on the N900. In fact, I did some quick packaging of the 0.15 release and just pushed ofono in Fremantle extras-devel. So let's see... Excellent! I can't wait to try it out. I was trying latest git (e.g. 0.15+). There is some jumping through hoops required to get Phonet over USB working that would allow you to use oFono on the desktop with N900 or any other (recent) Nokia phone connected via USB in PC suite mode. I've been meaning to write a howto for that, and I guess it's high time I actually go and do that. ;) Well, that kind of sounds like what my quick dirty mini-howto is about: http://wiki.maemo.org/User:Jebba/Ofono That said, you know far more about it! Do you have a sample modem.conf for N900? And other clues would be appreciated! There's no need for modem.conf on the N900; in fact, my ofono package builds with atmodem and udev disabled. The isimodem driver automagically detects modems via netlink. Nice. :) Thanks for all the info, -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Auto builder failure (was [fremantle]: kmplayer 0.10.2-4 FAILED)
On Friday 08 January 2010 08:05:59 Cornelius Hald wrote: koos vriezen wrote: I think this isn't my fault, no? No, it´s not your fault. Unfortunately I have no idea when it will work again. I guess you just have to try again later... Outages get reported here: https://bugs.maemo.org/show_bug.cgi?id=5818 Good luck, -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Auto builder failure (was [fremantle]: kmplayer 0.10.2-4 FAILED)
On Friday 08 January 2010 10:54:36 koos vriezen wrote: FWIW, I think using a BR for all outrages is not the right way, a product in bugzilla might be. This list is another one (normally I just ask Niels, but this time I though a heads-up for all developers was appropriate). Maemo needs something like this: https://fedoraproject.org/wiki/Outage_Infrastructure_SOP https://fedoraproject.org/wiki/Category:Infrastructure_SOPs Perhaps they are just moving the builder *today*. Perhaps not. Maybe it's a planned outage, maybe it's not. Maybe they are aware of the outage, maybe they're not. It may be fixed in 5 minutes after a daemon restart, or it may be a day or two. Patience is what we need! -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: oFono
On Friday 08 January 2010 04:34:09 Aki Niemi wrote: to, 2010-01-07 kello 14:04 +0100, Niemi Aki (Nokia-D/Helsinki) kirjoitti: to, 2010-01-07 kello 13:48 +0100, ext Jeff Moe kirjoitti: You should use the isimodem driver in oFono. It is specifically made to support Nokia modems, such as the one on N900. I've been told, and tried my self, and it doesn't work on the N900. It _should_ work out of the box on the N900. In fact, I did some quick packaging of the 0.15 release and just pushed ofono in Fremantle extras-devel. So let's see... Right, ofono is now in extras-devel, and based on some quick testing, it seems to work fine. WORKSFORME ! :) Quick dirty: sudo gainroot apt-get install ofono /etc/init.d/ofono start exit (so you're not root) # Check see wtf is up: dbus-send --system --print-reply --dest=org.ofono /isimodem0 org.ofono.Modem.GetProperties # Make call: dbus-send --print-reply --system --dest=org.ofono /isimodem0 org.ofono.VoiceCallManager.Dial string:5551212 string: I have updated my wiki page: http://wiki.maemo.org/User:Jebba/Ofono Thanks! This is fantastico. -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Unified map tile storage
On Friday 08 January 2010 17:01:10 Till Harbaum / Lists wrote: Hi, maep 1.1 is currently in the autobuilder and is supposed to store tiles where you suggested. It is supposed to ask the user whether he wants to move the existing cache etc ... Please give it a try and check that you can live with the result. WORKSFORME. The tile maps appear to have moved. I just did a quick test of disconnecting net and then looking at previous places and they were there and also switching from Hybrid to Google maps, etc. I didn't dig deeper, but it appears to have worked. Thanks for Maep, it's my favorite mapping program. :) -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: oFono
On Thursday 07 January 2010 04:09:46 you wrote: ke, 2010-01-06 kello 15:26 +0100, ext Jeff Moe kirjoitti: On Wednesday 06 January 2010 08:25:15 you wrote: Hi, I wonder if you really need a laptop for making calls. The program pnatd gives you tty to a modem where you can send AT commands. I'm using it to send USSD codes. Very cool. That looks like it may work, actually, at least for within Maemo. Can you give me a hint as to how to use it though? You should use the isimodem driver in oFono. It is specifically made to support Nokia modems, such as the one on N900. I've been told, and tried my self, and it doesn't work on the N900. That said, you know far more about it! Do you have a sample modem.conf for N900? And other clues would be appreciated! Thanks, -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: oFono
On Wednesday 06 January 2010 08:25:15 you wrote: Hi, I wonder if you really need a laptop for making calls. The program pnatd gives you tty to a modem where you can send AT commands. I'm using it to send USSD codes. Very cool. That looks like it may work, actually, at least for within Maemo. Can you give me a hint as to how to use it though? The only info I can find is this wiki page with a command that doesn't work... ( http://wiki.maemo.org/Fremantle_Unsupported_Bluetooth_profiles ) ...and a discussion thread that ends Seriously.. DAMNIT!! I can find very little about pnatd... ;) No source is available: $ apt-get source phonet-at Reading package lists... Done Building dependency tree... Done E: Unable to find a source package for phonet-at Thanks! -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Where to find sources of gtk+ 2:2.14.7-1maemo15?
On Monday 04 January 2010 11:56:38 tero.k...@nokia.com wrote: For others to know: https://stage.maemo.org/svn/maemo/projects/haf/trunk/gtk+/ https://stage.maemo.org/svn/maemo/projects/haf/tags/gtk+/ And as a pre-warning stage as a svn server will be history as soon as we move the hardware. It was originally designed to be a temporary solution, and it turned into a semi-permanent one. GTK+ is finding a home in most likely gitorious. Could you clarify what is meant here? Does this affect other SVN repos on garage (such as qstardict, as an example)? -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Where to find sources of gtk+ 2:2.14.7-1maemo15?
On Wednesday 06 January 2010 15:36:36 Jeff Moe wrote: On Monday 04 January 2010 11:56:38 tero.k...@nokia.com wrote: For others to know: https://stage.maemo.org/svn/maemo/projects/haf/trunk/gtk+/ https://stage.maemo.org/svn/maemo/projects/haf/tags/gtk+/ And as a pre-warning stage as a svn server will be history as soon as we move the hardware. It was originally designed to be a temporary solution, and it turned into a semi-permanent one. GTK+ is finding a home in most likely gitorious. Could you clarify what is meant here? Does this affect other SVN repos on garage (such as qstardict, as an example)? One second after sending this I saw on from feri IRC that stage svn != garage svn so presumably qstardict, etc. are fine. -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Mirrors
On Tuesday 05 January 2010 04:08:19 tero.k...@nokia.com wrote: Thank you, I hope a local mirror helps in your case. apt-get update in 2 seconds. You are aware that we are using Akamai (fully distributed content delivery) for the caching? And that the hit and transfer amounts are way out of the league for anything we could set up ourselves? Yes, but that still doesn't preclude using mirrors. Akamai goes down too. As for Akamail problems, would you don't mind privately e-mailing your rough location on the planet, I can try to find out why Akamai seems to be breaking a lot for you? Sent via private mail (I had previously noted it here https://bugs.maemo.org/show_bug.cgi?id=5818#c18 and https://bugs.maemo.org/show_bug.cgi?id=5818#c24 ). I also offered ssh access on the server box. On another note: Apple Hits 3 Billion Apps Served Milestone http://www.pcworld.com/article/185877/apple_hits_3_billion_apps_served_milestone.html/ (Since July 10, 2008). Nokia lost Q4 2009 due to brokenness. Hopefully they won't lose Q1 2010 too. -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
maemo-optify-deb lib symlink problem
I built a simple package that is a plugin for pidgin called pidgin-otr. When I maemo-optify-deb it, it creates a symlink to itself. * I did the standard easy optification: echo auto debian/optify * The package built/installed fine in scratchbox: [sbox-FREMANTLE_ARMEL: ~] ls -l /usr/lib/pidgin/pidgin-otr.so -rw-r--r-- 1 jebba jebba 81072 Jan 5 14:09 /usr/lib/pidgin/pidgin-otr.so * I removed package. * I then optified: [sbox-FREMANTLE_ARMEL: ~] maemo-optify-deb pidgin-otr_3.2.0-7_armel.deb pidgin-otr: optified 10 entries, saving about 185 kB. dpkg-deb: building package `pidgin-otr' in `pidgin-otr_3.2.0-7_armel.deb'. * I then installed optified package. [sbox-FREMANTLE_ARMEL: ~] ls -l /usr/lib/pidgin/pidgin-otr.so lrwxrwxrwx 1 jebba jebba 39 Jan 5 14:55 /usr/lib/pidgin/pidgin-otr.so - /opt/maemo/usr/lib/pidgin/pidgin-otr.so But here is where the problem came in: [sbox-FREMANTLE_ARMEL: ~] ls -l /opt/maemo/usr/lib/pidgin/pidgin-otr.so lrwxrwxrwx 1 jebba jebba 39 Jan 5 14:55 /opt/maemo/usr/lib/pidgin/pidgin-otr.so - /opt/maemo/usr/lib/pidgin/pidgin-otr.so The optified file is symlinking to itself, thus breaking the package. I'll leave this directory here for awhile if someone wants to check it out. It is my live scratchbox: http://www.freemoe.org/users/jebba/scratchbox/pidgin-otr-OPTIFY_PROB/ The two different .debs for comparison are here: pidgin-otr_3.2.0-7_armel.deb-NOOPTIFY pidgin-otr_3.2.0-7_armel.deb-OPTIFY I made minimal changes to the upstream Sid package. I'm probably doing something dumb, but this has worked easily for other packages. Thanks, -Jeff http://wiki.maemo.org/User:Jebba ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
oFono
I've written up some quick and dirty docs on using ofono with your N900: http://wiki.maemo.org/User:Jebba/Ofono It works, but you'll need to carry around a laptop with you if you want to make calls. -Jeff P.S. Reposted from talk.m.o since many of you probably don't check forums. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Continued outages and lame updates
On Monday 04 January 2010 15:36:17 Valerio Valerio wrote: Hi, this email was sent to the council private list, but since there's nothing private here, and the email has some valuable points/suggestions, I'm replying here in the public mailing list. I did some censorship in the email in order to avoid flame wars, since there's some rants including names, if the author wants he can paste these parts here, IMO these parts are not valuable to the discussion, so should be avoided :). Well, if you send it here, I prefer you send the whole thing instead of saying I was ranting, flaming and including names. You probably shouldn't have sent it here without asking me first either :( It's not like I'm hard to get ahold of. I mentioned GAN900 and no one else. Since it's now public, what I was referring to is logged here: http://mg.pov.lt/maemo-bugs-irclog/%23maemo-bugs.2010-01-03.log.html http://mg.pov.lt/maemo-irclog/%23maemo.2010-01-03.log.html Here is the email in it's entirety: From: Jeff Moe m...@blagblagblag.org To: coun...@maemo.org Subj: Continued outages and lame updates I don't need to tell you that the *.maemo.org infrastructure is very broken. Surely you have experienced frequent outages yourselves. I haven't experienced such poor service from any other distro that I can remember, big or small. I am writing to ask that some sort of Standard Operating Procedure be developed for handling outages and server updates. I have brought up some of these points on the maemo-devel mailing list ( http://lists.maemo.org/pipermail/maemo-developers/2010-January/023329.html ): == I think we should look to Fedora since they have a similar arrangement: community distribution with corporate overlord. This is how they do it: * IRC channel of admin issues: #fedora-admin and #fedora-noc where you can watch things live. * Standard Operating Procedure for outages: https://fedoraproject.org/wiki/Outage_Infrastructure_SOP * PAGER access, available to the public, where you can page one of 9 admins (a bit unbelievable, actually): https://admin.fedoraproject.org/pager * More people would know how the whole *.maemo.org infrastructure actually worked if information about it was public. The joke is that it runs on a N700. But people can make this joke because the actual server set up is known by only a few. Compare that to this dream: https://fedoraproject.org/wiki/Category:Infrastructure_SOPs Anyway, they are doing things far better and I don't see people griping about outages over there much at all. What's the procedure for Maemo? Dive into #maemo-devel and hope someone knows WTF is up? Their answer is usually wait for x-fade. Post to talk.m.o.? Hit reload on qaiku? Post a comment there? Add more here? https://bugs.maemo.org/show_bug.cgi?id=5818 Surprisingly I was told by an @nokian that reporting to that bug was the correct place to report outages (!). Anyway, there are organizations all around the world that run servers 24/7/365 with minimal outages that have more than 2 admins with access. That is obvious. The maemo infrastructure is no where near approaching 99% uptime (let alone .999s). A mere 40 submitted builds is also a loss of time and momentum of many developers... == After further discussion (not in the thread) with Nigel Jone's from Fedora, there are 18 people that can fix Fedora buildserver issues. They use git and puppet to track configuration changes. None of this is majick or unique. These are standard system administration practices which should be followed by Maemo. Also, I have suggested using mirrors of content, which is what every other distro that I know of, big or small, community or corporate does. For instance see: http://www.debian.org/mirror/list http://www.novell.com/products/opensuse/downloads/ftp/int_mirrors.html http://mirrors.fedoraproject.org/publiclist http://api.mandriva.com/mirrors/list.php http://www.ubuntu.com/getubuntu/downloadmirrors http://www.gentoo.org/main/en/mirrors2.xml Even tiny distros like puppy linux have mirrors: http://www.puppylinux.com/download/ Here is a thread I started on maemo-devel about mirrors: http://lists.maemo.org/pipermail/maemo-developers/2010-January/023363.html I think the sysadmins should provide more info about what they are doing, what is planned, when the outages are coming, etc. This is in line with common practices. For instance, they could: * Send emails to maemo-devel (or whatever list), advising of forthcoming outages. * Send updates when they are aware of an outage (e.g. the builder is known down, we're working on it) * Send updates when work has been complete (the new garage server is up) Right now there are occasional tweets to qaiku, but this falls far short. If you need examples of this done correctly, let me
Re: Mirrors
On Monday 04 January 2010 01:42:15 Jeff Moe wrote: On Sunday 03 January 2010 15:28:04 Jeremiah Foster wrote: I think you'll find it non-trivial Nope, trivial. ;) Done. I wrote up docs on how I set up the server and details about it's configuration here: http://wiki.maemo.org/User:Jebba/Espejo I don't think it's critical by any means that this info be in the wiki in this case, but I put it up there more as an example of what could be done with all the servers in the infrastructure so more people can learn about how things are set up. (Cf. Debian, wikipedia, fedora, etc.). -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Continued outages and lame updates
On Monday 04 January 2010 15:36:17 Valerio Valerio wrote: Hi, this email was sent to the council private list, but since there's nothing private here, and the email has some valuable points/suggestions, I'm replying here in the public mailing list. I did some censorship in the email in order to avoid flame wars, since there's some rants including names, if the author wants he can paste these parts here, IMO these parts are not valuable to the discussion, so should be avoided :). So the entirety of rants including names that had to be censored is one part of one sentence. I bit of a mischaracterization of my message, I must say. Here is the entirety of what was removed: (including from a former Community Council member, generalantilles [GAN900], who even threatened to boot me from IRC!). --- jeff-orig.txt 2010-01-04 18:41:43.117226296 -0300 +++ valerio.txt 2010-01-04 18:39:38.458506712 -0300 @@ -87,9 +87,7 @@ you need examples of this done correctly, let me know and I'll send you some. STFU and just sit and wait is not a good answer, but I've been hearing that -for a month now -(including from a former Community Council member, -generalantilles [GAN900], who even threatened to boot me from IRC!). +for a month now. I have wasted much of the last month just waiting for things to work correctly. These failures are killing the momentum, initiative, and goodwill of your developer ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Continued outages and lame updates
On Monday 04 January 2010 19:40:59 Qole wrote: Jeff, I want to say that you have been very helpful to me and others in the maemo.org community. Thank you very much. np But your style can come across as being somewhat aggressive, and can sometimes obscure your message. I too frequently suffer from this problem. I find that thinking of the recipients and subjects of my posts as friends and peers can really help. Would I use the same tone when talking to my friend about another friend? You should see what it's like down here! hah. ;) -Jeff Buenos Aires, Argentina ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Mirrors
On Sunday 03 January 2010 11:45:17 Jeremiah Foster wrote: On Jan 3, 2010, at 12:22, David Greaves wrote: Jeff Moe wrote: As far as I can tell, there are no mirrors of the repositories. Pretty sure Nokia/maemo.org went with a CDN which satisfies all the points you raised. The maemo.org infrastructure problems are more to do with dynamic content and build services and are being addressed AFAIUI. David is right on both counts. Most free software projects do have mirrors but we are lucky in having Nokia as a partner in Maemo because they have taken on the significant cost of pushing maemo.org content to mirrors. In this case the mirrors are a top notch Content Delivery Network. * That doesn't make us lucky. The repositories are frequently down. If there were mirrors we could just point at the mirrors. They were down yesterday, for instance. * Why not complement this top notch service with mirrors and get the best of both? * I'm not talking dynamic content here. I'm talking a simple http repo. I understand that mirroring dynamic sites like talk, the wiki, bugzilla, etc. are harder to mirror. * Every other single distro of note, whether community, corporate, or a mix has a mirror. Can you point me to one that doesn't? What makes Nokia's way so much better? Again, it would be much more convincing if it actually *worked* reliably. What's the downside to having mirrored content? Garage is being replaced, you can see lots of information about that progress on Maemork: http://www.qaiku.com/channels/show/maemork/ Lots of infomation? Like an occasional tweet? I have been following that. Garage has been a victim of its success and of the significant growth that maemo has seen. Many people are working hard to make sure that garage will continue to work smoothly for the whole community. I personally am working towards that goal and I know that teams inside and outside Nokia are working towards that too. Yes, garage is slow and that is a bit understandable. Even that could be mirrored I'm guessing since sourceforge has lots of mirrors when you go to download and garage is running sf-esque code. But I wasn't talking about garage in particular, I was talking about the repository. Surely the repository functioning isn't dependent on garage code. If so, garage should sync that over to another box which can be sync'd publicly. Again, what's the downside to following the tried and true practices of every gnulinux distro of the last decade+? -Jeff P.S. Tangentally: change your /etc/resolv.conf nameservers and you get a different download server. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Mirrors
On Sunday 03 January 2010 17:57:08 Jeremiah Foster wrote: On Jan 3, 2010, at 20:13, Jeff Moe wrote: I have created http://wiki.maemo.org/Mirrors to see if anyone else has issues and to try and have a central place for mirror issues. Ok good. Done. Copying over at the moment to my server at netdepot.org. Wrote up mini- HOWTO: http://wiki.maemo.org/User:Jebba/Mirror Can you use reprepro to mirror the repos? It is far and away the best tool to do that sort of thing (it used to be called 'mirrorer') and is a debian native project. Good documentation plus very responsive upstream. Sure. I've never used it before and I just saw mention of apt-mirror on IRC, so I used that. I'll check out reprepro as apt-mirror felt a little crufty anyway. Can you give me a log in to your machine? Then we can do some testing and expose reprepro and the repos to other testers as well. Currently the reprepro installation I did on stage.maemo.org is not publicly visible. Ok. Right now it's on a box I don't give you access to, but I'll plonk it all within a nice KVM to keep things clean. Mail me your ssh pubkey and i'll set it up. It wasn't my intention to provide some big mirror for people to use myself, I was just suggesting the project have mirrors. There already is plenty of existing mirror infrastructure you can tap into, such as mirrors.kernel.org and ibiblio. Check out some of the mirrors used by other distros--there's a number of well known ones that will begin mirroring if you email them. Typically they use rsync from what I've seen, but if reprepro is becoming common, perhaps they are using that more often now too. It really is that simple with many of them--email contents: Plz mirror me. rsync://rsync.maemo.org/pub Thx. That said, I'll still set it up and you can kick it around. :) You want Debian Lenny? I think you'll find it non-trivial and your time will be better spent helping the new infrastructure and pointing out where Akamai fails to deliver so we can fix it. What can I do to help out with the new infrastructure? I think there is a lot one can do. I would love to organize a team to manage the repos. Teams are used in debian for nearly every task and it spreads the responsibility and points of contact. I would love it if we could collaborate on a SOP for the repos. Hopefully the repos will be free of any secret software that requires an NDA to work on (part of the problem with a half closed, half open project). In any case, a SOP would be a great start. Would you be interested in working on a repo team? Not really, I just want them to work, heh. ;) But if you need folks I can pitch in. I won't NDA though. Thanks! -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Mirrors
On Sunday 03 January 2010 22:11:47 you wrote: On Jan 4, 2010, at 24:28, Jeff Moe wrote: It wasn't my intention to provide some big mirror for people to use myself, I was just suggesting the project have mirrors. Oh, I misunderstood. I thought you were offering to mirror the repos publicly. You just want your own local mirror. That makes sense, and can make life a lot easier. I still recommend reprepro, it is a fantastic tool. Hahha. Well, it's all set up either way: http://espejo.freemoe.org/ I'm syncing over content (locally) right now. I installed reprepro etc. Feel free to mail me your ssh pubkey. -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Mirrors
On Sunday 03 January 2010 22:16:12 Jeff Moe wrote: On Sunday 03 January 2010 22:11:47 you wrote: On Jan 4, 2010, at 24:28, Jeff Moe wrote: It wasn't my intention to provide some big mirror for people to use myself, I was just suggesting the project have mirrors. Oh, I misunderstood. I thought you were offering to mirror the repos publicly. You just want your own local mirror. That makes sense, and can make life a lot easier. I still recommend reprepro, it is a fantastic tool. Hahha. Well, it's all set up either way: http://espejo.freemoe.org/ I'm syncing over content (locally) right now. I installed reprepro etc. Feel free to mail me your ssh pubkey. Ok, jeremiah sent over his key and has logged in fine + sudo so that's up and running. I sync'd over free fremantle extras, extras-testing, and extras-devel for ARM, i386, and source. I set up http/ftp/rsync access: http://espejo.freemoe.org/ ftp://espejo.freemoe.org/ rsync://espejo.freemoe.org/ I'll grab some reprepro configs from jeremiah or he can install them himself if he so desires. -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Mirrors
On Sunday 03 January 2010 15:28:04 Jeremiah Foster wrote: I think you'll find it non-trivial Nope, trivial. ;) Done. -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
On Saturday 02 January 2010 16:33:56 Till Harbaum / Lists wrote: Hi, it seems that some of the extras-testing testers are not really doing a good job. Thus it seems to happen every now and then that some app gets a thumbs down for things it shouldn't be getting a thumbs down for or where such a verdict is at least questionable. My proposal is simple: Let's setup some mailing list which only real developers are allowed to join (may just be everybody with a working app in any of the repositories). And once someone thinks to be the victim of a karma-whore he may ask for help on that list. If we have at least 10 people on such a list we can easily override any such thumb down. In such a case the developer would explain why he thinks the thumb down is not justified and if enough list members agree and help out the problem will be fixed. Does garage allow for invitation-only mailing lists? What do you think? I really think it's wrong that testers can stop bad developers, but that there's no way for developers to stop bad testers. Closed lists are bad and only cause trouble and bad feelings. How about just bringing up particular cases to this list where you think there was an inappropriate thumbs down and it can be sorted here? It's not happening that often, is it? Any examples? -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
On Saturday 02 January 2010 16:33:56 Till Harbaum / Lists wrote: Hi, it seems that some of the extras-testing testers are not really doing a good job. Thus it seems to happen every now and then that some app gets a thumbs down for things it shouldn't be getting a thumbs down for or where such a verdict is at least questionable. My proposal is simple: Let's setup some mailing list which only real developers are allowed to join (may just be everybody with a working app in any of the repositories). And once someone thinks to be the victim of a karma-whore he may ask for help on that list. If we have at least 10 people on such a list we can easily override any such thumb down. In such a case the developer would explain why he thinks the thumb down is not justified and if enough list members agree and help out the problem will be fixed. Does garage allow for invitation-only mailing lists? What do you think? I really think it's wrong that testers can stop bad developers, but that there's no way for developers to stop bad testers. Does this, perchance, have anything to do with what you are talking about? http://maemo.org/packages/package_instance/view/fremantle_extras- testing_free_armel/osm2go/0.8.1-maemo1 I must say he annoyed me to at first, but make my silly package better for in in the end. Seems if you just freaking optified your binary all these threads could die. -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
On Saturday 02 January 2010 17:54:46 Andrew Flegg wrote: For the record, you don't even need to do that now. All you need to do is opt-in to the autobuilder doing optification for you, by putting the single word 'auto' in a new file: debian/optify. At some point the default will change from 'none' to 'auto', and then you can opt-out by putting the single word 'none' in debian/optify. I hope that day comes soon with optify is the default... Can it be today? What is needed to make that change? Then people will have to explain why they are opting out of optifying instead of coming up with excuses of why they won't optify. -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
On Saturday 02 January 2010 17:23:24 Till Harbaum / Lists wrote: Hi, Am Samstag 02 Januar 2010 schrieb Jeff Moe: Does this, perchance, have anything to do with what you are talking about? http://maemo.org/packages/package_instance/view/fremantle_extras- testing_free_armel/osm2go/0.8.1-maemo1 Sure I must say he annoyed me to at first, but make my silly package better for in in the end. Seems if you just freaking optified your binary all these threads could die. Just to make this clear: I WILL do this particular optification. But this will take some time as i am also doing other changes. And any bug i fixed in that version is now delayed. I am annoyed by the fact that my bug fixes are delayed for something the version already in extras also has. Where's the advantage in delaying the update? What's the advantage in delaying the optification? It is soo easy. A whopping 4 bytes or so. It sounds like your app shouldn't have made it to extras in the first place if it wasn't optified. Just optify and let this die finally. -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Mirrors
As far as I can tell, there are no mirrors of the repositories. Most large (and even small!) free software projects have complete mirrors of their archives. There are a good number of reasons: * Faster access to users that are far away on the network from the main repo. * Failover, in case something should happen to the main repository. * Distributes the load, so poor *.maemo.org doesn't get hit so hard. * Distributes the bandwidth (costs) so it doesn't all fall on Maemo's shoulders. Projects with mirrors include the kernel, kde, gnome, Fedora, Debian, etc. Basically every single distribution of note has a mirror--even the tiny ones. All that would need to be done on the *.maemo.org infrastructure side would be to set up an rsync daemon. This is like 3 lines of configuration and can literally be done in minutes by a good admin. Then someone could email a few of the big mirrors such as mirrors.kernel.org and ibiblio and voila! done. Thanks for your consideration, -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder apt-get problems = failing builds
On Friday 01 January 2010 09:03:06 Andrew Flegg wrote: Attempting to upload a new version of vim to the Fremantle auto-builder, I get the following failure: [tons of missing deps] I think it happened because someone uploaded debconf and somehow it got pulled into the mix. I haven't looked deeply into it though. -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder apt-get problems = failing builds
On Friday 01 January 2010 11:12:47 Ed Bartosh wrote: 2010/1/1 Jeremiah Foster jerem...@jeremiahfoster.com: On Jan 1, 2010, at 15:00, Ed Bartosh wrote: 2010/1/1 Andrew Flegg and...@bleb.org: Hi, Attempting to upload a new version of vim to the Fremantle auto-builder, I get the following failure: https://garage.maemo.org/builder/fremantle/vim_7.2-0maemo6/armel.root.l og.FAILED.txt Should be fixed now: https://garage.maemo.org/builder/fremantle/vim_7.2-0maemo6/ Thanks for pointing out to this. Somebody's changed sbdmock configuration on the build host. I don't know why, because it was working just fine before. This reminds me aphorisms like 'Too many cooks spoil the broth' or 'Many commanders sink the ship. I like better Russian one 'Seven babysitters have a child without eye'. Autobuilder reminds me that child sometimes. Funny, I was thinking the exact opposite. If more people had access, then more than one person could fix it. I doubt that. What I can see is that more people can break it. If you need a proof - give everyone root access to that box :) Starting with me. :) Though I must say things seem down an awfully lot and we just sit around waiting for someone to fix it. How does Fedora do it? I imagine they have a number of people with access. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder apt-get problems = failing builds
On Friday 01 January 2010 11:37:24 you wrote: 2010/1/1 Jeff Moe m...@blagblagblag.org: On Friday 01 January 2010 11:12:47 Ed Bartosh wrote: 2010/1/1 Jeremiah Foster jerem...@jeremiahfoster.com: On Jan 1, 2010, at 15:00, Ed Bartosh wrote: 2010/1/1 Andrew Flegg and...@bleb.org: Hi, Attempting to upload a new version of vim to the Fremantle auto-builder, I get the following failure: https://garage.maemo.org/builder/fremantle/vim_7.2-0maemo6/armel.roo t.l og.FAILED.txt Should be fixed now: https://garage.maemo.org/builder/fremantle/vim_7.2-0maemo6/ Thanks for pointing out to this. Somebody's changed sbdmock configuration on the build host. I don't know why, because it was working just fine before. This reminds me aphorisms like 'Too many cooks spoil the broth' or 'Many commanders sink the ship. I like better Russian one 'Seven babysitters have a child without eye'. Autobuilder reminds me that child sometimes. Funny, I was thinking the exact opposite. If more people had access, then more than one person could fix it. I doubt that. What I can see is that more people can break it. If you need a proof - give everyone root access to that box :) Starting with me. :) Though I must say things seem down an awfully lot and we just sit around waiting for someone to fix it. How does Fedora do it? I imagine they have a number of people with access. OK, let's look at this particular case. Autobuilder was broken for about 15 hours. There were about 40 packages uploaded and failed during that time. Before that change builder was working fine. I really doubt that it would be better to have doesns of people to break this than 1-2 to fix. Even if those who can breake it could fix it. Well, you'd have a better case if things worked more reliably. Anyway it was not working for a long time and people became confused. And now I'm restarting all those 40 builds manually. I think we should look to Fedora since they have a similar arrangement: community distribution with corporate overlord. This is how they do it: * IRC channel of admin issues: #fedora-admin and #fedora-noc where you can watch things live. * Standard Operating Procedure for outages: https://fedoraproject.org/wiki/Outage_Infrastructure_SOP * *PAGER* access, available to the public, where you can page one of 9 admins (a bit unbelievable, actually): https://admin.fedoraproject.org/pager * More people would know how the whole *.maemo.org infrastructure actually worked if information about it was public. The joke is that it runs on a N700. But people can make this joke because the actual server set up is known by only a few. Compare that to this dream: https://fedoraproject.org/wiki/Category:Infrastructure_SOPs Anyway, they are doing things far better and I don't see people griping about outages over there much at all. What's the procedure for Maemo? Dive into #maemo-devel and hope someone knows WTF is up? Their answer is usually wait for x-fade. Post to talk.m.o.? Hit reload on qaiku? Post a comment there? Add more here? https://bugs.maemo.org/show_bug.cgi?id=5818 Surprisingly I was told by an @nokian that reporting to that bug *was* the correct place to report outages (!). Anyway, there are organizations all around the world that run servers 24/7/365 with minimal outages that have more than 2 admins with access. That is obvious. The maemo infrastructure is no where near approaching 99% uptime (let alone .999s). A mere 40 submitted builds is also a loss of time and momentum of many developers... -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder apt-get problems = failing builds
On Friday 01 January 2010 12:18:53 Jeremiah Foster wrote: On Jan 1, 2010, at 15:12, Ed Bartosh wrote: 2010/1/1 Jeremiah Foster jerem...@jeremiahfoster.com: On Jan 1, 2010, at 15:00, Ed Bartosh wrote: 2010/1/1 Andrew Flegg and...@bleb.org: now why, because it was working just fine before. This reminds me aphorisms like 'Too many cooks spoil the broth' or 'Many commanders sink the ship. I like better Russian one 'Seven babysitters have a child without eye'. Autobuilder reminds me that child sometimes. Funny, I was thinking the exact opposite. If more people had access, then more than one person could fix it. I doubt that. What I can see is that more people can break it. If you need a proof - give everyone root access to that box :) Seems to work for debian. And Fedora, and... According to Fedora's Nigel Jones, a well-known-fedoraista and admin: G: jebba: I think it stands at about 15 unique people that can cover buildsys issues G: jebba: and that spans US, Europe and Australia/NZ (I am the latter) G: jebba: it is mostly US, but if I'm not around or the ones in Europe (I think it's still only 1 but I'm not 100% sure) then there is people in US that can be paged G: (not all people on the pager can fix buildsys issues) -Jeff http://wiki.maemo.org/User:Jebba ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
On Wednesday 30 December 2009 16:13:19 Till Harbaum / Lists wrote: Am Dienstag 29 Dezember 2009 schrieb Jeff Moe: You should do so, so your users don't brick their phones. It's soo easy to put everything in /opt. I agree the symlinking madness is a bit messy, but it workz and it's what we are stuck with until we have 2G NANDs. In fact i just thought that i can put the binary in opt and reference it directly from the .desktop file without putting a symlink into /usr/bin I'll do that in the next release (although i don't have a clue how you expect my program to brick a phone by not doing so). If it is the package that is the final straw that pushes a user to 100% full filesystem, next time they boot, their system will be bricked. This has happened to *many* users with a variety of packages (I don't know of any cases of it happening with yours, but it can happen with any package that writes to the NAND). There are lots of reports of people bricking due to full NAND on talk.maemo.org, for example. -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
On Tuesday 29 December 2009 11:03:01 Marius Vollmer wrote:
ext Attila Csipa ma...@csipa.in.rs writes:
A broader question is if the 500K as a *number* should be part of the
blocker paragraph. [...]
I think the only sane thing to do is to look at the ratio of files in
/opt to those not in /opt, and require that ratio to be at least the
same as the ratio of the space in /opt to the one in /.
Maemo-optify could be changed to move as many files into /opt as needed
to meet this requirement, starting from the biggest. It's on my todo
list...
I don't understand why maemo-optify doesn't just move *everything* to /opt,
including files under 2k etc. What advantage does it give to not have them in
/opt? For instance, I ran into this problem with asterisk where it had many
small sound files which still put 600k on the NAND.
-} elsif ($size = 2048) {
+} elsif ($size = 0) {
...
In sum, what is the upside of including anything but symlinks on the NAND?
IMHO, it should punt everything to /opt as long as it is needed at all.
Thanks for maemo-optify, it makes things so much lazier^H^H...easier. :)
-Jeff
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
On Tuesday 29 December 2009 13:07:36 Mohammed Hassan wrote: On Tue, 2009-12-29 at 16:57 +0100, ext Tim Teulings wrote: Hallo! In sum, what is the upside of including anything but symlinks on the NAND? IMHO, it should punt everything to /opt as long as it is needed at all. Thanks for maemo-optify, it makes things so much lazier^H^H...easier. :) Symlinks take space on disk, too. I'm not sure if they take a whole block or a part of it but there is likely a limit where a links costs more space than the data itself. Is this where the 2K come from? I didn't check for sure, but I don't think symlinks take anywhere near 2k. Perhaps it's the time to symlink directories ? ;-) ln -s /opt/etc /etc/opt http://www.pathname.com/fhs/pub/fhs-2.3.html#ETCOPTCONFIGURATIONFILESFOROPT But a bit OT. -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
On Tuesday 29 December 2009 16:49:21 Till Harbaum / Lists wrote: Now, on to solving the problem, have you tried putting auto in debian/optify? If so, did both packages continue to work after being auto-optified by the builder (or maemo-build-deb in Scratchbox, if you prefer). Why should i? I think the 500k per package limit is fine and neither of my two packages exceeds it. You should do so, so your users don't brick their phones. It's soo easy to put everything in /opt. I agree the symlinking madness is a bit messy, but it workz and it's what we are stuck with until we have 2G NANDs. Do it for the users, not for some QA list. :) -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: how to hide libs project etc.
On Tuesday 29 December 2009 21:40:34 Kimitake wrote: Hi, I'm planning to release a package that requires some libs and other relating projects, so I will upload them to auto build and extras-devel. But I'm wondering if I can hide some of them from application manager list, because the user needs to select the main project only. Is it possible ? If so, how to set it? In Section: just don't preface them with user/. That will make them invisible to the Hildon Application Manager. You can find valid a Section: here, btw: http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging%2C_Deploying_and_Distributing#Sections -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbdmock sample config
On Wednesday 23 December 2009 06:38:11 you wrote: 2009/12/23 Jeff Moe m...@blagblagblag.org: Can anyone provide me with sample configs for sbdmock and fremantle? Like a file like this? ~/.sbdmock/maemo-fremantle-armel-extras-devel.cfg Please, find it attached. BTW, it would be great if somebody added Fremantle configuration to this wiki: http://wiki.maemo.org/Building_packages_with_sbdmock Great! Thanks. Won't be able to test it til Monday though. I think I'm most of the way there, just having some issues with updating the config. Also, debian lenny doesn't have python-pip so I made a package, if anyone needs it: http://www.freemoe.org/users/jebba/lenny/binary-i386/python- pip_0.6.1-2_all.deb http://www.freemoe.org/users/jebba/lenny/source/python-pip_0.6.1-2/ How is it related to the topic? Per the wiki: http://wiki.maemo.org/Building_packages_with_sbdmock Do: sudo aptitude install git-core python-pip python-setuptools python-virtualenv pip install -E sbdmock minideblib pip install -E sbdmock -e git://github.com/kad/sbdmock.git#egg=sbdmock I tried to find an equivalent, but in the end it wound up faster just rebuilding the package and it worked fine. Thanks, -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbdmock sample config
On Wednesday 23 December 2009 10:51:38 Anderson Lizardo wrote: On Wed, Dec 23, 2009 at 9:38 AM, Jeff Moe m...@blagblagblag.org wrote: Per the wiki: http://wiki.maemo.org/Building_packages_with_sbdmock Do: sudo aptitude install git-core python-pip python-setuptools python-virtualenv pip install -E sbdmock minideblib pip install -E sbdmock -e git://github.com/kad/sbdmock.git#egg=sbdmock I tried to find an equivalent, but in the end it wound up faster just rebuilding the package and it worked fine. According to the pip documentation, it is a replacement for easy_install. Have you tried using easy_install ? (AFAIK it is installed by default on most python installations). I did not try easy_install. I just don't know if easy_install supports installing directly from git repositories, like shown above. I'm not sure either. And I don't understand why you need python-setuptools and python-virtualenv to install sbdmock... For sure I didn't need them to install sbdmock. I was just following the wiki. Perhaps you could update it? I still haven't used sbdmock, so I don't know all that is needed to install so I was just RTFMing... http://wiki.maemo.org/Building_packages_with_sbdmock Thanks for the info! -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Package Building HOWTO
I have written up a Package Building HOWTO. You can find it here: http://wiki.maemo.org/User:Jebba#Package_Building_HOWTO Perhaps some here will find it useful. :) Have fun, -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Package Building HOWTO
On Tuesday 22 December 2009 18:52:13 Joseph Charpak wrote: On Tue, 2009-12-22 at 18:24 -0300, Jeff Moe wrote: I have written up a Package Building HOWTO. You can find it here: http://wiki.maemo.org/User:Jebba#Package_Building_HOWTO Looks good although I'd swap the order of compile for armel with compile for x86. First you compile for x86 and run the resulting app to see if it works in scratchbox. When you're satisfied it does, you compile for armel to make sure it'll compile for the actual device. Testing the armel build in scratchbox for run time errors, is in general not supported (YMMV). Ah good point. Added sub-section and re-arranged things. Thanks, -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Package Building HOWTO
On Tuesday 22 December 2009 19:24:09 Michael Cronenworth wrote: Jeff Moe wrote: I have written up a Package Building HOWTO. You can find it here: http://wiki.maemo.org/User:Jebba#Package_Building_HOWTO Jeff, Would it be beneficial to add or update the necessary pages in the standard wiki namespace instead of adding on to your already long user page? I'm not criticizing your efforts, but it should better organized before your user page is megabytes worth of text. Yes, I do think it would be good to put it in the main namespace, but right now I'm sort of ramping myself up to where everything is and how it is all set up. I didn't want to munge up the main pages yet. ;) Writing this up is a learning experience for me as I go through the process. That said, it's a wiki so feel free to cut paste my page into a new page or augment an existing page. That was done as the base for this page, for example: http://wiki.maemo.org/Phone_control Thanks, -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
sbdmock sample config
Can anyone provide me with sample configs for sbdmock and fremantle? Like a file like this? ~/.sbdmock/maemo-fremantle-armel-extras-devel.cfg I think I'm most of the way there, just having some issues with updating the config. Also, debian lenny doesn't have python-pip so I made a package, if anyone needs it: http://www.freemoe.org/users/jebba/lenny/binary-i386/python- pip_0.6.1-2_all.deb http://www.freemoe.org/users/jebba/lenny/source/python-pip_0.6.1-2/ Any other comments relating to using sbdmock and fremantle would be appreciated. Thanks, -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How remove package from extra-devel free?
On Monday 21 December 2009 07:50:35 Dave Neary wrote: There are a few ways to deal with the source requirement - and if you are merely redistributing binaries made by someone else, you don't need to provide sources, you only need to be able to point someone to the sources. No, you if you are distributing binaries, you need to provide the sources. It doesn't matter where you go them from. This issue came up (on my radar at least), when a number of smallish distros that were just re-rolling Fedora or Debian or whatever had to provide sources. Previously they were just saying get it upstream, but that is not allowed by the GPL. In sum, the binary distributor must distribute sources in all cases. -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify with Chinook / conditionals in debian/rules
On Sunday 20 December 2009 18:09:35 Cornelius Hald wrote: After a lot of trying I found out the the following works: if [ `which maemo-optify` ]; then maemo-optify; fi Perhaps: if [ -x /usr/bin/maemo-optify ]; then maemo-optify; fi Have fun, -Jeff http://wiki.maemo.org/User:Jebba ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify with Chinook / conditionals in debian/rules
On Sunday 20 December 2009 19:38:31 Mikko Vartiainen wrote: Hi, I'm trying to optify Conboy and noticed that maemo-optify does not exist on Chinook. So I've added the build dependency like that: Build-Depends: [...] maemo-optify | maemo-version-dev ( 5.0) Currently it's possible to simply add debian/optify file and put auto there. Builder will optify package for fremantle and ignore the file for other targets. No need for deps or rules changes. I have generally put maemo-optify in the rules file right after dh_builddep as mentioned in the README. It may be true that the builder doesn't need it, but it appears the SDK does (?). Thanks, -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify with Chinook / conditionals in debian/rules
On Sunday 20 December 2009 20:32:45 Mikko Vartiainen wrote: I have generally put maemo-optify in the rules file right after dh_builddep as mentioned in the README. It may be true that the builder doesn't need it, but it appears the SDK does (?). Builder runs maemo-optify-deb which you can run locally too if needed. I think I'll start doing it that way from now to keep in line with builder. As slightly related note, I have a package that was maemo-optifying fine locally for armel/i386, but the builder croaked on maemo-optify of the i386 for some reason: maemo-optify print() on closed filehandle $out at /usr/bin/maemo-optify line 220. print() on closed filehandle $out at /usr/bin/maemo-optify line 183. Bad file descriptor at /usr/bin/maemo-optify line 240. Here's full logs, if it interests you: https://garage.maemo.org/builder/fremantle/portaudio19_19+svn20071022-4/i386.build.log.FAILED.txt But like I said, I will now use maemo-optify-deb and drop maemo-optify from my debian/rules. Thanks, -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
