Re: Optional build dependencies (e.g. for fremantle)

[Guillem Jover]

On Wed, 2009-03-18 at 13:50:00 +0100, ext Till Harbaum / Lists wrote:
> Am Dienstag 17 März 2009 schrieb Till Harbaum / Lists:
> > > Build-Depends: would-like-to-have-pkg1|harmless-pkg2,
> > > would-like-to-have-pkg2|harmless-pkg2, ...
> > I'll give it a try.

> Ok, first try yesterday was
> Build-Depends: maemo-version-dev, 
> tablet-browser-interface-dev|maemo-version-dev, ...
> 
> This did not install tablet-browser-interface-dev. There seems to be
> some optimization somewhere that makes such a shortcut impossible.

There's no optization of any kind going on here. You request a
dependency to be fullfilled and maemo-version-dev does that, so
there's no point in also installing tablet-browser-interface-dev.

> So i just tried:
> Build-Depends: maemo-version-dev, tablet-browser-interface-dev|devscripts, ...
> 
> Which works fine and pulls tablet-browser-interface-dev in. What about the 
> package
> to use for this? Such a packet has some limitations:
> 
> - It must not be a dependency of anything else the build depends upon. E.g. 
> things
>   like libpng-dev will likely always be loaded due to dependencies from the 
> gui
>   libs.
> - It must always be present
> - It must be something an application will normally never need to build 
> successfully 
>   (it should never become a real dependency)
> 
> This seems to be true for devscripts. Any other suggestion?

Yes, do *not* do that, it's a major hack, and it might stop working at
any time, you cannot control if some of the other Build-Depends will at
any point start pulling devscripts (or any phony package you want to
add there).

The clean and proper way to do this is to branch the packaging, in
Debian, packages always target the latest (sid), and often people do
backports for old releases (oldstable, stable, etc).

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

Re: Optional build dependencies (e.g. for fremantle)

[Guillem Jover]

On Tue, 2009-03-17 at 13:38:39 +0100, ext Till Harbaum / Lists wrote:
> i am currently trying to prepare the osm2go package to build for
> fremantle. I've fixed most things, but one thing still lacks: How do
> i specify "would like to have" build dependencies?

The short answer is that you don't.

> E.g. i'd like to rely on table-browser-interface-dev. But this isn't
> there yet for fremantle. So if i have it in the build-depends line in
> the control file the fremantle build breaks. If i don't put it there it
> won't be installed in any autobuild process, hence it won't be used
> in chinook/diablo autobuild.
> 
> How do i specifiy a package that i'd like to use during buikd but that
> i can cope with if it's not there (yet)?

Oportunistic Build-Depends are bad because they make your build not
reproducible, as it can change depending on the system it got built
in. The point is that anything not listed on the Build-Depends is not
guaranteed to be present (even on a fremantle build daemon).

I guess in your case, you'll have to branch the packaging for
chinook/diablo and fremantle.

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

Re: Warnings when starting scratchbox (diablo) on debian Lenny

[Guillem Jover]

Hi,

On Fri, 2009-03-13 at 15:26:52 +0100, Jeremiah C. Foster wrote:
> When I start up my dev environment in scratchbox I call 'af-sb-init.sh
> start'. I then get this warning;
> 
> Starting Maemo Launcher: maemo-launcher.
> defender: died my parent is not who he claims to be
> maemo-launcher: warning rising the oom shield for pid=8471 status=2816

> I assume this is not so serious since everything works, but I would love
> to know a little more about what is happening here.

Yeah, it should not be a problem under sbox as there should not be
the same memory limitations as on the device.

> And shouldn't that be "raising oom shield" instead of "rising"? :)

Hmm ‘rising’ is not a verb, fixed the typo now in my git tree, thanks!

> Google also mentions the Linux Out of Memory killer which may be why the
> shield is protecting against. Am I right in that assumption?

Right.

Given that the maemo-launcher main process is spawning most of the UI
processes on the device it gets lots of points from the OOM killer,
even if it's not directly at fault for its childs allocations.

So it tries to protect itself from OOM killer by executing the defender
(found in /usr/lib/maemo-launcher/defender). The defender is a suid root
binary that disables the OOM killer for the main maemo-launcher, as
the latter is running with normal user privs. To make sure no other
process can also use the defender, it checks for its caller to be
exactly /usr/bin/maemo-launcher (or whatever path was used as prefix
at configure time).

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

Re: Application Manager and Extras-devel: Dealing with unstable software

[Guillem Jover]

Hi,

On Tue, 2008-11-25 at 16:38:08 -0500, ext Ryan Abel wrote:
> Let's say you've got a user, and this user wants to get to something  
> shiny, but the only place this something shiny is available is from an  
> unstable testing repository. Normally this unstable testing repository  
> would not be the sort of place this user would venture into, but the  
> application is only there because a few minor packaging issues have to  
> be wrapped up (maybe the l10n is split up into a bunch of separate  
> packages); or there's just a few more bugs they want to stomp out; or  
> they want to give it a week or two of testing before they push it to  
> the unstable repository--whatever, so the user decides (perhaps with  
> the encouragement of some of their peers) to dive in, add the unstable  
> repository and install the application.

[ Long description of highly unstable repostory usage removed. ]

This is what in Debian is called «experimental».

> Those issues aside, what can we do at an application level to improve  
> the user experience here? An opt-in system for Extras-devel updates  
> and installs might be useful (rather than offering the Extras-devel  
> version, the user has to request it specifically), visual cues to a  
> packages origin (color coding, a small icon) and notices might also  
> help ("this package is unstable software, and may contain many  
> significant bugs, are you sure you want to install it?"), or even some  
> sort of apt pinning system to ignore certain updates.

And this is already solved in Debian, by just marking experimental as
to not be used to automatically upgrade packages from there. Apt will
pin it down to priority 1, while unstable has normally priority 500.
The only needed thing is to add an “NotAutomatic: yes” field in the
Release file for experimental.

So, with this, one can select to upgrade to a specific version from
experimental, but this needs to be explicit. Otherwise no other package
will be upgraded from there.

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

Re: Aptitude for Maemo

[Guillem Jover]

Hi,

On Fri, 2009-01-23 at 11:27:41 -0500, Ryan Abel wrote:
> On Jan 23, 2009, at 11:23 AM, Jonathan Marsaud wrote:
> > In my humble opinion, aptitude should be added to the main seed of
> > Maemo; why is it not already the case?
> 
> Because 95% of Maemo users would never use it and flash space isn't  
> free?

But being on the repository does not imply being installed by default.
I think the former is what Jonathan tried to say.

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

Re: where might this old version be coming from

[Guillem Jover]

On Thu, 2008-10-02 at 12:52:44 +0300, Eero Tamminen wrote:
> Guillem Jover wrote:
> > You mean something like dpkg-scanpackages or apt-ftparchive?
>
> According to man pages they would seem to do at least part of the work,
> but it wasn't on quick reading clear how I would actually use them
> (I have no experience with maintaining or creating repositories).
>
> For example if:
> - I've built in Scratchbox ARMEL packages "a.deb" & "b.deb"
> - I'am outside of Sbox in the directory where these packages are
> - the device memory card is mounted to /media/n810/ on my Debian
>   Desktop
>
> What I need to do to get a "repository" created under
> /media/n810/repository/?

Something like:

  $ mkdir -p /media/n810/repository
  $ cp $sboxdir/*.deb /media/n810/repository/
  $ cd /media/n810/repository/
  $ $packages_generator . | gzip -9 > Packages.gz

where packages_generator is either “dpkg-scanpackages” or
“apt-ftparchive packages”.

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

Re: where might this old version be coming from

[Guillem Jover]

On Thu, 2008-10-02 at 09:37:42 +0300, ext Eero Tamminen wrote:
> I don't have any idea whether Application Manager supports what I 
> suggest below, but I think it's at least worth considering.
> 
> There could be a script that creates a repository from given packages,
> under given directory. Repository meaning =
> - certain directory structure where it puts the packages and
> - "Packages" file listing the given packages
> 
> This script could be run on desktop so that one gives it the packages
> one wants to test and as a directory, the USB mountpoint for the device
> memory card.

You mean something like dpkg-scanpackages or apt-ftparchive?

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

Re: SDL, pixel format and little endian issue

[Guillem Jover]

On Mon, 2008-09-01 at 16:27:55 +0300, ext Michael Stepanov wrote:
> SDL_GetRGB((Uint32)Pixel, m_pScreenImage->format, &red, &green, &blue);

> But now I have to fill pink pixel by specified color. And as I understand I
> should convert that color from 32bit to 16bit? How can I do it?

You can use SDL_MapRGB.

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

Re: Extras repository: clean out older versions.

[Guillem Jover]

Hi,

On Thu, 2008-07-24 at 16:26:02 +0200, ext Niels Breet wrote:
> Up until now we have always kept every version of a package that was
> uploaded to Extras. This wasn't considered a problem when we had only a
> few applications in the repository. But now we are getting more serious
> about Extras, we might want to consider cleaning up too.

Please!

> Why do we need to remove outdated packages?
> 
> We need to reindex the repository every once in a while and these extra
> files are taking up a lot of time to md5sum etc. Another side effect is
> that the Packages file gets very large when we list 10 times the same
> application but with a different version.
> 
> An example:
> http://repository.maemo.org/extras-devel/pool/diablo/free/a/advanced-backlight/
> 
> Does anybody know a good way to remove these old versions without causing
> dependency problems? I've searched for existing tools, but can't seem to
> find anything that is useful for this.

All this depends on what software are you using to handle the archive.
It would have to support some form of obsoleting, as you'd want to do
that continuously.

If it does not, the preferred option is changing the software, ideally
by switching to dak.

  

If for whatever reason you don't want to switch but have the .changes
files around you could use mini-dak's obsolete scripts. But then you'll
be mixing two different archive software, which seems messy.

  

The other cheap options, which will also probably only lead to pain are:

Generating the Package index files and then filter them with something
like dctrl-tools (uniq-dctrl from dbug#387413), but this will not fix
your long runtimes, neither remove the dangling packages.

  $ sort-dctrl -k Package -k Version:rv $original_lists | uniq-dctrl

Or use “dpkg-scanpackages”, which will not output dupes by default,
but might take way longer as it does no caching at all.

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

Re: How to know target in makefile?

[Guillem Jover]

On Tue, 2008-06-17 at 13:50:04 +0300, ext Daniil Ivanov wrote:
> This command return you some useful output
> dpkg-architecture -qDEB_BUILD_GNU_TYPE

I think you mean DEB_HOST_GNU_TYPE. And I guess DEB_HOST_ARCH_CPU
would be more useful, but I agree it does not seem to make much sense
to have the SONAME change depending on the arch, if it's not actually
providing really specific arch functions?

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

Re: policy: maemo packaging policy -draft

[Guillem Jover]

On Mon, 2008-06-02 at 12:15:05 +0100, ext Graham Cobb wrote:
> On Wednesday 28 May 2008 08:32:22 Eero Tamminen wrote:
> > A draft version of the "maemo packaging policy" is available
> > for commenting:
> >  https://maemo.org/forrest-images/pdf/maemo-policy.pdf

> I am not quite sure about the name: personally I am not convinced that we 
> need 
> a strict "policy" for Maemo packages.  I completely agree we need guidelines 
> but Maemo is a small (really, tiny) distribution, both in terms of users and, 
> more importantly for this discussion, developers.  Our most critical problem 
> at the moment is the lack of ported software, not the quality of the packages 
> which have been ported.  If anything, the number of active developers in the 
> Maemo community seems to be declining (for example, I was amazed by the 
> almost zero response to the autobuilder announcement).

"Porting" software should not be needed most of the time, and maemo
would be better off pulling directly from the Debian armel archives.

And honestly the packaging I've seen in general in Maemo is not that
good, not only the stuff from extras and similar, this also applies to
the one from Nokia.

About the autobuilder, I still don't understand the need to reinvent
the wheel, there's already infrastructure for that in Debian, but oh
well.

> I would be very firmly against any attempt to "enforce" a policy (for 
> example, 
> by preventing packages appearing in Extras if they violate the policy).  But, 
> I realise that that is a separate discussion.  My comments below do assume 
> that this is an advisory policy (or "guidelines" as I would prefer to call 
> it).

For really broken stuff I don't see what'd be wrong in not accepting
packages in the archives. I tend to agree thought that really strict
enforcing (like rejecting due to warnings or not really critical stuff)
at archive tool level is not generally good, as most of the time it just
makes development slower, but at the same time if the policy is not
followed (eventually) then there's not much point in having one.

Ideally the real enforcement would be done on the release side, so
packages that do not conform to all MUSTs would not get into the next
Maemo release.

> 2.2: The list of user sections should not be in this document.  It should be 
> on a Wiki page which can be maintained separately from the document.

This has been discussed before at length, but I think you guys want
just debtags.

> 3.2: This section needs to be clearer about the circumstances which cause 
> the "maemo" version string to be required.  If a Debian package is taken and 
> the only changes are to the debian/control file (e.g. Section: changed to 
> conform to 2.2, dependencies changed to reflect maemo environment 
> differences, maintainer changed, etc.) then I would have thought it should 
> retain the debian version number.  On the other hand, if a source or build 
> change occurs (for example, a feature which is enabled in the Debian version 
> is disabled in the maemo version because it makes no sense in that 
> environment, or is dependent on something which has not been ported) then the 
> maemo revision should be used. Other changes may be less clear (for example, 
> if the documentation has been removed as per 3.9.4).

Any change needs a new version, always, it does not matter the size of
the change. It's really not good to modify something and not increment
the version. Consider that in Debian even a rebuild (no changes at all)
of the same package, gets a new version number (+bN).

> 3.9: I don't really see the point in saying packaging changes SHOULD be 
> propagated back to upstream.  No Debian maintainer is going to change any of 
> their packaging for the benefit of Maemo!  Are you really suggesting people 
> should report bugs on a maemo package because the upstream maintainer chooses 
> to package it differently?!

No, people should report Maemo packaging problems in Maemo, but the
Maemo maintainer for a given package, should send patches upstream to
avoid divergence, of course not all changes are good or generic enough
for upstream, but the idea would be to reduce those to a minium, or
make them general enough so that they can be pushed. You'd be
surprised how many DDs/DMs would take clean and sane packaging
patches, that can benefit embedded systems.

Another thing is if people here start messing with stuff like
switching packaging from debhelper to cdbs, etc, and that'd be
unacceptable.

> 3.9.5.  I agree with this section as currently written.  It must not become 
> MUST as it is really only critical for general purpose libraries and general 
> purpose plugin based applications.  Some applications may use libraries and 
> plugins which are only for the convenience of the application developers and 
> are not, realistically, ever going to be used by anyone else -- in those 
> cases SHOULD would be correct.

I guess that makes sense, but only if those shared libraries or
plugins do no

Re: Curious: Maemo devices other than Nokia?

[Guillem Jover]

On Thu, 2008-01-24 at 08:13:56 +0200, ext Tapani Pälli wrote:
> Tollef Fog Heen wrote:
> > Yes, the coordinated way is to get it upstream or at least upstream
> > agreeing to such an API change.  Extending somebody else's API without
> > permission and without changing the soname is, IMNSHO, quite rude.
> 
> Yep, I agree. Release schedules can make hard to stay in sync though.

Sure. But one thing would be to backport stuff that has been already
accepted upstream, the other is to go our own way.

> If free distribution of modified sources is not generally wanted then
> perhaps the licensing model should provide a way to restrict it.

That's not the point. I don't think licenses are the proper tool
to address common sense and/or a proper relationship with
upstream/community.

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

Re: Packaging images into deb

[Guillem Jover]

Hi,

On Mon, 2008-02-04 at 10:17:12 -0500, ext Levi Bard wrote:
> # Example Makefile
> # The DESTDIR is important for dpkg

This is not only for dpkg or Debian, this is how proper upstream build
systems should behave, to ease packaging the software. It allows to
install in a different directory than the one it was built for, so
that you can relocate when creating the packages.

> all:
> 
> install:
> mkdir -p $DESTDIR/my/image/directory
> cp images/* $DESTDIR/my/image/directory
> # End Makefile

$DESTDIR is not going to do what you think it would, what you want is
$(DESTDIR) instead. Also you might want to use install calls instead
of mkdir and cp.

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

Re: Curious: Maemo devices other than Nokia?

[Guillem Jover]

On Wed, 2008-01-23 at 13:49:19 +0200, ext Tapani Pälli wrote:
> Riku Voipio wrote:
> > The layering violation is including a function
> > hildon_gtk_im_context_show() inside *gtk-2-0*. And the call for

> What's the problem? Why we could not have our own custom functionality
> in our Gtk+ tree?

Huh? Because that's just wrong, it's a layering violation as Riku
said, and because we are extending the API in an uncoordinated way
with upstream. Reminds me of embrace and extend...

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

Re: Announcement: OS2008 2.2007.50-2 source repository

[Guillem Jover]

On Mon, 2008-01-07 at 12:57:10 +0200, ext Santtu Lakkala wrote:
> Graham Cobb wrote:
> > To my mind there are two solutions to this:
> > There is a third option: make the process of upgrading the tablet so easy 
> 
> The fourth option would be to assure the shlibs -files of said libraries
> always contained at most the version of the first release. To do this,
> however, it is not enough to keep ABI compatibility, but you cannot
> introduce any new functions either -- or then you need to create a
> "better" shlibs-system. ;)

You mean like the one in the latest dpkg versions? :)

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

Re: Static and dynamic linkage

[Guillem Jover]

On Wed, 2007-11-28 at 10:19:17 +0200, ext Eero Tamminen wrote:
> [EMAIL PROTECTED] wrote:
> > Is there a standard way to ask for a specific library to be linked in 
> > statically and the rest to be dynamic?
> 
> Just specify the static library you want to link with:
>   gcc -o test -lsomedynamiclib my-static-libs/foobar.a

Better do something like:

  $ gcc -o test \
  -lsomedynamiclib \
  -Wl,-Bstatic -lsomestaticlib -Wl,-Bdynamic \
  -lsomeotherdynamiclib \
  ...

> > Specifically, I want to statically link in the SQLite library but leave 
> > the rest of the linkage as is.

I'd say better not to statically link at all.

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

Re: Maemo localization to officially non-supported languages

[Guillem Jover]

On Wed, 2007-10-24 at 14:56:46 +0300, ext Marius Vollmer wrote:
> In general, we should try to reduce the need for context and
> complicated translations.  The classical example might:
> 
>Searched in %d files and %d directories.
> 
> You will never be able to translate this nicely for all languages
> because of the wierd way they handle plurals, etc, and because of the
> combinatorial explosion.  A better way is:
> 
>Number of files searched: %d
>Number of directories searched: %d

That's what ngettext is for...

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

Re: Maemo localization to officially non-supported languages

[Guillem Jover]

Hi Jordi,

On Thu, 2007-10-18 at 21:20:11 +0200, Jordi Mas wrote:
> It seems technically possible to localize the different components to
> other languages since all the infrastructure is based on intltool and
> seems very well internationalized.

Well, the source code is using logical strings, which I've pointed
out in the past being a bad idea (internally and on this list [0]).
But then I'm not officially involved with l10n at Nokia.

At the time, I wanted to start translating it to Catalan, but I decided
I didn't want to waste my spare time dealing with the logical strings.
Supposedly some packages might be switching or have switched to
"engineering english", which is an improvement, but still. Good luck
anyway ...

regards,
guillem

[0] http://lists.maemo.org/pipermail//maemo-developers/2006-February/002974.html
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Software categories

[Guillem Jover]

On Tue, 2007-08-14 at 19:00:44 +0300, Ed Bartosh wrote:
> On Tue, 2007-08-14 at 02:01 +0100, Neil MacLeod wrote:
> > Marius Vollmer wrote:
> > > Neil MacLeod writes:
> > > > Perhaps if someone can identify the method currently being used by
> > > > the Application Manager to group applications it can cut down on the
> > > > guesswork, and give us a base from which to move forward.
> > > 
> > > http://hildon-app-mgr.garage.maemo.org/packaging.html
> > 
> > Thanks and I give up. The predefined sections in the packaging guide 
> > matches quite closely the list of "categories" I had proposed in this 
> > mailing list.

> Don't give up please. Let's agree on the category list and I'll add this
> list to queue-manager as Ferenc suggested. It can work the following
> way: packages without 'User' sections will be processed by queue-manager
> and added to the garage-testing repository without any check. Packages
> with 'User' section will be checked against list of allowed sections and
> will not be uploaded to the repository if section name isn't found in
> the list. Email with explanations will be sent to uploader.

First, please could people stop inventing new names for exsting
things, it gets really confusing (Ed, this is not directed at you,
just about this general trend on Maemo...).

For the Section:s stuff, as I've said few times on this thread, you
just need to add override files (check the man pages for deb-override,
dpkg-scanpackages and/or apt-ftparchive on an up-to-date Debian sid
system). This makes unnecessary to fork the current packages taken
from Debian, allows centralized changes in the Section:s on the
archive if need be, and does not require rejecting packages just for
this.

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

Re: Software categories

[Guillem Jover]

On Tue, 2007-08-14 at 18:00:37 +0300, Marius Vollmer wrote:
> Guillem Jover" <[EMAIL PROTECTED]> writes:
> > I disagree. You'd be using tags to filter what you show. Probably
> > we'd iwant a new tag like uitoolkit::hildon, but that's not maemo
> > specific, and it's not needed to start using them with the current
> > tagged data.  You could show only packages matching a set of tags, a
> > starting point could be for example:
> >
> >   role::program && interface::x11 && \
> >   (uitoolkit::hildon || uitoolkit::gtk || uitoolkit::sdl || uitoolkit::xlib)
>
> Right, that makes a lot of sense.  But still, it is a rather indirect
> way of controlling visibility in the AM.

And I think that's a feature. One just needs to come up with an
adequate filter for your specific needs.

> What about packages like language packs that enhance the system in
> some subtle way?

In this particular case you could also show packages having the
culture::catalan tag (for example), if my system locale is ca_ES. And
you could change that dynamically depending on the locale.

> It is very important whether or not a package is shown in the AM and I
> think we should let a package declare itself visible in a very direct
> and dedicated way.

I think this is a bad idea, it encodes our (Maemo and/or Nokia) narrow
definition of end user into the packages (although the tag data can be
just supplied externally, but still). Also I'd guess 3rd party devels
would like their apps to show up on the AM, so there might be some
abusing with this kind of tags.

> What about a "audience" tag?  The default filter rule could be
>
> audience::enduser

enduser defined in Maemo terms, or how do you come up with a general
definition that can be universally used upstream?

> or something and we could have others like audience::poweruser,
> audience::admin, audience::hacker, etc.

I don't remember exactly, but I think there was some talk about this
upstream and it was rejected. I'd have to check the archives, though.

There's already an admin:: namespace, there's also use:: and other
similar, if there's missing stuff, I'm sure upstream would be glad to
listen, and maybe we should move this discussion there?

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

Re: Software categories

[Guillem Jover]

On Tue, 2007-08-14 at 16:03:13 +0300, Marius Vollmer wrote:
> Guillem Jover" <[EMAIL PROTECTED]> writes:
> > Right, currently it's using the Section, but personally I think that's
> > a mistake, which I've told Marius several times, the proper solution is
> > using tags.
>
> Using tags instead of the section is just another implementation of
> the same feature.  Had I used tags, we still would have to have a
> special maemo specific tag that controls visibility in the AM, and
> people would still be diverging from Debian.

I disagree. You'd be using tags to filter what you show. Probably we'd
iwant a new tag like uitoolkit::hildon, but that's not maemo specific,
and it's not needed to start using them with the current tagged data.
You could show only packages matching a set of tags, a starting point
could be for example:

  role::program && interface::x11 && \
  (uitoolkit::hildon || uitoolkit::gtk || uitoolkit::sdl || uitoolkit::xlib)

Or something on those lines. Also the user could be allowed to change
the tag filtering, even if it was on some advanced mode, hidden menu or
whatever.

> But, tags are better than sections, and maybe it is easier to diverge
> when using tags.

I don't think we'd need to diverge, for example I can see the hildon
tag accepted upstream, also given that tags represent facts from the
software, that makes them quite neutral.

> In any case, tags are more powerful and the AM should clearly support
> them as well.

Good!

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

Re: Software categories (was do we need garage sandbox repos?)

[Guillem Jover]

On Mon, 2007-08-13 at 17:17:41 +0100, Neil MacLeod wrote:
> Guillem Jover wrote:
> > On Mon, 2007-08-13 at 15:32:01 +0300, Eero Tamminen wrote:
> > There's no cli section in Debian. But anyway, what you did is incorrect,
> > as the Section from the '.deb' packages is not the authoritative
> > source. The Section:s are overriden on the archive, so you should check
> > from the Package metaindex files. «apt-cache show» is your friend.
> 
> $ apt-cache show ncurses-bin | grep -i cli
> Section: user/cli

Ah, I was talking about the Debian package. I find it disturbing that
the Section:s are being modified on all those packages, this is useless
divergence! If there's really a need to change the Section the override
on the archive side should be used instead...

> Any other suggestions as to how Application Manager is determining what
> applications appear within each "button" in the "Browse Installable
> applications" page?

Right, currently it's using the Section, but personally I think that's
a mistake, which I've told Marius several times, the proper solution is
using tags.

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

Re: Software categories (was do we need garage sandbox repos?)

[Guillem Jover]

Hi,

On Mon, 2007-08-13 at 15:32:01 +0300, Eero Tamminen wrote:
> Neil MacLeod wrote:
> > Having downloaded a handful of debs and viewed the info with "dpkg --info 
> > "
> > it's clear that by "category" I mean "Section", eg. ncurses-bin appears in
> > the category "cli" within Application Manager while the deb has a "Section"
> > value set to "user/cli".

There's no cli section in Debian. But anyway, what you did is incorrect,
as the Section from the '.deb' packages is not the authoritative
source. The Section:s are overriden on the archive, so you should check
from the Package metaindex files. «apt-cache show» is your friend.

> If there's nothing inside given section, it should not be shown,
> similarly to menus.  It could be that Debian sections should have
> a similar revamp as what they're doing for their menu policy...

I'd say Section:s are something obsolete which used to work more or
less when Debian size was way way smaller. It was also used for some
time to define what was part of the base system for example, this is
not the case anymore.

The future is in debtags, which is way more powerful and flexible.
Some frontents have some support for it already. For example you
can do something like:

  $ aptitude search ~Guse::debugging ~Gimplemented-in::haskell

> Btw. I'm not really sure what or whether there's a formal mapping
> between Debian sections and menu policy, maybe some debian developer
> could clarify this?

I don't think there's any mapping. And I don't think there should be
much effort spent on this, tagging on the other hand might be more
useful.

  

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

Re: Software categories (was do we need garage sandbox repos?)

[Guillem Jover]

Hi,

On Mon, 2007-08-13 at 10:31:23 +0300, ext Eero Tamminen wrote:
> Neil MacLeod wrote:
> > Ferenc Szekely wrote:
> > > Neil raised a very important point in his mail: categories and control
> > > of the repository. We could experiment with the categories in this
> > > "extras-testing" repository. First we would need a proposal of
> > > categories. The best would be to write this on a wiki page. Neil,
> > > would you mind coming up with a draft?
> 
> Could you first define what you mean by "category"?
> 
> I have a bug in Bugzilla about the terminology, and it's not very clear:
>   https://bugs.maemo.org/show_bug.cgi?id=1524
> 
> This is the relevant part in Debian Policy:
>   http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections
> 
> The Maemo sections should at least try to mostly match Debian as we use
> Debian as upstream.  Otherwise there will be useless patching of
> packages when they are built/ported for Maemo.

Right.

> > [ ... "category" examples ... ]

> > Any thoughts?

Depending on what's referred to with "category", there's already
several systems in use, please do not create a new one...

> I guess this also relates to menu policy, i.e. where the applications
> should be in the menu.  Debian is currently in process of changing
> it:
> http://lists.debian.org/debian-devel-announce/2007/07/msg0.html
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=361418

The menu package implements new policy already, in functional and
documented forms. The menu subpolicy included in the Debian policy
package has not been updated yet, as in Debian, policy follows
practice.

> and I think Debian has already accepted the change, but he actual
> menu policy document is not yet updated, it's still the obsolete
> one:
> http://www.debian.org/doc/packaging-manuals/menu-policy/ch2.html#s2.1

Right.

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

Re: 3.2007.10-7 - Detailed change log?

[Guillem Jover]

Hi,

On Fri, 2007-08-03 at 16:39:07 +0100, ext Andrew Flegg wrote:
> On 8/3/07, Eero Tamminen <[EMAIL PROTECTED]> wrote:
> > Please check what's available; kernel and X git repositories you should
> > find with Google, Application framework stuff you will find from Maemo
> > (until it's moved to Gnome), new Browser is in Garage.  For all the open
> > source(d) packages you find the debian source package from the maemo
> > repos and those contain change logs.  Maybe you could view them and tell
> > what specifically you're lacking?

> OK, so the only changelog we need is:
> 
>   * Moved from vX.Y.Z to vX.Y.Z2 of Xorg
>   * Moved from v2.6.20-arm-rmk0 to v2.26.23-arm-rmk1 of Linux kernel
>   * Moved from branches/20060403-HAF r3929 to branches/20070801-HAF r3829
>   * ...

Err, then I think the problem is that people don't seem to be talking
about the same things here.

When I read people demanding changelogs, for me that maps to
debian/changelog or GNU style kind of ChangeLog in the source tree.
Any package w/o a proper descriptive changelog is broken IMO, and it
must be fixed.

What you seem to be asking for, is some kind of Release Notes, with the
most important package versions, or really big features. And if I'm
not mistaken we have that already, it might be lacking, though.
Otherwise please explain exactly what are you requesting, I think Eero
is having the same problem understanding what people is asking.

> Of course, this presupposes there are absolute *zero* patches that
> you're maintaining internally for these things which aren't upstream.

I say that presupposition is wrong. Take Debian as an example, most
of the packages contain changes relative to upstream, yet this is not
announced in any kind of distro-wide Release Notes. It's present,
though, on the particular NEWS.Debian files or debian/changelogs.

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

Re: Help with menu integration for an X11 game

[Guillem Jover]

Hi,

On Fri, 2007-08-03 at 08:56:45 +0300, Tapani Pälli wrote:
> Missouga wrote:
> > Please let me know if you can help me to build a proper .deb package
> > with an install file out of this project.
>
> I don't want to tell you as I might be using politically incorrect
> method of doing debian packages myself.

If it's wrong, I'd say it's technically wrong, not politically. ;)

> But here's a link to package guide available at maemo.org :

> http://maemo.org/development/documentation/how-tos/3-x/how_to_make_a_dbg_package.html

This refers to building debugging packages, though. I'd recommend
first reading the Debian Policy [0], the Debian New Maintainers'
Guide [1] and some parts of the Debian Developers' Reference [2].

After that you could check the specific parts applying to Maemo [3].

regards,
guillem

[0] 
[1] 
[2] 
Section 5 (only some subsections), section 6 and A, probably.
[3] 

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

Re: maemo trademark policy draft

[Guillem Jover]

Hi,

On Fri, 2007-05-11 at 19:42:25 +0300, ext Quim Gil wrote:
> We have just published the maemo trademark policy draft for community
> review. Its purpose is to regulate the usage of the maemo mark, owned by
> Nokia, basically allowing the good uses and discouraging all the rest.
> We have followed a flexible approach similar to the Mozilla Foundation
> Trademark Policy and the GNOME Trademark Licensing.
> 
> Please have your say. This trademark is also a tool to protect your
> interests as maemo users and developers.
> 
> The materials:
> 
> http://maemo.org/intro/licenses/trademark_faq.html
> Start here specially if you are not familiar with trademark texts.
> Contains the most essential elements of the rest of documents.
> 
> http://maemo.org/intro/licenses/trademark_policy.html
> The basic text. Contains the what, the why and the how.

In the general section when talking about the maemo trademark and
significant changes done to products and services it states those may
not be distributed. Even if it seems to refer to maemo as a whole
(like the distro or whatever), I take that applies to single software
projects which have maemo in their name as well? How much would be a
significant change (I'm thinking on the general patching a distro might
do which depending on your interpretatino might be significant)?
If the non-commercial use right applies to those single projects
(which I also take it does), those would have to be renamed on
inclusion on free distros so that derivatives can use them safely?

> http://maemo.org/intro/licenses/trademar_usage_guidelines.html
> Willing to use the maemo mark? Have a look here for guidance and
> instructions.
> 
> http://garage.maemo.org/frs/download.php/1362/maemo_logos_v3.3.zip
> The set of official logos. The one that is in the current web header
> plus other variants (B/W, 3D, etc).

What's the license for those logos, there's not file stating any in
the zip file?

> Of course all the projects/products currently called maemo something can
> keep the name. You were quicker than us, well done. You will be subject
> to the policy and guidelines, though, just like anybody else (including
> i.e. the team running this website).

This contradicts with what's stated on the FAQ, which is the correct one?

regards,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: creating new targets based on bora

[Guillem Jover]

On Mon, 2007-04-30 at 11:42:06 +0300, ext Miko Nieminen wrote:
> On 30/04/07, Daniel Stone <[EMAIL PROTECTED]> wrote:
> >Why do you use ar and tar instead of dpkg --build?  The former are not
> >guaranteed to work: dpkg uses a certain defined set of ar functionality,
> >whereas GNU ar has some extensions.  So, a file generated with GNU ar is
> >not guaranteed to be a valid Debian package.
> 
> Because original script did it that way. Like I said it's not pretty one, I
> just modified original install script to meet my needs.

The original is as wrong as this one. ;) Also the term used to refer
to those packages is misleading, virtual packages by definition are
not real ones, they only exist in the db as Provides.

> What you say is very true and it would be good idea to fix that one. Maybe
> some one could fix original install script too ;)

Just «apt-get install equivs», and check the manpages ... although
this should not be abused either!

regards,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: Fwd: Compiling latest kernel (from kernel.org, linux-omap git version) in n800

[Guillem Jover]

On Thu, 2007-04-26 at 17:44:31 -0300, ext Leandro Melo de Sales wrote:
> So, finally. Is the unique solution to wait nokia until they release
> the umac.ko source and live with n800 + latest linux-omap kernel
> version without WLAN support?

Normal module-init-tools' modprobe has a --force-vermagic option,
which you could use to load umac.ko and ignore its vermagic info. I
don't see this option supported right now by busybox modprobe, but
should not be that much work to add it.

Of course this is a workaround, and the proper solution would be to
have the source for that module, but sadly that's not the case now
so ...

regards,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: Boot Screen and Start App at Boot up

[Guillem Jover]

On Thu, 2007-04-26 at 13:35:24 -0700, ext Ian wrote:
> > And, do you know of a way to launch an application at startup? I would
> > like the unit to launch the image viewer at startup. Ideally, full
> > screen.

> I think maemo-launcher listens to system dbus to launch a program and
> as the install.sh script sym links to the init script /etc/rc2.d/ for
> maemo-launcher maybe look into hacking this

maemo-launcher does not listen to dbus, it just starts programs
through maemo-invoker (or maemo-summoner). But dbus can start services
by itself if asked for.

regards,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: soup2.2 and soup2.2-8 don't make a good broth (gpe build problem)

[Guillem Jover]

On Thu, 2007-04-26 at 22:51:30 +0200, ext koos vriezen wrote:
> 2007/4/25, Santtu Lakkala <[EMAIL PROTECTED]>:
> >marc zonzon wrote:
> > > did somebody solved this problem?
> >
> > I guess the only solution is to rebuild the packages using libsoup2.2
> > against libsoup2.2-8 (or vice versa). Or to remove and not use any
> > packages using one or the other.
> 
> Q&D:
> $ dpkg-deb -x libsoup2.2-8_2.2.100-1mh3_armel.deb
> libsoup2.2-8_2.2.100-1mh3_armel
> $ dpkg-deb -e libsoup2.2-8_2.2.100-1mh3_armel.deb
> libsoup2.2-8_2.2.100-1mh3_armel/DEBIAN
> $ vi libsoup2.2-8_2.2.100-1mh3_armel/DEBIAN/control
> $ mv libsoup2.2-8_2.2.100-1mh3_armel.deb libsoup2.2-8_2.2.100-1mh3_armel.old
> $ dpkg-deb -b libsoup2.2-8_2.2.100-1mh3_armel
> 
> and hope it will work

Err, for something that you have the sources, you are proposing to
edit the binary packages? ...

regards,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: how to make install package for applications written in python

[Guillem Jover]

Hi,

On Tue, 2007-04-24 at 22:36:10 +0200, ext Kees Jongenburger wrote:
> On 4/24/07, Xi Chen <[EMAIL PROTECTED]> wrote:
> > Could tell me how to make debian package for python applications? I
> > developed my application using python and not in scratchbox environment…
> > directly edit file and test it in real device. Following the tutorial from
> > maemo.org, I found command "dh_make" isn't there in device…

Probably best to check the Debian python policy, there might be some
tools missing in Maemo though, I've not checked that. But it can give
some guidance:

  

You might want to check general packaging documentation such as:

  
  

Some of the things mentioned there might be quite Debian specific,
take that into account.

> Have a look at the closed source maemo sdk installer script they
> create .deb files
> the script show that it's "easy" to create .deb files without needing
> debian at all
> 
> http://repository.maemo.org/stable/bora/maemo-sdk-install_3.1.sh
> I think this is the relevant section
> http://paste-it.net/1993/
> It can be handy to add the right depends in the .deb file

Please don't, creating packages this way does not guarantee getting
proper .deb files. You should have the guarantee to be able to extract
them with raw tar and ar though, but not generating them.

Use dpkg-deb, even if not using Debian, building dpkg is trivial.

regards,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: soup2.2 and soup2.2-8 don't make a good broth (gpe build problem)

[Guillem Jover]

On Wed, 2007-04-25 at 11:15:02 +0200, ext marc zonzon wrote:
> I try to install gpe from the experimental repository of Graham Cobb
> http://www.cobb.uk.net/apt/dists/bora/experimental/
> but it requires libsoup2.2 and I yet have a libsoup2.2-8; they seem
> mutually incompatible (not same version, option, dependency, the first
> one is build with gnutls not the second)
> did somebody solved this problem?

Those packages there seem broken, the library does not include the
SOVERSION in the package name. The packaging is not that good, it
seems to be the product of tweaking a bit the output from dh_make
(I could do a proper review if asked for).

I'd recommend you to rebuild the packages from Debian. I still don't
understand why people repackage everything from scratch...

regards,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: Instructions cache flush on ARM (was: N800 & Video playback)

[Guillem Jover]

On Mon, 2007-04-23 at 21:09:26 +0300, ext Siarhei Siamashka wrote:
> On Monday 23 April 2007 16:49, Guillem Jover wrote:
> > > You are right. gcc has function
> > > void __clear_cache (char *BEG, char *END)
> > > which should be more portable.
> >
> > It should, but it still has the problem of emitting an OABI syscall
> > due to our old gcc.
> >
> > You could use syscall(2) and __ARM_NR_cacheflush instead.
> 
> Yes, but __clear_cache(char *BEG, char *END)  works fine with the 
> current combination of gcc and kernel in maemo. So I guess it's the best 
> option if portability is desired.

That it works fine now does not mean it's the correct solution. Also I
disagree on the premise that it's more portable, both solutions are
quite non-portable, either you'll have to check if that function is
present in autoconf or similar, or you'll have to check for the presence
of the syscall NR on arm.

> If you decide to drop support for old ABI from kernel without upgrading
> gcc, that would be a bug in maemo platform :-)

No, because as this is coming from gcc it gets embedded in the actual
object, so it would need a recompilation, I wouldn't say that's a bug
in maemo, you have hardcoded OABI calls in your object files.

Also that makes it more difficult for people to flash their own new
kernel.

regards,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: Instructions cache flush on ARM (was: N800 & Video playback)

[Guillem Jover]

On Mon, 2007-04-23 at 16:11:17 +0800, ext 黄涛 wrote:
> 2007/4/23, Siarhei Siamashka <[EMAIL PROTECTED]>:
> > Thanks, it works. But I'm worried about [1]. Looks like EABI has a new
> > syscall interface and this code from qemu uses old ABI. And from reading
> > description at the wiki page, compatibility with old ABI can be disabled
> > (and it makes sense disabling it as this compatibility reduces
> > performance a bit).
> 
> You are right. gcc has function
> void __clear_cache (char *BEG, char *END)
> which should be more portable.

It should, but it still has the problem of emitting an OABI syscall
due to our old gcc.

You could use syscall(2) and __ARM_NR_cacheflush instead.

regards,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: Boot bora as root

[Guillem Jover]

On Thu, 2007-04-19 at 09:50:35 +0300, ext Eero Tamminen wrote:
> ext Kalle Vahlman wrote:
> > 2007/4/19, Chris Taylor <[EMAIL PROTECTED]>:
> >> looks like you ran  strace with /usr/bin/run-standalone.sh
> >> /usr/bin/maemo-summoner /usr/bin/osso-application-launcher  I
> >> couldn't get that to work .
> > 
> > I ran it like this (from a ssh shell):
> > 
> >  strace /usr/bin/maemo-summoner /usr/bin/osso-application-installer.launch
> 
> And this maemo-summoner usage should be documented in the Maemo
> debugging guide...

The utility usage is already documented on its man page.

regards,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: Cross compiling under debian

[Guillem Jover]

Hi,

On Wed, 2007-04-18 at 09:43:32 +0200, ext Sebastian Mancke wrote:
> So, at the moment I cross compile from my x86 debian, which seems to
> work fine except of the following problems with the debian packaging:
> 
> 1. dh_strip -a (from x86) does not know, how to handle the arm binaries.
> (I have disabled it with: DEB_BUILD_OPTIONS=nostrip)

You need to install binutils-multiarch.

> 2. dh_shlibdeps does not work, because the ldd (from the toolchain)
> tries to use ld-linux.so.3 from my host instead from the rootstrap.
> /home/asteban/maemo/toolchain/scratchbox/compilers/arm-linux-2006q3-27/arm-none-linux-gnueabi/libc/usr/bin/ldd:
> line 166: /lib/ld-linux.so.3: No such file or directory

Neither dh_shlibdeps nor dpkg-shlibdeps should be using ldd on the latest
Debian versions. Also dpkg-shlibdeps needs access to the dpkg db, to
match sonames with package names, so this will not work yet. You could
fix some of the problems with -L, but you'll need dpkg svn's trunk to
get the new --admindir. But admindir is not propagated to the child dpkg,
this needs to be fixed in general so that child processes inherit the
admindir variables (I talked about this in a thread about sbox2).

> 3. dpkg-architecture does not know 'arml'
> It would be possible to hack a fix in the script, like the one in
> scratchbox:
> sub debian_arch_fix
> {
> local ($os, $cpu) = @_;
> ...
> } elsif ("$os-$cpu" eq "gnueabi-linux-arm") {
> return "armel";
> ...
> }

It needs a bit more fixing than that, it's on the 1.14.0 roadmap.
Should be uploaded into unstable RSN.

> The problem 2. is my biggest one. Any suggestions? Cleaner solutions?

Either you wait, or you mess with the two scripts.

> My setup is as follows:
> 
> TOOLCHAIN=~/maemo/toolchain/scratchbox
> ROOTSTRAP=~/maemo/toolchain/rootstrap
> export
> PATH=$TOOLCHAIN/compilers/arm-linux-2006q3-27/bin/:$TOOLCHAIN/compilers/arm-linux-2006q3-27/arm-none-linux-gnueabi/libc/usr/bin/:$PATH
> export CC=`which arm-none-linux-gnueabi-gcc`
> export LD=`which arm-none-linux-gnueabi-ld`
> export AR=`which arm-none-linux-gnueabi-ar`
> export PKG_CONFIG_PATH=$ROOTSTRAP/usr/lib/pkgconfig/
> alias pkg-config='pkg-config --define-variable=prefix=$ROOTSTRAP/usr'
> 
> # no a nice soution
> export DEB_BUILD_OPTIONS=nostrip
> 
> Then I simply run 'fakeroot dpkg-buildpackage -d'

Ideally you should be able to use -aarmel and get it working, but we
are not there yet.

regards,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: sb2 wishlist

[Guillem Jover]

[ Bah, I had to subscribe to be able to post to the list... ]

On Thu, 2007-04-12 at 16:09:52 +0300, Lauri Leukkunen wrote:
> On 4/12/07, Guillem Jover <[EMAIL PROTECTED]> wrote:
> >On Thu, 2007-04-12 at 03:06:11 +0300, Lauri Leukkunen wrote:
> >> It would be nice if Nokia or some other entity with money or available
> >> resources would sponsor or provide these items for SB2:
> >>
> >> - apt and dpkg support
> >>  - these seem to be quite critical for Maemo usage
> >
> >> Support for apt is there, at least to some extent, thanks to inz, but
> >> dpkg is a bit more tricky.
> >> It'd probably take around a week or two to implement.
> >
> >What do you need from dpkg?
> 
> SB2 needs to know what kind of path mappings dpkg needs to work
> correctly. Currently it fails to install packages. I can't remember
> the exact details at the moment. As Riku suggested, it might be best
> to run apt and dpkg in target emulation mode entirely. That would be a
> bit slower but it would be trivial to get to work and would be
> guaranteed to do the right thing always.

Ah right, I agree with Riku. Also only in dpkg 1.14.0 (svn's trunk) the
remaning perl programs got --admindir support, which might still not
be enough to be able to do cross-installations (which would probably
be the cleanest way to support sb2 in a generic way, and not with
specific hacks), as there's still things not handled properly like
maintainer scripts not inheriting the admindir or similar. Although
proper chrooting might be less troublesome.

regards,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Sponsoring Maemo packages into Debian

[Guillem Jover]

Hi,

Now that the maemo-gtk and hildon situation is in a way better shape
(thanks to the great efforts of the desktop team, which have reduced
the gtk delta between maemo and upstream), I'd like to offer package
sponsoring for the core of the libraries (for now) into debian.

So, my conditions:

 * might have time to mentor.
 * the sponsoring will be strict (maybe a bit more than my usual
   sponsoring standards).
 * no interest in anything that might go outside main.
 * no interest in actual maintainership.

And of course anything uploaded to debian will end up eventually being
in ubuntu, even if it might not get the same support.

My hope is that this, combined with the debian armel port might reduce
the massive forking proliferation that can be seen in maemo right now,
and also make maemo more neutral.

regards,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: sb2 wishlist

[Guillem Jover]

[ For dpkg related stuff please use my debian address, with which I'm
  not subscribed here...  ]

On Thu, 2007-04-12 at 03:06:11 +0300, ext Lauri Leukkunen wrote:
> It would be nice if Nokia or some other entity with money or available
> resources would sponsor or provide these items for SB2:
> 
> - apt and dpkg support
>  - these seem to be quite critical for Maemo usage

> Support for apt is there, at least to some extent, thanks to inz, but
> dpkg is a bit more tricky.
> It'd probably take around a week or two to implement.

What do you need from dpkg? This probably should be moved to
[EMAIL PROTECTED] Also take into account that most probably Debian is
going to switch to multiarch for lenny, which would make it way easier
to cross-compile and similar stuff, and might make part of the sbox
functionallity unneeded (not all of course!).

regards,
guillem
___
maemo-developers mailing list
[EMAIL PROTECTED]
https://maemo.org/mailman/listinfo/maemo-developers

Re: Asking about running an executable on the device

[Guillem Jover]

Hi,

On Fri, 2007-03-23 at 14:38:59 +0100, ext magda chelly wrote:
> So, I developed a simple helloworld on scratchbox, and
> when I copied it to the device it doesn't show this
> file!! Had I to install special things on the N800 to
> make that work?

Please take a loot at this:

  

thanks,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: SBOX_CPU=arm, not armel?

[Guillem Jover]

Hi,

On Mon, 2007-03-19 at 22:48:07 +0100, ext Patrick Ohly wrote:
> My problem is that after setting up a new ARM target via sb-menu and
> selecting it, "uname -a" says that my architecture is "arm", not
> "armel". "arm" is also the value of
> SBOX_UNAME_MACHINE/SBOX_DPKG_INST_ARCH in my environment and the setting
> of SBOX_CPU in the target's .config file.

There's no such cpu as armel, so uname, SBOX_CPU and SBOX_UNAME_MACHINE
are correct being arm, SBOX_DPKG_INST_ARCH being the Debian architecture
name is wrong, it should be armel (which is just a symbolic name,
encoding the cpu+abi+kernel).

> How does scratchbox determine which flavor of ARM I want to emulate?
> Where do I need to look for an installation mistake?

The target Debian architecture should get determined using the toolchain.
Did you install an EABI toolchain?

> When I create a target and install the "cputrans" devkit, then I can
> select multiple versions of qemu-arm, including versions 0.7.0, 0.8.0,
> and arm-0.8.1-sb2 and armeb-0.8.1-sb2. Which one is the right one, if
> any?

Take the -mN if there's any.

regards,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: dpkg: serious warning: files list .......

[Guillem Jover]

On Mon, 2007-02-19 at 21:37:58 +0200, ext Guillem Jover wrote:
> On Sun, 2007-02-18 at 21:18:34 +0100, ext Visti Andresen wrote:
> > Hi, I succeeded in building my first .deb package.
> > I created the control file and friends manually, I looked at the
> > source of maemopadplus for "inspiration".
> 
> I still wonder why the tutorials lead people to build packages by
> hand...

Hmm, what Visti meant with creating the files manually is different
than the package being built by hand (as in ar + tar + cp, etc ;).
But I still think there's some tutorial around pointing people to
use the latter.

regards,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: dpkg: serious warning: files list .......

[Guillem Jover]

On Mon, 2007-02-19 at 19:15:31 +0100, ext Visti Andresen wrote:
> On Mon, 19 Feb 2007 19:04:34 +0200 Marius Gedminas wrote:
> > On Sun, Feb 18, 2007 at 09:18:34PM +0100, Visti Andresen wrote:
> > > "dpkg-buildpackage -rfakeroot" creates a debian/files file containing:
> > > n770-fire_1.2_armel.deb user/games optional
> >
> > That's not good either.
>
> Any idea what this file should contain?
> And how make it contain the proper content, as it seem to be auto
> generated.

No, that file is fine.

> > > I was wondering if anyone knows which newbie mistake I made?
> > 
> > We can't tell without looking at your source code (especially the
> > debian/ directory).
> 
> Ups probably should have written this yesterday: 
> Sources are available though "svn checkout 
> https://garage.maemo.org/svn/n770demos";
> 
> The debian directory is located under packages/fire/

There's several problems with your package:

* Do not hardcode the Depends for shared libraries, use a substvar.
* Why are you using a Pre-Depends?

* You should move the contents of the binary target to binary-arch, and
  make binary depend on binary-arch and binary-indep.
* You could use a n770-fire.install file istead of the install calls in
  debian/rules.

* This package will not build when provided as a source package as it's
  not self contained, you are ascending two dirs up the hierarchy,
  outside of what's provided in it.

regards,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: dpkg: serious warning: files list .......

[Guillem Jover]

On Sun, 2007-02-18 at 21:18:34 +0100, ext Visti Andresen wrote:
> Hi, I succeeded in building my first .deb package.
> I created the control file and friends manually, I looked at the
> source of maemopadplus for "inspiration".

I still wonder why the tutorials lead people to build packages by
hand...

> Using the "Application manager" the package installs and uninstalls
> without any problems.

You probably have those messages as well if you ask for the output
log.

> But when I use dpkg I get the following message:
> 
> dpkg -i n770-fire_0.1_armel.deb 
> Selecting previously deselected package n770-fire.
> (Reading database ... 
> dpkg: serious warning: files list file for package `armel' missing,
> assuming package has no files currently installed.
> 12900 files and directories currently installed.)

This is saying that there's an installed package called «armel» which
does not have the corresponding «/var/lib/dpkg/info/armel.list» file.
So you got such package installed somehow and dpkg is complaining.

> Unpacking n770-fire (from n770-fire_0.1_armel.deb) ...
> Setting up n770-fire (0.1) ...

And the warning message should be unrelated to this package.

> "dpkg-buildpackage -rfakeroot" creates a debian/files file containing:
> n770-fire_1.2_armel.deb user/games optional

This file does not have anything to do with the one dpkg is
complaining about, the former being binary package related the latter
being source package related.

regards,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Re: [maemo-users] 'Locking down' software installation

[Guillem Jover]

On Thu, 2007-02-15 at 14:02:19 -0600, ext Levi Bard wrote:
> > Not exactly: we do not only want to control which individual packages
> > you can install, but also which combinations.  Say there is a new
> > version of cairo, but we figure out that we also need to upgrade the
> > internet radio applet since it had a bug that--by chance--wasn't
> > triggered by the old version of cairo.  So we want to only support the
> > new cairo together with the new radio applet.
> >
> > With a version locked meta package, we can make sure that the user
> > gets the right combinations of packages.
> 
> Wouldn't you just use standard dependencies for this?  Make the new
> radio applet depend on the new cairo?

That does not help when you pull the new cairo but not the radio
applet, but in this case a Conflicts from cairo against the broken radio
applet version or lower would.

regards,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Re: GLIBC_2.4

[Guillem Jover]

Hi,

On Wed, 2007-01-31 at 10:27:33 -0500, Amy Sockanathan wrote:
> On 1/30/07, Amy Sockanathan wrote:
> > I am having a problem where it says "GLIBC_2.4" not defined and I saw
> > that the scratchbox compilers in maemo are 2.3.6 and I need 2.4. Is
> > there anyway to upgrade libc. Any help is much appreciated.

Given the lack of more detail I'll assume that with GLIBC_2.4 your error
is referring to a versioned symbol. If so, glibc should be providing that
already.

> Can someone please let me know how I cna upgrade libc in the maemo
> scratchbox from 2.3.6 to 2.4. This is a road-block for me.

,
[sbox-armel: ~] > objdump -p /lib/libc.so.6 | sed -ne '/^Version/,/^priv/p'
Version definitions:
1 0x01 0x0865f4e6 libc.so.6
2 0x00 0x0d696914 GLIBC_2.4
3 0x00 0x0963cf85 GLIBC_PRIVATE
GLIBC_2.4

Version References:
  required from ld-linux.so.3:
0x0963cf85 0x00 05 GLIBC_PRIVATE
0x0d696914 0x00 04 GLIBC_2.4
private flags = 402: [Version4 EABI] [has entry point]
[sbox-armel: ~] >
`

Without more information it's difficult to help you, please provide the
complete error message.

regards,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Unified/Umbrella garage project for direct ports

[Guillem Jover]

On Tue, 2007-01-30 at 01:45:50 +0200, ext Kemal Hadimli wrote:
> There are a lot of userspace utilities or system libraries that work
> on maemo without requiring any special/custom "porting", and are just
> direct scratchbox compiles of debian packages. These libraries/utils
> are currently distributed across custom repositories. Moving these
> over to the maemo garage would result in countless project entries
> which are rarely updated.

And a waste of time and resources.

> The idea is to create an "umbrella project" and add maintainers of
> various packages as developers to this project, so they can publish
> files. They will all have garage repository access and will maintain
> directly-ported packages like simple command line utils, small
> libraries, etc. The aim is to make these packages accessible in a
> single repository. (which is the maemo extras repo)

I think this "umbrella project" and the proliferation of all those
independent repositories are making the fragmentation of the armel
port bigger, and a massive duplication of work. The proper thing to
do would be to direct all those efforts in getting a working Debian
armel port running, and just pull from there, as was done before the
move to EABI.

  

> So, comments? Do you have a few utils/libraries compiled for maemo in
> your personal homepage/repository? Would you be interested in
> maintaining some of these packages in this umbrella project? What do
> you think?

As noted above, it would be slightly better than the current status,
but bad compared to just using the Debian port.

regards,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] extras repository

[Guillem Jover]

On Mon, 2006-11-27 at 20:12:24 +0200, ext Marius Gedminas wrote:
> Would it be possible to do it somewhat like the way Debian/Ubuntu does it:

>   1. Maintainers upload Debian source packages.

In Debian maintaiers upload source and at least binaries for one
arch:any or arch:all. In Ubuntu it's source only uploads.

>   2. Autobuilders build binary packages for each repository and send
>  emails to maintainers if there are errors.

The buildd does not send any mail, that's the job of the buildd
admin, which checks the logs and files appropriate bug reports, or
requeues the build if it was a transient failiure, or sets Dep-Waits
etc...

> Even if there are no autobuilders I would still want to enforce the
> requirement for having proper Debian source packages for everything that
> is distributed from Garage.

That'd be good, yes.

regards,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] libosso svn up-to-date?

[Guillem Jover]

On Wed, 2006-10-04 at 14:36:24 +0300, ext Kimmo Hämäläinen wrote:
> On Wed, 2006-10-04 at 14:04, ext Murray Cumming wrote:
> > On Wed, 2006-10-04 at 13:45 +0300, Kimmo Hämäläinen wrote:
> > > Yes, it does not tell the reasons for the changes (they are in
> > > debian/changelog), but I'm too lazy to put those since you seem to be
> > > the only one who is interested about Libosso changes ;)

I consider those two serve different purposes, ChangeLog (as in upstream)
explains in detail up to the function and variable level what has been
changed. And debian/changelog describes the packaging changes, and a
summary of upstream changes if it's native package.

> > At the moment, nobody (me included) knows what on earth libosso is. The
> > README is empty, for instance.
>
> It's there just because automake complains otherwise.

That's because automake defaults to gnu strictness, if you are not
following the GCS[0] you probably want:

AM_INIT_AUTOMAKE([foreign])

> 98% of Debian packages the README file is totally useless anyway.

On this one I disagree, if you have specific examples, please tell me
or file bug reports.

> > ChangeLogs are one way to introduce people to what a module does and how
> > it works, and how it is evolving. Not doing ChangeLogs because nobody
> > cares about them would be almost a circular argument.

[ This snipped reordered ]
> The code and API should be pretty self-explaining (yes, they're not,
> that's why I'm working on new API).

> Well, just try to use the diff. The code is so simple that manually
> writing some ChangeLog just seems stupid to me.

It's not about the code being simple, it's about having an offline
history of what has been changed and how the code evolved. That's
pretty useful when tracking down bugs for example.


[0] 

regards,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Reply to of this list is not maemo-developers@maemo.org

[Guillem Jover]

On Tue, 2006-10-03 at 23:41:39 +0200, ext koos vriezen wrote:
> I keep forgetting the reply-to-all of my mailer for lists that don't
> set the ReplyTo or From to the list itself. Is that intentional (or
> otherwise can that be changed)?

Consider for example:

  

regards,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Problems packaging a shared library

[Guillem Jover]

On Sun, 2006-10-01 at 21:06:05 +0300, ext Teemu Harju wrote:
> I'm struggling trying to make a .deb package out of libupnp
> (http://sourceforge.net/projects/upnp/). It compiles nicely in the
> scratchbox ARM target, but when I try to make a package out of it with
> dpkg-buildpackage the package contains basically only the directories.

Have you checked ?

> Here's what I've done...
> 
> 1) run dh_make and select the library option
> 2) edit the debian/control file
> 3) run dpkg-buildpackage -rfakeroot

> The debian/tmp directory then contains the compiled library and dev
> files, but the created .deb package does not contain those.

You'd have to use "dh_install --sourcedir=$(CURDIR)/debian/tmp" and
add a proper .install file.

> Is there something I'm doing wrong? libupnp installs nicely with
> "./configure --prefix=/usr && make && make install" so I think that,
> e.g., the debian/rules file wouldn't need anything special. Am I
> right?

Also I suppose you have DESTDIR already on make install.

regards,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Re: [maemo-users] Flash to 2006 trouble

[Guillem Jover]

On Tue, 2006-09-19 at 15:20:10 +0300, ext Eero Tamminen wrote:
> Usually it seems to say "Incompatible package" if the package
> "Section" is something else than "user".  Those packages you
> can install from the command line with "dpkg -i".
>
> You can kludge around this by extracting the package contents:
>   ar x package.deb
> Editing the control file Section field and repackaging the file:
>   ar c package.deb control.tar.gz data.tar.gz debian-binary

ITYM
ar rcu package.deb debian-binary control.tar.gz data.tar.gz

regards,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] kernel code

[Guillem Jover]

On Sun, 2006-09-03 at 09:55:52 +0200, ext Koen Kooi wrote:
> Kalle Vahlman schreef:
> > The version in IT2006 is
> > 
> > http://repository.maemo.org/pool/mistral/non-free/k/kernel-source-2.6.16/
> 
> Non-free !?!?

Right, could someone (Ferenc, Devesh?) please check and fix the contents
of that repo? There's other packages which seem wrongly placed, like
attr, bzip2, build-essential, etc.

thanks,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Re: Tinymail using mmap() gets killed by the kernel of the device

[Guillem Jover]

On Sun, 2006-07-16 at 14:52:41 +0300, ext Tomi Ollila wrote:
> Also, maybe better (or worse!) is (char *)(((int)address + 3) & ~3),
> assumed that sizeof (char *) == sizeof (int).

> This latter version seems to compile...

And runs... on this architecture, but not on others. ;)
If you have to use something like this, use intptr_t instead of int.

regards,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] maemo/debian packaging tutorial (Helsinki, June 16. or 19.)

[Guillem Jover]

Hey Marius,

On Wed, 2006-06-07 at 13:03:35 +0300, ext Marius Vollmer wrote:
> Jussi Kukkonen <[EMAIL PROTECTED]> writes:
> > (any Nokia packaging people reading this may also volunteer now ;)
> 
> I could attend Lars' tutorial, to correct my own cowboy approach to
> Debian packaging and just be there to answer all maemo specific
> questions.

You could start by dropping debmake, which is considered obsolete and
is going to be removed soon from Debian. =)

regards,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Identifiers instead of English strings

[Guillem Jover]

Hi,

On Fri, Feb 17, 2006 at 03:25:48PM +0200, ext Kalle Vahlman wrote:
> On 2/17/06, David D. Hagood <[EMAIL PROTECTED]> wrote:
> > Murray Cumming wrote:
> > > Is there some explanation somewhere about the use of these strange
> > > identifiers instead of English strings in the maemo source code. What is
> > > the advantage?

> > Internationalization (I18N) - the strings are kept in a set of  separate
> > files, one for each language. The code then accesses that file to get
> > the string. Thus, you create a new file, and suddenly your app speaks
> > Spanish.

> AFAIK the id's are there for few reasons, one being that any
> mistypings or phrase changes in the original version won't mean a
> change for all the translations already done. This would be bad if
> there's 10 translations, all handled by different people (as I'm sure
> open source translators know ;).

If you use gettext properly, and have a typo in an original
(non-logical) string, you can fix the string, regenerate the pot file,
merge it with all po files and un-fuzzy the ones that were not fuzzy
previously due to this change. Thus no change in translations, and if
the translation was already fuzzy it needed updating anyway.

If the actual meaning of the string changed, then obviusly you want
the translations to reflect that.

> Also the code side benefits as you can quickly add a string called
> "this_app_warns_about_this" instead of waiting for the real and
> perfect sentence to be thought up, since it can be done after the code
> is already done (without changes to it).

I don't see a benefit with that. Also it has some severe problems:

Compiler checks - a wrongly specified format string or a missing
argument may produce a build time warning in normal situations, bogus
data or even a runtime crash with logical strings.

 - Logical: Bogus warnings + Runtime crash

   printf(_("foo_bar"), 45000, 'c');

   msgid "foo_bar"
   msgstr "value %ld with string %s and %s.\n"

 - English: Proper build time warnings

   printf(_("value %ld with string %s and %s.\n"), 45, 'c');

   $ gcc -Wall -o foo foo.c
   foo.c:6: warning: format '%ld' expects type 'long int', but argument 2 has t
   foo.c:6: warning: format '%s' expects type 'char *', but argument 3 has type
   foo.c:6: warning: too few arguments for format

Translation consistency checks - some of those can be performed
automatically if using the po tools with normal strings.

 - Logical: No warnings nor errors

   # Master English
   msgid "foo_bar"
   msgstr "this is an integer %d.\n"

   # Translation to Catalan
   msgid "foo_bar"
   msgstr "això és un enter %f %s."

 - English: Fatal errors

   #, c-format
   msgid "this is an integer %d.\n"
   msgstr "això és un enter %f %s."

   $ msgfmt -c foo.po
   foo.po:14: number of format specifications in 'msgid' and 'msgstr' does not
   foo.po:17: `msgid' and `msgstr' entries do not both end with '\n'
   msgfmt: found 2 fatal errors

Fuzzy handling - changes to the original english string do not trigger
changes to the translations. Also translations marked "fuzzy" are not
displayed to the user as they are obviously wrong and not matching the
meaning of the current original text.

 - Logical:

   printf(_("foo_bar"), 4, "baz");

   # Master English
   msgid "foo_bar"
   msgstr "This is a string"

   - We fix a typo.

   msgid "foo_bar"
   msgstr "This is a string."

   - Translations do not get noticed. Manual review needed.

   # Translation to Catalan
   msgid "foo_bar"
   msgstr "Això és una cadena de text"

 - English:

   printf(_("This is a string"), 4, "baz");

   msgid "This is a string"
   msgstr "Això és una cadena de text"

   - We fix a typo. The translation gets "fuzzy".

   #, fuzzy
   msgid "This is a string."
   msgstr "Això és una cadena de text"

   - We fix the translations. No "fuzzy" anymore.

   msgid "This is a string."
   msgstr "Això és una cadena de text."

And some less severe ones:

Losing the ability to get repeated translations of the same strings
merged into the same string.

Losing the ability to do incremental translations. It's everything or
nothing, as logical strings are meaningless to the user and thus like
not having anything.

regards,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Shared Libs and Application Installer

[Guillem Jover]

Hi,

On Thu, Dec 22, 2005 at 12:24:27PM -0200, ext Gustavo Sverzut Barbieri wrote:
> On 12/22/05, Eduardo de Barros Lima <[EMAIL PROTECTED]> wrote:
> > A solution for this case would be create a separeted package for
> > libglade, but i think if we have to do this job for each and every lib
> > on the system, the application installer loses its meaning. An
> > alternative was to link the library statically, but as we take so much
> > care our free space, it would be a waste of it. I see libglade is
> > included in the SDK image, but it is not in the product image, so I
> > think the better solution is to include it in the newer versions.  Any
> > comments?

In the future a proper solution would be to have a real application
installer.

> That's in my list of "things to fix", together with installation on
> MMC and enable users to share applications peer-to-peer (like Palm
> users can "beam" each other).

> I need to implement my ideas and see how they fit into dpkg, probably
> they don't, but the scracth is like this:

> You can install applications and they know their dependencies. When
> you talk to the "server" (it can be an app server or other maemo user)
> you'll get the list of dependencies, you'll reply with dependencies
> you don't have, then together with the App, you'll get the
> dependencies... transparent to user. Probably you will not distribute
> an "abiword.deb" on your website but and "abiword.app", that will have
> "abiword.deb" and "libglade.deb". If you already have libglade.deb, it
> will not install it, just abiword.deb. This is a _scratch_, I'll write
> some wiki pages on it before implementing.

I don't see the point in all that complication, if you want to
distribute a .deb from your web page, the proper Debian way is through
a repo, and creating a simple one is quite easy. =)

In the case of the user, then we would only need a nice app that would
make easy the process of creating a local repo.

> This is also related to other feature I want: to beam apps between
> users. This system will need to "reconstruct" packages from installed
> files, with safety to configuration files and also remember need
> (pre/post) scripts.

If you'd like to do this, you may want to check dpkg-repack. It will
only work if you have the dpkg status files on the system. Although
ideally you'd want the original .deb from a trustworthy/original repo.

regards,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

[maemo-developers] maemo-launcher moved to the stage repo

[Guillem Jover]

Hi there,

I've moved today maemo-launcher to the stage repo. It's a hack we are
using in the 770 to make application startup time faster, and to be
able to share memory between applications.

The source can be found here:

  

For the technical details you can read the README, or the source. :)

regards,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] ipkg vs dpkg

[Guillem Jover]

Hi,

On Fri, Nov 25, 2005 at 08:46:23PM -0500, ext Russell Nelson wrote:
> Instead of tossing out opinions, let's look at some numbers.

> I have Debian 2.2 on a server and Familiar 6.2 on a handheld.  Since
> we're talking about using either dpkg or ipkg on a jffs2 filesystem,
> all space consumption is given as so:

> packagessize  bytes/package
> ipkg total  378K
>  available939   317K  388
>  installed14761K  415
> dpkg total10620K
>  available  15272  8660K  567
>  installed301  1860K 6180

You are comparing different things, pkg managment tool and the repostitory
used with its contained data.

The interesting data here is the bytes per package, and that will
increase with later Debian releases as they include tag information,
but nothing prevents the repos provided by maemo to be stripped down,
for example removing the long description and keeping the short one
(as Familiar is doing).

regards,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] The future of the Application installer

[Guillem Jover]

On Mon, Nov 07, 2005 at 02:15:06PM +, ext Tomas Frydrych wrote:
> The big issue is the screen realestate: even in the File Manager it is 
> difficult to get to your files in a folder if  you have more than 3 or 4 
> in there. The same goes for the installer: I am not sure what kind of UI 
> would make it possible to trace a large number of dependencies without 
> it being major pain, which is why I actually quite like the applet only 
> keeping track of applications, not the system. If you want the installer 
> to be fullblown dpkg frontend, there should be a 'normal user mode', 
> that would be similar to how the intaller works just now, and some kind 
> of an 'experienced user mode', and make the 'normal user' mode the default.

That's pretty easy to filter, given that debtags is being integrated in the
main package installer frontends (like aptitude in sid).

  

> Synaptic-like view of the system can be overwhelming even on a big 
> screen with mouse and keyboard -- whatever you do, design it first of 
> all to work for the ordinary user; just because the hackers find it not 
> powerful enough does not mean it is bad.

There used to be a debtags enabled synaptic, don't know of the current
state though.

regards,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers