Andreas - Am working on getting the latest devscripts distro. I have 2.14.1 from Ubuntu but I think that mk-origtargz is actually from 2.14.2 or later. Will be a day or two for me to figure out if I should just switch to a development version of Debian or <gulp> jump on the unstable development branch in Ubuntu. Probably will need to be a virtual machine with a Debian version.
More once I have that going ... cheers ian On Mon, Jun 23, 2014 at 11:28 PM, Andreas Tille <[email protected]> wrote: > Hi Ian, > > On Mon, Jun 23, 2014 at 03:57:14PM -0700, Ian Wallace wrote: >> > The Files-Excluded field in debian/copyright works when you *obtain* >> > (create) the tarball via uscan (or mk-origtargz which is called by uscan >> > and can be used to test your Files-Excluded field without the need to >> > fetch the upstream source from the web over and over. I have added a >> > get-orig-source target to debian/rules which is described in the >> > developers reference as a target you should use if simple uscan is not >> > sufficient. So you can >> > >> > debian/rules get-orig-source >> > >> > now. The problem is that your patch levels are not really downloadable >> > from sf.net - so uscan can not work like this. So if you have any other >> > means to download openemr-4.1.2p7.tar.gz you could verify the >> > functionality fo Files-Excluded via >> > >> > mk-origtargz --repack --compress xz <path_to>/openemr-4.1.2p7.tar.gz >> >> Is the true solution here to ask the upstream maintainer (Brady) to >> essentially issue a new tar ball with each patch? Would that be a >> more Debian method of doing this? > > Strictly speaking yes, if we would talk about packages that would be > prepared for an upload. I also have no idea whether these patches are > just marking some development status or whether these are intended to be > used in production. In the later case I would recommend to provide > these tarballs in any case independently from our packaging attempt. We > are currently in the first development phase so it might have some > profit for you to get a grip on "not so official" code to prepare a > final release and I think it is OK to work with certain patch levels. > But uscan and Files-Excluded which is regarded by uscan only work on > released tarballs which I tried to explain above. > >> Then uscan would find the >> openemr-4.1.2p7.tar.gz file on sf.net and could be used to create the >> new orig tar? I'll try the above command to test my Files-Excluded in >> the copyright - I have been creating from scratch using 'tar zcvf'. I >> was worried that the way I was doing it was incorrect (I removed >> 'phpmyadmin' directly from the git repo and then just committed the >> changes which from what you are saying isn't the correct method I >> should always start from the original source tar ball). > > Well, I'm hesitating to address one method as "correct" and an other one > as "wrong". Files-Exclouded is working on tarballs and I personally > prefer working with this since it is an established method (well, > working with tarballs is established, Files-Excluded is quite new). > There are alternatives to work with upstream Git repositories and > Charles Plessy is using this in a few packages for certain reasons. > However, this method is totally orthogonal to the Files-Excluded field > in debian/copyright. In short: If you want to use the later you need a > tarball - either from upstream or you might fake one and use > mk-origtargz as written above. > >> I tried a >> second method of creating a large quilt patch to just remove >> everything but phpmyadmin has binary files that quilt doesn't like to >> handle. > > A quilt patch is NOT the method to remove files from a tarball. The > binaries without source would simply remain in the tarball and just > become invisible in the build process. So this is definitely not the > solution (but remaining a nice training for using quilt anyway ;-)). > >> > when beeing located in the root of your Git repository. This should >> > create a file >> > >> > ../openemr_4.1.2p7.orig.tar.xz >> > >> > which you could import via >> > >> > git import-orig --pristine-tar ../openemr_4.1.2p7.orig.tar.xz >> > >> >> Once I test the above creation of the orig.tar.xz I will add to the >> repo so that you can rebuild/test if you have time/want to. > > OK. > >> > BTW, this would also be needed to enable me reproducing your work since >> > there is no such information in the pristine-tar branch to enable me >> > reproducing your current source tarball. >> > >> > > Just to recap here's where I am: >> > > 1) Can create a deb file that will install/remove. >> > >> > Good. >> > >> > > 2) Webserver currently needs to be manually configured with a2enconf and >> > > service apache2 reload but the default configuration is packaged. >> > >> > Sounds reasonable. >> > >> > > 3) Maintainer scripts (pre/post/inst/rm) have been disabled (Brady Miller >> > > wrote the originals) and I need to wade through them now fixing the >> > > various >> > > complaints that linitian generates about unsafe temp files, not using the >> > > template system correctly, not using the PO stuff for >> > > internationalization. >> > >> > OK, just report any problems here. >> > >> > > 4) The large project left is finding/updating all of our minified JS. I >> > > confirmed with upstream that in fact the project *does* rely on several >> > > versions all the way back to 1.2.1 of jQuery and the scripts that rely on >> > > it are known to break if updated. >> > >> > Uhm. :-( >> >> I checked on this explicitly to try and determine how many versions of >> the libraries we actually used. I will have to take this on as a pet >> project to update/test and submit patches so that OpenEMR can start to >> use the more recent versions of jQuery. They also use lots of the >> sub-projects (jQuery-ui, and some other ones). I might add some of >> the original source files in the mean time since this will be the >> faster of the two options ... I realize it's duplicate code and should >> be removed but that will be many, many months. > > I agree that we should try to find some compromise between a totally > clean implementation and something we and our users could start working > with. There will be some period of time when we need to work with those > duplicates and remove them step by step over time. > > Kind regards > > Andreas. > > -- > http://fam-tille.de > > > -- > To UNSUBSCRIBE, email to [email protected] > with a subject of "unsubscribe". Trouble? Contact [email protected] > Archive: https://lists.debian.org/[email protected] > -- Ian Wallace - CCRMC DFM Staff Physician - (c) 303.681.5732 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/CABRQjx3bmaP7fXmQPwg88a532mKZyQrk+ZNRfL5wq=vccsh...@mail.gmail.com
