Multi-arch branches
 

Hi,

just to let you know that I have updated my "test-build" branch (and hence
the "dpkg-test" APT repository[1]). Guillem has merged all the remaining fixes
I had in pu/multiarch/full so his pu/multiarch/master is currently passing
the multi-arch test-suite and both branches have the same content.

I just had to update the test suite to cope with the rename of
${virt:Package-Spec} to ${binary:Package}.

I'm looking forward to the completion of the multiarch merge!

Cheers,

[1] deb http://jenkins.grml.org/debian dpkg-test main
--
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120123080412.GA28720@rivendell.home.ouaza.com">h ttp://lists.debian.org/20120123080412.GA28720@rivendell.home.ouaza.com

Multi-arch branches
 

Hi,

Raphael Hertzog <hertzog@debian.org> (23/01/2012):
> just to let you know that I have updated my "test-build" branch (and
> hence the "dpkg-test" APT repository[1]). Guillem has merged all the
> remaining fixes I had in pu/multiarch/full so his pu/multiarch/master
> is currently passing the multi-arch test-suite and both branches have
> the same content.
>
> I just had to update the test suite to cope with the rename of
> ${virt:Package-Spec} to ${binary:Package}.
>
> I'm looking forward to the completion of the multiarch merge!

me too! I've been running this code on several machines for a while, and
it works just fine.

Since apparently the only remaining blocker for an upload to the archive
seems to be time, I prepared a “Team upload� targeted at experimental,
using the 1.16.2~multiarch version.

For that, I needed to fix a make distcheck failure, so you can find both
the patch to fix it, and the patch to finalize this release at:
http://people.debian.org/~kibi/dpkg

source+amd64+all packages are available at the same URL, along with
SHA1 checksums, signed with my GPG key.

I picked 1.16.2_multiarch as tag name, which seems to match current
practice.

I plan to upload it no later than Friday, and even earlier if I get some
enthusiastic ACKS. :)

Mraw,
KiBi.

Multi-arch branches
 

Hi,

On Mon, 30 Jan 2012, Cyril Brulebois wrote:
> Since apparently the only remaining blocker for an upload to the archive
> seems to be time, I prepared a “Team upload� targeted at experimental,
> using the 1.16.2~multiarch version.

I'm pretty sure you know it, but on my side the "blocker" is not time but
agreement from Guillem.

> For that, I needed to fix a make distcheck failure, so you can find both
> the patch to fix it, and the patch to finalize this release at:
> http://people.debian.org/~kibi/dpkg

Thanks, I have queued the fix for the make distcheck failure. I will push
it once alioth comes back.

> I plan to upload it no later than Friday, and even earlier if I get some
> enthusiastic ACKS. :)

I won't ack this but I don't want to nack it either. If Guillem were not
there, I would be pretty happy to merge the current code and to upload it.

And Guillem has had more than enough time to finish his review and cleanup
of the code, he first promised[1] the release of 1.16.2 with multiarch as
usual after the usual 2 month of developement time. We know that this did
not happen but I waited longer because Guillem showed good sign of
progress in november and early december. He then told me that it should be
possible to finish this for Christmas. Again the delay was not respected.
December and January have been very quiet despite one (private) mail of
Guillem who assured me that he was back from vacation and that he would
continue to work on the merge. He did it to some extent but the amount of
progress is way too small to give me any confidence in Guillem's ability
to finish this in a reasonable delay.

There's still 31 commits in the external multiarch branch, pretty much the
same than at the end of november when I announced that the half of the
branch had been merged[2] (there were 66 commits initially). Of course,
some of the work that Guillem did involved creating new commits so those
statistics are not 100% accurate to represent the progress. But still,
they are depressing. :-(

Cheers,

[1] http://lists.debian.org/debian-dpkg/2011/10/msg00053.html
[2] http://lists.debian.org/debian-dpkg/2011/11/msg00076.html
--
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120130140929.GB20049@rivendell.home.ouaza.com">h ttp://lists.debian.org/20120130140929.GB20049@rivendell.home.ouaza.com

Multi-arch branches
 

On Mon, 2012-01-30 at 12:36:22 +0100, Cyril Brulebois wrote:
> me too! I've been running this code on several machines for a while, and
> it works just fine.

That it seems to work does not mean it's fine, I just fixed some days
ago bogus arguments passed to maintainer scripts, for example.

> Since apparently the only remaining blocker for an upload to the archive
> seems to be time, I prepared a “Team upload� targeted at experimental,
> using the 1.16.2~multiarch version.

Err, “Team upload�... and uploading (which is a trivial step) is not
the issue here.

> For that, I needed to fix a make distcheck failure, so you can find both
> the patch to fix it, and the patch to finalize this release at:
> http://people.debian.org/~kibi/dpkg

Thanks, I had pushed your build patch to hadrons' master branch. I
see Raphaël has queued it too, although the changelog entry is not
appropriate in this case.

> I picked 1.16.2_multiarch as tag name, which seems to match current
> practice.

The code assumes 1.16.2 is the one with multiarch support, earlier
versions will not trigger some stuff.

> I plan to upload it no later than Friday, and even earlier if I get some
> enthusiastic ACKS. :)

Well, NACK then.

guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120130192013.GA2695@gaara.hadrons.org">http://lists.debian.org/20120130192013.GA2695@gaara.hadrons.org

Multi-arch branches
 

Guillem Jover <guillem@debian.org> (30/01/2012):
> That it seems to work does not mean it's fine, I just fixed some days
> ago bogus arguments passed to maintainer scripts, for example.

Possible bugs can easily be found, and then fixed, by exposing packages to…
users. Experimental also means only people pulling it will be exposed to
it anyway.

> Err, “Team upload�...

I can make that NMU, point taken.

> and uploading (which is a trivial step) is not the issue here.

What's the issue then?

> Thanks, I had pushed your build patch to hadrons' master branch. I see
> Raphaël has queued it too, although the changelog entry is not
> appropriate in this case.

Whatever works for you.

> The code assumes 1.16.2 is the one with multiarch support, earlier
> versions will not trigger some stuff.

ACK.

> > I plan to upload it no later than Friday, and even earlier if I get
> > some enthusiastic ACKS. :)
>
> Well, NACK then.

What is the current plan? We're *months* already past any schedule that
might have been proposed by yourself, or proxied by Raphaël, since you
most of the time try and avoid answering publicly to legitimate
questions. Indeed, your fellow developers have been working hard for a
very long time on: multiarch specification, initial patch crafting, and
patch merging in various packages. Why are all those efforts stalled?
Just because there might be some bugs left in dpkg's multiarch support?
Time to find them and fix them!

We need dpkg's multiarch support. Not today. Months ago. Please make it
possible for your fellow developers to catch up and make it a reality,
now.

Mraw,
KiBi.

Multi-arch branches
 

On Mon, 30 Jan 2012, Cyril Brulebois wrote:
> Guillem Jover <guillem@debian.org> (30/01/2012):
> > That it seems to work does not mean it's fine, I just fixed some days
> > ago bogus arguments passed to maintainer scripts, for example.

I would love to be informed when you find mistakes in what I did. I would
love to be able to fix anything that's not good in what I did instead of
having to wait for you to do it.

> Possible bugs can easily be found, and then fixed, by exposing packages to…
> users. Experimental also means only people pulling it will be exposed to
> it anyway.

+1

I fixed more bugs in the branch because it has been in use in Ubuntu than bugs
that have been found by Guillem's review. That said both are valuable but there's
no reason to stall everything because you have not finished your review.

> > Thanks, I had pushed your build patch to hadrons' master branch. I see
> > Raphaël has queued it too, although the changelog entry is not
> > appropriate in this case.

Ok, I'll drop it from my queue.

> > The code assumes 1.16.2 is the one with multiarch support, earlier
> > versions will not trigger some stuff.
>
> ACK.

Actually, that's your mistake Guillem. The various maintainer scripts
properly use 1.16.2~ for the comparison (and there 1.16.2~multiarch > 1.16.2~).
But you introduced an inconsistency by using 1.16.2 without the tilde for
--assert-multi-arch. Anyone who has the code for --assert-multiarch has the
full multiarch branch so it's perfectly sane to lower this minimal version.

Anyway this small inconsistency makes no practical difference if
dpkg is configured since the version check is only triggered when dpkg
is in status unpacked, half-configured, half-installed or triggers-awaited
(cf assert_version_support() in src/enquiry.c).

I used 1.16.2~ on purpose because we have users testing the multiarch branch
out of the dpkg-test APT repository which has this kind of versioning.

$ grep 1.16.2 debian/dpkg.* src/enquiry.c
debian/dpkg.postrm: if dpkg --compare-versions "$2" lt 1.16.2~; then
debian/dpkg.prerm: if dpkg --compare-versions "$2" lt 1.16.2~; then
src/enquiry.c: struct versionrevision version = { 0, "1.16.2", NULL };

I have fixed this inconsistency in my pu/multiarch/full and have updated the
test-build branch too.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120130204110.GJ6882@rivendell.home.ouaza.com">ht tp://lists.debian.org/20120130204110.GJ6882@rivendell.home.ouaza.com

Multi-arch branches
 

Cyril Brulebois <kibi@debian.org> (30/01/2012):
> I can make that NMU, point taken.

I've updated the changelog accordingly.

> Guillem Jover <guillem@debian.org> (30/01/2012):
> > Thanks, I had pushed your build patch to hadrons' master branch. I
> > see Raphaël has queued it too, although the changelog entry is not
> > appropriate in this case.
>
> Whatever works for you.

I've cherry-picked it on top of Raphaël's updated branch.

> Guillem Jover <guillem@debian.org> (30/01/2012):
> > The code assumes 1.16.2 is the one with multiarch support, earlier
> > versions will not trigger some stuff.
>
> ACK.

Based on Raphaël's comments and the lack of further reply on your side,
I've used Raphaël's fixup commit, keeping the originally-proposed
version.

Based on the lack of objections and the lack of alternative plans, I'll
proceed with the NMU this evening, using the experimental branch on my
alioth repository:
http://anonscm.debian.org/gitweb/?p=users/kibi/dpkg.git

Mraw,
KiBi.

Multi-arch branches
 

Hi,

Cyril Brulebois wrote:

> Based on Raphaël's comments and the lack of further reply on your side,
> I've used Raphaël's fixup commit, keeping the originally-proposed
> version.
>
> Based on the lack of objections and the lack of alternative plans, I'll
> proceed with the NMU this evening, using the experimental branch on my
> alioth repository:
> http://anonscm.debian.org/gitweb/?p=users/kibi/dpkg.git

While I'm all for more testing in experimental, I thought Guillem
objected?

What I would find most useful to hear (from anyone) is if there are any
unresolved interface questions remaining. E.g., has the behavior of
"dpkg --get-selections" and --set-selections been worked out? If there
are the sort of problems that mean it would be unsafe to code on the
assumption that dpkg's behavior will stay roughly the same, then I
suggest at least a temporary NEWS.Debian entry saying so.

Hope that helps,
Jonathan


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120131154905.GB10306@burratino">http://lists.debian.org/20120131154905.GB10306@burratino

Multi-arch branches
 

On Mon, 2012-01-30 at 21:41:10 +0100, Raphael Hertzog wrote:
> On Mon, 30 Jan 2012, Cyril Brulebois wrote:
> > Possible bugs can easily be found, and then fixed, by exposing packages to…
> > users. Experimental also means only people pulling it will be exposed to
> > it anyway.
>
> +1

I don't have any problem with the random bug that escapes review,
regardless of it's severity. They can usually be fixed quickly.

I have a problem with merging unreviewed code, though, that among other
things might and do have design issues, as witnessed in the past. I also
have not seen Cyril jump to do any kind of code review during all this
time as quickly as he jumped to pester and with threats to NMU a new
*upstream release*, w/o having been involved with it at *all*, with
known issues, regardless of maintainer disapproval...

One of the many reasons this past year has been pretty distressful, to
be honest. :(

> I fixed more bugs in the branch because it has been in use in Ubuntu than
> bugs that have been found by Guillem's review.

I disagree, besides code cleanup and bug fixes there's also been design
issues spotted and fixed. Something user usage usually does not reveal.

> > > The code assumes 1.16.2 is the one with multiarch support, earlier
> > > versions will not trigger some stuff.
> >
> > ACK.
>
> Actually, that's your mistake Guillem. The various maintainer scripts
> properly use 1.16.2~ for the comparison (and there 1.16.2~multiarch > 1.16.2~).
> But you introduced an inconsistency by using 1.16.2 without the tilde for
> --assert-multi-arch. Anyone who has the code for --assert-multiarch has the
> full multiarch branch so it's perfectly sane to lower this minimal version.

> I used 1.16.2~ on purpose because we have users testing the multiarch branch
> out of the dpkg-test APT repository which has this kind of versioning.

And that's why that belongs in such branch, for master it does not
make sense because there's no such tag there anyway, I've been meaning
to remove the tildes before uploading the final 1.16.2 in any case.

regards,
guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120131172654.GA24680@gaara.hadrons.org">http://lists.debian.org/20120131172654.GA24680@gaara.hadrons.org

Multi-arch branches
 

Guillem Jover wrote:

> I have a problem with merging unreviewed code, though, that among other
> things might and do have design issues, as witnessed in the past. I also
> have not seen Cyril jump to do any kind of code review during all this
> time as quickly as he jumped to pester and with threats to NMU a new
> *upstream release*, w/o having been involved with it at *all*, with
> known issues, regardless of maintainer disapproval...

To be honest, I think it's okay. KiBi is on the release team and
presumably was doing this (among other reasons) to help ensure _other_
packages (e.g., zlib, cupt) have the appropriate changes made and
tested to get multiarch working reasonably by the time the release
comes.

The code doesn't even have to be merged in the current form --- it's
an experiment.

The package is in experimental so packages in sid cannot depend on it
and users can reasonably expect it to have a chance of breaking their
system. As far as I can tell, the biggest risk is that packages may
rely on details of the interface that will change later. The only
cure for that I can think of is to make sure it is communicated
clearly when that happens.

Thanks for your hard work. I wish there were some easier way to
accomplish this sort of thing.

Regards,
Jonathan


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120131210015.GC13252@burratino">http://lists.debian.org/20120131210015.GC13252@burratino