Re: Broken packages in Extras repository
On 04.09.10 16:06, Mikko Vartiainen wrote: > There are some broken packages in Extras repository which which are > preventing some applications from working. > Then there is python-numpy, which seems to be completely unfunctional. > "import numpy" fails after installing it. After installing mypaint numpy > seems to work, so python-numpy has broken dependencies. its dependencies libblas3gf and liblapack3gf were broken (due to a bug in fort77). There is a workaround in mypaint. The latest versions in testing should be fine. -- Thomas Tanner -- email: tan...@gmx.de GnuPG: 1024/5924D4DD ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
On 24.02.10 18:04, Graham Cobb wrote: > Why do I think many people will not upgrade? This device is a phone. The N900 is a mobile computer. If you want to use it as a phone, i.e. without applications from extras or Ovi, then there is no need to upgrade the firmware. If you want to use it as a computer by installing applications, you should upgrade your OS, especially to get security updates for a Internet-centric device. Maintaining software and working around bugs for every minor release is a nightmare. Only for different major releases and devices it is justified. -- Thomas Tanner -- email: tan...@gmx.de GnuPG: 1024/5924D4DD ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
On 24.02.10 15:18, Attila Csipa wrote: > On Wednesday 24 February 2010 13:20:40 Thomas Tanner wrote: >> Why would anybody not upgrade the firmware? >> Why is backwards compatibility necessary for Fremantle minor releases? >> Enforcing the requirement could make our life so much easier. > There can be a number of reasons, ranging from various regressions (like > sticking to 42-11 because of WiFi issues in 51-1), policies (if it ain't > broken, don't fix it, not all bugs affect all people), cost/stability (I > might not want to upgrade when roaming) or simply firmware non-availability > (firmwares are not rolled out simultaneously for all countries, ask UK > folks :). Forced upgrades are usually a last-resort measure, done only if > there is a legal reason (like compliance with some regulations, maybe things > related to emergency calls, etc). Forced upgrades of some components for installation of a new package is standard practice for all package management systems (keyword version dependencies). I think the main problem is that the mp-fremantle-pr packages hardcodes the exact version of all PR packages instead of specifying the minimum version. If a user could selectively upgrade a core package without conflicting with mp-fremantle-pr they would not be forced to completely upgrade the firmware for new extras apps. (BTW, the broken dependency specification in the PR also makes it impossible to remove unnecessary language packs) In a (Debian based) distribution the proper way to handle such conflicts would be to specify the minimum required version in each extras apps (e.g. qt4.5) and to switch to a new package name if the new package is no longer backwards compatible (qt4.6). If it not possible to install both qt4.5 and qt4.6 due to space constraints the user should have the option to either deinstall old qt4.5 apps or wait until all his extras apps are upgraded 4.6. -- Thomas Tanner -- email: tan...@gmx.de GnuPG: 1024/5924D4DD ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
I don't know whether this has been discussed before: what is wrong with forcing users that have the necessary Internet access to download applications from Extras, to also upgrade to the lastest firmware, which is supposed to fix bugs anyway. Why would anybody not upgrade the firmware? Why is backwards compatibility necessary for Fremantle minor releases? Enforcing the requirement could make our life so much easier. We could have a package "maemo-extras" which enables the extras repository and which always depends on the latest firmware version. Or we could add the current firmware version to the dependencies of packages build on autobuilder. Users who don't want to upgrade would have to stick with the on-device applications. cheers On 24.02.10 12:21, Niels Breet wrote: > Maemo 5 PR1.2 seems to be a release with some large changes which are not > backwards compatible with previous releases > - 'older' devices will continue to fetch from distribution: fremantle > This will effectively mean that the 'old' Extras will not get any updates. ... > Nokia will encourage people to upgrade to the latest release as much as > possible and we expect people to switch to PR1.2 at a high rate. -- Thomas Tanner -- email: tan...@gmx.de GnuPG: 1024/5924D4DD ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N900 kernel module recompile
On 18.02.10 19:40, Nils Faerber wrote: > OK, I will try - never compiled a kernel using the debian build system :) it's almost trivial :) I suggest to take a look at my custom kernel source in extras-devel/non-free (due to non-free fiasco-gen). I have converted it to use quilt which makes integration of other community matches much easier. -- Thomas Tanner -- email: tan...@gmx.de GnuPG: 1024/5924D4DD ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N900 kernel module recompile
On 18.02.10 18:18, Nils Faerber wrote: > I would like to hack on some drivers on the N900, so I need to be able > to recompile kernel modules. Ideally I would like only to replace > modules, not the whole kernel+modules package. > > So what I did was I installed the Maemo5 SDK first in order to get the > proper toolchain. > Then I took a vanilla 2.6.28 Linux kernel archive and applied the kernel > patch from "apt-get source kernel" would be easier Do you plan to provide the extra modules as a package in extras-devel or just as individual files? You could disable building and packaging of the kernel in the debian/rules and control file and only generate a modules package. Please make sure to also rename the source package and the generate packages to avoid conflict with the stock kernel. For indidivual files just extracting the output of the first solution could be the simplest approach. -- Thomas Tanner -- email: tan...@gmx.de GnuPG: 1024/5924D4DD ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: debhelper7 doesn't find python-central
Hi Matti, I have uploaded a new version which includes the python_central.pm file from python-central. While this may look like a quick hack (which debhelper7 is anyway) I think it is cleaner than adding a symlink to the Debhelper directory or asking python-central to install the file in two directories. The file is tiny and unlikely to change, anyway. Let me know whether it works with the latest version. cheers, On 18.02.10 18:56, Matti Airas wrote: > python_central.pm is provided by the python-central package but it is > installed under Debian/Debhelper instead of the custom Debian/Debhelper7 > directory assumed by the debhelper7 package. I wonder what would be the > best approach to fix this? -- Thomas Tanner -- email: tan...@gmx.de GnuPG: 1024/5924D4DD ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
For people who are fed up being spammed with rpm vs. deb and who want to contribute to a Debian implementation of MeeGo I have started the TMO thread http://talk.maemo.org/showthread.php?t=44967 On 18.02.10 16:05, Pavel Rojtberg wrote: > And as I got more time now, here is the Brainstorm vote for DEB: > http://maemo.org/community/brainstorm/view/keep_deb_for_meego/ -- Thomas Tanner -- email: tan...@gmx.de GnuPG: 1024/5924D4DD ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
On 16.02.10 17:18, Pavel Rojtberg wrote: > actually I only care what the MeeGo version will use that is supposed to > run on future Nokia handhelds. >> Frankly, it is suicide not to switch to rpm. you mean all .deb based distributions are doomed to fail?? > I think I will start a wiki page and a brainstorm vote, for keeping DEBs > and to collect arguments pro/ contra. according to Quim http://talk.maemo.org/showthread.php?p=529073 Harmattan is going to stay DEB based, despite being the first MeeGo implementation on Nokia devices. This is IMHO good news. Now we only need to convince them to stick to it even after Harmattan... -- Thomas Tanner -- email: tan...@gmx.de GnuPG: 1024/5924D4DD ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
On 16.02.10 00:13, Marc Bantle wrote: > From what I understand from [1], the > the thing I'll miss most will be X11. > > I hope someone can disprove :-( http://meego.com/developers/hardware-enabling-process lopers -- Thomas Tanner -- email: tan...@gmx.de GnuPG: 1024/5924D4DD ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: RPM vs. Deb (was Re: MeeGo)
I have repeatedly stated this is not about the package format! It is about the infrastructure and the available software. I have no problem with commercial apps being installed as rpms (using alien). Why should we drop the efforts of the Maemo and Debian community on ARM devices? Where is the Moblin community anway? compare http://arm.koji.fedoraproject.org/packages_to_be_fixed.html with http://www.ubuntu.com/products/whatisubuntu/arm On 15.02.10 19:07, Michael Cronenworth wrote: > Thomas, you're getting all upset over nothing. The fact that RPM will > now be used is nothing more than politics. No features will be lost. No > amount of whining to this list will change what is already in motion. > > *cough* http://fedoraproject.org/wiki/Architectures/ARM *cough* > > I don't see any value in this continued discussion of RPM vs. Deb. -- Thomas Tanner -- email: tan...@gmx.de GnuPG: 1024/5924D4DD ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
On 15.02.10 17:55, Christopher Intemann wrote: > Since MeeGo is about to become the successor of Maemo, I guess there > won't be any need to backport anything. such an attitude would make lots of N900 and N8x0 owners angry... > I guess that rpm is just more advanced than deb. this is wrong, but not relevant here. The package format itself is negligible. The important point is the infrastructure it implies. According to http://www.desktoplinux.com/news/NS2068665492.html Moblin switched from Ubuntu to Fedora because "RPM offers the advantage of containing license information" (I don't whether that's the only or main reason). But .debs have the license information in their doc directory (most of them are DFSG free anyway) and it could be added as X-License field of the package description, if necessary. I don't want a platform that is merely a Qt runtime enviroment (Symbian would be sufficient) but one which also offers me easy access to the complete GNU/Linux software world. Debian based distributions have offered working ARM ports for years but Fedora does not. Porting Moblin/Fedora to ARM would be lots of duplicated effort, using Maemo/Debian on X86 or ARM is for free. On 15.02.10 17:57, Dieter Plaetinck wrote: > PS: I have no idea of moblin's size, so maybe you make a good point. I > don't know. I could only find those standard GNOME applications http://garage.moblin.org/garage/all?page=1 -- Thomas Tanner -- email: tan...@gmx.de GnuPG: 1024/5924D4DD ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
On 15.02.10 16:47, Jeremiah Foster wrote: >> The problem is more complex than converting binary .debs to .rpms >> using a hack. > alien is not a hack. the hack referes to a process ignoring the issues listed below. No automated process can take into account all the distribution and program specific quirks. >> The dependencies, the build script and Debian (ucf, debconf) or >> Maemo (maemo-optify) specific aspects of the sources would need to >> be adapted as well. Backporting to Maemo5 would also be more >> difficult. > >> Who benefits more from the merger, Moblin or Maemo? > Both benefit if we get the kind of scale that is imagined. I'm not critising the merger itself, but how and what is merged and whether that are top-down decisions or whether the community is involved. AFAIK there a hardly any Moblin specific third-party apps. It could be much less effort to integrate the Moblin components in a Debian based system than converting all Maemo apps to Moblin/RPM. -- Thomas Tanner -- email: tan...@gmx.de GnuPG: 1024/5924D4DD ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
The problem is more complex than converting binary .debs to .rpms using a hack. The dependencies, the build script and Debian (ucf, debconf) or Maemo (maemo-optify) specific aspects of the sources would need to be adapted as well. Backporting to Maemo5 would also be more difficult. Who benefits more from the merger, Moblin or Maemo? On 15.02.10 15:35, Christopher Intemann wrote: > Its not to much an issue to convert deb-packages to rpm, though. > You might want to have a look at: > http://kitenet.net/~joey/code/alien/ > I prefer rpm to deb as well. > Cheers, > Chris > > On Mon, Feb 15, 2010 at 3:24 PM, Thomas Tanner <mailto:tan...@gmx.de>> wrote: > > the problem is not the package format itself but > they available applications using the package format. > Maemo uses .deb and already has lots of applications (plus Jebba's etch > build). For Moblin, OTOH, are they any applications? > Is there any good reason to switch to .rpm except for breaking > compatibility? -- Thomas Tanner -- email: tan...@gmx.de GnuPG: 1024/5924D4DD ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
the problem is not the package format itself but they available applications using the package format. Maemo uses .deb and already has lots of applications (plus Jebba's etch build). For Moblin, OTOH, are they any applications? Is there any good reason to switch to .rpm except for breaking compatibility? On 15.02.10 14:51, Andre Klapper wrote: > Am Montag, den 15.02.2010, 14:44 +0100 schrieb Tor: >> On Mon, Feb 15, 2010 at 14:30, Daniel Martin Yerga wrote: >> >>> Meego will use .rpm: http://meego.com/about/faq >> >> This is very bad news IMO. I work a lot with both formats and I know >> which one is less painful. > > And this is a very subjective comment that misses any arguments. ;-) > > andre -- Thomas Tanner -- email: tan...@gmx.de GnuPG: 1024/5924D4DD ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Debian Etch, Rebuilt: 6,451 .debs for Maemo 5
great job, Jeff! Marius Vollmer wrote: >> * Depends: are ok? Just because the Build-Depends: were there doesn't mean >> the Depends: are there. > Yes. Would be good to compile a list of such missing Depends and maybe > put some extra effort into making them build, too. > There will be cyclic build dependencies, though, and things get > interesting then. http://collab-maint.alioth.debian.org/debtree/ could be useful for ordering the build sequence from root to leaves or for visualizing the missing dependencies. cheers, -- Thomas Tanner -- email: tan...@gmx.de GnuPG: 1024/5924D4DD ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: tiny /tmp
MyDocs is not available if the USB mass storage mode is enabled. IMHO the new tmp directory should also be under control of temp-reaper and not visible to the (average joe) user. Martin Grimme wrote: > I'd suggest to use the 32 GB flash for storing these. > /home/user/MyDocs/. > > I see there is already a tmp directory in MyDocs. Where did this come > from? Does it belong to the eMMC fs image or did some app create it? -- Thomas Tanner -- email: tan...@gmx.de GnuPG: 1024/5924D4DD ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
tiny /tmp
Hello, /tmp on the device is only about 1MB small. I have an application which sometimes needs to create tmp files which are >1MB. Whst would be best and standard directory to store such files? I guess it should be somewhere on the eMMC, e.g. /opt/tmp, /home/tmp, /home/var/tmp, /home/user/.tmp What do you think? -- Thomas Tanner -- email: tan...@gmx.de GnuPG: 1024/5924D4DD ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: up-to-date debhelper and cdbs
Marcin Juszkiewicz wrote: > Or let nokia finally pay someone to upgrade those devkits to something more > fresh? Lenny or Squeeze? it already exists for sb2 http://maemo-sdk.garage.maemo.org/ when will that become the official SDK? cheers -- Thomas Tanner -- email: tan...@gmx.de GnuPG: 1024/5924D4DD ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: up-to-date debhelper and cdbs
Markku Savela wrote: > I may be misunderstanding something, but to me it looks like the newest > versions of debhelper and cdbs are already in scratchbox /usr/bin. > > It just those pesky devkit redirections that take us to ancient versions... > > ... thus, wouldn't just disabling those redirections be sufficient? ?? not for me: cat /scratchbox/devkits/debian-etch/deb_list/debhelper Source: debhelper Version: 5.0.42 Binary: debhelper do you have a more recent version of scratchbox? cheers -- Thomas Tanner -- email: tan...@gmx.de GnuPG: 1024/5924D4DD ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: up-to-date debhelper and cdbs
The latest debhelper7 can now happily coexist with debhelper from autobuilder and SDK. The following lines in debian/rules are necessary to use it: PATH:=/usr/bin/dh7:/usr/bin:$(PATH) export PATH SBOX_REDIRECT_IGNORE=/usr/bin/perl export SBOX_REDIRECT_IGNORE cdbs would require more changes (e.g. replacing all references to /usr/share/cdbs) but maybe Jeff's trick with Build-Depends: maemo-cflags-cdbs-rules could also give you a more recent cdbs? cheers, Anderson Lizardo wrote: > Ideally, it would be nice to allow this modified debhelper7 and the > original debhelper from the devkit to coexist on the same SDK > installation (so that users interested on trying it out can easily do > so without breaking their current target). That would require some > more changes to your debhelper7 and cdbs-dh7 packages though (e.g. to > not install files at conflicting paths). > > What do you think? > -- Thomas Tanner -- email: tan...@gmx.de GnuPG: 1024/5924D4DD ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
up-to-date debhelper and cdbs
Hi,
many Debian packages require more recent versions of debhelper
or cdbs than the outdated ones installed in the scratchbox devkits
(debhelper 5.0.42 and cdbs 0.4.48, both more than 3 years old).
The newer version make packaging also much easier.
I think I have found a minimally invasive workaround how to
use the latest version of debhelper (7.4.10) and cdbs (0.4.62)
in the SDK and autobuilder (see later).
HOWTO:
In your debian/control file replace the dependencies
debhelper (>= 7) with debhelper7
cdbs (> 0.4.48) with cdbs-dh7
add the following to the beginning of your debian/rules
PATH:=/usr/bin:$(PATH)
export PATH
SBOX_REDIRECT_IGNORE:=$(shell echo /usr/bin/{perl,dh_*} | sed "s/ /:/g")
export SBOX_REDIRECT_IGNORE
In your SDK you can run
apt-get install debhelper7 cdbs-dh7
which will automatically remove the old versions,
which were overwritten by the devkits anyway.
To restore the old versions use
apt-get remove debhelper7 cdbs-dh7
apt-get install debhelper cdbs
PROBLEM:
autobuilder should automatically install these build-depends
but currently it fails with
The following packages will be REMOVED:
debhelper
The following NEW packages will be installed:
bsdmainutils bsdutils debhelper7 groff-base man-db
E: Packages need to be removed but remove is disabled.
see the buildlog of a package used for testing the workaround
https://garage.maemo.org/builder/fremantle/dpkg-repack_1.31maemo1/i386.root.log.FAILED.txt
Would it be possible to allow package removal in autobuilder?
cheers,
--
Thomas Tanner --
email: tan...@gmx.de
GnuPG: 1024/5924D4DD
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: "Donate $x" button on Packages and/or Downloads
Hi Andrea Grandi wrote: > 2010/1/22 Andrew Flegg : >> And what about packages which don't *have* an "About" box, or even a >> UI? e.g. plugins for gstreamer & Telepathy; Catorise etc.? I agree. What if someone writes a wonderful media framework for Maemo and someone else a little GUI frontend. The latter is user visible (user section), the first is not but the latter gets all the donations. > why no including both things? maemo.org/download button and > About-->Donate if the application has a gui. > It would make sense for me I think we need some integrated feedback application for: * rating packages * sending bug reports and feature request which automatically include the installed version number and the dependencies * integration with crash-reporter * showing a detailed description (incl. the dependencies) * giving quick access (opens a browser window) to - a donation button (paypal link) - screenshots or the maemo.org/downloads page - the project webpage most of the information is already in the package lists or on maemo.org. maybe those features could be simply added to the existing AppWatch or PackageRate?. Adding the donation box to the details window in Application manager would be an alternative, but IMHO the design of the Application manager is not well suited for that: you would first click uninstall to donate for an installed app!? (I prefer synaptic/aptitude/dselect style programs anyway...) just my 2ยข, -- Thomas Tanner -- email: tan...@gmx.de GnuPG: 1024/5924D4DD ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
different binaries for the same version?
Hello, I just tried to install liblzo2-2, but I got the following error (with fresh apt-get update): The following NEW packages will be installed: liblzo2-2 0 upgraded, 1 newly installed, 0 to remove and 8 not upgraded. Need to get 56,1kB of archives. After this operation, 193kB of additional disk space will be used. Get:1 http://repository.maemo.org fremantle/free liblzo2-2 2.03-1maemo3 [56,1kB] Fetched 1B in 0s (1B/s) Failed to fetch http://repository.maemo.org/extras-devel/pool/fremantle/free/l/lzo2/liblzo2-2_2.03-1maemo3_armel.deb Size mismatch E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? the package in http://repository.maemo.org/pool/fremantle/free/l/lzo2/ has indeed a different size than the ones in http://repository.maemo.org/extras/pool/fremantle/free/l/lzo2/ http://repository.maemo.org/extras-testing/pool/fremantle/free/l/lzo2/ http://repository.maemo.org/extras-devel/pool/fremantle/free/l/lzo2/ How is this possible? Was the package recompiled and but the version number not changed? If someone uploads the same source, just to recompile it against the latest SDK or dependencies, wouldn't it be a good idea to increase the version number? best, -- Thomas Tanner -- email: tan...@gmx.de GnuPG: 1024/5924D4DD ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
upload invitations disabled?
Hi, who is responsible for processing the requests for an invitation for upload rights for Extras? https://garage.maemo.org/extras-assistant/index.php I've tried it a couple of times over past few weeks but I did not get any response so far.. :( Thanks -- Thomas Tanner -- email: tan...@gmx.de GnuPG: 1024/5924D4DD ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: repository.maemo.org down
Ville M. Vainio wrote: > On Mon, Jan 18, 2010 at 10:12 AM, wrote: > apt-get update seems to work now, but there still seems to be problem > with bz2 (trying to install toolchain with maemo-sdk, i.e. Maemo SDK+ > & sb2): > just replace all repository.maemo.org with stage.maemo.org in .maemo-sdk/index.toolchains best regards, -- Thomas Tanner -- email: tan...@gmx.de GnuPG: 1024/5924D4DD ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Mirrors
Hi Jeff and *, Jeff Moe wrote: >> I hope a local mirror helps in your case. > apt-get update in 2 seconds. Thanks a lot for your mirror, Jeff! It's really useful whenever... >> You are aware that we are using Akamai (fully distributed content delivery) >> for the caching? And that the hit and transfer amounts are way out of the >> league for anything we could set up ourselves? > Yes, but that still doesn't preclude using mirrors. Akamai goes down too. ... the "unbreakable" main repository is down. QED :) FYI: I have uploaded some reprepro configuration for people who want to setup their own mirror: http://www.maemory.com/mirror/repro-maemo.tgz cheers, -- Thomas Tanner -- email: tan...@gmx.de GnuPG: 1024/5924D4DD ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Debhelper 7
just found this old message: Marius Vollmer wrote: > That's the magic. You will likely need to update Perl as well, and then > update many many Perl modules. This is what I have done for Harmattan, > and now I am sitting on about 100 packages that I have updated... :-) it is actually much less http://www.maemory.com/N900/perl5.10/ http://www.maemory.com/N900/libperl/ but running it in the SDK is a hassle (you need to move devkit perl away and fix all references) > You can also backport debhelper 7 to Perl 5.8. that's what I have done: http://www.maemory.com/N900/build/ you'll have to move away the dh_* files from your devkits otherwise it won't use the files from the package. You could also try the SDK+ based on scratchbox 2 http://maemo-sdk.garage.maemo.org/ which make it easy to use the host perl with export SBOX_REDIRECT_FORCE=/usr/bin/perl cheers, -- Thomas Tanner -- email: tan...@gmx.de GnuPG: 1024/5924D4DD ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
/opt hierarchy (was: /usr/local)
Eero Tamminen wrote:
> Whereas /opt is standardized place for 3rd party software:
> http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES
thanks! then let me rephrase my question:
why not have the same hierarchy as in /usr
(i.e. /opt/{bin,lib,share,...} ) and
* either install user application there directly
to avoid clutter on root - which is AFAIK FHS compliant
* or use the current /opt/ structure
and put the symlinks in the /opt hierarchy as GNU stow
does for /usr/local.
For the /opt hierarchy just put /opt/bin in /etc/profile's $PATH,
/opt/lib in ld.so.conf and add /opt/share/{icons,theme,python}
to the respective search paths.
I've just found http://wiki.maemo.org/Opt_Problem
so I'll stop bothering you with probably the same old questions
unless you think it's worth continuing.
> Problematic issues would be how to deal with shared libraries,...
> Direct invocations of binaries from scripts could also be problematic.
I do not really understand why those would be issues,
at least not with solution described above?
> (And if somebody would want more space for applications than is
> available on /home partition, he could change the /opt symlink to
> point to a memory card with suitable file system and prepare for
> the issues resulting from having programs on removable media...)
not necessary - I already got rid of the MyDocs FAT partition
and have a 28GiB /home with MyDocs as a loop device file.
we have a brainstorm for that issue
https://maemo.org/community/brainstorm/view/more_efficient_and_flexible_use_of_internal_flash/
best,
--
Thomas Tanner --
email: tan...@gmx.de
GnuPG: 1024/5924D4DD
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: /usr/local
I'm aware that standard Debian packages would need to adapted but it would mainly involve replacing /usr with /usr/local (or removing /usr as /usr/local is the default prefix in autoconf), correct? Andrew Flegg wrote: > On Wed, Dec 30, 2009 at 12:23, Thomas Tanner wrote: >> Is there any good reason why Maemo does not follow the standard UNIX >> layout with user applications in /usr/local ? >> /usr/local seems to be in all search paths and if /usr/local >> would be just a symlink to /home/local there would be no need >> for further symlink tricks. > > Short version: most packages will install to /usr rather than > /usr/local, so there'd have to be build changes either way. -- Thomas Tanner -- email: tan...@gmx.de GnuPG: 1024/5924D4DD ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
/usr/local
Hi, sorry for my ignorance - I've only recently started following the optification discussion. Is there any good reason why Maemo does not follow the standard UNIX layout with user applications in /usr/local ? /usr/local seems to be in all search paths and if /usr/local would be just a symlink to /home/local there would be no need for further symlink tricks. best, -- Thomas Tanner -- email: tan...@gmx.de GnuPG: 1024/5924D4DD ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
N900 Usb Host + Power Charge
Hi would it be possible to enable USB host mode by connecting an external "power injector" http://tabletblog.com/2006/01/usb-power-injector-2.html between the N900 and a USB client? cheers, Igor Stoppa wrote: >> The N900 comes without USB host mode. When I asked I was told that the >> limitation comes at hardware level. > > I can confirm this. The most reasonable setup would have been to provide > the A connector, but only gadget mode working forthe sales release, then > in a SW update to provide full spectrum support. >> The reason for this decision was the complexity of providing support >> for charging, PC connectivity and USB OTG efficiently through the same >> Micro USB port within the project deadlines. -- Thomas Tanner -- email: tan...@gmx.de GnuPG: 1024/5924D4DD ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
