Fedora-Cloud-30-20191128.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (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 Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Is 50+ RPM Subpackages too extreme?
On 11/27/19 6:49 PM, Chris wrote: + Sérgio: In regards to why sub-packages: * Purely for modularity and isolation. Users who just use Apprise for... say Discord and Email, don't need the other 49 packages. But someone hosting a notification web service might want all of them except the ones that utilize local libraries (one uses the DBus interface as an example). Each package has absolutely no external dependences except maybe 2. Given that they're only one python file, making modules for each one seems rather excessive, especially since they don't have external dependencies. Depending on what the dependencies are for the two that do, it might be worth making subpackages for those only. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Is 50+ RPM Subpackages too extreme?
Thank you all for replying with so much information! I just had a few
comments:
+ I'm officially afraid of the texlive spec file.
+ Sérgio: In regards to why sub-packages:
* Purely for modularity and isolation. Users who just use Apprise
for... say Discord and Email, don't need the other 49 packages. But
someone hosting a notification web service might want all of them except
the ones that utilize local libraries (one uses the DBus interface as an
example). Each package has absolutely no external dependences except maybe
2.
+ Samuel: Thank you for your points.
* I don't honestly think my package really has much of a following. So
I see maybe frustrating a handful of people at worst case by changing
everything up. But you still raise some good points. Maybe I could do what
'nagios-plugins' does and has a general package that does nothing but
'Recommends' (or Requires) many others (hauling them all in). This was
brought up by Igor; i like this idea.
+ Tom: Thank you for the lua example!
* While this is somewhat cryptic to me at first glance (not knowing it);
I imagine once it works, it doesn't have to be touched again. Of the 50
some odd services (to-be-sub-packages), about 2 of them actually have
external dependencies. I presume there is some black magic taking place in
the %build section that is allowing these templates to work?
* Here is what my current working-spec-file looks like (without
sub-packages):
https://github.com/caronc/apprise/blob/master/packaging/redhat/python-apprise.spec
* Since I really want to maintain backwards compatibility with EPEL7, I
imagine I'm going to have double the entries to accommodate Python 2.7
references too... :(
+ Richard: Thank you very much for sharing those references, I had a look
into each specfile and first of... whoa... they're very big But one
thing I noticed is nbdkit is slightly inconsistent with some of the other
package (or vs versa?):
* sub-packages in nbdkit are formatted as: 'ndbkit-{name}-{type}' (where
{type} would be plugin) while other packages (such as libvirt) does it's
sub-packages as 'libvirtd-{type}-{plugin}'. Is there a preference or a
standard I should use?
* Also, this goes slightly against Tom's suggestion (using an lua
in-line script). While everything is in plain English using your examples;
well, it's just 'a-lot' of content. I saw some discussion going back and
forth which is better; but I guess it's preference at the end.
Chris
On Wed, Nov 27, 2019 at 12:38 PM Chris Adams wrote:
> Once upon a time, Matej Grabovsky said:
> > Can you please explain what you mean? What are the alternatives if
> > there really are over 5000 packages in CTAN?
>
> Why does all of CTAN need to go into one source RPM?
> --
> Chris Adams
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
F30+F31: systemupgrades added unfullfillable module dependencies
Hi, I just found this on Bugzilla and i think it needs immediate intervention: https://bugzilla.redhat.com/show_bug.cgi?id=1767422 release upgrades involved: F29->F30 & F30->F31 - removing the mentioned packages do not fix the problem - they complain about issues in the next release Conclusion: Something is not working as planed. Tasks needed: Autofix for those errors. Short version: [retranslated from german dnf output] # uname -a Linux eve... 5.3.12-200.fc30.x86_64 #1 SMP Thu Nov 21 22:47:04 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux [root@eve ]# dnf erase gimp problems with modular dependencies: Problem 1: conflicting requests - nothing provides module(platform:f31) needed by module gimp:2.10:3120191106095052:f636be4b-0.x86_64 Problem 2: conflicting requests - nothing provides module(platform:f31) needed by module meson:latest:3120191009081836:dc56099c-0.x86_64 Problem 3: conflicting requests - nothing provides module(platform:f31) needed by module ninja:latest:3120190304180949:f636be4b-0.x86_64 dependencies got resolved. Package Architecture Version Repository Size Entfernen: gimp x86_64 2:2.10.14-1.module_f30+6995+c35e2138 @updates-modular 109 M Dependencie packages getting removed: gimp-help-de noarch 2.10.0-1.fc30 @updates 62 M no longer needed dependencies getting removed: gimp-help noarch 2.10.0-1.fc30 @updates 61 M libmypaint x86_64 1.4.0-1.fc30 @updates 721 k mypaint-brushes noarch 1.3.0-3.fc30 @fedora 3.3 M [...] Removed: gimp-2:2.10.14-1.module_f30+6995+c35e2138.x86_64 gimp-help-de-2.10.0-1.fc30.noarch gimp-help-2.10.0-1.fc30.noarch libmypaint-1.4.0-1.fc30.x86_64 mypaint-brushes-1.3.0-3.fc30.noarch Fertig. [root@eve ]# dnf erase test problems with modular dependencies: Problem 1: conflicting requests - nothing provides module(platform:f31) needed by module gimp:2.10:3120191106095052:f636be4b-0.x86_64 Problem 2: conflicting requests - nothing provides module(platform:f31) needed by module meson:latest:3120191009081836:dc56099c-0.x86_64 Problem 3: conflicting requests - nothing provides module(platform:f31) needed by module ninja:latest:3120190304180949:f636be4b-0.x86_64 (1 A.M. here) good night, Marius ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: python3 entry_points console scripts packaging question
On Wed, Nov 27, 2019 at 05:11:37PM +0100, Dominique Martinet wrote:
> Miro Hrončok wrote on Wed, Nov 27, 2019 at 04:32:27PM +0100:
...snip...
> > And in Fedora, when you ahve both of those, it also means that
> > /usr/bin/python3 is Python 3.8.
>
> Ok, I thought it was just much less likely but it would also fail on
> upgrade, good to know.
>
>
> > However, this might not be the case for EPELs.
>
> Yes, they have python36-setuptools and python34-setuptools at the same
> time right now, and the packages do not conflict in any way.
>
> > The easiest way to ensure a specific shebang is:
> >
> >%global __python3 /usr/bin/python%{python3_version}
>
> Thanks, I will add that for our EPEL builds only.
Just to note, the python34 stack in epel7 is the 'old' one.
Everyone should if at all possible use the 3.6 stack now.
kevin
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Reproducible builds/bootstrap
On Wed, Nov 27, 2019 at 12:18 PM Neal Gompa wrote: > > On Wed, Nov 27, 2019 at 2:12 PM Chris Murphy wrote: > > The order of work needed: > > A. Upstream squashfs needs zstd support merged. There's patches > > Fedora's squashfs-tools are carrying that add this support. But it's > > probably fair to say this is for testing purposes, because upstream > > squashfs may have a different implementation in mind. I'm not sure of > > the status of this. > > squashfs-tools v4.4 has it included. The project moved to GitHub last > year: https://github.com/plougher/squashfs-tools Ahh yes it does, cool. And the change log shows reproducible builds support as well. > > > B. Koji needs to learn about existing support for plain squashfs images in > > Lorax > > https://pagure.io/koji/issue/1622 > > C. Releng needs to update build scripts to create plain squashfs images > > https://pagure.io/releng/issue/8646 > > livecd-tools probably needs that too... It might need logic to handle a plain squashfs image, yes. I think right now it expects to find a nested ext4. > > > D. Releng needs to decide whether to use zstd instead of xz, and then > > koji needs to support it, but before that A. above must happen. > > https://pagure.io/releng/issue/8581 > > > > I floated this idea to the Btrfs list. The discussion explores Btrfs > > and alternatives. A Btrfs approach is more work and coordination, flat > > out. But also offers more features for free: always on metadata and > > data checksumming could obviate the slow monolithic md5 ISO media > > checker; simple, consistent, transparent overlay for LiveOS (either > > transient in-memory, or persistent on-drive), seed/sprout fast > > replication option. All of that support is in-kernel so you don't need > > a sophisticated initramfs to do such assembly on the client, or > > complicated build system to create such images. There is a lot of > > *other* work to get there, but then I think it's a lot saner, less > > fragile, and a lot more consumable across distributions. Could that be > > mimicked with plain squashfs on dm-verity? Sure. And that's also > > mentioned in this thread. > > https://lore.kernel.org/linux-btrfs/CAJCQCtTPwQnzwkpk=4zszxfwtc7hymyetxp-9xuu_tsvotw...@mail.gmail.com/ > > > > I'd love to explore using Btrfs for doing it. I have no idea how to > get started with that... Before Btrfs specific, I'd ask how much compression configurability is needed in the compose system and where? That relates to plain squashfs images as well as hypothetical Btrfs images. Is there any advantage to having Rawhide use zstd:3 since these nightlies are throw away? These would be much faster to create and use than xz or zstd:16, but the ISO size would be a lot bigger, maybe 25% bigger. And then for branched nightlies, RCs, and releases, use zstd:16 or even zstd:19? Could the granularity be compress=low,medium,high? And that is then translated by lmc or even the installer, into the specific level numbers? This is in effect the question I'm posing here: https://pagure.io/releng/issue/8581#comment-613760 Btrfs specifically, you'd probably want the installer to learn how to enable Btrfs compression, at least in kickstarts, so that it's possible to create an ISO with a highly compressed Btrfs rootfs image rather than nesting it in squashfs. And then that support has to go all the way up: lorax, lmc, kojis - just like the plain squashfs feature. Next, create a Btrfs spin predicated on exactly cloning either Fedora Workstation or Silverblue. The two differences would be: ISO contains a Btrfs rootfs, and the installer default/autopartitioning uses Btrfs. The first instance of such a spin would make Btrfs almost incidental and pointless, but from there it could be tweeked in straightforward fashion to take advantage of Btrfs specific things. And beyond that I'd say we need a separate thread. :-D I just thought of a cute wrench to just cavalierly throw in the general direction of all that I just wrote: What if this future image isn't based on ISO? What if it assumes it's going to be used only for USB sticks and PXE? Do things get simper and more reliable? At what expense? And what if it assumes Fedora CoreOS as the base? Hmm... -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora rawhide compose report: 20191127.n.0 changes
OLD: Fedora-Rawhide-20191126.n.1 NEW: Fedora-Rawhide-20191127.n.0 = SUMMARY = Added images:3 Dropped images: 1 Added packages: 8 Dropped packages:0 Upgraded packages: 89 Downgraded packages: 122 Size of added packages: 770.65 MiB Size of dropped packages:0 B Size of upgraded packages: 2.86 GiB Size of downgraded packages: 904.44 MiB Size change of upgraded packages: 20.74 MiB Size change of downgraded packages: 354.66 MiB = ADDED IMAGES = Image: Cloud_Base vmdk ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20191127.n.0.ppc64le.vmdk Image: Cloud_Base raw-xz ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20191127.n.0.ppc64le.raw.xz Image: Cloud_Base qcow2 ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20191127.n.0.ppc64le.qcow2 = DROPPED IMAGES = Image: Workstation live ppc64le Path: Workstation/ppc64le/iso/Fedora-Workstation-Live-ppc64le-Rawhide-20191126.n.1.iso = ADDED PACKAGES = Package: eclipse-1:4.13-5.module_f32+7107+10e06045 Summary: An open, extensible IDE RPMs:eclipse-equinox-osgi eclipse-jdt eclipse-p2-discovery eclipse-pde eclipse-platform eclipse-swt Size:643.17 MiB Package: eclipse-ecf-3.14.5-3.module_f32+6792+7663b3b5 Summary: Eclipse Communication Framework (ECF) Eclipse plug-in RPMs:eclipse-ecf-core eclipse-ecf-runtime eclipse-ecf-sdk Size:4.50 MiB Package: eclipse-emf-2.19.0-1.module_f32+6792+7663b3b5 Summary: EMF and XSD Eclipse plug-ins RPMs:eclipse-emf-core eclipse-emf-runtime eclipse-emf-sdk eclipse-emf-xsd Size:14.90 MiB Package: python-stompest-2.3.0-1.20191018git715f358.fc32 Summary: STOMP library for Python including a synchronous client RPMs:python3-stompest python3-stompest-twisted Size:151.25 KiB Package: python39-3.9.0~a1-1.fc32 Summary: Version 3.9 of the Python interpreter RPMs:python39 Size:106.89 MiB Package: rust-lexical-core-0.6.2-1.fc32 Summary: Lexical, to- and from-string conversion routines RPMs:rust-lexical-core+arrayvec-devel rust-lexical-core+correct-devel rust-lexical-core+default-devel rust-lexical-core+dtoa-devel rust-lexical-core+grisu3-devel rust-lexical-core+noinline-devel rust-lexical-core+radix-devel rust-lexical-core+rounding-devel rust-lexical-core+ryu-devel rust-lexical-core+std-devel rust-lexical-core+table-devel rust-lexical-core+trim_floats-devel rust-lexical-core+unchecked_index-devel rust-lexical-core-devel Size:460.02 KiB Package: rust-lexical-core0.4-0.4.6-1.fc32 Summary: Lexical, to- and from-string conversion routines RPMs:rust-lexical-core0.4+arrayvec-devel rust-lexical-core0.4+correct-devel rust-lexical-core0.4+default-devel rust-lexical-core0.4+dtoa-devel rust-lexical-core0.4+grisu3-devel rust-lexical-core0.4+radix-devel rust-lexical-core0.4+rounding-devel rust-lexical-core0.4+ryu-devel rust-lexical-core0.4+std-devel rust-lexical-core0.4+table-devel rust-lexical-core0.4+trim_floats-devel rust-lexical-core0.4+unchecked_index-devel rust-lexical-core0.4-devel Size:447.88 KiB Package: rust-nom4-4.2.3-1.fc32 Summary: Byte-oriented, zero-copy, parser combinators library RPMs:rust-nom4+alloc-devel rust-nom4+default-devel rust-nom4+lazy_static-devel rust-nom4+regex-devel rust-nom4+regexp-devel rust-nom4+regexp_macros-devel rust-nom4+std-devel rust-nom4+verbose-errors-devel rust-nom4-devel Size:159.43 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: ImageMagick-1:6.9.10.75-1.fc32 Old package: ImageMagick-1:6.9.10.67-1.fc32 Summary: An X application for displaying and manipulating images RPMs: ImageMagick ImageMagick-c++ ImageMagick-c++-devel ImageMagick-devel ImageMagick-djvu ImageMagick-doc ImageMagick-libs ImageMagick-perl Size: 39.87 MiB Size change: -21.74 KiB Changelog: * Tue Nov 26 2019 Michael Cronenworth - 1:6.9.10.75-1 - Update to 6.9.10.75 Package: Thunar-1.8.11-1.fc32 Old package: Thunar-1.8.9-2.fc32 Summary: Thunar File Manager RPMs: Thunar Thunar-devel Thunar-docs Size: 10.09 MiB Size change: 31.31 KiB Changelog: * Tue Nov 26 2019 Kevin Fenzi - 1.8.11-1 - Update to 1.8.11. Fixes bug #1775329 Package: args4j-2.33-7.module_f32+7107+10e06045 Old package: args4j-2.33-7.module_f32+7102+8b1132d5 Summary: Java command line arguments parser RPMs: args4j args4j-javadoc args4j-parent args4j-tools Size: 291.75 KiB Size change: 215 B Package: bind-32:9.11.13-2.fc32 Old package: bind-32:9.11.13-1.fc32 Summary: The Berkeley Internet Name Domain (BIND) DNS (Domain Name System) server RPMs: bind bind-chroot bind-devel bind-dlz-bdb bind-dlz-filesystem bind-dlz-ldap bind-dlz-mysql bind-dlz-mysqldyn bind-dlz-sqlite3 bind-dnssec-utils bind-libs bind-libs-lite bind-license bind-lite-devel bind-pkcs11 bind-pkcs11-devel bind-pkcs11-libs bind-pkcs11-utils bind-sdb bind-sdb-chroot bind-utils python3-bind Size
Fedora-Rawhide-20191127.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 26 of 43 required tests failed, 17 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 99/161 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-Rawhide-20191126.n.1): ID: 489656 Test: x86_64 Server-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/489656 ID: 489657 Test: x86_64 Server-boot-iso install_default **GATING** URL: https://openqa.fedoraproject.org/tests/489657 ID: 489695 Test: x86_64 Everything-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/489695 ID: 489696 Test: x86_64 Everything-boot-iso install_default **GATING** URL: https://openqa.fedoraproject.org/tests/489696 ID: 489742 Test: x86_64 universal install_kickstart_user_creation **GATING** URL: https://openqa.fedoraproject.org/tests/489742 ID: 489752 Test: x86_64 universal install_kickstart_firewall_disabled **GATING** URL: https://openqa.fedoraproject.org/tests/489752 ID: 489781 Test: x86_64 universal install_mirrorlist_graphical **GATING** URL: https://openqa.fedoraproject.org/tests/489781 ID: 489796 Test: x86_64 universal install_kickstart_hdd URL: https://openqa.fedoraproject.org/tests/489796 ID: 489816 Test: x86_64 universal install_kickstart_firewall_configured **GATING** URL: https://openqa.fedoraproject.org/tests/489816 ID: 489817 Test: x86_64 universal install_kickstart_nfs URL: https://openqa.fedoraproject.org/tests/489817 Old failures (same test failed in Fedora-Rawhide-20191126.n.1): ID: 489660 Test: x86_64 Server-dvd-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/489660 ID: 489665 Test: x86_64 Server-dvd-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/489665 ID: 489682 Test: x86_64 Server-dvd-iso install_repository_hd_variation URL: https://openqa.fedoraproject.org/tests/489682 ID: 489683 Test: x86_64 Server-dvd-iso install_vnc_server URL: https://openqa.fedoraproject.org/tests/489683 ID: 489689 Test: x86_64 Server-dvd-iso install_vncconnect_server URL: https://openqa.fedoraproject.org/tests/489689 ID: 489697 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/489697 ID: 489698 Test: x86_64 Workstation-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/489698 ID: 489699 Test: x86_64 Workstation-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/489699 ID: 489712 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/489712 ID: 489713 Test: x86_64 KDE-live-iso install_no_user **GATING** URL: https://openqa.fedoraproject.org/tests/489713 ID: 489714 Test: x86_64 KDE-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/489714 ID: 489715 Test: x86_64 KDE-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/489715 ID: 489728 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/489728 ID: 489730 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/489730 ID: 489731 Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/489731 ID: 489740 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud **GATING** URL: https://openqa.fedoraproject.org/tests/489740 ID: 489741 Test: x86_64 universal support_server URL: https://openqa.fedoraproject.org/tests/489741 ID: 489743 Test: x86_64 universal install_scsi_updates_img **GATING** URL: https://openqa.fedoraproject.org/tests/489743 ID: 489744 Test: x86_64 universal install_multi **GATING** URL: https://openqa.fedoraproject.org/tests/489744 ID: 489745 Test: x86_64 universal install_multi@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/489745 ID: 489746 Test: x86_64 universal install_no_swap URL: https://openqa.fedoraproject.org/tests/489746 ID: 489747 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/489747 ID: 489748 Test: x86_64 universal install_blivet_ext3 URL: https://openqa.fedoraproject.org/tests/489748 ID: 489749 Test: x86_64 universal install_blivet_xfs URL: https://openqa.fedoraproject.org/tests/489749 ID: 489750 Test: x86_64 universal install_blivet_software_raid URL: https://openqa.fedoraproject.org/tests/489750 ID: 489751 Test: x86_64 universal install_simple_encrypted URL: https://openqa.fedoraproject.org/tests/489751 ID: 489753 Test: x86_64 universal install_pxeboot URL: https://openqa.fedoraproject.org/tests/489753 ID: 489754 Test: x86_64 universal install_pxeboot@uefi URL:
Re: bugs for non-EOL releases are being closed as EOL by a script
The bugzilla EOL script is running with correct input now. I just published a Community Blog post[1] that describes what happened and how I'll prevent it from happening again. Thank you to everyone who let me know about the error quickly. I apologize for the confusion and extra work this created. [1] https://communityblog.fedoraproject.org/accidental-eol-bug-closures/ -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Reproducible builds/bootstrap
On Wed, Nov 27, 2019 at 2:12 PM Chris Murphy wrote: > > On Wed, Nov 27, 2019 at 7:17 AM Pablo Greco wrote: > > > > I'm starting to work on a project to make Fedora fully reproducible and > > bootstrappable from scratch. > > I know it is a long term plan and still working on the steps, but it would > > be good to know the current status, if there is an internal interest in > > this, if someone is already working (or planning to). > > One small cog in the wheel that affects reproducibility in images is > file systems. There are currently two parts to this when creating > Fedora images: the rootfs is on ext4, and ext4 creation and writes are > non-deterministic; that ext4 is then nested into a squashfs image > using xz. Parallelized xz is non-deterministic, where parallelize zstd > is reproducible, as I understand it. But that should be confirmed. > > The order of work needed: > A. Upstream squashfs needs zstd support merged. There's patches > Fedora's squashfs-tools are carrying that add this support. But it's > probably fair to say this is for testing purposes, because upstream > squashfs may have a different implementation in mind. I'm not sure of > the status of this. squashfs-tools v4.4 has it included. The project moved to GitHub last year: https://github.com/plougher/squashfs-tools > B. Koji needs to learn about existing support for plain squashfs images in > Lorax > https://pagure.io/koji/issue/1622 > C. Releng needs to update build scripts to create plain squashfs images > https://pagure.io/releng/issue/8646 livecd-tools probably needs that too... > D. Releng needs to decide whether to use zstd instead of xz, and then > koji needs to support it, but before that A. above must happen. > https://pagure.io/releng/issue/8581 > > I floated this idea to the Btrfs list. The discussion explores Btrfs > and alternatives. A Btrfs approach is more work and coordination, flat > out. But also offers more features for free: always on metadata and > data checksumming could obviate the slow monolithic md5 ISO media > checker; simple, consistent, transparent overlay for LiveOS (either > transient in-memory, or persistent on-drive), seed/sprout fast > replication option. All of that support is in-kernel so you don't need > a sophisticated initramfs to do such assembly on the client, or > complicated build system to create such images. There is a lot of > *other* work to get there, but then I think it's a lot saner, less > fragile, and a lot more consumable across distributions. Could that be > mimicked with plain squashfs on dm-verity? Sure. And that's also > mentioned in this thread. > https://lore.kernel.org/linux-btrfs/CAJCQCtTPwQnzwkpk=4zszxfwtc7hymyetxp-9xuu_tsvotw...@mail.gmail.com/ > I'd love to explore using Btrfs for doing it. I have no idea how to get started with that... -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Reproducible builds/bootstrap
On Wed, Nov 27, 2019 at 7:17 AM Pablo Greco wrote: > > I'm starting to work on a project to make Fedora fully reproducible and > bootstrappable from scratch. > I know it is a long term plan and still working on the steps, but it would be > good to know the current status, if there is an internal interest in this, if > someone is already working (or planning to). One small cog in the wheel that affects reproducibility in images is file systems. There are currently two parts to this when creating Fedora images: the rootfs is on ext4, and ext4 creation and writes are non-deterministic; that ext4 is then nested into a squashfs image using xz. Parallelized xz is non-deterministic, where parallelize zstd is reproducible, as I understand it. But that should be confirmed. The order of work needed: A. Upstream squashfs needs zstd support merged. There's patches Fedora's squashfs-tools are carrying that add this support. But it's probably fair to say this is for testing purposes, because upstream squashfs may have a different implementation in mind. I'm not sure of the status of this. B. Koji needs to learn about existing support for plain squashfs images in Lorax https://pagure.io/koji/issue/1622 C. Releng needs to update build scripts to create plain squashfs images https://pagure.io/releng/issue/8646 D. Releng needs to decide whether to use zstd instead of xz, and then koji needs to support it, but before that A. above must happen. https://pagure.io/releng/issue/8581 I floated this idea to the Btrfs list. The discussion explores Btrfs and alternatives. A Btrfs approach is more work and coordination, flat out. But also offers more features for free: always on metadata and data checksumming could obviate the slow monolithic md5 ISO media checker; simple, consistent, transparent overlay for LiveOS (either transient in-memory, or persistent on-drive), seed/sprout fast replication option. All of that support is in-kernel so you don't need a sophisticated initramfs to do such assembly on the client, or complicated build system to create such images. There is a lot of *other* work to get there, but then I think it's a lot saner, less fragile, and a lot more consumable across distributions. Could that be mimicked with plain squashfs on dm-verity? Sure. And that's also mentioned in this thread. https://lore.kernel.org/linux-btrfs/CAJCQCtTPwQnzwkpk=4zszxfwtc7hymyetxp-9xuu_tsvotw...@mail.gmail.com/ -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Test-Announce] Fedora 32 Rawhide 20191127.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 32 Rawhide 20191127.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: pungi - 20191122.n.0: pungi-4.1.40-3.fc32.src, 20191127.n.0: pungi-4.1.40-4.fc32.src Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/32 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20191127.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20191127.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20191127.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20191127.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20191127.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20191127.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20191127.n.0_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
PSA: please stop manually titling Bodhi updates
Hey folks! Since the new Bodhi UI rolled out recently I've noticed a big uptick in updates where the update creator manually set the update title. This is a problem because in every single case so far, the manually- created title is worse than an auto-generated title would have been. If you just leave that box blank, Bodhi will set the update title to be the NVR(s) of the package(s) in the update, just like it always has. But the new UI seems to really encourage people to override this and write a title manually...and people are picking titles that are worse. e.g. https://bodhi.fedoraproject.org/updates/FEDORA-2019-edc1551b22 where the auto-generated title would have been "container-selinux-2.123.0-1.fc31" but the update author manually set it to "container-selinux", which is clearly much less useful. I've filed a Bodhi issue asking for the UI to be tweaked again to make manual titling less attractive: https://github.com/fedora-infra/bodhi/issues/3809 but until then, can I just ask folks to resist the temptation, unless you really really have a good reason to override the auto-generated title? You don't *have* to set this field, even though the UI kinda looks like you do. Thanks! -- 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 Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Is 50+ RPM Subpackages too extreme?
Once upon a time, Matej Grabovsky said: > Can you please explain what you mean? What are the alternatives if > there really are over 5000 packages in CTAN? Why does all of CTAN need to go into one source RPM? -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: bugs for non-EOL releases are being closed as EOL by a script
Update: all of the accidentally closed bugs should now be unclosed. I know what went wrong (spoiler alert: human error) and even better, I know how to help guard against this in the future. I am going to implement that and then re-run the script with the correct input. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: python3 entry_points console scripts packaging question
Miro Hrončok wrote on Wed, Nov 27, 2019 at 04:32:27PM +0100:
> If I understand this properly, your package requires (in Fedora):
>
> - /usr/bin/python3
> - python3.8dist(setuptools)
Yes, on Fedora 31 the current requires for clustershell (to continue
with that example) contain these:
$ rpm -q --requires python3-clustershell
/usr/bin/python3
python(abi) = 3.7
python3-PyYAML
python3-setuptools
python3.7dist(pyyaml)
python3.7dist(setuptools)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PartialHardlinkSets) <= 4.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsZstd) <= 5.4.18-1
> And in Fedora, when you ahve both of those, it also means that
> /usr/bin/python3 is Python 3.8.
Ok, I thought it was just much less likely but it would also fail on
upgrade, good to know.
> However, this might not be the case for EPELs.
Yes, they have python36-setuptools and python34-setuptools at the same
time right now, and the packages do not conflict in any way.
> The easiest way to ensure a specific shebang is:
>
>%global __python3 /usr/bin/python%{python3_version}
Thanks, I will add that for our EPEL builds only.
--
Dominique
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Reproducible builds/bootstrap
On Wed, Nov 27, 2019 at 09:34:23AM -0500, Neal Gompa wrote: > As far as bootstrapping from scratch, I believe Richard W. M. Jones > and David Abdurachmanov went through this process for Fedora RISC-V. > They may have more to say about how that was done... It depends exactly how far "from scratch" you want to go. For RISC-V because there were no .riscv64.rpm packages to start with, we had to do a full bootstrap entirely from nothing, and that's pretty complicated. I saved the instructions here: https://github.com/rwmjones/fedora-riscv-bootstrap However I guess for reproducible builds you don't mind starting from the existing (non-reproducible) RPMs, in which case it's basically the same as a Fedora Mass Rebuild, just schedule the packages to be built in your "shadow" Koji in alphabetical order. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: python3 entry_points console scripts packaging question
On 27. 11. 19 16:20, Dominique Martinet wrote:
Hi,
Some context first, skip to the end if you want.
We have a few python packages at $work with setuptools entry_points
console scripts - basically setuptools creates a small python script for
you loading a module and calling the function you specified.
For example, clustershell here defines four commands (clubak cluset
clush and nodeset) here:
https://github.com/cea-hpc/clustershell/blob/master/setup.py#L57
Setuptool embeds whatever python command was executed for running
setup.py at the start of the script, so if the command used in the spec
file was %py3_install as per the guidelines or even %{__python3}
setup.py something, you will get a #!/usr/bin/python3 shebang in your
scripts.
On the other hand, the script depends on what just got installed in
/usr/lib/python3.x/site-packages, so if python3 gets a major upgrade and
the /usr/bin/python3 link changes, the script will stop working
complaining that whatever it tried to import does not exist, while in
reality everything is still there, works if you run it with the right
python version, and the rpm requires ensure this properly.
For packages in fedora this doesn't matter as much as there is a python
mass rebuild when this happens, but I'm not sure it happens with epel
version bump, and it certainly doesn't happen for our internal packages
(hence this message!)
Now for the big question, should we try using `python%{python3_version}`
or fixing the link in scripts somehow for our rpms ?
Can anyone think of a cleaner way?
Another idea that just came to mind would be to try to write in the spec
file that we require /usr/bin/python3 to point to a specific version, so
that at least it fails to upgrade, but that doesn't sound much better
and I wouldn't know how to do that anyway.
If I understand this properly, your package requires (in Fedora):
- /usr/bin/python3
- python3.8dist(setuptools)
And in Fedora, when you ahve both of those, it also means that /usr/bin/python3
is Python 3.8.
However, this might not be the case for EPELs. The easiest way to ensure a
specific shebang is:
%global __python3 /usr/bin/python%{python3_version}
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
python3 entry_points console scripts packaging question
Hi,
Some context first, skip to the end if you want.
We have a few python packages at $work with setuptools entry_points
console scripts - basically setuptools creates a small python script for
you loading a module and calling the function you specified.
For example, clustershell here defines four commands (clubak cluset
clush and nodeset) here:
https://github.com/cea-hpc/clustershell/blob/master/setup.py#L57
Setuptool embeds whatever python command was executed for running
setup.py at the start of the script, so if the command used in the spec
file was %py3_install as per the guidelines or even %{__python3}
setup.py something, you will get a #!/usr/bin/python3 shebang in your
scripts.
On the other hand, the script depends on what just got installed in
/usr/lib/python3.x/site-packages, so if python3 gets a major upgrade and
the /usr/bin/python3 link changes, the script will stop working
complaining that whatever it tried to import does not exist, while in
reality everything is still there, works if you run it with the right
python version, and the rpm requires ensure this properly.
For packages in fedora this doesn't matter as much as there is a python
mass rebuild when this happens, but I'm not sure it happens with epel
version bump, and it certainly doesn't happen for our internal packages
(hence this message!)
Now for the big question, should we try using `python%{python3_version}`
or fixing the link in scripts somehow for our rpms ?
Can anyone think of a cleaner way?
Another idea that just came to mind would be to try to write in the spec
file that we require /usr/bin/python3 to point to a specific version, so
that at least it fails to upgrade, but that doesn't sound much better
and I wouldn't know how to do that anyway.
Thanks,
--
Dominique
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: debuginfod non-standard-uid and cache permissions
Hi - > These are all done deliberately through the following constructs in the spec > file: > > In %pre to create the debuginfod user: > >getent group debuginfod >/dev/null || groupadd -r debuginfod >getent passwd debuginfod >/dev/null || \ >useradd -r -g debuginfod -d /var/cache/debuginfod -s /sbin/nologin \ >-c "elfutils debuginfo server" debuginfod >exit 0 These are all intended to use the preferred "dynamic allocation" model: https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/ - FChE ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Is 50+ RPM Subpackages too extreme?
On Wed, Nov 27, 2019 at 02:33:15PM +, Richard W.M. Jones wrote: > I also maintain projects with a large (though not this large) number > of subpackages, eg: nbdkit has 25+: > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1417304 [...] > libvirt and qemu have a very large number too: > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1411277 > https://koji.fedoraproject.org/koji/buildinfo?buildID=1415318 I forgot to mention another thing here. nbdkit, libvirt and qemu also have metapackages which pull in a "good selection" of the subpackages, which is ideal for users who don't want to sort through all of them, or want to deploy those in particular scenarios. eg. "qemu" pulls in all subpackages of qemu. "nbdkit" pulls in the server and the basic plugins, but not the esoteric plugins with complex dependencies. "libvirt-client" pulls in the libvirt client libraries and tools but not the server stuff. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: bugs for non-EOL releases are being closed as EOL by a script
On Wed, Nov 27, 2019 at 9:26 AM Dominik 'Rathann' Mierzejewski wrote: > > Ben, stop the script and fix it, please. > I stopped it as soon as I saw Richard's email. I'm going through the ~150 bugs that were closed and reopening them as appropriate. Please be patient, as it will take a little bit to work through them. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: bugs for non-EOL releases are being closed as EOL by a script
On Wed, Nov 27, 2019 at 3:27 PM Dominik 'Rathann' Mierzejewski wrote: > > On Wednesday, 27 November 2019 at 15:22, Richard W.M. Jones wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=1774713#c13 > > Not only reviews: > https://bugzilla.redhat.com/show_bug.cgi?id=1777310 > https://bugzilla.redhat.com/show_bug.cgi?id=1763148 > > Ben, stop the script and fix it, please. This has happened for a few of my open bugs as well (one of them was opened for "rawhide" only two days ago, so something is definitely broken). Fabio > Regards, > Dominik > -- > Fedora https://getfedora.org | RPM Fusion 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 > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Reproducible builds/bootstrap
On Wed, Nov 27, 2019 at 9:17 AM Pablo Greco wrote: > > I'm starting to work on a project to make Fedora fully reproducible and > bootstrappable from scratch. > I know it is a long term plan and still working on the steps, but it would be > good to know the current status, if there is an internal interest in this, if > someone is already working (or planning to). > I believe Dennis was last interested in this recently, though the last time it was seriously worked on was when Dhiru Kholia was doing this in Fedora 23 for the Reproducible Builds project. Since then, RPM has gained a number of features for supporting reproducibility, some of them from our friends at SUSE who have been pushing this hard for openSUSE itself. I've done a small bit of work here and there for this, too. The current state of things is that we could relatively quickly start verifying the reproducibility of Fedora by running a shadow Koji that has the following flags set in the target tag where builds occur: %clamp_mtime_to_source_date_epoch 1 %use_source_date_epoch_as_buildtime 1 %_buildhost koji.fedoraproject.org We already set the following in redhat-rpm-config[0]: %source_date_epoch_from_changelog 1 It would likely be quite safe for us to add "%clamp_mtime_to_source_date_epoch 1" to redhat-rpm-config without seriously inhibiting things. That would just leave a shadow Koji to only need "%use_source_date_epoch_as_buildtime" and "%_buildhost" set. These settings should never be forcibly set in redhat-rpm-config, as they impact third-party packagers and their workflows. Thankfully, Koji supports having macros set on build target tags directly since Koji 1.18[1]. As far as bootstrapping from scratch, I believe Richard W. M. Jones and David Abdurachmanov went through this process for Fedora RISC-V. They may have more to say about how that was done... [0]: https://src.fedoraproject.org/rpms/redhat-rpm-config/c/86aae600e62fadc18760d95d1fddd323cf9e9a86 [1]: https://docs.pagure.org/koji/release_notes_1.18/#system-changes -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Is 50+ RPM Subpackages too extreme?
On Tue, Nov 26, 2019 at 08:49:31PM -0500, Chris wrote: > Hi guys, > > I just wanted to poll you for some advice. My notification tool I maintain > supports more than 50+ services now, but the only package isolation I do > within 2 RPMs. One for the actual CLI (for admin's who want to use it) and > the other is for the backend library (for Devs). I only ask because each > supported service is very modular. collectd seems comparable. It has countless subpackages each for a different service: https://koji.fedoraproject.org/koji/buildinfo?buildID=1406178 I also maintain projects with a large (though not this large) number of subpackages, eg: nbdkit has 25+: https://koji.fedoraproject.org/koji/buildinfo?buildID=1417304 libguestfs has a similar number: https://koji.fedoraproject.org/koji/buildinfo?buildID=1417302 libvirt and qemu have a very large number too: https://koji.fedoraproject.org/koji/buildinfo?buildID=1411277 https://koji.fedoraproject.org/koji/buildinfo?buildID=1415318 As long as the packages have a purpose I see no reason to stop packaging things discretely like this. [...] > Is it advisable to go this route? I presume there is no easy way to > transition without breaking users existing setup? I don't know what the d/l > stats are; so there may not be a large enough audience to even need to > worry about this? > > What are your thoughts and/or advice? As long as the packaging is sensible, go for it. It's a good way to reduce the number of dependencies a package pulls in. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Package review bug against Rawhide was just closed as EOL by a script
On Wed, Nov 27, 2019 at 9:23 AM Richard W.M. Jones wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=1774713#c13 > Whoops! Looks like part of my filter didn't apply. Thankfully, only 150 bugs were updated. Thanks for catching that quickly. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
bugs for non-EOL releases are being closed as EOL by a script
On Wednesday, 27 November 2019 at 15:22, Richard W.M. Jones wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=1774713#c13 Not only reviews: https://bugzilla.redhat.com/show_bug.cgi?id=1777310 https://bugzilla.redhat.com/show_bug.cgi?id=1763148 Ben, stop the script and fix it, please. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion 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 Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Package review bug against Rawhide was just closed as EOL by a script
https://bugzilla.redhat.com/show_bug.cgi?id=1774713#c13 -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Reproducible builds/bootstrap
I'm starting to work on a project to make Fedora fully reproducible and bootstrappable from scratch. I know it is a long term plan and still working on the steps, but it would be good to know the current status, if there is an internal interest in this, if someone is already working (or planning to). Thanks for the info. Pablo ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
debuginfod non-standard-uid and cache permissions
Hi fedora devel list,
The new elfutils upstream comes with a debuginfod server which we want
packaged (as a sub-package) for fedora. Testing looks good and
everything seems to work, but rpmlint flags a couple of issues that I
don't think should be real issues. Could someone help me understand why
rpmlint seems unhappy with:
elfutils-debuginfod.x86_64: W: non-standard-uid /var/cache/debuginfod
debuginfod
elfutils-debuginfod.x86_64: W: non-standard-gid /var/cache/debuginfod
debuginfod
elfutils-debuginfod.x86_64: E: non-standard-dir-perm /var/cache/debuginfod
700
elfutils-debuginfod.x86_64: W: non-standard-uid
/var/cache/debuginfod/debuginfod.sqlite debuginfod
elfutils-debuginfod.x86_64: W: non-standard-gid
/var/cache/debuginfod/debuginfod.sqlite debuginfod
elfutils-debuginfod.x86_64: E: non-readable
/var/cache/debuginfod/debuginfod.sqlite 600
elfutils-debuginfod.x86_64: E: zero-length
/var/cache/debuginfod/debuginfod.sqlite
These are all done deliberately through the following constructs in the spec
file:
In %pre to create the debuginfod user:
getent group debuginfod >/dev/null || groupadd -r debuginfod
getent passwd debuginfod >/dev/null || \
useradd -r -g debuginfod -d /var/cache/debuginfod -s /sbin/nologin \
-c "elfutils debuginfo server" debuginfod
exit 0
In %install to create the dir/file artifacts:
mkdir -p ${RPM_BUILD_ROOT}%{_localstatedir}/cache/debuginfod
touch ${RPM_BUILD_ROOT}%{_localstatedir}/cache/debuginfod/debuginfod.sqlite
And in %files to install them with the right permissions:
%dir %attr(0700,debuginfod,debuginfod) %{_localstatedir}/cache/debuginfod
%verify(not md5 size mtime) %attr(0600,debuginfod,debuginfod)
%{_localstatedir}/cache/debuginfod/debuginfod.sqlite
Should anything be done differently or does any of that violate
(rpmlint) policy somehow?
Thanks,
Mark
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Planned Outage - Taskotron and ResultsDB - 2019-11-26 19:00 UTC
I hit a hiccup during the upgrade but everything should be back to normal and upgraded. If you notice anything not working correctly, please let us know in #fedora-admin or #fedora-qa. Thanks, Tim On Tue, 26 Nov 2019 11:58:36 -0700 Tim Flink wrote: > Apologies for the last minute nature of this outage, the details > behind the upgrade were under debate and we didn't want to announce a > time until we were sure about what was going to happen when. > > Seeing as the machines are running F29, they need to be upgraded as > it's going EOL today. > > Tim > > > > > There will be an outage starting at 2019-11-26 21:00 UTC, which will > last approximately 3 hours. > > To convert UTC to your local time, take a look at > https://fedoraproject.org/wiki/UTCHowto or run: > > date -d '2019-11-26 19:00 UTC' > > Reason for outage: > > We will be upgrading the servers which host Taskotron and ResultsDB to > newer versions of Fedora. > > Affected Services: > > Taskotron, ResultsDB and anything which uses ResultsDB as a data > source (Bodhi, gating etc.) > > Ticket Link: > > https://pagure.io/fedora-infrastructure/issue/8420 > > Contact Information: > > Please join #fedora-admin in irc.freenode.net or add comments to the > ticket for this outage above. pgp0vHeRKl7Wq.pgp Description: OpenPGP digital signature ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Planned Outage - Taskotron and ResultsDB - 2019-11-26 19:00 UTC
Apologies for the last minute nature of this outage, the details behind the upgrade were under debate and we didn't want to announce a time until we were sure about what was going to happen when. Seeing as the machines are running F29, they need to be upgraded as it's going EOL today. Tim There will be an outage starting at 2019-11-26 21:00 UTC, which will last approximately 3 hours. To convert UTC to your local time, take a look at https://fedoraproject.org/wiki/UTCHowto or run: date -d '2019-11-26 19:00 UTC' Reason for outage: We will be upgrading the servers which host Taskotron and ResultsDB to newer versions of Fedora. Affected Services: Taskotron, ResultsDB and anything which uses ResultsDB as a data source (Bodhi, gating etc.) Ticket Link: https://pagure.io/fedora-infrastructure/issue/8420 Contact Information: Please join #fedora-admin in irc.freenode.net or add comments to the ticket for this outage above. pgpAIRab4ZYRV.pgp Description: OpenPGP digital signature ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Is 50+ RPM Subpackages too extreme?
On Wed, Nov 27, 2019 at 11:25:25AM +, Ankur Sinha wrote: > On Wed, Nov 27, 2019 10:45:00 +, Ian McInerney wrote: > > Tex isn't really the best example for the insane package numbers (since the > > main Tex system, CTAN, actually does define them as separate packages). It > > would be interesting to know if anyone actually does just install one or two > > rather than all... I know that I usually just install all of them on new > > systems. > > Oh, I almost never install the whole thing. I install whatever packages > I need only, taking advantage of the great packaging work that the > maintainers have put in. Yeah, me too. I usually run latex/xelatex/whatever, read any errors, and just do dnf install -y tex(foobar.sty) as needed. For a handful of required imports this works fine. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Is 50+ RPM Subpackages too extreme?
On Wed, 2019-11-27 at 07:44 +0100, Igor Gnatenko wrote: > No, 50 is perfectly fine. As others mentioned, we have much bigger amount of > them in texlive. Yeah, I also don't really see a problem in making packages more granular. There are many usecaseswhere you want that, such as installation images or minimal cloud images and containers. If packages are not granular, you need to resort to ugly hacks that are hard to maintain if you want to make yourimage smaller. With granular packages you can install only what you really need, no hacks required! > If those are like plugins which may or may not require other packages, I > would split them. And probably put Recommends > in the main package for the most used ones. > > On Wed, Nov 27, 2019, 02:58 Chris wrote: > > Hi guys, > > > > I just wanted to poll you for some advice. My notification tool I maintain > > supports more than 50+ services now, but > > the only package isolation I do within 2 RPMs. One for the actual CLI (for > > admin's who want to use it) and the > > other is for the backend library (for Devs). I only ask because each > > supported service is very modular. > > > > I kind of like the way nagios-plugins breaks apart it's check_scripts into > > many sub-packages, but 50+ subpackages > > seems a bit extreme... or is it? It certainly seems like a bit of a > > nightmare to maintain; it would be one very > > large .spec file. > > > > You can see the directory structure here on GitHub: > > https://github.com/caronc/apprise > > > > Effectively every single file in "apprise/plugins/Notify*.py" is it's own > > plugin-able module. You can add/remove > > content into here and the tool adapts. Thus the sub-packages would only > > include 1 file per RPM. > > > > Is it advisable to go this route? I presume there is no easy way to > > transition without breaking users existing > > setup? I don't know what the d/l stats are; so there may not be a large > > enough audience to even need to worry about > > this? > > > > What are your thoughts and/or advice? > > ___ > > > > devel mailing list -- devel@lists.fedoraproject.org > > > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > > > ___devel mailing list -- > devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Is 50+ RPM Subpackages too extreme?
Your reply completely lacks any point. Why is TeX Live the best example of what to avoid when packaging in Fedora? Having 50+ subpackages is perfectly justified once there is a reason why. For TeX Live it is that upstream (CTAN) actually maintains package dependencies and they do add and remove packages from different TeX Live collections, e.g. LaTeX, XeTeX, etc. That means the complete package set is actually generated from upstream metadata to give users freedom to not to install hundreds of MBs of stuff they don't need - as it was previously with teTeX. And also to be automatically synced with upstream. Jindrich On Wed, Nov 27, 2019 at 10:20 AM Nikos Mavrogiannopoulos wrote: > On Wed, Nov 27, 2019 at 4:46 AM Sam Varshavchik > wrote: > > > > Chris writes: > > > > > Hi guys, > > > > > > > > > I just wanted to poll you for some advice. My notification tool I > maintain > > > supports more than 50+ services now, but the only package isolation I > do > > > > You should really count the number of texlive subpackages… > > I think that from the user perspective that's the best example of what > to avoid when packaging in Fedora. > > regards, > Nikos > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Is 50+ RPM Subpackages too extreme?
On Wed, Nov 27, 2019 10:45:00 +, Ian McInerney wrote: > Tex isn't really the best example for the insane package numbers (since the > main Tex system, CTAN, actually does define them as separate packages). It > would be interesting to know if anyone actually does just install one or two > rather than all... I know that I usually just install all of them on new > systems. Oh, I almost never install the whole thing. I install whatever packages I need only, taking advantage of the great packaging work that the maintainers have put in. We have a page here on the NeuroFedora documentation about installing LaTeX on Fedora (please feel free to improve it): https://docs.fedoraproject.org/en-US/neurofedora/latex/ and, I hacked up this script that tries to install the packages needed by a LaTeX project on Fedora: https://github.com/sanjayankur31/100_dotfiles/blob/master/bin/fedora-install-texlive-deps.sh -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Is 50+ RPM Subpackages too extreme?
Le 2019-11-27 11:45, Ian McInerney a écrit : Tex isn't really the best example for the insane package numbers (since the main Tex system, CTAN, actually does define them as separate packages). It would be interesting to know if anyone actually does just install one or two rather than all... I know that I usually just install all of them on new systems. TEX includes things shared with the rest of the system (for example fonts), forcing the users of those things to install a huge TEX blob just to get the subset they need is not a good user experience. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Is 50+ RPM Subpackages too extreme?
Tex isn't really the best example for the insane package numbers (since the main Tex system, CTAN, actually does define them as separate packages). It would be interesting to know if anyone actually does just install one or two rather than all... I know that I usually just install all of them on new systems. -Ian On Wed, Nov 27, 2019 at 10:36 AM Matej Grabovsky wrote: > On Wed, Nov 27, 2019 at 10:20 AM Nikos Mavrogiannopoulos > wrote: > > > > I think that from the user perspective that's the best example of what > > to avoid when packaging in Fedora. > > Can you please explain what you mean? What are the alternatives if > there really are over 5000 packages in CTAN? > > Arch Linux has packaged bundles like texlive-science or texlive-music, > but these seem less usable as individual packages can't be installed. > Moreover, it might be difficult to find which of the bundles includes > the one specific package you need. > > Kind regards, > Matěj Grabovský > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Is 50+ RPM Subpackages too extreme?
On Wed, Nov 27, 2019 at 10:20 AM Nikos Mavrogiannopoulos wrote: > > I think that from the user perspective that's the best example of what > to avoid when packaging in Fedora. Can you please explain what you mean? What are the alternatives if there really are over 5000 packages in CTAN? Arch Linux has packaged bundles like texlive-science or texlive-music, but these seem less usable as individual packages can't be installed. Moreover, it might be difficult to find which of the bundles includes the one specific package you need. Kind regards, Matěj Grabovský ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Test-Announce] Fedora 29 EOL
Hello all, As of the 26th of November 2019, Fedora 29 has reached its end of life for updates and support. No further updates, including security updates, will be available for Fedora 29. Fedora 30 will continue to receive updates until approximately one month after the release of Fedora 32. The maintenance schedule of Fedora releases is documented on the Fedora Project wiki [0]. The Fedora Project wiki also contains instructions [1] on how to upgrade from a previous release of Fedora to a version receiving updates. Mohan Boddu. [0] https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule [2] https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/ ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Is 50+ RPM Subpackages too extreme?
Le 2019-11-27 10:37, Tom Hughes a écrit :
On 27/11/2019 09:30, Nicolas Mailhot via devel wrote:
The clean way to do it is to put the list of things to generate
against in a spec variable, and write the generator logic in a (lua)
rpm macro. That keeps the generation inside the spec instead of moving
some package creation steps outside our the shared and audited build
infra.
How is a file in distgit "outside our the shared and audited build
infra" exactly? The spec file is just a file in distgit after all!
Yes, I misunderstood, as long as the generation logic is done inside the
spec (via inlined macros, or detached files %{load}-ed), the end result
is perfectly fine
What is not fine is when people use an external generator to write a
spec file. And then fed this build output to the build infra. That moves
spec assembly outside the normal managed build process.
Regards,
--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Cloud-31-20191127.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (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 Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Is 50+ RPM Subpackages too extreme?
On 27/11/2019 09:30, Nicolas Mailhot via devel wrote: The clean way to do it is to put the list of things to generate against in a spec variable, and write the generator logic in a (lua) rpm macro. That keeps the generation inside the spec instead of moving some package creation steps outside our the shared and audited build infra. How is a file in distgit "outside our the shared and audited build infra" exactly? The spec file is just a file in distgit after all! The actual list in question is right here: https://src.fedoraproject.org/rpms/lodash/blob/master/f/lodash-modules.txt Obviously I could inline that in the spec file but I fail to see what that does other than make the spec file massive... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Is 50+ RPM Subpackages too extreme?
Le 2019-11-27 07:44, Igor Gnatenko a écrit : No, 50 is perfectly fine. As others mentioned, we have much bigger amount of them in texlive. It's not just about the number of subpackages. Each package you publish will end up as a separate node in the dependency graph. Since functional plugins tend to accumulate dependency links once published (things that need those plugins, and things the plugins need to work), splitting the plugins is a requirement to avoid unmanageable dependency hairballs. The reason upstreams move to a plugin architecture, is precisely to isolate the requirements of each plugin from the requirements of the others Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Is 50+ RPM Subpackages too extreme?
Le 2019-11-27 08:08, Tom Hughes a écrit : On 27/11/2019 01:49, Chris wrote: I kind of like the way nagios-plugins breaks apart it's check_scripts into many sub-packages, but 50+ subpackages seems a bit extreme... or is it? It certainly seems like a bit of a nightmare to maintain; it would be one very large .spec file. If the subpackages are sufficiently identical you can just use lua to programatically generate the relevant spec fragment - see lodash for an example: That’s also how it is done for go packages and in the proposed fonts packaging update. Though it is heavier upstream-agnostic lifting, you may not need this level of abstraction just for 50 packages. https://pagure.io/fonts-rpm-macros/blob/master/f/templates/rpm/spectemplate-fonts-0-simple.spec https://pagure.io/go-rpm-macros/blob/master/f/templates/rpm/spectemplate-go-0-source-minimal.spec It just reads the list of modules from a text file in the distgit repo and generates the spec fragment for each one. The clean way to do it is to put the list of things to generate against in a spec variable, and write the generator logic in a (lua) rpm macro. That keeps the generation inside the spec instead of moving some package creation steps outside our the shared and audited build infra. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Is 50+ RPM Subpackages too extreme?
On Wed, Nov 27, 2019 at 4:46 AM Sam Varshavchik wrote: > > Chris writes: > > > Hi guys, > > > > > > I just wanted to poll you for some advice. My notification tool I maintain > > supports more than 50+ services now, but the only package isolation I do > > You should really count the number of texlive subpackages… I think that from the user perspective that's the best example of what to avoid when packaging in Fedora. regards, Nikos ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Tue, Nov 26, 2019 at 09:53:49AM -0600, Michael Catanzaro wrote: > On Tue, Nov 26, 2019 at 9:35 am, Chris Adams wrote: > >That should be considered a bug IMHO... > > At least for rescue mode, probably yes, but I don't know what to do > about it. Can we make systemd's rescue prompt ask for username and > allow logging in with any user account (goal being to log in to > admin account then 'sudo -i')? Or would there be problems with that? > Clearly it's not designed for that purpose, and it seems > intentional. systemd does not implement user authentication by itself: it just spawns getty/gdm/etc during normal runtime, and sulogin for emergency logins. We generally do not want to re-implement this functionality in systemd. selinux has some special permissions for sulogin, etc. Ideally, sulogin would get the capability to pick an alternative user. util-linux already has the code to select and authenticate users, so it'd be just a question of some design work and rearranging the code. On Tue, Nov 26, 2019 at 09:39:59AM -0700, Chris Murphy wrote: > Mabee systemd-homed is in > a position to solve this by having early enough authentication > capability by rescue.target time that any admin user can login? Actually, it may. Things are confusing here, because systemd-homed is implemented together with changes to how user metadata querying is done: instead of using dbus, a brokerless and much simpler varlink query is used. That last part is what would be relevant to early-boot logins, because less services need to be up to bring up the user session. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
