kalev reported a new issue against the project: `releng` that you are following:
``
I'm getting the following when trying to build a flatpak for thunderbird:
```
$ fedpkg flatpak-build
Created task: 32963187
Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=32963187
Watching tasks (this may be safely interrupted)...
32963187 buildContainer (noarch): free
32963187 buildContainer (noarch): free -> open (buildvm-12.phx2.fedoraproject.org)
32963187 buildContainer (noarch): open (buildvm-12.phx2.fedoraproject.org) -> FAILED: Fault: <Fault 2001: 'Image build failed. Error in plugin orchestrate_build: \'{"aarch64": {"general": "\\\\"AllClustersFailedException(\\\'Could not find appropriate cluster for worker build.\\\')\\\\""}}\'. OSBS build id: thunderbird-master-79998-3'>
0 free 0 open 0 done 1 failed
32963187 buildContainer (noarch) failed
```
I assume this is fallout from https://pagure.io/releng/issue/8133 that added the aarch64 architecture to container build tags in koji.
@cverna @otaylor Any ideas?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8158
kalev reported a new issue against the project: `releng` that you are following:
``
Hi,
I just finished a new round of openh264 builds. Please sign and send the following to Cisco:
openh264-1.8.0-3.fc29
openh264-1.8.0-3.fc30
openh264-1.8.0-3.fc31
Thanks,
Kalev
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8157
zsun reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
This is a general question.
Given I am the LXQt spin maintainer, when I want to test my changes to kickstart files of generating livemedia, I need a way to try like the production.
I saw there is a page about [Building Images in Koji](https://docs.pagure.org/koji/image_build/). So I tried like that
```
koji spin-livemedia fedora-lxqt 30 f30 x86_64 ./flat-live-lxqt.ks --scratch
```
But I got
```
2019-02-20 11:20:15,915 [ERROR] koji: ActionNotAllowed: livemedia permission required
```
So my questions are
* Is the livemedia permission granted only to Release Engineering people, or also spin maintainers
* If this also grants to spin maintainers, can you grant me this permission?
* If this only grants to Release Engineering, can you provide some guide for building a livemedia like it does in Koji? I saw [this wiki](https://fedoraproject.org/wiki/Livemedia-creator-_How_to_create_and_u… already but I always need to set `selinux --permissive` to make a working Fedora Rawhide(f30) livemedia.
Thanks!
* When do you need this? (YYYY/MM/DD)
No ETA but as soon as possible
* When is this no longer needed or useful? (YYYY/MM/DD)
As long as I am still contributing to Fedora, this is still useful ;-)
* If we cannot complete your request, what is the impact?
Minimal. It just makes my work a little complex
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8145
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
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
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
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
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