On Thu, Dec 3, 2009 at 6:46 AM, Andrew Flegg wrote:
> 2009/12/2 Anderson Lizardo :
>>
>> All files installed under e.g. /usr/lib/python2.5 go "automatically"
>> to /opt. But note that the package itself is unchanged (because
>> pymaemo-optify takes care of handling these mount binds), so there is
2009/12/2 Anderson Lizardo :
>
> All files installed under e.g. /usr/lib/python2.5 go "automatically"
> to /opt. But note that the package itself is unchanged (because
> pymaemo-optify takes care of handling these mount binds), so there is
> no way for maemo-optify to know whether to optify some Py
On Wed, Dec 2, 2009 at 5:20 PM, Nathan Anderson
wrote:
> Anderson Lizardo,
>
> Unless I misunderstood; if the package itself has a /opt path in it
> the maemo-optify won't run on it. So if you are "installing" anything
> (even one file) under the /opt path (which based on what I see yo
cause the maemo-optify to not run.
Nathan Anderson
-Original Message-
From: maemo-developers-boun...@maemo.org
[mailto:maemo-developers-boun...@maemo.org] On Behalf Of Anderson Lizardo
Sent: Wednesday, December 02, 2009 11:56 AM
To: Marius Vollmer
Cc: maemo-developers@maemo.org
Subject: R
On Wed, Dec 2, 2009 at 12:56 PM, Marius Vollmer
wrote:
> ext Anderson Lizardo writes:
>
>> 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
>> opti
ext Anderson Lizardo writes:
> 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).
If a package alre
On Wed, Dec 2, 2009 at 9:43 AM, Ed Bartosh wrote:
> 2009/12/2 Anderson Lizardo :
>> 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
2009/12/2 Anderson Lizardo :
> On Wed, Dec 2, 2009 at 9:02 AM, Ed Bartosh wrote:
>> 2009/11/9 Marius Vollmer :
>>
When autobuilder expected to start to optify packages without
debian/optify in them?
>>>
>>> I don't know. We certainly need to tune the heuristic of maemo-optify
>>> first
On Wed, Dec 2, 2009 at 9:02 AM, Ed Bartosh wrote:
> 2009/11/9 Marius Vollmer :
>
>>> When autobuilder expected to start to optify packages without
>>> debian/optify in them?
>>
>> I don't know. We certainly need to tune the heuristic of maemo-optify
>> first to handle Python.
>>
> As far as I see
2009/11/9 Marius Vollmer :
>> When autobuilder expected to start to optify packages without
>> debian/optify in them?
>
> I don't know. We certainly need to tune the heuristic of maemo-optify
> first to handle Python.
>
As far as I see Python is optified now. When we should do next step?
--
BR,
2009/11/9 Marius Vollmer :
>
>> When autobuilder expected to start to optify packages without
>> debian/optify in them?
>
> I don't know. We certainly need to tune the heuristic of maemo-optify
> first to handle Python.
>
Just in case you need my help. I'm here for this week. My 2 weeks
vacation s
ext Ed Bartosh writes:
>> Maemo-optify can be invoked in a number of ways. I'll explain what
>> happens when the modified dpkg-buildpackage calls
>>
>>maemo-optify-deb --auto
>
> Which is how it's used in modified dpkg-buildpackage, right?
Correct.
>> after running ./debian/rules build.
>>
2009/11/6 Marius Vollmer :
> ext Ed Bartosh writes:
>
>> I've discussed this with sbdmock author and we decided to make small
>> change to sbdmock: New configurable action will be introduced. This
>> action will be executed by sbdmock between unpacking rootstrap and
>> installing build-deps.
>>
>>
From: ext Ed Bartosh [bart...@gmail.com]
>2009/11/4 Marius Vollmer :
>> ext Ed Bartosh writes:
>>
>>> Has anybody tried this devkit? Does it work as expected?
>>
>> I tried it by building (slightly modified versions of) xournal, hermes,
>> and libliqbase, and everything went as expected.
>
> Can y
2009/11/4 Marius Vollmer :
> ext Ed Bartosh writes:
>
>> 2009/11/3 Marius Vollmer :
>>
>>> Luckily, with apt-get upgrade being run during build, we don't need
>>> to change dpkg-checkbuilddeps and we can just update build-essential.
>>> (Unless I am missing something. Do I?)
>>
>> rootstrap is use
On Wed, Nov 4, 2009 at 17:52, Ed Bartosh wrote:
> 2009/11/4 Marius Vollmer :
>> ext Ed Bartosh writes:
>>
>>> Has anybody tried this devkit? Does it work as expected?
>>
>> I tried it by building (slightly modified versions of) xournal, hermes,
>> and libliqbase, and everything went as expected.
2009/11/4 Marius Vollmer :
> ext Ed Bartosh writes:
>
>> Has anybody tried this devkit? Does it work as expected?
>
> I tried it by building (slightly modified versions of) xournal, hermes,
> and libliqbase, and everything went as expected.
>
Can you elaborate a bit? Is it implemented the way prop
ext Ed Bartosh writes:
> 2009/11/3 Marius Vollmer :
>
>> Luckily, with apt-get upgrade being run during build, we don't need
>> to change dpkg-checkbuilddeps and we can just update build-essential.
>> (Unless I am missing something. Do I?)
>
> rootstrap is used as a build-essentials by sbdmock. T
ext Ed Bartosh writes:
>> 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
Yeah, it tells me
ext Ed Bartosh writes:
> Has anybody tried this devkit? Does it work as expected?
I tried it by building (slightly modified versions of) xournal, hermes,
and libliqbase, and everything went as expected.
The slight modification was "echo auto >debian/optify" to turn on
optification.
> Should we
ext Graham Cobb writes:
> I don't object to the autobuilder running apt-get upgrade but I would
> object very strongly if dpkg-buildpackage were to do an upgrade!
> [...]
> I am not sure anyone was proposing that dpkg-buildpackage would do an
> upgrade but wanted to point out that it can't befo
I did start a project to do that but i never gotr very far with it. But we
really don't need it now -- sbdmock serves that need and has the advantage that
it is the tool the autobuilder uses so you can use it to make sure you will
build in the autolbuilder.
But I wasn't referring to real build
Hi,
2009/11/2 Ed Bartosh :
> 2009/11/2 Marius Vollmer :
>> [ Jussi, we would like to get a new debian-etch devkit for Maemo 5 with
>> the attached patch. Please advise how to best go about this.
>> ]
>>
>> ext Ed Bartosh writes:
>>
>>> I can also help with building devkit if needed.
>>
>> I did
On Nov 4, 2009, at 13:04, Attila Csipa wrote:
> On Tuesday 03 November 2009 23:40:24 Graham Cobb wrote:
>> debugging, I need to be able to control exactly which versions of
>> various
>> libraries are being used for that particular build including,
>> sometimes,
>> old versions. And I often
On Tuesday 03 November 2009 23:40:24 Graham Cobb wrote:
> debugging, I need to be able to control exactly which versions of various
> libraries are being used for that particular build including, sometimes,
> old versions. And I often have different targets with different library
> versions delibe
Dammit, why won't modest do proper quoting...
Marius (I think) wrote...
> ext Graham Cobb writes:
>
> > On Monday 02 November 2009 12:16:57 Ed Bartosh wrote:
> > > 2009/11/2 Marius Vollmer :
> > > > The buildbot would need to run "apt-get install maemo-optify" at the
> > > > right time. Any idea
2009/11/3 Marius Vollmer :
> ext Ed Bartosh writes:
>
>> 2009/11/3 Marius Vollmer :
>>> ext Ed Bartosh writes:
>>>
We can hack dpkg-checkbuilddeps to unconditionally add maemo-optify to
the list of build dependencies.
>>>
>>> Ouch. That's very desperate.
>>>
>> May be. But not as despe
ext Ed Bartosh writes:
> 2009/11/3 Marius Vollmer :
>> ext Ed Bartosh writes:
>>
>>> We can hack dpkg-checkbuilddeps to unconditionally add maemo-optify to
>>> the list of build dependencies.
>>
>> Ouch. That's very desperate.
>>
> May be. But not as desperate as calling apt-get install from
>
2009/11/3 Marius Vollmer :
> ext Ed Bartosh writes:
>
>> We can hack dpkg-checkbuilddeps to unconditionally add maemo-optify to
>> the list of build dependencies.
>
> Ouch. That's very desperate.
>
May be. But not as desperate as calling apt-get install from
dpkg-buildpackage :)
> What about cha
ext Ed Bartosh writes:
> We can hack dpkg-checkbuilddeps to unconditionally add maemo-optify to
> the list of build dependencies.
Ouch. That's very desperate.
What about changing dpkg-buildpackage to run "apt-get install
maemo-optify" if necessary? That concentrates the hacks in one place
and
2009/11/3 Marius Vollmer :
> ext Graham Cobb writes:
>
>> On Monday 02 November 2009 12:16:57 Ed Bartosh wrote:
>>> 2009/11/2 Marius Vollmer :
>>> > The buildbot would need to run "apt-get install maemo-optify" at the
>>> > right time. Any idea of how to do that?
>>>
>>> Right way to do it is to
ext Graham Cobb writes:
> On Monday 02 November 2009 12:16:57 Ed Bartosh wrote:
>> 2009/11/2 Marius Vollmer :
>> > The buildbot would need to run "apt-get install maemo-optify" at the
>> > right time. Any idea of how to do that?
>>
>> Right way to do it is to include it into SDK rootstrap. Other
2009/11/3 Graham Cobb :
> On Monday 02 November 2009 12:16:57 Ed Bartosh wrote:
>> 2009/11/2 Marius Vollmer :
>> > The buildbot would need to run "apt-get install maemo-optify" at the
>> > right time. Any idea of how to do that?
>>
>> Right way to do it is to include it into SDK rootstrap. Other w
On Monday 02 November 2009 12:16:57 Ed Bartosh wrote:
> 2009/11/2 Marius Vollmer :
> > The buildbot would need to run "apt-get install maemo-optify" at the
> > right time. Any idea of how to do that?
>
> Right way to do it is to include it into SDK rootstrap. Other ways I
> can think of look hacki
2009/11/2 Marius Vollmer :
> [ Jussi, we would like to get a new debian-etch devkit for Maemo 5 with
> the attached patch. Please advise how to best go about this.
> ]
>
> ext Ed Bartosh writes:
>
>> I can also help with building devkit if needed.
>
> I didn't manage to get the devkit to compile
[ Jussi, we would like to get a new debian-etch devkit for Maemo 5 with
the attached patch. Please advise how to best go about this.
]
ext Ed Bartosh writes:
> I can also help with building devkit if needed.
I didn't manage to get the devkit to compile (I didn't see a way to get
it to not in
"Vollmer Marius (Nokia-D/Helsinki)" writes:
> I guess I need a special 'host' Scratchbox target to build this
> [devkit], right?
Right, the sucker wants to install into /scratchbox/devkits/ during
build. That can't be right. Any hints?
___
maemo-deve
ext Ed Bartosh writes:
> That's the plan so far. autobuilder calls dpkg-buildpackage without
> checkiing anything, like it already does.
Yes, and the modified dpkg-buildpackage would always call
"maemo-optify-deb --auto" without checking anything (except whether
maemo-optify-deb exists).
___
ext Ed Bartosh writes:
> 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
Thjanks for the pointer. I guess I need a special 'host' Scratchbox
target to build this sucker, right? I am no
2009/11/2 Marius Vollmer :
> ext Graham Cobb writes:
>
>> On Thursday 29 October 2009 11:12:45 Marius Vollmer wrote:
>>> ext Alberto Mardegan writes:
>>> >> b) A control file field makes the most sense to
>>> >> control the build process.
>>> >
>>> > Agreed.
>>>
>>> I think dedicated files
ext Graham Cobb writes:
> On Thursday 29 October 2009 11:12:45 Marius Vollmer wrote:
>> ext Alberto Mardegan writes:
>> >> b) A control file field makes the most sense to
>> >> control the build process.
>> >
>> > Agreed.
>>
>> I think dedicated files in debian/ are better, like the
>> de
2009/11/2 Marius Vollmer :
> ext Ed Bartosh writes:
>
>> Right way to do it is to include it into SDK rootstrap. Other ways I
>> can think of look hackish.
>
> (I think this is a good example of what is wrong with Maemo: normally,
> we would just upload a patched dpkg and be done with it. Now we
ext Ed Bartosh writes:
> Right way to do it is to include it into SDK rootstrap. Other ways I
> can think of look hackish.
(I think this is a good example of what is wrong with Maemo: normally,
we would just upload a patched dpkg and be done with it. Now we have to
muck around with devkits and
2009/11/2 Marius Vollmer :
> ext Ed Bartosh writes:
>
>> OK, we can make dependency from dpkb-buildpackage to maemo-optify not
>> so strict. If maemo-optify is present it will be called from
>> dpkg-buildpackage. With this approach we can put maemo-optify into
>> rootstrap.
>
> Ok, I'll make it l
ext Ed Bartosh writes:
> OK, we can make dependency from dpkb-buildpackage to maemo-optify not
> so strict. If maemo-optify is present it will be called from
> dpkg-buildpackage. With this approach we can put maemo-optify into
> rootstrap.
Ok, I'll make it like that, then.
> BTW, official root
2009/11/2 Andrew Flegg :
> Ed wrote:
>> 2009/11/2 Marius Vollmer :
>>
>> > Would maemo-optify be part of that devkit as well, or would it be in the
>> > rootstrap?
>> >
>> > I prefer to leave maemo-optify in the rootstrap: that way, we can update
>> > it much easier, which is quite important at thi
Ed wrote:
> 2009/11/2 Marius Vollmer :
>
> > Would maemo-optify be part of that devkit as well, or would it be in the
> > rootstrap?
> >
> > I prefer to leave maemo-optify in the rootstrap: that way, we can update
> > it much easier, which is quite important at this stage.
> >
> Unfortunately it ha
2009/11/2 Marius Vollmer :
> ext Ed Bartosh writes:
>
>> So, I can see this way of implementing this:
>> - give optification scripts to SDK developers and ask them to prepare
>> Debian devkit for Fremantle with patched dpkg-buildpackage as fast as
>> possible.
>
> We should prepare a concrete
ext Jeremiah Foster writes:
> dpkg-buildpackage is written in perl. It would facilitate merging with
> upstream and any potential downstream if we kept any additional dpkg-
> buildpackage calls/methods as perl modules.
Perl modules or not, the Right Way is indeed adding generic hooks to
dpkg-
ext Ed Bartosh writes:
> So, I can see this way of implementing this:
> - give optification scripts to SDK developers and ask them to prepare
> Debian devkit for Fremantle with patched dpkg-buildpackage as fast as
> possible.
We should prepare a concrete patch against dpkg-buildpackage, of c
On Nov 1, 2009, at 18:17, Ed Bartosh wrote:
> 2009/11/1 Graham Cobb :
>> On Sunday 01 November 2009 09:02:34 Ed Bartosh wrote:
>>> So, what should we do?
>>>
>>> My proposal is to make dpkg-buildpackage to call maemo-optify. With
>>> this we can solve 2 problems - autobuilder will optify packages
2009/11/1 Graham Cobb :
> On Sunday 01 November 2009 09:02:34 Ed Bartosh wrote:
>> So, what should we do?
>>
>> My proposal is to make dpkg-buildpackage to call maemo-optify. With
>> this we can solve 2 problems - autobuilder will optify packages and
>> developers will have their packages automatic
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
2009/10/29 Graham Cobb :
> On Wednesday 28 October 2009 22:50:25 Ed Bartosh wrote:
>> Somehow I don't like the idea of doing anything with the package
>> without developer being aware of this. I'd rather implement check on
>> autobuilder side to insure that packages are optified. Developer can
>> u
2009/10/29 Marius Vollmer :
> ext Andrew Flegg writes:
>
>> I suggest the header is XS-Maemo-Optify, and has the following values:
>>
>> none: no optification should be done, or considered, by the autobuilder.
>> manual: the application author will do optification manually. If the
>>
On Thursday 29 October 2009 11:12:45 Marius Vollmer wrote:
> ext Alberto Mardegan writes:
> >> b) A control file field makes the most sense to
> >> control the build process.
> >
> > Agreed.
>
> I think dedicated files in debian/ are better, like the
> debian/.install files, etc.
There is
ext Andrew Flegg writes:
> I suggest the header is XS-Maemo-Optify, and has the following values:
>
> none: no optification should be done, or considered, by the autobuilder.
> manual: the application author will do optification manually. If the
> package contains no entries under
ext Alberto Mardegan writes:
>> b) A control file field makes the most sense to
>> control the build process.
>
> Agreed.
I think dedicated files in debian/ are better, like the
debian/.install files, etc.
Right now, I am just putting the mode into debian/optify, but I can
already see ho
Andrew Flegg wrote:
> Alberto wrote:
>> Graham Cobb wrote:
>>> So, the consensus decision was that the solution would be that autobuilder
>>> should automatically optify by default.
>> Sounds wrong to me.
>
> Can you elaborate? I'd like to be convinced (as I was during the BOF) rather
> than just
On Thursday 29 October 2009 08:08:20 Attila Csipa wrote:
> On Thursday 29 October 2009 07:07:14 Ed Bartosh wrote:
> > Then let's find the way to do it better.
>
> I believe that was the stance on the problem since day 1 :)
>
> > What I'm afraid of is that developers wouldn't like the approach to
>
2009/10/29 Andrew Flegg :
> Ed wrote:
>> 2009/10/29 Graham Cobb :
>> >
>> > Nobody likes doing something to the package automatically but, after a long
>> > discussion at the BOF, we agreed that the alternatives were even worse [1].
>> >
>> Then let's find the way to do it better.
>> What I'm afrai
ext Andrew Flegg writes:
> 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?
I'll give this a shot.
_
Alberto wrote:
> Graham Cobb wrote:
> > So, the consensus decision was that the solution would be that autobuilder
> > should automatically optify by default.
>
> Sounds wrong to me.
Can you elaborate? I'd like to be convinced (as I was during the BOF) rather
than just whomever expresses the most
On Thursday 29 October 2009 07:07:14 Ed Bartosh wrote:
> Then let's find the way to do it better.
I believe that was the stance on the problem since day 1 :)
> What I'm afraid of is that developers wouldn't like the approach to
> change packages implicitly.
Herein lies the root of the problem.
Ed wrote:
> 2009/10/29 Graham Cobb :
> >
> > Nobody likes doing something to the package automatically but, after a long
> > discussion at the BOF, we agreed that the alternatives were even worse [1].
> >
> Then let's find the way to do it better.
> What I'm afraid of is that developers wouldn't li
Graham Cobb wrote:
> So, the consensus decision was that the solution would be that autobuilder
> should automatically optify by default.
Sounds wrong to me. I agree with Ed, the default should be "manual": so, non
optified packages would fail to build, but fixing that would be as easy as
addin
2009/10/29 Graham Cobb :
> On Wednesday 28 October 2009 22:50:25 Ed Bartosh wrote:
>> Somehow I don't like the idea of doing anything with the package
>> without developer being aware of this. I'd rather implement check on
>> autobuilder side to insure that packages are optified. Developer can
>> u
2009/10/29 Graham Cobb :
> I think we should do the second item before Ed goes on holiday, even if it
> means deferring the multiple package builds. We can then test it (setting
> the header to auto in various packages) while Ed is away but there is minimal
> danger of problems cropping up while h
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
2009/10/28 Andrew Flegg :
> Ed wrote:
>> >
>> > I've put together a suggested spec for the decision, taken at the
>> > summit during the /opt BOF[1], that the auto-builder would run some
>> > maemo-optify version during the build process (controlled by a control
>> > file header):
>>
>> Sorry, I se
On Wednesday 28 October 2009 20:39:57 Andrew Flegg wrote:
> Ed wrote:
> > 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.
>
> i don't know, it's not my baby :-) One w
I think it is good to be able to keep maemo-optify out of Build-Depends :
This way we can keep the same debian control file for Diablo and Fremantle.
I suppose the Diablo builder will only ignore the optify header ?
Fred
On Wed, Oct 28, 2009 at 8:10 PM, Ed Bartosh wrote:
> 2009/10/28 Andrew Fleg
Kamen wrote:
>
> Wouldn't it be better to leave the none option out considering the lack of
> storage space in N900. It can be made available in Harmattan.
The thought was that there might be a small, or niche, product which just
wouldn't work with maemo-optify and changing it to use /opt would b
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
Wouldn't it be better to leave the none option out considering the lack of
storage space in N900. It can be made available in Harmattan.
Regards:
Bundyo
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listin
2009/10/28 Andrew Flegg :
> Hi,
>
> I've put together a suggested spec for the decision, taken at the
> summit during the /opt BOF[1], that the auto-builder would run some
> maemo-optify version during the build process (controlled by a control
> file header):
>
>http://talk.maemo.org/showthrea
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 th
77 matches
Mail list logo
