| View previous topic :: View next topic |
| Author |
Message |
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 10020
Location: almost Mile High in the USA
|
 Posted: Wed Apr 16, 2025 10:10 am Post subject: ebuild minversion problems found... |
 |
|
This recent update cycle seems to be having a lot of versions of libraries updated too late? and software linking against the old versions failing. This is a note to myself so far...
shotwell-0.32.10 requires >=libportal-0.7
file-roller-44.4 requires >=gtk-4.12 (bug fixed on 13/apr)
libpanel-1.6.0 seems to require >=libadwaita-1.5
gnome-chess-46.0 requires >=libadwaita-1.5 (fixed on 16apr)
gnome-bluetooth-46.2 requires >=libadwaita-1.4
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?
Last edited by eccerr0r on Wed Apr 16, 2025 8:00 pm; edited 3 times in total |
|
| Back to top |
|
 |
sam_
Developer
Joined: 14 Aug 2020
Posts: 2353
|
| Posted: Wed Apr 16, 2025 11:11 am Post subject: |
|
|
You should really file bugs immediately for these with the full log. Having notes for them afterwards is way more work to verify. And of course, no bug at all is even worse.
EDIT: For example, I just spent a few minutes looking at libpanel, and it's not obvious at all where or when that changed. There was an upstream commit a while after that release which cranked the requirement in meson.build but it wasn't along with the code changes which presumably came earlier. The error would help a lot with that. This is the kind of thing I'm very happy to fix if you make it easy! |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 10020
Location: almost Mile High in the USA
|
| Posted: Wed Apr 16, 2025 4:14 pm Post subject: |
|
|
The problem is that most of the times the particular issue I'm running into is that my machine has a lot of old packages. The old packages satisfy the DEPEND written in the ebuild for the new packages scheduled for merge, but the package version no longer is in the portage tree and the software was written to take advantage of new library functions.
The debate I was wondering is if portage should notice a package version no longer exists in the tree and consider an update before building a package that depends on it? I don't like this either but if there's no effort to check against package versions that no longer exist anymore...
Btw I estimate average time for how old the packages are is 2.4 years on this computer, as that was the last time it was emerge --update @world ...
Incidentally I didn't fully debug libpanel but it appears to have adwaita issues:
| libpanel build log wrote: | | Code: | ../libpanel-1.6.0/src/panel-dock-child.c: In function ‘panel_dock_child_get_empty’:
../libpanel-1.6.0/src/panel-dock-child.c:562:7: error: implicit declaration of function ‘ADW_IS_TOOLBAR_VIEW’; did you mean ‘ADW_IS_TAB_VIEW’? [-Werror=implicit-function-declaration]
562 | if (ADW_IS_TOOLBAR_VIEW (child))
| ^~~~~~~~~~~~~~~~~~~
| ADW_IS_TAB_VIEW
../libpanel-1.6.0/src/panel-dock-child.c:562:7: warning: nested extern declaration of ‘ADW_IS_TOOLBAR_VIEW’ [-Wnested-externs]
../libpanel-1.6.0/src/panel-dock-child.c:563:13: error: implicit declaration of function ‘adw_toolbar_view_get_content’; did you mean ‘adw_flap_get_content’? [-Werror=implicit-function-declaration]
563 | child = adw_toolbar_view_get_content (ADW_TOOLBAR_VIEW (child));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
| adw_flap_get_content
../libpanel-1.6.0/src/panel-dock-child.c:563:13: warning: nested extern declaration of ‘adw_toolbar_view_get_content’ [-Wnested-externs]
../libpanel-1.6.0/src/panel-dock-child.c:563:43: error: implicit declaration of function ‘ADW_TOOLBAR_VIEW’; did you mean ‘ADW_TAB_VIEW’? [-Werror=implicit-function-declaration]
563 | child = adw_toolbar_view_get_content (ADW_TOOLBAR_VIEW (child));
| ^~~~~~~~~~~~~~~~
| ADW_TAB_VIEW
../libpanel-1.6.0/src/panel-dock-child.c:563:43: warning: nested extern declaration of ‘ADW_TOOLBAR_VIEW’ [-Wnested-externs]
../libpanel-1.6.0/src/panel-dock-child.c:563:11: error: assignment to ‘GtkWidget *’ {aka ‘struct _GtkWidget *’} from ‘int’ makes pointer from integer without a cast [-Werror=int-conversion]
563 | child = adw_toolbar_view_get_content (ADW_TOOLBAR_VIEW (child));
| ^
cc1: some warnings being treated as errors../libpanel-1.6.0/src/panel-dock-child.c: In function ‘panel_dock_child_get_empty’:
../libpanel-1.6.0/src/panel-dock-child.c:562:7: error: implicit declaration of function ‘ADW_IS_TOOLBAR_VIEW’; did you mean ‘ADW_IS_TAB_VIEW’? [-Werror=implicit-function-declaration]
562 | if (ADW_IS_TOOLBAR_VIEW (child))
| ^~~~~~~~~~~~~~~~~~~
| ADW_IS_TAB_VIEW
../libpanel-1.6.0/src/panel-dock-child.c:562:7: warning: nested extern declaration of ‘ADW_IS_TOOLBAR_VIEW’ [-Wnested-externs]
../libpanel-1.6.0/src/panel-dock-child.c:563:13: error: implicit declaration of function ‘adw_toolbar_view_get_content’; did you mean ‘adw_flap_get_content’? [-Werror=implicit-function-declaration]
563 | child = adw_toolbar_view_get_content (ADW_TOOLBAR_VIEW (child));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
| adw_flap_get_content
../libpanel-1.6.0/src/panel-dock-child.c:563:13: warning: nested extern declaration of ‘adw_toolbar_view_get_content’ [-Wnested-externs]
../libpanel-1.6.0/src/panel-dock-child.c:563:43: error: implicit declaration of function ‘ADW_TOOLBAR_VIEW’; did you mean ‘ADW_TAB_VIEW’? [-Werror=implicit-function-declaration]
563 | child = adw_toolbar_view_get_content (ADW_TOOLBAR_VIEW (child));
| ^~~~~~~~~~~~~~~~
| ADW_TAB_VIEW
../libpanel-1.6.0/src/panel-dock-child.c:563:43: warning: nested extern declaration of ‘ADW_TOOLBAR_VIEW’ [-Wnested-externs]
../libpanel-1.6.0/src/panel-dock-child.c:563:11: error: assignment to ‘GtkWidget *’ {aka ‘struct _GtkWidget *’} from ‘int’ makes pointer from integer without a cast [-Werror=int-conversion]
563 | child = adw_toolbar_view_get_content (ADW_TOOLBAR_VIEW (child));
| ^
cc1: some warnings being treated as errors
|
|
And shotwell which I did investigate which pinpointed to requiring libportal-0.7:
| shotwell build log wrote: | | Code: | ../shotwell-0.32.10/src/util/string.vala:206.18-206.43: warning: `GLib.UnicodeType.COMBINING_MARK' has been deprecated since 2.30. Use SPACING_MARK
206 | case UnicodeType.COMBINING_MARK:
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
../shotwell-0.32.10/src/DesktopIntegration.vala:109.26-109.48: error: The name `initable_new' does not exist in the context of `Xdp.Portal' (libportal)
109 | var portal = new Xdp.Portal.initable_new();
| ^~~~~~~~~~~~~~~~~~~~~~~
libportal.vapi:12.2-12.34: note: `Portal' was declared here
12 | public class Portal : GLib.Object {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../shotwell-0.32.10/src/DesktopIntegration.vala:183.26-183.48: error: The name `initable_new' does not exist in the context of `Xdp.Portal' (libportal)
183 | var portal = new Xdp.Portal.initable_new();
| ^~~~~~~~~~~~~~~~~~~~~~~
libportal.vapi:12.2-12.34: note: `Portal' was declared here
12 | public class Portal : GLib.Object {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../shotwell-0.32.10/src/DesktopIntegration.vala:325.26-325.48: error: The name `initable_new' does not exist in the context of `Xdp.Portal' (libportal)
325 | var portal = new Xdp.Portal.initable_new();
| ^~~~~~~~~~~~~~~~~~~~~~~
libportal.vapi:12.2-12.34: note: `Portal' was declared here
12 | public class Portal : GLib.Object {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../shotwell-0.32.10/src/plugins/Plugins.vala:307.19-307.31: warning: `GLib.Module.SUFFIX' has been deprecated since 2.76
307 | return ext == Module.SUFFIX;
| ^~~~~~~~~~~~~
Compilation failed: 3 error(s), 2 warning(s)
|
|
BTW I'm sort of on a time battle and want to get this updated ASAP (this is my PVR box and don't want to miss recording shows! LOL! That's why I really don't want to update this often as a risk of breakage happens every update...) so I've been hacking an overlay to change the version requirements instead of syncing and having to re-fix any new portage version collisions that may occur, so yeah sorry some of these build logs will get overwritten as they get fixed. I'm assuming that the devs were able to successfully compile and adding the versions should fix the issues as building against antiquated versions of the libraries is probably not what's happening.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 10020
Location: almost Mile High in the USA
|
| Posted: Wed Apr 16, 2025 6:27 pm Post subject: |
|
|
net-wireless/gnome-bluetooth-46.2 failed
| gnome-bluetooth-46.2 build log wrote: | | Code: |
Found pkg-config: YES (/usr/bin/x86_64-pc-linux-gnu-pkg-config) 2.3.0
Run-time dependency gio-2.0 found: YES 2.82.5
Run-time dependency gio-unix-2.0 found: YES 2.82.5
Run-time dependency gtk4 found: YES 4.16.12
Run-time dependency gsound found: YES 1.0.3
Dependency libadwaita-1 found: NO. Found 1.2.0 but need: '>= 1.4'
Found CMake: /usr/bin/cmake (3.31.5)
Run-time dependency libadwaita-1 found: NO (tried pkgconfig and cmake)
Looking for a fallback subproject for the dependency libadwaita-1
meson.build:102:17: ERROR: Automatic wrap-based subproject downloading is disabled
|
|
more adwaita fallout
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 2353
|
| Posted: Wed Apr 16, 2025 10:54 pm Post subject: |
|
|
| eccerr0r wrote: | The problem is that most of the times the particular issue I'm running into is that my machine has a lot of old packages. The old packages satisfy the DEPEND written in the ebuild for the new packages scheduled for merge, but the package version no longer is in the portage tree and the software was written to take advantage of new library functions.
|
Yes, I understand. ebuilds should specify the minimum version correctly. In each of the cases mentioned so far, it looks like the upstream build system was incorrect rather than the ebuild (the ebuild reflected what the build system said). Of course, we can still add the right minimum version once we have a log and some analysis from somebody (not necessarily the reporter) on which version would satisfy that, but someone (again, possibly the reporter, but the maintainer if not) should send a patch upstream with such analysis to fix the build system too.
But the right minimum version is not "whatever the latest version is", and if we did do that, it'd both feel wrong and also surely upset somebody.
| eccerr0r wrote: |
The debate I was wondering is if portage should notice a package version no longer exists in the tree and consider an update before building a package that depends on it? I don't like this either but if there's no effort to check against package versions that no longer exist anymore...
|
We could perhaps do that, but it'd probably need to be optional, as I'm sure "eccerr0r_2" would appear and say it's forcing him to upgrade when he's not ready 
(bug 913197 may also be of interest.)
| eccerr0r wrote: |
BTW I'm sort of on a time battle and want to get this updated ASAP (this is my PVR box and don't want to miss recording shows! LOL! That's why I really don't want to update this often as a risk of breakage happens every update...) so I've been hacking an overlay to change the version requirements instead of syncing and having to re-fix any new portage version collisions that may occur, so yeah sorry some of these build logs will get overwritten as they get fixed. I'm assuming that the devs were able to successfully compile and adding the versions should fix the issues as building against antiquated versions of the libraries is probably not what's happening. |
Yes, the problem is far worse because you wait ages between updates. You'd have little to no issues without that. The question is which versions to be added to the ebuilds and to justify the change correctly. |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 10020
Location: almost Mile High in the USA
|
| Posted: Wed Apr 16, 2025 11:18 pm Post subject: |
|
|
I had to choose an off-season time where it's less likely to be a show I wanted to record ;) Since the box is not used for internet stuff (other than possible mythtv security upgrades as it appears to contact the web for some stuff), there wasn't a strong need to upgrade other than it being part of my distcc farm and having obsolete versions of clang and gcc don't help.
In any case there are masks to prevent portage from upgrading, so that should be used if not ready to upgrade. However in this case today, libadwaita, gtk, and libportal were actually in the merge queue, just the dependencies were updated AFTER the requesting packages merged and I can't think of a way other than modifying the ebuilds to get the ordering correct.
On another note I also have another complaint about dev-perl/Locale-gettext that I frequently have to manually merge in order for portage to finish building packages when they say that gettext isn't installed for whatever reason. Not sure if it's a similar issue or not however, as I didn't look at the ordering carefully.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?
Last edited by eccerr0r on Wed Apr 16, 2025 11:32 pm; edited 1 time in total |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 2353
|
| Posted: Wed Apr 16, 2025 11:28 pm Post subject: |
|
|
| Modifying the ebuilds is correct. The question is what modification should be made and with what justification. |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 10020
Location: almost Mile High in the USA
|
| Posted: Thu Apr 17, 2025 3:17 am Post subject: |
|
|
Not sure how to go from here then. The world update merge completed so fairly high confidence the old installed version and new version ordering was indeed the reason why it didn't complete the first time around.
Other than that silly X11 -wayland problem with mutter, so far so good. Need to reboot it later tonight or tomorrow and see if everything is hunky dory...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 2353
|
| Posted: Thu Apr 17, 2025 3:19 am Post subject: |
|
|
| Again, not disputing that at all (which is why I said in the earlier post that such a feature request would likely need to be made optional if implemented. |
|
| Back to top |
|
|
|
Portage & Programming
