Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Stefano Zacchiroli]

On Thu, May 06, 2010 at 09:11:56PM +0200, Petter Reinholdtsen wrote:
> These days, the init.d script dependencies in Squeeze are quite
> complete, so complete that it is actually possible to run all the
> init.d scripts in parallell based on these dependencies.

> Running scripts in parallel could be the default in Debian when we
> manage to get the init.d script dependencies complete and correct.  I
> expect we will get there in Squeeze+1, if we get manage to test and
> fix the remaining issues.

From your message I can't exactly tell why we can't have it for
Squeeze. My personal experience is that I've been using
CONCURRENCY=makefile since several months now, and I've never run into
problems.

Can't we just make it the default for Squeeze? (which would presumably
mean changing the default *now* in testing to seek the most feedback
possible before the actual release) If not, do you have a list of bugs
that block us from doing that? Or comments from the release team that
consider that not appropriate, or ...

The init.d world has changed quite a bit in recent years and might
change even more in the next, it is possible that for Squeeze+1 we'll
want to be elsewhere than at CONCURRENCY=makefile.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Josselin Mouette]

Le jeudi 06 mai 2010 à 21:11 +0200, Petter Reinholdtsen a écrit :
> These days, the init.d script dependencies in Squeeze are quite
> complete, so complete that it is actually possible to run all the
> init.d scripts in parallell based on these dependencies.  If you want
> to test your Squeeze system, make sure dependency based boot
> sequencing is enabled, and add this line to /etc/default/rcS:
> 
>   CONCURRENCY=makefile

Seems to work fine for me. However the gain isn’t really important,
given that the critical path includes fsck and networking.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “A handshake with whitnesses is the same
  `- as a signed contact.”  -- 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/1273218456.28184.1.ca...@meh

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Mike Hommey]

On Fri, May 07, 2010 at 09:47:36AM +0200, Josselin Mouette wrote:
> Le jeudi 06 mai 2010 à 21:11 +0200, Petter Reinholdtsen a écrit :
> > These days, the init.d script dependencies in Squeeze are quite
> > complete, so complete that it is actually possible to run all the
> > init.d scripts in parallell based on these dependencies.  If you want
> > to test your Squeeze system, make sure dependency based boot
> > sequencing is enabled, and add this line to /etc/default/rcS:
> > 
> >   CONCURRENCY=makefile
> 
> Seems to work fine for me. However the gain isn’t really important,
> given that the critical path includes fsck and networking.

And kernel+initramfs. That's more than half the boot time (without
even CONCURRENCY=makefile) here.

Mike


-- 
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/20100507075906.ga13...@glandium.org

ITP: kapow -- a punch clock program

[Tang Ke]

Package: wnpp
Severity: wishlist
Owner: Tang Ke 

* Package name: tanglet
   Version: 1.3.2
   Upstream Authors: Graeme Gott 
* URL:http://gottcode.org/kapow/
* License: GPL3
   Programming Lang: C++
   Description: a punch clock program

 Kapow is designed to easily keep  track of your hours,
 whether you're working on one project or many.Simply clock in  
 and out with the start/stop button. I you make a mistake in  
 your hours, you can go back and edit any of the entries by
 double-clicking on the session in question.




-- 
Tang Ke (Application develop of software department)
Tel：0086-512-52308628 Fax：0086-512-52308688
Phone:18962393077
E-mail:ta...@lemote.com  msn：ta...@lemote.com, mumut...@gmail.com
Web: http://www.lemote.com 
JiangSu ZhongKe Lemote Technology Co.,Ltd
MengLan Industry Park,YuShan,ChangShu City,JiangSu,China

<>

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Petter Reinholdtsen]

[Stefano Zacchiroli]
> From your message I can't exactly tell why we can't have it for
> Squeeze. My personal experience is that I've been using
> CONCURRENCY=makefile since several months now, and I've never run
> into problems.

I know there are bugs in the dependencies, which only affect some
combinations of packages when concurrent booting is enabled (example:
#508289) , and believe the number of users testing with
CONCURRENCY=makefile is so low that it is unlikely that all such bugs
have been found and detected.  There is also the issue with booting
too fast exposing race conditions, where the boot just happen to work
now in sequential mode.  I ran into issues with X failing to start
when CONCURRENCY=makefile and readahead were both enabled, and never
found time to track down the problem.  I suspect the cause is that
some services are not operational when their init.d script is
finished, causing their depending scripts to fail if the boot happen
too quickly.

And I also got the idea that Squeeze will freeze fairly soon, and
given my believe that there are edge cases and race conditions left to
fix, introducing it shortly before freeze seem like a bad idea.

All of this is based on my belief that there are very few people
testing with CONCURRENCY=makefile.  If a lot of people are using it
successfully, it is less likely that there are many race conditions
and edge cases left to fix, and enabling it for Squeeze would be a
more safe option.

Working with the boot system tend to make me very careful when
introducing changes, as a wrong upload can render a lot of machines
unable to boot. :)

> The init.d world has changed quite a bit in recent years and might
> change even more in the next, it is possible that for Squeeze+1
> we'll want to be elsewhere than at CONCURRENCY=makefile.

I am quite sure we will still have init.d scripts around (the LSB
require it), but I also hope we have replaced /sbin/init with an event
based system, pushed most scripts out of rcS.d/ and into rc[2-5].d or
event triggers.  It should both solve the broken single user in Debian
and make sure machines boot no matter the type of hardware
connected. :)

Happy hacking,
-- 
Petter Reinholdtsen


-- 
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/2fl6330b0f7@login1.uio.no

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Alexey Salmin]

On Fri, May 7, 2010 at 2:59 PM, Mike Hommey  wrote:
> On Fri, May 07, 2010 at 09:47:36AM +0200, Josselin Mouette wrote:
>> Le jeudi 06 mai 2010 à 21:11 +0200, Petter Reinholdtsen a écrit :
>> > These days, the init.d script dependencies in Squeeze are quite
>> > complete, so complete that it is actually possible to run all the
>> > init.d scripts in parallell based on these dependencies.  If you want
>> > to test your Squeeze system, make sure dependency based boot
>> > sequencing is enabled, and add this line to /etc/default/rcS:
>> >
>> >   CONCURRENCY=makefile
>>
>> Seems to work fine for me. However the gain isn’t really important,
>> given that the critical path includes fsck and networking.
>
> And kernel+initramfs. That's more than half the boot time (without
> even CONCURRENCY=makefile) here.

AFAIK the main idea right now is not to significantly speed up the
boot process but to move from obsolete lexicographic script ordering
and keep up with event-driven trends in the kernel. It's important to
test new infrastructure carefully and spread it across Debian users,
after that we can work on further improvements like decreasing the
boot time. I'm not a insserv developer though, please correct me if I
get it wrong.


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

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Goswin von Brederlow]

Stefano Zacchiroli  writes:

> On Thu, May 06, 2010 at 09:11:56PM +0200, Petter Reinholdtsen wrote:
>> These days, the init.d script dependencies in Squeeze are quite
>> complete, so complete that it is actually possible to run all the
>> init.d scripts in parallell based on these dependencies.
> 
>> Running scripts in parallel could be the default in Debian when we
>> manage to get the init.d script dependencies complete and correct.  I
>> expect we will get there in Squeeze+1, if we get manage to test and
>> fix the remaining issues.
>
> From your message I can't exactly tell why we can't have it for
> Squeeze. My personal experience is that I've been using
> CONCURRENCY=makefile since several months now, and I've never run into
> problems.
>
> Can't we just make it the default for Squeeze? (which would presumably
> mean changing the default *now* in testing to seek the most feedback
> possible before the actual release) If not, do you have a list of bugs
> that block us from doing that? Or comments from the release team that
> consider that not appropriate, or ...

Did you actualy read the mail till the end?

http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=initscripts-ng-de...@lists.alioth.debian.org

> The init.d world has changed quite a bit in recent years and might
> change even more in the next, it is possible that for Squeeze+1 we'll
> want to be elsewhere than at CONCURRENCY=makefile.

Yet again?

> Cheers.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87aascf7ex@frosties.localdomain

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Paul Wise]

On Fri, May 7, 2010 at 4:22 PM, Goswin von Brederlow  wrote:
> Stefano Zacchiroli  writes:
>> The init.d world has changed quite a bit in recent years and might
>> change even more in the next, it is possible that for Squeeze+1 we'll
>> want to be elsewhere than at CONCURRENCY=makefile.
>
> Yet again?

Other distros are using upstart:

http://upstart.ubuntu.com/

There are more interesting ideas on the horizon too:

http://0pointer.de/blog/projects/systemd

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

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Stefano Zacchiroli]

On Fri, May 07, 2010 at 10:22:14AM +0200, Goswin von Brederlow wrote:
> Did you actualy read the mail till the end?
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=initscripts-ng-de...@lists.alioth.debian.org

Yes, I did, and I noticed that none of those bugs are RC severity,
that's why I've explicitly asked for "blockers" (and yes, I could have
been explicit about that distinction in my mail).

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Marco d'Itri]

On May 07, Mike Hommey  wrote:

> And kernel+initramfs. That's more than half the boot time (without
> even CONCURRENCY=makefile) here.
I am still waiting for an answer from the kernel/initramfs-tools
maintainer about moving udevsettle from init-top to premount.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Aaron Toponce]

On 5/7/2010 2:33 AM, Paul Wise wrote:
> Other distros are using upstart:
> 
> http://upstart.ubuntu.com/

I thought Upstart was on the list for release in Sqeeze. Has this changed?

http://lists.debian.org/debian-devel-announce/2009/09/msg3.html

-- 
. O .   O . O   . . O   O . .   . O .
. . O   . O O   O . O   . O O   . . O
O O O   . O .   . O O   O O .   O O O



signature.asc
Description: OpenPGP digital signature

Bug#580643: [general] Chicony KU-0420 (Targus Slim Internet Media USB Keyboard) generates two incorrect symbols

[Filipus Klutiero]

Package: general
Severity: minor

The media player and my computer keys on the Chicony KU-0420 (aka Targus Slim 
Internet Media USB Keyboard) are
generating wrong symbols (with XKeyboardConfig 1.8). The first generates
XF86Tools instead of XF86AudioMedia and the second generates XF86Explorer
instead of XF86MyComputer.

The keys generate keycodes 179 and 152. This once worked with 
XKeyboardConfig 1.5. I reported the bug as a regression in 1.8, but here 
is the answer from XKeyboardConfig's maintainer: 
https://bugs.freedesktop.org/show_bug.cgi?id=27606


This system is different from the one on which I verified things were 
working. The "regression" (on my system's side) may be due to switching 
from kbd to evdev, if I understand Sergey correctly. But I don't 
remember which keyboard driver I was using, and trying to use the kbd 
driver doesn't help (all special keys don't work). If I understand 
Sergey correctly, this should be assigned to Linux.


--- System information. ---
Architecture: i386
Kernel: Linux 2.6.32-4-686

Debian Release: squeeze/sid
990 testing security.debian.org
990 testing ftp.ca.debian.org
500 unstable ftp.ca.debian.org
500 stable deb.opera.com
1 experimental ftp.ca.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/4be40cc0.3070...@gmail.com

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Petter Reinholdtsen]

[Aaron Toponce]
> I thought Upstart was on the list for release in Sqeeze. Has this changed?
>
> http://lists.debian.org/debian-devel-announce/2009/09/msg3.html

It is still on the wishlist, but the needed pieces are not ready, so
it seem unlikely to happen this late in the release process.  At the
moment, I believe it will happen shortly after Squeeze is released, if
the needed pieces are ready by then.

Happy hacking,
-- 
Petter Reinholdtsen


-- 
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/2fly6fvamzf@login1.uio.no

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Julien Cristau]

On Fri, May  7, 2010 at 14:57:08 +0200, Petter Reinholdtsen wrote:

> 
> [Aaron Toponce]
> > I thought Upstart was on the list for release in Sqeeze. Has this changed?
> >
> > http://lists.debian.org/debian-devel-announce/2009/09/msg3.html
> 
> It is still on the wishlist, but the needed pieces are not ready, so
> it seem unlikely to happen this late in the release process.  At the
> moment, I believe it will happen shortly after Squeeze is released, if
> the needed pieces are ready by then.
> 
What are the "needed pieces"?

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#580643: marked as done ([general] Chicony KU-0420 (Targus Slim Internet Media USB Keyboard) generates two incorrect symbols)

[Debian Bug Tracking System]

Your message dated Fri, 7 May 2010 15:23:25 +0200
with message-id <20100507132325.gh12...@radis.liafa.jussieu.fr>
and subject line Re: Bug#580643: [general] Chicony KU-0420 (Targus Slim 
Internet Media USB Keyboard) generates two incorrect symbols
has caused the Debian Bug report #580643,
regarding [general] Chicony KU-0420 (Targus Slim Internet Media USB Keyboard) 
generates two incorrect symbols
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
580643: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580643
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: general
Severity: minor

The media player and my computer keys on the Chicony KU-0420 (aka Targus Slim 
Internet Media USB Keyboard) are
generating wrong symbols (with XKeyboardConfig 1.8). The first generates
XF86Tools instead of XF86AudioMedia and the second generates XF86Explorer
instead of XF86MyComputer.

The keys generate keycodes 179 and 152. This once worked with 
XKeyboardConfig 1.5. I reported the bug as a regression in 1.8, but here 
is the answer from XKeyboardConfig's maintainer: 
https://bugs.freedesktop.org/show_bug.cgi?id=27606


This system is different from the one on which I verified things were 
working. The "regression" (on my system's side) may be due to switching 
from kbd to evdev, if I understand Sergey correctly. But I don't 
remember which keyboard driver I was using, and trying to use the kbd 
driver doesn't help (all special keys don't work). If I understand 
Sergey correctly, this should be assigned to Linux.


--- System information. ---
Architecture: i386
Kernel: Linux 2.6.32-4-686

Debian Release: squeeze/sid
990 testing security.debian.org
990 testing ftp.ca.debian.org
500 unstable ftp.ca.debian.org
500 stable deb.opera.com
1 experimental ftp.ca.debian.org


--- End Message ---
--- Begin Message ---
On Fri, May  7, 2010 at 08:51:12 -0400, Filipus Klutiero wrote:

> Package: general
> Severity: minor
> 
> The media player and my computer keys on the Chicony KU-0420 (aka Targus Slim 
> Internet Media USB Keyboard) are
> generating wrong symbols (with XKeyboardConfig 1.8). The first generates
> XF86Tools instead of XF86AudioMedia and the second generates XF86Explorer
> instead of XF86MyComputer.
> 
> The keys generate keycodes 179 and 152. This once worked with
> XKeyboardConfig 1.5. I reported the bug as a regression in 1.8, but
> here is the answer from XKeyboardConfig's maintainer:
> https://bugs.freedesktop.org/show_bug.cgi?id=27606
> 
> This system is different from the one on which I verified things
> were working. The "regression" (on my system's side) may be due to
> switching from kbd to evdev, if I understand Sergey correctly. But I
> don't remember which keyboard driver I was using, and trying to use
> the kbd driver doesn't help (all special keys don't work). If I
> understand Sergey correctly, this should be assigned to Linux.
> 
This is not debian-user, so closing the bug.

You can use the evtest program to see what scancode the kernel reports
for those keys, and get things fixed in the kernel or udev (see the
files in /lib/udev/keymaps) if they're not correct.

Cheers,
Julien


signature.asc
Description: Digital signature
--- End Message ---

Re: Bug#580533: ITP: libtest-notabs-perl -- module for scanning for hard tabs in files

[Jonathan Yu]

On Fri, May 7, 2010 at 2:11 AM, Yves-Alexis Perez  wrote:
> On jeu., 2010-05-06 at 12:26 -0400, Jonathan Yu wrote:
>> Test::NoTabs is a Perl test module that scans your project/distribution for
>> any Perl files (scripts, modules, etc) that contain hard tabs (the \t, or
>> 0x09) character. Tabs can render with slightly different width depending on
>> the author's environment, so it's best to use spaces instead.
>
> Do we really need a perl module for that?
Not sure if we do, but upstream modules certainly do. I should've
mentioned that this package is needed for MojoMojo (libmojomojo-perl)
currently, though I have been working with upstream so it will no
longer be a hard dependency in future releases.

At this point, I'm fine whether or not the ftp-master accepts it. I
have no personal attachment to this module, so I have no problem
withdrawing the ITP if enough people think I should do so.
> --
> Yves-Alexis
>


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

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Petter Reinholdtsen]

[Julien Cristau]
> What are the "needed pieces"?

I am sorry, do not have time to write a full update, so I give a quick
pointer instead.  The list we use to discuss the boot system work is
initscripts-ng-de...@.  See for example
http://lists.alioth.debian.org/pipermail/initscripts-ng-devel/2010-March/000844.html
 >
for a peek into the status.

Happy hacking,
-- 
Petter Reinholdtsten


-- 
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/20100507132943.gc10...@login1.uio.no

Bug#580650: ITP: libgraph-easy-as-svg-perl -- Output a Graph::Easy as Scalable Vector Graphics (SVG)

[Salvatore Bonaccorso]

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

* Package name: libgraph-easy-as-svg-perl
  Version : 0.23
  Upstream Author : Copyright (C) 2004 - 2008 by Tels L
* URL : http://search.cpan.org/dist/Graph-Easy-As_svg/
* License : GPL-2+
  Programming Lang: Perl
  Description : Output a Graph::Easy as Scalable Vector Graphics

Graph::Easy::As_svg contains just the code for converting a Graph::Easy object
to a SVG (Scalable Vector Graphics) text.



-- 
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/1273239709.886243.4...@elende

Re: Bug#580533: ITP: libtest-notabs-perl -- module for scanning for hard tabs in files

[Jonathan Yu]

On Fri, May 7, 2010 at 2:18 AM, Russ Allbery  wrote:
> Yves-Alexis Perez  writes:
>> On jeu., 2010-05-06 at 12:26 -0400, Jonathan Yu wrote:
>
>>> Test::NoTabs is a Perl test module that scans your project/distribution
>>> for any Perl files (scripts, modules, etc) that contain hard tabs (the
>>> \t, or 0x09) character. Tabs can render with slightly different width
>>> depending on the author's environment, so it's best to use spaces
>>> instead.
>
>> Do we really need a perl module for that?
>
> Well, it would be better to integrate the test in with something else,
> ideally, but I saw the ITP and thought "hm, that might be useful to start
> using with all my Perl projects."  Checking a file for lack of tabs is
> relatively easy, but locating all the Perl stuff in a source tree is a bit
> trickier, and rolling those two things together so that one can write a
> one- or two-line test is fairly useful.
>
> It would be nice if that, Test::Pod, Test::Fixme, Test::Synopsis,
> Test::MinimumVersion, and piles of other similar modules could be rolled
> together into one distribution.  But that's really an upstream problem.

For the record, Test::Pod is actually a pretty complex module.
(Correction: I was going to say this, but I just did a sloccount to
verify it, and it's only 112 lines of Perl code... interesting)

Perl is very much maintained by a bunch of different people, so having
one upstream package wouldn't work very well. Test::Pod is considered
fairly stable now and doesn't often have new releases, however, I
believe Test::Synopsis and Test::MinimumVersion are newer modules.

We could, I suppose, bundle these tests together in Debian, but it
opens a whole new can of worms. What would we call the package? How
would we decide what goes in there? Is it worth it to reduce the
Packages.gz file? (What other positive benefit would such a situation
provide, except to appease those who seem to hate new software being
added to Debian?)
>
> --
> 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/87bpcsgrq8@windlord.stanford.edu
>
>


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

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Steve Langasek]

On Fri, May 07, 2010 at 03:15:25PM +0200, Julien Cristau wrote:
> On Fri, May  7, 2010 at 14:57:08 +0200, Petter Reinholdtsen wrote:

> > [Aaron Toponce]
> > > I thought Upstart was on the list for release in Sqeeze. Has this changed?

> > > http://lists.debian.org/debian-devel-announce/2009/09/msg3.html

> > It is still on the wishlist, but the needed pieces are not ready, so
> > it seem unlikely to happen this late in the release process.  At the
> > moment, I believe it will happen shortly after Squeeze is released, if
> > the needed pieces are ready by then.

> What are the "needed pieces"?

Upstart doesn't work on any kernels other than Linux.  The original goal was
to have a compat layer to pull upstart jobs into the sysvinit system, which
would both address the hurd/BSD kernel issues and allow a soft transition to
upstart where users could opt to stay with sysvinit, but this compat layer
hasn't materialized.

So upstart by default in squeeze would require one of:

 - a compat layer for non-Linux ports
 - an upstart port to kfreebsd (and ideally hurd)
 - a decision to drop kfreebsd as a release architecture

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Julien Cristau]

On Fri, May  7, 2010 at 15:47:39 +0200, Steve Langasek wrote:

> Upstart doesn't work on any kernels other than Linux.  The original goal was
> to have a compat layer to pull upstart jobs into the sysvinit system, which
> would both address the hurd/BSD kernel issues and allow a soft transition to
> upstart where users could opt to stay with sysvinit, but this compat layer
> hasn't materialized.
> 
> So upstart by default in squeeze would require one of:
> 
>  - a compat layer for non-Linux ports
>  - an upstart port to kfreebsd (and ideally hurd)
>  - a decision to drop kfreebsd as a release architecture
> 
Thanks for the explanation, Steve.

Since 1 and 2 aren't happening, I think we should consider going with
the third option.  That's assuming there's still time to move to upstart
before the squeeze freeze; if there isn't, that means we should have
decided to drop kfreebsd earlier.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#580662: ITP: pyoptical -- python interface to the CRS 'OptiCAL' photometer

[Michael Hanke]

Package: wnpp
Severity: wishlist
Owner: Michael Hanke 

* Package name: pyoptical
  Version : 0.2
  Upstream Author : Valentin Haenel 
* URL : http://github.com/esc/pyoptical
* License : MIT/X
  Programming Lang: Python
  Description : python interface to the CRS 'OptiCAL' photometer

 The 'OptiCAL' is a photometer that is produced by Cambridge Research
 Systems (CRS).  This device is a standard tool for gamma-calibration of
 display devices in vision research. This package provides a
 free-software replacement for the Windows-software distributed by the
 manufacturer that allows querying an OptiCAL via a serial connection.
 pyoptical can be used as a library in third-party applications or as a
 standalone command line tool.



-- 
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/20100507145554.29196.50164.report...@meiner

Re: ITP: kapow -- a punch clock program

[Martín Ferrari]

2010/5/7 Tang Ke :

> * Package name: tanglet

is it called kapow or tanglet?

A couple of corrections in the description:

>  Kapow is designed to easily keep  track of your hours,
>  whether you're working on one project or many.Simply clock in

A space is missing after the dot.

>  and out with the start/stop button. I you make a mistake in

s/I/If/


-- 
Martín Ferrari


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

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Vincent Danjean]

On 07/05/2010 16:24, Julien Cristau wrote:
> On Fri, May  7, 2010 at 15:47:39 +0200, Steve Langasek wrote:
> 
>> Upstart doesn't work on any kernels other than Linux.  The original goal was
>> to have a compat layer to pull upstart jobs into the sysvinit system, which
>> would both address the hurd/BSD kernel issues and allow a soft transition to
>> upstart where users could opt to stay with sysvinit, but this compat layer
>> hasn't materialized.
>>
>> So upstart by default in squeeze would require one of:
>>
>>  - a compat layer for non-Linux ports
>>  - an upstart port to kfreebsd (and ideally hurd)
>>  - a decision to drop kfreebsd as a release architecture
>>
> Thanks for the explanation, Steve.
> 
> Since 1 and 2 aren't happening, I think we should consider going with
> the third option.  That's assuming there's still time to move to upstart
> before the squeeze freeze; if there isn't, that means we should have
> decided to drop kfreebsd earlier.

I would object to this analysis. Having a compat layer would also allow
to stick to sysvinit on linux ports. I think this is very important because
*lots* of system uses local sysvinit scripts and does not have ported them
to upstart (not even to inserv dependency...)
  If all linux ports are required to switch to an other thing than sysvinit
for squeeze, I think it will be a bad thing for lots of server admin in the
real world. If this is only the default upgrade path, then this would be
a good think.

  About the switch to a new boot system, I reported #576788 to ask for a
good, local, documentation. No answer for now. If it were only me, I would
put this bug RC. But as nobody else complains, I let it normal. I think
that local admin will be hit by hit when they will try to upgrade
their 'stable' Debian server with local specific init scripts.

  Regards,
Vincent

> Cheers,
> Julien


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


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

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Cyril Brulebois]

Since -bsd@ might be interested, Cc-ing them:

Steve Langasek  (07/05/2010):
> On Fri, May 07, 2010 at 03:15:25PM +0200, Julien Cristau wrote:
> > On Fri, May  7, 2010 at 14:57:08 +0200, Petter Reinholdtsen wrote:
> 
> > > [Aaron Toponce]
> > > > I thought Upstart was on the list for release in Sqeeze. Has this 
> > > > changed?
> 
> > > > http://lists.debian.org/debian-devel-announce/2009/09/msg3.html
> 
> > > It is still on the wishlist, but the needed pieces are not ready, so
> > > it seem unlikely to happen this late in the release process.  At the
> > > moment, I believe it will happen shortly after Squeeze is released, if
> > > the needed pieces are ready by then.
> 
> > What are the "needed pieces"?
> 
> Upstart doesn't work on any kernels other than Linux.  The original goal was
> to have a compat layer to pull upstart jobs into the sysvinit system, which
> would both address the hurd/BSD kernel issues and allow a soft transition to
> upstart where users could opt to stay with sysvinit, but this compat layer
> hasn't materialized.
> 
> So upstart by default in squeeze would require one of:
> 
>  - a compat layer for non-Linux ports
>  - an upstart port to kfreebsd (and ideally hurd)
>  - a decision to drop kfreebsd as a release architecture

Follow-ups available under:
  http://lists.debian.org/debian-devel/2010/05/msg00145.html

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#580667: ITP: r-cran-inline -- GNU R package to inline Fortran, C and C++ functions

[Dirk Eddelbuettel]

Package: wnpp
Owner: Dirk Eddelbuettel 
Severity: wishlist

* Package name: r-cran-inline
  Version : 0.3.4
  Upstream Author : Oleg Sklyar, Duncan Murdoch, Mike Smith, Dirk Eddelbuettel 
* URL or Web page : http://cran.r-project.org/web/packages/inline/
* License : LGPL-2.1
  Description : GNU R package to inline Fortran, C and C++ functions

This is a really small but immensely useful package which 'inlines' source
code from Fortran, C, or C++ into R -- and which compiles, links and loads
the resulting object code.  

We make extensive use of this in Rcpp (r-cran-rcpp) for the 230+ unit test
functions and now have a Depends rather than Suggests on it.

-- 
  Regards, Dirk



-- 
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/e1oapkd-0008en...@ron.nulle.part

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Marc Haber]

On Fri, 7 May 2010 09:26:18 +0200, Stefano Zacchiroli
 wrote:
>The init.d world has changed quite a bit in recent years and might
>change even more in the next, it is possible that for Squeeze+1 we'll
>want to be elsewhere than at CONCURRENCY=makefile.

If we want to be elsewhere for squeeze+1, why do we need to do a
critical migration twice?

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1oaqcy-0007lf...@swivel.zugschlus.de

/usr/bin/mail policy

[Florian Weimer]

bts from devscripts invokes mail with an -a flag, which has different
meanings in bsd-mailx and heirloom-mailx (the latter being some
sort-of-default in squeeze installations, apparently).

I'm not sure which package is at fault here.  Any suggestions?


-- 
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/87ocgr65zd@mid.deneb.enyo.de

Re: /usr/bin/mail policy

[James Vega]

On Fri, May 7, 2010 at 12:17 PM, Florian Weimer  wrote:
> bts from devscripts invokes mail with an -a flag, which has different
> meanings in bsd-mailx and heirloom-mailx (the latter being some
> sort-of-default in squeeze installations, apparently).

This has been brought up in #577564 as well.  The subject is a little
misleading since, at the time, I was under the impression mailx provided
the functionality we needed while mail didn't.

> I'm not sure which package is at fault here.  Any suggestions?

This is done to add extra headers to the mail being sent.  The
User-Agent header is always added and when --no-ack is specified the
X-Debbugs-No-Ack header is also added.

Since heirloom-mailx (and any mailx following the POSIX spec) doesn't
have a way to specify extra headers, I've been considering changing
this.  X-Debbugs-No-Ack can be set as a pseudo-header and the User-Agent
header was only added in response to #493884.  While the User-Agent
header is useful, I could see backing out this change so bts doesn't
require the non-standard -a flag.

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega 


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

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Stefano Zacchiroli]

On Fri, May 07, 2010 at 06:15:24PM +0200, Marc Haber wrote:
> On Fri, 7 May 2010 09:26:18 +0200, Stefano Zacchiroli  wrote:
> >The init.d world has changed quite a bit in recent years and might
> >change even more in the next, it is possible that for Squeeze+1 we'll
> >want to be elsewhere than at CONCURRENCY=makefile.
> 
> If we want to be elsewhere for squeeze+1, why do we need to do a
> critical migration twice?

(Beside the nitpick on "we want" vs "we possibly want") I'd argue that
it's because we want a faster boot from our users ASAP. More
importantly, I was trying to understand whether the migration really is
critical, as the shown bug list didn't seem to imply that.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Bug#580533: ITP: libtest-notabs-perl -- module for scanning for hard tabs in files

[Russ Allbery]

Jonathan Yu  writes:

> We could, I suppose, bundle these tests together in Debian, but it
> opens a whole new can of worms. What would we call the package? How
> would we decide what goes in there? Is it worth it to reduce the
> Packages.gz file? (What other positive benefit would such a situation
> provide, except to appease those who seem to hate new software being
> added to Debian?)

I'm not a big fan of bundling together for Debian things that have
separate upstreams, releases, and versions.  It's horribly confusing and
awkward.

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

Bug#580686: ITP: iroffer-dinoex -- IRC file distribution bot

[Firas Kraiem]

Package: wnpp
Severity: wishlist
Owner: Firas Kraiem 
Owner: Firas Kraiem 

* Package name: iroffer-dinoex
  Version : 3.21
  Upstream Author : David Johnson (PMG) 
Dirk Meyer (dinoex) 
* URL : http://iroffer.dinoex.net/
* License : GPLv2
  Programming Lang: C
  Description : IRC file distribution bot

 iroffer is a fileserver for IRC (commonly referred to as a DCC bot).
 It uses the DCC feature of IRC to send files to other users. iroffer
 will connect to an IRC server and let people request files from it.
 Unlike similar programs, iroffer is not a script; it is a standalone
 executable written entirely in C, from scratch, with high transfer
 speed and efficiency in mind. iroffer has been known to reach
 6MByte/sec or higher bandwidth usage when multiple transfers are
 occurring at the same time.
 .
 iroffer-dinoex is a fork of iroffer developed and maintained by
 Dirk Meyer. It offers a lot of enhancements and new features,
 and is backwards-compatible with the original iroffer. New features
 offered by iroffer-dinoex include support for IPv6, SSL (either via
 OpenSSL or GNU TLS), passive DCC, large (> 4 GB) files, UPnP, and
 the ability to extend it via a Ruby scripting engine.



-- 
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/20100507185059.5178.65193.report...@itsuki.fkraiem.org

Re: /usr/bin/mail policy

[Bernd Eckenfels]

In article  you 
wrote:
> Since heirloom-mailx (and any mailx following the POSIX spec) doesn't
> have a way to specify extra headers

What about using /usr/sbin/sendmail?

Gruss
Bernd


-- 
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/201005071818.o47iiqlf056...@neskaya.eckenfels.net

Re: /usr/bin/mail policy

[James Vega]

On Fri, May 7, 2010 at 2:18 PM, Bernd Eckenfels  wrote:
> In article  
> you wrote:
>> Since heirloom-mailx (and any mailx following the POSIX spec) doesn't
>> have a way to specify extra headers
>
> What about using /usr/sbin/sendmail?

Currently, our mail sending mechanisms fall into two categories:
either $DEBEMAIL or $EMAIL is set or they aren't.  For the former, one
of mutt, sendmail, or a direct smtp connection is used to send the
email.  For the latter, we use mail to generate a From address for us
and send the email.

If people consider it acceptable to require $DEBEMAIL or $EMAIL to be
set, then I have no problem removing our use of the mail command.

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega 


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

Bug#580694: ITP: liblocale-rails-ruby -- Pure ruby library with basic functions for localization

[Gunnar Wolf]

Package: wnpp
Severity: wishlist
Owner: Gunnar Wolf 
Owner: Gunnar Wolf 

* Package name: liblocale-rails-ruby
  Version : 2.0.5
  Upstream Author : Masao Mutoh 
* URL : http://www.yotabanana.com/hiki/ruby-locale-rails.html
* License : GPLv2 / LGPLv3 / Ruby
  Programming Lang: Ruby
  Description : Pure ruby library with basic functions for localization

Bindings for basic Ruby localization functions for Rails applications



-- 
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/20100507203856.13594.79802.report...@mosca.local.iiec

Bug#580697: ITP: libgettext-rails-ruby -- Gettext support for Rails applications

[Gunnar Wolf]

Package: wnpp
Severity: wishlist
Owner: Gunnar Wolf 
Owner: Gunnar Wolf 

* Package name: libgettext-rails-ruby
  Version : 2.1.0
  Upstream Author : Masao Mutoh 
* URL : http://www.yotabanana.com/hiki/ruby-gettext.html
* License : GPLv2, LGPLv3, Ruby
  Programming Lang: Ruby
  Description : Gettext support for Rails applications

Provides localization support for Ruby on Rails applications using the
familiar GNU Gettext syntax and semantics. Its main features are: 

* Autodetects client's locale using locale/locale_rails.
* Easy maintainance of translations using the powerful gettext tools.
* Model translation using gettext_activerecord.
* Localization for some helpers.
* Works with other Rails I18n backends (note that gettext_rails is not
  one of the I18n backends)
* Thread safe.



-- 
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/20100507204653.13008.85408.report...@mosca.local.iiec

Bug#580701: ITP: libgettext-activerecord-ruby -- Localization support for applications using ActiveRecord

[Gunnar Wolf]

Package: wnpp
Severity: wishlist
Owner: Gunnar Wolf 
Owner: Gunnar Wolf 

* Package name: libgettext-activerecord-ruby
  Version : 2.1.0
  Upstream Author : Masao Mutoh 
* URL : http://www.yotabanana.com/hiki/ruby-gettext.html
* License : GPLv2+LGPLv3+Ruby
  Programming Lang: Ruby
  Description : Localization support for applications using ActiveRecord
Localization support for ActiveRecord-2.2 or later using
libgettext-ruby. Its features include:

* Validation messages translation
* Model translation
  * extract messages from models with the rake task.



-- 
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/20100507205745.15209.39093.report...@mosca.local.iiec

Bug#580696: ITP: libpdl-io-hdf5-perl -- PDL Interface to the HDF5 Data Format

[Henning Glawe]

Package: wnpp
Severity: wishlist
Owner: Henning Glawe 
Owner: Henning Glawe 

* Package name: libpdl-io-hdf5-perl
  Version : 0.6
  Upstream Author : John Cerney 
* URL : http://cpansearch.perl.org/src/CERNEY/PDL-IO-HDF5-0.6/
* License : same as Perl
  Programming Lang: Perl, PDL
  Description : PDL Interface to the HDF5 Data Format

This package provides an object-oriented interface for the
PDL package to the HDF5 data-format. Information on the
HDF5 Format can be found at the NCSA's web site at
http://hdf.ncsa.uiuc.edu/ .
.
LIMITATIONS
.
Currently this interface only provides a subset of the total
HDF5 library's capability.
.
* Only HDF5 Simple datatypes are supported. No HDF5 Compound
  datatypes are supported since PDL doesn't support them.
.
* Only HDF5 Simple dataspaces are supported.


-- 
c u
henning



-- 
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/20100507204233.ga20...@ford.simpsons.bogus

Re: Bug#580686: ITP: iroffer-dinoex -- IRC file distribution bot

[Firas Kraïem]

Hi,

this is my fist package, please comment so I don't send a RFS for nothing if 
the package is wrong.

Thanks

Firas


The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/i/iroffer-dinoex
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget http://mentors.debian.net/debian/pool/main/i/iroffer-dinoex/iroffer-
dinoex_3.21-1.dsc


On Friday 07 May 2010 20:50:59 Firas Kraiem wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Firas Kraiem 
> Owner: Firas Kraiem 
> 
> * Package name: iroffer-dinoex
>   Version : 3.21
>   Upstream Author : David Johnson (PMG) 
> Dirk Meyer (dinoex) 
> * URL : http://iroffer.dinoex.net/
> * License : GPLv2
>   Programming Lang: C
>   Description : IRC file distribution bot
> 
>  iroffer is a fileserver for IRC (commonly referred to as a DCC bot).
>  It uses the DCC feature of IRC to send files to other users. iroffer
>  will connect to an IRC server and let people request files from it.
>  Unlike similar programs, iroffer is not a script; it is a standalone
>  executable written entirely in C, from scratch, with high transfer
>  speed and efficiency in mind. iroffer has been known to reach
>  6MByte/sec or higher bandwidth usage when multiple transfers are
>  occurring at the same time.
>  .
>  iroffer-dinoex is a fork of iroffer developed and maintained by
>  Dirk Meyer. It offers a lot of enhancements and new features,
>  and is backwards-compatible with the original iroffer. New features
>  offered by iroffer-dinoex include support for IPv6, SSL (either via
>  OpenSSL or GNU TLS), passive DCC, large (> 4 GB) files, UPnP, and
>  the ability to extend it via a Ruby scripting engine.


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

Bug#580717: ITP: ctemplate -- A simple but powerful template language for C++ - development files

[Mark Purcell]

Package: wnpp
Severity: wishlist
Owner: Mark Purcell 
Owner: Mark Purcell 

* Package name: ctemplate
  Version : 0.96
  Upstream Author : Google Inc. 
* URL :  http://code.google.com/p/google-ctemplate/
* License : BSD'ish - see below
  Programming Lang: C++
  Description : A simple but powerful template language for C++ - 
development files

a library implementing a simple but
 powerful template language for C++.  It emphasizes separating logic
 from presentation: it is impossible to embed application logic in this
 template language.  The devel package contains static and debug
 libraries and header files for developing applications that use the
 ctemplate package.

Initial packaging based on ubuntu: http://packages.ubuntu.com/ctemplate

Build-Depends for kraft application.

Mark


Source: http://code.google.com/p/google-ctemplate/
Copyright: 2006-2009, Google Inc. 
License:
 All rights reserved.
 
 Redistribution and use in source and binary forms, with or without
 modification, are permitted provided that the following conditions are
 met:

 * Redistributions of source code must retain the above copyright
 notice, this list of conditions and the following disclaimer.
 * Redistributions in binary form must reproduce the above
 copyright notice, this list of conditions and the following disclaimer
 in the documentation and/or other materials provided with the
 distribution.
 * Neither the name of Google Inc. nor the names of its
 contributors may be used to endorse or promote products derived from
 this software without specific prior written permission.
 
 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Files: contrib/highlighting.vim
Copyright: 2006, Patrick Lacasse 

Files: contrib/tpl-mode.el
Copyright: 2006, Tony Gentilcore

Files: contrib/convert_to_95.pl
Copyright: 2006, Google Inc. 



-- 
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/20100507235802.16401.92300.report...@hp.purcell.id.au

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Raphael Geissert]

Vincent Danjean wrote:

> Having a compat layer would also allow
> to stick to sysvinit on linux ports. I think this is very important
> because *lots* of system uses local sysvinit scripts and does not have
> ported them to upstart (not even to inserv dependency...)

Support for SysV init scripts is not going to be removed.
The compat layer is to allow non-linux ports to run upstart jobs.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


-- 
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/hs2ecp$3q...@dough.gmane.org

Bug#580718: ITP: kraft -- small business-management application

[Mark Purcell]

Package: wnpp
Severity: wishlist
Owner: Mark Purcell 
Owner: Mark Purcell 

* Package name: kraft
  Version : 0.40
  Upstream Author : Klaas Freitag 
* URL : http://kraft.sourceforge.net/
* License : GPL2+
  Programming Lang: C++
  Description : small business-management application

 Kraft is an application for people who operate a small business. Kraft helps to
 write business communication documents like offers and invoices.
 .
 Kraft is not a program specialised on a certain trade or craft. Instead Kraft
 covers the practical issues of a small business and helps through ease of use
 yet powerful features to deal with most of the office jobs effectively.



Packaging based on Ubuntu PPA; Rohan Garg 

This package was debianized by Jonathan Patrick Davies  on
Tue, 11 Dec 2007 21:17:11 +0200.

It was downloaded from http://kraft.sourceforge.net/

Upstream Author: Klaas Freitag 

Copyright:
Copyright (C) 2003 - 2007 Klaas Freitag 

License:

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful, 
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software Foundation,
Inc., 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA 

On Debian GNU/Linux systems, the complete text of the GNU General
Public License can be found in the /usr/share/common-licenses/GPL file.

The Debian packaging is (C) 2007, Jonathan Patrick Davies 
and is licensed under the version 2 or (at your option) any later version of the
GPL, see above.



-- 
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/20100508011721.30659.63131.report...@hp.purcell.id.au

Re: Bug#580686: ITP: iroffer-dinoex -- IRC file distribution bot

[Paul Wise]

On Sat, May 8, 2010 at 5:16 AM, Firas Kraïem  wrote:

> this is my fist package, please comment so I don't send a RFS for nothing if
> the package is wrong.

RFS should be sent to debian-mentors, not debian-devel.

Please read the FAQ for more info:

http://people.debian.org/~mpalmer/debian-mentors_FAQ.html

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

Dual init scripts (or two init scripts in one package)

[Roberto C . Sánchez]

Greetings.  I am curious as to how the scenario described in the below
message would work in Debian.  That is, can one package install two init
scripts?

Regards,

-Roberto

- Forwarded message from Tom Eastep  -

Date: Tue, 04 May 2010 12:28:47 -0700
Subject: Dual init scripts
From: Tom Eastep 
To: "Roberto C. Sanchez" 

Hi Roberto,

The Gentoo folks have an issue with the way that Shorewall is normally
started; namely, we supply init scripts that start the firewall after
networking has started. This is an issue in that there is a window after
networking starts but before Shorewall starts when the firewall is wide
open.

SuSEFirewall manages this issue by having multiple init scripts; one
that runs prior to networking startup and one that runs after. That is
what I'm planning to do with Shorewall in 4.4.10. So the question is,
can a single 'shorewall' package (for example), provide both scripts or
do I need four additional packages, the only purpose of which would be
to provide 4 additional init scripts.

Thanks,
-Tom
-- 
Tom Eastep\ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \

- End forwarded message -

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


signature.asc
Description: Digital signature

Re: Dual init scripts (or two init scripts in one package)

[Russ Allbery]

Roberto C. Sánchez  writes:

> Greetings.  I am curious as to how the scenario described in the below
> message would work in Debian.  That is, can one package install two init
> scripts?

Sure.  A package can install as many init scripts as it wants and needs.

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