[00:01] <redvamp128> Or if anyone knows of a room on Enlightenment that might help too.
[00:28] <\sh> james_w: are you importing the orig.tar.gz sources of our packages in <release>-upstream or do you rely really on upstream tarballs?
[00:34] <james_w> \sh: the LP branches use pristine-tar, so you don't need to download the upstream tarball in addition
[01:09] <directhex> NCommander, i have never touched hppa, and my last SPARC was evicted with the help of a crowbar
[02:20] <jcastro> cjwatson: the grub2 article on LWN was highly informative.
[02:43] <NCommander> directhex, O_O;;;;;;;;;;;;;
[02:43] <NCommander> directhex, 1. WTF 2. Huh?
[03:04] <nixternal> bryce: fyi, your ppa fixes my issues concerning the one bug report I filed a bit earlier today
[03:10] <bryce> nixternal, uh, which ppa and which bug?  (juggling fixes for bunch of different issues today)
[03:18] <nixternal> lol
[03:18] <nixternal> intel, crashing back to gdm after the kernel updates in karmic
[03:19] <nixternal> bryce: bug #391797
[03:20] <nixternal> ya, couldn't tell if it was a dup as browsing LP with w3m isn't fun :)
[03:20] <bryce> oh yeah, that fix is uploaded to karmic earlier today
[03:20] <nixternal> the mesa packages?
[03:20] <nixternal> after upgrading those packages my machine went bonkers
[03:21] <nixternal> 7.4.1-1ubuntu3 killed me, 7.4.1-1ubuntu4 from your PPA seems solid
[03:22] <bryce> nixternal, heh, we're up to mesa_7.4.1-1ubuntu6 now
[03:22] <nixternal> hahha, groovy
[03:22] <ajmitch> it's hard to keep up with all this development
[03:22] <nixternal> maybe I should actually read my karmic-changes messages from time-to-time :)
[03:23] <ajmitch> it's often helpful to read that list
[03:23] <nixternal> OK, America's Got Talent is on, time to go laugh at silly Americans
[03:23]  * ajmitch won't comment on that :)
[03:24] <bryce> nixternal, oh you could do that by reading the mesa change log too, it turns out ;-)
[05:01] <ScottK> cjwatson: I've made (I think) the needed changes to tasksel for Kubuntu Netbook Edition.  I'd appreciate it if you could have a look over it in bzr before it's uploaded.  http://bazaar.launchpad.net/~ubuntu-core-dev/tasksel/ubuntu/revision/1413
[05:51] <YokoZar> what package is the KDE menu editor?
[06:34] <twb> I'm creating a (private) package that assumes the target host is hardy.
[06:34] <twb> Can I add a dependency on a particular version of base-files or something, so that my package will not be installable on newer/older LTS systems?
[06:43] <dholbach> good morning
[06:43] <amitk> morning everyone, dholbach
[06:43] <dholbach> hiya amitk
[07:00] <pitti> Good morning
[07:01] <pitti> YokoZar: erm, you want to start clamd at login? that seems unappropriate to me, can't we start it on demand when its needed the first time?
[07:01] <YokoZar> pitti: if we do that, then we have to wait the 5 seconds when that app is starting up
[07:01] <pitti> YokoZar: do you need the system daemon, or can you just invoke it as an user without the daemon?
[07:02] <pitti> YokoZar: that's not too bad, since you won't start it anyway, right? you just say "checking for viruses" and then give the lecture about why you can't start it? or did I misunderstand something?
[07:02] <YokoZar> well either way it's got to load the virus definitions
[07:03] <pitti> sure, but only for a newly downloaded program?
[07:03] <pitti> clamd isn't something which we need running all the time on a desktop
[07:03] <Hobbsee> morning pitti!
[07:03] <YokoZar> pitti: this is true, if it takes 5 seconds to read the dialog then we might as well be loading clamd then and have a little spinning "scanning for viruses" thingy
[07:04] <pitti> pochu: p-c-d's dh_strip does handle -X
[07:04] <pitti> pochu: and also --keep-debug
[07:04] <pitti> YokoZar: you could certainly start the dialog first, display the progress bar, and then start clamav?
[07:05] <pitti> YokoZar: I suppose the actual virus check will also take a fair while, so you'd need a progress bar anyway?
[07:05] <YokoZar> pitti: the actual check is very fast once clam is running
[07:05] <pitti> pochu: dh compat 1> yes, a few :(
[07:05] <YokoZar> as in, so fast we could do it before showing the dialog
[07:05] <pitti> YokoZar: I suppose that again depends on the size of what you are checking?
[07:06] <YokoZar> probably, I guess I haven't tested 400 megabyte installers...
[07:06] <pitti> nixternal: ubuntu-bug just brings up apport-{gtk,kde,cli} as well; you mean you used apport-cli?
[07:07] <YokoZar> pitti: how about leaving clamd running after the dialog is closed?
[07:09] <pitti> YokoZar: why would you?
[07:10] <pitti> it's just wasting memory, and you probably won't need it again anytime soon?
[07:10] <pitti> YokoZar: can you please add some work items to the blueprint as well?
[07:11] <YokoZar> pitti: I did, at the bottom of the wiki page
[07:12] <pitti> YokoZar: they shold be a little more granular, these two that I added were just examples
[07:12] <StevenK> pitti: Can you check if I'm good to upload ubuntu-meta?
[07:12] <YokoZar> pitti: my thought about needing it again was if we had a clamav integration with Wine and it then wanted to scan more files (eg a whole CD), but I guess if it's for downloaded things then it's a one shot deal
[07:13] <pitti> YokoZar: can it time out after N minutes of being unused?
[07:13] <YokoZar> oh, that's a good question, I'll ask ScottK
[07:13] <pitti> StevenK: hm, apparently udev 143 is stalled; if you need to update urgently, we could revert the seed change for now
[07:13] <StevenK> pitti: No, it's okay.
[07:14] <StevenK> pitti: It isn't urgent, it's just on my plate to do.
[07:16] <YokoZar> pitti: I'll add more work items, note that clam starts when dialog starts (and ends when dialog closes or some timeout thereafter).  Was there anything else?
[07:24] <pitti> YokoZar: there were some other questions in my previous review, but you might already have addressed them
[07:55] <Peaker> Hey - I wanted to discuss the issue of sudo.  I think the association of a pseudo-tty with a remembered password (ala sudo's strategy) is OK for remote ssh connections and for local/physical tty's.  But I think its silly that an X server (representing a real screen/keyboard, probably a user) does not also have its own "remembered sudo".
[07:55] <ebroder> Isn't there a blueprint about that...?
[07:55] <ebroder> https://blueprints.launchpad.net/ubuntu/+spec/security-karmic-no-sudo
[07:56] <Peaker> well, that's about removing sudo altogether. I have a less radical idea, perhaps a temporary solution:
[07:57] <Peaker> I think maybe there should be a gnome/KDE applet for the panel or such that lets you type in the password once globally for all of X (or un-type it, if you leave the computer) - and then all gnome-terminals or anyone who wants root access can "sudo" without needing a password
[07:58] <Peaker> Perhaps "sudo" shall launch an X application to perform its deed - which can check with X or the applet whether you're allowed to do it
[08:00] <Peaker> its really silly for me to type in my password 5 times in the same minute, to prove to 5 different terminals on the same physical screen that I know the password
[08:00] <Peaker> on the other side of the coin, its also kind of silly that if two terminals end up on the same pseudo-tty by accident, they also don't need a password!  I think sudo should only remember physical tty's and X screens
[09:15] <soren>    /win 21
[09:15] <soren> Whoops
[09:23] <dholbach> Laney, bigon, seb128: if empathy is in main now and built with webkit, would it make sense to build gimp with webkit (like debian) again?
[09:24] <dholbach> also if clutter0.8 and champlain are in main now, would it make sense to build eog and gnome-games with the new options?
[09:24] <dholbach> bigon: did the indicate patch not apply any more?
[09:24] <pitti> dholbach: both are in universe still
[09:25] <dholbach> oh ok
[09:25] <dholbach> excusez-moi :)
[09:25] <dholbach> I thought empathy had already moved to main
[09:25] <seb128> dholbach, empathy is in universe, and we don't plan to use champlain
[09:25] <pitti> empathy still needs some gstreamer bits sorted out, and there's no MIR for champlain
[09:25] <dholbach> seb128: why not? :)
[09:25]  * dholbach isn't up-to-date on the desktop world
[09:25] <seb128> dholbach, because ENOCDSPACEFORITANDCLUTTERSTACK
[09:25] <dholbach> boohooooooo :-((((
[09:26] <seb128> I'm open to suggestions
[09:26] <seb128> but we have an explosion of depends there
[09:26] <seb128> and CD are still the same
[09:26] <pitti> seb128: you mean there's hope that we don't need to put webkit on the CDs?
[09:26] <seb128> not sure how we will add couchdb, clutter, webkit, etc
[09:26] <seb128> pitti, webkit we will, clutter maybe not
[09:26] <pitti> yeah, the entire empathy stack is quite large, plus the planned new online services packages
[09:26] <seb128> though gnome-games will require it
[09:26] <seb128> at least for some games
[09:27] <seb128> time to stop putting openoffice on the CD? ;-)
[09:28] <dholbach> will we manage to drop some of the old libraries?
[09:28] <dholbach> like the old sourceview, gnomeprint and stuff?
[09:28] <seb128> nothing which take space
[09:28] <seb128> yes, those cumulated will give some 700k each
[09:28] <dholbach> woohoo!
[09:28] <wgrant> How big is Erlang+CouchDB going to be?
[09:29] <seb128> dholbach, ie we spare 3*700k and add several 3meg libraries instead
[09:29] <dholbach> still it'd be worth to dump that stuff :)
[09:29] <pitti> wgrant: erlang was recently built without debug symbols, so erlang-base is "down" to 3.5 MB
[09:29] <seb128> right!
[09:29] <wgrant> pitti: Ah, not too terrible.
[09:30] <pitti> wgrant: slightly better than the original 25 MB of dependency chain :)
[09:30] <pitti> it still has a couple of extra dependencies, though
[09:30] <wgrant> pitti: Right, that's around what I'd remembered it being.
[09:30] <wgrant> I was scared a
[09:30] <pitti> 5.2 MB right now
[09:30] <wgrant> .. about what was going to have to be cut to fit it.
[09:31] <pitti> it at least moved from the "scaary, no way" into the "ugh, but possible" range
[09:31] <pitti> I hope we can trim it some more still
[09:32] <pitti> so far, the biggest potential space savings are: split out gnome help into langpacks (some 50 MB?), drop gimp help from CD (20 MB), recent tomboy with identical file symlinking (5 MB)
[09:32] <bigon> dholbach: I've dropped it for now because of cassidy review of the patch
[09:33] <wgrant> pitti: That's an awful lot of space you've got, then.
[09:33] <pitti> the first depends on a LP feature, though
[09:33] <wgrant> Right, so I saw.
[09:33] <pitti> gimp help takes some serious reorganization of language-support-*, but that's on the plan
[09:34] <pitti> robert_ancell, seb128: do you know if it's possible to have gimp start the online help if it isn't locally installed? it already opens an external browser anyway
[09:34] <dholbach> ArneGoetje: are there any plans around scim / ibus this cycle?
[09:34] <robert_ancell> pitti, no, sorry
[09:35] <seb128> pitti, no idea about this one
[09:35] <dholbach> bigon: ok
[09:35]  * pitti purges gimp help and tries
[09:36] <pochu> pitti: good morning. this is what I mean: http://pastebin.com/f70d9d462
[09:37] <pitti> robert_ancell, seb128: well, it almost works OOTB; it does open the help, just not in firefox, but in (ugh) w3m
[09:37] <seb128> lol
[09:37] <pitti> but that should be fixable?
[09:37] <seb128> pitti, what issue are you trying to solve?
[09:37] <pitti> pochu: aah; that makes sense
[09:37] <seb128> pitti, I though you already made it open the webbrowser in jaunty to avoid webkit on CD
[09:38] <pitti> seb128: having an option to not have gimp-help-common installed by default
[09:38] <seb128> pitti, should be easy to change the called URL to be the web one
[09:38] <pitti> seb128: I'm not saying that I'd particularly like it, but it's always good to have some fallback optinos at hand, especially for alphas
[09:39] <pitti> seb128: as I said, it already falls back to the online documentaiton if it isn't locally installed
[09:39] <pitti> it just opens w3m instead of firefox
[09:39] <seb128> ok, should be easy enough to fix
[09:39] <seb128> we need a way to put contributors tasks on a todolist ;-)
[09:40] <pitti> both xdg-open and gnome-open DTRT here, so I'm not sure what gimp uses
[09:41] <pitti> could anyone please try to open gimp help and check whether it's ffox or w3m?
[09:42] <seb128> pitti, firefox on karmic
[09:42] <seb128> but I do have the local help installed
[09:42] <pitti> hm, so it might be local misconfiguration here
[09:42] <seb128> opening firefox is wrong though since I use epiphany-browser
[09:42] <wgrant> Using Karmic, with local help installed, it complains that it doesn't have the help viewer, and then opens the help in epiphany-gecko.
[09:42] <wgrant> Which isn't my default; firefox-3.5 is.
[09:43] <pitti> lol
[09:43] <pitti> so, there does seem to be a strange browser problem here
[09:43] <wgrant> There does.
[09:43] <pitti> I don't think it's related to having the help installed or not
[09:43] <chrisccoulson> it isn't getting it from /etc/alternatives/x-www-browser is it?
[09:43] <pitti> since it needs a browser either way
[09:43] <geser> gimp opens firefox for me too (but first complains that the gimp help browser isn't installed)
[09:43] <pitti> aaah
[09:43] <pitti> lrwxrwxrwx 1 root root 20 2009-06-15 13:08 /etc/alternatives/x-www-browser -> /usr/bin/firefox-3.5
[09:43] <pitti> I have that purged again
[09:43] <pitti> yay alternatives
[09:43] <wgrant> pitti: x-www-browser matches for me too.
[09:44] <seb128> lrwxrwxrwx 1 root root 17 2009-06-15 22:16 /etc/alternatives/x-www-browser -> /usr/bin/epiphany
[09:44] <wgrant> Damn.
[09:44] <pitti> shouldn't it just use xdg-open?
[09:44] <seb128> pitti, gvfs-open rather
[09:44] <pitti> and only fall back to sensible-browser if it's not available?
[09:44] <pitti> seb128: I thought GIMP was gtk-only, not GNOME? or is it?
[09:44] <pitti> well, either way
[09:44] <seb128> pitti, gvfs-open is gio which is glib
[09:45] <seb128> pitti, well it use the same mechanism than gvfs-open, ie gio
[09:45] <seb128> not the actual gvfs-open command
[09:45] <seb128> but that should open the same thing that gvfs-open do
[09:45] <chrisccoulson> should it not use xdg-open? xdg-open should be modified to wrap gvfs-open on gnome rather than gnome-open perhaps
[09:46] <pitti> seb128: ok, after fixing my broken alternatives link, it works fine again
[09:46] <pitti> so wrt. having help installed, if we just dropped it, it would be bearable
[09:46] <seb128> it opens http://docs.gimp.org/2.6/fr/index.html by default there
[09:46] <seb128> I don't have the local documentation installed
[09:47] <pitti> right, here as well (just the German variant)
[09:47] <pitti> yay gimp
[10:00] <lesshaste> hi
[10:19] <lesshaste> I have been told to enable boot logging and post the output ( https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/389930 ) but this feature has not worked for ages and does nothing in jaunty.  Do they just mean /var/log/dmesg ?
[10:19] <lesshaste> because if so I can't see how that could help as it never says anything about grub
[10:20] <cjwatson> jcastro: oh, it was published? good
[10:21] <lesshaste> any help much appreciated
[10:33] <seb128> RainCT, hi
[10:33] <RainCT> Hey seb128
[10:33] <seb128> RainCT, what is the current status on zeitgeist packaging for karmic?
[10:35] <RainCT> seb128: Zeitgeist has undergone a complete database rewrite since UDS, and now we plan to release 0.1 Friday next week. I'll start pushing snapshots to the PPAs on ~zeitgeist (engine) and ~gnome-zeitgeist (GUI) within the next days and push the package into Debian/Ubuntu once 0.1 is out
[10:36] <seb128> RainCT, ok thanks, looks like we should wait a bit before trying to get it in karmic then
[10:37] <seb128> RainCT, let me know when it's ready if you need review to get in universe
[10:37] <RainCT> Yes, a week ago the engine was completely unstable and yesterday we finished an API change, so there wasn't much point in getting it in yet.
[10:38] <seb128> ok
[10:38] <RainCT> Okay, I'll keep you offer in mind. Thanks :).
[10:50] <geser> I've an executable (pdftk) that is linked against /usr/lib/gcj/itext-2.1.5.jar.so. Is there a better way to get dh_shlibdeps get this library found than passing "-l/" as an option?
[10:50] <geser> it looks a little bit ugly to me
[11:13] <\sh> MOINS
[11:13] <\sh> argl..caps no good
[11:19] <trip0-nb> who's the right guy to talk to about maximus in UNR ?
[11:19] <trip0-nb> I've got 2 screens and maximus only seems to be running on one of them
[11:23] <dholbach> trip0-nb: njpatel I guess
[11:29] <cjwatson> ScottK: your Kubuntu netbook stuff now names a "netbook-ship" seed in STRUCTURE which doesn't exist, which causes Kubuntu CD builds to fall over
[11:36] <trip0-nb> njpatel ping
[12:29] <ScottK> cjwatson: Ouch.
[12:30]  * ScottK looks
[12:33] <ScottK> cjwatson: It exists now.  Sorry about that.
[12:34] <trip0-nb> hmmm... looks lime maximus only respects the :0.0 display
[12:34] <trip0-nb> you need to launch a second instance for any other display
[12:35] <trip0-nb> I can do that with the command line, but I can't via this startup script: http://pastebin.com/m4968d092
[12:35] <cjwatson> ScottK: thanks
[12:35] <trip0-nb> for some unknown reason...
[12:36] <ScottK> pitti: Yesterday I created a kubuntu-netbook metapackage.  It needs to get promoted to Main (It's built out of the same source as kubuntu-desktop).  I was wondering if you would just promote it or if you want a bug on that?
[13:04] <nixternal> pitti: ya, used apport-cli, it was nice, refreshing, lovely :)
[13:55] <janmejay> i have a jaunty box running chroot jail, when i try to start mysql server (using /etc/init.d/mysql start) it waits for about 10 seconds and then exits after failing to start it
[13:55] <janmejay> is anyone aware of such problems
[13:55] <janmejay> ?
[13:56] <janmejay> when i try mysqld_safe start, i get Starting mysqld daemon with databases from /var/lib/mysql
[13:56] <janmejay> mysqld_safe[21012]: started
[13:56] <janmejay> STOPPING server from pid file /var/run/mysqld/mysqld.pid
[13:56] <janmejay> mysqld_safe[21018]: ended
[13:56] <janmejay> any ideas? (it works brilliantly on lenny (debian 5.0.1)
[13:57] <Chipzz> janmejay: this is not a bug-reporting channel
[13:58] <Chipzz> file a bug on launchpad
[13:58] <janmejay> sure, just wondering if anyone has seen a similar issue
[13:58] <Chipzz> also
[13:58] <Chipzz> #ubuntu-server would probably be a better place to ask
[13:59] <Chipzz> and it most likely is due to some filesystem (like /proc) not being mounted
[14:01] <mvo> Keybuk, zul: i take the rsync merge (if you don't mind)
[14:02] <zul> mvo: fine with me
[14:12] <Ampelbein> mvo: hi, would you mind if i merge python-adodb from debian?
[14:12] <mterry> cjwatson, what's the preferred solution for oem-config (if built out of ubiquity source) having a lower version than it used to?  bump ubiquity's version?  epoch?  a custom binary version (never done that before, but assume it's possible)?
[14:14] <mvo> Ampelbein: fine with me, go ahead
[14:14] <Ampelbein> ok, thanks.
[14:14] <Keybuk> mvo: sure
[14:15] <mvo> Ampelbein: and let me know if you need sponsoring for it
[14:16]  * mvo forwards the rsync teardown changes to debian as well
[14:17] <pitti> ScottK: promoted
[14:17] <pitti> nixternal: yeah, all that desktop crap :)
[14:18] <pitti> meh, something in Karmic broke USB yesterday
[14:18] <pitti> and I already wasted two hours suspecting my hardware and hassling the Dell support line about a broken docking station (internal USB works fine)
[14:18] <cjwatson> mterry: maybe bump ubiquity's version to 1.99, with the expectation of making it 2.0 for karmic
[14:18] <cjwatson> 1.99.0 rather
[14:18] <pitti> and now I found out that something during boot messes up USB
[14:18] <mterry> cjwatson, Sure
[14:18] <cjwatson> the others are possible but less preferable IMO
[14:19] <pitti> does that sound familiar to anyone?
[14:19] <cjwatson> mterry: BTW I expect that oem-config can have the old timezone map removed too, just as I recently did in ubiquity. Would you like me to do that in the oem-config tree?
[14:20] <mterry> cjwatson, eh, don't bother.  I'm pretty far along.  You can see a rough version of the merge at ~mterry/ubiquity/oem-config-merge
[14:20] <ArneGoetje> dholbach: we will use ibus as default IME for Karmic
[14:22] <cjwatson> mterry: filesystem layout looks fairly reasonable, haven't looked in depth though
[14:22] <cjwatson> mterry: you'll want to merge with ubiquity trunk sooner rather than later, as the removal of src/ and resulting autotools changes is a big delta
[14:23] <mterry> cjwatson, basically it's just ubiquity exact and if we're running with the script name 'oem-config' we set an environment variable that controls a few knobs (but as few as possible)
[14:23] <dholbach> ArneGoetje: maybe we'll save some space by dropping the other stuff to universe? :)
[14:23] <mterry> cjwatson, removal of src?  whoops, did I do that?
[14:23] <cjwatson> no, I did :-)
[14:24] <mterry> cjwatson, ah
[14:24] <cjwatson> mterry: environment> makes sense, if you've figured out how to merge the UI ...
[14:24] <ArneGoetje> dholbach: I'm not so sure about that
[14:24] <cjwatson> mterry: I was fed up of ubiquity-frontend-gtk being architecture-dependent
[14:24] <cjwatson> and there's really no excuse for it now
[14:24] <mterry> cjwatson, Yeah, the UI is mostly the same.  Only big change was the language screen was different.  I still have yet to hide a few options when in oem-config mode
[14:25] <cjwatson> yeah, I saw you had a separate glade file for that
[14:25] <cjwatson> what about the cases where component/script logic is different?
[14:25] <cjwatson> did you just deal with that using that environment variable?
[14:25] <mterry> cjwatson, there are a few cases where I call a different script from the component based on the env var
[14:25] <mterry> cjwatson, but by and large, not too many differences
[14:26] <cjwatson> yeah, just a few painful ones but I agree not many
[14:26] <cjwatson> tzsetup-wrapper is intentionally a bit different, IIRC
[14:26] <mterry> cjwatson, there's upstream work to reduce that delta (like allowing passing a $ROOT var to scripts)
[14:26] <cjwatson> console-setup-apply is entirely different
[14:26] <mterry> cjwatson, but I'm deferring that obviously until we nail this down
[14:27] <cjwatson> yeah, one thing at a time :)
[14:27] <mterry> cjwatson, but yah, agree that this is best merged soon.  asides from oem stuff, this is all I'm focusing on
[14:28] <dpm> ArneGoetje: I had missed the fact that scim was going to be replaced by ibus in Karmic. Is this the associated blueprint/spec ? -> https://blueprints.edge.launchpad.net/ubuntu/+spec/ibus-improvement/
[14:28] <mterry> cjwatson, oh, I see, you were saying best for me to merge with trunk, not other way
[14:28] <cjwatson> right
[14:28] <cjwatson> since I see you have diffs to various bits of autotoolsery and most of that can probably vanish
[14:28] <mterry> cjwatson, well, as long as you keep changing the layout, I want to merge with trunk asap.  ;)
[14:29] <ArneGoetje> dpm: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-input-methods
[14:29] <cjwatson> mterry: I'm done for the moment. :-)
[14:29] <cjwatson> just had a burst of enthusiasm
[14:29] <mterry> cjwatson, I'm sure we can dampen that with some more specs
[14:29] <dpm> ArneGoetje: thanks, subscribing
[14:30] <cjwatson> mterry: hey, the online help work I had scheduled for d-i took me a whole half a day
[14:30] <cjwatson> (modulo whatever feedback I get, the GTK frontend, actually writing the help text ...)
[14:31] <cjwatson> ttx: regarding the Java-related uploads I did yesterday; is there anything else I can do to help you get Eucalyptus sorted out for main and the CD?
[14:31] <mterry> cjwatson, (btw, I used the bzr-merge-into script to save history of imported files and not change the bzr format;  pretty hot)
[14:31] <cjwatson> mterry: I heard you mention that; not something I'm familiar with directly, but it sounds cool
[14:32] <ttx> cjwatson: at that point, no. We are very much waiting on Eucalyptus to give us a more precise idea of what buildtime and runtime deps will be on the upcoming release
[14:32] <mterry> cjwatson, I was too dumb to figure out bzr join.  :)  Kept giving me an error, so I looked elsewhere
[14:32]  * mterry heads back to oem-config land
[14:32] <cjwatson> mterry: so you merged into a subdirectory and then renamed stuff back out of the subdirectory?
[14:32] <mterry> cjwatson, yah
[14:32] <ttx> cjwatson: the work that was done so far is based on reasonable assumptions on what they will require in all cases
[14:33] <cjwatson> mterry: makes sense - and you checked that 'bzr log <filename>' showed the history?
[14:33] <mterry> cjwatson, yeah, if you add --include-merges (and without it, it prompts you to use it if you want merge info)
[14:33] <cjwatson> ttx: basically I'm trying to figure out if there's any way I can unblock myself on my cloud installer spec
[14:34] <cjwatson> ttx: or if I should switch it to a later milestone and pull something else forward
[14:34] <cjwatson> mterry: sounds very cool
[14:39] <dpm> ArneGoetje: I'm having a look at the upstream ibus code at http://github.com/phuang/. Which is the default UI frontend which will be used in Karmic? I'm trying to see if it's translatable.
[14:45] <al-maisan> who should be listed as the maintainer of the 'pycairo' package?
[14:45] <seb128> ubuntu core dev?
[14:45] <seb128> there is a sponsoring request waiting for it
[14:46] <al-maisan> thanks seb128!
[14:46] <seb128> before you start on an update if you want plan to do one
[14:47] <al-maisan> doko: do you mind if I take a stab at 'python-geoip'?
[14:47] <doko> al-maisan: no, please go ahead, I'm staying away from syncs and merges for this cycle
[14:47] <al-maisan> doko: thanks.
[14:49] <ArneGoetje> dpm: client/gtk2/
[14:50] <dpm> ArneGoetje: thanks, yes, I see it now
[15:15] <cjwatson> ScottK: you added kubuntu-netbook as a flavour to tasksel, but that seems a bit odd since the netbook stuff is part of the main Kubuntu seeds, isn't it? the UFLAVOURS list is a list of seed collections ...
[15:19] <jcastro> hyperair: are you working on getting lp:385801 upstream?
[15:20] <hyperair> hmm?
[15:20] <hyperair> er.. lemme see what that is.
[15:20] <seb128> bug #385801
[15:20] <hyperair> oh that!
[15:20] <hyperair> i need to hijack the upstream project =\
[15:20] <hyperair> but i haven't really figured out how i should go about it
[15:21] <hyperair> upstream devels have gone missing
[15:22] <cjwatson> ScottK: it causes ubuntu-seeds.pl to fail, so I'm going to adjust it
[15:37] <pitti> arrgh
[15:37] <pitti> superm1: I found out what "broke" my docking station yesterday
[15:38] <pitti> superm1: two hours of debugging and pestering the Dell support line about a docking station replacement helped :)
[15:38] <pitti> superm1: hid2hci -> b0rkage
[15:38] <pitti> superm1: do you have some minutes to debug this?
[15:38] <seb128> pitti, how did it break?
[15:39] <pitti> as soon as that udev rule becomes active, it breaks _all_ USB ports on the docking station
[15:39] <pitti> i. e. keyboard, mouse, etc. stop to work
[15:39] <pitti> it "just happened" during normal work yesterday, thus I suspected hw failure
[15:39] <pitti> but it seems I had a dist-upgrade running in the background which pulled in the new udev-extras
[15:39] <seb128> pitti, you called support before trying a jaunty CD to make sure it was not the distro? ;-)
[15:39] <pitti> the internal ports work fine
[15:40] <pitti> and the external didn't
[15:40] <pitti> so I suspected the docking station
[15:40] <seb128> ok I see
[15:40] <seb128> I don't get the issue there
[15:40] <pitti> I'll have to apologize tomorrow when they call back
[15:40] <pitti> seb128: dockign station as well?
[15:40] <seb128> yes
[15:40] <seb128> and usb mouse and keyboard
[15:40] <seb128> dist-upgraded during lunch today
[15:41] <pitti> -KERNEL=="mouse*", SUBSYSTEMS=="usb", ATTRS{idVendor}=="413c", ATTRS{bmAttributes}=="e0", \
[15:41] <pitti> +ATTR{bInterfaceProtocol}=="02", ATTRS{idVendor}=="413c", ATTRS{bmAttributes}=="e0", \
[15:41] <pitti>      RUN+="hid2hci --method dell -v $attr{idVendor} -p $attr{idProduct} --mode hci"
[15:42] <pitti> I'm pretty sure that's it
[15:42] <pitti> anyway, will file a bug with details
[15:46] <pitti> superm1: bug 392144
[15:59] <cjwatson> StevenK: I've committed Task-Name support to tasksel, along with UNR seed support
[16:12] <pitti> superm1: ok, I added a comprehensive analysis and proposed patch, but I need you to verify the intention and test the new rules
[16:15] <kees> mornin!
[16:16] <kees> slangasek: so, re: 391761, can't we just pass-through the NPROC setting like before?
[16:20] <tseliot> pitti: the fix in jaunty-proposed for bug 373711 works well
[17:47] <ogra> seb128, every seen something like that ? http://94.209.196.70/Screenshot.png
[17:48] <ogra> (it seems to happen only after login, the login manager is teh right way round)
[17:48] <seb128> ogra: no, seems a decorator bug
[17:48] <ogra> ah, compiz ?
[17:49] <ogra> i'll try to get him checking
[17:51] <ogra> seb128, hmm, that would influence the panel icons too ?
[17:51] <seb128> no
[17:51] <ogra> (beyond flipping all fonts etc)
[17:52] <seb128> is that locale specific?
[17:52] <ogra> he's gone in #ltsp anyway now ... cant ask him to test stuff ... but it looks weird, especially since the login manager is proper
[17:53] <mterry> slangasek, heyo, at some point can you give an opinion on bug 385949?  In particular the appropriate place to run pm-powersave
[17:54] <billybigrigger> is sound in flash still being worked on does anyone know?
[17:54] <billybigrigger> a few weeks ago i was told it would be fixed when a new ia32libs was updated
[17:58] <pitti> hey kees
[17:59] <kees> hi pitti!
[18:02] <slangasek> kees: the purpose of this patch is to reset limits on every session, to avoid inheriting lower-than-intended limits when doing something like su; we could pass them through, but that would still leave the NPROC value clobbered in some cases
[18:04] <kees> slangasek: hrm, so you it sounds like there is no way to get the kernel-set limits then?
[18:04] <kees> s/you/
[18:05] <kees> does grub2 not support triggers correctly?
[18:13] <cjwatson> kees: s/correctly/at all/. It's on the list
[18:14] <kees> cjwatson: heh, okay.
[18:39]  * zSoilworker o/
[19:08] <slytherin> kenvandine: ping. Do you plan to do a rebuild of ekiga? there are lot of NBS (http://people.ubuntu.com/~ubuntu-archive/NBS/) dependencies of ekiga
[19:09] <kenvandine> slytherin, haven't thought about it
[19:09] <kenvandine> slytherin, for karmic?
[19:09] <slytherin> kenvandine: yes
[19:10] <kenvandine> so it just needs a rebuild?
[19:10] <slytherin> kenvandine: I haven't checked. Do you want me to check?
[19:11] <superm1> pitti, wow, great work with that debugging.  i'll be sure to take a look at the proposed rules as soon as I can nab that hardware once more.
[19:29] <slytherin> can anyone please give back pygtk2 on sparc?
[19:30] <slytherin> oops, it is pygtk
[20:21] <slangasek> kenvandine: correct; the "default" limits have long since been discarded from the process state in the case we care about
[20:21] <slangasek> kees: ^^
[20:21] <slangasek> kenvandine: oops
[20:21] <slangasek> mterry: I think we want pitti to comment on that part; mine is not an expert opinion
[20:22] <mterry> slangasek, OK.  pitti, can you look at bug 385949 when you get a chance?  In particular, the decision of where and when to call pm-powersave?
[20:26] <slytherin> can anyone please give back pygtk on sparc?
[20:30] <cjwatson> slytherin: done
[20:30] <slytherin> cjwatson: thanks
[20:51] <ScottK> cjwatson: Thanks for fixing tasksel.
[20:51] <ScottK> pitti: Thanks for taking care of kubuntu-netbook promotion.
[20:57] <NCommander> ScottK, we have kubuntu-netbook now?
[21:01] <kees> slangasek: so it seems reasonable to emulate the kernel's estimations for the dynamic limits?
[21:11] <slangasek> kees: yes, we already have to do this type of shadowing for other limits :(
[21:15] <pam> Hi. Is there a wiki page describing the build process of the distro (build framework)?
[21:25] <cjwatson> pam: err. not really in its entirety (it's rather complex, and the distro is not just built all in one piece, but incrementally over time). https://wiki.ubuntu.com/UbuntuArchitecture may help
[21:27] <cjwatson> could an archive admin binary-NEW parted for me?
[21:27] <cjwatson> libparted1.8-12 belongs in main
[21:28] <pam> Thanks cjwatson, I will look into it. I am currently building a distro (roughly debootstrap + come customization) using a set of Makefile but it is a pain to maintain. Wondering if there are better ways to do that (scons? shell scripts? ...).
[21:28] <cjwatson> pam: not sure I can really help you, maintaining a distro on a rolling basis for years the way we do is very different from doing customisation work
[21:29] <pam> Right, my job is more integration rather building the packages
[21:30] <cjwatson> stuff like https://help.ubuntu.com/community/InstallCDCustomization and https://help.ubuntu.com/community/LiveCDCustomization is the best I'm aware of, but you're probably ahead of that already in terms of automation
[21:31] <cjwatson> make, scons, and shell are equivalent in terms of expressive power when it comes to automation; in fact I'd consider make rather superior if any dependencies are involved. My only awareness of scons is that some of my fellow developers complain that build failures that involve it are all but impossible to debug :)
[21:31] <cjwatson> if substantial dependencies aren't involved, make (or scons) is probably the wrong tool for the job
[21:35] <pam> heh
[21:36] <pam> Well, they are some dependencies to resolve (if I am updating the kernel, the build needs to rebuild the squash for instance). But most of my Makefile are phony targets and do a bunch of `cp -fau'.
[21:36] <pam> I am not really leveraging the power of Make besides dependencies checking, really.
[21:38] <pam> Make does a poor job of updating the base distro too. If I update my list of packages, I roughly need to make clean && make squash again (chrooting and dpkg -i would be an option but I would like to avoid being root on the build nodes).
[21:46] <cjwatson> slangasek: ^- parted NEW, if you're available? I have a dependency chain hanging off this that I'd like to be able to upload before going on holiday :)
[22:08]  * cjwatson naughtily NEWs libparted1.8-12 for himself in the cause of getting to bed at a reasonable hour. It's pretty obvious and I've checked that it seems sane ...
[22:09] <ScottK> NCommander: We do (sort of).  Currently it looks identical to regular Kubuntu, but that will change.
[22:10] <ebroder> How unusual is it for somebody to be appointed to MOTU without going through ubuntu-contributors first?
[22:10] <ScottK> ebroder: Quite common.
[22:14] <slangasek> cjwatson: ah, sorry - just blame any bugs in the NEWed package on me, then :)
[22:22] <cjwatson> slangasek: heh
[22:23] <cjwatson> I already caught the worst bug (debian/patches not applied!) as a result of an amd64 build failure
[22:36] <ion> USERID=`id | cut -f2 -d= | cut -f1 -d\(`; PIDS=`ps -eo pid,ruid,args | grep $USERID | egrep "mouseTrap[.]mouseTrap" | grep -v grep | awk '{print $1}'`
[22:37] <ion> *shiver
[22:37] <cjwatson> dtchen: can xfonts-scalable just be synced? the only change is for smooth upgrades from 6.06, which doesn't seem likely to be needed any more
[23:25] <kirkland> bryce: so is kms the sweetness that gives me 128 columns on my tty's now?
[23:26]  * kirkland 's wife just read that last sentence over his shoulder and thinks he was talking dirty
[23:27] <Laney> haha
[23:28]  * bryce winks at kirkland
[23:28] <RAOF> Nice big terminals, you know what I mean?
[23:28] <bryce> kirkland, yes and the toad dances the little lady, day after tomorrow
[23:28] <ajmitch> now what was that system load monitor which was slightly controversial in debian?
[23:29] <kirkland> bryce: heh
[23:29]  * bryce fixes aspell and hunspell to accept "Ubuntu" as correct
[23:29]  * kirkland hugs bryce 
[23:30] <kirkland> that's only 5 years too late
[23:30] <directhex> ajmitch, hot-babe
[23:30] <kirkland> bryce: soren has an old bug on that one
[23:30] <ajmitch> bryce: didn't you upload that a day or two ago?
[23:30] <bryce> kirkland, yeah I built off of that
[23:30] <kirkland> bryce: nice
[23:30] <bryce> ajmitch, I did aspell the other day, and hunspell today
[23:30] <ajmitch> ah right
[23:31]  * ajmitch sponsored maco's upload of aspell earlier which added blogs & blogger to the list you added :)
[23:31] <bryce> soren had the aspell stuff pretty much done, dunno why that didn't get uploaded, but I expanded on it a bit with Kubuntu, Shuttleworth, etc.
[23:31] <bryce> ajmitch, ahh cool
[23:32] <bryce> ajmitch, maco could hit hunspell too with those
[23:33] <kirkland> bryce: was that a 100-paper-cuts bug?
[23:33] <kirkland> bryce: if not, it should have been, imho
[23:34] <ajmitch> it is a little bit funny typing away in firefox & not having words like Ubuntu recognised on jaunty :)
[23:37] <bryce> kirkland, yeah, noticed it on the list, but it's one that's bothered me before
[23:38] <bryce> kirkland, what's a bit amazing is that there wasn't the infrastructure in place for us to add more words to the dictionaries easily
[23:38] <kirkland> bryce: odd ... is there now?
[23:40] <bryce> yep (actually that was most of the work)
[23:40] <bryce> I didn't want to do it as a patch to the dictionary because for aspell the wordlist is compressed so a patch wouldn't work
[23:41] <bryce> for hunspell, you also have to update the first line, which is a count of total words in the dictionary
[23:41] <bryce> so in both cases patching would just be recipe for patch bitrot
[23:42] <lifeless> so you wrote a dict updater?
[23:42] <bryce> so instead there's now a simple extrawords.txt file you can toss more words into, and the build process regenerates the dictionary appropriately
[23:47] <bryce> lifeless, I'm sure it could be improved on a lot, but it seems to do the job
[23:49] <lifeless> bryce: nice