Re: Upload of dpkg 1.13.23 (Was: Re: How are things going?)

[Andreas Barth]

* Guillem Jover ([EMAIL PROTECTED]) [061012 03:29]:
> On Fri, 2006-10-06 at 21:58:39 +0300, Guillem Jover wrote:
> > On Fri, 2006-09-29 at 22:35:33 -0700, Steve Langasek wrote:
> > > Carry on :-)
> > 
> > Ok, there has been one last commit to svn, and I'd like approval
> > before the planned upload for today. Attached the diff. And here's
> > both changelogs entries.
> 
> I've reverted Brendan's commit (after my mail interchange with him)
> for now as I didn't get any reply from the RMs. I'm going to target
> this patch for the next and last dpkg upload before the etch release.

Actually, it becomes hard for me to follow if a full thread is CCed to
-release. If it is a single mail, it is easier.

I don't mind the patch (in both directions), as long as you assure you
have tested it properly.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Upload of dpkg 1.13.23 (Was: Re: How are things going?)

[Guillem Jover]

On Fri, 2006-10-06 at 21:58:39 +0300, Guillem Jover wrote:
> On Fri, 2006-09-29 at 22:35:33 -0700, Steve Langasek wrote:
> > Carry on :-)
> 
> Ok, there has been one last commit to svn, and I'd like approval
> before the planned upload for today. Attached the diff. And here's
> both changelogs entries.

I've reverted Brendan's commit (after my mail interchange with him)
for now as I didn't get any reply from the RMs. I'm going to target
this patch for the next and last dpkg upload before the etch release.

regards,
guillem


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

Re: Dpkg testing framework, take 5 (was: Re: How are things going?)

[Ian Jackson]

Esteban Manchado Velázquez writes ("Re: Dpkg testing framework, take 5 (was: 
Re: How are things going?)"):
> On Sun, Oct 08, 2006 at 03:36:16PM +0200, Nicolas François wrote:
> > Is the testsuite intended to be run at build time, or manually?
> 
> My initial idea was manually, mostly because it fits my testing style
> better, but I don't know.

If the tests do not take an inordinate time to run (as a rule of
thumb, if they're not more time-consuming than the build itself) then
you should run them automatically as part of the build.  Otherwise
they should be left to be run manually.

I would also like to make a request: please try to make it relatively
straightforward to run the tests on the installed version of the
package, on the running system, as well as in the obvious `playground'
style.  This will make whole-system testing much easier.

In particular, it will make it easier to grind my automated in-system
testing axe (http://wiki.ubuntu.com/AutomatedTesting).

Ian.

Re: How are things going?

[Ian Jackson]

Guillem Jover writes ("Re: How are things going?"):
> On Fri, 2006-09-29 at 22:35:33 -0700, Steve Langasek wrote:
> > Carry on :-)
> 
> Ok, there has been one last commit to svn, and I'd like approval
> before the planned upload for today. Attached the diff. And here's
> both changelogs entries.

I'm pretty sure this diff is safe but it seems odd.  Why not just
  use POSIX;
at the top of the script ?

Ian.


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

Re: Dpkg testing framework, take 5 (was: Re: How are things going?)

[Esteban Manchado Velázquez]

Hi Nicolas!

On Sun, Oct 08, 2006 at 03:36:16PM +0200, Nicolas François wrote:
> Hi Esteban,
> 
> I had a look at the testsuite.
> 
> It basically fulfill my requirements:
>   * I'm able to read the results of the testsuite
>   * I'm able to write tests

Great :-)

> Just a few things (not really related to the test environment, but more on
> the current tests)
> [...]

OK, thanks for your comments. There's LOTS of things I want to change,
that was just an experiment, a proof of concept.  I would like to document it,
integrate it well with the dpkg codebase, and fix the obvious bits _before_ it
getting into some SCM.

If nobody has anything against it, I will begin that clean up and
documentation work, so I get it in shape to let it enter the repository...

> Is the testsuite intended to be run at build time, or manually?

My initial idea was manually, mostly because it fits my testing style
better, but I don't know. Perhaps we could leave that as manually, _but_ show
some note when the build is complete, telling the user how to run the test
suite :-?

> I would like to see it in the dpkg repository, I don't think it's
> necessary to distribute it with the source package. If it does not
> interfer with the current build (does not change the source & binary
> packages), it would be nice to have it in trunk, otherwise in a separate
> branch.

AFAIK, it should never need any changes to the source, except:

1) Some change to the main Makefile, if you want the testsuite to be
executed from the tree root (not the case)
2) Any refactoring you may need to make the code unit-testable (not the
case, either).

Regards,

-- 
Esteban Manchado Velázquez <[EMAIL PROTECTED]>
EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es
Help spread it through the Net in signatures, webpages, whatever!


signature.asc
Description: Digital signature

Re: Dpkg testing framework, take 5 (was: Re: How are things going?)

[Nicolas François]

Hi Esteban,

I had a look at the testsuite.

It basically fulfill my requirements:
  * I'm able to read the results of the testsuite
  * I'm able to write tests

Just a few things (not really related to the test environment, but more on
the current tests)
  * can you mention the dependencies of the testsuite (the check and
libtest-unit-perl packages), in a README file
  * I would like to see the testsuite able to test builds done from a
subversion working directory (objects and binaries are compiled in the
build-tree directory)
  * libdpkg.a is not in ../lib
  * dpkg-scanpackages should be ../script/dpkg-scanpackages.pl
(it may require some changes to be runnable from the source
directory)
Currently, on my system, the dpkg-scanpackages test check the
dpkg-multicd implementation.

Is the testsuite intended to be run at build time, or manually?

I would like to see it in the dpkg repository, I don't think it's
necessary to distribute it with the source package. If it does not
interfer with the current build (does not change the source & binary
packages), it would be nice to have it in trunk, otherwise in a separate
branch.
It could be nice to play with the testsuite during the freeze.

Kind Regards,
-- 
Nekral


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

Re: Dpkg testing framework, take 5 (was: Re: How are things going?)

[Esteban Manchado Velázquez]

Hi,

On Thu, Oct 05, 2006 at 01:52:29PM +0200, Raphael Hertzog wrote:
> [...]
> I bet for lack of time... all the dpkg developers that I know are
> reasonable and wouldn't want to throw away the work of someone else if he
> has taken care to ask for regular review of his work.

OK, thanks for your reply.


> Ian Jackson said he's ready to give advice on dpkg developement in
> general. Furthermore it did some groundwork on a testing framework for
> Ubuntu (it was a package testing framework), so I'm sure that he could
> review your work in that area.

OK, I would love to have some comments/criticism from Ian (and anybody
else, for that matter).


> Just go ahead!

Right now there are two proposals. If people want to review them and make
some comments, but lack the time to review both, _please_ ignore the first
proposal (well, even if you have lots of free time: begin with the _second_
one and only review the first if you don't like the second).

Just to try to speed things up, I have prepared a kind of executive
summary. But before that, PLEASE TAKE INTO ACCOUNT: *testing is way easier
than it seems*, it you don't understand terms or want to help but think it's
too hard, please don't think so, and ask whatever you want. We could even
arrange an IRC meeting to make a demo, explain the framework or the underlying
ideas, or just to discuss the design of the whole thing.

- 8< -
Dpkg Testing Framework Proposals Executive Summary
==

Both proposals
--
The main idea is integrate both unit and functional testing for both C-based
and Perl-based programs. If new utilities appear in other languages, of course
the tests for them should be integrated in the same system.

Right now both proposals are proofs of concept with examples of C
unittesting[1] and Perl utilities functional testing [3].  One of the most
important features of the system would be _not_ to force the developers to
write all the testing code themselves: when possible, micro-formats, simple
text files, macros and other tools will be used to ease common cases.

Second proposal
---
Uses Test::Unit, a xUnit-style module for Perl. The main advantage over the
first proposal are: (1) more dpkg hackers know Perl than Tcl, and (2) we
already have Perl code in the dpkg codebase (related utilities as
dpkg-parsechangelogs), so it's easier to integrate unit tests for those cases.
Another advantage is that xUnit is very well thought, and that probably most
testing-aware guys know xUnit in _some_ language, so they will be more
comfortable with a xUnit-style solution.

It's available in a Darcs repo, at http://www.demiurgo.org/darcs/testsuite/

More info in http://lists.debian.org/debian-dpkg/2006/10/msg0.html

First proposal
--
Uses DejaGNU[4], written in Tcl. I don't like the language, either ;-) I tried
with DejaGNU because it was supposed to have the "different kinds of tests
integration" thing already solved, but I'm not sure that's that hard to do
ourselves.

It's available in an Arch/Bazaar repo, at
http://people.debian.org/~zoso/arch/dpkg--test--1.0/
- >8 -

HTH,


[1] I.e., making calls to specific functions or modules; I'm using the check[2]
library for this
[2] http://check.sourceforge.net/
[3] http://www.gnu.org/software/dejagnu/
[4] I.e., executing programs with some parameters and see if they behave
correctly
-- 
Esteban Manchado Velázquez <[EMAIL PROTECTED]>
EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es
Help spread it through the Net in signatures, webpages, whatever!


signature.asc
Description: Digital signature

Re: How are things going?

[Guillem Jover]

Hi,

On Fri, 2006-09-29 at 22:35:33 -0700, Steve Langasek wrote:
> Carry on :-)

Ok, there has been one last commit to svn, and I'd like approval
before the planned upload for today. Attached the diff. And here's
both changelogs entries.

debian/changelog:
  * Require POSIX inside subprocerr in controllib.pl. Closes: #390636

ChangeLog:
2006-10-03  Brendan O'Dea  <[EMAIL PROTECTED]>

* scripts/controllib.pl (subprocerr): Require POSIX for WIFEXITED,
WEXITSTATUS, WIFSIGNALED and WTERMSIG.

regards,
guillem
Index: scripts/controllib.pl
===
--- scripts/controllib.pl   (revision 540)
+++ scripts/controllib.pl   (revision 541)
@@ -430,12 +430,13 @@
 
 sub subprocerr {
 local ($p) = @_;
-if (WIFEXITED($?)) {
+require POSIX;
+if (POSIX::WIFEXITED($?)) {
 die sprintf(_g("%s: failure: %s gave error exit status %s"),
-$progname, $p, WEXITSTATUS($?))."\n";
-} elsif (WIFSIGNALED($?)) {
+$progname, $p, POSIX::WEXITSTATUS($?))."\n";
+} elsif (POSIX::WIFSIGNALED($?)) {
 die sprintf(_g("%s: failure: %s died from signal %s"),
-$progname, $p, WTERMSIG($?))."\n";
+$progname, $p, POSIX::WTERMSIG($?))."\n";
 } else {
 die sprintf(_g("%s: failure: %s failed with unknown exit code %d"),
 $progname, $p, $?)."\n";

Re: Dpkg testing framework, take 5 (was: Re: How are things going?)

[Raphael Hertzog]

On Fri, 29 Sep 2006, Esteban Manchado Velázquez wrote:
> Hi people!
> 
[...]
> As I was the one who talked to Steve, I think I should say something :-)
> The thing that worried me the most was the silence after my proposals or
> questions on the testing framework. I assume that we mostly agree about the
> _having_ some test suite for the most important utility in Debian, so the
> problem seems to be either lack of time or agreement.

I bet for lack of time... all the dpkg developers that I know are
reasonable and wouldn't want to throw away the work of someone else if he
has taken care to ask for regular review of his work.

Ian Jackson said he's ready to give advice on dpkg developement in
general. Furthermore it did some groundwork on a testing framework for
Ubuntu (it was a package testing framework), so I'm sure that he could
review your work in that area.

Just go ahead!

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: How are things going?

[Russ Allbery]

Ian Jackson <[EMAIL PROTECTED]> writes:

> I think overall, Debian needs a proper conversation about revision
> control systems and source package formats.

I think Debian is going to continue using a wide variety of different
revision control systems as fit the feelings of individual developers and
having another conversation about that will probably generate more heat
than light.

The *dpkg* maintainers, on the other hand, can probably have a proper
conversation about revision control systems for maintaining *dpkg* and
generate a fair amount of light.  :)

I do think there's some appeal in the suggestion of making dpkg a package
with a separate "upstream" release that both Debian and Ubuntu merge with,
if for no other reason than that it provides clear synchronization points
and makes it extremely obvious in which ways Debian and Ubuntu may have
diverged from that synchronization point.  Although if that resulted in an
upstream version that never got a formal release, it would be worse than
what we have now.

> (With Ubuntu hat on) I'm afraid I can't guarantee that Ubuntu won't want
> to do something to dpkg that (with Debian hat on) I think is a bad idea
> :-).

I would certainly hope that isn't the case; I think it would be a failure
of imagination in finding a good general solution or a way of optionally
enabling a feature that would still allow Debian and Ubuntu to share the
same source.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: How are things going?

[Ian Jackson]

Matt Taggart writes ("Re: How are things going? "):
> Maybe it's time that dpkg become a separate upstream project?

I think Debian should continue to regard itself as dpkg upstream.

Ian.


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

Re: How are things going?

[Ian Jackson]

Russ Allbery writes ("Re: How are things going?"):
> Ian Jackson <[EMAIL PROTECTED]> writes:
> > Brendan O'Dea writes ("Re: How are things going?"):
> >> Merging changes to dpkg from Ubuntu to Debian seems daft.  Why have two
> >> repositories?
> >
> > Debian and Ubuntu sometimes have different views about things and I
> > don't think either would be happy necessarily using the same branch.
> 
> Could you give an example of what sort of thing you anticipate being
> different?  Beyond timing of releases, which could be dealt with via
> branches within the same repository, I can't think of anything.

You're vigorously agreeing with me.

But we do need merge tracking because of the desynchronised release
cycles, at the very least.  I don't think it really matters whether
it's one repository or several, so long as it's a system with merge
tracking.

I think overall, Debian needs a proper conversation about revision
control systems and source package formats.

> I would hope that the ongoing goal would be for Ubuntu and Debian to use
> the same dpkg as much as possible, with deviations only around release
> freezes.  I can't think of anything immediately obvious that would make
> that a bad idea.  But maybe my imagination is insufficient.

(With Ubuntu hat on) I'm afraid I can't guarantee that Ubuntu won't
want to do something to dpkg that (with Debian hat on) I think is
a bad idea :-).

Ian.


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

Re: How are things going?

[Ian Jackson]

Nicolas François writes ("Re: How are things going?"):
> The first patches were applied in the dpkg's repository.
> This means that the svn version should support packages using Breaks (I
> mean not reject them, but they will not use the content of these fields).

I need to check that the final version of the patch is the one that
got applied.

Also, to make proper use of Breaks changes are needed to apt and
aptitude as well.  It might be nice (but not essential) to improve
dselect too.

I have a complete working implementation of Breaks in apt; aptitude I
have hacked to make it treat it like Conflicts (which is not right but
better than ignoring it).

> If including the rest of the Breaks patches is also acceptable, I
> volunteer to push it in the svn (after listening Ian's opinion; was there
> any issue in Ubuntu?).

I think the Breaks support that we have in Ubuntu's dpkg and apt, and
the hack for aptitude, are suitable for inclusion in etch.  But
actually using it in packages in etch won't work very well because
sarge's tools don't know about it.

Ian.

Re: How are things going?

[Matt Taggart]

Ian Jackson writes...

> Brendan O'Dea writes ("Re: How are things going?"):
> > Merging changes to dpkg from Ubuntu to Debian seems daft.  Why have two
> > repositories?
> 
> Debian and Ubuntu sometimes have different views about things and I
> don't think either would be happy necessarily using the same branch.
> 
> But I agree that it would be useful for us to agree a revision control
> system with merge tracking.  If we had that then `merging the Breaks
> changes' would be trivial.

Maybe it's time that dpkg become a separate upstream project?

We certainly want to avoid the mess that rpm is in,
  http://lwn.net/Articles/196523/

-- 
Matt Taggart
[EMAIL PROTECTED]



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

Re: How are things going?

[Russ Allbery]

Ian Jackson <[EMAIL PROTECTED]> writes:
> Brendan O'Dea writes ("Re: How are things going?"):

>> Merging changes to dpkg from Ubuntu to Debian seems daft.  Why have two
>> repositories?

> Debian and Ubuntu sometimes have different views about things and I
> don't think either would be happy necessarily using the same branch.

Could you give an example of what sort of thing you anticipate being
different?  Beyond timing of releases, which could be dealt with via
branches within the same repository, I can't think of anything.

(Of course, this point is moot if using a revision control system where
branches are separate repositories anyway.)

I would hope that the ongoing goal would be for Ubuntu and Debian to use
the same dpkg as much as possible, with deviations only around release
freezes.  I can't think of anything immediately obvious that would make
that a bad idea.  But maybe my imagination is insufficient.

-- 
Russ Allbery ([EMAIL PROTECTED])   <http://www.eyrie.org/~eagle/>


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

Re: How are things going?

[Ian Jackson]

Brendan O'Dea writes ("Re: How are things going?"):
> Merging changes to dpkg from Ubuntu to Debian seems daft.  Why have two
> repositories?

Debian and Ubuntu sometimes have different views about things and I
don't think either would be happy necessarily using the same branch.

But I agree that it would be useful for us to agree a revision control
system with merge tracking.  If we had that then `merging the Breaks
changes' would be trivial.

Ian.


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

Re: How are things going?

[Ian Jackson]

Steve McIntyre writes ("Re: How are things going?"):
> Christian Perrier wrote:
> >There has also been, IIRC, some exchanges with Ian Jackson. Probably
> >more could be done here.
> 
> OK... Ian, do you have any comments/suggestions to make at this point?

Well, I've become more interested in dpkg recently.

Particularly, firstly I got one of the longstanding deficiencies (lack
of Breaks) addressed as part of my work on Ubuntu, although deployment
is still going to take a while.  I'm hoping to do the same with
hooks/triggers at some point, although this will need more discussion
as the design isn't entirely set down yet.

Looking what has at the code after all of this time has definitely
given me a revived interest in improving it :-/.  But although I'd
hoped to have some free time to do this in practice it doesn't seem to
be materialising, which means I won't be able to do much more than
give advice.

Thanks for asking.

Ian.


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

Re: How are things going?

[Steve Langasek]

On Fri, Sep 29, 2006 at 05:40:07AM +0300, Guillem Jover wrote:
> On Thu, 2006-09-28 at 16:51:33 -0700, Steve Langasek wrote:
> > On Thu, Sep 28, 2006 at 03:59:14PM -0400, Joey Hess wrote:
> > > Steve Langasek wrote:
> > > > Since "Breaks field" here means "doesn't complain about the Breaks 
> > > > field",
> > > > rather than "honors the Breaks field", these changes look ok.

> Argh, I should have corrected this one, sorry. From the changelog:

>   * Add initial support for the Breaks field, by parsing but rejecting it.

Aha, then you're doing the right thing and I'm just confused.  Carry on :-)
> There's two ways to introduce it that I can think of now, but I'd opt
> for the first one, otherwise we'll need to wait a lot for this.

> Fast:
> 
>   * etch
> - dpkg parse but reject.
>   * etch+1:
> - dpkg full support.
> - require to upgrade dpkg first from etch to etch+1.
> - packages using the field in the archive (not the ones that dpkg
>   (pre-)depends on though).

Yep, sounds doable to me.

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


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

Dpkg testing framework, take 5 (was: Re: How are things going?)

[Esteban Manchado Velázquez]

Hi people!

On Thu, Sep 28, 2006 at 01:40:55AM +0100, Steve McIntyre wrote:
> >thanks for the interest,
> 
> *grin* I was just a little worried things had gone quiet; I've been
> watching the list for a while. But you all seem happy enough with
> where things are at the moment, and that's cool.
> 
> I'd volunteer to help myself, but right now it would just be another
> project for me to feel guilty about not working on due to lack of
> time... :-(

As I was the one who talked to Steve, I think I should say something :-)
The thing that worried me the most was the silence after my proposals or
questions on the testing framework. I assume that we mostly agree about the
_having_ some test suite for the most important utility in Debian, so the
problem seems to be either lack of time or agreement.

I would _really_ like to put my money where my mouth is, that is, I'm NOT
just evangelizing about testing and expecting that _another_ developer steps
in. I really want to help in the design and implementation of the whole thing,
and I would even like to lead the development if no one wants to... but,
before starting, I would like to have some sort of acknowledgement that there
is interest in it. Don't get me wrong, I _want_ it to be useful and I'm not
afraid of throwing some code away and rewriting if that's the best thing to
do. I just don't want to first write "lots" of code and then realize that
people don't like the approach or something like that (more or less what
happened with my first try).

So, to summarize the current situation, AFAICT:

1) In the "Working on dpkg during Debconf" thread[1], Frank said[2] we
need four different kinds of tests (C unit, C functional, Perl unit, Perl
functional).
2) Frank has experience in Perl unit/functional tests. I have experience
in 2, 3 and 4 (well, 2 is basically the same as 4). So, the only weak point
right now seems to be 1. And in fact I have done some limited C unit testing
for my first testing framework proposal, using check[3].
3) After a neat tip from Jörg, I showed[4] a simple way to "solve" 1 for
dpkg.
4) There hasn't been any discussion, AFAIK, about the design of the
framework. I haven't even heard too many comments on my initial proposal, so
I'm not sure what's wrong with it (if there is anything at all!) to improve
the second try :-) The only comment I remember was from Scott, who said[5]:

- 8< -
My main concerns so far with test suites is that the suite be:

1) easy for users and casual developers to run, and be able to quickly
   identify failed tests and use them to fix the code.

2) sufficiently easy to use to encourage developers to write tests with
   every code modification they make, and even with every bug fix.

3) not require exotic or unusual support platforms or languages.
[...]
DejaGNU in particular doesn't seem to manage to satisfy any of these
three concerns [...]
That being said, I did have some interesting discussions with tridge at
LCA about how they test the samba suite.
- >8 -

As I tried to explain, I don't think 1 and 2 are that problematic, because I
didn't want to use DejaGNU as the testing framework, but build a testing
framework _on top of it_. I tried to ask him if he had any specific idea on
how it should look like, and languages/platforms he considered OK, but he
never replied :-(
5) Frank has begun some work on a testing framework for dpkg-dev[6] (only
the Perl tools, I think), available as an Arch repository. I don't know what's
the current state for his project.
6) I also proposed[7] using different tools/frameworks for each kind of
tests, and integrate them with the TAP format (the Perl test output format).
Now I'm not sure it is such a good idea, but... :-)

Perhaps we could start with a list of requirements or something like that. Any
ideas?

Best regards,

[1] http://lists.debian.org/debian-dpkg/2006/05/msg0.html
[2] http://lists.debian.org/debian-dpkg/2006/05/msg00031.html
[3] http://check.sf.net/
[4] http://lists.debian.org/debian-dpkg/2006/05/msg00052.html
[5] http://lists.debian.org/debian-dpkg/2005/06/msg00043.html
[6] http://lists.debian.org/debian-dpkg/2005/08/msg00010.html
[7] http://lists.debian.org/debian-dpkg/2006/07/msg6.html
-- 
Esteban Manchado Velázquez <[EMAIL PROTECTED]>
EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es
Help spread it through the Net in signatures, webpages, whatever!


signature.asc
Description: Digital signature

Re: How are things going?

[Esteban Manchado Velázquez]

On Thu, Sep 28, 2006 at 03:45:44AM +1000, Brendan O'Dea wrote:
> On Tue, Sep 26, 2006 at 03:53:06AM -0400, Joey Hess wrote:
> >I'm rather worried that there's been no apparent progress on getting
> >Ian's Breaks support merged in, [...]
> 
> Merging changes to dpkg from Ubuntu to Debian seems daft.  Why have two
> repositories?
> 
> Pick one, either Debian's or Ubuntu's, I don't care which, merge any
> outstanding changes and give write access to everyone who is actively
> developing.

Amen. If we don't do that, we could end with different, slightly
incompatible package formats :-( I mean, if we are using the same package
format, I think we should really be using the same program, and not two
different "forks".

-- 
Esteban Manchado Velázquez <[EMAIL PROTECTED]>
EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es
Help spread it through the Net in signatures, webpages, whatever!


signature.asc
Description: Digital signature

Re: How are things going?

[Guillem Jover]

On Thu, 2006-09-28 at 16:51:33 -0700, Steve Langasek wrote:
> On Thu, Sep 28, 2006 at 03:59:14PM -0400, Joey Hess wrote:
> > Steve Langasek wrote:
> > > Since "Breaks field" here means "doesn't complain about the Breaks field",
> > > rather than "honors the Breaks field", these changes look ok.

Argh, I should have corrected this one, sorry. From the changelog:

  * Add initial support for the Breaks field, by parsing but rejecting it.

> > > As far as *implementing* Breaks, I don't think a new feature of that
> > > level should be introduced during a freeze.

I'd feel really unconfortable introducing full support at this time.

> > Couldn't it be potentially dangerous to have a dpkg in a released
> > version of Debian that silently ignores Breaks? It seems it would both
> > allow for much foot-shooting by anyone who tries to install packages
> > from another source that use Breaks, as well as prevent us from using
> > Breaks in any packages in etch+1, since upgrades won't work.

This should not be the case.

> Hmm, good point.  The logical consequence of supporting Breaks is that we
> will start to see packages that use Breaks instead of Conflicts, so
> silently ignoring the contents of the Breaks field will result in packages
> being co-installed that should not have been.

> So indeed, I think we want Breaks support to be all or nothing.

No, I'd say we want partial then full support. And we definitely want
that the dpkg in the next release understands the field and rejects
it, so that we don't get an upgrade path where suddenly the system has
got unsatisfiable dependencies due to dpkg not understanding the field
previously.

There's two ways to introduce it that I can think of now, but I'd opt
for the first one, otherwise we'll need to wait a lot for this.

Fast:

  * etch
- dpkg parse but reject.
  * etch+1:
- dpkg full support.
- require to upgrade dpkg first from etch to etch+1.
- packages using the field in the archive (not the ones that dpkg
  (pre-)depends on though).

Slow:

  * etch
- dpkg parse but reject.
  * etch+1
- dak disallows packages in the archive with such field.
- dpkg full support.
  * etch+2
- dak allows packages in the archive with such field.

regards,
guillem


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

Re: How are things going?

[Steve Langasek]

On Thu, Sep 28, 2006 at 03:59:14PM -0400, Joey Hess wrote:
> Steve Langasek wrote:
> > Since "Breaks field" here means "doesn't complain about the Breaks field",
> > rather than "honors the Breaks field", these changes look ok.

> > As far as *implementing* Breaks, I don't think a new feature of that level
> > should be introduced during a freeze.

> Couldn't it be potentially dangerous to have a dpkg in a released
> version of Debian that silently ignores Breaks? It seems it would both
> allow for much foot-shooting by anyone who tries to install packages
> from another source that use Breaks, as well as prevent us from using
> Breaks in any packages in etch+1, since upgrades won't work.

Hmm, good point.  The logical consequence of supporting Breaks is that we
will start to see packages that use Breaks instead of Conflicts, so
silently ignoring the contents of the Breaks field will result in packages
being co-installed that should not have been.

So indeed, I think we want Breaks support to be all or nothing.

Dpkg maintainers, do you agree?

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


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

Re: How are things going?

[Joey Hess]

Steve Langasek wrote:
> Since "Breaks field" here means "doesn't complain about the Breaks field",
> rather than "honors the Breaks field", these changes look ok.
> 
> As far as *implementing* Breaks, I don't think a new feature of that level
> should be introduced during a freeze.

Couldn't it be potentially dangerous to have a dpkg in a released
version of Debian that silently ignores Breaks? It seems it would both
allow for much foot-shooting by anyone who tries to install packages
from another source that use Breaks, as well as prevent us from using
Breaks in any packages in etch+1, since upgrades won't work.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: How are things going?

[Nicolas François]

On Wed, Sep 27, 2006 at 04:23:00AM -0700, Steve Langasek wrote:
> 
> BTW, with the changes to scripts/dpkg-architecture.pl, does something fix
> the dpkglibdir and pkgdatadir paths when installing this script?

Yes, the Makefile fixes all the dpkglibdir and pkgdatadir variables during
the build.
Some of these variables have "# This line modified by Makefile" specified
at the end of the line...not all of them;(

Best Regards,
-- 
Nekral


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

Re: How are things going?

[Guillem Jover]

On Wed, 2006-09-27 at 04:23:00 -0700, Steve Langasek wrote:
> So I've unblocked it after reviewing the changelog.

Thanks.

> On Wed, Sep 27, 2006 at 01:09:26PM +0300, Guillem Jover wrote:
> > I've created a diff[2] with the new commited stuff and removed all
> > autogenerated things (I've not removed the comment changes for
> > completeness). Debian chanelog and upstream ChangeLog are in the
> > header of the patch.
> 
> > Basically the changes are:
> 
> >   * The tar 'nul' warning fix.
> >   * The Breaks field.
> >   * Using dpkg-architecture from the source instead of duping its
> > logic in the m4 files (this is kind of a requisite for the armel
> > architecture introduction).
> >   * Comments or new line fixes.
> 
> Since "Breaks field" here means "doesn't complain about the Breaks field",

Yes, sorry for not being more clear there, as the changelog contained
 the detailed info anyway.

> rather than "honors the Breaks field", these changes look ok.

> As far as *implementing* Breaks, I don't think a new feature of that level
> should be introduced during a freeze.

I've not even thought about pushing for such a thing. =)

> BTW, with the changes to scripts/dpkg-architecture.pl, does something fix
> the dpkglibdir and pkgdatadir paths when installing this script?

Yes, the Makefile when converting from foo.pl to foo replaces the
correct values for some of those variables with the final paths, or
version.

regards,
guillem


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

Re: How are things going?

[Steve McIntyre]

Guillem Jover wrote:
>On Mon, 2006-09-25 at 23:33:48 +0100, Steve McIntyre wrote:
>
>> While I was in Tenerife last week, I met up with Esteban
>> Manchado Velazquez and he told me about his ideas for a testing
>> framework for dpkg. To me as a rank outsider, this sounds like a cool
>> idea, but he was concerned that he hadn't had any responses to his
>> mails.
>
>Yes it is, but right now it's a bit painful to do development on dpkg.
>I don't really like to use experimental for something like it, even if
>I've state in -devel that I've been thinking on branching it. I prefer
>to do incremental changes, deploy them, get testing for few weeks, see
>if something breaks, and upload again. Creating a big delta in
>experimental make me feel unconfortable with something like dpkg.

Yeah, I can understand that... :-)

>Also l10n, documentation and similar are cheap to get in, that's why
>I've not worried much about pushing that into sid. But any other kind
>of changes needs RMs approval and thus takes their time by reviewing
>the patches and the justifications, which I prefer to minimize if
>possible.

Yup, OK.

>> So, I have a couple of questions: Who (if anybody) is working on dpkg
>> at the moment? Is more help needed at the moment?
>
>Christian explained already what's the status right now, who is who
>etc. About needed help, I suppose more help would not harm, but I
>don't think right now is a good moment to evaluate this, I'd say after
>the release we can check what the status is.

Ok, that's fair enough.

>thanks for the interest,

*grin* I was just a little worried things had gone quiet; I've been
watching the list for a while. But you all seem happy enough with
where things are at the moment, and that's cool.

I'd volunteer to help myself, but right now it would just be another
project for me to feel guilty about not working on due to lack of
time... :-(

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
Is there anybody out there?


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

Re: How are things going?

[Steve McIntyre]

Christian Perrier wrote:
>
>When Scott decided to lower his involvment in March or April, he
>handed the maintenance to a couple of DD's who, at some moment,
>involved themselves in dpkg maintenance:
>
>-Frank Lichtenheld
>-Guillem Jover
>-Brendan O'Dea
>-myself
>
>Speaking for myself, I was mostly handling the i18n/l10n part which
>essentially consists in dealing with translation updates. Not a very
>big part, indeed, and definitely no code maintenance.
>
>The team auto-organized itself, without much coordination (not a
>criticism, mostly a fact). The most visible part of work has been done
>by Guillem with a few achievments (which he probably can described
>better than myself).



>There has also been, IIRC, some exchanges with Ian Jackson. Probably
>more could be done here.

OK... Ian, do you have any comments/suggestions to make at this point?

>In short, the manpower is more or less here but probably not enough
>organized. We probably need someone to stand up, act as a team leader
>and drive dpkg development. This is not vital now...but could become
>vital after the release of etch.
>
>1 or 2 more contributors would certainly be welcomedafter we have
>solved this leadership issue.
>
>There is probably a lot more to say, indeed but I wanted to give you my
>own views after something like 2 years lurking on dpkg development.

Great, thanks!

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
Is there anybody out there?


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

Re: How are things going?

[Brendan O'Dea]

On Tue, Sep 26, 2006 at 03:53:06AM -0400, Joey Hess wrote:
>I'm rather worried that there's been no apparent progress on getting
>Ian's Breaks support merged in, [...]

Merging changes to dpkg from Ubuntu to Debian seems daft.  Why have two
repositories?

Pick one, either Debian's or Ubuntu's, I don't care which, merge any
outstanding changes and give write access to everyone who is actively
developing.

--bod


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

Re: How are things going?

[Brendan O'Dea]

On Tue, Sep 26, 2006 at 07:51:26AM +0200, Christian Perrier wrote:
>When Scott decided to lower his involvment in March or April, he
>handed the maintenance to a couple of DD's who, at some moment,
>involved themselves in dpkg maintenance:
>
>-Frank Lichtenheld
>-Guillem Jover
>-Brendan O'Dea
>-myself

I was hoping when Scott asked me to have some time to work on dpkg
(specifically -dev), but my current employment is leaving me little time
to do so.

With luck I will have more time soon, but for now my involvement is
limited to hosting the MX for dpkg.org .

--bod


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

Re: How are things going?

[Steve Langasek]

On Tue, Sep 26, 2006 at 09:13:23PM +0200, Nicolas François wrote:

> > I'm rather worried that there's been no apparent progress on getting
> > Ian's Breaks support merged in, especially since in my limited
> > understanding it's already present in Ubuntu and presumably being used
> > there. That doesn't seem very good for cross-distro package
> > compatability if our dpkg ignores the field.

> The first patches were applied in the dpkg's repository.
> This means that the svn version should support packages using Breaks (I
> mean not reject them, but they will not use the content of these fields).

> IIRC, the same remains to be done for dselect.

> Before going farther, the next step must be pushing 1.13.22 to testing.
> It was locked in unstable because of the perl RC bug, which caused dpkg to
> FTBFS.

> This version of dpkg is now in unstable since more than 3 months and
> should have receive enough tests. I'm CCing debian-release to see if this
> version can be pushed to testing.

Yes, since this version has been in unstable for three months already
without major incident, it doesn't make sense to keep it out of the release,
especially since it's the version that will be used for building so many of
our binary packages included in etch.

So I've unblocked it after reviewing the changelog.

On Wed, Sep 27, 2006 at 01:09:26PM +0300, Guillem Jover wrote:

> > Regarding the next dpkg version, the patch is quite large, but it's mostly
> > l10n stuff. Would the current 1.13.23 be acceptable to bypass the dpkg
> > freeze? [1]

> I've created a diff[2] with the new commited stuff and removed all
> autogenerated things (I've not removed the comment changes for
> completeness). Debian chanelog and upstream ChangeLog are in the
> header of the patch.

> Basically the changes are:

>   * The tar 'nul' warning fix.
>   * The Breaks field.
>   * Using dpkg-architecture from the source instead of duping its
> logic in the m4 files (this is kind of a requisite for the armel
> architecture introduction).
>   * Comments or new line fixes.

Since "Breaks field" here means "doesn't complain about the Breaks field",
rather than "honors the Breaks field", these changes look ok.

As far as *implementing* Breaks, I don't think a new feature of that level
should be introduced during a freeze.

BTW, with the changes to scripts/dpkg-architecture.pl, does something fix
the dpkglibdir and pkgdatadir paths when installing this script?

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


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

Re: How are things going?

[Guillem Jover]

On Tue, 2006-09-26 at 21:13:23 +0200, Nicolas François wrote:
> On Tue, Sep 26, 2006 at 03:53:06AM -0400, Joey Hess wrote:
> > I'm rather worried that there's been no apparent progress on getting
> > Ian's Breaks support merged in, especially since in my limited
> > understanding it's already present in Ubuntu and presumably being used
> > there. That doesn't seem very good for cross-distro package
> > compatability if our dpkg ignores the field.

> The first patches were applied in the dpkg's repository.
> This means that the svn version should support packages using Breaks (I
> mean not reject them, but they will not use the content of these fields).

> IIRC, the same remains to be done for dselect.

I've applied it now, I was just waiting until contacting the release team,
to revert the other part or commit the missing one, depending on the
outcome of their decision.

> Before going farther, the next step must be pushing 1.13.22 to testing.
> It was locked in unstable because of the perl RC bug, which caused dpkg to
> FTBFS.
>
> This version of dpkg is now in unstable since more than 3 months and
> should have receive enough tests. I'm CCing debian-release to see if this
> version can be pushed to testing.

Yes, please.

> Regarding the next dpkg version, the patch is quite large, but it's mostly
> l10n stuff. Would the current 1.13.23 be acceptable to bypass the dpkg
> freeze? [1]

I've created a diff[2] with the new commited stuff and removed all
autogenerated things (I've not removed the comment changes for
completeness). Debian chanelog and upstream ChangeLog are in the
header of the patch.

Basically the changes are:

  * The tar 'nul' warning fix.
  * The Breaks field.
  * Using dpkg-architecture from the source instead of duping its
logic in the m4 files (this is kind of a requisite for the armel
architecture introduction).
  * Comments or new line fixes.

There's few changes I may want to make to dpkg, which I'd like to
request permission first to avoid commiting changes that will not be
approved, but I'll send a separete mail about those later.

[2] 

regards,
guillem


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

Re: How are things going?

[Guillem Jover]

Hi,

On Mon, 2006-09-25 at 23:33:48 +0100, Steve McIntyre wrote:
> How is dpkg development going atm? I know it's not necessarily a good
> indicator of activity, but I've not seen much happening on this
> list.

Kind of frozen right now, I had a list of stuff I wanted to get done
for etch, but due to holidays and then the freeze I've not done, they
are not critical though, and I've let that aside to deal with other
non-frozen packages to prepare them for the release.

> While I was in Tenerife last week, I met up with Esteban
> Manchado Velazquez and he told me about his ideas for a testing
> framework for dpkg. To me as a rank outsider, this sounds like a cool
> idea, but he was concerned that he hadn't had any responses to his
> mails.

Yes it is, but right now it's a bit painful to do development on dpkg.
I don't really like to use experimental for something like it, even if
I've state in -devel that I've been thinking on branching it. I prefer
to do incremental changes, deploy them, get testing for few weeks, see
if something breaks, and upload again. Creating a big delta in
experimental make me feel unconfortable with something like dpkg.

Also l10n, documentation and similar are cheap to get in, that's why
I've not worried much about pushing that into sid. But any other kind
of changes needs RMs approval and thus takes their time by reviewing
the patches and the justifications, which I prefer to minimize if
possible.

> So, I have a couple of questions: Who (if anybody) is working on dpkg
> at the moment? Is more help needed at the moment?

Christian explained already what's the status right now, who is who
etc. About needed help, I suppose more help would not harm, but I
don't think right now is a good moment to evaluate this, I'd say after
the release we can check what the status is.

thanks for the interest,
guillem


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

Re: How are things going?

[Nicolas François]

Hi,

On Tue, Sep 26, 2006 at 03:53:06AM -0400, Joey Hess wrote:
> Christian Perrier wrote:
> > There has also been, IIRC, some exchanges with Ian Jackson. Probably
> > more could be done here.
> 
> I'm rather worried that there's been no apparent progress on getting
> Ian's Breaks support merged in, especially since in my limited
> understanding it's already present in Ubuntu and presumably being used
> there. That doesn't seem very good for cross-distro package
> compatability if our dpkg ignores the field.

The first patches were applied in the dpkg's repository.
This means that the svn version should support packages using Breaks (I
mean not reject them, but they will not use the content of these fields).

IIRC, the same remains to be done for dselect.

Before going farther, the next step must be pushing 1.13.22 to testing.
It was locked in unstable because of the perl RC bug, which caused dpkg to
FTBFS.

This version of dpkg is now in unstable since more than 3 months and
should have receive enough tests. I'm CCing debian-release to see if this
version can be pushed to testing.


Regarding the next dpkg version, the patch is quite large, but it's mostly
l10n stuff. Would the current 1.13.23 be acceptable to bypass the dpkg
freeze? [1]

If including the rest of the Breaks patches is also acceptable, I
volunteer to push it in the svn (after listening Ian's opinion; was there
any issue in Ubuntu?).


[1]
I'm putting some info about the diff between 1.13.21 (testing),
1.13.22 (unstable) and 1.13.23 (svn) at:
http://haydn.debian.org/~nekral-guest/dpkg/

 * 22_to_23.code.diff contains the diff between 1.13.22 and the current
   1.13.23 with only the code section (no l10n stuff).
 * 22_to_23.stats has some comments that associate the debian/changelog
   entries with the code changes.

Kind Regards,
-- 
Nekral


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

Re: How are things going?

[Joey Hess]

Christian Perrier wrote:
> There has also been, IIRC, some exchanges with Ian Jackson. Probably
> more could be done here.

I'm rather worried that there's been no apparent progress on getting
Ian's Breaks support merged in, especially since in my limited
understanding it's already present in Ubuntu and presumably being used
there. That doesn't seem very good for cross-distro package
compatability if our dpkg ignores the field.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: How are things going?

[Christian Perrier]

> So, I have a couple of questions: Who (if anybody) is working on dpkg
> at the moment? Is more help needed at the moment?


When Scott decided to lower his involvment in March or April, he
handed the maintenance to a couple of DD's who, at some moment,
involved themselves in dpkg maintenance:

-Frank Lichtenheld
-Guillem Jover
-Brendan O'Dea
-myself

Speaking for myself, I was mostly handling the i18n/l10n part which
essentially consists in dealing with translation updates. Not a very
big part, indeed, and definitely no code maintenance.

The team auto-organized itself, without much coordination (not a
criticism, mostly a fact). The most visible part of work has been done
by Guillem with a few achievments (which he probably can described
better than myself).

The repository has been moved back to a SVN repository on Alioth,
mostly because most of us felt more comfortable with centralized
development, at least for the time things could get organized.

In short, dpkg is in correct shape for etch.

I think that Frank has some long-term views but essentially delays
them for post-etch.

Nicolas François informally joined us and will certainly be of great
help in long-term code maintenance. He's also taking over the
maintenance of l10n which leaves myself without special involvment
(which is not a problem...:-))

Bruce Sass recently popped up and began some bug cleaning mostly on
dselect issues

There has also been, IIRC, some exchanges with Ian Jackson. Probably
more could be done here.

In short, the manpower is more or less here but probably not enough
organized. We probably need someone to stand up, act as a team leader
and drive dpkg development. This is not vital now...but could become
vital after the release of etch.

1 or 2 more contributors would certainly be welcomedafter we have
solved this leadership issue.

There is probably a lot more to say, indeed but I wanted to give you my
own views after something like 2 years lurking on dpkg development.

Thanks anyway for bringing that topic, Steve





signature.asc
Description: Digital signature