Re: yada generated deb not calling update-menus
On Wed, 2007-04-18 at 10:59 +0200, Thijs Kinkhorst wrote: I'm wondering why you, as a 'novice deb builder', chose yada as a packaging helper. I wouldn't recommend it to new packagers (or at all), because it hides large parts of the build process. Ah, but that's exactly why I chose it. I did start off trying dh scripts but thought it seemed like a lot of work for a simple install. I didn't discover yada until I got hold of the Martin Krafft Debian book, liked the look of the apparently cleaner approach and got something which seemed to work well very quickly. You can see that right here: there's code generated that doesn't work, but it's very opaque what does this, why, and how to change it. A look at an old .deb built with yada on sarge (where it worked fine wrt menus) shows it just contains if test -x /usr/bin/update-menus; then update-menus; fi Searching etch's /usr/bin/yada (perl) for update-menus finds \nif [ \$1\ = \configure\ ] ... the $1 is presumably being prematurely substituted when it should go into the postinst script intact. Aha... in fact a few lines later I can see some presumably correctly escaped \nif [ \\$1\ = \configure\ ]; I've just put in a reportbug. My only options for fixing my debs immediately seems to be patching yada or unpacking the debs and patching the affected line. I'm not sure which is more horrible. debhelper might lead to a longer debian/rules file, but it has the advatages that you actually see which steps are taken in what order, and that you can easily control what happens. Hmmm maybe I should give dh another go. Regards Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: yada generated deb not calling update-menus
On Wed, 2007-04-18 at 17:13 +0100, James Westby wrote: On (18/04/07 00:32), Tim Day wrote: When I look at the postinst file in my yada-generate deb then the only thing of note is: if [ = configure ] [ -x `which update-menus 2/dev/null` ]; then update-menus; fi That should be $1 (or is it $2?) in the first set of quotes. Whatever is writing this out is probably a shell or perl script that isn't escaping it. I don't have internet access to check your script now though. That does seem to be the problem; there's bug #419878 in for it now. Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
yada generated deb not calling update-menus
I (novice deb builder) am building a deb with yada (and pbuilder) on Etch. I don't have any problems getting a sensible /usr/share/menu entry put in place, but it doesn't actually seem to appear in any menus until I do a manual sudo update-menus (or install some other package which triggers a menu update itself). When I look at the postinst file in my yada-generate deb then the only thing of note is: if [ = configure ] [ -x `which update-menus 2/dev/null` ]; then update-menus; fi ...which clearly isn't ever going to do anything! But I can't figure out what's needed to get yada to (presumably) put whatever's needed into those empty quotes so that the configure step will call update-menus. You can see my whole deb-building script at http://fracplanet.cvs.sourceforge.net/fracplanet/fracplanet/mkdeb?revision=1.15view=markup the yada input is setup in the catEOF scope at lines ~60-100. Thanks for any help Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: evolvotron (graphics)
Thanks to all for the tips and pointers. - Turns out there is a -k option for dh_installchangelogs which makes CHANGES a symlink to changelog, which seems sensible enough. - I have enough semi-obsolete spare machines here to turn one over to unstable (looks a bit easier to get to grips with than pbuilder). - I was going to ask how an i386 distro handles apps which could really benefit from P4/SSE type optimsations, but I've just noticed ctsim-pentium3 ctsim-pentium4, which seems like a good solution. - Still looking for a sponsor! Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: evolvotron (graphics)
Thanks to all for the tips and pointers. - Turns out there is a -k option for dh_installchangelogs which makes CHANGES a symlink to changelog, which seems sensible enough. - I have enough semi-obsolete spare machines here to turn one over to unstable (looks a bit easier to get to grips with than pbuilder). - I was going to ask how an i386 distro handles apps which could really benefit from P4/SSE type optimsations, but I've just noticed ctsim-pentium3 ctsim-pentium4, which seems like a good solution. - Still looking for a sponsor! Tim
RFS: evolvotron (graphcs)
I'm the developer of evolvotron, an interactive evolutionary art program. Home page: http://www.bottlenose.demon.co.uk/share/evolvotron/index.htm Examples: http://www.bottlenose.demon.co.uk/share/evolvotron/gallery.htm Project page: http://sourceforge.net/projects/evolvotron/index.htm I'd like to become the maintainer of a packaging of it for debian, if you're interested. There's my initial attempt at building a .deb and associates (following the new maintainer's guide) at: http://www.bottlenose.demon.co.uk/tmp/ (sorry, I don't have an ftp site, but the files should be retreivable using your browser's download link or similar). It installs a /usr/bin/evolvotron (and a couple of related command line apps) and creates an Apps/Graphics/evolvotron entry on the Debian menu. This is actually a .deb of work in progress so there is some dead functionality on the Settings/Functions menu. Depending on how fast things happen I'd actually expect to put the finished 0.2.4 release into Debian when it's done, or would fixup the last 0.2.3 release (which was missing man pages). A few of questions: - Does it matter that I built this on a testing rather than unstable system ? (I have a stable and a testing box here). - I was expecting (according to the guide) to have to enter a GPG key during thedpkg-buildpackage step. It didn't ask, but I'm guessing this because I haven't set myself up with gpg yet ? - The evolvotron sources come with a CHANGES file. In /usr/share/doc/evolvotron I seem to have ended up with a duplicate CHANGES.gz changelog.gz plus a changelog.Debian.gz. Should I get rid of CHANGES and just have the changelogs, or is this not a big deal ? - Is there any policy on optimisation flags ? The evolvotron sources override the qmake supplied -O2 flag with -O3 -fomit-frame-pointer -funroll-loops -ffast-math, which last time I checked could render about 13% faster. Should I force them back to just -O2 for the debian build ? Thanks -- Tim Day - www.timday.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: evolvotron (graphcs)
I'm the developer of evolvotron, an interactive evolutionary art program. Home page: http://www.bottlenose.demon.co.uk/share/evolvotron/index.htm Examples: http://www.bottlenose.demon.co.uk/share/evolvotron/gallery.htm Project page: http://sourceforge.net/projects/evolvotron/index.htm I'd like to become the maintainer of a packaging of it for debian, if you're interested. There's my initial attempt at building a .deb and associates (following the new maintainer's guide) at: http://www.bottlenose.demon.co.uk/tmp/ (sorry, I don't have an ftp site, but the files should be retreivable using your browser's download link or similar). It installs a /usr/bin/evolvotron (and a couple of related command line apps) and creates an Apps/Graphics/evolvotron entry on the Debian menu. This is actually a .deb of work in progress so there is some dead functionality on the Settings/Functions menu. Depending on how fast things happen I'd actually expect to put the finished 0.2.4 release into Debian when it's done, or would fixup the last 0.2.3 release (which was missing man pages). A few of questions: - Does it matter that I built this on a testing rather than unstable system ? (I have a stable and a testing box here). - I was expecting (according to the guide) to have to enter a GPG key during thedpkg-buildpackage step. It didn't ask, but I'm guessing this because I haven't set myself up with gpg yet ? - The evolvotron sources come with a CHANGES file. In /usr/share/doc/evolvotron I seem to have ended up with a duplicate CHANGES.gz changelog.gz plus a changelog.Debian.gz. Should I get rid of CHANGES and just have the changelogs, or is this not a big deal ? - Is there any policy on optimisation flags ? The evolvotron sources override the qmake supplied -O2 flag with -O3 -fomit-frame-pointer -funroll-loops -ffast-math, which last time I checked could render about 13% faster. Should I force them back to just -O2 for the debian build ? Thanks -- Tim Day - www.timday.com
