rel-eng February 2019

rel-eng@lists.fedoraproject.org

9 participants
265 discussions

[releng] Issue #7498: Support on-the-fly tarball generation in Koji
by Florian Weimer 08 Jul '19

08 Jul '19

fweimer reported a new issue against the project: `releng` that you are following: `` I've just filed this fedpkg-minimal feature request: * https://bugzilla.redhat.com/show_bug.cgi?id=1578348 It would be great if we could get this to work on Fedora Koji, with a suitable whitelist of supported repositories. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7498

12 43

[releng] Issue #7393: perl component is missing from Fedora/Fedora Module product in Bugzilla
by Petr Pisar 08 Jul '19

08 Jul '19

ppisar reported a new issue against the project: `releng` that you are following: `` Bugzilla finally contains component for modules. But "perl" is still missing there (in contrast to "perl-bootstrap"). Please create "perl" component in Fedora/Fedora Module product with default assignee "ppisar(a)redhat.com". `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7393

4 12

[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 #7288: Request permissions to untag packages
by Jason ティビツ 26 Jun '19

26 Jun '19

tibbs reported a new issue against the project: `releng` that you are following: `` So I know I used to be able to untag a package but now that fails due to me not having autosign permissions (and probably other things). Today I merged a PR against redhat-rpm-config but wasn't able to test it sufficiently locally due to my local rawhide box not having received gcc 8 yet. I foolishly built it anyway and immediately broke all of rawhide. 100% my fault. It's a one line fix, but I can't untag it and nobody is online with permissions to do so. Since as of late I have been doing a number of changes to that and other related packages which can potentially break all of rawhide/fedora/epel, it would be useful for me to be able to untag in case something goes wrong. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7288

5 9

[releng] Issue #7753: Permission to change package owner (to reassign packages from nonrepsonsive packager procedure)
by Miro Hrončok 25 Jun '19

25 Jun '19

churchyard reported a new issue against the project: `releng` that you are following: `` * Describe the issue Recently, i deal with a lot of nonrepsonsive packagers and people ask to be assigned to those. I open releng tickets. It's a bit tedious. I cannot imagine how tedious this is for releng. Can I please be granted permission to reassign packages to different users? This might be the cvsadmin group. I'm already a provenpackager and I would only use this once the nonrepsonsive packager process is approved by FESCo. * When do you need this? The sooner the better. * When is this no longer needed or useful? This is always useful. * If we cannot complete your request, what is the impact? A lot of releng tickets from me. Thank you. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7753

5 23

[releng] Issue #7265: blender git repo contains large files causing git checkout to timeout during builds
by Richard Shaw 24 Jun '19

24 Jun '19

hobbes1069 reported a new issue against the project: `releng` that you are following: `` ``` From checkout.log: $ git clone -n https://src.fedoraproject.org/rpms/blender.git /var/lib/mock/f28-build-11036148-838686/root/tmp/scmroot/blender Cloning into '/var/lib/mock/f28-build-11036148-838686/root/tmp/scmroot/blender'... error: RPC failed; curl 18 transfer closed with outstanding read data remaining fatal: The remote end hung up unexpectedly fatal: protocol error: bad pack header ``` ``` $ git rev-list --objects --all | grep "\.rpm\|\.gz" 6115a22040643818e89404f301faa1d4a4ce4a56 results_blender/2.77a/1.fc23/blender-2.77a-1.fc24.src.rpm 2340a78e377e89c3a3b751a997ce0a563a9714ff results_blender/2.77a/1.fc23/blender-2.77a-1.fc24.x86_64.rpm 7966c177500299784bcaa963381f14b74eddc108 results_blender/2.77a/1.fc23/blender-debuginfo-2.77a-1.fc24.x86_64.rpm 014423f48c5697e0c256cc93c789823800883d85 results_blender/2.77a/1.fc23/blender-rpm-macros-2.77a-1.fc24.noarch.rpm e2e943ce223ac62904fde4717ceac8e4f3387018 results_blender/2.77a/1.fc23/blenderplayer-2.77a-1.fc24.x86_64.rpm e3c53ce853edd37b76bc5b4d422f85b14a1a10c5 results_blender/2.77a/1.fc23/fonts-blender-2.77a-1.fc24.noarch.rpm 5b6716c806f9ef18beaeed55beb07b2c162179b6 results_blender/2.77a/1.fc26/blender-2.77a-1.fc26.src.rpm 12a5eee6eb79f3ec8c257cc4b02a16e1c0774966 results_blender/2.77a/1.fc26/blender-2.77a-1.fc26.x86_64.rpm 8a7e6d7dc970f5b1fdd66e9a9e57e814db4de9a2 results_blender/2.77a/1.fc26/blender-debuginfo-2.77a-1.fc26.x86_64.rpm ac7b7d731e06bf30deb8cfcbbf2a7002b3cef7c4 results_blender/2.77a/1.fc26/blender-rpm-macros-2.77a-1.fc26.noarch.rpm 9b783965dbe33cdc8a670a70d5212e62442094ec results_blender/2.77a/1.fc26/blenderplayer-2.77a-1.fc26.x86_64.rpm dee39b967a93774562690fc7a898013bbdd831e5 results_blender/2.77a/1.fc26/fonts-blender-2.77a-1.fc26.noarch.rpm 7bffb5068eb55df30d688d8608cd9264a77c8cf3 results_blender/2.78/1.fc26/blender-2.78-1.fc26.src.rpm c89795526e03033ff0255495f94ced42cea86271 results_blender/2.78/1.fc26/blender-2.78-1.fc26.x86_64.rpm 12907ae1397483d284498820e3fac62ad7e17c07 results_blender/2.78/1.fc26/blender-debuginfo-2.78-1.fc26.x86_64.rpm b518a731b7f38961433cbf8f6b2b9c4716fce785 results_blender/2.78/1.fc26/blender-rpm-macros-2.78-1.fc26.noarch.rpm 4cd2e44e3562eb77ddf4c3193e80f69389469090 results_blender/2.78/1.fc26/blenderplayer-2.78-1.fc26.x86_64.rpm 6459a4e4cf1ac226117b091ddd7a59bec6cfc6b5 results_blender/2.78/1.fc26/fonts-blender-2.78-1.fc26.noarch.rpm 30bb773c1b4242fdb48b33788e53374a4a900e14 blender-2.77a-1.el7.src.rpm a6c477b254d54ebe07ed11df6b2ec41e132ddded blender-2.77a-1.fc23.src.rpm a34c5c49de2fcd378e3d7f74cecfc1dcf77082af blender-2.77a-1.fc26.src.rpm e17f27a4415c31a747f76e10a68e592bf5d25b47 blender-2.78-1.el7.src.rpm 0e7cb8ad4bf7571ac1123c853e5636854e622124 blender-2.78-1.fc26.src.rpm a4a9f0f6a24e622799cfefccf1804cae48cdfcae blender-2.78.tar.gz ``` Can these files be removed? `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7265

7 12

[releng] Issue #8129: Changes/BuildRequires Generators
by Igor Gnatenko 23 Jun '19

23 Jun '19

ignatenkobrain reported a new issue against the project: `releng` that you are following: `` ### Describe the issue Please take a look at https://fedoraproject.org/wiki/Changes/BuildRequires_Generators. This will definitely affect releng, although I'm not entirely sure in which way (apart from installing latest mock on builders). Also it would probably mean that src.rpm won't contain all required dependencies, but rather somnething like `rust-packaging`. That means, it would be still possible to build packages from same SRPM, but probably won't be enough to query.. This is still under discussion in upstream RPM/mock how we will handle this. If you have any specific requirement, let me know. ### When do you need this? (YYYY/MM/DD) ASAP, as usual. ### When is this no longer needed or useful? (YYYY/MM/DD) It is really useful, trust me in it! ### If we cannot complete your request, what is the impact? Fedora will stuck in old century =( `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8129

4 9

[releng] Issue #8080: rsync temporaries under /alt/risc-v
by Jason ティビツ 20 Jun '19

20 Jun '19

tibbs reported a new issue against the project: `releng` that you are following: `` I've talked about this in IRC, but I figured I would open an issue for it. Whatever process is responsible for copying content into /alt/risc-v does so by calling rsync without --delay-updates. This means that rsync temporaries can appear anywhere in that directory structure. These temporaries are world-readable, and so the file list generator will include them in the file listings of the mirror. So quick-fedora-mirror will try to copy them, and this causes a failure: ``` Looks like the file list is outdated. rsync: link_stat "/alt/risc-v/repo/fedora/29/24607/src/Packages/i/.initial-setup-0.3.62-2.fc29.src.rpm.UQ5u2x" (in fedora-buffet0) failed: No such file or directory (2) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1659) [generator=3.1.3] rsync failed; aborting run. Will not check in or delete anything. ``` This seems to happen a couple of times a week, though of course it's quite random. The simplest solution seems to me to be to call rsync with --delay-updates. This will make rsync store the temporaries in a directory named `.~tmp~` which the file list generator and other rsync process should conveniently skip. It's much easier to skip one file with a weird name than it is to try and figure out what might be an rsync temporary. (Starts with a dot and ends with a dot followed by maybe six alphanumerics is the best we could do, which doesn't seem particularly safe.) `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8080

6 9

[releng] Issue #8173: Base container image compose fails on f29 because of the arm32 builder
by Clement Verna 19 Jun '19

19 Jun '19

cverna reported a new issue against the project: `releng` that you are following: `` * Describe the issue The base container image compose is failing because the arm32 builder is running out of memory. ``` ApplianceError: Image status is FAILED: internal error: process exited while connecting to monitor: 2019-02-27T06:46:23.311581Z qemu-system-arm: cannot set up guest memory 'mach-virt.ram': Cannot allocate memory ``` https://koji.fedoraproject.org/koji/taskinfo?taskID=33076997 * When do you need this? (YYYY/MM/DD) * When is this no longer needed or useful? (YYYY/MM/DD) * If we cannot complete your request, what is the impact? `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8173

6 19

[releng] Issue #7995: Automate Unretirement and Unorphan procedures
by Mohan Boddu 19 Jun '19

19 Jun '19

mohanboddu reported a new issue against the project: `releng` that you are following: `` * Describe the issue Currently its a manual process to unretire a package and it is described in https://docs.pagure.org/releng/sop_unretire.html (unorphan is nothing but assigning the package to the requestor which is also part of that sop - https://docs.pagure.org/releng/sop_unretire.html#verify-package-is-not-orph…) It would be great if the process is automated. It cannot be fully automated, but a script that runs the unretirement rather than running each step manually. * When do you need this? (YYYY/MM/DD) Sooner the better * When is this no longer needed or useful? (YYYY/MM/DD) There will be always unretirement requests * If we cannot complete your request, what is the impact? Someone has to run the steps manually every time there is a unretirement request. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7995

7 12

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

rel-eng February 2019