Re: PR1.2 SDK for Extras-devel: how to solve?
On Wed, 7 Apr 2010 21:27:30 +0100 Graham Cobb 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 > > > 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: PR1.2 SDK for Extras-devel: how to solve?
On Wed, 7 Apr 2010 15:41:48 +0100 Andrew Flegg wrote: > On Wed, Apr 7, 2010 at 15:13, Bryan Jacobs 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?
o into > Extras-devel. Can be promoted to Extras-testing and > tested by testers using the most recent release. > Once promoted it will go into fremantle-1.2. > > 6) Case-by-case basis. > > Developer complains: add a temporary exception to autobuilder to build > $APPNAME with PR1.0/1.1 SDK, but goes into the shared extras-devel as > now. > > Thanks in advance, > > Andrew > Hello all, Pardon the intrusion from somebody who doesn't usually post on this list, but I think I might have some input. 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. 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: 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 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 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
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 wrote: > And you're sure debian/rules is marked as executable? > > On Fri, Jan 1, 2010 at 4:14 PM, Bryan Jacobs > 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 > > 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
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 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
