Re: Test suites after build and Build-Depends.

2009-01-23 Thread Stefano Zacchiroli
On Fri, Jan 23, 2009 at 02:53:59PM +0900, Charles Plessy wrote:
> I packaged a lot programs that have a test suite, and realised that, in order
> to run it after build, the dependancies of the binary package produced must be
> present as well. For the moment, I add them in Build-Depends(-Indep), but this
> is not satisfactory, because:
> 
> - The build dependancy graph becomes unnecessarily complex when running the
>   test suite is skipped.

I don't buy this argument, i.e., please expand it.

Build-Depends determines what is needed to completely perform the
process of turning a Debian source package into a set of Debian binary
packages. If that includes running tests, the test dependencies should
be mentioned there. If you are arguing that Build-Depends is too
coarse grained, and it might need a more precise splitting, according
to which debian/rules target build-dependencies are for, I might
concur. Still, the benefits of doing the needed split are not clear to
me.

> - Information is duplicated between Build-Depends: and the binary packages's
>   Depends: field.

Uh? Why? In general test suite dependencies are not the same as binary
package dependencies, they might be:

- larger: due to the need of test framework which are not needed at
  runtime

- smaller: due to part of the source code for which there are no tests

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


Processed: cleanup

2009-01-23 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> close 292481
Bug#292481: Collaborative repository of package meta-information is needed
'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing.
Bug closed, send any further explanations to Artur Górniak 


> reassign 512717 general
Bug#512717: project: Should have alternatives for graphical su and sudo (x-su, 
x-sudo?)
Bug reassigned from package `project' to `general'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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



Re: Test suites after build and Build-Depends.

2009-01-23 Thread Adeodato Simó
* Charles Plessy [Fri, 23 Jan 2009 14:53:59 +0900]:

> Dear all,

> I packaged a lot programs that have a test suite, and realised that,
> in order to run it after build, the dependancies of the binary package
> produced must be present as well.

I think you've brought up this in the past already, and I pointed out
(as I will now) that this mostly affects software written in interpreted
languages, since when compiling, the resulting Dependencies are probably
already installed.

> - Information is duplicated between Build-Depends: and the binary packages's
>   Depends: field.

If this really, really annoys you, you can always use debian/control.in
pin a way that's allowed to be used).

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
«¡Pero si es tan español que debe de tener el cerebro en forma de botijo,
con pitorro y todo!»
-- Javier Cercas, “La velocidad de la luz”


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



Bug#512745: ITP: pct-wireless-setup -- program to configure wireless networks with system width configuration and profiles options

2009-01-23 Thread Jelle de Jong
Package: wnpp
Severity: wishlist
Owner: Jelle de Jong 

Hello everybody,

I would like to get this program into the debian repository, I will package it 
and 
upload it to debian mentors, I will be looking for a sponser and mentor. This 
package is
part of a larger group of packages that will form the pct-desktop-environment 
that I have
been working on.

Thanks in advance for any feedback and help.

  Package name: pct-wireless-setup
  Version : 0.0.2
  Upstream Author : Jelle de Jong 
  URL : 
https://secure.powercraft.nl/svn/packages/trunk/deb/pct-wireless-setup/
  License : GPLv3
  Programming Lang: BASH
  Description : program to configure wireless networks with system width 
configuration and profiles options

pct-wireless-setup is a helper script to efficient setup common
wireless network configurations. You can debug this script by
running it as bash -x pct-wireless-setup [options]. The script
is just a setup wrapper for the /etc/network/interfaces and the
/etc/wpa_supplicant.conf configuration files.

This package contains a script to setup wireless networking environments.
The program can be used to configure the /etc/network/interfaces and
/etc/wpa_supplicant files with a system width settings. The program should
makes it easy to setup wep, wpa, wpa-personal, roaming wireless networks
and ieee8021x-eap-ttls used by some universities. The program has a
configuration system where different setups can be defined, this makes it
easy to switching between multiple networks. The script is designed to
efficiently setup and maintain network configurations for wireless clients.
Take a look at the help argument to see all options, help, and useful
examples. The package is maintained by PowerCraft Technology.

-- System Information:
Debian Release: 5.0
  APT prefers unstable
  APT policy: (990, 'unstable'), (50, 'experimental')
Architecture: i386 (i686)



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



Bug#512754: ITP: get-iplayer -- download or stream any available BBC iPlayer TV or radio programme

2009-01-23 Thread Jonathan Wiltshire
Package: wnpp
Severity: wishlist
Owner: Jonathan Wiltshire 

* Package name: get-iplayer
  Version : 1.20
  Upstream Author : Phil Lewis 
* URL : http://linuxcentre.net/iplayer
* License : GPLv3
  Programming Lang: Perl
  Description : download/stream available BBC iPlayer TV or radio programmes

get-iplayer allows you to download or stream any available TV or radio programme
from the BBC iPlayer. It can fetch programmes in H.264, ASF/WMV and
MP3/RealAudio formats, and BBC podcasts in MP3/AAC. It also downloads subtitles
and has full PVR functionality for automatic downloading.

-- System Information:
Debian Release: 5.0
  APT prefers testing
  APT policy: (500, 'testing')
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



deprecated server packages in lenny?

2009-01-23 Thread Noah Meyerhans
The etch release notes documented several major server packages as being
deprecated, and stated that they'd be removed for lenny.  These include
Apache 1, php4, mysql 4, etc.  Users were encouraged to migrate to their
replacement packages, which were already included in etch.  Can anybody
suggest a set of packages in a similar state with lenny?

This has been submitted as bug #512690 against release-notes.

Thanks.
noah



signature.asc
Description: Digital signature


Re: Gnomesword, libsword, diatheke, sword modules, bibletime

2009-01-23 Thread Adeodato Simó
Hello,

a person from the Ubuntu community forwarded this mail of yours to a
Debian list.

All these problems you enumerate should be responsibility of the
designated maintainer (Daniel Glassey). You say that you haven't been
successful in contacting him; maybe it's that he has lost interest in
these packages, or doesn't have the time to take care of them anymore,
or perhaps doesn't read his @debian.org mail any more due to spam. I'm
CC'ing him to his latest known address, hoping he can clarify.

I think that if we don't get an answer from him (or if he says he's no
longer interested, doesn't have the time, or would welcome some help) we
should go forward with finding a new maintainer or co-maintainer for
these packages. You expressed interest in bringing your packages into
the Debian archive (which would propagate automatically to Ubuntu):
that'd be great, particularly if you're committed to providing packages
that meet the Debian Policy requirements.

So, let's wait a bit for Daniel's reply, and tell us if you prefer to
try maintaining these packages in Debian yourselves, or would rather
have somebody else do it, if anybody would be interested.

Thanks for contacting us (and thanks Jeffrey Ratcliffe too for
forwarding us your mail).

Oh, and by the way, it would be great if you could submit bug reports
for issues #2 and #4 below, so that they won't be forgotten. (Reports
about out of date versions are not really necessary in this case, since
that's what a new maintainer will address first.)

>> I am one of the developers at CrossWire. Several of our programmes are
>> in your repository, but they are ancient, often 2 or more releases
>> behind us.

>> I have tried on several occasions to contact the maintainer listed but
>> to little avail.

>> I asked eventually on #ubuntu-devel and was advised to mail to you.
>> As we see it, following is wrong:

>> 1) libsword is at 1.5.11 - if you wait a couple of weeks probably at
>> 1.5.12. You keep 1.5.9. 1.5.9 is nearly 2 years old. The functional
>> increase is massive.

>> 2) libsword should be compiled with ICU to allow it full function. It is
>> not.

>> 3) you should not maintain sword modules as all our programmes have a
>> module manager which will download modules directly. Installing modules
>> via apt-get renders the module manager non-functional as the modules are
>> installed by apt-get into non user writable areas (/usr/share/sword
>> instead of ~/.sword)

>> 4) diatheke is a commandline utility which can if carefully handled also
>> be used as a base for CGI script. The example CGI code coming along with
>> it is not meant to be exposed to the internet - at least not in this
>> form. Therefore the dependency on Apache is wrong. Most users will use
>> diatheke only as commandline routine, never as CGI.

>> 5) Gnomesword is ancient history. All bug reports you have on file for
>> GS are sorted in upodated versions. Our last release was 2.4.1. we are
>> currently moving towards the next release - a week or two.

>> There is probably more to it, but to be honest for years now we direct
>> everyone to our own debs as Ubuntu and Debian are so out of date.
>> I would therefore extremely grateful if someone could take this one up
>> or advise us how to go about submitting a new set of packages ourselves.

>> Thanks!

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
The first step on the road to wisdom is the admission of ignorance. The
second step is realizing that you don't have to blab it to the world.


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



Re: Gnomesword, libsword, diatheke, sword modules, bibletime

2009-01-23 Thread Daniel Glassey
On Fri, Jan 23, 2009 at 4:20 PM, Adeodato Simó  wrote:
> Hello,
>
> a person from the Ubuntu community forwarded this mail of yours to a
> Debian list.
>
> All these problems you enumerate should be responsibility of the
> designated maintainer (Daniel Glassey). You say that you haven't been
> successful in contacting him; maybe it's that he has lost interest in
> these packages, or doesn't have the time to take care of them anymore,
> or perhaps doesn't read his @debian.org mail any more due to spam. I'm
> CC'ing him to his latest known address, hoping he can clarify.

I'd be very interested in co-maintainers. The pkg-crossw...@alioth
project never really got off the ground but it is time to try again.

I've just created a new list so I'd like to invite anyone that would
be interested to join

http://lists.alioth.debian.org/mailman/listinfo/pkg-crosswire-devel

for discussion, and send your alioth id to me if you'd like to join the project.

Thanks dato,
Daniel


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



Re: Test suites after build and Build-Depends.

2009-01-23 Thread Noah Slater
What about providing a test target in debian/rules and hooking into this
automatically with pdebuild. You should be able to run tests from within the
chroot without having to modify your debian/control file.

-- 
Noah Slater, http://tumbolia.org/nslater


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



Re: Test suites after build and Build-Depends.

2009-01-23 Thread Vincent Bernat
OoO Lors de la soirée naissante du vendredi 23 janvier 2009, vers 18:55,
Noah Slater  disait :

> What about providing a test target in debian/rules and hooking into this
> automatically with pdebuild. You should be able to run tests from within the
> chroot without having to modify your debian/control file.

One of the interests of those test suits is to be executed automatically
by buildd (on arch that you cannot easily test).
-- 
I WILL NOT SELL SCHOOL PROPERTY
I WILL NOT SELL SCHOOL PROPERTY
I WILL NOT SELL SCHOOL PROPERTY
-+- Bart Simpson on chalkboard in episode 7F10


pgpAIGmW8NALJ.pgp
Description: PGP signature


Re: Test suites after build and Build-Depends.

2009-01-23 Thread Noah Slater
On Fri, Jan 23, 2009 at 08:24:41PM +0100, Vincent Bernat wrote:
> > What about providing a test target in debian/rules and hooking into this
> > automatically with pdebuild. You should be able to run tests from within the
> > chroot without having to modify your debian/control file.
>
> One of the interests of those test suits is to be executed automatically
> by buildd (on arch that you cannot easily test).

Aha, thanks for the clarification.

-- 
Noah Slater, http://tumbolia.org/nslater


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



Packaging of a few new wireless packages

2009-01-23 Thread Luis R. Rodriguez
I'd like to help get a few new wireless userspace applications
packaged into Debian unstable. Here are the new ones:

* iw
* crda
* wireless-regdb

iw is used to configure new cfg80211 based wireless drivers (all
mac80211 drivers for example). wireless-regdb contains the wireless
regulatory database we have moved out to userspace and crda is the
udev helper which reads this database and sends regulatory domains to
the kernel. Its best to separate crda and wireless-regdb as
wireless-regdb can be updated while crda remains intact. I have an
example debian/ dir using cdbs for each of these. Please let me know
if someone is willing to review it so we can throw it into unstable
soon. I *really* would prefer to *not* become the maintainer of these
packages though so am hoping someone can take it up to keep them
brushed up and updated. They all have respective man pages so it would
require less effort :D

http://wireless.kernel.org/en/users/Documentation/iw
http://wireless.kernel.org/en/developers/Regulatory

  Luis


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



Re: deprecated server packages in lenny?

2009-01-23 Thread Daniel Baumann
Noah Meyerhans wrote:
> Can anybody suggest a set of packages in a similar state with lenny?

tinyerp, replaced with the all new openerp (same upstream, but new major
version which will requiring manual upgrade/migration of the psql db).

although probably almost everyone already does, it's finally time to
drop nfs-user-server (nfs-kernel-server has got support for nohide).

-- 
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:  daniel.baum...@panthera-systems.net
Internet:   http://people.panthera-systems.net/~daniel-baumann/


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



Re: Packaging of a few new wireless packages

2009-01-23 Thread Michael Biebl
Luis R. Rodriguez schrieb:
> I'd like to help get a few new wireless userspace applications
> packaged into Debian unstable. Here are the new ones:
> 
> * iw

http://packages.debian.org/experimental/iw

> * crda
> * wireless-regdb

Probably the best contact is
Debian/Ubuntu wpasupplicant Maintainers


If you are interested, I'm sure they would welcome your help
co-maintaining it.

Cheers,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Re: Test suites after build and Build-Depends.

2009-01-23 Thread Charles Plessy
Dear Stefano, Adeodato and Noah, thank you for your answers.

Indeed, I wrote my previous mail after packaging half a dozen of perl modules,
plus enabling tests in a python package. For compiled programs, the situation
is definitely more simple. However, as Stefano noted, there may be sometimes
more things to depend on. In particular, some of the packages I worked on
recently provide wrappers for other programs, which can have complex
dependancies as well. This is why for instance I end up pulling mysql-common
when cowbuilding python-biopython (I miserably failed to arrange the test
target correctly for sbuild). This "spagetthi effect" is what I thought about
when I wrote "unnecessarly complex": I felt a bit afraid that in some
situations where some packages are temporarly mutually incompatible, we can end
up in a situation where the source package that depends on it is not rebuidable
unless the tests are disabled.

In addition, I thought that the 'notest' build option that was discussed last
year (or the year before?) on this list made it into the Policy, but I was
wrong. Maybe I overvaluated this issue. In the context of a 'notest' option,
listing the packages on which the source package build-depends only for the
tests would make sense, so that their installation can be skipped as well.
Probably we can postpone the discussion until there are serious attempts to
push 'notest' to our build toold and the Policy.

In the packages I prepared, I ended up duplicating the binary packages's
Depends, Recommends and Suggests (excluding the non-free ones) into the
Build-Depends field. Fortunately, we can intercalate comments, so I documented
which packages are needed for building and which are needed for testing. As for
the most complex packages, keeping these two lists synchronised is error-prone,
I will think about a 'control.in' system as Adeodato suggested. 

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
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: Test suites after build and Build-Depends.

2009-01-23 Thread Russ Allbery
Charles Plessy  writes:

> In addition, I thought that the 'notest' build option that was discussed
> last year (or the year before?) on this list made it into the Policy,
> but I was wrong.

nocheck will be in 3.8.1 (see Bug#416450), but it doesn't really address
your issue.

> Maybe I overvaluated this issue. In the context of a 'notest' option,
> listing the packages on which the source package build-depends only for
> the tests would make sense, so that their installation can be skipped as
> well.

There isn't anything about that in the upcoming Policy change.  The
assumption of the Policy change is that checks would be enabled by
default; nocheck is available if for some reason one wants to disable
those.  The upcoming wording doesn't add a way to distinguish between
build dependencies required for the build and ones required for testing.

-- 
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



Why is su preserving the environment?

2009-01-23 Thread Josselin Mouette
Hi,

it has been brought to my attention (through #512803) that su does not
clean the environment at all. This has several security implications:
  * variables like PERL5LIB or GTK_MODULES can be passed to another
user, leading to unwanted execution of code;
  * variables like DBUS_SESSION_BUS_ADDRESS or XDG_SESSION_COOKIE
export authentication information that could be used to obtain
private information such as passwords in gnome-keyring.

Before I work around this specific issue in the fugliest way, shouldn’t
we prevent su from preserving the environment?

There have been several security advisories related to sudo not cleaning
the environment, and the final call has been to make env_reset the
default. Is there any reason why su should not be considered vulnerable
the same way?

Cheers,
-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


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


Re: Why is su preserving the environment?

2009-01-23 Thread Steve Langasek
On Sat, Jan 24, 2009 at 08:41:37AM +0100, Josselin Mouette wrote:

> it has been brought to my attention (through #512803) that su does not
> clean the environment at all. This has several security implications:
>   * variables like PERL5LIB or GTK_MODULES can be passed to another
> user, leading to unwanted execution of code;
>   * variables like DBUS_SESSION_BUS_ADDRESS or XDG_SESSION_COOKIE
> export authentication information that could be used to obtain
> private information such as passwords in gnome-keyring.

> Before I work around this specific issue in the fugliest way, shouldn’t
> we prevent su from preserving the environment?

> There have been several security advisories related to sudo not cleaning
> the environment, and the final call has been to make env_reset the
> default. Is there any reason why su should not be considered vulnerable
> the same way?

Because su does not attempt to control what commands are being run; if you
can su to another user, you can run arbitrary commands as that user, which
means there's no sense in trying to filter the environment.

-- 
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


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