Bug#611429: ITP: python-django-websocket -- Websocket support for django.

[TANIGUCHI Takaki]

Package: wnpp
Owner: tak...@debian.org
Severity: wishlist

* Package name: python-django-websocket
  Version : 0.3.0
  Upstream Author : Gregor M$(D+d(Bllegger 
* URL or Web page : http://pypi.python.org/pypi/django-websocket
* License : BSD
  Description : Websocket support for django.





-- 
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/87vd18oy2k.wl%tak...@asis.media-as.org

Re: Safe file update library ready (sort of)

[Ted Ts'o]

On Fri, Jan 28, 2011 at 07:37:02AM +0100, Olaf van der Spek wrote:
> 
> Is there a way to log cases where (potentially) unsafe writes happen?
> Cases like truncation of an existing file, rename on a target that's
> not yet synced, etc.

Not really, because there are plenty of cases where it's perfectly OK
not to sync a file on close or on rename.  Any files created during a
build, for example, can easily be reproduced in the unlikely case of a
systme crash.  If you are untaring a source tree, it's fine not to
worry about syncing out the files, since presumably you can always
repeat the untar operation.  Or take git; when git is checking out
files into the working directory, there's no reason that has to be
done in a super-safe way.  On the other hand, when it is writing the
git object files and pack files, those had better be done safely.  At
the end of the day the application programmer needs to understand what
is going on, and write his code appropriately based on the needs of
his application with respect to reliability after a power crash.

So how can you just log warnings that the program has just done
something unsafe?  It's unsafe only if there's no other way to
reconstitute the data that was just written.  But that's not something
which is easily knowable.

(I know, I'm being *so* unfair; I'm expecting application programmers
to be competent...)

- Ted


-- 
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/20110129125308.ga19...@thunk.org

Re: Safe file update library ready (sort of)

[Olaf van der Spek]

On Sat, Jan 29, 2011 at 1:53 PM, Ted Ts'o  wrote:
> On Fri, Jan 28, 2011 at 07:37:02AM +0100, Olaf van der Spek wrote:
>>
>> Is there a way to log cases where (potentially) unsafe writes happen?
>> Cases like truncation of an existing file, rename on a target that's
>> not yet synced, etc.
>
> Not really, because there are plenty of cases where it's perfectly OK
> not to sync a file on close or on rename.  Any files created during a
> build, for example, can easily be reproduced in the unlikely case of a
> systme crash.  If you are untaring a source tree, it's fine not to
> worry about syncing out the files, since presumably you can always
> repeat the untar operation.  Or take git; when git is checking out
> files into the working directory, there's no reason that has to be
> done in a super-safe way.  On the other hand, when it is writing the
> git object files and pack files, those had better be done safely.  At
> the end of the day the application programmer needs to understand what
> is going on, and write his code appropriately based on the needs of
> his application with respect to reliability after a power crash.
>
> So how can you just log warnings that the program has just done
> something unsafe?  It's unsafe only if there's no other way to
> reconstitute the data that was just written.  But that's not something
> which is easily knowable.

If all potentially unsafe cases could be logged, the log can be
analyzed by a human to detect the real unsafe cases such that the
developers of those apps can be notified and the apps can be fixed.

-- 
Olaf


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

Bug#611445: ITP: haserl -- CGI scripting program for embedded environments

[Chow Loong Jin]

Package: wnpp
Severity: wishlist
Owner: Chow Loong Jin 


* Package name: haserl
  Version : 0.9.27
  Upstream Author : Nathan Angelacos 
* URL : http://haserl.sf.net
* License : GPL-2
  Programming Lang: C
  Description : CGI scripting program for embedded environments

Haserl is a small cgi wrapper that allows "PHP" style cgi programming, but uses
a UNIX bash-like shell or Lua as the programming language. It is very small, so
it can be used in embedded environments, or where something like PHP is too
big.
.
It combines three features into a small cgi engine:
 * It parses POST and GET requests, placing form-elements as name=value
   pairs into the environment for the CGI script to use.  This is somewhat like
   the uncgi wrapper.
 * It opens a shell, and translates all text into printable statements. All
   text within <% ... %> constructs are passed verbatim to the shell. This is
   somewhat similar to how PHP scripts are parsed.
 * It can optionally be installed to drop its permissions to the owner of the
   script, giving it some of the security features of suexec or cgiwrapper.



-- 
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/20110129135514.11153.97945.reportbug@localhost6.localdomain6

Re: Safe file update library ready (sort of)

[Goswin von Brederlow]

"Hendrik Sattler"  writes:

> "char buffer[0];" is veeery gcc-specific as the storage size of buffer
> is 0. According to the C99 standard:
> "6.7.5.2 Array declarators
>  Constraints
>  1 In addition to optional type qualifiers and the keyword static, the [ and
>] may delimit an expression or *. If they delimit an expression (which
>specifies the size of an array), the expression shall have an integer type.
>If the expression is a constant expression, it shall have a value greater
>than zero."

Iirc the [0] is the pre C99 syntax that behaves the same as [] in sane
compilers and still works in compilers that didn't support []. You would
get a few extra byte allocated in that case.

But yes. Best to do it right and screw the non C99 compilers. :)

> Either make this "char buffer[1];" and live with the fact that e.g.
> cppcheck will yell at you (better not), or use "safe_t x= ...; char
> *buffer = x + 1;" with or without explicit reference in safe_t (if you
> want to allocate in one block) or simply allocate it seperately.

Uh oh, no pointer arithmetic there. C99 does have the unspecified size
arrays at the end of a struct so that one can specify texactly this use
case.

> BTW: KDE4 is a very good example for failure with modern filesystems.
> I regularly loose configuration files when suspend-to-ram fails even
> if the configuration of the running programs were not changed. Yay :-(
> And this is with XFS, not Ext4! Filed a bug a looong time ago in
> KDE BTS. Reaction: none!
>
> HS

And the error is in something generic so every KDE app uses the same
horrible thing. :)

MfG
Goswin


-- 
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/874o8raghy.fsf@frosties.localnet

Bug#611450: ITP: node-stringprep -- ICU StringPrep profiles for Node

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name: node-stringprep
  Version : 0.0.2
  Upstream Author : Stephan Maka 
* URL : https://github.com/astro/node-stringprep
* License : Expat
  Programming Lang: C++
  Description : ICU StringPrep profiles for Node

 Node is an event-based server-side JavaScript engine.
 .
 node-stringprep provides a Node binding to ICU, exposing predefined
 Unicode normalization functions that are required by many protocols.



-- 
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/20110129150806.26627.44815.reportbug@localhost.localdomain

Re: Results of the App Installer Meeting

[Duncan Mac-Vicar P.]

On 01/27/2011 06:07 PM, David Kalnischkies wrote:

I am thinking of the AppStream project therefore as a big experiment to
work together and I have the strong hope that we can find more places
where we can work on together instead of against each other.


Agreed. And if you see we were able to come up with lot of agreements 
without falling in the typical two Linux traps:


- talking about packaging
- talking about GUI toolkits or desktop environments

We are focusing in the user and the simple problem of finding a cool app 
and install it. We are using PackageKit to solve technical issues in the 
current reality of Linux, but if the user gets the software as a Chrome 
extension or a full self contained image, he will not care, and we will 
slowly open our minds and leave more and more dogmas out to fulfill this 
goal.


Duncan


--
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/4d443175.2050...@suse.de

Re: Bug#611422: ITP: libmath-base85-perl -- Perl extension for base 85 numbers, as referenced by RFC 1924

[Niko Tyni]

On Sat, Jan 29, 2011 at 03:27:54PM +0900, TANIGUCHI Takaki wrote:
> Package: wnpp
> Owner: tak...@debian.org
> Severity: wishlist
> 
> * Package name: libmath-base85-perl
>   Version : 0.2 
>   Upstream Author : Tony Monroe
> * URL or Web page : http://cpan.org/
> * License : Perl
>   Description : Perl extension for base 85 numbers, as referenced by RFC 
> 1924
>  RFC 1924 describes a compact, fixed-size representation of IPv6 addresses
>  which uses a base 85 number system. Math::Base85 handles some of the uglier
>  details of it.

Do you really have a use case for this?

RFC 1924 is an April 1st one, and I've never seen anybody actually use
the base85 representation of IPv6 addresses anywhere.

(In case somebody wants a quick try, ipv6calc supports it:
 % ipv6calc -O base85 2607:f8f0:610:4000:214:38ff:feee:b65a
 No input type specified, try autodetection...found type: ipv6addr
 B7RDhRib#Y+VwlwuPBOG
)
-- 
Niko Tyni   nt...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110129184558.GA7227@madeleine.local.invalid

Re: Bug#611422: ITP: libmath-base85-perl -- Perl extension for base 85 numbers, as referenced by RFC 1924

[brian m. carlson]

On Sat, Jan 29, 2011 at 08:45:58PM +0200, Niko Tyni wrote:
> Do you really have a use case for this?

It looks like this is not generic enough, but if it were, it could be
used for PostScript and PDF, which can use Ascii85.  The printable
characters used there are different, though.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: package testing, autopkgtest, and all that

[Iustin Pop]

On Fri, Jan 28, 2011 at 03:19:32PM +, Ian Jackson wrote:
> Iustin Pop writes ("Re: package testing, autopkgtest, and all that"):
> > I think even without a full archive integration, having this spec
> > publicised a bit among developers would be useful; I know I'm looking
> > forward to adapting my own packages.
> 
> Perhaps I should be trying to get the spec referred to in useful
> places ?

My belief is that yes, that's a good idea. But I'm a bit surprised that
other people didn't chime in on this thread.

regards,
iustin


signature.asc
Description: Digital signature

Bug#611500: general: Can't apply cursor theme changes

[Guilherme Salazar]

Package: general
Severity: minor

Hello.
I've tried to change the cursor theme but I can't see any effect on the main
cursor (pointer).

Please, check it.  :)

Thank you.



-- System Information:
Debian Release: 6.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.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/20110130014219.3042.85927.reportbug@inspiron.SALAZAR

Bug#611508: ITP: Sahana-Eden -- Free and Open Source Disaster Management System

[Sana Khan]

Package: wnpp
Severity: wishlist
Owner: Sana Khan 


* Package name: Sahana-Eden
  Version : 0.5.3
  Upstream Author : Lanka Software Foundation 
* URL : http://www.sahana.lk
* License : LGPL
  Programming Lang: Python
  Description : Free and Open Source Disaster Management System

Sahana-Eden is a project of the Sahana Software Foundation. 
Sahana is a Free and Open Source Disaster Management Sytem. 
It is a web based collaboration tool that addresses the common coordination
problems during a disaster from finding missing people,managing aid,
managing volunteers, tracking camps effectively between Government groups,
the civil society (NGOs) and the victims themselves.



-- 
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/20110130151656.2199.87774.report...@sana.sana