devel February 2018

devel@lists.fedoraproject.org

237 participants
244 discussions

Test gating enabled in Bodhi
by Pierre-Yves Chibon 01 Mar '18

01 Mar '18

Good Morning Fedorans! On Thursday, a new version of Bodhi was deployed that enabled Bodhi to gate updates based on test results. You may notice a "Test Gating Status" message in the right have side of the page. One thing to know about this is that there is currently a confusing issue where Bodhi will say that the tests have failed when the tests haven't finished running[0]. We are working on solving that issue, but for now you can just wait a while and it should report the result once all the tests have finished. There are three tests that must pass in order for updates to go to stable: 0. dist.depcheck - to make sure the update's dependencies are available. 1. dist.abicheck - to make sure the update's ABI remains stable in a given Fedora release. 2. AtomicCI pipeline - packages that are part of the Atomic Host *and* include in their dist-git tests, must have these tests passed in the AtomicCI pipeline This last requirement only concern packages that are in the Atomic Host while the first two is enforced for all packages. We are also working on another CI pipeline that will allow running tests stored in dist-git for all packages without discrimination. You are in control of these three tests. The first two can be fixed by making changes in the spec file, and the latter test is controlled via the tests in your repo. Finally, if it turns out you need to push an update through despite of the test results, you can do so using waiver-cli (dnf install waiverdb-cli). We are working on integrating this into Bodhi itself, making this easier. We have started a wiki page to store all of this information and that we will keep up to date as improvements are done or for any frequent questions coming up: https://fedoraproject.org/wiki/CI/gating_updates Please accept my apology in the delay in writing this message. It should have been sent last week when it was enabled, and it got lost. Thanks for your attention, Pierre [0] https://github.com/fedora-infra/bodhi/issues/2124 _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org

18 38

News in net-snmp package
by Josef Ridky 01 Mar '18

01 Mar '18

Hi folks, I would like to inform you, that net-snmp package will use Python3 package instead of Python2. With this change, python2-net-snmp package will be renamed to python3-net-snmp package. This change will be applied in Fedora Rawhide and Fedora 28. I would be glad for any feedback. Regards Josef Ridky Associate Software Engineer Core Services Team Red Hat Czech, s.r.o.

3 4

Exclude paths for elfdeps dependency generator
by Till Hofmann 01 Mar '18

01 Mar '18

Hi all, I have a question regarding the the RPM dependency generator scripts. I'm working on packaging the ROS stack [1,2] and I'm currently dealing with the dependency generation. My goal is to wrap all Provides and Requires for sonames because ROS does not use proper sonames (and therefore they shouldn't be in the ld cache), but I still want to use the information for ROS packages. This means I want to replace: Provides: librosconsole.so()(64bit) => Provides: ros(librosconsole.so()(64bit)) [or possibly ros-kinetic(librosconsole.so()(64bit))] and similarly for Requires. I have a working solution [3] that wraps all ROS Provides and Requires and generates other Provides and Requirest just as elfdeps does, but it uses an (imho ugly) hack: As I don't want to have the normal Provides generated by elfdeps, I have: %__ros_path ^/usr/lib.*/ros/.*$ %__elf_exclude_path %__ros_path in /usr/lib/rpm/fileattrs/ros.attr. I see two problems: If %__elf_exclude_path is set by something else, it is overridden, because I couldn't figure out how to append to the exclude path. Second, %__elf_exclude_path should not be set at all in ros.attr, the doc [4] says: "NAME needs to be replaced by the name choosen for the file attribute and needs to be the same as the file name of the macro file itself" It still works, but shouldn't according to the documentation. So my question: Is there any other way to exclude the ROS dir to be checked by elfdeps? I cannot just use %__requires_exclude_from because I want my dependency generator to run on the directory. Thanks for any hints. Kind regards, Till [1] https://pagure.io/ros [2] https://copr.fedorainfracloud.org/coprs/thofmann/ros/ [3] https://pagure.io/ros-rpm-macros [4] http://rpm.org/user_doc/dependency_generators.html

1 1

march VFAD for the atomic working group
by Dusty Mabe 28 Feb '18

28 Feb '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 https://pagure.io/atomic-wg/issue/429 In the Atomic working group in Fedora we have occasionally used virtual Fedora Activity Days (VFADs) to get the community together to discuss in a high bandwidth setting (video conference) some techical issues we're having or some direction of where we're going. We have scheduled a VFAD for next Friday (march 9th). We'd like to get some input on some topics to discuss during this VFAD. Please discuss and add topics to the ticket. It would be preferable if we keep discussion in one place so please add responses to the ticket. Thanks! Atomic Working Group -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEPb6zG5c6sV89tRYPMwLb1zlS5nEFAlqW4BkACgkQMwLb1zlS 5nFk+g/+MInPWyUZcBt1ZmBHgPxkyaaE3vDkNIB2upt4nzABVmiOQIFvijnPie37 pN6jRhTChCSFxgDD2NIklNvoJN9CEwSWogD/IFHsr3Ty2p2+5RDHDHaGQVNsEn0a nD9Ye6E05C0A/iQ3QFbTS+Fin4go+P5Z/ZekCrnaC+6VE12MNf6L1v3y3hXplepo HuYVf9nfrQr+pw4m/4E1zcWDbxWkDVWv3l76HsVMMzCevgWoj/I6/GGzl0oIgnfy oMmw9wgpWst72EKMP5bTEpLl1VfG6UU0MVquv4sWpoP3eM7zSjXbwZ1DFuf3gWHS R4yjWN9vk+haRbyDnfLDZ6/a1hvqXd91rGA9XSNaMVSpSx2ePjBPAj9zO/i4b9ZI 0/04NM3A4ru0jxzDljZmHSolkPh3qmNK9TYFF1Vl3c0ukOAjE1g3JoGHeHCbpyp9 uks1ImatgkhWduV3OyrtpblmxUfZLbn2GxkGKZIavK7z9sN8mStI6Ids4WYMO2PC Z8k5TYge9lQpUOUQYOSQEEiCxtzuwEJGAzWI7JMW6hECO7xd6XFCqPcrYDChgkAr PIHJH9/puurhLUmP/3MUpx3nK1V6g26mgs5oeYwYdu7SmSz9RvrlhH5lihWO6njM 6J9A0Pwh8pSgmymXnrBtYZAIgFGmH8ZCuRdgkLDTeJ+GD4aiWy4= =1Vdx -----END PGP SIGNATURE-----

2 1

packmol license change
by Susi Lehtola 28 Feb '18

28 Feb '18

Hi, I've updated packmol to version 18.013. This carries a license change from GPLv2+ to MIT. No other packages are affected, since packmol is executable only. -- Susi Lehtola Fedora Project Contributor jussilehtola(a)fedoraproject.org

1 0

Re: Fedora Atomic Host Two Week Release Announcement: 27.93
by Dusty Mabe 27 Feb '18

27 Feb '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/27/2018 10:47 AM, noreply(a)fedoraproject.org wrote: > > A new Fedora Atomic Host update is available via an OSTree update: > > Version: 27.93 > Commit(x86_64): da0bd968610aa1e29c5bb37065649407fbbfffa53e63831afdadbd34a3b05327 > Commit(aarch64): 6607b02ff08bd0f0fc488772b398c25de28345a0bda0508ef45b433b91839ccd > Commit(ppc64le): 848b618bd36e8b03bbcedf2d9ff881450440d8434f62cdb80006d3e899ebaa28 > > > We are releasing images from multiple architectures but please note > that x86_64 architecture is the only one that undergoes automated > testing at this time. > > Existing systems can be upgraded in place via e.g. `atomic host upgrade`. > > Corresponding image media for new installations can be downloaded from: > > https://getfedora.org/en/atomic/download/ > > Alternatively, image artifacts can be found at the following links: > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-201802… > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-201802… > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-201802… > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-201802… > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-201802… > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-201802… > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-201802… > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-201802… > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-201802… > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-201802… > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-201802… > > Respective signed CHECKSUM files can be found here: > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-201802… > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-201802… > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-201802… > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-201802… > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-201802… > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-201802… > > For direct download, the "latest" targets are always available here: > https://getfedora.org/atomic_iso_latest > https://getfedora.org/atomic_qcow2_latest > https://getfedora.org/atomic_raw_latest > https://getfedora.org/atomic_vagrant_libvirt_latest > https://getfedora.org/atomic_vagrant_virtualbox_latest > > Filename fetching URLs are available here: > https://getfedora.org/atomic_iso_latest_filename > https://getfedora.org/atomic_qcow2_latest_filename > https://getfedora.org/atomic_raw_latest_filename > https://getfedora.org/atomic_vagrant_libvirt_latest_filename > https://getfedora.org/atomic_vagrant_virtualbox_latest_filename > > For more information about the latest targets, please reference the Fedora > Atomic Wiki space. > > https://fedoraproject.org/wiki/Atomic_WG#Fedora_Atomic_Image_Download_Links > > Do note that it can take some of the mirrors up to 12 hours to "check-in" at > their own discretion. > > Thank you, > Fedora Release Engineering > We have a new kernel (4.15), ostree [1], and rpm-ostree [2] in this release. It is also worth noting that now the `rpm-ostree status` output will prefix the remote:ref with `ostree://` in order to denote the system is following an ostree repository remote (see example below). This is in preparation of some upstream changes related to rpm-ostree jigdo, where updates can be delivered via a special rpm in a yum repo rather than an ostree server/remote. See the release announcement at [3] for more info. ``` [root@vanilla-f27atomic ~]# rpm-ostree status State: idle; auto updates disabled Deployments: ? ostree://fedora-atomic:fedora/27/x86_64/atomic-host Version: 27.93 (2018-02-25 20:49:19) Commit: da0bd968610aa1e29c5bb37065649407fbbfffa53e63831afdadbd34a3b05327 GPGSignature: Valid signature by 860E19B0AFA800A1751881A6F55E7430F5282EE4 ``` An example of the diff between this and the previous released version (for x86_64) is: ostree diff commit old: b25bde0109441817f912ece57ca1fc39efc60e6cef4a7a23ad9de51b1f36b742 ostree diff commit new: da0bd968610aa1e29c5bb37065649407fbbfffa53e63831afdadbd34a3b05327 Upgraded: bash 4.4.12-13.fc27 -> 4.4.19-1.fc27 ca-certificates 2017.2.20-1.0.fc27 -> 2018.2.22-1.0.fc27 container-selinux 2:2.44-1.fc27 -> 2:2.48-1.fc27 coreutils 8.27-19.fc27 -> 8.27-20.fc27 coreutils-common 8.27-19.fc27 -> 8.27-20.fc27 findutils 1:4.6.0-14.fc27 -> 1:4.6.0-16.fc27 freetype 2.8-7.fc27 -> 2.8-8.fc27 glusterfs 3.12.5-1.fc27 -> 3.12.6-2.fc27 glusterfs-client-xlators 3.12.5-1.fc27 -> 3.12.6-2.fc27 glusterfs-fuse 3.12.5-1.fc27 -> 3.12.6-2.fc27 glusterfs-libs 3.12.5-1.fc27 -> 3.12.6-2.fc27 gnutls 3.5.17-1.fc27 -> 3.5.18-2.fc27 grub2-common 1:2.02-19.fc27 -> 1:2.02-22.fc27 grub2-efi-x64 1:2.02-19.fc27 -> 1:2.02-22.fc27 grub2-pc 1:2.02-19.fc27 -> 1:2.02-22.fc27 grub2-pc-modules 1:2.02-19.fc27 -> 1:2.02-22.fc27 grub2-tools 1:2.02-19.fc27 -> 1:2.02-22.fc27 grub2-tools-extra 1:2.02-19.fc27 -> 1:2.02-22.fc27 grub2-tools-minimal 1:2.02-19.fc27 -> 1:2.02-22.fc27 ima-evm-utils 1.0-2.fc27 -> 1.0-3.fc27 iproute 4.14.1-4.fc27 -> 4.15.0-1.fc27 iproute-tc 4.14.1-4.fc27 -> 4.15.0-1.fc27 kernel 4.14.18-300.fc27 -> 4.15.4-300.fc27 kernel-core 4.14.18-300.fc27 -> 4.15.4-300.fc27 kernel-modules 4.14.18-300.fc27 -> 4.15.4-300.fc27 krb5-libs 1.15.2-4.fc27 -> 1.15.2-7.fc27 ostree 2018.1-1.fc27 -> 2018.2-1.fc27 ostree-grub2 2018.1-1.fc27 -> 2018.2-1.fc27 ostree-libs 2018.1-1.fc27 -> 2018.2-1.fc27 python2 2.7.14-6.fc27 -> 2.7.14-7.fc27 python2-libs 2.7.14-6.fc27 -> 2.7.14-7.fc27 python3 3.6.4-7.fc27 -> 3.6.4-8.fc27 python3-libs 3.6.4-7.fc27 -> 3.6.4-8.fc27 rpm-ostree 2018.1-2.fc27 -> 2018.3-1.fc27 rpm-ostree-libs 2018.1-2.fc27 -> 2018.3-1.fc27 skopeo 0.1.27-1.git93876ac.fc27 -> 0.1.28-1.git0270e56.fc27 skopeo-containers 0.1.27-1.git93876ac.fc27 -> 0.1.28-1.git0270e56.fc27 strace 4.20-1.fc27 -> 4.21-1.fc27 vim-minimal 2:8.0.1478-1.fc27 -> 2:8.0.1527-1.fc27 Removed: compat-openssl10-1:1.0.2m-1.fc27.x86_64 The Vagrant Cloud page with the new atomic host: https://app.vagrantup.com/fedora/boxes/27-atomic-host https://app.vagrantup.com/fedora/boxes/27-atomic-host/versions/27.20180226.0 For posterity the AMIs for this release are: Fedora-Atomic-27-20180226.0.x86_64 EC2 (ap-northeast-1) ami-2b1e594d hvm standard Fedora-Atomic-27-20180226.0.x86_64 EC2 (ap-southeast-1) ami-ab541cd7 hvm standard Fedora-Atomic-27-20180226.0.x86_64 EC2 (ap-southeast-2) ami-4b844229 hvm standard Fedora-Atomic-27-20180226.0.x86_64 EC2 (eu-central-1) ami-3d1e7352 hvm standard Fedora-Atomic-27-20180226.0.x86_64 EC2 (eu-west-1) ami-273f455e hvm standard Fedora-Atomic-27-20180226.0.x86_64 EC2 (sa-east-1) ami-dbd79fb7 hvm standard Fedora-Atomic-27-20180226.0.x86_64 EC2 (us-east-1) ami-068b627b hvm standard Fedora-Atomic-27-20180226.0.x86_64 EC2 (us-west-1) ami-202d2640 hvm standard Fedora-Atomic-27-20180226.0.x86_64 EC2 (us-west-2) ami-5840c920 hvm standard Fedora-Atomic-27-20180226.0.x86_64 EC2 (ap-northeast-1) ami-ed1d5a8b hvm gp2 Fedora-Atomic-27-20180226.0.x86_64 EC2 (ap-southeast-1) ami-cd551db1 hvm gp2 Fedora-Atomic-27-20180226.0.x86_64 EC2 (ap-southeast-2) ami-4884422a hvm gp2 Fedora-Atomic-27-20180226.0.x86_64 EC2 (eu-central-1) ami-911c71fe hvm gp2 Fedora-Atomic-27-20180226.0.x86_64 EC2 (eu-west-1) ami-983a40e1 hvm gp2 Fedora-Atomic-27-20180226.0.x86_64 EC2 (sa-east-1) ami-86d59dea hvm gp2 Fedora-Atomic-27-20180226.0.x86_64 EC2 (us-east-1) ami-2b8d6456 hvm gp2 Fedora-Atomic-27-20180226.0.x86_64 EC2 (us-west-1) ami-242d2644 hvm gp2 Fedora-Atomic-27-20180226.0.x86_64 EC2 (us-west-2) ami-dd4fc6a5 hvm gp2 Dusty [1] https://github.com/ostreedev/ostree/releases/tag/v2018.2 [2] https://github.com/projectatomic/rpm-ostree/releases/tag/v2018.3 [3] https://github.com/projectatomic/rpm-ostree/releases/tag/v2018.2 -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEPb6zG5c6sV89tRYPMwLb1zlS5nEFAlqV0NcACgkQMwLb1zlS 5nE7ChAAi7RwJNVmTj2FCaAnXZH9gUDvgLvM2M6LZBlb35tG+XLcRzSAaE0pJ/Nt jF9d+xJem/LOIxOXZjAscDU25h3gvZLehZKTHkq0N9GG+vGmSPBzWnp5OaA2fURT URFWDGpZnQWSzGHOWZzXZ9oBusTGTc0kRPxQp6yPl6ODZYTmwnZWTW2oO+7HPxsq 2P+rb5nx+KRpHHRClXxRXO3VDuypejHOIIlcikn8zMo30mJEfK62mjRv7n6CREWB Hp0iKmyRFkZdgxNzyWZVm1wrEKVfswj3aaeMPI4wsYnRIHZOs1UeYzJUXWqdmBmx vinfxdjwO6g4ml6IihHNqwYr2nuZuieHbWc6aDIMvgYONummHo8enP19030p/fIl hUHO69I14c1A22is+yn2Y7c6yZ7vLygP/fcHSW3MyORc1yXnZbYhUrEcUt9ZAqrX XUMjjsYwHxml9850jycoGTMgQgW03o6+hlcI04L7JTN/PuuKxQ096vf2PQoZ28HR /qEBR4jaTl4EzF5XqOjFYhpQ5e6GidAsG22yOfbcYbpXZgm4bpHubfIsObu/qn8c xCopxc4rsCGzfQ3MUzDxzGR0fz53COL468Wg8coXCMHEjSRc3fVZSlxhW+Af9IW3 FV38sqL1LOJ9H9TFFV5O4ZnHOM8MU1h3/xovrVvHCKPB1Z9oJ5Y= =JD4j -----END PGP SIGNATURE-----

1 0

Review Request: swift-lang (Apple's Swift programming language)
by Ron Olson 27 Feb '18

27 Feb '18

Hi all- I'm looking for a package review of Apple's Swift programming language: https://bugzilla.redhat.com/show_bug.cgi?id=1536780 I greatly appreciate any and all assistance in getting Swift available on Fedora. Ron

1 1

runroot changing during the course of a rawhide pungi run
by Dusty Mabe 27 Feb '18

27 Feb '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 If I understand correctly there was a new lorax build [1] that completed at 01:11 UTC (02/23) that then made it into the runroot of a task [2] that was part of a pungi compose [3] that started at 14:54 UTC (02/22). I think this caused problems with the build, but that isn't really important. The real question is: if our runroot changes during the run then we could have some tasks (lorax imagebuild etc) that run with some versions of software and other tasks that run with others. This is probably especially maddening when trying to debug why one failed when others didn't. Is my understanding correct? Dusty [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1048851 [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=25243479 [3] https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180222.… -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEPb6zG5c6sV89tRYPMwLb1zlS5nEFAlqPi74ACgkQMwLb1zlS 5nGSwg/9HIHUVvCTZiU/3tNT1zskuJZNUtiuefWFsVQTQfgLulLz+L/Fw8KxtmLO zVKXKF7Aqs5xHxkAle+VZq6HNmhU6lB6DUpLpxnhXhBw8fBB8TpEbxaHBQtE9mPS 90zrYNTYXB7vMLkM+FnenpELF2XYe80/O6iz34ZUCMqYdavw1G7s8MI6cS36CV0m ZpOTdYpIRtVFgv4NSy8hFDs91XPXE3hp4jP/ffU0rnA0Aq1tW3r67EyDT26LSRk1 CfKewnLNCXN329PukFAA1xYOjT9JxjZJAswCXsgx+Vr5vjI6AGCq+773Iz2PgX4H ZPcGWrZDeILtCPARjAqfUx22ldPF38MSfL3v0GHy9NgC683yLaLUqm08Zl7l4Ujh xg/wPbvvYt/VmwhCY+MQLf1XrYylLvCdVJyI7yrum8QhfWieTzH2OizejyddT6dE 2NEqdNsh1BIrsh/9kw8s7XdE3dZ6UyfxYwwcdMC6XtJT633IlJiXq2HfqtlRLipp H1rqz+1+Qp7bQAIQqH8sn2FpgW2IBr9csb/vxWq3ZcePeukRe4q/SRFa+xDvg8gF yuLrBa+Ovkh8KZvVeH34OAyf8AFRCjHCz1YtKThCfELzDWRFwOfzWmbA80+8rKQN JcapBDyqHJDeL86O/HuTXNE770EtzeglA0YDO+a/G4Of2ngedP4= =/fUr -----END PGP SIGNATURE-----

2 3

Multilib issue: apitrace-libs.i686 version mismatches apitrace-libs.x86_64 on F27
by Sandro Mani 27 Feb '18

27 Feb '18

Hi I've received a bug report from a user reporting broken dependencies when updating apitrace in F27. Upon closer investigation I found out that on F27 # dnf install --refresh apitrace-libs.i686 will give you apitrace-libs-7.1-7.fc27.i686, whereas # dnf install --refresh apitrace-libs will give you apitrace-libs-7.1-9.fc27.x86_64. This means that a user with currently installed apitrace-7.1-7.x84_64, apitrace-libs-7.1-7.x86_64 and apitrace-libs-7.1-7.i686 is currently getting broken dependencies when updating: # dnf update [...] Problem 1: package apitrace-libs-7.1-7.fc27.i686 requires apitrace = 7.1-7.fc27, but none of the providers can be installed - cannot install both apitrace-7.1-9.fc27.x86_64 and apitrace-7.1-7.fc27.x86_64 - cannot install both apitrace-7.1-7.fc27.x86_64 and apitrace-7.1-9.fc27.x86_64 - cannot install the best update candidate for package apitrace-libs-7.1-7.fc27.i686 - cannot install the best update candidate for package apitrace-7.1-7.fc27.x86_64 Problem 2: problem with installed package apitrace-libs-7.1-7.fc27.i686 - apitrace-libs-7.1-7.fc27.i686 has inferior architecture - cannot install both apitrace-libs-7.1-9.fc27.x86_64 and apitrace-libs-7.1-7.fc27.x86_64 - cannot install both apitrace-libs-7.1-7.fc27.x86_64 and apitrace-libs-7.1-9.fc27.x86_64 - cannot install the best update candidate for package apitrace-libs-7.1-7.fc27.x86_64 [...] Where should I submit a ticket for this? Thanks Sandro

3 4

CUPS will change license since 2.3 version - now incompatible with GPLv2
by Zdenek Dohnal 27 Feb '18

27 Feb '18

Hi, CUPS upstream changed license of project to Apache license 2.0, which is now incompatible with GPLv2. This change will be in new minor release of CUPS - 2.3.0, which is currently in developing phase (not in Fedora for now). If someone takes code of CUPS and has its project under GPLv2, please change it to GPLv3 (which should be compatible according https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#SoftwareLicenses ) or try to argument with CUPS developers against this change on their mailing list cups(a)cups.org . Is there someone who is influenced by this change? -- Zdenek Dohnal Associate Software Engineer Red Hat Czech - Brno TPB-C

17 43

← Newer
1
2
3
4
5
6
7
...
25
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel February 2018