Fedora 28-20180316.n.1 compose check report
No missing expected images. Failed openQA tests: 14/137 (x86_64), 5/23 (i386), 1/2 (arm) ID: 206139 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller URL: https://openqa.fedoraproject.org/tests/206139 ID: 206145 Test: x86_64 Server-dvd-iso server_role_deploy_database_server URL: https://openqa.fedoraproject.org/tests/206145 ID: 206176 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/206176 ID: 206177 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/206177 ID: 206178 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/206178 ID: 206179 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/206179 ID: 206191 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/206191 ID: 206195 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/206195 ID: 206196 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/206196 ID: 206197 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_no_user URL: https://openqa.fedoraproject.org/tests/206197 ID: 206210 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/206210 ID: 206244 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/206244 ID: 206257 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/206257 ID: 206262 Test: x86_64 universal install_btrfs URL: https://openqa.fedoraproject.org/tests/206262 ID: 206263 Test: x86_64 universal install_xfs URL: https://openqa.fedoraproject.org/tests/206263 ID: 206268 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/206268 ID: 206283 Test: i386 universal install_simple_encrypted URL: https://openqa.fedoraproject.org/tests/206283 ID: 206291 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/206291 ID: 206292 Test: i386 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/206292 ID: 206314 Test: x86_64 KDE-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/206314 Soft failed openQA tests: 64/137 (x86_64), 15/23 (i386) (Tests completed, but using a workaround for a known bug) ID: 206134 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/206134 ID: 206135 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/206135 ID: 206137 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/206137 ID: 206138 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/206138 ID: 206151 Test: x86_64 Server-dvd-iso install_updates_nfs URL: https://openqa.fedoraproject.org/tests/206151 ID: 206154 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/206154 ID: 206155 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/206155 ID: 206171 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/206171 ID: 206174 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/206174 ID: 206193 Test: x86_64 AtomicHost-dvd_ostree-iso install_default URL: https://openqa.fedoraproject.org/tests/206193 ID: 206194 Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/206194 ID: 206204 Test: x86_64 universal install_shrink_ext4 URL: https://openqa.fedoraproject.org/tests/206204 ID: 206205 Test: x86_64 universal install_shrink_ntfs URL: https://openqa.fedoraproject.org/tests/206205 ID: 206206 Test: x86_64 universal install_blivet_xfs URL: https://openqa.fedoraproject.org/tests/206206 ID: 206207 Test: x86_64 universal install_blivet_software_raid URL: https://openqa.fedoraproject.org/tests/206207 ID: 206208 Test: x86_64 universal install_blivet_lvmthin URL: https://openqa.fedoraproject.org/tests/206208 ID: 206211 Test: x86_64 universal install_blivet_ext3@uefi URL: https://openqa.fedoraproject.org/tests/206211 ID: 206212 Test: x86_64 universal install_blivet_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/206212 ID: 206213 Test: x86_64 universal install_blivet_lvmthin@uefi URL: https://openqa.fedoraproject.org/tests/206213 ID: 206214 Test: x86_64 universal install_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/206214 ID: 206215 Test: x86_64 universal install_delete_partial@uefi URL: htt
Fedora Rawhide-20180316.n.1 compose check report
No missing expected images. Failed openQA tests: 17/137 (x86_64), 5/23 (i386), 1/2 (arm) ID: 205977 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller URL: https://openqa.fedoraproject.org/tests/205977 ID: 205983 Test: x86_64 Server-dvd-iso server_role_deploy_database_server URL: https://openqa.fedoraproject.org/tests/205983 ID: 206006 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/206006 ID: 206011 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/206011 ID: 206014 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/206014 ID: 206015 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/206015 ID: 206016 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/206016 ID: 206021 Test: x86_64 KDE-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/206021 ID: 206029 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/206029 ID: 206033 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/206033 ID: 206034 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/206034 ID: 206035 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_no_user URL: https://openqa.fedoraproject.org/tests/206035 ID: 206075 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/206075 ID: 206076 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/206076 ID: 206082 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/206082 ID: 206083 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/206083 ID: 206086 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/206086 ID: 206087 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/206087 ID: 206095 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/206095 ID: 206109 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/206109 ID: 206121 Test: i386 universal install_simple_encrypted URL: https://openqa.fedoraproject.org/tests/206121 ID: 206129 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/206129 ID: 206130 Test: i386 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/206130 Soft failed openQA tests: 9/137 (x86_64), 4/23 (i386) (Tests completed, but using a workaround for a known bug) ID: 205992 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/205992 ID: 205993 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/205993 ID: 205998 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/205998 ID: 205999 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/205999 ID: 206009 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/206009 ID: 206012 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/206012 ID: 206013 Test: i386 Workstation-live-iso install_default URL: https://openqa.fedoraproject.org/tests/206013 ID: 206017 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/206017 ID: 206018 Test: x86_64 KDE-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/206018 ID: 206058 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/206058 ID: 206085 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/206085 ID: 206113 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/206113 ID: 206128 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/206128 Passed openQA tests: 101/137 (x86_64), 14/23 (i386) Skipped openQA tests: 9 of 162 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 28 compose report: 20180316.n.1 changes
OLD: Fedora-28-20180316.n.0 NEW: Fedora-28-20180316.n.1 = SUMMARY = Added images:1 Dropped images: 0 Added packages: 1 Dropped packages:0 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 121.15 MiB Size of dropped packages:0 B Size of upgraded packages: 0 B Size of downgraded packages: 0 B Size change of upgraded packages: 0 B Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Jam_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Jam_KDE-Live-x86_64-28-20180316.n.1.iso = DROPPED IMAGES = = ADDED PACKAGES = Package: nodejs-1:8.9.4-3.fc28 Summary: JavaScript runtime RPMs:nodejs nodejs-devel nodejs-docs npm Size:121.15 MiB = DROPPED PACKAGES = = UPGRADED PACKAGES = = DOWNGRADED PACKAGES = ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Goodbye nvr.rsplit('-', 2), hello modularity
El vie, 16-03-2018 a las 15:19 -0700, Adam Williamson escribió: > On Fri, 2018-03-16 at 16:04 -0400, Dennis Gregorovic wrote: > > modules are not RPMs. I would not expect them to necessarily use > > the same > > format as RPMs. If we take koji out of the equation, > > That's an extremely big and invalid 'if', though. koji is mirroring rpm's behaviour, the if would have to be if you took rpm out of the equation. Dennis signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Review swaps
On vendredi 16 mars 2018 22:33:42 CET Jared K. Smith wrote: > On Fri, Mar 16, 2018 at 12:53 PM, Robert-André Mauchin > > wrote: > > I'm looking for some help to review some Golang packages. These are all > > renamed packages to conform with the new Golang guidelines which > > standardizes package names. These are super simple devel only package and > > shouldn't pose any issue. > > I've done about half of these, and will try to get to the rest of them by > early next week. > > -- > Jared Smith Thank you! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Link error in F28 (but not Rawhide)
Sérgio Basto wrote: > Who still use cds ? , one pen usb do the work much better ... I used them until the images stopped fitting, but that was not really the point. I used CD size as a tangible unit to measure things in. If you prefer straightforward abstract units: F17: 0.7 GiB, F27: 1.5 GiB, F28: 1.9 GiB. And the CD size limit was a convenient physical barrier that could be held against people trying to add more and more bloat to all our images. Once that barrier was declared irrelevant, that became the excuse to add new distrowide bloat at every release because there is no hardware limit anyway. (If that continues, we will be hitting the DVD size limit soon, but I guess at that point the responsible will simply declare DVDs "obsolete" as well.) Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora rawhide compose report: 20180316.n.1 changes
OLD: Fedora-Rawhide-20180316.n.0 NEW: Fedora-Rawhide-20180316.n.1 = SUMMARY = Added images:1 Dropped images: 2 Added packages: 1 Dropped packages:0 Upgraded packages: 49 Downgraded packages: 1 Size of added packages: 91.26 MiB Size of dropped packages:0 B Size of upgraded packages: 786.51 MiB Size of downgraded packages: 296.17 KiB Size change of upgraded packages: -2.04 MiB Size change of downgraded packages: 210 B = ADDED IMAGES = Image: Container_Minimal_Base docker s390x Path: Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20180316.n.1.s390x.tar.xz = DROPPED IMAGES = Image: KDE live i386 Path: Spins/i386/iso/Fedora-KDE-Live-i386-Rawhide-20180316.n.0.iso Image: Minimal raw-xz aarch64 Path: Spins/aarch64/images/Fedora-Minimal-Rawhide-20180316.n.0.aarch64.raw.xz = ADDED PACKAGES = Package: utop-2.1.0-1.fc29 Summary: Improved toplevel for OCaml RPMs:utop utop-devel Size:91.26 MiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: ExchangeIR-0.0.8.2-8.fc29 Old package: ExchangeIR-0.0.8.2-4.fc24 Summary: Java infrared signals analysis and conversion library RPMs: ExchangeIR ExchangeIR-javadoc Size: 89.74 KiB Size change: 2.23 KiB Changelog: * Fri Feb 10 2017 Fedora Release Engineering - 0.0.8.2-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild * Wed Jul 26 2017 Fedora Release Engineering - 0.0.8.2-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild * Wed Feb 07 2018 Fedora Release Engineering - 0.0.8.2-7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild * Fri Mar 16 2018 Alec Leamas - 0.0.8.2-8 - Fix maven-assembly plugin configuration syntax change. - Fix missing BR: after maven-local split. Package: apache-ivy-2.4.0-11.fc29 Old package: apache-ivy-2.4.0-10.fc28 Summary: Java-based dependency manager RPMs: apache-ivy apache-ivy-javadoc Size: 1.77 MiB Size change: 696 B Changelog: * Fri Mar 16 2018 Michael Simacek - 2.4.0-11 - Fix build against ant 1.10.2 Package: archivemount-0.8.10-1.fc29 Old package: archivemount-0.8.9-1.fc29 Summary: FUSE based filesystem for mounting compressed archives RPMs: archivemount Size: 316.04 KiB Size change: 2.41 KiB Changelog: * Fri Mar 16 2018 Niels de Vos - 0.8.10-1 - Update to version 0.8.10 (#1557308) Package: atoum-3.3.0-1.fc29 Old package: atoum-3.2.0-2.fc28 Summary: PHP Unit Testing framework RPMs: atoum Size: 420.68 KiB Size change: 2.91 KiB Changelog: * Fri Mar 16 2018 Remi Collet - 3.3.0-1 - update to 3.3.0 - undefine __brp_mangle_shebangs Package: atril-1.20.0-2.fc29 Old package: atril-1.20.0-1.fc28 Summary: Document viewer RPMs: atril atril-caja atril-devel atril-libs atril-thumbnailer Size: 11.11 MiB Size change: 10.22 KiB Changelog: * Fri Mar 16 2018 Wolfgang Ulbrich - 1.20.0-2 - fix for rhbz (#1554134) Package: brltty-5.6-7.fc29 Old package: brltty-5.6-2.fc28 Summary: Braille display driver for Linux/Unix RPMs: brlapi brlapi-devel brlapi-java brltty brltty-at-spi2 brltty-docs brltty-espeak brltty-espeak-ng brltty-speech-dispatcher brltty-xw ocaml-brlapi python3-brlapi tcl-brlapi Added RPMs: brltty-espeak-ng Dropped RPMs: python2-brlapi Size: 15.32 MiB Size change: -313.68 KiB Changelog: * Mon Feb 26 2018 Ond??ej Lyson??k - 5.6-3 - Fix generating the brltty-debugsource package * Tue Mar 06 2018 Ond??ej Lyson??k - 5.6-4 - Fix the License tags. The license of whole brltty is LGPLv2+ since the 5.6 release. * Tue Mar 06 2018 Ond??ej Lyson??k - 5.6-5 - Add support for eSpeak-NG * Thu Mar 08 2018 Ond??ej Lyson??k - 5.6-6 - Build with espeak support only on Fedora * Fri Mar 16 2018 Miro Hron??ok - 5.6-7 - Don't build Python 2 subpackage on EL > 7 and Fedora > 28 - Use bconditionals Package: cinnamon-3.6.8-0.6.20180316git45339e8.fc29 Old package: cinnamon-3.6.8-0.4.20180309gitd4679f7.fc29 Summary: Window management and application launching for GNOME RPMs: cinnamon cinnamon-devel-doc Size: 12.21 MiB Size change: -1.23 MiB Changelog: * Fri Mar 16 2018 Leigh Scott - 3.6.8-0.5.20180316gitd7e0764 - update to git snapshot * Fri Mar 16 2018 Leigh Scott - 3.6.8-0.6.20180316git45339e8 - update to git snapshot Package: cri-o-2:1.10.0-1.beta.1.gitc956614.fc29 Old package: cri-o-2:1.9.10-1.git8723732.fc29 Summary: CRI-O is the Kubernetes Container Runtime Interface for OCI-based containers RPMs: conmon cri-o cri-o-integration-tests Size: 71.58 MiB Size change: -1.80 MiB Changelog: * Fri Mar 16 2018 Dan Walsh - 2:1.10.0-beta.1 - bump to v1.10.0-beta.1 Package: cryptobone-1.1.2-3.fc29 Old package: cryptobone-1.1.2-1.fc28 Summary: Secure Communic
Re: Goodbye nvr.rsplit('-', 2), hello modularity
Don't be afraid of koji. :) It is under active development. Of course, resources are limited and not everything can be taken on, but it's worth having the discussion. I have filed https://pagure.io/koji/issue/851 as a strawman and will try to solicit feedback on the idea. Patrick, if https://pagure.io/koji/issue/851 was implemented would that resolve the challenge you were facing? If not, it might be worth reaching out to koji-de...@lists.fedorahosted.org and discussing it further there. Cheers -- Dennis On Fri, Mar 16, 2018 at 6:21 PM, Adam Williamson wrote: > On Fri, 2018-03-16 at 16:14 -0400, Randy Barlow wrote: > > > > > If that means > > > tweaking the Koji UI we can look into that. > > > > For my concerns, it would be more helpful to tweak the Koji API than the > > UI, so that tools that interact with Koji (like Bodhi) don't have to > > know that Modules are different in Koji than they are everywhere else. > > Of course, I'd rather just having modules not use -'s in stream names as > > I wrote above, but if we really are going that route it'd be ideal if we > > used :'s everywhere, including Koji. > > Thanks, that's what I was trying to get at. The problem is that Koji is > very big and very hairy and no-one enjoys poking it much. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > -- Dennis Gregorovic Manager, PnT DevOps Red Hat dgre...@redhat.comT: +1-978.392.3112M: +1-617.901.9799 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Use Noto Sans UI for Cantarell fallback in Workstation?
On Fri, 2018-03-16 at 23:31 +, Nikolaus Waxweiler wrote: > > DejaVu had already proven at that time fontforge was more than good enough > > for a complex modern font. > > In the sense that you can write a complex application in assembler, yes. With > an assembler full of quirks and bugs. I have used Fontforge, I know why I ran > from it and why people have been payed to improve it and not gotten far. > > > That's what the ”professional” mindview gets you: dead projects with no > > live community > > DejaVu is clearly alive to prove your point. How about this: font > design is different from software development and _not_ the forté of > the open source community. The subpar open-source tooling to work on > these things certainly has not helped. The Ubuntu font was maybe just > good enough for most people. It's kind of ironic that this flies in the face of one of the initial justifications for Cantarell, though: https://thegnomejournal.wordpress.com/2011/04/06/fonts-in-gnome-3-cantarell-tweaking-and-trailblazing/ Interesting quotes from that article: "The commissioning approach to fonts involves a proprietary foundry developing a font family in-house, and then transferring it to a community who will maintain it with a different toolkit and methodology. A fully libre software project approach, in contrast, develops fonts with a FLOSS toolkit on a FLOSS desktop from the start, and hosts and maintains them like other modules in the community’s infrastructure. (In GNOME’s case, those comparable modules would include git, Bugzilla, the wiki, etc.) GNOME is blazing a brand new trail in moving from the commissioning approach towards a libre approach. Jakub “Jimmac” Steiner, designer extraordinaire and core LGM contributor from the earlier days, now also committer to Dave Crossland’s project, had already designed open fonts of his own. He indicated in his blog that the methodology used by Dave Crossland was more in tune with GNOME’s culture and made much more sense in the long- term. They are many challenges ahead but these are interesting times." "Who will be the first to take advantage of the flexibility of the gnome-shell to write extensions specifically tuned to advanced fonts capabilities? Will fonts be the focus of GSOC work as well? Will gnome-tweak-tool be extended to expose more font-related capabilities for the advanced typophile or designer using GNOME? Will some inspiration come fromfontmatrix ? Is a revamping of the font menu widget still planned? Will officially supporting a new language in GNOME include making sure the needed glyphs and behaviors are validated in the official GNOME UI font family? Will the upcoming Desktop Summit—held in Berlin, Germany, a city renowned for the high concentration of typographers and typophiles—push the envelope even further? Will other desktops using freedesktop.org open standards also embark on the project of picking and maintaining their own dedicated visual identity in the shape of an open font? Maybe just in the lettering of their logo?" "Why not pick up fontforge and the rest of the open font design toolkit, learn its formidable feature set and start playing with your own branch of the Cantarell sources? Contributing to making it work perfectly in your own language? Contributing to weight variations? Adding advanced typographic features and smart behaviors? Joining an open font design workshop in your corner of the world? Have fun and happy open font hacking!" It seems like at least the *pitch* was that a large part of Cantarell's justification was "it's going to be a great collaborative open source project that will get lots of contributions for other scripts and stuff, plus it's developed in a more open way than other 'open' fonts". Did either of those really happen in practice? Is either of them likely to in future? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Link error in F28 (but not Rawhide)
On Fri, 2018-03-16 at 23:25 +, Sérgio Basto wrote: > On Sat, 2018-03-17 at 00:06 +0100, Kevin Kofler wrote: > > Sérgio Basto wrote: > > > https://fedoraproject.org/wiki/Changes/Annobin > > > > I have read that page. There is not a single compelling reason > > warranting > > the global size increase across the whole distribution nor the > > recurring > > breakage from annobin bugs (see e.g. this thread). > > > > I am really fed up of the cavalier attitude towards the creepy size > > inflation that has been plaguing us all the time. All those small or > > not-so- > > small size increases (MiniDebugInfo, Annobin, but also lots of small > > local > > size increases in all packages) add up to a huge bloat. > > > > The Fedora 17 KDE Spin fit on a CD. Only 10 releases (≈ 5 years) > > later, the > > Fedora 27 KDE Spin is more than twice the size! And the Fedora 28 KDE > > Spin > > is again ~30% larger than the Fedora 27 one, coming close to 3 times > > CD > > size! The other spins are equally hit. This creeping biggerism needs > > to > > stop! > > I think you shouldn't be so upset, it is an error in a pre-alfa/beta > version and seems it is already fixed. Who still use cds ? , one pen > usb do the work much better ... The compile error is fixed, but the packages didn't magically get smaller. I really kinda agree with Kevin, FWIW. The images have got *significantly* bigger across the last few releases and we're just sorta shrugging and going 'ok, whatever'. I keep seeing pushes to spin- kickstarts to make image sizes bigger for no particular reason except just 'stuff bloated', that's kinda sad. It's not really about whether things fit on a CD or not, it's about not needlessly wasting bandwidth and storage space. If the packages are bigger then they take up more space on our hard disks, USB sticks, on mirrors, they take more time to transfer, and we *do* still have users on slow and bandwidth-limited connections. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: test gate failures (again)
On Friday, 09 March 2018 at 12:02, Pavel Zhukov wrote: > Hello, > Gating is failed for some weird reason: > > # Test died: command 'dnf -y install bodhi-client git createrepo koji' > failed at /var/lib/openqa/share/tests/fedora/lib/utils.pm line 383. > > https://bodhi.fedoraproject.org/updates/FEDORA-2018-fda9fed6fd > > I suppose it's known issue. Is there any way to override such false > failures? It's not needed for this particular update but waiting 6 > hours for next run is not optimal solution in case of security fixes > etc. I have another case here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-b322e211ca It was in testing for 10 days but I still couldn't push it (Tests Failed/no test results found), so I followed Kevin's advice from this thread and now I'm getting (Tests Failed/1 of 2 required tests not found). What's going on here? Regards, Dominik -- Fedora https://getfedora.org | RPMFusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Use Noto Sans UI for Cantarell fallback in Workstation?
> DejaVu had already proven at that time fontforge was more than good enough > for a complex modern font. In the sense that you can write a complex application in assembler, yes. With an assembler full of quirks and bugs. I have used Fontforge, I know why I ran from it and why people have been payed to improve it and not gotten far. > That's what the ”professional” mindview gets you: dead projects with no live > community DejaVu is clearly alive to prove your point. How about this: font design is different from software development and _not_ the forté of the open source community. The subpar open-source tooling to work on these things certainly has not helped. The Ubuntu font was maybe just good enough for most people. > so everyone understands it's your business and your business alone to improve > the font, and third parties are not welcome. I took on Cantarell and refreshing the technicalities of the Ubuntu font as a third-party and was welcomed. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Link error in F28 (but not Rawhide)
On Sat, 2018-03-17 at 00:06 +0100, Kevin Kofler wrote: > Sérgio Basto wrote: > > https://fedoraproject.org/wiki/Changes/Annobin > > I have read that page. There is not a single compelling reason > warranting > the global size increase across the whole distribution nor the > recurring > breakage from annobin bugs (see e.g. this thread). > > I am really fed up of the cavalier attitude towards the creepy size > inflation that has been plaguing us all the time. All those small or > not-so- > small size increases (MiniDebugInfo, Annobin, but also lots of small > local > size increases in all packages) add up to a huge bloat. > > The Fedora 17 KDE Spin fit on a CD. Only 10 releases (≈ 5 years) > later, the > Fedora 27 KDE Spin is more than twice the size! And the Fedora 28 KDE > Spin > is again ~30% larger than the Fedora 27 one, coming close to 3 times > CD > size! The other spins are equally hit. This creeping biggerism needs > to > stop! I think you shouldn't be so upset, it is an error in a pre-alfa/beta version and seems it is already fixed. Who still use cds ? , one pen usb do the work much better ... -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Link error in F28 (but not Rawhide)
Sérgio Basto wrote: > https://fedoraproject.org/wiki/Changes/Annobin I have read that page. There is not a single compelling reason warranting the global size increase across the whole distribution nor the recurring breakage from annobin bugs (see e.g. this thread). I am really fed up of the cavalier attitude towards the creepy size inflation that has been plaguing us all the time. All those small or not-so- small size increases (MiniDebugInfo, Annobin, but also lots of small local size increases in all packages) add up to a huge bloat. The Fedora 17 KDE Spin fit on a CD. Only 10 releases (≈ 5 years) later, the Fedora 27 KDE Spin is more than twice the size! And the Fedora 28 KDE Spin is again ~30% larger than the Fedora 27 one, coming close to 3 times CD size! The other spins are equally hit. This creeping biggerism needs to stop! Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Link error in F28 (but not Rawhide)
On Fri, 2018-03-16 at 20:09 +0100, Kevin Kofler wrote: > Adam Williamson wrote: > > I've actually seen the exact same thing in something else, I forget > > what and can't find the bug right now. I think just building with > > the > > Rawhide annobin package makes it work, so we might need an updated > > annobin for F28, or something. > > Now why is that buggy binary-bloating plugin being forced on us? > Annobin > offers no benefits whatsoever to the user, quite the opposite, > because it > bloats the whole distro. https://fedoraproject.org/wiki/Changes/Annobin -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Use Noto Sans UI for Cantarell fallback in Workstation?
Nikolaus Waxweiler wrote: > It is my upstream opinion that the entire free desktop landscape should > use Noto Sans/Serif (UI) as the default (fallback) font for everything and > not ship anything else in a base system, except DejaVu Mono because Noto > Mono has only a regular face. For the record, Noto Sans is already the default sans-serif font in upstream KDE Plasma. So if GNOME also wants to switch, we should probably just change the distrowise Sans font alias. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Goodbye nvr.rsplit('-', 2), hello modularity
On Fri, 2018-03-16 at 16:14 -0400, Randy Barlow wrote: > > > If that means > > tweaking the Koji UI we can look into that. > > For my concerns, it would be more helpful to tweak the Koji API than the > UI, so that tools that interact with Koji (like Bodhi) don't have to > know that Modules are different in Koji than they are everywhere else. > Of course, I'd rather just having modules not use -'s in stream names as > I wrote above, but if we really are going that route it'd be ideal if we > used :'s everywhere, including Koji. Thanks, that's what I was trying to get at. The problem is that Koji is very big and very hairy and no-one enjoys poking it much. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Goodbye nvr.rsplit('-', 2), hello modularity
On Fri, 2018-03-16 at 16:04 -0400, Dennis Gregorovic wrote: > modules are not RPMs. I would not expect them to necessarily use the same > format as RPMs. If we take koji out of the equation, That's an extremely big and invalid 'if', though. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Review swaps
On Fri, Mar 16, 2018 at 12:53 PM, Robert-André Mauchin wrote: > I'm looking for some help to review some Golang packages. These are all > renamed packages to conform with the new Golang guidelines which > standardizes package names. These are super simple devel only package and > shouldn't pose any issue. > I've done about half of these, and will try to get to the rest of them by early next week. -- Jared Smith ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Goodbye nvr.rsplit('-', 2), hello modularity
On Fri, Mar 16, 2018 at 4:04 PM, Dennis Gregorovic wrote: > The challenge here is that those module builds are squeezed into a N-V-R > format when imported into Koji. The N-V-R format is used for all build > types in Koji and it works well for its purpose, but it's also not > realistic to expect that all content types are going to natively use N-V-R > outside of Koji. My suggestion is that we consider the N-V-R format of > modules to be a representation internal to koji and that N:S:V:C is the > format used to represent modules to users. If that means tweaking the Koji > UI we can look into that. > There's also a terminology problem that gets less confusing with the : separator. When compared to Name-VERSION-Release.DistTag it would be fairly confusing to have: Name-Stream-VERSION.Context while: Name:Stream:VERSION:Context is slightly less confusing. of course, it might have been better to call 'Version' in a module version Build or something, but I think that ship has sailed. In the end, modules are not packages, and it's necessarily required or good if they are named in the same format. I'd also like to see Koji's representation of a module version stay inside Koji as much as possible. Owen ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 28-20180316.n.0 compose check report
No missing expected images. Failed openQA tests: 15/137 (x86_64), 5/23 (i386), 1/2 (arm) ID: 205499 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller URL: https://openqa.fedoraproject.org/tests/205499 ID: 205505 Test: x86_64 Server-dvd-iso server_role_deploy_database_server URL: https://openqa.fedoraproject.org/tests/205505 ID: 205531 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/205531 ID: 205534 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/205534 ID: 205536 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/205536 ID: 205537 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/205537 ID: 205538 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/205538 ID: 205539 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/205539 ID: 205551 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/205551 ID: 20 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/20 ID: 205556 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/205556 ID: 205557 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_no_user URL: https://openqa.fedoraproject.org/tests/205557 ID: 205570 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/205570 ID: 205577 Test: x86_64 universal install_ext3@uefi URL: https://openqa.fedoraproject.org/tests/205577 ID: 205604 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/205604 ID: 205617 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/205617 ID: 205628 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/205628 ID: 205643 Test: i386 universal install_simple_encrypted URL: https://openqa.fedoraproject.org/tests/205643 ID: 205651 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/205651 ID: 205652 Test: i386 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/205652 ID: 205693 Test: x86_64 KDE-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/205693 Soft failed openQA tests: 65/137 (x86_64), 15/23 (i386) (Tests completed, but using a workaround for a known bug) ID: 205492 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/205492 ID: 205494 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/205494 ID: 205495 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/205495 ID: 205497 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/205497 ID: 205498 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/205498 ID: 205511 Test: x86_64 Server-dvd-iso install_updates_nfs URL: https://openqa.fedoraproject.org/tests/205511 ID: 205514 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/205514 ID: 205515 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/205515 ID: 205517 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/205517 ID: 205553 Test: x86_64 AtomicHost-dvd_ostree-iso install_default URL: https://openqa.fedoraproject.org/tests/205553 ID: 205554 Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/205554 ID: 205564 Test: x86_64 universal install_shrink_ext4 URL: https://openqa.fedoraproject.org/tests/205564 ID: 205565 Test: x86_64 universal install_shrink_ntfs URL: https://openqa.fedoraproject.org/tests/205565 ID: 205566 Test: x86_64 universal install_blivet_xfs URL: https://openqa.fedoraproject.org/tests/205566 ID: 205567 Test: x86_64 universal install_blivet_software_raid URL: https://openqa.fedoraproject.org/tests/205567 ID: 205568 Test: x86_64 universal install_blivet_lvmthin URL: https://openqa.fedoraproject.org/tests/205568 ID: 205571 Test: x86_64 universal install_blivet_ext3@uefi URL: https://openqa.fedoraproject.org/tests/205571 ID: 205572 Test: x86_64 universal install_blivet_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/205572 ID: 205573 Test: x86_64 universal install_blivet_lvmthin@uefi URL: https://openqa.fedoraproject.org/tests/205573 ID: 205574 Test: x86_64 universal install_softw
Fedora Rawhide-20180316.n.0 compose check report
No missing expected images. Failed openQA tests: 36/137 (x86_64), 12/24 (i386), 1/2 (arm) New failures (same test did not fail in Rawhide-20180312.n.0): ID: 205331 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/205331 ID: 205335 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/205335 ID: 205368 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/205368 ID: 205371 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/205371 ID: 205372 Test: i386 Workstation-live-iso install_default URL: https://openqa.fedoraproject.org/tests/205372 ID: 205388 Test: i386 KDE-live-iso install_default URL: https://openqa.fedoraproject.org/tests/205388 ID: 205404 Test: x86_64 universal install_blivet_xfs URL: https://openqa.fedoraproject.org/tests/205404 ID: 205405 Test: x86_64 universal install_blivet_software_raid URL: https://openqa.fedoraproject.org/tests/205405 ID: 205406 Test: x86_64 universal install_blivet_lvmthin URL: https://openqa.fedoraproject.org/tests/205406 ID: 205409 Test: x86_64 universal install_blivet_ext3@uefi URL: https://openqa.fedoraproject.org/tests/205409 ID: 205410 Test: x86_64 universal install_blivet_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/205410 ID: 205411 Test: x86_64 universal install_blivet_lvmthin@uefi URL: https://openqa.fedoraproject.org/tests/205411 ID: 205415 Test: x86_64 universal install_ext3@uefi URL: https://openqa.fedoraproject.org/tests/205415 ID: 205441 Test: x86_64 universal install_blivet_btrfs URL: https://openqa.fedoraproject.org/tests/205441 ID: 205445 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/205445 ID: 205448 Test: x86_64 universal install_blivet_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/205448 ID: 205450 Test: x86_64 universal install_blivet_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/205450 ID: 205461 Test: x86_64 universal install_xfs URL: https://openqa.fedoraproject.org/tests/205461 ID: 205464 Test: x86_64 universal install_ext3 URL: https://openqa.fedoraproject.org/tests/205464 ID: 205467 Test: x86_64 universal install_blivet_ext3 URL: https://openqa.fedoraproject.org/tests/205467 ID: 205473 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/205473 ID: 205477 Test: i386 universal install_blivet_ext3 URL: https://openqa.fedoraproject.org/tests/205477 ID: 205478 Test: i386 universal install_blivet_btrfs URL: https://openqa.fedoraproject.org/tests/205478 ID: 205483 Test: i386 universal install_ext3 URL: https://openqa.fedoraproject.org/tests/205483 ID: 205484 Test: i386 universal install_blivet_lvmthin URL: https://openqa.fedoraproject.org/tests/205484 ID: 205488 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/205488 ID: 205774 Test: x86_64 KDE-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/205774 ID: 205793 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/205793 ID: 205794 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/205794 Old failures (same test failed in Rawhide-20180312.n.0): ID: 205373 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/205373 ID: 205374 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/205374 ID: 205389 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/205389 ID: 205393 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/205393 ID: 205394 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/205394 ID: 205395 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_no_user URL: https://openqa.fedoraproject.org/tests/205395 ID: 205416 Test: x86_64 universal install_xfs@uefi URL: https://openqa.fedoraproject.org/tests/205416 ID: 205435 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/205435 ID: 205436 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/205436 ID: 205442 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/205442 ID: 205446 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/205446 ID: 205447 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/205447 ID: 205449 Test: x86_6
Fedora Rawhide-20180315.n.1 compose check report
No missing expected images. Failed openQA tests: 83/137 (x86_64), 24/24 (i386), 1/2 (arm) ID: 205074 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/205074 ID: 205075 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/205075 ID: 205077 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/205077 ID: 205078 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/205078 ID: 205080 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/205080 ID: 205081 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/205081 ID: 205094 Test: x86_64 Server-dvd-iso install_updates_nfs URL: https://openqa.fedoraproject.org/tests/205094 ID: 205097 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/205097 ID: 205098 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/205098 ID: 205099 Test: x86_64 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/205099 ID: 205100 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/205100 ID: 205101 Test: i386 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/205101 ID: 205103 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/205103 ID: 205104 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/205104 ID: 205114 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/205114 ID: 205115 Test: x86_64 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/205115 ID: 205116 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/205116 ID: 205117 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/205117 ID: 205118 Test: i386 Workstation-live-iso install_default URL: https://openqa.fedoraproject.org/tests/205118 ID: 205119 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/205119 ID: 205120 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/205120 ID: 205121 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/205121 ID: 205122 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/205122 ID: 205123 Test: x86_64 KDE-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/205123 ID: 205126 Test: x86_64 KDE-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/205126 ID: 205134 Test: i386 KDE-live-iso install_default URL: https://openqa.fedoraproject.org/tests/205134 ID: 205135 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/205135 ID: 205137 Test: x86_64 AtomicHost-dvd_ostree-iso install_default URL: https://openqa.fedoraproject.org/tests/205137 ID: 205138 Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/205138 ID: 205139 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/205139 ID: 205140 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/205140 ID: 205141 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_no_user URL: https://openqa.fedoraproject.org/tests/205141 ID: 205148 Test: x86_64 universal install_shrink_ext4 URL: https://openqa.fedoraproject.org/tests/205148 ID: 205149 Test: x86_64 universal install_shrink_ntfs URL: https://openqa.fedoraproject.org/tests/205149 ID: 205150 Test: x86_64 universal install_blivet_xfs URL: https://openqa.fedoraproject.org/tests/205150 ID: 205151 Test: x86_64 universal install_blivet_software_raid URL: https://openqa.fedoraproject.org/tests/205151 ID: 205152 Test: x86_64 universal install_blivet_lvmthin URL: https://openqa.fedoraproject.org/tests/205152 ID: 205153 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/205153 ID: 205154 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/205154 ID: 205155 Test: x86_64 universal install_blivet_ext3@uefi URL: https://openqa.fedoraproject.org/tests/205155 ID: 205156 Test: x86_64 universal install_blivet_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/205156 ID: 205157 Test: x86_64 universal install_blivet_lvmthin@uef
Re: Use Noto Sans UI for Cantarell fallback in Workstation?
Le vendredi 16 mars 2018 à 19:47 +, Nikolaus Waxweiler a écrit : > > 2. There were no obvious ways to contribute because open-source > tooling either didn't exist or was something you didn't want to use > (Fontforge I'm looking at you) Please, don't rewrite history, DejaVu had already proven at that time fontforge was more than good enough for a complex modern font. Those projects chose font upstreams that had no interest in encouraging contributions (either because they were “professionals” or because they were overcommitted one-man operations). They didn't invest anything to make sure contributions could happen or would be welcomed. It was shameful, even granddaddy Bitsream Vera was better organised. As a result contributions died down. That's what the ”professional” mindview gets you: dead projects with no live community and no future once the contractor funds die down. Especially when you make sure to market the resulting font as an identity marker, so everyone understands it's your business and your business alone to improve the font, and third parties are not welcome. -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Goodbye nvr.rsplit('-', 2), hello modularity
On 03/16/2018 04:04 PM, Dennis Gregorovic wrote:
> modules are not RPMs. I would not expect them to necessarily use the
> same format as RPMs. If we take koji out of the equation, we have
> module builds in N:S:V:C format and module RPMs in N-V-R.A format. They
> use different separators, but both can be parsed consistently.
I don't contest the above, but I am arguing that it is needlessly
different and causes infrastructure software to need to handle module
strings differently than they handle RPMs and containers. Perhaps there
is a benefit that I've not been made aware of yet, but from where I sit
it seems like a change that causes problems without bringing a tangible
benefit.
The reasoning I've heard so far is that this allows stream names to have
-'s in them - is that important? I don't know it to be, but am open to
be convinced. Thus my question - is it important enough to have -'s in
stream names to justify the work needed to make all things that interact
with Koji parse them using a web service rather than local code (such as
rsplit('-', 2) in Python)?
> If that means
> tweaking the Koji UI we can look into that.
For my concerns, it would be more helpful to tweak the Koji API than the
UI, so that tools that interact with Koji (like Bodhi) don't have to
know that Modules are different in Koji than they are everywhere else.
Of course, I'd rather just having modules not use -'s in stream names as
I wrote above, but if we really are going that route it'd be ideal if we
used :'s everywhere, including Koji.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Goodbye nvr.rsplit('-', 2), hello modularity
modules are not RPMs. I would not expect them to necessarily use the same format as RPMs. If we take koji out of the equation, we have module builds in N:S:V:C format and module RPMs in N-V-R.A format. They use different separators, but both can be parsed consistently. The challenge here is that those module builds are squeezed into a N-V-R format when imported into Koji. The N-V-R format is used for all build types in Koji and it works well for its purpose, but it's also not realistic to expect that all content types are going to natively use N-V-R outside of Koji. My suggestion is that we consider the N-V-R format of modules to be a representation internal to koji and that N:S:V:C is the format used to represent modules to users. If that means tweaking the Koji UI we can look into that. Cheers -- Dennis On Fri, Mar 16, 2018 at 3:40 PM, Randy Barlow wrote: > On 03/16/2018 05:18 AM, Pierre-Yves Chibon wrote: > > I wonder what we can do about this. Is it FESCo material? > > Can the folks working on modularity comment more on this? > > I am considering filing it for FESCo to consider. I haven't seen a > compelling explanation for why modules are using a different separator > than our other content types so far, and it really does break a lot of > tooling. > > Koji also does not allow the :'s (so modules continue to use -'s there), > so it also causes an inconsistency in NSVC syntax for Koji and > everything else (which will be very confusing in the Bodhi UI, which > touches "everything else" as well as Koji). > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > -- Dennis Gregorovic Manager, PnT DevOps Red Hat dgre...@redhat.comT: +1-978.392.3112M: +1-617.901.9799 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Use Noto Sans UI for Cantarell fallback in Workstation?
1. Gnome and Ubuntu had good reasons: DejaVu fits the bill when you want a free Verdana for text and terminal, but the design isn't made for UI or branding. Ubuntu is significantly nicer to look at than something using DejaVu. 2. There were no obvious ways to contribute because open-source tooling either didn't exist or was something you didn't want to use (Fontforge I'm looking at you) -- the latter is why the Ubuntu font was made in a proprietary design application and only later converted to an open UFO workflow. For the longest time, the industry standard way of producing a production font binary was Adobe's closed source font development kit that got mostly open-sourced a while ago. Hinting was something you wanted to do in Microsoft's closed source VTT application instead of writing assembly in Fontforge. The UFO and designspace specification, base open-source libraries like ufoLib, defcon, ufo2ft, fonttools with all its underlying sub-libraries, etc. and tools like ttfautohint, fontmake and friends are all relatively recent developments. The font landscape is different today to what it was even just years ago. Things are getting better :) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Goodbye nvr.rsplit('-', 2), hello modularity
On 03/16/2018 05:18 AM, Pierre-Yves Chibon wrote: > I wonder what we can do about this. Is it FESCo material? > Can the folks working on modularity comment more on this? I am considering filing it for FESCo to consider. I haven't seen a compelling explanation for why modules are using a different separator than our other content types so far, and it really does break a lot of tooling. Koji also does not allow the :'s (so modules continue to use -'s there), so it also causes an inconsistency in NSVC syntax for Koji and everything else (which will be very confusing in the Bodhi UI, which touches "everything else" as well as Koji). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Link error in F28 (but not Rawhide)
On Fri, 16 Mar 2018, Sérgio Basto wrote: On Thu, 2018-03-15 at 20:47 -0400, Scott Talbert wrote: I'm seeing a strange error when building wxGTK3 on F28. This only happens on x86_64. The same package built fine on Rawhide. Anyone have any ideas what's going on here? This message [1] (70 times) is very strange and seems the root cause [1] annobin: sound_sdl.cpp: CET values have changed from 0:1954187174:20:1 to 0:100824:20:1 Thanks for noticing that. I didn't look far enough back in the log. I filed [1] against annobin in F28. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1557511 Scott___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Link error in F28 (but not Rawhide)
Adam Williamson wrote: > I've actually seen the exact same thing in something else, I forget > what and can't find the bug right now. I think just building with the > Rawhide annobin package makes it work, so we might need an updated > annobin for F28, or something. Now why is that buggy binary-bloating plugin being forced on us? Annobin offers no benefits whatsoever to the user, quite the opposite, because it bloats the whole distro. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Summary/Minutes from today's FESCo Meeting (2018-03-16)
=== #fedora-meeting: FESCO (2018-03-16) === Meeting started by jsmith at 15:01:14 UTC. The full logs are available athttps://meetbot.fedoraproject.org/fedora-meeting/2018-03-16/fesco.2018-03-16-15.01.log.html . Meeting summary --- * init process (jsmith, 15:01:14) * #1745 F28 System Wide Change: Switch OpenLDAP from NSS to OpenSSL (jsmith, 15:02:47) * LINK: https://pagure.io/fesco/issue/1745 (jsmith, 15:02:47) * AGREED: move on (jsmith, 15:03:35) * #1820 Adjust/Drop/Document batched updates policy (jsmith, 15:03:48) * LINK: https://pagure.io/fesco/issue/1820 (jsmith, 15:03:48) * ACTION: bowlofeggs will talk to QA about batching (bowlofeggs, 15:17:34) * ACTION: kalev to share his ideas on batching in the ticket (jsmith, 15:18:44) * AGREED: Continue the discussion on the mailing list and ticket this week. Try to identify concrete goals and concrete plans to get us there. (jsmith, 15:21:15) * #1853 F29 System Wide Change: Enable dbus-broker (jsmith, 15:21:33) * LINK: https://pagure.io/fesco/issue/1853 (jsmith, 15:21:33) * AGREED: (+1:7,+0:0,-1:0) Accept the dbus-broker change for F29, with the caveat that the team should coordinate with FreeIP to ensure they don't break custodia/oddjob/SSSD-info pipe stuff (jsmith, 15:31:41) * #1858 Proposed Fedora 29 schedule (jsmith, 15:31:58) * LINK: https://pagure.io/fesco/issue/1858 (jsmith, 15:31:58) * AGREED: (+1:5,+0:0,-1:1) FESCo accepts the F29 schedule. (jsmith, 15:43:06) * #1861 F28 Changes not in ON_QA status (jsmith, 15:43:44) * LINK: https://pagure.io/fesco/issue/1861 (jsmith, 15:43:44) * AGREED: (+1:6,+0:0,-1:0) Kerberos in Python modernization - ask change owner to update change with what will be shipped in f28 and file last changes in f29 change (jsmith, 15:48:30) * critera are in https://bugzilla.redhat.com/show_bug.cgi?id=1537253#c6 (zbyszek, 16:26:08) * AGREED: The critieria posted in comments 6 and 7 at https://bugzilla.redhat.com/show_bug.cgi?id=1537253 are required for modularity (+8, 0, -0) (bowlofeggs, 16:30:55) * ACTION: sgallagh will inform QA (the proposals are in the BZ already) (bowlofeggs, 16:31:25) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1537261#c5 (nirik, 16:32:37) * ACCEPTED: we let nirik work some koji magic to try get the cloud imegas done, by next week we ask that ksinny has updated the change to reflect reality and punt the rest to f29 (+8, 0, -0) (bowlofeggs, 16:41:53) * ACTION: nirik will perform wonders with koji to attempt to get cloud images done (bowlofeggs, 16:42:18) * #1862 Fedora 28 Beta status, schedule risk (bowlofeggs, 16:42:46) * AGREED: FESCo acknowledges the risk and closes the ticket (+8, 0, -0) (bowlofeggs, 16:48:12) * #1863 F29 Self Contained Change: OpenLDAP: Drop MozNSS Compatibility Layer (bowlofeggs, 16:48:26) * AGREED: #1863 is approved (+9, 0, -0) (bowlofeggs, 16:51:19) * Next week's chair (jsmith, 16:51:59) * AGREED: tyll to chair next week's meeting (jsmith, 16:53:48) * Open Floor (jsmith, 16:53:54) * #1859 Review of release blocking deliverables for F28 (jsmith, 16:54:35) * LINK: https://pagure.io/fesco/issue/1859 (jsmith, 16:54:35) * Open Floor (jsmith, 16:56:04) Meeting ended at 17:05:08 UTC. Action Items * bowlofeggs will talk to QA about batching * kalev to share his ideas on batching in the ticket * sgallagh will inform QA (the proposals are in the BZ already) * nirik will perform wonders with koji to attempt to get cloud images done Action Items, by person --- * bowlofeggs * bowlofeggs will talk to QA about batching * kalev * kalev to share his ideas on batching in the ticket * nirik * nirik will perform wonders with koji to attempt to get cloud images done * sgallagh * sgallagh will inform QA (the proposals are in the BZ already) * **UNASSIGNED** * (none) People Present (lines said) --- * bowlofeggs (162) * jsmith (119) * sgallagh (101) * nirik (75) * zbyszek (68) * jwb (37) * maxamillion (34) * tyll (32) * dgilmore (32) * zodbot (22) * kalev (13) * pingou (3) * pwhalen (2) * orc_fedo (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Review swaps
Hello, I'm looking for some help to review some Golang packages. These are all renamed packages to conform with the new Golang guidelines which standardizes package names. These are super simple devel only package and shouldn't pose any issue. Of course I'm available for any review in exchange. Review Request: golang-gopkg-sourcemap-1 - Source Maps consumer for Golang https://bugzilla.redhat.com/show_bug.cgi?id=1556649 Review Request: golang-gopkg-readline-1 - Pure golang implementation for GNU-Readline kind library https://bugzilla.redhat.com/show_bug.cgi?id=1556636 Review Request: golang-github-vividcortex-ewma - Exponentially Weighted Moving Average algorithms for Go https://bugzilla.redhat.com/show_bug.cgi?id=1555437 Review Request: golang-github-unknwon-goconfig - Configuration file parser for the Go Programming Language https://bugzilla.redhat.com/show_bug.cgi?id=1555434 Review Request: golang-github-nsf-termbox - A minimalistic API which allows programmers to write text-based user interfaces https://bugzilla.redhat.com/show_bug.cgi?id=1555402 Review Request: golang-github-ncw-acd - Go library for accessing the Amazon Cloud Drive https://bugzilla.redhat.com/show_bug.cgi?id=1555388 Review Request: golang-github-ncw-dropbox-sdk-unofficial - An unofficial Go SDK for integrating with the Dropbox API v2 https://bugzilla.redhat.com/show_bug.cgi?id=1555386 Review Request: golang-github-bitly-simplejson - Go package to interact with arbitrary JSON https://bugzilla.redhat.com/show_bug.cgi?id=1555345 Best regards, Robert-André. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 28 compose report: 20180316.n.0 changes
OLD: Fedora-28-20180315.n.0 NEW: Fedora-28-20180316.n.0 = SUMMARY = Added images:0 Dropped images: 8 Added packages: 0 Dropped packages:0 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 0 B Size of downgraded packages: 0 B Size change of upgraded packages: 0 B Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: Modular boot x86_64 Path: Modular/x86_64/iso/Fedora-Modular-netinst-x86_64-28-20180315.n.0.iso Image: Jam_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Jam_KDE-Live-x86_64-28-20180315.n.0.iso Image: Container_Minimal_Base docker s390x Path: Container/s390x/images/Fedora-Container-Minimal-Base-28-20180315.n.0.s390x.tar.xz Image: Modular boot aarch64 Path: Modular/aarch64/iso/Fedora-Modular-netinst-aarch64-28-20180315.n.0.iso Image: Modular boot i386 Path: Modular/i386/iso/Fedora-Modular-netinst-i386-28-20180315.n.0.iso Image: Modular boot ppc64 Path: Modular/ppc64/iso/Fedora-Modular-netinst-ppc64-28-20180315.n.0.iso Image: Modular boot ppc64le Path: Modular/ppc64le/iso/Fedora-Modular-netinst-ppc64le-28-20180315.n.0.iso Image: Modular boot s390x Path: Modular/s390x/iso/Fedora-Modular-netinst-s390x-28-20180315.n.0.iso = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = = DOWNGRADED PACKAGES = ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
batched periodic updates with security 'fast-tracked', vs incumbent continous updates firehose
I see the ongoing disagreement as to approaches in the Fedora FESCO bug, Adjust/Drop/Document batched updates policy [A], and here. I think there is some ** common ground **, fairly easy to implement, to satisfy both the: 'we need testing at once' cohort, and the: 'we are bandwidth constrained, or _churn_-adverse' group I chipped in briefly in today's FESCO meeting, but wanted to state a clean possible away forward Background: For updates, repodata is made by recursing a binary RPM tree That binary RPM tree may contain matter which has been indicated as security sensitive, and the rest not so designated Why not: 1. Continuously add to the binary RPM corpus (the present practice) 2. THEN run a new post process, where a new directory (call it 'security' for the moment) is created via 'hardlinks' (so no additional space requirements) (new) 3. If a given package is 'tagged' as security sensitive (put to one side for a moment HOW to know), add a hardlink to that new directory (new) 3a. Once the process is complete, run a 'repoclosure' test on the 'security' directory, and additional hardlinks to satisfy needed dependencies for those files, pulling from 'base' and 'updates' (similar to present practice) 4. Run a 'createrepo' on the 'security' directory, and name the output something distinctive: security-YMD comes to mind (new) 5. Once a week for say, Tuesday, run a 'repoclosure' test on the FULL directory (the present practice, but with a new output name in a moment) 5a. Raise an exception if it fails such, and bail and carp (the present practice) 6. If it passes, then run a 'createrepo' on the 'security' directory, and name the output something distinctive: patchTuesday-YMD (new) 7. Push those two sets of repodata out async, or daily, under the names (symlinks work here): security (new, so 'security' is always as fresh as possible with repoclosure) 8. - and - ONLY weekly, update the link an updated last successfully generated: patchTuesday (new) [This has the effect of fast-tracking security matter, and yet still having a pointer to the last known good complete transaction set of general updates] === 9. Continue to run 'normal' repoclosure, and 'createrepodata' processes. This is the full and continuous async 'updates' archive (the present practice) === 10. Amend the yum.conf offerings to have reference, in addition to 'updates', enabled and pointing to two new stanza's in 'updates' called: security -and- patchTuesday (new but fully backward compatible) === Use case narrative: If one enables both regular 'updates' and the 'security' / 'patchTuesday' config file, one gets continuous updates. If one disables regular 'updates' , one still gets updates, but only security updates get fast-tracked. If one disables the new stanza, one assumedly does not mess with 'updates' if one cares about updates (so: new, but fully backward compatible) -- Sidenote: Above, I put to one side how to ascertain that something is: 'tagged' as security sensitive I would suggest that if an update is asserted to be security sensitive, just add to the top Changelog entry: a tag with a "[CVE -]" reference, or once any embargo has passed, a tag with a "[Security]" reference and a pointer to the long form description of the issue in play It is trivial to extract the --changelog first stanza from a package, and so scan it and branch accordingly, if such are found, in building the 'security' hardlinked working copy -- Russ herrold A. https://pagure.io/fesco/issue/1820 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GCC 8.0.1 updates in F28
On Fri, 2018-03-16 at 13:13 +0100, Dominik 'Rathann' Mierzejewski wrote: > On Friday, 16 March 2018 at 01:36, Adam Williamson wrote: > > On Thu, 2018-03-15 at 18:26 +0100, Dan Horák wrote: > > > On Thu, 15 Mar 2018 17:11:49 + > > > Peter Robinson wrote: > > > > > > > On Thu, Mar 15, 2018 at 6:25 AM, Vascom > > > > wrote: > > > > > Hi. > > > > > > > > > > GCC 8.0.1-0.16 in F28 repo is freezed until F28 release? > > > > > Or it will be updated soon so we can build some packages > > > > > failed to > > > > > build now? > > > > > Or better use build override new gcc for this packages? > > > > > > > > Is there a particular bug fix that you need in the GA release > > > > you need > > > > for building against? The gcc release in stable is pretty close > > > > to GA > > > > so unless there's a specific bug that was fixed between the > > > > last > > > > stable build and the GA build it should make no difference to > > > > your > > > > builds. > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1554279 (fixed with > > > gcc-8.0.1-0.18.fc28) blocks builds packages using the gdal > > > library, so > > > an update (and override) would be useful > > > > Jakub says this is not broken in F28: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1554279#c3 > > But this is: > https://bugzilla.redhat.com/show_bug.cgi?id=1546743 > > And it's an ICE. IMHO , We should open an FE (Freeze exception) to gcc and annobin [1], please. I have been there (on GCC bugs) [2] after the GCC 8 mass rebuild, the problem was composes for F28/rawhide that stopped and we didn't had time to fix all things, now that composes back to normal we should add , at least, these packages. What I mean if composes worked as usual, I'm almost certain thatpackages would be in F28 before freeze . [1] I think just building with the Rawhide annobin [2] opencv , mlt , gdal, texlive etc -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora rawhide compose report: 20180316.n.0 changes
OLD: Fedora-Rawhide-20180315.n.1 NEW: Fedora-Rawhide-20180316.n.0 = SUMMARY = Added images:1 Dropped images: 2 Added packages: 7 Dropped packages:0 Upgraded packages: 164 Downgraded packages: 1 Size of added packages: 1.01 MiB Size of dropped packages:0 B Size of upgraded packages: 3.50 GiB Size of downgraded packages: 500.99 KiB Size change of upgraded packages: -6.73 MiB Size change of downgraded packages: 696 B = ADDED IMAGES = Image: Container_Base docker s390x Path: Container/s390x/images/Fedora-Container-Base-Rawhide-20180316.n.0.s390x.tar.xz = DROPPED IMAGES = Image: Container_Minimal_Base docker s390x Path: Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20180315.n.1.s390x.tar.xz Image: Python_Classroom raw-xz armhfp Path: Labs/armhfp/images/Fedora-Python-Classroom-armhfp-Rawhide-20180315.n.1-sda.raw.xz = ADDED PACKAGES = Package: bcal-1.8-1.fc29 Summary: Storage conversion and expression calculator RPMs:bcal Size:205.77 KiB Package: buku-3.6-1.fc29 Summary: Powerful command-line bookmark manager RPMs:buku Size:68.19 KiB Package: googler-3.5-1.fc29 Summary: Access google search, google site search, google news from the terminal RPMs:googler Size:60.34 KiB Package: imgp-2.5-1.fc29 Summary: Multi-core batch image resizer and rotator RPMs:imgp Size:32.73 KiB Package: insect-5.0.0-2.fc29 Summary: A scientific calculator RPMs:insect Size:312.61 KiB Package: nnn-1.7-1.fc29 Summary: The missing terminal file browser for X RPMs:nnn Size:329.45 KiB Package: pdd-1.1-1.fc29 Summary: Tiny date, time diff calculator RPMs:pdd Size:25.26 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: ETL-1:1.2.1-3.fc29 Old package: ETL-1:1.2.1-2.fc29 Summary: Extended Template Library RPMs: ETL-devel Size: 913.62 KiB Size change: -20 B Package: NetworkManager-ssh-1.2.7-3.fc29 Old package: NetworkManager-ssh-1.2.7-1.fc28 Summary: NetworkManager VPN plugin for SSH RPMs: NetworkManager-ssh NetworkManager-ssh-gnome Size: 723.81 KiB Size change: 9.75 KiB Changelog: * Wed Feb 07 2018 Fedora Release Engineering - 1.2.7-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild * Fri Mar 16 2018 Dan Fruehauf - 1.2.7-3 - Drop libnm-glib for Fedora 28 Package: PyGreSQL-5.0.4-3.fc29 Old package: PyGreSQL-5.0.4-1.fc27 Summary: Python client library for PostgreSQL RPMs: python2-pygresql python3-pygresql Added RPMs: python2-pygresql python3-pygresql Dropped RPMs: PyGreSQL python3-PyGreSQL Size: 1.52 MiB Size change: 21.19 KiB Changelog: * Tue Jan 02 2018 Zbigniew J??drzejewski-Szmek - 5.0.4-2 - Python 2 binary package renamed to python2-pygresql See https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3 - Python 3 binary package renamed to python3-pygresql * Wed Feb 07 2018 Fedora Release Engineering - 5.0.4-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild * Thu Mar 15 2018 Pavel Raiskup - 5.0.4-3 - fix FTBFS after PostgreSQL upgrade to 10 Package: R-DelayedArray-0.4.1-1.fc29 Old package: R-DelayedArray-0.2.7-2.fc27 Summary: Delayed operations on array-like objects RPMs: R-DelayedArray Size: 622.74 KiB Size change: 253.50 KiB Changelog: * Wed Feb 07 2018 Fedora Release Engineering - 0.2.7-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild * Wed Mar 14 2018 Tom Callaway - 0.4.1-1 - update to 0.4.1 Package: R-GenomicAlignments-1.14.1-1.fc29 Old package: R-GenomicAlignments-1.12.1-3.fc27 Summary: Representation and manipulation of short genomic alignments RPMs: R-GenomicAlignments Size: 12.06 MiB Size change: 1.13 MiB Changelog: * Wed Feb 07 2018 Fedora Release Engineering - 1.12.1-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild * Wed Mar 14 2018 Tom Callaway - 1.14.1-1 - update to 1.14.1 Package: R-GenomicRanges-1.30.3-1.fc29 Old package: R-GenomicRanges-1.28.3-3.fc27 Summary: Representation and manipulation of genomic intervals RPMs: R-GenomicRanges Size: 10.94 MiB Size change: 787.44 KiB Changelog: * Wed Feb 07 2018 Fedora Release Engineering - 1.28.3-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild * Wed Mar 14 2018 Tom Callaway - 1.30.3-1 - update to 1.30.3 Package: R-IRanges-2.12.0-1.fc29 Old package: R-IRanges-2.10.1-3.fc27 Summary: Low-level containers for storing sets of integer ranges RPMs: R-IRanges R-IRanges-devel Size: 10.51 MiB Size change: 208.41 KiB Changelog: * Wed Feb 07 2018 Fedora Release Engineering - 2.10.1-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild * Wed Mar 14 2018 Tom Callaway - 2.12.0-1 - update to 2.12.0 Package: R-R6
Changes in Fedora Release Engineering
Hi all, Today I am writing to announce some changes in Fedora Release Engineering. Effective Friday the 23rd of March 2018 Mohan Boddu will be taking over as the primary person responsible for Release Engineering in Fedora. Mohan has effectively been the primary person since Fedora 26 as he has been doing most of the work. I will be taking on a new role within Red Hat, and will no longer be in the internal Release Engineering team. Going forward Mohan will be supported by Suzanne Yeghiayan as project manager for release engineering. All requests for work should go though pagure[1] or taiga[2] to be groomed, prioritised and scoped. I have posted a blog post[3] with some of my thoughts in reflection looking back at the last 8 or so years. Thank you all for you support over the years and your continued support of Mohan and the rest of the Release Engineers in Fedora. Dennis [1] https://pagure.io/releng [2] https://taiga.fedorainfracloud.org/project/acarter-fedora-docker-at omic-tooling/ [3] https://ausil.us/wordpress/?p=143 signature.asc Description: This is a digitally signed message part ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Link error in F28 (but not Rawhide)
On Fri, 2018-03-16 at 12:09 +, Sérgio Basto wrote: > On Thu, 2018-03-15 at 20:47 -0400, Scott Talbert wrote: > > I'm seeing a strange error when building wxGTK3 on F28. This only > > happens > > on x86_64. The same package built fine on Rawhide. Anyone have any > > ideas > > what's going on here? > > This message [1] (70 times) is very strange and seems the root cause > > [1] > annobin: sound_sdl.cpp: CET values have changed from > 0:1954187174:20:1 to 0:100824:20:1 I've actually seen the exact same thing in something else, I forget what and can't find the bug right now. I think just building with the Rawhide annobin package makes it work, so we might need an updated annobin for F28, or something. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GCC 8.0.1 updates in F28
On Friday, 16 March 2018 at 01:36, Adam Williamson wrote: > On Thu, 2018-03-15 at 18:26 +0100, Dan Horák wrote: > > On Thu, 15 Mar 2018 17:11:49 + > > Peter Robinson wrote: > > > > > On Thu, Mar 15, 2018 at 6:25 AM, Vascom wrote: > > > > Hi. > > > > > > > > GCC 8.0.1-0.16 in F28 repo is freezed until F28 release? > > > > Or it will be updated soon so we can build some packages failed to > > > > build now? > > > > Or better use build override new gcc for this packages? > > > > > > Is there a particular bug fix that you need in the GA release you need > > > for building against? The gcc release in stable is pretty close to GA > > > so unless there's a specific bug that was fixed between the last > > > stable build and the GA build it should make no difference to your > > > builds. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1554279 (fixed with > > gcc-8.0.1-0.18.fc28) blocks builds packages using the gdal library, so > > an update (and override) would be useful > > Jakub says this is not broken in F28: > > https://bugzilla.redhat.com/show_bug.cgi?id=1554279#c3 But this is: https://bugzilla.redhat.com/show_bug.cgi?id=1546743 And it's an ICE. Regards, Dominik -- Fedora https://getfedora.org | RPMFusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Link error in F28 (but not Rawhide)
On Thu, 2018-03-15 at 20:47 -0400, Scott Talbert wrote: > I'm seeing a strange error when building wxGTK3 on F28. This only > happens > on x86_64. The same package built fine on Rawhide. Anyone have any > ideas > what's going on here? This message [1] (70 times) is very strange and seems the root cause [1] annobin: sound_sdl.cpp: CET values have changed from 0:1954187174:20:1 to 0:100824:20:1 > This is the Koji task: > https://koji.fedoraproject.org/koji/taskinfo?taskID=25734989 > > Here's the error: > `_ZN8wxThread8OnDeleteEv_end' referenced in section > `.gnu.build.attributes' of advdll_sound_sdl.o: defined in discarded > section `.text._ZN8wxThread8OnDeleteEv[_ZN8wxThread8OnDeleteEv]' of > advdll_sound_sdl.o > `_ZN8wxThread6OnKillEv_end' referenced in section > `.gnu.build.attributes' > of advdll_sound_sdl.o: defined in discarded section > `.text._ZN8wxThread6OnKillEv[_ZN8wxThread6OnKillEv]' of > advdll_sound_sdl.o > `_ZN8wxThread6OnExitEv_end' referenced in section > `.gnu.build.attributes' > of advdll_sound_sdl.o: defined in discarded section > `.text._ZN8wxThread6OnExitEv[_ZN8wxThread6OnExitEv]' of > advdll_sound_sdl.o > `_ZNK20wxObjectEventFunctor13GetEvtHandlerEv_end' referenced in > section > `.gnu.build.attributes' of advdll_sound_sdl.o: defined in discarded > section > `.text._ZNK20wxObjectEventFunctor13GetEvtHandlerEv[_ZNK20wxObjectEven > tFunctor13GetEvtHandlerEv]' > of advdll_sound_sdl.o > `_ZNK20wxObjectEventFunctor12GetEvtMethodEv_end' referenced in > section > `.gnu.build.attributes' of advdll_sound_sdl.o: defined in discarded > section > `.text._ZNK20wxObjectEventFunctor12GetEvtMethodEv[_ZNK20wxObjectEvent > Functor12GetEvtMethodEv]' > of advdll_sound_sdl.o > `_ZNK7wxEvent16GetEventCategoryEv_end' referenced in section > `.gnu.build.attributes' of advdll_sound_sdl.o: defined in discarded > section > `.text._ZNK7wxEvent16GetEventCategoryEv[_ZNK7wxEvent16GetEventCategor > yEv]' > of advdll_sound_sdl.o > `_ZN12wxEvtHandler14SetNextHandlerEPS__end' referenced in section > `.gnu.build.attributes' of advdll_sound_sdl.o: defined in discarded > section > `.text._ZN12wxEvtHandler14SetNextHandlerEPS_[_ZN12wxEvtHandler14SetNe > xtHandlerEPS_]' > of advdll_sound_sdl.o > `_ZN12wxEvtHandler18SetPreviousHandlerEPS__end' referenced in section > `.gnu.build.attributes' of advdll_sound_sdl.o: defined in discarded > section > `.text._ZN12wxEvtHandler18SetPreviousHandlerEPS_[_ZN12wxEvtHandler18S > etPreviousHandlerEPS_]' > of advdll_sound_sdl.o > `_ZN12wxEvtHandler15AddPendingEventERK7wxEvent_end' referenced in > section > `.gnu.build.attributes' of advdll_sound_sdl.o: defined in discarded > section > `.text._ZN12wxEvtHandler15AddPendingEventERK7wxEvent[_ZN12wxEvtHandle > r15AddPendingEventERK7wxEvent]' > of advdll_sound_sdl.o > `_ZN12wxEvtHandler12TryValidatorER7wxEvent_end' referenced in section > `.gnu.build.attributes' of advdll_sound_sdl.o: defined in discarded > section > `.text._ZN12wxEvtHandler12TryValidatorER7wxEvent[_ZN12wxEvtHandler12T > ryValidatorER7wxEvent]' > of advdll_sound_sdl.o > `_ZN20wxObjectEventFunctorclEP12wxEvtHandlerR7wxEvent_end' referenced > in > section `.gnu.build.attributes' of advdll_sound_sdl.o: defined in > discarded section > `.text._ZN20wxObjectEventFunctorclEP12wxEvtHandlerR7wxEvent[_ZN20wxOb > jectEventFunctorclEP12wxEvtHandlerR7wxEvent]' > of advdll_sound_sdl.o > `_ZN50wxStringToStringHashMap_wxImplementation_HashTable16GetBucketFo > rNodeEPS_PNS_4NodeE_end' > referenced in section `.gnu.build.attributes' of advdll_sound_sdl.o: > defined in discarded section > `.text._ZN50wxStringToStringHashMap_wxImplementation_HashTable16GetBu > cketForNodeEPS_PNS_4NodeE[_ZN50wxStringToStringHashMap_wxImplementati > on_HashTable16GetBucketForNodeEPS_PNS_4NodeE]' > of advdll_sound_sdl.o > `_ZN12wxEvtHandler9TryParentER7wxEvent_end' referenced in section > `.gnu.build.attributes' of advdll_sound_sdl.o: defined in discarded > section > `.text._ZN12wxEvtHandler9TryParentER7wxEvent[_ZN12wxEvtHandler9TryPar > entER7wxEvent]' > of advdll_sound_sdl.o > `_ZN20wxObjectEventFunctorD2Ev_end' referenced in section > `.gnu.build.attributes' of advdll_sound_sdl.o: defined in discarded > section > `.text._ZN20wxObjectEventFunctorD2Ev[_ZN20wxObjectEventFunctorD5Ev]' > of > advdll_sound_sdl.o > `_ZN20wxObjectEventFunctorD0Ev_end' referenced in section > `.gnu.build.attributes' of advdll_sound_sdl.o: defined in discarded > section > `.text._ZN20wxObjectEventFunctorD0Ev[_ZN20wxObjectEventFunctorD5Ev]' > of > advdll_sound_sdl.o > `_ZN20wxThreadHelperThread5EntryEv_end' referenced in section > `.gnu.build.attributes' of advdll_sound_sdl.o: defined in discarded > section > `.text._ZN20wxThreadHelperThread5EntryEv[_ZN20wxThreadHelperThread5En > tryEv]' > of advdll_sound_sdl.o > `_ZN20wxThreadHelperThreadD2Ev_end' referenced in section > `.gnu.build.attributes' of advdll_sound_sdl.o: defined in discarded > section > `.text._ZN20wxThreadHelperThreadD2Ev[_ZN20wxThreadHelperThread
Re: Use Noto Sans UI for Cantarell fallback in Workstation?
Le vendredi 16 mars 2018 à 11:49 +, Nikolaus Waxweiler a écrit : > You sound like you need to cool your head. > > > It's kind of sad that despite being is stasis for years DejaVu is > > still leagues away from prototypes dumped on our users just for the > > coolness factor > > Well duh ;) And to finish one major reason DejaVu went in stasis is that major so- called FLOSS projects like GNOME or Ubuntu dropped it for designer fonts that didn't offer any obvious way to submit enhancements and get them six months later in their next Linux distro release. That pretty much killed any incentive to contribute font enhancements anywhere. -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Use Noto Sans UI for Cantarell fallback in Workstation?
> But even compared to Noto, DejaVu has lots coverage for convenient glyphs > that people added over the years People who want those can and probably know how to continue to use DejaVu or one of its derivatives. Cathedrals and bazaars can happily coexist :) This is about setting a sane and consistent default to covers (almost?) all living scripts you care to display text in on a computer screen, and I absolutely support any decision to default to Noto (and maybe ship DejaVu Sans Mono for the console if Noto Sans Mono turns out to not be up to the task yet). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Use Noto Sans UI for Cantarell fallback in Workstation?
Le vendredi 16 mars 2018 à 11:49 +, Nikolaus Waxweiler a écrit : > > Not sure what you're referring to? Do you mean something specific > about the Notos? I mean all the idiots that will look down on any font with some community development, because “professional” is better. It’s not necessarily better any more than closed software is better than free software (I still remember the idiots that wrote dozens of disparaging articles on DejaVu, only to fall over themselves once Apple forked it, renamed it and tweaked a couple glyphs. And IIRC the tweaked glyphs were originally done by the Bitstream “professionals”). -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Use Noto Sans UI for Cantarell fallback in Workstation?
Le vendredi 16 mars 2018 à 07:14 -0400, Neal Gompa a écrit : > > I personally would prefer if we used Noto across the board. It's a > fantastic font family, and its CJK and Indic font representation is > fairly solid for me. Anyway and just to be clear I'll be personally happy with any default FLOSS font set that takes i18n coverage seriously, over vanity fonts whose main point is to be “different” and consider it's ok to drop coverage even from easy scripts like Greek or Cyrillic, just to tweak some ASCII glyphs. Font set means synchronized sans and sans mono at minima. i18n means LGC at least and hopefully indic CJK or arabic. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Use Noto Sans UI for Cantarell fallback in Workstation?
You sound like you need to cool your head. > It's kind of sad that despite being is stasis for years DejaVu is still > leagues away from prototypes dumped on our users just for the coolness factor Well duh ;) > And, I wouldn't put to much weight on “professional” development. The last > years have pretty much proven that “professionnal” development is a synonym > for “cutting corners on i18n where we think users won't notice it, because > our customers only check ASCII”. Not sure what you're referring to? Do you mean something specific about the Notos? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Use Noto Sans UI for Cantarell fallback in Workstation?
Le vendredi 16 mars 2018 à 04:07 -0700, Adam Williamson a écrit : > > Are you conflating Cantarell and Noto there? I am not especially > qualified to judge the quality of any of these fonts, but the Noto > family's script coverage seems pretty solid: > > https://en.wikipedia.org/wiki/Noto_fonts#List_of_Noto_fonts > > at least some of those seem to be essentially other fonts that have > been 'rebranded' as Noto, so I've no idea how consistent their > appearance is, of course. > > DejaVu seems to have less coverage, Sure Noto is the heavyweight in the room and nothing much approaches it. But even compared to Noto, DejaVu has lots coverage for convenient glyphs that people added over the years, that do not fall easily in script classification, and that are notably absent in “design-for-hire” fonts that focus on script lists. That’s one reason it continues to be popular among users, even latin script users. That’s the difference between cathedral and bazaar approaches. Cathedral is much more consistent and clean, but you better hope your need was in the cathedral architect list (and most actual cathedrals never managed to pursue cathedral approach to the end, they have deviations from the master plan because at one point need trumped unified vision) Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Schedule for Friday's FESCo Meeting (2018-03-16)
Following is the list of topics that will be discussed in the FESCo meeting Friday at 15:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2018-03-16 15:00 UTC' Links to all issues below can be found at: https://pagure.io/fesco/report/meeting_agenda = Followups = #topic #1745 F28 System Wide Change: Switch OpenLDAP from NSS to OpenSSL .fesco 1745 https://pagure.io/fesco/issue/1745 #topic #1820 Adjust/Drop/Document batched updates policy .fesco 1820 https://pagure.io/fesco/issue/1820 #topic #1853 F29 System Wide Change: Enable dbus-broker .fesco 1853 https://pagure.io/fesco/issue/1853 #topic #1858 Proposed Fedora 29 schedule .fesco 1858 https://pagure.io/fesco/issue/1858 #topic #1859 Review of release blocking deliverables for F28 .fesco 1859 https://pagure.io/fesco/issue/1859 #topic #1859 Review of release blocking deliverables for F28 .fesco 1859 https://pagure.io/fesco/issue/1859 #topic #1861 F28 Changes not in ON_QA status .fesco 1861 https://pagure.io/fesco/issue/1861 = New business = #topic #1862 Fedora 28 Beta status, schedule risk .fesco 1862 https://pagure.io/fesco/issue/1862 #topic #1863 F29 Self Contained Change: OpenLDAP: Drop MozNSS Compatibility Layer .fesco 1863 https://pagure.io/fesco/issue/1863 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Use Noto Sans UI for Cantarell fallback in Workstation?
On Fri, Mar 16, 2018 at 7:07 AM, Adam Williamson wrote: > On Fri, 2018-03-16 at 12:00 +0100, Nicolas Mailhot wrote: >> Le vendredi 16 mars 2018 à 10:43 +, Nikolaus Waxweiler a écrit : >> > > >> > >> > Fine with me actually. DejaVu only having two weights (the thin looks >> > more experimental to me) is going to clash with Gnome's design >> > intentions though from what I hear. Noto would still be preferable >> > because it's the 800 pound gorilla in Unicode coverage, _consistent_ >> > design quality and available weights and widths. And it's under active >> > professional development, while DejaVu seems to be in stasis. >> >> It's kind of sad that despite being is stasis for years DejaVu is still >> leagues away from prototypes dumped on our users just for the coolness >> factor >> >> And, I wouldn't put to much weight on “professional” development. The >> last years have pretty much proven that “professionnal” development is a >> synonym for “cutting corners on i18n where we think users won't notice >> it, because our customers only check ASCII”. > > Are you conflating Cantarell and Noto there? I am not especially > qualified to judge the quality of any of these fonts, but the Noto > family's script coverage seems pretty solid: > > https://en.wikipedia.org/wiki/Noto_fonts#List_of_Noto_fonts > > at least some of those seem to be essentially other fonts that have > been 'rebranded' as Noto, so I've no idea how consistent their > appearance is, of course. > > DejaVu seems to have less coverage, and indeed IIRC we currently use > other fonts by default for scripts other than Latin, Greek and > Cyrillic. I personally would prefer if we used Noto across the board. It's a fantastic font family, and its CJK and Indic font representation is fairly solid for me. My only gripe with it is the ambiguity in Noto Mono for zero, i/l, period/comma, and colon/semicolon. That is, they're not necessarily distinct enough. Otherwise I'd even love for it to be the default terminal font (since I think we can use OpenType fonts for console fonts now...). -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Use Noto Sans UI for Cantarell fallback in Workstation?
On Fri, 2018-03-16 at 12:00 +0100, Nicolas Mailhot wrote: > Le vendredi 16 mars 2018 à 10:43 +, Nikolaus Waxweiler a écrit : > > > > > > > Fine with me actually. DejaVu only having two weights (the thin looks > > more experimental to me) is going to clash with Gnome's design > > intentions though from what I hear. Noto would still be preferable > > because it's the 800 pound gorilla in Unicode coverage, _consistent_ > > design quality and available weights and widths. And it's under active > > professional development, while DejaVu seems to be in stasis. > > It's kind of sad that despite being is stasis for years DejaVu is still > leagues away from prototypes dumped on our users just for the coolness > factor > > And, I wouldn't put to much weight on “professional” development. The > last years have pretty much proven that “professionnal” development is a > synonym for “cutting corners on i18n where we think users won't notice > it, because our customers only check ASCII”. Are you conflating Cantarell and Noto there? I am not especially qualified to judge the quality of any of these fonts, but the Noto family's script coverage seems pretty solid: https://en.wikipedia.org/wiki/Noto_fonts#List_of_Noto_fonts at least some of those seem to be essentially other fonts that have been 'rebranded' as Noto, so I've no idea how consistent their appearance is, of course. DejaVu seems to have less coverage, and indeed IIRC we currently use other fonts by default for scripts other than Latin, Greek and Cyrillic. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Use Noto Sans UI for Cantarell fallback in Workstation?
Le vendredi 16 mars 2018 à 10:43 +, Nikolaus Waxweiler a écrit : > > > Fine with me actually. DejaVu only having two weights (the thin looks > more experimental to me) is going to clash with Gnome's design > intentions though from what I hear. Noto would still be preferable > because it's the 800 pound gorilla in Unicode coverage, _consistent_ > design quality and available weights and widths. And it's under active > professional development, while DejaVu seems to be in stasis. It's kind of sad that despite being is stasis for years DejaVu is still leagues away from prototypes dumped on our users just for the coolness factor And, I wouldn't put to much weight on “professional” development. The last years have pretty much proven that “professionnal” development is a synonym for “cutting corners on i18n where we think users won't notice it, because our customers only check ASCII”. -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Use Noto Sans UI for Cantarell fallback in Workstation?
> Users prefer sans and sans mono to be synchronized Weight parity is in the works :) https://github.com/googlei18n/noto-fonts-alpha/tree/master/from-pipeline/unhinted/otf/sans/NotoSansMono. A true italic seems to be a way off though. > so maybe it’s time to put back as default a font with decent > i18n coverage instead of making it “different is better” for a few > blessed locales and a pit of font substitutions for the majority of > other locales? Fine with me actually. DejaVu only having two weights (the thin looks more experimental to me) is going to clash with Gnome's design intentions though from what I hear. Noto would still be preferable because it's the 800 pound gorilla in Unicode coverage, _consistent_ design quality and available weights and widths. And it's under active professional development, while DejaVu seems to be in stasis. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Use Noto Sans UI for Cantarell fallback in Workstation?
Le vendredi 16 mars 2018 à 09:43 +, Nikolaus Waxweiler a écrit : > It is my upstream opinion that the entire free desktop landscape > should use Noto Sans/Serif (UI) as the default (fallback) font for > everything and not ship anything else in a base system, except DejaVu > Mono because Noto Mono has only a regular face. And you have your answer DejaVu Mono is way more advanced and complete than the alternatives Users prefer sans and sans mono to be synchronized The original decision to use Cantarell in Workstation was GNOME's desire to distinguish itself from a DejaVu design “everyone had already seen” (so a more technically deficient font for many locales for NIH reasons), and “more coverage would come later”, but now everyone has seen Cantarell, it’s old and tired too, its coverage is not progressing but regressing, so maybe it’s time to put back as default a font with decent i18n coverage instead of making it “different is better” for a few blessed locales and a pit of font substitutions for the majority of other locales? There's no excuse in 2018 to default to a font without Greek or Cyrillic (there was almost no excuse when GNOME dumped Cantarell on us, DejaVu and other FLOSS font had already set the new bar to attain). Other parts of Unicode are hard and lack of coverage is still acceptable to users, but Greek and Cyrillic? They should be a solved problem today. If you can't do them in your default font, don't pretend being an i18n project. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Use Noto Sans UI for Cantarell fallback in Workstation?
It is my upstream opinion that the entire free desktop landscape should use Noto Sans/Serif (UI) as the default (fallback) font for everything and not ship anything else in a base system, except DejaVu Mono because Noto Mono has only a regular face. Self-quote: > The difference between Noto Sans UI and Noto Sans is that UI keeps the > vertical height the same across all scripts, so text height doesn't jump when > multiple scripts turn up on the same line or you switch from one script to > the next. > > Noto Sans (UI) should be the default (fallback) font for everything anyway, > as it is the most-well funded professional, open-source, active font > development effort spanning the most languages. The alternatives for > different languages commonly shipping with distros don't even compare in > quality. Side-note: changing the default (fallback) sans font has side-effects: websites relying on DejaVu being the default sans have their text appear smaller. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Gating packages in Rawhide
On Mon, Mar 12, 2018 at 06:05:22PM -0400, Randy Barlow wrote: > On 03/09/2018 04:20 AM, Pierre-Yves Chibon wrote: > > I had a different idea in mind, basically try to keep the experience as > > close as > > what it is now. > > for single package: > > - packager commit > > - packager build > > - build is tagged into a specfic koji tag > > - test are run on this tag > > -> results go to src.fp.o > > - if tests pass > > - package is moved to another koji tag > > - package is signed > > - package is pushed to rawhide > > - if tests do not pass > > - do nothing > > - if the user submits a waiver > > - move the package to the next koji tag for signing it > > If a packager does not want to run the tests, we could have a fedpkg build > > --noci that would directly build the package in the koji tag used for > > signing > > the package (useful for mass-rebuild for example) > > I would really like to have tests in src.fpo, but I think they would be > most helpfully displayed on pull requests, rather than after I've > already made a Koji build. This is more similar to the workflow I'm > accustomed to when I work on Bodhi's upstream code - I submit a PR and > CentOS CI (which is very nice btw) chews on it and tells me if I'm good > to merge. For a single package update (which is most of what I > personally do) it would be very nice to have this before I merge my PR > in Pagure. I don't think the two are antagonist, one is the pre-merge/PR workflow with the tests ran on the PR, the other is post-merge. Both approach can already be supported today. > So all that to say that I like the above, but I'd like to propose that > there also be some tests run before I commit (i.e., merge the PR) and > build in Koji (for cases where we use PRs. I'm not proposing we require > PRs, but that it be available for those of us who would like to use that > workflow). PRs do get the simplekojici build today, which is cool. I'd > really just like a few more tests than that to be run as well. We're working on the pipeline that will run the tests present on all and every package having tests (instead of the restricted set of packages included in Fedora Atomic Host). The next step will be PR testing. Feel free to poke Dominik Perpeet if you want more details :) > > for multi-package: > > - packager requests a new side-tag (I'd propose via bodhi) > > - packager build all the different packages in that side-tag > > - packager asks for the side tag to be merged > > - tests are run on all these packages > > -> results go to src.fp.o > > At this point there aren't pull requests, right? Where would we display > this in src.fp.o that would make it clear which change the test results > pertain to? In the commit page itself, for example: https://src.fedoraproject.org/rpms/perl-IO-HTML/c/69a460858b8c1f47bb6320faa6f310dab6808184 (that's the fbom service: https://pagure.io/fedora-ci/fbom which flags in src.fp.o successful build made in koji, it's not currently running, we need to process the RFR: https://pagure.io/fedora-infrastructure/issue/6717 so don't look for it on every repo) > > --> We probably want to also report them on the bodhi request to merge > > the > > tag as otherwise the packager will have to go through all the > > package to > > find the one(s) that failed > > Do you mean that Bodhi would display them on a side tag page? That was my proposal yes. > Or in this scenario are you suggesting that a Bodhi update has been created? I don't really see the need for one, so in this proposal, the bodhi update mechanism wasn't used. Bodhi was used for only for managing side-tags and since merging a side-tag will be impacted by the test results including that info there made sense to me. > The update would be less friction since we already have code to display test > results on Bodhi updates. That's fair, on the other side we're going to have to build an entirely new part in bodhi and we potentially may want to present the test results differently there (don't know, something to think about). Pierre signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Goodbye nvr.rsplit('-', 2), hello modularity
On Thu, Mar 15, 2018 at 05:47:41PM -0700, Adam Williamson wrote: > So: there would be no problem with - in the *name* of the modules, so > long as that's the first field, which apparently it is. > > The problem is if you allow the delimiter in *both* the first and last > fields, or in *any other field besides the first and the last*. As soon > as you do that, parsing is impossible. This is the issue with module > names, as Patrick pointed out: they allow - in the stream, which is the > *second* field. As soon as you allow this, reliably parsing the name > components out of the whole name becomes impossible. > > Yes, you can say 'just don't parse strings, go ask a service instead', > but parsing strings is sometimes by a long way the most convenient way > to do things, and I really can't see how allowing the delimiter > character to appear in one of the field names is a *bigger* win than > allowing the components to be reliably parsed from the overall name. I wonder what we can do about this. Is it FESCo material? Can the folks working on modularity comment more on this? This is quite failing the moto: it's ok to disagree, not to surprise Pierre ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Use Noto Sans UI for Cantarell fallback in Workstation?
Hi all, In Workstation, our UI font is Cantarell. I was chatting to Cantarell's upstream maintainer, Nikolaus Waxweiler yesterday and he said that we should be using Noto Sans UI as a fallback for glyphs where Cantarell lacks coverage (cyrillic, for example). Right now we're falling back to DejaVu Sans, which looks a bit out of place; Noto Sans UI would be a much closer match to Cantarell. I've opened a ticket in the Workstation issue tracker to consider changing the fallback for F28, but I'm largely clueless about fonts in general and would appreciate any feedback, both positive and negative, and any help from fonts people to actually make it happen (changing fontconfig fallbacks and priorities etc). https://pagure.io/fedora-workstation/issue/36 Thanks, and please let me know if you think this doesn't make any sense (and also if it does!). :) Kalev ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GCC 8.0.1 updates in F28
On Thu, 15 Mar 2018 17:36:47 -0700 Adam Williamson wrote: > On Thu, 2018-03-15 at 18:26 +0100, Dan Horák wrote: > > On Thu, 15 Mar 2018 17:11:49 + > > Peter Robinson wrote: > > > > > On Thu, Mar 15, 2018 at 6:25 AM, Vascom wrote: > > > > Hi. > > > > > > > > GCC 8.0.1-0.16 in F28 repo is freezed until F28 release? > > > > Or it will be updated soon so we can build some packages failed to > > > > build now? > > > > Or better use build override new gcc for this packages? > > > > > > Is there a particular bug fix that you need in the GA release you need > > > for building against? The gcc release in stable is pretty close to GA > > > so unless there's a specific bug that was fixed between the last > > > stable build and the GA build it should make no difference to your > > > builds. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1554279 (fixed with > > gcc-8.0.1-0.18.fc28) blocks builds packages using the gdal library, so > > an update (and override) would be useful > > Jakub says this is not broken in F28: > > https://bugzilla.redhat.com/show_bug.cgi?id=1554279#c3 hm, then I had the problem only in Rawhide, too many things changing and being worked on ... Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora-Atomic 27-20180316.0 compose check report
No missing expected images. Passed openQA tests: 2/2 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Rawhide-20180315.n.1 compose check report
On Thu, 2018-03-15 at 22:26 +, Fedora compose checker wrote: > No missing expected images. > > Failed openQA tests: 84/137 (x86_64), 24/24 (i386), 1/2 (arm) Virtually all tests currently fail on Rawhide because a complete redesign of Cantarell - the font we use in anaconda - landed and broke just about every needle in openQA :/ This isn't affecting F28 install tests yet due to the freeze, it does affect update tests, though. I've been redoing needles all day, I wanted to get it finished today but it's midnight, so I'm leaving it for tonight, I'll finish up in the morning. Sorry for the inconvenience. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
