From cfergeau at redhat.com Mon Jul 2 09:39:02 2018 From: cfergeau at redhat.com (Christophe Fergeau) Date: Mon, 2 Jul 2018 11:39:02 +0200 Subject: [Libosinfo] [PATCH libosinfo] freebsd: add FreeBSD 11.2 isodata In-Reply-To: <20180630133436.59254-1-bogorodskiy@gmail.com> References: <20180630133436.59254-1-bogorodskiy@gmail.com> Message-ID: <20180702093902.GB32053@natto.ory.fergeau.eu> Acked-by: Christophe Fergeau On Sat, Jun 30, 2018 at 05:34:36PM +0400, Roman Bogorodskiy wrote: > Signed-off-by: Roman Bogorodskiy > --- > .../FreeBSD-11.2-RELEASE-amd64-disc1.iso.txt | 33 +++++++++++++++++++ > .../FreeBSD-11.2-RELEASE-amd64-dvd1.iso.txt | 33 +++++++++++++++++++ > .../FreeBSD-11.2-RELEASE-i386-disc1.iso.txt | 33 +++++++++++++++++++ > .../FreeBSD-11.2-RELEASE-i386-dvd1.iso.txt | 33 +++++++++++++++++++ > 4 files changed, 132 insertions(+) > create mode 100644 tests/isodata/freebsd/freebsd11.2/FreeBSD-11.2-RELEASE-amd64-disc1.iso.txt > create mode 100644 tests/isodata/freebsd/freebsd11.2/FreeBSD-11.2-RELEASE-amd64-dvd1.iso.txt > create mode 100644 tests/isodata/freebsd/freebsd11.2/FreeBSD-11.2-RELEASE-i386-disc1.iso.txt > create mode 100644 tests/isodata/freebsd/freebsd11.2/FreeBSD-11.2-RELEASE-i386-dvd1.iso.txt > > diff --git a/tests/isodata/freebsd/freebsd11.2/FreeBSD-11.2-RELEASE-amd64-disc1.iso.txt b/tests/isodata/freebsd/freebsd11.2/FreeBSD-11.2-RELEASE-amd64-disc1.iso.txt > new file mode 100644 > index 0000000..8b887fd > --- /dev/null > +++ b/tests/isodata/freebsd/freebsd11.2/FreeBSD-11.2-RELEASE-amd64-disc1.iso.txt > @@ -0,0 +1,33 @@ > +CD-ROM is in ISO 9660 format > +System id: FreeBSD > +Volume id: 11_2_RELEASE_AMD64_CD > +Volume set id: > +Publisher id: THE FREEBSD PROJECT. HTTP://WWW.FREEBSD.ORG/ > +Data preparer id: > +Application id: > +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: 342412 > +El Torito VD version 1 found, boot catalog is in sector 19 > +NO Joliet present > + > +SUSP signatures version 1 found > +Rock Ridge signatures version 1 found > +Rock Ridge id 'IEEE_P1282' > +Eltorito validation header: > + Hid 1 > + Arch 0 (x86) > + ID '' > + Cksum AA 55 OK > + Key 55 AA > + Eltorito defaultboot header: > + Bootid 88 (bootable) > + Boot media 0 (No Emulation Boot) > + Load segment 0 > + Sys type 0 > + Nsect 4 > + Bootoff 1A4 420 > diff --git a/tests/isodata/freebsd/freebsd11.2/FreeBSD-11.2-RELEASE-amd64-dvd1.iso.txt b/tests/isodata/freebsd/freebsd11.2/FreeBSD-11.2-RELEASE-amd64-dvd1.iso.txt > new file mode 100644 > index 0000000..e13bdae > --- /dev/null > +++ b/tests/isodata/freebsd/freebsd11.2/FreeBSD-11.2-RELEASE-amd64-dvd1.iso.txt > @@ -0,0 +1,33 @@ > +CD-ROM is in ISO 9660 format > +System id: FreeBSD > +Volume id: 11_2_RELEASE_AMD64_DVD > +Volume set id: > +Publisher id: THE FREEBSD PROJECT. HTTP://WWW.FREEBSD.ORG/ > +Data preparer id: > +Application id: > +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: 1563513 > +El Torito VD version 1 found, boot catalog is in sector 19 > +NO Joliet present > + > +SUSP signatures version 1 found > +Rock Ridge signatures version 1 found > +Rock Ridge id 'IEEE_P1282' > +Eltorito validation header: > + Hid 1 > + Arch 0 (x86) > + ID '' > + Cksum AA 55 OK > + Key 55 AA > + Eltorito defaultboot header: > + Bootid 88 (bootable) > + Boot media 0 (No Emulation Boot) > + Load segment 0 > + Sys type 0 > + Nsect 4 > + Bootoff 1A4 420 > diff --git a/tests/isodata/freebsd/freebsd11.2/FreeBSD-11.2-RELEASE-i386-disc1.iso.txt b/tests/isodata/freebsd/freebsd11.2/FreeBSD-11.2-RELEASE-i386-disc1.iso.txt > new file mode 100644 > index 0000000..13cc515 > --- /dev/null > +++ b/tests/isodata/freebsd/freebsd11.2/FreeBSD-11.2-RELEASE-i386-disc1.iso.txt > @@ -0,0 +1,33 @@ > +CD-ROM is in ISO 9660 format > +System id: FreeBSD > +Volume id: 11_2_RELEASE_I386_CD > +Volume set id: > +Publisher id: THE FREEBSD PROJECT. HTTP://WWW.FREEBSD.ORG/ > +Data preparer id: > +Application id: > +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: 295666 > +El Torito VD version 1 found, boot catalog is in sector 19 > +NO Joliet present > + > +SUSP signatures version 1 found > +Rock Ridge signatures version 1 found > +Rock Ridge id 'IEEE_P1282' > +Eltorito validation header: > + Hid 1 > + Arch 0 (x86) > + ID '' > + Cksum AA 55 OK > + Key 55 AA > + Eltorito defaultboot header: > + Bootid 88 (bootable) > + Boot media 0 (No Emulation Boot) > + Load segment 0 > + Sys type 0 > + Nsect 4 > + Bootoff 14 20 > diff --git a/tests/isodata/freebsd/freebsd11.2/FreeBSD-11.2-RELEASE-i386-dvd1.iso.txt b/tests/isodata/freebsd/freebsd11.2/FreeBSD-11.2-RELEASE-i386-dvd1.iso.txt > new file mode 100644 > index 0000000..8dac59a > --- /dev/null > +++ b/tests/isodata/freebsd/freebsd11.2/FreeBSD-11.2-RELEASE-i386-dvd1.iso.txt > @@ -0,0 +1,33 @@ > +CD-ROM is in ISO 9660 format > +System id: FreeBSD > +Volume id: 11_2_RELEASE_I386_DVD > +Volume set id: > +Publisher id: THE FREEBSD PROJECT. HTTP://WWW.FREEBSD.ORG/ > +Data preparer id: > +Application id: > +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: 1395641 > +El Torito VD version 1 found, boot catalog is in sector 19 > +NO Joliet present > + > +SUSP signatures version 1 found > +Rock Ridge signatures version 1 found > +Rock Ridge id 'IEEE_P1282' > +Eltorito validation header: > + Hid 1 > + Arch 0 (x86) > + ID '' > + Cksum AA 55 OK > + Key 55 AA > + Eltorito defaultboot header: > + Bootid 88 (bootable) > + Boot media 0 (No Emulation Boot) > + Load segment 0 > + Sys type 0 > + Nsect 4 > + Bootoff 14 20 > -- > 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 cfergeau at redhat.com Mon Jul 2 09:39:08 2018 From: cfergeau at redhat.com (Christophe Fergeau) Date: Mon, 2 Jul 2018 11:39:08 +0200 Subject: [Libosinfo] [PATCH osinfo-db] freebsd: add FreeBSD 11.2 info In-Reply-To: <20180630133400.59155-1-bogorodskiy@gmail.com> References: <20180630133400.59155-1-bogorodskiy@gmail.com> Message-ID: <20180702093908.GC32053@natto.ory.fergeau.eu> Acked-by: Christophe Fergeau On Sat, Jun 30, 2018 at 05:34:00PM +0400, Roman Bogorodskiy wrote: > Signed-off-by: Roman Bogorodskiy > --- > data/os/freebsd.org/freebsd-11.2.xml.in | 50 +++++++++++++++++++++++++ > 1 file changed, 50 insertions(+) > create mode 100644 data/os/freebsd.org/freebsd-11.2.xml.in > > diff --git a/data/os/freebsd.org/freebsd-11.2.xml.in b/data/os/freebsd.org/freebsd-11.2.xml.in > new file mode 100644 > index 0000000..d8cbaa5 > --- /dev/null > +++ b/data/os/freebsd.org/freebsd-11.2.xml.in > @@ -0,0 +1,50 @@ > + > + > + > + freebsd11.2 > + <_name>FreeBSD 11.2 > + 11.2 > + <_vendor>FreeBSD Project > + freebsd > + freebsd > + > + > + > + 2018-06-27 > + > + > + > + > + > + > + > + https://download.freebsd.org/ftp/releases/ISO-IMAGES/11.2/FreeBSD-11.2-RELEASE-amd64-dvd1.iso > + > + FreeBSD > + 11_2_RELEASE_AMD64_DVD > + > + > + > + https://download.freebsd.org/ftp/releases/ISO-IMAGES/11.2/FreeBSD-11.2-RELEASE-amd64-disc1.iso > + > + FreeBSD > + 11_2_RELEASE_AMD64_CD > + > + > + > + https://download.freebsd.org/ftp/releases/ISO-IMAGES/11.2/FreeBSD-11.2-RELEASE-i386-dvd1.iso > + > + FreeBSD > + 11_2_RELEASE_I386_DVD > + > + > + > + https://download.freebsd.org/ftp/releases/ISO-IMAGES/11.2/FreeBSD-11.2-RELEASE-i386-disc1.iso > + > + FreeBSD > + 11_2_RELEASE_I386_CD > + > + > + > + > -- > 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 fabiano at fidencio.org Tue Jul 3 11:32:28 2018 From: fabiano at fidencio.org (=?UTF-8?Q?Fabiano_Fid=C3=AAncio?=) Date: Tue, 3 Jul 2018 13:32:28 +0200 Subject: [Libosinfo] [RFC] Providing apps an easier way to update osinfo-db Message-ID: Folks, One thing that has been discussed between Felipe Borges (GNOME Boxes maintainer) and myself is the possibility to, from an app, download and install the latest osinfo-db content without being dependent of distribution packagers and being able to ensure that the users will have the most up-to-date db as soon as a something was introduced/changed. In order to do so, we'd have to (according to my understanding): - Support URLs as arguments for osinfo-db-import: This step would allow the apps to download the latest release from our official source; - Expose a "latest" osinfo-db build: Currently we tag our releases, make a tarball and this tarball is uploaded in pagure. The tarball's name looks like "osinfo-db-20180612.tar.xz" and, preferably, we'd like to have something like "osinfo-db-latest.tar.xz" pointing to the latest release. Actually, in an ideal world, we'd like to have a osinfo-db-latest.tar.xz pointing to the last osinfo-db commit (then, maybe, we would have to rely on gitlab infra to do that?); - Provide a DBus API for osinfo-db-import and osinfo-db-validate (at least): With this we can easily spawn, for instance, `osinfo-db-import https://releases.pagure.org/libosinfo/osinfo-db-latest.tar.xz` from any app using osinfo-db; Ideas? Possible limitations? Best Regards, -- Fabiano Fid?ncio From berrange at redhat.com Tue Jul 3 11:54:37 2018 From: berrange at redhat.com (Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?=) Date: Tue, 3 Jul 2018 12:54:37 +0100 Subject: [Libosinfo] [RFC] Providing apps an easier way to update osinfo-db In-Reply-To: References: Message-ID: <20180703115437.GD24516@redhat.com> On Tue, Jul 03, 2018 at 01:32:28PM +0200, Fabiano Fid?ncio wrote: > Folks, > > One thing that has been discussed between Felipe Borges (GNOME Boxes > maintainer) and myself is the possibility to, from an app, download > and install the latest osinfo-db content without being dependent of > distribution packagers and being able to ensure that the users will > have the most up-to-date db as soon as a something was > introduced/changed. > > In order to do so, we'd have to (according to my understanding): > - Support URLs as arguments for osinfo-db-import: > This step would allow the apps to download the latest release from > our official source; This is fine, and needed no matter what else is done I think. > - Expose a "latest" osinfo-db build: > Currently we tag our releases, make a tarball and this tarball is > uploaded in pagure. The tarball's name looks like > "osinfo-db-20180612.tar.xz" and, preferably, we'd like to have > something like "osinfo-db-latest.tar.xz" pointing to the latest > release. Actually, in an ideal world, we'd like to have a > osinfo-db-latest.tar.xz pointing to the last osinfo-db commit (then, > maybe, we would have to rely on gitlab infra to do that?); I think the idea of a -latest.tar.xz link is a mistake as it encourages apps to download the content even if hasn't been changed, as they can't easily see if it is a new version or not. > - Provide a DBus API for osinfo-db-import and osinfo-db-validate (at least): > With this we can easily spawn, for instance, `osinfo-db-import > https://releases.pagure.org/libosinfo/osinfo-db-latest.tar.xz` from > any app using osinfo-db; I'm pretty sceptical about need for adding dbus into this. I don't see why an app couldn't just spawn the commands as is. Turning them into a DBus service feels like massive overkill for the problem. Also we must not have any applications hardcoding releases.pagure.org URLs. I do not have confidence in pagure.org sticking around over the long time frames RHEL lives for. > Ideas? Possible limitations? I've been thinking about live updates for quite a while - ever since I created the osinfo-db-tools separate package in fact :-) The two key problems with any live update mechanism are scalability and compatibility. We need to ensure that applications don't repeatedly hit the web server to download unchanged content over & over. We also neeed to ensure that we don't bake in usage of a URL that is liable to change over time. Whatever we do will end up in RHEL releases that can live for 10+ years, and I don't have confidence our hosting will live for 10+ years without moving at least once. My thought was to leverage DNS as a key part of the solution. Have DNS TXT record exposing the current live update URL ie a TXT query against "dbupdate.libosinfo.org" could return something akin to url=https://releases.pagure.org/libosinfo/osinfo-db-20180612.tar.xz,version=20180612 The locally install osinfo-db content always creates a file VERSION in the root of the install location. So that content can be compared against the DNS result to see if it is outdated of not, and thus avoid hitting the web server at all unless there's genuinely a change that needs acquiring. I would anticipate some osinfo-db-update-check tool to perform this work and print out a URL, that could then be given to osinfo-db-import. It feels like a cron job to kick off periodic updates would be nice, but the downside with that is that it synchronizes a DOS attack from all deployed hosts (modulo timezone differences). Security is, however, a key issue here. For this to be practical at the very least it would likely require either DNSSEC, or embedding a crypto signature in the result. The latter would however require a long term pub key to be embedded in the client, and I'm not a fan of that. There is a concern of reinventing the wheel here. There is some kind of industry standard I vaguely recall for doing software/content updates over the internet. I've not investigated that in enough detail to understand if it avoids the scalability & compatibility concerns I have though. 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 bogorodskiy at gmail.com Tue Jul 3 17:20:46 2018 From: bogorodskiy at gmail.com (Roman Bogorodskiy) Date: Tue, 3 Jul 2018 21:20:46 +0400 Subject: [Libosinfo] [PATCH osinfo-db] freebsd: add FreeBSD 11.2 info In-Reply-To: <20180702093908.GC32053@natto.ory.fergeau.eu> References: <20180630133400.59155-1-bogorodskiy@gmail.com> <20180702093908.GC32053@natto.ory.fergeau.eu> Message-ID: <20180703172044.GA2104@kloomba> Christophe Fergeau wrote: > Acked-by: Christophe Fergeau Thanks! It looks like it's not merged though. > On Sat, Jun 30, 2018 at 05:34:00PM +0400, Roman Bogorodskiy wrote: > > Signed-off-by: Roman Bogorodskiy > > --- > > data/os/freebsd.org/freebsd-11.2.xml.in | 50 +++++++++++++++++++++++++ > > 1 file changed, 50 insertions(+) > > create mode 100644 data/os/freebsd.org/freebsd-11.2.xml.in Roman Bogorodskiy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: not available URL: From fabiano at fidencio.org Tue Jul 3 20:29:32 2018 From: fabiano at fidencio.org (=?UTF-8?Q?Fabiano_Fid=C3=AAncio?=) Date: Tue, 3 Jul 2018 22:29:32 +0200 Subject: [Libosinfo] [PATCH osinfo-db] freebsd: add FreeBSD 11.2 info In-Reply-To: <20180703172044.GA2104@kloomba> References: <20180630133400.59155-1-bogorodskiy@gmail.com> <20180702093908.GC32053@natto.ory.fergeau.eu> <20180703172044.GA2104@kloomba> Message-ID: On Tue, Jul 3, 2018 at 7:20 PM, Roman Bogorodskiy wrote: > Christophe Fergeau wrote: > >> Acked-by: Christophe Fergeau > > Thanks! It looks like it's not merged though. They are now! > >> On Sat, Jun 30, 2018 at 05:34:00PM +0400, Roman Bogorodskiy wrote: >> > Signed-off-by: Roman Bogorodskiy >> > --- >> > data/os/freebsd.org/freebsd-11.2.xml.in | 50 +++++++++++++++++++++++++ >> > 1 file changed, 50 insertions(+) >> > create mode 100644 data/os/freebsd.org/freebsd-11.2.xml.in > > > > Roman Bogorodskiy > > _______________________________________________ > Libosinfo mailing list > Libosinfo at redhat.com > https://www.redhat.com/mailman/listinfo/libosinfo > -- Fabiano Fid?ncio From fabiano at fidencio.org Wed Jul 4 06:46:11 2018 From: fabiano at fidencio.org (=?UTF-8?Q?Fabiano_Fid=C3=AAncio?=) Date: Wed, 4 Jul 2018 08:46:11 +0200 Subject: [Libosinfo] [RFC] Providing apps an easier way to update osinfo-db In-Reply-To: <20180703115437.GD24516@redhat.com> References: <20180703115437.GD24516@redhat.com> Message-ID: On Tue, Jul 3, 2018 at 1:54 PM, Daniel P. Berrang? wrote: > On Tue, Jul 03, 2018 at 01:32:28PM +0200, Fabiano Fid?ncio wrote: >> Folks, >> >> One thing that has been discussed between Felipe Borges (GNOME Boxes >> maintainer) and myself is the possibility to, from an app, download >> and install the latest osinfo-db content without being dependent of >> distribution packagers and being able to ensure that the users will >> have the most up-to-date db as soon as a something was >> introduced/changed. >> >> In order to do so, we'd have to (according to my understanding): >> - Support URLs as arguments for osinfo-db-import: >> This step would allow the apps to download the latest release from >> our official source; > > This is fine, and needed no matter what else is done I think. > >> - Expose a "latest" osinfo-db build: >> Currently we tag our releases, make a tarball and this tarball is >> uploaded in pagure. The tarball's name looks like >> "osinfo-db-20180612.tar.xz" and, preferably, we'd like to have >> something like "osinfo-db-latest.tar.xz" pointing to the latest >> release. Actually, in an ideal world, we'd like to have a >> osinfo-db-latest.tar.xz pointing to the last osinfo-db commit (then, >> maybe, we would have to rely on gitlab infra to do that?); > > I think the idea of a -latest.tar.xz link is a mistake as it > encourages apps to download the content even if hasn't been changed, > as they can't easily see if it is a new version or not. With the -latest naming I was envisioning that we could ship non-official releases, but git master. So, first thing, the name is, at least, misleading. :-/ Daniel, You think that shipping git master would also be a mistake? We can easily do a release per day we have patches and update the release in pagure without issues. But it becomes problematic in order to how distribute those to fedora (considering that the time waiting for those to reach the distro is ~2 weeks from the release day ... and I'm packaging it as soon as a release is done). If you think this idea is okay, how do you envision it being shipped/displayed to the apps to download? The reason I'm asking here is because if we take this path, we'd have to have a way to provide git master already built to the apps and having this on pagure, for sure, doesn't seem like a good idea. > >> - Provide a DBus API for osinfo-db-import and osinfo-db-validate (at least): >> With this we can easily spawn, for instance, `osinfo-db-import >> https://releases.pagure.org/libosinfo/osinfo-db-latest.tar.xz` from >> any app using osinfo-db; > > I'm pretty sceptical about need for adding dbus into this. I don't see > why an app couldn't just spawn the commands as is. Turning them into > a DBus service feels like massive overkill for the problem. Okay from my side. I'd like to hear here from Felipe as well why a dbus API would be their preferred way and, mainly, whether we could go for spawning the command as they are now. > > Also we must not have any applications hardcoding releases.pagure.org > URLs. I do not have confidence in pagure.org sticking around over the > long time frames RHEL lives for. > >> Ideas? Possible limitations? > > I've been thinking about live updates for quite a while - ever since I > created the osinfo-db-tools separate package in fact :-) > > The two key problems with any live update mechanism are scalability and > compatibility. We need to ensure that applications don't repeatedly > hit the web server to download unchanged content over & over. We also > neeed to ensure that we don't bake in usage of a URL that is liable > to change over time. Whatever we do will end up in RHEL releases that > can live for 10+ years, and I don't have confidence our hosting will > live for 10+ years without moving at least once. > > My thought was to leverage DNS as a key part of the solution. Have DNS > TXT record exposing the current live update URL ie a TXT query against > "dbupdate.libosinfo.org" could return something akin to > > url=https://releases.pagure.org/libosinfo/osinfo-db-20180612.tar.xz,version=20180612 > > The locally install osinfo-db content always creates a file VERSION in > the root of the install location. So that content can be compared against > the DNS result to see if it is outdated of not, and thus avoid hitting > the web server at all unless there's genuinely a change that needs > acquiring. > > I would anticipate some osinfo-db-update-check tool to perform this work > and print out a URL, that could then be given to osinfo-db-import. I like the idea! Who's the owner of libosinfo.org? Daniel? Red Hat? Daniel, Did you start poking at this in the past? If not, it's something I can slowly starting to take a look at. > > It feels like a cron job to kick off periodic updates would be nice, but > the downside with that is that it synchronizes a DOS attack from all > deployed hosts (modulo timezone differences). The idea about what will be used on Boxes is something to be discussed during its hackfest that will happen next Monday. I'm expecting that for generating the flatpack a cron job will be used. I'm not sure whether we want to also have an option to update the osinfo-db on non-flatpak'ed apps (aka, the ones normally shipped on OSes), although I do believe GNOME Boxes should! > > Security is, however, a key issue here. For this to be practical at the > very least it would likely require either DNSSEC, or embedding a crypto > signature in the result. The latter would however require a long term > pub key to be embedded in the client, and I'm not a fan of that. > > There is a concern of reinventing the wheel here. There is some kind of > industry standard I vaguely recall for doing software/content updates > over the internet. I've not investigated that in enough detail to > understand if it avoids the scalability & compatibility concerns I > have though Hmm. Right, it makes sense. I'll check what the standard is and how we could take advantage of that. . > > 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 :| Best Regards, -- Fabiano Fid?ncio From fabiano at fidencio.org Wed Jul 4 06:49:37 2018 From: fabiano at fidencio.org (=?UTF-8?Q?Fabiano_Fid=C3=AAncio?=) Date: Wed, 4 Jul 2018 08:49:37 +0200 Subject: [Libosinfo] [RFC] Providing apps an easier way to update osinfo-db In-Reply-To: References: <20180703115437.GD24516@redhat.com> Message-ID: On Wed, Jul 4, 2018 at 8:46 AM, Fabiano Fid?ncio wrote: > On Tue, Jul 3, 2018 at 1:54 PM, Daniel P. Berrang? wrote: >> On Tue, Jul 03, 2018 at 01:32:28PM +0200, Fabiano Fid?ncio wrote: >>> Folks, >>> >>> One thing that has been discussed between Felipe Borges (GNOME Boxes >>> maintainer) and myself is the possibility to, from an app, download >>> and install the latest osinfo-db content without being dependent of >>> distribution packagers and being able to ensure that the users will >>> have the most up-to-date db as soon as a something was >>> introduced/changed. >>> >>> In order to do so, we'd have to (according to my understanding): >>> - Support URLs as arguments for osinfo-db-import: >>> This step would allow the apps to download the latest release from >>> our official source; >> >> This is fine, and needed no matter what else is done I think. >> >>> - Expose a "latest" osinfo-db build: >>> Currently we tag our releases, make a tarball and this tarball is >>> uploaded in pagure. The tarball's name looks like >>> "osinfo-db-20180612.tar.xz" and, preferably, we'd like to have >>> something like "osinfo-db-latest.tar.xz" pointing to the latest >>> release. Actually, in an ideal world, we'd like to have a >>> osinfo-db-latest.tar.xz pointing to the last osinfo-db commit (then, >>> maybe, we would have to rely on gitlab infra to do that?); >> >> I think the idea of a -latest.tar.xz link is a mistake as it >> encourages apps to download the content even if hasn't been changed, >> as they can't easily see if it is a new version or not. > > With the -latest naming I was envisioning that we could ship > non-official releases, but git master. Argh. "(...) non-official releases, like git master." Sorry for the typo. > So, first thing, the name is, at least, misleading. :-/ > > Daniel, > You think that shipping git master would also be a mistake? We can > easily do a release per day we have patches and update the release in > pagure without issues. But it becomes problematic in order to how > distribute those to fedora (considering that the time waiting for > those to reach the distro is ~2 weeks from the release day ... and I'm > packaging it as soon as a release is done). > > If you think this idea is okay, how do you envision it being > shipped/displayed to the apps to download? The reason I'm asking here > is because if we take this path, we'd have to have a way to provide > git master already built to the apps and having this on pagure, for > sure, doesn't seem like a good idea. > >> >>> - Provide a DBus API for osinfo-db-import and osinfo-db-validate (at least): >>> With this we can easily spawn, for instance, `osinfo-db-import >>> https://releases.pagure.org/libosinfo/osinfo-db-latest.tar.xz` from >>> any app using osinfo-db; >> >> I'm pretty sceptical about need for adding dbus into this. I don't see >> why an app couldn't just spawn the commands as is. Turning them into >> a DBus service feels like massive overkill for the problem. > > Okay from my side. > I'd like to hear here from Felipe as well why a dbus API would be > their preferred way and, mainly, whether we could go for spawning the > command as they are now. > >> >> Also we must not have any applications hardcoding releases.pagure.org >> URLs. I do not have confidence in pagure.org sticking around over the >> long time frames RHEL lives for. >> >>> Ideas? Possible limitations? >> >> I've been thinking about live updates for quite a while - ever since I >> created the osinfo-db-tools separate package in fact :-) >> >> The two key problems with any live update mechanism are scalability and >> compatibility. We need to ensure that applications don't repeatedly >> hit the web server to download unchanged content over & over. We also >> neeed to ensure that we don't bake in usage of a URL that is liable >> to change over time. Whatever we do will end up in RHEL releases that >> can live for 10+ years, and I don't have confidence our hosting will >> live for 10+ years without moving at least once. >> >> My thought was to leverage DNS as a key part of the solution. Have DNS >> TXT record exposing the current live update URL ie a TXT query against >> "dbupdate.libosinfo.org" could return something akin to >> >> url=https://releases.pagure.org/libosinfo/osinfo-db-20180612.tar.xz,version=20180612 >> >> The locally install osinfo-db content always creates a file VERSION in >> the root of the install location. So that content can be compared against >> the DNS result to see if it is outdated of not, and thus avoid hitting >> the web server at all unless there's genuinely a change that needs >> acquiring. >> >> I would anticipate some osinfo-db-update-check tool to perform this work >> and print out a URL, that could then be given to osinfo-db-import. > > I like the idea! > > Who's the owner of libosinfo.org? Daniel? Red Hat? > > Daniel, > Did you start poking at this in the past? If not, it's something I can > slowly starting to take a look at. > >> >> It feels like a cron job to kick off periodic updates would be nice, but >> the downside with that is that it synchronizes a DOS attack from all >> deployed hosts (modulo timezone differences). > > The idea about what will be used on Boxes is something to be discussed > during its hackfest that will happen next Monday. > I'm expecting that for generating the flatpack a cron job will be > used. I'm not sure whether we want to also have an option to update > the osinfo-db on non-flatpak'ed apps (aka, the ones normally shipped > on OSes), although I do believe GNOME Boxes should! > >> >> Security is, however, a key issue here. For this to be practical at the >> very least it would likely require either DNSSEC, or embedding a crypto >> signature in the result. The latter would however require a long term >> pub key to be embedded in the client, and I'm not a fan of that. >> >> There is a concern of reinventing the wheel here. There is some kind of >> industry standard I vaguely recall for doing software/content updates >> over the internet. I've not investigated that in enough detail to >> understand if it avoids the scalability & compatibility concerns I >> have though > > Hmm. Right, it makes sense. I'll check what the standard is and how we > could take advantage of that. > . >> >> 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 :| > > > Best Regards, > -- > Fabiano Fid?ncio -- Fabiano Fid?ncio From berrange at redhat.com Wed Jul 4 15:46:32 2018 From: berrange at redhat.com (Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?=) Date: Wed, 4 Jul 2018 16:46:32 +0100 Subject: [Libosinfo] [RFC] Providing apps an easier way to update osinfo-db In-Reply-To: References: <20180703115437.GD24516@redhat.com> Message-ID: <20180704154632.GL32267@redhat.com> On Wed, Jul 04, 2018 at 08:46:11AM +0200, Fabiano Fid?ncio wrote: > On Tue, Jul 3, 2018 at 1:54 PM, Daniel P. Berrang? wrote: > > On Tue, Jul 03, 2018 at 01:32:28PM +0200, Fabiano Fid?ncio wrote: > >> Folks, > >> > >> One thing that has been discussed between Felipe Borges (GNOME Boxes > >> maintainer) and myself is the possibility to, from an app, download > >> and install the latest osinfo-db content without being dependent of > >> distribution packagers and being able to ensure that the users will > >> have the most up-to-date db as soon as a something was > >> introduced/changed. > >> > >> In order to do so, we'd have to (according to my understanding): > >> - Support URLs as arguments for osinfo-db-import: > >> This step would allow the apps to download the latest release from > >> our official source; > > > > This is fine, and needed no matter what else is done I think. > > > >> - Expose a "latest" osinfo-db build: > >> Currently we tag our releases, make a tarball and this tarball is > >> uploaded in pagure. The tarball's name looks like > >> "osinfo-db-20180612.tar.xz" and, preferably, we'd like to have > >> something like "osinfo-db-latest.tar.xz" pointing to the latest > >> release. Actually, in an ideal world, we'd like to have a > >> osinfo-db-latest.tar.xz pointing to the last osinfo-db commit (then, > >> maybe, we would have to rely on gitlab infra to do that?); > > > > I think the idea of a -latest.tar.xz link is a mistake as it > > encourages apps to download the content even if hasn't been changed, > > as they can't easily see if it is a new version or not. > > With the -latest naming I was envisioning that we could ship > non-official releases, but git master. > So, first thing, the name is, at least, misleading. :-/ > > Daniel, > You think that shipping git master would also be a mistake? We can > easily do a release per day we have patches and update the release in > pagure without issues. But it becomes problematic in order to how > distribute those to fedora (considering that the time waiting for > those to reach the distro is ~2 weeks from the release day ... and I'm > packaging it as soon as a release is done). I'd be pretty wary of shipping git master without having any human interaction given our current way of testing. All our tests are done post-commit, so we don't know that things are 100% working correctly at time of push. We've also had cases where we simply wanted to change things before releasing them. This is particularly important for URLs. So I would not want applications pulling down git master based content, at least not with our current workflow. > > Also we must not have any applications hardcoding releases.pagure.org > > URLs. I do not have confidence in pagure.org sticking around over the > > long time frames RHEL lives for. > > > >> Ideas? Possible limitations? > > > > I've been thinking about live updates for quite a while - ever since I > > created the osinfo-db-tools separate package in fact :-) > > > > The two key problems with any live update mechanism are scalability and > > compatibility. We need to ensure that applications don't repeatedly > > hit the web server to download unchanged content over & over. We also > > neeed to ensure that we don't bake in usage of a URL that is liable > > to change over time. Whatever we do will end up in RHEL releases that > > can live for 10+ years, and I don't have confidence our hosting will > > live for 10+ years without moving at least once. > > > > My thought was to leverage DNS as a key part of the solution. Have DNS > > TXT record exposing the current live update URL ie a TXT query against > > "dbupdate.libosinfo.org" could return something akin to > > > > url=https://releases.pagure.org/libosinfo/osinfo-db-20180612.tar.xz,version=20180612 > > > > The locally install osinfo-db content always creates a file VERSION in > > the root of the install location. So that content can be compared against > > the DNS result to see if it is outdated of not, and thus avoid hitting > > the web server at all unless there's genuinely a change that needs > > acquiring. > > > > I would anticipate some osinfo-db-update-check tool to perform this work > > and print out a URL, that could then be given to osinfo-db-import. > > I like the idea! > > Who's the owner of libosinfo.org? Daniel? Red Hat? I own & host it. > Daniel, > Did you start poking at this in the past? If not, it's something I can > slowly starting to take a look at. No I've not done any active work on it. > > It feels like a cron job to kick off periodic updates would be nice, but > > the downside with that is that it synchronizes a DOS attack from all > > deployed hosts (modulo timezone differences). > > The idea about what will be used on Boxes is something to be discussed > during its hackfest that will happen next Monday. > I'm expecting that for generating the flatpack a cron job will be > used. I'm not sure whether we want to also have an option to update > the osinfo-db on non-flatpak'ed apps (aka, the ones normally shipped > on OSes), although I do believe GNOME Boxes should! > > > > > Security is, however, a key issue here. For this to be practical at the > > very least it would likely require either DNSSEC, or embedding a crypto > > signature in the result. The latter would however require a long term > > pub key to be embedded in the client, and I'm not a fan of that. > > > > There is a concern of reinventing the wheel here. There is some kind of > > industry standard I vaguely recall for doing software/content updates > > over the internet. I've not investigated that in enough detail to > > understand if it avoids the scalability & compatibility concerns I > > have though > > Hmm. Right, it makes sense. I'll check what the standard is and how we > could take advantage of that. This is the thing I was remembering: https://theupdateframework.github.io/ It is, however, fairly complicated spec. It avoids apps pulling down the actual content when there is no change, but apps will still be querying the server for metadata about the content. Their approach to this appears to expect you to setup mirroring/redundancy in your hosting solution. This is fine for big orgs like distros or commercial vendors with money to spend, but its more limiting for a small scale project like libosinfo, which could none the less see notable traffic growth. We're a smaller scale in terms of data size, but I'm wary of the fate that happened with LVFS where amazon bills ended up being $100/month https://blogs.gnome.org/hughsie/2018/04/03/the-lvfs-cdn-will-change-soon/ Having read more about TUP spec though, I can see it covers many security flaws that would affect the "simple" DNS based impl I mentioned. So I'm not too sure how to go forward. 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 carnold at suse.com Tue Jul 17 21:34:32 2018 From: carnold at suse.com (Charles Arnold) Date: Tue, 17 Jul 2018 15:34:32 -0600 Subject: [Libosinfo] [PATCH osinfo-db] sles: Add SLE15 Information Message-ID: <5B4E60E8020000910012CA5D@prv-mh.provo.novell.com> >From 1a35058843f8e8e12e0894d0d454cec95ce79e18 Mon Sep 17 00:00:00 2001 From: Charles Arnold Date: Tue, 17 Jul 2018 15:03:01 -0600 Subject: [PATCH] sles: Add SLE15 Information Beginning with SLE15 the OS comes with an installer ISO that asks the user what product to install (eg, Server, Desktop, etc.) For this reason the OS description file describes only the installer media which is simply 'sle15' instead of 'sles15' or 'sled15'. --- data/os/suse.com/sle-15.xml.in | 65 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 65 insertions(+) create mode 100644 data/os/suse.com/sle-15.xml.in diff --git a/data/os/suse.com/sle-15.xml.in b/data/os/suse.com/sle-15.xml.in new file mode 100644 index 0000000..68fb0f3 --- /dev/null +++ b/data/os/suse.com/sle-15.xml.in @@ -0,0 +1,65 @@ + + + + sle15 + <_name>SUSE Linux Enterprise 15 + 15 + <_vendor>SUSE + linux + sle + + + + 2018-07-16 + + + + LINUX + SLE-15-Installer-DVD-x86_64 + + boot/x86_64/loader/linux + boot/x86_64/loader/initrd + + + + + LINUX + SLE-15-Installer-DVD-aarch64 + + boot/aarch64/linux + boot/aarch64/initrd + + + + + LINUX + SLE-15-Installer-DVD-ppc64le + + boot/ppc64le/linux + boot/ppc64le/initrd + + + + + LINUX + SLE-15-Installer-DVD-s390x + + boot/s390x/linux + boot/s390x/initrd + + + + + 500000000 + 536870912 + 1074151424 + + + 2400000000 + 1073741824 + 17179869184 + + + + -- 1.8.5.6 From carnold at suse.com Tue Jul 17 21:34:43 2018 From: carnold at suse.com (Charles Arnold) Date: Tue, 17 Jul 2018 15:34:43 -0600 Subject: [Libosinfo] [PATCH libosinfo] sles: Add SLE15 ISO Information Message-ID: <5B4E60F3020000910012CA61@prv-mh.provo.novell.com> >From f94303bcba998f25eb2ee3f77eee71bc36b98067 Mon Sep 17 00:00:00 2001 From: Charles Arnold Date: Fri, 13 Jul 2018 13:45:21 -0600 Subject: [PATCH] sles: Add SLE15 ISO Information --- .../SLE-15-Installer-DVD-aarch64-GM-DVD1.iso.txt | 29 ++++++++++++++++++++++ .../SLE-15-Installer-DVD-ppc64le-GM-DVD1.iso.txt | 16 ++++++++++++ .../SLE-15-Installer-DVD-s390x-GM-DVD1.iso.txt | 29 ++++++++++++++++++++++ .../SLE-15-Installer-DVD-x86_64-GM-DVD1.iso.txt | 29 ++++++++++++++++++++++ 4 files changed, 103 insertions(+) create mode 100644 tests/isodata/sles/sles15/SLE-15-Installer-DVD-aarch64-GM-DVD1.iso.txt create mode 100644 tests/isodata/sles/sles15/SLE-15-Installer-DVD-ppc64le-GM-DVD1.iso.txt create mode 100644 tests/isodata/sles/sles15/SLE-15-Installer-DVD-s390x-GM-DVD1.iso.txt create mode 100644 tests/isodata/sles/sles15/SLE-15-Installer-DVD-x86_64-GM-DVD1.iso.txt diff --git a/tests/isodata/sles/sles15/SLE-15-Installer-DVD-aarch64-GM-DVD1.iso.txt b/tests/isodata/sles/sles15/SLE-15-Installer-DVD-aarch64-GM-DVD1.iso.txt new file mode 100644 index 0000000..55949a2 --- /dev/null +++ b/tests/isodata/sles/sles15/SLE-15-Installer-DVD-aarch64-GM-DVD1.iso.txt @@ -0,0 +1,29 @@ +CD-ROM is in ISO 9660 format +System id: LINUX +Volume id: SLE-15-Installer-DVD-aarch64.001 +Volume set id: +Publisher id: SUSE LINUX GmbH +Data preparer id: KIWI - http://opensuse.github.com/kiwi +Application id: SLE-15-Installer-DVD-aarch64-Build668.1-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: 298600 +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 DC8 + Bootoff 8730 34608 diff --git a/tests/isodata/sles/sles15/SLE-15-Installer-DVD-ppc64le-GM-DVD1.iso.txt b/tests/isodata/sles/sles15/SLE-15-Installer-DVD-ppc64le-GM-DVD1.iso.txt new file mode 100644 index 0000000..cc3873f --- /dev/null +++ b/tests/isodata/sles/sles15/SLE-15-Installer-DVD-ppc64le-GM-DVD1.iso.txt @@ -0,0 +1,16 @@ +CD-ROM is in ISO 9660 format +System id: LINUX +Volume id: SLE-15-Installer-DVD-ppc64le.001 +Volume set id: +Publisher id: SUSE LINUX GmbH +Data preparer id: KIWI - http://opensuse.github.com/kiwi +Application id: SLE-15-Installer-DVD-ppc64le-Build668.1-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: 303875 +Joliet with UCS level 3 found +Rock Ridge signatures version 1 found diff --git a/tests/isodata/sles/sles15/SLE-15-Installer-DVD-s390x-GM-DVD1.iso.txt b/tests/isodata/sles/sles15/SLE-15-Installer-DVD-s390x-GM-DVD1.iso.txt new file mode 100644 index 0000000..abd8938 --- /dev/null +++ b/tests/isodata/sles/sles15/SLE-15-Installer-DVD-s390x-GM-DVD1.iso.txt @@ -0,0 +1,29 @@ +CD-ROM is in ISO 9660 format +System id: LINUX +Volume id: SLE-15-Installer-DVD-s390x66.001 +Volume set id: +Publisher id: SUSE LINUX GmbH +Data preparer id: KIWI - http://opensuse.github.com/kiwi +Application id: SLE-15-Installer-DVD-s390x-Build668.1-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: 389767 +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 81 129 diff --git a/tests/isodata/sles/sles15/SLE-15-Installer-DVD-x86_64-GM-DVD1.iso.txt b/tests/isodata/sles/sles15/SLE-15-Installer-DVD-x86_64-GM-DVD1.iso.txt new file mode 100644 index 0000000..85dda21 --- /dev/null +++ b/tests/isodata/sles/sles15/SLE-15-Installer-DVD-x86_64-GM-DVD1.iso.txt @@ -0,0 +1,29 @@ +CD-ROM is in ISO 9660 format +System id: LINUX +Volume id: SLE-15-Installer-DVD-x86_646.001 +Volume set id: +Publisher id: SUSE LINUX GmbH +Data preparer id: KIWI - http://opensuse.github.com/kiwi +Application id: SLE-15-Installer-DVD-x86_64-Build668.1-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: 324780 +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 1066 4198 -- 1.8.5.6 From fabiano at fidencio.org Tue Jul 17 21:57:12 2018 From: fabiano at fidencio.org (=?UTF-8?Q?Fabiano_Fid=C3=AAncio?=) Date: Tue, 17 Jul 2018 23:57:12 +0200 Subject: [Libosinfo] [PATCH osinfo-db] sles: Add SLE15 Information In-Reply-To: <5B4E60E8020000910012CA5D@prv-mh.provo.novell.com> References: <5B4E60E8020000910012CA5D@prv-mh.provo.novell.com> Message-ID: On Tue, Jul 17, 2018 at 11:34 PM, Charles Arnold wrote: > >From 1a35058843f8e8e12e0894d0d454cec95ce79e18 Mon Sep 17 00:00:00 2001 > From: Charles Arnold > Date: Tue, 17 Jul 2018 15:03:01 -0600 > Subject: [PATCH] sles: Add SLE15 Information > > Beginning with SLE15 the OS comes with an installer ISO > that asks the user what product to install (eg, Server, > Desktop, etc.) For this reason the OS description file describes > only the installer media which is simply 'sle15' instead of > 'sles15' or 'sled15'. Patch looks good, ack! > > --- > data/os/suse.com/sle-15.xml.in | 65 ++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 65 insertions(+) > create mode 100644 data/os/suse.com/sle-15.xml.in > > diff --git a/data/os/suse.com/sle-15.xml.in b/data/os/suse.com/sle-15.xml.in > new file mode 100644 > index 0000000..68fb0f3 > --- /dev/null > +++ b/data/os/suse.com/sle-15.xml.in > @@ -0,0 +1,65 @@ > + > + > + > + sle15 > + <_name>SUSE Linux Enterprise 15 > + 15 > + <_vendor>SUSE > + linux > + sle > + > + > + > + 2018-07-16 > + > + > + > + LINUX > + SLE-15-Installer-DVD-x86_64 > + > + boot/x86_64/loader/linux > + boot/x86_64/loader/initrd > + > + > + > + > + LINUX > + SLE-15-Installer-DVD-aarch64 > + > + boot/aarch64/linux > + boot/aarch64/initrd > + > + > + > + > + LINUX > + SLE-15-Installer-DVD-ppc64le > + > + boot/ppc64le/linux > + boot/ppc64le/initrd > + > + > + > + > + LINUX > + SLE-15-Installer-DVD-s390x > + > + boot/s390x/linux > + boot/s390x/initrd > + > + > + > + > + 500000000 > + 536870912 > + 1074151424 > + > + > + 2400000000 > + 1073741824 > + 17179869184 > + > + > + > + > -- > 1.8.5.6 > > > > > _______________________________________________ > Libosinfo mailing list > Libosinfo at redhat.com > https://www.redhat.com/mailman/listinfo/libosinfo -- Fabiano Fid?ncio From fabiano at fidencio.org Tue Jul 17 22:01:35 2018 From: fabiano at fidencio.org (=?UTF-8?Q?Fabiano_Fid=C3=AAncio?=) Date: Wed, 18 Jul 2018 00:01:35 +0200 Subject: [Libosinfo] [PATCH libosinfo] sles: Add SLE15 ISO Information In-Reply-To: <5B4E60F3020000910012CA61@prv-mh.provo.novell.com> References: <5B4E60F3020000910012CA61@prv-mh.provo.novell.com> Message-ID: On Tue, Jul 17, 2018 at 11:34 PM, Charles Arnold wrote: > >From f94303bcba998f25eb2ee3f77eee71bc36b98067 Mon Sep 17 00:00:00 2001 > From: Charles Arnold > Date: Fri, 13 Jul 2018 13:45:21 -0600 > Subject: [PATCH] sles: Add SLE15 ISO Information > > --- > .../SLE-15-Installer-DVD-aarch64-GM-DVD1.iso.txt | 29 ++++++++++++++++++++++ > .../SLE-15-Installer-DVD-ppc64le-GM-DVD1.iso.txt | 16 ++++++++++++ > .../SLE-15-Installer-DVD-s390x-GM-DVD1.iso.txt | 29 ++++++++++++++++++++++ > .../SLE-15-Installer-DVD-x86_64-GM-DVD1.iso.txt | 29 ++++++++++++++++++++++ > 4 files changed, 103 insertions(+) > create mode 100644 tests/isodata/sles/sles15/SLE-15-Installer-DVD-aarch64-GM-DVD1.iso.txt > create mode 100644 tests/isodata/sles/sles15/SLE-15-Installer-DVD-ppc64le-GM-DVD1.iso.txt > create mode 100644 tests/isodata/sles/sles15/SLE-15-Installer-DVD-s390x-GM-DVD1.iso.txt > create mode 100644 tests/isodata/sles/sles15/SLE-15-Installer-DVD-x86_64-GM-DVD1.iso.txt Charles, This patch is not correct. As you changed the os id from sles to sle for this release, you'd also have to move the data provided here to tests/isodate/sle/sle15/... > > diff --git a/tests/isodata/sles/sles15/SLE-15-Installer-DVD-aarch64-GM-DVD1.iso.txt b/tests/isodata/sles/sles15/SLE-15-Installer-DVD-aarch64-GM-DVD1.iso.txt > new file mode 100644 > index 0000000..55949a2 > --- /dev/null > +++ b/tests/isodata/sles/sles15/SLE-15-Installer-DVD-aarch64-GM-DVD1.iso.txt > @@ -0,0 +1,29 @@ > +CD-ROM is in ISO 9660 format > +System id: LINUX > +Volume id: SLE-15-Installer-DVD-aarch64.001 > +Volume set id: > +Publisher id: SUSE LINUX GmbH > +Data preparer id: KIWI - http://opensuse.github.com/kiwi > +Application id: SLE-15-Installer-DVD-aarch64-Build668.1-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: 298600 > +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 DC8 > + Bootoff 8730 34608 > diff --git a/tests/isodata/sles/sles15/SLE-15-Installer-DVD-ppc64le-GM-DVD1.iso.txt b/tests/isodata/sles/sles15/SLE-15-Installer-DVD-ppc64le-GM-DVD1.iso.txt > new file mode 100644 > index 0000000..cc3873f > --- /dev/null > +++ b/tests/isodata/sles/sles15/SLE-15-Installer-DVD-ppc64le-GM-DVD1.iso.txt > @@ -0,0 +1,16 @@ > +CD-ROM is in ISO 9660 format > +System id: LINUX > +Volume id: SLE-15-Installer-DVD-ppc64le.001 > +Volume set id: > +Publisher id: SUSE LINUX GmbH > +Data preparer id: KIWI - http://opensuse.github.com/kiwi > +Application id: SLE-15-Installer-DVD-ppc64le-Build668.1-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: 303875 > +Joliet with UCS level 3 found > +Rock Ridge signatures version 1 found > diff --git a/tests/isodata/sles/sles15/SLE-15-Installer-DVD-s390x-GM-DVD1.iso.txt b/tests/isodata/sles/sles15/SLE-15-Installer-DVD-s390x-GM-DVD1.iso.txt > new file mode 100644 > index 0000000..abd8938 > --- /dev/null > +++ b/tests/isodata/sles/sles15/SLE-15-Installer-DVD-s390x-GM-DVD1.iso.txt > @@ -0,0 +1,29 @@ > +CD-ROM is in ISO 9660 format > +System id: LINUX > +Volume id: SLE-15-Installer-DVD-s390x66.001 > +Volume set id: > +Publisher id: SUSE LINUX GmbH > +Data preparer id: KIWI - http://opensuse.github.com/kiwi > +Application id: SLE-15-Installer-DVD-s390x-Build668.1-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: 389767 > +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 81 129 > diff --git a/tests/isodata/sles/sles15/SLE-15-Installer-DVD-x86_64-GM-DVD1.iso.txt b/tests/isodata/sles/sles15/SLE-15-Installer-DVD-x86_64-GM-DVD1.iso.txt > new file mode 100644 > index 0000000..85dda21 > --- /dev/null > +++ b/tests/isodata/sles/sles15/SLE-15-Installer-DVD-x86_64-GM-DVD1.iso.txt > @@ -0,0 +1,29 @@ > +CD-ROM is in ISO 9660 format > +System id: LINUX > +Volume id: SLE-15-Installer-DVD-x86_646.001 > +Volume set id: > +Publisher id: SUSE LINUX GmbH > +Data preparer id: KIWI - http://opensuse.github.com/kiwi > +Application id: SLE-15-Installer-DVD-x86_64-Build668.1-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: 324780 > +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 1066 4198 > -- > 1.8.5.6 > > > _______________________________________________ > Libosinfo mailing list > Libosinfo at redhat.com > https://www.redhat.com/mailman/listinfo/libosinfo -- Fabiano Fid?ncio From carnold at suse.com Tue Jul 17 22:14:36 2018 From: carnold at suse.com (Charles Arnold) Date: Tue, 17 Jul 2018 16:14:36 -0600 Subject: [Libosinfo] [PATCH libosinfo] sles: Add SLE15 ISO Information In-Reply-To: References: <5B4E60F3020000910012CA61@prv-mh.provo.novell.com> Message-ID: <5B4E6A4C020000910012CA74@prv-mh.provo.novell.com> >>> On 7/17/2018 at 04:01 PM, Fabiano Fid?ncio wrote: > On Tue, Jul 17, 2018 at 11:34 PM, Charles Arnold wrote: >> >From f94303bcba998f25eb2ee3f77eee71bc36b98067 Mon Sep 17 00:00:00 2001 >> From: Charles Arnold >> Date: Fri, 13 Jul 2018 13:45:21 -0600 >> Subject: [PATCH] sles: Add SLE15 ISO Information >> >> --- >> .../SLE-15-Installer-DVD-aarch64-GM-DVD1.iso.txt | 29 > ++++++++++++++++++++++ >> .../SLE-15-Installer-DVD-ppc64le-GM-DVD1.iso.txt | 16 ++++++++++++ >> .../SLE-15-Installer-DVD-s390x-GM-DVD1.iso.txt | 29 > ++++++++++++++++++++++ >> .../SLE-15-Installer-DVD-x86_64-GM-DVD1.iso.txt | 29 > ++++++++++++++++++++++ >> 4 files changed, 103 insertions(+) >> create mode 100644 > tests/isodata/sles/sles15/SLE-15-Installer-DVD-aarch64-GM-DVD1.iso.txt >> create mode 100644 > tests/isodata/sles/sles15/SLE-15-Installer-DVD-ppc64le-GM-DVD1.iso.txt >> create mode 100644 > tests/isodata/sles/sles15/SLE-15-Installer-DVD-s390x-GM-DVD1.iso.txt >> create mode 100644 > tests/isodata/sles/sles15/SLE-15-Installer-DVD-x86_64-GM-DVD1.iso.txt > > Charles, > > This patch is not correct. As you changed the os id from sles to sle > for this release, you'd also have to move the data provided here to > tests/isodate/sle/sle15/... Right. I should have noticed that. I'll send another patch. - Charles From carnold at suse.com Tue Jul 17 22:21:38 2018 From: carnold at suse.com (Charles Arnold) Date: Tue, 17 Jul 2018 16:21:38 -0600 Subject: [Libosinfo] [PATCH libosinfo v2] sles: Add SLE15 ISO Information Message-ID: <5B4E6BF2020000910012CA7A@prv-mh.provo.novell.com> >From aafaa1b5331dedde60322e0423dfa62c87635da2 Mon Sep 17 00:00:00 2001 From: Charles Arnold Date: Tue, 17 Jul 2018 16:15:00 -0600 Subject: [PATCH] sles: Add SLE15 ISO Information Specify 'sle15' instead of 'sles15' for the path. --- .../SLE-15-Installer-DVD-aarch64-GM-DVD1.iso.txt | 29 ++++++++++++++++++++++ .../SLE-15-Installer-DVD-ppc64le-GM-DVD1.iso.txt | 16 ++++++++++++ .../SLE-15-Installer-DVD-s390x-GM-DVD1.iso.txt | 29 ++++++++++++++++++++++ .../SLE-15-Installer-DVD-x86_64-GM-DVD1.iso.txt | 29 ++++++++++++++++++++++ 4 files changed, 103 insertions(+) create mode 100644 tests/isodata/sles/sle15/SLE-15-Installer-DVD-aarch64-GM-DVD1.iso.txt create mode 100644 tests/isodata/sles/sle15/SLE-15-Installer-DVD-ppc64le-GM-DVD1.iso.txt create mode 100644 tests/isodata/sles/sle15/SLE-15-Installer-DVD-s390x-GM-DVD1.iso.txt create mode 100644 tests/isodata/sles/sle15/SLE-15-Installer-DVD-x86_64-GM-DVD1.iso.txt diff --git a/tests/isodata/sles/sle15/SLE-15-Installer-DVD-aarch64-GM-DVD1.iso.txt b/tests/isodata/sles/sle15/SLE-15-Installer-DVD-aarch64-GM-DVD1.iso.txt new file mode 100644 index 0000000..55949a2 --- /dev/null +++ b/tests/isodata/sles/sle15/SLE-15-Installer-DVD-aarch64-GM-DVD1.iso.txt @@ -0,0 +1,29 @@ +CD-ROM is in ISO 9660 format +System id: LINUX +Volume id: SLE-15-Installer-DVD-aarch64.001 +Volume set id: +Publisher id: SUSE LINUX GmbH +Data preparer id: KIWI - http://opensuse.github.com/kiwi +Application id: SLE-15-Installer-DVD-aarch64-Build668.1-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: 298600 +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 DC8 + Bootoff 8730 34608 diff --git a/tests/isodata/sles/sle15/SLE-15-Installer-DVD-ppc64le-GM-DVD1.iso.txt b/tests/isodata/sles/sle15/SLE-15-Installer-DVD-ppc64le-GM-DVD1.iso.txt new file mode 100644 index 0000000..cc3873f --- /dev/null +++ b/tests/isodata/sles/sle15/SLE-15-Installer-DVD-ppc64le-GM-DVD1.iso.txt @@ -0,0 +1,16 @@ +CD-ROM is in ISO 9660 format +System id: LINUX +Volume id: SLE-15-Installer-DVD-ppc64le.001 +Volume set id: +Publisher id: SUSE LINUX GmbH +Data preparer id: KIWI - http://opensuse.github.com/kiwi +Application id: SLE-15-Installer-DVD-ppc64le-Build668.1-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: 303875 +Joliet with UCS level 3 found +Rock Ridge signatures version 1 found diff --git a/tests/isodata/sles/sle15/SLE-15-Installer-DVD-s390x-GM-DVD1.iso.txt b/tests/isodata/sles/sle15/SLE-15-Installer-DVD-s390x-GM-DVD1.iso.txt new file mode 100644 index 0000000..abd8938 --- /dev/null +++ b/tests/isodata/sles/sle15/SLE-15-Installer-DVD-s390x-GM-DVD1.iso.txt @@ -0,0 +1,29 @@ +CD-ROM is in ISO 9660 format +System id: LINUX +Volume id: SLE-15-Installer-DVD-s390x66.001 +Volume set id: +Publisher id: SUSE LINUX GmbH +Data preparer id: KIWI - http://opensuse.github.com/kiwi +Application id: SLE-15-Installer-DVD-s390x-Build668.1-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: 389767 +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 81 129 diff --git a/tests/isodata/sles/sle15/SLE-15-Installer-DVD-x86_64-GM-DVD1.iso.txt b/tests/isodata/sles/sle15/SLE-15-Installer-DVD-x86_64-GM-DVD1.iso.txt new file mode 100644 index 0000000..85dda21 --- /dev/null +++ b/tests/isodata/sles/sle15/SLE-15-Installer-DVD-x86_64-GM-DVD1.iso.txt @@ -0,0 +1,29 @@ +CD-ROM is in ISO 9660 format +System id: LINUX +Volume id: SLE-15-Installer-DVD-x86_646.001 +Volume set id: +Publisher id: SUSE LINUX GmbH +Data preparer id: KIWI - http://opensuse.github.com/kiwi +Application id: SLE-15-Installer-DVD-x86_64-Build668.1-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: 324780 +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 1066 4198 -- 1.8.5.6 From fabiano at fidencio.org Wed Jul 18 05:36:13 2018 From: fabiano at fidencio.org (=?UTF-8?Q?Fabiano_Fid=C3=AAncio?=) Date: Wed, 18 Jul 2018 07:36:13 +0200 Subject: [Libosinfo] [PATCH libosinfo v2] sles: Add SLE15 ISO Information In-Reply-To: <5B4E6BF2020000910012CA7A@prv-mh.provo.novell.com> References: <5B4E6BF2020000910012CA7A@prv-mh.provo.novell.com> Message-ID: On Wed, Jul 18, 2018 at 12:21 AM, Charles Arnold wrote: > >From aafaa1b5331dedde60322e0423dfa62c87635da2 Mon Sep 17 00:00:00 2001 > From: Charles Arnold > Date: Tue, 17 Jul 2018 16:15:00 -0600 > Subject: [PATCH] sles: Add SLE15 ISO Information > > Specify 'sle15' instead of 'sles15' for the path. > > --- > .../SLE-15-Installer-DVD-aarch64-GM-DVD1.iso.txt | 29 ++++++++++++++++++++++ > .../SLE-15-Installer-DVD-ppc64le-GM-DVD1.iso.txt | 16 ++++++++++++ > .../SLE-15-Installer-DVD-s390x-GM-DVD1.iso.txt | 29 ++++++++++++++++++++++ > .../SLE-15-Installer-DVD-x86_64-GM-DVD1.iso.txt | 29 ++++++++++++++++++++++ > 4 files changed, 103 insertions(+) > create mode 100644 tests/isodata/sles/sle15/SLE-15-Installer-DVD-aarch64-GM-DVD1.iso.txt > create mode 100644 tests/isodata/sles/sle15/SLE-15-Installer-DVD-ppc64le-GM-DVD1.iso.txt > create mode 100644 tests/isodata/sles/sle15/SLE-15-Installer-DVD-s390x-GM-DVD1.iso.txt > create mode 100644 tests/isodata/sles/sle15/SLE-15-Installer-DVD-x86_64-GM-DVD1.iso.txt Thanks for the change! I've ran make check and it passed without any issue. I'll merge the patches later Today. > > diff --git a/tests/isodata/sles/sle15/SLE-15-Installer-DVD-aarch64-GM-DVD1.iso.txt b/tests/isodata/sles/sle15/SLE-15-Installer-DVD-aarch64-GM-DVD1.iso.txt > new file mode 100644 > index 0000000..55949a2 > --- /dev/null > +++ b/tests/isodata/sles/sle15/SLE-15-Installer-DVD-aarch64-GM-DVD1.iso.txt > @@ -0,0 +1,29 @@ > +CD-ROM is in ISO 9660 format > +System id: LINUX > +Volume id: SLE-15-Installer-DVD-aarch64.001 > +Volume set id: > +Publisher id: SUSE LINUX GmbH > +Data preparer id: KIWI - http://opensuse.github.com/kiwi > +Application id: SLE-15-Installer-DVD-aarch64-Build668.1-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: 298600 > +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 DC8 > + Bootoff 8730 34608 > diff --git a/tests/isodata/sles/sle15/SLE-15-Installer-DVD-ppc64le-GM-DVD1.iso.txt b/tests/isodata/sles/sle15/SLE-15-Installer-DVD-ppc64le-GM-DVD1.iso.txt > new file mode 100644 > index 0000000..cc3873f > --- /dev/null > +++ b/tests/isodata/sles/sle15/SLE-15-Installer-DVD-ppc64le-GM-DVD1.iso.txt > @@ -0,0 +1,16 @@ > +CD-ROM is in ISO 9660 format > +System id: LINUX > +Volume id: SLE-15-Installer-DVD-ppc64le.001 > +Volume set id: > +Publisher id: SUSE LINUX GmbH > +Data preparer id: KIWI - http://opensuse.github.com/kiwi > +Application id: SLE-15-Installer-DVD-ppc64le-Build668.1-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: 303875 > +Joliet with UCS level 3 found > +Rock Ridge signatures version 1 found > diff --git a/tests/isodata/sles/sle15/SLE-15-Installer-DVD-s390x-GM-DVD1.iso.txt b/tests/isodata/sles/sle15/SLE-15-Installer-DVD-s390x-GM-DVD1.iso.txt > new file mode 100644 > index 0000000..abd8938 > --- /dev/null > +++ b/tests/isodata/sles/sle15/SLE-15-Installer-DVD-s390x-GM-DVD1.iso.txt > @@ -0,0 +1,29 @@ > +CD-ROM is in ISO 9660 format > +System id: LINUX > +Volume id: SLE-15-Installer-DVD-s390x66.001 > +Volume set id: > +Publisher id: SUSE LINUX GmbH > +Data preparer id: KIWI - http://opensuse.github.com/kiwi > +Application id: SLE-15-Installer-DVD-s390x-Build668.1-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: 389767 > +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 81 129 > diff --git a/tests/isodata/sles/sle15/SLE-15-Installer-DVD-x86_64-GM-DVD1.iso.txt b/tests/isodata/sles/sle15/SLE-15-Installer-DVD-x86_64-GM-DVD1.iso.txt > new file mode 100644 > index 0000000..85dda21 > --- /dev/null > +++ b/tests/isodata/sles/sle15/SLE-15-Installer-DVD-x86_64-GM-DVD1.iso.txt > @@ -0,0 +1,29 @@ > +CD-ROM is in ISO 9660 format > +System id: LINUX > +Volume id: SLE-15-Installer-DVD-x86_646.001 > +Volume set id: > +Publisher id: SUSE LINUX GmbH > +Data preparer id: KIWI - http://opensuse.github.com/kiwi > +Application id: SLE-15-Installer-DVD-x86_64-Build668.1-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: 324780 > +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 1066 4198 > -- > 1.8.5.6 > > > _______________________________________________ > Libosinfo mailing list > Libosinfo at redhat.com > https://www.redhat.com/mailman/listinfo/libosinfo -- Fabiano Fid?ncio From vbudikov at redhat.com Wed Jul 18 05:43:20 2018 From: vbudikov at redhat.com (=?UTF-8?q?V=C4=9Bra=20Cholasta?=) Date: Wed, 18 Jul 2018 07:43:20 +0200 Subject: [Libosinfo] [PATCH] Add alpinelinux 3.8 support Message-ID: <1531892600-10925-1-git-send-email-vbudikov@redhat.com> --- data/os/alpinelinux.org/alpinelinux-3.8.xml.in | 50 ++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 data/os/alpinelinux.org/alpinelinux-3.8.xml.in diff --git a/data/os/alpinelinux.org/alpinelinux-3.8.xml.in b/data/os/alpinelinux.org/alpinelinux-3.8.xml.in new file mode 100644 index 0000000..4aaa321 --- /dev/null +++ b/data/os/alpinelinux.org/alpinelinux-3.8.xml.in @@ -0,0 +1,50 @@ + + + + + alpinelinux3.8 + <_name>Alpine Linux 3.8 + 3.8 + <_vendor>Alpine Linux Project + linux + alpinelinux + + + + + + 1000000000 + 1 + 134217728 + 1073741824 + + + 1000000000 + 1 + 805306368 + 4294967296 + + + + + alpine-.* 3.8.\d x86$ + + + + + alpine-.* 3.8.\d x86_64.* + + + + + alpine-.* 3.8.\d ppc64le + + + + + alpine-.* 3.8.\d s390x$ + + + + -- 1.8.3.1 From vbudikov at redhat.com Wed Jul 18 06:31:44 2018 From: vbudikov at redhat.com (=?UTF-8?q?V=C4=9Bra=20Cholasta?=) Date: Wed, 18 Jul 2018 08:31:44 +0200 Subject: [Libosinfo] [libosinfo] Add test files for Alpinelinux 3.8 Message-ID: <1531895504-14155-1-git-send-email-vbudikov@redhat.com> --- .../alpine-standard-3.8.0-ppc64le.iso.txt | 16 ++++++++++++ .../alpine-standard-3.8.0-s390x.iso.txt | 29 ++++++++++++++++++++++ .../alpine-standard-3.8.0-x86.iso.txt | 29 ++++++++++++++++++++++ .../alpine-standard-3.8.0-x86_64.iso.txt | 29 ++++++++++++++++++++++ .../alpinelinux3.8/alpine-virt-3.8.0-x86.iso.txt | 29 ++++++++++++++++++++++ .../alpine-virt-3.8.0-x86_64.iso.txt | 29 ++++++++++++++++++++++ .../alpinelinux3.8/alpine-xen-3.8.0-x86_64.iso.txt | 29 ++++++++++++++++++++++ 7 files changed, 190 insertions(+) create mode 100644 tests/isodata/alpinelinux/alpinelinux3.8/alpine-standard-3.8.0-ppc64le.iso.txt create mode 100644 tests/isodata/alpinelinux/alpinelinux3.8/alpine-standard-3.8.0-s390x.iso.txt create mode 100644 tests/isodata/alpinelinux/alpinelinux3.8/alpine-standard-3.8.0-x86.iso.txt create mode 100644 tests/isodata/alpinelinux/alpinelinux3.8/alpine-standard-3.8.0-x86_64.iso.txt create mode 100644 tests/isodata/alpinelinux/alpinelinux3.8/alpine-virt-3.8.0-x86.iso.txt create mode 100644 tests/isodata/alpinelinux/alpinelinux3.8/alpine-virt-3.8.0-x86_64.iso.txt create mode 100644 tests/isodata/alpinelinux/alpinelinux3.8/alpine-xen-3.8.0-x86_64.iso.txt diff --git a/tests/isodata/alpinelinux/alpinelinux3.8/alpine-standard-3.8.0-ppc64le.iso.txt b/tests/isodata/alpinelinux/alpinelinux3.8/alpine-standard-3.8.0-ppc64le.iso.txt new file mode 100644 index 0000000..7de68d9 --- /dev/null +++ b/tests/isodata/alpinelinux/alpinelinux3.8/alpine-standard-3.8.0-ppc64le.iso.txt @@ -0,0 +1,16 @@ +CD-ROM is in ISO 9660 format +System id: LINUX +Volume id: alpine-std 3.8.0 ppc64le +Volume set id: +Publisher id: +Data preparer id: XORRISO-1.4.8 2017.09.12.143001, LIBISOBURN-1.4.8, LIBISOFS-1.4.8, LIBBURN-1.4.8 +Application id: +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: 25399 +NO Joliet present +Rock Ridge signatures version 1 found diff --git a/tests/isodata/alpinelinux/alpinelinux3.8/alpine-standard-3.8.0-s390x.iso.txt b/tests/isodata/alpinelinux/alpinelinux3.8/alpine-standard-3.8.0-s390x.iso.txt new file mode 100644 index 0000000..456aa82 --- /dev/null +++ b/tests/isodata/alpinelinux/alpinelinux3.8/alpine-standard-3.8.0-s390x.iso.txt @@ -0,0 +1,29 @@ +CD-ROM is in ISO 9660 format +System id: LINUX +Volume id: alpine-std 3.8.0 s390x +Volume set id: +Publisher id: +Data preparer id: XORRISO-1.4.8 2017.09.12.143001, LIBISOBURN-1.4.8, LIBISOFS-1.4.8, LIBBURN-1.4.8 +Application id: +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: 26135 +El Torito VD version 1 found, boot catalog is in sector 41 +Joliet with UCS level 3 found +Rock Ridge signatures version 1 found +Eltorito validation header: + Hid 1 + Arch 0 (x86) + ID '' + Key 55 AA + Eltorito defaultboot header: + Bootid 88 (bootable) + Boot media 0 (No Emulation Boot) + Load segment 0 + Sys type 0 + Nsect 779C + Bootoff 2A 42 diff --git a/tests/isodata/alpinelinux/alpinelinux3.8/alpine-standard-3.8.0-x86.iso.txt b/tests/isodata/alpinelinux/alpinelinux3.8/alpine-standard-3.8.0-x86.iso.txt new file mode 100644 index 0000000..ad7eec2 --- /dev/null +++ b/tests/isodata/alpinelinux/alpinelinux3.8/alpine-standard-3.8.0-x86.iso.txt @@ -0,0 +1,29 @@ +CD-ROM is in ISO 9660 format +System id: LINUX +Volume id: alpine-std 3.8.0 x86 +Volume set id: +Publisher id: +Data preparer id: XORRISO-1.4.8 2017.09.12.143001, LIBISOBURN-1.4.8, LIBISOFS-1.4.8, LIBBURN-1.4.8 +Application id: +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: 48640 +El Torito VD version 1 found, boot catalog is in sector 48 +Joliet with UCS level 3 found +Rock Ridge signatures version 1 found +Eltorito validation header: + Hid 1 + Arch 0 (x86) + ID '' + Key 55 AA + Eltorito defaultboot header: + Bootid 88 (bootable) + Boot media 0 (No Emulation Boot) + Load segment 0 + Sys type 0 + Nsect 4 + Bootoff 31 49 diff --git a/tests/isodata/alpinelinux/alpinelinux3.8/alpine-standard-3.8.0-x86_64.iso.txt b/tests/isodata/alpinelinux/alpinelinux3.8/alpine-standard-3.8.0-x86_64.iso.txt new file mode 100644 index 0000000..ed4af59 --- /dev/null +++ b/tests/isodata/alpinelinux/alpinelinux3.8/alpine-standard-3.8.0-x86_64.iso.txt @@ -0,0 +1,29 @@ +CD-ROM is in ISO 9660 format +System id: LINUX +Volume id: alpine-std 3.8.0 x86_64 +Volume set id: +Publisher id: +Data preparer id: XORRISO-1.4.8 2017.09.12.143001, LIBISOBURN-1.4.8, LIBISOFS-1.4.8, LIBBURN-1.4.8 +Application id: +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: 53248 +El Torito VD version 1 found, boot catalog is in sector 48 +Joliet with UCS level 3 found +Rock Ridge signatures version 1 found +Eltorito validation header: + Hid 1 + Arch 0 (x86) + ID '' + Key 55 AA + Eltorito defaultboot header: + Bootid 88 (bootable) + Boot media 0 (No Emulation Boot) + Load segment 0 + Sys type 0 + Nsect 4 + Bootoff 31 49 diff --git a/tests/isodata/alpinelinux/alpinelinux3.8/alpine-virt-3.8.0-x86.iso.txt b/tests/isodata/alpinelinux/alpinelinux3.8/alpine-virt-3.8.0-x86.iso.txt new file mode 100644 index 0000000..86781cd --- /dev/null +++ b/tests/isodata/alpinelinux/alpinelinux3.8/alpine-virt-3.8.0-x86.iso.txt @@ -0,0 +1,29 @@ +CD-ROM is in ISO 9660 format +System id: LINUX +Volume id: alpine-virt 3.8.0 x86 +Volume set id: +Publisher id: +Data preparer id: XORRISO-1.4.8 2017.09.12.143001, LIBISOBURN-1.4.8, LIBISOFS-1.4.8, LIBBURN-1.4.8 +Application id: +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: 14848 +El Torito VD version 1 found, boot catalog is in sector 48 +Joliet with UCS level 3 found +Rock Ridge signatures version 1 found +Eltorito validation header: + Hid 1 + Arch 0 (x86) + ID '' + Key 55 AA + Eltorito defaultboot header: + Bootid 88 (bootable) + Boot media 0 (No Emulation Boot) + Load segment 0 + Sys type 0 + Nsect 4 + Bootoff 31 49 diff --git a/tests/isodata/alpinelinux/alpinelinux3.8/alpine-virt-3.8.0-x86_64.iso.txt b/tests/isodata/alpinelinux/alpinelinux3.8/alpine-virt-3.8.0-x86_64.iso.txt new file mode 100644 index 0000000..dbda887 --- /dev/null +++ b/tests/isodata/alpinelinux/alpinelinux3.8/alpine-virt-3.8.0-x86_64.iso.txt @@ -0,0 +1,29 @@ +CD-ROM is in ISO 9660 format +System id: LINUX +Volume id: alpine-virt 3.8.0 x86_64 +Volume set id: +Publisher id: +Data preparer id: XORRISO-1.4.8 2017.09.12.143001, LIBISOBURN-1.4.8, LIBISOFS-1.4.8, LIBBURN-1.4.8 +Application id: +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: 16384 +El Torito VD version 1 found, boot catalog is in sector 48 +Joliet with UCS level 3 found +Rock Ridge signatures version 1 found +Eltorito validation header: + Hid 1 + Arch 0 (x86) + ID '' + Key 55 AA + Eltorito defaultboot header: + Bootid 88 (bootable) + Boot media 0 (No Emulation Boot) + Load segment 0 + Sys type 0 + Nsect 4 + Bootoff 31 49 diff --git a/tests/isodata/alpinelinux/alpinelinux3.8/alpine-xen-3.8.0-x86_64.iso.txt b/tests/isodata/alpinelinux/alpinelinux3.8/alpine-xen-3.8.0-x86_64.iso.txt new file mode 100644 index 0000000..a5f7717 --- /dev/null +++ b/tests/isodata/alpinelinux/alpinelinux3.8/alpine-xen-3.8.0-x86_64.iso.txt @@ -0,0 +1,29 @@ +CD-ROM is in ISO 9660 format +System id: LINUX +Volume id: alpine-xen 3.8.0 x86_64 +Volume set id: +Publisher id: +Data preparer id: XORRISO-1.4.8 2017.09.12.143001, LIBISOBURN-1.4.8, LIBISOFS-1.4.8, LIBBURN-1.4.8 +Application id: +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: 78848 +El Torito VD version 1 found, boot catalog is in sector 57 +Joliet with UCS level 3 found +Rock Ridge signatures version 1 found +Eltorito validation header: + Hid 1 + Arch 0 (x86) + ID '' + Key 55 AA + Eltorito defaultboot header: + Bootid 88 (bootable) + Boot media 0 (No Emulation Boot) + Load segment 0 + Sys type 0 + Nsect 4 + Bootoff 30A 778 -- 1.8.3.1 From cfergeau at redhat.com Wed Jul 18 08:31:57 2018 From: cfergeau at redhat.com (Christophe Fergeau) Date: Wed, 18 Jul 2018 10:31:57 +0200 Subject: [Libosinfo] [PATCH] Add alpinelinux 3.8 support In-Reply-To: <1531892600-10925-1-git-send-email-vbudikov@redhat.com> References: <1531892600-10925-1-git-send-email-vbudikov@redhat.com> Message-ID: <20180718083157.GZ5388@natto.ory.fergeau.eu> Hey, this looks good to me, just a few small nits: On Wed, Jul 18, 2018 at 07:43:20AM +0200, V?ra Cholasta wrote: > --- > data/os/alpinelinux.org/alpinelinux-3.8.xml.in | 50 ++++++++++++++++++++++++++ > 1 file changed, 50 insertions(+) > create mode 100644 data/os/alpinelinux.org/alpinelinux-3.8.xml.in > > diff --git a/data/os/alpinelinux.org/alpinelinux-3.8.xml.in b/data/os/alpinelinux.org/alpinelinux-3.8.xml.in > new file mode 100644 > index 0000000..4aaa321 > --- /dev/null > +++ b/data/os/alpinelinux.org/alpinelinux-3.8.xml.in > @@ -0,0 +1,50 @@ > + > + > + > + > + alpinelinux3.8 > + <_name>Alpine Linux 3.8 > + 3.8 > + <_vendor>Alpine Linux Project > + linux > + alpinelinux > + > + > + > + > + > + 1000000000 > + 1 > + 134217728 > + 1073741824 > + > + > + 1000000000 > + 1 > + 805306368 > + 4294967296 I'd remove the tabs at the beginning of the lines and replace them with spaces > + > + > + > + > + alpine-.* 3.8.\d x86$ > + > + > + > + > + alpine-.* 3.8.\d x86_64.* Any reason for using .* here at the end of the regex? I guess it could be $ as for the others? > + > + > + > + > + alpine-.* 3.8.\d ppc64le Ditto here, I guess it could be made consistent with the others with a $ (I did not test these suggestions against the testsuite though). I can make these adjustments before pushing, no need for a v2. Thanks for the patches, Christophe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From cfergeau at redhat.com Wed Jul 18 08:32:09 2018 From: cfergeau at redhat.com (Christophe Fergeau) Date: Wed, 18 Jul 2018 10:32:09 +0200 Subject: [Libosinfo] [libosinfo] Add test files for Alpinelinux 3.8 In-Reply-To: <1531895504-14155-1-git-send-email-vbudikov@redhat.com> References: <1531895504-14155-1-git-send-email-vbudikov@redhat.com> Message-ID: <20180718083209.GA5388@natto.ory.fergeau.eu> Acked-by: Christophe Fergeau On Wed, Jul 18, 2018 at 08:31:44AM +0200, V?ra Cholasta wrote: > --- > .../alpine-standard-3.8.0-ppc64le.iso.txt | 16 ++++++++++++ > .../alpine-standard-3.8.0-s390x.iso.txt | 29 ++++++++++++++++++++++ > .../alpine-standard-3.8.0-x86.iso.txt | 29 ++++++++++++++++++++++ > .../alpine-standard-3.8.0-x86_64.iso.txt | 29 ++++++++++++++++++++++ > .../alpinelinux3.8/alpine-virt-3.8.0-x86.iso.txt | 29 ++++++++++++++++++++++ > .../alpine-virt-3.8.0-x86_64.iso.txt | 29 ++++++++++++++++++++++ > .../alpinelinux3.8/alpine-xen-3.8.0-x86_64.iso.txt | 29 ++++++++++++++++++++++ > 7 files changed, 190 insertions(+) > create mode 100644 tests/isodata/alpinelinux/alpinelinux3.8/alpine-standard-3.8.0-ppc64le.iso.txt > create mode 100644 tests/isodata/alpinelinux/alpinelinux3.8/alpine-standard-3.8.0-s390x.iso.txt > create mode 100644 tests/isodata/alpinelinux/alpinelinux3.8/alpine-standard-3.8.0-x86.iso.txt > create mode 100644 tests/isodata/alpinelinux/alpinelinux3.8/alpine-standard-3.8.0-x86_64.iso.txt > create mode 100644 tests/isodata/alpinelinux/alpinelinux3.8/alpine-virt-3.8.0-x86.iso.txt > create mode 100644 tests/isodata/alpinelinux/alpinelinux3.8/alpine-virt-3.8.0-x86_64.iso.txt > create mode 100644 tests/isodata/alpinelinux/alpinelinux3.8/alpine-xen-3.8.0-x86_64.iso.txt > > diff --git a/tests/isodata/alpinelinux/alpinelinux3.8/alpine-standard-3.8.0-ppc64le.iso.txt b/tests/isodata/alpinelinux/alpinelinux3.8/alpine-standard-3.8.0-ppc64le.iso.txt > new file mode 100644 > index 0000000..7de68d9 > --- /dev/null > +++ b/tests/isodata/alpinelinux/alpinelinux3.8/alpine-standard-3.8.0-ppc64le.iso.txt > @@ -0,0 +1,16 @@ > +CD-ROM is in ISO 9660 format > +System id: LINUX > +Volume id: alpine-std 3.8.0 ppc64le > +Volume set id: > +Publisher id: > +Data preparer id: XORRISO-1.4.8 2017.09.12.143001, LIBISOBURN-1.4.8, LIBISOFS-1.4.8, LIBBURN-1.4.8 > +Application id: > +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: 25399 > +NO Joliet present > +Rock Ridge signatures version 1 found > diff --git a/tests/isodata/alpinelinux/alpinelinux3.8/alpine-standard-3.8.0-s390x.iso.txt b/tests/isodata/alpinelinux/alpinelinux3.8/alpine-standard-3.8.0-s390x.iso.txt > new file mode 100644 > index 0000000..456aa82 > --- /dev/null > +++ b/tests/isodata/alpinelinux/alpinelinux3.8/alpine-standard-3.8.0-s390x.iso.txt > @@ -0,0 +1,29 @@ > +CD-ROM is in ISO 9660 format > +System id: LINUX > +Volume id: alpine-std 3.8.0 s390x > +Volume set id: > +Publisher id: > +Data preparer id: XORRISO-1.4.8 2017.09.12.143001, LIBISOBURN-1.4.8, LIBISOFS-1.4.8, LIBBURN-1.4.8 > +Application id: > +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: 26135 > +El Torito VD version 1 found, boot catalog is in sector 41 > +Joliet with UCS level 3 found > +Rock Ridge signatures version 1 found > +Eltorito validation header: > + Hid 1 > + Arch 0 (x86) > + ID '' > + Key 55 AA > + Eltorito defaultboot header: > + Bootid 88 (bootable) > + Boot media 0 (No Emulation Boot) > + Load segment 0 > + Sys type 0 > + Nsect 779C > + Bootoff 2A 42 > diff --git a/tests/isodata/alpinelinux/alpinelinux3.8/alpine-standard-3.8.0-x86.iso.txt b/tests/isodata/alpinelinux/alpinelinux3.8/alpine-standard-3.8.0-x86.iso.txt > new file mode 100644 > index 0000000..ad7eec2 > --- /dev/null > +++ b/tests/isodata/alpinelinux/alpinelinux3.8/alpine-standard-3.8.0-x86.iso.txt > @@ -0,0 +1,29 @@ > +CD-ROM is in ISO 9660 format > +System id: LINUX > +Volume id: alpine-std 3.8.0 x86 > +Volume set id: > +Publisher id: > +Data preparer id: XORRISO-1.4.8 2017.09.12.143001, LIBISOBURN-1.4.8, LIBISOFS-1.4.8, LIBBURN-1.4.8 > +Application id: > +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: 48640 > +El Torito VD version 1 found, boot catalog is in sector 48 > +Joliet with UCS level 3 found > +Rock Ridge signatures version 1 found > +Eltorito validation header: > + Hid 1 > + Arch 0 (x86) > + ID '' > + Key 55 AA > + Eltorito defaultboot header: > + Bootid 88 (bootable) > + Boot media 0 (No Emulation Boot) > + Load segment 0 > + Sys type 0 > + Nsect 4 > + Bootoff 31 49 > diff --git a/tests/isodata/alpinelinux/alpinelinux3.8/alpine-standard-3.8.0-x86_64.iso.txt b/tests/isodata/alpinelinux/alpinelinux3.8/alpine-standard-3.8.0-x86_64.iso.txt > new file mode 100644 > index 0000000..ed4af59 > --- /dev/null > +++ b/tests/isodata/alpinelinux/alpinelinux3.8/alpine-standard-3.8.0-x86_64.iso.txt > @@ -0,0 +1,29 @@ > +CD-ROM is in ISO 9660 format > +System id: LINUX > +Volume id: alpine-std 3.8.0 x86_64 > +Volume set id: > +Publisher id: > +Data preparer id: XORRISO-1.4.8 2017.09.12.143001, LIBISOBURN-1.4.8, LIBISOFS-1.4.8, LIBBURN-1.4.8 > +Application id: > +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: 53248 > +El Torito VD version 1 found, boot catalog is in sector 48 > +Joliet with UCS level 3 found > +Rock Ridge signatures version 1 found > +Eltorito validation header: > + Hid 1 > + Arch 0 (x86) > + ID '' > + Key 55 AA > + Eltorito defaultboot header: > + Bootid 88 (bootable) > + Boot media 0 (No Emulation Boot) > + Load segment 0 > + Sys type 0 > + Nsect 4 > + Bootoff 31 49 > diff --git a/tests/isodata/alpinelinux/alpinelinux3.8/alpine-virt-3.8.0-x86.iso.txt b/tests/isodata/alpinelinux/alpinelinux3.8/alpine-virt-3.8.0-x86.iso.txt > new file mode 100644 > index 0000000..86781cd > --- /dev/null > +++ b/tests/isodata/alpinelinux/alpinelinux3.8/alpine-virt-3.8.0-x86.iso.txt > @@ -0,0 +1,29 @@ > +CD-ROM is in ISO 9660 format > +System id: LINUX > +Volume id: alpine-virt 3.8.0 x86 > +Volume set id: > +Publisher id: > +Data preparer id: XORRISO-1.4.8 2017.09.12.143001, LIBISOBURN-1.4.8, LIBISOFS-1.4.8, LIBBURN-1.4.8 > +Application id: > +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: 14848 > +El Torito VD version 1 found, boot catalog is in sector 48 > +Joliet with UCS level 3 found > +Rock Ridge signatures version 1 found > +Eltorito validation header: > + Hid 1 > + Arch 0 (x86) > + ID '' > + Key 55 AA > + Eltorito defaultboot header: > + Bootid 88 (bootable) > + Boot media 0 (No Emulation Boot) > + Load segment 0 > + Sys type 0 > + Nsect 4 > + Bootoff 31 49 > diff --git a/tests/isodata/alpinelinux/alpinelinux3.8/alpine-virt-3.8.0-x86_64.iso.txt b/tests/isodata/alpinelinux/alpinelinux3.8/alpine-virt-3.8.0-x86_64.iso.txt > new file mode 100644 > index 0000000..dbda887 > --- /dev/null > +++ b/tests/isodata/alpinelinux/alpinelinux3.8/alpine-virt-3.8.0-x86_64.iso.txt > @@ -0,0 +1,29 @@ > +CD-ROM is in ISO 9660 format > +System id: LINUX > +Volume id: alpine-virt 3.8.0 x86_64 > +Volume set id: > +Publisher id: > +Data preparer id: XORRISO-1.4.8 2017.09.12.143001, LIBISOBURN-1.4.8, LIBISOFS-1.4.8, LIBBURN-1.4.8 > +Application id: > +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: 16384 > +El Torito VD version 1 found, boot catalog is in sector 48 > +Joliet with UCS level 3 found > +Rock Ridge signatures version 1 found > +Eltorito validation header: > + Hid 1 > + Arch 0 (x86) > + ID '' > + Key 55 AA > + Eltorito defaultboot header: > + Bootid 88 (bootable) > + Boot media 0 (No Emulation Boot) > + Load segment 0 > + Sys type 0 > + Nsect 4 > + Bootoff 31 49 > diff --git a/tests/isodata/alpinelinux/alpinelinux3.8/alpine-xen-3.8.0-x86_64.iso.txt b/tests/isodata/alpinelinux/alpinelinux3.8/alpine-xen-3.8.0-x86_64.iso.txt > new file mode 100644 > index 0000000..a5f7717 > --- /dev/null > +++ b/tests/isodata/alpinelinux/alpinelinux3.8/alpine-xen-3.8.0-x86_64.iso.txt > @@ -0,0 +1,29 @@ > +CD-ROM is in ISO 9660 format > +System id: LINUX > +Volume id: alpine-xen 3.8.0 x86_64 > +Volume set id: > +Publisher id: > +Data preparer id: XORRISO-1.4.8 2017.09.12.143001, LIBISOBURN-1.4.8, LIBISOFS-1.4.8, LIBBURN-1.4.8 > +Application id: > +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: 78848 > +El Torito VD version 1 found, boot catalog is in sector 57 > +Joliet with UCS level 3 found > +Rock Ridge signatures version 1 found > +Eltorito validation header: > + Hid 1 > + Arch 0 (x86) > + ID '' > + Key 55 AA > + Eltorito defaultboot header: > + Bootid 88 (bootable) > + Boot media 0 (No Emulation Boot) > + Load segment 0 > + Sys type 0 > + Nsect 4 > + Bootoff 30A 778 > -- > 1.8.3.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 vbudikov at redhat.com Wed Jul 18 08:52:52 2018 From: vbudikov at redhat.com (=?UTF-8?q?V=C4=9Bra=20Cholasta?=) Date: Wed, 18 Jul 2018 10:52:52 +0200 Subject: [Libosinfo] [libosinfo] Add RHEL6.10 iso test files Message-ID: <1531903972-24021-1-git-send-email-vbudikov@redhat.com> --- .../RHEL-6.10-20180525.0-Server-i386-dvd1.iso.txt | 29 ++++++++++++++++++++++ .../RHEL-6.10-20180525.0-Server-ppc64-dvd1.iso.txt | 16 ++++++++++++ .../RHEL-6.10-20180525.0-Server-s390x-dvd1.iso.txt | 16 ++++++++++++ ...RHEL-6.10-20180525.0-Server-x86_64-dvd1.iso.txt | 29 ++++++++++++++++++++++ 4 files changed, 90 insertions(+) create mode 100644 tests/isodata/rhel/rhel6.10/RHEL-6.10-20180525.0-Server-i386-dvd1.iso.txt create mode 100644 tests/isodata/rhel/rhel6.10/RHEL-6.10-20180525.0-Server-ppc64-dvd1.iso.txt create mode 100644 tests/isodata/rhel/rhel6.10/RHEL-6.10-20180525.0-Server-s390x-dvd1.iso.txt create mode 100644 tests/isodata/rhel/rhel6.10/RHEL-6.10-20180525.0-Server-x86_64-dvd1.iso.txt diff --git a/tests/isodata/rhel/rhel6.10/RHEL-6.10-20180525.0-Server-i386-dvd1.iso.txt b/tests/isodata/rhel/rhel6.10/RHEL-6.10-20180525.0-Server-i386-dvd1.iso.txt new file mode 100644 index 0000000..0f76ed8 --- /dev/null +++ b/tests/isodata/rhel/rhel6.10/RHEL-6.10-20180525.0-Server-i386-dvd1.iso.txt @@ -0,0 +1,29 @@ +CD-ROM is in ISO 9660 format +System id: LINUX +Volume id: RHEL-6.10 Server.i386 +Volume set id: +Publisher id: +Data preparer id: +Application id: GENISOIMAGE ISO 9660/HFS FILESYSTEM CREATOR (C) 1993 E.YOUNGDALE (C) 1997-2006 J.PEARSON/J.SCHILLING (C) 2006-2007 CDRKIT TEAM +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: 1592449 +El Torito VD version 1 found, boot catalog is in sector 499 +Joliet with UCS level 3 found +Rock Ridge signatures version 1 found +Eltorito validation header: + Hid 1 + Arch 0 (x86) + ID '' + Key 55 AA + Eltorito defaultboot header: + Bootid 88 (bootable) + Boot media 0 (No Emulation Boot) + Load segment 0 + Sys type 0 + Nsect 4 + Bootoff 17A32 96818 diff --git a/tests/isodata/rhel/rhel6.10/RHEL-6.10-20180525.0-Server-ppc64-dvd1.iso.txt b/tests/isodata/rhel/rhel6.10/RHEL-6.10-20180525.0-Server-ppc64-dvd1.iso.txt new file mode 100644 index 0000000..cc10d0e --- /dev/null +++ b/tests/isodata/rhel/rhel6.10/RHEL-6.10-20180525.0-Server-ppc64-dvd1.iso.txt @@ -0,0 +1,16 @@ +CD-ROM is in ISO 9660 format +System id: PPC +Volume id: RHEL-6.10 Server.ppc64 +Volume set id: +Publisher id: +Data preparer id: +Application id: GENISOIMAGE ISO 9660/HFS FILESYSTEM CREATOR (C) 1993 E.YOUNGDALE (C) 1997-2006 J.PEARSON/J.SCHILLING (C) 2006-2007 CDRKIT TEAM +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: 1653048 +Joliet with UCS level 3 found +Rock Ridge signatures version 1 found diff --git a/tests/isodata/rhel/rhel6.10/RHEL-6.10-20180525.0-Server-s390x-dvd1.iso.txt b/tests/isodata/rhel/rhel6.10/RHEL-6.10-20180525.0-Server-s390x-dvd1.iso.txt new file mode 100644 index 0000000..dec83f1 --- /dev/null +++ b/tests/isodata/rhel/rhel6.10/RHEL-6.10-20180525.0-Server-s390x-dvd1.iso.txt @@ -0,0 +1,16 @@ +CD-ROM is in ISO 9660 format +System id: LINUX +Volume id: RHEL-6.10 Server.s390x +Volume set id: +Publisher id: +Data preparer id: +Application id: GENISOIMAGE ISO 9660/HFS FILESYSTEM CREATOR (C) 1993 E.YOUNGDALE (C) 1997-2006 J.PEARSON/J.SCHILLING (C) 2006-2007 CDRKIT TEAM +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: 1447366 +Joliet with UCS level 3 found +Rock Ridge signatures version 1 found diff --git a/tests/isodata/rhel/rhel6.10/RHEL-6.10-20180525.0-Server-x86_64-dvd1.iso.txt b/tests/isodata/rhel/rhel6.10/RHEL-6.10-20180525.0-Server-x86_64-dvd1.iso.txt new file mode 100644 index 0000000..6a2ff12 --- /dev/null +++ b/tests/isodata/rhel/rhel6.10/RHEL-6.10-20180525.0-Server-x86_64-dvd1.iso.txt @@ -0,0 +1,29 @@ +CD-ROM is in ISO 9660 format +System id: LINUX +Volume id: RHEL-6.10 Server.x86_64 +Volume set id: +Publisher id: +Data preparer id: +Application id: GENISOIMAGE ISO 9660/HFS FILESYSTEM CREATOR (C) 1993 E.YOUNGDALE (C) 1997-2006 J.PEARSON/J.SCHILLING (C) 2006-2007 CDRKIT TEAM +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: 1902115 +El Torito VD version 1 found, boot catalog is in sector 647 +Joliet with UCS level 3 found +Rock Ridge signatures version 1 found +Eltorito validation header: + Hid 1 + Arch 0 (x86) + ID '' + Key 55 AA + Eltorito defaultboot header: + Bootid 88 (bootable) + Boot media 0 (No Emulation Boot) + Load segment 0 + Sys type 0 + Nsect 4 + Bootoff 1D81E 120862 -- 1.8.3.1 From vbudikov at redhat.com Wed Jul 18 08:53:46 2018 From: vbudikov at redhat.com (=?UTF-8?q?V=C4=9Bra=20Cholasta?=) Date: Wed, 18 Jul 2018 10:53:46 +0200 Subject: [Libosinfo] [PATCH] Add RHEL6.10 support Message-ID: <1531904026-24116-1-git-send-email-vbudikov@redhat.com> --- data/os/redhat.com/rhel-6.10.xml.in | 53 +++++++++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+) create mode 100644 data/os/redhat.com/rhel-6.10.xml.in diff --git a/data/os/redhat.com/rhel-6.10.xml.in b/data/os/redhat.com/rhel-6.10.xml.in new file mode 100644 index 0000000..4d17935 --- /dev/null +++ b/data/os/redhat.com/rhel-6.10.xml.in @@ -0,0 +1,53 @@ + + + + rhel6.10 + <_name>Red Hat Enterprise Linux 6.10 + 6.10 + <_vendor>Red Hat, Inc + linux + rhel + Santiago + + + + 2018-05-25 + 2024-06-30 + + + + LINUX + RHEL-6.10 .*.i386.* + + isolinux/vmlinuz + isolinux/initrd.img + + + + LINUX + .*RHEL-6.10 .*.x86_64.* + + isolinux/vmlinuz + isolinux/initrd.img + + + + + 1 + 536870912 + + + + 400000000 + 1073741824 + 9663676416 + + + + +