Re: Bug#855028: ITP: fonts-sansation -- Clean, futuristic font by Bernd Montag
On Mon, Feb 13, 2017 at 01:55:24PM +0200, Kyle Robbertze wrote: > * Package name: fonts-sansation > Version : 1.31 > Upstream Author : Berd Montag > * URL : http://www.dafont.com/sansation.font > * License : OFL-1.1 I don't see any mention of the OFL-1.1 for this font. In fact, the font comes with a ReadMe.txt that says this: "This font family is freeware and can be used freely for personal and commercial purposes." Looks good, but no permission to modify. As for redistributions, it says this: "You may share this font on CDs, websites,... with the following restrictions: - Modification of the font files is only allowed for personal use - don't distribute a modified version of the font files! - Do not rename the font files! - Do not sell the font files! - Do not pass the font files without this textfile! - Make sure you have downloaded the latest update from www.dafont.com for best optical results." So, modification is not allowed. That makes the font non-free. If empty-epsilon depends on this font, then empty-epsilon has to go to contrib. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Re: changelog practice, unfinalised vs UNRELEASED vs ~version
Simon McVittie writes ("Re: changelog practice, unfinalised vs UNRELEASED vs
~version"):
> If I'm understanding correctly, your motivation to do so is that you
> have a strong belief that building a Debian source package with `debuild`
> or similar, directly from a VCS checkout, should always work and should
> always produce results that could be considered correct (in terms of not
> having the version number of a prior version, not having the version
> number of a future version either, not claiming to have been released
> by a person who did not in fact release it, and so on).
I wouldn't say I have a "strong belief" in these notions. I mean, I
do broadly agree with them.
I think it is much more tolerable to have build reuse the version
number of an actually-uploaded previous version. This is because in
that case the uploaded version is still available via the archive. So
confusion is less likely. But I still don't think it's very
desirable.
> Broadly, the two extremes of workflows for Debian packages' changelogs
> maintained in git seem to be:
>
> * Write the changelog as you go along: [...]
> * Write the changelog later: each commit just has a commit message
> in a normal git way, and its debian/changelog is out of date. [...]
> * Mostly write the changelog later, as in the second model.
> Periodically summarize the changelog so far [...]
Contrary to what Ben seems to have read into my message, I don't have
an opinion about this. I use all three of these workflows on
different occasions. I don't understand why you and Ben see a
connection between my suggestions and the choice between these
workflows.
> While as an abstract model I agree that the uploader name and date
> are not meaningful in an unreleased version, I can't help thinking
> that this is a "boil the ocean" sort of change - a lot of tools follow
> and require Policy syntax, in which the uploader name and date are
> non-optional.
Policy can be changed. Obviously what I am proposing should be
written in policy.
> Allowing and ignoring an arbitrary and non-meaningful uploader and date,
> or possibly establishing a convention like Unreleased
> for the unreleased uploader, seems more pragmatic.
I don't understand why it is better to have dummy (or wrong) data than
no data. Of course there will be a bit of work to update our tools
but there is a fairly limited set of them and the changes are not
difficult.
> Our experience with this script and workflow has mostly been very positive,
> and I intend to integrate similar functionality into Vectis[2] soon. The
> one thing I'm regretting is making it switch behaviour based on whether
> the current version is tagged; I think that's "too much magic", and it
> forces you to tag a version before you have built and tested it.
I confess I don't understand all of this, but I think we should agree,
as a project on some conventions about what debian/changelog would
mean if you find it in some vcs branch (or, for that matter, a tarball
or whatever someone sends you). I definitely don't think vcs tags are
the right answer. They are not always transported with the revision
and vcs-unaware tools cannot see them at all.
> Clearly, the down side of this approach is that it doesn't work as-is
> with debuild or similar, violating what I believe to be the axiom you're
> working from - the developer has to run a special script instead.
I think we should be aiming to reduce the need for special scripts.
I think our current practices (and tooling) are mostly a mess, and
when they are not a mess they are quite suboptimal. If we want to
improve this, it can't be done by telling everyone to "just run this
script".
> > Q1. Should the suite in the changelog entry be UNRELEASED,
> > or the suite at which the vcs branch is targeted ?
>
> If you're trying to change common practice (being prescriptive rather than
> descriptive) *anyway*, maybe something like experimental-UNRELEASED that
> contains both, with UNRELEASED being shorthand for unstable-UNRELEASED
> (or possibly ${current development suite}-UNRELEASED in Ubuntu
> and other derivatives)?
This would be another approach. But it is not as good as decorating
the version, because it's not usually desirable to generate binaries
with version numbers that will be reused.
Ian.
Re: changelog practice, unfinalised vs UNRELEASED vs ~version
Simon McVittie writes ("Re: changelog practice, unfinalised vs UNRELEASED vs
~version"):
> On Mon, 13 Feb 2017 at 09:42:32 +1100, Ben Finney wrote:
> > I don't see how this complaint is any different from the need to merge,
> > for example, changes to API documentation and test cases that accompany
> > a functional change.
>
> It's the difference between "sometimes conflicts" and "always conflicts".
This is a very real problem for debian/changelog, but mergechangelogs
helps a lot. In any case as I say I'm not trying to mandate the
workflow where the changelog is updated as-we-go.
Ian.
Re: changelog practice, unfinalised vs UNRELEASED vs ~version
Sean Whitton writes ("Re: changelog practice, unfinalised vs UNRELEASED vs
~version"):
> On Sun, Feb 12, 2017 at 12:48:35PM +, Ian Jackson wrote:
> > Q1. Should the suite in the changelog entry be UNRELEASED,
> > or the suite at which the vcs branch is targeted ?
> > [...]
> > Q1: Replacing the suite with "UNRELEASED" means that it is not
> > possible to distinguish a branch intended for experimental from one
> > intended for sid, other than by branch name (and of course branch
> > names are often used for other purposes). I think this is very
> > undesirable. AFAICT only reason to use UNRELEASED is to prevent
> > accidental upload, but maybe we can do that some other way.
>
> Why do you think this is "very" undesirable? At worst, you have to ask
> the person who committed to the branch what their intention was, and
> you're probably talking to them anyway.
No, at worst you upload to unstable something that ought to have gone
to experimental, because the tooling failed to notice your mistake.
If you had been able to note somehow in the relevant vcs branch that
it was intended for experimental, you have a much better chance of
having done so - and the tools would then be able to catch it.
> > Q2. Should the changelog entry be finalised ? That is, should it
> > have an uploader name and date ?
>
> Just a terminological point:
>
> I use "finalised" to mean "suite is not UNRELEASED and timestamp is not
> behind the last change" -- i.e. `dch -r` has been run and the result
> committed.
>
> I suspect I'm not alone in using "finalised" to refer to this, given the
> behaviour of `dch`. It is only the Emacs changelog mode which leaves no
> name and e-mail.
There's two meanings of "finalised" then.
One is "contains name, email address, and date of purported decision
to upload". (Let's call that "with trailer" from now on.)
The other meaning is "has been updated to reflect decision to upload,
including recording name and email of the person making that decison
and the time they did so". (Let's call that "upload decided".)
I think that recording a false or dummy set of information about a
purported upload decision is a silly way of recording the fact that
the upload decision has not, in fact, been taken.
I think tools and people only do it this way because some other tools
have been grumpy about changelogs without trailers. This is also
silly, since they're all our tools and we could just fix them.
> > Q3. Should the version number be the intended next version number,
> > or should it be decorated with ~something ? If it should
> > be decorated, what should it be decorated with ?
> > [...]
> > Q3. If the version number is not decorated, then binaries (or even
> > source packages!) built for testing (or for other reasons other than
> > upload) are not always distinguishable from intended-for-release
> > builds. IMO this is very undesirable.
>
> If we use dgit for all our uploads then this doesn't really matter :)
That's not true. I would like to know, for example, whether the
version of sysvinit I have running on my laptop is the version I
finally uploaded to sid, or some pre-release which might not be
identical to sid's.
Ian.
Re: changelog practice, unfinalised vs UNRELEASED vs ~version
Wookey writes ("Re: changelog practice, unfinalised vs UNRELEASED vs ~version"):
> I'd be happier if I didn't have to deal with 'UNRELEASED' at all
> unless I actually wanted to, so I'm not at all keen on your suggestion
> of making it mandatory.
Well, tools can be configured, too. If my UNRELEASED version proposal
is adopted, we could easily let you have a DEB_ENABLE_FOOTGUN variable
that will let you become confused about what binaries and sources are
what, by reusing version numbers from ad-hoc test builds.
> 1. I really dislike dch's enthusiasm for putting in 'UNRELEASED'. It
> gives me nothing I wanted, and just provides the opportunity to really
> do a final, clean, tested, build, only to find on upload that it's
> still marked 'UNRELASED', and I have to do the build, test, upload
> step again - for big packages that is a huge pain and happens way too
> often. I really resent that there is no way to do dch -i;dch -r in one
> go - the separation of these is just makework for me.
Does that mean that if you tested ~UNRELEASED, and it passed all your
tests, you would be unhappy to strip the ~UNRELEASED from the version
and upload it ?
I often do that. My tools make it very hard for me to mess this up by
uploading anything whose source tree (besides the changelog and
therefore besides the version number) differs to what I tested.
(Of course in principle there might be situations where version
X~UNRELEASED would be treated differently to X. If that's likely to
be going on then I would have to, regrettably, use the actual
for-release version number for your ad-hoc tests.)
> > Proposal:
> >
> > * Tools which add/edit changelog change items should insist that the
> >changelog is unfinalised and contains ~UNRELEASED in its version.
>
> I really don't want this to be _required_. Dicking with the version is
> better than dicking with the suite, but I really would prefer it if
> the tools did neither, or could simply be asked to.
>
> I realise that I'm pushing uphill somewhat here and no-one much cares
> about people who still don't use git if they don't have to. But the
> UNRELEASED/'dch -r' thing pisses me off on a daily basis, and this
> seemed like the time to point out that some of us don't find it all
> helpful. From that POV, moving it from suite to version would
> definitely be less annoying.
Well, I guess you'd be satisfied with an option to disable this
behaviour.
But: it seems that intend to make commits whose debian/changelog has a
trailer line, a real suite, and a real version, but where the commit
does not contain all the changes ? I think that's poor practice.
These commits are a liability. If you push such a commit, and then
later make more changes and do the upload, but forget to to push, a
subsequent upload made from the vcs might lack your changes.
Of course if you really insist you can do this, and probably if the
commits are buried in the history so that no-one every sees them
except when doing archaeology, then there is little chance of your
metadata misleading anyone but you into a mistake.
I don't know how you avoid mistakes. Perhaps you're just very
careful.
Ian.
