Bug#524660: ITP: mumble-django -- A web interface for a Mumble server, written as a Django project

[Michael Ziegler]

Package: wnpp
Severity: wishlist
Owner: Michael Ziegler 


* Package name: mumble-django
  Version : 0.5
  Upstream Author : Michael Ziegler 
* URL : http://bitbucket.org/Svedrin/mumble-django
* License : GPLv2 or later
  Programming Lang: Python
  Description : A web interface for a Mumble server, written as a Django 
project

mumble-django is a Django web interface application that configures a
Murmur server. It is able to create and remove server instances, start/stop
them, and configure them.

Furthermore, registered Django users can sign up for user accounts on the
configured vservers and change their registration names and passwords.

Main Features:
 * Channel viewer
 * Detailed server configuration via Django's Admin interface (for the hoster)
 * User registration: Users can register and manage their accounts themselves
 * Granting/revoking membership in the Admin group
 * existing server instances and users are recognized during installation
 * Admin group members can configure basic settings like MOTD and server
   password via the web interface, without getting access to settings like
   maximum user count and allowed bandwith
 * Does not require access to Murmur's database
 * Reusable: the Mumble app can easily be integrated into other Django
   projects

Prerequisites:
 * Murmur v1.1.5 or later, configured to connect to the system DBus
 * a web server capable of running Django (Apache2 with mod_wsgi recommended)
 * Django >= 1.0.2
 * DBus and python-dbus
 * django-registration
   


-- System Information:
Debian Release: 5.0.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFC: Better formatting for long descriptions

[Andreas Tille]

On Sat, 18 Apr 2009, Manoj Srivastava wrote:


   Frankly, I have no idea where this trade is going.


IMHO the problem is that you assume our suggestions are in contrast to
each other - but they are not.  I wanted to iron out suggestions how
to format the input in a standardised way.  What will be done afterwards
is the choice of people who are working with this input.  I don't care
whether they choose markdown, restructured text or just take your
perl code and use  /  instead of the additional blank lines
and wrapp the lines in lists in  /  tags if they need HTML
output.  But this is NOT to be discussed HERE (even if it does not
harm.  The point is that our input should ENABLE this which needs
a better standardisation of long descriptions.

You are one step after this - and your input is welcome - but there
is no contradiction.


   With a 6 line pre-processor, you can feed the grep-dctrl
provided Description fields to Markdown.


BTW, your pre-processor will need some additional lines if it comes to
second level lists (and yes, I'm sure this can easily be done - but
this is, and never was the point)


So, seems like we have come
somewhere -- we have had one investigation that leads one to believe
that there are a small fraction of packages using "o" as a bullet that
need to be changed, and apart fro that there are less than 50 packages
are affected


Great - let's iron out the advise how to format long descriptions
in our docs to enable us to write lintian checks and file bug reports.
Manoj, we really reached a point here!


(if we want to specify markdown as the markup language for
descriptions -- and these are the one where we have some unwanted
emphasis, a non-fatal result).


Please let's draw this to a different discussion.  People who are
responsible for packages.debian.org might be interested and adopt
your idea.


   There is a mechanism to pre-process  the description for
markdown (Perl implementation below). What more is needed for you to
think this is leading somewhere?


Did I gave the impression that I wanted more?  Honestly, I'd be
interested from what part of my mails you are drawing the conclusion
to enhance my communication skills.


   All I am doing with the code is inserting a line before the
lists. I am not generating html. I am not also handling the _other_
markup that markdown handles, that I presented as something that will
make the description more readable too. The markdown librarys does all
the heavy lifting fro the html generation. If you think my little perl
snippet is the equivalent for what markdown does, you have not looked
at markdown.


In the whole discussion I was talking about structuring the input
to ENABLE turning it to html (or whatever structured output you need).
You were discussing steps to actually *do* the step I just wanted to
provide the precondition for.  I just was saying if you need a
preprocessor for a library while you could reach a similar result
by tweaking the preprocessor a little bit.  I just do not want to
force any programmer to use markdown (even if it has advantages
admittedly as I also agreed to).  This was a *sidenote* because this
whole processing of the input is just not my point.


   I am not re-inventing the wheel when it comes to markup
languages.


Same for me - or am I writing in delirium???

And your divergence of the original topic just blurs the issue -
would you mind rereading my initial mail. [1] Do you agree that
long descriptions need enhancement or not?


   We know we needed _some_ pre-processing because we have the
paragraphs separated by ' .', but the code is pretty minimal.

--8<---cut here---start->8---
my $in=0;
while(<>) {
 chomp;  s/^ //g;  s/^\.\s*$//;
 if(/^\s+[\*\+\-]\s+/) { print "\n" unless $in++;}
 else  { $in=0; }
 print "$_\n"
}
--8<---cut here---end--->8---

   manoj

ps: This can easily become a shell function.


Again: Please asume for the rest of this thread that I'm not stupid
and know how scripts can be used.


__> grep-aptavail -s Description -P airport-utils | perl -e '
my $in=0;
while(<>) {
 chomp;  s/^ //g;  s/^\.\s*$//;
 if(/^\s+[\*\+\-]\s+/) { print "\n" unless $in++;}
 else{ $in=0; }
 print "$_\n"
}' | markdown
Description: configuration and management utilities for Apple AirPort base 
stations
This package contains various utilities to manage the Apple AirPort base
stations.

Be aware that Apple released several versions of the AirPort base station;
the original AirPort ("Graphite") was a rebranded Lucent RG-1000 base
station, doing 802.11a/b. The AirPort Extreme ("Snow") is an Apple-built
802.11a/b/g base station.

For the original Apple AirPort and the Lucent RG-1000 base stations only:


airport-config: base station configurator
airport-linkmon: wireless link monitor, gives information on the wireless
link quality between the base station and the associated hosts

Re: RFC: Better formatting for long descriptions

[Manoj Srivastava]

On Sat, Apr 18 2009, Andreas Tille wrote:

> On Sat, 18 Apr 2009, Manoj Srivastava wrote:
>
>>Here is an algorithm:
>> --8<---cut here---start->8---
>> we are not in a list
>> while reading each line, do
>>   remove leading space
>>   if the only non white space character on the line is a singe .
>> remove the dot
>>   if the line matches the regexp: '^\s+[\*\+\-]\s+'
>> if we are not in a list
>>   emit blank line first
>>   record we are not in a list
   s/not//
>>   else
>> if we are in a list
>>   record we are not in a list
>>   emit line
>> --8<---cut here---end--->8---
>>
>>People who can not convert this 13 line Psuedocode into a real
>> code should not be writing stuff to pretty print descriptions.
>
> Thanks for the trust in the programming skills of your fellow
> developers.  You obviosely are able to write the code to detect
> a list *without* using a library.  Wasn't it you who told me we
> should use a library to *avoid* inventing our own code?  So if
> you have this code which works perfectly on the input I'm
> suggesting since two weeks why you want to add an additional library
> on top of this.  I feel a little bit bored by this discussion which
> is running several circles starts to become personal without any
> real reason (I hope I did not gave any) and finally leads to nothing
> (at least this is my impression).

Frankly, I have no idea where this trade is going.

With a 6 line pre-processor, you can feed the grep-dctrl
 provided Description fields to Markdown. So, seems like we have come
 somewhere -- we have had one investigation that leads one to believe
 that there are a small fraction of packages using "o" as a bullet that
 need to be changed, and apart fro that there are less than 50 packages
 are affected (if we want to specify markdown as the markup language for
 descriptions -- and these are the one where we have some unwanted
 emphasis, a non-fatal result).

There is a mechanism to pre-process  the description for
 markdown (Perl implementation below). What more is needed for you to
 think this is leading somewhere?

>>> enclose lists in blank lines because people will tell you that
>>> this will look ugly in the existing interfaces.  So I would rather
>>> tend to "No for both" and this is the crux here.
>>
>>Frankly, I think this is very wrong.
>
> The solution does not work without the code you wrote above.  But you
> need this code anyway to detect lists in the long descriptions and so
> I wonder where the real profit of an additional library is.

*Sigh*.

All I am doing with the code is inserting a line before the
 lists. I am not generating html. I am not also handling the _other_
 markup that markdown handles, that I presented as something that will
 make the description more readable too. The markdown librarys does all
 the heavy lifting fro the html generation. If you think my little perl
 snippet is the equivalent for what markdown does, you have not looked
 at markdown.

I am not re-inventing the wheel when it comes to markup
 languages. 

We know we needed _some_ pre-processing because we have the
 paragraphs separated by ' .', but the code is pretty minimal.

--8<---cut here---start->8---
 my $in=0;
 while(<>) {
  chomp;  s/^ //g;  s/^\.\s*$//;
  if(/^\s+[\*\+\-]\s+/) { print "\n" unless $in++;}
  else  { $in=0; }
  print "$_\n"
}
--8<---cut here---end--->8---

manoj

ps: This can easily become a shell function.

__> grep-aptavail -s Description -P airport-utils | perl -e '
 my $in=0;
 while(<>) {
  chomp;  s/^ //g;  s/^\.\s*$//;
  if(/^\s+[\*\+\-]\s+/) { print "\n" unless $in++;}
  else{ $in=0; }
  print "$_\n"
}' | markdown
Description: configuration and management utilities for Apple AirPort base 
stations
This package contains various utilities to manage the Apple AirPort base
stations.

Be aware that Apple released several versions of the AirPort base station;
the original AirPort ("Graphite") was a rebranded Lucent RG-1000 base
station, doing 802.11a/b. The AirPort Extreme ("Snow") is an Apple-built
802.11a/b/g base station.

For the original Apple AirPort and the Lucent RG-1000 base stations only:


airport-config: base station configurator
airport-linkmon: wireless link monitor, gives information on the wireless
link quality between the base station and the associated hosts


For the Apple AirPort Extreme base stations only:


airport2-config: base station configurator
airport2-portinspector: port maps monitor
airport2-ipinspector: WAN interface monitoring utility


For all:


airport-modem: modem control utility, displays modem state, starts/stops
modem connections, displays the approximate connection time (Extreme only)


airport-hostmon: wireless host

Bug#524644: ITP: r-cran-rsymphony -- GNU interface to SYMPHONY solver from COIN-OR

[Dirk Eddelbuettel]

Package: wnpp
Owner: Dirk Eddelbuettel 
Severity: wishlist

* Package name: r-cran-rsymphony
  Version : 0.1-8
  Upstream Author : Reinhard Harter, Kurt Hornik and Stefan Theussl for
Rsymphony; various authors for SYMPHONY
* URL or Web page : http://R-Forge.R-project.org/projects/rsymphony,
http://www.coin-or.org/SYMPHONY/
* License : GPL-2 for R part, CPL for Symphony
  Description : GNU interface to SYMPHONY solver from COIN-OR

This is now being required by fPortfolio (aka r-cran-fportfolio) so I spent
the last hour packaging it up.  

Dirk


Draft debian/control (indented two spaces)

  Source: rsymphony
  Section: gnu-r
  Priority: optional
  Maintainer: Dirk Eddelbuettel 
  Build-Depends: debhelper (>= 5.0.0), r-base-dev (>= 2.9.0), cdbs
  Standards-Version: 3.8.1
  Homepage: http://R-Forge.R-project.org/projects/rsymphony
  
  Package: r-cran-rsymphony
  Architecture: any
  Depends: ${shlibs:Depends}, r-base-core (>= 2.9.0)
  Suggests: r-cran-runit
  Description: GNU R interface to the SYMPHONY MILP solver
   Rsymphony provides an interface from GNU R to the SYMPHONY mixed
   integer linear programming (MILP) solver. More information about
   SYMPHONY is at http://www.coin-or.org/SYMPHONY/

  
Draft debian/copyright (indented two spaces)

  This is the Debian GNU/Linux r-cran-timedate package of Rsymphony, an
  interface between GNU R and the SYMPHONY mixed integer linear
  programming solver. Rsymphony was written by Reinhard Harter, Kurt
  Hornik and Stefan Theussl. Symphony itself is part of the COIN-OR
  project for Operations Research (www.coin-or.org).
  
  This package was created by Dirk Eddelbuettel .
  The sources were downloaded from the main CRAN site
http://cran.r-project.org/src/contrib/
  and are also available from all CRAN mirrors as e.g.
http://cran.us.r-project.org/src/contrib/
  
  The package was renamed from its upstream name 'Rsymphony' to
  'r-cran-rsymphony' to fit the pattern of CRAN (and non-CRAN) packages
  for R.
  
  Copyright (C) 1994 - 2005 Free Software Foundation, Inc.
  Copyright (C) 2000 - 2007 International Business Machines and others.
  Copyright (C) 2008 - 2009 Reinhard Harter, Kurt Hornik and Stefan Theussl
  Portions Copyright (C) 2003Yan Xu, Jeff Linderoth, Martin Savelsberg 
and others.
  Portions Copyright (C) 2005Pierre Bonami and others
  Portions Copyright (C) 2006Francois Margot and others
  Portions Copyright (C) 2005COIN-OR.
  Portions Copyright (C) 2003Tim Helge Hultberg
  Portions Copyright (C) 2001 - 2002 Vivian De Smedt
  Portions Copyright (C) 2002 - 2003 Braden Hunsaker
  Portions Copyright (C) 2003 - 2004 University of Pittsburgh
  Portions Copyright (C) 2004Joseph Young
  Portions Copyright (C) 2003 - 2007 Lou Hafer, International Business Machines 
Corporation and others
  Portions Copyright (C) 2002 - 2004 Lou Hafer, Stephen Tse, International 
Business Machines Corporation and others
  Portions Copyright (C) 2005 - 2007 Lou Hafer
  Portions Copyright (C) 2002Tobias Pfender, International Business 
Machines Corporation and others.
  Portions Copyright (C) 2004 - 2006 Ted Ralphs and Lehigh University
  Portions Copyright (C) 2000 - 2008 Ted Ralphs 
  Portions Copyright (C) 2005 - 2007 Michael Trick and Ted Ralphs
  Portions Copyright (C) 2005Marta Eso and Ted Ralphs.
  Portions Copyright (C) 2007 - 2008 Stefan Vigerske and others.
  Portions Copyright (C) 1994X Consortium
  Portions Copyright (C) 2006 - 2008 Lehigh University
  License: GPL-2  (for the R integration)
  License: CPL  (Common Public License, for src/SYMPHONY/*)
  
  On a Debian GNU/Linux system, the GPL license (version 2) is included
  in the file /usr/share/common-licenses/GPL-2.
  
  For reference, the upstream DESCRIPTION file is included below:
  
Package: Rsymphony
Version: 0.1-8
Date: 2009-03-19
Title: Symphony in R
Author: Reinhard Harter, Kurt Hornik and Stefan Theussl
Maintainer: Kurt Hornik 
Description: An R interface to the SYMPHONY MILP solver (version
5.1.10).
License: GPL-2
Depends: R (>= 2.6.0)
URL: http://R-Forge.R-project.org/projects/rsymphony,
http://www.coin-or.org/SYMPHONY/
Packaged: Thu Mar 19 09:16:13 2009; hornik
Repository: CRAN
Date/Publication: 2009-03-19 12:24:10

  The Common Public License is included below (indented two spaces):
  
Common Public License Version 1.0

THE ACCOMPANYING PROGRAM IS PROVIDED UNDER THE TERMS OF THIS COMMON PUBLIC
LICENSE ("AGREEMENT"). ANY USE, REPRODUCTION OR DISTRIBUTION OF THE PROGRAM
CONSTITUTES RECIPIENT'S ACCEPTANCE OF THIS AGREEMENT.

1. DEFINITIONS

"Contribution" means:

a) in the case of the initial Contributor, the initial code and
documentation distributed under this Agreement, and

b) in the case of each subseque

Re: RFC: Better formatting for long descriptions

[Andreas Tille]

On Sat, 18 Apr 2009, Manoj Srivastava wrote:


   Here is an algorithm:
--8<---cut here---start->8---
we are not in a list
while reading each line, do
  remove leading space
  if the only non white space character on the line is a singe .
remove the dot
  if the line matches the regexp: '^\s+[\*\+\-]\s+'
if we are not in a list
  emit blank line first
  record we are not in a list
  else
if we are in a list
  record we are not in a list
  emit line
--8<---cut here---end--->8---

   People who can not convert this 13 line Psuedocode into a real
code should not be writing stuff to pretty print descriptions.


Thanks for the trust in the programming skills of your fellow
developers.  You obviosely are able to write the code to detect
a list *without* using a library.  Wasn't it you who told me we
should use a library to *avoid* inventing our own code?  So if
you have this code which works perfectly on the input I'm
suggesting since two weeks why you want to add an additional library
on top of this.  I feel a little bit bored by this discussion which
is running several circles starts to become personal without any
real reason (I hope I did not gave any) and finally leads to nothing
(at least this is my impression).


enclose lists in blank lines because people will tell you that
this will look ugly in the existing interfaces.  So I would rather
tend to "No for both" and this is the crux here.


   Frankly, I think this is very wrong.


The solution does not work without the code you wrote above.  But you
need this code anyway to detect lists in the long descriptions and so
I wonder where the real profit of an additional library is.


   Is the above algorithm proof enough for you? Or do I have to
write that into real code in your favourite porogramming language
before you can see it?


I hope you would not code the bug in line no. 9.

What you basically tried to prove is that you are keen on teaching your
fellow developers programming.  Your time would be much better spend if
you would bring the effort forward to finally reach a consensus how we
should change best practices for debian/control to enable the parsing
of list.  My suggestions I presented [1] are not in contrast to markdown
and what you finally are using for the description parsing tools -
the algorithm above or a library on top of it - does not matter at all
if we agree to some simple standard.

It would be really helpful if you would return to the constructive way
of discussion I observed in former times instead of bluring the issue
with distracting discussions.

Kind regards

  Andreas.

[1] http://lists.debian.org/debian-devel/2009/04/msg00643.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

Re: One-time cron output?

[Frank Lin PIAT]

Hello,

On Sat, 2009-03-14 at 23:50 +, Ben Hutchings wrote:
> On Sat, 2009-03-14 at 11:28 +0100, Adeodato Simó wrote:
> > 
> > I wanted to gather some opinions on this matter. I’ve recently applied
> > to the mlocate package a patch I received to skip running the daily
> > update of the database if the system is running on batteries.
> [...]
> 
> I think such a policy should be implemented by the cron daemon or by a
> common script, rather than by each package with a cron job.

It would be nice if [some of] those delayed jobs could be launched when
the laptop is connected back to power socket.

This could be achieved by dropping a flag when a job is skipped (a
symlink to the cron.d entry?)

Note that since the laptop batteries are lasting longer and longer, some
people won't connect their laptop during the day. (I now tend to work
plugged for 1h in the morning, then a few hours during the day as I
travel, then a few hours in the evening. I plug the laptop back into the
main before going to bed)

my 2cents,

Franklin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#524623: ITP: icedove-attachmentreminder -- Missing attachment warnings for Icedove

[Christoph Goehre]

Package: wnpp
Severity: wishlist
Owner: Christoph Goehre 

* Package name: icedove-attachmentreminder
  Version : 0.3.10
  Upstream Author : Daniel Folkinshteyn 
* URL : http://attachreminder.wiki.sourceforge.net
* License : GPL
  Programming Lang: Javascript
  Description : Missing attachment warnings for Icedove

This plugin for Icedove warns the user with a popup window if some reference to
an attachment is found in the composed mail text but no file is attached.


-- System Information:
Debian Release: 5.0
  APT prefers stable
  APT policy: (990, 'stable'), (50, 'testing')
Architecture: i386 (i686)


signature.asc
Description: Digital signature

Re: RFC: Better formatting for long descriptions

[Manoj Srivastava]

On Sat, Apr 18 2009, Andreas Tille wrote:

> On Sat, 18 Apr 2009, Vincent Danjean wrote:
>
>> Remove the first space, remove the '.' that are alone on their line,
>
> That's cheap.
>
>> add a blank line before enumeration (this last point seems the more
>> annoying to me: it can be difficult to automatically find where to
>> insert a blank line).
>
> Well - here is the crux which let's me wonder whether Manoj was
> right in his posting[1] when he claimed:
>
>> > If you make a suggestion please answer the following question:
>> >
>> >   A. Does the suggestion enable parsing logical structures like
>> >  two level itemize lists?
>> >  (This is what I want to approach and what is IMHO needed)
>>
>> Markdown and ReST, trivially.
>>
>> >   B. Does the suggestion enable keeping the majority of description
>> >  untouched and enables keeping the currently existing tools?
>> >  (This is important to gain any acceptance)
>>
>> Yes, for both.
>
> It is neither trivial to detect the point where to add the needed
> blank line nor would it be a solution to advise people alwasy to

Actually, it is pretty trivial. It is a second chanpeter
 exercise in K&R; it is a first month exercise in computer science 101.

Here is an algorithm:
--8<---cut here---start->8---
 we are not in a list
 while reading each line, do
   remove leading space
   if the only non white space character on the line is a singe .
 remove the dot
   if the line matches the regexp: '^\s+[\*\+\-]\s+'
 if we are not in a list
   emit blank line first
   record we are not in a list
   else
 if we are in a list
   record we are not in a list
   emit line
--8<---cut here---end--->8---

People who can not convert this 13 line Psuedocode into a real
 code should not be writing stuff to pretty print descriptions.

> enclose lists in blank lines because people will tell you that
> this will look ugly in the existing interfaces.  So I would rather
> tend to "No for both" and this is the crux here.

Frankly, I think this is very wrong.


> So while I perfectly agree with Manoj that voting on technical
> decisions is a bad idea I come back to my initial suggestion because
> my suggestions are technically equivalent but express a matter of
> taste of the developers which might lead to better acceptance.
>
> I would love if somebody could provide a proof that I'm wrong and
> there is a reliable way to turn long descriptions into proper markdown
> input to *really* be able to detect the lists.  If not I think I
> continue with my intention as described. [2]

Is the above algorithm proof enough for you? Or do I have to
 write that into real code in your favourite porogramming language
 before you can see it?

manoj
-- 
"The minority is always right." Henrik Ibsen 1828-1906
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Processed (with 1 errors): splashy prevents kernel modules to load

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign #524286 splashy
Bug#524286: general: kernel modules does not automatically load
Bug#524276: udev not loading hardware modules
Bug reassigned from package `general' to `splashy'.

> reassign #523449 splashy
Bug#523449: acpid fails to open input layer
Bug reassigned from package `hal' to `splashy'.

> severity #524286 critical
Bug#524286: general: kernel modules does not automatically load
Bug#524276: udev not loading hardware modules
Severity set to `critical' from `normal'

> merge #523449 #524286
Bug#523449: acpid fails to open input layer
Bug#524286: general: kernel modules does not automatically load
Mismatch - only Bugs in same state can be merged:
Values for `done mark' don't match:
 #523449 has `open';
 #524286 has `done'

> retitle #523449 splashy prevents kernel modules to load
Bug#523449: acpid fails to open input layer
Changed Bug title to `splashy prevents kernel modules to load' from `acpid 
fails to open input layer'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#524605: ITP: cupt -- alternative front-end for dpkg

[Eugene V. Lyubimkin]

Package: wnpp
Severity: wishlist
Owner: "Eugene V. Lyubimkin" 


* Package name: cupt
  Version : 0.1.0
  Upstream Author : Eugene V. Lyubimkin 
* URL : http://wiki.github.com/jackyf/cupt
* License : GPL3+ | Artistic
  Programming Lang: Perl
  Description : alternative front-end for dpkg

Description: alternative front-end for dpkg -- console interface

 This package provides a console interface to Cupt library, which is a
 re-implementation of libapt-pkg C++ library using Perl. The aim is to
 produce more strict, more robust, less buggy front-end than APT.
 .
 Cupt uses the same APT infrastructure, e.g. index files, deb cache
 archive files, configuration files. It understands some of widely used APT
 options.
 .
 Some features:
  - strict full-case resolver;
  - command-line and APT-like option name checker;
  - case-sensitive search;
  - pinning by source package name;
  - pinning by package groups using shell-like patterns;
  - configurable 'depends' and 'rdepends' subcommands;
  - 'satisfy' subcommand.
 .
 Its interface is mostly like apt-get/aptitude console interface.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#524286: Same here

[Khapin]

I'm having exactly the same problem here with udev 0.125-7 on a
Testing...
If there is any info/test I could do to help fixing that bug, just ask.

btw, this bug should have its severity set to "grave" or even "critical",
as it prevents the system from working properly: no mouse, no network, no
sound, no ACPI information about the battery, etc.

Cheers,

Khapin

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFC: Better formatting for long descriptions

[Andreas Tille]

On Sat, 18 Apr 2009, Vincent Danjean wrote:


Remove the first space, remove the '.' that are alone on their line,


That's cheap.


add a blank line before enumeration (this last point seems the more
annoying to me: it can be difficult to automatically find where to
insert a blank line).


Well - here is the crux which let's me wonder whether Manoj was
right in his posting[1] when he claimed:


> If you make a suggestion please answer the following question:
>
>   A. Does the suggestion enable parsing logical structures like
>  two level itemize lists?
>  (This is what I want to approach and what is IMHO needed)

Markdown and ReST, trivially.

>   B. Does the suggestion enable keeping the majority of description
>  untouched and enables keeping the currently existing tools?
>  (This is important to gain any acceptance)

Yes, for both.


It is neither trivial to detect the point where to add the needed
blank line nor would it be a solution to advise people alwasy to
enclose lists in blank lines because people will tell you that
this will look ugly in the existing interfaces.  So I would rather
tend to "No for both" and this is the crux here.

So while I perfectly agree with Manoj that voting on technical
decisions is a bad idea I come back to my initial suggestion because
my suggestions are technically equivalent but express a matter of
taste of the developers which might lead to better acceptance.

I would love if somebody could provide a proof that I'm wrong and
there is a reliable way to turn long descriptions into proper markdown
input to *really* be able to detect the lists.  If not I think I
continue with my intention as described. [2]

Kind regards

Andreas.


[1] http://lists.debian.org/debian-devel/2009/04/msg00652.html
[2] http://lists.debian.org/debian-devel/2009/04/msg00643.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

Re: lrmi vs new kernels vs libx86

[Evgeni Golov]

Hi David,

On Sun, 8 Mar 2009 21:07:29 +0100 David Paleino wrote:

> I prepared a package with an updated LRMI:
> 
> http://alioth.debian.org/~hanska-guest/apt/unstable/libx86_1.1+ds1-3.dsc
> 
> All the people involved: would you please testbuild your packages against it?
> Thank you.

Sorry that I didn't write yet, was somehow busy and forgot about this
issue.
Now I have tested -3 from your home and it works fine for me with v86d.
Still no luck with including it into the initrd, but that is not your
fault (it also happens when I build with the internal copy of
lrmi/x86emu).

Matthew, any plans on releasing a new version with David's patches
upstream?

Regards
Evgeni


pgplrvDbUKvSA.pgp
Description: PGP signature

Fwd: keep in contact

[Vipul .]

hi
i m seo vipul
Keep in contact


Thanks
vipul

Bug#524286: general: kernel modules does not automatically load

[B. L. Jilek]

On Thu, Apr 16, 2009 at 9:56 PM, Don Armstrong  wrote:

> On Thu, 16 Apr 2009, Marco d'Itri wrote:
> > On Apr 16, Holger Levsen  wrote:
> > > Marco, if this is not a udev bug, please reassign it to the proper
> > > package, but dont make users workaround you. Also note that 524276
> > > is about udev in stable, which is not etch anymore.
> >
> > I have no reason to believe that there is a bug (hint: "my computer
> > is not working as expected" is not a bug).
>
> Clearly something is wrong. At the time that this bug was closed you
> haven't even identified what the actual problem is or at the very
> least pointed the user at the type of information required so that the
> actual problem can be identified.
>
> > The user should ask for support on debian-user or a similar forum.
>
> If you want to delegate the initial triaging of your bugs to
> debian-user or some random forum, that's your business, but you still
> need to inform the user that they should ask
> debian-u...@lists.debian.org for assistance because you don't want to
> deal with what is likely a user configuration issue.
>
> Even a simple template response pointing people at the right resources
> would be useful.
>
>
I have fixed my problem.

One of the things I did was uninstall splashy. But I also had a bigger
problem.
There were missing rules in /etc/udev and /etc/udev/rules.d

I looked in packages:
udev_0.125-7_amd64.deb
udev_0.140-2_amd64.deb

and there are no *.rules files in the new package (udev_0.140-2_amd64.deb).

My system was missing all of the .rules that were in the
udev_0.125-7_amd64.deb
package.

So I was having issues with everything from ethernet cards to usb devices
and sound.
When I put the missing files in /etc/udev and /etc/udev/rules.d, everything
worked.

I don't know if these files should be in the new package or not, but my
system was
jacked until I replaced them.

-- 
B. L. Jilek   |  Debian Linux!
blji...@yahoo.com  |  GPG key: 11A5D1A4

Re: autoconf method in ifupdown

[Thomas Preud'homme]

On samedi 18 avril 2009 00:06:52 Guillem Jover wrote:
> On Fri, 2009-04-17 at 19:14:14 +0200, Thomas Preud'homme wrote:
> > I'm ready to do it but I think this makes more sense to submit the bug to
> > the upstream dev. Unfortunetely I couldn't find the web page of the
> > ifupdown upstream development. It's not a software specific to debian,
> > isn't it ?
>
> The Debian maintainers are the upstream devs, so filing a bug report
> to the BTS is what you are looking for. Although it's not specific to
> Debian, I think other distros also use it.

Perfect, I'll do in within a few days.

Thanks

>
> regards,
> guillem

Regards,

Thomas Preud'homme


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFC: Better formatting for long descriptions

[Ben Finney]

Peter Pentchev  writes:

> Just as a kind of clarification: Manoj, I think that Giacomo's
> comments were only to the *last* item of the text he quoted, not to
> the whole portion above it :) Thus, IMHO his first "really needed?"
> question referred specifically to the "ordered lists" item, and the "I
> don't think they are needed" referred specifically to the "underlines
> and strike-throughs", not to the emphasis, strong emphasis, etc.

Traps for new players: One must remember to trim irrelevant quoted
material so it's clear what the context of one's responses are.

-- 
 \“You can't have everything; where would you put it?” —Steven |
  `\Wright |
_o__)  |
Ben Finney


pgpE8rXLZJiKa.pgp
Description: PGP signature

Bug#524569: ITP: pqiv -- a minimalistic picture viewer for X

[Andreas Metzler]

Package: wnpp
Severity: wishlist
Owner: Andreas Metzler 

* Package name: pqiv
  Version : 0.8
  Upstream Author : Phillip Berndt 
* URL : http://www.pberndt.com/Programme/Linux/pqiv/
* License : GPLv2+
  Programming Lang: C
  Description : a minimalistic picture viewer for X

Pqiv is a rewrite of the small image viewer qiv that does not rely
on unmaintained libraries anymore. Pqiv is small, quick and easily
controllable either from the keyboard or by mouse klicks.



Yes, *another* image viewer. ;-) Afaik however the only similar one
(i.e. optimized for keyboard control and fullscreen mode) is feh,
which somehow manages to just not fel comfortable, although offering
more features.

I am not stuck on maintaining this myself, but have already prepared
preliminary packages.

See also 456133. 

cu andreas



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFC: Better formatting for long descriptions

[Vincent Danjean]

Andreas Tille wrote:
> But what exactly do I have to do to get the item lists marked?

Remove the first space, remove the '.' that are alone on their line,
add a blank line before enumeration (this last point seems the more
annoying to me: it can be difficult to automatically find where to
insert a blank line).

> grep-available -s Description -F Package airport-utils | markdown

grep-aptavail -s Description -F Package airport-utils | sed -e 's/^ \(.$\)\?//' 
-e '/: *$/a\\
' | markdown
Description: configuration and management utilities for Apple AirPort base 
stations
This package contains various utilities to manage the Apple AirPort base
stations.

Be aware that Apple released several versions of the AirPort base station;
the original AirPort ("Graphite") was a rebranded Lucent RG-1000 base
station, doing 802.11a/b. The AirPort Extreme ("Snow") is an Apple-built
802.11a/b/g base station.

For the original Apple AirPort and the Lucent RG-1000 base stations only:


airport-config: base station configurator
airport-linkmon: wireless link monitor, gives information on the wireless
link quality between the base station and the associated hosts


For the Apple AirPort Extreme base stations only:


airport2-config: base station configurator
airport2-portinspector: port maps monitor
airport2-ipinspector: WAN interface monitoring utility


For all:


airport-modem: modem control utility, displays modem state, starts/stops
modem connections, displays the approximate connection time (Extreme only)

airport-hostmon: wireless hosts monitor, lists wireless hosts connected
to the base station (see airport2-portinspector for the Snow)




  Regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial pacakges: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://perso.debian.org/~vdanjean/debian unstable main


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org