Re: urw-fonts: Versioning Mess

[David Kaspar [Dee'Kej]]

OK, I will proceed with Domininik's or Zbigniew's idea. Thanks all to your
suggestions. :)

David Kaspar [Dee'Kej]
*Associate Software Engineer*
*Brno, Czech Republic*

RED HAT | TRIED. TESTED. TRUSTED.
Every airline in the Fortune 500 relies on Red Hat.
Find out why at Trusted | Red Hat .

On Thu, Dec 1, 2016 at 9:13 AM, Pierre-Yves Chibon 
wrote:

> On Thu, Dec 01, 2016 at 01:37:18AM +, Zbigniew Jędrzejewski-Szmek
> wrote:
> > On Wed, Nov 30, 2016 at 05:35:19PM +0100, Dominik 'Rathann' Mierzejewski
> wrote:
> > > On Wednesday, 30 November 2016 at 16:07, David Kaspar [Dee'Kej] wrote:
> > > > On Wed, Nov 30, 2016 at 12:38 PM, Dominik 'Rathann' Mierzejewski <
> > > > domi...@greysector.net> wrote:
> > > [...]
> > > > I'm not sure where your Version == 1.0 comes from. If they're
> versioned
> > > > > only by date now, then you have two options. Use Version: 0 in the
> new
> > > > > package in anticipation of upstream eventually reintroducing
> semantic
> > > > > versioning. Or, Version: MMDD. Admittedly, the latter looks
> nicer
> > > > > and upstream already said they'll stick to it.
> > > > >
> > > > The Version == 1.0 comes from the source code of the fonts
> themselves.
> > > > Running 'grep "Version" *.afm' tells me that there are all files with
> > > > Version == 1.0, except two of them (which have Version
> > >
> > > If they don't have the same version then it doesn't make sense to use
> > > the version of *some* of them as base.
> > >
> > > > > If you worry about upstream versioning sanity, then stick with
> > > > > Version: 0
> > > > > and follow the snapshot versioning guidelines.
> > > > >
> > > > > > There's also one more option, and that is to base the package on
> > > > > > upstream's git repository and the snapshot scheme, because we
> > > > > > would be using snapshot string in the package name anyway. And it
> > > > > > would also solve one more issue that upstream is not shipping
> > > > > > license files in the archive. (I have already contacted to
> correct
> > > > > > this.)
> > > > >
> > > > > The exact location of the source doesn't matter too much as long
> as it's
> > > > > official and pristine. I agree it might be better to use the git
> repo
> > > > > directly since it contains both the licence indication and its full
> > > > > text.
> > > > >
> > > > Upstream has heard to my request and fixed it. (
> > > > http://bugs.ghostscript.com/show_bug.cgi?id=697390)
> > > >
> > > > And yes, what Douhlas wrote is correct (about the 35 fonts), and I
> will
> > > > have that noted in the %description section.
> > > >
> > > > Anyway, since determining the Version field is still unclear, I
> think the
> > > > most sense to me right now is to proceed with option 2) - IOW - to
> bypass
> > > > the versioning from URW++ completely, and have Version field based on
> > > > snapshot string, in a way:
> > > > X.Y.Z == .MM.DD
> > > >
> > > > Or do you some problem with this approach?
> > >
> > > As I said, please do not invent the version on your own. Please apply
> > > the existing snapshot guidelines instead, i.e.:
> > > Version: 0
> > >
> > > Release: 0.N.MMDD
> > > or
> > > Release: 0.N.MMDDgitHASH
> >
> > Or even better, as you proposed in the other e-mail, Version: MMDD.
> > This is much nicer for users, and actually easier for the maintainer
> > of the package. David seems to ignore this option for some reason,
> > but it really seems the best one.
> >
> > (If upstream does something crazy and it is necessary to change the
> > versioning scheme again in the future, adding an epoch is always an
> > option.)
>
> Since I guess the idea of this thread is to avoid using epoch, I think the
> better approach is to stick with the Dominik's suggestions. It is what
> gives the
> most flexibility for future changes.
>
>
> Pierre
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: urw-fonts: Versioning Mess

[Pierre-Yves Chibon]

On Thu, Dec 01, 2016 at 01:37:18AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Nov 30, 2016 at 05:35:19PM +0100, Dominik 'Rathann' Mierzejewski 
> wrote:
> > On Wednesday, 30 November 2016 at 16:07, David Kaspar [Dee'Kej] wrote:
> > > On Wed, Nov 30, 2016 at 12:38 PM, Dominik 'Rathann' Mierzejewski <
> > > domi...@greysector.net> wrote:
> > [...]
> > > I'm not sure where your Version == 1.0 comes from. If they're versioned
> > > > only by date now, then you have two options. Use Version: 0 in the new
> > > > package in anticipation of upstream eventually reintroducing semantic
> > > > versioning. Or, Version: MMDD. Admittedly, the latter looks nicer
> > > > and upstream already said they'll stick to it.
> > > >
> > > The Version == 1.0 comes from the source code of the fonts themselves.
> > > Running 'grep "Version" *.afm' tells me that there are all files with
> > > Version == 1.0, except two of them (which have Version
> > 
> > If they don't have the same version then it doesn't make sense to use
> > the version of *some* of them as base.
> > 
> > > > If you worry about upstream versioning sanity, then stick with
> > > > Version: 0
> > > > and follow the snapshot versioning guidelines.
> > > >
> > > > > There's also one more option, and that is to base the package on
> > > > > upstream's git repository and the snapshot scheme, because we
> > > > > would be using snapshot string in the package name anyway. And it
> > > > > would also solve one more issue that upstream is not shipping
> > > > > license files in the archive. (I have already contacted to correct
> > > > > this.)
> > > >
> > > > The exact location of the source doesn't matter too much as long as it's
> > > > official and pristine. I agree it might be better to use the git repo
> > > > directly since it contains both the licence indication and its full
> > > > text.
> > > >
> > > Upstream has heard to my request and fixed it. (
> > > http://bugs.ghostscript.com/show_bug.cgi?id=697390)
> > > 
> > > And yes, what Douhlas wrote is correct (about the 35 fonts), and I will
> > > have that noted in the %description section.
> > > 
> > > Anyway, since determining the Version field is still unclear, I think the
> > > most sense to me right now is to proceed with option 2) - IOW - to bypass
> > > the versioning from URW++ completely, and have Version field based on
> > > snapshot string, in a way:
> > > X.Y.Z == .MM.DD
> > > 
> > > Or do you some problem with this approach?
> > 
> > As I said, please do not invent the version on your own. Please apply
> > the existing snapshot guidelines instead, i.e.:
> > Version: 0
> > 
> > Release: 0.N.MMDD
> > or
> > Release: 0.N.MMDDgitHASH
> 
> Or even better, as you proposed in the other e-mail, Version: MMDD.
> This is much nicer for users, and actually easier for the maintainer
> of the package. David seems to ignore this option for some reason,
> but it really seems the best one.
> 
> (If upstream does something crazy and it is necessary to change the
> versioning scheme again in the future, adding an epoch is always an
> option.)

Since I guess the idea of this thread is to avoid using epoch, I think the
better approach is to stick with the Dominik's suggestions. It is what gives the
most flexibility for future changes.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: urw-fonts: Versioning Mess

[Zbigniew Jędrzejewski-Szmek]

On Wed, Nov 30, 2016 at 05:35:19PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> On Wednesday, 30 November 2016 at 16:07, David Kaspar [Dee'Kej] wrote:
> > On Wed, Nov 30, 2016 at 12:38 PM, Dominik 'Rathann' Mierzejewski <
> > domi...@greysector.net> wrote:
> [...]
> > I'm not sure where your Version == 1.0 comes from. If they're versioned
> > > only by date now, then you have two options. Use Version: 0 in the new
> > > package in anticipation of upstream eventually reintroducing semantic
> > > versioning. Or, Version: MMDD. Admittedly, the latter looks nicer
> > > and upstream already said they'll stick to it.
> > >
> > The Version == 1.0 comes from the source code of the fonts themselves.
> > Running 'grep "Version" *.afm' tells me that there are all files with
> > Version == 1.0, except two of them (which have Version
> 
> If they don't have the same version then it doesn't make sense to use
> the version of *some* of them as base.
> 
> > > If you worry about upstream versioning sanity, then stick with
> > > Version: 0
> > > and follow the snapshot versioning guidelines.
> > >
> > > > There's also one more option, and that is to base the package on
> > > > upstream's git repository and the snapshot scheme, because we
> > > > would be using snapshot string in the package name anyway. And it
> > > > would also solve one more issue that upstream is not shipping
> > > > license files in the archive. (I have already contacted to correct
> > > > this.)
> > >
> > > The exact location of the source doesn't matter too much as long as it's
> > > official and pristine. I agree it might be better to use the git repo
> > > directly since it contains both the licence indication and its full
> > > text.
> > >
> > Upstream has heard to my request and fixed it. (
> > http://bugs.ghostscript.com/show_bug.cgi?id=697390)
> > 
> > And yes, what Douhlas wrote is correct (about the 35 fonts), and I will
> > have that noted in the %description section.
> > 
> > Anyway, since determining the Version field is still unclear, I think the
> > most sense to me right now is to proceed with option 2) - IOW - to bypass
> > the versioning from URW++ completely, and have Version field based on
> > snapshot string, in a way:
> > X.Y.Z == .MM.DD
> > 
> > Or do you some problem with this approach?
> 
> As I said, please do not invent the version on your own. Please apply
> the existing snapshot guidelines instead, i.e.:
> Version: 0
> 
> Release: 0.N.MMDD
> or
> Release: 0.N.MMDDgitHASH

Or even better, as you proposed in the other e-mail, Version: MMDD.
This is much nicer for users, and actually easier for the maintainer
of the package. David seems to ignore this option for some reason,
but it really seems the best one.

(If upstream does something crazy and it is necessary to change the
versioning scheme again in the future, adding an epoch is always an
option.)

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: urw-fonts: Versioning Mess

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 30 November 2016 at 16:07, David Kaspar [Dee'Kej] wrote:
> On Wed, Nov 30, 2016 at 12:38 PM, Dominik 'Rathann' Mierzejewski <
> domi...@greysector.net> wrote:
[...]
> I'm not sure where your Version == 1.0 comes from. If they're versioned
> > only by date now, then you have two options. Use Version: 0 in the new
> > package in anticipation of upstream eventually reintroducing semantic
> > versioning. Or, Version: MMDD. Admittedly, the latter looks nicer
> > and upstream already said they'll stick to it.
> >
> The Version == 1.0 comes from the source code of the fonts themselves.
> Running 'grep "Version" *.afm' tells me that there are all files with
> Version == 1.0, except two of them (which have Version

If they don't have the same version then it doesn't make sense to use
the version of *some* of them as base.

> > If you worry about upstream versioning sanity, then stick with
> > Version: 0
> > and follow the snapshot versioning guidelines.
> >
> > > There's also one more option, and that is to base the package on
> > > upstream's git repository and the snapshot scheme, because we
> > > would be using snapshot string in the package name anyway. And it
> > > would also solve one more issue that upstream is not shipping
> > > license files in the archive. (I have already contacted to correct
> > > this.)
> >
> > The exact location of the source doesn't matter too much as long as it's
> > official and pristine. I agree it might be better to use the git repo
> > directly since it contains both the licence indication and its full
> > text.
> >
> Upstream has heard to my request and fixed it. (
> http://bugs.ghostscript.com/show_bug.cgi?id=697390)
> 
> And yes, what Douhlas wrote is correct (about the 35 fonts), and I will
> have that noted in the %description section.
> 
> Anyway, since determining the Version field is still unclear, I think the
> most sense to me right now is to proceed with option 2) - IOW - to bypass
> the versioning from URW++ completely, and have Version field based on
> snapshot string, in a way:
> X.Y.Z == .MM.DD
> 
> Or do you some problem with this approach?

As I said, please do not invent the version on your own. Please apply
the existing snapshot guidelines instead, i.e.:
Version: 0

Release: 0.N.MMDD
or
Release: 0.N.MMDDgitHASH

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: urw-fonts: Versioning Mess

[David Kaspar [Dee'Kej]]

On Wed, Nov 30, 2016 at 12:38 PM, Dominik 'Rathann' Mierzejewski <
domi...@greysector.net> wrote:

> I also found this:
> http://git.ghostscript.com/?p=urw-core35-fonts.git;a=summary
> and they're called urw-core35-fonts here. It might be wise to ask
> upstream to clarify before choosing the new package name.
>
​OK, will do.​

I'm not sure where your Version == 1.0 comes from. If they're versioned
> only by date now, then you have two options. Use Version: 0 in the new
> package in anticipation of upstream eventually reintroducing semantic
> versioning. Or, Version: MMDD. Admittedly, the latter looks nicer
> and upstream already said they'll stick to it.
>
​The Version == 1.0 comes from the source code of the fonts themselves.​
Running 'grep "Version" *.afm' tells me that there are all files with
Version == 1.0, except two of them (which have Version

​

> If you worry about upstream versioning sanity, then stick with
> Version: 0
> and follow the snapshot versioning guidelines.
>
> > There's also one more option, and that is to base the package on
> upstream's
> > git repository and the snapshot scheme, because we would be using
> snapshot
> > string in the package name anyway. And it would also solve one more issue
> > that upstream is not shipping license files in the archive. (I have
> already
> > contacted to correct this.)
>
> The exact location of the source doesn't matter too much as long as it's
> official and pristine. I agree it might be better to use the git repo
> directly since it contains both the licence indication and its full
> text.
>
​Upstream has heard to my request and fixed it. (
http://bugs.ghostscript.com/show_bug.cgi?id=697390)​

​And yes, what Douhlas wrote is correct ​(about the 35 fonts), and I will
have that noted in the %description section.

Anyway, since determining the Version field is still unclear, I think the
most sense to me right now is to proceed with option 2) - IOW - to bypass
the versioning from URW++ completely, and have Version field based on
snapshot string, in a way:
X.Y.Z == .MM.DD

Or do you some problem with this approach?

Thanks! :)
​​
David Kaspar [Dee'Kej]
*Associate Software Engineer*
*Brno, Czech Republic*

RED HAT | TRIED. TESTED. TRUSTED.
Every airline in the Fortune 500 relies on Red Hat.
Find out why at Trusted | Red Hat .​
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: urw-fonts: Versioning Mess

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 30 November 2016 at 14:17, Douglas Kosovic wrote:
> On 30/11/2016, 9:38 PM, "Dominik 'Rathann' Mierzejewski" 
>  wrote:
>>> 2) or map the X.Y.Z versioning to MMDD from upstream - IOW - X == Year,
>>> Y == Month, Z == Day (based on the snapshot date in the name of the source
>>> archive)
>>> 3) or set the Version to some constant (35 for example) and just use the
>>> snapshot to distinguish between older and newer releases.
>>
>> What does the number "35" mean here, anyway?
> 
> Each PostScript specification defines a core set of fonts:
> - PostScript 1 has 13 base fonts.
> - PostScript 2 has 35 base fonts.
> - PostScript 3 has 135 base fonts.
> 
> So, the URW++ base35 font pack is a replacement for the 35 Adobe PostScript
> Level 2 base fonts.

Thanks for the explanation. It would be useful to put this information
in the Summary of the new package if not in the name. Definitely not in
the version field as it has nothing to do with versioning.

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: urw-fonts: Versioning Mess

[Douglas Kosovic]

On 30/11/2016, 9:38 PM, "Dominik 'Rathann' Mierzejewski" 
 wrote:

> 2) or map the X.Y.Z versioning to MMDD from upstream - IOW - X == 
Year,
> Y == Month, Z == Day (based on the snapshot date in the name of the source
> archive)
> 3) or set the Version to some constant (35 for example) and just use the
> snapshot to distinguish between older and newer releases.

What does the number "35" mean here, anyway?

Each PostScript specification defines a core set of fonts:
- PostScript 1 has 13 base fonts.
- PostScript 2 has 35 base fonts.
- PostScript 3 has 135 base fonts.

So, the URW++ base35 font pack is a replacement for the 35 Adobe PostScript 
Level 2 base fonts.



Doug



 

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: urw-fonts: Versioning Mess

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 30 November 2016 at 12:14, David Kaspar [Dee'Kej] wrote:
> I took over the maintenance of urw-fonts to update them to the latest
> version (ghostscript and other packages needs them). However, there are
> several problems in versioning of it, and I would like to discuss future
> steps for the package.
> 
> The current problems:
[...]
> * we obtain the source archive from Artifex (aka upstream responsible for
> ghostscript), nowadays they are no longer using the X.Y.Z versioning
> system. Instead, they have created a separate git repository for it, and
> are doing "snapshot based" releases... Their latest release is:
> urw-base35-20160926.zip

Do you mean this location? http://downloads.ghostscript.com/public/fonts/

> * I asked them if they could go back to X.Y.Z versioning system, here's
> what Chris Liddell replied:
> 
> "If you check the versions in the font files, you'll see why I switched to
> the release dates.
>  For several releases they never changed from 1.10, and with the latest
> release, they're back to 1.00.
>  Since this is how URW++ release them to us, there's not a huge amount we
> can do."

That makes sense.

> * and as you can see above, they also changed the name from 'urw-fonts' to
> 'urw-base35' because of this

I also found this:
http://git.ghostscript.com/?p=urw-core35-fonts.git;a=summary
and they're called urw-core35-fonts here. It might be wise to ask
upstream to clarify before choosing the new package name.

> As you can see, the versioning of urw-fonts is total mess right now, and I
> would like to bring back some order to it, but I don't want it to backfire
> on me because of how URW++ tends to version their fonts... Here's my
> proposed solution to this:
> - create a new package for urw-fonts which would obsolete the current
> urw-fonts
> - choose a similar name to the new package - 'urw-base35-fonts' or similar

Good idea, but see above.

> And either...
> 1) stick to URW++ based versioning - this would mean (at the moment)
> Version == 1.0 and adding snapshot == 20160926
>   (MMDD as described in
> https://fedoraproject.org/wiki/Packaging:Versioning#Snapshot_packages)

I'm not sure where your Version == 1.0 comes from. If they're versioned
only by date now, then you have two options. Use Version: 0 in the new
package in anticipation of upstream eventually reintroducing semantic
versioning. Or, Version: MMDD. Admittedly, the latter looks nicer
and upstream already said they'll stick to it.

> 2) or map the X.Y.Z versioning to MMDD from upstream - IOW - X == Year,
> Y == Month, Z == Day (based on the snapshot date in the name of the source
> archive)
> 3) or set the Version to some constant (35 for example) and just use the
> snapshot to distinguish between older and newer releases.

What does the number "35" mean here, anyway?

> I am affraid that I would pick option 1) it could pose problems in the
> future again, because there's not guarantee that URW++ will follow sane
> versioning. So, personally, I would choose 2) or 3).

If you worry about upstream versioning sanity, then stick with
Version: 0
and follow the snapshot versioning guidelines.

> There's also one more option, and that is to base the package on upstream's
> git repository and the snapshot scheme, because we would be using snapshot
> string in the package name anyway. And it would also solve one more issue
> that upstream is not shipping license files in the archive. (I have already
> contacted to correct this.)

The exact location of the source doesn't matter too much as long as it's
official and pristine. I agree it might be better to use the git repo
directly since it contains both the licence indication and its full
text.

I hope the above helps. You might want to review the current font
packaging guidelines as well:
https://fedoraproject.org/wiki/Packaging:FontsPolicy .

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

urw-fonts: Versioning Mess

[David Kaspar [Dee'Kej]]

Hello guys,

I took over the maintenance of urw-fonts to update them to the latest
version (ghostscript and other packages needs them). However, there are
several problems in versioning of it, and I would like to discuss future
steps for the package.

The current problems:
* our urw-fonts are kind of old (~2 years), and ghostscript is unable to
build without latest version correctly
 (unless I patch it, and it would still cause ghostscript crashes for some
instances AFAIK)

* according to git log the urw-fonts in Fedora should be based on version
1.10, but the source code archive indicates version 1.07 pre-release
 (1.06 in fact, if we check the source code)

* the NVR of urw-fonts does not correlate to this at all -
urw-fonts-2.4-22.fc24.noarch

* we obtain the source archive from Artifex (aka upstream responsible for
ghostscript), nowadays they are no longer using the X.Y.Z versioning
system. Instead, they have created a separate git repository for it, and
are doing "snapshot based" releases... Their latest release is:
urw-base35-20160926.zip

* I asked them if they could go back to X.Y.Z versioning system, here's
what Chris Liddell replied:

"If you check the versions in the font files, you'll see why I switched to
the release dates.
 For several releases they never changed from 1.10, and with the latest
release, they're back to 1.00.
 Since this is how URW++ release them to us, there's not a huge amount we
can do."

* and as you can see above, they also changed the name from 'urw-fonts' to
'urw-base35' because of this

As you can see, the versioning of urw-fonts is total mess right now, and I
would like to bring back some order to it, but I don't want it to backfire
on me because of how URW++ tends to version their fonts... Here's my
proposed solution to this:
- create a new package for urw-fonts which would obsolete the current
urw-fonts
- choose a similar name to the new package - 'urw-base35-fonts' or similar

And either...
1) stick to URW++ based versioning - this would mean (at the moment)
Version == 1.0 and adding snapshot == 20160926
  (MMDD as described in
https://fedoraproject.org/wiki/Packaging:Versioning#Snapshot_packages)
2) or map the X.Y.Z versioning to MMDD from upstream - IOW - X == Year,
Y == Month, Z == Day (based on the snapshot date in the name of the source
archive)
3) or set the Version to some constant (35 for example) and just use the
snapshot to distinguish between older and newer releases.

I am affraid that I would pick option 1) it could pose problems in the
future again, because there's not guarantee that URW++ will follow sane
versioning. So, personally, I would choose 2) or 3).

There's also one more option, and that is to base the package on upstream's
git repository and the snapshot scheme, because we would be using snapshot
string in the package name anyway. And it would also solve one more issue
that upstream is not shipping license files in the archive. (I have already
contacted to correct this.)

What are you thoughts, guys? Anyone has a better idea how to solve this
mess? Or which option would you recommend?

Thank you in advance for all your ideas.

Best regards,

David Kaspar [Dee'Kej]
*Associate Software Engineer*
*Brno, Czech Republic*

RED HAT | TRIED. TESTED. TRUSTED.
Every airline in the Fortune 500 relies on Red Hat.
Find out why at Trusted | Red Hat .
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org