[00:07] <neversfelde> are we reverting the bzr branches to the status before 4.3.4?
[00:08] <JontheEchidna> yeah
[00:09] <neversfelde> k
[00:16]  * JontheEchidna is happy to have his device notifier in the systray
[00:16] <neversfelde> it is bzr uncommit right?
[00:16] <JontheEchidna> I've just been removing the changelog entries manually myself
[00:17] <Quintasan|Szel> why we would be doing this?
[00:17] <JontheEchidna> 4.3.4 was never released to lucid
[00:17] <neversfelde> Quintasan|Szel: 4.3.4 is in bzr, but will not be release for 10.04
[00:18] <Quintasan> ah okay
[00:18] <JontheEchidna> and the changelog entries can't really be merged with the 4.3.80 changelog
[00:18]  * JontheEchidna is unsure if bzr uncommit works after pushing
[00:19] <JontheEchidna> -./usr/bin/servicemenudeinstallation <- name fail :P
[00:28]  * ryanakca sighs
[00:29] <ryanakca> My dad asked: "Why do I get keeping offered bug fixes... I thought there weren't supposed to be bugs"
[00:36] <nixternal> JontheEchidna: after a push, bzr revert -r<REV#>
[00:36] <nixternal> REV# being the rev you want to revert back to
[00:37] <nixternal> then you ci and push that
[00:38] <Quintasan|Szel> hurrr, so my changes were a waste of time? :D
[00:42] <neversfelde> nixternal: is there a difference to uncommit, whe it is the second last revision you want to revert to?
[00:42] <neversfelde> s/whe/when
[00:48] <nixternal> I didn't know about that, seems it does the same thing as revert, but a bit simpler
[00:48] <neversfelde> I'll test it
[01:26] <ScottK> qt4-x11 4.6.0 being uploaded (it'll take a while)
[01:28] <Daskreech> Quintasan|Szel: are you doing gluon?
[01:30] <Quintasan> Daskreech: not really, I planned to take on it after kdeutils but this is harder than I expected and I need some sleep
[01:31] <Daskreech> ryanakca: No Bugs?? then who will make sweet sweet chirping noises in the background while I work?
[01:32] <Daskreech> Quintasan: Ok learning curves are good as long as you have claws
[01:33] <Quintasan> uhm, what?
[01:33] <Daskreech> So you don't slide off and you can keep climbing the curve
[01:34] <Quintasan> ah :P
[01:34] <Daskreech> When you reach the top there is likker and cookies :)
[01:34] <Daskreech> Followed instantly by more work >_>
[01:34] <Daskreech> But likker and cookies!
[01:34] <ScottK> Quintasan: Did you look at the lirc files now in kdebase-workspace?
[01:35] <Quintasan> ScottK: nope, I will download it but I'll try compiling files from kdeutils first
[01:35] <Quintasan> maybe the cmake rules are borked somewhere
[01:36] <ScottK> Quintasan: I'd look in the ninja PPA and see what lirc files are now provided by workspace before I spent a lot of effort convincing utils to build stuff.
[01:42] <JontheEchidna> Quintasan: 99_fix_ftbfs_on_marble_wallpaper.diff needs documenting in debian/changelog
[01:43] <JontheEchidna> most of the stuff from your bzr commit message would make great additions to debian/chanelog too
[01:44]  * Quintasan facepalms
[01:44] <Quintasan> I forget to modify the changelog all the time :/
[01:44] <Quintasan> JontheEchidna: I should get "new - old" branch and then push my changes or update the one I currently have?
[01:45] <JontheEchidna> I did commit a fix removing the unreleased 4.3.4 changelog entry, so you will want to do a pull before further editing
[01:46] <JontheEchidna> It looks like all you really need to do is add the stuff to the changelog file, commit and push
[01:50] <JontheEchidna> oh, yippie. kipi-plugins and koffice2 need a rebuild for new kdegraphics
[01:51]  * JontheEchidna goes off to watch the last half of the Return of the King
[01:54] <Quintasan> ScottK: Files is workspace are different, anyways I need to get some sleep since it's almost 13 hours since I'm up and running :P
[01:54]  * Quintasan goes to bed
[01:54] <ScottK> Quintasan: OK.  Good night.  Please make sure your work is up to date in bzr so maybe someone else can look at it.
[02:21] <ScottK> Final workspace package on the way to the ninja PPA
[03:00] <ScottK> maco: Having any luck with kdeedu?
[03:07] <maco> ScottK: since i moved my hard drive to the 32bit computer, im having to regenerate my pbuilder as a 32bit one.
[03:07] <maco> plz hold :)
[03:07] <ScottK> OK.
[03:08] <Lex79> ScottK: ehm you uploaded Qt from ppa instead bzr...I merged in bzr and in ppa it's only a new upstream release. Second thing, you signed my package, and it's not good.
[03:09] <ScottK> Lex79: OK.  I signed it without making any changelog entries because i had to clean up the Debian dir.
[03:09] <ScottK> Lex79: I'll look at bzr and do another upload.
[03:09] <ScottK> Sorry about that
[03:10] <Lex79> no problem ScottK :)
[03:15] <ScottK> maco: You know you'll need to use https://launchpad.net/~kubuntu-ppa/+archive/staging for KDE 4.4 beta 1 sources to build against, right?
[03:16] <maco> ScottK: eep! so i have to login to pbuilder and edit the sources.list? ok then...
[03:17] <ScottK> Lex79: When you merged from Debian Experimental, why did you keep it -0ubuntu1 instead of -1ubuntu1?
[03:20] <Lex79> I'm wrong :)
[03:20] <ScottK> OK.  I'll fix it then.
[03:21] <Lex79> go to bed, good night
[03:26] <ScottK> Good night.
[03:27] <ScottK> JontheEchidna: Are you going to be able to be doing any uploading tonight?
[03:48] <JontheEchidna> ScottK: yes
[03:48] <ScottK> JontheEchidna: Cool.  Looks like plasma-addons is working out.
[03:48] <JontheEchidna> ScottK: so does it matter what order as long as kde4libs goes last?
[03:49] <ScottK> JontheEchidna: No.
[03:49] <ScottK> JontheEchidna: Let's just keep each other informed here of what we're working on.
[03:49] <JontheEchidna> ok
[03:49]  * ScottK is still on qt4-x11 and final touches on workspace
[03:52] <JontheEchidna> I think I'll take a look at eigen2
[03:55] <ScottK> OK.
[03:55] <ScottK> JontheEchidna: Can you upload that one?
[03:56] <JontheEchidna> ScottK: according to edit_acl I can
[03:56] <ScottK> Cool
[03:57] <JontheEchidna> I was a bit surprised, seeing as I couldn't upload akonadi or soprano
[03:58]  * ScottK looks at kdeplasma-addons
[04:02] <ScottK> My poor hard drive.
[04:19]  * ScottK will be with addons for a while
[04:28] <JontheEchidna> blah
[04:28] <JontheEchidna> kdm fails trying to show that ksplash crap
[04:31] <ScottK> Probably because you left the x off the end
[04:32] <ScottK> BTW, I'll be on plasma-addons for a while.
[04:34] <JontheEchidna> :(
[04:36] <JontheEchidna> how do I make Xorg die without having it respawn itself?
[04:39] <JontheEchidna> oh, kill kdm_greet
[04:40] <JontheEchidna> mrgh, still no X session
[04:41] <ScottK> shift to a VT and kill it from there?
[04:41] <JontheEchidna> I got Xorg to die, but startx gives me a black screen
[04:43] <JontheEchidna> grr, it's logging in, but it's black
[04:43] <JontheEchidna> It looks like I'm hitting an unrelated X bug :/
[04:44] <ScottK> People like dark themes.  Maybe it's a feature.
[04:44] <JontheEchidna> brb
[04:52] <JontheEchidna> I think kdebase-workspace-libs4+5 still depends on the two libnepomuk packages that were removed
[04:52] <JontheEchidna> well, moved to kde4libs, but
[04:56] <JontheEchidna> oh... there's a ppa3 in -ninjas. wonder when that'll be downloadable
[05:00] <ScottK> JontheEchidna: I didn't fix that.
[05:00] <ScottK> I was just about to upload it to the archive, so good catch.
[05:02] <JontheEchidna> would it be better for the packaging itself to move to kde4libs or should it be absorbed into kdelibs5?
[05:03] <ScottK> JontheEchidna: You mean for libnepomukqueryclient4?
[05:03] <ScottK> I think it would be best to keep the binary packages for now.
[05:04] <ScottK> That way we don't have to figure out what depends on them and transition them tonight.
[05:06] <ScottK> plasma-addons is going to ninjas again
[05:07]  * JontheEchidna hopes his issue isn't widespread
[05:08] <ScottK> You mean the instanity that causes you to run your main machine on the development release before Alpha 1?
[05:09] <JontheEchidna> heh
[05:10] <JontheEchidna> I suppose I can still sponsor packages from the tty
[05:11] <ScottK> Workspace is on the way to the archive
[05:13] <JontheEchidna> eigen2 is back to building
[05:16] <rgreening> hey all
[05:16] <JontheEchidna> lo
[05:19] <Darkwing-Netbook> hey nixternal, you around brother?
[05:21] <JontheEchidna> up goes eigen2
[05:22] <JontheEchidna> looking at kdeadmin
[05:23] <ScottK> rgreening: Work on that kubuntu-dev app
[05:25] <ScottK> Lex79: Reuploaded Qt4
[05:33]  * ScottK is looking at sip4-qt3
[05:36] <rgreening> ScottK: yeah, I plan too this week... been real bogged down at work with my new position
[05:52] <ScottK> debfx: KDE SC 4.4 beta 1 kdebase-workspace package is published now, so I'd appreciate it if you coul take a look at your brightness patch and update it for 4.4.
[06:00] <ScottK> sip4-qt3 and python-at4 done
[06:01] <ScottK> at4/qt4
[06:04] <ScottK> Looking at kdetoys
[06:11] <ScottK> kdetoys uploaded
[06:16] <JontheEchidna> uploading kdeadmin
[06:17]  * ScottK isn't going to last a lot longer
[06:21]  * JontheEchidna isn't either
[06:22] <JontheEchidna> in fact, I'm going to call it a night
[06:32] <ScottK> kdeplasma-addons uploaded.
[06:33] <ScottK> apachelogger, nixternal, or Riddell: JontheEchidna and I started uploading.  See https://wiki.kubuntu.org/Kubuntu/Ninjas/Packaging - we are saving kde4libs for last, to minimize retries, but please jump in and grab some.
[06:33]  * ScottK is off to bed too.
[07:14] <lmm> hi, I mentioned this before but it's still happening with pykde 4.3.4 : pykdeuic4 is failing whenever I try to run it with AttributeError: 'kde_i18n_string' object has no attribute 'escape'; http://pastebin.ca/1702129 is a full backtrace
[08:02] <tsimpson> lmm: what's the output of "python -c 'from PyQt4.uic.Compiler import qtproxies; print qtproxies'"? pykdeuic4 still works fine here
[08:02] <lmm> md401@arcueid ~ $ python -c 'from PyQt4.uic.Compiler import qtproxies; print qtproxies'
[08:02] <lmm> <module 'PyQt4.uic.Compiler.qtproxies' from '/usr/lib64/python2.6/site-packages/PyQt4/uic/Compiler/qtproxies.pyc'
[08:03] <tsimpson> that's different from mine
[08:03] <tsimpson> $ python -c 'from PyQt4.uic.Compiler import qtproxies; print qtproxies'
[08:03] <tsimpson> <module 'PyQt4.uic.Compiler.qtproxies' from '/usr/lib/pymodules/python2.6/PyQt4/uic/Compiler/qtproxies.pyc'>
[08:03] <tsimpson> and not just the lib64 part
[08:04] <lmm> sorry, I mentioned this yesterday, I'm not running kubuntu, it's just this is listed as a place with pykde people
[08:05] <lmm> to my eyes it looks like the problem is that escape is now a function in the module rather than a method on the i18n_string object
[08:05] <lmm> *class, whatever
[08:06] <tsimpson> then you'll probably need to patch pykdeuic4
[08:08] <lmm> yeah, if I change the self.escape in kde_i18n_string.__str__ to qtproxies.escape then it works
[08:09] <tsimpson> what version of PyQt4 do you have?
[08:09] <lmm> 4.6.2
[08:11] <tsimpson> hmm, the changelog for pyqt4 doesn't mention the change
[08:14] <tsimpson> well, it looks like KDE isn't using that version
[08:14] <tsimpson> lmm: you should probably file a bug with KDE about that
[08:14] <lmm> ok, will do
[09:34] <jussi01> yay, no plasma...
[09:36] <jussi01> http://paste.ubuntu.com/335775/
[09:43] <Peace-> guys kde 4.4 will be on ppa repo ?
[09:43] <Peace-> guys  will kde4.4 be on ppa repo ?
[10:21] <fale> Lex79: sandsmask released the patch?
[10:21] <fale> Peace-: yes it will
[10:23] <Peace-> fale: ty and when ? if you know??
[10:24] <fale> Peace-: as soon as sandsmask release a patch that is necessary to compile kde4.4 smootly
[11:11] <Quintasan> ScottK: I see I pretty screwed kdeplasma-addons, what's with the rename on liblancelot?
[11:13] <jussi01> Quintasan: does your plasma work atm?
[11:17] <Quintasan> jussi01: yeah, I'm still at 4.3.4
[11:33] <Quintasan> ScottK: dunno what ${sameVersionDep:kdelibs5-dev:liblancelot1} is expected to cause but for now it makes kdeplasma-addons to fail
[11:47] <Lex79> fale: no for now, we are packaging and uploading for lucid 4.4 without pulse audio support
[12:00] <fale> Lex79: I see
[12:10] <Peace-> Lex79: just to know are you italian ?
[12:10] <Lex79> yeah Peace-
[12:10] <Lex79> :)
[12:11] <Peace-> xD you are then xD
[12:11] <Lex79> :D
[12:11] <Peace-> here is nowardev from italian communty
[12:11] <Peace-> tooo
[12:13] <Lex79> nice to meet you :)
[12:13] <Peace-> i have written to you just because i have read some topic on on ubuntu-it forum about rai-qt
[12:14] <Lex79> oh, I didn't read :(
[12:14] <Lex79> Quintasan: can you fix kdeplasma-addons in ppa ? problems?
[12:19] <Quintasan> Lex79: dunno what  ${sameVersionDep:kdelibs5-dev:liblancelot1} does but it cause a fail while dh_libs<something>
[12:19] <Quintasan> and ppa rejects my source, wtf
[12:20] <Lex79> you should download orig.tar.gz from ppa
[13:08] <Quintasan> Lex79: kdeplasma-addons fixed in ppa
[13:08] <Quintasan> Lex79: pushing to bzr now
[13:10] <Lex79> awesome
[13:14] <Lex79> damn, my kdepim building is stuck here: http://pastebin.ca/1704185
[13:14] <Lex79> uff :(
[13:17] <Quintasan> hmm, noone is doing edu?
[13:18] <Quintasan> oh nvm
[13:18] <Quintasan> back to utils :/
[13:19] <Quintasan> hurr durr, kdelirc cmake file is broken probably, it yields no files :/
[13:30] <Quintasan> FFS!
[13:31] <Lex79> ?
[13:31] <Quintasan> Lex79: http://pastebin.ca/1704196 -> enjoy your failCMake :/
[13:45] <ScottK> Quintasan: The liblancelot0 -> 1 rename is because the major so version changed.
[13:46] <JontheEchidna> I can't edit the wiki from lynx :(
[13:46] <ScottK> Quintasan: I fixed (I think) the sameversiondeps issue before I uploaded it to the archive.
[13:46] <JontheEchidna> Could somebody set eigen2 and kdeadmin to uploaded?
[13:47] <ScottK> Quintasan: When you were fixing plasma-addons, did you look at what was in bzr/the archive?
[13:47] <ScottK> JontheEchidna: Doing
[13:47] <Quintasan> ScottK: I pulled your changes, applied mine and pushed back
[13:48] <ScottK> Quintasan: Good.
[13:48] <ScottK> JontheEchidna: Not doing, someone else has an edit lock on the page
[13:48] <Quintasan> Too bad LP gives Internal Server Error :/
[13:48] <JontheEchidna> Taking a look at kdeaccessibility
[13:48] <Lex79> ScottK: doing
[13:48] <ScottK> ok
[13:49] <Lex79> JontheEchidna: are you in console? :(
[13:49] <JontheEchidna> Lex79: yeah... kdm_greet churns at 100% cpu trying to show that ksplash junk and never gets to kdm
[13:50] <JontheEchidna> and I can't use startx due to an X bug which I've had for a while (since karmic)
[13:50] <Lex79> oh man :(
[13:51] <JontheEchidna> I wonder if installing gdm would work...
[13:51] <Quintasan> ScottK:  ${sameVersionDep:kdelibs5-dev:liblancelot1}   <--- what this line is supposed to do?
[13:52] <ScottK> Quintasan: Look in pkg-kde-tools.  There's a script there that makes sure the packge depends on the same version of kde5libs as liblancelot1.
[13:53] <ScottK> It was there before, but with liblancelot0
[13:53] <Quintasan> ScottK: but now it causes the whole build to fail, I removed it and it works here
[13:54] <Lex79> ScottK: some docs for kdepim doesn't want build and stuck the building, I'll disable with a patch, http://pastebin.ca/1704193
[13:54] <Quintasan> ScottK: keeps telling me liblancelot1 has no Depends field to scan, ppa was reporting the same error
[13:55] <Lex79> I asked in #kde-devel but seems they haven't an answer for that issue
[13:57] <Quintasan> Lex79: ha, something similar here, stuck at [ 97%] Generating index.cache.bz2
[13:57] <Quintasan> :D
[13:57] <ScottK> I think it's OK to disable stuff for now, just make sure it's well documented so we don't forget to come back to it later.
[13:58] <Lex79> ok ScottK, Quintasan for which package?
[13:58] <ScottK> Quintasan: We can sort that out later too then (but we shouldn't forget)
[13:58] <ScottK> Lex79: pim
[13:58] <Quintasan> Lex79: kdeutils :/
[13:58] <Quintasan> let me try rerunning it
[13:58]  * ScottK needs to run off for a while.  Good luck.
[13:59] <Lex79> Quintasan: disable in CMakeList.txt
[14:04] <ScottK> Quintasan: You do need to make a new debian changelog entry instead of changing mine, since I already uploaded -0ubuntu1.
[14:04] <ScottK> It should be 0ubuntu2
[14:05] <Quintasan> oh my, should I revert and change it?
[14:06] <Lex79> no, add new entry with 0ubuntu2
[14:06] <Lex79> and remove your changes from 0ubuntu1 changelog and add it to 0ubuntu2 changelog
[14:08] <ScottK> Quintasan: Also your plasma-addons uploads are a native package.  Pull the tarball from the archive and use that.
[14:08]  * ScottK really gone now
[14:13] <Quintasan> Lex79: just to be sure -> http://pastebin.com/f76371f46 everythings fine now?
[14:14] <Lex79> uhmm second
[14:15] <Lex79> Quintasan: it's ok
[14:16] <Quintasan> Lex79: thanks, pushing to bzr, it's necessary to repeat the change and put in into ppa?
[14:17] <Quintasan> hurr durr the whole doc making proccess fails. I'm going to comment out all the docbook generation entries
[14:20] <Quintasan> WTF?
[14:21] <tsimpson> someone must have tripped over the power cable :p
[14:34] <Quintasan> tsimpson: lol
[14:39] <JontheEchidna> kdeaccessibility uploading
[14:59] <JontheEchidna> looking at kdemultimedia
[15:01] <Quintasan> Lex79: I have disable building all docs in kdeutils since they seem stuck like in your case
[15:02] <JontheEchidna> Quintasan: kdemultimedia needs it's kde build-deps bumped and the libknotificationitem-dev build-dep removed
[15:02] <JontheEchidna> (libknotificationitem-dev's files moved to kdelibs5-dev)
[15:09] <Quintasan> JontheEchidna: okay, getting to it right away
[15:10] <Quintasan> JontheEchidna: should I make 0ubuntu2 or edit 0ubuntu1?
[15:11] <Quintasan> JontheEchidna: also, should I remove 4:4.3.4-0ubuntu1 entry?
[15:21] <JontheEchidna> Quintasan: just edit ubuntu1 and remove the 4.3.4 entry
[15:21] <Quintasan> okay
[15:22] <Quintasan> change unreleased to lucid?
[15:22] <Quintasan> JontheEchidna: ^
[15:22] <Nightrose> hey Quintasan :)   any news?
[15:23] <JontheEchidna> Quintasan Sponsors usually do that when they upload
[15:23]  * JontheEchidna misses xorg
[15:24] <Quintasan> JontheEchidna: pushed
[15:25] <JontheEchidna> k, I've been pbuilding it in the meanwhile
[15:25] <Quintasan> Nightrose: I was fighting with it before 4.4 b1 but it's an biggest PITA I have ever seen, if I get it running it will be a miracle
[15:25] <Quintasan> apachelogger must've been drunk while writing it
[15:26] <Nightrose> heh damn
[15:26] <Nightrose> users are asking for it :(
[15:26] <Quintasan> it builds nothing then tries to execute wget from archive to check if the files are there :/
[15:28] <Quintasan> Nightrose: I will get to it after 4.4 beta which is soon :)
[15:28] <Nightrose> cool
[15:28] <Nightrose> thx
[15:33] <Lex79> ALL docs in kdeutils doesn't want build? :(
[15:34] <Quintasan> Lex79: I've tried first five and each hung the whole process :/
[15:34] <Lex79> ok
[15:38] <Lex79> well, now kdepim is stuck at [ 98%] Built target korg_hebrew
[15:38] <Lex79> \o/
[15:38] <Quintasan> hurr durr, Lex79, okteta has several depends on libkasten things, should I make em a separate package or just paste to okteta.install?
[15:41] <Lex79> Quintasan: dunno, can you paste to pastebin?
[15:41] <JontheEchidna> kdemultimedia uploaded
[15:41] <Lex79> JontheEchidna: are you uploading without xorg? lol
[15:41] <Quintasan> Lex79: http://pastebin.ca/1704316
[15:42] <JontheEchidna> Lex79: doesn't stop me ;-)
[15:42] <Quintasan> who cares bout X :P
[15:42] <Lex79> lol
[15:42] <JontheEchidna> looking at kdenetwork now
[15:42] <Quintasan> urgh let's finish this and I'll send my application to MOTU and to ML to get some sponsors :P
[15:44] <Quintasan> JontheEchidna: lol failed on powerpc right away :D
[15:44] <Quintasan> hell yeah, kdeutils build!
[15:44] <JontheEchidna> ya, port archs are all fail right now
[15:45]  * Quintasan does the ninja dance
[15:45] <JontheEchidna> ia64, powerpc and armel all are busted atm
[15:45] <Lex79> Quintasan: put into okteta.install, kasten controllers is part of okteta
[15:45] <Quintasan> ~cookies for Quintasan
[15:45] <Quintasan> no cookies for me :<
[15:45] <Lex79> ahahha
[15:46] <Quintasan> kubotu: order cookies for Quintasan
[15:46]  * kubotu slides a whole bunch of world's finest cookies down the bar to Quintasan.
[15:46] <JontheEchidna> technically it would be proper to make a libkasten4 package for the libkasten libraries in /usr/lib/
[15:46] <Quintasan> so I should make it or not? hurr!
[15:46] <JontheEchidna> the liboktetakasten libraries would go to oktete
[15:47] <apachelogger> Quintasan: neon does dput, not build :P
[15:48] <JontheEchidna> There should be a libkastencore4, libkastengui4 and libkastencontroller4 package
[15:48] <Quintasan> apachelogger: dunno wtf it does, just keeps wgeting what is not there obviously
[15:48] <Quintasan> zomfg
[15:48] <Quintasan> JontheEchidna: okay, getting to it
[15:48] <apachelogger> so your dput is all messed up
[15:49] <apachelogger> the wegetting is in place to prevent breaks of the stack if a lowlevel stack package FTBFS
[15:49] <Quintasan> apachelogger: not mine fault you wrote this whole thing based on YOUR configuration :P
[15:49] <JontheEchidna> Quintasan: hmm... were there any kasten files in /usr/include?
[15:49] <apachelogger> no no
[15:50] <apachelogger> the onlything that is specific to me is the svn url
[15:50] <apachelogger> everything else is specific to neon
[15:50] <apachelogger> and granted, I never intent to use it outside the neon ppa :P
[15:50] <Quintasan> JontheEchidna: doesn't seem so, let me build it after separating the libkasten
[15:50] <Quintasan> JontheEchidna: and only okteta or whole kdeutils package should depend on it?
[15:51] <JontheEchidna> only okteta, though shlibdeps should pick up on that automatically
[15:51] <Quintasan> apachelogger: it wasn't working with modified qt link on your machine or you were too lazy to check? :P
[15:51] <apachelogger> modified qt link?
[15:52] <JontheEchidna> though I am having second thoughts... If it's just a private library with no public includes there's not much sense for extra packages
[15:52] <Quintasan> apachelogger: Qt now sits in GIT, doesn't it?
[15:52] <apachelogger> so?
[15:52] <JontheEchidna> But private libraries usually go to /usr/lib/kde4, if I'm not mistaken... hrm
[15:53] <JontheEchidna> apachelogger, any opinion on this libkasten* stuff?^
[15:53] <Quintasan> apachelogger: I was wondering what's really wrong with it, it is your script that is an ultimate PITA or it's just failing to build because it does't like us
[15:53] <apachelogger> JontheEchidna: got a quick summary?
[15:53] <JontheEchidna> ok, here it goes:
[15:53] <JontheEchidna> okteta builds several versioned libkasten* libraries
[15:53] <JontheEchidna> no public includes, they go to /usr/lib/
[15:54] <Quintasan> apachelogger: http://pastebin.ca/1704316 ->> I have pasted it to okteta.install to make sure it's linked
[15:54] <JontheEchidna> separate package, or include w/ okteta?
[15:54] <JontheEchidna> or should upstream really be installing it to /usr/lib/kde4?
[15:54] <apachelogger> JontheEchidna: the question is really what that kasten is meant for
[15:55] <Quintasan> shhh, we can't be smarter than upsteam ;P
[15:55] <apachelogger> uhh, that sounds funny, you see kasten in german means closet :D
[15:55] <Quintasan> LOL
[15:55] <JontheEchidna> lol
[15:55] <Quintasan> Closet implementation in C++
[15:55] <Quintasan> void::FlushWater
[15:55] <Quintasan> :P
[15:55] <Quintasan> lol fail
[15:55] <JontheEchidna> Water closet, old british term for toilet
[15:55] <Quintasan> Kasten::FlushWater
[15:56] <apachelogger> if kasten is meant to be like libokular, then it needs to go to a seperate package
[15:56] <apachelogger> and looking at the libnames I would suppose it is
[15:56] <JontheEchidna> not more fail than /usr/bin/servicemenudeinstaller :P
[15:56]  * Quintasan wonders how he is supposed to know that
[15:56] <Quintasan> menude? nice
[15:56] <Quintasan> :D
[15:57] <JontheEchidna> "service me nude installer"
[15:57] <apachelogger> JontheEchidna, Quintasan: I would consult with upstream and debian about the best course of action
[15:57] <apachelogger> though without knowing what it does, just from looking at the names it probably should get an own lib and dev package *shrug*
[15:57] <JontheEchidna> there's nothing to throw in a -dev package, though
[15:58] <JontheEchidna> besides the unversioned .so
[15:58] <apachelogger> lib package is necessary too!!
[15:58] <apachelogger> having a .so for a lib that is meant to be used without the app in a -dev package without a related lib package doesnt make much sense IMHO :P
[15:59] <apachelogger> that was for example the reason we didnt have kopete headers packaged for a long time IIRC
[15:59] <JontheEchidna> Quintasan: libknotificationitem-dev build-dep needs to go in kdenetwork, as well as the ~ppa in the changelog version
[16:00]  * JontheEchidna realises that that is an awkwardly worded sentence
[16:01] <Quintasan> damn I would just throw it in okteta.install, only okteta complained about it during the whole build proccess
[16:02] <apachelogger> Quintasan: that is not future proof :P
[16:02] <apachelogger> if we do that and indeed the lib is supposed to be public, then we have to shuffle around and introduce replaces/conflicts
[16:02] <apachelogger> possibly where debian has none
[16:02] <apachelogger> leading to unnecessary diff
[16:02] <JontheEchidna> the best thing to do is to discuss with debian
[16:03]  * JontheEchidna won't because he has graduated from minion status :P
[16:03] <Quintasan> hurr and ofc the must be on another network
[16:03] <Quintasan> they
[16:04] <Quintasan> too much stallman there, I should repeat those words until I die
[16:06] <apachelogger> Quintasan: what does your fetcher.rb look like?
[16:07] <Quintasan> apachelogger: http://pastebin.com/f1827c62d
[16:07] <apachelogger> nice tab mess :P
[16:08] <Quintasan> don't really care since I want it just to work for now :P
[16:08] <apachelogger> lame excuse
[16:08] <Quintasan> don't care about that too :)
[16:09] <JontheEchidna> apachelogger: Whenever an icecc-enabled pbuilder tries to exit, it fails to unmount the chroot because the device is busy. Any hints?
[16:09] <apachelogger> JontheEchidna: there is a special hook that kills the icecc
[16:09] <apachelogger> though, it really depends on how the pbuilder exits
[16:10] <JontheEchidna> is it included in pbuilder-hooks?
[16:10] <apachelogger> I think after build failure I cant hook into and ensure the icecc gets killed
[16:10] <apachelogger> JontheEchidna: should be
[16:10] <apachelogger> though there is at least one exit case where we cant hook in and icecc needs to be killed manually
[16:10] <Quintasan> JontheEchidna: on top of that all I forgot to fix kdenetwork :P
[16:10] <apachelogger> meant to go complain about that ...
[16:11] <JontheEchidna> forgot to fix it?
[16:11] <JontheEchidna> meaning I should just stop my build now?
[16:11] <Quintasan> I mean the control and changelog :P
[16:11] <JontheEchidna> oh
[16:11] <Quintasan> libknotificationitem-dev should go to hell?
[16:11] <JontheEchidna> yus
[16:12] <apachelogger> oh dear
[16:12] <apachelogger> 300 KiB down
[16:12] <apachelogger> -.-
[16:12] <apachelogger> what a drag
[16:12] <JontheEchidna> ideally after we get core KDE libknotificationitem-dev free all we'll have to do is remove the build-dep from plasma-widget-networkmanagement
[16:12] <JontheEchidna> then we can file a removal request for kdelibs-experimental
[16:12] <Quintasan> pinotree | Quintasan: given the author removed the installation of headers, there's no need to split the single okteta package
[16:13] <Quintasan> JontheEchidna: http://pastebin.com/f56a8fb6f <-- looks good enough?
[16:13]  * JontheEchidna agrees with pinotree, much as I hate to agree with him :P
[16:13] <apachelogger> Quintasan: ask upstream if they are coming back?
[16:13] <apachelogger> it is not like libs outside kdelibs are not allowed to change post-beta :S
[16:13] <Quintasan> coming back with what?
[16:14] <apachelogger> beta2, rc, final
[16:15] <JontheEchidna> Quintasan: looks fine to me
[16:15] <Quintasan> pushing then
[16:20] <Quintasan> apachelogger: I'll first build with kasten files in okteta.install, check for missing files and then I we will see if I really need to separate it :P
[16:20] <markey> hmm, is this normal?
[16:20]  * apachelogger doesnt get the point
[16:20] <markey> The following packages have been kept back:
[16:20] <markey>   linux-generic linux-headers-generic linux-image-generic
[16:20] <apachelogger> Quintasan: you shoudl ask upstream if there is any chance that he will introduce header files before 4.4.0
[16:21] <JontheEchidna> markey: yeah, apt-get holds back updates that introduce new packages. Do an apt-get dist-upgrade
[16:21] <apachelogger> which he hopefully answeres with no and adding all and everything to okteta.install is a save bet
[16:21] <markey> JontheEchidna: is it safe?
[16:21] <Quintasan> apachelogger: just as you said
[16:21] <Quintasan> http://markmail.org/message/zgh7ck52yhmfvsj5
[16:21] <JontheEchidna> markey: yes, it will keep the old kernel around
[16:21] <markey> ok, cool
[16:22] <markey> thanks
[16:22] <apachelogger> Quintasan: go talk to upstream!
[16:22] <apachelogger> talk, not interpret
[16:22]  * markey nudges apachelogger
[16:22]  * Quintasan pokes apachelogger
[16:22] <markey> how's TimeLord going? :)
[16:22] <markey> can't wait
[16:22] <apachelogger> Quintasan: as I also said, libs outside kdelibs are not bound to the same api restrictions
[16:22] <apachelogger> markey: slowish
[16:22] <markey> slow is bad
[16:23] <markey> too few contributors?
[16:23] <apachelogger> very much so
[16:23] <markey> hum
[16:23] <markey> should we promote it a bit? some blogging foo?
[16:23] <apachelogger> markey: I'll come back on that, first we need to outline some recruiting guidelines
[16:23] <markey> ok
[16:25] <apachelogger> Nightrose, Quintasan: new lp team "neon", is new driver of "project-neon" project, maintainer is Quintasan, bzr branch ownership transferred to "neon", commited some stuff to hopefully help karmicifcation along
[16:26] <Nightrose> apachelogger: *hug*
[16:26] <Nightrose> you're the best
[16:26] <apachelogger> neon got ppa, id ppa, name project neon
[16:26] <Nightrose> Quintasan: your turn to rock the show ;-)
[16:26] <Quintasan> well okay
[16:26] <apachelogger> once ported I'll try to transfer all subscriptions from old project-neon user to the new neon ppa
[16:26] <Quintasan> apachelogger: I got that link from pinotree, I will mail the developer who commited this now
[16:26] <apachelogger> Quintasan: you go talk to okteta dev :P
[16:27]  * apachelogger tries uploading qt already
[16:28] <apachelogger> +I think all that stuff should be de-amarokified
[16:29] <apachelogger> either establish project neon as own brand or transfer to kde governing or kubuntu governing
[16:32] <ryanakca> How far away are the KDE SC 4
[16:32] <ryanakca> oops, 4.4 beta1 packages? (I'm wondering if it's still worth putting up a notice on the website saying that they are on their way)
[16:32] <apachelogger> ryanakca: https://code.edge.launchpad.net/~apachelogger/kubuntu-website/kubuntu-theme-v2-imgdim+compression
[16:33] <apachelogger> ryanakca: btw, I think we should look into making kubuntu.org fasterish
[16:33] <apachelogger> for example compress that counter pic a bit
[16:33] <apachelogger> quite bigish
[16:33] <apachelogger> also, does the css need to be so distributed?
[16:33]  * apachelogger notes that transfering one large file is mostly faster than transfering 10 smaller ones
[16:34] <Quintasan> apachelogger: mail sent, awaiting response
[16:35] <ryanakca> apachelogger: I'll merge it in to my branch
[16:39] <ryanakca> apachelogger: Anyways, do we have a time frame for 4.4~beta1, or will this suffice: http://paste.ubuntu.com/335999/
[16:41] <apachelogger> ryanakca: should suffice
[16:41] <apachelogger> giving time frames never works out in my experience
[16:45] <Quintasan> WTF IS WITH LP HURRRRR!!!
[16:46] <JontheEchidna> hmm... I've not heard my computer's fans in quite a long time
[16:47] <Quintasan> Launchpad's bzr interface is borked :/
[16:49] <Quintasan> apachelogger: cmd += " co<EMAIL_ADDRESS>#{SVNPATH}/#{dir}"  <-- wtf I should do with this? I get svn: Network connection closed unexpectedly
[16:49] <JontheEchidna> svn://anonsvn.kde.org?
[16:50] <Quintasan> hmm
[16:50]  * Quintasan facepalms
[16:53] <Quintasan> apachelogger: no headers for 4.4
[16:53] <apachelogger> then go ahead with your plan
[16:53] <Quintasan> maybe it will change for 4.5 but that's not sure since dev got not feedback
[16:54] <apachelogger> can be reevaluated then :)
[16:54] <Quintasan> apachelogger: you're hacking the code faster than me, not fair :P
[16:54]  * Quintasan 's commits were overwritten by apachelogger's
[16:55] <apachelogger> dont try to hack ruby faster than me :P
[16:55] <apachelogger> anyhow
[16:55] <apachelogger> I am done
[16:56] <apachelogger> Quintasan: qt src builds
[16:56] <apachelogger> also
[16:56] <apachelogger> you can do amarok while qt builds
[16:56] <apachelogger> amarok does not depend on most recent qt anymore
[16:58] <apachelogger> oh my
[16:58] <apachelogger> Quintasan: uploading qt
[16:58] <apachelogger> that could take some time
[16:58] <Quintasan> uploading to where?
[16:58] <apachelogger> DPUT_OPTS = "ppa:neon/ppa"
[16:59] <Quintasan> this is awesome, apachelogger is doing all the work and I can claim credit for this  :PPP
[16:59] <apachelogger> qt is as far as I will go :P
[17:00] <apachelogger> I suppose from this point on only package changes need to be done
[17:02] <DAskreech> Quintasan: I like your dent updates :) Might help to mention that youare working on 4.3.80 packages
[17:05] <Quintasan> 4.8.30 :D
[17:06] <Nightrose> ryanakca: aroun?
[17:06] <Nightrose> +d
[17:07] <DAskreech> Quintasan: OMGKDEROXBBQFTWCOPTER!
[17:07] <Nightrose> DAskreech: you forgot the ROFL
[17:07] <Nightrose> !!!
[17:08] <Quintasan> roflcopter
[17:08] <DAskreech> I'ts a bug it'll get patched in the 4.8.33 release
[17:17] <EagleScreen> hello
[17:18] <EagleScreen> i am here from a Kubuntu 9.10 Live CD, I am seeing that KDE check spell is not working in official packages, neither in 4.3.4 packages from updates PPA
[17:19] <DAskreech> hi EagleScreen
[17:19] <EagleScreen> hi
[17:19] <DAskreech> Where are you seeing that?
[17:19] <EagleScreen> for instance, in lokalize
[17:20] <DAskreech> This is in English?
[17:20] <EagleScreen> but i think it is the same for the rest KDE apps like konqueror
[17:20] <EagleScreen> this is in Spanish
[17:21] <EagleScreen> Check spell works very well in Debian KDE 4.3.2 packages
[17:22] <DAskreech> ok
[17:26] <JontheEchidna> Is aspell-es installed?
[17:26] <EagleScreen> in a text input box, wrong typed words are not underlined, and if I right-click and I click on Spell Checking in context menu, nothing is opened
[17:28] <EagleScreen> ok, aspell-es wasn't installed
[17:29] <EagleScreen> it may be a bug in language-selector which shlud install it for Spanish language
[17:29] <JontheEchidna> yes, that would be my guess too
[17:30] <EagleScreen> okay, i will check this for 4.3.4 in a installed system
[17:30] <EagleScreen> see you in a moment
[17:35] <JontheEchidna> uploading kdenetwork
[17:38] <DAskreech> Who maintains the Ninja/Packaging wikipage?
[17:38] <DAskreech> or has apachelogger rubyfied it?
[17:39] <JontheEchidna> ninjas manually update it as they go
[17:39] <DAskreech> ok
[17:39] <DAskreech> Silently
[17:39] <DAskreech> >_>
[17:39] <DAskreech> <_<
[17:39] <JontheEchidna> yus!
[17:40] <JontheEchidna> on that note, I'm taking a look at kdepimlibs
[17:40]  * DAskreech considers doing a time line legedn
[17:40] <DAskreech> legend
[17:44] <DAskreech> JontheEchidna: bzr,ppa essentially means done? or does it mean uploaded and not verified/tested ?
[17:45] <JontheEchidna> It means "It's done and the final work is in both the PPA and in bzr, but needs a final review"
[17:45] <JontheEchidna> after the final review it's uploaded
[17:46] <JontheEchidna> we used to have a legend at the old batcave before it went down
[17:46] <JontheEchidna> statuses are: FTBFS, dep-wait (waiting on other packages), in progress, ppa, bzr, reviewed and uploaded
[17:50] <Lex79> kdepim is a mess, hope I can finish today
[17:51] <DAskreech> FTBFS ?
[17:51] <JontheEchidna> fails to build from source
[17:52] <JontheEchidna> or: HALP!
[17:52] <DAskreech> So the initial state is in progress ?
[17:53] <JontheEchidna> yeah, or blank if the ninjas is stealthily lazy :P
[17:53] <DAskreech> Or silent
[17:53] <DAskreech> >_>
[17:53] <DAskreech> <_<
[17:54] <JontheEchidna> oh, if somebody with a working X could update the wiki to say that kdenetwork, kdemultimedia and kdeaccessibility are uploaded, that would be great (lynx can't edit the wiki properly)
[17:54]  * ScottK waves
[17:54] <Lex79> JontheEchidna: ok
[17:54] <ScottK> JontheEchidna: What should I look at?
[17:54] <DAskreech> what about w3m ?
[17:54] <DarkwingDuck> Morning guys
[17:55] <DAskreech> Damn it!
[17:55] <DarkwingDuck> Oh, ScottK Netbook started acting up again
[17:55] <DAskreech> The theme song starts playing in my head everytime you do that DarkwingDuck
[17:55] <JontheEchidna> ScottK: once the wiki is up to date you can take anything that's not uploaded
[17:55] <JontheEchidna> I'm doing kdepimlibs at the moment, though
[17:55] <ScottK> JontheEchidna: OK.
[17:55] <DarkwingDuck> DAskreech: :D It's on my cell.
[17:56] <Lex79> JontheEchidna: done
[17:56] <JontheEchidna> thx
[17:56] <DarkwingDuck> ScottK: When I log in it starts to load up then kicks me back to login screen. If I try again to log in then it crashes stating it is already running and it wont ge anywhere from there.
[17:57] <ScottK> DarkwingDuck: Karmic or Lucid?
[17:57] <DarkwingDuck> I can still run programs via Alt+F2
[17:57] <DarkwingDuck> Lucid
[17:57] <ScottK> Weird.
[17:57] <DAskreech> Any error messages?
[17:57] <DarkwingDuck> It's only the plasma workspace
[17:57] <ScottK> I wouldn't sweat it until we get 4.3.80 in.
[17:58] <DarkwingDuck> Other then my netbook is a 2 pound paperweight? :P
[17:58] <DarkwingDuck> DAskreech: It crashes stateing that that it is already running
[17:59] <ScottK> DarkwingDuck: See if it is already running, ps -AF|grep plasma-netbook
[17:59] <DarkwingDuck> I'm going to do another install from the most recent daily-build and see if it is there or, if this was just my system not liking an update somewhere.
[18:00] <DarkwingDuck> kk hang on
[18:03] <DarkwingDuck> DAskreech: The two error messages are: KDE Daemon; kded4 PID: 1320 Signal: 11 and Plasma-netbook PID:1338 Signal:11
[18:04] <ScottK> Quintasan: I figured out the liblancelot-dev sameversiondeps problem.
[18:05] <ScottK> I didn't bzr add liblancelot1.install
[18:05] <Quintasan> -_-
[18:05] <ScottK> No install, empty package and the "Had no depends" error is exactly correct.
[18:05] <JontheEchidna> uploading kdepimlibs
[18:05] <JontheEchidna> going out for a bit, too
[18:06] <DarkwingDuck> ScottK: It's running...
[18:06] <ScottK> DarkwingDuck: Then kill it and try again
[18:06] <Quintasan> ScottK: pull mine changes and overwrite them, I removed the sameversion line from control
[18:06] <ScottK> Quintasan: Will do
[18:06] <DAskreech> kquitapp plasma-netbook
[18:11] <DarkwingDuck> DAskreech: ScottK, http://pastebin.ubuntu.com/336049/
[18:11] <ScottK> JontheEchidna: Leave kdeplasma-addons for me.  I need to look this over and make sure I didn't confuse myself.
[18:13] <ScottK> DarkwingDuck: It needs to be rebuilt.  Just wait for 4.3.80
[18:13] <DarkwingDuck> kk
[18:13] <DarkwingDuck> :D I'll run without a workspace LOL
[18:14] <DAskreech> My daily regime
[18:14] <DarkwingDuck> lol I knew the risk when I decided to run Lucid on my netbook
[18:15] <ryanakca> Nightrose: aye
[18:15] <DAskreech> DarkwingDuck: Why Sudo?
[18:15] <Nightrose> ryanakca: got a minute for a query?
[18:15] <ScottK> lrwxrwxrwx root/root         0 2009-12-06 18:10 ./usr/lib/liblancelot.so.0 -> liblancelot.so.1.7.0
[18:16] <ScottK>  ^^^ SO version 0 or 1?
[18:16] <ScottK> Anyone?
[18:16] <ScottK> apachelogger: ^^^?
[18:17]  * apachelogger belinks
[18:17] <apachelogger> -e
[18:17] <apachelogger> ScottK: I am not sure that is valid at all
[18:17] <ScottK> That's kind of my thought.
[18:17] <ScottK> It's a bit of a WTF
[18:18] <apachelogger> technically it is 0 though
[18:20] <ScottK> set_target_properties(lancelot PROPERTIES VERSION 1.7.0 SOVERSION 0)
[18:20] <ScottK> I need to go to the grocery store.
[18:20] <apachelogger> I suppose it must be a valid thing to do if cmake allows for that to be done :)
[18:21] <ScottK> Anyone know Lancelot devs?
[18:21] <apachelogger> Nightrose: ^
[18:21] <Quintasan> JontheEchidna: please wait with kdeutils, I'm minutes away from pushing updated commit
[18:22] <Nightrose> ScottK: ivancuckic (sp?)
[18:23] <ScottK> Nightrose, apachelogger, somebody, would you please check and make sure that's on purpose?
[18:23]  * Nightrose is currently fixing amarok stuff - sorry
[18:23]  * ScottK really needs to go to the store
[18:23]  * ScottK launches Quintasan
[18:24] <ScottK> Quintasan: You may have had liblancelot correct (in terms of staying with liblancelot0)
[18:25] <ScottK> (once you get done with kdeutils, would you please double check with upstream that they intended to stay with SO version 0
[18:25] <Quintasan> sure I'll ask around
[18:26] <Quintasan> I won't be here for longer than and hour anyways
[18:29] <ScottK> Quintasan: OK.  Just let me know what you find out here and I'll read the scrollback after I return.
[18:43] <Quintasan> JontheEchidna: kdeutils pushed to bzr and ppa
[18:46] <Lex79> we are sure this release is a beta? seems alpha0
[18:47] <Quintasan> rly
[18:47] <apachelogger> why oh why does ubuntu brainstorm not use openid and hook up with lp
[18:48] <apachelogger> oh my
[18:51] <apachelogger> Xand3r: ping
[18:51] <Xand3r> yes sir
[18:52] <apachelogger> Xand3r: groupies team still got no branding I noticed :P
[18:52] <Xand3r> thats right
[18:52] <apachelogger> anyone up for a brainstorm?
[18:52] <apachelogger> Xand3r: should be fix0red at some point :P
[18:53] <Xand3r> apachelogger: it could, but i have no time
[18:53]  * apachelogger hands Xand3r some time :)
[18:54] <Xand3r> if it could workl like that -.-
[18:54]  * apachelogger would be buying time on ebay if it was :D
[18:58] <ryanakca> Does anybody have a box with a pile of source packages (with watch files) I could access, or on which they could test a patch to uscan ?
[19:02] <Lure> are we now to apply for kubuntu-dev if we want to upload any kde package?
[19:02]  * Lure is motu, but would like to work at least on digikam/kipi-plugins and am not sure what options I have now with new model
[19:03] <maco> Lure: ~kubuntu-dev ?
[19:03] <Lure> maco: https://edge.launchpad.net/~kubuntu-dev
[19:03] <Lure> maco: the thing Jonathan just got in ;-)
[19:03] <maco> Lure: ah see i missed the question before the /me part
[19:04] <maco> Lure: so i was suggesting that
[19:04] <maco> Lure: no that i read the actual question, "yes"
[19:04] <maco> s/no/now/
[19:05] <Lure> maco: ok, I am just not sure what options there are in the new model
[19:05]  * Lure would like to understand options, to get the thing that matches my needs/skills ;-)
[19:05] <maco> i think motu becomes generalist
[19:06] <apachelogger> !info digikam lucid
[19:06] <maco> and then on top of that you can apply for kubuntu-dev, ubuntu-desktop, ubuntu-server, etc
[19:06] <maco> theres like 6 of them
[19:06] <apachelogger> hm, should be in the set controlled by kubuntu-dev
[19:06] <ryanakca> With the new model, could you have more than one maintainer, and that new maintainer gets access to that particular package? Or no?
[19:06]  * apachelogger looks
[19:06] <maco> edubuntu and mythbuntu are two of the others
[19:07] <maco> ryanakca: its like larger-scale per-package-uploaders, it seems
[19:09] <Lure> apachelogger: I would suspect everything that depends on kde should be in kubuntu seed somehow
[19:09] <Lure> apachelogger: and digikam is main, so it should be seeded
[19:09] <apachelogger> == All uploaders for package 'digikam' ==
[19:09] <apachelogger> Archive Upload Rights for ubuntu-core-dev: package set 'kubuntu' in karmic
[19:09] <apachelogger> Archive Upload Rights for ubuntu-core-dev: package set 'kubuntu' in lucid
[19:09] <apachelogger> Archive Upload Rights for kubuntu-dev: package set 'kubuntu' in karmic
[19:09] <apachelogger> Archive Upload Rights for kubuntu-dev: package set 'kubuntu' in lucid
[19:10] <apachelogger> BUT
[19:10] <apachelogger> I am not sure we have the competency to grant per-package upload, we'd probably just direct a recommendation towards the TB or whoever now controls per-package upload rights
[19:11] <maco> apachelogger: i was trying to describe the new "more than just motu and coredev" thing as being similar to largescale PPU
[19:13] <apachelogger> *nod*
[19:14] <apachelogger> as usual the documentation is more than confusing
[19:14] <ryanakca> apachelogger: Do you have a directory full of source packages, or do you delete them when you're done?
[19:14] <Lure> apachelogger: did you now set any req for kubuntu-dev applications?
[19:14]  * apachelogger is a deleter
[19:14] <ryanakca> apachelogger: Bummer
[19:15] <apachelogger> Lure: you need to have considerable experience in working with all them fancy kubuntu packages
[19:15] <apachelogger> Lure: in your case I would go for per-package upload rights though
[19:15]  * ryanakca wouldn't mind having upload rights for packages he maintains in Debian
[19:16] <apachelogger> Lure: if I got the process right ... you would be applying for per-package upload rights to the kubuntu-dev team, who will then direct a recommendation for grating those to the developer membership board, which as I understand is currently the TB
[19:18]  * apachelogger notes that it might also be that kubuntu-dev is able to grant per-package since it got the priviledges delgated from the developer membership board
[19:18] <apachelogger> ScottK: can we grant per-package uploads?
[19:19] <Lure> apachelogger: that makes sense - I am too old to learn your ruby magic scripts ;-)
[19:19] <apachelogger> lol
[19:19] <apachelogger> I dont think we use them right now :P
[19:19] <apachelogger> need major overhowl anyway
[19:20] <Lure> apachelogger: ok, then it is still hope for me ;-)
[19:20] <apachelogger> and sensible infrastructure to go with that
[19:20] <apachelogger> Lure: well, if you apply for per-package you'd not have to use them anyway :P
[19:20] <Lure> apachelogger: btw, what should/can we do with digikam in karmic?
[19:21] <apachelogger> Lure: backport?
[19:21] <Lure> apachelogger: how to get backports through?
[19:21] <apachelogger> Lure: we could also try to get a exception from TB so it can go to karmic-upadates
[19:21]  * Lure opened bug but do not know how to go further
[19:21] <apachelogger> though that is considerable more work, so we should try to get it backported first anyway
[19:21] <Lure> also, -updates would be more appropriate
[19:22] <Lure> apachelogger: who does backports (reads karmic-backports bug mail)?
[19:22] <apachelogger> Lure: once bug is filed -> attach some buildlog for karmic, and mention that all works well -> poke ncommander or ScottK to approve it
[19:22] <apachelogger> then get Riddell to invoke the backport
[19:23] <Lure> apachelogger: ok, will retry with rc1 then
[19:23] <apachelogger> that is if the packaging does not require changes from lucid to karmic
[19:23] <Lure> I am test building new merge in my ppa
[19:23] <Lure> apachelogger: no changes needed, correct
[19:23] <apachelogger> otherwise you would go as above but upload yourself once approval is given and wait for archive admin to let it through
[19:24] <apachelogger> Lure: https://help.ubuntu.com/community/UbuntuBackports#Backport Process
[19:25] <Lure> apachelogger: thanks
[19:25] <apachelogger> Lure: once 1.0.0 is out, you should get it to backports and then get movement towards updates going (i.e. file request with the technical board)
[19:25] <apachelogger> having it in backports first will enable more testing etc.
[19:25]  * Lure notices that ubuntu processes become overwhelming for occasional contributer with limited time as me
[19:26] <apachelogger> +999999 on that
[19:26] <Lure> apachelogger: that makes sense
[19:26] <Lure> apachelogger: I am more and more seeing it is better for me to just work on kde directly
[19:27] <Lure> + I prefer coding to packaging still ;-)
[19:27] <Lure> but I would like digikam/kipi to be in better shape in kubuntu
[19:28] <dtchen> Lure: I kinda dropped the ball on that for Jaunty
[19:28] <apachelogger> Lure: you could recruite someone to take over ;)
[19:28] <dtchen> I was supposed to stand up some sort of -review team for drive-by contributors, so people could just shoot an e-mail to such a list and say, please merge this patch, and the team would take over
[19:28] <apachelogger> now that JontheEchidna lost minion status I suppose we could use some more minions :D
[19:29] <Lure> dtchen: that is challenging setup
[19:30] <Lure> apachelogger: lol
[19:30]  * apachelogger is wondering how long a train ride from graz to ljubljana would be
[19:30] <Lure> apachelogger: maybe JontheEchidna has some jounger brothers and sisters? ;-)
[19:31] <apachelogger> Lure: wouldnt that make kubuntu a family business? :D
[19:31] <Lure> apachelogger: I do not care, if it works ;-)
[19:31] <dtchen> isn't KDE about community? Family is community. :-)
[19:32] <apachelogger> limited scope community though :P
[19:32] <maco> dtchen: ill take it
[19:32] <dtchen> maco: take what?
[19:33] <maco> dtchen: the review team
[19:33] <maco> the [ACTION] on it
[19:33]  * Lure got his lucid pbuilder first real job
[19:33] <dtchen> maco: I think that was already discussed at UDS-L?
[19:34] <maco> dtchen: i wasnt in that session, but i mentioned it to james_w and have since talked to bdmurray. i think they might wanna hear from you though that you're passing it on
[19:34]  * Lure needs to write MIR for liblqr and opencv for this cycle
[19:34] <Lure> btw, what is now the new point of main/universe?
[19:34] <dtchen> maco: I'm not looking to pass it on, because I'm still looking to push legit patches into the archive
[19:35] <Lure> and do we (kubuntu) really care if package is in main or universe?
[19:35] <dtchen> maco: I'm looking for people to step up and help
[19:35] <maco> Lure: main = anything shipped on CD
[19:35] <dtchen> maco: and whether people step up and help has nothing to do with "who's taking the action"
[19:35] <maco> dtchen: ok
[19:35] <DAskreech> Lex79: I would suspect that we will get a slew of fixes soon. First release and rush to get code in etc
[19:36] <Lure> maco: not exactly - digikam is not on cd
[19:36] <Lure> maco: maybe on dvd
[19:36] <maco> Lure: yeah im not sure how thats working out...
[19:36] <Lure> maco: it was: main=supported by canonical
[19:37] <maco> Lure: was....but "will be" is the part that im talking about
[19:37] <Lex79> DAskreech: I hope :)
[19:37] <maco> sounded at uds like "things on the cds"
[19:38] <DAskreech> overhowl.. seems like a hangover from Amarok days eh apachelogger?
[19:40] <DAskreech> apachelogger: SHould I check for a doktor for kipi to take over from Lure?
[19:40] <DAskreech> Lure: Can you check if the kipiplugins allow plugins? :)
[19:40] <Lure> DAskreech: how do you know I need a doctor? ;-)
[19:40] <dtchen> everyone needs a Doctor. Some of us need a Rose.
[19:41] <DAskreech> maco: I thought main was Canonical will accept money to support it
[19:41]  * apachelogger needs a jack :|
[19:42] <maco> DAskreech: archive reorg, though...
[19:42] <DAskreech> apt-get install jack
[19:42] <apachelogger> DAskreech: in general we need more doktors
[19:42] <apachelogger> IMHO
[19:42] <maco> DAskreech: harkness?
[19:42] <DAskreech> maco: Ah Missed that. any notes/writeup/docs on it?
[19:42]  * apachelogger drops mail with super offensive subject :P
[19:43] <DAskreech> Lure: Doktor :) It's a timelord
[19:43] <maco> DAskreech: https://wiki.ubuntu.com/ArchiveReorganisation
[19:43] <DAskreech> dtchen: Nightrose IS a rose. How does that work?
[19:44] <maco> wow kdeedu takes a long time to build
[19:44]  * apachelogger notes that Nightrose does not speak that awful london slang :P
[19:44] <Lure> DAskreech: it works only for one ;-)
[19:44] <Nightrose> hehe
[19:47] <dtchen> jack is unlikely to appear in season 11 of dr who, apparently
[19:47] <dtchen> uh, completely mistyped that. meant the 11th doctor, but that somehow became season
[19:48]  * maco hopes for a Torchwood season 4
[19:49] <dtchen> there will be.
[19:49] <maco> dtchen: since at some point we will cease to be roommates, my xmas list i'm giving to mum is a list of Doctor Who DVDs so i'll still have access when we live apart :P
[19:49] <dtchen> RTD is already writing it
[19:49] <maco> dtchen: AWESOME!
[19:49] <dtchen> maco: ...or you could just watch the youtube doctor who channel.
[19:49] <dtchen> since it's, like, officially sanctioned by the BBC
[19:49] <apachelogger> iTube?
[19:49] <maco> wow really?
[19:50] <maco> is it...does it have old Who to?
[19:50] <maco> *too?
[19:52] <fale> any news about pulseaudio in 4.4?
[19:52] <Lex79> fale: no
[19:52] <apachelogger> waiting on patch still
[19:52] <fale> I see, thankyou
[19:52] <Lure> ok, any core-dev/kubuntu-dev that can sponsor upload of digikam 1.0rc1 merge from debian?
[19:53] <apachelogger> eww
[19:53] <apachelogger> cold tea
[19:53] <apachelogger> oh my
[19:53] <Lure> it is ready in bzr, just get orig.tar.gz from debian
[19:53] <Lure> bzr location: lp:~kubuntu-members/digikam/ubuntu
[19:54]  * Lure moves to kipi-plugins now
[19:57] <dtchen> I need someone to confirm that KMix stores and restores mixer settings upon session logout and login, respectively
[19:57] <dtchen> (sound mixer, of course)
[19:58] <dtchen> i.e., I'm ripping out the store and restore portions from alsa-utils's initscript, but I don't intend to break anyone
[19:58]  * apachelogger prepares digikam upload
[19:59] <JontheEchidna> Lure: my brother didn't know the difference between RAM and a harddrive until today, and my sister is 7.
[20:00] <JontheEchidna> My brother does however have a Dell 9 mini w/ Ubuntu
[20:00] <apachelogger> Lure: btw, you might want to take a look at the debcommit tool
[20:00] <Lure> JontheEchidna: you should fix that ;-)
[20:00] <apachelogger> very helpful when working with packaging branches
[20:00] <JontheEchidna> but no chance of minionizing them I'm afraid
[20:00]  * Lure notes that he has daughters of that age too ;-)
[20:00] <Ahab> Ah kmix question. Can you have multiple Kmix applets running tied to different audio outputs?
[20:01] <Lure> JontheEchidna: btw, congrats of kubuntu-dev!
[20:01] <JontheEchidna> thanks :)
[20:01]  * Lure likes stronger and stronger kubuntu team
[20:03] <JontheEchidna> ugh... gotta go again. Will have to continue uploads later
[20:21] <shtylman> would there be a reason why I can't view lines in an svg file with qt's svg rendering stuff?
[20:22] <shtylman> I have an svg which I made in inkscape
[20:22] <shtylman> but qt won't render the lines...
[20:22] <shtylman> is this a known limitation? or problem?
[20:22] <Lure> apachelogger: thanks for digikam
[20:23] <apachelogger> shtylman: #qt is probably better suited for that question
[20:23] <apachelogger> though last I checked Qt did not support all of inkscape's magic
[20:23] <apachelogger> that was like Qt 4.2 though, so quite long time ago :)
[20:23] <shtylman> hmm
[20:23] <apachelogger> Lure: thanks for merging :)
[20:24] <shtylman> I will query in #qt... I was just curious if any bugs flew our way that we knew of related to this
[20:24] <apachelogger> not to my knowledge
[20:25] <Lure> apachelogger: just commited kipi-plugins to bzr, but still waiting for lucid test build to finish in my pbuilder
[20:26] <Lure> interesting: git push does not work on bzr repositories... ;-)
[20:27] <apachelogger> so much for git being superior :P
[20:29] <apachelogger> Lure: I just need to pull the trigger for kipi-plugins
[20:33] <Lure> apachelogger: ok, kipi-plugins is also ready for upload - it builds in my lucid pbuilder just fine
[20:55] <Lure> ScottK: if you can ack two backports, it would be great: bug 481851 and bug 481856 - digikam's is really important due to (too) many crash reports with karmic's version
[22:07] <ScottK> apachelogger: I don't think we can do per-package.  That still needs to be TB/DMB.
[22:07] <apachelogger> ScottK: but we can do the recommendation?
[22:08] <apachelogger> since it is concerning kubuntu packages I dont see why MOTU would do the recommendation
[22:08] <ScottK> apachelogger: I think it's reasonable, but nothing says either way.  Worth a try.
[22:08] <ScottK> Agreed.
[22:08] <apachelogger> k


[00:00] <ronny> i want it to be distributed with the commit its refering to
[00:00] <Spaz> strange question...
[00:00] <Spaz> what is ubottu written in?
[00:00] <Spaz> and is it open source?
[00:00] <Spaz> oh it's a supybot :(
[00:00]  * Spaz cries a bit, and forks back into the background
[00:00] <ronny> monotone can do that just fine
[00:01] <lifeless> ronny: AIUI monotone it will do that because it syncs the entire database bidirectionally unconditionally
[00:02] <ronny> lifeless: its append-only - and metadata are certified key-value pairs on the revision
[00:02] <lifeless> ronny: I'm sorry, but we don't have an existing facility. What is the monotone facility called so I can look it up
[00:02] <ronny> (and it can have more than one key-value pair with the same key)
[00:02] <Odd_Bloke> ronny: What would happen when the same revision was richly-tagged in two different branches at the same time?
[00:02] <ronny> lifeless: certificates
[00:03] <lifeless> Odd_Bloke: monotone's storage system is quite sophisticated, you get two tags with different certs
[00:03] <lifeless> ronny: thanks
[00:03] <ronny> Odd_Bloke: thats the way fast-forward merges with branches work in monotone
[00:03] <ronny> i rev, n branches
[00:03] <lifeless> ronny: http://www.monotone.ca/docs/Certificates.html <- the right place?
[00:03] <ronny> just n certificates with the key branch, and the branch names as value
[00:04] <ronny> lifeless: yeah
[00:04] <lifeless> ronny: right, I've been through some related stuff before
[00:04] <ronny> lifeless: it allos to do quite cool things
[00:05] <lifeless> ronny: I'll read this on the train after work; I wish I could offer you a precanned answer, but we don't have one
[00:05] <ronny> like accept only revs that have passes a set of tests on all buildbots
[00:05] <lifeless> AFAIK neither hg nor git have precanned answers for adding-metadata like this either
[00:05] <ronny> lifeless: basically all mainstream dvc's have toy-level metadata
[00:06] <lifeless> I think its a perspective thing
[00:06] <lifeless> monotone has a very different worldview
[00:06] <lifeless> like darcs has a different worldview
[00:07] <lifeless> and its good to learn and consider ideas; however the challenge for bzr/git/hg in this space is that much of monotone is built up from the certificates primitive, and well, we're not.
[00:13] <ronny> lifeless: well, the core of it is the graph of files/revisions (i dont correctly understand it, but bzr's graph should be pretty close)
[00:14] <ronny> however everything thats not part of the real history of files is not in that graph, but a certificate that add information (commit messages, authors, dates, ...)
[00:20] <fullermd> Which is to say, a rather different worldview   8-}
[00:22] <ronny> but much more sane and practical
[00:22] <fullermd> A matter of perspective.  Some people consider CVS more sane and practical too.
[00:22] <ronny> one can just limit updates by the certificates added to an revision
[00:23] <ronny> (ie test passes, developer approval, anything else)
[00:24] <fullermd> Yes, but by its very nature that means that the metadata is completely divorced from the data.  Two people could have the same revision, but have completely different ideas about how committed it, when it was committed, and what the log message was.
[00:25] <fullermd> So you end up having to have conflict resolution procedures for that, and accepting the local-view issues.
[00:25] <ronny> you just dont have to care about that
[00:25] <fullermd> Neither is necessarily Right, but there are different tradeoffs either way.
[00:26] <fullermd> I'll care about whatever I wanna care about, thankyouverymuch   ;)
[00:26] <ronny> well, its all there, and if you pull it, you keep it
[00:45] <spiv> The weather is getting warm enough that I'm starting to really notice it when I run the test suite on my laptop...
[00:46] <poolie> spiv, it's supposed to get up to 36C today
[00:46] <poolie> also
[00:46] <spiv> Yeah, I saw :/
[00:46] <jelmer> lucky bastards
[00:46] <poolie> apparently batteries getting hot in a laptop while at full charge is a leading cause of early exhaustion
[00:46] <poolie> in the sense of their capacity decreasing
[00:47] <spiv> My battery is already down to ~40% capacity, but it is about 2 years old.
[00:47] <poolie> so if you want to be really frugal it's better to pull them out while on ac
[00:47] <spiv> Hmm, maybe not quite that bad, but pretty low.
[00:47] <poolie> this is pretty annoying if you bump the cord though :)
[00:47] <spiv> Right, which I do do :)
[00:48] <poolie> apparently it is best to store them at about 50% charge
[00:48] <poolie> which is a bit hard to arrang
[00:54] <lifeless> yah
[00:54] <lifeless> there is a site
[00:54] <lifeless> that has differnet battery types and storage levels
[01:04] <AfC> It's probably best, though, to arrange for you laptop not to oops at 100% CPU when you think it's suspended before putting it in a bag and closing the zipper. There's just nothing like the smell of singed components that comes from baking your machine in constrained CPU exhaust.
[01:07] <fullermd> Oh, sure there is.  Like the one time I put 120 volts across a 2N2222...
[01:08] <lifeless> thats a DC diode isn't it ?
[01:08] <lifeless> a little one
[01:08] <fullermd> NPN bipolar transistor.
[01:08] <lifeless> duh, yes
[01:08] <lifeless> I need to do more electronics I think
[01:09] <fullermd> It lasted a good quarter of a second, I figure...
[01:12] <AfC> What's a few extra volts between friends?
[01:12] <lifeless> AfC: electric
[01:12] <fullermd> Well, a few extra volts presumably means a lot of extra amps   :p
[01:14] <fullermd> After all, a transistor is just a fuse with gain...
[01:16] <poolie> spiv, i thought i remembered multiple occurrences of _ on the lhs of an assignment giving an error in python
[01:16] <poolie> but it does seem to work, at least in 2.5
[01:17] <lifeless> poolie: don't see why it would error, it just has to bind multiple times :)
[01:19] <lifeless> poolie: I think for _, _ in thing:
[01:19] <lifeless> poolie: that might error
[01:20] <poolie> it's not a big deal
[01:21] <spiv> poolie: I dimly recall there being some case where than happens, but I can't seem to find it now.
[01:21] <spiv> So I guess it's sufficiently obscure not to matter :)
[01:47] <spiv> poolie: ok, I think I have only one more thing to do on the autopack branch
[01:48] <spiv> poolie: which is deciding what the "NotPackRepository" error on the wire ought to look like
[01:48] <lifeless> spiv: why error?
[01:48] <lifeless> spiv: if there is no return value, and its not a pack repo, just swallow
[01:49] <spiv> lifeless: well, that's a possibility.
[01:49] <spiv> It is an indication that at best something weird is happening.
[01:49] <spiv> Because it shouldn't ever be trying that verb on a non-pack repo.
[01:50] <spiv> Not returning an error has the advantage of being a little bit simpler.
[01:51] <spiv> Ok, I think I'll just not return an error, I'm happy with that.
[01:51] <spiv> lifeless: thanks
[02:11] <poolie> that's ok with me too
[02:12] <spiv> Ok, I've just sent the current patch to the list.
[02:12] <spiv> I think this version is ready for merging as-is, so please take a look and give it a BB: blessing :)
[02:37] <poolie> i will
[02:38] <poolie> spiv, you have a handful of other patches approved for 1.9
[02:38] <poolie> if you're sure of them now would be a good time, while i read this
[02:41] <poolie> lifeless: so would there be any drawbacks to making 1.9 (the btree format) be rich-root only?
[02:42] <poolie> i guess conversions into it would be substantially slower as we'd have to rewrite all inventories
[02:43] <lifeless> poolie: do the sha1's get rewritten correctly?
[02:43] <lifeless> I still don't have a clear answer to this
[02:43] <poolie> when the inventories are changed when fetching into a rich root repo?
[02:43] <lifeless> and yes, while the default isn't rich root, I think there are clear drawbacks to adding a new format that is a trapdoor for users on the default
[02:43] <lifeless> yes
[02:43] <lifeless> and during reconcile
[02:44] <lifeless> I don't know the status of this; I thought it was the one remaining issue; I may be wrong and its done.
[02:44] <poolie> what would reconcile be doing here?
[02:45] <poolie> s/here/relevant to this
[02:45] <lifeless> there are existing repositories with damaged goods
[02:45] <lifeless> where the revision sha1 is the sha1 of a non-rich-root inventory, but the inventory is a rich root one
[02:45] <lifeless> I have a patch I cannot land for 'check' to check the sha1's are valid
[02:46] <lifeless> reconcile can in theory detect this specific issue by converting the repository to a non-rich-root one, serialising, and if the sha then matches, rewrite the revision object to have the current inventories sha
[02:47] <poolie> cannot land the patch why? because there's no reconcile code to fix up what it finds?
[02:47] <lifeless> yeah
[02:47] <lifeless> in fact, IMO accessing inventories should check the sha1 against the revision as a matter of course
[02:47] <lifeless> but thats different (though still dependent)
[03:09] <Peng_> beuno: ping?
[03:15] <poolie> spiv, review sent
[03:16] <spiv> poolie: thanks
[03:21] <spiv> poolie: I don't see the review anywhere?
[03:21] <poolie> :/
[03:22] <poolie> try now?
[03:24] <spiv> poolie: I see it now
[03:25] <spiv> I just tested 'bzr pack' manually, and it's working ok over HPSS.
[03:27] <spiv> And that explicit raise is correct (although it maybe it'd be worth making a self._ensure_ok(response) helper like RemoteTransport uses?).
[03:27] <poolie> ok
[03:27] <poolie> please send it to pqm then
[03:27] <poolie> it does seem kind of buggy to me that so many of the client stubs check the response explicitly
[03:27] <poolie> (i may be out of date here, i know you landed something for this)
[03:27] <spiv> _translate_error handles responses that are flagged as errors, this is checking that a successful response doesn't have garbage (which is perhaps less useful now that error responses are clearly flagged on the wire).
[03:27] <poolie> ah i see
[03:28] <spiv> It's more interesting when the response may be one of a fixed set of values.
[03:29] <spiv> I think maybe that the client should be more liberal and not worry about the content of responses that it doesn't use in any way.
[03:29] <spiv> But atm we're pretty consistent about doing it this way.
[03:31] <spiv> Ok, it's with PQM.
[03:31] <spiv> I'm going to grab a late lunch.
[03:49] <michalski-bj> when trying to push my branch(that I own)(bzr push lp:~<username>/+junk/<project>)
[03:49] <michalski-bj> it says: bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Emichalski/%2Bjunk/vector-core/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
[03:49] <michalski-bj> ...
[03:50] <Peng_> michalski-bj: Run 'bzr lp-login your-username'
[03:51] <michalski-bj> ok thanks, I think I remember doing this on my old pc, you should add these instructions to the error message
[03:59] <lifeless> poolie: back
[03:59] <michalski-bj> thanks again, gotta go, bye
[04:12] <Peng_> Has that error message improved in a recent version?
[04:15] <warren> [warren@newcaprica ldm-trunk]$ bzr diff
[04:15] <warren> bzr: ERROR: [Errno 12] Cannot allocate memory
[04:15] <warren> [warren@newcaprica ldm-trunk]$ bzr diff
[04:15] <warren> [04:15] <warren> Really odd...
[04:15] <warren> bzr-1.7-1.fc9.x86_64
[04:18] <Peng_> "Errno 12", huh? I wonder why that happens instead of a MemoryError?
[04:19] <lifeless> Peng_: probably a C extension
[04:19] <lifeless> Peng_: raising OSError(errno, strerror(errno))
[04:19] <Peng_> Oh, ok
[04:19] <lifeless> warren: ^
[04:19] <warren> meaning?
[04:20] <lifeless> warren: not sure about root cause; does this happen repeatedly for you?
[04:20] <warren> lifeless: yes
[04:20] <warren> lifeless: although not all the time
[04:21] <lifeless> warren: there should be a backtrace in ~/.bzr.log
[04:23] <warren> lifeless: http://fpaste.org/paste/8358
[04:24] <lifeless> hmm, I don't have a browser handy
[04:24] <lifeless> warren: could you file a bug please?
[04:24] <warren> umm, where, how?
[04:24] <lifeless> https://bugs.launchpad.net/bzr/
[04:24] <fullermd> _readdir_pyx
[04:25] <spiv> Yay, autopack-rpc landed.
[04:25] <lifeless> fullermd: interesting; readdir is ENOMEMing? - or -
[04:25] <lifeless> warren: actually
[04:25] <lifeless> warren: I bet that this is a fixed bug in 1.8
[04:25] <lifeless> warren: readdir has some special needs for errno handling
[04:25] <warren> ok
[04:25] <lifeless> we didn't have that correct in the first release of the readdir bindings
[04:27] <fullermd> Seems like it.  That's what errno 12 is on my system (though I'm pretty sure those vary a fair bit from system to system)
[04:27] <lifeless> they're pretty stable for the common ones
[04:40] <poolie_> lifeless: i'd like you to make a 1.9 branch when my current pqm job completes
[04:41] <poolie_> approximately then anyhow
[04:41] <poolie_> if it would be much easier you can do it now
[04:41] <lifeless> poolie_: tell me when its ready, I've made the branch, just need pull over the top
[04:41] <poolie_> kk
[04:41] <lifeless> poolie_: I'm leaving for the train in < 10 minutes though
[04:47] <lifeless> ok -> train (the 4:03 gets to town hall with at 15 to, allowing a timely walk with no crowds)
[04:48] <spiv> I'm looking at a similar trip, different train line :)
[07:04] <vila> hi all !
[07:33]  * gour sent reply to 'bzr vs. git' thread
[07:34] <luks> hopefull it will not turn into a
[07:34] <luks> ... into a 'bzr vs git' thread
[07:34] <luks> man, I can't type
[07:35] <poolie_> i hope so too
[07:35] <poolie_> i'll kill the thread if it does
[07:35] <poolie_> life's too short
[07:51] <newfeats> hi.  i'm trying to set the BZR_SSH variable.  how would i go about that?
[07:52] <poolie_> on windows or unix?
[07:52] <newfeats> win.
[07:53] <newfeats> i created my SSH keys already and IDed myself.  it suddenly then asks for BZR_SSH variable.
[07:55] <newfeats> i'm using putty from openssh.org's site links.
[07:57] <newfeats> getting tired of conservatives.
[08:17] <beuno>
[08:18] <poolie_> newfeats: (back) what message are you getting exactly?
[08:18] <poolie_> could you open something at http://answers.launchpad.net/bzr
[08:33] <newfeats> poolie_: https://answers.launchpad.net/bzr/+question/49587
[08:34] <luks> newfeats: it's missing the main information, the actual error message
[08:37] <poolie_> ok, i took a stab at it
[08:37] <poolie_> good night though
[08:38] <Spaz> hello :0
[08:38] <Spaz> :)
[08:38] <Spaz> happy halloween
[09:56] <uws> Urgh
[09:56] <uws> Bzr is eating all my RAM
[09:57] <uws>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
[09:57] <uws> 14032 wbolster  20   0 2492m 1.4g 1536 D   13 73.5   5:54.59 bzr
[09:57] <uws> 2GB RAM in total
[09:57] <Peng_> That's awesome.  I've already got Firefox using all my RAM.
[09:58] <uws> 14032 wbolster  20   0 2502m 1.6g 1520 R  100 79.8   6:22.60 bzr
[09:58] <uws> Also eating all 100% of my CPU
[09:59] <uws> well, one of my cores
[10:01] <Peng_> Oh, that's your branch?
[10:01] <Peng_> Jeepers, how large is it to cause that?
[10:01] <uws> Peng_: it's huge
[10:02] <uws> it's (not even up to date) mirror of the webkit svn repository
[10:02] <uws> Finishing pack 5/5
[10:02] <uws> Yay. RAM usage dropped
[10:02] <Peng_> What does "bzr info -v" do? Download the entire indexes?
[10:04] <uws> Peng_: on my branch?
[10:04] <uws> bzr is now eating 100% CPU in "Build phase 0/2"
[10:04] <uws> whatever that may be
[10:06] <uws> ai, RAM usage growing again :(
[10:06]  * uws waits for the OOM to kick in ;)
[10:10] <Peng_> uws: No, in general. I ran "bzr info -v" on your branch, and it was using a lot of bandwidth and the RAM kept growing (only to like 90 MB, but..).
[10:10] <uws> What does "build phase" mean?
[10:10] <Peng_> Oh..I guess I can check the code. :P
[10:11] <vila> uws: building the working tree
[10:11] <uws> takes 100% cpu for minutes already
[10:11] <uws> and this is a relatively fast machine
[10:12] <Peng_> Hmm...hasn't that been improved recently?
[10:13] <uws> 1.8 is quite recent
[10:13] <uws> the progress bar is halfway done and just advanced to "build phase 1/2"
[10:13] <Peng_>     * ``bzr co`` uses less memory. It used to unpack the entire WT into
[10:13] <Peng_>       memory before writing it to disk. This was a little bit faster, but
[10:13] <Peng_>       consumed lots of memory. (John Arbash Meinel, #269456)
[10:13] <Peng_> That's more recent than 1.8.
[10:14] <uws> Hm, good
[10:14] <uws> Branched 29843 revision(s).
[10:14] <uws> YAY!
[10:14] <Peng_> Yay
[10:19] <jrydberg_> hi.
[10:22] <visik7> it's been a while since I used bzr upload I don't remember how to put it through ssh I got bzr: ERROR: Unsupported protocol for url "sftp://...
[10:23] <visik7> or ssh://
[10:23] <uws> vila: Install python-paramiko
[10:23] <uws> vila: then sftp:// ("dumb") and bzr+ssh:// ("smart") should work
[10:33] <visik7> oh
[10:33] <visik7> and for permission there is no way to have a post command that fixes them?
[11:38] <Pieter> is ian here?
[11:43] <james_w> Pieter: Ian Clatworthy?
[11:43] <Pieter> yes
[11:43] <james_w> it's the middle of the night for him
[11:43] <Pieter> ah :)
[12:08] <spiv> aadassdfsd
[12:09] <Odd_Bloke> spiv: aadassdfsd to you too.
[12:12] <spiv> Odd_Bloke: I would also have accepted "gesundheit"
[12:13] <james_w> if I have a 16000 path tree, is it going to be more efficient for bzr workingtree operations to have it split in to directories?
[12:13] <james_w> it's just a flat layout currently
[12:29] <awilkins> james_w: I can't see why it would be any different, personally
[12:31] <james_w> it seemed to be taking an age to read the dirstate
[12:31] <james_w> it's not so bad now though, once it's reasonably up-to-date
[12:31] <awilkins> This on Windows?
[12:32] <james_w> nah
[12:32] <awilkins> I get the same ; once it's "warm" my tree of 4000 odd paths will `bzr st` in less than a second
[12:32] <awilkins> On *nix it's rather faster though :-)
[12:33] <james_w> this is a rather odd tree
[12:33] <awilkins> 16,000 files in one folder, yes, that's a little off
[12:33] <awilkins> *odd
[12:33] <james_w> it's not source code or anything
[12:34] <james_w> just a bunch of log files
[12:34] <awilkins> Heh, I can imagine
[12:34] <awilkins> Why, pray tell, do you version logfiles?
[12:34] <awilkins> Would it not be just as good to incrementally back them up?
[12:34] <james_w> it was Rob's suggestion, though I think I'm implementing it wrong
[12:35] <awilkins> Since a logfile, in my experience, is not mutable once it's finished?
[12:35] <james_w> I think it's supposed to clear the tree after committing
[12:35] <awilkins> Meh?
[12:35] <james_w> so it's instead of logrotate
[12:35] <james_w> I'm using it as a kind of logwatch
[12:36] <awilkins> What, sort of "bzr commit -m "Lots of logs" ; rm *  ?
[12:39] <james_w> hmm, can't find where Rob uses it to compare
[12:40] <james_w> it's on bzr-playground.gnome.org somewhere, but I think it's hidden
[12:51] <awilkins> james_w: Oh, is it supposed to be renaming each rotated log to the same filename?
[12:51] <james_w> yeah, I think that's what Rob does
[12:51] <awilkins> james_w: that way you can compare the logs to each other based on their diff (and presumably spot anomalies easier)(
[12:52] <awilkins> Works ok as long as your diff viewer supports rules to ignore timestamps I suppose.(or if you set your log formats to omit them)
[12:52] <james_w> though his is in in-process, so it just writes the log, commits, and then removes it. I can't really do that, as I have four processes
[12:52] <awilkins> james_w: How about - write log until finished, rename log to a file that ISNT in your ignore pattern
[12:53] <awilkins> Have job that watches for new non-ignored files
[12:55] <james_w> yeah, that could work
[12:57] <awilkins> I've been using it to diff my output from a program so I know if I break it (in the absence of proper unit tests /me slaps own wrist)
[12:57] <james_w> :-)
[12:57] <awilkins> It spits about 9000 files so it's v. useful on that score
[13:27] <Odd_Bloke> What are split-inventories?
[13:46] <rocky> don't suppose anyone's updating http://doc.bazaar-vcs.org/bzr.dev/en/release-notes/NEWS.html for the 1.9rc1 release?
[14:03] <Tak> is there a known winstaller for a bzr-svn that works with a newer bzr than 1.5?
[14:15] <jelmer> Tak: Hi
[14:15] <jelmer> Tak: I think John was looking at creating one for 1.8 last night
[14:15] <jelmer> not sure what the status of that is
[14:15] <jelmer> jam: ping
[14:18] <Tak> jelmer: hello, cool
[14:19] <jelmer> Tak, btw, did you see my changes to monodevelop-bzr?
[14:19] <Tak> yeah, I'm just merging them into my branch now
[14:20] <Tak> I was just going to ask how things were going wrt md-bzr
[14:21] <jelmer> I'm still waiting for a new version of monodevelop to hit debian sid :-/
[14:22] <Tak> heh
[14:22] <Tak> that won't happen until after mono 2.0 hits
[14:26] <Tak> "bzr: ERROR: Repository KnitPackRepository is not compatible with repository KnitPackRepository"
[14:27] <Peng_> Tak: One repo is --pack-0.92, one is --rich-root-pack.
[14:28] <Odd_Bloke> Tak: And the error message has been improved, I believe. :)
[14:28]  * Tak waiting for new bzr to hit debian sid :-P
[14:28] <Peng_> Oh, really? That's good.
[14:38] <jelmer> tak: there's new versions in experimental
[14:51] <Tak> hm @ experimental
[14:56] <Tak> argh, now my wc is rich-root-pack and my lp branch is an old format - how do I resolve this?
[14:58] <Peng_> Tak: Well, you could upgrade the lp branch, or you could push your current branch to a non-rich-root repo to downgrade it (probably).
[14:58] <Peng_> Err, wait.
[14:59] <Peng_> Or pull it into a non-rich-root repo.
[14:59] <Tak> I tried to upgrade the lp branch
[14:59] <Peng_> I dunno. *Something* like that should work, if someone didn't go and break it.
[14:59] <Tak> some of the other branches are rrp, so it's going to be a pita if I can't convert mine somehow
[14:59] <Peng_> Tak: What happened?
[14:59] <Peng_> Tak: You might have to use the full bazaar.launchpad.net URL, and you might have to use sftp
[15:00] <Peng_> (Yes, this is a pain.)
[15:00] <Tak> hmm, I tried the bzr+ssh url
[15:00] <Tak> I'll try others
[15:04] <Tak> ok, it looks like it's going with sftp
[15:08] <Tak> success!
[15:12] <Peng_> Great. :)
[15:13] <awilkins> Yes, the SFTP works, I don't think the smart server does upgrades
[15:14] <Peng_> I thought that had been added recently (1.6?), just thunking over to the VFS. But that might've been something else.
[15:14] <awilkins> Hmm, which version is Launchpad running though
[15:15] <tvainika> jelmer: do you have plans to upload bzr 1.9rc1 to debian experimental?
[15:15] <jelmer> tvainika, Yeah - I just wasn't aware it was out already :-)
[15:16] <Peng_> awilkins: 1.7.1rc1
[15:17] <Peng_> upgrade over bzr+ssh was added in 1.6rc2.
[15:17] <Peng_> But I think there are issues with LP.
[15:19] <james_w> what's the "--strict" argument to testament for?
[15:21] <awilkins> james_w: It seems to produce a different hash
[15:21] <awilkins> james_w: Why this is, I'm not sure
[15:22] <james_w> yeah, that's what concerns me
[15:22] <awilkins> Theory - the strict has includes the log comment
[15:22] <awilkins> git hashes include their log comments, perhaps bzr does not by deafult
[15:23] <james_w> it adds in ie.revision and ie.executable to what is hashed for each ie
[15:25] <chrisob> When I get a 'bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)' What should I check? I know there is connectivity and the user has permission (tested from another PC)
[15:26] <awilkins> chrisob: What's the server?
[15:27] <chrisob> an internal linux server, I dont know if thats what you mean though. I have only just started supporting users on it...
[15:28] <awilkins> Hmm, which protocol are you using
[15:28] <chrisob> SSH
[15:29] <awilkins> Ok, can this machine just open a plain old shell using SSH for that user?
[15:29] <chrisob> bzr info bzr+ssh://<username>@<server>
[15:29] <awilkins> Ah, how about - is this machine running ssh-agent with the appropriate key loaded
[15:30] <chrisob> well it has no problem with another shell connection using ssh
[15:30] <chrisob> i though it could be a key problem
[15:31] <chrisob> though i dont know where it references the key
[15:31] <awilkins> ls
[15:31] <awilkins> oops
[15:36] <awilkins> chrisob: It should just choose try all the keys in the local ssh-agent against the server and see if they work for the user you are specifying
[15:38] <chrisob> okay thought so....thanks for the help
[16:16] <mwhudson> jelmer: bzr.dev get svn://svn.twistedmatrix.com/svn/Twisted/trunk twisted-bzr-svn
[16:16] <mwhudson> bzr: ERROR: The branch svn://svn.twistedmatrix.com/svn/Twisted/trunk has no revision None.
[16:16] <mwhudson> jelmer: ^ seen that one before?
[16:16] <jelmer> mwhudson, yeah
[16:16] <jelmer> mwhudson, what version of bzr-svn?
[16:17] <mwhudson> jelmer: lp:~jelmer/bzr-svn/0.4/ as of a day or two ago
[16:17] <jelmer> hmm
[16:17] <mwhudson> jelmer: i'm updating now, will try again
[16:17] <jelmer> mwhudson, please file a bug
[16:24] <jelmer> mwhudson, I did fix some things related to this, but more than a month ago
[16:24] <jelmer> it's actually another exception masked by an exception handler in bzrlib/builtsin.py
[17:11] <mwhudson> jelmer: still happens with trunk everything
[17:11]  * mwhudson embuginates
[17:19] <mwhudson> jelmer: https://bugs.edge.launchpad.net/bzr-svn/+bug/291686
[17:34] <jelmer> mwhudson, thanks
[17:34] <jelmer> mwhudson, isn't it like 4 in the morning in NZ btw?
[17:34] <mwhudson> jelmer: i'm in london :)
[17:34] <jelmer> ahh :-)
[17:42] <jam> asmodehn: hey, I just saw your email. The change I made isn't in 1.9 AFAIK
[18:08] <asmodehn_> jam : yeah that what I realized... I am using your dev versions now to replicate what I have to ;)
[18:09] <asmodehn_> hopefully it ll go to the end this time ;)
[18:14] <jam> well, worst case I suppose you could use rsync
[18:16] <asmodehn_> I tried that but I am not sure yet how to properly use it
[18:16] <asmodehn_> but yes for now I ll keep using your dev version ;)
[18:16] <asmodehn_> at least for the big transfers
[18:16] <asmodehn_> 1.9rc1 for the rest I think
[18:51] <asmodehn_> jam : mmm doesnt finish... hit the other bug I posted to the mailnig list :-s
[18:52] <jam> asmodehn_: the ldap one?
[18:54] <asmodehn_> yep
[18:54] <asmodehn_> just sent another email with the end of the log
[18:56] <asmodehn_> but yeah maybe I should play with rspush instead :s
[18:57] <jam> so... the locking thing seems like a more significant issue that you need to resolve.
[18:57] <jam> one quick fix is to just do
[18:57] <jam> bzr whoami "My User <my@username>"
[18:57] <jam> or whatever makes sense for you
[18:57] <jam> it sounds like that would fix it
[18:57] <asmodehn_> the whoami already shows the right user...
[18:58] <jam> but is it getting that "by accident" from the system, or because it is set somewhere?
[18:58] <asmodehn_> you mean I need to force it to write it somewhere in bzr ?
[18:58] <asmodehn_> bzr whoami return the current user running the command right ?
[18:59] <asmodehn_> anyway I did that and I ll run the bbranch again...
[19:01] <jam> asmodehn_: aren't you also doing something weird with "sudo/su" ?
[19:02] <jam> could it be that the other user is not configured correctly?
[19:02] <asmodehn_> bzr whoami is fine everywhere...
[19:02] <asmodehn_> I mean return the good user
[19:03] <asmodehn_> maybe I need to "force it" so it gets stored somewhere in .bzr ?
[19:03] <asmodehn_> everywhere I mean ?
[19:42] <ktenney> Howdy, what is the recommended bzrlib version of $>bzr revert -r10
[19:42] <ktenney> I would suspect bzrlib.workingtree.Workingtree.revert, but don't see how to specify a revision to revert to
[19:51] <ktenney> there is bzrlib.transform.revert(working_tree, target_tree, filenames, ... but I don't know where to plug in version numbers
[20:10] <james_w> ktenney: for the transform thing I suspect you pass a target_tree which is
[20:11] <james_w> target_tree = wt.branch.repository.revision_tree(rev_id)
[20:11] <james_w> I suggest you look at cmd_revert in bzrlib/builtins.py
[20:19] <ktenney> james_w: ok, previously I was discouraged from the builtins.cmd_xxx when scripting, however in this case, preferred to the transform thing?
[20:20] <james_w> ktenney: no, I'm just suggesting looking at how bzrlib implements revert might give you some clues about implementing revert
[20:20] <ktenney> james_w: ah, ok, thanks.
[20:24] <asmodehn_> jam: mm it looks like explicitely setting teh bzr whoami the problem has been fixed... I ll test once more though...
[20:38] <asmodehn_> jam: mm ok seems it did... bit confusing... in that case, shouldnt whoami return something more when it s not been setup in bazaar, or when the bazaar and the system result dont match ?
[21:08] <disturbedsaint> hi all
[21:24] <Peng_> Shouldn't "bzr help formats" list the knit formats as deprecated?
[21:30] <Peng_> So...should using btrees on bzr.dev's repo make much of a difference performance-wise?
[21:30] <Peng_> What about something larger?
[21:39] <Peng_> Are the indices created by "bzr upgrade" fully packed and whatnot?
[21:51] <Peng_> (fully optimized, I mean)
[21:53] <fullermd> I would assume they otter be, since it's touching everything anyway.  Not that that necessarily bears on whether it does, but...
[21:53] <Peng_> Right.
[21:54] <Peng_> I tried running "bzr pack", but it took 3 seconds and did nothing.
[22:10] <Peng_> I almost want to try to pack it again, but my disk cache has been thrashed enough today.
[22:44] <lifeless> beuno: search in loggerhead trunk is broken ?
[22:45] <Peng_> lifeless: Does "bzr upgrade"ing to btrees create them all fully optimized and eveyrthing, or should you run "bzr pack" afterwards?
[22:47] <lifeless> Peng_: they should benefit much less from 'bzr pack'
[22:48] <Peng_> Should they benefit at all?
[22:49] <lifeless> yes, there is always the latency impact of multiple pack files
[22:49] <lifeless> so packed is always optimal vs unpacked
[22:49] <lifeless> just the index layer doesn't suck now
[22:52] <Peng_> Well yeah, but... Ignoring multiple pack files, after running "bzr upgrade --1.9", is there any reason to "bzr pack"? Will it save 5 KB of disk space or anything?
[22:54] <lifeless> no
[22:54] <Peng_> OK :)
[22:54] <Peng_> Thanks.
[23:03] <Peng_> Nice, upgrading one large repo to btrees made the indices go from 60 to 18 MB. :)
[23:16] <disturbedsaint> markh: are you there?
[23:16] <markh> disturbedsaint: i am - hi!
[23:16] <disturbedsaint> hi
[23:17] <disturbedsaint> been trying a little more, clean install and all, but not that much progress unfortunately :/
[23:18] <markh> did you try printing win32event.__file__ just before the failing import of win32pipe?
[23:19] <disturbedsaint> didnt get that far :/
[23:19] <disturbedsaint> "FAILED to import tbzrlib - please adjust your PYTHONPATH"
[23:20] <disturbedsaint> since I am running from sources and dont want to install it to site-packages (for now, to keep the new install clean ;) but the tbzr dir is in sys.path
[23:21] <markh> right - the way I do things is to not try and get 'tbzrlib' in site-packages at all - just set PYTHONPATH to point at the parent of the tbzrlib directory.  I do the same with bzrlib itself - PYTHONPATH points at both bzrlib and tbzrlib
[23:21] <markh> the *parent* of tbzrlib must be
[23:21] <markh> ie, a python shell should be able to do a simple import of tbzrlib
[23:22] <disturbedsaint> tried to do it in a clean way with .pth files, but that doesn't really seem to work
[23:24] <markh> set set PYTHONPATH=c:\parent_of_tbzrlib
[23:25] <markh> s/set set/just set/
[23:25] <lifeless> Peng_: :)
[23:26] <markh> (due to some magic, its not necessary for this to be set globally - just when registering the extensions - the path where tbzrlib is written to the com object's registry and used at runtime)
[23:28] <pekuja> is it possible to undo a merge if there's a conflict?
[23:29] <Peng_> pekuja: If it's uncommitted, "bzr revert"?
[23:29] <pekuja> ah, of course
[23:30] <disturbedsaint> markh: the part about it not beeing needed globally is to hard for me to grasp Im afraid :x
[23:30] <markh> um - its not necessary to try and set PYTHONPATH to point at tbzr lib in a "global" way.  Just at the cmdprompt you are using is fine
[23:30] <pekuja> how about a pull? that'd just be a matter of going back to a previous revision, right?
[23:31] <Peng_> pekuja: Well, what do you want to undo? If you want to get rid of the new revisions, "uncommit", though that doesn't touch the working tree.
[23:31] <Peng_> pekuja: You shouldn't pull with uncommitted changes.
[23:32] <pekuja> oh, right, you have to commit a pull too?
[23:32] <pekuja> sorry, I'm new
[23:33] <disturbedsaint> markh: have to reboot, just installed tsvn, brb
[23:33] <pekuja> and I meant if I pull something, but maybe that has changes I didn't want to have... well I guess it's kinda not a real issue
[23:33] <pekuja> well, maybe if the newly pulled code breaks something without creating a conflict
[23:33] <pekuja> how would I "undo" the pull?
[23:34] <pekuja> revert?
[23:34] <Peng_> pekuja: Undo how? You could "bzr revert -r 123" to revert the working tree to a previous revision.
[23:35] <pekuja> yeah, well I meant going back to how my branch was before I pulled somebody else's changes
[23:35] <Peng_> pekuja: What do you mean by that? If you want to remove the new revisions from history, use uncommit.
[23:35] <pekuja> not like undoing the actual changes, just not including them at that point in my particular branch
[23:35] <Peng_> Er.
[23:35] <Peng_> I don't know what that means.
[23:35] <pekuja> ok
[23:36] <pekuja> I'm having trouble explaining it here...
[23:36] <pekuja> but yeah I think uncommit might be what I mean
[23:36] <pekuja> I just meant I'm not looking into removing the changes such that if the other user were to pull from my branch later, they'd have the changes removed
[23:38] <pekuja> so basically, a pull fetches me changes from another user's branch and commits them in my branch, while a merge will get me the changes but commit nothing? (so that I can resolve any conflicts and then commit when the code is ok)
[23:41] <Peng_> A pull makes your branch a mirror of another branch. A merge lets you, well, merge changes into your branch, without having to throw out your unique history.
[23:57] <disturbedsaint> markh
[23:57] <disturbedsaint> still get the same error
[23:58] <disturbedsaint> added the print win32event.__file__ but where would it print to? since the error happens when opening the file-open dialog box
[23:58] <markh> is should print to win32traceutil, just above the ImportError traceback
[23:59] <markh> it should print the path to a .pyd file, and it should be the win32event.pyd next to win32pipe.pyd
[23:59] <disturbedsaint> ah, got it!
[23:59] <disturbedsaint> C:\Program Files\TortoiseHg\win32event.pyd


[09:45] <apw> JanC, yeah, that ... or only buy from h/w manufacturers who have drivers already, let their money do the talking
[20:36] <ZeuZ> Hi, I've got a question regarding the kernel patches applied by Ubuntu. Is it ok for this to be asked?
[20:42] <Snowhog_> ZeuZ: 04/06/14 [08:59:21] * Topic for #ubuntu-kernel is " Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues April 8th, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!"
[20:43] <ZeuZ> Are kernel patches from the ubuntu team released somewhere as .patch files?
[21:40] <ZeuZ> git clone git://kernel.ubuntu.com/ubuntu/ubuntu-maverick.git
[21:40] <ZeuZ>  fails, with "access denied or repository not exported: /ubuntu/ubuntu-maverick.git" is it just me?
[21:44] <TJ-> ZeuZ: My remotes list has Lucid and Natty but no Maverick; not sure if that is because it isn't there, or just that I never wanted it
[21:45] <TJ-> ZeuZ: I think you want this: http://kernel.ubuntu.com/git?p=ubuntu-archive/ubuntu-maverick.git;a=summary
[21:47] <ZeuZ> TJ-, Thanks, I think I'll start by grabbing saucy wich is the last version that works with my hardware though
[21:48] <TJ-> ZeuZ: The trick is, the EOL (end of life) releases move to 'ubuntu-archive', but most published Wiki pages don't mention that