Comment 1 Marcell Lengyel 2010-06-01 11:05:38 UTC

Vesku, could you check this?

Comment 2 Marcell Lengyel 2010-06-02 09:55:28 UTC

The missing packages are now in the SDK repo.

The problem persists. See
https://garage.maemo.org/builder/fremantle/glob2_0.9.4.4-1maemo1/armel.root.log.FAILED.txt

Comment 4 Vesa-Matti Laitinen 2010-06-03 08:56:07 UTC

Works like a charm on my computer. I installed fresh and clean SDK from public
repository.

More info is needed if your problem remains.

Could you be more specific about what info do you need?
You have the whole autobuilder log.

It works fine on my local PC too, but not on autobuilder.

Comment 6 Vesa-Matti Laitinen 2010-06-03 10:18:04 UTC

Your installer is old:
> [2010-06-03 02:26:05] Extracting rootstrap /scratchbox/packages/maemo-sdk-rootstrap_5.0_10.2010.09-3_armel.tgz

Latest rootstrap is 10.2010.19-1

Comment 7 Marcell Lengyel 2010-06-03 11:20:58 UTC

Looks like an autobuilder issue. Reassigning.

Comment 8 Niels Breet 2010-06-03 15:16:53 UTC

Rootstrap and updated sdk installed on builder.

A note: this resolution causes non-installable packages because the
libsdl-ttf2.0 binary package is available on SDK repo only.

There's an alternate libsdl-ttf2.0 package on -devel, but it is discarded by
autobuilder because "osso" > "maemo" as per dpkg version sorting rules.

I suggest that we either upload the SDK binary as-is to a device repo, or just
create an extra libsdl-ttf2.0 package with an artificially bumped version
number.

I can only do the second, is that OK with everybody?

I think this problem should be reported to Nokia for fixing their repos.

Comment 11 Niels Breet 2010-07-12 17:50:18 UTC

I pinged the SDK team about this. It is being looked at, will report back when
I know more.

Comment 12 Marcell Lengyel 2010-07-16 12:14:09 UTC

libsdl-ttf2.0 is in the applications repository now.

The SDK binary package is named "libsdl-ttf2.0" while the previously existing,
and Debian ones are named "libsdl-ttf2.0-0", and of course they conflict :( .

I think the problem wasn't solved (or better: a new problem was created!):
http://talk.maemo.org/showthread.php?t=59553
http://talk.maemo.org/showthread.php?p=772873
http://talk.maemo.org/showpost.php?p=771781&postcount=56

Ok, could SDK repo maintainer change libsdl-ttf2.0 source package so that its
binary package name is "libsdl-ttf2.0-0" (as Debian and the older extras-devel
package do), and trigger a rebuild of all SDK repo packages?

Otherwise we have to rebuild all extras and -devel "libsdl-ttf2.0-0"-depending
packages, and I'm not a fan of that specially considering Debian uses
"libsdl-ttf2.0-0".

(In reply to comment #15)
> Ok, could SDK repo maintainer change libsdl-ttf2.0 source package so that its
> binary package name is "libsdl-ttf2.0-0" (as Debian and the older extras-devel
> package do), and trigger a rebuild of all SDK repo packages?
> 
> Otherwise we have to rebuild all extras and -devel "libsdl-ttf2.0-0"-depending
> packages, and I'm not a fan of that specially considering Debian uses
> "libsdl-ttf2.0-0". 
> 

I've already uploaded to extras-devel a new version of libsdl-ttf2.0-0 [1]
which is only a transitional package to libsdl-ttf2.0; in other words, the
former package only pulls the latter as dependency and do nothing else. This
should allow packages that depend on either version to work, as both packages
are based on the same Debian revision (2.0.9-1).

[1]
https://garage.maemo.org/pipermail/pymaemo-developers/2010-August/001506.html

Thanks, problem solved :)

Comment 18 Marcell Lengyel 2010-08-03 10:05:46 UTC

Closing based on comment #17

Comment 19 Attila Csipa 2010-08-16 14:54:04 UTC

I'm having an issue with this solution in cases an application has already
installed an older version on libsdl-ttf2.0-0. Example:

http://pastebin.com/7FGcFMph

(old version installed by apps in Extras stable, like fheroes2, enigma,
brainparty, etc)

Wouldn't a "Provides:/Replaces:/Conflicts:" clause on the Nokia-repo-stored
package, and removal of libsdl-ttf-2.0-0 from Extras altogether, help ?

HAM never removes any packages, so "Replaces:" solution does not work with HAM.

Comment 21 Attila Csipa 2010-08-16 15:14:42 UTC

As per the Debian policy, Replaces: is also used to allow one package to
overwrite parts of other packages, which is, from what I gather, exactly what
is needed here (so the 'new' libsdl-ttf2.0 could, when installed, overwrite
files from an un-upgraded libsdl-ttf2.0-0).

Comment 22 Eero Tamminen 2010-09-14 11:58:36 UTC

Policy states that packages should follow Debian package names (for obvious
reasons[1]).

So the correct solution is to:

* Update libsdl-ttf2.0-0 to Conflict/Replace/Provide libsdl-ttf2.0.
  This is urgent as without this user can half-install conflicting packages
  and needs to repair device state manually from the command line (remove
  packages containing overlapping files + all dependent packages).

* Purge libsdl-ttf2.0 from the repositories
  (also internal Nokia ones)

* And eventually change packages depending on libsdl-ttf2.0 to
  correctly depend on libsdl-ttf2.0-0
  (for example "python-pygame" and "xresponse-visualize")


[1] For example there are a lot more Debian ported games depending on the
Debian package than stuff depending on the incorrect package:
http://maemo.org/packages/package_instance/view/diablo_extras_free_armel/libsdl-ttf2.0-0/2.0.9-1/

(In reply to comment #22)

> * Update libsdl-ttf2.0-0 to Conflict/Replace/Provide libsdl-ttf2.0.
>   This is urgent as without this user can half-install conflicting packages
>   and needs to repair device state manually from the command line (remove
>   packages containing overlapping files + all dependent packages).

We can do this change, which is essentially revert what was done on comment #16
and add the Conflicts/Replaces/Provide keywords. Is that OK?

Comment 24 Eero Tamminen 2010-09-15 12:15:40 UTC

(In reply to comment #23)
> We can do this change, which is essentially revert what was done on
> comment #16 and add the Conflicts/Replaces/Provide keywords. Is that OK?

As there seem to be so few packages (I found only two) depending on the
incorrectly named package, I think it makes sense to do this the correct way
which involves also fixing the wrong package dependencies.

The wrongly built Python package is here:
http://maemo.org/packages/package_instance/view/fremantle_extras-devel_free_armel/python-pygame/1.9.1release-0maemo1/

The previous, blocked version was correct:
http://maemo.org/packages/package_instance/view/fremantle_extras-devel_free_armel/python-pygame/1.8.1release-0maemo3/

xresponse-visualize from the SDK tools repo is a debugging tool that doesn't
even need to be installed to the device, it can as well be used from x86 Sbox
to view the xresponse logs from the device.

Comment 25 Marcell Lengyel 2010-09-15 12:59:49 UTC

It will be fixed in the next Fremantle release in a similar way what Eero
suggested in comment #22, but the other way round. Since the internal Fremantle
repositories have libsdl-ttf2.0, that is going to be the "good" package and
that one will Provide: Conflict: and Replace libsdl-ttf2.0-0.

Comment 26 Attila Csipa 2010-09-15 13:43:51 UTC

I don't know the original background why the package was renamed in the first
place, all things equal I would like to stick with the same package names as
Debian does, but of course if there is a GOOD reason to change it...

Comment 27 Eero Tamminen 2010-09-15 13:50:15 UTC

(In reply to comment #25)
> It will be fixed in the next Fremantle release in a similar way what Eero
> suggested in comment #22, but the other way round. Since the internal Fremantle
> repositories have libsdl-ttf2.0, that is going to be the "good" package and
> that one will Provide: Conflict: and Replace libsdl-ttf2.0-0.

The internal repo should be fixed, we're violating the policy about following
Debian package naming.

It needs only removing the broken package, taking the correct package from
Debian (as we don't seem to have any patches to the brokenly named package),
and rebuilding the package(s) depending on it.  No change is needed to any of
these packages because the name of the -dev package doesn't change and
dependencies are generated automatically based on what the packages link
against.

A slight question: what to do _right_ now? Ideally we shouldn't block all
libsdl-ttf depending packages from Extras until next firmware+SDK update (which
might never come to be).

Can we filter the SDK -dev package from being used by the autobuilder, for
example?


As for my packages (mupen64plus, ...): via hacky manipulation of the generated
control files right from debian/rules I can build packages that end up
depending on the pre-existing libsdl-ttf2.0-0, thus should be able to pass
-testing without a problem, and be installed on "pure extras -stable" users
without a single warning from HAM.

This supposedly shouldn't break users who have upgraded to the invalidly named
one; HAM should be able to pull the transitional package for them.

Comment 29 Attila Csipa 2010-09-30 10:39:11 UTC

(In reply to comment #28)
> A slight question: what to do _right_ now? Ideally we shouldn't block all
> libsdl-ttf depending packages from Extras until next firmware+SDK update (which
> might never come to be).
> 
> Can we filter the SDK -dev package from being used by the autobuilder, for
> example?

Things are moving along, maybe not as fast as we would like to, but the issue
is far from forgotten. Also, trickery as above would have to wait a bit anyway
as Niels is away ATM.

Comment 30 Eero Tamminen 2010-09-30 14:17:27 UTC

(In reply to comment #28)
> A slight question: what to do _right_ now?

I think the proposal in comment 16 is fine for Fremantle.

This should be properly fixed for Harmattan though (comment 22).
-> separate bug?


> Ideally we shouldn't block all
> libsdl-ttf depending packages from Extras until next firmware+SDK update 
> (which might never come to be).

Next PR release is definitely coming and close now.

As a newbie I don't know if this is a related bug, but I believe I may be a
victim to the situation mentioned in comment #19. I have two of those packages
installed since way back (fheroes2, brainparty), and now I can no longer
install any packages at all as dpkg breaks on trying to install libsdl-ttf2.0.
I have tried 'apt-get -f install' but it breaks the same way every time. [1]

Based on 'dpkg --configure --pending' the dependency was caused by shariks,
tar-gnu or filebox.

I run Maemo 5, version 10.2010.19-1. 

[1] Output from 'apt-get -f install' http://pastebin.com/GvtHNhCi

Comment 32 Eero Tamminen 2010-10-25 14:38:07 UTC

(In reply to comment #31)
> As a newbie I don't know if this is a related bug, but I believe I may be a
> victim to the situation mentioned in comment #19. I have two of those packages
> installed since way back (fheroes2, brainparty), and now I can no longer
> install any packages at all as dpkg breaks on trying to install libsdl-ttf2.0.
> I have tried 'apt-get -f install' but it breaks the same way every time. [1]

I think installing the package from comment 16 should fix the issue.

If not, I guess you need to ask apt to remove both of the libsdl-ttf* packages
and everything else it complains about.

So...

It seems that with PR1.3 "libsdl-ttf2.0" is becoming the default (sigh).