mkisofs and genisoimage are dead. Please use xorriso instead.

You could probably get the arch from Koji for this...

Please use xorriso (standard CLI) or xorrisofs (mkisofs compatible CLI)

• About multiple archs - see changes I've did for kiwi #3211 (e.g. https://pagure.io/koji/pull-request/3211#_1__44) I'm just rewriting filenames to include arch. For log files on hub side there is an exception in https://pagure.io/koji/blob/master/f/hub/kojihub.py#_10385 I don't think it is a good idea to expand it more in that part of the code. It should be more near to the log/file source.
• download image artifacts from the build: koji download-build <nvr> --type=image
• logs - it would be nice to run mkisofs/xorrisof in verbose mode and capture that log separately (if it can provide more info than what will be present in mock_output.log

It raises a lot of flake8 errors (especially incoherent indenting) but it is of course simple to fix. I would also rename group dud to dud-build to be consistent with the rest of build groups. (I did it for kiwi in the last PR).

/me thinking: I've written kiwi plugin as py3 only as originally kiwi was meant to be installed on builder and it doesn't have py2 version. Anyway, now it runs inside the mock so this requirement is lifted. I wonder if I should it also backport to be 2.7 compatible...

• About multiple archs - see changes I've did for kiwi #3211 (e.g. https://pagure.io/koji/pull-request/3211#_1__44) I'm just rewriting filenames to include arch. For log files on hub side there is an exception in https://pagure.io/koji/blob/master/f/hub/kojihub.py#_10385 I don't think it is a good idea to expand it more in that part of the code. It should be more near to the log/file source.
• download image artifacts from the build: koji download-build <nvr> --type=image
• logs - it would be nice to run mkisofs/xorrisof in verbose mode and capture that log separately (if it can provide more info than what will be present in mock_output.log

It raises a lot of flake8 errors (especially incoherent indenting) but it is of course simple to fix. I would also rename group dud to dud-build to be consistent with the rest of build groups. (I did it for kiwi in the last PR).

/me thinking: I've written kiwi plugin as py3 only as originally kiwi was meant to be installed on builder and it doesn't have py2 version. Anyway, now it runs inside the mock so this requirement is lifted. I wonder if I should it also backport to be 2.7 compatible...

Regarding the xorriso logs, I think it is not worth extracting them apart, they do not provide much more info and can be checked in the mock_output.log.

Regarding the hub side logs, I think I did not get your message. Do you mean we should treat those logs inside the plugin itself? Something like moving or renaming them before the hub part does its log thing?

Regarding the xorriso logs, I think it is not worth extracting them apart, they do not provide much more info and can be checked in the mock_output.log.

agreed

Regarding the hub side logs, I think I did not get your message. Do you mean we should treat those logs inside the plugin itself? Something like moving or renaming them before the hub part does its log thing?

Yes, builder should rename the file before uploading it to the hub (adding architecture in the name).

Please update the documentation to note we're using xorrisofs.

Yes, builder should rename the file before uploading it to the hub (adding architecture in the name).

I may need some help in here. The logfiles (build.log, hw_info.log, mock_output.log, root.log and state.log) are created (and listed on the koji task UI) as soon as the child task starts running. Is it actually possible to rename them during the builder BuildRoot handler?

Before expiring my BuildRoot I can get to rename them, using workpath = koji.pathinfo.task(self.id), which is where they are ending up. The problem is that at this point I have no permissions to rename files in there.

For reference, I see in my tests that this comment does not seem to be true with the current code: https://imgur.com/a/698GsFW

I've lookg into that again and now I'm more persuaded to do system-level change supporting this. Filing #3229

You can try #3230

You can try #3230

Working fine with that. No problem building multiarch DUD's in both scratch and non-scratch builds.

s/dug-build-tag/dud-target/ or something similar to not confuse build tag with target.

I wonder if there is some reason for that (except of clarity). Code is not using anything specific to image channel (appliance-tools, imagefactory, ...). So it can run on any builder now, not? Maybe just rephrase it to as a hint but not strict requirement.

I wonder if there is some reason for that (except of clarity). Code is not using anything specific to image channel (appliance-tools, imagefactory, ...). So it can run on any builder now, not? Maybe just rephrase it to as a hint but not strict requirement.

Isn't this required when dealing with tasks based on BuildImageTask ? See https://pagure.io/koji/blob/master/f/plugins/builder/kiwi.py + https://pagure.io/koji/blob/master/f/docs/source/plugins.rst. This is where I took this from.

You've got me :-) It is a leftover of original kiwi work. In that moment I've had installed kiwi outside of buildroot (on builder) as there were no other way how to parse results file. Nevertheless, it is not true anymore and it is completely independent. I've created #3315 for myself.

You've got me :-) It is a leftover of original kiwi work. In that moment I've had installed kiwi outside of buildroot (on builder) as there were no other way how to parse results file. Nevertheless, it is not true anymore and it is completely independent. I've created #3315 for myself.

Done, I had forgotten about it.

Commit f61fbeb6 fixes this pull-request