-=| gregor herrmann, Sat, Sep 06, 2008 at 02:50:09PM +0200 |=-
> On Sat, 06 Sep 2008 09:03:27 +0300, Damyan Ivanov wrote:
>
> > > > > When: Wednesday, 2008-08-06, 11:00 (UTC-3)
> > > > > Where: Salón de Mar ("larger talk room", 7th floor)
> > > > And the meeting has happened!
> > https://gallery.debconf.org/v/debconf8/gwolf/080820081028.jpg.html
>
> Nice picture, but that's the openmoko-bof :)
> (Although the place is the same)
Eh, I followed Gunnar's titles :) Perhaps some the previous picture in
the gallery is indeed from the pkg-perl meeting. Not critical anyway
:)
> > > > debian/rules again
> > > > ------------------
> > > > * For mass-updates it would be nice to have the information about
> > > > which debian/rules-template is used. Ideas:
> > > > - add a "header" to debian/rules, containing some unique identifier
> > > > e.g. the version number of dh-make-perl
> > > > - save the md5sum of the used template somewhere
> > It seems natural for this place to be debian/rules itself, but I guess
> > calculating the checksum, including the checksum itself can be tricky
> > :).
>
> :)
> Therefore a unique id (like dh-make-perl version or svn revision)
> might be easier.
Thought about this, but the checksum serves one very important
function -- one can check whether the rules file was hand-modified, or
is it the same generated version and can safely be re-generated.
> > How about ignoring the lines before and including the line
> > containing the checksum? Some sed magic should be able to provide
> > that. And dh-make-perl should place the checksum in the generated
> > rules on create/refresh.
>
> Yup, could work.
> But then we'd need to keep the checksums somewhere (unless we only
> want to know if they are current or not).
I meant something like this:
#!/usr/bin/make -f
# Generated-Content-SHA1: 1234567890deadbeef
... content follows ...
with the checksum made only for the content *after* the
Generated-Content-SHA1 line, thus not including it and solving the
chicken-and-egg problem.
> > > > debian/copyright
> > > > ----------------
> > > > * "The superset of the module license and the Perl license" seems
> > > > like a good default licensing for debian/*.
> > > > * Create a boilerplate that refers to changelog for the contributors.
> > > That needs to be created. Maybe someone who speaks en_LEGAL can
> > > propose a nice wording for "Files: debian/*\nCopyright: $foo\n
> > > License: $bar"?
> > (without claiming anything about en_LEGAL): "The full list of
> > contributors can be found in /usr/share/doc/$PKG/changelog.Debian.gz"
> > This does not say anything about © holders, thugh. We keep them as it
> > is now? (i.e. 'significant' contributions lead to addition to
> > copyright holders, 'significant' evaluated by the individual
> > contributor)
>
> That of course works but having something like
> Copyright: the contributors, cf. changelog.Debian.gz
> License: $superset of ...
> might be more convenient.
I see. While I think the Copyright: part may work, the License may be
tricky. Not only because the "superset" may ot be that clear, but also
because there if upstream changes their license, that would mean that
all contributors automatically change the license of their work.
Smells bad to me :)
> > > > * We have many old minor bugs open, we need somebody to triage
> > > > them.
> > > Yes.
> > > And upgrade 3 dozens of packages ...
> > ack ack
> > Ready for upload: 0
> > Damn, we need more people/time, otherwiise the nice "they cope with
> > hundrets of packages" propaganda in Sledge's teams survey results
> > would be false :)
>
> Ack, we are a bit falling behind our normal speed at the moment.
One reason for this may be the vacations season just about to end, and
people having to catch up with their work.
My reason is more my dee[er than expected involvment with the
DebianEeePC project. Hopefully we'll fix everything that needs fixing
and I'll use the nice toy for more pkg-perl work. :)
> > > > * qareport could show a warning if debian/watch uses a non-dist URL.
> > I think such a check belongs to packagecheck, now that PET is not
> > group-specific.
>
> Good point.
> And fortunately it's in packagecheck since quite some time :)
>
Oops! :)
> > What do we do with the few packages that are not on
> > CPAN, although they are perl modules?
>
> Nothing?
> (Except adding a commented out /dist/ line to d/watch so that
> packagecheck doesn't try to create one. But I think at the moment all
> d/watch files are already up2date.)
I meant with regard to the warning you talk about. These packages
would be false positives. X-Not-CPAN: ok?
--
dam JabberID: dam@jabber.minus273.org
Attachment:
signature.asc
Description: Digital signature