[00:18] <ccheney> how do you flush your dns cache in ubuntu?
[00:19] <lifeless> ccheney: what dns cache
[00:20] <ccheney> i thought there was some sort of dns cache at the system level, maybe my problem is actually arp cache instead
[00:20] <BUGabundo> restarting networking ?
[00:21] <ccheney> my system can't connect to gtalk claiming no route to host i think due to it trying to connect before i authenticated with AP at the hotel
[00:21] <lifeless> there is an arp cache
[00:21] <lifeless> no route to host - you can see your route table by
[00:21] <lifeless> ip route
[00:21] <lifeless> you can get no route errors two ways
[00:21] <lifeless> no route locally
[00:21] <ccheney> yea just pidgin claims it not eg firefox
[00:22] <ccheney> or ssh, etc
[00:22] <lifeless> a router somewhere else sending back an ICMP error
[00:22] <BUGabundo> ccheney: restart pidgin ?
[00:22] <lifeless> routers can do that when they have no route. *or* when they don't want to let the traffic through
[00:23] <ccheney> BUGabundo: it seems to not help restarting pidgin, i'll try rebooting my system to see if it changes
[00:23] <BUGabundo> ccheney: that's a bit extreme
[00:23] <BUGabundo> even for 10 sec boot systems
[00:23] <BUGabundo> eheh
[00:24] <BUGabundo> try restarting networking
[00:25] <ccheney> hmm even total reboot didn't help :(
[00:25]  * ccheney kicks the hotel
[00:28] <BUGabundo> ccheney: mtr it ?
[00:29] <pochu> ccheney: you should be using empathy anyway ;)
[00:29] <ccheney> pochu: i'm using jaunty
[00:29] <ccheney> i can see talk.google.com
[00:29] <BUGabundo> not an excusse eheeh
[00:29] <ccheney> with mtr
[00:30] <BUGabundo> there is a PPA for empaty trunk
[00:30] <BUGabundo> hey pochu
[00:30] <BUGabundo> ccheney: ahhh pidgin updates?
[00:30] <BUGabundo> check for the record on the server tab
[00:32] <ccheney> hmm no pidgin updates available for me, i'm mostly up to date (as of sat night)
[00:32] <ccheney> it was working at the office too, so i think they are just blocking it somehow at the hotel
[00:32] <ccheney> it was working last night though so its a bit weird
[00:33]  * ccheney heads off to dinner, bbl
[00:33] <BUGabundo> ccheney: try https://imo.im
[00:34] <ccheney> BUGabundo: thanks
[00:35] <BUGabundo> np
[00:36]  * ccheney heads out now to dinner
[02:08] <cleary> hi - I hope I've got the right channel for my question, please redirect me if not -
[02:10] <cleary> I'm in the process of customising a desktop gnome environment based on jaunty - the customisations need to packaged, and I'd prefer to try and get this more correct than not
[02:11] <cleary> currently, I have replaced the ubuntu-artwork and ubuntu-wallpapers packages, providing modified gconf keys
[02:11] <cleary> so that takes care of the various themes and the desktop background
[02:11] <cleary> I need to make some fairly drastic changes to the panel though
[02:12] <ScottK> This is not the channel you are looking for.
[02:12] <cleary> currently, the panel layout seems to be controlled from the gnome-panel-data package, which provides two files
[02:13] <cleary> /etc/gconf/schemas/panel-default-setup.entries and /usr/share/gconf/defaults/05_panel-default-setup.entries
[02:14] <cleary> my panel changes basically mean I remove the top panel and move relevant applets to the bottom panel
[02:15] <cleary> so I need to override those default files somehow (without modifying them directly, preferably)
[02:16] <cleary> I know I can provide my own 90_foo.entries file in /usr/share/gconf/defaults/
[02:17] <cleary> however, because I don't plan to use the top panel gconf entry at all, I'm wondering if the 05_...entries file will still create it
[02:17] <cleary> what is the safest way for me to override these setting?
[02:17] <cleary> ScottK: sorry - completely missed your bit
[02:17] <cleary> ScottK: got a suggestion where I could go?
[02:18] <cleary> the problem is, this stuff seems to be distro specific
[02:19] <ScottK> Not particularly, but that's definitlely not development of Ubuntu.
[02:19] <ScottK> I think there is an #ubuntu-installer channel.
[02:20] <cleary> is there a desktop development focussed channel?
[02:20] <cleary> +gnome even
[02:23] <cleary> nvm, I'll have a look at #ubuntu-installer, and see if there's any relevant debian channels
[02:23] <cleary> thanks
[02:38] <pam> cjwatson: Thanks for the pointers. I am trying to test my merged syslinux package. The Ubuntu (non-Suse: 12-, 13- and 14- ones) gfxboot patches can't apply to the new comboot16 module and upstream doesn't know if they are still relevant. Testing this whole thing is kind of tricky actually :) For reference: http://syslinux.zytor.com/archives/2009-July/012866.html
[06:01] <talltomWA> I just got done with a computer sci degree and am looking to take up an open source project, any ideas on where to start
[06:44] <pitti> Good morning
[06:51] <pitti> slangasek: you rock!
[06:52] <pitti> slangasek: want me to accept gvfs for hardy-proposed now, or stall everything until after .3 was released?
[07:04] <\sh> moins
[07:07] <maxb> liw: Hello. Does apt-sync/zsync apply in any way to Packages files, or is it just about .deb files ?
[07:21] <anilg> I've multiple repositories in my sources.list.. how do I print the packages in one particular repository (say a launchpad ppa repo)?
[07:23] <dholbach> good morning
[07:24]  * slangasek wavse
[07:24] <maxb> anilg: Hi, that's not really a development question (as the topic says: "Development of Ubuntu (not support, not app development on Ubuntu)"). You'd be better placed asking that in #ubuntu. (Though ftr I don't think there is any command for this, and I'd probably resort to applying grep-ctrl to apt's raw lists files)
[07:25] <ogra> hmm, why dont we have a proper commandline interface to tasksel ...
[07:25]  * ogra cant belive nobody ever wrote something like that 
[07:25]  * dholbach wavse to slangasek too
[07:25] <anilg> maxb: thanks.. I did try #ubuntu
[07:25]  * ogra joins the wavsing to slangasek 
[07:28] <StevenK> ogra: We do, apt-get
[07:29] <ogra> StevenK, apt-get can make me a list of available tasks ?
[07:29]  * ogra checks the docs ... thats news to me
[07:32] <StevenK> ogra: grep '^Task: ' /var/lib/apt/lists/silver.archive.ubuntu.com_ubuntu_dists_jaunty_*_binary-*_Packages | cut -d\  -f2- | tr ',' '\n' | sed -e 's/^ //' | sort -u
[07:32] <ogra> lol
[07:33] <ogra> well, then i rather parse /usr/share/tasksel/ubuntu-tasks.desc :)
[07:33] <ogra> and depend on tasksel data
[07:34] <StevenK> ogra: For what?
[07:34] <ogra> rootstock
[07:34] <StevenK> Ah
[07:35] <ogra> i want to show a gtk list with available tasks plus a textfield where you can add sinle packages as csv list before you fire up the build
[07:36] <ogra> so what i was actually lookinf for was something like "tasksel --list-tasks" and "tasksel --list-taks-descriptions" to just feed into the list :)
[07:36] <StevenK> ogra: /usr/share/tasksel/ubuntu-tasks.desc will show you the *hosts* tasksel list, not the targets
[07:37] <ogra> the target doesnt exist at that point
[07:37] <StevenK> ogra: For the example of running rootstock on a Jaunty machine, but building a Karmic root
[07:38] <ogra> hmm, yeah, i probably shuld pull the packages list from the archive and use your approach ...
[07:38] <ogra> prob is that this changes my UI approach :/
[07:39] <ogra> since i need to know the target release before doing that ...
[07:40] <StevenK> ogra: You can pre-populate it, given data on the running system first.
[07:40] <ogra> indeed, thats what i do anyway
[07:40] <StevenK> ogra: But the task list might change if you're building for Karmic.
[07:40] <StevenK> Actually, it *will* change, I can think of two tasks that Karmic has and Jaunty doesn't.
[07:41] <ogra> by default it builds ubuntu-minimal and pulls all other data (locale, kbd settings etc) from the host
[07:43]  * ogra ponders how to make that switchable on the fly without ending up with something like a wizard UI
[07:45] <dholbach> ogra: mtp loves wizards!
[07:46] <dholbach> mpt
[07:46] <ogra> hmm, i should probably make the script stop generating *all* en_* locales inside qemu-system-arm ... might speed it up a bit
[07:46] <ogra> dholbach, oh, since when ?
[07:46] <ogra> i always thought he didnt :)
[07:46] <dholbach> didn't you see the wizard costume he was wearing in Boston?
[07:46] <ogra> heh
[07:51] <ogra> hrm, why did my trap code in the script stop working
[07:57] <nikolam> I have a problem with menu.lst
[07:57] <nikolam> Every time hardy updates kernel it mess up the grup option for testing ubuntu instalaltion
[07:57] <nikolam> and vice versa
[07:57] <YokoZar> dholbach: I propose that all Fall UDSes that are in the US overlap halloween
[07:58] <dholbach> YokoZar: I'm not sure I'm the right person to talk to :)
[07:58] <YokoZar> Failing that, they should end with a costume party
[07:58] <nikolam> I am editing menu.lst for Every kernel update on testing or stable since 6.10 and I am finally sick of it
[07:59] <nikolam> sorry I maybe should post this ono ubuntu or ubuntu+1, sorry.
[08:00] <YokoZar> btw dholbach, are there plans to let the 5-a-day stats page apply to individuals again?  It's been "groups only" for a long time now
[08:00] <dholbach> YokoZar: bdmurray is working on that
[08:01] <dholbach> YokoZar: it needs an RT ticket resolved because we need to process HUGE amounts of data
[08:01] <YokoZar> ahh ok
[08:02] <dholbach> like all ubuntu-bugs@ archives :)
[08:02] <dholbach> the code is open
[08:02] <dholbach> so if you want to help out, that's cool
[08:03] <dholbach> hey mdz
[08:06] <TheMuso> c
[08:08] <mdz_> dholbach, hi
[08:09]  * maxb boots intrepid and experiences nostalgia for how pretty it was :-/
[08:10] <ogra> nostalgia ?
[08:11] <maxb> usplash and notifications were both prettier in intrepid than jaunty/karmic, IMO
[08:11] <ogra> well ... but its not even a year old
[08:12] <ogra> boot a warty or hoary liveCD ... thats nostalgic :)
[08:12] <maxb> I was running jaunty from alpha 3, intrepid seems a long time ago :-)
[08:15] <hile> about names, just curious: so what will happen when ubuntu runs out of latin alphabet in release names? too far away to think about this?
[08:15] <maxb> That will not be until 2017....
[08:16] <highvoltage> the 2K17 bug. very serious stuff indeed.
[08:16] <hile> need a committee to solve the issue!
[08:16] <ogra> we will have taken over the world by then ... we'll just anhance the latin alphabet
[08:16] <ogra> *enhance
[08:17] <hile> that's a good plan
[08:17] <highvoltage> hile: I guess it will start over with unpronouncable letters. and then you'll call it things like "the distribution formerly known as hoary"
[08:18] <maxb> I dunno, I quite like the sound of "Ancestral Alligator"
[08:46] <seb128> slangasek, \o/ for fixing the gvfs samba issue
[08:47] <slangasek> seb128: thanks for your help setting me on the right track!
[08:47] <seb128> ;-)
[08:53] <dholbach> ¡¡¡ please everybody help to clean up http://people.ubuntu.com/~dholbach/sponsoring/ !!! :-)
[09:02] <liw> maxb, why ask in multiple forums, making sure that people miss the answer? I will answer via e-mail
[09:02] <Q-FUNK> howdy!  could someone with upload rights please merge the two attached maintainer scripts at LP bug #399482 ?
[09:04] <RAOF> Q-FUNK: Doesn't that say "fix released"?
[09:10] <Q-FUNK> RAOF: it was entirely the wrong fix.
[09:37] <ogra> Keybuk, erm, did the behavior of reboot change with upstart 0.6 ?
[09:38] <ogra> Keybuk, reboot -fp doesnt see to do what it did before in my qemu-system-arm VM
[09:38] <ogra> *seem
[09:55] <Keybuk> ogra: what do you mean?
[09:57] <wincide> hi all, i would appreciate an answer if someone know something about return codes when launching some proccesses... When i run some proccess and it finish its task, sometimes the return code in the terminal is like [1]   Done    |         [3]-  Done             or       [9]+  Exit 251
[09:57] <ogra> Keybuk, i'm running a script that bootstraps a base system into a qemu image, fires up the image with a shellscript to proceed the second stage bootstrap and set up some stuff ... in the end the sript calls reboot -f which doesnt seem to behave like it did before
[09:57] <Mez> ok, that's a major bug, gksu no longer works.
[09:57] <ogra> it uses init=<path to script> and indeed doesnt invoke upstart
[09:57] <wincide> i dont know the differences among [1] or a - / + after the number, or the exit code sometimes with + and other times with -   ..
[09:58] <liw> wincide, it's your shell outputting those, so a good first step would be its documentation ("man bash" if you're using that), even if it is intimidating
[09:59] <Keybuk> ogra: "doesn't seem to behave like it did before" ?
[09:59] <Keybuk> this is what I'm trying confused about
[09:59] <ogra> Keybuk, the vm doesnt shut down
[09:59] <Keybuk> did you try strace reboot -f ?
[10:00] <ogra> tricky to do in that setup
[10:01] <ogra> but i just had an insane idea, i can kill the vm from the outside after debootstrap is done with its second stage, do a normal boot and make the configuration script an upstart job :)
[10:02] <smb> hi, is currently someone around who knows a bit more on the userspace side of v4l1->v4l2 transition and applications only capable of v4l1. There is a regression bug on the kernel side (bug 352765) which I believe is rather tied to the applications and the compat lib.
[10:04] <Keybuk> ogra: reboot -f/poweroff -f really don't do much other than call the reboot() syscall
[10:04] <ogra> Keybuk, ok, i thought they might try to route that through upstart or so now
[10:04] <wincide> thx liw, buy i've reading all the bash man, and the closest term related to what i trying to find out, is just the number of proccess launched, but ,anything about this kind of return codes with + - or exit with + or - ....
[10:04] <Keybuk> ogra: no, only if you don't call with -f
[10:04] <ogra> the thing is that the kernel and VM are the same as before, only the image content is karmic
[10:05] <Keybuk> without -f they call shutdown
[10:05] <ogra> so its some software thats blocking here
[10:05] <Daviey> Keybuk: Is this a good time to start thinking about switiching from init.d scripts to upstart?
[10:05] <ogra> but i think i'll go with abusing upstart as installer, thats a funny idea
[10:06] <ogra> and will actually give me all initscripts out of the box instead of me having to invoke them from the script one by one
[10:06] <Keybuk> Daviey: to a limited degree, yes
[10:07] <ogra> Keybuk, is there a limitation on the amount of runlevels or could i just add a runlevel 7 or 8 ?
[10:07] <Keybuk> ogra: there are no runlevels 7 or 8
[10:07] <Daviey> Keybuk: thanks.
[10:07] <Keybuk> use 3, 4 or 5 - they're spare
[10:07] <ogra> Keybuk, no, i want them to stay untouched
[10:08] <Keybuk> you could use a different event than runlevel
[10:08] <ogra> being able to add runlevel 7 and just dump my job scripts in there would be cool
[10:09] <ogra> and delete everything related to 7 after i'm done
[10:09] <cjwatson> pam: I'm a bit confused. Why not just start with the working assumption that the upstream gfxboot module is sufficient, and test that? You could test for screen-clearing after 'localboot' (i.e. "Boot from first hard disk") easily enough, and I'd be surprised if force-prompt weren't handled upstream since otherwise it doesn't work very well with the standard menu system
[10:09] <ogra> hmm
[10:10] <cjwatson> pam: surely we shouldn't be getting a reputation of asking upstream to support Ubuntu's changes; that's bad form
[10:11] <cjwatson> wincide: it's described in the "JOB CONTROL" section of the bash manual page, specifically towards the end of the paragraph starting with "There are a number of ways to refer to jobs in the shell"
[10:12] <wincide> im taking a look again, lets check it... thx
[10:14] <ogra> Keybuk, oh, i suspect its even easier, i could just temporary replace /etc/init/rcS.conf
[10:15] <ogra> and call my config the same way sulogin is started
[10:16] <ogra> wow, thats so insane that i actually start to like it :)
[10:21] <Keybuk> you could do that
[10:21] <Keybuk> though that would mean forcing start into single-user mode
[10:25] <ogra> Keybuk, thats fine what bothers me since a while is that my script needs to invoke all the rcS stuff, thats error prone, using upstart works around that :)
[10:26] <ogra> and i can properly shut down
[10:26] <Keybuk> ogra: the rcS stuff?  your script needs the recovery menu?
[10:27] <ogra> no, but mounted / and proc etc etc
[10:27] <Keybuk> ah, I see your confusing
[10:27] <Keybuk> rcS.conf is for what to do *while* in single-user mode
[10:27] <Keybuk> not the sysinit scripts
[10:27] <ogra> oh, k
[10:27] <Keybuk> (which Debian always confusingly put in rcS.d)
[10:27] <Keybuk> rc-sysinit.conf is the one you want to look at
[10:27] <ogra> ok, will do
[10:28] <Keybuk> it runs rcS.d
[10:28] <Keybuk> then runs telinit to switch to the next runlevel
[10:28] <ogra> yep i see
[10:28] <ogra> oh and telinit dies with my test image :/
[10:29] <Keybuk> "dies" ?
[10:30] <ogra> yeah
[10:30] <ogra> but the image seems corrupt as well
[10:30] <ogra> grmbl
[10:30] <Keybuk> do you have a core dump?
[10:31] <ogra> telinit "did not recieve a reply etc etc"
[10:32] <ogra> i guess its the kernel i use for the VM
[10:32]  * ogra tries with a jaunty versatile one 
[10:35] <wincide> bye, thx for all
[10:35] <ogra> weird, same issue
[10:44] <ogra> Keybuk, was a corrupted fs ...
[10:44] <ogra> works with a different image
[10:45] <Keybuk> good to know
[10:47] <ogra_> grmbl
[10:47] <ogra_> whats up with my network today
[11:19] <cody-somerville> Ummm... why was a package seemingly just accepted into the jaunty release pocket?
[11:20] <cody-somerville> oh, uploads to partner get sent to jaunty-changes too
[11:20] <ogra> cody-somerville, partner archive ?
[11:20] <ogra> yeah
[11:27] <ogra> udevd[9589]: udev: missing sysfs features; please update the kernel or disable the kernel's CONFIG_SYSFS_DEPRECATED option; udev may fail to work correctly
[11:27] <ogra> mumble
[11:33] <james_w> quadrispro: around?
[11:37] <quadrispro> james_w: hi james
[11:37] <james_w> hi
[11:38] <james_w> I'm looking at ncurses
[11:38] <james_w> what does "Install wide-character patches into /{,usr/}lib32." mean?
[11:39] <quadrispro> james_w: only a moment, bug?
[11:39] <quadrispro> found
[11:39] <enrico> mvo: I saw your patch, I've been overly busy these days, I'll take care of it now
[11:39] <quadrispro> bug 399625
[11:43] <quadrispro> james_w: nothing, maybe I forgot to do some change... i'm checking it (and unsubscribing sponsors team for now)
[11:44] <james_w> quadrispro: thanks
[11:44] <james_w> it looks as though that changelog entry might have just been carried forwards for lots of uploads when it wasn't needed
[11:50] <mvo> enrico: thanks, no problem about the delay
[11:55] <dpm> StevenK: what do you think about the reply from fbreader upstream regarding their contributor guidelines, is this going to be a problem? -> http://www.fbreader.org/docs/contributions.php
[12:01] <enrico> mvo: uploaded, thanks a lot for the patch"
[12:01] <enrico> s/"/!/
[12:04] <mvo> enrico: cool, thanks!
[12:33] <ogra> oh
[12:34] <ogra> did the initscripts massively change in karmic ?
[12:34] <ogra> especially the stop tasks in them ?
[13:35] <cjwatson> seb128: could somebody please add a versioned Replaces on gnome-session to gnome-session-bin? I don't really want to accept the package in NEW since the missing Replaces will cause problems
[13:35] <seb128> cjwatson, will do, thanks for noticing
[13:35] <cjwatson> ta
[13:39] <seb128> cjwatson, in fact isn't the Conflicts enough?
[13:40] <cjwatson> seb128: I'm not convinced
[13:40] <seb128> cjwatson, I think Josselin argued before that using Conflicts only is enough and will assure things are upgraded in the right order
[13:40] <cjwatson> the safe rule is *always* to add a Replaces and it does no harm
[13:41] <seb128> right, I'm doing that, I just failed to convince Josselin apparently during previous discussions
[13:41] <seb128> I will ping him again about that
[13:41] <cjwatson> is Conflicts actually necessary? it makes the upgrade painful
[13:41] <cjwatson> using Conflicts means the old gnome-session package has to be entirely removed before installing the new gnome-session-bin
[13:42] <seb128> well I would say only Replaces is required
[13:42] <cjwatson> if possible, it would be better to use Replaces plus maybe Breaks
[13:42] <seb128> Breaks is not required, it's really a Replaces situation I think
[13:43] <cjwatson> right, in that case it's probably just the old-fashioned confusion between Conflicts and Replaces
[13:43] <seb128> yes
[13:43] <cjwatson> it's possible that he's technically right that Conflicts is enough, but it's definitely a suboptimal way to do it
[13:46] <seb128> cjwatson, Replaces version uploaded, you can accept the binaries now the Conflicts should work too or wait for the new build
[13:46] <cjwatson> ok, thanks
[13:46] <seb128> np, thanks for checking the binaries and letting me know about the issue
[13:49] <ivoks> could someone finally fix lvm2 bug 246324 ; it's trivial and makes life easier...
[13:52] <lool> pitti: I've pushed a seed change to desktop-common to pull apmd on armel; apmd was demoted from main to universe in karmic, so I don't think I need a MIR to promote it back, do I?
[13:53] <cjwatson> ivoks: done
[13:53] <ivoks> cjwatson: awsome; thanks
[13:59] <pitti> lool: right, we can just re-promote it; I just thought it was horribly outdated and ditched it from main
[13:59] <lool> pitti: The Marvell SoC we target for karmic will rely on APM, yeah!
[14:00] <lool> pitti: (I discovered that 10 minutes ago BTW)
[14:00] <pitti> modern!
[14:01]  * ogra wonders if devicekit-power can do APM at all
[14:27] <mvo> enrico: did you push your upload to git yet?
[14:36] <c_korn> is fast-user-switch-applet being dropped in karmic?
[14:37] <enrico> mvo: ah, right, I forgot
[14:38] <enrico> mvo: done.
[14:38] <mvo> thanks!
[14:42] <pitti> james_w: thanks for the package branch announcement
[14:42] <seb128> c_korn, it's in gdm now
[14:43] <pitti> james_w: one thing that's not quite clear to me, should the official brnaches be committed/pushed to, or are they read-only and only an auto-import?
[14:43] <james_w> they should be pushed to
[14:43] <james_w> you just can't yet
[14:43] <james_w> see the part about permissions
[14:43] <pitti> james_w: ah, so right now, they are read-only
[14:43] <james_w> yeah
[14:43] <pitti> james_w: other question, should they only be full-source, or packaging-only branches as well?
[14:44] <james_w> so any commit you do are just "squashed" in to one
[14:44] <james_w> full-source is the one true way!
[14:44] <cjwatson> there was discussion at UDS of how to incorporate history from older packaging-only branches
[14:45] <didrocks> pitti: I think we will have to update our desktop team workflow progressively to full-source branches :)
[14:45] <pitti> james_w: right, but both debian and ubuntu have a huge set of packaging-only branches
[14:45] <c_korn> seb128: http://www.ubuntu-pics.de/bild/18739/screenshot_003_qv7BQY.png you mean that?
[14:45] <pitti> and at this point they are still better than using the auto-imports
[14:46] <pitti> didrocks: yes, probably
[14:46] <james_w> why are they better?
[14:46] <seb128> c_korn, yes, cf gdm changelog for details
[14:46] <seb128> c_korn, the ubuntu changes need to be ported to the gdm version
[14:46] <james_w> (not being argumentative, I'd like to fix the issues)
[14:46] <seb128> c_korn, what you have now is the upstream variant, tedg is working on porting the ubuntu changes
[14:47] <seb128> didrocks, no; no change in the ubuntu desktop workflow
[14:47] <gnomefreak> ah that explains the depends on gdm
[14:47] <cjwatson> pitti: (FWIW there is no harm in continuing to use the old packaging-only branches outside the lp:ubuntu/karmic/ namespace until such time as the full-source branches are good enough)
[14:47] <didrocks> seb128: not now, just when the branches will be ready to use (not read only as of now), don't you think?
[14:48] <seb128> didrocks, we have something working I think we should not be the first to run in new things, we have enough to do without fighting tools and learning new way every week
[14:48] <didrocks> seb128: I can't agree more :)
[14:52] <seb128> james_w, one thing better with packaging only in vcs is the time it takes to fetch the source
[14:53] <seb128> james_w, it takes over 15 minutes to get the nautilus source there where it takes 1 minutes to get the tarball and the debian dir from a vcs
[14:53] <james_w> yes
[14:53] <djsiegel_> StevenK: what's happening with https://launchpad.net/about-window ?
[14:53] <james_w> I don't think that should be the only deciding factor though, and it is something that is being worked on and has improved a lot.
[14:54] <seb128> james_w, well it's a matter of pro and con, and that's an annoying con without any real pro for full source in what we do now
[14:54] <james_w> well, let me try and convince you of the pros
[14:56] <seb128> james_w, ok ;-)
[14:56] <james_w> seb128: nautilus isn't imported yet, and I'd like to do an experiment
[14:56] <james_w> any other package of a similar size you work with a lot?
[14:57] <seb128> james_w, gnome-control-center?
[14:57] <james_w> nope :-)
[14:58] <james_w> seems a lot of gnome isn't done yet :-)
[14:58] <seb128> gtk+2.0 is a bit an extreme example
[14:58] <seb128> gedit?
[14:58] <seb128> or gvfs
[14:58] <djsiegel_> pitti: scott ritchie reports that pcspkr sounds have been replaced with normal alert sounds in karmic https://bugs.edge.launchpad.net/ubuntu/+bug/77010
[14:58] <seb128> gvfs is recent though
[14:58] <pitti> djsiegel_: indeed, I saw his comment
[14:58] <pitti> didn't check on that bug yet, though
[14:58] <seb128> james_w, rhythmbox? just pick anything desktopish... ;-)
[14:58] <djsiegel_> pitti: glory glory hallelujah
[14:59] <pam> cjwatson: This is what I am trying to do (test if the patches are still relevant). About the mail: since Stefen is rewritting the patch again in C, just wanted to ping him about these fixes and incorporate them in the new version if necessary.
[14:59] <djsiegel_> pitti: ok, I will check and mark fixed when I get a chance, should have a machine to test tomorrow
[14:59] <cjwatson> pam: why not just plug it into an existing image and see if it works? :)
[15:00] <pam> I don't have access to the C version yet, not released AFAIK
[15:00] <pam> cjwatson: for the com16, sure
[15:01] <cjwatson> kirkland: why am I getting the motd every time I start a terminal window? that's incredibly annoying
[15:02] <james_w> seb128: empathy 38s vs 9s, so still some work to do
[15:03] <james_w> seb128: but when there's a new one to grab it should be quicker in bzr
[15:03] <seb128> james_w, that's already quite good my tests there where rather 10 times slower
[15:03] <james_w> that's why we are using the new format :-)
[15:03] <seb128> well there is a limit anyway which is the quantity of information you need to get
[15:04] <seb128> even git which is reputed to be fast is some 6-7 times slower than getting just the source in tarball
[15:04] <seb128> all the commits history is quite some datas
[15:16] <kirkland> cjwatson: that will go away as soon as slangasek accepts the pam_motd patch
[15:17] <kirkland> cjwatson: rm /etc/profile.d/update-motd.sh if you can't wait
[15:17] <kirkland> cjwatson: update-motd package going away, see ubuntu-devel@ mailing list
[15:18]  * kirkland -> returns to his holiday
[15:28] <StevenK> djsiegel_: You know, that's been stalled for about 5 releases?
[15:28] <djsiegel_> StevenK: yes I know
[15:29] <djsiegel_> StevenK: do you have any interest or bandwidth to unstall it?
[15:34] <cjwatson> kirkland: ok, thanks
[15:46]  * manjo moving to ubuntu-kernel as per rtg's command
[16:27] <fta> pitti, how long does it take to have a -dbgsym for a package? (say libdbus-1-3-dbgsym)
[16:29] <pitti> fta: until it's on ddebs.u.c.? Should be within 6 hours
[16:30] <pitti> 8, actually
[16:30] <pitti> 10 3,11,19 * * *
[16:30] <fta> pitti, hm, ok. thanks. i guess i'll wait
[16:30] <fta> 19:10, is that UTC?
[16:31] <jpds> Probably London.
[16:31] <pitti> BST
[16:31] <pitti> so, 1810 UTC
[16:31] <fta> less than 3h.. ok, thanks
[16:43] <slangasek> Keybuk: I see that upstart 0.6 provides /lib/init/upstart-job, but there's no Provides: upstart-job; oversight?  want a bug report?
[16:44] <Keybuk> slangasek: ah, yes please
[16:45] <mbiebl> Should also have a Conflicts/Replaces I guess
[16:46] <Keybuk> yeah should be a super-switch thing
[16:46] <Keybuk> mbiebl: btw. did you get any further with the "better" upstart-job than my hacky shell script?
[16:47] <mbiebl> It's not much better, but it has support for being called by /etc/rc?.d/???servicename
[16:47] <mbiebl> and it also tries to much all action that are supposed to be available (like force-reload)
[16:47] <mbiebl> to corresponding upstart actions
[16:49] <slangasek> mbiebl: should it?  we shouldn't ever have more than one upstart-job implementation on a given arch?
[16:50] <Keybuk> mbiebl: can you file a bug and attach it?
[16:50] <Keybuk> slangasek: upstart vs. sysvinit both providing it
[16:50] <slangasek> since when is sysvinit going to provide it?  I thought the alternative implementation was going to be built from upstart source
[16:50] <mbiebl> yeah, the idea was to provide a upstart-job implementation for sysvinit
[16:50] <slangasek> since it needs to understand upstart job formats
[16:51] <mbiebl> for people that don't want (or can make) the switch
[16:52] <mbiebl> can't make, meaning upstart is not yet available on their arch
[16:52] <slangasek> ah, I forgot that we were giving people a choice in some cases. :)
[16:53] <Keybuk> right, but there are two alternate implementations in Debian
[16:53] <Keybuk> or at least will be
[16:53] <mbiebl> this alternate implementation is giving me some headaches though.
[16:54] <mbiebl> not sure yet, how the stop action can be implemented
[16:58] <slangasek> mbiebl: killall5 should be fine
[16:58] <mbiebl> slangasek: I switched to #pkg-sysvinit
[17:31] <kees> pitti: do you have https://blueprints.launchpad.net/ubuntu/+spec/security-karmic-apport-abort on your schedule?  I'd like to start using that feature now that it's in glibc.
[17:33] <ogra> Keybuk, "init: rc-sysinit main process (380) killed by TERM signal" ... i assume i'm missing a kernel feature (fiddling with qemu arm kernels) would anything strike you as something i could miss from the top of your head ?
[17:33] <ogra> apart from that message the VM works perfectly fine
[17:34] <Keybuk> ogra: when did you receive that message?
[17:35] <ogra> Keybuk, when the login prompt shows up
[17:35] <Keybuk> "the login prompt" ?
[17:35] <ogra>  * Setting up console font and keymap...                                 [ OK ]
[17:35] <ogra>  * Starting system log daemon...                                                init: rc-sysinit main process (380) killed by TERM signal
[17:35] <ogra>                                                                          [ OK ]
[17:35] <ogra>  * Starting kernel log daemon...                                         [ OK ]
[17:35] <ogra> Ubuntu karmic (development branch) dove ttyAMA0
[17:35] <ogra> dove login: test
[17:36] <ogra> thats the boot (through a serial console)
[17:37] <Keybuk> ah right
[17:37] <Keybuk> it's just what was in the syslog buffer then
[17:37] <ogra> ah
[17:37] <ogra> so it actually died before
[17:37] <Keybuk> yeah, when it ran telinit
[17:38] <ogra> hmm
[17:38] <ogra> telinit itself didnt spill a message though
[17:39] <Keybuk> why would it?
[17:39] <ogra> because there is a stderr ?
[17:39] <Keybuk> no, I mean why are you expecting an error from telinit
[17:40] <ogra> because rc-sysinit gets killed and you said its caused by telinit ?
[17:41]  * ogra has the feeling he doesnt get it
[17:41] <Keybuk> rc-sysinit has
[17:41] <Keybuk>   stop on runlevel
[17:41] <Keybuk> the last command that rc-sysinit runs is
[17:41] <Keybuk>     telinit "${DEFAULT_RUNLEVEL}"
[17:41] <ogra> telinit default...
[17:42] <ogra> right
[17:42] <Keybuk> so telinit will generate the runlevel event
[17:42] <Keybuk> which will forcibly stop the job its actually running from
[17:42] <ogra> oh, so its no error at all
[17:42] <Keybuk> so Upstart will tell you that it was killed by the TERM signal
[17:42] <Keybuk> right
[17:42] <ogra> then i wonder why i dont see it anywhere else ?
[17:42] <Keybuk> the only reason you see it at all is because it's the last message in the syslog buffer
[17:43] <Keybuk> and it ends up on the console for some reason
[17:43] <ogra> yeah, and i see it on SDL qemu as well as on serial console ...
[17:43] <Keybuk> that might be part of the reason why
[17:43] <ogra> i would have blamed the serial console otherwise
[17:43] <Keybuk> it's just an escaped log message
[17:44] <Keybuk> nothing harmful
[17:44] <ogra> ok
[17:44] <ogra> thanks a lot for the clearification
[17:44]  * ogra dances .... so i have a cotex-a8 kernel for qemu :)
[17:44] <ogra> *cortex-a8
[18:00] <maco> Keybuk, question about bootlogd
[18:01] <Keybuk> maco: quickly...
[18:01] <maco> you said the init script wont be removed because what if the user patches bootlogd to work, then theyll need it.  why dont we patch it to work and put it back in?
[18:01] <maco> if such patches seem to already exist, that is
[18:01] <Keybuk> if you want to do that, please do
[18:02] <Keybuk> I'll happily sponsor the patches ;)
[18:02] <maco> are you making an evil smile right now?
[18:03] <apw> Keybuk, did X move to VT1 in karmic?  and where might i find that
[18:03] <Keybuk> no...
[18:03] <maco> ok. just checking that this isnt a "MUAHAHAHAH" moment
[18:03] <Keybuk> apw: X moved all over the place in karmic; frankly it's all gone a bit quantum
[18:03] <Keybuk> apw: you can tell which VT X is going to be on, or which VT X is actually on, but not both at the same time
[18:03] <apw> heheh ...
[18:04] <Keybuk> maco: it's somewhere on my TODO list, but it's a very long list, and it's quite near the bottom - so if you have some time, please do feel free to have go at it - if you get it all to work, I'll sponsor the upload
[18:04] <apw> what actually decides where it thinks it wants it started
[18:04] <Keybuk> maco: one of the obvious bits is that bootlogd would need to end up in sysvutils or whatever that package is called
[18:04] <Keybuk> maco: check with pere on OFTC #pkg-sysvinit
[18:04]  * apw is lost in a maze of twisty packages
[18:04] <Keybuk> apw: ironically, now I think about it
[18:04] <Keybuk> apw: my jokey statement was actually largely true
[18:04] <Keybuk> apw: X when started calls the VTQUERY ioctl to ask the kernel for the first free VT
[18:05] <Keybuk> apw: though I believe pitti has been doing some work to hardcode it to VT7, since BAD THINGS happen when X and getty share a VT
[18:05] <maco> Keybuk, ok, will look into it
[18:05] <chrisccoulson> hi cody-somerville - i just saw your GDM merge proposal
[18:05] <Keybuk> apw: obviously we'd rather not hardcode X to VT7, which would mean not hardcoding getty to VT1-6 either <g>
[18:05] <chrisccoulson> i think GDM still needs to depend on gnome-settings-daemon, else it doesn't theme properly
[18:05] <apw> Keybuk, on my jaunty box its on VT7 and there is a vt7 on X's command line
[18:05] <chrisccoulson> it used to get that dep via gnome-session
[18:05] <Keybuk> apw: but there's some resistance from the sandal-wearing crowd to a first-come-first-served approach to VTs
[18:05] <Keybuk> apw: then pitti has uploaded his patch :)
[18:06] <apw> and i think my crashy box which isn't here with me, that it was on VT1, and i was trying to confirm and failed
[18:06] <Keybuk> apw: that sounds plausible
[18:06]  * apw will have to download some more packages i guess
[18:06] <Keybuk> we have two options really
[18:06] <Keybuk> keep hardcoding getty to vt1-6 on boot
[18:07] <cody-somerville> chrisccoulson, Its generally not a good idea to take for granted dependencies you get through other dependencies for this exact situation <grins>
[18:07] <Keybuk> err s/ on boot//
[18:07] <Keybuk> hardcode X to vt7+
[18:07] <Keybuk> then VT switch on boot
[18:07] <Keybuk> (ugh)
[18:07] <Keybuk> or just do VTs on a first-come-first-served basis
[18:07] <Keybuk> ie. X would take VT1 on boot
[18:07] <Keybuk> and the "six gettys" configured would get VT2-7
[18:07] <chrisccoulson> cody-somerville - agreed ;)
[18:07] <cody-somerville> chrisccoulson, Does it need gnome-settings-daemon or gconf?
[18:07] <apw> Keybuk, yeah ...
[18:08] <chrisccoulson> cody-somerville - it needs both
[18:08] <Keybuk> apw: but then of course you could have two X logged in users, and two gettys
[18:08] <chrisccoulson> does it not already have a gconf dependency?
[18:08] <Keybuk> with X on vt1 and vt3, and getty on vt2 and vt4
[18:08] <Keybuk> maybe we could use udev
[18:08] <apw> yeah i thinl when i had two users they were VT-1 and 8
[18:08] <Keybuk> /dev/tty/by-user
[18:08] <ion> How about additional X sessions? They wouldn’t get adjacent VTs.
[18:09] <Keybuk> ion: everything would get "first free VT"
[18:09] <apw> ion the user has no clue where they are now
[18:09] <apw> they happen to be on 7 which is pretty mad
[18:09] <Keybuk> 7 and 9 now usually
[18:09] <Keybuk> user on 7, guest on 9
[18:09] <apw> yeah see what is on 8
[18:09] <Keybuk> because usplash took 8
[18:09] <apw> ahh
[18:10] <Keybuk> in this model, user would be on 1, and guest on 8 (assuming 6 gettys)
[18:10] <apw> i think in the new user switcher you get a 'switch to someone' entry on your logout menu
[18:10] <Keybuk> though it'd be generally unpredictable
[18:10] <Keybuk> right exatcly
[18:10] <apw> and it knows where it is and you son't have to know
[18:10] <Keybuk> the right way to solve this is just to embrace the chaos
[18:11] <Keybuk> and supply a more useful "VT switch" command ;)
[18:11] <Keybuk> console equivalent of user switch
[18:11] <cody-somerville> chrisccoulson, it does
[18:12] <chrisccoulson> so, it will still pull in some gnome-components. but, depending on gnome-session-bin only will mean that gnome-session is not registered as an alternative for x-session-manager and it won't start some gnome-only components
[18:13] <chrisccoulson> so it's slightly better ;)
[18:15] <cody-somerville> chrisccoulson, say again
[18:15] <apw> Keybuk, we could simply clear the first N vt's and push the console to 4 up or 6 and up
[18:15] <apw> and leave nothing on 1-5 so VT would be there
[18:17] <apw> Keybuk, how do i find out what makes 'system-services' apt-get source seems all confused by it
[18:20] <pitti> kees: ah, saw your spec approval; sorry, didn't have time to look into that yet
[18:28] <kees> pitti: no problemo; let me know if I can help.
[18:29] <pitti> kees: well, patches/commits appreciated, as always :) it'll still take me a bit to get to, since I have some high prio/stuff that other people depend on to do
[18:29] <kees> pitti: sure thing.
[18:29] <cody-somerville> chrisccoulson, I'm going to try starting gdm without gnome-settings-daemon
[18:30] <chrisccoulson> cody-somerville - no problem. i think you will lose the theme though
[18:31] <cody-somerville> chrisccoulson, I'm sure we can figure something out :)
[18:31] <cody-somerville> chrisccoulson, Thanks for your help btw with this. Its very *much* appreciated.
[18:31] <cody-somerville> :)
[18:31] <cody-somerville> brb
[18:31] <chrisccoulson> you're welcome:)
[18:33] <cody-somerville> chrisccoulson, it boots now atleast :)
[18:33] <cody-somerville> chrisccoulson, no theme as you said
[18:34] <chrisccoulson> excellent \o/ i did try booting a xubuntu live CD, and all i got was a broken gnome session
[18:34] <chrisccoulson> does the new dependencies fix that?
[18:34] <cody-somerville> chrisccoulson, It booted into Xfce and not gnome so I consider that a success :)
[18:34] <cody-somerville> albeit I don't have "gnome" installer
[18:35] <chrisccoulson> fantastic:)
[18:35] <chrisccoulson> fantastic :) even**
[18:40] <cody-somerville> chrisccoulson, hmm... looking at the logs it looks like gnome-session tried to start metacity for some reason
[18:40] <cody-somerville> chrisccoulson, this is in /var/log/gdm/:0-greeter.log
[18:41] <chrisccoulson> cody-somerville - it seems that GDM ships a metacity desktop file in it's autostart folder
[19:11] <jcastro> liw: FYI: http://dev.chromium.org/developers/design-documents/software-updates-courgette
[19:12] <jcastro> might be interesting to that deb zsync stuff
[19:17]  * ScottK waves to jcastro.
[19:22] <liw> jcastro, ack, thanks, I'll have a look
[19:23] <jcastro> hi ScottK!
[19:23] <ScottK> jcastro: I saw you found @kubuntunetbook
[19:24] <jcastro> ScottK: My spies are everywhere.
[19:24] <ScottK> jcastro: Yeah, well it's not like we're hiding ....
[19:24] <jcastro> heh
[19:25] <ScottK> jcastro: Feel free to hang out in #kubuntu-netbook if you want.  We have one of the plasma-netbook upstream devs in there with us if you want to supervise our upstream relations.
[19:25]  * jcastro todo's it
[19:25] <jcastro> ScottK: post-Debconf I will.
[19:25] <ScottK> Wouldn't it be faster to just join ...
[19:25] <ScottK> OK
[19:28] <superm1> Hm. so can someone advise the best way to proceed to fix bug 399482?  If you upgrade from 4.45-0ubuntu{1,2} to 4.45-ubuntu3 and bluetoothd isn't running, the prerm will fail. Adding in a case to the preinst to check if upgrading from 4.45-0ubuntu1 or 4.45-0ubuntu2 and spawning bluetoothd is all I can see working right now
[19:40] <ScottK> superm1: I think you can do something with dh_installinit --error-handler (see the man page).
[19:42] <superm1> ScottK, ah that looks to be a useful alternative, i'll do some experimenting with it. thanks
[19:42] <ScottK> You're welcome.
[19:59] <geser> superm1: looking at http://women.debian.org/wiki/English/MaintainerScripts adding a "failed-upgrade" case to the new prerm seems to be the only way to work around this failure when execute the old prerm
[20:07] <fta> pitti, is there a way to tell apport to keep several crash files for the same program+user?
[20:08] <fta> pitti, and what happens when a chrooted program crashes? where is the crash file generated?
[20:10] <cody-somerville> chrisccoulson, It seems like gdm is pretty much automatically logging into, for a lack of a better description, the gdm user, auto-launching a minimal gnome session and a GTK application to provide a GTK UI to perform the login.
[20:11] <mrooney> evand: I heard maybe you handle ubuntu-devel mailing list whitelisting? I was wondering if I could be added as I keep getting those moderation notices every time I reply and my replies also aren't timely then
[20:11] <chrisccoulson> cody-somerville - yeah, that sounds about right.
[20:37] <cody-somerville> chrisccoulson, is there anything in particular that demands gnome-session or metacity or [insert other gnome thing here]... that is besides the fact that launching gnome-session appears to be hardcoded into gdm simple slave?
[20:38] <evand> mrooney: I'm out for the evening, can you please send me an email to remind me and I'll take care of it tomorrow#
[20:42] <slangasek> pitti: pulling empathy in by default seems to have cost us about 7MB on the CDs now; how are we going to make that up?
[20:43] <mrooney> evand: sure thing, thanks!
[20:43] <slangasek> pitti: a lot of that is libwebkit, which we'd avoided in previous releases - is there other stuff we can convert to webkit and bring in some savings?
[20:43] <directhex> slangasek, sure. firefox.
[20:44] <directhex> Laney, is the current tomboy in karmic size-reduced?
[20:44] <Laney> should be
[20:44] <directhex> let me check some dep chains to see if i can get you anything
[20:44] <Laney> I was just doing the new tomboy
[20:45] <directhex> hm. my f-spot patch landed. i already gave you 2.7 meg last week, slangasek!
[20:45] <Laney> he's so demanding!
[20:45] <sebner> lol
[20:46] <slangasek> I only demand that CDs fit on CDs, the rest is the desktop team's doing. :)
[20:52] <seb128> slangasek, webkit will probably be a requirement for GNOME too soon but that will not win anything since xulruinner will stay for firefox anyway
[20:52] <seb128> slangasek, pitti suggested dropping the gimp user documentation today I think
[20:53] <slangasek> that sounds like a good place to start
[20:53] <slangasek> seb128: we also still have pidgin on here, is that going away soon?
[20:54] <seb128> slangasek, that should be fixed with the seed update to drop pidgin-libnotify
[20:54] <slangasek> ok
[20:54] <seb128> slangasek, did you get a CD rebuild since?
[20:54] <slangasek> I don't know
[20:54] <slangasek> doesn't look like it
[20:55] <seb128> slangasek, well we noticed the issue this morning and pitti unseeded pidgin-libnotify if there is still something pulling pidgin we need to investigate
[20:55]  * slangasek fires off a quick alternate build to see
[21:02] <chrisccoulson> cody-somerville - AFAICT, gdm needs gnome-session because gnome-session allows you to specify an autostart directory, to tell it where to load session agents from. i'm not sure if other session managers do that
[21:02] <cody-somerville> chrisccoulson, AFAIK, xfce4-session can do that
[21:03] <chrisccoulson> can it? i had a quick glance a couple of weeks ago and i wasn;t sure if it did
[21:04] <chrisccoulson> GDM does something like "gnome-session --autostart /etc/gdm/LoginWindow/autostart", to stop it loading files from the normal system autostart directories
[21:41] <johanbr> tkamppeter_, I have a pdf file (from latex) that cups in karmic treats very badly
[21:42] <johanbr> the source pdf is 1 meg, the pdf output that cups gives to the print server is 826 megs
[21:42] <johanbr> something you're aware of?
[22:01] <tormod> johanbr, sounds like something for a bug report and upstream possibly
[22:02] <tkamppeter> johanbr, please make the PDF file available to me. Thanks.
[22:09] <Askalon> 'Buonasera
[22:10] <Askalon> Siete tutti sviluppatori qui dentro?
[22:15] <slangasek> Askalon: si, ma la lingua franca qui é l'inglese
[22:15] <Askalon> Quindi se parlo in Italiano rischio di non essere capito, giusto?
[22:17] <charlie-tca> !it
[22:20] <slangasek> Askalon: non esserebbe capito, no :)
[22:20] <sebner> slangasek for italiano \o/
[22:22] <slangasek> sebner: survival-level, at least :)
[22:23] <sebner> slangasek: 8 years at school. knowledge forgotten -> 99%
[22:43] <slangasek> seb128: oh my... https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/207072/comments/239 :)
[22:43] <slangasek> well, at least that assures us there's no chance of regression ;)
[22:45] <Askalon> 	
[22:45] <Askalon> I can give you advice about an betterment?
[22:47]  * ScottK has a special folder in his email with lots of advice about betterment.
[22:48] <seb128> slangasek, arg, I don't have my hardy machine there but I will fix that tomorrow morning if nobody beats me to it
[22:54] <cjwatson> Askalon: suggestions for improvement are generally best filed as bug reports; https://help.ubuntu.com/community/ReportingBugs
[22:54] <cjwatson> Askalon: or, as that page notes, general ideas are better in brainstorm.ubuntu.com
[22:55] <Askalon> OK THANK YOU
[22:56] <ScottK> cjwatson: Do you a moment for an ISO image question/issue (I know it's late there and it's not urgent)
[22:57] <cjwatson> ScottK: go ahead, if it's too involved I can always defer the answer ;-)
[22:57] <ScottK> cjwatson: OK.  I noticed when I did a kubuntu-netbook install yesterday that the background during the live session was Ubuntu and not Kubuntu.  Where should I look for making a change to fix that?
[22:57] <ScottK> BTW, the kubuntu-netbook ISO are working quite well so far.
[22:58] <cjwatson> ScottK: hmm, IIRC that's controlled by which artwork packages are seeded, rather than by anything ISO-ish
[22:58] <cjwatson> I think, anyway
[22:59] <ScottK> cjwatson: OK.  I'll have a look and see if anything Ubuntu crept in.  Thanks.
[22:59]  * ScottK downloads todays first to verify ...
[23:00] <cjwatson> you do seem to have kubuntu-default-settings seeded
[23:01] <ScottK> That's the current intention (we'll have a netbook specific settings package eventually)
[23:05] <ScottK> cjwatson: The only thing I saw in the CD build log was some reference to edubuntu artwork.  I've no idea if it's related, but it seems odd the edubuntu addon stuff is getting run with netbook.
[23:05] <cjwatson> ScottK: it does rather. which log is that?
[23:05] <ScottK> cjwatson: http://people.canonical.com/~ubuntu-archive//cd-build-logs/kubuntu-netbook/karmic/daily-live-20090715.log
[23:08] <cjwatson> ScottK: oh, right, that's nothing to worry about, it's just the presence of the Kubuntu education seed but it isn't actually used on your CD
[23:08] <ScottK> cjwatson: OK.  Thanks.  I'm still left a bit mistified then.
[23:08] <cjwatson> find the file that contains the wallpaper in question, dpkg -S, look for that package name?
[23:08] <ScottK> Or rather mystified since I'm not getting wet.
[23:09] <cjwatson> IIRC the default is /usr/share/backgrounds/simple-ubuntu.png -> ubuntu-wallpapers
[23:09] <ScottK> cjwatson: OK.  I'm downloading today's ISO and I'll try that in a bit.  Thanks.
[23:09] <cjwatson> but that isn't in your image ...
[23:09] <cjwatson> according to http://cdimage.ubuntu.com/kubuntu-netbook/daily-live/current/karmic-netbook-i386.manifest anyway
[23:10] <cjwatson> so I confess myself a bit baffled too.
[23:10] <ScottK> That should give me a good pointer to see what's what once I get the image downloaded and converted.
[23:10] <ScottK> I'll make sure it's still a problem on today's image before getting too excited.
[23:11] <cjwatson> right
[23:12] <ScottK> Thanks for the pointers.