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

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 tak

Re: goals for hardening Debian: ideas and help wanted

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 sec

Re: Call for help from KDE Team

¡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 > > enoug

Re: mirror.debian.net down?

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

Re: Call for help from KDE Team

¡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

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

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

Re: Call for help from KDE Team

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,

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

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/Cata

Re: goals for hardening Debian: ideas and help wanted

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

Re: goals for hardening Debian: ideas and help wanted

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

Re: goals for hardening Debian: ideas and help wanted

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

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

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

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

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 i

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

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

Multiarch and interpreters

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]

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

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 > infrastr

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

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 suppor

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

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 simpl

Re: Non-source Javascript files in upstream source

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

Re: Non-source Javascript files in upstream source

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 cl

Re: Non-source Javascript files in upstream source

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 de

A question about patches for upstream

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

Re: Non-source Javascript files in upstream source

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

Re: A question about patches for upstream

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 do

Re: Non-source Javascript files in upstream source

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 cover

Re: A question about patches for upstream

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

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

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

Re: Non-source Javascript files in upstream source

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 incl

Re: Non-source Javascript files in upstream source

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 sh

Re: A question about patches for upstream

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 essent

Re: Non-source Javascript files in upstream source

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

Re: Non-source Javascript files in upstream source

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-

Re: Non-source Javascript files in upstream source

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 a

Re: A question about patches for upstream

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 re

Re: A question about patches for upstream

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 a

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

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 s