[virt-tools-list] Libosinfo 0.2.10
Libosinfo 0.2.10 is out! Changes since 0.2.9: - Add API and option to osinfo-install-script utility that allows you to query the available methods to inject the installer script to the installation process. - Add JEOS installer scripts for Debian and Ubuntu. - Disable installer script for Windows 8.1 as its known not to work. - Allow XML special chars in installer script configuration values. - Fix a few build issues. - Add/improve/fix data on: - Debian - Fedora - FreeBSD - Mandrake - Mandriva - Microsoft Windows 7 - openSUSE - Solaris - Ubuntu - Qemu Release tarball available here for download: http://fedorahosted.org/releases/l/i/libosinfo/libosinfo-0.2.10.tar.gz sha256 checksum: 564bd487a39dc09a10917c1d7a95f739ee7701d9cd0fbabcacea64f615e20a2d What is libosinfo? == libosinfo is a GObject based library API for managing information about operating systems, hypervisors and the (virtual) hardware devices they can support. It includes a database containing device metadata and provides APIs to match/identify optimal devices for deploying an operating system on a hypervisor. Via the magic of GObject Introspection, the API is available in all common programming languages with demos for javascript (GJS/Seed) and python (PyGObject). Also provided are Vala bindings. libosinfo is Free Software and licenced under LGPLv2+. Dependencies - Required: - gobject-2.0 - gio-2.0 - libxml-2.0 - Optional: - gobject-introspection - Vala (build-time only) For further information about libosinfo please consult the project homepage http://libosinfo.org/ -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] Libosinfo 0.2.7
Libosinfo 0.2.7 is out! Changes since 0.2.6: - Add/improve/fix data on: - CentOS 6.* - Fedora 19 - GNOME 3.8 - openSUSE 12.3 - RHEL 6.4 - Ubuntu 13.04 - Add testcases for media detection: - Debian 7.0.* - Fedora 17, 18 and 19 - Ubuntu 12.10 and 13.04 - Installer script fixes/improvements: - Setup user avatar for Windows 7. - Fix against old RHEL and Fedora. - Specify installation method for Fedora (required by Fedora 19). - New API: - osinfo_platform_get_all_devices() - osinfo_install_script_generate_command_line() - build: - Take DESTDIR into account when creating symlinks. - Fix issues with installing in a tree where libosinfo was already installed. - Fix a race-condition regarding usb.ids/pci.ids setup. - Disable static libraries by default. - Some portability improments/fixes. - Fixes `make syntax-check`. - More docs and fixes to existing docs. Release tarball available here for download: https://fedorahosted.org/releases/l/i/libosinfo/libosinfo-0.2.7.tar.gz sha256 checksum: fce8f43d02da7c8f05db1b3cf40850711d56978f880558fde5cde7c8d0b24a46 What is libosinfo? = libosinfo is a GObject based library API for managing information about operating systems, hypervisors and the (virtual) hardware devices they can support. It includes a database containing device metadata and provides APIs to match/identify optimal devices for deploying an operating system on a hypervisor. Via the magic of GObject Introspection, the API is available in all common programming languages with demos for javascript (GJS/Seed) and python (PyGObject). Also provided are Vala bindings. libosinfo is Free Software and licenced under LGPLv2+. Dependencies - Required: - gobject-2.0 - gio-2.0 - libxml-2.0 - Optional: - gobject-introspection - Vala (build-time only) For further information about libosinfo please consult the project homepage https://libosinfo.org/ -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] Libosinfo 0.2.7
On Tue, May 14, 2013 at 5:04 AM, Guannan Ren g...@redhat.com wrote: On 05/14/2013 04:59 AM, Zeeshan Ali (Khattak) wrote: Libosinfo 0.2.7 is out! Changes since 0.2.6: - Add/improve/fix data on: - CentOS 6.* - Fedora 19 - GNOME 3.8 - openSUSE 12.3 - RHEL 6.4 - Ubuntu 13.04 - Add testcases for media detection: - Debian 7.0.* - Fedora 17, 18 and 19 - Ubuntu 12.10 and 13.04 - Installer script fixes/improvements: - Setup user avatar for Windows 7. - Fix against old RHEL and Fedora. - Specify installation method for Fedora (required by Fedora 19). - New API: - osinfo_platform_get_all_devices() - osinfo_install_script_generate_command_line() - build: - Take DESTDIR into account when creating symlinks. - Fix issues with installing in a tree where libosinfo was already installed. - Fix a race-condition regarding usb.ids/pci.ids setup. - Disable static libraries by default. - Some portability improments/fixes. - Fixes `make syntax-check`. - More docs and fixes to existing docs. Release tarball available here for download: https://fedorahosted.org/releases/l/i/libosinfo/libosinfo-0.2.7.tar.gz sha256 checksum: fce8f43d02da7c8f05db1b3cf40850711d56978f880558fde5cde7c8d0b24a46 What is libosinfo? = libosinfo is a GObject based library API for managing information about operating systems, hypervisors and the (virtual) hardware devices they can support. It includes a database containing device metadata and provides APIs to match/identify optimal devices for deploying an operating system on a hypervisor. Via the magic of GObject Introspection, the API is available in all common programming languages with demos for javascript (GJS/Seed) and python (PyGObject). Also provided are Vala bindings. libosinfo is Free Software and licenced under LGPLv2+. Dependencies - Required: - gobject-2.0 - gio-2.0 - libxml-2.0 - Optional: - gobject-introspection - Vala (build-time only) For further information about libosinfo please consult the project homepage https://libosinfo.org/ When I click the above link, it leads me to Daniel's blog which I visit a lot:) When I use http://libosinfo.org, it leads me to libosinfo project homepage. Probably, these two project stay on the same host machine. Ah yes, using 'https' instead of 'http' does that. Thanks for pointing it out. I'll try to remember in next release announcement. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] Libosinfo 0.2.6
Libosinfo 0.2.6 is out! Changes since 0.2.5: - New API to: - query signed status of device drivers. - query device driver signing requirement of installer scripts. - enable/disable installer script driver signing checks. - Use system-installed pci.ids/usb.ids files, if available. - Don't ignore vendor/device names from pci.ids/usb.ids files. - Corrections to RPM spec. Release tarball available here for download: https://fedorahosted.org/releases/l/i/libosinfo/libosinfo-0.2.6.tar.gz sha256 checksum: 4c61a566d71e40936b8c327d63c2fa8287a03b50bac94a4d93cb094f17f71dc9 What is libosinfo? = libosinfo is a GObject based library API for managing information about operating systems, hypervisors and the (virtual) hardware devices they can support. It includes a database containing device metadata and provides APIs to match/identify optimal devices for deploying an operating system on a hypervisor. Via the magic of GObject Introspection, the API is available in all common programming languages with demos for javascript (GJS/Seed) and python (PyGObject). Also provided are Vala bindings. libosinfo is Free Software and licenced under LGPLv2+. Dependencies - Required: - gobject-2.0 - gio-2.0 - libxml-2.0 - Optional: - gobject-introspection - Vala (build-time only) For further information about libosinfo please consult the project homepage https://libosinfo.org/ -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] Libosinfo 0.2.5
Libosinfo 0.2.5 is out! Changes since 0.2.4: - Make use of post-installation drivers in Windows 7 install scripts. This implies apps can now easily setup virtio+QXL device drivers and spice-vdagent as part of Windows 7 unattended installation. - Windows 7 install script now requires product key, mainly because product key is the only way to choose product when dealing with installer media with multiple products on it. - Actually add install scripts for Windows 8. This was supposed to be merged in release 0.2.3. - Formalize architecture names in DB to align with libvirt. The main change is that i386, i486, i586, all merge to just i686, since in practice these differences haven't mattered for at least 15 years now. - Fixes to mingw RPM spec from Fedora. - Add a Windows 7 volume ID to DB. Release tarball available here for download: https://fedorahosted.org/releases/l/i/libosinfo/libosinfo-0.2.5.tar.gz What is libosinfo? = libosinfo is a GObject based library API for managing information about operating systems, hypervisors and the (virtual) hardware devices they can support. It includes a database containing device metadata and provides APIs to match/identify optimal devices for deploying an operating system on a hypervisor. Via the magic of GObject Introspection, the API is available in all common programming languages with demos for javascript (GJS/Seed) and python (PyGObject). Also provided are Vala bindings. libosinfo is Free Software and licenced under LGPLv2+. Dependencies - Required: - gobject-2.0 - gio-2.0 - libxml-2.0 - Optional: - gobject-introspection - Vala (build-time only) For further information about libosinfo please consult the project homepage https://libosinfo.org/ -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] Libosinfo 0.2.4
Libosinfo 0.2.4 is out! Changes since 0.2.3: - Fix crash in osinfo-detect against non-bootable media. - osinfo-install-script now displays names of generated files. - Add an all-in-one virtio and QXL device driver setup binary to Windows XP and 7. Same binary also installs spice-vdagent for us. - Make use of post-installation drivers in Windows XP installer scripts. - Log post-install commands of Windows XP to target disk. - Add/improve/fix data on: - QEMU/QEMU-KVM hypervisor - GNOME - openSUSE - RPM spec file changes: - Include datamaps and locale files. - Pointto libosinfo official website. - Disable udev rule on Fedora = 19. Changes in udev 197 and libblkid 2.22.2 have made this rule obsolete. - Adapt to glib 2.36. - Fix some build warnings. - Some other fixes and improvements. What is libosinfo? = libosinfo is a GObject based library API for managing information about operating systems, hypervisors and the (virtual) hardware devices they can support. It includes a database containing device metadata and provides APIs to match/identify optimal devices for deploying an operating system on a hypervisor. Via the magic of GObject Introspection, the API is available in all common programming languages with demos for javascript (GJS/Seed) and python (PyGObject). Also provided are Vala bindings. libosinfo is Free Software and licenced under LGPLv2+. The latest official releases can be found at: https://fedorahosted.org/released/libosinfo/ Dependencies - Required: - gobject-2.0 - gio-2.0 - libxml-2.0 - Optional: - gobject-introspection - Vala (build-time only) For further information about libosinfo please consult the project homepage https://fedorahosted.org/libosinfo/ -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] Libosinfo 0.2.4
On Wed, Feb 20, 2013 at 2:54 AM, Zeeshan Ali (Khattak) zeesha...@gnome.org wrote: For further information about libosinfo please consult the project homepage https://fedorahosted.org/libosinfo/ Yikes, forgot to update the URL in release announcement: http://libosinfo.org/ -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] Libosinfo 0.2.3
Libosinfo 0.2.3 is out! Changes since 0.2.2: - Add datamaps for translating OS-neutral values to OS-specific ones, e.g some installer configuration parameters like keyboard, language and timezone etc. - New API to detect media that makes it possible to also query languages supported by the media. - Add install scripts for: - RHEL 6.x. - Microsoft Windows 8 - Fix install script for Fedora 18. - Drop support for encoding in l10n install script configuration parameters. - Fix test build issues. - Fixes and improvements to documentation. - Fix potential issues spotted by Coverity. - Fix build for translations. - osinfo-install-script tool now has options to list available configuration parameters and profiles. - Add/improve data on: - RHEL - Debian - openSUSE - Microsoft Windows 7 - Ubuntu - MacOS X - Added translations: - Ukrainian - Polish - Many other fixes and improvements. What is libosinfo? = libosinfo is a GObject based library API for managing information about operating systems, hypervisors and the (virtual) hardware devices they can support. It includes a database containing device metadata and provides APIs to match/identify optimal devices for deploying an operating system on a hypervisor. Via the magic of GObject Introspection, the API is available in all common programming languages with demos for javascript (GJS/Seed) and python (PyGObject). Also provided are Vala bindings. libosinfo is Free Software and licenced under LGPLv2+. The latest official releases can be found at: https://fedorahosted.org/released/libosinfo/ Dependencies - Required: - gobject-2.0 - gio-2.0 - libxml-2.0 - Optional: - gobject-introspection - Vala (build-time only) For further information about libosinfo please consult the project homepage https://fedorahosted.org/libosinfo/ -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo PATCHv3 10/12] Add osinfo_install_config_new_for_script
On Thu, Dec 13, 2012 at 2:06 PM, Christophe Fergeau cferg...@redhat.com wrote: On Thu, Dec 13, 2012 at 02:56:09AM +0200, Zeeshan Ali (Khattak) wrote: On Wed, Dec 12, 2012 at 5:18 PM, Christophe Fergeau cferg...@redhat.com wrote: In order to be able to automatically transform configuration parameters set on OsinfoInstallConfig instances (ie translate from generic value to OS-specific value), Hmm.. this seemingly small change is rather a big change in terms of API design as so far we have kept install config separate from install script. They only meet each other when generating scripts from template. Since the OS-specific values are actually needed when transforming the template to script (i-e in osinfo_install_script_generate_config_xml), I wonder if there is another less intrusive (in terms of API) way to achieve the goal. I was initially considering plugging into osinfo_install_script_generate_config_xml or some such function, but then it made more sense to me to do things the way it's done in this patch series. The install script XML contains a config section describing the valid parameters for the install script. Codewise, we have a OsinfoInstallScript which can contain a list of OsinfoInstallConfigParam. These objects are the result of parsing the install script XML. We also have an OsinfoInstallConfig class, which, as you mention, is independent of the OsinfoInstallScript and OsinfoInstallConfigParam classes Note the naming which could be confusing, OsinfoInstallConfig and OsinfoInstallConfigParam have nothing to do with each other at the moment. This separation between OsinfoInstallConfigParam and OsinfoInstallConfig means that one has to refer to OsinfoInstallScript to know which parameters are valid/required when filling an OsinfoInstallConfig object with data. Regardless of the datamap stuff, it makes sense to me to associate the OsinfoInstallConfig 'schema' (that is a list of OsinfoInstallConfigParam) with the OsinfoInstallConfig instance that is being filled. This could also allow us in the future to reject setting 'useless' arguments, to do argument validation (this arg only has X, Y and Z as valid values, this int must be between 1 and 10, ...). I can look at not associating OsinfoInstallConfigParam with OsinfoInstallConfig, but this will require a bit of refactoring, and I think this alternative approach would look more hackish than what this series is doing. In short, I consider the subseries: Add osinfo_install_config_new_for_script Add OsinfoInstallConfig::valid-params property OsinfoInstallScript: Use an OsinfoInstallConfigParamList Set id in osinfo_install_config_param_new Add OsinfoInstallConfigParamList as a nice improvement to the codebase even if there were not the datamap changes on top of it. Thanks for the explanation and I would agree with you to everything you said here but this kinda breaks API/ABI cause user is now expected to use a different _new(). I'll repeat the question I asked before: How does the app know which _new() to use? Now that we'll be expecting OS-specific values in scripts, any existing code (or even future code that uses the existing _new()) will still pass us OS-independent config that did not see the transformation. Regarding needing a lot of changes for keeping config separate, that is unfortunately true but keeping all above in mind I'm afraid we might not have a choice. We can still reuse some of the patches/code you already wrote though. At least these: Add osinfo_install_config_new_for_script OsinfoInstallScript: Use an OsinfoInstallConfigParamList Set id in osinfo_install_config_param_new Add OsinfoInstallConfigParamList osinfo_install_config_new_for_script() could be an internal function we can use in osinfo_install_script_generate_config_xml(). I don't think this very hackish. Still, If you could suggest how to solve the issue(s) I pointed out in your approach, I'm more than willing to accept your patches. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 1/2] Fix GObject property gtk-doc name
On Thu, Dec 13, 2012 at 1:41 PM, Christophe Fergeau cferg...@redhat.com wrote: They must be described as ClassName:property-name: or gtk-doc won't pick them up. There were some files where '::' was used instead of ':' as the class name/property name separator. Yeah '::' is for signals. ACK! -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 3/3] API to retrieve checksum for driver files
On Wed, Dec 12, 2012 at 11:13 AM, Christophe Fergeau cferg...@redhat.com wrote: On Wed, Dec 12, 2012 at 03:21:30AM +0200, Zeeshan Ali (Khattak) wrote: From: Zeeshan Ali (Khattak) zeesha...@gnome.org Keeping this API agnostic of MD5 so that we can later switch to another hashing alogirthm without breaking the API. algorithm /** + * osinfo_device_driver_get_file_checksum: + * @driver: a #OsinfoDeviceDriver instance + * @file: The name of the driver file for which checksum is requested + * @checksum_type: (out) (allow-none): place-holder to return type of the + * checksum into, or NULL + * + * Retrieves the expected checksum for the given driver file @file. + * + * Returns: The file checksum + */ +const gchar *osinfo_device_driver_get_file_checksum(OsinfoDeviceDriver *driver, +const gchar *file, +GChecksumType *checksum_type) I'd prefer a gboolean osinfo_device_driver_check_file(OsinfoDeviceDriver *driver, const char *file, GError **error); rather than forcing every app to do md5/sha1/... checks by hands while we can easily do it for them. Thats the idea I started with but then I thought checksum might have some other uses. Also what if app wants/needs to check data before pushing it into a file (this is what I'm doing in Boxes). Since glib doesn't provide simple API for computing checksum for a file (only for a buffer in memory), perhaps its a good idea to provide this _check_file() API in addition to exposing checksum to app. Keep in mind that _check_file() does I/O and therefore we must provide async variant too then. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 1/3] Every driver file in DB must provide MD5 checksum
On Wed, Dec 12, 2012 at 11:25 AM, Christophe Fergeau
cferg...@redhat.com wrote:
On Wed, Dec 12, 2012 at 03:21:28AM +0200, Zeeshan Ali (Khattak) wrote:
From: Zeeshan Ali (Khattak) zeesha...@gnome.org
---
data/schemas/libosinfo.rng| 9 +
osinfo/osinfo_device_driver.c | 18 ++
osinfo/osinfo_device_driver_private.h | 3 +++
osinfo/osinfo_loader.c| 11 ---
4 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/data/schemas/libosinfo.rng b/data/schemas/libosinfo.rng
index 51b0c20..819790a 100644
--- a/data/schemas/libosinfo.rng
+++ b/data/schemas/libosinfo.rng
@@ -415,6 +415,9 @@
/optional
zeroOrMore
element name='file'
+ attribute name=md5
+ref name='md5'/
+ /attribute
text/
/element
/zeroOrMore
@@ -636,4 +639,10 @@
param name=patterndos|unix/param
/data
/define
+
+ define name='md5'
+data type=string
+ param name=pattern[0-9a-fA-F]{32}/param
+/data
+ /define
I'd go with SHA256 from the start
Why? Do we expect these files to be huge? MD5 should suffice.
--
Regards,
Zeeshan Ali (Khattak)
FSF member#5124
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo] Checksums for driver files
On Wed, Dec 12, 2012 at 12:31 PM, Christophe Fergeau cferg...@redhat.com wrote: Hey, Hi, On Wed, Dec 12, 2012 at 03:21:27AM +0200, Zeeshan Ali (Khattak) wrote: These patches aims to provide applications a way to be able to verify the integrity of driver files, which they'll typically be downloading over unreliable networks. This series opens up some interesting questions... If I understand correctly, you want to check that the files that were downloaded didn't get corrupt during the download (or that they were not silently corrupted server-side, ..). However, what this does not address is checking if the driver we downloaded is legit. By 'legit', I mean making sure the library user actually downloaded the file we intended her to download when libosinfo told her to use 'http://zeenix.fedorapeople.org/drivers/win-tools/preinst/winxp/x86/viostor.sys' as the virtio-disk driver. There are various ways for a malicious user to return a different file from the one we intended (DNS hijacking, hacking zeenix.fedorapeople.org, ...). As these drivers are then automatically installed in the guest, a malicious file downloaded this way could do quite some nasty things. Let's call this issue #1. Another vector I'm worried about is the fact that by default we load database data from ~/.config/libosinfo/db after the system data. Only if the app chooses to do so (fwiw, Boxes doesn't do that). Apps using libosinfo rely on the data provided for setting up many different things so if I'd get worried about DB being compromised, drivers isn't the only problem we have. Especially the install scripts can do whatever they want on your VM. While I might not be as worried about local DB getting compromised as much as you, I will share the concern when we execute our plan to have the whole DB available online and apps using that directly. This can probably be abused by overriding Windows installation info and pointing it at drivers on a totally different server. I'll call this issue #2. Your patch series would address issue #1 as the file checksums will be hardcoded in the system libosinfo database. I should have explained better. The main rationale for checksums was to check if file got corrupted or not during download. #1 is more of a side-affect. TBH, security wasn't my concern with these patches. We need to use something different than md5 though if we want to rely on that as this has known collision vulnerabilities. Depends on the maximum size of files we expect, doesn't it? This does not address #2. And even that validation will probably break once we add a way to download updates to the libosinfo database from the net as the db updates could be compromised in the same way, with the drivers URLS/sha256sum changed to point to malicious drivers. One way of addressing these issues would be to add GPG signatures alongside each file we want to download, and hardcoding the known keys in libosinfo binary. Other options could be to only validate DB updates in such a way, or to not allow install-scripts and related data to be overridden by the user/remote updates (didn't give a lot of thoughts to that). Yeah, GPG signing sounds like a good idea to me. I'll look into that.. The reason I'm bringing that up now is that this seems to me more worrying than checking that the file was not corrupted doing download, and, depending on which way we want to go to solve these problems, the solution may be redundant with what this series does (ie checking that the files are legit would also guarantee that they were not corrupt during download). True. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 3/3] API to retrieve checksum for driver files
On Wed, Dec 12, 2012 at 5:24 PM, Christophe Fergeau cferg...@redhat.com wrote: On Wed, Dec 12, 2012 at 04:04:04PM +0200, Zeeshan Ali (Khattak) wrote: On Wed, Dec 12, 2012 at 11:13 AM, Christophe Fergeau cferg...@redhat.com wrote: On Wed, Dec 12, 2012 at 03:21:30AM +0200, Zeeshan Ali (Khattak) wrote: From: Zeeshan Ali (Khattak) zeesha...@gnome.org Keeping this API agnostic of MD5 so that we can later switch to another hashing alogirthm without breaking the API. algorithm /** + * osinfo_device_driver_get_file_checksum: + * @driver: a #OsinfoDeviceDriver instance + * @file: The name of the driver file for which checksum is requested + * @checksum_type: (out) (allow-none): place-holder to return type of the + * checksum into, or NULL + * + * Retrieves the expected checksum for the given driver file @file. + * + * Returns: The file checksum + */ +const gchar *osinfo_device_driver_get_file_checksum(OsinfoDeviceDriver *driver, +const gchar *file, +GChecksumType *checksum_type) I'd prefer a gboolean osinfo_device_driver_check_file(OsinfoDeviceDriver *driver, const char *file, GError **error); rather than forcing every app to do md5/sha1/... checks by hands while we can easily do it for them. Thats the idea I started with but then I thought checksum might have some other uses. s/uses/abuses? ;) Apps who want to get to the checksum can always use raw osinfo_entity calls, so I'm not sure we need to promote this use in the API. Except that there is no way to get to checksums through that API. Also what if app wants/needs to check data before pushing it into a file (this is what I'm doing in Boxes). Since glib doesn't provide simple API for computing checksum for a file (only for a buffer in memory), perhaps its a good idea to provide this _check_file() API in addition to exposing checksum to app. Keep in mind that _check_file() does I/O and therefore we must provide async variant too then. Ah, good points. gboolean osinfo_device_driver_check_file_data(OsinfoDeviceDriver *driver, const guint8 *data, gsize len, GError **error) would work for me to, and would avoid the need for async variants. Well then we are not really providing much help in case of validation of already saved file (app can use some API that allows to directly download to a file e.g) and glib already provides one function to do the validation of data given the checksum info. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo] Checksums for driver files
On Wed, Dec 12, 2012 at 5:43 PM, Christophe Fergeau cferg...@redhat.com wrote: On Wed, Dec 12, 2012 at 04:41:03PM +0200, Zeeshan Ali (Khattak) wrote: On Wed, Dec 12, 2012 at 12:31 PM, Christophe Fergeau cferg...@redhat.com wrote: Hey, Hi, On Wed, Dec 12, 2012 at 03:21:27AM +0200, Zeeshan Ali (Khattak) wrote: These patches aims to provide applications a way to be able to verify the integrity of driver files, which they'll typically be downloading over unreliable networks. This series opens up some interesting questions... If I understand correctly, you want to check that the files that were downloaded didn't get corrupt during the download (or that they were not silently corrupted server-side, ..). However, what this does not address is checking if the driver we downloaded is legit. By 'legit', I mean making sure the library user actually downloaded the file we intended her to download when libosinfo told her to use 'http://zeenix.fedorapeople.org/drivers/win-tools/preinst/winxp/x86/viostor.sys' as the virtio-disk driver. There are various ways for a malicious user to return a different file from the one we intended (DNS hijacking, hacking zeenix.fedorapeople.org, ...). As these drivers are then automatically installed in the guest, a malicious file downloaded this way could do quite some nasty things. Let's call this issue #1. Another vector I'm worried about is the fact that by default we load database data from ~/.config/libosinfo/db after the system data. Only if the app chooses to do so (fwiw, Boxes doesn't do that). Are you sure? osinfo_loader_process_default_path() loads user data, and Boxes calls this. Then I remembered wrong. Thing is that we load our (Boxes) custom logos db explicitly so that confused me.. This can probably be abused by overriding Windows installation info and pointing it at drivers on a totally different server. I'll call this issue #2. Your patch series would address issue #1 as the file checksums will be hardcoded in the system libosinfo database. I should have explained better. The main rationale for checksums was to check if file got corrupted or not during download. #1 is more of a side-affect. TBH, security wasn't my concern with these patches. Yes, this was my feeling as well (that they were not aimed at security). However these patches probably overlap with making this stuff more secure, and depending on how we choose to achieve this, they may be redundant/need adjustments, that's why I'm wondering what we want to do there. After talking to Daniel on IRC about this, I agree with him that properly addressing all security issues would be pain and we really have better things to do right now. Checksums already address the issue #1 so recommend we go with this approach for now. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo PATCHv3 5/9] media: Add OsinfoMedia::languages property
On Wed, Dec 12, 2012 at 4:26 PM, Christophe Fergeau cferg...@redhat.com wrote:
This lists all the languages a given media can show its UI in.
---
osinfo/libosinfo.syms | 1 +
osinfo/osinfo_media.c | 65
++-
osinfo/osinfo_media.h | 2 ++
osinfo/osinfo_media_private.h | 1 +
4 files changed, 68 insertions(+), 1 deletion(-)
diff --git a/osinfo/libosinfo.syms b/osinfo/libosinfo.syms
index 4d886f6..767a1fc 100644
--- a/osinfo/libosinfo.syms
+++ b/osinfo/libosinfo.syms
@@ -397,6 +397,7 @@ LIBOSINFO_0.2.3 {
osinfo_install_script_get_config_params;
+ osinfo_media_get_languages;
osinfo_media_get_os;
} LIBOSINFO_0.2.2;
diff --git a/osinfo/osinfo_media.c b/osinfo/osinfo_media.c
index d891615..abf449d 100644
--- a/osinfo/osinfo_media.c
+++ b/osinfo/osinfo_media.c
@@ -154,7 +154,8 @@ enum {
PROP_INSTALLER,
PROP_LIVE,
PROP_INSTALLER_REBOOTS,
-PROP_OS
+PROP_OS,
+PROP_LANGUAGES,
};
static void
@@ -225,6 +226,10 @@ osinfo_media_get_property (GObject*object,
g_value_take_object (value, osinfo_media_get_os (media));
break;
+case PROP_LANGUAGES:
+g_value_set_pointer (value, osinfo_media_get_languages (media));
+break;
+
default:
/* We don't have any other property... */
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, property_id, pspec);
@@ -311,6 +316,10 @@ osinfo_media_set_property(GObject *object,
osinfo_media_set_os(media, g_value_get_object(value));
break;
+case PROP_LANGUAGES:
+osinfo_media_set_languages(media, g_value_get_pointer(value));
+break;
+
default:
/* We don't have any other property... */
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, property_id, pspec);
@@ -517,6 +526,24 @@ osinfo_media_class_init (OsinfoMediaClass *klass)
G_PARAM_READWRITE |
G_PARAM_STATIC_STRINGS);
g_object_class_install_property (g_klass, PROP_OS, pspec);
+
+/*
+ * OsinfoMedia::languages:
+ *
+ * If media is an installer, this property indicates the languages that
+ * can be used during automatic installations.
+ *
+ * On media that are not installers, this property will indicate the
+ * languages that the user interface can be displayed in.
+ * Use #osinfo_media_get_installer (or OsinfoMedia::installer) to know
+ * if the media is an installer or not.
You need type and transfer annotation here. You can check
osinfo_avatar_format_class_init() for example.
--
Regards,
Zeeshan Ali (Khattak)
FSF member#5124
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo PATCHV3 0/9] Extract language information from Windows ISOs
On Wed, Dec 12, 2012 at 4:26 PM, Christophe Fergeau cferg...@redhat.com wrote: New iteration of this series addressing the review comments Changes since v2: - moved osinfo_media_set_os and osinfo_media_set_languages to a private header, added osinfo_media_get_os to public symbols - fixed osinfo_db_identify_media API doc - changed l10n-language type=regex to l10n-language regex=true ACK to this series with the annotation added to 5/9 patch I pointed out. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 5/8] Add osinfo_db_identify_media
On Tue, Dec 11, 2012 at 11:32 AM, Christophe Fergeau
cferg...@redhat.com wrote:
On Mon, Dec 10, 2012 at 10:45:23PM +0200, Zeeshan Ali (Khattak) wrote:
On Mon, Dec 10, 2012 at 11:20 AM, Christophe Fergeau
cferg...@redhat.com wrote:
On Wed, Dec 05, 2012 at 06:42:43PM +0200, Zeeshan Ali (Khattak) wrote:
+
+/**
+ * osinfo_db_identify_media:
+ * @db: a #OsinfoDb database
+ * @media: the installation media
+ * data
+ *
+ * Try to match the @media created using
osinfo_media_create_from_location()
This makes it sound like app developer doesn't have a choice. As an
app developer, I'd think why is libosinfo not creating the media
instance for me if it knows that I'll be doing that just before this
call anyways.
I recall that you are doing it this way because implementing async
version of this method will than be very difficult?
Not really difficult, but we already have async methods that can be used to
read the needed info from an image
(osinfo_media_create_from_location{_async}). It also does not strike me as
so bad to separate actual disk IO from DB lookups,
Only that there is no advantage to app developers, only minor inconvenience.
Well, adding more async functions also means a slightly bigger API to
figure out, a bit more changes to go from the old API to the new one, ...
These are also minor inconvenience for developers.
Thats what I was asking in the first email and you told me that that
is not the main rationale.
Adding an all-in-one
method would mean at least 3 more API calls, redundant with the existing
functions, ...
so I prefer to stay with the standalone _identify_media
call. Nothing prevents us from adding more calls later if they are really
needed, removing redundant calls is harder.
IMO we already know that they are needed.
if they are *really* needed. As we can't remove functions once they get
into a release, I'd rather that we live without these functions for now,
and see how different apps use the OsinfoMedia class,
There is no need to see. I already gave you example of one app
(actually there is no other user app ATM that I know of) that will
make use of the API I'm proposing.
If you could give me one reason why apps will want to make two calls
while they can make just one, I might get convinced.
and if this
additional API would make their life much better, then we can add it
knowing it's not API we'll have to deprecate 3 months later.
So we should avoid adding API being scared of the API getting
deprecated although we already know that API is very much desired?
With that extreme cautious approach, we better not add any API anymore
at all.
--
Regards,
Zeeshan Ali (Khattak)
FSF member#5124
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 07/11] OsinfoInstallScript: Use an OsinfoInstallConfigParamList
On Tue, Dec 11, 2012 at 11:52 AM, Christophe Fergeau
cferg...@redhat.com wrote:
On Tue, Dec 11, 2012 at 12:20:09AM +0200, Zeeshan Ali (Khattak) wrote:
On Mon, Dec 10, 2012 at 6:46 PM, Christophe Fergeau cferg...@redhat.com
wrote:
gboolean osinfo_install_script_has_config_param_name(const
OsinfoInstallScript *script, const gchar *name)
{
-GList *l;
-
-for (l = script-priv-config_param_list; l != NULL; l = l-next) {
-OsinfoInstallConfigParam *tmp = l-data;
-
-if (g_strcmp0(osinfo_install_config_param_get_name(tmp), name) ==
0)
-return TRUE;
-}
-return FALSE;
+OsinfoList *l = OSINFO_LIST(script-priv-config_params);
+return (osinfo_list_find_by_id(l, name) != NULL);
Should this code be assuming that name and ID are the same thing for
ConfigParam?
This is discussed a bit in 'Set id in osinfo_install_config_param_new'
commit log. OsinfoInstallConfigParam should have had an id from the start
as it's an entity, but it currently does not. The patch mentioned above
uses the name as id.
I'm fine with changing the code from these various functions back to list
iterations so that we don't rely on 'id' and 'name' being the same, but I
hate code doing lookup in lists ;)
You are not alone. :) I was only thinking aloud. Do as you think is
best but if you go with this approach, perhaps adding this fact to
OsinfoInstallConfigParam documentation might be a good idea (if you
haven't done that already) and a comment in here as well.
--
Regards,
Zeeshan Ali (Khattak)
FSF member#5124
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo] loader: Don't harcode '+ 9' in tree loading
On Tue, Dec 11, 2012 at 3:12 PM, Christophe Fergeau cferg...@redhat.com wrote: When loading tree elements, we want to skip the 'treeinfo-' part of entity property names. This is currently done by using a '+ 9', using sizeof(treeinfo-) instead will make things more obvious. ACK -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] [libosinfo 3/3] API to retrieve checksum for driver files
From: Zeeshan Ali (Khattak) zeesha...@gnome.org
Keeping this API agnostic of MD5 so that we can later switch to another
hashing alogirthm without breaking the API.
---
osinfo/libosinfo.syms | 4
osinfo/osinfo_device_driver.c | 24
osinfo/osinfo_device_driver.h | 3 +++
3 files changed, 31 insertions(+)
diff --git a/osinfo/libosinfo.syms b/osinfo/libosinfo.syms
index 82f6f95..4218b53 100644
--- a/osinfo/libosinfo.syms
+++ b/osinfo/libosinfo.syms
@@ -372,6 +372,10 @@ LIBOSINFO_0.2.2 {
osinfo_os_add_device_driver;
} LIBOSINFO_0.2.1;
+LIBOSINFO_0.2.3 {
+ osinfo_device_driver_get_file_checksum;
+} LIBOSINFO_0.2.2;
+
/* Symbols in next release...
LIBOSINFO_0.0.2 {
diff --git a/osinfo/osinfo_device_driver.c b/osinfo/osinfo_device_driver.c
index 6b81170..c78b974 100644
--- a/osinfo/osinfo_device_driver.c
+++ b/osinfo/osinfo_device_driver.c
@@ -142,6 +142,30 @@ GList *osinfo_device_driver_get_files(OsinfoDeviceDriver
*driver)
}
/**
+ * osinfo_device_driver_get_file_checksum:
+ * @driver: a #OsinfoDeviceDriver instance
+ * @file: The name of the driver file for which checksum is requested
+ * @checksum_type: (out) (allow-none): place-holder to return type of the
+ * checksum into, or NULL
+ *
+ * Retrieves the expected checksum for the given driver file @file.
+ *
+ * Returns: The file checksum
+ */
+const gchar *osinfo_device_driver_get_file_checksum(OsinfoDeviceDriver *driver,
+const gchar *file,
+GChecksumType
*checksum_type)
+{
+g_return_val_if_fail(OSINFO_IS_DEVICE_DRIVER(driver), NULL);
+g_return_val_if_fail(file != NULL, NULL);
+
+if (checksum_type != NULL)
+*checksum_type = G_CHECKSUM_MD5;
+
+return g_hash_table_lookup(driver-priv-checksums, file);
+}
+
+/**
* osinfo_device_driver_get_pre_installable:
* @driver: a #OsinfoDeviceDriver instance
*
diff --git a/osinfo/osinfo_device_driver.h b/osinfo/osinfo_device_driver.h
index c894fe8..aa571c6 100644
--- a/osinfo/osinfo_device_driver.h
+++ b/osinfo/osinfo_device_driver.h
@@ -83,6 +83,9 @@ const gchar
*osinfo_device_driver_get_location(OsinfoDeviceDriver *driver);
gboolean osinfo_device_driver_get_pre_installable(OsinfoDeviceDriver *driver);
GList *osinfo_device_driver_get_files(OsinfoDeviceDriver *driver);
OsinfoDeviceList *osinfo_device_driver_get_devices(OsinfoDeviceDriver *driver);
+const gchar *osinfo_device_driver_get_file_checksum(OsinfoDeviceDriver *driver,
+const gchar *file,
+GChecksumType
*checksum_type);
#endif /* __OSINFO_DEVICE_DRIVER_H__ */
/*
--
1.8.0.1
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo PATCHv2] add datamap support
On Tue, Dec 11, 2012 at 8:20 PM, Christophe Fergeau cferg...@redhat.com wrote: Hey, Hi, Here is a v2 of my datamap patches which addresses the review comments. I've also moved the new symbols to a new section in libosinfo.syms as there has been a release since the initial posting Changes since v1: - rename osinfo_install_script_get_config_paramlist to osinfo_install_script_get_config_params - fix wrong API doc mentioning g_list_free - add comments in patch 7 about 'name' and 'id' being assumed to be the same in some functions If that is all the changes made in v2, then ACK for the series. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo PATCHv2 3/9] Add osinfo_db_identify_media
On Tue, Dec 11, 2012 at 10:17 PM, Christophe Fergeau
cferg...@redhat.com wrote:
---
osinfo/libosinfo.syms | 1 +
osinfo/osinfo_db.c| 71
+++
osinfo/osinfo_db.h| 2 ++
osinfo/osinfo_media.c | 5 +++-
test/test-isodetect.c | 10
tools/osinfo-detect.c | 13 ++
6 files changed, 91 insertions(+), 11 deletions(-)
diff --git a/osinfo/libosinfo.syms b/osinfo/libosinfo.syms
index c5ab005..8d1e27a 100644
--- a/osinfo/libosinfo.syms
+++ b/osinfo/libosinfo.syms
@@ -386,6 +386,7 @@ LIBOSINFO_0.2.3 {
osinfo_db_add_datamap;
osinfo_db_get_datamap;
osinfo_db_get_datamap_list;
+ osinfo_db_identify_media;
osinfo_install_config_new_for_script;
osinfo_install_config_get_valid_params;
diff --git a/osinfo/osinfo_db.c b/osinfo/osinfo_db.c
index dcda2fe..eea8d12 100644
--- a/osinfo/osinfo_db.c
+++ b/osinfo/osinfo_db.c
@@ -527,6 +527,77 @@ OsinfoOs *osinfo_db_guess_os_from_media(OsinfoDb *db,
return ret;
}
+static void fill_media (OsinfoMedia *media, OsinfoMedia *matched_media,
OsinfoOs *os)
+{
+gboolean is_installer;
+gboolean is_live;
+gint reboots;
+const gchar *kernel_path;
+const gchar *initrd_path;
+const gchar *arch;
+const gchar *url;
+
+arch = osinfo_media_get_architecture(matched_media);
+if (arch != NULL)
+g_object_set(G_OBJECT(media), architecture, arch, NULL);
+url = osinfo_media_get_url(matched_media);
+if (url != NULL)
+g_object_set(G_OBJECT(media), url, url, NULL);
+
+kernel_path = osinfo_media_get_kernel_path(matched_media);
+if (kernel_path != NULL)
+g_object_set(G_OBJECT(media), kernel_path, kernel_path, NULL);
+
+initrd_path = osinfo_media_get_initrd_path(matched_media);
+if (initrd_path != NULL)
+g_object_set(G_OBJECT(media), initrd_path, initrd_path, NULL);
+is_installer = osinfo_media_get_installer(matched_media);
+is_live = osinfo_media_get_live(matched_media);
+g_object_set(G_OBJECT(media),
+ installer, is_installer,
+ live, is_live,
+ NULL);
+if (is_installer) {
+reboots = osinfo_media_get_installer_reboots(matched_media);
+g_object_set(G_OBJECT(media), installer-reboots, reboots, NULL);
+}
+if (os != NULL)
+osinfo_media_set_os(media, os);
+}
+
+/**
+ * osinfo_db_identify_media:
+ * @db: a #OsinfoDb database
+ * @media: the installation media
+ * data
+ *
+ * Try to match the @media created using osinfo_media_create_from_location()
+ * with a media description from @db. If found, @media will be filled with
+ * the corresponding information stored in @db.
If we are going to keep media identifying API separate from media
creation, I suggest we don't make it sound like media must be created
using osinfo_media_create_from_location(). As you pointed out, we
could easily have other constructors in future. When that happens, its
very likely that we'll not remember to update this doc comment.
In particular, after a call
+ * to osinfo_media_create_from_location(), if the media could be
+ * identified, its OsinfoMedia::os property will be set.
s/osinfo_media_create_from_location/osinfo_db_identify_media/ ? IMHO
the , after a call to osinfo_media_create_from_location(), part is
quite redundant in this context.
+ * Returns: (transfer none): TRUE if @media was found in @db, FALSE
Not really an issue but for future ref: Transfer annotations are
redundant for basic C/glib types.
--
Regards,
Zeeshan Ali (Khattak)
FSF member#5124
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo PATCHv2 6/9] loader: Read media language information
On Tue, Dec 11, 2012 at 10:17 PM, Christophe Fergeau cferg...@redhat.com wrote: Getting language information can either be supplied through a series of l10n-language tag set on the media element or through a regex that will be applied on the media volume ID. The former should be all that is needed for most Linux distros while the latter will be useful to get the language of Windows images. --- data/schemas/libosinfo.rng | 21 + osinfo/libosinfo.syms | 2 ++ osinfo/osinfo_loader.c | 33 + osinfo/osinfo_media.h | 3 +++ 4 files changed, 55 insertions(+), 4 deletions(-) diff --git a/data/schemas/libosinfo.rng b/data/schemas/libosinfo.rng index 4094710..796d5f2 100644 --- a/data/schemas/libosinfo.rng +++ b/data/schemas/libosinfo.rng @@ -281,6 +281,9 @@ text/ /element /optional +zeroOrMore + ref name='media-lang'/ +/zeroOrMore /interleave /element /define @@ -328,6 +331,24 @@ /element /define + define name='media-lang' +element name='l10n-language' + optional +attribute name=type + choice +valueregex/value + /choice Only one choice? :) I think a boolean is-regex or just regex would be more appropriate here. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] [libosinfo 2/3] xp, win7: Specify MD5 checksums for driver files
From: Zeeshan Ali (Khattak) zeesha...@gnome.org --- data/oses/windows.xml.in | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/data/oses/windows.xml.in b/data/oses/windows.xml.in index a3ff365..092572f 100644 --- a/data/oses/windows.xml.in +++ b/data/oses/windows.xml.in @@ -381,20 +381,20 @@ !-- virtio block device driver -- driver arch=i386 location=http://zeenix.fedorapeople.org/drivers/win-tools/preinst/winxp/x86; pre-installable=true - fileviostor.cat/file - fileviostor.inf/file - fileviostor.sys/file + file md5=fdef0051308d862c1026b7b98480ef6aviostor.cat/file + file md5=b3d85d4d38f15801a933117755eef73fviostor.inf/file + file md5=af59853336e23eab54f86e20dc4c6e6dviostor.sys/file !-- For now we require this for pre-installation but we should probably generate this too -- - filetxtsetup.oem/file + file md5=825f7123b5ff2910c3e12a850ac0cd09txtsetup.oem/file device id=http://pciids.sourceforge.net/v2.2/pci.ids/1af4/1001/ /driver driver arch=x86_64 location=http://zeenix.fedorapeople.org/drivers/win-tools/preinst/winxp/amd64; pre-installable=true - fileviostor.cat/file - fileviostor.inf/file - fileviostor.sys/file + file md5=10aab06a65bfd70f7569baa2c34ad0d7viostor.cat/file + file md5=5fa8e9673d0604b7f55f5a55de81451fviostor.inf/file + file md5=f690b3f1a5907eca5eb2478a2dde5bc2viostor.sys/file !-- For now we require this for pre-installation but we should probably generate this too -- - filetxtsetup.oem/file + file md5=825f7123b5ff2910c3e12a850ac0cd09txtsetup.oem/file device id=http://pciids.sourceforge.net/v2.2/pci.ids/1af4/1001/ /driver /os @@ -740,16 +740,16 @@ !-- virtio block device driver -- driver arch=i386 location=http://zeenix.fedorapeople.org/drivers/win-tools/preinst/win7/x86; pre-installable=true - fileviostor.cat/file - fileviostor.inf/file - fileviostor.sys/file + file md5=c1bfc514b3e5487623a8df97038af1c9viostor.cat/file + file md5=5fadbe04a4443e1084cb43fbec247c4eviostor.inf/file + file md5=8220ade09ce8c1978c531681c14e557cviostor.sys/file device id=http://pciids.sourceforge.net/v2.2/pci.ids/1af4/1001/ /driver driver arch=x86_64 location=http://zeenix.fedorapeople.org/drivers/win-tools/preinst/win7/amd64; pre-installable=true - fileviostor.cat/file - fileviostor.inf/file - fileviostor.sys/file + file md5=b2f5304f41e64cd70de6ee0544399fc7viostor.cat/file + file md5=f0ffaf1b394ca59ecd1c4b21ef981f61viostor.inf/file + file md5=d9a7616b187f46731af77f449b7d543aviostor.sys/file device id=http://pciids.sourceforge.net/v2.2/pci.ids/1af4/1001/ /driver /os -- 1.8.0.1 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] [libosinfo] Checksums for driver files
These patches aims to provide applications a way to be able to verify the integrity of driver files, which they'll typically be downloading over unreliable networks. ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] [libosinfo 1/3] Every driver file in DB must provide MD5 checksum
From: Zeeshan Ali (Khattak) zeesha...@gnome.org
---
data/schemas/libosinfo.rng| 9 +
osinfo/osinfo_device_driver.c | 18 ++
osinfo/osinfo_device_driver_private.h | 3 +++
osinfo/osinfo_loader.c| 11 ---
4 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/data/schemas/libosinfo.rng b/data/schemas/libosinfo.rng
index 51b0c20..819790a 100644
--- a/data/schemas/libosinfo.rng
+++ b/data/schemas/libosinfo.rng
@@ -415,6 +415,9 @@
/optional
zeroOrMore
element name='file'
+ attribute name=md5
+ref name='md5'/
+ /attribute
text/
/element
/zeroOrMore
@@ -636,4 +639,10 @@
param name=patterndos|unix/param
/data
/define
+
+ define name='md5'
+data type=string
+ param name=pattern[0-9a-fA-F]{32}/param
+/data
+ /define
/grammar
diff --git a/osinfo/osinfo_device_driver.c b/osinfo/osinfo_device_driver.c
index 9a7e5e2..6b81170 100644
--- a/osinfo/osinfo_device_driver.c
+++ b/osinfo/osinfo_device_driver.c
@@ -50,6 +50,8 @@ G_DEFINE_TYPE (OsinfoDeviceDriver, osinfo_device_driver,
OSINFO_TYPE_ENTITY);
struct _OsinfoDeviceDriverPrivate
{
OsinfoDeviceList *devices;
+
+GHashTable *checksums;
};
static void
@@ -58,6 +60,7 @@ osinfo_device_driver_finalize (GObject *object)
OsinfoDeviceDriver *driver = OSINFO_DEVICE_DRIVER (object);
g_object_unref(driver-priv-devices);
+g_hash_table_unref(driver-priv-checksums);
/* Chain up to the parent class */
G_OBJECT_CLASS (osinfo_device_driver_parent_class)-finalize (object);
@@ -80,6 +83,8 @@ osinfo_device_driver_init (OsinfoDeviceDriver *driver)
driver-priv = priv = OSINFO_DEVICE_DRIVER_GET_PRIVATE(driver);
priv-devices = osinfo_devicelist_new ();
+driver-priv-checksums = g_hash_table_new_full(g_str_hash, g_str_equal,
+g_free, g_free);
}
OsinfoDeviceDriver *osinfo_device_driver_new(const gchar *id)
@@ -172,6 +177,19 @@ void osinfo_device_driver_add_device(OsinfoDeviceDriver
*driver,
OSINFO_ENTITY(device));
}
+void osinfo_device_driver_add_file(OsinfoDeviceDriver *driver,
+ const gchar *name,
+ const gchar *checksum)
+{
+g_hash_table_replace(driver-priv-checksums,
+ g_strdup(name),
+ g_strdup(checksum));
+
+osinfo_entity_add_param(OSINFO_ENTITY(driver),
+OSINFO_DEVICE_DRIVER_PROP_FILE,
+name);
+}
+
/*
* Local variables:
* indent-tabs-mode: nil
diff --git a/osinfo/osinfo_device_driver_private.h
b/osinfo/osinfo_device_driver_private.h
index d49ffa1..6e54c61 100644
--- a/osinfo/osinfo_device_driver_private.h
+++ b/osinfo/osinfo_device_driver_private.h
@@ -29,6 +29,9 @@
OsinfoDeviceDriver *osinfo_device_driver_new(const gchar *id);
void osinfo_device_driver_add_device(OsinfoDeviceDriver *driver,
OsinfoDevice *device);
+void osinfo_device_driver_add_file(OsinfoDeviceDriver *driver,
+ const gchar *name,
+ const gchar *checksum);
#endif /* __OSINFO_DEVICE_DRIVER_PRIVATE_H__ */
diff --git a/osinfo/osinfo_loader.c b/osinfo/osinfo_loader.c
index 18325f6..f230395 100644
--- a/osinfo/osinfo_loader.c
+++ b/osinfo/osinfo_loader.c
@@ -971,9 +971,14 @@ static OsinfoDeviceDriver
*osinfo_loader_driver(OsinfoLoader *loader,
nodes[i]-children-type == XML_TEXT_NODE
(strcmp((const gchar *)nodes[i]-name,
OSINFO_DEVICE_DRIVER_PROP_FILE) == 0)) {
-osinfo_entity_add_param(OSINFO_ENTITY(driver),
-(const gchar *)nodes[i]-name,
-(const gchar
*)nodes[i]-children-content);
+xmlChar *checksum = xmlGetProp(nodes[i], BAD_CAST md5);
+if (checksum == NULL)
+continue; // Checksum is a must!
+
+osinfo_device_driver_add_file(driver,
+ (const gchar
*)nodes[i]-children-content,
+ (const gchar *)checksum);
+xmlFree(checksum);
} else if (strcmp((const gchar *)nodes[i]-name,
OSINFO_DEVICE_DRIVER_PROP_DEVICE) == 0) {
xmlChar *device_id = xmlGetProp(nodes[i], BAD_CAST id);
--
1.8.0.1
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo PATCHv2 5/9] media: Add OsinfoMedia::languages property
On Tue, Dec 11, 2012 at 10:17 PM, Christophe Fergeau
cferg...@redhat.com wrote:
This lists all the languages a given media can show its UI in.
---
osinfo/osinfo_media.c | 65
++-
osinfo/osinfo_media.h | 2 ++
2 files changed, 66 insertions(+), 1 deletion(-)
diff --git a/osinfo/osinfo_media.c b/osinfo/osinfo_media.c
index 7654cf7..c30afe8 100644
--- a/osinfo/osinfo_media.c
+++ b/osinfo/osinfo_media.c
@@ -153,7 +153,8 @@ enum {
PROP_INSTALLER,
PROP_LIVE,
PROP_INSTALLER_REBOOTS,
-PROP_OS
+PROP_OS,
+PROP_LANGUAGES,
};
static void
@@ -224,6 +225,10 @@ osinfo_media_get_property (GObject*object,
g_value_take_object (value, osinfo_media_get_os (media));
break;
+case PROP_LANGUAGES:
+g_value_set_pointer (value, osinfo_media_get_languages (media));
+break;
+
default:
/* We don't have any other property... */
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, property_id, pspec);
@@ -310,6 +315,10 @@ osinfo_media_set_property(GObject *object,
osinfo_media_set_os(media, g_value_get_object(value));
break;
+case PROP_LANGUAGES:
+osinfo_media_set_languages(media, g_value_get_pointer(value));
+break;
+
default:
/* We don't have any other property... */
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, property_id, pspec);
@@ -516,6 +525,24 @@ osinfo_media_class_init (OsinfoMediaClass *klass)
G_PARAM_READWRITE |
G_PARAM_STATIC_STRINGS);
g_object_class_install_property (g_klass, PROP_OS, pspec);
+
+/*
+ * OsinfoMedia::languages:
+ *
+ * If media is an installer, this property indicates the languages that
+ * can be used during automatic installations.
+ *
+ * On media that are not installers, this property will indicate the
+ * languages that the user interface can be displayed in.
+ * Use #osinfo_media_get_installer (or OsinfoMedia::installer) to know
+ * if the media is an installer or not.
+ */
+pspec = g_param_spec_pointer (languages,
+ Languages,
+ _(Supported languages),
+ G_PARAM_READABLE |
+ G_PARAM_STATIC_STRINGS);
+g_object_class_install_property (g_klass, PROP_LANGUAGES, pspec);
}
static void
@@ -1101,6 +1128,42 @@ void osinfo_media_set_os(OsinfoMedia *media, OsinfoOs
*os)
g_weak_ref_set(media-priv-os, os);
g_object_unref(os);
}
+
+/**
+ * osinfo_media_get_languages:
+ * @media: a #OsinfoMedia instance
+ *
+ * If media is an installer, this property indicates the languages that
+ * can be used during automatic installations.
+ *
+ * On media that are not installers, this property will indicate the
+ * languages that the user interface can be displayed in.
+ * Use #osinfo_media_get_installer (or OsinfoMedia::installer) to know
+ * if the media is an installer or not.
+ *
+ * Returns: (transfer container) (element-type utf8): a #GList
+ * containing the list of supported supported languages which must be
+ * freed with g_list_free() when no longer neede, or NULL if the supported
+ * languages are unknown
+ */
+GList *osinfo_media_get_languages(OsinfoMedia *media)
+{
+g_return_val_if_fail(OSINFO_IS_MEDIA(media), NULL);
+return osinfo_entity_get_param_value_list(OSINFO_ENTITY(media),
OSINFO_MEDIA_PROP_LANG);
+}
+
+void osinfo_media_set_languages(OsinfoMedia *media, GList *languages)
I wonder if this should be internal only?
--
Regards,
Zeeshan Ali (Khattak)
FSF member#5124
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] [libosinfo] data: Add forgotten macos.xml.in file
From: Zeeshan Ali (Khattak) zeesha...@gnome.org This file got never added to Makefile.am so was never installed or distributed. --- data/oses/Makefile.am | 1 + 1 file changed, 1 insertion(+) diff --git a/data/oses/Makefile.am b/data/oses/Makefile.am index be492ae..ba03408 100644 --- a/data/oses/Makefile.am +++ b/data/oses/Makefile.am @@ -11,6 +11,7 @@ database_in_files = \ mandrake.xml.in \ netbsd.xml.in \ netware.xml.in \ + macos.xml.in\ openbsd.xml.in \ opensuse.xml.in \ rhl.xml.in \ -- 1.8.0.1 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo] data: Add forgotten macos.xml.in file
On Mon, Dec 10, 2012 at 7:40 PM, Zeeshan Ali (Khattak) zeesha...@gnome.org wrote: From: Zeeshan Ali (Khattak) zeesha...@gnome.org This file got never added to Makefile.am so was never installed or distributed. --- Forgot to mention: Already pushed under trivial rule. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] Libosinfo 0.2.2
Libosinfo 0.2.2 is out! Changes since 0.2.1: - Loads of improvements and fixes to installer APIs and scripts. Now they are in such a good shape that next release of Boxes will make full use of them. - Add API for information on downloadable device drivers. As a starting point, information on virtio storage drivers for Windows XP and 7 is provided. - Add/improve data on: - RHEL - Windows 7 - Windows 8 - Windows XP - Enable translations for many (potential) user-visible strings. No translations submitted yet. :( - Correct default value for OsinfoMedia::installer-reboots. - Register enum types with gobject type system. - Add enum param getter/setter helpers. - OsinfoList is now instantiable and all its subclasses has been deprecated. Newer code should use OsinfoList directly. - Various other fixes and improvements. What is libosinfo? = libosinfo is a GObject based library API for managing information about operating systems, hypervisors and the (virtual) hardware devices they can support. It includes a database containing device metadata and provides APIs to match/identify optimal devices for deploying an operating system on a hypervisor. Via the magic of GObject Introspection, the API is available in all common programming languages with demos for javascript (GJS/Seed) and python (PyGObject). Also provided are Vala bindings. libosinfo is Free Software and licenced under LGPLv2+. The latest official releases can be found at: https://fedorahosted.org/released/libosinfo/ Dependencies - Required: - gobject-2.0 - gio-2.0 - libxml-2.0 - Optional: - gobject-introspection - Vala (build-time only) For further information about libosinfo please consult the project homepage https://fedorahosted.org/libosinfo/ -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 5/8] Add osinfo_db_identify_media
On Mon, Dec 10, 2012 at 11:20 AM, Christophe Fergeau
cferg...@redhat.com wrote:
On Wed, Dec 05, 2012 at 06:42:43PM +0200, Zeeshan Ali (Khattak) wrote:
+
+/**
+ * osinfo_db_identify_media:
+ * @db: a #OsinfoDb database
+ * @media: the installation media
+ * data
+ *
+ * Try to match the @media created using
osinfo_media_create_from_location()
This makes it sound like app developer doesn't have a choice. As an
app developer, I'd think why is libosinfo not creating the media
instance for me if it knows that I'll be doing that just before this
call anyways.
I recall that you are doing it this way because implementing async
version of this method will than be very difficult?
Not really difficult, but we already have async methods that can be used to
read the needed info from an image
(osinfo_media_create_from_location{_async}). It also does not strike me as
so bad to separate actual disk IO from DB lookups,
Only that there is no advantage to app developers, only minor inconvenience.
Adding an all-in-one
method would mean at least 3 more API calls, redundant with the existing
functions, ...
so I prefer to stay with the standalone _identify_media
call. Nothing prevents us from adding more calls later if they are really
needed, removing redundant calls is harder.
IMO we already know that they are needed. If we have one function that
does both, we'd want to use that in Boxes for example. Can't be sure
of other apps of course but I don't see why any app would prefer two
calls over one.
--
Regards,
Zeeshan Ali (Khattak)
FSF member#5124
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo] Improve list API
On Fri, Dec 7, 2012 at 4:06 PM, Zeeshan Ali (Khattak) zeesha...@gnome.org wrote: On Fri, Dec 7, 2012 at 11:34 AM, Christophe Fergeau cferg...@redhat.com wrote: Hi, libosinfo has various *List classes which basically are a GObject class wrapping a hash table of objects of a specific type. Each of these classes implements osinfo_list_new_filtered, osinfo_list_new_copy, ... probably because of cp. I don't think that is the case. The issue is that these functions should have been virtual so if you call osinfo_list_new_*() on an instance of subclass, you get an instance of subclass (although in the form of OsinfoList). Now with these method deprecated in subclasses, apps now have to deal with different classes depending on whether or not they needed to call any of these methods (e.g whether or not they needed to filter a list). This Boxes patch should give you an idea of the issue I'm talking about: http://bugzilla-attachments.gnome.org/attachment.cgi?id=231171 Now the problem is that we can't make these methods virtual without breaking the ABI. Which is where another of our failures show-up. To avoid ABI breakage, its really important to keep redudant padding in class structs and we never added those before declaring libosinfo ABI stable. :( On a personal note, I don't think its a good idea for any API should be declared stable forever before it going through at least a few unstable and stable cycles. However, these methods are seldomly used, and are not used at all on most classes. It's actually possible to implement these generically in the OsinfoList base class, this is what this series is doing while deprecating all the other implementations in derived classes. I've checked that make check is still working and also ran a quick test with Boxes. Series looks good. Since you have also tested it, ACK! I did a very bad job on reviewing these and totally missed the main point. Rest assured I wont' be able to sleep tonight. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 07/11] OsinfoInstallScript: Use an OsinfoInstallConfigParamList
On Mon, Dec 10, 2012 at 6:46 PM, Christophe Fergeau cferg...@redhat.com wrote:
Currently the install script config parameters are stored in a
raw GList. However, OsinfoInstallScript ends up reimplementing
part of the OsinfoList API, and the raw GList also does not make
it convenient to pass the list of config parameters around.
Replace the internal GList with an OsinfoInstallConfigParamList,
which has the side-effect of nicely simplifying the code.
---
osinfo/libosinfo.syms | 1 +
osinfo/osinfo_install_script.c | 69
+-
osinfo/osinfo_install_script.h | 1 +
3 files changed, 36 insertions(+), 35 deletions(-)
diff --git a/osinfo/libosinfo.syms b/osinfo/libosinfo.syms
index d96ac53..7ec1bbd 100644
--- a/osinfo/libosinfo.syms
+++ b/osinfo/libosinfo.syms
@@ -374,6 +374,7 @@ LIBOSINFO_0.2.2 {
osinfo_install_script_get_avatar_format;
osinfo_install_script_get_can_pre_install_drivers;
osinfo_install_script_get_can_post_install_drivers;
+ osinfo_install_script_get_config_paramlist;
osinfo_install_script_get_path_format;
osinfo_install_script_get_product_key_format;
diff --git a/osinfo/osinfo_install_script.c b/osinfo/osinfo_install_script.c
index cecad04..bb7ad29 100644
--- a/osinfo/osinfo_install_script.c
+++ b/osinfo/osinfo_install_script.c
@@ -50,7 +50,7 @@ struct _OsinfoInstallScriptPrivate
{
gchar *output_prefix;
gchar *output_filename;
-GList *config_param_list;
+OsinfoInstallConfigParamList *config_params;
OsinfoAvatarFormat *avatar;
};
@@ -164,8 +164,11 @@ osinfo_install_script_finalize (GObject *object)
OsinfoInstallScript *script = OSINFO_INSTALL_SCRIPT (object);
g_free(script-priv-output_prefix);
g_free(script-priv-output_filename);
-g_list_free_full(script-priv-config_param_list, g_object_unref);
-if (script-priv-avatar != NULL)
+
+if (script-priv-config_params)
+g_object_unref(script-priv-config_params);
+
+if (script-priv-avatar)
g_object_unref(script-priv-avatar);
/* Chain up to the parent class */
@@ -258,35 +261,20 @@ void
osinfo_install_script_add_config_param(OsinfoInstallScript *script, OsinfoI
g_return_if_fail(OSINFO_IS_INSTALL_SCRIPT(script));
g_return_if_fail(OSINFO_IS_INSTALL_CONFIG_PARAM(param));
-script-priv-config_param_list =
-g_list_prepend(script-priv-config_param_list, param);
+osinfo_list_add(OSINFO_LIST(script-priv-config_params),
+OSINFO_ENTITY(param));
}
gboolean osinfo_install_script_has_config_param(const OsinfoInstallScript
*script, const OsinfoInstallConfigParam *config_param)
{
-GList *l;
-
-for (l = script-priv-config_param_list; l != NULL; l = l-next) {
-OsinfoInstallConfigParam *tmp = l-data;
-
-if (g_strcmp0(osinfo_install_config_param_get_name(tmp),
- osinfo_install_config_param_get_name(config_param)) ==
0)
-return TRUE;
-}
-return FALSE;
+const char *name = osinfo_install_config_param_get_name(config_param);
+return osinfo_install_script_has_config_param_name(script, name);
}
gboolean osinfo_install_script_has_config_param_name(const
OsinfoInstallScript *script, const gchar *name)
{
-GList *l;
-
-for (l = script-priv-config_param_list; l != NULL; l = l-next) {
-OsinfoInstallConfigParam *tmp = l-data;
-
-if (g_strcmp0(osinfo_install_config_param_get_name(tmp), name) == 0)
-return TRUE;
-}
-return FALSE;
+OsinfoList *l = OSINFO_LIST(script-priv-config_params);
+return (osinfo_list_find_by_id(l, name) != NULL);
Should this code be assuming that name and ID are the same thing for
ConfigParam?
}
/**
@@ -300,7 +288,21 @@ gboolean
osinfo_install_script_has_config_param_name(const OsinfoInstallScript *
*/
GList *osinfo_install_script_get_config_param_list(const OsinfoInstallScript
*script)
{
-return g_list_copy(script-priv-config_param_list);
+return
osinfo_list_get_elements(OSINFO_LIST(script-priv-config_params));
+}
+
+/**
+ * osinfo_install_script_get_config_paramlist:
+ *
+ * Get the list of valid config parameters for @script.
+ *
+ * Returns: (transfer none): the
+ * list of valid #OsinfoInstallConfigParam parameters. Free with
+ * g_list_free() when done. The elements are owned by libosinfo.
You want to update the doc about free function above.
+ */
+OsinfoInstallConfigParamList
*osinfo_install_script_get_config_paramlist(const OsinfoInstallScript *script)
This name seems a bit inconsistent with names for existing similar
functions. Since _get_config_param_list() is already taken, I suggest
_get_config_params.
--
Regards,
Zeeshan Ali (Khattak)
FSF member#5124
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https
Re: [virt-tools-list] [libosinfo 2/2] fedora, installer: Set keyboard config for = F18
On Fri, Dec 7, 2012 at 10:06 AM, Christophe Fergeau cferg...@redhat.com wrote: On Fri, Dec 07, 2012 at 03:43:37AM +0200, Zeeshan Ali (Khattak) wrote: On Thu, Dec 6, 2012 at 4:06 PM, Christophe Fergeau cferg...@redhat.com wrote: On Thu, Dec 06, 2012 at 03:12:36PM +0200, Zeeshan Ali (Khattak) wrote: On Wed, Dec 5, 2012 at 6:08 PM, Zeeshan Ali (Khattak) zeesha...@gnome.org wrote: On Wed, Dec 5, 2012 at 5:56 PM, Christophe Fergeau cferg...@redhat.com wrote: Hey Hi, I don't think it's good to duplicate the mapping twice, and that's a good candidate for these datamaps. I agree but for now we can do it this way. Once we have the datamaps in place, we can make use of them here. So whats the verdict on this? I don't think it's good to duplicate the mapping twice. I understood this very simple sentence the first time too. :) I also said that I agree with it. I only wanted to know if its OK like that for now to improve later. I guess the answer is 'no' then. It depends, you did not explain at all why you'd prefer to keep things this way for now. If it would take significant time to remove the duplication, then I could get convinced, but without explanations/arguments it's hard to make a decision. And adding datamaps don't seem that hard, looking into it at the moment... Hopefully you are correct, we'll see once you are done. In the meantime, the keyboard setting API remains broken. As long as we are not about to make a new libosinfo release, this can wait a few more days, right? I really don't see the point of waiting. When something is broken, the priority should be fixing the issue as soon as possible, even if the only solution available is ugly as long as you ensure you don't forget to clean it soon afterwards. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 2/2] fedora, installer: Set keyboard config for = F18
On Fri, Dec 7, 2012 at 3:41 PM, Christophe Fergeau cferg...@redhat.com wrote: On Fri, Dec 07, 2012 at 02:52:24PM +0200, Zeeshan Ali (Khattak) wrote: On Fri, Dec 7, 2012 at 10:06 AM, Christophe Fergeau cferg...@redhat.com wrote: It depends, you did not explain at all why you'd prefer to keep things this way for now. If it would take significant time to remove the duplication, then I could get convinced, but without explanations/arguments it's hard to make a decision. As long as we are not about to make a new libosinfo release, this can wait a few more days, right? I really don't see the point of waiting. For now, things are waiting on you addressing my review comments from this email. I really don't see any way to remove the duplication other than either using datamaps or removing the fix for one of the profiles. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo] Improve list API
On Fri, Dec 7, 2012 at 11:34 AM, Christophe Fergeau cferg...@redhat.com wrote: Hi, libosinfo has various *List classes which basically are a GObject class wrapping a hash table of objects of a specific type. Each of these classes implements osinfo_list_new_filtered, osinfo_list_new_copy, ... probably because of cp. However, these methods are seldomly used, and are not used at all on most classes. It's actually possible to implement these generically in the OsinfoList base class, this is what this series is doing while deprecating all the other implementations in derived classes. I've checked that make check is still working and also ran a quick test with Boxes. Series looks good. Since you have also tested it, ACK! -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [PATCH 0/4] Add some documentation
On Fri, Dec 7, 2012 at 3:22 PM, Michal Privoznik mpriv...@redhat.com wrote: When generating documentation I've noticed couple of warnings produced by gtk-doc like missing field description or incorrect format of enum items description and so on. All patches look good. Thanks and ACK series. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [PATCH 0/4] Add some documentation
On Fri, Dec 7, 2012 at 4:37 PM, Zeeshan Ali (Khattak) zeesha...@gnome.org wrote: On Fri, Dec 7, 2012 at 3:22 PM, Michal Privoznik mpriv...@redhat.com wrote: When generating documentation I've noticed couple of warnings produced by gtk-doc like missing field description or incorrect format of enum items description and so on. All patches look good. Thanks and ACK series. Now pushed! -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 2/2] fedora, installer: Set keyboard config for = F18
On Fri, Dec 7, 2012 at 3:55 PM, Zeeshan Ali (Khattak) zeesha...@gnome.org wrote: On Fri, Dec 7, 2012 at 3:41 PM, Christophe Fergeau cferg...@redhat.com wrote: On Fri, Dec 07, 2012 at 02:52:24PM +0200, Zeeshan Ali (Khattak) wrote: On Fri, Dec 7, 2012 at 10:06 AM, Christophe Fergeau cferg...@redhat.com wrote: It depends, you did not explain at all why you'd prefer to keep things this way for now. If it would take significant time to remove the duplication, then I could get convinced, but without explanations/arguments it's hard to make a decision. As long as we are not about to make a new libosinfo release, this can wait a few more days, right? I really don't see the point of waiting. For now, things are waiting on you addressing my review comments from this email. I really don't see any way to remove the duplication other than either using datamaps or removing the fix for one of the profiles. Does that address your review comment or is this still waiting on me? -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 2/2] fedora, installer: Set keyboard config for = F18
On Fri, Dec 7, 2012 at 6:55 PM, Christophe Fergeau cferg...@redhat.com wrote: On Fri, Dec 07, 2012 at 03:55:22PM +0200, Zeeshan Ali (Khattak) wrote: I really don't see any way to remove the duplication other than either using datamaps or removing the fix for one of the profiles. The good news is that the datamap code at http://cgit.freedesktop.org/~teuf/libosinfo/log/?h=datamap seems to be working. I'll send it for review early next week once I've tested it a bit more. That would mean we can't get libosinfo-based installer stuff in Boxes done for Monday's release and I'm very keen on getting that done so unless there is anything else wrong with this patch other than it being ugly, I'll push it. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 2/2] fedora, installer: Set keyboard config for = F18
On Fri, Dec 7, 2012 at 7:12 PM, Christophe Fergeau cferg...@redhat.com wrote: On Fri, Dec 07, 2012 at 07:02:05PM +0200, Zeeshan Ali (Khattak) wrote: On Fri, Dec 7, 2012 at 6:55 PM, Christophe Fergeau cferg...@redhat.com wrote: On Fri, Dec 07, 2012 at 03:55:22PM +0200, Zeeshan Ali (Khattak) wrote: I really don't see any way to remove the duplication other than either using datamaps or removing the fix for one of the profiles. The good news is that the datamap code at http://cgit.freedesktop.org/~teuf/libosinfo/log/?h=datamap seems to be working. I'll send it for review early next week once I've tested it a bit more. That would mean we can't get libosinfo-based installer stuff in Boxes done for Monday's release and I'm very keen on getting that done so unless there is anything else wrong with this patch other than it being ugly, I'll push it. I hate things always having to be done in a rush, ugly patches always having a good reason to get pushed without being improved, If you think I did not provide any justification, you might want to read previous emails again. ... In this case, this also means new API/ABI getting frozen without having been exercised a lot. This patch does not touch any API/ABI. The patch that did in a way was touching the API/ABI was install-config: Document expected kbd layout format and that was already ack'ed by you and merged. This patch only fixes the script as per that change. If you push the patch anyway (and I'm not saying it's ok with me if you do that), I expect to get a patch from you moving these things over datamaps by the time I send the series for review. I promise to do that next week but once your datamap changes are merged (or at least ACK'ed). -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] [libosinfo] fedora, win, installer: Assume full paths
From: Zeeshan Ali (Khattak) zeesha...@gnome.org According to the documentation, we expect apps to specify full paths for disks and locations so we must assume they are so in the scripts. --- data/install-scripts/fedora.xml | 12 ++-- data/install-scripts/windows-cmd.xml | 2 +- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/data/install-scripts/fedora.xml b/data/install-scripts/fedora.xml index b3c2b47..99218cd 100644 --- a/data/install-scripts/fedora.xml +++ b/data/install-scripts/fedora.xml @@ -24,15 +24,15 @@ /xsl:when xsl:when test=os/version gt; 9 !-- virtio -- - xsl:textvda/xsl:text + xsl:text/dev/vda/xsl:text /xsl:when xsl:when test=os/version gt; 6 !-- libata IDE -- - xsl:textsda/xsl:text + xsl:text/dev/sda/xsl:text /xsl:when xsl:otherwise !-- IDE -- - xsl:texthda/xsl:text + xsl:text/dev/hda/xsl:text /xsl:otherwise /xsl:choose /xsl:template @@ -225,15 +225,15 @@ reboot /xsl:when xsl:when test=os/version gt; 9 !-- virtio -- - xsl:textvda/xsl:text + xsl:text/dev/vda/xsl:text /xsl:when xsl:when test=os/version gt; 6 !-- libata IDE -- - xsl:textsda/xsl:text + xsl:text/dev/sda/xsl:text /xsl:when xsl:otherwise !-- IDE -- - xsl:texthda/xsl:text + xsl:text/dev/hda/xsl:text /xsl:otherwise /xsl:choose /xsl:template diff --git a/data/install-scripts/windows-cmd.xml b/data/install-scripts/windows-cmd.xml index 84833a9..85aae12 100644 --- a/data/install-scripts/windows-cmd.xml +++ b/data/install-scripts/windows-cmd.xml @@ -51,7 +51,7 @@ sc config TlntSvr start= auto net user xsl:value-of select=config/user-realname/ xsl:text /xsl:text xsl:value-of select=config/admin-password/ /add /passwordreq:no net localgroup administrators xsl:value-of select=config/user-realname/ /add net accounts /maxpwage:unlimited -if not xsl:value-of select=config/avatar-location/== copy xsl:value-of select=config/avatar-disk/:\xsl:value-of select=config/avatar-location/ xsl:call-template name=target-disk/:\Documents and Settings\All Users\Application Data\Microsoft\User Account Pictures\xsl:value-of select=config/user-realname/.bmp +if not xsl:value-of select=config/avatar-location/== copy xsl:value-of select=config/avatar-disk/:xsl:value-of select=config/avatar-location/ xsl:call-template name=target-disk/:\Documents and Settings\All Users\Application Data\Microsoft\User Account Pictures\xsl:value-of select=config/user-realname/.bmp REGEDIT /S xsl:call-template name=script-disk/:\windows.reg EXIT /xsl:template -- 1.8.0.1 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 2/2] fedora, installer: Set keyboard config for = F18
On Wed, Dec 5, 2012 at 6:08 PM, Zeeshan Ali (Khattak) zeesha...@gnome.org wrote: On Wed, Dec 5, 2012 at 5:56 PM, Christophe Fergeau cferg...@redhat.com wrote: Hey Hi, I don't think it's good to duplicate the mapping twice, and that's a good candidate for these datamaps. I agree but for now we can do it this way. Once we have the datamaps in place, we can make use of them here. So whats the verdict on this? -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 2/2] fedora, installer: Set keyboard config for = F18
On Thu, Dec 6, 2012 at 4:06 PM, Christophe Fergeau cferg...@redhat.com wrote: On Thu, Dec 06, 2012 at 03:12:36PM +0200, Zeeshan Ali (Khattak) wrote: On Wed, Dec 5, 2012 at 6:08 PM, Zeeshan Ali (Khattak) zeesha...@gnome.org wrote: On Wed, Dec 5, 2012 at 5:56 PM, Christophe Fergeau cferg...@redhat.com wrote: Hey Hi, I don't think it's good to duplicate the mapping twice, and that's a good candidate for these datamaps. I agree but for now we can do it this way. Once we have the datamaps in place, we can make use of them here. So whats the verdict on this? I don't think it's good to duplicate the mapping twice. I understood this very simple sentence the first time too. :) I also said that I agree with it. I only wanted to know if its OK like that for now to improve later. I guess the answer is 'no' then. And adding datamaps don't seem that hard, looking into it at the moment... Hopefully you are correct, we'll see once you are done. In the meantime, the keyboard setting API remains broken. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] [libosinfo] loader: Fix media object leaks
From: Zeeshan Ali (Khattak) zeesha...@gnome.org --- osinfo/osinfo_loader.c | 1 + 1 file changed, 1 insertion(+) diff --git a/osinfo/osinfo_loader.c b/osinfo/osinfo_loader.c index c49d303..a4dd01d 100644 --- a/osinfo/osinfo_loader.c +++ b/osinfo/osinfo_loader.c @@ -957,6 +957,7 @@ static void osinfo_loader_os(OsinfoLoader *loader, break; osinfo_os_add_media (os, media); +g_object_unref (media); } g_free(nodes); -- 1.8.0.1 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 7/8] rfc: Infer ISO language from label
On Wed, Dec 5, 2012 at 11:15 AM, Christophe Fergeau cferg...@redhat.com wrote: On Tue, Dec 04, 2012 at 04:08:00PM +0200, Zeeshan Ali (Khattak) wrote: On Tue, Dec 4, 2012 at 1:01 PM, Daniel P. Berrange berra...@redhat.com wrote: The values required for each of these setters is really OS-specific. To properly isolate apps from this, we need to have a data map concept, so libosinfo defines a canonical set of keyboard, language and timezone values, and then maps to the OS-specific values internally. This ISO language extraction is just another example of the need for a general datamap capability IMHO, and while we only see it for Windows currently, I would not be suprised if other OS we encounter in the future need it too. I did actually start hacking up datamap support, but never finished it. Not sure there is really a need to do mapping in the code for at least the installers. Apart from app developers, we need to think about non-C-hackers to be able to add data (including installer script templates). If we put this in C, anyone wanting to add a new OS and/or its installer will then be required to have to hack on libosinfo in C. They will need to make changes in the C code if they need a new datamap, they won't need to if they can reuse the existing one. That might not be such a bad thing but is there a way to communicate that to them. Perhaps comments in the XML saying these values get mapped to XXX by libosinfo? Doesn't the alternative involve them writing some xslt instead? For installers, yes but thats what they are supposed to do anyways in there. For the other XML, i don't see how we can use XSLT but i'm no XML/XSLT expert. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] [libosinfo] Device drivers API/data
These patches add means for apps to find and fetch device drivers and to tell installer about where to find pre- and post-installation device drivers. Also included is the first implementation: virtio storage device drivers for Windows XP and Windows 7. I have tested these against Boxes and they seem to work flawlessly. I have not yet finalized and uploaded the Boxes patch but it will be available here soon: https://bugzilla.gnome.org/show_bug.cgi?id=676537 Note that the viostor driver files are currently located in private webspace. We can move those files once we have mergable patches. ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] [libosinfo 04/10] schema: Allow driver info under os nodes
From: Zeeshan Ali (Khattak) zeesha...@gnome.org This defines the XML we'll use to add device driver information to our XML database. --- data/schemas/libosinfo.rng | 31 +++ 1 file changed, 31 insertions(+) diff --git a/data/schemas/libosinfo.rng b/data/schemas/libosinfo.rng index 87635dd..3eff268 100644 --- a/data/schemas/libosinfo.rng +++ b/data/schemas/libosinfo.rng @@ -400,6 +400,34 @@ /element /define + define name='driver' +element name='driver' + attribute name='arch' +text/ + /attribute + attribute name='location' +text/ + /attribute + optional +attribute name=pre-installable + ref name='bool'/ +/attribute + /optional + zeroOrMore +element name='file' + text/ +/element + /zeroOrMore + oneOrMore +element name='device' + attribute name='id' +ref name='url'/ + /attribute +/element + /oneOrMore +/element + /define + define name='os' element name='os' interleave @@ -422,6 +450,9 @@ zeroOrMore ref name='installer'/ /zeroOrMore +zeroOrMore + ref name='driver'/ +/zeroOrMore /interleave /element /define -- 1.8.0.1 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] [libosinfo 01/10] Add DeviceDriver class
From: Zeeshan Ali (Khattak) zeesha...@gnome.org
---
osinfo/Makefile.am| 3 +
osinfo/libosinfo.syms | 7 ++
osinfo/osinfo.h | 1 +
osinfo/osinfo_device_driver.c | 181 ++
osinfo/osinfo_device_driver.h | 93 +
osinfo/osinfo_device_driver_private.h | 41
6 files changed, 326 insertions(+)
create mode 100644 osinfo/osinfo_device_driver.c
create mode 100644 osinfo/osinfo_device_driver.h
create mode 100644 osinfo/osinfo_device_driver_private.h
diff --git a/osinfo/Makefile.am b/osinfo/Makefile.am
index c8a831b..996a498 100644
--- a/osinfo/Makefile.am
+++ b/osinfo/Makefile.am
@@ -59,6 +59,7 @@ libosinfo_1_0_include_HEADERS = \
osinfo_db.h \
osinfo_loader.h \
osinfo_device.h \
+ osinfo_device_driver.h \
osinfo_devicelink.h \
osinfo_devicelist.h \
osinfo_devicelinklist.h \
@@ -95,6 +96,8 @@ libosinfo_1_0_la_SOURCES = \
osinfo_filter.c\
osinfo_list.c \
osinfo_device.c\
+ osinfo_device_driver.c \
+ osinfo_device_driver_private.h \
osinfo_devicelink.c\
osinfo_devicelist.c\
osinfo_devicelinklist.c\
diff --git a/osinfo/libosinfo.syms b/osinfo/libosinfo.syms
index 2824678..09c0d3e 100644
--- a/osinfo/libosinfo.syms
+++ b/osinfo/libosinfo.syms
@@ -323,6 +323,13 @@ LIBOSINFO_0.2.2 {
osinfo_avatar_format_get_height;
osinfo_avatar_format_get_alpha;
+ osinfo_device_driver_get_type;
+ osinfo_device_driver_get_architecture;
+ osinfo_device_driver_get_devices;
+ osinfo_device_driver_get_location;
+ osinfo_device_driver_get_files;
+ osinfo_device_driver_get_pre_installable;
+
osinfo_install_config_param_policy_get_type;
osinfo_media_error_get_type;
osinfo_product_relationship_get_type;
diff --git a/osinfo/osinfo.h b/osinfo/osinfo.h
index 559eaa8..7acd70a 100644
--- a/osinfo/osinfo.h
+++ b/osinfo/osinfo.h
@@ -32,6 +32,7 @@
#include osinfo/osinfo_filter.h
#include osinfo/osinfo_list.h
#include osinfo/osinfo_device.h
+#include osinfo/osinfo_device_driver.h
#include osinfo/osinfo_devicelink.h
#include osinfo/osinfo_devicelist.h
#include osinfo/osinfo_devicelinklist.h
diff --git a/osinfo/osinfo_device_driver.c b/osinfo/osinfo_device_driver.c
new file mode 100644
index 000..9a7e5e2
--- /dev/null
+++ b/osinfo/osinfo_device_driver.c
@@ -0,0 +1,181 @@
+/*
+ * libosinfo: Device driver
+ *
+ * Copyright (C) 2009-2012 Red Hat, Inc.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
USA
+ *
+ * Authors:
+ * Zeeshan Ali zee...@redhat.com
+ */
+
+#include config.h
+
+#include osinfo/osinfo.h
+#include gio/gio.h
+#include stdlib.h
+#include string.h
+#include glib/gi18n-lib.h
+
+#include osinfo_device_driver_private.h
+
+G_DEFINE_TYPE (OsinfoDeviceDriver, osinfo_device_driver, OSINFO_TYPE_ENTITY);
+
+#define OSINFO_DEVICE_DRIVER_GET_PRIVATE(obj) \
+(G_TYPE_INSTANCE_GET_PRIVATE ((obj), \
+ OSINFO_TYPE_DEVICE_DRIVER, \
+ OsinfoDeviceDriverPrivate))
+
+/**
+ * SECTION:osinfo_device_driver
+ * @short_description: Information about device driver
+ * @see_also: #OsinfoOs
+ *
+ * #OsinfoDeviceDriver is an entity representing device drivers for an (guest)
+ * operating system.
+ */
+
+struct _OsinfoDeviceDriverPrivate
+{
+OsinfoDeviceList *devices;
+};
+
+static void
+osinfo_device_driver_finalize (GObject *object)
+{
+OsinfoDeviceDriver *driver = OSINFO_DEVICE_DRIVER (object);
+
+g_object_unref(driver-priv-devices);
+
+/* Chain up to the parent class */
+G_OBJECT_CLASS (osinfo_device_driver_parent_class)-finalize (object);
+}
+
+/* Init functions */
+static void
+osinfo_device_driver_class_init (OsinfoDeviceDriverClass *klass)
+{
+GObjectClass *g_klass = G_OBJECT_CLASS (klass);
+
+g_klass-finalize = osinfo_device_driver_finalize;
+g_type_class_add_private (klass, sizeof (OsinfoDeviceDriverPrivate));
+}
+
+static void
+osinfo_device_driver_init (OsinfoDeviceDriver *driver)
+{
+OsinfoDeviceDriverPrivate
[virt-tools-list] [libosinfo 02/10] Add DeviceDriverList class
From: Zeeshan Ali (Khattak) zeesha...@gnome.org
OsinfoDeviceDriverList is a list specialization that stores only
OsinfoDeviceDriver objects.
---
osinfo/Makefile.am| 2 +
osinfo/libosinfo.syms | 7 ++
osinfo/osinfo.h | 1 +
osinfo/osinfo_device_driverlist.c | 171 ++
osinfo/osinfo_device_driverlist.h | 93 +
5 files changed, 274 insertions(+)
create mode 100644 osinfo/osinfo_device_driverlist.c
create mode 100644 osinfo/osinfo_device_driverlist.h
diff --git a/osinfo/Makefile.am b/osinfo/Makefile.am
index 996a498..1cbacea 100644
--- a/osinfo/Makefile.am
+++ b/osinfo/Makefile.am
@@ -60,6 +60,7 @@ libosinfo_1_0_include_HEADERS = \
osinfo_loader.h \
osinfo_device.h \
osinfo_device_driver.h \
+ osinfo_device_driverlist.h \
osinfo_devicelink.h \
osinfo_devicelist.h \
osinfo_devicelinklist.h \
@@ -98,6 +99,7 @@ libosinfo_1_0_la_SOURCES = \
osinfo_device.c\
osinfo_device_driver.c \
osinfo_device_driver_private.h \
+ osinfo_device_driverlist.c \
osinfo_devicelink.c\
osinfo_devicelist.c\
osinfo_devicelinklist.c\
diff --git a/osinfo/libosinfo.syms b/osinfo/libosinfo.syms
index 09c0d3e..0f1d751 100644
--- a/osinfo/libosinfo.syms
+++ b/osinfo/libosinfo.syms
@@ -330,6 +330,13 @@ LIBOSINFO_0.2.2 {
osinfo_device_driver_get_files;
osinfo_device_driver_get_pre_installable;
+ osinfo_device_driverlist_get_type;
+ osinfo_device_driverlist_new;
+ osinfo_device_driverlist_new_copy;
+ osinfo_device_driverlist_new_filtered;
+ osinfo_device_driverlist_new_intersection;
+ osinfo_device_driverlist_new_union;
+
osinfo_install_config_param_policy_get_type;
osinfo_media_error_get_type;
osinfo_product_relationship_get_type;
diff --git a/osinfo/osinfo.h b/osinfo/osinfo.h
index 7acd70a..836baf1 100644
--- a/osinfo/osinfo.h
+++ b/osinfo/osinfo.h
@@ -33,6 +33,7 @@
#include osinfo/osinfo_list.h
#include osinfo/osinfo_device.h
#include osinfo/osinfo_device_driver.h
+#include osinfo/osinfo_device_driverlist.h
#include osinfo/osinfo_devicelink.h
#include osinfo/osinfo_devicelist.h
#include osinfo/osinfo_devicelinklist.h
diff --git a/osinfo/osinfo_device_driverlist.c
b/osinfo/osinfo_device_driverlist.c
new file mode 100644
index 000..fecc124
--- /dev/null
+++ b/osinfo/osinfo_device_driverlist.c
@@ -0,0 +1,171 @@
+/*
+ * libosinfo: Device driver list
+ *
+ * Copyright (C) 2009-2012 Red Hat, Inc.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
USA
+ *
+ * Authors:
+ * Zeeshan Ali zee...@redhat.com
+ * Arjun Roy ar...@redhat.com
+ * Daniel P. Berrange berra...@redhat.com
+ */
+
+#include config.h
+
+#include osinfo/osinfo.h
+#include glib/gi18n-lib.h
+
+G_DEFINE_TYPE (OsinfoDeviceDriverList, osinfo_device_driverlist,
OSINFO_TYPE_LIST);
+
+#define OSINFO_DEVICE_DRIVERLIST_GET_PRIVATE(obj) (G_TYPE_INSTANCE_GET_PRIVATE
((obj), OSINFO_TYPE_DEVICE_DRIVERLIST, OsinfoDeviceDriverListPrivate))
+
+/**
+ * SECTION:osinfo_device_driverlist
+ * @short_description: A list of device drivers
+ * @see_also: #OsinfoList, #OsinfoDeviceDriver
+ *
+ * #OsinfoDeviceDriverList is a list specialization that stores only
+ * #OsinfoDeviceDriver objects.
+ */
+
+struct _OsinfoDeviceDriverListPrivate
+{
+gboolean unused;
+};
+
+static void
+osinfo_device_driverlist_finalize (GObject *object)
+{
+/* Chain up to the parent class */
+G_OBJECT_CLASS (osinfo_device_driverlist_parent_class)-finalize (object);
+}
+
+/* Init functions */
+static void
+osinfo_device_driverlist_class_init (OsinfoDeviceDriverListClass *klass)
+{
+GObjectClass *g_klass = G_OBJECT_CLASS (klass);
+
+g_klass-finalize = osinfo_device_driverlist_finalize;
+g_type_class_add_private (klass, sizeof (OsinfoDeviceDriverListPrivate));
+}
+
+static void
+osinfo_device_driverlist_init (OsinfoDeviceDriverList *list)
+{
+OsinfoDeviceDriverListPrivate *priv;
+list-priv = priv = OSINFO_DEVICE_DRIVERLIST_GET_PRIVATE(list);
+
+}
+
+/**
+ * osinfo_device_driverlist_new:
+ *
+ * Construct a new device driver list that is initially
[virt-tools-list] [libosinfo 08/10] winxp, win7, installer: Claim drivers pre-install capability
From: Zeeshan Ali (Khattak) zeesha...@gnome.org --- data/install-scripts/windows-sif.xml | 2 ++ data/install-scripts/windows-unattend.xml | 2 ++ 2 files changed, 4 insertions(+) diff --git a/data/install-scripts/windows-sif.xml b/data/install-scripts/windows-sif.xml index b16d979..2947efa 100644 --- a/data/install-scripts/windows-sif.xml +++ b/data/install-scripts/windows-sif.xml @@ -5,6 +5,7 @@ path-formatdos/path-format product-key-format$-$-$-$-$/product-key-format expected-filenamewinnt.sif/expected-filename +can-pre-install-driverstrue/can-pre-install-drivers config param name=admin-password policy=optional/ param name=reg-product-key policy=required/ @@ -70,6 +71,7 @@ path-formatdos/path-format product-key-format$-$-$-$-$/product-key-format expected-filenamewinnt.sif/expected-filename +can-pre-install-driverstrue/can-pre-install-drivers config param name=admin-password policy=optional/ param name=reg-product-key policy=required/ diff --git a/data/install-scripts/windows-unattend.xml b/data/install-scripts/windows-unattend.xml index 0901e5b..2cf2235 100644 --- a/data/install-scripts/windows-unattend.xml +++ b/data/install-scripts/windows-unattend.xml @@ -4,6 +4,7 @@ path-formatdos/path-format product-key-format$-$-$-$-$/product-key-format expected-filenameautounattend.xml/expected-filename + can-pre-install-driverstrue/can-pre-install-drivers config param name=admin-password policy=optional/ param name=hardware-arch policy=optional/ @@ -201,6 +202,7 @@ path-formatdos/path-format product-key-format$-$-$-$-$/product-key-format expected-filenameautounattend.xml/expected-filename + can-pre-install-driverstrue/can-pre-install-drivers config param name=admin-password policy=optional/ param name=hardware-arch policy=required/ -- 1.8.0.1 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] [libosinfo 10/10] win7, installer: Setup pre-installation drivers
From: Zeeshan Ali (Khattak) zeesha...@gnome.org --- data/install-scripts/windows-unattend.xml | 68 +++ 1 file changed, 68 insertions(+) diff --git a/data/install-scripts/windows-unattend.xml b/data/install-scripts/windows-unattend.xml index 2cf2235..de84b65 100644 --- a/data/install-scripts/windows-unattend.xml +++ b/data/install-scripts/windows-unattend.xml @@ -14,6 +14,8 @@ param name=user-realname policy=optional/ param name=reg-product-key policy=optional/ param name=target-disk policy=optional/ + param name=pre-install-drivers-disk policy=optional/ + param name=pre-install-drivers-location policy=optional/ /config template xsl:stylesheet @@ -61,9 +63,41 @@ /xsl:choose /xsl:template +xsl:template name=pre-install-drivers-disk + xsl:choose +xsl:when test=config/pre-install-drivers-disk != '' + xsl:value-of select=config/pre-install-drivers-disk/ +/xsl:when + xsl:otherwise + xsl:textA/xsl:text + /xsl:otherwise + /xsl:choose +/xsl:template + +xsl:template name=pre-install-drivers-location + xsl:choose +xsl:when test=config/pre-install-drivers-location != '' + xsl:value-of select=config/pre-install-drivers-location/ +/xsl:when + xsl:otherwise + xsl:text\/xsl:text + /xsl:otherwise + /xsl:choose +/xsl:template + xsl:template match=/install-script-config unattend xmlns=urn:schemas-microsoft-com:unattend settings pass=windowsPE + component name=Microsoft-Windows-PnpCustomizationsWinPE publicKeyToken=31bf3856ad364e35 language=neutral versionScope=nonSxS xmlns:wcm=http://schemas.microsoft.com/WMIConfig/2002/State; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; +xsl:attribute name=processorArchitecture + xsl:call-template name=arch/ +/xsl:attribute +DriverPaths + PathAndCredentials wcm:keyValue=1 wcm:action=add +Pathxsl:call-template name=pre-install-drivers-disk/:xsl:call-template name=pre-install-drivers-location//Path + /PathAndCredentials +/DriverPaths + /component component name=Microsoft-Windows-Setup publicKeyToken=31bf3856ad364e35 language=neutral versionScope=nonSxS xmlns:wcm=http://schemas.microsoft.com/WMIConfig/2002/State; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsl:attribute name=processorArchitecture xsl:call-template name=arch/ @@ -213,6 +247,8 @@ param name=hostname policy=required/ param name=reg-product-key policy=optional/ param name=target-disk policy=optional/ +param name=pre-install-drivers-disk policy=optional/ +param name=pre-install-drivers-location policy=optional/ /config template xsl:stylesheet @@ -263,9 +299,41 @@ /xsl:choose /xsl:template + xsl:template name=pre-install-drivers-disk + xsl:choose + xsl:when test=config/pre-install-drivers-disk != '' + xsl:value-of select=config/pre-install-drivers-disk/ + /xsl:when +xsl:otherwise + xsl:textA/xsl:text +/xsl:otherwise + /xsl:choose + /xsl:template + + xsl:template name=pre-install-drivers-location + xsl:choose + xsl:when test=config/pre-install-drivers-location != '' + xsl:value-of select=config/pre-install-drivers-location/ + /xsl:when +xsl:otherwise + xsl:text\/xsl:text +/xsl:otherwise + /xsl:choose + /xsl:template + xsl:template match=/install-script-config unattend xmlns=urn:schemas-microsoft-com:unattend settings pass=windowsPE + component name=Microsoft-Windows-PnpCustomizationsWinPE publicKeyToken=31bf3856ad364e35 language=neutral versionScope=nonSxS xmlns:wcm=http://schemas.microsoft.com/WMIConfig/2002/State; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; + xsl:attribute name=processorArchitecture + xsl:call-template name=arch/ + /xsl:attribute + DriverPaths + PathAndCredentials wcm:keyValue=1 wcm:action=add + Pathxsl:call-template name=pre-install-drivers-disk/:xsl:call-template name=pre-install-drivers-location//Path + /PathAndCredentials + /DriverPaths +/component component name=Microsoft-Windows-Setup publicKeyToken=31bf3856ad364e35 language=neutral versionScope=nonSxS xmlns:wcm=http://schemas.microsoft.com/WMIConfig/2002/State; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsl:attribute name=processorArchitecture xsl:call-template name=arch/ -- 1.8.0.1
[virt-tools-list] [libosinfo 06/10] win7, xp: Provide info on viostor drivers
From: Zeeshan Ali (Khattak) zeesha...@gnome.org The drivers are currently availalable from my own webspace, we should probably put it in a more canonical location and update this patch once the approach taken here is agreed upon by everyone. --- data/oses/windows.xml.in | 34 ++ 1 file changed, 34 insertions(+) diff --git a/data/oses/windows.xml.in b/data/oses/windows.xml.in index d09e873..a3ff365 100644 --- a/data/oses/windows.xml.in +++ b/data/oses/windows.xml.in @@ -378,6 +378,25 @@ script id='http://microsoft.com/windows/reg/desktop'/ script id='http://microsoft.com/windows/cmd/desktop'/ /installer + +!-- virtio block device driver -- +driver arch=i386 location=http://zeenix.fedorapeople.org/drivers/win-tools/preinst/winxp/x86; pre-installable=true + fileviostor.cat/file + fileviostor.inf/file + fileviostor.sys/file + !-- For now we require this for pre-installation but we should probably generate this too -- + filetxtsetup.oem/file + device id=http://pciids.sourceforge.net/v2.2/pci.ids/1af4/1001/ +/driver + +driver arch=x86_64 location=http://zeenix.fedorapeople.org/drivers/win-tools/preinst/winxp/amd64; pre-installable=true + fileviostor.cat/file + fileviostor.inf/file + fileviostor.sys/file + !-- For now we require this for pre-installation but we should probably generate this too -- + filetxtsetup.oem/file + device id=http://pciids.sourceforge.net/v2.2/pci.ids/1af4/1001/ +/driver /os os id=http://microsoft.com/win/2k3; @@ -718,6 +737,21 @@ script id='http://microsoft.com/windows/unattend/jeos'/ script id='http://microsoft.com/windows/unattend/desktop'/ /installer + +!-- virtio block device driver -- +driver arch=i386 location=http://zeenix.fedorapeople.org/drivers/win-tools/preinst/win7/x86; pre-installable=true + fileviostor.cat/file + fileviostor.inf/file + fileviostor.sys/file + device id=http://pciids.sourceforge.net/v2.2/pci.ids/1af4/1001/ +/driver + +driver arch=x86_64 location=http://zeenix.fedorapeople.org/drivers/win-tools/preinst/win7/amd64; pre-installable=true + fileviostor.cat/file + fileviostor.inf/file + fileviostor.sys/file + device id=http://pciids.sourceforge.net/v2.2/pci.ids/1af4/1001/ +/driver /os os id=http://microsoft.com/win/8; -- 1.8.0.1 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 7/8] rfc: Infer ISO language from label
On Wed, Dec 5, 2012 at 4:11 PM, Daniel P. Berrange berra...@redhat.com wrote: On Tue, Dec 04, 2012 at 04:08:00PM +0200, Zeeshan Ali (Khattak) wrote: On Tue, Dec 4, 2012 at 1:01 PM, Daniel P. Berrange berra...@redhat.com wrote: On Tue, Dec 04, 2012 at 11:47:06AM +0100, Christophe Fergeau wrote: On Mon, Dec 03, 2012 at 06:30:18PM +0200, Zeeshan Ali (Khattak) wrote: I agree with you that it would be nice to avoid this mapping all together but if its not possible/feasible, these mappings should be in the XML like rest of OS specific stuff. I could do that, but the C code would still have to match the regex with data from the table, which is only useful to Windows anyway, so the C code would still be somehow Windows specific. Looking at the problem more broadly, I believe we have a general need to have OS specific data maps for several installation aspects. In the OsinfoInstallConfig class we have setters for the keyboard layout, language, AFAICT, we already have solution for those. It involves maps but in the xml itself. The benefit of having t datamaps explicitly represented in the API is that it allows apps to determine which mappings are actually valid for a given OS. ie not all OS support all possible keymaps This ISO language extraction is just another example of the need for a general datamap capability IMHO, and while we only see it for Windows currently, I would not be suprised if other OS we encounter in the future need it too. I did actually start hacking up datamap support, but never finished it. Not sure there is really a need to do mapping in the code for at least the installers. Apart from app developers, we need to think about non-C-hackers to be able to add data (including installer script templates). If we put this in C, anyone wanting to add a new OS and/or its installer will then be required to have to hack on libosinfo in C. Huh, no, that's not right. Adding a new OS in the XML will just require adding a new datamap in the XML too. Never touching C code. The existing GVirInstallSCript class will automatically identify the required datamap and apply the mapping to properties being passed in Ah cool, then I misunderstood your patch/idea. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 2/2] fedora, installer: Set keyboard config for = F18
On Wed, Dec 5, 2012 at 5:56 PM, Christophe Fergeau cferg...@redhat.com wrote: Hey Hi, I don't think it's good to duplicate the mapping twice, and that's a good candidate for these datamaps. I agree but for now we can do it this way. Once we have the datamaps in place, we can make use of them here. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 2/8] Make OsinfoMedia::os a weak reference
On Mon, Dec 3, 2012 at 3:23 PM, Christophe Fergeau cferg...@redhat.com wrote: On Mon, Dec 03, 2012 at 12:23:31PM +0100, Christophe Fergeau wrote: OsinfoOs stores a list of media when it's part of an OsinfoDb. If these OsinfoMedia took a reference on the OsinfoOs they are part of, we'd get a circular reference. Should be squashed in the first patch. Yeah, ACK with this squashed into first patch. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 1/8] Add OsinfoMedia::os property
On Mon, Dec 3, 2012 at 1:23 PM, Christophe Fergeau cferg...@redhat.com wrote:
---
osinfo/osinfo_media.c | 51
++-
osinfo/osinfo_media.h | 2 ++
2 files changed, 52 insertions(+), 1 deletion(-)
diff --git a/osinfo/osinfo_media.c b/osinfo/osinfo_media.c
index ffc37b7..6d0bdec 100644
--- a/osinfo/osinfo_media.c
+++ b/osinfo/osinfo_media.c
@@ -136,7 +136,7 @@ G_DEFINE_TYPE (OsinfoMedia, osinfo_media,
OSINFO_TYPE_ENTITY);
struct _OsinfoMediaPrivate
{
-gboolean unused;
+OsinfoOs *os;
};
enum {
@@ -153,6 +153,7 @@ enum {
PROP_INSTALLER,
PROP_LIVE,
PROP_INSTALLER_REBOOTS,
+PROP_OS
};
static void
@@ -219,6 +220,10 @@ osinfo_media_get_property (GObject*object,
osinfo_media_get_installer_reboots (media));
break;
+case PROP_OS:
+g_value_set_object (value, osinfo_media_get_os (media));
+break;
+
default:
/* We don't have any other property... */
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, property_id, pspec);
@@ -301,6 +306,10 @@ osinfo_media_set_property(GObject *object,
g_value_get_int (value));
break;
+case PROP_OS:
+osinfo_media_set_os(media, g_value_get_object(value));
+break;
+
default:
/* We don't have any other property... */
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, property_id, pspec);
@@ -315,6 +324,16 @@ osinfo_media_finalize (GObject *object)
G_OBJECT_CLASS (osinfo_media_parent_class)-finalize (object);
}
+static void osinfo_media_dispose(GObject *obj)
+{
+OsinfoMedia *media = OSINFO_MEDIA(obj);
+
+g_clear_object(media-priv-os);
+
+G_OBJECT_CLASS(osinfo_media_parent_class)-dispose(obj);
+}
+
+
/* Init functions */
static void
osinfo_media_class_init (OsinfoMediaClass *klass)
@@ -322,6 +341,7 @@ osinfo_media_class_init (OsinfoMediaClass *klass)
GObjectClass *g_klass = G_OBJECT_CLASS (klass);
GParamSpec *pspec;
+g_klass-dispose = osinfo_media_dispose;
g_klass-finalize = osinfo_media_finalize;
g_klass-get_property = osinfo_media_get_property;
g_klass-set_property = osinfo_media_set_property;
@@ -480,6 +500,20 @@ osinfo_media_class_init (OsinfoMediaClass *klass)
G_PARAM_READWRITE |
G_PARAM_STATIC_STRINGS);
g_object_class_install_property (g_klass, PROP_INSTALLER_REBOOTS, pspec);
+
+/**
+ * OsinfoMedia::os:
+ *
+ * Os information for the current media. Won't get filled before a call
+ * to osinfo_db_fill_media_info
+ */
I don't think this is correct anymore.
ACK otherwise.
--
Regards,
Zeeshan Ali (Khattak)
FSF member#5124
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 3/8] Set OsinfoOs::media for OSes stored in an OsinfoDb
On Mon, Dec 3, 2012 at 1:23 PM, Christophe Fergeau cferg...@redhat.com wrote: --- ACK. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 5/8] Add osinfo_db_identify_media
On Mon, Dec 3, 2012 at 1:23 PM, Christophe Fergeau cferg...@redhat.com wrote:
---
osinfo/libosinfo.syms | 2 +
osinfo/osinfo_db.c| 105
+-
osinfo/osinfo_db.h| 2 +
test/test-isodetect.c | 10 ++---
tools/osinfo-detect.c | 12 --
5 files changed, 87 insertions(+), 44 deletions(-)
diff --git a/osinfo/libosinfo.syms b/osinfo/libosinfo.syms
index 2824678..d45e58e 100644
--- a/osinfo/libosinfo.syms
+++ b/osinfo/libosinfo.syms
@@ -328,6 +328,8 @@ LIBOSINFO_0.2.2 {
osinfo_product_relationship_get_type;
osinfo_path_format_get_type;
+ osinfo_db_identify_media;
+
osinfo_entity_get_param_value_enum;
osinfo_entity_set_param_enum;
diff --git a/osinfo/osinfo_db.c b/osinfo/osinfo_db.c
index 665554c..1e8a93c 100644
--- a/osinfo/osinfo_db.c
+++ b/osinfo/osinfo_db.c
@@ -391,40 +391,6 @@ static gint media_volume_compare (gconstpointer a,
gconstpointer b)
return 1;
}
-static void fill_media (OsinfoMedia *media, OsinfoMedia *matched_media)
-{
-gboolean is_installer;
-gboolean is_live;
-gint reboots;
-const gchar *kernel_path;
-const gchar *initrd_path;
-const gchar *arch;
-const gchar *url;
-
-arch = osinfo_media_get_architecture(matched_media);
-if (arch != NULL)
-g_object_set(G_OBJECT(media), architecture, arch, NULL);
-url = osinfo_media_get_url(matched_media);
-if (url != NULL)
-g_object_set(G_OBJECT(media), url, url, NULL);
-
-kernel_path = osinfo_media_get_kernel_path(matched_media);
-if (kernel_path != NULL)
-g_object_set(G_OBJECT(media), kernel_path, kernel_path, NULL);
-
-initrd_path = osinfo_media_get_initrd_path(matched_media);
-if (initrd_path != NULL)
-g_object_set(G_OBJECT(media), initrd_path, initrd_path, NULL);
-is_installer = osinfo_media_get_installer(matched_media);
-is_live = osinfo_media_get_live(matched_media);
-reboots = osinfo_media_get_installer_reboots(matched_media);
-g_object_set(G_OBJECT(media),
- installer, is_installer,
- live, is_live,
- installer-reboots, reboots,
- NULL);
-}
-
/**
* osinfo_db_guess_os_from_media:
* @db: the database
@@ -477,7 +443,6 @@ OsinfoOs *osinfo_db_guess_os_from_media(OsinfoDb *db,
match_regex (os_system, media_system)
match_regex (os_publisher, media_publisher)) {
ret = os;
-fill_media(media, os_media);
if (matched_media != NULL)
*matched_media = os_media;
break;
@@ -496,6 +461,76 @@ OsinfoOs *osinfo_db_guess_os_from_media(OsinfoDb *db,
return ret;
}
+static void fill_media (OsinfoMedia *media, OsinfoMedia *matched_media,
OsinfoOs *os)
+{
+gboolean is_installer;
+gboolean is_live;
+gint reboots;
+const gchar *kernel_path;
+const gchar *initrd_path;
+const gchar *arch;
+const gchar *url;
+
+arch = osinfo_media_get_architecture(matched_media);
+if (arch != NULL)
+g_object_set(G_OBJECT(media), architecture, arch, NULL);
+url = osinfo_media_get_url(matched_media);
+if (url != NULL)
+g_object_set(G_OBJECT(media), url, url, NULL);
+
+kernel_path = osinfo_media_get_kernel_path(matched_media);
+if (kernel_path != NULL)
+g_object_set(G_OBJECT(media), kernel_path, kernel_path, NULL);
+
+initrd_path = osinfo_media_get_initrd_path(matched_media);
+if (initrd_path != NULL)
+g_object_set(G_OBJECT(media), initrd_path, initrd_path, NULL);
+is_installer = osinfo_media_get_installer(matched_media);
+is_live = osinfo_media_get_live(matched_media);
+g_object_set(G_OBJECT(media),
+ installer, is_installer,
+ live, is_live,
+ NULL);
+if (is_installer) {
+reboots = osinfo_media_get_installer_reboots(matched_media);
+g_object_set(G_OBJECT(media), installer-reboots, reboots, NULL);
+}
+if (os != NULL)
+osinfo_media_set_os(media, os);
+}
+
+/**
+ * osinfo_db_identify_media:
+ * @db: a #OsinfoDb database
+ * @media: the installation media
+ * data
+ *
+ * Try to match the @media created using osinfo_media_create_from_location()
This makes it sound like app developer doesn't have a choice. As an
app developer, I'd think why is libosinfo not creating the media
instance for me if it knows that I'll be doing that just before this
call anyways.
I recall that you are doing it this way because implementing async
version of this method will than be very difficult?
--
Regards,
Zeeshan Ali (Khattak)
FSF member#5124
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 6/8] Deprecate osinfo_db_guess_os_from_media
On Mon, Dec 3, 2012 at 1:23 PM, Christophe Fergeau cferg...@redhat.com wrote:
---
osinfo/osinfo_db.c | 38 +++---
osinfo/osinfo_db.h | 1 +
2 files changed, 24 insertions(+), 15 deletions(-)
diff --git a/osinfo/osinfo_db.c b/osinfo/osinfo_db.c
index 1e8a93c..46101d6 100644
--- a/osinfo/osinfo_db.c
+++ b/osinfo/osinfo_db.c
@@ -391,20 +391,10 @@ static gint media_volume_compare (gconstpointer a,
gconstpointer b)
return 1;
}
-/**
- * osinfo_db_guess_os_from_media:
- * @db: the database
- * @media: the installation media
- * @matched_media: (out) (transfer none) (allow-none): the matched operating
- * system media
- *
- * Guess operating system given a #OsinfoMedia object.
- *
- * Returns: (transfer none): the operating system, or NULL if guessing failed
- */
-OsinfoOs *osinfo_db_guess_os_from_media(OsinfoDb *db,
-OsinfoMedia *media,
-OsinfoMedia **matched_media)
+static OsinfoOs *
+osinfo_db_guess_os_from_media_internal(OsinfoDb *db,
+ OsinfoMedia *media,
+ OsinfoMedia **matched_media)
{
OsinfoOs *ret = NULL;
GList *oss = NULL;
@@ -460,6 +450,23 @@ OsinfoOs *osinfo_db_guess_os_from_media(OsinfoDb *db,
return ret;
}
+/**
+ * osinfo_db_guess_os_from_media:
+ * @db: the database
+ * @media: the installation media
+ * @matched_media: (out) (transfer none) (allow-none): the matched operating
+ * system media
+ *
+ * Guess operating system given a #OsinfoMedia object.
+ *
+ * Returns: (transfer none): the operating system, or NULL if guessing failed
+ */
Don't we need some deprecation note in the doc?
Looks right otherwise.
--
Regards,
Zeeshan Ali (Khattak)
FSF member#5124
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 7/8] rfc: Infer ISO language from label
, pl_PL },
+{ BR, pt_BR },
+{ PT, pt_PT },
+{ RO, ro_RO },
+{ RU, ru_RU },
+{ SRL, sr_RS@latin },
+{ SK, sk_SK },
+{ SL, sl_SI },
+{ ES, es_ES },
+{ SV, sv_SE },
+{ TH, th_TH },
+{ TR, tr_TR },
+{ UK, uk_UA },
+
+/* starting from Windows 8, the ISO label contains both
+ * language and country code */
+{ EN-US, en_US },
+{ EN-GB, en_GB },
+{ AR-SA, ar_SA },
+{ BG-BG, bg_BG },
+{ ZH-HK, zh_HK },
+{ ZH-CN, zh_CN },
+{ ZH-TW, zh_TW },
+{ HR-HR, hr_HR },
+{ CS-CZ, cs_CZ },
+{ DA-DK, da_DK },
+{ NL-NL, nl_NL },
+{ ET-EE, et_EE },
+{ FI-FI, fi_FI },
+{ FR-FR, fr_FR },
+{ DE-DE, de_DE },
+{ EL-GR, el_GR },
+{ HE-IL, he_IL },
+{ HU-HU, hu_HU },
+{ IT-IT, it_IT },
+{ JA-JP, ja_JP },
+{ KO-KR, ko_KR },
+{ LV-LV, lv_LV },
+{ LT-LT, lt_LT },
+{ NB-NO, nb_NO },
+{ PL-PL, pl_PL },
+{ PT-BR, pt_BR },
+{ PT-PT, pt_PT },
+{ RO-RO, ro_RO },
+{ RU-RU, ru_RU },
+{ SR-LATN-CS, sr_RS@latin },
+{ SK-SK, sk_SK },
+{ SL-SI, sl_SI },
+{ ES-ES, es_ES },
+{ SV-SE, sv_SE },
+{ TH-TH, th_TH },
+{ TR-TR, tr_TR },
+{ UK-UA, uk_UA },
+
+{ EU-ES, eu_ES }, //language pack
+{ CA-ES, ca_ES }, //language pack
+{ GL-ES, gl_ES }, //language pack
+{ KY-KG, ky_KG }, //language pack
+
+{ NULL, NULL }
+};
Seems all of these except for 1 can be covered by a simple 's/-/_/'
conversion and thus do not need all this hard coding.
Rest of the patch looks good now as a first implementation. We can
make use of the datamaps API here once that API is available.
--
Regards,
Zeeshan Ali (Khattak)
FSF member#5124
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 8/8] win: Add lang-regex tags
On Mon, Dec 3, 2012 at 1:23 PM, Christophe Fergeau cferg...@redhat.com wrote: Now that libosinfo knows how to use the lang-regex OsinfoDB attribute, we can add this data to the various Windows media definitions in the database. ACK and I'm assuming you'll remove the same entries from patch 7/8? -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo] build-sys: Fix circular make dependency
On Wed, Dec 5, 2012 at 6:17 PM, Christophe Fergeau cferg...@redhat.com wrote: osinfo_enum_types.h was depending on libosinfo_1_0_include_HEADERS, which contains osinfo_enum_types.h. This caused a build-time warning from make about a circular dependency. ACK and thanks for fixing this mess I created. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 7/8] rfc: Infer ISO language from label
On Tue, Dec 4, 2012 at 12:47 PM, Christophe Fergeau cferg...@redhat.com wrote: On Mon, Dec 03, 2012 at 06:30:18PM +0200, Zeeshan Ali (Khattak) wrote: I agree with you that it would be nice to avoid this mapping all together but if its not possible/feasible, these mappings should be in the XML like rest of OS specific stuff. I could do that, but the C code would still have to match the regex with data from the table, which is only useful to Windows anyway, so the C code would still be somehow Windows specific. Then again, if we go that route, I wonder if all this approach is really better than having separate media entries for each combination of supported languages. If we put separate entries in the XML file, this will make it harder to add new volume IDs (plenty of places to update), Not at all. You'll have entries like: media languagesfi_Fi,fr_FR/languages volume-idWHATEVER/volume-id /media media languagesfi_Fi,fr_FR,us_US/languages volume-id(WHATEVER2)|(WHATEVER3)/volume-id /media ... Now if there is a new volume ID to be added, you'll either put it in a new media entry or to an existing entry that has the same languages in its list. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 7/8] rfc: Infer ISO language from label
On Tue, Dec 4, 2012 at 4:59 PM, Christophe Fergeau cferg...@redhat.com wrote: On Tue, Dec 04, 2012 at 03:52:23PM +0200, Zeeshan Ali (Khattak) wrote: Not at all. You'll have entries like: media languagesfi_Fi,fr_FR/languages volume-idWHATEVER/volume-id /media media languagesfi_Fi,fr_FR,us_US/languages volume-id(WHATEVER2)|(WHATEVER3)/volume-id /media ... Now if there is a new volume ID to be added, you'll either put it in a new media entry or to an existing entry that has the same languages in its list. This would work for fedora ISOs. Windows Volume IDs look like EDITION_LANG, where there is a set of valid values for EDITION (this is what we already have in windows.xml), and a set of valid values for LANG (which is what I'm trying to add). EDITION and LANG can be associated more or less freely (some editions are not available in some languages, but this is the exception rather than the norm). This means we would have: media languagesfr_FR/languages volume-idEDITION_FR/volume-id /media media languagesfi_FI/languages volume-id(EDITION_FI|EDITION2_FI)/volume-id /media And if we wanted to add an EDITION3 which is available both in French and Finland, we'd have to change both entries. No, with the approach I was thinking (not exactly suggesting), we'd want to create a separate entry for media support this particular set of languages. I know that still means a lot of entries but at least we won't have to change mechanics of libosinfo for it. BTW if XML files getting too big is also an issue here, we can split those easily in different ways. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 4/8] Fill in media with guessed info in Db::guess_os_from_media
On Mon, Dec 3, 2012 at 1:23 PM, Christophe Fergeau cferg...@redhat.com wrote: --- One of the main reasons for deprecating _guess_os_from_media function and introducing new API was to avoid this change. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 4/8] Fill in media with guessed info in Db::guess_os_from_media
On Mon, Dec 3, 2012 at 5:55 PM, Zeeshan Ali (Khattak) zeesha...@gnome.org wrote: On Mon, Dec 3, 2012 at 1:23 PM, Christophe Fergeau cferg...@redhat.com wrote: --- One of the main reasons for deprecating _guess_os_from_media function and introducing new API was to avoid this change. Ah, NM. I now see that next patch fixes this. :) -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 7/8] rfc: Infer ISO language from label
On Mon, Dec 3, 2012 at 1:23 PM, Christophe Fergeau cferg...@redhat.com wrote:
Now that libosinfo has an osinfo_db_identify_media method which
modifies the media it was passed, we can generate properties which
needs information from the media stored in the OsinfoDB, and
information from the actual media (ISO volume ID).
This is useful to guess what languages are supported by a given
Windows ISO: the end of the ISO volume ID has a language code, which
we can translate to a locale identifier.
This commit adds a lang-regex property to the OsinfoDB database to
extract the language code from Windows ISO volume IDs, and
then add mapping tables to turn it into a locale identifier.
---
data/oses/windows.xml.in | 2 +
data/schemas/libosinfo.rng | 5 ++
osinfo/libosinfo.syms | 4 +-
osinfo/osinfo_db.c | 177
+
osinfo/osinfo_loader.c | 4 +-
osinfo/osinfo_media.c | 67 -
osinfo/osinfo_media.h | 3 +
7 files changed, 258 insertions(+), 4 deletions(-)
diff --git a/data/oses/windows.xml.in b/data/oses/windows.xml.in
index d09e873..e8c29f9 100644
--- a/data/oses/windows.xml.in
+++ b/data/oses/windows.xml.in
@@ -739,12 +739,14 @@
iso
volume-id(HB1_CCPA_X86FRE|HRM_CCSA_X86FRE|HRM_CCSA_X86CHK|HRM_CCSNA_X86CHK|HRM_CCSNA_X86FRE|HRM_CENA_X86FREV|HRM_CENA_X86CHKV|HRM_CENNA_X86FREV|HRM_CENNA_X86CHKV|HRM_CPRA_X86FREV|HRM_CPRNA_X86FREV)_/volume-id
publisher-idMICROSOFT CORPORATION/publisher-id
+
lang-regex[[:upper:][:digit:]_]*_([[:upper:]]*-[[:upper:]]*)/lang-regex
/iso
/media
media arch=x86_64
iso
volume-id(HB1_CCPA_X64FRE|HRM_CCSA_X64FRE|HRM_CCSA_X64CHK|HRM_CCSNA_X64FRE|HRM_CCSNA_X64CHK|HRM_CENNA_X64FREV|HRM_CENNA_X64CHKV|HRM_CENA_X64FREV|HRM_CENA_X64CHKV|HRM_CPRA_X64FREV|HRM_CPRNA_X64FREV)_/volume-id
publisher-idMICROSOFT CORPORATION/publisher-id
+
lang-regex[[:upper:][:digit:]_]*_([[:upper:]]*-[[:upper:]]*)/lang-regex
/iso
/media
diff --git a/data/schemas/libosinfo.rng b/data/schemas/libosinfo.rng
index 87635dd..36fa1a1 100644
--- a/data/schemas/libosinfo.rng
+++ b/data/schemas/libosinfo.rng
@@ -281,6 +281,11 @@
text/
/element
/optional
+optional
+ element name='lang-regex'
+text/
+ /element
+/optional
/interleave
/element
/define
diff --git a/osinfo/libosinfo.syms b/osinfo/libosinfo.syms
index d45e58e..7c3efe1 100644
--- a/osinfo/libosinfo.syms
+++ b/osinfo/libosinfo.syms
@@ -341,11 +341,11 @@ LIBOSINFO_0.2.2 {
osinfo_install_config_set_target_disk;
osinfo_install_config_get_script_disk;
osinfo_install_config_set_script_disk;
-
osinfo_install_script_get_avatar_format;
osinfo_install_script_get_path_format;
-
osinfo_install_script_get_product_key_format;
+
+ osinfo_media_get_languages;
} LIBOSINFO_0.2.1;
/* Symbols in next release...
diff --git a/osinfo/osinfo_db.c b/osinfo/osinfo_db.c
index 46101d6..2c2eb5a 100644
--- a/osinfo/osinfo_db.c
+++ b/osinfo/osinfo_db.c
@@ -38,6 +38,177 @@ G_DEFINE_TYPE (OsinfoDb, osinfo_db, G_TYPE_OBJECT);
(((str) != NULL) \
g_regex_match_simple((pattern), (str), 0, 0)))
+static gchar *get_raw_lang(const char *volume_id, const gchar *regex_str)
+{
+GRegex *regex;
+GMatchInfo *match;
+gboolean matched;
+gchar *raw_lang = NULL;
+
+regex = g_regex_new(regex_str, G_REGEX_ANCHORED,
+G_REGEX_MATCH_ANCHORED, NULL);
+if (regex == NULL)
+return NULL;
+
+matched = g_regex_match(regex, volume_id, G_REGEX_MATCH_ANCHORED,
match);
+if (!matched || !g_match_info_matches(match))
+goto end;
+raw_lang = g_match_info_fetch(match, 1);
+if (raw_lang == NULL)
+goto end;
+
+end:
+g_match_info_unref(match);
+g_regex_unref(regex);
+
+return raw_lang;
+}
+
+struct LanguageMapping {
+const char *iso_label_lang;
+const char *gettext_lang;
+};
+
+static GHashTable *init_win_lang_map(void)
+{
+GHashTable *lang_map;
+const struct LanguageMapping lang_table[] = {
+/* ISO label strings up to Windows 7 */
+{ EN, en_US },
I agree with you that it would be nice to avoid this mapping all
together but if its not possible/feasible, these mappings should be in
the XML like rest of OS specific stuff. Then again, if we go that
route, I wonder if all this approach is really better than having
separate media entries for each combination of supported languages.
--
Regards,
Zeeshan Ali (Khattak)
FSF member#5124
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] [libosinfo 1/2] install-config: Document expected kbd layout format
From: Zeeshan Ali (Khattak) zeesha...@gnome.org
---
osinfo/osinfo_install_config.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/osinfo/osinfo_install_config.c b/osinfo/osinfo_install_config.c
index adbf9df..6ba9c08 100644
--- a/osinfo/osinfo_install_config.c
+++ b/osinfo/osinfo_install_config.c
@@ -124,7 +124,14 @@ const gchar
*osinfo_install_config_get_hardware_arch(OsinfoInstallConfig *config
OSINFO_INSTALL_CONFIG_PROP_HARDWARE_ARCH);
}
-
+/**
+ * osinfo_install_config_set_l10n_keyboard:
+ *
+ * Sets the #OSINFO_INSTALL_CONFIG_PROP_L10N_KEYBOARD parameter.
+ *
+ * The expected format of this string is the same as
+ * #osinfo_install_config_set_l10n_language function's 'language' parameter.
+ */
void osinfo_install_config_set_l10n_keyboard(OsinfoInstallConfig *config,
const gchar *keyboard)
{
@@ -133,7 +140,6 @@ void
osinfo_install_config_set_l10n_keyboard(OsinfoInstallConfig *config,
keyboard);
}
-
const gchar *osinfo_install_config_get_l10n_keyboard(OsinfoInstallConfig
*config)
{
return osinfo_entity_get_param_value(OSINFO_ENTITY(config),
--
1.8.0.1
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] [libosinfo] Sort out keyboard layout config setting
Based on my discussion with Christophe here and on IRC, I changed the whole approach in these patches: We now expect apps to provide locale (same format as 'l10-language' config) instead of X layout. We then infer layout from that in the script template XML (currently only Fedora makes use of it). ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo] More Windows 8 coverage
On Sat, Dec 1, 2012 at 7:56 PM, Christophe Fergeau cferg...@redhat.com wrote: This covers the whole range of English Windows 8 ISOs available on MSDN. Hopefully this will extend to non-English win8 ISOs on MSDN, and to all non-MSDN win8 releases as well. Looks good. ACK! -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 1/2] install-config: Document expected kbd layout format
On Fri, Nov 30, 2012 at 11:37 AM, Christophe Fergeau cferg...@redhat.com wrote: On Fri, Nov 30, 2012 at 03:00:47AM +0200, Zeeshan Ali (Khattak) wrote: From: Zeeshan Ali (Khattak) zeesha...@gnome.org --- osinfo/osinfo_install_config.c | 14 +- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/osinfo/osinfo_install_config.c b/osinfo/osinfo_install_config.c index adbf9df..e7a8946 100644 --- a/osinfo/osinfo_install_config.c +++ b/osinfo/osinfo_install_config.c @@ -124,7 +124,19 @@ const gchar *osinfo_install_config_get_hardware_arch(OsinfoInstallConfig *config OSINFO_INSTALL_CONFIG_PROP_HARDWARE_ARCH); } - +/** + * osinfo_install_config_set_l10n_keyboard: + * + * Sets the #OSINFO_INSTALL_CONFIG_PROP_L10N_KEYBOARD parameter. + * + * The expected format of this string is an X Window System keyboard layout + * specifier: + * + * http://www.freedesktop.org/wiki/Software/XKeyboardConfig + * http://fedoraproject.org/wiki/Anaconda/Kickstart#keyboard None of these links are really helpful to figure out what the format looks like. Thats the best I could find. If you could help me find better references, I'll be grateful. This API seems to be very fedora-specific, The format is more like Linux specific but yeah, currently we only need this for Fedora and 'keyboard' command is required in the kickstart. the way it works on win7 is described there: http://technet.microsoft.com/fr-fr/library/cc749191%28v=ws.10%29.aspx though I did not quite get the format of keyboard layouts void osinfo_install_config_set_l10n_keyboard(OsinfoInstallConfig *config, const gchar *locale, const gchar *keyboard_layout); will probably be more flexible. 'locale' would be in the same 'gettext' format as in other places. Not sure at all what the format of keyboard_layout should be, just that it can be NULL to use the default keyboard layout (which is what we'll want most of the time). IMO for now we shouldn't set the keyboard layout for windows since its autodeteced (right?) from the language params that we do set. We also have the API for apps to know if a param is used by a script or not and if it is used, if its mandatory. If we decide to do so in future, we could either figure a way to translate from X layouts to locale names or add new param/API to set/get locale and declare in windows scripts that they make use of this param. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 1/2] install-config: Document expected kbd layout format
On Fri, Nov 30, 2012 at 5:03 PM, Christophe Fergeau cferg...@redhat.com wrote: On Fri, Nov 30, 2012 at 04:30:16PM +0200, Zeeshan Ali (Khattak) wrote: On Fri, Nov 30, 2012 at 11:37 AM, Christophe Fergeau cferg...@redhat.com wrote: This API seems to be very fedora-specific, The format is more like Linux specific but yeah, currently we only need this for Fedora and 'keyboard' command is required in the kickstart. Ubuntu (and Debian as well I guess) uses a similar but different format, 'layout_variant' as opposed to the 'layout (variant)' that you suggest using in the public API. We can easily translate it to their format then? XkbLayout seems to be quite close to a country code, so is easy to get from a 'gettext' format. I don't know if i got this. You mean we can guess/derive layout from l10-language param? the way it works on win7 is described there: http://technet.microsoft.com/fr-fr/library/cc749191%28v=ws.10%29.aspx though I did not quite get the format of keyboard layouts void osinfo_install_config_set_l10n_keyboard(OsinfoInstallConfig *config, const gchar *locale, const gchar *keyboard_layout); will probably be more flexible. 'locale' would be in the same 'gettext' format as in other places. Not sure at all what the format of keyboard_layout should be, just that it can be NULL to use the default keyboard layout (which is what we'll want most of the time). IMO for now we shouldn't set the keyboard layout for windows since its autodeteced (right?) from the language params that we do set. We also have the API for apps to know if a param is used by a script or not and if it is used, if its mandatory. If we decide to do so in future, we could either figure a way to translate from X layouts to locale names or add new param/API to set/get locale and declare in windows scripts that they make use of this param. After looking at how Ubuntu does things, having 2 arguments seems it will make things less convoluted... while breaking API. From what you said above, I don't see how we cant easily use the same API for Ubuntu/Debian. And I'd prefer if we spent a bit of time trying to get the API right now. The API is already there, I'm just trying to decide/fix a format for the argument/param involved. I'm afraid you have missed the best opportunity for discussing these APIs in detail: when they were proposed by Daniel for the first time many months ago. This API is also missing a way to handle multiple layouts, which at least Windows and Fedora support, I don't know if this is on purpose? Thats something Daniel can answer with certainty but: a. That should be easy to add support for without breaking API/ABI (e.g allow comma separated list of layouts as the param) later. b. I don't think its very important to allow that so I'll rather leave that out for now. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] [libosinfo 1/2] install-config: Document expected kbd layout format
From: Zeeshan Ali (Khattak) zeesha...@gnome.org
---
osinfo/osinfo_install_config.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/osinfo/osinfo_install_config.c b/osinfo/osinfo_install_config.c
index adbf9df..e7a8946 100644
--- a/osinfo/osinfo_install_config.c
+++ b/osinfo/osinfo_install_config.c
@@ -124,7 +124,19 @@ const gchar
*osinfo_install_config_get_hardware_arch(OsinfoInstallConfig *config
OSINFO_INSTALL_CONFIG_PROP_HARDWARE_ARCH);
}
-
+/**
+ * osinfo_install_config_set_l10n_keyboard:
+ *
+ * Sets the #OSINFO_INSTALL_CONFIG_PROP_L10N_KEYBOARD parameter.
+ *
+ * The expected format of this string is an X Window System keyboard layout
+ * specifier:
+ *
+ * http://www.freedesktop.org/wiki/Software/XKeyboardConfig
+ * http://fedoraproject.org/wiki/Anaconda/Kickstart#keyboard
+ *
+ * Examples: 'am (eastern-alt)', 'am', 'us', 'fi (classic)' etc.
+ */
void osinfo_install_config_set_l10n_keyboard(OsinfoInstallConfig *config,
const gchar *keyboard)
{
--
1.8.0
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] [libosinfo 2/2] fedora, installer: Set keyboard config for = F18
From: Zeeshan Ali (Khattak) zeesha...@gnome.org Now that we have established what kind of string to expect in 'l10n-keyboard' config, lets correctly set this for F18 and higher. For F17 and older, we hardcode the layout to 'us'. Those require layout to be a console layout so we'll need some complicated XSL magic to translate from X to console layout if we want to properly support those. --- data/install-scripts/fedora.xml | 30 -- 1 file changed, 28 insertions(+), 2 deletions(-) diff --git a/data/install-scripts/fedora.xml b/data/install-scripts/fedora.xml index e76f5dd..2d1c961 100644 --- a/data/install-scripts/fedora.xml +++ b/data/install-scripts/fedora.xml @@ -59,11 +59,24 @@ /xsl:choose /xsl:template + xsl:template name=keyboard + xsl:choose + xsl:when test=os/version gt; 17 + xsl:value-of select=config/l10n-keyboard/ + /xsl:when + xsl:otherwise + !-- F17 and older required keyboard layout to be a console layout so we'll need some complicated + code to translate from X to console layout if we want to properly support those. -- + xsl:textus/xsl:text + /xsl:otherwise + /xsl:choose + /xsl:template + xsl:template match=/install-script-config # Install script for xsl:value-of select=os/short-id/ profile xsl:value-of select=script/profile/ install text -keyboard xsl:value-of select=config/l10n-keyboard/ +keyboard 'xsl:call-template name=keyboard/' lang xsl:value-of select=config/l10n-language/ xsl:if test=os/version lt; 7 langsupport --default xsl:value-of select=config/l10n-language/ xsl:value-of select=config/l10n-language/ @@ -181,10 +194,23 @@ reboot /xsl:choose /xsl:template + xsl:template name=keyboard + xsl:choose + xsl:when test=os/version gt; 17 + xsl:value-of select=config/l10n-keyboard/ + /xsl:when + xsl:otherwise + !-- F17 and older required keyboard layout to be a console layout so we'll need some complicated + code to translate from X to console layout if we want to properly support those. -- + xsl:textus/xsl:text + /xsl:otherwise + /xsl:choose + /xsl:template + xsl:template match=/install-script-config # Install script for xsl:value-of select=os/short-id/ profile xsl:value-of select=script/profile/ install -keyboard xsl:value-of select=config/l10n-keyboard/ +keyboard 'xsl:call-template name=keyboard/' lang xsl:value-of select=config/l10n-language/ network --onboot yes --device eth0 --bootproto dhcp --noipv6 --hostname=xsl:value-of select=config/hostname/ --activate rootpw dummyPa55w0rd # Actual password set (or unset) in %post below -- 1.8.0 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] [libosinfo] Export osinfo_install_script_get_product_key_format
Already pushed under trivial rule. ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] [libosinfo] Export osinfo_install_script_get_product_key_format
From: Zeeshan Ali (Khattak) zeesha...@gnome.org
This function was never added to libosinfo.syms and hence not exported
in the so files.
---
osinfo/libosinfo.syms | 2 ++
1 file changed, 2 insertions(+)
diff --git a/osinfo/libosinfo.syms b/osinfo/libosinfo.syms
index a79425a..2824678 100644
--- a/osinfo/libosinfo.syms
+++ b/osinfo/libosinfo.syms
@@ -342,6 +342,8 @@ LIBOSINFO_0.2.2 {
osinfo_install_script_get_avatar_format;
osinfo_install_script_get_path_format;
+
+ osinfo_install_script_get_product_key_format;
} LIBOSINFO_0.2.1;
/* Symbols in next release...
--
1.8.0
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 3/5] Fix OsinfoMedia::installer-reboots default value
On Wed, Nov 28, 2012 at 10:58 AM, Christophe Fergeau cferg...@redhat.com wrote: On Wed, Nov 28, 2012 at 01:29:54AM +0200, Zeeshan Ali (Khattak) wrote: On Wed, Nov 28, 2012 at 12:39 AM, Christophe Fergeau cferg...@redhat.com wrote: In other words, am I introducing a regression, Well its not really causing a regression but its not fixing anything either. Definitely not, it just makes the code more consistent (same value for the gobject default property value and in the osinfo_entity_get_value_with_default). Not sure how can still state this as a fact while I already told you how its not. Do you want me to change something in this patch or drop it? As I said, this change is not needed so the latter. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 2/4] Add RHEL 5.5 media information
On Wed, Nov 28, 2012 at 2:23 PM, Christophe Fergeau cferg...@redhat.com wrote: --- data/oses/rhel.xml.in | 13 ++ .../rhel5.5/rhel-server-5.5-x86_64-dvd.iso.txt | 29 ++ 2 files changed, 42 insertions(+) create mode 100644 test/isodata/rhel/rhel5.5/rhel-server-5.5-x86_64-dvd.iso.txt diff --git a/data/oses/rhel.xml.in b/data/oses/rhel.xml.in index 0d2a057..3f3b601 100644 --- a/data/oses/rhel.xml.in +++ b/data/oses/rhel.xml.in @@ -554,6 +554,19 @@ release-date2010-03-30/release-date eol-date2020-03-31/eol-date + +media arch=i386 + iso +system-idLINUX/system-id +volume-id.*RHEL/5.5 i386.*/volume-id I think the '.*' at beginning and end are redundant. ACK with or without removing those. ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] [libosinfo] fedora, installer: Fix against Fedora 18
From: Zeeshan Ali (Khattak) zeesha...@gnome.org 'base' package group has been replaced by 'standard'. For jeos profile, we now use the right name of the group depending on the OS version. For desktop profile, we can simply drop this group from the list as its pulled-in by other groups anyways. --- data/install-scripts/fedora.xml | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/data/install-scripts/fedora.xml b/data/install-scripts/fedora.xml index fcb1143..e76f5dd 100644 --- a/data/install-scripts/fedora.xml +++ b/data/install-scripts/fedora.xml @@ -94,7 +94,14 @@ logvol / --fstype xsl:call-template name=rootfs/ --name=LogVol00 --vgname=Vo reboot %packages +xsl:choose + xsl:when test=os/version lt; 18 @base + /xsl:when + xsl:otherwise +@standard + /xsl:otherwise +/xsl:choose @core xsl:if test=os/version gt; 6 @hardware-support @@ -200,7 +207,6 @@ logvol / --fstype xsl:call-template name=rootfs/ --name=LogVol00 --vgname=Vo reboot %packages -@base @core @hardware-support @base-x -- 1.8.0 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo] Add test case for handling int in entities
On Wed, Nov 28, 2012 at 4:58 PM, Christophe Fergeau cferg...@redhat.com wrote: This test case would have caught the bug fixed by 14defe8e and 4e86e2bf ACK! -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo] Remove duplicate EXTRA_DIST definition
On Wed, Nov 28, 2012 at 5:03 PM, Christophe Fergeau cferg...@redhat.com wrote: --- ACK -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo] fedora, installer: Fix against Fedora 18
On Thu, Nov 29, 2012 at 3:54 AM, Fabiano Fidêncio fabi...@fidencio.org wrote: On Wed, Nov 28, 2012 at 1:47 PM, Fabiano Fidêncio fabi...@fidencio.org wrote: On Wed, Nov 28, 2012 at 1:44 PM, Zeeshan Ali (Khattak) zeesha...@gnome.org wrote: From: Zeeshan Ali (Khattak) zeesha...@gnome.org 'base' package group has been replaced by 'standard'. For jeos profile, we now use the right name of the group depending on the OS version. For desktop profile, we can simply drop this group from the list as its pulled-in by other groups anyways. --- data/install-scripts/fedora.xml | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/data/install-scripts/fedora.xml b/data/install-scripts/fedora.xml index fcb1143..e76f5dd 100644 --- a/data/install-scripts/fedora.xml +++ b/data/install-scripts/fedora.xml @@ -94,7 +94,14 @@ logvol / --fstype xsl:call-template name=rootfs/ --name=LogVol00 --vgname=Vo reboot %packages +xsl:choose + xsl:when test=os/version lt; 18 @base + /xsl:when + xsl:otherwise +@standard + /xsl:otherwise +/xsl:choose @core xsl:if test=os/version gt; 6 @hardware-support @@ -200,7 +207,6 @@ logvol / --fstype xsl:call-template name=rootfs/ --name=LogVol00 --vgname=Vo reboot %packages -@base @core @hardware-support @base-x -- 1.8.0 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list ACK Since I ACK'ed it is my fault. Zeeshan, your modification only affects jeos profiles. Could you cp the code also for desktop profiles? Its also covered. Read the commit log and don't miss this change :) %packages -@base @core @hardware-support @base-x -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo] Another couple of Windows DVD labels
On Tue, Nov 27, 2012 at 10:41 AM, Richard W.M. Jones rjo...@redhat.com wrote: See below. Another issue: I notice that two volume IDs in the current Windows database end in '..._EN'. I believe this indicates that the language on the disk is English so you should remove this suffix. Thanks for point this out. Yeah, I think it makes sense to remove those suffices. Christophe is working on adding language detection and AFAICT his work will also fix this as a side-effect. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] [libosinfo 2/2] win8: Add one more volume ID pattern
From: Zeeshan Ali (Khattak) zeesha...@gnome.org --- data/oses/windows.xml.in | 2 +- .../en_windows_8_enterprise_x86_dvd_917587.iso.txt | 29 ++ 2 files changed, 30 insertions(+), 1 deletion(-) create mode 100644 test/isodata/windows/win8/en_windows_8_enterprise_x86_dvd_917587.iso.txt diff --git a/data/oses/windows.xml.in b/data/oses/windows.xml.in index 2a58d8d..851c1b7 100644 --- a/data/oses/windows.xml.in +++ b/data/oses/windows.xml.in @@ -737,7 +737,7 @@ media arch=i386 iso -volume-idHB1_CCPA_X86FRE/volume-id +volume-id(HB1_CCPA_X86FRE)|(HRM_CENA_X86)/volume-id publisher-idMICROSOFT CORPORATION/publisher-id /iso /media diff --git a/test/isodata/windows/win8/en_windows_8_enterprise_x86_dvd_917587.iso.txt b/test/isodata/windows/win8/en_windows_8_enterprise_x86_dvd_917587.iso.txt new file mode 100644 index 000..1d797ae --- /dev/null +++ b/test/isodata/windows/win8/en_windows_8_enterprise_x86_dvd_917587.iso.txt @@ -0,0 +1,29 @@ +CD-ROM is in ISO 9660 format +System id: +Volume id: HRM_CENA_X86FREV_EN-US_DV5 +Volume set id: HRM_CENA_X86FREV_EN-US_DV5 +Publisher id: MICROSOFT CORPORATION +Data preparer id: MICROSOFT CORPORATION, ONE MICROSOFT WAY, REDMOND WA 98052, (425) 882-8080 +Application id: CDIMAGE 2.53 (01/01/2005 TM) +Copyright File id: +Abstract File id: +Bibliographic File id: +Volume set size is: 1 +Volume set sequence number is: 1 +Logical block size is: 2048 +Volume size is: 1245681 +El Torito VD version 1 found, boot catalog is in sector 22 +NO Joliet present +NO Rock Ridge present +Eltorito validation header: +Hid 1 +Arch 0 (x86) +ID 'Microsoft Corporation' +Key 55 AA +Eltorito defaultboot header: +Bootid 88 (bootable) +Boot media 0 (No Emulation Boot) +Load segment 0 +Sys type 0 +Nsect 8 +Bootoff 5B8 1464 -- 1.8.0 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] [libosinfo 2/2] install-config: Document format of 'l10n-language'
From: Zeeshan Ali (Khattak) zeesha...@gnome.org
Co-author reviewer: Zeeshan Ali (Khattak) zeesha...@gnome.org
---
osinfo/osinfo_install_config.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/osinfo/osinfo_install_config.c b/osinfo/osinfo_install_config.c
index a2ee496..adbf9df 100644
--- a/osinfo/osinfo_install_config.c
+++ b/osinfo/osinfo_install_config.c
@@ -140,7 +140,18 @@ const gchar
*osinfo_install_config_get_l10n_keyboard(OsinfoInstallConfig *config
OSINFO_INSTALL_CONFIG_PROP_L10N_KEYBOARD);
}
-
+/**
+ * osinfo_install_config_set_l10n_language:
+ *
+ * Sets the #OSINFO_INSTALL_CONFIG_PROP_L10N_LANGUAGE parameter.
+ *
+ * The expected format of this string is the gettext locale names standard:
+ *
+ *
https://www.gnu.org/savannah-checkouts/gnu/gettext/manual/html_node/Locale-Names.html
+ *
+ * Both encoding and variant are accepted but optional. For example, both
'pt_BR'
+ * and 'pt_BR.utf8' are accepted as the language codes for Brazilian
Portuguese.
+ */
void osinfo_install_config_set_l10n_language(OsinfoInstallConfig *config,
const gchar *language)
{
--
1.8.0
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] [libosinfo 1/2] win7, installer: Translate l10n-language configuration
From: Fabiano Fidêncio fabi...@fidencio.org The expected format of l10n_language string is the gettext locale names standard: https://www.gnu.org/savannah-checkouts/gnu/gettext/manual/html_node/Locale-Names.html, While Windows expect this to be in *the* standard format: http://www.ietf.org/rfc/rfc4646.txt So we need to translate the language code for windows. Co-author reviewer: Zeeshan Ali (Khattak) zeesha...@gnome.org --- data/install-scripts/windows-unattend.xml | 50 ++- 1 file changed, 42 insertions(+), 8 deletions(-) diff --git a/data/install-scripts/windows-unattend.xml b/data/install-scripts/windows-unattend.xml index d3b2df5..0901e5b 100644 --- a/data/install-scripts/windows-unattend.xml +++ b/data/install-scripts/windows-unattend.xml @@ -32,6 +32,23 @@ /xsl:choose /xsl:template +xsl:template name=language + xsl:variable name=language +xsl:value-of select=config/l10n-language/ + /xsl:variable + xsl:variable name=formatted-language +xsl:value-of select=translate($language,'_','-')/ + /xsl:variable + xsl:choose +xsl:when test=contains($formatted-language,'.') + xsl:value-of select=substring-before($formatted-language,'.')/ +/xsl:when +xsl:otherwise + xsl:value-of select=$formatted-language/ +/xsl:otherwise + /xsl:choose +/xsl:template + xsl:template name=arch xsl:choose xsl:when test=count(config/hardware-arch) gt; 0 @@ -99,11 +116,11 @@ xsl:call-template name=arch/ /xsl:attribute SetupUILanguage - UILanguagexsl:value-of select=config/l10n-language//UILanguage + UILanguagexsl:call-template name=language//UILanguage /SetupUILanguage - SystemLocalexsl:value-of select=config/l10n-language//SystemLocale - UILanguagexsl:value-of select=config/l10n-language//UILanguage - UserLocalexsl:value-of select=config/l10n-language//UserLocale + SystemLocalexsl:call-template name=language//SystemLocale + UILanguagexsl:call-template name=language//UILanguage + UserLocalexsl:call-template name=language//UserLocale /component /settings settings pass=oobeSystem @@ -213,6 +230,23 @@ /xsl:choose /xsl:template + xsl:template name=language +xsl:variable name=language + xsl:value-of select=config/l10n-language/ +/xsl:variable +xsl:variable name=formatted-language + xsl:value-of select=translate($language,'_','-')/ +/xsl:variable +xsl:choose + xsl:when test=contains($formatted-language,'.') +xsl:value-of select=substring-before($formatted-language,'.')/ + /xsl:when + xsl:otherwise +xsl:value-of select=$formatted-language/ + /xsl:otherwise +/xsl:choose + /xsl:template + xsl:template name=arch xsl:choose xsl:when test=config/hardware-arch = 'x86_64' @@ -283,11 +317,11 @@ xsl:call-template name=arch/ /xsl:attribute SetupUILanguage - UILanguagexsl:value-of select=config/l10n-language//UILanguage + UILanguagexsl:call-template name=language//UILanguage /SetupUILanguage - SystemLocalexsl:value-of select=config/l10n-language//SystemLocale - UILanguagexsl:value-of select=config/l10n-language//UILanguage - UserLocalexsl:value-of select=config/l10n-language//UserLocale + SystemLocalexsl:call-template name=language//SystemLocale + UILanguagexsl:call-template name=language//UILanguage + UserLocalexsl:call-template name=language//UserLocale /component /settings xsl:if test=os/version gt; 6.0 -- 1.8.0 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 3/5] Fix OsinfoMedia::installer-reboots default value
On Tue, Nov 27, 2012 at 7:50 PM, Christophe Fergeau cferg...@redhat.com wrote: By default, we want to report 1 reboot during installation, not -1. That depends on the media. We want to return '1' for media that has an installer and '-1' for others (so apps can differentiate). I think we don't want to have this prop as _CONSTRUCT in the first place as we don't pass the value to the constructor. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 4/5] media: Don't mark properties as _CONSTRUCT
On Tue, Nov 27, 2012 at 7:50 PM, Christophe Fergeau cferg...@redhat.com wrote: Marking them as _CONSTRUCT will cause the property setter to be called at object construction time to set the property default value. For the properties of OsinfoMedia, this causes the default value to be stored in the entity store as the property setters call osinfo_entity_set_param. Since I already said we want this in review to another patch, I'm obviously in favor of this change. :) ACK! -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo 3/5] Fix OsinfoMedia::installer-reboots default value
On Wed, Nov 28, 2012 at 12:39 AM, Christophe Fergeau cferg...@redhat.com wrote: On Tue, Nov 27, 2012 at 10:03:18PM +0200, Zeeshan Ali (Khattak) wrote: On Tue, Nov 27, 2012 at 7:50 PM, Christophe Fergeau cferg...@redhat.com wrote: By default, we want to report 1 reboot during installation, not -1. That depends on the media. We want to return '1' for media that has an installer and '-1' for others (so apps can differentiate). The current code is not (trying to) do that at all, is it? It *is* doing that in the getter function. Combined with your other patch in this series that removes the _CONSTRUCT flag fixes the issue already AFAICT. In other words, am I introducing a regression, Well its not really causing a regression but its not fixing anything either. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo] win7: Add one more volume ID to DB
On Mon, Nov 26, 2012 at 11:42 AM, Christophe Fergeau cferg...@redhat.com wrote: On Mon, Nov 26, 2012 at 05:49:17AM +0200, Zeeshan Ali (Khattak) wrote: From: Zeeshan Ali (Khattak) zeesha...@gnome.org --- data/oses/windows.xml.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/data/oses/windows.xml.in b/data/oses/windows.xml.in index 8ba9e8d..f968565 100644 --- a/data/oses/windows.xml.in +++ b/data/oses/windows.xml.in @@ -680,7 +680,7 @@ /media media arch=x86_64 installer-reboots=2 iso - volume-id(GRMCULXFRER|GSP1RMCPRXFRER|GSP1RMCNHPXFRER|GSP1RMCENXVOL|GRMCENXVOL|GRMCNENXVOL|GRMCPRXFRER|GSP1RMCPRXVOL)_/volume-id + volume-id(GRMCULXFRER|GSP1RMCPRXFRER|GSP1RMCNHPXFRER|GRMCHPXFRER|GSP1RMCENXVOL|GRMCENXVOL|GRMCNENXVOL|GRMCPRXFRER|GSP1RMCPRXVOL)_/volume-id It never hurts to add new volume IDs to the test suite as well. I would have if i could have. :) I got this information from here: https://plus.google.com/101573170439007021210/posts/SiQwAqVqjDp . I already had asked that guy to try out many things and then to try this patch so I didn't feel like asking him for more. Feel free to ask him. :) -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] [libosinfo 1/2] xp: Bump recommended RAM and storage
From: Zeeshan Ali (Khattak) zeesha...@gnome.org A RAM of 128 MiB and storage of 2 GiB might have been adequate in the days when XP came out but now a days its not a lot at all. So lets recommend at least 512 MiB RAM and 10 GiB storage. --- data/oses/windows.xml.in | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/data/oses/windows.xml.in b/data/oses/windows.xml.in index f968565..879ead3 100644 --- a/data/oses/windows.xml.in +++ b/data/oses/windows.xml.in @@ -352,10 +352,11 @@ recommended cpu3/cpu -ram134217728/ram -storage2147483648/storage +ram536870912/ram +storage10737418240/storage /recommended /resources + resources arch=x86_64 minimum cpu73300/cpu -- 1.8.0 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] [libosinfo] win7: Add one more volume ID to DB
From: Zeeshan Ali (Khattak) zeesha...@gnome.org --- data/oses/windows.xml.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/data/oses/windows.xml.in b/data/oses/windows.xml.in index 8ba9e8d..f968565 100644 --- a/data/oses/windows.xml.in +++ b/data/oses/windows.xml.in @@ -680,7 +680,7 @@ /media media arch=x86_64 installer-reboots=2 iso - volume-id(GRMCULXFRER|GSP1RMCPRXFRER|GSP1RMCNHPXFRER|GSP1RMCENXVOL|GRMCENXVOL|GRMCNENXVOL|GRMCPRXFRER|GSP1RMCPRXVOL)_/volume-id + volume-id(GRMCULXFRER|GSP1RMCPRXFRER|GSP1RMCNHPXFRER|GRMCHPXFRER|GSP1RMCENXVOL|GRMCENXVOL|GRMCNENXVOL|GRMCPRXFRER|GSP1RMCPRXVOL)_/volume-id publisher-idMICROSOFT CORPORATION/publisher-id /iso /media -- 1.8.0 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo v4] API to query required user avatar format
On Fri, Nov 23, 2012 at 9:59 AM, Christophe Fergeau cferg...@redhat.com wrote: On Fri, Nov 23, 2012 at 05:26:19AM +0200, Zeeshan Ali (Khattak) wrote: @@ -157,6 +165,8 @@ osinfo_install_script_finalize (GObject *object) g_free(script-priv-output_prefix); g_free(script-priv-output_filename); g_list_free_full(script-priv-config_param_list, g_object_unref); +if (script-priv-avatar != NULL) +g_object_unref(script-priv-avatar); I've heard a few times that g_*_free should be done in _finalize while g_object_unref should be called from _dispose. I don't know how important this is (ie we can probably live with this _unref in _finalize). Moreover this pattern is all over in libosinfo so I always think maybe its better to be consistent about this. If it turns out to be an issue, we can move all these unrefs into _dispose at the same time. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo v4] install-scripts: Translate lang format when needed
but are optional. + * + * For example, 'pt_BR' is used to Brazilian Portuguese. 'pt_BR.utf8' is + * accepted but the encoding part is optional. + * + * [0]: https://www.gnu.org/savannah-checkouts/gnu/gettext/manual/html_node/Locale-Names.html This will not translate into footnote (as its meant to be) in the generated docs. See if there is any way to create links in gtk-doc. If not, you want to inline it. Looks good otherwise. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [libosinfo v3] API to query required user avatar format
On Thu, Nov 22, 2012 at 11:26 AM, Christophe Fergeau
cferg...@redhat.com wrote:
On Wed, Nov 21, 2012 at 07:39:05PM +0200, Zeeshan Ali (Khattak) wrote:
From: Zeeshan Ali (Khattak) zeesha...@gnome.org
Add a new API for apps to be able to query in which format do the user
avatar file need to be in.
Based on a patch from Fabiano Fidêncio fabi...@fidencio.org.
---
data/install-scripts/fedora.xml | 3 +
data/install-scripts/windows-cmd.xml | 6 +
data/schemas/libosinfo.rng | 30 +
osinfo/Makefile.am | 2 +
osinfo/libosinfo.syms| 8 +-
osinfo/osinfo.h | 1 +
osinfo/osinfo_avatar_format.c| 242
+++
osinfo/osinfo_avatar_format.h| 95 ++
osinfo/osinfo_install_script.c | 51
osinfo/osinfo_install_script.h | 6 +
osinfo/osinfo_loader.c | 44 +++
po/POTFILES.in | 1 +
12 files changed, 488 insertions(+), 1 deletion(-)
create mode 100644 osinfo/osinfo_avatar_format.c
create mode 100644 osinfo/osinfo_avatar_format.h
diff --git a/data/install-scripts/fedora.xml
b/data/install-scripts/fedora.xml
index dc767d5..fcb1143 100644
--- a/data/install-scripts/fedora.xml
+++ b/data/install-scripts/fedora.xml
@@ -122,6 +122,9 @@ reboot
param name=avatar-disk policy=optional/
param name=target-disk policy=optional/
/config
+avatar-format
+ mime-typeimage/png/mime-type
+/avatar-format
template
xsl:stylesheet
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
diff --git a/data/install-scripts/windows-cmd.xml
b/data/install-scripts/windows-cmd.xml
index 020a493..84833a9 100644
--- a/data/install-scripts/windows-cmd.xml
+++ b/data/install-scripts/windows-cmd.xml
@@ -12,6 +12,12 @@
param name=target-disk policy=optional/
param name=script-disk policy=optional/
/config
+avatar-format
+ mime-typeimage/bmp/mime-type
+ width48/width
+ height48/height
+ alphafalse/alpha
+/avatar-format
template
xsl:stylesheet
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
diff --git a/data/schemas/libosinfo.rng b/data/schemas/libosinfo.rng
index 3c57c36..87635dd 100644
--- a/data/schemas/libosinfo.rng
+++ b/data/schemas/libosinfo.rng
@@ -478,6 +478,9 @@
/element
/optional
optional
+ ref name='avatar-format'/
+/optional
+optional
element name='config'
oneOrMore
element name='param'
@@ -509,6 +512,33 @@
/element
/define
+ define name='avatar-format'
+element name='avatar-format'
+ interleave
+oneOrMore
+ element name=mime-type
+text/
+ /element
+/oneOrMore
+optional
+ element name=width
+ref name='num'/
+ /element
+/optional
+optional
+ element name=height
+ref name='num'/
+ /element
+/optional
+optional
+ element name=alpha
+ref name='bool'/
+ /element
+/optional
+ /interleave
+/element
+ /define
+
define name=customElement
element
anyName/
diff --git a/osinfo/Makefile.am b/osinfo/Makefile.am
index abaa78c..e85adb7 100644
--- a/osinfo/Makefile.am
+++ b/osinfo/Makefile.am
@@ -55,6 +55,7 @@ libosinfo_1_0_includedir =
$(includedir)/libosinfo-1.0/osinfo
libosinfo_1_0_include_HEADERS = \
osinfo.h \
+ osinfo_avatar_format.h \
osinfo_db.h\
osinfo_loader.h\
osinfo_device.h\
@@ -88,6 +89,7 @@ libosinfo_1_0_include_HEADERS = \
$(NULL)
libosinfo_1_0_la_SOURCES = \
+ osinfo_avatar_format.c \
osinfo_entity.c\
osinfo_enum_types.c\
osinfo_filter.c\
diff --git a/osinfo/libosinfo.syms b/osinfo/libosinfo.syms
index de33a70..f3349d9 100644
--- a/osinfo/libosinfo.syms
+++ b/osinfo/libosinfo.syms
@@ -317,6 +317,12 @@ LIBOSINFO_0.2.1 {
LIBOSINFO_0.2.2 {
global:
+ osinfo_avatar_format_get_type;
+ osinfo_avatar_format_get_mime_types;
+ osinfo_avatar_format_get_width;
+ osinfo_avatar_format_get_height;
+ osinfo_avatar_format_get_alpha;
+
osinfo_install_config_param_policy_get_type;
osinfo_media_error_get_type;
osinfo_product_relationship_get_type;
@@ -336,10 +342,10 @@ LIBOSINFO_0.2.2 {
osinfo_install_config_get_script_disk;
osinfo_install_config_set_script_disk;
+ osinfo_install_script_get_avatar_format;
osinfo_install_script_get_path_format;
} LIBOSINFO_0.2.1;
-
/* Symbols in next release...
LIBOSINFO_0.0.2 {
diff --git a/osinfo/osinfo.h b/osinfo/osinfo.h
index
Re: [virt-tools-list] [PATCH 1/2] entity: Use g_ascii_strtoll to parse int64 strings
On Thu, Nov 22, 2012 at 4:32 PM, Christophe Fergeau cferg...@redhat.com wrote: osinfo_entity_get_param_value_int64 uses g_ascii_strod to parse strings to int64, better to use g_ascii_strtoll which is there for that purpose. ACK. --- Maybe this was done on purpose because we have floating point values which we want to interpret as int64 I don't think so. We don't have any floating point numbers in xml that we parse as numbers and not strings AFAICT. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [PATCH 2/2] entity: Fix osinfo_entity_get_param_value_int64_with_default
On Thu, Nov 22, 2012 at 4:32 PM, Christophe Fergeau cferg...@redhat.com wrote: The way it's currently implemented, osinfo_entity_get_param_value_int64_with_default will return the default value if the value which is being parsed is negative. This happens because it tries to reuse osinfo_entity_get_param_value_int64 to do the parsing, which returns -1 when the value could not be found. However, we have no way of knowing if the -1 means that the value could not be found, or if this means the value was found and its value is -1. This is made worse by the fact that we return the default value as soon as osinfo_entity_get_param_value_int64 returns a negative value, not just -1. By implementing osinfo_entity_get_param_value_int64 by calling osinfo_entity_get_param_value_int64_with_default rather than doing the contrary, we can avoid this issue. ACK -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] [libosinfo v4] API to query required user avatar format
* Put osinfo_install_script_set_avatar_format into a private header. * osinfo_install_script_get_avatar_format doesn't return a new ref. ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
