Re: chip of cellular/wireless modem
> What is the concrete name of chip of cellular/wireless modem > in Nokia 770, Nokia N800, Nokia N810, Nokia N900 ? > > > P.S. > E.g. for Nokia N900: > As i read, "TI OMAP 3430 SoC" does not contain integrated modem? The 770, N800 and N810 do not contain any cellular device at all. They are not phones, they were sold as "Phone Accessories". To get connectivity they could connect to a phone via Bluetooth, or they could use WiFi. Ed Okerson ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Builder is creating zero sized packages (Was: Re: Package import into Extras-devel from the builder stucked)
2010/3/25 Henrik Hedberg : > 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 : > 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 : > 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 : > On 07/02/2010 01:30, Ed Bartosh wrote: >> 2010/2/7 Yves-Alexis Perez : >>> 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/7 Yves-Alexis Perez : > 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: Getting a CC: for cauldon mails (extras-devel)
2010/2/6 Yves-Alexis Perez : > 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: Query (Maemo) packages
2010/2/5 : > > 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 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 : > On Tuesday 26 January 2010 12:20:32 you wrote: >> 2010/1/26 Jeff Moe : >> > On Tuesday 26 January 2010 02:02:52 you wrote: >> >> 2010/1/26 Jeff Moe : >> >> > 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 Jeff Moe : > On Tuesday 26 January 2010 02:02:52 you wrote: >> 2010/1/26 Jeff Moe : >> > 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. -- 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 : > On Tue, Jan 26, 2010 at 8:05 AM, Ed Bartosh 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/26 Jeremiah Foster : > >>> 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 Jeremiah Foster : > > 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 : > > 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 : >>>>> 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 Jeff Moe : > 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 : > > On Jan 25, 2010, at 22:27, Ed Bartosh wrote: > >> 2010/1/25 Jeremiah Foster : >>> >>> 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/25 Jeff Moe : > 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 -e"Automatic Builder " -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/25 Jeremiah Foster : > > 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/23 Jeff Moe : > 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 : > On Fri, Jan 22, 2010 at 12:59, Simon Pickering > 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: How to destroy your community
> Large publicly listed companies have very strict rules when using money. > There's even a law about it in the USA > (http://en.wikipedia.org/wiki/Sarbanes_oxley) That has the implication > that a listed company cannot buy from wherever, and that limits the > choices considerably. I'm going to have to call BS on that one. Sarbanes-Oxley has absolutely nothing to do with whom you can do legitimate business. That law was created because some large companies had set up shell corporations to hide debt in to make their balance sheets look better. The law was designed to reform accounting practices by making corporate officers personally responsible for the accuracy of accounting records and financial reports. Ed Okerson ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to destroy your community
On Wed, January 20, 2010 3:54 pm Jeff Moe wrote: > Definitely. /me takes third swing: and just who is this ISP right now? I > know akamai is in the picture, but apparently someone else is hosting the > main part (e.g. the NFS/SAN ISP). I wouldn't even go as far as say they > should be a "stakeholder", they just need to provide industry standard > quality. Any ISP that isn't "motivated" 24/7 should be dropped. I think > one extended outage of the nature we saw over the weekend is enough even > (e.g. the hunt for a new ISP should begin immediately). Not really that hard to figure out: (abbreviated cut and paste) $ dig www.maemo.org ;; ANSWER SECTION: www.maemo.org. 41354 IN CNAME maemo.org. maemo.org. 42736 IN A 80.248.164.250 $ whois 80.248.164.250 inetnum:80.248.164.224 - 80.248.164.255 netname:FI-BILIA descr: Logica Finland Oy / Datacentre services country:FI role: Logica Finland Hostmaster remarks:Logica Finland Oy LIR role address:Logica Finland Oy address:P.O.BOX 38 address:FIN-00381 Helsinki phone: +35810302010 (Wild ass guess follows) $ whois logica.fi domain: logica.fi descr:Logica Suomi oy descr:03575029 address: Hannu Honkala address: Karvaamokuja 2 address: 00380 address: HELSINKI phone:+358 10-302010 (phone numbers match, damn my guesses are good). Open web browser and go to http://www.logica.fi/ pick the flag in the upper right corner and choose a country you can read the language of. Ed Okerson ___ 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 : > 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 : > Hi, > > On Mon, Jan 11, 2010 at 8:17 PM, ds 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
Re: Autobuilder is broken again
2010/1/11 Niels Breet : >> Hi guys, > Hi, > >> >> Do you happen to know who switched off armel builds and why? > > We didn't touch it at all. Was there a lock file left behind or something? > I don't know what happened, but I've seen about 15 builds using only i386 architecture. Now it's OK again, so I think that change was reverted back. -- 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 : > On Sun, Jan 3, 2010 at 15:39, Jeremiah Foster > 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 Ed Bartosh : > 2010/1/1 Jeff Moe : >> On Friday 01 January 2010 11:12:47 Ed Bartosh wrote: >>> 2010/1/1 Jeremiah Foster : >>> > On Jan 1, 2010, at 15:00, Ed Bartosh wrote: >>> >> 2010/1/1 Andrew Flegg : >>> >>> 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
Re: Autobuilder apt-get problems => failing builds
2010/1/1 Jeff Moe : > On Friday 01 January 2010 11:12:47 Ed Bartosh wrote: >> 2010/1/1 Jeremiah Foster : >> > On Jan 1, 2010, at 15:00, Ed Bartosh wrote: >> >> 2010/1/1 Andrew Flegg : >> >>> 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 Jeremiah Foster : > > On Jan 1, 2010, at 15:00, Ed Bartosh wrote: > >> 2010/1/1 Andrew Flegg : >>> 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 Andrew Flegg : > 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: How to switch hardware keyboard language?
2009/12/27 Arkadiy Glazov : > 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
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 allowed me to switch keyboard layout to . 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: Auto builder - Maemo-Optify
2009/12/24 David Greaves : > > 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: Auto builder - Maemo-Optify
2009/12/24 Andrew Flegg : > On Thu, Dec 24, 2009 at 12:22, Ed Bartosh 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 Andrew Flegg : > On Thu, Dec 24, 2009 at 12:01, Ed Bartosh wrote: >> 2009/12/24 Andrew Flegg : >>> 2009/12/24 Benoît HERVIER : >>>> 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. > > I read Benoît's question as the default having been switched from > "none" to "auto" (as discussed, but I didn't think we were in the > position to and was surprised it hadn't been mentioned as happening). > Since that's not it, that's not a problem. > >>> Put "none" in debian/optify: >>> >> It's not needed. The problem is not in autobuilder, but in the package. > > Fair enough :-) > > 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. Look at this example: [sbox-FREMANTLE_ARMEL: ~] > fakeroot apt-get install desktop-photoapplet Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: desktop-photoapplet 0 upgraded, 1 newly installed, 0 to remove and 82 not upgraded. Need to get 88.2kB of archives. After this operation, 233kB of additional disk space will be used. WARNING: The following packages cannot be authenticated! desktop-photoapplet Install these packages without verification [y/N]? y Get:1 http://repository.maemo.org fremantle/non-free desktop-photoapplet 0.2-8 [88.2kB] Fetched 88.2kB in 0s (216kB/s) /scratchbox/tools/bin/sh: line 1: /usr/sbin/dpkg-preconfigure: No such file or directory Selecting previously deselected package desktop-photoapplet. (Reading database ... 16528 files and directories currently installed.) Unpacking desktop-photoapplet (from .../desktop-photoapplet_0.2-8_armel.deb) ... Setting up desktop-photoapplet (0.2-8) ... If you can call it SDK bug or scratchbox bug I'd agree. But it has nothing to do with maemo-optify and autobuilder. So, the bug is invalid. -- 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 : > 2009/12/24 Benoît HERVIER : >> 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 Benoît HERVIER : > 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: sbdmock sample config
2009/12/23 Jeff Moe : > On Wednesday 23 December 2009 06:38:11 you wrote: >> 2009/12/23 Jeff Moe : >> > 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: sbdmock sample config
2009/12/23 Jeff Moe : > 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: Issues with autobuilder x86 bison
2009/12/16 Antonio Aloisio : > 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 : > 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 https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Promoting Diablo packages to extras-devel?
2009/12/8 Ville M. Vainio : > I have a package that's built ok for both Diablo and Fremantle > (penguinreader, to be exact). However, I can't find the plage where I > could promote the Diablo version to extras-testing. > There is no extras-testing for Diablo. It exists only for Fremantle. However you can promote Diablo packages from extras-devel directly to Extras using Maemo Extras promoter [1]. [1] https://garage.maemo.org/promoter/diablo -- 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 : > On Wed, Dec 2, 2009 at 9:02 AM, Ed Bartosh wrote: >> 2009/11/9 Marius Vollmer : >> >>>> 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 : >> 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/11/9 Marius Vollmer : > >> 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 : > ext Ed Bartosh 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
2009/11/4 Marius Vollmer : > ext Ed Bartosh writes: > >> 2009/11/3 Marius Vollmer : >> >>> 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: maemo-optify, autobuilder & /opt
2009/11/4 Marius Vollmer : > ext Ed Bartosh 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
Hi, 2009/11/2 Ed Bartosh : > 2009/11/2 Marius Vollmer : >> [ 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 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/3 Marius Vollmer : > ext Ed Bartosh writes: > >> 2009/11/3 Marius Vollmer : >>> ext Ed Bartosh 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/3 Marius Vollmer : > ext Ed Bartosh 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 : > ext Graham Cobb writes: > >> On Monday 02 November 2009 12:16:57 Ed Bartosh wrote: >>> 2009/11/2 Marius Vollmer : >>> > 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 Graham Cobb : > On Monday 02 November 2009 12:16:57 Ed Bartosh wrote: >> 2009/11/2 Marius Vollmer : >> > 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: Autobuilder repository priority ?
2009/11/3 Graham Cobb : > 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 : >> >> 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/2 Marius Vollmer :
> [ 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 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
* 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
Re: maemo-optify, autobuilder & /opt
2009/11/2 Marius Vollmer : > ext Graham Cobb writes: > >> On Thursday 29 October 2009 11:12:45 Marius Vollmer wrote: >>> ext Alberto Mardegan 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/.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 : > ext Ed Bartosh 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 : > ext Ed Bartosh 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: Autobuilder repository priority ?
2009/11/2 Jeremiah Foster : > > On Nov 1, 2009, at 18:05, Ed Bartosh wrote: > >> 2009/11/1 Attila Csipa : >>> 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 Andrew Flegg : > Ed wrote: >> 2009/11/2 Marius Vollmer : >> >> > 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: maemo-optify, autobuilder & /opt
2009/11/2 Marius Vollmer : > ext Ed Bartosh 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/1 Graham Cobb : > 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/11/1 Attila Csipa : > 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/10/29 Graham Cobb : > 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/10/31 Attila Csipa : > 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: Autobuilder repository priority ?
2009/11/1 Attila Csipa : >> >> 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 : > 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: Autobuilder repository priority ?
2009/10/31 Attila Csipa : > 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: maemo-optify, autobuilder & /opt
2009/10/29 Marius Vollmer : > ext Andrew Flegg 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/29 Andrew Flegg : > Ed wrote: >> 2009/10/29 Graham Cobb : >> > >> > 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 Graham Cobb : > 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 Graham Cobb : > 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: maemo-optify, autobuilder & /opt
2009/10/28 Andrew Flegg : > 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/28 Andrew Flegg : > 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: Error installing optified packages in Fremantle SDK
2009/10/27 Luca Donaggio : > 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: How to find the author of a git commit?
2009/10/26 Alberto Mardegan : > 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 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: Error installing optified packages in Fremantle SDK
2009/10/26 Luca Donaggio : > On Mon, Oct 26, 2009 at 4:40 PM, Ed Bartosh wrote: >> >> 2009/10/26 Luca Donaggio : >> > 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: Error installing optified packages in Fremantle SDK
2009/10/26 Luca Donaggio : > 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 : > 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: Maemo-Optify & Builder Bots = Broken?
2009/10/24 Graham Cobb : > On Sat, Oct 24, 2009 at 11:03:18AM +0300, Ed Bartosh wrote: >> 2009/10/24 Graham Cobb : >> > 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/24 Graham Cobb : > > 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//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/22 Julius Luukko : > > 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: AutoBuilders ignoring a depenancy
2009/10/22 Nathan Anderson : > Ed, > >I resubmitted my package; and it decided to ignore one of my > dependency. (But it did pull in the optified packages! ) > > 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: QA queue determine required thumbs down for removal
2009/10/22 Niels Breet : > 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: 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 : > Hi, > > Please read my last message. The issue is fixed. Nobody should do > anything except of SDK guys. > > 2009/10/22 Kamen Bundev : >> 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 >> 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 wrote: >>>> >>>> Nah, that's not enough. Still fails. >>>> >>>> Regards: >>>> Bundyo >>>> >>>> On Thu, Oct 22, 2009 at 12:52 AM, Kamen Bundev 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 >>>>> 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 : >>>>>> > Ed, >>>>>> > >>>>>> >Sure can (and following the chain). >>>>>> > >>>>>> > ls -l / | grep opt >>>>>> >lrwxrwxrwx1 root root 18 Oct 6 22:36 opt -> >>>>>> > /targets/links/opt >>>>>>
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 : > 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 > 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 wrote: >>> >>> Nah, that's not enough. Still fails. >>> >>> Regards: >>> Bundyo >>> >>> On Thu, Oct 22, 2009 at 12:52 AM, Kamen Bundev 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 >>>> 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 : >>>>> > 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//opt is a directory. In >>>>> autobuilder >>>>> environment it's a symlink: >>>>> >>>>> > ls -l /targets/maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c/ >>>>> > |grep opt >>>>> lrwxrwxrwx 1 builder1 build
Re: Maemo-Optify & Builder Bots = Broken?
2009/10/22 Kamen Bundev : > 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?
2009/10/21 Nathan Anderson : > 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//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 is in rootstraps. Tell me which rootstrap do you use and I'll compare it with the one autobuilder uses. -- 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 : > 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: Maemo-Optify & Builder Bots = Broken?
2009/10/21 Nathan Anderson : > 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 : > 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 : ... > 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: 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 : > 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 : > 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 : > 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 : > > 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 : > ext Ed Bartosh 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: Autobuilder: building svn tags from garage
2009/8/31 Marius Vollmer : > ext Ed Bartosh 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 comments&suggstions. 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: 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 : > 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
