Re: Why should it be so hard and should I even bother with Extras for fremantle?

[tz]

To extend or clarify another issue:

There are things which should be and are in other sections like python
and associated libs.  Lots of things like this and cli stuff are
building-blocks, i.e. I might want to use a maintained and tested
utility for several things and which others can use instead of copying
a routine and having it duplicated.

Karma would work for this but not for user/* - if I update something
outside of user and in something which won't be visible in application
manager, how can I get it to users without a user stub whose only
purpose is to pull in the updated library?

On Wed, Nov 4, 2009 at 4:04 PM, tz  wrote:
> I was hoping to spark a discussion, and I think it worked out better
> than I was expecting for a rant.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Why should it be so hard and should I even bother with Extras for fremantle?

[tz]

I was hoping to spark a discussion, and I think it worked out better
than I was expecting for a rant.

My thoughts on extras:  (maybe instead of karma it should be called
extras credit?).

* I don't do games, so I would consider user/games as cluttered as
someone else might consider user/cli.  I don't have a solution except
a good hierarchy.  Clutter tends to be anything you don't want or
like.

* There are a lot of good bits of discussion, but my original point is
that only user/* is visible, so going outside requires a "red pill"
kind of hack (and my complaint is that it doesn't auto-restore).
Anything which expands user/* to XYZ/* needs to have XYZ in the
extras-tester promotion system and in the application manager.  Maybe
a universe/ or multiverse/ or advanced/ - just create something,
support it, and tell me where I can put something.

* Some apps will have hundreds of users, some only a handful, but all
require the same amount of Karma to approve.  Same with complex and
critical apps v.s. simple (see below).

* Requiring a reason for "thumbs down" would probably be a good idea.

* As pointed out Karma needs some persistence so trivial changes can
be checked and promoted quickly but new versions can be tested (and
possibly beta3 inherit from beta2).  Perhaps after getting a base
karma I can set how much karma I think it needs before it can be
promoted.  You might need to trust developers, but karma should be
different for a simple picture viewer v.s. a security application.

* Also I should be able to pull and replace a version or some
documentation when the build doesn't change any actual code.  There
seems to be no way to do this.

* The karma promoter could be a mini bug-reporting system.  It isn't
designed to be bugzilla, but for an app there could be a URL somewhere
to a talk discussion or bugzilla or email or something else for the
bigger things with patches, screenshots, but simple "the button is
half off the screen" can be put into a karma comment.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Maemo5 on Beagleboard

[Till Harbaum / Lists]

Hi,

Am Mittwoch 04 November 2009 schrieb Henning Heinold:
> did you download the latest driver from
> http://home.eeti.com.tw/web20/eGalaxTouchDriver/linuxDriver.htm ?
Nope, i am using the driver that is present in the kernel. 

> It comes with binary calibration and configure program called Touchkit,
> which resolve your touchscreen problems. There is one funny think to notice
> the right mouse click is emulated be holding the touchscreen for some time,
> but this is configurable to your needs via the Touchkit-program.
Did you successfully run this program on maemo5 on the beagleboard?

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

Re: Quality Assurance and Extras-testing discussion on IRC

[Jeremiah Foster]

On Nov 4, 2009, at 18:36, Andrew Flegg wrote:

> On Wed, Nov 4, 2009 at 14:47, Jeremiah Foster
>  wrote:
>>
>> There are a number of things to discuss, both technical and
>> non-technical, and it would be great if we could come together and
>> create a list of actionable items so we can make the QA process as
>> efficient and usable as possible.
>
> Agreed. However, IME (from other IRC meetings and the /opt BOF etc.)
> no matter how much consensus is got during the meeting, there'll be
> further discussion on the mailing list.

Yeah, I agree. Mailing list discussion is the most focused and can be  
the most detailed, in my experience.

> This needs to be chaired as
> well :-)

I think Valerio will do that. I was supposed to forward this mail to  
him for approval first, I failed. :-/

>
>>Meeting details:
>>
>>IRC: irc.freenode.org
>>Channel: #maemo-meeting
>>Time: Tuesday, November 10th, 14:30 UTC
>
> I won't be able to make this as I will be onsite at a client, however
> my views can be summarised as:
>
>   * QA is good.
>   * The criteria are a good start, but need tweaks (see thread)
>   * The packages UI needs some streamlining for testers.
>   * As a tester, a better reminder of the checklist when checking
> would be good. I also like the ease with which I can give  
> feedback.
>   * As a developer, I don't *think* I want to be constrained with
> "release early, release often" when fixing bugs or introducing new
> small features (i.e. karma resets to zero).

I've scooped this up and put it on the wiki page for the meeting as an  
agenda.
http://wiki.maemo.org/QAMeeting

>
>>Jeremiah Foster
>>Maemo.org debmaster
>
> This should be "maemo.org debmaster" BTW ;-)

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

RE: maemo-optify, autobuilder & /opt

[marius.vollmer]

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 you elaborate a bit? Is it implemented the way proposed by Andrew?

For the devkit, "as expected" means to invoke "maemo-optify-deb --auto" at the 
right time.
Whatever maemo-optify-deb does is not under scrutiny yet.

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

Correct, the default mode for maemo-optify-deb --auto (when debian/optify
does not exist) is currently "none".
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: QA process = bug fixing disincentive?

[Ryan Abel]

On Nov 4, 2009, at 9:21 AM, Graham Cobb wrote:

> But the update description does not help with testing: (a) it is  
> user friendly text, not a developer changelog and (b) the  
> description is vs. the version already in Extras not vs. the last  
> extras-testing version.

I'd still love to see a Testing Mode in h-a-m. Show Debian changelogs,  
show repository origin, give you an interface to packages, etc.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: maemo-optify, autobuilder & /opt

[Ed Bartosh]

2009/11/4 Marius Vollmer :
> ext Ed Bartosh  writes:
>
>> 2009/11/3 Marius Vollmer :
>>
>>> Luckily, with apt-get upgrade being run during build, we don't need
>>> to change dpkg-checkbuilddeps and we can just update build-essential.
>>> (Unless I am missing something. Do I?)
>>
>> rootstrap is used as a build-essentials by sbdmock. The initial idea
>> was to put maemo-optify in there, but now we're trying to avoid that.
>
> Hmm, the rootstrap contains the "build-essential" package.  If we put a
> newer version of the build-essential package into extras-devel, then
> that newer version will be installed by 'apt-get upgrade'.
>
> If apt-get upgrade does indeed run during a build.  I no longer think it
> actually does.  Checking the build log of maemo-optify certainly shows
> no signs of running apt-get upgrade.
>
I'm sorry. This is my faul. I thought you're asking about 'apt-get
update'. sbdmock doesn't run 'apt-get upgrade', it just unpacks
rootstrap and installs build deps.

>
> https://garage.maemo.org/builder/fremantle/maemo-optify_0.1/i386.root.log.OK.txt
>
> Hmm, so is "apt-get upgrade" being executed at one point before calling
> dpkg-buildpackage?

 Yes it is.
>>>
>>> Cool, then that's our ticket to get maemo-optify into the build
>>> environment, I would say.
>>>
>> The only problem left is were to put 'apt-get install' :)
>
> Which apt-get install?  We just add a dependency on maemo-optify to
> build-essential and apt-get upgrade does the rest.  No?
>
Sorry, but no.

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

Re: maemo-optify, autobuilder & /opt

[Andrew Flegg]

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.
>>
> Can you elaborate a bit? Is it implemented the way proposed by Andrew?

"auto" for Hermes should do nothing, as it has entries in /opt (if, as
Ed asks, it does as I outlined).

Cheers,

Andrew

-- 
Andrew Flegg -- mailto:and...@bleb.org  |  http://www.bleb.org/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: maemo-optify, autobuilder & /opt

[Ed Bartosh]

2009/11/4 Marius Vollmer :
> ext Ed Bartosh  writes:
>
>> Has anybody tried this devkit? Does it work as expected?
>
> I tried it by building (slightly modified versions of) xournal, hermes,
> and libliqbase, and everything went as expected.
>
Can you elaborate a bit? Is it implemented the way proposed by Andrew?

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


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

Re: Quality Assurance and Extras-testing discussion on IRC

[Andrew Flegg]

On Wed, Nov 4, 2009 at 14:47, Jeremiah Foster
 wrote:
>
> There are a number of things to discuss, both technical and
> non-technical, and it would be great if we could come together and
> create a list of actionable items so we can make the QA process as
> efficient and usable as possible.

Agreed. However, IME (from other IRC meetings and the /opt BOF etc.)
no matter how much consensus is got during the meeting, there'll be
further discussion on the mailing list. This needs to be chaired as
well :-)

>        Meeting details:
>
>        IRC: irc.freenode.org
>        Channel: #maemo-meeting
>        Time: Tuesday, November 10th, 14:30 UTC

I won't be able to make this as I will be onsite at a client, however
my views can be summarised as:

   * QA is good.
   * The criteria are a good start, but need tweaks (see thread)
   * The packages UI needs some streamlining for testers.
   * As a tester, a better reminder of the checklist when checking
 would be good. I also like the ease with which I can give feedback.
   * As a developer, I don't *think* I want to be constrained with
 "release early, release often" when fixing bugs or introducing new
 small features (i.e. karma resets to zero).

I'm happy, from what I've seen in the discussion to date, that people
share enough views with me that I don't need to be there :-)

Cheers,

Andrew

>        Jeremiah Foster
>        Maemo.org debmaster

This should be "maemo.org debmaster" BTW ;-)

-- 
Andrew Flegg -- mailto:and...@bleb.org  |  http://www.bleb.org/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: How to get a transparent GtkWindow (fremantle)

[Luca Donaggio]

2009/11/3 Luca Donaggio 

> 2009/11/3 Kimmo Hämäläinen 
>
> On Tue, 2009-11-03 at 15:06 +0100, ext Luca Donaggio wrote:
>> > I'm still banging my head against a wall with this:
>> >
>> > why without reparenting the popup undecorated window to the main app
>> > window it becomes transparent but the app menu doesn't work (it starts
>> > to be drawn but immediately disappears) and viceversa?
>>
>> I think this is not the way to go. This is way too hacky and ugly.
>> Also, the window manager has not been tested for this kind of
>> reparenting cases (which cause unmaps and remapping of windows), and
>> it's likely that it's buggy in handling those.
>>
>> Home applet windows are transparent, so clearly there is some way to do
>> it depending on the window type.
>>
>> Do you have a stand-alone program showing transparent dialog (without
>> reparenting hacks), so I could spend some time to see if it can be made
>> to work?
>>
>> -Kimmo
>>
>>
>>
> Hi Kimmo,
>
> my project is pretty simple, you can have a look at its sources here: [1].
> The relevant code is in interface.c (create_image_details) and callbacks.c
> (draw_image_details).
>
> I don't think either that reparenting should be the way to go (I think I've
> seen it done for the first time in some example, don't remember where now),
> I just found that with it the app menu did work and window's transparency
> didn't!
>
> [1]
> https://garage.maemo.org/plugins/scmsvn/viewcvs.php/trunk/src/?root=mrawviewer
>
> --
> Luca Donaggio
>

Sorry Kimmo,

I forgot to update the svn repo, I'm doing it right now!

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

Re: maemo-optify, autobuilder & /opt

[Marius Vollmer]

ext Ed Bartosh  writes:

> 2009/11/3 Marius Vollmer :
>
>> Luckily, with apt-get upgrade being run during build, we don't need
>> to change dpkg-checkbuilddeps and we can just update build-essential.
>> (Unless I am missing something. Do I?)
>
> rootstrap is used as a build-essentials by sbdmock. The initial idea
> was to put maemo-optify in there, but now we're trying to avoid that.

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

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


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?

I'll put a newer version of build-essential into extras-devel and see
what happens, fingers crossed.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Strange message from autobuilder: ERROR running /etc/buildme.d/setup_build

[Dave Neary]

Hi,

ds wrote:
> [2009-11-04 16:35:01] Processing package vncviewer 0.6.3-fremantle3.
> Uploader: dschmicker, builder: builder1
> [2009-11-04 16:35:21] ERROR running /etc/buildme.d/setup_build:  
> We trust you have received the usual lecture from the local System
> Administrator. It usually boils down to these three things:
> 
> #1) Respect the privacy of others.
> #2) Think before you type.
> #3) With great power comes great responsibility.
> 
> Password:
> 
> 
> 
> 
> I do not really understand, what it wants to say to me:-(

I recognise this message - it is the message which you get when you run
sudo (sometimes only the first time). The password is usually not needed
if your username is in the sudoers file. The lecture is not given every
time if you have "lecture=once" or "lecture=never" as options at the top
of the file /etc/sudoers.

So - the error message isn't weird, it merely indicates a call to sudo
with a UID which isn't in the sudoers file as not needing to enter their
password.

Cheers,
Dave.

-- 
maemo.org docsmaster
Email: dne...@maemo.org
Jabber: bo...@jabber.org

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

Re: maemo-optify, autobuilder & /opt

[Marius Vollmer]

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 to chown /scratchbox/devkits/debian-etch to
myself... not very nice.

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

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

Re: maemo-optify, autobuilder & /opt

[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.

The slight modification was "echo auto >debian/optify" to turn on
optification.

> Should we deploy it?

It has my vote.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: maemo-optify, autobuilder & /opt

[Marius Vollmer]

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 before anyone suggested
> it.

I was close. :)

I have proposed to run apt-get install maemo-optify fmr within
dpkg-buildpackage, but that is quite clearly a very gross thing to do.
I have to admit that I pretty much have no dignity anymore when it comes
to kicking Maemo and Scratchbitch into behaving as they should... :/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Strange message from autobuilder: ERROR running /etc/buildme.d/setup_build

[ds]

I received a strange message from autobuilder, but it indicates
everything is correct. I did not change my upload process?!:

[2009-11-04 16:35:01] Processing package vncviewer 0.6.3-fremantle3.
Uploader: dschmicker, builder: builder1
[2009-11-04 16:35:21] ERROR running /etc/buildme.d/setup_build:  
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.

Password:




I do not really understand, what it wants to say to me:-(

Detlef

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

Quality Assurance and Extras-testing discussion on IRC

[Jeremiah Foster]

Hello,

During the most recent Maemo.org Sprint meeting, Valerio suggested we  
get together on IRC and discuss the Quality Assurance process, and  
Extras-testing. There are a number of things to discuss, both  
technical and non-technical, and it would be great if we could come  
together and create a list of actionable items so we can make the QA  
process as efficient and usable as possible.

Note that we as a community can drive this process, it is we who can  
shape it, make it great. Furthermore, if we can increase quality and  
can demonstrate a responsible and effective way of testing  
applications, we'll get more confidence from users and Nokia.  
Hopefully this confidence will result in the ability to also shape the  
entire development process - the toolchain, the licensing, scratchbox,  
etc. This is why I think it is paramount that we act responsibly and  
get as much feedback from developers as possible.

We have a great opportunity here. We are establishing a method for  
doing QA and testing that is community based, on the most advanced  
mobile platform in the world. We have participation from people inside  
the Nokia firewall, from the community, and some excellent developers.  
Soon the device will be in the hands of users and all our hard work  
will have paid off.

I encourage us as a community to be open and honest about the process  
- we have to fix what doesn't work and promote that which does. We  
can't do that without your participation.

Meeting details:

IRC: irc.freenode.org
Channel: #maemo-meeting
Time: Tuesday, November 10th, 14:30 UTC

I hope to collect a list of issues, fixes, complaints, and maybe even  
some praise, which I will further send out to our existing  
communication channels so that we can execute the changes that this  
process needs. Please note that Niels is away in November and his  
feedback and views are crucial to our discussion since he has been  
involved in maemo and the infrastructure for such a long time. But  
make no mistake, this is a community process and we have Valerio to  
thank for taking a leadership role in this latest phase of testing  
Extras-testing.

Best regards,

Jeremiah Foster
Maemo.org debmaster
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: maemo-optify, autobuilder & /opt

[Graham Cobb]

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 builds, I was referring to compiles during 
debugging and testing. I just wanted to make sure we can all use 
dpkg-buildpackage without it touching our apt environment.  

While we are about it, I don't think the SDK guys support people doing apt-get 
update.  In the past we have been told they do not test that.

--
Sent from Nokia Nseries mobile computer
- Original message -
>
> 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 have different targets with different 
> > > library
> > > versions deliberately installed.
> >
> > I'm not sure if it's possible/viable on scratchbox and the final 
> > SDK, but
> > things like pbuilder make this easier (since they are in essence
> > mini-autobuilders).
>
> pbuilder (Personal Builder)[0] and cowbuilder (Copy On Write Builder)
> [1] both are extremely useful tools, I heartily recommend them. I 
> wonder if one day we might configure them for maemo somehow.
>
> Jeremiah
>
> 0. http://www.netfort.gr.jp/~dancer/software/pbuilder-doc/pbuilder-doc.html
> 1. http://wiki.debian.org/cowbuilder
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers

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

Re: QA process = bug fixing disincentive?

[Graham Cobb]

Attila said...
> On Wednesday 04 November 2009 10:28:58 Andrew Flegg wrote:
> > On Wed, Nov 4, 2009 at 09:03,   wrote:
> > > Two days later I notice a blinking orange light in my status bar. I see
> > > a new version of the application. I install, I check what has changed
> > > (minor or major?), I run my tests and thumb it up again.
> >
> > Aside: how do you check what has changed?
>
> This is one of the things I miss sorely from the Application Manager. Sure,
> you can see the description and version, but not things like free/non-free,
> the repo and last, but not least, the changelog (maybe based on the
> debian/changelog most packages have, anyway).

For users AppMgr has a user-friendly alternative: you specify an update 
description in the control file.  Now that I think of it this needs to go into 
the extras testing rules: any package which is already in Extras must specify 
an update description to give people information on why they should upgrade.

But the update description does not help with testing: (a) it is user friendly 
text, not a developer changelog and (b) the description is vs. the version 
already in Extras not vs. the last extras-testing version.

It sounds like it would be useful to start including changelog in Maemo 
packages and make it visible from the package page.

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

Re: maemo-optify, autobuilder & /opt

[Ed Bartosh]

Hi,

2009/11/2 Ed Bartosh :
> 2009/11/2 Marius Vollmer :
>> [ Jussi, we would like to get a new debian-etch devkit for Maemo 5 with
>>  the attached patch.  Please advise how to best go about this.
>> ]
>>
>> ext Ed Bartosh  writes:
>>
>>> I can also help with building devkit if needed.
>>
>> I didn't manage to get the devkit to compile (I didn't see a way to get
>> it to not install into / during build), but I have a patch anyway
>> (attached).
>>
> You can learn how to do it here:
> http://scratchbox.org/documentation/docbook/devkit.html
>
> Here you can get result of my build(patch attached):
> https://garage.maemo.org/builder/scratchbox-devkit-debian_1.0.16-1.optify_i386.deb
>
Has anybody tried this devkit? Does it work as expected? Should we deploy it?

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

Re: maemo-optify, autobuilder & /opt

[Jeremiah Foster]

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 have different targets with different  
>> library
>> versions deliberately installed.
>
> I'm not sure if it's possible/viable on scratchbox and the final  
> SDK, but
> things like pbuilder make this easier (since they are in essence
> mini-autobuilders).

pbuilder (Personal Builder)[0] and cowbuilder (Copy On Write Builder) 
[1] both are extremely useful tools, I heartily recommend them. I  
wonder if one day we might configure them for maemo somehow.

Jeremiah

0. http://www.netfort.gr.jp/~dancer/software/pbuilder-doc/pbuilder-doc.html
1. http://wiki.debian.org/cowbuilder
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: How to remove an app from extras-testing?

[Jeremiah Foster]

On Nov 4, 2009, at 14:24, Andrew Flegg wrote:

> On Wed, Nov 4, 2009 at 13:19, Till Harbaum  wrote:
>>
>> how can i have programs removed from extras-testing?
>
> Ask X-Fade (ni...@maemo.org), but since he's on holiday, Jeremiah
> (jerem...@maemo.org).

Yes - a request to me, or even to maemo-developers mailing list which  
I try to keep up-to-date on is all that is required. I will respond in  
the same manner: i.e. privately if you emailed me privately, publicly  
to the list if you mailed me publicly.

Best,

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

Re: QA process = bug fixing disincentive?

[Jeremiah Foster]

On Nov 4, 2009, at 12:49, Attila Csipa wrote:

> On Wednesday 04 November 2009 10:28:58 Andrew Flegg wrote:
>> On Wed, Nov 4, 2009 at 09:03,   wrote:
>>> Two days later I notice a blinking orange light in my status bar.  
>>> I see
>>> a new version of the application. I install, I check what has  
>>> changed
>>> (minor or major?), I run my tests and thumb it up again.
>>
>> Aside: how do you check what has changed?

Technically there could be a way to use debdiff as well as parse the  
changelog. I wouldn't want to do to much more that say;

 > 10 Lines of code changed
 > Changelog says: Added bugfix for frobulation

Jeremiah

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

Re: python-dbus Re: Autobuilder repository priority ?

[Anderson Lizardo]

On Wed, Nov 4, 2009 at 8:25 AM, Johannes Schmid
 wrote:
> Hi!
>
>> Johannes: any problems with that?
>
> Sure, so I must admit I cannot remeber uploading this package. But I
> suppose something is depending on python2.5-dbus which should be fixed.
> Can you check this in the repository?

python-dbus (the newer package) has this in debian/control:

Provides: python2.5-dbus

This should satisfy dependencies for those packages that Depend: on
python2.5-dbus. It works very well for other packages we currently
maintain in PyMaemo.

Regards,
-- 
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: How to remove an app from extras-testing?

[Andrew Flegg]

On Wed, Nov 4, 2009 at 13:19, Till Harbaum  wrote:
>
> how can i have programs removed from extras-testing?

Ask X-Fade (ni...@maemo.org), but since he's on holiday, Jeremiah
(jerem...@maemo.org).

HTH,

Andrew

-- 
Andrew Flegg -- mailto:and...@bleb.org  |  http://www.bleb.org/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

How to remove an app from extras-testing?

[Till Harbaum]

Hi,

how can i have programs removed from extras-testing?

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

Re: QA process = bug fixing disincentive?

[Marius Vollmer]

"Voipio Riku (Nokia-D/Helsinki)"  writes:

> Every company has software testers, yet it doesn't mean they dont trust
> their developers :)

I think there are two kinds of trust on the table here: trust in
developers not to make mistakes, and trust in developers not to abuse
the process malevolently.

We don't need to trust developers not to make mistakes.  A developer
doesn't even trust himself/herself not to make mistakes, of course.

But I think wa want to trust developers not to be malevolent.  There
will be exceptions, they will be found out and punished, the malecreants
will create another account, and life goes on.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Autobuilder repository priority ?

[Anderson Lizardo]

On Tue, Nov 3, 2009 at 4:31 PM, Attila Csipa  wrote:
> On Tuesday 03 November 2009 18:58:04 Anderson Lizardo wrote:
>> Can you be more specific? Which paths are those? How does this affect
>> your package?
>
> Okay, I backtracked my steps as far as I could, and it *seems* the actual
> source of the problem is python-support (which I pull in through python-dbus).
> 1maemo1 (from the SDK) pulls in python-support 0.6.4 (from the SDK). 1maemo3,
> on the other hand, pulls in python-support 1.0.2maemo1 (from extras-devel).
> Depending on which python-support module got pulled in, the paths for the dbus
> module change:
> [...]

This path has changed due to the new python-support 1.0.2 version.
They decided to change this path for some reason. Unfortunately, we
can't keep compatibility in this case, as it was an upstream change.
Ideally, your package should not depend on that path being the same
forever.

In my opinion, the best way to handle it is to have your package
Build-Depend on python-support (>= 1.0.2maemo1), given that you rely
on this private path (which BTW comes from "installedpath" variable in
/usr/share/python-support/private/movemodules).

> And since the paths change, the .so will go (or rather won't go, as the
> autobuilder bombs) to the wrong path. Yes, I know, I can introduce a
> downstream patchset and start depending on python-support myself, but that is
> not the point here. :)

I can see that it is not the main point of the discussion (I myself
had problems with some broken libraries being uploaded to extras-devel
that "shadowed" working ones from the SDK), but keep in mind that in
case of any python* packages in the SDK, it is legitimate for the
PyMaemo team to upload up-to-date versions to the extras*
repositories, and you should not rely on any Python packages that come
from the SDK tools repository when doing Python development on Maemo,
as they are outdated and they are there just for satisfying
dependencies of some SDK tools.

Regards,
-- 
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: QA process = bug fixing disincentive?

[Riku Voipio]

ext Henrik Hedberg wrote:
> Tim Teulings wrote:
>
>   
>>> Except how do you try to prevent abuse (whether intentional or
>>> accidental)? At least with the version number you've got some safety
>>> check (although it is in no way comprehensive). It also requires more
>>> changes at more levels (I bet), so harder to implement.
>>>   
>> I think it is time to decide (again?) if we trust developers in their
>> atempt to get their software/package into extras or not. 
>> 
>
> Currently, we trust ten random testers rather than one well-known 
> developer.
>
> Why could not we trust well-known developers who have track record 
> of producing high-enough quality software? They may have their own 
> methods for testing, like couple of active and skilful dedicated testers 
> for the application domain. I see that more trustful than those random 
> testers who vote subjectively based on their opinions of an user interface.

Every company has software testers, yet it doesn't mean they dont trust
their developers :) But even highly skilled, well-known developers are
just humans and make mistakes every now and then. Therefor, testing and
QA process is needed.

The problem with "just trust the developer" and "skillful dedicated
testers" is exactly that they become rapidly used to their own UI
mistakes and stop caring about them. 10 random users is a bit extreme,
but in principle it is a very good idea. If random extras-testing users
don't like the Use Experience, chances are very high that actual
"extras" endusers don't like it either! Certainly there are cases where
testers will thumb down unfairly, but if we have enough testers it
doesn't matter.

QA process is always going to somewhat painful. Still, the pain needs to
minimized and the QA process must be presented in a way that developers
can see the advantages of it rather than consider it as arbitrary
hurdle. Currently it appears the package promotion website is simply too
crude for both developers and testers. At the minimum we need a better
communication channel between developers and testers so that any
misunderstandings can be cleared directly without resorting to ranting
here :)

> Sounds familiar? See Debian New Maintainers Process [1].


Being a longterm Debian Developer, and a for a while a Application
Manager for the New Maintainer process, I think applying such model for
maemo extras would be a very bad idea.

1. It is a massive hurdle of contribution, discouraging people from
joining (I don't see you in debian or NM although you create Debian
packages;)
2. "Accredited" Debian Developers still upload crap all the time
3. It leads to complex workarounds such as sponsoring uploads for others

(In fact I hope we can some day dismantle NM it in Debian as well, and
move to a model where more people can upload directly, but _all_ uploads
are reviewed before accepting them in.)

ps. I also agree that guessing from version number is bad.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

python-dbus Re: Autobuilder repository priority ?

[Anderson Lizardo]

On Tue, Nov 3, 2009 at 4:31 PM, Attila Csipa  wrote:
> Foreword: My particular problem is not that big of an issue, in the end I went
> for extras-devel compatibility, no big deal, it's not yet for end users
> anyway. It's the generic approach that is at question here - tomorrow someone
> else will fall through the same manhole and it might become a recurring issue.
>
> On Tuesday 03 November 2009 18:58:04 Anderson Lizardo wrote:
>> Did you mean "-1maemo1" instead of "-1maemo0"? (there is no maemo0 IIRC)
>
> Yes, indeed, -1maemo1. To add to the confusion there *IS* a python2.5-0maemo0
> in *extras-testing* (see http://maemo.org/packages/view/python2.5-dbus/ )

This is certainly a bug. Someone else uploaded this package without
knowing there was already a python-dbus package in fremantle
extras-devel (apparently some months ago). This created two entries
for virtually the same package:

http://maemo.org/packages/view/python-dbus/ (the newer one)
http://maemo.org/packages/view/python2.5-dbus/ (the older)

I'm CC'ing the original uploader of this package (Johannes) and Jeremy
as well, so that we can remove the older package from extras*
repositories.

As you can see the version number of this package (0.83-0maemo0) is
actually smaller than the one maintained by the PyMaemo team
(0.83.0-1maemo1), so we can safely remove it, I suppose.

Johannes: any problems with that?

Regards,
-- 
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: maemo-optify, autobuilder & /opt

[Attila Csipa]

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 deliberately installed.

I'm not sure if it's possible/viable on scratchbox and the final SDK, but 
things like pbuilder make this easier (since they are in essence 
mini-autobuilders). For development purposes, of course one may want to 
control exact packages and versions. When it comes to proper builds, however, 
pbuilder et al are very handy as they allow you to check things compared to a 
predefined, but pristine status (i.e. no whoopses because you manually 
installed something in the SDK but forgot to add the dependency or have 
fiddled with sources.list).

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

Re: QA process = bug fixing disincentive?

[Attila Csipa]

On Wednesday 04 November 2009 10:28:58 Andrew Flegg wrote:
> On Wed, Nov 4, 2009 at 09:03,   wrote:
> > Two days later I notice a blinking orange light in my status bar. I see
> > a new version of the application. I install, I check what has changed
> > (minor or major?), I run my tests and thumb it up again.
>
> Aside: how do you check what has changed?

This is one of the things I miss sorely from the Application Manager. Sure, 
you can see the description and version, but not things like free/non-free, 
the repo and last, but not least, the changelog (maybe based on the 
debian/changelog most packages have, anyway).

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

How to Send SMS programatically in Maemo

[ibrahim]

greetings;

I Want To Implement An App For Sending And Receiving SMS. I looked for 
telepathy and DBus APIs ,took a look at articles and books like 
http://people.collabora.co.uk/~danni/telepathy-book/ , but didn't help 
me much

I also read the Bluetooth example code provided in maemo.org 
documentation  like
http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Using_Connectivity_Components/Maemo_Connectivity#Bluetooth_DBUS_UI_dialogs
and 
https://garage.maemo.org/svn/maemoexamples/trunk/maemo-examples/example_bluetooth.c
and I figured out my application would be a lot like them, Maybe i only 
have yo use the APIs they used to get the SMS message done.

but the problem is I can't seem to find any documentation related to SMS 
handling. what parameters should I provide to the telepathy APIs to use 
the SMS sending functionality ??? (I mean the service name, dbus 
interface name and path)
what parameters should I provide for methods like :
dbus_g_bus_get 

 
(DBusBusType type, GError **error) // the type

dbus_g_proxy_new_for_name   (DBusGConnection 

 *connection,
 const char *name,
 const char *path,
 const char 
*interface); // what is the path and interface


dbus_g_proxy_call 

 
(DBusGProxy 
 
*proxy, const char *method, GError **error, GType first_arg_type,...) // 
what is the name of the method to call in order to send sms??
. etc

i am kind of lost and i dont't know where to find things like that

I appreciate any help
thanx in advance
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

RE: QA process = bug fixing disincentive?

[tero.kojo]

Andrew Flegg wrote:
> On Wed, Nov 4, 2009 at 09:03,   wrote:
> >
> > Two days later I notice a blinking orange light in my status bar. I 
> > see a new version of the application. I install, I check what has 
> > changed (minor or major?), I run my tests and thumb it up again.
> 
> Aside: how do you check what has changed?

For the stuff in garage it's simple; skim the source, and for others see what 
the package installed, and see if everything is still there.

> > I didn't loose too many minutes or hours of my life, no one 
> got killed 
> > or injured, and the punitive damages to all parties appear 
> to be zero.
> > Life's good and I get a cup of coffee.
> 
> Trouble is, developers (myself and others) are saying the 
> current process of resetting to zero on every single 
> promotion is incompatible with "release early and release 
> often". The theory about resetting to zero is that testers 
> will do the full QA process again (check it still uses /opt, 
> check a bug hasn't been introduced which introduces battery 
> management issues, check that it both installs, uninstalls 
> and upgrades cleanly).

Yes, none of those are so hard that I wouldn't do it. (Ok, I sometimes skimp on 
the uninstall testing for apps that will never leave my device. I'm a bad 
person)

> > In other words, I test applications that I use or leave on device.
> > It's not something I do randomly. I believe that the author 
> of the app 
> > has committed to the app, so in return I commit to it as well. The 
> > rules and process are a good thing, but in the end it is 
> people who do 
> > the things. No matter if it is the developer, the tester or 
> the user, 
> > it's about the people.
> 
> Yep, however I now disagree with the logical conclusion of 
> your statement (which has been expressed elsewhere) which is 
> "when we have lots of users it'll all work itself out".

I still think that. 10 votes from an installed base of fifty, a few hundred or 
say ten thousand is a different thing.

> [and your original statement]
> > Too complicated.

Referring to the complex schemes of saving the karma points. Sounds too 
complicated to start counting things like time, rate times or things like that. 
It might be cool to implement, but does it make sense?

Just do something really simple like new version get's the old votes if the app 
is still in testing. The tester will see the new version and change her/his 
mind if necessary.

> We seem(ed ;-)) to have a consensus between this thread, and 
> the QA marathon feedback, between both developers and testers 
> that resetting to zero was causing more problems than it 
> solved. We've now moved on to ways of maintaining some app 
> karma from one release to another, but it sounds like you 
> disagree with that consensus? 

I see issues in saving the karma, but they can most likely be worked out. 
Either dump the votes or keep them. Just don't make it too complicated.

> It may be that there are two 
> kind of testers:
> 
> * Dedicated QA browsers. Will install any app from the QA queue
>   to evaluate and score it. Will be done whenever they have time.
> 
> * Dedicated application users. Will install upgrades of 
> apps they've
>   installed and evaluate/score them as pushed to.

This most likely is the case. I do admit to random testing once in a while, but 
it is more to see whether there is something I could start using occasionally.

Tero

> Cheers,
> 
> Andrew
> 
> --
> Andrew Flegg -- mailto:and...@bleb.org  |  http://www.bleb.org/
> 
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: RE: Re: Maemo5 on Beagleboard

[Henning Heinold]

On Fri, Oct 30, 2009 at 01:57:11PM +0100, Till Harbaum wrote:
> Hi,
> 
> > It's in the alpha patch
> Found it. Unfortunately it doesn't help.
> 
> I think i need some help of an x-server expert here. The problems with my
> touchscreen are related to this:
> (**) eGalax Inc. USB TouchController: Device: "/dev/input/event3"
> (**) eGalax Inc. USB TouchController: Calibration factors: 200 3910 3761 180 
> 0 0
> (II) eGalax Inc. USB TouchController: Found x and y absolute axes
> 
> The calibration factors are completely nonsense and in fact the behaviour
> of the touch makes sense when taking these numbers into account. But my touch 
> needs
> 100 1900 100 1900 0 0
> 
> Where do these default numbers come from? Adding some section like described
> here http://www.conan.de/touchscreen/evtouch.html does not have any impact 
> on these wrong numbers.
> 
> Till

Hi Till,

did you download the latest driver from
http://home.eeti.com.tw/web20/eGalaxTouchDriver/linuxDriver.htm ?

It comes with binary calibration and configure program called Touchkit,
which resolve your touchscreen problems. There is one funny think to notice
the right mouse click is emulated be holding the touchscreen for some time,
but this is configurable to your needs via the Touchkit-program.

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

Re: QA process = bug fixing disincentive?

[Andrew Flegg]

On Wed, Nov 4, 2009 at 09:03,   wrote:
>
> Two days later I notice a blinking orange light in my status bar. I see
> a new version of the application. I install, I check what has changed
> (minor or major?), I run my tests and thumb it up again.

Aside: how do you check what has changed?

> I didn't loose too many minutes or hours of my life, no one got killed
> or injured, and the punitive damages to all parties appear to be zero.
> Life's good and I get a cup of coffee.

Trouble is, developers (myself and others) are saying the current
process of resetting to zero on every single promotion is incompatible
with "release early and release often". The theory about resetting to
zero is that testers will do the full QA process again (check it still
uses /opt, check a bug hasn't been introduced which introduces battery
management issues, check that it both installs, uninstalls and
upgrades cleanly).

> In other words, I test applications that I use or leave on device.
> It's not something I do randomly. I believe that the author of the app
> has committed to the app, so in return I commit to it as well. The
> rules and process are a good thing, but in the end it is people who
> do the things. No matter if it is the developer, the tester or the
> user, it's about the people.

Yep, however I now disagree with the logical conclusion of your
statement (which has been expressed elsewhere) which is "when we have
lots of users it'll all work itself out".

[and your original statement]
> Too complicated.

We seem(ed ;-)) to have a consensus between this thread, and the QA
marathon feedback, between both developers and testers that resetting
to zero was causing more problems than it solved. We've now moved on
to ways of maintaining some app karma from one release to another, but
it sounds like you disagree with that consensus? It may be that there
are two kind of testers:

* Dedicated QA browsers. Will install any app from the QA queue
  to evaluate and score it. Will be done whenever they have time.

* Dedicated application users. Will install upgrades of apps they've
  installed and evaluate/score them as pushed to.

Cheers,

Andrew

-- 
Andrew Flegg -- mailto:and...@bleb.org  |  http://www.bleb.org/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

RE: QA process = bug fixing disincentive?

[tero.kojo]

Andrew Flegg wrote.
> 
> Jeremiah wrote:
> >
> > Shall we put a checkbox by the package promotion page, or somewhere 
> > where we remember, which keeps all accrued karma?
> 
> That's probably a good first step, however I wonder if long 
> term something like Marius suggested might be better: 
> remaining karma for an app is...
> 
>* proportional to current app karma
>* proportional to developer's karma
>* proportional to testers' karma
>* inversely proportional to the time between
>  last build and this build.
> 
> This'd mean that if I released an app and had it voted up by 
> Ryan, Tim, Daniel, Quim and a few others on the first karma 
> page; and I released a new version the next day (short time 
> => probable bug fix); my app might only lose one or two points.
> 
> Maybe this works for time too (or vote by high roller reduces 
> time?) Or maybe it's just too complicated?

Too complicated.

I start testing an application that I pick from extras-testing (a repository 
that is enabled on my device). I do my tests, am happy and go press a thumbs up.

Two days later I notice a blinking orange light in my status bar. I see a new 
version of the application. I install, I check what has changed (minor or 
major?), I run my tests and thumb it up again.

I didn't loose too many minutes or hours of my life, no one got killed or 
injured, and the punitive damages to all parties appear to be zero. Life's good 
and I get a cup of coffee.

In other words, I test applications that I use or leave on device. It's not 
something I do randomly. I believe that the author of the app has committed to 
the app, so in return I commit to it as well. The rules and process are a good 
thing, but in the end it is people who do the things. No matter if it is the 
developer, the tester or the user, it's about the people.

Tero

> Thoughts welcome.
> 
> Cheers,
> 
> Andrew
> 
> --
> Andrew Flegg -- mailto:and...@bleb.org  |  http://www.bleb.org/
> 
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers