devel February 2018

devel@lists.fedoraproject.org

237 participants
247 discussions

389-ds-base and freeipa on 32 bit arches
by Randy Barlow 02 Mar '18

02 Mar '18

Greetings gcc maintainers! A FESCo issue[0] has been filed due to the dropping of 389-ds-base and freeipa on 32 bit arches for Fedora 28. This was done without a change request being filed, so FESCo is trying to decide how best to handle it. It seems there are some concerns about whether the C tooling correctly handles some cases for 32-bit arches that led to the decision by the IPA maintainers to drop support for 32-bit. FESCo would like to ask for the GCC maintainers' input on the issue. Thanks in advance for your feedback! [0] https://pagure.io/fesco/issue/1845 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1544386

4 5

Add ability to check ABI compliance from fedpkg?
by Richard Shaw 01 Mar '18

01 Mar '18

I don't have to do it for many of my packages, but I do regularly check ABI compliance before performing an update so I know if I need to rebuild dependencies or not. Currently my workflow is something like: $ cd abicompare/<pkgname> $ mkdir <oldver> <newver> $ cd <oldver> (unpack pakage and -devel package) (same for <newver>) $ abi-compliance-checker -l <package> -vnum <newver> -dump <newver> $ abi-compliance-checker -l <package> -vnum <oldver> -dump <oldver> $ abi-compliance-checker -l <package> -old <oldabidump_dir> -new <newabidump_dir> $ scp -r <html_report> <fedorapeople>:public_html/compatibility_report/ It would be REALLY nice to automate this to any extent possible PRIOR to actually building a package (fedpkg <scratch-build | mockbuild>). I'm partial to abi-compliance-checker because I maintain it and I know how to interpret the results but any equivalent tool would be fine :) Thanks, Richard

2 1

Should we have a release manager for each release? (or, "who owns rawhide"?)
by Matthew Miller 01 Mar '18

01 Mar '18

As shown at https://www.happyassassin.net/nightlies.html, we haven't had a successful compose for almost two weeks. AIUI this is mostly worked out now, but it raises the question: who should be keeping track of this and coordinating fixes? For the releases, the blocker bug process basically handles this, so functionally the ownership ends up with QA (and the various heroes of QA who then track down all the problems). For rawhide, we don't have any such thing. Is it rel-eng? Is it FESCo? Is it the FPgM? Is it QA after all? I suspect that right now, the answer is kind of "It's all of us together", which unfortunately practically speaking often comes down to 0.02% per person and rounds down to 0. Or if the answer is: "Matthew, you are the FPL. It's you!" … then fine, but I'm going to then have to find some way to turn around and delegate. :) I was chatting with Kevin Fenzi and he suggested naming a release manager for each release — someone who would keep track of stuff starting at branch, and help coordinate things like this. This would help with more than just Rawhide — I'm sure everyone involved in the blocker bug process would be grateful for more help. At least, if it was someone who isn't already deeply involved in that. I'm thinking probably someone selected from FESCo — but it also could be a way for people with the particular set of skills required here to get involved in a way that's different from FESCo membership. What do you think? -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

18 41

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

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

Jump to page:

2025

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