from:"Ed Bartosh"

2010/1/26 Jeremiah Foster jerem...@jeremiahfoster.com:

 On Jan 25, 2010, at 22:27, Ed Bartosh wrote:

 2010/1/25 Jeremiah Foster jerem...@jeremiahfoster.com:

 There are other build tools which are better documented and more flexible 
 than sdbmock. Debian has a complete toolchain which is obviously good at 
 building debs and is completely open and well supported.

 Interesting. Can you point me out to the one, which supports scratchbox?

 Why do you need scratchbox to build debs? Why not just use the debian 
 toolchain? I know you don't want to learn perl, but hey, it works for debian.

Funny. Rebuilding with crosscompilation toolchain is better approach
or course, but I doubt that it's easy doable for Maemo packages. It
would require changes in big amount of packages.
If you're brave enough you can try it. Just let me know and I will
stop supporting current solution.

Even not considering above you might notice, that Maemo SDK is based
on scratchbox. So, second answer is 'Because Maemo SDK and all
developers use it'.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Build Server Configuration

2010/1/26 Jeff Moe m...@blagblagblag.org:
 On Monday 25 January 2010 15:02:57 Ed Bartosh wrote:
 [chop]
 # Additional apt-get parameters
 config_opts['apt-get_options'] = '-o APT::Get::AllowUnauthenticated=1'

 # Command to run after rootstrap unpacking
 config_opts['after_rootstrap'] = 'fakeroot apt-get -y -q %s install
 maemo-optify' % config_opts['apt-get_options']

 I'm building fine in sbdmock unless the package calls maemo-optify. I don't 
 see where after_rootstrap occurs in sbdmock, so I think that above `apt-get 
 install` isn't being run (maemo-optify doesn't get installed in the chroot). 
 How are you getting maemo-optify installed in every chroot?

I'm using sbdmock with corresponding change. You can find it here:
http://github.com/bartosh/sbdmock/tree/after_rootstrap
The change was discussed with upstream author and merge request has
been sent to him some time ago. It's not merged in his gir repo yet,
but I hope it will be eventually.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Build Server Configuration

2010/1/26 Jeremiah Foster jerem...@jeremiahfoster.com:

 On Jan 26, 2010, at 9:43 AM, Ove Kaaven wrote:

 Jeremiah Foster skrev:
 On Jan 25, 2010, at 22:27, Ed Bartosh wrote:

 2010/1/25 Jeremiah Foster jerem...@jeremiahfoster.com:
 There are other build tools which are better documented and more flexible 
 than sdbmock. Debian has a complete toolchain which is obviously good at 
 building debs and is completely open and well supported.
 Interesting. Can you point me out to the one, which supports scratchbox?

 Why do you need scratchbox to build debs? Why not just use the debian 
 toolchain? I know you don't want to learn perl, but hey, it works for 
 debian.

 The Debian tools are not really designed for cross-compilation, they're
 meant to run inside the target environment.

 Yeah, this seems to be the key differentiator between Maemo's build system 
 and Debian's. Still, there was a SoC project last year in which we could have 
 participated to help shape the debian build process to more closely match 
 Maemo's. No one was interested.

 That target environment also
 needs a full complement of Debian tools, including compilers. The reason
 it works for Debian is because they have a LARGE farm of dedicated,
 donated machines of various architectures: http://db.debian.org/machines.cgi

 I find it fascinating that a Free Software operating system, without a very 
 formal form of governance, without any assets of its own aside from SIP, run 
 completely by volunteers, has a larger build farm than the world's leading 
 handset manufacturer.
You're confusing Maemo and Nokia here. First, you most probably don't
know how big farm Nokia uses internally.
And, second, because of not using native compilation current Maemo
build infrastructure is more than enough for what it does.
However nothing prevents nobody to donate maney or computers for
extending existing buildfarm. Maemo is free project, isn't it?

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Build Server Configuration

2010/1/26 Jeremiah Foster jerem...@jeremiahfoster.com:

 What about tools like qemu and dpkg-cross? Can't they be used to build debs 
 without scratchbox?
 And my goal is not to necessarily get rid of scratchbox, but rather enable 
 alternatives to the current build toolchain.

I still don't understand what's so bad with current toolchain and
autobuilder? I'm asking not just out of curiosity, but because right
now I have some free time and I'm going to spend it to improve
autobuilder.
My plan I was to implement the following features:
- support for multiple packages builds
- parallel package builds
- improvements for external checks
- support for building tags from garage VCS(svn and git)

So, if it's not needed and community tends to switch to another build
system I'd rather do something more useful.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Build Server Configuration

2010/1/26 Jeremiah Foster jerem...@jeremiahfoster.com:

 What about tools like qemu and dpkg-cross? Can't they be used to build debs 
 without scratchbox?
 And my goal is not to necessarily get rid of scratchbox, but rather enable 
 alternatives to the current build toolchain.

 I still don't understand what's so bad with current toolchain and
 autobuilder? I'm asking not just out of curiosity, but because right
 now I have some free time and I'm going to spend it to improve
 autobuilder.
 My plan I was to implement the following features:
 - support for multiple packages builds
 - parallel package builds
 - improvements for external checks
 - support for building tags from garage VCS(svn and git)

 So, if it's not needed and community tends to switch to another build
 system I'd rather do something more useful.

 Personally I think it is highly useful the work you do.

Thank you.

 What I see as the bottleneck is the political aspect, not the technical 
 aspect.

 Having alternative build environments frees us from having to rely on one 
 autobuilder, one build machine, one process. If we could let in more 
 community resources either through replication or distribution I think we can 
 ease developers lives when the ISP fails to keep the autobuilder up. I 
 realize that we again reach the limit that in order to build, we need 
 proprietary software / tools / blobs so it will be impossible to replicate 
 the current build toolchain, but having an independent, community managed (or 
 assisted) build toolchain would seem to me useful and a worthy goal.

I don't see that community should switch to another build system just
because Maemo server infrastructure hosted on non-reliable ISP. From
my point of veiw these 2 things are not related at all.
All build tools are open. If community don't like this ISP and has
ability to switch to alternative one it can move all infrastructure
there. It has nothing to do with the changing build system.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Build Server Configuration

2010/1/26 Anderson Lizardo anderson.liza...@openbossa.org:
 On Tue, Jan 26, 2010 at 8:05 AM, Ed Bartosh bart...@gmail.com wrote:
 - support for building tags from garage VCS(svn and git)

 Would be nice to also allow fetching code from external VCS hosting
 services (gitorious for instance). Is that feasible? Maybe using the
 Vcs-* fields line in Debian?)

The reason why I'm planning to implement it only for garage projects
is that I can use push method instead of polling.
For garage it can be easy done by developing svn/git hooks. For
external vcs it's harder. Fetching sources from there is also more
time consuming than from garage.

I'm not trying to say that it doesn't make sense to implement. Just
want to start with easy task :)
Let's see how this feature is used among developers first and then
decide if we need to go further in this direction or not.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Build Server Configuration

2010-01-25 Thread Ed Bartosh

2010/1/25 Jeremiah Foster jerem...@jeremiahfoster.com:

 There are other build tools which are better documented and more flexible 
 than sdbmock. Debian has a complete toolchain which is obviously good at 
 building debs and is completely open and well supported.

Interesting. Can you point me out to the one, which supports scratchbox?

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Build Server Configuration

2010-01-25 Thread Ed Bartosh

2010/1/25 Jeff Moe m...@blagblagblag.org:
 On Saturday 23 January 2010 04:07:48 you wrote:
 BTW, what do you think about to prepare guide for developers for easy
 setup of local buld configurations identical to autobuilder ones? I
 can provide whatever information you need for that.

 Ok, I pushed my first successful package throught sdbmock armel extras-devel. 
 The preliminary config files for the server are in the git repo, browsable 
 here:
 http://gitorious.org/freemoe/freemoe/trees/master/servers/obra

 Also, can you give me an i386 example?

Here you go:

#!/usr/bin/python -tt

# Scratchbox target name
config_opts['sbtarget'] = 'maemo5-i386'

# Target settings. Used if invoked with -u flag
config_opts['cputransparency-method'] = None # or none
config_opts['compiler-name'] = 'cs2007q3-glibc2.5-i486'
config_opts['devkits'] = 'perl:debian-lenny:doctools:svn:git'
#config_opts['devkits'] = 'perl:debian-etch:doctools:svn:git:apt-https'

config_opts['dpkg-buildpackage'] = 'dpkg-buildpackage -rfakeroot
-eAutomatic Builder buil...@maemo.org -sa -D'

# Additional apt-get parameters
config_opts['apt-get_options'] = '-o APT::Get::AllowUnauthenticated=1'

# Command to run after rootstrap unpacking
config_opts['after_rootstrap'] = 'fakeroot apt-get -y -q %s install
maemo-optify' % config_opts['apt-get_options']

# Location of rootstrap
#
# You can specify local path to file
# example 1: archive located in /scratchbox/packages :
#  config_opts['rootstrap']=maemo-sdk-rootstrap_4.0_i386.tgz
#
# example 2: archive from original site
#  
config_opts['rootstrap']=http://repository.maemo.org/stable/chinook/i386/maemo-sdk-rootstrap_4.0_i386.tgz;
#
# example 3: custom location inside scratchbox:
#
#  
config_opts['rootstrap']=/home/user/rootstraps/maemo-sdk-rootstrap_4.0_i386.tgz
#
config_opts['rootstrap']=/scratchbox/packages/maemo-sdk-rootstrap_5.0_i386.tgz
#config_opts['rootstrap']=/scratchbox/packages/maemo-sdk-rootstrap_5.0_i386_update1.tgz

config_opts['sources.list'] = 
# Official SDK repositories:
#deb http://stage/ fremantle/sdk free non-free
#deb http://stage/ fremantle/tools free non-free

#revert PR1.1 because of backwards compatibility issue 2010-01-19 -Niels

deb file:/scratchbox/packages/maemo5.0_update1_public/ fremantle/sdk
free non-free
deb file:/scratchbox/packages/maemo5.0_update1_public/ fremantle/tools
free non-free

# Development Extras repositories:
deb http://repository.maemo.org/extras-devel/ fremantle free non-free

# Nokia binaries
deb file:/scratchbox/packages/maemo-sdk-nokia-binaries_5_update1
fremantle explicit


# Following example should be safe for most cases (resolver*.opendns.com)
# If not specified, content of host's /etc/resolv.conf used.
#config_opts['files']['/etc/resolv.conf'] = 
#search maemo.org
#nameserver 208.67.222.222
#nameserver 208.67.220.220
#

# Special hacks to /host_usr/bin
# This will automatically add export PATH=/host_usr/bin:$PATH
# and redirection of binary from /usr/bin/binname to /host_usr/bin/binname
config_opts['host_usr']['gconftool-2'] = #!/bin/sh
export SBOX_REDIRECT_IGNORE=/usr/bin/gconftool-2
export GCONF_CONFIG_SOURCE=`/usr/bin/gconftool-2 --get-default-source`
/usr/bin/gconftool-2 --config-source $GCONF_CONFIG_SOURCE --direct $@


config_opts['env']['DEB_BUILD_OPTIONS']=parallel=4

config_opts['env']['TMP']=/var/tmp
config_opts['env']['TEMP']=/var/tmp
config_opts['env']['TMPDIR']=/var/tmp
#config_opts['env']['http_proxy']=http://proxy.dmz:3128;


 How about scripts that process incoming jobs, etc?
You can find current production version of buildme (builder for Maemo
Extras) here:
https://garage.maemo.org/plugins/scmsvn/viewcvs.php/tags/buildme/1.5.1/?root=extras-cauldron

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Build Server Configuration

2010-01-23 Thread Ed Bartosh

2010/1/23 Jeff Moe m...@blagblagblag.org:
 Could the configuration files of the build server and related scripts be put 
 up on the wiki or mailed here or something?

 I had a build fail due to a small difference between the SDK and the 
 buildbox. I would like to be able to have an identical setup to the build box 
 before submitting jobs.

It doesn't differ too much from what I showed in December[1]

The only valuable difference I can see is that SDK have been changed.
 # Official SDK repositories:
-deb http://repository.maemo.org/ fremantle/sdk free non-free
-deb http://repository.maemo.org/ fremantle/tools free non-free
+#deb http://stage/ fremantle/sdk free non-free
+#deb http://stage/ fremantle/tools free non-free
+
+#revert PR1.1 because of backwards compatibility issue 2010-01-19 -Niels
+
+deb file:/scratchbox/packages/maemo5.0_update1_public/ fremantle/sdk
free non-free
+deb file:/scratchbox/packages/maemo5.0_update1_public/
fremantle/tools free non-free

As you can see from the comment Niels did this change.

BTW, what do you think about to prepare guide for developers for easy
setup of local buld configurations identical to autobuilder ones? I
can provide whatever information you need for that.

[1] http://lists.maemo.org/pipermail/maemo-developers/2009-December/023162.html

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Maemo extras repository package uploader/maintainer verification?

2010-01-22 Thread Ed Bartosh

2010/1/22 Andrew Flegg and...@bleb.org:
 On Fri, Jan 22, 2010 at 12:59, Simon Pickering s.g.picker...@bath.ac.uk 
 wrote:

 I'd suggest that the autobuilder checks to see that the uploader's email
 address is included in one of the *Maintainer fields; but there is the
 slight problem of what happens when someone is uploading someone else's
 package (e.g. as a favour when they are away from a build machine)?

 There's also packages which are maintained by a team but uploaded by
 an individual.

And there are also packages taken from Debian/Ubuntu and uploaded
without any change.
I don't think we should stop them from coming. It's possible to find
real uploader name in autobuilder logs and might be in the /packages
web UI as well.
Bringing new checks like this to the system wouldn't make entrance
barrier lower for newcomers.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: SDK rootstraps updated

2010-01-18 Thread Ed Bartosh

2010/1/18 Graham Cobb g+...@cobb.uk.net:
 On Monday 18 January 2010 14:08:07 Jeff Moe wrote:
 Take note, since the service restoration, the Maemo 5 SDK rootstraps have
 been (silently?) updated with no changes to timestamps:

 Thanks Jeff for noticing this.

 Niels or Ed, do you have any idea what has happened here?

Unfortunately I'm not aware of any changes.
And autobuilder still uses old SDK rootstraps unless Niels or other
admins did something.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Promotion to extras

2010-01-11 Thread Ed Bartosh

2010/1/11 Valerio Valerio vdv...@gmail.com:
 Hi,

 On Mon, Jan 11, 2010 at 8:17 PM, ds d...@physik.de wrote:

 Hello,

 some weeks ago I promoted to extras. I could not find any changes.

 I have Karma 11 in extras testing: Why is there not promotion link now?

 The packages have to pass 10 days of quarantine[1] in testing before the
 promotion link appears.

According to this: http://maemo.org/packages/view/vncviewer/ latest
version of packages was not even promoted to testing.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Autobuilder is broken again

2010-01-09 Thread Ed Bartosh

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-01-03 Thread Ed Bartosh

2010/1/3 Andrew Flegg and...@bleb.org:
 On Sun, Jan 3, 2010 at 15:39, Jeremiah Foster
 jerem...@jeremiahfoster.com wrote:
 On Jan 2, 2010, at 21:54, Andrew Flegg wrote:

 For the record, you don't even need to do that now. All you need to do
 is opt-in to the autobuilder doing optification for you, by putting
 the single word 'auto' in a new file: debian/optify.

 To stay abreast of these changes it would be great if we had a
 canonical document about this [...]

 Agreed. Someone needs to take ownership not just of the technical
 changes (which have been coordinated between Ed  Marius so far,
 AFAICT) but also the communication and education of developers.

 I am happy to add information there from disparate sources but if
 there is already a canonical source I'll copy that.

 I'm not aware of any documentation - nor what Ed  Marius' current
 timescales are.


I'll definitely find a time to do whatever is needed. Moreover, I was
asking couple of times already if it's time to enable optification by
default in autobuilder. I was given an answer that some testing is
still needed. I think Marius should know the latest status.

PS: Last news about optification for me was a discusstion about python
 maemo-optify [1] last month.

[1] http://lists.maemo.org/pipermail/maemo-developers/2009-December/022782.html

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Autobuilder apt-get problems = failing builds

2010/1/1 Andrew Flegg and...@bleb.org:
 Hi,

 Attempting to upload a new version of vim to the Fremantle
 auto-builder, I get the following failure:


 https://garage.maemo.org/builder/fremantle/vim_7.2-0maemo6/armel.root.log.FAILED.txt

Should be fixed now: https://garage.maemo.org/builder/fremantle/vim_7.2-0maemo6/
Thanks for pointing out to this.

Somebody's changed sbdmock configuration on the build host. I don't
know why, because it was working just fine before.

This reminds me aphorisms like 'Too many cooks spoil the broth' or
'Many commanders sink the ship. I like better Russian one 'Seven
babysitters have a child without eye'. Autobuilder reminds me that
child sometimes.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Autobuilder apt-get problems = failing builds

2010/1/1 Jeremiah Foster jerem...@jeremiahfoster.com:

 On Jan 1, 2010, at 15:00, Ed Bartosh wrote:

 2010/1/1 Andrew Flegg and...@bleb.org:
 Hi,

 Attempting to upload a new version of vim to the Fremantle
 auto-builder, I get the following failure:

   
 https://garage.maemo.org/builder/fremantle/vim_7.2-0maemo6/armel.root.log.FAILED.txt

 Should be fixed now: 
 https://garage.maemo.org/builder/fremantle/vim_7.2-0maemo6/
 Thanks for pointing out to this.

 Somebody's changed sbdmock configuration on the build host. I don't
 know why, because it was working just fine before.

 This reminds me aphorisms like 'Too many cooks spoil the broth' or
 'Many commanders sink the ship. I like better Russian one 'Seven
 babysitters have a child without eye'. Autobuilder reminds me that
 child sometimes.

 Funny, I was thinking the exact opposite. If more people had access, then 
 more than one person could fix it.


I doubt that. What I can see is that more people can break it.
If you need a proof - give everyone root access to that box :)

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Autobuilder apt-get problems = failing builds

2010/1/1 Jeff Moe m...@blagblagblag.org:
 On Friday 01 January 2010 11:12:47 Ed Bartosh wrote:
 2010/1/1 Jeremiah Foster jerem...@jeremiahfoster.com:
  On Jan 1, 2010, at 15:00, Ed Bartosh wrote:
  2010/1/1 Andrew Flegg and...@bleb.org:
  Hi,
 
  Attempting to upload a new version of vim to the Fremantle
  auto-builder, I get the following failure:
 
 
  https://garage.maemo.org/builder/fremantle/vim_7.2-0maemo6/armel.root.l
 og.FAILED.txt
 
  Should be fixed now:
  https://garage.maemo.org/builder/fremantle/vim_7.2-0maemo6/ Thanks for
  pointing out to this.
 
  Somebody's changed sbdmock configuration on the build host. I don't
  know why, because it was working just fine before.
 
  This reminds me aphorisms like 'Too many cooks spoil the broth' or
  'Many commanders sink the ship. I like better Russian one 'Seven
  babysitters have a child without eye'. Autobuilder reminds me that
  child sometimes.
 
  Funny, I was thinking the exact opposite. If more people had access, then
  more than one person could fix it.

 I doubt that. What I can see is that more people can break it.
 If you need a proof - give everyone root access to that box :)

 Starting with me.  :)

 Though I must say things seem down an awfully lot and we just sit around
 waiting for someone to fix it. How does Fedora do it? I imagine they have a
 number of people with access.

OK, let's look at this particular case. Autobuilder was broken for
about 15 hours. There were about 40 packages uploaded and failed
during that time. Before that change builder was working fine.

I really doubt that it would be better to have doesns of people to
break this than 1-2 to fix. Even if those who can breake it could fix
it.
Anyway it was not working for a long time and people became confused.
And now I'm restarting all those 40 builds manually.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Autobuilder apt-get problems = failing builds

2010/1/1 Ed Bartosh bart...@gmail.com:
 2010/1/1 Jeff Moe m...@blagblagblag.org:
 On Friday 01 January 2010 11:12:47 Ed Bartosh wrote:
 2010/1/1 Jeremiah Foster jerem...@jeremiahfoster.com:
  On Jan 1, 2010, at 15:00, Ed Bartosh wrote:
  2010/1/1 Andrew Flegg and...@bleb.org:
  Hi,
 
  Attempting to upload a new version of vim to the Fremantle
  auto-builder, I get the following failure:
 
 
  https://garage.maemo.org/builder/fremantle/vim_7.2-0maemo6/armel.root.l
 og.FAILED.txt
 
  Should be fixed now:
  https://garage.maemo.org/builder/fremantle/vim_7.2-0maemo6/ Thanks for
  pointing out to this.
 
  Somebody's changed sbdmock configuration on the build host. I don't
  know why, because it was working just fine before.
 
  This reminds me aphorisms like 'Too many cooks spoil the broth' or
  'Many commanders sink the ship. I like better Russian one 'Seven
  babysitters have a child without eye'. Autobuilder reminds me that
  child sometimes.
 
  Funny, I was thinking the exact opposite. If more people had access, then
  more than one person could fix it.

 I doubt that. What I can see is that more people can break it.
 If you need a proof - give everyone root access to that box :)

 Starting with me.  :)

 Though I must say things seem down an awfully lot and we just sit around
 waiting for someone to fix it. How does Fedora do it? I imagine they have a
 number of people with access.

 OK, let's look at this particular case. Autobuilder was broken for
 about 15 hours. There were about 40 packages uploaded and failed
 during that time. Before that change builder was working fine.

Sorry, I was wrong. It was down for about 24 hours and there were
about 50 failed package builds.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

How to switch hardware keyboard language?

2009-12-27 Thread Ed Bartosh

Hi,

Does anybody know how to get current hw keyboard language and how to
switch between them programmatically?

Here is what I did so far:
1. I could get list of configured layouts by reading gconf variables
/apps/osso/inputmethod/int_kb_layout and
/apps/osso/inputmethod/ext_kb_layout
2. setxkbmap -layout layout allowed me to switch keyboard layout to
layout. However, it worked quite funny way.
For example if I have English and Russian (us and ru layouts)
configured and English layout active(I can type English) after running
setxkbmap -layout ru sometimes I can type Russian, sometimes I can't!
But if I have Russian layout active and run setxkbmap -layout us it
always switches layout to English, but I can't switch it back to
Russian by pressing Ctrl+Space (or Ctrl+Chr on N810).
3. My attempts to get any info using xkb calls XkbRF_GetNamesProp,
XkbGetState didn't help much. Both calls return the same info
regardless of which layout is active.
4. I was able to switch layouts using XkbRF_SetNamesProp, but it
worked pretty much like setxkbmap.
5. It's also possible to switch layout by setting gconf variable
/apps/osso/inputmethod/int_kb_layout, but if I set it to 'us' it also
stops switching by Ctrl-Space even if I set
/apps/osso/inputmethod/ext_kb_layout to 'ru'

After doing above exercises I came to conclusion that I'm going wrong
way and setting xkb map isn't a proper way to switch languages on
Maemo. After reading sources of several desktop language switchers. I
also understood that xkb extension works differently on Maemo. Bugs
2501 and 3407 from Maemo bugzilla made me think that something might
be even broken in xkb internals. I gave up when I read this in the bug
2501: The Ctrl+Space on languages other than Russian changes the
input language, not the keyboard layout. At that point I was totally
confused and decided to write this email.

Can anybody help me with this?

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: How to switch hardware keyboard language?

2009-12-27 Thread Ed Bartosh

2009/12/27 Arkadiy Glazov uglobs...@gmail.com:
 Hi,

 Look the head of file /usr/share/X11/xkb/symbols/nokia_vndr/rx-51 and see 
 some answers :)
I can't see any answers there, only new questions :(

 Also I wrote package xkblayouts-rx51-ru that set russian phonetic hardware 
 layout. You can look Perl script /usr/bin/xkbcustom after install. I use 
 setxkbmap for determinate and switch keyboard layout

As I understood from your code(I'm not good at Perl though) you're
just reloading xkb map using setxkbmap utility.
What I'm looking for is how to get the current language and how to
switch between them. I've looked into setxkbmap sources and tried to
use it. It didn't work for me, as I explained in my first email.

Answering two simple questions would help a lot:
1. How to determine which language is active at the moment?
2. How to switch between them?
This is pretty much all I want to know :)

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Auto builder - Maemo-Optify

2009/12/24 Benoît HERVIER kher...@khertan.net:
 So now maemo optify is automatically added on extras builder ?

It was added lont time ago and discussed in details on this mailing list.

 Seems to have some problems :
 https://garage.maemo.org/builder/fremantle/python2.5-py2deb_0.5.3-1/

Definitely. Check your debian/control and remove empty line between
XSBC-Bugtracker and XB-Maemo-Icon-26 lines.

 Get:1 http://repository.maemo.org fremantle/free maemo-optify 0.2 [5664B]
 /scratchbox/tools/bin/sh: line 1: /usr/sbin/dpkg-preconfigure: No such file
 or directory

 Is there a way to unactivate it ?

Why? It doesn't do anything unless explicytly asked.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Auto builder - Maemo-Optify

2009/12/24 Andrew Flegg and...@bleb.org:
 2009/12/24 Benoît HERVIER kher...@khertan.net:
 So now maemo optify is automatically added on extras builder ?

 Is it? Are Ed/Marius around to confirm?

Yes it was. Long time ago, as we all agreed, with 'none' as default.

 Is there a way to unactivate it ?

 Put none in debian/optify:

It's not needed. The problem is not in autobuilder, but in the package.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Auto builder - Maemo-Optify

2009/12/24 Andrew Flegg and...@bleb.org:
 On Thu, Dec 24, 2009 at 12:22, Ed Bartosh bart...@gmail.com wrote:

 Bug #7309 is still valid, of course, and can be used as the hook in
 which the Python-based heuristics for maemo-optify are done.

 No, it's not valid.
 I think everyone's seen this message:
 /usr/sbin/dpkg-preconfigure: No such file or directory and it's not
 related to the package being installed. Moreover it's not en error.

 The initial assumptions underlying the report were invalid; however
 the fact that maemo-optify is not yet aware of pymaemo-optify (AFAIK)
 IS a bug. Resolve #7309 as invalid and raise another one if you like,
 but that seems like a bit too much work for work's sake to me.

It's just ridiculous to have bug against autobuilder about
maemo-optify is not taking care of build dependency to pymaemo-optify
considering the fact that at the moment maemo-optify doesn't even try
to do anything unless it founds debian/optify file with the line
'auto' inside it.
Of course it's invalid and confusing.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Auto builder - Maemo-Optify

2009/12/24 David Greaves da...@dgreaves.com:

 Ed... 2 questions:
 1. are you happy that /usr/sbin/dpkg-preconfigure: No such file or directory
 is a bug (as you said a couple of emails back)?
Yes, I am.

 2. what section do you think the bug should be against?

Product: Development Platform
Component: SDK

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: sbdmock sample config

2009-12-23 Thread Ed Bartosh

2009/12/23 Jeff Moe m...@blagblagblag.org:
 Can anyone provide me with sample configs for sbdmock and fremantle? Like a 
 file
 like this?

 ~/.sbdmock/maemo-fremantle-armel-extras-devel.cfg

Please, find it attached.
BTW, it would be great if somebody added Fremantle configuration to this wiki:
http://wiki.maemo.org/Building_packages_with_sbdmock

 I think I'm most of the way there, just having some issues with updating the
 config.

 Also, debian lenny doesn't have python-pip so I made a package, if anyone
 needs it:

 http://www.freemoe.org/users/jebba/lenny/binary-i386/python-
 pip_0.6.1-2_all.deb

 http://www.freemoe.org/users/jebba/lenny/source/python-pip_0.6.1-2/

How is it related to the topic?

-- 
BR,
Ed


maemo-fremantle-armel-extras-devel.cfg
Description: Binary data
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: sbdmock sample config

2009-12-23 Thread Ed Bartosh

2009/12/23 Jeff Moe m...@blagblagblag.org:
 On Wednesday 23 December 2009 06:38:11 you wrote:
 2009/12/23 Jeff Moe m...@blagblagblag.org:
  Can anyone provide me with sample configs for sbdmock and fremantle? Like
  a file like this?
 
  ~/.sbdmock/maemo-fremantle-armel-extras-devel.cfg

 Please, find it attached.
 BTW, it would be great if somebody added Fremantle configuration to this
  wiki: http://wiki.maemo.org/Building_packages_with_sbdmock

 Great! Thanks. Won't be able to test it til Monday though.

  I think I'm most of the way there, just having some issues with updating
  the config.
 
  Also, debian lenny doesn't have python-pip so I made a package, if anyone
  needs it:
 
  http://www.freemoe.org/users/jebba/lenny/binary-i386/python-
  pip_0.6.1-2_all.deb
 
  http://www.freemoe.org/users/jebba/lenny/source/python-pip_0.6.1-2/

 How is it related to the topic?

 Per the wiki:
 http://wiki.maemo.org/Building_packages_with_sbdmock

 Do:
 sudo aptitude install git-core python-pip python-setuptools python-virtualenv

 pip install -E sbdmock minideblib
 pip install -E sbdmock -e git://github.com/kad/sbdmock.git#egg=sbdmock

 I tried to find an equivalent, but in the end it wound up faster just
 rebuilding the package and it worked fine.

The equivalent in your case is much more easier and safer.
What you need is to build sbdmock and minideblib Debian packages and
install them.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Issues with autobuilder x86 bison

2009-12-16 Thread Ed Bartosh

2009/12/16 Antonio Aloisio antonio.aloi...@gmail.com:
 Hi,
 I've some problem building jam into the autobuilder for X86... and I can't
 understand where is the problem.
 I'm able to build it for both architectures on my Maemo5 SDK.
Most probably you've installed bison in your environment from
Fremantle SDK repo.
If you remove it you can reproduce the failure. In this case bison
from scratchbox (/scratchbox/tools/bin/bision) is used.

 Bison looks to work fine in ARMEL but it fails with the following error in
 X86:

 /scratchbox/tools/bin/bison: I/O error

 Complete log is here [1].

 Any hints?

Adding build dependency to bison version from sdk repo 'bison (=
1:1.875d-1osso2)' should help.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Build-Depends for several Maemo versions

2009-12-11 Thread Ed Bartosh

2009/12/11 David Greaves da...@dgreaves.com:
 On Fri, 2009-12-11 at 14:34 +0100, Cornelius Hald wrote:
 What am I missing?

 In the general sense: A way to specify per-build-target .dsc files (for
 pre-calculation of the build-deps  setup of the chroot

Well, I investigated this issue using sbdmock
conboy-unstable_0.6.1.6.dsc -r maemo-diablo-armel-extras-devel -u init
--debug
It showed everything I needed and did pretty much what you've mentioned.
Here is the quote from its output:
[2009-12-11 18:31:28] DEBUG: Executing(scratchbox) cd
/home/ed/maemo-diablo-armel-extras-devel/work  dpkg-source -x
conboy-unstable_0.6.1.6.dsc
[2009-12-11 18:31:47] DEBUG: Return status: 0
[2009-12-11 18:31:47] DEBUG: Checking build-deps first time
[2009-12-11 18:31:47] DEBUG: Checking dependencies ...
[2009-12-11 18:31:47] DEBUG: Executing(scratchbox) cd
/home/ed/maemo-diablo-armel-extras-devel/work/conboy-unstable-0.6.1.6
 dpkg-checkbuilddeps
[2009-12-11 18:33:47] DEBUG: Return status: 0
[2009-12-11 18:33:47] DEBUG: Unment build dependencies: intltool
libhildon1-dev libosso-dev libgconf2-dev libxml2-dev libjson-glib-dev
osso-af-settings libcurl3-dev liboauth-dev libssl-dev
tablet-browser-interface-dev mce-dev libpcre3-dev libhildonmime-dev
libgda3-dev
[2009-12-11 18:33:47] DEBUG: Builddeps: 'intltool libhildon1-dev
libosso-dev libgconf2-dev libxml2-dev libjson-glib-dev
osso-af-settings libcurl3-dev liboauth-dev libssl-dev
tablet-browser-interface-dev mce-dev libpcre3-dev libhildonmime-dev
libgda3-dev'
[2009-12-11 18:33:47] DEBUG: apt: command fakeroot apt-get -y -q -o
APT::Get::AllowUnauthenticated=1 install --no-remove intltool
libhildon1-dev libosso-dev libgconf2-dev libxml2-dev libjson-glib-dev
osso-af-settings libcurl3-dev liboauth-dev libssl-dev
tablet-browser-interface-dev mce-dev libpcre3-dev libhildonmime-dev
libgda3-dev /dev/null
[2009-12-11 18:33:47] DEBUG: Executing(scratchbox) fakeroot apt-get -y
-q -o APT::Get::AllowUnauthenticated=1 install --no-remove intltool
libhildon1-dev libosso-dev libgconf2-dev libxml2-dev libjson-glib-dev
osso-af-settings libcurl3-dev liboauth-dev libssl-dev
tablet-browser-interface-dev mce-dev libpcre3-dev libhildonmime-dev
libgda3-dev /dev/null

After it finished I was able to run scratchbox, go to the directory
with unpacked source package and investigate this further.

BTW, the reason for the issue was using wrong syntax for versioning
dependencies in the control file. Instead of using ( 4.1) Cornelius
was using ( 4.1).

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: maemo-optify, autobuilder /opt

2009-12-02 Thread Ed Bartosh

2009/11/9 Marius Vollmer marius.voll...@nokia.com:

 When autobuilder expected to start to optify packages without
 debian/optify in them?

 I don't know.  We certainly need to tune the heuristic of maemo-optify
 first to handle Python.

As far as I see Python is optified now. When we should do next step?

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: maemo-optify, autobuilder /opt

2009-12-02 Thread Ed Bartosh

2009/12/2 Anderson Lizardo anderson.liza...@openbossa.org:
 On Wed, Dec 2, 2009 at 9:02 AM, Ed Bartosh bart...@gmail.com wrote:
 2009/11/9 Marius Vollmer marius.voll...@nokia.com:

 When autobuilder expected to start to optify packages without
 debian/optify in them?

 I don't know.  We certainly need to tune the heuristic of maemo-optify
 first to handle Python.

 As far as I see Python is optified now. When we should do next step?

 Correct. But, in Python's case, we didn't add such debian/optify file,
 and we relied on the fact that the (current) default optify policy was
 none.

 If you have plans to begin enabling auto-optification by default,
 please inform us here on the list so we can begin adding the
 debian/optify file to avoid optifying packages that were manually
 optified  by other means (e.g. python packages).


I hope you'll see everything in this thread.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: maemo-optify, autobuilder /opt

2009-11-09 Thread Ed Bartosh

2009/11/9 Marius Vollmer marius.voll...@nokia.com:

 When autobuilder expected to start to optify packages without
 debian/optify in them?

 I don't know.  We certainly need to tune the heuristic of maemo-optify
 first to handle Python.

Just in case you need my help. I'm here for this week. My 2 weeks
vacation starts on Satuday.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: maemo-optify, autobuilder /opt

2009-11-08 Thread Ed Bartosh

2009/11/6 Marius Vollmer marius.voll...@nokia.com:
 ext Ed Bartosh bart...@gmail.com writes:

 I've discussed this with sbdmock author and we decided to make small
 change to sbdmock: New configurable action will be introduced. This
 action will be executed by sbdmock between unpacking rootstrap and
 installing build-deps.

 For Fremantle we can simply put 'apt-get install maemo-optify' in there.

 I'll try to make this change on weekends and deploy new sbdmock and
 devkit in production.

 Excellent, thanks!

Done.

Here you can see my test builds:
Fremantle builds:
without debian/optify: https://garage.maemo.org/builder/fremantle/sbdmock_0.4.4/
'auto' in debian/optify:
https://garage.maemo.org/builder/fremantle/sbdmock_0.4.4.optify/

Diablo build:
with 'auto' in debian/optify:
https://garage.maemo.org/builder/diablo/sbdmock_0.4.4/

Looking forward to your feedback and further instructions

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: maemo-optify, autobuilder /opt

2009-11-04 Thread Ed Bartosh

Hi,

2009/11/2 Ed Bartosh bart...@gmail.com:
 2009/11/2 Marius Vollmer marius.voll...@nokia.com:
 [ Jussi, we would like to get a new debian-etch devkit for Maemo 5 with
  the attached patch.  Please advise how to best go about this.
 ]

 ext Ed Bartosh bart...@gmail.com writes:

 I can also help with building devkit if needed.

 I didn't manage to get the devkit to compile (I didn't see a way to get
 it to not install into / during build), but I have a patch anyway
 (attached).

 You can learn how to do it here:
 http://scratchbox.org/documentation/docbook/devkit.html

 Here you can get result of my build(patch attached):
 https://garage.maemo.org/builder/scratchbox-devkit-debian_1.0.16-1.optify_i386.deb

Has anybody tried this devkit? Does it work as expected? Should we deploy it?

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: maemo-optify, autobuilder /opt

2009-11-04 Thread Ed Bartosh

2009/11/4 Marius Vollmer marius.voll...@nokia.com:
 ext Ed Bartosh bart...@gmail.com writes:

 Has anybody tried this devkit? Does it work as expected?

 I tried it by building (slightly modified versions of) xournal, hermes,
 and libliqbase, and everything went as expected.

Can you elaborate a bit? Is it implemented the way proposed by Andrew?

 The slight modification was echo auto debian/optify to turn on
 optification.
So, it doesn't do anything by default, right?


-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: maemo-optify, autobuilder /opt

2009-11-04 Thread Ed Bartosh

2009/11/4 Marius Vollmer marius.voll...@nokia.com:
 ext Ed Bartosh bart...@gmail.com writes:

 2009/11/3 Marius Vollmer marius.voll...@nokia.com:

 Luckily, with apt-get upgrade being run during build, we don't need
 to change dpkg-checkbuilddeps and we can just update build-essential.
 (Unless I am missing something. Do I?)

 rootstrap is used as a build-essentials by sbdmock. The initial idea
 was to put maemo-optify in there, but now we're trying to avoid that.

 Hmm, the rootstrap contains the build-essential package.  If we put a
 newer version of the build-essential package into extras-devel, then
 that newer version will be installed by 'apt-get upgrade'.

 If apt-get upgrade does indeed run during a build.  I no longer think it
 actually does.  Checking the build log of maemo-optify certainly shows
 no signs of running apt-get upgrade.

I'm sorry. This is my faul. I thought you're asking about 'apt-get
update'. sbdmock doesn't run 'apt-get upgrade', it just unpacks
rootstrap and installs build deps.


 https://garage.maemo.org/builder/fremantle/maemo-optify_0.1/i386.root.log.OK.txt

 Hmm, so is apt-get upgrade being executed at one point before calling
 dpkg-buildpackage?

 Yes it is.

 Cool, then that's our ticket to get maemo-optify into the build
 environment, I would say.

 The only problem left is were to put 'apt-get install' :)

 Which apt-get install?  We just add a dependency on maemo-optify to
 build-essential and apt-get upgrade does the rest.  No?

Sorry, but no.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Autobuilder repository priority ?

2009/11/3 Graham Cobb g+...@cobb.uk.net:
 On Monday 02 November 2009 21:52:48 Jeremiah Foster wrote:
 On Nov 2, 2009, at 10:27, Ed Bartosh wrote:
  2009/11/2 Jeremiah Foster jerem...@jeremiahfoster.com:
  On Nov 1, 2009, at 18:05, Ed Bartosh wrote:
  Idea of having separate queue for Extras updates sounds more
  promising
  to me. Developers might become confused with all this set of
  repositories, queues and processes, but the idea is good. I support
  this.
 
  What about this? Can we have separate queue for updates? Any other
  ideas?

 Can you explain how this might work and it's advantages? I am not
 against it aside from the fact that I think another repo is confusing.
 Is the proposal to create a repo called extras-updates which would
 hold only updates to software that has already existed in the repos? I
 don't see how that is different from just updating the existing
 package with new software. If you want to pull in different version
 numbers than what exists why would you need a separate repo?

 Sorry, like Jeremiah I am now a bit confused.  Can you, Ed, please summarise
 what this proposal is?  You mention separate queue but which queue are you
 referring to?  Does the suggestion involve additional repositories? And/or
 does it involve differnet rules for which repositories will be in scope
 during a build?  Or what.

As I understood Attila he proposed to create separate autobulder
incoming queue for Extras updates.
If packages are uploaded to this queue they're built using only Extras
and SDK repos and put into extras-devel.
As a result they won't depend on unstable packages from Extras-devel
and can go to extras-testing and then to Extras faster.

As I already mentioned I'm also a bit afraid of extra complexity and
possible confusion, but I think this idea at least worth to be
discussed.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: maemo-optify, autobuilder /opt

2009/11/3 Graham Cobb g+...@cobb.uk.net:
 On Monday 02 November 2009 12:16:57 Ed Bartosh wrote:
 2009/11/2 Marius Vollmer marius.voll...@nokia.com:
  The buildbot would need to run apt-get install maemo-optify at the
  right time.  Any idea of how to do that?

 Right way to do it is to include it into SDK rootstrap. Other ways I
 can think of look hackish.

 Can't we have the hacked dpkg-buildpackage add (if optification is turned on)
 maemo-optify to the build dependencies?  Then it will get installed
 automatically.

We can avoid changing rootstraps if we use this. The idea looks a bit
hackish, but I like it anyway.

 It is essential that it is in a repository (and preferably not the SDK
 repository -- I would like to see it in extras-devel) so that it can be
 updated very quickly if we need to fix bugs or change its behaviour.
 Particularly while Ed is on holiday!

It's already there:
http://repository.maemo.org/extras-devel/pool/fremantle/free/m/maemo-optify/


-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: maemo-optify, autobuilder /opt

2009/11/3 Marius Vollmer marius.voll...@nokia.com:
 ext Graham Cobb g+...@cobb.uk.net writes:

 On Monday 02 November 2009 12:16:57 Ed Bartosh wrote:
 2009/11/2 Marius Vollmer marius.voll...@nokia.com:
  The buildbot would need to run apt-get install maemo-optify at the
  right time.  Any idea of how to do that?

 Right way to do it is to include it into SDK rootstrap. Other ways I
 can think of look hackish.

 Can't we have the hacked dpkg-buildpackage add (if optification is turned on)
 maemo-optify to the build dependencies?

 No, dpkg-buildpackage does not install build dependencies, it just
 checks whether they are satisfied.

True. I've missed it, my bad.

We can hack dpkg-checkbuilddeps to unconditionally add maemo-optify to
the list of build dependencies.
It will allow to have maemo-optify installed together with other build deps.

 What the buildbot could do (and maybe does), is to run

     apt-get upgrade

 at one point.  This is important to get the target into a current state
 in general.  If it does, we could just upload a newer version of
 build-essential into extras-devel that depends on maemo-optify.

 This is quite a correct way to go about this, I'd say.  The mess results
 from the SDK repo not being identical to extras-devel (which I would
 call a bug in itself).

 To reduce the mess, we should probably first put a version of
 maemo-optify and the modified build-essential into the sdk repo and make
 a SDK release.  We can then still put newer versions of maemo-optify
 into extras-devel.

 So, does the auto-builder run apt-get upgrade?
Nope. Sbdmock does it. Sbdmock is a separate tool, which is run from
autobuilder. And I really doubt that sbdmock author will accept our
hacks. And I really don't like to fork it either.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: maemo-optify, autobuilder /opt

2009/11/3 Marius Vollmer marius.voll...@nokia.com:
 ext Ed Bartosh bart...@gmail.com writes:

 We can hack dpkg-checkbuilddeps to unconditionally add maemo-optify to
 the list of build dependencies.

 Ouch.  That's very desperate.

May be. But not as desperate as calling apt-get install from
dpkg-buildpackage :)

 What about changing dpkg-buildpackage to run apt-get install
 maemo-optify if necessary?  That concentrates the hacks in one place
 and is thus less magical.

What if developer doesn't have internet connection open during the
build? Remember, we're going to put this into devkit, so not only
autobuilder will use it.

 (This wouldn't normally work since dpkg-buildpackage is not run as root,
 but in Scratchbox, it does.)

 So, does the auto-builder run apt-get upgrade?

 Nope. Sbdmock does it. Sbdmock is a separate tool, which is run from
 autobuilder.

 Hmm, so is apt-get upgrade being executed at one point before calling
 dpkg-buildpackage?
Yes it is.

 If so, that's enough; no need to change sbdmock.  If
 not, I think it would be a good idea to do it in general, not just for
 Maemo.  It's not really a hack to keep your build environment
 up-to-date, or is it?

Well, from my point of view all  /opt-related changes are hacks, so I
don't want to even propose them to general purpose tool.
It would be the same as if you would decide to send your patch for
dpkg-buildpackage to Debian.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: maemo-optify, autobuilder /opt

2009/11/3 Marius Vollmer marius.voll...@nokia.com:
 ext Ed Bartosh bart...@gmail.com writes:

 2009/11/3 Marius Vollmer marius.voll...@nokia.com:
 ext Ed Bartosh bart...@gmail.com writes:

 We can hack dpkg-checkbuilddeps to unconditionally add maemo-optify to
 the list of build dependencies.

 Ouch.  That's very desperate.

 May be. But not as desperate as calling apt-get install from
 dpkg-buildpackage :)

 Yeah, I have to agree, actually.

 Luckily, with apt-get upgrade being run during build, we don't need to
 change dpkg-checkbuilddeps and we can just update build-essential.
 (Unless I am missing something.  Do I?)

rootstrap is used as a build-essentials by sbdmock. The initial idea
was to put maemo-optify in there, but now we're trying to avoid that.

 Hmm, so is apt-get upgrade being executed at one point before calling
 dpkg-buildpackage?

 Yes it is.

 Cool, then that's our ticket to get maemo-optify into the build
 environment, I would say.

The only problem left is were to put 'apt-get install' :)

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: maemo-optify, autobuilder /opt

2009/11/2 Marius Vollmer marius.voll...@nokia.com:
ext Ed Bartosh bart...@gmail.com writes:

So, I can see this way of implementing this:
- give optification scripts to SDK developers and ask them to prepare
Debian devkit for Fremantle with patched dpkg-buildpackage as fast as
possible.

We should prepare a concrete patch against dpkg-buildpackage, of course.
I will do that.

Please, use dpkg-buildpackage from the current devkit:
http://scratchbox.org/download/files/sbox-releases/stable/src/scratchbox-devkit-debian-1.0.10.tar.gz

Would maemo-optify be part of that devkit as well, or would it be in the
rootstrap?

I prefer to leave maemo-optify in the rootstrap: that way, we can update
it much easier, which is quite important at this stage.

Unfortunately it has to be part of the devkit. Otherwise it will
behave differently with different rootstraps and make devkit
inconsistent.

- test new devkit with local builds and with autobuilder when it's ready.
- distirbute devkit among developers and change SDK documentation for
Fremantle.
- deploy in autobuilder production

If someone is willing and able to keep a close eye on the buildbot, then
we could deploy the devkit in the buildbot quite early. It might break
some builds, but if we are able to react quickly, then it is better to
catch those broken builds earlier than later. Ed?

Of course I'll take care of this. I can also help with building devkit
if needed.

What's the best way to make SDK guys to adopt our changes? Bug?

--
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: maemo-optify, autobuilder /opt

2009/11/2 Andrew Flegg and...@bleb.org:
 Ed wrote:
 2009/11/2 Marius Vollmer marius.voll...@nokia.com:

  Would maemo-optify be part of that devkit as well, or would it be in the
  rootstrap?
 
  I prefer to leave maemo-optify in the rootstrap: that way, we can update
  it much easier, which is quite important at this stage.
 
 Unfortunately it has to be part of the devkit.

 This is a problem. We need to be able to iterate maemo-optify to change its 
 behaviour and, at some point, be able to switch its default mode from 'none' 
 (to either 'auto' or 'manual').

OK, we can make dependency from dpkb-buildpackage to maemo-optify not
so strict. If maemo-optify is present it will be called from
dpkg-buildpackage.
With this approach we can put maemo-optify into rootstrap.
BTW, official rootstrap is also part of the SDK releases, so frankly
speaking I don't see much difference between these two options.

 How quickly will we be able to iterate changes to the devkit?

It's just one package, so pretty quickly.

 How happy will the SDK team be to make these changes?
Well, their main goal to support developers, right? I think they will
be extremely happy that someone did almost all job for them.
However, it's better to ask them directly. It's good oportunity to try
to collaborate with them, so we can use it.

 How will devs get new versions in their SDKs (reinstall devkit?!)?
Yes.

 Depending on these answers, perhaps we should have the maemo-optify package 
 include maemo-buildpackage which is a wrapper around dpkg-buildpackage  
 maemp-optify.
In this case it has to be included into rootsrap, which is provided by
the same SDK team, so anyway we should work with them somehow.


-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Autobuilder repository priority ?

2009/11/2 Jeremiah Foster jerem...@jeremiahfoster.com:

 On Nov 1, 2009, at 18:05, Ed Bartosh wrote:

 2009/11/1 Attila Csipa ma...@csipa.in.rs:
 On Sunday 01 November 2009 07:46:55 you wrote:
 So, you propose to have one more queue, which would use only SDK? Or
 only Extras? or both? Sorry, your proposal is still unclear to me
 and
 I doubt it would be clear for other devs.

 First we need to decide on whether Extras packages can update
 packages from
 the SDK/official repos.

 I don't think any Extras packages should update official SDK repos.

 It depends on type of packages. SDK contains 2 parts: developer tools
  libs, which are not installed on the device and libs  apps, which
 are installed on the device.

 Can't we have a monolithic repo which is _identical_ to the device,
 plus dev tools? This would allow developers to know in advance which
 dependencies are on the device and which dependencies they will have
 to pull in themselves.

I don't know. Can we?

 Idea of having separate queue for Extras updates sounds more promising
 to me. Developers might become confused with all this set of
 repositories, queues and processes, but the idea is good. I support
 this.

What about this? Can we have separate queue for updates? Any other ideas?


 In case of overlapping SDK/Extras I can't think of a satisfactory
 solution as
 then fixes for the latter would appear as fixes for the former,
 which is wrong
 and dangerous. Another issue would be that you would not be getting
 SDK
 updates if you have extras or extras-updates disabled, which is very
 counterintuitive.

 True. I also don't see any more or less acceptable solution for this.

 Having a single repo for each distro would be ideal, with _all_ the
 software required to run the device in the repo. Then we can co-
 ordinate the release as a single, monolithic repository. I know this
 is wishful thinking because not everything is licensed to allow this,
 but if we could get as much as possible in a single location, then we
 make life easier for developers.

Sounds like a long-term plan.
Attila  was asking us to solve problem with updates. And he proposed
good solution. Shell we implement it right now or you propose to wait
until we have Maemo distro and all this great things?


-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: maemo-optify, autobuilder /opt

2009/11/2 Marius Vollmer marius.voll...@nokia.com:
 ext Ed Bartosh bart...@gmail.com writes:

 OK, we can make dependency from dpkb-buildpackage to maemo-optify not
 so strict. If maemo-optify is present it will be called from
 dpkg-buildpackage.  With this approach we can put maemo-optify into
 rootstrap.

 Ok, I'll make it like that, then.

 BTW, official rootstrap is also part of the SDK releases,
 so frankly speaking I don't see much difference between these two
 options.

 Sorry, rootstrap was the wrong term.  Maemo-optify would be in a
 package that is installed in the buildbot environment.

 The buildbot would need to run apt-get install maemo-optify at the
 right time.  Any idea of how to do that?

Right way to do it is to include it into SDK rootstrap. Other ways I
can think of look hackish.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: maemo-optify, autobuilder /opt

2009/11/2 Marius Vollmer marius.voll...@nokia.com:
 ext Ed Bartosh bart...@gmail.com writes:

 Right way to do it is to include it into SDK rootstrap. Other ways I
 can think of look hackish.

 (I think this is a good example of what is wrong with Maemo: normally,
 we would just upload a patched dpkg and be done with it.  Now we have to
 muck around with devkits and rootstraps... a lot of hassle for no gain
 if you ask me.  But this is not the time to whine... :)

Looks like you're trying to say that scratchbox is what's wrong with Maemo :)
100% agree :)

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: maemo-optify, autobuilder /opt

2009/11/2 Marius Vollmer marius.voll...@nokia.com:
 ext Graham Cobb g+...@cobb.uk.net writes:

 On Thursday 29 October 2009 11:12:45 Marius Vollmer wrote:
 ext Alberto Mardegan ma...@users.sourceforge.net writes:
    b) A control file field makes the most sense to
       control the build process.
 
  Agreed.

 I think dedicated files in debian/ are better, like the
 debian/package.install files, etc.

 There is a difference.  A debian/optify is fine for controlling how
 maemo-optify works.  A control field is more logical for controlling how the
 auto-builder works: i.e. should it call maemo-optify at all, should it reject
 the package because it claims to be optified but there are not files in /opt,
 etc.

 I was thinking that the auto-builder would always calls maemo-optify,
 and maemo-optify would do the rest: decide whether to do anything, check
 for correct optification, etc.

That's the plan so far. autobuilder calls dpkg-buildpackage without
checkiing anything, like it already does.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: maemo-optify, autobuilder /opt

2009/11/2 Marius Vollmer marius.voll...@nokia.com:
 [ Jussi, we would like to get a new debian-etch devkit for Maemo 5 with
  the attached patch.  Please advise how to best go about this.
 ]

 ext Ed Bartosh bart...@gmail.com writes:

 I can also help with building devkit if needed.

 I didn't manage to get the devkit to compile (I didn't see a way to get
 it to not install into / during build), but I have a patch anyway
 (attached).

You can learn how to do it here:
http://scratchbox.org/documentation/docbook/devkit.html

Here you can get result of my build(patch attached):
https://garage.maemo.org/builder/scratchbox-devkit-debian_1.0.16-1.optify_i386.deb

I didn't test it, so don't expect too much :)

 What's the best way to make SDK guys to adopt our changes? Bug?

 Jussi Haakala should be our man (in CC).

I think we should ask him to build final variant, when everyone will
be happy with it.
Until that I can build it.

-- 
BR,
Ed
Mon Nov  2 21:31:37 EET 2009  Ed Bartosh bart...@gmail.com
  * modified dpkg-buildpackage to run maemo-optify
diff -rN -u old-sb-debian-devkit/debian/rules new-sb-debian-devkit/debian/rules
--- old-sb-debian-devkit/debian/rules	2009-11-02 21:38:29.0 +0200
+++ new-sb-debian-devkit/debian/rules	2009-11-02 21:38:30.0 +0200
@@ -4,6 +4,7 @@
 DEVKIT	= $(shell echo $(PACKAGE) | cut -d- -f3-)
 VERSION	= $(shell head -n1 /scratchbox/etc/scratchbox-version)
 DATE	= $(shell head -n2 /scratchbox/etc/scratchbox-version | tail -n1)
+VERSION = 1.0.16-1.optify
 
 build:
 
diff -rN -u old-sb-debian-devkit/etch_tools/dpkg/Makefile new-sb-debian-devkit/etch_tools/dpkg/Makefile
--- old-sb-debian-devkit/etch_tools/dpkg/Makefile	2009-11-02 21:38:29.0 +0200
+++ new-sb-debian-devkit/etch_tools/dpkg/Makefile	2009-11-02 21:38:30.0 +0200
@@ -7,7 +7,8 @@
  debian-triplet.patch \
  cris.patch \
  passwd-check-fix.patch \
- dpkg-uclibc.patch
+ dpkg-uclibc.patch \
+	 maemo-optify.patch
 
 LIBDEPS =
 DEPENDS = 
diff -rN -u old-sb-debian-devkit/etch_tools/dpkg/checksums new-sb-debian-devkit/etch_tools/dpkg/checksums
--- old-sb-debian-devkit/etch_tools/dpkg/checksums	2009-11-02 21:38:29.0 +0200
+++ new-sb-debian-devkit/etch_tools/dpkg/checksums	2009-11-02 21:38:30.0 +0200
@@ -5,3 +5,4 @@
 d35eba925f322f4591ebc0f6cf292d1d  download/dpkg-sbox.patch
 84819d216460537ad94df636d340c7f5  download/passwd-check-fix.patch
 fb6d6636d762fc6a1086807c0378002f  download/dpkg-uclibc.patch
+3d6bc31986de2ab958d9d78927fbdd67  files/maemo-optify.patch
diff -rN -u old-sb-debian-devkit/etch_tools/dpkg/files/maemo-optify.patch new-sb-debian-devkit/etch_tools/dpkg/files/maemo-optify.patch
--- old-sb-debian-devkit/etch_tools/dpkg/files/maemo-optify.patch	1970-01-01 02:00:00.0 +0200
+++ new-sb-debian-devkit/etch_tools/dpkg/files/maemo-optify.patch	2009-11-02 21:38:30.0 +0200
@@ -0,0 +1,58 @@
+--- orig/dpkg-1.13.25/scripts/dpkg-buildpackage.sh	2006-06-21 05:35:01.0 +0300
 new/dpkg-1.13.25/scripts/dpkg-buildpackage.sh	2009-11-02 18:44:41.0 +0200
+@@ -12,6 +12,7 @@
+ 	echo 
+ Copyright (C) 1996 Ian Jackson.
+ Copyright (C) 2000 Wichert Akkerman
++Copyright (C) 2009 Nokia Corporation (Marius Vollmer)
+ This is free software; see the GNU General Public Licence version 2 or
+ later for copying conditions. There is NO warranty.
+ }
+@@ -45,6 +46,7 @@
+   -snforce Debian native source format.  } only passed
+   -s[sAkurKUR]   see dpkg-source for explanation.} to dpkg-source
+   -ncdo not clean source tree (implies -b).
++  -nodo not run maemo-optify-deb.
+   -tcclean source tree when finished.
+   -apadd pause before starting signature process.
+   -W turn certain errors into warnings.   } passed to
+@@ -77,6 +79,7 @@
+ maint=''
+ desc=''
+ noclean=false
++nooptify=false
+ usepause=false
+ warnable_error=0
+ passopts=''
+@@ -109,6 +112,7 @@
+ 	-tc)	cleansource=true ;;
+ 	-t*)targetgnusystem=$value ;;  # Order DOES matter!
+ 	-nc)	noclean=true; if [ -z $binaryonly ]; then binaryonly=-b; fi ;;
++	-no)	nooptify=true ;;
+ 	-b)	binaryonly=-b; [ $sourceonly ]  \
+ 			{ echo 2 $progname: cannot combine $1 and -S ; exit 2 ; } ;;
+ 	-B)	binaryonly=-B; checkbuilddep_args=-B; binarytarget=binary-arch; [ $sourceonly ]  \
+@@ -127,6 +131,13 @@
+ 	shift
+ done
+ 
++if [ x$nooptify != xtrue ]; then
++if [ x`type -p maemo-optify-deb` = x ]; then
++echo 2 $progname: maemo-optify-deb not found, not optifying.
++nooptify=true
++fi
++fi
++
+ if [ -z $signcommand  ] ; then
+ 	signsource=:
+ 	signchanges=:
+@@ -216,6 +227,9 @@
+ if [ x$sourceonly = x ]; then
+ 	withecho debian/rules build 
+ 	withecho $rootcommand debian/rules $binarytarget
++if [ x$nooptify != xtrue ]; then
++withecho $rootcommand maemo-optify-deb --auto
++fi
+ fi
+ if [ $usepause = true

Re: Autobuilder repository priority ?

2009/11/1 Attila Csipa ma...@csipa.in.rs:

 Are you sure it works this way? I thought that packages are built with
 dependencies from unstable in Debian, just like they're built against
 extras-devel in Maemo.

 You're right you can't change pinning on the *builder* within the *same*
 queue, that would make no sense. The problem is that the autobuilder already
 uses a mix of repositories (as you said later, having packages from extras-*
 overriding SDK stuff is not right) and that we can't skip the promotion 
 process
 (i.e. no security.debian.org that is handled differently). If I was unclear as
 to the goal - I don't want to cross-reference repo contents (bad, bad idea). I
 want to be able to issue updates to packages that have been already promoted
 and got to the general public (obviously not typo fixes but stuff that is 
 REALLY
 important), and for that, we need a queue that has a different repository
 layout (i.e. no extras-devel overriding extras).

So, you propose to have one more queue, which would use only SDK? Or
only Extras? or both? Sorry, your proposal is still unclear to me and
I doubt it would be clear for other devs.

 Actually python-dbus is not very good example. It's not only SDK
 package. I might be wrong but I think it's included into PyMaemo
 releases and is delivered through Extras. Nokia included it into SDK,
 but this is a special case.

 I just ran into this problem personally with python-dbus, hence the mention,
 but I did say the problem is more generic than that :)

I agree that the problem exists. Let's find possible solutions for it.
I still think that the one I proposed is the fastest and simplest for now.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Autobuilder repository priority ?

2009/10/31 Attila Csipa ma...@csipa.in.rs:
 I have a small issue with the autobuilder. The whole thing started out by
 having a package that compiled nice in the SDK but not in the autobuilder due
 to a versioning mismatch (in my case python-dbus, but it's a generic problem
 as you'll see). After some snooping around, I realized the problem was that
 the SDK had 0.83.0-1maemo1 in fremantle/tools/free (and that's what got used
 when compiling in the SDK), however, the autobuilder insists on using
 0.83.0-1maemo3 from fremantle/free (-devel).

You can try to use python2.5-dbus instead of python-dbus to work
around the problem. python2.5-dbus is just a meta package, but it
presents only in SDK, which might allow you to avoid installing
python-dbus from extras-devel.

PS: It's just a workaround, not more than that. We can continue our discussion.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: maemo-optify, autobuilder /opt

2009/10/29 Graham Cobb g+...@cobb.uk.net:
 On Wednesday 28 October 2009 22:50:25 Ed Bartosh wrote:
 Somehow I don't like the idea of doing anything with the package
 without developer being aware of this. I'd rather implement check on
 autobuilder side to insure that packages are optified. Developer can
 use option XS-Maemo-Optify: none to disable optification if developer
 doesn't want it.

 Nobody likes doing something to the package automatically but, after a long
 discussion at the BOF, we agreed that the alternatives were even worse [1].

 In particular, there was a strong argument that the package should not have to
 include anything (even a control field option) to cause optification to
 happen.  Packages which wanted to do their own optification or which had to
 disable optification would have to include an option to stop optification.

 If it makes you happier: rename the autobuilder as autobuilder and optifier!

 We did agree that there had to be a way for developers to generate packages in
 the scratchbox environment which had been optified in exactly the same way
 the autobuilder would.  And that we would update the wiki pages about
 checking packages will build to include using that tool to test the
 optification.

 So, the consensus decision was that the solution would be that autobuilder
 should automatically optify by default.


So, what should we do?

My proposal is to make dpkg-buildpackage to call maemo-optify. With
this we can solve 2 problems - autobuilder will optify packages and
developers will have their packages automatically optified for their
local builds without using any extra tools.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Autobuilder repository priority ?

2009/11/1 Attila Csipa ma...@csipa.in.rs:
 On Sunday 01 November 2009 07:46:55 you wrote:
 So, you propose to have one more queue, which would use only SDK? Or
 only Extras? or both? Sorry, your proposal is still unclear to me and
 I doubt it would be clear for other devs.

 First we need to decide on whether Extras packages can update packages from
 the SDK/official repos.
It depends on type of packages. SDK contains 2 parts: developer tools
 libs, which are not installed on the device and libs  apps, which
are installed on the device.
For first group updating through Extras is not good, but possible and
most of the time it would work faster than through SDK update
process(if it exists at all).
Packages from second group can break SSU if they they're considered as
a system packages. Actually, application manager doesn't allow to
install them, but if installed using dpkg they can break SSU.

Another concern here is that SDK and device firmware usually released
together, but packages in Extras are not synchronized with those
releases until they appear. It practically means that it's better to
avoid overlapping SDK/Extras as much as possible. However it's still
unclear to me what to do with components taken into SDK from projects
similar to PyMaemo with their own release circle and distributing
scheme.

 I'd say no. In that case, go the Debian way and have an
 sdk-updates and extras-updates queue with a different QA procedure.
Maemo isn't Debian. Debian has consistent repository one for
everything. Maemo has at least 3 different components(SDK, Extras,
device packages) and 2 different operation environments(scratchbox and
device). SDK has never been released through Extras, so separate queue
for SDK updates should be agreed with SDK team. I doubt they need it.

Idea of having separate queue for Extras updates sounds more promising
to me. Developers might become confused with all this set of
repositories, queues and processes, but the idea is good. I support
this.


 In case of overlapping SDK/Extras I can't think of a satisfactory solution as
 then fixes for the latter would appear as fixes for the former, which is wrong
 and dangerous. Another issue would be that you would not be getting SDK
 updates if you have extras or extras-updates disabled, which is very
 counterintuitive.

True. I also don't see any more or less acceptable solution for this.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: maemo-optify, autobuilder /opt

2009/11/1 Graham Cobb g+...@cobb.uk.net:
 On Sunday 01 November 2009 09:02:34 Ed Bartosh wrote:
 So, what should we do?

 My proposal is to make dpkg-buildpackage to call maemo-optify. With
 this we can solve 2 problems - autobuilder will optify packages and
 developers will have their packages automatically optified for their
 local builds without using any extra tools.

 I am happy to go with your recommendation.  I guess there is a small downside
 that we are forking dpkg-buildpackage but, as you say, the advantage is that
 developers will not have to do anything locally.


So, I can see this way of implementing this:
- give optification scripts to SDK developers and ask them to prepare
Debian devkit for Fremantle with patched dpkg-buildpackage as fast as
possible.
- test new devkit with local builds and with autobuilder when it's ready.
- distirbute devkit among developers and change SDK documentation for Fremantle.
- deploy in autobuilder production

Any ideas, objections, clarifications?

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Autobuilder repository priority ?

2009-10-31 Thread Ed Bartosh

2009/10/31 Attila Csipa ma...@csipa.in.rs:
 I have a small issue with the autobuilder. The whole thing started out by
 having a package that compiled nice in the SDK but not in the autobuilder due
 to a versioning mismatch (in my case python-dbus, but it's a generic problem
 as you'll see). After some snooping around, I realized the problem was that
 the SDK had 0.83.0-1maemo1 in fremantle/tools/free (and that's what got used
 when compiling in the SDK), however, the autobuilder insists on using
 0.83.0-1maemo3 from fremantle/free (-devel). The problem is IMHO that
 the repository priorities seem to be wrong. The autobuilder should be using
 the highest version in the TOP PRIORITY repository that satisfies a dependency
 to avoid breakage because of unstable stuff in -devel and because otherwise a
 package can't be promoted without dragging other folks' packages with them.
 Thoughts ?

The reason of this is that apt designed so that it will always install
higher possible version of package. It's actually rather good than
bad. Imagine what would happen if it would work another way. No new
python-dbus ever :)

The solution for this is to go to bugs.maemo.org and report your
problem to Pymaemo project and wait for a fix. Or, better, to provide
patch. You can also discuss this with pymaemo developers on their irc
channel or mailing list:
http://pymaemo.garage.maemo.org/getinvolved.html

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Autobuilder repository priority ?

2009-10-31 Thread Ed Bartosh

2009/10/31 Attila Csipa ma...@csipa.in.rs:
 On Saturday 31 October 2009 14:49:24 Ed Bartosh wrote:
  is IMHO that the repository priorities seem to be wrong. The autobuilder
  should be using the highest version in the TOP PRIORITY repository that
  satisfies a dependency to avoid breakage because of unstable stuff in
  -devel and because otherwise a package can't be promoted without dragging
  other folks' packages with them. Thoughts ?

 The reason of this is that apt designed so that it will always install
 higher possible version of package. It's actually rather good than
 bad. Imagine what would happen if it would work another way. No new
 python-dbus ever :)

 This is not entirely correct (and definitely not recommended in our case of 
 the
 autobuilder). Apt uses priorities (both repository and package level
 priorities can be defined, 'pinned') to decide which package to use to satisfy
 a dependency, and only if the priorities are equal does it base the choice on
 version number.

 Why is the current (same-priority, version only) approach bad ?

 Say, my app depends on python-dbus. I test it with version A, currently in the
 SDK and it works just fine. I upload and promote my app. All is well. However,
 later, the pymaemo team uploads a newer, experimental B version into -devel.
 From that point on I am NO LONGER ABLE to reliably update my application nor
 promote it (this actually happened to me, my stuff compiles in SDK, but not in
 the autobuilder for this very reason).

True.

However there can be another situation: SDK version of python-dbus is
buggy and you can't use it with your application. You would have to
wait until new fixed version of python-dbus reaches high priority repo
to be able to build your application with it. Not so good for
application developer, either. I don't want to say that current
uproach is the best, just want to show you another side of the
problem.

 But you can specify a fixed version dependency (the one in SDK and extras), 
 you
 say ?
 But THEN I get to the problem of no updates. If bugs get squashed in the
 -devel version of the library I'm using, the user will never be able to
 upgrade to it, as my package is insisting on the old version (and the package
 manager wisely rather skips updates than removing already installed packages).

 Ubuntu and Debian solve this problem by advising different repository
 priorities. Stable has a highest priority, Testing is lower and Unstable is
 lowest. If there is a package in Stable that satisfies my requirement, that's
 the one that should be used.
Are you sure it works this way? I thought that packages are built with
dependencies from unstable in Debian, just like they're built against
extras-devel in Maemo.

 But then it will never get updated, you say ?
 Wrong ! Remember what I said up there - if the priority is the same, the
 version decides. So, the moment a new version of the dependency reaches
 *Stable*, it will become the highest priority and will get updated. It's a
 recommendation that dependencies should be REALISTICALLY listed. You should
 not depend on a high version number just because it's new or even because it's
 the one bundled on the system (!). You should depend on the minimal version
 that provides the actual functionality you require.

 Hope my problem is a bit more clear now.

It was clear from your previous mail.

Actually python-dbus is not very good example. It's not only SDK
package. I might be wrong but I think it's included into PyMaemo
releases and is delivered through Extras. Nokia included it into SDK,
but this is a special case.

SDK packages shouldn't be uploaded to extras-devel at all. There are
plans to implement checks on autobuilder side to prevent this.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: maemo-optify, autobuilder /opt

2009-10-29 Thread Ed Bartosh

2009/10/29 Graham Cobb g+...@cobb.uk.net:
 On Wednesday 28 October 2009 22:50:25 Ed Bartosh wrote:
 Somehow I don't like the idea of doing anything with the package
 without developer being aware of this. I'd rather implement check on
 autobuilder side to insure that packages are optified. Developer can
 use option XS-Maemo-Optify: none to disable optification if developer
 doesn't want it.

 Nobody likes doing something to the package automatically but, after a long
 discussion at the BOF, we agreed that the alternatives were even worse [1].

Then let's find the way to do it better.
What I'm afraid of is that developers wouldn't like the approach to
change packages implicitly. It potentially can create repository mess
again. And I really don't want this to happen.

 In particular, there was a strong argument that the package should not have to
 include anything (even a control field option) to cause optification to
 happen.  Packages which wanted to do their own optification or which had to
 disable optification would have to include an option to stop optification.

 If it makes you happier: rename the autobuilder as autobuilder and optifier!

No, it won't make me happier.

 We did agree that there had to be a way for developers to generate packages in
 the scratchbox environment which had been optified in exactly the same way
 the autobuilder would.  And that we would update the wiki pages about
 checking packages will build to include using that tool to test the
 optification.

Would it be better to change the common part of developer environment
and autobuilder, for example somewhere in debian devkit? If
dpkg-buildpackage will produce optified packages they will be at least
the same everywhere.

 So, the consensus decision was that the solution would be that autobuilder
 should automatically optify by default.

I didn't even think it will go this way. This why I didn't participate
on discussions and BOF, sorry. Does it mean that I should shut up and
do what I'm told to do?

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: maemo-optify, autobuilder /opt

2009-10-29 Thread Ed Bartosh

2009/10/29 Andrew Flegg and...@bleb.org:
 Ed wrote:
 2009/10/29 Graham Cobb g+...@cobb.uk.net:
 
  Nobody likes doing something to the package automatically but, after a long
  discussion at the BOF, we agreed that the alternatives were even worse [1].
 
 Then let's find the way to do it better.
 What I'm afraid of is that developers wouldn't like the approach to
 change packages implicitly.

 There were some very senior and well respected developers in the room, who 
 package some of the leading Maemo applications.

 It potentially can create repository mess
 again. And I really don't want this to happen.

 No-one does, however increasing the amount of work developers have to do to 
 get into Extras because of Nokia's short-sightedness is also a demotivating 
 factor which could lead to multiple repositories springing up.

True. However I'm not sure that making developers to do additional
work is worse than change package imlicitly, which can potentially
cause installation and runtime problems.

  In particular, there was a strong argument that the package should not 
  have to
  include anything (even a control field option) to cause optification to
  happen.  Packages which wanted to do their own optification or which had to
  disable optification would have to include an option to stop optification.

 And this is because /opt is basically a weirdness caused specific to Maemo 
 packaging, and (with the move to Qt) the Maemo development community is 
 increasingly realising the benefits of abstracting platform weirdness.

 Would it be better to change the common part of developer environment
 and autobuilder, for example somewhere in debian devkit? If
 dpkg-buildpackage will produce optified packages they will be at least
 the same everywhere.

 Have you an estimate on the comparative costs of developing one vs. the 
 other? This is an implementation detail of make the autobuider do it. Who 
 owns the Debian devkit and do they want to do the work?

I'd say changing devkit would take twice more then modifying
autobuilder. Not a very big difference, considering that  we can have
one solution to both problems. With modified devkit we can change both
developer and autobuider environments in one shot.

Devkit is a part of SDK, so SDK people own it.
I can help to modify it if we decide to go this way.

 A maemo-buildpackage was mentioned in the BOF as a potential way of 
 allowing developers to do what the auto-builder does. How hard would it be to 
 develop this and get the autobuilder to call maemo- rather than 
 dpkg-buildpackage?

 However, there seem to be two arguments on your side:

  1) Don't do anything, developers should modfy
     debian/rules as they do now.
  2) Make something in the build process do it,
     rather than the autobuilder.

I like 1st better. Second is just a bit better alternative to your decision.

 (2) is an internal implementation detail which isn't important externally: 
 the consensus view could be tested by uploading a Diablo source package with 
 no changes and having it auto-optified. Whether that's through a change to 
 the devkit, autobuilder-specific code or the introduction of 
 maemo-buildpackage is of little interest to the person doing the uploading :-)

It is important. Instead of introducing new tool we just change the
existing. No additional work for developers in this case.


-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: maemo-optify, autobuilder /opt

2009-10-29 Thread Ed Bartosh

2009/10/29 Marius Vollmer marius.voll...@nokia.com:
 ext Andrew Flegg and...@bleb.org writes:

 I suggest the header is XS-Maemo-Optify, and has the following values:

   none:   no optification should be done, or considered, by the autobuilder.
   manual: the application author will do optification manually. If the
           package contains no entries under /opt it would be considered a
           build failure.
   auto:   maemo-optify would be run if certain heuristics were met (e.g.
           no entries in /opt, no Python dependency)
   force:  maemo-optify would always be run

 Thanks for the initiative, Andrew!

 I have put maemo-optify 0.2 into extras-devel with the following
 changes, motivated by your proposal:

  * Added --auto option to maemo-optify-deb which will read debian/optify
    and debian/files and does the right thing.

  * Added maemo-optify-buildpackage, which invokes maemo-optify-deb in
    auto mode.

 More details in the README here:

    http://maemo.gitorious.org/maemo-af/maemo-optify/blobs/master/README

 Thus, only none and auto are really implemented right now, and the
 mode is read from debian/optify instead of from debian/control.

 (Proper man pages are still missing.)

 Thus, the next step is to make sure that maemo-optify is installed in
 the build environment and to use maemo-optify-buildpackage instead of
 dpkg-buildpackage.  (Or make the equivalent changes to dpkg-buildpackage
 itself, which are quite small.)

There are two ways to have maemo-optify in build environment - to add
it to the rootstrap and to put it into Build-Depends.
As I understood we don't want to ask developers to put it into
Build-Depends, so rootstrap should be changed.
I already hacked it one time when I removed /opt from there. I can do
it again, but I don't want to fork SDK rootstrap, so it would
be nice to somehow agree with SDK team to include these changes into
the next release.

I like the idea of making equivalent changes to dpkg-buildpackage. Why
we should introduce new tool?

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: maemo-optify, autobuilder /opt

2009-10-28 Thread Ed Bartosh

2009/10/28 Andrew Flegg and...@bleb.org:
 Hi,

 I've put together a suggested spec for the decision, taken at the
 summit during the /opt BOF[1], that the auto-builder would run some
 maemo-optify version during the build process (controlled by a control
 file header):

http://talk.maemo.org/showthread.php?p=359996#post359996

 I suggest the header is XS-Maemo-Optify, and has the following values:

  none:   no optification should be done, or considered, by the autobuilder.
  manual: the application author will do optification manually. If the
  package contains no entries under /opt it would be considered a
  build failure.
  auto:   maemo-optify would be run if certain heuristics were met (e.g.
  no entries in /opt, no Python dependency)
  force:  maemo-optify would always be run

 Marius: are you taking ownership of talking to Ed Bartosh, and anyone
 else, about this plan?

We can discuss it here.

Sorry, I seem to miss the whole point of this activity. Why do you
need to do that on autobuilder side? As far as I understood it's just
a matter of including maemo-optify as a build dependency  and run it
in debian/rules, right? Why developer can't do this then? I don't see
much difference between setting XS-Maemo-Optify and changes I
mentioned above. In both cases developer should understand what
optification means.

BTW, when you want to have it done?
I'm going to vacation in a couple of weeks. Before that I was going to
finish implementation of multiple packages builds if I have time.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: maemo-optify, autobuilder /opt

2009-10-28 Thread Ed Bartosh

2009/10/28 Andrew Flegg and...@bleb.org:
 Ed wrote:
 
  I've put together a suggested spec for the decision, taken at the
  summit during the /opt BOF[1], that the auto-builder would run some
  maemo-optify version during the build process (controlled by a control
  file header):

 Sorry, I seem to miss the whole point of this activity. Why do you
 need to do that on autobuilder side? As far as I understood it's just
 a matter of including maemo-optify as a build dependency  and run it
 in debian/rules, right? Why developer can't do this then? I don't see
 much difference between setting XS-Maemo-Optify and changes I
 mentioned above. In both cases developer should understand what
 optification means.

 The consensus at the BOF was that since it's something which SHOULD be done 
 for all Maemo packages, but that this is Maemo specific, that it should be 
 done at the autobuilder to ensure that as many packages are optified as 
 possible.

 By having auto be the default (i.e. the developer has NOT specified 
 XS-Maemo-Optify) at some point in the future we can avoid the current problem 
 where, even though the requirements are well understood more than half the 
 user-facing applications in -testing aren't using /opt.


Somehow I don't like the idea of doing anything with the package
without developer being aware of this. I'd rather implement check on
autobuilder side to insure that packages are optified. Developer can
use option XS-Maemo-Optify: none to disable optification if developer
doesn't want it.

Explicit is better than implicit. (C) Zen of Python :)

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: maemo-optify, autobuilder /opt

2009-10-28 Thread Ed Bartosh

2009/10/29 Graham Cobb g+...@cobb.uk.net:
 I think we should do the second item before Ed goes on holiday, even if it
 means deferring the multiple package builds.  We can then test it (setting
 the header to auto in various packages) while Ed is away but there is minimal
 danger of problems cropping up while he is away.

 Ed, could we do that?

I think we can. I just want to understand why this way.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Error installing optified packages in Fremantle SDK

2009-10-27 Thread Ed Bartosh

2009/10/27 Luca Donaggio donag...@gmail.com:
 Linking /opt against /targets/links/opt did the trick!
 Now I can install my packages with dpkg, at least - apt-get will still
 complain about /opt and the base-files package I think.


No, it shouldn't complain. At least it doesn't complain in my environment.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Error installing optified packages in Fremantle SDK

2009/10/26 Luca Donaggio donag...@gmail.com:
 Hi!

 I've succesfully built a new version of my packages and optified them, but
 now if I try to install them in the SDK to see if they works as expected
 before pushing them to extras-testing, all I've got is:

 dpkg: error processing /var/cache/apt/archives/blablabla.deb (--unpack):
  trying to overwrite `/opt', which is also in package base-files
 dpkg-deb: subprocess paste killed by signal (Broken pipe)

 I've made through all the steps related to /opt in the SDK when I installed
 the final version as described here [1]:

 [sbox-FREMANTLE_X86: ~] rm /targets/FREMANTLE_X86/opt
 [sbox-FREMANTLE_X86: ~] mkdir /targets/FREMANTLE_X86/opt

 but, still:

 [sbox-FREMANTLE_X86: ~]  v /opt
 lrwxrwxrwx  1 cthulhu cthulhu 9 Oct  6 16:46 /opt - /home/opt

 and, of course, /home/opt doesn't exist.

 Can someone point me to what I'm doing wrong here? Or is there some
 workaround?


Have you tried to install your optified packages after you created
/opt directory inside your target?
Did dpkg fail with the same output?


-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Error installing optified packages in Fremantle SDK

2009/10/26 Luca Donaggio donag...@gmail.com:
 The output from dpkg is exactly the same.
 What do you mean by Have you tried to install your optified packages after
 you created
 /opt directory inside your target? ?
I thought it was failing before you re-created /opt. Probably I
misunderstood the situation.

 I have:

 [sbox-FREMANTLE_X86: ~]  v /targets/links/opt
 lrwxrwxrwx  1 cthulhu cthulhu 26 Oct  7 15:26 /targets/links/opt -
 /targets/FREMANTLE_X86/opt

 and:

 [sbox-FREMANTLE_X86: ~]  v /targets/FREMANTLE_X86
 total 76
 [...]
 drwxrwxr-x   2 cthulhu cthulhu 4096 Oct  7 15:04 opt
 [..]

 but:

 [sbox-FREMANTLE_X86: ~]  v /opt
 lrwxrwxrwx  1 cthulhu cthulhu 9 Oct  6 16:46 /opt - /home/opt

You can read this thread:
http://lists.maemo.org/pipermail//maemo-developers/2009-October/021588.html
The error explained there is the same as yours.

I resolved it by removing /opt from rootstraps.
Here is what I have in my target:
[sbox-maemo5-arm: ~]  ls -la / | grep opt
lrwxrwxrwx   1 root root   18 Oct 22 09:22 opt - /targets/links/opt

[sbox-maemo5-arm: ~]  ls -la /targets/maemo5-arm/ |grep opt
drwxrwxr-x   2 ed ed 4096 Oct 26 16:19 opt

And I'm able to install optified packages into this target:
[sbox-maemo5-arm: ~]  fakeroot apt-get install clucene-core
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  clucene-core
0 upgraded, 1 newly installed, 0 to remove and 2 not upgraded.
Need to get 0B/319kB of archives.
After unpacking 1085kB of additional disk space will be used.
WARNING: The following packages cannot be authenticated!
  clucene-core
Install these packages without verification [y/N]? y
/scratchbox/tools/bin/sh: line 1: /usr/sbin/dpkg-preconfigure: No such
file or directory
Selecting previously deselected package clucene-core.
(Reading database ... 6395 files and directories currently installed.)
Unpacking clucene-core (from .../clucene-core_0.9.21b-0maemo1_armel.deb) ...
Setting up clucene-core (0.9.21b-0maemo1) ...
[sbox-maemo5-arm: ~]  dpkg -L clucene-core |grep opt
/opt
/opt/maemo
/opt/maemo/usr
/opt/maemo/usr/lib
/opt/maemo/usr/lib/libclucene.so.0.0.0

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Error installing optified packages in Fremantle SDK

2009/10/26 Luca Donaggio donag...@gmail.com:
 On Mon, Oct 26, 2009 at 4:40 PM, Ed Bartosh bart...@gmail.com wrote:

 2009/10/26 Luca Donaggio donag...@gmail.com:
  The output from dpkg is exactly the same.
  What do you mean by Have you tried to install your optified packages
  after
  you created
  /opt directory inside your target? ?
 I thought it was failing before you re-created /opt. Probably I
 misunderstood the situation.

  I have:
 
  [sbox-FREMANTLE_X86: ~]  v /targets/links/opt
  lrwxrwxrwx  1 cthulhu cthulhu 26 Oct  7 15:26 /targets/links/opt -
  /targets/FREMANTLE_X86/opt
 
  and:
 
  [sbox-FREMANTLE_X86: ~]  v /targets/FREMANTLE_X86
  total 76
  [...]
  drwxrwxr-x   2 cthulhu cthulhu 4096 Oct  7 15:04 opt
  [..]
 
  but:
 
  [sbox-FREMANTLE_X86: ~]  v /opt
  lrwxrwxrwx  1 cthulhu cthulhu 9 Oct  6 16:46 /opt - /home/opt
 
 You can read this thread:

 http://lists.maemo.org/pipermail//maemo-developers/2009-October/021588.html
 The error explained there is the same as yours.

 I resolved it by removing /opt from rootstraps.
 Here is what I have in my target:
 [sbox-maemo5-arm: ~]  ls -la / | grep opt
 lrwxrwxrwx   1 root root   18 Oct 22 09:22 opt - /targets/links/opt

 [sbox-maemo5-arm: ~]  ls -la /targets/maemo5-arm/ |grep opt
 drwxrwxr-x   2 ed ed 4096 Oct 26 16:19 opt

 And I'm able to install optified packages into this target:
 [sbox-maemo5-arm: ~]  fakeroot apt-get install clucene-core
 Reading package lists... Done
 Building dependency tree... Done
 The following NEW packages will be installed:
  clucene-core
 0 upgraded, 1 newly installed, 0 to remove and 2 not upgraded.
 Need to get 0B/319kB of archives.
 After unpacking 1085kB of additional disk space will be used.
 WARNING: The following packages cannot be authenticated!
  clucene-core
 Install these packages without verification [y/N]? y
 /scratchbox/tools/bin/sh: line 1: /usr/sbin/dpkg-preconfigure: No such
 file or directory
 Selecting previously deselected package clucene-core.
 (Reading database ... 6395 files and directories currently installed.)
 Unpacking clucene-core (from .../clucene-core_0.9.21b-0maemo1_armel.deb)
 ...
 Setting up clucene-core (0.9.21b-0maemo1) ...
 [sbox-maemo5-arm: ~]  dpkg -L clucene-core |grep opt
 /opt
 /opt/maemo
 /opt/maemo/usr
 /opt/maemo/usr/lib
 /opt/maemo/usr/lib/libclucene.so.0.0.0

 --
 BR,
 Ed

 Thank you Ed,

 I've read that thread, but I was hoping for another (quicker) solution!
 After changing the rootstrap do I need to re-install the whole environment?

I hope it would be enough to reset your targets and unpack rootstraps there.
You can also try to make the same symlinks as I have instead of
removing /opt from roostraps.
Here is what I have:
[sbox-maemo5-arm: ~]  file /opt
/opt: symbolic link to `/targets/links/opt'
[sbox-maemo5-arm: ~]  file /targets/links/opt
/targets/links/opt: symbolic link to `/targets/maemo5-arm/opt'
[sbox-maemo5-arm: ~]  file /targets/maemo5-arm/opt
/targets/maemo5-arm/opt: directory

The only difference I can see is that my symlinks point out to the
directory which exists,
so you can start from creating /home/opt. If it won't work then you
can try to make the same symlinks that I have.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: How to find the author of a git commit?

2009/10/26 Alberto Mardegan ma...@users.sourceforge.net:
 Hi,
   I noticed just now that a few days ago someone committed some code
 into maemo-mapper, but I have no idea who did. I will ask in the project
 forum, but in case the author is not following it, is it possible to
 find out who the author was by looking at the git commit?

 It's this one:
 https://garage.maemo.org/plugins/ggit/browse.php/?p=maemo-mapper;a=commit;h=edd250bb545e15385375b131843d080ec81a8d1f

git-show edd250bb545e15385375b131843d080ec81a8d1f will show you the author.
commit edd250bb545e15385375b131843d080ec81a8d1f
Author: maemo ma...@maemo-desktop.(none)
Date:   Tue Oct 20 23:46:38 2009 +0100

Here you can find his email:
https://garage.maemo.org/users/maemo/

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Maemo-Optify Builder Bots = Broken?

2009-10-24 Thread Ed Bartosh

2009/10/24 Graham Cobb g+...@cobb.uk.net:

 I don't think you will get anywhere.  Isn't this a known issue?  The manual
 installation instructions for the SDK
 (http://wiki.maemo.org/Documentation/Maemo5_Final_Installation#Manual_Installation)
 include:

 In order to facilitate installing applications under /opt on the device, a
 symlink /opt has been created pointing to /home/opt. The SDK inherits this
 feature.
I'd say it inherits it in a funny way. May be it's better not to do it
at all then do it like it's done.

 Under Scratchbox, /opt points to /target/links/opt which in turn
 points to /targets/target_name/opt. Installing the rootstraps makes this
 point to /home/opt, which is not what we want, since we need /opt to be
 target specific. In order to resolve this situation,
 [sbox-FREMANTLE_X86: ~] rm /targets/FREMANTLE_X86/opt
 [sbox-FREMANTLE_X86: ~] mkdir /targets/FREMANTLE_X86/opt

 I think sbdmock needs to do the same thing after installing the rootstrap.

I don't think so. It looks like a hack to remove something provided by
official SDK image.
Why they put this symlink in there if it's not needed and even
prevents installation of optified packages?
As you can see from my posts deleting it from rootstrap solves the
issue. So, obvious way would be to not provide it in rootstrap at all.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Maemo-Optify Builder Bots = Broken?

2009-10-24 Thread Ed Bartosh

2009/10/24 Graham Cobb g+...@cobb.uk.net:
 On Sat, Oct 24, 2009 at 11:03:18AM +0300, Ed Bartosh wrote:
 2009/10/24 Graham Cobb g+...@cobb.uk.net:
  I think sbdmock needs to do the same thing after installing the rootstrap.
 
 I don't think so. It looks like a hack to remove something provided by
 official SDK image.
 Why they put this symlink in there if it's not needed and even
 prevents installation of optified packages?
 As you can see from my posts deleting it from rootstrap solves the
 issue. So, obvious way would be to not provide it in rootstrap at all.

 I completely agree with you but from a **practical** point of view it is not
 likely to change in the short term (and maybe not at all)!

I understand that. That's why I removed /opt from the rootstrap
instead of waiting
for the fix from SDK team.

 And it is definitely a BUG in sbdmock if it is not following the
 instructions included in the documentation of doing a manual rootstrap
 installation.  Whether we agree with it or not, the documentation includes
 instructions for what has to be done after installing the rootstrap.  Of
 course, it should be an option set in the conf file so that it is only
 done for the broken SDKs and can be turned off if it is ever fixed in later
 SDKs.

I'm still not sure it's good to remove /opt in sbdmock code.
Sbdmock isn't a tool for building packages only for Maemo, so it
doesn't have to follow instructions specific for one particular
release of SDK for particular platform.
It's general-purpose builder which uses scratchbox as a low level tool
and rootstrap as pre-defined enviromnent for the build. Having
workarounds for specific Maemo SDK bug in it doesn't look good for me.
I like fixing rootstrap more.
However you can send patch to sbdmock author. He might have another opinion.

Marius, can you point us to the bug, please? I'd like to see what SDK
guys say about it.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Maemo-Optify Builder Bots = Broken?

2009/10/22 Kamen Bundev bun...@gmail.com:
 Hmm, yes, that seems to be the problem. In the final SDK /opt is a symlink
 but in the latest beta SDK it is not. I didn't upgrade my development
 machine, but I have the final on another so I can compare. I'll report back
 if successful.

You're right.
Autobuilder uses latest SDK and /opt is in the rootstrap:
tar -ztf /scratchbox/packages/maemo-sdk-rootstrap_5.0_armel.tgz | grep '^\./opt'
./opt

I removed it from there and now packages with /opt directory should be
installable.
Try to re-upload your packages to autobuilder. It should work now.

Thank you for your help.

PS: Is someone willing to file a bug for SDK :) ?

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Maemo-Optify Builder Bots = Broken?

Hi,

Please read my last message. The issue is fixed. Nobody should do
anything except of SDK guys.

2009/10/22 Kamen Bundev bun...@gmail.com:
 Hi guys,

 I've played around with maemo-optify yesterday and decided to instead of
 creating the paths in the package subdir, to create a symlink to /opt and
 drop everything there before packaging. Wrong move, dpkg-deb doesn't follow
 symlinks, it packages them :) So, the logical step was to instead of symlink
 to /opt, to create home/opt in the package subdir and symlink opt/ to it.
 That worked and I have a package ready that will work in the device, but I'm
 hesitant to try it in the autobuilder because if the autobuilder is like
 scratchbox, then the package will be installed to /home/opt but the /opt
 symlinks will point to somewhere else (/targets/links/opt) and the build
 will fail anyway.

 So my question is - is this the right way to go about this and can I control
 where the /opt dir is symlinked to in the autobuilder?

 Regards:
 Bundyo

 On Thu, Oct 22, 2009 at 2:35 AM, Nathan Anderson nat...@andersonsplace.net
 wrote:

 Kamen,

 I build both binary target and source targets debs in my scratchbox
 before I upload.For instance last night I had to rebuild the binary debs
 about 20 times (trying to get a weird make file rule to work).  Once I got
 it working then I would copy my rules to a fresh copy and re-run a source
 deb then re-run a binary once more just to make sure it wasn't left over
 stuff causing a success.  ;-)

So, I don't think it has anything to do with the scratchbox.  I suspect
 it as Ed found something to do with the symlink - directory or something in
 their on the auto-builder.

 Nathan.
 
 From: Kamen Bundev [mailto:bun...@gmail.com]
 Sent: Wednesday, October 21, 2009 6:14 PM
 To: Nathan Anderson
 Cc: maemo-developers@maemo.org
 Subject: Re: Maemo-Optify  Builder Bots = Broken?

 Nah, that's not enough. Still fails.

 Another difference is that I'm building my optified package in scratchbox
 before upload and the other people are using the autobuilder, so the problem
 should be somewhere else.

 Regards:
 Bundyo

 On Thu, Oct 22, 2009 at 2:09 AM, Kamen Bundev bun...@gmail.com wrote:

 Nah, that's not enough. Still fails.

 Regards:
 Bundyo

 On Thu, Oct 22, 2009 at 12:52 AM, Kamen Bundev bun...@gmail.com wrote:

 Looks like the only difference here is that my /opt should be pointing
 to /targets/links/opt which is symlinked to the proper target on target
 change. Uploading the new package to extras now.

 Regards:
 Bundyo

 On Thu, Oct 22, 2009 at 12:39 AM, Nathan Anderson
 nat...@andersonsplace.net wrote:

 Ed,

I believe this is what you are asking:
 FREMANTLE_ARMEL  cs2007q3-glibc2.5-arm7
 FREMANTLE_X86cs2007q3-glibc2.5-i486


 Nathan

 -Original Message-
 From: Ed Bartosh [mailto:bart...@gmail.com]
 Sent: Wednesday, October 21, 2009 4:03 PM
 To: Nathan Anderson
 Cc: maemo-developers@maemo.org
 Subject: Re: Maemo-Optify  Builder Bots = Broken?

 2009/10/21 Nathan Anderson nat...@andersonsplace.net:
  Ed,
 
 Sure can (and following the chain).
 
  ls -l / | grep opt
 lrwxrwxrwx1 root  root  18 Oct  6 22:36 opt -
  /targets/links/opt
 
  ls -l /targets/links/ | grep opt
 lrwxrwxrwx  1 maemo 1000 26 Oct 19 16:55 opt -
  /targets/FREMANTLE_X86/opt
 
 I've found the difference!
 In your environment /targets/target/opt is a directory. In
 autobuilder
 environment it's a symlink:

  ls -l /targets/maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c/
  |grep opt
 lrwxrwxrwx   1 builder1 builder19 Oct 21 23:50 opt - /home/opt

 And it looks like it becomes symlink after rootstrap unpacking. Look:
 [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~]  sb-conf
 re
 -f
 [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~]  ls -l
 /targets/maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c/ |grep opt
 drwxrwxr-x  2 1005 1006 4096 Oct 21 23:56 opt
 [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~]  sb-conf
 in
 --etc --devkits
 [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~]  ls -l
 /targets/maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c/ |grep opt
 drwxrwxr-x   2 builder1 builder1 4096 Oct 21 23:56 opt
 [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~]  sb-conf
 in
 --fakeroot Installing fakeroot version 1.4.2.1...
 [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~]  ls -l
 /targets/maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c/ |grep opt
 drwxrwxr-x   2 builder1 builder1 4096 Oct 21 23:56 opt
 [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~]  sb-conf
 rs
 /scratchbox/packages/maemo-sdk-rootstrap_5.0_armel.tgz
 Unpacking rootstrap...
 [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~]  ls -l
 /targets/maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c/ |grep opt
 lrwxrwxrwx   1 1005 10069 Oct 21 23:57 opt - /home/opt

 So, the difference

Re: Maemo-Optify Builder Bots = Broken?

Hi,

I restarted Nathan's build and autobuilder seems to be able to install
all build-deps.
You can see autobuilder logs here soon:
https://garage.maemo.org/builder/fremantle/sword_1.6.0a-0maemo1/

2009/10/22 Ed Bartosh bart...@gmail.com:
 Hi,

 Please read my last message. The issue is fixed. Nobody should do
 anything except of SDK guys.

 2009/10/22 Kamen Bundev bun...@gmail.com:
 Hi guys,

 I've played around with maemo-optify yesterday and decided to instead of
 creating the paths in the package subdir, to create a symlink to /opt and
 drop everything there before packaging. Wrong move, dpkg-deb doesn't follow
 symlinks, it packages them :) So, the logical step was to instead of symlink
 to /opt, to create home/opt in the package subdir and symlink opt/ to it.
 That worked and I have a package ready that will work in the device, but I'm
 hesitant to try it in the autobuilder because if the autobuilder is like
 scratchbox, then the package will be installed to /home/opt but the /opt
 symlinks will point to somewhere else (/targets/links/opt) and the build
 will fail anyway.

 So my question is - is this the right way to go about this and can I control
 where the /opt dir is symlinked to in the autobuilder?

 Regards:
 Bundyo

 On Thu, Oct 22, 2009 at 2:35 AM, Nathan Anderson nat...@andersonsplace.net
 wrote:

 Kamen,

 I build both binary target and source targets debs in my scratchbox
 before I upload.For instance last night I had to rebuild the binary debs
 about 20 times (trying to get a weird make file rule to work).  Once I got
 it working then I would copy my rules to a fresh copy and re-run a source
 deb then re-run a binary once more just to make sure it wasn't left over
 stuff causing a success.  ;-)

So, I don't think it has anything to do with the scratchbox.  I suspect
 it as Ed found something to do with the symlink - directory or something in
 their on the auto-builder.

 Nathan.
 
 From: Kamen Bundev [mailto:bun...@gmail.com]
 Sent: Wednesday, October 21, 2009 6:14 PM
 To: Nathan Anderson
 Cc: maemo-developers@maemo.org
 Subject: Re: Maemo-Optify  Builder Bots = Broken?

 Nah, that's not enough. Still fails.

 Another difference is that I'm building my optified package in scratchbox
 before upload and the other people are using the autobuilder, so the problem
 should be somewhere else.

 Regards:
 Bundyo

 On Thu, Oct 22, 2009 at 2:09 AM, Kamen Bundev bun...@gmail.com wrote:

 Nah, that's not enough. Still fails.

 Regards:
 Bundyo

 On Thu, Oct 22, 2009 at 12:52 AM, Kamen Bundev bun...@gmail.com wrote:

 Looks like the only difference here is that my /opt should be pointing
 to /targets/links/opt which is symlinked to the proper target on target
 change. Uploading the new package to extras now.

 Regards:
 Bundyo

 On Thu, Oct 22, 2009 at 12:39 AM, Nathan Anderson
 nat...@andersonsplace.net wrote:

 Ed,

I believe this is what you are asking:
 FREMANTLE_ARMEL  cs2007q3-glibc2.5-arm7
 FREMANTLE_X86cs2007q3-glibc2.5-i486


 Nathan

 -Original Message-
 From: Ed Bartosh [mailto:bart...@gmail.com]
 Sent: Wednesday, October 21, 2009 4:03 PM
 To: Nathan Anderson
 Cc: maemo-developers@maemo.org
 Subject: Re: Maemo-Optify  Builder Bots = Broken?

 2009/10/21 Nathan Anderson nat...@andersonsplace.net:
  Ed,
 
 Sure can (and following the chain).
 
  ls -l / | grep opt
 lrwxrwxrwx1 root  root  18 Oct  6 22:36 opt -
  /targets/links/opt
 
  ls -l /targets/links/ | grep opt
 lrwxrwxrwx  1 maemo 1000 26 Oct 19 16:55 opt -
  /targets/FREMANTLE_X86/opt
 
 I've found the difference!
 In your environment /targets/target/opt is a directory. In
 autobuilder
 environment it's a symlink:

  ls -l /targets/maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c/
  |grep opt
 lrwxrwxrwx   1 builder1 builder19 Oct 21 23:50 opt - /home/opt

 And it looks like it becomes symlink after rootstrap unpacking. Look:
 [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~]  sb-conf
 re
 -f
 [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~]  ls -l
 /targets/maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c/ |grep opt
 drwxrwxr-x  2 1005 1006 4096 Oct 21 23:56 opt
 [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~]  sb-conf
 in
 --etc --devkits
 [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~]  ls -l
 /targets/maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c/ |grep opt
 drwxrwxr-x   2 builder1 builder1 4096 Oct 21 23:56 opt
 [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~]  sb-conf
 in
 --fakeroot Installing fakeroot version 1.4.2.1...
 [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~]  ls -l
 /targets/maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c/ |grep opt
 drwxrwxr-x   2 builder1 builder1 4096 Oct 21 23:56 opt
 [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~]  sb-conf
 rs
 /scratchbox/packages/maemo-sdk-rootstrap_5.0_armel.tgz

Re: QA queue determine required thumbs down for removal

2009/10/22 Niels Breet ni...@maemo.org:
 On Thu, October 22, 2009 15:31, gary liquid wrote:
 There is no interface to pull apps manually.
 if testing identifies a blocker, the maintainer has no way but to leave it
  there wasting the other testers time.

 This reminds me. If a maintainer votes his own app down, it should be
 removed instantly.

We should also think about dependencies when packages are removed from
-testing.
If maintainer doesn't like his library and removes it what will happen
with another
application, which depends on this library? Theoretically it should be
also removed from -testing or rebuilt with older version of library if
it exists.
This situation can be resolved if autobuilder would build dependencies
only from extras.
However it can slow down the whole process, because developers would
have to wait
untill all needed libraries go to extras before they'll be able to
build their packages.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: AutoBuilders ignoring a depenancy

2009/10/22 Nathan Anderson nat...@andersonsplace.net:
 Ed,

I resubmitted my package; and it decided to ignore one of my
 dependency.  (But it did pull in the optified packages! g)

 https://garage.maemo.org/builder/fremantle/sword_1.6.0a-0maemo1/armel.root.l
 og.OK.txt Shows:

 2009-10-22 17:46:55] Try to install static depends:
 libcurl3 libcurl3-dev libicu42 libicu42-dev clucene-core clucene-core-dev
 zlib1g-dev python2.5 python2.5-dev maemo-optify

 However the dsc file has:
 https://garage.maemo.org/builder/fremantle/sword_1.6.0a-0maemo1/sources/swor
 d_1.6.0a-0maemo1.dsc

 Build-Depends: debhelper (= 5), libcurl3, libcurl3-dev, libicu42,
 libicu42-dev, clucene-core, clucene-core-dev, zlib1g-dev, zlib1g, python2.5,
 python2.5-dev, swig1.3, maemo-optify

It ignored my swig1.3 request.   The default swig inside
 scratchbox/sdk is 1.3.29 -- It generates totally broken code for this
 package so I took the debian packaged 1.3.40 and added the minor changes to
 it to make it work on maemo.   It is listed in the extras repository as
 swig1.3

Just put swig1.3 (= 1.3.40) into Build-depends: line of your package.
It should solve the problem.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Maemo-Optify Builder Bots = Broken?

2009/10/22 Julius Luukko julle.luu...@quicknet.inet.fi:

 But did you forgot to do it for x86 target? armel builds now fine, but i386
 does not [1]:

Oops, sorry. My bad.

Done. Should work now.

Just in case someone wants to do the same for their rootstraps. This
is what I did:

gunzip /scratchbox/packages/maemo-sdk-rootstrap_5.0_i386.tgz 
/tmp/maemo-sdk-rootstrap_5.0_i386.tar
tar --delete -f /tmp/maemo-sdk-rootstrap_5.0_i386.tar ./opt
mv /scratchbox/packages/maemo-sdk-rootstrap_5.0_i386.tgz
/scratchbox/packages/maemo-sdk-rootstrap_5.0_i386.tgz.withopt
gzip /tmp/maemo-sdk-rootstrap_5.0_i386.tar 
/scratchbox/packages/maemo-sdk-rootstrap_5.0_i386.tar.gz

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Maemo-Optify Builder Bots = Broken?

2009/10/21 Nathan Anderson nat...@andersonsplace.net:
...
 Selecting previously deselected package clucene-core.
 Unpacking clucene-core (from .../clucene-core_0.9.21b-0maemo1_armel.deb) ...
 dpkg: error processing
 /var/cache/apt/archives/clucene-core_0.9.21b-0maemo1_armel.deb (--unpack):
  trying to overwrite `/opt', which is also in package base-files
  
 Uhm, this is not good.   Each of my optified packages throws this error.
 That kinda makes optifing the libraries a pointless exercise if I can't use
 them later in the buildbot.  And Lib-icu is about 16 MEGS of libraries, so I
 would think it would be a great canidate for optification. Do I need to
 resubmit everything w/o optification, or are the build bots broken?

Have you tried to reproduce this issue in your build environment by
installing your library and base-files locally inside scratchbox?

Below are my attempts to reproduce and fix the problem:

This is what I see in autobulder environment:
 grep /opt$ /var/lib/dpkg/info/base-files.list
/opt
It means that /opt belongs to base-files package.
And I can easily reproduce the error if I try to install any package
with /opt directory inside it:
  fakeroot apt-get install clucene-core
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  clucene-core
0 upgraded, 1 newly installed, 0 to remove and 2 not upgraded.
Need to get 319kB of archives.
After unpacking 1085kB of additional disk space will be used.
WARNING: The following packages cannot be authenticated!
  clucene-core
Install these packages without verification [y/N]? y
Get:1 http://osso.stage.dmz fremantle/free clucene-core 0.9.21b-0maemo1 [319kB]
Fetched 319kB in 0s (329kB/s)
/scratchbox/tools/bin/sh: line 1: /usr/sbin/dpkg-preconfigure: No such
file or directory
Selecting previously deselected package clucene-core.
(Reading database ... 6395 files and directories currently installed.)
Unpacking clucene-core (from .../clucene-core_0.9.21b-0maemo1_armel.deb) ...
dpkg: error processing
/var/cache/apt/archives/clucene-core_0.9.21b-0maemo1_armel.deb
(--unpack):
 trying to overwrite `/opt', which is also in package base-files
dpkg-deb: subprocess paste killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/clucene-core_0.9.21b-0maemo1_armel.deb
E: Sub-process /scratchbox/devkits/debian-etch/bin/dpkg returned an
error code (1)

Hmm. Let's remove /opt from base-files.list and see what happens:
Unpacking clucene-core (from .../clucene-core_0.9.21b-0maemo1_armel.deb) ...
dpkg: error processing
/var/cache/apt/archives/clucene-core_0.9.21b-0maemo1_armel.deb
(--unpack):
 error creating directory `./opt': Permission denied
dpkg-deb: subprocess paste killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/clucene-core_0.9.21b-0maemo1_armel.deb

It didn't help, but we can see that dpkg tries to create directory
/opt and fails because symlink /opt already exists.
OK, then. Let's put /opt back to base-files.list and create directory
/opt instead of symlink:
$ sudo rm /scratchbox/users/ed/opt
$ sudo mkdir /scratchbox/users/ed/opt
$ sudo chown ed /scratchbox/users/ed/opt
And try again:
 fakeroot apt-get install clucene-core
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  clucene-core
0 upgraded, 1 newly installed, 0 to remove and 2 not upgraded.
Need to get 0B/319kB of archives.
After unpacking 1085kB of additional disk space will be used.
WARNING: The following packages cannot be authenticated!
  clucene-core
Install these packages without verification [y/N]? y
/scratchbox/tools/bin/sh: line 1: /usr/sbin/dpkg-preconfigure: No such
file or directory
(Reading database ... 6395 files and directories currently installed.)
Unpacking clucene-core (from .../clucene-core_0.9.21b-0maemo1_armel.deb) ...
Setting up clucene-core (0.9.21b-0maemo1) ...

It works! Hurray! :)

So, my conclusion is this is scratchbox problem, not autobuilder one.
It's not autobuilder, who creates /opt symlinks. They're created by
scratchbox for each user.
May be scratchbox guys can explain how to fix it properly. Of course I
can remove symlinks and create directories instead for all builders,
but may be there is better way to solve the problem?

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Maemo-Optify Builder Bots = Broken?

2009/10/21 Nathan Anderson nat...@andersonsplace.net:
 Ed,

I have actually installed all the packages I have built and
 submitted to extras _inside_ my scratchbox from extras(-devel/testing)
Good. In this case we just need to understand what's the difference between
your environment and autobuilder one.

Can you show me output of the following commands run inside scratchbox:
ls -l / |grep opt
dpkg -l base-files

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Maemo-Optify Builder Bots = Broken?

2009/10/21 Nathan Anderson nat...@andersonsplace.net:
 Ed,

Sure can (and following the chain).

 ls -l / | grep opt
lrwxrwxrwx1 root  root  18 Oct  6 22:36 opt -
 /targets/links/opt

 ls -l /targets/links/ | grep opt
lrwxrwxrwx  1 maemo 1000 26 Oct 19 16:55 opt -
 /targets/FREMANTLE_X86/opt

 ls -l /targets/FREMANTLE_X86 | grep opt
drwxr-xr-x   4 maemo sbox 4096 Oct  7 11:39 opt


 Dpkg -l base-files
 Desired=Unknown/Install/Remove/Purge/Hold
 | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
 |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err:
 uppercase=bad)
 ||/ Name Version  Description
 +++---==
 ==
 ii  base-files   3.1.osso2+3.1.10.osso23+ Debian base system
 miscellaneous files

Looks the same as in autobuilder environment.

Can you show versions of scratchbox packages?
This is what I have on  autobuilder host:
$ dpkg -l |grep scratchbox
ii  scratchbox-core   1.0.16
   Scratchbox base system
ii  scratchbox-devkit-apt-https   1.0.10
   APT HTTPS devkit for Scratchbox
ii  scratchbox-devkit-cputransp   1.0.9
   CPU transparency methods
ii  scratchbox-devkit-debian  1.0.10
   Debian tools for Scratchbox
ii  scratchbox-devkit-doctools1.0.13
   Doctools for Scratchbox
ii  scratchbox-devkit-git 1.0.1
   Git for Scratchbox
ii  scratchbox-devkit-maemo3  1.0.3
   Maemo 3 devkit for Scratchbox
ii  scratchbox-devkit-perl1.0.4
   Perl modules for Scratchbox
ii  scratchbox-devkit-qemu0.10.0-0sb5
   Qemu scratchbox devkit
ii  scratchbox-devkit-svn 1.0
   Subversion devkit for Scratchbox
ii  scratchbox-libs   1.0.16
   Scratchbox libraries
ii  scratchbox-toolchain-cs2005q3.2-glibc2.5-arm  1.0.7.2
   cs2005q3.2-glibc2.5-arm compiler for Scratch
ii  scratchbox-toolchain-cs2005q3.2-glibc2.5-i386 1.0.7
   cs2005q3.2-glibc2.5-i386 compiler for Scratc
ii  scratchbox-toolchain-cs2007q3-glibc2.5-arm7   1.0.12-10
   cs2007q3-glibc2.5-arm7 compiler for Scratchb
ii  scratchbox-toolchain-cs2007q3-glibc2.5-i486   1.0.12-8
   cs2007q3-glibc2.5-i486 compiler for Scratchb
ii  scratchbox-toolchain-host-gcc 1.0.16
   Scratchbox host-gcc toolchain


-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Maemo-Optify Builder Bots = Broken?

2009/10/21 Nathan Anderson nat...@andersonsplace.net:
 Ed,

Sure can (and following the chain).

 ls -l / | grep opt
lrwxrwxrwx1 root  root  18 Oct  6 22:36 opt -
 /targets/links/opt

 ls -l /targets/links/ | grep opt
lrwxrwxrwx  1 maemo 1000 26 Oct 19 16:55 opt -
 /targets/FREMANTLE_X86/opt

 ls -l /targets/FREMANTLE_X86 | grep opt
drwxr-xr-x   4 maemo sbox 4096 Oct  7 11:39 opt

Oops, sorry. I've overlooked that you're using X86 target.
Autobuilder used armel target when it failed. You can see it here:
https://garage.maemo.org/builder/fremantle/sword_1.6.0a-0maemo1/armel.root.log.FAILED.txt

Try to install your packages in armel target, please.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Can't find lt_dlopen in autobuilder for DIABLO

2009-10-04 Thread Ed Bartosh

Hi,

Short answer:

Change libltdl3-dev to libltdl3-dev (= 1.5.22) in Build-depends line
of your debian/control. It should help to fix your build.

Long answer:
-

I've debugged this situation a bit and found out that libltdl3-dev is
provided by scratchbox:
[sbox-maemo4-arm: ~/libmp3splt-0.5.7a]  dpkg-checkbuilddeps
: Using Scratchbox tools to satisfy builddeps
: Dependency provided by Scratchbox: libtool
: Dependency provided by Scratchbox: libltdl3-dev
: Dependency provided by Scratchbox: autotools-dev

and scratchbox really provides this library:
find /scratchbox/compilers/cs2005q3.2-glibc2.5-arm/ -name *ltdl*
/scratchbox/compilers/cs2005q3.2-glibc2.5-arm/arch_tools/share/aclocal/ltdl.m4
/scratchbox/compilers/cs2005q3.2-glibc2.5-arm/arch_tools/share/libtool/libltdl
/scratchbox/compilers/cs2005q3.2-glibc2.5-arm/arch_tools/share/libtool/libltdl/ltdl.c
/scratchbox/compilers/cs2005q3.2-glibc2.5-arm/arch_tools/share/libtool/libltdl/ltdl.h
/scratchbox/compilers/cs2005q3.2-glibc2.5-arm/arch_tools/lib/libltdl.so.3.1.2
/scratchbox/compilers/cs2005q3.2-glibc2.5-arm/arch_tools/lib/libltdl.a
/scratchbox/compilers/cs2005q3.2-glibc2.5-arm/arch_tools/lib/libltdl.la
/scratchbox/compilers/cs2005q3.2-glibc2.5-arm/arch_tools/lib/libltdl.so.3
/scratchbox/compilers/cs2005q3.2-glibc2.5-arm/arch_tools/lib/libltdl.so
/scratchbox/compilers/cs2005q3.2-glibc2.5-arm/arch_tools/include/ltdl.h

However configure couldn't find it or it finds it but for some reason
can't use it. I decided not to investigate why it happens and just try
to make build to use another libltdl. Scratchbox provides libltdl3-dev
version 1.5.20. You can see this in here:
/scratchbox/compilers/cs2005q3.2-glibc2.5-arm/deb_list/libtool.
Fortunately we have libltdl3-dev 1.5.22-4maemo1 in SDK repo. So, to
make build use version from repo we need to change build dependency of
your package from libltdl3-dev to libltdl3-dev (= 1.5.22). After that
it was built just fine for me.

Another, proper way was to keep digging into configure magic and find
out why it doesn't like libltdl provided by scratchbox, which would
most probalby lead us to the long way of waiting for the fix from
scratchbox guys. May be I'm too lazy or too old for this, but I
decided to leave this exercise to someone else :)

Regards,
Ed

2009/10/4 Bruce Forsberg bruce.forsb...@gmail.com:
 I am trying to port the mp3splt package to DIABLO. I am have problems
 getting the library package to build with the autobuilder. It does not
 seem to be able to find the libltdl library. I have included libtool,
 libltdl3, libltdl3-dev in the Build-Depends of the control file but
 this does not seem to work as the configure file gives the error:

 checking ltdl.h usability... no
 checking ltdl.h presence... no
 checking for ltdl.h... no
 checking whether to use included libltdl...
 .
 .
 .
 checking for lt_dlopen in -lltdl... no
 configure: error: libltdl not found - check libtool installation !

 This all works in my scratchbox DIABLO_ARMEL environment. Does anybody
 have any ideas on what I need to add to get this to work. I believe
 that mp3splt uses plugins so I need this to work. The error files are
 at:
 https://garage.maemo.org/builder/diablo/libmp3splt_0.5.7a-maemo1/

 The control file is (I have tried many combinations):
 Source: libmp3splt
 Priority: optional
 Maintainer: Munteanu Alexandru Ionut (io_alex_2...@yahoo.fr)
 Build-Depends: debhelper (= 5), libtool, libltdl3-dev, libvorbis-dev,
 libmad0-dev, libid3tag0-dev, autotools-dev
 Standards-Version: 3.6.0
 Section: user/multimedia

 Package: libmp3splt0
 Section: libs
 Architecture: any
 Depends: libmp3splt
 Description: Library that splits MP3 and Ogg Vorbis files without reencoding
  Used to split MP3 (VBR supported) and Ogg Vorbis
  files into smaller files without decoding. Useful for splitting albums, 
 either
  manually, using freedb.org data, or .cue files ...
  .
  Homepage: http://mp3splt.sourceforge.net/

 Package: libmp3splt0-dev
 Section: libdevel
 Architecture: any
 Depends: libmp3splt0
 Description:  Library that splits MP3 and Ogg Vorbis files without reencoding
  Used to split MP3 (VBR supported) and Ogg Vorbis
  files into smaller files without decoding. Useful for splitting albums, 
 either
  manually, using freedb.org data, or .cue files ...
  .
  This is the package you need to develop or compile applications that
 use mp3splt.


 Thanks for any help. I am a novice debian developer.

 Thanks,
 Bruce
 ___
 maemo-developers mailing list
 maemo-developers@maemo.org
 https://lists.maemo.org/mailman/listinfo/maemo-developers




-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Allowed sections for Fremantle

2009-09-24 Thread Ed Bartosh

Hi,

Here are new categories suggested by community:
http://wiki.maemo.org/Task:Package_categories

Don't ask me why official SDK documentation contains another list :)

Regards,
Ed

2009/9/24 Luca Donaggio donag...@gmail.com:
 According to [1], the allowed user/* sections are:

 user/accessories Accessories
 user/communication Communication
 user/games Games
 user/multimedia Multimedia
 user/office Office
 user/other Other
 user/programming Programming
 user/support Support
 user/themes Themes
 user/tools Tools

 But the package interface seems to think differently; the page for grsync
 [2] says:

 Section:user/accessories
 Warning: This package is not using one of the allowed user/* sections!
 What's wrong? The wiki or the package interface? Or maybe the reason is
 another one?



 [1]
 http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging%2C_Deploying_and_Distributing#Sections
 [2]
 https://maemo.org/packages/package_instance/view/fremantle_extras-devel_free_i386/grsync/0.6.3-mameo1/


-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Diablo Libssl broken in extras-devel

2009-09-09 Thread Ed Bartosh

2009/9/9 Jeremiah Foster jerem...@maemo.org:
 On Sep 8, 2009, at 9:43, Ed Bartosh wrote:

 BTW, before removing it from extras-devel try to find all packages
 which depend on it and after removing libssl reupload them to the
 autobuilder. They will be rebuilt with proper openssl then.

 How does that work? I thought the problem was that it was being built
 from stuff from extras-devel - how is it going to suddenly find the
 right libs?

Autobuilder uses extras-devel and SDK repos to satisfy build
dependencies. So, if you remove libssl from extras-devel
and reindex repository next builds will use proper libssl from SDK
repo. SDK version of libssl should be the same as
device one.


-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Diablo Libssl broken in extras-devel

2009-09-08 Thread Ed Bartosh

2009/9/8 Jeremiah Foster jerem...@maemo.org:

 On Sep 8, 2009, at 24:58, Graham Cobb wrote:

 Jeremiah,

 I haven't checked this out myself but I **think** what Till is
 seeing is that
 the autobuilder builds his app with the libssl package from extras-
 devel and
 ends up with a versioned dependency on that specific version of
 libssl.
 However, the extras-devel version of libssl cannot be installed
 because it
 conflicts with a Nokia package (presumably it is one of the
 libraries Nokia
 installs and does not allow to be replaced).

 If this guess is right then the new version of libssl should be
 removed from
 extras-devel as it can never be used by anyone.  But you might want
 to check
 out who uploaded it to see if you can find out why.


 Very interesting. I think you are right because someone asked my
 yesterday to remove libssl since the version they uploaded ddin't
 work. I imagine they uploaded libssl again since they need it as a
 dependency.

Here is the summary log of latest libssl uploaded to autobuilder:
https://garage.maemo.org/builder/diablo/openssl_0.9.8g-15maemo4+0m5/summary.log
You can see uploader name there and ask him why he uploaded it.

BTW, before removing it from extras-devel try to find all packages
which depend on it and after removing libssl reupload them to the
autobuilder. They will be rebuilt with proper openssl then.

 Ed and Niels: Shouldn't we disallow uploading of packages that are un-
 installable on the tablet?

That was the idea of package installability check which I wrote
recently. I showed you the logs it produced.
Unfortunately it's still under consideration of Nokia legal if we can
use it outside Nokia.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Autobuilder: building svn tags from garage

2009-09-06 Thread Ed Bartosh

2009/8/31 Marius Vollmer marius.voll...@nokia.com:
 ext Ed Bartosh bart...@gmail.com writes:

 As I already said building in a proper order is already solved task.
 There is no need to upload packages in build order if it can be done
 automatically. It will only create extra job for developers.

 Here is something to consider:

 Source packages produce binary packages and they have dependies on
 binary packages.  If you have a set of source packages, you need to
 order them so that any source package that has a dependency on a binary
 package is build after the source package that produces that binary.
 This is the obvious part.

 The interesting bit is this: Binary packages have dependencies on other
 binary packages.  If you depend on a binary package that depends on
 another binary package, you also indirectly depend on that other
 package.  This means that when ordering source packages, we need to look
 at all direct _and_indirect_ dependencies it has on binary packages, not
 just the direct dependencies.

True.

 I think our internal buildbot (who does order source packages by their
 dependencies) only looks at the direct dependencies.

Yes. And I'm going to use that code in autobuilder without
redesigning. At least now. Later on I might consider to implement
analyzing binary dependencies, but it will happen only if it's really
needed. I doubt that this can be showstopper for first implementation
of multiple package builds.

 Now, there is a slight complication: dependencies between binary
 packages are computed at build-time.  That is, they are not known before
 actually building the binary package.  The problem is still solveable if
 we interleave building with sorting: I.e., we start with an incomplete
 graph of dependencies (that contains all source packages and the binary
 packages they produce as nodes, the dependencies from source to binary
 as arrows, but not the dependencies between binary packages) and start
 building those source packages that do not have any dependencies on
 other packages in the graph.  Then we look at the packages that have
 just been built and update the graph with the new dependencies.

 Then there are cycles of dependencies, of course, or more correctly,
 stronly connected components in the dependency graph.  Absent any hints
 in the source packages themselves, these strongly connected components
 need to be broken up by humans, I think.

Thank you for the commentssuggstions. It definitely make sense to
implement if we're talking about perfect build system. However for me
it doesn't sound like thing to do right now.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Autobuilder: building svn tags from garage

2009-09-06 Thread Ed Bartosh

2009/8/31 Marius Vollmer marius.voll...@nokia.com:
 ext Ed Bartosh bart...@gmail.com writes:

 [To upload a multi-package build request] It might be enough to just
 allow more than one paragraph in the .changes files, and make the
 guarantees that packages are build in order of their
 build-dependencies and the build aborts as soon as one package fails.
 (If I understand right what people are looking for.)

 Adding new paragraph would require to make a tool or change existing
 tools, right?

 Yes, of course.  I think ideally dput should be changed to understand
 the new .changes format.  A entry in .dput.cf could say for each remote
 whether it is supported or not (the default being no), so that people
 don't upload multi-package requests to queues that don't support it.

 Maybe it is a good idea to add a new 'header' paragraph at the beginning
 of multi-package .changes file so that queues that don't support it fail
 very visibly and don't just ignore the second and later paragraphs.

I see this way as much more complicated than way I proposed in this
thread. Please, read this message and comment if you don't mind:
http://lists.maemo.org/pipermail/maemo-developers/2009-August/020315.html

It would also require to modify dput just a bit, but no changes to
.changes format are required.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: upload to extra

2009-08-31 Thread Ed Bartosh

Hi,

It's available and works, but sometimes gives the same error to me
also. Last time I've asked admins they told me that reason can be
network load of the host or something like that.

2009/8/31 Fred f...@lefevere-laoide.net:
 Hi,

 Is the dput method still available for uploading to extras ?

 Or do I have to do something to re-activate my garage account since the
 new system ?

 I'm fredoll on garage and the account/index2.php page gives me the right
 public ssh key.
  but I always get authent... denied

 Thanks for your help

 Fred
 ___
 maemo-developers mailing list
 maemo-developers@maemo.org
 https://lists.maemo.org/mailman/listinfo/maemo-developers




-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: [lists] Re: Subversion and libesd?

2009-08-28 Thread Ed Bartosh

Hi,

And what about libkpathsea4? Any chance for it?

2009/8/28 Jeremiah Foster jerem...@jeremiahfoster.com:

 It has gone through the builder, but has not shown up in the file
 system as a deb yet.



-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Autobuilder: building svn tags from garage

2009-08-27 Thread Ed Bartosh

2009/8/27 Henrik Hedberg henrik.hedb...@innologies.fi:
 Graham Cobb wrote:
   Personally, I would much rather the autobuilder dependency problem
 was fixed
   (with some method for submiting multiple packages with build
 dependencies and
   having them build in the right order, with the dependencies being
 satisfied)
   instead of this particular feature.

    This should definitely be fixed first and soon. Thanks! :)
If everybody thinks that support of multiple package builds is more
important I'll do that.


 Ed Bartosh wrote:
   Submitting is the main problem. As far as I know dput can't upload
   several packages at the same time. Any ideas how to do this?

    I find that you all are thinking this too complicated. Depency
 graphs, web based interfaces, discussion about extending the dput and
 such...

    The current situation is that the build is triggered when a .dsc
 file has been uploaded. Fine.

I'm going to change the code as Marius suggested. .changes will
trigger the build.

    Let's require that a developer must upload .dsc files (or packages,
 if you like) in the order he or she wants the packages to be build.
 Fairly reasonable, I think. There are timestamps, and scp modifies those
 when it uploads a file into the server. Simple as that. Even make is
 using those magical timestamps.

For one package it's already implemented in dput. .changes file is
uploaded after all sources are uploaded.
For multiple packages this is the problem, which we're trying to solve here.

    Now, the only real modification is that the autobuilder should use
 the latest version of a package that has been built - not some ancient
 package found from the repository.

    So, if a package A depends on a package B, I should upload the .dsc
 file of the package B first. I can upload the .dsc file of the package A
 immediately after that. The autobuilder builds the package B first,
 because it came first (the timestamp is older), and then the package A.
 When building the package A, it is using the package B from _the latest
 build_, not from the repository.

As I already said building in a proper order is already solved task.
There is no need to upload packages in build order if it can be done
automatically. It will only create extra job for developers.

    I think the main problem with the current implementation is that
 even if you have uploaded a package and if it has been successfully
 built, it is not used when building other packages immediately after
 that. You have to wait unspecified time until the package hits the
 repository. Without that delay, one could even write a sequential upload
 script based on email build notifications. (Yes, I know that I could
 repeatedly download the Packages file from the repository, search the
 version number of my library packages, and trigger the uploading of my
 application based on that knowledge. Too complicated!)

True. But if we manage to define a group of packages as one build I
can solve this problem by creating local repo, adding packages to it
as soon as they're built and using it for the build.
Of course better solutions would be to make adding to extras-devel
work faster, but i tend to think it's near to impossible :)

    If you care the situation when building fails, you could write an
 additional rule that all other packages from the same uploader are
 removed from the build queue if building of a package fails. Thus, if a
 package A depends on a package B, but the building of the package B
 fails, the autobuilder is not building the package A if it had already
 been uploaded into the queue.

If group of the packages is in the separate directory this is even
better. The same uploader can upload several groups and failure of one
group wouldn't cause removing of others.
This is what I've almost achieved by using dput.cf *_upload_command keywords.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Autobuilder: building svn tags from garage

2009-08-27 Thread Ed Bartosh

2009/8/27 Vlad Vasiliev v...@gas.by:
 Graham Cobb wrote:
 skip
 ...

 This can be done through a web interface, but I don't think many of the
 hardcore coders, needing this functionality, would use that?


 I would if it meant the autobuilder would handle the dependencies!  I would
 even manually create the dependency graph using a web interface if analysing
 Build-Depends is too hard!

 It would be good if there was a way to upload the files using (say) scp to a
 staging area and then trigger the build using the web interface.

 Graham



 Hi.


 I think many packages don't need in those very complicated things.
 Maybe for begin Ed will create possibility to build package in
 Autobuilder  using tag from svn.

Most of them actually. But looking at this thread I see that support
of multiple package builds is more welcome here than building tags.


-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Autobuilder: building svn tags from garage

2009-08-27 Thread Ed Bartosh

2009/8/27 Jeremiah Foster jerem...@jeremiahfoster.com:

 On Aug 26, 2009, at 19:52, Ed Bartosh wrote:

 2009/8/26 Jeremiah Foster jerem...@jeremiahfoster.com:

 On Aug 26, 2009, at 18:05, Andrew Flegg wrote:

 On Wed, Aug 26, 2009 at 16:25, Ed Bartoshbart...@gmail.com wrote:

 2009/8/26 Andrew Flegg and...@bleb.org:

 On Wed, Aug 26, 2009 at 16:17, Ed Bartoshbart...@gmail.com wrote:

 This is a good point - we have a chance to reduce the bloat of the
 debian system that is designed for at least eight official
 architectures when we build only two. Plus there might be a way to
 innovate and to simplify the entire build process over time which
 would be a huge win for developers.

 I understand that. If you may notice we're already using our own
 builder instead of wanna-build or whatever Debian uses for this.

 Some of the upstream build stuff is quite good though. And is python really
 the right tool to do builds? As far as I am concerned it has some drawbacks
 in this particular area:

        1. The GIL problems make it unsuitable for multicore machines
        2. Python is slow in general
        3. The vast majority of existing build systems are written in
 something else, so there is a bit of wheel re-invention with python

This is a bit out of scope of this thread. If you're really interested
in comparing Python capabilities with other programming languages in
this area feel free to create new thread for that.

Regarding slowness of the Maemo build system in my opinion it isn't a
result of using Python, but lack of resources (only one build host)
and brain-damaged repository management system.
And if it's not changed in near future I doubt that change to another
build system will help.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Autobuilder: building svn tags from garage

Hi,

I'm thinking about to add this feature to autobuilder. With developers
don't need to prepare package's source and upload it to autobuilder
queue. They just need to tag the sources.

This is how i plan to implement it:
1. Svn hook will be creating description file or record in the
database if new tag appears in tags/autobuilder/product directory
for any garage project.
2. Special cron job will fetch new tag, build source package and put
it into autobuilder incoming directory.
3. Autobuilder will build it the same way as it does currently.

How does it look? Any ideas/suggestions?

PS: If this feature will be usable I can add processing of git tags as well.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Autobuilder: building svn tags from garage

2009/8/26 Anderson Lizardo anderson.liza...@openbossa.org:
 On Wed, Aug 26, 2009 at 6:54 AM, Ed Bartoshbart...@gmail.com wrote:
 Hi,

 I'm thinking about to add this feature to autobuilder. With developers
 don't need to prepare package's source and upload it to autobuilder
 queue. They just need to tag the sources.

 This is how i plan to implement it:
 1. Svn hook will be creating description file or record in the
 database if new tag appears in tags/autobuilder/product directory
 for any garage project.
 2. Special cron job will fetch new tag, build source package and put
 it into autobuilder incoming directory.
 3. Autobuilder will build it the same way as it does currently.

 How does it look? Any ideas/suggestions?

 It would be nice if it could support those projects that keep only the
 debian/ directory under revision control. We do that for many PyMaemo
 packages, because there is no point keeping the entire source if we
 are only touching the debian packaging. Then we currently using some
 scripts that generate the source packages for us (and even build
 locally for testing).

 One idea might be to use some custom field in debian/control (see
 http://www.debian.org/doc/debian-policy/ch-controlfields.html#s5.7)
 that point to the original .dsc file in Debian, e.g.:

 XC-Original-Dsc:
 http://ftp.de.debian.org/debian/pool/main/d/dbus-python/dbus-python_0.83.0-1.dsc

 Then in case the autobuilder would simply do:

 dget url_to_dsc
 dpkg-source -x *.dsc
 rm -rf */debian
 cp -a /path/to/debian */debian

 The reason it should not point simply to the orig tarball is that some
 (misbehaved IMHO) packages keep changes directly on the sources, that
 are applied only when the diff.gz is applied with dpkg-source.


Added to the TODO list.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Autobuilder: building svn tags from garage

2009/8/26 Graham Cobb g+...@cobb.uk.net:
 On Wednesday 26 August 2009 11:54:13 Ed Bartosh wrote:
 I'm thinking about to add this feature to autobuilder. With developers
 don't need to prepare package's source and upload it to autobuilder
 queue. They just need to tag the sources.

 How is the version specified?  Is the tag name used?

Version is specified in debian/changelog, which is standard way for
Debian packages, I believe.

 Will it handle build dependencies?  I.e. if I create an autobuild tag for
 libaaa and also for application-aaa (with a build dependency on libaaa), will
 it submit the library build first?  Will it wait for it to finish before
 submitting the application build?

This is another story and much more complicated to implement.
However if community wants this we can start to discuss possible ways
to implement it.

 Personally, I would much rather the autobuilder dependency problem was fixed
 (with some method for submiting multiple packages with build dependencies and
 having them build in the right order, with the dependencies being satisfied)
 instead of this particular feature.

Submitting is the main problem. As far as I know dput can't upload
several packages at the same time. Any ideas how to do this?


 But I realise others may disagree!
True. Most of developers developing one application and don't care
about this feature.
Main supporters for it is your project, pymaemo, efl and a few others,
who has a lot of packages. And most of them have their own workarounds
implemented.

-- 
BR,
Ed
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Autobuilder: building svn tags from garage