From phrdina at redhat.com Wed Nov 1 13:35:16 2017 From: phrdina at redhat.com (Pavel Hrdina) Date: Wed, 1 Nov 2017 14:35:16 +0100 Subject: [Libosinfo] [libosinfo PATCH] tests: get the curl response code every time Message-ID: This failed on FreeBSD with following error: ../../tests/test-mediauris.c:47:13: error: variable 'response_code' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] Signed-off-by: Pavel Hrdina --- tests/test-mediauris.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/tests/test-mediauris.c b/tests/test-mediauris.c index 5ac2c8e..a079f46 100644 --- a/tests/test-mediauris.c +++ b/tests/test-mediauris.c @@ -44,9 +44,7 @@ static void test_media(OsinfoMediaList *medialist, GError **error, CURL *curl) g_test_message("%s", url); curl_easy_setopt(curl, CURLOPT_URL, url); res = curl_easy_perform(curl); - if (res != CURLE_OK) { - curl_easy_getinfo(curl, CURLINFO_RESPONSE_CODE, &response_code); - } + curl_easy_getinfo(curl, CURLINFO_RESPONSE_CODE, &response_code); g_test_message("res=%d, %s; code=%ld", res, curl_easy_strerror(res), response_code); g_assert_cmpint(res, ==, CURLE_OK); -- 2.13.6 From berrange at redhat.com Wed Nov 1 13:37:52 2017 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 1 Nov 2017 13:37:52 +0000 Subject: [Libosinfo] [libosinfo PATCH] tests: get the curl response code every time In-Reply-To: References: Message-ID: <20171101133752.GF9289@redhat.com> On Wed, Nov 01, 2017 at 02:35:16PM +0100, Pavel Hrdina wrote: > This failed on FreeBSD with following error: > > ../../tests/test-mediauris.c:47:13: error: variable 'response_code' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] > > Signed-off-by: Pavel Hrdina > --- > tests/test-mediauris.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) Reviewed-by: Daniel P. Berrange Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| From berrange at redhat.com Wed Nov 1 14:22:53 2017 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 1 Nov 2017 14:22:53 +0000 Subject: [Libosinfo] [libosinfo PATCH] tests: get the curl response code every time In-Reply-To: <20171101133752.GF9289@redhat.com> References: <20171101133752.GF9289@redhat.com> Message-ID: <20171101142253.GI9289@redhat.com> On Wed, Nov 01, 2017 at 01:37:52PM +0000, Daniel P. Berrange wrote: > On Wed, Nov 01, 2017 at 02:35:16PM +0100, Pavel Hrdina wrote: > > This failed on FreeBSD with following error: > > > > ../../tests/test-mediauris.c:47:13: error: variable 'response_code' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] > > > > Signed-off-by: Pavel Hrdina > > --- > > tests/test-mediauris.c | 4 +--- > > 1 file changed, 1 insertion(+), 3 deletions(-) > > Reviewed-by: Daniel P. Berrange Turns out test-treeuris.c has the same bug, so I've pushed a followup doing the exact same fix there too Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| From phrdina at redhat.com Wed Nov 1 14:25:21 2017 From: phrdina at redhat.com (Pavel Hrdina) Date: Wed, 1 Nov 2017 15:25:21 +0100 Subject: [Libosinfo] [libosinfo PATCH] tests: get the curl response code every time In-Reply-To: <20171101142253.GI9289@redhat.com> References: <20171101133752.GF9289@redhat.com> <20171101142253.GI9289@redhat.com> Message-ID: <20171101142521.GB23793@antique-laptop> On Wed, Nov 01, 2017 at 02:22:53PM +0000, Daniel P. Berrange wrote: > On Wed, Nov 01, 2017 at 01:37:52PM +0000, Daniel P. Berrange wrote: > > On Wed, Nov 01, 2017 at 02:35:16PM +0100, Pavel Hrdina wrote: > > > This failed on FreeBSD with following error: > > > > > > ../../tests/test-mediauris.c:47:13: error: variable 'response_code' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] > > > > > > Signed-off-by: Pavel Hrdina > > > --- > > > tests/test-mediauris.c | 4 +--- > > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > Reviewed-by: Daniel P. Berrange > > Turns out test-treeuris.c has the same bug, so I've pushed a followup doing > the exact same fix there too Should have checked that, thanks :) Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From cfergeau at redhat.com Mon Nov 6 13:38:29 2017 From: cfergeau at redhat.com (Christophe Fergeau) Date: Mon, 6 Nov 2017 14:38:29 +0100 Subject: [Libosinfo] [PATCH] Marginally simplify the code to create and run a GMainLoop In-Reply-To: <20171030142422.GA29344@aloka.lostca.se> References: <20170117142941.5412-1-rishi.is@lostca.se> <20170207170353.pfn5uwgvfz3ybks2@edamame.cdg.redhat.com> <20170208101620.q7e4squumv6jkox4@edamame.cdg.redhat.com> <20171016122059.GR29716@natto.ory.fergeau.eu> <20171030142422.GA29344@aloka.lostca.se> Message-ID: <20171106133829.GH27643@natto.ory.fergeau.eu> On Mon, Oct 30, 2017 at 02:24:22PM +0000, Debarshi Ray wrote: > Hey, > > On Mon, Oct 16, 2017 at 02:20:59PM +0200, Christophe Fergeau wrote: > > Just took another look at it, and we don't have this situation currently > > in libosinfo codebase, so your patch should be fine. > > > > Acked-by: Christophe Fergeau > > My point was that this situation should never arise in any > asynchronous API in the first place. :) Yes, I understand, but since we did not have this situation in mind when writing the code, better to double-check this actually holds true ;) > > By the way, I don't have commit access, so somebody has to push the > patches for me. I'll do that! Christophe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From cfergeau at redhat.com Mon Nov 6 13:38:43 2017 From: cfergeau at redhat.com (Christophe Fergeau) Date: Mon, 6 Nov 2017 14:38:43 +0100 Subject: [Libosinfo] [libosinfo] tests: Add test case for Windows 10 1709 builds Message-ID: <20171106133843.4437-1-cfergeau@redhat.com> These are currently missing from osinfo-db Signed-off-by: Christophe Fergeau https://bugzilla.redhat.com/show_bug.cgi?id=1509387 --- ...709_updated_sept_2017_x64_dvd_100090817.iso.txt | 29 ++++++++++++++++++++++ 1 file changed, 29 insertions(+) create mode 100644 tests/isodata/windows/win10/en_windows_10_multi-edition_version_1709_updated_sept_2017_x64_dvd_100090817.iso.txt diff --git a/tests/isodata/windows/win10/en_windows_10_multi-edition_version_1709_updated_sept_2017_x64_dvd_100090817.iso.txt b/tests/isodata/windows/win10/en_windows_10_multi-edition_version_1709_updated_sept_2017_x64_dvd_100090817.iso.txt new file mode 100644 index 00000000..7c329932 --- /dev/null +++ b/tests/isodata/windows/win10/en_windows_10_multi-edition_version_1709_updated_sept_2017_x64_dvd_100090817.iso.txt @@ -0,0 +1,29 @@ +CD-ROM is in ISO 9660 format +System id: +Volume id: CCCOMA_X64FRE_EN-US_DV9 +Volume set id: CCCOMA_X64FRE_EN-US_DV9 +Publisher id: MICROSOFT CORPORATION +Data preparer id: MICROSOFT CORPORATION, ONE MICROSOFT WAY, REDMOND WA 98052, (425) 882-8080 +Application id: CDIMAGE 2.56 (01/01/2005 TM) +Copyright File id: +Abstract File id: +Bibliographic File id: +Volume set size is: 1 +Volume set sequence number is: 1 +Logical block size is: 2048 +Volume size is: 2293634 +El Torito VD version 1 found, boot catalog is in sector 22 +NO Joliet present +NO Rock Ridge present +Eltorito validation header: + Hid 1 + Arch 0 (x86) + ID 'Microsoft Corporation' + Key 55 AA + Eltorito defaultboot header: + Bootid 88 (bootable) + Boot media 0 (No Emulation Boot) + Load segment 0 + Sys type 0 + Nsect 8 + Bootoff 20C 524 -- 2.13.6 From cfergeau at redhat.com Mon Nov 6 13:38:53 2017 From: cfergeau at redhat.com (Christophe Fergeau) Date: Mon, 6 Nov 2017 14:38:53 +0100 Subject: [Libosinfo] [osinfo-db] win10: Add iso data for 1709 builds Message-ID: <20171106133853.4564-1-cfergeau@redhat.com> These are currently missing from osinfo-db Signed-off-by: Christophe Fergeau https://bugzilla.redhat.com/show_bug.cgi?id=1509387 --- data/os/microsoft.com/win-10.xml.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/data/os/microsoft.com/win-10.xml.in b/data/os/microsoft.com/win-10.xml.in index e443276..b44a38c 100644 --- a/data/os/microsoft.com/win-10.xml.in +++ b/data/os/microsoft.com/win-10.xml.in @@ -87,7 +87,7 @@ - (J_)?CCSN?A_X64FRE_ + (J_)?(CCSN?A|CCOMA)_X64FRE_ MICROSOFT CORPORATION [[:upper:][:digit:]_]*_([[:upper:]]*-[[:upper:]]*) -- 2.13.6 From fabiano at fidencio.org Mon Nov 6 17:38:28 2017 From: fabiano at fidencio.org (=?UTF-8?Q?Fabiano_Fid=C3=AAncio?=) Date: Mon, 6 Nov 2017 18:38:28 +0100 Subject: [Libosinfo] [osinfo-db] win10: Add iso data for 1709 builds In-Reply-To: <20171106133853.4564-1-cfergeau@redhat.com> References: <20171106133853.4564-1-cfergeau@redhat.com> Message-ID: On Mon, Nov 6, 2017 at 2:38 PM, Christophe Fergeau wrote: > These are currently missing from osinfo-db > > Signed-off-by: Christophe Fergeau > > https://bugzilla.redhat.com/show_bug.cgi?id=1509387 > --- > data/os/microsoft.com/win-10.xml.in | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/data/os/microsoft.com/win-10.xml.in b/data/os/microsoft.com/win-10.xml.in > index e443276..b44a38c 100644 > --- a/data/os/microsoft.com/win-10.xml.in > +++ b/data/os/microsoft.com/win-10.xml.in > @@ -87,7 +87,7 @@ > > > > - (J_)?CCSN?A_X64FRE_ > + (J_)?(CCSN?A|CCOMA)_X64FRE_ > MICROSOFT CORPORATION > [[:upper:][:digit:]_]*_([[:upper:]]*-[[:upper:]]*) > > -- > 2.13.6 > > _______________________________________________ > Libosinfo mailing list > Libosinfo at redhat.com > https://www.redhat.com/mailman/listinfo/libosinfo ack both patches! -- Fabiano Fid?ncio From zeeshanak at gnome.org Sun Nov 12 16:04:19 2017 From: zeeshanak at gnome.org (Zeeshan Ali) Date: Sun, 12 Nov 2017 17:04:19 +0100 Subject: [Libosinfo] [PATCH] Drop redundant 'const' keyword from object parameters Message-ID: <20171112160419.32730-1-zeeshan@kinvolk.io> Use of 'const' parameter on object parameters is redundant, inconsistent (both internally and against other GObject libraries) and currently breaks the low-level Rust binding generator: https://github.com/gtk-rs/glib/pull/249 --- osinfo/osinfo_install_config_param.c | 10 +++++----- osinfo/osinfo_install_config_param.h | 10 +++++----- osinfo/osinfo_install_script.c | 10 +++++----- osinfo/osinfo_install_script.h | 10 +++++----- 4 files changed, 20 insertions(+), 20 deletions(-) diff --git a/osinfo/osinfo_install_config_param.c b/osinfo/osinfo_install_config_param.c index f74a802..4adcd07 100644 --- a/osinfo/osinfo_install_config_param.c +++ b/osinfo/osinfo_install_config_param.c @@ -221,7 +221,7 @@ OsinfoInstallConfigParam *osinfo_install_config_param_new(const gchar *name) * * Returns: (transfer none): the name of the configuration parameter */ -const gchar *osinfo_install_config_param_get_name(const OsinfoInstallConfigParam *config_param) +const gchar *osinfo_install_config_param_get_name(OsinfoInstallConfigParam *config_param) { return osinfo_entity_get_param_value(OSINFO_ENTITY(config_param), OSINFO_INSTALL_CONFIG_PARAM_PROP_NAME); @@ -233,7 +233,7 @@ const gchar *osinfo_install_config_param_get_name(const OsinfoInstallConfigParam * * Returns: (transfer none): the policy of the configuration parameter */ -OsinfoInstallConfigParamPolicy osinfo_install_config_param_get_policy(const OsinfoInstallConfigParam *config_param) +OsinfoInstallConfigParamPolicy osinfo_install_config_param_get_policy(OsinfoInstallConfigParam *config_param) { return osinfo_entity_get_param_value_enum(OSINFO_ENTITY(config_param), OSINFO_INSTALL_CONFIG_PARAM_PROP_POLICY, @@ -248,7 +248,7 @@ OsinfoInstallConfigParamPolicy osinfo_install_config_param_get_policy(const Osin * Returns: (transfer none): TRUE if the config_param is required. * FALSE otherwise. */ -gboolean osinfo_install_config_param_is_required(const OsinfoInstallConfigParam *config_param) +gboolean osinfo_install_config_param_is_required(OsinfoInstallConfigParam *config_param) { return (osinfo_install_config_param_get_policy(config_param) == OSINFO_INSTALL_CONFIG_PARAM_POLICY_REQUIRED); @@ -261,13 +261,13 @@ gboolean osinfo_install_config_param_is_required(const OsinfoInstallConfigParam * Returns: (transfer none): TRUE if the config_param is optional. * FALSE otherwise. */ -gboolean osinfo_install_config_param_is_optional(const OsinfoInstallConfigParam *config_param) +gboolean osinfo_install_config_param_is_optional(OsinfoInstallConfigParam *config_param) { return (osinfo_install_config_param_get_policy(config_param) == OSINFO_INSTALL_CONFIG_PARAM_POLICY_OPTIONAL); } -OsinfoDatamap *osinfo_install_config_param_get_value_map(const OsinfoInstallConfigParam *config_param) +OsinfoDatamap *osinfo_install_config_param_get_value_map(OsinfoInstallConfigParam *config_param) { return config_param->priv->value_map; } diff --git a/osinfo/osinfo_install_config_param.h b/osinfo/osinfo_install_config_param.h index 58bb40b..8c083f3 100644 --- a/osinfo/osinfo_install_config_param.h +++ b/osinfo/osinfo_install_config_param.h @@ -81,16 +81,16 @@ GType osinfo_install_config_param_get_type(void); OsinfoInstallConfigParam *osinfo_install_config_param_new(const gchar *name); -const gchar *osinfo_install_config_param_get_name(const OsinfoInstallConfigParam *config_param); +const gchar *osinfo_install_config_param_get_name(OsinfoInstallConfigParam *config_param); -OsinfoInstallConfigParamPolicy osinfo_install_config_param_get_policy(const OsinfoInstallConfigParam *config_param); +OsinfoInstallConfigParamPolicy osinfo_install_config_param_get_policy(OsinfoInstallConfigParam *config_param); -gboolean osinfo_install_config_param_is_required(const OsinfoInstallConfigParam *config_param); +gboolean osinfo_install_config_param_is_required(OsinfoInstallConfigParam *config_param); -gboolean osinfo_install_config_param_is_optional(const OsinfoInstallConfigParam *config_param); +gboolean osinfo_install_config_param_is_optional(OsinfoInstallConfigParam *config_param); void osinfo_install_config_param_set_value_map(OsinfoInstallConfigParam *config_param, OsinfoDatamap *datamap); -OsinfoDatamap *osinfo_install_config_param_get_value_map(const OsinfoInstallConfigParam *config_param); +OsinfoDatamap *osinfo_install_config_param_get_value_map(OsinfoInstallConfigParam *config_param); #endif /* __OSINFO_INSTALL_CONFIG_PARAM_H__ */ diff --git a/osinfo/osinfo_install_script.c b/osinfo/osinfo_install_script.c index 4856eae..52b6d75 100644 --- a/osinfo/osinfo_install_script.c +++ b/osinfo/osinfo_install_script.c @@ -266,7 +266,7 @@ void osinfo_install_script_add_config_param(OsinfoInstallScript *script, OsinfoI OSINFO_ENTITY(param)); } -gboolean osinfo_install_script_has_config_param(const OsinfoInstallScript *script, const OsinfoInstallConfigParam *config_param) +gboolean osinfo_install_script_has_config_param(OsinfoInstallScript *script, OsinfoInstallConfigParam *config_param) { /* NB: this code assumes that the 'id' and 'name' entity properties * are the same @@ -275,7 +275,7 @@ gboolean osinfo_install_script_has_config_param(const OsinfoInstallScript *scrip return osinfo_install_script_has_config_param_name(script, name); } -gboolean osinfo_install_script_has_config_param_name(const OsinfoInstallScript *script, const gchar *name) +gboolean osinfo_install_script_has_config_param_name(OsinfoInstallScript *script, const gchar *name) { OsinfoList *l = OSINFO_LIST(script->priv->config_params); return (osinfo_list_find_by_id(l, name) != NULL); @@ -291,7 +291,7 @@ gboolean osinfo_install_script_has_config_param_name(const OsinfoInstallScript * * list of valid #OsinfoInstallConfigParam parameters. Free with * g_list_free() when done. The elements are owned by libosinfo. */ -GList *osinfo_install_script_get_config_param_list(const OsinfoInstallScript *script) +GList *osinfo_install_script_get_config_param_list(OsinfoInstallScript *script) { return osinfo_list_get_elements(OSINFO_LIST(script->priv->config_params)); } @@ -305,7 +305,7 @@ GList *osinfo_install_script_get_config_param_list(const OsinfoInstallScript *sc * Returns: (transfer none): the list of valid #OsinfoInstallConfigParam * parameters. */ -OsinfoInstallConfigParamList *osinfo_install_script_get_config_params(const OsinfoInstallScript *script) +OsinfoInstallConfigParamList *osinfo_install_script_get_config_params(OsinfoInstallScript *script) { return script->priv->config_params; } @@ -321,7 +321,7 @@ OsinfoInstallConfigParamList *osinfo_install_script_get_config_params(const Osin * NULL otherwise. */ OsinfoInstallConfigParam * -osinfo_install_script_get_config_param(const OsinfoInstallScript *script, +osinfo_install_script_get_config_param(OsinfoInstallScript *script, const gchar *name) { /* NB: this code assumes that the 'id' and 'name' entity properties diff --git a/osinfo/osinfo_install_script.h b/osinfo/osinfo_install_script.h index 61bf0e4..e07ab5e 100644 --- a/osinfo/osinfo_install_script.h +++ b/osinfo/osinfo_install_script.h @@ -235,14 +235,14 @@ gchar *osinfo_install_script_generate_command_line_for_media(OsinfoInstallScript OsinfoMedia *media, OsinfoInstallConfig *config); -gboolean osinfo_install_script_has_config_param(const OsinfoInstallScript *script, const OsinfoInstallConfigParam *config_param); +gboolean osinfo_install_script_has_config_param(OsinfoInstallScript *script, OsinfoInstallConfigParam *config_param); -gboolean osinfo_install_script_has_config_param_name(const OsinfoInstallScript *script, const gchar *name); +gboolean osinfo_install_script_has_config_param_name(OsinfoInstallScript *script, const gchar *name); -OsinfoInstallConfigParam *osinfo_install_script_get_config_param(const OsinfoInstallScript *script, const gchar *name); +OsinfoInstallConfigParam *osinfo_install_script_get_config_param(OsinfoInstallScript *script, const gchar *name); -GList *osinfo_install_script_get_config_param_list(const OsinfoInstallScript *script); -OsinfoInstallConfigParamList *osinfo_install_script_get_config_params(const OsinfoInstallScript *script); +GList *osinfo_install_script_get_config_param_list(OsinfoInstallScript *script); +OsinfoInstallConfigParamList *osinfo_install_script_get_config_params(OsinfoInstallScript *script); OsinfoPathFormat osinfo_install_script_get_path_format(OsinfoInstallScript *script); gboolean osinfo_install_script_get_can_pre_install_drivers(OsinfoInstallScript *script); -- 2.13.6 From cfergeau at redhat.com Thu Nov 16 09:16:22 2017 From: cfergeau at redhat.com (Christophe Fergeau) Date: Thu, 16 Nov 2017 10:16:22 +0100 Subject: [Libosinfo] [PATCH] Drop redundant 'const' keyword from object parameters In-Reply-To: <20171112160419.32730-1-zeeshan@kinvolk.io> References: <20171112160419.32730-1-zeeshan@kinvolk.io> Message-ID: <20171116091622.GO8250@natto.ory.fergeau.eu> Hey, On Sun, Nov 12, 2017 at 05:04:19PM +0100, Zeeshan Ali wrote: > Use of 'const' parameter on object parameters is redundant, inconsistent > (both internally and against other GObject libraries) and currently breaks > the low-level Rust binding generator: > > https://github.com/gtk-rs/glib/pull/249 Could the Rust binding generator be fixed to cope with that instead? It's definitely not used consistently, but removing a 'const' from external API is going to cause breakage in C++ code: extern "C" { #include #include #include #include #include } int main(void) { const OsinfoInstallScript *script; osinfo_install_script_get_config_param(script, ""); return 0; } $ LC_ALL=C g++ $(pkg-config --cflags --libs libosinfo-1.0) ./osinfo.cpp ./osinfo.cpp: In function 'int main()': ./osinfo.cpp:12:58: error: invalid conversion from 'const OsinfoInstallScript* {aka const _OsinfoInstallScript*}' to 'OsinfoInstallScript* {aka _OsinfoInstallScript*}' [-fpermissive] osinfo_install_script_get_config_param(script, ""); In file included from ./osinfo.cpp:6:0: /usr/include/libosinfo-1.0/osinfo/osinfo_install_script.h:246:27: note: initializing argument 1 of 'OsinfoInstallConfigParam* osinfo_install_script_get_config_param(OsinfoInstallScript*, const gchar*)' OsinfoInstallConfigParam *osinfo_install_script_get_config_param(OsinfoInstallScript *script, const gchar *name); Christophe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From zeeshan at kinvolk.io Thu Nov 16 10:11:29 2017 From: zeeshan at kinvolk.io (Zeeshan Ali) Date: Thu, 16 Nov 2017 11:11:29 +0100 Subject: [Libosinfo] [PATCH] Drop redundant 'const' keyword from object parameters In-Reply-To: <20171116091622.GO8250@natto.ory.fergeau.eu> References: <20171112160419.32730-1-zeeshan@kinvolk.io> <20171116091622.GO8250@natto.ory.fergeau.eu> Message-ID: Hi Christophe, On Thu, Nov 16, 2017 at 10:16 AM, Christophe Fergeau wrote: > Hey, > > On Sun, Nov 12, 2017 at 05:04:19PM +0100, Zeeshan Ali wrote: >> Use of 'const' parameter on object parameters is redundant, inconsistent >> (both internally and against other GObject libraries) and currently breaks >> the low-level Rust binding generator: >> >> https://github.com/gtk-rs/glib/pull/249 > > Could the Rust binding generator be fixed to cope with that instead? I'm actually hoping for both to happen. :) > It's definitely not used consistently, but removing a 'const' from > external API is going to cause breakage in C++ code: Well that's true but IMHO this breakage is OK, given: * the unlikelyhood of an existing C++ project using libosinfo. * how trivial the fix is to this breakage. But that's just my opinion. :) P.S. Kudos for writing the actual code to test this. From cfergeau at redhat.com Fri Nov 17 10:57:29 2017 From: cfergeau at redhat.com (Christophe Fergeau) Date: Fri, 17 Nov 2017 11:57:29 +0100 Subject: [Libosinfo] [PATCH] Drop redundant 'const' keyword from object parameters In-Reply-To: References: <20171112160419.32730-1-zeeshan@kinvolk.io> <20171116091622.GO8250@natto.ory.fergeau.eu> Message-ID: <20171117105729.GM8250@natto.ory.fergeau.eu> Hey, > > It's definitely not used consistently, but removing a 'const' from > > external API is going to cause breakage in C++ code: > > Well that's true but IMHO this breakage is OK, given: > > * the unlikelyhood of an existing C++ project using libosinfo. This patch would fix generation of rust bindings, which have 0 users for sure at the moment since it's broken. So there are at least as many C++ projects using libosinfo, maybe more :) If the breakage is fixed in the Rust binding generator soon, I'd rather we drop this patch. Christophe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From berrange at redhat.com Fri Nov 17 11:10:08 2017 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 17 Nov 2017 11:10:08 +0000 Subject: [Libosinfo] [PATCH] Drop redundant 'const' keyword from object parameters In-Reply-To: <20171116091622.GO8250@natto.ory.fergeau.eu> References: <20171112160419.32730-1-zeeshan@kinvolk.io> <20171116091622.GO8250@natto.ory.fergeau.eu> Message-ID: <20171117111008.GF25830@redhat.com> On Thu, Nov 16, 2017 at 10:16:22AM +0100, Christophe Fergeau wrote: > Hey, > > On Sun, Nov 12, 2017 at 05:04:19PM +0100, Zeeshan Ali wrote: > > Use of 'const' parameter on object parameters is redundant, inconsistent > > (both internally and against other GObject libraries) and currently breaks > > the low-level Rust binding generator: > > > > https://github.com/gtk-rs/glib/pull/249 > > Could the Rust binding generator be fixed to cope with that instead? > It's definitely not used consistently, but removing a 'const' from > external API is going to cause breakage in C++ code: > > extern "C" { > #include > #include > #include > #include > #include > } > > int main(void) > { > const OsinfoInstallScript *script; The question is whether any C++ app will have actually declared it 'const' in the first place. I venture to suggest that most would have just don OsinfoInstallScript *script; since, that's what they need todo for all other APIs in libosinfo anyway. That way works both before & after this patch. So we're it won't break all C++ programs, only a small subset. IOW instead of breaking 0 users, this change will break 0 users (for a smaller value of 0 ) > osinfo_install_script_get_config_param(script, ""); > > return 0; > } Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| From zeeshan at kinvolk.io Fri Nov 17 11:05:57 2017 From: zeeshan at kinvolk.io (Zeeshan Ali) Date: Fri, 17 Nov 2017 12:05:57 +0100 Subject: [Libosinfo] [PATCH] Drop redundant 'const' keyword from object parameters In-Reply-To: <20171117105729.GM8250@natto.ory.fergeau.eu> References: <20171112160419.32730-1-zeeshan@kinvolk.io> <20171116091622.GO8250@natto.ory.fergeau.eu> <20171117105729.GM8250@natto.ory.fergeau.eu> Message-ID: On Fri, Nov 17, 2017 at 11:57 AM, Christophe Fergeau wrote: > Hey, > >> > It's definitely not used consistently, but removing a 'const' from >> > external API is going to cause breakage in C++ code: >> >> Well that's true but IMHO this breakage is OK, given: >> >> * the unlikelyhood of an existing C++ project using libosinfo. > > This patch would fix generation of rust bindings, which have 0 users > for sure at the moment since it's broken. So there are at least as many > C++ projects using libosinfo, maybe more :) It's true that Rust bindings are my main motivation here but it's not the only reason. I did mention consistency too, although that alone isn't enough of a justification for this small fix. Having said that, at least there are Rust bindings for libosinfo but I couldn't find any C++ bindings so I'm pretty sure there is no existing project using libosinfo and it will be pretty safe to break this API for C++ right now. But again, that's my opinion. > If the breakage is fixed in the Rust binding generator soon, I'd rather > we drop this patch. We'll see, it's not very simple IIUC. --- Zeeshan Ali Kinvolk GmbH Adalbertstr.6a, 10999 Berlin From berrange at redhat.com Fri Nov 17 11:19:37 2017 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 17 Nov 2017 11:19:37 +0000 Subject: [Libosinfo] [PATCH] Drop redundant 'const' keyword from object parameters In-Reply-To: References: <20171112160419.32730-1-zeeshan@kinvolk.io> <20171116091622.GO8250@natto.ory.fergeau.eu> <20171117105729.GM8250@natto.ory.fergeau.eu> Message-ID: <20171117111937.GH25830@redhat.com> On Fri, Nov 17, 2017 at 12:05:57PM +0100, Zeeshan Ali wrote: > On Fri, Nov 17, 2017 at 11:57 AM, Christophe Fergeau > wrote: > > Hey, > > > >> > It's definitely not used consistently, but removing a 'const' from > >> > external API is going to cause breakage in C++ code: > >> > >> Well that's true but IMHO this breakage is OK, given: > >> > >> * the unlikelyhood of an existing C++ project using libosinfo. > > > > This patch would fix generation of rust bindings, which have 0 users > > for sure at the moment since it's broken. So there are at least as many > > C++ projects using libosinfo, maybe more :) > > It's true that Rust bindings are my main motivation here but it's not > the only reason. I did mention consistency too, although that alone > isn't enough of a justification for this small fix. Having said that, > at least there are Rust bindings for libosinfo but I couldn't find any > C++ bindings so I'm pretty sure there is no existing project using > libosinfo and it will be pretty safe to break this API for C++ right > now. NB, there's no need for C++ bindings in general. C++ code can trivially call directly into C APIs. Someone would only create bindings if they absolutely wanted libosinfo objects to be proper C++ classes. That said, I still agree that I doubt there's any C++ users out there, because I've never heard of anyone in the virt space using C++ :-) Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| From berrange at redhat.com Fri Nov 17 11:21:21 2017 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 17 Nov 2017 11:21:21 +0000 Subject: [Libosinfo] [PATCH] Drop redundant 'const' keyword from object parameters In-Reply-To: <20171117105729.GM8250@natto.ory.fergeau.eu> References: <20171112160419.32730-1-zeeshan@kinvolk.io> <20171116091622.GO8250@natto.ory.fergeau.eu> <20171117105729.GM8250@natto.ory.fergeau.eu> Message-ID: <20171117112121.GI25830@redhat.com> On Fri, Nov 17, 2017 at 11:57:29AM +0100, Christophe Fergeau wrote: > Hey, > > > > It's definitely not used consistently, but removing a 'const' from > > > external API is going to cause breakage in C++ code: > > > > Well that's true but IMHO this breakage is OK, given: > > > > * the unlikelyhood of an existing C++ project using libosinfo. > > This patch would fix generation of rust bindings, which have 0 users > for sure at the moment since it's broken. So there are at least as many > C++ projects using libosinfo, maybe more :) > If the breakage is fixed in the Rust binding generator soon, I'd rather > we drop this patch. I'm on the fence, but I think on balance i'm slightly in favour of taking in the patch. It doesn't change ABI, only API so it would only be source level incompatible. Even then its only incompatible if the dev actually declared the variable const, which is about as likely as someone using C++ in the first place. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| From zeeshanak at gnome.org Fri Nov 17 11:26:48 2017 From: zeeshanak at gnome.org (Zeeshan Ali (Khattak)) Date: Fri, 17 Nov 2017 12:26:48 +0100 Subject: [Libosinfo] [PATCH] Drop redundant 'const' keyword from object parameters In-Reply-To: <20171117112121.GI25830@redhat.com> References: <20171112160419.32730-1-zeeshan@kinvolk.io> <20171116091622.GO8250@natto.ory.fergeau.eu> <20171117105729.GM8250@natto.ory.fergeau.eu> <20171117112121.GI25830@redhat.com> Message-ID: On 17 November 2017 at 12:21, Daniel P. Berrange wrote: > On Fri, Nov 17, 2017 at 11:57:29AM +0100, Christophe Fergeau wrote: >> Hey, >> >> > > It's definitely not used consistently, but removing a 'const' from >> > > external API is going to cause breakage in C++ code: >> > >> > Well that's true but IMHO this breakage is OK, given: >> > >> > * the unlikelyhood of an existing C++ project using libosinfo. >> >> This patch would fix generation of rust bindings, which have 0 users >> for sure at the moment since it's broken. So there are at least as many >> C++ projects using libosinfo, maybe more :) >> If the breakage is fixed in the Rust binding generator soon, I'd rather >> we drop this patch. > > I'm on the fence, but I think on balance i'm slightly in favour of taking > in the patch. It doesn't change ABI, only API so it would only be source > level incompatible. Even then its only incompatible if the dev actually > declared the variable const, which is about as likely as someone using > C++ in the first place. Moreover, it's super trivial fix for the build of C++ code. Does that fact help you cross the fence? :) -- Regards, Zeeshan Ali From cfergeau at redhat.com Fri Nov 17 13:09:02 2017 From: cfergeau at redhat.com (Christophe Fergeau) Date: Fri, 17 Nov 2017 14:09:02 +0100 Subject: [Libosinfo] [PATCH] Drop redundant 'const' keyword from object parameters In-Reply-To: <20171117112121.GI25830@redhat.com> References: <20171112160419.32730-1-zeeshan@kinvolk.io> <20171116091622.GO8250@natto.ory.fergeau.eu> <20171117105729.GM8250@natto.ory.fergeau.eu> <20171117112121.GI25830@redhat.com> Message-ID: <20171117130902.GP8250@natto.ory.fergeau.eu> On Fri, Nov 17, 2017 at 11:21:21AM +0000, Daniel P. Berrange wrote: > On Fri, Nov 17, 2017 at 11:57:29AM +0100, Christophe Fergeau wrote: > > Hey, > > > > > > It's definitely not used consistently, but removing a 'const' from > > > > external API is going to cause breakage in C++ code: > > > > > > Well that's true but IMHO this breakage is OK, given: > > > > > > * the unlikelyhood of an existing C++ project using libosinfo. > > > > This patch would fix generation of rust bindings, which have 0 users > > for sure at the moment since it's broken. So there are at least as many > > C++ projects using libosinfo, maybe more :) > > If the breakage is fixed in the Rust binding generator soon, I'd rather > > we drop this patch. > > I'm on the fence, but I think on balance i'm slightly in favour of taking > in the patch. It doesn't change ABI, only API so it would only be source > level incompatible. Even then its only incompatible if the dev actually > declared the variable const, which is about as likely as someone using > C++ in the first place. Yes, your point about the actual object most likely being declared without the "const" modifier also makes me lean towards taking it. Christophe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From cfergeau at redhat.com Fri Nov 17 13:09:52 2017 From: cfergeau at redhat.com (Christophe Fergeau) Date: Fri, 17 Nov 2017 14:09:52 +0100 Subject: [Libosinfo] [PATCH] Drop redundant 'const' keyword from object parameters In-Reply-To: References: <20171112160419.32730-1-zeeshan@kinvolk.io> <20171116091622.GO8250@natto.ory.fergeau.eu> <20171117105729.GM8250@natto.ory.fergeau.eu> <20171117112121.GI25830@redhat.com> Message-ID: <20171117130952.GQ8250@natto.ory.fergeau.eu> On Fri, Nov 17, 2017 at 12:26:48PM +0100, Zeeshan Ali (Khattak) wrote: > On 17 November 2017 at 12:21, Daniel P. Berrange wrote: > > On Fri, Nov 17, 2017 at 11:57:29AM +0100, Christophe Fergeau wrote: > >> Hey, > >> > >> > > It's definitely not used consistently, but removing a 'const' from > >> > > external API is going to cause breakage in C++ code: > >> > > >> > Well that's true but IMHO this breakage is OK, given: > >> > > >> > * the unlikelyhood of an existing C++ project using libosinfo. > >> > >> This patch would fix generation of rust bindings, which have 0 users > >> for sure at the moment since it's broken. So there are at least as many > >> C++ projects using libosinfo, maybe more :) > >> If the breakage is fixed in the Rust binding generator soon, I'd rather > >> we drop this patch. > > > > I'm on the fence, but I think on balance i'm slightly in favour of taking > > in the patch. It doesn't change ABI, only API so it would only be source > > level incompatible. Even then its only incompatible if the dev actually > > declared the variable const, which is about as likely as someone using > > C++ in the first place. > > Moreover, it's super trivial fix for the build of C++ code. Does that > fact help you cross the fence? :) If you go the ugly way (add a cast from const to non-const), then yes it's probably trivial to change. If you want to do things properly, then I would not call it "super trivial" Christophe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From cfergeau at redhat.com Fri Nov 17 13:13:13 2017 From: cfergeau at redhat.com (Christophe Fergeau) Date: Fri, 17 Nov 2017 14:13:13 +0100 Subject: [Libosinfo] [PATCH] Drop redundant 'const' keyword from object parameters In-Reply-To: <20171117130902.GP8250@natto.ory.fergeau.eu> References: <20171112160419.32730-1-zeeshan@kinvolk.io> <20171116091622.GO8250@natto.ory.fergeau.eu> <20171117105729.GM8250@natto.ory.fergeau.eu> <20171117112121.GI25830@redhat.com> <20171117130902.GP8250@natto.ory.fergeau.eu> Message-ID: <20171117131313.GR8250@natto.ory.fergeau.eu> On Fri, Nov 17, 2017 at 02:09:02PM +0100, Christophe Fergeau wrote: > On Fri, Nov 17, 2017 at 11:21:21AM +0000, Daniel P. Berrange wrote: > > On Fri, Nov 17, 2017 at 11:57:29AM +0100, Christophe Fergeau wrote: > > > Hey, > > > > > > > > It's definitely not used consistently, but removing a 'const' from > > > > > external API is going to cause breakage in C++ code: > > > > > > > > Well that's true but IMHO this breakage is OK, given: > > > > > > > > * the unlikelyhood of an existing C++ project using libosinfo. > > > > > > This patch would fix generation of rust bindings, which have 0 users > > > for sure at the moment since it's broken. So there are at least as many > > > C++ projects using libosinfo, maybe more :) > > > If the breakage is fixed in the Rust binding generator soon, I'd rather > > > we drop this patch. > > > > I'm on the fence, but I think on balance i'm slightly in favour of taking > > in the patch. It doesn't change ABI, only API so it would only be source > > level incompatible. Even then its only incompatible if the dev actually > > declared the variable const, which is about as likely as someone using > > C++ in the first place. > > Yes, your point about the actual object most likely being declared > without the "const" modifier also makes me lean towards taking it. As usual, forgot to finish the email, but Acked-by: Christophe Fergeau -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From fabiano at fidencio.org Fri Nov 17 14:53:25 2017 From: fabiano at fidencio.org (=?UTF-8?q?Fabiano=20Fid=C3=AAncio?=) Date: Fri, 17 Nov 2017 15:53:25 +0100 Subject: [Libosinfo] [osinfo-db.libosinfo] Avoid recommended resources being smaller than minimum resources Message-ID: <20171117145327.32611-1-fabiano@fidencio.org> Those 2 patches fixes a problem originally found when trying to customize the disk size of RHEL when using GNOME Boxes. The first one adjusts the values according to: https://access.redhat.com/articles/rhel-limits The second one adds a test to avoid any regression on this part. Fabiano Fid?ncio (2): (osinfo-db) rhel,centos: Fix recommended resources (libosinfo) tests: Add test-os-resources osinfo-db/data/os/centos.org/centos-7.0.xml.in | 4 ++-- osinfo-db/data/os/redhat.com/rhel-7.0.xml.in | 6 +++--- osinfo-db/data/os/redhat.com/rhel-7.1.xml.in | 6 +++--- osinfo-db/data/os/redhat.com/rhel-7.2.xml.in | 6 +++--- osinfo-db/data/os/redhat.com/rhel-7.3.xml.in | 6 +++--- osinfo-db/data/os/redhat.com/rhel-7.4.xml.in | 6 +++--- osinfo-db/data/os/redhat.com/rhel-atomic-7.0.xml.in | 4 ++-- osinfo-db/data/os/redhat.com/rhel-atomic-7.1.xml.in | 4 ++-- osinfo-db/data/os/redhat.com/rhel-atomic-7.2.xml.in | 4 ++-- 9 files changed, 23 insertions(+), 23 deletions(-) libosinfo/tests/Makefile.am | 5 ++ libonsinfo/tests/test-os-resources.c | 184 ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 189 insertions(+) -- 2.13.6 From fabiano at fidencio.org Fri Nov 17 14:53:26 2017 From: fabiano at fidencio.org (=?UTF-8?q?Fabiano=20Fid=C3=AAncio?=) Date: Fri, 17 Nov 2017 15:53:26 +0100 Subject: [Libosinfo] [osinfo-db] rhel,centos: Fix recommended resources In-Reply-To: <20171117145327.32611-1-fabiano@fidencio.org> References: <20171117145327.32611-1-fabiano@fidencio.org> Message-ID: <20171117145327.32611-2-fabiano@fidencio.org> Both RHEL and CentOS have some wrong values set for minimum and recommended ram and storage size. I've adjusted the recommended resources values according to: https://access.redhat.com/articles/rhel-limits Signed-off-by: Fabiano Fid?ncio --- data/os/centos.org/centos-7.0.xml.in | 4 ++-- data/os/redhat.com/rhel-7.0.xml.in | 6 +++--- data/os/redhat.com/rhel-7.1.xml.in | 6 +++--- data/os/redhat.com/rhel-7.2.xml.in | 6 +++--- data/os/redhat.com/rhel-7.3.xml.in | 6 +++--- data/os/redhat.com/rhel-7.4.xml.in | 6 +++--- data/os/redhat.com/rhel-atomic-7.0.xml.in | 4 ++-- data/os/redhat.com/rhel-atomic-7.1.xml.in | 4 ++-- data/os/redhat.com/rhel-atomic-7.2.xml.in | 4 ++-- 9 files changed, 23 insertions(+), 23 deletions(-) diff --git a/data/os/centos.org/centos-7.0.xml.in b/data/os/centos.org/centos-7.0.xml.in index a58c642..cdeb28a 100644 --- a/data/os/centos.org/centos-7.0.xml.in +++ b/data/os/centos.org/centos-7.0.xml.in @@ -31,9 +31,9 @@ - 400000000 + 1000000000 1073741824 - 9663676416 + 10737418240 diff --git a/data/os/redhat.com/rhel-7.0.xml.in b/data/os/redhat.com/rhel-7.0.xml.in index bdf6231..e841ab3 100644 --- a/data/os/redhat.com/rhel-7.0.xml.in +++ b/data/os/redhat.com/rhel-7.0.xml.in @@ -48,7 +48,7 @@ - 400000000 + 1000000000 2147483648 21474836480 @@ -63,9 +63,9 @@ - 400000000 + 1000000000 1073741824 - 9663676416 + 10737418240 diff --git a/data/os/redhat.com/rhel-7.1.xml.in b/data/os/redhat.com/rhel-7.1.xml.in index 984e82a..8a43acf 100644 --- a/data/os/redhat.com/rhel-7.1.xml.in +++ b/data/os/redhat.com/rhel-7.1.xml.in @@ -41,7 +41,7 @@ - 400000000 + 1000000000 2147483648 21474836480 @@ -56,9 +56,9 @@ - 400000000 + 1000000000 1073741824 - 9663676416 + 10737418240 diff --git a/data/os/redhat.com/rhel-7.2.xml.in b/data/os/redhat.com/rhel-7.2.xml.in index 7344341..6763445 100644 --- a/data/os/redhat.com/rhel-7.2.xml.in +++ b/data/os/redhat.com/rhel-7.2.xml.in @@ -60,7 +60,7 @@ - 400000000 + 1000000000 2147483648 21474836480 @@ -75,9 +75,9 @@ - 400000000 + 1000000000 1073741824 - 9663676416 + 10737418240 diff --git a/data/os/redhat.com/rhel-7.3.xml.in b/data/os/redhat.com/rhel-7.3.xml.in index 894f511..4418af7 100644 --- a/data/os/redhat.com/rhel-7.3.xml.in +++ b/data/os/redhat.com/rhel-7.3.xml.in @@ -60,7 +60,7 @@ - 400000000 + 1000000000 2147483648 21474836480 @@ -75,9 +75,9 @@ - 400000000 + 1000000000 1073741824 - 9663676416 + 10737418240 diff --git a/data/os/redhat.com/rhel-7.4.xml.in b/data/os/redhat.com/rhel-7.4.xml.in index a230d68..72bb357 100644 --- a/data/os/redhat.com/rhel-7.4.xml.in +++ b/data/os/redhat.com/rhel-7.4.xml.in @@ -60,7 +60,7 @@ - 400000000 + 1000000000 2147483648 21474836480 @@ -75,9 +75,9 @@ - 400000000 + 1000000000 1073741824 - 9663676416 + 10737418240 diff --git a/data/os/redhat.com/rhel-atomic-7.0.xml.in b/data/os/redhat.com/rhel-atomic-7.0.xml.in index cb9434e..31f5d7f 100644 --- a/data/os/redhat.com/rhel-atomic-7.0.xml.in +++ b/data/os/redhat.com/rhel-atomic-7.0.xml.in @@ -36,9 +36,9 @@ - 400000000 + 1000000000 1073741824 - 9663676416 + 10737418240 diff --git a/data/os/redhat.com/rhel-atomic-7.1.xml.in b/data/os/redhat.com/rhel-atomic-7.1.xml.in index d01a70e..a5302b6 100644 --- a/data/os/redhat.com/rhel-atomic-7.1.xml.in +++ b/data/os/redhat.com/rhel-atomic-7.1.xml.in @@ -42,9 +42,9 @@ - 400000000 + 1000000000 1073741824 - 9663676416 + 10737418240 diff --git a/data/os/redhat.com/rhel-atomic-7.2.xml.in b/data/os/redhat.com/rhel-atomic-7.2.xml.in index 4734ed5..c4ff6e3 100644 --- a/data/os/redhat.com/rhel-atomic-7.2.xml.in +++ b/data/os/redhat.com/rhel-atomic-7.2.xml.in @@ -31,9 +31,9 @@ - 400000000 + 1000000000 1073741824 - 9663676416 + 10737418240 -- 2.13.6 From fabiano at fidencio.org Fri Nov 17 14:53:27 2017 From: fabiano at fidencio.org (=?UTF-8?q?Fabiano=20Fid=C3=AAncio?=) Date: Fri, 17 Nov 2017 15:53:27 +0100 Subject: [Libosinfo] [libosinfo] tests: Add test-os-resources In-Reply-To: <20171117145327.32611-1-fabiano@fidencio.org> References: <20171117145327.32611-1-fabiano@fidencio.org> Message-ID: <20171117145327.32611-3-fabiano@fidencio.org> test-os-resources has been written to avoid bug as having minimum resources greater than the recommended resources in osinfo-db. It has been hitting (without any harm no far) by RHEL/CentOS data files, which caused so really bad UI effect on clients using those two attributes (as in GNOME Boxes). Signed-off-by: Fabiano Fid?ncio --- tests/Makefile.am | 5 ++ tests/test-os-resources.c | 184 ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 189 insertions(+) create mode 100644 tests/test-os-resources.c diff --git a/tests/Makefile.am b/tests/Makefile.am index 7566d3c..06f81bf 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -17,6 +17,7 @@ check_PROGRAMS = \ test-loader \ test-isodetect \ test-install-script \ + test-os-resources \ $(NULL) if HAVE_CURL @@ -111,6 +112,10 @@ test_install_script_LDADD = $(COMMON_LDADD) test_install_script_CFLAGS = $(COMMON_CFLAGS) test_install_script_SOURCES = test-install-script.c +test_os_resources_LDADD = $(COMMON_LDADD) +test_os_resources_CFLAGS = $(COMMON_CFLAGS) +test_os_resources_SOURCES = test-os-resources.c + TESTS = $(check_PROGRAMS) \ $(NULL) diff --git a/tests/test-os-resources.c b/tests/test-os-resources.c new file mode 100644 index 0000000..9942d9c --- /dev/null +++ b/tests/test-os-resources.c @@ -0,0 +1,184 @@ +/* + * Copyright (C) 2017 Fabiano Fid?ncio + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, + * Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + * + * Authors: + * Fabiano Fid?ncio + */ + +#include + +#include +#include + + +static void test_n_cpus(OsinfoResources *minimum, OsinfoResources *recommended) +{ + gint minimum_cpus, recommended_cpus; + + minimum_cpus = osinfo_resources_get_n_cpus(minimum); + recommended_cpus = osinfo_resources_get_n_cpus(recommended); + + if (recommended_cpus >= 0 && minimum_cpus >= 0) + g_assert_true(recommended_cpus >= minimum_cpus); +} + + +static void test_cpu(OsinfoResources *minimum, OsinfoResources *recommended) +{ + gint64 minimum_cpu, recommended_cpu; + + minimum_cpu = osinfo_resources_get_cpu(minimum); + recommended_cpu = osinfo_resources_get_cpu(recommended); + + if (recommended_cpu >= 0 && minimum_cpu >= 0) + g_assert_true(recommended_cpu >= minimum_cpu); +} + + +static void test_ram(OsinfoResources *minimum, OsinfoResources *recommended) +{ + gint64 minimum_ram, recommended_ram; + + minimum_ram = osinfo_resources_get_ram(minimum); + recommended_ram = osinfo_resources_get_ram(recommended); + + if (recommended_ram >= 0 && minimum_ram >= 0) + g_assert_true(recommended_ram >= minimum_ram); +} + + +static void test_storage(OsinfoResources *minimum, OsinfoResources *recommended) +{ + gint64 minimum_storage, recommended_storage; + + minimum_storage = osinfo_resources_get_storage(minimum); + recommended_storage = osinfo_resources_get_storage(recommended); + + if (recommended_storage >= 0 && minimum_storage >= 0) + g_assert_true(recommended_storage >= minimum_storage); +} + +static void +test_minimum_recommended_resources(void) +{ + OsinfoLoader *loader = osinfo_loader_new(); + OsinfoDb *db = osinfo_loader_get_db(loader); + OsinfoOsList *oslist; + GList *oses; + GError *error = NULL; + + g_assert_true(OSINFO_IS_LOADER(loader)); + g_assert_true(OSINFO_IS_DB(db)); + + osinfo_loader_process_default_path(loader, &error); + g_assert_no_error(error); + + oslist = osinfo_db_get_os_list(db); + oses = osinfo_list_get_elements(OSINFO_LIST(oslist)); + + for (; oses != NULL; oses = oses->next) { + OsinfoOs *os = oses->data; + OsinfoResourcesList *minimum_list, *recommended_list; + GList *minimum_resources, *recommended_resources; + const gchar *minimum_arch, * recommended_arch; + + minimum_list = osinfo_os_get_minimum_resources(os); + minimum_resources = osinfo_list_get_elements(OSINFO_LIST(minimum_list)); + + recommended_list = osinfo_os_get_recommended_resources(os); + recommended_resources = osinfo_list_get_elements(OSINFO_LIST(recommended_list)); + + /* That's fine as not all OSes have those fields filled */ + if (minimum_resources == NULL || recommended_resources == NULL) + continue; + + for (; minimum_resources != NULL; + minimum_resources = minimum_resources->next) { + OsinfoResources *minimum = minimum_resources->data; + GList *tmp = recommended_resources; + + minimum_arch = osinfo_resources_get_architecture(minimum); + + + for (; tmp != NULL; tmp = tmp->next) { + OsinfoResources *recommended = tmp->data; + + recommended_arch = osinfo_resources_get_architecture(recommended); + + if (g_str_equal(minimum_arch, recommended_arch)) { + const gchar *name; + + name = osinfo_product_get_name(OSINFO_PRODUCT(os)); + + g_test_message("checking %s (architecture: %s)", + name, minimum_arch); + + test_n_cpus(minimum, recommended); + test_cpu(minimum, recommended); + test_ram(minimum, recommended); + test_storage(minimum, recommended); + break; + } + } + } + + g_object_unref(minimum_list); + g_object_unref(recommended_list); + } + + if (oslist) + g_object_unref(oslist); + + g_object_unref(loader); +} + + +int +main(int argc, char *argv[]) +{ + int ret; + + g_test_init(&argc, &argv, NULL); + + g_test_add_func("/os/resources/minimum_recommended", test_minimum_recommended_resources); + + /* Make sure we catch unexpected g_warning() */ + g_log_set_always_fatal(G_LOG_LEVEL_ERROR | G_LOG_LEVEL_CRITICAL | G_LOG_LEVEL_WARNING); + + /* Upfront so we don't confuse valgrind */ + osinfo_entity_get_type(); + osinfo_db_get_type(); + osinfo_device_get_type(); + osinfo_platform_get_type(); + osinfo_os_get_type(); + osinfo_list_get_type(); + osinfo_devicelist_get_type(); + osinfo_platformlist_get_type(); + osinfo_oslist_get_type(); + osinfo_filter_get_type(); + + ret = g_test_run(); + + return ret; +} +/* + * Local variables: + * indent-tabs-mode: nil + * c-indent-level: 4 + * c-basic-offset: 4 + * End: + */ -- 2.13.6 From pierre-alain.toret at protonmail.com Wed Nov 22 09:47:21 2017 From: pierre-alain.toret at protonmail.com (Pierre-Alain TORET) Date: Wed, 22 Nov 2017 10:47:21 +0100 Subject: [Libosinfo] [PATCH osinfo-db] fedora: add Fedora 27 info Message-ID: <20171122094721.14525-1-pierre-alain.toret@protonmail.com> Signed-off-by: Pierre-Alain TORET --- data/os/fedoraproject.org/fedora-27.xml.in | 114 +++++++++++++++++++++++++++++ 1 file changed, 114 insertions(+) create mode 100644 data/os/fedoraproject.org/fedora-27.xml.in diff --git a/data/os/fedoraproject.org/fedora-27.xml.in b/data/os/fedoraproject.org/fedora-27.xml.in new file mode 100644 index 0000000..53881ca --- /dev/null +++ b/data/os/fedoraproject.org/fedora-27.xml.in @@ -0,0 +1,114 @@ + + + + fedora27 + <_name>Fedora 27 + 27 + <_vendor>Fedora Project + linux + fedora + + + + 2017-11-14 + + + <_name>Fedora 27 Workstation + + + <_name>Fedora 27 Workstation + + + <_name>Fedora 27 Server + + + <_name>Fedora 27 Server + + + + + + + + https://download.fedoraproject.org/pub/fedora/linux/releases/27/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-27-1.6.iso + + Fedora-WS-Live-27.* + LINUX + + isolinux/vmlinuz + isolinux/initrd.img + + + + + + https://download.fedoraproject.org/pub/fedora/linux/releases/27/Workstation/x86_64/iso/Fedora-Workstation-netinst-x86_64-27-1.6.iso + + Fedora-WS-dvd-x86_64-26 + LINUX + + isolinux/vmlinuz + isolinux/initrd.img + + + + + + + + https://download.fedoraproject.org/pub/fedora/linux/releases/27/Server/x86_64/iso/Fedora-Server-dvd-x86_64-27-1.6.iso + + Fedora-S-dvd-x86_64-27 + LINUX + 2490368000 + + isolinux/vmlinuz + isolinux/initrd.img + + + + + + https://download.fedoraproject.org/pub/fedora/linux/releases/27/Server/x86_64/iso/Fedora-Server-netinst-x86_64-27-1.6.iso + + Fedora-S-dvd-x86_64-27 + LINUX + 535822336 + + isolinux/vmlinuz + isolinux/initrd.img + + + + https://download.fedoraproject.org/pub/fedora/linux/releases/27/Server/x86_64/os/ + + + Fedora + 27 + x86_64 + + + + + + + + 1 + 1000000000 + 1073741824 + 10737418240 + + + + 2147483648 + 21474836480 + + + + +