Re: udev and /usr

[Giacomo A. Catenazzi]

Steve Langasek wrote:

On Fri, Sep 04, 2009 at 12:59:10AM -0400, Felipe Sateler wrote:

The issue was raised by the udev upstream maintainer along with the udev
package maintainers of the major distributions, who all agreed that this
configuration is not supported.

FYI, udev 146 ships usb-id and pci-id programs which read
/usr/share/misc/usb.ids and /usr/share/misc/pci.ids .
udev itself does not care about the results of these programs but other
programs which used to use HAL may do, leading to subtle breakage.



Reading again your mail, I think we are discussing a inexistent problem.



You say that "some programs which use HAL may do" use /usr/share.



Hal also lives on /usr, so I don't see the problem either.


The problem is this:

 - In udev 146 and above, a number of the stock udev rules call the
   /lib/udev/{pci,usb}-db helpers to query the vendor name / product name
   and and this information to the udev environment.
 - These helpers work by parsing the pci.ids and usb.ids databases, which
   have long had standard locations that are *not* in /lib (either in /usr
   or in /var, both of which are allowed to be separate filesystems under
   the FHS).
 - Now that there are udev rules exporting this information, arbitrary other
   components in the stack may come to rely on this information being
   available (but we don't seem to know what components; the rationale for
   this facility being added to udev so far is pretty opaque, though
   whatever it is can't be good).
 - These udev rules are applied from runlevel S, before /usr or /var are
   guaranteed to be mounted.  That means that any device which is detected
   by the kernel before this point (such as non-hotpluggable PCI devices)
   will have different information exported by udev depending on whether
   /usr and /var are on the root filesystem.

I still can't fathom why someone decided that udev should be responsible for
translating PCI IDs and USB IDs into text strings.  This smells of crazy.


I agree, also considering that AFAIK we have not the official names, thus from
time to time there are huge renames in the ids files. Sometime a company
changes the name and the ids file will change (addition or change of suffix
like "limited" etc; adding or replacing the new company name (on merges), ...

Some names contain non alphanumeric characters, which is annoying on device
names (they are properly quoted, but anyway).

Thus the use of ids file create not stable device names, and probably not
nice names. I really think numeric names are a lot better.

Anyway reading the id_usb:

 * A unique USB identification is generated like this:
 *
 * 1.) Get the USB device type from InterfaceClass and InterfaceSubClass
 * 2.) If the device type is 'Mass-Storage/SPC-2' or 'Mass-Storage/RBC'
 * use the SCSI vendor and model as USB-Vendor and USB-model.
 * 3.) Otherwise use the USB manufacturer and product as
 * USB-Vendor and USB-model. Any non-printable characters
 * in those strings will be skipped; a slash '/' will be converted
 * into a full stop '.'.
 * 4.) If that fails, too, we will use idVendor and idProduct
 * as USB-Vendor and USB-model.
 * 5.) The USB identification is the USB-vendor and USB-model
 * string concatenated with an underscore '_'.
 * 6.) If the device supplies a serial number, this number
 * is concatenated with the identification with an underscore '_'.

Thus the use of name is only the third priority, and there are
3 additional fallbacks. Thus, IMHO, we don't need to worry much about
missing /usr/share on *some* environments.

Thus I think people who want a separate /usr can live lovely without
ids files (and probably they/me prefer numeric ids).

BTW the files are also included in the kernel, so we can use kernel
informations.

ciao
cate


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

Re: udev and /usr

[Steve Langasek]

On Fri, Sep 04, 2009 at 12:59:10AM -0400, Felipe Sateler wrote:
> >>> The issue was raised by the udev upstream maintainer along with the udev
> >>> package maintainers of the major distributions, who all agreed that this
> >>> configuration is not supported.
> >> FYI, udev 146 ships usb-id and pci-id programs which read
> >> /usr/share/misc/usb.ids and /usr/share/misc/pci.ids .
> >> udev itself does not care about the results of these programs but other
> >> programs which used to use HAL may do, leading to subtle breakage.

> > Reading again your mail, I think we are discussing a inexistent problem.

> > You say that "some programs which use HAL may do" use /usr/share.

> Hal also lives on /usr, so I don't see the problem either.

The problem is this:

 - In udev 146 and above, a number of the stock udev rules call the
   /lib/udev/{pci,usb}-db helpers to query the vendor name / product name
   and and this information to the udev environment.
 - These helpers work by parsing the pci.ids and usb.ids databases, which
   have long had standard locations that are *not* in /lib (either in /usr
   or in /var, both of which are allowed to be separate filesystems under
   the FHS).
 - Now that there are udev rules exporting this information, arbitrary other
   components in the stack may come to rely on this information being
   available (but we don't seem to know what components; the rationale for
   this facility being added to udev so far is pretty opaque, though
   whatever it is can't be good).
 - These udev rules are applied from runlevel S, before /usr or /var are
   guaranteed to be mounted.  That means that any device which is detected
   by the kernel before this point (such as non-hotpluggable PCI devices)
   will have different information exported by udev depending on whether
   /usr and /var are on the root filesystem.

I still can't fathom why someone decided that udev should be responsible for
translating PCI IDs and USB IDs into text strings.  This smells of crazy.

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


signature.asc
Description: Digital signature

Re: Future of the s390 port

[Christian Perrier]

Quoting Petter Reinholdtsen (p...@hungry.com):

> I expect you will get this if you use HTTP to submit and any HTTP
> proxy specified using the HTTP_PROXY variable in
> /etc/popularity-contest.conf.  The only identity submitted would be
> the random ID generated by popcon to make sure the weekly resubmission
> of information replaces the last one.  Or one could use a SMTP
> remailer stripping headers, I guess.  But that seem to be more work
> than just using a HTTP proxy.


FWIW, I have personnally always considered this as way enough to
guarantee the level of "anonymization" mentioned by Russ.

Enough to have all "my" production Debian servers at ONERA
(www.onera.fr) to report by popcon through our HTTP proxy. ONERA is a
governmental research agency which activity is focused on both
Defense-oriented research and industry-related research in aeronautics
and space. You probably get the drill: we *are* concerned about
security and confidentiality and our servers do report to popcon.

I would of course be much more reluctant to do this for servers
located directly on the Internet but we have (sigh) no Debian servers
there. We create our own security holes by using Solaris
everywhere..:-)





signature.asc
Description: Digital signature

Out of Office

[mgt . santhosh]

I will be out of office from 3rd September  till 7 th september and  will 
attend to mail intermittently. In case of urgency please contact :

 Sethumadhavan: dox.se...@cok.plsll.co.in
 Manoj Unnikrishnan: sal.ma...@cok.plsll.co.in 

Thanks/Regards
Santhosh Kumar


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

Re: udev and /usr

[Felipe Sateler]

Giacomo A. Catenazzi wrote:

> Marco d'Itri wrote:
>> On May 31, md wrote:
>>
>>> The issue was raised by the udev upstream maintainer along with the udev
>>> package maintainers of the major distributions, who all agreed that this
>>> configuration is not supported.
>> FYI, udev 146 ships usb-id and pci-id programs which read
>> /usr/share/misc/usb.ids and /usr/share/misc/pci.ids .
>> udev itself does not care about the results of these programs but other
>> programs which used to use HAL may do, leading to subtle breakage.
> 
> Reading again your mail, I think we are discussing a inexistent problem.
> 
> You say that "some programs which use HAL may do" use /usr/share.

Hal also lives on /usr, so I don't see the problem either.

-- 
Felipe Sateler


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

Re: Of the use of native packages for programs not specific to Debian.

[Ben Finney]

Wouter Verhelst  writes:

> I feel I should point out that my initial mail in this subthread was a
> reaction to a one-line statement that 'switching upstreams does not
> make a package native.' That I objected to, because of the lack of
> context, and the inherent feeling that, to me, seemed to be part of
> this message that this package had no business whatsoever of being a
> native package.

I didn't read that comment that way. Rather I read that switching
upstream developer *by itself* is insufficient reason to make a package
native. (I agree with that position.)

You don't seem to have argued against that. Rather, you've presented the
position that there are particular reasons that are sufficient for a
package to be native. That's compatible with a position that switching
upstreams is not one of those reasons, so I don't see what you object
to.

-- 
 \  “I got an answering machine for my phone. Now when someone |
  `\  calls me up and I'm not home, they get a recording of a busy |
_o__)  signal.” —Steven Wright |
Ben Finney


pgpMDypM4v5ZM.pgp
Description: PGP signature

Re: trayer_1.1_i386.changes REJECTED

[Gunnar Wolf]

Wouter Verhelst dijo [Thu, Sep 03, 2009 at 12:47:44PM +0200]:
> > >   * Upstream has abandoned the program, so the package is now Debian
> > > native.
> > 
> > Switching upstreams does not make a package native.
> 
> How so? There is no reason why a package where the upstream and the
> Debian Developer are one and the same person could not be native.
> 
> I know it is fancy and modern to think that Debian native packages
> should only be used for things that are specific to the Debian
> infrastructure, but there is nothing in policy that requires that, and
> indeed several packages (including, e.g., offlineimap) are distributed
> as such.

Why should it be Debian-native? Do you want other distributions
carrying it to necessarily include your debian/*? Do you want to
throw stones in the way of Debian derivatives by being unable to do
packaging-specific changes while keeping track of your upstream
releases? 

-- 
Gunnar Wolf • gw...@gwolf.org • (+52-55)5623-0154 / 1451-2244


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

Re: Fwknop: Layout suggestions for a future implementation

[Manoj Srivastava]

On Thu, Sep 03 2009, Franck Joncourt wrote:

> Manoj Srivastava wrote:
>> On Wed, Sep 02 2009, Franck Joncourt wrote:
>> 
>>> I have got one tarball from upstream which is separated in fwknop-client
>>> and fwknop-server. The programs are mainly implemented in perl.
>>>
>>> Upstream is now working on rewriting it in C. Thus we have now a brand
>>> new tarball available known as fwknop-c.
>>>
>>> This new tarball contains at the moment :
>>>
>>> - a shared library -> libfko
>>> - the documentation of the shared library
>>> - an XS module FKO that allows fwknop-client/server to use the new
>>>   libfko library.
>>> - the fwknop client written in C
>>>
>>> - later maybe a fwknop-c-server
>>>
>>> Therefore, I was thinking about such binary packages:
>>>
>>>  - 1) a shared library libfko0
>>>  - 2) a devel package libfko0-dev
>>>  - 3) a doc package libfko-doc
>>>  - 4) a fwknop-c-client
>>>  - 5) a fwknop-c-server
>>>  - 6) a libspa-fko-perl module
>>>
>>> and I was suggesting to split the current fwknop-c tarball in three as
>>> following:
>>>
>>>  - one for 1+2+3
>>>  - one for 4+5
>>>  - one for 6
>>>
>>> To me it looks reasonable to split it. What do others think?
>>> Upstream is also insterested in hearing your opinions :)
>> 
>> Please explain why it needs to be split? A single source package
>>  can create as many binary packages as are desired, so the splitting off
>>  the binary packages does not impose any requirements to split the source
>>  package. 
>
> At a first glance there is no need to split it, and all of the binary
> packages could be created from one source package as you mentionned.
> However, for other distributions than Debian I do not know how their
> packaging stuff work.

This is not an issue for any Debian derivatives; they all take
 the same underlying  package infrastructure. Non derivative
 distributions  will not use the Debian packaging, and thus splitting it
 in Debian will not help anyone.

So, if this is questions the upstream is considering, you
 already have the answer:

> Looking at projects like mysql and dhcp, I would tend to say it is fine
> to have both the client and server applications bundled in the source
> package with the shared library.


I think the project, and thus the tarball, should reflect  the
 line of development; this is a single project, developed together, and
 thus the tarball should remain together, especially since this avoids
 the hassle of the different source tarballs gtting out of sync
 somewhere.

Most distriutions have already figured out how to create
 multiple  binary packages from a single source tarball, so this should
 not be a consideration.

manoj

-- 
The more things change, the more they stay insane.
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: Future of the s390 port

[Russ Allbery]

Petter Reinholdtsen  writes:

> I expect you will get this if you use HTTP to submit and any HTTP proxy
> specified using the HTTP_PROXY variable in /etc/popularity-contest.conf.
> The only identity submitted would be the random ID generated by popcon
> to make sure the weekly resubmission of information replaces the last
> one.  Or one could use a SMTP remailer stripping headers, I guess.  But
> that seem to be more work than just using a HTTP proxy.

Okay, cool, I'll poke at that and see if that works for our environment.

-- 
Russ Allbery (r...@debian.org)   


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

Re: Future of the s390 port

[Samuel Thibault]

Russ Allbery, le Thu 03 Sep 2009 13:32:46 -0700, a écrit :
> In specific, our information security office (rightfully) considers
> the relationship between system and list of installed packages to
> be confidential data because of the potential use of such data in
> determining which systems to attack following a publicly announced
> vulnerability.

Could perhaps an almost empty popcon report be considered as valid at
least just for the number of installed systems?

Samuel


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

Re: Future of the s390 port

[Petter Reinholdtsen]

[Russ Allbery]
> Is there an easy way (read: the software already exists and I can
> just install it) for all of the systems to report to an internal
> proxy that then resubmits the data so that no one else can know
> where it's coming from exactly other than from our servers
> somewhere?

I expect you will get this if you use HTTP to submit and any HTTP
proxy specified using the HTTP_PROXY variable in
/etc/popularity-contest.conf.  The only identity submitted would be
the random ID generated by popcon to make sure the weekly resubmission
of information replaces the last one.  Or one could use a SMTP
remailer stripping headers, I guess.  But that seem to be more work
than just using a HTTP proxy.

The information submitted is generated and available in
/var/log/popularity-contest for those that want to have a look.  There
is no information recorded about the source, except for the unique ID
of the host which is generated using

  dd if=/dev/urandom bs=1k count=1 2>/dev/null | md5sum

when the package is installed.

Happy hacking,
-- 
Petter Reinholdtsen


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

Re: Future of the s390 port

[Adam Thornton]

On Sep 3, 2009, at 4:32 AM, Martin Grimm wrote:


I'm aware of popcon and as much as I'd appreciate it to see our  
systems

counted there this will not happen because these are mainly production
systems behind firewalls or in internal networks with no internet  
access

and I've generally a bad feeling when thinking of software that's
talking to outside systems when there is sensitive data on my  
server ;-)


I'm running about 20 Debian guests on z, but like Martin's, mine  
cannot actually get to the outside world directly, and that is not  
going to change.


Apt-proxy is a wonderful thing, though.

Adam


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

Re: Of the use of native packages for programs not specific to Debian.

[Wouter Verhelst]

On Thu, Sep 03, 2009 at 10:04:49PM +0200, Luk Claes wrote:
> Wouter Verhelst wrote:
> > True. However, if something is not explicitly forbidden by Policy (and
> > this isn't), and it does not cause (obvious) harm to Debian as a whole
> > (which this doesn't), there is no good reason why people should pretend
> > it's a bad idea.
> 
> This sounds very wrong, as if it would be ok to cause harm to some part
> of Debian when it's not forbidden in Policy.

Hmm. I don't know how, but you somehow managed to read the exact
opposite in my words of the message I was trying to deliver :-)

[...]
> > native package; however, several of them also explicitly state the
> > opinion that making a package native is perfectly okay, after having
> > considered those downsides. That's pretty much what I was saying in my
> > previous mail.
> 
> Yes, though only after considering all the downsides, including having
> these discussions and people requesting you to reconsider from time to time.

Sure.

I feel I should point out that my initial mail in this subthread was a
reaction to a one-line statement that 'switching upstreams does not make
a package native.' That I objected to, because of the lack of context,
and the inherent feeling that, to me, seemed to be part of this message
that this package had no business whatsoever of being a native package.
I did not (and do not) defend making _this particular_ package a native
one (I don't know enough about it either way), but was trying to discuss
the more general issue here.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


signature.asc
Description: Digital signature

Re: OK to reduce priority of update-inetd to optional?

[Patrick Matthäi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Serafeim Zanikolas schrieb:
> Hi,
> 
> Is it OK to reduce update-inetd's priority to optional, to agree with the
> archive admin's override? (It should be, as all its rdepends are at most
> optional)
> 
> It should be Priority: standard only if people use it interactively, and
> expect it to be part of a standard installation (but I'm guessing that this
> isn't common).
> 
> update-inetd_4.32_all.deb: package says priority is important, override says 
> optional.
> 

In my opinion (and I sponsored this upload) it is okay. In my opinion
there is no need that this packages has a bigger importance than
optional, this should fit for this package.

You may report this against ftp.debian.org.

- --
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

E-Mail: pmatth...@debian.org
patr...@linux-dev.org

Comment:
Always if we think we are right,
we were maybe wrong.
*/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkqgKFQACgkQ2XA5inpabMfhvQCeLy0RScUaQ4HxMUAwWIebeHQY
nksAnR54p7JQfSwsBULyhtITNNEkXyUU
=+rYd
-END PGP SIGNATURE-


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

Re: Future of the s390 port

[Russ Allbery]

Martin Grimm  writes:

> I'm aware of popcon and as much as I'd appreciate it to see our systems
> counted there this will not happen because these are mainly production
> systems behind firewalls or in internal networks with no internet access
> and I've generally a bad feeling when thinking of software that's
> talking to outside systems when there is sensitive data on my server ;-)

We're in a similar situation, although not with s390.  In specific, our
information security office (rightfully) considers the relationship
between system and list of installed packages to be confidential data
because of the potential use of such data in determining which systems to
attack following a publicly announced vulnerability.  I can therefore only
report popcon results for a handful of personal and test systems, rather
than ~300 production servers.

Is there an easy way (read: the software already exists and I can just
install it) for all of the systems to report to an internal proxy that
then resubmits the data so that no one else can know where it's coming
from exactly other than from our servers somewhere?

-- 
Russ Allbery (r...@debian.org)   


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

OK to reduce priority of update-inetd to optional?

[Serafeim Zanikolas]

Hi,

Is it OK to reduce update-inetd's priority to optional, to agree with the
archive admin's override? (It should be, as all its rdepends are at most
optional)

It should be Priority: standard only if people use it interactively, and
expect it to be part of a standard installation (but I'm guessing that this
isn't common).

update-inetd_4.32_all.deb: package says priority is important, override says 
optional.

-- 
debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp


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

Re: Of the use of native packages for programs not specific to Debian.

[Luk Claes]

Wouter Verhelst wrote:
> On Fri, Sep 04, 2009 at 01:31:40AM +1000, Ben Finney wrote:
>> Charles Plessy  writes:
>>> Le Thu, Sep 03, 2009 at 12:47:44PM +0200, Wouter Verhelst a écrit :
 I know it is fancy and modern to think that Debian native packages
 should only be used for things that are specific to the Debian
 infrastructure, but there is nothing in policy that requires that,
>> To be clear (and I know you probably already know this): just because
>> some practice is not explicitly mentioned in Policy, does not mean there
>> is no good way to decide whether or not it's good practice.
> 
> True. However, if something is not explicitly forbidden by Policy (and
> this isn't), and it does not cause (obvious) harm to Debian as a whole
> (which this doesn't), there is no good reason why people should pretend
> it's a bad idea.

This sounds very wrong, as if it would be ok to cause harm to some part
of Debian when it's not forbidden in Policy.

I also don't agree that there are no good reasons why it's a bad idea.

>> As far as whether this idea is “modern”, I don't know whether “more than
>> 8 years” is outside that range for an operating system only 16 years
>> old, but the consensus on this 2001-01 ‘debian-mentors’ thread
>> http://lists.debian.org/debian-mentors/2001/01/msg00191.html> seems
>> to be that packages should be native only if the package is specific to
>> the Debian infrastructure.
> 
> That thread has four people stating the downsides of making a package a
> native package; however, several of them also explicitly state the
> opinion that making a package native is perfectly okay, after having
> considered those downsides. That's pretty much what I was saying in my
> previous mail.

Yes, though only after considering all the downsides, including having
these discussions and people requesting you to reconsider from time to time.

Cheers

Luk


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

Re: Of the use of native packages for programs not specific to Debian.

[Wouter Verhelst]

On Fri, Sep 04, 2009 at 01:31:40AM +1000, Ben Finney wrote:
> Charles Plessy  writes:
> > Le Thu, Sep 03, 2009 at 12:47:44PM +0200, Wouter Verhelst a écrit :
> > > I know it is fancy and modern to think that Debian native packages
> > > should only be used for things that are specific to the Debian
> > > infrastructure, but there is nothing in policy that requires that,
> 
> To be clear (and I know you probably already know this): just because
> some practice is not explicitly mentioned in Policy, does not mean there
> is no good way to decide whether or not it's good practice.

True. However, if something is not explicitly forbidden by Policy (and
this isn't), and it does not cause (obvious) harm to Debian as a whole
(which this doesn't), there is no good reason why people should pretend
it's a bad idea.

> As far as whether this idea is “modern”, I don't know whether “more than
> 8 years” is outside that range for an operating system only 16 years
> old, but the consensus on this 2001-01 ‘debian-mentors’ thread
> http://lists.debian.org/debian-mentors/2001/01/msg00191.html> seems
> to be that packages should be native only if the package is specific to
> the Debian infrastructure.

That thread has four people stating the downsides of making a package a
native package; however, several of them also explicitly state the
opinion that making a package native is perfectly okay, after having
considered those downsides. That's pretty much what I was saying in my
previous mail.

As an aside, even if the thread did say something else, and with all due
respect, I do not consider -mentors to be authoritative on such a
subject.

> > At least one of the consequences of being native is that the package
> > gets all its gettext and manpages translations for free from Debian.
> 
> Another one is that any change to the Debian packaging for the work
> can't be released without bumping the version number of the work, even
> when there's no other change in the work other than the Debian
> packaging.

That's all most certainly true. I never said that making a package of
which one is both Debian and upstream maintainer a native package is a
good idea in _all_ cases. Indeed, my own such package, the nbd
utilities, is not a native package, precisely because I do not consider
it to be a good idea in that specific case for many of the reasons
mentioned.

What I am saying is that there can be cases where making a package a
native package can be the right thing to do, even if the functionality
of the package has nothing to do with Debian infrastructure. That it
should be the choice of the maintainer to be able to do so. That
deciding whether or not something should be a native package is the
maintainer's prerogative, and nobody else's.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


signature.asc
Description: Digital signature

Re: RFC: Moving gpg to /bin?

[Marco d'Itri]

On Sep 03, Daniel Leidert  wrote:

> Posting to debian-devel too. Please comment.
Don't do this. gnupg is 5 MB big, if we keep increasing the size of the
root file system what is the point of supporting a standalone /usr/?
Using cryptsetup+gnupg for /usr is a niche configuration of an already
niche configuration, it is not reasonable to move a large package to the
root just for this.

I agree that a new fstab flag would be a much better solution.
Not all feature requests are worth being implemented.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Fwknop: Layout suggestions for a future implementation

[Franck Joncourt]

Manoj Srivastava wrote:
> On Wed, Sep 02 2009, Franck Joncourt wrote:
> 
>> I have got one tarball from upstream which is separated in fwknop-client
>> and fwknop-server. The programs are mainly implemented in perl.
>>
>> Upstream is now working on rewriting it in C. Thus we have now a brand
>> new tarball available known as fwknop-c.
>>
>> This new tarball contains at the moment :
>>
>> - a shared library -> libfko
>> - the documentation of the shared library
>> - an XS module FKO that allows fwknop-client/server to use the new
>>   libfko library.
>> - the fwknop client written in C
>>
>> - later maybe a fwknop-c-server
>>
>> Therefore, I was thinking about such binary packages:
>>
>>  - 1) a shared library libfko0
>>  - 2) a devel package libfko0-dev
>>  - 3) a doc package libfko-doc
>>  - 4) a fwknop-c-client
>>  - 5) a fwknop-c-server
>>  - 6) a libspa-fko-perl module
>>
>> and I was suggesting to split the current fwknop-c tarball in three as
>> following:
>>
>>  - one for 1+2+3
>>  - one for 4+5
>>  - one for 6
>>
>> To me it looks reasonable to split it. What do others think?
>> Upstream is also insterested in hearing your opinions :)
> 
> Please explain why it needs to be split? A single source package
>  can create as many binary packages as are desired, so the splitting off
>  the binary packages does not impose any requirements to split the source
>  package. 

At a first glance there is no need to split it, and all of the binary
packages could be created from one source package as you mentionned.
However, for other distributions than Debian I do not know how their
packaging stuff work.

I thought interfaces to the shared library could be maintained through a
different tarball. Therefore the xs module could have been added to
CPAN. I mean, it would be like the libpcap library and its differents
interfaces. Does it make sense?

Looking at projects like mysql and dhcp, I would tend to say it is fine
to have both the client and server applications bundled in the source
package with the shared library.

However, people start working on GUIs to send SPA packets to the current
fwknop-server. Although the server and client side are the roots of the
shared library (this one has been created to allow their rewrite in C),
maybe the application could be put into another tarball as other
applications would be.

We are not to split the tarball or to gather everyting in the same
tarball, but in the middle :) What is the wiser thing to do? Which
layout to use to make it easy to maintain. Are there any problems which
could be encountered by using one method rather than the other?

This mail is intended to get your thoughts about the way the project
should be laid.

Regards,

-- 
Franck Joncourt
http://debian.org - http://smhteam.info/wiki/



signature.asc
Description: OpenPGP digital signature

Re: udev and /usr

[Florian Lohoff]

On Thu, Sep 03, 2009 at 12:53:10PM +0200, Tollef Fog Heen wrote:
> ]] Florian Lohoff 
> 
> | I have ~600 Machines in the field - all with /usr on a seperate fs - If 
> Debian
> | is going to make seperate /usr a no-go its about 30 Euros worth
> | of field Engineer time - swapping disks.
> 
> I'm fairly sure I can sell you a small shell script that you can install
> in the initramfs on those boxes which will do the mount before init is
> started, for say, 10k€?  I'll even make it as a Debian package.

Thats not the point - The point is breaking old assumptions about
Debian beeing a Unixoid OS. It'll cost money somewhere - not necessarily
for me but probably others.

I am just making the point that this is not a lightweight decision which
can be made between 12 and lunch but one which has a lot and complicated
dependencies ...

Flo
-- 
Florian Lohoff f...@rfc822.org
"Es ist ein grobes Missverständnis und eine Fehlwahrnehmung, dem Staat
im Internet Zensur- und Überwachungsabsichten zu unterstellen."
- - Bundesminister Dr. Wolfgang Schäuble -- 10. Juli in Berlin 


signature.asc
Description: Digital signature

Re: RFC: Moving gpg to /bin?

[Gabor Gombas]

On Thu, Sep 03, 2009 at 04:06:53PM +0200, Daniel Leidert wrote:

> > I'm thinking about moving gpg to /bin to solve bugs #386980 and #477671.

That may be a workaround, but IMHO this is really a bug/limitation in
the way the current init scripts are set up.

There is already the "_netdev" flag in fstab to defer mounting some
filesystems after the network has been initialized. There could be a
similar "_cryptdev" tag for encrypted devices. Then the boot process
would look like:

- do the equivalent of "mount -a -O no_netdev,no_cryptdev". /usr
  should be mounted by this step, since it should not contain sensitive
  information, therefore it should not be encrypted, or at least not
  using gpg.
- configure the network
- "mount -a -O _netdev,no_cryptdev"
- unlock encrypted devices (incl. encrypted iSCSI/AoE/etc. devices)
- "mount -a -O _netdev,_cryptdev"

Now the question is when/how to run fsck, but it is already a problem if
you want to have a file system on an LVM device where one of the PVs is
an AoE device, as I've found out the other day...

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Re: udev and /usr

[Florian Lohoff]

On Wed, Sep 02, 2009 at 11:11:31PM +0200, Josselin Mouette wrote:
> Le mercredi 02 septembre 2009 à 22:30 +0200, Florian Lohoff a écrit : 
> > /usr was on seperate filesystems for decades and some 3733t broken by design
> > Desktop utility turns around old Unix paradigms? I dont get it ...
> 
> Since when is udev a desktop utility?

Its not udevs idea to sort out usb/pci ids - Its whatevers consumer like
hal/dbus and co decided to.

udev itself is an essential tool necessary to bring up the machine so 
it has to go into root and not depend on any other filesystem to be there.

Flo
-- 
Florian Lohoff f...@rfc822.org
"Es ist ein grobes Missverständnis und eine Fehlwahrnehmung, dem Staat
im Internet Zensur- und Überwachungsabsichten zu unterstellen."
- - Bundesminister Dr. Wolfgang Schäuble -- 10. Juli in Berlin 


signature.asc
Description: Digital signature

Re: Manually providing popcon data (Was: Future of the s390 port)

[Jakub Wilk]

* Andreas Tille , 2009-09-03, 13:12:

So as long as there is no easy manual way to provide anonymized figures
without installing software on our production servers we can't deliver
such data :-( and yes, I know there are many reasons why a manual upload
form would be a bad idea regarding accuracy and actuality.


What about a popcon-offline package or configuration option of plain
popcon which just generates the content of the mail that is sended to
popcon.debian.org and leave it to the admin to send it manually.


I believe that one can implement (sort of) popcon-offline by setting:

MAILTO=root
USEHTTP=no

in the /etc/popularity-contest.conf file.

--
Jakub Wilk


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

Bug#544890: ITP: ibus-table-easy -- Easy input method based on table engine of ibus

[Asias He]

Package: wnpp
Severity: wishlist
Owner: Asias He 


* Package name: ibus-table-easy
  Version : 1.2.0.20090902
  Upstream Author : Woodman Tuen   Caius 'kaio' Chance < k 
at kaio dot me >
* URL : http://code.google.com/p/ibus/
* License : GPLv2
  Programming Lang: N/A
  Description : Easy input method based on table engine of ibus

 IBus-Table is the IM Engine framework for table-based input methods, such as
 WuBi, ErBi, Cangjie and so on. 
 .
 This package provides one input method: Easy.
 .
 Easy is a Chinese input method. 



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

Bug#544889: ITP: ibus-table-cns11643 -- Cns11643 input method based on table engine of ibus

[Asias He]

Package: wnpp
Severity: wishlist
Owner: Asias He 


* Package name: ibus-table-cns11643
  Version : 1.2.0.20090902
  Upstream Author : Caius 'kaio' Chance < k AT kaio DOT me >
* URL : http://code.google.com/p/ibus/
* License : GPLv2
  Programming Lang: N/A
  Description : Cns11643 input method based on table engine of ibus

 IBus-Table is the IM Engine framework for table-based input methods,
 such as WuBi, ErBi, Cangjie and so on.
 .
 This package provides one input method: Cns11643.
 .
 Cns11643 is a Chinese input method. 



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

Re: Of the use of native packages for programs not specific to Debian.

[Ben Finney]

Charles Plessy  writes:

> Le Thu, Sep 03, 2009 at 12:47:44PM +0200, Wouter Verhelst a écrit :
> > I know it is fancy and modern to think that Debian native packages
> > should only be used for things that are specific to the Debian
> > infrastructure, but there is nothing in policy that requires that,

To be clear (and I know you probably already know this): just because
some practice is not explicitly mentioned in Policy, does not mean there
is no good way to decide whether or not it's good practice.

As far as whether this idea is “modern”, I don't know whether “more than
8 years” is outside that range for an operating system only 16 years
old, but the consensus on this 2001-01 ‘debian-mentors’ thread
http://lists.debian.org/debian-mentors/2001/01/msg00191.html> seems
to be that packages should be native only if the package is specific to
the Debian infrastructure.

> At least one of the consequences of being native is that the package
> gets all its gettext and manpages translations for free from Debian.

Another one is that any change to the Debian packaging for the work
can't be released without bumping the version number of the work, even
when there's no other change in the work other than the Debian
packaging.

-- 
 \  “The manager has personally passed all the water served here.” |
  `\  —hotel, Acapulco |
_o__)  |
Ben Finney


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

Of the use of native packages for programs not specific to Debian.

[Charles Plessy]

Le Thu, Sep 03, 2009 at 12:47:44PM +0200, Wouter Verhelst a écrit :
> 
> I know it is fancy and modern to think that Debian native packages
> should only be used for things that are specific to the Debian
> infrastructure, but there is nothing in policy that requires that, and
> indeed several packages (including, e.g., offlineimap) are distributed
> as such.

Hi Wouter,

At least one of the consequences of being native is that the package gets all
its gettext and manpages translations for free from Debian. In the case of
programs like ikiwiki made by somebody who gave a lot to Debian, it is for sure
a good thing, but in the case when the package maintainer sits on the
translations, like for sbackup, this is clearly a problem.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


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

Re: Where should DLL files go?

[Peter Samuelson]

[Steve Langasek]
> Mm, not exactly.  At build time you use libfoo.so; at runtime you use
> libfoo.so.VER.  It just happens that the ELF version of "stubs" is trivial
> (a symlink).

_Usually_ a symlink ... it doesn't have to be (see /usr/lib/libc.so).  (:


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

Re: Release goal: Getting rid of unneeded *.la / emptying dependency_libs

[Peter Samuelson]

[Paul Wise]
> Summarizing the upstream thread, it seems the solution they prefer is
> to just ignore dependency_libs when linking dynamically.

Sounds good to me.  I can't comment on the Libs/Libs.private split,
except that if Steve is right and this is mostly for Gtk, they're
already pretty married to pkg-config, so I wouldn't think libtool would
have to support this.

Does upstream have a timeline?  After they make the change, how long
before we in Debian can assume our issues are all addressed?  I ask
because most upstreams include a private copy of libtool, and I don't
know if we'd feel as though we need to accommodate that.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


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

Re: RFC: Moving gpg to /bin?

[Daniel Leidert]

Posting to debian-devel too. Please comment.

Am Donnerstag, den 03.09.2009, 11:58 +0200 schrieb Daniel Leidert:

> I'm thinking about moving gpg to /bin to solve bugs #386980 and #477671.
> But this might break scripts and executables, which hardcoded gpg (e.g.
> dput). So what to do? Create a symlink
> 
> /usr/bin/gpg -> /bin/gpg
> 
> as a workaround and file bugs against all packages, which hard-coded the
> path? Or ship the symlink for the next two releases?
> 
> http://bugs.debian.org/386980
> http://bugs.debian.org/477671

Regards, Daniel


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

Re: udev and /usr

[Marc Haber]

On Thu, 03 Sep 2009 13:23:11 +0200, Marc Haber
 wrote:
>On Wed, 2 Sep 2009 22:30:37 +0200, Florian Lohoff 
>wrote:
>>I have ~600 Machines in the field - all with /usr on a seperate fs - If Debian
>>is going to make seperate /usr a no-go its about 30 Euros worth
>>of field Engineer time - swapping disks.
>>
>>/usr was on seperate filesystems for decades and some 3733t broken by design
>>Desktop utility turns around old Unix paradigms? I dont get it ...
>
>Agreed. Pretty please let Debian stay a Unixoid OS, which it isn't any
>more if separate /usr is not supported any more.

See also FHS 3.1 "Purpose". "/usr, /opt, and /var are designed such
that they may be located on other partitions or filesystems."

I do sincerely hope that we're not going to start violating this part
of the FHS.

Greetings
Marc

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


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

Re: udev and /usr

[Marc Haber]

On Wed, 2 Sep 2009 22:30:37 +0200, Florian Lohoff 
wrote:
>I have ~600 Machines in the field - all with /usr on a seperate fs - If Debian
>is going to make seperate /usr a no-go its about 30 Euros worth
>of field Engineer time - swapping disks.
>
>/usr was on seperate filesystems for decades and some 3733t broken by design
>Desktop utility turns around old Unix paradigms? I dont get it ...

Agreed. Pretty please let Debian stay a Unixoid OS, which it isn't any
more if separate /usr is not supported any more.

Greetings
Marc

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


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

Re: udev and /usr

[Giacomo A. Catenazzi]

Josselin Mouette wrote:
Le mercredi 02 septembre 2009 à 22:30 +0200, Florian Lohoff a écrit : 

/usr was on seperate filesystems for decades and some 3733t broken by design
Desktop utility turns around old Unix paradigms? I dont get it ...


Since when is udev a desktop utility?


hmm. udev doesn't requires directly /usr, instead /usr is *maybe* required
by HAL (called by udev). Thus the desktop rant is still valid.

ciao
cate


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

Manually providing popcon data (Was: Future of the s390 port)

[Andreas Tille]

On Thu, Sep 03, 2009 at 11:32:14AM +0200, Martin Grimm wrote:
> So as long as there is no easy manual way to provide anonymized figures
> without installing software on our production servers we can't deliver
> such data :-( and yes, I know there are many reasons why a manual upload
> form would be a bad idea regarding accuracy and actuality.

What about a popcon-offline package or configuration option of plain
popcon which just generates the content of the mail that is sended to
popcon.debian.org and leave it to the admin to send it manually.  You
would be able to verify the content of the file before sending to make
sure there is no information inside you want to be submitted.  I guess
no admin would like to do this manual work on a daily basis, but sending
such a mail say once per month would probably worth the effort to make
sure that the used packages / archs will be continuosely supported in
the future.

I have no idea whether this is useful in the end but it sounds like a
reasonable compromise to me.

We might also consider a way to scp such a popcon datafile to a host
which is able to send mails and let it be sended from there.  This might
be helpful on machines with no means to send mails.

Kind regards

   Andreas.

-- 
http://fam-tille.de
Klarmachen zum Ändern!


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

Re: udev and /usr

[Steve Langasek]

On Thu, Sep 03, 2009 at 12:53:10PM +0200, Tollef Fog Heen wrote:
> ]] Florian Lohoff 

> | I have ~600 Machines in the field - all with /usr on a seperate fs - If 
> Debian
> | is going to make seperate /usr a no-go its about 30 Euros worth
> | of field Engineer time - swapping disks.

> I'm fairly sure I can sell you a small shell script that you can install
> in the initramfs on those boxes which will do the mount before init is
> started, for say, 10k€?  I'll even make it as a Debian package.

That's not the point.  /usr as a separate partition is a use case that's
guaranteed by the FHS, and it's the responsibility of Debian maintainers to
ensure that their packages behave correctly in this scenario.

(Setting aside the question of whether the bug here is a udev bug - there
/may/ be a strong architectural reason why udev needs to be the package
providing this interface, in which case we must, grudgingly, move the ids
files to the root filesystem; either way, the result is that we have a
serious bug in one of these packages now.)

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


signature.asc
Description: Digital signature

Re: trayer_1.1_i386.changes REJECTED

[Emilio Pozuelo Monfort]

Wouter Verhelst wrote:
> I know it is fancy and modern to think that Debian native packages
> should only be used for things that are specific to the Debian
> infrastructure, but there is nothing in policy that requires that, and
> indeed several packages (including, e.g., offlineimap) are distributed
> as such.

Maybe it's time we include such a requirement in the policy?

Emilio



signature.asc
Description: OpenPGP digital signature

Re: Future of the s390 port

[Bastian Blank]

[ Restricting to debian-devel, as generic development stuff ]

On Thu, Sep 03, 2009 at 12:28:27PM +0200, Mike Hommey wrote:
> On Thu, Sep 03, 2009 at 12:16:53PM +0200, Bastian Blank  
> wrote:
> > Okay, this also depends on the condition that you don't consider the
> > package names themself sensitive.
> That could surely grant a wishlist bug for popcon, to allow to, say, only
> report package names that are found in the debian archive.

This information is not available at the moment. You could use apt to
check if the package is _currently_ available in the debian archive up
to some degree.

Bastian

-- 
You!  What PLANET is this!
-- McCoy, "The City on the Edge of Forever", stardate 3134.0


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

Re: udev and /usr

[Tollef Fog Heen]

]] Florian Lohoff 

| I have ~600 Machines in the field - all with /usr on a seperate fs - If Debian
| is going to make seperate /usr a no-go its about 30 Euros worth
| of field Engineer time - swapping disks.

I'm fairly sure I can sell you a small shell script that you can install
in the initramfs on those boxes which will do the mount before init is
started, for say, 10k€?  I'll even make it as a Debian package.

-- 
Tollef Fog Heen, not really serious.
UNIX is user friendly, it's just picky about who its friends are


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

Re: Future of the s390 port

[Bastian Blank]

On Mon, Aug 31, 2009 at 01:01:24PM -0400, Michael Casadevall wrote:
> I think a bigger question is where do you find hardware where you can
> get remote root on;

I know at least two posibilites
- IBM provides access for evaluation purposes and
- OSDL provides access for project work.

Bastian

-- 
A princess should not be afraid -- not with a brave knight to protect her.
-- McCoy, "Shore Leave", stardate 3025.3


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

Re: trayer_1.1_i386.changes REJECTED

[Wouter Verhelst]

On Wed, Sep 02, 2009 at 07:09:01PM +, Sune Vuorela wrote:
> >>From the changelog:
> >
> >   * Upstream has abandoned the program, so the package is now Debian
> > native.
> 
> Switching upstreams does not make a package native.

How so? There is no reason why a package where the upstream and the
Debian Developer are one and the same person could not be native.

I know it is fancy and modern to think that Debian native packages
should only be used for things that are specific to the Debian
infrastructure, but there is nothing in policy that requires that, and
indeed several packages (including, e.g., offlineimap) are distributed
as such.

Of course making a package Debian native can have downsides, and anyone
considering doing so should weigh these downsides against the benefits
that going native may or may not bring them; however, if they choose to
do so, there is no reason for them not to do so. As it should be.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


signature.asc
Description: Digital signature

Re: tigase xmpp server package

[Wouter Verhelst]

Hi,

On Tue, Sep 01, 2009 at 08:43:30PM +0200, Mateusz Fiołka wrote:
> Hi,
> 
> I am on of the Tigase XMPP server developers. Tigase is written purely
> in Java and is meant to be high performing, scalable and extensible.
> Some time ago one of our users contributed deb packages. There is even
> an automatic system which builds these packages automaticaly, there
> are placed in a custom repository.
> 
> My question is: is there any debian develper or package maintainer who
> would be interested in helping me out to include these packages in
> standard debian repository?

The process by which this happens is 'sponsorship', and this happens all
the time. Note that I'm not volunteering to maintain the package at this
time (I have way too much other responsibilities already), but I'd
certainly be willing to help you out in getting stuff ready.

First, the more appropriate mailinglist for this kind of requests is
debian-ment...@lists.debian.org -- CC set; please direct any follow-ups
there.

You basically have three options:
- Maintain the package yourself, through a 'sponsor'. A sponsor is a
  Debian Developer who will look over your package, and either send it
  back to you with comments on what needs to be improved, or upload it
  in your name.
- Ask the person who initially made the packages to do this maintenance.
  They may or may not be working on this already.
- Convince a Debian Developer to do take on maintenance.

The first is the surest way to get the package included in the
distribution, but also the one with the most work (isn't it always). If
you have a package that you think is ready for inclusion into the Debian
archive, then upload it somewhere (including the source package), and
ask on the -mentors mailinglist for someone to review and possibly
upload it. To make sure this doesn't need too many iterations, you may
want to have a look at the 'Debian Policy Manual', at
.

If you don't feel like taking on that work, and the person who initially
made the packages isn't willing to do so either, then filing an 'RFP'
bug (using the command 'reportbug wnpp' with the 'reportbug' package
installed) is the standard and documented way to get the latter.

> Packages may need some testing, but I have been told that they are
> working.

You obviously understand that in order for anyone to upload the package,
they'll need a bit more than 'I have been told that they are working'...

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


signature.asc
Description: Digital signature

Re: Future of the s390 port

[Mike Hommey]

On Thu, Sep 03, 2009 at 12:16:53PM +0200, Bastian Blank  
wrote:
> On Thu, Sep 03, 2009 at 11:32:14AM +0200, Martin Grimm wrote:
> > So as long as there is no easy manual way to provide anonymized figures
> > without installing software on our production servers we can't deliver
> > such data :-(
> 
> Hmm. You could collect the /var/lib/dpkg/status files and do a
> mass submit with the data out of this files. It would lack the usage
> data, but at least shows something.
> 
> Okay, this also depends on the condition that you don't consider the
> package names themself sensitive.

That could surely grant a wishlist bug for popcon, to allow to, say, only
report package names that are found in the debian archive.

Mike


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

Re: Future of the s390 port

[Bastian Blank]

On Thu, Sep 03, 2009 at 11:32:14AM +0200, Martin Grimm wrote:
> So as long as there is no easy manual way to provide anonymized figures
> without installing software on our production servers we can't deliver
> such data :-(

Hmm. You could collect the /var/lib/dpkg/status files and do a
mass submit with the data out of this files. It would lack the usage
data, but at least shows something.

Okay, this also depends on the condition that you don't consider the
package names themself sensitive.

Bastian

-- 
We have phasers, I vote we blast 'em!
-- Bailey, "The Corbomite Maneuver", stardate 1514.2


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

Re: Future of the s390 port

[Martin Grimm]

Am 02.09.2009 20:03 schrieb Petter Reinholdtsen:
> [Martin Grimm]
>> We've currently running 240+ Linux guests on 2 IBM System z10 EC,
>> that's the newest hardware of this kind for those not so familiar
>> with this architecture. 236 of these are running Debian, mostly
>> etch, some still sarge and some lenny. Amongst these are
>> zelenka.debian.org and a build system for security updates.
> 
> One simple way to help a bit which will make it more visible to the
> Debian community at large that the s390 port is used, is to install
> and activate popularity-contest on these machines and thus make sure
> 236 machines show up on http://popcon.debian.org/ > as running
> the s390 port. :)
> 
> At the moment, only 8 machines are reporting to popularity-contest,
> which put s390 in line with hurd-i386, kfreebsd-amd64 and m68k as
> ports with very small user groups.  That number made me and probably
> others believe that very few are using the s390 port - at least until
> your email came along. :)
> 
> Happy hacking,

I'm aware of popcon and as much as I'd appreciate it to see our systems
counted there this will not happen because these are mainly production
systems behind firewalls or in internal networks with no internet access
and I've generally a bad feeling when thinking of software that's
talking to outside systems when there is sensitive data on my server ;-)

So as long as there is no easy manual way to provide anonymized figures
without installing software on our production servers we can't deliver
such data :-( and yes, I know there are many reasons why a manual upload
form would be a bad idea regarding accuracy and actuality.

Greetings,
Martin

-- 
Martin Grimm
Zentrum für Informationsverarbeitung und Informationstechnik
Dienstsitz Bonn
An der Küppe 2
53225 Bonn
Tel.: +49 228 99 680 5298
e-mail: extern.martin.gr...@zivit.de


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

Re: Python2.6 in unstable?

[Stefano Zacchiroli]

On Thu, Sep 03, 2009 at 04:32:10PM +0800, Paul Wise wrote:
> See the recent threads on debian-python, debian-devel and debian-release.

Given that Bastian's post is the first time I've seen the question
posed straight away for the -devel public, can you please summarize an
answer for us?

It would also provide a clear reference material for people that might
wonder about the same in the (near) future.

TIA,
Cheers.

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


signature.asc
Description: Digital signature

Re: Python2.6 in unstable?

[Paul Wise]

On Thu, Sep 3, 2009 at 3:10 PM, Bastian Venthur  wrote:

> will python2.6 enter unstable and eventually next stable or was it
> decided to skip 2.6 and go straight to 3.x some time?
>
> I'm just asking, since 2.6.2 and 3.1.1 seem to be the current production
> versions according to http://python.org/download/ (and 2.6 has features
> I /desperately/ need for my own projects :)

See the recent threads on debian-python, debian-devel and debian-release.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Python2.6 in unstable?

[Bastian Venthur]

Hi List,

will python2.6 enter unstable and eventually next stable or was it
decided to skip 2.6 and go straight to 3.x some time?

I'm just asking, since 2.6.2 and 3.1.1 seem to be the current production
versions according to http://python.org/download/ (and 2.6 has features
I /desperately/ need for my own projects :)


Cheers,

Bastian

-- 
Bastian Venthur  http://venthur.de
Debian Developer venthur at debian org


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