Naming policy for Perl modules (mass bug filing)

[Ansgar Burchardt]

Hi,

the Debian Perl Policy asks for packages for the Foo::Bar module to be
named libfoo-bar-perl [1].  Some packages do not adhere to this scheme:

  opalmod   → libopal-perl
  gnuift-perl   → libgnuift-perl
  perl-mapscript→ libmapscript-perl
  perl-tk   → libtk-perl
  speedy-cgi-perl   → libspeedy-cgi-perl
  exactimage-perl   → libexactimage-perl
  perl-ifeffit  → libifeffit-perl
  rplay-perl→ librplay-perl
  nfqueue-bindings-perl → libnfqueue-perl
  perlmagick→ libimage-magick-perl

(dd-list attached below; the list is based on data from Feb 23 [2])

I believe these modules should be renamed to have a consistent naming
scheme in Debian instead of using a prefix "perl-" or omitting the "lib"
for some packages.

Unless there are objections I will file bugs of severity "normal" in a
few days for these packages.

Regards,
Ansgar

[1] 
http://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html#s-package_names
[2] http://lists.debian.org/debian-perl/2010/02/msg00062.html
Luciano Bello 
   imagemagick (U)

Alan Boudreault 
   mapserver (U)

Pierre Chifflier 
   nfqueue-bindings

Debian GIS Project 
   mapserver

Debian QA Group 
   gnuift
   rplay

ImageMagick Packaging Team 
   imagemagick

Daniel Kobras 
   imagemagick (U)

Francesco Paolo Lovergine 
   mapserver (U)

Ola Lundqvist 
   opalmod

Nelson A. de Oliveira 
   imagemagick (U)

Andreas Putzo 
   mapserver (U)

Bastien Roucariès 
   imagemagick (U)

Michael C. Schultheiss 
   perl-tk (U)

Carlo Segre 
   ifeffit

Jose Carlos Garcia Sogo 
   speedy-cgi-perl

Colin Tuckley 
   perl-tk

Niko Tyni 
   speedy-cgi-perl (U)

Jakub Wilk 
   exactimage

Re: Bug#533708: ITP: libhugetlbfs -- Tools and Library access huge pages of memory

[Frank Lin PIAT]

[re-sending, with proper debian-devel address, sorry for the noise]

Hello Christopher and all,

This ITP was stalled, so I packaged this tool. I am looking for one or
more co-maintainer (read more at the bottom).

On Fri, 2009-06-19 at 15:18 -0700, Simmons, Christopher wrote:
> Package: wnpp
>  
> I wish to work on creating a debian package for libhugetlbfs-2.4

* Package name: libhugetlbfs
  Version : 2.7
  Upstream Authors: Eric B Munson 
  : Adam Litke 
  : David Gibson 
* URL : http://libhugetlbfs.sourceforge.net/
* License : LGPL-2.1
  Programming Lang: C
  Description : Tools and Library access huge pages of memory

::libhugetlbfs::
Description: A library which provides access to huge pages of memory
 libhugetlbfs is a library which provides easy access to huge pages of
 memory. It is a wrapper for the hugetlbfs file system. Applications 
 can use huge pages to fulfill malloc() requests without being
 recompiled by using LD_PRELOAD. Alternatively, applications can be
 linked against libhugetlbfs without source modifications to load BSS
 or BSS, data, and text segments into large pages.

::hugepages::
Description: A set of tools to configure huge pages of memory
 This package contains a number of utilities that will help administrate
 the use of huge pages on your system.  hugeedit modifies binaries to
 set default segment remapping behavior. hugectl sets environment
 variables for using huge pages and then execs the target program.
 hugeadm gives easy access to huge page pool size control. pagesize
 lists page sizes available on the machine.


My current work is available from:
 http://git.debian.org/?p=collab-maint/libhugetlbfs.git


Co-maintainer wanted

I am looking for a co-maintainer for this package. There are two reasons
for that: 1) I can't write C, well not really.  2) I believe that every
package should be co-maintained (in a perfect world anyway).

You should be prepared to handle all the aspects of the packaging which
are specific to C and/or library handling. I can help for other aspects
of packaging, bug handling, backporting patches, etc...

Current Lintian :
> P: libhuge*: no-upstream-changelog
> W: libhugetlbfs*: shlib-without-versioned-soname ...
> E: libhugetlbfs: postinst-must-call-ldconfig 

Regards,

Franklin



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1269330984.3587.23.ca...@solid.paris.klabs.be

Group for hugepages / libhugetlbfs

[Frank Lin PIAT]

[re-sending, with proper debian-devel address, sorry for the noise]

Hello,

On Tue, 2010-03-23 at 01:20 +0100, Frank Lin PIAT wrote:
> This ITP was stalled, so I packaged this tool...
> 
> * Package name: libhugetlbfs
>   Description : Tools and Library access huge pages of memory
> 
> ::hugepages::
> Description: A set of tools to configure huge pages of memory
>  This package contains a number of utilities that will help administrate
>  the use of huge pages on your system. hugeedit modifies binaries to
>  set default segment remapping behavior. hugectl sets environment
>  variables for using huge pages and then execs the target program.
>  hugeadm gives easy access to huge page pool size control. pagesize
>  lists page sizes available on the machine.

I would like some advices on how to handle group for granting permission
to use HugePage/HugeTlbFs. I wonder If I should request a fixed GID...

That group can be used in the following places:

 1. Sysctl's  vm.hugetlb_shm_group = GIDNUMBER
 2. hugetlbfs mount-points permissions
 3. /etc/security/limits.conf's memlock

For #2 and #3, it is possible to use the group name. But unfortunately,
sysctl only accept GID number.

Is this reason sufficient to request a fixed GID? Alternatively, we
could use an init script to do the conversion. I don't like that option
very much, because I think it would be better to let /etc/sysctl handle
it.

What do you think about it?

Franklin


[1] http://wiki.debian.org/Hugepages



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1269331457.3587.55.ca...@solid.paris.klabs.be

Re: Processed: ipv6 release goal

[Petter Reinholdtsen]

[Ben Hutchings]
> "ipv6
> This bug affects support for Internet Protocol version 6."
>
> This is *not* the same as the release goal, which is about fixing
> networking programs that don't support IPv6 at all.  Many of these bugs
> should not be release-critical.

How is it different from the release goal?  Release goal bugs are not
necessarily release-critical (it is a goal, not a requirement) so I do
not understand your comment at all.

And the ipv6 goal is as far as I understand it about fixing all Debian
packages to work properly with ipv6, not just network programs,
whatever that is.

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2fld3yva1s3@login2.uio.no

Re: Processed: ipv6 release goal

[Colin Watson]

On Tue, Mar 23, 2010 at 09:19:08AM +0100, Petter Reinholdtsen wrote:
> [Ben Hutchings]
> > "ipv6
> > This bug affects support for Internet Protocol version 6."
> >
> > This is *not* the same as the release goal, which is about fixing
> > networking programs that don't support IPv6 at all.  Many of these bugs
> > should not be release-critical.
> 
> How is it different from the release goal?  Release goal bugs are not
> necessarily release-critical (it is a goal, not a requirement) so I do
> not understand your comment at all.

Ben is replying to a BTS notification that many of these bugs were
upgraded to severity 'serious' by Clint Adams.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100323085723.ga28...@master.debian.org

Re: Naming policy for Perl modules (mass bug filing)

[Bastien ROUCARIES]

2010/3/23 Ansgar Burchardt :
> Hi,
>
> the Debian Perl Policy asks for packages for the Foo::Bar module to be
> named libfoo-bar-perl [1].  Some packages do not adhere to this scheme:
>
>  opalmod               → libopal-perl
>  gnuift-perl           → libgnuift-perl
>  perl-mapscript        → libmapscript-perl
>  perl-tk               → libtk-perl
>  speedy-cgi-perl       → libspeedy-cgi-perl
>  exactimage-perl       → libexactimage-perl
>  perl-ifeffit          → libifeffit-perl
>  rplay-perl            → librplay-perl
>  nfqueue-bindings-perl → libnfqueue-perl
>  perlmagick            → libimage-magick-perl

In this case perlmagick is the upstream name, but we could create an
empty package  libimage-magick-perl that will depend on  perlmagick ,
or the reverse if needed, but thename perlmagick should be kept due to
upstream naming [1].

[1] http://www.imagemagick.org/script/perl-magick.php

Bastien


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/195c7a901003230147u22d479abxa7889a98e9e63...@mail.gmail.com

Re: Bug#533708: ITP: libhugetlbfs -- Tools and Library access huge pages of memory

[Colin Watson]

On Tue, Mar 23, 2010 at 02:14:51AM +0100, Frank Lin PIAT wrote:
> On Tue, 2010-03-23 at 01:20 +0100, Frank Lin PIAT wrote:
> > This ITP was stalled, so I packaged this tool...
> > 
> > * Package name: libhugetlbfs
> >   Description : Tools and Library access huge pages of memory
> > 
> > ::hugepages::
> > Description: A set of tools to configure huge pages of memory
> >  This package contains a number of utilities that will help administrate
> >  the use of huge pages on your system.  hugeedit modifies binaries to
> >  set default segment remapping behavior. hugectl sets environment
> >  variables for using huge pages and then execs the target program.
> >  hugeadm gives easy access to huge page pool size control. pagesize
> >  lists page sizes available on the machine.
> 
> I would like some advice regarding HugePage/HugeTlbFs. I wonder If I
> should request a fixed GID...
> 
> To grant a user the right to use hugepages, that user have to be in a
> group that can be used in one or more of :
> 
> 1. hugetlbfs mountpoints permission
> 2. Sysctl's  vm.hugetlb_shm_group = GIDNUMBER
> 3. /etc/security/limits.conf's memlock
> 
> For #1 and #3, it is possible to use the group name. But unfortunately,
> sysctl only accept GID number.
> 
> Is it sufficient reason to request a fixed GID? Alternatively, we could
> use an init script to do the conversion. I don't like that option very
> much, because I think it would be better to let /etc/sysctl handle it.

As base-passwd maintainer, this is in principle sufficient reason for a
fixed GID. However, I'm concerned about the management procedures and
wouldn't want to allocate a GID before it's clear that this has been
thought through properly.

Who should be able to use huge pages?  What basis should a system
administrator use to determine who should be added to this group?  We
need to work this out *before* adding the group.  I have to say that a
group feels like a very odd way to manage this to me - surely this is
more like what we traditionally manage using resource limits, which
might be associated with groups but might also be associated with other
properties of PAM sessions or with particular applications?  I know
there's some mention of resource limits in the wiki page you cited, but
it seems to be secondary to the ability to create files in this virtual
filesystem.

Normally, I would not allocate any new entries in the global static
range (0-99) without an extraordinarily good overriding reason.  An
entry in the static on-demand range (6-64999) would be more usual,
but requires a package to own it and actually create the group using
addgroup.  Doing this in a run-time library package is problematic
because what if its SONAME changes?  If at all possible, I would prefer
it if any package owning such a group has a stable name and is one
you're prepared to say will stick around for a long time.

I think that the mount point should be handled dynamically, in a new
init script or perhaps even in mountkernfs (or mountdevsubfs if you
decide to put the mount point under /dev), rather than by requiring
everyone who wants to use this to edit /etc/fstab.  (This seems to be
partially covered by #572733.)

(You could of course work around my objections by using a dynamic GID
and an init script, but I agree with you that that is not so desirable.)

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100323085637.gg4...@riva.ucam.org

Re: Processed: ipv6 release goal

[Hendrik Sattler]

Zitat von Ben Hutchings :


"ipv6
This bug affects support for Internet Protocol version 6."

This is *not* the same as the release goal, which is about fixing
networking programs that don't support IPv6 at all.  Many of these bugs
should not be release-critical.


Context? Can you make your post a bit less brief? Where does the  
citation comes from?


HS



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100323093559.6gqgmi314wscc...@v1539.ncsrv.de

Re: Naming policy for Perl modules (mass bug filing)

[Philipp Kern]

["Followup-To:" header set to gmane.linux.debian.devel.general.]
On 2010-03-23, Jozef Kutej  wrote:
> what should be the motivation and reasoning for spending time on this task? as
> it will require change on the package it self, all the packages that have it 
> as
> dependency, plus an transition effort in order to make the upgrades work
> properly. can you list the benefits?

It's consistent.  I'm always annoyed when looking for a Perl package that
apt-cache search lib-perl doesn't turn up something but another
search phrase might have.

(Hint:  isn't always unique among the packages.)

Kind regards,
Philipp Kern


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnhqh3qp.7qc.tr...@kelgar.0x539.de

Re: Naming policy for Perl modules (mass bug filing)

[Jozef Kutej]

Ansgar Burchardt wrote:
> the Debian Perl Policy asks for packages for the Foo::Bar module to be

Perl module packages *should* be named... :)

> I believe these modules should be renamed to have a consistent naming
> scheme in Debian instead of using a prefix "perl-" or omitting the "lib"
> for some packages.

what should be the motivation and reasoning for spending time on this task? as
it will require change on the package it self, all the packages that have it as
dependency, plus an transition effort in order to make the upgrades work
properly. can you list the benefits?

> Unless there are objections I will file bugs of severity "normal" in a
> few days for these packages.

if, then a wishlist would be better. there are still functional bugs [1] that
need a people having some free time...

Cheers,
Jozef


[1] http://pkg-perl.alioth.debian.org/cgi-bin/pet.cgi


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

Re: definition of contrib & buildd inconsistency

[Marc 'HE' Brockschmidt]

Carlo Segre  writes:
> On Mon, 22 Mar 2010, Marc 'HE' Brockschmidt wrote:
>> We are currently reworking the non-free support in the buildd
>> network. In the long term, we want to be able to build whitelisted
>> packages, and allow contrib packages to use binaries built from
>> whitelisted package. This is not done yet, but people (more
>> specifically, Andreas Barth) are working on it.
> Thanks for the information.  Do you have any notion about when this
> might be completed?

No, sorry.

Marc
-- 
BOFH #310:
asynchronous inode failure


pgpAZ3rDSkaGh.pgp
Description: PGP signature

Re: Who is running non-free autobuilders

[Marc 'HE' Brockschmidt]

Michael Hanke  writes:
> since a while I try to figure out why a package is not being auto-built.
> I was suggested to contact the "team that runs the non-free
> autobuilders". However, I have trouble finding that team. Whom could I
> contact -- neither google nor the wiki seems to know about them.

Currently, noone is running the non-free autobuilder because we have
none. In the long run, this will be integrated into the usual Debian
infrastructure, but this hasn't happened yet.

Marc
-- 
BOFH #219:
Recursivity.  Call back if it happens again.


pgpA85MWeFHVr.pgp
Description: PGP signature

Re: Bug#540215: Introduce dh_checksums

[Wouter Verhelst]

On Sat, Mar 20, 2010 at 01:27:52PM +0100, Harald Braumann wrote:
> On Fri, Mar 19, 2010 at 05:56:40PM -0700, Russ Allbery wrote:
> > Harald Braumann  writes:
> > > On Thu, Mar 18, 2010 at 04:52:07PM -0700, Russ Allbery wrote:
> > 
> > >> You add an additional ar member that contains the signed checksums of
> > >> all of the files in data.tar.gz, possibly another additional member
> > >> that contains the signed checksums for control.tar.gz, or you document
> > >> some convention so that you can combine both into the same signed
> > >> checksum document.
> > 
> > > Wouldn't it be simpler to just extract *sums from control.tar.gz, create
> > > a detached signature for it and put it in the ar archive, instead of
> > > extracting data.tar.gz and generating the sums a second time? Or would
> > > this replace dh_*sums during package build time?
> > 
> > I think it would replace dh_*sums during package build time and make
> > obsolete including md5sums in the control.tar.gz.  You don't really want
> > the signature and checksums to be inside one of the other data members
> > since that breaks, as Wouter points out, the ability to remove the
> > signature and checksums and verify against the original *.changes file.
> > And there's no need to include two copies of the checksums.
> 
> There would only be one additional file, containing a detached
> signature for the checksum file. No duplication of checksums and it
> can easily be removed from the ar. But doing everything in one step,
> like you proposed, is better anyway.

Yes, agreed; detached signatures are probably better, since they would
allow for multiple signatures without the requirement of having several
copies of the checksums file in the .deb. What's more, if the checksums
are still in the control.tar.gz, this would provide some level of
backwards compatibility with a version of dpkg that doesn't support the
detached signatures yet (i.e., a package installed with that version
would still have the checksums on disk, though not the signatures).

Since I haven't seen any input from the dpkg developers to this thread
(-dpkg Cc'ed for their benefit), and since we seem to have hammered out
a proposal that would involve some change to dpkg, let me summarize the
proposal and ask for their input.

The idea would be to provide a path from a binary on disk to a GPG
signature for installed packages of which the user no longer has the
.deb file from which it was originally installed, nor the Packages
and/or Release.gpg file that was used to download it.

The proposal as it currently stands would be that:
- md5sums are phased out in favour of a more generic 'checksums' file
  that would use a more secure hash algorithm than MD5 (one of the SHA*
  family of hashes would probably do at the moment).
- When asked to sign a .deb file, dpkg(-deb) would extract the checksums
  data member from control.tar.gz, create a detached signature for that
  file, and store it as an additional data member in that .deb.

The benefits of this method as opposed to storing the signature in the
control.tar.gz file would be:
- Autobuilders would not need to be modified to support signed packages.
- Adding a member to an ar file and removing it again later can be done
  in a way which is idempotent; the same is not true for modifying a tar
  file. As such, it is trivially possible to remove signatures from a
  .deb file to allow its verification against the original .changes file
  that was used for its upload, should this at any point be necessary
- If adding multiple signatures is possible in a way which does not
  modify the contents of the .deb file itself, then the archive-wide key
  could in theory be used to sign individual .deb files. While a massive
  increase of CPU power on ftp-master.d.o would be needed to support
  this, it would allow for easier key management on the end-user end.
- It would not break backwards compatibility. I tried this, by manually
  adding a file "signature_01.asc" to a .deb file; dpkg was still able
  to install this package, it just ignored the unknown file.

If we're going to sign .deb files, then it would make sense to also sign
the metadata and maintainer scripts in the control.tar.gz file. Doing
this would require some way to clarify the difference between data in
control.tar.gz and data in data.tar.gz; current suggestions are to
either use a prefix (something like CONTROL:preinst, for instance) or to
use the path of the binary-as-installed (wherein the above would become
"/var/lib/dpkg/info/.preinst"). There aren't any strong
feelings towards one or the other, however.

What's the opinion of the dpkg maintainers on this?

-- 
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: Naming policy for Perl modules (mass bug filing)

[Petter Reinholdtsen]

[Philipp Kern]
> It's consistent.  I'm always annoyed when looking for a Perl package that
> apt-cache search lib-perl doesn't turn up something but another
> search phrase might have.

I normally use 'apt-cache serach perl|grep -i ', and it almost
always give me a useful result.  I suspect it is less work for more
gain if we change the way you do searches instead of spending a lot of
time renaming packages for dubious gain.

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2fl8w9jfiex@login1.uio.no

Bug#575075: ITP: aaphoto -- Auto Adjust Photo, automatic color correction of photos

[Andras Horvath]

Package: wnpp
Severity: wishlist
Owner: Andras Horvath 


* Package name: aaphoto
  Version : 0.36-1
  Upstream Author : Andras Horvath 
* URL : http://log69.com/aaphoto_en.html
* License : GPLv3
  Programming Lang: C
  Description : Auto Adjust Photo, automatic color correction of photos

Auto Adjust Photo is a tiny command-line image manipulation
tool for automatic color correction of photos. It tries to
make the picture look better. The program does this by
analyzing the input image and then sets the most optimal
contrast, gamma, color balance and saturation for it.

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



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100323100131.16369.53689.report...@dell.andras

Re: Bug#533708: ITP: libhugetlbfs -- Tools and Library access huge pages of memory

[Vincent Danjean]

On 23/03/2010 09:57, Colin Watson wrote:
> Who should be able to use huge pages?  What basis should a system
> administrator use to determine who should be added to this group?

To start, I see two use cases:
- developers/researchers, in particular in HPC field that needs to
  be able to efficiently use the memory
  => some users need to have access to huge pages
- HPC applications
  => some applications need to have access to huge pages

  Regards,
Vincent

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


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

Re: Who is running non-free autobuilders

[Michael Hanke]

On Tue, Mar 23, 2010 at 11:20:07AM +0100, Marc 'HE' Brockschmidt wrote:
> Michael Hanke  writes:
> > since a while I try to figure out why a package is not being auto-built.
> > I was suggested to contact the "team that runs the non-free
> > autobuilders". However, I have trouble finding that team. Whom could I
> > contact -- neither google nor the wiki seems to know about them.
> 
> Currently, noone is running the non-free autobuilder because we have
> none. In the long run, this will be integrated into the usual Debian
> infrastructure, but this hasn't happened yet.

Thanks for this information.

Michael

-- 
GPG key:  1024D/3144BE0F Michael Hanke
http://mih.voxindeserto.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100323110941.ga17...@meiner

Re: Bug#533708: ITP: libhugetlbfs -- Tools and Library access huge pages of memory

[Marco d'Itri]

On Mar 23, Colin Watson  wrote:

> Who should be able to use huge pages?  What basis should a system
KVM, Oracle.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Processed: ipv6 release goal

[Felipe Augusto van de Wiel (faw)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 23-03-2010 05:35, Hendrik Sattler wrote:
> Zitat von Ben Hutchings :
> 
>> "ipv6
>> This bug affects support for Internet Protocol version 6."
>>
>> This is *not* the same as the release goal, which is about fixing
>> networking programs that don't support IPv6 at all.  Many of these bugs
>> should not be release-critical.
> 
> Context? 

As pointed by Colin:

| Ben is replying to a BTS notification that many of these bugs were
| upgraded to severity 'serious' by Clint Adams.



> Can you make your post a bit less brief? Where does the
> citation comes from?

http://www.debian.org/Bugs/Developer#tags

Kind regards,
- -- 
Felipe Augusto van de Wiel (faw)
Debian. Freedom to code. Code to freedom!
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuoq1wACgkQCjAO0JDlykYYZACgwG2f1PNouPmHiyU6ualgEZIO
P+cAnRyxNpc3iplfDaBWviv1cds/cM3Q
=cJ7G
-END PGP SIGNATURE-


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

Re: Processed: ipv6 release goal

[Hendrik Sattler]

Zitat von "Felipe Augusto van de Wiel (faw)" :


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 23-03-2010 05:35, Hendrik Sattler wrote:

Zitat von Ben Hutchings :


"ipv6
This bug affects support for Internet Protocol version 6."

This is *not* the same as the release goal, which is about fixing
networking programs that don't support IPv6 at all.  Many of these bugs
should not be release-critical.


Context?


As pointed by Colin:

| Ben is replying to a BTS notification that many of these bugs were
| upgraded to severity 'serious' by Clint Adams.


Thanks.


Can you make your post a bit less brief? Where does the
citation comes from?


http://www.debian.org/Bugs/Developer#tags


BTW: How can I force that page to _not_ use the "preferred language"  
of the browser? Having to change that in the firefox/iceweasel  
settings every time is a bit... weird.


HS



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100323133351.ldsshmdvs404g...@v1539.ncsrv.de

Re: Processed: ipv6 release goal

[Paul Wise]

On Tue, Mar 23, 2010 at 8:33 PM, Hendrik Sattler
 wrote:

> BTW: How can I force that page to _not_ use the "preferred language" of the
> browser? Having to change that in the firefox/iceweasel settings every time
> is a bit... weird.

That is a feature, not a bug. Why is your preferred language set
incorrectly in the first place? Unfortunately respecting the
Accept-Language HTTP header is less and less common for web
applications these days, mapping IP addresses to languages through
GeoIP is more common and extremely annoying.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/e13a36b31003230555g138965dcpcdf9021fdb13d...@mail.gmail.com

Re: Processed: ipv6 release goal

[Mike Hommey]

On Tue, Mar 23, 2010 at 08:55:09PM +0800, Paul Wise wrote:
> On Tue, Mar 23, 2010 at 8:33 PM, Hendrik Sattler
>  wrote:
> 
> > BTW: How can I force that page to _not_ use the "preferred language" of the
> > browser? Having to change that in the firefox/iceweasel settings every time
> > is a bit... weird.
> 
> That is a feature, not a bug. Why is your preferred language set
> incorrectly in the first place? Unfortunately respecting the
> Accept-Language HTTP header is less and less common for web
> applications these days, mapping IP addresses to languages through
> GeoIP is more common and extremely annoying.

There is one annoying misfeature of content negotiation, though. If you
follow one of the language links at the bottom of the, say, english page, and
then follow a link within the translated page, you are back to english.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100323130506.ga13...@glandium.org

Re: Processed: ipv6 release goal

[Hendrik Sattler]

Zitat von Hendrik Sattler :

http://www.debian.org/Bugs/Developer#tags


BTW: How can I force that page to _not_ use the "preferred language" of
the browser? Having to change that in the firefox/iceweasel settings
every time is a bit... weird.


Ups. Should have scrolled all the way down :-/

HS



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100323135635.5ac1y3iigwkgo...@v1539.ncsrv.de

Re: Naming policy for Perl modules (mass bug filing)

[Ansgar Burchardt]

Jozef Kutej  writes:

> Ansgar Burchardt wrote:
>> the Debian Perl Policy asks for packages for the Foo::Bar module to be
> Perl module packages *should* be named... :)

  "Non-conformance with guidelines denoted by should (or recommended)
  will generally be considered a bug, but will not necessarily render a
  package unsuitable for distribution."

I don't object to naming packages differently if there is a reason to do
so, but fail to see one for these packages (except for perlmagick which
is also the upstream name as noted by Bastien ROUCARIES [1]).

[1] http://lists.debian.org/debian-devel/2010/03/msg00706.html

>> I believe these modules should be renamed to have a consistent naming
>> scheme in Debian instead of using a prefix "perl-" or omitting the "lib"
>> for some packages.
>
> what should be the motivation and reasoning for spending time on this
> task? as it will require change on the package it self, all the
> packages that have it as dependency, plus an transition effort in
> order to make the upgrades work properly. can you list the benefits?

 · Consistency.  I like to find packages with a name I would expect.
   Charles Plessy [2] and Philipp Kern [3] seem to agree with this.

 · A good example.  When packages that do not live in the Debian
   archive do not adhere to the naming policy are installed, there
   are problems when Debian introduces the same Perl module [4].
   This was the reason I started looking for these packages.
   (I know that already existing packages will not cause this problem,
but they should be a good example for other people.)

[2] http://lists.debian.org/debian-perl/2010/02/msg00074.html
[3] http://lists.debian.org/debian-devel/2010/03/msg00709.html
[4] http://lists.debian.org/debian-perl/2010/02/msg00055.html

>> Unless there are objections I will file bugs of severity "normal" in a
>> few days for these packages.
>
> if, then a wishlist would be better. there are still functional bugs
> [1] that need a people having some free time...
>
> [1] http://pkg-perl.alioth.debian.org/cgi-bin/pet.cgi

I'm fine with that priority as well.  It is not really urgent after all.
And I know the PET page quite well...

Regards,
Ansgar


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

Re: Naming policy for Perl modules (mass bug filing)

[Jonas Smedegaard]

On Tue, Mar 23, 2010 at 10:04:58PM +0900, Ansgar Burchardt wrote:

Jozef Kutej  writes:


Ansgar Burchardt wrote:

the Debian Perl Policy asks for packages for the Foo::Bar module to be

Perl module packages *should* be named... :)


 "Non-conformance with guidelines denoted by should (or recommended)
 will generally be considered a bug, but will not necessarily render a
 package unsuitable for distribution."

I don't object to naming packages differently if there is a reason to do
so, but fail to see one for these packages (except for perlmagick which
is also the upstream name as noted by Bastien ROUCARIES [1]).

[1] http://lists.debian.org/debian-devel/2010/03/msg00706.html


What is so special about Perlmagick?  I do not know of *any* upstream 
project named lib*-perl, so same argument would be true for most Perl 
module packages, I believe.



 - Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: Bug#547079: login: Should set the iutf8 tty c_iflag if the locale is utf8

[Nicolas François]

tags #539354 help
thanks

Hello,

As I have no clue about TTY setup, let see if I can get some other
opinions on debian-devel.

The question raised on http://bugs.debian.org/547079 is who shall be
responsible for setting up the user's tty (e.g. regarding UTF-8 handling).

Some defaults are in the kernel.
getty makes some changes, login also, and the end user may also do so in a
user profile script.

The kernel, getty, or login do not really know if the user wants a UTF-8
locale, so my preference would be to move the setup of the iutf8 tty
c_iflag to the user's configuration.  For example the user could use
unicode_start / unicode_stop.

(This also has the advantage for me not to require any change in login)


The bug discusses also these alternatives:
 2 iutf8 tty c_iflag forced by getty (maybe based on an option in inittab)
   (currently getty always drop this flag)
 3 iutf8 tty c_iflag forced by login
   (I did not really understand how login shall guess when this shall be
   done, maybe an option in /etc/login.defs)
 4 iutf8 tty c_iflag forced by a PAM module

Do you have any opinion on how this should be done?

Thanks in advance,
-- 
Nekral

On Thu, Sep 17, 2009 at 08:35:16PM -0400, Mike Frysinger wrote:
> On Thursday 17 September 2009 19:59:14 Samuel Thibault wrote:
> > Mike Frysinger, le Thu 17 Sep 2009 19:30:02 -0400, a écrit :
> > > > > login/pam are there to do authentication only, not screw with the
> > > > > terminal.
> > > >
> > > > Login already does screw with the terminal in setup_tty(),
> > >
> > > presumably enough to prevent echoing of the password, but that's about it
> > > (for obvious security reasons).
> > 
> > Have you looked at the code before saying that?
> > 
> > /*
> >  * Add your favorite terminal modes here ...
> >  */
> > termio.c_lflag |= ISIG | ICANON | ECHO | ECHOE;
> > termio.c_iflag |= ICRNL;
> > 
> > etc...
> 
> looks like a lot of stuff login shouldnt be doing, but historically has been 
> so no one complained because "it worked".  extending poor behavior because 
> it's already there isnt really a good line of reasoning.
> 
> > > i dont have a fedora box myself, but from talking to a friend, things
> > > "just work" in the default setup. or at least it defaults everything
> > > to unicode.
> > 
> > Did he check whether stty -a properly shows iutf8?  Things work very
> > fine even without it, one of the very few effects of iutf8 left cleared
> > is the bug I mentioned in my report: canonical mode's treatment of
> > backspace.  People rarely notice it.
> 
> i didnt ask him "hey does your keyboard work", i asked him what his settings 
> were after he logged in.  so of course i validated the stty output.
> 
> i'm not suggesting everything is great and nothing needs to be changed.  i'm 
> saying that login/pam is not really part of the solution.
> -mike



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100323140951.ga9...@nekral.nekral.homelinux.net

Re: Processed: ipv6 release goal

[Hendrik Sattler]

Zitat von Paul Wise :


On Tue, Mar 23, 2010 at 8:33 PM, Hendrik Sattler
 wrote:


BTW: How can I force that page to _not_ use the "preferred language" of the
browser? Having to change that in the firefox/iceweasel settings every time
is a bit... weird.


That is a feature, not a bug. Why is your preferred language set
incorrectly in the first place? Unfortunately respecting the
Accept-Language HTTP header is less and less common for web
applications these days, mapping IP addresses to languages through
GeoIP is more common and extremely annoying.


Actually, it is (set to German). However, I do not always want to see  
a translated page. Nothing that any solution can get right (as for a  
computer, the choice is rather random), be it content negotiation or  
geoip.

Already found it anyway :)

HS



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100323151457.2l7dztujy8scs...@v1539.ncsrv.de

Re: Bug#547079: login: Should set the iutf8 tty c_iflag if the locale is utf8

[Petter Reinholdtsen]

[Nicolas François]
> As I have no clue about TTY setup, let see if I can get some other
> opinions on debian-devel.
>
> The question raised on http://bugs.debian.org/547079 is who shall be
> responsible for setting up the user's tty (e.g. regarding UTF-8 handling).

This sound related to http://bugs.debian.org/547073 >, fixed in
sysvinit. in version 2.87dsf-7.  Init now leave it to the kernel to
set the utf-8 flag.  Perhaps login should do the same?

I do not know much about TTY setup myself, so I do not have much to
say on the topic. :)

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2fl39zrf6q5@login1.uio.no

Preparing a Debian "e500" port/derivative (ABI-incompatible PowerPC variant)

[Moffett, Kyle D]

Hello,

I am currently preparing a Debian port to the "e500" architecture for my
employer eXMeritus, a subdivision of Boeing.  The "e500" architecture is an
architecturally-incompatible variant of PowerPC sponsored by IBM and
FreeScale, used in several of FreeScale's high-end embedded networking
processors (also known as MPC85xx).  The Debian bugreport below indicates
that there's at least one other developer currently trying to use Debian on
e500-based systems:
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=568123
  http://download.breakpoint.cc/debian/linutronix-lenny-gnuspe/

We are building some very high-end specialty embedded hardware using these
processors, although there are a number of affordable development boards
available for others interested in the CPUs.

The specific GNU triplet for this architecture is "powerpc-linux-gnuspe".
Like the ARM EABI port (arm-linux-gnueabi) the naming seems unfortunate
here; an architecture triplet such as "powerpcspe-linux-gnu" or
"e500-linux-gnu" would have been far more appropriate.

At this time I'm not sure if there would be any interest in this port from
the rest of the community, as the e500 is a relatively obscure architecture.
On the other hand, as the port uses almost exactly the same codebase as the
"powerpc" architecture incidental package breakage should be unlikely.

Regardless, we certainly plan to submit the few e500-relevant patches (just
eglibc and gcc at present) and make a general buildd and archive available
within a month or so.  For our specific embedded system, we will also be
publishing additional sets of patched-and-hardened Debian packages as we
move closer to an actual final release.

So my questions for the community:

  * Are there any immediate recommendations or cautions regarding a new
architecture port?

  * Where can I find the latest-and-greatest Debian buildd and archive
software?  There seems to be one version in the archives and several others
running around on the internet.  As far as I can tell the 3 I have tried
have all been miserably buggy and/or undocumented.  Internally we are using
the python-based "rebuildd" as a build server and "reprepro" for repository
hosting right now; they seem to work moderately well after some fiddling.

  * Are there any ready-made configurations available for using "icecc" or
"distcc" to distribute load from an embedded Debian buildd/rebuildd to
several amd64 build servers with cross-compilers?

  * Is there potentially general interest in an e500 port?  My employer
might be able to provide long-term buildd and porter systems; unfortunately
we would probably need to maintain physical ownership and control over the
computers themselves.

  * Regarding software security updates, I am aware that most vendors of OS
distributions participate in coordinated-disclosure and embargo agreements
in order to receive advance notice of certain vulnerabilities.  My employer
is currently considering what we would need to do in order to get access to
those notifications; on the other hand we would much rather participate
directly in the Debian security release process.  Would it be possible for
us as a third-party corporation to be a part of that process?

  * Even if an e500 port does not go upstream, would it be possible to get
the appropriate entries added to the upstream dpkg cpu and triplet tables?
We're using a simple 10-line patch to dpkg locally, hopefully that would be
acceptable?


Your advice, comments, and criticism are highly appreciated!

Cheers,
Kyle Moffett

-- 
Kyle Moffett
kyle.d.moff...@boeing.com
eXMeritus Software
Integrated Intelligence
The Boeing Company
http://www.exmeritus.com/


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/c7ce5272.7f63%kyle.d.moff...@boeing.com

Re: Bug#547079: login: Should set the iutf8 tty c_iflag if the locale is utf8

[Samuel Thibault]

Petter Reinholdtsen, le Tue 23 Mar 2010 15:33:22 +0100, a écrit :
> 
> [Nicolas François]
> > As I have no clue about TTY setup, let see if I can get some other
> > opinions on debian-devel.
> >
> > The question raised on http://bugs.debian.org/547079 is who shall be
> > responsible for setting up the user's tty (e.g. regarding UTF-8 handling).
> 
> This sound related to http://bugs.debian.org/547073 >, fixed in
> sysvinit. in version 2.87dsf-7.  Init now leave it to the kernel to
> set the utf-8 flag.  Perhaps login should do the same?

See my concern in the bug report:

“My concern is that getty used to not keep any flag at all.  Keeping
_some_ flags contrary to none is not just a "fix", it's a change of
behavior.  Think for instance about a situation where a user clears
the tty's iutf8.  The next user to log in will have a bogus terminal
since getty would leave it cleared and nothing else will set it.  This
is the same for all the flags, getty could just keep the kernel's
current state, but it doesn't. [...] Letting a user break another user's
environment is wrong”

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100323161842.ga5...@const.bordeaux.inria.fr

Re: Preparing a Debian "e500" port/derivative (ABI-incompatible PowerPC variant)

[Luca Bruno]

Moffett, Kyle D scrisse:

> I am currently preparing a Debian port to the "e500" architecture for
> my employer eXMeritus, a subdivision of Boeing.
[...]
>   * Are there any immediate recommendations or cautions regarding a
> new architecture port?
 
You may be interested in http://www.debian-ports.org/

For the other specific questions, if you get no answer you'd better
address them directly to the relevant teams (ie. security,
dpkg, buildd and such).

Cheers, Luca

-- 
 .''`.  ** Debian GNU/Linux **  | Luca Bruno (kaeso)
: :'  :   The Universal O.S.| lucab (AT) debian.org
`. `'`  | GPG Key ID: 3BFB9FB3
  `- http://www.debian.org  | Debian GNU/Linux Developer


pgpFUpGtDahn5.pgp
Description: PGP signature

Re: Naming policy for Perl modules (mass bug filing)

[gregor herrmann]

On Tue, 23 Mar 2010 22:04:58 +0900, Ansgar Burchardt wrote:

> > can you list the benefits?
>  · Consistency.  I like to find packages with a name I would expect.
>Charles Plessy [2] and Philipp Kern [3] seem to agree with this.

Count me in.
A consistent schema is easier for searching, for downloading
(source|binary) package, for finding a package's bugs or PTS page,
for "blindly" adding dependencies ...
 
> > if, then a wishlist would be better. there are still functional bugs
> > [1] that need a people having some free time...
> I'm fine with that priority as well.  It is not really urgent after all.

I agree that fixing "real" (especially RC) bugs is more important but
nevertheless I'm in favour of filing bugs asking for a renaming of
the packages in question.

Cheers,
gregor
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG Key IDs: 0x8649AA06, 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: Peter Jones: Belle


signature.asc
Description: Digital signature

Re: Preparing a Debian "e500" port/derivative (ABI-incompatible PowerPC variant)

[Moffett, Kyle D]

[Note: I'm not authorized to speak "on behalf of" my employer, but this
 represents (to the best of my knowledge) our current plans and goals]

Please maintain the CC list, all of us here at eXMeritus are interested in
comments and advice.

On 2010/03/23 13:40, "Moritz Muehlenhoff"  wrote:
> On 2010-03-23, Moffett, Kyle D  wrote:
>>   * Regarding software security updates, I am aware that most vendors of OS
>> distributions participate in coordinated-disclosure and embargo agreements
>> in order to receive advance notice of certain vulnerabilities.  My employer
>> is currently considering what we would need to do in order to get access to
>> those notifications; on the other hand we would much rather participate
>> directly in the Debian security release process.  Would it be possible for
>> us as a third-party corporation to be a part of that process?
> 
> The easiest approach for all parties involved would be if e500 becomes an
> official port. In that case you don't need to do anything on the security
> side, all security updates are autobuilt and if there's an embargoed
> security issue targeted for a specific release date it's automatically
> available for e500 on the release day. But even if e500 starts unofficially
> we can discuss/evaluate the possibilities to hook a e500 autobuild system
> into the security buildd network.

This would be wonderful from the official-Debian-port side of things, but we
would still like to get our company into the security process.  If at all
possible, we would like to be able to participate in the Debian security
release process enough to identify which security updates pertain to our
specific configurations and provide our clients with release-day updates.

Specifically, we are going to be distributing a derivative/fork of Debian
that has been patched-and-hardened for our specific use-case (as a network
security appliance on aircraft).  We certainly plan to collaborate with the
general Debian (and other open-source) communities as we build this product,
including releasing all the open-source debs and source packages.  On the
other hand, the very strictly locked-down and feature-neutered environment
that actually gets installed on the aircraft will be unlikely to be
interesting on general-purpose servers or desktops.

If you have any suggestions or comments, I am very interested to hear them.

>>   * Even if an e500 port does not go upstream, would it be possible to get
>> the appropriate entries added to the upstream dpkg cpu and triplet tables?
>> We're using a simple 10-line patch to dpkg locally, hopefully that would be
>> acceptable?
> 
> That has been done in the past for unofficial architectures like "lpia"
> already.
> 
> Simply file a bug against dpkg using reportbug and send the patch along.

Wonderful!  I'll hopefully have time to get to it some time today.  I'll
also try to send over our tiny patches for "eglibc", "gcc-4.3", and
"gcc-4.4" at the same time.

Thanks again for your comments and advice!

Cheers,
Kyle Moffett

-- 
Kyle Moffett
eXMeritus Software
Integrated Intelligence
The Boeing Company

(703) 764-0925
(703) 832-0657 (fax)
kyle.d.moff...@boeing.com


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/c7ce7ad4.7f7b%kyle.d.moff...@boeing.com

Re: Preparing a Debian "e500" port/derivative (ABI-incompatible PowerPC variant)

[Michael Gilbert]

On Tue, 23 Mar 2010 13:04:04 -0500, Moffett, Kyle D wrote:
> [Note: I'm not authorized to speak "on behalf of" my employer, but this
>  represents (to the best of my knowledge) our current plans and goals]
> 
> Please maintain the CC list, all of us here at eXMeritus are interested in
> comments and advice.
> 
> On 2010/03/23 13:40, "Moritz Muehlenhoff"  wrote:
> > On 2010-03-23, Moffett, Kyle D  wrote:
> >>   * Regarding software security updates, I am aware that most vendors of OS
> >> distributions participate in coordinated-disclosure and embargo agreements
> >> in order to receive advance notice of certain vulnerabilities.  My employer
> >> is currently considering what we would need to do in order to get access to
> >> those notifications; on the other hand we would much rather participate
> >> directly in the Debian security release process.  Would it be possible for
> >> us as a third-party corporation to be a part of that process?
> > 
> > The easiest approach for all parties involved would be if e500 becomes an
> > official port. In that case you don't need to do anything on the security
> > side, all security updates are autobuilt and if there's an embargoed
> > security issue targeted for a specific release date it's automatically
> > available for e500 on the release day. But even if e500 starts unofficially
> > we can discuss/evaluate the possibilities to hook a e500 autobuild system
> > into the security buildd network.
> 
> This would be wonderful from the official-Debian-port side of things, but we
> would still like to get our company into the security process.  If at all
> possible, we would like to be able to participate in the Debian security
> release process enough to identify which security updates pertain to our
> specific configurations and provide our clients with release-day updates.
> 
> Specifically, we are going to be distributing a derivative/fork of Debian
> that has been patched-and-hardened for our specific use-case (as a network
> security appliance on aircraft).  We certainly plan to collaborate with the
> general Debian (and other open-source) communities as we build this product,
> including releasing all the open-source debs and source packages.  On the
> other hand, the very strictly locked-down and feature-neutered environment
> that actually gets installed on the aircraft will be unlikely to be
> interesting on general-purpose servers or desktops.

hi,

if you are interested in security, your best bet is to become familiar
with the debian security tracker [0] and its database [1],[2].  debian
strives to work out in the open, so most, but not all, known issues are
tracked there.  if you want to make active contributions, you can join
the alioth project [3].

there are private issues every now and then, and you can try to join
vendor-sec [4], but you may not qualify.  those issues are eventually
disclosed anyway on an agreed date, and then they're tracked in the
public database.

best wishes,
mike

[0] http://security-tracker.debian.org
[1] http://svn.debian.org/wsvn/secure-testing 
(secure-testing-comm...@lists.alioth.debian.org)
[2] http://svn.debian.org/wsvn/secure-testing/doc/narrative_introduction
[3] https://alioth.debian.org/projects/secure-testing/
[4] http://oss-security.openwall.org/wiki/mailing-lists/vendor-sec


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100323151714.520ed283.michael.s.gilb...@gmail.com

Re: Preparing a Debian "e500" port/derivative (ABI-incompatible PowerPC variant)

[Moritz Muehlenhoff]

On 2010-03-23, Moffett, Kyle D  wrote:

[ Only commenting on two issues, the sbuild maintainers, powerpc and Debian
embedded people are more versed in commenting them. ]

>   * Regarding software security updates, I am aware that most vendors of OS
> distributions participate in coordinated-disclosure and embargo agreements
> in order to receive advance notice of certain vulnerabilities.  My employer
> is currently considering what we would need to do in order to get access to
> those notifications; on the other hand we would much rather participate
> directly in the Debian security release process.  Would it be possible for
> us as a third-party corporation to be a part of that process?

The easiest approach for all parties involved would be if e500 becomes an 
official port. In that case you don't need to do anything on the security
side, all security updates are autobuilt and if there's an embargoed
security issue targeted for a specific release date it's automatically 
available for e500 on the release day. But even if e500 starts unofficially
we can discuss/evaluate the possibilities to hook a e500 autobuild system 
into the security buildd network.

>   * Even if an e500 port does not go upstream, would it be possible to get
> the appropriate entries added to the upstream dpkg cpu and triplet tables?
> We're using a simple 10-line patch to dpkg locally, hopefully that would be
> acceptable?

That has been done in the past for unofficial architectures like "lpia" already.

Simply file a bug against dpkg using reportbug and send the patch along.

Cheers,
Moritz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnhqhv8n.2fl@inutil.org

Re: Preparing a Debian "e500" port/derivative (ABI-incompatible PowerPC variant)

[Moritz Muehlenhoff]

On Tue, Mar 23, 2010 at 01:04:04PM -0500, Moffett, Kyle D wrote:
> [Note: I'm not authorized to speak "on behalf of" my employer, but this
>  represents (to the best of my knowledge) our current plans and goals]
> 
> Please maintain the CC list, all of us here at eXMeritus are interested in
> comments and advice.
> 
> On 2010/03/23 13:40, "Moritz Muehlenhoff"  wrote:
> > On 2010-03-23, Moffett, Kyle D  wrote:
> >>   * Regarding software security updates, I am aware that most vendors of OS
> >> distributions participate in coordinated-disclosure and embargo agreements
> >> in order to receive advance notice of certain vulnerabilities.  My employer
> >> is currently considering what we would need to do in order to get access to
> >> those notifications; on the other hand we would much rather participate
> >> directly in the Debian security release process.  Would it be possible for
> >> us as a third-party corporation to be a part of that process?
> > 
> > The easiest approach for all parties involved would be if e500 becomes an
> > official port. In that case you don't need to do anything on the security
> > side, all security updates are autobuilt and if there's an embargoed
> > security issue targeted for a specific release date it's automatically
> > available for e500 on the release day. But even if e500 starts unofficially
> > we can discuss/evaluate the possibilities to hook a e500 autobuild system
> > into the security buildd network.
> 
> This would be wonderful from the official-Debian-port side of things, but we
> would still like to get our company into the security process.  If at all
> possible, we would like to be able to participate in the Debian security
> release process enough to identify which security updates pertain to our
> specific configurations and provide our clients with release-day updates.
> 
> Specifically, we are going to be distributing a derivative/fork of Debian
> that has been patched-and-hardened for our specific use-case (as a network
> security appliance on aircraft).  We certainly plan to collaborate with the
> general Debian (and other open-source) communities as we build this product,
> including releasing all the open-source debs and source packages.  On the
> other hand, the very strictly locked-down and feature-neutered environment
> that actually gets installed on the aircraft will be unlikely to be
> interesting on general-purpose servers or desktops.
> 
> If you have any suggestions or comments, I am very interested to hear them.

I think we rather need to analyse this the other way round: What specific
part of the "life cycle" of a security issue are you interested in and in
what way do you want to want to be involved in the process?

The general life cycle looks roughly like this:

1. Initial report and triage
The comes from many different sources. In most cases this is a public source,
e.g. a Debian bug report filed by a user or a security issue reported by a
specific open source project by announcing in on their website. This
comprises the majority of all security issues (no hard numbers, but my gut
feeling is 3/4 of all issues). All this information is directly fed into
the Debian Security Tracker, a very powerful framework for the analysis and
tracking of security issues. You could participate in this process right-away.

Please see the following links for more information:
http://security-tracker.debian.org/tracker/data/report
http://security-tracker.debian.org/tracker/

A key benefit of Debian is that we do (almost) everything in the open, we don't
have inaccessible private Bugzilla or Launchpad bugs, so any information
collected on our bugtracking is directly available for our appliance-specific
analysis.

For a limited subset of vulnerabilities the initial report information is 
brought to our attention by other distributions through a cross-distribution
mailing list called vendor-sec. In that case we cannot disclose the information
prior to the release of the updated package. This is something we're not fond
of, but which is an unpleasant fact of reality. Fortunately vendor-sec is
less important these days in comparison to the situation some years ago, since
a lot of discussion has been shifted to the oss-security mailing list.

For step (1) you will be mostly interested in sufficient information to study
whether this vulnerability affects our appliance. Since we do a lot of
version specific tracking this should help you a lot. If e.g. a security
issue only affects the latest release and not the versions included in Debian
stable or oldstable this information is annotated in the Debian Security 
Tracker.

You're welcome to participate in the analysis work done there; you don't need
to be a Debian developer to contribute.


2. Development of the security fix / prerelease testing

The backport of the security fix is usually done by the Debian Security Team
or the maintainers of the relevant packages (especially if a backport is
needed for non-standard 

Re: Preparing a Debian "e500" port/derivative (ABI-incompatible PowerPC variant)

[Frans Pop]

Moritz Muehlenhoff wrote:
>> * Even if an e500 port does not go upstream, would it be possible to get
>> the appropriate entries added to the upstream dpkg cpu and triplet
>> tables? We're using a simple 10-line patch to dpkg locally, hopefully
>> that would be acceptable?
> 
> That has been done in the past for unofficial architectures like "lpia"
> already.

Which is possibly not the best example as lpia was abandoned not all that 
much later.

Cheers,
FJP


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201003232318.18780.elen...@planet.nl

Re: Preparing a Debian "e500" port/derivative (ABI-incompatible PowerPC variant)

[Moffett, Kyle D]

[Note: I'm not authorized to speak "on behalf of" my employer, but this
 represents (to the best of my knowledge) our current plans and goals]

Please maintain the CC list, all of us here at eXMeritus are interested in
comments and advice.

Thanks for your detailed comments!  I'm very optimistic that we'll be able
to work out a long-term solution that keeps us as close to upstream (in this
case Debian) as possible.  I've added further commentary below.

On 2010/03/23 17:02, "Moritz Muehlenhoff"  wrote:
> On Tue, Mar 23, 2010 at 01:04:04PM -0500, Moffett, Kyle D wrote:
>> This would be wonderful from the official-Debian-port side of things, but we
>> would still like to get our company into the security process.  If at all
>> possible, we would like to be able to participate in the Debian security
>> release process enough to identify which security updates pertain to our
>> specific configurations and provide our clients with release-day updates.
>> 
>> Specifically, we are going to be distributing a derivative/fork of Debian
>> that has been patched-and-hardened for our specific use-case (as a network
>> security appliance on aircraft).  We certainly plan to collaborate with the
>> general Debian (and other open-source) communities as we build this product,
>> including releasing all the open-source debs and source packages.  On the
>> other hand, the very strictly locked-down and feature-neutered environment
>> that actually gets installed on the aircraft will be unlikely to be
>> interesting on general-purpose servers or desktops.
>> 
>> If you have any suggestions or comments, I am very interested to hear them.
> 
> I think we rather need to analyse this the other way round: What specific
> part of the "life cycle" of a security issue are you interested in and in
> what way do you want to want to be involved in the process?
> 
> The general life cycle looks roughly like this:

[snip] 
 
> For a limited subset of vulnerabilities the initial report information is
> brought to our attention by other distributions through a cross-distribution
> mailing list called vendor-sec. In that case we cannot disclose the
> information
> prior to the release of the updated package. This is something we're not fond
> of, but which is an unpleasant fact of reality. Fortunately vendor-sec is
> less important these days in comparison to the situation some years ago, since
> a lot of discussion has been shifted to the oss-security mailing list.

The vendor-sec coordinated-disclosure nonsense is my major concern.  We are
already subscribed appropriately to the DSA mailing lists, and we will set
up an automatic internal notification that polls the debsecan databases.
Our local Debian servers already monitor that data on a regular basis
anyways.

> The backport of the security fix is usually done by the Debian Security Team
> or the maintainers of the relevant packages (especially if a backport is
> needed for non-standard packages). Currently all testing prior to the release
> is performed by the Security Team and the respective maintainers. We're
> planning to have a "security beta test" program for large customers (which
> usually deploy/test security fixes in test environment prior to the rollout).
> Hopefully we'll be able to have the necessary infrastructure ready during this
> year. Once we have such a program you would be very welcome to contribute your
> testing feedback.

What I am a little worried about is getting completely blindsided by some
update that all the "other" OS vendors have known about for months.  Right
now we would only find out about it when Debian officially releases its
security update packages.  Ideally we would monitor vendor-sec and identify
which vulnerabilities apply to our appliance, then acquire, test, and
comment on the Debian-specific patch before the disclosure date.  Our backup
plan is to simply monitor vendor-sec and attempt to patch the security
problems ourselves, though again we'd rather stay close to upstream (IE:
Debian).

We are certainly going to try to get ourselves on the vendor-sec mailing
list, as we believe our network security appliance would certainly qualify
us as an "OS vendor" with a real need to know about such vulnerabilities.
In particular, the commercial software application we are deploying onto our
network appliances is called the "HardwareWall"; it provides a safe
government-certified system for connecting government networks of different
classification levels.

Cheers,
Kyle Moffett

-- 
Kyle Moffett
eXMeritus Software
Integrated Intelligence
The Boeing Company

(703) 764-0925
(703) 832-0657 (fax)
kyle.d.moff...@boeing.com


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/c7ceb7c9.7f8c%kyle.d.moff...@boeing.com

Status of kernel patch packages

[Yann Dirson]

[this and the following mails are resent versions, my mails did not
make it to the list due to some config problem - sorry for any dups
this may cause]

Since April 2009, kernel-package has no use any more for the
{kernel,linux}-patch-* packages (AFAIK the current recommended way of
patching a kernel is using git).  My understanding was that those
packages should then be simply removed from the archive.  However,
there are still a couple of kernel patch packages in squeeze and sid,
and some of them got recent updates.

So the question is, is it time to request removal of those packages,
or is there any remaining reason not to do so that I missed ?

[CC'd maintainers of the relevant packages]

Best regards,
-- 
Yann


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100323223506.ga11...@nan92-1-81-57-214-146.fbx.proxad.net

Re: Status of kernel patch packages

[Yann Dirson]

On Sun, Mar 21, 2010 at 12:17:22AM +0900, Hideki Yamane wrote:
> On Sat, 20 Mar 2010 15:14:59 +0100
> Yann Dirson  wrote:
> > So the question is, is it time to request removal of those packages,
> > or is there any remaining reason not to do so that I missed ?
> 
>  As linux-patch-tomoyo1.7 package maintainer, tomoyo is merged with 
>  mainline, but it's not fully featured one yet. At least, I want to 
>  provide it with squeeze.
> 
>  and hope kernel-package would enable patch support again... ;)

I won't speak for Manoj here, but I feel we should think about other
ways to provide those patches.

One way could be simply to provide ensure those patches in some git
tree, that users can easily fetch and merge before running make-kpkg.

But I'm not aware of a git tree holding the debian kernels - SVN is
still listed as the VCS for the linux-2.6 package (which, BTW,
continues to surprise me).  But at least we could have some convention
about where to make available git trees for patch stacks - something
on git.debian.org surely, which could be quite efficient with the
"forks" feature of gitweb activated (which does not seems to be the
case aleady).

Then maybe some simple helper scripts could make it a snap to fetch
all patch stacks and start a merge.  Maybe we could at some point also
be able to publish merges of conflicting patch stacks in a similarly
convenient way.  Such a resource may even be interesting to many
people out of Debian.

Well, that's just random week-end thoughts - you know, world
domination and the like :)

Best regards,
-- 
Yann


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100323223533.ga11...@nan92-1-81-57-214-146.fbx.proxad.net

Re: Status of kernel patch packages

[Yann Dirson]

On Sun, Mar 21, 2010 at 11:57:01AM +0100, Yann Dirson wrote:
> On Sat, Mar 20, 2010 at 05:39:00PM +0100, Jonas Smedegaard wrote:
> > On Sat, Mar 20, 2010 at 05:28:33PM +0100, Yann Dirson wrote:
> > >On Sun, Mar 21, 2010 at 12:17:22AM +0900, Hideki Yamane wrote:
> > >>On Sat, 20 Mar 2010 15:14:59 +0100
> > >>Yann Dirson  wrote:
> > >>> So the question is, is it time to request removal of those >
> > >>packages, or is there any remaining reason not to do so that I >
> > >>missed ?
> > >>
> > >> As linux-patch-tomoyo1.7 package maintainer, tomoyo is merged
> > >>with  mainline, but it's not fully featured one yet. At least, I
> > >>want to  provide it with squeeze.
> > >>
> > >> and hope kernel-package would enable patch support again... ;)
> > >
> > >I won't speak for Manoj here, but I feel we should think about
> > >other ways to provide those patches.
> > >
> > >One way could be simply to provide ensure those patches in some
> > >git tree, that users can easily fetch and merge before running
> > >make-kpkg.
> > 
> > Lots of possibilities arise if we do not constrain ourselves to the
> > Debian ideal of a fully self-contained distribution usable while
> > offline.
> > 
> > I happen to like that ideal, also for kernel patches.
> 
> I don't think there is a contradiction - eg. it could make sense to
> ship a kernel repository in a package, and similarly for kernel
> patches referencing the former as a (local) remote.

Let's maybe stay focussed on the initial problem: we *had* a way to
handle kernel patches as part of a self-contained distribution, but
there is no support for this any more.  Moreover that support we had
was not 100% satisfactory (eg. bad handling of conflicting patches
needing manual merge - although that was something I wanted to address
in the never-finished dh-kpatches 0.100).  My idea is to rethink the
whole thing using today's tools - namely, git.

Anyway, to get back to the initial problem of the current linux-patch
packages, we currently still have patches in the distro, which were
packaged for a mechanism that is not to be shipped in squeeze (and
referencing that obsolete mechanism in their /usr/share/doc/), and
this in itself is a problem of quality of the overal distro, right ?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100323223705.ga11...@nan92-1-81-57-214-146.fbx.proxad.net

Re: Bug#547079: login: Should set the iutf8 tty c_iflag if the locale is utf8

[Nicolas François]

Hi Samuel,

On Tue, Mar 23, 2010 at 05:18:42PM +0100, Samuel Thibault wrote:
> 
> See my concern in the bug report:
> 
> “My concern is that getty used to not keep any flag at all.  Keeping
> _some_ flags contrary to none is not just a "fix", it's a change of
> behavior.  Think for instance about a situation where a user clears
> the tty's iutf8.  The next user to log in will have a bogus terminal
> since getty would leave it cleared and nothing else will set it.  This
> is the same for all the flags, getty could just keep the kernel's
> current state, but it doesn't. [...] Letting a user break another user's
> environment is wrong”

Is it an issue to set the utf8 flag too often?
(does it break something?, does it affect performances?)

Also, can you elaborate on your solution. Who would configure what and how?

Best Regards,
-- 
Nekral


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100323225929.ge5...@nekral.nekral.homelinux.net

Bug#575171: ITP: libnet-nationalrail-livedepartureboards-perl -- Perl module for retrieving UK rail live departure board information

[Tim Retout]

Package: wnpp
Severity: wishlist
Owner: Tim Retout 
Owner: Tim Retout 

* Package name: libnet-nationalrail-livedepartureboards-perl
  Version : 0.02
  Upstream Author : Tim Retout 
* URL : 
http://search.cpan.org/dist/Net-NationalRail-LiveDepartureBoards/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl module for retrieving UK rail live departure board 
information

 Net::NationalRail::LiveDepartureBoards provides an interface to the
 National Rail Enquiries Live Departure Boards SOAP API.  This can be
 used to find the next trains arriving or departing a particular
 railway station in the UK.
 .
 Related modules on CPAN include WWW::LiveDepartureBoards and
 WWW::NationalRail, but those are implemented by scraping and parsing
 the relevant websites.  This SOAP API should be more stable.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100323230516.4833.25648.report...@arneb.retout.co.uk

Re: Status of kernel patch packages

[Ben Hutchings]

On Tue, Mar 23, 2010 at 11:35:33PM +0100, Yann Dirson wrote:
> On Sun, Mar 21, 2010 at 12:17:22AM +0900, Hideki Yamane wrote:
> > On Sat, 20 Mar 2010 15:14:59 +0100
> > Yann Dirson  wrote:
> > > So the question is, is it time to request removal of those packages,
> > > or is there any remaining reason not to do so that I missed ?
> > 
> >  As linux-patch-tomoyo1.7 package maintainer, tomoyo is merged with 
> >  mainline, but it's not fully featured one yet. At least, I want to 
> >  provide it with squeeze.
> > 
> >  and hope kernel-package would enable patch support again... ;)
> 
> I won't speak for Manoj here, but I feel we should think about other
> ways to provide those patches.
> 
> One way could be simply to provide ensure those patches in some git
> tree, that users can easily fetch and merge before running make-kpkg.
 
Or just 'make deb-pkg', the upstream-supported method.

> But I'm not aware of a git tree holding the debian kernels - SVN is
> still listed as the VCS for the linux-2.6 package (which, BTW,
> continues to surprise me).

It's on our to-do list but further down than the work needed for squeeze.

I do have a script that can convert the patch series into a git branch,
and I could publish a git repository if that's useful.

> But at least we could have some convention
> about where to make available git trees for patch stacks - something
> on git.debian.org surely, which could be quite efficient with the
> "forks" feature of gitweb activated (which does not seems to be the
> case aleady).
> 
> Then maybe some simple helper scripts could make it a snap to fetch
> all patch stacks and start a merge.  Maybe we could at some point also
> be able to publish merges of conflicting patch stacks in a similarly
> convenient way.  Such a resource may even be interesting to many
> people out of Debian.
 
Forking Linux is easy; maintaining a fork is very hard indeed, and we
generally try to avoid doing so.  This is why we are trying to get rid
of the virtualisation 'featuresets'[1] and get all our other patches
upstream[2].  It's also why we're sharing the work of maintaining 2.6.32
with other distributions.  Any intrusive patch set (as opposed to a new
driver or filesystem, which is easier to maintain out-of-tree) should be
treated as a short-term experiment, to be merged upstream or abandoned.
It should never be included in a stable distribution.

[1] Not right now but after squeeze.
[2] Mostly successfully.

Ben.

> Well, that's just random week-end thoughts - you know, world
> domination and the like :)
> 
> Best regards,

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100324003910.gm16...@decadent.org.uk

uq=незабываемое удовольствие

[Чихалин]

Вибро оргазм ! Получи незабываемое удовольствие от вибраций своего мобильного 
телефон, испытай незабываемые ощущение!! http://kl.am/9d38


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/005c01cacb66$ec372da3$8fdb2...@kjbkenloynk

Re: Status of kernel patch packages

[Manoj Srivastava]

On Tue, Mar 23 2010, Yann Dirson wrote:


> Let's maybe stay focussed on the initial problem: we *had* a way to
> handle kernel patches as part of a self-contained distribution, but
> there is no support for this any more.  Moreover that support we had
> was not 100% satisfactory (eg. bad handling of conflicting patches
> needing manual merge - although that was something I wanted to address
> in the never-finished dh-kpatches 0.100).  My idea is to rethink the
> whole thing using today's tools - namely, git.
>
> Anyway, to get back to the initial problem of the current linux-patch
> packages, we currently still have patches in the distro, which were
> packaged for a mechanism that is not to be shipped in squeeze (and
> referencing that obsolete mechanism in their /usr/share/doc/), and
> this in itself is a problem of quality of the overal distro, right ?

So all we really need is a little script that does the
 patch/unpatch  that make-kpkg used to do on the fly, and have the user
 run the patch script, call make-kpkg (or make deb-pkg, or what have
 you), and call the unpatch script later if the feel like it.

This should be pretty simple to do, really.

manoj
-- 
When one is overcome by this wretched, clinging desire in the world,
one's sorrows increase like grass growing up after a lot of rain. 335
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wrx2ifgs@anzu.internal.golden-gryphon.com

Re: Naming policy for Perl modules (mass bug filing)

[Carlo Segre]

On Tue, 23 Mar 2010, Ansgar Burchardt wrote:


Jozef Kutej  writes:


Ansgar Burchardt wrote:

the Debian Perl Policy asks for packages for the Foo::Bar module to be

Perl module packages *should* be named... :)


 "Non-conformance with guidelines denoted by should (or recommended)
 will generally be considered a bug, but will not necessarily render a
 package unsuitable for distribution."

I don't object to naming packages differently if there is a reason to do
so, but fail to see one for these packages (except for perlmagick which
is also the upstream name as noted by Bastien ROUCARIES [1]).



as the maintainer for one of the listed modules, I can tell you that I 
don't object to the notion of changing the name (I have often considered 
it) but for the fact that


1. it would entail a lot of changes for the packages which depend on it 
and


2. the ifeffit source package is contrib and cannot be built by the 
autobuilders because of its build time dependence on pgplot5.


The latter is causing me much grief and needs to be solved before I work 
on consistency issues.  Right now I have to build the package by hand on 
whatever architectures I can get my hands on (I only have 8) and upload 
all the binaries.  The package has not migrated to testing for nearly 2 
years because not all the architectures are present and until this is 
resolved, there is really no point since it will only languish in 
unstable.


So please go ahead and file the bug, I will consider it as wishlist until 
I can get the rest resolved.


Crankily (but not with the Perl Developers),

Carlo

--
Carlo U. Segre -- Professor of Physics
Associate Dean for Graduate Admissions, Graduate College
Illinois Institute of Technology
Voice: 312.567.3498Fax: 312.567.3494
se...@iit.edu   http://www.iit.edu/~segre   se...@debian.org


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/alpine.deb.2.00.1003240023590.3...@hydride.iit.edu