Re: [dd-list] Please use Architecture: linux-any

[Samuel Thibault]

gregor herrmann, le Sun 13 Apr 2014 02:25:18 +0200, a écrit :
> On Sun, 13 Apr 2014 01:34:52 +0200, Samuel Thibault wrote:
> 
> > Here is a refreshed list of the packages that should probably use
> > Architecture: linux-any, please consider using it.
> 
> > Debian Perl Group 
> >libvideo-ivtv-perl
> 
> % grep Architecture debian/control 
> Architecture: linux-any kfreebsd-any
> 
> So hurd is excluded, should kfreebsd also go away?

Well, kfreebsd currently gets

ivtv.xs:5:25: fatal error: linux/types.h: No such file or directory

but perhaps libvideo-ivtv-perl could be fixed so it can use kfreebsd's
v4l layer.

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140413062640.GG5323@type

Re: Why Debian

[Pirate Praveen]

2014-04-12 21:46 GMT+05:30, Alberto Salvia Novella :
> Why you choose to develop in Debian over any other distribution?

Because my contributions are respected equally, in most other
distributions my contributions will be treated second class, subject
to wishes of managers, even those who don't contribute technically in
that area. There was a concrete example when I tried to get emacs
installed by default when a user chooses my language (Malayalam),
because at that time only emacs terminal emulator could display
Malayalam correctly. But it was rejected because the desktop team did
not want to support another terminal emulator. It would have still be
acceptable if a manager working on i18n made that decision.

The reason I switched to Debian was when another distribution which
took everything from debian refused to contribute back something
better it developed. I want to spent my efforts on someone who treats
me as their own member rather than just free work.

I love democracy, where everyone has a say and have a chance to make
the changes they want rather than depending on someone.
-- 
പ്രവീണ്‍ അരിമ്പ്രത്തൊടിയില്‍
You have to keep reminding your government that you don't get your rights
from them; you give them permission to rule, only so long as they follow the
rules: laws and constitution.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caoo+evpdpza1pqpc+2_9+1+qb9ndodjmvmasw+uxlr2xtwj...@mail.gmail.com

Re: Having fun with the following C code (UB)

[Russ Allbery]

Shachar Shemesh  writes:
> On 13/04/14 05:39, Russ Allbery wrote:

>> One can make a good argument that such checks are exactly what you
>> should be doing.

> Then the answer is very simple. Write in Java.

There are a lot of reasons other than the absolute fastest performance you
can possibly muster to write something in C instead of Java.  For example,
if you're writing an Apache or PAM module, Java is not very useful, but
that doesn't mean you need micro-optimized signed integer math or need to
worry about the few instructions it takes to check parameters for whether
they're NULL.

There are some very experienced C programmers that make extensive use of
preconditions and checks.  For example, there was an article in
Communications of the ACM within the past year (sadly, I don't remember
exactly where and a quick search didn't help me out) that talked about a C
coding style that aimed for defining checks for every non-trivial
statement.  With some macro assistance, the resulting code wasn't too
ugly, and the result is rather appealing.  It's been something I've been
pondering experimenting with since reading that article.

> I am not a compiler writer, so I have no actual data. I suspect your
> common 20k line will yield about a thousand such warnings, the huge
> majority of which there will be nothing for you to do about.

> Also, it turns out gcc does have such an option. See
> http://www.airs.com/blog/archives/120. -Wstrict-overflow will let you
> know when the optimizer uses the assumption of no overflow to change
> other code.

Thanks for the pointer to that option!  I'd missed that.

I enabled -fstrict-overflow -Wstrict-overflow=5 -Werror in my standard
utility library, which has about 13,000 lines of C, and got one additional
warning, which was trivial to fix (and which was in a bit of code that has
a rather bad smell and has been on my list to rewrite when I get a
chance).  So I'm not horribly impressed by your doomsday worries.  :)
That said, I believe that warning flag does not catch all possible
overflows, just the ones where GCC happens to do an optimization.

I use all sorts of warning flags, with -Werror, that I've seen other
people claim are completely unworkable in practice, like -Wwrite-strings
and -Wsign-compare.  They're not.  They just require care and attention
and writing high-quality C code.

>> Put a different way, the answer to your question is quite different if
>> that function were instead:
>>
>> int compute_offset_into_network_packet( int a, int b )
>> {
>> return a+b;
>> }
>>
>> No?

> In most cases, you will overflow the packet long before you overflow the
> integer.

Not if either a or b is coming from the network, which is the case I'm
concerned about.  You should do bounds-checking before using them to look
at offsets in a packet.  Tons and tons of security vulnerabilities have
happened due to lack of that bounds-checking, or getting the check wrong.
If there was a way for the compiler to check whether you've done that
bounds-checking before you start doing math with those values, that would
be very helpful.  Obviously, that warning might not be appropriate for all
code, but gcc has a rich pragmata system for handling that.

> If that's the case, the compiler won't help you.

That's the problem with C code in general: the compiler doesn't help you
enough.  Which is why I like seeing more warnings and smarter compilers
that can, from the code, work out what invariants you've established and
then warn you when you haven't checked for ones that may be important.

clang, for example, does a great job of this (far better than gcc) at
detecting variables that may be NULL at the point of use.

There are, obviously, limits, since the C language semantically doesn't
give either the author or the compiler a lot of help.  But there are still
opportunities for improvement.  Ten years ago, I would have said that a
lot of the diagnostics that clang provides were impossible in C because
there just wasn't enough information available to the compiler.  I was
wrong.

> Like I said before, I am not against the compilers warning about such
> cases. I just think that these warnings need to be done very carefully,
> or they become worse than useless.  As such, if you see a case in which
> you feel gcc (or clang, or whatever) should warn, by all means open a
> bug for it.  Just make sure you make it a "feature request" and not a
> "security hole" severity.  In other words, don't get mad merely because
> the compiler author did not read your mind.

I'll be sure to keep that in mind, since I've never reported a bug or
discussed issues with compiler writers before.

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

Re: Having fun with the following C code (UB)

[Shachar Shemesh]

On 13/04/14 05:39, Russ Allbery wrote:
> One can make a good argument that such checks are exactly what you should
> be doing.
Then the answer is very simple. Write in Java.
>> My understanding of things is that undefined behaviors are fairly
>> common, and almost always benign. Look at the following code:
>> int add( int a, int b )
>> {
>> return a+b;
>> }
>> Do you really want to get a "Warning: signed integer overflow yields
>> undefined behavior" on this function?
> I would certainly like to be able to enable such a thing.  I write a lot
> of code where I'd love the compiler to double-check that I've established
> bounds checks on a and b before doing the addition that guarantee that it
> won't overflow.
I am not a compiler writer, so I have no actual data. I suspect your
common 20k line will yield about a thousand such warnings, the huge
majority of which there will be nothing for you to do about.

Also, it turns out gcc does have such an option. See
http://www.airs.com/blog/archives/120. -Wstrict-overflow will let you
know when the optimizer uses the assumption of no overflow to change
other code.
>
> Put a different way, the answer to your question is quite different if
> that function were instead:
>
> int compute_offset_into_network_packet( int a, int b )
> {
> return a+b;
> }
>
> No?
>
In most cases, you will overflow the packet long before you overflow the
integer. If that's the case, the compiler won't help you. There is a
good case to claim that the warning would be appropriate for the
following code:

int compute_offset_into_network_packet( int a, int b )
{
int offset = a+b;
if( offset<0 || offset>PACKET_SIZE )
offset = 0;

return offset;
}

But, then again, what should the warning be? Like I said before, if you
don't like to deal with overflows, use Java and take Java's performance
hit. In fact, most of the world is doing precisely that.

Like I said before, I am not against the compilers warning about such
cases. I just think that these warnings need to be done very carefully,
or they become worse than useless. As such, if you see a case in which
you feel gcc (or clang, or whatever) should warn, by all means open a
bug for it. Just make sure you make it a "feature request" and not a
"security hole" severity. In other words, don't get mad merely because
the compiler author did not read your mind.

I don't know whether -Wstrict-overflow is on for -Wall (or -Wextra). If
it isn't, I do think it should be. Just checked, and it is on for -Wall,
sort of. See http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html.

Shachar

Re: Having fun with the following C code (UB)

[Russ Allbery]

Shachar Shemesh  writes:

> I will point out that it is not always is possible, and is quite often
> not easy. For example, the famous "undefined after NULL dereference"
> would probably cause a warning every time a function uses a pointer it
> was given without first validating its non-NULLness.

One can make a good argument that such checks are exactly what you should
be doing.

I used to be mildly opposed to this coding style since I felt like it led
to a lot of code clutter, but the more time I spend looking at security
vulnerabilities, the more I've come around to that approach.  I'm still
not sure that I want shared libraries calling assert(), but on the other
hand I can think of a lot of places where I'd rather have the shared
library call assert() than to go on and quietly do something bogus.
(Best, of course, is if you can return some sort of error in a reasonable
way, but that does force an often-awkward way of writing code.)

> My understanding of things is that undefined behaviors are fairly
> common, and almost always benign. Look at the following code:

> int add( int a, int b )
> {
> return a+b;
> }

> Do you really want to get a "Warning: signed integer overflow yields
> undefined behavior" on this function?

I would certainly like to be able to enable such a thing.  I write a lot
of code where I'd love the compiler to double-check that I've established
bounds checks on a and b before doing the addition that guarantee that it
won't overflow.

Put a different way, the answer to your question is quite different if
that function were instead:

int compute_offset_into_network_packet( int a, int b )
{
return a+b;
}

No?

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

Re: Having fun with the following C code (UB)

[Shachar Shemesh]

On 12/04/14 23:38, Henrique de Moraes Holschuh wrote:
> On Thu, 10 Apr 2014, Shachar Shemesh wrote:
>> I never did understand what people expect. gcc uses the undefined
> Warn the hell out of any line of code with per-spec undefined behaviour, if
> not by default, at least under -Wall.
I have no argument with that, in those places it is possible.

I will point out that it is not always is possible, and is quite often
not easy. For example, the famous "undefined after NULL dereference"
would probably cause a warning every time a function uses a pointer it
was given without first validating its non-NULLness.

> THAT would be a good start.  Too bad not even gcc knows every time it hits
> undefined behaviour...
My understanding of things is that undefined behaviors are fairly
common, and almost always benign. Look at the following code:

int add( int a, int b )
{
return a+b;
}

Do you really want to get a "Warning: signed integer overflow yields
undefined behavior" on this function?

Shachar

Re: Changelogs - was: Re: [dd-list] Please use Architecture: linux-any

[Paul Wise]

On Sun, Apr 13, 2014 at 9:31 AM, John Paul Adrian Glaubitz wrote:

> So, in order to avoid situations like these in the future, please write
> proper changelogs, people! Your future self or the future maintainer
> of your package will be very glad to have them. It can save you or them
> lots of time digging through mailing list archives, commit histories
> and similar resources.

Some best practices for debian/changelog are written in devref:

https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-debian-changelog

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6HbLQO3xpyO48u_ZV_JgES6urcM=fmUhqFMB1=xlxt...@mail.gmail.com

Changelogs - was: Re: [dd-list] Please use Architecture: linux-any

[John Paul Adrian Glaubitz]

On 04/13/2014 02:25 AM, gregor herrmann wrote:
> 
> (The git history + d/changelog don't say why I changed this in 2011,
> I guess it was a similar request :))

And now you know why I am always so nitpicky about changelogs :).

As someone who has been reviewing several dozen packages over the past
18 months when sponsoring them, I have seen many packages where the
debian/changelog had many useless or virtually empty entries.

Things like "Fix a minor bug in xyz" or "Fix bug #133222" aren't really
what you'd expect from a changelog. Instead, a proper changelog entry
should include exactly what changes were made and why there were made,
e.g.:

* Add missing build dependency on libabc-dev. Fixes FTBFS on powerpc.
  (Closes: #122333)

* Add debian/patches/0001-hardening.patch to pass proper compiler and
  linker flags necessary for hardening.

Just providing the bug number isn't helpful either. Some older bugs
I have searched for aren't actually accessible through the bug tracker
anymore. And, even if the bug number is included, there is no guarantee
the bug report actually documents the cause of the bug or the changes
that were made to remedy it. Some bug reports don't even include
any discussions besides the original bug report and the automated
message which closed the bug when the fixed version was uploaded.

So, in order to avoid situations like these in the future, please write
proper changelogs, people! Your future self or the future maintainer
of your package will be very glad to have them. It can save you or them
lots of time digging through mailing list archives, commit histories
and similar resources.

And, while you're at it, please use proper grammar, punctuation,
spelling, indentation and avoid trailing spaces :).

PS: If you're maintaining your packages source in git, just use
git-dch to create a nicely formatted and complete changelog
entry including all changes since the last package revision.
It usually just involves some additional editing since git-dch
doesn't wrap lines after 80 characters (which lintian will
complain about), for example (I should file a bug against
git-dch, maybe).

Thank you!

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



signature.asc
Description: OpenPGP digital signature

Re: [dd-list] Please use Architecture: linux-any

[gregor herrmann]

On Sun, 13 Apr 2014 01:34:52 +0200, Samuel Thibault wrote:

> Here is a refreshed list of the packages that should probably use
> Architecture: linux-any, please consider using it.

> Debian Perl Group 
>libvideo-ivtv-perl

% grep Architecture debian/control 
Architecture: linux-any kfreebsd-any

So hurd is excluded, should kfreebsd also go away?

(The git history + d/changelog don't say why I changed this in 2011,
I guess it was a similar request :))


Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Ludwig Hirsch: Die gottverdammte Pleite


signature.asc
Description: Digital Signature

[dd-list] Please use Architecture: linux-any

[Samuel Thibault]

Hello,

Here is a refreshed list of the packages that should probably use
Architecture: linux-any, please consider using it.

Samuel

Alexander Wirt 
   libnfnetlink
   libnfnetlink (U)

Andreas Schuldei 
   uml-utilities (U)

Anibal Monsalve Salazar 
   apmd

Ard van Breemen 
   vlan

Cyril Brulebois 
   xserver-xorg-video-sisusb (U)

Dariusz Dwornikowski 
   kerneltop

Debian Hamradio Maintainers 
   baycomusb
   libax25
   z8530-utils2

Debian Perl Group 
   libvideo-ivtv-perl

Debian QA Group 
   mouseemu

Debian X Strike Force 
   xserver-xorg-video-sisusb

Frederic Peters 
   iptraf

Gaudenz Steinlin 
   mouseemu

Gerfried Fuchs 
   beep

gregor herrmann 
   libvideo-ivtv-perl (U)

Gustavo Franco 
   kerneltop

Guus Sliepen 
   inputlirc
   libraw1394

Hamish Moffatt 
   baycomusb (U)
   libax25 (U)
   z8530-utils2 (U)

Jaime Robles 
   baycomusb (U)
   libax25 (U)
   z8530-utils2 (U)

Jochen Friedrich 
   arptables
   ebtables

Jonathan Niehof 
   joy2key

Krzysztof Burghardt 
   esekeyd

Laurence J. Lane 
   iptables

Loic Minier 
   vlan (U)

Mario Lang 
   screader

Mattia Dongili 
   uml-utilities (U)

Max Kellermann 
   libnfnetlink (U)

Michael Biebl 
   libnl
   lksctp-tools

netfilter maintainers 
   libnfnetlink

Otavio Salvador 
   mtd-utils (U)

Patrick Ouellette 
   baycomusb (U)
   libax25 (U)
   z8530-utils2 (U)

Peter De Schrijver (p2) 
   linux-atm

Peter Samuelson 
   gpm

Pierre Chifflier 
   nufw

Radu Spineanu 
   fprobe-ulog

Riku Voipio 
   mtd-utils

Ryan Niebur 
   inotify-tools

Santiago Garcia Mantinan 
   bridge-utils

tony mancill 
   libvideo-ivtv-perl (U)

Torsten Werner 
   libcap2

User Mode Linux Maintainers 
   uml-utilities

William Dauchy 
   ebtables (U)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140412233452.ga20...@type.home.polyno.me

Re: default messaging/VoIP client for Debian 8/Jessie

[Toni Mueller]

On Tue, Apr 01, 2014 at 04:07:24PM +0800, Thomas Goirand wrote:
> BTW, it'd be nice to have a backport of Jitsi. Not sure how much work
> that would be though (there must be lots of java dependencies...).

I recently installed 2.5.5190-1 on Wheezy without much trouble, but
imho, the operational issues are much bigger than the possible
dependencies (eg. no roster on amd64).

Not sure how I to usefully contribute, though... their Wiki basically
says (my perception only) "spend your days with us, or go away".


Kind regards,
--Toni++


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140412232536.ga20...@spruce.wiehl.oeko.net

Re: Why Debian

[Manoj Srivastava]

On Sat, Apr 12 2014, Alberto Salvia Novella wrote:

> Why you choose to develop in Debian over any other distribution?

Because I could contribute. I looked at other UNIX like
 operating systems, and Linux, and then Debian, had the least barriers
 to entry for contribution. Why is being able to contribute important
 (apart from making one feel good -- which is a good reason, but too
 highly subjective to be of interest to most people)?  Well, it gives
 one a voice in how the distribution co-evolves with you. I can honestly
 say that after all the time I have been using it, now Debian works like
 my brain thinks and OS should :-)

manoj
-- 
"Cats are smarter than dogs.  You can't get eight cats to pull a sled
through snow."  --Jeff Valdez
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


signature.asc
Description: PGP signature

Re: Having fun with the following C code (UB)

[Henrique de Moraes Holschuh]

On Thu, 10 Apr 2014, Shachar Shemesh wrote:
> I never did understand what people expect. gcc uses the undefined

Warn the hell out of any line of code with per-spec undefined behaviour, if
not by default, at least under -Wall.

THAT would be a good start.  Too bad not even gcc knows every time it hits
undefined behaviour...

> Are you really sure you want to have slower code just so that your
> corner cases are easier for you? How is that a reasonable trade-off to make?

Yes in just about everything that did not ask for -On where n > 2.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140412203827.ga25...@khazad-dum.debian.net

Re: Why Debian

[Russ Allbery]

Alberto Salvia Novella  writes:

> Why you choose to develop in Debian over any other distribution?

Because I have some control over my work, some say in the policies that
affect me, and the freedom to do things the right way, as opposed to
having some manager or company decide on policy without any meaningful
input from anyone else on what that policy should be.

There are other distributions with that property, but I think Debian is
the largest and most mature, which for me makes it more interesting.

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

Bug#744308: ITP: json-schema-validator -- JSON schema validation utility

[Neil Williams]

Package: wnpp
Severity: wishlist
Owner: Neil Williams 

* Package name: json-schema-validator
  Version : 2.3.1
  Upstream Author : Zygmunt Krynicki 
* URL : https://github.com/zyga/json-schema-validator
* License : LGPL-3.0
  Programming Lang: Python
  Description : JSON schema validation utility

 This package provides a JSON Schema validator
 conforming to a subset of second draft of the specification.
 .
 JSON files can be verified against a schema expressed in the
 python source code, producing either a SchemaError exception
 or ValidationError exception.

I'm using this package as a dependency of a validation architecture
which is due for packaging later. The upstream author is one of
the uploaders and will be seeking DM status in due course.
Packaging to be maintained in github.
https://github.com/codehelp/pkg-json-schema-validator


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140412201516.30529.80369.reportbug@sylvester.codehelp

Bug#744306: ITP: bookie -- Python based delicious.com replacement

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij 

* Package name: bookie
  Version : 0.0
  Upstream Author : Rick Harding 
* URL : http://www.bmark.us/
* License : AGPLv3
  Programming Lang: Python
  Description : Self-hosted bookmark management service

Bookie is a self-hosted bookmark management service. It supports
multiple users. Bookmarks can be created, tagged and managed through a
web service or a Chromium or Iceweasel extension.


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

Re: Why Debian

[Wookey]

+++ Alberto Salvia Novella [2014-04-12 18:16 +0200]:
> Why you choose to develop in Debian over any other distribution?

Because of the wide architecture support.

That what was what got me involved in the first place.

And I also really liked the regularity of it as a distro, from an
admin/user point of view (files being placed consistently, policy on
things as mundane as the delete/backspace key, and applied everywhere,
along with excellent upgradeability.  Having also used Red Hat (5)
Debian seemed significantly beter in these various technical ways.

14 years later the original reasons have not gone away, which is
pleasing, and now that I know how the tools and community work I have
no desire to learn it all again for some other distro :-)

Why do you ask?

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140412185601.gh15...@stoneboat.aleph1.co.uk

Re: Why Debian

[Arturo Borrero Gonzalez]

On 12 April 2014 18:16, Alberto Salvia Novella  wrote:
> Why you choose to develop in Debian over any other distribution?
>

For me, Debian is the best distro. That's my main reason.

Also:
 * I use Debian for all (from netbooks, laptops, desktop, to
high-demand servers).
 * There is a big community.
 * The technical level is high. Is challenging. I want to keep that
and I want to contribute and be a part of it.
 * Debian project as a FLOSS project is serious. I like important
things to be serious and meticulous.
 * I like the 'Debian style' and policy. Many aspects: FHS, packages
management, etc..
 * Here, there are some great hackers I want to learn from.
 * There isn't one big company making decision based on 'the market'.

I'm neither DD nor DM, but I do develop.
-- 
Arturo Borrero González


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAOkSjBjJZSdVePdL-d+QtujkFEC8DfE3xui+o=txlp+lh5b...@mail.gmail.com

Bug#744305: ITP: rsbackup -- rsync-based backup utility

[Matthew Vernon]

Package: wnpp
Severity: wishlist
Owner: Matthew Vernon 

  Package name: rsbackup
  Version : 0.4.3
  Upstream Author : Richard Kettlewell 
  URL : http://www.greenend.org.uk/rjk/2010/rsbackup.html
  License : GPL
  Programming Lang: C++
  Description : rsync-based backup utility
 Backups are stored as complete filesystem trees on a (perhaps
 external) hard disk.  Multiple backups use hard links between
 identical files to save space.
 .
 Backups may be taken from multiple machines (over SSH) and stored to
 multiple disks.
 .
 Backups may be made automatically, i.e. without relying on the
 operator to remember to make a backup.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140412172344.5306.81223.report...@aragorn.weathertop.principate.org.uk

Re: Why Debian

[Neil Williams]

On Sat, 12 Apr 2014 18:16:22 +0200
Alberto Salvia Novella  wrote:

> Why you choose to develop in Debian over any other distribution?
> 

My reasons are personal - I tried lots and lots of other distributions
before finding that Debian suits the way I want a distribution to work
better than any of the others. The vast majority of the tools work the
way I'm happy to work. Since deciding, I've made lots of friends in the
Debian community and there are lots of things I can do in Debian, even
if I'm not as active now as I was in the first couple of years.

If you don't use Debian, it's hard to see why you should want to
develop it.

There's also the question of whether to work in Debian or just work
upstream or some combination of the two. I've always done both but
basing all my upstream work on Debian. Trying to do one upstream
project on multiple platforms is hard unless you have a sufficiently
diverse team. Most free software upstream teams are individuals or very
small teams.

Scratch your own itch. If you like how Debian does things and want
something inside Debian fixed, then do the work. If that work is good
enough, it can be accepted into Debian. Your work needs to speak for
you. Ignore the vocal minority who don't contribute, get the source
code and fix stuff - that's how it works.

Finally, make your own mind up - don't use my reasons or those of anyone
else as the basis for your decision.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



signature.asc
Description: PGP signature

Why Debian

[Alberto Salvia Novella]

Why you choose to develop in Debian over any other distribution?


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/534966d6.2020...@gmail.com

Bug#744298: ITP: python-convoy -- WSGI app for loading multiple files in the same request

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij 

* Package name: python-convoy
  Version : 0.2.4
  Upstream Author : Canonical Javascripters
* URL : http://launchpad.net/convoy/
* License : AGPLv3
  Programming Lang: Python
  Description : WSGI app for loading multiple files in the same request

Convoy is a WSGI app for loading multiple CSS and JavaScript files in
one request. It's built to be compatible with the YUI Loader.

convoy is already packaged in Ubuntu; I'll base my packages on the
Ubuntu packages.

convoy is a dependency for bookie (git://github.com/bookieio/bookie)


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

Bug#744293: ITP: python-breadability -- Reworked Python Readability parsing library

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij 

* Package name: python-breadability
  Version : 0.1.2
  Upstream Author : Rick Harding 
* URL : http://github.com/bookieio/breadability
* License : BSD
  Programming Lang: Python
  Description : Reworked Python Readability parsing library

Python module that can clean up HTML documents to make them more
easily readable.

This is fork of the python-readability module, cleaned up and with
additional tests.

This is a dependency for bookie (http://github.com/bookieio/bookie)


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

Re: the importance of defaults (was: Debian default desktop environment)

[alberto fuentes]

On Sat, Apr 12, 2014 at 1:15 PM, Jonas Smedegaard  wrote:
>> Some numbers with my free interpretation from ubuntu popcon:
>> unity is installed in 605_209 machines, but its used regularly only by
>> 46_210
>>
>> Thats a very low number by all metrics for a default desktop [0].
>> People dislike it. People dislike disruptive
>
> ...or those people simply do not use a desktop on those installations?
>
> Only if popcon numbers for xfce/kde/whatever add up to somewhere near
> the missing amount can you reasonably conclude distaste for a particular
> desktop as reason, I believe.

The number of the rest of the desktops are severely skewed towards
defaults. Thus, is very hard to add up the rest of the desktops vs the
default. The point was very well illustrated with Ariely ted talk if
you know or have watched the talk

I think that the number being low says something already. if people is
not going to run a desktop at all, they would install ubuntu server.
if you know enough not to run desktop you know enough not to install
desktop at all

People installing regular ubuntu desktop and those very low numbers,
even if that means no desktop at all, says something about the
default. It also match my experience that people dont like disruptive
and dont being disruptive would be a good default

confirmation bias? it very well might be. These are all free
interpretation of the already skewed popcon data anyway

Can you pull data from popcon in the past to add some more numbers and
graphs to my free interpretation?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/calkubt7uqdznyya04yvkd9+ttwds3t7s97xv9mwnxlnsb1a...@mail.gmail.com

Re: the importance of defaults (was: Debian default desktop environment)

[Fabio Rafael da Rosa]

Em 12-04-2014 08:15, Jonas Smedegaard escreveu:

Quoting alberto fuentes (2014-04-12 12:23:46)

I had to leave gnome with gnome3 because it disrupted my workflow so
much i couldn't cope

In my case I like shiny but not at the cost of useful.

xfce4 felt like a less polished gnome2 but at least it didn't disrupt
my workflow.

I am in favor of Xfce as default desktop for Debian, but...



Some numbers with my free interpretation from ubuntu popcon:
unity is installed in 605_209 machines, but its used regularly only by
46_210

Thats a very low number by all metrics for a default desktop [0].
People dislike it. People dislike disruptive

...or those people simply do not use a desktop on those installations?
I think that this would make more sense. Every ubuntu installation I 
see, that was not from a previous Linux user, is running Unity. None of 
them did ever complain to me (and people like to complain when they 
recognize you as a 'Linux guy') .



Only if popcon numbers for xfce/kde/whatever add up to somewhere near
the missing amount can you reasonably conclude distaste for a particular
desktop as reason, I believe.


  - Jonas



--
Fabio Rafael da Rosa
f...@fdrout.net
http://fdrout.net


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53492588.5030...@fdrout.net

Re: the importance of defaults (was: Debian default desktop environment)

[Jonas Smedegaard]

Quoting alberto fuentes (2014-04-12 12:23:46)
> I had to leave gnome with gnome3 because it disrupted my workflow so 
> much i couldn't cope
> 
> In my case I like shiny but not at the cost of useful.
> 
> xfce4 felt like a less polished gnome2 but at least it didn't disrupt 
> my workflow.

I am in favor of Xfce as default desktop for Debian, but...


> Some numbers with my free interpretation from ubuntu popcon:
> unity is installed in 605_209 machines, but its used regularly only by 
> 46_210
> 
> Thats a very low number by all metrics for a default desktop [0].
> People dislike it. People dislike disruptive

...or those people simply do not use a desktop on those installations?

Only if popcon numbers for xfce/kde/whatever add up to somewhere near 
the missing amount can you reasonably conclude distaste for a particular 
desktop as reason, I believe.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

the importance of defaults (was: Debian default desktop environment)

[alberto fuentes]

tl;dr go to [0]

On Thu, Apr 10, 2014 at 1:06 PM, Ghislain Vaillant  wrote:
> My vote would be on GNOME 3 classic for now, but XFCE with sensible and
> visually appealing defaults would do it for me too.

You are all facing different experiences with end-users because
end-users are probably different. Some likes shiny, others like
useful, some are computer illiterate, others are experts, most are in
between

I had to leave gnome with gnome3 because it disrupted my workflow so
much i couldn't cope

In my case I like shiny but not at the cost of useful.

xfce4 felt like a less polished gnome2 but at least it didn't disrupt
my workflow.

Some numbers with my free interpretation from ubuntu popcon:
unity is installed in 605_209 machines, but its used regularly only by 46_210

Thats a very low number by all metrics for a default desktop [0].
People dislike it. People dislike disruptive

My point is that gnome3 is even more disruptive than unity. Do we want
to attract users or scare them away?

Those who like disruptive desktops will still be able to do it by
install it them. The next less disruptive thing after gnome2 is xfce.

I used ubuntu instead of debian to make my point because i think is
more representative for several reasons:
- their numbers are one order of magnitude bigger than debian's
- the user base is more average than debian's (its debatable what
average even means)

[0] Please watch this ted talk about the importance of defaults
http://www.ted.com/talks/dan_ariely_asks_are_we_in_control_of_our_own_decisions


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/calkubt7s+qtkij-lk3s-p3xbqodmo6vajlkytglb3puzrt8...@mail.gmail.com