[01:36] <cody-somerville> If you were going to introduce someone to Ubuntu, would you go ahead and install Ubuntu 9.10 for them or would most folks recommend waiting for 10.04 at this point? I've heard a lot of great things about 10.04.
[01:37] <jdong> cody-somerville: at this point wait for 10.04 to hit final
[01:37] <cody-somerville> Cool.
[02:05] <psusi> whoa... I really pissed something off when I ejected a dvd that had music on it I had previously been listening to with rhythmbox and put in the livecd and tried to open it... the drive vanished from nautilus and /var/log/kern.log is filling with errors saying "VFS: busy inodes on changed media or resized disk sr0"
[02:06] <psusi> it's like the old disk is still mounted but doesn't show in /proc/mounts
[02:10] <psusi> hrm... closing rhythmbox seems to have fixed it.... that shouldn't happen should it?  what IS supposed to happen if files are in use when the media is ejected?  I thought the fs was forcibly unmounted and all fds to files there were invalidated?
[02:41] <lamont> nxvl: still around?
[03:14] <poningru> OMG we were in a Univeristy challenge question
[03:20] <LaserJock> is that a good thing or a bad thing?
[03:24] <nigelb> crimsun, ping?
[03:28] <nxvl> lamont: here
[03:29] <lamont> nxvl: I figured I'd let you have the 0.92 upload honors. FFe is blessed, we win, kthx.
[03:29] <nxvl> just uploaded it \o/
[03:39] <crimsun> nigelb: pong
[03:39] <ScottK> lamont and nxvl: Accepted.
[03:39] <nigelb> crimsun, can you sign up for an hour or 2 as review leader for patch day? https://wiki.ubuntu.com/PatchDay
[03:41]  * nxvl HUGS ScottK 
[03:41] <crimsun> nigelb: May 5 looks to be a Wednesday, which would place it squarely mid-workday for me?
[03:42] <ScottK> nxvl: Go fix me some FTBFS.  BTW, I fixed courier for you (your last upload FTBFS)
[03:43]  * nxvl runs away silently :P
[03:43] <nxvl> will start squashing them on the weekend
[03:48] <ajmitch> #ubuntu-reviewers is the regular channel for it?
[03:49]  * ajmitch thought it'd be -reviews
[04:36] <psusi> wow..... just tested installing lucid beta 2 ( or today's nightly that apparently will be beta 2 ) installing to 1.5 tb wd green drive.. takes 11 minutes normally, then when I edit /etc/mke2fs.conf and add lazy_itable_init=1, install time goes down to just over 5 minutes... gets rid of a 5:30-6:00 period of sitting at 5% while running mkfs
[04:36] <psusi> from liveusb
[04:37] <psusi> that seems a pretty damn significant performance improvement... any chance of getting that option set for lucid release? :)
[04:40] <TheMuso> psusi: Does it fix a bug, other than performance, and is it safe to use that option in most cases?
[04:45] <IntuitiveNipple> Can someone take a look at bug #555500 and maybe push it for release please?
[04:47] <psusi> TheMuso, no, just takes the mkfs time from 5.5-6 minutes down to ~15 seconds... doesn't seem to be any risk per se... just doesn't init the inode bitmaps and sets a flag on the bg descriptors to tell the kernel that so it initializes them when needed and until then assumes they are unused
[04:47] <TheMuso> psusi: ah.
[04:47] <persia> psusi: Does that affect later runtime performance significantly?
[04:49] <psusi> persia, doesn't seem to... the rest of the install seems to proceed at the same rate as before... and the itable only needs initialized if the kernel actually needs to allocate inodes from that bg... and generally speaking, a lot more inodes are allocated than needed, so most bgs can remain with uninitialized inode bitmaps indefinately
[04:50] <persia> OK.  I suspect the user has to pay the 5 minutes at some point, but distributed over the lifetime of the install, this may be less obviously apparent.
[04:50] <psusi> only if they actually use all of the inode tables... most often this is not the case
[04:50] <psusi> since generally, many more inodes are reserved than the fs will ever have files to use
[05:03] <psusi> cjwatson, added ubiquity to bug #556621 since this has such a large impact on installing from the livecd.  If it is not made system wide default via mke2fs.conf, then ubiquity at least should consider specifying it when calling mkfs
[05:11] <cjwatson> psusi: I don't think ubiquity should touch it - mke2fs(8) says that it's 1 by default, so why isn't it?
[05:11] <cjwatson> oh, maybe it doesn't say that
[05:11] <psusi> cjwatson, you know, I thought so at first but now I get it... the man page is just misleading
[05:12] <cjwatson> psusi: please don't ever use the ubiquity upstream project for bug tracking.  I'll fix it up
[05:12] <psusi> if you specify lazy_itable_init, then the VALUE defaults to 1 if you don't explicitly =1
[05:12] <psusi> but if you don't say anything, the default is 0
[05:12] <cjwatson> yeah, I've arrived at that reading now
[05:13] <psusi> if setting it in mke2fs.conf to be a system wide default is not done, ubiquity could add the -E lazy_itable_init when calling mkfs... it makes such a huge difference on these larger drives...
[05:16] <psusi> ohh, yea... I guess that should have been ubiquity(ubuntu) but my lp-fu is weak
[05:16] <cjwatson> yeah, I've made that change locally and will test.  thanks!
[05:18] <cjwatson> I have an external 1TB disk that should be a good test target
[05:19] <psusi> cool
[05:20] <lifeless> persia: I was in ubuntu-universe-sponsors. Its expiring; what should I do?
[05:22] <psusi> after monkeying with this a bit and looking at the fs with debugfs while testing with e2defrag, it seems the default behavior is with unint_bg feature on by default for ext4, mke2fs leaves the BLOCK usage bitmaps in each bg uninitialized and sets the flag indicating such on each bg, but without lazy_bg_init=1, it goes ahead and initializes the inode tables and inode allocation bitmaps in each bg to zeroes
[05:23] <psusi> with lazy_itable_init=1 it also leaves the inode tables and bitmaps uninitialized and sets corresponding flags in the bg descriptors indicating this is so
[05:23] <persia> lifeless: If you wish to continue as a sponsor, join ubuntu-sponsors (I'll do that now unless you countermand me before I finish)
[05:25] <psusi> cjwatson, btw, given any thought to moving to gpt as the default partition label yet when using the full disk on disks over 1tb? ;)
[05:25] <lifeless> persia: I'd like to. But I'm not able to upload to 'main' yet
[05:26] <TheMuso> psusi: Does that not require the host system BIOS to be able to work with GPT? Yes I know there is the GPT/mbr sync stuff...
[05:26] <psusi> TheMuso, nope.... since gpt still has an mbr
[05:27] <TheMuso> ok
[05:27] <psusi> it just looks like the entire disk is used by one partition of type e8 I think it was, unless you use gptsync
[05:27] <persia> lifeless: That's OK.  Just pick stuff you *can* upload from http://qa.ubuntu.com/reports/sponsoring
[05:28] <persia> lifeless: "unseeded" is the useful keyword (code improvements to make discovery easy are very welcome)
[05:29] <psusi> and grub should still install and boot fine... it will use blocklists otherwise, but prefers to dump the core in the grub dedicated gpt partition which could be created by default when using a full disk initializing it with gpt as well by default
[05:30]  * psusi needs to try that out next
[05:31] <psusi> but wife says it's time for bed now, so night
[06:07] <ccheney> heh just got an icon merge from munchkinguy tonight
[06:07]  * ccheney will have to carefully examine it to make he sure he doesn't end up screwing up the merge :)
[06:22] <kusum> can anyone here expalin me the preseed file
[07:37] <pitti> Good morning
[08:07] <dholbach> good morning
[08:07] <mdke> morning dholbach
[08:08] <dholbach> hey mdke
[08:43] <geser> good morning
[08:44] <geser> pitti: Hi, have you some time to review and sponsor https://code.edge.launchpad.net/~geser/pkg-create-dbgsym/strip_-O_some_more/+merge/22977?
[08:45] <pitti> geser: I got your mail; will look at it ASAP, promised
[08:46] <seb128> urg
[08:46] <seb128> the current beta2 iso partition screen behave weirdly
[08:47] <seb128> it change the device "sda<n>" numbers on the fly
[08:47] <stefanlsd> didrocks: do you know if quickly dialogs are broken? mine in lucid dont seem to work
[08:48] <seb128> ie I delete a partition I don't care about, sda8 and I still get a sda8 in the refreshed list but it's an another one
[08:48] <didrocks> stefanlsd: no, it should work, let me try
[08:48] <seb128> and sda6 I wanted to keep is now showed as sda8
[08:48] <seb128> ev, cjwatson: ^ known issue? what info would be useful in a bug?
[08:49] <didrocks> stefanlsd: (well, it has been renamed to quickly add dialog btw)
[08:50] <didrocks> working here
[08:50] <ev> seb128: news to me.  Can you run ubiquity in debug mode (`ubiquity -d`), reproduce the issue, then run ubuntu-bug ubiquity?
[08:50] <seb128> ev: ok
[08:51] <ev> sounds like it could be a bug in the freeze/thaw code in the partman component
[08:52] <stefanlsd> didrocks: yeah. i picked that up (quickly tutorial incorrect there...) - i create it with quickly add dialog test. I import TestDialog and i get - from sourceswitcher.helpers import get_builder
[08:52] <stefanlsd> ImportError: No module named helpers
[08:54] <geser> pitti: no hurry, I just noticed there is now a second merge proposal to fix the same problem: https://code.edge.launchpad.net/~anders-kaseorg/pkg-create-dbgsym/dh_strip-O-X
[08:59] <tkamppeter> pitti, hi
[08:59] <didrocks> stefanlsd: ok, understood, someone changed the syntax and didn't think to add helpers.py to existing project :(
[09:11] <seb128> ev: bug #557913
[09:12] <seb128> ev: do you need screenshots too or are the logs enough?
[09:12] <ev> they would probably help to understand exactly what's going on
[09:13] <seb128> ok
[09:17] <primes2h> tkamppeter: Hi! Any ideas about this bug 557199?
[09:18] <tkamppeter> primes2h, no, I think I need to contact Tim Waugh about that. I never touched the translation part of s-c-p and I also did not change any standard menu entry.
[09:18] <tkamppeter> pitti, ping
[09:18] <pitti> hello tkamppeter
[09:19] <primes2h> tkamppeter: the big problem is that it affect documentation too, which deadline is coming. we don't know how to handle it into documentation.
[09:19] <primes2h> tkamppeter: thanks a lot.
[09:20] <primes2h> s/coming/ coming soon
[09:22] <pitti> geser: it seems to fix different things
[09:22] <pitti> geser: Anders' fix is for -X, while your's is for -O ?
[09:22] <pitti> or, rather, -X-O
[09:22] <pitti> meh, debhelper really becomes complicated these days
[09:22] <pitti> this should get a test case
[09:23] <tkamppeter> primes2h, I have discovered now, it seems that the I18n (/usr/share/locale) is missing in the package. I will fix this in tomorrow's upload.
[09:23] <pitti> tkamppeter: /usr/share/locale/*.mo is stripped from main packages; they aren't supposed to contain them
[09:23] <pitti> .mo files are shipped in language packs
[09:24] <pitti> geser: but Ander's patch doesn't seem to make sense to me -- -X is for file names, not options
[09:25] <geser> pitti: it's the same issue, http://launchpadlibrarian.net/43380277/barnowl_1.5.1-1_amd64.build shows how it started
[09:27] <pitti> geser: I do understand your's, but still don't understand Anders'
[09:27] <pitti> -O-Xautom4te.cache
[09:27] <geser> pitti: the problem is that my first attempt in 0.39 only "fixed" for boolean flags as it stripped the -O only for the case statement
[09:27] <pitti> with your's, the -O would be stripped, and you'd get a normal -Xfilename
[09:28] <pitti> but with Ander's fix, you'd try to strip an -O from the _argument_ of -X
[09:28] <pitti> but -X-O doesn't make sense at all AFAICS?
[09:28] <geser> $p is unstripped at this place
[09:29] <pitti> geser: oh, right; I read it as "further" strip, i. e. on top of your change; sorry
[09:29] <geser> xopts gets the whole -O-Xautom4te.cache appended (and pkg_create_dbgsym doesn't know what to do with it)
[09:29] <primes2h> tseliot: Hello, any news about this? bug #553954  dpm told me he would sponsor the exception if needed.
[09:29] <geser> pitti: there are two different branches to fix the same problem
[09:30] <tseliot> primes2h: it's on my todo list
[09:30] <seb128> ev: bug updated
[09:30] <geser> Anders' branch fixes it only for -O-X but leaves the other ones still broken, while mine branch should (hopefully) fix it for the other cases too
[09:30] <pitti> geser: merged your's, and running tests now
[09:31] <pitti> geser: if you fancy it, please write a test for it, then we can merge that later on
[09:31] <pitti> to ensure it stays fixed
[09:31] <pitti> geser: thanks!
[09:31] <tkamppeter> pitti, then the .mo files were not forgotten, I was about to add them. Then the bug is in the language packs.
[09:32] <pitti> tkamppeter: they do ship the .mo files
[09:32] <pitti> /usr/share/locale-langpack/de/LC_MESSAGES/system-config-printer.mo
[09:32] <geser> pitti: will do
[09:33] <pitti> tkamppeter: s-c-p is translated just fine here
[09:33] <tkamppeter> pitti, this makes it much more complicated. So the languiage packs need to get updated with every update of the applications.
[09:33] <primes2h> tseliot: thank you. :-)
[09:33] <tkamppeter> pitti, are mman pages also centralized?
[09:33] <pitti> tkamppeter: man pages don't use gettext at runtime
[09:34] <primes2h> pitti: did you checked strings reported in bug?
[09:34] <tkamppeter> pitt, I asked because they were also omitted in s-c-p.
[09:34] <pitti> tkamppeter: ah, right, some strings are missing; they just might not be translated, or the .pot file is missing them, then they are not translatable
[09:35] <primes2h> pitti: both of them, some are missing from .pot and some are translated but are still in english.
[09:35] <tkamppeter> pitti, perhaps the langpacks need to get re-generated with the newest .po and .pot files from s-c-p?
[09:36] <pitti> primes2h: so the latter will just fix itself by translating them and updating the langpacks
[09:36] <primes2h> pitti: this is a regression, in Karmic those missing were present.
[09:36] <pitti> primes2h: did you check whether they are in the .pot/
[09:36] <pitti> ?
[09:36] <primes2h> sorry, I checked .po in launchpad.
[09:37] <primes2h> pitti: comparing karmic and lucid .po files, some strings are missing in lucid
[09:38] <primes2h> pitti: and others are present, translated a long time ago but they are in english
[09:42] <primes2h> pitti: I'm downloading .pot file from launchpad now.
[09:42] <tkamppeter> primes2h, pitti, the strings are indeed missing in the .pot file of the source, how can this happen? The main menu entries were always there.
[09:43] <pitti> tkamppeter: perhaps po/POTFILES.in got broken? Or they aren't marked to be translatable any more?
[09:44] <pitti> tkamppeter: sure enough:
[09:44] <pitti>                        <property name="label">_Connect...</property>
[09:44] <pitti> this is missing translatable="yes"
[09:44] <pitti> i. e. it needs to be marked as translatable in glade
[09:46] <pitti> followed up in the bug
[09:46] <tkamppeter> pitti, perhaps Tim changed the Glade version making the translatable="yes" getting lost or the default changed so that from now on it is needed.
[09:46] <primes2h> tkamppeter: a commit from upstream probably broke that
[09:46] <tkamppeter> Is thgere a quick way to fix it?
[09:47] <pitti> tkamppeter: add the flag manually with a patch, or open it in glade and tick the "translatable" check boxes again
[09:47] <tkamppeter> pitti, and do I have translations for all languages then? Probably they are also missing?
[09:48] <pitti> tkamppeter: I guess they were dropped from the language packs when they fell out of the .pot
[09:48] <pitti> tkamppeter: but once they are translat_able_, LP will recover the old translations, and the next langpack update should have them again
[09:49] <tkamppeter> pitti, only problem is that there are hundreds of strings in s-c-p and so setting all these translatable flags again can take me several hours.
[09:49] <pitti> tkamppeter: it's just three or four in the menus, though?
[09:50] <tkamppeter> primes2h, how many strings are really missing? Is the list in the bug report really complete?
[09:51] <tkamppeter> pitti, primes2h: The bug report looks like that lots of strings are missing.
[09:51] <pitti> tkamppeter: when you start the app, it's not that many; it's by and large in German
[09:54] <primes2h> tkamppeter: in fact, it seems that there aren't a lot missing. There are a lot translated but still in english.
[09:56] <primes2h> instead
[09:58] <primes2h> tkamppeter: Those translated but still in english are explicitly mentioned in bug report, all the other are missing (like  _Connect...
[09:58] <primes2h> )
[09:59] <tkamppeter> I have added comments to the bug to contact Tim Waugh.
[10:00] <primes2h> tkamppeter: I didn't mention all translated but still in english (seems to be a lot)
[10:00] <primes2h> tkamppeter: but those missing should be all reported.
[10:00] <primes2h> tkamppeter: thanks
[10:03] <didrocks> stefanlsd: ok, fixed your issue. You can grab latest trunk, "PATH=/path/to/quickly/trunk/bin:$PATH quickly upgrade" in your project
[10:10] <stefanlsd> didrocks: thanks! will give it a try. dont see the trunk update yet
[10:13] <didrocks> stefanlsd: should be better now. Branch diverged and I switched my ws. Rebased and pushed :)
[10:16] <stefanlsd> didrocks: branching. thanks for the quick fix :)
[10:17] <didrocks> stefanlsd: you're welcome :)
[10:20] <tkamppeter> pitti, how do I add a locale to a US-only installed system so that I can test translations? Only "sudo apt-get install language-pack-de" does not work.
[10:26] <pitti> tkamppeter: you need language-pack-gnome-de for GNOME packages
[10:28] <tkamppeter> pitti, still says "Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale.".
[10:28] <pitti> tkamppeter: installing the language pack should have generated the de_DE.UTF-8 locale; didn't it?
[10:28] <pitti> tkamppeter: you can do it manually with "sudo locale-gen de_DE.UTF-8", but if it's not there, I suspect that the langpack is missing, too
[10:29] <tkamppeter> pitti, now it weorks, LANG=de_DE.UTF-8 and not only LANG=de, awkward.
[10:29] <cjwatson> LANG=de has never been valid
[10:29] <cjwatson> if it worked, it was because you were lucky
[10:29] <pitti> tkamppeter: it's a locale, not a language
[10:32] <seb128> cjwatson, ev: let me know if you need extra details on bug #557913, I keep the box in the current disk state for now
[10:38] <cjwatson> seb128: I've commented; there is no need to keep the box in its current state, it's not a regression
[10:39] <cjwatson> if anything, it's a confusing property of how partitioning works really ...
[10:39] <seb128> cjwatson, ok thanks
[10:42] <seb128> cjwatson, I guess it's not so much an issue nowadays with uuid used rather than device entries to do mounting etc
[10:42] <seb128> cjwatson, I was concerned the install I wanted to keep would stop booting because the partition ordering is changing
[10:44] <cjwatson> seb128: right, but there's nothing that can be done about that, as I say partition numbers are not a persistent thing stored in the partition table - the fourth logical partition is going to be 8 regardless of whether it used to be 9
[10:44] <cjwatson> I didn't close it because I wondered whether there might be a less surprising way to present this in the UI
[10:45] <cjwatson> warning when you delete a partition that would cause partitions to be renumbered?  I can see that being pretty annoying in some cases :-/
[10:45] <seb128> I'm trying to think about that, I guess out of not showing the number in a such noticable way I don't see one
[10:45] <cjwatson> I wonder what other partitioners do
[10:45] <cjwatson> well, but as you say the renumbering could have real effects
[10:45] <seb128> what confused me is that I noted what "sda<n>" I need to keep before starting the installation
[10:46] <seb128> and I saw it listed as swap after doing changes
[10:46] <cjwatson> right
[10:46] <cjwatson> I understand that it's a problem, certainly, just not sure what to do about it
[10:46] <seb128> I'm not sure either
[10:47] <seb128> out of displaying a warning somewhere as you said to indicate that the changes leaded to partition numbering changes...
[10:48] <seb128> but I'm not sure when and where
[10:48] <seb128> and if it would annoy most users rather than help
[10:53] <seb128> cjwatson, I commented on the bug, feel free to set it as wishlist or close it if you think that's it in the category of things which will not likely change, no point to keep buglist noise when not needed
[10:55] <mdz> james_w, the sub-pages on https://wiki.ubuntu.com/DistributedDevelopment/Documentation seem to be very short, and usually someone would need to refer to more than one of them in order to complete a task. might it make sense to use includes to put them together on the page?
[10:56] <james_w> mdz: I don't see why we can't provide an all-in-one page, no
[10:56] <mdz> james_w, at least for the basic "get the source, make some changes, submit for review" workflow
[10:56] <mdz> (currently 3 pages)
[10:56] <james_w> yeah
[10:59] <slangasek> ogra: did you forget to bzr push your debian-installer upload?
[10:59] <ogra> slangasek, i dont think so
[10:59]  * ogra checks
[11:00] <ogra> https://code.edge.launchpad.net/~ubuntu-core-dev/debian-installer/ubuntu seems to have it
[11:00] <ogra> oh, wait
[11:00] <slangasek> ogra: UNRELEASED
[11:01] <ogra> sorry i dont have that branch in autocommit to prevent accidents ...
[11:01] <ogra> (which i apprently produced now nontheless :P)
[11:01] <ogra> pushed
[11:02] <slangasek> ogra: thanks :)
[11:08] <mdz> Keybuk, had you not pushed that revision to Launchpad until just now? I swear I looked and didn't see it, and it's not in the revision history for my branch
[11:08] <Keybuk> mdz: I pushed it this morning
[11:08] <Keybuk> must have forgotten last night
[11:09] <mdz> we must have raced
[11:09] <Keybuk> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/mountall/lucid/revision/298 FWIW
[11:09] <Keybuk> my patch is quite a bit different from yours ;)
[11:09] <mdz> Keybuk, but still a one-liner ;-)
[11:10] <mdz> ah, you fixed -dev too
[11:31] <slangasek> Keybuk: do you have thoughts on how plymouth is going to select a different image based on fb bitdepth?  Is this information exposed somewhere the script plugin can already grab it?
[11:33] <Keybuk> slangasek: I don't think there's an existing function, but it should probably go alongside GetHeight etc.
[11:34] <slangasek> Keybuk: ok. were you planning to work on the implementation?
[11:35] <Keybuk> it wasn't a difficult implementation
[11:35] <Keybuk> I'm not 100% sure it's not already there in fact ;)
[11:36] <slangasek> I don't see it in script-lib-sprite.c in the package
[11:37] <slangasek> and I didn't suggest it would be difficult, I'm asking if you're doing it or if I need to open a bug myself to keep it on the radar
[11:37] <Keybuk> open a bug
[11:37] <slangasek> (since the flavors will all need theme updates as well once this facility is there)
[11:37] <slangasek> ok
[11:37] <Keybuk> at this point of the release process, air traffic control is important
[11:38] <Keybuk> obviously this depends on having some artwork
[11:38] <slangasek> implementing the facility doesn't
[11:40] <Keybuk> but LEAN development says I should not do that early ;)
[11:42] <persia> But surely it calls to *document* it early, so that the theme providers can prepare, and since the best possible documentation is code ... :)
[11:44] <Keybuk> I'm actually kinda saddened that we've ended up with a myriad of different *-logo themes!
[11:44] <Keybuk> I can't work out why each one needs its own .script
[11:44] <Keybuk> surely they could just Depend: ubuntu-logo and put a different ImageDir in their .theme file
[11:44] <Keybuk> and refer to the same .script
[11:45] <slangasek> Keybuk: background colors can't be set as variables in the theme file
[11:45] <slangasek> if the script plugin allowed loading arbitrary vars from the theme, then it'd be fine
[11:45] <persia> Also, I suspect the majority copied the ubuntu theme verbatim, rather than looking for ways to refactor for shared scripts.
[11:46] <slangasek> perhaps, but I looked into this exact question because I was adjusting ubuntu-logo and noticed that flavors were gonna have to merge
[11:46] <slangasek> and this made me sad too
[11:47] <persia> With the current structure, aren't all core-devs implicitly also flavour-devs, so that if someone had time, everything could be refactored sanely?
[11:48] <slangasek> if someone has time to refactor the script plugin to support loading arbitrary vars from .theme, yes
[11:48] <slangasek> s/refactor/enhance/
[11:48] <persia> Time is always the painful bit.
[11:50] <Keybuk> slangasek: can't they?
[11:50] <Keybuk> slangasek: sounds like that'd be a simple patch ;-)
[11:51] <dholbach> mvo, geser: will ubuntu-dev-tools get another upload?
[11:51] <dholbach> with the fixes you put in there? :)
[11:51] <slangasek> Keybuk: well, feel free... :)
[11:51] <Keybuk> slangasek: got any spare round tuits?
[11:52] <slangasek> not me; I haven't grokked the script plugin yet, I'd have to sit down with it for a while to avoid making a mess
[11:52] <geser> dholbach: yes
[11:52] <dholbach> geser: awesome
[11:53] <Keybuk> slangasek: bribe brejc8
[11:53] <Keybuk> "hey, wouldn't it be REALLY SWELL if script did this" on #plymouth
[11:53] <slangasek> ok :)
[11:59] <Keybuk> cjwatson: http://thread.gmane.org/gmane.linux.kernel/969355
[12:00] <cjwatson> inspired
[12:02] <mvo> ArneGoetje: it appears that the package description of thunderbird-locale-nb-no is not valid utf8, could you please have a look?
[12:08] <geser> dholbach, mvo: ubuntu-dev-tools 0.97 uploaded.
[12:09] <dholbach> geser: THANKS
[12:09] <mvo> geser: you rock!
[12:09] <dholbach> indeed
[12:20] <ogra> bah, plymouth splash has stripes on OMAP
[12:20] <TrueTom> sudo echo 0x1f > /sys/module/acpi/parameters/debug_layer
[12:20] <TrueTom> bash: /sys/module/acpi/parameters/debug_layer: Permission denied
[12:20] <TrueTom> ?
[12:20] <ogra> see the RootSudo wikipage
[12:20] <ogra> (and please ask for support in #ubuntu, this isnt a support channel)
[12:22] <TrueTom> ogra: thanks
[12:34] <slangasek> pitti: wrt bug #553745, can you tell me anything about how to reproduce it?  do you visibly see plymouth crash when it happens, does it happen on startup or shutdown, does it always happen or only when certain plymouth messages are displayed, etc?
[12:40] <pitti> slangasek: hm, yesterday it consistently crashed at startup (i. e. I didn't see plymouth at all; just text cursor, and then immediately X/gdm)
[12:41] <pitti> slangasek: today startup seems to work as well; shutdown has always worked so far, I see plymouth
[12:41] <slangasek> pitti: hmm, ok
[12:41] <pitti> slangasek: I only saw it the very first time yesterday when I reinstalled UNE on the mini 10; before that I just upgraded
[12:42] <pitti> slangasek: hm, now it happens again; the difference is that I plugged in the AC
[12:42] <pitti> it might speed up the boot just enough to make a difference in a race condition..
[12:43] <slangasek> yes
[12:43] <slangasek> now, not seeing plymouth may be bug #540801
[12:43] <slangasek> but maybe that's a precondition of this bug
[12:43] <pitti> (in my bootcharts I noticed that booting on battery is quite a bit slower, presumably due to CPU scaling down?)
[12:44] <slangasek> I don't know what would scale the CPU down at that point
[12:44] <pitti> slangasek: I can remove the .crash file and see if I get it again
[12:44] <pitti> I just wondered yesterday why plymouth was gone (it has worked fine for weeks on the mini), but with the crash it's quite obvious why I don't see it
[12:45] <slangasek> not obvious to me
[12:45] <pitti> slangasek: well, plymouthd segfault -> no plymouth on screen?
[12:45] <slangasek> why would plymouthd segfault that early? :)
[12:45] <slangasek> it's not a 100% reproducible crash
[12:47] <pitti> hm, indeed; I didn't see plymouth now, but no .crash file
[12:47] <pitti> perhaps apport was started too late, or it didn't crash
[12:47] <pitti> but anyway, I booted 6 times in a row and never saw plymouth
[12:47] <pitti> (on startup)
[12:48]  * pitti -> late lunch
[12:50] <dholbach> Packaging Training session in #ubuntu-classroom with geser in 10 mins: Q&A about the Developer Membership Board
[12:50] <seb128> slangasek, pitti: I get similar plymouth crashes on my mini too
[13:37] <seb128> hum
[13:37] <seb128> does anybody know how far we are from having another langpack installed on the CD?
[13:37] <seb128> the directfb upstream changelog sneaked back in with the dh7 switch
[13:38] <seb128> which is over one meg
[13:38] <seb128> the package also has both gziped and ungziped versions of changelogs
[13:38] <seb128> there is some space win to do there, but not sure if that's worth chassing that now
[13:39] <seb128> ie if we will not use the space for anything else in lucid...
[13:41] <cjwatson> don't know how far we are, but 1MB sounds worth saving
[13:42] <seb128> seems we have also several times the openoffice changelog which is 1meg gzip-ed
[13:42] <seb128> ie openoffice.org-style-galaxy openoffice.org-l10n-common openoffice.org-core
[13:42] <seb128> they have the same upstream changelog
[13:42] <seb128> cjwatson, k, I will fix the directfb one
[13:42] <seb128> I don't fancy looking to openoffice though :p
[13:43] <seb128> ccheney, ^ do you know if that would easy to change?
[13:44] <seb128> hum
[13:44] <seb128> I'm wondering if there is a debhelper bug there
[13:44] <seb128> some packages have a ChangeLog.gz and changelog.gz identical installed
[13:44] <seb128> but upstream has only ChangeLog.gz
[13:46] <lifeless> I bet there is a .docs file lsiting ChangeLog
[13:46] <lifeless> and debhelper is grabbing ChangeLog as changelog as a built in default
[13:47] <cjwatson> agree
[13:47] <cjwatson> debhelper >= 7.0.1 has defaults for upstream changelog
[13:47] <cjwatson> so it's just that some package failed to notice the change
[13:48] <cjwatson> (this isn't done in compat=6 and below)
[13:48] <seb128> hum k
[13:48] <seb128> "rules:	dh_installchangelogs -plibdirectfb-dev ChangeLog"
[13:49] <seb128> directfb has that for example
[13:49] <cjwatson> right, just remove ChangeLog probably
[13:50] <seb128> well we add that as the "move the upstream changelog to the libdev"
[13:50] <seb128> but debian changed to dh7 meanwhile so we have
[13:50] <seb128> dh_installchangelogs
[13:50] <seb128> dh_installchangelogs -Nlibdirectfb-dev
[13:50] <seb128> dh_installchangelogs -plibdirectfb-dev ChangeLog
[13:51] <seb128> I'm not even sure what the intend was with the -N
[13:51] <seb128> shouldn't we just -XChangeLog in -plibdirectfb-...?
[13:54] <cjwatson> TBH, you could now just say dh_installchangelogs and leave it at that, if you build-depend on at least debhelper (>= 7.0.1)
[13:54] <cjwatson> or at least I'm pretty sure
[13:55] <seb128> well it would install the upstream changelog in the lib then?
[13:55] <cjwatson> oh, right
[13:55] <cjwatson> it does it for the "main package", whatever's first in debian/control
[13:55] <cjwatson> but that's overridable
[13:55] <cjwatson> dh_installchangelogs --mainpackage=libdirectfb-dev
[13:55] <cjwatson> try that?
[13:56] <seb128> will do
[13:56] <seb128> I've to figure how dh7 do overwritting first :p
[13:56] <seb128> right now it just add extra calls
[13:56] <seb128> so we get the dh7 dh_installchangelogs + the ones we added
[13:56] <cjwatson> overrides in dh7 are only relevant if you're using dh(1)
[13:56] <cjwatson> is directfb doing that?
[13:57] <seb128>         dh --with quilt $@
[13:57] <seb128> it uses
[13:57] <cjwatson> hm, the import is out of date
[13:57] <seb128> I guess I want to add some
[13:57] <cjwatson> then:
[13:57] <cjwatson> override_dh_installchangelogs:
[13:57] <seb128> override_dh_installchangelogs:
[13:57] <cjwatson>         dh_installchangelogs --mainpackage=libdirectfb-dev
[13:57] <seb128> right, thanks
[13:58] <seb128> trying that now
[13:58] <seb128> next I look at why gtk2 has duplicates changelos too
[13:58] <seb128> it uses debhelper 5
[13:58] <kirkland> cjwatson: hi there ... question about the eucalyptus-* tasks in the ubuntu-lucid seeds
[13:58] <cjwatson> kirkland: yu
[13:58] <cjwatson> p
[13:59] <kirkland> cjwatson: ttx and I were surprised to notice that they're not a proper superset of ubuntu-server
[13:59] <cjwatson> is that important in any way?
[13:59] <kirkland> cjwatson: ttx: ie, stuff like vim and screen aren't included
[13:59] <kirkland> cjwatson: consistency
[14:00] <cjwatson> I would have thought that the appropriate response would be to install the server task as well
[14:00] <ttx> cjwatson: ah, interesting point.
[14:00] <ttx> cjwatson: but the UEC installer doesn't give you that option
[14:00] <lamont> I'd just like to shoot debian-installer / hardy-proposed.  Trying to remember what the fix was so that it would actually build on sparc
[14:00] <cjwatson> I don't think task supersets are really the right way to do this; they introduce quite a bit of clutter into Packages and are less visible
[14:00] <cjwatson> ttx: it would be trivial to make eucalyptus-udeb just always include the server task, if that's what you wanted
[14:01] <ttx> cjwatson: I'm slightly worried about the timing, but apart from landscape-common, I can't see anything potentially harmful in there
[14:02] <cjwatson> http://paste.ubuntu.com/411040/ or similar
[14:03] <ttx> cjwatson: with your release team hat on, do you see potential trouble ?
[14:03] <ttx> I'm ok with having those packages in... just wished we would have done that pre-beta :)
[14:05] <kirkland> ttx: I agree -- I'd like to see an UEC install have Ubuntu Server + Euca-stuff
[14:05] <ttx> cjwatson: that would add patch, screen, landscape-common, vim, apport, w3m and ubuntu-serverguide
[14:05] <cjwatson> ttx: it seems OK to me; didn't we go to some effort to ensure that landscape-common was harmless by default?
[14:06] <ttx> cjwatson: that's the key idea, yes.
[14:08] <ttx> kirkland: ok, so please back out the addition of "screen" in the seeds, and locally test the change cjwatson pastebinned
[14:08] <ttx> ..and if successful, upload a euca with that as soon as we unfreeze
[14:12] <kirkland> ttx: will test
[14:24] <slangasek> tseliot: have you looked into bug #552782 yet?  if not, I'm going to have a look
[14:24] <slangasek> (should be fairly easy to fix, though I'm pulling the package history to make sure we don't overlook any cases)
[14:26] <tseliot> slangasek: I'm fixing a bunch of fglrx bugs today but I haven't worked on that yet. Help is always welcome ;)
[14:26] <slangasek> ok
[14:27] <slangasek> tseliot: is there a bzr branch for the package, do you work off lp:ubuntu/fglrx-installer directly, ...?  No Vcs-* fields in debian/control
[14:28] <tseliot> slangasek: I work on this git master branch: http://www.phorogit.com/index.php?p=fglrx-packaging.git
[14:29] <tseliot> which is also what upstream use so that my changes end up in their installer
[14:29] <slangasek> tseliot: ah
[14:30] <slangasek> tseliot: well, the package bzr is taking enough time to download, so for right now you'll just be getting patches against that. :)
[14:31] <tseliot> slangasek: sounds good :-)
[14:32] <tseliot> slangasek: in git we only have packaging scripts, so installers or blobs of any kind
[14:32] <tseliot> s/so/no/
[14:32]  * slangasek nods
[14:32] <tseliot> so it might actually be faster to get that. Either way it's fine
[14:33] <slangasek> faster to get it, but certain to take me longer to inspect the history <shrug> :)
[14:34] <u-foka> Hy! After todays upgrade and reboot, I noticed that my system freezes with kernel panic imediately after I start empaty :( I can check my mail, ot surf the web without problems, but when I start empathy it freezes... but after I start with the older (18) kernel the problem disappears...
[14:35] <u-foka> I will look around launchpad if that bug is already reported or not, but I wanted to inform you quickly because it seems to be hard regression
[14:39] <u-foka> well it looks like Bug #495577 but that reported on karmic four months ago...
[14:39] <u-foka> strange
[14:39] <u-foka> anyone?
[14:41] <slangasek> u-foka: "kernel panic" is far too generic for us to comment meaningfully; you should file a bug report showing /where/ the kernel panics
[14:43] <u-foka> slangasek, but how to track that down, I'm locked inside X with the blinking num+capslock leds... If I was enough fast, I can go to a console before the kernel freezes and can read the end of the message
[14:43] <u-foka> there is any way to get the full error, or I have to get a higher res terminal and take a photo of the error? 8-)
[14:43] <slangasek> u-foka: switch to console, and launch empathy with 'DISPLAY=:0.0 empathy'?
[14:44] <kusum> Could somebody explain me the lines in preseed.cfg file in wubi , please
[14:44] <slangasek> u-foka: but yes, if the panic scrolls off your screen, you either need a higher-res console setting or to use a serial console to capture it
[14:44] <u-foka> slangasek, yeah, and then how to save the error?
[14:44] <slangasek> u-foka: a photo is a good start
[14:44] <u-foka> okay
[14:44] <u-foka> I'l be back in some minutes
[14:44] <slangasek> or transcribing by hand - whichever is easier for you...
[14:45] <ArneGoetje> mvo: confirmed
[14:45] <mvo> ArneGoetje: I fixed it in the meantime
[14:45] <mvo> ArneGoetje: no worries, thanks for verifiying
[14:45] <ArneGoetje> mvo: ok
[14:55] <slangasek> tseliot: patch posted to the bug
[14:55] <nigelb> crimsun, I know its smack in the middle of a working week, but if you could spare one hour, would be great :)
[14:55] <hdon> hi all. i have a really weird situation, not really a problem right now, but i don't understand how this is happening... http://pastebin.mozilla.org/713743
[14:56] <slangasek> tseliot: what else are you working on for fglrx today?  Can we get that particular fix into the queue today, so it's available for people upgrading immediately post-beta?
[14:56] <hdon> so it appears that SOCK_STREAM is surviving gcc -E without being substituted
[14:56] <hdon> but if i compile (no -E) then it gets substituted, apparently
[14:59] <slangasek> hdon: because SOCK_STREAM is an enum, not a #define; but I don't see how this is related to Ubuntu development?
[14:59] <hdon> oh!
[14:59] <hdon> thanks
[15:00]  * hdon sleazes his way out the door
[15:01] <cjwatson> kusum: please don't do this thing of asking the same question in multiple channels.  it's quite annoying for those of us who follow those multiple channels
[15:05] <tseliot> slangasek: I have fixed 538071, 556653 and I'm almost done with 552903
[15:06] <slangasek> tseliot: ok, cool
[15:07] <u-foka> hy again! slangasek! Sorry, I found that not any update, but vmware-workstation, that I installed today, and it's vmnet module caused the problem..
[15:07] <u-foka> it's still strange why only empathy was affected
[15:07] <u-foka> but it seems it affected only the latest kernel because the module was only compiled for that
[15:08] <slangasek> heh
[15:08] <slangasek> well, now you know where to file the bug, anyway :)
[15:08] <u-foka> yeah
[15:08] <u-foka> thanks :)
[15:13]  * apachelogger enters crying the channel
[15:13] <apachelogger> dholbach: me@osiris:~/src/bzr$ get-branches kubuntu-members
[15:13] <apachelogger> The team 'kubuntu-members' does not have any branches on Launchpad.
[15:13] <dholbach> apachelogger: I didn't touch the script in years
[15:13] <apachelogger> omg :(
[15:14] <apachelogger> jpds: ^
[15:14] <dholbach> apachelogger: I haven't had the need to use it for ages
[15:15] <apachelogger> dholbach: I figured it could be useful for kubuntu since we have a billion branches associated with kubuntu-members
[15:16] <dholbach> apachelogger: I usually just check out whatever I'm going to need next :)
[15:16] <soren> apachelogger: I have a patch that fixes it.
[15:16] <soren> apachelogger: ...almost.
[15:16] <soren> Heh.
[15:16] <soren> Hang on :)
[15:16] <apachelogger> ^^
[15:17] <dholbach> apachelogger: last rev I made changes to it: 18.3.5
[15:17] <dholbach> apachelogger: since then: rainct, jpds :)
[15:17] <apachelogger> k :)
[15:18] <slangasek> seb128: can you tell me if bug #539951 is a regression?
[15:19] <seb128> slangasek, seems bug #486929
[15:20] <seb128> slangasek, not new no
[15:20] <asac> doko_: is icedtea6-plugin supposed to work?
[15:21] <slangasek> seb128: thanks, duping
[15:21] <seb128> slangasek, yw ;-)
[15:21] <doko_> asac: 556549
[15:24] <asac> doko_: hmm. thats the reason why example applets dont work?
[15:24] <asac> even if they dont touch security stuff?
[15:30] <doko_> asac: the example applet should work, and it does work for me
[15:31] <micahg> doko_: which applet are you using?
[15:33] <ccheney> seb128: i'll take a look and see, we have code that is supposed to keep the duplication from happening but it seems to be broken for openoffice.org-style-galaxy, shouldn't be too hard to fix
[15:34] <ccheney> seb128: and actually for openoffice.org-style-galaxy i'm not sure why it is even on the cd since the only rdepends is openoffice.org which is not supposed to be on the cd
[15:34] <doko_> micahg: http://www.java.com/en/download/help/testvm.xml
[15:35] <ccheney> seb128: if openoffice.org-style-galaxy really is on the cd that is a bug somewhere with the cds most likely and would free space on its own
[15:36] <seb128> ccheney, no sure I was typing on an another box than the one I was installing on
[15:36] <ccheney> seb128: ok
[15:36] <seb128> ccheney, it's -human on the CD but it has the changelog too
[15:37] <ccheney> seb128: and for -human the dir is a symlink
[15:38] <ccheney> pointing to openoffice.org-common dir
[15:38] <seb128> right
[15:38] <seb128> so it's -common -core - l10n-common
[15:38] <slangasek> ccheney: other than the fact that we keep ending up with openoffice.org-style-galaxy Provides: openoffice.org-style-default?
[15:38] <seb128> those are real dirs and have the same 1meg changelog
[15:39] <micahg> doko_: weird, wfm now too :)
[15:39] <ccheney> slangasek: yea galaxy is bugged and if it is hitting the cd i need to fix that if its a bug in OOo packaging
[15:39] <seb128> ccheney, uno-libs3 seems to have the same one too
[15:40] <slangasek> ccheney: yes, this is a repeat of a previous packaging bug - which style was supposed to be the default?
[15:41] <slangasek> ccheney: anyway, -common depends on -style-default | -style, and -style-default is the obviously-correct virtual package name; so it's just that it's being provided by the wrong package
[15:42] <slangasek> ccheney: however, I don't actually see -style-galaxy being pulled into the CDs; this is only going to be an issue when installing OOo from the network (but it *will* be an issue there)
[15:45] <ccheney> slangasek: all of the style packages provide openoffice.org-style
[15:45] <slangasek> ccheney: it's not about -style, it's about -style-default
[15:45] <ccheney> slangasek: and depending on if you install openoffice.org-kde or openoffice.org-gnome it installs a openoffice.org-style-* package already
[15:46] <ccheney> slangasek: so is this a apt bug?
[15:46] <slangasek> ccheney: I don't see a description of the actual problem in my immediate scrollback
[15:46] <slangasek> ccheney: other than the comments about the CDs, and it's *not* on the CDs
[15:47] <ccheney> slangasek: ok
[15:49] <ccheney> seb128: looks like i might need to change all the arch packages to link to uno-libs3 doc dir (due to dependency chain) which would reduce the duplicates for that
[15:56] <soren> apachelogger: See ubuntu-dev-tools trunk for a fixed get-branches script.
[16:06] <apachelogger> soren: awesome, thanks \o/
[16:08] <sebner> apachelogger: huhu :)
[16:09] <apachelogger> sebner: ahoy
[16:11] <sebner> huhu sistpoty|work :)
[16:11] <sistpoty|work> hi sebner
[16:22] <kirkland> ttx: i tested cjwatson's pastebin'd fix, rolled into a udeb, retrieved and installed early in a UEC install ... works well
[16:22] <kirkland> ttx: cjwatson: I see no negative effects at this point
[16:23] <kirkland> ttx: cjwatson: I suggest we commit this as soon as the freeze lifts, and start testing dailies again
[16:23] <ttx> kirkland: ack
[16:23] <kirkland> ttx: i'm going to upload it now, to get it into the queue
[16:47] <maco> cjwatson: ping. is there a reason why udev should "breaks" not "conflicts" with casper? had a user in #ubuntu installing updates yesterday whose dpkg had wedged over it.
[16:49] <slangasek> maco: because Conflicts are when there are overlapping files between the two packages - how did that wedge dpkg?
[16:49]  * persia suspects something like policy 7.2 recommending Breaks for most uses that were conflicts pre-Breaks.
[16:50] <maco> slangasek: its set to breaks currently. user was getting http://ubuntu.pastebin.com/fR5Pn1Ch when trying to update. had to "dpkg -P --force-depends casper" as the only way to get dpkg into a sane state
[16:51] <maco> slangasek: crimsun said breaks goes into effect during the dpkg part, so if it had been breaks instead, apt wouldve caught it and not let it get so far and get stuck.  by stuck i mean it tells you "sudo dpkg --configure -a" and so you try that and then it just does the same thing again
[16:51] <maco> slangasek: er... "if it had conflicts instead"
[16:52] <slangasek> maco: casper 1.57 is the version from dapper - I think the user is Doing It Wrong
[16:52] <maco> slangasek: oh O_O
[16:52] <maco> how the heck did they.....
[16:52] <slangasek> maco: the problem there is probably that they used an apt that doesn't understand Breaks
[16:52] <slangasek> which was first added in edgy
[16:53] <maco> udev version matches karmic
[16:53] <maco> well karmic-updates
[16:53] <maco> ok yeah ill agree with Doin It Wrong
[16:53] <cjwatson> yeah, no sympathy :)
[16:54] <maco> i suspect there is some howto for remastersys on the interwebs that instead of saying "use apt" hands out old old old dapper casper packages
[16:55] <slangasek> hand-installing the wrong casper package would also cause the problem, sure
[16:58] <maco> i just memoserv'd the person to tell them that
[17:01] <ScottK> maco: Better a blog posting that names names.
[17:11] <LaserJock> ScottK: public "peer" review? :-)
[17:12] <ScottK> Exactly.
[17:23] <tseliot> slangasek: I have fixed all of the bugs that I mentioned but the one you volunteered to have a look at. What shall I do? Upload?
[17:23] <slangasek> tseliot: you should take my patch from that bug report, apply it, and then upload :)
[17:23] <slangasek> tseliot: (in a manner consistent with the FeatureFreeze, that is)
[17:24] <tseliot> slangasek: there's no patch from you there
[17:25] <slangasek> tseliot: https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/552782/comments/6 ?
[17:26] <tseliot> slangasek: oh, sorry I was looking at bug 554298 (which is a duplicate)
[17:29] <tseliot> slangasek: we haven't added any diversions in the package in lucid, therefore I think I will just replace $PKGNAME with xorg-driver-fglrx in all of the lines in the preinst script instead of affecting only the line that you modified
[17:32] <slangasek> tseliot: ok; I was being conservative since the bug people were reporting was about the very last diversion in the list which means the others weren't causing failures, but if none of these were ever in the fglrx package, I agree that's more appropriate
[17:32]  * tseliot nods
[17:32] <tseliot> slangasek: thanks a lot for spotting the problem
[17:32] <slangasek> n/p
[17:37] <kees> pitti: does gwibber zero it's passwords when it's done with them?
[17:38] <pitti> kees: Nafai and I just finished a commit to mlock() them
[17:38] <pitti> kees: but in Python you can't zero a string, they are immutable :/
[17:40]  * kees wonders if the mlock ulimit is per-process or per-user
[17:41] <pitti> kees: per session, I thought?
[17:41] <pitti> kees: but anyway, a handful of passwords shouldn't get anywhere near the shm limit?
[17:42] <tkamppeter> pitti, I have a problem with system-config-printer: Back in February when I wanted to take a 1.1.x GIT snapshot I have accidentally taken a 1.2.x GIT snapshot, but assigned 1.1.x version numbers to the package, not knowing that I am using an unstable test release.
[17:44] <kees> pitti: it shouldn't but it should gracefully not die if mlock fails.
[17:44] <tkamppeter> pitti, what should I do, advance to 1.2.0+HEAD, as this is the stable release with first bug fixes? Especially this instable release caused bug #555213.
[17:44] <pitti> kees: it doesn't currently
[17:44] <pitti> tkamppeter: depends on which direction is safer and less intrusive at this point
[17:45] <pitti> tkamppeter: if it's just a couple of bug fixes towards 1.2.0 final, I'd do that one
[17:45] <pitti> tkamppeter: if it was an early snapshot with not too many changes from 1.1, go bacak
[17:45] <pitti> kees: it's using ctypes, so it won't except out; it just returns with -1
[17:47] <davidm>  /msg akgraner how much of a disaster is it if I can't make SELF until Saturday morning? Was reminded by Debra she wants to go to Phoenix AZ from June 4th - June 12th?
[17:50] <tkamppeter> pitti, thanks, I have asked Tim now.
[17:53] <tseliot> slangasek: ok, committed to git and uploaded to lucid. Thanks again for your help
[18:12] <nemo> huh
[18:12] <nemo> W:Failed to fetch http://www.ksplice.com/apt/dists/lucid/ksplice/binary-amd64/Packages.gz  404  Not Found
[18:12] <nemo> , W:Failed to fetch http://www.ksplice.com/apt/dists/lucid/ksplice/source/Sources.gz  404  Not Found
[18:12] <nemo> , E:Some index files failed to download, they have been ignored, or old ones used instead.
[18:12] <nemo> that's a bit odd
[18:12] <nemo> I mean, I guess I can remove ksplice, but isn't typical for an upgrade to abort just due to missing packages
[18:13] <cjwatson> that's not missing packages, it's missing package indexes, which is a different matter
[18:13] <cjwatson> it doesn't abort either
[18:13] <cjwatson> it's an error, but you can proceed with upgrades of packages not in those package indexes
[18:14] <nemo> it didn't give me an option to procede
[18:14] <nemo> it simply exited
[18:14] <nemo> so I assume I have to manually remote ksplice
[18:14] <cjwatson> "it"?  I assume you're talking about some frontend.
[18:14] <nemo> cjwatson: upgrade-manager
[18:14] <nemo> er
[18:14] <nemo> update-manager
[18:14] <nemo> the dist upgrade tool that is
[18:15] <cjwatson> that's an error from 'apt-get update'.  Perhaps update-manager should tolerate it better somehow, I'm not sure.  Frontends that give you more control will let you proceed
[18:15] <cjwatson> I can understand why it aborts though.  Entire missing repositories can have fairly significant effects on the correctness of an upgrade.
[18:28] <pitti> cjwatson: would you have some time to accept the postgresql-* SRUs in unapproved? (bug 557408) or shall I accept them myself?
[18:28] <pitti> cjwatson: nevermind if you are busy with release tasks, it's not that urgent
[18:29] <cjwatson> I'm not
[18:35] <nemo> cjwatson: well. no big deal, wasn't like ksplice was critical. was just cool to play with
[18:53] <MacSlow> ev, hey there
[18:53] <ev> hiya
[18:53] <MacSlow> mvo_, hey there
[18:54] <MacSlow> ev, mvo_: I was wondering if anyone of you could tell me how to get a proper screenshot into the info-page of notify-osd inside software-center. Thanks in advance!
[18:54] <cjwatson> pitti: done
[20:26] <philsf> apport-collect is crashing on me http://paste.ubuntu.com/411195/ is this the right channel to ask about this?
[20:43] <jdong> what would be the cause of dbus-monitor --system revealing spammy events that look like signal sender=org.freedesktop.DBus -> dest=(null destination) serial=913 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
[20:44] <jdong> (several per second, 30% of CPU usage in system constantly)
[20:45] <chrisccoulson> jdong, an application constantly restarting/terminating probably
[20:47] <ScottK> slangasek: Still not having a great Plymouth transition on KDE: http://people.ubuntu.com/~apachelogger/screencasts/plymouth-uglyness.ogv any suggestions?
[20:49] <jdong> chrisccoulson: ah. Seems like pulseaudio's PID keeps climbing by hundreds
[20:49] <chrisccoulson> jdong, that will be it then ;)
[20:49] <jdong> fun fun fun
[20:50] <jdong> any hints on debugging that?
[20:50] <chrisccoulson> heh
[20:50] <chrisccoulson> i'm probably not the best person to ask about pulseaudio
[20:50] <chrisccoulson> but crimsun might be able to help ;)
[20:51] <jdong> indicator-sound-service seems to be using a couple percent of CPU constantly
[20:52] <slangasek> ScottK: hold that thought
[20:52] <ScottK> OK.  Holding.
[20:53] <nemo> anyone else have appearance preferences hang after switching to compiz?
[20:53] <nemo> mine's been just sitting there, unresponsive, even though compiz seems to be working fine
[20:53] <nemo> hung immediately after I clicked "keep settings"
[20:53] <jdong> a lot of clone() -> wait4() looping
[20:54] <nemo> doesn't seem to actually be doing anything though
[20:55] <jdong> killing it with SIGSTOP stops the CPU usage
[20:55] <jdong> ok, who do I whine about indicator-sound-service to?
[20:57] <robbiew> \o/
[20:57] <robbiew> we released on the right day this time :P
[20:57] <robbiew> heh
[20:57] <robbiew> nice work people
[20:58] <jdong> well... removing the volume applet thing seemed to have helped
[20:58] <nemo> hm. nothing obvious in xsession-errors
[20:58] <nemo> nor strace or lsof
[20:58] <nemo> gdb bt says it is hanging in theme_thumbnail_factory_init
[20:59] <nemo> oh well
[20:59]  * nemo kills it
[21:05] <micahg> slangasek: should something be added to the release notes from beta 2 that the Firefox search engine will be changed back to Google?
[21:05] <slangasek> ScottK, apachelogger: that video looks like a plymouth crash bug to me; any apport naggings afterwards?
[21:06]  * ScottK looks at apachelogger.
[21:07] <apachelogger> slangasek: apport reports are in /var/crash, right?
[21:08] <slangasek> yep
[21:08] <apachelogger> nothing then :(
[21:08] <slangasek> ok
[21:09] <ScottK> apachelogger: So not our fault.
[22:00] <seb128> slangasek, hey, are we unfrozen? ie can I do syncs?
[22:00] <slangasek> you can do syncs, yes
[22:00] <seb128> thanks
[22:00] <slangasek> we're not completely unfrozen yet, there are some things in the queue that I want to eyeball before letting them in
[22:01] <seb128> slangasek, ok
[22:16] <slangasek> pitti: tzdata's not in the freeze queue for lucid?