Re: [Libosinfo] [libosinfo/osinfo-db PATCH 0/2] Revert e616846 and fix win-10 volume ids
On 10/08/2018 09:09 AM, Fabiano Fidêncio wrote: On Fri, 2018-10-05 at 14:00 -0400, Cole Robinson wrote: On 10/04/2018 06:51 AM, Fabiano Fidêncio wrote: Let's revert e6168463f and. instead of forcing anchored patterns on libosinfo, let's fix the problematic volume-ids on osinfo-db. libosinfo: Fabiano Fidêncio (1): Revert "db: Force anchored patterns when matching regex" osinfo/osinfo_db.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) osinfo-db: Fabiano Fidêncio (1): win10: Anchor some volume-ids ACK, though I still think we should discourage non-anchored regex, it's going to make it easier for subtle problems to slip in. Is the rng schema strictly enforced anywhere in the stack, or is it only informative? (like libvirt xml schema). If it's the latter, I'd suggest we extend the schema to complain about non-anchored regex, and update every entry in our db to be explicitly anchored. So we aren't breaking API, but if users are running osinfo-db-validate they will see warnings If yall agree I can file a bug for it Please, file a bug for it and we can have the discussion there in case someone disagrees with that. https://bugzilla.redhat.com/show_bug.cgi?id=1637667 - Cole ___ Libosinfo mailing list Libosinfo@redhat.com https://www.redhat.com/mailman/listinfo/libosinfo
Re: [Libosinfo] [PATCH osinfo-db v3 0/3] Add q35 chipset
On 10/09/2018 11:13 AM, Cole Robinson wrote: The main goal of this series is to advertise q35 chipset and device support for suitable OS. We should probably continue design discussions in the v2 thread, this is just a small bug fix update. v1 posting: https://www.redhat.com/archives/libosinfo/2018-August/msg6.html v2 posting: https://www.redhat.com/archives/libosinfo/2018-September/msg00162.html v3 changes: * Push patch 1+2 * Fix chipet device ID URL in data/os/ Example virt-manager patch for enabling q35: https://github.com/crobinso/virt-manager/tree/q35 Cole Robinson (3): device: Add chipset q35 os: Add q35/e1000e/ich9 for win2k8r2+ and win7+ os: linux: Add q35/ich9/e1000e alongside virtio1.0 data/device/qemu.org/chipset-x86_64-q35.d/class.xml.in | 8 data/os/debian.org/debian-9.xml.in | 3 +++ data/os/fedoraproject.org/fedora-23.xml.in | 5 - data/os/microsoft.com/win-2k8r2.xml.in | 6 ++ data/os/microsoft.com/win-7.xml.in | 3 +++ data/os/opensuse.org/opensuse-42.2.xml.in | 3 +++ data/os/redhat.com/rhel-7.2.xml.in | 3 +++ data/os/suse.com/sled-12.2.xml.in | 3 +++ data/os/suse.com/sles-12.2.xml.in | 3 +++ data/os/ubuntu.com/ubuntu-17.04.xml.in | 3 +++ data/schema/osinfo.rng.in | 1 + 11 files changed, 40 insertions(+), 1 deletion(-) create mode 100644 data/device/qemu.org/chipset-x86_64-q35.d/class.xml.in Apologies, I screwed up this mailing, ignore the duplicate patches - Cole ___ Libosinfo mailing list Libosinfo@redhat.com https://www.redhat.com/mailman/listinfo/libosinfo
[Libosinfo] [PATCH osinfo-db 1/3] device: Add chipset q35
Introduce a new URI scheme and class chipset.virtual, rather than attach this to any particular PCI ID. Signed-off-by: Cole Robinson --- data/device/qemu.org/chipset-x86_64-q35.d/class.xml.in | 8 data/schema/osinfo.rng.in | 1 + 2 files changed, 9 insertions(+) create mode 100644 data/device/qemu.org/chipset-x86_64-q35.d/class.xml.in diff --git a/data/device/qemu.org/chipset-x86_64-q35.d/class.xml.in b/data/device/qemu.org/chipset-x86_64-q35.d/class.xml.in new file mode 100644 index 000..6920c67 --- /dev/null +++ b/data/device/qemu.org/chipset-x86_64-q35.d/class.xml.in @@ -0,0 +1,8 @@ + + + http://qemu.org/chipset/x86_64/q35;> +q35 +chipset.virtual + + diff --git a/data/schema/osinfo.rng.in b/data/schema/osinfo.rng.in index fa09249..fc45dbd 100644 --- a/data/schema/osinfo.rng.in +++ b/data/schema/osinfo.rng.in @@ -77,6 +77,7 @@ audio block console + chipset.virtual controller.usb filesystem input -- 2.19.0 ___ Libosinfo mailing list Libosinfo@redhat.com https://www.redhat.com/mailman/listinfo/libosinfo
[Libosinfo] [PATCH osinfo-db v3 0/3] Add q35 chipset
The main goal of this series is to advertise q35 chipset and device support for suitable OS. We should probably continue design discussions in the v2 thread, this is just a small bug fix update. v1 posting: https://www.redhat.com/archives/libosinfo/2018-August/msg6.html v2 posting: https://www.redhat.com/archives/libosinfo/2018-September/msg00162.html v3 changes: * Push patch 1+2 * Fix chipet device ID URL in data/os/ Example virt-manager patch for enabling q35: https://github.com/crobinso/virt-manager/tree/q35 Cole Robinson (3): device: Add chipset q35 os: Add q35/e1000e/ich9 for win2k8r2+ and win7+ os: linux: Add q35/ich9/e1000e alongside virtio1.0 data/device/qemu.org/chipset-x86_64-q35.d/class.xml.in | 8 data/os/debian.org/debian-9.xml.in | 3 +++ data/os/fedoraproject.org/fedora-23.xml.in | 5 - data/os/microsoft.com/win-2k8r2.xml.in | 6 ++ data/os/microsoft.com/win-7.xml.in | 3 +++ data/os/opensuse.org/opensuse-42.2.xml.in | 3 +++ data/os/redhat.com/rhel-7.2.xml.in | 3 +++ data/os/suse.com/sled-12.2.xml.in | 3 +++ data/os/suse.com/sles-12.2.xml.in | 3 +++ data/os/ubuntu.com/ubuntu-17.04.xml.in | 3 +++ data/schema/osinfo.rng.in | 1 + 11 files changed, 40 insertions(+), 1 deletion(-) create mode 100644 data/device/qemu.org/chipset-x86_64-q35.d/class.xml.in -- 2.19.0 ___ Libosinfo mailing list Libosinfo@redhat.com https://www.redhat.com/mailman/listinfo/libosinfo
[Libosinfo] [PATCH osinfo-db v3 2/3] os: Add q35/e1000e/ich9 for win2k8r2+ and win7+
I haven't explicitly tested either of these. However there's been users of win7 and q35 in the wild, mostly for vga passthrough AFAICT, so this should work. win2k8r2 is roughly the same vintage as win7 Signed-off-by: Cole Robinson --- data/os/microsoft.com/win-2k8r2.xml.in | 6 ++ data/os/microsoft.com/win-7.xml.in | 3 +++ 2 files changed, 9 insertions(+) diff --git a/data/os/microsoft.com/win-2k8r2.xml.in b/data/os/microsoft.com/win-2k8r2.xml.in index 2edb169..68d1f16 100644 --- a/data/os/microsoft.com/win-2k8r2.xml.in +++ b/data/os/microsoft.com/win-2k8r2.xml.in @@ -14,6 +14,12 @@ 2009-10-22 2013-07-09 + + http://qemu.org/chipset/x86_64/q35"/> + http://pcisig.com/pci/8086/10d3"/> + http://pcisig.com/pci/8086/293e"/> + + (GRMSXVOL|GRMSXFRER|GRMSHXVOL)_ diff --git a/data/os/microsoft.com/win-7.xml.in b/data/os/microsoft.com/win-7.xml.in index fc196a0..6c8c819 100644 --- a/data/os/microsoft.com/win-7.xml.in +++ b/data/os/microsoft.com/win-7.xml.in @@ -182,6 +182,9 @@ http://pcisig.com/pci/8086/2668"/> + http://qemu.org/chipset/x86_64/q35"/> + http://pcisig.com/pci/8086/10d3"/> + http://pcisig.com/pci/8086/293e"/> -- 2.19.0 ___ Libosinfo mailing list Libosinfo@redhat.com https://www.redhat.com/mailman/listinfo/libosinfo
[Libosinfo] [PATCH osinfo-db 2/3] os: Add q35/e1000e/ich9 for win2k8r2+ and win7+
I haven't explicitly tested either of these. However there's been users of win7 and q35 in the wild, mostly for vga passthrough AFAICT, so this should work. win2k8r2 is roughly the same vintage as win7 Signed-off-by: Cole Robinson --- data/os/microsoft.com/win-2k8r2.xml.in | 6 ++ data/os/microsoft.com/win-7.xml.in | 3 +++ 2 files changed, 9 insertions(+) diff --git a/data/os/microsoft.com/win-2k8r2.xml.in b/data/os/microsoft.com/win-2k8r2.xml.in index 2edb169..68d1f16 100644 --- a/data/os/microsoft.com/win-2k8r2.xml.in +++ b/data/os/microsoft.com/win-2k8r2.xml.in @@ -14,6 +14,12 @@ 2009-10-22 2013-07-09 + + http://qemu.org/chipset/x86_64/q35"/> + http://pcisig.com/pci/8086/10d3"/> + http://pcisig.com/pci/8086/293e"/> + + (GRMSXVOL|GRMSXFRER|GRMSHXVOL)_ diff --git a/data/os/microsoft.com/win-7.xml.in b/data/os/microsoft.com/win-7.xml.in index fc196a0..6c8c819 100644 --- a/data/os/microsoft.com/win-7.xml.in +++ b/data/os/microsoft.com/win-7.xml.in @@ -182,6 +182,9 @@ http://pcisig.com/pci/8086/2668"/> + http://qemu.org/chipset/x86_64/q35"/> + http://pcisig.com/pci/8086/10d3"/> + http://pcisig.com/pci/8086/293e"/> -- 2.19.0 ___ Libosinfo mailing list Libosinfo@redhat.com https://www.redhat.com/mailman/listinfo/libosinfo
[Libosinfo] [PATCH osinfo-db v3 0/3] Add q35 chipset
The main goal of this series is to advertise q35 chipset and device support for suitable OS. We should probably continue design discussions in the v2 thread, this is just a small bug fix update. v1 posting: https://www.redhat.com/archives/libosinfo/2018-August/msg6.html v2 posting: https://www.redhat.com/archives/libosinfo/2018-September/msg00162.html v3 changes: * Push patch 1+2 * Fix chipet device ID URL in data/os/ Example virt-manager patch for enabling q35: https://github.com/crobinso/virt-manager/tree/q35 Cole Robinson (3): device: Add chipset q35 os: Add q35/e1000e/ich9 for win2k8r2+ and win7+ os: linux: Add q35/ich9/e1000e alongside virtio1.0 data/device/qemu.org/chipset-x86_64-q35.d/class.xml.in | 8 data/os/debian.org/debian-9.xml.in | 3 +++ data/os/fedoraproject.org/fedora-23.xml.in | 5 - data/os/microsoft.com/win-2k8r2.xml.in | 6 ++ data/os/microsoft.com/win-7.xml.in | 3 +++ data/os/opensuse.org/opensuse-42.2.xml.in | 3 +++ data/os/redhat.com/rhel-7.2.xml.in | 3 +++ data/os/suse.com/sled-12.2.xml.in | 3 +++ data/os/suse.com/sles-12.2.xml.in | 3 +++ data/os/ubuntu.com/ubuntu-17.04.xml.in | 3 +++ data/schema/osinfo.rng.in | 1 + 11 files changed, 40 insertions(+), 1 deletion(-) create mode 100644 data/device/qemu.org/chipset-x86_64-q35.d/class.xml.in -- 2.19.0 ___ Libosinfo mailing list Libosinfo@redhat.com https://www.redhat.com/mailman/listinfo/libosinfo
[Libosinfo] [osinfo-db-tools PATCH 0/1] RFC: Introduce "--latest" to osinfo-db-import
This patches introduces the "--latest" option to osinfo-db-import, which can be used to download and install the latest officially released osinfo-db. The approach taken, at least in this RFC, is to have a file which contains the version and URL of the latest osinfo-db. Whether we'd stick to the very simple format used or change it to something else ... it's totally open for discussion. For testing purposes, the file is part of my fedorapeople's space but in the final version of the patch I'd like to fetch that from libosinfo.org. The file is small enough that (hopefully) wouldn't cause traffic problems on libosinfo's website and adding libosinfo.org in our source code seems way more sane than adding "pagure"/"gitlab" ... In order to test those patches, you'd need to have the following series applied: https://www.redhat.com/archives/libosinfo/2018-October/msg00046.html Here you can find a branch on my gitlab which contains all the patches: https://gitlab.com/fidencio/osinfo-db-tools/tree/wip/import_latest Fabiano Fidêncio (1): import: Introduce "--latest" option tools/osinfo-db-import.c | 155 +++ 1 file changed, 155 insertions(+) -- 2.19.1 ___ Libosinfo mailing list Libosinfo@redhat.com https://www.redhat.com/mailman/listinfo/libosinfo
[Libosinfo] [osinfo-db-tools PATCH 1/1] import: Introduce "--latest" option
--latest option checks whether there's a new osinfo-db available from
the official libosinfo's release website, downloads and install it.
The download and installation is only then when the version available in
libosinfo's release website is newer than the version installed in the
(specified location in) system.
Signed-off-by: Fabiano Fidêncio
---
tools/osinfo-db-import.c | 155 +++
1 file changed, 155 insertions(+)
diff --git a/tools/osinfo-db-import.c b/tools/osinfo-db-import.c
index c0b4931..79a0031 100644
--- a/tools/osinfo-db-import.c
+++ b/tools/osinfo-db-import.c
@@ -31,6 +31,9 @@
#include "osinfo-db-util.h"
+#define LATEST_URI "https://fidencio.fedorapeople.org/osinfo-db-latest.txt;
+#define VERSION_FILE "VERSION"
+
const char *argv0;
static int osinfo_db_import_create_reg(GFile *file,
@@ -184,6 +187,127 @@ osinfo_db_import_download_file(const gchar *url,
return ret;
}
+static gboolean osinfo_db_get_installed_version(GFile *dir,
+gchar **version)
+{
+GFile *file = NULL;
+GFileInfo *info = NULL;
+GFileInputStream *stream = NULL;
+goffset count;
+GError *err = NULL;
+gboolean ret = FALSE;
+
+file = g_file_get_child(dir, VERSION_FILE);
+if (file == NULL)
+return FALSE;
+
+info = g_file_query_info(file, "standard", G_FILE_QUERY_INFO_NONE, NULL,
);
+if (err != NULL) {
+/* In the case the file was not found, it just means that there's no
+ * osinfo-db installed in the specified, directory. Let's just return
+ * TRUE and proceed normally from here. */
+if (err->code == G_IO_ERROR_NOT_FOUND) {
+ret = TRUE;
+goto cleanup;
+}
+g_printerr("Failed to query info for the "VERSION_FILE" file: %s\n",
+ err->message);
+goto cleanup;
+}
+
+stream = g_file_read(file, NULL, );
+if (err != NULL) {
+g_printerr("Failed to read the "VERSION_FILE" file: %s\n",
+ err->message);
+goto cleanup;
+}
+
+count = g_file_info_get_size(info);
+*version = g_malloc0(count*sizeof(gchar));
+if (*version == NULL)
+goto cleanup;
+
+if (!g_input_stream_read_all(G_INPUT_STREAM(stream),
+ (void *)*version,
+ count,
+ NULL,
+ NULL,
+ )) {
+g_printerr("Failed get the "VERSION_FILE" file content: %s\n",
+ err->message);
+goto cleanup;
+}
+
+ret = TRUE;
+
+ cleanup:
+g_object_unref(file);
+if (info != NULL)
+g_object_unref(info);
+if (stream != NULL)
+g_object_unref(stream);
+if (err != NULL)
+g_error_free(err);
+if (!ret)
+g_free(*version);
+
+return ret;
+}
+
+static gboolean osinfo_db_get_latest_info(gchar **version,
+ gchar **url)
+{
+GFile *uri = NULL;
+gchar **set = NULL;
+gchar *content = NULL;
+GError *err = NULL;
+gboolean ret = FALSE;
+
+uri = g_file_new_for_uri(LATEST_URI);
+if (uri == NULL)
+return FALSE;
+
+if (!g_file_load_contents(uri, NULL, , NULL, NULL, )) {
+g_printerr("Could not load the content of "LATEST_URI": %s\n",
+ err->message);
+goto cleanup;
+}
+
+/* As the osinfo-db-latest.txt file has the following format:
+ * ```
+ * 20180920
+ * https://releases.pagure.org/libosinfo/osinfo-db-20180920.tar.xz
+ * ```
+ *
+ * We can safely split the content by "\n" that the first element
+ * of the resulting array will be the version and the second will
+ * be the url. */
+set = g_strsplit(content, "\n", 0);
+if (set == NULL)
+goto cleanup;
+
+*version = g_strdup(set[0]);
+if (*version == NULL)
+goto cleanup;
+
+*url = g_strdup(set[1]);
+if (*url == NULL)
+goto cleanup;
+
+ret = TRUE;
+
+ cleanup:
+g_object_unref(uri);
+if (set != NULL)
+g_strfreev(set);
+if (ret != TRUE) {
+g_free(*version);
+g_free(*url);
+}
+
+return ret;
+}
+
static int osinfo_db_import_extract(GFile *target,
const char *source,
gboolean verbose)
@@ -280,6 +404,8 @@ gint main(gint argc, gchar **argv)
gboolean user = FALSE;
gboolean local = FALSE;
gboolean system = FALSE;
+gboolean latest = FALSE;
+gchar *latest_url = NULL;
const gchar *root = "";
const gchar *archive = NULL;
const gchar *custom = NULL;
@@ -298,6 +424,8 @@ gint main(gint argc, gchar **argv)
N_("Import into custom directory"), NULL, },
{ "root", 0, 0, G_OPTION_ARG_STRING, ,
N_("Installation root directory"), NULL, },
+ { "latest", 0, 0,
Re: [Libosinfo] [osinfo-db-tools PATCH] authors, maintainers: Add all gitlab's group members
On 10/08/2018 09:41 AM, Fabiano Fidêncio wrote: Let's update the list of authors/maintainers accordingly to the libosinfo's gitlab group members[0]. The list has been put in alphabetical order on purpose. [0]: https://gitlab.com/groups/libosinfo/-/group_members Signed-off-by: Fabiano Fidêncio --- AUTHORS.in | 8 +++- MAINTAINERS | 6 ++ 2 files changed, 13 insertions(+), 1 deletion(-) Reviewed-by: Cole Robinson - Cole ___ Libosinfo mailing list Libosinfo@redhat.com https://www.redhat.com/mailman/listinfo/libosinfo
Re: [Libosinfo] [libosinfo PATCH] authors, maintainers: Add all gitlab's group members
On 10/08/2018 09:42 AM, Fabiano Fidêncio wrote: Let's update the list of authors/maintainers accordingly to the libosinfo's gitlab group members[0]. The list has been put in alphabetical order on purpose. [0]: https://gitlab.com/groups/libosinfo/-/group_members Signed-off-by: Fabiano Fidêncio --- AUTHORS.in | 8 +++- MAINTAINERS | 6 ++ 2 files changed, 13 insertions(+), 1 deletion(-) Reviewed-by: Cole Robinson - Cole ___ Libosinfo mailing list Libosinfo@redhat.com https://www.redhat.com/mailman/listinfo/libosinfo
Re: [Libosinfo] [osinfo-db, libosinfo PATCH 0/5] Add Fedora29 / Silverblue 29 (Beta) info
On Tue, Oct 09, 2018 at 06:06:50AM -0400, Jeremy Bicha wrote: > On Tue, Oct 9, 2018 at 5:34 AM Fabiano Fidêncio wrote: > > My rationale for this is that in a few weeks the official ISOs will be > > released and we'd just remove the prerelease tag and add the release date. > > This is somewhat similar to what I did with Ubuntu 18.10 recently. The > URLs point to the daily iso build which is really the recommended way > to get Ubuntu's development release. Before my change, the pre-release > Ubuntu iso's weren't recognized at all so you don't get any of the > pre-configured RAM and disk sizes in Boxes. It's also a problem if > developers always run the development release and so don't see how the > behavior is different with recognized stable release iso's. > > It's a bit different for Fedora because I believe Fedora does have > generic recognition for these pre-release ISOs in osinfo-db. Yep, for fedora/opensuse, there are 'catch-all' fedora-unknown/opensuse-unknown OSes. > > Anyway, I would support the Fedora proposal here. Yes, thanks for pointing out the ubuntu situation, it would indeed be odd to accept the patches for ubuntu and not the similar ones for fedora. Christophe signature.asc Description: PGP signature ___ Libosinfo mailing list Libosinfo@redhat.com https://www.redhat.com/mailman/listinfo/libosinfo
Re: [Libosinfo] [osinfo-db, libosinfo PATCH 0/5] Add Fedora29 / Silverblue 29 (Beta) info
On Tue, Oct 9, 2018 at 5:34 AM Fabiano Fidêncio wrote: > My rationale for this is that in a few weeks the official ISOs will be > released and we'd just remove the prerelease tag and add the release date. This is somewhat similar to what I did with Ubuntu 18.10 recently. The URLs point to the daily iso build which is really the recommended way to get Ubuntu's development release. Before my change, the pre-release Ubuntu iso's weren't recognized at all so you don't get any of the pre-configured RAM and disk sizes in Boxes. It's also a problem if developers always run the development release and so don't see how the behavior is different with recognized stable release iso's. It's a bit different for Fedora because I believe Fedora does have generic recognition for these pre-release ISOs in osinfo-db. Anyway, I would support the Fedora proposal here. Thanks, Jeremy Bicha ___ Libosinfo mailing list Libosinfo@redhat.com https://www.redhat.com/mailman/listinfo/libosinfo
Re: [Libosinfo] [Patch] bump default ubuntu RAM size
On Mon, Oct 08, 2018 at 04:25:21PM +0200, Didier Roche wrote: > Le 08/10/2018 à 13:21, Fabiano Fidêncio a écrit : > > On Mon, 2018-10-08 at 13:12 +0200, Didier Roche wrote: > > > > > > Yes, we can be more fine-grained, basically: > > > * 16.04 -> Min and recommended is 2Gb (this was bumped when our > > > 16.04.x > > > maintenance image started to include snapd) > > > * 18.04 and onward: 2Gb min, 4Gb recommended. > > > However, if we bump recommended in that file to 4Gb, GNOME Boxes > > > will > > > set that as a default, which we aren't really keen on (the 4Gb > > > recommended is a large estimate for people using a lot of tabs in > > > their > > > browser, which isn't our GNOME Boxes typical usage we are targeting > > > at). > > > > > > Does it makes sense? > > > > On one hand it does, on the other hand ... I'd still prefer to have the > > recommended amount of RAM properly set in osinfo-db. > > > > AFAIR, in Boxes the user can change the amount of RAM to the minimum > > one if their decide to do so. > > > > Also, the recommended disk size has been increased, right? Would be > > nice to have it changed as well. > > > > It's a bit tricky because the configuration is shared between Ubuntu desktop > & server. Ah, it probably would make sense to be able to override these depending on the type of image that we are dealing with. Maybe adding a 'variant' attribute to the tag would do the trick. > > We discussed that at length within the desktop team, and it seems the > conscensus is to separate the physical install recommendations vs > virtualised one. Will Cooke (manager of the desktop team) has just updated > the wiki page: > https://help.ubuntu.com/community/Installation/SystemRequirements?action=diff=110=109. > I hope that facilitate that patch which is increasing a non working > configuration. To me it's really unexpected that requirements for a 2.5 years old image change like that :) But that's your project decision, libosinfo can just follow suit... Acked-by: Christophe Fergeau signature.asc Description: PGP signature ___ Libosinfo mailing list Libosinfo@redhat.com https://www.redhat.com/mailman/listinfo/libosinfo
Re: [Libosinfo] [osinfo-db, libosinfo PATCH 0/5] Add Fedora29 / Silverblue 29 (Beta) info
On Tue, Oct 09, 2018 at 11:34:29AM +0200, Fabiano Fidêncio wrote: > On Tuesday, October 9, 2018, Christophe Fergeau wrote: > > > Hey > > Series looks good to me, though I'm still not fully convinced we want to > > add 'transient' ISOs like these. > > > Okay, I will wait for a second opinion then before pushing the patches. > > My rationale for this is that in a few weeks the official ISOs will be > released and we'd just remove the prerelease tag and add the release date. and update the URLs and update the test data. No strong opposition btw, and I agree it's nice if at release time f29 info is already there (which will work in that case because the volume id does not mention 'beta'). Christophe > > > > > > Reviewed-by: Christophe Fergeau > > > > On Mon, Oct 08, 2018 at 05:15:55PM +0200, Fabiano Fidêncio wrote: > > > This patch series add support for Fedora29/Silverblue29 (Beta). > > > > > > osinfo-db: > > > Fabiano Fidêncio (2): > > > fedora: Add fedora29 (Beta) info > > > silverblue: Add silverblue29 (Beta) data > > > fedora: Adjust unkown regex > > > > > > data/os/fedoraproject.org/fedora-29.xml.in| 124 ++ > > > .../os/fedoraproject.org/silverblue-29.xml.in | 44 +++ > > > data/os/fedoraproject.org/fedora-unknown.xml.in | 8 > > > 3 files changed, 172 insertions(+), 4 deletions(-) > > > create mode 100644 data/os/fedoraproject.org/fedora-29.xml.in > > > create mode 100644 data/os/fedoraproject.org/silverblue-29.xml.in > > > > > > > > > libosinfo: > > > Fabiano Fidêncio (2): > > > fedora: Add fedora29 (Beta) isodata > > > silverblue: Add silverblue29 (Beta) isodata > > > > > > ...dora-Server-dvd-x86_64-29_Beta-1.5.iso.txt | 29 +++ > > > ...-Server-netinst-x86_64-29_Beta-1.5.iso.txt | 29 +++ > > > ...orkstation-Live-x86_64-29_Beta-1.5.iso.txt | 29 +++ > > > ...station-netinst-x86_64-29_Beta-1.5.iso.txt | 29 +++ > > > ...lverblue-ostree-x86_64-29_Beta-1.5.iso.txt | 29 +++ > > > 5 files changed, 145 insertions(+) > > > create mode 100644 tests/isodata/fedora/fedora29/ > > Fedora-Server-dvd-x86_64-29_Beta-1.5.iso.txt > > > create mode 100644 tests/isodata/fedora/fedora29/ > > Fedora-Server-netinst-x86_64-29_Beta-1.5.iso.txt > > > create mode 100644 tests/isodata/fedora/fedora29/ > > Fedora-Workstation-Live-x86_64-29_Beta-1.5.iso.txt > > > create mode 100644 tests/isodata/fedora/fedora29/ > > Fedora-Workstation-netinst-x86_64-29_Beta-1.5.iso.txt > > > create mode 100644 tests/isodata/fedora/silverblue29/Fedora- > > Silverblue-ostree-x86_64-29_Beta-1.5.iso.txt > > > > > > -- > > > 2.19.1 > > > > > > ___ > > > Libosinfo mailing list > > > Libosinfo@redhat.com > > > https://www.redhat.com/mailman/listinfo/libosinfo > > > ___ > Libosinfo mailing list > Libosinfo@redhat.com > https://www.redhat.com/mailman/listinfo/libosinfo signature.asc Description: PGP signature ___ Libosinfo mailing list Libosinfo@redhat.com https://www.redhat.com/mailman/listinfo/libosinfo
Re: [Libosinfo] [osinfo-db, libosinfo PATCH 0/5] Add Fedora29 / Silverblue 29 (Beta) info
On Tuesday, October 9, 2018, Christophe Fergeau wrote: > Hey > Series looks good to me, though I'm still not fully convinced we want to > add 'transient' ISOs like these. Okay, I will wait for a second opinion then before pushing the patches. My rationale for this is that in a few weeks the official ISOs will be released and we'd just remove the prerelease tag and add the release date. > > Reviewed-by: Christophe Fergeau > > On Mon, Oct 08, 2018 at 05:15:55PM +0200, Fabiano Fidêncio wrote: > > This patch series add support for Fedora29/Silverblue29 (Beta). > > > > osinfo-db: > > Fabiano Fidêncio (2): > > fedora: Add fedora29 (Beta) info > > silverblue: Add silverblue29 (Beta) data > > fedora: Adjust unkown regex > > > > data/os/fedoraproject.org/fedora-29.xml.in| 124 ++ > > .../os/fedoraproject.org/silverblue-29.xml.in | 44 +++ > > data/os/fedoraproject.org/fedora-unknown.xml.in | 8 > > 3 files changed, 172 insertions(+), 4 deletions(-) > > create mode 100644 data/os/fedoraproject.org/fedora-29.xml.in > > create mode 100644 data/os/fedoraproject.org/silverblue-29.xml.in > > > > > > libosinfo: > > Fabiano Fidêncio (2): > > fedora: Add fedora29 (Beta) isodata > > silverblue: Add silverblue29 (Beta) isodata > > > > ...dora-Server-dvd-x86_64-29_Beta-1.5.iso.txt | 29 +++ > > ...-Server-netinst-x86_64-29_Beta-1.5.iso.txt | 29 +++ > > ...orkstation-Live-x86_64-29_Beta-1.5.iso.txt | 29 +++ > > ...station-netinst-x86_64-29_Beta-1.5.iso.txt | 29 +++ > > ...lverblue-ostree-x86_64-29_Beta-1.5.iso.txt | 29 +++ > > 5 files changed, 145 insertions(+) > > create mode 100644 tests/isodata/fedora/fedora29/ > Fedora-Server-dvd-x86_64-29_Beta-1.5.iso.txt > > create mode 100644 tests/isodata/fedora/fedora29/ > Fedora-Server-netinst-x86_64-29_Beta-1.5.iso.txt > > create mode 100644 tests/isodata/fedora/fedora29/ > Fedora-Workstation-Live-x86_64-29_Beta-1.5.iso.txt > > create mode 100644 tests/isodata/fedora/fedora29/ > Fedora-Workstation-netinst-x86_64-29_Beta-1.5.iso.txt > > create mode 100644 tests/isodata/fedora/silverblue29/Fedora- > Silverblue-ostree-x86_64-29_Beta-1.5.iso.txt > > > > -- > > 2.19.1 > > > > ___ > > Libosinfo mailing list > > Libosinfo@redhat.com > > https://www.redhat.com/mailman/listinfo/libosinfo > ___ Libosinfo mailing list Libosinfo@redhat.com https://www.redhat.com/mailman/listinfo/libosinfo
Re: [Libosinfo] [osinfo-db, libosinfo PATCH 0/5] Add Fedora29 / Silverblue 29 (Beta) info
Hey Series looks good to me, though I'm still not fully convinced we want to add 'transient' ISOs like these. Reviewed-by: Christophe Fergeau On Mon, Oct 08, 2018 at 05:15:55PM +0200, Fabiano Fidêncio wrote: > This patch series add support for Fedora29/Silverblue29 (Beta). > > osinfo-db: > Fabiano Fidêncio (2): > fedora: Add fedora29 (Beta) info > silverblue: Add silverblue29 (Beta) data > fedora: Adjust unkown regex > > data/os/fedoraproject.org/fedora-29.xml.in| 124 ++ > .../os/fedoraproject.org/silverblue-29.xml.in | 44 +++ > data/os/fedoraproject.org/fedora-unknown.xml.in | 8 > 3 files changed, 172 insertions(+), 4 deletions(-) > create mode 100644 data/os/fedoraproject.org/fedora-29.xml.in > create mode 100644 data/os/fedoraproject.org/silverblue-29.xml.in > > > libosinfo: > Fabiano Fidêncio (2): > fedora: Add fedora29 (Beta) isodata > silverblue: Add silverblue29 (Beta) isodata > > ...dora-Server-dvd-x86_64-29_Beta-1.5.iso.txt | 29 +++ > ...-Server-netinst-x86_64-29_Beta-1.5.iso.txt | 29 +++ > ...orkstation-Live-x86_64-29_Beta-1.5.iso.txt | 29 +++ > ...station-netinst-x86_64-29_Beta-1.5.iso.txt | 29 +++ > ...lverblue-ostree-x86_64-29_Beta-1.5.iso.txt | 29 +++ > 5 files changed, 145 insertions(+) > create mode 100644 > tests/isodata/fedora/fedora29/Fedora-Server-dvd-x86_64-29_Beta-1.5.iso.txt > create mode 100644 > tests/isodata/fedora/fedora29/Fedora-Server-netinst-x86_64-29_Beta-1.5.iso.txt > create mode 100644 > tests/isodata/fedora/fedora29/Fedora-Workstation-Live-x86_64-29_Beta-1.5.iso.txt > create mode 100644 > tests/isodata/fedora/fedora29/Fedora-Workstation-netinst-x86_64-29_Beta-1.5.iso.txt > create mode 100644 > tests/isodata/fedora/silverblue29/Fedora-Silverblue-ostree-x86_64-29_Beta-1.5.iso.txt > > -- > 2.19.1 > > ___ > Libosinfo mailing list > Libosinfo@redhat.com > https://www.redhat.com/mailman/listinfo/libosinfo signature.asc Description: PGP signature ___ Libosinfo mailing list Libosinfo@redhat.com https://www.redhat.com/mailman/listinfo/libosinfo
Re: [Libosinfo] [Patch] bump default ubuntu RAM size
Le 08/10/2018 à 16:25, Didier Roche a écrit : Le 08/10/2018 à 13:21, Fabiano Fidêncio a écrit : On Mon, 2018-10-08 at 13:12 +0200, Didier Roche wrote: Yes, we can be more fine-grained, basically: * 16.04 -> Min and recommended is 2Gb (this was bumped when our 16.04.x maintenance image started to include snapd) * 18.04 and onward: 2Gb min, 4Gb recommended. However, if we bump recommended in that file to 4Gb, GNOME Boxes will set that as a default, which we aren't really keen on (the 4Gb recommended is a large estimate for people using a lot of tabs in their browser, which isn't our GNOME Boxes typical usage we are targeting at). Does it makes sense? On one hand it does, on the other hand ... I'd still prefer to have the recommended amount of RAM properly set in osinfo-db. AFAIR, in Boxes the user can change the amount of RAM to the minimum one if their decide to do so. Also, the recommended disk size has been increased, right? Would be nice to have it changed as well. It's a bit tricky because the configuration is shared between Ubuntu desktop & server. We discussed that at length within the desktop team, and it seems the conscensus is to separate the physical install recommendations vs virtualised one. Will Cooke (manager of the desktop team) has just updated the wiki page: https://help.ubuntu.com/community/Installation/SystemRequirements?action=diff=110=109. I hope that facilitate that patch which is increasing a non working configuration. Keep me posted. Hey, Anything I can do to push this forward? We are in finale freeze on Thursday for our cosmic (18.10) release and it would be great if I can take an upstream snapshot, getting it into debian and syncing in ubuntu if possible (rather than distro-patching). Thanks! Didier ___ Libosinfo mailing list Libosinfo@redhat.com https://www.redhat.com/mailman/listinfo/libosinfo
