Re: PR1.2 SDK for Extras-devel: how to solve?
in implementing #4 above. If there were magically separate infrastructure for each incompatible release, there would be no issue - a developer uploads their package to each repository for which it builds (preferably through a list of checkboxes in the web interface), and a user selects one or more package sources that match the preinstalled software on their device. No problems, mate. So the real issue is that creating a new branch requires a nontrivial amount of work. This is a computerized system; computers excel at automation. Why not spend the one-off time to allow for near-instant creation of a new branch? Once that's done, future releases will just consist of oh, I should create a new repository for this release. Let me run that script again with a new name and then upload the new SDK release to it. Have I missed some important consideration? Bryan Jacobs signature.asc Description: PGP signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PR1.2 SDK for Extras-devel: how to solve?
On Wed, 7 Apr 2010 15:41:48 +0100 Andrew Flegg and...@bleb.org wrote: On Wed, Apr 7, 2010 at 15:13, Bryan Jacobs n...@landwarsin.asia wrote: It seems to me that the real problem is actually the difficulty in implementing #4 above. If there were magically separate infrastructure for each incompatible release, there would be no issue - a developer uploads their package to each repository for which it builds (preferably through a list of checkboxes in the web interface), and a user selects one or more package sources that match the preinstalled software on their device. No problems, mate. True; however what about the QA process? The UI at http://maemo.org/packages/ is getting better, but it's also getting more familiar. How do we: a) not confuse ad-hoc testers b) ensure that versions in all repos get tested? Each QA tester (probably) only uses one device for testing. If this is true, this means that applications get tested on the platform the QA testers are on. This doesn't guarantee coverage for any particular application/SDK combination, but it does mean that things that are important to (the QA) users will get more throughly used. I'm not convinced that's a bad thing. As long as the QA users make both positive and negative bug reports, I think this will probably work out while not totally satisfying (b) above. (a) is OK because each QA tester just uses the repos matching their device, and upgrades whenever the next level meets their own personal comfort level with the bleeding-edge-to-stability spectrum. One suggestion would be to promote all versions simultaneously, but there are obvious drawbacks with that! I wouldn't do that. I'd promote things when you have enough negative bug reports about the particular version. Some things will never get promoted if nobody loves them. Tough cookies - if nobody cares enough to test the package as it is, does it really need promotion? So the real issue is that creating a new branch requires a nontrivial amount of work. This is a computerized system; computers excel at automation. Why not spend the one-off time to allow for near-instant creation of a new branch? Once that's done, future releases will just consist of oh, I should create a new repository for this release. Let me run that script again with a new name and then upload the new SDK release to it. Indeed. Have I missed some important consideration? I think the issues aren't technical (although streamlining the repo creation is obviously part of it), but more procedural. I could be wrong. I wonder what the testing squad think (I'll poke VDVsx). I can't really say anything about whatever internal rules would restrict this from working. I obviously have an interest in the process working better than it has, so I felt like commenting. It would be a shame if it were more than a technical problem. It's easier to argue for longer about qualitative things. Cheers, Andrew Bryan Jacobs signature.asc Description: PGP signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PR1.2 SDK for Extras-devel: how to solve?
On Wed, 7 Apr 2010 21:27:30 +0100 Graham Cobb g+...@cobb.uk.net wrote: On Wednesday 07 April 2010 16:54:28 Niels Breet wrote: On Wed, April 7, 2010 16:41, Andrew Flegg wrote: On Wed, Apr 7, 2010 at 15:13, Bryan Jacobs n...@landwarsin.asia wrote: It seems to me that the real problem is actually the difficulty in implementing #4 above. If there were magically separate infrastructure for each incompatible release, there would be no issue - a developer uploads their package to each repository for which it builds (preferably through a list of checkboxes in the web interface), and a user selects one or more package sources that match the preinstalled software on their device. No problems, mate. True; however what about the QA process? The UI at http://maemo.org/packages/ is getting better, but it's also getting more familiar. How do we: a) not confuse ad-hoc testers b) ensure that versions in all repos get tested? This is a non-trivial issue. Testing against all repos is not going to work, imagine what happens when we have PR1.2+1 etc. I agree. There is little point in having repositories for old versions if nothing can ever get promoted into them because there are very few testers left. Unless they are really intended just to be archives: they work while the new version is being introduced (like where we are at at the moment with PR1.2) but once the new version has been out a few weeks, they just drop into archive mode with no promotions, just an archive of software for the old version. You want to keep the repositories for exactly that reason. People can keep using their devices with no disruption of service. I, at least, feel that having the latest version of an application is secondary to avoiding a backwards leap in functionality. One suggestion would be to promote all versions simultaneously, but there are obvious drawbacks with that! That would make the most recent repo the best supported and tested repo. Older repos might or might not work. But then again, that is what -devel is now too. Actually I would make the process make all versions eligible for promotion simultaneously -- once the latest version is tested the developer can promote the other versions without QA when they wish but they can choose to do some more testing themselves if they wish. That sounds decent to me. And it would help keep old/extras as up-to-date as new/extras. In an earlier discussion I had proposed another alternative: have a single repository but multiple autobuilders feeding it. I could submit to either the PR1.1 or PR1.2 autobuilder but the output would go into a single place. This seems more efficient than the build with PR1.1 and if that fails try PR1.2 option but otherwise quite similar. The only problem I have noticed so far with that would come when you introduced a new version which made use of some PR1.2 feature, and hence was built with PR1.2. At that time, the PR1.1 version would no longer be installable (as it has a lower version number and is in the same repository). But for cases like this, where PR1.2 is expected to be fairly quickly adopted once it is eventually released, this would probably work well enough. This is the only solution proposed so far which I would reject out of hand. It's what we've got right now, more or less. As a developer, this is fine - I can use PR1.2 packages. As a user, this is a nightmare. My applications disappear forever for reasons that are unclear to me. When I contact a developer, they say wait for the PR1.2 release to come out. When I ask Nokia, they say We do not discuss release dates for future firmware updates. It's better than the current situation in that packages not using 1.2 functionality aren't broken, but it's still not optimal and I feel it should be avoided at all costs. Remember, you also break packages DEPENDING on the ones using 1.2 functionality. The disruption could be very large if, say, Nokia were to update glibc. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers signature.asc Description: PGP signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Failure with Claws PGP on maemo5 device n900
I've opened a bug at https://bugs.maemo.org/show_bug.cgi?id=7707 since I was unable to find one already open (surprisingly). Bryan Jacobs On Wed, 6 Jan 2010 13:31:29 + Graham Cobb g+...@cobb.uk.net wrote: On Wednesday 06 January 2010 00:27:04 Bryan Jacobs wrote: As I said, the self-symlinking of the plugins is a result of a bug in Maemo auto-optification. What is the bug number? I would like to make sure Marius is working on it. Thanks Graham signature.asc Description: PGP signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Failure with Claws PGP on maemo5 device n900
Hubertus, As I said, the self-symlinking of the plugins is a result of a bug in Maemo auto-optification. The PGP plugins are part of the claws-mail package. If I were to unoptify that it would take up a considerable amount of the precious space available on the device root -_-. Since the problem I forwarded you *is* the cause of the problem, and the actual .deb is thus fine, here's what I recommend you do: - Download the claws-mail-pgp-plugins ARMEL deb ( http://repository.maemo.org/extras-devel/pool/fremantle/free/c/claws-mail/claws-mail-pgp-plugins_3.7.3-1maemo4_armel.deb ). - ar x claws-mail-pgp-plugins_3.7.3-1maemo4_armel.deb - tar xvzf data.tar.gz - rm /opt/maemo/usr/lib/claws-mail/plugins/pgp* - cp usr/lib/claws-mail/plugins/pgp* /opt/maemo/usr/lib/claws-mail/plugins That should get you the real files. Hopefully the Maemo folks will work quickly to resolve this (pretty terrible) bug. Bryan Jacobs On Tue, 05 Jan 2010 23:46:48 +0100 Hubertus Bergmann hubertus.bergm...@web.de wrote: Hi Bryan, aha. Do you have a non optified version for the pgp plugins available? Thanks in advance, Hubertus signature.asc Description: PGP signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Packages using cdbs broken?
Hello all! I cannot seem to build any Debian package using cdbs in my Fremantle scratchbox. The output I get always looks like this: dpkg-buildpackage: source package is heimdal dpkg-buildpackage: source version is 1.2.dfsg.1-2.1maemo1 dpkg-buildpackage: source changed by Bryan Jacobs b...@q3q.us dpkg-buildpackage: host architecture armel dpkg-buildpackage: source version without epoch 1.2.dfsg.1-2.1maemo1 : Using Scratchbox tools to satisfy builddeps : Dependency provided by Scratchbox: bison : Dependency provided by Scratchbox: cdbs : Dependency provided by Scratchbox: texinfo : Dependency provided by Scratchbox: python fakeroot debian/rules clean test -x debian/rules make: *** [testdir] Error 1 Obviously, Error 1 doesn't tell me anything. I'm pretty sure it's cdbs that's causing the issue as this happens with 100% of the packages I've tried making use of it and 0% of packages not using it. Any help? Bryan Jacobs signature.asc Description: PGP signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Packages using cdbs broken?
That does it! Note to self: use the tar 'p' option for sources. I'm puzzled by why *any* of my builds have worked without this. Bryan Jacobs On Fri, 1 Jan 2010 16:24:10 + Faheem Pervez tripp...@gmail.com wrote: And you're sure debian/rules is marked as executable? On Fri, Jan 1, 2010 at 4:14 PM, Bryan Jacobs n...@landwarsin.asia wrote: Hello all! I cannot seem to build any Debian package using cdbs in my Fremantle scratchbox. The output I get always looks like this: dpkg-buildpackage: source package is heimdal dpkg-buildpackage: source version is 1.2.dfsg.1-2.1maemo1 dpkg-buildpackage: source changed by Bryan Jacobs b...@q3q.us dpkg-buildpackage: host architecture armel dpkg-buildpackage: source version without epoch 1.2.dfsg.1-2.1maemo1 : Using Scratchbox tools to satisfy builddeps : Dependency provided by Scratchbox: bison : Dependency provided by Scratchbox: cdbs : Dependency provided by Scratchbox: texinfo : Dependency provided by Scratchbox: python fakeroot debian/rules clean test -x debian/rules make: *** [testdir] Error 1 Obviously, Error 1 doesn't tell me anything. I'm pretty sure it's cdbs that's causing the issue as this happens with 100% of the packages I've tried making use of it and 0% of packages not using it. Any help? Bryan Jacobs ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers signature.asc Description: PGP signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
