Re: DFSG status of petsc

[Drew Parsons]

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

[Drew Parsons]

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

[Riley Baird]

> 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

Re: DFSG status of petsc

[Walter Landry]

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

[Graham Inggs]

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