[07:47] <pitti> Good morning
[08:04] <ajmitch> morning pitti
[08:42] <pitti> $ sudo dpkg -P hal
[08:42] <pitti> MUHAHA
[08:46] <pitti> kees, jdstrand: http://piware.de/workitems/security/lucid/report.html
[10:47] <pitti> cjwatson: do you know if there's a way to invoke ssh-agent on demand (on the first ssh attempt) instead of having to run your entire session with the ssh-agent wrapper?
[10:56] <Rocha> hello =)
[10:56] <cjwatson> pitti: you can run 'eval `ssh-agent`' in your shell, but ssh can't do it for you because it would require poking environment variables into its parent shell
[10:56] <Rocha> how can i contribute with translations for ubuntu?
[10:56] <cjwatson> Rocha: https://wiki.ubuntu.com/ContributeToUbuntu#Translation
[10:57] <Rocha> i've found a lot os missing translations in the ptPT locale during the installation process
[10:57] <soren> pitti: Is starting ssh-agent really that expensive?
[10:57] <\sh> Pitti to Hal: HAL, I won't argue with you anymore, leave me alone : HAL to Pitti: Pitti, this conversation can serve no purpose anymore. Goodbye ;)
[10:57] <Rocha> cjwatson: thanks
[10:57] <pitti> cjwatson:  would it be feasible to also look for a  ~/.ssh/socket -> /tmp/... symlink if $SSH_AUTH_SOCK isn't there?
[10:57] <pitti> \sh: :)
[10:58] <pitti> soren: yes, it blocks the session for a second, which is an entire quarter of our budget
[10:58] <cjwatson> pitti: doesn't sound very appealing - this often needs to be session-specific and I think that could easily go wrong
[10:58] <cjwatson> why on earth is ssh-agent taking a second?
[10:58] <pitti> so since we got nailed on this 4 second thing, it's either "install it by default, but not in xsession.d", or "don't install it by default"
[10:59] <cjwatson> it's blindingly fast here. are you sure you aren't using the crappy seahorse thing?
[10:59] <pitti> http://people.canonical.com/~seb128/bootchart/seb128-dellmini-lucid-20091127-2.png
[10:59] <pitti> ssh-agent there loads and only runs its program (argument) a second later
[10:59] <cjwatson> $ time ssh-agent true
[10:59] <cjwatson> real    0m0.010s
[10:59] <pitti> and that's pretty consistent across all boot charts
[11:00] <\sh> pitti, when I read your post, I just thought about "A Space Odysee" from 1968 ;)
[11:00] <pitti> \sh: yeah, I've seen the movie some months ago
[11:01] <cjwatson> pitti: regardless, I think we should optimise ssh-agent, not remove it
[11:02] <pitti> it still strikes me as a less-than-optimal concept
[11:02] <Riddell> pitti: how's this for work items? https://wiki.kubuntu.org/Kubuntu/Todo
[11:02] <cjwatson> an strace of ssh-agent on a default installation would be nice, to see what it's doing
[11:03] <cjwatson> I would kindly request that you don't mess with the ssh authentication setup in the name of optimisation :)
[11:03]  * cjwatson doesn't really want to be flamed to death by the entire world
[11:07] <soren> Could it be some kind of bootchart artifact? What is the command that ssh-agent runs on a default install?
[11:08] <soren> (me uses gpg-agent as his ssh agent, so can't tell)
[11:08] <cjwatson> ssh-agent runs the rest of the session
[11:08] <cjwatson> it's just chained execution
[11:08] <soren> I know.
[11:09] <soren> I'm just wondering what the specific command was.
[11:09] <soren> I.e. the argv that ssh-agent ends up exec'ing.
[11:09] <cjwatson> I think it's chained pretty late - it ought to exec gnome-session
[11:09] <cjwatson> hmm, except it appears to be the other way round
[11:09] <pitti> martin   23688  0.0  0.0  36060   704 ?        Ss   09:22   0:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session /usr/bin/seahorse-agent --execute gnome-session
[11:10] <pitti> it's 90x11-common_ssh-agent
[11:10] <soren> Ok, so dbus-launch.
[11:10] <pitti> which is the last Xsession.d right before the "real" thing
[11:10] <cjwatson> while we're on useless things, what's the point of seahorse-agent?
[11:10] <pitti> and the commands are chained inside out
[11:10] <soren> Glancing at ssh-agent, I don't see why it would take second before it reaches the execvp.
[11:10] <pitti> cjwatson: it provides the passphrase dialog input box
[11:11] <cjwatson> as opposed to ssh-askpass? ... ok
[11:11] <pitti> (for gpg)
[11:11] <cjwatson> we could use pinentry for that
[11:11] <soren> So I was just wondering if it may be bootchart that's getting it wrong and that it's really all dbus-launch's fault. I don't know. Just a completely random stab in the dark.
[11:12] <pitti> switching to gnupg2 and pinentry is an option, if that's any faster
[11:12] <cjwatson> you can use pinentry with normal gpg?
[11:12] <cjwatson> I do ...
[11:12] <cjwatson> well, I use pinentry-curses, but still
[11:13] <cjwatson> that said, I don't see seahorse-agent in the bootchart
[11:13] <pitti> soren: could entirely be an interpretation artifact, yes
[11:13] <soren> Oddly, I don't see anything in between ssh-agent and gnome-settings-daemon in your bootchart?
[11:14] <cjwatson> I definitely don't understand why gnome-session is a parent of ssh-agent here
[11:14] <soren> It's a long exec chain.
[11:14] <pitti> cjwatson: seahorse-agent is only on my system with seahorse-plugins (for gpg)
[11:14] <soren> How does boothcart do its thing?
[11:14] <pitti> we don't install that by default, so it's not on seb128's
[11:14] <soren> bsd accounting or some such?
[11:14] <cjwatson> is there some weirdness in gnome-session to start ssh-agent itself?
[11:15] <cjwatson> or are we misinterpreting the intended ordering?
[11:16]  * soren heads out for a long lunch
[11:17] <pitti> I don't see anythign that would start ssh-agent from within gnome-session
[11:18] <pitti> we'll do some more accurate measurements, and compare charts with and without any agents, to see what the real difference is
[11:19] <pitti> but I still stand by my opinion that it'd be better to launch things on demand than everything at startup (many users might not ever need ssh/gpg ever)
[11:20] <pitti> which is why I asked whether there's an existing method to do that (well know location instead of well know environment variable); if that was there, it would have been a good step for clean up
[11:20] <pitti> but if it's not, let's shelve this for now
[11:21] <Rocha> is there a channel availabe for ubuntu translations?
[11:21] <pitti> Rocha: there is a mailing list: https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
[11:21] <Rocha> pitti: ok, thanks, subscribed 10min ago
[11:22] <pitti> Riddell: so is https://wiki.kubuntu.org/Kubuntu/Todo != https://wiki.kubuntu.org/Kubuntu/Todo/Lucid ?
[11:22] <pitti> Riddell: I'm currently pulling in the latter for WIs
[11:22] <pitti> ah, seems to be the same
[11:25] <Riddell> pitti: yes it's the same
[12:59] <jussi01> pitti: congratulations on the HAL achievement :D
[13:05] <cjwatson> pitti: has anyone suggested per-assignee burndown charts, or at least a list of work items for each assignee? there's no easy way to get a full list of WIs one's assigned to right now, since they don't necessarily correspond to spec assignees
[13:06] <cjwatson> (I'd be OK with a full list of specs on which I have WIs, too)
[13:23] <cyberix> hello
[13:23] <Tm_T> hi cyberix
[13:23] <cyberix> I'm wishing to get scrub into main
[13:24] <cyberix> http://packages.ubuntu.com/lucid/scrub
[13:24] <cyberix> It is a tool for securily deleting stuff
[13:24] <cyberix> It would be very convenient to have it on the live cd
[13:24] <Tm_T> cyberix: https://wiki.ubuntu.com/UbuntuMainInclusionRequirements
[13:25] <cyberix> so one could use it from the cd to write random on some partition
[13:25] <Tm_T> cyberix: is this document familiar to you?
[13:25] <cyberix> no
[13:25] <cyberix> I'm looking at it
[13:25] <Tm_T> good (:
[13:26] <cyberix> Is it possible for a command line utility to be "useful for a large part of our user base"
[13:26] <Tm_T> sure
[13:27] <cyberix> I guess securily destroying all data from an old HD is usefull for most users
[13:28] <cyberix> But I'm not sure, if it should be made easier than just having the tool available
[13:28] <cyberix> clearly you cannot do that from within the system as the filesystem is mounted when you boot from the HD
[13:28] <cjwatson> cyberix: it'd be better to get improvements merged into shred, perhaps
[13:28] <cjwatson> since that's already there
[13:30] <cyberix> cjwatson: does shred support clearing entire partitions and disks?
[13:31] <ion> Yes
[13:31] <cjwatson> the question is whether it *should* support that
[13:31] <cjwatson> we don't want to have multiple tools that do the same kind of job
[13:31] <cyberix> the reason why I'd be going for scrub is that it has names for different procedures of clearing the disk
[13:31] <cjwatson> and since shred is clearly already aiming at this kind of thing, the best approach is therefore to improve it
[13:31] <cyberix> according to different standards
[13:31] <cjwatson> since it's in coreutils and is already installed
[13:32] <cyberix> ok
[13:32] <cyberix> I could file bugs for shred
[13:32] <cjwatson> it'd be best to try to get upstream scrub and upstream coreutils working together, I'd have thought
[13:33] <cjwatson> I know people often want to run their own project, but coreutils is installed *everywhere* so it's an excellent way to get software out to people, if it fits
[13:33] <cjwatson> and I'm pretty sure a GNU project will want to have the best possible implementation of secure erase, rather than a half-hearted one :)
[13:34] <Tm_T> also it's typically good idea to avoid "NIH" effect where possible (:
[13:34] <cjwatson> I'm slightly puzzled, since the author of scrub is clearly already aware of shred
[13:36] <cyberix> I'll try to find him and ask him
[13:37] <cyberix> oh dear
[13:38] <cyberix> his email address ends with @llnl.gov
[13:38] <cyberix> sounds serious
[13:38] <cyberix> what is it?
[13:38] <cjwatson> also maybe talk with coreutils upstream
[13:38] <cjwatson> it's a research lab
[13:38] <cyberix> huh
[13:38] <Keybuk> people with lots of time on their hands and a tendency to do everything themselves from scratch :0
[13:38] <cyberix> that's good
[13:40] <Tm_T> cjwatson: hard to find any information about this project, or maybe it's just me failing again
[13:40] <cjwatson> scrub has been mentioned on the coreutils list, but only tangentially
[13:40] <cjwatson> Tm_T: which project?
[13:40] <Tm_T> cjwatson: scrub
[13:40] <cjwatson> you were expecting a .gov project to have an open development process? :)
[13:41] <Tm_T> cjwatson: no, but some info in http://code.google.com/p/diskscrub/
[13:41] <Tm_T> I mean, _something_
[13:41] <cjwatson> it's not unusual for single-command projects to not have much in the way of a web presence
[13:42] <Keybuk> superm1: around?
[13:42] <Tm_T> true, but I find that alone as one reason not to consider main for that
[13:42] <cjwatson> that would be a bit overkill given the number of things in main that don't have much of a web presence
[13:42] <goldins> what's wrong with shred?
[13:43] <cyberix> should I cc the discussion to some ubuntu-devel list?
[13:43] <cjwatson> honestly, I think that coreutils will be more interested in going out and merging ideas from scrub than the other way round ...
[13:43] <cjwatson> maybe this is unfair, but it's my impression
[13:43] <Tm_T> cjwatson: true that
[13:45] <ion> Yay, the lucid kernel fixes KMS with my radeon.
[13:46] <Laney> is there a karmic backport?
[13:47] <ion> Dunno
[13:48] <Laney> hmm
[13:48] <Laney> might just upgrade my desktop to lucid
[13:51]  * Laney takes the plunge
[13:51] <cjwatson> apw: any chance of a dummy linux-backports-modules-lucid?
[13:52] <apw> cjwatson, i don't think we are going to have a linux-backport-modules for lucid, we'll have backports packages, but its split into the components
[13:52] <cjwatson> oh really?
[13:52] <cjwatson> I guess we should update the seeds then ...
[13:53] <apw> even in karmic the we encourage use of l-b-m-alsa and l-b-m-wifi (approximarly
[13:53] <apw> as l-b-m has only been wifi for the longest time, but we're needing more now
[13:53] <apw> would you seed all of them onto the CD ?
[13:53] <ScottK> linux-backports-modules-lucid as a metapackage perhaps?
[13:54] <apw> ScottK, w
[13:54] <apw> ScottK, what would it mean?
[13:54] <cjwatson> I've dropped linux-backports-modules-karmic from the supported-kernel seed for now
[13:54] <apw> generally applying all of them would be bad from a users point of view
[13:54] <ScottK> Install that one and it pulls all the individual backports packages
[13:54] <ScottK> apw: OK.  Probably not then
[13:54] <directhe`> you also want to have backports for disk controllers
[13:55] <cjwatson> is anyone in xubuntu-dev around?
[13:55] <directhe`> and a clear policy regarding install media
[13:55] <directhe`> since those factors are why my servers run debian not dapper
[13:55] <cjwatson> actually never mind that, Cody applied my change
[13:55] <apw> if thats useful for the CD then i can see its something we could do, so you don't have to track the individual packages ... but not somethign a user would use
[13:55] <cjwatson> probably only point releases, by nature
[13:55] <apw> directhe`, backports for disk controllers?  never been asked for such a thing to my knowledge
[13:56] <cjwatson> I'm happy enough to figure it out then ...
[13:56] <directhe`> apw, i'm sure i had a bug open for it, but this is many years ago
[13:56] <ScottK> cjwatson: We already have our first kubuntu-dev application, so people aren't waiting to take advantage of the new permissions.
[13:56] <cjwatson> excellent
[13:57] <apw> cjwatson, ok ... so would it help to keep ubuntu-installer informed of when we get the various l-b-m components back
[13:57] <cjwatson> apw: never hurts at least
[13:57] <apw> ack
[13:57] <cjwatson> it's certainly possible that we might want to embed some of them into the installer
[13:57] <cjwatson> but probably not all
[13:58] <directhe`> apw, dapper as shipped didn't support dell perc5 controllers properly (it listed all drives individually as WELL as the raid array, which was listed last, so no deterministic way to rely upon a /dev node)
[13:58] <directhe`> apw, there was a kernel in -proposed with lots of backported drivers including that one, but i gave up on trying to squeeze it into a d-i disc
[13:59] <apw> directhe`, hrm, thats such old technology now, i would expect the brave new [sic] udev powered world to get that right
[13:59] <apw> one would hope that hardy would have been ok in that redard
[14:00] <directhe`> apw, well, the problem was the module was presenting all disks, so udev was creating nodes for them
[14:00] <directhe`> apw, i had servers to deploy, couldn't wait 2 years, so installed etch
[14:00] <apw> directhe`, as is your right :)
[14:46] <soren> pitti: How often are the burndown charts generated now? Daily?
[14:50] <pitti> cjwatson: I didn't get the request for per-assignee charts; the html report has per-assignee stats, but they might be spread over teams, so it's not very useful yet
[14:50] <pitti> cjwatson: it's relatively easy to generate a list of work items per assignee, though
[14:51] <soren> pitti: I would like that as well. It would make a nice, complete todo list sort of thing.
[14:51] <pitti> soren: right now, daily; this will switch to hourly once most blueprints have WIs; right now this would spam you 24 times a day with "BP has no work items waawaa"
[14:52] <soren> pitti: Oh, I see.
[14:52] <pitti> foundations now has hourly
[14:52] <soren> pitti: I think server should be in good shape for that as well.
[14:52]  * soren checks to make sure
[14:52]  * pitti regenerates
[14:53] <soren> pitti: How do you generate the report? It doesn't say on the wiki, only how to generate the chart.
[14:53] <pitti> soren: I just run the cron job manually
[14:53] <pitti> the entire cron job line is on the wiki
[14:53] <pitti> WARNING: server-lucid-cloud-krd has no work items
[14:53] <pitti> WARNING: server-lucid-bug-zapping has no work items
[14:53] <pitti> just those two
[14:53] <soren> cloud-krd? Hmm..  What on Earth is that?
[14:53] <pitti> soren: ok, server is in "full spam" hourly mode
[14:54] <soren> pitti: Who gets spammed? mdz?
[14:54] <mdz> soren, me and ttx
[14:54] <mdz> soren, cloud-krd is getting rid of the ec2 ramdisk
[14:55] <mdz> (smoser's)
[14:55] <soren> Ah. That's funny: last night I was considering adding an extra ramdisk. :)
[14:56] <soren> So, basically create a tiny AMI that just sits around waiting for an EBS volume to be attached, mount it, and boot into that. Voila, we have persistent instances.
[15:00] <soren> pitti: Is the cron job done? I still don't see myself on the assignee list.
[15:00] <pitti> yes, it only takes a couple of seconds
[15:00] <pitti> soren: http://piware.de/workitems/server/lucid/report.html has 50 work items for you..
[15:00] <soren> pitti: https://blueprints.edge.launchpad.net/ubuntu/+spec/server-lucid-automated-testing is listed on the spec list saying it has 50 work items and I'm the assignee..
[15:01] <soren> pitti: Oh. So it does.
[15:01] <soren> Firefox was showing me a cached version odd.
[15:01] <pitti> soren: you meant you _wish_ you wouldn't have any? :-)
[15:01] <soren> I just typed in the URL manually. :/
[15:02] <pitti> robbiew_: what's the topic for today's release meeting? I'm not sure what to prepare
[15:11] <asac> pitti: i dont see a release meeting on todays calendar ... first entry is next week
[15:11] <pitti> asac: hm, I remember accepting an invitation
[15:12] <asac> yeah. me too ... but that was for 4th dec and after as it seems
[15:12] <pitti> ah, so it is
[15:12] <pitti> thanks!
[15:12] <asac> np
[15:12] <pitti> robbiew_: unping then :)
[15:12] <asac> ;)
[15:15]  * lamont continues to scratch his head at the b0rked karmic upgrade
[15:15] <lamont> gdm-simple-greeter[2468]: WARNING: Unable to find users: no seat-id found
[15:16] <pitti> lamont: is console-kit-daemon running? does ck-list-sessions work for you?
[15:17] <lamont> pitti: seems not to be.  the issue at hand is that after a upgrade of this jaunty machine to karmic, gdm presents no users for login
[15:17] <lamont> mind you, the machine was running edgy at some point since it's last coldinstall
[15:20] <lamont> pitti: ok.  followup question: why did console-kit-daemon die/not-start then?  (where does it log?)
[15:21] <pitti> lamont: if it's not running, ck-list-sessions should dbus-activate it
[15:21] <pitti> so if it's still not running now, can you please run sudo  /usr/sbin/console-kit-daemon and see what it's complaining about?
[15:22] <pitti> lamont: it just uses /var/log/daemon.log
[15:22] <lamont> when I ran it, it started just fine
[15:22] <pitti> so after a reboot it isn't running? any error about it in /var/log/daemon.log?
[15:23] <lamont> just a warning about some pid's environ file in proc when I ran it now
[15:23]  * lamont reboots to get a fresh look at it
[15:24] <lamont> to make matters more, um, interesting, I dpkg --purged all of the rc packages to unclutter the dpkg output...  I suspect this tanked some file somewhere, so I did an install --reinstall of every installed package while I slept
[15:26] <lamont> nothing in daemon.log, no console-kit-daemon, after reboot
[15:27] <lamont> pitti: OTOH, gdm now shows users
[15:28] <lamont> rather, user.  how do I get it to quit showing the list of users again?  (since that's totally WRONG in this machine's case, given that I'm the only local user (kids come from nss-db), so they have to hit 'other' before they can log in)
[15:34] <pitti> lamont: hiding user list is not that easy, but you could do "sudo -u gdm gconf-editor" and set /apps/gdm/simple-greeter/disable_user_list to false
[15:35] <lamont> no, you set it to true, seb128 sucks
[15:35] <pitti> (there's a plan to make that accessible in gdmconfig in lucid)
[16:02] <lamont> pitti: thanks - I had the gconf thing, just backwards sense on the value
[16:02] <lamont> (since it's wrong in the bug)
[16:07] <lamont> pitti: though it might be nice if gdm also noticed a lack of users, and dropped into the "username/password" non-face-browser version of login at that point...
[16:07] <lamont> bigger question is why didn't console-kit-daemon start
[16:07] <pitti> lamont: does c-k-d start when you log in?
[16:07] <pitti> at that point at latest it should get spawned
[16:07] <lamont> oh, it's all working just fine ever since I manually started it.
[16:07] <pitti> I guess with zero users in the list gdm doesn't have anything it needs to query c-k about
[16:08] <pitti> auto non-face browser> indeed
[16:08] <lamont> and it's not actually running in the logged in session now...
[16:09] <lamont> ISTR running into this when I dragged my machine from intrepid->jaunty, and solved it by coldinstalling.  or something like that
[16:10] <lamont> and nothing logged in daemon.log
[16:10] <pitti> very strange; it means that you are missing half of the requried device access permissions, etc.
[16:10] <pitti> you do have /usr/share/dbus-1/system-services/org.freedesktop.ConsoleKit.service, I take it
[16:11] <lamont> -rw-r--r-- 1 root root 92 2009-08-23 23:17 /usr/share/dbus-1/system-services/org.freedesktop.ConsoleKit.service
[16:12] <lamont> missing half == cause, or effect?
[16:24] <geser> does somebody know if there is a requirement on the timestamps inside a deb package? I'm looking at http://launchpadlibrarian.net/36001574/upload_1361070_log.txt (php-auth_1.6.2-1_all.deb: has 23 file(s) with a time stamp too far into the future (e.g. usr/share/doc/php-auth/examples/tests/users [Thu Jan  1 10:13:08 1970]))
[16:26] <cjwatson> geser: tar whines if timestamps suggest that you're running inside a time machine
[16:26] <cjwatson> it doesn't actually break
[16:27] <geser> cjwatson: that's the error message for a "Failed Upload" from the buildds and I'm trying to figure out if it's a bug in soyuz or the package
[16:28]  * cjwatson stares at an apt error message: "E:I wasn't able to locate file for the ubiquity package. This might mean you need to manually fix this package."
[16:28] <cjwatson> I'm sure I'm doing something wrong with python-apt, but I can't figure out exactly what ...
[16:30] <cjwatson> geser: ah, well, LP does do that check explicitly
[16:31] <cjwatson> the error message is buggy: it says "too far into the future" both for future files and ancient files; please file a bug on that
[16:31] <cjwatson> there's an argument that it's overly strict, but it is pointing out a genuine problem, so rather than tilt at windmills I'd be inclined to fix the package if I were you
[16:32] <cjwatson> I believe that dak does the same check
[16:33] <cjwatson> yeah, it does
[16:34] <cjwatson> in extremis you could touch the offending files during build or something, and get upstream to fix their tarball if it's their files at fault
[16:34] <geser> it's in the .orig.tar.gz too
[16:35] <geser> I wonder how the DD got the deb built (arch:all) as my attempt to build the package in a lenny pbuilder showed the same problem while the uploaded deb from the Debian archive has only current timestamps
[16:42] <cjwatson> geser: if they touched the files locally, it would have built for them but dpkg-source wouldn't have preserved the timestamp changes
[16:42] <directhex> bloody debian developers with their unreproducible binary uploads
[16:44] <geser> directhex: especially arch:all only packages
[16:45]  * geser hopes that the planned force rebuild of uploaded source in Debian will help a little bit
[17:00] <cjwatson> siretart: do you fancy (fixing|getting somebody to fix) the couple of bugs I filed under https://bugs.launchpad.net/ubuntu/+bugs?field.tag=emacs23-transition? I moved emacs23 to main, emacs22 to universe, and adjusted python2.4 and python2.5 to build with emacs23.
[17:05] <Bengan3> Ancient coder sais "Seek for any change in wine" Ubuntu/Fedora. Sound in Fedora seems better atm. Graphics seems ok in both of these. /Thanks for listening.
[17:24] <cjwatson> apw: anything delaying linux-meta from bumping to 2.6.32-5? (put another way, any reason I shouldn't rebuild the installer against -5?)
[17:24] <cjwatson> apw: ... never mind, apparently I meant linux-ports-meta not linux-meta
[17:24] <pitti> cjwatson: hm, that already happened a few days back?
[17:24] <pitti> ah
[17:24] <apw> yeah ... i thought i remembered this time :)
[17:25] <apw> yeah ports is a bit behind, but i don't have that tree
[17:25] <apw> i did mention it to themuso at uds
[17:26]  * cjwatson should check facts before typing, that's all
[17:27] <apw> cjwatson, only human, i have tended to lag too far on meta so i am a likely source :)
[17:31] <Keybuk> pitti: shouldn't the burndown graphs be generated with the highest number of items as the top of the burndown
[17:31] <Keybuk> rather than the number in the first day?
[17:31] <Keybuk> otherwise as work items get added, it won't adjust
[17:31] <Keybuk> and you get ...
[17:31] <Keybuk> http://piware.de/workitems/foundations/lucid/report.html
[17:31] <pitti> Keybuk: that would blur the effect of adding new items in the middle of the cycle, though
[17:32] <apw> waht he said
[17:32] <pitti> Keybuk: right, the plan is to ditch the DB next Monday (or alternatively adjust the start)
[17:32] <Keybuk> otoh, right now, it's useless if you didn't get all the items in when you started the graphs <g>
[17:32] <Keybuk> adding new items *should* change the graph
[17:32] <pitti> this week was pretty much meant to get the stuff running, and every team set up their WIs
[17:32] <Keybuk> your black line should decrease to the point the items were added
[17:33] <Keybuk> then jump higher again, but be steeper for the remainder
[17:35] <pitti> hm, it's not what we used so far
[17:35] <pitti> when we got new stuff in the middle of the cycle, it prominently was the blame for suddenly not reaching our goals any more
[17:35] <Keybuk> right, which means you need to work harder or add more employees
[17:35] <pitti> the trend line should not adapt to the current reality, but reality should measure against the plan
[17:35] <Keybuk> given our team, add more employees would be the right fix :p
[17:35] <pitti> (that's at least how I understood Rick)
[17:35] <pitti> Keybuk++
[17:36] <Keybuk> depends
[17:36]  * apw smiles
[17:36] <Keybuk> if you have 20 items and 5 days, you need to complete 4 items a day
[17:36] <apw> i suspect both are useful
[17:36] <Keybuk> if you now have 40 items and 4 days, you *now* need to complete 10 items a day
[17:36] <Keybuk> depends whether the line is supposed to show the original plan
[17:36] <apw> perhaps we could have a black line which is ricks line, and a red line which is keybuks line
[17:36] <Keybuk> or be indicative of where you need to be on a given day
[17:36] <Keybuk> rick's line shows the original plan
[17:37] <apw> yep, and keybuk's line shows reality from 'here'
[17:37] <Keybuk> my line should show the future trend based on the current items
[17:37] <Keybuk> neither line is actually true
[17:37] <Keybuk> you need a third line
[17:37] <Keybuk> the number of items that people actually *can* get done in a day
[17:37] <apw> they do make managers all excited though
[17:37] <Keybuk> the black line assumes that all work items planned at the start of the cycle *can* be completed ;P
[17:37] <Keybuk> when in reality, you want a fixed black line
[17:37] <Keybuk> so as more work items get added, even at the start, it shows "not going to happen"

[17:38] <pitti> you can also use it to see how much stuff you need to postpone
[17:39] <Keybuk> only if the line at the start reflected what could be done ;)
[17:39] <pitti> no, if you masssively over-planned, you just need to postpone more
[17:40] <pitti> and you can do that early, because trend and reality will drift away quickly
[17:40] <pitti> anyway, if you need another red line, patches accepted :)
[17:41] <cjwatson> speaking of which, is the running code automatically updated from bzr?
[17:41] <pitti> yes, it is
[17:41] <pitti> the cron job does a pull before anything else
[17:42] <pitti> which is kind of a remote hole on my server, I guess, but that's the reason why commit access is limited :)
[17:42]  * pitti finishes testing tzdata stuff and calls it a weekend
[17:43] <pitti> good night everyone!
[17:43] <apw> pitti, night
[18:01] <Bengan3> cjwatson: You seem to know what everyone likes (No GUIs what so ever). Now, how did your lame brain ever come to think that people wouldnt want "easy" to do the same work as "hard" ?
[18:11]  * apw shakes his head ... how constructive 
[18:11] <cjwatson> (no more constructive in /msg; I didn't think it was likely which is why I kicked him immediately)
[18:13] <apw> cjwatson, completely reasonable, its not like you don't think about users ever ...
[18:26] <kees> pitti: \o/ thanks!
[18:48] <mdz> mathiaz, zip and unzip are already in main
[18:49] <mathiaz> mdz: hm - right
[18:50] <mathiaz> mdz: so the proposal is to install them by default?
[18:50] <mdz> mathiaz, I believe so, it should be in the notes
[18:51] <mathiaz> mdz: was the proposal to install zip/unzip on -server only or by default everywhere?
[18:52] <mdz> mathiaz, what do the notes say?
[18:52] <mathiaz> mdz: "promote zip, unzip to server default install? "
[18:52] <mdz> mathiaz, yes, the proposal was to add them to the default server install then
[18:53]  * mathiaz updates the Work Items list
[18:53] <mdz> they fall into the "very small but very useful" category for me
[18:53] <mathiaz> mdz: right - which bring the question of having it part of ubuntu-standard instead of -server default install
[18:54] <mdz> mathiaz, I'm not sure of all the implications of that
[18:54] <mdz> mathiaz, if there are any other parts of the server seed which are not well documented/organized, it would be good to clean those up
[18:55] <mdz> some simple reordering and section changes would make it more readable
[18:55] <mdz> cjwatson, btw, can we remove the # WikiName comments from the seeds yet? ;-)
[18:56] <mathiaz> mdz: well - there are multiple server seeds
[18:56] <mathiaz> mdz: it would be good to have a list of seeds we're looking after
[18:56] <mathiaz> mdz: and I wonder how that maps to the PackageSets as well...
[18:57] <tormod> where did git-send-email and git-svn go?
[19:00] <ebroder> tormod: In terms of packages? git-send-email is in git-email and git-svn is in git-svn. Neither is installed with git-code
[19:00] <ebroder> *git-core
[19:00] <tormod> ebroder, I just updated to git-core/lucid and it forced out these two
[19:01] <tormod> and they did not migrate to git-core
[19:04] <tormod> ebroder, operator fault, I had forgotten to update my universe sources
[19:06] <cjwatson> mdz: feel free to remove any that are no longer useful ...
[19:06] <cjwatson> it's not as if anything parses them. :)
[19:06] <cjwatson> and they're in history if we're desperate for some reason
[19:06] <mdz> cjwatson, I don't think any of them are useful any longer, and was considering just removing them en masse
[19:07] <cjwatson> that's fine by me
[19:07]  * tormod thought all binaries of one source would belong to the same pocket
[19:07] <cjwatson> tormod: do you mean component?
[19:07] <tormod> yes I mean component :)
[19:07] <cjwatson> (pocket => release, security, updates ...; component => main, restricted, universe, multiverse)
[19:07] <cjwatson> tormod: no, not necessarily
[19:08] <cjwatson> I don't believe that's ever been the case in Ubuntu, although it is true in Debian
[19:11] <ebroder> tormod: Yeah, that's definitely untrue - I have the unfortunate habit of caring about packages that have one binary package in main :)
[19:11] <cjwatson> mdz: zip and unzip are in desktop-common anyway. As far as I can see the only other practical consequence of moving them from desktop-common to standard would be that they would end up in UEC images too
[19:12] <cjwatson> uec currently == server - wireless-tools - wpa-supplicant + some other stuff
[19:12] <cjwatson> mathiaz: ^-
[19:13] <dnivra_> i'm trying to compile the sudo source code
[19:14] <dnivra_> in the install file it's stated that PAM and LDAP headers are not installed by default and so need to be installed
[19:14] <mathiaz> cjwatson: I think that would be fine
[19:15] <dnivra_> but apt-get is unable find the packages pav-dev and openldap-devel
[19:15] <dnivra_> is it not available in the ubuntu repo?
[19:15] <tormod> dnivra_, usually apt-get build-dep sudo will help you
[19:16] <mathiaz> dnivra_: libldap2-dev
[19:16] <mathiaz> dnivra_: libpam0g-dev
[19:16] <dnivra_> tormod: well actually i'm trying to learn how sudo works; so need to manually specify where to install the files using ./configure <options>. is it possible using the apt-get command you gave?
[19:17] <dnivra_> mathiaz: thanks
[19:19] <dnivra_> i tried to run the following command for ./configure
[19:20] <dnivra_> but i get the error configure: error: expected an absolute directory name for --mandir: =/home/arvind/sudo/man
[19:20] <dnivra_> http://pastebin.org/57889
[19:20] <dnivra_> this is the command
[19:21] <dnivra_> why did the error occur?
[19:23] <mathiaz> dnivra_: because you've used 2 = instead of 1 in the configure command?
[19:24] <ebroder> Geez. When did pastebin.org start popping up background windows. That's disgusting
[19:24] <dnivra_> oops didn't notice that.
[19:24] <dnivra_> mathiaz: thanks
[19:28] <cjwatson> dnivra_: if you want to build it the same way Ubuntu does, you can just use 'debian/rules build'
[19:28] <cjwatson> assuming you're working with the Ubuntu source package rather than the upstream tarball
[19:29] <dnivra_> cjwatson: i used apt-get source sudo. so that is ubuntu source package right?
[19:29] <cjwatson> yes
[19:29] <goldins> ooh maybe that's how I should build ssh with opensc
[19:30] <cjwatson> or 'debuild -b' if you want it to go all the way through and build a package (requires that you've installed the devscripts package first)
[19:37] <goldins> can I pass configure options to debuild?
[19:38] <dnivra_> cjwatson: well i'm actually trying to create the binary so that i can analyse how it works using gdb; that's why all this compiling the source etc
[19:38] <dnivra_> cjwatson: thanks for the debuild; will check it out
[19:38] <ebroder> dnivra_: Are you just looking for ddebs.ubuntu.com?
[19:38] <ebroder> dnivra_: It has debugging symbols for everything
[19:39] <tormod> dnivra_, or build with: DEB_BUILD_OPTIONS="noopt nostrip debug" debuild -b -us -uc
[19:42] <dnivra_> what is a ddeb actually?
[19:43] <ebroder> It's just a .deb that contains debugging symbols instead of an actual package
[19:46] <dnivra_> ok
[19:46] <dnivra_> i have a doubt why not use this itself as the deb package?
[19:46] <tormod> dnivra_, but for gdb you want the "noopt" as well
[19:46] <dnivra_> tormod: ok
[19:48] <tormod> dnivra_, and also you can look up the source inside gdb, which won't work with ddebs
[19:48] <dnivra_> so tormod are you saying that ddebs.ubuntu.com is not enough because it's not specifically compiled for gdb?
[19:48] <dnivra_> tormod: that's precisely what i want to do look at the source inside gdb as each statement, each function call is executed
[19:49] <tormod> dnivra_, it's specifically for making gdb (and backtraces) more useful, but it is a convenience compromise
[19:49] <dnivra_> tormod: how is it a compromise?
[19:53] <cjwatson> because adding debugging symbols to everything would make the archive very much bigger, and would make it harder for us to fit a useful system inside our space constraints
[19:54] <cjwatson> (BTW, you mean "I have a question", not "I have a doubt" - seems to be a common non-native-speaker mistake :-) )
[19:54] <cjwatson> but if you build the package yourself with the DEB_BUILD_OPTIONS tormod gave, you'll usually get debugging symbols
[19:55] <cjwatson> and you don't need to mess about with ddebs
[19:55] <dnivra_> cjwatson: agreed. i really can improve english a bit more
[19:55] <cjwatson> no particular criticism, I'm sure I'm much worse at your native language ...
[19:55] <dnivra_> cjwatson: actually i speak english the best relatively
[19:55] <cjwatson> I'm curious why "doubt" is such a common miswording there, though - does it correspond to some word for "question" in some other language?
[19:56] <cjwatson> or language family?
[19:56] <dnivra_> no such correspondence in mine as far as i know
[20:03] <dnivra_> well thank you all for your help. gotta get some sleep(1:30am here).
[20:05] <tormod> cjwatson, I guess it is a direct translation, of something that is a question in your head, and not something you ask
[20:05] <tormod> another classic is "defect" about bug - I think that's Russian
[20:07] <maco> tormod: i see native english speakers use that
[20:08] <tormod> oh they must be non-geeks
[20:08] <maco> tormod: i think because bug implies broken functionality, while defect can be for misfeatures too (ie, it works as intended, but the intention is wrong)
[20:08] <joaopinto> cjwatson, in portuguese and eventually spanish, "dúvida"="doubt" means, "not be be sure, not to understand" , the second meaning allows it to be used directly as a replacement for "question"
[20:08] <maco> tormod: um...people at UDS...?
[20:08] <tormod> maco, forget it :)
[20:09] <maco> tormod: i think it came up in relation to usability bugs
[20:09] <tormod> well works as intended = "feature"
[20:10] <joaopinto> when we say "tenho uma dúvida"="I have a doubt", valid in portuguese, the next sentence will be a question :P
[20:10]  * tormod gonna reboot into a "full" lucid and has some doubt about there being some defects
[20:14] <joaopinto> some multinational IT companies do use "defect" as the standard term for "bug"
[20:14] <ScottK> They are roughly synonomous.
[20:16] <tormod> are the notification messages "low - report incorrect urgency?" a feature?
[20:17] <cjwatson> tormod: "defect" is quite common particularly in corporates (as joaopinto also said while you were /quit)
[20:17] <soren> joaopinto: "doubt" in Spanish is "duda".
[20:17] <cjwatson> and it does mean "something that's broken" so it's fair enough really
[20:17] <joaopinto> soren, close to portuguese, "dúvida"  :)
[20:17] <soren> joaopinto: Right :)
[20:18] <joaopinto> lately I decided to use "defect" on customer communication, it looks more professional :P
[20:19] <mpt> kees, did you see <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2009-November/010062.html>? Sorry if you're the wrong person to ask, but I'm not sure what it's about, and no-one replied
[20:25] <tormod> ok so wikipedia says that "bug" = "inexplicable defect" :)
[20:26] <cjwatson> how can I put this? that's a wikipedia bug :)
[20:29] <mannyv> joaopinto, schroot_build.py has fixed all my schroot/sbuild headaches.. now even when installing  a debian chroot, so thanks.
[20:30] <joaopinto> mannyv, great :)
[20:38] <mathiaz> cjwatson: is there a way to get the whole list of package sets?
[20:40] <cjwatson> mathiaz: yes, iterate over the launchpad.packagesets collection using the API
[20:40] <mathiaz> cjwatson: great - thanks
[20:41] <ScottK> mathiaz: ./edit_acl.py -P ubuntu-desktop -S lucid query works.
[20:41] <cjwatson> >>> sorted(set([s.name for s in launchpad.packagesets]))
[20:41] <cjwatson> [u'core', u'desktop-core', u'edubuntu', u'kernel', u'kubuntu', u'langpack', u'mobile', u'mythbuntu', u'ubuntu-desktop', u'ubuntu-server', u'ubuntustudio', u'unr', u'xubuntu']
[20:41] <ScottK> As an example.
[20:41] <cjwatson> ScottK: that gives you all the packages in a package set, but not the list of all package sets
[20:41] <mathiaz> ScottK: right - now I wanna figure the equivalent of ubuntu-desktop for server
[20:41] <ScottK> cjwatson: Ah, read the question wrong.  Thanks.
[20:42] <ScottK> Looks like ubuntu-server
[20:42] <mathiaz> cjwatson: during the karmic cycle you mentionned the following command: ./edit_acl.py -P karmic-ubuntu-server query
[20:43] <cjwatson> that has changed to -P ubuntu-server -S karmic
[20:43] <mathiaz> cjwatson: ok
[20:56] <tormod> do upstart script output go somewhere?
[21:04] <Arc> does anyone know why karmic-backports isn't in /usr/share/app-install/channels/ ?
[21:06] <Arc> im trying to discover how to enable karmic-backports using apturl
[22:06] <Arc> quiet room?
[22:07] <Arc> should update sources be enabled in apt-url or should backports be added as a channel?