Latest upstream release: 1.6.1 Current version/release in rawhide: 1.6.0-7.fc35 URL: http://lumina-desktop.org Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/11808/
As the upstream Developer, I can confirm that there are additional dependencies required for this version. There is a new runtime dependency on the la-capitaine-icon-theme which is already packaged and available in the Fedora Repos. Also in my local compiles on my Fedora 34 machine it also seems that pam-devel is a new build dependency.
(In reply to jt from comment #1) > As the upstream Developer, I can confirm that there are additional > dependencies required for this version. There is a new runtime dependency > on the la-capitaine-icon-theme which is already packaged and available in > the Fedora Repos. So - this package *required* or suggested/recommended?
To answer this as clearly as I can. Lumina 'should' default to the fallback material design set if the La-Capitaine-icon-theme is not installed. However I have gotten reports from a few different distros and BSD releases, this does not always seem to be the case. On my FreeBSD, Slackware and Fedora systems this has seemed to work properly from my testing. However since I'm getting reports that it isn't always working, I'm not entirely willing to claim its 'suggested' at this point. Until I figure out if its a distro/OS bug or a Lumina bug, it's probably safer to claim its a required. I'd rather default to installing an extra package than for a user to run into buttons with no iconography. Whenever I figure out the issue and having the La-Captaine-icon-theme wont break usability, then I'm happy if it gets marked as 'suggested'.
(In reply to jt from comment #1) > Also in my local compiles on my Fedora 34 machine it also seems that pam-devel is a new build dependency. Yes, pam-devel moved building process further. But not enough: https://koji.fedoraproject.org/koji/taskinfo?taskID=76651429
Well that's interesting. The compile seemed to finish without issue and without any issues. It's failing at line 11677 when its attempting to `make install lumina-checkpass` which doesn't have any errors during compile which is at line 177-179. The compile and make install for this works perfectly find on my Fedora 34 system: https://github.com/lumina-desktop/lumina/blob/fedora-build/makeinstall.log#L1773 Let me see if I can pull someone else into this who is more familiar with the Koji build process for Fedora. I'm not sure why the compile would be successful but the file wouldn't be available for the make install. Extra information from my local Fedora Build: My system uname: https://github.com/lumina-desktop/lumina/blob/fedora-build/F34-uname.txt My build deps: https://github.com/lumina-desktop/lumina/blob/fedora-build/fedora-lumina-build-deps.txt My qmake invocation (taken directly from the previous 1.6.0 Koji build logs for F34) : https://github.com/lumina-desktop/lumina/blob/fedora-build/lbuild.sh My build log https://github.com/lumina-desktop/lumina/blob/fedora-build/make.log
(In reply to jt from comment #5) > The compile and make install for this works perfectly Don't mix 'make install' and '%make_install' (rpmbuild installs everything into fake root). Bug reported: https://github.com/lumina-desktop/lumina/issues/771 PS. I don't know what to do with (https://kojipkgs.fedoraproject.org//work/tasks/6499/76656499/build.log): 1. lumina-checkpass 2. lumina-pingcursor Who they are? What they do? What subpackage? 3. /usr/share/icons/lumina-icons/*/*.svg - very strange path and cannot find what these icons for
It seems that Koji is not happy that these extra things exist, but are not packaged. My assumption based on my very limited knowledge of Fedora Spec files is that it would need %package lines added for each of these, but I may be entirely wrong on that. To answer your other questions: 1. This function provides the basic current-user password validation. As stated in the source: https://github.com/lumina-desktop/lumina/blob/master/src-qt5/core/lumina-checkpass/main.c#L7 2. This function provides a simple visual ping for 8k and higher desktops to find the cursor. That comment has been added into the source file. 3. /usr/share/icons/lumina-icons are the menu system control icons (logout, restart, shutdown, etc) Not sure why you're getting that path though, the icons after being installed are /usr/share/icons/lumina-icons/actions/symbolic/*.svg as shown by L12111-12146 in that koji build log.
(In reply to jt from comment #7) > It seems that Koji is not happy that these extra things exist, but are not > packaged. Koji (and rpmbuild at all) cannot be happy or not happy. The rule is: "Everything installed must be packaged. No exception". > My assumption based on my very limited knowledge of Fedora Spec > files is that it would need %package lines added for each of these, but I > may be entirely wrong on that. Solution is: - if the binary *required* for subpackage - I include it to this package - if it is *required* for other subpackages - I make subpackage like lumina-common that is *required* for other subpackage. - if it is not *required* (and other applications can work without it) then: -- if it is CLI - I can package those binaries in extra subpackage like lumina-utils; but they _must_ have proper man pages -- if they are GUI - I will package them into separate subpackages but they must have proper *.desktop files and own icons
(In reply to jt from comment #7) > 3. /usr/share/icons/lumina-icons are the menu system control icons (logout, > restart, shutdown, etc) Not sure why you're getting that path though, the > icons after being installed are > /usr/share/icons/lumina-icons/actions/symbolic/*.svg as shown by > L12111-12146 in that koji build log. May be already existent paths /usr/share/icons/hicolor/scalable/actions or /usr/share/icons/hicolor/symbolic/apps will be better?
(In reply to jt from comment #7) > 3. /usr/share/icons/lumina-icons are the menu system control icons (logout, > restart, shutdown, etc) Who use it? 'Lumina' binary only? Then I'll package it in that package. Or other lumina-* applications too? Then it must be common shared package. Because lumina-* apps can be run without lumina main package installed.
> 'Lumina' binary only? Then I'll package it in that package. > Or other lumina-* applications too? Then it must be common shared package. Because lumina-* apps can be run without lumina main package installed. If in doubt, I'd go with filesystem or better data packages as both are noarch.
(In reply to Eugene A. Pivnev from comment #9) … > May be already existent paths /usr/share/icons/hicolor/scalable/actions or > /usr/share/icons/hicolor/symbolic/apps will be better? Not a good idea IMHO. We'd have to Require: hicolor-icon-theme as owner for those folders.
(In reply to Raphael Groner from comment #12) > (In reply to Eugene A. Pivnev from comment #9) > … > > May be already existent paths /usr/share/icons/hicolor/scalable/actions or > > /usr/share/icons/hicolor/symbolic/apps will be better? > > Not a good idea IMHO. We'd have to Require: hicolor-icon-theme as owner for > those folders. Most of GUI packages that I maintain use "Requires: hicolor-icon-theme", no problem. If application use multisize pixmaps (like 32x32/... etc) it have to use hicolor-icon-theme.
> Most of GUI packages that I maintain use "Requires: hicolor-icon-theme", no problem. Indeed, it tends to become quite usual in several packages. > If application use multisize pixmaps (like 32x32/... etc) it have to use hicolor-icon-theme. Because general policy.
OK, finally got time to check back on this ticket, let me read through it and respond. > Solution is: > - if the binary *required* for subpackage - I include it to this package > - if it is *required* for other subpackages - I make subpackage like lumina-common that is *required* for other subpackage. > - if it is not *required* (and other applications can work without it) then: > -- if it is CLI - I can package those binaries in extra subpackage like lumina-utils; but they _must_ have proper man pages > -- if they are GUI - I will package them into separate subpackages but they must have proper *.desktop files and own icons lumina-checkpass should only be used by the desktop as its used by screen lockers and such. lumina-pingcursor should only be launched by the desktop. Other Lumina utilities will not use either of them. > May be already existent paths /usr/share/icons/hicolor/scalable/actions or /usr/share/icons/hicolor/symbolic/apps will be better? > Who use it? > 'Lumina' binary only? Then I'll package it in that package. > Or other lumina-* applications too? Then it must be common shared package. Because lumina-* apps can be run without lumina main package installed. The plan is to slowly add more and more icons for Lumina itself as I get time to make them so that the material design icons are no longer needed. That's why a new icon pack has been created. It has its own project file, so if you want to make that its own package, that's fine with me. Currently they are only used by the desktop session, but that will change as more and more icons are added in. So it might make more sense to make it an icon package, but its your choice how you want to package it for Fedora. > If in doubt, I'd go with filesystem or better data packages as both are noarch. This also works. Fedora can package it however they want according to the Fedora standards. >> Most of GUI packages that I maintain use "Requires: hicolor-icon-theme", no problem. > Indeed, it tends to become quite usual in several packages. >> If application use multisize pixmaps (like 32x32/... etc) it have to use hicolor-icon-theme. > Because general policy. I'll mention this here since it's related to a ticket on Github about the pixmaps. Currently there are two PNGs which Fedora has a patch file to change the directory location, I will be turning these into SVGs which will resolve the need for this patch. Along with a few other minor updates to different things, I will try to get the SVG creation done as well and put into v1.6.2 that will hopefully come out at the end of the month.
The last question about icons - lumina-desktop requires *exactly* these icons - or wants icons with these names? I mean that icons can be packaged into: 1. lumina-desktop main package (near lumina-desktop binary) 2. lumina-icons that *required* by lumina-desktop 3. lumina-icons that recommended/suggested by lumina-desktop
Please no. Not another subpackage. Use data (or filesystem) as it builds with noarch, as I suggested in comment #11.
> lumina-desktop requires *exactly* these icons - No > wants icons with these names? Yes
(In reply to Raphael Groner from comment #17) Ok, lets play with it: https://koji.fedoraproject.org/koji/taskinfo?taskID=76757813 Spec diff sent directly.
FEDORA-2021-be4568edbd has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-be4568edbd
FEDORA-2021-be4568edbd has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-be4568edbd` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-be4568edbd See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-be4568edbd has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.