Re: .py suffixed scripts to /usr/bin/

[David Prévot]

Le 03/11/2013 11:28, bastien ROUCARIES a écrit :

> Should we add a lintian test for this kind of problem ?

http://lintian.debian.org/tags/script-with-language-extension.html





signature.asc
Description: OpenPGP digital signature

Bug#728673: ITP: golang-nzaat -- Go implementation of the NZAAT hash algorithm

[Tonnerre LOMBARD]

Package: wnpp
Severity: wishlist
Owner: Tonnerre LOMBARD 

* Package name: golang-nzaat
  Version : 0.1
  Upstream Author : Tonnerre LOMBARD 
* URL : http://github.com/tonnerre/golang-nzaat
* License : BSD-3-Clause
  Programming Lang: Go
  Description : Go implementation of the NZAAT hash algorithm

Go implementation of the hash algorithm "NUL zaehlen an allen Teilen"
based on the One At A Time hash (OAAT) by Bob Jenkins. This is not a
cryptographic hash, but it satisfies the perfect hash criteria well
enough to be usable as a hash table hash or similar.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20131104022219.29124.37690.report...@phileas.roam.internetputzen.com

Bug#728671: general: Screen backlight "Pulses" when being lowered and is inconsistent (Debian Testing)

[Panagiotis Kyriacou]

Package: general
Severity: normal

Hello,

I'm currently running the latest version of Debian Testing (as of 4/11/2013
02:00 GMT+2), and I've noticed a problem while changing the backlight of my
screen.

When I press the "Lower Brightness" key combination (FN+Home on my Lenovo
SL500) and keep it pressed, the backlight keeps pulsing on the lowest setting,
like it's trying to go one step lower but it can't. This keeps happening as
long as the key-combo is pressed.

I've noticed that the stepping for the brightness level is kind of unstable as
there's also a small pulse-like effect going on when I change brightness in
general. It gradually becomes more evident as I get close to the lowest
brightness setting.

The amount of steps is inconsistent, as it requires 14 steps to go from
brightest to lowest and only 5 to go from lowest to brightest. Also, the OSD
freezes when keeping the key combination pressed, instead of gradually changing
to the highest or lowest setting. After a while (a few seconds), it unfreezes
and shows the correct value. It also appears that you can't do anything while
the OSD is frozen.

The same problem also occurs when using Ubuntu 13.10 (tried that about a week
ago... so many crashes), on the same laptop. This problem did not occur in
Wheezy or Ubuntu 13.04.

I'm not really sure but I think that this problem has appeared in Testing
today, after installing the latest updates:
[UPGRADE] gnome-icon-theme:amd64 3.8.3-1 -> 3.10.0-1
[UPGRADE] gnome-icon-theme-extras:amd64 3.6.2-2 -> 3.6.2-3
[UPGRADE] gnome-icon-theme-symbolic:amd64 3.8.2.2-2 -> 3.10.1-1
[UPGRADE] gnome-terminal:amd64 3.8.4-1 -> 3.10.1-1
[UPGRADE] gnome-terminal-data:amd64 3.8.4-1 -> 3.10.1-1
[UPGRADE] libtxc-dxtn-s2tc0:amd64 0~git20121227-1 -> 0~git20121227-2
[UPGRADE] libtxc-dxtn-s2tc0:i386 0~git20121227-1 -> 0~git20121227-2
[UPGRADE] libxml-libxml-perl:amd64 2.0010+dfsg-1+b1 -> 2.0106+dfsg-1
[UPGRADE] python-apt:amd64 0.8.9.1+b1 -> 0.9.1
[UPGRADE] python-apt-common:amd64 0.8.9.1 -> 0.9.1
[UPGRADE] python3-apt:amd64 0.8.9.1+b1 -> 0.9.1

I also installed (and configured) the lm_sensors and hddtemp packages.

I'm using gnome-shell. I don't know whether a gnome-shell extension is causing
this. I've disabled any newly installed extensions but it hasn't done anything.

Thank you,
Panagiotis



-- System Information:
Debian Release: jessie/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.10-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131104004629.7910.33521.report...@titan.home

Bug#728670: ITP: libwx-glcanvas-perl -- Perl interface to wxWidgets' OpenGL canvas

[Nicolas Dandrimont]

Package: wnpp
Severity: wishlist
Owner: Nicolas Dandrimont 

* Package name: libwx-glcanvas-perl
  Version : 0.09
  Upstream Author : Mattia Barbon 
* URL : https://metacpan.org/release/Wx-GLCanvas/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl interface to wxWidgets' OpenGL canvas

 Wx::GLCanvas is an extension module allowing the integration of an OpenGL 
Canvas
 in Perl programs using the wxWidgets toolkit. It does so by wrapping the
 wxWidgets wxGLCanvas class.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20131103233035.6593.67958.report...@darboux.home.olasd.eu

Bug#728669: ITP: goldbug -- secure fully decentralized instant messaging, chat and email client

[Richard Sellam]

Package: wnpp
Severity: wishlist
Owner: Richard Sellam 

* Package name: goldbug
  Version : 0.6
  Upstream Author : Bernd H Stramm 
* URL : http://goldbug.sourceforge.net/
* License : BSD, LGPLv2
  Programming Lang: C++
  Description : secure fully decentralized instant messaging, chat and 
email client
 Goldbug is a fully decentralized peer-to-peer or friend-to-friend Instant 
Messenger
 that aims to provide secure communications by using multi-encryption (RSA 
keys, SSL
 and end-to-end encryption) and the Echo Protocol (EMPP = Echoed Messaging and 
Presence
 Protocol) to avoid tracking.
 .
 Random fake messages can be sent as well from time to time to avoid tracking. 
Goldbug
 prevents data retention for the same reasons and provides Web-of-Trust (WoT) 
Deniability.
 .
 It also offers decentralized and encrypted email and decentralized public 
E*IRC Chat for
 groups of friends to chat privately. Signatures are available for 
authentication of chat
 and emails.


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

Bug#728662: ITP: golang-doozer-exportedservice -- Doozer exported HTTP/TCP/whatever service ports

[Tonnerre LOMBARD]

Package: wnpp
Severity: wishlist
Owner: Tonnerre LOMBARD 

* Package name: golang-doozer-exportedservice
  Version : 0.2
  Upstream Author : Tonnerre LOMBARD 
* URL : http://github.com/tonnerre/golang-doozer-exportedservice
* License : BSD-3-Clause
  Programming Lang: Go
  Description : Doozer exported HTTP/TCP/whatever service ports

Simple method for programmers to bind their service to anonymous ports
and to export the host name and port of the location to a Doozer
lock service.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20131103221749.13069.11880.report...@phileas.roam.internetputzen.com

Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))

[Steve Langasek]

On Sun, Nov 03, 2013 at 11:54:34AM +0100, Niels Thykier wrote:
> On 2013-10-29 17:48, Ian Jackson wrote:
> > Niels Thykier writes ("Re: Bits from the Release Team (Jessie freeze 
> > info)"):
> >> [...]
> >> As mentioned we are debating whether the "5 DDs" requirement still makes
> >> sense.  Would you say that we should abolish the requirement for DD
> >> porters completely?  I.e. Even if there are no (soon to be) DDs, we
> >> should consider the porter requirements fulfilled as long as they are
> >> enough "active porters" behind the port[0]?

> > I don't have a good feel for the answer to that question.  

> > It's just that if it is the case that a problem with ports is the lack
> > of specifically DDs, rather than porter effort in general, then
> > sponsorship is an obvious way to solve that problem.

> > If you feel that that's not really the main problem then a criterion
> > which counts porters of any status would be better.

> I suppose a "sponsor-only" DD could be sufficient, provided that the
> sponsor knows the porters well enough to be willing to sign off on e.g.
> access to porter boxes.  I guess the sponsor would also need to dedicate
> time to mentor (new?) porters on workflows and on quicks like when is a
> FTBFS RC and when it isn't etc.

Why would the sponsor need to be involved in getting the porters access to
porter boxes?  Porter boxes exist so that DDs *not* involved in a port have
access to a machine of the architecture and can keep their packages working.
I've never heard of a porter who didn't have access to their own box for
porting work.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#728657: ITP: golang-urlconnection -- Go library to connect to targets given as URLs

[Tonnerre LOMBARD]

Package: wnpp
Severity: wishlist
Owner: Tonnerre LOMBARD 

* Package name: golang-urlconnection
  Version : 0.2
  Upstream Author : Tonnerre LOMBARD 
* URL : http://github.com/tonnerre/go-urlconnection
* License : BSD-3-Clause
  Programming Lang: Go
  Description : Go library to connect to targets given as URLs

Go library to allow establishing connections to various types of backends
which are given as URLs. Provides a common constructor for different types
of connections, which takes only an URL, and returns a regular
read/write/close interface to the corresponding destination.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20131103203519.20043.87099.report...@phileas.roam.internetputzen.com

Re: Jessie release goal: DNSSEC as default recursive resolver

[Marko Randjelovic]

On Sun, 3 Nov 2013 12:32:40 +0100
Bastian Blank  wrote:

> On Sun, Nov 03, 2013 at 11:15:36AM +0100, Marko Randjelovic wrote:
> > Just to say we should not expect to much from DNSSEC because DNSSEC is 
> > centralized:
> 
> Could you explain the problems you see a bit more verbose?
> 
> > https://gnunet.org/uva2013
> 
> This is just an announcement and nothing about DNSSEC.
> 
> Bastian
> 

It is explained in a PDF document that can be downloaded from that page.

-- 
http://mr.flossdaily.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131103190549.0eab5...@eunet.rs

Re: .py suffixed scripts to /usr/bin/

[Jonathan Dowland]

> On 3 Nov 2013, at 15:28, Thomas Goirand  wrote:
> 
> The problem
> with /usr/bin/ collision is *only* when we have 2 software
> doing completely different things using the same /usr/bin/.

We've already established that the tools are not command line compatible.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/44213167-d702-4cc6-aec6-9f0d143fa...@debian.org

Re: Potential issues for most ports

[Niels Thykier]

On 2013-11-03 16:54, Niels Thykier wrote:
> On 2013-11-03 15:49, Thorsten Glaser wrote:
>> > Niels Thykier dixit:
>> > 
>>> >> [...]
>>> >> Until we have a clear definition of "actively maintained ports", I would
>>> >> recommend porters to err on the side of being verbose over being silent.
>> > 
>> > I’ve held off on the m68k side because I think the role call was only
>> > for architectures in the main archive, right?
>> > 
> Yes, we are only talking about architectures in the main architecture.
> 

s/main arcihtecture/main archive/;

~Niels



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/527674bd.2070...@thykier.net

Re: Potential issues for most ports

[Niels Thykier]

On 2013-11-03 15:49, Thorsten Glaser wrote:
> Niels Thykier dixit:
> 
>> [...]
>> Until we have a clear definition of "actively maintained ports", I would
>> recommend porters to err on the side of being verbose over being silent.
> 
> I’ve held off on the m68k side because I think the role call was only
> for architectures in the main archive, right?
> 

Yes, we are only talking about architectures in the main architecture.

>> [1] Nothing official yet, but gcc-4.6 (and earlier) /might/ not be
>> acceptable as a default for Jessie.
> 
> Didn't Doko say he’d want 4.8? We (on the m68k side) are putting
> effort into that one, since 4.7 appears to only be used by eglibc
> right now. And 4.6 for GNAT, but gnat-4.8 is new, and the ICE may
> be fixed as there’s active upstream on the GCC/m68k side.
> 
> bye,
> //mirabilos
> 

I am not entirely up to speed on what he wants; I am still waiting for
him to get back to me (see [1]).

~Niels

[1] https://lists.debian.org/debian-release/2013/10/msg00710.html



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/527671af.7050...@thykier.net

Re: .py suffixed scripts to /usr/bin/

[Thomas Goirand]

On 10/31/2013 10:21 PM, Yaroslav Halchenko wrote:
> there is a non-free original MNE which provides some of those
> tools implemented in C.  Happen MNE gets freed (and packaged) or
> otherwise installed -- there would be a conflict (command line interface
> differs, alternatives is not the way).

Having 2 implementations of the same thing isn't a problem, we can use
update-alternatives for that. See mawk vs gawk for example. The problem
with /usr/bin/ collision is *only* when we have 2 software
doing completely different things using the same /usr/bin/.

So if you want to prepare the future, you could install your command
line utility as /usr/bin/python- and use update-alternatives
to make it available as /usr/bin/, though it might be a bit
overkill if the C version isn't released as free software yet.

On 11/01/2013 06:32 AM, Charles Plessy wrote:
> The solution is to the change Policy :)

No! :)

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52766b90.9000...@debian.org

Re: Jessie release goal: DNSSEC as default recursive resolver

[Thomas Goirand]

On 10/30/2013 10:56 PM, Wouter Verhelst wrote:
> At any rate, my main point was that we should not default to using a
> system-local recursive resolver which ignores the ISP-provided one, just
> because that's the "easiest" way to do DNSSEC these days.

Correct, that's not the *only* reason! :)

Another one would be that many ISPs are just doing bad things with their
DNS, like replacing the NXDOMAIN by a catchall that points to
advertizing (for example, some Chinese ISP do that (or at least used
to)), banning some websites from their servers (piratebay has had this
in many countries), and all sorts of other malicious things (another
example, recently, in France, Free / Illiad made the headlines because
they started blocking Google ADWords, which IMO, isn't under their
responsibility as an ISP).

Not trusting local ISP by default would be a good thing, even without
talking about DNSSEC. I know it, and I have the knowledge and the will
to do that, though maybe it's too hard for the less tech-savvy of our
users. It'd be nice to have an easy solution for these.

However, I do understand the concern that it may sometimes not work and
that this should be addressed. If there's no easy solution, I would
understand that we leave things as they are.

> A cache on an
> ISP-provided recursive nameserver is likely to be containing a lot of
> results for "common" DNS queries, which is good for performance.

I've been using bind on my laptop, querying the root servers directly
for years, and it hasn't bothered me.

> It might be a good idea to _fall back_ to that solution if the
> alternatives result in not having DNSSEC enabled; but it should not be
> the default.

I'm tempted to think the other way around! :)

Though anyway, whatever... if we can have DNSSEC by default, one way or
another, that's a good thing. Let's drop the "local resolver" debate, if
that helps move forward.

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/527669f1.7040...@debian.org

Bug#728606: general: Keyboard shortcuts for Volume, keyboard backlight no longer work. Shortcut for brightness works, but OSD does not

[Jonathan Dowland]

Hello,

What desktop environment are you using: E.g., GNOME3, KDE, XFCE, LXDE…

If GNOME 3, do you know whether you are using it in "normal" mode or 
"classic" mode (aka fallback mode, sometimes)?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2013110319.ga19...@bryant.redmars.org

Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))

[Thorsten Glaser]

Niels Thykier dixit:

>Then there are more concrete things like ruby's test suite seg. faulting
>on ia64 (#593141), ld seg. faulting with --as-needed on ia64

And only statically linked klibc-compiled executables work on IA64,
not dynamically linked ones. I’ve looked into it, but Itanic is so
massively foreign I didn’t manage to find out anything except that
the problem appears to happen before main.

>Until we have a clear definition of "actively maintained ports", I would
>recommend porters to err on the side of being verbose over being silent.

I’ve held off on the m68k side because I think the role call was only
for architectures in the main archive, right?

>[1] Nothing official yet, but gcc-4.6 (and earlier) /might/ not be
>acceptable as a default for Jessie.

Didn't Doko say he’d want 4.8? We (on the m68k side) are putting
effort into that one, since 4.7 appears to only be used by eglibc
right now. And 4.6 for GNAT, but gnat-4.8 is new, and the ICE may
be fixed as there’s active upstream on the GCC/m68k side.

bye,
//mirabilos
-- 
 Beware of ritual lest you forget the meaning behind it.
 yeah but it means if you really care about something, don't
ritualise it, or you will lose it. don't fetishise it, don't
obsess. or you'll forget why you love it in the first place.


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

Bug#728606: general: Keyboard shortcuts for Volume, keyboard backlight no longer work. Shortcut for brightness works, but OSD does not

[Bart-Jan Vrielink]

Gnome3

 
 
-Original message-
> From:Jonathan Dowland mailto:j...@debian.org> >
> Sent: Sunday 3rd November 2013 15:44
> To: Bart-Jan Vrielink mailto:bart...@vrielink.net> >; 
> 728...@bugs.debian.org  
> Subject: Re: Bug#728606: general: Keyboard shortcuts for Volume, keyboard 
> backlight no longer work. Shortcut for brightness works, but OSD does not
> 
> Hello,
> 
> What desktop environment are you using: E.g., GNOME3, KDE, XFCE, LXDE…
> 
> If GNOME 3, do you know whether you are using it in "normal" mode or 
> "classic" mode (aka fallback mode, sometimes)?
> 
> 

Re: .py suffixed scripts to /usr/bin/

[bastien ROUCARIES]

On Saturday 02 November 2013 08:33:54 Paul Wise wrote:
> On Fri, Nov 1, 2013 at 11:09 PM, Yaroslav Halchenko wrote:
> > in any case -- upstream seems have liked a 'gateway script' solution:
> > https://github.com/mne-tools/mne-python/pull/866

Should we add a lintian test for this kind of problem ?

Pedantic level ?
> 
> Sounds like a better solution anyway, thanks.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/6181820.SvroZiYcVK@bastien-debian

Bug#728606: general: Keyboard shortcuts for Volume, keyboard backlight no longer work. Shortcut for brightness works, but OSD does not

[Bart-Jan Vrielink]

Package: general
Severity: normal

Dear Maintainer,

Since a couple of weeks, on my Asus Zenbook (UX32VD), running Testing, the 
keyboard shortcuts for the audio volume and keyboard backlight no longer work, 
and somewhere in the boot cyclus, the keyboard backlight gets disabled.
The keyboard shortcut for brightness does work, but it does no longer give OSD 
feedback.

Since I have no clue which package is responsible for this behavior, I've filed 
it against general. Please re-assign to the correct package (and educate me how 
to find out which package is responsible).

These keyboard shortcuts (Fn+f3, Fn+f4 for keyboard backlight, Fn+f11, Fn+f12 
for volume and Fn+f5, Fn+f6 for brightness) used to work correctly until a few 
weeks ago, but stopped working, most likely because of an apt-get upgrade.

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (750, 'testing'), (400, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.10-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Bug#728597: ITP: libcss-lessp-perl -- LESS for perl

[Vasudev Kamath]

Package: wnpp
Severity: wishlist
Owner: Vasudev Kamath 

* Package name: libcss-lessp-perl
  Version : 0.86
  Upstream Author : Ivan Drinchev 
* URL : https://metacpan.org/pod/CSS::LESSp
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : LESS for perl

 This module is designed to parse and compile .less files into CSS
 files.
 .
 The benifit of this module is that it is extremely fast. This tool also
 provides less.pl binary which can be directly used to convert less
 files to css.

 This will be dependency for Plack::Middleware::Asset::RailsLike module.

-- 
Vasudev Kamath
http://copyninja.info
Connect on ~friendica: copyninja@{frndk.de | vasudev.homelinux.net}
IRC nick: copyninja | vasudev {irc.oftc.net | irc.freenode.net}
GPG Key: C517 C25D E408 759D 98A4  C96B 6C8F 74AE 8770 0B7E


signature.asc
Description: Digital signature

Bug#728591: ITP: riemann-c-client -- C language client library for the Riemann event stream processor

[Gergely Nagy]

Package: wnpp
Severity: wishlist
Owner: Gergely Nagy 

* Package name: riemann-c-client
  Version : 1.0.1
  Upstream Author : Gergely Nagy 
* URL : https://github.com/algernon/riemann-c-client/
* License : LGPL-3+
  Programming Lang: C
  Description : C language client library for the Riemann event stream 
processor
 Riemann is a network event stream processor, intended for analyitics,
 metrics and alerting; and to glue various monitoring systems together.
 .
 This library provides a C language client, with a simple but
 convenient API, to connect to Riemann, send events and run queries
 against it.

I already have the debianisation complete, it just needs to be
uploaded. This is a dependency of the syslog-ng-incubator project
which I also plan to upload shortly after syslog-ng 3.5 made it into
unstable.


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

Re: Jessie release goal: DNSSEC as default recursive resolver

[Bastian Blank]

On Sun, Nov 03, 2013 at 11:15:36AM +0100, Marko Randjelovic wrote:
> Just to say we should not expect to much from DNSSEC because DNSSEC is 
> centralized:

Could you explain the problems you see a bit more verbose?

> https://gnunet.org/uva2013

This is just an announcement and nothing about DNSSEC.

Bastian

-- 
You're too beautiful to ignore.  Too much woman.
-- Kirk to Yeoman Rand, "The Enemy Within", stardate unknown


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131103113240.ga11...@mail.waldi.eu.org

Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))

[Niels Thykier]

On 2013-10-29 17:48, Ian Jackson wrote:
> Niels Thykier writes ("Re: Bits from the Release Team (Jessie freeze info)"):
>> [...]
>> As mentioned we are debating whether the "5 DDs" requirement still makes
>> sense.  Would you say that we should abolish the requirement for DD
>> porters completely?  I.e. Even if there are no (soon to be) DDs, we
>> should consider the porter requirements fulfilled as long as they are
>> enough "active porters" behind the port[0]?
> 
> I don't have a good feel for the answer to that question.  
> 
> It's just that if it is the case that a problem with ports is the lack
> of specifically DDs, rather than porter effort in general, then
> sponsorship is an obvious way to solve that problem.
> 
> If you feel that that's not really the main problem then a criterion
> which counts porters of any status would be better.
> 

I suppose a "sponsor-only" DD could be sufficient, provided that the
sponsor knows the porters well enough to be willing to sign off on e.g.
access to porter boxes.  I guess the sponsor would also need to dedicate
time to mentor (new?) porters on workflows and on quicks like when is a
FTBFS RC and when it isn't etc.

> (Mind you, I have my doubts about a process which counts people
> promising to do work - it sets up some rather unfortunate incentives.
> I guess it's easier to judge and more prospective than a process which
> attempts to gauge whether the work has been done "well enough".)
> 
> [...]
> 
> Thanks,
> Ian.
> 
> 

Ah, you are not the first to question this process.  Obviously, we
intend to keep people up on their promise by "actively maintaining their
port".  Sadly, we do not have a clear definition of "actively maintained
ports" and I doubt we will have it any time soon either.
  But porters can start by working on the concerns from DSA (if they
haven't already done so).  Ports having gcc-4.6 as default compiler
might also consider improving in that area[1].

Then there are more concrete things like ruby's test suite seg. faulting
on ia64 (#593141), ld seg. faulting with --as-needed on ia64
(#718047[2]), a lot of ruby packages being stuck on kfreebsd-any due to
ruby2.0 FTBFS (#726095[3]).  Personally, I would also expect that
key-packages work on all ports (on which they are built) in general[4].

All of the (non-mild) DSA concerns are already something we will
officially hold against the ports.  Most of the other issues listed
above are not official concerns.  However, I would not be surprised if
most of them became official issues eventually.


Until we have a clear definition of "actively maintained ports", I would
recommend porters to err on the side of being verbose over being silent.
 As an example, lack of visible reply to mails like [5] makes it seem
like nobody is home.
  Mind you, I am not saying porters have the responsibility to fix every
problem forwarded to their port list.  I am also aware that sometimes
issues/mail "disappear" in the depths of people inbox - heck it happens
to me as well.
  Come to think of it; maybe we should have a BTS page for each of the
ports (e.g. a pseudo package in the BTS).  That way it would at least be
easier for all people to find outstanding issues for the port[6].  It
would also give us the possiblity to trivial declare a problem RC (or
not) for ports.  (Plus, then I won't have to update some random file on
release.d.o for every new issue :P)

Anyhow, I hope to be able to give a more "official" statement in the
near future.

~Niels

[1] Nothing official yet, but gcc-4.6 (and earlier) /might/ not be
acceptable as a default for Jessie.

[2] Apparently it is controversial whether that bug should be RC, but it
definitely looks like that kind of thing that will cause issues for ia64
later.

[3] That one got a patch, but it might be worth it to put some pressure
on the maintainer or even doing a NMU.

[4] A rule of thumb could be something like "your port should probably
not be listed here in the long run:

http://udd.debian.org/bugs.cgi?release=jessie_and_sid&merged=ign&keypackages=only&fnewerval=7&flastmodval=7&rc=1&sortby=id&sorto=asc
"

[5] https://lists.debian.org/debian-mips/2013/08/msg5.html

Btw, this is not intended to single out mips.

[6] I know that people have been usertags for issues that affect the
port, but it is not clear to me that all those usertags bugged is
something we expect porters to fix.  Rather it seems more like porters
tagging the FTBFS bugs they file.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52762b6a.5060...@thykier.net

Re: Jessie release goal: DNSSEC as default recursive resolver

[Marko Randjelovic]

Just to say we should not expect to much from DNSSEC because DNSSEC is 
centralized:

https://gnunet.org/uva2013

-- 
http://mr.flossdaily.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131103111536.42e81...@eunet.rs

Bug#728568: ITP: libdispatch-class-perl -- dispatch on the type (class) of an argument

[Vasudev Kamath]

Package: wnpp
Severity: wishlist
Owner: Vasudev Kamath 

* Package name: libdispatch-class-perl
  Version : 0.01
  Upstream Author : Lukas Mai 
* URL : https://metacpan.org/pod/Dispatch::Class
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : dispatch on the type (class) of an argument

 This module offers a simple way to check the class of an object and
 handle specific cases specifically.
 .
 In other words the module allows to do specific tasks depending on
 object type, similar to run time polymorphism.

 This module is dependency of libtry-tiny-byclass-perl which is inturn
 dependency of libcatmandu-perl


-- 
Vasudev Kamath
http://copyninja.info
Connect on ~friendica: copyninja@{frndk.de | vasudev.homelinux.net}
IRC nick: copyninja | vasudev {irc.oftc.net | irc.freenode.net}
GPG Key: C517 C25D E408 759D 98A4  C96B 6C8F 74AE 8770 0B7E


signature.asc
Description: Digital signature