Re: debhelper third-party command option parsing transition

[Josselin Mouette]

Le dimanche 15 février 2009 à 15:19 -0500, Joey Hess a écrit :
>   * Move many command-specific options to only be accepted by the command
> that uses them. Affected options are:

> --version-info

This option disappears, but does -V stays around ?

(The dh_pysupport documentation only talks about -V and I don’t think
anyone is using --version-info.)

-- 
 .''`.
: :' :  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

Is the FHS dead ?

[Josselin Mouette]

Hi,

I wanted to discuss the python-support directory tree location (and
similar issues) with the FHS maintainers, however it occurred to me that
the mailing list is completely dead, and the standard doesn’t seem very
alive either. The last release was 5 years ago, and is starting to look
slightly outdated.

Is there a standards body still interested in moving forward with
filesystem layout discussions? If not, shouldn’t we start our own
standard?

-- 
 .''`.  Debian 5.0 "Lenny" has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and 
  `-told that if you don't install Lenny, he'd melt your brain.


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

RFH: mdadm packaging

[martin f krafft]

I am a bit swamped and won't be able to see to the many things that
need to be done with mdadm for squeeze:

- synchronise the big Ubuntu patch; Dustin Kirkland from Canonical
  has expressed interest to cooperate and could help.

- consider how to support non-dynamic (non-udev) creation of arrays
  during boot.

- various improvements relating to the monthly consistency checks.

- convert the Git repo into a TopGit repo.

If you are interested in helping out, let me know. I am happy to
answer questions, walk you through the package, and mentor.

Cheers,

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"let me take you down, 'cause i'm going to strawberry fields.
 nothing is real and nothing to get hungabout.
 strawberry fields forever."
-- the beatles


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: Whoos with GnuTLS and md5-signed certificates

[Florian Weimer]

Would those who have an interest in this topic please test the patch
in



and report if it improves things for them?  Thanks.


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

Re: Is the FHS dead ?

[Patrick Schoenfeld]

Hi,

On Mon, Feb 16, 2009 at 11:14:52AM +0100, Josselin Mouette wrote:
> I wanted to discuss the python-support directory tree location (and
> similar issues) with the FHS maintainers, however it occurred to me that
> the mailing list is completely dead, and the standard doesn’t seem very
> alive either. The last release was 5 years ago, and is starting to look
> slightly outdated.

there is no post from you on the mailinglist in the last six months?
But apart from this is looks quiet dead, yeah. Did you try contacting
persons who are personally involved with FHS? For example the mentioned
editors ("The process is overseen by FHS editors, Rusty Russell, Daniel
Quinlan, and Christopher Yeoh.")?

> Is there a standards body still interested in moving forward with
> filesystem layout discussions? If not, shouldn’t we start our own
> standard?

I'm not sure if "start our own standard" is a good idea. We already have
our own standards and the FHS is more like a distribution-independent
standard, which it should stay. Defining our own standards wouldn't
neccessarily mean that other distributions adopt it. So if we really
start something on our own we should encourage other distributions to
take a part from the beginning.

Best Regards,
Patrick


signature.asc
Description: Digital signature

Re: Bug#515154: ITP: gitg -- git repository viewer for gtk+/GNOME

[Adeodato Simó]

* Jonny Lamb [Sat, 14 Feb 2009 18:03:51 +]:

> On Sat, Feb 14, 16:25:41 +0100, Adeodato Simó wrote:
> > Do you have binary packages anywhere? I'd like to give it a try without
> > having to compile it.

> Sure. I threw some i386 and amd64 packages here:

> http://people.debian.org/~jonny/gitg/

Thanks. I've been looking for ages at a history graph that was as pretty
as bzr-gtk's, and gitg looks promising. :-)

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
  Listening to: Ana Belén - Qué pena


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

Ho tro vay mua nha va vay the chap nha

[huy tran]

Tạo ra vốn kinh doanh và đầu tư.
Đầu tư vào nhà đất tăng giá trị nguồn vốn.
Ổn định nơi cư trú là ổn định cuộc sống.
 
PRUDENTIAL FINANCE

 
 

VAY MUA NHÀ & VAY THẾ CHẤP NHÀ

 
Khách hàng: 
- Nhân viên chính thức đơn vị đang công tác và có thu nhập ổn định hàng 
tháng tren 5 trieu /thang 
- Hô khẩu hoặc kt3 / giấy tạm trú tại Tp. HCM , Biên Hòa, Bình Dương. 
- Tuổi từ 21 – 58 
 
Đặc điểm :
- Vay đến 75 % giá trị của nhà cho vay mua nhà & 50 % cho vay thế chấp 
- Thời hạn vay từ 5 đến 20 năm ( thế chấp nhà là 1-7 năm )
- Lãi suất cạnh tranh tính trên dư nợ giảm dần 
- Khoản vay lên đến 8 tỉ đồng 
- Thủ tục nhanh chóng và hiệu quả ( 40 gio ke tu ngay nhan ho so )
- Miễn phí dịch vụ 
 
  Thủ tục :
  ( bản photo)
- 1 ảnh 3 x 4 ( 1 ảnh 3 x 4 của người cùng vay )
- 1 bản sao chứng minh nhân dân ( cả người cùng vay )
- 1 bản sao giấy tờ thứ cấp ( giấy phép lái xe, hộ chiếu, thẻ nhân 
viên… )
- 1 bản sao hộ khẩu / kt3 / giấy chứng nhận cư trú tại thành phố Hồ Chí 
Minh 
- Hợp đồng lao động ( còn thời hạn ) và giấy xác nhận lương ( có xác 
nhận của phòng Nhân Sự )
- Chứng nhận kết hôn/ độc thân
- Chứng nhận quyền sở hữu nhà ( sổ hồng) của nhà dự định mua 
- Hóa đơn điện/ nước/ điện thoại của tháng gần nhất. 
- Bản sao kê giao dịch ngân hàng 3 tháng gần nhất
 
Quý khách hàng vui lòng liên hệ để được tư vấn thêm thông tin trực tiếp từ nhân 
viên công ty.
 
Công ty Tài Chánh Prudential Việt Nam
Tầng 25, Saigon Trade Center, 37 Tôn Đức Thắng,  Q1, Tp.HCM
Trần Đức Huy – Phòng tín dụng thế chấp Mobile : 0934 00 30  40
_
Invite your mail contacts to join your friends list with Windows Live Spaces. 
It's easy!
http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us

Re: About the current state of the Yum package in Lenny

[Vincent Danjean]

  Hi,

  I few general remarks about packaging in Debian (I never used yum nor
rpm).

Thomas Goirand wrote:
> Philipp Kern wrote:
>> Anyway: there won't be new packages introduced into Lenny.
[...]
> How can I provide a set of patches when the problem is that 2 python
> modules are needed? We can't ship these 2 python modules in yum, this
> goes against the policy, and against any reasonable thinking.

  I think that that the best you can do (if you want to work on this issue) is:
1) propose patches to yum/rpm (via BTS or by [co-]maintaining the package if it
   is possible) so that we get a good working yum/rpm in unstable
2) wait for yum/rpm (and other new packages if any) available in testing and
   realize a backport of them for lenny => lenny users will be able to use
   them easily
3) perhaps, try to push what is available in lenny backport into a point-release
   of lenny. This will depends on how many bug fix are present, how intrusive
   the changes are, the release maintainers opinion, ...

For me, 3 is not the more important. Work on yum/rpm should have been done
earlier to be added in lenny. So you should mainly ensure that squeeze will
be in good shape with respect to yum/rpm. And backports is here for lenny
users if they really needed it.

  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 pacakges: http://www-id.imag.fr/~danjean/deb.html#package
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

Re: About the current state of the Yum package in Lenny

[Thomas Goirand]

Vincent Danjean wrote:
> 3) perhaps, try to push what is available in lenny backport into a 
> point-release
>of lenny. This will depends on how many bug fix are present, how intrusive
>the changes are, the release maintainers opinion, ...
> 
> For me, 3 is not the more important. Work on yum/rpm should have been done
> earlier to be added in lenny. So you should mainly ensure that squeeze will
> be in good shape with respect to yum/rpm. And backports is here for lenny
> users if they really needed it.
> 
>   Regards,
> Vincent

I do agree with you. I even posted on the BTS the URL of GPLHost's own
Debian repository that I manage so there is a workable solution NOW.

My employee, which know python a lot better than me, is working on a
patch. I'm not sure we will be able to have it working without
python-iniparse, but we will try.

That being said, if we can't have a working yum without new python
modules, I do insist: yum shall be REMOVED from Lenny, as it's BROKEN.

More about this later on, after Manuel's python work on the package.

Thomas


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

Bug#515611: general: Keyboard layout problem

[fayaz]

Package: general
Severity: important



-- System Information:
Debian Release: 5.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

After I upgrade to Lenny, my keyboard layout has been lost. It work fine 
on the shell. But in gnome it types wrong character. I remove and 
re-installed gnome and xserver but it doesn't make any difference.



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

Re: Is the FHS dead ?

[Matthew Johnson]

On Mon Feb 16 13:14, Patrick Schoenfeld wrote:
> > Is there a standards body still interested in moving forward with
> > filesystem layout discussions? If not, shouldn’t we start our own
> > standard?
> 
> I'm not sure if "start our own standard" is a good idea. We already have
> our own standards and the FHS is more like a distribution-independent
> standard, which it should stay. Defining our own standards wouldn't
> neccessarily mean that other distributions adopt it. So if we really
> start something on our own we should encourage other distributions to
> take a part from the beginning.

the FHS should certainly continue to exist and be coordinated between
distros though. I agree that if it needs taking over we should do so in
cooperation with the other big distros.

Matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature

Processed: Re: Bug#515611: general: Keyboard layout problem

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 515611 xserver-xorg
Bug#515611: general: Keyboard layout problem
Bug reassigned from package `general' to `xserver-xorg'.

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

Bug#515611: general: Keyboard layout problem

[Julien Cristau]

reassign 515611 xserver-xorg
kthxbye

On Mon, 2009-02-16 at 09:15 -0500, fayaz wrote:
> After I upgrade to Lenny, my keyboard layout has been lost. It work fine 
> on the shell. But in gnome it types wrong character. I remove and 
> re-installed gnome and xserver but it doesn't make any difference.

We need more information.  Please run
'/usr/share/bug/xserver-xorg/script 3>/tmp/xserver-xorg.bug' and send us
the resulting xserver-xorg.bug file.  Please also send the output of
'gconftool --recursive-list /desktop/gnome/peripherals/keyboard'.

Thanks,
Julien



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

Re: Is the FHS dead ?

[Ron Johnson]

On 02/16/2009 04:14 AM, Josselin Mouette wrote:

Hi,

I wanted to discuss the python-support directory tree location (and
similar issues) with the FHS maintainers, however it occurred to me that
the mailing list is completely dead, and the standard doesn’t seem very
alive either. The last release was 5 years ago, and is starting to look
slightly outdated.

Is there a standards body still interested in moving forward with
filesystem layout discussions? If not, shouldn’t we start our own
standard?



Has, maybe, it been merged into the LSB?

http://www.opengroup.org/testing/lsb-fhs/
Present Status

LSB-FHS2.3 merged into LSB 2.0 runtime tests.

This test suite is now being maintained in the LSB CVS tree see
http://www.linuxbase.org/test/

--
Ron Johnson, Jr.
Jefferson LA  USA

Supporting World Peace Through Nuclear Pacification


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

Re: Is the FHS dead ?

[Josselin Mouette]

Le lundi 16 février 2009 à 14:20 +, Matthew Johnson a écrit :
> the FHS should certainly continue to exist and be coordinated between
> distros though. I agree that if it needs taking over we should do so in
> cooperation with the other big distros.

Certainly. It’s just that someone needs to start the work.

-- 
 .''`.  Debian 5.0 "Lenny" has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and 
  `-told that if you don't install Lenny, he'd melt your brain.


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

Bug#515617: ITP: laby -- Laby is a small program to learn how to program with ants and spider webs.

[Mehdi Dogguy]

Package: wnpp
Severity: wishlist
Owner: Mehdi Dogguy 


* Package name: laby
  Version : 20080818
  Upstream Author : Stéphane Gimenez 
* URL : http://www/~gimenez/enseignement.html
* License : GPLv3
  Programming Lang: OCaml
  Description : A small program to learn how to program with ants and 
spider webs.

Laby is a small program to learn how to program with ants and spider webs.
You have to move an ant out of a labyrinth. You have to avoid spider webs,
move rocks, etc.
..
Using Laby, you can learn OCaml, C and Java. Other bindings can be added later
to support new programming languages.

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

Proposed release goal: fix debian/rules build-arch

[Kari Pahula]

Currently, Debian Policy doesn't match with the current practice in
section 7.7.

> The Build-Depends-Indep and Build-Conflicts-Indep fields must be
> satisfied when any of the following targets is invoked: build,
> build-indep, binary and binary-indep.

I know that people like to say that Policy should reflect reality, not
have wishful thinking (like in #178809).  It's been tried before but
I'd like to try again to get a transition done to make reality into
what 7.7 says it is.

As it stands, buildds call "debian/rules build" without having B-D-I
installed, contrary to 7.7.  Buildds do call "debian/rules
binary-arch".  As such, B-D-I does what it's supposed to do on buildds
only in conjunction with binary-arch and clean targets.

Obviously, we'd get half of the archive FTBFS if we made buildds call
build-arch instead of build now, since it's an optional feature.
Having a call to "debian/rules build-arch" fail tells us less than
we'd like, too.  Nobody's yet written a reliable check to see if the
build-arch target is present in a debian/rules file.  I'm hoping that
we're only dealing with debian/rules files that are makefiles.  It'd
be desirable to know if build-arch is supported from the .dsc file
alone, without unpacking the source package.

This has been discussed before and I'll list some options from the top
of my head.  I'm hoping to start a discussion, again.

Now, option 1 (cold turkey):

Make build-arch to be a mandatory target in debian/rules files in the
next policy version (3.9.0, already?).  Any existing "build" targets
work, by necessity, correctly without having B-D-I installed, and a
debian/rules file could be fixed by adding one line:
build-arch: build

Buildds would still call "debian/rules build" on anything that had a
smaller Standards-Version than 3.9.0, and "debian/rules build-arch" on
the rest.  It'd be the maintainer's responsibility to check that it
works before bumping the version.

Option 2 (features field):

Add a field called "Build-Features:" to debian/control and have it
contain a space separated list of tokens.  Define "build-arch" as a
recognized value.  Put that in .dsc.  As with things like this, we'd
potentially get stuck with it forever, but it'd be the least invasive
thing to do and still get buildds to use build-arch.  There'd be no
transition, other than getting sbuild patched.

We could also change build-arch into a "should" feature and warn
anyone who didn't support build-arch and switch over to having it as a
"must" once everyone did it.  It'd be easy to check for that, with
this.

Option 3 (lintian hackery first):

I know some people would like to see a lintian check, first.  The
thing is, debian/rules is a program, so trying to figure out any
properties about it, like "does it support feature X?" or "does it
halt?" gets quite close to the halting problem.

GNU make does have some options to query a makefile, like --dry-run
and --question.  Even those would require evaluating a makefile, at
least to some degree.  If someone put $(shell rm *) in there, it'd do
that.  I'd like to see something like "Running debian/rules --dry-run
or --question must not have harmful side effects or affect any
subsequent calls to debian/rules." in the policy before relying on
those.  I'm hoping that there's nothing controversial about this
addition.  IMHO it's a rather pathological makefile that does things
like that.

I'd like to see some explicit option added to make that would just
answer the question "Is there a rule that would match target X?".
Same considerations about evaluation would apply as to -n and -q.  As
it stands, I'd need to do something like this:

debian/rules -q build-arch 2>&1 >/dev/null | tail -n 1 | \
egrep -e '^make: \*\*\* No rule to make target `build-arch.\.  Stop\.$'

As an aside, guaranteeing that --dry-run wouldn't do anything evil
would help lintian in other matters, too.  For example, this is what
the current version does to check whether a package uses CDBS:
if (m,^include\s+/usr/share/cdbs/1/rules/debhelper.mk,)

I'd rather run "debian/rules -nds" to check if it includes something
from under /usr/share/cdbs/.

Option 4 (give up):

Remove the mention of "build" from 7.7.  Policy would match the
current usage, right then.  This is not what I'd like to see, since I
think that a reliable build-arch would be a really nice thing to have.

Option 5 (further discussion):

Do nothing.  Have this discussion again sometime after Squeeze.  Can
we please not do this?


I see less of a need for a build-indep target.  Should we touch that?


signature.asc
Description: Digital signature

Re: Bug#515154: ITP: gitg -- git repository viewer for gtk+/GNOME

[Tino Keitel]

Hi,

could it be that there is some limitation in the number of
files/directories?  It only shows 80 directories here in the tree view,
but 173 are present.

Regards,
Tino


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

Re: Bug#515617: ITP: laby -- Laby is a small program to learn how to program with ants and spider webs.

[Brett Parker]

On 16 Feb 16:15, Mehdi Dogguy wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Mehdi Dogguy 
> 
> 
> * Package name: laby
>   Version : 20080818
>   Upstream Author : Stéphane Gimenez 
> * URL : http://www/~gimenez/enseignement.html

That's fine if you have pps.jussieu.fr as the first thing in your search
path, I, err, don't. So:
http://www.pps.jussieu.fr/~gimenez/enseignement.html

(Sounded like fun, looks fun... might have a look at some point :)

-- 
Brett Parker


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

Re: Is the FHS dead ?

[Teodor]

On Mon, Feb 16, 2009 at 5:14 PM, Josselin Mouette  wrote:
> Le lundi 16 février 2009 à 14:20 +, Matthew Johnson a écrit :
>> the FHS should certainly continue to exist and be coordinated between
>> distros though. I agree that if it needs taking over we should do so in
>> cooperation with the other big distros.
>
> Certainly. It's just that someone needs to start the work.

There is no need to create another standard, FHS is being continued in
the LSB project at linuxfoundation.org / freestandards.org. FHS was
the starting point for LSB.
Even if the LSB project has been criticized by the Debian project,
this seems to become the "the facto" file hierarchy standard for
Linux. It is not perfect, but is being adopted by the majority of
Linux distros.

Thanks


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

Re: Is the FHS dead ?

[Josselin Mouette]

Le lundi 16 février 2009 à 18:08 +0200, Teodor a écrit :
> There is no need to create another standard, FHS is being continued in
> the LSB project at linuxfoundation.org / freestandards.org. FHS was
> the starting point for LSB.
> Even if the LSB project has been criticized by the Debian project,
> this seems to become the "the facto" file hierarchy standard for
> Linux. It is not perfect, but is being adopted by the majority of
> Linux distros.

Nevertheless, the Linux Foundation hasn’t made evolve the standard for 5
years. Where could we start if we want the standard to evolve? 

Currently, the discussion is clearly happening at other levels. If you
look at the recent cgroups discussion for example, it will clearly be
decided at the distribution level, without any kind of standardization.

-- 
 .''`.  Debian 5.0 "Lenny" has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and 
  `-told that if you don't install Lenny, he'd melt your brain.


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

Re: Bug#515617: ITP: laby -- Laby is a small program to learn how to program with ants and spider webs.

[Mehdi Dogguy]

Brett Parker wrote:
> On 16 Feb 16:15, Mehdi Dogguy wrote:
>> Package: wnpp
>> Severity: wishlist
>> Owner: Mehdi Dogguy 
>>
>>
>> * Package name: laby
>>   Version : 20080818
>>   Upstream Author : Stéphane Gimenez 
>> * URL : http://www/~gimenez/enseignement.html
> 
> That's fine if you have pps.jussieu.fr as the first thing in your search
> path, I, err, don't. So:
> http://www.pps.jussieu.fr/~gimenez/enseignement.html
> 

Yes. Sorry for that. I've already sent the correct url to #515617
Maybe, I had to add de...@lists.d.o ...

> (Sounded like fun, looks fun... might have a look at some point :)
> 

-- 
Mehdi Dogguy مهدي الدقي
http://www.pps.jussieu.fr/~dogguy
Tel.: (+33).1.44.27.28.38


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

Re: Proposed release goal: fix debian/rules build-arch

[Raphael Hertzog]

On Mon, 16 Feb 2009, Kari Pahula wrote:
> Currently, Debian Policy doesn't match with the current practice in
> section 7.7.
> 
> > The Build-Depends-Indep and Build-Conflicts-Indep fields must be
> > satisfied when any of the following targets is invoked: build,
> > build-indep, binary and binary-indep.
> 
> I know that people like to say that Policy should reflect reality, not
> have wishful thinking (like in #178809).  It's been tried before but
> I'd like to try again to get a transition done to make reality into
> what 7.7 says it is.

I don't know if you are aware, but there's lots of discussion already
about this in various dpkg bug reports and in particular this one:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=229357

This bug is on my radar and I certainly plan to fix it in the squeeze
timeline but before we can clearly fix it, we need to come to a reasonable
agreement about what constitutes the official interface to build Debian
packages and how it should look like. We currently have an unfortunate
divergence between dpkg-buildpackage and the policy that needs to be
solved before we can tackle this problem seriously.

> Now, option 1 (cold turkey):
> 
> Make build-arch to be a mandatory target in debian/rules files in the
> next policy version (3.9.0, already?).  Any existing "build" targets
> work, by necessity, correctly without having B-D-I installed, and a
> debian/rules file could be fixed by adding one line:
> build-arch: build
> 
> Buildds would still call "debian/rules build" on anything that had a

Note: buildd use dpkg-buildpackage so the change needs to be done in
dpkg-buildpackage.

> Option 2 (features field):
> 
> Add a field called "Build-Features:" to debian/control and have it
> contain a space separated list of tokens.  Define "build-arch" as a
> recognized value.  Put that in .dsc.  As with things like this, we'd
> potentially get stuck with it forever, but it'd be the least invasive
> thing to do and still get buildds to use build-arch.  There'd be no
> transition, other than getting sbuild patched.
> 
> We could also change build-arch into a "should" feature and warn
> anyone who didn't support build-arch and switch over to having it as a
> "must" once everyone did it.  It'd be easy to check for that, with
> this.

My current plan is to implement a Build-Options field but the expected use
case for such a field are a bit too broad and it leads us to the
discussion about how much "build customization" we should support and how
that customization must be handled (and how we should mix choices of
packagers, choices of user that rebuild the package, choices of the
(derivative) distributions). Note the usage of standards-version to
auto-enable some options is still possible even if we implement
Build-Options.

The first and main customization that users and derivatives distributions
want is related to compiler options so that they can do hardened builds or
optimized builds without having to hand-edit each and every package.
We have integrated some changes during Lenny related to that but it can't
deliver its potential if we don't change the policy to say that package
must respect/use the compiler flags provided in the environment.
Unfortunately, that change was merged/made in dpkg without much
consultation of debian-policy and we're now stuck in a situation where the
disagreement expressed afterwards would certainly lead to a refusal of a
policy change going in that direction.

On that topic I recently started to draft this wiki page, I hope it can
help summarize the options and the issues with each approach and we can
decide what direction we want to take.

http://wiki.debian.org/Teams/Dpkg/DebianRules

This wiki page is centered only on the topic of the preparation of the
build environment but its outcome will obviously have some consequences
on the decision we're going to take for the the build vs build-arch
problem. At least because it will have implications on the implementation
of Build-Options.

(I'm not sure that this discussion will be very constructive at this
stage because I wanted to get some more private feedback to better channel
the discussion but let's see…)

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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

Bug#515636: ITP: libtemplate-plugin-javascript-perl -- Encodes text to be safe in JavaScript

[Maximilian Gaß]

Package: wnpp
Severity: wishlist
Owner: "Maximilian Gaß" 


* Package name: libtemplate-plugin-javascript-perl
  Version : 0.01
  Upstream Author : Tatsuhiko Miyagawa 
* URL : http://search.cpan.org/dist/Template-Plugin-JavaScript/
* License : Artistic | GPL-1+
  Programming Lang: Perl
  Description : Encodes text to be safe in JavaScript

 Template::Plugin::JavaScript is a TT filter that filters text so it can
 be safely used in JavaScript quotes.



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

Bug#515641: ITP: r-cran-epi -- GNU R epidemiological analysis

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 


* Package name: r-cran-epi
  Version : 1.0.8
  Upstream Author : Bendix Carstensen 
* URL : http://cran.r-project.org/src/contrib/
* License : GPL2+
  Programming Lang: R
  Description : GNU R epidemiological analysis
 Functions for demographic and epidemiological analysis in the Lexis diagram,
 i.e. register and cohort follow-up data, including interval censored data and
 representation of multistate data. Also some useful functions for tabulation
 and plotting. Contains some epidemiological datasets.
 .
 The Epi package is mainly focused on "classical" chronic disease epidemiology.
 The package has grown out of the course Statistical Practice in Epidemiology
 using R (see http://www.pubhealth.ku.dk/~bxc/SPE).
 .
 There is A short introduction to R for Epidemiology available at
 http://staff.pubhealth.ku.dk/%7Ebxc/Epi/R-intro.pdf
 Beware that the pages 38-120 of this is merely the manual pages for the Epi
 package.
 .
 Epi is not the only R-package for epidemiological analysis, a package with
 more affinity to infectious disease epidemiology is the epitools package
 which is also evailable in Debian.
 .
 Epi is used in the Department of Biostatistics of the University of Copenhagen.


-- System Information:
Debian Release: 5.0
  APT prefers testing
  APT policy: (501, 'testing'), (50, 'unstable'), (5, '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#515637: ITP: libjs-dojo -- Modular JavaScript toolkit

[Maximilian Gaß]

Package: wnpp
Severity: wishlist
Owner: "Maximilian Gaß" 


* Package name: libjs-dojo
  Version : 1.2.3
  Upstream Author : Alex Russell, Dylan Schiemann, David Schontzler, and others
* URL : http://dojotoolkit.org
* License : BSD | Academic Free License
  Programming Lang: JavaScript
  Description : Modular JavaScript toolkit

The Dojo Toolkit is an open source modular JavaScript library (or more
specifically JavaScript toolkit) designed to ease the rapid development
of cross platform, JavaScript/Ajax based applications and web sites.



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

Bug#515646: ITP: r-cran-maptools -- GNU R Tools for reading and handling spatial objects

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-maptools
  Version : 0.7.16
  Upstream Author : Nicholas J. Lewin-Koh, Roger Bivand, and others
* URL : http://cran.r-project.org/src/contrib/
* License : GPL2+
  Programming Lang: R
  Description : GNU R Tools for reading and handling spatial objects
 Set of tools for manipulating and reading geographic data, in particular
 ESRI shapefiles; C code used from shapelib. It includes binary access to
 GSHHS shoreline files. The package also provides interface wrappers for
 exchanging spatial objects with packages such as PBSmapping, spatstat,
 maps, RArcInfo, Stata tmap, WinBUGS, Mondrian, and others.

-- System Information:
Debian Release: 5.0
  APT prefers testing
  APT policy: (501, 'testing'), (50, 'unstable'), (5, '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#515644: ITP: r-cran-epitools -- GNU R Epidemiology Tools for Data and Graphics

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-epitools
  Version : 0.5.2
  Upstream Author : Tomas Aragon 
* URL : http://cran.r-project.org/src/contrib/
* License : GPL2+
  Programming Lang: R
  Description : GNU R Epidemiology Tools for Data and Graphics
 GNU R Tools for public health epidemiologists and data analysts.
 Epitools provides numerical tools and programming solutions that
 have been used and tested in real-world epidemiologic applications.
 .
 Many practical problems in the analysis of public health data
 require programming or special software, and investigators in
 different locations may duplicate programming efforts. Often,
 simple analyses, such as the construction of confidence intervals,
 are not calculated and thereby complicate appropriate statistical
 inferences for small geographic areas. There are many examples of
 simple and useful numerical tools that would enhance the work of
 epidemiologists at local health departments and yet are not readily
 available for the problem in front of them. The availability of
 these tools will encourage wider use of appropriate methods and
 promote evidence-based public health practices.

-- System Information:
Debian Release: 5.0
  APT prefers testing
  APT policy: (501, 'testing'), (50, 'unstable'), (5, '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#515643: ITP: r-cran-epibasix -- GNU R Elementary Epidemiological Functions

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-epibasix
  Version : 0.1
  Upstream Author : Michael A Rotondi 
* URL : http://cran.r-project.org/src/contrib/
* License : GPL2+
  Programming Lang: R
  Description : GNU R Elementary Epidemiological Functions
 Elementary Epidemiological Functions for a Graduate Epidemiology /
 Biostatistics Course.
 .
 This package contains elementary tools for analysis of common epidemiological
 problems, ranging from sample size estimation, through 2x2 contingency table
 analysis and basic measures of agreement (kappa, sensitivity/specificity).
 Appropriate print and summary statements are also written to facilitate
 interpretation wherever possible. This package is a work in progress, so
 any comments or suggestions would be appreciated. Source code is commented
 throughout to facilitate modification. The target audience includes graduate
 students in various epi/biostatistics courses.
 .
 Epibasix was developed in Canada.

-- System Information:
Debian Release: 5.0
  APT prefers testing
  APT policy: (501, 'testing'), (50, 'unstable'), (5, '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#515638: ITP: swiftsieve -- Manage Sieve scripts in your webbrowser

[Maximilian Gaß]

Package: wnpp
Severity: wishlist
Owner: "Maximilian Gaß" 


* Package name: swiftsieve
  Version : 0.2
  Upstream Author : Maximilian Gaß 
* URL : http://swiftsieve.alioth.debian.org
* License : GPL-2+
  Programming Lang: Perl, JavaScript
  Description : Manage Sieve scripts in your webbrowser


Swiftsieve provides a webinterface for a limited subset of the Sieve
mail filtering language suitable for end users.  It connects to the
server via the ManageSieve protocol.



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

Bug#515647: ITP: r-cran-surveillance -- development and the evaluation of epidemiological outbreak detection algorithms

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-surveillance
  Version : 0.9.9
  Upstream Author : Michael Höhle, Michaela Paul
* URL : http://surveillance.r-forge.r-project.org/
* License : GPL2+
  Programming Lang: R
  Description : development and the evaluation of outbreak detection 
algorithms
 The R-package 'surveillance' is a framework for the development and the
 evaluation of outbreak detection algorithms in univariate and multivariate
 routine collected public health surveillance data. It is hosted on CRAN..
 .
 The intention of the R-package surveillance is to provide open source
 software for the visualization and monitoring of count data time series
 in public health surveillance. Potential users are epidemiologists and
 others working in applied infectious disease epidemiology.
 Furthermore, surveillance also provides a data structure and framework
 for methodological developments of surveillance algorithms.


-- System Information:
Debian Release: 5.0
  APT prefers testing
  APT policy: (501, 'testing'), (50, 'unstable'), (5, '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#515649: ITP: r-cran-xtable -- GNU R coerce data to LaTeX and HTML tables

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 


* Package name: r-cran-xtable
  Version : 1.5.4
  Upstream Author : David B. Dahl 
* URL : http://cran.r-project.org/src/contrib/
* License : GPL2+
  Programming Lang: R
  Description : GNU R coerce data to LaTeX and HTML tables
 Function returning and displaying or writing to disk the LaTeX or HTML
 code associated with the supplied object of class xtable.
 .
 Function converting an R object to an xtable object, which can then be
 printed as a LaTeX or  HTML table.


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

Re: Should Debian Live be supported with lenny?

[Filipus Klutiero]

Le February 15, 2009 06:03:46 am Daniel Baumann, vous avez écrit :
> Filipus Klutiero wrote:
> > Hi,
>
> Hi,
>
> first of all: you are aware that you hit the *worst* possible time of
> sending that email when doing it on the *very* *evening* *when* *we*
> *are* *actually* *really* *releasing*, especially when everyone knows
> that the release is being made that evening.
You are aware that Debian Live lenny RC1 was released on *2009-02-09*? I did 
not see any announcement of that, so I had to find that it was released by 
myself before waiting after the images server pushing around 20 kB/s, and I 
still managed to test and open this thread on the *first* week-end day 
following the release. I'm not paid to do QA on Debian.
>
> second, it would have been more than appropriate to CC me for that mail,
> and of course also send a CC to debian-l...@lists.debian.org.
I meant to CC debian-live but sent the mail too fast.
>
> third, i've took the time to answer your questions when you approached
> me with them 10 days ago. however, this appears to have been wasted as
> you did not care to attach my answers to the questions you're repeating
> here and i apparently (since this post should not left be unanswered
> from our side), do have to reiterate it here.
I asked you 2 questions, one of which I didn't repeat in this thread. I quoted 
your answer to the other one at the end of my message.
>
> fourthly, apparently you lack the ability to communicate bugs you
> experiencing properly. most of your issues do lack any information to
> make something useful out of it. also, again, you have never tried to
> contact our mailinglist about it at all, nor did you submit any bug
> report. bugs do not get solved by mumbling about them in a private mail
> (and not following up with required information).
I didn't perceive any request for follow ups in your answers. If I missed one, 
I'd be happy to provide the required information if you tell me what you 
want.
>
[...]
>
> > according to the current lenny release notes, Debian Live is going to
> > become official with lenny for x86. I tried Debian Live several times and
> > always had issues with it. So, I decided to test Debian Live a bit and
> > found that several issues still applied. I discussed with Daniel Baumann
> > about some issues, and the following seem to be relevant:
> >
> > Apparently innocuous error popup after KDE is started.
>
> you did not mention that 10 days ago, so this one is new.
Indeed, though I see that more as a negative point.
>
> however, such a statement is as usefull as "doesn't work[tm]". feel free
> to send a *useful* bug report with the needed details so that we are
> able to understand it.
The purpose of this thread is not to improve Debian Live. At the time I opened 
the thread, time was running out to even take the decision of making Debian 
Live official or not.
>
> > Fails to boot from hard disk (disk1).
>
> you did not mention that 10 days ago, so this one is new.
I don't know, I tested RC 1 more than beta 2.
>
> dd'ing a usb-hdd image to a harddisk works the same way as to an usb
> stick. this has always been working. stating "doesn't work[tm]" doesn't
> help. feel free to send a *useful* bug report with the needed details so
> that we are able to understand it.
As above.
>
> > Empty F8 screen.
>
> you did not mention that 10 days ago, so this one is new.
As above, I hadn't tested this with beta 2.
>
> this is not actually a bug. in order to have debian-cd and debian-live
> images similar, we do use the same organisation of the help screens in
> syslinux. however, d-i's f8 content does not apply and we don't have any
> usefull content to fill in there, that's why it's nothing there. i'm
> sure i could put an 'empty' frame there if desired.
Yes. Or don't mention that screen when it's empty. Or both.
>
> > The latest image I downloaded still has an old problem, failures at
> > shutdown. Daniel replied this one would be fixed either for r0 or r1.
>
> that's not precise, i said:
>
> "should be fixed with current live-initramfs in sid/lenny. the last
> prebuilds do contain an older version. if not, for r1 then."
>
> for the records: i didn't saw "failures at shutdown" in the last two
> month on cd builds, and neither 10 days ago and neither are they today.
> if they have happened, they were fixed in newer live-initramfs in late
> december (i don't remember from regular builds from before).
You must have been thinking about different failures then.
>
> additionally, stating "failures" doesn't help. feel free to send a
> *useful* bug report with the needed details to understand it.
As above.
>
> > As for the rest:
> >
> > The manual is under heavy construction.
>
> i said: "the manual is about live-helper; that's something completely
> different."
>
> it should be immediately clear to anyone that the documentation about
> the tool that is used to *build* the images does not bother people that
> *use* the image.
As I replied privately, I was refer

Re: About the current state of the Yum package in Lenny

[Luk Claes]

Thomas Goirand wrote:
> Vincent Danjean wrote:
>> 3) perhaps, try to push what is available in lenny backport into a 
>> point-release
>>of lenny. This will depends on how many bug fix are present, how intrusive
>>the changes are, the release maintainers opinion, ...
>>
>> For me, 3 is not the more important. Work on yum/rpm should have been done
>> earlier to be added in lenny. So you should mainly ensure that squeeze will
>> be in good shape with respect to yum/rpm. And backports is here for lenny
>> users if they really needed it.
>>
>>   Regards,
>> Vincent
> 
> I do agree with you. I even posted on the BTS the URL of GPLHost's own
> Debian repository that I manage so there is a workable solution NOW.
> 
> My employee, which know python a lot better than me, is working on a
> patch. I'm not sure we will be able to have it working without
> python-iniparse, but we will try.
> 
> That being said, if we can't have a working yum without new python
> modules, I do insist: yum shall be REMOVED from Lenny, as it's BROKEN.

I guess we should investigate if we can have a working yum without new
python modules.

> More about this later on, after Manuel's python work on the package.

Ok, thanks already for looking into it.

Cheers

Luk


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

Re: Bug#515154: ITP: gitg -- git repository viewer for gtk+/GNOME

[Cyril Brulebois]

Tino Keitel  (16/02/2009):
> could it be that there is some limitation in the number of
> files/directories?  It only shows 80 directories here in the tree
> view, but 173 are present.

Maybe a bunch of them are empty, which means they are of no interest
from a git point of view? (IOW: where can one clone from?)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#515637: ITP: libjs-dojo -- Modular JavaScript toolkit

[Damien Raude-Morvan]

Hi Maximilian,

On Monday 16 February 2009 18:03:19 Maximilian Gaß wrote:
> Package: wnpp
> Severity: wishlist
> Owner: "Maximilian Gaß" 
>
>
> * Package name: libjs-dojo
>   Version : 1.2.3
>   Upstream Author : Alex Russell, Dylan Schiemann, David Schontzler, and
> others * URL : http://dojotoolkit.org
> * License : BSD | Academic Free License
>   Programming Lang: JavaScript
>   Description : Modular JavaScript toolkit

You should merge your ITP with the existing RFP [1] made last year by Raphael 
Geissert.

And maybe also consider join existing pkg-javascript Team [2] ?

[1] http://bugs.debian.org/497122
[2] http://alioth.debian.org/projects/pkg-javascript/

-- 
Damien Raude-Morvan / www.drazzib.com



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

Re: Proposed release goal: fix debian/rules build-arch

[Russ Allbery]

Kari Pahula  writes:

> I know some people would like to see a lintian check, first.  The thing
> is, debian/rules is a program, so trying to figure out any properties
> about it, like "does it support feature X?" or "does it halt?" gets
> quite close to the halting problem.
>
> GNU make does have some options to query a makefile, like --dry-run and
> --question.  Even those would require evaluating a makefile, at least to
> some degree.  If someone put $(shell rm *) in there, it'd do that.  I'd
> like to see something like "Running debian/rules --dry-run or --question
> must not have harmful side effects or affect any subsequent calls to
> debian/rules." in the policy before relying on those.  I'm hoping that
> there's nothing controversial about this addition.  IMHO it's a rather
> pathological makefile that does things like that.

Such a requirement unfortunately still won't mean that Lintian can use
that option to do a check of debian/rules.  As long as make is willing to
run such code, we can't just rely on a Policy statement saying that you're
not supposed to do that.  It is, among other things, a security problem.
You should be able to run Lintian on a package of unknown origin and
provenance and not have it be able to do things that you don't want.  What
we would need is a make option that ensures that make would never run such
code, and unfortunately that's likely to lead to false positives in some
of the stranger cases.

Lintian can go a long way by scanning debian/rules.  This mostly fails
with build systems like CDBS (but one can generally assume that they'll do
the right thing) and hand-rolled build systems involving includes or more
fancy trickery.  Lintian can't get the latter right, but they're also
fairly rare.

There are also the few packages in the archive that don't have a makefile
as debian/rules.  I've been tempted for some time to file RC bugs against
all of them.

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

> Option 4 (give up):
>
> Remove the mention of "build" from 7.7.

I assume you mean build-arch and build-indep here.  I would go a step
further and deprecate Build-{Depends,Conflicts}-Indep if we go that route,
remove the corresponding Lintian checks, and start letting people simplify
their debian/control files.

> Policy would match the current usage, right then.  This is not what I'd
> like to see, since I think that a reliable build-arch would be a really
> nice thing to have.

I have to admit that I'm tempted by this approach, mostly because it's not
clear to me that the build-arch vs. build-indep separation actually gains
us anything that useful.  The point, so far as I can tell, is to save
buildd time by not building the architecture-independent packages.  How
much time would we actually be saving?  Is it worth putting a lot of human
effort into making that situation possible?  Generally CPU cycles are far,
far cheaper than human cycles.

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

Python related changes for unstable/squeeze

[Matthias Klose]

Besides the "normal" pending update of the python version for the
unstable distribution, there will be more changes around python
packaging, including the introduction of python-3.x and addressing
some packaging issues.


Python versions
---

 - 2.4 is still used by zope-2.x and depending packages like plone.
   There was a SoC project which intended to update zope-2.x to use a
   newer python version, but afaik this didn't reach a stable state
   yet. It doesn't make sense to provide a full set of third party
   python modules and extensions for 2.4.  If it is forseeable that
   zope-2.x still requires 2.4 when the freeze for the next Debian
   release approaches, maybe package only 2.4 modules for zope-2.x's
   and plone's dependencies. An alternative might be not to
   distribute zope-2.x and plone with the next stable release.

 - 2.5 is superseded by 2.6; currently there doesn't seem to be
   a reason to ship 2.5 and modules for 2.5 with the next stable
   release. The upstream 2.5 maintainance branch doesn't see bug
   fixes anymore, only security releases will be made from this
   branch.

 - 2.6 is the current stable release which should enter unstable
   soon and become the default after extension packages supporting
   more than one python version are built and migrated to testing.

 - I do not want to speculate about a 2.7 release and the upstream
   version freeze for the next Debian release. If the 2.7 release
   is well ahead of the Debian freeze, then there should be no
   problem to include it.

 - 3.0/3.1: I do not plan to upload 3.0 to unstable or experimental,
   but will prepare 3.1 packages for experimental and upload those
   to unstable with the final release or a late release candidate.
   The 3.1 release is planned for April 2009.

Packaging for Python 3.x


Python 3.x is not upward compatible to 2.x and requires changes to the
sources. Almost no file can be used unmodified. A large part of the
changes can be done automatically with the help of the 2to3 utility.
Porting resources can be found at

 - http://docs.python.org/3.0/whatsnew/3.0.html#porting-to-python-3-0
 - http://docs.python.org/3.0/howto/cporting.html#cporting-howto
 - http://docs.python.org/3.0/library/2to3.html

Upstream does expect Python-2.x to stay around for a while; Python-3.x
will need some time until extensions and modules are ported. For this
reason I do plan to have both Python-2.x and Python-3.x in the next
stable Debian release.

Some third party modules and extensions may be released in a form
where the code for 3.x can be auto-generated from the 2.x code with
the 2to3 utility, some upstreams may decide to stop 2.x support with
one version and provide 3.x support with another version. Debian has
to support both approaches.  The currently used packaging methods only
allow packaging of one version for all Python version (installing in a
shared area and providing this version for each Python version).
Binary packages will double in size when providing both 2.x and 3.x
compatible code, so it does make sense to provide separate binary
packages for 2.x and 3.x.  These new packages should be prefixed with
`python3-' instead of `python-'.  It's up to the package maintainer if
these packages are built from one or two source packages.

There will be a `python3' package and similiar packages built out of a
python3-defaults, which will provide the `python3' binary.


Local installation path
---

When installing Python modules using distutils, the resulting files
end up in the same location wether they are installed by a Debian
package, or by a local user or administrator, unless the installation
path is overwritten on the command line.  Compare this with most
software based on autoconf, where an explicit prefix has to be
provided for the packaging, while the default install installs into
/usr/local.  For new Python versions packaged in Debian this will
change so that an installation into /usr (not /usr/local) requires an
extra option to distutils install command (--install-layout=deb).  To
avoid breaking the packaging of existing code the distutils install
command for 2.4 and 2.5 will just accept this option and ignore it.
For the majority of packages we won't see changes in the packaging,
provided that the python packaging helpers can find the files in the
right location and move it to the expected target path.

A second issue raised by developers was the clash of modules and
extensions installed by a local python installation (with default
prefix /usr/local) with the modules provided by Debian packages
(/usr/local/lib/pythonX.Y/site-packages shared by the patched "system"
python and the locally installed python.  To avoid this clash the
directory `site-packages' should be renamed to `dist-packages' in
both locations:

 - /usr/lib/pythonX.Y/dist-packages (installation location for code
   packaged for Debian)
 - /usr/local/lib/pythonX.Y/dist-packages (installat

Re: debhelper third-party command option parsing transition

[Joey Hess]

> This option disappears, but does -V stays around ?

Yes, -V stays while its long form doesn't.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#515663: ITP: kmess2 -- Windows(R) Live(R) Messenger(R) Client for KDE4.

[Rafael Belmonte]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

--- Please fill out the fields below. ---

   Package name: kmess2
Version: 2.0alpha
Upstream Author: Diederik van der Boor
URL: http://kmess.org
License: GPL-2
Description: Kmess2 is an instant messenger for Windows(R) Live(R)  
Messenger(R) protocol for KDE4.
It supports emoticons, drawing, avatar and videoconference.




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

Re: Proposed release goal: fix debian/rules build-arch

[Kari Pahula]

On Mon, Feb 16, 2009 at 11:21:42AM -0800, Russ Allbery wrote:
> Such a requirement unfortunately still won't mean that Lintian can use
> that option to do a check of debian/rules.  As long as make is willing to
> run such code, we can't just rely on a Policy statement saying that you're
> not supposed to do that.  It is, among other things, a security problem.

That's a good point, but not running debian/rules means that you'd be
making it a requirement to write debian/rules files in a stylised way,
to make it greppable.  Conventions are one thing, that'd be another.
That'd have a human cost too.  But this is somewhat coincidental to
this.  Coming up with a test, even an imperfect one, could help push
changes forwards.

> I have to admit that I'm tempted by this approach, mostly because it's not
> clear to me that the build-arch vs. build-indep separation actually gains
> us anything that useful.  The point, so far as I can tell, is to save
> buildd time by not building the architecture-independent packages.  How
> much time would we actually be saving?  Is it worth putting a lot of human

Ask buildd admins.  They could start downloading and installing B-D-I
along with B-D today.  Deprecating B-D-I and -arch and -indep would be
a small step after that.

> effort into making that situation possible?  Generally CPU cycles are far,
> far cheaper than human cycles.

Another thing that B-D-I is good for: breaking dependency cycles.  An
example from the upcoming version of ghc6: ghc6 uses haddock to build
API docs.  Haddock needs to be built with the same version of ghc6 it
generates docs for.  Putting haddock in ghc6's B-D-I avoids that
cycle.


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

Re: Info on Planet Debian

[Jon Dowland]

On Tue, Nov 25, 2008 at 03:45:53PM +0100, Stefano Zacchiroli wrote:
> http://wiki.debian.org/PlanetDebian
> (2nd google hit for "planet debian")

Hey, if we keep posting, maybe it'll drop to 3rd, below this thread :P


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

Re: Python related changes for unstable/squeeze

[Piotr Ożarowski]

[debian-pyt...@l.d.o added to To and Reply-To, citing whole mail for those who
don't read -devel, me included ]

First of all: thanks Matthias for your work on Python package(s)

[Matthias Klose, 2009-02-16]
> Besides the "normal" pending update of the python version for the
> unstable distribution, there will be more changes around python
> packaging, including the introduction of python-3.x and addressing
> some packaging issues.
> 
> 
> Python versions
> ---
> 
>  - 2.4 is still used by zope-2.x and depending packages like plone.
>There was a SoC project which intended to update zope-2.x to use a
>newer python version, but afaik this didn't reach a stable state
>yet. It doesn't make sense to provide a full set of third party
>python modules and extensions for 2.4.  If it is forseeable that
>zope-2.x still requires 2.4 when the freeze for the next Debian
>release approaches, maybe package only 2.4 modules for zope-2.x's
>and plone's dependencies. An alternative might be not to
>distribute zope-2.x and plone with the next stable release.
> 
>  - 2.5 is superseded by 2.6; currently there doesn't seem to be
>a reason to ship 2.5 and modules for 2.5 with the next stable
>release. The upstream 2.5 maintainance branch doesn't see bug
>fixes anymore, only security releases will be made from this
>branch.

What about a smooth upgrade path for those who use Python2.5 for their (3rd
party) applications? I think Python 2.6 should be default in Squeeze and Python
2.4&2.5 in supported.
 
>  - 2.6 is the current stable release which should enter unstable
>soon and become the default after extension packages supporting
>more than one python version are built and migrated to testing.
> 
>  - I do not want to speculate about a 2.7 release and the upstream
>version freeze for the next Debian release. If the 2.7 release
>is well ahead of the Debian freeze, then there should be no
>problem to include it.
> 
>  - 3.0/3.1: I do not plan to upload 3.0 to unstable or experimental,
>but will prepare 3.1 packages for experimental and upload those
>to unstable with the final release or a late release candidate.
>The 3.1 release is planned for April 2009.
> 
> Packaging for Python 3.x
> 
> 
> Python 3.x is not upward compatible to 2.x and requires changes to the
> sources. Almost no file can be used unmodified. A large part of the
> changes can be done automatically with the help of the 2to3 utility.
> Porting resources can be found at
> 
>  - http://docs.python.org/3.0/whatsnew/3.0.html#porting-to-python-3-0
>  - http://docs.python.org/3.0/howto/cporting.html#cporting-howto
>  - http://docs.python.org/3.0/library/2to3.html
> 
> Upstream does expect Python-2.x to stay around for a while; Python-3.x
> will need some time until extensions and modules are ported. For this
> reason I do plan to have both Python-2.x and Python-3.x in the next
> stable Debian release.
> 
> Some third party modules and extensions may be released in a form
> where the code for 3.x can be auto-generated from the 2.x code with
> the 2to3 utility, some upstreams may decide to stop 2.x support with
> one version and provide 3.x support with another version. Debian has
> to support both approaches.  The currently used packaging methods only
> allow packaging of one version for all Python version (installing in a
> shared area and providing this version for each Python version).
> Binary packages will double in size when providing both 2.x and 3.x
> compatible code, so it does make sense to provide separate binary
> packages for 2.x and 3.x.  These new packages should be prefixed with
> `python3-' instead of `python-'.  It's up to the package maintainer if
> these packages are built from one or two source packages.
> 
> There will be a `python3' package and similiar packages built out of a
> python3-defaults, which will provide the `python3' binary.
> 
> 
> Local installation path
> ---
> 
> When installing Python modules using distutils, the resulting files
> end up in the same location wether they are installed by a Debian
> package, or by a local user or administrator, unless the installation
> path is overwritten on the command line.  Compare this with most
> software based on autoconf, where an explicit prefix has to be
> provided for the packaging, while the default install installs into
> /usr/local.  For new Python versions packaged in Debian this will
> change so that an installation into /usr (not /usr/local) requires an
> extra option to distutils install command (--install-layout=deb).  To
> avoid breaking the packaging of existing code the distutils install
> command for 2.4 and 2.5 will just accept this option and ignore it.
> For the majority of packages we won't see changes in the packaging,
> provided that the python packaging helpers can find the files in the
> right location and move it to the expected target 

Re: Info on Planet Debian

[Jon Dowland]

On Mon, Feb 16, 2009 at 09:02:06PM +, Jon Dowland wrote:
> On Tue, Nov 25, 2008 at 03:45:53PM +0100, Stefano Zacchiroli wrote:

Apologies. I'd moved some mail filters around and didn't realise I was
reading a stale mailbox!


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

Re: Python related changes for unstable/squeeze

[Josselin Mouette]

Le lundi 16 février 2009 à 20:33 +0100, Matthias Klose a écrit :
> Besides the "normal" pending update of the python version for the
> unstable distribution, there will be more changes around python
> packaging, including the introduction of python-3.x and addressing
> some packaging issues.

It’s nice to have this status update, but why wasn’t this discussed on
debian-python first?

> There will be a `python3' package and similiar packages built out of a
> python3-defaults, which will provide the `python3' binary.

Good. That’s the only sane way to go.

> The use of a common location was proposed in 2006, but didn't get any
> feedback at this time.  Last summer I did choose a name for this
> location, and a large part of packages already install into this
> location `/usr/share/pyshared'.  For code shared between Python-3.x
> installations I propose to use `/usr/share/py3shared'.

Using the /usr/share/py*shared common location in python-support is
technically feasible, but it’s opening the door to letting
python-central break other packages than those using it, so this is
probably not going to happen.

> The choice of packaging helper should not add additional constraints
> on upstream software.  To avoid these problems in the future, exactly
> one location for public python modules shold be used.

I have already explained why it is a bad idea to ship the installed .so
files and the symlinks directly in the /usr/lib/python2.X/site-packages
directories. I am certainly not going to change python-support for this
brokenness.

>  - Not removing symlinked files and not removing byte-compiled files
>during upgrades. This only works reliable if the new version
>does neither remove nor add files, or else an inconsistent set of
>files in a package may be imported during an upgrade.

And that’s also what happens when files are updated by dpkg. At a given
time, there may be an inconsistent set of files installed on the system.

> There is still the issue of handling name space packages based on
> setuptools. Ideally existing techniques like diversions should be used
> for this, even if it looks loke overkill to divert the same empty
> __init__.py file.

Creating empty __init__.py files as needed is the role of the packaging
helper. This is what python-support already does in lenny.

>  - The current policy advises packages to byte-compile only the
>files which a package owns itself. This is not done by several
>packages, with the result that an upgrade caused by a byte-
>compilation error may be attributed to the wrong package (makes
>the upgrade of an otherwise fine package fail).

A problem solved in python-support by using triggers and not failing for
a byte-compilation error.

>  - The removal of a python version will cause the need for massive
>rebuilds. because many python extensions currently have
>dependencies of the form pythonX.Y-foo.  There is nothing what
>can be done now for the upcoming removal, but those dependencies
>should not be there by default.  This is 2.4 of the python policy,
>but many packages tend to ignore that.

There is a very good reason to add these dependencies. Ignoring the
requests to update the policy accordingly is not going to make the
problem disappear magically. Packages must not have a "Provides:
${python:Provides}" field if these dependencies are not present.
Otherwise, packages depending on this incorrectly provided version are
going to fail miserably.


Instead of this nonsense, the move to Python 3 sounds like the perfect
time to finally phase out python-central. Given the flaws in its design
and the lack of correct maintenance, there have already been several
reports of broken upgrades from etch to lenny that have been directly
caused by python-central. If you can’t fix it, please just drop it.

If you really want to improve the overall situation, maybe it is also
the time to think of fixing the interpreter for good instead of adding
layers of symbolic links farms. For example, if it was able to merge
several directory hierarchies in a single module hierarchy - like perl
had been doing in Debian for years before python-support was even
written - the overall needs for Python packaging would be greatly
simplified.

-- 
 .''`.  Debian 5.0 "Lenny" has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and 
  `-told that if you don't install Lenny, he'd melt your brain.


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

Re: Python related changes for unstable/squeeze

[Matthias Klose]

Piotr Oz.arowski schrieb:
>>  - 2.5 is superseded by 2.6; currently there doesn't seem to be
>>a reason to ship 2.5 and modules for 2.5 with the next stable
>>release. The upstream 2.5 maintainance branch doesn't see bug
>>fixes anymore, only security releases will be made from this
>>branch.
> 
> What about a smooth upgrade path for those who use Python2.5 for their (3rd
> party) applications? I think Python 2.6 should be default in Squeeze and 
> Python
> 2.4&2.5 in supported.

always having the default version of the stable release included in the next
release would mean that Debian releases keep up with Python release, or we would
end up shipping more than two 2.x versions. Same if 2.7 gets released in time.

>> The path /usr/lib/pythonX.Y/site-packages is not found on sys.path
>> anymore.
> 
> is "local/" missing in this path or do you want to simply rename site-packages
> into dist-packages?

/usr/local/lib/pythonX.Y/site-packages isn't found in sys.path as well.

>> About the name: Discussed this with Barry Warsaw and Martin v. Loewis,
>> and we came to the conclusion that using the same directory name for
>> both locations would be the most consistent way.
>>
>> This change should make the request to conditionalize the inclusion of
>> /usr/local/lib/pythonX.Y/site-packages into sys.path obsolete.
> 
> if I understand this correctly, local installations (including ez_install 
> ones)
> will use /usr/local/.../site-packages and the ones used by administrators (who
> know about --install-layout=deb) /usr/local/.../dict-packages, and the
> site-packages will not be in default sys.path, right?

No, /usr/local/lib/pythonX.Y/site-packages will only be used if you install your
own python, and use this interpreter to call setup.py install. When using the
python (>= 2.6) provided by Debian without to call setup.oy install
--install-layout=deb, the installation will go to
/usr/local/lib/pythonX.Y/dist-packages, without --install-layout it will go to
/usr/lib/pythonX.Y/dist-packages.

> If yes, then although I love the idea of "solving" the `sudo easy-install
> MyModule` really annoying issue (last time I raised it here[1], see also
> Christoph's "Why you should not use easy_install carelessly on Debian"[2]),
> what's a purpose of having local site-packages if installing there will have 
> no
> effect. Or do you want to keep it for local *Python* interpreter 
> installations?

It is not kept, it is the standard site-packages for "local *Python* interpreter
installations".

> I really like the idea of using the same location for both tools, please note
> that you'll have to change pycentral to use something like /usr/lib/pyshared
> (for Python extensions)

where is the advantage of having a /usr/lib/pyshared?

> yes, that's a problem, but I think we should do it step by step, first:
> all packages should ship .py and .so files in the same directories (so that
> dpkg can handle conflicts again), then we'll think about using common entry in
> sys.path (and/or merging helper tools or making it possible to choose one of
> them to do all the stuff)

I can agree on "later", if it does mean "for squeeze".

>> The disadvantage of this approach is the limitation to a specific set
>> of python versions (the package will have a dependency of the form
>> "python (<< X.Y)", which we already have for architecture dependent
>> packages containing extensions.  This would add this kind of
>> dependency to all architecture independent python-* modules and then
>> requires an upload of these packages for each python transition as
>> well.  Afaics this would not affect a transition or a set of
>> transitions to testing, because no new dependencies on new versions of
>> shared libraries are introduced during these uploads. This approach
>> certainly has an impact on the ftp archive and its mirrors, but I
>> can't say if this would be an issue or not.
> 
> I don't like python (<< X.Y) dependencies, it's so... old-policy like.
> Not a good idea, IMHO

well, just "not liking" is a weak argument.

>>  - The removal of a python version will cause the need for massive
>>rebuilds. because many python extensions currently have
>>dependencies of the form pythonX.Y-foo.  There is nothing what
>>can be done now for the upcoming removal, but those dependencies
>>should not be there by default.  This is 2.4 of the python policy,
>>but many packages tend to ignore that.
> 
> python-support supports namespace packages and it does it good. I didn't want
> it to be enabled by default but since Joss provided a way to disable it (see
> #459468) I think it's OK.
> 
> python-central should implement the same behaviour, IMHO

As I did write above, the support for namespace packages should be implemented
using diversions. It's ok to generate these by a packaging helper.

> Just one more issue: what about "current" issue? Although I protested when
> others wanted to remove it, now I agree it's useless. All packages that

Re: Python related changes for unstable/squeeze

[Josselin Mouette]

Le lundi 16 février 2009 à 22:33 +0100, Matthias Klose a écrit :
> "current" is also useful to only provide a public module for just the default
> version. I'm unsure what you mean with when talking about the above mentioned
> "issue"

Is it a joke? If you don’t know what this is about, why are you even
talking about python packaging? Were you even reading the discussions on
the Python policy when there have been some?

"current" does not mean anything, semantically, especially for public
modules/extensions. There is a set of supported versions, and that’s
all. For extensions, it is the set of versions the extension has been
built against, and for modules, it is the set of versions the module can
work with. In neither of these cases does "current" mean anything.

-- 
 .''`.  Debian 5.0 "Lenny" has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and 
  `-told that if you don't install Lenny, he'd melt your brain.


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

Re: Python related changes for unstable/squeeze

[Ondrej Certik]

Hi Matthias,

thanks for all the work you do. I have one question:

>  - 3.0/3.1: I do not plan to upload 3.0 to unstable or experimental,
>   but will prepare 3.1 packages for experimental and upload those
>   to unstable with the final release or a late release candidate.
>   The 3.1 release is planned for April 2009.

It would really help if Debian had python3.0, becuase it would help
me, as upstream, to port my software. Currently I have to compile
python3.0 from the ubuntu source package. If ubuntu can have it, why
not Debian?

Ondrej


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

Re: Python related changes for unstable/squeeze

[Matthias Klose]

Ondrej Certik schrieb:
> Hi Matthias,
> 
> thanks for all the work you do. I have one question:
> 
>>  - 3.0/3.1: I do not plan to upload 3.0 to unstable or experimental,
>>   but will prepare 3.1 packages for experimental and upload those
>>   to unstable with the final release or a late release candidate.
>>   The 3.1 release is planned for April 2009.
> 
> It would really help if Debian had python3.0, becuase it would help
> me, as upstream, to port my software. Currently I have to compile
> python3.0 from the ubuntu source package. If ubuntu can have it, why
> not Debian?

I will provide packages on people.debian.org, which should help for the upstream
work. python-3.0 is very short lived and I do want to avoid an unnecessary
transition.

  Matthias


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

Bug#515684: ITP: [PACKAGE] -- psi-plus

[ivan]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

--- Please fill out the fields below. ---

Package name: psi-plus
Version: 0.13.r203
Upstream Author: vladimir.shelukhin 
URL: http://code.google.com/p/psi-dev/
License: GPL
Description: This is a Psi mod from psi-...@conference.jabber.ru

Conference: 
+ Specifying the reasons for the kick / ban 
+ Easy to edit and view the topic 
+ Quick change rank and roles from the context menu in roster / chat 
+ Insert nik by click
+ Context menu for nik in the message window 
+ User count
+ Lock avtologin in selected conference (at home / in the various avtologin) 
+ When haylayte - pop up with text message notification 
+ Collapsing conference roster 

Interface: 
+ Saving photo from the vCard 
+ Show photo in vCard full size by clicking 
+ Review of services on the button of the vCard 
+ Avatars contacts in the roster 
+ Icons in the roster of moods (moods icons) 
+ Icons tyunov in the roster (tune) 
+ Ability to turn off skroll-bar in the roster 
+ Display icon in the pop-up notifications 
+ Text messages in pop-up notifications 
+ Button send a message 
+ View the vCard from the context menu for jid in the body of your message 
+ Advanced set of commands to adjust the hotkeys
+ Align Center icon on the button change the status, as in previous versions 
+ Display of icons in the status tabah 
+ The history of writing their own messages on Ctrl + Arrow Up 
+ More contrasting color of the selected text 
+ Switching between tabami on Alt + N 
+ Close / minimize tab pressing the middle mouse button 

System: 
+ Show reports on your messages (XEP-0184: Message Receipts) 
+ Send notices of your messages (XEP-0184: Message Receipts) 
+ Portable Psi without creating a bat-file (for Windows) 
+ Time on Issuance iq request (XEP-0090: Entity Time, XEP-0202: Entity Time) 
+ Ability to set the "class" (XEP-0108: User Activity) 
+ Support for the broadcast stream from the Audacious (for Linux) 
+ Added command "idle" in the console (jabber: iq: last) 
+ Finalization for compatibility with Qt 4.5


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

Re: Bug#515154: ITP: gitg -- git repository viewer for gtk+/GNOME

[Tino Keitel]

On Mon, Feb 16, 2009 at 20:02:09 +0100, Cyril Brulebois wrote:
> Tino Keitel  (16/02/2009):
> > could it be that there is some limitation in the number of
> > files/directories?  It only shows 80 directories here in the tree
> > view, but 173 are present.
> 
> Maybe a bunch of them are empty, which means they are of no interest
> from a git point of view?

No, they are all crowded with files and subdirectories all tracked in
git.

> (IOW: where can one clone from?)

You can't, sorry.

Regards,
Tino


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

Re: Should Debian Live be supported with lenny?

[Daniel Baumann]

Filipus Klutiero wrote:
> You are aware that Debian Live lenny RC1 was released on *2009-02-09*?

no, i didn't know that *kidding*

> I did not see any announcement of that

http://lists.debian.org/debian-live/2009/02/msg00070.html

> I'm not paid to do QA on Debian.

me neither.

> The purpose of this thread is not to improve Debian Live.

fair enough. i stop reading here then.

Regards,
Daniel

-- 
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: Python related changes for unstable/squeeze

[Ondrej Certik]

On Mon, Feb 16, 2009 at 2:15 PM, Matthias Klose  wrote:
> Ondrej Certik schrieb:
>> Hi Matthias,
>>
>> thanks for all the work you do. I have one question:
>>
>>>  - 3.0/3.1: I do not plan to upload 3.0 to unstable or experimental,
>>>   but will prepare 3.1 packages for experimental and upload those
>>>   to unstable with the final release or a late release candidate.
>>>   The 3.1 release is planned for April 2009.
>>
>> It would really help if Debian had python3.0, becuase it would help
>> me, as upstream, to port my software. Currently I have to compile
>> python3.0 from the ubuntu source package. If ubuntu can have it, why
>> not Debian?
>
> I will provide packages on people.debian.org, which should help for the 
> upstream
> work. python-3.0 is very short lived and I do want to avoid an unnecessary
> transition.

Ok, that makes sense. Thanks!

Ondrej


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

Re: AW: Bug#515130: ITP: unrealircd -- Unreal IRC Server

[William Pitcock]

On Mon, 2009-02-16 at 07:56 +0100, Giacomo Catenazzi wrote:
> Rondal wrote:
> > Hi,
> >  
> >> UnrealIRCd has many licensing and code-quality issues which would
> >> block it's inclusion in a Debian release.
> > 
> > I admit that the sourcecode is not of the highest quality, but I do not
> > see where it will block inclusion into Debian. About the licensing issues
> > I already said that their license is incompatible with the OpenSSL license
> > but thats it.
> > 
> > Please be a little bit more specific. If I missed something important
> > within
> > their license or code, I will gladly reconsider building this package.
> 
> IIRC unrealircd will pass to inspiricd sources, so I recommend you to
> evantually pack only the "develpement" version.

That effort is dead. UnrealIRCd itself is basically a walking zombie. We
don't need this in Debian -- it is more trouble than it is worth.

William


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

Re: Bug#515663: ITP: kmess2 -- Windows(R) Live(R) Messenger(R) Client for KDE4.

[William Pitcock]

On Mon, 2009-02-16 at 20:38 +0100, Rafael Belmonte wrote:
> Package: wnpp
> Severity: wishlist
> X-Debbugs-CC: debian-devel@lists.debian.org
> 
> --- Please fill out the fields below. ---
> 
>Package name: kmess2
> Version: 2.0alpha
> Upstream Author: Diederik van der Boor
> URL: http://kmess.org
> License: GPL-2
> Description: Kmess2 is an instant messenger for Windows(R) Live(R)  
> Messenger(R) protocol for KDE4.
> It supports emoticons, drawing, avatar and videoconference.
> 

A better description is needed. The first line should be short and
lowercase.

The second part should be at least a paragraph.

William


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

Re: Python related changes for unstable/squeeze

[Michal Čihař]

Hi

[I agree that this should have have been sent also to debian-python]

Dne Mon, 16 Feb 2009 20:33:48 +0100
Matthias Klose  napsal(a):

>  - 3.0/3.1: I do not plan to upload 3.0 to unstable or experimental,
>but will prepare 3.1 packages for experimental and upload those
>to unstable with the final release or a late release candidate.
>The 3.1 release is planned for April 2009.

I would be great to have also 3.0.x (even in experimental and with no
third party modules at all). At least for us who also wear an upstream
hat sometimes.

> This change should make the request to conditionalize the inclusion of
> /usr/local/lib/pythonX.Y/site-packages into sys.path obsolete.
> 
> If needed we can provide a symlink /usr/lib/pythonX.Y/site-packages
> pointing to dist-packages.

Does this mean that /usr/local/lib/pythonX.Y/site-packages is meant for
custom installation of Python in /usr/local/,
while /usr/local/lib/pythonX.Y/dist-packages for packages for Python
shipped in Debian? That looks like too complicated to me and it will
lead to mistakes, when single directory (/usr/local/lib/pythonX.Y) is
supposed to be partly used by two different Python installations.

> Various
> ---
> 
> There are other things which may be worth a look.

- Can you guys please finally sit down and agree on one solution for
  handling python modules? I still think that having two (slightly
  different) ways of doing this task is not the way to go. I really do
  not see technical reason for this situation. I have  no preference at
  all and I'm actually using both things in my packages, but I really
  do not think it is way to go. And it would be great if we can have
  single tool, which gets more testing and will have less bugs than
  current concurrent solutions.

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


signature.asc
Description: PGP signature

Re: Python related changes for unstable/squeeze

[Ondrej Certik]

>> Various
>> ---
>>
>> There are other things which may be worth a look.
>
> - Can you guys please finally sit down and agree on one solution for
>  handling python modules? I still think that having two (slightly
>  different) ways of doing this task is not the way to go. I really do
>  not see technical reason for this situation. I have  no preference at
>  all and I'm actually using both things in my packages, but I really
>  do not think it is way to go. And it would be great if we can have
>  single tool, which gets more testing and will have less bugs than
>  current concurrent solutions.

I strongly support this. I also use both in my packages and I would
prefer if there was just one way. I don't mind which.

Ondrej


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

Re: Python related changes for unstable/squeeze

[Ben Finney]

Matthias Klose  writes:

> Local installation path
> ---
[…]

>  - /usr/lib/pythonX.Y/dist-packages (installation location for code
>packaged for Debian)
>  - /usr/local/lib/pythonX.Y/dist-packages (installation location
>for locally installed code using distutils install without
>options).
> 
> The path /usr/lib/pythonX.Y/site-packages is not found on sys.path
> anymore.
> 
> About the name: Discussed this with Barry Warsaw and Martin v. Loewis,
> and we came to the conclusion that using the same directory name for
> both locations would be the most consistent way.

I like this change; it's a good step toward making Python distribution
work on Debian more like everything else on Debian. Congratulations
for all involved in making this happen, and thank you for discussing
(and getting consensus) with the Python core developers too.

-- 
 \“There are no significant bugs in our released software that |
  `\ any significant number of users want fixed.” —Bill Gates, |
_o__)   1995-10-23 |
Ben Finney


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

Re: Proposed release goal: fix debian/rules build-arch

[Steve Langasek]

On Mon, Feb 16, 2009 at 11:21:42AM -0800, Russ Allbery wrote:
> There are also the few packages in the archive that don't have a makefile
> as debian/rules.  I've been tempted for some time to file RC bugs against
> all of them.

> http://lintian.debian.org/tags/debian-rules-not-a-makefile.html

Interestingly, all but one of these is a false positive, at least in the
sense of whether debian/rules is a makefile.  The vdr packages don't use
/usr/bin/make as the interpreter line, but debian/rules *is* a makefile -
they just have a rather convoluted custom script that they use to set up the
environment before calling make.

That leaves just 'leave' which is using a shell script as debian/rules.
Every time this issue has come up before, Josip has stuck to his guns on
using a non-makefile for this package; but it is a policy violation, and if
being able to rely on debian/rules being a makefile helps us finally unblock
the build-arch mess, I don't think it's defensible.  I'm all in favor of
enforcing this policy dictum as RC for squeeze.

> > Policy would match the current usage, right then.  This is not what I'd
> > like to see, since I think that a reliable build-arch would be a really
> > nice thing to have.

> I have to admit that I'm tempted by this approach, mostly because it's not
> clear to me that the build-arch vs. build-indep separation actually gains
> us anything that useful.  The point, so far as I can tell, is to save
> buildd time by not building the architecture-independent packages.  How
> much time would we actually be saving?  Is it worth putting a lot of human
> effort into making that situation possible?  Generally CPU cycles are far,
> far cheaper than human cycles.

In some cases, building the arch-indep documentation takes longer, and
requires downloading/installing more build dependencies, than building the
arch-dep binaries.  I've found this to be a waste of human cycles before
when building packages locally: since it's not possible to bypass the
"build-indep" component in a sane fashion, I wind up waiting on the
arch-indep bits when trying to test out a patch that only affects the
arch-dependent parts of the package.  If the doc building is expensive
enough to be noticeable to me when building on amd64, I would imagine that
the impact on buildds (and hand builds) for slower archs is significant,
too.

If we can ever settle on a suitable implementation, I would expect the
savings of both human and CPU cycles to be sizeable, and worth the effort.

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

Re: Python related changes for unstable/squeeze

[Felipe Sateler]

Josselin Mouette wrote:

> Le lundi 16 février 2009 à 22:33 +0100, Matthias Klose a écrit :
>> "current" is also useful to only provide a public module for just the default
>> version. I'm unsure what you mean with when talking about the above mentioned
>> "issue"
> 
> Is it a joke? If you don’t know what this is about, why are you even
> talking about python packaging? Were you even reading the discussions on
> the Python policy when there have been some?
> 
> "current" does not mean anything, semantically, especially for public
> modules/extensions. There is a set of supported versions, and that’s
> all. For extensions, it is the set of versions the extension has been
> built against, and for modules, it is the set of versions the module can
> work with. In neither of these cases does "current" mean anything.

But it does mean something. Modules which build from C sources have to be built
for each version it wants to support, right? Maybe "current" is an arbitrary,
unjustified choice, but it means that C modules which only build once don't
will only work with that version.

-- 

  Felipe Sateler


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

Re: Proposed release goal: fix debian/rules build-arch

[Russ Allbery]

Steve Langasek  writes:

> Interestingly, all but one of these is a false positive, at least in the
> sense of whether debian/rules is a makefile.  The vdr packages don't use
> /usr/bin/make as the interpreter line, but debian/rules *is* a makefile
> - they just have a rather convoluted custom script that they use to set
> up the environment before calling make.

Which means that if you call make on it directly, it doesn't work, since
the environment variables aren't set and all the stuff that shell script
does then isn't done.  I don't really agree that it's a false positive,
although I agree that it will happen to work given how we currently build
packages.

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


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

Re: Bug#515663: ITP: kmess2 -- Windows(R) Live(R) Messenger(R) Client for KDE4.

[Sune Vuorela]

On Monday 16 February 2009 20:38:38 Rafael Belmonte wrote:
> Package: wnpp
> Severity: wishlist
> X-Debbugs-CC: debian-devel@lists.debian.org
>
> --- Please fill out the fields below. ---
>
>Package name: kmess2
> Version: 2.0alpha
> Upstream Author: Diederik van der Boor
> URL: http://kmess.org
> License: GPL-2

What's the advantage of keeping kmess and kmess2 in the archive in parallel ?

Have you coordinated with the kmess maintainers?

And please take a look at pkg-kde-tools when eventually packaging it.

/Sune
-- 
I cannot rename the mail from Internet Explorer, how does it work?

You should telnet on a board to debug a wordprocessor of the software over the 
clock on the provider.


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

Re: Proposed release goal: fix debian/rules build-arch

[Charles Plessy]

Le Mon, Feb 16, 2009 at 10:16:56PM +0200, Kari Pahula a écrit :
> 
> Another thing that B-D-I is good for: breaking dependency cycles.  An
> example from the upcoming version of ghc6: ghc6 uses haddock to build
> API docs.  Haddock needs to be built with the same version of ghc6 it
> generates docs for.  Putting haddock in ghc6's B-D-I avoids that
> cycle.

Hello everybody,

maybe Build-Recommends could also solve this…

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


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

Re: ode 0.11 transition

[Adeodato Simó]

* Gonéri Le Bouder [Mon, 16 Feb 2009 00:34:51 +0100]:

> On Sun, Feb 15, 2009 at 11:11:04PM +0100, Adeodato Simó wrote:

> > I'd like to suggest ithat you upload again to experimental, but having
> > libode-dev Provide: libode0-dev. Then you ask reverse dependencies for
> > feedback, in particular if they can be recompiled without any source
> > change and continue to work. If that's the case, we keep the Provides
> > when uploading to unstable, and do binNMUs. Only if *all* reverse
> > dependencies need source changes to compile with the new version it'd be
> > okay to drop the Provides when uploading to unstable.

> > Once the transition is done (and only then), you can submit bugs at
> > non-RC severity against your reverse dependencies asking for a change
> > libode0-dev -> libode-dev in their Build-Dependencies, and you can drop
> > the provides once all bugs are fixed *and migrated to testing*.

> > Does this sound doable to you?

> ok, it's a much better plan. I added the Provides: in freshly uploaded 
> ode 0.11-3.

Great, thank you.

> > Also, it would be really nice if you could mail -release to get a spot
> > for this transition, like everybody else. From a quick look it's quite
> > an isolated transition, so it should be able to get the "go" very soon.
> Fine,

> Thank you for your valuable feedback and sorry for the noise.

No apology needed, thanks for your cooperation!

-- 
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: AW: Bug#515130: ITP: unrealircd -- Unreal IRC Server

[William Pitcock]

On Mon, 2009-02-16 at 08:37 +0100, Patrick Schoenfeld wrote:
> On Sun, Feb 15, 2009 at 09:00:22PM -0600, William Pitcock wrote:
> > There is also questions concerning why you would want to package
> > something that has effectively a dead upstream, and many code flaws
> > which could result in security issues in the future.
> 
> Uh? Since when is Unrealircd dead upstream? I wouldn't call a release
> less then a month ago "dead upstream", regardless of what can be
> said about unrealircd otherwise.

Once 3.2.8 final is out the door, it will be stagnant. "Syzop" has a
fairly large slacker attitude, and is only interested in Unreal for the
money (oops, it doesn't make any for him anymore. especially not now
with InspIRCd).

As such, we can call Unreal dead now, barring some miracle -- but I
don't see this happening with next generation ircd picking up steam like
InspIRCd - which cater to that same market of IRC admin which would be
interested in Unreal.

William


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

debian/rules being or not a makefile (was: Re: Proposed release goal: fix debian/rules build-arch)

[Charles Plessy]

Le Mon, Feb 16, 2009 at 03:34:41PM -0800, Steve Langasek a écrit :
> On Mon, Feb 16, 2009 at 11:21:42AM -0800, Russ Allbery wrote:
> > There are also the few packages in the archive that don't have a makefile
> > as debian/rules.  I've been tempted for some time to file RC bugs against
> > all of them.
> 
> > http://lintian.debian.org/tags/debian-rules-not-a-makefile.html
> 
> I'm all in favor of enforcing this policy dictum as RC for squeeze.

Hi again,

It seems that making debian/rules a symbolic link to /usr/bin/dh might actually
work for some packages (although I have not yet tried), so it could be the
perfect timing to double-think whether it is not as heretic as it looks, as
long as it would follow the Policy requirements about the expected result of
"debian/rules clean build binary" (and binary-arch and binary-indep if the
ongoing discussion does not end up in their deprecation).

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


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

Re: debian/rules being or not a makefile

[Russ Allbery]

Charles Plessy  writes:

> It seems that making debian/rules a symbolic link to /usr/bin/dh might
> actually work for some packages (although I have not yet tried), so it
> could be the perfect timing to double-think whether it is not as heretic
> as it looks, as long as it would follow the Policy requirements about
> the expected result of "debian/rules clean build binary" (and
> binary-arch and binary-indep if the ongoing discussion does not end up
> in their deprecation).

Why would we want to sanction that when the same effect can be achieved by
using a debian/rules of:

#!/usr/bin/make -f
%:
dh $@

without risking breaking any existing assumptions or software?

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

Post-Lenny discussion on packages with external (potentially non-free) dependencies

[Michael S. Gilbert]

Dear All,

First of all, congratulations on getting the Lenny release out the
door!  I understand that it was a lot of work, and you're probably
looking forward to at least somewhat of a break.  So I don't want
to treat this problem with too much urgency (yet), but I would like to
get a dialog going as people find the time to weigh in with their
opinions.

In the following, I recap the core problems at hand (listed in terms of
importance/relevance) and the arguments on both sides that have been
developed in the bug report [1].

Summary of the problem: Some packages such as foo2zjs, pciutils,
ttf-mathematica4.1, etc. have components that download files external
to the Debian archives (from the internet) at runtime, which is
problematic in many ways.

1.  Provides a potential avenue for introducing malicious software onto
users' systems

Argument: Since the standard checks and balances (digital signing of
packages by developers) is circumvented by fetching files from an
unreliable source, it is possible for an attacker to either hijack or
spoof the upstream site to introduce malicious software onto users'
systems.  This may seem obscure, for example, for foo2zjs's printer
firmwares, but the getweb script does provide an update mechanism, so
the attacker could use that to introduce his malicious code.
Regardless of how obscure an attack vector may be, I just don't think
that it is worth the risk to allow it to remain open.

Rebuttal: "Since this script explicitely downloads stuff from an
author's webpage (and it is stated like that), the user knows the risk.
Are you proposing to call this a security issue? Then packages like
iceweasel are also affected and many others ..."

Response: The user may not, and likely does not, fully appreciate the
risk. I'm sure that most users trust that the Debian developer has
considered and appropriately mitigated the risk for them, or more
likely, they do not consider risk at all.  They just use their
computer.  Iceweasel is not a very good analogy because it is
generally not run as root and is not permitted to execute downloaded
files without a smart (chmod'ing) user involved.

2.  Components of the package may stop working in the midst of a
stable release's lifetime

Argument: Since the location and composition of external files is
outside of the package maintainer's control, upstream changes can break
stable scripts.

Rebuttal: This is a simple bug.  If it happens, "we'll fix it, full
stop."

Response: This may be a permissable fix for a stable point release,
but it leaves the system potentially broken for an indeterminant
amount of time (e.g. foo2zjs's getweb in etch was broken for over a
year) between those releases (depending on when the break happens).
This also depends on users' willingness to report bugs in stable.  This
usually doesn't happen because people know that stable is stable and
doesn't get changed.  It may also be possible to address this problem
via maintainence in volatile, but do they want to take on more
responsibility?

3.  Allows packages in main to depend on external files, violating the
spirit of the Debian Policy

Argument:  Section 2.2.1 of the Debian Policy Manual states that
"...packages in main must not require a package outside of main for
compilation or execution...," and section 2.2.2 states that "[e]xamples
of packages which would be included in contrib are free packages which
require contrib, non-free packages or packages which are not in our
archive at all for compilation or execution, ..."  This seems to make
it very clear that external dependencies are unacceptable in terms of
"packages," but does not make clear the policy on general data and
files.  However, given an honest attempt at interpretation, it would
seem that the same conclusion shoud apply equally to general files as
well as packages.

Rebuttal 1: This is a grey area of Debian Policy, and a litteral
interpretation of the manual says that the current behavior is OK.

Response 1: We shouldn't make judgements based solely on the wording as
written, but instead based on the original intent of the author (as
an aside, this is why the judicial branch's role in the government is
so complicated and controvercial). Just because the writer chose to use
the term "package" does not mean that they did not intend to cover all
files in general.

Rebuttal 2: Objection to single script packages (maintainers do not
want to maintain separate packages in contrib that contain only these
externally depending scripts). 

Response 2: Decisions should not be made based on potential
inconveniences or work load.  Besides, it is not that difficult to build
and maintain additional binary packages.  The offending scripts can
remain within the original the source packages.

4.  Parts of the package work as intended only under certain
circumstances

Argument: Since an internet connection is not guaranteed on the user's
end, the program does not work as intended when the net is either down
or unavailable. 

Build-indep as a way to not build doc. (was: Re: Proposed release goal: fix debian/rules build-arch)

[Charles Plessy]

Le Mon, Feb 16, 2009 at 03:34:41PM -0800, Steve Langasek a écrit :
> In some cases, building the arch-indep documentation takes longer, and
> requires downloading/installing more build dependencies, than building the
> arch-dep binaries.  I've found this to be a waste of human cycles before
> when building packages locally: since it's not possible to bypass the
> "build-indep" component in a sane fashion, I wind up waiting on the
> arch-indep bits when trying to test out a patch that only affects the
> arch-dependent parts of the package.  If the doc building is expensive
> enough to be noticeable to me when building on amd64, I would imagine that
> the impact on buildds (and hand builds) for slower archs is significant,
> too.
> 
> If we can ever settle on a suitable implementation, I would expect the
> savings of both human and CPU cycles to be sizeable, and worth the effort.

If the problem is limited to local building of packages without their
documentation, maybe we can consider push forward the DEB_BUILD_OPTION "nodoc".
This would also help in the case the same problem happens, but with
documentation that is not in an arch=all package.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


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

Re: Build-indep as a way to not build doc. (was: Re: Proposed release goal: fix debian/rules build-arch)

[Steve Langasek]

On Tue, Feb 17, 2009 at 02:39:59PM +0900, Charles Plessy wrote:

> > If we can ever settle on a suitable implementation, I would expect the
> > savings of both human and CPU cycles to be sizeable, and worth the effort.

> If the problem is limited to local building of packages without their
> documentation, maybe we can consider push forward the DEB_BUILD_OPTION 
> "nodoc".

It doesn't solve the problem that anything needed for the build target has
to be listed in Build-Depends instead of Build-Depends-Indep, so these
packages need to be downloaded/installed unless you start hand-hacking
around this in the package or in the build tools.[1]  But then again,
there's no metadata to tell you which build-dependencies you can ignore when
you're not building docs, so you get to do this by trial and error, which
rather neutralizes the intended time-saving benefits.

Whereas Build-Depends-Indep was always intended to be used for precisely
this, and only the "build-arch" detection problem prevents it being used
this way.

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

[1] Some document-processing packages (TeX) have quite intensive maintainer
scripts, and are also non-negligible in size.


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

Re: Post-Lenny discussion on packages with external (potentially non-free) dependencies

[Don Armstrong]

On Tue, 17 Feb 2009, Michael S. Gilbert wrote:
> In the following, I recap the core problems at hand (listed in terms of
> importance/relevance) and the arguments on both sides that have been
> developed in the bug report [1].
> 
> Summary of the problem: Some packages such as foo2zjs, pciutils,
> ttf-mathematica4.1, etc. have components that download files external
> to the Debian archives (from the internet) at runtime, which is
> problematic in many ways.
> 
> 1. Provides a potential avenue for introducing malicious software
> onto users' systems

In the case of foo2zjs and pciutils, the software/data is not
downloaded automatically, but at the specific request of an admin by
running a special script.

It would be ideal if foo2zjs and pciutils had a mechanism to verify
that the files downloaded matched the expected contents by the use of
SHA256, gpg or some other file verification function. Since in neither
case should the downloaded files be executed directly (though I
suppose a specially crafted firmware would be annoying) this doesn't
seem like a serious security problem, but a wishlist bug.

In the case of ttf-mathematica4.1, the md5sum is verified by the
postinst script, so while it may be the case that this should be
changed to a more secure hash algorithm, it's still reasonable.

> 2. Components of the package may stop working in the midst of a
> stable release's lifetime

It is probably reasonable to make these scripts as flexible as
possible to find the proper location, and to allow users to easily
override the location in cases where it's changed. Again, a case where
a wishlist bug with a patch attached would most likely be accepted.
[In the case of ttf-mathematica4.1, since it doesn't fail the install,
and just complains, this isn't too bad.]
 
> 3. Allows packages in main to depend on external files, violating
> the spirit of the Debian Policy

ttf-mathematica4.1 isn't in main, and foo2zjs and pciutils don't
require a package outside of main for compilation and execution. It's
perfectly ok for packages outside of main to provide additional
functionality to packages in main, since that doesn't form a Depends:
relationship. [Compare and contrast foo2zjs with the linux kernel, for
example.]

> Hence, non-free components (if they are to be supported at all)
> should be included in the non-free archive instead of fetched
> externally.

In order for this to occur, Debian must be able to distribute the
firmware. I'm not sure that this is the case for foo2zjs; it's
certainly not the case for ttf-mathematica4.1, and we already
distribute the pciids for pciutils.

> Argument: This is a hard argument to make, but since main is
> supposed to be 100% free, it only makes sense that all dependencies
> shoud be free as well.

The only thing we require is that the required dependencies, that is,
those things that form a Depends: relationship be free, not that
everything that could possibly enhance the operation of a package be
free. Obviously, the latter is the ideal state, but it's not a
requirement.
 

Don Armstrong

-- 
Our days are precious, but we gladly see them going
If in their place we find a thing more precious growing
A rare, exotic plant, our gardener's heart delighting
A child whom we are teaching, a booklet we are writing
 -- Frederick Rükert _Wisdom of the Brahmans_ 
 [Hermann Hesse _Glass Bead Game_]

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

Personal invitation from Brijkishor tiwary

[Brijkishor tiwary]

Personal invitation from Brijkishor tiwary

Re: Post-Lenny discussion on packages with external (potentially non-free) dependencies

[Luk Claes]

Michael S. Gilbert wrote:

> Summary of the problem: Some packages such as foo2zjs, pciutils,
> ttf-mathematica4.1, etc. have components that download files external
> to the Debian archives (from the internet) at runtime, which is
> problematic in many ways.

If possible, the to be downloaded data should be packaged so most of
below problems are solved or mitigated.

> 1.  Provides a potential avenue for introducing malicious software onto
> users' systems

Well, input validation is very common for web applications. The
validation can consist of verifying the structure or a checksum etc, but
should always be present IMHO.

> 2.  Components of the package may stop working in the midst of a
> stable release's lifetime
> 
> Argument: Since the location and composition of external files is
> outside of the package maintainer's control, upstream changes can break
> stable scripts.

If possible the package should self adjust to or give the user the
opportunity to influence the location of the external files. Sometimes
it's possible to fallback to a location under the maintainer's control
so the package will continure to work.

If that's not possible, the package should not be included in the stable
release itself IMHO and people are encouraged to discuss the inclusion
in the volatile archive.

> 3.  Allows packages in main to depend on external files, violating the
> spirit of the Debian Policy

Like Don explained it could be a convenience script, in that case the
package is not really depending on the external files.

Not packaging external files because it would be too small packages is
not an argument IMHO as it could get included in the package itself in
that case or similar things can be packaged together.

> 4.  Parts of the package work as intended only under certain
> circumstances
> 
> Argument: Since an internet connection is not guaranteed on the user's
> end, the program does not work as intended when the net is either down
> or unavailable.  For example, a user with a printer supported by
> foo2zjs's getweb will not be able to make that printer work if they use
> their machine as a standalone.  As much of Debian as possible should be
> fully functional even when standalone.  Hence, non-free components (if
> they are to be supported at all) should be included in the non-free
> archive instead of fetched externally.
> 
> Rebuttal: None yet.

Well yes, depending on an internet connection should be avoided if possible.

> 5.  Allows packages in main to potentially depend on non-free files

If the functioning of the package needs the non-free files, it is not
just a convenience script, and I would put the package in contrib.

Cheers

Luk


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

Re: Is the FHS dead ?

[Giacomo Catenazzi]

Josselin Mouette wrote:
> Le lundi 16 février 2009 à 18:08 +0200, Teodor a écrit :
>> There is no need to create another standard, FHS is being continued in
>> the LSB project at linuxfoundation.org / freestandards.org. FHS was
>> the starting point for LSB.
>> Even if the LSB project has been criticized by the Debian project,
>> this seems to become the "the facto" file hierarchy standard for
>> Linux. It is not perfect, but is being adopted by the majority of
>> Linux distros.
> 
> Nevertheless, the Linux Foundation hasn’t made evolve the standard for 5
> years. Where could we start if we want the standard to evolve? 
> 
> Currently, the discussion is clearly happening at other levels. If you
> look at the recent cgroups discussion for example, it will clearly be
> decided at the distribution level, without any kind of standardization.

Is not this the right thing to do?

Standards should be most frozen as possible. I don't find a lot of
think that need to be added.

Also for cgroups, I really hope that proposal come from distributions
(and common usage). Only after one distribution use it, it need to
be standardized.  IMHO standards should come from bottom.
BTW, You know, there are a lot of details and possible
problems, so better to wait, not to have a wrong standardization,
which cause more problem to correct.

Anyway, I think that we must give new live to fhs mailing list
(also for discussion, not only for proposal).

ciao
cate


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

Bug#515718: [general] live: failures at shutdown on USB flash drive

[Filipus Klutiero]

Package: general
Version: 5.0.0
Severity: normal

When shutting down Debian Live running from a USB flash drive, one gets a 
bunch of errors on tty1:

Cleaning up ifupdown
Unmounting temporary filesystems...umount: /live/cow: device is busy
umount: /live/cow: device is busy
umount: /live: device is busy
umount: /live: device is busy
failed.
Deactivating swap...done.
Unmounting local filesystems...umount2: No such file or directory
umount: /filesystem.squashfs: not found
umount2: Device or resource busy
umount: /dev/sda1 busy - remounted read-only
failed.
live-initramfs is resyncing snapshots and caching reboot files...

Please remove the USB flash drive and press ENTER to continue:

Apparently, Debian Live doesn't have persistence by default, so that's just 
not pretty.



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

Bug#515721: [general] live: disk1 boot method fails

[Filipus Klutiero]

Package: general
Version: 5.0.0
Severity: normal

Debian Live's disk1 boot method (F4, Boot from the first hard disk) fails on 2 
PCs from 2 tested with

Could not find kernel image: disk1

I do not have any computer with 2 HDDs, so I didn't try disk2.
I got this with 
http://cdimage.debian.org/cdimage/release/5.0.0-live/i386/usb-hdd/debian-live-500-i386-kde-desktop.img
 
and the equivalent RC 1 image.



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

Re: Bug#515154: ITP: gitg -- git repository viewer for gtk+/GNOME

[Tollef Fog Heen]

]] Dmitrijs Ledkovs 

| 2009/2/15 Gunnar Wolf 
| >
| > Tollef Fog Heen dijo [Sat, Feb 14, 2009 at 06:42:37PM +0100]:
| > > | when i've had to do this in the past i think i did something like
| > > | ~.git..  this way you get lots of relevant info, 
the
| > > | fact that it's a prerelease of , the date the snapshot was taken,
| > > | the fact that it's a git snapshot, and the sha sum.   and of course it's
| > > | sortable.
| > >
| > > If you use $vers~$ymd.git.$sha or something like that, please do make
| > > sure the version number slightly bigger than zero.  Having version
| > > numbers that are positive and less than 0 sometimes breaks tools.
| >
| > Given that I kept staring at your message thinking something just went
| > wrong, I suppose somebody else might fall in that logic trap: How can
| > something be "positive but not bigger than zero"? 0~20090215 is. Nice
| > math-breaking rules we had to introduce here :)

Yes, it's quite confusing.

| Is it the -0 from the limits theory =D
|
| Or -0 is negative?

No.  It's a positive (version) number smaller than both -0 and 0.  (To
make matters worse, there's not just one of those, there's an infinity
of them (0~1 is also smaller than 0, so is 0~n for all n).

I think the fix here is «don't think the version number is a normal
number», because it isn't.

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


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

Re: Emdebian version strings and the BTS

[Tollef Fog Heen]

]] Neil Williams 

| if you start seeing bugs or getting email about your packages where the
| version string ends in em[0-9], or where dependencies mentioned by
| reportbug include such a version suffix, the user is running one of the
| two Emdebian distributions released alongside lenny (and based on lenny
| packages). You might also see Emdebian in the output of 'apt-cache
| policy' if your bug reports request or supply such data.
| 
| If there is any doubt that the bug is present in Debian, please
| immediately re-assign the bug to the buildd.emdebian.org pseudo-package
| in the BTS.

Why should those bugs not first be filed in the emdebian bug tracker and
if appropriate filed in the Debian BTS too?  This is what other, say,
Ubuntu do.  At least for your
recompiled-with-other-options-and-random-bits-stripped-out variant, this
seems much more appropriate than assuming the bugs actually exists in
Debian in the first place.

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


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