Re: Builder is creating zero sized packages (Was: Re: Package import into Extras-devel from the builder stucked)
2010/3/25 Henrik Hedberg henrik.hedb...@innologies.fi: Henrik Hedberg wrote: It seems that packages are not imported into Extras-devel after the builder has succeeded with them. Here is an example: I think I found the reason. The builder is creating empty packages. I doubt that. For example, http://maemo.org/packages/package_instance/view/fremantle_extras-devel_free_i386/jammo/0.4.6/ http://maemo.org/packages/package_instance/view/fremantle_extras-devel_free_armel/gltron/0.70final-9maemo9/ http://maemo.org/packages/package_instance/view/fremantle_extras-devel_free_i386/redmond-theme/0.1/ I don't see anything unusual from the builder logs: https://garage.maemo.org/builder/fremantle/jammo_0.4.6/ https://garage.maemo.org/builder/fremantle/gltron_0.70final-9maemo9/ https://garage.maemo.org/builder/fremantle/redmond-theme_0.1/ I am still hoping that it is easy and quick to fix... My guess is that something happened with the NFS share and files were truncated somewhere between builder and repository. Try to rebuild your packages. Most probably builds will succeed. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: External Repository and HAM
2010/3/8 Aldon Hynes aldon.hy...@orient-lodge.com: Graham, (et al.) I appreciate your concern about shared resources, but it seems to me that you are overstating the problem. Not at all. If you look here: http://www.gronmayer.com/it/ you'll find a proof of what people are refering to when they mention the situation we had in the past. You can easily multiply those numbers to 10 and you'll get possible picture for today: tons of broken repos, duplicates, no QA, frustrated users. We used to call it 'repository mess'. Believe me, you don't want hundreds of those repos in HAM configuration on your device. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: diablo autobuilder problem
2010/2/16 ds d...@physik.de: Some minutes ago this worked: https://garage.maemo.org/builder/diablo/vncviewer_0.6.6-fremantle1/armel.build.log.OK.txt checking for intltool = 0.23... 0.35.0 found a little bit later with minor changes (which I even tried to reverse) https://garage.maemo.org/builder/diablo/vncviewer_0.6.6-fremantle5/armel.build.log.FAILED.txt checking for intltool = 0.23... ./configure: line 1: intltool-update: command not found found configure: error: Your intltool is too old. You need intltool 0.23 or later. did not work anymore. Any idea, what happend? Looks very strange that it was built successfully. With current configuration it shouldn't happen, unless somebody just changed it. intltool-update comes from doctools devkit, which is not enabled for Diablo builds. Unfortunately I don't have permissions to change configuration files on the builder box. Niels, can you enable doctools devkit in /etc/sbdmock/maemo-diablo-*.cfg? -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Getting a CC: for cauldon mails (extras-devel)
2010/2/7 Yves-Alexis Perez cor...@debian.org: On 07/02/2010 01:30, Ed Bartosh wrote: 2010/2/7 Yves-Alexis Perez cor...@debian.org: On 06/02/2010 22:11, Ed Bartosh wrote: As far as I remember autobuilder doesn't use 'Maintainer' or any other field to prevent spamming of innocent people from upstream projects. It uses email from /etc/passed instead. Your email should be put in there by admins when they gave you upload rights. My garage account is 'corsac'. The associated mail should be cor...@debian.org or maybe cor...@corsac.net. Unfortunately there is no email specified for your username in /etc/passwd§. And not only for you, but for dozens of other uploaders also. Looks like it's time to go to bugs.maemo.org. Do you want me to do that or do you take care of that? It would be better if you do this. I can ask admins to look at this, but having a bug will help also. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Getting a CC: for cauldon mails (extras-devel)
2010/2/6 Yves-Alexis Perez cor...@debian.org: Hey, I just uploaded my first package to extras-devel, which was rejected (for valid reason), but I had to dig the cauldron list archive to get that mail. I don't really want to subscribe to that list, I'm already subsribed to debian-devel-changes and it's too noisy for apps I'm not interested in :) So it'd be nice to have a CC: when the package is accepted/rejected. In Debian, this is done by checking the signature on the .changes file, but as the upload aren't signed it's not really possible here. But changed-by might be used, or maybe use garage (since we use the garage account and the ssh key associated). What do you think? Could you point me out to your build or just tell me your uploader username? As far as I remember autobuilder doesn't use 'Maintainer' or any other field to prevent spamming of innocent people from upstream projects. It uses email from /etc/passed instead. Your email should be put in there by admins when they gave you upload rights. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Getting a CC: for cauldon mails (extras-devel)
2010/2/7 Yves-Alexis Perez cor...@debian.org: On 06/02/2010 22:11, Ed Bartosh wrote: As far as I remember autobuilder doesn't use 'Maintainer' or any other field to prevent spamming of innocent people from upstream projects. It uses email from /etc/passed instead. Your email should be put in there by admins when they gave you upload rights. My garage account is 'corsac'. The associated mail should be cor...@debian.org or maybe cor...@corsac.net. Unfortunately there is no email specified for your username in /etc/passwd§. And not only for you, but for dozens of other uploaders also. Looks like it's time to go to bugs.maemo.org. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Query (Maemo) packages
2010/2/5 ma...@bitblit.net: Is running dpkg inside scratchbox the best way to get a list of all the packages that are installed on a standard device? I want to check to see what packages are part of a standard device. ssh your device ip/hostname dpkg -l :) -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Build Server Configuration
2010/1/27 Jeff Moe m...@blagblagblag.org: 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) Yeah, I've seen this. The reason is the bug in SDK rootstraps. You can find the details in this thread: http://lists.maemo.org/pipermail/maemo-developers/2009-October/021588.html There is one more m-d thread you may be interested in. It's about automatic optification of packages by autobuilder: http://lists.maemo.org/pipermail/maemo-developers/2009-November/021992.html -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Build Server Configuration
2010/1/26 Jeremiah Foster jerem...@jeremiahfoster.com: On Jan 25, 2010, at 22:27, Ed Bartosh wrote: 2010/1/25 Jeremiah Foster jerem...@jeremiahfoster.com: There are other build tools which are better documented and more flexible than sdbmock. Debian has a complete toolchain which is obviously good at building debs and is completely open and well supported. Interesting. Can you point me out to the one, which supports scratchbox? Why do you need scratchbox to build debs? Why not just use the debian toolchain? I know you don't want to learn perl, but hey, it works for debian. Funny. Rebuilding with crosscompilation toolchain is better approach or course, but I doubt that it's easy doable for Maemo packages. It would require changes in big amount of packages. If you're brave enough you can try it. Just let me know and I will stop supporting current solution. Even not considering above you might notice, that Maemo SDK is based on scratchbox. So, second answer is 'Because Maemo SDK and all developers use it'. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Build Server Configuration
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. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Build Server Configuration
2010/1/26 Jeremiah Foster jerem...@jeremiahfoster.com: On Jan 26, 2010, at 9:43 AM, Ove Kaaven wrote: Jeremiah Foster skrev: On Jan 25, 2010, at 22:27, Ed Bartosh wrote: 2010/1/25 Jeremiah Foster jerem...@jeremiahfoster.com: There are other build tools which are better documented and more flexible than sdbmock. Debian has a complete toolchain which is obviously good at building debs and is completely open and well supported. Interesting. Can you point me out to the one, which supports scratchbox? Why do you need scratchbox to build debs? Why not just use the debian toolchain? I know you don't want to learn perl, but hey, it works for debian. The Debian tools are not really designed for cross-compilation, they're meant to run inside the target environment. Yeah, this seems to be the key differentiator between Maemo's build system and Debian's. Still, there was a SoC project last year in which we could have participated to help shape the debian build process to more closely match Maemo's. No one was interested. That target environment also needs a full complement of Debian tools, including compilers. The reason it works for Debian is because they have a LARGE farm of dedicated, donated machines of various architectures: http://db.debian.org/machines.cgi I find it fascinating that a Free Software operating system, without a very formal form of governance, without any assets of its own aside from SIP, run completely by volunteers, has a larger build farm than the world's leading handset manufacturer. You're confusing Maemo and Nokia here. First, you most probably don't know how big farm Nokia uses internally. And, second, because of not using native compilation current Maemo build infrastructure is more than enough for what it does. However nothing prevents nobody to donate maney or computers for extending existing buildfarm. Maemo is free project, isn't it? -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Build Server Configuration
2010/1/26 Jeremiah Foster jerem...@jeremiahfoster.com: What about tools like qemu and dpkg-cross? Can't they be used to build debs without scratchbox? And my goal is not to necessarily get rid of scratchbox, but rather enable alternatives to the current build toolchain. I still don't understand what's so bad with current toolchain and autobuilder? I'm asking not just out of curiosity, but because right now I have some free time and I'm going to spend it to improve autobuilder. My plan I was to implement the following features: - support for multiple packages builds - parallel package builds - improvements for external checks - support for building tags from garage VCS(svn and git) So, if it's not needed and community tends to switch to another build system I'd rather do something more useful. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Build Server Configuration
2010/1/26 Jeremiah Foster jerem...@jeremiahfoster.com: What about tools like qemu and dpkg-cross? Can't they be used to build debs without scratchbox? And my goal is not to necessarily get rid of scratchbox, but rather enable alternatives to the current build toolchain. I still don't understand what's so bad with current toolchain and autobuilder? I'm asking not just out of curiosity, but because right now I have some free time and I'm going to spend it to improve autobuilder. My plan I was to implement the following features: - support for multiple packages builds - parallel package builds - improvements for external checks - support for building tags from garage VCS(svn and git) So, if it's not needed and community tends to switch to another build system I'd rather do something more useful. Personally I think it is highly useful the work you do. Thank you. What I see as the bottleneck is the political aspect, not the technical aspect. Having alternative build environments frees us from having to rely on one autobuilder, one build machine, one process. If we could let in more community resources either through replication or distribution I think we can ease developers lives when the ISP fails to keep the autobuilder up. I realize that we again reach the limit that in order to build, we need proprietary software / tools / blobs so it will be impossible to replicate the current build toolchain, but having an independent, community managed (or assisted) build toolchain would seem to me useful and a worthy goal. I don't see that community should switch to another build system just because Maemo server infrastructure hosted on non-reliable ISP. From my point of veiw these 2 things are not related at all. All build tools are open. If community don't like this ISP and has ability to switch to alternative one it can move all infrastructure there. It has nothing to do with the changing build system. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Build Server Configuration
2010/1/26 Anderson Lizardo anderson.liza...@openbossa.org: On Tue, Jan 26, 2010 at 8:05 AM, Ed Bartosh bart...@gmail.com wrote: - support for building tags from garage VCS(svn and git) Would be nice to also allow fetching code from external VCS hosting services (gitorious for instance). Is that feasible? Maybe using the Vcs-* fields line in Debian?) The reason why I'm planning to implement it only for garage projects is that I can use push method instead of polling. For garage it can be easy done by developing svn/git hooks. For external vcs it's harder. Fetching sources from there is also more time consuming than from garage. I'm not trying to say that it doesn't make sense to implement. Just want to start with easy task :) Let's see how this feature is used among developers first and then decide if we need to go further in this direction or not. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Build Server Configuration
2010/1/25 Jeremiah Foster jerem...@jeremiahfoster.com: There are other build tools which are better documented and more flexible than sdbmock. Debian has a complete toolchain which is obviously good at building debs and is completely open and well supported. Interesting. Can you point me out to the one, which supports scratchbox? -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Build Server Configuration
2010/1/25 Jeff Moe m...@blagblagblag.org: 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? Here you go: #!/usr/bin/python -tt # Scratchbox target name config_opts['sbtarget'] = 'maemo5-i386' # Target settings. Used if invoked with -u flag config_opts['cputransparency-method'] = None # or none config_opts['compiler-name'] = 'cs2007q3-glibc2.5-i486' config_opts['devkits'] = 'perl:debian-lenny:doctools:svn:git' #config_opts['devkits'] = 'perl:debian-etch:doctools:svn:git:apt-https' config_opts['dpkg-buildpackage'] = 'dpkg-buildpackage -rfakeroot -eAutomatic Builder buil...@maemo.org -sa -D' # 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'] # Location of rootstrap # # You can specify local path to file # example 1: archive located in /scratchbox/packages : # config_opts['rootstrap']=maemo-sdk-rootstrap_4.0_i386.tgz # # example 2: archive from original site # config_opts['rootstrap']=http://repository.maemo.org/stable/chinook/i386/maemo-sdk-rootstrap_4.0_i386.tgz; # # example 3: custom location inside scratchbox: # # config_opts['rootstrap']=/home/user/rootstraps/maemo-sdk-rootstrap_4.0_i386.tgz # config_opts['rootstrap']=/scratchbox/packages/maemo-sdk-rootstrap_5.0_i386.tgz #config_opts['rootstrap']=/scratchbox/packages/maemo-sdk-rootstrap_5.0_i386_update1.tgz config_opts['sources.list'] = # Official SDK repositories: #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 # Development Extras repositories: deb http://repository.maemo.org/extras-devel/ fremantle free non-free # Nokia binaries deb file:/scratchbox/packages/maemo-sdk-nokia-binaries_5_update1 fremantle explicit # Following example should be safe for most cases (resolver*.opendns.com) # If not specified, content of host's /etc/resolv.conf used. #config_opts['files']['/etc/resolv.conf'] = #search maemo.org #nameserver 208.67.222.222 #nameserver 208.67.220.220 # # Special hacks to /host_usr/bin # This will automatically add export PATH=/host_usr/bin:$PATH # and redirection of binary from /usr/bin/binname to /host_usr/bin/binname config_opts['host_usr']['gconftool-2'] = #!/bin/sh export SBOX_REDIRECT_IGNORE=/usr/bin/gconftool-2 export GCONF_CONFIG_SOURCE=`/usr/bin/gconftool-2 --get-default-source` /usr/bin/gconftool-2 --config-source $GCONF_CONFIG_SOURCE --direct $@ config_opts['env']['DEB_BUILD_OPTIONS']=parallel=4 config_opts['env']['TMP']=/var/tmp config_opts['env']['TEMP']=/var/tmp config_opts['env']['TMPDIR']=/var/tmp #config_opts['env']['http_proxy']=http://proxy.dmz:3128; How about scripts that process incoming jobs, etc? You can find current production version of buildme (builder for Maemo Extras) here: https://garage.maemo.org/plugins/scmsvn/viewcvs.php/tags/buildme/1.5.1/?root=extras-cauldron -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Build Server Configuration
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. [1] http://lists.maemo.org/pipermail/maemo-developers/2009-December/023162.html -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo extras repository package uploader/maintainer verification?
2010/1/22 Andrew Flegg and...@bleb.org: On Fri, Jan 22, 2010 at 12:59, Simon Pickering s.g.picker...@bath.ac.uk wrote: I'd suggest that the autobuilder checks to see that the uploader's email address is included in one of the *Maintainer fields; but there is the slight problem of what happens when someone is uploading someone else's package (e.g. as a favour when they are away from a build machine)? There's also packages which are maintained by a team but uploaded by an individual. And there are also packages taken from Debian/Ubuntu and uploaded without any change. I don't think we should stop them from coming. It's possible to find real uploader name in autobuilder logs and might be in the /packages web UI as well. Bringing new checks like this to the system wouldn't make entrance barrier lower for newcomers. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDK rootstraps updated
2010/1/18 Graham Cobb g+...@cobb.uk.net: On Monday 18 January 2010 14:08:07 Jeff Moe wrote: Take note, since the service restoration, the Maemo 5 SDK rootstraps have been (silently?) updated with no changes to timestamps: Thanks Jeff for noticing this. Niels or Ed, do you have any idea what has happened here? Unfortunately I'm not aware of any changes. And autobuilder still uses old SDK rootstraps unless Niels or other admins did something. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Promotion to extras
2010/1/11 Valerio Valerio vdv...@gmail.com: Hi, On Mon, Jan 11, 2010 at 8:17 PM, ds d...@physik.de wrote: Hello, some weeks ago I promoted to extras. I could not find any changes. I have Karma 11 in extras testing: Why is there not promotion link now? The packages have to pass 10 days of quarantine[1] in testing before the promotion link appears. According to this: http://maemo.org/packages/view/vncviewer/ latest version of packages was not even promoted to testing. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Autobuilder is broken again
Hi guys, Do you happen to know who switched off armel builds and why? As I can see from yesterday evening autobuilder performs only i386 builds. If i386 packages are uploaded to the extras-devel it would lead to even more confusion among developers, because armel versions are not built, but reuploading would not be possible, because of i386 versions in the repo. I'd propose to switch autobuilder off while you do your work instead of breaking it so often. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
2010/1/3 Andrew Flegg and...@bleb.org: On Sun, Jan 3, 2010 at 15:39, Jeremiah Foster jerem...@jeremiahfoster.com wrote: On Jan 2, 2010, at 21:54, 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. To stay abreast of these changes it would be great if we had a canonical document about this [...] Agreed. Someone needs to take ownership not just of the technical changes (which have been coordinated between Ed Marius so far, AFAICT) but also the communication and education of developers. I am happy to add information there from disparate sources but if there is already a canonical source I'll copy that. I'm not aware of any documentation - nor what Ed Marius' current timescales are. I'll definitely find a time to do whatever is needed. Moreover, I was asking couple of times already if it's time to enable optification by default in autobuilder. I was given an answer that some testing is still needed. I think Marius should know the latest status. PS: Last news about optification for me was a discusstion about python maemo-optify [1] last month. [1] http://lists.maemo.org/pipermail/maemo-developers/2009-December/022782.html -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder apt-get problems = failing builds
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.log.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. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder apt-get problems = failing builds
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.log.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 :) -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder apt-get problems = failing builds
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.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. 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. Anyway it was not working for a long time and people became confused. And now I'm restarting all those 40 builds manually. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder apt-get problems = failing builds
2010/1/1 Ed Bartosh bart...@gmail.com: 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.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. 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. Sorry, I was wrong. It was down for about 24 hours and there were about 50 failed package builds. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
How to switch hardware keyboard language?
Hi, Does anybody know how to get current hw keyboard language and how to switch between them programmatically? Here is what I did so far: 1. I could get list of configured layouts by reading gconf variables /apps/osso/inputmethod/int_kb_layout and /apps/osso/inputmethod/ext_kb_layout 2. setxkbmap -layout layout allowed me to switch keyboard layout to layout. However, it worked quite funny way. For example if I have English and Russian (us and ru layouts) configured and English layout active(I can type English) after running setxkbmap -layout ru sometimes I can type Russian, sometimes I can't! But if I have Russian layout active and run setxkbmap -layout us it always switches layout to English, but I can't switch it back to Russian by pressing Ctrl+Space (or Ctrl+Chr on N810). 3. My attempts to get any info using xkb calls XkbRF_GetNamesProp, XkbGetState didn't help much. Both calls return the same info regardless of which layout is active. 4. I was able to switch layouts using XkbRF_SetNamesProp, but it worked pretty much like setxkbmap. 5. It's also possible to switch layout by setting gconf variable /apps/osso/inputmethod/int_kb_layout, but if I set it to 'us' it also stops switching by Ctrl-Space even if I set /apps/osso/inputmethod/ext_kb_layout to 'ru' After doing above exercises I came to conclusion that I'm going wrong way and setting xkb map isn't a proper way to switch languages on Maemo. After reading sources of several desktop language switchers. I also understood that xkb extension works differently on Maemo. Bugs 2501 and 3407 from Maemo bugzilla made me think that something might be even broken in xkb internals. I gave up when I read this in the bug 2501: The Ctrl+Space on languages other than Russian changes the input language, not the keyboard layout. At that point I was totally confused and decided to write this email. Can anybody help me with this? -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to switch hardware keyboard language?
2009/12/27 Arkadiy Glazov uglobs...@gmail.com: Hi, Look the head of file /usr/share/X11/xkb/symbols/nokia_vndr/rx-51 and see some answers :) I can't see any answers there, only new questions :( Also I wrote package xkblayouts-rx51-ru that set russian phonetic hardware layout. You can look Perl script /usr/bin/xkbcustom after install. I use setxkbmap for determinate and switch keyboard layout As I understood from your code(I'm not good at Perl though) you're just reloading xkb map using setxkbmap utility. What I'm looking for is how to get the current language and how to switch between them. I've looked into setxkbmap sources and tried to use it. It didn't work for me, as I explained in my first email. Answering two simple questions would help a lot: 1. How to determine which language is active at the moment? 2. How to switch between them? This is pretty much all I want to know :) -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Auto builder - Maemo-Optify
2009/12/24 Benoît HERVIER kher...@khertan.net: So now maemo optify is automatically added on extras builder ? It was added lont time ago and discussed in details on this mailing list. Seems to have some problems : https://garage.maemo.org/builder/fremantle/python2.5-py2deb_0.5.3-1/ Definitely. Check your debian/control and remove empty line between XSBC-Bugtracker and XB-Maemo-Icon-26 lines. Get:1 http://repository.maemo.org fremantle/free maemo-optify 0.2 [5664B] /scratchbox/tools/bin/sh: line 1: /usr/sbin/dpkg-preconfigure: No such file or directory Is there a way to unactivate it ? Why? It doesn't do anything unless explicytly asked. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Auto builder - Maemo-Optify
2009/12/24 Andrew Flegg and...@bleb.org: 2009/12/24 Benoît HERVIER kher...@khertan.net: So now maemo optify is automatically added on extras builder ? Is it? Are Ed/Marius around to confirm? Yes it was. Long time ago, as we all agreed, with 'none' as default. Is there a way to unactivate it ? Put none in debian/optify: It's not needed. The problem is not in autobuilder, but in the package. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Auto builder - Maemo-Optify
2009/12/24 Andrew Flegg and...@bleb.org: On Thu, Dec 24, 2009 at 12:22, Ed Bartosh bart...@gmail.com wrote: Bug #7309 is still valid, of course, and can be used as the hook in which the Python-based heuristics for maemo-optify are done. No, it's not valid. I think everyone's seen this message: /usr/sbin/dpkg-preconfigure: No such file or directory and it's not related to the package being installed. Moreover it's not en error. The initial assumptions underlying the report were invalid; however the fact that maemo-optify is not yet aware of pymaemo-optify (AFAIK) IS a bug. Resolve #7309 as invalid and raise another one if you like, but that seems like a bit too much work for work's sake to me. It's just ridiculous to have bug against autobuilder about maemo-optify is not taking care of build dependency to pymaemo-optify considering the fact that at the moment maemo-optify doesn't even try to do anything unless it founds debian/optify file with the line 'auto' inside it. Of course it's invalid and confusing. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Auto builder - Maemo-Optify
2009/12/24 David Greaves da...@dgreaves.com: Ed... 2 questions: 1. are you happy that /usr/sbin/dpkg-preconfigure: No such file or directory is a bug (as you said a couple of emails back)? Yes, I am. 2. what section do you think the bug should be against? Product: Development Platform Component: SDK -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbdmock sample config
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 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? -- BR, Ed maemo-fremantle-armel-extras-devel.cfg Description: Binary data ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbdmock sample config
2009/12/23 Jeff Moe m...@blagblagblag.org: 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. The equivalent in your case is much more easier and safer. What you need is to build sbdmock and minideblib Debian packages and install them. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Issues with autobuilder x86 bison
2009/12/16 Antonio Aloisio antonio.aloi...@gmail.com: Hi, I've some problem building jam into the autobuilder for X86... and I can't understand where is the problem. I'm able to build it for both architectures on my Maemo5 SDK. Most probably you've installed bison in your environment from Fremantle SDK repo. If you remove it you can reproduce the failure. In this case bison from scratchbox (/scratchbox/tools/bin/bision) is used. Bison looks to work fine in ARMEL but it fails with the following error in X86: /scratchbox/tools/bin/bison: I/O error Complete log is here [1]. Any hints? Adding build dependency to bison version from sdk repo 'bison (= 1:1.875d-1osso2)' should help. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Build-Depends for several Maemo versions
2009/12/11 David Greaves da...@dgreaves.com: On Fri, 2009-12-11 at 14:34 +0100, Cornelius Hald wrote: What am I missing? In the general sense: A way to specify per-build-target .dsc files (for pre-calculation of the build-deps setup of the chroot Well, I investigated this issue using sbdmock conboy-unstable_0.6.1.6.dsc -r maemo-diablo-armel-extras-devel -u init --debug It showed everything I needed and did pretty much what you've mentioned. Here is the quote from its output: [2009-12-11 18:31:28] DEBUG: Executing(scratchbox) cd /home/ed/maemo-diablo-armel-extras-devel/work dpkg-source -x conboy-unstable_0.6.1.6.dsc [2009-12-11 18:31:47] DEBUG: Return status: 0 [2009-12-11 18:31:47] DEBUG: Checking build-deps first time [2009-12-11 18:31:47] DEBUG: Checking dependencies ... [2009-12-11 18:31:47] DEBUG: Executing(scratchbox) cd /home/ed/maemo-diablo-armel-extras-devel/work/conboy-unstable-0.6.1.6 dpkg-checkbuilddeps [2009-12-11 18:33:47] DEBUG: Return status: 0 [2009-12-11 18:33:47] DEBUG: Unment build dependencies: intltool libhildon1-dev libosso-dev libgconf2-dev libxml2-dev libjson-glib-dev osso-af-settings libcurl3-dev liboauth-dev libssl-dev tablet-browser-interface-dev mce-dev libpcre3-dev libhildonmime-dev libgda3-dev [2009-12-11 18:33:47] DEBUG: Builddeps: 'intltool libhildon1-dev libosso-dev libgconf2-dev libxml2-dev libjson-glib-dev osso-af-settings libcurl3-dev liboauth-dev libssl-dev tablet-browser-interface-dev mce-dev libpcre3-dev libhildonmime-dev libgda3-dev' [2009-12-11 18:33:47] DEBUG: apt: command fakeroot apt-get -y -q -o APT::Get::AllowUnauthenticated=1 install --no-remove intltool libhildon1-dev libosso-dev libgconf2-dev libxml2-dev libjson-glib-dev osso-af-settings libcurl3-dev liboauth-dev libssl-dev tablet-browser-interface-dev mce-dev libpcre3-dev libhildonmime-dev libgda3-dev /dev/null [2009-12-11 18:33:47] DEBUG: Executing(scratchbox) fakeroot apt-get -y -q -o APT::Get::AllowUnauthenticated=1 install --no-remove intltool libhildon1-dev libosso-dev libgconf2-dev libxml2-dev libjson-glib-dev osso-af-settings libcurl3-dev liboauth-dev libssl-dev tablet-browser-interface-dev mce-dev libpcre3-dev libhildonmime-dev libgda3-dev /dev/null After it finished I was able to run scratchbox, go to the directory with unpacked source package and investigate this further. BTW, the reason for the issue was using wrong syntax for versioning dependencies in the control file. Instead of using ( 4.1) Cornelius was using ( 4.1). -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
2009/11/9 Marius Vollmer marius.voll...@nokia.com: When autobuilder expected to start to optify packages without debian/optify in them? I don't know. We certainly need to tune the heuristic of maemo-optify first to handle Python. As far as I see Python is optified now. When we should do next step? -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
2009/12/2 Anderson Lizardo anderson.liza...@openbossa.org: On Wed, Dec 2, 2009 at 9:02 AM, Ed Bartosh bart...@gmail.com wrote: 2009/11/9 Marius Vollmer marius.voll...@nokia.com: When autobuilder expected to start to optify packages without debian/optify in them? I don't know. We certainly need to tune the heuristic of maemo-optify first to handle Python. As far as I see Python is optified now. When we should do next step? Correct. But, in Python's case, we didn't add such debian/optify file, and we relied on the fact that the (current) default optify policy was none. If you have plans to begin enabling auto-optification by default, please inform us here on the list so we can begin adding the debian/optify file to avoid optifying packages that were manually optified by other means (e.g. python packages). I hope you'll see everything in this thread. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
2009/11/9 Marius Vollmer marius.voll...@nokia.com: When autobuilder expected to start to optify packages without debian/optify in them? I don't know. We certainly need to tune the heuristic of maemo-optify first to handle Python. Just in case you need my help. I'm here for this week. My 2 weeks vacation starts on Satuday. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
2009/11/6 Marius Vollmer marius.voll...@nokia.com: ext Ed Bartosh bart...@gmail.com writes: I've discussed this with sbdmock author and we decided to make small change to sbdmock: New configurable action will be introduced. This action will be executed by sbdmock between unpacking rootstrap and installing build-deps. For Fremantle we can simply put 'apt-get install maemo-optify' in there. I'll try to make this change on weekends and deploy new sbdmock and devkit in production. Excellent, thanks! Done. Here you can see my test builds: Fremantle builds: without debian/optify: https://garage.maemo.org/builder/fremantle/sbdmock_0.4.4/ 'auto' in debian/optify: https://garage.maemo.org/builder/fremantle/sbdmock_0.4.4.optify/ Diablo build: with 'auto' in debian/optify: https://garage.maemo.org/builder/diablo/sbdmock_0.4.4/ Looking forward to your feedback and further instructions -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
Hi, 2009/11/2 Ed Bartosh bart...@gmail.com: 2009/11/2 Marius Vollmer marius.voll...@nokia.com: [ Jussi, we would like to get a new debian-etch devkit for Maemo 5 with the attached patch. Please advise how to best go about this. ] ext Ed Bartosh bart...@gmail.com writes: I can also help with building devkit if needed. I didn't manage to get the devkit to compile (I didn't see a way to get it to not install into / during build), but I have a patch anyway (attached). You can learn how to do it here: http://scratchbox.org/documentation/docbook/devkit.html Here you can get result of my build(patch attached): https://garage.maemo.org/builder/scratchbox-devkit-debian_1.0.16-1.optify_i386.deb Has anybody tried this devkit? Does it work as expected? Should we deploy it? -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
2009/11/4 Marius Vollmer marius.voll...@nokia.com: ext Ed Bartosh bart...@gmail.com writes: Has anybody tried this devkit? Does it work as expected? I tried it by building (slightly modified versions of) xournal, hermes, and libliqbase, and everything went as expected. Can you elaborate a bit? Is it implemented the way proposed by Andrew? The slight modification was echo auto debian/optify to turn on optification. So, it doesn't do anything by default, right? -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
2009/11/4 Marius Vollmer marius.voll...@nokia.com: ext Ed Bartosh bart...@gmail.com writes: 2009/11/3 Marius Vollmer marius.voll...@nokia.com: Luckily, with apt-get upgrade being run during build, we don't need to change dpkg-checkbuilddeps and we can just update build-essential. (Unless I am missing something. Do I?) rootstrap is used as a build-essentials by sbdmock. The initial idea was to put maemo-optify in there, but now we're trying to avoid that. Hmm, the rootstrap contains the build-essential package. If we put a newer version of the build-essential package into extras-devel, then that newer version will be installed by 'apt-get upgrade'. If apt-get upgrade does indeed run during a build. I no longer think it actually does. Checking the build log of maemo-optify certainly shows no signs of running apt-get upgrade. I'm sorry. This is my faul. I thought you're asking about 'apt-get update'. sbdmock doesn't run 'apt-get upgrade', it just unpacks rootstrap and installs build deps. https://garage.maemo.org/builder/fremantle/maemo-optify_0.1/i386.root.log.OK.txt Hmm, so is apt-get upgrade being executed at one point before calling dpkg-buildpackage? Yes it is. Cool, then that's our ticket to get maemo-optify into the build environment, I would say. The only problem left is were to put 'apt-get install' :) Which apt-get install? We just add a dependency on maemo-optify to build-essential and apt-get upgrade does the rest. No? Sorry, but no. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder repository priority ?
2009/11/3 Graham Cobb g+...@cobb.uk.net: On Monday 02 November 2009 21:52:48 Jeremiah Foster wrote: On Nov 2, 2009, at 10:27, Ed Bartosh wrote: 2009/11/2 Jeremiah Foster jerem...@jeremiahfoster.com: On Nov 1, 2009, at 18:05, Ed Bartosh wrote: Idea of having separate queue for Extras updates sounds more promising to me. Developers might become confused with all this set of repositories, queues and processes, but the idea is good. I support this. What about this? Can we have separate queue for updates? Any other ideas? Can you explain how this might work and it's advantages? I am not against it aside from the fact that I think another repo is confusing. Is the proposal to create a repo called extras-updates which would hold only updates to software that has already existed in the repos? I don't see how that is different from just updating the existing package with new software. If you want to pull in different version numbers than what exists why would you need a separate repo? Sorry, like Jeremiah I am now a bit confused. Can you, Ed, please summarise what this proposal is? You mention separate queue but which queue are you referring to? Does the suggestion involve additional repositories? And/or does it involve differnet rules for which repositories will be in scope during a build? Or what. As I understood Attila he proposed to create separate autobulder incoming queue for Extras updates. If packages are uploaded to this queue they're built using only Extras and SDK repos and put into extras-devel. As a result they won't depend on unstable packages from Extras-devel and can go to extras-testing and then to Extras faster. As I already mentioned I'm also a bit afraid of extra complexity and possible confusion, but I think this idea at least worth to be discussed. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
2009/11/3 Graham Cobb g+...@cobb.uk.net: On Monday 02 November 2009 12:16:57 Ed Bartosh wrote: 2009/11/2 Marius Vollmer marius.voll...@nokia.com: The buildbot would need to run apt-get install maemo-optify at the right time. Any idea of how to do that? Right way to do it is to include it into SDK rootstrap. Other ways I can think of look hackish. Can't we have the hacked dpkg-buildpackage add (if optification is turned on) maemo-optify to the build dependencies? Then it will get installed automatically. We can avoid changing rootstraps if we use this. The idea looks a bit hackish, but I like it anyway. It is essential that it is in a repository (and preferably not the SDK repository -- I would like to see it in extras-devel) so that it can be updated very quickly if we need to fix bugs or change its behaviour. Particularly while Ed is on holiday! It's already there: http://repository.maemo.org/extras-devel/pool/fremantle/free/m/maemo-optify/ -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
2009/11/3 Marius Vollmer marius.voll...@nokia.com: ext Graham Cobb g+...@cobb.uk.net writes: On Monday 02 November 2009 12:16:57 Ed Bartosh wrote: 2009/11/2 Marius Vollmer marius.voll...@nokia.com: The buildbot would need to run apt-get install maemo-optify at the right time. Any idea of how to do that? Right way to do it is to include it into SDK rootstrap. Other ways I can think of look hackish. Can't we have the hacked dpkg-buildpackage add (if optification is turned on) maemo-optify to the build dependencies? No, dpkg-buildpackage does not install build dependencies, it just checks whether they are satisfied. True. I've missed it, my bad. We can hack dpkg-checkbuilddeps to unconditionally add maemo-optify to the list of build dependencies. It will allow to have maemo-optify installed together with other build deps. What the buildbot could do (and maybe does), is to run apt-get upgrade at one point. This is important to get the target into a current state in general. If it does, we could just upload a newer version of build-essential into extras-devel that depends on maemo-optify. This is quite a correct way to go about this, I'd say. The mess results from the SDK repo not being identical to extras-devel (which I would call a bug in itself). To reduce the mess, we should probably first put a version of maemo-optify and the modified build-essential into the sdk repo and make a SDK release. We can then still put newer versions of maemo-optify into extras-devel. So, does the auto-builder run apt-get upgrade? Nope. Sbdmock does it. Sbdmock is a separate tool, which is run from autobuilder. And I really doubt that sbdmock author will accept our hacks. And I really don't like to fork it either. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
2009/11/3 Marius Vollmer marius.voll...@nokia.com: ext Ed Bartosh bart...@gmail.com writes: We can hack dpkg-checkbuilddeps to unconditionally add maemo-optify to the list of build dependencies. Ouch. That's very desperate. May be. But not as desperate as calling apt-get install from dpkg-buildpackage :) What about changing dpkg-buildpackage to run apt-get install maemo-optify if necessary? That concentrates the hacks in one place and is thus less magical. What if developer doesn't have internet connection open during the build? Remember, we're going to put this into devkit, so not only autobuilder will use it. (This wouldn't normally work since dpkg-buildpackage is not run as root, but in Scratchbox, it does.) So, does the auto-builder run apt-get upgrade? Nope. Sbdmock does it. Sbdmock is a separate tool, which is run from autobuilder. Hmm, so is apt-get upgrade being executed at one point before calling dpkg-buildpackage? Yes it is. If so, that's enough; no need to change sbdmock. If not, I think it would be a good idea to do it in general, not just for Maemo. It's not really a hack to keep your build environment up-to-date, or is it? Well, from my point of view all /opt-related changes are hacks, so I don't want to even propose them to general purpose tool. It would be the same as if you would decide to send your patch for dpkg-buildpackage to Debian. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
2009/11/3 Marius Vollmer marius.voll...@nokia.com: ext Ed Bartosh bart...@gmail.com writes: 2009/11/3 Marius Vollmer marius.voll...@nokia.com: ext Ed Bartosh bart...@gmail.com writes: We can hack dpkg-checkbuilddeps to unconditionally add maemo-optify to the list of build dependencies. Ouch. That's very desperate. May be. But not as desperate as calling apt-get install from dpkg-buildpackage :) Yeah, I have to agree, actually. Luckily, with apt-get upgrade being run during build, we don't need to change dpkg-checkbuilddeps and we can just update build-essential. (Unless I am missing something. Do I?) rootstrap is used as a build-essentials by sbdmock. The initial idea was to put maemo-optify in there, but now we're trying to avoid that. Hmm, so is apt-get upgrade being executed at one point before calling dpkg-buildpackage? Yes it is. Cool, then that's our ticket to get maemo-optify into the build environment, I would say. The only problem left is were to put 'apt-get install' :) -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
2009/11/2 Marius Vollmer marius.voll...@nokia.com: ext Ed Bartosh bart...@gmail.com writes: So, I can see this way of implementing this: - give optification scripts to SDK developers and ask them to prepare Debian devkit for Fremantle with patched dpkg-buildpackage as fast as possible. We should prepare a concrete patch against dpkg-buildpackage, of course. I will do that. Please, use dpkg-buildpackage from the current devkit: http://scratchbox.org/download/files/sbox-releases/stable/src/scratchbox-devkit-debian-1.0.10.tar.gz Would maemo-optify be part of that devkit as well, or would it be in the rootstrap? I prefer to leave maemo-optify in the rootstrap: that way, we can update it much easier, which is quite important at this stage. Unfortunately it has to be part of the devkit. Otherwise it will behave differently with different rootstraps and make devkit inconsistent. - test new devkit with local builds and with autobuilder when it's ready. - distirbute devkit among developers and change SDK documentation for Fremantle. - deploy in autobuilder production If someone is willing and able to keep a close eye on the buildbot, then we could deploy the devkit in the buildbot quite early. It might break some builds, but if we are able to react quickly, then it is better to catch those broken builds earlier than later. Ed? Of course I'll take care of this. I can also help with building devkit if needed. What's the best way to make SDK guys to adopt our changes? Bug? -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
2009/11/2 Andrew Flegg and...@bleb.org: Ed wrote: 2009/11/2 Marius Vollmer marius.voll...@nokia.com: Would maemo-optify be part of that devkit as well, or would it be in the rootstrap? I prefer to leave maemo-optify in the rootstrap: that way, we can update it much easier, which is quite important at this stage. Unfortunately it has to be part of the devkit. This is a problem. We need to be able to iterate maemo-optify to change its behaviour and, at some point, be able to switch its default mode from 'none' (to either 'auto' or 'manual'). OK, we can make dependency from dpkb-buildpackage to maemo-optify not so strict. If maemo-optify is present it will be called from dpkg-buildpackage. With this approach we can put maemo-optify into rootstrap. BTW, official rootstrap is also part of the SDK releases, so frankly speaking I don't see much difference between these two options. How quickly will we be able to iterate changes to the devkit? It's just one package, so pretty quickly. How happy will the SDK team be to make these changes? Well, their main goal to support developers, right? I think they will be extremely happy that someone did almost all job for them. However, it's better to ask them directly. It's good oportunity to try to collaborate with them, so we can use it. How will devs get new versions in their SDKs (reinstall devkit?!)? Yes. Depending on these answers, perhaps we should have the maemo-optify package include maemo-buildpackage which is a wrapper around dpkg-buildpackage maemp-optify. In this case it has to be included into rootsrap, which is provided by the same SDK team, so anyway we should work with them somehow. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder repository priority ?
2009/11/2 Jeremiah Foster jerem...@jeremiahfoster.com: On Nov 1, 2009, at 18:05, Ed Bartosh wrote: 2009/11/1 Attila Csipa ma...@csipa.in.rs: On Sunday 01 November 2009 07:46:55 you wrote: So, you propose to have one more queue, which would use only SDK? Or only Extras? or both? Sorry, your proposal is still unclear to me and I doubt it would be clear for other devs. First we need to decide on whether Extras packages can update packages from the SDK/official repos. I don't think any Extras packages should update official SDK repos. It depends on type of packages. SDK contains 2 parts: developer tools libs, which are not installed on the device and libs apps, which are installed on the device. Can't we have a monolithic repo which is _identical_ to the device, plus dev tools? This would allow developers to know in advance which dependencies are on the device and which dependencies they will have to pull in themselves. I don't know. Can we? Idea of having separate queue for Extras updates sounds more promising to me. Developers might become confused with all this set of repositories, queues and processes, but the idea is good. I support this. What about this? Can we have separate queue for updates? Any other ideas? In case of overlapping SDK/Extras I can't think of a satisfactory solution as then fixes for the latter would appear as fixes for the former, which is wrong and dangerous. Another issue would be that you would not be getting SDK updates if you have extras or extras-updates disabled, which is very counterintuitive. True. I also don't see any more or less acceptable solution for this. Having a single repo for each distro would be ideal, with _all_ the software required to run the device in the repo. Then we can co- ordinate the release as a single, monolithic repository. I know this is wishful thinking because not everything is licensed to allow this, but if we could get as much as possible in a single location, then we make life easier for developers. Sounds like a long-term plan. Attila was asking us to solve problem with updates. And he proposed good solution. Shell we implement it right now or you propose to wait until we have Maemo distro and all this great things? -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
2009/11/2 Marius Vollmer marius.voll...@nokia.com: ext Ed Bartosh bart...@gmail.com writes: OK, we can make dependency from dpkb-buildpackage to maemo-optify not so strict. If maemo-optify is present it will be called from dpkg-buildpackage. With this approach we can put maemo-optify into rootstrap. Ok, I'll make it like that, then. BTW, official rootstrap is also part of the SDK releases, so frankly speaking I don't see much difference between these two options. Sorry, rootstrap was the wrong term. Maemo-optify would be in a package that is installed in the buildbot environment. The buildbot would need to run apt-get install maemo-optify at the right time. Any idea of how to do that? Right way to do it is to include it into SDK rootstrap. Other ways I can think of look hackish. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
2009/11/2 Marius Vollmer marius.voll...@nokia.com: ext Ed Bartosh bart...@gmail.com writes: Right way to do it is to include it into SDK rootstrap. Other ways I can think of look hackish. (I think this is a good example of what is wrong with Maemo: normally, we would just upload a patched dpkg and be done with it. Now we have to muck around with devkits and rootstraps... a lot of hassle for no gain if you ask me. But this is not the time to whine... :) Looks like you're trying to say that scratchbox is what's wrong with Maemo :) 100% agree :) -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
2009/11/2 Marius Vollmer marius.voll...@nokia.com: ext Graham Cobb g+...@cobb.uk.net writes: On Thursday 29 October 2009 11:12:45 Marius Vollmer wrote: ext Alberto Mardegan ma...@users.sourceforge.net writes: b) A control file field makes the most sense to control the build process. Agreed. I think dedicated files in debian/ are better, like the debian/package.install files, etc. There is a difference. A debian/optify is fine for controlling how maemo-optify works. A control field is more logical for controlling how the auto-builder works: i.e. should it call maemo-optify at all, should it reject the package because it claims to be optified but there are not files in /opt, etc. I was thinking that the auto-builder would always calls maemo-optify, and maemo-optify would do the rest: decide whether to do anything, check for correct optification, etc. That's the plan so far. autobuilder calls dpkg-buildpackage without checkiing anything, like it already does. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
2009/11/2 Marius Vollmer marius.voll...@nokia.com: [ Jussi, we would like to get a new debian-etch devkit for Maemo 5 with the attached patch. Please advise how to best go about this. ] ext Ed Bartosh bart...@gmail.com writes: I can also help with building devkit if needed. I didn't manage to get the devkit to compile (I didn't see a way to get it to not install into / during build), but I have a patch anyway (attached). You can learn how to do it here: http://scratchbox.org/documentation/docbook/devkit.html Here you can get result of my build(patch attached): https://garage.maemo.org/builder/scratchbox-devkit-debian_1.0.16-1.optify_i386.deb I didn't test it, so don't expect too much :) What's the best way to make SDK guys to adopt our changes? Bug? Jussi Haakala should be our man (in CC). I think we should ask him to build final variant, when everyone will be happy with it. Until that I can build it. -- BR, Ed Mon Nov 2 21:31:37 EET 2009 Ed Bartosh bart...@gmail.com * modified dpkg-buildpackage to run maemo-optify diff -rN -u old-sb-debian-devkit/debian/rules new-sb-debian-devkit/debian/rules --- old-sb-debian-devkit/debian/rules 2009-11-02 21:38:29.0 +0200 +++ new-sb-debian-devkit/debian/rules 2009-11-02 21:38:30.0 +0200 @@ -4,6 +4,7 @@ DEVKIT = $(shell echo $(PACKAGE) | cut -d- -f3-) VERSION = $(shell head -n1 /scratchbox/etc/scratchbox-version) DATE = $(shell head -n2 /scratchbox/etc/scratchbox-version | tail -n1) +VERSION = 1.0.16-1.optify build: diff -rN -u old-sb-debian-devkit/etch_tools/dpkg/Makefile new-sb-debian-devkit/etch_tools/dpkg/Makefile --- old-sb-debian-devkit/etch_tools/dpkg/Makefile 2009-11-02 21:38:29.0 +0200 +++ new-sb-debian-devkit/etch_tools/dpkg/Makefile 2009-11-02 21:38:30.0 +0200 @@ -7,7 +7,8 @@ debian-triplet.patch \ cris.patch \ passwd-check-fix.patch \ - dpkg-uclibc.patch + dpkg-uclibc.patch \ + maemo-optify.patch LIBDEPS = DEPENDS = diff -rN -u old-sb-debian-devkit/etch_tools/dpkg/checksums new-sb-debian-devkit/etch_tools/dpkg/checksums --- old-sb-debian-devkit/etch_tools/dpkg/checksums 2009-11-02 21:38:29.0 +0200 +++ new-sb-debian-devkit/etch_tools/dpkg/checksums 2009-11-02 21:38:30.0 +0200 @@ -5,3 +5,4 @@ d35eba925f322f4591ebc0f6cf292d1d download/dpkg-sbox.patch 84819d216460537ad94df636d340c7f5 download/passwd-check-fix.patch fb6d6636d762fc6a1086807c0378002f download/dpkg-uclibc.patch +3d6bc31986de2ab958d9d78927fbdd67 files/maemo-optify.patch diff -rN -u old-sb-debian-devkit/etch_tools/dpkg/files/maemo-optify.patch new-sb-debian-devkit/etch_tools/dpkg/files/maemo-optify.patch --- old-sb-debian-devkit/etch_tools/dpkg/files/maemo-optify.patch 1970-01-01 02:00:00.0 +0200 +++ new-sb-debian-devkit/etch_tools/dpkg/files/maemo-optify.patch 2009-11-02 21:38:30.0 +0200 @@ -0,0 +1,58 @@ +--- orig/dpkg-1.13.25/scripts/dpkg-buildpackage.sh 2006-06-21 05:35:01.0 +0300 new/dpkg-1.13.25/scripts/dpkg-buildpackage.sh 2009-11-02 18:44:41.0 +0200 +@@ -12,6 +12,7 @@ + echo + Copyright (C) 1996 Ian Jackson. + Copyright (C) 2000 Wichert Akkerman ++Copyright (C) 2009 Nokia Corporation (Marius Vollmer) + This is free software; see the GNU General Public Licence version 2 or + later for copying conditions. There is NO warranty. + } +@@ -45,6 +46,7 @@ + -snforce Debian native source format. } only passed + -s[sAkurKUR] see dpkg-source for explanation.} to dpkg-source + -ncdo not clean source tree (implies -b). ++ -nodo not run maemo-optify-deb. + -tcclean source tree when finished. + -apadd pause before starting signature process. + -W turn certain errors into warnings. } passed to +@@ -77,6 +79,7 @@ + maint='' + desc='' + noclean=false ++nooptify=false + usepause=false + warnable_error=0 + passopts='' +@@ -109,6 +112,7 @@ + -tc) cleansource=true ;; + -t*)targetgnusystem=$value ;; # Order DOES matter! + -nc) noclean=true; if [ -z $binaryonly ]; then binaryonly=-b; fi ;; ++ -no) nooptify=true ;; + -b) binaryonly=-b; [ $sourceonly ] \ + { echo 2 $progname: cannot combine $1 and -S ; exit 2 ; } ;; + -B) binaryonly=-B; checkbuilddep_args=-B; binarytarget=binary-arch; [ $sourceonly ] \ +@@ -127,6 +131,13 @@ + shift + done + ++if [ x$nooptify != xtrue ]; then ++if [ x`type -p maemo-optify-deb` = x ]; then ++echo 2 $progname: maemo-optify-deb not found, not optifying. ++nooptify=true ++fi ++fi ++ + if [ -z $signcommand ] ; then + signsource=: + signchanges=: +@@ -216,6 +227,9 @@ + if [ x$sourceonly = x ]; then + withecho debian/rules build + withecho $rootcommand debian/rules $binarytarget ++if [ x$nooptify != xtrue ]; then ++withecho $rootcommand maemo-optify-deb --auto ++fi + fi + if [ $usepause = true
Re: Autobuilder repository priority ?
2009/11/1 Attila Csipa ma...@csipa.in.rs: Are you sure it works this way? I thought that packages are built with dependencies from unstable in Debian, just like they're built against extras-devel in Maemo. You're right you can't change pinning on the *builder* within the *same* queue, that would make no sense. The problem is that the autobuilder already uses a mix of repositories (as you said later, having packages from extras-* overriding SDK stuff is not right) and that we can't skip the promotion process (i.e. no security.debian.org that is handled differently). If I was unclear as to the goal - I don't want to cross-reference repo contents (bad, bad idea). I want to be able to issue updates to packages that have been already promoted and got to the general public (obviously not typo fixes but stuff that is REALLY important), and for that, we need a queue that has a different repository layout (i.e. no extras-devel overriding extras). So, you propose to have one more queue, which would use only SDK? Or only Extras? or both? Sorry, your proposal is still unclear to me and I doubt it would be clear for other devs. Actually python-dbus is not very good example. It's not only SDK package. I might be wrong but I think it's included into PyMaemo releases and is delivered through Extras. Nokia included it into SDK, but this is a special case. I just ran into this problem personally with python-dbus, hence the mention, but I did say the problem is more generic than that :) I agree that the problem exists. Let's find possible solutions for it. I still think that the one I proposed is the fastest and simplest for now. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder repository priority ?
2009/10/31 Attila Csipa ma...@csipa.in.rs: I have a small issue with the autobuilder. The whole thing started out by having a package that compiled nice in the SDK but not in the autobuilder due to a versioning mismatch (in my case python-dbus, but it's a generic problem as you'll see). After some snooping around, I realized the problem was that the SDK had 0.83.0-1maemo1 in fremantle/tools/free (and that's what got used when compiling in the SDK), however, the autobuilder insists on using 0.83.0-1maemo3 from fremantle/free (-devel). You can try to use python2.5-dbus instead of python-dbus to work around the problem. python2.5-dbus is just a meta package, but it presents only in SDK, which might allow you to avoid installing python-dbus from extras-devel. PS: It's just a workaround, not more than that. We can continue our discussion. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
2009/10/29 Graham Cobb g+...@cobb.uk.net: On Wednesday 28 October 2009 22:50:25 Ed Bartosh wrote: Somehow I don't like the idea of doing anything with the package without developer being aware of this. I'd rather implement check on autobuilder side to insure that packages are optified. Developer can use option XS-Maemo-Optify: none to disable optification if developer doesn't want it. Nobody likes doing something to the package automatically but, after a long discussion at the BOF, we agreed that the alternatives were even worse [1]. In particular, there was a strong argument that the package should not have to include anything (even a control field option) to cause optification to happen. Packages which wanted to do their own optification or which had to disable optification would have to include an option to stop optification. If it makes you happier: rename the autobuilder as autobuilder and optifier! We did agree that there had to be a way for developers to generate packages in the scratchbox environment which had been optified in exactly the same way the autobuilder would. And that we would update the wiki pages about checking packages will build to include using that tool to test the optification. So, the consensus decision was that the solution would be that autobuilder should automatically optify by default. So, what should we do? My proposal is to make dpkg-buildpackage to call maemo-optify. With this we can solve 2 problems - autobuilder will optify packages and developers will have their packages automatically optified for their local builds without using any extra tools. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder repository priority ?
2009/11/1 Attila Csipa ma...@csipa.in.rs: On Sunday 01 November 2009 07:46:55 you wrote: So, you propose to have one more queue, which would use only SDK? Or only Extras? or both? Sorry, your proposal is still unclear to me and I doubt it would be clear for other devs. First we need to decide on whether Extras packages can update packages from the SDK/official repos. It depends on type of packages. SDK contains 2 parts: developer tools libs, which are not installed on the device and libs apps, which are installed on the device. For first group updating through Extras is not good, but possible and most of the time it would work faster than through SDK update process(if it exists at all). Packages from second group can break SSU if they they're considered as a system packages. Actually, application manager doesn't allow to install them, but if installed using dpkg they can break SSU. Another concern here is that SDK and device firmware usually released together, but packages in Extras are not synchronized with those releases until they appear. It practically means that it's better to avoid overlapping SDK/Extras as much as possible. However it's still unclear to me what to do with components taken into SDK from projects similar to PyMaemo with their own release circle and distributing scheme. I'd say no. In that case, go the Debian way and have an sdk-updates and extras-updates queue with a different QA procedure. Maemo isn't Debian. Debian has consistent repository one for everything. Maemo has at least 3 different components(SDK, Extras, device packages) and 2 different operation environments(scratchbox and device). SDK has never been released through Extras, so separate queue for SDK updates should be agreed with SDK team. I doubt they need it. Idea of having separate queue for Extras updates sounds more promising to me. Developers might become confused with all this set of repositories, queues and processes, but the idea is good. I support this. In case of overlapping SDK/Extras I can't think of a satisfactory solution as then fixes for the latter would appear as fixes for the former, which is wrong and dangerous. Another issue would be that you would not be getting SDK updates if you have extras or extras-updates disabled, which is very counterintuitive. True. I also don't see any more or less acceptable solution for this. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
2009/11/1 Graham Cobb g+...@cobb.uk.net: On Sunday 01 November 2009 09:02:34 Ed Bartosh wrote: So, what should we do? My proposal is to make dpkg-buildpackage to call maemo-optify. With this we can solve 2 problems - autobuilder will optify packages and developers will have their packages automatically optified for their local builds without using any extra tools. I am happy to go with your recommendation. I guess there is a small downside that we are forking dpkg-buildpackage but, as you say, the advantage is that developers will not have to do anything locally. So, I can see this way of implementing this: - give optification scripts to SDK developers and ask them to prepare Debian devkit for Fremantle with patched dpkg-buildpackage as fast as possible. - test new devkit with local builds and with autobuilder when it's ready. - distirbute devkit among developers and change SDK documentation for Fremantle. - deploy in autobuilder production Any ideas, objections, clarifications? -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder repository priority ?
2009/10/31 Attila Csipa ma...@csipa.in.rs: I have a small issue with the autobuilder. The whole thing started out by having a package that compiled nice in the SDK but not in the autobuilder due to a versioning mismatch (in my case python-dbus, but it's a generic problem as you'll see). After some snooping around, I realized the problem was that the SDK had 0.83.0-1maemo1 in fremantle/tools/free (and that's what got used when compiling in the SDK), however, the autobuilder insists on using 0.83.0-1maemo3 from fremantle/free (-devel). The problem is IMHO that the repository priorities seem to be wrong. The autobuilder should be using the highest version in the TOP PRIORITY repository that satisfies a dependency to avoid breakage because of unstable stuff in -devel and because otherwise a package can't be promoted without dragging other folks' packages with them. Thoughts ? The reason of this is that apt designed so that it will always install higher possible version of package. It's actually rather good than bad. Imagine what would happen if it would work another way. No new python-dbus ever :) The solution for this is to go to bugs.maemo.org and report your problem to Pymaemo project and wait for a fix. Or, better, to provide patch. You can also discuss this with pymaemo developers on their irc channel or mailing list: http://pymaemo.garage.maemo.org/getinvolved.html -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder repository priority ?
2009/10/31 Attila Csipa ma...@csipa.in.rs: On Saturday 31 October 2009 14:49:24 Ed Bartosh wrote: is IMHO that the repository priorities seem to be wrong. The autobuilder should be using the highest version in the TOP PRIORITY repository that satisfies a dependency to avoid breakage because of unstable stuff in -devel and because otherwise a package can't be promoted without dragging other folks' packages with them. Thoughts ? The reason of this is that apt designed so that it will always install higher possible version of package. It's actually rather good than bad. Imagine what would happen if it would work another way. No new python-dbus ever :) This is not entirely correct (and definitely not recommended in our case of the autobuilder). Apt uses priorities (both repository and package level priorities can be defined, 'pinned') to decide which package to use to satisfy a dependency, and only if the priorities are equal does it base the choice on version number. Why is the current (same-priority, version only) approach bad ? Say, my app depends on python-dbus. I test it with version A, currently in the SDK and it works just fine. I upload and promote my app. All is well. However, later, the pymaemo team uploads a newer, experimental B version into -devel. From that point on I am NO LONGER ABLE to reliably update my application nor promote it (this actually happened to me, my stuff compiles in SDK, but not in the autobuilder for this very reason). True. However there can be another situation: SDK version of python-dbus is buggy and you can't use it with your application. You would have to wait until new fixed version of python-dbus reaches high priority repo to be able to build your application with it. Not so good for application developer, either. I don't want to say that current uproach is the best, just want to show you another side of the problem. But you can specify a fixed version dependency (the one in SDK and extras), you say ? But THEN I get to the problem of no updates. If bugs get squashed in the -devel version of the library I'm using, the user will never be able to upgrade to it, as my package is insisting on the old version (and the package manager wisely rather skips updates than removing already installed packages). Ubuntu and Debian solve this problem by advising different repository priorities. Stable has a highest priority, Testing is lower and Unstable is lowest. If there is a package in Stable that satisfies my requirement, that's the one that should be used. Are you sure it works this way? I thought that packages are built with dependencies from unstable in Debian, just like they're built against extras-devel in Maemo. But then it will never get updated, you say ? Wrong ! Remember what I said up there - if the priority is the same, the version decides. So, the moment a new version of the dependency reaches *Stable*, it will become the highest priority and will get updated. It's a recommendation that dependencies should be REALISTICALLY listed. You should not depend on a high version number just because it's new or even because it's the one bundled on the system (!). You should depend on the minimal version that provides the actual functionality you require. Hope my problem is a bit more clear now. It was clear from your previous mail. Actually python-dbus is not very good example. It's not only SDK package. I might be wrong but I think it's included into PyMaemo releases and is delivered through Extras. Nokia included it into SDK, but this is a special case. SDK packages shouldn't be uploaded to extras-devel at all. There are plans to implement checks on autobuilder side to prevent this. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
2009/10/29 Graham Cobb g+...@cobb.uk.net: On Wednesday 28 October 2009 22:50:25 Ed Bartosh wrote: Somehow I don't like the idea of doing anything with the package without developer being aware of this. I'd rather implement check on autobuilder side to insure that packages are optified. Developer can use option XS-Maemo-Optify: none to disable optification if developer doesn't want it. Nobody likes doing something to the package automatically but, after a long discussion at the BOF, we agreed that the alternatives were even worse [1]. Then let's find the way to do it better. What I'm afraid of is that developers wouldn't like the approach to change packages implicitly. It potentially can create repository mess again. And I really don't want this to happen. In particular, there was a strong argument that the package should not have to include anything (even a control field option) to cause optification to happen. Packages which wanted to do their own optification or which had to disable optification would have to include an option to stop optification. If it makes you happier: rename the autobuilder as autobuilder and optifier! No, it won't make me happier. We did agree that there had to be a way for developers to generate packages in the scratchbox environment which had been optified in exactly the same way the autobuilder would. And that we would update the wiki pages about checking packages will build to include using that tool to test the optification. Would it be better to change the common part of developer environment and autobuilder, for example somewhere in debian devkit? If dpkg-buildpackage will produce optified packages they will be at least the same everywhere. So, the consensus decision was that the solution would be that autobuilder should automatically optify by default. I didn't even think it will go this way. This why I didn't participate on discussions and BOF, sorry. Does it mean that I should shut up and do what I'm told to do? -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
2009/10/29 Andrew Flegg and...@bleb.org: Ed wrote: 2009/10/29 Graham Cobb g+...@cobb.uk.net: Nobody likes doing something to the package automatically but, after a long discussion at the BOF, we agreed that the alternatives were even worse [1]. Then let's find the way to do it better. What I'm afraid of is that developers wouldn't like the approach to change packages implicitly. There were some very senior and well respected developers in the room, who package some of the leading Maemo applications. It potentially can create repository mess again. And I really don't want this to happen. No-one does, however increasing the amount of work developers have to do to get into Extras because of Nokia's short-sightedness is also a demotivating factor which could lead to multiple repositories springing up. True. However I'm not sure that making developers to do additional work is worse than change package imlicitly, which can potentially cause installation and runtime problems. In particular, there was a strong argument that the package should not have to include anything (even a control field option) to cause optification to happen. Packages which wanted to do their own optification or which had to disable optification would have to include an option to stop optification. And this is because /opt is basically a weirdness caused specific to Maemo packaging, and (with the move to Qt) the Maemo development community is increasingly realising the benefits of abstracting platform weirdness. Would it be better to change the common part of developer environment and autobuilder, for example somewhere in debian devkit? If dpkg-buildpackage will produce optified packages they will be at least the same everywhere. Have you an estimate on the comparative costs of developing one vs. the other? This is an implementation detail of make the autobuider do it. Who owns the Debian devkit and do they want to do the work? I'd say changing devkit would take twice more then modifying autobuilder. Not a very big difference, considering that we can have one solution to both problems. With modified devkit we can change both developer and autobuider environments in one shot. Devkit is a part of SDK, so SDK people own it. I can help to modify it if we decide to go this way. A maemo-buildpackage was mentioned in the BOF as a potential way of allowing developers to do what the auto-builder does. How hard would it be to develop this and get the autobuilder to call maemo- rather than dpkg-buildpackage? However, there seem to be two arguments on your side: 1) Don't do anything, developers should modfy debian/rules as they do now. 2) Make something in the build process do it, rather than the autobuilder. I like 1st better. Second is just a bit better alternative to your decision. (2) is an internal implementation detail which isn't important externally: the consensus view could be tested by uploading a Diablo source package with no changes and having it auto-optified. Whether that's through a change to the devkit, autobuilder-specific code or the introduction of maemo-buildpackage is of little interest to the person doing the uploading :-) It is important. Instead of introducing new tool we just change the existing. No additional work for developers in this case. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
2009/10/29 Marius Vollmer marius.voll...@nokia.com: ext Andrew Flegg and...@bleb.org writes: I suggest the header is XS-Maemo-Optify, and has the following values: none: no optification should be done, or considered, by the autobuilder. manual: the application author will do optification manually. If the package contains no entries under /opt it would be considered a build failure. auto: maemo-optify would be run if certain heuristics were met (e.g. no entries in /opt, no Python dependency) force: maemo-optify would always be run Thanks for the initiative, Andrew! I have put maemo-optify 0.2 into extras-devel with the following changes, motivated by your proposal: * Added --auto option to maemo-optify-deb which will read debian/optify and debian/files and does the right thing. * Added maemo-optify-buildpackage, which invokes maemo-optify-deb in auto mode. More details in the README here: http://maemo.gitorious.org/maemo-af/maemo-optify/blobs/master/README Thus, only none and auto are really implemented right now, and the mode is read from debian/optify instead of from debian/control. (Proper man pages are still missing.) Thus, the next step is to make sure that maemo-optify is installed in the build environment and to use maemo-optify-buildpackage instead of dpkg-buildpackage. (Or make the equivalent changes to dpkg-buildpackage itself, which are quite small.) There are two ways to have maemo-optify in build environment - to add it to the rootstrap and to put it into Build-Depends. As I understood we don't want to ask developers to put it into Build-Depends, so rootstrap should be changed. I already hacked it one time when I removed /opt from there. I can do it again, but I don't want to fork SDK rootstrap, so it would be nice to somehow agree with SDK team to include these changes into the next release. I like the idea of making equivalent changes to dpkg-buildpackage. Why we should introduce new tool? -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
2009/10/28 Andrew Flegg and...@bleb.org: Hi, I've put together a suggested spec for the decision, taken at the summit during the /opt BOF[1], that the auto-builder would run some maemo-optify version during the build process (controlled by a control file header): http://talk.maemo.org/showthread.php?p=359996#post359996 I suggest the header is XS-Maemo-Optify, and has the following values: none: no optification should be done, or considered, by the autobuilder. manual: the application author will do optification manually. If the package contains no entries under /opt it would be considered a build failure. auto: maemo-optify would be run if certain heuristics were met (e.g. no entries in /opt, no Python dependency) force: maemo-optify would always be run Marius: are you taking ownership of talking to Ed Bartosh, and anyone else, about this plan? We can discuss it here. Sorry, I seem to miss the whole point of this activity. Why do you need to do that on autobuilder side? As far as I understood it's just a matter of including maemo-optify as a build dependency and run it in debian/rules, right? Why developer can't do this then? I don't see much difference between setting XS-Maemo-Optify and changes I mentioned above. In both cases developer should understand what optification means. BTW, when you want to have it done? I'm going to vacation in a couple of weeks. Before that I was going to finish implementation of multiple packages builds if I have time. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
2009/10/28 Andrew Flegg and...@bleb.org: Ed wrote: I've put together a suggested spec for the decision, taken at the summit during the /opt BOF[1], that the auto-builder would run some maemo-optify version during the build process (controlled by a control file header): Sorry, I seem to miss the whole point of this activity. Why do you need to do that on autobuilder side? As far as I understood it's just a matter of including maemo-optify as a build dependency and run it in debian/rules, right? Why developer can't do this then? I don't see much difference between setting XS-Maemo-Optify and changes I mentioned above. In both cases developer should understand what optification means. The consensus at the BOF was that since it's something which SHOULD be done for all Maemo packages, but that this is Maemo specific, that it should be done at the autobuilder to ensure that as many packages are optified as possible. By having auto be the default (i.e. the developer has NOT specified XS-Maemo-Optify) at some point in the future we can avoid the current problem where, even though the requirements are well understood more than half the user-facing applications in -testing aren't using /opt. Somehow I don't like the idea of doing anything with the package without developer being aware of this. I'd rather implement check on autobuilder side to insure that packages are optified. Developer can use option XS-Maemo-Optify: none to disable optification if developer doesn't want it. Explicit is better than implicit. (C) Zen of Python :) -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
2009/10/29 Graham Cobb g+...@cobb.uk.net: I think we should do the second item before Ed goes on holiday, even if it means deferring the multiple package builds. We can then test it (setting the header to auto in various packages) while Ed is away but there is minimal danger of problems cropping up while he is away. Ed, could we do that? I think we can. I just want to understand why this way. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Error installing optified packages in Fremantle SDK
2009/10/27 Luca Donaggio donag...@gmail.com: Linking /opt against /targets/links/opt did the trick! Now I can install my packages with dpkg, at least - apt-get will still complain about /opt and the base-files package I think. No, it shouldn't complain. At least it doesn't complain in my environment. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Error installing optified packages in Fremantle SDK
2009/10/26 Luca Donaggio donag...@gmail.com: Hi! I've succesfully built a new version of my packages and optified them, but now if I try to install them in the SDK to see if they works as expected before pushing them to extras-testing, all I've got is: dpkg: error processing /var/cache/apt/archives/blablabla.deb (--unpack): trying to overwrite `/opt', which is also in package base-files dpkg-deb: subprocess paste killed by signal (Broken pipe) I've made through all the steps related to /opt in the SDK when I installed the final version as described here [1]: [sbox-FREMANTLE_X86: ~] rm /targets/FREMANTLE_X86/opt [sbox-FREMANTLE_X86: ~] mkdir /targets/FREMANTLE_X86/opt but, still: [sbox-FREMANTLE_X86: ~] v /opt lrwxrwxrwx 1 cthulhu cthulhu 9 Oct 6 16:46 /opt - /home/opt and, of course, /home/opt doesn't exist. Can someone point me to what I'm doing wrong here? Or is there some workaround? Have you tried to install your optified packages after you created /opt directory inside your target? Did dpkg fail with the same output? -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Error installing optified packages in Fremantle SDK
2009/10/26 Luca Donaggio donag...@gmail.com: The output from dpkg is exactly the same. What do you mean by Have you tried to install your optified packages after you created /opt directory inside your target? ? I thought it was failing before you re-created /opt. Probably I misunderstood the situation. I have: [sbox-FREMANTLE_X86: ~] v /targets/links/opt lrwxrwxrwx 1 cthulhu cthulhu 26 Oct 7 15:26 /targets/links/opt - /targets/FREMANTLE_X86/opt and: [sbox-FREMANTLE_X86: ~] v /targets/FREMANTLE_X86 total 76 [...] drwxrwxr-x 2 cthulhu cthulhu 4096 Oct 7 15:04 opt [..] but: [sbox-FREMANTLE_X86: ~] v /opt lrwxrwxrwx 1 cthulhu cthulhu 9 Oct 6 16:46 /opt - /home/opt You can read this thread: http://lists.maemo.org/pipermail//maemo-developers/2009-October/021588.html The error explained there is the same as yours. I resolved it by removing /opt from rootstraps. Here is what I have in my target: [sbox-maemo5-arm: ~] ls -la / | grep opt lrwxrwxrwx 1 root root 18 Oct 22 09:22 opt - /targets/links/opt [sbox-maemo5-arm: ~] ls -la /targets/maemo5-arm/ |grep opt drwxrwxr-x 2 ed ed 4096 Oct 26 16:19 opt And I'm able to install optified packages into this target: [sbox-maemo5-arm: ~] fakeroot apt-get install clucene-core Reading package lists... Done Building dependency tree... Done The following NEW packages will be installed: clucene-core 0 upgraded, 1 newly installed, 0 to remove and 2 not upgraded. Need to get 0B/319kB of archives. After unpacking 1085kB of additional disk space will be used. WARNING: The following packages cannot be authenticated! clucene-core Install these packages without verification [y/N]? y /scratchbox/tools/bin/sh: line 1: /usr/sbin/dpkg-preconfigure: No such file or directory Selecting previously deselected package clucene-core. (Reading database ... 6395 files and directories currently installed.) Unpacking clucene-core (from .../clucene-core_0.9.21b-0maemo1_armel.deb) ... Setting up clucene-core (0.9.21b-0maemo1) ... [sbox-maemo5-arm: ~] dpkg -L clucene-core |grep opt /opt /opt/maemo /opt/maemo/usr /opt/maemo/usr/lib /opt/maemo/usr/lib/libclucene.so.0.0.0 -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Error installing optified packages in Fremantle SDK
2009/10/26 Luca Donaggio donag...@gmail.com: On Mon, Oct 26, 2009 at 4:40 PM, Ed Bartosh bart...@gmail.com wrote: 2009/10/26 Luca Donaggio donag...@gmail.com: The output from dpkg is exactly the same. What do you mean by Have you tried to install your optified packages after you created /opt directory inside your target? ? I thought it was failing before you re-created /opt. Probably I misunderstood the situation. I have: [sbox-FREMANTLE_X86: ~] v /targets/links/opt lrwxrwxrwx 1 cthulhu cthulhu 26 Oct 7 15:26 /targets/links/opt - /targets/FREMANTLE_X86/opt and: [sbox-FREMANTLE_X86: ~] v /targets/FREMANTLE_X86 total 76 [...] drwxrwxr-x 2 cthulhu cthulhu 4096 Oct 7 15:04 opt [..] but: [sbox-FREMANTLE_X86: ~] v /opt lrwxrwxrwx 1 cthulhu cthulhu 9 Oct 6 16:46 /opt - /home/opt You can read this thread: http://lists.maemo.org/pipermail//maemo-developers/2009-October/021588.html The error explained there is the same as yours. I resolved it by removing /opt from rootstraps. Here is what I have in my target: [sbox-maemo5-arm: ~] ls -la / | grep opt lrwxrwxrwx 1 root root 18 Oct 22 09:22 opt - /targets/links/opt [sbox-maemo5-arm: ~] ls -la /targets/maemo5-arm/ |grep opt drwxrwxr-x 2 ed ed 4096 Oct 26 16:19 opt And I'm able to install optified packages into this target: [sbox-maemo5-arm: ~] fakeroot apt-get install clucene-core Reading package lists... Done Building dependency tree... Done The following NEW packages will be installed: clucene-core 0 upgraded, 1 newly installed, 0 to remove and 2 not upgraded. Need to get 0B/319kB of archives. After unpacking 1085kB of additional disk space will be used. WARNING: The following packages cannot be authenticated! clucene-core Install these packages without verification [y/N]? y /scratchbox/tools/bin/sh: line 1: /usr/sbin/dpkg-preconfigure: No such file or directory Selecting previously deselected package clucene-core. (Reading database ... 6395 files and directories currently installed.) Unpacking clucene-core (from .../clucene-core_0.9.21b-0maemo1_armel.deb) ... Setting up clucene-core (0.9.21b-0maemo1) ... [sbox-maemo5-arm: ~] dpkg -L clucene-core |grep opt /opt /opt/maemo /opt/maemo/usr /opt/maemo/usr/lib /opt/maemo/usr/lib/libclucene.so.0.0.0 -- BR, Ed Thank you Ed, I've read that thread, but I was hoping for another (quicker) solution! After changing the rootstrap do I need to re-install the whole environment? I hope it would be enough to reset your targets and unpack rootstraps there. You can also try to make the same symlinks as I have instead of removing /opt from roostraps. Here is what I have: [sbox-maemo5-arm: ~] file /opt /opt: symbolic link to `/targets/links/opt' [sbox-maemo5-arm: ~] file /targets/links/opt /targets/links/opt: symbolic link to `/targets/maemo5-arm/opt' [sbox-maemo5-arm: ~] file /targets/maemo5-arm/opt /targets/maemo5-arm/opt: directory The only difference I can see is that my symlinks point out to the directory which exists, so you can start from creating /home/opt. If it won't work then you can try to make the same symlinks that I have. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to find the author of a git commit?
2009/10/26 Alberto Mardegan ma...@users.sourceforge.net: Hi, I noticed just now that a few days ago someone committed some code into maemo-mapper, but I have no idea who did. I will ask in the project forum, but in case the author is not following it, is it possible to find out who the author was by looking at the git commit? It's this one: https://garage.maemo.org/plugins/ggit/browse.php/?p=maemo-mapper;a=commit;h=edd250bb545e15385375b131843d080ec81a8d1f git-show edd250bb545e15385375b131843d080ec81a8d1f will show you the author. commit edd250bb545e15385375b131843d080ec81a8d1f Author: maemo ma...@maemo-desktop.(none) Date: Tue Oct 20 23:46:38 2009 +0100 Here you can find his email: https://garage.maemo.org/users/maemo/ -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo-Optify Builder Bots = Broken?
2009/10/24 Graham Cobb g+...@cobb.uk.net: I don't think you will get anywhere. Isn't this a known issue? The manual installation instructions for the SDK (http://wiki.maemo.org/Documentation/Maemo5_Final_Installation#Manual_Installation) include: In order to facilitate installing applications under /opt on the device, a symlink /opt has been created pointing to /home/opt. The SDK inherits this feature. I'd say it inherits it in a funny way. May be it's better not to do it at all then do it like it's done. Under Scratchbox, /opt points to /target/links/opt which in turn points to /targets/target_name/opt. Installing the rootstraps makes this point to /home/opt, which is not what we want, since we need /opt to be target specific. In order to resolve this situation, [sbox-FREMANTLE_X86: ~] rm /targets/FREMANTLE_X86/opt [sbox-FREMANTLE_X86: ~] mkdir /targets/FREMANTLE_X86/opt I think sbdmock needs to do the same thing after installing the rootstrap. I don't think so. It looks like a hack to remove something provided by official SDK image. Why they put this symlink in there if it's not needed and even prevents installation of optified packages? As you can see from my posts deleting it from rootstrap solves the issue. So, obvious way would be to not provide it in rootstrap at all. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo-Optify Builder Bots = Broken?
2009/10/24 Graham Cobb g+...@cobb.uk.net: On Sat, Oct 24, 2009 at 11:03:18AM +0300, Ed Bartosh wrote: 2009/10/24 Graham Cobb g+...@cobb.uk.net: I think sbdmock needs to do the same thing after installing the rootstrap. I don't think so. It looks like a hack to remove something provided by official SDK image. Why they put this symlink in there if it's not needed and even prevents installation of optified packages? As you can see from my posts deleting it from rootstrap solves the issue. So, obvious way would be to not provide it in rootstrap at all. I completely agree with you but from a **practical** point of view it is not likely to change in the short term (and maybe not at all)! I understand that. That's why I removed /opt from the rootstrap instead of waiting for the fix from SDK team. And it is definitely a BUG in sbdmock if it is not following the instructions included in the documentation of doing a manual rootstrap installation. Whether we agree with it or not, the documentation includes instructions for what has to be done after installing the rootstrap. Of course, it should be an option set in the conf file so that it is only done for the broken SDKs and can be turned off if it is ever fixed in later SDKs. I'm still not sure it's good to remove /opt in sbdmock code. Sbdmock isn't a tool for building packages only for Maemo, so it doesn't have to follow instructions specific for one particular release of SDK for particular platform. It's general-purpose builder which uses scratchbox as a low level tool and rootstrap as pre-defined enviromnent for the build. Having workarounds for specific Maemo SDK bug in it doesn't look good for me. I like fixing rootstrap more. However you can send patch to sbdmock author. He might have another opinion. Marius, can you point us to the bug, please? I'd like to see what SDK guys say about it. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo-Optify Builder Bots = Broken?
2009/10/22 Kamen Bundev bun...@gmail.com: Hmm, yes, that seems to be the problem. In the final SDK /opt is a symlink but in the latest beta SDK it is not. I didn't upgrade my development machine, but I have the final on another so I can compare. I'll report back if successful. You're right. Autobuilder uses latest SDK and /opt is in the rootstrap: tar -ztf /scratchbox/packages/maemo-sdk-rootstrap_5.0_armel.tgz | grep '^\./opt' ./opt I removed it from there and now packages with /opt directory should be installable. Try to re-upload your packages to autobuilder. It should work now. Thank you for your help. PS: Is someone willing to file a bug for SDK :) ? -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo-Optify Builder Bots = Broken?
Hi, Please read my last message. The issue is fixed. Nobody should do anything except of SDK guys. 2009/10/22 Kamen Bundev bun...@gmail.com: Hi guys, I've played around with maemo-optify yesterday and decided to instead of creating the paths in the package subdir, to create a symlink to /opt and drop everything there before packaging. Wrong move, dpkg-deb doesn't follow symlinks, it packages them :) So, the logical step was to instead of symlink to /opt, to create home/opt in the package subdir and symlink opt/ to it. That worked and I have a package ready that will work in the device, but I'm hesitant to try it in the autobuilder because if the autobuilder is like scratchbox, then the package will be installed to /home/opt but the /opt symlinks will point to somewhere else (/targets/links/opt) and the build will fail anyway. So my question is - is this the right way to go about this and can I control where the /opt dir is symlinked to in the autobuilder? Regards: Bundyo On Thu, Oct 22, 2009 at 2:35 AM, Nathan Anderson nat...@andersonsplace.net wrote: Kamen, I build both binary target and source targets debs in my scratchbox before I upload.For instance last night I had to rebuild the binary debs about 20 times (trying to get a weird make file rule to work). Once I got it working then I would copy my rules to a fresh copy and re-run a source deb then re-run a binary once more just to make sure it wasn't left over stuff causing a success. ;-) So, I don't think it has anything to do with the scratchbox. I suspect it as Ed found something to do with the symlink - directory or something in their on the auto-builder. Nathan. From: Kamen Bundev [mailto:bun...@gmail.com] Sent: Wednesday, October 21, 2009 6:14 PM To: Nathan Anderson Cc: maemo-developers@maemo.org Subject: Re: Maemo-Optify Builder Bots = Broken? Nah, that's not enough. Still fails. Another difference is that I'm building my optified package in scratchbox before upload and the other people are using the autobuilder, so the problem should be somewhere else. Regards: Bundyo On Thu, Oct 22, 2009 at 2:09 AM, Kamen Bundev bun...@gmail.com wrote: Nah, that's not enough. Still fails. Regards: Bundyo On Thu, Oct 22, 2009 at 12:52 AM, Kamen Bundev bun...@gmail.com wrote: Looks like the only difference here is that my /opt should be pointing to /targets/links/opt which is symlinked to the proper target on target change. Uploading the new package to extras now. Regards: Bundyo On Thu, Oct 22, 2009 at 12:39 AM, Nathan Anderson nat...@andersonsplace.net wrote: Ed, I believe this is what you are asking: FREMANTLE_ARMEL cs2007q3-glibc2.5-arm7 FREMANTLE_X86cs2007q3-glibc2.5-i486 Nathan -Original Message- From: Ed Bartosh [mailto:bart...@gmail.com] Sent: Wednesday, October 21, 2009 4:03 PM To: Nathan Anderson Cc: maemo-developers@maemo.org Subject: Re: Maemo-Optify Builder Bots = Broken? 2009/10/21 Nathan Anderson nat...@andersonsplace.net: Ed, Sure can (and following the chain). ls -l / | grep opt lrwxrwxrwx1 root root 18 Oct 6 22:36 opt - /targets/links/opt ls -l /targets/links/ | grep opt lrwxrwxrwx 1 maemo 1000 26 Oct 19 16:55 opt - /targets/FREMANTLE_X86/opt I've found the difference! In your environment /targets/target/opt is a directory. In autobuilder environment it's a symlink: ls -l /targets/maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c/ |grep opt lrwxrwxrwx 1 builder1 builder19 Oct 21 23:50 opt - /home/opt And it looks like it becomes symlink after rootstrap unpacking. Look: [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] sb-conf re -f [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] ls -l /targets/maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c/ |grep opt drwxrwxr-x 2 1005 1006 4096 Oct 21 23:56 opt [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] sb-conf in --etc --devkits [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] ls -l /targets/maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c/ |grep opt drwxrwxr-x 2 builder1 builder1 4096 Oct 21 23:56 opt [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] sb-conf in --fakeroot Installing fakeroot version 1.4.2.1... [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] ls -l /targets/maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c/ |grep opt drwxrwxr-x 2 builder1 builder1 4096 Oct 21 23:56 opt [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] sb-conf rs /scratchbox/packages/maemo-sdk-rootstrap_5.0_armel.tgz Unpacking rootstrap... [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] ls -l /targets/maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c/ |grep opt lrwxrwxrwx 1 1005 10069 Oct 21 23:57 opt - /home/opt So, the difference
Re: Maemo-Optify Builder Bots = Broken?
Hi, I restarted Nathan's build and autobuilder seems to be able to install all build-deps. You can see autobuilder logs here soon: https://garage.maemo.org/builder/fremantle/sword_1.6.0a-0maemo1/ 2009/10/22 Ed Bartosh bart...@gmail.com: Hi, Please read my last message. The issue is fixed. Nobody should do anything except of SDK guys. 2009/10/22 Kamen Bundev bun...@gmail.com: Hi guys, I've played around with maemo-optify yesterday and decided to instead of creating the paths in the package subdir, to create a symlink to /opt and drop everything there before packaging. Wrong move, dpkg-deb doesn't follow symlinks, it packages them :) So, the logical step was to instead of symlink to /opt, to create home/opt in the package subdir and symlink opt/ to it. That worked and I have a package ready that will work in the device, but I'm hesitant to try it in the autobuilder because if the autobuilder is like scratchbox, then the package will be installed to /home/opt but the /opt symlinks will point to somewhere else (/targets/links/opt) and the build will fail anyway. So my question is - is this the right way to go about this and can I control where the /opt dir is symlinked to in the autobuilder? Regards: Bundyo On Thu, Oct 22, 2009 at 2:35 AM, Nathan Anderson nat...@andersonsplace.net wrote: Kamen, I build both binary target and source targets debs in my scratchbox before I upload.For instance last night I had to rebuild the binary debs about 20 times (trying to get a weird make file rule to work). Once I got it working then I would copy my rules to a fresh copy and re-run a source deb then re-run a binary once more just to make sure it wasn't left over stuff causing a success. ;-) So, I don't think it has anything to do with the scratchbox. I suspect it as Ed found something to do with the symlink - directory or something in their on the auto-builder. Nathan. From: Kamen Bundev [mailto:bun...@gmail.com] Sent: Wednesday, October 21, 2009 6:14 PM To: Nathan Anderson Cc: maemo-developers@maemo.org Subject: Re: Maemo-Optify Builder Bots = Broken? Nah, that's not enough. Still fails. Another difference is that I'm building my optified package in scratchbox before upload and the other people are using the autobuilder, so the problem should be somewhere else. Regards: Bundyo On Thu, Oct 22, 2009 at 2:09 AM, Kamen Bundev bun...@gmail.com wrote: Nah, that's not enough. Still fails. Regards: Bundyo On Thu, Oct 22, 2009 at 12:52 AM, Kamen Bundev bun...@gmail.com wrote: Looks like the only difference here is that my /opt should be pointing to /targets/links/opt which is symlinked to the proper target on target change. Uploading the new package to extras now. Regards: Bundyo On Thu, Oct 22, 2009 at 12:39 AM, Nathan Anderson nat...@andersonsplace.net wrote: Ed, I believe this is what you are asking: FREMANTLE_ARMEL cs2007q3-glibc2.5-arm7 FREMANTLE_X86cs2007q3-glibc2.5-i486 Nathan -Original Message- From: Ed Bartosh [mailto:bart...@gmail.com] Sent: Wednesday, October 21, 2009 4:03 PM To: Nathan Anderson Cc: maemo-developers@maemo.org Subject: Re: Maemo-Optify Builder Bots = Broken? 2009/10/21 Nathan Anderson nat...@andersonsplace.net: Ed, Sure can (and following the chain). ls -l / | grep opt lrwxrwxrwx1 root root 18 Oct 6 22:36 opt - /targets/links/opt ls -l /targets/links/ | grep opt lrwxrwxrwx 1 maemo 1000 26 Oct 19 16:55 opt - /targets/FREMANTLE_X86/opt I've found the difference! In your environment /targets/target/opt is a directory. In autobuilder environment it's a symlink: ls -l /targets/maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c/ |grep opt lrwxrwxrwx 1 builder1 builder19 Oct 21 23:50 opt - /home/opt And it looks like it becomes symlink after rootstrap unpacking. Look: [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] sb-conf re -f [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] ls -l /targets/maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c/ |grep opt drwxrwxr-x 2 1005 1006 4096 Oct 21 23:56 opt [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] sb-conf in --etc --devkits [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] ls -l /targets/maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c/ |grep opt drwxrwxr-x 2 builder1 builder1 4096 Oct 21 23:56 opt [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] sb-conf in --fakeroot Installing fakeroot version 1.4.2.1... [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] ls -l /targets/maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c/ |grep opt drwxrwxr-x 2 builder1 builder1 4096 Oct 21 23:56 opt [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] sb-conf rs /scratchbox/packages/maemo-sdk-rootstrap_5.0_armel.tgz
Re: QA queue determine required thumbs down for removal
2009/10/22 Niels Breet ni...@maemo.org: On Thu, October 22, 2009 15:31, gary liquid wrote: There is no interface to pull apps manually. if testing identifies a blocker, the maintainer has no way but to leave it there wasting the other testers time. This reminds me. If a maintainer votes his own app down, it should be removed instantly. We should also think about dependencies when packages are removed from -testing. If maintainer doesn't like his library and removes it what will happen with another application, which depends on this library? Theoretically it should be also removed from -testing or rebuilt with older version of library if it exists. This situation can be resolved if autobuilder would build dependencies only from extras. However it can slow down the whole process, because developers would have to wait untill all needed libraries go to extras before they'll be able to build their packages. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: AutoBuilders ignoring a depenancy
2009/10/22 Nathan Anderson nat...@andersonsplace.net: Ed, I resubmitted my package; and it decided to ignore one of my dependency. (But it did pull in the optified packages! g) https://garage.maemo.org/builder/fremantle/sword_1.6.0a-0maemo1/armel.root.l og.OK.txt Shows: 2009-10-22 17:46:55] Try to install static depends: libcurl3 libcurl3-dev libicu42 libicu42-dev clucene-core clucene-core-dev zlib1g-dev python2.5 python2.5-dev maemo-optify However the dsc file has: https://garage.maemo.org/builder/fremantle/sword_1.6.0a-0maemo1/sources/swor d_1.6.0a-0maemo1.dsc Build-Depends: debhelper (= 5), libcurl3, libcurl3-dev, libicu42, libicu42-dev, clucene-core, clucene-core-dev, zlib1g-dev, zlib1g, python2.5, python2.5-dev, swig1.3, maemo-optify It ignored my swig1.3 request. The default swig inside scratchbox/sdk is 1.3.29 -- It generates totally broken code for this package so I took the debian packaged 1.3.40 and added the minor changes to it to make it work on maemo. It is listed in the extras repository as swig1.3 Just put swig1.3 (= 1.3.40) into Build-depends: line of your package. It should solve the problem. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo-Optify Builder Bots = Broken?
2009/10/22 Julius Luukko julle.luu...@quicknet.inet.fi: But did you forgot to do it for x86 target? armel builds now fine, but i386 does not [1]: Oops, sorry. My bad. Done. Should work now. Just in case someone wants to do the same for their rootstraps. This is what I did: gunzip /scratchbox/packages/maemo-sdk-rootstrap_5.0_i386.tgz /tmp/maemo-sdk-rootstrap_5.0_i386.tar tar --delete -f /tmp/maemo-sdk-rootstrap_5.0_i386.tar ./opt mv /scratchbox/packages/maemo-sdk-rootstrap_5.0_i386.tgz /scratchbox/packages/maemo-sdk-rootstrap_5.0_i386.tgz.withopt gzip /tmp/maemo-sdk-rootstrap_5.0_i386.tar /scratchbox/packages/maemo-sdk-rootstrap_5.0_i386.tar.gz -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo-Optify Builder Bots = Broken?
2009/10/21 Nathan Anderson nat...@andersonsplace.net: ... Selecting previously deselected package clucene-core. Unpacking clucene-core (from .../clucene-core_0.9.21b-0maemo1_armel.deb) ... dpkg: error processing /var/cache/apt/archives/clucene-core_0.9.21b-0maemo1_armel.deb (--unpack): trying to overwrite `/opt', which is also in package base-files Uhm, this is not good. Each of my optified packages throws this error. That kinda makes optifing the libraries a pointless exercise if I can't use them later in the buildbot. And Lib-icu is about 16 MEGS of libraries, so I would think it would be a great canidate for optification. Do I need to resubmit everything w/o optification, or are the build bots broken? Have you tried to reproduce this issue in your build environment by installing your library and base-files locally inside scratchbox? Below are my attempts to reproduce and fix the problem: This is what I see in autobulder environment: grep /opt$ /var/lib/dpkg/info/base-files.list /opt It means that /opt belongs to base-files package. And I can easily reproduce the error if I try to install any package with /opt directory inside it: fakeroot apt-get install clucene-core Reading package lists... Done Building dependency tree... Done The following NEW packages will be installed: clucene-core 0 upgraded, 1 newly installed, 0 to remove and 2 not upgraded. Need to get 319kB of archives. After unpacking 1085kB of additional disk space will be used. WARNING: The following packages cannot be authenticated! clucene-core Install these packages without verification [y/N]? y Get:1 http://osso.stage.dmz fremantle/free clucene-core 0.9.21b-0maemo1 [319kB] Fetched 319kB in 0s (329kB/s) /scratchbox/tools/bin/sh: line 1: /usr/sbin/dpkg-preconfigure: No such file or directory Selecting previously deselected package clucene-core. (Reading database ... 6395 files and directories currently installed.) Unpacking clucene-core (from .../clucene-core_0.9.21b-0maemo1_armel.deb) ... dpkg: error processing /var/cache/apt/archives/clucene-core_0.9.21b-0maemo1_armel.deb (--unpack): trying to overwrite `/opt', which is also in package base-files dpkg-deb: subprocess paste killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/clucene-core_0.9.21b-0maemo1_armel.deb E: Sub-process /scratchbox/devkits/debian-etch/bin/dpkg returned an error code (1) Hmm. Let's remove /opt from base-files.list and see what happens: Unpacking clucene-core (from .../clucene-core_0.9.21b-0maemo1_armel.deb) ... dpkg: error processing /var/cache/apt/archives/clucene-core_0.9.21b-0maemo1_armel.deb (--unpack): error creating directory `./opt': Permission denied dpkg-deb: subprocess paste killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/clucene-core_0.9.21b-0maemo1_armel.deb It didn't help, but we can see that dpkg tries to create directory /opt and fails because symlink /opt already exists. OK, then. Let's put /opt back to base-files.list and create directory /opt instead of symlink: $ sudo rm /scratchbox/users/ed/opt $ sudo mkdir /scratchbox/users/ed/opt $ sudo chown ed /scratchbox/users/ed/opt And try again: fakeroot apt-get install clucene-core Reading package lists... Done Building dependency tree... Done The following NEW packages will be installed: clucene-core 0 upgraded, 1 newly installed, 0 to remove and 2 not upgraded. Need to get 0B/319kB of archives. After unpacking 1085kB of additional disk space will be used. WARNING: The following packages cannot be authenticated! clucene-core Install these packages without verification [y/N]? y /scratchbox/tools/bin/sh: line 1: /usr/sbin/dpkg-preconfigure: No such file or directory (Reading database ... 6395 files and directories currently installed.) Unpacking clucene-core (from .../clucene-core_0.9.21b-0maemo1_armel.deb) ... Setting up clucene-core (0.9.21b-0maemo1) ... It works! Hurray! :) So, my conclusion is this is scratchbox problem, not autobuilder one. It's not autobuilder, who creates /opt symlinks. They're created by scratchbox for each user. May be scratchbox guys can explain how to fix it properly. Of course I can remove symlinks and create directories instead for all builders, but may be there is better way to solve the problem? -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo-Optify Builder Bots = Broken?
2009/10/21 Nathan Anderson nat...@andersonsplace.net: Ed, I have actually installed all the packages I have built and submitted to extras _inside_ my scratchbox from extras(-devel/testing) Good. In this case we just need to understand what's the difference between your environment and autobuilder one. Can you show me output of the following commands run inside scratchbox: ls -l / |grep opt dpkg -l base-files -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo-Optify Builder Bots = Broken?
2009/10/21 Nathan Anderson nat...@andersonsplace.net: Ed, Sure can (and following the chain). ls -l / | grep opt lrwxrwxrwx1 root root 18 Oct 6 22:36 opt - /targets/links/opt ls -l /targets/links/ | grep opt lrwxrwxrwx 1 maemo 1000 26 Oct 19 16:55 opt - /targets/FREMANTLE_X86/opt ls -l /targets/FREMANTLE_X86 | grep opt drwxr-xr-x 4 maemo sbox 4096 Oct 7 11:39 opt Dpkg -l base-files Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++---== == ii base-files 3.1.osso2+3.1.10.osso23+ Debian base system miscellaneous files Looks the same as in autobuilder environment. Can you show versions of scratchbox packages? This is what I have on autobuilder host: $ dpkg -l |grep scratchbox ii scratchbox-core 1.0.16 Scratchbox base system ii scratchbox-devkit-apt-https 1.0.10 APT HTTPS devkit for Scratchbox ii scratchbox-devkit-cputransp 1.0.9 CPU transparency methods ii scratchbox-devkit-debian 1.0.10 Debian tools for Scratchbox ii scratchbox-devkit-doctools1.0.13 Doctools for Scratchbox ii scratchbox-devkit-git 1.0.1 Git for Scratchbox ii scratchbox-devkit-maemo3 1.0.3 Maemo 3 devkit for Scratchbox ii scratchbox-devkit-perl1.0.4 Perl modules for Scratchbox ii scratchbox-devkit-qemu0.10.0-0sb5 Qemu scratchbox devkit ii scratchbox-devkit-svn 1.0 Subversion devkit for Scratchbox ii scratchbox-libs 1.0.16 Scratchbox libraries ii scratchbox-toolchain-cs2005q3.2-glibc2.5-arm 1.0.7.2 cs2005q3.2-glibc2.5-arm compiler for Scratch ii scratchbox-toolchain-cs2005q3.2-glibc2.5-i386 1.0.7 cs2005q3.2-glibc2.5-i386 compiler for Scratc ii scratchbox-toolchain-cs2007q3-glibc2.5-arm7 1.0.12-10 cs2007q3-glibc2.5-arm7 compiler for Scratchb ii scratchbox-toolchain-cs2007q3-glibc2.5-i486 1.0.12-8 cs2007q3-glibc2.5-i486 compiler for Scratchb ii scratchbox-toolchain-host-gcc 1.0.16 Scratchbox host-gcc toolchain -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo-Optify Builder Bots = Broken?
2009/10/21 Nathan Anderson nat...@andersonsplace.net: Ed, Sure can (and following the chain). ls -l / | grep opt lrwxrwxrwx1 root root 18 Oct 6 22:36 opt - /targets/links/opt ls -l /targets/links/ | grep opt lrwxrwxrwx 1 maemo 1000 26 Oct 19 16:55 opt - /targets/FREMANTLE_X86/opt ls -l /targets/FREMANTLE_X86 | grep opt drwxr-xr-x 4 maemo sbox 4096 Oct 7 11:39 opt Oops, sorry. I've overlooked that you're using X86 target. Autobuilder used armel target when it failed. You can see it here: https://garage.maemo.org/builder/fremantle/sword_1.6.0a-0maemo1/armel.root.log.FAILED.txt Try to install your packages in armel target, please. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Can't find lt_dlopen in autobuilder for DIABLO
Hi, Short answer: Change libltdl3-dev to libltdl3-dev (= 1.5.22) in Build-depends line of your debian/control. It should help to fix your build. Long answer: - I've debugged this situation a bit and found out that libltdl3-dev is provided by scratchbox: [sbox-maemo4-arm: ~/libmp3splt-0.5.7a] dpkg-checkbuilddeps : Using Scratchbox tools to satisfy builddeps : Dependency provided by Scratchbox: libtool : Dependency provided by Scratchbox: libltdl3-dev : Dependency provided by Scratchbox: autotools-dev and scratchbox really provides this library: find /scratchbox/compilers/cs2005q3.2-glibc2.5-arm/ -name *ltdl* /scratchbox/compilers/cs2005q3.2-glibc2.5-arm/arch_tools/share/aclocal/ltdl.m4 /scratchbox/compilers/cs2005q3.2-glibc2.5-arm/arch_tools/share/libtool/libltdl /scratchbox/compilers/cs2005q3.2-glibc2.5-arm/arch_tools/share/libtool/libltdl/ltdl.c /scratchbox/compilers/cs2005q3.2-glibc2.5-arm/arch_tools/share/libtool/libltdl/ltdl.h /scratchbox/compilers/cs2005q3.2-glibc2.5-arm/arch_tools/lib/libltdl.so.3.1.2 /scratchbox/compilers/cs2005q3.2-glibc2.5-arm/arch_tools/lib/libltdl.a /scratchbox/compilers/cs2005q3.2-glibc2.5-arm/arch_tools/lib/libltdl.la /scratchbox/compilers/cs2005q3.2-glibc2.5-arm/arch_tools/lib/libltdl.so.3 /scratchbox/compilers/cs2005q3.2-glibc2.5-arm/arch_tools/lib/libltdl.so /scratchbox/compilers/cs2005q3.2-glibc2.5-arm/arch_tools/include/ltdl.h However configure couldn't find it or it finds it but for some reason can't use it. I decided not to investigate why it happens and just try to make build to use another libltdl. Scratchbox provides libltdl3-dev version 1.5.20. You can see this in here: /scratchbox/compilers/cs2005q3.2-glibc2.5-arm/deb_list/libtool. Fortunately we have libltdl3-dev 1.5.22-4maemo1 in SDK repo. So, to make build use version from repo we need to change build dependency of your package from libltdl3-dev to libltdl3-dev (= 1.5.22). After that it was built just fine for me. Another, proper way was to keep digging into configure magic and find out why it doesn't like libltdl provided by scratchbox, which would most probalby lead us to the long way of waiting for the fix from scratchbox guys. May be I'm too lazy or too old for this, but I decided to leave this exercise to someone else :) Regards, Ed 2009/10/4 Bruce Forsberg bruce.forsb...@gmail.com: I am trying to port the mp3splt package to DIABLO. I am have problems getting the library package to build with the autobuilder. It does not seem to be able to find the libltdl library. I have included libtool, libltdl3, libltdl3-dev in the Build-Depends of the control file but this does not seem to work as the configure file gives the error: checking ltdl.h usability... no checking ltdl.h presence... no checking for ltdl.h... no checking whether to use included libltdl... . . . checking for lt_dlopen in -lltdl... no configure: error: libltdl not found - check libtool installation ! This all works in my scratchbox DIABLO_ARMEL environment. Does anybody have any ideas on what I need to add to get this to work. I believe that mp3splt uses plugins so I need this to work. The error files are at: https://garage.maemo.org/builder/diablo/libmp3splt_0.5.7a-maemo1/ The control file is (I have tried many combinations): Source: libmp3splt Priority: optional Maintainer: Munteanu Alexandru Ionut (io_alex_2...@yahoo.fr) Build-Depends: debhelper (= 5), libtool, libltdl3-dev, libvorbis-dev, libmad0-dev, libid3tag0-dev, autotools-dev Standards-Version: 3.6.0 Section: user/multimedia Package: libmp3splt0 Section: libs Architecture: any Depends: libmp3splt Description: Library that splits MP3 and Ogg Vorbis files without reencoding Used to split MP3 (VBR supported) and Ogg Vorbis files into smaller files without decoding. Useful for splitting albums, either manually, using freedb.org data, or .cue files ... . Homepage: http://mp3splt.sourceforge.net/ Package: libmp3splt0-dev Section: libdevel Architecture: any Depends: libmp3splt0 Description: Library that splits MP3 and Ogg Vorbis files without reencoding Used to split MP3 (VBR supported) and Ogg Vorbis files into smaller files without decoding. Useful for splitting albums, either manually, using freedb.org data, or .cue files ... . This is the package you need to develop or compile applications that use mp3splt. Thanks for any help. I am a novice debian developer. Thanks, Bruce ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Allowed sections for Fremantle
Hi, Here are new categories suggested by community: http://wiki.maemo.org/Task:Package_categories Don't ask me why official SDK documentation contains another list :) Regards, Ed 2009/9/24 Luca Donaggio donag...@gmail.com: According to [1], the allowed user/* sections are: user/accessories Accessories user/communication Communication user/games Games user/multimedia Multimedia user/office Office user/other Other user/programming Programming user/support Support user/themes Themes user/tools Tools But the package interface seems to think differently; the page for grsync [2] says: Section:user/accessories Warning: This package is not using one of the allowed user/* sections! What's wrong? The wiki or the package interface? Or maybe the reason is another one? [1] http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging%2C_Deploying_and_Distributing#Sections [2] https://maemo.org/packages/package_instance/view/fremantle_extras-devel_free_i386/grsync/0.6.3-mameo1/ -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Diablo Libssl broken in extras-devel
2009/9/9 Jeremiah Foster jerem...@maemo.org: On Sep 8, 2009, at 9:43, Ed Bartosh wrote: BTW, before removing it from extras-devel try to find all packages which depend on it and after removing libssl reupload them to the autobuilder. They will be rebuilt with proper openssl then. How does that work? I thought the problem was that it was being built from stuff from extras-devel - how is it going to suddenly find the right libs? Autobuilder uses extras-devel and SDK repos to satisfy build dependencies. So, if you remove libssl from extras-devel and reindex repository next builds will use proper libssl from SDK repo. SDK version of libssl should be the same as device one. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Diablo Libssl broken in extras-devel
2009/9/8 Jeremiah Foster jerem...@maemo.org: On Sep 8, 2009, at 24:58, Graham Cobb wrote: Jeremiah, I haven't checked this out myself but I **think** what Till is seeing is that the autobuilder builds his app with the libssl package from extras- devel and ends up with a versioned dependency on that specific version of libssl. However, the extras-devel version of libssl cannot be installed because it conflicts with a Nokia package (presumably it is one of the libraries Nokia installs and does not allow to be replaced). If this guess is right then the new version of libssl should be removed from extras-devel as it can never be used by anyone. But you might want to check out who uploaded it to see if you can find out why. Very interesting. I think you are right because someone asked my yesterday to remove libssl since the version they uploaded ddin't work. I imagine they uploaded libssl again since they need it as a dependency. Here is the summary log of latest libssl uploaded to autobuilder: https://garage.maemo.org/builder/diablo/openssl_0.9.8g-15maemo4+0m5/summary.log You can see uploader name there and ask him why he uploaded it. BTW, before removing it from extras-devel try to find all packages which depend on it and after removing libssl reupload them to the autobuilder. They will be rebuilt with proper openssl then. Ed and Niels: Shouldn't we disallow uploading of packages that are un- installable on the tablet? That was the idea of package installability check which I wrote recently. I showed you the logs it produced. Unfortunately it's still under consideration of Nokia legal if we can use it outside Nokia. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder: building svn tags from garage
2009/8/31 Marius Vollmer marius.voll...@nokia.com: ext Ed Bartosh bart...@gmail.com writes: As I already said building in a proper order is already solved task. There is no need to upload packages in build order if it can be done automatically. It will only create extra job for developers. Here is something to consider: Source packages produce binary packages and they have dependies on binary packages. If you have a set of source packages, you need to order them so that any source package that has a dependency on a binary package is build after the source package that produces that binary. This is the obvious part. The interesting bit is this: Binary packages have dependencies on other binary packages. If you depend on a binary package that depends on another binary package, you also indirectly depend on that other package. This means that when ordering source packages, we need to look at all direct _and_indirect_ dependencies it has on binary packages, not just the direct dependencies. True. I think our internal buildbot (who does order source packages by their dependencies) only looks at the direct dependencies. Yes. And I'm going to use that code in autobuilder without redesigning. At least now. Later on I might consider to implement analyzing binary dependencies, but it will happen only if it's really needed. I doubt that this can be showstopper for first implementation of multiple package builds. Now, there is a slight complication: dependencies between binary packages are computed at build-time. That is, they are not known before actually building the binary package. The problem is still solveable if we interleave building with sorting: I.e., we start with an incomplete graph of dependencies (that contains all source packages and the binary packages they produce as nodes, the dependencies from source to binary as arrows, but not the dependencies between binary packages) and start building those source packages that do not have any dependencies on other packages in the graph. Then we look at the packages that have just been built and update the graph with the new dependencies. Then there are cycles of dependencies, of course, or more correctly, stronly connected components in the dependency graph. Absent any hints in the source packages themselves, these strongly connected components need to be broken up by humans, I think. Thank you for the commentssuggstions. It definitely make sense to implement if we're talking about perfect build system. However for me it doesn't sound like thing to do right now. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder: building svn tags from garage
2009/8/31 Marius Vollmer marius.voll...@nokia.com: ext Ed Bartosh bart...@gmail.com writes: [To upload a multi-package build request] It might be enough to just allow more than one paragraph in the .changes files, and make the guarantees that packages are build in order of their build-dependencies and the build aborts as soon as one package fails. (If I understand right what people are looking for.) Adding new paragraph would require to make a tool or change existing tools, right? Yes, of course. I think ideally dput should be changed to understand the new .changes format. A entry in .dput.cf could say for each remote whether it is supported or not (the default being no), so that people don't upload multi-package requests to queues that don't support it. Maybe it is a good idea to add a new 'header' paragraph at the beginning of multi-package .changes file so that queues that don't support it fail very visibly and don't just ignore the second and later paragraphs. I see this way as much more complicated than way I proposed in this thread. Please, read this message and comment if you don't mind: http://lists.maemo.org/pipermail/maemo-developers/2009-August/020315.html It would also require to modify dput just a bit, but no changes to .changes format are required. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: upload to extra
Hi, It's available and works, but sometimes gives the same error to me also. Last time I've asked admins they told me that reason can be network load of the host or something like that. 2009/8/31 Fred f...@lefevere-laoide.net: Hi, Is the dput method still available for uploading to extras ? Or do I have to do something to re-activate my garage account since the new system ? I'm fredoll on garage and the account/index2.php page gives me the right public ssh key. but I always get authent... denied Thanks for your help Fred ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [lists] Re: Subversion and libesd?
Hi, And what about libkpathsea4? Any chance for it? 2009/8/28 Jeremiah Foster jerem...@jeremiahfoster.com: It has gone through the builder, but has not shown up in the file system as a deb yet. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder: building svn tags from garage
2009/8/27 Henrik Hedberg henrik.hedb...@innologies.fi: Graham Cobb wrote: Personally, I would much rather the autobuilder dependency problem was fixed (with some method for submiting multiple packages with build dependencies and having them build in the right order, with the dependencies being satisfied) instead of this particular feature. This should definitely be fixed first and soon. Thanks! :) If everybody thinks that support of multiple package builds is more important I'll do that. Ed Bartosh wrote: Submitting is the main problem. As far as I know dput can't upload several packages at the same time. Any ideas how to do this? I find that you all are thinking this too complicated. Depency graphs, web based interfaces, discussion about extending the dput and such... The current situation is that the build is triggered when a .dsc file has been uploaded. Fine. I'm going to change the code as Marius suggested. .changes will trigger the build. Let's require that a developer must upload .dsc files (or packages, if you like) in the order he or she wants the packages to be build. Fairly reasonable, I think. There are timestamps, and scp modifies those when it uploads a file into the server. Simple as that. Even make is using those magical timestamps. For one package it's already implemented in dput. .changes file is uploaded after all sources are uploaded. For multiple packages this is the problem, which we're trying to solve here. Now, the only real modification is that the autobuilder should use the latest version of a package that has been built - not some ancient package found from the repository. So, if a package A depends on a package B, I should upload the .dsc file of the package B first. I can upload the .dsc file of the package A immediately after that. The autobuilder builds the package B first, because it came first (the timestamp is older), and then the package A. When building the package A, it is using the package B from _the latest build_, not from the repository. As I already said building in a proper order is already solved task. There is no need to upload packages in build order if it can be done automatically. It will only create extra job for developers. I think the main problem with the current implementation is that even if you have uploaded a package and if it has been successfully built, it is not used when building other packages immediately after that. You have to wait unspecified time until the package hits the repository. Without that delay, one could even write a sequential upload script based on email build notifications. (Yes, I know that I could repeatedly download the Packages file from the repository, search the version number of my library packages, and trigger the uploading of my application based on that knowledge. Too complicated!) True. But if we manage to define a group of packages as one build I can solve this problem by creating local repo, adding packages to it as soon as they're built and using it for the build. Of course better solutions would be to make adding to extras-devel work faster, but i tend to think it's near to impossible :) If you care the situation when building fails, you could write an additional rule that all other packages from the same uploader are removed from the build queue if building of a package fails. Thus, if a package A depends on a package B, but the building of the package B fails, the autobuilder is not building the package A if it had already been uploaded into the queue. If group of the packages is in the separate directory this is even better. The same uploader can upload several groups and failure of one group wouldn't cause removing of others. This is what I've almost achieved by using dput.cf *_upload_command keywords. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder: building svn tags from garage
2009/8/27 Vlad Vasiliev v...@gas.by: Graham Cobb wrote: skip ... This can be done through a web interface, but I don't think many of the hardcore coders, needing this functionality, would use that? I would if it meant the autobuilder would handle the dependencies! I would even manually create the dependency graph using a web interface if analysing Build-Depends is too hard! It would be good if there was a way to upload the files using (say) scp to a staging area and then trigger the build using the web interface. Graham Hi. I think many packages don't need in those very complicated things. Maybe for begin Ed will create possibility to build package in Autobuilder using tag from svn. Most of them actually. But looking at this thread I see that support of multiple package builds is more welcome here than building tags. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder: building svn tags from garage
2009/8/27 Jeremiah Foster jerem...@jeremiahfoster.com: On Aug 26, 2009, at 19:52, Ed Bartosh wrote: 2009/8/26 Jeremiah Foster jerem...@jeremiahfoster.com: On Aug 26, 2009, at 18:05, Andrew Flegg wrote: On Wed, Aug 26, 2009 at 16:25, Ed Bartoshbart...@gmail.com wrote: 2009/8/26 Andrew Flegg and...@bleb.org: On Wed, Aug 26, 2009 at 16:17, Ed Bartoshbart...@gmail.com wrote: This is a good point - we have a chance to reduce the bloat of the debian system that is designed for at least eight official architectures when we build only two. Plus there might be a way to innovate and to simplify the entire build process over time which would be a huge win for developers. I understand that. If you may notice we're already using our own builder instead of wanna-build or whatever Debian uses for this. Some of the upstream build stuff is quite good though. And is python really the right tool to do builds? As far as I am concerned it has some drawbacks in this particular area: 1. The GIL problems make it unsuitable for multicore machines 2. Python is slow in general 3. The vast majority of existing build systems are written in something else, so there is a bit of wheel re-invention with python This is a bit out of scope of this thread. If you're really interested in comparing Python capabilities with other programming languages in this area feel free to create new thread for that. Regarding slowness of the Maemo build system in my opinion it isn't a result of using Python, but lack of resources (only one build host) and brain-damaged repository management system. And if it's not changed in near future I doubt that change to another build system will help. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Autobuilder: building svn tags from garage
Hi, I'm thinking about to add this feature to autobuilder. With developers don't need to prepare package's source and upload it to autobuilder queue. They just need to tag the sources. This is how i plan to implement it: 1. Svn hook will be creating description file or record in the database if new tag appears in tags/autobuilder/product directory for any garage project. 2. Special cron job will fetch new tag, build source package and put it into autobuilder incoming directory. 3. Autobuilder will build it the same way as it does currently. How does it look? Any ideas/suggestions? PS: If this feature will be usable I can add processing of git tags as well. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder: building svn tags from garage
2009/8/26 Anderson Lizardo anderson.liza...@openbossa.org: On Wed, Aug 26, 2009 at 6:54 AM, Ed Bartoshbart...@gmail.com wrote: Hi, I'm thinking about to add this feature to autobuilder. With developers don't need to prepare package's source and upload it to autobuilder queue. They just need to tag the sources. This is how i plan to implement it: 1. Svn hook will be creating description file or record in the database if new tag appears in tags/autobuilder/product directory for any garage project. 2. Special cron job will fetch new tag, build source package and put it into autobuilder incoming directory. 3. Autobuilder will build it the same way as it does currently. How does it look? Any ideas/suggestions? It would be nice if it could support those projects that keep only the debian/ directory under revision control. We do that for many PyMaemo packages, because there is no point keeping the entire source if we are only touching the debian packaging. Then we currently using some scripts that generate the source packages for us (and even build locally for testing). One idea might be to use some custom field in debian/control (see http://www.debian.org/doc/debian-policy/ch-controlfields.html#s5.7) that point to the original .dsc file in Debian, e.g.: XC-Original-Dsc: http://ftp.de.debian.org/debian/pool/main/d/dbus-python/dbus-python_0.83.0-1.dsc Then in case the autobuilder would simply do: dget url_to_dsc dpkg-source -x *.dsc rm -rf */debian cp -a /path/to/debian */debian The reason it should not point simply to the orig tarball is that some (misbehaved IMHO) packages keep changes directly on the sources, that are applied only when the diff.gz is applied with dpkg-source. Added to the TODO list. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder: building svn tags from garage
2009/8/26 Graham Cobb g+...@cobb.uk.net: On Wednesday 26 August 2009 11:54:13 Ed Bartosh wrote: I'm thinking about to add this feature to autobuilder. With developers don't need to prepare package's source and upload it to autobuilder queue. They just need to tag the sources. How is the version specified? Is the tag name used? Version is specified in debian/changelog, which is standard way for Debian packages, I believe. Will it handle build dependencies? I.e. if I create an autobuild tag for libaaa and also for application-aaa (with a build dependency on libaaa), will it submit the library build first? Will it wait for it to finish before submitting the application build? This is another story and much more complicated to implement. However if community wants this we can start to discuss possible ways to implement it. Personally, I would much rather the autobuilder dependency problem was fixed (with some method for submiting multiple packages with build dependencies and having them build in the right order, with the dependencies being satisfied) instead of this particular feature. Submitting is the main problem. As far as I know dput can't upload several packages at the same time. Any ideas how to do this? But I realise others may disagree! True. Most of developers developing one application and don't care about this feature. Main supporters for it is your project, pymaemo, efl and a few others, who has a lot of packages. And most of them have their own workarounds implemented. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder: building svn tags from garage
2009/8/26 Andrew Flegg and...@bleb.org: On Wed, Aug 26, 2009 at 15:29, Ed Bartoshbart...@gmail.com wrote: 2009/8/26 Graham Cobb g+...@cobb.uk.net: Personally, I would much rather the autobuilder dependency problem was fixed (with some method for submiting multiple packages with build dependencies and having them build in the right order, with the dependencies being satisfied) instead of this particular feature. Submitting is the main problem. As far as I know dput can't upload several packages at the same time. Any ideas how to do this? Bypass dput and use scp directly?debian/control's Build-Depends should be enough to say something like if there is a dependency on something else on the queue, build it first. Me personally don't like this. It looks hackish. Moreover, this is not enough. If autobuilder starts in the middle of upload it can pick up wrong packages, because their dependencies have not been uploaded yet. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers