headers
Michelle Konzack | 1 Jun 01:15

Re: Bug#531221: okular: Arbitrarily enforces DRM

Am 2009-06-01 00:39:07, schrieb Olof Johnasson:
> This is not correct. In Europe similar laws exist. In Sweden you have
> the right to quote any published work, and after a quick search i
> found the same goes for at least France.
> 
> http://www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI000006278917
> (in french)

This is right, but what if they say, you where ongoing to pubish parts?
(violation of article 2)

Which was in my case, even if I had it in my private research database.

> IANAL, but this seems pretty clear.

In theory, but they where some newer stuff from 2007 and 2008 and  I  am
waiting  of  the  "Cour de Cassation"  (Colmar)  because  this  shit  is
blocking my enterprise entirely...

(This is WHY I transfer my enterprise back to Germany)

Thanks, Greetings and nice Day/Evening
    Michelle Konzack
    Systemadministrator
    Tamay Dogan Network
    Debian GNU/Linux Consultant

--

-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
(Continue reading)

Permalink | Reply | 0 comments |
headers
Johan Henriksson | 1 Jun 02:40

Re: Bug#531221: okular: Arbitrarily enforces DRM

Mike Hommey wrote:
> On Sun, May 31, 2009 at 03:54:29PM +0200, Sune Vuorela wrote:
>   
>> On Sunday 31 May 2009 15:32:25 John Goerzen wrote:
>>
>>
>>     
>>> #2 and #4 especially should be exceptionally trivial patches.
>>>       
>>> Why are you tagging it wontfix, Sune?
>>>       
>> I see no reason to deviate from upstream's choices here, no matter how trivial 
>> the patches are.
>>
>> Here is no bug, so here is nothing to fix.
>>
>> There is a design decision you don't like, well. Learn to live with it. 
>>
>> If upstream changes, we will follow, though.
>> Just because we *can* patch things does not mean we should.
>>
>> And I consider this debate closed, and please find a different battle field that 
>> doesn't involve me for fighting DRM.
>>     
>
> Note that consistency between the pdf readers within the distro is
> worth keeping the debate open.
>   
if we wanted consistency then we would stick to a single PDF reader and
throw out the rest. if they all work the same then what's the point in
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bernd Eckenfels | 1 Jun 02:27
Gravatar

Re: Bug#531221: okular: Arbitrarily enforces DRM

In article <20090531223907.GA16418 <at> jericho.bsnet.se> you wrote:
> This is not correct. In Europe similar laws exist. In Sweden you have
> the right to quote any published work, and after a quick search i
> found the same goes for at least France.

Same for germany. But circumventing DRM is another thing.

Gruss
Bernd
Permalink | Reply | 0 comments |
headers
John Goerzen | 1 Jun 03:14
Favicon
Gravatar

Re: Bug#531221: okular: Arbitrarily enforces DRM

Johan Henriksson wrote:
> Mike Hommey wrote:
>> On Sun, May 31, 2009 at 03:54:29PM +0200, Sune Vuorela wrote:
>>   
>>> On Sunday 31 May 2009 15:32:25 John Goerzen wrote:
>>>
>>>
>>>     
>>>> #2 and #4 especially should be exceptionally trivial patches.
>>>>       
>>>> Why are you tagging it wontfix, Sune?
>>>>       
>>> I see no reason to deviate from upstream's choices here, no matter how trivial 
>>> the patches are.
>>>
>>> Here is no bug, so here is nothing to fix.
>>>
>>> There is a design decision you don't like, well. Learn to live with it. 
>>>
>>> If upstream changes, we will follow, though.
>>> Just because we *can* patch things does not mean we should.
>>>
>>> And I consider this debate closed, and please find a different battle field that 
>>> doesn't involve me for fighting DRM.
>>>     
>> Note that consistency between the pdf readers within the distro is
>> worth keeping the debate open.
>>   
> if we wanted consistency then we would stick to a single PDF reader and
> throw out the rest. if they all work the same then what's the point in
(Continue reading)

Permalink | Reply | 1 comment |
headers
John Goerzen | 1 Jun 03:45
Favicon
Gravatar

Re: Bug#531221: okular: Arbitrarily enforces DRM

John Goerzen wrote:
> In any case, two of the three, at least (xpdf and evince) have a similar
> core.  It would be something if all three could standardize on poppler, eh?

Actually, it appears that okular also uses poppler.  But then I also
forgot the Ghostscript-based ones: gv, gs, etc.

-- John

> 
> -- John
> 
>
Permalink | Reply | 0 comments |
headers
Steve Langasek | 1 Jun 04:50
Picon
Favicon

Re: no deprecation of /usr as a standalone filesystem

On Sun, May 31, 2009 at 07:43:00PM +0200, Marco d'Itri wrote:
> This is a summary of last month's thread about the feasibility of
> removing support for /usr on a standalone filesystem.

> The issue was raised by the udev upstream maintainer along with the udev
> package maintainers of the major distributions, who all agreed that this
> configuration is not supported.

I spoke with Scott James Remnant at UDS about this, and he clarified that
Ubuntu does not support /usr *on NFS*; which is accurate, since there are
significant changes that need to be made to the out-of-the-box configuration
to get this to work.  But Ubuntu *does* support /usr on a separate
filesystem.

--

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek <at> ubuntu.com                                     vorlon <at> debian.org
Permalink | Reply | 0 comments |
headers
William Pitcock | 1 Jun 07:27
Picon

Re: fstrcmp

On Sun, 2009-05-31 at 11:04 +0200, Florian Weimer wrote:
> * Peter Miller:
> 
> > I've been considering turning my fuzzy string compare function into a
> > library.
> 
> I would certainly welcome that.
> 
> Would you be willing to relicense it under a more permissive license,
> so that we don't have to worry about OpenSSL license compatibility
> etc.?
> 
> >         /**
> >          * the fstrcmp function compare two strings, to determine how
> >          * similar two strings appear.
> >          *
> >          * @param s1
> >          *     The first of the strings to compare.
> >          * @param s2
> >          *     The second of the strings to compare.
> >          * @returns
> >          *     a number between 0.0 and 1.0; 0.0 means the strings are
> >          *     nothing alike, 1.0 means the two strings are identical.
> >          */
> >         double fstrcmp(const char *s1, const char *s2);
> 
> It could be helpful if it didn't use floating point because we support
> some systems where floating point is software-emulated.
> 
> I don't think we've got a library of C goodies.  libbsd is something
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Wise | 1 Jun 07:40
Picon
Favicon
Gravatar

stopped daemons starting again during upgrade

Hi all,

I recently did an upgrade from lenny to squeeze. I did it in single
user mode / runlevel 1 (with all the daemons stopped). I noted that
during the upgrade various daemons were started again. IMO it is
reasonable to expect that stopped daemons stay stopped during an
upgrade, expecially in runlevel 1. Does anyone else agree? Is this a
bug in each of the packages with a daemon or in the init system?

--

-- 
bye,
pabs

http://wiki.debian.org/PaulWise
Permalink | Reply | 2 comments |
headers
Felipe Sateler | 1 Jun 08:04
Picon

Vcs-Svn field and trunk

Recently I've ran into a few cases were doing debcheckout of a package using 
svn downloads the whole thing: tags, branches and trunk.  I would expect 
debcheckout to give me just the HEAD of development. What should be the sane 
behavior?

--

-- 
Felipe Sateler
Permalink | Reply | 5 comments |
headers
Paul Wise | 1 Jun 08:15
Picon
Favicon
Gravatar

Re: Vcs-Svn field and trunk

On Mon, Jun 1, 2009 at 2:04 PM, Felipe Sateler <fsateler <at> gmail.com> wrote:

> Recently I've ran into a few cases were doing debcheckout of a package using
> svn downloads the whole thing: tags, branches and trunk.  I would expect
> debcheckout to give me just the HEAD of development. What should be the sane
> behavior?

Checking out trunk sounds like reasonable behaviour, I guess file
minor bugs when you encounter this issue.

--

-- 
bye,
pabs

http://wiki.debian.org/PaulWise
Permalink | Reply | 0 comments |

Gmane