<davidlt[m]>
So the 1st command configures Koji internal COMPS (package groups). Each group is used to create chroot/container environment for the task to be executed.
<davidlt[m]>
The 2nd command is adding packages to a particular tag. Basically which packages belong to Fedora fXY release.
<davidlt[m]>
Those two things have separate uses-cases.
<davidlt[m]>
The same groups exist in upstream Koji too. They are configured exactly in the same way.
<davidlt[m]>
For example there is a task in Koji that generated SRPM. That tasks will look at the build tag, check the group list for srpm-build and generated rootfs/chroot/container root image. That task will be executed in that environmen.t
<davidlt[m]>
The package itself for that SRPM must be part of the tag (destination tag) that you are building for.
<davidlt[m]>
So if you are building binutils, it needs to be part of f38.
<davidlt[m]>
If you are executing: `koji build --nowait f38 <..>`
kalev has joined #fedora-riscv
kalev has quit [Quit: leaving]
kalev has joined #fedora-riscv
fuwei has joined #fedora-riscv
<Entei[m]>
<davidlt[m]> "The 2nd command is adding..." <- So this would be the package I wish to rebuild right?
<davidlt[m]>
Yes.
<davidlt[m]>
In this case you would need to just export and import the list of Fedora XY package list.
<davidlt[m]>
In both cases it's just copy & paste from upstream Koji.
<Entei[m]>
<davidlt[m]> "In this case you would need to..." <- Umm...wouldn't specifying packages from comps be part of 1st command?
<Entei[m]>
In second command I specify some random package I wish to build and my tag
<davidlt[m]>
Yes
<davidlt[m]>
The 1st command is only done once per tag creation for the release, and you basically never touch it again unless there is a reason (which will almost never happen).
<Entei[m]>
davidlt[m]: no I am currently just trying everything on x86, will later deploy on riscv64
<davidlt[m]>
I wonder if this is because you have 0 builds.
<davidlt[m]>
I never really had 0 builds in the tag.
<Entei[m]>
In this command `$ koji add-pkg --owner <kojiuser> dist-foo <pkg1> <pkg2> .....`
<Entei[m]>
Does owner refer to host or user? I have put kojiadmin as user.
<davidlt[m]>
User. I can be anything, doesn't matter much.
<Entei[m]>
davidlt[m]: But I have to start somewhere....
<davidlt[m]>
Also enable full debug messages on koji-web, this way you can always give a look at code to see what it actually wants here.
<Entei[m]>
<davidlt[m]> "Import some random package..." <- imported the package hello with `koji import`, still gives the same error when trying to regen repo
<davidlt[m]>
Do something like this: koji import --create-build *.rpm
<davidlt[m]>
Then `koji call tagBuildBypass f38 <build> force=1`
<davidlt[m]>
Kojira should kick-in automatically and schedule internal Koji repo rebuild.
<davidlt[m]>
Oh, f37 in your case instead of f38.
<davidlt[m]>
I have been rebasing kernel-ark to 6.4 this morning. My head is still not back in the game.
<davidlt[m]>
For example, python-pyqt6-6.5.1-5.fc38
<davidlt[m]>
It will directly tag this build in the main Koji server instead of spinning a task for the builder to tag it. It just makes things a bit faster here.
<Entei[m]>
koji call tagBuildBypass f37 hello-2.10-8.fc37 force=1
<Entei[m]>
None
<davidlt[m]>
Yeah, now if you look at build information it should mention that build belongs to f37 tag.
<davidlt[m]>
If Kojira is running it should notice tag change and trigger a repo gen for the relevant tags.
<Entei[m]>
Kojira did kick in but failed with the same repo directory missing error
<davidlt[m]>
Maybe something failed in /mnt/koji because of wrong SELinux labels/etc. Check the logs.
<davidlt[m]>
It could be that it wasn't allowed to create directory.
<Entei[m]>
davidlt[m]: I've disabled selinux for these tests...
<davidlt[m]>
Still check the logs, usually you can find the answers there.
<Entei[m]>
davidlt: I think I somehow solved it. regen-repo got success this time.
<Entei[m]>
In kojid.conf, I forgot to specify `topdir` in my script. Also changed `use_createrepo_c` to True. Don't think the latter would have made the difference since on Fedora createrepo is just symlink to createrepo_c.
<Entei[m]>
But hey at least some success. Thanks a lot.
<davidlt[m]>
createrepo_c is default for some years now.
<Entei[m]>
Judging from it trying to open some html files, maybe I didn't put the allowed_scms link properly
<davidlt[m]>
The builder access /mnt/koji (and the whole info) via HTTP(s).
<davidlt[m]>
That's why topurl exist IIRC.
<Entei[m]>
I'll specify the chroot_tmpdir parameter. Isn't specified by default in my config. I thought it would take it by default since it's supposed to be default
<davidlt[m]>
Thus I assume this received apache 404 webpage instead of whatever it needed.
<Entei[m]>
davidlt: For now I just gave it locally downloaded srpm, it built successfully 😀. Not sure what's going on with scm link, but that can be managed later.
<Entei[m]>
Thanks a lot for all the help. This was one of the most unexpected place to get help on Koji, I have tried on fedora-devel room and fedora discussions forum, no one else has actively helped me. My sincere thanks.
<davidlt[m]>
I think there are only a few folks that could actually help.
<davidlt[m]>
mock development IRC channel might be a good place too.
<davidlt[m]>
But in general it would be relatively hard to get prompt reaction.
<davidlt[m]>
Well, I wasn't really active for the last two weeks either.
zsun has joined #fedora-riscv
<rwmjones>
davidlt[m]: re TH1520 yes, but it's still running off the SD card
<davidlt[m]>
Ah, no USB driver in the kernel?
<rwmjones>
I'd need to rebuild the initrd
<davidlt[m]>
rwmjones: while working on kernel-ark v6.4 rebase I got impression that VF2 / JH7110 should be ready for Fedora/RISCV.
<davidlt[m]>
Well, v6.6 will have it ready.
<davidlt[m]>
But in general it's probably safe to do v6.4 + v6.5 backports + other things.
<davidlt[m]>
I have a feeling most things will get merged into v6.6.
<davidlt[m]>
But I don't think there is any improvement on TH1520 front, but I haven't been in the loop for some time.
esv has quit [Remote host closed the connection]
<davidlt[m]>
I wish folks wouldn't use "risc-v" in the emails, patches, etc.
<davidlt[m]>
I see v6.4.5 was released and incl. a few patches for riscv64, but there will be more coming from what I can see.
<conchuod>
davidlt[m]: start with palmer on that front!
<conchuod>
It'd be nice if everyone used the same thing, but you get "RISC-V" "risc-v" "riscv" and sometimes even "Riscv" and "Risc-v"
<davidlt[m]>
Yeah, and I am annoyed to search for all of those.
<davidlt[m]>
rwmjones: check your boards
<davidlt[m]>
both stopped talking to Koji ~1+ hour ago.
<sorear>
case sensitive?
<rwmjones>
davidlt[m]: both boards look ok here; I can reboot them if you want
<davidlt[m]>
rwmjones: check kojid logs
<davidlt[m]>
they aren't talking to the server.
<davidlt[m]>
might be something stupid like kojid timting out on something, or whatever.
<rwmjones>
they both look fine to me; I can restart kojid if you like
<davidlt[m]>
yeah, kick kojid or reboot the boards if there is something crazy on dmesg