[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#940578: printer-driver-cups-pdf: cups pdf printer cannot create pdf file



Hi Martin-Éric,

Martin-Éric Racine:
> ke 18. syysk. 2019 klo 10.03 intrigeri (intrigeri@debian.org) kirjoitti:

>>    Here it's already kind of the case:
>>    https://sources.debian.org/src/cups-pdf/3.0.1-5/debian/README.Debian/#L12
>>
>>    But that file incorrectly suggests that this caveat applies only to
>>    Ubuntu, which is not the case anymore. So I would say first thing
>>    is to drop the " (UBUNTU)" annotation.
>>
>>    If you choose this option, then this bug should be reassigned back
>>    to cups-pdf.

> It shouldn't. This is an AppArmor issue. AppArmor interferes with
> CUPS-PDF configuration.

Between the lines you wrote, what I _think_ I understand is that:

 - You don't particularly care how and where the problem is solved.

 - You'd rather not spend more time yourself on AppArmor-related
   issues that affect cups-pdf.

 - You expect AppArmor folks to solve the problem.

Did I understand your position correctly?

FWIW, I personally find such a position perfectly fair and reasonable.

If I understood correctly that you don't particularly want to choose
a strategy nor implement a fix yourself, then I'll do this myself.
I'll probably go with option C, because:

 - I have not enough time and interest in cups-pdf to implement
   option A myself.

 - Option B will not fully fix the problem and you would still get the
   occasional bug report, which I understand you'd rather
   avoid entirely.

Regarding "to which package should this bug be assigned to": even if
this bug is assigned to package X, because that's where the chosen
solution shall be implemented, it does not mean that the maintainers
of package X are the ones responsible to fix the problem themselves.

Other folks, who are particularly interested in the topic of the bug
can help. That's how we handle things for similar topics, where
a broad class of issues are fixed in a great number of packages by
some specialized folks who are not the package maintainers.
For example: non-systemd init support, build reproducibility, or
porting to various architectures.

Cheers,
-- 
intrigeri


Reply to: