Re: Ifupdown, loopback interface, /etc/network/interfaces.d

[Andrew Shadura]

Hello,

On Mon, 07 Jan 2013 08:42:40 +0100
Tollef Fog Heen  wrote:

> > I'd like to hear opinions on this idea.

> I think you should just get a wheezy-ignore tag from the release team
> and solve this properly for jessie.

> Also, your fix doesn't actually solve the RC bug either:

Well, it does.

> You Must Preserve All Admin Changes in /etc.  Not just the ones you think
> is sensible or reasonable.  Why not just report that the file is
> missing and leave it to the admin to fix (on upgrades, feel free to
> create it on the initial installation)?  After all, if they have
> removed it, they probably know how to bring it back.

> My suggestion would be to, over the jessie cycle, deprecate (but still
> read) /etc/network/interfaces and for jessie+1 just drop the file and
> only use the .d directory.

I don't think it's a good idea.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Re: Ifupdown, loopback interface, /etc/network/interfaces.d

[Tollef Fog Heen]

]] Andrew Shadura 

> > Also, your fix doesn't actually solve the RC bug either:
> 
> Well, it does.

No, it doesn't.  You're still recreating /etc/network/interfaces if it's
not there.  Removing a file is a change which must be preserved.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/87wqvpfkzc@qurzaw.varnish-software.com

Re: Ifupdown, loopback interface, /etc/network/interfaces.d

[Martin Wuertele]

* Andrew Shadura  [2013-01-07 09:15]:

> On Mon, 07 Jan 2013 08:42:40 +0100
> Tollef Fog Heen  wrote:
> 
> > My suggestion would be to, over the jessie cycle, deprecate (but still
> > read) /etc/network/interfaces and for jessie+1 just drop the file and
> > only use the .d directory.
> 
> I don't think it's a good idea.

Out of curiosity: why do you think this is a bad idea? 

Yours Martin


-- 
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/20130107084117.gb1...@anguilla.debian.or.at

Bug#697593: ITP: laborejo -- music notation workshop

[Alessio Treglia]

Package: wnpp
Severity: wishlist
Owner: Alessio Treglia 

* Package name: laborejo
  Version : 0.4.0
  Upstream Author : Nils Gey 
* URL : http://www.laborejo.org/
* License : GPL
  Programming Lang: Python
  Description : music notation workshop

 Laborejo, Esperanto for "Workshop", is used to craft
 music through notation. It is a Lilypond GUI frontend,
 a MIDI creator and finally a tool collection to inspire
 and help one to compose music. It works by reducing
 music-redundancy and by seperating layout and data.
 .
 Laborejo provides many features:
  * Unlimited tracks/staffs, voices, items.
  * Input via Keyboard, Mouse or MIDI.
  * Flexibel and fast shortcut and configuring system.
  * Portable, as few dependencies as possible.
  * PDF generation, ready-to-print, through Lilypond.
  * Separation of editing and note/data entry and layout.
  * MIDI file generation.
  * Playback through JACK.
  * Control over performance from a global level (e.g.
change how long non-legato notes or fermatas are) to
detailed, technical tweaks like MIDI CC messages.


-- 
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/20130107122129.9807.70325.reportbug@Aspire-1410

Re: Updates in the very-old-stable

[Mike Gabriel]

Hi Thomas, hi others,

On So 06 Jan 2013 19:36:09 CET Thomas Goirand wrote:


Another idea that pops up. Obviously, if this starts somehow,
it will be for when Squeeze is declared EOL, so that's in about
a year of time. Probably we can have an open round table
about this at next Debconf.


I'd be happy to join such a meeting on next DebConf. A lifetime that  
is greater than a year of squeeze (then as oldstable) would be  
fabulous!!!


Greets,
Mike


--

DAS-NETZWERKTEAM
mike gabriel, rothenstein 5, 24214 neudorf-bornstein
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb


pgpeMo5EP0c5q.pgp
Description: Digitale PGP-Unterschrift

Bug#697608: ITP: python-argcomplete -- Bash completion for python argparse

[Marco Nenciarini]

Package: wnpp
Severity: wishlist
Owner: Marco Nenciarini 

* Package name: python-argcomplete
  Version : 0.3.2
  Upstream Author : Andrey Kislyuk 
* URL : https://github.com/kislyuk/argcomplete
* License : Apache Software License
  Programming Lang: Python
  Description : Bash completion for python argparse
Argcomplete provides easy, extensible command line tab completion of
arguments for your Python script.
.
It makes two assumptions:
.
 * You're using bash as your shell
 * You're using argparse to manage your command line arguments/options
.
Argcomplete is particularly useful if your program has lots of options
or subparsers, and if your program can dynamically suggest completions
for your argument/option values (for example, if the user is browsing
resources over the network).


-- 
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/20130105231332.14725.13071.reportbug@asperger

Bug#697614: ITP: libsoxr -- High quality 1D sample-rate conversion library

[Benjamin Drung]

Package: wnpp
Severity: wishlist
Owner: Benjamin Drung 

* Package name: libsoxr
  Version : 0.1
  Upstream Author : Rob Sykes 
* URL : http://sourceforge.net/projects/soxr
* License : LGPL-2.1+ plus some BSD files
  Programming Lang: C
  Description : High quality 1D sample-rate conversion library

The SoX Resampler library `libsoxr' performs one-dimensional sample-rate
conversion - it may be used, for example, to resample PCM-encoded audio.

It aims to give fast and high quality results for any constant (rational or
irrational) resampling ratio. Phase-response, preserved bandwidth, aliasing,
and rejection level parameters are all configurable; alternatively, simple
`preset' configurations may be selected.

A simple API is provided that allows interfacing using commonly-used sample
formats and buffering schemes.

libsoxr will be a build dependency of the next release of Audacity. The package
will belong to the Debian Multimedia Maintainers team.


-- 
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/20130107160313.18954.20733.reportbug@deep-thought

Continue discussion about uscan enhancement (Was: Uscan enhancements revitalised)

[Andreas Tille]

Hi Nicolas,

happy new year - happy new discussion.

I was busy editing the Wiki page you created[1] and updated also the Git
repository to finally apply the patch you mentioned in the previous
discussion[2] because I realised that the `find -name` solution had the
drawback that it is not possible to remove a file from the package
source root while leaving a file with the same name in a subdirectory
(which I actually need to do for the igv package.)  I also adapted the
debian/copyright files I previousely created to this change (needs some
additional checking, but we need to be cautiously with the new code
anyway.  Some debugging output "the following files were removed" or
something like this comes to mind (and was mentioned previousely.)

Please have a look at the Wiki page[1] because I think I have mixed it
to a large extend - may be you might not recognize it as your initial
text. ;-)  My main point was that it was absolutely not clear that the
proposal + implementation you are providing there is totally different
from what we discussed in the thread - just some alternative way.

>From my point of view we should now discuss first what way to prefer:
Either the 'Files-Excluded' field or 'License: not-shipped-by-debian'
should be used and we should decide now before we keep on implementing
it.  I have a clear preference but for sure I'm biased and I'm waiting
for other opinions.

Kind regards and thanks for pushing the discussion

   Andreas.

[1] http://wiki.debian.org/UscanEnhancements
[2] https://lists.debian.org/debian-devel/2012/09/msg00083.html

-- 
http://fam-tille.de


-- 
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/20130107221316.gc28...@an3as.eu

Re: Bug#697433: Is the Package-List field necessary for uploads ?

[Charles Plessy]

Le Sun, Jan 06, 2013 at 09:12:11AM +0900, Charles Plessy a écrit :
> 
> we are documenting in the Policy the Package-List field of the Debian source
> control files.
> 
>   Multiline field listing all the packages that can be built from
>   the source package.  The first line of the field value is empty.
>   Each one of the next lines describe one binary package, by listing
>   its name, type, section and priority separated by spaces.  There
>   are two possible package types: binary package (deb) or
>   micro binary package (udeb).
> 
> I do not know if this field should be marked mandatory, recommended or
> optional.  Is this field is strictly necessary for uploads ?

After experimenting by uploading a package without the Package-List field, I
see that it is not mandatory.  But the Policy also distinguishes recommended
from other fields (for which nothing is mentioned).  Given that it is there by
default, I propose to mark it recommended.

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


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

Re: Bug#697433: Is the Package-List field necessary for uploads ?

[Russ Allbery]

Charles Plessy  writes:

> After experimenting by uploading a package without the Package-List
> field, I see that it is not mandatory.  But the Policy also
> distinguishes recommended from other fields (for which nothing is
> mentioned).  Given that it is there by default, I propose to mark it
> recommended.

Sounds right to me.

-- 
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: http://lists.debian.org/87d2xg8ukq@windlord.stanford.edu

Bug#697652: RFP: vimprobable2 -- Light-weight Webkit based browser with Vimperator's fingerfeel

[Axel Beckert]

Package: wnpp
Severity: wishlist

* Package name: vimprobable2
  Version : 1.2.0
  Upstream Author : Hannes Schueller et al.
* URL or Web page : http://www.vimprobable.org/
* License : MIT
  Description : Light-weight Webkit based browser with Vimperator's 
fingerfeel

Vimprobable is a web browser that behaves like the Vimperator plugin
available for Mozilla Firefox. It is based on the WebKit engine (using
GTK bindings). The goal of Vimprobable is to build a completely
keyboard-driven, efficient and pleasurable browsing-experience. Its
featureset might be considered "minimalistic", but not as minimalistic
as being completely featureless.

Despite there are already some vi-like Webkit GTK based browsers in
Debian (Luakit, Surf, Uzbl, Dwb and Xxxterm), this was the first one
with vi-like keybindings which was intuitively usable for me. A
comparison of most of these browsers is available at [0].

  [0] http://sourceforge.net/apps/trac/vimprobable/wiki/Alternatives

Vimprobable was started in March 2009 (i.e. before the first commits of
Surf, Uzbl and Luakit) as Vimpression, but has been discontinued a few
months later. Nevertheless it already had a community big enough
to take over. It has been renamed to Vimprobable in October 2009 (upon
wish of the original author) and that team seems to maintain it since
then.

Vimprobable is already offically packaged for at least ArchLinux,
FreeBSD and NetBSD.

Vimprobable1 and Vimprobable2 both recently saw their 1.0 release after
close to 4 years of developement, hence they can be considered stable
and mature.

As the lighter Vimprobable1 is just configurable via config.h, it seems
less suitable for Debian. The slightly bloatier but more featureful and
easier configurable Vimprobable2 seems to fit better.

There are already Ubuntu packages of Vimprobable2 at [1] and the package
of 1.2.0 builds and works fine on Wheezy, too.

  [1] https://launchpad.net/~serge-hallyn/+archive/vimprobable

The packages are not perfect, but all the show-stoppers I found so far
(like being a native package) seem easy to fix. I'd also help to get the
package in shape for Debian as I did some preliminary vimprobable1
packaging work[2] in the past.

  [2] https://github.com/xtaran/vimprobable

As vimprobable isn't my primary browser, I don't want to maintain it
alone (hence RFP and not ITP), but I'm open for co-maintaining it.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-|  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5


-- 
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/87zk0ko3xr@c-crosser.deuxchevaux.org