Re: Bug#652423: ITP: v3c -- C/C++/sh/make/automake/Debian utility toolkit

2011-12-17 Thread Peter Palfrader 
On Sat, 17 Dec 2011, Philip Ashmore wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Philip Ashmore 
> 
> * Package name: v3c
>   Description : C/C++/sh/make/automake/Debian utility toolkit

None of your ITPs have long descriptions.

This makes the ITPs rather less useful as part of the point of ITPs and
especially of CCing them to debian-devel is so that people can comment
and possibly improve on your description.

Furthermore, we might realize that the purpose of a new package is
already covered by existing software in the archive quite adequately.
This is impossible to judge from just the short description.

Please give it more care next time.

Cheers,
weasel
-- 
   |  .''`.   ** Debian **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.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/20111217094821.gg17...@anguilla.noreply.org

Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

2011-12-17 Thread Thomas Goirand 
On 12/17/2011 05:12 AM, Josh Triplett wrote:
> And while we might
> debate the usefulness of a separate /usr back and forth, I think I can
> safely say that it won't become a *recommended* configuration anytime
> soon. :)

I do recommend a separate /usr to anyone. It's *not* safe to say that,
and I know many people that agree with me. To me, it has, and still is,
the best choice. You have no rights to arbitrary decide what should
be/was/will be the recommended configuration. Your choice is not more
valid than mine, and (computer) science isn't about majorities anyway.

On 12/17/2011 05:12 AM, Josh Triplett wrote:
> For the installer, "easy" represents a significant component of
> "do the job and do it well".
> Sure; see below for a more detailed suggestion along these lines.
> However, I also don't think that should stop us from optimizing
> for the common case.

Well, commonly, for a desktop computer, I recommend separated /usr,
/var, /tmp and /home. Reasonably, if you put enough space for it (for
example, 16GB for usr, 8GB for var, 1GB for tmp) then you can set the
rest for /home. Today's HDD are really big, and in most cases, this
setup will work very well for a desktop, and you'll be able to install a
really insane amount of software without filling up /usr or /var. If you
then lack space, LVM is there.

Doing this has many advantage. Like, if your laptop has to unexpectedly
reboot (like when you inadvertently removed power cord when batteries
were not plugged, which happens often in real life), having separated
partitions usually makes the fsck faster. Only some of the partitions
may have dirty bits to clean, and there's a very good chance your /usr
(which holds a lot of files and is long to check) doesn't even need a
check. That alone is a cool feature that justifies having a separate
/usr for me.

When it comes to *real* newbies (here, I'm thinking about people like my
father in law or my wife who really, don't want to know what is
partitionning), they wont go to hit corner cases and fill any of the
partitions of their HDD anyway. For them, I see no issue "wasting" a bit
of space on multiple hundreds of GB space that will anyway never be used.

> Only in the case where you have such a big disk that you can afford to
> waste a pile of space with mostly empty partitions. Personally [...]

In most general cases nowadays, we *do* have huge disks. Just have a
look into what's available in the marketplace. If you lack space in one
of the default partitions, you can resize using LVM anyway.

Thomas


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

Re: [Fwd: [ISC-Bugs #25979] What happened to the dhcp patch in ISC-Bugs #24697 (Debian Bug #616290)?]

2011-12-17 Thread Paul Wise 
On Fri, Dec 16, 2011 at 9:00 AM, Russ Allbery wrote:

> Thanks to a lot of work by the Hurd folks, there's quite a bit less than
> there used to be.  :)
>
> I haven't looked at the patch in this thread, but most of the time that
> I've seen PATH_MAX used in software, it's indicated a design flaw in an
> interface: use of static buffers for file paths rather than adjusting to
> arbitrary length of file names.  You can arguably "fix" it by defining
> PATH_MAX to something arbitrary, but usually the better fix is to go back
> and fix the incorrect choice of API to use a caller-provided buffer or to
> do memory allocation instead.

I tend to see upstreams defining their own PATH_MAX rather than
calling pathconf. Perhaps there needs to be a lintian warning about
that.

-- 
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: 
http://lists.debian.org/CAKTje6GBF=vyb-e4dsotyq8h2plwdf5hs8u14rh+a0abpvd...@mail.gmail.com

Re: [Fwd: [ISC-Bugs #25979] What happened to the dhcp patch in ISC-Bugs #24697 (Debian Bug #616290)?]

2011-12-17 Thread Adam Borowski 
On Sat, Dec 17, 2011 at 06:08:48PM +0800, Paul Wise wrote:
> On Fri, Dec 16, 2011 at 9:00 AM, Russ Allbery wrote:
> > I haven't looked at the patch in this thread, but most of the time that
> > I've seen PATH_MAX used in software, it's indicated a design flaw in an
> > interface: use of static buffers for file paths rather than adjusting to
> > arbitrary length of file names.  You can arguably "fix" it by defining
> > PATH_MAX to something arbitrary, but usually the better fix is to go back
> > and fix the incorrect choice of API to use a caller-provided buffer or to
> > do memory allocation instead.
> 
> I tend to see upstreams defining their own PATH_MAX rather than
> calling pathconf.

Which is just as bad.

Here's the entire code for pathconf(_PC_PATH_MAX):


long int
__pathconf (const char *path, int name)
{
  switch (name)
{

[...]

case _PC_PATH_MAX:
#ifdef  PATH_MAX
  return PATH_MAX;
#else
  return -1;
#endif


> Perhaps there needs to be a lintian warning about that.

It's easy to find uses of pathconf, finding PATH_MAX would be hard since it
tends to be heavily #ifdefed.  Still, any reference to either is most likely
a bug.

-- 
1KB // Yo momma uses IPv4!


signature.asc
Description: Digital signature

Re: Bug#652423: Acknowledgement (ITP: v3c -- C/C++/sh/make/automake/Debian utility toolkit)

2011-12-17 Thread Philip Ashmore 

Long description:
 utility C/C++ include files
 libv3c - a C/C++ library
 v3c - a utility program meant to be used in scripts or from the 
command line

 makefile includes - see v3c's client projects "makefile" for examples
 automake/aclocal m4 macros - see v3c's client projects for examples


--
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/4eec7e73.7010...@philipashmore.com

Re: Bug#652425: Acknowledgement (ITP: treedb -- on-disk memory library)

2011-12-17 Thread Philip Ashmore 

Long description:
 treedb can implement malloc functionality, and much more!
 Need a heap that allocates of a fixed size chunk of memory? No problem.
 But where treedb comes into its own is when it comes to allocating from a
 mmap()ed disk file - the memory becomes persistent.
 .
 If you follow the tests/examples, you too can store dictionaries, 
trees, lists
 or whatever you can think of in disk-based memory, just an open() and 
mmap()

 away.
 .
 Treedb comes with an AVL tree, doubly-linked-list and 
variable-entry-sized-array

 implementations for you to use in your data structures.


--
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/4eec7f06.8060...@philipashmore.com

Re: Bug#652429: Acknowledgement (ITP: meta-treedb -- on-disk memory library using meta-data)

2011-12-17 Thread Philip Ashmore 

Long description:
 meta-treedb can implement malloc functionality, and much more!
 Need a heap that allocates of a fixed size chunk of memory? No problem.
 But where treedb comes into its own is when it comes to allocating from a
 mmap()ed disk file - the memory becomes persistent.
 .
 If you follow the tests/examples, you too can store dictionaries, 
trees, lists
 or whatever you can think of in disk-based memory, just an open() and 
mmap()

 away.
 .
 Meta-treedb comes with an AVL tree, doubly-linked-list and
 variable-entry-sized-array implementations for you to use in your data
 structures.
 .
 So, what distinguishes meta-treedb from treedb?
 * "class" interfaces for treedb collections
 .  These are vtables (virtual function tables) that implement the 
interface.

 * faster compiles - only the "class" interfaces are visible to client code
 .  This is at the expense of a small performance hit.
 * the ability to use implementations that were developed after client 
code was

 .  compiled.
 .  This feature hasn't been fully fleshed out yet, as it would require a
 .  plug-in system such as that provided by v3c-dcom, but it's coming soon.


--
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/4eec7f91.4040...@philipashmore.com

Re: Bug#652432: Acknowledgement (ITP: v3c-dcom -- Baby steps to DCOM)

2011-12-17 Thread Philip Ashmore 

Long description:
 v3c-dcom provides a plug-in system as an alternative COM implementation.
 Unlike COM, v3c-dcom encourages the use of "sandboxes" of registered 
plug-ins,
 so allowing per site, per-group, per-user, per-program and per-job 
sandboxes,

 allowing virtually unlimited configuration and customization.
 Users and client programs can even create sandboxes on the fly.
 .
 Using COM's naming scheme aims at reducing the learning curve for those
 familiar with COM, as does the tiny ATL implementation for C++ developers.


--
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/4eec8020.5060...@philipashmore.com

Re: Bug#652433: Acknowledgement (ITP: v3c-qt -- v3c/automake wrapper for QT)

2011-12-17 Thread Philip Ashmore 

Long description:
 The v3c-qt package ties QT doxygen-generated documentation into the v3c
 documentation chain, so that client packages can "inherit" this in 
their own

 doxygen-generated documentation.
 .
 It also provides automake rules for MOC, UIC and RCC, to ease their 
usage in

 client packages automake Makefile.am files.


--
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/4eec8188.5000...@philipashmore.com

Re: Bug#652435: Acknowledgement (ITP: v3c-qt-examples -- v3c/automake wrapper for Qt4 - examples)

2011-12-17 Thread Philip Ashmore 

Long description:
 The v3c-qt package ties QT doxygen-generated documentation into the v3c
 documentation chain, so that client packages can "inherit" this in 
their own

 doxygen-generated documentation.
 .
 It also provides automake rules for MOC, UIC and RCC, to ease their 
usage in

 client packages automake Makefile.am files.
 .
 This is the examples package.


--
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/4eec81fe.1020...@philipashmore.com

Re: Bug#652423: Acknowledgement (ITP: v3c -- C/C++/sh/make/automake/Debian utility toolkit)

2011-12-17 Thread Reinhard Tartler 
On Sa, Dez 17, 2011 at 12:35:15 (CET), Philip Ashmore wrote:

> Long description:
>  utility C/C++ include files
>  libv3c - a C/C++ library
>  v3c - a utility program meant to be used in scripts or from the command
> line
>  makefile includes - see v3c's client projects "makefile" for examples
>  automake/aclocal m4 macros - see v3c's client projects for examples

This description fails to explain what this package is intended for and
how it relates and is better to alternatives in Debian. After reading
the package description, the reader should be able to decide if the
package satisfies the user's requirements.

cf. http://mdcc.cx/debian/descriptions.html and many other guidelines on
the internet.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


-- 
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/87ehw3qrp3@faui43f.informatik.uni-erlangen.de

Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib

2011-12-17 Thread Roger Leigh 
On Thu, Dec 15, 2011 at 01:29:18PM +, Roger Leigh wrote:
> WRT mounting additional filesystems in the initramfs, how difficult
> would it be to add an additional mount option to /etc/fstab entries,
> e.g. "init" or "initramfs" to mark them as being required for mounting
> in the initramfs.  This could include /, /usr, /etc and anything else
> the admin deems necessary for booting, and would just be checked and
> added when creating/updating the initramfs.

So WRT mounting /usr (and potentially /etc and other filesystems),
I've pushed patches upstream for util-linux (initramfs mount option)
and initramfs-tools (generate /etc/fstab from host and mount after
rootfs).  Once fully implemented, this will guarantee the presence of
/usr from before init starts, which will solve all the current
problems of the / vs. /usr separation.

Obviously this is a separate problem to whether /usr should be kept
in the long run, but it does make guarantees WRT the availability of
files which we currently don't.  This would, for example, permit the
removal of duplicated files in / and /usr which would make future
migration possible.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


-- 
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/20111217132508.ga23...@codelibre.net

Bug#652462: ITP: libwx-scintilla-perl -- Scintilla source code editing component for wxWidgets

2011-12-17 Thread Dominique Dumont 

Package: wnpp
Owner: Dominique Dumont 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libwx-scintilla-perl
  Version : 0.34
  Upstream Author : Ahmad M. Zawawi 
* URL : http://search.cpan.org/dist/Wx-Scintilla/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Scintilla source code editing component for wxWidgets

Wx::Scintilla Perl module is a Wx wrapper around scintilla editor.

Wx::Scintilla prjoect goal is to provide fresh Perl 5 and maybe Perl 6
support in Wx while preserving compatibility with Wx::StyledTextCtrl.

Note: You cannot load Wx::STC and Wx::Scintilla in the same application. They
are mutually exclusive. The wxSTC_... events are handled by one library or
the other.

Wx::Scintilla is required by Padre 0.92

Dominique
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/


signature.asc
Description: This is a digitally signed message part.

Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

2011-12-17 Thread Josselin Mouette 
Le samedi 17 décembre 2011 à 17:42 +0800, Thomas Goirand a écrit : 
> I do recommend a separate /usr to anyone. It's *not* safe to say that,
> and I know many people that agree with me. To me, it has, and still is,
> the best choice. You have no rights to arbitrary decide what should
> be/was/will be the recommended configuration. Your choice is not more
> valid than mine, and (computer) science isn't about majorities anyway.

True. But the fact that you are in minority doesn’t necessarily mean you
are right, either.

> Doing this has many advantage. Like, if your laptop has to unexpectedly
> reboot (like when you inadvertently removed power cord when batteries
> were not plugged, which happens often in real life), having separated
> partitions usually makes the fsck faster.

This is complete bullshit. With a journaled filesystem, the boot time
will greatly increase with the number of filesystems to check. If no
files were modified in /usr, they won’t be mentioned in the journal, and
that’s all. But having one journal to parse for all the system is
definitely a measurable improvement.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


signature.asc
Description: This is a digitally signed message part

Bug#652464: ITP: aguilas -- A web-based LDAP user management system

2011-12-17 Thread Luis Alejandro Martínez Faneyth 
Package: wnpp
Severity: wishlist
Owner: "Luis Alejandro Martínez Faneyth" 

* Package name: aguilas
  Version : 1.0.0
  Upstream Author : Luis Alejandro Martínez Faneyth

* URL : http://code.google.com/p/aguilas
* License : GPL-3
  Programming Lang: PHP
  Description : A web-based LDAP user management system

AGUILAS is an application written mostly in PHP, but it has bits of JavaScript,
SQL, style sheets and of course, HTML. It is a centralized registration system
that allows users to manage an LDAP authentication platform, using MYSQL
database support in cases where necessary (temporary records).

AGUILAS has the following features:

Creates user accounts based on a customizable number of LDAP attributes.
Resends confirmation email in case it gets lost on spam folders.
Password reset.
Password change.
Username reminder.
Deletion of account.
Edit your user profile (ajax enabled).
List all registered users.
Find a Member.



-- 
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/20111217134822.10890.2219.reportbug@OKComputer

Re: Bug#652423: Acknowledgement (ITP: v3c -- C/C++/sh/make/automake/Debian utility toolkit)

2011-12-17 Thread David Prévot 
Le 17/12/2011 08:59, Reinhard Tartler a écrit :
> On Sa, Dez 17, 2011 at 12:35:15 (CET), Philip Ashmore wrote:
> 
>> Long description:
>>  utility C/C++ include files
>>  libv3c - a C/C++ library
>>  v3c - a utility program meant to be used in scripts or from the command
>> line
>>  makefile includes - see v3c's client projects "makefile" for examples
>>  automake/aclocal m4 macros - see v3c's client projects for examples
> 
> This description fails to explain what this package is intended for and
> how it relates and is better to alternatives in Debian. After reading
> the package description, the reader should be able to decide if the
> package satisfies the user's requirements.
> 
> cf. http://mdcc.cx/debian/descriptions.html and many other guidelines on
> the internet.

Please prefer the up to date developers' reference:

http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices#bpp-desc-basics
www.debian.org/doc/manuals/developers-reference/best-pkging-practices#bpp-pkg-synopsis
www.debian.org/doc/manuals/developers-reference/best-pkging-practices#bpp-pkg-desc

Regards

David



signature.asc
Description: OpenPGP digital signature

Re: Bug#652433: ITP: v3c-qt -- v3c/automake wrapper for QT

2011-12-17 Thread Mario Fux 
Am Samstag 17 Dezember 2011, 07.10:06 schrieb Philip Ashmore:
> Package: wnpp
> Severity: wishlist
> Owner: Philip Ashmore 
> 
> * Package name: v3c-qt
>   Version : 0.7.0-01
>   Upstream Author : Philip Ashmore 
> * URL : http://sourceforge.net/projects/v3c-qt/
> * License : LGPL
>   Programming Lang: m4
>   Description : v3c/automake wrapper for QT

I think this should be "Qt" (for the Qt Framework from Nokia) and not "QT" for 
Quicktime? And yes I saw that's wrong upstream (see URL above) as well.

thx
Mario


-- 
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/201112171725.56980.debian...@unormal.org

/etc/mtab and /lib/init/rw migration; libpam-mount breakage

2011-12-17 Thread Roger Leigh 
On Tue, Dec 13, 2011 at 08:54:14PM +, Roger Leigh wrote:
> The above have been mentioned a few times during the course of the
> year, but we're now at the point where all the prerequisites have
> been satisfied, and there are no blockers present to proceed.
> 
> I've put a proposed set of packages at
>   http://people.debian.org/~rleigh/sysvinit/
> which I plan to upload to experimental soon, and then to unstable
> following some testing.

These packages have now been uploaded to unstable, following some
small fixes.  /etc/mtab and /lib/init/rw will be migrated and
removed, respectively, on upgrade.

Note that if you're a user of libpam-mount, the Breaks on libpam-mount
in initscripts will prevent you upgrading unless you remove it.  This
is because it requires a new upstream version which has not yet been
packaged (#622693, #652473, #652474).  No response from the actual
package maintainer.

If you're a user of libpam-mount, I've put packages of libhx and
libpam-mount here:
  http://people.debian.org/~rleigh/libhx/
  http://people.debian.org/~rleigh/pam_mount/
There's some obscure bug in the upstream src/Makefile.am though--it's
missing libcryptsetup and OpenSSL libs when linking, which causes
link failures.  The actual Makefile looks like it's correct though,
so not sure what's wrong.  If anyone who uses is wants to fix that,
that's all (I think) that's blocking their upload.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


-- 
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/20111217165518.gd23...@codelibre.net

Bug#652481: ITP: libhtml-html5-entities-perl -- module to encode and decode character entities defined in HTML5

2011-12-17 Thread Florian Schlichting 
Package: wnpp
Severity: wishlist
Owner: Florian Schlichting 

* Package name: libhtml-html5-entities-perl
  Version : 0.001
  Upstream Author : Toby Inkster 
* URL : http://search.cpan.org/~tobyink/HTML-HTML5-Entities-0.001/
* License : GPL-1 or Artistic
  Programming Lang: Perl
  Description : module to encode and decode character entities defined in 
HTML5

HTML::HTML5::Entities is a drop-in replacement for HTML::Entities,
providing the character entities defined in HTML5. It is a pure Perl
implementation and hence slower, expecially decoding.

libhtml-html5-entities-perl is a dependency of the latest
libhtml-html5-parser-perl.



-- 
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/20111217165239.22658.3454.report...@island.zedat.fu-berlin.de

Re: [Fwd: [ISC-Bugs #25979] What happened to the dhcp patch in ISC-Bugs #24697 (Debian Bug #616290)?]

2011-12-17 Thread Russ Allbery 
Paul Wise  writes:

> I tend to see upstreams defining their own PATH_MAX rather than calling
> pathconf. Perhaps there needs to be a lintian warning about that.

The purpose of Lintian is not to be a C source lint program.  There are
lots of those that already have the C parsing infrastructure implemented
to do it properly.

-- 
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/87obv7yran@windlord.stanford.edu

Users of Debian! Who lives in the North Caucasus? (Russia)

2011-12-17 Thread UNLEVIN 
Good time of day Dear subscribers, users of Debian.

I have a simple question: Who lives in the North Caucasus (preferably in
the Stavropol Territory)

I assure you this question applies to Debian and its development. 


-- 
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/1324151205.13023.11.camel@debian

Bug#652492: ITP: python-multipartposthandler -- handler for urllib2 to enable multipart form uploading

2011-12-17 Thread Georges Khaznadar 
Package: wnpp
Severity: wishlist
Owner: Georges Khaznadar 


* Package name: python-multipartposthandler
  Version : 0.1.0
  Upstream Author : Will Holcomb 
* URL : http://pypi.python.org/pypi/MultipartPostHandler/
* License : LGPL-2
  Programming Lang: Python
  Description : handler for urllib2 to enable multipart form uploading

 Enables the use of multipart/form-data for posting forms,
 with an easy management of file uploads.



-- 
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/20111217184903.23964.44891.report...@photos.khaznadar.fr

Users of Debian! Who lives in the North Caucasus? (Russia)

2011-12-17 Thread UNLEVIN 
Good time of day Dear subscribers, users of Debian.

I have a simple question: Who lives in the North Caucasus (preferably in
the Stavropol Territory)

I assure you this question applies to Debian and its development.


-- 
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/1324151166.13023.8.camel@debian

RFP: BOINC screensaver for Unix/X11

2011-12-17 Thread Ettore Atalan 

Package: wnpp
Severity: wishlist


* Package name: boincscr
* URL : 
http://boinc.berkeley.edu/svn/trunk/boinc/clientscr/screensaver_x11.cpp
* License : GPL
  Programming Lang: C++
  Description : A XScreenSaver compatible BOINC screensaver for Unix/X11


BOINC is an open-source software platform for computing using volunteered 
resources. It was originally developed to support the SETI@home project.
The boinc-client is already packaged, but currently there is no Debian package 
available containing the BOINC screensaver.


Regards,
Ettore Atalan


--
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/4eecfaae.3020...@googlemail.com

Re: from / to /usr/: a summary

2011-12-17 Thread Philip Hands 
On Fri, 16 Dec 2011 14:52:36 +0100, Josselin Mouette  wrote:
> Le jeudi 08 décembre 2011 à 20:16 +0100, Marco d'Itri a écrit : 
> > Let's try to summarize the possible configurations and what is needed to
> > support them:
> > 
> > - / and /usr are in the same filesystem
> >   * no changes are needed
> > - / and /usr are in different filesystems
> >   - an initramfs is or can be used and will mount /usr
> > * initramfs-tools will be updated, no operational changes are needed
> >   - the platform does not support an initramfs
> > * I am still waiting for somebody to enumerate them, but I believe
> >   that I can design a suitable workaround
> >   - the administrator refuses to use an initramfs
> > * tough luck for them
> 
> After a big week of discussions, I don’t think there have been any valid
> objections against the scheme you are proposing. It still allows to
> split / and /usr for various reasons (the most useful one today being
> encrypting / and not /usr). Once this is done I don’t think there are
> valid reasons to not move back stuff from / to /usr, either.
> 
> The cost is not too high, the number of systems it breaks is extremely
> small, and the long-term gain is significant.

I've read all of these threads, but I'm afraid I'm still a little
befuddled about the pros and cons.

Pro seems to be saving some effort for packagers when RedHat as
upstream, say, makes changes that assume /usr is always available,
that's clear.

It also seems that Gnome folks[1] will be able to relax and stop
worrying about whether their stuff should really be on / and/or whether
/usr will be available early in the boot -- which sounds great for them,
but I'm left wondering if allowing people to be less rigorous in this
area is good for the embedded folks, for example, because it gives
developers an excuse to say they don't care about how much they've
entangled the early boot with things that are only important if you're
running a full desktop environment.

I'm also wondering: Does this mean that this change compromises our
ability to recover from a failure that renders a system unable to
mount /usr for some reason?

Cheers, Phil.

[1] or at least those who package things upon which Gnome depends, and
which need to be around early in the boot -- and I'd imagine that KDE is
similar in many respects, so I'm not being specifically anti-gnome.  I
just don't happen to know enough about Gnome/KDE or any other such
desktoppy stuff to discover the fine details here.

It would be really helpful if someone would spell out the packages that
have had to be twisted into a funny shape to fit into the current
scheme, so that the long-term gains we are expecting were then revealed.
-- 
|)|  Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/
|-|  HANDS.COM Ltd.http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND


pgpK13ig4SJIQ.pgp
Description: PGP signature

Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

2011-12-17 Thread Otavio Salvador 
On Sat, Dec 17, 2011 at 07:42, Thomas Goirand  wrote:

> On 12/17/2011 05:12 AM, Josh Triplett wrote:
> > And while we might
> > debate the usefulness of a separate /usr back and forth, I think I can
> > safely say that it won't become a *recommended* configuration anytime
> > soon. :)
>
> I do recommend a separate /usr to anyone. It's *not* safe to say that,
> and I know many people that agree with me. To me, it has, and still is,
> the best choice. You have no rights to arbitrary decide what should
> be/was/will be the recommended configuration. Your choice is not more
> valid than mine, and (computer) science isn't about majorities anyway.


Sure but Debian Installer defaults are. End point.


> ...
> In most general cases nowadays, we *do* have huge disks. Just have a
> look into what's available in the marketplace. If you lack space in one
> of the default partitions, you can resize using LVM anyway.
>

New users will think LVM is something to eat with bread or similar. This is
mostly as if I starting to try to convince to use Awesome WM as default
desktop install because I think it is more user-friendly (and it is, for my
type of use, but not for general use).

I do think you ought to stop to try to push your personal opinion too
hard... it is clear on this thread that most people do not agree with you
so lets go ahead and move topic.

-- 
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854  http://projetos.ossystems.com.br

Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

2011-12-17 Thread Josh Triplett 
On Sat, Dec 17, 2011 at 05:42:59PM +0800, Thomas Goirand wrote:
> On 12/17/2011 05:12 AM, Josh Triplett wrote:
> > And while we might
> > debate the usefulness of a separate /usr back and forth, I think I can
> > safely say that it won't become a *recommended* configuration anytime
> > soon. :)
> 
> I do recommend a separate /usr to anyone. It's *not* safe to say that,
> and I know many people that agree with me. To me, it has, and still is,
> the best choice. You have no rights to arbitrary decide what should
> be/was/will be the recommended configuration. Your choice is not more
> valid than mine, and (computer) science isn't about majorities anyway.

Let me clarify: I can safely say it won't become *Debian's* recommended
configuration anytime soon.  It has strong enough arguments against it
that while a vocal minority might manage to keep it around, I doubt
it will become the default.  The discussion would have to change quite
drastically for that to occur.

> On 12/17/2011 05:12 AM, Josh Triplett wrote:
> > For the installer, "easy" represents a significant component of
> > "do the job and do it well".
> > Sure; see below for a more detailed suggestion along these lines.
> > However, I also don't think that should stop us from optimizing
> > for the common case.
> 
> Well, commonly, for a desktop computer, I recommend separated /usr,
> /var, /tmp and /home. Reasonably, if you put enough space for it (for
> example, 16GB for usr, 8GB for var, 1GB for tmp) then you can set the
> rest for /home. Today's HDD are really big, and in most cases, this
> setup will work very well for a desktop, and you'll be able to install a
> really insane amount of software without filling up /usr or /var. If you
> then lack space, LVM is there.

Brand new laptops, *today*, come with as little as 300GB drives, or 80GB
SSDs.  Netbooks often have even less than that.  Wasting ~20GB of that
seems excessive.

And do you seriously expect the average user to go through the process
of an LVM resize?  "Possible" doesn't mean "easy".

> Doing this has many advantage. Like, if your laptop has to unexpectedly
> reboot (like when you inadvertently removed power cord when batteries
> were not plugged, which happens often in real life), having separated
> partitions usually makes the fsck faster. Only some of the partitions
> may have dirty bits to clean, and there's a very good chance your /usr
> (which holds a lot of files and is long to check) doesn't even need a
> check. That alone is a cool feature that justifies having a separate
> /usr for me.

Modern fsck runs very fast (in large part by not checking unused bits of
the filesystem).  Also, unless you've mounted some of those partitions
read-only, they'll all always need fsck when not cleanly shut down.

> When it comes to *real* newbies (here, I'm thinking about people like my
> father in law or my wife who really, don't want to know what is
> partitionning), they wont go to hit corner cases and fill any of the
> partitions of their HDD anyway. For them, I see no issue "wasting" a bit
> of space on multiple hundreds of GB space that will anyway never be used.

On the contrary, significant overlap exists between the set of users who
don't want to think about advanced concepts like partitioning and the
set of users quite capable of filling a disk and installing piles of
software.  If you really don't want to know about partitioning, you
don't want to deal with situations where you have plenty of free space
but not on the partitions where you need it.

> > Only in the case where you have such a big disk that you can afford to
> > waste a pile of space with mostly empty partitions. Personally [...]
> 
> In most general cases nowadays, we *do* have huge disks. Just have a
> look into what's available in the marketplace. If you lack space in one
> of the default partitions, you can resize using LVM anyway.

See above; we don't have sufficiently huge disks to waste enough space
that the non-/home partitions will never fill up, and we don't want to
inflict partition resizes on most users unnecessarily.

- Josh Triplett


-- 
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/20111217204726.GA22701@leaf

Re: from / to /usr/: a summary

2011-12-17 Thread Ben Hutchings 
On Sat, 2011-12-17 at 20:42 +, Philip Hands wrote:
> On Fri, 16 Dec 2011 14:52:36 +0100, Josselin Mouette  wrote:
> > Le jeudi 08 décembre 2011 à 20:16 +0100, Marco d'Itri a écrit : 
> > > Let's try to summarize the possible configurations and what is needed to
> > > support them:
> > > 
> > > - / and /usr are in the same filesystem
> > >   * no changes are needed
> > > - / and /usr are in different filesystems
> > >   - an initramfs is or can be used and will mount /usr
> > > * initramfs-tools will be updated, no operational changes are needed
> > >   - the platform does not support an initramfs
> > > * I am still waiting for somebody to enumerate them, but I believe
> > >   that I can design a suitable workaround
> > >   - the administrator refuses to use an initramfs
> > > * tough luck for them
> > 
> > After a big week of discussions, I don’t think there have been any valid
> > objections against the scheme you are proposing. It still allows to
> > split / and /usr for various reasons (the most useful one today being
> > encrypting / and not /usr). Once this is done I don’t think there are
> > valid reasons to not move back stuff from / to /usr, either.
> > 
> > The cost is not too high, the number of systems it breaks is extremely
> > small, and the long-term gain is significant.
> 
> I've read all of these threads, but I'm afraid I'm still a little
> befuddled about the pros and cons.
> 
> Pro seems to be saving some effort for packagers when RedHat as
> upstream, say, makes changes that assume /usr is always available,
> that's clear.

This isn't specific to 'Red Hat as upstream'.  It's simply very hard for
a general-purpose distribution to know all executables and libraries
that may be wanted by init scripts and daemons before all volumes are
mounted, and it can be disruptive to move executables between
directories.

Red Hat (or the Fedora part of it) has formally decided that it will now
ensure and assume that /usr is mounted before the 'real' init starts,
which removes a lot of the difficulty (and moves some of it into the
initramfs, but that is a much simpler environment).

We're now debating what, if any, effort we should make to continue to
support running init scripts without /usr mounted.  There is also
discussion of whether separate / and /usr partitions should be supported
or deprecated, but I think that's quite separate.

[...]
> I'm also wondering: Does this mean that this change compromises our
> ability to recover from a failure that renders a system unable to
> mount /usr for some reason?

Yes, any recovery tools would need to be included in the initramfs or an
alternate boot image (apparently grml is good for this; haven't tried it
myself).

[...]
> It would be really helpful if someone would spell out the packages that
> have had to be twisted into a funny shape to fit into the current
> scheme, so that the long-term gains we are expecting were then revealed.

nfs-common.  But it will probably end up with funny shaped bits in the
initramfs anyway.

Ben.

-- 
Ben Hutchings
Computers are not intelligent.  They only think they are.


signature.asc
Description: This is a digitally signed message part

Re: Bug#652464: ITP: aguilas -- A web-based LDAP user management system

2011-12-17 Thread Sune Vuorela 
On Saturday 17 December 2011 14:48:22 Luis Alejandro Martínez Faneyth wrote:
> Package: wnpp
> Severity: wishlist
> Owner: "Luis Alejandro Martínez Faneyth" 
> 
> * Package name: aguilas
>   Version : 1.0.0
>   Upstream Author : Luis Alejandro Martínez Faneyth
> 
> * URL : http://code.google.com/p/aguilas
> * License : GPL-3
>   Programming Lang: PHP
>   Description : A web-based LDAP user management system
> 
> AGUILAS is an application written mostly in PHP, but it has bits of
> JavaScript, SQL, style sheets and of course, HTML. It is a centralized

I was showing 'aguilas' to some people also looking for web based ldap user 
management systems, and then within not too much time, I got a message back 
saying 

"not sure I like the look of that sql query..."
"sql injection in 5 seconds flat"


$sel_q = "SELECT * FROM NewUser"
  . " WHERE mail='" . $mail . "'"
  . " AND uid='" . $uid . "'"
  . " AND token='" . $token . "'"
  . " ORDER BY token DESC LIMIT 0,1";

I also got a bit scared by this. 

/Sune
-- 
Do you know how might I reset the SCSI window?

You should reset the head.


--
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/201112172149.16597.s...@debian.org

Re: Bug#652464: ITP: aguilas -- A web-based LDAP user management system

2011-12-17 Thread Luis Alejandro Martínez Faneyth 
On 17/12/11 16:19, Sune Vuorela wrote:
> On Saturday 17 December 2011 14:48:22 Luis Alejandro Martínez Faneyth wrote:
>> Package: wnpp
>> Severity: wishlist
>> Owner: "Luis Alejandro Martínez Faneyth" 
>>
>> * Package name: aguilas
>>   Version : 1.0.0
>>   Upstream Author : Luis Alejandro Martínez Faneyth
>> 
>> * URL : http://code.google.com/p/aguilas
>> * License : GPL-3
>>   Programming Lang: PHP
>>   Description : A web-based LDAP user management system
>>
>> AGUILAS is an application written mostly in PHP, but it has bits of
>> JavaScript, SQL, style sheets and of course, HTML. It is a centralized
> 
> I was showing 'aguilas' to some people also looking for web based ldap user 
> management systems, and then within not too much time, I got a message back 
> saying 
> 
> "not sure I like the look of that sql query..."
> "sql injection in 5 seconds flat"
> 
> 
> $sel_q = "SELECT * FROM NewUser"
>   . " WHERE mail='" . $mail . "'"
>   . " AND uid='" . $uid . "'"
>   . " AND token='" . $token . "'"
>   . " ORDER BY token DESC LIMIT 0,1";

Thanks for having a look :)

Well, i perform a very strict validation before that query is made.
Lines 20 - 54:

http://code.google.com/p/aguilas/source/browse/NewUserDo.php#20
http://code.google.com/p/aguilas/source/browse/NewUserDo.php#54

You are still scared?

> 
> I also got a bit scared by this. 
> 
> /Sune

-- 
Sin más que agregar y siempre a la orden,


Luis Alejandro Martínez Faneyth
Ingeniero de Telecomunicaciones
Blog: http://www.huntingbears.com.ve/
Twitter: @LuisAlejandro
GPG Key = E78DAA2E


CODE IS POETRY


-- 
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/4eed19eb.9010...@gmail.com

Re: Bug#652464: ITP: aguilas -- A web-based LDAP user management system

2011-12-17 Thread Roberto C . Sánchez 
On Sat, Dec 17, 2011 at 06:08:35PM -0430, Luis Alejandro Martínez Faneyth wrote:
> On 17/12/11 16:19, Sune Vuorela wrote:
> > 
> > $sel_q = "SELECT * FROM NewUser"
> >   . " WHERE mail='" . $mail . "'"
> >   . " AND uid='" . $uid . "'"
> >   . " AND token='" . $token . "'"
> >   . " ORDER BY token DESC LIMIT 0,1";
> 
> Thanks for having a look :)
> 
> Well, i perform a very strict validation before that query is made.
> Lines 20 - 54:
> 
> http://code.google.com/p/aguilas/source/browse/NewUserDo.php#20
> http://code.google.com/p/aguilas/source/browse/NewUserDo.php#54
> 
> You are still scared?
> 
I would be.  Bind variables exist for a reason.  Aside from that, your
validation of email addresses is wrong:

// Invalid e-mail
} elseif (preg_match("/\w+([-+.]\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*/", $mail) == 
0) {

First off, there is nothing in the RFC that says that the email address
must start with a letter, which your regex requires.  In addition to
that, you do not allow other allowed special characters:

 !#$%&'*/=?^_`{|}~"(),:;<>@[\]

You also don't properly check for consecutive dots, so I could pass the
email a@foo.com and it pass your check, and still be wrong.

What you have done is reinvent the wheel, and badly at that.

If it were up to me, I would reject this package based on that one line
of code alone.
> 
> CODE IS POETRY
> 
I find it terribly ironic that you have that satement in your email
signature.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


-- 
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/20111217225432.ga27...@connexer.com

Re: Bug#652464: ITP: aguilas -- A web-based LDAP user management system

2011-12-17 Thread Luis Alejandro Martínez Faneyth 
On 17/12/11 18:24, Roberto C. Sánchez wrote:
> On Sat, Dec 17, 2011 at 06:08:35PM -0430, Luis Alejandro Martínez Faneyth 
> wrote:
>> On 17/12/11 16:19, Sune Vuorela wrote:
>>>
>>> $sel_q = "SELECT * FROM NewUser"
>>>   . " WHERE mail='" . $mail . "'"
>>>   . " AND uid='" . $uid . "'"
>>>   . " AND token='" . $token . "'"
>>>   . " ORDER BY token DESC LIMIT 0,1";
>>
>> Thanks for having a look :)
>>
>> Well, i perform a very strict validation before that query is made.
>> Lines 20 - 54:
>>
>> http://code.google.com/p/aguilas/source/browse/NewUserDo.php#20
>> http://code.google.com/p/aguilas/source/browse/NewUserDo.php#54
>>
>> You are still scared?
>>
> I would be.  Bind variables exist for a reason.  Aside from that, your
> validation of email addresses is wrong:
> 
> // Invalid e-mail
> } elseif (preg_match("/\w+([-+.]\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*/", $mail) 
> == 0) {
> 
> First off, there is nothing in the RFC that says that the email address
> must start with a letter, which your regex requires.  In addition to
> that, you do not allow other allowed special characters:
> 
>  !#$%&'*/=?^_`{|}~"(),:;<>@[\]
> 
> You also don't properly check for consecutive dots, so I could pass the
> email a@foo.com and it pass your check, and still be wrong.

Thank you, i will correct that inmediately.

> 
> What you have done is reinvent the wheel, and badly at that.

I coudn't find any other user friendly interface to manage user accounts
from an LDAP.

> 
> If it were up to me, I would reject this package based on that one line
> of code alone.
>>
>> CODE IS POETRY
>>
> I find it terribly ironic that you have that satement in your email
> signature.

Don't. It does not states that i'm a poetrician :)

> 
> Regards,
> 
> -Roberto
> 

-- 
Sin más que agregar y siempre a la orden,


Luis Alejandro Martínez Faneyth
Ingeniero de Telecomunicaciones
Blog: http://www.huntingbears.com.ve/
Twitter: @LuisAlejandro
GPG Key = E78DAA2E


CODE IS POETRY


-- 
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/4eed2693.6070...@gmail.com

Re: Bug#652464: ITP: aguilas -- A web-based LDAP user management system

2011-12-17 Thread Josselin Mouette 
Le samedi 17 décembre 2011 à 18:08 -0430, Luis Alejandro Martínez
Faneyth a écrit :
> > $sel_q = "SELECT * FROM NewUser"
> >   . " WHERE mail='" . $mail . "'"
> >   . " AND uid='" . $uid . "'"
> >   . " AND token='" . $token . "'"
> >   . " ORDER BY token DESC LIMIT 0,1";

> You are still scared?

Yes. No such things in the Debian archive please.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'  “If you behave this way because you are blackmailed by someone,
  `-[…] I will see what I can do for you.”  -- Jörg Schilling


--
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/1324165012.2828.1.camel@tomoe

Re: Bug#652464: ITP: aguilas -- A web-based LDAP user management system

2011-12-17 Thread Roberto C . Sánchez 
On Sat, Dec 17, 2011 at 07:02:35PM -0430, Luis Alejandro Martínez Faneyth wrote:
> On 17/12/11 18:24, Roberto C. Sánchez wrote:
> > 
> > What you have done is reinvent the wheel, and badly at that.
> 
> I coudn't find any other user friendly interface to manage user accounts
> from an LDAP.
> 
I should have been more clear.  I was referring to the fact that there
are lots of proven ways to validate email addresses in PHP.  In fact,
you don't even need any external library, you can just use filter_var():

http://php.net/manual/en/filter.examples.validation.php

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: Bug#652433: ITP: v3c-qt -- v3c/automake wrapper for QT

2011-12-17 Thread Philip Ashmore 

On 17/12/11 16:25, Mario Fux wrote:

Am Samstag 17 Dezember 2011, 07.10:06 schrieb Philip Ashmore:

Package: wnpp
Severity: wishlist
Owner: Philip Ashmore

* Package name: v3c-qt
   Version : 0.7.0-01
   Upstream Author : Philip Ashmore
* URL : http://sourceforge.net/projects/v3c-qt/
* License : LGPL
   Programming Lang: m4
   Description : v3c/automake wrapper for QT

I think this should be "Qt" (for the Qt Framework from Nokia) and not "QT" for
Quicktime? And yes I saw that's wrong upstream (see URL above) as well.

thx
Mario



Fixed upstream - thanks.

Should I file another ITP to change the spelling?

Regards,
Philip Ashmore


--
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/4eed382b.50...@philipashmore.com

Re: Bug#652423: Acknowledgement (ITP: v3c -- C/C++/sh/make/automake/Debian utility toolkit)

2011-12-17 Thread Philip Ashmore 

On 17/12/11 15:29, David Prévot wrote:

Le 17/12/2011 08:59, Reinhard Tartler a écrit :

On Sa, Dez 17, 2011 at 12:35:15 (CET), Philip Ashmore wrote:


Long description:
  utility C/C++ include files
  libv3c - a C/C++ library
  v3c - a utility program meant to be used in scripts or from the command
line
  makefile includes - see v3c's client projects "makefile" for examples
  automake/aclocal m4 macros - see v3c's client projects for examples

This description fails to explain what this package is intended for and
how it relates and is better to alternatives in Debian. After reading
the package description, the reader should be able to decide if the
package satisfies the user's requirements.

cf. http://mdcc.cx/debian/descriptions.html and many other guidelines on
the internet.

Please prefer the up to date developers' reference:

http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices#bpp-desc-basics
www.debian.org/doc/manuals/developers-reference/best-pkging-practices#bpp-pkg-synopsis
www.debian.org/doc/manuals/developers-reference/best-pkging-practices#bpp-pkg-desc

Regards

David


package_description: automake wrapper + utility toolkit
package_long_description:
 Highlights:
 = "make" wrapper =
   make - configures + builds the package (debug mode by default - see 
below)

   make dist - builds a distribution tar ball
   make check - runs the packages automake checks
   make distcheck - builds a distribution tar ball, installs and "make 
check"s it
   make install - installs the package - may require elevated (root) 
privileges

 .
 = GIT version control =
   make git branch=master - build the "master" branch
   make git tag=test1.2.3 - build the branch locally tagged as "test1.2.3"
 .
 = Debian/Ubuntu packages =
   make debian - runs "make distcheck", then builds Debian/Ubuntu packages
 .
 = build modes =
 You can choose several configurations using "build modes" - "debug" 
and "release"

 are available by default, and "debug" is the default build mode.
   make debian (optimizations off unless "release" was the last build 
mode used)

   make release debian (optimizations on)
   make git tag=new2 debug distcheck
 The build system remembers your last build mode, so
   make release
   ...tests+edits
   make (uses the last build mode - release in this case)
   ...tests+edits
   make debug
   ...tests+edits
   make install
   ...tests+edits
   make uninstall
 This gives you a relatively quick turnaround for testing/debugging.
 .
 = libv3c = - a C/C++ utility library
 .
 = doxygen documentation integration =
   make doxygen-doc - generates html documentation from the packages 
source files

   make install-doxygen-doc - installs it
 .
 = v3c = - a utility program for use in scripts or the command line
 The "v3c" build system uses this extensively.
 .
 = lots of examples/tests =
 Run "make check" to see more.

Please let me know what you think.

Regards,
Philip Ashmore


--
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/4eed38bd.9070...@philipashmore.com

Re: Bug#652423: Acknowledgement (ITP: v3c -- C/C++/sh/make/automake/Debian utility toolkit)

2011-12-17 Thread David Prévot 
Le 17/12/2011 20:50, Philip Ashmore a écrit :
> On 17/12/11 15:29, David Prévot wrote:

>> Please prefer the up to date developers' reference:
>>
>> http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices#bpp-desc-basics

[…]
> Please let me know what you think.

Quote from the previous URL:

“If you are having problems writing your description, you may wish to
send it along to  and request
feedback.”

Regards

David



signature.asc
Description: OpenPGP digital signature

Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

2011-12-17 Thread Russell Coker 
On Sun, 18 Dec 2011, Josselin Mouette  wrote:
> > Doing this has many advantage. Like, if your laptop has to unexpectedly
> > reboot (like when you inadvertently removed power cord when batteries
> > were not plugged, which happens often in real life), having separated
> > partitions usually makes the fsck faster.
> 
> This is complete bullshit. With a journaled filesystem, the boot time
> will greatly increase with the number of filesystems to check. If no
> files were modified in /usr, they won’t be mentioned in the journal, and
> that’s all. But having one journal to parse for all the system is
> definitely a measurable improvement.

If we want to improve fsck time then the best thing to do would be to consider 
a different default value for the -i option of mke2fs.

The current default is to have one Inode per 16K of disk space.  Of the 
Maildir format mail servers that I run the one with the smallest disk space 
used per Inode has 307G and 4773821 Inodes in use for an average of 67K per 
Inode.  A randomly selected Debian workstation with a lot of packages 
installed has for it's root filesystem 9.1G and 19 Inodes for an average 
of 49K.

As it seems quite unlikely that any non-root filesystem is going to have a 
smaller average Inode space usage than the root filesystem (I had expected 
Maildir to be the pathological case of small files) it seems quite safe to 
make the default be -i 49152 for non-root filesystems and be -i 32768 for root 
filesystems.

Finally using ext4 features either through "mke2fs -t ext4" or "mke4fs" will 
give you better fsck performance.  Are we doing ext4 by default nowadays?

As an aside "mke2fs -t ext4" includes huge_file, dir_nlink, and extra_isize 
while mke4fs doesn't.  This difference seems wrong to me.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


--
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/201112181327.08373.russ...@coker.com.au

Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib

2011-12-17 Thread Marco d'Itri 
On Dec 17, Roger Leigh  wrote:

> So WRT mounting /usr (and potentially /etc and other filesystems),
> I've pushed patches upstream for util-linux (initramfs mount option)
> and initramfs-tools (generate /etc/fstab from host and mount after
> rootfs).
From my answer to #652459:

This is highly suboptimal, because it suddenly makes the initramfs not
generic anymore.
The initramfs should:
- mount / as usual
- look at the rootfs fstab
- mount /usr using the information from the rootfs fstab

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bug#652423: Acknowledgement (ITP: v3c -- C/C++/sh/make/automake/Debian utility toolkit)

2011-12-17 Thread Philip Ashmore 

On 18/12/11 01:30, David Prévot wrote:

Le 17/12/2011 20:50, Philip Ashmore a écrit :

On 17/12/11 15:29, David Prévot wrote:

Please prefer the up to date developers' reference:

http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices#bpp-desc-basics

[…]

Please let me know what you think.

Quote from the previous URL:

“If you are having problems writing your description, you may wish to
send it along to  and request
feedback.”

Regards

David

Hmm. I'm a native English speaker although being from Ireland the odd 
twang may creep in.
I read the "best packaging practices link" above but I couldn't figure 
out how to add formatting to the

long description.

Is that where you think I need help?

Otherwise, if your issue is with me asking for a review of the packages 
long description,
martin f krafft  complained about the lack of long 
descriptions for my ITPs,

which I duly addressed.

Then Reinhard Tartler  had legitimate issues that I 
addressed with the updated long description.


If no one has any more issues with the new long description then I'll 
assume all is well.


Regards,
Philip Ashmore


--
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/4eed9796.7030...@philipashmore.com