[aur-general] Updating MATE Packages
Hello All, A couple weeks ago I found out that Martin was no longer going to be able to maintain the MATE desktop packages for Arch Linux [1] [2]. I had a chat with Martin on IRC and confirmed that MATE would need a new maintainer. Since then I've been working on updating the relevant MATE PKGBUILD's from 1.12 to 1.14. I've been getting spun up with how Arch maintains packages, learning more about the PKGBUILD creation and updating processes, and getting set up on the various mailing lists and my AUR profile. The question comes now how do I get these updated PKGBUILD's to the community? If the packages are bumped down from [Community] to the AUR, I would be more than happy to maintain them there. If/when I earn TU status, I would then move them back to the official [Community] repository. The drawback there is a major DE would no longer be in an official Arch repository and would require users manually building each updated PKGBUILD or to use an AUR helper. Alternatively, perhaps a current TU could use my updated PKGBUILD's to get MATE 1.14 out to the community while I work on earning TU status and can then maintain the packages directly at a later date. To head off any ideas about my motivations here, I am not trying to leverage this issue to bypass or fasttrack past any TU requirements. I realize I'm pretty much unknown in the Arch community. I would like to change that with good work. To the matter at hand, what is going to be the best way to get the MATE packages updated? What is my next step in that process? I'm eager to get my hands dirty helping out with maintaining MATE (and other packages as well). Thank you, Sean Fennell <eadrom> [1] https://lists.archlinux.org/pipermail/aur-general/2016-May/032306.html [2] https://www.reddit.com/r/archlinux/comments/4kakzk/
Sean Fennell <eadrom> wrote:
Hello All,
A couple weeks ago I found out that Martin was no longer going to be able to maintain the MATE desktop packages for Arch Linux [1] [2]. I had a chat with Martin on IRC and confirmed that MATE would need a new maintainer. Since then I've been working on updating the relevant MATE PKGBUILD's from 1.12 to 1.14. I've been getting spun up with how Arch maintains packages, learning more about the PKGBUILD creation and updating processes, and getting set up on the various mailing lists and my AUR profile.
The question comes now how do I get these updated PKGBUILD's to the community? If the packages are bumped down from [Community] to the AUR, I would be more than happy to maintain them there. If/when I earn TU status, I would then move them back to the official [Community] repository. The drawback there is a major DE would no longer be in an official Arch repository and would require users manually building each updated PKGBUILD or to use an AUR helper. Alternatively, perhaps a current TU could use my updated PKGBUILD's to get MATE 1.14 out to the community while I work on earning TU status and can then maintain the packages directly at a later date.
To head off any ideas about my motivations here, I am not trying to leverage this issue to bypass or fasttrack past any TU requirements. I realize I'm pretty much unknown in the Arch community. I would like to change that with good work.
To the matter at hand, what is going to be the best way to get the MATE packages updated? What is my next step in that process? I'm eager to get my hands dirty helping out with maintaining MATE (and other packages as well).
Thank you,
Sean Fennell <eadrom>
[1] https://lists.archlinux.org/pipermail/aur-general/2016-May/032306.html [2] https://www.reddit.com/r/archlinux/comments/4kakzk/
As a recent convert to MATE (coming from XFCE), I wish you the best of luck. It looks like Manjaro is maintaining their own MATE packages [0]. I am not sure if you were aware of this, but if you were not then this should help tremendously. I experimented a little and successfully built all the GTK2 (stable) versions of 1.14 [1]. Most of the effort was building things in the right order (Take a look at make-gtk2.sh in [1].). I did not need to modify any of the PKGBUILDS from Manjaro. I hope you may find this useful. MATE is certainly seeing far more active development than XFCE at this point. XFCE is unfortunately making the Netscape mistake of focusing on rewriting all their code so it compiles with GTK3. (In fact, they have no new features planned for the next release.) It will most likely be years before we see new things and fixes come out of XFCE (and the GTK3 change will likely introduce more regressions). So, MATE is like a breath of fresh air. Personally, I would really like to see MATE stay in community where everyone can easily install it. The way I see the problem, all we need to do is build the PKGBUILDS from Manjaro and have someone from Arch officially vet them. Will a TU please help us? --Kyle [0]: https://github.com/manjaro/packages-community/tree/master/mate [1]: https://gitlab.com/KlipKyle/mate-pkgbuilds
Sean Fennell <eadrom> wrote:
To the matter at hand, what is going to be the best way to get the MATE packages updated? What is my next step in that process? I'm eager to get my hands dirty helping out with maintaining MATE (and other packages as well).
Thank you,
Sean Fennell <eadrom>
I agree that it's not good that we ship an unmaintained desktop environment in our repos. DEs need constant work to be properly maintained (not just updating packages, but also fixing bugs, backporting fixes needed for new versions of libraries...) and unfortunately no current TU seems to be interested in MATE. If you plan to step up to maintain this in the future, one first step would be to post your updated PKGBUILDs somewhere so that we could check them out.
On 06/11/2016 04:55 AM, Antonio Rojas wrote:
If you plan to step up to maintain this in the future, one first step would be to post your updated PKGBUILDs somewhere so that we could check them out.
I've uploaded my updated PKGBUILD's to GitHub. [1] I've noticed a few of the packages are split packages for GTK2 and GTK3 while most of them are seperate packages for GTK2 and GTK3 versions. For MATE 1.14, I would like to have both GTK2 and GTK3 versions available. For future stable releases, MATE should be ready for GTK3 primetime. The Ubuntu MATE team is working on getting their MATE 1.14 ready for GTK3 only for their 16.10 release. The Ubuntu MATE team works closely with upstream MATE, so the next stable MATE release should have all their patches upstreamed by then and so I'm expecting MATE to have a pretty solid GTK3 only release for 1.16. I'm still getting up to speed on the development side of Arch. I've not altered the PKGBUILD's in any major ways, outside of bringing them up to 1.14. If there are major changes that need to be made or any tips or other helpful and constructive criticism, I welcome the feedback. [1] https://github.com/Eadrom/arch_mate -- Sean Fennell <eadrom>
Sean Fennell <eadrom> wrote:
I'm still getting up to speed on the development side of Arch. I've not altered the PKGBUILD's in any major ways, outside of bringing them up to 1.14. If there are major changes that need to be made or any tips or other helpful and constructive criticism, I welcome the feedback.
I haven't looked in detail, just a couple of comments: - If the GTK2 and GTK3 versions are built from the same source, then a split GTK2/GTK3 package is the way to go. Having separate PKGBUILDs for each version just doubles the maintenance work for no good reason (every fix and update would need to be applied twice). - You should remove the install files that run commands already handled by hooks. See https://www.archlinux.org/todo/hooks-part-1/
On 2016-06-12 14:49, Antonio Rojas wrote:
Sean Fennell <eadrom> wrote:
I'm still getting up to speed on the development side of Arch. I've not altered the PKGBUILD's in any major ways, outside of bringing them up to 1.14. If there are major changes that need to be made or any tips or other helpful and constructive criticism, I welcome the feedback.
I haven't looked in detail, just a couple of comments:
- If the GTK2 and GTK3 versions are built from the same source, then a split GTK2/GTK3 package is the way to go. Having separate PKGBUILDs for each version just doubles the maintenance work for no good reason (every fix and update would need to be applied twice). - You should remove the install files that run commands already handled by hooks. See https://www.archlinux.org/todo/hooks-part-1/
I talked with Martin about it and as far as I remember, there was no way to tell MATE build system to prefer GTK2 over GTK3 (and vice versa) if both were installed. Bartłomiej
Bartłomiej Piotrowski wrote:
I talked with Martin about it and as far as I remember, there was no way to tell MATE build system to prefer GTK2 over GTK3 (and vice versa) if both were installed.
Bartłomiej
This seems to have changed now: $ ./configure --help | grep with-gtk --with-gtk=2.0|3.0 which gtk+ version to compile against (default: 2.0)
Sean Fennell <eadrom> wrote:
I'm still getting up to speed on the development side of Arch. I've not altered the PKGBUILD's in any major ways, outside of bringing them up to 1.14. If there are major changes that need to be made or any tips or other helpful and constructive criticism, I welcome the feedback.
I haven't looked in detail, just a couple of comments:
- If the GTK2 and GTK3 versions are built from the same source, then a split GTK2/GTK3 package is the way to go. Having separate PKGBUILDs for each version just doubles the maintenance work for no good reason (every fix and update would need to be applied twice). - You should remove the install files that run commands already handled by hooks. See https://www.archlinux.org/todo/hooks-part-1/
@eadrom: If it's a matter of time I could help you out a little bit. For example I could handle the .install files if you haven't done that already. Let me know (email me) if you are interested... Regards, Michael
On 06/12/2016 05:49 AM, Antonio Rojas wrote:
I haven't looked in detail, just a couple of comments:
- If the GTK2 and GTK3 versions are built from the same source, then a split GTK2/GTK3 package is the way to go. Having separate PKGBUILDs for each version just doubles the maintenance work for no good reason (every fix and update would need to be applied twice). - You should remove the install files that run commands already handled by hooks. See https://www.archlinux.org/todo/hooks-part-1/
I've done my first pass at updating the packages to use hooks. [1] From what andreyv from #aur-general IRC told me, I just need to add the package that provides the hook to the PKGBUILD's depends() array to set the hooks needed. The documentation is kinda sparse on the process, at least what I could find. If anyone has some detailed documentation on how to update from .install to pacman 5.0 hooks or hooks in general, I would love to read it so I can better understand what's going on. I found Allan's blog and an Andrew's github with examples, but that was pretty much it. Mayhaps my Google-fu was not strong enough. If I've setup the hooks correctly, then I'll next work on sorting out the GTK2/GTK3 split packages. This'll be nice once that work is done because it'll mean in the long run, there will be fewer packages to maintain. I would really appreciate it if someone could check a few of my PKGBUILD's to make sure I'm doing hooks correctly and my understanding of them is correct. Thank you! -- Sean Fennell <eadrom> [1] https://github.com/Eadrom/arch_mate
Sean Fennell <eadrom> wrote:
- If the GTK2 and GTK3 versions are built from the same source, then a split GTK2/GTK3 package is the way to go. Having separate PKGBUILDs for each version just doubles the maintenance work for no good reason (every fix and update would need to be applied twice). - You should remove the install files that run commands already handled by hooks. See https://www.archlinux.org/todo/hooks-part-1/
I've done my first pass at updating the packages to use hooks. [1]
From what andreyv from #aur-general IRC told me, I just need to add the package that provides the hook to the PKGBUILD's depends() array to set the hooks needed. The documentation is kinda sparse on the process, at least what I could find. If anyone has some detailed documentation on how to update from .install to pacman 5.0 hooks or hooks in general, I would love to read it so I can better understand what's going on. I found Allan's blog and an Andrew's github with examples, but that was pretty much it. Mayhaps my Google-fu was not strong enough.
Packages such as desktop-file-utils, shared-mime-info or glib2 don't need to be explicitely added as dependencies since gtk already depends on them. Namcap should warn you about this. Other than that, LGTM.
If anyone has some detailed documentation on how to update from .install to pacman 5.0 hooks or hooks in general, I would love to read it so I can better understand what's going on.
Just remove the install files. It's all handled automatically by the hooks. Look at the update-mime-database.hook for example [Trigger] Type = File Operation = Install Operation = Upgrade Operation = Remove Target = usr/share/mime/packages/*.xml [Action] Description = Updating the MIME type database... When = PostTransaction Exec = /usr/bin/update-mime-database /usr/share/mime This hook will be executed whenever a *.xml file in /usr/share/mime/packages is installed/changed/removed by pacman. So you don't have to care about if a package contains such a file anymore. The hook does it for you. Please correct me if I'm wrong. Michael
Just remove the install files.
A little addition: If it runs commands that are not handled by hooks, keep it and remove only the commands (if there are any) that are handled by hooks from the file.
On 06/12/2016 05:49 AM, Antonio Rojas wrote:
- If the GTK2 and GTK3 versions are built from the same source, then a split GTK2/GTK3 package is the way to go. Having separate PKGBUILDs for each version just doubles the maintenance work for no good reason (every fix and update would need to be applied twice). - You should remove the install files that run commands already handled by hooks. See https://www.archlinux.org/todo/hooks-part-1/
Quick update on my progress. I've completed my first pass on merging the GTK2 and GTK3 PKGBUILD's into one. I'm not sure on if I've handled dependencies correctly. I've left the GTK2 dependencies as the main package depends() array and then added in the GTK3 versions needed depends() in its package() function. Then I added any packages that the GTK3 version needed, but not the GTK2 version, to the makedepends() array. I'm sure I'll quickly find I've done this wrong when I go to start build testing here shortly, heh. If anyone has feedback on how I should be handling dependencies for this kind of split package, I welcome the help! Latest changes viewable here: https://github.com/Eadrom/arch_mate -- Sean Fennell <eadrom>
Quick update on my progress. I've completed my first pass on merging the GTK2 and GTK3 PKGBUILD's into one. I'm not sure on if I've handled dependencies correctly. I've left the GTK2 dependencies as the main package depends() array and then added in the GTK3 versions needed depends() in its package() function. Then I added any packages that the GTK3 version needed, but not the GTK2 version, to the makedepends() array.
There's no need to have a top-level depends array, and in fact most split packages don't have one. Just drop it and move all build time dependencies for both versions to the makedepends array
Sean Fennell <eadrom> wrote:
On 06/11/2016 04:55 AM, Antonio Rojas wrote: I've uploaded my updated PKGBUILD's to GitHub. [1]
I've noticed a few of the packages are split packages for GTK2 and GTK3 while most of them are seperate packages for GTK2 and GTK3 versions. For MATE 1.14, I would like to have both GTK2 and GTK3 versions available. For future stable releases, MATE should be ready for GTK3 primetime. The Ubuntu MATE team is working on getting their MATE 1.14 ready for GTK3 only for their 16.10 release. The Ubuntu MATE team works closely with upstream MATE, so the next stable MATE release should have all their patches upstreamed by then and so I'm expecting MATE to have a pretty solid GTK3 only release for 1.16.
I'm still getting up to speed on the development side of Arch. I've not altered the PKGBUILD's in any major ways, outside of bringing them up to 1.14. If there are major changes that need to be made or any tips or other helpful and constructive criticism, I welcome the feedback.
This may sound like a silly question, but how are you building packages in bulk? Are you using a home-brewed script like I did a week ago [0], or are you building each package by hand? In the case of the latter, would you like help automating stuff? --Kyle [0] https://gitlab.com/KlipKyle/mate-pkgbuilds/blob/master/make-gtk2.sh
On 06/12/2016 10:51 AM, Kyle Terrien via aur-general wrote:
This may sound like a silly question, but how are you building packages in bulk? Are you using a home-brewed script like I did a week ago [0], or are you building each package by hand?
In the case of the latter, would you like help automating stuff?
--Kyle
[0] https://gitlab.com/KlipKyle/mate-pkgbuilds/blob/master/make-gtk2.sh
I'm using namcap to check my PKGBUILD's as I go along, but I've yet try and build them until after I sorted through the hooks and cleaning up of split packages. I tried using extra-{i686,x86_64}-build, but right away ran into the whole needing to build them in the correct order issue when I tried building atril. I'm planning on using a clean VM and figuring out the correct order and then building and installing them there to test and make sure the packages will build. In your make-gtk2.sh script, it looks like you build mate-common and then work through a list of packages. Is that list in the correct order in which they need to be built? If so, that'll make it a much easier time for me when I go to test building my PKGBUILD's. Thank you for sharing that script! -- Sean Fennell <eadrom>
Sean Fennell <eadrom> wrote:
On 06/12/2016 10:51 AM, Kyle Terrien via aur-general wrote:
[0] https://gitlab.com/KlipKyle/mate-pkgbuilds/blob/master/make-gtk2.sh
I'm using namcap to check my PKGBUILD's as I go along, but I've yet try and build them until after I sorted through the hooks and cleaning up of split packages. I tried using extra-{i686,x86_64}-build, but right away ran into the whole needing to build them in the correct order issue when I tried building atril. I'm planning on using a clean VM and figuring out the correct order and then building and installing them there to test and make sure the packages will build.
In your make-gtk2.sh script, it looks like you build mate-common and then work through a list of packages. Is that list in the correct order in which they need to be built? If so, that'll make it a much easier time for me when I go to test building my PKGBUILD's.
Thank you for sharing that script!
I'm 90% certain that the order is correct. It's a little hard to know for sure because MATE 1.12 is still in community. Almost everything depends on either mate-common or mate-desktop either directly or indirectly. That is why they are built first. After that, every package from MATE is installed as needed from the temporary repo. The reason why I setup a temporary repo for the chroot is because many of the PKGBUILDS are split PKGBUILDS that build conflicting gtk2 and gtk3 packages, and those cannot be installed in the same chroot. It took about half an hour for all of GTK2 MATE to build on my Bloomfield i7 920 system. (If you do find a discrepancy in the build order, please let me know. I'm genuinely curious.) I based the build order on the Install Guidelines [1] as best as I could. And the PKGBUILDs are taken directly from Manjaro, where they have their own guy maintaining MATE packages [2]. I suspect that building all the gtk3 versions just involves modifying my script to refer to the gtk3 packages. --Kyle [1]: http://wiki.mate-desktop.org/building [2]: https://github.com/manjaro/packages-community/tree/master/mate
participants (5)
-
Antonio Rojas
-
Bartłomiej Piotrowski
-
Kyle Terrien
-
Michael Straube
-
Sean Fennell <eadrom>