| Matr|X | hello i need help in ubntu plz | 01:03 |
|---|---|---|
| jmarsden|work | Matr|X: Ask in #ubuntu, not in here, #ubuntu-classroom is for classes at specific times. | 01:10 |
| Matr|X | thx | 01:11 |
| Matr|X | sorry | 01:11 |
| Lucy | I'm having a bit of trouble getting the right performance from all but one SATA drives. instead of around 110 mb/s with hdparm -t i get around 50-60 mb/s . Help anyone ? | 01:15 |
| istaz | Ask in #ubuntu, not in here, #ubuntu-classroom is for classes at specific times. (c) jmarsden|work | 01:15 |
| === fabrice_sp_ is now known as fabrice_sp | ||
| somaunn | i'm looking for someone who have knowledges of sed | 07:02 |
| techno_freak | somaunn, #bash | 07:21 |
| somaunn | techno_freak: thank you | 07:47 |
| === asac_ is now known as asac | ||
| === lan3y is now known as Laney | ||
| CrownAmbassador | Does anyone have the getting started talk from Monday? It is not on http://wiki.ubuntu.com/MeetingNotes | 13:28 |
| istaz | CrownAmbassador: the one on this channel? | 13:29 |
| CrownAmbassador | istaz: yeah | 13:30 |
| istaz | (the link you gave doesnt exist) | 13:30 |
| istaz | CrownAmbassador: I can send you my log if you want | 13:30 |
| MarkoKaa | There it is https://wiki.ubuntu.com/MeetingLogs/devweek0901/GettingStartedEN | 13:30 |
| CrownAmbassador | istaz: oops! Should be MeetingLogs | 13:30 |
| CrownAmbassador | MarkoKaa: Thanks. Seems like the link to it on the https://wiki.ubuntu.com/MeetingLogs does not work. | 13:32 |
| MarkoKaa | and also you can go to the logs by clicking the topic on https://wiki.ubuntu.com/UbuntuDeveloperWeek | 13:32 |
| CrownAmbassador | MarkoKaa: Thanks. | 13:34 |
| MarkoKaa | No problem | 13:34 |
| CrownAmbassador | Does anyone know when Pitti will be doing his deleted talk? | 13:36 |
| Ape3000 | I just packaged my first package. It's 0.6.5 version of typespeed. There is 0.6.4 available on the Ubuntu repos. | 15:05 |
| Ape3000 | https://launchpad.net/~ape3000/+archive | 15:05 |
| Ape3000 | It says that it needs building. | 15:05 |
| james_w | cool :-) | 15:06 |
| james_w | do you know the process for getting it updated in jaunty? | 15:06 |
| Ape3000 | Not perfectly | 15:07 |
| james_w | k | 15:08 |
| Ape3000 | I think I could send to Debian, since it has also only 0.6.4 | 15:08 |
| james_w | is there already a bug open on the package about there being a new upstream release? | 15:08 |
| james_w | that would be great | 15:08 |
| Ape3000 | I didn't find any bug reports | 15:08 |
| james_w | ok, the first step is to file one | 15:09 |
| Ape3000 | I just wanted to practice building and I knew that the version of typespeed isn't the newest upstream version. | 15:09 |
| james_w | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=499133 is the Debian bug about it | 15:09 |
| james_w | so you can link the reports in launchpad once you have filed the Ubuntu bug | 15:10 |
| Ape3000 | So what is the package where I file the bug? | 15:12 |
| Ape3000 | Is it the typespeed source package or Ubuntu? | 15:12 |
| james_w | the former | 15:12 |
| james_w | https://bugs.launchpad.net/ubuntu/+source/typespeed/+filebug | 15:13 |
| Ape3000 | https://bugs.launchpad.net/ubuntu/+source/typespeed/+bug/320484 | 15:16 |
| Ape3000 | So how do I link the debian bug? | 15:16 |
| james_w | Ape3000: click on "Also affects Distribution", select Debian, and enter the url I gave | 15:22 |
| dholbach | HELLO EVERYBODY! | 15:59 |
| zerwas | Hi :) | 15:59 |
| dholbach | Who's here for the last day of the week of awesome? | 15:59 |
| dholbach | Who's excited? :-) | 15:59 |
| dholbach | COME ON! :) | 15:59 |
| * liw cracks knuckles | 15:59 | |
| zerwas | i hope all 144 here are! | 15:59 |
| dholbach | liw: seems like you have a bit of a shy audience today :-) | 16:00 |
| dholbach | Ok... welcome everybody! | 16:00 |
| dholbach | We have the amazing Lars Wirzenius here today and I promise he won't bite | 16:00 |
| * weboide is ready for it! | 16:00 | |
| dholbach | instead, he'll talk about the fantastic things you can do with piuparts and I hope you enjoy the ride | 16:00 |
| dholbach | questions, as always, go into #ubuntu-classroom-chat please | 16:01 |
| dholbach | and please prefix them with QUESTION: | 16:01 |
| liw | if someone wants to volunteer to paste questions to this channel, that would be fabulous! | 16:01 |
| dholbach | ie: QUESTION: liw: why don't Finns hug? | 16:01 |
| dholbach | enjoy the session, liw: the floor is yours :) | 16:01 |
| liw | dholbach, thank you, thank you | 16:01 |
| dholbach | :-)( | 16:02 |
| liw | so, I'm going to talk about piuparts. Questions are welcome at any time. I've structured this into sections: What is piuparts; basic usage; interpreting the results; speeding it up; testing for newer releasees; gotchas | 16:03 |
| liw | if I'm going too fast, or too slow, don't hesitate to tell me | 16:03 |
| liw | first section: What is piuparts? | 16:03 |
| liw | Piuparts is a tool to test that a .deb package can be installed and removed, and installed, upgraded, and removed. | 16:03 |
| liw | It is primarily meant for people who maintain and upload packages. | 16:04 |
| liw | It works by constructing a chroot with a minimal Debian or Ubuntu installation, and then installing the package being tested into the chroot. It also installs the dependencies. | 16:04 |
| liw | After this is done, it removes and then purges the package, and any other packages that got installed. | 16:04 |
| liw | Finally, it compares the state of the chroot before the package and its dependencies were installed, and after they got purged. | 16:04 |
| liw | It checks that all files are still there, and haven't been changed, and that there are no new files. | 16:04 |
| liw | Obviously, some things will always change, such as log files. Piuparts ignores those. | 16:04 |
| liw | any questions so far? anyone getting this at all? | 16:04 |
| zerwas | <weboide> QUESTION: is this like pbuilder ? | 16:05 |
| liw | zerwas, thanks (I was just fighting my irc client to do that :) | 16:05 |
| liw | weboide, pbuilder uses a chroot to build a package in a clean environment; piuparts uses a chroot to test that a package installs into a clean environment, so there are similarities, but they are solving different problems with chroots | 16:06 |
| liw | I will get back to pbuilder in a bit | 16:07 |
| liw | any other questions? if not, I'll continue on to the next section | 16:07 |
| liw | second section: Basic usage | 16:07 |
| liw | The very basic way of using piuparts is as follows: | 16:07 |
| liw | piuparts foo.deb | 16:08 |
| liw | where foo.deb is a .deb package you have built. | 16:08 |
| liw | Note that this can take a long time, and can produce quite a lot of output. | 16:08 |
| liw | You probably don't want to run the command just now. | 16:08 |
| liw | Because piuparts builds a chroot, it must run as root. | 16:08 |
| liw | Prefix the command with sudo. (But not yet) | 16:08 |
| liw | To avoid people accidentally copypasting commands when they shouldn't, I'm not prefixing it in examples. | 16:08 |
| liw | The above command will run the install/remove/purge test. | 16:09 |
| liw | If the package is already in the archive, it will also test that the package can be upgraded from the archive to the .deb you give. | 16:09 |
| liw | The other way of running piuparts is as follows: | 16:09 |
| liw | piuparts -a foo | 16:09 |
| liw | Here foo is the name of a package, not of a .deb. | 16:09 |
| liw | Piuparts will fetch the package from the archive and test it. | 16:09 |
| liw | This will, obviously, not test upgrades since there is no newer package. | 16:09 |
| liw | If you feel like being evil, you can spend your time worse than running piuparts on all sorts of random packages and filing bugs for serious problems. | 16:09 |
| liw | any questions so far? | 16:10 |
| liw | continuin... | 16:10 |
| liw | You can also test upgrading from release to release: | 16:10 |
| liw | piuparts -a -d dapper -d hardy -d intrepid -d jaunty foo | 16:10 |
| liw | This will take even longer. | 16:10 |
| liw | it will first construct a chroot with dapper, install the package into that, then upgrade the whole chroot to hardy, then to intrepid, then to jaunty, and then remove and purge the package and its dependencies | 16:11 |
| zerwas | <ia> QUESTION: can piuparts use pbuilder's tgz chroot images (so to don't create for each tool each set of chroots)? | 16:11 |
| liw | ia, yes; I'll show an example in a while | 16:11 |
| zerwas | <weboide> QUESTION: what version of piuparts should be we use? repos version? dev version? | 16:12 |
| liw | weboide, you should use the version in current development version of Ubuntu, by preference, unless that breaks | 16:12 |
| liw | piuparts development has not been very fast in the past couple of years, so there are not a lot of versions to choose from that are easily available | 16:13 |
| liw | third section: Interpreting the results | 16:14 |
| liw | Piuparts outputs quite a lot of text when it runs. | 16:14 |
| liw | This is because when I was developing it, it was quite useful to me to see what was going on and figure out when things broke. | 16:14 |
| liw | I never got around to fixing things so that it was nice to use for other people. | 16:14 |
| liw | (sorry) | 16:14 |
| liw | Since the output can be pretty large, up to several hundred kilobytes, it is best to capture it in a file: | 16:14 |
| liw | piuparts -l foo.log foo.deb | 16:14 |
| liw | The output will go to the named file, and also to the screen. | 16:14 |
| liw | Every line of output piuparts outputs is prefixed with a relative timestamp (minutes and seconds since piuparts started), and a log level: DUMP, DEBUG, INFO, WARNING, ERROR, FATAL. | 16:14 |
| liw | DUMP and DEBUG you can mostly ignore; unfortunately there is no switch to let you do that at the moment. | 16:15 |
| liw | (sorry) | 16:15 |
| liw | The useful stuff is in INFO, and in ERROR if it is there. | 16:15 |
| liw | Therefore, the way to read a piuparts log file is to grep for INFO and ERROR. | 16:15 |
| liw | Then, if those don't make any sense, read DUMP and DEBUG as well. | 16:15 |
| liw | When piuparts finishes, it outputs one of two things: either a PASS or a FAIL message. | 16:15 |
| liw | They look like these: | 16:15 |
| liw | 2m11.0s INFO: PASS: All tests. | 16:15 |
| liw | 5m33.8s ERROR: Broken symlinks: | 16:15 |
| liw | Obviously these were from different runs. You only get one of them per run. | 16:15 |
| liw | I should pastebin some actual log output, just a minute. | 16:16 |
| liw | http://paste.ubuntu.com/108624/ and http://paste.ubuntu.com/108625/ are two snippets of an actual log file | 16:17 |
| liw | just to give you a taste of what they look like. the beginning and the end. | 16:18 |
| zerwas | <Ape3000> QUESTION: How much time does the basic test usually take? | 16:18 |
| liw | Ape3000, the second pastebin answers that for the hello package: almost 7 minutes (but that was running inside kvm) | 16:19 |
| liw | any questions about interpreting those log files? they're long, but hopefully not too obscure | 16:19 |
| liw | next section (is this 12765 already?): Speeding it up | 16:20 |
| liw | (everyone's favorite topic) | 16:20 |
| liw | It can take a long time to construct the chroot. | 16:20 |
| liw | Since most package maintainers use pbuilder, and it constructs a chroot too, piuparts provides the --pbuilder (-p) option to use the pbuiler tarball to create the chroot. | 16:21 |
| liw | This makes things much faster. | 16:21 |
| zerwas | <Laney> QUESTION: Does the chroot have to be created every time? | 16:21 |
| liw | On the server I used to use to run piuparts on all packages in Debian, a couple of years ago, piuparts took only a few seconds per typical small package, when using a pre-built chroot tarball. | 16:21 |
| liw | Laney, so yeah, some kind of chroot gets created every time. When it is created by unpacking a tarball, it is pretty fast, just a couple of seconds | 16:21 |
| liw | except on a netbook, perhaps | 16:22 |
| === smarter_ is now known as smarter | ||
| liw | In addition to -p, piuparts can create its own tarballs. Or you can construct one by hand. But let's stick to pbuilder ones, they're easiest for most people. | 16:22 |
| zerwas | QUESTION: (by Laney) piuparts understands debian and ubuntu releases, right? | 16:23 |
| liw | Laney, yes; piuparts just uses apt-get to do stuff, so it is fine with anything that apt understands | 16:23 |
| liw | next+1 section: Testing packages for newer releases | 16:23 |
| liw | Piuparts can test packages for newer releases of Ubuntu, on older release of Ubuntu, if you use the debootstrap package from backports. | 16:24 |
| liw | This way, if your machine runs intrepid, but you want to test that your package works in jaunty, you can. | 16:24 |
| liw | okay, I have one final section to go through (Gotchas), and after that you're all ready to actually start running things without ruining things :) | 16:24 |
| liw | last section: Gotchas | 16:25 |
| liw | Piuparts works on a chroot. | 16:25 |
| liw | This means that it does not properly protect the host system. | 16:25 |
| liw | A malicious package, or a really unfortunately buggy package, may ruin the host system. | 16:25 |
| liw | In the three years since I wrote piuparts, I have had that happen, but it's possible. | 16:25 |
| liw | The solution, of course, is to fix piuparts to use KVM. (Volunteers welcome.) Or to run piuparts in a virtual machine (that's what I do now). | 16:25 |
| liw | Piuparts can use a lot of CPU, RAM, disk I/O, and network bandwidth. | 16:26 |
| liw | Be prepared for that. It's nowhere near as fast to use as, say, lintian. | 16:26 |
| liw | Some of the checks piuparts does often fail, but they don't matter much in real life. | 16:26 |
| liw | The manual page has lists all options, so you can look there if something annoys you. | 16:26 |
| liw | For example, piuparts checks that all symlinks point somewhere that actually exist. | 16:26 |
| liw | For some reason, this is triggered fairly often, so you can disable it with the --no-symlinks (-N) option. | 16:26 |
| liw | piuparts in Ubuntu defaults to gutsy, since it hasn't been updated since the hardy release to a better default. You can blame me for that. | 16:26 |
| liw | Actually, don't blame me, file a bug in Launchpad, and subscribe me to it (liw on Launchpad). | 16:27 |
| liw | (Yes, everyone reading this can do that. I can take it.) | 16:27 |
| liw | You can work around this by specifying the distribution manually with the -d option: | 16:27 |
| liw | piuparts -d jaunty foo | 16:27 |
| liw | OK. Go run piuparts now. I want questions. | 16:27 |
| liw | <Laney> So what's the command to test upgradability from the current stable release? I guess -d intrepid -d jaunty foo.deb? | 16:29 |
| liw | yep, unless I forget something | 16:30 |
| Laney | \o/ | 16:30 |
| liw | it's possible piuparts can only test upgrades between releases for packages already in the archive, in which case you need to specify "-a foo" instead of "foo.deb" | 16:30 |
| zerwas | <weboide> I just had this error: E: Couldn't find package debfoster | 16:30 |
| liw | weboide, hmm, let me check | 16:31 |
| liw | ah, I think we're hitting the difference between "main" in Debian and Ubuntu here | 16:31 |
| liw | let me check something | 16:32 |
| liw | the problem is that debfoster is in main in Debian (almost everything is), but in universe in Ubuntu, and piuparts was written before I really knew about Ubuntu, so it assumes it's enough to just use main | 16:34 |
| liw | so the solution is to tell piuparts to use universe as well as main | 16:35 |
| liw | except for some reason, for me the debfoster thing works, so I have a hard time testing, hmm | 16:36 |
| liw | oh, I forgot -p | 16:37 |
| liw | no wonder it was slow :) | 16:37 |
| liw | debugging under public scrutiny does wonders for my humility muscles | 16:37 |
| liw | weboide, anyway, the solution should be to specify the mirror for piuparts: -m 'http://your.mirrorhere/ubuntu main universe' | 16:40 |
| liw | weboide, could you test that? | 16:40 |
| weboide | liw: sure | 16:40 |
| weboide | liw: It just passed the debfoster installation. so it helped :) | 16:43 |
| liw | weboide, yay | 16:43 |
| liw | any further questions? is everyone busy waiting for their machines to stop churning? | 16:47 |
| jbernard | yep ;) | 16:48 |
| === bac is now known as bac_lunch | ||
| mneptok | liw: i thought "Thou shalt not paste Unix commands from Finns on IRC into thy shell," was one of the new commandments. | 16:57 |
| liw | I think we're just about out of time. Thank you, everyone. If you have further questions about piuparts, I'm often available on #ubuntu-devel and other IRC channels. | 16:58 |
| dinxter | cheers liw! | 16:59 |
| Ape3000 | I just got it working :D | 17:00 |
| liw | Ape3000, yeay | 17:00 |
| zerwas | THANKS for all this liw! | 17:01 |
| mvo | hello | 17:03 |
| mvo | I think I'm next :) | 17:04 |
| mvo | the next topic is "fun with python-apt" | 17:05 |
| mvo | is there anyone interessted in montioring #ubuntu-classroom-chat for questions while I talk and paste them there ? | 17:05 |
| dinxter | yep... oops :) | 17:06 |
| mvo | aha, cool. I will just start then - you can ask questions anytime :) | 17:06 |
| mvo | python-apt exposes most of the functionatliy that apt-get/libapt | 17:06 |
| mvo | provide via python. | 17:06 |
| mvo | so everything that apt-get/synaptic and friends can do can be done via python-apt | 17:06 |
| mvo | lets start with a example to see how scary it really is :) | 17:07 |
| mvo | Here is a simple example: | 17:07 |
| mvo | #!/usr/bin/python | 17:07 |
| mvo | import apt | 17:07 |
| mvo | cache = apt.Cache() | 17:07 |
| mvo | pkg = cache["apt"] | 17:07 |
| mvo | print "name: ", pkg.name | 17:07 |
| mvo | print "installed version: ", pkg.installedVersion | 17:07 |
| mvo | (feel free to copy/paste that into a text file and run to see what it outputs) | 17:07 |
| mvo | This example illustrates the central piece of the libapt system. The | 17:08 |
| mvo | package cache (availalbe as apt.Cache()). It is a fast representation | 17:08 |
| mvo | of the data available in /var/lib/apt/lists and is created as a | 17:08 |
| mvo | mmap-able binary file in /var/cache/apt/pkgcache.bin. It contains | 17:08 |
| mvo | information about all the available binary packages and | 17:08 |
| mvo | dependencies. In the python version it behaves like a dict. | 17:08 |
| mvo | The other piece is the package object. It contains general information | 17:08 |
| mvo | like name and description, version information and information about | 17:08 |
| mvo | the status (installed, downloadable, ..). It can also be used to | 17:08 |
| mvo | manipulate the state of the package. | 17:08 |
| mvo | Documentation is available via: "pydoc apt", "pydoc apt.Cache", "pydoc | 17:09 |
| mvo | apt.Package", etc. There is also a (very new and good) website | 17:09 |
| mvo | available here: | 17:09 |
| mvo | http://apt.alioth.debian.org/python-apt-doc/ | 17:09 |
| mvo | any questions so far? | 17:10 |
| mvo | package can be in a lot of different states | 17:11 |
| mvo | Here is a example to inspect package states: | 17:11 |
| mvo | #!/usr/bin/python | 17:11 |
| mvo | import apt | 17:11 |
| mvo | cache = apt.Cache() | 17:11 |
| mvo | print "available packages: ", len(cache) | 17:11 |
| mvo | for pkg in cache: | 17:11 |
| mvo | if pkg.isInstalled: | 17:11 |
| mvo | print "installed: ", pkg.name | 17:11 |
| mvo | print "num installed: ", len([pkg for pkg in cache if pkg.isInstalled]) | 17:11 |
| mvo | If I'm going too fast (or too slow) please shout :) | 17:12 |
| mvo | This shows that the cache can be manipulated in a similar way like a | 17:12 |
| mvo | regular dict, it should feel "python-ish" :) | 17:12 |
| mvo | this example again shows that the cache is the central structure, it contains all the package object that can be used to get information about the system | 17:14 |
| mvo | QUESTION: what is the difference between Package.installedSize and Package.installedPackageSize? | 17:15 |
| mvo | the package size is the size of the download (the compressed package itself) | 17:15 |
| mvo | the installedSize is the actual size on disk | 17:16 |
| mvo | of the unpacked thing | 17:16 |
| mvo | it may be not 100% accurate because the package may create files in its postinst or other scripts | 17:16 |
| mvo | but generally its good enough | 17:16 |
| mvo | Lets do anohter example: | 17:17 |
| mvo | #!/usr/bin/python | 17:17 |
| mvo | import apt | 17:17 |
| mvo | progress = apt.progress.OpTextProgress() | 17:17 |
| mvo | cache = apt.Cache(progress) | 17:17 |
| mvo | print "summary: ", cache["apt"].summary | 17:17 |
| mvo | This shows another important concept. Progress objects. Everytime apt | 17:17 |
| mvo | does something that takes a long time (like building the caches, | 17:17 |
| mvo | fetching stuff from the network or installing packages) it can use | 17:17 |
| mvo | progress objects to give user feedback. There are some text based | 17:17 |
| mvo | progress objects available that can be readily used. | 17:17 |
| mvo | those progress object are regular python classes so they can be used as the basis to make fanncier progress information available | 17:19 |
| mvo | gtk or qt progress would be a example | 17:19 |
| mvo | currently there is text based progress available in the lib, but the jaunty version already has some gtk based progress widgets available as well | 17:19 |
| mvo | that should make intergration even easier | 17:19 |
| mvo | Here is a example how to create your own progress objects: | 17:20 |
| mvo | #!/usr/bin/python | 17:20 |
| mvo | import apt | 17:20 |
| mvo | class MyOpProgress(apt.progress.OpProgress): | 17:20 |
| mvo | " example class that demonstrates how a progress can be subclassed " | 17:20 |
| mvo | def update(self, percent): | 17:20 |
| mvo | print "update: ", percent | 17:20 |
| mvo | def done(self): | 17:20 |
| mvo | print "done!" | 17:20 |
| mvo | progress = MyOpProgress() | 17:20 |
| mvo | cache = apt.Cache(progress) | 17:20 |
| mvo | print "summary: ", cache["apt"].summary | 17:20 |
| mvo | This creates a new class based on the normal progress class that | 17:20 |
| mvo | overwrites the the functions called by apt. | 17:20 |
| mvo | information about the methods in the progress code is avialable via "pydoc apt.progress" | 17:21 |
| mvo | there is also a lot of example code in update-manager or gdebi (big users of pyhton-apt :) | 17:21 |
| mvo | all good so far? examples working :) ? | 17:22 |
| mvo | The python-apt system is not limited to querrying but it can also | 17:24 |
| mvo | perform actions. Here is a example (that needs to run as root) of a | 17:24 |
| mvo | apt-get update like call: | 17:24 |
| mvo | #!/usr/bin/python | 17:24 |
| mvo | import apt | 17:24 |
| mvo | fetchprogress = apt.progress.TextFetchProgress() | 17:24 |
| mvo | cache = apt.Cache() | 17:24 |
| mvo | cache.update(fetchprogress) | 17:24 |
| mvo | cache.open(apt.cache.OpProgress()) | 17:24 |
| mvo | Its important to re-open the cache after it was updated (this will | 17:24 |
| mvo | eventually become part of update() api I think so that it happens | 17:24 |
| mvo | automatically). | 17:24 |
| mvo | while the api is pretty solid there are some small warts still (like this open() is required after update()) | 17:25 |
| mvo | we are working on it :) | 17:25 |
| mvo | fetchprogress can again be your own class, it just has some more methods that can be overwriten | 17:26 |
| mvo | We can of course install stuff too: | 17:26 |
| mvo | #!/usr/bin/python | 17:26 |
| mvo | import apt | 17:26 |
| mvo | fetchprogress = apt.progress.TextFetchProgress() | 17:26 |
| mvo | installprogress = apt.progress.InstallProgress() | 17:26 |
| mvo | cache = apt.Cache() | 17:26 |
| mvo | cache["2vcard"].markInstall() | 17:27 |
| mvo | cache.commit(fetchprogress, installprogress) | 17:27 |
| mvo | cache.open(apt.cache.OpProgress()) | 17:27 |
| mvo | the open() is important again so that apt knows about the chanages. you could omit it and save time is the cache is not needed afterwards | 17:28 |
| mvo | e.g. because your applicaiton exists after it installed something | 17:28 |
| mvo | (the last line should be cache.open(apt.progress.OpProgress()) - thanks to maxb) | 17:29 |
| mvo | any change done in the cache is just "simulated" until commit() is called | 17:30 |
| mvo | by default python-apt will ensure that everything is consistent, i.e. if you install a package in the cache that requires dependencies, it will automatically mark them for install in the cache as well | 17:31 |
| mvo | This lets us do multiple install/removes too, it will commit | 17:31 |
| mvo | whatever is currently set in the cache. So its a good idea to inspect | 17:31 |
| mvo | the cache before we commit changes. This is done like this: | 17:31 |
| mvo | #!/usr/bin/python | 17:31 |
| mvo | import apt | 17:31 |
| mvo | cache = apt.Cache() | 17:31 |
| mvo | cache["4g8"].markInstall() | 17:31 |
| mvo | for pkg in cache.getChanges(): | 17:31 |
| mvo | if pkg.markedInstall: | 17:31 |
| mvo | print "installing: ", pkg.name | 17:31 |
| mvo | elif pkg.markedUpgrade: | 17:31 |
| mvo | print "upgrade: ", pkg.name | 17:32 |
| mvo | elif pkg.markedDelete: | 17:32 |
| mvo | print "removing: ", pkg.name | 17:32 |
| mvo | See the "pydoc apt.package" documentation for all the available | 17:32 |
| mvo | states. | 17:32 |
| mvo | python-apt gives you full control over the consistency if you want, you can e.g. prevent it from automatically fixing problem and do that yourself, but its recommended to let it run in autoFix mode :) | 17:33 |
| mvo | states like automatic dependencies (for apt-get autoremove) will also be done correctly and a commit() will do the right thing and write them out | 17:34 |
| mvo | Each package has two versions. The installed version (if any) and the | 17:35 |
| mvo | candidate version. Those can be querried via: | 17:35 |
| mvo | #!/usr/bin/python | 17:35 |
| mvo | import apt | 17:35 |
| mvo | cache = apt.Cache() | 17:35 |
| mvo | for pkg in cache: | 17:35 |
| mvo | if pkg.isUpgradable: | 17:35 |
| mvo | print "pkg '%s': now '%s' candidate: '%s'" % (pkg.name, pkg.installedVersion, pkg.candidateVersion) | 17:35 |
| mvo | Each package can of course have multiple versions, but apt will show you two by default | 17:35 |
| mvo | the candidate is the one that you can install | 17:35 |
| mvo | and the installed is self explaining :) | 17:35 |
| mvo | the candidate version can be manipulated with the apt policy and by setting it directly, but that again is not recommended, usually its doing the right thing when it calculates the candidate | 17:36 |
| mvo | usually the candidate is just the higest available downloadable version | 17:36 |
| mvo | One nice feature of python-apt is that you can give it a alternative | 17:37 |
| mvo | rootdir to look for status file and sources.list. If you want to know | 17:37 |
| mvo | what warty loooked like (back in the days) you could do: | 17:37 |
| mvo | #!/usr/bin/python | 17:37 |
| mvo | import apt | 17:37 |
| mvo | import os | 17:37 |
| mvo | import os.path | 17:37 |
| mvo | alt_root = "/tmp/warty" | 17:37 |
| mvo | for d in ["/etc/apt/", | 17:37 |
| mvo | "/var/lib/apt/lists/partial", | 17:37 |
| mvo | "/var/lib/dpkg", | 17:37 |
| mvo | "/var/cache/apt/archives/partial"]: | 17:37 |
| mvo | os.makedirs(alt_root+d) | 17:37 |
| mvo | open(alt_root+"/var/lib/dpkg/status","w") | 17:38 |
| mvo | open(alt_root+"/etc/apt/sources.list","w").write("deb http://old-releases.ubuntu.com/ubuntu warty main") | 17:38 |
| mvo | c=apt.Cache(rootdir=alt_root) | 17:38 |
| mvo | c.update(apt.progress.TextFetchProgress()) | 17:38 |
| mvo | c.open(apt.progress.OpProgress()) | 17:38 |
| mvo | print "warty apt version: ", c["apt"].candidateVersion | 17:38 |
| mvo | in this example first a bit of directory structure is created (that should probably go into the lib itself) and then the alternative rootdir is created | 17:38 |
| mvo | the cache then reads the information from there instead of the main system | 17:38 |
| mvo | this is handy in some situations, e.g. to debug stuff or to calculate differences in the packages between multiple version or for history interesst or or .) | 17:39 |
| mvo | you could do e.g. a daily "whats new available in jaunty" thing with it while still runing hardy etc | 17:41 |
| mvo | you may have noticed that the apt.package.Package object does not expose everything there is in a package record | 17:41 |
| mvo | (the package record is the stuff that is output via apt-cache show package) | 17:42 |
| mvo | e.g. apt-cache show apt has a task field | 17:42 |
| mvo | that is not exposed there | 17:42 |
| mvo | or the bugs field | 17:42 |
| mvo | the reason is that in the mmap struture only the most important information is represented | 17:42 |
| mvo | for performance reasons | 17:42 |
| mvo | but the information is still available, its just a little bit slower when checked :) | 17:43 |
| mvo | (and a lot slower if you querry every package with the full record instead of the mmap-ed struture) | 17:43 |
| mvo | The package object does not expose all fields of a package, just the | 17:43 |
| mvo | most important ones. To access the others, there is the package | 17:43 |
| mvo | "Record". It contains the full content of the Packages entry for the | 17:43 |
| mvo | particular package. It can be accessed as a dict or as a string. Here | 17:43 |
| mvo | is a example: | 17:43 |
| mvo | #!/usr/bin/python | 17:43 |
| mvo | import apt | 17:43 |
| mvo | cache = apt.Cache() | 17:43 |
| mvo | pkg = cache["synaptic"] | 17:44 |
| mvo | print "Bugs entry: ", pkg.candidateRecord["Bugs"] | 17:44 |
| mvo | print "Full record: ", str(pkg.candidateRecord) | 17:44 |
| mvo | This covers the most important aspects of the python-apt high level | 17:45 |
| mvo | interface. | 17:45 |
| mvo | more examples (of mixed quality :P are availalbe in the python-apt examples folder: | 17:45 |
| mvo | /usr/share/doc/python-apt/examples/ | 17:45 |
| mvo | There is also the aptsources interface to manipulate the sources.list | 17:45 |
| mvo | and the low level apt_pkg and apt_inst interfaces that provide a | 17:45 |
| mvo | direct mapping of the underlaying C++ interface of libapt to python | 17:45 |
| mvo | (and its not very python-ish :). apt_pkg/apt_inst is used to implement | 17:45 |
| mvo | the higher level apt interface. | 17:45 |
| mvo | apt_pkg is nowdays no longer needed for most tasks, the apt interface covers most of it | 17:46 |
| mvo | apt_pkg does not follow PEP08 (the python code style guidelines) and is generally a bit "rough" | 17:46 |
| mvo | so only use it if you really need it :) | 17:46 |
| mvo | otherwise use "import apt" | 17:46 |
| mvo | Developement power is always welcome! Projects that use python-apt are | 17:47 |
| mvo | update-manager, gnome-app-install, gdebi, software-properties and | 17:47 |
| mvo | more. If you are interessted in hacking on python-apt (or any of the | 17:47 |
| mvo | tools that use it) you are very welcome to do so. The code is | 17:47 |
| mvo | maintained in bzr. | 17:47 |
| mvo | that was my overview about python-apt - any questions? | 17:47 |
| mvo | or suggestions? | 17:47 |
| mvo | if there are none, thank you very much for your attention and I hope you have enjoyed it :) | 17:50 |
| jbernard | thanks alot, very helpful | 17:52 |
| mvo | let me answer the packagekit question first | 17:52 |
| mvo | packagekit is currently in universe, we plan to move it to main for jaunty, but we can not use it for everything | 17:53 |
| mvo | the problem is basicly that packagekit does not allow anything like debconf during installation | 17:53 |
| mvo | that is fine most of the time | 17:53 |
| mvo | but there are packages that require some form of interaction, otherwise they fail to install | 17:53 |
| mvo | thing of virtualbox (at least that used to need it) | 17:54 |
| mvo | or java | 17:54 |
| mvo | or stuff like this | 17:54 |
| mvo | so we will use it for some stuff were we know its save to use | 17:54 |
| mvo | but not for e.g. update-manager where it maybe any package (including those that require debconf) | 17:54 |
| mvo | but packagekit is really something on top of python-apt, its a layer higher | 17:55 |
| mvo | (in fact, the packagekit backend for apt is implemented using python-apt :) | 17:55 |
| mvo | QUESTION: i take it getting the apt.Cache() locks the cache file? if so how do i release it for other apps | 17:55 |
| mvo | threre are the "apt_pkg.PkgSystemLock() and apt_pkg.PkgSystemUnLock()" calls for this | 17:56 |
| mvo | if python-apt is used as non-root then no locking is needed, that is the safest option :) | 17:56 |
| mvo | gdebi for example only switches to root for the actual installing, everything else is done as the user | 17:57 |
| mvo | a last note. a pretty nice overview over the apt system is here: http://algebraicthunk.net/~dburrows/blog/entry/images/apt-diagram-simple.png | 18:01 |
| iulian | Next up is rockstar and beuno with "Bazaar and Launchpad - How to do it". | 18:05 |
| iulian | Rock on guys! | 18:05 |
| rockstar | Hi everyone. My name is Paul Hummer, and I work on the Launchpad Code team. Also with me is my cow orker, Martin Albisetti, who is awesome in his own rite. | 18:05 |
| rockstar | Today we're going to be talking about some good principles and practices for using bzr with Launchpad. Most of these things are only suggestions, but I would say that they are very STRONG suggestions. | 18:06 |
| rockstar | First, some pre-requisites... | 18:06 |
| * beuno waves | 18:06 | |
| rockstar | If you're not using bzr from the bzr ppa, you REALLY should be. | 18:07 |
| rockstar | It can be found here: https://edge.launchpad.net/~bzr/+archive/ppa | 18:07 |
| rockstar | This will make sure you're getting the best out of Bazaar, and in effect, the best out of Launchpad. | 18:07 |
| rockstar | I'm not sure if emmajane covered this in her session, but I can't stress enough the importance of setting your name in bzr. | 18:08 |
| rockstar | You can do this at the terminal by typing `bzr whoami` first. | 18:08 |
| rockstar | If I were to type that on this system without configuring it, it would return <rockstar@megatron>, as my system user is rockstar, and my system name is megatron. | 18:09 |
| rockstar | If it returns a <user@host> to you, you need to configure it. | 18:10 |
| rockstar | So you'll need to type `bzr whoami "Paul Hummer <paul@example.com"` obvious substitutions. | 18:11 |
| rockstar | ...apply | 18:11 |
| rockstar | Now bzr will know who attribute your revisions to. | 18:11 |
| holloway | sorry for the interrupt, you mean `bzr whoami "Paul Hummer <paul@example.com">` ? | 18:12 |
| rockstar | `bzr whoami "Paul Hummer <paul@example.com>"` | 18:12 |
| rockstar | Thanks for the clarification beuno | 18:12 |
| beuno | holloway, please head over to #ubuntu-classroom-chat for questions | 18:12 |
| beuno | apw, asked: QUESTION: is bzr whoami global or per checkout? | 18:13 |
| rockstar | Er, holloway, thanks. | 18:13 |
| holloway | yeah sorry | 18:13 |
| beuno | answer: global, although you can specify it per branch additionally | 18:13 |
| rockstar | apw, yes, what beuno said. ~/.bazaar/locations.conf is where you'd set it per banch. | 18:14 |
| rockstar | s/banch/branch | 18:14 |
| rockstar | It's important that the email address you set here is one that Launchpad knows about (and it's confirmed). | 18:14 |
| rockstar | Launchpad will then look at those revisions, and say "I know this email address! It belongs to X user!" | 18:15 |
| rockstar | Then, when you look at a branch's revisions, the ones that belong to you will be linked to your account. | 18:15 |
| rockstar | And, for those who are karma happy, you'll get karma for the revisions that belong to you. | 18:16 |
| rockstar | So, let's get on to the Launchpad part. | 18:16 |
| rockstar | You've got your project all set up, with it's accompanying branding bling, and now you're ready to make it host some code. | 18:16 |
| rockstar | For the next few examples, I'm going to use my username and a project I work on called Entertainer. | 18:17 |
| rockstar | So I have a branch that I'd like to be considered THE entertainer branch. It's the one that releases will be cut from. | 18:17 |
| rockstar | Inside that branch I'll type `bzr push lp:~rockstar/entertainer/trunk` | 18:17 |
| rockstar | This will push up a branch of entertainer called trunk | 18:17 |
| rockstar | Now I need to make launchpad reflect that this is the Entertainer "trunk" | 18:18 |
| rockstar | I do that by setting it as the "Development Focus" | 18:18 |
| rockstar | This has a few side effects. | 18:18 |
| rockstar | The first is that I can now branch that same branch by typing `bzr branch lp:entertainer` | 18:19 |
| rockstar | Launchpad knows the development focus branch is lp:~rockstar/entertainer/trunk and so that's the branch I end up with. | 18:19 |
| beuno | < apw> QUESTION: how did you tell it that it was the Development Focus, was that a ticky somewhere in LP ? | 18:20 |
| rockstar | Also, when new users come to hack on my project (because that's Launchpad's best thing about it), they'll know where to focus their efforts. | 18:20 |
| rockstar | apw, if you go to https://edge.launchpad.net/entertainer you'll see a link that says trunk (focus of development) | 18:21 |
| rockstar | Click on that, and you'll see a link to the "trunk" branch. | 18:22 |
| rockstar | On the right hand side, you'll see a Link to branch link. | 18:23 |
| rockstar | That's how you would set it. | 18:23 |
| rockstar | I need to add a caveat here. It's best to have you trunk branch owned by a team (this will require creating a team). | 18:24 |
| rockstar | This way, you don't block development landings when you go on vacation for two months. Other members can merge branches into trunk while you're gone. | 18:24 |
| rockstar | Alright, moving on... | 18:26 |
| rockstar | Now we have the "trunk" set up. | 18:26 |
| rockstar | I'm going to context switch to act as a user named cthulu on Launchpad. | 18:27 |
| rockstar | I come to the entertainer project and I want to hack on it. | 18:27 |
| rockstar | The first thing I want to do is to get a local mirror of trunk. | 18:27 |
| crashsystems | I'm late | 18:28 |
| rockstar | The benefit of a local mirror of trunk is that it doesn't require internet connections to create a new branch. | 18:28 |
| rockstar | So I `bzr branch lp:entertainer` and now have a local branch called entertainer. | 18:29 |
| rockstar | So I branch from that one to fix bug 1234567 by doing `bzr branch entertainer bug-1234567` | 18:29 |
| rockstar | I can then go into the bug-1234567 branch, and push it to Launchpad by doing `bzr push lp:~cthulu/entertainer/bug-1234567` | 18:30 |
| beuno | 16:25 < DoruHush> QUESTION: How a sub-branch of a main branch of a project get registred. What steps a user should to register a sub-branch (his working bzr | 18:30 |
| beuno | branch in Launchpad, not localy ) ? | 18:30 |
| beuno | 16:26 < DoruHush> like another branch in a team project | 18:30 |
| rockstar | I blogged about some configuration settings that I use to make pushing simpler here : http://theironlion.net/blog/2009/01/13/using-bazaar-launchpad-making-pushing-easy/ | 18:31 |
| rockstar | DoruHush, I think what you're asking is what I just went over. Do you have other questions? | 18:31 |
| === bac_lunch is now known as bac | ||
| rockstar | The branch for bug-1234567 is now registered with Launchpad as a hosted branch (notice I didn't have to use the Web UI at all. Launchpad is so s-m-a-r-t) | 18:32 |
| beuno | < postalchris> Is the bug-XXXX branch name magically recognized by Launchpad, or are you using that as a personal convention? | 18:32 |
| rockstar | Personal convention really. | 18:32 |
| rockstar | However, this would be a good time to note a cool way to link your branch to a bug. | 18:33 |
| rockstar | So I (as cthulu) hack and commit a few times, and finally get the code that fixes bug 1234567. | 18:33 |
| rockstar | So when I commit, I'll type `bzr commit --fixes=lp:1234567` | 18:34 |
| rockstar | When that revision gets pushed, it'll automatically link the branch to the bug. | 18:34 |
| beuno | newz2000> QUESTION: is there a convention you use when working on new features not driven by bugs? | 18:35 |
| rockstar | newz2000, not really. | 18:35 |
| rockstar | newz2000, for instance, I just created a branch called "do-some-important-things-with-unicode" | 18:35 |
| rockstar | Branch names are only limited by your own creativity. | 18:36 |
| rockstar | I suggest leaving out cursewords unless the branch absolutely warrants it. :) | 18:36 |
| rockstar | james_w also notes "for the packagers amongst you if you use changelog bug closing and debcommit then (from intrepid onwards) the links will happen magically" | 18:37 |
| rockstar | Alright, moving on. | 18:37 |
| rockstar | So now cthulu has his branch all completed, with tests (because he wrote his tests first, right?), and he wants to see his work land in mainline. | 18:38 |
| rockstar | Mainline being "trunk" | 18:38 |
| rockstar | cthulu, however, doesn't have write privileges to trunk, and, frankly, teh Entertainer dev process is a little less "Wild west" with their commits. | 18:39 |
| rockstar | We require code reviews and all that. | 18:39 |
| rockstar | Looking at his branch page on Launchpad, cthulu then clicks "Propose for merging into another branch" | 18:40 |
| rockstar | He then follows the form through, setting it to land on trunk, and, since the Default Reviewer is set to Entertainer-Releases, he doesn't have to mess with that. | 18:41 |
| rockstar | Although, when I have a Launchpad branch that introduces new ui, I usually will request beuno to look at. He's awesomer than me at that stuff. | 18:41 |
| rockstar | So now there's a new merge proposal showing cthulu's bug-1234567 branch as the "source branch" and lp:entertainer as the "target branch" | 18:42 |
| beuno | < apw> QUESTION: if i commited something --fixes=lp:123456 how can i see that in bzr on my branch? | 18:43 |
| rockstar | apw, on Launchpad, when you view either that branch or that bug, you'll see a link to the other. | 18:43 |
| apw | nothing on my local branch copy? | 18:44 |
| rockstar | apw, not sure actually. I've never had to do that. beuno? | 18:44 |
| beuno | apw, I don't think we expose that through the command line | 18:44 |
| beuno | it's hidden meta-data that you can get out through the API | 18:45 |
| rockstar | apw, I think I could probably whip together a plugin for that data later. | 18:45 |
| rockstar | Alright, moving on to the review process. | 18:46 |
| rockstar | I (as myself again) get an email that there's a branch proposed for merging. | 18:46 |
| rockstar | First I get really excited to see a new contributor. | 18:47 |
| rockstar | Then I'll look at the branch, and usually look at a patch by doing `bzr merge lp:~cthulu/entertainer/bug-1234567` in my trunk mirror, and then `bzr diff` to look at the diff. | 18:48 |
| rockstar | Soon, Launchpad will generate that diff for you. | 18:48 |
| rockstar | I'll make comments and suggestions, and then I'll give it a vote. For this example I'll vote "Needs Fixing" | 18:49 |
| rockstar | cthulu will then respond with justifications on why he did things the way he did, and fix the code to follow the Entertainer coding conventions. | 18:50 |
| rockstar | After I look at it again, I see the changes made, and I change my review vote to "Approve" | 18:50 |
| rockstar | At this point, the branch is ready to be merged. | 18:51 |
| rockstar | However, my band had an emergency tour to go on with my favorite band ever, so I disappear off the face of the planet for 6 months. | 18:51 |
| rockstar | Not to worry though, because there are other members of entertainer-releases that can merge (or "land") cthulu's changes into trunk. | 18:52 |
| rockstar | They do this by merging his branch into their local mirror copy, committing it (with a detailed commit message), and then pushing it up. | 18:54 |
| rockstar | Any questions? | 18:54 |
| rockstar | I should also mention that if you're prototyping something, and it doesn't have a project in LP, you can push what we call a "junk branch". | 18:55 |
| rockstar | We don't call it "junk" as a judgment of your coding skills, but because it's either going to become a project, or just scratch your itch. | 18:56 |
| beuno | < ia> QUESTION: how to create project at launchpad, so anyone else could download source via "bzr branch lp:<project>", not via "bzr branch | 18:56 |
| beuno | lp:~<id>/+junk/<project>"? | 18:56 |
| rockstar | You can push a junk branch by doing "bzr push lp:~rockstar/+junk/total-hack" | 18:56 |
| rockstar | ia, creating a project is a pretty easy process. https://edge.launchpad.net/projects/+new | 18:57 |
| rockstar | Then just pick up where I started in this session. | 18:58 |
| rockstar | Any other questions? | 18:58 |
| rockstar | Also, if a project you like is using CVS or Subversion, but won't give you access to their repo, you can set up an import branch. | 18:59 |
| rockstar | Import branches sync a CVS or SVN trunk to a bzr branch that you can branch from and hack on. | 19:00 |
| rockstar | This way, when you submit a patch to upstream, you also have a versioned path to creating that patch, instead of just having an svn checkout or something. | 19:01 |
| beuno | < LaserJock> QUESTION: so do you do all the code review via email? | 19:01 |
| * beuno doesn't | 19:02 | |
| rockstar | LaserJock, I do most of my code reviews via email, because I like to use Vim as I review a patch. | 19:02 |
| beuno | < LaserJock> QUESTION: is there any real advantage to using a vcs-import instead of bzr-svn? | 19:02 |
| rockstar | LaserJock, but I sometimes use the web interface. | 19:03 |
| rockstar | LaserJock, well, the real advantage is that a vcs-import will stay synced for you, instead of you having to sync it yourself. | 19:03 |
| LaserJock | rockstar: assuming the vcs-import stays in sync, right | 19:04 |
| rockstar | LaserJock, they usually do once the initial import is over. | 19:04 |
| rockstar | There is some work being done to the import system to make it even more robust. | 19:05 |
| LaserJock | .. I'll leave that one alone then ;-) | 19:05 |
| rockstar | The import system uses cscvs (https://edge.launchpad.net/launchpad-cscvs) to import. Patches welcome. | 19:06 |
| rockstar | <tyhicks> QUESTION: In terms of migrating a project to bzr/launchpad, is it possible to import the code from git and preserve all commit history? | 19:07 |
| rockstar | I know there is some work being done on bzr-git (/me looks at jelmer), but currently, the only way to import is using fastexport/fastimport | 19:07 |
| rockstar | Launchpad is planning on supporting git imports this year. | 19:08 |
| rockstar | Alright, thanks everyone! | 19:10 |
| dinxter | thanks! | 19:10 |
| Ape3000 | Anybody know anything about the time of "Debugging program crashes by pitti"? | 19:11 |
| * BenC wonders if there is a moderator, or should I just jump in | 19:11 | |
| iulian | Thank you rockstar, beuno! | 19:11 |
| iulian | We now have BenC with "Packaging Kernel modules with DKMS." | 19:11 |
| iulian | The stage is yours, Ben. | 19:11 |
| BenC | iulian: Thanks | 19:12 |
| * Arc applauds for BenC | 19:12 | |
| crashsystems | was this discussion logged anywhere? | 19:12 |
| Ape3000 | crashsystems: It can be soon fount here: https://wiki.ubuntu.com/MeetingLogs/devweek0901/BzrAndLp | 19:12 |
| BenC | I have to start off by saying that because of last minute schedule changes, I'm going to have to keep this short and sweet :) | 19:12 |
| BenC | So this sessions is about DKMS, and using it to package kernel modules... | 19:13 |
| DoruHush | thank you | 19:13 |
| BenC | DKMS is a program that allows you to easily manage sources for modules, and have them automatically build against the kernel you are running/installing | 19:14 |
| BenC | Generally it's used by users so they can have third party modules, and have those modules stay in sync with the kernel provided by your distro | 19:14 |
| BenC | But we also use it for modules provided by vendors, especially those where there is a binary blob or other closed source portion (e.g. broadcom, fglrx, nvidia) | 19:15 |
| BenC | http://kernel.ubuntu.com/~bcollins/dkms-presentation/ | 19:15 |
| BenC | At the above URL, you can find a presentation I did awhile back, and an example dkms package created for the presentation | 19:16 |
| * BenC pauses for questions... | 19:16 | |
| BenC | Ok, I guess I'll go into some details of the package itself | 19:18 |
| BenC | The source is always installed as /usr/src/<module>-<version> | 19:18 |
| BenC | the package registers this with dkms during postinst | 19:19 |
| BenC | in the above directory is a dkms.conf file that describes the module and how it needs to be built | 19:19 |
| BenC | When the kernel is upgraded (or specifically, when the headers are upgraded) a script installed by dkms is triggered, and checks if any of the modules need to be rebuilt | 19:20 |
| * BenC is assuming people interested in the kernel are already out drinking right now | 19:22 | |
| BenC | Great, that will let me wrap things up quick so I can take care of some other things... | 19:24 |
| BenC | Last chance for questions... | 19:24 |
| BenC | Ok, thanks for having me...have a great weekend everyone | 19:25 |
| Dykam | BenC, you should write this up in a text file somewhere, so people can read it later... | 19:26 |
| Dykam | it is a join/part mess now | 19:26 |
| dinxter | thanks BenC | 19:26 |
| duanedesign | . | 19:48 |
| cody-somerville | Hello Folks :) | 20:01 |
| thiebaude | hi | 20:01 |
| cody-somerville | A coworker of mine is just showing me Xubuntu running on some ARM hardware. :) Pretty neat. | 20:02 |
| cody-somerville | Anyhow, today I'm here to chat about Xubuntu | 20:03 |
| === kahrn_ is now known as kahrn | ||
| cody-somerville | I'm going to cover some of the upcoming changes in Jaunty, how you can take part in making those changes, and then I'm going to hand things off to charlie-tca | 20:04 |
| * charlie-tca waves | 20:04 | |
| cody-somerville | charlie-tca will talk to you about how to get involved in Xubuntu via testing and QA efforts | 20:04 |
| cody-somerville | So, first, lets start off with what I'm sure most Xubuntu users would like to hear about... Xfce 4.6. | 20:05 |
| cody-somerville | We currently have Xfce 4.4.3 uploaded to Jaunty and backported to Intrepid. We're currently working on preparing and uploading the third beta of Xfce 4.6. | 20:05 |
| cody-somerville | Xfce 4.6 will be the next major release of the Xfce desktop | 20:05 |
| cody-somerville | environment. The previous release was 4.4 with the last bugfix release | 20:05 |
| cody-somerville | being 4.4.3. | 20:05 |
| cody-somerville | Xfce 4.6 comes with a lot of new components, some of them replacing old | 20:06 |
| cody-somerville | code and some of them being completely new. | 20:06 |
| cody-somerville | 20:06 | |
| cody-somerville | Replaced components: | 20:06 |
| cody-somerville | * libxfce4mcs => xfconf | 20:06 |
| cody-somerville | * xfce-mcs-manager => xfconf, xfce4-settings | 20:06 |
| cody-somerville | * xfce-mcs-plugins => xfce4-settings | 20:06 |
| cody-somerville | * xfce4-mixer => xfce4-mixer (rewrite) | 20:06 |
| cody-somerville | * xfce4-appfinder => xfce4-appfinder (rewrite) | 20:06 |
| cody-somerville | 20:06 | |
| cody-somerville | New components: | 20:06 |
| cody-somerville | * libxfce4menu (used by xfdesktop and xfce4-appfinder) | 20:06 |
| cody-somerville | Lets take a quick look at some of the changes: | 20:07 |
| cody-somerville | While Xfce 4.4 shipped a centralized settings storage system with | 20:07 |
| cody-somerville | dynamically loaded plugins, 4.6 features a D-Bus based settings | 20:07 |
| cody-somerville | daemon (xfconfd). All settings dialogs are just standalone | 20:07 |
| cody-somerville | applications now which makes the whole platform more flexible. You | 20:07 |
| cody-somerville | can now much easier write a settings dialog and remove/add | 20:07 |
| cody-somerville | components from/to Xfce. | 20:07 |
| cody-somerville | In addition to xfconf and the settings dialogs being ported to | 20:08 |
| cody-somerville | xfconf, there will also be tools addressed to users who would you | 20:08 |
| cody-somerville | like to have direct access to the settings. There is a shell | 20:08 |
| cody-somerville | application xfconf-query which allows to list/get/set properties | 20:08 |
| cody-somerville | and a graphical settings editor is in development and will most | 20:08 |
| cody-somerville | likely be part of 4.6 as well. | 20:08 |
| cody-somerville | So scripting your desktop will become super-duper easy in Xubuntu. | 20:08 |
| cody-somerville | One major complaint I hear is about keyboard shortcuts in Xubuntu, luckily Xfce4 developers have addressed that too. Xfce4 developers have tried to make the keyboard shortcuts settings more | 20:09 |
| cody-somerville | transparent to the user. Shortcut themes have been completely | 20:09 |
| cody-somerville | dropped and there are dialogs now which help resolving conflicting | 20:09 |
| cody-somerville | shortcuts between xfce4-settings (command shortcuts) and xfwm4 | 20:09 |
| cody-somerville | (window manager shortcuts). | 20:09 |
| cody-somerville | Any questions thus far? | 20:09 |
| cody-somerville | Okay, awesome. | 20:09 |
| cody-somerville | Another major complaint was the menu! | 20:10 |
| cody-somerville | In 4.4 xfdesktop used a pseudo-fd.o-compliant menu system. In 4.6 | 20:10 |
| cody-somerville | this is replaced by libxfce4menu which aims at implementing the | 20:10 |
| cody-somerville | fd.o menu spec. It's still in development but covers enough of the | 20:10 |
| cody-somerville | specification already to replace the old code. | 20:10 |
| cody-somerville | The volume control (xfce4-mixer) has also been replaced with a | 20:10 |
| cody-somerville | completely new mixer based on GStreamer 0.10. This removes the need | 20:10 |
| cody-somerville | to maintain support code for different sound architectures and also | 20:10 |
| cody-somerville | provides some new features. | 20:10 |
| cody-somerville | QUESTION:will xubuntu continue to be supported by low machines (~192 RAM)even though applications are growing? | 20:12 |
| cody-somerville | This is a difficult question to answer. I'd certainly like to see Xubuntu attempt to maintain a lightweight, responsive feeling. Unfortunately, performance degradation in Xubuntu often has to do with low-level components such as X and the kernel. | 20:14 |
| cody-somerville | However, there has been changes made in Jaunty that will hopefully see a faster login to desktop time. | 20:14 |
| cody-somerville | QUESTION: What "different sound architectures" did you have in mind? | 20:15 |
| cody-somerville | bullgard4, since the new xfce4-mixer uses gstreamer, it no longer has to maintain code for different sound architectures like alsa, esd, etc. Gstreamer takes care of it. | 20:15 |
| cody-somerville | Anyhow, if you'd like to see some videos of Xfce 4.6 in action, an Xfce4 Developer has posted some here:http://lunar-linux.org/~jannis/videos/xfce/ | 20:16 |
| cody-somerville | Some other enhancements that we're making to Jaunty include: | 20:16 |
| cody-somerville | * Samba browsing via Thunar | 20:16 |
| cody-somerville | You can take a look at a screenshot here: http://cody.zapto.org/screenshots/xubuntu_delivers_samba.jpg | 20:16 |
| cody-somerville | * GIO Mount Manager | 20:17 |
| cody-somerville | * And other improvements to thunar such as a meta-data pane | 20:17 |
| cody-somerville | You can take a look at a screenshot here:http://cody.zapto.org/screenshots/Screenshot%20-%20thunar4.png | 20:18 |
| cody-somerville | * Search in Thunar | 20:18 |
| cody-somerville | You can take a look at a screnshot here: http://cody.zapto.org/screenshots/Screenshot%20-%20thunar2.png | 20:18 |
| cody-somerville | QUESTION: Will old plugins to Thunar and Panel work? | 20:18 |
| cody-somerville | TheSheep, yes | 20:18 |
| cody-somerville | The next item on my list of things to discuss with you guys today is getting involved. | 20:19 |
| cody-somerville | Getting involved in Xubuntu is easy and fun! :) | 20:19 |
| cody-somerville | To start, simply sign up on our xubuntu-devel mailing list and join #xubuntu-devel on Freenode | 20:19 |
| cody-somerville | We're a friendly bunch and enjoy helping folks learn the ropes :) | 20:20 |
| cody-somerville | There are tons of opportunity to take initiative and make your mark. | 20:20 |
| cody-somerville | Packaging, artwork, evangelism, coding, web design, documentation writing, etc. you name it. | 20:21 |
| cody-somerville | :) | 20:21 |
| cody-somerville | Not to mention bug triage and testing! | 20:21 |
| cody-somerville | charlie-tca, :) | 20:21 |
| charlie-tca | Thank you, cody-somerville | 20:21 |
| charlie-tca | I am the lead for Xubuntu QA, Testing and Bug Triage. | 20:22 |
| charlie-tca | Xubuntu is an ideal candidate for old or low-end machines, thin-client networks, or those who would like to get more performance out of their hardware. | 20:22 |
| charlie-tca | Also, Xubuntu is the Xfce-based distribution with a native 64-bit architecture. We produce both a 32-bit and 64-bit versions. | 20:23 |
| charlie-tca | We also produce ports for the Mac PowerPC and Sony PlayStation 3. | 20:23 |
| charlie-tca | Along with producing those versions comes testing to make sure the distribution actually works. | 20:23 |
| charlie-tca | The goal is to have each image tested thoroughly before release. Being a small group, that becomes difficult at times. | 20:24 |
| charlie-tca | To accomplish this testing, almost any hardware will work. I personnally favor a PIII myself. | 20:24 |
| charlie-tca | I do not use any restricted drivers, and normally get 1400x900 resolution out of these machines. The cpu is only 866MHz. | 20:25 |
| charlie-tca | We have information on the xubuntu developers wiki at https://wiki.ubuntu.com/Xubuntu/Testing/TestingInfo for testing Xubuntu. | 20:25 |
| charlie-tca | Since it is Xfce-based, many of the tests are unique to Xubuntu. We also use Thunar for the file manager and Listen for music. | 20:25 |
| charlie-tca | We maintain a short test case for daily images, to allow a quick test to be done. This test is also used for the liveCD testing and shouldn't take more than about 5 minutes to complete. | 20:26 |
| charlie-tca | We also maintain a longer, more involved test for milestone releases. This allows more thorough testing before the users get the image. | 20:26 |
| charlie-tca | When testing the images, results are reported on the qa tracker. This allows the Ubuntu QA team to know the images are good or bad, also. | 20:27 |
| charlie-tca | Most of the bugs we find in Xfce are forwarded upstream to http://bugzilla.xfce.org/ | 20:28 |
| charlie-tca | OpenOffice.org is not included as a default in Xubuntu, so we handle most of the Gnumeric and AbiWord bugs too, since those are the default applications. They are both very powerful for the user, yet lightweight. | 20:29 |
| charlie-tca | We have provided procedures for forwarding Xfce and AbiWord bugs upstream. These procedures help to smooth the processes greatly. | 20:29 |
| charlie-tca | We work very close with xfce, abiword and gnumeric bug teams to help resolve the bugs found. | 20:30 |
| charlie-tca | We have some really exciting things happening, with Xfce 4.6 coming! We will be the first distribution running this, and will be doing extensive tests to make sure it works. | 20:31 |
| charlie-tca | we welcome anyone who would like to assist in development, testing, and bug triage! | 20:31 |
| charlie-tca | Any questions? | 20:32 |
| charlie-tca | <cody-somerville> QUESTION: What do I do when I find a bug? | 20:34 |
| charlie-tca | I did leave that out, didn't I. There is information on https://wiki.ubuntu.com/Xubuntu/Bugs for filing bugs found in Xubuntu testing. | 20:35 |
| charlie-tca | We do report bugs found through launchpad. | 20:35 |
| charlie-tca | We also try to make sure the bugs are forwarded upstream when needed. | 20:36 |
| charlie-tca | <tictacaddict> QUESTION: Is XFCE 4.6 planned for Jaunty, then? | 20:36 |
| charlie-tca | At this time, we are planning to include it in Jaunty. | 20:37 |
| charlie-tca | The beta 3 is being packaged for us at this time. Hopefully, I get to test it before the Alpha4 release. | 20:38 |
| charlie-tca | <bullgard4> charlie-tca: GNOME is there because many users like it.Why don't they choose to take XFCE instead? | 20:41 |
| charlie-tca | Great question! I used Gnome and Ubuntu desktop in the past. I found that on my older equipment, Gnome would react much | 20:42 |
| charlie-tca | too slow for my uses. I could firerox by itself, with at most 4-5 tabs. | 20:43 |
| charlie-tca | I had to replace OpenOffice.org apps with AbiWord and Gnumeric. | 20:43 |
| charlie-tca | Xubuntu comes ready for me to use on that same equipment. I can now use the system without replacing many of the applications. | 20:44 |
| charlie-tca | Xubuntu's lower memory requirement and use of light weight applications fit the older hardware very well. | 20:45 |
| charlie-tca | Any more questions? | 20:47 |
| charlie-tca | I think that for anyone trying it, you will find that Xubuntu gives excellent performance with no loss of applications. | 20:47 |
| charlie-tca | We maintain the same release schedule as Ubuntu, and did release Hardy Heron 8.04 as an LTS. | 20:49 |
| charlie-tca | Since we are using the same repositories as Ubuntu, Xubuntu is as up to date as Ubuntu. | 20:50 |
| charlie-tca | <ongolaBoy> QUESTION: when will be xubuntu 8.04.2 available ? | 20:50 |
| charlie-tca | Due to the packaging requirements, Xubuntu will not be releases as .2 ; however, if you update your system, it is automatic. | 20:51 |
| charlie-tca | The .2 release is simply Ubuntu 8.04 with the latest updates to the point of the .2 release. | 20:52 |
| charlie-tca | <ongolaBoy> charlie-tca: ok. so the last spin was xubuntu 8.04.1 | 20:53 |
| charlie-tca | Yes, the last 8.04 spin was .1 | 20:53 |
| charlie-tca | And, it will probably stay as the 8.04.1 through it's lifetime. Our images are built by the same team, and do use most of the same software. | 20:54 |
| charlie-tca | I would like to thank everyone for participating! Have a great day! | 20:58 |
| iulian | Thank you cody-somerville, charlie-tca. That was very interesting. | 21:00 |
| iulian | OK, so I'm afraid I will have to say that this is the end of Ubuntu Developer Week. | 21:01 |
| iulian | I would like to thank you all for participating and have a wonderful weekend! | 21:01 |
| iulian | I am sure you all had a great time! | 21:01 |
| mneptok | iulian: multsumesc! | 21:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
