rel-eng July 2019

rel-eng@lists.fedoraproject.org

9 participants
162 discussions

[releng] Issue #8504: unable to push fixes to python-ttystatus package
by Filipe Rosset 03 Jul '19

03 Jul '19

filiperosset reported a new issue against the project: `releng` that you are following: `` I'm trying to fix some broken packages, but I'm stuck with python-ttystatus, I cannot commit my changes to fix FTBFS: [filiperosset@raw python-ttystatus]$ git push Enter passphrase for key '/home/filiperosset/.ssh/id_rsa': Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 4 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 502 bytes | 502.00 KiB/s, done. Total 3 (delta 1), reused 0 (delta 0) remote: Branch refs/heads/master is unsupported remote: Denied push for ref 'refs/heads/master' for user 'filiperosset' remote: All changes have been rejected To ssh://pkgs.fedoraproject.org/rpms/python-ttystatus ! [remote rejected] master -> master (pre-receive hook declined) error: failed to push some refs to 'ssh://filiperosset@pkgs.fedoraproject.org/rpms/python-ttystatus' [filiperosset@raw python-ttystatus]$ `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8504

3 3

[releng] Issue #8507: F31 System-Wide Change:
by Ben Cotton 03 Jul '19

03 Jul '19

bcotton reported a new issue against the project: `releng` that you are following: `` Opening for impact check on behalf of @petersen, @pnemade, @mfabian: https://fedoraproject.org/wiki/Changes/Langpacks-core `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8507

2 2

[releng] Issue #8503: F31 system wide change: IBus 1.5.21 - request for review
by Takao Fujiwara 03 Jul '19

03 Jul '19

fujiwara reported a new issue against the project: `releng` that you are following: `` * Describe the issue I'd like to request review of IBus 1.5.21 for Fedora 31 from I18N team: https://fedoraproject.org/wiki/Changes/IBus_1.5.21 * When do you need this? Fedora 31 Mass Rebuild * When is this no longer needed or useful? Fedora 31 GA * If we cannot complete your request, what is the impact? Fedora Changes asks to get the impact from release-engineers. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8503

2 2

Fedora Release Engineering Meeting Summary for 2019-07-03
by Mohan Boddu 03 Jul '19

03 Jul '19

====================================== #fedora-meeting-2: RELENG (2019-07-04) ====================================== Meeting started by mboddu at 16:04:26 UTC. The full logs are available athttps://meetbot.fedoraproject.org/fedora-meeting-2/2019-07-03/releng.2019… . Meeting summary --------------- * init process (mboddu, 16:04:26) * EPEL8 (mboddu, 16:07:32) * fedpkg and fedscm-admin changes are tested in stage and are working. People can request epel8 branches just like they do for fedora release branches. (mboddu, 16:07:34) * ACTION: mboddu need to create pungi configs and scripts to run epel8 nightly composes (mboddu, 16:08:05) * #7400 Rethink how we handle networking config with createImage (oz / ImageFactory) (mboddu, 16:36:16) * LINK: https://pagure.io/releng/issue/7400 (mboddu, 16:36:21) * Alternate Architecture Updates (mboddu, 16:42:46) * Now we have a s390x buildvmhost now, and nirik have configured it but it has networking issues, once its sorted out, nirik will try to setup a guest builder on the buildvmhost and once tested, all the existing builders will moved (mboddu, 16:47:05) * Open Floor (mboddu, 16:47:17) Meeting ended at 16:50:44 UTC. Action Items ------------ * mboddu need to create pungi configs and scripts to run epel8 nightly composes Action Items, by person ----------------------- * mboddu * mboddu need to create pungi configs and scripts to run epel8 nightly composes * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * mboddu (47) * nirik (39) * zodbot (8) * puiterwijk (0) * jednorozec (0) * pbrobinson (0) * dustymabe (0) * ksinny (0) * sharkcz (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

[releng] Issue #7400: Rethink how we handle networking config with createImage (oz / ImageFactory)
by Adam Williamson 03 Jul '19

03 Jul '19

adamwill reported a new issue against the project: `releng` that you are following: `` I spent a bit of time digging into the issues around https://pagure.io/fedora-kickstarts/pull-request/366 this morning, and I figure we can improve this area more generally, but I don't think the optimal path is *completely* obvious, so I thought I'd file an issue for discussion before filing any PRs. As things stand, I believe, for all `createImage` tasks, we wind up with oz running the installer in a VM such that a single network interface is brought up, using a udev 'persistent' name. anaconda then writes out an ifcfg file for that 'persistent' name - e.g. `ifcfg-ens3` or `ifcfg-ens0p3` or something - to the installed system. If you poke about in fedora-kickstarts a bit, you'll find that five kickstarts then do stuff to try and 'clean this up'. We can ignore `fedora-cloud-bigdata` and `fedora-cloud-experimental`, I think, so we're left with `fedora-atomic`, which does this: bootloader --timeout=1 --append="no_timer_check console=tty1 console=ttyS0,115200n8 console=ttyAMA0 console=hvc0 net.ifnames=0" network --bootproto=dhcp --device=link --activate --onboot=on .... # Remove any persistent NIC rules generated by udev rm -vf /etc/udev/rules.d/*persistent-net*.rules # And ensure that we will do DHCP on eth0 on startup cat > /etc/sysconfig/network-scripts/ifcfg-eth0 << EOF DEVICE="eth0" BOOTPROTO="dhcp" ONBOOT="yes" TYPE="Ethernet" PERSISTENT_DHCLIENT="yes" EOF .... # For trac ticket https://pagure.io/atomic-wg/issue/128 rm -f /etc/sysconfig/network-scripts/ifcfg-ens3 `fedora-cloud-base`, which does this: bootloader --timeout=1 --append="no_timer_check net.ifnames=0 console=tty1 console=ttyS0,115200n8" network --bootproto=dhcp --device=link --activate --onboot=on .... # When we build the image with oz, dracut is used # and sets up a ifcfg-en<whatever> for the device. We don't # want to use this, we use eth0 so it is always the same. # So we remove all these ifcfg-en<whatever> devices so # The 'network' service can come up cleanly. rm -f /etc/sysconfig/network-scripts/ifcfg-en* And `fedora-disk-base`, which does this: network --bootproto=dhcp --device=link --activate bootloader --timeout=1 # The enp1s0 interface is a left over from the imagefactory install, clean this up rm -f /etc/sysconfig/network-scripts/ifcfg-enp1s0 Note they all do something different for trying to remove the 'predictably'-named interface configuration produced by the installer. We touched the `cloud-base` version most recently, and it's most probably the best approach. `disk-base` doesn't try to disable 'persistent' naming for the installed system, which I believe is intentional and correct, as that kickstart is for the ARM disk images which will be booted on real hardware with potentially varying network adapters and should probably respect the distro default to use 'persistent' naming on real hardware. I don't know how this results in the network coming up on first boot of these images, if it even does, but hey, that seems a bit out of scope. `atomic` and `cloud-base` both try to disable 'persistent' naming for the installed system. `cloud-base` used to try and do it just by removing udev rules, which was dumb, so @nirik recently changed that to add `net.ifnames=0` to the kickstart `bootloader` line, which basically disables udev 'predictable' naming (the udev rules will see the param and not rename the device). `atomic` seems to do a belt-and-braces approach ATM: it *both* sets `net.ifnames=0` in the `bootloader` line *and* tries to remove udev rules, badly (they don't live in `/etc/udev/rules.d` any more). One obvious cleanup would be to make all three use the `rm -f /etc/sysconfig/network-scripts/ifcfg-en*` strategy for removing the 'predictably'-named interface config file. Another obvious cleanup would be to take the udev rule deletion bits out of `fedora-atomic`, since they're not doing anyone any good there. There is another thing we can do, though. oz actually permits (since https://github.com/clalancette/oz/commit/14ad1922aa8c0922aaa2a3f9e52daa2692… , I think that's version 0.13.0) the passing of arbitrary extra kernel parameters to the installer, at least for the RHEL/Fedora 'url' install type, which is what `createImage` uses. You just have to add a `kernelparam` entry to the template. We could send a PR for Koji to use this to disable 'predictable' interface naming during the image creation; either to just *always* include a `kernelparam` value of `biosdevname=0 net.ifnames=0` for `createImage` tasks, or to make this configurable via the command line somehow and then have pungi / pungi-fedora pass it in for the images we want to use it for (handwave handwave). This should mean anaconda would write an `ifcfg-eth0` into the installed system, and for Atomic and Cloud images, in theory we wouldn't have to mung *anything* in the kickstart. @kevin points out that the file might in fact specify a MAC address, which we would have to filter out, but we might be able to tweak the kickstart to avoid that, I'll look into it. For ARM images, we'd just want to tweak the kickstart to remove that `ifcfg-eth0` file instead of the name it currently tries to remove - but this is slightly *better* than the current situation, where we've had at least one case where the 'predictable' interface name suddenly became unpredictable. At least in this particular workflow, the name `eth0` for the sole interface used during the image build should be *truly* predictable. Anyway, that's where I'm up to. Thoughts / comments / ideas on this? @kevin @mohanboddu @dustymabe @walters @mikem @lsedlar `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7400

4 6

[releng] Issue #8320: Side tag for Python 3.8
by Miro Hrončok 03 Jul '19

03 Jul '19

churchyard reported a new issue against the project: `releng` that you are following: `` * Describe the issue I'd kindly like to request a Fedora 29 side tag in koji for Python 3.7 rebuilds. See https://pagure.io/releng/issue/8092 Preferred tag/target name: f31-python Parent: f31-build ``` $ koji add-tag f31-python --parent=f31-build --arches='armv7hl i686 x86_64 aarch64 ppc64 ppc64le s390x' $ koji add-target f31-python f31-python ``` * When do you need this? (2019/05/26) * When is this no longer needed or useful? (2019-07-24) * If we cannot complete your request, what is the impact? We would not be able to rebuild Python 3.8. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8320

3 14

[Fedocal] Reminder meeting : Fedora Release Engineering
by mohanboddu＠fedoraproject.org 02 Jul '19

02 Jul '19

Dear all, You are kindly invited to the meeting: Fedora Release Engineering on 2019-07-03 from 16:00:00 to 17:00:00 UTC At fedora-meeting-2(a)irc.freenode.net The meeting will be about: Fedora Release Engineering weekly meeting Source: https://apps.fedoraproject.org/calendar/meeting/9274/

1 0

[releng] PR #8502: Fix the FTBFS weekly reminder hotfix
by Miro Hrončok 02 Jul '19

02 Jul '19

churchyard opened a new pull-request against the project: `releng` that you are following: `` Fix the FTBFS weekly reminder hotfix `` To reply, visit the link below or just reply to this email https://pagure.io/releng/pull-request/8502

2 1

[releng] Issue #8497: Orphan all packages of lef
by Miro Hrončok 02 Jul '19

02 Jul '19

churchyard reported a new issue against the project: `releng` that you are following: `` https://pagure.io/fesco/issue/2160 (I'm on it.) `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8497

2 3

[release] pungi 4.1.38
by Lubomír Sedlář 02 Jul '19

02 Jul '19

Hello everyone, a new version of Pungi is available! The 4.1.38 build is ready to be used. There are updates waiting in Bodhi to go to updates-testing. Here are the highlights of the release: * Configuration options were deprecated: runroot, release_is_layered. These options can be dropped from the config files, as the same information was already deducible from other options. * Temporary repositories created in pkgset phase now include modular metadata. This is required for upcoming DNF failsafe mechanism - it will reject repositories with modular packages without metadata. * Pkgset phase creates repositories in parallel. Hopefully this should make things slightly faster. And a couple other small fixes. Refer to the documentation [0] for details on what configuration options are available. [0] https://docs.pagure.org/pungi/index.html If you encounter problems or need general help, stop by #fedora-releng IRC channel or file issues in Pagure. Happy composing! Lubomír

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

rel-eng July 2019