From fidencio at redhat.com Mon Oct 1 06:56:20 2018 From: fidencio at redhat.com (Fabiano =?ISO-8859-1?Q?Fid=EAncio?=) Date: Mon, 01 Oct 2018 08:56:20 +0200 Subject: [Libosinfo] [PATCH osinfo-db 00/10] usb3 and misc device tweaks In-Reply-To: References: Message-ID: On Fri, 2018-09-28 at 14:25 -0400, Cole Robinson wrote: > This series is a collection of device annotation cleanups, > improvements, and additions. > > 1-4 are cleanups > 5-7 add more annotations for existing devices > 8-10 add usb3 device annotations > > Thanks, > Cole Reviewed-by: Fabiano Fid?ncio And I'm also pushing this series. Cole, checking those devices manually seems to be a not so nice work to do and also quite error prone (in the way that we may just add more duplications at any time). I do believe that having a test for this would be the ideal situation. What do you think? In case you don't have time to work on this, would you mind filling a bug some we can at least keep track of this? Best Regards, From mkletzan at redhat.com Mon Oct 1 12:59:27 2018 From: mkletzan at redhat.com (Martin Kletzander) Date: Mon, 1 Oct 2018 14:59:27 +0200 Subject: [Libosinfo] [PATCH] gitignore: Ignore more tags Message-ID: For people using, for example gtags, this helps make the wordkir clean. Signed-off-by: Martin Kletzander --- .gitignore | 3 +++ 1 file changed, 3 insertions(+) diff --git a/.gitignore b/.gitignore index 7e33c50f233a..d6ec8ac13525 100644 --- a/.gitignore +++ b/.gitignore @@ -1,5 +1,8 @@ ChangeLog AUTHORS +GPATH +GRTAGS +GTAGS *.[ao] *.l[ao] *~ -- 2.19.0 From fidencio at redhat.com Mon Oct 1 13:24:26 2018 From: fidencio at redhat.com (Fabiano =?ISO-8859-1?Q?Fid=EAncio?=) Date: Mon, 01 Oct 2018 15:24:26 +0200 Subject: [Libosinfo] [PATCH] gitignore: Ignore more tags In-Reply-To: References: Message-ID: <1a42e71563f849de4efb6abe1bbd9131211d5e8c.camel@redhat.com> On Mon, 2018-10-01 at 14:59 +0200, Martin Kletzander wrote: > For people using, for example gtags, this helps make the wordkir > clean. It makes sense and those are already part of gitignore in a few other projects (as libvirt). > > Signed-off-by: Martin Kletzander Reviewed-by: Fabiano Fid?ncio I'll push the patch later Today. From crobinso at redhat.com Mon Oct 1 13:28:46 2018 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 1 Oct 2018 09:28:46 -0400 Subject: [Libosinfo] [PATCH] gitignore: Ignore more tags In-Reply-To: References: Message-ID: On 10/01/2018 08:59 AM, Martin Kletzander wrote: > For people using, for example gtags, this helps make the wordkir clean. > > Signed-off-by: Martin Kletzander > --- > .gitignore | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/.gitignore b/.gitignore > index 7e33c50f233a..d6ec8ac13525 100644 > --- a/.gitignore > +++ b/.gitignore > @@ -1,5 +1,8 @@ > ChangeLog > AUTHORS > +GPATH > +GRTAGS > +GTAGS > *.[ao] > *.l[ao] > *~ > IMO these types of things belong in a personal global gitignore. For example in ~/.gitconfig I have [core] excludesfile = ~/bin/config/gitignore Which ignores things like ctags, cscope, and pycscope output that I use occasionally Thanks, Cole From crobinso at redhat.com Mon Oct 1 14:05:33 2018 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 1 Oct 2018 10:05:33 -0400 Subject: [Libosinfo] [PATCH osinfo-db 00/10] usb3 and misc device tweaks In-Reply-To: References: Message-ID: <64fc46e5-5353-ed75-3577-1431d77f6bf5@redhat.com> On 10/01/2018 02:56 AM, Fabiano Fid?ncio wrote: > On Fri, 2018-09-28 at 14:25 -0400, Cole Robinson wrote: >> This series is a collection of device annotation cleanups, >> improvements, and additions. >> >> 1-4 are cleanups >> 5-7 add more annotations for existing devices >> 8-10 add usb3 device annotations >> >> Thanks, >> Cole > > Reviewed-by: Fabiano Fid?ncio > > And I'm also pushing this series. > Thanks! > Cole, checking those devices manually seems to be a not so nice work to > do and also quite error prone (in the way that we may just add more > duplications at any time). I do believe that having a test for this > would be the ideal situation. What do you think? In case you don't have > time to work on this, would you mind filling a bug some we can at least > keep track of this? > Yeah tracking this is hard right now. I wrote a script to do a text dump of an os, its devices and resources. Attached below. I was thinking of adding something like 'osinfo-query dump ' to do the same thing. Adding a test to catch duplicates is definitely a good idea. I will file a bug, but where? I realized last week we have bugzilla.redhat.com product=Virtualization Tools component=libosinfo, but there's also the issue tracker in gitlab that has some reports as well. I don't have any strong preference for either: bugzilla is more a part of my workflow but its less discoverable and more overhead for new contributors. I think we should pick one though and disable the other Thanks, Cole -------------- next part -------------- A non-text attachment was scrubbed... Name: osinfo-print-all.py Type: text/x-python Size: 2207 bytes Desc: not available URL: From fidencio at redhat.com Mon Oct 1 14:16:26 2018 From: fidencio at redhat.com (Fabiano =?ISO-8859-1?Q?Fid=EAncio?=) Date: Mon, 01 Oct 2018 16:16:26 +0200 Subject: [Libosinfo] [PATCH osinfo-db 00/10] usb3 and misc device tweaks In-Reply-To: <64fc46e5-5353-ed75-3577-1431d77f6bf5@redhat.com> References: <64fc46e5-5353-ed75-3577-1431d77f6bf5@redhat.com> Message-ID: On Mon, 2018-10-01 at 10:05 -0400, Cole Robinson wrote: > On 10/01/2018 02:56 AM, Fabiano Fid?ncio wrote: > > On Fri, 2018-09-28 at 14:25 -0400, Cole Robinson wrote: > > > This series is a collection of device annotation cleanups, > > > improvements, and additions. > > > > > > 1-4 are cleanups > > > 5-7 add more annotations for existing devices > > > 8-10 add usb3 device annotations > > > > > > Thanks, > > > Cole > > > > Reviewed-by: Fabiano Fid?ncio > > > > And I'm also pushing this series. > > > > Thanks! > > > Cole, checking those devices manually seems to be a not so nice > > work to > > do and also quite error prone (in the way that we may just add more > > duplications at any time). I do believe that having a test for this > > would be the ideal situation. What do you think? In case you don't > > have > > time to work on this, would you mind filling a bug some we can at > > least > > keep track of this? > > > > Yeah tracking this is hard right now. I wrote a script to do a text > dump > of an os, its devices and resources. Attached below. I was thinking > of > adding something like 'osinfo-query dump ' to do the same > thing. > > Adding a test to catch duplicates is definitely a good idea. I will > file > a bug, but where? I realized last week we have bugzilla.redhat.com > product=Virtualization Tools component=libosinfo, but there's also > the > issue tracker in gitlab that has some reports as well. It's not so easy to keep track right now. New contributors would, for sure, prefer to have the issues in gitlab (and some already complained that we don't accept Merge-Requests there as well). I, personally, think that we should stick to the bugzilla.redhat.com product=Virtualization Tools component=libosinfo/osinfo-db/osinfo-db- tools. Anyways, if you could, please, create a bug in bugzilla.redhat.com then! > > I don't have any strong preference for either: bugzilla is more a > part > of my workflow but its less discoverable and more overhead for new > contributors. I think we should pick one though and disable the other I'm not totally sure it generates more overhead, to be honest. If the new contributor doesn't have a gitlab account, they'd have to create one ... so, more or less the same thing as using Red Hat's bugzilla. I totally agree with your statement about picking one and disabling the others in order to help us to properly maintain one place only. It's also a question for the others (teuf? danpb?) to answer. > > Thanks, > Cole From mkletzan at redhat.com Mon Oct 1 14:16:35 2018 From: mkletzan at redhat.com (Martin Kletzander) Date: Mon, 1 Oct 2018 16:16:35 +0200 Subject: [Libosinfo] [PATCH] gitignore: Ignore more tags In-Reply-To: References: Message-ID: <20181001141635.GA30791@wheatley> On Mon, Oct 01, 2018 at 09:28:46AM -0400, Cole Robinson wrote: >On 10/01/2018 08:59 AM, Martin Kletzander wrote: >> For people using, for example gtags, this helps make the wordkir clean. >> >> Signed-off-by: Martin Kletzander >> --- >> .gitignore | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/.gitignore b/.gitignore >> index 7e33c50f233a..d6ec8ac13525 100644 >> --- a/.gitignore >> +++ b/.gitignore >> @@ -1,5 +1,8 @@ >> ChangeLog >> AUTHORS >> +GPATH >> +GRTAGS >> +GTAGS >> *.[ao] >> *.l[ao] >> *~ >> > >IMO these types of things belong in a personal global gitignore. For >example in ~/.gitconfig I have > >[core] > excludesfile = ~/bin/config/gitignore > >Which ignores things like ctags, cscope, and pycscope output that I use >occasionally > Oh, that's cool. Thanks for the tip. It actually uses ~/.config/git/ignore by default (rough approximation of git-config(1)). Feel free to drop this patch then. Have a nice day, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Digital signature URL: From crobinso at redhat.com Mon Oct 1 16:45:21 2018 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 1 Oct 2018 12:45:21 -0400 Subject: [Libosinfo] [PATCH osinfo-db 00/10] usb3 and misc device tweaks In-Reply-To: References: <64fc46e5-5353-ed75-3577-1431d77f6bf5@redhat.com> Message-ID: <8be850b4-1531-0197-ee84-7c56c4612cf4@redhat.com> On 10/01/2018 10:16 AM, Fabiano Fid?ncio wrote: > On Mon, 2018-10-01 at 10:05 -0400, Cole Robinson wrote: >> On 10/01/2018 02:56 AM, Fabiano Fid?ncio wrote: >>> On Fri, 2018-09-28 at 14:25 -0400, Cole Robinson wrote: >>>> This series is a collection of device annotation cleanups, >>>> improvements, and additions. >>>> >>>> 1-4 are cleanups >>>> 5-7 add more annotations for existing devices >>>> 8-10 add usb3 device annotations >>>> >>>> Thanks, >>>> Cole >>> >>> Reviewed-by: Fabiano Fid?ncio >>> >>> And I'm also pushing this series. >>> >> >> Thanks! >> >>> Cole, checking those devices manually seems to be a not so nice >>> work to >>> do and also quite error prone (in the way that we may just add more >>> duplications at any time). I do believe that having a test for this >>> would be the ideal situation. What do you think? In case you don't >>> have >>> time to work on this, would you mind filling a bug some we can at >>> least >>> keep track of this? >>> >> >> Yeah tracking this is hard right now. I wrote a script to do a text >> dump >> of an os, its devices and resources. Attached below. I was thinking >> of >> adding something like 'osinfo-query dump ' to do the same >> thing. >> >> Adding a test to catch duplicates is definitely a good idea. I will >> file >> a bug, but where? I realized last week we have bugzilla.redhat.com >> product=Virtualization Tools component=libosinfo, but there's also >> the >> issue tracker in gitlab that has some reports as well. > > It's not so easy to keep track right now. > > New contributors would, for sure, prefer to have the issues in gitlab > (and some already complained that we don't accept Merge-Requests there > as well). > > I, personally, think that we should stick to the bugzilla.redhat.com > product=Virtualization Tools component=libosinfo/osinfo-db/osinfo-db- > tools. > > Anyways, if you could, please, create a bug in bugzilla.redhat.com > then! Done: https://bugzilla.redhat.com/show_bug.cgi?id=1634807 Thanks, Cole From crobinso at redhat.com Tue Oct 2 16:32:39 2018 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 2 Oct 2018 12:32:39 -0400 Subject: [Libosinfo] [PATCH osinfo-db] Add a "Contribute" page In-Reply-To: <20180913133955.23292-1-fidencio@redhat.com> References: <20180913133955.23292-1-fidencio@redhat.com> Message-ID: On 09/13/2018 09:39 AM, Fabiano Fid?ncio wrote: > Let's add some instructions and examples on how to contribute with the > most basic scenarios of adding an OS info to osinfo-db. > > -- > While do think this is useful material to point to newcomers, I'm > totally fine about having it as a blogpost or somewhere else than our > git repo. > > Also, I do believe that we can start growing the amount of docs/examples > we have and that it can help people to start helping us with some basic > patches of their favourite distro. > > I'm looking forward to receiving some feedback about this and > suggestions on how this could be done better. :-) > -- > The content is very nice! It's definitely useful to have some place to point people for these details. Generally rather than diffs in the file I'd say just point people to either email postings, or gitweb commits, if they want the particular details. I like the idea of identifying a few common tasks like adding new OS, adding isodata, adjusting EOL dates, and referencing those in the contributing doc, but storing the details elsewhere. Maybe a blog or wiki page if it has lots to explain (does gitlab have wiki pages like github?), or just a mailing list or git example link for something simpler like EOL adjusting Generally I think a contributing doc should be 1-2 pages (don't want it to scare people away) and just hits the major points like common building from git, running the test suite, and anything deeper should be links to more info. > Signed-off-by: Fabiano Fid?ncio > --- > CONTRIBUTE.md | 930 ++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 930 insertions(+) > create mode 100644 CONTRIBUTE.md > FWIW on github this type of document is typically called CONTRIBUTING.md and infact has some special meaning: https://blog.github.com/2012-09-17-contributing-guidelines/ Thanks, Cole From carnold at suse.com Wed Oct 3 19:19:51 2018 From: carnold at suse.com (Charles Arnold) Date: Wed, 3 Oct 2018 13:19:51 -0600 Subject: [Libosinfo] [PATCH osinfo-db 3/3] Add SUSE CaaS Platform 3.0 In-Reply-To: <1538594391-11586-1-git-send-email-carnold@suse.com> References: <1538594391-11586-1-git-send-email-carnold@suse.com> Message-ID: <1538594391-11586-4-git-send-email-carnold@suse.com> --- data/os/suse.com/caasp-3.0.xml.in | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) create mode 100644 data/os/suse.com/caasp-3.0.xml.in diff --git a/data/os/suse.com/caasp-3.0.xml.in b/data/os/suse.com/caasp-3.0.xml.in new file mode 100644 index 0000000..4abd0e4 --- /dev/null +++ b/data/os/suse.com/caasp-3.0.xml.in @@ -0,0 +1,38 @@ + + + + caasp3.0 + <_name>SUSE CaaS Platform 3.0 + 3.0 + <_vendor>SUSE + SUSE + linux + caasp + + + 2018-06-28 + + + + LINUX + SUSE-CaaS-Platform-3.0-DVD-x86_6 + + boot/x86_64/loader/linux + boot/x86_64/loader/initrd + + + + + 500000000 + 2147483648 + 21474836480 + + + 2400000000 + 8589934592 + 42949672960 + + + + -- 1.8.5.6 From carnold at suse.com Wed Oct 3 19:19:50 2018 From: carnold at suse.com (Charles Arnold) Date: Wed, 3 Oct 2018 13:19:50 -0600 Subject: [Libosinfo] [PATCH osinfo-db 2/3] Add SUSE CaaS Platform 2.0 In-Reply-To: <1538594391-11586-1-git-send-email-carnold@suse.com> References: <1538594391-11586-1-git-send-email-carnold@suse.com> Message-ID: <1538594391-11586-3-git-send-email-carnold@suse.com> --- data/os/suse.com/caasp-2.0.xml.in | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) create mode 100644 data/os/suse.com/caasp-2.0.xml.in diff --git a/data/os/suse.com/caasp-2.0.xml.in b/data/os/suse.com/caasp-2.0.xml.in new file mode 100644 index 0000000..409bcca --- /dev/null +++ b/data/os/suse.com/caasp-2.0.xml.in @@ -0,0 +1,38 @@ + + + + caasp2.0 + <_name>SUSE CaaS Platform 2.0 + 2.0 + <_vendor>SUSE + SUSE + linux + caasp + + + 2017-10-26 + + + + LINUX + SUSE-CaaS-Platform-2.0-DVD-x86_6 + + boot/x86_64/loader/linux + boot/x86_64/loader/initrd + + + + + 500000000 + 2147483648 + 21474836480 + + + 2400000000 + 8589934592 + 42949672960 + + + + -- 1.8.5.6 From carnold at suse.com Wed Oct 3 19:19:48 2018 From: carnold at suse.com (Charles Arnold) Date: Wed, 3 Oct 2018 13:19:48 -0600 Subject: [Libosinfo] [PATCH osinfo-db 0/3] Add SUSE Caasp Platform info Message-ID: <1538594391-11586-1-git-send-email-carnold@suse.com> There have been three releases. They are derived from SUSE Linux Enterprise 12. Charles Arnold (3): Add SUSE CaaS Platform 1.0 Add SUSE CaaS Platform 2.0 Add SUSE CaaS Platform 3.0 data/os/suse.com/caasp-1.0.xml.in | 38 ++++++++++++++++++++++++++++++++++++++ data/os/suse.com/caasp-2.0.xml.in | 38 ++++++++++++++++++++++++++++++++++++++ data/os/suse.com/caasp-3.0.xml.in | 38 ++++++++++++++++++++++++++++++++++++++ 3 files changed, 114 insertions(+) create mode 100644 data/os/suse.com/caasp-1.0.xml.in create mode 100644 data/os/suse.com/caasp-2.0.xml.in create mode 100644 data/os/suse.com/caasp-3.0.xml.in -- 1.8.5.6 From carnold at suse.com Wed Oct 3 19:19:49 2018 From: carnold at suse.com (Charles Arnold) Date: Wed, 3 Oct 2018 13:19:49 -0600 Subject: [Libosinfo] [PATCH osinfo-db 1/3] Add SUSE CaaS Platform 1.0 In-Reply-To: <1538594391-11586-1-git-send-email-carnold@suse.com> References: <1538594391-11586-1-git-send-email-carnold@suse.com> Message-ID: <1538594391-11586-2-git-send-email-carnold@suse.com> --- data/os/suse.com/caasp-1.0.xml.in | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) create mode 100644 data/os/suse.com/caasp-1.0.xml.in diff --git a/data/os/suse.com/caasp-1.0.xml.in b/data/os/suse.com/caasp-1.0.xml.in new file mode 100644 index 0000000..f23de3c --- /dev/null +++ b/data/os/suse.com/caasp-1.0.xml.in @@ -0,0 +1,38 @@ + + + + caasp1.0 + <_name>SUSE CaaS Platform 1.0 + 1.0 + <_vendor>SUSE + SUSE + linux + caasp + + + 2017-08-03 + + + + LINUX + SUSE-CaaS-Platform-1.0-DVD-x86_6 + + boot/x86_64/loader/linux + boot/x86_64/loader/initrd + + + + + 500000000 + 2147483648 + 21474836480 + + + 2400000000 + 8589934592 + 42949672960 + + + + -- 1.8.5.6 From carnold at suse.com Wed Oct 3 19:20:54 2018 From: carnold at suse.com (Charles Arnold) Date: Wed, 3 Oct 2018 13:20:54 -0600 Subject: [Libosinfo] [PATCH libosinfo 0/3] Add SUSE CaaS Platform isodata Message-ID: <1538594457-12650-1-git-send-email-carnold@suse.com> There have been three releases. Charles Arnold (3): Add SUSE CaaS Platform 1.0 isodata Add SUSE CaaS Platform 2.0 isodata Add SUSE CaaS Platform 3.0 isodata ...SE-CaaS-Platform-1.0-DVD-x86_64-GM-DVD1.iso.txt | 29 ++++++++++++++++++++++ ...SE-CaaS-Platform-2.0-DVD-x86_64-GM-DVD1.iso.txt | 29 ++++++++++++++++++++++ ...SE-CaaS-Platform-3.0-DVD-x86_64-GM-DVD1.iso.txt | 29 ++++++++++++++++++++++ 3 files changed, 87 insertions(+) create mode 100644 tests/isodata/sles/caasp10/SUSE-CaaS-Platform-1.0-DVD-x86_64-GM-DVD1.iso.txt create mode 100644 tests/isodata/sles/caasp20/SUSE-CaaS-Platform-2.0-DVD-x86_64-GM-DVD1.iso.txt create mode 100644 tests/isodata/sles/caasp30/SUSE-CaaS-Platform-3.0-DVD-x86_64-GM-DVD1.iso.txt -- 1.8.5.6 From carnold at suse.com Wed Oct 3 19:20:57 2018 From: carnold at suse.com (Charles Arnold) Date: Wed, 3 Oct 2018 13:20:57 -0600 Subject: [Libosinfo] [PATCH libosinfo 3/3] Add SUSE CaaS Platform 3.0 isodata In-Reply-To: <1538594457-12650-1-git-send-email-carnold@suse.com> References: <1538594457-12650-1-git-send-email-carnold@suse.com> Message-ID: <1538594457-12650-4-git-send-email-carnold@suse.com> --- ...SE-CaaS-Platform-3.0-DVD-x86_64-GM-DVD1.iso.txt | 29 ++++++++++++++++++++++ 1 file changed, 29 insertions(+) create mode 100644 tests/isodata/sles/caasp30/SUSE-CaaS-Platform-3.0-DVD-x86_64-GM-DVD1.iso.txt diff --git a/tests/isodata/sles/caasp30/SUSE-CaaS-Platform-3.0-DVD-x86_64-GM-DVD1.iso.txt b/tests/isodata/sles/caasp30/SUSE-CaaS-Platform-3.0-DVD-x86_64-GM-DVD1.iso.txt new file mode 100644 index 0000000..24b5700 --- /dev/null +++ b/tests/isodata/sles/caasp30/SUSE-CaaS-Platform-3.0-DVD-x86_64-GM-DVD1.iso.txt @@ -0,0 +1,29 @@ +CD-ROM is in ISO 9660 format +System id: LINUX +Volume id: SUSE-CaaS-Platform-3.0-DVD-x86_6 +Volume set id: +Publisher id: SUSE LINUX GmbH +Data preparer id: KIWI - http://opensuse.github.com/kiwi +Application id: SUSE-CaaS-Platform-3.0-DVD-x86_64-Build0101-Media1 +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: 994044 +El Torito VD version 1 found, boot catalog is in sector 20 +Joliet with UCS level 3 found +Rock Ridge signatures version 1 found +Eltorito validation header: + Hid 1 + Arch 0 (x86) + ID 'SUSE LINUX GmbH' + Key 55 AA + Eltorito defaultboot header: + Bootid 88 (bootable) + Boot media 0 (No Emulation Boot) + Load segment 0 + Sys type 0 + Nsect 4 + Bootoff 1116 4374 -- 1.8.5.6 From carnold at suse.com Wed Oct 3 19:20:56 2018 From: carnold at suse.com (Charles Arnold) Date: Wed, 3 Oct 2018 13:20:56 -0600 Subject: [Libosinfo] [PATCH libosinfo 2/3] Add SUSE CaaS Platform 2.0 isodata In-Reply-To: <1538594457-12650-1-git-send-email-carnold@suse.com> References: <1538594457-12650-1-git-send-email-carnold@suse.com> Message-ID: <1538594457-12650-3-git-send-email-carnold@suse.com> --- ...SE-CaaS-Platform-2.0-DVD-x86_64-GM-DVD1.iso.txt | 29 ++++++++++++++++++++++ 1 file changed, 29 insertions(+) create mode 100644 tests/isodata/sles/caasp20/SUSE-CaaS-Platform-2.0-DVD-x86_64-GM-DVD1.iso.txt diff --git a/tests/isodata/sles/caasp20/SUSE-CaaS-Platform-2.0-DVD-x86_64-GM-DVD1.iso.txt b/tests/isodata/sles/caasp20/SUSE-CaaS-Platform-2.0-DVD-x86_64-GM-DVD1.iso.txt new file mode 100644 index 0000000..e2cc6c1 --- /dev/null +++ b/tests/isodata/sles/caasp20/SUSE-CaaS-Platform-2.0-DVD-x86_64-GM-DVD1.iso.txt @@ -0,0 +1,29 @@ +CD-ROM is in ISO 9660 format +System id: LINUX +Volume id: SUSE-CaaS-Platform-2.0-DVD-x86_6 +Volume set id: +Publisher id: SUSE LINUX GmbH +Data preparer id: KIWI - http://opensuse.github.com/kiwi +Application id: SUSE-CaaS-Platform-2.0-DVD-x86_64-Build0115-Media1 +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: 920994 +El Torito VD version 1 found, boot catalog is in sector 20 +Joliet with UCS level 3 found +Rock Ridge signatures version 1 found +Eltorito validation header: + Hid 1 + Arch 0 (x86) + ID 'SUSE LINUX GmbH' + Key 55 AA + Eltorito defaultboot header: + Bootid 88 (bootable) + Boot media 0 (No Emulation Boot) + Load segment 0 + Sys type 0 + Nsect 4 + Bootoff 110E 4366 -- 1.8.5.6 From carnold at suse.com Wed Oct 3 19:20:55 2018 From: carnold at suse.com (Charles Arnold) Date: Wed, 3 Oct 2018 13:20:55 -0600 Subject: [Libosinfo] [PATCH libosinfo 1/3] Add SUSE CaaS Platform 1.0 isodata In-Reply-To: <1538594457-12650-1-git-send-email-carnold@suse.com> References: <1538594457-12650-1-git-send-email-carnold@suse.com> Message-ID: <1538594457-12650-2-git-send-email-carnold@suse.com> --- ...SE-CaaS-Platform-1.0-DVD-x86_64-GM-DVD1.iso.txt | 29 ++++++++++++++++++++++ 1 file changed, 29 insertions(+) create mode 100644 tests/isodata/sles/caasp10/SUSE-CaaS-Platform-1.0-DVD-x86_64-GM-DVD1.iso.txt diff --git a/tests/isodata/sles/caasp10/SUSE-CaaS-Platform-1.0-DVD-x86_64-GM-DVD1.iso.txt b/tests/isodata/sles/caasp10/SUSE-CaaS-Platform-1.0-DVD-x86_64-GM-DVD1.iso.txt new file mode 100644 index 0000000..b29d86f --- /dev/null +++ b/tests/isodata/sles/caasp10/SUSE-CaaS-Platform-1.0-DVD-x86_64-GM-DVD1.iso.txt @@ -0,0 +1,29 @@ +CD-ROM is in ISO 9660 format +System id: LINUX +Volume id: SUSE-CaaS-Platform-1.0-DVD-x86_6 +Volume set id: +Publisher id: SUSE LINUX GmbH +Data preparer id: KIWI - http://opensuse.github.com/kiwi +Application id: SUSE-CaaS-Platform-1.0-DVD-x86_64-Build0425-Media1 +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: 649036 +El Torito VD version 1 found, boot catalog is in sector 20 +Joliet with UCS level 3 found +Rock Ridge signatures version 1 found +Eltorito validation header: + Hid 1 + Arch 0 (x86) + ID 'SUSE LINUX GmbH' + Key 55 AA + Eltorito defaultboot header: + Bootid 88 (bootable) + Boot media 0 (No Emulation Boot) + Load segment 0 + Sys type 0 + Nsect 4 + Bootoff 1108 4360 -- 1.8.5.6 From fidencio at redhat.com Wed Oct 3 19:41:06 2018 From: fidencio at redhat.com (=?UTF-8?Q?Fabiano_Fid=C3=AAncio?=) Date: Wed, 3 Oct 2018 21:41:06 +0200 Subject: [Libosinfo] [PATCH osinfo-db 0/3] Add SUSE Caasp Platform info In-Reply-To: <1538594391-11586-1-git-send-email-carnold@suse.com> References: <1538594391-11586-1-git-send-email-carnold@suse.com> Message-ID: Charles, On Wed, Oct 3, 2018 at 9:20 PM Charles Arnold wrote: > > There have been three releases. They are derived from SUSE Linux Enterprise 12. I have a few general questions about those patches: - What's the end of life of each Caasp release? Does version x.0 reaches its end of life when (x+1).0 is released? If not, is 1.0 and 2.0 stil supported? - Shall we also consider that 2.0 upgrades 1.0? Depending on your answers I can do the changes before pushing without you having to submit a v2. Best Regards. -- Fabiano Fid?ncio From fidencio at redhat.com Wed Oct 3 19:45:51 2018 From: fidencio at redhat.com (=?UTF-8?Q?Fabiano_Fid=C3=AAncio?=) Date: Wed, 3 Oct 2018 21:45:51 +0200 Subject: [Libosinfo] [PATCH libosinfo 0/3] Add SUSE CaaS Platform isodata In-Reply-To: <1538594457-12650-1-git-send-email-carnold@suse.com> References: <1538594457-12650-1-git-send-email-carnold@suse.com> Message-ID: Charles. On Wed, Oct 3, 2018 at 9:21 PM Charles Arnold wrote: > > There have been three releases. > > Charles Arnold (3): > Add SUSE CaaS Platform 1.0 isodata > Add SUSE CaaS Platform 2.0 isodata > Add SUSE CaaS Platform 3.0 isodata > Those changes broke test-isodetect and it happened because the directory which contains the isodata should match the short-id of the OS. So, for instance, instead of caasp10, it should be named caasp1.0. There's no need to submit a v2, I can do the changes manually before pushing the patches (and I'll push those after your feedback on the osinfo-db series). A kind unrelated topic (but not so much) ... I've noticed that openSUSE also keeps one downstream patch for a Windows volume id. Would be possible for you to also send that upstream? That would make our life easier wrt maintaining opensuse package. And thanks for submitting those changes! Best Regards, -- Fabiano Fid?ncio From carnold at suse.com Wed Oct 3 20:07:11 2018 From: carnold at suse.com (Charles Arnold) Date: Wed, 03 Oct 2018 14:07:11 -0600 Subject: [Libosinfo] [PATCH osinfo-db 0/3] Add SUSE Caasp Platform info In-Reply-To: References: <1538594391-11586-1-git-send-email-carnold@suse.com> Message-ID: <5BB5216F0200009100139093@prv-mh.provo.novell.com> >>> On 10/3/2018 at 01:41 PM, Fabiano Fid?ncio wrote: > Charles, > > On Wed, Oct 3, 2018 at 9:20 PM Charles Arnold wrote: >> >> There have been three releases. They are derived from SUSE Linux Enterprise > 12. > > I have a few general questions about those patches: > - What's the end of life of each Caasp release? Does version x.0 > reaches its end of life when (x+1).0 is released? If not, is 1.0 and > 2.0 stil supported? The lifecycle ends when the next version ships so technically the end of 1.0 is when 2.0 shipped, 2.0 when 3.0 shipped. No specific length of time is given in advance for how long until the next version ships so it is unknown when 4.0 will ship thereby ending the 3.0 lifecycle. > - Shall we also consider that 2.0 upgrades 1.0? Yes. Both are based on SLE-12 SP2. 3.0 is based on SLE-12 SP3. They can each upgrade from the previous version with a simple update. Their lifecyle is doc'ed here, https://www.suse.com/releasenotes/x86_64/SUSE-CAASP/3.0/#Intro.Lifecycle Thank you for the review, - Charles > > Depending on your answers I can do the changes before pushing without > you having to submit a v2. > > Best Regards. > -- > Fabiano Fid?ncio From carnold at suse.com Wed Oct 3 20:08:43 2018 From: carnold at suse.com (Charles Arnold) Date: Wed, 03 Oct 2018 14:08:43 -0600 Subject: [Libosinfo] [PATCH libosinfo 0/3] Add SUSE CaaS Platform isodata In-Reply-To: References: <1538594457-12650-1-git-send-email-carnold@suse.com> Message-ID: <5BB521CB0200009100139099@prv-mh.provo.novell.com> >>> On 10/3/2018 at 01:45 PM, Fabiano Fid?ncio wrote: > Charles. > > On Wed, Oct 3, 2018 at 9:21 PM Charles Arnold wrote: >> >> There have been three releases. >> >> Charles Arnold (3): >> Add SUSE CaaS Platform 1.0 isodata >> Add SUSE CaaS Platform 2.0 isodata >> Add SUSE CaaS Platform 3.0 isodata >> > > Those changes broke test-isodetect and it happened because the > directory which contains the isodata should match the short-id of the > OS. > So, for instance, instead of caasp10, it should be named caasp1.0. > > There's no need to submit a v2, I can do the changes manually before > pushing the patches (and I'll push those after your feedback on the > osinfo-db series). Thank you! > > A kind unrelated topic (but not so much) ... I've noticed that > openSUSE also keeps one downstream patch for a Windows volume id. > Would be possible for you to also send that upstream? That would make > our life easier wrt maintaining opensuse package. I will get that one ready and submit. Thanks for the review, - Charles > > And thanks for submitting those changes! > > Best Regards, > -- > Fabiano Fid?ncio From fidencio at redhat.com Wed Oct 3 20:47:08 2018 From: fidencio at redhat.com (=?UTF-8?Q?Fabiano_Fid=C3=AAncio?=) Date: Wed, 3 Oct 2018 22:47:08 +0200 Subject: [Libosinfo] [PATCH libosinfo 0/3] Add SUSE CaaS Platform isodata In-Reply-To: <5BB521CB0200009100139099@prv-mh.provo.novell.com> References: <1538594457-12650-1-git-send-email-carnold@suse.com> <5BB521CB0200009100139099@prv-mh.provo.novell.com> Message-ID: Charles, On Wed, Oct 3, 2018 at 10:08 PM Charles Arnold wrote: > > >>> On 10/3/2018 at 01:45 PM, Fabiano Fid?ncio wrote: > > Charles. > > > > On Wed, Oct 3, 2018 at 9:21 PM Charles Arnold wrote: > >> > >> There have been three releases. > >> > >> Charles Arnold (3): > >> Add SUSE CaaS Platform 1.0 isodata > >> Add SUSE CaaS Platform 2.0 isodata > >> Add SUSE CaaS Platform 3.0 isodata > >> > > > > Those changes broke test-isodetect and it happened because the > > directory which contains the isodata should match the short-id of the > > OS. > > So, for instance, instead of caasp10, it should be named caasp1.0. > > > > There's no need to submit a v2, I can do the changes manually before > > pushing the patches (and I'll push those after your feedback on the > > osinfo-db series). > > Thank you! I've pushed both series with the modifications I've mentioned and here's a short recap: - osinfo-db: - Added the for caasp1.0 and caasp2.0 - Added for caasp2.0 and caasp3.0 - libosinfo: - Changed the isodata's directories to match the caasp short-ids: - caasp10 -> caasp1.0 - caasp20 -> caasp2.0 - caasp30 -> caasp3.0 > > > > > A kind unrelated topic (but not so much) ... I've noticed that > > openSUSE also keeps one downstream patch for a Windows volume id. > > Would be possible for you to also send that upstream? That would make > > our life easier wrt maintaining opensuse package. > > I will get that one ready and submit. Thanks, that would be really nice! Best Regards, -- Fabiano Fid?ncio From carnold at suse.com Wed Oct 3 21:03:45 2018 From: carnold at suse.com (Charles Arnold) Date: Wed, 3 Oct 2018 15:03:45 -0600 Subject: [Libosinfo] [osinfo-db PATCH] Fix volume ID for windows media Message-ID: <1538600625-17943-1-git-send-email-carnold@suse.com> Microsoft has changed the rules for naming the volume ID in their ISOs. This patch allows for more accurate detection by tools like virt-manager. --- data/os/microsoft.com/win-10.xml.in | 4 ++-- data/os/microsoft.com/win-2k12.xml.in | 6 +++--- data/os/microsoft.com/win-2k12r2.xml.in | 8 ++++---- data/os/microsoft.com/win-2k16.xml.in | 6 +++--- data/os/microsoft.com/win-8.1.xml.in | 2 +- data/os/microsoft.com/win-8.xml.in | 2 +- 6 files changed, 14 insertions(+), 14 deletions(-) diff --git a/data/os/microsoft.com/win-10.xml.in b/data/os/microsoft.com/win-10.xml.in index b82989c..c5da3e8 100644 --- a/data/os/microsoft.com/win-10.xml.in +++ b/data/os/microsoft.com/win-10.xml.in @@ -38,7 +38,7 @@ - (J_)?CEDN?A_X64FRE_ + (J_)?CEDN?A_X64FREE?_ MICROSOFT CORPORATION [[:upper:][:digit:]_]*_([[:upper:]]*-[[:upper:]]*) @@ -108,7 +108,7 @@ - (J_)?(CCSN?A|C?CCOMA)_X64FRE_ + (J_)?(CCSN?A|C?CCOMA)_X64FREE?_ MICROSOFT CORPORATION [[:upper:][:digit:]_]*_([[:upper:]]*-[[:upper:]]*) diff --git a/data/os/microsoft.com/win-2k12.xml.in b/data/os/microsoft.com/win-2k12.xml.in index 7463ef4..b40ee11 100644 --- a/data/os/microsoft.com/win-2k12.xml.in +++ b/data/os/microsoft.com/win-2k12.xml.in @@ -33,7 +33,7 @@ - (HRM_SSS_X64CHK|HRM_SSS_X64FRE)_ + (HRM_SSS_X64CHK|HRM_SSS_X64FREE?)_ MICROSOFT CORPORATION [[:upper:][:digit:]]*_([[:upper:]]*) @@ -42,7 +42,7 @@ - (HRM_SSSO_X64FRE)_ + (HRM_SSSO_X64FREE?)_ MICROSOFT CORPORATION [[:upper:][:digit:]]*_([[:upper:]]*) @@ -50,7 +50,7 @@ - (HRM_SHV_X64CHK|HRM_SHV_X64FRE)_ + (HRM_SHV_X64CHK|HRM_SHV_X64FREE?)_ MICROSOFT CORPORATION [[:upper:][:digit:]]*_([[:upper:]]*) diff --git a/data/os/microsoft.com/win-2k12r2.xml.in b/data/os/microsoft.com/win-2k12r2.xml.in index b80db39..7bf7b9c 100644 --- a/data/os/microsoft.com/win-2k12r2.xml.in +++ b/data/os/microsoft.com/win-2k12r2.xml.in @@ -28,7 +28,7 @@ - (IRM_SSS_X64FRE|IRM_SSS_X64CHK|IR3_SSS_X64FRE|IR5_SSS_X64FRE)_ + (IRM_SSS_X64FREE?|IRM_SSS_X64CHK|IR3_SSS_X64FREE?|IR5_SSS_X64FREE?)_ MICROSOFT CORPORATION [[:upper:][:digit:]]*_([[:upper:]]*) @@ -36,7 +36,7 @@ - (IRM_SSSO_X64CHK|IR5_SSSO_X64FRE|IRM_SSSO_X64FRE)_ + (IRM_SSSO_X64CHK|IR5_SSSO_X64FREE?|IRM_SSSO_X64FREE?)_ MICROSOFT CORPORATION [[:upper:][:digit:]]*_([[:upper:]]*) @@ -44,7 +44,7 @@ - (IRM_SHV_X64CHK|IRM_SHV_X64FRE)_ + (IRM_SHV_X64CHK|IRM_SHV_X64FREE?)_ MICROSOFT CORPORATION [[:upper:][:digit:]]*_([[:upper:]]*) @@ -52,7 +52,7 @@ - (IR5_SSS_X64FREV|IR2_SSS_X64FREV)_ + (IR5_SSS_X64FREV|IR2_SSS_X64FREV|IR1_SSS_X64FREV)_ MICROSOFT CORPORATION [[:upper:][:digit:]]*_([[:upper:]]*) diff --git a/data/os/microsoft.com/win-2k16.xml.in b/data/os/microsoft.com/win-2k16.xml.in index 523733d..f3db328 100644 --- a/data/os/microsoft.com/win-2k16.xml.in +++ b/data/os/microsoft.com/win-2k16.xml.in @@ -19,7 +19,7 @@ - ^(SSS_X64CHK|SSS_X64FRE|SSS_X64FREE)_ + ^(SSS_X64CHK|SSS_X64FREE?)_ MICROSOFT CORPORATION [[:upper:][:digit:]]*_([[:upper:]]*) @@ -27,7 +27,7 @@ - ^(SESS_X64FRE)_ + ^(SESS_X64FREE?)_ MICROSOFT CORPORATION [[:upper:][:digit:]]*_([[:upper:]]*) @@ -35,7 +35,7 @@ - ^(SHV_X64CHK|SHV_X64FRE)_ + ^(SHV_X64CHK|SHV_X64FREE?)_ MICROSOFT CORPORATION [[:upper:][:digit:]]*_([[:upper:]]*) diff --git a/data/os/microsoft.com/win-8.1.xml.in b/data/os/microsoft.com/win-8.1.xml.in index a140f7e..9294ba0 100644 --- a/data/os/microsoft.com/win-8.1.xml.in +++ b/data/os/microsoft.com/win-8.1.xml.in @@ -108,7 +108,7 @@ - (IR[M35]_CCSN?A_X64FRE)_ + (IR[M35]_CCSN?A_X64FREE?)_ MICROSOFT CORPORATION [[:upper:][:digit:]_]*_([[:upper:]]*-[[:upper:]]*) diff --git a/data/os/microsoft.com/win-8.xml.in b/data/os/microsoft.com/win-8.xml.in index e4ae8a4..900eac4 100644 --- a/data/os/microsoft.com/win-8.xml.in +++ b/data/os/microsoft.com/win-8.xml.in @@ -36,7 +36,7 @@ - (HB1_CCPA_X64FRE|HRM_CCSN?A_X64FRE)_ + (HB1_CCPA_X64FREE?|HRM_CCSN?A_X64FREE?)_ MICROSOFT CORPORATION [[:upper:][:digit:]_]*_([[:upper:]]*-[[:upper:]]*) -- 1.8.5.6 From fidencio at redhat.com Wed Oct 3 21:31:24 2018 From: fidencio at redhat.com (=?UTF-8?Q?Fabiano_Fid=C3=AAncio?=) Date: Wed, 3 Oct 2018 23:31:24 +0200 Subject: [Libosinfo] [osinfo-db PATCH] Fix volume ID for windows media In-Reply-To: <1538600625-17943-1-git-send-email-carnold@suse.com> References: <1538600625-17943-1-git-send-email-carnold@suse.com> Message-ID: On Wed, Oct 3, 2018 at 11:04 PM Charles Arnold wrote: > > Microsoft has changed the rules for naming the volume ID > in their ISOs. This patch allows for more accurate detection > by tools like virt-manager. This info is quite hard (maybe impossible?) to find by just searching the volume-ids in the internet. :-/ Would be really nice to have the isodata of those medias, but I have the feeling you don't have access to the problematic ISOs. Anyways, the patch itself doesn't cause any harm and it's been kept downstream on SLES and openSUSE for quite a while and I do believe it's better to have it merged. Reviewed-by: Fabiano Fid?ncio > > --- > data/os/microsoft.com/win-10.xml.in | 4 ++-- > data/os/microsoft.com/win-2k12.xml.in | 6 +++--- > data/os/microsoft.com/win-2k12r2.xml.in | 8 ++++---- > data/os/microsoft.com/win-2k16.xml.in | 6 +++--- > data/os/microsoft.com/win-8.1.xml.in | 2 +- > data/os/microsoft.com/win-8.xml.in | 2 +- > 6 files changed, 14 insertions(+), 14 deletions(-) > > diff --git a/data/os/microsoft.com/win-10.xml.in b/data/os/microsoft.com/win-10.xml.in > index b82989c..c5da3e8 100644 > --- a/data/os/microsoft.com/win-10.xml.in > +++ b/data/os/microsoft.com/win-10.xml.in > @@ -38,7 +38,7 @@ > > > > - (J_)?CEDN?A_X64FRE_ > + (J_)?CEDN?A_X64FREE?_ > MICROSOFT CORPORATION > [[:upper:][:digit:]_]*_([[:upper:]]*-[[:upper:]]*) > > @@ -108,7 +108,7 @@ > > > > - (J_)?(CCSN?A|C?CCOMA)_X64FRE_ > + (J_)?(CCSN?A|C?CCOMA)_X64FREE?_ > MICROSOFT CORPORATION > [[:upper:][:digit:]_]*_([[:upper:]]*-[[:upper:]]*) > > diff --git a/data/os/microsoft.com/win-2k12.xml.in b/data/os/microsoft.com/win-2k12.xml.in > index 7463ef4..b40ee11 100644 > --- a/data/os/microsoft.com/win-2k12.xml.in > +++ b/data/os/microsoft.com/win-2k12.xml.in > @@ -33,7 +33,7 @@ > > > > - (HRM_SSS_X64CHK|HRM_SSS_X64FRE)_ > + (HRM_SSS_X64CHK|HRM_SSS_X64FREE?)_ > MICROSOFT CORPORATION > [[:upper:][:digit:]]*_([[:upper:]]*) > > @@ -42,7 +42,7 @@ > > > > - (HRM_SSSO_X64FRE)_ > + (HRM_SSSO_X64FREE?)_ > MICROSOFT CORPORATION > [[:upper:][:digit:]]*_([[:upper:]]*) > > @@ -50,7 +50,7 @@ > > > > - (HRM_SHV_X64CHK|HRM_SHV_X64FRE)_ > + (HRM_SHV_X64CHK|HRM_SHV_X64FREE?)_ > MICROSOFT CORPORATION > [[:upper:][:digit:]]*_([[:upper:]]*) > > diff --git a/data/os/microsoft.com/win-2k12r2.xml.in b/data/os/microsoft.com/win-2k12r2.xml.in > index b80db39..7bf7b9c 100644 > --- a/data/os/microsoft.com/win-2k12r2.xml.in > +++ b/data/os/microsoft.com/win-2k12r2.xml.in > @@ -28,7 +28,7 @@ > > > > - (IRM_SSS_X64FRE|IRM_SSS_X64CHK|IR3_SSS_X64FRE|IR5_SSS_X64FRE)_ > + (IRM_SSS_X64FREE?|IRM_SSS_X64CHK|IR3_SSS_X64FREE?|IR5_SSS_X64FREE?)_ > MICROSOFT CORPORATION > [[:upper:][:digit:]]*_([[:upper:]]*) > > @@ -36,7 +36,7 @@ > > > > - (IRM_SSSO_X64CHK|IR5_SSSO_X64FRE|IRM_SSSO_X64FRE)_ > + (IRM_SSSO_X64CHK|IR5_SSSO_X64FREE?|IRM_SSSO_X64FREE?)_ > MICROSOFT CORPORATION > [[:upper:][:digit:]]*_([[:upper:]]*) > > @@ -44,7 +44,7 @@ > > > > - (IRM_SHV_X64CHK|IRM_SHV_X64FRE)_ > + (IRM_SHV_X64CHK|IRM_SHV_X64FREE?)_ > MICROSOFT CORPORATION > [[:upper:][:digit:]]*_([[:upper:]]*) > > @@ -52,7 +52,7 @@ > > > > - (IR5_SSS_X64FREV|IR2_SSS_X64FREV)_ > + (IR5_SSS_X64FREV|IR2_SSS_X64FREV|IR1_SSS_X64FREV)_ > MICROSOFT CORPORATION > [[:upper:][:digit:]]*_([[:upper:]]*) > > diff --git a/data/os/microsoft.com/win-2k16.xml.in b/data/os/microsoft.com/win-2k16.xml.in > index 523733d..f3db328 100644 > --- a/data/os/microsoft.com/win-2k16.xml.in > +++ b/data/os/microsoft.com/win-2k16.xml.in > @@ -19,7 +19,7 @@ > > > > - ^(SSS_X64CHK|SSS_X64FRE|SSS_X64FREE)_ > + ^(SSS_X64CHK|SSS_X64FREE?)_ > MICROSOFT CORPORATION > [[:upper:][:digit:]]*_([[:upper:]]*) > > @@ -27,7 +27,7 @@ > > > > - ^(SESS_X64FRE)_ > + ^(SESS_X64FREE?)_ > MICROSOFT CORPORATION > [[:upper:][:digit:]]*_([[:upper:]]*) > > @@ -35,7 +35,7 @@ > > > > - ^(SHV_X64CHK|SHV_X64FRE)_ > + ^(SHV_X64CHK|SHV_X64FREE?)_ > MICROSOFT CORPORATION > [[:upper:][:digit:]]*_([[:upper:]]*) > > diff --git a/data/os/microsoft.com/win-8.1.xml.in b/data/os/microsoft.com/win-8.1.xml.in > index a140f7e..9294ba0 100644 > --- a/data/os/microsoft.com/win-8.1.xml.in > +++ b/data/os/microsoft.com/win-8.1.xml.in > @@ -108,7 +108,7 @@ > > > > - (IR[M35]_CCSN?A_X64FRE)_ > + (IR[M35]_CCSN?A_X64FREE?)_ > MICROSOFT CORPORATION > [[:upper:][:digit:]_]*_([[:upper:]]*-[[:upper:]]*) > > diff --git a/data/os/microsoft.com/win-8.xml.in b/data/os/microsoft.com/win-8.xml.in > index e4ae8a4..900eac4 100644 > --- a/data/os/microsoft.com/win-8.xml.in > +++ b/data/os/microsoft.com/win-8.xml.in > @@ -36,7 +36,7 @@ > > > > - (HB1_CCPA_X64FRE|HRM_CCSN?A_X64FRE)_ > + (HB1_CCPA_X64FREE?|HRM_CCSN?A_X64FREE?)_ > MICROSOFT CORPORATION > [[:upper:][:digit:]_]*_([[:upper:]]*-[[:upper:]]*) > > -- > 1.8.5.6 > > _______________________________________________ > Libosinfo mailing list > Libosinfo at redhat.com > https://www.redhat.com/mailman/listinfo/libosinfo From fidencio at redhat.com Wed Oct 3 21:34:31 2018 From: fidencio at redhat.com (=?UTF-8?Q?Fabiano_Fid=C3=AAncio?=) Date: Wed, 3 Oct 2018 23:34:31 +0200 Subject: [Libosinfo] [osinfo-db PATCH] Fix volume ID for windows media In-Reply-To: References: <1538600625-17943-1-git-send-email-carnold@suse.com> Message-ID: On Wed, Oct 3, 2018 at 11:31 PM Fabiano Fid?ncio wrote: > > On Wed, Oct 3, 2018 at 11:04 PM Charles Arnold wrote: > > > > Microsoft has changed the rules for naming the volume ID > > in their ISOs. This patch allows for more accurate detection > > by tools like virt-manager. > > This info is quite hard (maybe impossible?) to find by just searching > the volume-ids in the internet. :-/ > Would be really nice to have the isodata of those medias, but I have > the feeling you don't have access to the problematic ISOs. > > Anyways, the patch itself doesn't cause any harm and it's been kept > downstream on SLES and openSUSE for quite a while and I do believe > it's better to have it merged. > > Reviewed-by: Fabiano Fid?ncio (And merged!) From fidencio at redhat.com Thu Oct 4 07:26:17 2018 From: fidencio at redhat.com (Fabiano =?ISO-8859-1?Q?Fid=EAncio?=) Date: Thu, 04 Oct 2018 09:26:17 +0200 Subject: [Libosinfo] [PATCH osinfo-db 0/5 v2] Add q35 devices In-Reply-To: References: Message-ID: <26ceca03c645fb28c10abaa52c41f9049d7494dc.camel@redhat.com> On Fri, 2018-09-28 at 18:55 -0400, Cole Robinson wrote: > The main goal of this series is to advertise q35 chipset and device > support for suitable OS. Some details about the individual decisions > > * We group q35+ich9+e1000e together. This likely isn't completely > accurate but in the virt case I think it only makes sense to > specify the latter two devices when pcie (q35) is present, so > I went with it. > > * We only advertise q35 when virtio1.0 devices are available, on > linux. > This definitely isn't accurate, q35 predates virtio1.0 by 8 years > or > so, but there's issues combining q35 with legacy virtio, and that's > the only combo I'll be exploring for virt-manager so other > scenarios > my go untested. > > * The actual OS+q35 combos are largely untested by me. > > v1 posting: > https://www.redhat.com/archives/libosinfo/2018-August/msg00006.html > > v2 changes: > * Rebased, drop committed patches > * Rework the chipset device ID and dir structure > > > In the original posting danpb suggested introducing a new > concept to cover this case, roughly outlined here: > > https://www.redhat.com/archives/libosinfo/2018-September/msg00014.html > > This posting doesn't add that and instead uses like before, > but with some changes: > > $ cat data/device/qemu.org/chipset-x86_64-q35.d/class.xml.in > > > > q35 > chipset.virtual > > > > > My justifications for not going the full route: > > * It's much more work to add new APIs, test them, document them, etc. > I'm lazy, but it's also a lot more code to maintain forever. > > * Will be harder in the short term for clients as well. virt-manager > will need to use the new APIs and correctly check that they exist, > vs just using the existing device APIs. > > * I think we should bite the bullet and make the concept > more fuzzy, since we may want that anyways to model things like > hyperv features which aren't all strictly devices. > > * Eventually we will need to extend the XML schema with some way to > mark unsupported if a new version of an OS drops support. > This is already the case with newer windows which doesn't support > ac97 out of the box, though libosinfo still reports support. If > we have a separate concept, we will need to duplicate > that schema and likely libosinfo support to handle that case as > well. So more work going forward. > > > Now some questions: A quick one: is class=chipset.virtual okay? I > used .virtual as some day we may want to track actual chipset PCI > devices for example, like the PCI ID for q35. Considering we're going for the approach you suggested, yes, it does make sense. > > Bigger question: What is the expected way that API users should > determine if libosinfo supports a particular device? Take USB tablet > support for example. The qemu usb tablet has this device xml: > > > tablet > input > > > Ways you can presently search for that device with the API: > > - Search for the device ID which is expected to be unique > - Search for name=tablet which presently is unique. However that's a > super generic name, and nothing seems to enforce uniqueness > for devices, so I don't know if we can/should count on that. > - Search for class=input name=tablet which narrows it a bit Boxes takes the second apprach. It basically gets the list of all supported devices and then does, for instance: `find_device_by_prop(supported_devices, DEVICE_PROP_NAME, "virtio- net")` > > virt-manager for example does the last step. I don't know if that's > a good idea though, given how generic name is. Do we aim to give > any guarantees about uniqueness, or that it will never change? > Is never expected to change? With the current codebase, I'd say that although we don' enforce, apps are already assuming the uniqueness. So, in case it fits your design choices, we could go for that. > > With that context, let's consider querying chipset. I want to make > sure this syntax isn't going to make future virt chipset additions > difficult. Dan's list in the email lays out some other examples: > > qemu.org/chipset/i686-q35 > qemu.org/chipset/x86_64-q35 > qemu.org/chipset/aarch64/virt > qemu.org/chipset/riscv/virt > > If is expected to be globally unique, we probably don't want > to use name=q35 incase it clashes with a future pcisig.com , > another virt stack's chipset, or even qemu q35 for i686. So that > could > mean name=x86_64-q35, or even name=qemu-x86_64-q35. That gets ugly > and > redundant fast though. And here I see that it may not fit your design choices :-) Anyways, can't we enforce the arch/platform for this? So, for instance ... q35 chipset.virtual x86_64 Btw, I don't have a proper understanding on how we use the platform so far and if someone is in the mood to give a nice explanation, that would be really welcome! :-) In any case, we'd have to expand the "device" schema and have new APIs for that in order to guarantee we're not matching the wrong device. > > So IMO the sensible thing would be to enforce uniqueness in two ways: > 1) the device ID, 2) the set of all device properties. So that would > lead > to these 4 configs > > > q35 > x86_64 > chipset.virtual > > > q35 > i686 > chipset.virtual > > > virt > aarch64 > chipset.virtual > > > virt > riscv > chipset.virtual > Aha. I should have read the whole e-mail before start answering it. :-/ > > > The downsides of that: 1) if an app naively searchs for name=q35 they > may get the wrong result, because it ignored . Easy to misuse. > That's something that should be documented how the apps are expected to use and that's it, IMHO. > 2) There aren't any other examples yet of non-unique so maybe > it causes other issues. True. > > All of that makes me think that the only safe recommendation for apps > is to search by device id. should be treated largely as > metadata. > > We don't necessarily need to implement all this now, since the q35 > case > is fairly straightforward, but we should at least make sure we aren't > going down the wrong path. Please, take my answers with a grain of salt as I do believe that Daniel should/will want to have his opinion on this series as well. > > > Cole Robinson (5): > device: Add network e1000e > device: Add sound ich9 > device: Add chipset q35 > os: Add q35/e1000e/ich9 for win2k8r2+ and win7+ > os: linux: Add q35/ich9/e1000e alongside virtio1.0 > > data/device/pcisig.com/pci-8086-10d3.d/class.xml.in | 8 ++++++++ > data/device/pcisig.com/pci-8086-293e.d/class.xml.in | 8 ++++++++ > 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 + > 13 files changed, 56 insertions(+), 1 deletion(-) > create mode 100644 data/device/pcisig.com/pci-8086- > 10d3.d/class.xml.in > create mode 100644 data/device/pcisig.com/pci-8086- > 293e.d/class.xml.in > create mode 100644 data/device/qemu.org/chipset-x86_64- > q35.d/class.xml.in > Best Regards, -- Fabiano Fid?ncio From fidencio at redhat.com Thu Oct 4 07:30:55 2018 From: fidencio at redhat.com (Fabiano =?ISO-8859-1?Q?Fid=EAncio?=) Date: Thu, 04 Oct 2018 09:30:55 +0200 Subject: [Libosinfo] [PATCH osinfo-db v2 1/5] device: Add network e1000e In-Reply-To: References: Message-ID: On Fri, 2018-09-28 at 18:55 -0400, Cole Robinson wrote: > Signed-off-by: Cole Robinson > --- > data/device/pcisig.com/pci-8086-10d3.d/class.xml.in | 8 ++++++++ > 1 file changed, 8 insertions(+) > create mode 100644 data/device/pcisig.com/pci-8086- > 10d3.d/class.xml.in > > diff --git a/data/device/pcisig.com/pci-8086-10d3.d/class.xml.in > b/data/device/pcisig.com/pci-8086-10d3.d/class.xml.in > new file mode 100644 > index 0000000..703e26f > --- /dev/null > +++ b/data/device/pcisig.com/pci-8086-10d3.d/class.xml.in > @@ -0,0 +1,8 @@ > + > + > + > + e1000e > + net > + > + Reviewed-by: Fabiano Fid?ncio From fidencio at redhat.com Thu Oct 4 07:31:21 2018 From: fidencio at redhat.com (Fabiano =?ISO-8859-1?Q?Fid=EAncio?=) Date: Thu, 04 Oct 2018 09:31:21 +0200 Subject: [Libosinfo] [PATCH osinfo-db v2 2/5] device: Add sound ich9 In-Reply-To: <55c9b73451e8503a41018559f10412c05981ce11.1538175297.git.crobinso@redhat.com> References: <55c9b73451e8503a41018559f10412c05981ce11.1538175297.git.crobinso@redhat.com> Message-ID: <2309c8b328044cc1b3c638f84572f6140fe9dc0d.camel@redhat.com> On Fri, 2018-09-28 at 18:55 -0400, Cole Robinson wrote: > Signed-off-by: Cole Robinson > --- > data/device/pcisig.com/pci-8086-293e.d/class.xml.in | 8 ++++++++ > 1 file changed, 8 insertions(+) > create mode 100644 data/device/pcisig.com/pci-8086- > 293e.d/class.xml.in > > diff --git a/data/device/pcisig.com/pci-8086-293e.d/class.xml.in > b/data/device/pcisig.com/pci-8086-293e.d/class.xml.in > new file mode 100644 > index 0000000..6326a4d > --- /dev/null > +++ b/data/device/pcisig.com/pci-8086-293e.d/class.xml.in > @@ -0,0 +1,8 @@ > + > + > + > + ich9 > + audio > + > + Reviewed-by: Fabiano Fid?ncio From fidencio at redhat.com Thu Oct 4 07:31:48 2018 From: fidencio at redhat.com (Fabiano =?ISO-8859-1?Q?Fid=EAncio?=) Date: Thu, 04 Oct 2018 09:31:48 +0200 Subject: [Libosinfo] [PATCH osinfo-db v2 3/5] device: Add chipset q35 In-Reply-To: References: Message-ID: <17c4d388d5c3d123124d4416cda0b779fbf68cea.camel@redhat.com> On Fri, 2018-09-28 at 18:55 -0400, Cole Robinson wrote: > 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 0000000..6920c67 > --- /dev/null > +++ b/data/device/qemu.org/chipset-x86_64-q35.d/class.xml.in > @@ -0,0 +1,8 @@ > + > + > + > + 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 Reviewed-by: Fabiano Fid?ncio From fidencio at redhat.com Thu Oct 4 07:35:08 2018 From: fidencio at redhat.com (Fabiano =?ISO-8859-1?Q?Fid=EAncio?=) Date: Thu, 04 Oct 2018 09:35:08 +0200 Subject: [Libosinfo] [PATCH osinfo-db v2 3/5] device: Add chipset q35 In-Reply-To: <17c4d388d5c3d123124d4416cda0b779fbf68cea.camel@redhat.com> References: <17c4d388d5c3d123124d4416cda0b779fbf68cea.camel@redhat.com> Message-ID: <55e55d2d68ca84fc5a7c23b533f2ec4d5859e8c9.camel@redhat.com> On Thu, 2018-10-04 at 09:31 +0200, Fabiano Fid?ncio wrote: > On Fri, 2018-09-28 at 18:55 -0400, Cole Robinson wrote: > > 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 0000000..6920c67 > > --- /dev/null > > +++ b/data/device/qemu.org/chipset-x86_64-q35.d/class.xml.in > > @@ -0,0 +1,8 @@ > > + > > + > > + > > + 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 > > Reviewed-by: Fabiano Fid?ncio Ooops, sorry, the "Reviewed-by" has been added by mistake in this patch. I can't ACK this patch yet at least not before we have a better idea on the discussion your started in the cover-letter. Before having this ACK'ed, I really would like to have an agreement whether we're going to also add the / fields as well and have a bug opened for that as I don't believe that's something strictly needed for now! From fidencio at redhat.com Thu Oct 4 07:44:40 2018 From: fidencio at redhat.com (Fabiano =?ISO-8859-1?Q?Fid=EAncio?=) Date: Thu, 04 Oct 2018 09:44:40 +0200 Subject: [Libosinfo] [PATCH osinfo-db v2 4/5] os: Add q35/e1000e/ich9 for win2k8r2+ and win7+ In-Reply-To: <9a8a6705e6d0ea6bcac6ab496de815ecb4d50ec5.1538175297.git.crobinso@redhat.com> References: <9a8a6705e6d0ea6bcac6ab496de815ecb4d50ec5.1538175297.git.crobinso@redhat.com> Message-ID: On Fri, 2018-09-28 at 18:55 -0400, Cole Robinson wrote: > 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..71a7172 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 > > + > + > + > + > + > + > > > (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..0ae1868 100644 > --- a/data/os/microsoft.com/win-7.xml.in > +++ b/data/os/microsoft.com/win-7.xml.in > @@ -182,6 +182,9 @@ > > > > + > + > + > > > In your cover-letter you stated that this combo (q35+e1000e+ich9) wasn't extensively tested. May I assume that it was tested on this case? :-) From fidencio at redhat.com Thu Oct 4 07:46:04 2018 From: fidencio at redhat.com (Fabiano =?ISO-8859-1?Q?Fid=EAncio?=) Date: Thu, 04 Oct 2018 09:46:04 +0200 Subject: [Libosinfo] [PATCH osinfo-db v2 5/5] os: linux: Add q35/ich9/e1000e alongside virtio1.0 In-Reply-To: <2df27cef2e7a8dbbd2f6e8636e6b921f82684f4c.1538175297.git.crobinso@redhat.com> References: <2df27cef2e7a8dbbd2f6e8636e6b921f82684f4c.1538175297.git.crobinso@redhat.com> Message-ID: <024a7ec3f6719f8a5ba8c1bd7151251ee8a50b72.camel@redhat.com> On Fri, 2018-09-28 at 18:55 -0400, Cole Robinson wrote: > q35 is from 2007, so older OS versions definitely support it, > however combining q35 with non-1.0 virtio can cause issues due to > 'I/O port space PCIe limitations' > > https://ladipro.wordpress.com/2016/10/17/virtio1-0-and-windows-guests/ > Signed-off-by: Cole Robinson > --- > data/os/debian.org/debian-9.xml.in | 3 +++ > data/os/fedoraproject.org/fedora-23.xml.in | 5 ++++- > 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 +++ > 7 files changed, 22 insertions(+), 1 deletion(-) > > diff --git a/data/os/debian.org/debian-9.xml.in > b/data/os/debian.org/debian-9.xml.in > index d90ceb9..14f2b8e 100644 > --- a/data/os/debian.org/debian-9.xml.in > +++ b/data/os/debian.org/debian-9.xml.in > @@ -23,6 +23,9 @@ > > > > + > + > + > > > > diff --git a/data/os/fedoraproject.org/fedora-23.xml.in > b/data/os/fedoraproject.org/fedora-23.xml.in > index 2711620..f426bbc 100644 > --- a/data/os/fedoraproject.org/fedora-23.xml.in > +++ b/data/os/fedoraproject.org/fedora-23.xml.in > @@ -37,7 +37,10 @@ > > > > + pretend its just not available until F24 to avoid bug > reports --> > + > + > + > > > > diff --git a/data/os/opensuse.org/opensuse-42.2.xml.in > b/data/os/opensuse.org/opensuse-42.2.xml.in > index 2e77055..18ffd6e 100644 > --- a/data/os/opensuse.org/opensuse-42.2.xml.in > +++ b/data/os/opensuse.org/opensuse-42.2.xml.in > @@ -24,6 +24,9 @@ > > > > + > + > + > > > > diff --git a/data/os/redhat.com/rhel-7.2.xml.in > b/data/os/redhat.com/rhel-7.2.xml.in > index 5c8db2b..309d0d9 100644 > --- a/data/os/redhat.com/rhel-7.2.xml.in > +++ b/data/os/redhat.com/rhel-7.2.xml.in > @@ -23,6 +23,9 @@ > > > > + > + > + > > > > diff --git a/data/os/suse.com/sled-12.2.xml.in > b/data/os/suse.com/sled-12.2.xml.in > index 67d2b17..1c44fd3 100644 > --- a/data/os/suse.com/sled-12.2.xml.in > +++ b/data/os/suse.com/sled-12.2.xml.in > @@ -23,6 +23,9 @@ > > > > + > + > + > > > > diff --git a/data/os/suse.com/sles-12.2.xml.in > b/data/os/suse.com/sles-12.2.xml.in > index dccc443..014b3e3 100644 > --- a/data/os/suse.com/sles-12.2.xml.in > +++ b/data/os/suse.com/sles-12.2.xml.in > @@ -23,6 +23,9 @@ > > > > + > + > + > > > > diff --git a/data/os/ubuntu.com/ubuntu-17.04.xml.in > b/data/os/ubuntu.com/ubuntu-17.04.xml.in > index 28e9784..033fb0d 100644 > --- a/data/os/ubuntu.com/ubuntu-17.04.xml.in > +++ b/data/os/ubuntu.com/ubuntu-17.04.xml.in > @@ -25,6 +25,9 @@ > > > > + > + > + > > > I guess the same question from the last patch applies here. Which of those changes were actually tested so far? From fidencio at redhat.com Thu Oct 4 07:48:04 2018 From: fidencio at redhat.com (Fabiano =?ISO-8859-1?Q?Fid=EAncio?=) Date: Thu, 04 Oct 2018 09:48:04 +0200 Subject: [Libosinfo] [PATCH osinfo-db 0/5 v2] Add q35 devices In-Reply-To: <26ceca03c645fb28c10abaa52c41f9049d7494dc.camel@redhat.com> References: <26ceca03c645fb28c10abaa52c41f9049d7494dc.camel@redhat.com> Message-ID: On Thu, 2018-10-04 at 09:26 +0200, Fabiano Fid?ncio wrote: > On Fri, 2018-09-28 at 18:55 -0400, Cole Robinson wrote: > > The main goal of this series is to advertise q35 chipset and device > > support for suitable OS. Some details about the individual > > decisions > > > > * We group q35+ich9+e1000e together. This likely isn't completely > > accurate but in the virt case I think it only makes sense to > > specify the latter two devices when pcie (q35) is present, so > > I went with it. > > > > * We only advertise q35 when virtio1.0 devices are available, on > > linux. > > This definitely isn't accurate, q35 predates virtio1.0 by 8 years > > or > > so, but there's issues combining q35 with legacy virtio, and > > that's > > the only combo I'll be exploring for virt-manager so other > > scenarios > > my go untested. > > > > * The actual OS+q35 combos are largely untested by me. > > > > v1 posting: > > https://www.redhat.com/archives/libosinfo/2018-August/msg00006.html > > > > v2 changes: > > * Rebased, drop committed patches > > * Rework the chipset device ID and dir structure > > > > > > In the original posting danpb suggested introducing a new > > concept to cover this case, roughly outlined here: > > > > https://www.redhat.com/archives/libosinfo/2018-September/msg00014.html > > > > This posting doesn't add that and instead uses like > > before, > > but with some changes: > > > > $ cat data/device/qemu.org/chipset-x86_64-q35.d/class.xml.in > > > > > > > > q35 > > chipset.virtual > > > > > > > > > > My justifications for not going the full route: > > > > * It's much more work to add new APIs, test them, document them, > > etc. > > I'm lazy, but it's also a lot more code to maintain forever. > > > > * Will be harder in the short term for clients as well. virt- > > manager > > will need to use the new APIs and correctly check that they > > exist, > > vs just using the existing device APIs. > > > > * I think we should bite the bullet and make the concept > > more fuzzy, since we may want that anyways to model things like > > hyperv features which aren't all strictly devices. > > > > * Eventually we will need to extend the XML schema with some way to > > mark unsupported if a new version of an OS drops > > support. > > This is already the case with newer windows which doesn't support > > ac97 out of the box, though libosinfo still reports support. If > > we have a separate concept, we will need to duplicate > > that schema and likely libosinfo support to handle that case as > > well. So more work going forward. > > > > > > Now some questions: A quick one: is class=chipset.virtual okay? I > > used .virtual as some day we may want to track actual chipset PCI > > devices for example, like the PCI ID for q35. > > Considering we're going for the approach you suggested, yes, it does > make sense. > > > Bigger question: What is the expected way that API users should > > determine if libosinfo supports a particular device? Take USB > > tablet > > support for example. The qemu usb tablet has this device xml: > > > > > > tablet > > input > > > > > > Ways you can presently search for that device with the API: > > > > - Search for the device ID which is expected to be unique > > - Search for name=tablet which presently is unique. However that's > > a > > super generic name, and nothing seems to enforce > > uniqueness > > for devices, so I don't know if we can/should count on that. > > - Search for class=input name=tablet which narrows it a bit > > Boxes takes the second apprach. > It basically gets the list of all supported devices and then does, > for > instance: > `find_device_by_prop(supported_devices, DEVICE_PROP_NAME, "virtio- > net")` > > > virt-manager for example does the last step. I don't know if that's > > a good idea though, given how generic name is. Do we aim to give > > any guarantees about uniqueness, or that it will never > > change? > > Is never expected to change? > > With the current codebase, I'd say that although we don' enforce, > apps > are already assuming the uniqueness. So, in case it fits your > design choices, we could go for that. > > > With that context, let's consider querying chipset. I want to make > > sure this syntax isn't going to make future virt chipset additions > > difficult. Dan's list in the email lays out some other examples: > > > > qemu.org/chipset/i686-q35 > > qemu.org/chipset/x86_64-q35 > > qemu.org/chipset/aarch64/virt > > qemu.org/chipset/riscv/virt > > > > If is expected to be globally unique, we probably don't want > > to use name=q35 incase it clashes with a future pcisig.com > > , > > another virt stack's chipset, or even qemu q35 for i686. So that > > could > > mean name=x86_64-q35, or even name=qemu-x86_64-q35. That gets ugly > > and > > redundant fast though. > > And here I see that it may not fit your design choices :-) > > Anyways, can't we enforce the arch/platform for this? > > So, for instance ... > > q35 > chipset.virtual > x86_64 > > > > Btw, I don't have a proper understanding on how we use the platform > so > far and if someone is in the mood to give a nice explanation, that > would be really welcome! :-) > > In any case, we'd have to expand the "device" schema and have new > APIs > for that in order to guarantee we're not matching the wrong device. > > > So IMO the sensible thing would be to enforce uniqueness in two > > ways: > > 1) the device ID, 2) the set of all device properties. So that > > would > > lead > > to these 4 configs > > > > > > q35 > > x86_64 > > chipset.virtual > > > > > > q35 > > i686 > > chipset.virtual > > > > > > virt > > aarch64 > > chipset.virtual > > > > > > virt > > riscv > > chipset.virtual > > > > Aha. I should have read the whole e-mail before start answering it. > :-/ > > > > > The downsides of that: 1) if an app naively searchs for name=q35 > > they > > may get the wrong result, because it ignored . Easy to > > misuse. > > > > That's something that should be documented how the apps are expected > to > use and that's it, IMHO. > > > 2) There aren't any other examples yet of non-unique so > > maybe > > it causes other issues. > > True. > > > All of that makes me think that the only safe recommendation for > > apps > > is to search by device id. should be treated largely as > > metadata. > > > > We don't necessarily need to implement all this now, since the q35 > > case > > is fairly straightforward, but we should at least make sure we > > aren't > > going down the wrong path. > > Please, take my answers with a grain of salt as I do believe that > Daniel should/will want to have his opinion on this series as well. Last thing here: I went throught the patches and they look okay enough to go if Daniel agrees with the approach and we have an agreement on how to expand it in the future (if we do). > > > > > Cole Robinson (5): > > device: Add network e1000e > > device: Add sound ich9 > > device: Add chipset q35 > > os: Add q35/e1000e/ich9 for win2k8r2+ and win7+ > > os: linux: Add q35/ich9/e1000e alongside virtio1.0 > > > > data/device/pcisig.com/pci-8086-10d3.d/class.xml.in | 8 > > ++++++++ > > data/device/pcisig.com/pci-8086-293e.d/class.xml.in | 8 > > ++++++++ > > 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 + > > 13 files changed, 56 insertions(+), 1 deletion(-) > > create mode 100644 data/device/pcisig.com/pci-8086- > > 10d3.d/class.xml.in > > create mode 100644 data/device/pcisig.com/pci-8086- > > 293e.d/class.xml.in > > create mode 100644 data/device/qemu.org/chipset-x86_64- > > q35.d/class.xml.in > > > > Best Regards, From berrange at redhat.com Thu Oct 4 10:05:18 2018 From: berrange at redhat.com (Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?=) Date: Thu, 4 Oct 2018 11:05:18 +0100 Subject: [Libosinfo] [PATCH libosinfo/osinfo-db 0/5] Force anchored patterns when matching regex In-Reply-To: References: <20180907191859.931-1-fidencio@redhat.com> Message-ID: <20181004100518.GG3667@redhat.com> On Tue, Sep 11, 2018 at 01:15:26PM -0400, Cole Robinson wrote: > On 09/07/2018 03:18 PM, Fabiano Fid?ncio wrote: > > This patch series basically consists in a fix for a possibly always > > present issue that I've faced Today after adding more data to osinfo-db. > > > > Please, take a careful look at "db: Force anchored ..." patch as this is > > the most important patch of the series. > > > > As this change ends up exposing a few more issues on osinfo-db, would be > > really nice to have the osinfo-db patches merged altogether. > > > > It's important to note that the osinfo-db patches themselves are **not** > > going to break something in case they're used against a "non-patched" > > libosinfo. > > > > Also, the osinfo-db patches will have their commit message edited after > > the libosinfo patches are pushed, so I can reference the proper commit > > hash in their commit messages. > > > > libosinfo: > > Fabiano Fid?ncio (2): > > tests: Expand the arch's parser for isodetect > > db: Force anchored patterns when matching regex > > > > osinfo/osinfo_db.c | 2 +- > > tests/test-isodetect.c | 2 ++ > > 2 files changed, 3 insertions(+), 1 deletion(-) > > > > osinfo-db: > > Fabiano Fid?ncio (3): > > altlinux: Fix publisher-id for 4.0 and 4.1 > > win10: Fix volume-id > > openbsd: Fix all publisher-ids > > > > I guess technically this could constitute an API break: if a user has custom > installed db entries and is depending on this behavior, they could see > different results after an update. That said I doubt it's an issue in > practice, and implying ANCHORED mode is the better long term option IMO, so: > > Reviewed-by: Cole Robinson If we want anchored matches, then the osinfo-db regexes should include the "^" and "$" anchors as they see fit. We shouldn't force it in libosinfo API itself. Note that we explicitly allow apps to load & interpret the XML files directly without using libosinfo APIs, which further pushes to using anchors in the XML 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 Thu Oct 4 10:09:31 2018 From: berrange at redhat.com (Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?=) Date: Thu, 4 Oct 2018 11:09:31 +0100 Subject: [Libosinfo] [osinfo-db-tools PATCH 0/1] RFC: Make osinfo-db-import aware of URLs In-Reply-To: <20180925124520.13916-1-fidencio@redhat.com> References: <20180925124520.13916-1-fidencio@redhat.com> Message-ID: <20181004100931.GH3667@redhat.com> On Tue, Sep 25, 2018 at 02:45:19PM +0200, Fabiano Fid?ncio wrote: > This is a simple draft of a work that has been discussed back in July as > part of this thread[0]. > > There are a few things which are not clear to me whether we want (or > whether we do *not* want). > > This work adds a dependency on libcurl (which is not that bad) in order > to download the archive file that would, then, be extracted into the > user's desired location. I thought that GIO included support for https URIs via curl already. Is that not the case ? 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 fidencio at redhat.com Thu Oct 4 10:28:44 2018 From: fidencio at redhat.com (Fabiano =?ISO-8859-1?Q?Fid=EAncio?=) Date: Thu, 04 Oct 2018 12:28:44 +0200 Subject: [Libosinfo] [PATCH libosinfo/osinfo-db 0/5] Force anchored patterns when matching regex In-Reply-To: <20181004100518.GG3667@redhat.com> References: <20180907191859.931-1-fidencio@redhat.com> <20181004100518.GG3667@redhat.com> Message-ID: <33794043ca0b96133af7a7ed51b1fb9e75581e33.camel@redhat.com> On Thu, 2018-10-04 at 11:05 +0100, Daniel P. Berrang? wrote: > On Tue, Sep 11, 2018 at 01:15:26PM -0400, Cole Robinson wrote: > > On 09/07/2018 03:18 PM, Fabiano Fid?ncio wrote: > > > This patch series basically consists in a fix for a possibly > > > always > > > present issue that I've faced Today after adding more data to > > > osinfo-db. > > > > > > Please, take a careful look at "db: Force anchored ..." patch as > > > this is > > > the most important patch of the series. > > > > > > As this change ends up exposing a few more issues on osinfo-db, > > > would be > > > really nice to have the osinfo-db patches merged altogether. > > > > > > It's important to note that the osinfo-db patches themselves are > > > **not** > > > going to break something in case they're used against a "non- > > > patched" > > > libosinfo. > > > > > > Also, the osinfo-db patches will have their commit message edited > > > after > > > the libosinfo patches are pushed, so I can reference the proper > > > commit > > > hash in their commit messages. > > > > > > libosinfo: > > > Fabiano Fid?ncio (2): > > > tests: Expand the arch's parser for isodetect > > > db: Force anchored patterns when matching regex > > > > > > osinfo/osinfo_db.c | 2 +- > > > tests/test-isodetect.c | 2 ++ > > > 2 files changed, 3 insertions(+), 1 deletion(-) > > > > > > osinfo-db: > > > Fabiano Fid?ncio (3): > > > altlinux: Fix publisher-id for 4.0 and 4.1 > > > win10: Fix volume-id > > > openbsd: Fix all publisher-ids > > > > > > > I guess technically this could constitute an API break: if a user > > has custom > > installed db entries and is depending on this behavior, they could > > see > > different results after an update. That said I doubt it's an issue > > in > > practice, and implying ANCHORED mode is the better long term option > > IMO, so: > > > > Reviewed-by: Cole Robinson > > If we want anchored matches, then the osinfo-db regexes should > include the "^" and "$" anchors as they see fit. We shouldn't force > it in libosinfo API itself. Note that we explicitly allow apps to > load & interpret the XML files directly without using libosinfo APIs, > which further pushes to using anchors in the XML So, your preference would be to revert the libosinfo patch and then patch osinfo-db case-by-case? > > Regards, > Daniel From berrange at redhat.com Thu Oct 4 10:29:28 2018 From: berrange at redhat.com (Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?=) Date: Thu, 4 Oct 2018 11:29:28 +0100 Subject: [Libosinfo] [PATCH libosinfo/osinfo-db 0/5] Force anchored patterns when matching regex In-Reply-To: <33794043ca0b96133af7a7ed51b1fb9e75581e33.camel@redhat.com> References: <20180907191859.931-1-fidencio@redhat.com> <20181004100518.GG3667@redhat.com> <33794043ca0b96133af7a7ed51b1fb9e75581e33.camel@redhat.com> Message-ID: <20181004102928.GI3667@redhat.com> On Thu, Oct 04, 2018 at 12:28:44PM +0200, Fabiano Fid?ncio wrote: > On Thu, 2018-10-04 at 11:05 +0100, Daniel P. Berrang? wrote: > > On Tue, Sep 11, 2018 at 01:15:26PM -0400, Cole Robinson wrote: > > > On 09/07/2018 03:18 PM, Fabiano Fid?ncio wrote: > > > > This patch series basically consists in a fix for a possibly > > > > always > > > > present issue that I've faced Today after adding more data to > > > > osinfo-db. > > > > > > > > Please, take a careful look at "db: Force anchored ..." patch as > > > > this is > > > > the most important patch of the series. > > > > > > > > As this change ends up exposing a few more issues on osinfo-db, > > > > would be > > > > really nice to have the osinfo-db patches merged altogether. > > > > > > > > It's important to note that the osinfo-db patches themselves are > > > > **not** > > > > going to break something in case they're used against a "non- > > > > patched" > > > > libosinfo. > > > > > > > > Also, the osinfo-db patches will have their commit message edited > > > > after > > > > the libosinfo patches are pushed, so I can reference the proper > > > > commit > > > > hash in their commit messages. > > > > > > > > libosinfo: > > > > Fabiano Fid?ncio (2): > > > > tests: Expand the arch's parser for isodetect > > > > db: Force anchored patterns when matching regex > > > > > > > > osinfo/osinfo_db.c | 2 +- > > > > tests/test-isodetect.c | 2 ++ > > > > 2 files changed, 3 insertions(+), 1 deletion(-) > > > > > > > > osinfo-db: > > > > Fabiano Fid?ncio (3): > > > > altlinux: Fix publisher-id for 4.0 and 4.1 > > > > win10: Fix volume-id > > > > openbsd: Fix all publisher-ids > > > > > > > > > > I guess technically this could constitute an API break: if a user > > > has custom > > > installed db entries and is depending on this behavior, they could > > > see > > > different results after an update. That said I doubt it's an issue > > > in > > > practice, and implying ANCHORED mode is the better long term option > > > IMO, so: > > > > > > Reviewed-by: Cole Robinson > > > > If we want anchored matches, then the osinfo-db regexes should > > include the "^" and "$" anchors as they see fit. We shouldn't force > > it in libosinfo API itself. Note that we explicitly allow apps to > > load & interpret the XML files directly without using libosinfo APIs, > > which further pushes to using anchors in the XML > > So, your preference would be to revert the libosinfo patch and then > patch osinfo-db case-by-case? Yes, pretty much. 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 fidencio at redhat.com Thu Oct 4 10:29:49 2018 From: fidencio at redhat.com (Fabiano =?ISO-8859-1?Q?Fid=EAncio?=) Date: Thu, 04 Oct 2018 12:29:49 +0200 Subject: [Libosinfo] [osinfo-db-tools PATCH 0/1] RFC: Make osinfo-db-import aware of URLs In-Reply-To: <20181004100931.GH3667@redhat.com> References: <20180925124520.13916-1-fidencio@redhat.com> <20181004100931.GH3667@redhat.com> Message-ID: <65371f9c276551da3eabdca5fbdf788058f8d0f0.camel@redhat.com> On Thu, 2018-10-04 at 11:09 +0100, Daniel P. Berrang? wrote: > On Tue, Sep 25, 2018 at 02:45:19PM +0200, Fabiano Fid?ncio wrote: > > This is a simple draft of a work that has been discussed back in > > July as > > part of this thread[0]. > > > > There are a few things which are not clear to me whether we want > > (or > > whether we do *not* want). > > > > This work adds a dependency on libcurl (which is not that bad) in > > order > > to download the archive file that would, then, be extracted into > > the > > user's desired location. > > I thought that GIO included support for https URIs via curl already. > Is that not the case ? I'll check it and submit a v2. > > > Regards, > Daniel From fidencio at redhat.com Thu Oct 4 10:51:17 2018 From: fidencio at redhat.com (=?UTF-8?q?Fabiano=20Fid=C3=AAncio?=) Date: Thu, 4 Oct 2018 12:51:17 +0200 Subject: [Libosinfo] [libosinfo/osinfo-db PATCH 0/2] Revert e616846 and fix win-10 volume ids Message-ID: <20181004105119.30798-1-fidencio@redhat.com> 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 data/os/microsoft.com/win-10.xml.in | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) -- 2.19.0 From fidencio at redhat.com Thu Oct 4 10:51:18 2018 From: fidencio at redhat.com (=?UTF-8?q?Fabiano=20Fid=C3=AAncio?=) Date: Thu, 4 Oct 2018 12:51:18 +0200 Subject: [Libosinfo] [libosinfo PATCH 1/2] Revert "db: Force anchored patterns when matching regex" In-Reply-To: <20181004105119.30798-1-fidencio@redhat.com> References: <20181004105119.30798-1-fidencio@redhat.com> Message-ID: <20181004105119.30798-2-fidencio@redhat.com> Daniel suggested that the fix should go to the osinfo-db entries that are causing the issue instead of forcing anchored patterns in libosinfo. This reverts commit e6168463f4fc659b9827b5c8694dc1c6d7d5239a. Signed-off-by: Fabiano Fid?ncio --- osinfo/osinfo_db.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/osinfo/osinfo_db.c b/osinfo/osinfo_db.c index f4b3a8c..fa14c6d 100644 --- a/osinfo/osinfo_db.c +++ b/osinfo/osinfo_db.c @@ -37,7 +37,7 @@ G_DEFINE_TYPE(OsinfoDb, osinfo_db, G_TYPE_OBJECT); #define match_regex(pattern, str) \ (((pattern) == NULL) || \ (((str) != NULL) && \ - g_regex_match_simple((pattern), (str), 0, G_REGEX_MATCH_ANCHORED))) + g_regex_match_simple((pattern), (str), 0, 0))) static gchar *get_raw_lang(const char *volume_id, const gchar *regex_str) { -- 2.19.0 From fidencio at redhat.com Thu Oct 4 10:51:19 2018 From: fidencio at redhat.com (=?UTF-8?q?Fabiano=20Fid=C3=AAncio?=) Date: Thu, 4 Oct 2018 12:51:19 +0200 Subject: [Libosinfo] [osinfo-db PATCH 2/2] win10: Anchor some volume-ids In-Reply-To: <20181004105119.30798-1-fidencio@redhat.com> References: <20181004105119.30798-1-fidencio@redhat.com> Message-ID: <20181004105119.30798-3-fidencio@redhat.com> Let's explicitly anchor the beginning of some volume-ids as they can cause a wrong match with some win-8 volume ids. Example: "(J_)?CENN?A_X64FREV" (win-10) can be taken as a match for "HRM_CENNA_X64FREV" (win-8). Signed-off-by: Fabiano Fid?ncio --- data/os/microsoft.com/win-10.xml.in | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/data/os/microsoft.com/win-10.xml.in b/data/os/microsoft.com/win-10.xml.in index c5da3e8..288bc06 100644 --- a/data/os/microsoft.com/win-10.xml.in +++ b/data/os/microsoft.com/win-10.xml.in @@ -48,7 +48,7 @@ - (J_)?CEN?A_X86FREV_ + ^(J_)?CEN?A_X86FREV_ MICROSOFT CORPORATION [[:upper:][:digit:]_]*_([[:upper:]]*-[[:upper:]]*) @@ -56,7 +56,7 @@ - (J_)?CENN?A_X64FREV_ + ^(J_)?CENN?A_X64FREV_ MICROSOFT CORPORATION [[:upper:][:digit:]_]*_([[:upper:]]*-[[:upper:]]*) @@ -101,14 +101,14 @@ - (J_)?CCSN?A_X86FRE_ + ^(J_)?CCSN?A_X86FRE_ MICROSOFT CORPORATION [[:upper:][:digit:]_]*_([[:upper:]]*-[[:upper:]]*) - (J_)?(CCSN?A|C?CCOMA)_X64FREE?_ + ^(J_)?(CCSN?A|C?CCOMA)_X64FREE?_ MICROSOFT CORPORATION [[:upper:][:digit:]_]*_([[:upper:]]*-[[:upper:]]*) -- 2.19.0 From berrange at redhat.com Thu Oct 4 12:36:38 2018 From: berrange at redhat.com (Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?=) Date: Thu, 4 Oct 2018 13:36:38 +0100 Subject: [Libosinfo] [libvirt] domain XML for tracking libosinfo ID In-Reply-To: <20180907142650.GB12467@wheatley> References: <4f516faf-aedf-3776-a838-8c755fd0e36b@redhat.com> <20180905082852.GC3026@redhat.com> <20180905120142.GC11712@wheatley> <20180905143722.GN3026@redhat.com> <20180906130419.GG13497@wheatley> <2a706842-2955-3a44-ebdc-da0c126f376c@redhat.com> <20180907142650.GB12467@wheatley> Message-ID: <20181004123638.GL3667@redhat.com> On Fri, Sep 07, 2018 at 04:26:50PM +0200, Martin Kletzander wrote: > On Thu, Sep 06, 2018 at 10:04:35AM -0400, Cole Robinson wrote: > > On 09/06/2018 09:04 AM, Martin Kletzander wrote: > > > On Wed, Sep 05, 2018 at 03:37:22PM +0100, Daniel P. Berrang? wrote: > > > > On Wed, Sep 05, 2018 at 02:01:42PM +0200, Martin Kletzander wrote: > > > > > On Wed, Sep 05, 2018 at 09:28:52AM +0100, Daniel P. Berrang? wrote: > > > > > > On Tue, Sep 04, 2018 at 03:44:12PM -0400, Cole Robinson wrote: > > > > > > > Right now in virt-manager we only track a VM's OS name (win10, > > > > > fedora28, > > > > > > > etc.) during the VM install phase. This piece of data is important > > > > > > > post-install though: if the user adds a new disk to the VM later, > > > > > we want to > > > > > > > be able to ask libosinfo about what devices the installed OS > > > > > supports, so we > > > > > > > can set optimal defaults, like enabling virtio. > > > > > > > > > > > > > > There isn't any standard libvirt XML field to track this kind of > > > > > info > > > > > > > though, so apps have to invent their own schema. nova and rhev do it > > > > > > > indirectly AFAICT. gnome-boxes does it directly with XML like this: > > > > > > > > > > > > > >?? > > > > > > >???? > > > > xmlns:boxes="https://wiki.gnome.org/Apps/Boxes"> > > > > > > >?????? http://fedoraproject.org/fedora/28 > > > > > > >?????? .... > > > > > > >???? > > > > > > >?? > > > > > > > > > > > > > > I want to add something similar to virt-manager but it seems a > > > > > shame to > > > > > > > invent our own private schema for something that most non-trivial > > > > > virt apps > > > > > > > will want to know about. I was thinking a schema we could > > > > > document with > > > > > > > libosinfo, something like > > > > > > > > > > > > > > > > > > > > >?? > > > > > > xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0"> > > > > > > >???? http://fedoraproject.org/fedora/28 > > > > > > >?? > > > > > > > > > > > > > > > > > > > Yes, I would like to see this standardized under . > > > > > > > > > > > > > > > > Me too and what Cole suggested looks fine. > > > > > > > > It occurs to me that we actually need more than just the os-id value. > > > > > > > > When you query devices for a given OS, you'll often be told that multiple > > > > devices are compatible, and the mgmt app can decide which of them to then > > > > use. > > > > > > > > So if we want consistency when later hotplugging, we should make a record > > > > of which devices we decided to use too, so if the mgmt app changes its > > > > preference, we still know what we originally picked. > > > > > > > > eg to express that we use virtio-net and virtio-blk (even if virtio-scsi > > > > was supported by the OS): > > > > > > > > ? > > > > ??? > > > xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0"> > > > > ????? > > > > ????? > > > > ????? > > > > ??? > > > > ? > > > > > > > > Note, I'm suggesting using an 'id' attribute, rather than naming the > > > > element 'os-id', to be more closely aligned with osinfo schema. > > > > > > > > > > I'm not against that but it is going to take some > > > effort to > > > properly specify what is really meant by that.? The fact that some > > > device model > > > was chosen for a particular device does not necessarily mean that it is > > > requested as the default.? It only means what is actually encoded in the > > > XML > > > already, that is a particular model for a particular device. > > > > > > > Yeah I'm a bit confused by this as well, it's not exactly clear to me > > how we would use or set XML like that for virt-manager, and how other > > apps would be expected to consume it. > > > > That's what I though of when trying to say we need to define the meaning of > that. What might be meaningful is if the user selects a particular *default* > model for new devices (e.g. disks should be IDE by default) then that option > could be honoured when adding a new device of that type (unless requested > otherwise). I'm not sure if that's what Daniel meant by that. Consider libosinfo reports that the guest supports virtio-blk, and virtio-scsi. The mgmt apps decides to use virtio-blk for disks. We should remember that so that when we later add more disks, we default to also using virtio-blk unless the user really wants virtio-scsi instead. 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 crobinso at redhat.com Fri Oct 5 18:00:11 2018 From: crobinso at redhat.com (Cole Robinson) Date: Fri, 5 Oct 2018 14:00:11 -0400 Subject: [Libosinfo] [libosinfo/osinfo-db PATCH 0/2] Revert e616846 and fix win-10 volume ids In-Reply-To: <20181004105119.30798-1-fidencio@redhat.com> References: <20181004105119.30798-1-fidencio@redhat.com> Message-ID: 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 - Cole From crobinso at redhat.com Fri Oct 5 18:30:23 2018 From: crobinso at redhat.com (Cole Robinson) Date: Fri, 5 Oct 2018 14:30:23 -0400 Subject: [Libosinfo] [PATCH osinfo-db v2 2/5] device: Add sound ich9 In-Reply-To: <2309c8b328044cc1b3c638f84572f6140fe9dc0d.camel@redhat.com> References: <55c9b73451e8503a41018559f10412c05981ce11.1538175297.git.crobinso@redhat.com> <2309c8b328044cc1b3c638f84572f6140fe9dc0d.camel@redhat.com> Message-ID: <369a3ce7-0257-3d3e-e2cf-25b0d7dc0c42@redhat.com> On 10/04/2018 03:31 AM, Fabiano Fid?ncio wrote: > On Fri, 2018-09-28 at 18:55 -0400, Cole Robinson wrote: >> Signed-off-by: Cole Robinson >> --- >> data/device/pcisig.com/pci-8086-293e.d/class.xml.in | 8 ++++++++ >> 1 file changed, 8 insertions(+) >> create mode 100644 data/device/pcisig.com/pci-8086- >> 293e.d/class.xml.in >> >> diff --git a/data/device/pcisig.com/pci-8086-293e.d/class.xml.in >> b/data/device/pcisig.com/pci-8086-293e.d/class.xml.in >> new file mode 100644 >> index 0000000..6326a4d >> --- /dev/null >> +++ b/data/device/pcisig.com/pci-8086-293e.d/class.xml.in >> @@ -0,0 +1,8 @@ >> + >> + >> + >> + ich9 >> + audio >> + >> + > > Reviewed-by: Fabiano Fid?ncio > Thanks, I pushed these first 2 - Cole From crobinso at redhat.com Fri Oct 5 18:38:04 2018 From: crobinso at redhat.com (Cole Robinson) Date: Fri, 5 Oct 2018 14:38:04 -0400 Subject: [Libosinfo] [PATCH osinfo-db v2 4/5] os: Add q35/e1000e/ich9 for win2k8r2+ and win7+ In-Reply-To: References: <9a8a6705e6d0ea6bcac6ab496de815ecb4d50ec5.1538175297.git.crobinso@redhat.com> Message-ID: <426647c2-9350-5776-5b6e-13b3f8f1bb90@redhat.com> On 10/04/2018 03:44 AM, Fabiano Fid?ncio wrote: > On Fri, 2018-09-28 at 18:55 -0400, Cole Robinson wrote: >> 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..71a7172 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 >> >> + >> + >> + >> + >> + >> + >> >> >> (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..0ae1868 100644 >> --- a/data/os/microsoft.com/win-7.xml.in >> +++ b/data/os/microsoft.com/win-7.xml.in >> @@ -182,6 +182,9 @@ >> >> >> >> + >> + >> + >> >> >> > > In your cover-letter you stated that this combo (q35+e1000e+ich9) > wasn't extensively tested. May I assume that it was tested on this > case? :-) > It's not so much the combo of q35+e1000e+ich9 specifically, more the combo of windows+q35. I personally haven't done much more than boot testing, but virt stack developers assure me the combo works and there's a lot of user reports. I'll do more testing over the next few working days though - Cole From crobinso at redhat.com Fri Oct 5 18:59:57 2018 From: crobinso at redhat.com (Cole Robinson) Date: Fri, 5 Oct 2018 14:59:57 -0400 Subject: [Libosinfo] [PATCH osinfo-db 0/5 v2] Add q35 devices In-Reply-To: <26ceca03c645fb28c10abaa52c41f9049d7494dc.camel@redhat.com> References: <26ceca03c645fb28c10abaa52c41f9049d7494dc.camel@redhat.com> Message-ID: CCing danpb as well On 10/04/2018 03:26 AM, Fabiano Fid?ncio wrote: > On Fri, 2018-09-28 at 18:55 -0400, Cole Robinson wrote: >> The main goal of this series is to advertise q35 chipset and device >> support for suitable OS. Some details about the individual decisions >> >> * We group q35+ich9+e1000e together. This likely isn't completely >> accurate but in the virt case I think it only makes sense to >> specify the latter two devices when pcie (q35) is present, so >> I went with it. >> >> * We only advertise q35 when virtio1.0 devices are available, on >> linux. >> This definitely isn't accurate, q35 predates virtio1.0 by 8 years >> or >> so, but there's issues combining q35 with legacy virtio, and that's >> the only combo I'll be exploring for virt-manager so other >> scenarios >> my go untested. >> >> * The actual OS+q35 combos are largely untested by me. >> >> v1 posting: >> https://www.redhat.com/archives/libosinfo/2018-August/msg00006.html >> >> v2 changes: >> * Rebased, drop committed patches >> * Rework the chipset device ID and dir structure >> >> >> In the original posting danpb suggested introducing a new >> concept to cover this case, roughly outlined here: >> >> https://www.redhat.com/archives/libosinfo/2018-September/msg00014.html >> >> This posting doesn't add that and instead uses like before, >> but with some changes: >> >> $ cat data/device/qemu.org/chipset-x86_64-q35.d/class.xml.in >> >> >> >> q35 >> chipset.virtual >> >> >> >> >> My justifications for not going the full route: >> >> * It's much more work to add new APIs, test them, document them, etc. >> I'm lazy, but it's also a lot more code to maintain forever. >> >> * Will be harder in the short term for clients as well. virt-manager >> will need to use the new APIs and correctly check that they exist, >> vs just using the existing device APIs. >> >> * I think we should bite the bullet and make the concept >> more fuzzy, since we may want that anyways to model things like >> hyperv features which aren't all strictly devices. >> >> * Eventually we will need to extend the XML schema with some way to >> mark unsupported if a new version of an OS drops support. >> This is already the case with newer windows which doesn't support >> ac97 out of the box, though libosinfo still reports support. If >> we have a separate concept, we will need to duplicate >> that schema and likely libosinfo support to handle that case as >> well. So more work going forward. >> >> >> Now some questions: A quick one: is class=chipset.virtual okay? I >> used .virtual as some day we may want to track actual chipset PCI >> devices for example, like the PCI ID for q35. > > Considering we're going for the approach you suggested, yes, it does > make sense. > >> >> Bigger question: What is the expected way that API users should >> determine if libosinfo supports a particular device? Take USB tablet >> support for example. The qemu usb tablet has this device xml: >> >> >> tablet >> input >> >> >> Ways you can presently search for that device with the API: >> >> - Search for the device ID which is expected to be unique >> - Search for name=tablet which presently is unique. However that's a >> super generic name, and nothing seems to enforce uniqueness >> for devices, so I don't know if we can/should count on that. >> - Search for class=input name=tablet which narrows it a bit > > Boxes takes the second apprach. > It basically gets the list of all supported devices and then does, for > instance: > `find_device_by_prop(supported_devices, DEVICE_PROP_NAME, "virtio- > net")` > >> >> virt-manager for example does the last step. I don't know if that's >> a good idea though, given how generic name is. Do we aim to give >> any guarantees about uniqueness, or that it will never change? >> Is never expected to change? > > With the current codebase, I'd say that although we don' enforce, apps > are already assuming the uniqueness. So, in case it fits your > design choices, we could go for that. > >> >> With that context, let's consider querying chipset. I want to make >> sure this syntax isn't going to make future virt chipset additions >> difficult. Dan's list in the email lays out some other examples: >> >> qemu.org/chipset/i686-q35 >> qemu.org/chipset/x86_64-q35 >> qemu.org/chipset/aarch64/virt >> qemu.org/chipset/riscv/virt >> >> If is expected to be globally unique, we probably don't want >> to use name=q35 incase it clashes with a future pcisig.com , >> another virt stack's chipset, or even qemu q35 for i686. So that >> could >> mean name=x86_64-q35, or even name=qemu-x86_64-q35. That gets ugly >> and >> redundant fast though. > > And here I see that it may not fit your design choices :-) > > Anyways, can't we enforce the arch/platform for this? > > So, for instance ... > > q35 > chipset.virtual > x86_64 > > > > Btw, I don't have a proper understanding on how we use the platform so > far and if someone is in the mood to give a nice explanation, that > would be really welcome! :-) > > In any case, we'd have to expand the "device" schema and have new APIs > for that in order to guarantee we're not matching the wrong device. > Re: platform. I don't think it was expected to be used like that. My understanding is that the platform concept was so an app can ask: 'I have qemu version 5.6.7 on my system, what devices does it support?', and then you could cross reference that with what devices the OS supports, and choose a hardware combo that will work. Problem is, 'what devices does qemu support' is not something that can effectively be tracked in static data. qemu could have support for a feature but it was compiled out. qemu could support a feature on some archs but not others. qemu might support a feature depending on some specific host state (/dev/kvm being available). A qemu feature might be modularized so is only available when a specific sub package is installed. Really libvirt+qemu is the only thing that can tell us what hardware a particular combo supports, and for that we have domcapabilities, although it needs to grow a lot. So if my understanding of the platform concept is correct, then I think it's dead these days. >> >> So IMO the sensible thing would be to enforce uniqueness in two ways: >> 1) the device ID, 2) the set of all device properties. So that would >> lead >> to these 4 configs >> >> >> q35 >> x86_64 >> chipset.virtual >> >> >> q35 >> i686 >> chipset.virtual >> >> >> virt >> aarch64 >> chipset.virtual >> >> >> virt >> riscv >> chipset.virtual >> > > Aha. I should have read the whole e-mail before start answering it. :-/ > >> >> >> The downsides of that: 1) if an app naively searchs for name=q35 they >> may get the wrong result, because it ignored . Easy to misuse. >> > > That's something that should be documented how the apps are expected to > use and that's it, IMHO. > >> 2) There aren't any other examples yet of non-unique so maybe >> it causes other issues. > > True. > >> >> All of that makes me think that the only safe recommendation for apps >> is to search by device id. should be treated largely as >> metadata. >> >> We don't necessarily need to implement all this now, since the q35 >> case >> is fairly straightforward, but we should at least make sure we aren't >> going down the wrong path. > > Please, take my answers with a grain of salt as I do believe that > Daniel should/will want to have his opinion on this series as well. > Yes I would like Dan's feedback as well, on q35 as a class=chipset.virtual , and this uniqueness bit The summary of my thoughts on uniqueness. - If is intended to be unique, we should have an idea of how to format fields to avoid collisions and start moving towards it. Maybe make them something closer to what lsusb/lspci prints, full human readable strings. For x86 q35 for example this could be like 'QEMU Chipset q35 x86_64'. This uniqueness should also be enforced somewhere - If is not intended to be unique, we should document that matching on device ID is the safest way to avoid accidental matches, and all other fields are just for filtering and cannot be relied upon for uniqueness. And probably file bugs against all libosinfo using apps to switch to this method when looking for specific device support. FWIW I switched to this method in virt-manager upstream because it's safe regardless, example: https://github.com/virt-manager/virt-manager/blob/a4097b7691bce9367ef3ffeca2ed3124399df918/virtinst/osdict.py#L382 Thanks, Cole From fidencio at redhat.com Mon Oct 8 08:59:05 2018 From: fidencio at redhat.com (=?UTF-8?q?Fabiano=20Fid=C3=AAncio?=) Date: Mon, 8 Oct 2018 10:59:05 +0200 Subject: [Libosinfo] [osinfo-db-tools PATCH v2 0/2] RFC: Make osinfo-db-import aware of URLs Message-ID: <20181008085907.16367-1-fidencio@redhat.com> This is a simple draft of a work that has been discussed back in July as part of this thread[0]. There are a few things which are not clear to me whether we want (or whether we do *not* want). For now I'm not using any progress callback to print the download status and I don't even know whether it would be desired to have. But this is something that could be easily done. Also, for now the operation is synchronous and there's no cancellable used ... but that's something that could be changed (although I don't see the need for that right now). In order to give it a try, please, just build our source with the patch included and try: ./tools/osinfo-db-import https://releases.pagure.org/libosinfo/osinfo-db-20180920.tar.xz ./tools/osinfo-db-import https://foo.bar/foo.bar.tar.xz [0]: https://www.redhat.com/archives/libosinfo/2018-July/msg00002.html Changes since v1: - Use Gio instead of curl; - An additional patch removing a unused var; Fabiano Fid?ncio (2): import: Learn how to deal with URLs import: Remove unused variable tools/osinfo-db-import.c | 91 ++++++++++++++++++++++++++++++++++++---- 1 file changed, 84 insertions(+), 7 deletions(-) -- 2.19.1 From fidencio at redhat.com Mon Oct 8 08:59:06 2018 From: fidencio at redhat.com (=?UTF-8?q?Fabiano=20Fid=C3=AAncio?=) Date: Mon, 8 Oct 2018 10:59:06 +0200 Subject: [Libosinfo] [osinfo-db-tools PATCH v2 1/2] import: Learn how to deal with URLs In-Reply-To: <20181008085907.16367-1-fidencio@redhat.com> References: <20181008085907.16367-1-fidencio@redhat.com> Message-ID: <20181008085907.16367-2-fidencio@redhat.com> Signed-off-by: Fabiano Fid?ncio --- tools/osinfo-db-import.c | 88 ++++++++++++++++++++++++++++++++++++++-- 1 file changed, 84 insertions(+), 4 deletions(-) diff --git a/tools/osinfo-db-import.c b/tools/osinfo-db-import.c index 0d0bdd9..289a85d 100644 --- a/tools/osinfo-db-import.c +++ b/tools/osinfo-db-import.c @@ -135,6 +135,55 @@ static GFile *osinfo_db_import_get_file(GFile *target, return g_file_resolve_relative_path(target, tmp); } +static int +osinfo_db_import_download_file(const gchar *url, + gchar **source_file) +{ + GFile *in = NULL; + GFile *out = NULL; + GError *err = NULL; + gchar *filename = NULL; + GFileCopyFlags flags = G_FILE_COPY_OVERWRITE | G_FILE_COPY_BACKUP; + int ret = -1; + + in = g_file_new_for_uri(url); + if (in == NULL) + return -1; + + filename = g_file_get_basename(in); + if (filename == NULL) + goto cleanup; + + *source_file = g_strdup_printf("%s/%s", g_get_user_cache_dir(), filename); + if (*source_file == NULL) + goto cleanup; + + out = g_file_new_for_path(*source_file); + if (out == NULL) + goto cleanup; + + if (!g_file_copy(in, out, flags, NULL, NULL, NULL, &err)) { + g_printerr("Could not download the \"%s\" file: %s\n", + url, err->message); + goto cleanup; + } + + ret = 0; + + cleanup: + g_free(filename); + if (in != NULL) + g_object_unref(in); + if (out != NULL) + g_object_unref(out); + if (err != NULL) + g_error_free(err); + if (ret != 0) + unlink(*source_file); + + return ret; +} + static int osinfo_db_import_extract(GFile *target, const char *source, gboolean verbose) @@ -145,6 +194,8 @@ static int osinfo_db_import_extract(GFile *target, int r; GFile *file = NULL; GError *err = NULL; + gchar *source_file = NULL; + const gchar *uri_schemes[] = {"ftp", "http", NULL}; arc = archive_read_new(); @@ -154,9 +205,37 @@ static int osinfo_db_import_extract(GFile *target, if (source != NULL && g_str_equal(source, "-")) source = NULL; - if ((r = archive_read_open_filename(arc, source, 10240)) != ARCHIVE_OK) { + if (source != NULL) { + gboolean download_file = FALSE; + + file = g_file_new_for_uri(source); + if (file == NULL) + goto cleanup; + + /* The supported uri schemes here are "ftp", "http" and "https". + * However, "https" is not set as part of the array as it matches with + * "http". */ + for (gint i = 0; uri_schemes[i] != NULL; i++) { + if (g_file_has_uri_scheme(file, uri_schemes[i])) { + download_file = TRUE; + break; + } + } + + if (download_file) { + if (osinfo_db_import_download_file(source, &source_file) < 0) + goto cleanup; + } else { + source_file = g_strdup(source); + } + + if (source_file == NULL) + goto cleanup; + } + + if ((r = archive_read_open_filename(arc, source_file, 10240)) != ARCHIVE_OK) { g_printerr("%s: cannot open archive %s: %s\n", - argv0, source, archive_error_string(arc)); + argv0, source_file, archive_error_string(arc)); goto cleanup; } @@ -166,7 +245,7 @@ static int osinfo_db_import_extract(GFile *target, break; if (r != ARCHIVE_OK) { g_printerr("%s: cannot read next archive entry in %s: %s\n", - argv0, source, archive_error_string(arc)); + argv0, source_file, archive_error_string(arc)); goto cleanup; } @@ -180,7 +259,7 @@ static int osinfo_db_import_extract(GFile *target, if (archive_read_close(arc) != ARCHIVE_OK) { g_printerr("%s: cannot finish reading archive %s: %s\n", - argv0, source, archive_error_string(arc)); + argv0, source_file, archive_error_string(arc)); goto cleanup; } @@ -191,6 +270,7 @@ static int osinfo_db_import_extract(GFile *target, g_error_free(err); if (file) g_object_unref(file); + g_free(source_file); return ret; } -- 2.19.1 From fidencio at redhat.com Mon Oct 8 08:59:07 2018 From: fidencio at redhat.com (=?UTF-8?q?Fabiano=20Fid=C3=AAncio?=) Date: Mon, 8 Oct 2018 10:59:07 +0200 Subject: [Libosinfo] [osinfo-db-tools PATCH v2 2/2] import: Remove unused variable In-Reply-To: <20181008085907.16367-1-fidencio@redhat.com> References: <20181008085907.16367-1-fidencio@redhat.com> Message-ID: <20181008085907.16367-3-fidencio@redhat.com> Signed-off-by: Fabiano Fid?ncio --- tools/osinfo-db-import.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/tools/osinfo-db-import.c b/tools/osinfo-db-import.c index 289a85d..c0b4931 100644 --- a/tools/osinfo-db-import.c +++ b/tools/osinfo-db-import.c @@ -193,7 +193,6 @@ static int osinfo_db_import_extract(GFile *target, int ret = -1; int r; GFile *file = NULL; - GError *err = NULL; gchar *source_file = NULL; const gchar *uri_schemes[] = {"ftp", "http", NULL}; @@ -266,8 +265,6 @@ static int osinfo_db_import_extract(GFile *target, ret = 0; cleanup: archive_read_free(arc); - if (err) - g_error_free(err); if (file) g_object_unref(file); g_free(source_file); -- 2.19.1 From didier.roche at canonical.com Mon Oct 8 10:26:51 2018 From: didier.roche at canonical.com (Didier Roche) Date: Mon, 8 Oct 2018 12:26:51 +0200 Subject: [Libosinfo] [Patch] bump default ubuntu RAM size Message-ID: <2749ae8c-37a0-8c4a-575c-30f23478e8d3@canonical.com> Hey! I have a patch to fix the RAM requirement on ubuntu (for 16.04, 18.04 and 18.10) that I pushed at https://gitlab.com/didrocks/osinfo-db/commit/67d8b0a34771b0e0aa8736cb707f8028e82c0bf3. As this is only one commit, I have enclosed a git format patch version to that email. What triggered that discussion was https://bugs.launchpad.net/ubuntu/+source/osinfo-db/+bug/1796037, which makes the default RAM size not being able to install ubuntu. The ubuntu desktop team decided to bump the requirement to 2Gb (which was the GNOME Boxes fallback for those versions when the file definition wasn't included). Thanks a lot in advance. Cheers, Didier -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Bump-minimal-ram-requirement-for-ubuntu-to-2Gb.patch Type: text/x-patch Size: 2620 bytes Desc: not available URL: From cfergeau at redhat.com Mon Oct 8 11:05:37 2018 From: cfergeau at redhat.com (Christophe Fergeau) Date: Mon, 8 Oct 2018 13:05:37 +0200 Subject: [Libosinfo] [Patch] bump default ubuntu RAM size In-Reply-To: <2749ae8c-37a0-8c4a-575c-30f23478e8d3@canonical.com> References: <2749ae8c-37a0-8c4a-575c-30f23478e8d3@canonical.com> Message-ID: <20181008110537.GC4479@natto.ory.fergeau.eu> Hey, On Mon, Oct 08, 2018 at 12:26:51PM +0200, Didier Roche wrote: > Hey! > > I have a patch to fix the RAM requirement on ubuntu (for 16.04, 18.04 and > 18.10) that I pushed at https://gitlab.com/didrocks/osinfo-db/commit/67d8b0a34771b0e0aa8736cb707f8028e82c0bf3. > As this is only one commit, I have enclosed a git format patch version to > that email. > > What triggered that discussion was > https://bugs.launchpad.net/ubuntu/+source/osinfo-db/+bug/1796037, which > makes the default RAM size not being able to install ubuntu. The ubuntu > desktop team decided to bump the requirement to 2Gb (which was the GNOME > Boxes fallback for those versions when the file definition wasn't included). The minimum was changed by https://help.ubuntu.com/community/Installation/SystemRequirements?action=diff&rev2=108&rev1=107 about 1 year ago. My understanding is that the minimum is 2GiB while the recommendation is 4GiB? (I'm unsure how to read the 4GiB mentioned in that page ;) Is 16.04 impacted by these changes in memory requirements though? Christophe > > Thanks a lot in advance. > Cheers, > Didier > > >From 67d8b0a34771b0e0aa8736cb707f8028e82c0bf3 Mon Sep 17 00:00:00 2001 > From: Didier Roche > Date: Mon, 8 Oct 2018 12:08:05 +0200 > Subject: [PATCH] Bump minimal ram requirement for ubuntu to 2Gb > > The ubuntu images needs 2Gb to end their installation process with > pre-seeded snap. Otherwise, the machine OOM and deadlock during install. > We weren't impacted previously as shipping an old osinfo-db version, > which didn't have the distribution specific requirements, and thus, > fallbacked to GNOME Boxes default which is 2Gb. > --- > data/os/ubuntu.com/ubuntu-16.04.xml.in | 4 ++-- > data/os/ubuntu.com/ubuntu-18.04.xml.in | 4 ++-- > data/os/ubuntu.com/ubuntu-18.10.xml.in | 4 ++-- > 3 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/data/os/ubuntu.com/ubuntu-16.04.xml.in b/data/os/ubuntu.com/ubuntu-16.04.xml.in > index 0a0936f..1281ca1 100644 > --- a/data/os/ubuntu.com/ubuntu-16.04.xml.in > +++ b/data/os/ubuntu.com/ubuntu-16.04.xml.in > @@ -20,12 +20,12 @@ > > 1000000000 > 1 > - 1073741824 > + 2147483648 > 5368709120 > > > 1000000000 > - 1073741824 > + 2147483648 > 16106127360 > > > diff --git a/data/os/ubuntu.com/ubuntu-18.04.xml.in b/data/os/ubuntu.com/ubuntu-18.04.xml.in > index 2903f11..33bd5cf 100644 > --- a/data/os/ubuntu.com/ubuntu-18.04.xml.in > +++ b/data/os/ubuntu.com/ubuntu-18.04.xml.in > @@ -21,12 +21,12 @@ > > 1000000000 > 1 > - 1073741824 > + 2147483648 > 5368709120 > > > 1000000000 > - 1073741824 > + 2147483648 > 16106127360 > > > diff --git a/data/os/ubuntu.com/ubuntu-18.10.xml.in b/data/os/ubuntu.com/ubuntu-18.10.xml.in > index 1fd6e20..73e0b52 100644 > --- a/data/os/ubuntu.com/ubuntu-18.10.xml.in > +++ b/data/os/ubuntu.com/ubuntu-18.10.xml.in > @@ -22,12 +22,12 @@ > > 1000000000 > 1 > - 1073741824 > + 2147483648 > 5368709120 > > > 1000000000 > - 1073741824 > + 2147483648 > 16106127360 > > > -- > 2.17.1 > > _______________________________________________ > Libosinfo mailing list > Libosinfo at redhat.com > https://www.redhat.com/mailman/listinfo/libosinfo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From didier.roche at canonical.com Mon Oct 8 11:12:12 2018 From: didier.roche at canonical.com (Didier Roche) Date: Mon, 8 Oct 2018 13:12:12 +0200 Subject: [Libosinfo] [Patch] bump default ubuntu RAM size In-Reply-To: <20181008110537.GC4479@natto.ory.fergeau.eu> References: <2749ae8c-37a0-8c4a-575c-30f23478e8d3@canonical.com> <20181008110537.GC4479@natto.ory.fergeau.eu> Message-ID: <77950785-71a6-4c48-9197-b65513cf81c2@canonical.com> Le 08/10/2018 ? 13:05, Christophe Fergeau a ?crit?: > Hey, Hey Christophe, > > On Mon, Oct 08, 2018 at 12:26:51PM +0200, Didier Roche wrote: >> Hey! >> >> I have a patch to fix the RAM requirement on ubuntu (for 16.04, 18.04 and >> 18.10) that I pushed at https://gitlab.com/didrocks/osinfo-db/commit/67d8b0a34771b0e0aa8736cb707f8028e82c0bf3. >> As this is only one commit, I have enclosed a git format patch version to >> that email. >> >> What triggered that discussion was >> https://bugs.launchpad.net/ubuntu/+source/osinfo-db/+bug/1796037, which >> makes the default RAM size not being able to install ubuntu. The ubuntu >> desktop team decided to bump the requirement to 2Gb (which was the GNOME >> Boxes fallback for those versions when the file definition wasn't included). > The minimum was changed by https://help.ubuntu.com/community/Installation/SystemRequirements?action=diff&rev2=108&rev1=107 > about 1 year ago. My understanding is that the minimum is 2GiB while the > recommendation is 4GiB? (I'm unsure how to read the 4GiB mentioned in > that page ;) > Is 16.04 impacted by these changes in memory requirements though? 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? Didier > > Christophe > >> Thanks a lot in advance. >> Cheers, >> Didier >> >> >From 67d8b0a34771b0e0aa8736cb707f8028e82c0bf3 Mon Sep 17 00:00:00 2001 >> From: Didier Roche >> Date: Mon, 8 Oct 2018 12:08:05 +0200 >> Subject: [PATCH] Bump minimal ram requirement for ubuntu to 2Gb >> >> The ubuntu images needs 2Gb to end their installation process with >> pre-seeded snap. Otherwise, the machine OOM and deadlock during install. >> We weren't impacted previously as shipping an old osinfo-db version, >> which didn't have the distribution specific requirements, and thus, >> fallbacked to GNOME Boxes default which is 2Gb. >> --- >> data/os/ubuntu.com/ubuntu-16.04.xml.in | 4 ++-- >> data/os/ubuntu.com/ubuntu-18.04.xml.in | 4 ++-- >> data/os/ubuntu.com/ubuntu-18.10.xml.in | 4 ++-- >> 3 files changed, 6 insertions(+), 6 deletions(-) >> >> diff --git a/data/os/ubuntu.com/ubuntu-16.04.xml.in b/data/os/ubuntu.com/ubuntu-16.04.xml.in >> index 0a0936f..1281ca1 100644 >> --- a/data/os/ubuntu.com/ubuntu-16.04.xml.in >> +++ b/data/os/ubuntu.com/ubuntu-16.04.xml.in >> @@ -20,12 +20,12 @@ >> >> 1000000000 >> 1 >> - 1073741824 >> + 2147483648 >> 5368709120 >> >> >> 1000000000 >> - 1073741824 >> + 2147483648 >> 16106127360 >> >> >> diff --git a/data/os/ubuntu.com/ubuntu-18.04.xml.in b/data/os/ubuntu.com/ubuntu-18.04.xml.in >> index 2903f11..33bd5cf 100644 >> --- a/data/os/ubuntu.com/ubuntu-18.04.xml.in >> +++ b/data/os/ubuntu.com/ubuntu-18.04.xml.in >> @@ -21,12 +21,12 @@ >> >> 1000000000 >> 1 >> - 1073741824 >> + 2147483648 >> 5368709120 >> >> >> 1000000000 >> - 1073741824 >> + 2147483648 >> 16106127360 >> >> >> diff --git a/data/os/ubuntu.com/ubuntu-18.10.xml.in b/data/os/ubuntu.com/ubuntu-18.10.xml.in >> index 1fd6e20..73e0b52 100644 >> --- a/data/os/ubuntu.com/ubuntu-18.10.xml.in >> +++ b/data/os/ubuntu.com/ubuntu-18.10.xml.in >> @@ -22,12 +22,12 @@ >> >> 1000000000 >> 1 >> - 1073741824 >> + 2147483648 >> 5368709120 >> >> >> 1000000000 >> - 1073741824 >> + 2147483648 >> 16106127360 >> >> >> -- >> 2.17.1 >> >> _______________________________________________ >> Libosinfo mailing list >> Libosinfo at redhat.com >> https://www.redhat.com/mailman/listinfo/libosinfo From fidencio at redhat.com Mon Oct 8 11:21:01 2018 From: fidencio at redhat.com (Fabiano =?ISO-8859-1?Q?Fid=EAncio?=) Date: Mon, 08 Oct 2018 13:21:01 +0200 Subject: [Libosinfo] [Patch] bump default ubuntu RAM size In-Reply-To: <77950785-71a6-4c48-9197-b65513cf81c2@canonical.com> References: <2749ae8c-37a0-8c4a-575c-30f23478e8d3@canonical.com> <20181008110537.GC4479@natto.ory.fergeau.eu> <77950785-71a6-4c48-9197-b65513cf81c2@canonical.com> Message-ID: On Mon, 2018-10-08 at 13:12 +0200, Didier Roche wrote: > Le 08/10/2018 ? 13:05, Christophe Fergeau a ?crit : > > Hey, > > Hey Christophe, > > On Mon, Oct 08, 2018 at 12:26:51PM +0200, Didier Roche wrote: > > > Hey! > > > > > > I have a patch to fix the RAM requirement on ubuntu (for 16.04, > > > 18.04 and > > > 18.10) that I pushed at > > > https://gitlab.com/didrocks/osinfo-db/commit/67d8b0a34771b0e0aa8736cb707f8028e82c0bf3 > > > . > > > As this is only one commit, I have enclosed a git format patch > > > version to > > > that email. > > > > > > What triggered that discussion was > > > https://bugs.launchpad.net/ubuntu/+source/osinfo-db/+bug/1796037, > > > which > > > makes the default RAM size not being able to install ubuntu. The > > > ubuntu > > > desktop team decided to bump the requirement to 2Gb (which was > > > the GNOME > > > Boxes fallback for those versions when the file definition wasn't > > > included). > > The minimum was changed by > > https://help.ubuntu.com/community/Installation/SystemRequirements?action=diff&rev2=108&rev1=107 > > about 1 year ago. My understanding is that the minimum is 2GiB > > while the > > recommendation is 4GiB? (I'm unsure how to read the 4GiB mentioned > > in > > that page ;) > > Is 16.04 impacted by these changes in memory requirements though? > > 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. > Didier > > Christophe > > > > > Thanks a lot in advance. > > > Cheers, > > > Didier > > > > > > > From 67d8b0a34771b0e0aa8736cb707f8028e82c0bf3 Mon Sep 17 > > > > 00:00:00 2001 > > > From: Didier Roche > > > Date: Mon, 8 Oct 2018 12:08:05 +0200 > > > Subject: [PATCH] Bump minimal ram requirement for ubuntu to 2Gb > > > > > > The ubuntu images needs 2Gb to end their installation process > > > with > > > pre-seeded snap. Otherwise, the machine OOM and deadlock during > > > install. > > > We weren't impacted previously as shipping an old osinfo-db > > > version, > > > which didn't have the distribution specific requirements, and > > > thus, > > > fallbacked to GNOME Boxes default which is 2Gb. > > > --- > > > data/os/ubuntu.com/ubuntu-16.04.xml.in | 4 ++-- > > > data/os/ubuntu.com/ubuntu-18.04.xml.in | 4 ++-- > > > data/os/ubuntu.com/ubuntu-18.10.xml.in | 4 ++-- > > > 3 files changed, 6 insertions(+), 6 deletions(-) > > > > > > diff --git a/data/os/ubuntu.com/ubuntu-16.04.xml.in > > > b/data/os/ubuntu.com/ubuntu-16.04.xml.in > > > index 0a0936f..1281ca1 100644 > > > --- a/data/os/ubuntu.com/ubuntu-16.04.xml.in > > > +++ b/data/os/ubuntu.com/ubuntu-16.04.xml.in > > > @@ -20,12 +20,12 @@ > > > > > > 1000000000 > > > 1 > > > - 1073741824 > > > + 2147483648 > > > 5368709120 > > > > > > > > > 1000000000 > > > - 1073741824 > > > + 2147483648 > > > 16106127360 > > > > > > > > > diff --git a/data/os/ubuntu.com/ubuntu-18.04.xml.in > > > b/data/os/ubuntu.com/ubuntu-18.04.xml.in > > > index 2903f11..33bd5cf 100644 > > > --- a/data/os/ubuntu.com/ubuntu-18.04.xml.in > > > +++ b/data/os/ubuntu.com/ubuntu-18.04.xml.in > > > @@ -21,12 +21,12 @@ > > > > > > 1000000000 > > > 1 > > > - 1073741824 > > > + 2147483648 > > > 5368709120 > > > > > > > > > 1000000000 > > > - 1073741824 > > > + 2147483648 > > > 16106127360 > > > > > > > > > diff --git a/data/os/ubuntu.com/ubuntu-18.10.xml.in > > > b/data/os/ubuntu.com/ubuntu-18.10.xml.in > > > index 1fd6e20..73e0b52 100644 > > > --- a/data/os/ubuntu.com/ubuntu-18.10.xml.in > > > +++ b/data/os/ubuntu.com/ubuntu-18.10.xml.in > > > @@ -22,12 +22,12 @@ > > > > > > 1000000000 > > > 1 > > > - 1073741824 > > > + 2147483648 > > > 5368709120 > > > > > > > > > 1000000000 > > > - 1073741824 > > > + 2147483648 > > > 16106127360 > > > > > > > > > -- > > > 2.17.1 > > > > > > _______________________________________________ > > > Libosinfo mailing list > > > Libosinfo at redhat.com > > > https://www.redhat.com/mailman/listinfo/libosinfo > > _______________________________________________ > Libosinfo mailing list > Libosinfo at redhat.com > https://www.redhat.com/mailman/listinfo/libosinfo From fidencio at redhat.com Mon Oct 8 13:09:24 2018 From: fidencio at redhat.com (Fabiano =?ISO-8859-1?Q?Fid=EAncio?=) Date: Mon, 08 Oct 2018 15:09:24 +0200 Subject: [Libosinfo] [libosinfo/osinfo-db PATCH 0/2] Revert e616846 and fix win-10 volume ids In-Reply-To: References: <20181004105119.30798-1-fidencio@redhat.com> Message-ID: 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. > > - Cole From fidencio at redhat.com Mon Oct 8 13:41:49 2018 From: fidencio at redhat.com (=?UTF-8?q?Fabiano=20Fid=C3=AAncio?=) Date: Mon, 8 Oct 2018 15:41:49 +0200 Subject: [Libosinfo] [osinfo-db-tools PATCH] authors, maintainers: Add all gitlab's group members Message-ID: <20181008134149.9388-1-fidencio@redhat.com> 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(-) diff --git a/AUTHORS.in b/AUTHORS.in index 397100c..85cadc6 100644 --- a/AUTHORS.in +++ b/AUTHORS.in @@ -3,8 +3,14 @@ Current maintainers: - Zeeshan Ali (Khattak) + Christophe Fergeau + Cole Robinson Daniel P. Berrange + Fabiano Fid?ncio + Guido G?nther + Marc-Andr? Lureau + Pino Toscano + Zeeshan Ali (Khattak) Patches contributed by: diff --git a/MAINTAINERS b/MAINTAINERS index f5da6d5..3d35c1c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1,2 +1,8 @@ +Christophe Fergeau +Cole Robinson Daniel P. Berrange +Fabiano Fid?ncio +Guido G?nther +Marc-Andr? Lureau +Pino Toscano Zeeshan Ali (Khattak) -- 2.19.1 From fidencio at redhat.com Mon Oct 8 13:42:04 2018 From: fidencio at redhat.com (=?UTF-8?q?Fabiano=20Fid=C3=AAncio?=) Date: Mon, 8 Oct 2018 15:42:04 +0200 Subject: [Libosinfo] [libosinfo PATCH] authors, maintainers: Add all gitlab's group members Message-ID: <20181008134204.9451-1-fidencio@redhat.com> 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(-) diff --git a/AUTHORS.in b/AUTHORS.in index 1f7ca5c..0dfd2da 100644 --- a/AUTHORS.in +++ b/AUTHORS.in @@ -3,8 +3,14 @@ Current maintainers: - Zeeshan Ali (Khattak) + Christophe Fergeau + Cole Robinson Daniel P. Berrange + Fabiano Fid?ncio + Guido G?nther + Marc-Andr? Lureau + Pino Toscano + Zeeshan Ali (Khattak) Previous maintainers: diff --git a/MAINTAINERS b/MAINTAINERS index f5da6d5..3d35c1c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1,2 +1,8 @@ +Christophe Fergeau +Cole Robinson Daniel P. Berrange +Fabiano Fid?ncio +Guido G?nther +Marc-Andr? Lureau +Pino Toscano Zeeshan Ali (Khattak) -- 2.19.1 From didier.roche at canonical.com Mon Oct 8 14:25:21 2018 From: didier.roche at canonical.com (Didier Roche) Date: Mon, 8 Oct 2018 16:25:21 +0200 Subject: [Libosinfo] [Patch] bump default ubuntu RAM size In-Reply-To: References: <2749ae8c-37a0-8c4a-575c-30f23478e8d3@canonical.com> <20181008110537.GC4479@natto.ory.fergeau.eu> <77950785-71a6-4c48-9197-b65513cf81c2@canonical.com> Message-ID: 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&rev2=110&rev1=109. I hope that facilitate that patch which is increasing a non working configuration. Keep me posted. Cheers, Didier From fidencio at redhat.com Mon Oct 8 15:15:55 2018 From: fidencio at redhat.com (=?UTF-8?q?Fabiano=20Fid=C3=AAncio?=) Date: Mon, 8 Oct 2018 17:15:55 +0200 Subject: [Libosinfo] [osinfo-db, libosinfo PATCH 0/5] Add Fedora29 / Silverblue 29 (Beta) info Message-ID: <20181008151600.20800-1-fidencio@redhat.com> 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 From fidencio at redhat.com Mon Oct 8 15:15:56 2018 From: fidencio at redhat.com (=?UTF-8?q?Fabiano=20Fid=C3=AAncio?=) Date: Mon, 8 Oct 2018 17:15:56 +0200 Subject: [Libosinfo] [osinfo-db PATCH 1/5] fedora: Add fedora29 (Beta) info In-Reply-To: <20181008151600.20800-1-fidencio@redhat.com> References: <20181008151600.20800-1-fidencio@redhat.com> Message-ID: <20181008151600.20800-2-fidencio@redhat.com> Signed-off-by: Fabiano Fid?ncio --- data/os/fedoraproject.org/fedora-29.xml.in | 124 +++++++++++++++++++++ 1 file changed, 124 insertions(+) create mode 100644 data/os/fedoraproject.org/fedora-29.xml.in diff --git a/data/os/fedoraproject.org/fedora-29.xml.in b/data/os/fedoraproject.org/fedora-29.xml.in new file mode 100644 index 0000000..f4d1c53 --- /dev/null +++ b/data/os/fedoraproject.org/fedora-29.xml.in @@ -0,0 +1,124 @@ + + + + fedora29 + <_name>Fedora 29 + 29 + <_vendor>Fedora Project + linux + fedora + + + + prerelease + + + <_name>Fedora 29 Workstation + + + <_name>Fedora 29 Workstation + + + <_name>Fedora 29 Server + + + <_name>Fedora 29 Server + + + + + + + + https://download.fedoraproject.org/pub/fedora/linux/releases/test/29_Beta/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-29_Beta-1.5.iso + + Fedora-WS-Live-29.* + LINUX + + isolinux/vmlinuz + isolinux/initrd.img + + + + + + https://download.fedoraproject.org/pub/fedora/linux/releases/test/29_Beta/Workstation/x86_64/iso/Fedora-Workstation-netinst-x86_64-29_Beta-1.5.iso + + Fedora-WS-dvd-x86_64-29 + LINUX + + isolinux/vmlinuz + isolinux/initrd.img + + + + + + + + https://download.fedoraproject.org/pub/fedora/linux/releases/test/29_Beta/Server/x86_64/iso/Fedora-Server-dvd-x86_64-29_Beta-1.5.iso + + Fedora-S-dvd-x86_64-29 + LINUX + 3001020416 + + isolinux/vmlinuz + isolinux/initrd.img + + + + + + https://download.fedoraproject.org/pub/fedora/linux/releases/test/29_Beta/Server/x86_64/iso/Fedora-Server-netinst-x86_64-29_Beta-1.5.iso + + Fedora-S-dvd-x86_64-29 + LINUX + 622301184 + + isolinux/vmlinuz + isolinux/initrd.img + + + + https://download.fedoraproject.org/pub/fedora/linux/releases/test/29_Beta/Workstation/x86_64/os + + + Fedora + 29 + x86_64 + + + + + https://download.fedoraproject.org/pub/fedora/linux/releases/test/29_Beta/Server/x86_64/os + + + Fedora + 29 + x86_64 + + + + + + + + 1 + 1000000000 + 1073741824 + 10737418240 + + + + 2147483648 + 21474836480 + + + + +