[02:00] <jmarsden> Hello, my name is Jonathan and I am an Lubuntu developer and a long-time Linux system and network admin.
[02:00] <jmarsden> This session is	about Using VirtualBox for Testing.
[02:00] <jmarsden> Hello, my name is Jonathan and I am an Lubuntu developer and a long-time Linux system and network admin.
[02:00] <jmarsden> This session is	about Using VirtualBox for Testing.
[02:01] <jmarsden> I have put my notes and	some screenshots on a wiki page	at https://wiki.ubuntu.com/Testing/Activities/Classroom/Saucy/Virtualbox
[02:01] <jmarsden> I suggest viewing that page during the class if	you are	able to	do so.
[02:02] <jmarsden> Virtualbox is free software that allows the creation and use of one or more virtual computers "inside" a real physical machine.
[02:02] <jmarsden> What that means for testers is a way to test installation or other actions that might be destructive if done on their main PC.
[02:02] <jmarsden> So it saves us from having to have several machines just in order to test installing Ubuntu.
[02:03] <jmarsden> I hope by the end of the session you will: Understand enough to install and use VirtualBox for Ubuntu ISO testing
[02:03] <jmarsden> Be able to create, configure and use VirtualBox virtual machines
[02:03] <jmarsden> And be aware of the limitations of this kind of testing.
[02:04] <jmarsden> Hopefully that is clear, and those wanting to follow along have already installed virtualbox on their own machines.
[02:04] <jmarsden> If not, on Quantal or Raring a quick    sudo apt-get install virtualbox -y
[02:05] <jmarsden> should be all you need to get that job done.
[02:05] <jmarsden> On earlier releases you probably want to download a .deb file fron virtualbox.org and install it manually.
[02:06] <jmarsden> https://www.virtualbox.org/wiki/Linux_Downloads is the page, and sudo dpkg -i virtualbox-4.2_4.2.12-84980~Ubuntu~lucid_amd64.deb
[02:06] <jmarsden> (or similar) is the command to install it.
[02:06] <jmarsden> OK, any questions about what virtualbox is or how to get it installed?
[02:07] <jmarsden> Good!  Let's look at how to create a virtual machine suitable for testing the installation of Ubuntu from a downloaded ISO image.
[02:07] <jmarsden> You can run Virtualbox from the menus or with the command    virtualbox &   in a shell.
[02:08] <jmarsden> Then click New to create a new VM (I will say VM when I mean Virtual Machine).
[02:09] <jmarsden> You need to give the VM a name and select Linux and Ubuntu for the OS type and version.
[02:10] <jmarsden> You then need to choose a memory size.  For Ubuntu 1024MB (1GB) is common.  512MB will work fine for Lubuntu or server installations, etc. and is the default size.
[02:10] <jmarsden> In general you do not want to use more than about 50% of the memory of your local PC for VMs that run at the same time.  Your host OS needs *some* RAM to work in.
[02:11] <jmarsden> But VMs only consume RAM when they are running, so you can create many VMs that use a lot of RAM, as long as you do not plan to run them all at once.
[02:12] <jmarsden> Generally speaking you will want to create a new virtual hard drive for each VM you create, and that is the default action on the next screen.
[02:13] <jmarsden> There are several different "hard drive file type"s to choose from.  The default is VDI which is fine for our purposes, so use that.
[02:14] <jmarsden> The next screen asks you to choose between a dynamic and fixed size virtual hard drive file.
[02:15] <jmarsden> Performance is somewhat faster with a fixed size file, but that uses up all the space it can be even if most of it is empty.  Using dynamic sizing means you only use the disk space on the real PC that you actually need.
[02:15] <jmarsden> And dynamic is the default, so in general just keep life simple and use that.
[02:16] <jmarsden> Next you need to tell Virtualbox how big this new virtual hard disk will be -- it's maximum size.
[02:16] <jmarsden> The default is 8GB and that works well for Lubuntu testing at least.  6GB is often sufficient if you want to keep things small.
[02:17] <jmarsden> At this point, you have a virtual machine which you could start up.  But a few changes to the configuration will help...
[02:19] <jmarsden> The first item is to tell the VM which ISO you want it to use to install from, so click on Storage and then on the "Empty" CD/DVD drive item.
[02:19] <jmarsden> Then clicking on the CD icon on the far right lets you open an ISO file (which you downloaded earlier) to select it as the "virtual CD" (or DVD) to boot this virtual machine from.
[02:20] <jmarsden> If all is well you will see the name of that ISO file appear in the "Storage Tree" section of the screen once you have selected the ISO to use.
[02:21] <jmarsden> This is, in a sense, putting a "virtual" CD in the "virtual" CD/DVD drive of the VM.  No burning step is needed, which is convenient and saves time as well as the cost of CD-R blanks.
[02:22] <jmarsden> Next we can configure networking to use what VirtualBox calls "Bridged" networking.  This is more flexible than the default of "NAT".
[02:22] <jmarsden> Bridged networking makes the virtual machine appear on the network it is bridged to (usually your local LAN).
[02:22] <jmarsden> So in that sense it is just like other machines on that network, it can see your local DHCP server, router, etc. and other machines can see it, and use services it runs.
[02:23] <jmarsden> One more optional thing we can do, while here in the Network screen, is to change the NIC type.
[02:24] <jmarsden> The default works fine, but since we are running Linux in the VM *and* Linux as a host OS, we can get better performance if we click the triangle next to "Advanced"
[02:24] <jmarsden> and then select "virtio" as the adapter type.
[02:25] <jmarsden> Then click OK to complete work in the Network dialog, and your changes to the NIC type and network type should be visible in the main Virtualbox GUI screen.
[02:26] <jmarsden> There are plenty of other things you can configure about your VM, but none are needed for ISO testing... we do not need multiple hard drives, or multiple screens, etc.
[02:27] <jmarsden> OK, any questions about configuring a VM and getting it ready to install a test version of Ubuntu ?
[02:27] <jmarsden> Good!  So now we have a VM all ready to run... how do we start it?
[02:28] <jmarsden> The easy way is to double-click on its entry in the list of VMs on the left, or select it and click the Start button , the green right-pointing arrow icon.
[02:29] <jmarsden> If you want to you can start it using a command in the shell:  VBoxHeadless --startvm name-of-vm &
[02:29] <jmarsden> where "name-of-vm" is the name you gave to your VM when configuring it.
[02:30] <jmarsden> Actually you can do all this configuration work from the command line if you want, but that is only useful if you need to script it to configure many VMs in bulk, and we won't cover doing that in this session!
[02:31] <jmarsden> When you click that Start button, or otherwise start up the VM, it will go through a boot process just like a real PC does, it even has a BIOS and you can configure whether to look at the floppy, CD, or hard disk first!
[02:32] <jmarsden> In our case it will boot from the ISO we selected for its virtual CD, and that should begin the process of installing your chosen flavour of Ubuntu.
[02:32] <jmarsden> If you are doing real ISO testing, follow the test case instructions carefully at this point... that is the subject of a different classroom session.
[02:33] <jmarsden> After the installation process is complete, you will want to reboot the machine.  You will also want to remove the (virtual) CD so it boots from the hard drive the next time.
[02:34] <jmarsden> While the VM is running you can do that by clicking Devices -> CD/DVD Devices... -> Remove disk from virtual drive.
[02:34] <jmarsden> Or, once the VM is stopped you can configure the drive to be empty (takes too long for my taste!), or run a command    VboxManage modifyvm name-of-vm --dvd none
[02:35] <jmarsden> Now if you start the VM it should boot from its virtual hard disk into Lubuntu, or whatever flavor you are testing.
[02:36] <jmarsden> If that works and you are doing application or network testing, it can be really helpful to shut the VM back down and then take a "snapshot" of it.
[02:36] <jmarsden> That means you can later quickly reset the state of the VM, including its hard disk, back to the state it was in at the time of the snapshot -- in this case, a freshly installed machine.
[02:37] <jmarsden> So, how can we shut down a VM?
[02:37] <jmarsden> The clean way is to use whatever buttons or commands exist inside the VM itself to shut it down.  For example, in a shell run the command    sudo shutdown -h now
[02:38] <jmarsden> But sometimes (recently for Lubuntu daily-live images!) doing that fails.  Just as in the real world we have some choices.
[02:38] <jmarsden> On a real PC we might push the reset button or even remove the AC power cord.
[02:39] <jmarsden> The equivalent in the Virtualbox GUI is to click Machine -> Close -> Power Off
[02:39] <jmarsden> You can do that from a command line if you prefer:    VboxManage controlvm lubuntu1310 poweroff
[02:39] <jmarsden> (if the machine name is lubuntu1310)
[02:40] <jmarsden> If the Virtualbox GUI does not work, or for whatever reason you just really really need to kill the VM, you can kill all of your currently running VMs with one command:
[02:40] <jmarsden> killall VirtualBox
[02:41] <jmarsden> The capitalization of VirtualBox matters in that command -- and please only do that if the other approaches fail to work.
[02:41] <jmarsden> Ok, any questions about the basic use of VirtualBox VMs -- starting them, stopping them, ejecting virtual CDs from them?
[02:42] <jmarsden> OK, moving on then... Virtualbox has a lot of other capabilities that are good to know about but not always necessary for ISO testing.
[02:43] <jmarsden> One of them is Guest Additions.  Ihe idea is that if you run some additional software in the VM, it can be smarter about communicating with the host PC it is running on in useful ways, including cut and paste working between applications on the VM and applications on the host.
[02:44] <jmarsden> It also allows resizing of the VM screens to any resolution you can fit on your real screen -- handy for real world use, but not all that important for ISO test use.
[02:45] <jmarsden> Guest Additions also allow setting up shared file space on the host machine that is visible in the VM as well.
[02:45] <jmarsden> This is handy for developers who build a new application on their host and then want to install it on the guest, or the other way around.
[02:46] <jmarsden> In ISO testing you do occasionally want to move a log file or a config file from the guest out to the host, ready to create a LaunchPad bug or something.
[02:46] <jmarsden> For that, just using scp works well enough that in general it is not worth setting up Guest Additions and file sharing, at least in my view.
[02:47] <jmarsden> You can configure VMs to be accessible using Remote Desktop.  This is the screen, keyboard and mouse "remote control" protocol that Microsoft Windows uses by default, and the rdesktop client uses in Linux.
[02:48] <jmarsden> Again that is rarely useful for our testing purposes, unless you set up test VMs at home and then go somewhere else and run tests on them :)
[02:49] <jmarsden> One thing Virtualbox does not offer by default is access to USB devices.  You can add a closed source "Extension pack" to get this capability, if you need it.
[02:49] <jmarsden> However you still cannot boot from USB devices, so its use for ISO testing is somewhat limited, and in general I recommend NOT installing the Extension Pack.
[02:50] <jmarsden> Any questions about these various additional capabilities that Virtualbox has?
[02:50] <ClassBot> There are 10 minutes remaining in the current session.
[02:51] <jmarsden> OK, let's briefly look at some limitations of using Virtualbox for testing.
[02:51] <jmarsden> Not using real hardware (no BIOS bugs, weird video cards, etc.)
[02:52] <jmarsden> Some people might say this is a benefit!  But it does mean some classes of bugs will not show up in a VM that will happen on some real machines.
[02:52] <jmarsden> No wireless NIC access (virtual NICs are "wired" NICs)
[02:53] <jmarsden> There may be workarounds for this but in general it is not easy to do wireless network testing in Virtualbox VMs.
[02:53] <jmarsden> No boot from USB (so testing Live USB stick "persistence" is not possible, please use a physical PC to test that)
[02:53] <jmarsden> There are test cases that need "perstistent" filesystem tests and booting from USB... Virtualbox cannot be used for those tests.
[02:54] <jmarsden> And lastly, it is not easy to test or use special purpose hardware (Braille readers, USB devices, scanners, SCSI controllers, etc.) in VMs
[02:55] <jmarsden> For further detailed info, see http://www.virtualbox.org or the man pages for vboxmanage and vboxheadless , and the full Virtualbox user manual which is at https://www.virtualbox.org/manual/UserManual.html
[02:55] <jmarsden> And we have five minutes left... any questions?
[02:55] <ClassBot> There are 5 minutes remaining in the current session.
[02:56] <jmarsden> None :)  Either everyone is asleep or I answered the questions already :)
[02:57] <jmarsden> Ok, thanks for being here and learning about Virtualbox.
[02:57] <jmarsden> The URL for the wiki page with most of what I spoek about here is https://wiki.ubuntu.com/Testing/Activities/Classroom/Saucy/Virtualbox
[06:00] <ahmadubuntu> hi every body
[06:00] <ahmadubuntu> how I can see channel logs?
[06:01] <smartboyhw> !irclogs | ahmadubuntu
[06:01] <ubot2`> ahmadubuntu: Official channel logs can be found at http://irclogs.ubuntu.com/ . LoCo channels are now logged there too.
[06:01] <ahmadubuntu> thanks
[06:01] <ahmadubuntu> !irclogs
[06:01] <ubot2`> Official channel logs can be found at http://irclogs.ubuntu.com/ . LoCo channels are now logged there too.
[14:30] <balloons> Hello and welcome to the Introducing Test Cases session . My name is Nicholas Skaggs and I'm the QA Community Coordinator. Thanks for attending (or reading this log later!)!
[14:31] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2013/06/28/%23ubuntu-classroom.html following the conclusion of the session.
[14:31] <balloons> I hope everyone is ready for some QA classroom sessions! I'll repeat my intro again for the log ;-)
[14:31] <balloons> Hello and welcome to the Introducing Test Cases session . My name is Nicholas Skaggs and I'm the QA Community Coordinator. Thanks for attending (or reading this log later!)!
[14:31] <balloons> In this session we're going to provide a brief overview of the different testcase types you'll encounter, talk a little about where the team stores and manages it's testcases, and then let you know how you can learn more about contributing testcases and results.
[14:32] <balloons> Feel free to ask questions at any time by prefixing your question with QUESTION: in the chat
[14:32] <balloons> The sessions following this will cover using different tools to help you test manual testcases.
[14:32] <balloons> Next week there is a section of classroom sessions on creating new manual and automated testcases. If your curious about contributing in this area, please feel free to ask questions and check out the resources given.
[14:32] <balloons> Also mark the date and time to attend those sessions.
[14:33] <balloons> The full classroom list is found here: https://wiki.ubuntu.com/Testing/Activities/Classroom/Saucy
[14:33] <balloons> And with that, let's get started
[14:34] <balloons> So, let's start off by talking about what a testcases is.
[14:34] <balloons> According to the ISTQB (http://en.wikipedia.org/wiki/International_Software_Testing_Qualifications_Board) a
[14:34] <balloons> TestCase is:
[14:34] <balloons> A set of input values, execution preconditions, expected results and execution postconditions, developed for a particular objective or test condition, such as to exercise a particular program path or to verify compliance with a specific requirement. [After IEEE 610]
[14:35] <balloons> Definitions are fun eh? So what does it really mean?
[14:35] <balloons> Simply put a testcase is a set of specific actions and specific results. By performing the listed action, you should expect the listed result.
[14:36] <balloons> This allows for the test to be completely repeatable and reproducible across many machines and testers without ambiguity
[14:36] <balloons> So how is this useful to us?
[14:36] <balloons> By having a list of testcases we can ensure the software works EXACTLY the same, and as EXPECTED for ANYONE.
[14:37] <balloons> If I follow the testcase and get the proper result, and so does 5 other testers, we have assurance that the software will function properly on each of these representative machines.
[14:37] <balloons> However we also have what are called smoke tests. These tests don't meet the listed criteria above for a testcase.
[14:38] <balloons> Instead, they are a list of open exploratory questions intended for the testers to intercept and potentially find issues.
[14:38] <balloons> A smoke test is not repeatable or reproducible and therefore has much more limited use. In general we greatly prefer well written testcases with the Action/Expected Result format.
[14:39] <balloons> So we understand what a testcase is, and how it is useful to us. So, what does a testcase look like?
[14:39] <balloons> A typical testcase found on the testing tracker intended for manual testing will follow one of two formats mentioned above.
[14:39] <balloons> You can see the formats listed on this page: https://wiki.ubuntu.com/Testing/TestCaseFormat
[14:41] <balloons> For some real-life examples, let's look at the packages and iso trackers for an example of each testcase.
[14:41] <balloons> Here's a default testcase on the iso tracker: http://iso.qa.ubuntu.com/qatracker/testcases/1301/info
[14:42] <balloons> And here's an example of a smoke test: http://packages.qa.ubuntu.com/qatracker/testcases/1336/info
[14:42] <balloons> See how the smoke test (barring a couple Action/Expected results at the top :-) ) is a list of questions which are open ended? This allows for a broad range, but very shallow testing.
[14:42] <balloons> The default test showcases a list of Actions/Expected results that tests very specific functionality.
[14:43] <balloons> In general we prefer these style of testcases as noted above.
[14:44] <balloons> So how do you use it? If your contributing results to a qatracker and you have a default testcase you now have the knowledge to understand how to read it.
[14:44] <balloons> Perform the action in bold, and then wait for the expected result listed in italics. If you don't get the expected result for ANY step you've found a bug and something is wrong.
[14:45] <balloons> This is general overview of what testcases look like, how they work, and the thought process behind them. The next sessions will cover performing testing using the testcases found on the various trackers.
[14:45] <balloons> next week we'll also cover writing testcases. Both manual tests, as we've covered and seen above, as well as automated tests
[14:46] <balloons> Are there any questions?
[14:48] <balloons> If not we'll wrap this one up early then. Enjoy the next sessions!
[14:50] <ClassBot> There are 10 minutes remaining in the current session.
[14:55] <ClassBot> There are 5 minutes remaining in the current session.
[15:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2013/06/28/%23ubuntu-classroom.html following the conclusion of the session.
[15:01] <phillw> Hi, my name is Phill. Whiteside and I'm the Team Leader for lubuntu-quality. This session is a brief over-view of the installation and use of KVM, using the graphical interface (GUI) virtual manager.
[15:02] <phillw> Firstly, can you please ensure that you have carried out the steps of getting and ISO and installing virtual-manager as detailed in https://wiki.ubuntu.com/Testing/Activities/Classroom/Saucy/Section3
[15:03] <phillw> So, what is KVM?
[15:04] <phillw> It is a virtualisation system that allows you to install and run a different (or same) operating system from within your existing system.
[15:05] <phillw> If any one has questions while I go through this session, please feel free to ask on the #ubuntu-classroom-chat channel, prefix your question QUESTION: so that I notice it!
[15:05] <phillw> KVM is exrtremely powerful, something which can put new comers off. I speak from experience!
[15:06] <phillw> However, we're going to use virtual-manager which takes care of the 'behind the scenes' stuff
[15:08] <phillw> Assuming you have virtual manager installed and have added yourself to the group libvirtd then Virtual Machine Manager should appear in your menu area (On my system it is under "System Tools")
[15:09] <phillw> launching it for the 1st time will bring up a window with no entries in it.
[15:10] <phillw> Towards the top left corner is a little icon that looks like a computer with a small sun shining on it. Clicking on this creates a new Virtual Machine
[15:13] <phillw> Sorry for the pause, I was doing some other work on it and had managed to disconnect myself!
[15:14] <phillw> We now have a window called 'New VM', into this enter the name you want it called (I'm using lubuntu AMD64, so I'll call mine lubuntu-64)
[15:14] <phillw> We are using a local ISO, so we just need to click 'Next'.
[15:15] <phillw> (Forward)
[15:15] <phillw> Next, it is asking where the ISO is stored. That depends on where you saved it / them. I use ~/Desktop/iso/ to hold mine
[15:16] <phillw> So I browse to /home/phillw/Desktop/isos/saucy-alternate-amd64.iso
[15:16] <phillw> The OS Type is Linux from that drop down box
[15:17] <phillw> and it should default to ubuntu12.10 which is quite close enough for us
[15:17] <phillw> Click 'Forward'
[15:22] <phillw> I use 512MB of RAM and 1 processor for testing, obviously if you have plenty of RAM or you intend to do smoke testing of applications you can use the default of 1024 MB
[15:24] <phillw> next up is the Create a disk image. Again I use 10 GB for this, so as to have room to do the side-by-side installs that are mentioned in the test cases, but you can use 5GB if space is low on your hard drive
[15:26] <phillw> sorry for the pauses here, my local virt-manager has decided not to play and I've had to ssh into my dedi server!
[15:27] <ClassBot> Vasudevan asked: how to improve the video perf of the kvm guest - my settings are : model - vga,  RAM - 9 MB. Tried increasing ram - does not seem to help - screen refresh is sluggish
[15:27] <phillw> kvm guests are getting opengl acceleration sometime this year (fingers crossed) (thanks balloons)
[15:28] <phillw> Vasudevan: one of the other things to check is if your CPU supports hardware acceleration, you can check that out at https://help.ubuntu.com/community/KVM/Installation#Check_that_your_CPU_supports_hardware_virtualization
[15:29] <phillw> again, sorry for the pauses
[15:30] <phillw> Having selected the disk size you want, click 'forward'
[15:30] <phillw> It will give you a summary of what it is about to do.
[15:31] <phillw> one *VERY* important thing here is to click on the 'Customise installation before install'.
[15:31] <phillw> this is because of bug 1080674
[15:32] <phillw> which means the default video setting does not work
[15:32] <phillw> I'll include the full link... https://bugs.launchpad.net/cairo/+bug/1080674
[15:33] <phillw> So, put a tick in that box and then click 'Finish'.
[15:33] <phillw> a new window opens, click on video on the left hand panel.
[15:34] <phillw> and change it from 'default' to vmvga
[15:35] <phillw> Click 'Apply', then click on 'Begin Installation' (Near the Top left of the window)
[15:36] <phillw> A new window will appear, once it connects it behaves just like a normal installation.
[15:37] <phillw> Now then, in best tradtions... I prepared one earlier on my local machine.
[15:38] <phillw> After the installation is completed and it has rebooted, you will have the usual grub2 login screen.
[15:39] <phillw> one note of grub... it will say that it can only find one operating system in yor VM - this is correct. the virtual machine is enclosed in its own little 'sandbox' and cannot affect your host machine.
[15:41] <phillw> when you shut down the virtual machine (usually via the *ubuntu shut down method) you can close the window and also then close the virtual machine window.
[15:42] <phillw> The next time you want to fire up the machine, launch virtual machine manager, click on the machine you want to use and then click the 'play' icon. Once it is starting up, click on Open and a new window will appear showing the machine boot up.
[15:44] <phillw> If you want to really delve into how much you can do with KVM then there is an extensive wiki area at https://help.ubuntu.com/community/KVM/ which goes into full details of different ways to use KVM. These are beyond this course (I even use virt-manager on my dedicated server) with a couple of virsh commands to fine tune a couple of things as the VM's on there are 'production' machines.
[15:45] <phillw> So, does anyone have any questions?
[15:46] <ClassBot> Vasudevan asked: Did not use guestfish before; guestfish is installed, but the next cmd fails - sudo libguestfs-test-tool -> command not found?
[15:47] <phillw> Vasudevan: I'm covering guest fish in the next session
[15:50] <ClassBot> There are 10 minutes remaining in the current session.
[15:55] <ClassBot> There are 5 minutes remaining in the current session.
[16:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2013/06/28/%23ubuntu-classroom.html following the conclusion of the session.
[16:02] <phillw>  Hi, my name is Phill. Whiteside and I'm the Team Leader for lubuntu-quality. This session is a brief over-view of the installation and use of guest-fish
[16:03] <phillw> what is guest-fish?
[16:03] <phillw> It is a set of commands that allow to manipulate KVM's
[16:06] <phillw> The one that I will specifically be covering is that of the copy-out command.
[16:06] <phillw> http://libguestfs.org/guestfs-recipes.1.html#export-any-directory-from-a-vm
[16:06] <phillw> has the general syntax, but I'll give an example
[16:07] <phillw> if your virtual machine 'died' during an install and will not restart, you need to get the log files from it.
[16:08] <phillw> to use guestfish tools the machine needs to not be running (in this case it is obviously not!!)
[16:08] <phillw> on your host machine, do a
[16:08] <phillw> cd
[16:08] <phillw> to get to your home directory
[16:09] <phillw> assuming your virtual machine is called
[16:09] <phillw> myvirtualmachine
[16:09] <phillw> we issue the command
[16:10] <phillw> virt-copy-out -d myvirtualmachine /var .
[16:10] <phillw> this will take the entire contents of /var and pop them into ~/home/var
[16:11] <phillw> using this command you can pull in crash reports etc. or even the entire machine using
[16:11] <phillw> virt-copy-out -d myvirtualmachine / .
[16:12] <phillw> virt-copy-out has a sister command virt-copy-in, which I've used on a poorly VM to insert a patch onto it when it could not 'see' the network and I couldn't use apt-get :)
[16:16] <phillw> If you'd like to look at the other things you can do with guest fish, head over to http://libguestfs.org/guestfs-recipes.1.html
[16:16] <phillw> Again, a lot of this is outside the scope of this quick introduction which was meant simply as a way to pull files from a 'dead' KVM so that a bug could still be raised.
[16:17] <phillw> if you have any questions, please feel free to ask (Remember to prefix them with QUESTION:  )
[16:21] <ClassBot> There are 10 minutes remaining in the current session.
[16:23] <phillw> if you have questions on any of the subjects covered in these classrooms, please feel free to ask on #ubuntu-quality or contact the tutor directly.
[16:25] <ClassBot> There are 5 minutes remaining in the current session.
[16:31] <ClassBot> Slides for Using pbuilder: http://people.ubuntu.com/~chilicuil/pdf/pbuilder.pdf
[16:31] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2013/06/28/%23ubuntu-classroom.html following the conclusion of the session.
[16:31] <chilicuil> Hi, I'm Javier Lopez an Ubuntu contributor: http://wiki.ubuntu.com/~chilicuil
[16:31] <chilicuil> on this session I'll talk a little bit about pbuilder
[16:32] <chilicuil> pbuilder is a tool many people in Debian & Ubuntu use to compile .deb packages, however it can also be used to test software, or to try things in a sandbox
[16:32] <chilicuil> I made some slides that you can fetch from: http://people.ubuntu.com/~chilicuil/pdf/pbuilder.pdf
[16:32] <chilicuil> if you have any question at any point feel free to ask in the #ubuntu-classroom-chat channel and I'll be happy to answer
[16:32] <chilicuil> so, to begin
[16:32] <chilicuil> technically, pbuilder is a cli driven wrapper in bash for chroot, debootstrap, dpkg-source and other similar tools
[16:33] <chilicuil> it helps to create minimal Ubuntu setups (using debootstrap) which then are saved and compressed in /var/cache/pbuilder
[16:33] <chilicuil> after the initial setup, pbuilder can uncompress and mount any of these images in a chroot environment
[16:34] <chilicuil> chroot is an old tool which was introduced for the first time in the 70s on Unix systems
[16:34] <chilicuil> it allows to change the root directory to one specified, this creates the ilussion that you are in other system from where you can launch apps that cannot access files from outside the chroot on normal conditions
[16:34] <chilicuil> this minimal setups are easy to create and use with pbuilder
[16:35] <chilicuil> I forgot to tell you, that this session will be practical, so fire up you terminal if you haven't done it =P
[16:36] <chilicuil> to continue I'll ask you install:
[16:36] <chilicuil>  $ sudo apt-get install pbuilder
[16:36] <chilicuil> if you don't feel like installing anything, feel free to ssh ubuntu@vps.javier.io and use any of the 10 available spots, passwd=ubuntu
[16:36] <chilicuil> pbuilder has already been installed there so you can avoid the last step
[16:36] <chilicuil> I'll wait a couple of minutes so you can decide if you install it or use the vps env =)
[16:38] <chilicuil> there are many alternatives to pbuilder, such as, pbuilder-dist, pbuild, sbuild, etc
[16:38] <chilicuil> however in my opinion, pbuilder is one of the easiest to use and maintain once you've configured correctly
[16:38] <chilicuil> in order to start using it, you'll need to configure a couple of vars in your ~/.bashrc and ~/.pbuilderrc files
[16:39] <chilicuil> first, you need to identify yourself, you can do it if you add the following to the ~/.bashrc file
[16:39] <chilicuil>  export DEBEMAIL="yourmail@domain.com"
[16:39] <chilicuil>  export DEBFULLNAME="Your Name"
[16:39] <chilicuil>  Ubuntu vars here: https://github.com/chilicuil/dotfiles/blob/master/.alias.linux#L51
[16:40] <chilicuil> that how my personal conf looks, feel free to grab any var
[16:40] <chilicuil> once you've updated your file, you need to create a ~/.pbuilderrc file
[16:42] <chilicuil> the ~/.pbuilderrc is nothing but a pure bash script, it may seem scary at the first impression but don't let it to stopping you from trying it, I'll suggest you to try with the following file
[16:42] <chilicuil>  $ wget https://raw.github.com/chilicuil/dotfiles/master/.pbuilderrc -O $HOME/.pbuilderrc
[16:43] <chilicuil> now, if you open the file, you'll see a lot of vars, it because this file has been customized to allow pbuilder work with differente ubuntu and debian releases
[16:43] <chilicuil> I wont explain every aspect of it but the most important parts
[16:43] <chilicuil>  UBUNTU_SUITES=("saucy" "raring" "quantal" "precise")
[16:44] <chilicuil> here are defined the releases pbuilder will be able to manage, whenever a new dev cycle start you can update this part to include the newest ubuntu dev release
[16:44] <chilicuil>  UBUNTU_MIRROR="us.archive.ubuntu.com"
[16:44] <chilicuil> from where pbuilder will download files
[16:44] <chilicuil>  PATH_PBUILDER="/var/cache/pbuilder"
[16:44] <chilicuil> where minimal ubuntu setups will be saved
[16:44] <chilicuil>  HOOKDIR="$HOME/.pbuider-hooks/"
[16:45] <chilicuil> where hooks will be saved, hooks are scripts (in any language) which are launched at different times, ie. before login into the chroot environment, before building packages, before deleting the environment, etc
[16:46] <chilicuil> right now I suggest you to trust me and use this config, if you agree, you'll need ot place a '#' before  export BUILDRESULT=....
[16:46] <chilicuil> this will allow pbuilder to save to /var/cache/pbuilder/result/, otherwise it will fail when trying to copy to the specified version, I'm running a modified pbuilder version
[16:47] <chilicuil> let me know when if you do it, or if you have problems to edit the file, I'll wait a couple of minutes
[16:49] <chilicuil> ok, now that we have it configured (hopefully correctly), we're gonna try to login
[16:49] <chilicuil> run the following in a terminal:
[16:49] <chilicuil>  $ sudo DIST=saucy ARCH=amd64 pbuilder login
[16:49] <chilicuil> anyone was able to do it?
[16:52] <chilicuil> if you try to do it, you'll find that it wont be possible, since you've not created the minimal image
[16:52] <chilicuil> so, we need to create it first
[16:52] <chilicuil>  $ sudo DIST=saucy ARCH=amd64 pbuilder create
[16:55] <chilicuil> balloons> QUESTION:  sudo DIST=saucy ARCH=amd64 pbuilder create -- are you making a little chroot here?
[16:56] <chilicuil> thanks for asking balloons, yep, a chroot is created and then very basic packages are installed, after that, the complete chroot is saved and compressed so pbuilder don't need to recreate it every time you use it
[16:57] <chilicuil> and it end of the command you should have a file in /var/cache/pbuilder/saucy-amd64/saucy-amd64-base.tgz with the minimal setup
[17:00] <chilicuil> Vasudevan> this also failed - E: debootstrap failed W: Aborting with an error
[17:01] <chilicuil> E: No such script: /usr/share/debootstrap/scripts/saucy
[17:02] <chilicuil> nice catch Vasudevan, when working with very recent ubuntu releases sometimes the soft links in /usr/share/debootstrap/scripts/ are not updated (on stable releases), so you need to create them manually
[17:02] <chilicuil> you can do it by running: $ cd /usr/share/debootstrap/scripts && sudo ln -s gutsy saucy
[17:02] <chilicuil> and then retrying the create step: $ sudo DIST=saucy ARCH=amd64 pbuilder create
[17:04] <chilicuil> you should look now a verbose output with all the packages which are been installed in the minimal setup
[17:05] <chilicuil> dependying on you bandwidth it should create a minimal setup in 5-20 minutes
[17:06] <chilicuil> you can create as many minimal setups as you want, for example, ubuntu precise for i386 computers
[17:06] <chilicuil>  $ sudo DIST=precise ARCH=i386 pbuilder create
[17:07] <chilicuil> or ubuntu raring for amd64, $  sudo DIST=raring ARCH=amd64 pbuilder create
[17:07] <chilicuil> Skini151> QUESTION: What package we can't test with pbuilder?
[17:10] <chilicuil> great question Skini151, chroots have their limits, I've been personally able to run even unity on a chroot environment, however I'd say that it's perfect for testing apps which doesn't have too many dependencies, for example bad apps to test would be the scopes, or an apps which depends of a particular network setup, for example network-manager
[17:11] <chilicuil> good examples are gedit, the calculator app, most cli apps, vim, netcat, coreutils...
[17:11] <chilicuil> Skini151> QUESTION: Is there a list of packages that can be tested with pbuilder or vice versa
[17:12] <chilicuil> Skini151: not that I know, however any app which can work on a chroot environment can be tested with pbuilder, since pbuilder is only a wrapper around chroot
[17:13] <chilicuil> Skini151: I'll look at it and will give you back a list off-air
[17:14] <chilicuil> alright, if you completed the last step, you should have now a minimal and pristine image of ubuntu saucy in /var/cache/pbuilder/saucy-amd64/saucy-amd64-base.tgz, let's continue
[17:15] <chilicuil> to make sure our image works, we are going to compile a package
[17:15] <chilicuil> in another terminal, please type:
[17:15] <chilicuil>  $  mkdir hello && cd hello
[17:15] <chilicuil> and then: $ pull-lp-source hello #probably you'll need to install ubuntu-dev-tools
[17:16] <chilicuil> this will fetch the source code of the hello package, which is a program that print 'Hello World!', a very basic program
[17:19] <chilicuil> Vasudevan> QUESTION: can we ignore this error - E: Logic failure in hook handling. Directory /var/cache/pbuilder/saucy-amd64/build//31858/tmp/hooks should exist but it does not.
[17:19] <chilicuil>  Vasudevan: if you don't have, and it fails completely, you can create a directory in ~/.pbuilder-hooks or to comment out the hooks var in your ~/.pbuilderrc file
[17:19] <chilicuil> it looks like this:
[17:19] <chilicuil> HOOKDIR="$HOME/.pbuilder-hooks/"
[17:20] <ClassBot> There are 10 minutes remaining in the current session.
[17:21] <chilicuil> if you downloaded the source code of the hello package, you can create the source deb file (.dsc) with the following command:
[17:21] <chilicuil>  $ cd hello-* && debuild -S -us -uc && cd ..
[17:22] <chilicuil> and then build the package with the following:  $ sudo DIST=saucy ARCH=amd64 pbuilder build hello*.dsc
[17:22] <chilicuil> this step will take a couple of minutes, and the result will be available in: /var/cache/pbuilder/result/saucy-amd64
[17:23] <chilicuil> if you see a .deb package there, we've done it right, and we can ensure we have a working minimal image available
[17:24] <chilicuil> now that we know for sure that pbuilder works we can use it for whichever we want, one of these possibilities is for testing sru's
[17:24] <chilicuil>  https://wiki.ubuntu.com/QATeam/PerformingSRUVerification
[17:24] <chilicuil> try this:
[17:24] <chilicuil>  $ sudo DIST=saucy ARCH=amd54 pbuilder login
[17:24] <chilicuil> you've access to a pristine environment, cool, eh?
[17:24] <chilicuil> there are some tips available from the <SLIDE 16>, and some other good resources at:
[17:25] <chilicuil>  * tinyurl.com/pbuilder
[17:25] <chilicuil>  * wiki.ubuntu.com/PbuilderHowto
[17:25] <chilicuil> and if you need help, feel free to join us at #ubuntu-quality, #ubuntu-motu or ping me directly
[17:25] <chilicuil> I think that's all, any question?
[17:25] <chilicuil> jsjgruber-l99-p> QUESTION: How do you use pbuilder to test unity?
[17:25] <ClassBot> There are 5 minutes remaining in the current session.
[17:27] <chilicuil> jsjgruber-l99-p: I was actually thinking in chroot when answered that question, I suppose pbuilder can be modified to do it, however it can't be done by default, to run unity inside of chroot you'll to mount extra directories, most taken from the livecd and then start some other deamons, such as dbus, enable X connections to the outside X and launch finally unity
[17:30] <chilicuil> thanks everyone for attending (or reading later)
[17:30] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2013/06/28/%23ubuntu-classroom.html