[00:17] <kees> tgm4883: look in /dev/v4l/by-path  (if it exists)  that should list the various tuners by physical location
[00:18] <kees> tgm4883: if you don't have that, add something like /etc/udev/rules.d/65-video-capture-names.rules:
[00:18] <kees> ACTION!="add", GOTO="video_capture_names_end"
[00:18] <kees> SUBSYSTEM!="video4linux", GOTO="video_capture_names_end"
[00:18] <kees> KERNEL=="video[0-9]", ATTRS{subsystem_vendor}=="0x7063", ATTRS{subsystem_device}=="0x3000", SYMLINK+="video-pchdtv"
[00:18] <kees> KERNEL=="video[0-9]", ATTRS{subsystem_vendor}=="0x0070", ATTRS{subsystem_device}=="0x4009", SYMLINK+="video-pvr250"
[00:18] <kees> KERNEL=="video[0-9]", ATTRS{subsystem_vendor}=="0x0070", ATTRS{subsystem_device}=="0x8003", SYMLINK+="video-pvr150"
[00:18] <kees> LABEL="video_capture_names_end"
[00:18] <kees> where the vendor and device map to your devices
[00:53] <CRXLPY> I am using the trunk repo for mythtv. I have not been able to use mytharchive for some time. It instructs me to recompile the plugin after a make distclean.....
[01:08] <CRXLPY> is mytharchive not current with trunk yet, or did I miss something silly?
[02:48] <pteague> i'm getting ready to build a new front end... i'm wondering if i go with intrepid if the front end will still work with my hardy back end ?
[02:58] <foxbuntu> pteague, should as long as your running Myth .21 on both
[03:01] <pteague> k, wasn't sure as i currently only have 1 box with intrepid installed so far... & it's an old 1 i discovered most of the ram in it was bad when i repurposed it...  so not sure what packages intrepid has for mythtv yet
[03:02] <pteague> back end has 0.21.0+fixes18207-0ubuntu4
[03:05] <pteague> hmm... any issues with the 64bit ? or is it still if you don't need it don't bother?
[03:08] <foxbuntu> pteague, it hasnt been that for a long time
[03:09] <foxbuntu> pteague, I use 64 on all my 64 hardware
[03:09] <foxbuntu> pteague, you should have no problems with Myth between intrepid and hardy
[03:12] <pteague> k, just wondering... i'm running 64bit on my desktop & usually don't have issues... just on occasion i get people that tell me all the problems with 64bit ;)
[03:13] <foxbuntu> pteague, 64bit windows perhaps :)
[03:14] <pteague> lol
[06:39] <cdg> howdy. -- Anyone on who knows anything about the Antec Fusion VFD?
[06:50] <foxbuntu> cdg, VFD or LCD?
[06:51] <cdg> VFD
[06:51] <cdg> and Silver if that matters
[06:51] <foxbuntu> yup
[06:51] <foxbuntu> cdg, what is the problem, silver pretty much work ootb
[06:52] <cdg> just got the case and trying to get the display to work.  When I power it on the entire display lights up (I can see all of the icons etc)
[06:52] <cdg> and it stays like that.
[06:52] <foxbuntu> cdg, you need to install LCDproc
[06:53] <cdg> I have the LCDproc from the 8.10 repos
[06:53] <cdg> and I see this from dmesg
[06:53] <foxbuntu> cdg, then select the Soundgrpah Imon ir/LCD in MCC
[06:53] <cdg> ok that may be the part I am missing
[06:54] <cdg> what is MCC?
[06:54] <foxbuntu> cdg, Mythbuntu Control Centre
[06:54] <cdg> ok
[06:54] <cdg> just in case this helps I see this from dmesg:
[06:54] <cdg>  lirc_imon: Driver for Soundgraph iMON MultiMedia IR/VFD w/imon pad2keys patch, v0.3p2k
[06:54] <foxbuntu> thats the one
[06:55] <cdg> then I see:  lirc_imon: Venky Raju<EMAIL_ADDRESS>[06:55] <foxbuntu> yup
[06:55] <foxbuntu> cdg, sounds like you have the driver already loaded
[06:55] <cdg> yep
[06:56] <cdg> however I never see the "found IMON device" message
[06:56] <foxbuntu> cdg, not sure why, but for someone reason, first time setup, shut the machine down, and flip the power switch on the PSU until the VFD goes dark, then power it back up
[06:56] <cdg> I read something similar to that on the antec site
[06:56] <foxbuntu> cdg, ls /dev/lirc*
[06:56] <cdg> ls: cannot access /dev/lirc*: No such file or directory
[06:56] <foxbuntu> you should see /dev/lirc0
[06:56] <cdg> I don't see that
[06:57] <cdg> obviously :)
[06:57] <foxbuntu> hmm
[06:57] <foxbuntu> lets see
[06:57] <foxbuntu> ah
[06:57] <foxbuntu> use the hardware conf from my wiki
[06:57] <foxbuntu> !antec black
[06:57] <Zinn> Sorry I don't know about antec black
[06:57] <foxbuntu> !antec%
[06:57] <Zinn> If you are having trouble setting up the LCD on the Antec Fusion v2 Black or its other integrated devices, check out this Wiki Article: http://wiki.foxmediasystems.com/index.php/Antec_Fusion_v2_Black_LCD
[06:57] <cdg> thanks!
[06:58] <foxbuntu> the hardware.conf section applies
[06:58] <foxbuntu> the rest wont
[06:58] <cdg> ok
[06:59] <cdg> ok I got it
[06:59] <foxbuntu> sudo /etc/init.d/restart lirc
[07:00] <foxbuntu> dmesg | grep lirc_imon
[07:00] <foxbuntu> ls /dev/lirc*
[07:00] <cdg> dmesg output:
[07:01] <cdg> [  777.989765] lirc_imon: Driver for Soundgraph iMON MultiMedia IR/VFD w/imon pad2keys patch, v0.3p2k
[07:01] <cdg> [  777.989772] lirc_imon: Venky Raju<EMAIL_ADDRESS>[07:01] <cdg> [  777.989809] usbcore: registered new interface driver lirc_imon
[07:01] <cdg> ls output:
[07:01] <cdg> /dev/lircd
[07:01] <cdg> that seems much better
[07:01] <foxbuntu> ok
[07:01] <foxbuntu> oh
[07:02] <foxbuntu> you also need to update your LCDd.conf
[07:02] <foxbuntu> sudo nano /ect/LCDd.conf
[07:02] <cdg> ok
[07:03] <foxbuntu> change the driver from Driver=curses to Driver=imon (iirc) look in the notes to make sure
[07:03] <foxbuntu> then: sudo /etc/init.d/lirc restart
[07:04] <cdg> ok
[07:04] <foxbuntu> then: sudo /etc/init.d/LCDd restart
[07:04] <cdg> did it
[07:04] <foxbuntu> dmesg | grep LCDd
[07:04] <cdg> nothing
[07:05] <foxbuntu> that might not work...im not sure what it shows up as off hand
[07:05] <foxbuntu> try the power off thing now
[07:05] <cdg> ok
[07:06] <cdg> let me fire up my irc client on my other computer
[07:06] <foxbuntu> k
[07:10] <cdg2> ok im rebooting my box now
[07:10] <cdg2> or really shutting it down
[07:10] <foxbuntu> did you take the power away?
[07:10] <foxbuntu> oh ok
[07:11] <foxbuntu> you have to flip the switch to get the VFD to shut off
[07:11] <cdg2> yeah I just unplugged the power cable
[07:11] <foxbuntu> ok
[07:11] <cdg2> ok so should I power it back on?
[07:11] <foxbuntu> yes
[07:12] <foxbuntu> as it boots up, if its all setup correctly, you will get LCDproc server on the VFD
[07:13] <cdg2> ok it is booting now and the display is on
[07:13] <foxbuntu> it will be close to the end of the boot that it should start to display something
[07:13] <cdg2> nope
[07:14] <cdg2> still the same.  everything on the display is on
[07:14] <foxbuntu> lsusb
[07:15] <cdg> Bus 004 Device 003: ID 15c2:0038 SoundGraph Inc.
[07:15] <cdg> Bus 004 Device 002: ID 413c:2105 Dell Computer Corp.
[07:15] <cdg> Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
[07:15] <cdg> Bus 003 Device 002: ID 093a:2510 Pixart Imaging, Inc.
[07:15] <cdg> Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
[07:15] <cdg> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
[07:15] <cdg> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
[07:15] <foxbuntu> ok
[07:16] <foxbuntu> ls /dev/lirc*
[07:16] <cdg> /dev/lircd
[07:16] <foxbuntu> ls /dev/lcd*
[07:17] <cdg> ls /dev/lcd*
[07:17] <cdg> oops
[07:17] <cdg> ls: cannot access /dev/lcd*: No such file or directory
[07:20] <foxbuntu> oh duh
[07:20] <foxbuntu> there is a modprobe option you are missing
[07:20] <foxbuntu> let me find it quick
[07:20] <cdg> cool
[07:23] <foxbuntu> ok
[07:23] <foxbuntu> sudo nano /etc/modprobe.d/options
[07:24] <cdg> ok
[07:24] <foxbuntu> then add these lines:
[07:24] <foxbuntu> # Set lirc_imon option to use LCD device
[07:24] <foxbuntu> options lirc_imon is_lcd=1
[07:24] <foxbuntu> then: sudo /etc/init.d/lirc restart
[07:25] <cdg> k
[07:25] <foxbuntu> ls /dev/lcd*
[07:25] <cdg> ls: cannot access /dev/lcd*: No such file or directory
[07:26] <foxbuntu> hrm
[07:26] <foxbuntu> usually dont have any problems with the Silver case
[07:26] <cdg> just my luck :)
[07:27] <foxbuntu> must be slightly different hardware
[07:27] <cdg> I was worried I wired the VFD incorrectly
[07:27] <foxbuntu> doubtful
[07:27] <cdg> that is good to know
[07:27] <foxbuntu> its key'd
[07:28] <foxbuntu> you say it has icons?
[07:28] <foxbuntu> on the display
[07:28] <foxbuntu> it sounds more like the LCD rather than the VFD
[07:28] <cdg> yeah I see "music", movie, etc across the top
[07:29] <foxbuntu> I wonder if Antec switched from the VFD on the silver cased
[07:29] <cdg> any way to tell for sure?
[07:29] <cdg> im looking at the manual
[07:29] <foxbuntu> the product number on the device...
[07:30] <cdg> I don't see anything on the outside except for antec
[07:31] <foxbuntu> no, the product number for the device was in the lsusb output you gave me earlier, I already looked it up, it is indeed the VFD
[07:31] <foxbuntu> just a different version of it
[07:31] <cdg> oh ok
[07:32] <cdg> does that mean I am sailing in uncharted waters?
[07:33] <foxbuntu> you could try: sudo apt-get update && sudo apt-get install lirc-modules-source
[07:33] <foxbuntu> cdg, naw, I see other people that have accomplished it
[07:34] <foxbuntu> cdg, Antec just has quite a few version of the hardware variants floating around
[07:34] <cdg> well that is good to know
[07:34] <cdg> I am getting the source now
[07:35] <cdg> got it
[07:38] <foxbuntu_laptop> cdg, send it again, I lost connection
[07:38] <cdg> ok.  I have the lirc-modules-source installed
[07:39] <foxbuntu_laptop> k
[07:39] <foxbuntu_laptop> cdg, then sudo apt-cache policy lirc
[07:39] <cdg> ok
[07:39] <cdg> did you want to see the output?
[07:40] <foxbuntu_laptop> yes
[07:40] <cdg> lirc:
[07:40] <cdg>   Installed: 0.8.3-0ubuntu2
[07:40] <cdg>   Candidate: 0.8.3-0ubuntu2
[07:40] <cdg>   Version table:
[07:40] <cdg>  *** 0.8.3-0ubuntu2 0
[07:40] <cdg>         500 http://us.archive.ubuntu.com intrepid/universe Packages
[07:40] <cdg>         100 /var/lib/dpkg/status
[07:40] <foxbuntu_laptop> ok
[07:41] <foxbuntu_laptop> sudo /etc/init.d/lirc restart
[07:41] <foxbuntu_laptop> ls /dev/lirc*
[07:41] <cdg> /dev/lircd
[07:41] <foxbuntu_laptop> hmm
[07:42] <Shadow__X> foxbuntu_laptop, are you familiar with tsocks
[07:42] <foxbuntu_laptop> cdg, I have to leave, however: http://ubuntuforums.org/showthread.php?t=1041258 might be helpful, also you need to get /dev/lirc0 and /dev/lcd0 to show up to get it working
[07:42] <foxbuntu_laptop> Shadow__X, nope
[07:42] <cdg> ok.  Thanks so much for all of your help
[07:42] <Shadow__X> k thanks anyway
[07:42] <foxbuntu_laptop> cdg, no problem, gl
[07:42] <cdg> thanks!
[10:47] <tqft> anyone else having trouble with nuvexport
[23:18] <frozenskunk> Hello all! Would anyone have an idea why mythbuntu 8.10 runs very slowly on a box that has run previous versions of mythbuntu as well as knoppmyth just fine? I have noticed that if I run top from a terminal window, my CPU wait time is almost always above 90%


[12:26] <davidcalle> mariogrip: ping
[13:48] <brunch8751> Hey! External bluetooth keyboard now types accents ☺ Great job!
[14:28] <nicomen> About to buy a new phone, what device would you recommend for runnin Ubuntu these days?
[19:45] <casanova> what's the best Ubuntu touch app available right now?
[22:00] <DPA> Hi. I have a Meizu Pro 5, and there are some things I couldn't found on the Internet. I made a copy of /dev/sd{a,b,c} of my Phone. Is on sdb fastboot and the bootloader? sda contains a gpt partitiontable and the system/recovery/etc. partitions. Would fastboot still work if I override sda with zeros, and if not, which Partitions are required by fastboot? Is fastboot using the gpt partitiontable when I
[22:01] <DPA> flash a partition, or is the offset where the partition starts hardcoded? Is ist possible to flash an image of the whole /dev/sda which was created using dd? Is it possible to get debugmessages from the kernel? Is there a way to emulate the hardware of my phone? Does the position of the recovery partition matter when booting into recovery mode, and wold recovery mode still work if any other partition on
[22:01] <DPA> sda wouldn't exist anymore? If I fill /dev/fb0 with 0xFF on my PC, my screen turns white, but if I try the same on my phone, it crashes and restarts; is this a bug?
[22:15] <altker128> DPA: I think a lot of these questions have to do with the fact Ubuntu touch is working on the Android subsystem and maintains the layout of the original device (I think)
[22:37] <DPA> altker128: I think so too, but it doesn't really help me to figure out if and which parts of the partitiontable I can change, etc. I wonder who would know this?
[22:39] <altker128> DPA: Is there a reason you want to change the partitioning?  Not that you shouldn't be able to.
[22:42] <DPA> Not really, I think about creating my own distribution, and I try to figure out what I can do without breaking my phone in a way I can't fix anymore.
[22:45] <altker128> DPA: Understood.  I don't have an M5 Pro, otherwise I'd pitch in


[08:53] <varg1> امروز کلاس چه ساعتی شروع می‌شه؟
[13:00] <smartboyhw> Guys, our QA Classroom sessions starts 1 hour later. Make sure you join us through #ubuntu-classroom and #ubuntu-classroom-chat!
[13:01] <smartboyhw> https://wiki.ubuntu.com/Testing/Activities/Classroom/Saucy
[14:13] <smartboyhw> 17 minutes till the first classroom session begins!
[14:22] <jlking3> Hi Phill
[14:23] <smartboyhw> Yeah!
[14:23]  * smartboyhw does anticipate for his own session a week later.
[14:30] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2013/06/24/%23ubuntu-classroom.html following the conclusion of the session.
[14:31] <balloons> Hello and welcome to the ubuntu quality team session. My name is Nicholas Skaggs and I'm the QA Community Coordinator. Thanks for attending (or reading this log later!)!
[14:32] <balloons> This is the first of many being held over the next few weeks serving as a introduction to the ubuntu quality community team
[14:32] <balloons> in this sessions I'll be giving a brief overview of what we do as a team and some of the ways to be involved.
[14:33] <balloons> This will be a high-level introduction with plenty of time for questions. So let's get started
[14:33] <balloons> You may ask questions at any point.. Just be sure to utilize the #ubuntu-classroom-chat channel. Prefix your question with QUESTION: to ensure I see it.
[14:34] <balloons> So first I'm going to give a brief overview of what QA is and how the team works, then I'll dive into the activities we do during the cycle. Along the way, we'll talk about the tools we use as well. Finally, we'll talk about how you can get involved and then do a Q & A.
[14:34] <balloons> So to start off, let’s take a look at the wiki page for the team
[14:34] <balloons> http://wiki.ubuntu.com/QATeam. On the page you can see some of the teams goals and purpose. Simply put, we help ensure everyone's work in ubuntu is presented in the best possible way
[14:35] <balloons> From designing good process, to testing, to making sure things 'just work', we want the culmination of work that results in the ubuntu image to be the best it can be
[14:35] <balloons> The ubuntu community site also has a page worth checking out on quality; re-iterating these goals and some team background
[14:35] <balloons> http://community.ubuntu.com/contribute/quality/
[14:36] <balloons> So who are we and where do we hang out?
[14:36] <balloons> We're people from all over the physical world, and from many different aspects of ubuntu
[14:37] <balloons> I held a blog series recently snapshotting of few of the people who are on the team: http://www.theorangenotebook.com/search/label/peoplebehindquality
[14:37] <balloons> So where do we hang out? As you can imagine many different places. A quick list of where to find us:
[14:37] <balloons> right here on IRC, #ubuntu-quality
[14:37] <balloons> on our mailing list:     https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
[14:37] <balloons> in the forums;     http://ubuntuforums.org/forumdisplay.php?f=427
[14:37] <balloons> on askubuntu;     http://askubuntu.com/questions/tagged/quality
[14:38] <balloons> and even on social sites like facebook; https://www.facebook.com/groups/UbuntuQA/
[14:38] <balloons> twitter; https://twitter.com/ubuntutesting
[14:38] <balloons> and google+; https://plus.google.com/b/108452779163647535106/108452779163647535106/
[14:39] <ClassBot> christoffer asked: So this is not about how I can utilize launchpad (and other tools) for my own app development, is it more general about Ubuntu development?
[14:39] <balloons> christoffer, this is intended to server as an introduction to the quality team. you can see the full schedule we have planned here: https://wiki.ubuntu.com/Testing/Activities/Classroom
[14:40] <balloons> I'm not sure if there is a specific session that meets your needs or not. Most of the sessions come from a quality perspective not development.
[14:40] <balloons> Sorry that link should be: https://wiki.ubuntu.com/Testing/Activities/Classroom/Saucy
[14:40] <balloons> Ok, So, what do we do exactly as a team?
[14:41] <balloons> During the course of the cycle, we as a team participate by providing test results for the packages as they are undergoing development. If we find a bug, we'll also report and file it.
[14:41] <balloons> In addition, we develop testcases, best practices and even tools to help us test more effectively
[14:42] <balloons> We test different types of things and utilize some terms to describe them
[14:42] <balloons> The frst is cadence testing, https://wiki.ubuntu.com/Testing/Cadence.
[14:42] <balloons> Cadence testing is simply the term we use to describe that we test at regular intervals.
[14:43] <balloons> In practice, this amounts to us testing every ~2 weeks during the cycle -- we test images, packages and and hardware.
[14:44] <balloons> The second is smoke testing, or dogfooding as some would call it, the development version of ubuntu. This means simply installing or upgrading to the development release and using it as a regular machine. By attempting to work and perform tasks under the development version you may encounter a bug. Your unique usage of the development version of ubuntu represents a testcase in of itself and helps us achieve broad general coverage across a
[14:44] <balloons> variety of hardware and workflows
[14:44] <balloons> The third is a call for testing. This is a call to test a specific piece of software, with an accompanying set of tests and instructions for testing.
[14:44] <balloons> This call could happen at anytime throughout the cycle, and is utilized by developers to help ensure the software they are landing in the development version is ready for general consumption.
[14:44] <balloons> This type of testing is generally for a new package landig in the development version of ubuntu
[14:45] <balloons> So collecting the results and running these different types of tests requires us to have a tool to help
[14:45] <balloons> The tool we use is called the QATracker
[14:45] <balloons> https://wiki.ubuntu.com/Testing/QATracker
[14:45] <balloons> The tracker is where we submit the test results and get information needed to complete the test, such as the testcase and installation instructions.
[14:46] <balloons> There are actually several qatracker instances each geared towards testing different things
[14:46] <balloons> http://iso.qa.ubuntu.com is used to report results for image testing
[14:46] <balloons> http://packages.qa.ubuntu.com is used to report results for package testing
[14:46] <balloons> http://laptop.qa.ubuntu.com is used for laptop/hardware testing
[14:46] <balloons> Each one has a specific focus and keeps track of results and testcases in the specific domain we're testing
[14:47] <balloons> The wiki page I linked above gives more specific details on how the qatracker works and it's usage
[14:47] <ClassBot> smartboyhw asked: Why should people join Quality when there are other aspects of contributing to consider? (I know the answer, but not all people here do:))
[14:48] <balloons> Joining the quality is a great way to get started with contributing to ubuntu.
[14:49] <balloons> you get to work with many different teams inside ubuntu and therefore get a taste of all the different areas. Quality is never the same from cycle to cycle; there's always new things to test and new ways to do it
[14:50] <ClassBot> There are 10 minutes remaining in the current session.
[14:50] <balloons> In addition, it covers a wide variety of skills. From very technical to writing to creativity
[14:50] <balloons> We'll talk more about the opportunities in a moment
[14:50] <hmdshr> هیشکی اینجا فارسی حرف نمیزنه ؟
[14:51] <balloons> Are a technical person? Do you like to code?
[14:51] <balloons> or perhaps your just wanting to learn a little python?
[14:51] <balloons> You could consider writing some automated testcases using autopilot and contributing them to the ubuntu-autopilot-tests project
[14:51] <balloons> you could also work on some of the tools we use, such as testdrive; https://launchpad.net/testdrive
[14:51] <balloons> Perhaps you enjoy writing, or are skilled with explaining things step by step
[14:51] <balloons> we need your skills in our ubuntu-manual-tests project writing manual testcases!
[14:51] <balloons> Maybe you just like breaking things, or running bleeding edge software -- contributing test results is right up your alley!
[14:51] <balloons> Even if your not running ubuntu, but a flavor instead, we still need and welcome contributions in all of the above areas. We share many things like testcases and tools across the ubuntu family
[14:52] <balloons> smartboyhw, I hope that helps to answer your question :-)
[14:52] <ClassBot> smartboyhw asked: I accidentally stumbled upon http://desktop.qa.ubuntu.com/ . What's that for?
[14:53] <balloons> Well as you can see at one time that was used for testing the desktop -- specifically new unity features. Nowadays we simply utilize packages.qa.ubuntu.com for those sorts of tests
[14:54] <balloons> Ask any questions if you have them :-) Let me share with you the next steps for joining the team and being more involved
[14:54] <balloons> The steps for joining the team are quite simple. It's an open membership. You simply need a ubuntu SSO account
[14:54] <balloons> https://login.launchpad.net/+new_account, if you don't have one
[14:54] <balloons> That will allow you to contribute results to the tracker. In addition you should join our launchpad team and mailing list.. And then leave us a message and say hello! We're happy to help you get started and guide you through an area you'd like to help in
[14:55] <ClassBot> There are 5 minutes remaining in the current session.
[14:55] <balloons> You can consider contributing testcases, test results, or even some new artwork for our pages (we always need those with an eye for creativity ;-) )
[14:56] <balloons> Here's the links to our launchpad team and mailing list
[14:56] <balloons> LP team: https://launchpad.net/~ubuntu-testing
[14:56] <balloons> mailing list:  https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
[14:56] <ClassBot> jlking3_ asked: The process, when I look at it, seems overwhelming and intimidating. I'm afraid that I'll report something wrong or in the wrong place or in the wrong way. I don't want to make things worse for the developers.
[14:59] <balloons> jlking3, yikes! we're here to help you feel more comfortable about the process. You don't have to jump into the technical deep end of kernel debugging or some other exotic testing right away (or ever :-) ). Our tests are intended to be run by folks like yourself. We work together to share knowledge and help each other test and file bugs. You don't have to be an expert to participate
[15:00] <balloons> I don't know everything (surprise!). However collectively as a team we are able to help each other out and solve most problems
[15:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2013/06/24/%23ubuntu-classroom.html following the conclusion of the session.
[15:01] <phillw> Hi everyone, my name is Phill. Whiteside and I'm the QA Team leader for lubuntu
[15:01] <phillw> This short session is to introduce zsync and md5sum
[15:02] <phillw> Firstly, why use zsync?
[15:02] <phillw> each iso image is quite large and as they usually get updated each 24 hours, that's a lot of data!
[15:03] <phillw> zsync only downloads the parts of the ISO that have changed, it is faster AND uses less bandwidth
[15:03] <phillw> Why use md5sum?
[15:04] <phillw> it is quite possible for a corruption to occur when downloading the ISO, if this happens your ISO will either not install, or exhibit very odd behaviour
[15:05] <phillw> the other nice thing about zsync is that when it has downloaded the update, it automatically checks the MD5 checksum for you (one less step to carry out).
[15:07] <phillw> You will see the zsync links if you go to the iso tracker and select the 'cd' icon to the  left of the ISO you want to download at http://iso.qa.ubuntu.com/qatracker/milestones/270/builds
[15:08] <phillw> in my example, the alternate install for lubuntu in 1386 architecture would be zsync http://cdimage.ubuntu.com/lubuntu/daily/20130623/saucy-alternate-i386.iso.zsync
[15:09] <phillw> zsync can also be scripted up to do various tasks automatically. Further details on that can be found at https://wiki.ubuntu.com/Testing/Activities/Classroom/Saucy/Zsync
[15:09] <ClassBot> jlking3_ asked: so you always add .zsync to the end of the URL to get the zsync'd version of the iso?
[15:11] <phillw> jlking3: the tracker has several ways to down load an ISO (direct, rsync etc.) the filename ends .zsync to make it obvious that it is the zsync version
[15:12] <phillw> if you wish to manually check an  ISO, move to the directory with the ISO in it and issue the command
[15:12] <phillw> md5sum *iso
[15:13] <phillw> this will give you the md5sum of the ISO's in the directory, which you can then check against what is on the iso-tracker, in my example, that would be http://cdimage.ubuntu.com/lubuntu/daily/20130623/MD5SUMS
[15:14] <phillw> Using zsync elliminates this step, as it does it for you.
[15:15] <phillw> That's the end of this introduction, if you have any questions, please feel free to ask (Preface them QUESTION: )
[15:17] <ClassBot> Vasudevan asked: Which is a faster way to update daily isos over a slow home dsl connection - apt-get dist-upgrade or download zsync version? Thanks.
[15:19] <phillw> Vasudevan: if you are UPDATING a running install,. use apt-get update && apt-get upgrade. The dist-upgrade is to go from, say, 12.10 to 13.04. Zysnc will refresh (or create) and ISO already on your system. They have different uses depending on the circumstances.
[15:19] <ClassBot> jlking3_ asked: So you manually compare the MD5 checksums?
[15:20] <ClassBot> There are 10 minutes remaining in the current session.
[15:21] <phillw> Vasudevan: if you use zsync to update an ISO, it will automatically do the md5sum check for you.
[15:22] <phillw> sorry that was for jlking3 :)
[15:24] <phillw> QUESTION : Thnaks, in terms of download which is faster - apt-get upgrade or zsync - over dsl conn?
[15:24] <phillw> Vasudevan: I've never compared them, so cannot answer that, sorry.
[15:25] <ClassBot> There are 5 minutes remaining in the current session.
[15:25] <phillw> apt-get update & upgrade for use on an already installed system, zsync is to get the ISO to install a system.
[15:28] <phillw> Thanks everyone for attending and for the questions. Happy testing :D
[15:29] <phillw> The next session start at 21:00 UTC / GMT, and it's me up 1st :)
[15:29] <phillw> https://wiki.ubuntu.com/Testing/Activities/Classroom/Saucy/
[15:30] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2013/06/24/%23ubuntu-classroom.html
[20:49] <varg1> کسی اینجا هست که فارسی بلد باشه و جواب من رو بده؟
[21:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2013/06/24/%23ubuntu-classroom.html following the conclusion of the session.
[21:00] <phillw> Hi everyone, my name is Phill. Whiteside and I'm the QA Team leader for lubuntu
[21:01] <phillw> This session is to briefly outline two systems of bug reporting with the development releases
[21:01] <phillw> Firstly, why report a bug?
[21:02] <phillw> For the testers, Often we are using the latest, unmodified alpha code for various projects during the development release
[21:02] <phillw> do NOT assume someone else will report a bug!
[21:03] <phillw> Another important thing to remember is that Discussing a bug on IRC, email, forum or facebook areas etc. does not raise a bug. The devs do not monitor those areas
[21:03] <phillw> By all means use them to discuss a problem. Once your discussion about the bug is at a stage where you can report it, then for it to be actioned by the devs you must raise a bug.
[21:03] <phillw> When 12.04 came along, it had added in an extra system for automated reporting of crashes.
[21:04] <phillw> It is still being enhanced.
[21:04] <phillw> But, there were blog reports of 'Canonical spying on your system', this is untrue.
[21:06] <phillw> The system that runs is called whoopsie and reports to launchpad and if you 'say yes' also to errors.ubuntu.com
[21:06] <phillw> it keeps an eye on your /var/crash area and if it sees something arrive, it springs into action
[21:07] <phillw> Apport actually writes the crash file to /var/crash and if the release being run is the development release of Ubuntu, the .crash files is submitted to Launchpad
[21:08] <phillw> it also looks out for .crash files as well. (i.e. not generated by apport).
[21:08] <phillw> Whoopise is an ongoing and active project. Fuller details all about it can be found at https://wiki.ubuntu.com/ErrorTracker
[21:09] <phillw> For most of running test cases, we will still use apport (ubuntu-bug)
[21:09] <phillw> going onto launchpad and manually creating a bug often results in a bug report that can not be actioned owing to a lack of information.
[21:09] <phillw> the best way to prevent this is to use the ubuntu-bug command.
[21:10] <phillw> For bugs that happen at install time, it can be a bit difficult to work out what to raise the bug against.
[21:10] <phillw> To this end, for testing of ISO's a quick list can be found at https://wiki.ubuntu.com/QATeam/Overview/Install_Bugs
[21:10] <phillw> So, if the error occurred whilst trying to install an iso, you would issue the command ubuntu-bug ubiquity
[21:11] <phillw> if you are testing an application, e.g. GClac and it failed, you would issue the command ubuntu-bug gcalc
[21:11] <phillw> using ubuntu-bug ensures that as much information relevant to the bug is obtained and put onto the bug report.
[21:11] <phillw> Again, there is a full explanation at https://wiki.ubuntu.com/Bugs/FindRightPackage
[21:11] <phillw> If you are unsure on what package to allocate a bug against, please feel free to ask on #ubuntu-bugs and one of the people there will be more than happy to assist.
[21:12] <phillw> incomplete bugs do take time up which could be better spent actually dealing with bugs.
[21:12] <phillw> Brian will be  holding  a session immediately after this introduction to explain this further.
[21:13] <phillw> by the way, please do feel to ask Questions, but I will get as much covered as I can, which should leave ~ 10 mins at the end for a Q & A session
[21:13] <phillw> Within the quality team, we have a brief section on the basics of bug reporting as it affects quality. This can be found at https://wiki.ubuntu.com/QATeam/Overview#Bugs
[21:14] <phillw> That's the basics covered, last time I ran this, there were a couple of questions - which I will now cover.
[21:15] <phillw> My bug goes to Private, what does it mean?
[21:15] <phillw> Usually, when a bug is marked "Private" there's some good reason for it.  With a lot of segfault (crash) bugs I see, a lot of them get marked as private, either because they contain information that *could* be private or could identify your system, or similar reasons
[21:15] <phillw> Typically, I see this with bugs which have core dumps or tracebacks which could contain information to identify someone: passwords, account numbers, etc. fall in the category of information that needs to be "removed" from the bug before it goes to a public view.
[21:15] <phillw> Those private bugs are therefore exactly what they are: hidden from the public eye until someone's gotten to it and actually looked through to see if there's anything that needs removal on those bugs, and then we usually make the bug visible after such things.
[21:16] <phillw> Also, The bot that goes looking for duplicated bugs does not worry if the bug it is using as master is private. If this happens please go to #ubuntu-bugs and raise it with them
[21:16] <phillw> What about reporting kernel bugs, could it be a duplicate?
[21:17] <phillw> For kernel bugs, *always* report a new one. It is difficult to say, a priori, if your affected system is *identical* with another in an already reported bug
[21:18] <phillw> There is a 3rd type of bug, in the test cases... This is to report an error in the test case (Typo, things out of order in the sequence etc).
[21:18] <phillw> on each test case, for example, http://iso.qa.ubuntu.com/qatracker/testcases/1301/info
[21:19] <phillw> it is not for reporting bugs found by using the test case, but only in the test case itself (these are written by humans, and we do make mistakes, even with over sight and proof reading :) )
[21:20] <ClassBot> There are 10 minutes remaining in the current session.
[21:20] <phillw> That sums up all I have to say, Brian will be following. Please feel free to ask questions
[21:25] <ClassBot> There are 5 minutes remaining in the current session.
[21:28] <phillw> Well, thanks for attending. I hope it was of use to you.... I'm never sure if no questions means I've covered it all - or scared everyone away :)
[21:30] <bdmurray> Hi, I'm Brian Murray an ubuntu developer and leader of the Ubuntu Bug Squad.
[21:30] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2013/06/24/%23ubuntu-classroom.html following the conclusion of the session.
[21:31] <bdmurray> I'd like to elaborate a bit more on what philw waid regarding reporting bugs.
[21:31] <bdmurray> ubuntu-bug is useful for reporting bugs about specific packages via the command 'ubuntu-bug' and the name of the package
[21:32] <bdmurray> However, sometimes you don't always know the name of the package.  Like what is the name of the package for the "Software Updater".
[21:33] <bdmurray> In that case you can use "ubuntu-bug -w" and then a dialog will appear indicating that you should click on the window for the problem application
[21:33] <bdmurray> apport will then gather information about your system and the application to add to a new bug report
[21:34] <bdmurray> Its also possible to use apport with symptoms for example if you are having an issue with an USB disk drive.  You can use 'ubuntu-bug storage'.
[21:34] <bdmurray> This will run through a series of tests to determine which package is the problem and then open a bug report about that package.
[21:35] <bdmurray> Additional symptoms live in /usr/share/apport/symptoms/ and include issues as vague as audio and display.
[21:36] <bdmurray> As you can see ubuntu-bug is a great help when reporting bugs, but is also a great help for us developers as detailed information about your system and specific information for the package is gathered.
[21:37] <bdmurray> However, having said that there is still one critical bit of information missing!  Detailed steps to recreate the bug report.
[21:37] <bdmurray> When I say detailed steps I really mean a list like
[21:37] <bdmurray> 1) click on the file menu
[21:37] <bdmurray> 2) choose print
[21:38] <bdmurray> 3) click on this other thing
[21:38] <bdmurray> 4) watch it explode!
[21:38] <bdmurray> This makes it easy for us to follow the same steps with little confusion
[21:38] <bdmurray> Additionally, an important part of the bug life cycle is having a bug confirmed
[21:39] <bdmurray> this also allows another Ubuntu user to come along and see your bug and follow the same steps you did and if they get the same result, confirm the bug report
[21:42] <bdmurray> It also helps for us to know how often the problem occurs.  Was it one in every ten attempts to scan something?
[21:42] <bdmurray> Or did it happen every single time?
[21:44] <bdmurray> I believe philw already mentioned this but is ususally best to open new bug reports rather than possibly adding additional issues to an existing bug report.
[21:44] <bdmurray> Having said that if you do find a bug that you think is about the same issue please mention it in the bug you are filing, either in the description or as an additional comment.
[21:46] <bdmurray> It is also important to know that every issue you may experience should be a separate bug report.  We don't want to hear about your printer and your DVD drvie in the same issue as they are unlikely to be related or be fixed with the same change.
[21:47] <ClassBot> balloons asked: does that mean I can use ubuntu-bug and say something like ubuntu-bug display or ubuntu-bug graphics if I'm having graphical issues, and ubuntu-bug audio for audio issues, etc?
[21:48] <bdmurray> balloons: yes, you can use 'ubuntu-bug display' to help you file a bug about graphic issues and the same is true for audio issues.
[21:48] <bdmurray> It's pretty neat, feel free to give a try, just don't send the bug to Launchpad!
[21:49] <bdmurray> (There will be a final confirmation dialog where you can review the details of the bug report.)
[21:49] <bdmurray> Let's say we've filed bug 1192332 and want to see what other bugs there are reported about update-manager
[21:50] <bdmurray> https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1192332
[21:50] <bdmurray> You can find them by clicking on update-manager (Ubuntu) in the "Affects" table
[21:50] <ClassBot> There are 10 minutes remaining in the current session.
[21:50] <bdmurray> Or by click on the word Bugs next to Code and Blueprints
[21:51] <bdmurray> Then you could review those new bug reports about the package and see if you can confirm them.
[21:51] <bdmurray> A bug can be confirmed when you can recreate the same issue.
[21:52] <bdmurray> You can confirm a bug by clicking the pencil next to "This bug affects you"
[21:52] <bdmurray> or by clicking the pencil next to the bugs status in the "Affects" table
[21:53] <bdmurray> You can learn more about confirming a bug here
[21:53] <bdmurray> http://www.youtube.com/watch?v=Vl-cQDAlPFc
[21:53] <bdmurray> Also keep in mind that bug reports can frequently be dialogs between developers and testers.
[21:54] <bdmurray> As such watch for additional requests for information or testing and reply promptly.
[21:55] <ClassBot> There are 5 minutes remaining in the current session.
[21:56] <bdmurray> Another part in the bug life cycle process is verifying that fixes actually work and as someone experiencing the issue you are in a good position to do that.  As I understand it that will be covered in the next section.
[21:56] <ClassBot> balloons asked: is there a recommended way to filter bugs against a package that one might be interested in? for example, I see 1700 bugs for update-manager at the moment.
[21:57] <bdmurray> I'd generally use the search box.  For example I was looking for configuration file prompts so I typed in 'conf file' in the dialog and clicked search and found some good results.
[21:57] <bdmurray> One can also filter on bug tags by clicking on advanced search
[21:58] <bdmurray> generally bugs are tagged with the release code name (e.g. saucy) so you could search for bugs affecting saucy
[21:58] <bdmurray> well really reported from saucy
[21:58] <bdmurray> any other questions?
[21:58] <bdmurray> I'm available in #ubuntu-bugs most of the time
[22:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2013/06/24/%23ubuntu-classroom.html following the conclusion of the session.
[22:00] <chilicuil> my name is Javier Lopez http://wiki.ubuntu.com/~chilicuil
[22:01] <chilicuil> this session will be practical so prepare your lp id and terminal =)
[22:01] <chilicuil> I made some slides, you can fetch them from: http://people.ubuntu.com/~chilicuil/pdf/sru-updates.pdf
[22:02] <chilicuil> if you have any question at any point feel free to ask in the #ubuntu-classroom-chat channel and I'll be glad to answer them
[22:02] <chilicuil> so, to begin
[22:03] <chilicuil> a SRU is a proposed update which has already been accepted in the ubuntu dev version and now is trying to make its way to a stable release (precise, quantal or raring)
[22:04] <chilicuil> not every update is candidate for SRU, to become a SRU an update needs to:
[22:04] <chilicuil>   * fix a severe regression
[22:04] <ClassBot> Slides for Verifying SRU updates: http://people.ubuntu.com/~chilicuil/pdf/sru-updates.pdf
[22:04] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2013/06/24/%23ubuntu-classroom.html following the conclusion of the session.
[22:04] <chilicuil>   * fix a program which loss user data
[22:05] <chilicuil>   * be simple and safe
[22:05] <chilicuil> this page summarize all the details: https://wiki.ubuntu.com/StableReleaseUpdates
[22:05] <chilicuil> so why stable ubuntu versions have a different policy?
[22:06] <chilicuil>  *stability*
[22:06] <chilicuil> in the past even one liner fixes have brought important issues, bugs #81125, #309674 and #559822 are some examples
[22:07] <chilicuil> so we're trying to ensure updates archived in -updates don't break everything =)
[22:07] <chilicuil> unfortunately, this policy has an issue
[22:08] <chilicuil> if no one actually test that a proposed update is good enough to get copied to stable releases, it could stay at -proposed starving for ever =(
[22:08] <chilicuil> a complete list of current -proposed updates can be found here: http://people.canonical.com/~ubuntu-archive/pending-sru.html
[22:09] <chilicuil> if you open the link, you'll see that there are updates for all stable releases, lucid, precise, quantal and raring
[22:10] <chilicuil> and once saucy get released, proposed updates will be visible there before any other place
[22:10] <chilicuil> blue and green updates are optimal to test
[22:11] <chilicuil> I'd like that we test a couple of them right now
[22:13] <chilicuil> you won't need many things, and it's relative easy to do
[22:13] <chilicuil> you'll require:
[22:13] <chilicuil> * any stable ubuntu release, I'll asume raring for this example
[22:14] <chilicuil>  * a lp account
[22:14] <chilicuil>  * optionally, pbuilder, virtualbox or a spare machine
[22:15] <chilicuil> there are chances that a proposed update could be really wrong and burn your machine, but tipically that's not the case
[22:15] <chilicuil> personally, I use pbuilder for testing cli applications and virtualbox for apps with a graphical interface
[22:17] <chilicuil> however, right now, I'll test directly on my main machine, since I've picked a safe update to test =P, and because I don't want to overcomplicate the example, learning pbuilder and virtualbox require a session for themselves
[22:17] <chilicuil> if you don't have a lp account you can create one in a couple of minutes: https://launchpad.net/+login
[22:18] <chilicuil> I'll wait here for those who don't have one =)
[22:22] <chilicuil> ok, I'll assume you've created a lp account, let's review some of the pending updates: http://people.canonical.com/~ubuntu-archive/pending-sru.html
[22:22] <chilicuil> as you can see, there are plenty of opportunities to help
[22:23] <chilicuil> for now I'd like that we could focus on software-properties, specifically bug #1047424
[22:23] <chilicuil> https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1047424
[22:24] <chilicuil> this report was opened to fix a problem with the additional drivers dialog
[22:24] <chilicuil> reports related to a sru are exceptional good, so it's generally easy to follow instructions
[22:25] <chilicuil> if they're not clear enough you can put a comment in the report and add the tag: 'verification-failed'
[22:25] <chilicuil> the 'test case' section is specially helpful so try to not overlook it
[22:26] <chilicuil> when a sru is requested, and it's accepted, members of the sru team, add the 'verification-needed' tag, our work as part of the QA team is to change those tags for 'verification-done' | 'verification-failed' depending of the result of our tests
[22:26] <chilicuil> before going further, I recommend to upgrade the system
[22:26] <chilicuil> $ sudo apt-get update && sudo apt-get upgrade
[22:27] <chilicuil> even if you use pbuilder or virtualbox, is generally a good idea to make sure we have the latest updates before testing any SRU
[22:28] <chilicuil> I'll give a couple of minutes for those who want to follow the live SRU testing session and need to update their machines
[22:29] <chilicuil> in the meantime, I'll talk more about the SRU reports
[22:30] <chilicuil> when you open a SRU report, you'll usually see these sections: [Impact], [Test case], [Regression potential], [Original description]
[22:31] <chilicuil> the Impact section refers to the main problem, why this SRU should be introduced to stable releases
[22:33] <chilicuil> the [Test case] sections usually have instructions step by step to reproduce the bug, it's a mandatory section, so you can be feel safe to find clear instructions
[22:34] <chilicuil> the [Regresssion potential] section list some issues who could appear after adding this update, the less the better
[22:35] <chilicuil> finally the [original section], well, it has the original post for reference
[22:36] <chilicuil> now, I'll asume we had enought time to update our systems, so we can look at the report #1047424 and see how if we can reproduce the bug
[22:37] <chilicuil> so the bug refers to a incorrect dialog after installing any driver using the software properties application
[22:38] <chilicuil> we'll launch the application by typing 'drivers' at the dash and selecting 'Software & Updates'
[22:39] <chilicuil> after opening it, we can click the latest tab 'Additional Drivers' and install or remove a driver, let's do it
[22:40] <chilicuil> you don't need to worry, we won't reboot our systems, so if you don't have a driver to install, remove one, we'll reinstall it before leaving the session
[22:41] <chilicuil> after selecting one driver we can press 'Apply changes', this will triage the installation|uninstalling process
[22:41] <chilicuil> after doing it, you'll see a 'Restart ...' button
[22:42] <chilicuil> a dialog asking for confirmation will appear, and it'll only have 'cancel' and 'shutdown' as options, that's the bug!
[22:42] <chilicuil> instead of asking for shutting down the system, it should ask for rebooting
[22:42] <chilicuil> so, we've confirmed the issue
[22:43] <chilicuil> so, once we've seen the bug, we'll apply the -proposed update
[22:43] <chilicuil> detailed instructions are here: https://wiki.ubuntu.com/Testing/EnableProposed
[22:44] <chilicuil> the fastest to do it IMO is to modify /etc/apt/sources.list
[22:44] <chilicuil> so, if you don't feel like reading the wiki right now, you can trust me and run:
[22:44] <chilicuil> $ echo 'deb http://mx.archive.ubuntu.com/ubuntu/ raring-proposed main restricted multiverse universe' | sudo tee /etc/apt/sources.list.d/proposed.list
[22:45] <chilicuil> that command will create a file in /etc/apt/sources.list.d/proposed.list with the following 'deb http://mx.archive.ubuntu.com/ubuntu/ raring-proposed main restricted multiverse universe'
[22:46] <chilicuil> apt uses those files to know from where to pull software
[22:46] <chilicuil> after adding the proposed repository the system needs to update the index and apply the updates
[22:46] <chilicuil> $ sudo apt-get update && sudo apt-get install software-properties-gtk
[22:47] <chilicuil> those commands will download the new index and after that will update the software-properties-gtk program, sudo apt-get install can install or update (if the package is already installed)
[22:48] <chilicuil> after completing the last step, it's time to retry the dialog
[22:49] <chilicuil> close the 'Software & Updates'
[22:49] <chilicuil> program
[22:49] <chilicuil> and then open it again, go the driver tab and renable the uninstalled driver
[22:50] <ClassBot> There are 10 minutes remaining in the current session.
[22:50] <chilicuil> one hint to know that you applied correctly the update is that after executing sudo apt-get install software-properties-gtk you should see your computer downloading a package from -proposed
[22:51] <chilicuil> if you don't see it, something went wrong, and you should review your /etc/apt/sources.list.d/proposed.list file
[22:52] <chilicuil> so, once you've applied the proposed update, you need to follow the test case steps and ensure the issue has gone
[22:53] <chilicuil> if you are following this example, you should see that after applying the driver installation and selecting the 'Restart...' button you'll see this time a dialog with two buttons, 'cancel' and 'reboot'
[22:53] <chilicuil> the -proposed update works!
[22:54] <chilicuil> that's it, that's exactly what SRU testing is about
[22:54] <chilicuil> so, once we've tested and confirm that the proposed update fixes the reported issue, we can add comments, those who completed the sru testing, please do so
[22:55] <ClassBot> There are 5 minutes remaining in the current session.
[22:55] <chilicuil> something like, 'the proposed update work in Ubuntu raring amd64' should be enough
[22:55] <chilicuil> and don't forget to add the appropiate tag, in this case, 'verification-done'
[22:57] <chilicuil> after completing all these steps a member of the SRU team will review the report and probably will copy the -proposed update to -update, after that, a lot of people will improve its Ubuntu experience
[22:58] <chilicuil> if have any problem while doing SRU testing feel free to ping me, or to join #ubuntu-quality
[22:58] <chilicuil> if you*
[22:58] <chilicuil> I think that's all, any question?
[22:59] <chilicuil> thanks Skini151, you rock!
[23:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2013/06/24/%23ubuntu-classroom.html


[13:16] <ardaguclu> Hello, I have some questions about snapd project structure. Where is the most appropriate place for this?, should I ask via forum or here?. Thanks