Hi belze,
[snip]
Santa, i tried to build self-made packages using kdesrc-build but i had a lot of problems setting up all. I tried to use git from debian experimental - this went even worst. I'm not asking you to write a how-to, but it would be nice to have some hints/tips on how your work is made! [i admit i'm not following this forum as i did in the last years, maybe you did it i missed it). Thanks in advice.
Well, the answer is not simple for someone which is not familiar with packaging.
I started to work on debian packaging kde software in 2009, so I have now various years of experience in this area. In March 2013, in a true homage to Julius Caesar's death, I got expelled from the debian qt/kde "team" so I ended up packaging kde's software for siduction. The last year, given there was no frameworks/plasma5 packaging from debian's people at all, I started to contribute to kubuntu, making their packaging a bit more compatible with sid[uction] so I could re-use their packaging here. From a technical point of view, I acted like if I were still working for debian. The funny thing here is that debian ended up adopting the kubuntu's packaging too, so apparently my contributions in kubuntu will end up in debian, regardless of my exile.
The paragraph above is actually a longer and unpleasant story, so let's move on. I'm currently doing a port of kubuntu/debian's packaging applying some changes on top. I do these changes with some scriptery available here:
https://gitlab.com/siduction-tools/pkg-kde-automation/commits/masterSo this is my current workflow for KDE Frameworks. Plasma 5 and KDE Applications:
1. I sync my git local clones to the best kubuntu's branch to base our packaging (currently kubuntu_wily_archive)
2. I apply my changes with the scriptery mentioned above.
3. I build the source packages using the scriptery mentioned above and upload them to a "private" place of kdenext. The repository kdenext is hosted by a siduction server and is using reprepro to provide the repository.
4. Once the souce packages are uploaded, I have 3 virtual machines to build automatically the binary packages (i.e. the debs containing the built kde software) these 3 virtual machines are hosted in a server located in the office of my local linux user group, inside my university. There is a huge upload bandwith in my university to upload the resulting debs, and that's why I have that server there. The 3 virtual machines are running ubuntu server LTS, and this is what they do:
*
wannabuild - it has a wannabuild installed. wannabuild is the software I use to have a database of the packages status, so a machine with a buildd installed can check out this database, build the *.deb's and upload them to the private place of kdenext.
*
builldd - it has a buildd installed, so it checks the wanna-build database, builds the *.deb's for 64 bit and uploads them to the private place of kdenext.
*
buildd32 - same as buildd, but for 32 bits packages
This setup of kdenext + my 3 virtual machines are, in practice, like an ubuntu ppa.
5. At some point the buildd machines mentioned in "5." will either finish the package building or will get stuck with some problem which will need manual intervention by me, usually it's that the packaging needs any change. So I do the changes in the packaging I need to do; each manual change in the packaging falls into any of these categories:
a)
It's interesting for kubuntu: I send the patch to kubuntu's people so I don't have to apply the change the next time. NOTE: If the change gets applied in kubuntu it will probably end up in debian, since the packages available in debian are based on kubuntu's packages as well, in fact, the packages uploaded to debian experimental are a poor outdated port of kubuntu's packaging.
b)
I can't convince kubuntu's people to include my change or get's too much talking with them (already happened for very important changes): I add them to my scriptery, so I don't have to do the changes manually the next time.
c)
The change it's not relevant to kubuntu: I add the change to my scriptery
6. When everything is built I have a tool to check automatically the packages for problems, my tool provides me a web page similar to this one:
http://qa.kubuntu.co.uk/kf5-status/build_status_5.10.0_wily.htmlThis tool is a for of the tool used by kubuntu's people to generate that status webpage, it's source code is available here:
https://gitlab.com/siduction-tools/kdenext-build-status/commits/masterIf I found relevant problems checking the webpage generated by this tool, I usually do the needed changes in packaging and I repeat the same steps mentioned in "5." depending if my change falls into the category a) b) or c)
7. I also have a tool to check the installability of the packages, if there is something which needs to be fixed I fix it. The source code of this tool is available here:
https://gitlab.com/siduction-tools/kdenext-installabilityI try to send back the changes to kubuntu if possible as explained in "5."
8. When everything seems reasonably fine, I publish the packages and write a post in "Upgrade Warnings".
9. Depending on the feedback of you, the users, I may do some further changes in the packaging in the next days.
