| futurama141 | ok | 02:25 |
|---|---|---|
| unop | ok | 02:25 |
| unop | right, what does the fdisk prompt say now? | 02:26 |
| unop | Command (m for help): ? | 02:26 |
| futurama141 | root@phlak | 02:26 |
| futurama141 | Last cylinder or +size or +sizeM or +sizeK (358-5169, default 5169): 5169 | 02:26 |
| futurama141 | Command (m for help): t' | 02:26 |
| futurama141 | Partition number (1-4): 1 | 02:26 |
| futurama141 | Hex code (type L to list codes): 83 | 02:26 |
| futurama141 | Command (m for help): t | 02:26 |
| futurama141 | Partition number (1-4): 2 | 02:26 |
| futurama141 | Hex code (type L to list codes): 82 | 02:26 |
| mika_videodev | futurama141: Do you really have bad sectors on your hard disk, or was oinck just joking about it ? | 02:26 |
| futurama141 | Changed system type of partition 2 to 82 (Linux swap / Solaris) | 02:26 |
| futurama141 | Command (m for help): | 02:26 |
| futurama141 | root@Phlak:~# | 02:27 |
| futurama141 | root@Phlak:~# p | 02:27 |
| futurama141 | -bash: p: command not found | 02:27 |
| futurama141 | root@Phlak:~# Partition number (1-4): 3 | 02:27 |
| futurama141 | -bash: syntax error near unexpected token `(' | 02:27 |
| futurama141 | root@Phlak:~# First cylinder (358-5169, default 358): 358 | 02:27 |
| futurama141 | -bash: syntax error near unexpected token `(' | 02:27 |
| futurama141 | i dont know!! | 02:27 |
| unop | futurama141, hmm, for some reason fdisk's quit and gone back to the shell | 02:28 |
| futurama141 | so what do i do? | 02:28 |
| unop | futurama141, what does this command give you? fdisk -l /dev/hda # or whatever your disk is | 02:28 |
| unop | mika_videodev, we can use fsck to check the swap partition - then zero it out again | 02:28 |
| mika_videodev | futurama141: Ok, if you did not mention anything about bad sectors first, then it was just oinck joking. In that case you can forget everything about bad sectors. | 02:28 |
| mika_videodev | unop: can you really use fsck to check a swap partition, or do you mean you need to first change it to a linux partition, then chechk, and fionally change back to swap partition ? | 02:29 |
| unop | mika_videodev, the latter | 02:30 |
| unop | futurama141, you still there? | 02:31 |
| mika_videodev | try cfdisk, it is easier to use | 02:31 |
| futurama141 | yea | 02:31 |
| futurama141 | i have no clue | 02:31 |
| unop | futurama141, copy and paste the output of that command. | 02:31 |
| mika_videodev | futurama141: cfdisk /dev/hda | 02:31 |
| futurama141 | it wont | 02:31 |
| futurama141 | it wont paste | 02:31 |
| unop | futurama141, ok, never mind that then. do what mika_videodev suggested | 02:32 |
| mika_videodev | well, if fdisk for some reason was interrupted before a normal write and quit, I guess it did not save any of it's changes, and the partition table is in whatever state it was before starting to use fdisk | 02:32 |
| unop | mika_videodev, it's plausible that fdisk was manuall interrupted too | 02:33 |
| unop | manually* | 02:33 |
| mika_videodev | and: if you have the ubuntu's install iso somewhere, it may be wiser to save it to an existing partition (you may format it but do not delete and re-create) | 02:33 |
| futurama141 | burn ubuntu iso to cd in phlak: help please? | 02:34 |
| mika_videodev | formatting with mke2fs can also check for bad sectors if you suspect there are some (but it needs an option to do that) | 02:34 |
| futurama141 | wait, how do i install gparted? | 02:35 |
| mika_videodev | for that to work, you either need 2 optical drives (one for phlak, one that can write to a cd-r) | 02:35 |
| mika_videodev | or else, you must load the plack to ramdisk | 02:35 |
| unop | futurama141, you said you had no CDs | 02:35 |
| futurama141 | i dont | 02:35 |
| unop | futurama141, so how can you burn the ISO then? | 02:36 |
| futurama141 | nevermind | 02:36 |
| mika_videodev | i would do that witk k3b, but it is possible to do it with just a command line tool as well.... | 02:36 |
| unop | futurama141, come on make up your mind, we haven't got time for indecision. what do you want to do? | 02:36 |
| futurama141 | i only have one OD | 02:36 |
| unop | futurama141, do you want to continue formatting the disk? | 02:36 |
| futurama141 | i want to get the hard drive formatted | 02:36 |
| mika_videodev | check what partition(s) do you have right now on the hard disk before deciding what to do | 02:37 |
| futurama141 | new terminal | 02:37 |
| futurama141 | sudo -i | 02:37 |
| unop | futurama141, ok, follow mika_videodev .. he'll help you with cfdisk | 02:37 |
| mika_videodev | you can format with mke2fs if you don't need to modify partition sizes | 02:37 |
| futurama141 | i dont know what that is, but ok | 02:37 |
| futurama141 | i dont know if i have any partitions | 02:37 |
| unop | mika_videodev, just create three partitions .. one for the ISO to be placed, one for swap and another for / | 02:38 |
| mika_videodev | mke2fs is a tool with what you can format already existing partitions | 02:38 |
| mika_videodev | fdisk -l will tell you, but not modify anything | 02:38 |
| mika_videodev | it wil also tell you the size of the hard disk | 02:38 |
| futurama141 | ok how to i copy and paste text from the terminal? | 02:38 |
| mika_videodev | futurama141: didn't you already do some copy&paste with the mouse ? | 02:40 |
| futurama141 | oh! | 02:40 |
| futurama141 | i did, but i didnt know how i did it | 02:40 |
| futurama141 | i figured it out | 02:40 |
| futurama141 | ok, check this... | 02:40 |
| futurama141 | (root@Phlak)(6/ttyp0)(04:40pm:08/31/08)- | 02:40 |
| futurama141 | (#:~)- sudo -i | 02:40 |
| futurama141 | root@Phlak:~# fdisk -l | 02:40 |
| futurama141 | Disk /dev/hdc: 40.0 GB, 40020664320 bytes | 02:40 |
| futurama141 | 240 heads, 63 sectors/track, 5169 cylinders | 02:40 |
| futurama141 | Units = cylinders of 15120 * 512 = 7741440 bytes | 02:40 |
| futurama141 | Device Boot Start End Blocks Id System | 02:40 |
| futurama141 | /dev/hdc1 * 1 5168 39070048+ 7 HPFS/NTFS | 02:40 |
| futurama141 | root@Phlak:~# | 02:40 |
| mika_videodev | oh, you have one gigantic partition of NTFS type covering all of the disk space (NTFS = used in win 2000, XP and possibly vista) | 02:41 |
| mika_videodev | And you are ok to delete all data on that win XP partition ? | 02:42 |
| futurama141 | yes | 02:42 |
| mika_videodev | in that case, I'd first try to test this: mke2fs -c /dev/hdc1 (note: some more options may need to be used too... !) | 02:43 |
| futurama141 | root@Phlak:~# mke2fs -c /dev/hdc1 | 02:43 |
| futurama141 | mke2fs 1.36 (05-Feb-2005) | 02:43 |
| futurama141 | /dev/hdc1 is mounted; will not make a filesystem here! | 02:43 |
| futurama141 | root@Phlak:~# | 02:43 |
| mika_videodev | you need to first umount /dev/hdc1 | 02:44 |
| futurama141 | root@Phlak:~# unmount /dev/hdc1 | 02:45 |
| futurama141 | -bash: unmount: command not found | 02:45 |
| futurama141 | root@Phlak:~# | 02:45 |
| unop | umount | 02:45 |
| futurama141 | ok | 02:45 |
| futurama141 | root@Phlak:~# umount /dev/hdc1 | 02:45 |
| futurama141 | root@Phlak:~# | 02:45 |
| unop | it's now unmounted | 02:46 |
| mika_videodev | ok ... | 02:46 |
| mika_videodev | now: if you suspect there may be bad sectors: try this: ... | 02:46 |
| futurama141 | idk | 02:46 |
| mika_videodev | mke2fs -c -j -m 1 - L somename /dev/hdc1 | 02:47 |
| mika_videodev | or, if you are quite SURE there are bad sectors, then ... | 02:47 |
| futurama141 | somename? | 02:47 |
| mika_videodev | otherwise same, but mke2fs -c -c -j ... | 02:47 |
| unop | futurama141, somename is the label you want to assign for the partition | 02:47 |
| mika_videodev | you can put there whatever name you want to give your partition | 02:47 |
| mika_videodev | if you think it is very likely / sure there ARE bad sectors, then it's a good idea to put that -c there twice. It is slower, but will check the disk more carefully for bad sectors | 02:48 |
| futurama141 | root@Phlak:~# mke2fs -c -j -m 1 - L barf /dev/hdc1 | 02:48 |
| futurama141 | mke2fs 1.36 (05-Feb-2005) | 02:48 |
| futurama141 | mke2fs: bad blocks count - L | 02:48 |
| futurama141 | root@Phlak:~# | 02:48 |
| unop | futurama141, you have a space between - and L there | 02:49 |
| unop | mika_videodev, and why adjust -m .. 5% is good | 02:49 |
| mika_videodev | uop, do you have any idea why it answers like "mke2fs: bad blocks count - L" - ??? | 02:49 |
| unop | mika_videodev, the command wasn't entered in right | 02:50 |
| mika_videodev | yes, you can put -m 5 also if you like. It just tells how many % is reserved for the root user only | 02:50 |
| mika_videodev | oh, it should be -L with NO space ... | 02:50 |
| unop | mika_videodev, yes, and 5% is a good default .. it allows you to recover the system with ease should your disk get filled up | 02:50 |
| unop | mika_videodev, and since this is his system - leave the defaults be | 02:51 |
| mika_videodev | futurama141, for general use, unop is correct. I just copied the line I used to format additional partitions for video usage ... | 02:51 |
| mika_videodev | futurama141: in that case mke2fs -c -j -L barf /dev/hdc1 would be fine | 02:52 |
| mika_videodev | but how can the amount of system RAM be checked ? | 02:53 |
| mika_videodev | unop: are you aware of some way to force the kernel reread the partition table and immediately switch to use the version just read ? | 02:54 |
| unop | mika_videodev, errm, no | 02:55 |
| unop | heh.. he's left - just great | 02:55 |
| mika_videodev | futurama141: if you have 3 people standing behind you and have no CD-R's (but do have a CD or DVD writer), why not send someone shopping for a CD-R ? | 02:55 |
| unop | mika_videodev, he's gone | 02:56 |
| mika_videodev | unop: seems so. But if there is such a command to the kernel, I'd like to know about it too ! | 02:56 |
| unop | mika_videodev, I'm not aware of a way .. but i presume if you can umount all filesystems, you should be able to make changes to partitions then remount them -- might struggle with / tho | 02:58 |
| mika_videodev | I don't understand why such a comman does not exist. It could be implemented so, that mounted partitions stay as they are, and prevent the space occupied by them to be uses as another partition that overlpas the space, but is not exactly the same partition, possibly just with different ordinal number. | 02:58 |
| unop | mika_videodev, all this in runlevel 1 off course | 02:58 |
| mika_videodev | For example the makers of gparted argued about this, but the kernel folks just decided to ignore the matter | 02:59 |
| unop | mika_videodev, well, i'd say it wouldn't be safe for you to adjust partition boundaries without first unmounting the filesystems on them .. because the kernel could be accessing a set of files in the area of disk you are modifying and you wouldn't want it to panic on you. | 03:01 |
| unop | in any case .. the need for something like this is trivial, and you can always do something similar by booting the system offline or in recovery mode | 03:02 |
| mika_videodev | of course, it is better to NOT delete/modify a partition that is mounted. But outside of the area occupied by any mounted partitions, there is no reason to prevent modifying / adding / deleting other (not mounted) partitions. | 03:03 |
| batbuyan | hello | 03:27 |
| batbuyan | test message | 03:27 |
| Socceroos | test message received. | 03:30 |
| Socceroos | yep, its working on my end. | 03:30 |
| Socceroos | :D | 03:30 |
| === dholbach changed the topic of #ubuntu-classroom to: Ubuntu Classroom || https://wiki.ubuntu.com/Classroom || https://lists.ubuntu.com/mailman/listinfo/Ubuntu-classroom || Next Event: Ubuntu Developer Week: https://wiki.ubuntu.com/UbuntuDeveloperWeek | Questions about the presentation in #ubuntu-classroom-chat (prefix with QUESTION: ...) | ||
| === Socceroos is now known as Socceroos_work | ||
| === EdwinMoore is now known as EdwinMoore_ | ||
| === EdwinMoore_ is now known as curdsy | ||
| === curdsy is now known as EdwinMoore | ||
| === buunso is now known as buunso_ | ||
| === buunso_ is now known as buunso | ||
| === e-jat is now known as fendora | ||
| === fendora is now known as e-jat | ||
| === e-jat is now known as fenris- | ||
| === tm_work is now known as themoler | ||
| === dholbach_ is now known as dholbach | ||
| === thekorn_ is now known as thekorn | ||
| === ALAY1 is now known as ALAYA | ||
| === krazyd__ is now known as krazyd | ||
| === krazyd___ is now known as krazyd | ||
| evo | exit | 14:33 |
| ahmadtarek | \join #ubuntu-classroom-chat | 15:02 |
| === thekorn_ is now known as thekorn | ||
| tacone | @schedule rome | 15:11 |
| === krazyd___ is now known as krazyd | ||
| Myrtti | woooooo | 15:31 |
| dholbach | welcome everybody - 1h25m to go until the first session! :-) | 15:33 |
| pleia2 | :) | 15:36 |
| sianis | dholbach: I'm ready :P | 15:38 |
| jscurtu | me too... just 2 more hours | 15:38 |
| * popey hugs dholbach | 15:41 | |
| * dholbach hugs popey back | 15:41 | |
| popey | \o/ | 15:42 |
| * Sulabh pokes bibstha | 15:48 | |
| Myrtti | silly developers. hugs are for bug testers. | 15:56 |
| * popey is weary of hugging Myrtti | 15:57 | |
| === dholbach changed the topic of #ubuntu-classroom to: Ubuntu Classroom || https://wiki.ubuntu.com/Classroom || https://lists.ubuntu.com/mailman/listinfo/Ubuntu-classroom || Next Event: Ubuntu Developer Week: https://wiki.ubuntu.com/UbuntuDeveloperWeek | Questions about the presentation in #ubuntu-classroom-chat (prefix with QUESTION: ...) | Run date -u to find out what UTC time is right now | ||
| sakjur | date -u | 16:01 |
| sakjur | whoops! | 16:01 |
| nellery | run in terminal ;) | 16:01 |
| gaspa | lun set 1 14:58:53 UTC 2008 | 16:01 |
| sakjur | nellery: Yeah... | 16:01 |
| sakjur | Understood it after a while :P | 16:01 |
| === fschrat is now known as fnordschrat | ||
| === fnordschrat is now known as fschrat | ||
| === emgent is now known as emgent`NL | ||
| === fschrat is now known as fnordschrat | ||
| ti4mi | date -u | 16:24 |
| jpds | Mon Sep 1 15:24:17 UTC 2008 | 16:24 |
| cupe^ | uname -a | 16:26 |
| Iulian | No output? | 16:26 |
| cupe^ | No output. :( | 16:27 |
| cupe^ | date -R | 16:27 |
| laga | Linux h1079978 2.6.15-51-server #1 SMP Tue Feb 12 17:12:18 UTC 2008 i686 GNU/Linux | 16:27 |
| cupe^ | Linux fuck 2.6.26-ARCH #1 SMP PREEMPT Tue Aug 26 21:15:43 UTC 2008 i686 AMD Athlon(tm) 64 X2 Dual Core Processor 5600+ AuthenticAMD GNU/Linux | 16:28 |
| cupe^ | \o/ | 16:28 |
| jrib | clever hostnames... | 16:28 |
| cupe^ | Yeah | 16:28 |
| DanielRM | Why are you spamming the output of uname -a? | 16:29 |
| cupe^ | I can't consider one post spam. | 16:31 |
| mcas | date -u | 16:37 |
| mcas | sorry | 16:37 |
| CShadowRun | mcas sorry, i'm taken. | 16:38 |
| CShadowRun | (but there are plenty of fish in the sea) | 16:39 |
| DanielRM | CShadowRun: -_- | 16:39 |
| CShadowRun | :D | 16:39 |
| DanielRM | CShadowRun: can't you get back to playing WoW unfairly? :P | 16:39 |
| CShadowRun | i only did that as a proof of concept :p | 16:40 |
| DanielRM | cupe^: collectively when it's a semi-large amount of output, though... | 16:40 |
| CShadowRun | i'm messing with python again now :D | 16:40 |
| DanielRM | Anyway, as jpds said, on-topic here. | 16:40 |
| DanielRM | Back to -uk for off-topicness. | 16:40 |
| popey | there is #ubuntu-classroom-chat too | 16:40 |
| Oli`` | But even that should stay mildly on-topic, no? | 16:42 |
| Oli`` | I thought it was the place to ask relevant questions, send notes behind the teacher's back, etc.. | 16:42 |
| cupe^ | :D | 16:43 |
| xander21c | Hello | 16:52 |
| popey | yeah, there's usually a bit of chat/banter in -chat | 16:52 |
| Tm_T | hckoe: ircing as root? | 16:57 |
| dholbach | so how are you all doing? everybody excited? :-) | 16:57 |
| Tm_T | dholbach: very (:) | 16:57 |
| soulhacker | yup | 16:58 |
| Raeknouhl | yes^^ | 16:58 |
| cupe^ | Yeah | 16:58 |
| * nxvl waves | 16:58 | |
| xander21c | dholbach +1 | 16:58 |
| wobblywu | i'm just here for the free soda | 16:58 |
| cupe^ | Have no idea what will happen though | 16:58 |
| cupe^ | But sounds like fun | 16:58 |
| jscurtu | yeah... | 16:58 |
| dholbach | :-) | 16:58 |
| * daradib is ready for the excitement | 16:58 | |
| tacone | \o.o | 16:58 |
| dholbach | a thunderstorm is coming up here... let's hope it will not kick me out of the net ;-) | 16:59 |
| bullgard4 | neither me nearby | 16:59 |
| dholbach | hi bullgard4 | 16:59 |
| dholbach | Ok my friends.... are you ready for another Ubuntu Developer Week? | 16:59 |
| dholbach | let's get cracking :-) | 17:00 |
| Tm_T | dholbach: YES! | 17:00 |
| * Tm_T hides | 17:00 | |
| sianis | YES | 17:00 |
| jscurtu | yep | 17:00 |
| techno_freak | dholbach, YES, rock on! | 17:00 |
| chienchouchen | yes! | 17:00 |
| soulhacker | get it on!! | 17:00 |
| dholbach | Some people might know me already, I'm Daniel Holbach, living in Berlin, Germany and always had a lot of love for the MOTU team, and work for Canonical for ~3 years now. | 17:00 |
| pedro_ | wooohoooo! | 17:00 |
| dholbach | I'll try to answer a few of the regular Developer Week questions beforehand | 17:01 |
| Myrtti | wooooo | 17:01 |
| dholbach | the schedule is up here: https://wiki.ubuntu.com/UbuntuDeveloperWeek - and please use 'date -u' (in the terminal) to find out which UTC time we have right now :) | 17:01 |
| dholbach | questions go into #ubuntu-classroom-chat, please prefix them with QUESTION: | 17:02 |
| dholbach | I'll take a look over there and copy them all over every once in a while | 17:02 |
| dholbach | let's try not to have too many disturbances in the session itself | 17:02 |
| dholbach | OK... who's here for the "Packaging 101" session? :-) | 17:02 |
| * dholbach expects a lot of raised hands | 17:02 | |
| cupe^ | I am | 17:02 |
| tacone | \o | 17:02 |
| sianis | I am | 17:03 |
| === hckoe_ is now known as hckoe | ||
| jscurtu | ME! | 17:03 |
| chienchouchen | i am | 17:03 |
| * techno_freak raises hand | 17:03 | |
| cupe^ | o/ | 17:03 |
| * daradib raises hand | 17:03 | |
| Myrtti | _o/ | 17:03 |
| Raeknouhl | here | 17:03 |
| cupe^ | \o/ | 17:03 |
| * jrib | 17:03 | |
| soulhacker | me me | 17:03 |
| * qense is partially here! | 17:03 | |
| * Oli`` raises both hands | 17:03 | |
| DoruHush | me | 17:03 |
| * Shunpike raises hand | 17:03 | |
| * jpds too. | 17:03 | |
| stefanlsd | here! | 17:03 |
| Iulian | Ay | 17:03 |
| ed_agemo | me too | 17:03 |
| * kevjava raises hands sheepishly. | 17:03 | |
| weefred | here! | 17:03 |
| didrocks | even though I will not be present o/ :) | 17:03 |
| * xander21c raisees hand | 17:03 | |
| raseel | Me | 17:03 |
| evolvedlight_bet | hello! | 17:03 |
| dholbach | excellent... I'm very excited and very happy you're all here | 17:04 |
| dholbach | just to make clear what you can expect during the session | 17:04 |
| dholbach | in this session we're not going to package something from scratch, instead I'll talk you through the bare-bone structure of a package, so the stuff that makes a package build and you will encounter in almost all packages | 17:04 |
| dholbach | I'll try to answer as many questions as possible | 17:05 |
| dholbach | for more info, I'd recommend https://wiki.ubuntu.com/MOTU/GettingStarted | 17:05 |
| dholbach | and of course http://youtube.com/ubuntudevelopers | 17:05 |
| dholbach | ok... let's get started | 17:05 |
| dholbach | please all install the devscripts package | 17:05 |
| dholbach | sudo apt-get install devscripts | 17:05 |
| dholbach | it contains tools we need for packaging and that make your life a lot lot easier | 17:06 |
| dholbach | afterwards, please get the source package we're going to look at together today | 17:06 |
| dholbach | dget http://daniel.holba.ch/motu/hello-debhelper_2.2-2.dsc | 17:06 |
| dholbach | if I'm too fast or something doesn't work or I'm unclear, please ask in #ubuntu-classroom-chat | 17:07 |
| dholbach | if you look at the downloaded files you will notice there's a .dsc a .diff.gz and a .orig.tar.gz | 17:07 |
| dholbach | it's the first thing you'll notice: we're not talking about .deb files (binary packages), but source packages | 17:08 |
| dholbach | when you start doing ubuntu development, you will always deal with those kind of files, so let's take a closer look | 17:09 |
| dholbach | the .orig.tar.gz is the original unmodified source code tarball that was released on the homepage of the upstream developers (software authors) | 17:09 |
| dholbach | the .diff.gz is the compressed patch we apply to make it build "our way" | 17:09 |
| dholbach | what does "our way" mean? | 17:09 |
| dholbach | we need to add a bunch of instructional files to be able to apply ONE build process to all kinds of source packages (no matter if they are python, PHP, C, C++, etc) | 17:10 |
| dholbach | <Myrtti> dscverify: can't find any Debian keyrings | 17:10 |
| dholbach | you can safely ignore that warning | 17:11 |
| dholbach | now please run | 17:11 |
| dholbach | dpkg-source -x hello-debhelper_2.2-2.dsc | 17:11 |
| dholbach | dpkg-source will then extract the tarball and apply our patch | 17:11 |
| dholbach | the .dsc file is used to check the md5sum and so on (it contains a bit of meta-data about the source package) | 17:11 |
| dholbach | <raseel> QUESTION : we need to add a bunch of instructional files to be able to apply ONE build process to all kinds of source packages. Could you elaborate this please ? | 17:12 |
| dholbach | raseel: some of you might have tinkered with ./configure; make; sudo make install when building software from source | 17:12 |
| raseel | yes | 17:12 |
| dholbach | this applies to most of the packages that use the auto tools (automake, autoconf, etc) | 17:12 |
| dholbach | but there's lot of other cases, for example python packages that use distutils need python setup.py build, python setup.py install etc | 17:13 |
| dholbach | some packages don't have an upstream build system at all, but just contain a few files that need to be shipped | 17:13 |
| === duluu is now known as mazaalai | ||
| dholbach | I'll get to the "Makefile" part of the source package in a bit, basically we expect a few Makefile targets (clean, install, etc) to be around, so all packages can be built "in the same way" | 17:14 |
| dholbach | ok, let's get cracking and dive in | 17:15 |
| dholbach | cd hello-debhelper-2.2 | 17:15 |
| dholbach | and check out debian/changelog | 17:15 |
| dholbach | debian/changelog has a very strict format you need to adhere to | 17:15 |
| dholbach | fortunately there's the dch tool in devscripts that makes the task easier | 17:16 |
| dholbach | each upload specifies: the name of the source package, the revision, the part of Ubuntu (or Debian) it is uploaded too, the changelog entry text itself and who made the particular upload | 17:17 |
| dholbach | (plus the timestamp) | 17:17 |
| dholbach | whenever you work on packages you need to put some good effort into making it clear WHAT you changed and WHY | 17:17 |
| dholbach | in Ubuntu we maintain all packages a one big team, therefore the next uploader should not have to guess where you got a patch from, why it was applied and the tricky conditions under which you made a package build :-) | 17:18 |
| dholbach | let's take a look at the topmost entry | 17:18 |
| dholbach | the upload has the revision number 2.2-2 and was uploaded to "unstable" | 17:18 |
| dholbach | 2.2 (the part in front of the dash) means: this is the upstream release that was packaged | 17:19 |
| dholbach | (remember the hello-debhelper_2.2.orig.tar.gz which basically said: these are the unmodified changes that upstream released as 2.2 on their homepage) | 17:19 |
| dholbach | <raseel> QUESTION : Does the debian/changelog file exist for only Debian packages ? | 17:19 |
| dholbach | good question | 17:19 |
| dholbach | no... whenever we make a change in Ubuntu we describe our changes in the same file | 17:20 |
| dholbach | what changes is the version number | 17:20 |
| dholbach | if I was to change a tiny bit in the package, I'd upload 2.2-2ubuntu1 | 17:20 |
| dholbach | which would mean: | 17:20 |
| dholbach | - 2.2 was released upstream | 17:20 |
| dholbach | - 2 revisions have been made in Debian | 17:20 |
| dholbach | - 1 in Ubuntu | 17:20 |
| dholbach | then I'd forward my change to the Debian maintainer, he'd incorporate it in | 17:21 |
| dholbach | 2.2-3 | 17:21 |
| dholbach | and we could "sync" the package from Debian again | 17:21 |
| dholbach | <tacone> QUESTION: so ubuntu counter gets resetted after each debian release ? | 17:21 |
| dholbach | tacone: "resetting the counter" would mean: overwriting all Ubuntu changes with the changes that have happened in Debian | 17:22 |
| dholbach | if you decide to do that you need to be V E R Y careful | 17:22 |
| dholbach | and when I say very, I mean | 17:22 |
| dholbach | 17:22 | |
| dholbach | __ _____ _ __ _ _ | 17:22 |
| dholbach | \ \ / / _ \ '__| | | | | 17:22 |
| dholbach | \ V / __/ | | |_| | | 17:22 |
| dholbach | \_/ \___|_| \__, | | 17:22 |
| dholbach | |___/ | 17:22 |
| raseel | :-D | 17:22 |
| dholbach | if you're not careful enough you might drop other small bits that were important to Ubuntu users and might be a regression | 17:23 |
| dholbach | so in cases where we're not able to sync straight-away (different opinions of maintainers, upstream, etc) we need to merge | 17:23 |
| dholbach | <raseel> QUESTION:And if it is NOT a Debian package ? | 17:23 |
| dholbach | raseel: can you elaborate? | 17:23 |
| dholbach | raseel: you mean if we inherited a package from "some other place"? | 17:23 |
| raseel | yes | 17:24 |
| dholbach | we'd still add "ubuntu1" to the version string to indicate that we did an Ubuntu-local change | 17:24 |
| dholbach | in cases where there are no "ubuntu<n>" revisions the sync happens automatically at the beginning of the release schedule | 17:24 |
| dholbach | <tacone> QUESTION: then I don't understand. If debian releases 2.2-3 which number shall my next release (for ubunt) have ? | 17:25 |
| dholbach | tacone: if you need to merge, it'd be 2.2-3ubuntu1 | 17:25 |
| dholbach | (carry over important Ubuntu changes) | 17:25 |
| dholbach | <qense> NEW QUESTION: Isn't this a bit weird? If I'm right this means that 2.2-2ubuntu1 could be exactly the same as 2.2-3. | 17:25 |
| dholbach | qense: it could, you need to make sure that it IS exactly the same | 17:25 |
| dholbach | <jscurtu> QUESTION: What if you take a source from SuSE, would that work? | 17:25 |
| dholbach | jscurtu: no, the build process is different there | 17:25 |
| dholbach | <techno_freak> QUESTION: what does 0ubuntu1 mean? | 17:25 |
| dholbach | it means we introduced a new upstream version in Ubuntu before we got it from Debian | 17:26 |
| dholbach | ok... let's move on, just 31m left :) | 17:26 |
| dholbach | I hope the concept of debian/changelog is almost clear now - if not, the other sessions this week of the Packaging Guide will enlighten you :) | 17:26 |
| dholbach | let's take a look at debian/control together | 17:27 |
| dholbach | you will see that it consists of two stanzas (at least two, two now because it's a simple package) | 17:27 |
| dholbach | the first one is about the Source package, the following one(s) are about binary package(s) | 17:27 |
| dholbach | a source package needs a name, a section and a maintainer | 17:28 |
| dholbach | the Standards-Version gives us a clue which version of the Debian Policy (THE document if you need to know about packaging rules) the package complies with | 17:28 |
| dholbach | and a very very intersting other bit: Build-Depends | 17:28 |
| dholbach | Build-Depends means: this is the bare minimum of packages that are required to build the package | 17:29 |
| dholbach | what happens if I upload a revision to the build daemons (soyuz) is: | 17:29 |
| dholbach | the will extract the package (just like we did), copy it into a minimal build environment (chroot containing build-essential which gives us make, etc), then install the build-depends | 17:30 |
| dholbach | and then attempt to build it | 17:30 |
| dholbach | in this case only debhelper is required (of a version >= 5) | 17:30 |
| dholbach | let's take a look at the second stanza | 17:30 |
| dholbach | it describes the resulting binary packages (all files that are going to be installed into the package go into one package) | 17:31 |
| dholbach | it has a package name and description (that turns up in synaptic, adept, etc) | 17:31 |
| dholbach | and two interesting bits: Architecture and Depends | 17:31 |
| dholbach | Depends is easy to explain: it's the binary packages this resulting binary packages requires to be installed | 17:32 |
| dholbach | ${shlibs:Depends} is just a bit incomprehensible | 17:32 |
| dholbach | if you run this on a terminal | 17:32 |
| dholbach | apt-cache show hello-debhelper | grep ^Depends | 17:32 |
| dholbach | you will get something like this: | 17:33 |
| dholbach | Depends: libc6 (>= 2.5-0ubuntu1) | 17:33 |
| dholbach | this means the hello-debhelper package that is in the archive needs libc6 to be installed | 17:33 |
| dholbach | the process how we get from ${shlibs:Depends} to libc6 is very interesting and I can only briefly explain it here | 17:33 |
| dholbach | basically the build process will figure out which shared libraries the binaries (stuff in /usr/bin/ or /usr/lib/ etc) in our package are linked against and which package they are in | 17:34 |
| dholbach | and substitute ${shlibs:Depends} with the right dependencies | 17:34 |
| dholbach | this is a very very awesome piece of voodoo that happens automatically during the build :) | 17:35 |
| dholbach | "Architecture: any" means build this source package individually on all the available architectures in the data center | 17:35 |
| dholbach | in the data center we have supported architectures like amd64 and i386 and community ports like powerpc, sparc, hppa, ia64, lpia, etc | 17:36 |
| dholbach | if you build C source for example you want the source to be built on each and every architecture individually | 17:36 |
| dholbach | if you use "Architecture: all" it will mean: this package can be used on ALL architectures (package that contains artwork or a few python scripts that don't need to be compiled) | 17:37 |
| dholbach | <tuxmaniac> QUESTION: Some more explanation on "Section" part of the control file would help | 17:38 |
| dholbach | <dholbach> Check out http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections | 17:38 |
| dholbach | <qense> QUESTION: Doesn't ${shlibs:Depends} work in the Build-Depends field? Why not? | 17:38 |
| dholbach | no there isn't, you need to specify them manually | 17:38 |
| dholbach | there are indicators for build-depends though (configure.in or configure.ac in packages using autoconf, or setup.py in python distutils packages) | 17:39 |
| dholbach | <kevjava> QUESTION: I can't find a package "shlibs"... if it's not a package, what is it? (or if this is part of the voodoo, where can I read more about the voodoo :)) | 17:39 |
| dholbach | kevjava: it's just placeholder that will be substituted after the build | 17:39 |
| dholbach | it could be #PLEASE_SUBSTITUTE_WITH_SHARED_LIBRARY_DEPENDS# but it's ${shlibs:Depends} :-) | 17:40 |
| dholbach | alright, let's crack on | 17:40 |
| dholbach | debian/copyright is another critical part of the package | 17:41 |
| dholbach | critical for different reasons though - it has little to do with the actual build process, but it makes sure we reflect all the copyright holders, copyrights and upstream authors in the package | 17:41 |
| dholbach | there is content we can't ship because of licenses that forbid us to make changes, etc | 17:42 |
| dholbach | this section is (when you create a package from scratch) something you need to pay a lot of attention to | 17:42 |
| dholbach | Steve Langasek will talk about "How to avoid making Archive Admins unhappy" later this week | 17:42 |
| dholbach | basically it need to contain: | 17:43 |
| dholbach | - the upstream authors | 17:43 |
| dholbach | - ALL copyright holders (make sure you check all files) | 17:43 |
| dholbach | - ALL licenses of all files | 17:44 |
| dholbach | in most cases it will be easy (COPYING file says GPLv3) and you just need to double-check | 17:44 |
| dholbach | be very careful, there's a lot at stake if we slip code into the archive (even worse: on the CDs) we're not allowed to redistribute, etc | 17:44 |
| dholbach | once again: the packaging guide has more info about it | 17:45 |
| dholbach | https://wiki.ubuntu.com/PackagingGuide | 17:45 |
| dholbach | <tacone> QUESTION: so you have to copy the content from all the license files in there ? | 17:45 |
| dholbach | tacone: yes, the source tarball should ship the verbatim license texts all itself and you need to reiterate them (and/or point to /usr/share/common-licenses/ if they're available there) | 17:46 |
| dholbach | <techno_freak> fnordschrat> QUESTION: i noticed some version strings like "2:1.0~rc2-0ubuntu13" what does the "2:" mean | 17:47 |
| dholbach | sorry, I missed this one earlier | 17:47 |
| dholbach | fnordschrat: good question | 17:47 |
| dholbach | the "2" is what we call "an epoch" | 17:47 |
| dholbach | it allows you to use a lower version number again | 17:47 |
| dholbach | a common use-case for this reverting to an older version | 17:48 |
| dholbach | so let's say you maintain the package frobnicator in Ubuntu and shipped the safe but boring 2.0.0 version in hardy | 17:48 |
| dholbach | 2.0.0-0ubuntu1 for example | 17:48 |
| dholbach | in intrepid you decide to update to 2.1.87 because the set of features sounds cool | 17:48 |
| dholbach | so it'd be 2.1.87-0ubuntu1 in intrepid | 17:49 |
| dholbach | after getting lots and lots of bug reports from users that your software is broken you decide to go back to 2.0.0 again | 17:49 |
| dholbach | so you ship 1:2.0.0-0ubuntu1 in intrepid release and everybody would be happy again | 17:49 |
| dholbach | <tacone> guess the epoch should be used when upstream changes the versioning scheme either | 17:49 |
| dholbach | tacone: exactly | 17:49 |
| dholbach | let's try it out | 17:50 |
| dholbach | please type: | 17:50 |
| dholbach | dpkg --compare-versions 2.1.87-0ubuntu1 lt 1:2.0.0-0ubuntu1 && echo true | 17:50 |
| dholbach | dpkg (which is the ultimate authority when it comes to package versions) tells us that 2.1.87-0ubuntu1 < 1:2.0.0-0ubuntu1 | 17:51 |
| dholbach | <kevjava> So the epoch is a way to make sure that the version number is always increasing? | 17:51 |
| dholbach | kevjava: yes | 17:51 |
| dholbach | <techII> QUESTION: I've seen projects that have various utility scripts shiped with them, under licenses other than the main project. How should these be handled? | 17:51 |
| dholbach | techII: if we can't allow those scripts to be shipped in Ubuntu, we need to strip them from the original tarball | 17:51 |
| dholbach | for example this could be frobnicator_2.4.6repack.orig.tar.gz or some such | 17:52 |
| dholbach | to indicate it's not the pristine "2.4.6", but a repacked version | 17:52 |
| dholbach | Debian uses DFSG as an acronym there - Debian Free Software Guidelines | 17:52 |
| dholbach | <daradib> QUESTION: What about using [version]really[version] to revert to an older version, as in 10.0.1.218+10.0.0.525ubuntu1~hardy1+really9.0.124.0ubuntu2 (the version of flashplugin-nonfree in hardy)? | 17:53 |
| dholbach | daradib: epochs are a nice feature, they just come with the problem that if we (in Ubuntu) decide to introduce one and the respective Debian maintainer decides to NOT use one, we have a problem | 17:53 |
| dholbach | because new Debian revisions will always be smaller than ours, we cannot "sync" any more | 17:54 |
| dholbach | let's move on to the last part of the puzzle | 17:54 |
| dholbach | debian/rules | 17:54 |
| dholbach | the first line of the file already gives it away: it's a Makefile | 17:54 |
| dholbach | #!/usr/bin/make -f | 17:54 |
| dholbach | those of you who have worked with makefiles already will notice that there are build targets called clean, install, build, binary-indep, binary-arch and so on | 17:55 |
| dholbach | you will also notice that in those targets the upstream build system is "wrapped" | 17:56 |
| dholbach | ./configure is called, make is called, etc | 17:56 |
| dholbach | just with different prefixes and in 'special' places | 17:56 |
| dholbach | the dh_* scripts are all part of debhelper (remember, it's the package we build-depended on) | 17:56 |
| dholbach | which contains a huge set of very handy helpers to make common tasks like "install this .desktop file and register it in the right place" or "put this changelog in the right place and pretty please compress it" very very easy | 17:57 |
| dholbach | it's the piece of the source package that's easy to get wrong, but in most cases the messages during the build are pretty understandable and there are lots of examples | 17:58 |
| dholbach | this is the reason why I very much recommend to start working on existing packages, fix small bugs first before moving on to other things :) | 17:58 |
| dholbach | please check out https://wiki.ubuntu.com/MOTU/GettingStarted | 17:58 |
| dholbach | and the documents linked from there | 17:59 |
| dholbach | and please join #ubuntu-motu if you ever have any questions about packaging, etc | 17:59 |
| dholbach | we have one minute left, so let's take a break before our next session | 17:59 |
| dholbach | Upstream Bug Linkages -- JorgeCastro (jcastro) | 17:59 |
| dholbach | woohoo | 17:59 |
| dholbach | THANKS EVERYBODY! | 17:59 |
| jcastro | \o/ | 17:59 |
| chienchouchen | thank you! | 18:00 |
| DanielRM | Good lesson. | 18:00 |
| tacone | thank you ! | 18:00 |
| qense | thanks! | 18:00 |
| svaksha | thanks dholbach :) | 18:00 |
| DanielRM | Good teacher, for that matter. | 18:00 |
| * daradib applauds | 18:00 | |
| dholbach | thanks a lot guys | 18:00 |
| raseel | Applauds | 18:00 |
| stefanlsd | Thanks - excellent | 18:00 |
| DanielRM | dholbach: thumbs up. :) | 18:00 |
| Yogarine | \o/ | 18:00 |
| techno_freak | \o/ | 18:00 |
| soulhacker | good | 18:00 |
| charlieb | thx | 18:00 |
| fnordschrat | Great lesson. | 18:00 |
| fnordschrat | Thanks for answering my question. | 18:00 |
| dholbach | You guys all ROCK - hope to see your names all related to Ubuntu development soon! Go and make me proud! :-) | 18:01 |
| Myrtti | thank you dholbach ♥ | 18:01 |
| * Myrtti huggles dholbach | 18:01 | |
| * dholbach hugs Myrtti back | 18:01 | |
| raseel | Its a promise | 18:01 |
| * dholbach hugs jcastro | 18:01 | |
| jcastro | Ok .... 30 seconds or so | 18:02 |
| * daradib hugs the group | 18:02 | |
| jcastro | let's have people compose themselves after the hug a thon. :D | 18:02 |
| dholbach | jcastro is the unstoppable Jorge Castro, member of the unstoppable Michigan team, enjoy the session with him and "Upstream Bug Linkages"! | 18:02 |
| jcastro | Hi Everyone: This session is Upstream Bug Linkages: I will paste in a prepared intro to save time, and then I'll take questions and explain things further if people need that. | 18:02 |
| jcastro | My name is Jorge Castro and I do external developer relations for Canonical Ltd. Basically this means I get to analyze how well we're working with upstreams and figure out ways to make that more efficient. Today I will concentrate on bug workflow, a topic near and dear to my heart. Heh. | 18:02 |
| jcastro | The first thing you need to understand about the relationship with an upstream project and Ubuntu is to figure out which parts of "Ubuntu" belong to which project. So for example, your browser isn't made by Ubuntu, it's made by Mozilla, your desktop isn't made by Ubuntu, it's made by GNOME, etc. | 18:02 |
| jcastro | Our users usually report bugs to our bug tracking system, Launchpad. Many times however, some of these bugs aren't Ubuntu-specific, they're actually a bug in the upstream project. So it is our duty to ensure that this bug get's filed upstream so that upstream developers can see it, and then fix it! | 18:03 |
| jcastro | This is why we have pages like this: https://wiki.ubuntu.com/Bugs/Upstream which should help you look at bugs that need to be filed upstream, and how to file them. | 18:03 |
| jcastro | It's not enough to just file a bug in Ubuntu and upstream, they need to be /linked/ via the linking feature in Launchpad. Why? Well, if upstream fixes the bug, we need to have a way of tracking that so the fix gets to our users. All this linking and cross-project collaboration is for naught if the user doesn't get a fix! | 18:03 |
| jcastro | I can't reiterate that enough! | 18:03 |
| jcastro | We use a site called Harvest (http://daniel.holba.ch/harvest/) that tracks low-hanging fruit (get it?) - so when a linked bug is fixed upstream, Launchpad knows this and updates the status. Harvest can then find bugs that are fixed upstream, but NOT fixed in Ubuntu. That gives us a list of bugs that people can work on. | 18:03 |
| jcastro | Sometimes people just put a URL in a bug comment that says something like "here's the upstream bug" but they don't link it. Linking it is the key because that helps us track it, so you can help by just linking bugs where people forget to do it. | 18:04 |
| jcastro | So how do we know how well we're doing? We have a report that we're working on: https://launchpad.net/ubuntu/+upstreamreport This shows us how well we are linking things. The more green there's on this report, the better. | 18:04 |
| jcastro | Questions so far? | 18:04 |
| jcastro | ok, sorry, lots of speed! I will give people time to catch up | 18:05 |
| jcastro | the good news is that's the end of my prewritten part so from now on we're live! | 18:06 |
| jcastro | < qense> QUESTION: Isn't there a feature in Malone that adds unlinked, upstream bug reports that _are_ mentioned in replies at Launchpad to the BugWatch? | 18:06 |
| jcastro | good question | 18:06 |
| jcastro | yes, there is a little box on the side that sucks up all the URLs on that page and makes them easy to get to | 18:07 |
| jcastro | the problem is that not all URLs are exactly the right upstream bugs | 18:07 |
| jcastro | people can be saying like "Is this related to bug foo?" | 18:07 |
| jcastro | Which is why we don't automatically link these bugs to upstream bug trackers | 18:07 |
| jcastro | it needs a human to click on the link, look at the bug report upstream | 18:07 |
| jcastro | and then determine if it's the same bug, and THEN make the link | 18:08 |
| jcastro | The way to see if something is properly linked is in the upstream task, which I will get to later in the session | 18:08 |
| jcastro | < soulhacker> QUESTION:so harvest is supposed to tell about the buges fixed upstream but not reflected back to ubuntu | 18:08 |
| jcastro | but on site i dont see any such bugs? | 18:08 |
| jcastro | ok, let's find one! | 18:08 |
| jcastro | http://daniel.holba.ch/harvest/handler.py?pkg=gtk+2.0 | 18:09 |
| jcastro | so here's an example | 18:09 |
| jcastro | the ones resolved-upstream is what you're looking for | 18:09 |
| jcastro | note how harvest also tracks patches from upstream as well | 18:09 |
| jcastro | < laga> QUESTION: i saw some talk about a feature in launchpad that merges bug reports with upstream (ie LP is now much better integrated with BTS like trac). can you explain how that works? | 18:10 |
| jcastro | there is a beta plugin for bugzilla and trac that let's them sync comments between the bug in launchpad and upstream. | 18:10 |
| jcastro | I think that's what you mean because I am unaware of something that merges bugs together | 18:10 |
| jcastro | < kevjava> QUESTION: In the case of the Debian package of some GNOME project, would upstream include both the Debian bugtracker and the GNOME one? Could there be multiple trackers to link to? | 18:11 |
| jcastro | yes, in fact, many times you will find a bug reported in launchpad, upstream, AND debian bug trackers | 18:11 |
| jcastro | you can link all of those up | 18:11 |
| jcastro | let me find an example | 18:11 |
| jcastro | or not, that will take me some time, I will find one later. | 18:12 |
| jcastro | < qense> QUESTION: A question about the policy of adding upstream watches. Should you add all watches of a bug you can find, even if it's a bug report in e.g. Fedora that doens't make it easier to fix the bug for us since it's upstream? | 18:13 |
| jcastro | If I find it, I link it. | 18:13 |
| jcastro | because sometimes there might be discussions in the bug for another distro that might be useful for ubuntu and/or upstream | 18:13 |
| jcastro | I always err on the side of adding too much information. :D | 18:13 |
| jcastro | Plus it's a benefit for upstreams when they see a launchpad bug and it's linked to other places, it's less work for them to track down other distros, etc. | 18:13 |
| jcastro | < stefanlsd> QUESTION: If the bug is fixed upstream and its linked. Does it automatically close the LP bug that describes the link? | 18:14 |
| jcastro | Someone just answered this: | 18:14 |
| jcastro | < slytherin> stefanlsd: No. LP bugs are automatically closed only when an entry of the form LP: #xxxxxx is found in Ubuntu changelog when a package is uploaded. | 18:14 |
| jcastro | Any other questions so far? Keep 'em coming! | 18:14 |
| jcastro | Ok, so now the nitty gritty. :D | 18:15 |
| jcastro | https://launchpad.net/ubuntu/+upstreamreport | 18:15 |
| jcastro | This is the page I use to dig around and see how we're doing with linkages | 18:15 |
| jcastro | We purposely haven't been advertising it because it's not done, and we're still figuring out exactly what information is useful here | 18:16 |
| jcastro | but, this will give you an idea of how we're doing as a project. | 18:16 |
| cormil | join #ubuntu-classroom-chat | 18:16 |
| jcastro | Ok, so this is a list of the "top 100" packages in ubuntu | 18:16 |
| jcastro | sorted by open bugs. | 18:16 |
| jcastro | so, top100 buggiest. :D | 18:16 |
| jcastro | If you look at the list, it's basically the core, important pieces of Ubuntu itself | 18:17 |
| jcastro | Though this report concentrates on the top100, remember there are some 20,000 packages overall | 18:17 |
| jcastro | So even linking bugs in smaller packages is useful! | 18:17 |
| jcastro | For this example let's look at the nautilus component | 18:17 |
| jcastro | 9th one down. | 18:18 |
| jcastro | it has 396 open(!) bugs | 18:18 |
| jcastro | under the open column | 18:18 |
| jcastro | 311 of those have been marked as upstream with an upstream task. Of those, 309 have links. | 18:18 |
| jcastro | So that's pretty good. | 18:18 |
| jcastro | When you look at Firefox-3.0, it has 96 upstream tasks, but only 64 have watches. | 18:19 |
| jcastro | So what you can do is click on the Delta, which is 32. | 18:19 |
| jcastro | This will give you a list of bugs that you can look at to possibly link to upstream bugs | 18:19 |
| jcastro | this is how you find easy bugs | 18:20 |
| jcastro | for example, look at this one: | 18:20 |
| jcastro | https://bugs.edge.launchpad.net/ubuntu/+source/kdebase/+bug/175152 | 18:20 |
| ubot5 | Launchpad bug 175152 in kdebase "konqueror misinterprets mailto: link with #" [Low,Confirmed] | 18:20 |
| jcastro | So, this was determined to be a bug upstream | 18:20 |
| jcastro | the missing part here is someone needs to either a)find it upstream kde's bug tracker and link it. | 18:21 |
| jcastro | or b) file it in upstream KDE and then make a link. | 18:21 |
| laga | QUESTION: what is that supposed to mean - "When you look at Firefox-3.0, it has 96 upstream tasks, but only 64 have watches.". do we have 96 bugs marked as upstream, but there's no corresponding link to the upstream BTS? | 18:21 |
| laga | gah. | 18:21 |
| jcastro | heh no worries, I'll get to it | 18:21 |
| jcastro | < daradib> QUESTION: How would upstream be notified of Launchpad links? | 18:21 |
| jcastro | ok, this is an important question | 18:21 |
| jcastro | Usually, if you find a bug upstream and you link it, you should leave a comment in the upstream bug to let them know. | 18:22 |
| jcastro | If you follow along some of the really high-bugcount triagers you'll see their comments all over bugzillas | 18:23 |
| jcastro | for example when I see a bug in gnome I usually see a comment from seb128 or pedro letting them know where the bug is in launchpad. | 18:23 |
| jcastro | This is a Good Thing(tm) | 18:23 |
| jcastro | < qense> QUESTION: What information should you include in the upstream report? When does just pointing them at the LP | 18:23 |
| jcastro | bug report is sufficent? | 18:23 |
| jcastro | This depends | 18:23 |
| jcastro | I usually don't know enough about something to make a positive technical contribution - so I concentrate on linking the bugs | 18:24 |
| jcastro | this helps link developers together so that someone who does know the details can helkp move the bug forward | 18:24 |
| jcastro | < nasam> QUESTION: I often find a bug in a gnome program. Each time I wonder: should I report it on LP, on Gnomes bugzilla or on both (and ofc link them)? | 18:24 |
| jcastro | another awesome question | 18:24 |
| jcastro | this depends I think | 18:25 |
| jcastro | Ususally if I know it's 100% an upstream bug, like a feature request, you can just put it in the upstream bugzilla | 18:25 |
| jcastro | But ... I always check launchpad bugs also | 18:25 |
| jcastro | because lots of times people have the same idea or ran into the same bug | 18:25 |
| jcastro | and if I create it upstream I make the link | 18:25 |
| jcastro | If you are unsure, make it in launchpad and someone more experienced will make the link | 18:26 |
| jcastro | if you are sure, then just put it upstream | 18:26 |
| jcastro | < tuxmaniac> QUESTION: Sometime bugs are made "Fix released" upstream once they are in VCS (but not released). And if we had to wait for upstream release then we could miss our dev cycle. In such cases is it advisable to pick up the upstream patch and apply it on an exisiting version in Ubuntu? | 18:26 |
| jcastro | tuxmaniac: this seems like a better question for a MOTU (next session), or the "How Do I fix an Ubuntu bug?" session | 18:27 |
| jcastro | since I don't know the answer. :D | 18:27 |
| jcastro | < Rocket2DMn> QUESTION: Are functionality bugs typically ones that should be filed upstream? | 18:27 |
| jcastro | yep, but like I said, it doesn't hurt to search in launchpad too and make a link | 18:28 |
| jcastro | since usually when I think of something someone already has filed it. :D | 18:28 |
| jcastro | < laga> QUESTION: what is that supposed to mean - "When you look at Firefox-3.0, it has 96 upstream tasks, but only 64 have watches.". do we have 96 bugs marked as upstream, but there's no corresponding link to the upstream BTS? | 18:28 |
| jcastro | correct | 18:28 |
| jcastro | that means that 96 bugs have been marked as upstream, but no one has taken the time to link them to an upstream bug. | 18:28 |
| jcastro | Please note that for a lot of these, it means going to an upstream tracker | 18:29 |
| jcastro | filing a bug | 18:29 |
| jcastro | and linking it | 18:29 |
| jcastro | this is time consuming, vs. normal bug work | 18:29 |
| jcastro | If you had to create a login for every upstream bugzilla | 18:29 |
| jcastro | and then file bugs on each one | 18:29 |
| jcastro | each with a different way of doing things ... you would go mad. | 18:29 |
| jcastro | So what I do instead is pick a "pet project" off this list | 18:30 |
| jcastro | and help out with it | 18:30 |
| jcastro | I usually try not to touch gnome bugs because seb128 and pedro keep the gnome stuff in really awesome shape | 18:30 |
| jcastro | I instead try to go for the ones that are not green, since they need help | 18:30 |
| jcastro | you can do this as part of your 5-a-day! | 18:30 |
| jcastro | < techno_freak> QUESTION: What if I find a big in a program, and also find a bug being reported for the same upstream. | 18:31 |
| jcastro | should I still file a bug in LP and link it to the upstream bug? | 18:31 |
| jcastro | that doesn't hurt. | 18:31 |
| jcastro | if someone else finds the bug they'll file it on launchpad and someone will have to link it later anyway, so if you want to preempt that then go ahead! | 18:31 |
| jcastro | < tuxmaniac> QUESTIOn: Can you link to upstream bug reports if that project isnt registered in LP. I am still unable | 18:31 |
| jcastro | to do it. may be I am missing something. But if it is true, is it in LP roadmap? | 18:31 |
| jcastro | this is unfortunately a bug | 18:32 |
| jcastro | you can't just link to an upstream bug tracker unless the product is registered in lp. | 18:32 |
| jcastro | For the top100 it's not an issue since many of those are in there | 18:32 |
| jcastro | but for little projects it can be annoying. | 18:32 |
| jcastro | I'll ask someone on the lp team about it. | 18:32 |
| jcastro | < qense> QUESTION: What's the function of an Upstream Contact? | 18:33 |
| jcastro | an upstream contact is someone that wants to take ownership of a product and act as the person taking care of bugs in launchpad and forwarding them upstream | 18:33 |
| jcastro | < soulhacker> not be a buzzkill here but this isnt exactly as "glorifying" as fixing a actual bug | 18:33 |
| jcastro | right | 18:33 |
| jcastro | it isn't | 18:33 |
| jcastro | Look at it this way | 18:34 |
| jcastro | we've got a bunch of users that find bugs | 18:34 |
| jcastro | and on the other side you have upstreams which need information to fix their bugs | 18:34 |
| jcastro | linking bugs acts as a "bridge" | 18:34 |
| jcastro | So even if I'm not fixing bugs themselves, making sure that bugs that our users report get to the right people still helps. | 18:35 |
| jcastro | Especially when you consider the millions of users we have. :D | 18:35 |
| jcastro | What you DON'T want is like the discussion I had with someone at GUADEC | 18:35 |
| jcastro | when I was talking to them about this same thing | 18:35 |
| jcastro | and he went into launchpad and found a bunch of bugs for his software he didn't know about | 18:35 |
| jcastro | That is an instance of FAIL on our part. | 18:36 |
| jcastro | But had someone been linking bugs and filing them upstream, he would have found them earlier | 18:36 |
| jcastro | (by the way he was able to fix 3 right then and there) | 18:36 |
| jcastro | so it does work when we're all Doing the Right Thing(tm) | 18:36 |
| jcastro | < balachmar> QUESTION: How do I link the bugs if I found a bugreport in the corresponding bug tracker? | 18:37 |
| jcastro | https://wiki.ubuntu.com/Bugs/Watches | 18:37 |
| jcastro | this is the page. | 18:37 |
| jcastro | note that that also talks about how to link the bug to other distros. | 18:37 |
| jcastro | As a rule, I always, always look for the bug in debian as well. | 18:37 |
| jcastro | Debian is special because it's our "upstream" for a good deal of the distribution | 18:38 |
| jcastro | so ensuring we have good linkages with Debian is crucial. | 18:38 |
| jcastro | If a bug has a link to upstream AND debian I consider it ideal. :D | 18:38 |
| jcastro | < daradib> QUESTION: Launchpad does not import bug status/importance from Savannah (Launchpad bug 191623 and bug 191624). Should they still be linked? | 18:38 |
| ubot5 | Launchpad bug 191623 in malone "Launchpad should import statuses from Savannah bugs" [Undecided,Confirmed] https://launchpad.net/bugs/191623 | 18:38 |
| jcastro | In that case just leave it in the comments | 18:39 |
| jcastro | when support for the tracker gets fixed we can all go back and link them | 18:39 |
| jcastro | < vish_> QUESTION: a PPA package providing the latest packages like for example telepathy, where do i file the bugs | 18:39 |
| jcastro | for it LP or Bugzilla? | 18:39 |
| jcastro | aha, good question. | 18:39 |
| jcastro | This is something I think should be clear for PPAs. | 18:40 |
| jcastro | Ideally they would say "Please file bugs here" | 18:40 |
| jcastro | Some PPAs are daily snapshots or random crack. | 18:40 |
| jcastro | What you don't want to do is file bogus reports for a PPA upstream. | 18:40 |
| jcastro | So in this case, I would ask the person running the PPA | 18:40 |
| jcastro | I believe the telepathy-team just want them in lp and then they'll forward it up, but you should confirm that with them | 18:41 |
| jcastro | as an example ... | 18:41 |
| jcastro | This upstream project, banshee, released 1.0 | 18:41 |
| jcastro | We formed a banshee-team and set up a PPA. | 18:41 |
| jcastro | One of the packagers started putting svn snapshots in there. | 18:42 |
| jcastro | and people reported bugs upstream. | 18:42 |
| jcastro | and upstream wasn't aware that anything but 1.0 was packaged | 18:42 |
| jcastro | so there was this mess of bugs that they thought were in 1.0 but were in svn instead. | 18:42 |
| jcastro | so what they do NOW is ... | 18:42 |
| jcastro | they release, when they do they ping the PPA team | 18:42 |
| jcastro | and then they roll out a PPA release | 18:43 |
| jcastro | it's just a simple manner of communication | 18:43 |
| jcastro | So be careful when filing bugs about PPAs | 18:43 |
| jcastro | They're totally awesome, but if you don't communicate things well your bugs can impede progress | 18:43 |
| jcastro | < stefanlsd> QUESTION: If the bugwatch we set is actually invalid - do we remove the bugwatch we set, or wait for | 18:43 |
| jcastro | upstream to mark it invalid? | 18:43 |
| jcastro | no, this is a bug | 18:44 |
| jcastro | We have someone on it though | 18:44 |
| jcastro | because it's very annoying | 18:44 |
| jcastro | I suppose I should have said this at the beginning. :D | 18:44 |
| jcastro | Once you link something, there's no easy way to undo it | 18:44 |
| jcastro | so if you're not sure, don't link it. :D | 18:44 |
| jcastro | but I find that usually people who link a bug in the comments are decent enough | 18:44 |
| jcastro | so all you have to do is read both bugs and make a judgement call | 18:45 |
| jcastro | if it's too complicated (for example, I can't really do kernel bugs) then let someone else who knows do it. | 18:45 |
| jcastro | any more questions? | 18:45 |
| jcastro | QUESTION: qense: Does anyone here knows what's the status of importing statusses from SF? | 18:46 |
| jcastro | No idea. I will put that on a todo though | 18:46 |
| jcastro | Ok, so ... https://launchpad.net/ubuntu/+upstreamreport | 18:47 |
| jcastro | that very last column | 18:47 |
| jcastro | the triangle column (that is the symbol for delta) | 18:47 |
| jcastro | those are bugs with open upstream tasks, but no link | 18:47 |
| jcastro | also, another tip | 18:48 |
| jcastro | Most times, when I am looking for bugs | 18:48 |
| jcastro | there are a bunch of duplicates | 18:48 |
| jcastro | or one upstream, etc. | 18:48 |
| jcastro | Finding these can be challenging - but if you're good at searching through bug lists it's something you can do | 18:48 |
| jcastro | < balachmar> QUESTION: What status should a bug get when it is linked to the upstream bug tracker? | 18:49 |
| jcastro | I notice that it's usually confirmed or triaged already | 18:49 |
| jcastro | but if it's linked, it should be at a minimum confirmed | 18:49 |
| jcastro | Ah | 18:49 |
| jcastro | that reminds me | 18:49 |
| jcastro | Sometimes I see bugs marked as New | 18:50 |
| jcastro | with an upstream link | 18:50 |
| jcastro | and a bunch of activity upstream on the bug | 18:50 |
| jcastro | Don't let it anguish in New, confirm it! | 18:50 |
| jcastro | < Iulian> We usually set it to Triage. I mean, that's what I do. | 18:50 |
| jcastro | If you're on the bugsquad and have permissions to mark it Triaged then do that | 18:51 |
| jcastro | < daradib> QUESTION: Is there a way to have the Upstream Bug Report for only specified package(s)? | 18:51 |
| jcastro | Not yet, but it's in the cards | 18:51 |
| jcastro | Right now we're concentrating on this big overall view | 18:51 |
| jcastro | We are still tweaking the report | 18:51 |
| jcastro | there's a bunch of ubuntu-specific things on there where we are the upstream and shouldn't be on the report | 18:52 |
| jcastro | so once we remove those more upstreams will get on the list | 18:52 |
| jcastro | < daradib> QUESTION: What should one do if you suspect there are two identical bugs on upstream bug tracker (i.e. | 18:52 |
| jcastro | duplicates of each other)? Should you just make a judgment call, link one of them, and add a bug comment on | 18:52 |
| jcastro | the upstream tracker about the other bug? | 18:52 |
| jcastro | ugh what is up with my paste today | 18:52 |
| jcastro | Ideally you want the duplicate to be marked as a duplicate upstream | 18:53 |
| jcastro | because it wouldn't make any sense to have that not done upstream | 18:53 |
| jcastro | so I usually mark it a dupe. | 18:53 |
| jcastro | if you don't have an account there you can just ask somebody or leave a comment there | 18:53 |
| jcastro | just use common sense for that, no one will yell at you for trying to do the right thing. :D | 18:53 |
| jcastro | ok | 18:54 |
| jcastro | so someone tried to link a bug | 18:54 |
| jcastro | let's look at it! | 18:54 |
| jcastro | https://bugs.edge.launchpad.net/firefox/+bug/219755 | 18:54 |
| ubot5 | Launchpad bug 219755 in firefox "Visiting the Extension Home Page replaces the saved session" [Medium,Confirmed] | 18:54 |
| jcastro | https://bugzilla.mozilla.org/show_bug.cgi?id=361129 | 18:55 |
| ubot5 | jcastro: Error: Could not parse XML returned by Mozilla: Unknown host. | 18:55 |
| jcastro | he linked to that bug | 18:55 |
| jcastro | so let's look at both and see if they're the same thing | 18:55 |
| jcastro | balachmar: that looks awesome to me! | 18:55 |
| jcastro | you don't need to leave a comment in the launchpad bug | 18:55 |
| jcastro | when someone sees the bug it's obvious it's linked. | 18:56 |
| jcastro | (remember, every comment you make is sent out via mail to people subscribed to the bug) | 18:56 |
| jcastro | So when I link I don't leave a comment. | 18:56 |
| jcastro | EXCEPT | 18:56 |
| jcastro | where you notice someone just pasting URLs | 18:57 |
| jcastro | in that case I leave a little comment with instructions on how to link the bug | 18:57 |
| jcastro | so that person knows that the feature exists and uses it | 18:57 |
| jcastro | our bugmaster bdmurray likes to say "when you have a chance to educate someone on how they file bugs, do it!" | 18:57 |
| mok0 | Will bugs reported in LP automatically be forwarded to mozilla? | 18:58 |
| jcastro | No | 18:58 |
| jcastro | there is no automatic forwarding | 18:58 |
| jcastro | we purposely leave this to humans | 18:58 |
| jcastro | because your brain can filter out noise better than anything automatic | 18:59 |
| jcastro | Ok, looks like I am out of time | 18:59 |
| jcastro | thanks so much everyone for coming | 18:59 |
| jcastro | I hope you learned something! | 18:59 |
| chienchouchen | thank you | 18:59 |
| jcastro | And I hope you keep linking bugs upstream! | 18:59 |
| mazaalai | tnx | 18:59 |
| charlieb | thx, jcastro | 19:00 |
| jcastro | If you use the upstream report and have feedback, feel free to mail me, jorge@ubuntu.com | 19:00 |
| techno_freak | thanks a lot jcastro | 19:00 |
| Iulian | Thank you Jorge - that was awesome. | 19:01 |
| Iulian | It's my turn now... | 19:01 |
| Iulian | Hello all and welcome to "Introduction to MOTU" session. My name is Iulian Udrea and I'm going to talk about MOTU obviously. | 19:01 |
| Iulian | I like to answer questions, so, if you have any, please do not hesitate to ask. Prefix your question with QUESTION: and ask it in #ubuntu-classroom-chat. | 19:02 |
| Iulian | OK, so... how many people we have here? | 19:02 |
| Iulian | Raise your hand in #-chat so I can see it :) | 19:02 |
| Iulian | Wow, we have some. | 19:03 |
| Iulian | Awesome - let's get started! | 19:03 |
| Iulian | The acronym MOTU stands for Master(s) of the Universe. | 19:03 |
| Iulian | There are three types of Ubuntu Developers: | 19:03 |
| Iulian | 1. Universe contributors - they are collectively responsible for the maintenance of most of the packages in Ubuntu (the 'universe' and 'multiverse' components). | 19:04 |
| Iulian | For example: merge new versions from Debian, synchronize them with Debian, fix bugs etc. | 19:04 |
| Iulian | 2. MOTU - they are the brave souls who keep the Universe and Multiverse components of Ubuntu in shape. | 19:05 |
| Iulian | They are community members who spend their time adding, maintaining and supporting as much as possible the software found in Universe. | 19:06 |
| bokey | heh. wikipedia says MOTU => Mark of the Unicorn | 19:06 |
| * bokey ducks | 19:06 | |
| Iulian | (approximately 15000 packages). | 19:06 |
| Iulian | Hehe | 19:06 |
| Iulian | 3. Core developers - they are collectively responsible for the maintenance of packages in the 'main' and 'restricted' components. | 19:07 |
| Iulian | They have a strong working knowledge of Ubuntu project procedures, packaging concepts and techniques. | 19:07 |
| Iulian | Any questions so far? | 19:07 |
| ogzy | no :) | 19:08 |
| Iulian | Ok then, let's keep going. | 19:08 |
| zenkk | What's the difference between "maintaining most of the packages" in Universe and Multiverse, and "keeping the Universe and Multiverse components in shape"? | 19:09 |
| richspirit | date -u | 19:09 |
| Iulian | zenkk: I'm afraid there is no difference between maintaining and keeping the components in shape. | 19:10 |
| Iulian | zenkk: Questions in #ubuntu-classroom-chat please. | 19:10 |
| Iulian | zenkk: Maintaining means that we take care of packages. | 19:11 |
| === serzholino_ is now known as serzholino | ||
| Iulian | <mok0> QUESTION: Can I post a wiki link? | 19:11 |
| Iulian | mok0: Yes, sure. | 19:11 |
| Iulian | <soulhacker> QUESTION: so if i want to add a package to ubuntu universe repository where do i fall 1 or 2? | 19:12 |
| mok0 | Here is a nice overview of the various developer categories in Ubuntu: https://wiki.ubuntu.com/UbuntuDevelopers | 19:12 |
| Iulian | soulhacker: I'll explain later how can you get your new package in the archive. | 19:12 |
| Iulian | The MOTU are a group of developers who take responsibility for Ubuntu Universe which is the community-maintained part of Ubuntu. | 19:13 |
| Iulian | If you want to get involved with the MOTU I suggest you to start with the bitesize bugs which are located at https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize. | 19:13 |
| Iulian | The bugs which have the bitesize tag means that they are easy to fix. | 19:14 |
| Iulian | For example, a manual page for a particular package has a typo or the .desktop file has a field which is deprecated and so on. | 19:14 |
| Iulian | <soulhacker> QUESTION: please don't mide me being a idiot but then what does MOTU ACTUALLY do? | 19:15 |
| Iulian | soulhacker: I just said earlier. :) | 19:15 |
| Iulian | If you are tired fixing bitesize bugs come and join us, we are sure that we'll find something for you to work on. | 19:15 |
| Iulian | Also you might want to have a look at https://wiki.ubuntu.com/MOTU/TODO/Bugs. | 19:15 |
| Iulian | You don't need to know any programming language to get involved with the MOTUs but sometimes it may help you. | 19:16 |
| Iulian | Take a look at this FAQ: https://wiki.ubuntu.com/MOTU/FAQ. | 19:16 |
| Iulian | It will answer you some questions. | 19:17 |
| Iulian | Let me quote some of them. | 19:18 |
| Iulian | Q: "Do I need to know a lot of programming languages to become a MOTU?" | 19:18 |
| Iulian | "Much more important than having a lot of progamming experience is:" | 19:18 |
| Iulian | # being a good team player | 19:18 |
| Iulian | # learning by reading documentation, trying things out and not being afraid to ask questions | 19:18 |
| Iulian | # being highly motivated | 19:18 |
| Iulian | # having a knack for trying to make things work | 19:19 |
| Iulian | # having some detective skills | 19:19 |
| Iulian | Much better now. | 19:19 |
| Iulian | If you get stuck at any point, we have a channel here on Freenode #ubuntu-motu and a ML ubuntu-motu@lists.ubuntu.com. Just come in and ask your question. We will be more than happy to answer all of your questions! | 19:19 |
| Iulian | We also have set up a Mentoring program, more details at https://wiki.ubuntu.com/MOTU/Mentoring as I don't have enough time to talk about. | 19:20 |
| Iulian | This program will help new contributors to get more involved in Ubuntu development. | 19:21 |
| Iulian | I'd also like to mention about the MOTU videos: https://wiki.ubuntu.com/MOTU/Videos. | 19:21 |
| Iulian | These videos are excellent for new contributors and those who would like to join our beautiful world, the MOTU world. | 19:22 |
| Iulian | The difference between a MOTU and a Contributor is not so big as many of you think. MOTU have just the right to upload packages to the Ubuntu Universe archive. | 19:22 |
| === _neversfelde is now known as neversfelde | ||
| Iulian | <DreamThief> QUESTION: So if I get it right the first step to get in the orbit of the MOTUs is to start fixing small bugs? | 19:23 |
| Iulian | DreamThief: Exactly | 19:23 |
| DreamThief | thx ;) | 19:23 |
| Iulian | :) | 19:23 |
| Iulian | You don't need to be a Universe Contributor or a MOTU to have your new package or patch uploaded to the archive. | 19:24 |
| Iulian | For NEW packages we have REVU which is located at http://revu.ubuntuwire.com/. REVU is a review tool for MOTUs. It is a web based tool where people can upload their packages. | 19:25 |
| Iulian | <xander21c> Question: Is there any requirements for mentoring? | 19:25 |
| === ssd7 is now known as Guest17464 | ||
| === Guest17464 is now known as ssd71 | ||
| Iulian | xander21c: No. Just write us an e-mail and we'll be more than happy to pick you up. | 19:25 |
| Iulian | <mruiz> QUESTION: Hi. How long is the period to become Universe contributor? In my case, I have worked before with the team (uploaded, merged and synced packages). | 19:26 |
| Iulian | mruiz: Well, I don't know how to answer your question. I think that you know better. If you contributed before, talk to your sponsors and tell them what they think. | 19:26 |
| Iulian | Ok, let's continue. | 19:27 |
| Iulian | I just said that for new packages we have REVU. | 19:28 |
| Iulian | It's something similar to what Debian has for new packages: http://mentors.debian.net/ | 19:28 |
| Iulian | <soulhacker> QUESTION:so i have found a bitesized bug i am intrested in how do i go about fixing it? | 19:29 |
| Iulian | soulhacker: dholbach gave a session earlier. You might want to read it. Anyway, if you get stuck, we have #ubuntu-motu. | 19:30 |
| Iulian | Just ask your question in that channel and I am sure that someone will answer it. | 19:30 |
| Iulian | <ogzy> QUESTION: what is the duty of the mentors, guiding a new volunteer on the MOTU road ? | 19:31 |
| Iulian | ogzy: Yup | 19:31 |
| Iulian | soulhacker: Does this answer your question? | 19:31 |
| Iulian | Ok then. | 19:32 |
| Iulian | You will need two advocates from two MOTUs in order for your new package to be uploaded to Universe. If everything is ok, the last reviewer (must be a MOTU) will upload your package to the archive. | 19:32 |
| Iulian | If you want to know more about REVU, I suggest you to have a look at https://wiki.ubuntu.com/MOTU/Packages/REVU. | 19:33 |
| Iulian | soulhacker: Since we're in Feature Freeze, we don't allow new packages to be uploaded to the archive. | 19:34 |
| Iulian | soulhacker: You can ask in #ubuntu-motu for someone to review your package. | 19:34 |
| Iulian | Also, if you have a fix for a bug in a package and would like to have your patch sponsored you need to file a bug in LP, attach your patch to the bug report and subscribe the right sponsors. | 19:35 |
| Iulian | For 'universe' ubuntu-universe-sponsors and for 'main' ubuntu-main-sponsors. | 19:35 |
| Iulian | You might want to have a look at https://wiki.ubuntu.com/SponsorshipProcess because the whole process is described in that wiki page. | 19:36 |
| Iulian | So, if you want to become a MOTU you need to submit an application to the MOTU Council and you need positive advocacy from several MOTUs. | 19:37 |
| Iulian | The MOTU Council currently has 5 members (Daniel Holbach, Emmet Hikory, Michael Bienia, Richard Johnson and Soren Hansen). | 19:37 |
| Iulian | Now I will talk a little bit about MOTU Release since we are in Feature Freeze... | 19:39 |
| Iulian | But first what Feature Freeze (also known as FF) means? | 19:39 |
| Iulian | When Feature Freeze is active it means that we won't accept new features, packages, APIs and focus on fixing bugs in the development release (current Intrepid Ibex). | 19:40 |
| Iulian | MOTU Release is a team that takes care of approving and denying Feature Freeze exceptions for Universe and Multiverse. | 19:41 |
| Iulian | For example if the upstream of a package releases a more stable version (only bug fixes, no new features) you might get an exception. | 19:42 |
| Iulian | The process is briefly described here: https://wiki.ubuntu.com/FreezeExceptionProcess | 19:43 |
| Iulian | <nxvl> QUESTION: Can any contributor at any time write an application for MOTUship? | 19:43 |
| Iulian | nxvl: Well, someone asked something similar to this one. It's up to him. If he thinks that he's ready for MOTUship, that's ok. | 19:44 |
| Iulian | nxvl: Well, I like to talk to my sponsors to see what they think, if I'm ready or now. | 19:45 |
| Iulian | Let's keep going. | 19:46 |
| Iulian | Let's say a few words about MOTU SRU too. | 19:46 |
| Iulian | s/now/not | 19:47 |
| Iulian | SRU stands for Stable Release Update which will only be issued in order to fix high impact bugs. | 19:47 |
| Iulian | For example: bugs with severe impact on a large portion of ubuntu users, bugs which cause loss of user data. | 19:48 |
| Iulian | Bugs which represent severe regressions from the previous release etc. | 19:48 |
| Iulian | A good example of a SRU bug is this one https://bugs.edge.launchpad.net/ubuntu/hardy/+source/oxine/+bug/225935 | 19:49 |
| ubot5 | Launchpad bug 225935 in oxine "oxine is not installable in 8.04" [High,Fix released] | 19:49 |
| Iulian | Just to give you an idea on how a SRU is managed. | 19:50 |
| Iulian | We still have some more minutes. Do you have any questions, ideas, remarks? | 19:51 |
| Iulian | Ohh come on! Hit me with your questions! | 19:52 |
| Iulian | <ogzy> QUESTION: there are some MOTU meetings, what's that about? | 19:52 |
| Iulian | ogzy: In the meetings they discuss different things, issues they encountered. | 19:54 |
| Iulian | ogzy: Before the meeting they have some topics. | 19:54 |
| Iulian | <drubin> QUESTION:(Not sure if appropriate feel free to tell me) I would like to know why Evolution vs thunderbird as the standard mail client? | 19:55 |
| Iulian | drubin: I'm not sure how to ask that. Maybe because they are popular? | 19:56 |
| Iulian | Okay, we still have a couple of minutes. | 19:58 |
| Iulian | <techII> i think evolution is 'part' of gnome, thus why it is default | 19:59 |
| Iulian | It can be one of these reasons too. | 19:59 |
| Iulian | I think we are out of time. | 19:59 |
| Iulian | Thank you all for attending! | 20:00 |
| Iulian | And don't forget, join #ubuntu-motu if you still have questions. I'll be more than happy to answer all of them. | 20:00 |
| Iulian | Next one is "Soyuz and all that Jazz" - Celso Providelo | 20:01 |
| Iulian | The stage is yours. | 20:01 |
| laga | yay | 20:01 |
| === tsudot_ is now known as tsudot | ||
| laga | thanks Iulian, lovely class. | 20:01 |
| jpds | Who is currently having lunch. | 20:01 |
| cprov-lunch | Iulian: thanks :) | 20:01 |
| mazaalai | thanks | 20:01 |
| Iulian | laga: Thanks | 20:02 |
| Iulian | cprov-lunch: Rock! | 20:02 |
| tsudot | Iulian, thanks | 20:02 |
| cprov-lunch | Hi guys, who is here for "Soyuz and all that Jazz" | 20:02 |
| === cprov-lunch is now known as cprov | ||
| charliecb | me | 20:02 |
| charliecb | hi cprov | 20:03 |
| * Iulian is here too. | 20:03 | |
| cprov | charliecb: hi | 20:03 |
| rulus | _o/ | 20:03 |
| cprov | aha, anyone else ? | 20:03 |
| nellery | me! | 20:03 |
| * jpds is here too. | 20:04 | |
| laga | me! | 20:04 |
| cprov | Okay, I have a nice chart representing Soyuz for your appreciation -> https://wiki.ubuntu.com/CelsoProvidelo/SoyuzInfrastructureOverview | 20:04 |
| cprov | For the records I blame daniel and his fancy title for the low-audience, "Soyuz and all that Jazz" is too fancy :) | 20:05 |
| * Shunpike is here | 20:05 | |
| cprov | So, I'm here today for clarifying how the whole Launchpad infrastructure for distribution management (Soyuz) work. | 20:07 |
| DreamThief | cprov: i'm here too. and you're right. rock 'n' roll with soyuz might have been a better title ;) | 20:07 |
| cprov | how all the parts are glued together from source uploads until package archives. | 20:08 |
| cprov | DreamThief: ehe, "Rock'n roll with soyuz" sounds a like a very good title for the next session ;) | 20:09 |
| bullgard4 | cprov: So, 'Soyuz' is another name for 'Launchpad infrastructure'? | 20:09 |
| cprov | bullgard4: soyuz is the part that supports distributions/uploads/packages/archives. The model of what we call distribution management system. | 20:10 |
| DreamThief | bullgard4: questions in #ubuntu-classroom-chat *scnr* | 20:10 |
| cprov | QUESTION: laga: cprov: maybe you'd like to start with a description what soyuz actually does. because i have no clue. | 20:10 |
| cprov | laga: soyuz is a group of sub-system plugged on the current Launchpad model of the world which is able to: | 20:11 |
| cprov | 1. process source uploads; | 20:11 |
| cprov | 2. build source packages | 20:11 |
| cprov | 3. publish sources and binaries in an archive that can be used by apt | 20:12 |
| cprov | those 3 major tasks are implemented in a multi-{distribution, distroseries, archive} context. | 20:13 |
| cprov | laga: does is make things clearer ? | 20:13 |
| cprov | QUESTION: laga: cprov: yes, but what's a distroseries? | 20:14 |
| cprov | laga: dapper, hardy and intrepid are distroseries. Distroseries is a "branch" of a distribution in the VCS analogy. | 20:15 |
| cprov | QUESTION: is it possible (in later stages) to adapt Soyuz so that is it able to work with other not-apt based distros (not that I'm personally intrested in it, but it sounds bad if it only supports apt) | 20:16 |
| cprov | nasam: yes, currently we only support the debian package format. However since the very beginning we have designed soyuz models to support other packaging formats, for example RPMs | 20:17 |
| cprov | so, keep the questions coming. Meanwhile let me elaborate on the 3 major soyuz sub-systems | 20:19 |
| cprov | take the upload-processing part as a subsystem that when fed with uploads will result in a reusable model of that package within Launchpad. | 20:22 |
| cprov | so Launchpad will be able to track bugs on it, associate bzr branches with it and more importantly publish that package in one or more archives. | 20:23 |
| cprov | QUESTION: define "reusable model". | 20:23 |
| cprov | laga: read 'reusable' by all the necessary metadata necessary to perform the tasks described above. | 20:24 |
| cprov | laga: specifically on debian packages, all the original files are in librarian (launchpad file storage) and debian control fields are directly available from our database. | 20:25 |
| cprov | Now few words about the source-building systems. This component is composed by a master part which is in charge of dispatching sources and collecting binaries of a farm of launchpad-buildd (sbuild-based) machines. | 20:28 |
| cprov | I.e. we pass them a DSC and get back one or more DEBs corresponding to their architecture. | 20:29 |
| cprov | the DEBs are collected as a binary upload (.changes + N debs) which is given back to the upload-processing system. | 20:30 |
| cprov | One important difference between soyuz as used in ubuntu and DAK in debian is the fact that we only accept binary uploads coming from our build farm. | 20:31 |
| cprov | binary uploads coming from users are rejected. | 20:31 |
| cprov | this way ubuntu can guarantee that all binaries distributed were generated in the same controlled environment. | 20:32 |
| cprov | kevjava: QUESTION: How is REVU related to Soyuz? | 20:33 |
| cprov | currently REVU is implemented externally to what we call Soyuz, it's a third-party application. | 20:34 |
| cprov | I know that Michael (NCommander) is looking into using LP (specifically the PPA part) to build sources submitted to REVU. | 20:35 |
| cprov | and we will be working to make integration easier in the next cycle. | 20:35 |
| cprov | kevjava: QUESTION: What type of programming languages is Soyuz written in? Is development done all internal to Canonical (since Ubuntu is currently the only product using it)? | 20:37 |
| cprov | Soyuz is written purely in python and the code was designed internally, but as everyone already know, as part of Launchpad it is also going to be released under a free-license in the next 12 (it's 11 already) months. | 20:39 |
| cprov | QUESTION: is soyuz already open sourced? | 20:39 |
| cprov | laga: no, not yet :( | 20:39 |
| cprov | more on the archive-publishing sub-system | 20:40 |
| === mcas is now known as mcas_away | ||
| cprov | are mentioned above, this component is able to establish relationships (publication) from any Source/BinaryPackageRelease with one or many Archives | 20:41 |
| cprov | As in source foo_1.0 and its binaries can be published in Celso's PPA and debian and ubuntu PRIMARY archive. | 20:42 |
| cprov | which represents a clean workflow for distribution derivatives. | 20:43 |
| cprov | emet: QUESTION: Does Soyuz build the Ubuntu ISOs? | 20:45 |
| cprov | emet: not yet, but this task is included in the planned extensions of our buildd-farm. | 20:46 |
| cprov | additionally to source-builds the launchpad-buildd machine (ans its master part) will be extended to generate ISO images for hosted archives | 20:47 |
| cprov | also to assembly source packages from branches (bzr-builddeb/NoMoreSourcePackages) | 20:47 |
| cprov | laga: QUESTION: you mentioned "archives". what exactly is that? a package repository like archive.ubuntu.com? | 20:48 |
| cprov | laga: good question, it was obscure. Yes, archive == repository in this context. | 20:49 |
| cprov | emet: QUESTION: what builds the ubuntu ISOs? can you go from a bunch of source packages to an LiveCD ISO automatically? | 20:49 |
| cprov | emet: currently, for ubuntu, its is a external task, archive-admins operate that in a semi-automated way. | 20:51 |
| cprov | emet: no trace of ISOs is stored in the Launchpad database. | 20:51 |
| cprov | but fear not, it's going to change very soon. | 20:51 |
| Cristatus | date -u | 20:53 |
| Cristatus | hmm.... | 20:53 |
| cprov | uhu | 20:53 |
| cprov | emet: QUESTION: About how many people develop Soyuz? | 20:53 |
| Cristatus | how does that command work? | 20:53 |
| picard_pwns_kirk | Cristatus: in a shell | 20:53 |
| Cristatus | oh! | 20:54 |
| cprov | emet: we recently became 3 full-time developers. | 20:54 |
| breize | ^^ | 20:54 |
| cprov | laga: QUESTION: what were your biggest annoyances with soyuz during its development? | 20:54 |
| cprov | laga: by far, the pressure of working in a system that needs to be working 24/7 | 20:55 |
| === mrguser is now known as hubuntu- | ||
| cprov | laga: we have to balance new features with ultimate reliability. | 20:55 |
| cprov | emet: QUESTION: What source control system do you use internally? | 20:57 |
| cprov | emet: bzr ;) | 20:57 |
| cprov | tacone: QUESTION: will it ever build VM appliances ? | 20:57 |
| cprov | tacone: I see it as a natural evolution of 'building ISOs', but I haven't seen any bug filled about this feature. Maybe you should file one. | 20:58 |
| cprov | okay, shall we wrap-up and give place for the next session ? | 21:00 |
| cprov | tacone: QUESTION: ponies ? | 21:01 |
| cprov | tacone: eventually ;) | 21:01 |
| cprov | that was a fabulous session end ... | 21:02 |
| pedro_ | all done? | 21:03 |
| cprov | pedro_: yes, stage is yours | 21:04 |
| pedro_ | cprov: great, thanks a lot! | 21:04 |
| cprov | Thanks you! | 21:04 |
| pedro_ | Hello everybody my name is Pedro Villavicencio Garrido | 21:04 |
| pedro_ | I'm currently living in Santiago de Chile, I'm the guy behind the Ubuntu Desktop Bugs and I work for Canonical since a little more than a year | 21:04 |
| pedro_ | Today i will talk to you a bit about the Ubuntu+GNOME QA | 21:05 |
| pedro_ | everybody knows what GNOME is ? | 21:05 |
| pedro_ | alright! well for those who don't know it | 21:05 |
| pedro_ | The GNOME project provides you of two things the GNOME Desktop environment an intuitive and attractive desktop (blink ;-)) for users and the GNOME development platform which is an extensive and rich framework for building applications that integrate with the rest of the Desktop | 21:06 |
| pedro_ | And if you haven't noticed... it's the default desktop of Ubuntu ;-) | 21:06 |
| pedro_ | The latest stable relase of GNOME is GNOME 2.22 and since it's the default desktop of Ubuntu , GNOME 2.22 is available in Hardy if you want to try it | 21:07 |
| pedro_ | if you want to use the development release of GNOME which is GNOME 2.23.90 there's a few ways to do it | 21:07 |
| pedro_ | The first one is to download Ubuntu Intrepid from http://www.ubuntu.com/testing/ , but for example if you're using Hardy and you don't want to upgrade to Intrepid but you really want to use GNOME what you can do is build GNOME from the source, there's two ways for doing this | 21:07 |
| pedro_ | 1) Using GARNOME | 21:08 |
| pedro_ | GARNOME is a build utility that allows you to build GNOME from latest tarballs, both the stable and unstable branch, it's pretty easy to use and actively maintained the only bad thing is that it doesn't support building from SVN... but we have another tool for that | 21:08 |
| pedro_ | 2) Jhbuild | 21:08 |
| pedro_ | if you're brave enough you can build GNOME with jhbuild which allows you to build the latest modules from GNOME the SVN, is way more flexible than GARNOME, you can build an specific branch like GNOME 2.18, 2.16, etc or use bleeding edge software (GNOME trunk), it's not really recommended for beginners but if you want to learn how GNOME is build it's perfect. | 21:09 |
| pedro_ | I currently use Jhbuild for testing and if you're interested I've put my jhbuildrc file at http://www.gnome.org/~pvillavi/jhbuild/ | 21:09 |
| pedro_ | you can also look to http://live.gnome.org/JhbuildOnUbuntu if want to see what you need to do in order to build your GNOME in Ubuntu with jhbuild | 21:10 |
| pedro_ | and if you're having issues with it, there's a page of common issues when building: http://live.gnome.org/JhbuildIssues | 21:10 |
| pedro_ | if your problem is not listed there, that's probably a bug and should be reported ;-) | 21:11 |
| pedro_ | <emet> QUESTION: Do these build tools output packages? | 21:11 |
| pedro_ | emet: no they don't do it | 21:11 |
| pedro_ | <apachelogger> QUESTION: are there daily packages for ubuntu, or are there plans to get such a thing running? | 21:12 |
| pedro_ | apachelogger: that might be difficult to do and not really necessary since there's no GNOME releases each day and also the desktop team is really good at packaging those in just a few hours | 21:12 |
| pedro_ | but it would be a really good question for the desktop testing talk at Thursday ;-) | 21:13 |
| pedro_ | alright, did you wondered how many space do you need to build? | 21:13 |
| pedro_ | between sources, build and install | 21:13 |
| pedro_ | you need ~10 gb for all | 21:13 |
| pedro_ | if you like to build things there's a project at GNOME called the Build Brigade | 21:14 |
| pedro_ | what they do is to automate discovery and reporting of GNOME build errors to make the testing of the development version easy for everyone, finding the build errors and regressions quickly | 21:14 |
| pedro_ | if you have your browser open | 21:14 |
| pedro_ | you can have a look to http://build.gnome.org | 21:15 |
| pedro_ | where you can see a pretty nice resume about all the GNOME modules, the red ones are the ones that failed to build and the green ones represent the ones that the build was successful | 21:15 |
| pedro_ | so if you have a spare machine and are interested on testing you can join them at #build-brigade in irc.gnome.org and yes you can also subscribe to their mailing list and ask things : http://mail.gnome.org/mailman/listinfo/build-brigade-list | 21:16 |
| pedro_ | help is always needed and both projects will benefit of that ;-) | 21:16 |
| === cprov is now known as cprov-afk | ||
| pedro_ | is anybody familiar with the Ubuntu Bugsquad? | 21:17 |
| pedro_ | you know those awesome people? | 21:17 |
| pedro_ | well in GNOME we also have a GNOME Bugsquad | 21:17 |
| pedro_ | The GNOME Bugsquad is the Quality Assurance team for GNOME, which basically keep track of the current bugs in GNOME and try to make sure that major bugs do not go unnoticed by developers | 21:17 |
| pedro_ | the same mission as the Ubuntu Bugsquad ;-) | 21:17 |
| pedro_ | Those bugs are being tracked in the GNOME Bugzilla which is located at bugzilla.gnome.org, everybody can help you only need to create an account also the Bugsquad hangs out in IRC at the #bugs channel on irc.gnome.org so if you have any questions regarding a report the best place to ask is there unless is something really technical in that case you can ask to the module maintainer | 21:18 |
| pedro_ | but hey what about getting permission for triage, if you want to have it, you need to read the Triage Guide at http://live.gnome.org/Bugsquad and after that ask for the permissions at #bugs | 21:19 |
| pedro_ | the general disclaimers are : 1) Use common sense and 2) If unsure, ask at the channel first | 21:20 |
| pedro_ | nothing too complex as you can see | 21:20 |
| pedro_ | When working with the GNOME Bugzilla you'll be winning some points | 21:20 |
| pedro_ | and no you can't change them for t-shirts | 21:20 |
| pedro_ | the more work you do the more points you'll have . same as karma at Launchpad | 21:21 |
| pedro_ | In Ubuntu we also have a team that take care of the GNOME Bugs | 21:21 |
| pedro_ | that team is called the Ubuntu Desktop Bugs | 21:21 |
| pedro_ | the team is basically the awesome seb128, me and a few outstanding community members ;-) | 21:22 |
| pedro_ | we always need help so if you like GNOME, Ubuntu and want to help us, you're more than welcome ;-) | 21:22 |
| pedro_ | <apachelogger> QUESTION: can one merge the gnome bugzilla points and lp karma to become ubercool? | 21:22 |
| pedro_ | apachelogger: haha no sadly you can't but hey submit a feature request :-P | 21:23 |
| pedro_ | if you're wondering which packages we keep track well the list is located at: https://bugs.edge.launchpad.net/~desktop-bugs/+packagebugs as you can see they are ~110 packages which is a lot of work | 21:23 |
| pedro_ | If we same some spare time we also do some triage at these products: https://wiki.ubuntu.com/Bugs/Upstream/GNOME/UniverseList If you want to adopt a package and do some triage work on it you're free to go ;-) | 21:24 |
| pedro_ | the team hang out at #ubuntu-bugs so if you want to join the team just drop by and say hi ;-) | 21:25 |
| pedro_ | the launchpad page is : https://edge.launchpad.net/~desktop-bugs | 21:25 |
| pedro_ | and yeah while doing work with Launchpad you also win points but in launchpad they are called Karma | 21:26 |
| pedro_ | One of our tasks is also forward bugs upstream | 21:26 |
| pedro_ | since you're already know how to get help and briefly how to GNOME Bugsquad works, I'll introduce you to the forward Ubuntu GNOME related ones | 21:27 |
| pedro_ | first steps well, you need a bugzilla account, if you don't have one http://bugzilla.gnome.org/createaccount.cgi | 21:27 |
| pedro_ | you only need a valid email ;-) | 21:28 |
| pedro_ | after that well you need to search the Bugzilla database in oder to see if the bug was already reported | 21:28 |
| pedro_ | if you go to http://bugzilla.gnome.org/query.cgi | 21:28 |
| pedro_ | you'll see the basic search functionality of bugzilla | 21:29 |
| pedro_ | one of the common mistakes people do when searching is not searching for the closed bugs | 21:29 |
| pedro_ | let's take for example a query with the string "i love ubuntu" | 21:29 |
| === hubuntu- is now known as hubuntu | ||
| pedro_ | if you search for it, bugzilla will return you "zarro boogs found" | 21:30 |
| pedro_ | OMG nobody loves ubuntu :-( | 21:30 |
| pedro_ | gnome people is so evil.... | 21:30 |
| pedro_ | but hey let's try something else | 21:30 |
| pedro_ | we made that mistake, we didn't searched for the closed ones | 21:31 |
| pedro_ | so let's try this, let's search with this text: "i love ubuntu" meta-status:all | 21:31 |
| pedro_ | meta-status:all means show me all the bugs containing "i love ubuntu" i don't care about the status , just please show me those | 21:31 |
| pedro_ | now you'll get results!! | 21:32 |
| pedro_ | woohoo people love us again! | 21:32 |
| pedro_ | that was just a brief example if you want to read more about it you can take a look to http://bugzilla.gnome.org/page.cgi?id=boogle-help.html | 21:33 |
| pedro_ | you can basically search by status, gnome-version, os, target, assignee, etc | 21:33 |
| pedro_ | ok before sending our bug upstream is also good to have a look to the list of the more frequent reported bugs http://bugzilla.gnome.org/duplicates.cgi | 21:34 |
| pedro_ | searching is a bit difficult if you don't really know how the software works and you can easily spend a few minutes on it | 21:34 |
| pedro_ | for example searching for a stacktraces that matches one submitted at Ubuntu, the basic way is to go to the simple search and start copy & paste a few of the function names into it, which is not very optimal... | 21:35 |
| pedro_ | and well the GNOME Bugzilla has a very cool feature called the "Simple Dup Finder" which allows you to of course find duplicates and if you used the gnome bugzilla before you probably saw it, on the reports there's a link at the top right which said "simple dup finder" if you click there it will show you the probably duplicates of that bug, but what if you want to search as said for a stacktrace what can you do? | 21:35 |
| pedro_ | there's a cool trick for that too | 21:36 |
| pedro_ | you can use the http://bugzilla.gnome.org/dupfinder/simple-dup-finder.cgi? simple dup finder page | 21:36 |
| pedro_ | and copy and paste the stacktrace or bug description there | 21:36 |
| pedro_ | <kevjava> QUESTION: Are there parts of GNOME that seem to consistently need more attention? | 21:37 |
| pedro_ | the big products always needs more attention, like the Evolution one | 21:37 |
| pedro_ | nautilus and so on | 21:37 |
| pedro_ | <xander21c> Question: Is there mentoring fot Gnome QA | 21:37 |
| kevjava | pedro_: Cool, thanks :). | 21:38 |
| pedro_ | xander21c: yes, the mentoring of the Ubuntu GNOME ones is provided at #ubuntu-bugs and the one for GNOME at #bugs in irc.gnome.org | 21:38 |
| pedro_ | so if you interested just join the channels and ask ;-) | 21:38 |
| pedro_ | If the bug was reported what you need to do is to link the report in launchpad (aka create a bug watch), more instructions about this at: https://wiki.ubuntu.com/Bugs/Watches | 21:39 |
| pedro_ | i think that jorge mentioned that in his amazing talk | 21:39 |
| pedro_ | so if you want to know more about it look at those logs ;-) | 21:39 |
| pedro_ | but here's is one issue | 21:40 |
| pedro_ | what if there's another report in launchpad linking to that report? | 21:40 |
| pedro_ | how can you know it? | 21:40 |
| pedro_ | we don't want to have 10 reports linking to the same one upstream | 21:40 |
| pedro_ | those should be marked as duplicate and just have one master right? | 21:40 |
| pedro_ | that's the right thing to do | 21:40 |
| pedro_ | but ok how we can search for those? | 21:40 |
| pedro_ | ok don't make too much noise i'll show you a secret... | 21:41 |
| pedro_ | let's say we found the bug http://bugzilla.gnome.org/show_bug.cgi?id=506357 | 21:42 |
| pedro_ | upstream | 21:42 |
| ubot5 | Gnome bug 506357 in screenshot "crash in Take Screenshot: taking a screen shot" [Critical,Unconfirmed] | 21:42 |
| pedro_ | what we are going to do is : go to https://bugs.launchpad.net/bugs/bugtrackers/gnome-bugs/#bugnumber | 21:42 |
| pedro_ | and replace #bugnumber for the bug number of the upstream one | 21:42 |
| pedro_ | you'll be redirected to the bug in launchpad that is linking to the upstream one | 21:43 |
| pedro_ | see magic! | 21:43 |
| pedro_ | <RoAkSoAx> QUESTION: how can we get more involved with Gnome development (more related to MOTU work). Are there any specific task list where we can get started | 21:44 |
| pedro_ | RoAkSoAx: yeah there's always tasks to do, I'd recommend to go trough the list of bugs marked as gnome-love | 21:44 |
| pedro_ | http://bugzilla.gnome.org/reports/gnome-love.cgi <- RoAkSoAx | 21:45 |
| pedro_ | let's continue if the bug wasn't reported at all you can add a new one then | 21:45 |
| pedro_ | for doing it you need to go to http://bugzilla.gnome.org/enter_bug.cgi and select the right product and component, sometimes it's hard to find the right component in big products like Evolution, but follow your common sense, if the bug describe issues with reading, writing emails well the component is Mailer, is the problem is with contacts, probably the right component is Contacts and so on | 21:45 |
| pedro_ | most of the products have a list describing their components so taking the same example the list of components of the Evolution product is here: http://bugzilla.gnome.org/describecomponents.cgi?product=Evolution | 21:46 |
| pedro_ | You also need to be carefully with reports from evince for example | 21:46 |
| pedro_ | people tend to reports bugs about rendering in Evince which is in most of the cases wrong | 21:47 |
| pedro_ | poppler is the rendering backend for evince and such bugs should be filled at their bug tracker | 21:47 |
| pedro_ | so double check them before submit any of those at the GNOME Bugzilla | 21:47 |
| pedro_ | one of the last considerations is to choose the right Keyword | 21:49 |
| pedro_ | if you're submitting a bug with a good stacktrace, you need to add the STACKTRACE keyword to the report | 21:49 |
| pedro_ | if is a bug about usability, well the usability keyword and so on | 21:49 |
| pedro_ | the list of keywords can be found here: http://bugzilla.gnome.org/describekeywords.cgi | 21:50 |
| pedro_ | be sure to use them and again if you're unsure just ask :-) | 21:50 |
| pedro_ | after the bug was forwarded what you need to do is to create a bug watch linking to the bug you just submitted upstream, it'll be updated regularly and will reflect the status of the upstream bug report | 21:52 |
| pedro_ | instructions at https://wiki.ubuntu.com/Bugs/Watches | 21:52 |
| pedro_ | that's almost the whole process of forwarding a bug to the GNOME Bugzilla | 21:53 |
| pedro_ | and linking it to launchpad also | 21:53 |
| pedro_ | now it's up to the maintainers to have a look to it in order to fix it, or why not you if you're interested | 21:54 |
| pedro_ | as said previously we have to deal with toons of bugs daily and we always need help so if you like GNOME and Ubuntu as we do | 21:55 |
| pedro_ | feel free to join us and ask a lot of questions, asking is not bad so the more the best ;-) | 21:56 |
| pedro_ | I think that's all if you have any questions later feel free to send an email to me or to the ubuntu bugsquad mailing list or why not ask it on the IRC channels, we are most of the time there and well there's always people willing to help new bugsquaders | 21:58 |
| pedro_ | thanks everybody and hope to see you around soon ;-) | 21:58 |
| gnubuntu | ty | 21:59 |
| bokey | Thanks Pedro, Celso, Iulian, Jorge and Daniel! | 22:12 |
| bokey | have a good day folks | 22:12 |
| jcastro | thanks for stopping by everyone! | 22:17 |
| emil_ | erml | 22:30 |
| zachr_ | date -u | 23:04 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!