Re: [rkward-devel] rules revised
hi, On Friday 07 August 2009 20:35:48 meik michalke wrote: what about this: we add lsb-release to the build-deps for the time being, and drop it again in april 2010, together with hardy support? [that is, if no one uses the tool to discover other distribution details until then.] i think i've found a solution that's both precise and easy, and without additional dependencies: looking for the source where lsb_release would actually look for the information, i discovered /etc/lsb-release which is part of the necessary package base-files. i'll grep for hardy or 8.04 in that file to discover the distribution, and we're done :-) viele grüße :: m.eik -- dipl. psych. meik michalke abt. fur diagnostik und differentielle psychologie institut fur experimentelle psychologie heinrich-heine-universitat dusseldorf signature.asc Description: This is a digitally signed message part. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] rules revised
hi, am Freitag, 7. August 2009 (22:43) schrieb Thomas Friedrichsmeier: Ok, my assumption was that the problem is in fact tied to kdelibs 4.0.x debian packages in general, not hardy. at least not at this point. hardy was delivered with kde3, so kde4 is being installed in a slightly different path, which should be true for later kde4 versions packed for hardy as well. so we need to check if we're compiling for hardy, add that path to $PATH (otherwise kde4-config won't be found) and apply the small patch that also just changes the path for the k-menu entry. i don't know where debian installs kdelibs 4.0.x. on the other hand, i think your approach could still be useful for problems that are actually kde 4.0.x related. if it's not too big changes to work around kde 4.0 bugs, you could put them in a patch of their own (and leave the sources written for later versions of kdelibs). of course this would mean the patches are only applied when a debian package is build, a cmake build would fail, though. therefore it might be good as it is, to deal with library bugs in the code directly but with distribution specific issues in the packaging process? what about this: we add lsb-release to the build-deps for the time being, and drop it again in april 2010, together with hardy support? [that is, if no one uses the tool to discover other distribution details until then.] Well, let's put this in for now (please increase the version number to 0.5.1-2 on the .deb, when you do so). i don't plan to re-package because of that, because only the package building itself is concerned. but it will help for the next packages to be build. We'll have to wait and see what happens with regard to inclusion in the official debian/ubuntu archives, though. if they don't like the one diff for all idea we could strip the added ubuntu parts again and create an ubuntu diff. it would still help building it for different ubuntu incarnations, but miss the opportunity to maintain only one unified build mechanism. I need to convince a debian developer of the quality of the packaging each time. So that's why I'm trying this hard to find an aesthetically pleasing solution. yes, sounds desireable :-) viele grüße :: m.eik -- dipl. psych. meik michalke institut fur experimentelle psychologie abt. fur diagnostik und differentielle psychologie heinrich-heine-universitat dusseldorf signature.asc Description: This is a digitally signed message part. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] rules revised
On Sunday 02 August 2009, meik michalke wrote: well, nothing awk couldn't handle. on the other hand, lsb_release -s -i -r still answers Ubuntu 8.04 (distribution release) -- to get Ubuntu 8.04.3 LTS you'd have to call lsb_release -s -d (description). so i wonder if lsb_release wasn't the cleaner solution after all? - awking through /etc/issue would do it, but in a less readable way, and it's more some dirty hack i think (because the issue file doesn't seem a safe place to get reliable release information) - lsb_release is clean and safe, but adds another build dependency i don't know, i'm ok with both ways. I've just though of a third way. As far as I can see, Ubuntu hardy is the only distribution out there that still has kdelibs 4.0.x, so we might be fine just checking the version of kdelibs5-dev. Probably, also, the kdelibs package is where the problem is really at, so this may well be the cleanest way. What do you think? so i don't see this as a hardy issue but more general. i'd prefer to keep *all* packages *we* depend on in *our* dependency list, even if in most (but not all) cases these dependencies are probably already resolved by some other package. that's how i would interpret debian's policy: o http://www.debian.org/doc/debian-policy/footnotes.html#f13 Well, I guess it could be argued that we really do depend on cmake, directly, but rkward does not actually use anything from libphonon. That's just to make linking with kdelibs5-dev work. Anyway. Of course this is merely a matter of aesthetics. And you're right, if there is no perfect all-round solution, then we should put the priority on the practical side, and simply keep these build- depends. I'll change that back in SVN, in a minute. As you might have seen, I gave Julien a note on our discussion, though, let's see, if he can convince us otherwise. Regards Thomas signature.asc Description: This is a digitally signed message part. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] rules revised
On Friday 31 July 2009, meik michalke wrote: yes, we could take the information from /etc/issue. i wanted to test it with ubuntu 8.04, but it comes with debhelper 6.0.4, and rkward now depends on =7.0.0. is that a recent development or have i just missed that because of my own hacks for hardy packages? I did that in 0.5.0d-2, because the previous debhelper compatibility version (4) had become deprecated. However, setting this to 6 is still allowed, so I did that in SVN. There is another issue, which may be harder to fix, though: I dropped the cmake and libphonon-dev build-depends (see http://bugs.debian.org/cgi- bin/bugreport.cgi?bug=531086). I believe they are probably still required on hardy, though, as kdelibs5-dev there fails to depend on them(?). So to build the .deb on hardy, you'd have to install those manually. Do you see a solution for that? BTW, is there a semi-official source for KDE 4.1 or 4.2 on hardy? Those packaging issues really aren't the only problems with KDE 4.0.x, so perhaps, instead of trying to work around them, we should recommend to upgrade the kde4 packages? What do you think? Regards Thomas signature.asc Description: This is a digitally signed message part. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] rules revised
hi, am Samstag, 1. August 2009 (14:20) schrieb Thomas Friedrichsmeier: I did that in 0.5.0d-2, because the previous debhelper compatibility version (4) had become deprecated. However, setting this to 6 is still allowed, so I did that in SVN. thanks, that helped, it compiles again :-) using /etc/issue could be a little more complex than i first thought, though. because on my system with all updates it says Ubuntu 8.04.3 LTS, not Ubuntu 8.04 LTS. well, nothing awk couldn't handle. on the other hand, lsb_release -s -i -r still answers Ubuntu 8.04 (distribution release) -- to get Ubuntu 8.04.3 LTS you'd have to call lsb_release -s -d (description). so i wonder if lsb_release wasn't the cleaner solution after all? - awking through /etc/issue would do it, but in a less readable way, and it's more some dirty hack i think (because the issue file doesn't seem a safe place to get reliable release information) - lsb_release is clean and safe, but adds another build dependency i don't know, i'm ok with both ways. There is another issue, which may be harder to fix, though: I dropped the cmake and libphonon-dev build-depends (see http://bugs.debian.org/cgi- bin/bugreport.cgi?bug=531086). I believe they are probably still required on hardy, though, as kdelibs5-dev there fails to depend on them(?). you're right, kdelibs5-dev doesn't depend on them yet in version 4.0.3. So to build the .deb on hardy, you'd have to install those manually. Do you see a solution for that? actually, i don't see the real issue that needs to be fixed in the first place ;-) perhaps i don't get it, but as far as i see it: julien would like to see those build-depends dropped because this 2 packages are already provided by kdelibs5-dev. kdelibs5-dev doesn't provide these packages but depends on them (in later versions), i guess that's what he meant, but it's still an important difference, seen though the eyes of debian package management. i think it never hurts to have a dependency that is satified already (in most cases), but you can really get into trouble if you start to depend on some other package's dependecies. what if kdelibs5-dev moves the cmake dependecy to its build-deps with the next release? it might be unlikely, but why risk it at all? so i don't see this as a hardy issue but more general. i'd prefer to keep *all* packages *we* depend on in *our* dependency list, even if in most (but not all) cases these dependencies are probably already resolved by some other package. that's how i would interpret debian's policy: o http://www.debian.org/doc/debian-policy/footnotes.html#f13 BTW, is there a semi-official source for KDE 4.1 or 4.2 on hardy? Those packaging issues really aren't the only problems with KDE 4.0.x, so perhaps, instead of trying to work around them, we should recommend to upgrade the kde4 packages? What do you think? i think if you're really still stuck to hardy now it's not that you don't want newer software, but need a stable release with long support. there might be cases where semi-official kde4 packages are an option, but in most of these cases a full upgrade to a whole new ubuntu release would probably be the even more obvious approach. if this sums it up correctly, the only meaningful way to support 8.04 is with its own old kde4 libs. 8.04 will officially be supported by canonical until april 2011. i don't think we need to care for workarounds that long, at least none of us gave this very long term support promise for buggy kde4 versions to anyone directly ;-) but in my view, as a compromise we should at least try to keep it up until the next lts release is due, that should be next april. rkward users could be prepared that kde 4.0 support will finally cease in april 2010. the alternative decision would be to drop hardy support completely, if it hinders the develeopment. btw, i plan to close the 8.10 repository after the release of 9.10. so i think, as a rule of thumb, it's worthwhile to have packages for a) the recent release, b) its predecessor (for those who haven't upgraded yet) and c) the recent long term support release. viele grüße :: m.eik -- dipl. psych. meik michalke institut fur experimentelle psychologie abt. fur diagnostik und differentielle psychologie heinrich-heine-universitat dusseldorf signature.asc Description: This is a digitally signed message part. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] rules revised
Am Donnerstag 30 Juli 2009 03:35:31 pm schrieb Thomas Friedrichsmeier: However since this is a debian package, perhaps we don't need the full flexibility of lsb_release after all: Could you check /etc/debian_version or /etc/issue on your various Ubuntus? (On debian/sid the files have: squeeze/sid and Debian GNU/Linux squeeze/sid \n \l respectively). Regards Thomas On Kubuntu 9.04: /etc/debian_version 5.0 /etc/issue Ubuntu 9.04 \n \l Cheers Dirk signature.asc Description: This is a digitally signed message part. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] rules revised
am Donnerstag, 30. Juli 2009 (15:35) schrieb Thomas Friedrichsmeier: Could you check /etc/debian_version or /etc/issue on your various Ubuntus? yes, we could take the information from /etc/issue. i wanted to test it with ubuntu 8.04, but it comes with debhelper 6.0.4, and rkward now depends on =7.0.0. is that a recent development or have i just missed that because of my own hacks for hardy packages? viele grüße :: m.eik -- dipl. psych. meik michalke institut fur experimentelle psychologie abt. fur diagnostik und differentielle psychologie heinrich-heine-universitat dusseldorf signature.asc Description: This is a digitally signed message part. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] rules revised
Hi, On Monday 27 July 2009, meik michalke wrote: am Montag, 27. Juli 2009 (17:30) schrieb Thomas Friedrichsmeier: This appears to work (at least the ubuntu 8.04 patch is not applied, here), fine; i was hoping so, because it worked with different ubuntu versions, but you never know... (you can change the condition to test how it would turn out if the patch was applied -- the clean rule safely removes the patch again from the sources, nothing to worry about) I just realized, though, that the command lsb_release is not even installed on debian by default. In this case that's not a problem, but to really differentiate the various debian flavors using this technique, we'd need to build-depend on lsb-release. That's possible, but pulls some further depends, including lsb and python. However since this is a debian package, perhaps we don't need the full flexibility of lsb_release after all: Could you check /etc/debian_version or /etc/issue on your various Ubuntus? (On debian/sid the files have: squeeze/sid and Debian GNU/Linux squeeze/sid \n \l respectively). Regards Thomas signature.asc Description: This is a digitally signed message part. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] rules revised
Hi, On Sunday 26 July 2009, meik michalke wrote: i did some work on the debian/rules file, mainly because i was finally annoyed enough i had to keep a seperate version for the ubuntu 8.04 lts release. instead, i was looking for an one size fits all solution that checks where it's running and applies patches, if applicable. yes, that would really be nice. I've commited this to SVN with some changes. the checks for R versions are tweaked a little as well, and updated after support for 2.7 has ceased. actually, the build won't even start any more if R is too old. awk is being called for this to work. make doesn't have too elaborate arithmetic features (e.g. greater than conditions...), does it? In fact, make really isn't well suited for this. I like your solution with awk. In fact, we would have gotten in trouble, soon, as I believe the R devels plan to release the next version as 2.10.0, which would break the old code in rules. I removed the check for R = 2.7, again. That should be specified in debian/control, instead (and it is, now). another new call goes to lsb_release to get the distribution. if it's not ubuntu 8.04, the included menu patch will be ignored. so you can distribute the patch as well and don't have to worry about it. on the other hand, new patches for certain distributions could be added easily. could you give it a try and see if it works under debian as well? This appears to work (at least the ubuntu 8.04 patch is not applied, here), and I like the general approach. I'm wondering, whether this could be written in more readable way, without using additional make targets for this (but instead just setting a list of patches to apply). Perhaps I need to read up on using dpatch, though. Any reason why you reverted dh_prep to dh_clean -k? lintian complains on the latter, so I've changed it again. Regards Thomas signature.asc Description: This is a digitally signed message part. -- ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
