Re: DFSG status of petsc
On Sat, 2015-09-19 at 21:22 +1000, Riley Baird wrote: > > But do we need to be pedantic about upstream pdf files? > > > > Our petsc distribution would be in principle be improved if we were > > to > > include the pdf manuals. > > Yeah, I completely understand. Especially seeing as we now have > things > like libreoffice-pdfimport. But the FTP masters have specifically > stated > (in their "Reject FAQ") that they will reject packages with > sourceless > PDFs. No worries. Thanks for the confirmation, Riley. > What you could do is use libreoffice-pdfimport to create a source > file, > repack the tarball and regenerate the pdfs at buildtime. I think philosophically this is suboptimal. If we're allowed to do this, then the original pdf file essentially counts as the source code and therefore the sourceless pdf should be permitted in the first place. Incidentally, editing the pdf via libreoffice is completely successful as far as editing content goes. But it loses the little extras, like hyperlinks or the structured index. > > Alternatively, you could try to contact upstream to get these issues > sorted out. That would solve the problem, of course :) Drew
Re: DFSG status of petsc
On Sat, 2015-09-19 at 19:21 +0200, Graham Inggs wrote: > Hi Drew > > On 19 September 2015 at 10:46, Drew Parsons > wrote: > > As far as the win32 exe goes, maintenance would be simpler if we > > didn't > > have to generate a separate dfsg-free upstream tarball just to > > remove a > > file that we don't use. > > Are you aware of UscanEnhancements[1]? > > You can now use the 'Files-Excluded' field in debian/copright to > exclude files from repacking. > Repacking can be done in one line in debian/rules. > See source package p4vasp for examples of debian/copyright [2] and > debian/rules [3]. > Thanks for the tip, Graham. I'll take a closer look at that mechanism. On Sat, 2015-09-19 at 07:42 -0700, Walter Landry wrote: > > Isn't this the source for win32fe? > > https://bitbucket.org/petsc/win32fe > Well spotted, thanks Walter. Drew
Re: DFSG status of petsc
Hi Drew On 19 September 2015 at 10:46, Drew Parsons wrote: > As far as the win32 exe goes, maintenance would be simpler if we didn't > have to generate a separate dfsg-free upstream tarball just to remove a > file that we don't use. Are you aware of UscanEnhancements[1]? You can now use the 'Files-Excluded' field in debian/copright to exclude files from repacking. Repacking can be done in one line in debian/rules. See source package p4vasp for examples of debian/copyright [2] and debian/rules [3]. Regards Graham [1] https://wiki.debian.org/UscanEnhancements [2] http://anonscm.debian.org/cgit/debichem/packages/p4vasp.git/tree/debian/copyright#n5 [3] http://anonscm.debian.org/cgit/debichem/packages/p4vasp.git/tree/debian/rules#n37
Re: DFSG status of petsc
Drew Parsons wrote: > What is Debian policy on pdf documentation in upstream source? > > > dolfin needs an updated petsc to run optimally (multiple processors). > And dolfin is cool, so I'll update petsc (the latest version at > http://www.mcs.anl.gov/petsc is 3.6.1). > > We've been using a dfsg version of petsc. The dfsg impact is minimal: > > (1) a windows executable and dll in bin/win32fe/ > > (2) pdf manuals (manual.pdf, tao_manual.pdf, developers.pdf in docs/) > > These two sets of files are only dfsg because the source code is not > available to generate them. I gather we'd be free to modify the files > and distribute modifications if we wanted to. Isn't this the source for win32fe? https://bitbucket.org/petsc/win32fe Though you should probably just delete it from the tarball. In my 5 minute search, I could not find the source for the documentation. But I am absolutely certain someone on petsc-maint could point you to it. Cheers, Walter Landry
Re: DFSG status of petsc
> But do we need to be pedantic about upstream pdf files? > > Our petsc distribution would be in principle be improved if we were to > include the pdf manuals. Yeah, I completely understand. Especially seeing as we now have things like libreoffice-pdfimport. But the FTP masters have specifically stated (in their "Reject FAQ") that they will reject packages with sourceless PDFs. What you could do is use libreoffice-pdfimport to create a source file, repack the tarball and regenerate the pdfs at buildtime. > As far as the win32 exe goes, maintenance would be simpler if we didn't > have to generate a separate dfsg-free upstream tarball just to remove a > file that we don't use. If you want the PDF documentation, you'll have to repack the tarball anyway. get-orig-source targets in debian/rules can speed up this process for future releases. Alternatively, you could try to contact upstream to get these issues sorted out. pgp343NQC3Yqa.pgp Description: PGP signature
