Need assistance to fix bpy incompatiblity with Python 3.7 for f29+
Due to the incompatibly with bpy (Blender as Python module) and Python 3.7, the interface failed to render as seen on this report: https://bugzilla.redhat.com/show_bug.cgi?id=1631922 Normal solution would be using Python36. Unfortunately, there is no python36-devel or modules to properly rebuild Blender. So I am looking for suggestion and alternative to address that issue. I filed the bug upstream: https://developer.blender.org/T56969 for now. Thanks -- Luya Tshimbalanga Graphic & Web Designer E: l...@fedoraproject.org W: http://www.coolest-storm.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fwd: Weston package
On 9/28/18 8:03 AM, Brian Clark wrote: [02:04:21.928] Loading module '/usr/lib64/libweston-5/x11-backend.so' [02:04:22.373] fatal: failed to create compositor backend [root@d4895acb1694 /]# Are programs in the container allowed to contact the X server? Check for audit messages or try running xdpyinfo in the container. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaning some Java packages
I wouldn't use the word useless. Having the packages is just a quality of life thing. Just like for me as mainly C++ developer; not having Basel or abseil does not make Fedora useless for me or C++ developers. It doesn't take much effort to get your environment up and running script the procedure and share with team mates to replicate. \ Original Message On Sep 28, 2018, 18:39, Kevin Kofler < kevin.kof...@chello.at> wrote: > > Mikolaj Izdebski wrote: > Users that want to reproduce Ant 1.10.2 build would > need to repeat > series of builds and rely on information stored in Koji to > know what > builds should be ran in what order. Trying to build packages only > from > content released to users would be even more difficult. The point is, > the Ant 1.10.2 package can be used to build itself (as well as hundreds of > other Java packages, including the user's own code). It is not essential to > be able to redo the bootstrapping as long as the bootstrapped binary that is > shipped is self-hosting. And if you want to no longer ship Ant because it is > "only" a build tool, that is going to make Fedora essentially useless for > Java developers. Kevin Kofler > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an > email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: > https://getfedora.org/code-of-conduct.html List Guidelines: > https://fedoraproject.org/wiki/Mailing\_list\_guidelines List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org publickey - israel.bermudez@protonmail.com - 0x9B5B2637.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaning some Java packages
Mikolaj Izdebski wrote: > Users that want to reproduce Ant 1.10.2 build would need to repeat > series of builds and rely on information stored in Koji to know what > builds should be ran in what order. Trying to build packages only from > content released to users would be even more difficult. The point is, the Ant 1.10.2 package can be used to build itself (as well as hundreds of other Java packages, including the user's own code). It is not essential to be able to redo the bootstrapping as long as the bootstrapped binary that is shipped is self-hosting. And if you want to no longer ship Ant because it is "only" a build tool, that is going to make Fedora essentially useless for Java developers. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: How should the nvme-cli package generate its host "NQN"?
On Fri, Sep 28, 2018, at 2:42 PM, Andrew Lutomirski wrote: > There's a request for the nvme-cli package to generate a unique name > to use when connecting to NVMe-over-fabrics targets: > > https://bugzilla.redhat.com/show_bug.cgi?id=1633814 > > I'm wondering what the right approach is. For the various Atomic > variants, ISTM it's not very nice for the package to generate files in > /etc in a postinstall script. Regarding nomenclature, going forward you probably want to be saying "CoreOS-like" instead of Atomic. See also https://pagure.io/Fedora-Council/tickets/issue/208 Now, it's possible to write files in `/etc` in `%post` - but they're *server side* defaults. And this gets to a much more important point - rpm-ostree or CoreOS style systems are just one instance of building "images" server side. Doing a `podman build` or mkosi or tons of other image delivery formats will also trip up on things like this. So one approach then is generally of "image-based" delivery mechanisms. (Of course, rpm-ostree is fairly unique in being a hybrid) Anyways, all of that aside: the correct thing is to have a systemd service - those always run client side. > Maybe /etc/machine-id could just be symlinked to /etc/nvme/hostnqn. > Or maybe the user should be responsible for setting it up themselves. > Or maybe installing nvme-cli could create an NQN but uninstalling > could leave it there? Or perhaps better, if /etc/nvme/hostnqn is ENOENT, then default to /etc/machine-id. For sending unique IDs over the network, there was also discussion recently of generating a hashed value for privacy, I forget in what context though. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: Add release announcement post to Go/No-Go criteria
I want to address a few comments in particular: > Kevin Fenzi: > I'm prefer to add a new milestone of 'day before release' and put it > there. The current schedule starts the "create the release announcement" on the day of the Go/No-Go meeting. I don't think that makes much sense: the announcement can be pre-written and edited to track changes in release dates or Changes status. I'll go ahead and move that to *end* on the Go/No-Go day. My concern remains what happens if the announcement isn't ready by the deadline? We either proceed like we've done in the past and risk a rush to publish at the end, or we declare the release No-Go, in which case there's no practical difference from what I propose. > Adam Williamson (out of order) > 1. I'm fine with the overall release process blocking, in some sense, > on things like release announcements not being done. > > 3. The Go/No-Go meeting is not necessarily the best place to decide on > this, but I'm open to it being chosen. The Go/No-Go meeting is the only real decision point we have, so IMO it makes sense to add this in there. The Release Readiness Meeting is more informative than decision-making (although it sounds like it may be time to revisit that meeting more broadly, so maybe we change this?) > More Adam Williamson > 2. I believe this should **NOT** be handled through the things actually > called the "Fedora Release Criteria" and the process for nominating and > reviewing "release blocker" bugs. Agreed. To be clear, that is not what I am proposing. I've probably been sloppy in my wording, but I'm thinking of this as a criterion exclusively for the Go/No-Go process. > Mohan Boddu > I guess we can just consider as a soft criteria and if its not ready, we will > just ask people to help marketing team and get the article ready by Friday or Monday. Right. If it's "close" (for some value of close) then Marketing can say they are go and get it finished by Monday. Of course, the counter-argument to this is that a squishy criterion that we can just accept if we want to isn't much of a criterion. -- Ben Cotton Fedora Program Manager 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Packaging Guidelines on docs.fedoraproject.org
I concur the landing page font is large. I recommend that the link emoji icon utilized in "Fedora Budget" and "Fedora's Otreachy Docs" is replaces with an image. It differs from platform to platform. ‐‐‐ Original Message ‐‐‐ On Friday, September 28, 2018 4:00 PM, Richard Shaw wrote: > Looks a touch on the big side fonts wise but looks really nice overall. > > Thanks, > Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 29-20180927.n.0 compose check report
No missing expected images. Failed openQA tests: 4/133 (x86_64), 1/24 (i386), 1/2 (arm) ID: 286561 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/286561 ID: 286581 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/286581 ID: 286587 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/286587 ID: 286628 Test: x86_64 universal install_blivet_software_raid URL: https://openqa.fedoraproject.org/tests/286628 ID: 286641 Test: x86_64 universal modularity_tests URL: https://openqa.fedoraproject.org/tests/286641 ID: 286680 Test: i386 universal install_scsi_updates_img URL: https://openqa.fedoraproject.org/tests/286680 Soft failed openQA tests: 4/133 (x86_64), 2/24 (i386) (Tests completed, but using a workaround for a known bug) ID: 286523 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/286523 ID: 286524 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/286524 ID: 286549 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/286549 ID: 286550 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/286550 ID: 286574 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/286574 ID: 286685 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/286685 Passed openQA tests: 125/133 (x86_64), 21/24 (i386) Skipped openQA tests: 1 of 159 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Packaging Guidelines on docs.fedoraproject.org
Looks a touch on the big side fonts wise but looks really nice overall. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Review swap: easy Python module
On vendredi 28 septembre 2018 21:15:14 CEST Gwyn Ciesla wrote: I'd like a swap with: android-file-transfer - Reliable MTP client with minimalistic UI https://bugzilla.redhat.com/show_bug.cgi?id=1633317 Best regards, Robert-André ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: How should the nvme-cli package generate its host "NQN"?
* Andrew Lutomirski: > There's a request for the nvme-cli package to generate a unique name > to use when connecting to NVMe-over-fabrics targets: > > https://bugzilla.redhat.com/show_bug.cgi?id=1633814 How many bits can the NQN have? Is it long enough that random generation of IDs is feasible? > I'm wondering what the right approach is. For the various Atomic > variants, ISTM it's not very nice for the package to generate files in > /etc in a postinstall script. And it also seems like it might be > surprising for a remove-and-reinstall of nvme-cli to generate a whole > new NQN. You could have a separate nvme-filesystem package which generates and owns the file (via %ghost). Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Review swap: easy Python module
https://bugzilla.redhat.com/show_bug.cgi?id=1634087 I'll take one of yours, if you like. Thank you! -- Gwyn Ciesla she/her/hers in your fear, seek only peace in your fear, seek only love -d. bowie signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: How should the nvme-cli package generate its host "NQN"?
Tom Hughes wrote: > On 28/09/2018 19:42, Andrew Lutomirski wrote: > >> Debian has "purge" for things like this, but I don't think Fedora has >> any equivalent. > > Doesn't generating in %post and owning it as %ghost in the > files list achieve much the same result of removing it when > the package is removed? I concur, the above approach also means the file will be 'owned' properly as far as rpm is concerned. -- Rex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: How should the nvme-cli package generate its host "NQN"?
On 28/09/2018 19:42, Andrew Lutomirski wrote: Debian has "purge" for things like this, but I don't think Fedora has any equivalent. Doesn't generating in %post and owning it as %ghost in the files list achieve much the same result of removing it when the package is removed? 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
How should the nvme-cli package generate its host "NQN"?
There's a request for the nvme-cli package to generate a unique name to use when connecting to NVMe-over-fabrics targets: https://bugzilla.redhat.com/show_bug.cgi?id=1633814 I'm wondering what the right approach is. For the various Atomic variants, ISTM it's not very nice for the package to generate files in /etc in a postinstall script. And it also seems like it might be surprising for a remove-and-reinstall of nvme-cli to generate a whole new NQN. Maybe /etc/machine-id could just be symlinked to /etc/nvme/hostnqn. Or maybe the user should be responsible for setting it up themselves. Or maybe installing nvme-cli could create an NQN but uninstalling could leave it there? Is there any guidance for how to handle this? Debian has "purge" for things like this, but I don't think Fedora has any equivalent. --Andy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 29 compose report: 20180927.n.0 changes
OLD: Fedora-29-20180926.n.0 NEW: Fedora-29-20180927.n.0 = SUMMARY = Added images:1 Dropped images: 0 Added packages: 5 Dropped packages:1 Upgraded packages: 83 Downgraded packages: 0 Size of added packages: 125.29 MiB Size of dropped packages:47.81 KiB Size of upgraded packages: 5.16 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 157.19 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: LXQt live x86_64 Path: Spins/x86_64/iso/Fedora-LXQt-Live-x86_64-29-20180927.n.0.iso = DROPPED IMAGES = = ADDED PACKAGES = Package: oshinko-cli-0.5.4-1.fc29 Summary: Command line interface for spark cluster management app RPMs:oshinko-cli Size:64.54 MiB Package: python-curio-0.9-1.fc29 Summary: Building blocks for performing concurrent I/O RPMs:python3-curio Size:134.96 KiB Package: python-h11-0.8.1-1.fc29 Summary: A pure-Python, bring-your-own-I/O implementation of HTTP/1.1 RPMs:python3-h11 Size:93.68 KiB Package: tdlib-1.3.0-2.fc29 Summary: Cross-platform library for building Telegram clients RPMs:tdlib tdlib-devel tdlib-static Size:25.02 MiB Package: upm-1.7.0-2.fc29 Summary: A high level library for sensors and actuators RPMs:nodejs-upm python3-upm upm upm-devel Size:35.51 MiB = DROPPED PACKAGES = Package: python-mmdzanata-0.7-2.fc29 Summary: Tools for working with translations of modulemd RPMs:python2-mmdzanata python3-mmdzanata Size:47.81 KiB = UPGRADED PACKAGES = Package: R-3.5.1-1.fc29 Old package: R-3.5.0-6.fc29 Summary: A language for data analysis and graphics RPMs: R R-core R-core-devel R-devel R-java R-java-devel libRmath libRmath-devel libRmath-static Size: 331.53 MiB Size change: -3.31 MiB Changelog: * Mon Sep 10 2018 Tom Callaway - 3.5.1-1 - update to 3.5.1 - update bundled curl to 7.61.1 Package: agenda-1.0.12-1.fc29 Old package: agenda-1.0.11-1.fc29 Summary: Simple, fast, no-nonsense to-do (task) list RPMs: agenda Size: 429.22 KiB Size change: 71.18 KiB Changelog: * Sun Sep 16 2018 Fabio Valentini - 1.0.12-1 - Update to version 1.0.12. Package: aoetools-36-16.fc29 Old package: aoetools-36-14.fc28 Summary: ATA over Ethernet Tools RPMs: aoetools Size: 329.45 KiB Size change: -27.54 KiB Changelog: * Thu Jul 12 2018 Fedora Release Engineering - 36-15 - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild * Sat Sep 15 2018 Filipe Rosset - 36-16 - rebuilt to fix FTBFS + spec cleanup Package: chrony-3.4-1.fc29 Old package: chrony-3.3-5.fc29 Summary: An NTP client/server RPMs: chrony Size: 1.41 MiB Size change: 22.39 KiB Changelog: * Fri Aug 31 2018 Miroslav Lichvar 3.4-0.1.pre1 - update to 3.4-pre1 * Wed Sep 19 2018 Miroslav Lichvar 3.4-1 - update to 3.4 Package: clamtk-5.26-1.fc29 Old package: clamtk-5.25-5.fc29 Summary: Easy to use graphical user interface for Clam anti virus RPMs: clamtk Size: 211.45 KiB Size change: 56 B Changelog: * Sat Sep 15 2018 Dave M. - 5.26-1 - Updated to release 5.26. Package: clover2-5.0.7-1.D20180902git35da6ac.fc29 Old package: clover2-5.0.3-1.D20180822gitcfa5389.fc29 Summary: Yet another compiler language RPMs: clover2 clover2-devel clover2-libs Size: 5.08 MiB Size change: -19.50 KiB Changelog: * Wed Sep 05 2018 Mamoru TASAKA - 5.0.7-1.D20180902git35da6ac - 5.0.7 Package: ctstream-29-1.fc29 Old package: ctstream-28-1.fc29 Summary: Get URLs of Czech Television video streams RPMs: ctstream Size: 18.27 KiB Size change: -2.20 KiB Changelog: * Thu Sep 13 2018 Petr Pisar - 29-1 - Version 29 bump Package: distgen-1.2-1.fc29 Old package: distgen-1.1-3.fc29 Summary: Templating system/generator for distributions RPMs: distgen Size: 61.00 KiB Size change: 1.31 KiB Changelog: * Fri Sep 14 2018 Pavel Raiskup - 1.2-1 - latest upstream release Package: distribution-gpg-keys-1.23-1.fc29 Old package: distribution-gpg-keys-1.22-1.fc29 Summary: GPG keys of various Linux distributions RPMs: distribution-gpg-keys distribution-gpg-keys-copr Size: 10.70 MiB Size change: 245.17 KiB Changelog: * Fri Sep 14 2018 Miroslav Such?? 1.23-1 - update copr keys - add rawhide as symlink to F30 Package: dmidecode-1:3.2-1.fc29 Old package: dmidecode-1:3.1-7.fc29 Summary: Tool to analyse BIOS DMI data RPMs: dmidecode Size: 217.20 KiB Size change: 7.09 KiB Changelog: * Tue Sep 18 2018 Anton Arapov - 1:3.2-1 - updated to upstream v3.2 - Supported SMBIOS spec up to v3.2.0 Package: ecj-1:4.9-1.fc29 Old package: ecj-1:4.7.3a-2.fc29 Summary: Eclipse Compiler for Java RPMs: ecj Size: 2.58 MiB Size change: 31.75 KiB Changelog: * Wed Sep
Re: Orphaning some Java packages
Le vendredi 28 septembre 2018 à 10:26 -0400, Stephen John Smoogen a écrit : > On Fri, 28 Sep 2018 at 04:21, Nicolas Mailhot > wrote: > > Le vendredi 28 septembre 2018 à 10:09 +0200, Mikolaj Izdebski a > > écrit : > > > This is already not met for Fedora. Lets look at ant package which > > > you > > > mentioned earlier. > > > > > > > That just shows it is urgent for Fedora to improve its handling of > > bootstrapping operations, because major languages depend on it today > > (Java is not the only one). > > > > It is not sustainable to require packagers to manage bootstraping > > manually, because koji has no knowledge of it. > > > > Can you explain what you mean by that? I mean that when a larger and larger package set needs bootsrapping due to upstream practices, we can't continue to have koji and mock treat it like a weird exception that can be dealt with by manual packager handling Yes the packager has to document the bootstraping recipe in the spec, but the tools should apply it automatically when normal builds fails, not rely on manual switching of with/without bootstrap variables by the packager, or manual computation of mass rebuild execution plans. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Packaging Guidelines on docs.fedoraproject.org
On Fri, Sep 28, 2018 at 02:02:37PM +0200, Igor Gnatenko wrote: > We have moved packaging guidelines onto docs.fedoraproject.org[0]. > If you find any error or would like to change something, don't hesitate to > open ticket or submit pull request for packaging committee repo[1]. This is amazing! Thanks everyone for all your work on this! -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fwd: Weston package
Hello, I am trying to put weston in a docker container. I have run into some issues and have been able to solve them with some trial and error and research. But, I have hit an error when trying to start weston that there are no other warning that I can see and I am not sure what else to do. Here is what I got: [brianclark@localhost weston]$ cat Dockerfile FROM registry.fedoraproject.org/fedora:rawhide LABEL MAINTAINER "Brian Clark" ENV NAME=weston VERSION=0 RELEASE=1 ARCH=x86_64 XDG_RUNTIME_DIR=/run/user/XDG LABEL BZComponent="$NAME" \ Name="$FGC/$NAME" \ Version="$VERSION" \ Release="$RELEASE.$DISTTAG" \ Architecture="$ARCH" RUN dnf -y install libunwind libinpu wayland mesa wayland-protocols weston wayland-ivi-extension [brianclark@localhost weston]$ docker run --rm -e DISPLAY=$DISPLAY -ti weston [root@d4895acb1694 /]# weston Date: 2018-09-28 UTC [02:04:21.902] weston 5.0.0 https://wayland.freedesktop.org Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/ Build: unknown (not built from git or tarball) [02:04:21.921] Command line: weston [02:04:21.921] OS: Linux, 4.18.8-200.fc28.x86_64, #1 SMP Sun Sep 16 18:15:41 UTC 2018, x86_64 [02:04:21.921] warning: XDG_RUNTIME_DIR "/run/user/XDG" is not configured correctly. Unix access mode must be 0700 (current mode is 755), and must be owned by the user (current owner is UID 0). Refer to your distribution on how to get it, or http://www.freedesktop.org/wiki/Specifications/basedir-spec on how to implement it. [02:04:21.921] Starting with no config file. [02:04:21.921] Output repaint window is 7 ms maximum. [02:04:21.928] Loading module '/usr/lib64/libweston-5/x11-backend.so' [02:04:22.373] fatal: failed to create compositor backend [root@d4895acb1694 /]# If this is a bug I will be happy to file it on bugzilla and/or email the devel list. Thank you for your help in advance. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora Packaging Guidelines on docs.fedoraproject.org
Hello everyone, We have moved packaging guidelines onto docs.fedoraproject.org[0]. If you find any error or would like to change something, don't hesitate to open ticket or submit pull request for packaging committee repo[1]. Thanks for attention! [0] https://docs.fedoraproject.org/en-US/packaging-guidelines/ [1] https://pagure.io/packaging-committee -- -Igor Gnatenko ___ 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://getfedora.org/code-of-conduct.html 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaning some Java packages
On Fri, 28 Sep 2018 at 04:21, Nicolas Mailhot wrote: > > Le vendredi 28 septembre 2018 à 10:09 +0200, Mikolaj Izdebski a écrit : > > > > This is already not met for Fedora. Lets look at ant package which you > > mentioned earlier. > > > > That just shows it is urgent for Fedora to improve its handling of > bootstrapping operations, because major languages depend on it today > (Java is not the only one). > > It is not sustainable to require packagers to manage bootstraping > manually, because koji has no knowledge of it. > Can you explain what you mean by that? Since we have been doing basically this for 20+ years since the beginning of Red Hat Linux in some form or another.. it would seem not just sustainable but just what happens with various source trees. What does sustainable mean in this case? -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaning some Java packages
Gerald Henriksen wrote: > Fedora (rightly) > as a rule doesn't want multiple versions of libraries. what rule is that? -- Rex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaning some Java packages
On Fri, 28 Sep 2018 10:15:46 +0200, you wrote: >Le jeudi 27 septembre 2018 à 19:14 -0400, Gerald Henriksen a écrit : >> >> Or, short version, the Java ecosystem is either indifferent or hostile >> to distribution packages. > >Any language ecosystem is initially hostile to distribution packages. Except this has been going on for years, and hence is long past the initially stage. >Besides the main advantage of distribution packages is upgrade >management, and composing of many software components, by tracking the >state of each of those components, and providing uniform deployment >rules. Which quickly falls apart when upstream refuses to update their code to the latest versions of the libraries they use, and Fedora (rightly) as a rule doesn't want multiple versions of libraries. I agree that in an ideal world the distribution model is the best and most effective, but we don't live in an ideal world and sadly many (most?) upstreams don't follow what a distribution would consider good practices. >There are no special distribution-friendly langages. C?C++ software was >deployed for years without packages on Solaris, AIX, Windows and so on >before all the efficiency wins of doing via packages on Linux made Linux >distributions capture that market. Except all the "modern" languages decided to solve the problem themselves with their own repositories of libraries and build systems that pull in dependencies as needed. They (somewhat rightly from their respective) view maven, gradle, npm, etc. as the best and preferred solution because they deal with it once and it covers every OS. Which is why the C++ community is belatedly dealing with the issue and has started a working group on trying to deal with the issue of a package manager. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaning some Java packages
Le vendredi 28 septembre 2018 à 10:09 +0200, Mikolaj Izdebski a écrit : > > This is already not met for Fedora. Lets look at ant package which you > mentioned earlier. > That just shows it is urgent for Fedora to improve its handling of bootstrapping operations, because major languages depend on it today (Java is not the only one). It is not sustainable to require packagers to manage bootstraping manually, because koji has no knowledge of it. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaning some Java packages
Le jeudi 27 septembre 2018 à 19:14 -0400, Gerald Henriksen a écrit : > > Or, short version, the Java ecosystem is either indifferent or hostile > to distribution packages. Any language ecosystem is initially hostile to distribution packages. Languages ecosystems are created by devs, that care little about deployment, because 1. they have nothing to deploy at first 2. if they cared about deployment and upgrades, they wouldn't join an ecosystem with no deployment story That initial dev-not-deploy seed tend to imprint the ecosystem culture deeply. And it's worse when you have large business adoption, because businesses want immediate ROI and will pay to have software deployed now even if it takes manual non reusable steps, immature language-specific packages, business-specific no shared tooling, SCL hacks and so on. Thus reinforcing the initial dev conviction they need not bother about deployment and upgrades (note that in that case the "open source free software" gets captured inside the business non open or free bubble because that's the only way to use it in production; and right now Fedora's main sponsor does not care so much about this capture because it has become a business provider). You have to package a large initial baseline of software components, against at best the indifference at worst the hostility of this ecosystem, do much outreaching, before it gets established enough a significant part of the language ecosystem uses it and is convinced the approach is good. You have to be persistent, and try to bridge two tech cultures, and be convinced yourself, because people the other side are waiting for you for give up so they can continue to ignore deployment problems and offload them to (despised) operations. Containers and devops are just another way to collect this huge bag of poop and dump it on someone else. Just take any random container and try to do a security audit of the stuff contained inside the shiny modern enveloppe. Besides the main advantage of distribution packages is upgrade management, and composing of many software components, by tracking the state of each of those components, and providing uniform deployment rules. So you have to wait for years of botched upgrades via other means, and exhaustion of all alternative ways to ignore this tracking by precomposing every possible component mix in separate images, before it becomes evident you need to use distribution packages (and devs are not on the front line for botched upgrades so the realization will not come from the dev side). Note that modules already hit the "too many composition scenarii to precompose everything" wall. That's what caused the back-pedalling on transforming Fedora in a set of independent leaf modules with no distro packages left (but modules-only no distro package little song lingers) There are no special distribution-friendly langages. C∕C++ software was deployed for years without packages on Solaris, AIX, Windows and so on before all the efficiency wins of doing via packages on Linux made Linux distributions capture that market. Many other markets are waiting for a similar distribution moment. For now, addressing them via container, images or modules is not a business handicap, because of the lack of an alternative player. I'm sure they were many meetings at SUN, IBM, HP & Microsoft where the packaging question was raised and someone decided "why bother, it takes money and energy, right now competitors are just as bad as us, devs do not want to deal with the complexity of tracking dependencies, let's look at it later". -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaning some Java packages
On 09/28/2018 02:50 AM, Kevin Kofler wrote: > Mikolaj Izdebski wrote: >> Modules with their API specifications at least make it more clear what >> are expectations about packages. Something user may consider essential >> is only a build dependency for a packager and the packages won't receive >> enough attention from the maintainer. > > As I wrote in another thread: Any packages that are used to build packages > that are delivered to the users MUST also themselves be delivered to the > users in a self-hosting distribution. This is the definition of > "self-hosting". It is also required to comply with some copyleft licenses. This is already not met for Fedora. Lets look at ant package which you mentioned earlier. Ant 1.10.2 was built with a chain build [1]. This chain build can be represented as: ant-1.10.1-9.fc28 -> ant-1.10.2-0.1.fc28 -> ant-1.10.2-1.fc28 Chain build was necessary because: - Ant is built with Ant. - Ant 1.10.2 requires Ant 1.10.2 to build. - Ant 1.10.2 can't be built with Ant 1.10.1 without patching. Intermediary build ant-1.10.2-0.1.fc28 (which release starts with 0 to make it clear it's a bootstrap build) was never shipped to users. It was used only as a buildroot override that was active for less than 5 minutes: Tue Mar 6 14:13:24 2018 ant-1.10.2-0.1.fc28 tagged into f28-override Tue Mar 6 14:17:49 2018 ant-1.10.2-0.1.fc28 untagged from f28-override Moreover, this intermediary build was already deleted [2] from Koji. Users that want to reproduce Ant 1.10.2 build would need to repeat series of builds and rely on information stored in Koji to know what builds should be ran in what order. Trying to build packages only from content released to users would be even more difficult. This also shows why Java package maintenance may be time consuming and why I'm looking for ways to reduce maintenance work - even micro version bumps like 1.10.1 to 1.10.2 may require bootstrapping. Bootstrapping developed specifically for particular upgrade. [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=25518471 [2] https://koji.fedoraproject.org/koji/buildinfo?buildID=1027958 -- Mikolaj Izdebski Senior Software Engineer, Red Hat IRC: mizdebsk ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
