Re: Is menu orphaned? (Was: Debian Menu transition status)

[Bill Allombert]

On Tue, Dec 04, 2007 at 07:48:22AM +0100, Andreas Tille wrote:
> >Anyway, if you have some cdd scripts that are broken by menu-2, please
> >send them to me and I am sure we will fix them in a short time.
> 
> Well, I'm sure that /usr/share/menu/cdd-menu (from cdd-common) can be
> fixed to cope with /usr/share/menu/amide (from amide) to create a valid
> menu.  The problem is that I'm missing a clear strategy in which way it
> should be fixed.  There are several possibilities.  The cdd-menu scripts
> concatenates single menu entries to build a user menu.  The concatenation
> only works if the input files have the same format.

Actually this is not true: You can just add 
!C menu-1
to the start of each files (or each menu-1 files if you prefer)
before concatening them.
Menu change format each time it see a !C request, even inside a file.

Cheers,
Bill.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#454359: ITP: processing -- spawning processes mimicking the threading module

[Sandro Tosi]

Hello Charles,

> since processing is also the name of a Java free software, I would
> recommend to name your package python-processing or something similar.
>
> http://www.processing.org/

Oh, sure, no problem; I've checked the archive for taht name, and find
noone, but only searched bin pkgs, not source too.

Thanks for your hint,
Sandro

-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Heimdal changes

[Gabor Gombas]

On Fri, Nov 30, 2007 at 03:48:19PM -0800, C.J. Adams-Collier wrote:

> > I modified my krb5.conf file so that heimdal stores its principals in an
> > LDAP data store.  A peculiarity of this configuration is that kadmind
> > expects the access control file to be named after the LDAP dn of the
> > principal container node and to be in the current directory:< >
> > [EMAIL PROTECTED]:~$ ls -l /etc/heimdal-kdc/*.acl
> > -rw-r--r-- 1 root root 156 Nov  8 18:00 /etc/heimdal-kdc/kadmind.acl
> > lrwxrwxrwx 1 root root  28 Nov  8 17:31
> > /etc/heimdal-kdc/ldap:ou=KerberosPrincipals,dc=cls2,dc=colliertech,dc=
> > org.acl -> /etc/heimdal-kdc/kadmind.acl
> > EOF
> >
> > In order to set $PWD to the correct value, inetd would need to call a
> > wrapper which does the chdir(2) and exec(3)

Is this still the case with Heimdal 1.0? If it is, I'd suggest reporting it
upstream. No daemon should depend on the current directory.

> > At this point, it seems that kadmind and kpasswd should be de-coupled
> > from kdc and moved into their own packages.  I can imagine many use
> > cases where administrators wouldn't feel comfortable opening a TCP port
> > for remote administration of kerberos principals, and "slave" servers
> > should not run kpasswd.  Allowing sysadmins to choose not to install the
> > daemons seems a useful feature.

Quite the contrary. You want everything installed on the slaves in case
the master dies and you have to do a failover. Maybe add a low-priority
debconf question whether this will be the master or a slave and
configure the kadmind/kpasswdd daemons appropriately.

> > Currently, all heimdal servers run as root.  Yipe.  We should probably
> > create a system user and group as well as an SELinux MAC policy.
> > This /is/ a network authentication infrastructure, after all.

IMHO if the KDC is compromised then whether the intruder gets root or
not is the least of your worries. You must assume that the complete
database was stolen and they're happily cracking the master key so you
must re-key every principal. Re-installing the KDC from scratch is about
half an hour (you do not run _anything_ else on it, right?),
re-generating and re-distributing the host keys and issuing new
passwords for users may take days or weeks depending on the number of
principals.

> > While going through all of this, I considered requirements to ease the
> > process of modifying the heimdal packages to configure the system to use
> > alternative principal sources.

What do you mean by that?

> > Is it possible to have one package query
> > another's entries in the database?  How about making modifications to
> > another's configuration?  In order to store to OpenLDAP, heimdal would
> > benefit from being able to discover some system settings:
> >
> > * the configured LDAP base DN

Which one? A single KDC instance can serve multiple realms using
multiple databases (well, you need some small patches for 0.7; they
should be included in 1.0 - I'll find out once I upgrade). Or different
kdc/kadmind/kpasswdd instances may run on the same machine bound to
different IP addresses.

> > * LDAP bind dn and password capable of creating the KerberosPrincipals
> > ou and a bind dn for the heimdal daemons' access to principals

Huh? You want to discover a _password_?!? If that password is stored
anywhere else than the kdc's configuration that would be quite a serious
misconfiguration...

> > Additionally, the package would need to cause some modifications
> > to /etc/default/slapd and /etc/ldap/slapd.conf, which are owned by the
> > slapd package.

That would be a very _BAD_ thing to do. Mucking with other packages'
config files only increases the possibility that something will go wrong
if the admin already did non-trivial modifications to those files.

> > If heimdal is configured to store principals to LDAP, removal of slapd
> > would break the system's kerberos settings, unless principals were
> > dumped to heimdal's native database and the /etc/krb5.conf were updated
> > to reflect the change.

Well, the UNIX philosophy is to let sysadmins shot themselves in the
foot if they want to. Do not employ clueless sysadmins.

> > I would like to see a simple set of regression tests run after
> > (re)configuration of slapd and heimdal packages.  This would ensure that
> > the heimdal user is able to access and modify principals.  There should
> > also be a rollback mechanism in case the regression tests fail.  I'd
> > hate to see an automated update cause a kerberos outage until a human
> > was able to fix the problem.

Automated update? On a KDC?!?! No way! An update can _ALWAYS_ go wrong
and can _ALWAYS_ cause breakage, so

- no sane man wants to do it on the master before being absolutely sure
  that it worked on a replica
- no sane man wants to do it at a time when there are no sysadmins near
  the console

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
   

Re: Proposalto introduce compiler options passed from dpkg-buildpackage

[Matthias Klose]

Frank Lichtenheld writes:
> On Tue, Dec 04, 2007 at 05:08:13PM +0100, Matthias Klose wrote:
> > We define a set of macros which are passed from dpkg-buildpackage to
> 
> If you say "macros" you mean the same as environment variables?

IIRC we cannot assume that debian/rules is a makefile and pass them as
macros directly, so we have to pass them as environment variables.

> [...]
> > === Alternate naming of the macros ===
> > 
> > Do omit the '''DEB_HOST_''' prefix and all packages should honour the
> > value of CFLAGS etc. in the environment. Many packages are likely to
> > do this by accident anyway. For packages that set CFLAGS etc., there
> > are basically two common cases:
> [...]
> > It has the disadvantage that these macros might be injected into the
> > build for some non-standard build systems.
> 
> If we would choose to use the common names without DEB_HOST_ prefix
> should dpkg-buildpackage then honor them if they are already set in
> the environment? Probably not as this seems error prone.

yes, that makes sense.

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposalto introduce compiler options passed from dpkg-buildpackage

[Manoj Srivastava]

On Wed, 5 Dec 2007 21:11:53 +0100, Matthias Klose <[EMAIL PROTECTED]> said: 

> Frank Lichtenheld writes:
>> On Tue, Dec 04, 2007 at 05:08:13PM +0100, Matthias Klose wrote:
>> > We define a set of macros which are passed from dpkg-buildpackage
>> > to
>> 
>> If you say "macros" you mean the same as environment variables?

> IIRC we cannot assume that debian/rules is a makefile and pass them as
> macros directly, so we have to pass them as environment variables.

I think you remember incorrectly. Policy currently states
--8<---cut here---start->8---

4.9. Main building script: `debian/rules'
-

 This file must be an executable makefile, and contains the
 package-specific recipes for compiling the package and building binary
 package(s) from the source.
--8<---cut here---end--->8---



Also, note that other parts of policy also refer to the rules
 being a makefile:
--8<---cut here---start->8---

4.6. Error trapping in makefiles


 When `make' invokes a command in a makefile (including your package's
 upstream makefiles and `debian/rules'), it does so using `sh'.  
  
--8<---cut here---end--->8---

So we can pass the macros directly on the command line, if you
 so desire.

manoj
-- 
You don't have to know how the computer works, just how to work the
computer.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#442008: Add /usr/local to $KDEDIRS

[Mathieu Bouchard]

I've been testing this for a couple of months and didn't found any problems on 
my configuration.

But since no other user asked for this for years and KDE3 will be replace in 
the near future by KDE4 (i hope), I don't know if it is worth to (maybe) 
break some configurations.

And normally, users should install kde applications in the kde prefix or in 
their local directory.
-- 
Mathieu Bouchard
Centre de bio-informatique (www.bioinfo.ulaval.ca)
Université Laval (Québec, Canada)

Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html


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

Re: ITP: crunchy -- Delivers html-written python tutorials in a browser window, adding interactive elements

[Hendrik Sattler]

Am Mittwoch 05 Dezember 2007 schrieb Ryan Kavanagh:
> Package: wnpp
> Severity: wishlist
> Owner: Ryan Kavanagh <[EMAIL PROTECTED]>
>
> * Package name: crunchy
>   Version : 0.9.8.3
>   Upstream Author : André Roberge <[EMAIL PROTECTED]>, Johannes
>   Woolard 
> * URL : http://crunchy.sourceforge.net
> * License : MIT
>   Programming Lang: Python
>   Description : Delivers html-written python tutorials in a browser
> window, adding interactive elements

too long

> Crunchy is an application that formats and delivers html-written Python
> tutorials inside a browser window, adding interactive elements and snazzy
> navigation. Crunchy exists to transform static html tutorials into exciting
> interactive applications: It can insert a whole range of interactive
> elements into web pages, including Python interpreters, code editors with
> Python source highlighting and graphics canvasses.

That says what it does but not what it is. What kind of application?
"Delivers [...] inside a browser window" doesn't make any sense to me. Does it 
generate HTML formatted output files or is it a webserver or a browser plugin 
or...?

HS

Re: Bug#454359: ITP: processing -- spawning processes mimicking the threading module

[Charles Plessy]

Le Wed, Dec 05, 2007 at 12:40:13AM +0100, Sandro Tosi a écrit :
> Package: wnpp
> Severity: wishlist
> Owner: Sandro Tosi <[EMAIL PROTECTED]>
> 
> * Package name: processing
>   Version : 0.39
>   Upstream Author : R Oudkerk 
> * URL : http://pypi.python.org/pypi/processing/
> * License : BSD
>   Programming Lang: Python
>   Description : spawning processes mimicking the threading module

Dear Sandro,

since processing is also the name of a Java free software, I would
recommend to name your package python-processing or something similar.

http://www.processing.org/

Have a nice day,

-- 
Charles Plessy
http://charles.plessy.org
Wakō, Saitama, Japan


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Is menu orphaned? (Was: Debian Menu transition status)

[Andreas Tille]

On Wed, 5 Dec 2007, Bill Allombert wrote:


Actually this is not true: You can just add
!C menu-1
to the start of each files (or each menu-1 files if you prefer)
before concatening them.
Menu change format each time it see a !C request, even inside a file.


OK, this hint (is it documented somewhere?) would probably help
to fix cdd-common easily.  But my question regarding the general
menu strategy obviousely remains.

Kind regards

Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Is menu orphaned?

[Andreas Tille]

On Tue, 4 Dec 2007, Manoj Srivastava wrote:


   When there is consensus, and the practice follows the consensus,
then we write it into policy.  Just a bunch of us munchkins agreeing on
a mailing list somewhere (consensus) is not, in my opinion, enough:
existing practice must shift.   There are exceptions to this policy
change rule, but I have not, sofar, seen any compelling arguments to
warrant departing from the "policy defines existing standard behaviour"
rule so far.


I completely agree here.
That's why I started some action (I agree that changing the policy
would be one of the last steps) regarding informing people about the
new format.  It seems that my logic was wrong that format-2 would
be the successor of format-1 (which in my opinion would be a
normal thing if numbers increase) because I had the feeling that
former and current menu maintainer failed completely in communicating
their work regarding a new format.

Currently I desperately hope for a reasonable explanation of the
sense of two coexisting formats when there is no but a cosmetic
advantage of one over the other.  IMHO two formats with
nearly no difference just cause trouble.  I'm waiting for a
statement of the maintainer that says: "Lets drop one of them"
(I personally do not care which one) or "we really need both
formats for this or that reason" (and thus have to cope with the
extra work that might occure from this decision).

I personally could cope with any decision that is undermined
by a clear reasoning - but any decision has to be done.

Kind regards

  Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposalto introduce compiler options passed from dpkg-buildpackage

[Russ Allbery]

Lars Wirzenius <[EMAIL PROTECTED]> writes:

> The two packages in question are leave and webserver-package, and as it
> turns out, the latter is a false positive, since my grepping for
> debian/rules found a file that wasn't a real debian/rules file. So, only
> one package in etch/main uses something not a makefile for debian/rules.

http://lintian.debian.org/reports/Tdebian-rules-not-a-makefile.html

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#454469: ITP: lrslib -- enumerate vertices and extreme rays of a convex polyhedron

[David Bremner]

Package: wnpp
Severity: wishlist
Owner: David Bremner <[EMAIL PROTECTED]>


* Package name: lrslib
  Version : 4.2b
  Upstream Author : David Avis <[EMAIL PROTECTED]>
* URL : http://cgm.cs.mcgill.ca/~avis/C/lrs.html
* License : GPL 2+
  Programming Lang: C
  Description : Enumerate vertices and extreme rays of a convex polyhedron

A convex polyhedron is the set of points satisfying  a finite family of linear 
inequalities.  The study of the vertices and extreme rays of such systems is 
important 
and useful in e.g. mathematics and optimization.  In a dual interpretation, 
finding the 
vertices of a (bounded) polyhedron is equivalent to finding the convex hull 
(bounding 
inequalities) of an (arbitrary dimensional) set of points.  Lrs (lexicographic 
reverse search) 
has two important features that can be very important for certain applications: 
it works in exact 
arithmetic, and it consumes memory proportional to the input, no matter how 
large the 
output is.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)

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



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposalto introduce compiler options passed from dpkg-buildpackage

[Lars Wirzenius]

On ke, 2007-12-05 at 21:11 +0100, Matthias Klose wrote:
> IIRC we cannot assume that debian/rules is a makefile and pass them as
> macros directly, so we have to pass them as environment variables.

Debian Policy, 4.9, "Main building script: debian/rules":

This file must be an executable makefile

So I think we can assume things.

Since I happened to have the etch/main sources lying around unpacked on
a hard disk (don't ask), I ran a quick scan for the first lines of
debian/rules files:

  1 #! /bin/sh
  1 #!/bin/sh -e
  1 #!/usr/bin/make -ef
403 #! /usr/bin/make -f
 13 #! /usr/bin/make -f 
  1 #!/usr/bin/make  -f 
   9876 #!/usr/bin/make -f
 17 #!/usr/bin/make -f 
  1 #!/usr/bin/make -f   
  4 #!/usr/bin/make -f 
  2 #!/usr/bin/make -f 
  1 #! /usr/bin/make -rf

That's two packages that use /bin/sh, everything else uses make.

The two packages in question are leave and webserver-package, and as it
turns out, the latter is a false positive, since my grepping for
debian/rules found a file that wasn't a real debian/rules file. So, only
one package in etch/main uses something not a makefile for debian/rules.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

ITP: crunchy -- Delivers html-written python tutorials in a browser window, adding interactive elements

[Ryan Kavanagh]

Package: wnpp
Severity: wishlist
Owner: Ryan Kavanagh <[EMAIL PROTECTED]>

* Package name: crunchy
  Version : 0.9.8.3
  Upstream Author : André Roberge <[EMAIL PROTECTED]>, Johannes
  Woolard 
* URL : http://crunchy.sourceforge.net
* License : MIT
  Programming Lang: Python
  Description : Delivers html-written python tutorials in a browser 
window, adding interactive elements


Crunchy is an application that formats and delivers html-written Python
tutorials inside a browser window, adding interactive elements and snazzy
navigation. Crunchy exists to transform static html tutorials into exciting
interactive applications: It can insert a whole range of interactive elements
into web pages, including Python interpreters, code editors with Python
source highlighting and graphics canvasses.


-- System Information:
Debian Release: lenny/sid
  APT prefers gutsy-updates
  APT policy: (500, 'gutsy-updates'), (500, 'gutsy-security'), (500, 'gutsy')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-14-generic (SMP w/1 CPU core)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
-- 
Ryan Kavanagh (ryanakca)
My GPG/PGP Key: E95EDDC9
http://blog.ryanak.ca


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

Bug#454477: ITP: nulog -- Graphical firewall log analysis interface

[Pierre Chifflier]

Package: wnpp
Severity: wishlist
Owner: Pierre Chifflier <[EMAIL PROTECTED]>

* Package name: nulog
  Version : 2.0
  Upstream Author : INL
* URL : http://software.inl.fr/trac/trac.cgi/wiki/EdenWall/NuLog2
* License : GPL
  Programming Lang: Python
  Description : Graphical firewall log analysis interface

 NuLog is a web interface to netfilter logs, when stored in a database
 using ulog.
 .
 The features currently include:
 o Index page with a summary of firewall activity:
 * Packet dropped per host
 * Packets dropped per UDP port
 * Packets dropped per TCP port
 * Packets dropped per user (NuFW only) 
 o Fully browsable tables
 o Search engine
 o Graphing capabilities (display clickable array, histogram or pie for a 
dataset)
 o SOAP request system for integration with other systems
 o IPv6 support.
 o Customizable pages (index page, etc)
 o AJAX features.
 o Special pages for user, ip and ports.
 o CSV export. 
 .
  Homepage: http://software.inl.fr/trac/trac.cgi/wiki/EdenWall/NuLog2

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.22-3-amd64 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ITP: crunchy -- Delivers html-written python tutorials in a browser window, adding interactive elements

[Ryan K.]

On Dec 5, 2007 5:51 PM, Hendrik Sattler <[EMAIL PROTECTED]> wrote:
> >   Description : Delivers html-written python tutorials in a browser
> > window, adding interactive elements
>
> too long
>
Yeah yeah, 60 chars, I know, It's just temporary, to be fixed /
improved / rewritten.
Just like the following paragraph is a copy paste from their website... to be
reformatted / etc.

> That says what it does but not what it is. What kind of application?(no l
> "Delivers [...] inside a browser window" doesn't make any sense to me. Does it
> generate HTML formatted output files or is it a webserver or a browser plugin
> or...?
To answer your question, it takes any python tutorial with code in a  tag
and replaces it with appropriate javascript, and permits you to modify it on the
page, and test it as you go, similar to the W3C's CSS school[1]
So, it generates
HTML formatted output files.  It also acts as a web server and is
usually started
manually, instead of as a daemon. It has three security levels, the
default being
rather secure. For more info, download the tarball,
'cd crunchy/ && python crunchy.py' :o)

>
> HS
>

Hope this answers your questions,
Ryan

[1] http://www.w3schools.com/css/default.asp

-- 
Ryan K. (ryanakca)
Get my public key: http://blog.ryanak.ca/E95EDDC9.gpg


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]