Re: Fedora 31 Mass Rebuild
by Petr Pisar
On 2019-07-23, Mohan Boddu <mboddu(a)bhujji.com> wrote:
> --===============2842249291292134861==
> Content-Type: multipart/alternative; boundary="000000000000614583058e5d7a59"
>
> --000000000000614583058e5d7a59
> Content-Type: text/plain; charset="UTF-8"
>
> Hi all,
>
> Per the Fedora 31 schedule[1] we will be starting a mass rebuild for Fedora
> 31 tomorrow. We are doing a mass rebuild for Fedora 31 for all the changes
> listed in
>
> https://pagure.io/releng/issue/8555
>
> we will start the mass rebuild on 2019-07-23
>
> This is a heads up that it will be done in a side tag and moved over
> when completed. We will be running scripts to output failure stats.
> please be sure to let releng know if you see any bugs in the reporting.
>
> You can contact releng in #fedora-releng on freenode.
>
> Failures can be seen
>
> https://kojipkgs.fedoraproject.org/mass-rebuild/f31-failures.html
>
> Things still needing rebuilt
>
> https://kojipkgs.fedoraproject.org/mass-rebuild/f31-need-rebuild.html
>
> [1] https://fedoraproject.org/wiki/Releases/31/Schedule
>
> Regards,
> Mohan Boddu
>
> --000000000000614583058e5d7a59
> Content-Type: text/html; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
>
><div dir=3D"ltr">Hi all,<br><br>Per the Fedora 31 schedule[1] we will be st=
> arting a mass rebuild for Fedora 31 tomorrow. We are doing a mass rebuild f=
> or Fedora 31 for all the changes listed in<br><br><a href=3D"https://pagure=
> .io/releng/issue/8555">https://pagure.io/releng/issue/8555</a><br><br>we wi=
> ll start the mass rebuild on 2019-07-23<br><br>This is a heads up that it w=
> ill be done in a side tag and moved over<br>when completed. We will be runn=
> ing scripts to output failure stats.<br>please be sure to let releng know i=
> f you see any bugs in the reporting.<br><br>You can contact releng in #fedo=
> ra-releng on freenode.<br><br>Failures can be seen <br><br><a href=3D"https=
>://kojipkgs.fedoraproject.org/mass-rebuild/f31-failures.html">https://kojip=
> kgs.fedoraproject.org/mass-rebuild/f31-failures.html</a><br><br>Things stil=
> l needing rebuilt <br><br><a href=3D"https://kojipkgs.fedoraproject.org/mas=
> s-rebuild/f31-need-rebuild.html">https://kojipkgs.fedoraproject.org/mass-re=
> build/f31-need-rebuild.html</a><div><br></div><div>[1]=C2=A0<a href=3D"http=
> s://fedoraproject.org/wiki/Releases/31/Schedule">https://fedoraproject.org/=
> wiki/Releases/31/Schedule</a><br><br>Regards,<br><div>Mohan Boddu</div></di=
> v></div>
>
> --000000000000614583058e5d7a59--
>
> --===============2842249291292134861==
> Content-Type: text/plain; charset="utf-8"
> MIME-Version: 1.0
> Content-Transfer-Encoding: base64
> Content-Disposition: inline
>
> X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZGV2ZWwtYW5u
> b3VuY2UgbWFpbGluZyBsaXN0IC0tIGRldmVsLWFubm91bmNlQGxpc3RzLmZlZG9yYXByb2plY3Qu
> b3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwgdG8gZGV2ZWwtYW5ub3VuY2UtbGVhdmVA
> bGlzdHMuZmVkb3JhcHJvamVjdC5vcmcKRmVkb3JhIENvZGUgb2YgQ29uZHVjdDogaHR0cHM6Ly9k
> b2NzLmZlZG9yYXByb2plY3Qub3JnL2VuLVVTL3Byb2plY3QvY29kZS1vZi1jb25kdWN0LwpMaXN0
> IEd1aWRlbGluZXM6IGh0dHBzOi8vZmVkb3JhcHJvamVjdC5vcmcvd2lraS9NYWlsaW5nX2xpc3Rf
> Z3VpZGVsaW5lcwpMaXN0IEFyY2hpdmVzOiBodHRwczovL2xpc3RzLmZlZG9yYXByb2plY3Qub3Jn
> L2FyY2hpdmVzL2xpc3QvZGV2ZWwtYW5ub3VuY2VAbGlzdHMuZmVkb3JhcHJvamVjdC5vcmcK
>
> --===============2842249291292134861==
> Content-Type: text/plain; charset="utf-8"
> MIME-Version: 1.0
> Content-Transfer-Encoding: base64
> Content-Disposition: inline
>
> X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZGV2ZWwgbWFp
> bGluZyBsaXN0IC0tIGRldmVsQGxpc3RzLmZlZG9yYXByb2plY3Qub3JnClRvIHVuc3Vic2NyaWJl
> IHNlbmQgYW4gZW1haWwgdG8gZGV2ZWwtbGVhdmVAbGlzdHMuZmVkb3JhcHJvamVjdC5vcmcKRmVk
> b3JhIENvZGUgb2YgQ29uZHVjdDogaHR0cHM6Ly9kb2NzLmZlZG9yYXByb2plY3Qub3JnL2VuLVVT
> L3Byb2plY3QvY29kZS1vZi1jb25kdWN0LwpMaXN0IEd1aWRlbGluZXM6IGh0dHBzOi8vZmVkb3Jh
> cHJvamVjdC5vcmcvd2lraS9NYWlsaW5nX2xpc3RfZ3VpZGVsaW5lcwpMaXN0IEFyY2hpdmVzOiBo
> dHRwczovL2xpc3RzLmZlZG9yYXByb2plY3Qub3JnL2FyY2hpdmVzL2xpc3QvZGV2ZWxAbGlzdHMu
> ZmVkb3JhcHJvamVjdC5vcmcK
>
> --===============2842249291292134861==--
>
4 years, 10 months
Package nagstamon seems unmaintained / non-responsive maintainer
by Raphael Groner
Hi,
does anyone know how to reach out for the maintainer of nagstamon? There's a FTBFS bug [1] since ages without any response so far.
It would be bad to see this useful package go away from Fedora.
Regards, Raphael
[25.07.19 07:23] <RaphGro> whoowns nagstamon
[25.07.19 07:23] <zodbot> owner: jaur; admin: echevemaster
[25.07.19 07:23] <RaphGro> fasinfo jaur
[25.07.19 07:23] <zodbot> User: jaur, Name: Nikita Klimov, email: nk(at)jaur.su, Creation: 2013-03-26, IRC Nick: , Timezone: Europe/Moscow, Locale: en, GPG key ID: , Status: active
[25.07.19 07:23] <zodbot> Approved Groups: cla_fpca cla_done packager fedorabugs
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1675438
4 years, 10 months
[RFC] target font model on Freedesktop systems
by Nicolas Mailhot
Hi,
Now that things are starting to move fonts-side[1], I’d like the various
actors to agree on a common font model target.
Without a a common target, we’ll end up working at odds with one
another. Upstream font files can not serve as a an officious target.
They are full of quirks, you end up with a different model per file-set.
My understanding of the state of the art is that OpenType is now
hegemonic. So it’s useless to target anything not specified in OpenType
specs. The latest OpenType enhancement is variable fonts.
Therefore, I’d like to propose that the target font model on freedesktop
systems, is the functional unit defined in variable fonts[2]:
> Things, that share a common design, and vary only in
> — Optical size
> — Slant (Italic axis is some weird legacy way to specify Slant in
> another way)
> — Width
> — Weight
That’s pretty much the same thing as WWS fonts as OpenType defined them
10 years ago, with optical size added. Add optical size is not intended
to be exposed in font selectors, it’s supposed to be auto-applied by
apps at need. I hoped we could ignore it at first, but we already have
things like PT Sans caption in Fedora.
Practical consequences of agreeing on a common model:
1. the unit of deployment (in rpm packages and software catalogs)
becomes all the files contributing to such an ideal font[4]
2. fontconfig strives to hide all the legacy ways to designate different
parts of this ideal font, and strives to expose a single "font" objet no
matter what quirks exist in individual font files. We stop exposing lots
of weird quirky bits right and left, that need manual assembling by
users, or glue-ing with TEX macros.
No foo variable, foo hebrew, foo narrow, foo caption, just a single foo
with different available features (full variability or fixed states on
the default axis, real upstream provided states or fakes generated by
fontconfig at pango’s request[5], etc)
3. the API between fontconfig and pango manipulates this kind of unit
4. the thing that end up in font selectors is also this unit.
Is this something we can agree on?
If we continue to special-case complex fonts like Noto, and bolt on
features without any form of master plan, I fear we’ll never get
anywhere.
If the agreement exists, can it be traced in a short fontconfig
document, that serves as coordinating references?
Regards,
[1] https://fedoraproject.org/wiki/Changes/VariableNotoFonts
[2]
https://developer.microsoft.com/en-us/microsoft-edge/testdrive/demos/vari...
https://docs.microsoft.com/en-us/typography/opentype/spec/dvaraxisreg
[4]
https://pagure.io/fork/nim/packaging-committee/commits/fonts-rpm-macros
https://pagure.io/fork/nim/fonts-rpm-macros
https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros/builds/
https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros-noreg/builds/
[5]
https://lists.freedesktop.org/archives/fontconfig/2019-June/006546.html
--
Nicolas Mailhot
4 years, 10 months
Self Introduction: Dee'Kej (looking for sponsor)
by David Kašpar
Hello,
my name is David Kaspar (a.k.a. Dee'Kej), and I used to be a package
maintainer as a Red Hat employee for 3.5 years. Now that I'm no longer part
of Red Hat I can't use my old Red Hat associated accounts to help with the
work on Fedora...
Therefore I have restored my old 'deekej' FAS account, and I'm currently
looking for a sponsorship for packagers group here, because right now I
don't have any new package I would like to add into Fedora (to set a
blocker to FE-NEEDSPONSOR BZ). I hope my previous contributions &
experience will be enough for someone to grant it. :)
I used to maintain these packages:
* initscripts
* ghostscript (+ libijs, urw-base35-fonts, ...)
* gawk
* tcsh
With kind regards,
Dee'Kej
4 years, 10 months
Re: [Fontconfig] [RFC] target font model on Freedesktop systems
by Nicolas Mailhot
Le 2019-07-24 13:49, Akira TAGOH a écrit :
Hi Akira
> On Tue, Jul 23, 2019 at 10:45 PM Nicolas Mailhot
> <nicolas.mailhot(a)laposte.net> wrote:
>> No foo variable, foo hebrew, foo narrow, foo caption, just a single
>> foo
>> with different available features (full variability or fixed states on
>> the default axis, real upstream provided states or fakes generated by
>> fontconfig at pango’s request[5], etc)
>
> Such family name issue should be more likely a font issue. it could be
> worked around but there are a lot of patterns to drop such things
> heuristically and that may be huge costs to be automated; well, that
> may depends what the level of support you expect on it.
> Having something more or less would be useful though, I hope some
> moves happens in fonts side for that too.
I've given up on font creators cleaning up their mess. Microsoft and
Adobe have been trying for a decade to get them to adopt common
conventions, and they continue not fixing old projects, and diverging
randomly on new projects. Each font tooling author and each font creator
thinks he knows best.
If we agree that this OpenType theorical definition is our target to
enable freedesktop apps to do interesting text things, the logical
consequence is to perform naming fixing at the fontconfig level (and
make sure text libs like Pango do not re-expose accidentally the
upstream broken naming to apps).
Fixing at the fontconfig level means lots of naming heuristics (that
you've started working on thank you very much). But, an heuristic is not
a 100% solution by definition. So we’ll also need you help to define the
fontconfig grammar, to tell fontconfig things, it can not guess alone.
This is also linked to Peng Wu’s request for an API to tell fontconfig
what faces to fake using variable font axis. Because:
– such faking needs to persist on disk to be convenient
— the persisting needs to be done fontconfig-side, otherwise the faked
faces are not shared with apps that do not use pango
— the next logical step is to preset convenient faked faces directly in
the font package, so you don't need to redo-them in a GUI on all the
computers one uses
So what Peng Wu sees as a fontconfig API need, I see as a fontconfig
config file need.
Also, once variable fonts become more common, I'm sure everyone will get
sick of faking the same font faces in all variable fonts, so someone is
bound to ask for a generic fontconfig heuristic, that takes available
axes, and auto-segment them at useful points (probably, using all the
segmentation levels defined by Microsoft in the WWS whitepaper)
That’s why I’m requesting a formal agreement on the target. Lots of
things become evident and easy to plan once the exit point is known.
And, it will probably take years to get there (getting everyone on
harfbuzz was defined as a target in the 2006 text summit IIRC, we’re
finishing it now) but at least we’ll be all pushing in the same
direction.
Regards,
--
Nicolas Mailhot
4 years, 10 months
