[00:40] <igc> bbiab
[00:45] <mubasher> hi
[02:14] <mrbig> Is there any mechanism for handling hook script in bzr? For example: I want bzr send me a email when somebody commits his change. ( same function as CVSROOT/loginfo or commitinfo)
[02:15] <beuno> mrbig, there is a plugin that does that in: http://bazaar-vcs.org/BzrPlugins
[02:16] <mrbig> beuno: thx, I check it now
[02:16] <beuno> mrbig, :D
[02:16] <mrbig> ;)
[02:59]  * igc lunch & some xmas shopping - bbl
[03:19] <bac> mrbig: hi nhan!
[04:01] <mrbig> opps
[04:01] <mrbig> Hi bac
[04:01] <mrbig> :)
[04:01] <bac> mrbig: i just came here to find an answer for you but saw you had already done so.  i hope one of those plugins works for you.
[04:02] <mrbig> bac: I'm playing with this
[04:02] <mrbig> bac: bzr is really cool
[04:03] <bac> mrbig: great!  i hope it works out for you!
[04:05] <mrbig> bac: yeah, I've told my team try to use it already. We'll have a small internal presentation about bzr tomorror
[04:06] <bac> mrbig: i look forward to hearing how that goes.  will you be at the LUG dinner tomorrow night?
[04:08] <mrbig> bac: I don't know about it, it's a weekly cafe I guess
[04:11] <mrbig> bac: ah just got email, sure I'll come
[04:16] <ubotu> New bug: #177592 in bzr "Commit fails after reconfiguring from light- to heavy-checkout" [Undecided,New] https://launchpad.net/bugs/177592
[05:12] <poolie> http://sourcefrog.net/tmp/bzrsite-draft/
[05:12] <poolie> hi bac
[05:12] <poolie> retro r us
[05:13] <jml> quick, publish it!
[06:01] <ubotu> New bug: #177605 in bzr-cvsps-import "module help too bare bones" [Undecided,New] https://launchpad.net/bugs/177605
[06:01] <ubotu> New bug: #177606 in bzr-cvsps-import "no install guide" [Undecided,New] https://launchpad.net/bugs/177606
[06:06] <ubotu> New bug: #177607 in bzr-cvsps-import "no setup.py" [Undecided,New] https://launchpad.net/bugs/177607
[06:45] <thumper> can someone tell me a more friendly name for branch format: Bazaar Knit Repository Format 4?
[06:45] <bac> poolie: hi
[06:47] <abentley> thumper: It's the repository format used in "rich-root".
[06:48] <thumper> abentley: ah, thanks, is this provided through a plug-in?
[06:48] <abentley> No, it's in Bazaar 1.0
[06:48] <spiv> thumper: no, it's part of 1.0
[06:49] <thumper> thanks
[06:49]  * thumper expects LP errors to go away then
[06:49] <thumper> abentley: isn't it almost 2am for you?
[06:50] <abentley> Yep.  Just off to bed.
[06:50] <thumper> :)
[06:50] <thumper> night
[07:15] <ubotu> New bug: #177613 in bzr "Crash when merging" [Undecided,New] https://launchpad.net/bugs/177613
[07:19] <poolie> ok, i'm going away for a while
[07:19] <poolie> see you later
[07:20] <bac> poolie: hi...
[07:20] <bac> poolie: give me a shout when you get back. i see you pinged when i was out for lunch
[07:21] <poolie> mm
[07:21] <poolie> not that i remember
[07:21] <poolie> i'm leaving for the holidays tomorrow
[07:21] <poolie> have a good holiday
[07:21] <bac> poolie: 00:12:39 hi bac
[07:21] <poolie> i was just saying hello
[07:22] <bac> ah, ok.  hello and good bye.  :)
[09:02] <igc> poolie: if you're still online, have a good holiday, xmas and New Year.
[09:02]  * igc dinner
[09:14]  * quicksilver thinks everyone should have a good holiday xmas and new year, including but not restricted to poolie
[09:15] <fullermd> Sorry, there's only one good holiday to go around this year, and it's already been assigned to poolie...
[09:17] <quicksilver> ah well, I'm off to poolie house to bask in reflected happiness, then
[09:39] <mwhudson> do tracebacks like
[09:39] <mwhudson>   File "<string>", line 4, in set_last_revision_info_write_locked
[09:39] <mwhudson>   File "/srv/sm-ng/production/launchpad/sourcecode/bzr/bzrlib/branch.py", line 1412, in set_last_revision_info
[09:39] <mwhudson>     assert len(history) == revno, '%d != %d' % (len(history), revno)
[09:39] <mwhudson> AssertionError: 1368 != 1370
[09:39] <mwhudson> look familiar to anyone here?
[09:40] <jelmer> I've seen it before, yes
[09:40] <jelmer> not sure what causes it though
[09:42] <mwhudson> it is currently screwed up mirrored branches on launchpad
[10:59] <spiv> jelmer: I can reproduce it with: http://pastebin.com/m189c0ec9
[11:00] <jelmer> that branch may have been modified by .dev versions of bzr
[11:02] <spiv> Reconciling the local copy and reconciling the source to pull --overwrite from doesn't fix it.
[11:05] <spiv> Upgrading the local branch to rich-root format fixes the problem.
[11:10] <mwhudson> spiv: upgrading to dirstate-tags is enough
[11:10] <mwhudson> i really think it must be revision-history vs last-revision
[11:11] <spiv> Right
[11:11] <mwhudson> and so it's probably not as bad as i thought: it's only breaking mirroring of all dirstate branches on lp
[11:14]  * spiv wonders why _lefthand_history is disagreeing with revision_history
[11:14] <mwhudson> oh, it's not even that bad
[11:14] <spiv><EMAIL_ADDRESS>is the revision it's omitting.
[11:14] <mwhudson> although there are 2278 failures today
[11:15] <mwhudson> it is actually only 13 branches that are failing
[11:16] <mwhudson> for some reason they are not being marked as failing, and are being attempted every time the puller runs
[11:21] <spiv> Hmm!:
[11:21] <spiv> $ bzr revno
[11:21] <spiv> 37
[11:21] <spiv> $ bzr revision-history | wc -l
[11:21] <spiv> 36
[11:21] <mwhudson> well, that looks bad
[11:21] <spiv> Indeed.
[11:22] <spiv> That's after upgrading to dirstate-tags.
[11:22] <mwhudson> i suspect that we're hitting an old, maybe unreleased, bzr bug that's lead to bogus data
[11:22] <spiv> If I leave it in the original format, they're both 37.
[11:22] <spiv> Yeah.
[11:22] <mwhudson> does 'bzr check' pass in both branches?
[11:23] <spiv> The disagreement is basically that<EMAIL_ADDRESS>is sometimes in the revision-history, and it shouldn't be, because it's not a mainline revision I think.
[11:24] <spiv> mwhudson: it does in the original
[11:24] <spiv> It also passes in the dirstate-tags branch
[11:24] <mwhudson> feh
[11:24] <spiv> (despite "45 inconsistent parents", which reconcile can fix)
[11:32] <spiv> jelmer: deleting<EMAIL_ADDRESS>from your .bzr/branch/revision-history corrects the problem
[11:32] <spiv> jelmer: I think...
[11:32] <spiv> jelmer: I'm fairly sure that's correct.
[11:33] <spiv> Current bzr probably ought to give a better error than an assert for this case.
[11:33] <jelmer> ok
[11:34] <spiv> mwhudson: I need to stop for the night, can you file a bug and make sure jam knows about it
[11:34] <spiv> mwhudson: maybe even mail the list.
[11:34] <spiv> jelmer: Please keep a copy of the branch as is, though :)
[11:34] <jelmer> ok, I'll just leave ti for now
[11:34] <spiv> jelmer: thanks!
[11:35] <jam> mwhudson: bzr pull --overwrite . should fix it
[11:35] <jam> What is happening is that history was not normalized on one side
[11:35] <spiv> We should make "bzr check" check that .bzr/branch/{revision-history,last-revision} is correct
[11:35] <spiv> jam: great timing
[11:36] <jam> spiv: you pinged my name :)
[11:36] <mwhudson> hello jam!
[11:36] <spiv> jam: it's amazing what technology can do :)
[11:36] <jam> It used to happen in bzr pre 0.8 or so
[11:36] <jam> and it just sort of stayed there for a long time
[11:36] <mwhudson> 'bzr.dev pull --overwrite .' crashes too
[11:36] <spiv> (And we should make "bzr reconcile" fix it)
[11:37] <jam> well, internally it is
[11:37] <jam> b = bzrlib.branch.Branch.open('.')
[11:37] <spiv> Anyway, that's it for me for the night.
[11:37] <jam> b.generate_revision_history(b.last_revision())
[11:38] <jam> spiv: good night
[11:38] <jam> mwhudson: it happened in a recent patch to just call "set_last_revision"
[11:38] <spiv> jam: sounds like an easy thing to teach bzr check/reconcile... ;)
[11:39] <jam> spiv: should be fairly trivial
[11:39]  * spiv -> zzz
[11:39] <jam> part of the problem is that we are trusting the source branch to have the correct revno and last revision
[11:40] <jam> But there seem to be a lot of Branch5 out there with incorrect revision-history
[11:40] <mwhudson> anyway, the problem is nowhere near as bad as i feared
[11:40] <jam> yeah, we just used to allow you to pick any path through history you wanted
[11:40] <jam> but we moved away from that
[11:41] <jam> mwhudson: are you willing to put together a patch for check & reconcile?
[11:41] <mwhudson> jam: not right now
[11:41] <fullermd> Speaking of reconcile, there's something there that bugs me...
[11:41] <fullermd> It seems like 'reconcile' always takes longer than 'check', even when there's nothing to do.
[11:41] <mwhudson> jam: i want to fix the two problems that made this so scary for me
[11:45] <jam> fullermd: really? in what repository format?
[11:45] <jam> I've always found "check" to take longer
[11:45] <jam> because it checks all texts match their sha1sum
[11:46] <fullermd> All knit, probably.
[11:46] <jam> reconcile doesn't, because at the moment, there isn't really anything you can do if there is a mismatch
[11:46] <fullermd> Don't remember runs back in weave days.
[11:49] <fullermd> (And I've not had the time/adventuresomeness to try pack)
[11:49] <lifeless> knit reconcile << pack reconcile. pack reconcile is very fast, according to the intel users.
[11:49] <lifeless> night all
[11:49]  * fullermd gets whiplash watching the drive-by.
[11:50] <Peng> Knit and pack reconcile both do the same thing, right?
[11:51] <fullermd> The end result is the same, presumably, but the mechanics are probably a lot different.
[11:55] <jam> Peng: they work very differently
[11:55] <jam> IIRC knit reconcile is a bit more brute force
[11:56] <Peng> Is that good or bad?
[11:57] <jam> Peng: well it makes knits slower
[11:57] <jam> knits extract all inventories and work out what files have changed, etc.
[11:57] <jam> packs do a similar action, but without having to extract all fulltexts
[12:00] <Peng> If I'm converting from knits to packs, would it be a good idea to reconcile both, just to be careful?
[12:11] <ubotu> New bug: #177643 in bzr "http auth pycurl is broken" [Undecided,New] https://launchpad.net/bugs/177643
[12:30] <jam> Peng: you could, though I don't think the final effect is any different
[12:34] <TeTeT> is there a way to purge a version of a file from a repository? I hold some sample media files in bzr and would like to keep the version overhead small
[12:35] <TeTeT> I'm aware that this goal conflicts with having a file under version control at all
[12:36] <TeTeT> use case here would be 'I'd like to have the latest 3 versions of this audio files available, but not all of them'
[12:39] <jam> TeTeT: generally, no
[12:39] <jam> for referential integrity we don't yet allow removing nodes
[12:39] <TeTeT> jam: ok
[12:40] <jam> TeTeT: you might be able to put something together with 'rebase' but it would get pretty clumsy
[12:40] <jam> You can also look forward to
[12:40] <jam> http://bazaar-vcs.org/HistoryHorizons
[12:40] <TeTeT> ok
[12:40] <jam> which should allow people to do partial downloads
[12:40] <jam> sorry the correct link is: http://bazaar-vcs.org/HistoryHorizon
[12:40] <jam> I expect them to be finish in the first quarter next year
[12:41] <TeTeT> for projects like the desktop training where graphics go through 2-4 versions each easily I guess it's best to split the media files from the text files
[15:45] <wharp> Can someone give me some pointers.  I'm getting an error when I do bzr launchpad-login username
[15:46] <wharp> specifically bzr: ERROR: Connection error: curl connection error (problem with the SSL CA cert (path? access rights?))
[15:46] <mwhudson> wharp: are you a launchpad beta tester?
[15:46] <mwhudson> (very random guess)
[15:46] <wharp> don't think so
[15:46] <wharp> is it possibly a problem with my key?
[15:47] <fullermd> No, it's pycurl not being able to verify the chain to LP's cert.
[15:47] <mwhudson> no, it sounds like pycurl being a pain
[15:47] <wharp> well from what i can tell I don't have pycurl
[15:48] <wharp> or is it not a package?
[15:48] <fullermd> It's just hiding 'cuz it knows you're pissed.
[15:48] <mwhudson> python -c 'import pycurl'
[15:48] <wharp> Where's my trout.
[15:49] <wharp> tried that, still nothing
[15:49] <wharp> do I possibly need to remove curl?  I did install that
[15:50] <mwhudson> if that didn't fail, then you have pycurl installed
[15:50] <wharp> it didn't fail
[15:51] <wharp> at least, it didn't return anything
[15:51] <wharp> is there a way to test?
[15:51] <mwhudson> do you have the 'ca-certificates' package installed?
[15:51] <wharp> i do now
[15:51] <mwhudson> does it help?
[15:52] <wharp> yep, sure does
[15:52] <wharp> thanks, nothing I'd read mentioned that
[15:52] <mwhudson> just another piece of random knowledge floating around
[15:52] <wharp> just out of curiosity, should I have known I needed that?
[15:52] <mwhudson> wharp: probably not
[15:52] <wharp> lol
[15:53] <mwhudson> well, put another way: yes, but it's our fault not yours that you didn't :)
[15:53] <wharp> I'll blame it on Mr. Shuttleworth
[15:54] <fullermd> If only we had a FAQ where we could list such things...
[15:54] <wharp> I really didn't see that error mentioned anywhere.
[15:54] <wharp> Is the FAQ a wiki?
[15:55] <wharp> Another question.  It's adding bazar.launchpad.net, etc to the host....should it do something after that or will that take a while?
[15:56] <mwhudson> embarrassingly, given this is my area of the code, i don't really know what it does
[15:56] <wharp> lol
[15:57] <mwhudson> but basically it just sets a configuration option, it shouldn't take very long
[15:58] <wharp> yeah, palintheus is getting a timeout so I think there might be an issue network wise
[15:58] <Palintheus> Im geting: ssh: connect to host bazaar.launchpad.net port 53000: Connection timed out
[15:59] <mwhudson> port 53000 ??
[15:59] <Palintheus> thats what Isaid
[16:00]  * Palintheus double checks /etc/ssh/ssh_config
[16:00] <mwhudson> well, that makes sense on one level:
[16:00] <mwhudson> there's nothing listening on bazaar.launchpad.net:53000
[16:03] <wharp> now when it's pulling something down, is there a progress bar or anything?
[16:11] <Palintheus> gah! had remnants of an old work-around I needed, now its just sitting there, hope its working
[17:39] <zekel> Is there a way to get `bzr st` relative to your current directory? I.e., not show anything in parent folders, and show all paths relative to the current directory?
[17:39] <mwhudson> bzr st . ?
[17:39] <zekel> That shows all the changes in the whole tree.
[17:39] <zekel> And all paths are relative to the top most directory.
[17:40] <mwhudson> er no
[17:40] <mwhudson> it show only changes below the cwd
[17:40] <mwhudson> but it does show paths relative to the root
[17:40] <mwhudson> which is a bug, i guess
[17:40] <zekel> Ah.
[17:41] <zekel> It makes it really tough to look down the st list and type the paths.
[17:42] <vila> what pycurl version is running on pam ? I have a test involving http proxy failing in a rather strange way
[17:42] <vila> s/pam/pqm/ ghaa
[17:44] <mwhudson> vila: whatever's in dapper i'd guess
[17:45] <vila> wow, how do I find what version of pycurl is in dapper ? ;-)
[17:45] <mwhudson> packages.ubuntu.com ?
[17:46] <vila> excellent, thanks
[17:46] <vila> 7.15.0
[17:51] <mwhudson> vila: yes, 7.15.0-1ubuntu1 according to the sysadmins
[18:17] <orospakr> will bazaar look into shipping some of the more popular plugins, like git, svn, and bisect along with the standard source distribution?
[18:17] <orospakr> because that would be pretty awesome.
[18:37] <radix> rebase is tooootally confusing.
[18:42] <mgedmin> bzr: ERROR: dirstate: inconsistent delta, with tree 0. 'fbreader/qvfb/fbreader.desktop' 'fbreader.desktop-20071220183852-09pyx75ogdtn8vpl-6' :(
[18:42]  * mgedmin has the ability to break software
[18:43] <mgedmin> what I did: took my old bzr repositories (that could very well have internal inconsistencies in their data structures), ran bzr upgrade, then tried to remove, replace and add some files
[18:43] <mgedmin> the old repositories were created with an ancient version of bzr that didn't support symlinks, and my source tree had symlinks
[18:45]  * mgedmin wonders if "101 inconsistent parents" in the output of bzr check is bad
[18:46]  * mgedmin assumes that BzrCheckError: Internal check failed: Mismatched basis inventory content. is bad
[18:47] <luks> to fix the dirstate you can try 'bzr branch broken new'
[18:47] <luks> but I have no idea about the output from bzr check
[18:48]  * mgedmin should probably just rm the old history
[18:51] <fullermd> That check error is probably from the broken dirstate.
[18:52] <mgedmin> no, that's in a different repo
[18:52] <mgedmin> er. branc
[19:10] <vila> mwhudson: thanks for the confirmation (was dining)
[19:17] <brilliantnut> Hi, deepjoy and myself are trying to integrate WebDAV with a bzr centralized server.. Could we get some help?
[19:18] <jelmer> brilliantnut, using the webdav plugin?
[19:19] <brilliantnut> yes, or trying to.. :)
[19:19] <jelmer> vila is the person you'd want to talk to
[19:20] <vila> brilliantnut: what bzr version are you using ?
[19:20] <deepjoy> 1.0
[19:20] <deepjoy> :-)
[19:21] <vila> Are you server's admins ?
[19:21] <brilliantnut> yeah,.
[19:21] <vila> use bzr+http then ;-)
[19:22] <deepjoy> We have an ldap server we set up for other authentication
[19:22] <vila> the plugin doesn't support bzr-1.0 until one bug is fixed and you'll get far better results with smart server anyway
[19:22] <deepjoy> so Apache is able to authenticate against it for other use
[19:22] <deepjoy> we're running a smart server right now
[19:22] <vila> deepjoy: you can still use that
[19:22] <deepjoy> performance seems good
[19:23] <vila> with the webdav plugin ?!?!?
[19:23] <vila> sry, miss one line
[19:23] <brilliantnut> no, we haven't been able to integrate the webdav plugin yet.
[19:23] <brilliantnut> we've set up the bzr:// smart server, and its working cool for us.
[19:24] <brilliantnut> Never mind webdav, could you point us to some documentation for setting up bzr+http
[19:24] <brilliantnut> using ldap?
[19:25] <vila> bzr+http with use http authentication, if your Apache is configured to use ldap, there should be nothing to do
[19:25] <deepjoy> so we put the bzr repository directory to be authenticated against
[19:25] <vila> I think so
[19:26] <deepjoy> and the the bzr client should work with the bzr+http:// protocol?
[19:26] <vila> that's the idea ;)
[19:26] <deepjoy> cool
[19:26] <deepjoy> we'll give it a try
[19:26] <deepjoy> :-) thanks a ton
[19:26] <brilliantnut> thanks vila
[19:26] <vila> have you read doc/en/user-guide/http_smart_server.txt
[19:27] <vila> deepjoy, brilliantnut: happy to help (TM)(jam)
[19:27] <jam> well, modulo spiv's recent patch to make it all work smoothly
[19:29] <vila> jam: I can't remember if it was server-side client-side or both ?
[19:29] <jam> I see a change to SmartClient
[19:29] <jam> and one to SmartWSGIApp
[19:29] <jam> so it looks like both
[19:29] <jam><EMAIL_ADDRESS>[19:29] <jam> and
[19:29] <jam><EMAIL_ADDRESS>[19:30] <jam> vila: I'll try to get them reviewed today
[19:30] <jam> which would mean they get merged for 1.1
[19:30] <vila> ok, thks for that
[19:32] <phanatic> jelmer: hey, could you have a look at bzr-gtk bundlebuggy? i get a 503 http error...
[19:32] <jelmer> phanatic, sure, will do
[19:33] <jelmer> abentley: Any specific reason rich-root-pack is still marked as experimental ?
[19:33] <phanatic> jelmer: thanks. i'd like to go through the pending stuff...
[19:35] <jelmer> phanatic: fixed
[19:35] <phanatic> jelmer: cool, thanks :)
[19:42] <CardinalFang> Hi.  I'm having trouble writing a plugin hook, or rather, I have a plugin written and I think I found a bug.
[19:42] <jelmer> phanatic: can you also merge the two requests you've just approved?
[19:43] <jelmer> hi CardinalFang
[19:43] <CardinalFang> """bzrlib.errors.UnknownHook: The Hooks hook 'post_commit' is unknown in this version of bzrlib."""
[19:43] <phanatic> jelmer: sure
[19:44] <jelmer> phanatic, I think it would be nice to maintain the same policy as core bzr: if the original author is a team member, they do the merge, if the original author isn't, the second approver does
[19:45] <jelmer> CardinalFang: What are you calling to install the hook?
[19:45] <phanatic> jelmer: okay :)
[19:49] <CardinalFang> jelmer,   hooks = bzrlib.branch.Hooks(); hooks.install_hook("post_commit", foo)
[19:50] <jelmer> CardinalFang, You don't have to create an instance of hooks
[19:50] <CardinalFang> Ah.
[19:50] <jelmer> just something like this should do:
[19:50] <jelmer> Branch.hooks.install_hook('post_commit', branch_commit_hook)
[19:51] <CardinalFang> jelmer, TypeError: unbound method install_hook() must be called with Hooks instance as first argument (got str instance instead)
[19:53] <jelmer> CardinalFang: What are you calling exactly now?
[19:53] <jelmer> note that hooks is with a lowercase h
[19:55] <CardinalFang> jelmer, Yes.  install_hooks() is a method of a Hooks class.  Calling it as a class method causes that error.
[19:55] <CardinalFang> (My first way was where I roamed after this error message.)
[19:55] <jelmer> CardinalFang: sorry, I should've been a bit clearer
[19:56] <jelmer> there's no need to create your own instance of hooks
[19:56] <jelmer> rather, use the one in the Branch class
[19:56] <jelmer> see my example
[19:57] <CardinalFang> jelmer, I think I know the problem.  I was testing my code my running it standalone.   $ python .bazaar/plugins/foo.py
[19:57] <CardinalFang> "by running"
[19:58] <jelmer> no, standalone should work as well
[19:58] <phanatic> jelmer: patches applied...
[19:58] <jelmer> yep, does here
[19:58] <jelmer> phanatic, Thanks!
[20:39] <brilliantnut> hi vila, this is brilliantnut, and deepjoy, back with some questions.
[20:40] <vila> brilliantnut: pong
[20:40] <brilliantnut> in bzr-smart.py, what should we set the root and prefix parameters to?
[20:41] <brilliantnut> ..
[20:41] <brilliantnut> smart_server_app = wsgi.make_app(
[20:41] <brilliantnut>     root='/srv/example.com/code',
[20:41] <brilliantnut>     prefix='/code/',
[20:41] <brilliantnut> ..
[20:42] <brilliantnut> so, our repository is rooted at /home/vcs/bzr/ , and the trunk  is at /home/vcs/bzr/branches/HEAD
[20:42] <brilliantnut> so, what do we set root and prefix in this configuration to, and what is the significance..
[20:43] <brilliantnut> BTW, we have apache 2.2, and the <Location> is /bzr
[20:43] <brilliantnut> and we don't have any rewrite rules defined.. is that required?
[20:44] <vila>  /bzr points to /home/vcs/bzr/ ?
[20:45] <deepjoy> in the file-system or in the apache conf?
[20:45] <vila> :) Whatever
[20:46] <deepjoy> I guess I'll try both
[20:46] <deepjoy> :-)
[20:47] <vila> I'd say root='/bzr' prefix='/bzr' but you may be hitting bugs recently fixed by spiv, in which case you'll need to update to bzr.dev or wait for bzr 1.1
[20:47] <vila> prefix='/bzr/'
[20:48] <brilliantnut> hmm.
[20:48] <vila> have you read doc/en/user-guide/http_smart_server.txt
[20:48] <brilliantnut> yes, I was quoting that earlier.
[20:49] <vila> ok, just making sure, in the urls mentioned by jam earlier, spiv said: This, combined with the small change to fix the client-side path calculations
[20:49] <vila> I've posted separately, makes bzr+http actually work in non-trivial situations.

[20:50] <jam> brilliantnut: I think before Andrew's patches, you have to set "root = /path/to/repo" and that must line up with "http://host/"
[20:50] <vila> spiv is the definitive reference on these problems anyway
[20:51] <jam> In other words, you set root to the location that is the root of public space
[20:51] <vila> spiv == Andrew
[20:51] <jam> After spiv's patches land (I'm just finishing a review of one)
[20:51] <brilliantnut> Is he here?
[20:51] <jam> brilliantnut: he is, but is in Australia
[20:51] <jam> so we won't be online for at least another hour
[20:51] <jam> anyway, after spiv's patches land, you can do:
[20:51] <jam> root = /path/to/repo
[20:52] <jam> prefix = '/repo/'
[20:52] <jam> And have that exported as
[20:52] <jam> http://host/repo
[20:52] <jam> brilliantnut: am I making sense?
[20:52] <brilliantnut> you are, but would this also require some special handling in httpd.conf?
[20:53] <brilliantnut> or a blind redirect for everything in the /bzr context to the bzr-smart.py would do?
[20:53] <brilliantnut> the latter is what we have set up.
[20:53] <jam> brilliantnut: I *think* a blind redirect works
[20:54] <CardinalFang> I can't manage to get hooks to work.  Can someone give me a dummy "pass" example?
[20:55] <brilliantnut> jam: before Andrew's patches, (i.e. on 1.0), if we set root = /path/to/repo, what should we set prefix to?
[20:55] <jam> It has been a *long* time since I set that up, give me a sec
[20:55] <jam> CardinalFang: what hook
[20:55] <jam> (just to give you an example you want)
[20:57] <deepjoy> FYI we keep getting
[20:57] <deepjoy> bzr: ERROR: Not a branch<EMAIL_ADDRESS>[20:57] <brilliantnut> when we try a checkout or a branch or a bind to that url
[20:58] <jam> brilliantnut: so I set it up to be
[20:58] <deepjoy> if we add or subtract from the URL we get 404's
[20:58] <jam> root = '/home/jameinel/dev/bzr'
[20:58] <jam> prefix='/bzr/'
[20:58] <jam> and in http.conf
[20:58] <jam> I have
[20:58] <jam> Alias /bzr /home/jameinel/dev/bzr
[20:59] <CardinalFang> $ cat dummy.py
[20:59] <CardinalFang> def notify_list(local, master, old_revno, old_revid, new_revno, new_revid): pass
[20:59] <CardinalFang> import bzrlib.branch
[20:59] <CardinalFang> bzrlib.branch.hooks.install_hook("post_commit", dummy)
[20:59] <CardinalFang> $ bzr plugins
[20:59] <CardinalFang> Unable to load plugin 'dummy' from '/home/cmiller/.bazaar/plugins'
[21:00] <jam> brilliantnut: do you have "GET" and "POST" installed
[21:01] <brilliantnut> yes
[21:01] <jam> CardinalFang: check ~/.bzr.log
[21:01] <jam> it should explain why it is failing
[21:01] <jam> but you should do
[21:01] <jam> bzrlib.branch.Branch.hooks.install_hook...
[21:01] <jam> bzrlib.branch
[21:01] <jam> is a module
[21:01] <jam> bzrlib.branch.Branch
[21:01] <jam> is the class
[21:01] <jam> brilliantnut: make sure this works
[21:01] <jam> echo "hello" | POST http://localhost/path/.bzr/smart
[21:01] <jam> It should return something like "ok2"
[21:02] <jam> Technically, it returns
[21:02] <jam> ok\012\n
[21:02] <jam> well, ok\0x012\n
[21:02] <jam> depending on how you want to escape "\001"
[21:04] <jam> brilliantnut: also, at least the way I configured apache, I can browse to: 'http://localhost/bzr/'
[21:04] <jam> just to make sure my Alias is correct
[21:04] <deepjoy> http://localhost/bzr returns a blank page
[21:05] <deepjoy> there are no errors in the apache logs
[21:05] <jam> deepjoy: not an index?
[21:05] <deepjoy> no
[21:07] <jam> deepjoy: try http://localhost/bzr/.bzr
[21:07] <brilliantnut> errorincomplete request
[21:07] <jam> I assume deepjoy and brilliantnut  are working together?
[21:07] <brilliantnut> oh yes, we are.
[21:07] <deepjoy> yes we are. I repeat we did not set up Apache with a rewrite rule.
[21:07] <brilliantnut> in fact, we're sitting in the same cubicle currently.
[21:08] <jam> deepjoy: I think you need to...
[21:08] <deepjoy> <Location /bzr>
[21:08] <deepjoy>    SetHandler mod_python
[21:08] <deepjoy>    PythonInterpreter main_interpreter
[21:08] <deepjoy>    PythonHandler bzrlib.bzr-smart
[21:08] <deepjoy>    AuthType Basic
[21:08] <deepjoy>    AuthName "Bazaar"
[21:08] <deepjoy>    AuthBasicProvider ldap
[21:08] <deepjoy>    Order Allow,Deny
[21:08] <deepjoy>    Allow from All
[21:08] <deepjoy>    AuthLDAPURL "ldap://localhost:389/ou=People,dc=domain,dc=com?mail"
[21:08] <deepjoy>    AuthzLDAPAuthoritative off
[21:08] <deepjoy>    Require valid-user

[21:08] <deepjoy> inside a virtual host
[21:09] <jam> deepjoy: http://rafb.net/p/H0rAE268.html
[21:09] <jam> is my configuration
[21:09] <jam> that said, echo "hello" | ... works
[21:09] <jam> but "bzr log http://localhost/path" does not
[21:09] <jam> it gives me
[21:09] <jam> bzr: ERROR: Not a branch: "bzr+http://localhost/".
[21:10] <jam> (And I can't help but notice it is using the root path, and not the localhost/path)
[21:10] <CardinalFang> jam, that was it, module/class .
[21:10] <jam> "bzr log http://localhost/path" works
[21:10] <jam> but that is because of our default (non-smart) code
[21:11] <brilliantnut> jam: We'll try out your configuration and get back?
[21:11] <jam> sure
[21:11] <jam> I'll be around for a bit
[21:12] <jam> I could have sworn my config used to work, and I obviously can see the smart server
[21:12] <jam> it may just need Andrews patches, I might play with it in a second
[21:14] <brilliantnut> I'm hoping to find a solution without requiring to move to bzr.dev, because it will be harder to sell to the team.. :( deepjoy and myself are already struggling hard against organizational inertia.
[21:14] <jam> brilliantnut: would it be sufficient to have bzr.dev on the server?
[21:14] <jam> And 1.1 should be out Jan 4 or so
[21:15] <brilliantnut> yeah, that might work, we just won't tell anybody about the server  ;)
[21:15] <brilliantnut> but no clients
[21:18] <jam> ... unfortunately my quick test shows that both patches are needed ...
[21:18] <jam> If I have them both, "bzr log bzr+http://localhost/bzr/bzr.dev" works
[21:19] <jam> interesting, it almost seems like only the client patch is needed
[21:21] <brilliantnut> right, so when can we try out the client patch?
[21:22] <brilliantnut> alternatively, could you suggest alternatives to add an authentication layer on top of bzr://
[21:22] <vila> bzr+ssh://
[21:23] <brilliantnut> thats where we started the day..
[21:23] <jam> brilliantnut: bzr+ssh:// possibly using 'bzr_access' on the server to use a single logon with multiple ssh-keys
[21:23] <deepjoy> :-)
[21:24] <jam> brilliantnut: what was the reason not to use bzr+ssh?
[21:24] <deepjoy> we have to eventually auth against ldap
[21:24] <brilliantnut> we have sshd running separately on the server
[21:25] <deepjoy> and since it's a remote machine we'd have to set up a chrooted ssh server with PAM against ldap
[21:25] <deepjoy> so we thought we'd give this a try :-)
[21:25] <brilliantnut> actually, we first arrived on #bzr looking for assistance with the WebDAV plugin :)
[21:26] <brilliantnut> and vila deflected us onto this
[21:26] <deepjoy> didn't think of doing what you just suggested
[21:26] <deepjoy> but makes a lot of sense
[21:26] <brilliantnut> but we didn't consider ssh-keys, maybe we'll look into that option..
[21:27] <deepjoy> thanks a ton guys but it's 3 am in India we gtg get some sleep before a 9 am
[21:27] <jam> deepjoy: sleep well, though spiv should be on in about 1 hour :)
[21:27] <deepjoy> btw BZR is amazing
[21:27] <brilliantnut> gnite.. and thanks for all the fish.
[21:31] <abadger1999> Anyone tested out bzrweb against pack repos?
[21:32] <abadger1999> bazaar-webserve tracebacks and I wanted to see if it was a general problem or something specific.
[21:37] <jam> abadger1999: it sounds like a case of a function not calling "branch.lock_read()" when it should
[21:37] <jam> Knit repositories had a few more "automatic lock" functions
[21:37] <abadger1999> That sounds right.
[21:38] <jam> But they are actually usually a bit harmful because people don't realize that all caches are thrown away at unlock time.
[21:53] <abadger1999> jam: Is it safe to call lock_read() and unlock() even if it's a knit repository?  Or do I need to test for that first
[21:53] <jam> abadger1999: it is always safe
[21:53] <jam> even for weaves
[21:53] <abadger1999> Cool.  Thanks
[22:12] <i386> lifeless: ping
[22:16] <jam> i386: he may show up, but he is technically still on vacation
[22:18] <i386> jam: ahh
[22:18] <i386> Im having dinner with him tonight :)
[22:18] <i386> So I wanted to see if it was all still happening
[22:19] <jam> Well, I couldn't tell you that :)
[22:19] <jam> He just sent an email to the ML, so I believe he is awake.
[22:20] <Solarion> I think bzr horked my svn repo
[22:20] <Solarion> svn: 'Field/.svn/tmp/text-base/makefile.svn-base' has unsupported special file type ''
[22:22] <jelmer> Solarion, is this using bzr-svn?
[22:22] <jelmer> or plain bzr?
[22:22] <Solarion> jelmer: sorry, bzr-svn, to my knowledge
[22:22] <Solarion> I didn't knwo that bzr had builtin svn support
[22:23] <Solarion> I mean, this is using bzr {push,pull}
[22:23] <lifeless> i386: hi
[22:23] <jelmer> Solarion: It doesn't, but you may've simply "bzr add"-ed a .svn directory
[22:23] <jelmer> Solarion: Please file a bug
[22:23] <Solarion> jelmer: I sent the stacktrace from trying to pull it to<EMAIL_ADDRESS>like a good buy
[22:24] <Solarion> until then, I need to figure out how to unhork the repo so I can use it.  :)
[22:24] <jelmer> Solarion, the error suggests this is a working copy, not a repository
[22:25] <Solarion> jelmer: what do you mean?
[22:26] <jelmer> Solarion: You say there is corruption in the svn repository, but the path (.svn/tmp/text-base/...) is a working copy path.
[22:27] <Solarion> jelmer: this is from a straight svn checkout, with nothing existing.
[22:27] <jelmer> Solarion, What were you doing before this error occurred?
[22:27] <Solarion> jelmer: I had bzr push'ed it from a different computer (sitll ubuntu gutsy)
[22:30] <jelmer> Solarion, How do you mean? You ran bzr push /to/ the svn working copy?
[22:30] <Solarion> jelmer: I have an svn repo at svn+ssh://host/dir
[22:30] <Solarion> I used bzr pull to get it on my notebook (having bzr push'ed it from the workstation).
[22:31] <Solarion> I made huge changes, then push'ed them back up from the laptop.
[22:31] <Solarion> I now cannot check out from the repository using either bzr nor using svn.
[22:31] <Solarion> bzr gives me a backtrace; svn gives me the error I mentioned here.
[22:31] <jelmer> Solarion: something like "svn co svn+ssh://host/dir" breaks?
[22:32] <Solarion> yes
[22:32] <Solarion> with the error I specified.
[22:32] <jelmer> Solarion: Please post the backtrace of "bzr co" as well
[22:32] <Solarion> jelmer: I've sent it to the bazaar list; are you a moderator on it?
[22:32] <Solarion> it's awaiting moderation, since I'm not on the list
[22:33] <jelmer> no
[22:33] <jelmer> Solarion: what version of bzr-svn/bzr?
[22:33] <Solarion> http://pastebin.com/d58f43fd4
[22:34] <Solarion> whatever's in ubuntu gutsy (bzr 0.90.0, bzr-svn 0.4.1-1
[22:35] <jelmer> ah, looks like it breaks on a symlink
[22:35] <Solarion> I told the boss man that he should use bzr, but he wanted to stay with svn because it's better supported by Apple
[22:36] <Solarion> (though he's not opposed to bzr)
[22:36] <jelmer> Please try running bzr pull again, but with the BZR_PDB=1 environment variable set
[22:36] <jelmer> that should get you into a debugger
[22:36] <Solarion> ok
[22:36] <jelmer> please print the contents of the following variables:
[22:36] <Solarion> what is the syntax for printing the variables?
[22:37] <jelmer> print lines
[22:37] <jelmer> print path
[22:37] <Solarion> (Pdb) print lines
[22:37] <Solarion> []
[22:37] <Solarion> (Pdb) print path
[22:37] <Solarion> Field/makefile
[22:38] <Solarion> jelmer: are you the bzr-svn guy?
[22:38] <jelmer> Solarion: yup, I'm the main author
[22:38] <Solarion> jelmer: congrats; it's awesome stuff
[22:38] <jelmer> did you add a file called "Field/makefile" from bazaar that is a symlink?
[22:38] <Solarion> not knowingly, but possibly; I did a bulk add
[22:40] <jelmer> Solarion, in the original tree, what does Field/makefile link to?
[22:40] <Solarion> I dunno; I'm not on my notebook atm
[22:41]  * Solarion starts up his notebook
[22:45] <Solarion> ok, it is a symlink to makefile.subdir
[22:46] <Solarion> what do I need to do?
[22:52] <Solarion> jelmer: still there
[22:52] <Solarion> ?
[22:53] <jelmer> yeah, I'm just checking how this bug could ever occur
[22:54] <Solarion> jelmer: it's a symlink to a file in the parent directory, if that's any help
[22:55] <Solarion> makefile is a symlink to ../makefile.subdir
[22:58] <igc> morning all
[22:59] <jelmer> Solarion: has the type ever changed? I.e. was Field/makefile ever a regular file?
[23:01] <Solarion> jelmer: don't think so
[23:05] <jelmer> what were the changes to this file as reported by `svn log' ?
[23:05] <jelmer> In particular "svn diff -c <rev> svn+ssh://host/../Field/makefile" may be interesting
[23:06] <Solarion> I can't get a full checkout because of this problem
[23:06] <jelmer> Solarion, You can run svn log and svn diff directly against the repository
[23:07] <Solarion> log says "Added non-object files.
[23:07] <Solarion> which is true
[23:08] <jelmer> Solarion: and diff for that particular file?
[23:09] <Solarion> svn diff -r 5:6 svn+ssh://host/path/to/file states nothing
[23:10] <Solarion> before 5, it says "Unable to find <file> in revision <revisions>'
[23:10] <jelmer> hmm
[23:12] <Solarion> bzr (in the copy I pushed from) says "[23:13] <Solarion> notebook has same versions of bzr and bzr-svn
[23:15] <Solarion> I tried to push a new version with the symlink blown away, and I was able to but it still chokes
[23:16] <jelmer> both svn and bzr?
[23:17] <Solarion> yes
[23:18] <Solarion> well, sorta
[23:19] <Solarion> apparently, with the file gone, svn only chokes *after* everything's been checked out
[23:19] <jelmer> what error?
[23:19] <Solarion> actually, hold on.
[23:20] <Solarion> if I remove the symlink, svn no longer chokes there.
[23:21] <Solarion> yes, svn no longer chokes now that I've removed the symlinks
[23:21] <Solarion> bzr, however, still chokes
[23:22] <Solarion> even when doing a fresh branch
[23:23] <Solarion> jelmer: any idea what's going on yet?
[23:24] <jelmer> Solarion: I'm still not sure why it's setting the symlink correctly
[23:24] <jelmer> It's easy to make the error on bzr go away
[23:24] <vila> wow, lp is making use of --fix lp:nnnn !!
[23:24] <vila> congrats to lp guys :)
[23:24] <jelmer> but I'd rather fix the problem that's causing it
[23:24] <jelmer> vila: how?
[23:25] <Solarion> yes, me too, since it prvents others from checking things out.
[23:25] <vila> look at bug #176643
[23:25] <ubotu> Launchpad bug 176643 in ubuntu "SoundBlater 5.1 digital soundcard doesn't work all the time" [Undecided,Incomplete] https://launchpad.net/bugs/176643
[23:25] <vila> errr bug #177643 ;-)
[23:25] <ubotu> Launchpad bug 177643 in bzr "http auth pycurl is broken" [High,Fix released] https://launchpad.net/bugs/177643
[23:25] <Solarion> jelmer: it's definitely in the symlink adding code; I cannot add a symlink from bzr and push it to svn and have svn not ide.
[23:25] <Solarion> I just tried, and now things are horked again
[23:26] <Solarion> bbiab
[23:28] <spiv> vila: I think jml is the one to thank for that
[23:29] <vila> jml: very nice Christmas gift, thanks :)
[23:29] <jml> my pleasure
[23:30] <Solarion> back
[23:30] <jelmer> Solarion, I'm trying to reproduce it here
[23:30] <Solarion> jelmer: are you sure you're looking at verion 0.41?
[23:30] <Solarion> 0.4.1, rather
[23:32] <jelmer> no, I'm at 0.4.6
[23:32] <jelmer> but I don't recal fixing it
[23:33] <Solarion> if you can't reproduce it in 0.4.6...  :)
[23:35] <Solarion> does 0.4.6 work iwth bzr 0.90?
[23:38] <jelmer> yep, I can reproduce it
[23:38] <jelmer> Solarion, no, it requires 1.0
[23:39] <Solarion> heh
[23:39] <Solarion> maybe i should re-install bzr-svn then.  :)
[23:40] <Solarion> jelmer: so we're halfway there, eh?
[23:40] <jelmer> yep
[23:41] <Solarion> anything I can help with?
[23:42] <jelmer> nope, just need a few minutes to write a testcase and get this fixed
[23:42] <jelmer> it should be fairly trivial
[23:42] <Solarion> found the bug?
[23:43] <Solarion> trivially-fixed bugs are the best oens
[23:46] <Solarion> hey jamesh
[23:48] <jamesh> hello
[23:56]  * Solarion wonders if jelmer is still around.  :)
[23:57] <Solarion> right, I'm off then.  :)


[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_<IP_ADDRESS>~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 ?


[04:26] <MarkDude> https://twitter.com/TheCommunitizer/status/499403768832614401
[04:26] <darthrobot`> Title: [Twitter / TheCommunitizer: Dealing With Disrespect - Jono ...]
[04:38] <MarkDude> Jono will likely call this racist :D https://www.youtube.com/watch?v=06hPljOZNzc
[04:38] <darthrobot`> Title: [Life After Linux - Jono Bacon @OSCON 2014 - YouTube]
[10:09] <raevol> anyone alive who wants to help me with some bash?
[10:22] <nhaines> raevol: what's up?
[10:23] <raevol> nhaines, i think i got it -_- thanks though
[10:24] <nhaines> Glad I could help!
[10:25] <raevol> :D
[13:29] <Roguehorse> Good Morning
[13:36] <nhaines> Roguehorse: good morning!
[13:38]  * Roguehorse is reading up on BoringSSL
[14:03] <Roguehorse> http://www.linuxfoundation.org/programs/core-infrastructure-initiative
[14:04] <darthrobot`> Title: [Core Infrastructure Initiative | The Linux Foundation]
[14:04] <Roguehorse> Good things
[19:27] <ianorlin> hmm when using open source expiernce for a job how do you really fill in fields where they say like supervisor email?
[19:38] <pleia2> yep
[19:38] <pleia2> people put me as a reference to their open source work all the time
[19:38] <pleia2> best to ask first though, since "supervisor" may not particularly fit
[21:28] <pleia2> boo, not feeling so well today, may have to just do a drive by of the Debian dinner
[21:29] <pleia2> and skip beer (well, they do make root beer!)
[21:50] <rww> we're skipping it too. menu didn't look promising for gluten-free stuff, and work has been tiring recently
[21:55] <pleia2> heh, yeah, most breweries don't really do gluten free well :)
[21:55] <pleia2> dietary restrictions are why we typically do chinese
[21:55] <pleia2> (plus, yum)
[21:59] <rww> indeed :)
[22:16]  * ianorlin thinks of botsnack factoid


[09:26] <Stereocaulon> Emmanuel_Chanel, どもありがとうで昨日の話ことがよ。できました。
[09:26] <Emmanuel_Chanel> Good.
[09:27] <Stereocaulon> Emmanuel_Chanel, the solution was to remove any other input method except ibus-related ones. Now to improve on my Japanese...
[09:28] <Emmanuel_Chanel> ok. Post an entry about that on your blog and people can solve same trouble easilier.
[09:30] <Stereocaulon> Emmanuel, I don't have a blog, but I might add it into the Ubuntu wiki.
[09:30] <Stereocaulon> Thanks again for your patience!
[09:36] <Emmanuel_Chanel> (Correctly, your Japanese phrase should be "昨日の話のこと，どうもありがとう．できました．" or so.)
[09:37] <Emmanuel_Chanel> How did you find the solution?
[09:39] <Emmanuel_Chanel> Stereocaulon?
[09:39] <Stereocaulon> Emmanuel_Chanel, yes, I'm still there
[09:39] <Emmanuel_Chanel> How did you find the solution of your problem that we talked yesterday?
[09:40] <Emmanuel_Chanel> your problem... -> your Japanese input trouble
[09:40] <Stereocaulon> Emmanuel_Chanel, I doublechecked everything that had to do with IME's, so I found out that I also had uim installed. I figured that this might conflict with ibus and fortunately, I was right.
[09:41] <Emmanuel_Chanel> ok. You must have cost very much labor...
[09:42] <Stereocaulon> Emmanuel_Chanel, not really, but it did take some time yes. I have searched for a solution and whenb I couldn't find one at hand, it threw back into my own common sense. It was a learning experience :-)
[09:44] <Stereocaulon> Emmanuel_Chanel, I have some experience with linux, using it since 1997...so I do know my way around my system.
[09:44] <Emmanuel_Chanel> I watch TV. Be back soon.
[09:44] <Stereocaulon> Emmanuel_Chanel, see you soon :-)
[09:53] <Stereocaulon> Is it possible to let a utility key (on top of my keyboard, used for opening documents etc.) perform as a Zenkaku key?
[10:32] <Emmanuel_Chanel> Stereocaulon: I don't know.