[00:01] Hm. Startup like things seem to have changed. [00:03] a cron to rotate images would have some issues [00:03] * wrong chan [00:04] Works! [00:15] form? [00:15] formapi? [00:16] fine.. [00:16] tolstoy: cool [00:16] mwhudson: I see it now displays tags. [00:17] yes [00:18] Headings are centered, but the data in the columns isn't. Now I can't remember if it's always been that way. [00:47] ok - this shouldn't be too hard..... [01:58] I'm getting this error warning: mysqli_fetch_object() expects parameter 1 to be mysqli_result, array given in /var/www/d6/includes/database.mysqli.inc on line 144. which seems to be coming from thsi line $rslts = db_fetch_array(db_query('SELECT title, image, titlelink, content FROM {udsidebar} ORDER BY position')); [02:00] Wrong channel? [02:00] yup.... [02:00] sorry [02:00] * Peng_ /away! [02:11] * igc out for a bit - bbl [02:11] Is there no way to specify the umask for bzr+ssh, is there? How do other people set up servers with shared branches? [02:13] We did it the hokey way. All our accounts on that machine have umask of 000, with the same group as the bzr repo. [02:19] tolstoy: Hrm. How did you specify the umask? Altering the umask in /etc/profile doesn't seem to work with bzr+ssh. (new branches are still 755 instead of 775) [02:19] We have the same group set up with everything as well [02:19] Also set it in .bashrc [02:20] Our repos are on Solaris. I think interactive shells source one, and non-interactive source the other. [02:20] I can never remember, and maybe it varies from platform to platform. [02:20] tolstoy: that's ~/.bashrc, right? [02:21] yes, of the account that's doing the logging in. [02:21] ok, i'll try that [02:22] Nope. [02:22] drwxr-sr-x 3 andrew dev 4096 Oct 2 01:22 badges3 [02:23] So, you're doing something like bzr push sftp://tolstoy@host/path/to/repo? [02:24] ~tolstoy is the thing that should have the bashrc/profile/bash_profile umask setting. [02:24] Er, the account. [02:27] ah, no, we're doing it over bzr+ssh [02:27] bzr+shh://host/path/to/repo [02:27] ssh [02:27] Heh. Ssh is somthing else entirely. [02:28] I thought sftp was on top of ssh. [02:28] Isn't pushing over bzr+ssh much faster than sftp? [02:28] "Smart server" and all that? [02:28] Maybe. [02:28] You have a smart server running? [02:28] We don't have that, so no doubt things are different. [02:29] tolstoy: Well, smart server is basically invoking bzr on the server side. Nothing really runs, per se. [02:29] Right. I thought it had a config file for perms and so on. But it's been a while. [02:30] We didn't use it because a year or so ago, it was just one too many steps. [02:30] ok, a tiny bit slower, but not by much [02:30] oh? maybe that's why i'm missing. [02:30] ug, and no, sftp:// still gives me 755. >:( [02:31] Hm.. [02:33] What I ended up doing under similar circumstances was reading the bash man page on that particular server and trying to determine which files it sourced under which conditions. [02:35] emmajane: around? [02:35] verterok, ish :) [02:35] emmajane: hi, I have a *experimetal* pyqt4 installer for 10.5 [02:36] verterok, oh! cool! [02:36] emmajane: do you know of someone willing to try it? [02:36] verterok, let me see if jacine is around. [02:39] * emmajane pings everyone she can find.... [02:39] oh, I can ask in the channel :) anyone with OS X 10.5 willing to try a PyQt4 installer? [02:39] hehe :) [02:39] emmajane: don't worry, we can test it tomorrow :) [02:39] emmajane: is just the first one that looks like it's working :p [02:40] * emmajane hates waiting :) [02:42] I've got two peeps :) [02:42] litwol and dww are both on 10.5 [02:42] hmm? [02:42] :) [02:42] litwol|mac: hi [02:42] link me [02:43] \o/ [02:43] litwol|mac: http://verterok.com.ar/PyQt-4.5.4.dmg [02:43] litwol|mac: it requires Qt installed (I used 4.5.2 for the build) [02:44] fail http://litwol.com/sites/litwol.com/files/Install_PyQt_4-20091001-214409.jpg [02:44] litwol|mac: hmm, looks like it never prompted for admin password, right? [02:45] bingo [02:45] litwol|mac: building a new one :) [02:45] k [02:45] gimme 2' [02:45] verterok: emmajane just had me try your installer... [02:45] in the mean while maybe you can explain what am i installing ? [02:46] verterok: "Install Failed" [02:46] verterok: "The Installer could not install some files in "/". Contact the software manufacturer for assistance." [02:46] dww: http://litwol.com/sites/litwol.com/files/Install_PyQt_4-20091001-214409.jpg [02:46] dww: litwol|mac, it's a PyQt4 standalone installer, but if it works, it will be included in the bzr OS X installer [02:46] dww: I'm uploading a new one 2' [02:47] brb [02:47] * dww nods and agrees with litwol|mac's screenshot [02:48] litwol|mac, dww: uploaded new version that ask for admin rights: http://verterok.com.ar/PyQt-4.5.4-1.dmg [02:49] * dww tries again [02:49] "Mounting failed" ;) [02:50] dww: hmm, looks like the upload did't finished yet :/ [02:50] that'd explain it. ;) [02:51] yeap, looks like the scp is stalled [02:51] I'll cancel it and try again [02:53] dww: now it fully uploaded [02:54] that's more like it... [02:54] dww: do you have Qt installed right? [02:54] says it worked. [02:54] i'm honestly not sure... I don't write GUIs. ;) [02:55] dww: ok, coo. could you try something? [02:55] sure. [02:55] dww: in a terminal: python -c "from PyQt4 import QtCore, QtGui" [02:55] (is Qt included with osx and/or xcode at all?) [02:55] dww: no, is a separate download [02:55] dww: and not a small one :( [02:56] yeah, no Qt here. [02:56] ImportError: dlopen(/Library/Python/2.5/site-packages/PyQt4/QtCore.so, 2): Library not loaded: QtCore.framework/Versions/4/QtCore [02:56] dww: ok, so it's working in some way...but wihtout qt we can't test it [02:56] dww: thanks a lot! [02:57] where's the "uninstall" button? ;) [02:57] dww: that was about to say :) [02:57] dww: open thre installer again [02:57] ok, did so [02:57] dww: Cmd + i [02:58] k [02:58] dww: it expand the two items, those are the files installed [02:58] dww: I can give a script to remove them ;) gimme a minute [02:58] so just manually purge them? [02:58] no, that's fine... i see them. [02:58] dww: yes, nothing else is needed [02:58] dww: ok, cool. [02:59] wow, except: ultra annoying the cmd-i window disappears whenever I make any other app (e.g. iterm) active. :( [03:01] verterok: also, might be nice if "sip" made its own subdir in site-packages instead of using the root... [03:01] dww: I can't change the layout :( [03:02] drat [03:02] any idea how to keep the cmd-i window from disappearing? :( [03:02] i was about to take a screenshot of it. ;) [03:03] dww: no ide :( [03:03] dww: rm -Rf /Library/Python/2.5/site-packages/sip* /Library/Python/2.5/site-packages/PyQt4* [03:03] that was the easy part. ;) [03:03] it's the stuff in /System I'm being a little more careful about. [03:04] dww: yeap :) rm /System/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5/sip.h [03:04] verterok: fear not, I have a screenshot now. ;) [03:04] working fine. [03:04] dww: ok [03:04] dww: thanks! [03:05] interesting: FYI: sip.h was installed chmod 664 instead of 644 like everything else in that dir... [03:05] verterok: not sure if that's something you control. [03:05] dww: yes, I can change that. good catch [03:06] back [03:06] sadly, I didn't look closely at any others before I did. [03:06] what to test ? [03:06] verterok: but you might want to go through and check the perms on all the files... [03:06] litwol|mac: dww already installed it, thanks! [03:06] cool [03:06] cheers [03:07] dww: yes I just need to click one button in PackageManager: "apply recomendations" :) [03:07] good idea. [03:07] * verterok is still learning this mac installers thing [03:08] * dww shrugs [03:09] dww: also I'll change the location of the sip stuff that it's in System/ to /Library [03:09] verterok, did you make it work? :) [03:09] emmajane: partially :) [03:09] WOO! :) [03:10] spiv: https://bugs.edge.launchpad.net/bzr/+bug/427736 [03:10] Launchpad bug 427736 in bzr "bzr1.17 on launchpad streams wrong data, causes "unknown object type identifier 60" in bencode pulling from pack into 2a repository" [Critical,In progress] [03:10] spiv: don't set 2.0.1 as a milestone in trunk; target to release 2.0, then milestone that task [03:10] Oh, blah. Right. [03:10] spiv: I've done it for you [03:10] I guess I see how that makes sense. [03:11] Thanks. [03:11] it lets use record what actual trunk release it makes it into [03:11] while still recording it as a blocker for 2.0.1 [thats what you intended, right?] [03:11] As a user I just think "this should go into 2.0.1" [03:11] And there's a drop down right there that lists 2.0.1. [03:11] in which case, don't set a milestone at all [03:11] yeah [03:11] So I unthinkingly did the obvious thing :/ [03:12] so, I've unmilestoned it completely now [03:12] I'll add a bug comment to explain the noise [03:12] Thanks for cleaning my mess :) [03:13] verterok: anything else? I'm about to flee. [03:13] dww: no, thanks a lot! [03:13] no problem. [03:13] * dww bows [03:14] emmajane: dww didn't have Qt installed, and it's big install/download :) [03:14] spiv: you might like to eyeball how I've leftit. [03:14] verterok, that was the 1+Gig one that jacine had to wait for last night, IIRC [03:15] emmajane: yes, actually. the non-sdk is a bit smaller ~140MB [03:16] emmajane: if jancine wants to download, here is a direct link: http://get.qt.nokia.com/qt/source/qt-mac-opensource-4.5.3.dmg [03:16] verterok, she got Explorer working last night. :) [03:16] emmajane: oh, good to know [03:16] she has fast internets [03:16] or rather: she got it *installed* [03:17] http://dl.getdropbox.com/u/912092/bzr-install.txt <--- I have to update the wiki with her instructions [03:19] emmajane: cool [03:20] yah [03:20] spiv: UI bug filed [03:33] emmajane: fyi, I've changed the banner image to be explorer until you have the carousel going [03:34] igc, perfect [04:06] lifeless: btw, I haven't updated the 2.0 branch to use subunit yet. I'm not sure how to do it nicely while retaining the '[ascii]' prefix on the 2nd test run... [04:07] spiv: just nested progress would do it; there isn't a CLI for that yet [04:07] it would look like [04:08] echo "progress: 2" [04:08] before the tests run at all [04:08] Is it possible to pull just the head of a bzr branch? I'd like to be able to pull it sometimes w/o the .bzr directory [04:08] but, may need testing to make sure it all hangs together correctly. [04:08] could also tag the second half, but I haven't put tags into the PQM UI [04:09] MTecknology: do you mean 'get a copy of the content of the head' ? [04:09] ya [04:09] bzr export [04:09] thanks :) === ivan`` is now known as ivan === ivan is now known as Guest83508 [04:34] spm: around? Would you mind zapping my current PQM request? It has an mildly embarrassing wrong commit message. [04:35] I did specify a sane message to pqm-submit, but I forgot to write "-m"... [04:35] And so pqm-submit silently ignored that argument and just used the last commit on the branch :/ [04:36] I should hack my copy of pqm-submit to require -m, the automatic behaviour is never what I want. [04:37] spiv: or update your local copy [04:37] I doubt you've done so in uhm 2 years [04:37] revno: 55 [merge] [04:38] timestamp: Tue 2008-04-01 18:00:47 +0800 [04:38] Merge John's changes to make --message mandatory. [04:41] lifeless: Oh, hmm. [04:41] lifeless: odd, I've definitely gone through and systematically updated all my plugins several times since that date. [04:43] lifeless: "No revisions to pull.", and bzr plugins -v says it is using the copy I think it is. [04:43] (I have revno 60) === Guest83508 is now known as ivan [04:51] hi [04:51] how to run bzr-gtk? [05:06] lifeless: hmm, no spm it seems... I don't suppose you can kill that PQM job for me? [05:08] Ah well. [05:08] * spiv grabs some lunch. [05:12] spiv: no, I can't [05:12] spiv: pjdc can [06:13] spiv: want to merge 2.0 to .dev? or shall I? [06:13] lifeless: I was about to :) [06:13] cool, shoo :) [06:14] lifeless: I was going to use it as an opportunity to make my intended commit text appear somewhere, at least ;) [06:14] we need a report 'fixed in .dev fix committed in malone' [06:14] Yes. Or even better for LP to just do it... [06:21] do you mean change the status? [06:50] spiv: did you send it to pqm? I see rev 4722 from poolie yesteday, nothing playing, [06:54] spiv: I'm guessing it failed or you were distracted ;) [06:54] spiv: if it failed I'd like to help, if I can [06:55] lifeless: you must have refreshed PQM a second too soon! [06:55] heh:) [06:56] I did spend a bit of time puzzling over the NEWS conflicts and checking that I was supposed to duplicate them etc. [06:56] yeah [06:56] ETOOMANUAL [06:56] I'm a bit puzzled by the current state of the 2.0 NEWS file, actually... why does it have apparently current sections for both 2.0 series and 2.0.1? [06:56] its not an obvious useful thing *today*, but once 2.1b1 is released the utility will be clear [06:57] spiv: grawk, possibly me. Possibly someone else [06:58] Yes, I agree that the policy for lp:bzr's news file is sane. I just needed to dig up the email to ensure that sanity was also the official policy :) [06:59] spiv: :) - I wasn't doubting that, just idly commenting [07:01] hi all [07:01] lifeless, spiv : just to help me wake up, can you remind me in a few (and slow) words what that policy is ? [07:02] numerical or chronological ? [07:05] numerical [07:05] I htink [07:05] it may not be strictly defined in fact [07:06] vila: the policy I'm referring to is that when merging from 2.0 -> dev, NEWS entries for things added in 2.0 should appear in dev's NEWS in both the appropriate 2.0.x section, and the appropriate 2.1.x section. [07:06] lifeless: ha, good, I thought so and was wondering if I misunderstood something [07:06] And, yes, I think numerical. [07:06] But I haven't had cause to really care about that yet :) [07:06] vila: you've seen the pqm bling, I presume? :) [07:07] spiv: Hmm, I think I'm rather strongly against duplicating NEWS entries... [07:07] lifeless: ooooh yes [07:07] vila: then you should reply to the relevant thread :P [07:07] only the screenshot so far [07:07] vila: the reason is that once 2.1b1 released, a NEWS entry in 2.0.1 (say) *doesn't* indicate that it was fixed in 2.1b1 [07:08] spiv: damn, so I *missed* something or is that a today's thread ? [07:08] vila: weeks ago [07:08] vila: but I think it's best to have the entry appear at the right point in each release series, so it's obvious what is fixed, and not fixed, in each release. [07:08] another good point [07:08] over and above inferred data [07:08] vila: which reminds me :) [07:09] vila: please refuse the temptation to guess about milestones for already fixed bugs [07:09] I did that ? [07:09] vila: its better to have it unknown than wrong, I think. Unknown means 'we don't know'. means 'buggy-before' to folk looking at the bug tracker [07:09] vila: yes, about 3 hours ago :) [07:09] The duplication does grate a bit, but I think it's really just a natural consequence of the duplication of effort inherent in maintaining multiple concurrent release series. [07:10] I thought I rather mark fix released *without* milestone than putting an unverified one [07:10] lifeless: I slept this night, I'm sure, so 3 hours ago wasn't me, bug # ? [07:10] vila: you put 2.1b1 as the milestone for a report that came in [07:10] vila: uhm maybe you did it your evening. I noticed my afternoon :) [07:11] lifeless: hmm, that rings a bell, but I was 90% sure for that one, I'll double-check [07:12] https://bugs.edge.launchpad.net/bzr/+bug/363452 [07:12] Launchpad bug 363452 in bzr "bzr revert crashes after shelving a file add on a new repo." [Undecided,Fix released] [07:13] lifeless: ooh, that one, ok [07:13] hmm [07:13] of course, I could be wrong;) [07:14] but, I fixed revert a while back now [07:16] well, I think in that case I thought that occurred in bzr.dev and things are a bit blurry these weeks, so, yes, you're right I shouldn't have guessed, [07:17] but on the other hand, I *had* some rough idea of when... [07:28] spiv: btw, 3918 - don't close it ;) [07:28] the merge improves but does't complete i [07:28] t [07:31] \o/ [07:33] lifeless: I won't :) [07:33] lifeless: as the commit message says, it's a fix "for" 3918, not necessary a fix *of* ;) [07:36] spiv: thanks, was just being preemptive, as its a grey area [07:36] thought I'd save you some overhead [07:36] Yes, actually I was going to forget to update bugs at all until you said that! [07:36] So it's good you did :) [07:37] :P [07:37] I've done 403322 [07:45] hello bzr [07:46] hai [07:46] bialix: I would appreciate if you could give dirstate2 a test spin; just to know how it behaves on windows (only use it on copies :)) [07:47] lifeless: ok, maybe this weekend [07:47] what should I test specifically? [07:47] bzr commit [07:47] just run some commit-status-diff? [07:47] # other window [07:47] bzr diff [07:47] bzr status [07:47] bzr diff | more [07:47] # go to editor [07:47] # put in commit message and have it do the commit [07:47] --- that sort of thing [07:48] ok, I understand [07:48] try to break it; I expect you can [07:48] its a prototype, but I want to get a feeling for how far off it is [07:49] I'll try [07:51] thanks ^^ [07:52] gary gary where are you [07:54] spiv: I'm fairly happy with: https://bugs.edge.launchpad.net/bzr/+bugs?field.tag=dirstate - all the in progress are dirstate2 [07:55] spiv: and I haven't found any other dirstate bugs in the bts [07:55] lifeless: nice [07:55] lifeless: very nice, in fact! [07:56] Ok, I'm off. Have a lovely weekend everyone! [07:56] ciao [08:03] Holy crow, I just typed 'bzrip2'. There was some serious evil going on in the naming process somewhere... :| [08:04] :) === fullermd_ is now known as fullermd === t0mm13b is now known as t0mmieb_away [09:41] * igc dinner [10:34] lifeless: wow, nice bling on pqm... we lost the timings though, do you plan to do more than addressing the failures/errors mismatch there ? Like, hmmm, an option to get back the subunit output even for successful submissions ? [10:34] vila: no [10:35] vila: raw subunit should still be in the log [10:35] its just the status region that parses [10:35] ok, but there is no option to get that log back right ? [10:35] I think its rsynced around somewhere in the dc [10:35] you thinking for baseline timing stuff? The machine has other PQM instances on it. [10:36] so potentially noisy [10:36] yeah, no, not really the timing stuff itself, more generally have some reference about what tests are skipped, etc [10:36] and even if noisy, the timings can give some indications [10:36] Patchs Gratefully Accepted [10:36] :D [10:37] I can put that on my TODO list, but that does not mean it will occur any time soon :-/ [10:38] vila: me neither which is why I'm not offering [10:38] lifeless: but no worries, the new feedback is *very* welcome, thks for that [10:38] I wanted '% complete', that was the main thing :) [10:38] sure, me too, that's what I'm thanking about :D [10:38] should I also thank spiv may be ? [11:06] vila: he took the 'risk' of turning it on once I had the pieces in place ;) [11:06] so perhaps yes [11:09] lifeless, spiv: seeing 97% is indeed soooo good :) [11:09] makes me hungry, will grab some food :) [11:15] Me, I usually get hungry by about 75%... [11:20] fullermd: Oh ! You're there [11:21] No I'm not, I'm here. You're there. [11:21] fullermd: So I had more and more crash with the 8.0rc1 [11:21] fullermd: and it seems that changing the IDE controller did the trick... [11:21] Same crash? [11:22] no, different ones, but I updated from beta4 to rc1 [11:22] and from there I had a different failure mode: attempt to dump the core, encounter file system full 8-( [11:23] another new detail was that it rebooted on failure (Well I mostly suppose here because I was always late in the game...) [11:24] my Debian box keeps doing that ... I'm thinking something is overheating, maybe ... [11:24] ... there is definately a fan down :-( [11:24] SamB_XP_: hmm, I don't have virtual fans in my MVs :D [11:25] vila: hehe [11:25] didn't realize you were talking about VMs -- didn't know you could swap out IDE controllers in those ;-) [11:25] fullermd: So I commented dumpdev="auto" but I were wondering how to specify something else to avoid dumping in '/' ! [11:25] Obviously, that's the problem. If it had virtual fans, it wouldn't overheat :p [11:26] fullermd: lol [11:26] I didn't know I could, I just followed my intuition and tried :D [11:26] vila: Well, it dumps to the swap. savecore(8) copies it into the filesystem on next boot. $dumpdir sets where it's saved to (/var/crash by default; changing it or setting a symlink would move it) [11:27] fullermd: nope, /var/crash exists and doesn't point to / [11:28] and / and /var are on different volumes [11:28] vila: but did you check whether there was a /var/crash hidden behind the mount point ? [11:28] vila: As for the rebooting, the kernel debugger is part of the debugging that tends to be taken out around the first RC. [11:28] df / /var [11:28] Filesystem 1K-blocks Used Avail Capacity Mounted on [11:28] /dev/ad0s1a 507630 313616 153404 67% / [11:28] /dev/ad0s1d 3027598 1338820 1446572 48% /var [11:28] Shouldn't matter, the filesystems are mounted by that time. [11:29] okay [11:30] I may be wrong, but the fact is I found a ps.core on / and a / full at 109% (haha, always love that one) [11:31] and the recipe to come back to a half-stable setup was to boot in single user mode, issue fsck -y and reboot [11:31] issuing fsck -y in "normal" mode didn't seem enough [11:32] why -y ? [11:32] That may sound a bit hammer debugging (it was), but it worked and I had to do it once or twice a day only [11:32] didn't have time to sit there and say yes ? [11:32] Wye -i? [11:33] oh, it happened over and over again? [11:33] SamB_XP_: yes [11:33] * SamB_XP_ missed that [11:33] fullermd: what -i ? [11:33] that's for interactive, probably? [11:33] E -i E -i O. [11:33] okay, now he's being silly ... [11:33] fullermd: had some DUCKS [11:34] fullermd: so back to my initial question, why core dumps on '/', how to avoid that (while still having core dumps, just in case) [11:35] vila: I don't suppose you could reapportion space such that there is enough space on / ? [11:36] Well, it doesn't... on boot it copes into $dumpdir. [11:36] And copies, even. [11:36] fullermd: where does it do that? [11:36] SamB_XP_: It's a default freebsd install, so no, I don't want to spend time on that [11:36] "Where" in what sense? [11:36] I mean, what script or binary does it ? [11:37] savecore(8), as called from /etc/rc.d/savecore [11:37] so, maybe vila should read that script and manpage? [11:37] fullermd: dumpdir is not set in *my* rc.conf, how can I check ? [11:37] SamB_XP_: sshhhh, I have a translator handy [11:37] The default is /var/crash (as seen in /etc/defaults/rc.conf) [11:38] Yes, I translate sh to IRC :p [11:38] well, I just mean I find it helpful to look at init scripts when they go wrong ... [11:38] dumpdir="/var/crash" in /etc/default/rc.conf :-/ [11:39] There's a minfree file in that dir that savecore(8) checks and won't write if it would leave less than that much free. But the default is like 2 megs, and surely you're not THAT close to the line. [11:39] vila: how about adding a line to the /etc/rc.d/savecore to display the mounts at that time to make sure fullermd was right about the filesystems being mounted? [11:40] Well, let's back up; is savecore(8) actually what's giving you the error? It should be in your `dmesg -a` if not scrollback. [11:40] fullermd: ETOOOLD [11:41] vila: say what ? [11:41] They are. It requires syslogd, which requires filesystems. And if it didn't, it would have been seen _ages_ ago, since nobody would be able to get at their crashdumps. [11:41]