Package: okular
Version: 4:4.2.2-2
Severity: normal
I'm CCing this to Debian-devel because I think it speaks to a larger
issue.
I just downloaded a PDF, and tried to copy and paste a bit of text
from it. I used the selection tool, and Okular offered to speak it to
me, but said "Copy forbidden by DRM."
pdftotext was able to convert the entire file to text format in an
instant.
So what I want to know is: why are people putting code into Debian
that limits our freedom? Why are people putting such code into KDE?
And can we please patch it to stop that?
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (99, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.29-2-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages okular depends on:
ii kdebase-runtime 4:4.2.2-1 runtime components from the offici
ii kdelibs5 4:4.2.2-2 core libraries for all KDE 4 appli
ii libc6 2.9-12 GNU C Library: Shared libraries
ii libfreetype6 2.3.9-4.1 FreeType 2 font engine, shared lib
ii libgcc1 1:4.4.0-5 GCC support library
ii libjpeg62 6b-14 The Independent JPEG Group's JPEG
ii libokularcore1 4:4.2.2-2 libraries for the Okular document
ii libphonon4 4:4.3.1-1 Phonon multimedia framework for Qt
ii libpoppler-qt4-3 0.10.6-1 PDF rendering library (Qt 4 based
ii libqca2 2.0.0-4 libraries for the Qt Cryptographic
ii libqimageblitz4 1:0.0.4-4 QImageBlitz image effects library
ii libqt4-dbus 4.5.1-2 Qt 4 D-Bus module
ii libqt4-qt3support 4.5.1-2 Qt 3 compatibility library for Qt
ii libqt4-svg 4.5.1-2 Qt 4 SVG module
ii libqt4-xml 4.5.1-2 Qt 4 XML module
ii libqtcore4 4.5.1-2 Qt 4 core module
ii libqtgui4 4.5.1-2 Qt 4 GUI module
ii libspectre1 0.2.2.ds-1+b1 Library for rendering Postscript d
ii libstdc++6 4.4.0-5 The GNU Standard C++ Library v3
ii phonon 4:4.3.1-1 metapackage for Phonon multimedia
ii zlib1g 1:1.2.3.3.dfsg-13 compression library - runtime
okular recommends no packages.
Versions of packages okular suggests:
pn okular-extra-backends <none> (no description available)
ii texlive-base-bin 2007.dfsg.2-6 TeX Live: Essential binaries
pn unrar <none> (no description available)
-- no debconf information
Acknowledgement sent
to [email protected] (Marco d'Itri):
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Sun, 31 May 2009 01:18:02 GMT) (full text, mbox, link).
On May 31, John Goerzen <[email protected]> wrote:
> So what I want to know is: why are people putting code into Debian
> that limits our freedom? Why are people putting such code into KDE?
>
> And can we please patch it to stop that?
Indeed, the program is clearly broken by design and needs to be fixed.
--
ciao,
Marco
Acknowledgement sent
to Pino Toscano <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Sun, 31 May 2009 01:33:03 GMT) (full text, mbox, link).
Hi,
Okular maintainer (upstream, and cooperating in Debian) speaking here.
> I just downloaded a PDF, and tried to copy and paste a bit of text
> from it. I used the selection tool, and Okular offered to speak it to
> me, but said "Copy forbidden by DRM."
This means the author of the PDF set that users shouldn't (in their will) copy
the text from their PDF.
You can disable the usage of document permissions by disabling the related
option from the preferences.
> pdftotext was able to convert the entire file to text format in an
> instant.
Most probably pdftotext just ignores user permissions.
> So what I want to know is: why are people putting code into Debian
> that limits our freedom? Why are people putting such code into KDE?
If you feel limited in "your freedom", then go complaining about Adobe and the
ISO 32000, aka the standardization of the PDF format, because, in case you
don't know, those permissions are features of the PDF format, nothing Okular
enforces on its own. And given that it is a feature of a file format just like
annotations or sounds, people could use it (for example in corporate
environments to avoid documents or parts of them being leaked or so).
> And can we please patch it to stop that?
Option is there, you have also the freedom to use it.
> Indeed, the program is clearly broken by design and needs to be fixed.
The program is just following a file format in that regard AND providing the
option to not to, so nothing to be fixed.
--
Pino Toscano
Acknowledgement sent
to Adeodato Simó <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Sun, 31 May 2009 01:33:04 GMT) (full text, mbox, link).
+ John Goerzen (Sat, 30 May 2009 19:09:11 -0500):
> I'm CCing this to Debian-devel because I think it speaks to a larger
> issue.
> I just downloaded a PDF, and tried to copy and paste a bit of text
> from it. I used the selection tool, and Okular offered to speak it to
> me, but said "Copy forbidden by DRM."
> pdftotext was able to convert the entire file to text format in an
> instant.
> So what I want to know is: why are people putting code into Debian
> that limits our freedom? Why are people putting such code into KDE?
> And can we please patch it to stop that?
I see it's been pointed out in a comment in your blog post already, but
I'll mention it here for the benefit of those reading along: obeying DRM
is a configurable runtime option in Okular, so it's just a matter of
going to the preferences dialog and unchecking the "Obey DRM" check box.
Now I have no idea why it would default to obeying it (or, for that
matter, why it would have such an option). I'm CC'ing Pino whom I'm sure
will be able to help. (My guess would be that it protects upstream
against some shit or whatever, at least by their reckoning, or the
person that added it in the first place.)
Cheers,
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
Acknowledgement sent
to [email protected] (Marco d'Itri):
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Sun, 31 May 2009 01:42:02 GMT) (full text, mbox, link).
On May 31, Pino Toscano <[email protected]> wrote:
> This means the author of the PDF set that users shouldn't (in their will) copy
> the text from their PDF.
> You can disable the usage of document permissions by disabling the related
> option from the preferences.
It's not clear to me why this should not be the default, but anyway I
think that the interface could be improved by mentioning this in the
error dialog.
--
ciao,
Marco
Acknowledgement sent
to John Goerzen <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Sun, 31 May 2009 02:39:05 GMT) (full text, mbox, link).
On Sun, May 31, 2009 at 03:30:33AM +0200, Pino Toscano wrote:
> Hi,
>
> Okular maintainer (upstream, and cooperating in Debian) speaking here.
>
> > I just downloaded a PDF, and tried to copy and paste a bit of text
> > from it. I used the selection tool, and Okular offered to speak it to
> > me, but said "Copy forbidden by DRM."
>
> This means the author of the PDF set that users shouldn't (in their will) copy
> the text from their PDF.
> You can disable the usage of document permissions by disabling the related
> option from the preferences.
I checked, and do see that option. But why is it on by default? Or
even there at all?
> > So what I want to know is: why are people putting code into Debian
> > that limits our freedom? Why are people putting such code into KDE?
>
> If you feel limited in "your freedom", then go complaining about Adobe and the
> ISO 32000, aka the standardization of the PDF format, because, in case you
> don't know, those permissions are features of the PDF format,
> nothing Okular
False. I'm not running Adobe code on my system. I'm running Okular
code on my system. It is entirely within the power of the developers
of Okular to decide whether or not to implement this "feature". The
cheaper option in terms of developer time would have been to ignore
that flag.
> enforces on its own. And given that it is a feature of a file format just like
> annotations or sounds, people could use it (for example in corporate
> environments to avoid documents or parts of them being leaked or
> so).
But we all know it's trivial to work around. pdftotext will do it,
and Okular will even do it if you untick that box. It's no real
security at all. It's a bit in a file, not some sort of encryption
scheme. Why are we honoring it?
> > And can we please patch it to stop that?
>
> Option is there, you have also the freedom to use it.
It should be off by default, then, and the error message should
clearly state where to go to turn it off.
> > Indeed, the program is clearly broken by design and needs to be fixed.
>
> The program is just following a file format in that regard AND providing the
> option to not to, so nothing to be fixed.
Pfft. You are causing incompatibility with nothing if you ignore that
flag. You are causing incompatibility with things if you honor it.
What is the point to honoring it?
Acknowledgement sent
to Sune Vuorela <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Sun, 31 May 2009 10:21:12 GMT) (full text, mbox, link).
tag 531221 wontfix
thanks
On Sunday 31 May 2009 02:09:11 John Goerzen wrote:
> Package: okular
> Version: 4:4.2.2-2
> Severity: normal
>
> I'm CCing this to Debian-devel because I think it speaks to a larger
> issue.
>
> I just downloaded a PDF, and tried to copy and paste a bit of text
> from it. I used the selection tool, and Okular offered to speak it to
> me, but said "Copy forbidden by DRM."
So. you want Okular to by default help you with violating conditions of use of
the document you downloaded?
Is the next step to make Debian help more active to by default violate the
conditions of use of software?
If you download files with license issues that you don't like, I'm not sure you
should blame it on the software use to view the files.
You even have a check box to make it possible for you to violate the
conditions of use of the document if you really really want it.
> So what I want to know is: why are people putting code into Debian
> that limits our freedom? Why are people putting such code into KDE?
>
> And can we please patch it to stop that?
Why are you downloading files that limits your freedom?
(I don't like DRM, but the right way to fight it is not to ignore the terms,
but to get the people providing the content to stop using it)
/Sune
- who are putting such code into Debian.
1d488450ffb075c1d844b032952f3202faa6ff3dba9d8069f742a300bad92f99 ddtext
--
I cannot telnet to the icon, how does it work?
First from Flash MX 6.9 you should boot the front-end, so that you either need
to remove from a LCD DVD mousepad, or can never turn on the controller on the
ISA proxy over a serial 3D fan on a case over a 3-inch provider to delete a
printer.
Acknowledgement sent
to Pino Toscano <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Sun, 31 May 2009 10:21:13 GMT) (full text, mbox, link).
Hi,
> > This means the author of the PDF set that users shouldn't (in their will)
> > copy the text from their PDF.
> > You can disable the usage of document permissions by disabling the
> > related option from the preferences.
>
> I checked, and do see that option. But why is it on by default? Or
> even there at all?
Because Okular by default respect the PDF format.
Why it is there? Exactly to give you the freedom to choose, to respect both
the ideas of people who just shiver at listening the "DRM" word, and people
who make a use of that PDF "feature".
> > > So what I want to know is: why are people putting code into Debian
> > > that limits our freedom? Why are people putting such code into KDE?
> >
> > If you feel limited in "your freedom", then go complaining about Adobe
> > and the ISO 32000, aka the standardization of the PDF format, because, in
> > case you don't know, those permissions are features of the PDF format,
> > nothing Okular
>
> False. I'm not running Adobe code on my system.
You're missing the point. It is not matter of "Adobe code", but "format which
was totally in the hand of Adobe until one year ago" (when ISO 32000 was
standardized).
> It is entirely within the power of the developers
> of Okular to decide whether or not to implement this "feature".
If tomorrow a corporate person complains that Okular does not respect the PDF
format in that sense and that they cannot make use of it because of that, what
should I tell them? They would be right.
Look, having the "power of developers" does not imply developers should feel
like crackers, disabling restrictions just because they can or in the name of
some "freedom".
> The cheaper option in terms of developer time would have been to ignore
> that flag.
Speculating on what how we should had spent our time won't work, sorry.
> > enforces on its own. And given that it is a feature of a file format just
> > like annotations or sounds, people could use it (for example in corporate
> > environments to avoid documents or parts of them being leaked or so).
>
> But we all know it's trivial to work around. pdftotext will do it,
> and Okular will even do it if you untick that box. It's no real
> security at all. It's a bit in a file, not some sort of encryption
> scheme. Why are we honoring it?
Because it is part of the file format, and some people can make use of it (as
told just in the sentence you quoted)?
> > The program is just following a file format in that regard AND providing
> > the option to not to, so nothing to be fixed.
>
> Pfft. You are causing incompatibility with nothing if you ignore that
> flag. You are causing incompatibility with things if you honor it.
> What is the point to honoring it?
If everything we do cases problems, then I don't see how it is worth changing
anything.
--
Pino Toscano
Acknowledgement sent
to Josselin Mouette <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Sun, 31 May 2009 10:36:05 GMT) (full text, mbox, link).
Le dimanche 31 mai 2009 à 11:47 +0200, Pino Toscano a écrit :
> If tomorrow a corporate person complains that Okular does not respect the PDF
> format in that sense and that they cannot make use of it because of that, what
> should I tell them? They would be right.
You tell them to enable the “feature” if they want to follow the dumb
spec. But you do not bother the 99.99% of people who don’t care about
that shit.
--
.''`. Josselin Mouette
: :' :
`. `' “I recommend you to learn English in hope that you in
`- future understand things” -- Jörg Schilling
Changed Bug title to `okular: Arbitrarily enforces DRM by default' from `okular: Arbitrarily enforces DRM'.
Request was from Modestas Vainius <[email protected]>
to [email protected].
(Sun, 31 May 2009 11:12:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Stefano Zacchiroli <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Sun, 31 May 2009 12:48:03 GMT) (full text, mbox, link).
On Sun, May 31, 2009 at 02:30:58AM +0100, Adeodato Simó wrote:
> I see it's been pointed out in a comment in your blog post already,
> but I'll mention it here for the benefit of those reading along:
> obeying DRM is a configurable runtime option in Okular, so it's just
> a matter of going to the preferences dialog and unchecking the "Obey
> DRM" check box.
I've just read Pino Toscano's answer, and I found it a reasonable
choice from an *upstream author point of view*. They want okular to
fully implement the spec, to be able to sell it as a feature.
Of course, downstream distribution editors (i.e., us) can make
different choices, to better implement the philosophy of their
distro. Considering that upstream already implemented the mechanism
for choosing at runtime, I see an easy way out.
- If okular has a system-wide setting "Obey DRM" which acts as a
default for user choices, we have already won: the Debian package
maintainer is fully in charge of making the choice of what that
default should be.
- If it has not, I guess adding support for such system-wide setting
should be easy enough to do.
FWIW If I were the package maintainer, my choice would be not to "Obey
DRM" by default, but I'm not.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
Acknowledgement sent
to Modestas Vainius <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Sun, 31 May 2009 13:06:02 GMT) (full text, mbox, link).
Hello,
On 2009 m. May 31 d., Sunday 15:42:33 Stefano Zacchiroli wrote:
> - If okular has a system-wide setting "Obey DRM" which acts as a
> default for user choices, we have already won: the Debian package
> maintainer is fully in charge of making the choice of what that
> default should be.
>
> - If it has not, I guess adding support for such system-wide setting
> should be easy enough to do.
>
> FWIW If I were the package maintainer, my choice would be not to "Obey
> DRM" by default, but I'm not.
Package maintainers have already stated their decision (marked the bug
wontfix). So there is no need to keep posting to the bug report.
--
Modestas Vainius <[email protected]>
Acknowledgement sent
to John Goerzen <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Sun, 31 May 2009 13:39:04 GMT) (full text, mbox, link).
Philipp Kern wrote:
> On 2009-05-31, Mike Hommey <[email protected]> wrote:
>> Both these propositions make the "feature" pointless. The only sensible
>> options is to dump it entirely, as you are suggesting below.
>
> Actually an advisory dialog (which could be turned off) would make some sense.
> ("The author of this PDF document didn't mean to allow you $foo, do you want
> to continue anyway? Abort Continue")
>
> Then a) you are aware that there are restrictions on the document, so if
> you b) pass it on to people who cannot turn off DRM restrictions (like to
> print it for you) you can take additional action to strip DRM.
That would seem a quite reasonable compromise to me, as a default
option. You can still have a checkbox in preferences for complete
enforcement if there is somebody that really wants it, and leave it off
by default.
What do you think, Pino?
-- John
Acknowledgement sent
to John Goerzen <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Sun, 31 May 2009 13:42:14 GMT) (full text, mbox, link).
Stefano Zacchiroli wrote:
> FWIW If I were the package maintainer, my choice would be not to "Obey
> DRM" by default, but I'm not.
Interestingly enough, we patch this stuff out of xpdf already, for
presumably the same reasons. evince either never had it, or it is
patched out in Debian. I would be happy with us patching okular to
simply have a different default on Debian.
In any case, I think it was very premature to tag this wontfix. There
are many trivial things you could do to improve the situation, in order
of preference:
1) Remove the DRM feature entirely
2) Patch the default to have it disabled
3) Patch the prompt to have an "allow/deny" option
4) Patch the text to tell people where to go to turn it off
#2 and #4 especially should be exceptionally trivial patches.
Why are you tagging it wontfix, Sune?
-- John
Acknowledgement sent
to Ana Guerrero <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Sun, 31 May 2009 13:45:03 GMT) (full text, mbox, link).
On Sun, May 31, 2009 at 08:32:25AM -0500, John Goerzen wrote:
>
> In any case, I think it was very premature to tag this wontfix.
...
> Why are you tagging it wontfix, Sune?
>
I do not see this as premature at all. We, KDE maintainers, have talked
about it and we all have decided we are ok as it is now. Then tagged your
wishlist report as wonfix accordingly.
Ana
Acknowledgement sent
to [email protected] (Marco d'Itri):
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Sun, 31 May 2009 13:48:05 GMT) (full text, mbox, link).
On May 31, Sune Vuorela <[email protected]> wrote:
> So. you want Okular to by default help you with violating conditions of use of
> the document you downloaded?
Correct, this is what I would like it to do (but I use evince instead,
which by default does not bother users with this sillyness).
Users can still legally have rights even if they are forbidden by
license terms which are effectively void.
DRM deprives users of such rights.
> Is the next step to make Debian help more active to by default violate the
> conditions of use of software?
I will offer an opinion about such a situation when this will actually
be proposed. Since I do not believe in following copyright as a
religious matter I cannot provide a blanket statement on this issue.
> You even have a check box to make it possible for you to violate the
> conditions of use of the document if you really really want it.
It is being argued that it has an inconvenient default and that it is
not well documented. Properly documenting the existence of this
configuration option in the error dialog would go a long way in solving
this issue.
> Why are you downloading files that limits your freedom?
Why do you care?
> (I don't like DRM, but the right way to fight it is not to ignore the terms,
> but to get the people providing the content to stop using it)
I don't like people who think they know better than me what I need.
--
ciao,
Marco
Acknowledgement sent
to John Goerzen <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Sun, 31 May 2009 14:12:11 GMT) (full text, mbox, link).
Ana Guerrero wrote:
> On Sun, May 31, 2009 at 08:32:25AM -0500, John Goerzen wrote:
>> In any case, I think it was very premature to tag this wontfix.
> ...
>
>> Why are you tagging it wontfix, Sune?
>>
>
> I do not see this as premature at all. We, KDE maintainers, have talked
> about it and we all have decided we are ok as it is now. Then tagged your
> wishlist report as wonfix accordingly.
Could you share your reasoning with us, specifically why you don't like
each of the four options I mentioned? (Reproduced below)
1) Remove the DRM feature entirely
2) Patch the default to have it disabled
3) Patch the prompt to have an "allow/deny" option
4) Patch the text to tell people where to go to turn it off
>
> Ana
>
>
Acknowledgement sent
to John Goerzen <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Sun, 31 May 2009 14:12:12 GMT) (full text, mbox, link).
Marco d'Itri wrote:
> On May 31, Sune Vuorela <[email protected]> wrote:
>
>> So. you want Okular to by default help you with violating conditions of use of
>> the document you downloaded?
> Correct, this is what I would like it to do (but I use evince instead,
> which by default does not bother users with this sillyness).
> Users can still legally have rights even if they are forbidden by
> license terms which are effectively void.
> DRM deprives users of such rights.
While completely agreeing with you, Marco, I would like to add a couple
of points.
First off, this is just a flag, and is not really DRM in the sense we
normally understand it: some sort of encryption, etc. It is easier to
write a PDF viewer that does not honor the flag than to write one that
does, since there is no decryption or anything needed. Honoring the
flag is an optional "feature", not a prerequisite.
The other point is that the flag has nothing to do with the law. I can
perfectly well set a flag on a PDF that I generate for myself, and that
doesn't make it illegal to copy text out of the PDF I generate for
myself. Similarly, just because someone sets the flag on a PDF they
give me, doesn't make it illegal to copy text from that PDF. Copyright
law, at least in the USA, provides "fair use" rights to copy and
distribute small portions of a work. Being able to cut and paste just
makes that process slightly faster. And copyright law does not prevent
you from copying the entire thing, if you keep the result to yourself.
As, of course, cp and the KDE file manager can do (just keeping it in
the same format).
If it is illegal to do something with the document, that is orthogonal
to whether Okular obeys this flag by default, in my mind.
Okular is run by the Debian user. As our social contract states, "Our
priorities are our users and Free Software." We can, and should, take
the high road on this and make sure our users have maximum functionality
by default.
-- John
Acknowledgement sent
to Ana Guerrero <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Sun, 31 May 2009 14:21:06 GMT) (full text, mbox, link).
On Sun, May 31, 2009 at 09:05:10AM -0500, John Goerzen wrote:
> Ana Guerrero wrote:
> > On Sun, May 31, 2009 at 08:32:25AM -0500, John Goerzen wrote:
> >> In any case, I think it was very premature to tag this wontfix.
> > ...
> >
> >> Why are you tagging it wontfix, Sune?
> >>
> >
> > I do not see this as premature at all. We, KDE maintainers, have talked
> > about it and we all have decided we are ok as it is now. Then tagged your
> > wishlist report as wonfix accordingly.
>
> Could you share your reasoning with us, specifically why you don't like
> each of the four options I mentioned? (Reproduced below)
>
> 1) Remove the DRM feature entirely
>
> 2) Patch the default to have it disabled
>
> 3) Patch the prompt to have an "allow/deny" option
>
> 4) Patch the text to tell people where to go to turn it off
>
Where you offers solutions for a problem, I firstly do not see the problem.
Because for me the current default is ok. I consider this is a wishlist bug that
does not bother me at all, if it did then i might use my time in patching it
and maintaining it in the future, but it is not the case. The only thing I can
do here is telling you this is a wontfix and that is what you got.
If you get upstream adding a notice here, I will be fine with that too, and debian
will carry that.
Finally, I only took the time of answering firstly to the bug report because
I thought you deserved to know we did not ignore you issue slightly and we
packagers talked about it. But I am not going to mail further to this bug report
just to say one time and again exaclty the same...
Ana
Acknowledgement sent
to John Hasler <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Sun, 31 May 2009 14:21:09 GMT) (full text, mbox, link).
John Goerzen writes:
> 1) Remove the DRM feature entirely
Please don't call it DRM. It's just advisory locking. IMHO not enabling
it or omitting it entirely has no legal implications.
(I think it should be off by default with an option to turn it on but
that's just my irrelevant opinion. I don't use the package.)
--
John Hasler
Acknowledgement sent
to [email protected] (Marco d'Itri):
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Sun, 31 May 2009 15:00:02 GMT) (full text, mbox, link).
On May 31, John Hasler <[email protected]> wrote:
> Please don't call it DRM. It's just advisory locking. IMHO not enabling
> it or omitting it entirely has no legal implications.
It clearly has no legal implication (in jurisdictions having such a
clause, like the USA) because it is not an *effective* technological
protection measure.
--
ciao,
Marco
Acknowledgement sent
to Clint Adams <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Sun, 31 May 2009 15:00:04 GMT) (full text, mbox, link).
On Sun, May 31, 2009 at 08:32:25AM -0500, John Goerzen wrote:
> presumably the same reasons. evince either never had it, or it is
> patched out in Debian. I would be happy with us patching okular to
http://bugs.debian.org/413953
Acknowledgement sent
to Pino Toscano <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Sun, 31 May 2009 15:06:04 GMT) (full text, mbox, link).
Hi,
> 1) Remove the DRM feature entirely
This will not be done until ISO 32000 changes in that regard.
> 2) Patch the default to have it disabled
Nope.
> 3) Patch the prompt to have an "allow/deny" option
Which prompt are you speaking about?
> 4) Patch the text to tell people where to go to turn it off
The text is currently shown as an entry in the popup menu of the page view.
Setting a long text in a popup menu is a big no-no in every HIG possible.
> Why are you tagging it wontfix, Sune?
Because KDE maintainers decided to not change anything, simply.
A final remark; John Hasler (and other people) wrote:
> (I think it should be off by default with an option to turn it on but
> that's just my irrelevant opinion. I don't use the package.)
I'm just curious to know: if you don't use the package, how can you express an
opinion on it? This for sure doesn't help about the current discussion.
--
Pino Toscano
Acknowledgement sent
to Gustavo Noronha <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Sun, 31 May 2009 16:33:03 GMT) (full text, mbox, link).
On Sun, 2009-05-31 at 16:59 +0200, Pino Toscano wrote:
> A final remark; John Hasler (and other people) wrote:
> > (I think it should be off by default with an option to turn it on but
> > that's just my irrelevant opinion. I don't use the package.)
>
> I'm just curious to know: if you don't use the package, how can you express an
> opinion on it? This for sure doesn't help about the current discussion.
We, the maintainers as a collective, are building a distribution, we are
free to have (and express) opinions on whatever we want, if we believe
it may make it better, even if we do not use a specific package
ourselves. You are, of course, just as free to ignore those you don't
deem worthy. Does it make sense?
--
Gustavo Noronha <[email protected]>
Debian Project
Acknowledgement sent
to John Hasler <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Sun, 31 May 2009 17:00:03 GMT) (full text, mbox, link).
Pino Toscano writes:
> I'm just curious to know: if you don't use the package, how can you express an
> opinion on it?
I commented on the misuse of the term DRM to describe the advisory locking
that is the subject of this discussion. I added the parenthetical to make
it clear that I was not thereby endorsing the present arrangement.
BTW "Settings->Configure Ocular" offers a "Obey DRM limitations" checkbox.
This will confuse many users as the feature seems to be normally referred
to as "securing" or "locking". To most people "DRM" has to do with music
and videos.
> This for sure doesn't help about the current discussion.
I just wanted to clarify the point that this advisory locking is not DRM.
--
John Hasler
Acknowledgement sent
to John Goerzen <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Sun, 31 May 2009 18:24:06 GMT) (full text, mbox, link).
John Hasler wrote:
> Pino Toscano writes:
>> I'm just curious to know: if you don't use the package, how can you express an
>> opinion on it?
>
> I commented on the misuse of the term DRM to describe the advisory locking
> that is the subject of this discussion. I added the parenthetical to make
> it clear that I was not thereby endorsing the present arrangement.
>
> BTW "Settings->Configure Ocular" offers a "Obey DRM limitations" checkbox.
> This will confuse many users as the feature seems to be normally referred
> to as "securing" or "locking". To most people "DRM" has to do with music
> and videos.
>
>> This for sure doesn't help about the current discussion.
>
> I just wanted to clarify the point that this advisory locking is not DRM.
You are quite correct on all of it. I didn't even think to look in that
box to start with, because KDE's text referred to DRM, and where do you
ever find a DRM disable box?
Acknowledgement sent
to John Goerzen <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Sun, 31 May 2009 18:36:04 GMT) (full text, mbox, link).
tags 531221 patch
thanks
Sune Vuorela wrote:
>> 2) Patch the default to have it disabled
>
> It's a deviation from upstream that we would have to maintain for eternity.
> This issue is not important enough for me to put the extra required work into
> it
Here's the patch:
jgoerzen@katherina:/tmp/kdegraphics-4.2.2/okular/conf$ diff -d -u
okular.kcfg.orig okular.kcfg
--- okular.kcfg.orig 2009-05-31 13:27:25.310927480 -0500
+++ okular.kcfg 2009-05-31 13:27:32.258926063 -0500
@@ -148,7 +148,7 @@
</group>
<group name="General" >
<entry key="ObeyDRM" type="Bool" >
- <default>true</default>
+ <default>false</default>
</entry>
<entry key="ChooseGenerators" type="Bool" >
<default>false</default>
I don't want to be a thorn in anybody's side here, but are you seriously
telling me that this 1-word patch is too much to maintain? It's in a
default config file, not even in a .cpp or .h source file.
>> 3) Patch the prompt to have an "allow/deny" option
>
> It's a deviation from upstream that we would have to maintain for eternity.
> This issue is not important enough for me to put the extra required work into
> it.
> Getting the prompt options translated and patch all translation packages is
> also not something to be easy done, please get out of your anglocentered
> world.
I'm sure that there are i18n templates elsewhere in KDE with similar
language that could be copied. It is rather fallacious of you to assume
I'm making an anglo-centric remark by suggesting a dialog be improved.
Right now it sucks for everyone. It could be made better for everyone.
> When accepting patches that upstream won't carry the maintainers have to
> maintain it forever, thru all new upstream revisions of the software. Some
> times, it can be done with quilt refresh, some times it needs a much closer
> look at the code to get to a good enough level of understanding to actually be
> able to update the patch.
First off, if upstream ever drops the patch, it is no worse than the
current situation.
Secondly, this is an incredibly trivial patch. It is changing one word
"true" to "false" in a config file. If only all the patches I had to
maintain were so simple!
-- John
Acknowledgement sent
to Ana Guerrero <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Mon, 01 Jun 2009 17:54:05 GMT) (full text, mbox, link).
On Sat, May 30, 2009 at 07:09:11PM -0500, John Goerzen wrote:
> Package: okular
> Version: 4:4.2.2-2
...
Hi John,
I hope at least you read this email and get the whole map. Why this bug
report is tagged as wontfix and why your patch won't be applied.
You have got answers from several people from the KDE team and you seemed to
stick only to the aggressive ones (i guess because they annoyed you).
okular belongs to the official KDE modules, in Debian those modules
are maintained for a variable group of people. No everybody is the same active,
and we usually have time with more and less activity. This is good because
in theory there is always somebody around, the truth is the team is always
lacking of people.
We all have very different points of view, and we almost never agree on
something, and always have to search for some compromise. This time we all
agreed on something after a lot of time, this was nice, thanks for this :D
About this option in okular, call it protection bit, DRM or whatever you want,
there are 2 options: enabled or disabled. I think this is clear for everybody.
And you have to choose one. Personally, I think there are good reasons for
having it enabled and for having it disabled, like it happens with any setting
in KDE (in some cases it is more complicated because you do not choose between
2 options, more like 10). This is usually just a technical decision, and in KDE
you always can change this options, but here it got mixed with something
social, people's feeling towards DRM or copy restrictions.
They exist and they are there, when we disagree against such laws, we should
try to not get them in our respective countries (if you are lucky enough to
live in a democratic country).
We tend to respect upstream's defaults, this is important for consistency across
distros, and we patch only what is needed for fixing big bugs or integration
with the Debian system (in the sense of using proper paths for stuff, libraries
that are somehow different in debian, changes for archs we support, ...).
I think we are one of the distros that is patching less.
I am sorry, but I am not going to change a default because you think something
should be differently. I also think that having konsole by default with limited
scroll is a bad idea and i do not patch away. I do not feel empowered to decide
what is better or worse for the users, so I will keep upstream defaults except
when there is a good reason for change them, and there is not good reason here.
I think this copy restrictions stuff could be improved in okular itself, because
software _always_ can be improved, but I do not know how. So if you have a good
idea, report it upstream. If the idea is good, okular authors will be glad to
improve their software. Debian will carry with that.
Finally, today I have seen you quoting in IRC the usual "Our priorities are our
users and free software". John, if you are really worried about our users, you
should wonder why Debian skip the release 4.2.3 of KDE or if your KDE team needs
helps with upcoming 4.3. That will serve all of the users.
Ana
Acknowledgement sent
to John Goerzen <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Mon, 01 Jun 2009 18:09:03 GMT) (full text, mbox, link).
Ana Guerrero wrote:
> You have got answers from several people from the KDE team and you seemed to
> stick only to the aggressive ones (i guess because they annoyed you).
Hi Ana,
Thanks for the email.
I don't actually know who is on the KDE team. But in general, I don't
reply to posts with "I agree" because it just creates noise on the list.
If there's something I disagree with, then I may post. So I may be
agreeing with quite a few KDE team members and never know it.
> We all have very different points of view, and we almost never agree on
> something, and always have to search for some compromise. This time we all
> agreed on something after a lot of time, this was nice, thanks for this :D
DOH! <grin>
> About this option in okular, call it protection bit, DRM or whatever you want,
> there are 2 options: enabled or disabled. I think this is clear for everybody.
I don't see it that way. I think there are a multitude of options:
1) Remove the misfeature entirely (as Debian did with xpdf)
2) Change the default so it's disabled
3) Change the alert mechanism so that the user gets a dialog asking if
they want to respect the bit or copy anyway, with a chance to save the
preference for all future sessions
4) Change the text that the user sees to make it clear how to disable
the thing
5) Others, I'm sure.
Some of these are more or less appealing to me; the most appealing to me
are at the top of the list. You may sort the list differently.
> And you have to choose one. Personally, I think there are good reasons for
> having it enabled and for having it disabled, like it happens with any setting
> in KDE (in some cases it is more complicated because you do not choose between
> 2 options, more like 10). This is usually just a technical decision, and in KDE
My personal opinion, as you may gather, is that this is not a feature at
all, but anyhow...
> We tend to respect upstream's defaults, this is important for consistency across
> distros, and we patch only what is needed for fixing big bugs or integration
> with the Debian system (in the sense of using proper paths for stuff, libraries
> that are somehow different in debian, changes for archs we support, ...).
> I think we are one of the distros that is patching less.
This is an integration bug, in my mind. As far as I know, none of the
other PDF readers in Debian respect this bit by default. evince, xpdf,
pdftotext, gs, gv, etc. all ignore it. KPDF respected it, but without
any information, so I (and apparently several others) switched to evince
or xpdf thinking KPDF sucked because it wouldn't let us copy text from
documents that others would.
> I am sorry, but I am not going to change a default because you think something
> should be differently. I also think that having konsole by default with limited
This bug isn't here because *I* want it different. I've already
unchecked that box on my machines. The bug is here because:
1) The behavior is inconsistent with other PDF readers in Debian;
2) The behavior is inconsistent with the liberating ideals of Free Software;
3) The behavior is inconsistent with our social contract;
4) As it stands, it is completely non-obvious that this behavior can be
disabled, or how.
To expand on these each, a bit:
#1: I already discussed above, but I would add that whatever rationale
leads us to remove this misfeature from xpdf should also lead us to
remove it from Okular.
#2: The behavior restricts, by default, ability to manipulate a document
I possess. Freedom to use my computer to the best of its abilities is
what Free Software is all about. Restricting my abilities artificially
is opposed to that ideal.
#3: Our social contract states that our priorities are our users and
Free Software. The users of Debian are not served by an intentionally
crippled PDF reader.
#4: When a program tells you "I can't do something", especially if that
"something" contains the word "DRM", it is not at all natural to go
thinking that the program is a liar and try to find a configuration
option to override it.
Again, I don't care about it for me. I know about this now and it won't
trip me up again. But if I ran into this problem, many more people will
to, and not all of them will know how to solve it easily.
Therefore, ideally we should remove this bug. But if we can't do that,
we should at least make it easy for our users to do so. I have seen
some proposals on IRC along the lines of suggestions #3 or #4 above to
do just that.
> Finally, today I have seen you quoting in IRC the usual "Our priorities are our
> users and free software". John, if you are really worried about our users, you
> should wonder why Debian skip the release 4.2.3 of KDE or if your KDE team needs
> helps with upcoming 4.3. That will serve all of the users.
I think this is really a low insult. It feels to me like you are saying
that the work I do for Debian doesn't help our users. Frankly, I think
it's pretty clear that I do work for Debian that helps our users too; I
maintain quite a number of Haskell libraries and applications, and wrote
a number of libraries and applications from scratch that are part of the
Debian distribution. Just because my passions and skills lie in an area
apart from KDE development does not mean that I contribute nothing. I
have neither the time nor the expertise to help with KDE packaging; and
I suspect you have neither the time nor the expertise to help our
understaffed Haskell team. Let us each contribute where we can the
best, and spare the insults, please.
-- John
Acknowledgement sent
to John Goerzen <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Mon, 01 Jun 2009 18:33:03 GMT) (full text, mbox, link).
Peter Samuelson wrote:
> [Michael Banck]
>> If copying is indeed the only thing which is mediated via DRM, I agree
>> with you, but maybe the situation should get analyzed a bit and anyway,
>> we should make it easy for large organisations (public administration,
>> companies) to set a default for their users how this should work.
>
> I think the user education aspect is interesting. It is unhealthy for
> people to think the "don't copy" bit actually works; it causes them to
> make poor security decisions. Any time we can demonstrate to users
> that this bit is purely advisory, it helps everyone. (Well... everyone
> except those who, when shown the shortcomings of the "trusted client"
> security model, believe the solution is to get rid of untrustworthy
> clients.)
Yep, an in fact some people were discussing such a solution on IRC as
well. There was some indication it might be accepted.
-- John
Acknowledgement sent
to Modestas Vainius <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Mon, 01 Jun 2009 19:00:07 GMT) (full text, mbox, link).
Hello,
On 2009 m. June 1 d., Monday 21:07:21 John Goerzen wrote:
> I don't actually know who is on the KDE team. But in general, I don't
> reply to posts with "I agree" because it just creates noise on the list.
> If there's something I disagree with, then I may post. So I may be
> agreeing with quite a few KDE team members and never know it.
You seem to think somebody from KDE team shares your POV. Although Ana's mail
made it pretty clear, *nobody* from KDE team agrees with you (and have pretty
strong feelings about it). Everybody is fine with current default option and
overall situation in a sense that nobody supports locally patching okular to
solve your pet bug. You do not have to agree with us but please respect
opinion of others who happen to have the last word on this issue.
--
Modestas Vainius <[email protected]>
Acknowledgement sent
to Gunnar Wolf <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Thu, 04 Jun 2009 13:27:02 GMT) (full text, mbox, link).
John Goerzen dijo [Sun, May 31, 2009 at 08:24:17AM -0500]:
> > Actually an advisory dialog (which could be turned off) would make some sense.
> > ("The author of this PDF document didn't mean to allow you $foo, do you want
> > to continue anyway? Abort Continue")
> >
> > Then a) you are aware that there are restrictions on the document, so if
> > you b) pass it on to people who cannot turn off DRM restrictions (like to
> > print it for you) you can take additional action to strip DRM.
>
> That would seem a quite reasonable compromise to me, as a default
> option. You can still have a checkbox in preferences for complete
> enforcement if there is somebody that really wants it, and leave it off
> by default.
>
> What do you think, Pino?
I have seen arguments on this (very long) thread by Pino and other
members of the KDE team regarding the undeniable disadvantage of
having to maintain a patch basically forever. I have not seen
indication of this mailing reaching the upstream developers for Okular
— Yes, Pino is addressed at a @kde.org, but I understand he is
addressed as he is listed as the Debian maintainer for Okular. Has
this suggestion been pushed upstream? Don't you think we would do a
greater service to the KDE users if we convinced the authors instead
of just the Debian maintainers? (or at least, if we listened at their
arguments as well)
Greetings,
--
Gunnar Wolf - [email protected] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Acknowledgement sent
to Alan BRASLAU <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Fri, 28 Jan 2011 10:21:04 GMT) (full text, mbox, link).
Acknowledgement sent
to Frederik Schwarzer <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Fri, 28 Jan 2011 10:51:03 GMT) (full text, mbox, link).
Did you read the whole discussion?
All opinions were stated and a decision was made.
What is there still to be done from your point of view?
On 28/01/2011, Alan BRASLAU <[email protected]> wrote:
> Over one year+ and still "Will not fix".
> Is this Debian??
>
> Alan
>
>
>
> --
> To UNSUBSCRIBE, email to [email protected]
> with a subject of "unsubscribe". Trouble? Contact
> [email protected]
> Archive: http://lists.debian.org/[email protected]
>
>
Acknowledgement sent
to Alan BRASLAU <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Fri, 28 Jan 2011 12:03:06 GMT) (full text, mbox, link).
On Friday 28 January 2011 11:48:43 Frederik Schwarzer wrote:
> Did you read the whole discussion?
> All opinions were stated and a decision was made.
> What is there still to be done from your point of view?
>
> On 28/01/2011, Alan BRASLAU <[email protected]> wrote:
> > Over one year+ and still "Will not fix".
> > Is this Debian??
> >
> > Alan
I read all of the opinions in the long thread.
But I saw little respect or weight given to Debian's
very reason for existence. ALL the justifications for
"won't fix" are not Debian-ian.
Alan
Acknowledgement sent
to Frederik Schwarzer <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Fri, 28 Jan 2011 12:36:03 GMT) (full text, mbox, link).
> I read all of the opinions in the long thread.
> But I saw little respect or weight given to Debian's
> very reason for existence. ALL the justifications for
> "won't fix" are not Debian-ian.
Well, there are clearly at least two opinions about that.
I see it this way:
1) there is a standard, so it's nothing the Okular guys invented.
2) the argument, this limitation endangers our freedon also stands for
the GPL. It clearly endangers my freedom to just sell the software
modified without opening the sources. I mean ... why do I not have the
freedom to do that?
Well, I do not want to do it but this discussion reminds me a bit of
some GPL haters that also argue it is a restrictive and thus non-free
license because of the "limitations".
We want all the world to respect our GPL limitations to keep things
free. So we should respect other people's right to restrict their
works. If you disagree, discuss it with the author who applied that
limitation.
As a disclaimer: I am neither a KDE packager nor an Okular developer,
so it's just another opinion.
Acknowledgement sent
to Kevin Krammer <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Fri, 28 Jan 2011 12:51:06 GMT) (full text, mbox, link).
Aside from the already mentioned options, anyone who'd like to have a
different default on their systems (globally for all users) can simply create
a minimal Okular config with that parameter set to false.
I.e. creating a file /usr/share/kde4/config/okularrc or
/usr/local/share/config/okularrc with the following content
[General]
ObeyDRM=false
Cheers,
Kevin
Acknowledgement sent
to Alan BRASLAU <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Fri, 28 Jan 2011 13:45:07 GMT) (full text, mbox, link).
On Friday 28 January 2011 13:46:06 Kevin Krammer wrote:
> Aside from the already mentioned options, anyone who'd like to have a
> different default on their systems (globally for all users) can simply
> create a minimal Okular config with that parameter set to false.
>
> I.e. creating a file /usr/share/kde4/config/okularrc or
> /usr/local/share/config/okularrc with the following content
>
> [General]
> ObeyDRM=false
>
> Cheers,
> Kevin
Thank you, this is useful, perhaps better than the other already mentioned
options. And I note in passing that I do not find any documentation concerning
okularrc, not even a man page.
This entire discussion is rather old, going way back, and I am surprised by
okular for re-inventing a problem.
Alan
Acknowledgement sent
to Kevin Krammer <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Fri, 28 Jan 2011 13:51:06 GMT) (full text, mbox, link).
On Friday, 2011-01-28, Alan BRASLAU wrote:
> Thank you, this is useful, perhaps better than the other already mentioned
> options. And I note in passing that I do not find any documentation
> concerning okularrc, not even a man page.
/usr/share/kde4/config.kcfg/okular.kcfg
Cheers,
Kevin
Acknowledgement sent
to Sami Liedes <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Qt/KDE Maintainers <[email protected]>.
(Fri, 28 Jan 2011 13:57:06 GMT) (full text, mbox, link).
On Fri, Jan 28, 2011 at 01:32:42PM +0100, Frederik Schwarzer wrote:
> We want all the world to respect our GPL limitations to keep things
> free. So we should respect other people's right to restrict their
> works. If you disagree, discuss it with the author who applied that
> limitation.
There's a crucial difference. GPL is based in copyright law, so others
cannot choose under law whether to respect the copyright. However no
law gives the PDF authors the alleged right to restrict its use in
this way. There are very specific rights equally recognized by law,
like some fair use rights, that DRM restrictions tend to hinder.
There's also the very important difference between being legally
forbidden from doing something and being technically prevented from
doing it (whether doing it would be legal or not - and in most cases
printing a PDF where this stupid DRM bit is set would still be legal).
So DRM in software means it's intentionally crippled for the users,
preventing them from exercising even their very rights under the law.
That's not something to support.
Not that I consider this a major issue, because there's the
configuration option.
Sami
Acknowledgement sent
to "Interfax Service" <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian/Kubuntu Qt/KDE Maintainers <[email protected]>.
(Mon, 26 Oct 2015 17:33:03 GMT) (full text, mbox, link).
Acknowledgement sent
to "FedEx Standard Overnight" <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian/Kubuntu Qt/KDE Maintainers <[email protected]>.
(Wed, 24 Aug 2016 07:42:04 GMT) (full text, mbox, link).
Acknowledgement sent
to "FedEx International Next Flight" <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian/Kubuntu Qt/KDE Maintainers <[email protected]>.
(Fri, 02 Sep 2016 14:36:03 GMT) (full text, mbox, link).
Acknowledgement sent
to "FedEx International Ground" <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian/Kubuntu Qt/KDE Maintainers <[email protected]>.
(Thu, 22 Sep 2016 14:18:04 GMT) (full text, mbox, link).
Acknowledgement sent
to "FedEx International Ground" <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian/Kubuntu Qt/KDE Maintainers <[email protected]>.
(Wed, 28 Sep 2016 23:09:03 GMT) (full text, mbox, link).
HELLO, Går du igennem økonomiske vanskeligheder, eller du har brug for
et presserende lån for at forbedre din forretningsstandard. ... Vi
tilbyder også både personlige lån, virksomhedslån, realkreditlån,
studielån og payday lån.
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.