=== ssweeny_ is now known as ssweeny === txwikinger is now known as txwikinger_work === txwikinger_work is now known as txwikinger === txwikinger is now known as txwikinger3 === txwikinger3 is now known as txwikinger_work === txwikinger_work is now known as txwikinger [06:38] date -u === Gonzofox_ is now known as Gonzofox === croppa_ is now known as croppa === bluesmoke_ is now known as bluesmoke === asac_ is now known as asac [10:45] Hello everybody [10:46] hello johane [10:47] Hi guys [10:47] You are Ubuntu developers? [10:50] johane: No [10:50] Ok [10:50] Johane: just someone who's trying to be more integrated in ubuntu & linux life cycle [10:51] Good job and keep up the good work [10:51] I'm using ubuntu too [10:52] I'm helping myself with bits and tights [10:54] johane: good thing, i encourage you [10:56] somaunn:Thankyou [10:56] I'm also learning programing [10:57] johane: programming ? good thing to do with linux === KennethP_ is now known as KennethP [10:58] johane: i'm watching a video concerning notifications in jaunty (Ubuntu 9.04) [10:58] johane: telling you that thing is crazy [10:59] johane: i mean hot and different than what i've seen in linux before [10:59] Can you give me the link? [11:01] johane: http://www.markshuttleworth.com/wp-content/uploads/2008/12/jaunty904_notifications_example1_web_092.swf [11:03] Holy got :Looks very nice [11:03] More info on notifications: http://www.markshuttleworth.com/archives/253 [11:03] Y can't wait for it tobe released [11:05] Vista and WinShit 7 are babies next to the upcomming Ubuntu [11:07] johane: :D right [11:08] if someone have links containing the same video please don't hesitate [11:08] to send it [11:11] somaunn:Where you from? [11:12] johane: from congo, but actually in south africa [11:12] somaun: Is it hot there? [11:14] johane: yeah, i mean sometimes [11:14] johane: but it's a nice place [11:15] Where i live i have only 5*C maximin [11:16] *Maximim [11:16] Is winter here in Romania [11:16] You heard of Romania? [11:21] johane: yeah [11:22] johane: was there long time ago for studies [11:26] Wow-Can you remember the city? [11:29] And what studies you made there? [11:33] johane: it wasn't me, but my father [11:33] johane: and he was in sovata if remenber [12:46] hola, hay alguien por aqui? [12:51] ... [13:24] hi all! === ursula_ is now known as Ursinha === jyeager is now known as duanedesign === Obama is now known as Guest2079 [14:10] hello guys ... [14:12] get a question right here [14:12] can someone help me ? [14:13] somaunn: #ubuntu for help with ubuntu === sdx24 is now known as sdx23 [15:30] hey [15:31] hey [15:31] how are you doing today? [15:54] hey seb128 [15:54] hi Arc [15:54] Hi everyone [15:55] HELLO EVERYBODY! [15:55] WELCOME TO DAY 3 OF UBUNTU DEVELOPER WEEK! [15:55] morning dholbach! [15:55] ... also known as the Week of Awesome! [15:55] How are you all doing? [15:55] Who's excited for another day of UDW? [15:55] groggy with green tea in hand :-P [15:55] Me, me [15:56] but ready :-) [15:56] /brewing a coffe [15:56] who else? don't be shy :) [15:56] Ok... there's a bunch of names I spotted in here that look familiar, for everybody who's new: [15:56] Me, yeah!!!!! [15:57] please... don't be shy! If you have questions, please ask! [15:57] but please.... ask in #ubuntu-classroom-chat and prefix them with QUESTION: [15:57] * directhex is excited for day 4. day 4 is more awesome [15:57] ie: QUESTION: seb128: are you really German? [15:57] lol [15:57] no [15:57] ;-) [15:57] and I'm not from Alsace [15:57] * dholbach hugs seb128 [15:57] * seb128 hugs dholbach [15:57] * dholbach hugs seb128 back [15:58] we still have 3 minutes left until seb128 takes over, so grab a coffee, tea or any other drink and enjoy it [15:58] Sebastien Bacher will talk about a topic he's very familiar with: Pushing out GNOME releases to millions of users [15:58] ROCK ON! :) [15:59] Still 30 seconds.. [15:59] no join in #ubuntu-classroom-chat ?? [16:01] ok, good ;-) [16:01] good morning, afternoon, evening to everybody! [16:02] I'll do a presentation of what the ubuntu desktop team is doing first [16:02] and then we can do questions-answers [16:02] so [16:02] The Ubuntu Desktop Team is the team working on most of the Ubuntu GNOME desktop applications. [16:03] The team is a mix of people working full time for canonical and rocking contributors [16:03] we have some contributors around I see ;-) [16:03] hey crevette, pochu (and probably others) ;-) [16:03] * Where we are [16:03] - #ubuntu-desktop on irc.ubuntu.com [16:03] - ubuntu-desktop@lists.ubuntu.com [16:04] - launchpad: desktop-bugs and ubuntu-desktop teams [16:04] * What we do [16:04] - work on the desktop packages, the rough list is on https://launchpad.net/~desktop-bugs/+packagebugs [16:04] - update the desktop packages when new versions are available [16:04] - work on the corresponding bugs lists, triage the bugs and work with upstream to get those resolved [16:05] * How we work: [16:05] - most of the packages are coming from the debian pkg-gnome team [16:05] - we try to keep those packages in sync as much as possible and send their our changes to them [16:05] - we do package unstable version earlier and carry ubuntu specific changes though [16:06] - the packaging is mostly done using cdbs [16:06] - we mostly updates packages when GNOME roll new tarballs and backport upstream fixes [16:06] [16:06] * How we do updates: [16:07] - we current have somebody looking at the new upstream tarballs and noting what upgrade we need to do in ubuntu [16:07] - tasks are usually splitted on IRC (ie, upgrade are assigned to people there) [16:08] - people are free to claim tarballs they want to work on [16:08] - contributors use bugs on launchpad to get their work reviewed [16:08] usually it's easy to get review since the team is quite active [16:09] and you often find people to help on IRC [16:09] [16:10] the current workflow has some limitation and we will try to improve it [16:10] some packages are moving to bzr for the packaging work and we will probably try to standardize that [16:10] didrocks started some documentation on the topic and you can find details on the ubuntu desktop wiki: https://wiki.ubuntu.com/DesktopTeam [16:11] we also want a system which allow to set a todolist and let people claim work directly there rather than using IRC [16:11] some people started to work on a website listing all the versions available in ubuntu, debian and upstream for the team packages [16:12] we will probably try to continue this way and have a website which allow people to claim work they are doing [16:12] on a technical side upgrades are usually standard version updates [16:13] some are easy enough for beginner so if you want to get started that's no issue [16:13] some other are tricker (soname changes, change to build system, new binaries added) [16:13] the things we usually check for updates [16:13] - the configure requirement and if they changed [16:14] if they changed the (build-)depends need to be updated to reflect that [16:14] - that the update builds and work correctly [16:14] - the bugs closed in the upgrade [16:15] library are also checked for abi changes (in which case the soname should be updated if the new abi is not compatible, or the shlibs updated if there is new functions but the abi is still compatible) [16:15] [16:15] ok [16:15] that was it for the summary of what the team is doing on how [16:15] we also discuss desktop changes, new components to install by default or not, configuration changes, etc [16:16] [16:16] we can do questions and answers now ;-) [16:16] can't join #ubuntu-classroom-chat [16:16] why? [16:16] good question [16:16] QUESTION: Off-topic: Can someone work remotely for Canonical? [16:17] DasEi: /msg me and I'll try to help you [16:17] pochu: can you write the nickname of whoever asked too maybe? [16:17] sure, sorry [16:17] creek23> QUESTION: Off-topic: Can someone work remotely for Canonical? :-/ [16:17] creek23: most of the people working on Ubuntu for canonical are working remotely [16:17] so yes it's possible [16:18] the job offers are on the website and that's specified in the descriptions [16:18] [16:18] next [16:18] fta> QUESTION: seb128: you said "somebody looking at the new upstream tarballs", d'oh! manually? how often? why somebody and not some script? [16:19] fta: GNOME has a mailing list which gets mails about all the tarballs uploaded so that's easy to keep track ... why not a script because nobody wrote one yet ... interested? ;-) [16:19] probably [16:19] in fact somebody started working on a website listing ubuntu, debian and upstream version as said before [16:19] would be good to continue this work [16:19] QUESTION:seb128: I'm not ready for doing development, but could help translating to german, where to go ? [16:19] that would show what is to update [16:20] DasEi: please write questions in #ubuntu-classroom-chat [16:20] DasEi: questions on #ubuntu-classroom-chat [16:20] pochu: NEXT [16:20] directhex> QUESTION: how often does the desktop team reassess which app is used to accomplish a given task (e.g. pidgin vs empathy), and what are the criteria for a change? [16:20] seb128, ok (a pointer would be nice). Thanks [16:21] fta: there is a discussion about it on the ubuntu-desktop@lists.ubuntu.com started some months ago if you want to check the archives [16:21] directhex: good question, that's not a periodic tasks, we do look at suggestions though so that's whenever somebody do one [16:21] you can do a suggestion on the mailing list or during the weekly meetings [16:22] the team has weekly IRC meeting on #ubuntu-desktop, they are at 16:30utc on tuesday [16:22] pochu: NEXT [16:22] hggdh> QUESTION: we are based on Debian. But every so often a Debian package is found to be older than a new requirement. What is the procedure? [16:23] fta: btw, the page is this: http://norsetto.890m.com/desktop_packages.php [16:23] hggdh: we try to get work done there so we don't block on Debian [16:23] pinging the debian maintainer before starting on an update can be a good idea [16:23] usually we don't block on a reply as said though [16:23] sending the debdiff back to the debian pts is good practice too [16:24] or at least a bug there request for the update and pointing to the ubuntu work [16:24] if they do the update and we can sync we lower the ubuntu-debian delta which means less work for everybody [16:24] pochu: NEXT [16:24] Arc> QUESTION: whats the future for the default XMPP client look like? [16:25] this cycle is focussed on stabilization since we have quite some users annoying but how much rewrittes or GNOME changes have been breaking in previous cycle so we will not likely change that, it should still be pidgin [16:25] we will probably look again at empathy next cycle [16:25] pochu: NEXT [16:25] DasEi> QUESTION:seb128: I'm not ready for doing development, but could help translating to german, where to go ? [16:26] (urg should read what I type [16:26] annoying but how -> annoyed by how [16:26] yes, I suggest contacting the german translation team for that though [16:26] ubuntu-l10n-de on launchpad, they probably have a mailing list too [16:27] translations are made on launchpad or directly upstream, check with your locale team to know the details [16:27] pochu: NEXT [16:27] creek23> QUESTION: Who makes the Ubuntu theme? Wallpaper? etc? [16:27] the ubuntu artwork team [16:27] they have their own channel and I don't know how they decide on changes exactly [16:28] pochu: NEXT [16:29] I think we are running out of questions [16:29] creek23> QUESTION: Lots of opening from China, Taiwan? Why no Philippines? [16:29] (relating to job offers) [16:30] pochu: yeah, replying to those on the other channel ;-) [16:30] fta> QUESTION: what about daily builds, or builds for each commit (i refer to the last UDS opening from Mark) [16:31] (i meant "each upstream commit") [16:31] fta: that's out of the scope of the current #ubuntu-desktop ressources to do that I think but it's possible that some other team is wanting to put ressources on that, I don't know about it though, that's being discussed for some years but nobody got to do it yet [16:31] fair enough :) [16:31] that would be a good thing, a bit tricky to get right though [16:32] creek23> QUESTION: Why is "Windows key" (from the keyboard) not supported as it does in KDE? [16:32] creek23: that's a bug, what you expect to do? open the menu? or use it in shortcut [16:32] there is a gnome-control-center about it not working in shortcuts [16:33] +bug [16:33] NEXT [16:33] pochu> QUESTION: there has been a opening position for a desktop developer in terms of packaging for some time. Did you find anyone yet? [16:33] pochu: it would not still be open if we did ;-) [16:34] (hmm, so it is a bug.) [16:34] we are still interviewing candidates [16:34] if you keep it open for a few more time, I may apply :) [16:34] we didn't had some many matches for the job until now and some of those who were good decided to take a job somewhere else [16:35] thanks [16:35] Arc> QUESTION: is there any specific programming tasks open that would help gnome integration with Ubuntu? [16:35] pochu: you have the good profile so feel free to apply when you are done with universtity ;-) [16:35] :) [16:35] hum, good question [16:35] what sort of integration you are looking at exactly? [16:35] the next canonical dx team is going to work in those area [16:36] otherwise they is a lot of open bugs and request on launchpad [16:36] there is no specific list though [16:37] NEXT [16:37] creek23> QUESTION: How many exactly are the developers in the Desktop Team? [16:37] hum, good question [16:38] the ubuntu desktop team has probably around 7-8 regular contributors [16:38] and around the same number of people hanging around and doing some work every now and then [16:38] whoah! just 8?!?... o_O [16:39] so let's 7-8 people doing active work (some of them being full time canonical employees) and double the number if you count people helping on bug triage, etc [16:39] bug triage being active work too ;-) [16:39] NEXT [16:39] pochu> QUESTION: regarding the move to bzr for packaging, one of my reservations is that there will be a branch per package instead of one repository for all the desktop packages (as with pkg-gnome). Do you think this will be an advantage or a drawback? [16:40] that's something we already discussed, I don't think that makes a real different [16:40] there is some wrappers around to bzr get everything for a team [16:41] which would give you a full checkout [16:41] and that let you the option to just get and work on one component [16:41] ah, makes sense [16:41] NEXT [16:41] creek23> QUESTION: Ubuntu Netbook Remix out, is there a chance for Ubuntu Mobile Remix with GNOME in it? [16:41] I don't know enough about remix to reply to that I think [16:41] they do use GNOME applications now? [16:42] the purpose of the remix edition is that GNOME doesn't really fit on those screen [16:42] you need different interfaces on different devices [16:42] oh, I thought GNOME was used in it. [16:42] I think they modified some apps (e.g. liferea) for them [16:42] ie, the user experience is different on a notebook or tablet than on a desktop [16:43] the netbook remix uses gnome, albeit with some hacks here & there to fill more of the screen. mobile ed is something else [16:43] not the same input device, screen space, etc [16:43] NEXT? [16:43] SUGGESTION: it would attract more programmers to help with Ubuntu desktop if there was a "wishlist" for applets or specific added features, vs mixing them with "bugs" [16:43] (not really a question (: ) [16:44] that's a good remark though [16:44] the wiki has a todo and we try to tag some bugs [16:44] we could do a better job to make lists, it's not easy to classify by tasks and how easy they are though [16:45] NEXT [16:45] looks like there are no more questions [16:45] the todolist thing [16:46] you can send emails to the list if you have suggestions [16:46] or look at specs for the current cycle [16:46] those are usually tasks the team is working on [16:47] ji [16:47] hi* [16:47] no other question? [16:48] let me summarize what we need help on maybe then ;-) [16:48] - doing regular desktop updates and package new components [16:48] - triage bugs, send those upstream when they are upstream issue and get them resolved [16:50] what does he mean by "triage"? [16:50] - organize the workflow: documentation, create activity on the mailing list to encourage people to join, switch to bzr, tools to automate verifications done on every updates for example, work on the website to summarize work to get done, etc [16:50] ah [16:50] ok, so we push software to users, ie you [16:51] the users happily update to new version and notice that things stopped working the way they did [16:51] or they have request to had a feature [16:51] they open bugs on launchpad [16:51] our work is to review those bugs to decide on what is important to fix and what can wait [16:51] we don't have the resources to work on everything [16:52] and lot of those issues are in code ubuntu is not writing [16:52] ie if you get a bug in gedit it's likely in the GNOME gedit code and it should be sent to bugzilla.gnome.org so the people who are writting the code know about the issue [16:53] (there are a few questions now) [16:53] NEXT ;-) [16:53] ia> QUESTION: if you've heard about gnome-macmenu-panel, then could you tell, please, does gnome or ubuntu-desktop team plan include it "right-in-box", so user right after installation could select, which type of menu he would like to use - global(one, at top panel, for all windows) or not(traditional usage, when each window has its own menu bar) [16:53] no, first time I read about this name [16:54] feel free to discuss it on #ubuntu-desktop or mail the ubuntu-desktop mailing list to suggest that we look at it [16:54] next [16:54] Ape3000> QUESTION: So how can we help in triaging in practice? [16:54] dholbach: do you have a pointer on how to start on bug triage? ;-) [16:55] https://wiki.ubuntu.com/Bugs [16:55] https://wiki.ubuntu.com/DesktopTeam/Bugs [16:55] too [16:55] ... and https://wiki.ubuntu.com/Bugs/HowToTriage too [16:55] perhaps https://wiki.ubuntu.com/Bugs/Triaging [16:55] :-) [16:55] next? [16:56] basically pick an application you use and know and look on launchpad to bugs which are not Confirmed or Triaged [16:56] ask for details if required, etc [16:56] #ubuntu-bugs is a good place to start [16:56] pochu: NEXT ;-) [16:56] DasEi> QUESTION/idea :though not hard for me to figure out, I think it'll be nice for new users to see the files (and maybe harddrives/dev's) on their desks, as they are used from other [16:57] we decided back in warty to have a clean desktop because that's usually where people have the files they use, their background image they like to look at, etc [16:57] there is enough way to access those drivers, the computer location, the places menu, etc [16:57] I don't think we want to change the default setting but that's just a gconf setting to switch if you want to do that [16:57] NEXT [16:58] that was the last question :) [16:58] ok, thanks everybody! [16:58] thanks seb! [16:58] seb128: in ibex first even files created on desk didn't show up, is what I meant [16:58] thanks seb128! [16:58] * creek23 claps! :D [16:59] thanks!!! [16:59] thanks a lot seb128 [16:59] nice [16:59] cheers [16:59] applause [16:59] thanks [16:59] cheers [17:00] excellent - I hope you guys are going to help out seb128 in #ubuntu-desktop soon! :) [17:00] so who's here for fixing Ubuntu bugs? who's excited? :-))) [17:00] yeah!! [17:00] * Flimm waves hand [17:00] \0/ [17:00] who else? :) [17:00] You told me on Packaging 101 to come and listen here for the answer to my question, so here I am [17:00] sorry not at this point :-P [17:01] * creek23 is. [17:01] yep, partly excited because i've got a steak though too :) [17:01] dholbach: do you know when pitti will run his gdb/crash session btw? the one that didnt happen yesterday? [17:01] * charlie-tca waves [17:01] :-) [17:01] * porthose waves [17:01] mnemo: it'll be announced broadly - no worries :) [17:01] ok my friends - let's talk about fixing bugs [17:02] it's really not difficult to be part of the revolution, to help out and make Ubuntu better [17:02] especially with helpful people in #ubuntu-bugs and #ubuntu-motu [17:02] again let me point you to https://wiki.ubuntu.com/MOTU/GettingStarted as it links to all the important stuff [17:03] the important skill you need to have or develop is what I like to refer to as 'detective skills' [17:03] it sometimes takes some searching on the web, some reading of docs, some talking to people [17:04] and checking out what happened in the upstream revision control system, etc. to find a fix that's ready already or find a way to develop a simple fix [17:04] because that's what it's all about: make Ubuntu better, be part of an awesome team :) [17:04] OK, enough hand-waving - let's get to work and fix a few open bugs :) [17:05] we have myriads of lists of open bugs, lists with CD building problems, lists of packages that don't build anymore and so on and so forth [17:05] a bunch of them are linked from the MOTU/GettingStarted page [17:05] I put some efforts into agreggating those lists in Harvest [17:05] http://daniel.holba.ch/harvest [17:06] it's a tool that pulls information about various 'opportunities' from various lists and displays them per package [17:06] dholbach: how do you" check out what happened in the upstream control system?" [17:06] duanedesign: we'll get to that in a bit in one of the examples [17:06] duanedesign: can you ask the next questions in #ubuntu-classroom-chat prefixed with QUESTION: please? :) === KennethP_ is now known as KennethP [17:06] I picked a few easy ones from harvest and hope we'll get through them in time [17:07] let's start off with empathy [17:07] http://daniel.holba.ch/harvest/handler.py?pkg=empathy [17:08] it displays opportunities from various lists - not very nice, but it does its job - if you want to help out making harvest better, let me know - the code is in Launchpad [17:08] let's click on the 291533 link [17:08] it'll take us to one of the bugs that is on the "resolved-upstream" list [17:08] which means: fixed upstream, broken in Ubuntu [17:09] you can see the bug is about intrepid, version 2.24.1 all tabs having the same name [17:09] now let's click on the "gnome-bugs #535042" link [17:09] (if I'm too quick or anything is not clear, let me know in #ubuntu-classroom-chat please) === bluesmoke is now known as Amaranth [17:10] so the upstream developer says on 2008-11-24 this is fixed already and that we should check if it really is [17:10] intrepid will still have the same version, but let's check if we have a newer version in jaunty to play with [17:11] click on the 'overview' link on the launchpad bug, it'll take you to https://launchpad.net/ubuntu/+source/empathy [17:11] jaunty has 2.25.4-1ubuntu1 [17:11] and if you check ftp://ftp.gnome.org/pub/GNOME/sources/empathy/2.25/ (where new GNOME releases end up at), you'll see that 2.25.4 was released at 06.01.2009 [17:12] which is way after 2008-11-24 [17:12] this means: the bug can theoretically be closed in Ubuntu [17:12] what's important now? [17:12] _____ _____ ____ _____ ___ _ _ ____ _ [17:12] |_ _| ____/ ___|_ _|_ _| \ | |/ ___| | [17:12] | | | _| \___ \ | | | || \| | | _| | [17:12] | | | |___ ___) || | | || |\ | |_| |_| [17:12] |_| |_____|____/ |_| |___|_| \_|\____(_) [17:12] [17:12] sorry for the bold letters and stuff, I thought I'd point it out clearly :) [17:13] who here runs jaunty? [17:13] * dholbach does [17:13] * mnemo too [17:13] * fta does too [17:13] * charlie-tca too [17:13] * seb128 does [17:13] * creek23 uses Intrepid :( [17:13] if nobody else does that's fine... here's how you can still SAFELY test jaunty: [17:13] https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases [17:13] me too [17:14] it will tell you how to make use of virtual machines, separate partitions or whatnot to safely run and test the development release [17:14] so going back to our nice empathy bug [17:14] we're <-> this close to closing it and having another bug fixed [17:14] we just need to test it :) [17:15] this was a very cheesy example, but you see what it took to get to the point of "ah, this should be fixed already" [17:15] just a bit of digging and checking some other sites [17:15] and that's what it's all about :) [17:15] QUESTION: Will VirtualBox run Jaunty on WUBI? o.O [17:15] creek23: I'm sorry, I'm the wrong person to ask that, I did not use WUBI yet - you could try it :) [17:16] alright... let's move on to the next example ;-) [17:16] http://daniel.holba.ch/harvest/handler.py?pkg=gtksourceview [17:16] gtksourceview is the piece of code that does syntax highlighting in places like gedit and stuff [17:16] let's click on the 242920 link [17:17] another one on the list of resolved-upstream bugs [17:17] Question: Don't you close the bug now? [17:17] benste: did you test if it was really fixed? :) [17:17] closing on hearsay does not count :) [17:17] thought someone else did it here :-) [17:17] _____ _____ ____ _____ ___ _ _ ____ _ [17:17] |_ _| ____/ ___|_ _|_ _| \ | |/ ___| | [17:17] | | | _| \___ \ | | | || \| | | _| | [17:17] | | | |___ ___) || | | || |\ | |_| |_| [17:17] |_| |_____|____/ |_| |___|_| \_|\____(_) [17:17] [17:17] :-) [17:17] QUESTION: how do you "close" a bug? [17:18] duanedesign: you click on the dropdown thingie next to "empathy" on the launchpad page (in the yellow bar) [17:18] it'll open a menu where you can change the status to "fix released" [17:18] alright, let's crack on with the gtksourceview bug [17:19] again it's supposed to be fixed upstream, so let's take a look at the upstream bug [17:19] "gnome-bugs #139968" [17:19] http://bugzilla.gnome.org/show_bug.cgi?id=139968 [17:19] question: fix released on LP only care about the latest development version and eg not about a LTS version? [17:19] benste: yes [17:19] :-( [17:19] benste: else you need to open a bug task for the old version [17:20] https://wiki.ubuntu.com/StableReleaseUpdates is the policy for SRUs (stable release updates) [17:20] which is only for very important stuff [17:21] OK, seems like a new file was added to allow ASP stuff with gtksourceview (comment 18) [17:21] let's see what we need to do [17:22] so it was talking about it not working in gedit, let's check in jaunty [17:22] this is what I get in Jaunty [17:22] daniel@bert:~$ apt-cache showsrc gedit | grep Depends [17:22] Build-Depends: cdbs (>= 0.4.41), debhelper (>= 5.0.37.2), gnome-pkg-tools (>= 0.10), dpkg-dev (>= 1.13.19), python-support (>= 0.3), intltool (>= 0.35.0), gnome-doc-utils (>= 0.3.2), gtk-doc-tools (>= 1.0), libenchant-dev (>= 1.2.0), iso-codes (>= 0.35), libattr1-dev, libsm-dev (>= 2:1.0), libxml2-dev (>= 2.5.0), libglib2.0-dev (>= 2.16.0), libgtk2.0-dev (>= 2.13.0), libgtksourceview2.0-dev (>= 2.2.0), libgconf2-dev, python-dev (>= 2.3 [17:22] ), python-gobject-dev (>= 2.15.4), python-gtk2-dev (>= 2.12.0), python-gtksourceview2 (>= 2.2.0), scrollkeeper, liblaunchpad-integration-dev (>= 0.1.17) [17:22] daniel@bert:~$ [17:22] erm, sorry [17:22] this is what I meant to do: [17:22] daniel@bert:~$ apt-cache show gedit | grep ^Depends [17:22] Depends: gconf2 (>= 2.10.1-2), python, python-support (>= 0.7.1), libatk1.0-0 (>= 1.20.0), libattr1 (>= 2.4.41-1), libc6 (>= 2.4), libcairo2 (>= 1.2.4), libenchant1c2a (>= 1.4.2), libgconf2-4 (>= 2.13.5), libglib2.0-0 (>= 2.18.0), libgtk2.0-0 (>= 2.14.0), libgtksourceview2.0-0 (>= 2.3), libice6 (>= 1:1.0.0), liblaunchpad-integration1 (>= 0.1.17), libpango1.0-0 (>= 1.22.0), libsm6, libx11-6, libxml2 (>= 2.6.27), python2.5 (>= 2.5), scro [17:22] llkeeper, gedit-common (>= 2.25), gedit-common (<< 2.26), python-gtksourceview2 (>= 2.2.0), python-gobject (>= 2.15.4), python-gtk2 (>= 2.12.0), iso-codes [17:22] daniel@bert:~$ [17:23] you can see that gedit links against libgtksourceview2.0-0 [17:23] and this shows us which package we need to look at: [17:23] daniel@bert:~$ apt-cache showsrc libgtksourceview2.0-0 | head -n2 [17:23] Package: gtksourceview2 [17:23] Binary: libgtksourceview2.0-0, libgtksourceview2.0-common, libgtksourceview2.0-dev, libgtksourceview2.0-doc [17:23] daniel@bert:~$ [17:24] (just as a side-note: the bug was filed against gtksourceview, but it's actually gtksourceview2 we need to look at!) [17:24] if you're on jaunty, please run [17:24] apt-get source gtksourceview2 [17:24] if not, please run [17:24] sudo apt-get install devscripts; dget -x https://launchpad.net/ubuntu/jaunty/+source/gtksourceview2/2.5.3-0ubuntu1/+files/gtksourceview2_2.5.3-0ubuntu1.dsc [17:25] with these commands we download the gtksourceview2 package and see if it was fixed already [17:25] once that's done, please [17:25] cd gtksourceview2-2.5.3 [17:25] find . -name '*asp*' [17:26] on my machine it spits out ./gtksourceview/language-specs/asp.lang [17:26] so it seems an ASP language definition was added [17:26] Woohoo! [17:26] what do we need to do now? :) [17:26] right [17:26] _____ _____ ____ _____ ___ _ _ ____ _ [17:26] |_ _| ____/ ___|_ _|_ _| \ | |/ ___| | [17:26] | | | _| \___ \ | | | || \| | | _| | [17:26] | | | |___ ___) || | | || |\ | |_| |_| [17:26] |_| |_____|____/ |_| |___|_| \_|\____(_) [17:26] [17:26] and we can close the bug :) [17:28] https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases if you don't want to run jaunty on real hardware [17:28] that was another cheesy example, this time we checked the upstream bug tracker and we downloaded the source package to verify in the code [17:28] everybody having fun so far? :) [17:28] :) [17:28] open questions? [17:29] guess not, so let's crack on [17:29] please run this now: [17:29] sudo apt-get install subversion cdbs devscripts gnome-pkg-tools [17:29] we're going to need the tools mentioned there [17:30] QUESTION: Do you recommend installing on virtualbox? [17:30] Ape3000: whatever works for you, if it's KVM or virtualbox doesn't matter :) [17:30] they both work great for me [17:30] alright, let's take a look at http://daniel.holba.ch/harvest/handler.py?pkg=gnome-utils [17:31] and let's click on the 301952 link === KennethP_ is now known as KennethP [17:31] it's another bug that was resolved upstream [17:31] this time we'll get the patch for it and see what we need to do [17:31] Question: how about closing a bug that turns out was a config problem that the submitter solves in the process of the triage? [17:32] duanedesign: fine to close it, if you give a nice response explaining where the user went wrong [17:32] OK, "gnome-bugs #567834" seems to be the upstream bug that fixed the issue [17:32] let's see what the upstream guys say [17:33] Fabio says it was fixed in the development version, let's check in SVN [17:33] http://svn.gnome.org/viewvc/gnome-utils/trunk/ is where you can see what's going on in upstream's subversion repository [17:33] the first check can always be the ChangeLog file [17:34] so http://svn.gnome.org/viewvc/gnome-utils/trunk/ChangeLog?revision=8374&view=markup [17:34] unfortunately it just says that the last release was pushed out on 2009-01-09 [17:34] hmm [17:34] so let's take a look at http://svn.gnome.org/viewvc/gnome-utils/trunk/baobab/ [17:34] we'll find it has a separate ChangeLog [17:35] http://svn.gnome.org/viewvc/gnome-utils/trunk/baobab/ChangeLog?revision=8378&view=markup [17:35] The last entry was on 2009-01-15, from Fabio [17:35] saying that he fixed the issue we are talking about [17:35] that means we can't just grab a new release and upgrade the package to it [17:36] we need to grab the patch [17:36] if you want to use svn to do it (you can do it through the Web UI too), run this [17:36] svn checkout http://svn.gnome.org/svn/gnome-utils/trunk [17:36] it will download the trunk of gnome-utils [17:37] in the Web UI you can also see that the commit that fixed it was r8378 [17:37] so: [17:37] cd trunk [17:37] svn diff -r 8377:8378 [17:38] it shows the changelog entry and a small fix in baobab/src/baobab.c [17:38] we're just interested in the fix, we'll document the fix ourselves, so: [17:38] svn diff -r 8377:8378 baobab/src/ > ~/patch [17:38] now we have the patch file in ~/patch [17:38] awesome [17:39] QUESTION: Is there something that tells where SVN is for various projects? [17:39] charlie-tca: google is always a good place to check, or the upstream homepage, some packages have it documented in the source package itself [17:39] if you have a set of packages you're interested you find out very quickly where to check [17:39] unfortunately there's no "big shopping list of upstream revision control systems" yet [17:40] but we're working on importing lots of upstream RCS data into Launchpad, so we can use just launchpad and bzr everywhere [17:40] which is going to be a glorious, golden and sunshiny day [17:40] alright [17:40] to get the newest source package of gnome-utils in jaunty (so we can patch it), please run [17:41] in jaunty: [17:41] apt-get source gnome-utils [17:41] else, please run [17:41] dget -x https://launchpad.net/ubuntu/jaunty/+source/gnome-utils/2.25.2-0ubuntu1/+files/gnome-utils_2.25.2-0ubuntu1.dsc [17:42] the package gnome-utils (as almost all GNOME source packages) makes use of a tool called CDBS (and CDBS patch system) to make the packaging a bit easier [17:42] Question: what is dget? [17:42] rugby471: yes, it uses wget (or curl) to download not only the .dsc file, but also the .diff.gz and .orig.tar.gz which in summary make up the source package [17:43] now please: [17:43] cd gnome-utils-2.25.2 [17:43] maxb just tells me: [17:43] dholbach: Rather than dget, maybe mention pull-lp-source from ubuntu-dev-tools? e.g. $ pull-lp-source gnome-utils jaunty [17:43] there you go: just learned something new (just install ubuntu-dev-tools too) [17:45] rugby471 just tells me he had trouble, because the tarball was not extracted, if that happened to you, please run [17:45] dpkg-source -x gnome-utils*dsc [17:45] cool that works now [17:45] sorry folks, no idea what happened there, but let's crack on :) [17:45] thx [17:45] now we'll use a cool feature of CDBS [17:45] please run [17:45] cdbs-edit-patch 20_fix_fat32_scan_crash [17:45] what it does is: [17:46] - open a "sub shell" where you can edit the source and do all you need to make it work again [17:46] - when you type exit (or just Ctrl-D) it will close the subshell and create debian/patches/20_fix_fat32_scan_crash.patch for us [17:46] - which is the patch of the changes we did [17:46] which is awesome [17:46] in this subshell, please run [17:46] patch -p0 < ~/patch [17:47] (which will use the patch we extracted from SVN) [17:47] then, please type [17:47] exit [17:47] or hit Ctrl-D [17:48] this means we have succeeded and added the patch to the source package - fantastico [17:48] I said we're going to document it, so please run [17:48] dch -i [17:48] now [17:48] which will add a boilerplate changelog entry for you [17:49] now what we put in there should be quite verbose [17:49] we want to document well what we did and why we did it [17:49] I'll put in there something like this: [17:51] * debian/patches/20_fix_fat32_scan_crash.patch: fix segmentation fault when trying to performe "scan folder" on a fat32 partition. Taken from Upstream SVN r8378 (LP: #301952) [17:51] of course add some line wrapping to it [17:51] let's take a look at it step by step [17:51] - I reference the file I added, so it's easier to spot which files exactly I changed [17:52] - I mentioned what the bug was all about and that it's fixed now [17:52] - I mentioned where I have the patch from (add extra authority by saying that it comes from upstream) [17:52] - I mention the SVN revision, so the uploader who works on gnome-utils the next time will now: with the next upstream release I can drop the patch again [17:53] - and I refer to the Launchpad bug in a special notation: this way the bug will get automatically fixed on upload [17:53] QUESTION: Shouldn't I use my pgp key with the dch? [17:53] Ape3000: if you mean the email address you have on your GPG key, yes [17:53] QUESTION: does the debian build process automatically apply debian/patches/* to the orig before compiling? [17:53] mnemo: yes, that's what simple-patchsys.mk in debian/rules does [17:53] QUESTION: Would you also push this patch to debian? [17:54] porthose: I'm going to say a bit more about what we're going to do with it in a sec [17:54] now let's save the file and please run [17:55] debuild -S -us -uc [17:55] to rebuild the source package with the new entry [17:55] if all goes well a [17:55] ls .. [17:55] should show you gnome-utils_2.25.2-0ubuntu2.dsc amongst others === Philipp_ is now known as HEP85 [17:55] now please run [17:55] cd .. [17:56] debdiff gnome-utils_2.25.2-0ubuntu1.dsc gnome-utils_2.25.2-0ubuntu2.dsc [17:56] and post the output to a pastebin and post the link in this channel [17:56] QUESTION: is there a good reference for all of the options of debuild? I notice some mentioned in HOWTO's that aren't in the manpage directly, so either I'm missing them or there's something a bit more complex going on. [17:57] WalterMundt: check https://wiki.ubuntu.com/PackagingGuide and man dpkg-buildpackage and man debuild [17:57] ok, a few words until you posted your results somewhere: [17:57] http://pastebin.com/m7b422082 [17:57] - in the specific case of gnome-utils you would probably just wait for the next release (which is regular and in just a few days) [17:57] - in all other cases, you would [17:57] http://paste.ubuntu.com/107870/ [17:57] http://paste.ubuntu.com/107868/ [17:58] + attach the resulting patch to the bug report [17:58] + and subscribe ubuntu-main-sponsors, who will review the patch and upload it for you because they like it [17:58] http://wklej.org/id/42593/ [17:58] dinxter: I'd wrap the text at 80 chars per line, other than that: good work [17:59] Ape3000: same as for dinxter :) [17:59] You mean I should wrap the ChangeLog line? [17:59] rugby471: good work, I'd add a reference to where the patch comes from and which LP bug it fixes [17:59] Ape3000: yep [17:59] Quintasan: good work, same as Ape3000 [17:59] wow... any more patches? [18:00] and don't forget one thing: [18:00] _____ _____ ____ _____ ___ _ _ ____ _ [18:00] |_ _| ____/ ___|_ _|_ _| \ | |/ ___| | [18:00] | | | _| \___ \ | | | || \| | | _| | [18:00] | | | |___ ___) || | | || |\ | |_| |_| [18:00] |_| |_____|____/ |_| |___|_| \_|\____(_) [18:00] [18:00] https://wiki.ubuntu.com/MOTU/GettingStarted [18:00] https://wiki.ubuntu.com/SponsorshipProcess [18:00] https://wiki.ubuntu.com/PbuilderHowto [18:00] for more info :) [18:00] get wild, use harvest, make me proud! :) [18:01] thanks a bunch everybody [18:01] you are awesome [18:01] * dholbach hugs y'all [18:01] * james_w hugs dholbach [18:01] next up is Mr james_w! [18:01] big round applause for James! [18:01] * rugby471 feels his life is now complete [18:01] thanks daniel!!! [18:01] This was very good session and I really learned lots of things. [18:01] thanks daniel [18:01] http://daniel.holba.ch/harvest for more Harvest goodness :-) [18:02] * porthose *applause [18:02] thx [18:02] thanks daniel great session [18:02] thanks [18:02] Harvest looks especially interesting [18:02] james_w is going to talk about Bazaar and Packaging which is going to make 1) your life easier, 2) you very happy [18:02] \o/ [18:02] Rock On everybody! [18:03] I'm just getting set up still, I had a great idea about 10 minutes ago, so I'm changing the session a bit [18:03] thnks it was great!! [18:03] is anyone still running Hardy? [18:03] nope [18:03] Not me [18:04] Yes [18:04] I borrow somebody else's comp to test stuff on Hardy [18:04] as Mr. Holbach said, we're going to be looking at bzr for packaging [18:05] we're actually going to fix that baobab bug again, but this time using bzr [18:05] for that we need some extra tools, so if you would all [18:05] sudo aptitude install bzr bzrtools bzr-svn bzr-builddeb [18:05] that would be fantastic [18:08] I'm working on a project called "Distributed Development" that aims to make bzr really useful for packaging [18:08] and at the same time use bzr for packaging more in Ubuntu [18:08] as part of that I have created the branches you can see at http://package-import.ubuntu.com/ [18:08] these will be moved to launchpad soon, the launchpad developers are working hard to accommodate them. [18:09] until that time they live there [18:09] so you can click through there and find the gnome-utils branches [18:09] QUESTION: is this currently supported for PPAs on launchpad? [18:09] Arc: you mean bzr for PPAs? [18:09] yes [18:09] sort of [18:10] you can use bzr and then upload a source package [18:10] there are plans in the works to allow you to just point to a branch and ask for it to be built in your PPA [18:10] QUESTION: packages-import for both main and universe? [18:11] yup [18:11] to show off some of the things that it will be possible to do I have created a project on staging.launchpad.net [18:11] you can see it at https://code.staging.launchpad.net/gnome-utils-ubuntu [18:12] and once you have the above packages installed you can grab the source by typing [18:14] bzr branch lp://staging/gnome-utils-ubuntu [18:14] (the staging is just there as we are experimenting) [18:15] also it will be written "lp:ubuntu/jaunty/gnome-utils-ubuntu" once launchpad hosts the branches [18:15] QUESTION: where can I upload any commits I make to bzr branches from packages-import? [18:15] I would just recommend pushing them to your +junk area for now [18:16] once launchpad hosts them you will be able to push to [18:16] lp:~your-user/ubuntu/jaunty/gnome-utils [18:17] once you have branched the code then we can work on the fix [18:17] Mr. Holbach helpfully told us that the fix is between revisions 8377 and 8378 of http://svn.gnome.org/svn/gnome-utils/trunk [18:18] now, we installed bzr-svn, meaning we can access this URL using bzr [18:19] (I've just noticed I also have a bzr plugin named "sandwich", I wonder what that does) [18:21] bzr diff http://svn.gnome.org/svn/gnome-utils/trunk -c 8378 [18:21] that will show us the changes in revision 8378 in SVN [18:21] except that we are not accessing a native bzr branch, so we have to say [18:21] bzr diff http://svn.gnome.org/svn/gnome-utils/trunk -c svn:8378 [18:22] because 8378 is an svn revision number [18:22] (when you run these commands it will spin a progress bar for a little while as it does the translation) [18:25] as well as making packaging branches available we are working on making bzr versions of the SVN projects available [18:26] so one day you won't have to wait for this translation to be done, you can just access the bzr version [18:33] right [18:33] so it's the same diff we saw an hour ago :-) [18:33] interesting eh? :-) [18:34] but we don't just want to see the diff, we want to pull in the changes [18:34] we want to merge them [18:34] bzrtools provides a nice "patch" command we can use for this [18:34] so you can "bzr patch file" and it will apply it [18:35] or you can pipe in a patch so "bzr diff http://svn.gnome.org/svn/gnome-utils/trunk -c svn:8378 | bzr patch" should work [18:35] if you were in the last session and have the patch file laying around then "bzr patch thatfile" will work [18:36] interestingly, it should also work over any transport [18:36] so "bzr patch http://some-server/some-patch-someone-has-pointed-you-to" should work [18:37] e.g. "bzr patch http://svn.gnome.org/viewvc/gnome-utils/trunk/baobab/src/baobab.c?view=patch&r1=8378&r2=8377&pathrev=8378" [18:38] to apply the part of the patch that makes the code change [18:38] once you've applied the patch however you chose to do it [18:39] you can write a changelog entry to go along with it [18:39] run "dch -i -D UNRELEASED" [18:39] and type in your message [18:39] once done, save and quit [18:39] and run "debcommit" [18:40] (I assume you all have devscripts installed from the last session for those last two commands) [18:41] make sure include the bug number as "LP: #301952" in the changelog [18:42] once you are done you can run "bzr log -r -1" and "bzr diff -c -1" to see your message and the changes [18:42] (or install bzr-gtk and run "bzr viz") [18:42] now you want to build the package to test it [18:42] simply run "bzr builddeb -S" [18:43] that will download the tarball that you need, and build you a source package [18:43] you can then build that in pbuilder or similar, or sign it and push it to your PPA [18:43] bzr: ERROR: A Debian packaging error occurred: uscan failed to retrieve the upstream tarball [18:43] ah, you don't have deb-src entries for jaunty in your sources.list [18:45] you can add them or run "(cd .. && wget http://archive.ubuntu.com/ubuntu/pool/main/g/gnome-utils/gnome-utils_2.25.2.orig.tar.gz)" [18:45] once you are happy with the fix you want to get this uploaded to Ubuntu [18:45] so it needs to be merged in to the main packaging branch [18:45] for that we use launchpad [18:45] so first you need to push your changes back to launchpad [18:46] "bzr push lp://staging/~YOUR_LP_USERNAME/gnome-utils-ubuntu/fix-301952" [18:46] where YOUR_LP_USERNAME is your launchpad username, and the last part of the URL is anything you want [18:47] this will fail if you haven't registered you SSH key with launchpad yet [18:48] oh, and also if you haven't yet run "bzr launchpad-login" [18:48] "bzr launchpad-login YOUR_LP_USERNAME" [18:49] https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair for information on registering your launchpad SSH key [18:49] iulian> QUESTION: Can Ubuntu devs commit to the main branch? If yes, where will it be located? [18:49] iulian: yes, if they can upload the package [18:49] once the branches are hosted on launchpad [18:50] once you have pushed you can go to https://code.staging.launchpad.net/gnome-utils-ubuntu and you should be able to see your branch [18:54] when you can see your branch the next step is to propose it for merging in to the main branch [18:54] if you click on the link to your branch you can click "Propose for merging in to another branch" [18:56] in the next form you can just add your explanation of what you have done, the "cover letter" of the change [18:57] you will end up with something like https://code.staging.launchpad.net/~james-w/gnome-utils-ubuntu/fix-301952/+merge/2999 [18:57] which a developer can then review and merge [18:58] and if you also look at the bug report on staging you will see that under the description it now links to a branch that has the fix https://bugs.staging.launchpad.net/ubuntu/+source/gnome-utils/+bug/301952 [18:58] this went from the changelog -> bzr because of debcommit [18:59] then launchpad noticed that and added the link for us [18:59] we're out of time unfortunately [19:00] sorry for rushing the last bit [19:00] that's what happens when you decide to change your session at the last minute :-) [19:00] saludos [19:01] thanks james === pochu_ is now known as pochu [19:01] james_w: thanks for the great session :-D [19:01] I'm happy to help people with things outside the session, but we have to make way for the next session now [19:01] Thank you james_w [19:01] Thanks James, that was great. [19:01] thanks for playing along [19:02] thanks, some knowledge wont hurt ;) [19:02] WalterMundt> QUESTION: I notice that committing to bzr this way doesn't create a patchfile under debian/ -- does that get handled at some other stage? [19:02] good question [19:02] you can still create that patch file manually if you like [19:02] it's better not to do that if you are using bzr, but while we still use patch systems you can do that step [19:03] bzr doesn't stop you, it could automate it better though [19:03] but now we have JontheEchidna with "Kubuntu Bug Squishing" [19:03] \o [19:03] Hi, my name's Jonathan [19:04] Welcome to my course on bug squishing in Kubuntu. [19:04] As you may recall, this previous Ubuntu OpenWeek I did a course on triaging bugs. [19:04] Even though triaging bugs is an important part of Quality Assurance, you do have to eventually, well, fix bugs. :-P [19:05] A properly triaged upstream bug usually does get fixed by upstream. But some times, for various reasons, we must make fixes to our KDE packages ourselves before the next KDE release. [19:05] This is especially true when the problem is not with KDE itself, but with our packages. [19:05] Aside from packaging bugs, we may also need to apply upstream fixes to our packages when the following happens: [19:05] a) A severe bug has been fixed upstream for a future release, but the severity of the bug warrants early inclusion of packages. [19:06] b) At the end of a development cycle especially, we start including bugfix patches. This is because once we include the most recent upstream release before the next Kubuntu release, some upstream bugs get fixed. Since the next bugfix release won't be coming by default, we take the patch and apply it to our KDE packages. An excellent example would be bug 314016, which has yet to be fixed. [19:07] Luckily, in most cases, upstream has done most of the bug fixing. Aside from packaging bugs, all we need to do is include the upstream patch in our packaging. [19:07] QUESTION: How are treated .po file for localization, for languages with more then 2 forms of plurals (eg. nplurals=3), in Kubuntu. [19:08] Our packaging extracts the .po files and through some magical way or another Rosetta imports them [19:08] Right before the intrepid release there were a few serious bugs found with rosetta in regards to how it imported translations [19:08] and once they did get imported, there were some bugs with plural forms, etc [19:09] The last time I checked there were some updates langpacks released to intrepid-updates [19:09] While this is quite unforunate, it's not exactly a bug with our KDE packages, and is somewhat out of the scope of this talk. [19:10] Steps have been taken to fix this for the future though. :-) [19:10] It has been a source of frustration for all of us, I assure you [19:10] Continuing: [19:10] For this session I will walk you through fixing a bug that has been fixed upstream for KDE 4.2. [19:11] This is how myself or another kubuntu hacker would go about fixing a bug [19:11] Since the fix was brought about by a change in behavior, it was not added as a bugfix for the KDE 4.1 branch. [19:11] The bug is somewhat more than trivial, though, so it would be a good idea to fix it since we do have to support KDE 4.1.4 in Intrepid for a year. [19:12] The bug in question is bug 314016. (https://launchpad.net/bugs/314016) [19:13] Basically, a new feature in KDE 4.1 crapped up Left-to-Right text handling in Kate, severly crippling its usefulness for LTR languages [19:13] QUESTION: What do you mean by "KDE 4.1 branch"? I thought that KDE 4.1 is a release. [19:13] Good question! [19:13] Right before every 4.x release, trunk is branched [19:14] From the release on, bugfixes will be aggregated to that branch and be released in bugfix releases [19:15] Right before KDE 4.1 was released it was branched into the "4.1 branch". Since then fixes have been backported from trunk by KDE to this branch, and they have released 4 bugfix releases since then [19:15] with the most recent one being 4.1.4 [19:16] These branches are for bugfixes only, so new features and bugfixes with rather widespread changes are generally not included [19:16] So we as a distro can choose to include fixes ourselves [19:16] which is what we're going to do today [19:17] Since Kate (the application affected by the bug) is part of the kdesdk package, we need to get its source [19:17] Since this would be an update to a stable release of Kubuntu we will need to modify the current kdesdk for intrepid-updates: https://edge.launchpad.net/ubuntu/intrepid/+source/kdesdk/4:4.1.3-0ubuntu1~intrepid1 [19:18] I should note that we do have kdesdk 4.1.4 in intrepid-proposed which will be copied to -updates after proper testing is done. The bugfix update we are doing today won't be uploaded to -proposed until KDE 4.1.4 is out. [19:18] since having two stable release updates in -proposed is generally frowned upon [19:19] Going through the Stable Release Update could be half of another session itself, so we will focus on including the fix to our packages [19:19] To start off, we will download the 3 files listed under "download" in the page I just linked to. [19:20] I don't exactly know the exact technical range of those of you reading, so bear with me if this seems like common knowledge [19:20] and don't be afraid to ask me to explain better [19:22] I'll give y'all a chance to download the source for a bit whilst I compose what I want to do next [19:23] Once we've downloaded the source package, we'll need to unpack it. [19:23] navigate to the directory and do a standard "dpkg-source -x *.dsc" to unpack the source package. [19:24] If you're using dolphin you could just press alt+f4 to get a terminal in the directory you are in :D [19:24] <3 KDE [19:24] er, not alt+f4 [19:24] just f4 [19:24] <.< [19:25] Once extraction is done there should be a folder entitled "kdesdk-4.1.4" in your directory [19:25] This is the unpacked source + our packaging. The packaging is located in the debian/ directory [19:26] cd to kdesdk-4.1.4, this is where we'll mostly be working from [19:27] I think I'll take this time for questions if there are any :-) [19:30] or wait for people to catch up ;-) [19:31] The Debian and Kubuntu KDE packaging teams generally favor quilt as their patch system. It is quite nice once you get used to it. [19:32] Quilt is a system for managing patches for programs [19:32] 'ello.. I am new.. there is a list of events on UbuntuDeveloperWeek but it is not clear to me how to actually attend one [19:32] and for keeping them all in order [19:33] darkblue_B: you're in the right place. The talks are being given here. You can chat and ask questions in #ubuntu-classroom-chat :-) [19:33] thx [19:33] to attend a session all you need to do is just join this channel and listen [19:33] :) [19:33] Using quilt we will add the patch KDE has made to our packages [19:34] to start off we make a symlink from kdesdk-4.1.3 to kdesdk-4.1.3/debian/patches [19:34] so from kdesdk-4.1.3 directory: [19:35] ln -s debian/patches patches [19:35] this is so we can work from the top level of the source tree [19:35] and quilt will still think we're in the patches directory [19:36] so first we'll need to give our new patch a name [19:37] quilt new kubuntu_03_fix_paragraph_direction.diff [19:37] This will "create" a new patch entitled kubuntu_03_fix_paragraph_direction.diff [19:38] now that we have the patch named we will need to get the actual patch from upstream [19:38] As it so happens, the bug report handily links to the webpage of the svn revision that fixed this bug: http://websvn.kde.org/?view=rev&revision=905112 [19:39] From that page, open the "text changed" links for both files in new tabs [19:39] and in these tabs click the "patch" link on the top toolbar [19:40] both should open up the patch in Kate or whatever your default text editor is if you are using Konqueror [19:40] you can save them as patch1.diff and patch2.diff [19:41] oh crap, actually I had you guys download the wrong source package [19:41] I forgot that Kate actually has some of its code in kdelibs [19:42] download kde4libs from here: https://edge.launchpad.net/ubuntu/intrepid/+source/kde4libs/4:4.1.3-0ubuntu1~intrepid1 or via apt-get source as before [19:42] extract, make the symlink, etc [19:43] my bad :-( [19:43] I'll give everybody time to catch up [19:43] download, dpkg-source -x *dsc; cd kde4libs-4.1.4; ln -s debian/patches patches; quilt new kubuntu_03_fix_paragraph_direction.diff [19:44] and we should be back where we were after that [19:44] * JontheEchidna takes this opportunity to throw away his empty soda can [19:45] ok, so is everybody good up to this point? [19:45] Ok, I would recommend saving patch1 and patch2.diff to the same directory kde4libs-4.1.4 is in [19:46] as we can see from the svn page, 2 files are affected: [19:46] http://websvn.kde.org/?view=rev&revision=905112 [19:46] we need to tell quilt that we are going to be changing these two [19:47] from the kde4libs-4.1.3 directory: [19:47] quilt add kate/render/katerenderer.cpp [19:47] and [19:47] quilt add kate/render/katerenderer.h [19:48] now we will make the changes to the actual files themselves [19:48] since the kde svn structure is a bit different that the folder structure we have now, the patches won't apply as they are [19:48] Where you see this: [19:49] --- trunk/KDE/kdelibs/kate/render/katerenderer.cpp 2009/01/03 17:58:16 905111 [19:49] +++ trunk/KDE/kdelibs/kate/render/katerenderer.cpp 2009/01/03 17:58:42 905112 [19:49] it should probably be more like: [19:49] --- kate/render/katerenderer.cpp 2009/01/03 17:58:16 905111 [19:49] +++ kate/render/katerenderer.cpp 2009/01/03 17:58:42 905112 [19:49] that^ [19:49] make the changes for both files and save [19:49] (patch1.diff and patch2.diff [19:50] once that's done we can apply the patches using linux's patch command [19:50] patch -p0 < ../patch1.diff [19:50] patch -p0 < ../patch2.diff [19:51] oh, uh, actually I forgot something important before that [19:52] nevermind [19:52] now run quilt refresh [19:54] with luck it should say that the patch was refreshed [19:54] and if you'll check you should see a new file in debian/patches [19:55] namely your patch :-) [19:55] the patch's name will also have been added to the series file [19:55] run quilt pop -a to revert the changes you have made directly to the source files [19:56] when the package is built your patch will be applied automagically [19:56] Oh, I should say that at the beginning it's a good idea to apply all existing patches after you make the patches symlink [19:56] quilt push -a would do that [19:57] it helps prevent things from going wrong [19:57] anyway, after that you'd run dch -i from kde4libs-4.1.4 to add a changelog entry [19:59] it'd look something like this: [19:59] kde4libs (4:4.1.3-0ubuntu1~intrepid1.1) intrepid; urgency=low [19:59] * Add kubuntu_03_fix_paragraph_direction.diff to fix KDE bug [19:59] 178594. (LP: #314016) [19:59] -- Jonathan Thomas Wed, 21 Jan 2009 14:57:50 -0500 [20:00] after that you'd run debuild -S -sa and you'd have yourself a fixed package [20:00] you coudl then speak to the kubuntu doods about sponsoring your package [20:01] which we would be glad to help out with [20:01] My time is just about up, feel free to throw questions, tomatoes, Windows 7 beta CDs, etc at me in #kubuntu-devel [20:02] Thanks :D [20:02] Thanks JontheEchidna [20:02] ^_^ [20:02] Next up is g VMBuilder to create tests environments -- Søren Hansen and Nicolas Barcet will entertain you with virtual machines and the fantastic vmbuilder. Need a clean test environment for something? Don't want to run the latest development release on actual hardware yet? These two fine men have the answer for you. [20:03] Welcome everyone and thanks for attending this presentation about [20:03] __ ___ __ [20:03] /\ \ __ /\_ \ /\ \ [20:03] __ __ ___ ___\ \ \____ __ __/\_\\//\ \ \_\ \ __ _ __ [20:03] \ \ \_/ |/\ \/\ \/\ \ \ \L\ \ \ \_\ \ \ \ \_\ \_/\ \L\ \/\ __/\ \ \/ [20:03] \ \___/ \ \_\ \_\ \_\ \_,__/\ \____/\ \_\/\____\ \___,_\ \____\\ \_\ [20:03] \/__/ \/_/\/_/\/_/\/___/ \/___/ \/_/\/____/\/__,_ /\/____/ \/_/ [20:03] * nxvl waver [20:03] Originally Soren Hansen, the author and maintainer of vmbuilder was supposed to run this presentation with me, but he unfortunately got a bad flu and I'll therefore will have to do this alone. [20:03] waves* [20:04] Well not completely alone, I bet mathiaz and zul are around to make sure I don't say anything stupid ;) [20:04] * zul waves [20:04] if it's really stupid, I will make sure everyone notices. [20:04] soren, what is vmbuilder? (you may ask) [20:04] ehe, I meant so not soren ^ :) [20:05] vmbuilder is a python tool that allows to create virtual machine images on the fly, without the need to start an installer in an hypervisor. [20:05] vmbuilder can create images for KVM, Xen, VMWare and for Amazon EC2. [20:05] And soon hopefully for virtualbox too... [20:05] On a reasonably powerfull machine with a local package cache (for example apt-proxy or apt-cacher), the creation of a minimal virtual server (aka JeOS) can take less than a minute. [20:06] jmarsden|work: please use #ubuntu-classroom-chat for comments [20:06] As a python tool, it is first of all a library with a very powerfull plugin architecture. [20:07] One of the plugins that is provided is a CLI (command line interface), and anyone could write another plugin to provide a GTK interface or use the vmbuilder library to create a web service. [20:07] Apart for the front end plugin mechanism, there are 2 other types of plugins that are used in vmbuilder: Hypervisors and Distributions. [20:07] The distribution plugin would allow for someone to easily extend vmbuilder for other distributions, but at this time the only available one is Ubuntu. [20:08] The same is true for the hypervisor plugin, and it seems that jmarsden|work is voluteering some work :) [20:08] Contributions are always welcome! [20:09] The first implementation of vmbuilder was on hardy as a shell script that used to be called ubuntu-vm-builder. [20:09] When Soren rewrote in python for intrepid, the source package was renamed python-vm-builder and contains a binary package called ubuntu-vm-builder which is just a wrapper to the old CLI to maintain upward compatibility. [20:10] Now that we have covered what vmbuilder is (in a nutshell), let's explore what you could use it for as a developer. === weboide_ is now known as weboide [20:10] A couple scenarios come to mind, but I'm sure there are many others. [20:11] 1/let's imagine that you want to test something (a program that you wrote, an upgrade, a bug) in a clean environement. [20:11] chroot is generally great for this, but is not really what we could call a complete environment. [20:11] Using vmbuilder, you can generate a virtual machine on the fly that contains whichever package and configuration that you want almost as quickly as you would generate a chroot environment. [20:12] You can then start the machine in your favorite hypervisor and start testing. [20:12] Some of the great options vmbuilder provides are the ability to chose wich series you want (dapper, gutsy, hardy, intrepid, ...) and, to the difference of pre-built images that you would duplicate, is building machines from the latest versions of the packages in the repositories. [20:13] Since vmbuilder does not require any user interaction to run, this can be scripted and made part of build or test process. [20:14] 2/let's imagine that you want to deliver your package/packages/application/integration as a pre-built virtual machine for various hypervisor (providing so called "virtual-appliances", for example). [20:14] The traditional way would imply creating reference virtual images for each target environements and each time you updated your code, after building your package you would have to: [20:15] a- start each vm [20:15] b- update your package in each vm manually [20:15] c- clean up the vm [20:15] d- save it [20:15] e- send it to testers/users [20:16] Since vmbuilder knows about your various Hypervisors, it is very easy to integrate this work in your build scripts so that your virtual images are almost ready to ship once your build process is completed. [20:16] To make things even easier, vmbuilder includes three "sub-scripts" features that can be specified: [20:17] a- an "exec" script that is called during the machine build process just after finishing the the installation. The script can chroot within the target machine and make additional changes. [20:17] b- a "first-boot" script that is copied to the virtual machine and executed in batch mode the first time the vm will boot [20:18] c- a "first-login" script that is copied as well to the vm and executed as the user the first time someone logs-in to the vm (and therefore allows to perform some final interactive setup). [20:18] ok, now that I have covered the main use cases, I'll try to answer the first few questions before we move on [20:18] QUESTION: What do I need to use KVM? [20:19] You need a processor that supports hardware virtualization [20:19] there is a detailed step by step procedure to test this on http://help.ubuntu.com/communtity/KVM [20:20] err community [20:20] QUESTION: are there plans to also support qemu/kqemu? [20:21] That really should no be too hard to had, but it is not on any official roadmap, AFAIK [20:21] contributions, again, are very welcome [20:21] QUESTION: vmbuilder on gutsy? [20:22] unfortunately not. ubuntu-vm-builder was first developped on hardy [20:22] we badly need kpartx for it, and it is not available before hardy [20:23] QUESTION: which one should I choose between KVM, Xen, VMWare and for Amazon EC2 (if I got a machine that supports hardware virtualization and I want to do ubuntu package testing for instance) ??? [20:23] it all really depends on your use case [20:23] VMWARE (esx) is certainly the most complete virtualization solution available today [20:24] but it has some hard dependency, and is not really free software [20:24] Xen is nice if you processor does not have hardware virtualization extension [20:24] but then it will only provide paravirtualized os virtualization [20:25] and it is a BULKY thing to maintain in a distro [20:25] so that's mainly why, if your use case is server virtualization, we prefer KVM [20:25] ok, lets move on [20:26] To start using vmbuilder, you need to first install its package: [20:26] $sudo apt-get install python-vm-builder [20:26] note that if you want to create EC2 images, you will need to install the python-vm-builder-ec2, which, for licence reasons on the AMI tools, had to be made a separate package and placed into multiverse. [20:27] Once the install is complete, the first thing to do is to have a look a the help. [20:27] As I said before, python-vm-builder uses a plugin mechanism. [20:27] This implies that you will have different sets of options depending on the hypervisor and distribution that you pick. [20:28] This is the reason why the man page or a basic 'sudo vmbuilder --help' will only list options that are common to all hypervisors or distributions. [20:28] To get all options displayed, you need to specify your target hypervisor and distribution. For example try doing: [20:28] $sudo vmbuilder kvm ubuntu --help [20:28] or [20:29] $sudo vmbuilder xen ubuntu --help [20:29] and notice the additional options provided in each case. [20:29] So now, assuming that you all are going to use vmbuilder intensively, let's start setting up a package caching system. [20:30] Soren likes apt-cacher while I've preferred apt-proxy. [20:30] Since the later is what I know and is quite simple to enable, I'll invite you to: [20:30] $sudo apt-get install apt-proxy [20:30] once this is done, apt-proxy will immediately start listenning on all your interfaces on port 9999. [20:31] There are multiple options you can set on /etc/apt-proxy/apt-proxy.conf, but the default will work very nicely for our purpose. [20:32] In order for apt-proxy to be used by vmbuilder automatically, we could very well [20:32] add the option "--install-mirror http://127.0.0.1:9999/ubuntu" each time we would invoke vmbuilder, but since I am quite lazy, I have defined this as a permanent option in my ~/.vmbuilder.cfg file by putting in the following two lines: [20:33] [ubuntu] [20:33] install_mirror = http://127.0.0.1:9999/ubuntu [20:33] in fact, any command line option that can be passed to vmbuilder can added to this config file, and you can even specify an additional config file that uses the same format using the --config option. [20:34] not that the format of the config file changed between hardy and interpid... so I assume your are all on intrepid or jaunty here [20:35] Another option that speeds up the creation of vm is the --tmpfs one, which will use a ramdisk to store temporary file. [20:35] I have added in my ~/.vmbuilder.cfg file the following 2 lines: [20:35] [DEFAULT] [20:35] tmpfs = - [20:36] how is everyone doing so far? [20:36] * rmcbride nods [20:36] ok, so we are now ready to start building our first image. [20:37] For this example we'll build and equivalent of an Intrepid JeOS using the following command: [20:38] $sudo vmbuilder kvm ubuntu --suite intrepid --flavour virtual --arch i386 --verbose [20:38] I do not think the above options need much comments, do they? [20:39] The first time you will build a machine for a new suite, it will obviously take a bit longer as apt-proxy is not loaded. [20:40] While your vm is building, let's open the floor to questions. [20:40] In the absence of Soren, I may not be able to answer some of them [20:40] in which case I'll make sure to write them down and provide you with valid answers on my blog as soon as I can get them [20:40] QUESTION: sry to dwell on this but why could KVM only be used for server testing? cant I run X.org inside a KVM? [20:41] well, sure you can run X.org inside a KVM [20:41] but the interface has not really been tuned to provide you with the best experience possible for full desktop vritualization [20:42] but, I do use kvm for testing gnome once in a while [20:42] and apart from a few quirk, it is quite useable [20:42] I would not recommend it for any real usage on a daily basis though [20:43] qUESTION: what I have done in the past is boot from an .iso and then use rtegular tools to make mods [20:43] this is a CLI approach based on, listing all the pkgs you want to install in a text file, for example? [20:44] (please try to write your question starting with QUESTION without breaks) [20:44] yes, this is the general approach, yes [20:45] UESTION: when running vmbuilder, it printed a bunch of these: "Can not write log, openpty() failed (/dev/pts not mounted?)" is that a problem? [20:45] no, actually the reason why you saw those is because we enabled the --verbose option [20:46] but, unless vmbuilder stops before sayng it is done, these error are just transient [20:46] QUESTION what about custom downloads.. eg not debian/ubuntu packages.. not covered by this approach? [20:46] this is the reason why we have multiple scripts options [20:46] as I described earlier [20:47] you could have a --exec script [20:47] that download something with wget [20:47] and untars it wherever you want [20:48] ok, is everyone done building their first vm? [20:49] * sebp nods [20:49] * Quintasan nods [20:49] another very inresting part of vmbuilder are templates [20:50] have a look at what is inside /etc/vmbuilder/ [20:50] each of these directory contains base templates for file that we'll use for configuration during the build process [20:51] for example, to enable bridging in our vm, we'll need to modify the libvirt template [20:51] $mkdir -p mytemplates/libvirt [20:52] $cp /etc/vmbuilder/libvirt/* mytemplates/libvirt/ [20:52] we can then edit mytemplates/libvirt/libvirtxml.tmpl [20:52] and change the interface section of it to: [20:52] [20:52] [20:52] [20:53] and then specify which template set to use by adding the following to our command line: [20:53] --templates mytemplates [20:54] QUESTION: how can I start the kvm I just built? [20:54] this brings me to the --libvirt option [20:54] assuming that libvirt is installed and running [20:55] (if it is not, have a look at https://help.ubuntu.com/community/KVM/Installation ) [20:56] then you can pass "--libvirt qemu:///system" to the command line [20:56] which will automatically add the generated vm as a livirt domain [20:56] which can be started immediately [20:57] https://help.ubuntu.com/community/KVM/Managing#From%20the%20shell gives an overview of how to manage running vm [20:58] I you do not want to use libvirt, see https://help.ubuntu.com/community/KVM/Directly [20:59] QUESTION: kvm is a standard'ish ubuntu VM I take it? [20:59] yes, it is the official virtualization technology since hardy [20:59] have a look at http://www.ubuntu.com/products/whatisubuntu/serveredition/technologies/virtualization [21:00] For additional reference, apart for the --help, I would like to point you to a tutorial I have writen on using VMBuilder which is available at https://help.ubuntu.com/community/JeOSVMBuilder [21:00] Hope this was a useful session for most of you and feel free to drop by #ubuntu-virt at any time if you have additional questions or just want to say hi :) [21:01] Thanks nijaba, this is very helpful :) [21:01] thanks nijaba! [21:01] Thanks for attending and asking very good questions everyone :) [21:01] thanks nijaba [21:02] I'm glad I could answer most of them [21:02] nijaba: hey, I started run.sh and I get to the prompt... but what is the password to my new VM ?? [21:02] mnemo: by default user and password are ubuntu [21:03] sweet [21:03] thanks [21:03] of course there is a command line option to change that too :) [21:03] great session btw!! :)