[00:47] <fR__> how can I make pbuilder-dist not regenerate the source package files? I'm trying to build and upload multiple archs to a private apt server and it doesnt work because the tar/diff files are different each time (specifically it seems the content is the same, but they're recreated slightly and have different hashes)
[03:22] <cody-somerville> fR__, yes
[03:26] <cody-somerville> fR__, You can either set DEBBUILDOPTS="-b" in ~/.pbuilderrc or pass --debbuildopts -b when you call pbuilder
[04:15] <Kaptein_> Hello , my name is Marius and have been a user of Linux for the last 4 years , the two last on Ubuntu. Anyway i was wondering if theres any way i can contribute with code? I have acquired some C++ skills over the last year :)
[04:24] <fR__> cody-somerville: thanks
[04:24] <fR__> cody-somerville: it seemed that also passing -nc worked, but this makes more sense
[06:42] <dholbach> good morning
[06:42] <ruslanr> dholbach: good morning :)
[06:42] <nixternal> good morning dholbach
[06:42] <dholbach> hi ruslanr
[06:42] <dholbach> hey nixternal
[06:43] <dholbach> how are you guys doing?
[06:43] <nixternal> tired :)
[06:43] <nixternal> riding the bike like always :)
[06:43] <dholbach> :-)
[06:43] <nixternal> working on some KDE and Kubuntu magic to hopefully be released with karmic
[06:44] <dholbach> what kind of magic?
[06:44] <nixternal> a magician never reveals his secrets
[06:44] <nixternal> netbook loving :)
[06:44] <dholbach> man... you could reveal some secrets at Ubuntu Developer Week!
[06:44] <nixternal> when is it?
[06:44] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep
[06:45] <dholbach> still has some open slots
[06:45] <dholbach> maybe something about easy pyqt hacking?
[06:46] <dholbach> asac: you wanted to add yourself to UDW too! :)
[06:46] <nixternal> interesting..how long has then been in prep and why am I just not hearing about it?
[06:46] <dholbach> nixternal: man, I asked for contributions to it for a very long time :-)
[06:47] <nixternal> I would be jiggy doing some PyKDE, Plasmoid Hacking, something...need to check with the rest of the team and see if anyone else would be interested as well
[06:47] <nixternal> I must have been sleeping when you asked :p
[06:47] <dholbach> 2009-06-25 08:12:47 was when I reset it again
[06:47] <nixternal> ScottK, Riddell, rgreening ^^
[06:47] <dholbach> nixternal: it'd be great if it was something hands-on
[06:47] <dholbach> like you present a piece of code that people can try out or something
[06:48] <ScottK> dholbach: I saw a buddy of mine tonight that's very Windows oriented and has always resisted anything Linux I've tried to push him to (he is the IT guy for a medium sized business).  I showed him my Mini 10v with Kubuntu on it and it took him about 30 seconds to say he wanted one.
[06:48] <nixternal> ScottK: you get your mini today?
[06:48] <ScottK> nixternal: Yep
[06:48] <nixternal> I am loving this mini 10v with kubuntu on it
[06:48] <nixternal> did you play with the dell garbage at all?
[06:48] <dholbach> ScottK: NICE
[06:48] <nixternal> one update and it was broken...haha
[06:49] <nixternal> the first thing I was greeted with when I booted it was Apport :)
[06:49] <ScottK> nixternal: Mine came with XP.  I couldn't find the hardware I wanted with Ubuntu.  I did boot it and it was truly ugly and unsuitable.
[06:51] <nixternal> ahh
[06:53] <ScottK> I had to put the panel on autohide and slide the config window as high as it would possibly go to see the 'next' button on the WPA passphrase entry screen.
[06:53] <ScottK> They did nothing to make it work on a netbook.
[06:54] <ScottK> nixternal: Are you having trouble with the touchpad being jumpy?
[06:55] <nixternal> ScottK: ya, the touchpad sucks
[06:55] <ScottK> nixternal: Look in my PPA.  Try the synaptics thingy there.  I ported a patch tseliot did to Karmic
[06:55] <nixternal> some of the configs in gnome and kde suffer that same exact thing with having to move the window up so you can click OK or next
[06:55] <ScottK> Should smooth things up a bit.
[06:56] <nixternal> ya, I am using tseliots ppa
[06:56] <ScottK> He's only got this patch for Jaunty
[06:56] <nixternal> actually, it was already incorporated into karmic I thought
[06:56] <ScottK> Nope
[06:56] <nixternal> originally, the touchpad didn't even work
[06:56] <nixternal> with the shipped ubuntu from dell it didn't work, and at first in kubuntu it didn't work
[06:57] <nixternal> it seems there was 0 QA done on the mini when it was shipped, and my buddy experienced the same exact issues with his 10v as well
[06:58] <ScottK> It was jumpy in XP too.
[06:59] <ScottK> nixternal: It's a whole lot better with the one patch added.
[07:01] <pitti> Good morning
[07:02] <TheMuso> Morning pitti
[07:03] <pitti> kirkland: thanks; I'm not quite sure whether cache or config, but that should be fine :)
[07:04] <pitti> kirkland: thanks for stopping my home dir cluttering :)
[07:27] <dholbach> nixternal, scottK, Riddell, rgreening: if you have a topic you'd like to talk about at UDW, please let me know soon - I'd like to have the schedule in the bag before I go on vacations (end of next week :-))
[07:27] <dholbach> (if you have more than one, that's great to :-))
[07:32] <ogra> hmm, update-manager didnt want to upgrade upstart for me ... dist-upgrade did ... strange
[07:32]  * ogra reboots to new upstart
[07:35] <ogra> great, seems Keybuk didnt mess up my system :)
[07:36] <fabbione> morning guys
[07:36] <ogra> hey fabbione
[07:37] <fabbione> hey oliver!
[07:37] <pitti> Padre!
[07:37]  * pitti hugs fabbione
[07:37] <fabbione> hey pitti
[07:38] <fabbione> ogra: at somepoint, once I am back from vacation, I need to suck your brain for a few minutes :)
[07:39] <ogra> sure, feel free :)
[07:39]  * fabbione sucks...
[07:39] <fabbione> ;)
[07:39]  * ogra hears the slurping from the top
[07:40] <ogra> hmm, my boot is still very slow ...
[07:40]  * ogra reboots with profile to see if readahead update helps
[07:48]  * StevenK prods pitti good naturedly for MIRs :-)
[07:49] <pitti> StevenK: have the tab open already
[07:51] <ogra> hmm, didnt really get faster
[07:54] <StevenK> pitti: Heh, great. :-)
[07:54] <pitti> zul, kirkland: I'd like to have postgresql-8.4 by default in karmic; is that ok with you guys? should I talk to someone else in the server team about it, or "just do it"?
[07:57] <Sarvatt> darn, 2 seconds slower here even
[08:07] <StevenK> pitti: pgsql 8.4 is out? Hmm, I'm behind the times.
[08:21] <pitti> just synced from Debian
[08:22] <mvo> pitti: if the sync script is still close could you sync apt-xapian-index from debian/sid too? or should I rather write a fomal sync request?
[08:23] <pitti> mvo: doing
[08:24]  * mvo hugs pitti
[08:46] <ogra> hmm, my boot sits quietly for 10s without moving
[08:47] <ogra> seems udevd probes like mad
[08:52] <pitti> I'm off for a few hours, need to do some errands
[09:59] <Keybuk> Session terminated, killing shell...
[09:59] <Keybuk> Build killed with signal 15 after 150 minutes of inactivity
[09:59] <Keybuk> that's very rude, mr armel buildd
[10:00] <ogra> Keybuk, what package ?
[10:00] <Keybuk> ogra: Upstart
[10:00] <Sarvatt> happened to me with mesa as well
[10:00] <ogra> Keybuk, afaik NCommander filed an RT ticket for setting the timeout values higher
[10:01] <ogra> Keybuk, so either wait or make your code compile faster ;)
[10:01] <Sarvatt> https://edge.launchpad.net/ubuntu/+source/mesa/7.5~rc4-1ubuntu3/+build/1109719/+files/buildlog_ubuntu-karmic-armel.mesa_7.5~rc4-1ubuntu3_FAILEDTOBUILD.txt.gz
[10:01] <cjwatson> why's upstart sitting inactive for 2.5 hours in the middle of the build?
[10:01] <Keybuk> cjwatson: it wasn't inactive, it was compiling
[10:01] <cjwatson> well, inactive => no output
[10:01] <ogra> Sarvatt, yes, i looked at that already, its on NCommander's list
[10:01] <Keybuk> sure, it's compiling a vewy vewy big file
[10:01] <cjwatson> which is all the buildd can tell atm
[10:01] <Keybuk> though I am quite amused that it takes > 2.5 hours on arm :)
[10:02]  * liw is finding X in karmic to be unstable enough to be unusable :(
[10:02] <Keybuk> actually, that one's not unreasonbly big
[10:02] <cjwatson> Keybuk: mind if I fix up the seeds and ubuntu-meta for the new upstart?
[10:03] <Keybuk> cjwatson: sure
[10:03] <Keybuk> cjwatson: I put provides and replaces in, which seems fine for apt, but not for update-manager fwict
[10:03] <Keybuk> was just looking at that
[10:03] <Keybuk> liw: are you sure it's X that's unstable?
[10:03] <liw> Keybuk, no
[10:04] <Keybuk> liw: do you get randomly logged out after some interesting number like 10 minutes?
[10:04] <liw> Keybuk, I get randomly logged out at random intervals like from under a minute up to seven hours
[10:05] <Keybuk> liw: it's basically caused by X and getty sharing a vt and getty killing X
[10:05] <Keybuk> liw: "sudo stop tty1" after you login
[10:06] <liw> Keybuk, yay, one more thing to do after I login -- but thanks, I assume a proper fix is forthcoming
[10:06] <Keybuk> liw: pitti has been working on it
[10:06] <liw> (although since update-manager now crashes on me, perhaps I won't be getting the fix either *sigh*)
[10:07] <ogra> wasnt that fixed yesterday ?
[10:07]  * ogra thought it was in gdm's changelog from last night
[10:07] <liw> crashes without a crash report, more's the pity
[10:07] <cjwatson> new ubuntu-meta might make update-manager's job easier
[10:07] <cjwatson> at least those split-out upstart packages weren't Essential: yes ;-)
[10:08] <liw> hm, actually, something (apport?) told me that update-manager crashed, after which I happily finished the update using it
[10:08] <ogra> yeah, bug 396226 appaers to be closed by the last gdm upload
[10:08] <ogra> liw, is your system up to date ?
[10:08] <cjwatson> liw: maybe it forked and a subprocess crashed? </guess>
[10:08] <liw> ogra, now it should be; it was up to date as of yesterday afternoon though
[10:09] <Keybuk> cjwatson: I'm confused as to why update-manager didn't dtrt though?
[10:09] <liw> cjwatson, possibly. in that case apport (if that was it) shouldn't have been triggered, though?
[10:09] <ogra> right, the gdm fix was uploaded around 6pm
[10:09] <ogra> Keybuk, at least dist-upgrade did :)
[10:09] <cjwatson> Keybuk: mm, I haven't tried it. apt-get dist-upgrade wanted to remove upstart-compat-sysv and upstart-logd, but for some reason not startup-tasks or system-services
[10:10] <cjwatson> Keybuk: oh, don't you want Conflicts on those packages too?
[10:10] <ogra> it removed it for me ... system still boots
[10:10] <cjwatson> Replaces: startup-tasks, system-services, sysvinit, upstart-compat-sysv
[10:10] <cjwatson> Provides: startup-tasks, system-services, upstart-compat-sysv
[10:10] <liw> is the "These windows do not support 'save current setup' and will have to be restarted manually..." bug going to be fixed, too? :) (that's the error dialog I get after I log in, for gdm-simple-greeter)
[10:10] <cjwatson> Conflicts: sysvinit
[10:10] <Keybuk> cjwatson: I wasn't sure on the Conflicts
[10:10] <cjwatson> "replace entire package" => Conflicts+Replaces, per policy
[10:10] <ogra> liw, thats the one remaining one
[10:10] <mvo> liw: what is the traceback?
[10:10] <liw> mvo, of the update-manager thing? there is none
[10:10] <Keybuk> ok, let me add those as well
[10:11] <mvo> liw: nothing in the crash file?
[10:11] <cjwatson> Replaces alone is just "I stole some of your files"
[10:11] <liw> mvo, nothing whatsoever, except an old epiphany one
[10:11] <liw> mvo, I apologize for whining about something you can't fix :(
[10:11] <Keybuk> cjwatson: I thought Replaces+Provides was the special one
[10:11] <cjwatson> nah
[10:12] <cjwatson> http://people.ubuntu.com/~cjwatson/ubuntu-policy/policy.html/ch-relationships.html#s7.6.2
[10:12] <Keybuk> cjwatson: ah, no, that's the special one in dpkg isn't it
[10:12] <Keybuk> apt needs conflicts as well
[10:12] <Keybuk> I remember
[10:12] <liw> hmm... gdm-greeter, /dev/sdd1, and xrandr... just three things for me to do after login, to work around bugs, now
[10:12]  * liw quits whining and goes find lunch
[10:13]  * mvo hugs liw
[10:17] <ogra> Keybuk, hmm, no /etc/event.d/tty files anymore ?
[10:17] <Keybuk> ogra: /etc/init/tty*
[10:17] <ogra> oh, thats the new dir
[10:17] <ogra> i was looking for jobs.d :)
[10:17] <Keybuk> man 5 init

[10:18] <ogra> i still have /etc/event.d/control-alt-delete and /etc/event.d/sulogin left though
[10:18] <Keybuk> ogra: yes, I haven't done any magic to migrate user changes from /etc/event.d into /etc/init yet
[10:18] <Keybuk> so I deliberately left them there
[10:18] <ogra> ok
[10:18] <Keybuk> before FF, there'll be some Perl that'll migrate things over and clean up
[10:19]  * ogra guesses the serial console howto will need updating
[10:20] <Keybuk> that's weird
[10:20] <ogra> ?
[10:20] <Keybuk> my init(8) is out of date
[10:21] <Keybuk> cjwatson: so, here's one for you ;)
[10:21] <ogra> mine isnt
[10:21] <Keybuk> I seem to have both /usr/share/man/man8/init.8
[10:21] <Keybuk> and /usr/share/man/man8/init.8.gz
[10:21] <Keybuk> :p
[10:21] <cjwatson> DDTT ;-)
[10:21] <cjwatson> dh_installman called after dh_compress?
[10:22] <Keybuk> ah, no
[10:22] <Keybuk> "make install" vs "dpkg -i"
[10:22] <cjwatson> ah
[10:22] <cjwatson> I doubt that man-db defines any ordering between those two files
[10:26] <pitti> liw: should be fixed with latest gdm (ubuntu5)
[10:26] <Keybuk>  apparmor depends on upstart-compat-sysv (>= 0.3.9-6) | sysvinit (>= 2.86.ds1-56ubuntu3); however:
[10:26] <Keybuk> *sigh*
[10:27] <Keybuk> I wonder why it even does that
[10:34] <Keybuk> cjwatson: you were doing a seed and meta update, right?
[10:35] <cjwatson> I did
[10:36] <cjwatson> does it need a further change?
[10:39] <Keybuk> cjwatson: did you drop the upstart-logd dep?
[10:39] <Keybuk> ah yes
[10:39] <Keybuk> great, no further change necessary
[10:39] <Keybuk> my -changes folder hadn't quite caught up
[10:40] <cjwatson> ok
[10:41] <cjwatson> Keybuk: http://cdimage.ubuntu.com/custom/20090710-i486/ http://cdimage.ubuntu.com/custom/20090710-i586/
[10:41] <cjwatson> Keybuk: gratuitously oversized; I haven't bothered to investigate why
[10:41] <cjwatson> no idea whether it'll boot successfully, etc. :-)
[10:42] <Keybuk> I'm sure it'll break usb-creator in some new and unique way
[10:42] <Keybuk> but great, I shall download that and get testing presently
[10:43] <cjwatson> Keybuk: I just ran it through the usual cdimage code, so hopefully not too much new and exciting there, but the live filesystems were necessarily built rather weirdly
[10:59] <dupondje> Brasero broken ? it can't find a single device here :s
[11:04] <Keybuk> dupondje: -v
[11:10] <dupondje> Keybuk: it segfaults on brasero --version :(
[11:10] <dupondje> ii  brasero                                    2.27.3-0ubuntu1                            CD/DVD burning application for GNOME
[11:12] <Keybuk> dupondje: karmic?  use apport to file a bug
[11:15] <dupondje> https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/397776
[11:15] <dupondje> there
[11:19] <Keybuk> the speed difference between "initctl list" and "sudo initctl list" is kinda interesting
[11:59]  * NCommander grumbles awake
[11:59] <NCommander> (ish)
[12:06] <NCommander> ogra, Keybuk I extended the RT request on the timeout for mesa now that I see its the same issue
[12:07] <ogra> NCommander, i thought you wanted to have it higher generally
[12:07] <ogra> that would make a lot more sense given that even upstart times out now
[12:07] <NCommander> ogra, I did, but I also provided a list of packages we know are doing it
[12:07] <NCommander> But its up to IS to decide if they want to extend the timeout overall, or just for specific packages
[12:08] <pitti> tkamppeter: foo2zjs now recommends tix and thus tries to pull tix into main; I don't think that we want that; can the recommends be dropped to a suggests?
[12:09] <ogra> well, add upstart to the list :)
[12:09] <ogra> doesnt build either
[12:13] <NCommander> Ugh
[12:13] <NCommander> We need to take a look at why lzma is so slow on ARM
[12:13] <NCommander> Even on 1GHz hardware, it should be fast enough to crunch upstart down to size
[12:13] <ogra> what makes you so sure its lzma ?
[12:14] <NCommander> ogra, that's what it was for KDE, and mesa using lzma compression
[12:14] <NCommander> I haven't looked at upstart yet
[12:14] <NCommander> (the change that broke KDE was also lzma)
[12:14] <NCommander> upstart is an unrelated FTBFS
[12:15] <ogra> well, i dont see any indicator in either upstart or mesa that its lzma related
[12:15] <NCommander> (if it dies in dpkg-deb, and pkgstriptranslations has run, and it uses LZMA compression, then it usually is just lzma taking too long)
[12:15] <NCommander> ogra, mesa fails in dpkg-deb, the options have it use lzma compresison, its failing during creation of the actual debs
[12:16]  * ogra thought he saw it dying in unpacking ... 
[12:16]  * ogra checks again
[12:16] <ogra> oh, right
[12:16] <NCommander> ogra, right, so mesa is the same issue, upstart isn't; the compiler looks like its hanging there
[12:17] <ogra> yeah, its Keybuk's code or packaging
[12:18] <tkamppeter> pitti, yes, the tix recommendation in foo2zjs can be changed to a Suggests.
[12:19] <NCommander> grumble
[12:19] <NCommander> That's going to be annoying to fix
[12:19] <ogra> we should just run the buildds with cerosine instead of diesel :)
[12:22] <NCommander> ogra, huh?
[12:22]  * NCommander felt that joke buzz my hair as it flew over my head
[12:44] <pitti> tkamppeter: do the hplip upstream guys read LP? bug 394447 has an upstream task, but no link to an upstream bug
 kirkland: thanks for stopping my home dir cluttering :)   ....
[13:08] <kirkland> pitti: wow, that one patch stopped your home dir cluttering ?   :-)
[13:09] <kirkland> pitti: if you're looking for opinions, you could mention it on the ubuntu-server@ mailing list, or in next week's community IRC meeting (Tuesday)
[13:09] <kirkland> pitti: we had a similar discussion about PHP5.3 this week
[13:09] <tkamppeter> pitti, HP uses Launchpad as upstream bug tracker, so adding an upstream task makes a real upstream bug report out of the Ubuntu bug.
[13:10] <kirkland> pitti: on the other hand...  you could just "do it", and you won't catch any flack from me, or rest of Canonical's server team;  not sure about the rest of the community
[13:14] <NCommander> kirkland, how goes the kvm SRU :-)
[13:28] <kirkland> NCommander: SRU or backport?
[13:28] <kirkland> NCommander: oh, it's in -proposed
[13:28] <NCommander> kirkland, did we say we were going to wait on the SRU before backporting?
[13:28] <NCommander> Right
[13:28] <NCommander> ;-)
[13:29] <kirkland> NCommander: hmm, yeah, I'm not opposed to that
[13:30] <ScottK> If you do the backport first you'll never get SRU testers.
[13:30] <NCommander> kirkland, my concern is in the (admitly unlikely case) the update gets deleted
[13:30] <NCommander> ScottK, this is the backport of kvm
[13:30] <kirkland> NCommander: let me poke a few people to verify the -proposed upload
[13:30] <ScottK> NCommander: OK.  I got that.
[13:30] <NCommander> ScottK, its already been heavily PPA tested, but I wanted the latest SRU to land before I give it the magic blessing
[13:30] <ScottK> NCommander: I agree with that.
[13:31] <NCommander> ScottK, indeed
[13:38] <pitti> kirkland: the only 8.3 specific dependency is bacula, I'll do that migratino
[13:42] <kirkland> pitti: could you have a look at my last comment to https://bugs.edge.launchpad.net/ubuntu/+source/kvm/+bug/392295 and see if that's reasonable?
[13:44] <pitti> kirkland: answered in the bug
[13:45] <kirkland> pitti: cool, thanks.
[14:06] <bigon> could someone have a look at gupnp-idg and telepathy-mission-control-5 that are sitting in karmic new queue?
[14:08] <seb128> bigon, why?
[14:09] <bigon> tp-mc-5 will be needed by empathy 2.28
[14:09] <bigon> and gupnp-igd provide upnp support to libnice (I don't know if we want that)
[14:10] <bigon> booth are stuck in debian newqueue ATM
[14:11] <seb128> bigon, is there any hurry, is it blocking an update?
[14:11] <seb128> bigon, ie any reason to drop other tasks to hurry on that now or can it wait?
[14:14] <bigon> not really actually (and I've just checked ff is in 1month+ ahead)
[14:16] <bigon> but maybe enabling upnp support is not a bad idea to let ppl test it
[14:16] <seb128> right, but that seems it can wait for monday
[14:16] <seb128> I will have a look next week if nobody is faster
[14:17] <seb128> I still have things I want to get done today and it's friday afternoon ;-)
[14:17] <bigon> no problem :)
[14:44] <chrisccoulson> hi mbiebl - have you done any more work on tracker packaging recently? it seems that a 0.7 release is quite close, and i wanted to start thinking about the packaging in ubuntu now
[15:18]  * liw has the first results from zsync benchmarking: for hardy-security updates, it saves 25% compared to plain http, if the .debs get recompressed
[15:24] <robbiew> cjwatson: ^^
[15:24] <robbiew> :)
[15:25] <cjwatson> liw: recompressed ordinarily, or with gzip --rsyncable?
[15:25] <liw> with --rsyncable
[15:25] <liw> I'm not entirely impressed with these results
[15:25] <kees> Keybuk: it's probably something very old
[15:37] <cjwatson> liw: mm, not superb. I'm interested in Packages file savings?
[15:37] <liw> cjwatson, that's on my todo list, haven
[15:38] <liw> 't gotten that far yet
[15:39]  * cjwatson nods
[15:40] <liw> is there an archive of the Packages files easily accessible?
[15:41] <cjwatson> I don't think so, I think we throw those away
[15:41] <cjwatson> you'd probably just have to sit downloading them daily for a while to get a decent archive
[15:41] <cjwatson> or you might try snapshot.debian.net for near-equivalents, maybe?
[15:41] <cjwatson> I can't remember if it has the right kind of indices
[15:42] <liw> for now, I'll just test the packages files between hardy and hardy-security, but I'll set up something to snapshot the packages fail daily for karmic
[15:43] <liw> hm, no, there's no point in updating from hardy to hardy-security for the Packages file
[15:43] <liw> so I'll just do the snapshotting first
[15:43] <cjwatson> perhaps compare hardy-security to hardy-updates for that?
[15:49] <liw> how often does the packages file get updated? hourly?
[15:51] <liw> hm, total bytes in original .debs: 1271336808; recompressed with --rsyncable: 1283683849; that's less than 1% of increase
[15:52] <cjwatson> hourly, yes
[15:52] <cjwatson> liw: what's that, main?
[15:52] <cjwatson> oh, the security packages
[15:52] <liw> cjwatson, yeah, security
[15:52] <cjwatson> did you recompress hardy as well?
[15:52] <cjwatson> or do you not need to?
[15:53] <liw> both files need to be re-compressed
[15:53] <cjwatson> mm, that's what I thought
[15:55] <liw> that should not be a problem, though, since apt-sync needs to re-create the .deb (using dpkg-repack) and can do --rsyncable then
[15:55] <liw> hmm... if I undo the compression within the .deb, the percentage of re-used bytes grows up to 50
[15:56] <liw> can we stop compressing .debs, please? ;-)
[15:57] <cjwatson> did you exclude non-gzipped packages from the set, or just recompress them?
[15:58] <liw> essentially I do this:     (cd "$temp" && ar x x.deb && gunzip *.gz && gzip --rsyncable *.tar &&
[15:58] <liw>      rm -f x.deb && ar qc x.deb *)
[16:00] <liw> hm, maybe I should push the bzr branch with these scripts somewhere public
[16:01] <liw> (I decided it's worth automating the whole running of the benchmarks, since I'm a klutz and will be running them many times. Also, helps other people reproduce results.)
[16:04] <cjwatson> right, so maybe exclude anything bz2/lzma-compressed there, since we think we know those aren't going to work out so well
[16:05] <liw> I should to that, yes
[16:05] <liw> or I could convert those compressions to gzip --rsyncable?
[16:06] <cjwatson> or that, yes
[16:06] <cjwatson> it'd be useful data even if we don't do that with the .debs themselves
[16:06] <liw> I wonder how many of the security updates do that, anyway
[16:08] <liw> there's a bunch
[16:11] <mterry> cjwatson, one more question -- is there a standard mapping for area-zones to city-zones, (e.g. US/Eastern -> America/New_York) sitting around somewhere?  Seems to only be US/MX/CA that use area-zones
[16:13] <cjwatson> the 'backward' file in the tzdata source package has an equivalence list
[16:13] <mterry> cjwatson, you are chock-full of useful information.  :)  Thanks
[16:15] <mterry> evand, duh about oem reserved name.  :)  thanks for the catch
[16:16] <evand> Sure thing.  I completely missed it while eying over the code.
[16:18] <liw> for x in hardy-security-2009-07-10/*.deb; do echo "$x $(ar t $x | grep -E '\.(lzma|bz2)$' | tr '\n' ' ')"; done | awk '/ (control|data).tar.(lzma|bz2)/ { print $1 }' | sed 's:.*/::;s:_.*$::' # my youth was misspent
[16:19] <liw> 186 packages, mainly openoffice.org and linux kernel related ones
[16:21] <ScottK> lzma will go up a lot in Karmic.
[16:23] <llml> hi, i found mysqlslap is listed as one of the MySQL 5.1 Client Programs at http://dev.mysql.com/doc/refman/5.1/en/programs-client.html, but not included in any of the apt packages like other client programs. i'm not sure if it's a bug or intended?
[16:27] <llml> maybe not the right place to report this:(
[16:33] <kees> Keybuk: hey, you didn't update the apparmor bzr tree.  :P
[16:39] <kirkland> pitti: around?
[16:39] <pitti> kirkland: yes (in release meeting)
[16:39] <kirkland> pitti: perhaps naive MIR question....
[16:40] <kirkland> pitti: i wonder about the utility of the wiki portion of the MIR
[16:40] <kirkland> pitti: what does the wiki add, that couldn't be handled in an LP bug?
[16:41] <pitti> kirkland: some MIR bugs paste the info directly, that's generally fine
[16:41] <pitti> kirkland: not much, just better formatting, but it's not important
[16:41] <kirkland> pitti: okay, cool, thanks.
[16:41] <pitti> by and large, just for historical reasons
[17:04] <mathiaz> james_w: hey - could you bump mysql-dfsg-5.{0,1} in the package importer?
[17:04] <wip> so nobody care about all the bugs in the RT-kernel???
[17:05] <james_w> mathiaz: I can, but it won't be very quick I'm afriad
[17:05] <wip> am i the only one trying to make music with linux?
[17:05] <james_w> the LP API is currently broken
[17:05] <mathiaz> james_w: I'm fine with that
[17:05] <james_w> should be back up today
[17:06] <mathiaz> james_w: ok - I was playing with the bzr branches yesterday
[17:06] <james_w> queued anyway
[17:06] <james_w> everything go ok?
[17:06] <wip> anyone knows, maybe someone is working on it and i will finally shut the $"#% up
[17:07] <Quintasan> wip: why don't you ask the kernel team?
[17:07] <mterry> cjwatson, re: your 'backward' isn't exported.  Yeah, I was looking at that.  It might just be easiest to hardcode US/MX/CA mappings.
[17:07] <cody-somerville> Whats the best way to do deal with an upstream who released an rc and actual release (note there are changes between the two releases) but don't change the version (so the tarball name is different but naturally have different md5sums)?
[17:08] <wip> Quintasan: is there a specific irc channel?
[17:08] <mathiaz> james_w: well - I was suprised how easy it was to merge a new debian revision
[17:08] <mathiaz> james_w: but when I tried to merge a new upstream version it got much more complicated
[17:08] <Quintasan> wip: dunno try #ubuntu-kernel or use mailing lists
[17:08] <james_w> mathiaz: what did you try?
[17:09] <mathiaz> james_w: so I tried squid, which was a new debian revision
[17:09] <james_w> cody-somerville: the RC is in the archive?
[17:09] <cody-somerville> james_w, yes
[17:09] <mathiaz> james_w: bzr branch sid/ k-merge
[17:09] <mathiaz> james_w: cd k-merge; bzr merge ../karmic
[17:09] <james_w> cody-somerville: I'd just change the version number, with a ".really" or something if needed
[17:09] <mathiaz> james_w: it went very well
[17:09]  * cody-somerville nods.
[17:09] <james_w> and explain in the changelog
[17:10] <james_w> not really another option
[17:10] <mathiaz> james_w: I could do things like bzr diff --old ../sid or bzr diff --old ../karmic
[17:10] <james_w> mathiaz: cool
[17:10] <mathiaz> james_w: and things were much faster than using debdiffs
[17:10] <mathiaz> james_w: after that I tried drbd8 which was a new upstream version
[17:11] <mathiaz> james_w: and then I got way more information to look at, tons of conflicts
[17:11] <cjwatson> mterry: you could take md5sums of everything in /usr/share/zoneinfo and look for dups; could be done pretty cheaply I think
[17:11] <mterry> cjwatson, or could add tzdata to d-i source packages and steal the backward file
[17:11] <mathiaz> james_w: so I'm not about the correct workflow to do a merge when there is a new upstream version
[17:11] <james_w> mathiaz: still merging from debian?
[17:12] <mathiaz> james_w: yes
[17:12] <cjwatson> cody-somerville: doesn't really matter what the upstream tarball is called; you'll be renaming it to foo_1.0.orig.tar.gz anyway, and the directory at the top-level of the tarball doesn't matter as dpkg-source canonicalises that itself
[17:12] <james_w> mathiaz: let me try
[17:12] <mterry> cjwatson, but really, I thought the number of zones was small enough to get away with cheap and dirty
[17:12] <cjwatson> mterry: could do, though it feels messy
[17:12] <james_w> mathiaz: ah, where are the branches?
[17:12] <mathiaz> james_w: hm - right - it wasn't drbd
[17:12] <cody-somerville> cjwatson, They name their tarball as foo_1.0.orig.tar.gz
[17:12] <cjwatson> mterry: it's probably OK, just consider whether there's any rate of change there
[17:12] <mathiaz> james_w: let me go try to remember which package I choose
[17:12] <cody-somerville> cjwatson, so the md5sum mismatches foo_1.0.orig.tar.gz already in the archive
[17:13] <cjwatson> cody-somerville: oh, in that case what james_w said. consider this a reason not to package RCs as 1.0 in the future ;-))
[17:14] <mterry> cjwatson, Yar, I'm not sure.  How often do the area-zones change? (every time the law renames them?  :))  It doesn't sound like tzsetup upstream is likely to add new translations for area-zones soon
[17:14] <cody-somerville> superm1, ^^ ;]
[17:14] <cjwatson> it's usually every time some legislature gets a bright idea, yes
[17:15] <mathiaz> james_w: found it - it was ipsec-tools
[17:15] <cjwatson> not so much renames, but additions (think things like Indiana and Arizona)
[17:15] <cjwatson> which I think are city-based in the US but I don't know whether that's the case everywhere
[17:16] <james_w> mathiaz: thanks, pulling, I'll get back to you in a minute :-)
[17:17] <mathiaz> james_w: great - so what I did was branch sid/ k-merge; cd k-merge; merge ../karmic
[17:17] <james_w> you were merging ubuntu in to Debian?
[17:17] <mathiaz> james_w: and I end up with 68 conflicts
[17:17] <mathiaz> james_w: well - I was trying to merge debian in ubuntu
[17:18] <mathiaz> james_w: ie - upload a new version of ipsec-tools to ubuntu based on the debian package
[17:19] <mathiaz> james_w: if I do the other way around (branch karmic/ k-merge; cd k-merge; merge ../sid) I end up in the same situation
[17:19] <mathiaz> james_w: with 68 conflicts to resolve
[17:25] <ogra> doko, is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39501 fixed in our gcc 4.4 ?
[17:26] <ogra> (the bug sadly only talks about 4.3.x)
[17:26] <james_w> mathiaz: I think that it's because the Ubuntu history is more complete than the Debian one
[17:26] <james_w> mathiaz: I need to spend some time looking at it though
[17:27] <james_w> could be annoying if this affects a lot of packages
[17:28] <doko> ogra: yes, and 4.3 as well
[17:28] <mathiaz> james_w: ok
[17:28] <james_w> mathiaz: thanks for testing
[17:29] <ogra> doko, yes, i saw 4.3 ... i have some werid stuff going on the the ogg gstreamer plugin and digging got me to that bug, thanks for the info
[17:29] <mathiaz> james_w: now the last block I stumbled upon was how to construct the final src package.
[17:29] <mathiaz> james_w: in the case of the squid package, bzr merge worked perfectly well
[17:30] <mathiaz> james_w: and I ended up with (almost) the same debdiff as posted in LP
[17:30] <mathiaz> james_w: but when I tried to bzr bd -S it failed as there wasn't any .orig file.
[17:30] <mathiaz> james_w: IIUC in the long term it won't matter anymore as we would just push to the LP branch
[17:31] <mathiaz> james_w: but in the short term I'd still need to download the .orig file from somewhere
[17:31] <james_w> it should have extracted it
[17:32] <james_w> mathiaz: ah, it's possibly a bug that I fixed the other day
[17:33] <mathiaz> james_w: so bzr bd is supposed to rebuild the .orig file from the bzr tree?
[17:33] <james_w> mathiaz: if you still have the branch around then the output of "bzr bd -S" would allow me to confirm
[17:33] <james_w> yeah
[17:34] <lool> evand: Just a note that I merged the guadalinex branch except for s/Ubuntu/distribution changes in lp:usb-creator (#310804) will unsub main sponsors now
[17:35] <mvo> pitti: did you had a chance to look at my apport branch yet (not urgent, just curious)?
[17:35] <mathiaz> james_w: http://paste.ubuntu.com/214923/
[17:35] <james_w> mathiaz: yup, stupid bug, sorry
[17:35] <james_w> http://bazaar.launchpad.net/~bzr-builddeb-hackers/bzr-builddeb/trunk/revision/342 is the fix
[17:35] <james_w> I should do an SRU
[17:36] <mathiaz> james_w: well - this is running in a karmic chroot
[17:36] <james_w> ok, I should upload :-)
[17:41] <sbeattie> slangasek: you have a thinkpad, are you seeing bug 395358?
[17:42] <slangasek> sbeattie: I can confirm that the rfkill interface no longer shows up under /sys/class/net/wlan0/
[17:45] <slangasek> sbeattie: the behavior I see is that it *only* toggles bluetooth
[17:45] <sbeattie> hunh, interesting.
[17:45] <slangasek> pitti: hrm, what's this about dpkg not complaining about conffile conflicts?
[17:46] <pitti> slangasek: dpkg complains about "normal" file conflicts, but not for conffiles, AFAIK; it just re-owns the file
[17:46] <pitti> slangasek: if you have some doubts, I'm happy to test that again
[17:46] <slangasek> pitti: that would be a bug, surely; I've never noticed this behavior, though, can you point to an example?
[17:49] <lfaraone> james_w: heh, I'm still looking for a sponsor of that PPP-pam package if you happen to know anyone, btw.
[17:49] <james_w> lfaraone: in Debian?
[17:50] <lfaraone> james_w: at this point I'd settle for either, but Debian is preferable.
[17:50] <james_w> 'fraid not
[17:51] <james_w> you can obviously put it up on REVU and keep posting to debian-mentors@
[17:51] <pitti> slangasek: nice, dpkg properly fails now; thanks for checking
[17:52] <pitti> kirkland: ^ ignore me then, conffiles do generate conflicts
[17:52] <slangasek> pitti: ok, phew :)
[17:52] <pitti> I was pretty surprised when I tested that in the past
[17:52] <cjwatson> ScottK: kubuntu-netbook live images fail to build, but that's upstart (i.e. not your problem) and should get resolved fairly soon
[17:53] <ScottK> cjwatson: That's actually great news.
[17:53] <cjwatson> ScottK: I bodged together some extra cdimage changes to cope with different seed locations and such
[17:53] <ScottK> cjwatson: Thanks for looking into it.
[17:53] <cjwatson> ScottK: if you ever want non-live images, those will likely require additional bodging
[17:54] <cjwatson> ScottK: do you want to be auto-mailed about kubuntu-netbook build failures? it probably won't be terribly useful until the live filesystems start building, as we don't have a system for mail notifications of failures there yet (unfortunately)
[17:54] <ScottK> cjwatson: OK.  We'll cross that bridge when I think we have enough people that would test it.  Thanks.
[17:54] <cjwatson> if so, let me know what address(es) to use
[17:55] <ScottK> cjwatson: Probably a good idea.  Please use ubuntu at kitterman dot com.
[17:55] <cjwatson> ok
[17:55] <ScottK> Thanks.
[17:56] <cjwatson> you may get a bit of junk towards the start ...
[17:56] <cjwatson> hopefully not too much
[17:57] <cjwatson> let me know if you need it turned off again :)
[18:00] <cjwatson> Keybuk: are you fixing apparmor, or is somebody else?
[18:01] <cjwatson> oh, heh, Kees already did
[18:01] <jdstrand> cjwatson: kees has committed it to the bzr tree and I believe will upload soon if he hasn't already
[18:01] <cjwatson> he has
[18:02] <cjwatson> YKYBHOUTLW you can type bugs.launchpad.net/ubuntu/+source/util-linux/+bugs?orderby=-datecreated without pausing for breath
[18:02] <jdstrand> excellent :)
[18:04]  * lool has a blpus => https://bugs.launchpad.net/ubuntu/+source/%s keyword
[18:09] <maxb> Hmm... should the new upstart also Conflict+Replace upstart-logd ?
[18:09] <cjwatson> lool: oh, I have keywords too, but in this case firefox was being slow and I just gave it to w3m
[18:09] <ogra> lool, blpus ?
[18:10] <cjwatson> maxb: I suspect it may not actually include equivalent functionality; I don't think logd's properly implemented
[18:10] <lool> ogra: bugs.launchpad.net/ubuntu/+source => blpus
[18:10] <jdstrand> cjwatson: btw, mass-sync.py worked very well for me
[18:10] <ogra> lool, lol
[18:10] <lool> You can easily guess what bgo, lpus, or bfo are for
[18:11] <dupondje> somebody knows how to debug gvfs ?
[18:11] <dupondje> cause copying files seems broken
[18:11] <dupondje> on Karmic
[18:11] <cjwatson> jdstrand: oh good
[18:15] <cody-somerville> directhex, Do you happen to know the cause of "ERROR:mini-amd64.c:199:amd64_patch: assertion failed: (amd64_is_imm32 (disp))"? It occurs on amd64 but not i386.
[18:19] <kees> cjwatson: actually Keybuk did, then I fixed it harder.
[18:19] <kees> cjwatson: and it's been uploaded
[18:19] <cjwatson> yeah, the livefs build I was attempting just predated binaries being published
[18:20]  * kees nods
[18:20] <maxb> cody-somerville: Is that in Xen, perchance?
[18:22] <geser> does somebody know if apparmor is supposed to work on karmic amd64? because for me the init script exists with a failure
[18:23] <jdstrand> geser: open bug-- it is going to be fixed super soon now
[18:23] <cody-somerville> maxb, aye
[18:23] <jdstrand> geser: bug #375422
[18:23] <maxb> cody-somerville: something to do with LP 237724 possibly then
[18:23] <geser> jdstrand: does apparmor need a kernel module? because it seems to be missing for me
[18:24] <jdstrand> geser: yes it needs kernel support (and LSM)
[18:24] <jdstrand> geser: the forward porting is almost done and it is being tested
[18:24] <cody-somerville> maxb, looks promising. Thanks! :)
[18:24] <geser> jdstrand: thanks
[18:24] <dupondje> https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/393012
[18:24] <dupondje> gvfs broken on samba it seems :s
[18:25] <dupondje> anyone can confirm ?
[18:31] <cody-somerville> Is anyone familiar with gconftool-2? I'm wondering what possibilities there are to speed up 'gconftool-2 --makefile-install-rule <schema files>'
[18:46] <mathiaz> jdstrand: is ApparmorProfileMigration still needed?
[18:46] <mathiaz> jdstrand: ie can I drop changes related to ApparmorProfileMigration from karmic packages?
[18:57] <ScottK> pitti: Yesterday I did a fresh Karmic install (Kubuntu) on a Dell Mini 10v which needs bcmwl-kernel-source to make wireless work.  Is Jockey supposed to automatically work that out for the user (this is the first time I've needed non-free wifi since Edgy)?
[18:59] <superm1> ScottK, jockey is supposed to depend upon bcmwl-modaliases
[18:59] <superm1> so depends on how recent of an image you were using
[18:59] <ScottK> superm1: That was installed.
[18:59] <ScottK> It was yesterday's live snapshot
[18:59] <superm1> then it should be offering broadcom to you in jockey
[19:00] <ScottK> It didn't.
[19:00] <ScottK> When I ran jockey manually it just said I had no proprietary drivers installed.
[19:00] <superm1> did you have an up to date apt cache?
[19:00] <ScottK> I'm not sure.
[19:01] <superm1> jockey won't offer it unless it knows about the package from your apt cache
[19:01] <ScottK> OK.  I'll see that next time I do an install.
[19:01] <superm1> and i dont believe kubuntu cds offer it in their pool, so it wouldnt be in the default apt cache from the CD
[19:01] <ScottK> Ah.
[19:02] <ScottK> So I need to add that ....
[19:02] <superm1> if you want it to be able to install it without needing internet access, you'll want it in the seed at least
[19:02] <ScottK> Yes.
[19:02] <pitti> ScottK: it's supposed to work; testing appreciated
[19:02] <ScottK> pitti: OK.  Well I think superm1 just pointed out the problem (no package on the CD to offer).
[19:03] <pitti> ah, right
[19:03]  * ScottK will fix and then try again.
[19:03] <pitti> before they were in l-r-m
[19:03] <pitti> so I guess it's fair to include it
[19:03] <ScottK> I think it clearly falls into the catagory of make common hardware work.
[19:04] <superm1> its on the ubuntu cd and ubuntu dvd's pool already, just kubuntu and others don't have it
[19:04] <ScottK> superm1: OK.  Which seed is it in?
[19:04] <superm1> ubuntu.karmic
[19:05] <superm1> pitti, reminds me, were you intending to upload jockey again before a3?  was hoping jockey-text would be available in a3
[19:05] <pitti> superm1: yes, will do
[19:05] <superm1> thanks
[19:05] <pitti> superm1: I still want to fix that rmmod/modprobing
[19:06] <superm1> ah yeah, almost forgot about that too.
[19:07] <jdstrand> mathiaz: yes, why would you want to drop it?
[19:07] <ScottK> Found it.  ship-lave
[19:07] <ScottK> live even
[19:07] <mathiaz> jdstrand: I'm looking at mysql-5.0 merge from debian
[19:08] <mathiaz> jdstrand: and it seems that the code taking care of putting the profile in complain mode will never be run in karmic
[19:08] <mathiaz> jdstrand: I'm looking at the mysql-server-5.0.prerm script
[19:09] <ScottK> pitti and superm1: Seeded now.  Thanks.
[19:10] <jdstrand> mathiaz: prerm?
[19:10] <mathiaz> jdstrand: hm - debian/mysql-server-5.0.preinst rather
[19:26] <ScottK> cody-somerville: You might want review the discussion between superm1 and myself above and consider seeding bcmwl-kernel-source for Xubuntu.
[19:26] <jdstrand> mathiaz: sorry, someone came to the door
[19:29] <mbiebl> chrisccoulson: did you actually succeed in running a recent 0.7?
[19:29] <mbiebl> I tried a couple days ago, and the tracker-miner process immediately segfaulted
[19:30] <ion> “Software you want, as long as you want shoddy packaging and no security updates”
[19:30] <mathiaz> jdstrand: np - another related question is whether the force-complain directory is still needed
[19:34] <jdstrand> mathiaz: seems that steps 2, 3 and 5 can be skipped
[19:34] <jdstrand> mathiaz: notice step 4 has changed, and since you are doing the merge, it would be great if you could update the package during the merege
[19:35] <jdstrand> (I plan to update all the packages to use the new reload during this cycle)
[19:37] <mathiaz> jdstrand: ok
[19:37] <ScottK> jdstrand: I'm probably doing a clamav upload this weekend, so if you can provide a diff, I can include it.
[19:37] <jdstrand> ScottK: sure, thanks
[20:16] <c_korn> is firefox 3.5 in jaunty a beta or the final release? http://packages.ubuntu.com/jaunty/firefox-3.5
[20:17] <c_korn> the file list suggests that it is the beta 4. http://packages.ubuntu.com/jaunty/amd64/firefox-3.5/filelist
[20:21] <jpds> Anyone know why apparmor is broken in Karmic?
[20:21] <Pici> c_korn: Its the final.
[20:21] <c_korn> Pici: ok, thanks.
[20:21] <jdstrand> jpds: bug #375422
[20:23] <jjohansen> jpds: because it has been waiting on a rewritten apparmor
[20:23] <jpds> jdstrand: Thanks, subscribed
[20:24] <jjohansen> the new apparmor will be in alpha3 but I am not sure if it will be turned on by default
[20:26] <jpds> jjohansen: Considering the related blueprints, I hope so.
[20:27] <jdstrand> jpds: not to speak for jj, but not turned on by default for Alpha 3, not all of karmic
[20:27] <jpds> jdstrand: Ah, so it will be in final?
[20:28] <jdstrand> jpds: that's the plan
[20:28] <jjohansen> jpds: it could very well be turned on for alpha3, I am just not sure it will be
[20:28] <jpds> Groovy, thanks.
[20:28] <jdstrand> jpds: testing is ongoing and want to make sure the big bugs are shaken out first
[20:28] <jjohansen> jpds: if it isn't on by default adding security=apparmor to the boot line will do it
[20:29]  * jdstrand speaks as if he has participated in that testing :)
[20:29]  * jdstrand will as soon as he has the new kernel ;)
[20:29] <chrisccoulson> mbiebl - hi, sorry i didn't respond. i've only just got back
[20:29] <jjohansen> jdstrand: I can point you at a kernel
[20:29] <chrisccoulson> i'm running 0.7 here, although tracker-miner-fs doesn't crash immediately
[20:29] <chrisccoulson> it does crash eventually though ;)
[20:30] <mbiebl> chrisccoulson: how old?
[20:30] <jdstrand> jjohansen: yeah, I know kees has it going. I likely won'
[20:30] <chrisccoulson> mbiebl - 7-July i think
[20:30] <jdstrand> t be able to do anything with it til next week anyway
[20:30] <jjohansen> jdstrand: okay, np
[20:31] <jdstrand> jjohansen: and excellent work! :)
[20:31] <jjohansen> jdstrand: just don't want to hold you up anymore than I already have
[20:31] <chrisccoulson> sorry, 6-July. a day older ;)
[20:31] <mbiebl> chrisccoulson: no luck for me :-/
[20:31] <chrisccoulson> hmmmm. anyway, i wanted to talk to you about the packaging split if you have some time
[20:31] <jdstrand> jjohansen: no complaints here. I know it was a lot of work and am really looking forward to it
[20:32] <mbiebl> chrisccoulson: do you plan any changes?
[20:32] <chrisccoulson> now it's possible to have tracker-store independently of any indexing, i think that tracker-miner-fs should split off in to it's own package
[20:32] <jdstrand> jjohansen: I've been doing my AA profiling work on jaunty in the meantime, so I am not blocked
[20:33] <mbiebl> chrisccoulson: is there already an application out there, which only uses tracker-store?
[20:33] <mbiebl> I'd do it on a as-needed basis
[20:33] <chrisccoulson> mbiebl - not sure yet, but the idea is that people can write applications that store data in tracker-store
[20:34] <chrisccoulson> so it would be nice to let people have the metadata store without the indexing
[20:34] <mbiebl> sure. but as long as there aren't such applications yet
[20:34] <mbiebl> ...
[20:34] <chrisccoulson> yeah, i suppose. i just wanted to get your thoughts on it;)
[20:35] <mbiebl> I agree that it makes sense mid to long term
[20:35] <mbiebl> I just don't see the need yet
[20:35] <chrisccoulson> yeah, no problem
[20:37] <mbiebl> let's see how things evolve
[20:37] <mbiebl> and give it some time to stabilize
[20:38] <chrisccoulson> mbiebl - you can check out the packaging in my PPA - https://edge.launchpad.net/~chrisccoulson/+archive/tracker
[20:38] <chrisccoulson> that contains a split, although it's not 100% ideal
[20:39] <mbiebl> thanks, bookmarked
[20:39] <chrisccoulson> it still installs the push modules in the same package as tracker-store
[20:39] <chrisccoulson> mbiebl - what version of evolution do you have in debian now?
[20:40] <mbiebl> 2.26.2-2
[20:40] <chrisccoulson> cool, so you can enable them too. the evo module is actually working quite well
[20:40] <mbiebl> you mean for 0.6.95?
[20:40] <chrisccoulson> the tracker search tool isn't working yet, but you can inspect the store with tracker-explorer, and i can see my email data in the store now
[20:40] <chrisccoulson> no, only in 0.7
[20:41] <chrisccoulson> the push modules don't work at all in 0.6.95
[20:42] <chrisccoulson> i'm going to try and start giving 0.7 some extensive testing this week though, to hopefully find some bugs and help speed up the 0.7 release;)
[20:42] <mbiebl> chrisccoulson: are you still planing to go for 0.7 in karmic?
[20:42] <chrisccoulson> the crash you experience is interesting though. can you see it crashing on any particular file or not?
[20:42] <chrisccoulson> i was hoping for 0.7 in karmic, but i'm not sure yet
[20:43] <chrisccoulson> it depends how long it takes for the search tool to be re-written
[20:43] <chrisccoulson> there's not much point in uploading it until that works, otherwise users will just report lots of bugs for functionality that is known to not work yet
[20:44] <mbiebl> chrisccoulson: bt: http://paste.debian.net/41565/
[20:45] <ion> I fail at finding what’s new with Tracker 0.7.
[20:46] <chrisccoulson> mbiebl - i havent seen that one before
[20:46] <chrisccoulson> ion - what do you mean?
[20:47] <ion> I was trying to learn the major changes from 0.6 to 0.7, but didn’t find the information by skimming through the project website. http://live.gnome.org/Tracker/Roadmap wasn’t helpful either.
[20:48] <chrisccoulson> hmmm, yeah, it's not easy to see whats new from the roadmap. you should have a look at the changelog in git though ;)
[20:48] <chrisccoulson> there are major architectural changes.
[20:49] <chrisccoulson> filesystem indexing has been split off in to a stand-alone entity now, meaning it is possible to remove filesystem indexing functionality and use tracker as a generic RDF metadata store
[20:49] <ion> Neat
[20:49] <chrisccoulson> which you can store anything in really;)
[20:49] <ion> Yeah
[20:49] <chrisccoulson> it also makes it very easy to write your own data providers to push data in to the store
[20:50] <chrisccoulson> eg, the new evolution module is a plugin inside of the evolution process which goes through your emails and sends the data to the tracker store
[20:50] <ion> Alright
[20:50] <chrisccoulson> also, QDBM has gone completely now, which should close a lot of old bugs
[20:51] <chrisccoulson> such as index corruption and the inability to search for incomplete words
[20:51] <chrisccoulson> 0.6.9x has been a nightmare in ubuntu;)
[20:55] <mbiebl> pvanhof has some nice posts on his blog
[20:55] <mbiebl> like eg. http://pvanhoof.be/blog/index.php/2009/07/02/tracker-experimental-merged-to-main-development-tree-ivans-presentation
[21:22] <mathiaz> kees: hm - my sbuild karmic schroot are broken
[21:22] <mathiaz> kees: same error like yesterday: http://paste.ubuntu.com/215063/
[21:22] <mathiaz> kees: are you karmic sbuild schroot working?
[21:23] <mathiaz> kees: are *your* karmic sbuild schroots working?
[21:23] <mathiaz> kees: this time I've tried to build a package that has already been published in the archive
[21:24] <mathiaz> kees: and not used a local source build package
[21:24] <jdstrand> ScottK: debdiff added to bug #397988
[21:25] <ScottK> jdstrand: Thanks.  This can just go in Karmic, right?
[21:27] <jdstrand> ScottK: yeah, I'd upload it, but thought you had more to do
[21:27] <jdstrand> ScottK: no reason to backport it
[21:27] <ScottK> jdstrand: Does it hurt if I do?
[21:27] <jdstrand> ScottK: no
[21:28] <jdstrand> ScottK: but it is more of an optimization than a problem
[21:28] <ScottK> I've got one more set of updates for 0.95.2 in Karmic before I think it's mature enough for jaunty-proposed.
[21:28] <jdstrand> ScottK: it'll becoming increasingly important to not reload all of AppArmor as more and more profiles are added
[21:28] <ScottK> I may not get away with it, but I'd like to keep the packaging as much the same as possible.
[21:28] <jdstrand> *shrug*
[21:28] <jdstrand> doesn't bother me any :)
[21:29] <ScottK> Right.  It's not you I'm worried about.
[21:29] <jdstrand> heh
[21:35] <kees> mathiaz: let me try, one sec
[21:36] <mathiaz> kees: which version are you running on your build host? jaunty?
[21:36] <chrisccoulson> mbiebl - thanks, that's useful
[21:36] <kees> my host is karmic and I build in schroot/sbuild
[21:37] <mathiaz> kees: right - my host is still hardy
[21:37] <mathiaz> kees: and thus I'm using sbuild from hardy
[21:38] <kees> I can't say I've tested that :)
[21:38] <mathiaz> kees: there was a change in sbuild about not parsing dpkg-source output anymore
[21:38] <mathiaz> kees: it may be related to the issue I'm running into
[21:41] <kees> mathiaz: could very well be.  perhaps upgrade you machine to karmic?  :)
[21:45] <mathiaz> kees: ok - I'm hitting debian bug 471747
[21:51] <kees> mathiaz: yeah, looks like it.  can you move your build system to jaunty at least?
[21:51] <mathiaz> kees: well - I'm gonna try to apply the patch to hardy sbuild
[21:51] <mathiaz> kees: and see if it fixes the issue
[22:14] <ScottK> Updated my mini 10v to the new upstart and it seems to run fine.
[22:24] <superm1> Keybuk, ping.  I'm having a hard time figuring out something going on with a udev rule.  [ACTION=="add", SUBSYSTEM=="bluetooth", RUN+="/usr/sbin/bluetoothd --udev"] is the rule.  it works fine if the device is hotplugged, but not if the system boots up with the device plugged in.  Any ideas?
[22:27] <robbiew> superm1: it's 10:26pm on a Friday night in the UK...so Keybuk may not be around
[22:28] <ion> I’m sure i’ve seen Keybuk online even after midnight (in UK). :-P
[22:28] <robbiew> yep
[22:29] <davmor2> ion: it's only 10:29
[22:29] <ion> That’s what robbiew said.
[22:30] <ion> Anyway, IRC generally works even with huge delays between messages and responses, as long as people don’t have their awaylog functionality crippled... AFAIR Keybuk has, though. :-P
[22:31] <cjwatson> yeah, Keybuk doesn't tend to read IRC scrollback. mail him
[22:32] <robbiew> superm1: ^
[22:34] <ion> One doesn’t even need to read scrollback per se, as long as the client is able to give a short list of highlighted messages since the last time online.
[22:34] <mbiebl> chrisccoulson: tried your packages on karmic
[22:34] <mbiebl> get the same segfault
[22:35] <chrisccoulson> very strange. it might be worth having a chat with martyn then. i'll see if i can reproduce it at some point though
[22:35] <mbiebl> chrisccoulson: do you also see this warning:
[22:35] <mbiebl> (tracker-miner-fs:3536): Tracker-WARNING **: could not create proxy
[22:36] <chrisccoulson> mbiebl - i've just started it back up again, so i'll see if it appears
[22:36] <chrisccoulson> yeah, i see that warning
[22:37] <mbiebl> hm, doesn't /usr/share/dbus-1/services/org.freedesktop.Tracker.Miner.FS.service belong into tracker-miner
[22:37] <chrisccoulson> yeah, it should do
[22:37] <chrisccoulson> i'm trying to figure out where that warning is triggered from
[22:38] <mbiebl> Interesting:  tracker-explorer
[22:38] <mbiebl> tracker-explorer: error while loading shared libraries: libgee.so.0: cannot open shared object file: No such file or directory
[22:38] <chrisccoulson> hmmmm, does it not depend on libgee?
[22:38] <mbiebl> nope, does tracker-explorer miss a {shlibs:Depens}
[22:39] <chrisccoulson> heh
[22:39] <chrisccoulson> it does ;)
[22:39]  * chrisccoulson hides
[22:39] <mbiebl> chrisccoulson: is there a bzr branch where I can see the packaging files?
[22:39] <chrisccoulson> i'll sort that out
[22:40] <chrisccoulson> i havent put the packaging in bzr yet. i can do that though
[22:40] <chrisccoulson> i might not be able to do it tonight though
[22:40] <mbiebl> oh, no hurry
[22:42] <mbiebl> chrisccoulson: looks like a c&c error
[22:43] <mbiebl> both tracker-mine-fs and tracker-explorer have python:Depends
[22:43] <mbiebl> instead of shlibs:Depends
[22:44] <chrisccoulson> yeah, that sounds right. i'll fix that in a minute
[22:44] <chrisccoulson> that warning looks bogus by the way
[22:45] <chrisccoulson> if (!proxy)
[22:45] <chrisccoulson> g_warning ("could not create proxy");
[22:45] <chrisccoulson> but nothing sets up proxy
[22:45] <chrisccoulson> at least i can't see where that happens
[22:45] <chrisccoulson> in libtracker/tracker.c
[22:45] <mbiebl> we should also prod upstream about moving libtracker-module and libtracker-common to /usr/lib
[22:45] <mbiebl> if they want to see it used by 3rd party apps
[22:46] <chrisccoulson> yeah, i agree. not sure what the plan is for those
[22:59] <chrisccoulson> mbiebl - i've uploaded a fixed version now
[23:19] <chrisccoulson> fta - i'm not sure what is causing the status icon in xchat to disappear
[23:20] <chrisccoulson> i tried running the jaunty version on karmic and it does the same
[23:20] <chrisccoulson> i tried running it with the jaunty version of gtk on karmic, and it still does the same
[23:20] <chrisccoulson> :-/
[23:23] <jdstrand> didrocks: fyi-- committed bash completion to ufw
[23:23] <jdstrand> didrocks: I made it so I didn't need to change ufw code though-- ie I update /etc/bash_completion.d/ufw to parse 'ufw --help'
[23:24] <jdstrand> didrocks: it'll be in the next upload to Debian
[23:24] <jdstrand> didrocks: thanks for you work on it :)
[23:26] <maxb> xchat status icon? Seems happily there in Karmic for me
[23:30] <pochu> maxb: when started automatically by gnome-session
[23:31] <maxb> ah, right. No, I'm not doing that