Bug#552188: ITP: libcatalyst-plugin-server-perl -- Catalyst plugin implementing base server functionality

[Jonathan Yu]

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

* Package name: libcatalyst-plugin-server-perl
  Version : 0.26
  Upstream Author : Jos Boumans 
* URL : http://search.cpan.org/dist/Catalyst-Plugin-Server/
* License : Artistic | GPL-1+
  Programming Lang: Perl
  Description : Catalyst plugin implementing base server functionality

 Catalyst::Plugin::Server is a Perl module that extends Catalyst by providing
 a basic XMLRPC server using the RPC::XML module (see librpc-xml-perl). There
 is also support planned for a SOAP server. This module replaces the feature
 set formerly provided by Catalyst::Plugin::XMLRPC.

NOTE: this package used to be part of libcatalyst-modules-perl. It's
>800 lines long, so I'd like to split it into its own package. Also
lets us patch things (to fix FTBFS issues with RPC::XML)



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

Bug#552187: ITP: libppix-regexp-perl -- Perl module to parse regular expressions

[Jonathan Yu]

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

* Package name: libppix-regexp-perl
  Version : 0.001
  Upstream Author : Tom Wyant 
* URL : http://search.cpan.org/dist/PPIx-Regexp/
* License : Artistic | GPL-1+
  Programming Lang: Perl
  Description : Perl module to parse regular expressions

 PPIx::Regexp is a Perl module designed to parse regular expressions in a
 manner similar to the way that PPI parsers Perl documents. This class forms
 the root of the parse tree, playing a role similar to PPI::Document. Like
 PPI, this module produces output which is round-trip safe.

NOTE: this package was requested by Hydroxide via the #debian-perl channel



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

Bug#552184: ITP: furiusisomount -- An ISO, IMG, BIN, MDF and NRG image management utility

[Alessio Treglia]

Package: wnpp
Severity: wishlist
Owner: Alessio Treglia 

* Package name: furiusisomount
  Version : 0.11.1.2
  Upstream Author : Dean Harris 
* URL : https://launchpad.net/furiusisomount
* License : GPL
  Programming Lang: Python
  Description : An ISO, IMG, BIN, MDF and NRG image management utility

 Furius ISO Mount is a simple application for mounting .iso, .img, .bin, .mdf
 and .ng image files without burning them to disk.
 .
 It provides the following features:
  - Automatically Mounts ISO, IMG, BIN, MDF and NRG image files.
  - Automatically creates a mount point in your home directory.
  - Automatically Unmounts the Image files.
  - Automatically removes the mount directory to return your home directory to
its previous state.
  - Automatically saves the history of the last 10 images mounted.
  - Mounts multiple images.
  - Burn ISO and IMG Files to optical disk.
  - Generate Md5 and SHA1 checksums.
  - Automatically retrieves any previously unmounted images.
  - Automatically generates a log file of all commands needed to mount and
unmount images manually.
  - Language support (currently Czech, Danish, French, Hungarian, Italian,
German, Polish, Slovenian, Spanish and Turkish are available).

-- System Information:
Debian Release: 5.0
  APT prefers jaunty-updates
  APT policy: (500, 'jaunty-updates'), (500, 'jaunty-security'), (500, 
'jaunty-backports'), (500, 'jaunty')
Architecture: amd64 (x86_64)



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

Re: Bug#545691: diverting telinit

[Manoj Srivastava]

On Fri, Oct 23 2009, Bernd Eckenfels wrote:

> In article <87r5sudn0p.fsf...@anzu.internal.golden-gryphon.com> you wrote:
>> [ "$(stat -c %d/%i /sbin/init)" = "$(stat -Lc %d/%i /proc/1/exe 
>> 2>/dev/null)" ] ; then
>> # So, init exists, and there is a linuxy /proc, and the inode of
>> # the executable of the process with uid 1 is the same as
>> # /sbin/init (ok, no init=/bin/sh going on)
>
> Maybe another check besides inode idendity is better, otherwise it will not
> be able to be used afer an upgrade (and before reboot), or?

Not needed. If init has been just upgraded, it has been already
 told to init -u itself. So, what are the cases?

Consider the events:

 I1 Init unpacked
 I2 my package unpacked 

 C1 Init configured
 C2 my package configured

 These work 
 A) I1 I2 C1 C2
 B) I1 I2 C2 C1
 C) I2 I1 C1 C2
 D) I2 I1 C2 C1
 E) I1 C1 I2 C2
 F) I2 C2 I1 C1

What failure modes do you see that I need to clutter up my
 postinst to accommodate?

> And for the "else" case a diagnostics message would be good.

Umm, this is opportunistic: I don't think people want tob e
 bothered when running qemubuilder or doing things in a chroot. I am nto
 sure the information is valuable enough to clutter up the user
 interface; I am willing to hear reasons why I am wrong.

manoj
-- 
"But this one goes to eleven." Nigel Tufnel
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Bug#550031: ITP: libjs-extjs -- a cross-browser JavaScript library

[Thomas Goirand]

> Thomas,
>
> I discussed this matter with our CEO and he asked me to resolve the
> compliancy.  I iwll update you shortly.
>
> ~ Adam

Hi Adam,

Ok, that sounds good, as I would really hate to push for a
package that has some controversy on the freeness of it's license.
I am very happy to see that you guys respond to emails, and this
makes me feel a lot more comfortable for this packaging.

I have already done my packaging, you can get the Debian package
from there if you want to test/see/comment them:

http://ftparchive.gplhost.com/debian/pool/lenny/main/l/libjs-extjs/

At the time of reading, it should also have reached all of our
mirrors around the world.

As you can see, I have separated the library itself from the
documentation, as it was rather big, and this is a good practice
in this case in Debian.

Let me know when you update your site and/or your licensing,

Best Regards,

Thomas Goirand

-- 
Thomas Goirand
GPLHost CEO
Phone numbers: +1 302 213 1611 (USA) / +33 177627734 (France)
+44 8449108864 (UK) / +61 280617698 (Australia)
Web: http://www.gplhost.com
GPLHost:>_ Open source hosting worldwide
Web spaces featuring GPL control panel and Xen VPS
Locations in Singapore, Sydney, Seattle, Florida, Paris, London,
 Barcelona, Israel and Malaysia



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

Re: perl and perl-modules; reflexive dependencies vs. archive bloat

[James Vega]

On Fri, Oct 23, 2009 at 03:22:34PM -0700, Don Armstrong wrote:
> On Sat, 24 Oct 2009, Josselin Mouette wrote:
> > Le vendredi 23 octobre 2009 à 14:25 -0700, Don Armstrong a écrit : 
> > > 3: Specifically, where Package A Depends on (B=1), and Package B
> > > Depends on A; A and B are from the same source, B is architecture
> > > independent, and does not require configuration.
> > 
> > In the general case, B doesn’t need to depend on A. So this is not a
> > problem for that many packages.
> 
> Generally speaking, A tends to be necessary for B "to provide a
> significant amount of functionality". 
> 
> However, I agree that in almost all cases (including this case) it
> seems silly for any other package to depend on B or for users to
> install B directly. I actually suggested that perl-modules recommend
> perl, but that was rejected for the reason that perl-modules doesn't
> do anything useful without perl.

I don't see how perl-modules is that much different than the various
arch-independent data packages which provide little to no functionality
on their own but are required by another arch-dependent package.  Many
of those either Recommend the relevant package or declare no
relationship at all.

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


signature.asc
Description: Digital signature

Re: perl and perl-modules; reflexive dependencies vs. archive bloat

[Don Armstrong]

On Sat, 24 Oct 2009, Josselin Mouette wrote:
> Le vendredi 23 octobre 2009 à 14:25 -0700, Don Armstrong a écrit : 
> > 3: Specifically, where Package A Depends on (B=1), and Package B
> > Depends on A; A and B are from the same source, B is architecture
> > independent, and does not require configuration.
> 
> In the general case, B doesn’t need to depend on A. So this is not a
> problem for that many packages.

Generally speaking, A tends to be necessary for B "to provide a
significant amount of functionality". 

However, I agree that in almost all cases (including this case) it
seems silly for any other package to depend on B or for users to
install B directly. I actually suggested that perl-modules recommend
perl, but that was rejected for the reason that perl-modules doesn't
do anything useful without perl.


Don Armstrong

-- 
Whatever you do will be insignificant, but it is very important that
you do it.
 -- Mohandas Karamchand Gandhi

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

Re: perl and perl-modules; reflexive dependencies vs. archive bloat

[Josselin Mouette]

Le vendredi 23 octobre 2009 à 14:25 -0700, Don Armstrong a écrit : 
> Because this is a common situtation, where there is architecture
> independent data (of varying sizes) which is interdependent on
> architecture specific code of a particular version, reflexive
> dependencies are necessary.[2]

> 3: Specifically, where Package A Depends on (B=1), and Package B
> Depends on A; A and B are from the same source, B is architecture
> independent, and does not require configuration.

In the general case, B doesn’t need to depend on A. So this is not a
problem for that many packages.



-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: Bug#545691: diverting telinit

[Bernd Eckenfels]

In article <87r5sudn0p.fsf...@anzu.internal.golden-gryphon.com> you wrote:
> [ "$(stat -c %d/%i /sbin/init)" = "$(stat -Lc %d/%i /proc/1/exe 
> 2>/dev/null)" ] ; then
> # So, init exists, and there is a linuxy /proc, and the inode of
> # the executable of the process with uid 1 is the same as
> # /sbin/init (ok, no init=/bin/sh going on)

Maybe another check besides inode idendity is better, otherwise it will not
be able to be used afer an upgrade (and before reboot), or?

And for the "else" case a diagnostics message would be good.

Gruss
Bernd


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

perl and perl-modules; reflexive dependencies vs. archive bloat

[Don Armstrong]

Currently there is a proposal[0] to combine perl-modules and perl into
a single package. perl-modules currently contains architecture
independent bits, and perl contains architecture dependent bits.

FWICT, the primary argument[1] to do this is because perl and
perl-modules both require the other to function properly (so a
reflexive dependency or combining is reqeuired), and because circular
dependencies make things complicated for dpkg and other frontends.

Because this is a common situtation, where there is architecture
independent data (of varying sizes) which is interdependent on
architecture specific code of a particular version, reflexive
dependencies are necessary.[2]

Are there still tools which are in use which are unable to handle
reflexive dependencies of this type?[3] If so, does the effort to fix
them outweigh the effort to remove all of the circular dependencies
and the resultant archive bloat?x


Don Armstrong

0: http://lists.debian.org/debian-release/2009/10/msg00226.html (cc'ed
to -release, but further discussion should not happen there because
release isn't a discussion list.)

1: 
http://lists.alioth.debian.org/pipermail/perl-maintainers/2009-October/000799.html

2: The alternative is of course, archive bloat, where we have multiple
copies of such data; the instant case will only contribute around 150M
(3.1M*(13 archs-1)*4 releases) to the size of the archive, but I've no
doubt that there are larger examples.

3: Specifically, where Package A Depends on (B=1), and Package B
Depends on A; A and B are from the same source, B is architecture
independent, and does not require configuration.
-- 
The computer allows you to make mistakes faster than any other
invention, with the possible exception of handguns and tequila
 -- Mitch Ratcliffe

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

Re: Bug#545691: diverting telinit

[Manoj Srivastava]

On Fri, Oct 23 2009, brian m. carlson wrote:

> On Fri, Oct 23, 2009 at 12:43:18PM -0500, Manoj Srivastava wrote:
>>  if [ -x /sbin/init ] && [ -d /proc/1 ] &&
>>  [ "$(stat -c %d/%i /sbin/init)" = "$(stat -Lc %d/%i /proc/1/exe 
>> 2>/dev/null)" ] ; then
>>  # So, init exists, and there is a linuxy /proc, and the inode of
>>  # the executable of the process with uid 1 is the same as
>>  # /sbin/init (ok, no init=/bin/sh going on)
>> 
>>  if [ "$(stat -c %d/%i /)" = "$(stat -Lc %d/%i /proc/1/root 
>> 2>/dev/null)" ]; then
>>  # the devicenumber/inode pair of / is the same as that of
>>  # /sbin/init's root, so we're *not* in a chroot
>> 
>>  # Final sanity check. Make sure there is a /dev/initctl
>>  # for us to talk to
>>  if [ -e /dev/initctl ]; then
>
> Last I checked, the kfreebsd-* architectures don't use /dev/initctl; I
> think it's something like /etc/.initctl.  They do, however, have a
> linuxy proc.  You should probably check with the porters as to what
> location is appropriate on those architectures.

Well, this was not an issue i my case, since these packages do
 not support  ! linux, but yes, a generic solution would have to cater
 to that as well.

manoj
-- 
Today is the first day of the rest of the mess.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Bug#545691: diverting telinit

[brian m. carlson]

On Fri, Oct 23, 2009 at 12:43:18PM -0500, Manoj Srivastava wrote:
>  if [ -x /sbin/init ] && [ -d /proc/1 ] &&
>  [ "$(stat -c %d/%i /sbin/init)" = "$(stat -Lc %d/%i /proc/1/exe 
> 2>/dev/null)" ] ; then
>  # So, init exists, and there is a linuxy /proc, and the inode of
>  # the executable of the process with uid 1 is the same as
>  # /sbin/init (ok, no init=/bin/sh going on)
> 
>  if [ "$(stat -c %d/%i /)" = "$(stat -Lc %d/%i /proc/1/root 2>/dev/null)" 
> ]; then
>  # the devicenumber/inode pair of / is the same as that of
>  # /sbin/init's root, so we're *not* in a chroot
> 
>  # Final sanity check. Make sure there is a /dev/initctl
>  # for us to talk to
>  if [ -e /dev/initctl ]; then

Last I checked, the kfreebsd-* architectures don't use /dev/initctl; I
think it's something like /etc/.initctl.  They do, however, have a
linuxy proc.  You should probably check with the porters as to what
location is appropriate on those architectures.

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


signature.asc
Description: Digital signature

Bug#545691: diverting telinit

[Manoj Srivastava]

Hi,

I am pulling this discussion off 545...@bugs.debian.org and on
 to the devel list, in case it has broader interest. The issue was that
 a maintainer script called telinit to communicate with init, and that
 does not work when the kernel has been started with
 'init=/bin/bash'. (qemubuilder was impacted in the bug, but this might
 need a general fix).

I created a elaborate test case tos ee if we are in a chroot, if
 not if /proc/1 is actually /sbin/init, and that telinit exists (example
 below).

Does this need discussion?

manoj

 if [ -x /sbin/init ] && [ -d /proc/1 ] &&
 [ "$(stat -c %d/%i /sbin/init)" = "$(stat -Lc %d/%i /proc/1/exe 
2>/dev/null)" ] ; then
 # So, init exists, and there is a linuxy /proc, and the inode of
 # the executable of the process with uid 1 is the same as
 # /sbin/init (ok, no init=/bin/sh going on)

 if [ "$(stat -c %d/%i /)" = "$(stat -Lc %d/%i /proc/1/root 2>/dev/null)" 
]; then
 # the devicenumber/inode pair of / is the same as that of
 # /sbin/init's root, so we're *not* in a chroot

 # Final sanity check. Make sure there is a /dev/initctl
 # for us to talk to
 if [ -e /dev/initctl ]; then
 # Use telinit if available, it is better form, according
 # to the sysvinit maintainer.
 if [ -x /sbin/telinit ]; then
 (telinit u ; sleep 1)
 else
 (init u ; sleep 1)
 fi
 fi
 fi
 fi

-- 
Whether in the village or the forest, whether on high ground or low,
wherever the enlightened live, that is a delightful spot. 98
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Bug#551992: marked as done (general: stopping squeeze chroot shuts system)

[Debian Bug Tracking System]

Your message dated Fri, 23 Oct 2009 17:39:54 +0200
with message-id <200910231739.55125.hol...@layer-acht.org>
and subject line Re: Bug#551992: general: stopping squeeze chroot shuts system
has caused the Debian Bug report #551992,
regarding general: stopping squeeze chroot shuts system
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.)


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


On this system I installed a squeeze chroot using the following command:

debootstrap squeeze /chroot/squeeze-x64-lighttpd-chroot 
http://ftp.debian.org/debian/

This works as expected but when I stop the chroot, the system shuts as well.
This is highly unexpected and somewhat unpleasant behaviour.

Regards,
Martin Boer

mar...@grachtwal.nu


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

Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash


--- End Message ---
--- Begin Message ---
not a bug


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

Bug#552120: ITP: playdar -- music content resolver

[Paul Brossier]

Package: wnpp
Severity: wishlist
Owner: Paul Brossier 

* Package name: playdar
  Version : 0.1.8
  Upstream Author : Richard Jones
* URL : http://www.playdar.org/
* License : MIT/X
  Programming Lang: Erlang
  Description : music content resolver

Playdar is a music content resolver service - run it on every computer
you use, and you'll be able to listen to all the songs you would
otherwise be able to find manually by searching though all your
computers, hard disks, online services, and more.



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

Bug#551992: general: stopping squeeze chroot shuts system

[Mike Hommey]

On Fri, Oct 23, 2009 at 12:04:02PM +0200, mar...@grachtwal.nu wrote:
> >> In a lenny chroot, on the same system, rc6.d/S90reboot calls 'reboot -d
> >> -f
> >> i' and that works like I'd expect; the chroot is stopped and the system
> >> keeps on running.
> >> In the squeeze chroot we have rc6.d/K09reboot and the same 'reboot -d -f
> >> -i'.
> >>
> >> I will check if the -f does the trick but I still think the behaviour
> >> should be the same for both lenny and squeeze. I also think that the
> >> ability to reboot a system by rebooting a chrooted environment shouldn't
> >> be possible so the bug remains.
> >>
> >> According xen or kvm; eventually we will make that change of course, but
> >> at the moment that's not something we're focussing.
> >>
> >
> > Your script only calls all K* scripts (not S* scripts) when stop is
> > invoked.  Hence in the system where reboot is S90, it won't call it.
> > Where it's K09, it will be called.  I suspect if you rm K09reboot in
> > the squeeze chroot, it will fix the behaviour to what you want.
> >
> > As far as rebooting from inside a chroot rebooting the system I don;t
> > know whether that's a bug or not.  As far as I'm aware it has been the
> > way it's behaved for a long while...not sure what you can do to
> > prevent it even...
> 
> Ah, never occured to me that would be considered as normal behaviour. To
> be honest, I still think it shouldn't be possible but I don't want to
> start a religious fight about that.

There is no fight about this, you're just expecting too much from the
wrong tool. What you want is simply not chroot, but containers, such as
openvz, vserver or lxc.

Mike



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

Re: hardening-wrapper and debug symbols

[Julien Cristau]

On Fri, 2009-10-23 at 15:27 +0300, Peter Eisentraut wrote:
> I found out the hard way that when a package is built with
> hardening-wrapper, then debugging it with gdb results in seriously
> suboptimal backtraces like this:
> 
> #0  0xb7d01424 in __kernel_vsyscall ()
> #1  0xb7816d11 in ?? ()
> #2  0xb7e973a2 in ?? ()
> #3  0xb7e9784b in ?? ()
> #4  0xb7f1c8fd in ?? ()
> #5  0xb7eeae1b in ?? ()
> #6  0xb7eebee7 in ?? ()
> #7  0xb7e998d9 in ?? ()
> #8  0xb774a7a5 in ?? ()
> #9  0xb7d73011 in ?? ()
> 
> whether or not I have the -dbg package installed.  If I rebuild the
> package without hardening-wrapper, I get a normal backtrace (with more
> or less information, depending on whether the -dbg package is
> installed).

This is probably #346409.

Cheers,
Julien


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

hardening-wrapper and debug symbols

[Peter Eisentraut]

I found out the hard way that when a package is built with
hardening-wrapper, then debugging it with gdb results in seriously
suboptimal backtraces like this:

#0  0xb7d01424 in __kernel_vsyscall ()
#1  0xb7816d11 in ?? ()
#2  0xb7e973a2 in ?? ()
#3  0xb7e9784b in ?? ()
#4  0xb7f1c8fd in ?? ()
#5  0xb7eeae1b in ?? ()
#6  0xb7eebee7 in ?? ()
#7  0xb7e998d9 in ?? ()
#8  0xb774a7a5 in ?? ()
#9  0xb7d73011 in ?? ()

whether or not I have the -dbg package installed.  If I rebuild the
package without hardening-wrapper, I get a normal backtrace (with more
or less information, depending on whether the -dbg package is
installed).

First of all, is this normal?  Is there anything that can be done about
it?  The http://wiki.debian.org/Hardening page doesn't appear to cover
it.

Since debug packages and hardening-wrapper are both spreading in an
ad-hoc way across packages, it appears that we'll end up with a rather
nonuniform collection of packages that sometimes can be debugged,
sometimes can be debugged a little bit, and sometimes cannot be debugged
at all.

Also, hardening-wrapper describes itself as "experimental" and "for
build testing".  Is it appropriate for large-scale use in mainstream
packages intended for release?


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

ITP: jclicmoodle -- JClic module for Moodle

[Robert Millan]

Package: wnpp
Owner: Robert Millan 
Severity: wishlist

* Package name: jclicmoodle
  Version : 0.1.0.8
  Upstream Author : Sara Arjona Téllez
* URL : http://projectes.lafarga.cat/projects/jclicmoodle
* License : GPL
  Programming Lang: PHP
  Description : JClic module for Moodle

 Activity module for Moodle that allows the use JClic applets as a new
 type of resource in courses. The module collects and shows the results
 of the activities done by the students.


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

Bug#551992: general: stopping squeeze chroot shuts system

[martin]

>> In a lenny chroot, on the same system, rc6.d/S90reboot calls 'reboot -d
>> -f
>> i' and that works like I'd expect; the chroot is stopped and the system
>> keeps on running.
>> In the squeeze chroot we have rc6.d/K09reboot and the same 'reboot -d -f
>> -i'.
>>
>> I will check if the -f does the trick but I still think the behaviour
>> should be the same for both lenny and squeeze. I also think that the
>> ability to reboot a system by rebooting a chrooted environment shouldn't
>> be possible so the bug remains.
>>
>> According xen or kvm; eventually we will make that change of course, but
>> at the moment that's not something we're focussing.
>>
>
> Your script only calls all K* scripts (not S* scripts) when stop is
> invoked.  Hence in the system where reboot is S90, it won't call it.
> Where it's K09, it will be called.  I suspect if you rm K09reboot in
> the squeeze chroot, it will fix the behaviour to what you want.
>
> As far as rebooting from inside a chroot rebooting the system I don;t
> know whether that's a bug or not.  As far as I'm aware it has been the
> way it's behaved for a long while...not sure what you can do to
> prevent it even...

Ah, never occured to me that would be considered as normal behaviour. To
be honest, I still think it shouldn't be possible but I don't want to
start a religious fight about that.
I was so worried by the (for me) spontanious reboot I didn't check as
carefully as I should have. My bad.

Thanks for all the fast responses and sorry for my ignorance.
Martin




>
> --
> Stephen Stafford
>
>





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

Bug#551992: general: stopping squeeze chroot shuts system

[Stephen Stafford]

> In a lenny chroot, on the same system, rc6.d/S90reboot calls 'reboot -d -f
> i' and that works like I'd expect; the chroot is stopped and the system
> keeps on running.
> In the squeeze chroot we have rc6.d/K09reboot and the same 'reboot -d -f -i'.
>
> I will check if the -f does the trick but I still think the behaviour
> should be the same for both lenny and squeeze. I also think that the
> ability to reboot a system by rebooting a chrooted environment shouldn't
> be possible so the bug remains.
>
> According xen or kvm; eventually we will make that change of course, but
> at the moment that's not something we're focussing.
>

Your script only calls all K* scripts (not S* scripts) when stop is
invoked.  Hence in the system where reboot is S90, it won't call it.
Where it's K09, it will be called.  I suspect if you rm K09reboot in
the squeeze chroot, it will fix the behaviour to what you want.

As far as rebooting from inside a chroot rebooting the system I don;t
know whether that's a bug or not.  As far as I'm aware it has been the
way it's behaved for a long while...not sure what you can do to
prevent it even...

-- 
Stephen Stafford



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

plz add for link exch

[sahil dhall]

Bug#552081: ITP: python-pep8 -- A tool to check your Python code against some of the style conventions in PEP 8

[David Watson]

Package: wnpp
Severity: wishlist
Owner: David Watson 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: python-pep8
  Version : 0.3.1
  Upstream Author : Johann C. Rocholl 
* URL : http://pypi.python.org/pypi/pep8
* License : Expat
  Programming Lang: Python
  Description : A tool to check your Python code against some of the style 
conventions in PEP 8
 
Features:
 * Plugin architecture: Adding new checks is easy.
 * Parseable output: Jump to error location in your editor.
 * Small: Just one Python file, requires only stdlib. You can use just the 
pep8.py 
   file for this purpose

-- 
David Watson











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

Bug#551992: general: stopping squeeze chroot shuts system

[martin]

> /etc/rc6.d/S90reboot invokes  reboot -d -f -i.  The -f there means it
> goes straight to the kernel to reboot.
> Make that file empty (so it's treated as a conffile change) and you
> should be good.
> You might also want to consider using kvm or xen instead of raw chroots...
>

In a lenny chroot, on the same system, rc6.d/S90reboot calls 'reboot -d -f
i' and that works like I'd expect; the chroot is stopped and the system
keeps on running.
In the squeeze chroot we have rc6.d/K09reboot and the same 'reboot -d -f -i'.

I will check if the -f does the trick but I still think the behaviour
should be the same for both lenny and squeeze. I also think that the
ability to reboot a system by rebooting a chrooted environment shouldn't
be possible so the bug remains.

According xen or kvm; eventually we will make that change of course, but
at the moment that's not something we're focussing.

Regards,
Martin







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