[01:03] <Matr|X> hello i need help in ubntu plz
[01:10] <jmarsden|work> Matr|X: Ask in #ubuntu, not in here, #ubuntu-classroom is for classes at specific times.
[01:11] <Matr|X> thx
[01:11] <Matr|X> sorry
[01:15] <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
[07:02] <somaunn> i'm looking for someone who have knowledges of sed
[07:21] <techno_freak> somaunn, #bash
[07:47] <somaunn> techno_freak: thank you
[13:28] <CrownAmbassador> Does anyone have the getting started talk from Monday? It is not on http://wiki.ubuntu.com/MeetingNotes
[13:29] <istaz> CrownAmbassador: the one on this channel?
[13:30] <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:32] <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:34] <CrownAmbassador> MarkoKaa: Thanks.
[13:34] <MarkoKaa> No problem
[13:36] <CrownAmbassador> Does anyone know when Pitti will be doing his deleted talk?
[15:05] <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:06] <james_w> cool :-)
[15:06] <james_w> do you know the process for getting it updated in jaunty?
[15:07] <Ape3000> Not perfectly
[15:08] <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:09] <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:10] <james_w> so you can link the reports in launchpad once you have filed the Ubuntu bug
[15:12] <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:13] <james_w> https://bugs.launchpad.net/ubuntu/+source/typespeed/+filebug
[15:16] <Ape3000> https://bugs.launchpad.net/ubuntu/+source/typespeed/+bug/320484
[15:16] <Ape3000> So how do I link the debian bug?
[15:22] <james_w> Ape3000: click on "Also affects Distribution", select Debian, and enter the url I gave
[15:59] <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!
[16:00] <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:01] <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:02] <dholbach> :-)(
[16:03] <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:04] <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?
 QUESTION: is this like pbuilder ?
[16:05] <liw> zerwas, thanks (I was just fighting my irc client to do that :)
[16:06] <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:07] <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:08] <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:09] <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:10] <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:11] <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
 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
 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:13] <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:14] <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:15] <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:16] <liw> I should pastebin some actual log output, just a minute.
[16:17] <liw> http://paste.ubuntu.com/108624/ and http://paste.ubuntu.com/108625/ are two snippets of an actual log file
[16:18] <liw> just to give you a taste of what they look like. the beginning and the end.
 QUESTION: How much time does the basic test usually take?
[16:19] <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:20] <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:21] <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.
 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:22] <liw> except on a netbook, perhaps
[16:22] <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:23] <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:24] <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:25] <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:26] <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:27] <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.
 So what's the command to test upgradability from the current stable release? I guess -d intrepid -d jaunty foo.deb?
[16:30] <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"
 I just had this error: E: Couldn't find package debfoster
[16:31] <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:32] <liw> let me check something
[16:34] <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:35] <liw> so the solution is to tell piuparts to use universe as well as main
[16:36] <liw> except for some reason, for me the debfoster thing works, so I have a hard time testing, hmm
[16:37] <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:40] <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:43] <weboide> liw: It just passed the debfoster installation. so it helped :)
[16:43] <liw> weboide, yay
[16:47] <liw> any further questions? is everyone busy waiting for their machines to stop churning?
[16:48] <jbernard> yep ;)
[16:57] <mneptok> liw: i thought "Thou shalt not paste Unix commands from Finns on IRC into thy shell," was one of the new commandments.
[16:58] <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:59] <dinxter> cheers liw!
[17:00] <Ape3000> I just got it working :D
[17:00] <liw> Ape3000, yeay
[17:01] <zerwas> THANKS for all this liw!
[17:03] <mvo> hello
[17:04] <mvo> I think I'm next :)
[17:05] <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:06] <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:07] <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:08] <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:09] <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:10] <mvo> any questions so far?
[17:11] <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:12] <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:14] <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:15] <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:16] <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:17] <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:19] <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:20] <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:21] <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:22] <mvo> all good so far? examples working :) ?
[17:24] <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:25] <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:26] <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:27] <mvo> cache["2vcard"].markInstall()
[17:27] <mvo> cache.commit(fetchprogress, installprogress)
[17:27] <mvo> cache.open(apt.cache.OpProgress())
[17:28] <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:29] <mvo> (the last line should be cache.open(apt.progress.OpProgress()) - thanks to maxb)
[17:30] <mvo> any change done in the cache is just "simulated" until commit() is called
[17:31] <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:32] <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:33] <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:34] <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:35] <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:36] <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:37] <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:38] <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:39] <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:41] <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:42] <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:43] <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:44] <mvo> pkg = cache["synaptic"]
[17:44] <mvo> print "Bugs entry: ", pkg.candidateRecord["Bugs"]
[17:44] <mvo> print "Full record: ", str(pkg.candidateRecord)
[17:45] <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:46] <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:47] <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:50] <mvo> if there are none, thank you very much for your attention and I hope you have enjoyed it :)
[17:52] <jbernard> thanks alot, very helpful
[17:52] <mvo> let me answer the packagekit question first
[17:53] <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:54] <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:55] <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:56] <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:57] <mvo> gdebi for example only switches to root for the actual installing, everything else is done as the user
[18:01] <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:05] <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:06] <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:07] <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:08] <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:09] <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:10] <rockstar> If it returns a <user@host> to you, you need to configure it.
[18:11] <rockstar> So you'll need to type `bzr whoami "Paul Hummer<EMAIL_ADDRESS>obvious substitutions.
[18:11] <rockstar> ...apply
[18:11] <rockstar> Now bzr will know who attribute your revisions to.
[18:12] <holloway> sorry for the interrupt, you mean `bzr whoami "Paul Hummer<EMAIL_ADDRESS>?
[18:12] <rockstar> `bzr whoami "Paul Hummer<EMAIL_ADDRESS>[18:12] <rockstar> Thanks for the clarification beuno
[18:12] <beuno> holloway, please head over to #ubuntu-classroom-chat for questions
[18:13] <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:14] <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:15] <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:16] <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:17] <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:18] <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:19] <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:20] <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:21] <rockstar> apw, if you go to https://edge.launchpad.net/entertainer you'll see a link that says trunk (focus of development)
[18:22] <rockstar> Click on that, and you'll see a link to the "trunk" branch.
[18:23] <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:24] <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:26] <rockstar> Alright, moving on...
[18:26] <rockstar> Now we have the "trunk" set up.
[18:27] <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:28] <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:29] <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:30] <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:31] <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:32] <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:33] <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:34] <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:35] <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:36] <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:37] <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:38] <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:39] <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:40] <rockstar> Looking at his branch page on Launchpad, cthulu then clicks "Propose for merging into another branch"
[18:41] <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:42] <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:43] <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:44] <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:45] <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:46] <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:47] <rockstar> First I get really excited to see a new contributor.
[18:48] <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:49] <rockstar> I'll make comments and suggestions, and then I'll give it a vote.  For this example I'll vote "Needs Fixing"
[18:50] <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:51] <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:52] <rockstar> Not to worry though, because there are other members of entertainer-releases that can merge (or "land") cthulu's changes into trunk.
[18:54] <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:55] <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:56] <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:57] <rockstar> ia, creating a project is a pretty easy process.  https://edge.launchpad.net/projects/+new
[18:58] <rockstar> Then just pick up where I started in this session.
[18:58] <rockstar> Any other questions?
[18:59] <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.
[19:00] <rockstar> Import branches sync a CVS or SVN trunk to a bzr branch that you can branch from and hack on.
[19:01] <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:02]  * 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:03] <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:04] <LaserJock> rockstar: assuming the vcs-import stays in sync, right
[19:04] <rockstar> LaserJock, they usually do once the initial import is over.
[19:05] <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:06] <rockstar> The import system uses cscvs (https://edge.launchpad.net/launchpad-cscvs) to import.  Patches welcome.
 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:08] <rockstar> Launchpad is planning on supporting git imports this year.
[19:10] <rockstar> Alright, thanks everyone!
[19:10] <dinxter> thanks!
[19:11] <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:12] <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:13] <BenC> So this sessions is about DKMS, and using it to package kernel modules...
[19:13] <DoruHush> thank you
[19:14] <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:15] <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:16] <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:18] <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:19] <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:20] <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:22]  * BenC is assuming people interested in the kernel are already out drinking right now
[19:24] <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:25] <BenC> Ok, thanks for having me...have a great weekend everyone
[19:26] <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:48] <duanedesign> .
[20:01] <cody-somerville> Hello Folks :)
[20:01] <thiebaude> hi
[20:02] <cody-somerville> A coworker of mine is just showing me Xubuntu running on some ARM hardware. :) Pretty neat.
[20:03] <cody-somerville> Anyhow, today I'm here to chat about Xubuntu
[20:04] <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:05] <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:06] <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:07] <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:08] <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:09] <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:10] <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:12] <cody-somerville> QUESTION:will xubuntu continue to be supported by low machines (~192 RAM)even though applications are growing?
[20:14] <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:15] <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:16] <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:17] <cody-somerville>  * GIO Mount Manager
[20:17] <cody-somerville>  * And other improvements to thunar such as a meta-data pane
[20:18] <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:19] <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:20] <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:21] <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:22] <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:23] <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:24] <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:25] <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:26] <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:27] <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:28] <charlie-tca> Most of the bugs we find in Xfce are forwarded upstream to http://bugzilla.xfce.org/
[20:29] <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:30] <charlie-tca> We work very close with xfce, abiword and gnumeric bug teams to help resolve the bugs found.
[20:31] <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:32] <charlie-tca> Any questions?
 QUESTION: What do I do when I find a bug?
[20:35] <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:36] <charlie-tca> We also try to make sure the bugs are forwarded upstream when needed.
 QUESTION: Is XFCE 4.6 planned for Jaunty, then?
[20:37] <charlie-tca> At this time, we are planning to include it in Jaunty.
[20:38] <charlie-tca> The beta 3 is being packaged for us at this time. Hopefully, I get to test it before the Alpha4 release.
 charlie-tca: GNOME is there because many users like it.Why don't they choose to take XFCE instead?
[20:42] <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:43] <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:44] <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:45] <charlie-tca> Xubuntu's lower memory requirement and use of light weight applications fit the older hardware very well.
[20:47] <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:49] <charlie-tca> We maintain the same release schedule as Ubuntu, and did release Hardy Heron 8.04 as an LTS.
[20:50] <charlie-tca> Since we are using the same repositories as Ubuntu, Xubuntu is as up to date as Ubuntu.
 QUESTION: when will be xubuntu 8.04.2 available ?
[20:51] <charlie-tca> Due to the packaging requirements, Xubuntu will not be releases as .2 ; however, if you update your system, it is automatic.
[20:52] <charlie-tca> The .2 release is simply Ubuntu 8.04 with the latest updates to the point of the .2 release.
 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:54] <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:58] <charlie-tca> I would like to thank everyone for participating! Have a great day!
[21:00] <iulian> Thank you cody-somerville, charlie-tca.  That was very interesting.
[21:01] <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:31] <mneptok> iulian: multsumesc!


[09:08]  * enyc meows
[09:08] <enyc> Curious if LTS Kernel 5.4 creating increasing problems with new AMD's and so-on
[09:08] <enyc> or indeed new intels
[09:08] <enyc> I guess desktop variants include HWE for this reason, or so
[09:08] <enyc> but server variants too.... etc... ?
[11:13] <xnox> yes, no, maybe.
[11:13] <xnox> enyc:  most cloud kernels are rolling to newer series; some servers opt into hwe kernel but it is relatively short-lived, cause it does roll every 6 months until it gets parked on the next lts.
[11:13] <xnox> enyc:  desktops do default to hwe or oem kernels
[11:14] <xnox> enyc:  i have seen servers use intermediate releases; rather than hwe kernel. and then upgrade up to next lts then park on it.
[11:31] <enyc> xnox: hrrm that makes sense, nad I've done that setting up a dev systet or desktop, on pre-release   because if that works thats usually better  to then land in next-LTS than be on older-release


[03:40] <tb007noob> Hello Anyone Available To Help Me
[03:45] <tb007noob> Hello
[17:10] <Guest21748> hi team
[17:12] <wxl> hi
[17:17] <Guest21748> weiss du wie cache frei bekommt lubuntu
[17:19] <Guest21748> mem
[17:20] <wxl> !de
[17:23] <Guest21748> sorry
[17:23] <Guest21748> thanks
[17:24] <Guest21748>  frist question how can i clean cache
[17:31] <wxl> what cache?
[23:42] <user__> Hello everyone.
[23:43] <user__> So I just installed Lubuntu 19.04 recently, and tried to drag some pictures from my Android phone to the Desktop, when I got the options "Copy Here", "Move Here", and "Insert Symlink Here", I tried all of them but they didn't transfer to the desktop.
[23:44] <user__> However, only when I right clicked on the pictures, pressed "Copy", and pasted them, then they showed up on the desktop.
[23:47] <user__> This is the same guy that shared the imgur link with the similar issue.


[00:01] <maxb> The dist-packages thing is all about separating the install directories for site-installed modules being installed for the *system* python, vs. the modules of a completely site-installed python
[00:10] <JanC> maxb: right, so that if you install the new google-developed cpython-fork from source, things don't break between both of those
[06:26] <dholbach> good morning
[06:37] <YoBoY> hi dholbach
[06:37] <YoBoY> good morning
[06:43] <dholbach> hi YoBoY
[07:54] <thekorn> good morning
[08:15] <Ryan52> is there some easy way I can subscribe to bugs for packages? where easy means from a script or from a non interactive command line program. ;-)
[08:18] <thekorn> Ryan52, goto launchpad.net/ubuntu/+source/PACKAGE and click on "subscribe to bugmail"
[08:19] <Ryan52> I want to do this from a script..
[08:19] <Ryan52> your method doesn't scale well.
[08:20] <thekorn> ah, ok, got it now ;)
[08:21] <Ryan52> basically I'm lazy, I already have a list of "my" (or partially mine, or soon to be mine) packages (there's 104 of them), and I want to get ubuntu bug mail for them. I think I'm subscibed to maybe 10 of them... :P
[08:23] <thekorn> Ryan52, there are two python libraries to access launchpad, python-launchpad-bugs and launchpadlib, but both cannot do this for you
[08:23] <thekorn> oh, 104, that's a big number
[08:27] <thekorn> but I think scripting this should be easy, it looks like you have to POST something like {"field.subscribe_me.used": 1, "field.subscribe_me":1} to https://edge.launchpad.net/ubuntu/+source/PACKAGE/+subscribe
[08:28] <Ryan52> how do I handle logging in from a script, tho?
[08:31] <thekorn> Ryan52, you can use your mozilla cookie or a base64 encoded Authorization header
[08:35] <Ryan52> thekorn: ok, thanks!
[08:35] <thekorn> no problem
[12:29] <BUGabundo> calc: https://bugs.launchpad.net/bugs/346943
[12:29] <BUGabundo> that bug is becoming a nuisance
[12:31] <james_w> BUGabundo: rgrep -i office ~/.compiz/session
[12:32] <BUGabundo> james_w: empty
[12:33] <james_w> BUGabundo: what about calc?
[12:33] <BUGabundo> sorry?
[12:34] <james_w> rgrep -i calc ~/.compiz/session
[12:34] <BUGabundo> james_w: empty too
[15:12] <bddebian> Boo
[15:15] <BUGabundo> foo
[15:15] <bddebian> :)
[15:35] <BUGabundo> calc: ping
[15:35] <BUGabundo> just .openoffice or openoffice3 too?
[15:39] <calc> BUGabundo: any .openoffice*
[15:39] <BUGabundo> did both
[15:39] <calc> BUGabundo: perhaps .openoffice.org2 and .openoffice.org
[15:39] <BUGabundo> updated the bug
[15:39] <BUGabundo> it *worksP
[15:40] <calc> ah so it is some sort of werid configuration issue on your system
[15:40] <BUGabundo> I only have .org and .org3
[15:40] <BUGabundo> where would OOo conf set the Workspace?
[15:41] <calc> i have no idea at all
[15:41] <calc> i have a small idea
[15:41] <calc> let me see if i can find the file name
[15:42] <calc> i don't know if it is the same file as was causing problem for other users or not, let me see
[15:42] <BUGabundo> want me to pack and upload those conf dirs?
[15:42] <calc> maybe 3/user/registry/data/org/openoffice/Setup.xcu
[15:42] <calc> not really needed, unless you can make it reproduce again with a clean config dir i can't do anything with the bug
[15:43] <calc> as upstream won't take the issue unless I can prove it happens on their version
[15:43] <BUGabundo> ok
[15:43] <calc> they outright close their own bugs by the mere mention of Ubuntu in the same bug report, regardless of if the user even uses ubuntu
[15:43] <calc> eg a Windows XP OOo user mentioned that Ubuntu seemed to have the same problem so they closed the bug
[15:43] <calc> *@#! developers ;-)
[15:44] <charlie-tca> \o/
[15:44] <calc> that file above i noted may be all that is needed to be deleted to make it work for you
[15:44] <calc> but i am not certain, that file causes problems for users with forced maximized mode (aiui)
[15:44] <calc> charlie-tca: :)
[15:45] <BUGabundo> calc: http://pastebin.com/m68630c59
[15:47] <calc> BUGabundo: does just removing that file fix the problem also?
[15:47] <calc> i don't see anything in that file that seems to note virtual desktop it should run on
[15:48] <calc> but i am not 100% certain i am reading the file correctly
[15:48] <BUGabundo> let me try
[16:00] <BUGabundo> calc: just removing that file, seems to fix the prob
[16:00] <calc> BUGabundo: ok
[16:01] <calc> BUGabundo: if you can determine how to properly reproduce the bug then please reopen bug report with the information, then i can send the bug report to OOo developers
[16:01] <calc> otherwise they either close the bug immediately or never look at it at all
[16:02] <calc> we have a bug where OOo can get stuck in a permanent fullscreen mode which I was never able to reproduce until someone gave exact instructions (had to do with compositing being disabled, etc) then it was easy and now upstream is looking into it :)
[16:05] <BUGabundo> ok
[16:05] <BUGabundo> but since most of that info on the file doesn't seem to affect me options
[16:05] <BUGabundo> I have no idea how to reproduce
[16:05] <BUGabundo> maybe a PPA vs Archive thing
[16:07] <calc> ppa is the same as the archive (essentially)
[16:07] <calc> i only modified options that had to be to make it compile on older releases
[16:07] <calc> its probably just something very hard to trigger
[16:08] <calc> the fact the file is corrupt is a symptom not the issue itself, so without knowing what the issue is we can't really fix it
[16:10] <BUGabundo> ahh
[16:10] <BUGabundo> like XFS fail to dump to disj
[16:10] <BUGabundo> *disk
[16:10] <calc> sorta
[16:10] <BUGabundo> like many now like to call Ext4 bug
[16:10] <BUGabundo> that could be it
[16:11] <BUGabundo> very hard to trigger
[16:11] <calc> something in OOo is getting confused and writing out bad data about window states, which causes it to open on a different window than it should
[18:35] <thekorn> bdmurray, hi, I think it's time to purge lp_activity_comments.user.js from launchpad-gm-scripts
[18:35] <thekorn> it does not work correctly and launchpad does the job now
[18:37] <bdmurray> thekorn: sounds good to me, its exciting to see it deprecated ;-)
[18:38] <thekorn> yes, this new way of presenting activitylogs is the best UI improvement in the last couple of month ;)
[18:40] <thekorn> bdmurray, what do you think is the best way to proceed, should I create a bug for this, change it in an attached branch and request a merge?
[18:47] <bdmurray> thekorn: I hate to "lose" the script totally as it might contain something somebody can learn from.  Perhaps renaming it is the best idea?
[18:49] <thekorn> bdmurray, well the good thing about VCS is that it is still in the history, but renaming it is also fine, what about creating a "deprecated" directory and putting it there
[18:50] <bdmurray> thekorn: deprecated sounds fine and a merge proposal would be great
[18:50] <thekorn> ok, I'm going to create one now
[18:50] <thekorn> thanks
[18:50] <bdmurray> Thank you!
[19:09] <thekorn> bdmurray, I've created https://code.edge.launchpad.net/~thekorn/launchpad-gm-scripts/purge-activity-comments/+merge/5077
[20:25] <pitwalker> Anyone can start xfmedia without compositing?
[20:25] <pitwalker> https://bugs.launchpad.net/ubuntu/+source/xfmedia/+bug/333384
[21:39] <torkiano> hello, I reported bug #348275 but now all work ok
[21:40] <torkiano> I see here: https://wiki.ubuntu.com/Bugs/Responses#Bugs resolved after update or config change that I should mark it as invalid
[21:41] <torkiano> What should I do?
[21:44] <bdmurray> torkiano: What is different that may have fixed it?
[21:46] <torkiano> maybe the latest network-manager upgrade, but I am not sure, sorry
[21:47] <bdmurray> since other people are experiencing it and it is being tracked in Jaunty I'd leave it be
[21:47] <bdmurray> However, generally setting a bug to Invalid in this case would be fine
[21:48] <torkiano> bdmurray, ok, thank you
[21:48] <bdmurray> Thank you for asking!
[21:49] <torkiano> bdmurray, I close the upstream kernel bug because I don't upgrade any kernel package
[22:17] <hggdh> greg-g, ping
[22:20] <greg-g> hggdh: hello
[22:23] <hggdh> hi greg-g -- re. bug 351211 -- I am considering reassigning all such bugs elsewhere, perhaps libc
[22:23] <hggdh> this really does not look like a coreutils issue. In fact, we have many such bugs in other packages
[22:24] <greg-g> hggdh: sure, I actually didn't take a close look at those as I was just marking a lot of private bugs public (especially ones that were "master" bugs for other duplicates)
[22:25] <greg-g> this was after bdmurray blogged about the list of bugs opened during Jaunty's development, I sorted by Gravity and there were a bunch of private near the top
[22:26] <hggdh> heh
[22:26] <hggdh> OK, I will start the reassignment
[22:28] <hggdh> oooooh this goes a loong way back... oldest open bug on SEGV at __libc_start_main is bug 90660!
[22:32] <greg-g> wow, yeah, something to look into then
[23:24] <ghindo> Hi, if I know of a bug which has already been reported upstream, should I still report it through Launchpad?
[23:24] <bdmurray> ghindo: It depends on its importance / severity
[23:24] <bdmurray> Is it something that needs to be fixed in Jaunty?
[23:25] <ghindo> bdmurray: I'm not sure
[23:25] <ghindo> bdmurray: I'm mostly asking on behalf of this thread:  http://ubuntuforums.org/showthread.php?t=1112258
[23:27] <bdmurray> ghindo: Yes, that would be good to open in Launchpad since its a crash and something we'd like to fix in Jaunty
[23:29] <ghindo> bdmurray: Cool, thank you.
[23:30] <bdmurray> Some low priority ones it might make more sense just to open upstream, and the fixes will be pulled in during development of the next release.


[11:07] <bullgard4> [Ubuntu 11.10 GNOME Shell <IP_ADDRESS>] Super key > Applications > System tools > Power statistics > Prozessor > Wake-up processes lists 2 types of wakeup processes: i.) Symbol is a rhombus, ii.) Symbol is a gear. What is the name of these two types?
[13:12] <smoser> smb`, tgardner just fyi, put some new comments in bug 963420.
[13:12] <ubot2`> Launchpad bug 963420 in wget "https download performance significantly worse in precise than lucid" [Medium,Confirmed] https://launchpad.net/bugs/963420
[13:13] <smoser> my kernel assesment was probably wrong.
[13:34] <tgardner> smoser, cool, thanks for the note.


[00:00] <darkxst> jbicha, umm what for?
[00:02] <darkxst> is there something else thats needs to be fixed?
[00:21] <jbicha> yeah, I think we shouldn't use disable-log-out since it also hides power off/restart
[00:21] <jbicha> you could use disable-user-switching to hide "Switch Session"
[00:22] <jbicha> https://bugzilla.gnome.org/show_bug.cgi?id=684118
[00:22] <jbicha> I doubt that will get fixed for 3.6 since they're in code freeze, but maybe for 3.8
[00:27] <darkxst> hmm ok
[00:29] <jbicha> there were some complaints on the forum and I think they're right
[00:30] <darkxst> jbicha maybe I can use casper to patch out the logout item from the menu
[00:33] <jbicha> yeah, you probably could, I don't know if disabling log out is very important...
[00:33] <jbicha> but if you do, I think it's /usr/share/gnome-shell/js/ui/userMenu.js
[00:44] <darkxst> well except if they log out they land at a userless GDM
[00:47] <jbicha> oh yeah, there is that
[00:51] <darkxst> I will upload a patch upstream
[00:51] <darkxst> and if it doesnt make it in, apply it with casper
[00:52] <jbicha> cool, thanks!
[03:49] <darkxst> jbicha, goes a bit deeper than just the shell
[03:50] <jbicha> darkxst: could you update your descriptions for http://bugzilla-attachments.gnome.org/attachment.cgi?id=224433
[03:51] <jbicha> the first shouldn't have changed, and I think the second should be "Prevent the user from shutting down" or something
[03:53] <jbicha> yeah, Jasper said the same thing :)
[03:54] <jbicha> wow, 3 different modules to patch, that'll be fun
[03:54] <darkxst> the lockdown is actually set in gnome-session
[03:56] <darkxst> if just patch the shell, then power-off will still fail
[05:58] <darkxst> I will go back to my original idea
[05:58] <darkxst> jbicha: sed -i 's/let multiSession.*$/let multiSession = false/' /root/usr/share/gnome-shell/js/ui/userMenu.js
[06:11] <jbicha> yeah, that would probably work
[06:32] <darkxst> jbicha, https://code.launchpad.net/~darkxst/casper/fix-gdm-autologin-lp1046630-fix2/+merge/124566
[08:34] <darkxst> jbicha, actually that patch also removes 'switch session' did we want to leave that or not? would probably also result in userless login screen anyway
[12:36] <jbicha> darkxst: yeah, that's fine
[12:36] <smartboyhw> Hey jbicha
[12:37] <jbicha> hi
[16:13] <jbicha> oops, I left evolution out of the metapackage
[16:14] <jbicha> if we include it, I don't think there's any way we can keep close to an 800MB image
[16:19] <jbicha> interesting that no one complained yet though about it being missing...
[20:59] <darkxst> jbicha, so how then, would someone access gnome classic from the live CD?
[21:10] <jbicha> darkxst: they could use dconf to change the default session, but yeah it wouldn't be very obvious
[21:23] <darkxst> jbicha, so perhaps we should make ubuntu user show up in gdm and set nopasswd login?
[21:31] <jbicha> well it looks like 'ubuntu' is user 999 which explains why it's not showing up in gdm
[21:32] <jbicha> and I think the 'ubuntu' user intentionally does have a password
[21:41] <darkxst> I suppose it would be better to add an extra option to the first screen ("try shell", "try classic")
[21:41] <darkxst> but that might not be so easy to do
[23:50] <darkxst> finally, the menu bars are fixed in libreoffice!
[23:54] <jbicha> they still are broken in Unity though :(


[15:13] <Linden940> good morning
[17:14] <aeroplanez> morning
[17:14] <aeroplanez> anybody happens to know anything about military badges
[17:15] <aeroplanez>  i have some unidentified ones
[17:16] <Linden940> go to the dallas irc
[17:16] <Linden940> there is a x army guy in there...JJNova
[17:54] <aeroplanez> thanks
[18:24] <aeroplanez> http://www.huffingtonpost.com/2011/11/21/texas-drought-ghost-towns-graves_n_1104563.html


[11:56] <Ubugtu> New bug: #75102 in xserver-xorg-video-nv "display flickering problem" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75102
[02:55] <Ubugtu> New bug: #75121 in xserver-xorg-video-nv "vesa selected as default instead of nv on Feisty" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75121
[06:55] <Ubugtu> New bug: #75146 in xorg "Upgrade to 1:7.1.1ubuntu6.2 breaks AGP / xinerama " [Undecided,Unconfirmed]  http://launchpad.net/bugs/75146
[07:10] <Ubugtu> New bug: #75149 in xorg "Palm TX connecting on USB does not have consistent device name" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75149