Re: dh_installinit

[Manoj Srivastava]

On Sat, 10 Nov 2007 23:45:01 -0800, Russ Allbery <[EMAIL PROTECTED]> said: 

> Manoj Srivastava <[EMAIL PROTECTED]> writes:


>> Wearing my SELinux hat on, I find that daemons not closing file
>> descriptors when forking children result in a large number of AVC
>> denied messages. Of course, sometimes there are legitimate reasons
>> for not closing the descriptors (and these use cases can then be
>> explicitly allowed in the security policy).  Most cases, though, it
>> seems like the authors are just being lazy.

> From a security standpoint, isn't it clearly better to manage the file
> descriptors before invoking the daemon rather than just handing them
> all off to the daemon and trusting the daemon to close them?

I would agree that no entity should be passing open file
 descriptors off to other processes unless this is  deliberate, and in
 that case a proper policy has been written for it.

> Insofar as there is any security impact here (which is dubious in most
> cases),

Why do you say that? If a process acquires a file handle on a
 privileged file while running as dpkg_t; and passes it to debconf
 running as debconf_t; why is there no security impact? dpkg_t might
 have more access than debconf_t in the policy being run.

> I'd say that passing the open debconf file descriptor to the
> daemon is wrong regardless of whether the daemon closes it or not.

Yes.

manoj
-- 
QOTD: "I thought I saw a unicorn on the way over, but it was just a
horse with one of the horns broken off."
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]

Re: RFC: cups as "default" printing system for lenny?

[Bernd Zeimetz]

Russ Allbery wrote:
> Bernd Zeimetz <[EMAIL PROTECTED]> writes:
> 
>> Not sure if anybody is still using the old BSD printing stuff - at least
>> I can't see any reason why it should have a higher priority than
>> optional.
> 
> I am.  It's simple and it works, and CUPS seems ridiculously bloated for
> the only printing need I have (printing PostScript files to a network
> printer).

In theory that's all I need, too - and our printers support it. But they
also support to print from 6 different trays and a _lot_ of other
settings - and that's the point where you need a ppd file. Luckily OSX
uses cups, too, so often you're able to get good ppds from the producer,
at least for the more expensive models. Using them was very painless so
far - it just works.


-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


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

Re: RFC: cups as "default" printing system for lenny?

[Bernd Zeimetz]

Manoj Srivastava wrote:

> 
> Way back when, “standard” was defined as  stuff that an old UNIX
>  hand would say “WTF happened to that?” if it is not present on a
>  default install. While I am unsure of this definition of standard still
>  holds, but as an old UNIX hand I can say that if I am on a UNIX like
>  machine, and I can't just say lpr foo.txt and have it printed on the
>  default printer, I would find the system deficient and un-UNIX like.

That works well with cups if you have the cupsys-bsd package installed.


-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


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

Re: dh_installinit

[Vincent Danjean]

Manoj Srivastava wrote:
> On Sat, 10 Nov 2007 23:45:01 -0800, Russ Allbery <[EMAIL PROTECTED]> said: 
>> I'd say that passing the open debconf file descriptor to the
>> daemon is wrong regardless of whether the daemon closes it or not.
> 
> Yes.

I agree, too. If I remember correctly, there has been discussion in libc and/or
kernel to be able to open files with random high-numbered file descriptors. When
these mechanisms will be ready, a deamon will be unable to close all its file
descriptors (unless it closes the whole range of fd (0--2^16 ?) or unless an
application can get a list of its open fds).

  Vincent


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

Packaging: handling "private" libraries

[David Paleino]

Hi all,
I've already posted this question to my team's mailing list (debian-med), to
mentors and, since I received no answer, here it is "the last shore": here.

I'm working on the packaging of bioimagesuite [1], and upstream carries lots of
libraries. I've added dependencies on existing packages where possible, but the
upstream source also carries some "customized" libraries which aren't available
elsewhere on the net.

Here's the problem: dpkg-shlibdeps fails:

dpkg-shlibdeps: failure: couldn't find library libvtkpxRegistrationTCL.so
(note: only packages with 'shlibs' files are looked into).

I don't know how to handle this, since the library it refers to is
"internal" or "private" to the package.

I hope someone could help me.

Kindly,
David

[1] http://www.bioimagesuite.org

-- 
 . ''`.  Debian maintainer | http://snipurl.com/qa_page/
 : :'  :  Linuxer #334216  |  http://www.hanskalabs.net/
 `. `'`GPG: 1392B174   | http://www.debianizzati.org/
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: Packaging: handling "private" libraries

[Andreas Tille]

On Sun, 11 Nov 2007, David Paleino wrote:


I hope someone could help me.


I would like to try, but I'm a little bit bored by upstream that seems
to require a registration to download GPLed software.  Could you please
upload your stuff to mentors.debian.net?  (I have seen your packaging
stuff in debian-med SVN, but obtaining the orig.tar.gz in an easy way
would be great.)

Kind regards

  Andreas.

--
http://fam-tille.de


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

Re: ries.debian.org AKA ftp-master.debian.org - hardware problems

[Florian Weimer]

* Joerg Jaspert:

> you may have noticed that around yesterday evening (UTC) ries.debian.org
> AKA ftp-master.debian.org has problems. The exact cause and possible
> solutions for this are currently investigated by the admins, a first
> problem guess is "troubles with the harddiscs".

It seems that incoming.debian.org is up again, and the FTP server is
running, too.  Is it safe to upload packages?


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

Re: Opinions sought: mlocate appropriate for Priority: standard?

[Adeodato Simó]

* Joey Hess [Sat, 10 Nov 2007 11:47:40 -0500]:

> Josh Triplett wrote:
> > Thus, I would argue that:

> > * No locate should have standard priority as long as findutils
> >   contains locate.
> > * locate should move out of findutils into a separate package.
> > * Once that happens, if any locate should have priority standard,
> >   mlocate should.
> > * However, I don't think any locate should have priority standard.

> Agreed to all points, except I do think some locate should probably be
> standard priority. But not required or essential. It's easy enough to
> skip priority standard stuff if it's not wanted. 

Okay, thanks. Andreas, how does the idea of splitting locate/updatedb
out from findutils sound to you, to follow the above plan? (dlocate can
Depend: on locate | findutils (<= 4.3.8-X) then.)

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
I try to keep an open mind, but not so open that my brains fall out.


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

Re: ries.debian.org AKA ftp-master.debian.org - hardware problems

[Nico Golde]

Hi Florian,
* Florian Weimer <[EMAIL PROTECTED]> [2007-11-11 12:11]:
> * Joerg Jaspert:
> 
> > you may have noticed that around yesterday evening (UTC) ries.debian.org
> > AKA ftp-master.debian.org has problems. The exact cause and possible
> > solutions for this are currently investigated by the admins, a first
> > problem guess is "troubles with the harddiscs".
> 
> It seems that incoming.debian.org is up again, and the FTP server is
> running, too.  Is it safe to upload packages?

Referring to the topic in #debian-devel it's not:
"HALF-BROKEN: ries (aka ftp-master) being recovered, might 
return to normality in 12h or 24h; uploads being accepted 
but not yet processed"

Kind regards
Nico
-- 
Nico Golde - http://www.ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.


pgpoQhyXu9CxV.pgp
Description: PGP signature

Re: LSB-ize daemon without pidfile handling

[Marc Haber]

On Sat, 10 Nov 2007 17:01:38 +0100, Wouter Verhelst
<[EMAIL PROTECTED]> wrote:
>On Fri, Nov 09, 2007 at 10:24:46PM +0100, Adeodato Simó wrote:
>> Well, it's obvious it's the best approach if you're willing to do it. ;-)
>
>It's three lines of code to write a PID file, and it's the best approach
>to make sure you don't break stuff.

How many seconds until the "please make pidfile location configurable"
wishlist bug?

>> As a Debian packager, though, I would most likely just trust the authors
>> of start-stop-daemon and its --make-pidfile.
>
>--make-pidfile, --exec, and friends, are all ugly workarounds for buggy
>daemons that can't write a pidfile.

And I think that it is less broken to use them than to patch
third-party software.

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

Re: LSB-ize daemon without pidfile handling

[Marc Haber]

On Sat, 10 Nov 2007 17:00:13 +0100, Wouter Verhelst
<[EMAIL PROTECTED]> wrote:
>That is one way to look at it. The other way would be that these are
>just three lines of "code" being duplicated here, and that start_daemon
>is just a convenience function, nothing more.

So, start_daemon is not part of the standard?

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

Re: LSB-ize daemon without pidfile handling

[Stephen Gran]

This one time, at band camp, Marc Haber said:
> On Sat, 10 Nov 2007 17:01:38 +0100, Wouter Verhelst
> <[EMAIL PROTECTED]> wrote:
> >On Fri, Nov 09, 2007 at 10:24:46PM +0100, Adeodato Simó wrote:
> >> Well, it's obvious it's the best approach if you're willing to do it. ;-)
> >
> >It's three lines of code to write a PID file, and it's the best approach
> >to make sure you don't break stuff.
> 
> How many seconds until the "please make pidfile location configurable"
> wishlist bug?

Which is another, what, 5-10 lines of code?

> >> As a Debian packager, though, I would most likely just trust the authors
> >> of start-stop-daemon and its --make-pidfile.
> >
> >--make-pidfile, --exec, and friends, are all ugly workarounds for buggy
> >daemons that can't write a pidfile.
> 
> And I think that it is less broken to use them than to patch
> third-party software.

Patching third-party software is the majority of what we do.  Why is
this a problem?
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: buildds: "Authentication warning overridden."

[Florian Weimer]

* Michael Banck:

> Assuming that compromised mirrors get quickly identified by people using
> signatures, and buildd packages having to be uploaded directly, the
> amount of compromised packages this way is probably small, so they can
> be rebuilt using packages from another mirror, after the build logs have
> been inspected to see whether compromised packages have indeed been
> used.

I think it's possible to detect on the mirror side if the downloader is
going to verify any signatures. So it's possible to avoid the kind of
detection we get for free.


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

Re: buildds: "Authentication warning overridden."

[Florian Weimer]

* Wouter Verhelst:

> That's inevitable because http://incoming.debian.org is not signed; The
> update frequency of that repository (which is available only to buildd
> hosts by IP and/or password protection) makes that impossible -- or at
> least that's what I understood; you may want to check with ftp-masters
> for the full story.

In this case, HTTPS should be used to download the packages, together
with proper certificate validation.  This has got the added benefit that
passwords aren't sent in the clear (well, unless an error occurs, but
this is a separate issue).


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

Re: Long-term mass bug filing for crossbuild support

[Neil Williams]

On Sun, 11 Nov 2007 00:19:41 +0100
Hendrik Sattler <[EMAIL PROTECTED]> wrote:

> Am Samstag 10 November 2007 schrieb Neil Williams:
> > emdebian-tools will support any build system that can be used in
> > debian/rules. The build system should configure itself using only the
> > data provided by dpkg-architecture but can use that information in
> > whatever manner is needed to get the right values into the right
> > variables.
> 
> How do you determine the root dir of the target? 

? What do you mean ? / is /

'target' is a misleading term in cross compiling - it is probably best
to reserve the keyword 'target' as referring solely to the TARGET
variable specified to gcc when building the cross compiler. 'target' in
that context, has no specific meaning during the cross build itself.

Emebian uses the terminology:
--build == Big or Desktop (Build or builD) depending on your point of
view.
--host == handheld 

Emdebian supports amd64, i386 and powerpc as --build. My primary --host
is ARM but others are working on other objectives, like mips, and
other architectures are supported.

The cross built package will install into /usr/ just as before because
it is expected to be installed on the host device where / is correct.

When using dpkg-cross, the library is rebuilt to install into:
/usr/$triplet/lib/
and -dev packages into:
/usr/$triplet/include/
where 
$triplet = `dpkg-architecture -qDEB_HOST_GNU_TYPE`

When dpkg-buildpackage is called with the --arch option,
dpkg-architecture is called to set the appropriate values.

That makes the --host libfoo.so available to the cross compiler running
on the --build by a mechanism of paths and symlinks. It is this support
that is being rewritten during the migration of dpkg-cross back into
dpkg. This /usr/$triplet/ is only used to provide the shared objects
during the cross build - the final package looks in /usr/lib/ when
loading the dynamic links at runtime.

Currently, 'dpkg-buildpackage -a' is not fully functional. Emdebian
uses wrapper code in 'emdebuild' that implements a temporary solution
until bug 439979 is closed.

> It's likely not / so it can 
> be about anywhere in the tree. Or does the build happens in a chroot 
> automatically.

Please read http://www.emdebian.org/ and then transfer this thread to
[EMAIL PROTECTED]

> How and which environment variables are set to which values?
> "man dpkg-buildpackage" doesn't tell anything about those.

man dpkg-architecture

-- 

Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


pgpmnWxjiUcP2.pgp
Description: PGP signature

Watching mentors and nifticlib

[Andreas Tille]

Hello,

as you know we have several people who maintain Debian-Med relevant
packages but are no official DDs and thus needs sponsoring.  Today
I stumpled over a new version of nifticlib that would close the
show stopper bug which keeps the current version out of testing -
so we might be interested to get this uploaded soon. This fact
brought up several issues to discuss:

  1. Would it be interesting to get mentors included into our
 web-sentinel David is continuousely busy to enhance.  We
 could parse mentors whether there are packages hanging around
 that are mentioned in our tasks packages.

  2. What is the general procedure for sponsoring those packages?
 I was not able to find any information whether Michael has
 "his favourite sponsor".  Well I guess Michael is basically
 interested in getting his stuff uploaded soon and thus he will
 probably not really care who is just uploading but the fact
 that he did not announced a request for sponsoring here is
 a sign that he is not really seeking a sponsor and my guess
 is that the delay in the upload is just caused by the problems
 of ftp-master.

 But besides these assumptions I wonder how we could keep track
 of the sponsoring procedure.  I would love if we would have some
 control who sponsored a package to cause some action in case
 this sponsor is say on vacation or what else.  What do you
 think about this.

BTW, Michael, what do you think about pushing your packaging stuff
of nifticlib into our Debian-Med SVN?

Kind regards

  Andreas.

--
http://fam-tille.de


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

Re: Opinions sought: mlocate appropriate for Priority: standard?

[Andreas Metzler]

Adeodato Simó <[EMAIL PROTECTED]> wrote:
[...]
> Okay, thanks. Andreas, how does the idea of splitting locate/updatedb
> out from findutils sound to you, to follow the above plan? (dlocate can
> Depend: on locate | findutils (<= 4.3.8-X) then.)

If we have got (at least temporarily) three locate packages in Debian
we probably need to switch to alternatives. (Currently slocate uses
dpkg-divert.)
cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


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

Re: Watching mentors and nifticlib

[Michael Hanke]

Hi,

[ not sure whether the original post should have been posted to
debian-med instead of debian-devel. CC'ing it for now, but I guess we
should move there... ]

On Sun, Nov 11, 2007 at 02:10:35PM +0100, Andreas Tille wrote:
> Hello,
>
> as you know we have several people who maintain Debian-Med relevant
> packages but are no official DDs and thus needs sponsoring.  Today
> I stumpled over a new version of nifticlib that would close the
> show stopper bug which keeps the current version out of testing -
> so we might be interested to get this uploaded soon. This fact
> brought up several issues to discuss:
>
>   1. Would it be interesting to get mentors included into our
>  web-sentinel David is continuousely busy to enhance.  We
>  could parse mentors whether there are packages hanging around
>  that are mentioned in our tasks packages.
I like the idea, but it would only help solving the problem, if there
are actually some DDs reading it and acting accordingly.

>   2. What is the general procedure for sponsoring those packages?
>  I was not able to find any information whether Michael has
>  "his favourite sponsor".  Well I guess Michael is basically
>  interested in getting his stuff uploaded soon and thus he will
>  probably not really care who is just uploading but the fact
>  that he did not announced a request for sponsoring here is
>  a sign that he is not really seeking a sponsor and my guess
>  is that the delay in the upload is just caused by the problems
>  of ftp-master.
Indeed, I have a very reliable sponsor. In fact he is more than a
sponsor and (at least to some degree) we group-maintain all of 'my'
packages.

In general I think that packages should not be uploaded without a formal
request. Some people (including me) use mentors.d.n. to provide
unfinished packages for sponsors and beta-tester. Having such a package
uploaded could introduce unecessary, because already known, bugs to
Debian unstable.

>  But besides these assumptions I wonder how we could keep track
>  of the sponsoring procedure.  I would love if we would have some
>  control who sponsored a package to cause some action in case
>  this sponsor is say on vacation or what else.  What do you
>  think about this.
>
> BTW, Michael, what do you think about pushing your packaging stuff
> of nifticlib into our Debian-Med SVN?
We switched to Git some time ago and all my packages are available from
git.debian.org. The control files should list the corresponding
repository. If one package is not there (yet), it is because no
upload/update was necessary since I started moving. The next upload will
make the package repository available as well.

Because I use Git + git-buildpackage and a repository layout different
from the debian-med SVN I don't want to push things to it. But given the
distributed nature of Git, it should be equally easy to get the package
sources and provide patches for it.

Cheers,

Michael


-- 
GPG key:  1024D/3144BE0F Michael Hanke
http://apsy.gse.uni-magdeburg.de/hanke
ICQ: 48230050


signature.asc
Description: Digital signature

Re: Opinions sought: mlocate appropriate for Priority: standard?

[Adeodato Simó]

* Andreas Metzler [Sun, 11 Nov 2007 14:08:50 +0100]:

> If we have got (at least temporarily) three locate packages in Debian
> we probably need to switch to alternatives. (Currently slocate uses
> dpkg-divert.)

Yes, though the slocate maintainer scripts scare the hell out of me, and
ISTR that the maintainer is somewhat MIA. Shall we make coordinated
uploads of your locate and mine, and propose a patch to slocate? (I can
prepare it, my fears notwithstanding.) I guess dlocate would need an
upload as well.

How to handle the cron.daily script, though?

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
Mankind are very odd creatures: one half censure what they practice, the
other half practice what they censure; the rest always say and do as
they ought.
-- Michel de Montaigne


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

Re: Watching mentors and nifticlib

[Adeodato Simó]

Was this mail meant to be sent to [EMAIL PROTECTED] instead of -devel?

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
There is no man so good who, were he to submit all his thoughts to the
laws, would not deserve hanging ten times in his life.
-- Michel de Montaigne


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

Re: Packaging: handling "private" libraries

[David Paleino]

Il giorno Sun, 11 Nov 2007 11:58:27 +0100 (CET)
Andreas Tille <[EMAIL PROTECTED]> ha scritto:

> On Sun, 11 Nov 2007, David Paleino wrote:
> 
> > I hope someone could help me.
> 
> I would like to try, but I'm a little bit bored by upstream that seems
> to require a registration to download GPLed software.

Yes, that's weird to me too.

> Could you please upload your stuff to mentors.debian.net?

Upstream is 37Mb, won't upload it ;)

> (I have seen your packaging stuff in debian-med SVN, but obtaining the
> orig.tar.gz in an easy way would be great.)

I've added a "get-orig-source" target to debian/rules to get it.

Be careful that bioimagesuite_latest* would need bioimagesuite_extra* (to be
downloaded from the same website): this latter package merely contains the lib*
packages bioimagesuite already depends on (vtk-tcl, ...)

Moreover, you just get the original tarball. Renaming
to package_version.orig.tar.gz is still a manual thing (the upstream tarball
doesn't contain the version).

Kindly,
David

-- 
 . ''`.  Debian maintainer | http://snipurl.com/qa_page/
 : :'  :  Linuxer #334216  |  http://www.hanskalabs.net/
 `. `'`GPG: 1392B174   | http://www.debianizzati.org/
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: Watching mentors and nifticlib

[Andreas Tille]

On Sun, 11 Nov 2007, Michael Hanke wrote:


[ not sure whether the original post should have been posted to
debian-med instead of debian-devel. CC'ing it for now, but I guess we
should move there... ]


The posting was intended to Debian-Med list, because we try to enhance the
observation of packages that are interesting for this CDD.  The techniques
should be made available for other CDDs as well in case we consider the
stuff as useful - perhaps it is pure discussion.


I like the idea, but it would only help solving the problem, if there
are actually some DDs reading it and acting accordingly.


Sure. The sentinel we are building for Debian-Med relevant packages
is infact meant to be read by Debian-Med interested developers - that's
the reason we are developing it. ;-)
This is the explanation why I posted it on Debian-Med because we are
focussing on a subset of packages to pick out the relevant packages
from mentors.  A posting on debian-devel would have been apropriate
if I would have had a suggestion to make an enhancement for general
enhancing handling packages on mentors - which I just have no idea about.


Indeed, I have a very reliable sponsor. In fact he is more than a
sponsor and (at least to some degree) we group-maintain all of 'my'
packages.


Great.


In general I think that packages should not be uploaded without a formal
request. Some people (including me) use mentors.d.n. to provide
unfinished packages for sponsors and beta-tester. Having such a package
uploaded could introduce unecessary, because already known, bugs to
Debian unstable.


Yes, this is exactly the reason why I did not even downloaded your package
from mentors - because I expect you to have a sponsor if you don't ask
explicitely for sponsoring.  The problem is, that I have no chance to
*verify* that there is a sponsor working on this.  That's why my idea
was to list the sponsor in addition to the maintainer in the task
file to enable others to ping the sponsor if needed.


BTW, Michael, what do you think about pushing your packaging stuff
of nifticlib into our Debian-Med SVN?

We switched to Git some time ago and all my packages are available from
git.debian.org. The control files should list the corresponding
repository. If one package is not there (yet), it is because no
upload/update was necessary since I started moving. The next upload will
make the package repository available as well.


I admit that I have the strange feeling that the pure existence of several
different repository management systems makes the world a worse place than
the existance of different editors (emacs/vim/...) or desktop environments
(Gnome/KDE/...).  The later ones are pure personal decisions but different
repository systems that are intended to let different people work together
fail in doing so because different people tend to have different habits.
So even if I would adopt your preference of git over say svn and would move
my packages to git other DDs prefere something else and we will finally
not be able to have a common repository of the Debian-Med stuff for
instance.  I admit this is really disgusting.


Because I use Git + git-buildpackage and a repository layout different
from the debian-med SVN I don't want to push things to it. But given the
distributed nature of Git, it should be equally easy to get the package
sources and provide patches for it.


Well, the idea was to form a group maintaining Debian-Med relevant stuff
in one repositore.  This does not mean I would try to convince you to
drop git and switch to svn.  This is rather a cry for help to find a
way to easily enable every interested person easily to cope with changes
in packaging stuff od Debian-Med packages.  David has written a great
tool that lists SVN commits:
   http://debian-med.alioth.debian.org/
but all changes outside SVN slip through this.  Do you see any chance
to cover "everybody pet repository" which this kind of tool?

Kind regards

   Andreas.

--
http://fam-tille.de


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

Re: Opinions sought: mlocate appropriate for Priority: standard?

[Andreas Metzler]

Adeodato Simó <[EMAIL PROTECTED]> wrote:
> * Andreas Metzler [Sun, 11 Nov 2007 14:08:50 +0100]:
>> we probably need to switch to alternatives. (Currently slocate uses
>> dpkg-divert.)

> Yes, though the slocate maintainer scripts scare the hell out of me, and
> ISTR that the maintainer is somewhat MIA. Shall we make coordinated
> uploads of your locate and mine, and propose a patch to slocate? (I can
> prepare it, my fears notwithstanding.)

I guess it would need happen like this:

1. upload findutils with splitoff locate to experimental. The locate
package (Is this name ok?) ships /usr/bin/locate.findutils and
/usr/bin/updatedb.findutils. It installs low-priority alterntives for
these. The package conflicts with slocate (<< the next version, i.e.
3.1-1.2). It conflicts/replaces findutils (<=4.3.8-1, which is the
last vesion living in experimental.)

> I guess dlocate would need an
> upload as well.

> How to handle the cron.daily script, though?

--- find-cron.daily (Revision 220)
+++ find-cron.daily (Arbeitskopie)
@@ -5,6 +5,7 @@
 # Written by Ian A. Murdock <[EMAIL PROTECTED]> and
 #Kevin Dalley <[EMAIL PROTECTED]>

+[ -e /usr/bin/updatedb.findutils ] || exit 0
 LOCALUSER="nobody"
 export LOCALUSER
 if [ -f /etc/updatedb.conf ]; then
@@ -12,7 +13,7 @@
 fi

 if getent passwd $LOCALUSER > /dev/null ; then
-  cd / && nice -n ${NICE:-10} updatedb 2>/dev/null
+  cd / && nice -n ${NICE:-10} updatedb.findutils 2>/dev/null

cu andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


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

Re: Watching mentors and nifticlib

[David Paleino]

Il giorno Sun, 11 Nov 2007 16:13:09 +0100 (CET)
Andreas Tille <[EMAIL PROTECTED]> ha scritto:

> 
> ...
> 
> > Because I use Git + git-buildpackage and a repository layout different
> > from the debian-med SVN I don't want to push things to it. But given the
> > distributed nature of Git, it should be equally easy to get the package
> > sources and provide patches for it.
> 
> Well, the idea was to form a group maintaining Debian-Med relevant stuff
> in one repositore.  This does not mean I would try to convince you to
> drop git and switch to svn.  This is rather a cry for help to find a
> way to easily enable every interested person easily to cope with changes
> in packaging stuff od Debian-Med packages.  David has written a great
> tool that lists SVN commits:
> http://debian-med.alioth.debian.org/
> but all changes outside SVN slip through this.  Do you see any chance
> to cover "everybody pet repository" which this kind of tool?

First of all, CIA.vc is not a tool of mine. I simply wrote the code to parse
CIA.vc's XML and output it.

Secondly, yes. CIA.vc does have a GIT-capable script. Just use it, and we'll
happily support GIT, we're done :)

Kindly,
David

-- 
 . ''`.  Debian maintainer | http://snipurl.com/qa_page/
 : :'  :  Linuxer #334216  |  http://www.hanskalabs.net/
 `. `'`GPG: 1392B174   | http://www.debianizzati.org/
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: Opinions sought: mlocate appropriate for Priority: standard?

[Adeodato Simó]

* Andreas Metzler [Sun, 11 Nov 2007 16:19:16 +0100]:

> I guess it would need happen like this:

> 1. upload findutils with splitoff locate to experimental. The locate
> package (Is this name ok?) ships /usr/bin/locate.findutils and
> /usr/bin/updatedb.findutils. It installs low-priority alterntives for
> these. The package conflicts with slocate (<< the next version, i.e.
> 3.1-1.2). It conflicts/replaces findutils (<=4.3.8-1, which is the
> last vesion living in experimental.)

Sounds good, and I think locate as package name is appropriate. Is there
an ETA for uploading 4.3.8 to unstable?

> > I guess dlocate would need an
> > upload as well.

> > How to handle the cron.daily script, though?

> +[ -e /usr/bin/updatedb.findutils ] || exit 0
> +  cd / && nice -n ${NICE:-10} updatedb.findutils 2>/dev/null

Well, I should've been more verbose: that patch will run updatedb even
if findutil's locate is installed but not the selected alternative. Now
that I think about it, maybe:

  [ `readlink -f /usr/bin/updatedb` = /usr/bin/updatedb.findutils ] || exit 0

(And the same for mlocate *and* slocate). How does it sound?

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
And don't get me wrong - I don't mind getting proven wrong. I change my
opinions the way some people change underwear. And I think that's ok.
-- Linus Torvalds


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

Re: Watching mentors and nifticlib

[Andreas Tille]

On Sun, 11 Nov 2007, Adeodato Simó wrote:


Was this mail meant to be sent to [EMAIL PROTECTED] instead of -devel?


Yes.  Sorry and thanks for the hint

  Andreas.

--
http://fam-tille.de

Bug#450849: ITP: particleman -- free version of Ion3

[Ben Hutchings]

Package: wnpp
Severity: wishlist
Owner: Ben Hutchings <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: particleman
  Version : 20071109
  Upstream Author : Tuomo Valkonen <[EMAIL PROTECTED]>
* URL : http://modeemi.fi/~tuomov/ion/
* License : LGPL
  Programming Lang: C, Lua
  Description : keyboard-friendly window manager with tiled windows

This is Ion3 renamed to ParticleMan to comply with the DFSG.

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

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHNzE479ZNCRIGYgcRAgsVAJ9qL8Pba4Ret1Mj4nE7i0SYibdtewCbB0j9
P9oB59qpCkVIrLKN/WUoBjc=
=tqoL
-END PGP SIGNATURE-



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

Re: Packaging: handling "private" libraries

[Andreas Tille]

On Sun, 11 Nov 2007, David Paleino wrote:


Could you please upload your stuff to mentors.debian.net?


Upstream is 37Mb, won't upload it ;)


Our policy for Debian-Med repository is to not upload upstream tarballs -
especially n ot those huge ones ...


I've added a "get-orig-source" target to debian/rules to get it.


Great.


Be careful that bioimagesuite_latest* would need bioimagesuite_extra* (to be
downloaded from the same website): this latter package merely contains the lib*
packages bioimagesuite already depends on (vtk-tcl, ...)

Moreover, you just get the original tarball. Renaming
to package_version.orig.tar.gz is still a manual thing (the upstream tarball
doesn't contain the version).


Just downloaded the tarball.  The upstream policy has several drawbacks:

  0. It's just useless to password-protect GPLed software download.
 Please make sure that you give upstream a hint that an upload to
 the Debian-mirror will "undermine" their policy.  I think we are
 perfectly allowed to distribute it given it is GPLed, but I'd
 consider it to be polite to the authors to tell them about the
 consequence of a distribution by Debian.

  1. Watch file will not work.  Just also tell this to upstream that
 we could not really make sure to provide their latest version if
 they do not change their way of distributing the source.

  2. Without proper versioning we have a second reason that we can
 not provide a reasonable watch file.  In addition it is just no
 good style to leave out the version number - also for other users.

Did you told this to upstream?  Feel free to foreward this mail if you
feel it is reasonable.

Back to creating the orig.tar.gz: I added a get-orig-source script that
parses debian/changelog for the verison number and rebuilds upstream package
with apropriate version numbering.

Kind regards

 Andreas.

--
http://fam-tille.de


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

Bug#450850: ITP: libllmozlib -- A wrapper library with simple API for embedding of Gecko browsers via XULRunner

[robin cornelius]

Package: wnpp
Severity: wishlist
Owner: robin cornelius <[EMAIL PROTECTED]>


* Package name: libllmozlib
  Version : 1.1.1
  Upstream Author : Callum Prentice <[EMAIL PROTECTED]>
* URL : http://www.ubrowser.com
* License : Mozilla Tri-licence MPL1.1 or GPL2 or LGPG2.1
  Programming Lang: CPP
  Description : A wrapper library with simple API for embedding of Gecko 
browsers
 via XULRunner

A wrapper library that makes embedding of Gecko based browsers via XULRunner a 
simplified task. Designed for the Secondlife project, the library can be used
to display browsers on 3D OpenGL shapes as well as regular windows, by providing
access to a buffer that represents the display to be rendered.


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

Kernel: Linux 2.6.21 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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]

MTA comparison (postfix, exim4, ...)

[Osamu Aoki]

Hi,

After seeing recent post(*) on the default MTA issue, I did some
research and experiment on MTAs.  They are summarized at:

 http://wiki.debian.org/DefaultMTA

Also good review was found at: http://shearer.org/MTA_Comparison

Although both exim4 and postfix daemons are negligibly small ones on
a desktop machine, exim4 one was a bit smaller on memory.

So far, I did not see strong reason to switch to postfix here but I am
runing it anyway now.

Osamu

(*) http://lists.debian.org/debian-devel/2007/10/msg00717.html


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

Re: buildds: "Authentication warning overridden."

[Steve Langasek]

On Sun, Nov 11, 2007 at 01:27:14PM +0100, Florian Weimer wrote:
> * Wouter Verhelst:

> > That's inevitable because http://incoming.debian.org is not signed; The
> > update frequency of that repository (which is available only to buildd
> > hosts by IP and/or password protection) makes that impossible -- or at
> > least that's what I understood; you may want to check with ftp-masters
> > for the full story.

> In this case, HTTPS should be used to download the packages, together
> with proper certificate validation.  This has got the added benefit that
> passwords aren't sent in the clear (well, unless an error occurs, but
> this is a separate issue).

I believe the Packages file is only exposed over ssh, so there is a trusted
path - just not one that apt recognizes as being adequate to eliminate the
authentication warning.  (Which is unfortunate, because AFAIK the "accept
unauthenticated packages" flag can't be enabled on a per-source basis.)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org


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

Re: dh_installinit

[Russ Allbery]

Vincent Danjean <[EMAIL PROTECTED]> writes:

> I agree, too. If I remember correctly, there has been discussion in libc
> and/or kernel to be able to open files with random high-numbered file
> descriptors. When these mechanisms will be ready, a deamon will be
> unable to close all its file descriptors (unless it closes the whole
> range of fd (0--2^16 ?) or unless an application can get a list of its
> open fds).

Yeah, I believe this problem may already exist on the Hurd, which tries to
avoid any set limits on things like file descriptors.  That's another
reason why I'm not fond of these close loops.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: dh_installinit

[Russ Allbery]

Manoj Srivastava <[EMAIL PROTECTED]> writes:

> I would agree that no entity should be passing open file
>  descriptors off to other processes unless this is  deliberate, and in
>  that case a proper policy has been written for it.

Okay, I think we're in agreement there.  The only open question is what a
daemon should do when it's mistakenly and erroneously handed open file
descriptors by its parent process that it's not aware of (other than 0, 1,
and 2, of course).  Right now, some daemons close all file descriptors up
to some arbitrary point (255 is common) but leave higher ones open, others
try to get the file descriptor limit via getrlimit and close everything up
to that limit, and others only deal with file descriptors they themselves
opened.

(I certainly agree that any daemon that opens file descriptors needs to
handle them appropriately if it also forks -- and, of course, any daemon
that uses PAM may fork.  Usually by setting close-on-exec on all opened
file descriptors.)

>> Insofar as there is any security impact here (which is dubious in most
>> cases),

> Why do you say that? If a process acquires a file handle on a
>  privileged file while running as dpkg_t; and passes it to debconf
>  running as debconf_t; why is there no security impact? dpkg_t might
>  have more access than debconf_t in the policy being run.

Well, I was thinking of the specific case that started this discussion,
which as I understand it was the case of a debconf handle being left open
when starting a daemon.  I could be misunderstanding the problem, but if
not, while this is a violation, I have a hard time figuring out what a
process could do with the debconf handle.  But that may just be lack of
imagination on my part.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: buildds: "Authentication warning overridden."

[Raphael Geissert]

Michael Banck wrote:
> 
> Assuming that compromised mirrors get quickly identified by people using
> signatures, and buildd packages having to be uploaded directly, the
> amount of compromised packages this way is probably small, so they can
> be rebuilt using packages from another mirror, after the build logs have
> been inspected to see whether compromised packages have indeed been
> used.
> 

Your last point really depends on how the packages were compromised, so it
is possible that a compromised package is used without a chance to find it.

That means that any package built on that buildd since the last mirror push
would have to be dropped (or in case it was already uploaded to the
archive, rebuild).

> 
> Michael

Regards,
Raphael


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

Re: Opinions sought: mlocate appropriate for Priority: standard?

[Andreas Metzler]

Adeodato Simó <[EMAIL PROTECTED]> wrote:
[...]
> Sounds good, and I think locate as package name is appropriate. Is there
> an ETA for uploading 4.3.8 to unstable?

No, not yet. But once stuff works in experimental (and all components
have gone through the necessary NEW processing) the respective change
could go to 4.2.x.

[...]
>> > How to handle the cron.daily script, though?

>> +[ -e /usr/bin/updatedb.findutils ] || exit 0
>> +  cd / && nice -n ${NICE:-10} updatedb.findutils 2>/dev/null

> Well, I should've been more verbose: that patch will run updatedb even
> if findutil's locate is installed but not the selected alternative. Now
> that I think about it, maybe:

>  [ `readlink -f /usr/bin/updatedb` = /usr/bin/updatedb.findutils ] || exit 0

> (And the same for mlocate *and* slocate). How does it sound?

I am not sure I get what problem you are trying to solve. I think you
want to stop findutil's cron.daily from generating a locate
database if findutil's locate is installed but the alternative
/usr/bin/updatedb points to a different implementation.

Imho this problem is not one that needs to be solved, if multiple
locates are installed, multiple databases should be generated.
cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


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

Re: buildds: "Authentication warning overridden."

[Kurt Roeckx]

On Sun, Nov 11, 2007 at 09:24:12AM -0800, Steve Langasek wrote:
> On Sun, Nov 11, 2007 at 01:27:14PM +0100, Florian Weimer wrote:
> > * Wouter Verhelst:
> 
> > > That's inevitable because http://incoming.debian.org is not signed; The
> > > update frequency of that repository (which is available only to buildd
> > > hosts by IP and/or password protection) makes that impossible -- or at
> > > least that's what I understood; you may want to check with ftp-masters
> > > for the full story.
> 
> > In this case, HTTPS should be used to download the packages, together
> > with proper certificate validation.  This has got the added benefit that
> > passwords aren't sent in the clear (well, unless an error occurs, but
> > this is a separate issue).
> 
> I believe the Packages file is only exposed over ssh

It's received over http.  The only thing ssh is used for is talking
to wanna-build.


Kurt


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

Re: RFC: cups as "default" printing system for lenny?

[brian m. carlson]

On Sun, Nov 11, 2007 at 09:21:46AM +0100, Bernd Zeimetz wrote:

Manoj Srivastava wrote:


[lpr is standard on Unix]


That works well with cups if you have the cupsys-bsd package installed.


More importantly, programs (gv comes to mind) that don't have native 
printing support but use an external program almost always use lpr, not 
lp.  (I can think of at most one that used lp, and numerous ones that 
used lpr.)  So if we use CUPS as the default printing package, we almost 
certainly need the BSD utilities installed as well.


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


signature.asc
Description: Digital signature

Re: Opinions sought: mlocate appropriate for Priority: standard?

[Adeodato Simó]

* Andreas Metzler [Sun, 11 Nov 2007 19:41:07 +0100]:

> No, not yet. But once stuff works in experimental (and all components
> have gone through the necessary NEW processing) the respective change
> could go to 4.2.x.

Ah, very well then.

> Imho this problem is not one that needs to be solved, if multiple
> locates are installed, multiple databases should be generated.

I think differently. Particularly given that findutil's locate can be
installed only as a dependency of other packages. (If this wasn't the
case, I'd agree your point of view is valid as well.) Did you consider
this?

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
 Listening to: Fangoria - Me comeré tu piel, me beberé tu sangre


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

Re: RFC: cups as "default" printing system for lenny?

[Marc 'HE' Brockschmidt]

Russ Allbery <[EMAIL PROTECTED]> writes:
> Also, do we really need *any* printing system as priority: standard?  It's
> not clear to me that printing is still really part of a standard Unix
> installation, even for desktop users (and it definitely isn't for
> servers).

I believe it to be one of the more important bits of a standard Unix
*desktop* installation - but this just reminds me of the fact that I'm
quite uncomfortable with keeping a system like package priorities around
for much longer. Diverging use-cases (like in this case) show that one
definition of "standard" isn't really helpful anymore.

I think we may want to start thinking about getting rid of the whole
thing and switching to something which allows us to express more complex
importance measurements for packages. In fact, d-i and its task system
have been a step in that direction, so we maybe should evaluate if we
want to formalize it a bit more and get it into policy to replace
priorities.

Marc
-- 
BOFH #4:
static from nylon underwear


pgpqsyucbj3TQ.pgp
Description: PGP signature

Re: dh_installinit

[Arthur de Jong]

On Sun, 2007-11-11 at 11:04 +0100, Vincent Danjean wrote:
> When these mechanisms will be ready, a deamon will be unable to close
> all its file descriptors (unless it closes the whole range of fd
> (0--2^16 ?) or unless an application can get a list of its open fds).

This seems to be quite common code (from one of my packages (cvsd),
don't know what the original source for this code was):

  m=sysconf(_SC_OPEN_MAX);
  for (i=0;ihttp://people.debian.org/~adejong --


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

Re: buildds: "Authentication warning overridden."

[Bastian Blank]

On Sun, Nov 11, 2007 at 01:27:14PM +0100, Florian Weimer wrote:
> * Wouter Verhelst:
> > That's inevitable because http://incoming.debian.org is not signed; The
> > update frequency of that repository (which is available only to buildd
> > hosts by IP and/or password protection) makes that impossible

Nack. The Release files are automaticaly signed. The problem is that the
accepted queue is no complete dist but only a Packages file, so there is
no Release file to be signed.

> In this case, HTTPS should be used to download the packages, together
> with proper certificate validation.  This has got the added benefit that
> passwords aren't sent in the clear (well, unless an error occurs, but
> this is a separate issue).

You try to fix one of the problems with buildds. You need to spoof DNS
or similar things to overtake the main mirror. There is a much worser
problem, the build logs which are usualy used to generate the signed
changes file are not authenticated in any way. This bug can be triggered
by anyone and at least the security team usualy don't know where logs
may come from.

Bastian

-- 
You're dead, Jim.
-- McCoy, "Amok Time", stardate 3372.7


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

Re: RFC: cups as "default" printing system for lenny?

[Leo "costela" Antunes]

[not subscribed to -policy, just keeping original cross-posting]

Marc 'HE' Brockschmidt wrote:
> I think we may want to start thinking about getting rid of the whole
> thing and switching to something which allows us to express more complex
> importance measurements for packages. In fact, d-i and its task system
> have been a step in that direction, so we maybe should evaluate if we
> want to formalize it a bit more and get it into policy to replace
> priorities.

Seconded.
A use-case based priority system is clearly - IMHO - a better suited
system then the "Priority:" paradigm for a distribution as broad
reaching as Debian.
Whether by extending the tasks system, the Priority paradigm (by perhaps
including a [use-case] tag, for instance: "Priority: standard
[!embeded]") or another wholly different approach, this seems like a
worthwhile idea.

One of the possible advantages for a different paradigm would be for
"reduced" CDDs, such as Emdebian, whose standard set of packages might
divert considerably by having _less_ packages, in which case the current
task system would fall short, AFAICT.

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: LSB-ize daemon without pidfile handling

[Raphael Geissert]

Marc Haber wrote:
> On Sat, 10 Nov 2007 17:00:13 +0100, Wouter Verhelst
> <[EMAIL PROTECTED]> wrote:
>>That is one way to look at it. The other way would be that these are
>>just three lines of "code" being duplicated here, and that start_daemon
>>is just a convenience function, nothing more.
> 
> So, start_daemon is not part of the standard?

Actually, it is[1] (opening b.d.o/debhelper and check for an existing report
about it: /usr/share/debhelper/dh_make/debian/init.d.lsb.ex)

> 
> Greetings
> Marc
> 

[1]
http://refspecs.linux-foundation.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptfunc.html


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

Re: LSB-ize daemon without pidfile handling

[Raphael Geissert]

Marc Haber wrote:
> On Fri, 09 Nov 2007 22:00:42 +0100, Petter Reinholdtsen
> <[EMAIL PROTECTED]> wrote:
>>[Marc Haber]
>>> I do not plan to do so for obvious reasons.
>>
>>It is not obvious for me.  Can you explain why it should be obvious
>>that you do not plan to patch the daemon to write its own pid file?
>>For me, the obvious solution for a daemon unable to write its own pid
>>file is to patch the daemon.
> 
> I generally try not to patch upstream code if avoidable. Especially if
> a patch would not be acceptable to upstream in the form we would apply
> as a quick fix (no command line option, hard-coded path to the pid
> file).

Then why don't you do it The Right Way (tm)?
It isn't hard to read command line arguments with options, see man
getopt(3?).

> 
> Greetings
> Marc
> 



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

Re: Opinions sought: mlocate appropriate for Priority: standard?

[Paul Wise]

On Nov 11, 2007 10:38 PM, Andreas Metzler <[EMAIL PROTECTED]> wrote:

> If we have got (at least temporarily) three locate packages in Debian
> we probably need to switch to alternatives. (Currently slocate uses
> dpkg-divert.)

Why do we need 3 packages that do the same thing slightly differently?
Can't the 3 upstreams work together to get one locate that works
sanely and has all the features needed (another feature I'd like to
see in locate would be locateD, so I can avoid the nightly updatedb
runs and just use inotify or the kfreebsd equivalent)?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: dh_installinit

[Steve Langasek]

On Sun, Nov 11, 2007 at 09:25:11PM +0100, Arthur de Jong wrote:

> On Sun, 2007-11-11 at 11:04 +0100, Vincent Danjean wrote:
> > When these mechanisms will be ready, a deamon will be unable to close
> > all its file descriptors (unless it closes the whole range of fd
> > (0--2^16 ?) or unless an application can get a list of its open fds).

> This seems to be quite common code (from one of my packages (cvsd),
> don't know what the original source for this code was):

>   m=sysconf(_SC_OPEN_MAX);
>   for (i=0;i close(i);

> There are hurd packages for this package so that should also work.

I wouldn't be so quick to assume that sysconf(_SC_OPEN_MAX) does anything
useful on Hurd at runtime.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


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

Re: dh_installinit

[Russ Allbery]

Steve Langasek <[EMAIL PROTECTED]> writes:
> On Sun, Nov 11, 2007 at 09:25:11PM +0100, Arthur de Jong wrote:

>> This seems to be quite common code (from one of my packages (cvsd),
>> don't know what the original source for this code was):

>>   m=sysconf(_SC_OPEN_MAX);
>>   for (i=0;i> close(i);

>> There are hurd packages for this package so that should also work.

> I wouldn't be so quick to assume that sysconf(_SC_OPEN_MAX) does anything
> useful on Hurd at runtime.

Plus, I suppose making 65,000 pointless system calls during the startup of
a daemon (not a particularly surprising value for the limit on open file
descriptors) isn't really that big of a deal, but it feels kind of "ugh"
to me.  If every daemon does that, I wonder if it would have a noticable
impact on startup speed.  Probably not, since in Linux system calls are
pretty fast, but that's a large multiplicative factor.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: RFC: cups as "default" printing system for lenny?

[Steve Langasek]

On Sun, Nov 11, 2007 at 01:05:36AM -0500, Joey Hess wrote:
> Yes, it would make more sense for samba to default to CUPS, if there's
> some reason it can't probe/support both,

Well, because there's no code written to do this, and anyway supporting both
at the same time would likely be messy and result in duplicate queues.
(Note that one of the reasons Samba needs to know what print system is in
use is in order to export the list of available queues over SMB if
configured to do so.)

> and if it can't use the generic lpr interface also provided by cupsys.

The cupsys lpr interface is only available with the cupsys-bsd package,
which is Priority: extra and is not likely to be installed unless
specifically requested.  So if CUPS is preferred, it's more straightforward
to just use the native CUPS support.

I'll make this change to the Samba packages for lenny, after verifying
whether any special handling is needed for transitioning.

> Yes, there's no reason to have any printing system at standard priority.
> A full CUPS install with all the PPDs and such would bloat standard
> enormously.

I don't agree that making CUPS standard implies also making all of the PPDs
standard (AFAICS cupsys only Recommends foomatic-filters and doesn't depend
on any PPDs at all), but I'm not bothered if CUPS doesn't become standard
either; just thought the question was worth asking.

> Just making cupsys standard would perhaps allow spooling to remote
> printers from the command line, but not much else. d-i makes it easy
> enough to get CUPS installed.

Indeed, I seem to have it already installed even in places where I didn't
want it. ;)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


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

Re: dh_installinit

[Tim Spriggs]

Russ Allbery wrote:

Steve Langasek <[EMAIL PROTECTED]> writes:
  

On Sun, Nov 11, 2007 at 09:25:11PM +0100, Arthur de Jong wrote:



  

This seems to be quite common code (from one of my packages (cvsd),
don't know what the original source for this code was):
  


  

  m=sysconf(_SC_OPEN_MAX);
  for (i=0;i  


  

There are hurd packages for this package so that should also work.
  


  

I wouldn't be so quick to assume that sysconf(_SC_OPEN_MAX) does anything
useful on Hurd at runtime.



Plus, I suppose making 65,000 pointless system calls during the startup of
a daemon (not a particularly surprising value for the limit on open file
descriptors) isn't really that big of a deal, but it feels kind of "ugh"
to me.  If every daemon does that, I wonder if it would have a noticable
impact on startup speed.  Probably not, since in Linux system calls are
pretty fast, but that's a large multiplicative factor.
  


Is there no way of listing open file handles within a process? It seems 
like there should be a better way. If the kernel knows what file handles 
exist (and lsof can get the info) then what's stopping a process from 
accessing that information directly? Maybe it's just not portable enough?



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

Re: RFC: cups as "default" printing system for lenny?

[Steve Langasek]

On Sat, Nov 10, 2007 at 09:42:52PM -0800, Russ Allbery wrote:

> > - Should we consider raising the priority of cupsys to standard, to take the
> >   place of lpr as an available-by-default printing system on stock installs?

> The last time I looked at CUPS, it was massively more complicated than lpr
> and involved dubious things like running daemons that listened on network
> ports for user configuration.  Is that still the case?

CUPS still supports configuration via the web interface on port 631, yes; by
default the daemon only listens on localhost, though, and there are other
config tools that don't rely on the web interface for managing
printers/queues in a desktop setting.

It is more complicated than lpr, for sure.  That's a big reason why I don't
particularly care for the implementation.  Nevertheless, CUPS has
effectively won out as the standard printing service on Linux.

> Also, do we really need *any* printing system as priority: standard?  It's
> not clear to me that printing is still really part of a standard Unix
> installation, even for desktop users (and it definitely isn't for
> servers).

Perhaps not.  It did seem to me like something that we would want available
by default, and that would in any case be consistent with past practice.
After all, this isn't so much a question of installing a "print server"
task, the cupsys package is these days the package most users will want
installed even for local printing.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


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

Re: dh_installinit

[Michal Čihař]

Hi

On Sun, 11 Nov 2007 20:31:55 -0700
Tim Spriggs <[EMAIL PROTECTED]> wrote:

> Is there no way of listing open file handles within a process? It seems 
> like there should be a better way. If the kernel knows what file handles 
> exist (and lsof can get the info) then what's stopping a process from 
> accessing that information directly? Maybe it's just not portable enough?

You can definitely get it from /proc, but it is far from being portable.

-- 
Michal Čihař | http://cihar.com | http://blog.cihar.com


signature.asc
Description: PGP signature

Bug#450909: ITP: vblade-persist -- create/manage supervised AoE exports

[Daniel Kahn Gillmor]

Package: wnpp
Severity: wishlist
Owner: Daniel Kahn Gillmor <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


* Package name: vblade-persist
  Version : 0.1-1
  Upstream Author : Daniel Kahn Gillmor <[EMAIL PROTECTED]>
* URL : http://cmrg.fifthhorseman.net/wiki/vblade-persist
* License : GPL
  Programming Lang: shell
  Description : create/manage supervised AoE exports

This package uses runit to supervise permanent exports of AoE block
devices.  It gives administrators simple, fine-grained,
easily-automatable control over which devices should be actively
exported under which AoE shelfs and slots.

- -

vblade-persist is a package that would be useful for people building
AoE NAS devices, as well as for people managing virtualized server
farms who want to minimize single points of failure by mirroring data
across multiple physical machines.

- -

A simple package is already made, and is available from an APT
repository.  You can use these lines to get the package:

 deb http://cmrg.fifthhorseman.net/debian unstable vblade-persist
 deb-src http://cmrg.fifthhorseman.net/debian unstable vblade-persist

the repository is signed by my GPG key.

The package appears to me to be lintian- and linda-clean, and works
for me in an experimental server-farm scenario.  As always, i'm happy
to take any suggestions or advice on anything that could be improved.

As i'm not a DD, I'll need a sponsor to upload this package.

Thanks,

--dkg

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

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iQIVAwUBRzfY5MzS7ZTSFznpAQKILRAAgYmSSQS+SWYnRoU31CftrHQoHtJXePb3
3MoclOnxgbwkANKz3W83A5XroGJQ4dzMyor1HzFZEmXK7rzj5eQ/i2VERTmZG2IS
ov315+LTDo4Fzsbwvn3YfZO6vGu08Yb6MkTD6LJNTSpoRZP3gIEDai1wgcMaMLfq
zZTKAKRuZj2opetop82DuVNRs+yKjh3+xL681OWJgHrxjT/idlc32C1ACThJAhry
ra8pyplpE9rtPVG8Fem1164KvEeuSdKW6p47+hoODtV1INfn7foXUEPU7J9OAYKl
8GwpWwj5a7vAFK2XEZdCGF/7sf4HOkmRtyxup0ekLptVQGViegoHlgiHs/Dph2j8
5rQyOM9071ueQOw8JIuzHWZfocsrkLNbxfrO0BpMcFetN2PDTK8SBuKNjtbWIAHM
THvGzzBBNFAwKeCsCcFJRmRDzRU6wPDnYY7v9Fs+r/SLPR+OPi57TF4x9X/j/6Ne
7uBWW5awC6xBiUjmglOYFTjvz40mJaJF6qnVDGIOWSvFCRkvWYCvTtS6NHb9moLW
jW0+BgVqHIA2uVLN6YxVsPOnsfyEcxrNG48HQta8gypCbEGqS98Jbm+7apuGXPN9
lnVP5Mq1fAtLbeEhmuR7Qg1O7B3pK25SI7sACZRbPnEcKtWewWv1EvVLLD4fB7Sl
3VowsBeCJbo=
=kAuX
-END PGP SIGNATURE-



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

Re: Bug#449317: ITP: zekr-quran-translations-ur -- Zekr Quran Urdu translations

[David Starner]

Josselin Mouette wrote:
>Le lundi 05 novembre 2007 à 05:18 +, brian m. carlson a écrit :
> > According to Wikipedia, the translator died in 1921, which means that
> > his translation occurred prior to 1923.  In this case, the translation
> > is in the public domain in the United States, so the license above is
> > incorrect.
>
> That would be true if the author was a US citizen.

His citizenship is irrelevant here. If it was _published_ (_not_
translated) prior to 1923, it's in the public domain in the US. If it
was published prior to the translator's death, it's most likely out of
copyright everywhere, though there are some unlikely exceptions.

Intent to ship xfonts-wqy pcf fonts uncompressed

[Deng Xiyue]

There's been a long standing performance issue of using xfonts-wqy due
to compression. As Fang Qianqian <[EMAIL PROTECTED]> pointed
out, the Debian Policy[1] requires pcf to be gzipped. However, due to
the huge set of Chinese characters, the compression brings serious
performance issue as pointed out in bug #384149[2]. There is intention
to ship such fonts ungzipped, which should alleviate the situatio. Due
to the complication with Debian Policy, we think it'd better to have a
discussion in debian-devel and debian-policy mailing lists for a
suggestion.

[1]
http://www.debian.org/doc/debian-policy/ch-customized-programs.html#s11.8.5
[2] http://bugs.debian.org/384149



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

Re: [Pkg-samba-maint] RFC: cups as "default" printing system for lenny?

[Christian Perrier]

Quoting Steve Langasek ([EMAIL PROTECTED]):
> A few years back, Samba upstream began using CUPS as the default printing
> system whenever CUPS support was enabled.  At the time, cupsys was Priority:
> optional, and lpr as the standard Unix printing interface was Priority:
> standard (or higher), so I patched the Samba packages in Debian to default
> to BSD printing instead of CUPS.
> 
> Today the circumstances have changed.  It seems that lpr was demoted to
> optional sometime before the etch release, putting it on equal footing with
> cupsys in that regard, and CUPS itself has IME improved markedly since the
> time that decision was made (I'm personally still not fond of the
> implementation, but at least it does a better job of talking to printers for
> me :).  So I have two questions:
> 
> - Is there any remaining reason why the Samba maintainers shouldn't drop
>   this patch, switching to CUPS as the default print system?

I think that no objections to this was made so we might drop the
patch. DO you agree, Steve, or should we wait longer for other comments?

I vote for dropping the patch which is yet another step towards having
samba in Debian as close as possible as its upstream.

> - Should we consider raising the priority of cupsys to standard, to take the
>   place of lpr as an available-by-default printing system on stock installs?


Here, we clearly don't seem to have any consensus, but anyway, *this*
is not in samba maintainers hands, of course.




signature.asc
Description: Digital signature