From crobinso at redhat.com Sat Jun 1 16:52:28 2019 From: crobinso at redhat.com (Cole Robinson) Date: Sat, 1 Jun 2019 12:52:28 -0400 Subject: [Libosinfo] [osinfo-db PATCH 0/3] Misc fixes for rhel-7 & 8 related to ppc64le In-Reply-To: <20190529072815.22840-1-fidencio@redhat.com> References: <20190529072815.22840-1-fidencio@redhat.com> Message-ID: <7eb435b9-64ab-6024-2a40-b251ec245cd7@redhat.com> On 5/29/19 3:28 AM, Fabiano Fid?ncio wrote: > The series cover: > - Anchoring ppc64 arch entries for treeinfo, so those do not match > ppc64le; > - Adding ppc64le resources (same as the ones for ppc64) for rhel-7; > - Adjusting rhel-8.0 resources to use ppc64le as arch, instead of using > ppc64 (as there are no ppc64 ISOs for rhel-8.0); > > Fabiano Fid?ncio (3): > rhel-7.[2-6]: Anchor ppc64 arch for treeinfo > rhel-7.[2-6]: Add ppc64le resources > rhel-8.0: Fix typo in resources' architecture name > > data/os/redhat.com/rhel-7.2.xml.in | 17 ++++++++++++++++- > data/os/redhat.com/rhel-7.3.xml.in | 17 ++++++++++++++++- > data/os/redhat.com/rhel-7.4.xml.in | 17 ++++++++++++++++- > data/os/redhat.com/rhel-7.5.xml.in | 17 ++++++++++++++++- > data/os/redhat.com/rhel-7.6.xml.in | 17 ++++++++++++++++- > data/os/redhat.com/rhel-8.0.xml.in | 2 +- > 6 files changed, 81 insertions(+), 6 deletions(-) > Reviewed-by: Cole Robinson - Cole From crobinso at redhat.com Sat Jun 1 16:59:43 2019 From: crobinso at redhat.com (Cole Robinson) Date: Sat, 1 Jun 2019 12:59:43 -0400 Subject: [Libosinfo] [osinfo-db PATCH 0/2] Fix infinite loop on libosinfo side & add tests to avoid this to happen again In-Reply-To: <20190529121535.18391-1-fidencio@redhat.com> References: <20190529121535.18391-1-fidencio@redhat.com> Message-ID: <55d1c8cf-19e1-3e20-3000-d4a859ef54e2@redhat.com> On 5/29/19 8:15 AM, Fabiano Fid?ncio wrote: > This series fixes the infinite loop caused by a typo in openbsd-6.3 > entry and also adds a test avoiding this issue to happen in the future. > > Fabiano Fid?ncio (2): > openbsd-6.3: Fix derives-from > tests: Add test_related > > data/os/openbsd.org/openbsd-6.3.xml.in | 2 +- > tests/test_related.py | 12 ++++++++++++ > tests/util.py | 5 ++++- > 3 files changed, 17 insertions(+), 2 deletions(-) > create mode 100644 tests/test_related.py > Reviewed-by: Cole Robinson Ideas for future test improvements: * Check all references in the chain, there could be circular references. Maybe just try to resolve them all and a hanging test will make it clear something is wrong, or python will throw a recursion error. * validate the referenced id is valid (which libosinfo will assert on but we could catch it earlier here) - Cole From crobinso at redhat.com Sat Jun 1 17:07:36 2019 From: crobinso at redhat.com (Cole Robinson) Date: Sat, 1 Jun 2019 13:07:36 -0400 Subject: [Libosinfo] [osinfo-db-tools PATCH] test_osinfo_db_path: Unset XDG_CONFIG_HOME envvar In-Reply-To: <20190530095519.23412-1-fidencio@redhat.com> References: <20190530095519.23412-1-fidencio@redhat.com> Message-ID: <9b8d67c1-900f-5ed3-3a7a-3d852a1a8423@redhat.com> On 5/30/19 5:55 AM, Fabiano Fid?ncio wrote: > Similarly to what's been done as part of 1df4c0dbede91, let's just unset > XDG_CONFIG_HOME environment variable in our tests, in case those were > externally set for some reason. > > https://gitlab.com/libosinfo/osinfo-db-tools/issues/3 > > Signed-off-by: Fabiano Fid?ncio > --- > tests/test_osinfo_db_path.py | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/tests/test_osinfo_db_path.py b/tests/test_osinfo_db_path.py > index d813c34..b0b6aff 100755 > --- a/tests/test_osinfo_db_path.py > +++ b/tests/test_osinfo_db_path.py > @@ -44,6 +44,8 @@ def test_osinfo_db_path_user(): > """ > if "OSINFO_USER_DIR" in os.environ: > del os.environ["OSINFO_USER_DIR"] > + if "XDG_CONFIG_HOME" in os.environ: > + del os.environ["XDG_CONFIG_HOME"] > cmd = [util.Tools.db_path, util.ToolsArgs.USER] > output = util.get_output(cmd) > expected_output = os.path.join(os.environ["HOME"], ".config", > Reviewed-by: Cole Robinson - Cole From fidencio at redhat.com Mon Jun 3 11:04:23 2019 From: fidencio at redhat.com (=?UTF-8?Q?Fabiano_Fid=C3=AAncio?=) Date: Mon, 3 Jun 2019 13:04:23 +0200 Subject: [Libosinfo] [osinfo-db PATCH] drangonflybsd: Add 5.4.3 In-Reply-To: <20190527085851.25832-1-fidencio@redhat.com> References: <20190527085851.25832-1-fidencio@redhat.com> Message-ID: On Mon, May 27, 2019 at 10:59 AM Fabiano Fid?ncio wrote: > > Signed-off-by: Fabiano Fid?ncio > --- > .../dragonflybsd-5.4.3.xml.in | 23 +++++++++++++++ > .../dfly-x86_64-5.4.3_REL.iso.txt | 29 +++++++++++++++++++ > 2 files changed, 52 insertions(+) > create mode 100644 data/os/dragonflybsd.org/dragonflybsd-5.4.3.xml.in > create mode 100644 tests/isodata/dragonflybsd/dragonflybsd5.4.3/dfly-x86_64-5.4.3_REL.iso.txt > > diff --git a/data/os/dragonflybsd.org/dragonflybsd-5.4.3.xml.in b/data/os/dragonflybsd.org/dragonflybsd-5.4.3.xml.in > new file mode 100644 > index 0000000..645a1b1 > --- /dev/null > +++ b/data/os/dragonflybsd.org/dragonflybsd-5.4.3.xml.in > @@ -0,0 +1,23 @@ > + > + > + > + dragonflybsd5.4.3 > + <_name>DragonFlyBSD 5.4.3 > + 5.4.3 > + dragonflybsd > + dragonflybsd > + <_vendor>DragonFlyBSD Project > + > + > + 2019-05-20 > + > + > + http://mirror-master.dragonflybsd.org/iso-images/dfly-x86_64-5.4.3_REL.iso > + > + DragonFly > + DragonFly v5.4.3 > + > + > + > + > diff --git a/tests/isodata/dragonflybsd/dragonflybsd5.4.3/dfly-x86_64-5.4.3_REL.iso.txt b/tests/isodata/dragonflybsd/dragonflybsd5.4.3/dfly-x86_64-5.4.3_REL.iso.txt > new file mode 100644 > index 0000000..28f9618 > --- /dev/null > +++ b/tests/isodata/dragonflybsd/dragonflybsd5.4.3/dfly-x86_64-5.4.3_REL.iso.txt > @@ -0,0 +1,29 @@ > +CD-ROM is in ISO 9660 format > +System id: DragonFly > +Volume id: DragonFly v5.4.3 > +Volume set id: > +Publisher id: > +Data preparer id: > +Application id: MKISOFS ISO9660/HFS/UDF FILESYSTEM BUILDER & CDRECORD CD/DVD/BluRay CREATOR (C) 1993 E.YOUNGDALE (C) 1997 J.PEARSON/J.SCHILLING > +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: 528504 > +El Torito VD version 1 found, boot catalog is in sector 6902 > +Joliet with UCS level 3 found > +Rock Ridge signatures version 1 found > +Eltorito validation header: > + Hid 1 > + Arch 0 (x86) > + ID '' > + Key 55 AA > + Eltorito defaultboot header: > + Bootid 88 (bootable) > + Boot media 0 (No Emulation Boot) > + Load segment 0 > + Sys type 0 > + Nsect 4 > + Bootoff 1AF7 6903 > -- > 2.21.0 > Ping? From crobinso at redhat.com Mon Jun 3 13:17:32 2019 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 3 Jun 2019 09:17:32 -0400 Subject: [Libosinfo] [osinfo-db PATCH] drangonflybsd: Add 5.4.3 In-Reply-To: References: <20190527085851.25832-1-fidencio@redhat.com> Message-ID: <56b0532f-3d34-bb9e-57fb-25976022e603@redhat.com> On 6/3/19 7:04 AM, Fabiano Fid?ncio wrote: > On Mon, May 27, 2019 at 10:59 AM Fabiano Fid?ncio wrote: >> >> Signed-off-by: Fabiano Fid?ncio >> --- >> .../dragonflybsd-5.4.3.xml.in | 23 +++++++++++++++ >> .../dfly-x86_64-5.4.3_REL.iso.txt | 29 +++++++++++++++++++ >> 2 files changed, 52 insertions(+) >> create mode 100644 data/os/dragonflybsd.org/dragonflybsd-5.4.3.xml.in >> create mode 100644 tests/isodata/dragonflybsd/dragonflybsd5.4.3/dfly-x86_64-5.4.3_REL.iso.txt >> >> diff --git a/data/os/dragonflybsd.org/dragonflybsd-5.4.3.xml.in b/data/os/dragonflybsd.org/dragonflybsd-5.4.3.xml.in >> new file mode 100644 >> index 0000000..645a1b1 >> --- /dev/null >> +++ b/data/os/dragonflybsd.org/dragonflybsd-5.4.3.xml.in >> @@ -0,0 +1,23 @@ >> + >> + >> + >> + dragonflybsd5.4.3 >> + <_name>DragonFlyBSD 5.4.3 >> + 5.4.3 >> + dragonflybsd >> + dragonflybsd >> + <_vendor>DragonFlyBSD Project >> + >> + >> + 2019-05-20 >> + >> + >> + http://mirror-master.dragonflybsd.org/iso-images/dfly-x86_64-5.4.3_REL.iso >> + >> + DragonFly >> + DragonFly v5.4.3 >> + >> + >> + >> + >> diff --git a/tests/isodata/dragonflybsd/dragonflybsd5.4.3/dfly-x86_64-5.4.3_REL.iso.txt b/tests/isodata/dragonflybsd/dragonflybsd5.4.3/dfly-x86_64-5.4.3_REL.iso.txt >> new file mode 100644 >> index 0000000..28f9618 >> --- /dev/null >> +++ b/tests/isodata/dragonflybsd/dragonflybsd5.4.3/dfly-x86_64-5.4.3_REL.iso.txt >> @@ -0,0 +1,29 @@ >> +CD-ROM is in ISO 9660 format >> +System id: DragonFly >> +Volume id: DragonFly v5.4.3 >> +Volume set id: >> +Publisher id: >> +Data preparer id: >> +Application id: MKISOFS ISO9660/HFS/UDF FILESYSTEM BUILDER & CDRECORD CD/DVD/BluRay CREATOR (C) 1993 E.YOUNGDALE (C) 1997 J.PEARSON/J.SCHILLING >> +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: 528504 >> +El Torito VD version 1 found, boot catalog is in sector 6902 >> +Joliet with UCS level 3 found >> +Rock Ridge signatures version 1 found >> +Eltorito validation header: >> + Hid 1 >> + Arch 0 (x86) >> + ID '' >> + Key 55 AA >> + Eltorito defaultboot header: >> + Bootid 88 (bootable) >> + Boot media 0 (No Emulation Boot) >> + Load segment 0 >> + Sys type 0 >> + Nsect 4 >> + Bootoff 1AF7 6903 >> -- >> 2.21.0 >> > > Ping? > Hmm I can't seem to find that in my archives, not sure what happened. But it looks fine to me: Reviewed-by: Cole Robinson - Cole From crobinso at redhat.com Mon Jun 3 22:33:02 2019 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 3 Jun 2019 18:33:02 -0400 Subject: [Libosinfo] [osinfo-db PATCH 0/4] osinfo-db: Add firmware support to In-Reply-To: <20190507130621.9525-1-fidencio@redhat.com> References: <20190507130621.9525-1-fidencio@redhat.com> Message-ID: <9ba15535-22e4-bcba-2c56-d25f4d29ed11@redhat.com> On 5/7/19 9:06 AM, Fabiano Fid?ncio wrote: > This patch set adds support to advertising the firmware types an OS > supports and follows the same naming used by libvirt. > > For now, I've decided to not yet start decorating all x86_64/i686 OSes > we have in osinfo-db with , > but it may be needed in the future. > > Also, this patch set only adds info about UEFI support for Fedora and > RHEL (well, Silverblue and CentOS will get it for free). So, it'll have > to be expanded later on. > > Fabiano Fid?ncio (4): > schema: Add firmware support to > test: Add firmware related tests > fedora: Add info about UEFI support > rhel: Add info about UEFI support > > data/os/fedoraproject.org/fedora-19.xml.in | 3 +++ > data/os/redhat.com/rhel-6.9.xml.in | 3 +++ > data/os/redhat.com/rhel-7.0.xml.in | 2 ++ > data/os/redhat.com/rhel-8.0.xml.in | 2 ++ > data/schema/osinfo.rng.in | 26 +++++++++++++++++++++ > tests/osinfo.py | 17 ++++++++++++++ > tests/test_firmwares.py | 27 ++++++++++++++++++++++ > tests/util.py | 11 ++++++++- > 8 files changed, 90 insertions(+), 1 deletion(-) > create mode 100644 tests/test_firmwares.py > What's the criteria for 'support' status here, just officially advertised in distro docs? If so, do you have links? Quick googling didn't give me much for fedora and rhel How do you envision we would advertise something like secureboot support... as its own type='efi-secureboot', an extra attribute, a sub element, etc. For that matter how does libvirt new firmware= support handle it? - Cole From fidencio at redhat.com Tue Jun 4 07:30:05 2019 From: fidencio at redhat.com (=?UTF-8?Q?Fabiano_Fid=C3=AAncio?=) Date: Tue, 4 Jun 2019 09:30:05 +0200 Subject: [Libosinfo] unattended installation support Message-ID: People, libosinfo/osinfo-db claims to support unattended installations of various OSes and all the possible versions of each OS. However, this is not tested (apart from people using it on Boxes). There are a few things that come to my mind: - Having tests for unattended installations: - First step towards this has been done with the unattended installation support being added to virt-installl. A lot more work will need to be done in order to actually have it tested in a sane way ... - Drop support for EOL systems: - We claim to support Fedora >= 3. Was this ever tested? - We support Windows >= 2k. This was tested back in 2012 ... but is this something we really should keep? My suggestion (and I'd like to get the others maintainers bless) is to, right now, only keep support for: - Linuxes: The supported versions of the distros (so, for instance, for Fedora ... just support Fedora29 and Fedora30); - Windows: Windows 7+ By taking this path we'll have an easier time to ensure that our scripts are working and also reduce the maintainability of those. Shall I go for this change? Best Regards, -- Fabiano Fid?ncio From crobinso at redhat.com Tue Jun 4 14:38:14 2019 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 4 Jun 2019 10:38:14 -0400 Subject: [Libosinfo] unattended installation support In-Reply-To: References: Message-ID: <1ef93e77-a8fc-bddf-f549-17969cd3074c@redhat.com> On 6/4/19 3:30 AM, Fabiano Fid?ncio wrote: > People, > > libosinfo/osinfo-db claims to support unattended installations of > various OSes and all the possible versions of each OS. However, this > is not tested (apart from people using it on Boxes). > > There are a few things that come to my mind: > - Having tests for unattended installations: > - First step towards this has been done with the unattended > installation support being added to virt-installl. A lot more work > will need to be done in order to actually have it tested in a sane way > ... Yeah. There's definitely opportunity for some unit style tests in virt-install, but this stuff will need a functional test suite in some form, and some of it non-public for the windows stuff at least. > - Drop support for EOL systems: > - We claim to support Fedora >= 3. Was this ever tested? > - We support Windows >= 2k. This was tested back in 2012 ... but is > this something we really should keep? > > My suggestion (and I'd like to get the others maintainers bless) is > to, right now, only keep support for: > - Linuxes: The supported versions of the distros (so, for instance, > for Fedora ... just support Fedora29 and Fedora30); > - Windows: Windows 7+ > Dropping win2003 and earlier will simplify app implementations because they can (probably) avoid the floppy requirement, like we discussed on IRC. So I think that helps quite a bit. There's still definitely people using winxp (despite being out of support microsoft just pushed a patch update last week) but I don't think we need to support unattended installs there anymore. My opinion is mixed on killing off unattended support for EOL distros. Doing a one time purge now is one thing, but going forward is the more interesting bit. It would mean that working virt-install command line invocations may break in the future which I never like. But I don't want osinfo to be restricted by maintaining unattended compat with a ton of old distros... Maybe we can have an informal tier system based on what we test. So when making unattended changes to git, we only functional test the non-EOL distros. When a distro goes EOL we can fork off the install script to fossilize it, so changes we make for Fedora 30 don't alter the config for EOL Fedora 28. Presumably if we do a one time test of say Fedora14 installing correctly, then we fork the unattended install script, we can have reasonable confidence that it will continue to work into the future unless things change on the Fedora side. But we only do full install testing with latest supported Fedora. But if for example fedora14 is already broken then I'd say just drop it - Cole > By taking this path we'll have an easier time to ensure that our > scripts are working and also reduce the maintainability of those. > > Shall I go for this change? > > Best Regards, > - Cole From fidencio at redhat.com Wed Jun 5 07:44:56 2019 From: fidencio at redhat.com (=?UTF-8?q?Fabiano=20Fid=C3=AAncio?=) Date: Wed, 5 Jun 2019 09:44:56 +0200 Subject: [Libosinfo] [osinfo-db PATCH] install-script, windows: cdrom is also a viable injection method Message-ID: <20190605074456.14217-1-fidencio@redhat.com> For scripts being used on Windows Vista+ the unattended installer can also be used via cdrom and not only via a floppy device. Signed-off-by: Fabiano Fid?ncio --- It's important to mention that this change is not going to break current consumers of those scripts. There are more changes to come when actively using the unattended script, together with pre/post installation of drivers ... but, right now, this patch is good enough for dropping mtools dependency on virt-manager together with floppy injection there (as virt-install still doesn't pre/post install drivers). --- data/install-script/microsoft.com/windows-cmd-desktop.xml.in | 1 + .../install-script/microsoft.com/windows-unattend-desktop.xml.in | 1 + data/install-script/microsoft.com/windows-unattend-jeos.xml.in | 1 + 3 files changed, 3 insertions(+) diff --git a/data/install-script/microsoft.com/windows-cmd-desktop.xml.in b/data/install-script/microsoft.com/windows-cmd-desktop.xml.in index 7fee340..1be991e 100644 --- a/data/install-script/microsoft.com/windows-cmd-desktop.xml.in +++ b/data/install-script/microsoft.com/windows-cmd-desktop.xml.in @@ -18,6 +18,7 @@ + cdrom floppy image/bmp diff --git a/data/install-script/microsoft.com/windows-unattend-desktop.xml.in b/data/install-script/microsoft.com/windows-unattend-desktop.xml.in index b399bd0..7baebe8 100644 --- a/data/install-script/microsoft.com/windows-unattend-desktop.xml.in +++ b/data/install-script/microsoft.com/windows-unattend-desktop.xml.in @@ -21,6 +21,7 @@ + cdrom floppy