FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian dpkg

 
 
LinkBack Thread Tools
 
Old 06-20-2012, 05:32 AM
Guillem Jover
 
Default Next upload 2012-06-26 (dpkg 1.16.5)

Hi!

I'm planning to upload dpkg 1.16.5 to unstable on the 26th, to be able
to finish cleaning up some pending changes I've locally and to give
some time for the initial wave of translation updates once I've sent
the call. Given that there's no exact date for the freeze yet, I'm not
sure if I'm on borrowed time, that's why I'm CCing the release team. I
could probably advance the upload by few days though.

I'll be doing a first push today. The remaning things I'll be finishing
up next are at least the strings cleanup left out from the 1.16.4
release, the cross-multiarch patches, part of the changelog binNMU
solution, and some other multiarch related improvements.

thanks,
guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120620053220.GA18674@gaara.hadrons.org">http://lists.debian.org/20120620053220.GA18674@gaara.hadrons.org
 
Old 06-20-2012, 08:42 AM
Neil McGovern
 
Default Next upload 2012-06-26 (dpkg 1.16.5)

On Wed, Jun 20, 2012 at 07:32:20AM +0200, Guillem Jover wrote:
> I'm planning to upload dpkg 1.16.5 to unstable on the 26th, to be able
> to finish cleaning up some pending changes I've locally and to give
> some time for the initial wave of translation updates once I've sent
> the call. Given that there's no exact date for the freeze yet, I'm not
> sure if I'm on borrowed time, that's why I'm CCing the release team. I
> could probably advance the upload by few days though.
>

Hi,

You are indeed on borrowed time

Advancing that as much as you can would certainly be useful to catch any
errors, and to ensure translators get a chance to contribute.

Neil
--
 
Old 06-24-2012, 08:25 PM
Touko Korpela
 
Default Next upload 2012-06-26 (dpkg 1.16.5)

On Wed, Jun 20, 2012 at 07:32:20AM +0200, Guillem Jover wrote:
> Hi!
>
> I'm planning to upload dpkg 1.16.5 to unstable on the 26th, to be able
> to finish cleaning up some pending changes I've locally and to give
> some time for the initial wave of translation updates once I've sent
> the call. Given that there's no exact date for the freeze yet, I'm not
> sure if I'm on borrowed time, that's why I'm CCing the release team. I
> could probably advance the upload by few days though.
>
> I'll be doing a first push today. The remaning things I'll be finishing
> up next are at least the strings cleanup left out from the 1.16.4
> release, the cross-multiarch patches, part of the changelog binNMU
> solution, and some other multiarch related improvements.

I think it would be good to let 1.16.4.3 migrate before next
upload, because it has some (RC) fixes good to have in testing.


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120624202511.GA4928@tiikeri.vuoristo.local
 
Old 06-27-2012, 11:40 PM
Guillem Jover
 
Default Next upload 2012-06-26 (dpkg 1.16.5)

On Wed, 2012-06-20 at 07:32:20 +0200, Guillem Jover wrote:
> I'm planning to upload dpkg 1.16.5 to unstable on the 26th,

I got tied up with other stuff, and decided that given the short
remaining time needed for 1.16.4.x to transition to testing I'd wait
for that. I've everything I wanted for 1.16.5 finished locally, just
need final polishing and doing one ore more self reviews to reduce
the chance of regressions, which I'll be doing tomorrow, followed by
the upload.

thanks,
guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120627234035.GA4536@gaara.hadrons.org">http://lists.debian.org/20120627234035.GA4536@gaara.hadrons.org
 
Old 07-21-2012, 07:56 PM
Guillem Jover
 
Default Next upload 2012-06-26 (dpkg 1.16.5)

Hey Neil!

On Wed, 2012-06-20 at 09:42:18 +0100, Neil McGovern wrote:
> On Wed, Jun 20, 2012 at 07:32:20AM +0200, Guillem Jover wrote:
> > I'm planning to upload dpkg 1.16.5 to unstable on the 26th, to be able
> > to finish cleaning up some pending changes I've locally and to give
> > some time for the initial wave of translation updates once I've sent
> > the call. Given that there's no exact date for the freeze yet, I'm not
> > sure if I'm on borrowed time, that's why I'm CCing the release team. I
> > could probably advance the upload by few days though.

> You are indeed on borrowed time
>
> Advancing that as much as you can would certainly be useful to catch any
> errors, and to ensure translators get a chance to contribute.

So, the upload happened few days later than planned, but still before
the freeze deadline. But because there were posterior uploads to fix
regressions, RC bugs and translation updates the automatic freeze
exception does not apply anymore.

The way I understood the freeze (as any feature freeze) was that code
with new features on unstable at the time of the freeze would go in
(JFTR there's been no new features added afterwards), even if they'd
require to review the subsequent changes and update the version in
the unblock. It could have happened that those regressions could have
been spotted instead after the version would have migrated to testing,
or regressions for the version in testing still be discovered, so I
don't see the big difference really.

It appears, from mails from some other release team members, the above
is not the case.

Just to clarify, because it might have seemed otherwise in my mail to
the unblock request, personally I don't have any problem per se with a
whole review of the diff between the version in testing and the one in
unstable. And even way way longer than usual delay in transitioning the
package from unstable, say at least one more month or more, to catch
any other possible regression if there's fear of that.

But then I don't think having to argue over every and each change
in 1.16.5, or having to prepare releases through t-p-u, with the
implication of needing to reissue a call for translators is a good
way of spending our collective time. And while it's not like we are
releasing immediately anyway, doing the above just implies more work
for everyone, which certainly does not help speeding up the release
process.

But then if you still disagree and require us to go through the stuff
in the above paragraphs, then I think I'll just take the blame for my
misunderstanding, notify translators they should stop bothering,
pofusely apologize to them, and very regretably leave the IMO worse
1.16.4.3 version for wheezy, and call it a day.

thanks,
guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120721195624.GA22756@gaara.hadrons.org">http://lists.debian.org/20120721195624.GA22756@gaara.hadrons.org
 
Old 07-23-2012, 02:14 PM
Neil McGovern
 
Default Next upload 2012-06-26 (dpkg 1.16.5)

Hi,

On Sat, Jul 21, 2012 at 09:56:24PM +0200, Guillem Jover wrote:
> On Wed, 2012-06-20 at 09:42:18 +0100, Neil McGovern wrote:
> > Advancing that as much as you can would certainly be useful to catch any
> > errors, and to ensure translators get a chance to contribute.
>
> So, the upload happened few days later than planned, but still before
> the freeze deadline.

ITYM the day of the freeze, 10 days later...

> But because there were posterior uploads to fix
> regressions, RC bugs and translation updates the automatic freeze
> exception does not apply anymore.
>

That would be correct, yes. It is only versions that are in unstable at
the time that get an unblock.

> The way I understood the freeze (as any feature freeze) was that code
> with new features on unstable at the time of the freeze would go in
> (JFTR there's been no new features added afterwards), even if they'd
> require to review the subsequent changes and update the version in
> the unblock.

Um, no. It's not a feature freeze. It's a Debian freeze, as has been for
the past 8 or so years. This means that someone on the release team has
to manually review the patchset.

> It could have happened that those regressions could have been spotted
> instead after the version would have migrated to testing, or
> regressions for the version in testing still be discovered, so I don't
> see the big difference really.
>

Ah, perhaps this is the confusion. The difference is the amount of time
it will take the release team to manually review every patch set.

> Just to clarify, because it might have seemed otherwise in my mail to
> the unblock request, personally I don't have any problem per se with a
> whole review of the diff between the version in testing and the one in
> unstable. And even way way longer than usual delay in transitioning the
> package from unstable, say at least one more month or more, to catch
> any other possible regression if there's fear of that.
>

Yes, the issue is that the release team need to manually review the
patch set, not you.

> But then I don't think having to argue over every and each change
> in 1.16.5, or having to prepare releases through t-p-u, with the
> implication of needing to reissue a call for translators is a good
> way of spending our collective time.

Well, it requires much less work for the release team, who no longer
need to manually review the patch set.

> And while it's not like we are releasing immediately anyway, doing the
> above just implies more work for everyone, which certainly does not
> help speeding up the release process.

I've started to see this in a couple of places now. Let me be as clear
as possible in case anyone hasn't noticed.

*************************************
*** WE HAVE FROZEN DEBIAN WHEEZY. ***
*************************************

This does not mean you can upload random stuff to the archive because
the release is "ages away". This sort of wooly thinking helps generate a
self fulfilling prophecy that delays the release and harms Debian
overall. It means that the release team need to spend a lot of manual
time reviewing the patch sets and thus can't concentrate on RC bugs.

> But then if you still disagree and require us to go through the stuff
> in the above paragraphs, then I think I'll just take the blame for my
> misunderstanding, notify translators they should stop bothering,
> pofusely apologize to them, and very regretably leave the IMO worse
> 1.16.4.3 version for wheezy, and call it a day.

That is of course, your perogative. However, if you could kindly prepare
a patchset between 1.16.5 and whatever you want to migrate, with all the
translation and documentation changes stripped out, lets see how big
that is.

Thanks,
Neil
--
 
Old 07-23-2012, 04:38 PM
Julien Cristau
 
Default Next upload 2012-06-26 (dpkg 1.16.5)

On Mon, Jul 23, 2012 at 15:14:15 +0100, Neil McGovern wrote:

> That is of course, your perogative. However, if you could kindly prepare
> a patchset between 1.16.5 and whatever you want to migrate, with all the
> translation and documentation changes stripped out, lets see how big
> that is.
>
ITYM 1.16.4.3.

Cheers,
Julien
 
Old 07-23-2012, 04:51 PM
Neil McGovern
 
Default Next upload 2012-06-26 (dpkg 1.16.5)

On Mon, Jul 23, 2012 at 06:38:21PM +0200, Julien Cristau wrote:
> On Mon, Jul 23, 2012 at 15:14:15 +0100, Neil McGovern wrote:
>
> > That is of course, your perogative. However, if you could kindly prepare
> > a patchset between 1.16.5 and whatever you want to migrate, with all the
> > translation and documentation changes stripped out, lets see how big
> > that is.
> >
> ITYM 1.16.4.3.
>

Nope, 1.16.5. I'd like to see that to get a view as to why 1.16.5 was
broken. Once we've managed to have a look at that, it may give a clue as
to if it's worth reviewing the giant-diff-from-doom.

Neil
--
 
Old 07-23-2012, 05:18 PM
Guillem Jover
 
Default Next upload 2012-06-26 (dpkg 1.16.5)

Hi!

On Mon, 2012-07-23 at 17:51:56 +0100, Neil McGovern wrote:
> On Mon, Jul 23, 2012 at 06:38:21PM +0200, Julien Cristau wrote:
> > On Mon, Jul 23, 2012 at 15:14:15 +0100, Neil McGovern wrote:
> >
> > > That is of course, your perogative. However, if you could kindly prepare
> > > a patchset between 1.16.5 and whatever you want to migrate, with all the
> > > translation and documentation changes stripped out, lets see how big
> > > that is.

> > ITYM 1.16.4.3.

> Nope, 1.16.5. I'd like to see that to get a view as to why 1.16.5 was
> broken. Once we've managed to have a look at that, it may give a clue as
> to if it's worth reviewing the giant-diff-from-doom.

Thanks, attached the filtered diff (with additional junk left by
filterdiff, but left the changelog) from git:

$ git diff 1.16.5..1.16.8 |
filterdiff -x '*.po' -x '*.pot' -x '*/man/*' -x '*/doc/*' >
dpkg-1.16.5-1.16.8.patch

I can also send the git commit logs if you'd want that. The SE Linux
regression has been present since SE Linux support was added to dpkg.

thanks,
guillem
 
Old 07-28-2012, 09:59 AM
Neil McGovern
 
Default Next upload 2012-06-26 (dpkg 1.16.5)

On Mon, Jul 23, 2012 at 07:18:29PM +0200, Guillem Jover wrote:
> On Mon, 2012-07-23 at 17:51:56 +0100, Neil McGovern wrote:
> > Nope, 1.16.5. I'd like to see that to get a view as to why 1.16.5 was
> > broken. Once we've managed to have a look at that, it may give a clue as
> > to if it's worth reviewing the giant-diff-from-doom.
>
> Thanks, attached the filtered diff (with additional junk left by
> filterdiff, but left the changelog) from git:
>

Right, the delta diff was small enough that I actually put in the time
to look at the full diff. This took a number of hours, but anyway:

Some questions:
dpkg-1.16.8/dpkg-deb/main.c
-" -h|--help Show this help message.
"
-" --version Show the version.
"
+" -?, --help Show this help message.
"
+" --version Show the version.
"
Why are you removing -h?

dpkg-1.16.8/lib/dpkg/ar.c
+ if (strlen(name) > 15)
+ ohshit(_("ar member name '%s' length too long"), name);
+ if (size > 9999999999L)
+ ohshit(_("ar member size %jd too large"), size);
+
Why 9999999999?

dpkg-1.16.8/scripts/Dpkg/Deps.pm
- (any) # architecture name
+ ([a-zA-Z0-9][a-zA-Z0-9-]*) # architecture name
Why the additional restriction?

*.gmo - are you sure you're meant to be shipping these in the tarball?

Thanks,
Neil
--
 

Thread Tools




All times are GMT. The time now is 08:21 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org