Next upload 2008-01-20 (dpkg 1.14.16)
Hi, So let's target next release for this sunday (latish). dpkg should migrate to testing today or so and there has not been major regressions. I've pending for commit, the feature-removal-schedule and api docs, probably merging few more patches from the BTS, and I'll review Tollef's filter code, if I feel confortable and doesn't seem too disruptive I'll merge it as well, otherwise it will have to wait. Raphaël, are you planning to commit the parse_changelog stuff? regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Next upload 2008-01-20 (dpkg 1.14.16)
Hi, On Fri, 18 Jan 2008, Guillem Jover wrote: > I've pending for commit, the feature-removal-schedule and api docs, > probably merging few more patches from the BTS, and I'll review > Tollef's filter code, if I feel confortable and doesn't seem too > disruptive I'll merge it as well, otherwise it will have to wait. > > Raphaël, are you planning to commit the parse_changelog stuff? Yes, I believe it's ready. I'll push it today so that others can run it as well and discover problems if any. Cheersn -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] Enhance checksum support
On Mon, Jan 14, 2008 at 08:53:13AM +0100, Raphael Hertzog wrote:
> There's also a possibility of not breaking the compatibility by simply
> adding a new field and leaving "Files" untouched:
> Checksums:
>
> I think it would be best that way. The size of the file then stay in the
> Files field as would the md5sum. If the user enables additional checksums,
> they end up in this new field.
It'd actually be good to be able to break Files in future, so that we're
forced to verify something other than md5sum. Otherwise there will
be code that doesn't check it properly, and that will end up being a
security problem.
Having it be:
Contents: sha256
28ee6a10eb280ede4b19c1b975aff5533016a26de67ba9212d51ffaea020ce34 355 foo
Files:
4bf7ff17bd9ddf3846d9065b3c594fb4 355 foo
or similar would be nice and non-redundant, and make it possible to drop
the Files: stanza at some point. I guess Contents-sha256: might be easier
to parse. Or call it "Checksum" or whatever.
I guess that means changing:
+foreach my $alg (sort keys %sums) {
+ $fields->{'Checksums'} .= "\n $alg\t$sums{$alg} $filename";
+}
to:
+foreach my $alg (sort keys %sums) {
+ $fields->{'Checksum-$alg'} .= "\n $sums{$alg} $size $filename";
+}
and something similar for parsing. Is there a git branch/repo with these
changes somewhere?
Cheers,
aj
signature.asc
Description: Digital signature
Re: [RFC] Enhance checksum support
On Fri, Jan 18, 2008 at 11:38:55PM +1000, Anthony Towns wrote: > and something similar for parsing. Is there a git branch/repo with these > changes somewhere? (Will comment on your suggestions later) No, there is no public repository with these, and in this early stage of playing I see no real reason to do so since that would effectivly force me to retain the older versions and work on top of them. Please just use git-am if you want to try the code yourself. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] Integrated dpkg-parsechangelog processing into Dpkg::Changelog::parse_changelog()
On Thu, Jan 17, 2008 at 11:41:04PM +0100, Raphael Hertzog wrote: > > That is a behavioural change, right? Up to now, dpkg-genchanges > > includes all the descriptions in source-only uploads. I'm not sure this is > > a behaviour we need to keep, just making sure everyone is aware that we > > do. > > Indeed. It also means that XC-* fields are not forwarded for source-only > uploads (but IMO, XC-* should only have an effect in the source part of the > control file in general, but that's another discussion). > > We already don't include descriptions (and XC fields) of packages that have no > corresponding .deb file uploaded (even if they are valid packages that are > simply not built on the architecture of this upload). So this seemed like the > logical behaviour for a source only upload. > > It's highly unlikely that we break anything with this change but on the other > hand, as a frequent reviewer of .changes files, I appreciate having > descriptions... so I'm wondering if we shouldn't change the behaviour in the > opposite direction (always include all descriptions of all binary packages > even > those which are not uploaded). > > Opinions? I would support that. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
dpkg 1.14.15 MIGRATED to testing
FYI: The status of the dpkg source package in Debian's testing distribution has changed. Previous version: 1.14.7 Current version: 1.14.15 -- This email is automatically generated; [EMAIL PROTECTED] is responsible. See http://people.debian.org/~henning/trille/ for more information. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Next upload 2008-01-20 (dpkg 1.14.16)
On Fri, Jan 18, 2008 at 10:21:14AM +0200, Guillem Jover wrote: > So let's target next release for this sunday (latish). dpkg should > migrate to testing today or so and there has not been major > regressions. > > I've pending for commit, the feature-removal-schedule and api docs, > probably merging few more patches from the BTS, and I'll review > Tollef's filter code, if I feel confortable and doesn't seem too > disruptive I'll merge it as well, otherwise it will have to wait. What about the proposal to change the maintainer address to this mailing list. I've not heard any objections to that. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Next upload 2008-01-20 (dpkg 1.14.16)
Quoting Guillem Jover ([EMAIL PROTECTED]): > Hi, > > So let's target next release for this sunday (latish). dpkg should > migrate to testing today or so and there has not been major > regressions. Could you re-update the po/ directory (unless you're sure that no string changes happened since last update)? signature.asc Description: Digital signature
