[09:23] <Quintasan> Good morning
[09:32] <didrocks> hey Quintasan
[09:32] <didrocks> debfx: ScottK: seems the qt branch moved to ~kubuntu-packagers/kubuntu-packaging/qt, isn't it?
[09:33] <Quintasan> didrocks: Yup, we did a move to keep the naming consistent
[09:33] <didrocks> Quintasan: ok, would have been nice to have been warned about it for comaintainance, but it's fine :)
[09:34] <Quintasan> didrocks: I guess you are not subscribed to kubuntu-devel mailing list
[09:34] <didrocks> Quintasan: no, I have already enough mailing list TBH ;)
[09:35] <didrocks> but we kind of agree with ScottK that pinging on IRC was enough (even if last week, I was quite unavailable due to our rally)
[09:35] <apachelogger> woosh
[09:36] <apachelogger> I wonder why yofel did only send that to kubuntu-devel
[09:36] <Quintasan> Blame apachelogger for that
[09:41] <didrocks> :)
[09:42] <didrocks> so sni-qt should be moved as well, I guess?
[09:42] <didrocks> not sure if it makes sense for kubuntu to have it as well
[09:43] <apachelogger> fixed
[09:44] <apachelogger> didrocks: is it a packaging-only branch?
[09:45] <didrocks> apachelogger: it's a merge-upstream like branch, so contain sources (derived from upstream branch) + debian/ directory
[09:45] <apachelogger> Sput: on a related note, did you look into sni-qt to replace your own sni code?
[09:45] <apachelogger> didrocks: then there is no reason for it to be in packaging IMHO
[09:45] <didrocks> apachelogger: ok, so let's keep it that way
[09:46] <Sput> apachelogger: not yet, no
[09:46] <apachelogger> packaging only ought to contain packaging-only branches, branches that have a strong relation with an existing launchpad project/src import still have a reason to exist :)
[09:47] <Sput> apachelogger: isn't that a patch for Qt itself?
[09:47] <didrocks> apachelogger: ok, so ~kubuntu-packager/qt/ubuntu for now
[09:47] <apachelogger> Sput: I think it is a plugin of sorts
[09:47] <didrocks> Sput: there is a patch for Qt, and a plugin
[09:47] <didrocks> opss
[09:47] <didrocks> ~kubuntu-packager/sni-qt/ubuntu
[09:47] <Sput> apachelogger: yeah but aiui, you need to patch Qt first to make it pluggable
[09:47] <apachelogger> didrocks: right :)
[09:47] <Sput> so that's nothing we can use
[09:47] <apachelogger> Sput: ah, I see
[09:48] <didrocks> Sput: seems it will be integrated in next Qt merge window
[09:48] <Sput> at least not before requiring Qt 4.8 (or did it make it into 4.7?)
[09:48] <didrocks> (the patch to Qt)
[09:48] <didrocks> no, it didn't, even 4.8 is too late
[09:48] <Sput> there won't be a Qt 4.9
[09:48] <bambee> morning
[09:48] <didrocks> apachelogger: btw, I'm changeing the Vcs-Bzr tag for qt
[09:48] <Sput> and I don't think we'll depend on Qt5 anytime soon :)
[09:48] <apachelogger> didrocks: thx
[10:07] <didrocks> fabo: what's your pick on removing libqt4-sql-sqlite2 package?
[10:07] <didrocks> fabo: there is some intention of getting rid of sqlite2 in ubuntu, see https://bugs.launchpad.net/ubuntu/+source/sqlite/+bug/747325
[10:25] <didrocks> Quintasan: in rev 164 or Qt, you remove debian/patches/kubuntu_26_dbusconnection_pointer.diff, with as a title "removed patches which wen upstream according to Qt developers at UDS"
[10:25] <didrocks> Quintasan: for this patch however, it's upstream in Qt 4.8, not 4.7
[10:26] <Quintasan> didrocks: ddenis told us it's safe to remove that :s
[10:26] <didrocks> Quintasan: I'll readd it though, it's needed for the new dconf-qt binding
[10:26] <didrocks> no worry :)
[10:26] <didrocks> just so that you are not surprised of seeing it back  ;)
[10:27] <didrocks> I see little chance we can go with 4.8 for oneiric, unfortunately :/
[11:41] <Quintasan> apachelogger: ping
[11:46] <apachelogger> pogo
[11:51] <bambee> shadeslayer: what's about kcfg btw ? did you find what you were looking for ?
[11:52] <bambee> :)
[12:13]  * yofel blames apachelogger for not checking recipients too.
[12:13] <yofel> Sorry though.
[12:51] <apachelogger> Nightrose: ping
[12:51] <Nightrose> apachelogger: pong
[12:52] <apachelogger> I spammed you a preview request for blog posty posty, if you get a chance it would be cool if you could take a look at it :)
[12:52] <apachelogger> low-tech intro blahblah
[12:53] <Nightrose> apachelogger: i'm at work for a few more hours
[12:53] <apachelogger> k, no hurry
[12:57] <Quintasan> apachelogger: another ping
[12:57] <apachelogger> syn-ack
[12:57] <Quintasan> apachelogger: http://paste.kde.org/91669
[12:57] <apachelogger> rst
[12:58] <Quintasan> apachelogger: Am I doing library packaging right or wrong?
[12:58] <Quintasan> or horribly wrong?
[12:58] <Quintasan> inb4 symbols
[13:01] <apachelogger> well, hard to say with just the control file :P
[13:01] <apachelogger> Quintasan: the dev package ought to depend on the library packages
[13:01] <apachelogger> and you should make sure the libraries do not require stuff from the data package at runtime
[13:02] <apachelogger> for gluonengine you'd probably want a >= source:version or binary:version
[13:02] <apachelogger> on the libs
[13:02] <apachelogger> for -dev too for that matter
[13:02] <apachelogger> for the packages deping on libgluoncore0 too
[13:03] <apachelogger> rule of thumb: packages from the same source package usually should have some sort of versioned dep depending on the source or package version to prevent partial upgrade issues
[13:04] <apachelogger> also, while I am at it :P
[13:04] <apachelogger> Maintainer: Michał Zając<EMAIL_ADDRESS>[13:04] <apachelogger> I think control fiels are restricted to ASCII by policy
[13:05] <Quintasan> So I am bound to be Michal Zajac?
[13:05] <apachelogger> ah na
[13:05] <apachelogger> only the field name is bound to ascii
[13:06] <apachelogger>  The field name is composed of printable ASCII characters (i.e., characters that have values between 33 and 126, inclusive) except colon and must not with a begin with #
[13:06] <apachelogger> All control files must be encoded in UTF-8.
[13:06] <apachelogger> no further restrictions
[13:06] <apachelogger> also there is a typo in the manual
[13:06] <apachelogger> zomg
[13:06] <apachelogger> <-- to lazy to report
[13:09] <Quintasan> apachelogger: http://dl.dropbox.com/u/69524/packaging.tar.bz2
[13:09] <Quintasan> Please check this
[13:09] <ScottK> How's KDE 4.7 packaging going?
[13:09] <ScottK> maco: Any luck on the keyboard crash thingy?
[13:09] <apachelogger> JT apparently got lost playing minewars or what's its name
[13:13]  * Quintasan will get to that when apachelogger reviews his Gluon magic
[13:13] <apachelogger> Package: gluonengine
[13:13] <apachelogger> Architecture: any
[13:13] <apachelogger> Depends: libgluonaudio0 (>= ${source:Version}),
[13:13] <apachelogger> are you sure it is only source?
[13:14] <apachelogger> like does it link against it?
[13:14] <apachelogger> if so it is binary not source
[13:14] <apachelogger> Package: gluon-games
[13:14] <apachelogger> Architecture: any
[13:14] <apachelogger> Depends: gluonengine, gluonplayer, ${misc:Depends}, ${shlibs:Depends}
[13:14] <apachelogger> missing deps
[13:14] <apachelogger> eh
[13:14] <apachelogger> versions
[13:14] <apachelogger> gluoncreator too
[13:14] <apachelogger> Package: libgluoninput0
[13:14] <apachelogger> Architecture: any
[13:14] <apachelogger> Depends: libgluoncore0 (>= ${source:Version}),
[13:14] <apachelogger> that is definitely binary along with all the other libs
[13:15] <apachelogger> oh
[13:15] <apachelogger> come to think of it
[13:15] <apachelogger> Quintasan: why is it called libgluon-data and not gluon-data?
[13:15] <apachelogger> libgluon-dev still misses deps on the libs
[13:15] <Quintasan> wrap-and-sort--
[13:15] <apachelogger> typo
[13:15] <Quintasan> It must have eaten them
[13:15] <apachelogger> "devlopment"
[13:16] <apachelogger> gluonplayer's advanced advanced description probably exceeds 80 chars/line
[13:16] <apachelogger> Homepage: http://gluon.tuxfamily.org/
[13:17] <apachelogger> I thought gluon lives on gaminfreedom or something?
[13:17] <Quintasan> It odes
[13:17] <Quintasan> does*
[13:17] <apachelogger> your copyright file has mixture of tab and spaces to indent the copyright holders
[13:17] <apachelogger> also I think your dep5 is invalid
[13:18] <apachelogger> IIRC there must not be a newline before the license field, otherwise the paragraph will be licenseless
[13:19] <apachelogger> that said, what you can do is License: Foo and then have a sepearate paragraph that just contains "License: Foo\n description blah blah\n more description"
[13:19]  * ScottK wonders why we care?
[13:19] <apachelogger> license ought to be LGPL-2.1+ btw
[13:19] <apachelogger> ScottK: the parser
[13:19] <ScottK> So?
[13:19] <apachelogger> Format: http://anonscm.debian.org/viewvc/dep/web/deps/dep5.mdwn?view=markup&pathrev=174
[13:19] <ScottK> I'm familiar with it.
[13:19] <apachelogger> if you tell the parser this file complies with the spec then it better does so
[13:20] <apachelogger> ScottK: no, no, note the Format:
[13:20] <ScottK> So don't tell it that.
[13:20] <apachelogger> my point exactly :P
[13:20] <apachelogger> either you write valid dep5 or you do not denote it as such
[13:20] <ScottK> Just about the last thing we need is making filling out debian/copyright harder.
[13:20] <apachelogger> in which case you can still follow the spec but as you please rather than as it defines ^^
[13:20] <ScottK> Right, so just ignore dep5 entirely.
[13:20] <apachelogger> ScottK: well, you could write a gui for it with dep5 :P
[13:21] <ScottK> or I could spend my time doing something useful.
[13:21] <apachelogger> or cli for that matter
[13:22] <Quintasan> This DEP5 is totally...meh
[13:22] <apachelogger> Quintasan: gluon engines contains public libs?
[13:22] <Quintasan> No idea.
[13:23] <Quintasan> Since it's a library used to create games I guess it does
[13:24] <apachelogger> nono
[13:24] <apachelogger> my point being
[13:24] <apachelogger> usr/lib/libGluonEngine.so.*
[13:24] <apachelogger> that is a public lib so the package should be libgluonengine0
[13:24] <apachelogger> also
[13:25] <apachelogger> BROTIP: *.so should be in a -dev package UNLESS there is no *.so.* or the .so is no link in which case it is a proper lib and not material for -dev
[13:27] <Quintasan> I do not have *.so anywhere in install files
[13:28] <apachelogger> core0.install:
[13:28] <apachelogger> usr/lib/libGluonCore.so
[13:28] <apachelogger> usr/lib/libGluonCore.so.*
[13:28] <apachelogger> audio0.install:
[13:28] <apachelogger> usr/lib/libGluonAudio.so
[13:28] <apachelogger> usr/lib/libGluonAudio.so.*
[13:29] <apachelogger> graphics0.install:
[13:29] <apachelogger> usr/lib/libGluonGraphics.so
[13:29] <apachelogger> usr/lib/libGluonGraphics.so.*
[13:29] <apachelogger> .....
[13:29] <Quintasan> Are you implying I should put it in -dev?
[13:29] <apachelogger> yes
[13:29] <apachelogger> that is what the BROTIP sez
[13:29] <apachelogger> Quintasan: how was skateboarding btw?
[13:29] <Quintasan> then libgluon{input,graphics,audio,etc}0 is not neccessary?
[13:30] <apachelogger> read again
[13:30] <apachelogger> BROTIP: *.so should be in a -dev package UNLESS there is no *.so.* or the .so is no link in which case it is a proper lib and not material for -dev
[13:30] <Quintasan> apachelogger: I'm still not able to walk
[13:30] <apachelogger> lol
[13:30] <apachelogger> good
[13:30] <apachelogger> more work then!
[13:30] <apachelogger> muhahahaha
[13:30] <Quintasan> usr/lib/libGluonGraphics.so is not a link AFAIC
[13:31] <Quintasan> How the hell I am supposed to determine whether it is or not?
[13:32] <apachelogger> look at it? :P
[13:32] <apachelogger> + it most certainly is if there is a .so.x.x for the lib
[13:32] <apachelogger> (not always though)
[13:32] <Quintasan> So I should move usr/lib/libGluonGraphics.so
[13:33] <Quintasan> usr/lib/libGluonGraphics.so.* to -dev
[13:33] <Quintasan> and so on for the other stuff
[13:33] <Quintasan> that will make those packages empty :O
[13:33] <apachelogger> no
[13:33] <apachelogger> dude
[13:33] <apachelogger> BROTIP: *.so should be in a -dev package UNLESS there is no *.so.* or the .so is no link in which case it is a proper lib and not material for -dev
[13:33] <apachelogger> where do I say *.so.* should go into -dev?
[13:33] <Quintasan> hurp durp
[13:33] <Quintasan> K
[13:34] <apachelogger> oh, this just depressed me
[13:35] <Quintasan> apachelogger: http://paste.kde.org/91711 -> libgluon-dev.install
[13:35] <Quintasan> I am doing it right.
[13:35] <Quintasan> Otherwise, throw bricks
[13:40] <apachelogger> looks good
[13:40] <Quintasan> apachelogger: I guess I just fixed all that you mentioned, anything else?
[13:40] <apachelogger> no
[13:41]  * Quintasan goes to #debian-qt-kde
[13:48] <bambee> Is it correct ? http://paste.ubuntu.com/638431/
[13:57] <apachelogger> bambee: correct in what way?
[13:58] <bambee> apachelogger: Does this copyright contain an error ?
[14:06] <apachelogger> bambee: an error in what way?
[14:07] <apachelogger> the only way copyright can be wrong is by not being complete or listing people who do not have copyright or by noting wrong licenses
[14:07] <apachelogger> neither of which I can check :P
[14:19] <Quintasan> apachelogger: fix kgetsource so it uses new packaging branches
[14:22] <Quintasan> apachelogger: nvm
[14:25] <Quintasan> apachelogger: I fixed it
[14:25] <bambee> apachelogger: ok
[14:29] <CIA-52> [kubuntu-default-settings] Harald Sitter<EMAIL_ADDRESS>*<EMAIL_ADDRESS>* (2 files in 2 dirs) Remove quickaccess widget from plasma init script
[14:38] <shadeslayer> bambee: i used a QHash <QString, QString> serialized the data using a QDataStream, wrote the stream into a QByteArray and wrote the QBA using KConfigGroup::write() :P
[14:39] <apachelogger> shadeslayer: you have a formatting error there
[14:39] <apachelogger> it is tpl<t, t> not tpl <t, t>
[14:40] <apachelogger> also what are you storing that way?
[14:45] <CIA-52> [kubuntu-dev-tools] Harald Sitter<EMAIL_ADDRESS>*<EMAIL_ADDRESS>* bin/kgetsource merge
[14:46] <apachelogger> shadeslayer: ping
[14:46] <apachelogger> Quintasan: ping
[14:46] <apachelogger> yofel: ping
[14:46] <apachelogger> bambee: ping
[14:46] <shadeslayer> pong
[14:46] <Quintasan> apachelogger: pong
[14:46]  * Quintasan has to go in a bit
[14:47]  * shadeslayer might pull a rodrigo any moment
[14:47] <apachelogger> what are you working on?
[14:47] <shadeslayer> apachelogger: had to get my documents in order for my visa application
[14:47] <shadeslayer> involves running to and fro to the college
[14:48] <shadeslayer> apachelogger: ssup with the ping?
[14:48] <apachelogger> well
[14:48] <apachelogger> as you probably do not know
[14:48] <apachelogger> alpha2 is supposed to be released this week
[14:49] <apachelogger> seing as rc1 is not done that makes me a bit, erm, worrid
[14:49] <shadeslayer> apachelogger: question is, do we want rc1 in the alpha ?
[14:49] <shadeslayer> we have yet to test it
[14:50] <apachelogger> I reckon a alpha is meant to be tested
[14:50] <apachelogger> otherwise one would not bother releasing non-production quality sofware :P
[14:51] <shadeslayer> i just don't think its a good idea if we rush it, thats all
[14:51] <shadeslayer> there are only a couple of packages left on the wiki
[14:51] <apachelogger> so we should get them done
[14:52]  * Quintasan has to head out
[14:52] <shadeslayer> sure, i can work on some of them after dinner
[14:52] <Quintasan> I'll be back like in 4 hours so I'll start working
[14:52] <Quintasan> kdetoys are on dep wait
[14:52] <Quintasan> kdenetwork still awaits response from Kopete
[14:53] <shadeslayer> apachelogger: i'm also having a hard time figuring out ubiquity and python plasma kpart
[14:54] <apachelogger> shadeslayer: see, my point is that this is not particularly important right now
[14:54] <shadeslayer> right, which is why i haven't worked on it one bit, just searched for docs
[14:57] <shadeslayer> apachelogger: anyways, get RC1 done -> top priority
[15:12] <CIA-52> [kdegraphics-strigi-analyzer] Harald Sitter<EMAIL_ADDRESS>*<EMAIL_ADDRESS>* (10 files in 4 dirs) * Initial release (moved out of kdegraphics) * Repacked upstream source to include copies of LGPL and GPL
[15:15] <apachelogger> Quintasan: why is kdenetwork waiting?
[15:15] <apachelogger> that does not compute
[15:15] <apachelogger> ah, missing symbols
[15:15] <apachelogger> just dont package kopete :P
[15:41] <bambee> apachelogger: pong
[15:42] <CIA-52> [kdegraphics-strigi-analyzer] Harald Sitter<EMAIL_ADDRESS>*<EMAIL_ADDRESS>* debian/control add missing deps and transitional package
[15:42] <CIA-52> [kdegraphics-strigi-analyzer] Harald Sitter<EMAIL_ADDRESS>*<EMAIL_ADDRESS>* debian/kdegraphics-strigi-analyzer.install whoops, forgot to add an install file for the primary package
[15:42] <apachelogger> bambee: what are you working on right now?
[15:43] <bambee> apachelogger: libexiv2 to solve the build failure for kdeplasma-addons
[15:43] <bambee> libkexiv2 I mean
[15:43] <bambee> (required by kde-sc-dev-lastest)
[15:43] <apachelogger> any problems there?
[15:43] <bambee> except a build failure ... no
[15:43] <bambee> why?
[15:44] <CIA-52> [kdegraphics-thumbnailers] Harald Sitter<EMAIL_ADDRESS>*<EMAIL_ADDRESS>* (10 files in 4 dirs) * Initial release (moved out of kdegraphics) * Repack upstream source to contain copies of GPL and LGPL
[15:44] <bambee> I did something wrong ?
[15:45] <apachelogger> bambee: just checking
[15:45] <apachelogger> ...if you need help with anything
[15:48] <bambee> apachelogger: In fact, pkgkde-symbolhelpers does not work, I ask it to update symbols for libkexiv2 and NOTHING is updated
[15:49] <bambee> actually I build it with debuild, then I use the following command : pkgkde-symbolshelper patch -p libkexiv2-10 -v 4:4.6.90 < ../libkexiv2_4.6.90-0ubuntu1~ppa1_amd64.build
[15:49] <apachelogger> http://www.youtube.com/watch?v=uyn41Zjz3sk
[15:49]  * apachelogger packages away
[15:49] <apachelogger> oh gosh
[15:49] <apachelogger> ok, that dub is just horrible
[15:49] <apachelogger> I am sorry
[15:49] <bambee> the output: http://paste.ubuntu.com/638464/  <--- WTF ?
[15:50] <bambee> then if I try to build again the symbols are NOT UPDATED
[15:50] <apachelogger> bambee: do you ahve this in a branch?
[15:51] <bambee> apachelogger: I can update the package rules to my lp...
[15:51] <bambee> wait
[15:53] <CIA-52> [kdegraphics-strigi-analyzer] Harald Sitter<EMAIL_ADDRESS>*<EMAIL_ADDRESS>* debian/control add libtiff builddep
[15:57] <bambee> apachelogger: https://code.launchpad.net/~bambi/kubuntu-packaging/libkexiv2
[15:57] <bambee> the package is not perfect yet but it's almost done
[15:58] <bambee> the problem is: I cannot update libkexiv2-10.symbols with pkgkde-symbolshelper
[15:58] <CIA-52> [kdegraphics-thumbnailers] Harald Sitter<EMAIL_ADDRESS>*<EMAIL_ADDRESS>* debian/changelog +repack
[16:00] <apachelogger> bambee: does it not do anything?
[16:00]  * apachelogger has not updated symbol files in ages
[16:01] <bambee> apachelogger: see yourself http://paste.ubuntu.com/638464/
[16:01] <apachelogger> why yes, I reckon it is not supposed to print anything?
[16:01] <bambee> and when I try to build again the symbol file is definitively not updated, I see a "diff" on stdout
[16:02] <bambee> apachelogger: assuming it prints nothing, the build process should not compute a difference for the next build :)
[16:03] <apachelogger> well
[16:03] <apachelogger> you need to rebuild your source package :P
[16:04] <bambee> :P
[16:05] <bambee> debuild -S && debuild -j8 && pkgkde-symbolshelper :)
[16:06] <apachelogger> clearly the whole workflow surrounding symbols is flawed
[16:06]  * apachelogger puts on todo
[16:06] <apachelogger> bambee: you could just diff your symbols file against the one in bzr? :P
[16:06] <apachelogger> then you know whether it was updated or not
[16:07] <apachelogger> if there were any updates at all
[16:07] <apachelogger> also please paste an ls of your debian dir
[16:08] <CIA-52> [kdegraphics-strigi-analyzer] Harald Sitter<EMAIL_ADDRESS>*<EMAIL_ADDRESS>* debian/control fix dep name
[16:08] <bambee> apachelogger: found
[16:09] <bambee> the soname and the package name were not updated in the symbol file o_O  (I have renamed libkexiv2-9 to libkexiv2-10)
[16:10] <CIA-52> [kdegraphics-strigi-analyzer] Harald Sitter<EMAIL_ADDRESS>*<EMAIL_ADDRESS>* debian/control I am in a good mood, here is a long description
[16:12] <apachelogger> someone messed up :P
[17:25] <CIA-52> [kgamma] Harald Sitter<EMAIL_ADDRESS>*<EMAIL_ADDRESS>* (10 files in 4 dirs) * Initial release (moved out of kdegraphics) * Repack upstream source to include copy of GPL2
[17:27]  * apachelogger pokes shadeslayer
[17:30] <bambee> apachelogger: could you create a branch "libkexiv2" into lp:kubuntu-packagers please ?
[17:31] <bambee> then I will propose a merge
[17:32] <apachelogger> >>> bzr push lp:~kubuntu-packagers/kubuntu-packaging/libkexiv2
[17:32] <apachelogger> Created new branch.
[17:32] <apachelogger> bambee: ^
[17:36] <apachelogger> bambee: don't forget to copy the .bzr-builder dir from an existing branch
[17:37] <bambee> apachelogger: I've not the rights for that
[17:37] <apachelogger> into your branch
[17:37] <apachelogger> ah
[17:37] <apachelogger> what?
[17:37] <apachelogger> I do not compute
[17:37] <apachelogger> bambee: you are creating a new branch, no?
[17:37] <bambee> yes for libkexiv2, it's already pushed into my repository and I would like to push it into kubuntu-packagers
[17:38] <bambee> so someone has to create this branch before
[17:38] <bambee> and then I will propose a merge (from my branch to kubuntu-packagers)
[17:38] <bambee> :)
[17:38] <bambee> apachelogger: do you compute now?
[17:39] <apachelogger> there is the new branch now
[17:39] <apachelogger> BUT
[17:39] <apachelogger> you should copy the .bzr-builder dir from an existing packaging branch
[17:39] <bambee> ok
[17:40] <apachelogger> e.g. cd libkexiv2 && cp -r ../ksnapshot/.bzr-builddeb && bzr add .bzr-builddeb && bzr ci
[17:40] <bambee> well, I am tired xD
[17:48] <CIA-52> [kgeography] Harald Sitter<EMAIL_ADDRESS>*<EMAIL_ADDRESS>* (12 files in 4 dirs) * Initial release (moved out of kdeedu) * Repack upstream source to include a copy of GPL2
[17:51] <bambee> merge proposal : https://code.launchpad.net/~bambi/kubuntu-packaging/libkexiv2/+merge/66943
[17:51]  * apachelogger wonders where everyone is
[17:58] <CIA-52> [kgeography] Harald Sitter<EMAIL_ADDRESS>*<EMAIL_ADDRESS>* debian/changelog Repack upstream source to include a copy of GPL2 and GFDL1.2
[18:00] <CIA-52> [kgeography] Harald Sitter<EMAIL_ADDRESS>*<EMAIL_ADDRESS>* debian/changelog +repack kthxbai
[18:12] <CIA-52> [khangman] Harald Sitter<EMAIL_ADDRESS>*<EMAIL_ADDRESS>* (11 files in 4 dirs) Initial release (moved out of kdeedu)
[18:13] <apachelogger> bambee: do you want a PITA review with that?
[18:14] <bambee> what's a PITA review?
[18:14] <apachelogger> one done apachelogger style
[18:15] <apachelogger> one where you'd probably have to spend a whole day fixing stuff :P
[18:15] <apachelogger> lets just start :P
[18:15] <apachelogger> bambee: wrong: Vcs-Browser: http://bazaar.launchpad.net/~kubuntu-packagers/libexiv2/ubuntu
[18:15] <apachelogger> also wrong: Vcs-Bzr: https://code.launchpad.net/~kubuntu-packagers/libexiv2/ubuntu
[18:15] <cpatrick08> i was reading the ninjas packing and i was  wondering what was taking so long on 4.7 beta1 beta2 comes out tomorrow
[18:16] <bambee> apachelogger: oh right
[18:17] <apachelogger> ohoh
[18:17] <apachelogger> cpatrick08: you are not helping, so naturally it takes longer
[18:18] <apachelogger> bambee: I see at least one file that has LGPL
[18:18] <apachelogger> how very rude
[18:18] <apachelogger> bambee: but there is no full copy of the LGPL
[18:18] <apachelogger> or maybe I just can't find it?
[18:19] <apachelogger> "Any other files in libkexiv2/* and tests/* are under the GNU General Public License, version 2 or later (GPL-2+)"
[18:19] <apachelogger> s/Any/All/g
[18:19] <kubotu> apachelogger meant: ""All other files in libkexiv2/* and tests/* are under the GNU General Public License, version 2 or later (GPL-2+)""
[18:19] <apachelogger> ?
[18:19] <apachelogger> sounds bette rIMHO
[18:20] <apachelogger> bambee: it would be cool if you could make debian/copyright not exceed 80 chars/line
[18:20]  * apachelogger is too lazy to resize his terminal :P
[18:20] <apachelogger> bambee: it would be good if you could add the brief license statements of LGPL/GPL to the copyright ifle
[18:20] <apachelogger> *file
[18:34] <CIA-52> [khangman] Harald Sitter<EMAIL_ADDRESS>*<EMAIL_ADDRESS>* debian/control add libkdeedu-dev builddep
[18:36] <CIA-52> [khangman] Harald Sitter<EMAIL_ADDRESS>*<EMAIL_ADDRESS>* debian/changelog Repack upstream source to include a copy of FDL1.2
[18:52] <CIA-52> [kig] Harald Sitter<EMAIL_ADDRESS>*<EMAIL_ADDRESS>* (9 files in 4 dirs) Initial release (moved out of kdeedu)
[18:57] <_Groo_> hi/2 all
[18:57] <_Groo_> any news on kde 4.7 for nautty?
[18:59] <apachelogger> _Groo_: help needed
[19:00] <_Groo_> apachelogger: yeah i can see in ninjas we have packages for oneiric
[19:01] <bambee> apachelogger: ok I fill fix the copyright
[19:01] <_Groo_> apachelogger: anyone working on any backports or i would be the first?
[19:01] <bambee> s/fill/will/
[19:01] <kubotu> bambee meant: "apachelogger: ok I will fix the copyright"
[19:01] <apachelogger> _Groo_: first we need oneiric!!!!! zomg
[19:01] <_Groo_> apachelogger: dont have time for both :D i rather help with natty packages
[19:02] <bambee> _Groo_: you have to split a LOT of packages and to rewrite everything :)
[19:02] <_Groo_> apachelogger: im making my weekly build of calligra AWS
[19:02] <_Groo_> bambee: yeah, lots of fun :)
[19:02] <bambee> and a lot of work :)
[19:02] <_Groo_> work = fun!
[19:02] <_Groo_> all fun in packages is work!
[19:03] <bambee> right
[19:03] <apachelogger> _Groo_: there will be no natty packages unless oneiric gets finished
[19:03] <_Groo_> apachelogger: ehehe ill start migrating base packages to nautty :D
[19:03] <_Groo_> like soprano, kdelibs, kdebase etc etc
[19:04] <_Groo_> those alone will keep me busy for a few days
[19:04] <apachelogger> perhaps I did not make myself clear, you should work on oneiric packages
[19:04] <_Groo_> btw as soon as calligra hits the streets im i a position to release nautty almost in the same day
[19:04] <apachelogger> alpha2 is due this week and we are not done
[19:05] <_Groo_> apachelogger: i DONT have a oneiric build in my machine
[19:05] <apachelogger> and somehow I feel we wont get done as motivation is falling into a big black hole
[19:05] <apachelogger> _Groo_: sudo pbuilder create --dist oneiric
[19:05] <_Groo_> apachelogger: whi motivation is falling? no more beer? oO
[19:06] <_Groo_> apachelogger: how many gigabytes that little command will throw at me?
[19:08] <apachelogger> <1
[19:08] <apachelogger> in fact <0.5
[19:09] <apachelogger> in fact < 0.2 I suppose
[19:09] <apachelogger> perhaps even <0.1
[19:11] <_Groo_> apachelogger: ok ok
[19:12] <CIA-52> [kig] Harald Sitter<EMAIL_ADDRESS>*<EMAIL_ADDRESS>* debian/changelog Repack upstream source to include copy of FLD1.2 and COPYING-CMAKE-SCRIPTS
[19:13] <CIA-52> [kig] Harald Sitter<EMAIL_ADDRESS>*<EMAIL_ADDRESS>* debian/rules phony tests anyone?
[19:13] <CIA-52> [kig] Harald Sitter<EMAIL_ADDRESS>*<EMAIL_ADDRESS>* debian/copyright add copyright
[19:14] <CIA-52> [kig] Harald Sitter<EMAIL_ADDRESS>*<EMAIL_ADDRESS>* debian/control me be maintainer
[19:16] <CIA-52> [kig] Harald Sitter<EMAIL_ADDRESS>*<EMAIL_ADDRESS>* debian/changelog +repack kthxbai
[19:25] <CIA-52> [kiten] Harald Sitter<EMAIL_ADDRESS>*<EMAIL_ADDRESS>* (14 files in 4 dirs) Initial release (moved out of kdeedu)
[19:27] <jussi> its a Riddell! Hai Riddell!
[19:28] <Riddell> Hei jussi
[19:28] <jjesse> yay for Riddell
[19:29] <Riddell> oh good, you haven't forgotten about me :)
[19:30] <bambee> Riddell: hey ;)
[19:30] <jussi> Riddell: nah, we wouldnt do that :D
[19:35] <bambee> apachelogger: fixed
[19:46] <CIA-52> [kiten] Harald Sitter<EMAIL_ADDRESS>*<EMAIL_ADDRESS>* debian/copyright add copyright file
[20:04] <Quintasan_> clea
[20:04] <Quintasan_> ffs
[20:08] <Quintasan> yofel_: kdebase-workspace-dev (>= 4:4.6.90) any idea why it cannot be installed?
[20:09] <bambee> Quintasan: change it to kde-workspace-dev, it has been renamed
[20:09] <Quintasan> Oh
[20:11] <bambee> same thing for kdebase-runtime, it's kde-runtime now
[20:11] <bambee> just drop "base"
[20:26] <bambee> apachelogger: could you merge libkexiv2 ? should be okay now
[20:26] <apachelogger> well
[20:26] <apachelogger> I am hanging out rright now
[20:26] <apachelogger> also drinking
[20:26] <apachelogger> Quintasan can
[20:27] <Quintasan> Certainly. I will look at it when I am done with parley
[20:27] <apachelogger> also kiten has broken abi
[20:27] <apachelogger> bstds
[20:33] <bambee> apachelogger: np
[20:43]  * Quintasan throws bricks at apachelogger
[20:43] <Quintasan> Y U NO COPYRIGHT IT KITEN?
[20:43] <apachelogger> Quintasan: wut?
[20:43] <apachelogger> I am working on kiten
[20:43] <apachelogger> it has missing interfaces
[20:43] <apachelogger> and we are not quite sure why it is packaged as public lib to begin with
[20:43] <apachelogger> completely moot
[20:43] <Quintasan> http://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging/kiten/files/head:/debian/
[20:44] <yofel_> apachelogger: late pong
[20:44] <Quintasan> apachelogger: Also, shouldn't we fc@#!%! decide on a sane copyright for packaging?
[20:44] <apachelogger> I am all sexed up
[20:44] <Quintasan> Should we go Copyright: 2011 Kubuntu Developers<EMAIL_ADDRESS>[20:44] <apachelogger> nah, I like my copyright
[20:44] <Quintasan> Or just everyone claims it for himself?
[20:44] <apachelogger> :P
[20:45] <yofel> I did use kubuntu devels in copyright for our split packaging
[20:45]  * yofel looks what we're at
[20:45] <yofel> _Groo_: you could work on 4.6.5 if you don't want to work on oneiric
[20:46]  * Quintasan goes with GPLv3 for his licensing
[20:46] <Quintasan> packaging*
[20:46] <_Groo_> yofel: true... im gonna figure out what i can do this week, which is a little short on time
[20:48] <yofel> sure
[20:48] <Quintasan> apachelogger: libpkgs_gen_strict_local_shlibs = $(libpkgs_all_packages)
[20:48] <Quintasan> What is that doing?
[20:48] <apachelogger> being strict
[20:49] <Quintasan> apachelogger: Explain further
[20:53] <_Groo_> guys, im having this error when building calligra git, but the lib is there: dpkg-shlibdeps: error: couldn't find library libkundo2.so.8 needed by debian/karbon/usr/lib/kde4/karbontools.so (ELF format: 'elf64-x86-64'; RPATH: '').
[20:53] <_Groo_> and libkundo2.so.8 is right there in tmp/usr/lib/
[20:53] <_Groo_> so why cant it be found?
[20:53] <yofel> _Groo_: the file is in no .install file
[20:53] <_Groo_> yofel: aaaaaaaaaaaaaaaaaaaaaaaaaaaahhhhhhhhhhhhhhhhhhhhhh ok
[20:53] <yofel> so it's not actually installed in any package
[20:54] <_Groo_> gotcha
[20:55] <_Groo_> tks
[20:57] <Quintasan> lol
[20:57] <Quintasan> Latest commit
[20:57] <Quintasan>  	5. me be maintainer
[20:57] <Quintasan> hurpdurp
[20:59] <yofel> fooey, kdeartwork has ~2050 files in list-missing
[21:01] <Quintasan> LOL
[21:01] <Quintasan> yofel: Have fun ^_^
[21:02] <Quintasan> apachelogger: fix EGL on iMX nao
[21:02] <apachelogger> Quintasan: come hang out with us on google_
[21:02] <apachelogger> + even
[21:02] <Quintasan> lol?
[21:03] <yofel> why should I use something that's like facebook but not facebook?
[21:03] <apachelogger> so you can have hangouts
[21:04] <yofel> hahah
[21:04] <Quintasan> How does one hangout on Google?
[21:05] <Quintasan> apachelogger: Add me
[21:06] <apachelogger> you should see me hang out
[21:06] <apachelogger> in your stream
[21:06] <KRF> do you have your hat on?
[21:06] <KRF> might join then
[21:07] <Quintasan> apachelogger: Can't see that
[21:07] <KRF> apropos, where's kde 4.7 for natty?
[21:07] <KRF> apachelogger: work harder!
[21:07] <apachelogger> Quintasan: does you see me now?
[21:08] <apachelogger> KRF: I pulled like 5 packages today
[21:08] <apachelogger> them other lazy bstds are too lazy
[21:08] <Quintasan> apachelogger: nope
[21:08] <apachelogger> Quintasan: what is your gmail addy?
[21:08] <KRF> btw, how is that neon thing supposed to work? when i install those project-neon-foo packages, do i get a new xsession entry for the KDE beta?
[21:08] <Quintasan> apachelogger<EMAIL_ADDRESS>[21:09] <Quintasan> KRF: Yes, you get a new session entry in KDM
[21:09] <apachelogger> you should have an invite somewhere
[21:09] <KRF> ah, cool
[21:09] <KRF> gonna try that, then
[21:09] <Quintasan> KRF: we install everything in /opt so it doesnt mess with your stable settings
[21:09] <KRF> ++
[21:10] <Quintasan> FFFFFFFFFFFF
[21:10]  * KRF .oO(imagines harald sitting nakkid in from of his computer hanging out with others)
[21:11] <apachelogger> under the table I am nakkid
[21:11] <KRF> uh, i don't want to imagine
[21:13] <apachelogger> lol, I know you do
[21:13] <Quintasan> apachelogger: Can you hear me?
[21:13] <apachelogger> no
[21:13] <apachelogger> also no seey seey
[21:13] <Quintasan> FCK
[21:15] <Quintasan> It works like shit here
[21:15] <Quintasan> or doesnt work at all
[21:16] <apachelogger> Quintasan: you have broken software
[21:16] <claydoh> ooh google+, another place where I probably will have few friends :D
[21:16] <_Groo_> can non official minnions have + invites too?
[21:16] <Quintasan> god damn :S
[21:17] <Quintasan> PULSEAUDIO--
[21:18] <Quintasan> OH GOD
[21:18] <Quintasan> JR as an security officer
[21:18] <apachelogger> rofl
[21:19] <Quintasan> apachelogger: I'll pass on that
[21:19] <Quintasan> Can't speak
[21:19] <Quintasan> damned pulse
[21:19] <apachelogger> Quintasan: pavucontrol helps
[21:20] <Quintasan> + it hangs every browser I have
[21:20] <Quintasan> :/
[21:21] <KRF> try lynx
[21:27] <apachelogger> Quintasan: chrome it
[21:29] <Quintasan> apachelogger: What are you drinking?
[21:29] <Quintasan> yofel: libkdeedu (>= 4:4.6.90) which is a virtual package. @_@
[21:30] <yofel> how about libkdeedu-dev?
[21:30] <yofel> libkdeedu doesn't exist
[21:30] <Quintasan> hmm
[21:31] <Quintasan> apachelogger: chroming it
[21:32] <apachelogger> Quintasan: should be goody enough
[21:35] <Quintasan> apachelogger: this stuff is fckd up
[21:36] <apachelogger> something must be broken on your end
[21:36] <Quintasan> I blame my fucking microphone
[21:38] <Quintasan> bleh
[21:38] <Quintasan> gotta try that tomorrow
[21:38] <KRF> in the good old days you didnt need a microphone to hang out :/
[21:40] <Quintasan> Parley's done, I'm going to bed
[21:40] <apachelogger> KRF: you need to know a language though
[21:40] <apachelogger> that sucks
[21:40] <apachelogger> if parley is not packaged
[21:40] <apachelogger> Quintasan: nini
[21:50] <yofel> bah, good night too


[00:50] <elky> but whyyyyyyyy?
[00:50] <rww> ssshhhhhhhh
[01:07] <Pici> elky: because you ran for the positionnnnn
[01:07] <Pici> ;P
[02:28] <madsailor>  Hello all.  I have noticed that questions go unanswered for long periods sometimes in #ubuntu-beginners.  Would it be possible to have ubottu msg a redirect to the main #ubuntu channel rather than leaving people to wait indefinately?  Would this be a bad idea for some reason?
[02:28] <bazhang> madsailor, how about you giving them a nudge yourself? something like, you may get a quicker answer in #ubuntu
[02:30] <madsailor> bazhang, I do, and I try to help if I feel I can, but obviously there are times when everyone there is really just lurking
[02:30] <bazhang> madsailor, well sometimes no one knows the answer, no matter the channel
[02:31] <madsailor> bazhang, true.  Just thought that the main channel is more likely to have an answer since it is so much higher volume, and there is almost always someone active
[02:32] <bazhang> madsailor, thus my initial suggestion
[02:35] <madsailor> I understand. I can manually redirect.  Anyone can.  But sometimes no one is paying attention.  Ubottu can continuously pay attention when lurkers are elsewhere (or uninterested in typing the same please check in #ubuntu message for the #####'th time))
[02:36] <m4v> madsailor: we can't do that automatically in a reliable way or guaranteed that I won't be abused.
[02:36] <m4v> it*
[02:38] <m4v> bazhang suggestion is the best, if nobody is looking then the channel needs more active people, not a patch-work with a bot.
[02:38] <gpc> madsailor: it is a good idea but it is worth noting that not everybody is always available to help. Perhaps speaking with the channel ops and see if they want to add something in the channel topic about #ubuntu.
[02:39] <gpc> I can tell you for certain that 11 of the people who are voiced in that channel would have no problem with you sending them a PM, the rest I am sure would be fine with it also
[02:42] <madsailor> gpc, channel topic is a good idea.  I realize people are often busy w/other things and/or can't help with a specific issue.  I just thought having a helpful redirect when that was the case might be useful, but I suppose it could be abused
[02:42] <gpc> thing is there is no easy way of making the bot sentient
[02:42] <gpc> :)
[02:42] <m4v> yeah.
[02:43] <madsailor> maybe you can get ubottu a date with watson;)
[02:44] <m4v> ubottu: you wanna date Watson?
[02:45] <madsailor> haha...guess she'll need to be programmed with some livelier dinner conversation first
[02:45] <nhandler> madsailor: FYI, in the future, it usually helps if you go to the OPs for the channel (especially for a team channel like that). This sort of thing would be much better handled with a /topic or entrymsg than a patch for ubottu
[02:47] <madsailor> nhandler, ok.  Will do that in the future. thanks all!
[15:56] <Tm_T> awww
[16:03] <Pici> hrm, thats annoying.
[16:04] <DJones> I'm guessing that 8ball is a bot in -cym that answers yes/no
[16:04] <Tm_T> is not
[16:05] <DJones> Ah well
[16:05] <Tm_T> atleast wasn't when I last time were there
[16:06] <DJones> Has it been sorted out, or is it worth me querying with brobostigon, he's talking -uk, or was it just botabuse
[16:07] <Tm_T> I can talk to him if he continues
[16:07] <DJones> ok
[16:08] <Tm_T> I even might practice my cymraeg skills while doing so (:)
[16:09] <vish> "cym" is which locale?
[16:09] <DJones> Cymri - Wales
[16:09] <vish> oh!
[16:10] <DJones> Sorry, should be Cymru
[16:10] <DJones> Tm_T: I can only remember one word of Welsh from spending 3 years there at college
[16:12] <Tm_T> DJones: I might remember ~10 words
[16:13] <vish> interesting, i never would have made the connection to Wales..  thanks. :)  when 'cymraeg' was mentioned i thought it might be connected to reggae or something..
[20:53] <ubot4> pleia2 called the ops in #ubuntu-locoteams ()
[21:00] <pleia2> sorry, I should have acked that this is handled :)
[21:01] <Pici> tsk tsk :P
[21:01]  * pleia2 hugs Pici
[21:01] <Pici> I noted it a bit late anyway ;)


[15:49] <stevie_man> hey all, I'm trying to get my backend up and running but I cannot connect to the database. I get the error: "Cannot login". Why I try to login to mysql using the mythtv user I get access denied for user 'mythtv@localhost'. I let myth do the whole automatic table setup thing
[15:56] <tgm4883> stevie_man, is mysql started
[15:57] <stevie_man> tgm4883: yes, I was looking at the logs and I think mythbackend was using the hosts entry for <IP_ADDRESS> I had that said zues (name of the server) and not the one that said localhost
[15:58] <tgm4883> stevie_man, so 'mysql -u mythtv -p mythconverg' gives you access denied?
[15:58] <stevie_man> yep
[15:59] <tgm4883> odd
[15:59] <stevie_man> very
[15:59] <tgm4883> I'd try resetting it
[15:59] <tgm4883> !mysql
[15:59] <Zinn> If you are having problems connecting to your mysql database, perform the following to reconfigure it: [1] sudo dpkg-reconfigure mysql-server-5.5 (pay attention to the root password you set, you will need it later)  [2] sudo dpkg-reconfigure mythtv-database [3] sudo dpkg-reconfigure mythtv-common
[15:59] <stevie_man> I'm going to wipe everything and try again with the <IP_ADDRESS> zues entry commented out
[16:05] <stevie_man> So here is my mythbackend log. http://pastebin.ubuntu.com/6184448/
[16:05] <stevie_man> Yes I know I'm using .24 it's for testing only before I switch everythinf over to .27
[16:11] <tgm4883> stevie_man, did you go though mythtv-setup?
[16:11] <tgm4883> stevie_man, that is so old, i'm not even sure I remember all of the oddities of it
[16:15] <stevie_man> yah, that's what is generated when I do the mythtv-setup
[16:27] <stevie_man> what is this? Using configuration directory = /var/lib/mythtv/.mythtv
[16:27] <stevie_man> when I try to cd into it I'm told it is not a directory and when I try to edit it it's not a file
[16:28] <tgm4883> it looks like it thinks that is the home directory for the mythtv user
[16:28] <tgm4883> what did you do?
[16:28] <stevie_man> Nothing that I know of
[16:28] <tgm4883> what version of ubuntu is this?
[16:29] <stevie_man> I'm on Debian Squeeze
[16:29] <tgm4883> ok, where did you install the packages from?
[16:32] <stevie_man> from www.deb-multimedia.org
[16:33] <tgm4883> hmm
[16:33] <tgm4883> stevie_man, so for some reason, their packages are looking in that directory for the config files
[16:33]  * tgm4883 shrugs
[16:34] <stevie_man> even better the setup didn't create the mysql users this time around
[16:34] <stevie_man> oh that one was my fault
[16:35] <tgm4883> stevie_man, this is why I tend to recommend mythbuntu
[16:35] <stevie_man> yah, this is only a test, a prove of concept before I replace my working mediaportal frontends with mythbuntu
[16:38] <stevie_man> so even before I run the ,ythtv-setup the user cannot connect to the database
[16:41] <tgm4883> is the user even setup in the database?
[18:20] <stevie_man> tgm4883: The user was setup in the database twice. One @localhost and once @%
[18:42] <stevie_man> What does the mythbuntu-repos.deb file do? (located at http://www.mythbuntu.org/files/mythbuntu-repos.deb)
[18:43] <tgm4883> stevie_man, it adds the repos tab to MCC for versions prior to 12.04
[18:44] <stevie_man> ah, can I use this to install .25 then? (11.04?)
[18:46] <tgm4883> yea I think it's still available
[18:46] <tgm4883> yea it's still available
[20:02] <stevie_man> tgm4883: how do I use the mythbuntu repo installer package once it is installed?
[20:03] <tgm4883> stevie_man, you need mythbuntu-control-centre
[20:05] <stevie_man> oh so I need to be in mythbuntu to use the repo-installer?
[20:05] <tgm4883> stevie_man, no, mythbuntu-control-centre is another package. the repo installer is a plugin for i
[20:11] <stevie_man> ah, I guess there isn't a control centre for Debian


[15:42] <applepi> Does anyone else have an issue with all the init scripts being run twice in 1404 core armhf?


[00:23]  * mattman_ is away:
[00:37] <poolie> mkanat: mwh says if you request access to ~loggerhead-team he will approve it
[00:37] <mkanat> poolie: Okay, will do.
[00:37] <mkanat> Done.
[00:49] <poolie> hi spiv?
[00:52] <mkanat> jam: Thanks for the cvs2bzr recommendation. Worked like a charm.
[00:56] <spiv> Good morning :)
[01:46] <lifeless> spm: are you familiar with the new bazaar website deployment?
[01:47] <spm> lifeless: as in for http://bazaar.canonical.com/ ?
[01:47] <lifeless> yes
[01:48] <spm> heh, no. not familiar with.
[01:48] <lifeless> poolie has asked me to look at why an rss feed cron job in it isn't.
[01:48] <lifeless> and crontab -e as bzr-website on the machine -> empty file
[01:51] <spm> is that the way rss feeds are generated for the site? as in some I've worked with previously (geeklog springs to mind) encode the generation of rss in every home page request (I deliberately disabled THAT gem).
[01:51] <lifeless> :>
[01:51] <lifeless> yeah
[01:52] <lifeless> so I think I have it sorted - thanks
[01:55] <lifeless> ftr, its running from poolies crontab
[01:57] <poolie> thanks for all the reviews jam
[01:57] <poolie> i should migrate them...
[01:58] <spm> lifeless: coolio. possibly we should have a 'bzr' account to run those sorts of things, but that works.
[01:59] <poolie> there is a bzr-web
[01:59] <poolie> (or something like that) role account
[01:59] <poolie> i should migrate the cron jobs to run in that
[02:00] <spm> that works
[02:00] <mtaylor> lifeless: is there a reason you have not merge in my pandora-build packaging updates? or have you just not gotten to it?
[02:10] <lifeless> mtaylor: time, yeah.
[02:12] <mtaylor> lifeless: ok. just wanted to make sure it wasn't blocking on me
[02:15] <lifeless> I don't think so.
[02:15] <lifeless> Was moving country etc.
[02:15] <lifeless> the hits keep on coming ;>
[02:31] <mtaylor> lifeless: you were moving country?
[02:32] <mtaylor> lifeless: where do you live now?
[02:32] <lifeless> NZ
[02:32] <mtaylor> ah.
[02:33] <mtaylor> so you're even closer to my timezone now :)
[02:33] <lifeless> yes
[02:33] <mtaylor> woot
[02:33] <lifeless> except when I'm in .au (now), or europe (week after next)
[02:33] <mtaylor> well right
[02:33] <mtaylor> same goes for when I'm in other places - or when new zealand moves into the indian ocean
[03:03] <lifeless> http://www.paulhammond.org/2010/06/trunk/
[03:06]  * spiv hmms at a stacking test
[03:10] <poolie> spiv :)
[03:10] <poolie> so you're going to tackle those other bugs and then prod merge cleanups?
[03:11] <poolie> (if so that's fine with me)
[03:11] <spiv> poolie: yep, exactly
[03:19] <spiv> Can I get an incremental review of just http://bazaar.launchpad.net/~spiv/bzr/reconfigure-unstacked-551525/revision/5331 ?  I had some minor test fallout.
[03:22] <lifeless> +1
[03:23] <spiv> lifeless: thanks
[03:24] <lifeless> thanks for the direct link
[03:24] <lifeless> I wish that page didn't need a click to see the diff
[03:31] <lifeless> -> fud
[03:31] <parthm> i am trying to deprecate osutils.re_compile_checked. adding @deprecated_function(deprecated_in((2, 2, 0))) produces 'no attribute _format_version_tuple' http://pastebin.com/EeEiLfbx
[03:31] <parthm> should i be doing something differently?
[03:36] <spiv> parthm: argh, imports :/
[03:37] <spiv> parthm: the issue is that _format_version_tuple in bzrlib/__init__.py is defined after the import of bzrlib.lazy_regex
[03:37] <spiv> The fix is probably to move the definition _format_version_tuple above that import.
[03:38] <parthm> spiv: oh. ok. i can fix that and send it separately for merge if that works.
[03:38] <spiv> Or do the deprecation without using the decorator, I suppose.
[03:38] <spiv> (I don't have a strong opinion either way)
[03:41] <parthm> spiv: i will go ahead and am a separate patch for that. its a trivial change anyway. its nicer to use the decorator.
[03:57] <parthm> spiv: https://code.launchpad.net/~parthm/bzr/format_version_tuple_import_order/+merge/28953
[04:07] <spiv> parthm: reviewed, thanks
[04:12] <parthm> spiv: thanks. i fixed the comment. do you think its a small enough change to send to pqm or do we need another review?
[04:18] <spiv> parthm: Fine to send, I think.
[04:19] <parthm> cool. thanks. i will send it.
[04:33] <lifeless> parthm: hi
[04:34] <lifeless> parthm: I gave similar advice to john earlier in the review of your bad ignores branch
[04:34] <lifeless> parthm: Perhaps you missed it? I'd like to help you land that branch.
[04:40] <parthm> lifeless: hi. i might have missed it. what are you referring to?
[04:40] <lifeless> the layering - passing in info about where patterns came from etc
[04:42] <parthm> lifeless: ah. yes. thats probably a good way to go. i might have missed it earlier. the comments on the patches were really growing long :)
[04:43] <parthm> lifeless: i plan to look at that once the current patch (part-1) lands
[04:53] <spiv> Hmm, there are a few TODO comments in chk_map talking about improvements that weren't done because we didn't have a pure-python StaticTuple
[04:54] <spiv> There might be some cheap wins to be found there
[05:01] <lifeless> spiv: revision specs could use cleanups
[05:03] <spiv> lifeless: very much, yes
[05:04] <spiv> lifeless: the trick is doing it without disrupting 3rd party implementations & callers too much, I think
[05:04] <spiv> But right now, lunch!
[05:06] <lifeless> spiv: yes; I made the comment when working on loom.
[07:33] <vila> hi all !
[07:33] <mneptok> vila: salut
[08:01] <lifeless> night all
[08:03]  * poolie is trying to backport python-configobj to dapper in the ppa
[08:03] <poolie> hi there parthm vila
[08:15] <johnf> Say I have to releases trunk and release and I need to fix a bug in release but trunk has moved on. Am I better off fixing it in trunk and then cd release; bzr merge -r REVISION_ID ../trunk
[08:15] <johnf> or fix it in release and merge back into trunk
[08:15] <johnf> or it doesn't matter or some other better way? :)
[08:17] <spiv> If you merge release branches back into trunk (which is how bzr manages its branches), then branch off release and fix it there is typically easiest.
[08:17] <spiv> Because then your fix branch can be merged directly into both your trunk and release branch.
[08:17] <johnf> spiv: ok that's what I thought. Thanks
[08:18] <spiv> But fixing in trunk and then backporting via "bzr merge -c BLAH ../trunk" is not too painful either, although it leaves bzr with slightly less complete information in the revision history.
[08:22] <echo-area> If I'm going to make a repository public for all users on a host, what's the recommended way?  Currently 'chmod -R 777 repo-dir' comes into my mind
[08:23] <poolie> if you want to let them all commit to it?
[08:23] <poolie> that would do
[08:23] <echo-area> poolie: Okay, thank you.
[08:28] <echo-area> And I suddenly find there are very large files (~3.7G) in my ~/.bazaar/svn-cache directory.  Can I delete it?
[08:34] <spiv> You can.
[08:35] <spiv> (But bzr-svn may need regenerate some or all of them later if you access a SVN repo with bzr.)
[08:39] <echo-area> spiv: Fine.  Storage is a more critical factor than speed for me now :)
[08:40] <lifeless> poolie: I was taking a bet with myself whether you'd have finished yet :)
[08:41] <lifeless> mgz: hey, when you get here, it might be nice for us to put heads down and get a subunit + testtools release done
[09:07] <swathanthran> http://pastebin.ca/1892599 what can be the problem?
[09:12] <vila> swathanthran: s/lh/r/
[09:12] <vila> swathanthran: try it with a web browser and you'll realize you're using the wrong url (use 'r' not 'lh')
[09:13] <swathanthran> yeah i guessed that but didn't know what to use instead of lh
[09:13] <swathanthran> and lh is disabled on savannah.
[09:14] <vila> swathanthran: I walked up to the root to find it
[09:15] <vila> swathanthran: I don't know what is going on with lh on savannah
[09:16] <swathanthran> anyway to find out how much size it could be?
[09:17] <vila> what ? savannah ? loggerhead ? the branch ?
[09:17] <swathanthran> sorry, the branch..
[09:17] <vila> swathanthran: 147.685  Transferred: 60985kB (413.9kB/s r:60931kB w:54kB)
[09:17] <swathanthran> to find out how much size it could be to download, before downloading
[09:18] <swathanthran> vila: ok thanks.
[09:18] <vila> swathanthran: there is no easy way to find that without downloading :) It depends on what you want to download and that can be a part of the whole
[09:19] <swathanthran> ah
[09:20] <vila> the bulf of the data is the revisions, but you can branch from an older revision or the branch's repository can containg more revisions that you need to download
[09:20] <vila> and you may already have some revisions locally and don't need to download them
[09:21] <swathanthran> oh yeah, how to download the sources alone?
[09:23] <swathanthran> bzr co --lightweight?
[09:24] <vila> that's one way, another is: bzr export  builder.tgz http://bzr.savannah.gnu.org/r/gnewsense/builder
[09:24] <vila> but the former will allow you to update at will
[09:25] <swathanthran> oh thats great.. i actually wanted just the current version..
[09:27] <vila> swathanthran: right, if it's a one-time only operation it's ok, but you'll pay the full price the next time you need it otherwise
[09:27] <swathanthran> sure, at night, i don't have to pay for the net, to get along with work now, i have ot pay for the bandwidth;-)
[09:27] <swathanthran> bzr export does it without having the branch on our system?
[09:28] <vila> swathanthran: both export and co --lightweight won't store the downloaded revisions, you'll pay at each use :)
[09:29] <vila> swathanthran: if you use a local branch, you'll only need to download the new revisions next time
[09:30] <swathanthran> yeah got that.. i'll do a full branch at night when i have bandwidth..
[09:30] <swathanthran> and cool, i just got builder.tgz and it was like 20mb or so i guess.
[09:31] <spiv> G'night all.
[09:33] <vila> spiv: g'night
[09:34] <swathanthran> vila: thanks !:)
[09:38] <swathanthran> without loggerhead, can i have an http link to just one file on the repo?
[10:44] <Glenjamin> hi guys, i'm wondering if anyone can help me out; i'm getting this traceback http://pastebin.org/369909 whenever I try and checkout some branches from my SVN repo
[10:47] <maxb> Glenjamin: It looks like you might be branching into an existing shared repository.... if so can you try without?
[10:51] <Glenjamin> there's a whole bunch of inconsistent details in skipped record errors along the way - but the checkout appears to have worked.
[10:52] <Glenjamin> does this mean my shared repo is corrupt in some way?
[10:53] <maxb> Sounds like it
[10:54] <maxb> Try 'bzr check' to get more info, and 'bzr reconcile' to try to fix it
[10:59] <Glenjamin> i guess bzr check sitting there not spitting out any output for a while is probably just it working
[10:59] <Glenjamin> seems to be munching cpu, so i'll trust it
[11:03] <lifeless> check is not optimised -> by which I mean its pretty slow compared to many other commands
[11:06] <Glenjamin> fair engouh really
[11:06] <Glenjamin> http://pastebin.org/369954 was my output
[11:06] <Glenjamin> do i just do reconcile on the repo now?
[11:07] <lifeless> reconcile can't fix the ghosts
[11:07] <lifeless> it can fix the parents.
[11:07] <lifeless> that may fix your error
[11:07] <lifeless> have you looked in the bzr-svn bug tracker ?
[11:07] <Glenjamin> i have, the only similar errors are from 2008 and marked as fixed.
[11:07] <lifeless> ok
[11:07] <lifeless> take a backup
[11:08] <lifeless> then give it a shot
[11:10] <Glenjamin> bah, no luck :(
[11:10] <Glenjamin> i guess i'd better post the bug
[11:35] <Glenjamin> cheers for the help guys, fresh repo from SVN seems to be working :)
[15:00] <jam> GaryvdM: are you currently working on desolation?
[15:00] <jam> (no problem if you are, just checking)
[15:09] <GaryvdM> Hi jam
[15:09] <GaryvdM> I am, but am about to go to ice hockey.
[15:09] <GaryvdM> Trying 1 last build
[15:09] <jam> np
[15:10] <GaryvdM> jam: do you normally work in cygwin bash, or window cmd?
[15:10] <jam> GaryvdM: *I* work in cygwin bash
[15:10] <jam> I believe Ian was working under cmd using gnumake for win32
[15:11] <jam> rather than cygwin make
[15:11] <jam> I just find setting up cygwin a whole lot easier
[15:11] <jam> setup.exe is at least a cygwin package manager
[15:11] <GaryvdM> yes
[15:12] <GaryvdM> ok I'm off to ice hockey
[15:13] <jam> GaryvdM: have fun
[16:09] <vila> aaaaargh lp ! come back !
[16:20] <jam> jelmer: when you get this, 'bzr-svn' doesn't seem to have a tag for 1.0.3
[16:20] <jam> vila: hi
[16:20] <jelmer> jam: that's correct, since 1.0.3 is not out yet
[16:21] <jam> ah, I misread your lp page then
[16:21] <vila> hi jam !
[16:21] <jam> building the installer for 2.1.2 and hacking together the old scripts
[16:21] <jam> I think igc's updates were a push in a good direction, but I don't fully understand them, and they aren't working *right now* so easier for me to start with a known place
[16:22] <jam> jelmer: yeah, looking now I see 1.0.3 is an open circle.  But I'll give it a shot :)
[16:42] <jam> the FAQ I linked claims they use it to avoid cross-site scripting
[16:42] <mwhudson> no
[16:42] <jam> so all POSTs to LP now have to have a Referrer
[16:42] <mwhudson> cross site request forgery
[16:43] <mwhudson> not quite the same
[16:43] <mwhudson> in particular: no scripting
[16:43] <jam> mwhudson: so what is the specific problem if my web page helps you to upload something or update a bug on lp?
[16:43] <jam> is it more of a 'don't send your login credentials to 3rd party sites' ?
[16:44] <maxb> The idea is that javascript on some other site can't trick you into making a POST to launchpad to do something evil, using your cookie
[16:44] <mwhudson> maxb: again, not javascript, javascript already can't do that
[16:44] <mwhudson> boring old html can though
[16:45] <jam> mwhudson: so... will any edge.launchpad.net url work as the referrer?
[16:45] <mwhudson> http://en.wikipedia.org/wiki/Cross-site_request_forgery
[16:45] <exarkun> For that purpose, isn't a missing referrer as good as a correct launchpad.net referrer?
[16:45] <mwhudson> jam: probably
[16:46] <jam> exarkun: some people disable referrers in their web browser
[16:46] <jam> and they want to protect you from yourself
[16:46] <jam> it seem
[16:46] <jam> seems
[16:46] <mwhudson> a better fix is nonces in the form, but that would be considerably harder to trick with curl i guess :)
[16:46] <jam> mwhudson: the best part is because of how http uploads work, you don't find out about the failure until *after* you've upload 4MB of content
[16:46] <mwhudson> and the real real fix for uploads specifically is an api to do it
[16:47] <exarkun> jam: 100 Continue !!!
[16:47] <mwhudson> exarkun: ptth!
[16:47] <exarkun> mwhudson: yea, I was gonna say
[16:47] <exarkun> mwhudson: haha.
[16:48] <jam> and, of course, all of this worked 3 months ago when I was doing it last
[16:49] <jam> like 5+ things broke in the windows installers steps
[16:49] <jam> mwhudson: so --referrer https://edge.launchpad.net worked just fine
[17:19] <jam> vila: true story. Trying to download the svn binaries leads to URL recursion. It seems they redirect you to a second page, which then sets a cookie and redirects you back to the first page. If you don't carry your cookies along, then you get infinite recursion.
[17:19] <jam> *sigh*
[17:23]  * vila bangs head on desk
[17:24] <jam> vila: building the windows installers is being a real joy
[17:24] <jam> ...
[17:24] <jam> I remember why I loved doing them so much in the past
[17:25]  * jelmer sees his sarcasm-o-meter pan out
[17:25] <jam> it seems that everything in the world decided to change in the last 3 months, just to thwart us
[17:25] <jam> zlib has a new release without a similar dll build
[17:25] <jam> lp now requries referrer to be set
[17:26] <jam> ian did a lot of work to update the installer, but I don't quite follow how it should work yet
[17:26] <jam> svn moved to apache
[17:26] <jam> and doesn't have *new* dlls, and now the old dlls have crazy redirects
[17:26] <jam> qbzr didn't tag 0.19b1 in their trunk
[17:26] <jam> ah they did, but as '0.19beta1'
[17:27] <jam> anyway... getting there
[17:28] <jam> we shut down the old desolation instance, and it may have only been working because all the files were already cached in d:
[17:31] <vila> jam: :-/
[17:31] <vila> so before I EOD, you want me to confirm that as soon as the test suite is passing on windows I will set up babune for windows daily builds ? :-D
[17:31] <jam> anybody knows how to fake a buildout signature so that we can manually do the download and work around buildout trying to be extra helpful
[17:33] <vila> err, won't that make the next failure even more horrible to address ?
[17:35] <jam> vila: I don't care, I want to get builds
[17:35] <jam> stuff is der broken
[17:35] <jam> I'm asking sidnei for help, hopefully he can help work out the buildout stuff
[17:36] <jam> vila: right now I'm reverting back to my old code because it actually works
[17:43] <jam> and I'd really like to switch to what Ian was working
[17:43] <jam> on
[17:51] <chaosaddict> it sounds like the fast-import format prefers ASCII with the exception of raw file data. Is it possible to have non-ascii filenames? I've been having a lot of trouble with latin-1 encoded filenames from Perforce importing into Bazaar.
[17:53] <jam> chaosaddict: I believe the data stream is assumed to be in utf-8
[17:53] <jam> any way you can get the perforce output to .decode('latin-1').encode('utf-8') ?
[17:55] <eydaimon> hi. how is this even possible? http://pastie.org/pastes/1026887
[17:55] <chaosaddict> jam: I believe I have that working, and the fast-export-from-p4 part works. However then the fast-import step crashes. I haven't figured out the root cause on that yet.
[17:55] <jam> chaosaddict: tracebacks help
[17:55] <chaosaddict> jam: unfortunately it spits out a parsing error, rather than a crash + traceback.
[17:56] <jam> eydaimon: One side has: "pu = PaymentUser" and the other side only has "PaymentUser"
[17:56] <jam> I don't know what .rvmrc is, but it appears to be something your vim dropped in the current working dir
[17:57] <jam> eydaimon: otherwise I don't really understand your question
[17:57] <eydaimon> jam: The point I'm making is that after modify the file, and I resolve it, there's nothing to check in
[17:57] <eydaimon> jam: and if I merge again, I get exactly the same thing happening
[17:57] <jam> eydaimon: I don't really know. I would think at the least the merge revision would be ready to be committed.
[17:58] <eydaimon> exactly
[17:58] <jam> Though maybe this is because of the "infinite merge request" issue
[17:58] <eydaimon> sounds like
[17:58] <jam> merging a => b creates a commit that can be merged b => a
[17:58] <eydaimon> is that an open bug?
[17:58] <jam> so we probably added code to prevent that
[17:58] <jam> which is triggering here
[17:58] <jam> I don't think this is an open bug
[17:58] <jam> which is
[17:58] <eydaimon> then how can I address it?
[17:58] <jam> conflict resolution leading to know content change is preventing commit
[17:58] <jam> or something along those lines
[17:59] <jam> eydaimon: worse case you can make a trivial change somewhere
[17:59] <eydaimon> I don't want merging with trunk forever more to cause conflicts
[17:59] <jam> but I'm also surprised that 'bzr status' doesn't say anything
[17:59] <jam> can you paste the output of "bzr merge ; bzr status" *before* you resolve the conflicts?
[17:59] <eydaimon> yeah
[18:00] <jam> you might want to use paste.ubuntu.com, your formatting came out a bit weird on pastie
[18:00] <eydaimon> I already show the first merge
[18:01] <jam> eydaimon: you showed the merge, but not 'bzr status' afterwards
[18:02] <eydaimon> reload pastie to see changes
[18:03] <jam> eydaimon: so something is odd about your merge, as it isn't recording a revision to be merged
[18:03] <jam> ahhh
[18:03] <jam> you are doing a single file merge
[18:03] <jam> that doesn't get recorded
[18:03] <jam> you have to do a full tree merge
[18:04] <eydaimon> k
[18:04] <eydaimon> I would do that but there's one of the files I didn't know how to handle
[18:04] <eydaimon> so I was doing a whole directory
[18:04] <eydaimon> ( was using one file as an example here )
[18:07] <mkanat> 6) Important since these often outline the actual changes in a short form or
[18:07] <mkanat> reason for why the commit were done in that specific branch.
[18:07] <mkanat> Oops.
[18:07] <mkanat> Sorry.
[18:07] <mkanat> Drag-and-drop. :-|
[18:19] <mkanat> jam: Do you still need the account on my machine?
[18:19] <jam> mkanat: only if you tell me I do :)
[18:20] <mkanat> jam: Okay, I'll test meliae first. :-)
[18:46] <mgz> garyvdm, jam: thanks for working on packaging 2.2b3 for windows
[18:47] <jam> mgz: well, my version is pretty hack-tastic, but let me know if it works for you
 zlib has a new release without a similar dll build <- you still needed to do this bit? Does svn or something also need the dll?
[18:47] <jam> mgz: since you mention it, probably not. but the build code I was using still did
[18:47] <mgz> I'm going to test it to see if my -OO change does anything bad to plugins, then send a message to list for plugin authors
[18:48] <mgz> lifeless: after I do that, I have an hour out or so for squash, but am then free all evening for testtools/subunit things
[18:50] <mgz> 'd file a bug on the referer thing jam, even though it's easy to work around, it's stupid
[18:50] <mgz> uploading doesn't sign the binaries or anything, right?
[18:50] <jam> mgz: It looks to be a purposeful design thing, so I can file it, but I think the powers-that-be have explicitly requested it
[18:51] <jam> mgz: no, I manually sign them
[18:51] <mgz> it's purposful for editing bugs and so on, but an upload isn't a db-state-changing thing
[18:51] <mgz> it's just moving bits.
[18:56] <mgz> okay, I get API version complaints from svn and rebase
[18:57] <mgz> urk, and this one is my fault:
[18:57] <mgz> ValueError: No help message set for <bzrlib.plugins.explorer.lib.commands.cmd_explorer object at 0x0114ABF0>
[18:57] <jam> dang jelmer already left
[18:57] <mgz> I *thought* I'd avoided that, and the thingy had been changed not to throw any more anyway
[18:57] <jam> send a message to the list
[18:57] <mgz> will do.
[18:57] <jam> mgz: I think it has, but that will be in 2.2b4
[18:57] <jam> which isn't released yet
[18:58] <mgz> okay, so, this is a maximally borked version, that will probably be useful
[18:59] <mgz> these plugins *are* seperate though, and should be compiled differently, I wonder what went wrong
[19:00] <jam> mgz: well, I used some old build tools
[19:00] <mgz> the setup.py is from the bzr you're shipping though, right?
[19:00] <jam> should be
[19:01] <jam> (i'm pretty darn sure it is)
[19:03] <mgz> okay, so the bit that seems not to be working is the install_data_with_bytecompile class ~line 530
[19:03] <mgz> or I misunderstood how it works
[19:03] <mgz> the idea is that things in library.zip should get optimize=2 and things in the plugins dir should get optimize=1
[19:04] <jam> mgz: sure I remember that part of the patch
[19:04] <jam> I don't know what it takes to make it work or not work, though
[19:05] <mgz> ah, urk, problem.
[19:05] <mgz> it seems the pyo files there do contain the docstrings
[19:06] <mgz> so, instead perhaps the problem is when bzr.exe runs, it does in such a way as they're not loaded?
[19:06] <mgz> which would be I need to work out how to seperate the byte compiling of py files from the mode set for the base script
[19:08] <mgz> I'll get something worked out.
[19:10] <jam> mgz: my quick-and-dirty test says it shouldn't matter
[19:10] <jam> if I compile a .py to .pyo and include the docstring
[19:10] <jam> running python -OO main.py still loads the existing .pyo and still has a docstring
[19:11] <mgz> hmpf, so that's what I originally assumed, something else must be going on
[19:11] <jam> so I would guess something else is at fault
[19:11] <jam> mgz: we need a way to get to a python interpreter from the bzr.exe :)
[19:12] <mgz> that would indeed be useful ;)
[19:12] <mgz> bzr interpreterplz
[19:12] <mgz> wait, I already have the machinery for that, have a throwaway plugin to shove arbitrary stuff in
[19:14] <jam> mgz: yeah, here is one option: http://writeonly.wordpress.com/2008/09/08/embedding-a-python-shell-in-a-python-script/
[19:14] <jam> which uses ipython
[19:14] <jam> but I think you could just have something that does "import pdb; pdb.set_trace()" and get something good-enough
[19:15] <mgz> code.interpret is it indeed.
[19:16] <mgz> dammit, we don't bundle that. pdb it is.
[19:17] <mgz> okay, so explorer does have doc strings.
[19:17] <mgz> is this going to be something daft like, that cmd really *doesn't* have one in the source?
[19:17] <mgz> I should have checked that.
[19:18] <mgz> nope, it seems it does.
[19:18] <jam> mgz: it does in my copy
[19:19] <jam> mgz: are you sure it isn't loading your *local* copy of the plugin rather than the bundled one
[19:20] <jam> and because it is running -OO it is stripping them on-the-fly
[19:20] <jam> oooh
[19:20] <mgz> okay, and it really is missing from bzr.exe's perspective, though other bits keep it.
[19:20] <jam> so your code breaks people from installing extra plugins (it would seem)
[19:20] <mgz> it does, if they don't install them correctly
[19:20] <jam> mgz: I mean, if you put something in BZR_PLUGIN_PATH it will get loaded with -OO
[19:20] <mgz> I'll check on the location, but bzr.exe should really get the path right
[19:20] <jam> which will break them
[19:20] <mgz> right.
[19:21] <jam> import bzrlib.plugins.explorer; print bzrlib.plugins.explorer
[19:21] <jam> should tell you what you want to know
[19:21] <mgz> they are all from the right place
[19:22] <jam> mgz: define 'right place'
[19:22] <jam> the bundled plugin
[19:22] <jam> or a user-installed copy
[19:22] <mgz> bundled
[19:22] <mgz> what I don't get is that bzrlib.plugins.explorer isn't stripped, but bzrlib.plugins.explorer.lib.commands is
[19:22] <mgz> and they are both from the installer
[19:22] <mgz> so... one of two things
[19:22] <jam> mgz: and what does bzrlib.plugins.explorer.lib.commands.cmd_explorer.__doc__ say ?
[19:23] <mgz> (None)
[19:23] <jam> mgz: ah, so the sub-dirs are getting stripped
[19:23] <mgz> (as in, it says nothing, because it really is None)
[19:23] <jam> I wonder if they aren't getting anything
[19:23] <mgz> right, so one of two things
[19:23] <jam> aren't-getting pre-compiled because it isn't doing something recursively
[19:23] <mgz> either the installer is being generated with some plugin files stripped and some not
[19:24] <mgz> or the installer isn't generating some plugin files, and it's happening at run time with -OO
[19:24]  * mgz checks timestamps
[19:24] <jam> mgz: I would guess the latter
[19:25] <jam> mgz: I'm going to install here, and see what files end up
[19:25] <mgz> yup, and on quick check, it's only commands.py that's 18:58 rather than 09:31
[19:26] <jam> mgz: C:\Program Files\Bazaar\plugins\qbzr\lib\commands.pyo
[19:26] <jam> exists at install time
[19:26] <mgz> but I also had a problem with qbzr, so this suggests something slightly more systematic than one missing file in a list
[19:26] <mgz> ^ack.
[19:27] <jam> timestamp of commands.py is 9:30am, timestamp of commands.pyo is 9:34 am
[19:27] <mgz> okay, nice little mystery then.
[19:28] <jam> mgz: and the timestamp isn't updated when I run bzr.exe
[19:28] <jam> but it still fails to run bzr explorer because of a missing help text
[19:30] <jam> mgz: opening the commands.pyo in vim shows that the strings are present
[19:30] <mgz> something is certainly causing them to be rewritten here.
[19:31] <mgz> just did bzr lp-propose
[19:31] <mgz> and the stamp on plugins\launchpad\lp_propose.pyo bumped to now
[19:31] <jam> mgz: my user doesn't have rights
[19:31] <jam> so probably they are being rebuilt in memory, but not getting written down
[19:31] <jam> and just not getting used here
[19:31] <mgz> ah, yup, that'd explain it
[19:32] <mgz> so, the last remaining question is why it's not just loading them from disk...
[19:33] <jam> mgz: how are you getting it to run your code? I don't seem to be able to set BZR_PLUGIN_PATH and have it respected
[19:34] <mgz> 's under .\bazaar\2.0\plugins
[19:34] <jam> ah, k
[19:34] <mgz> in BZR_HOME
[19:34] <jam> well, I got it to run, but then it imported -OO and stripped the docstring :)
[19:35] <jam> mgz: also I wouldn't be surprised if the -O setting is stored in the compiled code
[19:35] <jam> and it sees "oh, this is only -1, I'll do -2 and update it"
[19:35] <mgz> I wouldn't be, but I tested previously and it didn't do that
[19:36] <mgz> so, if it's started doing it I'd be suprised
[19:36] <jam> mgz: python2.6 vs python2.5 maybe?
[19:36] <mgz> also... this is interesting
[19:36] <jam> mgz: so that fixed my problem
[19:36] <jam> I was compiling -O in py2.6 and then running bzr.exe which uses py2.5
[19:36] <jam> after doing that
[19:36] <jam> it just loaded the .pyo without recompiling my plugin
[19:37] <mgz> ah, so, that does explain it
[19:37] <mgz> different magic bit, but from the python version not the flag
[19:38] <jam> mgz: but why would we be building them in the installer with the wrong python version
[19:38] <mgz> good news is that fixing that not only unborks me, but will make first run faster all round
[19:38] <mgz> ...and all runs, in your case where you don't have write access
[19:38] <jam> mgz: (Pdb) bzrlib.plugins.explorer.lib.commands
[19:38] <jam> <module 'bzrlib.plugins.explorer.lib.commands' from 'C:/Users/jameinel/dev/bzr/plugins\explorer\lib\
[19:38] <jam> commands.py'>
[19:38] <jam> I'm pretty sure that confirms it is loading the .py directly, and not the extension
[19:38] <mgz> yup.
[19:39] <jam> however, we are shipping .pyo and I don't see any reason why they would be invalid
[19:39] <mgz> okay, I need to leave... now-ish, but this is something worth fixing
[19:39] <GaryvdM> Hi jam, mgz
[19:40] <jam> hi GaryvdM
[19:40] <jam> mgz: well, given the installer is thoroughly broken... I have to agree :)
[19:41] <GaryvdM> jam: I see you also had zlib issues. Thats where I was stuck today.
[19:41] <mgz> well, backing out my setup.py change will unbreak, but not fix the never-using-pyo thing
[19:41] <jam> GaryvdM: yeah, but we should be able to just drop zlib completely now
[19:42] <jam> I don't know when mgz's patch landed, but we shouldn't need it in the build steps for bzr >2.2?
[19:42] <jam> I pushed the builds out by just reverting to old build scripts
[19:42] <mgz> yup, zlib change landed for 2.2b3
[19:42] <jam> which should be okay for 2.1, it looks like it shows a lot of brokenness in 2.2, but I think that is going to be there regardless
[19:42] <mgz> so, deleting it from all remaining build scripts should work
[19:42] <jam> because it is stuff like "bzr-svn 1.0.2 is incompatible with bzr2.2"
[19:43] <jam> mgz: so there is still the concern that this fix will break anyone running custom plugins
[19:43] <jam> though 2.2b4 won't raise an exception
[19:43] <jam> it will still break "bzr help myplugin"
[19:46] <mgz> right, provided they are running from a tree, not installing with setup.py
[19:46] <jam> mgz: right
[19:46] <mgz> hence message to list about this, and seeing how people use the installer with plugins
[19:47] <jam> mgz: already sent
[19:47] <mgz> it's not a big change to put in and back out, I just wanted some testing and feedback with it in
[19:48] <GaryvdM> jam: So should I see if I can make the build script use wget?
[19:48] <mgz> okay, I need to leave... five minutes ago, but will be back in an hour and a bit to help sort this out
[19:48] <jam> GaryvdM: I'm uploading to launchpad
[19:48] <jam> and have us just point there for now
[19:48] <GaryvdM> ok
[19:49] <GaryvdM> jam: If you happen to do another 2.2, please use qbzr trunk.
[19:49] <jam> GaryvdM: bug #600746
[19:49] <jam> GaryvdM: it is a bit tricky to do a "trunk" build without a tag
[19:49] <jam> any chance you could take 0.19b2 ?
[19:50] <GaryvdM> Ok - let me do that.
[19:50] <jam> s/take/tag/
[19:57] <GaryvdM> jam: I still have not worked out, where do you specify the plugin versions.
[19:58] <jam> GaryvdM: have not worked out what?
[19:59] <jam> If you are on the build host, I'm doing the work in "old-windows-installers"
[19:59] <GaryvdM> jam: Where do you specify that it should use version 0.19b1 of qbzr
[20:00] <jam> tools/win32/buildout.cfg
[20:00] <jam> (yeah, ugly place, which is why igc was fixing it)
[20:00] <GaryvdM> Ah - thanks
[20:02] <GaryvdM> jam: can one not put any revision spec in [plugin]-release-tag?
[20:03] <GaryvdM> (still going to to qbzr release
[20:03] <jam> GaryvdM: probably could, but it is pretty set up to do it this way
[20:03] <jam> I think at one point it supported grabbing the latest tip of everything for doing the build
[20:03] <jam> but I've only really done releases
[20:03] <jam> and I prefer to have tagged code in releases anyway
[20:04] <GaryvdM> Ok
[20:04] <GaryvdM> We can try use "-1" for daily builds.
[20:32] <jam> GaryvdM: something like that
[20:36] <jam> GaryvdM: have you tagged 0.19beta2 yet?
[20:37] <GaryvdM> Not yet - Going through the whole release processes
[20:37] <jam> k
[20:37] <GaryvdM> jam: I normaly make sure I can build the installers before I tag and push
[20:38] <jam> sure
[20:38] <jam> as you wish
[20:42] <jam> GaryvdM: so why were you using the ~igc branch rather than lp:bzr-windows-installers?
[20:42] <GaryvdM> jam: I soon realised that lp:bzr-windows-installers was newer, and switched to that.
[20:43] <jam> ah, k
[20:43] <jam> good
[20:46] <mkanat> Hahaha, the page that causes a memory leak in loggerhead also causes a memory leak in Chrome. :-)
[20:48] <jam> mkanat: So it really is just generating too much stuff :)
[20:48] <jam> its not leaking
[20:48] <jam> just over allocating :)
[20:48] <jam> or just showing too much stuff
[20:48] <mkanat> jam: Well, no, it leaks, in loggerhead.
[20:49] <mkanat> jam: Also, I just crashed meliae.
[20:49] <jam> is this the one I commented on? That going to the 'files' page will leak memory if you reload it a few times until gc kicks in and memory drops again
[20:49] <mkanat> jam: No, I don't think so.
[20:49] <jam> k
[20:49] <jam> mkanat: care for more details than "crashed" ?
[20:49] <mkanat> jam: Yeah, getting them. I just want to be absolutely sure that I have 0.2.1rc installed.
[20:51] <jam> mkanat: I don't doubt you've managed to do something, as your machine seems to work differently than all the other ones I've worked with :)
[20:51] <mkanat> jam: lol
[20:53] <mkanat> jam: Exact same bug; no change on my end. Does 0.2.1.candidate.1 have the fix from yesterday, or do I need trunk?
[20:53] <mkanat> jam: Well, exact same original bug.
[20:53] <mkanat> jam: It now does a fair bit of dumping, but it crashes with the same assertion and a core dump. Do you want the core, or do you just want me to give you steps to reproduce and have you log in?
[20:54] <jam> candidate.1 should have the fix
[20:55] <jam> I might have an idea of one more place to check
[20:55] <mkanat> jam: Okay. Do you want a backtrace?
[20:55] <mkanat> It will take about 20 minutes to get, because I have to install a lot of debug symbols.
[20:56] <jam> either way
[20:56] <mkanat> Okay, I'll start the process.
[20:56] <jam> steps to reproduce would be helpful too
[20:56] <jam> I was able to reproduce it before with "python -c "from meliae import scanner; scanner.dump_all_objects()"
[20:56] <jam> but I fixed that
[20:56] <jam> so it seems to depend on something else now
[20:56] <mkanat> jam: Okay. It's: ./serve-branches /mnt/mkanat-hdd/mkanat/bzr/; SIGQUIT;  then the above.
[20:57] <mkanat> jam: But the ability to SIGQUIT serve-branches is a tiny patch of my own.
[20:57] <mkanat> jam: It just adds breakin to serve-branches.
[20:57] <jam> mkanat: bzr serve --http can be SIGQUIT :)
[20:57] <mkanat> jam: Ah, okay. :-)
[20:58] <mkanat> jam: And yeah, it doesn't matter where I point serve-branches.
[20:59] <mkanat> jam: If I install Cython, will it build with it instead?
[20:59] <jam> yes
[20:59] <mkanat> Hmm, maybe I should try that.
[20:59] <jam> but I don't think that is the specific problem
[20:59] <mkanat> Okay
[20:59] <jam> the core-dump is fix #1, the pyrex is fix #2
[20:59] <mkanat> Ahh.
[21:01] <jam> is everything installed globally?
[21:01] <jam> or are you running something from source?
[21:01] <mkanat> Except meliae, now. Meliae was installed globally, but now I'm running it from a build dir.
[21:01] <lifeless> hi jam
[21:01] <mkanat> And I just installed Cython.
[21:01] <lifeless> mkanat:
[21:02] <mkanat> lifeless: ?
[21:03] <jam> mkanat: well, I don't have your install of loggerhead, etc (at least not obviously)
[21:03] <mkanat> jam: Oh, right. Yes, that's from source.
[21:03] <jam> and I don't have perms for /mnt/mkanat-hdd/mkanat
[21:03] <mkanat> jam: You don't need them.
[21:04] <mkanat> jam: Just start: ./serve-branches
[21:04] <lifeless> mkanat: saying hi
[21:04] <jam> mkanat: well, I need loggerhead
[21:04] <jam> hi lifeless
[21:04] <jam> I was hoping to avoid re-downloading it for you
[21:04] <mkanat> jam: Oh. I could branch it over to you.
[21:04] <jam> loggerhead isn't terribly big
[21:04] <mkanat> jam: Yeah, re-downloading it would be fine.
[21:05] <mkanat> lifeless: Ah, okay. :-) Howdy. :-)
[21:06] <jam> mkanat: k, I've reproduced in a slightly different way
[21:07] <jam> mkanat: how would you get a stack trace from the core dump?
[21:07] <mkanat> jam: Well, normally I'd use gdb, and it would ask me if I wanted to use yum to install stuff.
[21:07] <mkanat> Or it would just tell me to.
[21:07] <mkanat> Or there's some tool for analyzing cores.
[21:07] <mkanat> It's too bad this isn't Fedora 13, though--they have something like pygdb built in.
[21:08] <jam> well the last thing in the dump fil is _ctypes.PointerType which is probably a good hint
[21:09] <jam> yep, got a core from: py -c "from meliae import scanner; import ctypes; scanner.dump_all_objects('test.dump')"
[21:09] <mkanat> Okay. I'm installing the debug symbols.
[21:11] <mkanat> Ah, debuginfo-install python.
[21:11] <PDecker> After "bzr pull"-ing updates of my system-wide-plugins, how do I know which ones need me to "python setup.py install"?  Seems some do (like Dulwich) and most others don't.
[21:11] <jelmer> PDecker, dulwich isn't a plugin but rather one of the dependencies
[21:12] <PDecker> jelmer: It's installed in the system plugins directory, at least on this box I got.  How do we know the difference?
[21:13] <jelmer> PDecker: It wouldn't do anything if it's in the system plugin directory - how did you get it there?
[21:13] <PDecker> Took me awhile to figure out why things weren't working, and that I had to do the 'install' step.
[21:13] <jelmer> PDecker, dulwich is used by bzr-git
[21:15] <PDecker> Never used bzr before ...
[21:15] <PDecker> jelmer: *I* didn't do anything.   I got this box -- new job -- with all this biz pre-installed.  Now I'm doing the usual "fix everything that's screwed up by the nitwits in corporate IT" phase
[21:15] <mkanat> jam: Okay, I have a backtrace for you.
[21:15] <jam> mkanat: can you paste it? or copy it into my home dir?
[21:16] <mkanat> jam: I'll paste it.
[21:16] <mkanat> jam: This is the only thread that isn't in sem_wait: http://pastie.org/1027210
[21:17] <GaryvdM> jam: Is there any think I can help with related to win installers?
[21:18] <jam> GaryvdM: any idea where we are supposed to set versions in the new igc code?
[21:18] <jam> I see in 'bazaar_releases.py' that it references qbzr (for example) but nothing where it says "use version X.Y"
[21:19] <mkanat> jam: I wonder if Fedora ships patches with python. I'll go see if they have any that would affect this.
[21:20] <jam> mkanat: well certainly their assert is tripping in a release build which is strange
[21:20] <jam> but I shouldn't be tripping that anyway
[21:20] <GaryvdM> jam: Same as before:  tools/win32/buildout.cfg
[21:20] <mkanat> jam: Okay.
[21:20] <jam> GaryvdM: are you sure? All the other download urls, etc, are in bazaar_releases.py
[21:21] <GaryvdM> jam: Maybe he meant to move it but did not get to it?
[21:21] <jam> GaryvdM: I think he just never removed it
[21:21] <jam> all the stuff in build-win32 seems to be auto-generated
[21:22] <jam> afaict his code *only* builds the latest tip of each branch
[21:22] <jam> look at build-win32/buildout-bzr-2.2.cfg
[21:22] <jam> it doesn't have any versions in there
[21:22] <jam> and just accesses the trunk brancehs
[21:23] <jam> branches
[21:23] <GaryvdM> jam: let me step through the code an see if i can confirm that.
[21:23] <jam> GaryvdM: he seems to be using a jinja2 template
[21:23] <jam> if you look in buildoutgen.py
[21:24] <jam> and then templates/buildout/buildout.cfg
[21:24] <jam> and nowhere in the template does he note a way to specify a version
[21:25] <jam> (I'm getting a failure in qbzr because of a .po being changed, and I think that is because you haven't made a release so the code that generates the .po files from the .mo is actually producing a new update)
[21:25] <jam> and buildout makes sure that trees are clean before building
[21:25] <jam> and so tip of qbzr is not perfectly up-to-date
[21:25] <jam> but regardless of all that
[21:25] <jam> I need a way to force versions of plugins
[21:26] <jam> especially for building the stable releases...
[21:26] <mkanat> jam: There are patches to python, but I don't see any of them that would affect this.
[21:27] <GaryvdM> jam: ok - let me work on that
[21:28] <GaryvdM> jam: I think you tired to do a build in /cygdrive/d/bzr/bzr-windows-installers. Please could you rm /cygdrive/d/bzr/bzr-windows-installers/build-win32 -r
[21:29] <jam> mkanat: so what is the quick way to get a stack trace from a dump?
[21:29] <jam> I'm triggering it differently, but getting the same failure
[21:29] <mkanat> gdb --core=core.12476 --exec=/usr/bin/python2.6 --batch -ex "thread apply all bt" > bt
[21:29] <jam> it looks like it may be a case of a class having its own tp_traverse, but one that calls into the original one
[21:29] <jam> mkanat: and where is the core dumped, because it isn't in '.'
[21:29] <mkanat> jam: And you have to set "ulimit -c unlimited" to get the core, first.
[21:30] <mkanat> jam: Before running bzr serve.
[21:30] <jam> nice of it to say core dumped without actually dumping it :)
[21:32] <GaryvdM> jam: I created the dir, so I was able to mv build-win32 build-win32-old
[21:33] <mgz> am back.
[21:35] <jam> mkanat: so I can certainly work around the obvious bug by just saying "don't dump anything that is considered a heap type"
[21:35] <jam> sorry a 'non-heap' type
[21:35] <jam> however, it means references will be left out
[21:35] <jam> for platforms that don't have the assert tripping them up
[21:36] <jam> anyway, I have to go now
[21:36] <jam> I'll poke back at this later
[21:36] <mkanat> Okay.
[21:36] <jam> the diff is stuff like this: http://paste.ubuntu.com/458000/
[21:36] <jam> in meliae/_scanner_core.c
[21:37] <jam> GaryvdM: it looks like you reverted some of my changes in bzr-windows-installers
[21:38] <jam> namely, pointing the code at the launchpadlibrarian branches
[21:38] <mkanat> jam: I'm not quite sure I understand what leaving out references would entail.  set to False for zlib
[21:38] <GaryvdM> jam: ah - sorry
[21:38] <GaryvdM> I restore from ~ files
[21:38] <jam> mkanat: the point of meliae is that it walks references to find objects and dumps their info. Not walking references means that we won't find refs and won't dump them
[21:38] <jam> GaryvdM: anyway, I'm done for now
[21:38] <jam> good luck
[21:38] <mkanat> jam: Yeah, that sounds problematic.
[21:39] <jam> mkanat: tp_traverse was originally meant only for the garbage collector
[21:39] <jam> and it doesn't make sense to garbage collect static objects
[21:39] <jam> (non heap objs)
[21:39] <mkanat> Ahh.
[21:39] <jam> however, it is nice to find them
[21:39] <jam> by for now, see you guys tomorrow
[21:42] <jelmer> moin lifeless
[21:42] <lifeless> hi jelmer
[21:42] <lifeless> how are things
[21:43] <mgz> blast, missed jam while catching up on log
[21:43] <mgz> I need to file a bug against the installer, what project should that be?
[21:43] <jelmer> lifeless: well, trying to fix the #1 bzr-svn bug!
[21:43] <lifeless> which installer
[21:43] <lifeless> windows/mac/ubuntu/???
[21:43] <mgz> just checked 2.1.1 installer and it too overwrites pyo files at runtime rather than using the ones on disk
[21:43] <lifeless> jelmer: cool
[21:43] <mgz> win.
[21:43] <lifeless> bzr-windows-installers
[21:43] <GaryvdM> mgz: bzr-windows-installers
[21:43] <lifeless> or something like that
[21:44] <mgz> this is going to hurt perf, even if we avoid my added docstring problem
[21:44] <lifeless> ugh faaail
[21:44] <mgz> badly, for people like jam who install as admin and run with dropped privs
[21:45] <lifeless> ah yes
[21:45] <lifeless> the classic' but I waannnnnnna cache Mommy!'
[21:46] <mgz> well, library.zip avoids this, but it hurts plugins
[21:46] <lifeless> how so?
[21:47] <mgz> well, it seems that (at least some of) the pyo files for plugins shipped in the installer are for python 2.6 but the python is 2.5
[21:47] <mgz> so they need to be recompiled from the py at least once (and every load if you don't have write privs to the dir)
[21:52] <lifeless> 06:46 < mgz> well, library.zip avoids this, but it hurts plugins
[21:52] <lifeless> 06:46 < lifeless> how so?
[21:53] <mgz> pasted what I said pre-ping in /query
[21:53] <lifeless> ah
[21:54] <lifeless> so that would be a bug, not a library.zip thing
[21:54] <mgz> but if you mean the library.zip bit of that question... I presume it's a different path in the building of the installer
[21:54] <mgz> nothing would work at all of the files in the zip had the wrong magic at the start
[21:54] <mgz> (as there are no .py files in there)
[21:54] <mgz> just finishing typing up the bug entry now
[22:04] <mgz> I'm not certain it's down the python version, the shipped and recreated files appear to have the same magic
[22:05] <mgz> and it's not timestamp related... what else can cause recompilation?
[22:05] <lifeless> nothing I've heard of
[22:05] <lifeless> oh
[22:05] <lifeless> if you can't read the file
[22:06] <mgz> oh, wait.
[22:06] <mgz> the timestamp check is != rather than < isn't it?
[22:06] <mgz> that'll be it.
[22:07] <mgz> the pyo files shipped are all from a few seconds later
[22:16] <mgz> wait, I'm wrong about that too. 's the timestamp in the bytecode that matters, not the file timestamp
[22:18] <mkanat> jam: The python-meliae maintainer in Fedora has a patch! :-D
[22:19] <mkanat> I didn't even know there was a python-meliae.
[22:20] <lifeless> mgz: is the timestamp in the bytecode borked perhaps ?
[22:21] <mgz> it is, seven hours out exactly
[22:21] <lifeless> oh joy
[22:21] <mgz> is jam in gmt+7?
[22:21] <lifeless> windows not understanding GMT. again.
[22:21] <mgz> (or whoever built 2.1.1)
[22:21] <lifeless> well
[22:21] <lifeless> I think they are built in a VM on ec2
[22:21] <lifeless> but whatever
[22:28] <mkanat> jam: Anyhow, I'm working it out with the Fedora python maintainer.
[22:30] <mkanat> jam: Okay, problem is that Fedora is unintentionally shipping debug builds of python, somehow.
[22:42] <GaryvdM> mgz: You are good with these things. Any idea how to fix this: http://pastebin.org/371858
[22:43] <GaryvdM> If I run the command manually, then it works. I only fails when the build script runs it.
[22:44] <mgz> hm, funky.
[22:45] <mgz> well, the environment is messed up, I don't seem to have a devenv.com to check out though
[22:45] <GaryvdM> mgz: ok thanks for looking.
[22:46] <mgz> anything more in the buildlog html file?
[22:47] <GaryvdM> mgz: no. Its just the same output nicely formated


[08:58] <stgraber> highvoltage: I'm doing update testing now btw
[09:01] <highvoltage> stgraber: ok great, I think I'm going to skip this round of testing. I've done the last 3 images and there's been only a tiny change and I think if you run through this one then we should be good
[09:02] <highvoltage> stgraber: I'm just filling in some of the smaller todo items for release, but overall I think we're looking good for release
[09:03] <stgraber> ok
[09:04] <stgraber> I built the latest iptables for raring and now I can do IPv6 NAT (yes it's evil), though the upside is that I've got IPv6 in my VMs and containers now
[09:04] <stgraber> and with archive being on IPv6, I'm at 99.36% of IPv6 traffic today ;)
[10:34] <stgraber> highvoltage: I'm checking if I've got enough bandwidth left at hetzner to mirror Edubuntu, depending on the result we may have to update the download/announcement pages
[10:35] <stgraber> 4TB left, so I guess I'll be mirroring then (but not Kubuntu this time around, don't have enough bandwidth for that one)
[10:36] <highvoltage> stgraber: ok great.
[10:58] <stgraber> highvoltage: are we ready to press the button and release?
[10:58] <stgraber> (waiting for the Supported: field to be sorted out but I guess we should be done in < 1 hour)
[11:05] <highvoltage> stgraber: yep, then just need to add the links to the downloads page
[11:05] <highvoltage> stgraber: edubuntu.org is still surprisingly snappy
[11:05] <stgraber> highvoltage: I've already updated the downloads page for 13.04
[11:05] <stgraber> highvoltage: and I did a couple of tweaks in the announcement (fixed URL to release notes, standardize the title, ...)
[11:06] <highvoltage> stgraber: I see
[11:06] <highvoltage> stgraber: ok just looked at it, looking good
[11:06] <highvoltage> ah just need to add some attribution to the image I used...
[11:07] <stgraber> highvoltage: documentation page updated too
[11:07] <stgraber> highvoltage: do you already have an e-mail announcement ready or should I prepare my usual one?
[11:08] <highvoltage> stgraber: I think you could go with your usual one. I know you like doing it ;)
[11:08] <highvoltage> stgraber: everything else looks good
[11:09] <stgraber> highvoltage: ok, I'll finish lunch and prepare the e-mail
[12:12] <highvoltage> http://edubuntu.org/news/13.04-release
[12:12] <meerkat> it is out?! :)
[12:12] <meerkat> I'll start seeding. or downloading rather


[03:46] <cliffybx> heloo
[03:46] <cliffybx> anyone here
[03:53] <gko> yo
[07:11] <BlueT_> @@
[07:15] <HugoKuo_> @@
[07:15] <HugoKuo_> 前輩
[07:16] <acman> $$
[07:16] <HugoKuo_> 請教filesystem testing 的record rewrite 意義是什麼呢
[15:08] <BlueT_> hugokuo: 複寫已有 data 的磁區？ # 15:16 < HugoKuo_> 請教filesystem testing 的record rewrite 意義是什麼呢
[15:08] <BlueT_> hugokuo: 哪個 tool 或是哪裡看到的？ :3
[15:08] <hugokuo> iozone
[15:08] <hugokuo> 頂等噢
[15:09] <hugokuo> Re-write-record
[15:09] <hugokuo> 好奇 為何這個項目出來的數據都很高
[15:19] <hugokuo> btw , does anyone know about how to disable filesystem read caching ……..   這影響我想做filesystem benchmark 的數據, 目前我只能把記憶體塞滿 應對 , if there's any suggestion ….'ll be appreciated :>
[17:49] <BlueT_> HugoKuo__: Re-Write
[17:49] <BlueT_> This test measures the performance of writing a file that already exists. When a file is written that already exists the work required is less as the metadata already exists. It is normal for the rewrite performance to be higher than the performance of writing a new file.
[17:49] <BlueT_> http://blogs.oracle.com/dom/entry/zfs_v_vxfs_iozone
[17:52] <BlueT_> HugoKuo__: http://www.linuxquestions.org/questions/linux-kernel-70/how-to-disable-filesystem-cache-627012/