[12:18] <cjwatson> Riddell: heh
[12:18] <cjwatson> guess it's all about familiarity in one form or another
[12:41] <Riddell> cjwatson: oh, can you let koffice into feisty backports?
[12:41] <agraveley> hey, i just had an awesome idea.  i come here looking for someone to do it for me ;-)
[12:42] <agraveley> what about altering ubuntu auto*/pkgconfig to automatically apt-get install missing requirements when trying to build something from source?
[12:43] <mjg59> That would be... interesting
[12:43] <agraveley> So I can avoid the ``No package 'mybutt-2.0' found'' spew whenever I download a tarball
[12:44] <mjg59> I'm not sure it would make sense as the default
[12:44] <agraveley> sure, it could prompt, and ask for sudo
[12:44] <mjg59> Yeah
[12:44] <crimsun> how well does auto-apt work with that?
[12:45] <agraveley> you guys altered bash to do that for uninstalled binary names, right?
[12:46] <mjg59> agraveley: It's a bash module rather than an altered bash
[12:46] <agraveley> neat
[01:51] <mbiebl> Have there been any changes to gnome-menu in gutsy?
[01:51] <mbiebl> I just upgraded from feisty to gutsy and now all the KDE kcm modules show up in the gnome menu (under "Others/Unknown")
[02:03] <Toxicity999> What's everyones take on ZFS/Fuse? Just reading up on it and thought I'd score some more insight.
[02:28] <wasabi> Oops. OS X gets ZFS.
[02:28] <wasabi> s/Oops/Ooh/
[03:07] <Toxicity999> wasabi haha yep I was reading that earlier, which led me into this fuse style ZFS implementation for Linux. Interesting stuff.
[03:08] <Spastic__teapot> Hello everyone.
[03:09] <Spastic__teapot> Anyone know who K. Mandla is?
[03:09] <Kioshen> https://launchpad.net/~k.mandla ?
[06:42] <fabbione> morning
[06:42] <LaserJock> morning
[06:44] <Burgundavia> hey fabbione, LaserJock
[07:55] <spasticteapot> Will Enemy Territory be added to the Repository?
[07:56] <Hobbsee> spasticteapot: if someone puts the work in and adds it, sure.
[07:56] <Hobbsee> !motu
[07:56] <ubotu> motu is short for Masters of the Universe. The brave souls who maintain the packages in the Universe section of Ubuntu. See  http://wiki.ubuntu.com/MOTU
[07:57] <spasticteapot> Nice.
[07:57] <Hobbsee> feel free to be that someone
[08:00] <jml> I really should learn how to make Ubuntu packages.
[08:04] <RAOF> jml: I'll help :).  We should package up Joybot sometime.
[08:04] <jml> RAOF: yes
[08:05] <RAOF> Maybe next month, particularly if radix does some more hacking on it.
[08:25] <evand> doesn't the Enemy Territory license prohibit redistribution?
[08:25] <Burgundavia> I have no idea
[08:26] <evand> http://liberatedgames.org/licenses/RTCW-ET_End_User_License_Agreement.txt - looks like it, but IANAL
[08:26] <LaserJock> we could probably ask for an exception if people wanted it enough
[08:26] <Burgundavia> http://www.ubuntu.com/getubuntu/releasenotes/704tour
[08:26] <Burgundavia> not listed here
[08:26] <Burgundavia> http://wiki.debian.org/Games/Unsuitable?highlight=%28game%29
[08:26] <Burgundavia> make that there
[08:27] <Burgundavia> section 4 nukes it
[08:30] <mfedyk> crimsun: hi, can we talk about bug 119033?
[08:30] <ubotu> Launchpad bug 119033 in control-center "gnome-sound-properties should call asoundconf" [Undecided,Unconfirmed]  https://launchpad.net/bugs/119033
[08:30] <mfedyk> ahh, I'm the reporter. :)
[08:32] <Burgundavia> crimsun: I believe that would be your queue
[08:34] <mfedyk> is this the right channel for bug discussion?
[08:34] <mfedyk> or should I go to #ubuntu?
[08:36] <jml> RAOF: btw, I've confirmed that I'll be up in Sydney in July
[08:38] <Hobbsee> jml: yay.  we should have a ubuntu meetup
[08:38] <jml> Hobbsee: for sure.
[08:38] <jml> Hobbsee: I'm not sure if I'll be there for SLUG though
[08:39] <Hobbsee> neither
[08:39] <Hobbsee> but there's a thought
[08:41] <pitti> Good morning
[08:41] <Hobbsee> morning pitti!
[08:41] <pitti> hi Hobbsee
[08:42] <Hobbsee> :)
[08:43] <pitti> ogra: ah, the new edubuntu live images are good size-wise; what did you change?
[08:43] <RAOF> Hobbsee, jml: Yay!  Ubuntu party at my new flat! :)
[08:43] <Hobbsee> RAOF: depends where it is :)
[08:43] <jml> pshaw
[08:43] <jml> as if it matters
[08:44] <RAOF> In the very centre of Sydney, Kensington ;)
[08:44] <jml> it takes 35mins to get anywhere in Sydney
[08:44] <jml> unless it takes longer
[08:44] <RAOF> Profound.
[08:45] <StevenK> The problem is, Kensington is dreadful to get to, public transport or otherwise.
[08:45] <LaserJock> pitti: I believe there was an issue where his seed changes didn't get taken because the publisher wasn't run
[08:45] <Lure> pitti: [Wed Jun 6 2007]  [21:32:49]  <cjwatson> ogra: there were no packages to publish for gutsy (because we're frozen), so the publisher skipped it
[08:45] <LaserJock> pitti: cjwatson found something
[08:45] <LaserJock> ah yeah, that's it
[08:46] <Lure> pitti: [Wed Jun 6 2007]  [21:33:00]  <cjwatson> which meant it didn't apply the germinate changes either
[08:46] <jml> RAOF: I try.
[08:46] <RAOF> StevenK: Sorry, what?  It's on anzac parade, along which there's a bus every minute or so.
[08:46] <Lure> pitti: [Wed Jun 6 2007]  [21:33:41]  <cjwatson> ogra: I've worked around this by accepting a few universe uploads
[08:46] <pitti> Lure: oh, that's black magic;
[08:47] <Lure> pitti: [Wed Jun 6 2007]  [21:34:57]  <cjwatson> I mean, it's something pitti should be told, not necessarily something he should have been expected to know
[08:47] <pitti> Lure: I wasn't aware that live seed changes involve the publisher since cdimage seems to directly check out the bzr branch
[08:47] <Hobbsee> jml: maybe from inside the city, yes.
[08:47] <pitti> Lure: right, I'll talk to cjwatson to have me enlightened
[08:47] <StevenK> RAOF: Okay, public transport from where I live is 40 minutes to the city and 30 minutes from the city to Kensington.
[08:47] <crimsun> mfedyk: -bugs for now.
[08:47] <pitti> Lure: thanks for the heads-up
[08:48] <crimsun> sorry, I was sleeping.
[08:48] <RAOF> StevenK: Right.  As long as you're already in town, Kensington is a snap to get to :)
[09:10] <dholbach> good morning
[09:11] <Hobbsee> morning dholbach!
[09:12] <Hobbsee> anyone know what time it is for stgraber at the moment?
[09:12] <dholbach> heya Hobbsee
[09:12] <dholbach> Hobbsee: it should be 09:12 for him iirc
[09:13] <Hobbsee> right
[09:13] <Hobbsee> thanks
[09:19] <pitti> ogra: I fixed the edubuntu desktop CD versions and re-enabled testing for them in the tracker; go wild :)
[09:26] <fabbione> pitti: i am testing a fix for the sparc kernel right now.... time between bug and fix = 27 minutes + email delivery time :)
[09:32] <pitti> fabbione: amazing
[09:34] <pitti> fabbione: can you please add this to a bug number, so that I have something to link to?
[09:35] <fabbione> pitti: yes. once i verify the fix
[09:35] <fabbione> it won't take too long
[09:49] <keescook> I really should not be awake.  :)
[09:49] <dholbach> keescook: good night!
[09:49] <dholbach> :-)
[09:49] <keescook> hi! just the person I was looking for.  :)
[09:50] <keescook> did you see the changes I committed to python-lp-bugs?
[09:50] <dholbach> no
[09:51] <dholbach> I wondered where they went
[09:51] <keescook> ah, I added the property "duplicate_of" to the Bug class.
[09:51] <dholbach> did you push it to some place? or is it on your local disk?
[09:51] <keescook> as well as subscriber lists and management, and set/clear of private and security flags
[09:51] <keescook> should be pushed, I though.  perhaps I did something wrong?
[09:52] <dholbach> normally we attach a patch to a bug report or link a branch to the bug, so somebody check it before it gets committed
[09:52] <pitti> hey keescook 
[09:52] <keescook> hiya pitti
[09:52] <dholbach> but I can review it if you pushed it, that's fine
[09:52] <dholbach> I just didn't find it
[09:52] <dholbach> I don't think you're in the bughelper-dev team anyway, right?
[09:53] <keescook> I think it was tied to bugsquad, not bh-dev, let me check
[09:53] <dholbach> that branch is abandoned :-/
[09:53] <keescook> oh, fantastic.  :P
[09:53] <dholbach> because we had quite some people just committing to it
[09:53] <dholbach> I'll add you to the team
[09:54] <keescook> thanks.  yeah, I wonder where I found the only bzr path?
[09:55] <keescook> s/only/old
[09:55] <dholbach> http://code.launchpad.net/python-launchpad-bugs
[09:55] <Fujitsu> Hum, gnome-terminal doesn't run on desktop-i386.
[09:55] <keescook> dholbach: should I commit to the main branch or make my own?
[09:55] <Fujitsu> Oh yay, that glib warning that has been floating around for a few days.
[09:56] <dholbach> keescook: you can either attach a patch, or link a branch to the bug
[09:56] <keescook> what's the best way for me to handle the merge?
[09:57] <dholbach> you can try to branch the ~bughelper-dev branch and merge from yours
[09:57] <keescook> can't I just do a "merge"?
[09:58] <dholbach> merge from the bughelper-dev branch?
[09:58] <keescook> right
[09:58] <dholbach> you can try
[09:58] <dholbach> or even try a pull first
[09:58] <keescook> hm, it merged, but I only see a changelog diff
[09:59] <dholbach> weird
[09:59] <dholbach> let me check
[09:59] <dholbach> oh right
[09:59] <dholbach> that's fine
[10:00] <dholbach> I just thought we had more commits to it since the move
[10:00] <dholbach> it's just the changelog diff
[10:00] <dholbach> *phew*
[10:00] <dholbach> let me merge from the old branch and look at your patch
[10:00] <keescook> okay
[10:00] <keescook> :)
[10:01] <keescook> so for future things like this, should I just make a branch on launchpad.net?
[10:01] <dholbach> either that or attach the patch
[10:01] <keescook> okay, cool.
[10:01] <dholbach> we all do cross-review before pushing to the branch
[10:02] <keescook> okay, sounds good.  I will use a branch then; I suspect I will continue to do more work on this.  :)
[10:02] <dholbach> keescook: you ROCK
[10:02] <keescook> thanks!!
[10:02] <dholbach> I guess you'll be in touch with thekorn (#ubuntu-bugs) sometimes then
[10:02] <dholbach> he's doing SoC project on it
[10:02] <dholbach> and is currently re-working the API
[10:03] <keescook> ah, cool.  I see he's got a branch.  what are his goals for it?
[10:04] <dholbach> split the HTMLOperations file into separate files, make the API less bughelper centric, less arguments to constructors, more sense in general
[10:04] <keescook> very cool
[10:04] <dholbach> we worked too quickly on it in the beginning, now it's the time for refactoring :)
[10:04] <dholbach> but I'm very happy with the progress in general
[10:04] <dholbach> keescook: your patch looks very good
[10:04] <keescook> for the security/private stuff I didn't want to have separate "set" routines since the LP interface is a single page.
[10:04] <keescook> dholbach: great, thanks.
[10:06] <dholbach> keescook: thanks again
[10:07] <keescook> dholbach: sure! bdmurray talked about it a great deal when describing his workflow to me, so I figured I might try using it for security bug triage.  works great; much faster than clicking around in LP.  :)
[10:08] <dholbach> ROCK
[10:08] <dholbach> we need more of that on http://wiki.ubuntu.com/BugSquad/Diaries :)
[10:09] <keescook> true.  I worry my bug workflow is rather specific.  *not security* *not security* *not private* :P
[10:09] <dholbach> hehehe :)
[10:10] <keescook> so, the BzrContributorHowto basically says I should make a new branch for every bug/feature that gets worked on.  that doesn't seem sane.
[10:11] <dholbach> I haven't found the optimal workflow yet either
[10:11] <keescook> seems like naming my branch "updates.kees" or something is better for an overall long-term branch
[10:11] <dholbach> it has the advantage of just being able to use     bzr merge URL    to try a patch or to use codebrowse to look at it
[10:12] <dholbach> I don't know if close-bug-by-commit-message already works
[10:12] <dholbach> if so, that'd be another advantage
[10:12] <keescook> true.  with apport, I've just used a separate branch (though my new branch got named poorly)
[10:13] <dholbach> it'd be nice if the bzrlp could do a demo of that or something or explain their longterm vision of it, so we could adapt documentation and train people to make best use of it
[10:13] <keescook> https://code.launchpad.net/apport  <-  hunh, it lists the bugs fixed by an assoicated branch if you link them in LP. neato
[10:13] <pitti> keescook: yeah :)
[10:14] <cjwatson> pitti: livefs images are built by the buildds, i.e. on separate machines from where cdimage checks out the seed branches
[10:15] <pitti> cjwatson: right
[10:15] <keescook> dholbach: I think I will just register a single branch for p-lp-b.  if that turns out to be wrong, I can start doing per-bug branches
[10:15] <cjwatson> pitti: the code there does 'apt-get install minimal^ standard^ ubuntu-desktop^ ubuntu-live^ ...' which installs packages based on Task fields in the archive
[10:15] <pitti> cjwatson: they are checked out straight from bazaar.lp.net?
[10:15] <dholbach> keescook: rock on :)
[10:15] <cjwatson> on cdimage? yes
[10:15] <cjwatson> that only affects packages that go onto the .iso as .debs though
[10:16] <cjwatson> maybe I should draw a honking big diagram at some point :)
[10:16] <pitti> cjwatson: oh, ubuntu-live^ -- I guess that's where the publisher comes into play?
[10:16] <pitti> cjwatson: My missing link was the need of the publisher to propagate live seed changes to the livefs builders
[10:17] <cjwatson> right, exactly
[10:17] <pitti> cjwatson: I still don't understand what and why it does, but at least I'm warned now :)
[10:18] <cjwatson> it actually takes two publisher runs, which is very nasty
[10:18] <cjwatson> the publisher consists of cron.daily which runs cron.germinate at the end
[10:18] <cjwatson> germinate needs an archive to work off
[10:18] <cjwatson> but its output also feeds back into the archive
[10:18] <cjwatson> so it's a bit logically difficult
[10:19] <cjwatson> germinate spits out (among other things) a file for each thing that turns into an archive task with a list of packages in that task
[10:19] <pitti> cjwatson: ok, so whenever we change live seeds, we run the publisher twice and then rebuild the livefs, and live should be good again?
[10:19] <pitti> ah, I see
[10:19] <cjwatson> cron.germinate turns those into an extra override file
[10:19] <cjwatson> which is then used as input to the next publisher run
[10:20] <cjwatson> for the first publisher run, the seeds only need to be in place when cron.germinate runs, and in fact in a pinch you could probably even run cron.germinate independently
[10:20] <pitti> cjwatson: clear now; this made me bite into the table yesterday, since it's rather non-obvious :)
[10:21] <cjwatson> I think it sets all the environment variables it needs for itself
[10:21] <cjwatson> the fact that the publisher does not spot that the extra overrides have changed and republish the affected suites as a result is a bug
[10:21] <cjwatson> cprov and I came up with a plan to fix that, which is relatively straightforward (i.e. implementable by somebody like me)
[10:59] <saispo> argh: d-bus problem in gutsy ?
[11:00] <RAOF> saispo: Not for me?  What sort of dbus problem are you seeing?
[11:00] <saispo> dbus-launch is missing
[11:01] <RAOF> saispo: Deliberate.  It's now in dbus-x11
[11:03] <saispo> RAOF: ok thanks, will relaunch my session
[11:03] <saispo> brb
[11:04] <shawarma> Just a thought: Maybe the installer shouldn't refer to /dev/sd* devices as SCSI harddrives anymore.
[11:05] <fabbione> shawarma: SCSI is not just the hw bus but the protocol you use to talk to the device...
[11:05] <cjwatson> shawarma: yeah, there's a bug about that
[11:05] <fabbione> shawarma:  i see no problem to say we talk SCSI to some ATA devices when the translation is done transparently
[11:05] <shawarma> fabbione: True. Nevertheless, it seems wrong.
[11:06] <cjwatson> I think it should probably just say "storage device" now or something
[11:06] <shawarma> fabbione: Users are going to be confused when their IDE drives are referred to as SCSI.
[11:06] <cjwatson> they are, and they file bugs
[11:06] <cjwatson> particularly when they have both IDE and SCSI, when they get lost and panic
[11:06] <fabbione> shawarma: yeah true that
[11:09] <stgraber> dholbach: it's right I'm at UTC+2, but was at school :(, Hobbsee is UTC+10 right ?
[11:12] <pitti> hi stgraber 
[11:13] <cjwatson> Lure: sorry for my screwup in bug 118967 - see my comment there
[11:13] <ubotu> Launchpad bug 118967 in ubiquity "ubiquity crashed with IndexError in child()" [High,Confirmed]  https://launchpad.net/bugs/118967
[11:14] <Lure> cjwatson: no problem - will do later today (at work now)
[11:15] <dholbach> stgraber: not exactly sure, but your estimation might be right, yes
[11:17] <shawarma> cjwatson: Doesn't ata_id reveal what type of disk it actually is?
[11:19] <shawarma> cjwatson: Hm.. No, it seems not.
[11:27] <Kmos> pitti: hi! you see my mail ?
[11:27] <Kmos> about gqview
[11:27] <pitti> Kmos: I got it, but I don't have time for that right now, sorry
[11:27] <pitti> no other reviewer/sponsor around?
[11:29] <Kmos> pitti: i understand..
[11:29] <Kmos> pitti: that's more hard to find
[11:29] <Kmos> :)
[11:32] <cjwatson> would anyone object to usplash's initramfs script clearing the screen before starting usplash? you can end up with weird cruft left behind otherwise
[11:33] <crimsun> Kmos: I can look, but I'd rather wait til post-Tribe1 since it'd be queued regardless.
[11:33] <pitti> cjwatson: would that also kill scrollback if usplash dies? messages are quite useful for those cases
[11:34] <cjwatson> it would kill anything from before usplash started
[11:34] <sladen> I'm sure the original spec had that usplash should ensure that it didn't destory any messages
[11:34] <Kmos> crimsun: yes, i understand
[11:34] <shawarma> Dear Father Christmas. Please send a faster CPU. kthxbye
[11:34] <cjwatson> right now, when the final login prompt appears on one of my systems, "Kernel alive" is still there at the bottom of the screen
[11:35] <Kmos> crimsun: but you can approve it, and it goes to merges.ubuntu.com, and after tribe1 you can just approve it, right ?
[11:35] <pitti> cjwatson: right, here too
[11:35] <cjwatson> I take sladen's point though. messy.
[11:36] <crimsun> Kmos: if I'm going to go through it, I'd just upload it, but main is frozen for Tribe1.
[11:36] <Kmos> crimsun: ok.. so you can check it and comment :) if it's all ok
[11:36] <Kmos> i've also contacted debain maintainer to notice him about the new version and ubuntu one
[11:37] <Kmos> *debian
[11:38] <fabbione> pitti: #119057 for you as reference
[11:38] <pitti> fabbione: splendid, thanks
[11:39] <fabbione> pitti: it's probably the worst bug report i ever wrote... but enough for you to say it sucks :)
[11:40] <pitti> fabbione: heh, but "itz b0rked, I'll fix it" is still much better than "itz b0rked, kthxbye" :)
[11:46] <fabbione> BZZZZZZZZZT
[11:46] <fabbione> why does mysql ask me for a "root password" at install time?
[11:47] <StevenK> It's trying to hint that you shouldn't use it.
[11:47] <shawarma>   * Bump the priority of the debconf prompt for the root password to high, to 
[11:47] <pitti> <jedi wave>PostgreSQL!</jedi wave>
[11:47] <shawarma>     ensure the question shows up in a default installation (closes: #418672).
[11:48] <shawarma> fabbione: ^^ from 5.0.41-1 changelog.
[11:48] <pitti> shawarma: bugger, that means we have to deviate again
[11:48] <fabbione> and it asks for it only once
[11:48] <fabbione> so that means if you type it wrong, you are doomed
[11:49] <pitti> gosh, I was so happy when we could finally sync this beast again
[11:49] <fabbione> anyway it's not a blocker for Tribe-1
[11:49] <fabbione> shawarma: want to take care to fix it?
[11:49] <shawarma> I just did a server install and it didn't ask me.. Is the installer threshold for questions perhaps critical?
[11:49] <StevenK> pitti: <jedi wave>MySQL is not the database you are looking for.</jedi wave>
[11:50] <shawarma> fabbione: Sure.
[11:50] <fabbione> shawarma: did you install LAMP?
[11:50] <shawarma> fabbione: Remember what it used to be? medium? 
[11:50] <shawarma> fabbione: Yes.
[11:50] <pitti> StevenK: right
[11:50] <fabbione> shawarma: i did install clean LAMP.. no changes in the debconf priority
[11:50] <shawarma> fabbione: Um... So did I.
[11:50] <shawarma> fabbione: Well, lvm+lamp.
[11:51] <fabbione> shawarma: gutsy.. you need to use gutsy install cd's.. not feisty :P
[11:51] <shawarma> fabbione: But that *really* shouldn't matter. :)
[11:51] <fabbione> yeah so did i
[11:51] <ogra> pitti, testpage updated
[11:51] <shawarma> Um... That's pretty odd. :)
[11:52] <fabbione> BZZT
[11:52] <fabbione> something did try to mount usbfs and failed.. on a server install... hmm
[11:52] <cjwatson> shawarma: no, installer threshold is high
[11:53] <fabbione> oh just details
[11:53] <shawarma> cjwatson: Mkay...
[11:53] <fabbione> the install looks good
[11:53] <shawarma> Gah... VirtualBox won't boot the server kernel.
[11:53] <cjwatson> unless you're using warty ;-)
[11:53] <shawarma> cjwatson: :)
[12:06] <Mithrandir> mjg59: any chance you could look at https://wiki.ubuntu.com/power-management-in-Ubuntu when you have the time?
[12:07] <shawarma> fabbione: I can't imagine why it didn't ask me for that password. Any bright ideas?
[12:08] <Kmos> tribe1 would have php 5.2.3 ?
[12:08] <fabbione> shawarma: try to reinstall? did you return without noticing?
[12:09] <shawarma> fabbione: I haven't tried reinstalling yet, and I suppose it's possible that I didn't notice.. I'd say it's unlikely, though. 
[12:16] <Mithrandir> Kmos: no
[12:18] <Kmos> which version ?
[12:19] <Mithrandir>       php5 | 5.2.2-1ubuntu1 |         gutsy | source, all
[12:25] <Kmos> :-)
[12:25] <Kmos> thx
[12:40] <pitti> fabbione: TBH I'd leave the prompt until we have a really good solution for this
[12:41] <pitti> fabbione: right now, every user can log in as mysql root without a password, including exploits in webapps
[12:41] <pitti> fabbione: I would prefer a pam user id matching and disabling the password entirely by default, but that doesn't seem to be possible with Mysql?
[12:42] <StevenK> That's right, MySQL doesn't touch PAM.
[12:42] <pitti> bugger
[12:43] <asac> pitti: thunderbird_2.0.0.4~rc1-0ubuntu1 is uploaded now
[12:43] <pitti> do you need the old password if you set a new one as root?
[12:43] <StevenK> Just thinking about it, I can't come up with a solution that is elegant.
[12:43] <pitti> setting it to an invalid value and documenting that you have to run 'sudo mysqladmin password blabla' first would be better
[12:44] <shawarma> pitti: Yes, you need the current password to change it.
[12:44] <pitti> shawarma: but, but, if you are root, there should be a way, right? :-)
[12:45] <Kmos> pitti: i think with root you can reset it
[12:45] <pitti> shawarma: what would be architecturally wrong with not requiring the old password if you change the passwd on the local server as root?
[12:45] <shawarma> pitti: The workaround (e.g. if you forgot your password), you need to restart myql with some option to make it ignore the current password.
[12:46] <pitti> shawarma: can you please file this as a bug so that we have a permanent record of the discussion? I'll milestone it appropriately
[12:46] <shawarma> pitti: Will do.
[12:46] <Kmos> http://www.tech-faq.com/reset-mysql-password.shtml
[12:46] <StevenK> Ewww
[12:47] <shawarma> --skip-grant-tables ftw!
[12:47] <pitti> ouch++
[12:48] <pitti> . o O { 'if (!geteuid() && host == 'localhost') auth=True; else auth=ask_password(); }
[12:48] <pitti> there's nothing you can hide from root anyway
[12:49] <StevenK> Except if the password is crypted...
[12:49] <pitti> shawarma: maybe that should even be forwarded upstream
[12:49] <pitti> StevenK: right, I don't mean showing the password in cleartext, but circumventing it
[12:49] <pitti> shawarma: they might like a better solution to that hack as well
[12:49] <StevenK> pitti: Oh, right.
[12:50] <pitti> StevenK: it would only matter if the mysql tables were encrypted with the root password, which is not the case
[12:50] <StevenK> pitti: It looks geser and myself have finished hacking requestsync. Shall I just throw it into devscripts and upload it?
[12:51] <pitti> StevenK: sure, if you are happy with it, go ahead; won't make it to the archive before thawing gutsy, of course
[12:51] <StevenK> pitti: I was pondering a bzr branch for devscripts.
[12:57] <pitti> ogra: how happy are you with the current edubuntu CDs?
[12:57] <ogra> i'm fie
[12:57] <ogra> *fine
[12:58] <pitti> ogra: amd64 CDs didn't get a single test so far; they should at least be checked for bootability
[12:58] <ogra> ok, i can do that 
[12:58] <ogra> i'll notify you 
[01:03] <pitti> ogra: do you care about the server addon CD?
[01:03] <ogra> not yet
[01:03] <pitti> ogra: I just updated the image greenishness on the iso tracker, most is good now
[01:03] <ogra> its fine to hear some respnse
[01:03] <ogra> but it will change a lot before i want testing
[01:03] <pitti> ogra: ok, they are not essential for installation, right?
[01:03] <ogra> right
[01:03] <pitti> ogra: ok, so let's not waste time on it now, shall we?
[01:04] <ogra> they have only a package archive and app-install data
[01:04] <ogra> right
[01:05] <pitti> ogra: ok, so you'll care about edubuntu server/desktop amd64 quick test, I'll sort out the mirroring and pre-release preps, and then we pop the trunk?
[01:06] <ogra> yup
[01:06] <fabbione> pitti: i don't know mySQL auth code at all, but that's why we have a server team to ask to fix :)
[01:07] <ogra> xubuntu and kubutu are good already ?
[01:07] <pitti> fabbione: indeed, that's what my gentle comments suggested :)
[01:07] <pitti> ogra: yep
[01:07] <fabbione> pitti: ehehhe
[01:07] <ogra> cool
[01:09] <shawarma> pitti: #119075
[01:10] <pitti> shawarma: great, thanks
[01:34] <pitti> fabbione: does the sparc CD work on at least some machines?
[01:34] <fabbione> pitti: it might.. 
[01:35] <fabbione> pitti: the problem is that the pci resource that is not init can be totally random
[01:35] <fabbione> pitti: in my case was the bridge before the CD
[01:35] <fabbione> pitti: for others might be something else
[01:35] <fabbione> pitti: like.. dunno.. I/O controllers? network?
[01:35] <StevenK> Random per boot, or per machine?
[01:35] <fabbione> per machine/per OBP version
[01:36] <fabbione> constant is that affects only PCI
[01:36] <pitti> fabbione: ok; so let's publish it, maybe someone is lucky; thanks
[01:36] <fabbione> pitti: really.. we agreed not to.. and it's probably best that way
[01:36] <fabbione> and we don't want to be flooded for tha
[01:36] <fabbione> that
[01:37] <fabbione> it will take longer to close all the bugs than to just skip it
[01:38] <pitti> fabbione: alright; I revert that image then
[01:42] <StevenK> Hah.
[01:42] <StevenK> pitti: I've got requestsync looking up the component in Debian, as well.
[01:42] <StevenK> "Please sync flashplugin-nonfree (multiverse) from Debian unstable (contrib)."
[01:43] <pitti> StevenK: cool
[01:43] <talmid> hello
[01:45] <talmid> anyone can help me with my apt-pinning problem? Unless I can ask in here? #ubuntu is too noisy and my problem has been buried.
[01:47] <persia> talmid: This really isn't a support channel.  If #ubuntu is too busy, consider trying again at a less busy time, or opening a support request from https://answers.launchpad.net/ubuntu/.
[01:49] <talmid> persia: I am not asking for support in here. I am asking if someone could contact me to help me. It must be doing something basic wrong and a second pair of eyes would fix the problem
[01:49] <talmid> persia: well unless I get permission from the channel to ask for support in here
[01:50] <gnomefreak> !pinning > talmid  ( please read the docs ubotu sent you and please ask in #ubuntu if you have further questions)
[01:50] <pitti> ogra: so do you want the addon CD published at all? it looks as if we should just skip it for now
[01:50] <talmid> gnomefreak: mind if I highlight you in #ubuntu. I have asked a few times and got no response?
[01:52] <ogra> pitti, well, since its identcal to the feisty one i wouldnt mind publishing it either ... doesnt matter, do as you like
[01:53] <pitti> ogra: ok, everything prepared for release, except copying the edubuntu CDs
[01:54] <StevenK> pitti: Would you mind holding off for 2 hours and 10 minutes? Then I get Tribe 1 for my birthday. :-P
[01:54] <shawarma> re
[01:55] <Mithrandir> I think he should hold it off until tomorrow, or at least 00:01 :-P
[01:55] <StevenK> 00:01 in which timezone? :-)
[01:55] <Mithrandir> CEST
[01:55] <StevenK> Heh
[01:58] <StevenK>  1 file changed, 69 insertions(+), 38 deletions(-)
[01:58] <StevenK> Poor requestsync.
[02:00] <StevenK> pitti: It occurs to me that we should probably put a licence on requestsync.
[02:00] <pitti> StevenK: might happen if you are lucky, and testing/website preps still take that long
[02:00] <pitti> StevenK: heh, GPL or public domain, I figure
[02:00] <StevenK> pitti: I'm happy with GPL if you are.
[02:00] <pitti> sure
[02:02] <pitti> ogra: I already prepare the publishing of the edubuntu CDs, btw, since it's likely that they work and it's easy to roll back (I didn't sync mirrors yet)
[02:03] <StevenK> pitti: Can I PM you what I just added?
[02:03] <pitti> StevenK: the entire diff? pastebin might be better than IRC flood
[02:03] <StevenK> pitti: No, the 3 lines for licence stuff
[02:03] <shawarma> pitti: Setting a bogus password on mysql-server is a bad idea, I think. The server's useless as long as it's set that way, so instead of being asked in a nice debconfy way for a password, the user will need to dig out the command line to change the password from some readme file or something.
[02:03] <pitti> StevenK: oh, sure
[02:04] <pitti> shawarma: *shrug* personally I think debconf is fine, but we have a certain policy for that; not sure whether we should be as strict for that server install, though
[02:05] <shawarma> {rules,policies,laws} are meant to be broken :)
[02:05] <StevenK> You could always randomly generate it, and store it in debconf.
[02:05] <StevenK> Document how to get at it with debconf-communicate.
[02:06] <StevenK> That neatly causes debconf-is-not-a-registry, though
[02:06] <shawarma> Sounds nasty, if you ask me.
[02:06] <pitti> shawarma: still, if someone doesn't see the debconf question, then it's better to RTFM how to set the password than to leave it wide open IMHO
[02:07] <pitti> shawarma: and as soon as mysql doesn't ask your password any more when being run as root, it doesn't matter so much, right?
[02:07] <pitti> shawarma: webapps shouldn't connect as admin user anyway
[02:08] <shawarma> pitti: I suppose.
[02:08] <StevenK> They shouldn't connect as root at all, IMO
[02:08] <StevenK> I *much* prefer how PostgreSQL handles this.
[02:08] <pitti> right, except for setting password and administering users, AFAICS
[02:08] <pitti> StevenK: so do I :)
[02:09] <persia> pitti: While I agree with you, it does break separation of server administrator and database administrator, which may be a violation of some compliance policies.
[02:09] <pitti> persia: how so?
[02:09] <StevenK> persia: In large organisations, they are completly seperate.
[02:09] <pitti> persia: if you are the server admin (root), then you can control the server daemons, no matter what passwords they user
[02:10] <pitti> s/r$//
[02:10] <persia> If mysql allows anyone with root access to access mysql without checking the password, the server administrator would not be prevented from adjusting the database.
[02:10] <pitti> persia: you cannot prevent him from doing that anyway
[02:10] <StevenK> persia: It does, it just needs to be started with '--skip-grant-tables'
[02:10] <StevenK> persia: I know a guy who has an ssh key to the DB machines and sudo rights to postgres. Only.
[02:11] <persia> pitti: I suppose.  root is fairly powerful.  Oh well, at that point it's just policy and auditing.
[02:11] <pitti> persia: sure
[02:11] <pitti> persia: and it's also pretty independent of the 'no password by default' problem
[02:12] <persia> pitti: That's why I started with "I agree with you" :)  I'm only commenting on possible downsides of the proposed solution, but any solution is better than the current situation.
[02:12] <shawarma> pitti: I'm not sure it's even possible to make it so that root doesn't have to authenticate. It's the client that would have to detect it, but the server that would have to enforce it..
[02:13] <shawarma> I'll file an upstream bug..
[02:13] <pitti> shawarma: true that
[02:13] <pitti> shawarma: the server would need to check the credentials of the client; postgresql does that
[02:13] <StevenK> 'ident trust' FTW
[02:13] <shawarma> pitti: how?
[02:13] <shawarma> Oh.
[02:14] <pitti> shawarma: and this also ensures that it's a local connect, since you cannot do that with IP
[02:14] <shawarma> So if it's a local connect, it checks if the connecting process is run by the same uid as the serveR?
[02:16] <pitti> shawarma: with unix sockets there is a function to get the peer uid
[02:16] <pitti>         if (getsockopt(sock, SOL_SOCKET, SO_PEERCRED, &peercred, &so_len) != 0 ||
[02:16] <pitti>                 so_len != sizeof(peercred))
[02:16] <pitti>         {
[02:16] <pitti>                 /* We didn't get a valid credentials struct. */
[02:17] <shawarma> pitti: Oh, really? 
[02:17] <pitti>         uid = getpwuid(peercred.uid);
[02:17] <pitti> "struct ucred peercred", BTW
[02:17] <pitti> shawarma: yep, that's pretty handy, used in e. g. dbus as well
[02:17] <shawarma> pitti: *very* handy.
[02:18] <pitti> shawarma: that's how postgresql does the PAM user/db user matching
[02:18] <shawarma> Hm... I wonder where my trusty IPC book has gone.
[02:18] <shawarma> pitti: Makes sense.
[02:18] <pitti> shawarma: man unix(7) is pretty good
[02:19] <StevenK> pitti: In unix(7)
[02:19] <StevenK> Under SOCKET OPTIONS
[02:20] <shawarma> It says PASSCRED
[02:20] <pitti> StevenK: right, PASSCRED, but not PEERCRED
[02:20] <torkel> socket(7) ?
[02:20] <StevenK> Oh right, sorry. I should learn to read at some point.
[02:21] <StevenK> Yup, socket(7)
[02:31] <Kmos> at my Acer 5633WLMi (https://wiki.ubuntu.com/LaptopTestingTeam/AcerAspire5633WLMi) the latest kernel for feisty, start with PCI: Failed to allocate memory
[02:32] <Kmos> it works fine, but has that message
[02:33] <Hobbsee> heya all
[02:33] <Hobbsee> mmm...we have power!  :)
[02:35] <coastGNU> Is there a way to get a preseed file as result of an oem-install? 
[02:39] <coastGNU> cjwatson: Colin, ping
[02:43] <Kmos> how to test Cpu frequency scaling on my laptop ?
[02:46] <pygi> fabbione, you've got mail
[02:46] <Hobbsee> Kmos: sounds like a #ubuntu type of questoin
[02:49] <Kmos> Hobbsee: ok
[02:50] <pitti> BenC: when I run /usr/share/apport/testsuite/test-apport kernel on 6.13, it immediately dies with 'does not leave core file behind'
[02:51] <BenC> pitti: what does that message mean, that no core was read from stdin?
[02:53] <pitti> BenC: the assert message is the wrong way around, it should be 'does leave core file'
[02:53] <pitti> BenC: I get a 0-byte 'core' file in the dir I run this in
[02:53] <pitti> BenC: not sure why; let me disable that test
[02:55] <pitti> BenC: indeed, most stuff seems to work when I disable this (it breaks at a later stage with 'cannot access memory', but I need to investigate that)
[02:56] <pitti> BenC: so it seems to open the core file already before diverting it to stdout?
[02:57] <pitti> ogra: any update?
[03:05] <cjwatson> coastGNU: same instructions apply as to the regular alternate install; see the installation guide
[03:11] <pygi> Zdra, poke, did that thing work for you? :)
[03:12] <Zdra> pygi: what thing ?
[03:12] <pygi> Zdra, the conversion script?
[03:12] <coastGNU> cjwatson: Hhhm, not exactly what Im looking for. What I would like to have is a preseed file to remaster the cd so that a user will only asked what is asked in the first boot after oem-config-prepare
[03:13] <Zdra> didn't looked yet, I had an exam this morning and I'm studying the next one atm :)
[03:13] <coastGNU> cjwatson: So my first idea was , It would be good to have somekind of logfile which may be used to set up a preseed file
[03:14] <pygi> Zdra, ah, oki. 6 exams next week here :(
[03:14] <pygi> how did it go?
[03:15] <Zdra> was easy :)
[03:15] <cjwatson> coastGNU: the way oem-config is intended to be used is that you install it once and clone the resulting disk image
[03:15] <cjwatson> not the CD
[03:15] <pygi> hehe, good for you Zdra :p
[03:15] <pygi> I don't think 6 exams for me will be easy :p
[03:16] <Zdra> pygi: good luck ;)
[03:16] <pygi> thanks, I'll need it ;)
[03:17] <coastGNU> cjwatson: I know about that. But what if there is need for a 'restore installation cd'? And thats what I like to have, and I bet a lot of oems also. :-)
[03:17] <cjwatson> coastGNU: I'm afraid that's very much a roll-your-own at the moment :-(
[03:18] <cjwatson> coastGNU: debconf-get-selections --installer after installation may provide a starting point though
[03:21] <coastGNU> cjwatson: Ahh, used dpkg --get-selections so far, didn't know about debconf-get-selections so far. I will have a closer look. Thanks a lot so far. cu
[03:23] <coastGNU> cjwatson: Arrgl, never wrote a sofar'ish sentence so far. Time to have a coffee...
[03:37] <pitti> fabbione: tribe-1 images are up, so certification testing can begin; do you need a more formal notification?
[03:54] <gnomefreak> is OO.o merged/synced from debian or is it something we build on our own?
[03:55] <StevenK> Merged, if I recall correctly.
[03:56] <gnomefreak> StevenK: we must drop thier changes than. they have a plugin built with OO.o that we seem not to have as i am hearing
[03:57] <pitti> heno: do we actually want people to report tests on isotest after the tribe-1 release? or should we maybe just completely skip that paragraph and keep it for a later tribe or beta?
[03:58] <StevenK> gnomefreak: File a bug/talk to doko.
[03:58] <fabbione> pitti: no, just send out the announcement. That's the official trigger to start the timer
[03:58] <heno> pitti: you can skip it and we'll make a more explicit process for tribe-2
[03:58] <gnomefreak> im filing the bug for someone he will fill in the info after ;)
[03:59] <pitti> heno: makes sense, thanks
[03:59] <heno> I'll set up the tribe images there anyway, but will just encourage people who are already familiar with it to use it
[03:59] <heno> It's good for developing the tracker itself if nothing else
[04:01] <fabbione> pygi: got the mail.. will do tomorrow
[04:01] <pygi> fabbione, oki
[04:17] <pitti> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007-June/000301.html
[04:17] <pitti> *drums*
[04:17] <ogra> \o/
[04:17] <StevenK> Oh yes! Tribe 1 for my birthday. \o/
[04:17] <mc44> pitti: nice quote :) Next time you can use the lyrics from The Funky Gibbon :)
[04:17] <pitti> StevenK: happy birthday!
[04:17] <StevenK> pitti: Thanks!
[04:18] <fabbione> pitti: congratulation on your first release
[04:18] <fabbione> pitti: well done
[04:18] <pitti> fabbione: thank you
[04:18] <pitti> thanks to all of you who were involved
[04:21] <pochu> Yay for the release! :)
[04:21] <Hobbsee> pitti: have you recovered yet?  :P
[04:21] <pitti> Hobbsee: sure, let's release tribe-2; should be fairly smooth ATM :)
[04:21] <pochu> Oh, and StevenK and Mithrandir, happy birthay :)
[04:21] <pitti> pochu: not yet for Tollef :)
[04:21] <pochu> pitti: depends in what part of the world :p
[04:22] <Hobbsee> when's Mithrandir's birthday?
[04:22] <pochu> I guess tomorrow
[04:22] <pitti> tomorrow, in 8-some hours
[04:22] <pochu> But today in Japan ;)
[04:22] <StevenK> pochu: Thanks!
[04:23] <Hobbsee> so today then
[04:23] <pochu> Oh, Tribe 5 is on my Birthay :-)
[04:23] <StevenK> Heh
[04:23] <StevenK> I started a trend, it appears.
[04:27] <Lure> cjwatson: added debug file to bug 118967 - hope it helps
[04:27] <ubotu> Launchpad bug 118967 in ubiquity "ubiquity crashed with IndexError in child()" [High,Confirmed]  https://launchpad.net/bugs/118967
[04:29] <pitti> mc44: thanks for that pointer
[04:33] <pitti> hm, what's that old crap on -changes@
[04:36] <elmo> I moderated them through
[04:36] <elmo> they were incorrectly moderated before the X-Katie hack got applied
[04:37] <elmo> seemed better to have them recorded for posterity/google, even if it is confusing having them turn up so late
[04:58] <pochu> pitti: I've found a reproducible crash in xqf, but it's giving a backtrace and the memory map to stdout. Is there a reason why apport isn't taking it?
[05:00] <pitti> pochu: apport frontend is still disabled by default in update-notifier
[05:16] <ssam> are there tribe 1 for powerpc isos, i can't find them on the cdimage server
[05:23] <Hobbsee> ssam: under /ports, probably?
[05:32] <ssam> Hobbsee, thanks, but i have already tried there ports/releases/ only has up to feisty
[05:41] <cjwatson> may just not have released it
[05:42] <cjwatson> it's certainly built and in ports/daily{,-live}/
[05:42] <cjwatson> if you're desperate, you can grab it from there
[05:53] <ssam> cjwatson, thanks
[05:56] <statik> is it valid to try doing an upgrade to tribe1, or do I need to do a clean install?
[07:30] <simira> good night, Hobbsee 
[07:30] <simira> (seems like everyone left before you :p )
[07:30] <Hobbsee> so it seems
[08:34] <robertj> gnome-system-tools-2.18.1/src/shares/Makefile has CFLAGS = -g -Wall -O2, does that mean it should be compiled with debugging symbols? and if so, why does gdb complain that it doesn't have them when running the resulting executable
[09:03] <geser> it's build with debugging symbols but they are split out during package build
[09:04] <robertj> geser: i'm running it in-place in the shares directory
[09:07] <DexterF> hi
[09:08] <DexterF> I noticed for some reason subfs/submountd is not in 7.04. compiling it myself failed. where canI file a request?
[09:44] <LaserJock> I need a core-dev to sponsor a merge of lintian, any volunteers?
[09:54] <crimsun> LaserJock: url to debdiff?
[09:54] <LaserJock> crimsun: http://tiber.tauware.de/~laserjock/lintian_1.23.31ubuntu1.debdiff
[09:55] <LaserJock> crimsun: that's a debdiff from the Debian sid source. I've added in a piece that will get rid of NMU warnings for Ubuntu packages
[09:55] <crimsun> LaserJock: but not *-security?
[09:55] <LaserJock> crimsun: so I'd appreciate a check of my perl on that
[09:56] <LaserJock> crimsun: hmm? Debian -security or Ubuntu -security?
[09:56] <crimsun> the latter
[09:57] <LaserJock> it just checks for "ubuntu" in the version and turns of NMU if that's the case
[09:57] <LaserJock> it's simple
[09:57] <LaserJock> I'm mostly just trying to get it so MOTU contributors don't always freak out over the NMU warnings
[09:58] <crimsun> right, that part seems fine
[09:58] <crimsun> I'm just wondering what the rationale for skipping Ubuntu's *-security (since *-{proposed,updates,backports} are covered)
[09:59] <crimsun> is
[09:59] <LaserJock> oh
[09:59] <LaserJock> security is already in there
[09:59] <LaserJock> from Debian
[09:59] <crimsun> ok blarg, silly Web browser
[09:59] <crimsun> no wonder, debdiff didn't finish loading due to local proxy
[10:04] <crimsun> LaserJock: What do you plan to do with -build suffixes?
[10:04] <LaserJock> nothing
[10:04] <LaserJock> I wanted to keep low divergence and the idea was to minimize NMU warnings for us
[10:05] <LaserJock> we don't do a lot of -build uploads
[10:06] <crimsun> done.
[10:06] <LaserJock> we can always tweak it later
[10:07] <LaserJock> I just figured it was fairly straightforward to get rid of the bulk of those
[10:07] <LaserJock> that's pretty much one of the first things people ask in #ubuntu-motu when they're learning to patch/debdiff
[10:47] <LaserJock> is gfxboot installed by default in gutsy?
[10:49] <cjwatson> LaserJock: gfxboot has never been installed by default, only used on the CDs
[10:49] <LaserJock> cjwatson: interesting, thanks
[10:52] <pochu> pitti: re: apport: but there's no crash in /var/crash, and it should be even if the frontend is disabled, right?
[10:53] <pitti> pochu: right
[10:53] <pochu> Might it be xqf? It's printing the traceback and the memory map into the terminal.
[10:53] <pitti> pochu: the gutsy kernel still has problems with apport, that can be it, too
[10:53] <pochu> Ok
[10:53] <pitti> pochu: ah, right, it probably has its own crash handler then
[10:54] <pitti> pochu: check /var/log/apport.log
[10:54] <pitti> if it was called at all
[10:54] <pochu> It wasn't, though some other apps were.
[10:54] <pochu> I'll file a bug upstream then, with the terminal output.
[10:55] <pochu> Thanks for the help :)
[11:10] <nn-ds> hi
[11:14] <nn-gentoo> hi
[11:24] <joeamined> hi
[11:25] <joeamined> was the linux kernel bug "pci failed to allocate mem resource"
[11:25] <joeamined> that happends in linux-source-20 in many laptops
[11:25] <joeamined> been fixed in linux-source-22 in gutsy ?