Re: A question about patches for upstream

[Marc Haber]

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 addition to eventually apply them to the
>> packages)?
>
>I don't think this is very clear from the guidelines, and I have had mixes
>responses from maintainers when reporting upstream bugs, varying from "thanks,
>I'll report it upstream for you" to "stop wasting my time, report it upstream
>instead".

While I find the latter reaction a nuisance, I understand that
maintainers of huge packages with an understaffed maintainer team tend
to do that. The situation is less than nice, but I'd rather see
maintainers' time spent on packaging in those cases.

>One of the main reasons I use a distribution (Debian) instead of installing
>things from upstream is that I have a single point of contact for bug reports,
>and don't need to register in several different bug tracking systems.
>Providing this service to our users is IMO one of the tasks of a maintainer.
>Needless to say, I'm not amused by the "report this upstream" response.  But
>the fact that I get it shows that this point of view is not shared by everyone.

Agreed.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1wgqdo-0007ax...@swivel.zugschlus.de

Re: Bits from the systemd + GNOME sprint

[Fabian Greffrath]

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.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1399187611.9795.0.camel@kff50

Re: A question about patches for upstream

[Svante Signell]

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 addition to eventually apply them to the
> > packages)?
> 
> Is this in relation to a particular package or situation?

No it is not. The most convenient way to get patches reviewed/accepted
upstream is that the maintainer does this since he/she is normally
subscribed and follows their mailing/bug report lists. As a bug
submitter including patches this can be very cumbersome to do if you
have more than a only a few packages reported.

Regarding the response from Debian maintainers to patches it varies a
lot: Many just don't react at all, some advise to go upstream
with/without applying them to the package, some apply patches and don't
report upstream and some do both apply and report upstream.

Then we have to distinguish which parts are relevant to upstream, some
parts are Debian specific, some are upstream material but should stay
Debian specific and some are pure upstream.

I think a good compromise solution is that the Debian maintainers at
least acknowledge the reports and give feedback to the bug submitter
(containing all kind of responses). This applies also to wishlist bug
reports asking to package a new release giving the reason for doing/not
doing that. A lot of packages are far behind upstream, even in
experimental.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1399190323.8487.44.camel@PackardBell-PC

Re: A question about patches for upstream

[Matthias Urlichs]

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 something like that, afaic.
>  it's like anti-design.   that too… may I quote you on that?
>  sure, tho i doubt anyone will listen ;)

I agree that they're somewhat like democracy -- pretty bad,
but all other possible solutions are worse.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140504084048.gb17...@smurf.noris.de

Bug#746947: ITP: libvarnam -- “Varnam” is an open source, cross platform transliterator for Indian languages

[Navaneeth K N]

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 platform
transliterator for Indian languages

Varnam provides a set of API functions to other applications so that they can
get predictive indic input on their applications. The package comes with a
library, and a command line utility to use it

I am the author of the project and I can mainatin the debian packages.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140504093638.19028.49477.reportbug@nkn

Re: gnutls28 transition

[Didier 'OdyX' Raboud]

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 libgmp directly, I added the 
inverse relationship:

# libgmp-dev is not GPL-2 compatible before it's 6 release, which makes
# it also GPL-2+
Build-Conflicts: libgmp-dev (<< 2:6)

Dimitri John Ledkov wrote:
> Should we start transition to gnutls28 by default, for all packages
> that are compatible?

Yes, please.

Cheers,
OdyX


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2156746.eBzsy0u8Yc@gyllingar

Re: Bits from the systemd + GNOME sprint

[Tshepang Lekhonkhobe]

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 yet another version with (probably) its own issues.


That was my guess, but I didn't want to speculate, just in case there
are issues with later versions, for example.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caa77j2awzdoysdljhybjn5uueufiezsekccbshbsquw...@mail.gmail.com

Re: A question about patches for upstream

[Thorsten Glaser]

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 truly awful implementation of quite a nice idea.
>>  just about the worst way you could do something like that, afaic.
>>  it's like anti-design.   that toob>  sure, tho i 
>> doubt anyone will listen ;)
>
>I agree that they're somewhat like democracy -- pretty bad,
>but all other possible solutions are worse.

No, explicit C error handling, once you standardise on one
way of signalling errors (ideally, 0 = okay, !0 = error),
bears the other methods.

But let’s not become even more off-topic ☻

bye,
//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/pine.bsm.4.64l.1405041017460.18...@herc.mirbsd.org

Error in the Debian Social Contract

[Solal]

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-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5366293a.4030...@me.com

Point 1 of Social Contract

[Solal]

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 creaters).

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53662b8d.7060...@me.com

Re: Point 1 of Social Contract

[Jean-Christophe Dubacq]

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, we will not help
> proprietary software creaters).
> 
> [[[ To any NSA and FBI agents reading my email: please consider]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

This is your idea. However, as shown by [GR2004-2], this is not the
opinion of the project.

[GR2004-2]: http://www.debian.org/vote/2004/vote_002

Sincerely,
-- 
Jean-Christophe Dubacq



signature.asc
Description: OpenPGP digital signature

Re: Point 1 of Social Contract

[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.

Le 04/05/2014 14:20, Jean-Christophe Dubacq a écrit :
> 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, we will not help
>> proprietary software creaters).
>>
>> [[[ To any NSA and FBI agents reading my email: please consider]]]
>> [[[ whether defending the US Constitution against all enemies, ]]]
>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
> This is your idea. However, as shown by [GR2004-2], this is not the
> opinion of the project.
> 
> [GR2004-2]: http://www.debian.org/vote/2004/vote_002
> 
> Sincerely,
> 



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53663170.1060...@me.com

Re: Point 1 of Social Contract

[Timo Weingärtner]

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 to enable non-free repositories. Perhaps 
the warning could be more verbose differentiating between open-source-but-non-
free (GFDL etc.) and closed-source.


Greetings
Timo

signature.asc
Description: This is a digitally signed message part.

Re: A question about patches for upstream

[Bas Wijnen]

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 upstream
> >instead".
> 
> While I find the latter reaction a nuisance, I understand that
> maintainers of huge packages with an understaffed maintainer team tend
> to do that. The situation is less than nice, but I'd rather see
> maintainers' time spent on packaging in those cases.

Yes, I can understand that maintainers set their priorities; I do that myself
as well.  The problem I have with the latter is not that I should report it
upstream (it's not ideal, but understandable), but the "stop wasting my time"
part, which implies that I'm wrong to send reports about upstream bugs to
Debian maintainers in general.

Thanks,
Bas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140504143308.gg10...@fmf.nl

Re: A question about patches for upstream

[Thomas Goirand]

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 who does it wins. :)

Thomas

P.S: Bonus point for a notice about the upstream report in the BTS, with
the appropriate "upstream" tag and upstream BTS URL.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/536651ef.6070...@debian.org

Re: Point 1 of Social Contract

[Jean-Christophe Dubacq]

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-Christophe Dubacq a écrit :
>> 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, we will not help
>>> proprietary software creaters).
>>>
>>> [[[ To any NSA and FBI agents reading my email: please consider]]]
>>> [[[ whether defending the US Constitution against all enemies, ]]]
>>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>
>> This is your idea. However, as shown by [GR2004-2], this is not the
>> opinion of the project.
>>
>> [GR2004-2]: http://www.debian.org/vote/2004/vote_002
>>

Please do not top-post if possible.

I'd rather not annoy our users more than the current warning about
enabling non-free at install time. However, this warning may be
rewritten if the project feels it is not informative enough.

However, your proposition also has the sentence "we shouldn't support
proprietary software creaters". This is subject to many interpretations.
The first interpretation that comes to my mind is in contradiction with
point 5 of the Debian social contract (for example in "Thus, although
non-free works are not a part of Debian, we support their use and
provide infrastructure for non-free packages").

As for other interpretations, the project generally does not distinguish
between uses of the software, be it for creating free software, curing
cancer, being evil, or worse: creating non-free software. Not supporting
proprietary software creaters would probably, in some of these
interpretations, require considering not allowing Debian to be used for
non-free software, which would bar us from using almost all currently
DFSG-free software. Is that what you meant by "we shouldn't support
proprietary software creaters"? Because providing them our wonderful
distribution is supporting them.

Sincerely,
-- 
Jean-Christophe Dubacq



signature.asc
Description: OpenPGP digital signature

Re: Point 1 of Social Contract

[Solal]

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
things.

Le 04/05/2014 17:07, Jean-Christophe Dubacq a écrit :
> 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-Christophe Dubacq a écrit :
>>> 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, we will not help
 proprietary software creaters).

 [[[ To any NSA and FBI agents reading my email: please consider]]]
 [[[ whether defending the US Constitution against all enemies, ]]]
 [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>>
>>> This is your idea. However, as shown by [GR2004-2], this is not the
>>> opinion of the project.
>>>
>>> [GR2004-2]: http://www.debian.org/vote/2004/vote_002
>>>
> 
> Please do not top-post if possible.
> 
> I'd rather not annoy our users more than the current warning about
> enabling non-free at install time. However, this warning may be
> rewritten if the project feels it is not informative enough.
> 
> However, your proposition also has the sentence "we shouldn't support
> proprietary software creaters". This is subject to many interpretations.
> The first interpretation that comes to my mind is in contradiction with
> point 5 of the Debian social contract (for example in "Thus, although
> non-free works are not a part of Debian, we support their use and
> provide infrastructure for non-free packages").
> 
> As for other interpretations, the project generally does not distinguish
> between uses of the software, be it for creating free software, curing
> cancer, being evil, or worse: creating non-free software. Not supporting
> proprietary software creaters would probably, in some of these
> interpretations, require considering not allowing Debian to be used for
> non-free software, which would bar us from using almost all currently
> DFSG-free software. Is that what you meant by "we shouldn't support
> proprietary software creaters"? Because providing them our wonderful
> distribution is supporting them.
> 
> Sincerely,
> 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/536658a7.1090...@me.com

Re: Point 1 of Social Contract

[Wookey]

+++ 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 still top-posting. Don't).

There are also many more useful things you could do for Debian than
tell us that we are doing it all wrong on this list.

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140504152909.gz29...@stoneboat.aleph1.co.uk

Re: A question about patches for upstream

[Jonas Smedegaard]

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" to "stop 
>>>wasting my time, report it upstream instead".
>>
>> While I find the latter reaction a nuisance, I understand that 
>> maintainers of huge packages with an understaffed maintainer team 
>> tend to do that. The situation is less than nice, but I'd rather see 
>> maintainers' time spent on packaging in those cases.
>
> Yes, I can understand that maintainers set their priorities; I do that 
> myself as well.  The problem I have with the latter is not that I 
> should report it upstream (it's not ideal, but understandable), but 
> the "stop wasting my time" part, which implies that I'm wrong to send 
> reports about upstream bugs to Debian maintainers in general.

I believe following https://www.debian.org/Bugs/Reporting should *never* 
be a waste of time.  Annoying, maybe, but not "waste of time".

Bugs reported twice or without sufficient data may be waste of time - 
response should then be to point to kindle point to the documented 
procedures for bugreporting (either the generic one or a more specific 
one for the team or package),

I cannot imagine *any* example of a bug reported reported according to 
guidelines being a waste of time.

Can you provide examples of that kind of response?

Or perhaps think up an example to spark my imagination (and this 
discussion)?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: A question about patches for upstream

[Marc Haber]

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 it upstream for you" to "stop wasting my time, report it 
>> >upstream
>> >instead".
>> 
>> While I find the latter reaction a nuisance, I understand that
>> maintainers of huge packages with an understaffed maintainer team tend
>> to do that. The situation is less than nice, but I'd rather see
>> maintainers' time spent on packaging in those cases.
>
>Yes, I can understand that maintainers set their priorities; I do that myself
>as well.  The problem I have with the latter is not that I should report it
>upstream (it's not ideal, but understandable), but the "stop wasting my time"
>part, which implies that I'm wrong to send reports about upstream bugs to
>Debian maintainers in general.

I understand. Unfortunately, Debian has a number of developers that
are quite impolite while doing their work. In a real company, such
people would be confined to their development work and kept away from
paying customers. A win-win situation for all parties, but Debian
cannot afford that, unfortunately.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1wgzgu-0008lu...@swivel.zugschlus.de

standalone logind (Re: Bits from the systemd + GNOME sprint)

[Michael Biebl]

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 version with (probably) its own issues.

Something like that. We had already begun work on v208 and we wanted to
get this release out as soon as possible. It would have been unlikely to
get v212 ready as part of the sprint as we had a lot of other topics on
the plate as well.

Why did we want to get v208 out? Because it contains the reworked cgroup
handling which as a consequence means that a standalone logind needs
systemd or an equivalent cgroup manager for creating and managing the
cgroup hierarchies.
The current version of systemd-shim doesn't provide that
functionality/those interfaces (yet).

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 prerequisite for being able to test those
changes in systemd-shim.

We are certainly planning on having something newer then v208 for
jessie, some preliminary work has already been done for v212.

Cheers,
Michael



signature.asc
Description: OpenPGP digital signature

Re: future of python-pipeline package

[Pietro Battiston]

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 mentioned in the
RFA bug or in the "breaks" bug): the original python-pipeline was
renamed to python-grapevine.
See http://jwilk.net/software/python-grapevine

Pietro



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1399233829.30660.10.ca...@debiousci.pietrobattiston.it

Re: standalone logind (Re: Bits from the systemd + GNOME sprint)

[Kevin Chadwick]

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 prerequisite for being able to test those
> changes in systemd-shim.

Is it possible to break up systemd-services into multiple
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
segfaults is a valid reason to depend it is a bit silly when it is the
only reason code is installed for some or in some cases almost all
users. There may be less to consider for a user/admin about dependence
on the simpler or particular parts of the package for example.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___

I have no idea why RTFM is used so aggressively on LINUX mailing lists
because whilst 'apropos' is traditionally the most powerful command on
Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.

(Kevin Chadwick)

___


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/326384.15025...@smtp144.mail.ir2.yahoo.com

Re: Point 1 of Social Contract

[Philipp Kern]

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 developers, etc. But they are warned.
> The installer already asks whether to enable non-free repositories. Perhaps 
> the warning could be more verbose differentiating between open-source-but-non-
> free (GFDL etc.) and closed-source.

…and firmware.

Kind regards
philipp Kern


signature.asc
Description: Digital signature

Re: Point 1 of Social Contract

[Jonathan Dowland]

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.debian.org/20140504211504.ga8...@bryant.redmars.org

Bug#747039: ITP: octave-ltfat -- Large Time/Frequency Analysis Toolbox

[Rafael Laboissiere]

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 Time/Frequency Analysis Toolbox


This package provides a Matlab/Octave toolbox for working with 
time-frequency analysis, wavelets and signal processing. It is 
intended both as an educational and a computational tool. The toolbox 
provides a large number of linear transforms including Gabor and 
wavelet transforms along with routines for constructing windows 
(filter prototypes) and routines for manipulating coefficients.


This package will be maintained by the Debian Octave Group.

A preliminary version of the Debianized package is available at:

http://anonscm.debian.org/gitweb/?p=pkg-octave/octave-ltfat.git


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140504221103.ga20...@laboissiere.net

Re: standalone logind (Re: Bits from the systemd + GNOME sprint)

[Marco d'Itri]

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 that it really needs it.
If you do not need that something then feel free to uninstall it.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Should update-mime warn when mailcap.order contains non-matching lines ?

[Charles Plessy]

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 not provide a mailcap file in /usr/lib/mime/packages.

This would be easy to implement, but I wonder if there are people who are using
a generic /etc/mailcap.order file that contains entries for packages that are
not installed on their systems.  There, update-mime would print a warning each
time it is run, and this happens each time files change in 
/usr/lib/mime/packages
and /usr/share/applications…

Any recommendation ?  In the absence of answer, I think that I will implement
the warnings.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140505002613.gb25...@falafel.plessy.net

Re: standalone logind (Re: Bits from the systemd + GNOME sprint)

[Cameron Norman]

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. Whilst avoiding



If something depends on it then it means that it really needs it.
If you do not need that something then feel free to uninstall it.



This is flawed for many reasons.

Example one: someone does not need logind, but removing it would remove 
their init system.


Example two: someone needs logind, but they do not need binfmt, nspawn, 
or networkd. Removing any of those would remove the init system, their 
window manager, most of their desktop environment, and their login 
manager.

Re: standalone logind (Re: Bits from the systemd + GNOME sprint)

[Marco d'Itri]

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, their window
> manager, most of their desktop environment, and their login manager.
There is no need to remove any of these components even if you are not 
using them.

You are failing to understand how systemd works and is packaged.
Please come back when you will.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: standalone logind (Re: Bits from the systemd + GNOME sprint)

[Cameron Norman]

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, but they do not need binfmt, 
nspawn, or
 networkd. Removing any of those would remove the init system, their 
window

 manager, most of their desktop environment, and their login manager.

There is no need to remove any of these components even if you are 
not 
using them.



‘4’

I understand just fine how it is packaged. It is packaged in a way that 
pushes components down other's throats and tells users to simply 
disable them if they are not necessary.


This is incredibly unfair to those components' competitors because it 
is not a fair playing field. Some authors (those that do their work in 
the systemd source tree) get higher preference to others (those that 
prefer to not create a monolithic source tree, do not like systemd's 
license, do not like people to have commit access to their project 
unless they have earned it, and an array of more valid reasons).



Please come back when you will.



I feel this statement is condescending, rude, alienating, and 
dictatorial. Do not act this way toward me; I do not appreciate it.


Nos vemos,
--
Cameron

Re: Error in the Debian Social Contract

[Russ Allbery]

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 license is a free license by Debian's definition of free.
Opinions can certainly differ over whether that's the correct call, but
changing it would require a GR, and is exceptionally unlikely to happen.

Unless someone is in a position to raise a GR on the issue, there's
therefore not much point in discussing it here.  Particularly in
debian-devel, which is not really the mailing list for this topic.  Either
debian-legal or debian-project would be more appropriate, not that you're
going to get any farther there than here.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87oazdq766@windlord.stanford.edu

Dropping support for continuation lines in package mailcap files ?

[Charles Plessy]

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 information collected
from the Desktop files in /usr/share/applications.

The format of mailcap files allows for continuation lines, when the last
character of a line is a backslash that escapes the newline character.

http://tools.ietf.org/html/rfc1524 (last paragraph of page 2).

update-mime supports this passively, since is to simply copies the contents of
the files in /usr/lib/mime/packages/ as they are.  That is, they are not
parsed.

However, this leads to the following bug.  The file /etc/mailcap.order can be
used to reorder the contents of the mailcap file according to the local user's
priorities.  But this is done with line-by-line matching, and therefore, an
entry spanning two lines will be broken in two parts here and there in
/etc/mailcap.

Given that this bug has not been reported since the ~16 years that the
mailcap.order system is in place in Debian, I conclude that is at least very
rare.  Indeed, Debian packages do not seem to use continuation lines in
the mailcap entries that they install in /usr/lib/mime/packages/:

To inspect them, I listed packages of interest with the following command:

apt-file search usr/lib/mime/packages | cut -f 1 -d ':' > 
packagesWithMailcapFiles

I then used this list of packages to extract their mailcap files on 
lintian.debian.org.

for package in $(cat packagesWithMailcapFiles)
do
  for deb in /srv/mirrors/debian/pool/main/*/*/${package}_*_amd*deb
  do
dpkg-deb --fsys-tarfile $deb | tar xf - ./usr/lib/mime/packages/$package
  done
done 

I am therefore tempted to acknowledge this current practice by officially not
supporting continuation lines in the files installed in
/usr/lib/mime/packages/, instead of implementing more complex parsing.

The way I would do it would be to test for the presence of a media type
at the beginning of each line, and emit a warning otherwise.  This would
answer to http://bugs.debian.org/384161.

Please let me know if you see reasons for not doing so (and in that case,
patches are more than welcome).

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140505030300.ge25...@falafel.plessy.net

Re: standalone logind (Re: Bits from the systemd + GNOME sprint)

[Andrey Rahmatullin]

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