Bug#746739: ITP: x4d-icons -- X4D Icon set for various online document types

[Dimitri John Ledkov]

Package: wnpp
Owner: Dimitri John Ledkov 
Severity: wishlist

* Package name: x4d-icons
  Version : 1.2
  Upstream Author : Dimitri John Ledkov
* URL or Web page : http://x4d.surgut.co.uk
* License : MIT
  Description : X4D Icon set for various online document types

 Icon set indicating document types and target versions of those
 specifications e.g. HTML, XHTML, CSS, MathML, etc. These are metric
 compatible & naming scheme compatible with other logos used for
 similar purposes.

Regards,

Dimitri.


-- 
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/878uqjwfsg@debian.org

Re: A question about patches for upstream

[Christian PERRIER]

Quoting Russ Allbery (r...@debian.org):

> That said, the process of forwarding bugs along is sort of annoying in
> many cases and may not be a very appealing place for volunteers to spend
> their time, so I think it tends to be one of the first things that stops
> happening when maintainer teams are overloaded.

Definitely. That happens even more quickly for packages or software
where reproducting bugs is not easy when you're not the one who
reported them initially. That has been my experience with samba, where
most bugs are related to some specific setups which are not easy to
reproduce in a developer environment. Acting as a proxy between bug
submitters and upstream developers isn't very efficient most of the
time.

Still, my feeling about this is that this is *at first* the
maintainer's responsibility and at least it is his|her responsibility
to help the bug submitter in reporting upstream properly, and properly
deal with upstream.

But, of course, for complicated *and* popular *and* understaffed
packages.that can very quickly become a really tedious taskand
often the one that gets dropped if the maintenance team is overloaded.

Still, we should avoid to leave bug submitter with "please report
upstream, thanks" (and, well, I did that anyway from time to time,
myself: we're all far from perfect).



signature.asc
Description: Digital signature

Re: A question about patches for upstream

[Paul Wise]

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?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/caktje6frujmxxwsgpvipobgblomxuwa0beubiyeaqgfymnk...@mail.gmail.com

Re: Non-source Javascript files in upstream source

[Nikolaus Rath]

Paul Tagliamonte  writes:
> On Fri, May 02, 2014 at 09:20:02PM +0200, Bas Wijnen wrote:
>> Is there any disagreement about this?  As far as I've understood so far, 
>> there
>> are only two points that keep being discussed:
>> 
>> 1. Do we need to check that generated files which we don't use are actually
>>generated from the provided source?  Main example here is a configure file
>>which gets overwritten during build.
>
> Yes. Please see the email. You need to make sure you have source for
> everything. If you're not shipping the raw source (e.g. most Python), be
> sure you're making the binary in your rules file, and using that binary
> in the deb.

Ah, wait. So is the requirement that we ship the source to all files in
the source package, or is the requirement to ship the source to all
files in the source package that are used to generate the binary
package?

I always thought it was the latter, and your mail seems to say that as
well, but the original email indicates the former.

I'm still surprised that I had to start stripping out javascript files
in the Sphinx-generated documentation from upstream tarballs, despite
the documentation being completely removed and regenerated during the
build.


Best,
-Nikolaus
-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«


--
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/87r44bpmof@vostro.rath.org

Re: Non-source Javascript files in upstream source

[Charles Plessy]

Le Fri, May 02, 2014 at 09:20:02PM +0200, Bas Wijnen a écrit :
> 
> 1. Do we need to check that generated files which we don't use are actually
>generated from the provided source?  Main example here is a configure file
>which gets overwritten during build.
> 
> 2. What is source for a non-programmatic work such as a rendered bitmap of a
>3-D model, do we require source for non-programmatic works, and if not, 
> what
>defines a programmatic work?
> 
> Neither of these is clarified by their recent statement.

I totally agree: in the FTP team's statement, first there is a quote of the 
DFSG:

“The program must include source code”

but then it adds later:

”all files in source packages must come with their source as required by 
the DFSG”

This does not resolve the ambiguity in our Social Contract and the DFSG, where
sometimes we refer to a “work”, sometimes a “component” and sometimes a
“program” (and actually never to “files” in that context).

Regarding the possibility of a GR:

Most of the text of the DFSG is about judging licenses, not files.  It refers
to “programs” without defining what they are.  Points 2 (related to source
code) and 4 (related to patches) suggest that “program” refers to executables,
but this interpretation may be too naive as it does not take into account how
others defined a “program” before the DFSG were written (in the GPL: a
copyrightable work), nor it takes into account the historical discussions when
the DFSG were written.  Altogether, this calls for clarifying what a “program”
is.

Point 2 is also strange from a gramatical point of view: 

   “The program must […], and must allow distribution in source code”.

I do not think that it was written with DRMs in mind (where programs really
allow or disallow some actions), and it looks like what it intended is rather :

   “The program must […], and its license must…”.  

We could clarify the DFSG by separating the two issues (freedom by source code
and freedom by license):

 - Introduce a point 0 explaining our requirements for the presence of source
   code.

 - Replace “program must include source code, and” by “license” in point 2.

 - Either define what a “program” is in point 0, or introduce a new definition
   for “works”, and replace “program” by “work” in the remaining points.

The contents of this new point 0 are the core of the disagreemnts.

I think that GR could be useful to solve the ambiguity of the DFSG it would not
contain too many overlaping options.  For instance:

 a) Disambiguate in a way that represents a status quo regarding our current
practices.

 b) Extend our requirements for source code to explicitely include non-programs
in our source packages.

 c) Focus our requirements for source code on the binary packages and the files
necessary to rebuild them from the source packages.

People know which one is my favorite, so I will not repeat it here :)

Have a nice week-end,

-- 
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/20140503015950.ga1...@falafel.plessy.net

Re: Non-source Javascript files in upstream source

[Scott Kitterman]

On May 2, 2014 5:43:30 PM EDT, Michael Banck  wrote:
>On Fri, May 02, 2014 at 03:58:37PM -0400, Paul Tagliamonte wrote:
>> If the png was made from the svg, include the svg. 
>
>Well, it is unclear who you are adressing here.  If upstream made a
>.png
>from (prsumably) an .svg, but did not include the .svg in the tarball,
>how can the Debian maintainer include if they don't have access to it?
>
>I agree that when possible and feasable, the original source should be
>used.  
>
>I just also tend to think then when upstream includes a PDF as very
>useful documentation, and it can be decuced from the layout that this
>was done by LaTeX or LibreOffice, but the respective source files are
>missing, our users are best served by including this PDF in this case
>(if there are no overriding licensing issues on top).  
>
>It is ok to ask upstream if the maintainer wants to take that extra
>step, but I don't think it should be mandated.
>
>My 0.02 cents, anyway.

I think these are all a different case than JavaScript. JavaScript is code and 
I don't think there's much debate about the question of if code requires 
source.  The debate is primarily about if lack of non-minified JavaScript 
source is a big enough problem to be worth the effort of fixing if it's not 
used in the binary. 

The works you describe aren't code, so there is an ambiguity between DFSG and 
the social contract that creates a difference of opinion about if these require 
source at all.

I believe it's important to keep these two  issues separate in order to better 
resolve both of them. 

Scott K



-- 
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/c5a0379d-1546-49c4-920e-e03f4e771...@email.android.com

Re: A question about patches for upstream

[Matthias Klose]

Am 02.05.2014 21:21, schrieb Svante Signell:
> 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)?

For any essential packages it should be a mix of the package maintainers and the
port maintainers.  I'm usually fine to apply local patches conditionally for
some port, when these are not yet upstream, but it really should be the
responsibility of the port maintainers to keep the basic port working and submit
these patches upstream.

  Matthias


-- 
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/536435b6.4070...@debian.org

Re: Non-source Javascript files in upstream source

[Theodore Ts'o]

On Fri, May 02, 2014 at 09:20:02PM +0200, Bas Wijnen wrote:
> 
> 1. Do we need to check that generated files which we don't use are actually
>generated from the provided source?  Main example here is a configure file
>which gets overwritten during build.

For the record, the reason why I ship a configure as well as a
configure.in file with e2fsprogs is simply because I don't trust that
an arbitrary version of autoconf won't break with what I have in my
configure.in.  And I don't want to trouble-shoot some random Gentoo's
user's version of autoconf --- as far as I am concerned, the autoconf
maintainers have provided no guarantees of stability between versions,
at least none that I am willing to trust.

So I am only going to ship configure as generated by a version of
autoconf that I have personally tested as working.  And there have
been times in the past when I've simply kept an older version of
autoconf because the current version of autoconf was busted as far as
I was concerned, and I didn't have time to trouble shoot the damned
thing.

If someone starts complaining that I shipped a version of configure
that corresponded to autoconf version N, and sid just uploaded N+1,
and therefore my configure doesn't match with my configure.in, and
that's therefore a DFSG violation, I'm going to be really annoyed.

Heck, when autoconf has been busted, there have been times that
modifying the configure script directly *was* my preferred form for
making modifications

*Especially* if debian stable, testing, unstable, and experimental
might theoretically have completely different versions of autoconf,
making it fundamentally impossible to guarantee that configure is
"exactly generated" from the version of autoconf in all releases of
Debian.

There is such a thing of trying to adhere to the DFSG to the point of 
insanity

- Ted


-- 
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/20140502234708.ga11...@thunk.org

Re: Non-source Javascript files in upstream source

[Michael Banck]

On Fri, May 02, 2014 at 03:58:37PM -0400, Paul Tagliamonte wrote:
> If the png was made from the svg, include the svg. 

Well, it is unclear who you are adressing here.  If upstream made a .png
from (prsumably) an .svg, but did not include the .svg in the tarball,
how can the Debian maintainer include if they don't have access to it?

I agree that when possible and feasable, the original source should be
used.  

I just also tend to think then when upstream includes a PDF as very
useful documentation, and it can be decuced from the layout that this
was done by LaTeX or LibreOffice, but the respective source files are
missing, our users are best served by including this PDF in this case
(if there are no overriding licensing issues on top).  

It is ok to ask upstream if the maintainer wants to take that extra
step, but I don't think it should be mandated.

My 0.02 cents, anyway.


Michael


-- 
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/20140502214330.gf25...@raptor.chemicalconnection.dyndns.org

Bug#746716: ITP: gnome-main-menu -- GNOME start menu applet for MATE

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: gnome-main-menu
  Version : 1.8.0
  Upstream Author : GNOME and MATE developers
* URL : http://git.mate-desktop.org/gnome-main-menu/
* License : GPL-2+
  Programming Lang: C, C++
  Description : GNOME start menu applet for MATE

 This applet provides a "start menu" for the MATE desktop.
 .
 It features a list of favorite applications, and recently used documents.
 .
 It provides shortcuts for common system administration actions and integrates
 with network-manager for network status reporting.


NOTE about the package name:

 This project is a friendship project between the MATE developers and
 the GNOME developers and the upstream code is maintained by the MATE
 developers on git.gnome.org.
 .
 Due to this, the name gnome-main-menu has been kept, but the package
 is a package for the MATE desktop environment.
 .
 The bin:package in Debian will be named mate-gnome-main-menu-applet.


-- 
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/20140502202857.20172.52616.report...@minobo.das-netzwerkteam.de

Re: A question about patches for upstream

[Russ Allbery]

Svante Signell  writes:

> 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 we have a clear guideline on it.

The ideal, as far as I'm concerned, is for the Debian package maintainer
to forward bugs upstream.  This has multiple advantages: the package
maintainer is generally capable of producing higher quality bug reports,
they usually have a better relationship with upstream and know which bugs
should be reported and how they should be reported to be effective, they
can filter out all of the bugs that are due to Debian packaging artifacts
or local changes, and that allows us to present a unified bug reporting
interface to our users.

I consider myself responsible for forwarding to upstream all of the
upstream-relevant bug reports on my packages.  (Note that just because
I'm responsible for it doesn't mean it necessarily *happens*.  I'm also
responsible for resolving the package bugs, and yet some of them will
probably not be resolved due to lack of time and resources.)  I'm
certainly happy for anyone else's help (who can do the job properly),
including the original reporter.

That said, the process of forwarding bugs along is sort of annoying in
many cases and may not be a very appealing place for volunteers to spend
their time, so I think it tends to be one of the first things that stops
happening when maintainer teams are overloaded.

I'm not a big fan of telling users not to report bugs against Debian and
instead report them upstream, which has happened a few times.  But in the
interest of transparency, I *do* think it's a good idea for overloaded
teams who are unlikely to find the time and energy to forward relevant
bugs upstream to tell the user that and let them know that they'll
probably have to forward it themselves to have any reasonable chance at
getting the bug fixed.  That's not an ideal situation, of course, but I
think it's better to admit when we're struggling than to let the bugs
silently accumulate and leave the users wondering.

-- 
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/87mwf0hr0f@windlord.stanford.edu

Re: Non-source Javascript files in upstream source

[Paul Tagliamonte]

I'm not writing this email with my ftpteam hat on.



On whenever (I can't be bothered to actually quote, sorry :) ) Russ wrote:
> That doesn't matter for a GR.  A GR can do that with a simple
> majority.

I know, but I just want to make it absolutely clear, since I believe
the statement made covers this, and I think it presents a GR in a
different light -- just politically, even if it doesn't change the votes
needed.




On Fri, May 02, 2014 at 09:20:02PM +0200, Bas Wijnen wrote:
> Is there any disagreement about this?  As far as I've understood so far, there
> are only two points that keep being discussed:
> 
> 1. Do we need to check that generated files which we don't use are actually
>generated from the provided source?  Main example here is a configure file
>which gets overwritten during build.

Yes. Please see the email. You need to make sure you have source for
everything. If you're not shipping the raw source (e.g. most Python), be
sure you're making the binary in your rules file, and using that binary
in the deb.


> 2. What is source for a non-programmatic work such as a rendered bitmap of a
>3-D model, do we require source for non-programmatic works, and if not, 
> what
>defines a programmatic work?

Preferred form of modification. Yes, there exist edge-cases (an image
made from a photo taken of someone which had two pixels flipped after
putting it through scanner after skydiving while drawing it), but I
think good judgement here is fine.

If the png was made from the svg, include the svg. If a binary was made
from c, include the c. If a min.js was made from .js, include the js. If
a config file was made by a jinja template, include the template.

If you were to 'update' the image, how would you do it? What things
would you need? Include that. Think about what you'd need when you fork
the project.


Hopefully most maintainers can identify the preferred form of
modification on their own. If anyone has trouble, ask for help.

Debian Legal is a good place, as is the ftpteam, debian-devel or
wherever you feel most comfortable soliciting the help of others.


> Neither of these is clarified by their recent statement.

I believe they are. We require source. This applies to source packages.
If you don't have source, don't include the thing. If you have the
source, rebuild it at build time.

> > However, to put this issue to rest, the GR probably needs to amend the
> > DFSG to make it unambiguous, so a 3:1 supermajority would be a good idea
> > anyway.
> 
> That would be a good idea, but given the constant discussions and the vote in
> 2006[1], it seems doubtful whether we can get a simple majority on any point 
> of
> view in this matter.  So it might be better to at least include an option 
> which
> makes the statement without modifying the DFSG.


-- 
 .''`.  Paul Tagliamonte   |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `- http://people.debian.org/~paultag/conduct-statement.txt


signature.asc
Description: Digital signature

Re: A question about patches for upstream

[Bas Wijnen]

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

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.

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/20140502192934.gb10...@fmf.nl

Re: Non-source Javascript files in upstream source

[Bas Wijnen]

On Fri, May 02, 2014 at 11:18:33AM -0700, Russ Allbery wrote:
> Paul Tagliamonte  writes:
> > On Fri, May 02, 2014 at 06:40:26PM +0100, Ian Jackson wrote:
> 
> >> I'm starting to get tempted.  If we have a GR on it, regardless of the
> >> outcome, we can stop these arguments a bit sooner.
> 
> > Please do note that this would be a GR to override a DPL delegated
> > team's decision[1], just to be absolutely clear.

Is there any disagreement about this?  As far as I've understood so far, there
are only two points that keep being discussed:

1. Do we need to check that generated files which we don't use are actually
   generated from the provided source?  Main example here is a configure file
   which gets overwritten during build.

2. What is source for a non-programmatic work such as a rendered bitmap of a
   3-D model, do we require source for non-programmatic works, and if not, what
   defines a programmatic work?

Neither of these is clarified by their recent statement.

> However, to put this issue to rest, the GR probably needs to amend the
> DFSG to make it unambiguous, so a 3:1 supermajority would be a good idea
> anyway.

That would be a good idea, but given the constant discussions and the vote in
2006[1], it seems doubtful whether we can get a simple majority on any point of
view in this matter.  So it might be better to at least include an option which
makes the statement without modifying the DFSG.

Thanks,
Bas

[1] https://www.debian.org/vote/2006/vote_004


-- 
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/20140502192002.ga10...@fmf.nl

A question about patches for upstream

[Svante Signell]

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)?

Thanks! 


-- 
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/1399058475.8487.20.camel@PackardBell-PC

Re: Non-source Javascript files in upstream source

[Russ Allbery]

Paul Tagliamonte  writes:
> On Fri, May 02, 2014 at 06:40:26PM +0100, Ian Jackson wrote:

>> I'm starting to get tempted.  If we have a GR on it, regardless of the
>> outcome, we can stop these arguments a bit sooner.

> Please do note that this would be a GR to override a DPL delegated
> team's decision[1], just to be absolutely clear.

That doesn't matter for a GR.  A GR can do that with a simple majority.

However, to put this issue to rest, the GR probably needs to amend the
DFSG to make it unambiguous, so a 3:1 supermajority would be a good idea
anyway.

-- 
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/878uqkjb7q@windlord.stanford.edu

Re: Non-source Javascript files in upstream source

[Paul Tagliamonte]

On Fri, May 02, 2014 at 06:40:26PM +0100, Ian Jackson wrote:
> I'm starting to get tempted.  If we have a GR on it, regardless of the
> outcome, we can stop these arguments a bit sooner.

Please do note that this would be a GR to override a DPL delegated
team's decision[1], just to be absolutely clear.

Cheers,
  Paul

[1]: https://lists.debian.org/debian-devel-announce/2014/04/msg00014.html

-- 
 .''`.  Paul Tagliamonte   |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `- http://people.debian.org/~paultag/conduct-statement.txt


signature.asc
Description: Digital signature

Re: Non-source Javascript files in upstream source

[Ian Jackson]

Russ Allbery writes ("Re: Non-source Javascript files in upstream source"):
> I continue to hold to my position that distributing sourceless files in
> source packages, provided they are under a free license and not used as
> part of the process of building binary package, is a nuisance rather than
> a meaningful DFSG violation and not worth spending project time and
> resources on.  That said, I do understand why people want simple rules
> with no exceptions, even if those rules lead to moderately nonsensical
> corner cases.
> 
> I very much doubt that further discussion of this is going to change
> anyone's mind, and I suspect we will simply continue to disagree on the
> requirements until such a time as someone proposes a GR to clarify this
> (if that ever happens).  I don't care enough about the issue to do that
> myself.

I'm starting to get tempted.  If we have a GR on it, regardless of the
outcome, we can stop these arguments a bit sooner.

Ian.


-- 
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/21347.55434.940648.630...@chiark.greenend.org.uk

Bug#746693: ITP: ruby-zip-zip -- provides a simple adapter to let all your dependencies use RubyZip v1.0.0

[Praveen Arimbrathodiyil]

Package: wnpp
Severity: wishlist
Owner: Praveen Arimbrathodiyil 

* Package name: ruby-zip-zip
  Version : 0.3
  Upstream Author : Orien Madgwick
* URL : https://rubygems.org/gems/zip-zip
* License : Expat
  Programming Lang: Ruby
  Description : provides a simple adapter to let all your dependencies use 
RubyZip v1.0.0

So you've upgraded a gem dependency that requires RubyZip v1.0.0 or higher. 
While all your other dependencies use the interface provided by v0.x.

zip-zip provides a simple adapter to let all your dependencies use RubyZip 
v1.0.0. It is very simple and light weight, aliasing the old class names to the 
new.


-- 
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/20140502154832.27747.45814.report...@ravel.debian.org

Re: noexec goal for hardening Debian (was Re: Bug#746496: general: Package upgrade scripts partly fail when /tmp is noexec)

[Henrique de Moraes Holschuh]

On Fri, 02 May 2014, Thorsten Glaser wrote:
> Henrique de Moraes Holschuh dixit:
> >On Wed, 30 Apr 2014, Pierre wrote:
> >> When /tmp is configured as noexec (for example /tmp in RAM), some
> >> scripts fail on package update.
> 
> […]
> >It may look like it is working, but we don't properly support it,
> 
> Sounds like a release goal for jessie+1 or jessie+2.

No, it is useless, wasted effort.  NOEXEC $TMPDIR (and NOEXEC /tmp) will
always break the world.

There is no shortage of troublesome release goals that are worth the effort.
NOEXEC /tmp is not one of them.

E.g. it would be a lot better to, instead, adopt per-user (that can also
mean per-daemon/per-service) exclusive $TMPDIR enhanced by per-user mount
namespaces that also take care of /tmp, or something to that effect.   But
those won't be NOEXEC.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20140502151920.gb19...@khazad-dum.debian.net

Re: mass bug report filing, update of the Ruby-Version attribute is needed for jessie

[Antonio Terceiro]

On Thu, May 01, 2014 at 10:51:15PM +0200, Matthias Klose wrote:
> Currently more than 300 packages have a Ruby-Version attribute which lists
> either ruby1.8 or ruby1.9, but neither ruby2.0 or ruby2.1.  When using these
> packages as gems, then the gem is not found.  The recent ruby gems
> infrastructure now uses 'all' as this Ruby-Version attribute for architecture
> independent packages, so after an one time update these packages should be
> usable as gems for future ruby versions as well.  Most of these packages only
> build architecture independent packages, so source full uploads are needed.
> 
> Not sure if all of these packages are used as gems, but at least for these the
> bug severity should be serious, maybe less for the others.
> 
> $ cat /var/lib/apt/lists/*Packages | grep-dctrl -n -sSource:Package
> -FRuby-Versions -r 'ruby1.[89]' | sort -u | wc -l
> 366

Note that the real issue is not the contents of the Ruby-Versions field,
which is not used for anything other than this very type of checking.

The real problem is the fact that their gemspecs (distro-agnostic
metadata that tells Ruby which packages are installed) are not installed
in a place that will be picked up by newer versions of Ruby, so yes they
need a sourcefull upload, but only if they actually ship gemspecs.

Looking for packages that still ship gemspecs for 1.8 or 1.9.1, the number is
slightly lower/

$ (apt-file search /usr/share/rubygems-integration/1.8; apt-file search 
/usr/share/rubygems-integration/1.9.1) | cut -d : -f 1 | sort -u | wc -l
300

-- 
Antonio Terceiro 


signature.asc
Description: Digital signature

Multiarch and interpreters

[Niko Tyni]

On Fri, Apr 18, 2014 at 07:11:56AM +0200, Guillem Jover wrote:

> After my warning [W] about this subverting the dependency system was
> willfully ignored, I concluded trying to do anything else about it
> was a waste of time and energy.
> 
>   [W] 

It seems to me that an interpreter supporting DSO language extensions
can have multi-arch support at several different levels. I think
this classification might explain why the current python multiarch
implementation hasn't encountered the above problems.

The levels I see are

1) multiarch annotations for /usr/bin/interp, but no Multi-Arch:same
   packages. The architecture of /usr/bin/interp must match the
   architecture of any corresponding embedded interpreter packages [1]
   (containing libinterp.so.*) on the system. Packaged DSO extensions
   must obviously match this architecture too.

2) Multi-Arch:same embedded interpreter packages (with the standard
   library), but separately packaged DSO extensions can be installed
   for only one architecture at a time
- makes a somewhat wider set of non-native packages installable than 1)
  (those depending on the embedded interpreter package)
- the dependencies of DSO extension packages guarantee that their
  architecture matches the /usr/bin/interp package
- how useful are the embedded interpreters on architectures not
  matching /usr/bin/interp, when you can't install packaged DSO
  extensions for them?

3) Multi-Arch:same embedded interpreters (+stdlib), but packaged DSO 
   extensions aren't limited to one architecture (and could be
   Multi-Arch:same)
- this would be the "full" multiarch implementation
- DSO extension packages depend on the embedded interpreter packages
  (and probably on the /usr/bin/interp package without :any as
   an alternative)
- currently fragile/broken due to our dependency system limitations
  (see Guillem's link above)

I think python3 is doing 2), and ruby2.0 seems to be trying to do 3).
I'm currently contemplating whether to do 1) or 2) for perl. I'll
follow up on that in a separate mail.

I hadn't fully realized the difference between 2) and 3) until now,
so I hope this is useful for somebody else too. 

This comes from a perl background, where packaged DSO extensions depend
on perlapi-* and the perl source package could control who provides
it. Possibly the dependencies of packaged DSO extensions for other
interpreters don't have a similar point of control. I suppose that this
would make the line between 2) and 3) more blurry and call for policy
and/or helper support to avoid premature takeup on 3) before its problems
are resolved.

Does this make sense?

[1] I'm assuming that linking against libinterp.so.* is only used for
embedding an interpreter, not for utility functions or the like.
I think this is true for perl. If it doesn't hold for other
interpreters, I'd be interested in examples.
-- 
Niko Tyni   nt...@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/20140502141448.GA7566@estella.local.invalid

noexec goal for hardening Debian (was Re: Bug#746496: general: Package upgrade scripts partly fail when /tmp is noexec)

[Thorsten Glaser]

Henrique de Moraes Holschuh dixit:

>On Wed, 30 Apr 2014, Pierre wrote:

>> When /tmp is configured as noexec (for example /tmp in RAM), some
>> scripts fail on package update.

[…]
>It may look like it is working, but we don't properly support it,

Sounds like a release goal for jessie+1 or jessie+2.

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.1405021354020.22...@herc.mirbsd.org

Re: [Pkg-shadow-devel] Help wanted: test new shadow source package (login, passwd, uidmap, etc.)

[Serge Hallyn]

Quoting Steve Langasek (vor...@debian.org):
> On Fri, May 02, 2014 at 04:38:15AM +, Serge Hallyn wrote:
> > Quoting Christian PERRIER (bubu...@debian.org):
> > > Quoting Christian PERRIER (bubu...@debian.org):
> > > > Hello fellow developers,
> > > > 
> > > > I would like to request your help in testing the new version of the
> > > > shadow package (that provides login, passwd and such other important
> > > > or base packages).
> 
> > > I haven't got much feedbackwhich is indeed what I was more or less
> > > expecting. ;-)
> 
> > > So, well, let's jump into the mud (I love to do that when
> > > running.not sure I love to do that in my FLOSS activities) and
> > > I'll soon upload shadow to unstable Be prepared.
> 
> > so first glitch I found is that /etc/subuid was not created for me.
> > login.postinst only creates that on new installs.  In Ubuntu it
> > does so anytime it does not exist - I assume you made that change
> > on purpose?  usermod -v refuses to run if the file does not exist,
> > so users will need to be told to create those files themselves.
> 
> The right answer is probably to create the file on new installs and on
> upgrades from versions earlier than the first version introducing this.

Yeah I was thinking that last night - i guess this is pretty easy to
do, and some people will not want to have those files.


-- 
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/20140502133823.GC1760@ubuntumail

Re: [Pkg-shadow-devel] Help wanted: test new shadow source package (login, passwd, uidmap, etc.)

[Serge Hallyn]

Quoting Christian PERRIER (bubu...@debian.org):
> Quoting Serge Hallyn (serge.hal...@ubuntu.com):
> > Quoting Christian PERRIER (bubu...@debian.org):
> > > Quoting Christian PERRIER (bubu...@debian.org):
> > > > Hello fellow developers,
> > > > 
> > > > I would like to request your help in testing the new version of the
> > > > shadow package (that provides login, passwd and such other important
> > > > or base packages).
> > > 
> > > I haven't got much feedbackwhich is indeed what I was more or less
> > > expecting. ;-)
> > > 
> > > So, well, let's jump into the mud (I love to do that when
> > > running.not sure I love to do that in my FLOSS activities) and
> > > I'll soon upload shadow to unstable Be prepared.
> > 
> > Hi,
> > 
> > so first glitch I found is that /etc/subuid was not created for me.
> > login.postinst only creates that on new installs.  In Ubuntu it
> > does so anytime it does not exist - I assume you made that change
> > on purpose?  usermod -v refuses to run if the file does not exist,
> > so users will need to be told to create those files themselves.
> 
> What makes you think this?
> 
> In login.postinst, we have:
> 
> # Create subuid/subgid if missing
> if [ ! -e /etc/subuid ]; then
> touch /etc/subuid
> chown root:root /etc/subuid
> chmod 644 /etc/subuid
> fi
> 
> 
> (strangely indented, admitedlybut unless I'm missing something

Oh, yo'ure right.  The indenting threw me off.

And the reason they weren't created was that I was blindly expecting
the uidmap package to depend on both passwd and login >= 1:4.2-1,
so while i had upgraded passwd to experimental's version i hadn't
upgraded login's.

Sorry, my bad.  So all seemed to be working fine!

> obvious, it is unconditionnally run)
> 
> That code probably somes unchanged from the patches that have been
> proposed, indeed.
> 
> And, well, on my system, /etc/subuid and /etc/subgid were indeed
> created when I manually installed the new login package.
> 



> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-shadow-devel


-- 
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/20140502133733.GB1760@ubuntumail

Re: goals for hardening Debian: ideas and help wanted

[Kevin Chadwick]

previously on this list Kevin Chadwick contributed:

> all sorts of stuff that would make any chroot
> in this way pointless. "more powerful" I expect means less secure in
> this usage.

p.p.s. why implement yet more code and complexity into systemd for
preventing device files when you can just use the nodev filesystem flag.

Yet another classic example of pointless arguably, more likely
detrimental feature creep/steal and even worse when duplicating existing
functions that can be applied more universally.

Perhaps because of this quote taken from the opening page of a book
about Ada and high integrity software.


"There are two ways of constructing a software design. One is to make
it so simple that there are OBVIOUSLY no deficiencies. And the other is
to make it so complicated that there are no OBVIOUS deficiencies"

Professor C. A. R. Hoare
The 1980 Turing award lecture

I think the one thing all should be able to agree on about systemd is
that systemd falls into the latter.

-- 
___

'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/753535.36099...@smtp138.mail.ir2.yahoo.com

Re: goals for hardening Debian: ideas and help wanted

[Kevin Chadwick]

On Fri, 02 May 2014 10:55:15 +0200
Aaron Zauner wrote:

> Bashing on Tor does not help here.

The page suggests all devs use Tor to avoid being targetted. 

I am saying, does it accomplish that and is is best practice. Should
they be hackable even if they are targetted or stumbled upon. I find
that highly questionable and I am suggesting other simpler policies
will be far more effective. Hiding is fine but not at the cost of
complexity where security (confidentiality/protection/unexploitability)
is paramount.

I also mentioned ssh which I believe all the devs are using already. I
am not going to say which VPN/SSH is best for the devs, I wouldn't
know. I expect they would not choose commerical proprietary
insecure CISCO you compare to TOR though in any case.


-- 
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/519419.15824...@smtp146.mail.ir2.yahoo.com

Re: goals for hardening Debian: ideas and help wanted

[Kevin Chadwick]

previously on this list Tzafrir Cohen contributed:

> > A wide misconception. Chroots are easily implemented and add security
> > almost for free   
> 
> Not completely for free. You now have an extra mini-system to maintain.
> 
> (often /dev/log is all that is needed) and so can be

You completely misunderstand. Many daemons have chroot config options
for security reasons. I am asking does Debian use them by default and
if not why not.

> > used by default without any potential problems,   
> 
> > they also never bring
> > new risks  
> 
> unless you forget to unpdate them.
> 

You don't need to update them, they are basically empty and created on
daemon startup with perhaos one or two files like a dns root key for
unbound which is then self maintained (better if writes could be
avoided though). I am talking about dropping an unpriviledged process
permissions to next to nothing running with no shell and no filesystem
access so that any exploit in the network/any input code is far
less likely to get any further.

> It's also worth mentioning systemd-nspawn:
> http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html

Not at all, it hasn't been tested for this, isn't supported by daemons
that crucially use "priviledge seperation, which involves forking
children so a tiny process doing what root needs or a tiny process doing
the dangerous stuff in a chroot as an unpriviledged user or a
combination of both and any wrong communication means the priv parent
dies), sounds like it does what most Linux admins think chroot is only
good for and talks about all sorts of stuff that would make any chroot
in this way pointless. "more powerful" I expect means less secure in
this usage.

p.s. this is proper security in quality daemons implementing application
specific security not polkit/systemd rubbish. Whilst you have got me to
mention systemd I shall bring something up that has yanked my chain.

I suppose the debian page

https://wiki.debian.org/Debate/initsystem/systemd

Is just written by random developers and is not official or speaking as
a debian collective because it is very unbalanced indeed.

Embedded more performance less memory blah blah well that depends as
systemd is NOT compatible with application specific embedded that
basically is what embedded is all about and the Linux kernel is
atleast for now and would be forked otherwise. I could argue further
about larger systems but I won't bother, it would just be twisted and
move away from the main point anyway.

http://lists.busybox.net/pipermail/buildroot/2011-November/047612.html

-- 
___

'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/25453.25357...@smtp118.mail.ir2.yahoo.com

Bug#746653: ITP: libcatalyst-plugin-email-perl -- module to send emails with Catalyst

[Michael Prokop]

Package: wnpp
Owner: Debian Perl Group 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libcatalyst-plugin-email-perl
  Version : 0.08
  Upstream Author : Sebastian Riedel 
* URL : https://metacpan.org/release/Catalyst-Plugin-Email
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module to send emails with Catalyst

Send emails with Catalyst and Email::Send and Email::MIME::Creator.

Actual packaging work is by Victor, and the current state of packaging is 
living at
git://anonscm.debian.org/pkg-perl/packages/libcatalyst-plugin-email-perl.git /
ssh://git.debian.org/git/pkg-perl/packages/libcatalyst-plugin-email-perl.git
thanks to gregor herrmann.

regards,
-mika-


signature.asc
Description: Digital signature

Re: Call for help from KDE Team

[David Goodenough]

On Friday 02 May 2014 11:32:41 Maximiliano Curia wrote:
> ¡Hola Paul!
> 
> El 2014-05-02 a las 08:40 +0800, Paul Wise escribió:
> > On Fri, May 2, 2014 at 2:19 AM, Maximiliano Curia wrote:
> > > For quite a while now the KDE team has been severely understaffed. We
> > > maintain a lot of packages, with many different kinds of bugs, but we
> > > don't have enough people to do all the work that needs to be done. We
> > > have tools that help us automate the update to new upstream releases,
> > > but that's just the tip of the iceberg of our work and so we are
> > > writing to invite more people to get involved in the team and help us
> > > get KDE software in Debian into better shape.> 
> > Have you invited the Kubuntu team to join you? I'll send a mail to the
> > other derivatives I can find that use KDE.
> 
> We've invited the Kubuntu team to merge their efforts with ours and use the
> same packaging vcs. The answer was positive, although the migration is a bit
> too far in the future. They sort of agree that they could migrate from
> launchpad bzr to git.debian.org, but as they are a larger group they
> separate junior and senior developers, requiring a review for each junior
> commit, for which they have a workflow and systems in place that won't be
> directly usable in git.debian.org. so the idea is to keep in sync most of
> our work, and see if we can figure out a way to merge it.
> 
> Which translates to some overhead and a larger TODO list than an immediate
> help, but sure, once certain threshold in time invested is reached, both
> Debian and Ubuntu could benefit from it.
> 
> Happy hacking,
Sounds like a job for Gerrit.  Currently not fully packages for Debian
but I understand there is work being done one it.  There is a github 
project at https://github.com/dnaeon/gerrit-debian which builds debs.

David


--
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/2391161.nUmctEEEVR@stargate

Bug#746652: ITP: openambit -- utilities for Suunto Ambit sport watches

[Christian Perrier]

Package: wnpp
Severity: wishlist
Owner: Christian Perrier 

* Package name: openambit
  Version : 0.2
  Upstream Author : Emil Ljungdahl
* URL : http://openambit.org/
* License : GPL-3
  Programming Lang: C
  Description : utilities for Suunto Ambit sport watches

 This package provides software that helps communicating with Suunto Ambit
 outdoor watches.

The main motivation for me to package this is because I need it to avoid
being forced to use a Microsoft Windows machine to synchronize my brand
new shiny Suunto Ambit 2 watch...:-)

Suunto only officially supports Windows and doesn't plan to provide Linux
versions of the software that helps communicating with the watch
and sync its data to the Movescount website.

That package would indeed be useful to all users of Debian who own
a Suunto Ambit watch for outdoor activities.


-- 
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/20140502103655.4085.97623.report...@mykerinos.kheops.frmug.org

Re: Call for help from KDE Team

[Maximiliano Curia]

¡Hola Ritesh!

El 2014-05-02 a las 00:57 +0530, Ritesh Raj Sarraf escribió:
> I've been trying to do my part, in maintaining small packages in the
> KDE Extras Team.

> For KDE Core, the commitments are high. Even after the source split,
> the dependencies that the KDE Components have amongst each other,
> makes me nervous to pick one up.

> Perhaps I will start with monitoring the bug report and adding my
> input as and when necessary.

Thanks for the reply. You are more than welcome to start working on some of
the tasks described or whatever tasks you consider useful for our users, but,
please, don't do it because of guilt. We value your contributions and the team
is lucky to have you as a member, if you have the time and the energy to chew
into more things, please go ahead. We can try to help you overcome your
nervousness about the pending tasks. But, remind yourself that the amount of
work we can accomplish is finite while the amount of things that need to be
done tends to be infinite, in various dimensions. :)

Have fun,
-- 
"UNIX is basically a simple operating system, but you have to be a genius to
understand the simplicity."
-- Dennis Ritchie
Saludos /\/\ /\ >< `/


signature.asc
Description: Digital signature

Re: mirror.debian.net down?

[Raphael Geissert]

[Copying the appropriate list]

Luca Filipozzi wrote:

> On Wed, Apr 30, 2014 at 12:00:55AM +0100, Steven Chamberlain wrote:
>> On 29/04/14 23:22, Luca Filipozzi wrote:
>> > It should be mostly corrected now although one name server is still not
>> > transferring properly.
>> > 
>> > Technicians have been deployed.
>> 
>> If there is any more you can tell me about this DNS zone, it would be
>> nice to document it better at https://wiki.debian.org/DebianGeoMirror
>> If it is deprecated (as is geomirror.debian.net) that could be mentioned
>> there.  I'm curious how the list of mirrors is maintained, too.
> 
> So am I.  It used to be a dynamic zone but hasn't seen updates in almost 2
> years.  It should go away, IMO.

I personally thought it was gone already. Simon might confirm or prove me 
wrong, but AFAIR it should no longer exist.

Oh and it used to be updated by the data from Mirrors.masterlist

>> I still find it very useful in combination with a caching web proxy
>> (better than http.debian.net because that can vary the resultant object
>> URI, and better than cdn.debian.net because that doesn't consider
>> mirrors carrying only a subset of architectures).

Doesn't your caching proxy actually cache the 301s? redirections to volatile 
data get a 302 so that only the data from the mirror is cached, but non-
volatile data get 301s.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


-- 
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/ljvqpr$o4e$1...@ger.gmane.org

Re: Call for help from KDE Team

[Maximiliano Curia]

¡Hola Paul!

El 2014-05-02 a las 08:40 +0800, Paul Wise escribió:
> On Fri, May 2, 2014 at 2:19 AM, Maximiliano Curia wrote:
> > For quite a while now the KDE team has been severely understaffed. We 
> > maintain
> > a lot of packages, with many different kinds of bugs, but we don't have 
> > enough
> > people to do all the work that needs to be done. We have tools that help us
> > automate the update to new upstream releases, but that's just the tip of the
> > iceberg of our work and so we are writing to invite more people to get
> > involved in the team and help us get KDE software in Debian into better 
> > shape.

> Have you invited the Kubuntu team to join you? I'll send a mail to the
> other derivatives I can find that use KDE.

We've invited the Kubuntu team to merge their efforts with ours and use the
same packaging vcs. The answer was positive, although the migration is a bit
too far in the future. They sort of agree that they could migrate from
launchpad bzr to git.debian.org, but as they are a larger group they separate
junior and senior developers, requiring a review for each junior commit, for
which they have a workflow and systems in place that won't be directly usable
in git.debian.org. so the idea is to keep in sync most of our work, and see if
we can figure out a way to merge it.

Which translates to some overhead and a larger TODO list than an immediate
help, but sure, once certain threshold in time invested is reached, both Debian
and Ubuntu could benefit from it.

Happy hacking,
-- 
"Good judgement comes from experience, and experience comes from bad
judgement."
-- Fred Brooks
Saludos /\/\ /\ >< `/


signature.asc
Description: Digital signature

Re: goals for hardening Debian: ideas and help wanted

[Aaron Zauner]

Hi Kevin,

Kevin Chadwick wrote:
> Debian developers not being able to upload security fixes is part of
> the mix but then I would guess you could more easily bring down the TOR
> network too than a private VPN and filtering would be much more
> difficult so I would say TOR is not *optimum* for security or
> availability and obscurity is no real security though perhaps very 
> occasionally the best possible ;-).
I'm not saying that DD's should use Tor. But a VPN might not be more secure.

> Tor is more complex, less proven, had more past exploits and crucially I
> believe? generally more reliant on external infrastructure. It's
> primary aim is privacy and not a simply secure protocol. I include SSH
> when I say VPN too but host security is paramount in any case.
Software VPNs have had vulnerabilities over and over again, the last one
being heartbleed (that also affected commercial VPN products such as
Cisco ASA/PIX and some Juniper devices). IPsec hat to be revised and is
often implemented in a way that defies the standard that has been under
heavy criticism by the cryptography community (e.g.
https://www.schneier.com/paper-ipsec.html)

Bashing on Tor does not help here.

Aaron



signature.asc
Description: OpenPGP digital signature

Re: Bug#745872: ITP: profanity -- a console based XMPP client

[Dariusz Dwornikowski]

On 28 April 2014 22:23, Clint Adams  wrote:
> On Mon, Apr 28, 2014 at 10:15:32PM +0200, Jeroen Dekkers wrote:
>> Please use a wording that also grants permission to link to forks of
>> OpenSSL such as LibreSSL, in case LibreSSL or another fork is
>> preferred over OpenSSL in the future. You can take wget as an example:
>
> No, please use a more secure library with a better license.


Great News,

Upstream reimplemented to use gnuTLS, so no need to relicense.


-- 
Pozdrawiam,
Dariusz Dwornikowski, Assistant
Institute of Computing Science, Poznań University of Technology
www.cs.put.poznan.pl/ddwornikowski/
room 2.7.2 BTiCW | tel. +48 61 665 29 41


--
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/CAGnkunc8HG=4mdHTAUhFpJAYohTAG+2s2BQL_q�5s0hza...@mail.gmail.com