Bug 1170875
Summary: | Review Request: budgie-desktop - An elegant desktop with GNOME integration | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Michel Lind <michel> | ||||||
Component: | Package Review | Assignee: | Zbigniew Jędrzejewski-Szmek <zbyszek> | ||||||
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | rawhide | CC: | abc.mikey, carl, diazbastian, ego.cordatus, haevalencia, libregeek, marco.sting, michel, ngompa13, package-review, petersen, rc040203, rdieter, zbyszek | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2020-02-19 17:47:07 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Michel Lind
2014-12-05 03:46:42 UTC
I second that. Budgie is a clean and good looking DE, a good alternative for those who don't like Gnome or have a computer with less horse power. (In reply to lnxslck from comment #1) > I second that. Budgie is a clean and good looking DE, a good alternative for > those who don't like Gnome or have a computer with less horse power. Who prefer not to run Gnome Shell, that is. Budgie actually integrates really quite well with the Gnome stack, and indeed the umbrella Evolve OS is a "Friend of Gnome" (see its homepage). Would appreciate if you could review this (if you can't for some reason, that's fine too, of course) Some remarks: - The "# Adjust for Fedora's multilib directory layout" section from %build is a hack playing with the symtops of an upstream bug (They miss to propagate some configuration parameters to "*.pc"). I'd propose this patch instead: <snip> --- budgie-plugin/budgie-1.0.pc.in +++ budgie-plugin/budgie-1.0.pc.in @@ -1,8 +1,8 @@ -prefix=/usr -exec_prefix=${prefix} -libdir=${exec_prefix}/lib -includedir=${prefix}/include -datarootdir=${prefix}/share +prefix=@prefix@ +exec_prefix=@prefix@ +libdir=@libdir@ +includedir=@includedir@ +datarootdir=@datarootdir@ Name: Budgie Description: Budgie Library </snip> - Building is non-verbose. You should append --disable-silent-rules to %configure. (In reply to Ralf Corsepius from comment #3) > Some remarks: > > - The "# Adjust for Fedora's multilib directory layout" > section from %build is a hack playing with the symtops of an upstream bug > (They miss to propagate some configuration parameters to "*.pc"). > > I'd propose this patch instead: > <snip> Right. Was thinking of patching the .pc.in file directly but wasn't sure if that layout (with pkgconfig hard-coded to /usr/lib but the libraries themselves elsewhere) might make sense in some other distribution. But we should at least try and upstream it, so I'll submit a pull request with the patch and, meanwhile, use it instead of dynamically using sed > > - Building is non-verbose. > You should append --disable-silent-rules to %configure. Fixing it in -2, thanks. (In reply to Ralf Corsepius from comment #3) > Some remarks: > <snip> > +prefix=@prefix@ > +exec_prefix=@prefix@ > +libdir=@libdir@ > +includedir=@includedir@ > +datarootdir=@datarootdir@ > On that note, what's the difference between ${prefix} and %prefix% ? Thanks. (In reply to Michel Alexandre Salim from comment #5) > On that note, what's the difference between ${prefix} and %prefix% ? Thanks. Let me try to elaborate. When building, the *.spec receives values/settings from rpm. Inside of the spec, these rpm-provided values are referenced as %{XXXX} and used to propagate them into a package's build process. Here, to "configure", as options being passed to configure. configure interprets/processes these parameters and generates source-files from "*.in" files, substituting all "@name@" patterns with the corresponding values. In this case, this means The spec's %configure expands to ./configure .. --libdir=%{_libdir} ... expands to ./configure .. --libdir=/usr/lib64 ... ./configure interprets the values being passed as argument to --libdir=... and substitutes the sed pattern @libdir@ in all *.ins with the value it received through --libdir=... In this case, configure creates a file budgie-plugin/budgie-1.0.pc using budgie-plugin/budgie-1.0.pc.in as input files, substituing @libdir@ with /usr/lib64 desktop-file-install should be used. See http://fedoraproject.org/wiki/Packaging:Guidelines#desktop-file-install_usage. .appdata.xml file should be added. See http://people.freedesktop.org/~hughsient/appdata/ for some introduction. Screenshots on https://evolve-os.com/budgie/ are probably OK, so this should only be a matter of writing the description. > %description devel > Development files for the Budgie Desktop I'd like to see a more verbose explanation here. bugie-desktop-devel is needed to develop plugins? Please clarify that. Package should own /usr/share/gir-1.0, /usr/share/vala/vapi, /usr/share/vala. budgie bundles https://git.gnome.org/browse/libgnome-volume-control. If I read things correctly, it does not use the system version. It probably should. (In reply to Ralf Corsepius from comment #6) > (In reply to Michel Alexandre Salim from comment #5) > > > On that note, what's the difference between ${prefix} and %prefix% ? Thanks. > > Let me try to elaborate. > > When building, the *.spec receives values/settings from rpm. > Inside of the spec, these rpm-provided values are referenced as %{XXXX} and > used to propagate them into a package's build process. > Here, to "configure", as options being passed to configure. configure > interprets/processes these parameters and generates source-files from "*.in" > files, substituting all "@name@" patterns with the corresponding values. > <snip> Ah, whereas the $-prefixed variables are only local to the *.pc itself, and configure doesn't touch them at all! Thanks. I somehow missed the line that hard-coded prefix to /usr and assumed they're two forms of expansions. Updated spec and SRPM: https://salimma.fedorapeople.org/specs/desktop/budgie-desktop.spec https://salimma.fedorapeople.org/specs/desktop/budgie-desktop-8-2.fc21.src.rpm (In reply to Zbigniew Jędrzejewski-Szmek from comment #7) > desktop-file-install should be used. See > http://fedoraproject.org/wiki/Packaging:Guidelines#desktop-file- > install_usage. > Done > Package should own /usr/share/gir-1.0, /usr/share/vala/vapi, /usr/share/vala. > Done Let me work on the AppData file, and check on the other two items with upstream. > .appdata.xml file should be added. See <snip> > > > %description devel > > Development files for the Budgie Desktop > I'd like to see a more verbose explanation here. bugie-desktop-devel is > needed to develop plugins? Please clarify that. > > budgie bundles https://git.gnome.org/browse/libgnome-volume-control. If I > read things correctly, it does not use the system version. It probably > should. (In reply to Zbigniew Jędrzejewski-Szmek from comment #7) > budgie bundles https://git.gnome.org/browse/libgnome-volume-control. If I > read things correctly, it does not use the system version. It probably > should. There's no system version -- gnome-control-center, gnome-settings-daemon and gnome-shell all bundle libgnome-volume-control using git submodules: https://mail.gnome.org/archives/commits-list/2012-November/msg06793.html https://bugzilla.gnome.org/show_bug.cgi?id=686488 (just checked and indeed there is no standalone libgnome-volume-control lib). I could check with the desktop and packaging lists on this one just to make sure. Ah, OK, that's why I couldn't find it. According to [1] the submodule does not have a stable api and is supposed to be "linked" wherever it is needed. So including it in budgie-desktop is allowed by the packaging guidelines, as a "copy library". [1] https://mail.gnome.org/archives/gnomecc-list/2012-October/msg00003.html Neverthless, all four projects use the same git version of the submodule. It seems a bit unfortunate to have it compiled separately four times. It would be great to de-duplicate those copies at some point, but it's nothing to hold up the review over. My last comment is wrong. Even if it is a copy library, FESCo is supposed to give its stamp of approval. Please file a ticket for a bundling exception at https://fedorahosted.org/fesco/newticket. See here http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Exceptions For details about bundled library policy, and how to ask for exceptions, in particular. (hint: comment #12 is incorrect) that said, the exception here should be trivial (this code aparrently is intended to be bundled as is used in those other referenced gnome components) Ah, FPC not FESCo. Sorry, there's a link to FESCo in the next paragraph which I copied by mistake. I just opened a request to determine whether libgnome-volume-control is an appropriate copylib with FPC: https://fedorahosted.org/fpc/ticket/476 Meanwhile, let's continue the review on the assumption that an exemption will be granted (the other packages that uses g-v-c will have to properly declare that they bundle g-v-c -- currently not being done). I'll release a -3 update with the appdata file and a bundled(gnome-volume-control) virtual provide. One question though -- what version should this virtual provide use? (In reply to Michel Alexandre Salim from comment #15) > Meanwhile, let's continue the review on the assumption that an exemption > will be granted (the other packages that uses g-v-c will have to properly > declare that they bundle g-v-c -- currently not being done). OK. > I'll release a -3 update with the appdata file and a > bundled(gnome-volume-control) virtual provide. One question though -- what > version should this virtual provide use? Date is used in the examples I checked. bundled(gnome-volume-control) = 20130904 https://fedorahosted.org/fpc/ticket/476#comment:6 The copylib exception is rejected, we'd have to turn libgnome-volume-control into a shared lib. I'll follow up on the ticket and dev + packaging lists asking who should undertake that and whether the review should wait till then. So, I think the FPC decision is suboptimal, but let's try to get this done. Can you check if you can build budgie with http://koji.fedoraproject.org/koji/taskinfo?taskID=8746278? If yes, I'll submit a review request. Ping? Build for new rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=8999916. Will try and find the time to do this in the next couple of days - I don't have access to Fedora at work. It would be really nice if we could include Budgie in Fedora 23. It's really a good desktop with sleek UI and high performance. I'm looking forward to seeing this in F23 myself, too. In light of the recent FESCo decision, the bundling would be allowed. Would be nice to make another attempt at this. pbrobinson's scratch build of gnome-dvb-daemon?#451a118009234eac9e3f06f465b00cf93478a5d5 for git://pkgs.fedoraproject.org/gnome-dvb-daemon?#451a118009234eac9e3f06f465b00cf93478a5d5 and rawhide failed http://koji.fedoraproject.org/koji/taskinfo?taskID=11560895 Just wondering what the current state of play is with this? Created attachment 1121945 [details]
Updated SPEC for budgie desktop 10.2.2
This is my attempt to update the original spec to budgie desktop 10.2.2.
I had some issues with the validation of the desktop files so had to disable it. The reason it was failing was for the "xsession" desktop file there is an entry "DesktopNames" for ligthDM, which is not in the XDG specification, looking briefly into it they seemed to be saying that this file is not a "real" desktop file so this entry shouldn't be added to the specification. Also the other desktop files failed as they had a 'OnlyShowIn=Budgie' which the validator does not recognise.
Created attachment 1121946 [details]
Updated patch for budgie desktop 10.2.2
Here is the updated patch to go along with the spec file.
I haven't tried to remove "libgnome-volume-control" from my updated spec file as I'm not sure how to go about it, but perhaps with some guidance we can get it packaged up in an acceptable form. Re: .desktop validation in comment #26 ... You really only need to validate stuff under /usr/share/applications (ie, stuff intended to be displayed in application menus) Oh, and for OnlyShowIn=... I'd recommend patching things to use/recognize X-Budgie instead for now, at least until Budgie is registered formally. Michel, what are your plans with this? My initial plan was to get this running in a reasonable packaged form on my Chromebook. But it would be nice to get it packaged up in a state that it could be included for the community. Fantastic, Budgie Desktop has improved a lot lately and it would be fantastic availability in fedora or as an additional spin. However, it has some flaws in usability as the inconsistency of some of its components (for being in development), such as the Network applet or absence of a switch graphic applications (Alt + Tab). Is there a way to actually prove it? I mean it can be downloaded here: https://software.opensuse.org/download.html?project=home%3Aikeydoherty%3Asolus-project&package=budgie-desktop but it requires manual installation of some components of GNOME, which is not very friendly. I hope you can have this desktop fedora 26 or 27, but the volunteer time is valuable. Thank you. Will we get it on Fedora 26? No longer working on this, freeing it up so someone else can get this reviewed |