On Fri, 2 May 2014 21:29:34 +0200, Bas Wijnen
wrote:
>On Fri, May 02, 2014 at 09:21:15PM +0200, Svante Signell wrote:
>> Does the Debian guidelines give any hints on who is responsible to
>> report a patch upstream? Is it the bug submitters or the Debian package
>> maintainers responsibility (in a
Am Freitag, den 02.05.2014, 01:26 +0200 schrieb Jordi Mallach:
> Below is a report from the recently held systemd + GNOME sprint in
> Antwerp. Enjoy!
o_O Impressive productivity, keep up the great work!
Thank you all!
- Fabian
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.or
On Sat, 2014-05-03 at 11:48 +0800, Paul Wise wrote:
> On Sat, May 3, 2014 at 3:21 AM, Svante Signell wrote:
>
> > Does the Debian guidelines give any hints on who is responsible to
> > report a patch upstream? Is it the bug submitters or the Debian package
> > maintainers responsibility (in additi
Hi,
Thorsten Glaser:
> Did you *read* how upstream answered the one thing I *did* forward
> myself?
>
For the benefit of the other readers here, would you please supply a
reference URL?
> exceptions: a truly awful implementation of quite a nice idea.
> just about the worst way you could do som
Package: wnpp
Severity: wishlist
Owner: Navaneeth K N
* Package name: libvarnam
Version : 3.1.3
Upstream Author : Navaneeth K N
* URL : http://www.varnamproject.com/
* License : MIT
Programming Lang: C
Description : “Varnam” is an open source, cross pl
Le dimanche, 4 mai 2014, 02.14:17 peter green a écrit :
> Personally I'd add a (build-)depends on the relicensed gmp in the next
> gnutls28 upload. That way packages can (build-)depend on the new
> gnutls and be assured of getting a GPLv2 compatible version.
For cups, as it doesn't build-depend on
On Sun, May 4, 2014 at 12:55 AM, Matthias Urlichs wrote:
> Hi,
>
>> > 212 was released in March. Why not package that?
>>
> Not having been there, I would guess that packaging 208 had already begun
> before the sprint, and thus should be completed and reasonably bug-free
> before going forward to
Matthias Urlichs dixit:
>Thorsten Glaser:
>> Did you *read* how upstream answered the one thing I *did* forward
>> myself?
>>
>For the benefit of the other readers here, would you please supply a
>reference URL?
Sure: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728053
>> exceptions: a tru
The "Artistic" link go to the Perl license text.
The Artistic License isn't a free license (non-defined definitions such
as "C or Perl subroutines" make it invalid and potentially proprietary,
FSF is right when they says "is too vague for talk about free").
--
To UNSUBSCRIBE, email to debian-dev
I think we shouldn't support proprietary software creaters, and we
should warn proprietary software users about proprietary software
unethicality (this does not mean that we will not help users proprietary
software but just that we warn of dangers. howewer, we will not help
proprietary software cre
On 04/05/2014 13:59, Solal wrote:
> I think we shouldn't support proprietary software creaters, and we
> should warn proprietary software users about proprietary software
> unethicality (this does not mean that we will not help users proprietary
> software but just that we warn of dangers. howewer,
[GR2004-2] have nothing to do with it.
My proprosition is just warn about proprietary software dangers, but
users would still install non-free software from repositories, get help
from developers, etc. But they are warned.
Le 04/05/2014 14:20, Jean-Christophe Dubacq a écrit :
> On 04/05/2014 13:59
Hi,
2014-05-04 14:24:16 Solal:
> [GR2004-2] have nothing to do with it.
> My proprosition is just warn about proprietary software dangers, but
> users would still install non-free software from repositories, get help
> from developers, etc. But they are warned.
The installer already asks whether
On Sun, May 04, 2014 at 09:14:50AM +0200, Marc Haber wrote:
> >I don't think this is very clear from the guidelines, and I have had mixed
> >responses from maintainers when reporting upstream bugs, varying from
> >"thanks,
> >I'll report it upstream for you" to "stop wasting my time, report it ups
On 05/03/2014 03:21 AM, Svante Signell wrote:
> Hi,
>
> Does the Debian guidelines give any hints on who is responsible to
> report a patch upstream? Is it the bug submitters or the Debian package
> maintainers responsibility (in addition to eventually apply them to the
> packages)?
The first one
On 04/05/2014 14:24, Solal wrote:
> [GR2004-2] have nothing to do with it.
> My proprosition is just warn about proprietary software dangers, but
> users would still install non-free software from repositories, get help
> from developers, etc. But they are warned.
>
> Le 04/05/2014 14:20, Jean-Chr
I speak about Point 1 : "We will help creaters and users of both free
and non-free software".
Help creaters of non-free software is unethical.
Don't support non-free software creaters and don't help them is freedom
protective.
Proprietary software is unethical and I see no reason to help unethical
+++ Solal [2014-05-04 17:11 +0200]:
> Proprietary software is unethical and I see no reason to help unethical
> things.
So why are you apparently posting from a Mac?
Hard to get much more unethical (in legal business) than Apple,
IMHO. I do hope you didn't give them any money.
(and you are sti
Quoting Bas Wijnen (2014-05-04 16:33:08)
> On Sun, May 04, 2014 at 09:14:50AM +0200, Marc Haber wrote:
>>>I don't think this is very clear from the guidelines, and I have had
>>>mixed responses from maintainers when reporting upstream bugs,
>>>varying from "thanks, I'll report it upstream for you
On Sun, 4 May 2014 16:33:08 +0200, Bas Wijnen
wrote:
>On Sun, May 04, 2014 at 09:14:50AM +0200, Marc Haber wrote:
>> >I don't think this is very clear from the guidelines, and I have had mixed
>> >responses from maintainers when reporting upstream bugs, varying from
>> >"thanks,
>> >I'll report i
Am 04.05.2014 00:55, schrieb Matthias Urlichs:
> Hi,
>
>>> 212 was released in March. Why not package that?
>>
> Not having been there, I would guess that packaging 208 had already begun
> before the sprint, and thus should be completed and reasonably bug-free
> before going forward to yet another
Il giorno ven, 02/05/2014 alle 15.53 +1000, Brian May ha scritto:
> [...]
>
> Alternatively, django-pipeline could be modified to conflict with
> python-pipeline. This would allow closing the grave bug report, but
> seems wrong.
>
Sorry if this is trivial to all of you... (but it's not mentione
previously on this list Michael Biebl contributed:
> Anyone interested in keeping standalone logind working is invited to
> help the systemd-shim maintainer to implement and test this
> functionality (it will most likely be using cgmanager for that as far as
> I heard). Having v208 out is a prereq
On Sun, May 04, 2014 at 02:55:21PM +0200, Timo Weingärtner wrote:
> 2014-05-04 14:24:16 Solal:
> > [GR2004-2] have nothing to do with it.
> > My proprosition is just warn about proprietary software dangers, but
> > users would still install non-free software from repositories, get help
> > from dev
On Sun, May 04, 2014 at 01:59:09PM +0200, Solal wrote:
> I think we shouldn't support proprietary software creaters
Who's 'we'?
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.
Package: wnpp
Severity: wishlist
Owner: Rafael Laboissiere
* Package name: octave-ltfat
Version : 1.4.4
Upstream Author : Peter L. Soendergaard
* URL : http://ltfat.sourceforge.net/
* License : GPL-3+
Programming Lang: Octave/C++
Description : Large
On May 04, Kevin Chadwick wrote:
> packages. I know our systems have no functional use for systemd-logind
> and yet lots seems to depend on it but it is less clear what depends on
> which parts and so why each of the many packages do so. Whilst avoiding
If something depends on it then it means th
Hello everybody,
I am preparing the next update of mime-support, and I am going through old
issues, considering if and how to solve them.
In http://bugs.debian.org/314952 it has been proposed to print a warning when
update-mime is run and a line in /etc/mailcap.order refers to a package that
does
El Sun, 4 de May 2014 a las 4:24 PM, Marco d'Itri
escribió:
On May 04, Kevin Chadwick wrote:
packages. I know our systems have no functional use for
systemd-logind and yet lots seems to depend on it but it is less
clear what depends on which parts and so why each of the many
packages do so
On May 05, Cameron Norman wrote:
> Example one: someone does not need logind, but removing it would remove
> their init system.
So do not try to do it.
> Example two: someone needs logind, but they do not need binfmt, nspawn, or
> networkd. Removing any of those would remove the init system, the
El Sun, 4 de May 2014 a las 5:59 PM, Marco d'Itri
escribió:
On May 05, Cameron Norman wrote:
Example one: someone does not need logind, but removing it would
remove
their init system.
So do not try to do it.
Constructive solution you have got there.
Example two: someone needs logind
Solal writes:
> The "Artistic" link go to the Perl license text.
> The Artistic License isn't a free license (non-defined definitions such
> as "C or Perl subroutines" make it invalid and potentially proprietary,
> FSF is right when they says "is too vague for talk about free").
The Artistic lic
Hello again,
I have one more question to ask related to mime-support and mailcap files.
Packages can install mailcap entries in /usr/lib/mime/packages/, which are
collected by update-mime from the mime-support via Dpkg triggers, and used
to produce the file /etc/mailcap, together with the informa
On Mon, May 05, 2014 at 01:28:44AM -0007, Cameron Norman wrote:
> This is incredibly unfair to those components' competitors because it is not
> a fair playing field.
We are not having a sports competition here.
--
WBR, wRAR
signature.asc
Description: Digital signature
34 matches
Mail list logo
