[00:05] <doko_> micahg: icedtea-plugin available in the openjdk ppa
[00:06] <micahg> doko_: cool, I'm still on maverick though, I was just wondering so I know what to do with bugs
[00:07] <micahg> doko_: will that be in Debian as well eventually?
[01:53] <ScottK> lifeless: I didn't say it was a good Zope answer, just the one we have.
[01:54] <lifeless> ScottK: ;)
[02:05] <TheMuso> Yay, tdb breakage...
[02:16] <psusi> tdb?
[02:26] <TheMuso> trivial database, used by samba, as well as a few other packages in Ubuntu, of which I maintain 2. I suspect its a gcc 4.5 related problem, just trying to confirm that first.
[02:28] <ajmitch> TheMuso: what sort of breakage are you seeing?
[02:29]  * TheMuso fetches a sample from a build log to pastebin.
[02:31] <TheMuso> ajmitch: http://paste.ubuntu.com/517147/
[02:34] <TheMuso> Ok, I am pretty sure its not gcc 4.5 specific.
[02:34] <ajmitch> is it not including the #define for _PUBLIC_?
[02:34] <TheMuso> I just built natty's version of tdb in maverick, and attempd to build pulse against it, and it failed in the same way.
[02:35] <TheMuso> Haven't looked closely yet.
[02:35] <TheMuso> I'm also getting the same failure with libcanberar.
[02:35] <TheMuso> libcanberra even
[02:35] <ajmitch> looking at the tdb source, _PUBLIC_ is defined in lib/replace/replace.h, if that's relevant
[02:36] <TheMuso> Ok thanks.
[02:36]  * TheMuso will dig some more...
[02:56] <ScottK> ajmitch: Thanks for being TIL boost.
[02:57] <lifeless> lol
[03:00] <ajmitch> ScottK: of course I remembered that I forgot to reference the bug in the changelog about 20 seconds after uploading
[03:00] <ScottK> Detail.
[03:00] <ajmitch> so I get to complain about security uploads DoSsing the buildds until boost gets built :)
[03:02] <ScottK> It build on i386, so I can test build anyway.
[03:02] <TheMuso> ajmitch: Yeah _PUBLIC_ is not being defined anywhere in tdb.h, and it doesn't reference any other headers to get it.
[03:02] <TheMuso> So, gotta sort that out.
[03:03] <ajmitch> TheMuso: ping jelmer about it, he ought to know if tdb needs fixing
[03:03] <TheMuso> ajmitch: Yeah, thats what I was thinking.
[03:04] <TheMuso> Better yet, I'll file a bug in Debian.
[03:09] <ScottK> Numpy is still going to screw with me I see.
[03:10] <ajmitch> I'd expect that
[03:14] <ScottK> It needs to be rebuilt for Python2.7 and it can't build right now because the new version build-deps on matplotlib which build-deps on wx2.8 and no suprise, that's not in Main.
[03:14]  * ScottK shakes his fist at barry for not getting the transition done already.
[03:14] <ajmitch> and noone really wants to support wxwidgets in main?
[03:15] <ScottK> Open question.
[03:15] <ScottK> matplotlib is a pretty sane piece of software.
[03:15] <ajmitch> wx is a bit involved to check over
[03:15] <ScottK> So we might bring it in and split it or split numpy.
[03:15] <ScottK> Yep.
[03:15] <ScottK> Or they might hoover the whole thing up.  Not sure.
[03:18] <ScottK> Somehow my pbuilder update got a mix of ubuntu1 and ubuntu2 boost1.42.  The -dev are all ubuntu1 and the main ones are ubuntu2.  very odd.
[03:18] <ScottK> Since it's i386, I'm not sure how that happens.
[03:19] <ajmitch> that is just a bit strange
[03:19] <ajmitch> & worrying
[03:19] <ScottK> Yep.
[03:19] <ScottK> Maybe wgrant knows.
[03:20] <ScottK> (he seems to have insight into all the hidden warts in soyuz.
[03:20] <ScottK> )
[03:21] <ajmitch> especially as https://edge.launchpad.net/ubuntu/+source/boost1.42/1.42.0-4ubuntu2/+build/2011663 lists a whole lot of -dev packages for i386
[03:22] <ScottK> I'm sure it's some weird archive skew thing that I didn't think was possible.
[03:23] <ScottK> It shouldn't matter though.
[03:23] <wgrant> What's borked?
[03:23] <ScottK> (in this case)
[03:24] <ScottK> wgrant: How'd I get that: http://paste.ubuntu.com/517164/
[03:24] <ScottK> (it's all i386, so no architecture skew)
[03:25] <wgrant> ScottK: boost-defaults or something looks out of date.
[03:25] <wgrant> The unversioned -dev packages aren't in that build.
[03:25] <ScottK> Ah.
[03:25] <ScottK> Right.
[03:25] <ScottK> Thanks.
[03:25]  * ScottK slaps forehead.
[03:25] <ajmitch> heh
[03:25] <wgrant> Soyuz isn't broken again :D
[03:25] <ScottK> That's fine.
[03:25] <ScottK> wgrant: Soyuz isn't broken in that way.  I'm sure it's got something else to make up for it.
[03:26] <wgrant> Indeed, indeed.
[03:26] <wgrant> But it's not really my problem for a few weeks yet, so it can be broken now if it wants to be.
[03:26] <ajmitch> until then, we pin the blame on someone else?
[03:27] <wgrant> Please.
[03:27] <ajmitch> I'm sure StevenK won't mind then
[03:42] <ScottK> Only numpy stands in my way now.
[03:43] <wgrant> Of what?
[03:46] <ScottK> Being able to request removal of boost1.40.
[03:46] <wgrant> Ah, excellent.
[03:46] <ajmitch> it'd be nice to have only one version
[03:47] <ajmitch> thanks to your source double-up for MPI
[03:47] <ScottK> I'm thinking I'll drop the numpy docs for now and assign barry a bug to figure out how to get them back.
[03:48] <ajmitch> is it just the docs causing the build failure, due to main/universe?
[03:49] <ScottK> Yes.  matplotlib is just needed to build the docs.
[03:49] <cr3> what might be wrong with having DH_ALWAYS_EXCLUDE in the debian/rules file? seems like calling debuild with -e explicitly seems to be the preferred approach
[07:37] <danners> hi i try to integrate ubuntu 10.04 with active directory i use likewise which works fine. on login the users have do type domain\username which sucks for not computersavy users. so i got a patch which is included by suse and applied it by hand. now when i compile it it says: http://paste.ubuntu.com/517249/ can someone tell me what this kind of error means?
[07:49] <pitti> Good morning
[07:49] <pitti> SpamapS: hah, awesome!
[07:50] <pitti> kirkland: can't move yet, needs testing
[07:52] <tjaalton> danners: uhm, likewise should have a config option to use the default domain (just like "winbind use default domain = yes" in samba)
[07:54] <tjaalton> danners: ah, seems it's only in the enterprise version.. sucks http://www.likewise.com/resources/documentation_library/manuals/open/likewise-open-guide.html#SetDefaultDomain
[07:59] <danners> tjaalton: yeah that would have been perfect...
[08:05] <dholbach> Good morning! :)
[08:07] <ion> that.
[08:08] <ajmitch> morning dholbach
[08:09] <dholbach> hey ajmitch
[08:10] <nigelb> morning ajmitch
[08:12] <ajmitch> nigelb: it must just about be time for another behindthecircle interview to be released? :)
[08:17] <nigelb> ajmitch: lucidfox and I are just swamped.
[08:18]  * nigelb could only grab 3 hours of sleep last night :/
[08:18] <ajmitch> fair enough
[08:36] <dholbach> can somebody approve my mail to u-d-a?
[08:40] <pitti> dholbach: looking
[08:40]  * dholbach hugs pitti
[08:40] <pitti> dholbach: the "Be young when making love", right?
[08:40]  * pitti hugs dholbach
[08:41] <pitti> dholbach: done
[08:41] <micahg> cjwatson: if you get a chance, can you please approve my mail to devel-permissions
[08:42] <dholbach> pitti, yes that one and the one about the 4th annual business jets conference please
[08:43] <pitti> I had expected that one to come from Mark
[08:43] <pitti> or did you get one as well by now?
[09:04] <pitti> dholbach: just played around with new harvest, nice!
[09:05] <dholbach> pitti, as I said in the mail: we might have to fix some of the "data feeds" and add new ones, but it should be good and easier to maintain now :)
[09:10] <geser> dholbach: is there a way to filter on sponsoring for universe/multiverse?
[09:10] <geser> in harvest
[09:10] <dholbach> geser, there's just "unseeded" right now
[09:12] <geser> which also lists packages in main (git-core) :(
[09:12] <dholbach> geser, no, git-core exists in an older release, it's "git" nowadays
[09:13] <geser> dholbach: harvest lists bug 636999 for sponsoring
[09:13] <dholbach> geser, in launchpad it's git-core
[09:13] <dholbach> although it should be git
[09:13] <dholbach> harvest can't find git-core in any packageset
[09:14] <dholbach> that's why it gets on the unseeded list
[09:14] <geser> ah right, it was in main (till lucid)
[09:14] <dholbach> yeah, it was renamed
[09:15] <geser> but it's still confuses me on the sponsoring page too
[09:16] <dholbach> ok, changed source package name
[09:16] <dholbach> in the bug report
[09:17] <geser> dholbach: do have an idea why bug 635406 is still listed in the FTBFS category?
[09:20] <dholbach> geser, no, I don't - that's weird
[09:21] <dholbach> geser, ok found the bug
[09:22] <geser> dholbach: what data format does harvest need? there is http://qa.ubuntuwire.com/ftbfs/natty.csv if harvest can use it (it can be changed if harvest need an other data format)
[09:22] <dholbach> geser, it needs to be a tiny little bit different
[09:22] <dholbach> just like http://reports.qa.ubuntu.com/reports/launchpad-database/ftbfs.csv
[09:22] <dholbach> http://bazaar.launchpad.net/~harvest-dev/harvest/trunk/annotate/head:/HACKING
[09:23] <geser> ok, will look at it and update the FTBFS data file
[09:24] <dholbach> geser, bug 664356
[09:24] <dholbach> I'll mark it as Critical
[09:32] <geser> could a core-dev please give-back https://edge.launchpad.net/ubuntu/+source/pciutils/1:3.1.7-4ubuntu3/+build/2011386 so we get fresh logs (a bug in LP caused it). Thanks
[09:32] <ajmitch> ok
[09:33] <dholbach> geser, done
[09:33] <ajmitch> looks like I was too slow
[09:34] <geser> ajmitch: thanks for your try
[09:35] <ajmitch> next time I'll have to setup my irc client to open the LP page & retry it automagically :)
[09:48] <dholbach> geser, I got a fix for it, I'll try to get it reviewed soon
[10:03] <YokoZar> debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable   <-- what causes this error to occur (during --configure of a particular package)?  I suspect the problem is not in the package apport automatically files this against.
[10:15] <StevenK> kirkland: I owe you your choice of beverage for the pointer to the 'alert' command
[10:19] <pitti> cjwatson, slangasek: besides postgresql-common I also uploaded a new udev to lucid-proposed (see bug 653568); I'd appreciate a review
[10:32] <bilalakhtar> bug #585468 has a fix in lucid-proposed for quite a long time, and till now nobody stepped up to test the proposed fix. But today RoAkSoAx checked the fact that the patch that I have applied is the same one that Debian and upstream have used. Can this be counted a a verification-done ?
[10:52] <pitti> bilalakhtar: we still need someone ot actually install that deb and confirm that it's working; it might have been misbuilt due to a race condition or toolchain change, etc.
[10:52] <ogra> pitti, i merged all my alsa-utils changes into one upload now, can you delete everything greater than 1.0.23-2ubuntu3 from proposed ?
[10:52] <bilalakhtar> ok thanks pitti
[10:52] <ogra> i think at least one was accepted
[10:53] <pitti> ogra: there's no alsa-utils in the queue
[10:53] <ogra> pitti, i think you accepted my first upload
[10:53] <pitti> ogra: but 1.0.23-2ubuntu3.2 is in maverick-proposed, so your upload needs to be bigger than that
[10:54] <ogra> hmm, k, i didnt want to have multiple changelog entries for the same bug ... butu if there is no way around
[10:54] <pitti> just add the new stuff and use -v
[10:58] <jibel> bilalakhtar, and this sru needs a specific setup, so even if the deb installs, we can't say if the most basic functionality of the package is working.
[10:58] <bilalakhtar> jibel: yes I know that
[11:04] <ogra> pitti, ok, 3.3 uploaded, please accept it if it appears (additional fixes needed for the bug)
[11:12] <jibel> pitti, I think that you can publish bug 582035 to lucid-updates too. The bugnum is missing from the pending sru list.
[11:23] <pitti> jibel: thanks!
[11:39] <aselims> Hello
[13:08] <kirkland> StevenK: \o/
[13:09] <kirkland> pitti: hmm, okay;  there's another upload queued behind it then
[13:09] <kirkland> StevenK: sure thing, i use it *every* day
[13:40] <hyperair> kirkland: ping
[13:41] <kirkland> hyperair: hi
[13:41] <hyperair> kirkland: is there a reason /var/run/motd needs to be created from scratch every boot?
[13:42] <hyperair> i was inspecting my bootchart, and i noticed that lsb_release takes an incredibly long time to finish
[13:42] <sladen> kirkland: doesn't it have the landscape-pr0n added each time?
[13:42] <kirkland> hyperair: lsb_release is really slow, yes
[13:43] <kirkland> hyperair: what is blocking on /var/run/motd being created
[13:43] <hyperair> kirkland: lsb_release.
[13:43] <kirkland> sladen: only where landscape-client is installed
[13:43] <kirkland> sladen: i mean landscape-sysinfo
[13:43] <hyperair> kirkland: lsb_release is run at boot when motd is being generated.
[13:44] <hyperair> kirkland: can't we cp /etc/motd /var/run/motd?
[13:44] <kirkland> hyperair: and what blocks on lsb_release?
[13:44] <hyperair> kirkland: what do you mean?
[13:44] <kirkland> hyperair: /etc/motd is a symlink to /var/run/motd
[13:44] <micahg> hyperair: how much of lsb_release is needed by motd?
[13:44] <kirkland> hyperair: if it happens in the background at boot, who cares?
[13:45] <kirkland> micahg: lsb_release -r basically
[13:45] <hyperair> kirkland: because it wastes CPU cycles and disk seeks.
[13:45] <hyperair> well of course, disk seeks are factored away with ureadahead, but we still have CPU cycles being wasted there that could go elsewhere.
[13:46] <kirkland> micahg: i lied ... printf "%s\n" "$(lsb_release -s -d)"
[13:46] <micahg> hyperair: kirkland: fta had performance issues with lsb_release and switched to sourcing /etc/lsb-release and that helped tremendously
[13:46] <micahg> the issues were with chromium start time
[13:47] <hyperair> heh that looks pretty awesome.
[13:47]  * micahg doesn't know if that's available at boot time though
[13:47] <kirkland> micahg: that looks reasonable
[13:47] <hyperair> it should be.
[13:48] <kirkland> hyperair: is there a bug number?
[13:48] <hyperair> nope
[13:48] <hyperair> do you want one?
[13:48] <hyperair> i mean should i file one?
[13:49] <kirkland> hyperair: sure
[13:49] <pitti> kirkland: did you ever happen to use kvm with ipv6?
[13:49] <kirkland> hyperair: i'm fixing it now
[13:50] <hyperair> kirkland: thanks.
[13:50] <kirkland> pitti: i don't think so ...
[13:50] <pitti> kirkland: ok, thanks
[13:50]  * hyperair starts looking into postfix taking 5 seconds to start
[13:53] <kirkland> pitti: something particular you're looking for?
[13:54] <pitti> kirkland: I'd like to test IPv6 in a VM
[13:55] <pitti> seems I should try setting up a tap device on my host, attach a DHCP server on it which spits out IPv6 addresses, and then connect to that using -net tap / -net nic
[14:03] <chrisccoulson> kees - do you know if gcc uses the gs segment register on x86 for anything specific?
[14:03] <chrisccoulson> i'm still trying to figure out what it is that actually triggers this bug
[14:04] <Ian_Corne> which kernel will be used in 11.04?
[14:04] <micahg> Ian_Corne: that'll probably be discussed at UDS
[14:05] <Ian_Corne> ok :)
[14:07] <chrisccoulson> oh, i think i found the answer already kees
[14:16] <tkamppeter> pitti, hi
[14:22] <pitti> hello tkamppeter
[14:24] <kirkland> hyperair: bug #?
[14:26] <hyperair> kirkland: i just filed it and assigned you. i think you should have it..
[14:26] <kirkland> hyperair: it's not in my inbox yet.  can you please paste the number here?
[14:27] <hyperair> kirkland: i need to look. damn launchpad doesn't give you feedback when you file the bug over email
[14:28] <hyperair> okay i think the first round didn't register. this one should >_>
[14:30] <kirkland> hyperair: the commit is blocking on getting a bug number from you
[14:36] <tkamppeter> pitti, I have posted a very important SRU, as with Maverick Duplex on HP inkjets does not work with most apps. Packages hplip and system-config-printer, bug 657357, bug 487695, bug 428588.
[14:39] <jml> james_w: why is https://blueprints.edge.launchpad.net/ubuntu/+spec/other-foundations-n-distributed-development-review-and-planning in "Other" and not "Ubuntu the project"?
[14:40] <JontheEchidna> ogra: sorry for stepping on your toes with that bug report. :(
[14:41] <ogra_ac> JontheEchidna, no prob, fix is uploaded now
[14:41] <JontheEchidna> nice
[14:41] <ogra_ac> JontheEchidna, and it was not you who missed the triaging ...
[14:41] <ogra_ac> i guess i'll need to blog about armel triaging practice to make people aware
[14:41] <JontheEchidna> yeah, that'd be great.
[14:42] <ogra_ac> it was just that i already had the bugnumber in the changelog and the package ready
[14:42] <ogra_ac> else i wouldnt have cared which is duplicate and which not
[14:42] <JontheEchidna> totally understandable
[14:43] <JontheEchidna> I try to help out w/ triage in that package when I can, but it still needs a bit of love
[14:43] <ogra_ac> on arm it needs massive love
[14:44] <ogra_ac> that build time neon detection doesnt fly, we will need a proper fix for runtime
[14:44] <ogra_ac> for natty
[14:50] <james_w> jml, no particular reason
[14:59] <zyga> SpamapS, ping
[15:14] <Riddell> ogra: could you renew my membership of canonical-arm-dev?
[15:15] <ogra_ac> Riddell, indeed, with pleasure ;)
[15:15] <ogra_ac> done
[15:17] <Riddell> thanks
[15:17] <cjwatson> ari-tczew: merge-o-matic already has a special blacklist, and it also already reads sync-blacklist.  please file a bug on merge-o-matic if you want it changed - requesting things on IRC isn't scaling well, particularly when I'm away
[15:18] <hyperair> kirkland: i guess you've gotten your bug number/
[15:20] <sladen> hyperair: kirkland: micahg: lsb_release really needs rewriting as a piece of C or Shell, currently IIRC it pulls in a mass of Python
[15:20] <sladen> hyperair: kirkland: micahg: this had a use somewhere else;  it's forcing Python to be installed on basic systems
[15:22] <sladen> hyperair: kirkland: micahg: bug #646795
[15:23] <micahg> sladen: well, it serves multiple functions, maybe it can be split into a shell piece and a python piece
[15:27] <cjwatson> micahg: devel-permissions> done
[15:27] <kirkland> sladen: yeah, i've hated on lsb_release many times before
[15:27] <kirkland> sladen: i like the idea of rewriting it in shell
[15:27] <cjwatson> it should be done upstream, not in Ubuntu ...
[15:28] <cjwatson> I think I said that in the bug already, too
[15:29] <ogra_ac> could some SRU team member let my qt4-x11 upload through, so we have a chance to test it before UDS ?
[15:29] <pitti> kirkland: like, "source /etc/lsb-release"?
[15:30] <kirkland> pitti: yeah, basically
[15:30] <kirkland> pitti: and a case statement to handle to couple of args lsb_release has
[15:30] <pitti> kirkland: I meant, you are certainly not asking for the "user calls it interactively" case
[15:31] <pitti> we recently changed the chromium startup script to try sourcing /etc/lsb-release first, and only call lsb_release if that fails
[15:31] <pitti> bought us more than one second on armel :)
[15:31] <kirkland> pitti: right, i just did the same in /etc/update-motd.d/00-header
[15:32] <kirkland> pitti: and byobu has done that for a while too
[15:32] <pitti> kirkland: right, for those you just source and use $DISTRIB_ID, etc.
[15:32] <kirkland> so maybe we just need to find all the callers of lsb_release and fix them individually
[15:32] <kirkland> alternatively, it would probably be easier to just "fix" lsb_release
[15:32] <pitti> well, only for those where speed matters
[15:32] <micahg> cjwatson: thanks
[15:34] <kirkland> cjwatson: are you comments about upstream related to this lsb-release conversation, or to your conversation with micahg
[15:34] <cjwatson> kirkland: this one, nothing to do with micahg
[15:35] <kirkland> cjwatson: k
[15:35] <cjwatson> (I thought it relatively obvious that complete reimplementations ought to be discussed upstream, but maybe I'm alone on this)
[15:36] <cjwatson> /etc/lsb-release is an internal implementation detail of the lsb_release interface, even though it's pretty well entrenched in Ubuntu
[15:38] <sladen> yup, which is why ideally it should be fixed in the executable call (/usr/bin/lsb_release is /the/ interface), whilst the presence of the file is a non-portable psuedo-standard
[15:38] <pitti> hm, did anyone play with connecting two kvm instances through a vlan? I have tried to do that for half an hour now, and I can't get them to talk to each other
[15:39] <pitti> I tried with -net user; do I need -net tap for this and create a tap device on the host?
[15:41] <cjwatson> tseliot: sorry, don't know about your quilt problem.  plymouth isn't packaged the way I usually use quilt, so I find it hard to follow myself sometimes
[15:41] <cjwatson> (I normally use separated patches for 3.0 (quilt) packages)
[15:42] <tseliot> cjwatson: no problem, in the end I figured out how quilt is meant to be used ;)
[15:42] <kirkland> pitti: i typically do it through a bridge
[15:43] <cjwatson> merging that one with Debian is going to be interesting
[15:43] <kirkland> pitti: the easiest way is to fire up virt-manager
[15:43] <kirkland> pitti: otherwise, i can dig up some helper scripts for you
[15:43] <pitti> kirkland: ah, ok; I'll try virt-manager then
[15:44] <kirkland> pitti: with that, all your vms should be on 192.168.122.*
[15:44] <kirkland> pitti: and be able to talk to one another
[15:47] <pitti> kirkland: v-m has two networks "default" and "specify shared device name" -- that again asks me for a "bridge name"; so it seems I still need to create something locally then?
[15:48] <pitti> on the default I'd get DHCP and everything, but I need a separate vlan
[15:48] <kirkland> pitti: oh, the vlan is required?
[15:49] <pitti> kirkland: one kvm should have "default" (eth0 with dhcp) and eth1 on a separate vlan, and another VM shuold have a single eth0 on the same vlan
[15:50] <pitti> hm, maybe one vlan is enough, let's see
[15:50] <pitti> kirkland: http://paste.ubuntu.com/517489/ was my first naive approach for taht
[15:51] <pitti> kirkland: but the vlan1 of both instances aren't connected apparently
[15:52] <kirkland> pitti: right, i think you'd a bridge for that vlan
[15:52] <kirkland> pitti: let me see if i have something
[15:52] <kirkland> pitti: http://paste.ubuntu.com/517495/
[15:53] <kirkland> pitti: # To use, append the following on your qemu or kvm command line:
[15:53] <kirkland> #   -net nic,model=virtio -net tap,script=/usr/sbin/qemu-bridge
[15:53] <kirkland> # and make sure that uml-utilities exists (to create /dev/net/tun)
[15:53] <kirkland> pitti: and i think you might have to use sudo kvm
[15:55] <pitti> kirkland: ah, thank you
[16:09] <kirkland> pitti: let me know if you're still struggling
[16:10] <pitti> kirkland: with virt-manager it actually works
[16:10] <kirkland> pitti: well there you go :-)
[16:10] <pitti> that looks quite nice these days; it's been a while since I used it
[16:10] <kirkland> pitti: yeah, it sucks far less than it use to :-)
[16:10] <kirkland> pitti: i actually use it, any time i need two vm's to talk to one another
[16:13] <ttx> pitti: when ant was upgraded to 1.8, debian kept an ant1.7 source package for compatibility with things that don't like 1.8... It's in universe right now, but is required to build tomcat6 (main). Do you need a MIR for it ? It's the same as the old ant_1.7, which was in main.
[16:13]  * pitti throws hands into the air for even more java duplication
[16:13] <pitti> ttx: anyway, I'm not in ~ubuntu-mir any more; we at least need a bug for tracking it, though
[16:14] <ttx> pitti: we have a spec about that at UDS, feel free to join the therapy group
[16:14] <ttx> "Java libraries housekeeping"
[16:14] <pitti> ttx: but that sounds like an easy one indeed
[16:14] <pitti> ttx: oh, good luck on that one!
[16:14] <kirkland> pitti: btw ...  this doesn't solve your current problem, but since you like KVM hacks ...
[16:14] <ttx> pitti: I file bug and subscrive ubuntu-mir ?
[16:14] <kirkland> pitti: hallyn has done a great job putting together https://wiki.ubuntu.com/VirtFeatureVerification
[16:15] <kirkland> pitti: which has short howto's on dozens of obscure kvm  and qemu features
[16:15] <kirkland> pitti: there is a section on bridging in that page at least
[16:15] <smoser> $ dpkg-query --show dmsetup
[16:15] <smoser> dmsetup 2:1.02.39-1ubuntu4.1
[16:16] <smoser> but dmsetup comes from source package lvm2, at version 2.02.54-1ubuntu4.1
[16:16] <smoser> how does that happen ? i'm looking at the control file and dont see anything obvious to me.
[16:17] <pitti> kirkland: ooh, that looks useful, thanks!
[16:18] <kirkland> smoser: line 97
[16:18] <kirkland> smoser: grep -n "Package: dmsetup" debian/control
[16:18] <kirkland> smoser: http://paste.ubuntu.com/517509/
[16:19] <smoser> i'm missing something obviously
[16:19] <smoser> i'm confused on where the version differences come from
[16:19] <kirkland> smoser: do you have the right sources?
[16:19] <smoser> why dmsetup is '2:1.02.39-1ubuntu4.1'
[16:19] <kirkland> smoser: what is this?  lucid?
[16:20] <smoser> yes
[16:21] <smoser> but the debian/changelog shows 2.02.54-1ubuntu4.1
[16:21] <kirkland> smoser: yeah, there's an epoch bump in there;  i'm looking for the source
[16:22] <kirkland> smoser: see debian/*symbols
[16:22] <cjwatson> look at the dpkg-gencontrol calls in debian/rules
[16:23] <cjwatson> and the DEVMAPPER_* stuff at the top
[16:23] <kirkland> ah yes, there it is, in debian/rules
[16:24] <smoser> ok. that makes more sense now.
[16:29] <kirkland> pitti: thank hallyn, he did 99% of the work on that page :-)
[16:30]  * pitti sends hallyn some cookies
[16:31] <smoser> hm.. ok. so, given a package manifest that says 'dmsetup 2:1.02.39-1ubuntu4.1' and one that says '2:1.02.39-1ubuntu4'
[16:32] <smoser> do i have *any* hope of determining which changelog blocks for lvm2 were relavant
[16:34] <smoser> in order to do that, it would seem that i would have to determine that 2:1.02.39-1ubuntu4.1 was built by 2.02.54-1ubuntu4.1 and 2:1.02.39-1ubuntu built by lvm2 at version 2.02.54-1ubuntu4
[16:34] <smoser> is that at all possible or am i SOL .  in this particular case, the archive could possibly help me as both those versions would exist, but its possible that one does not (if it had been replaced in -updates)
[16:44] <SpamapS> zyga: pong, yes?
[16:44] <zyga> SpamapS, hi
[16:44] <zyga> SpamapS, you registered a very interesting blueprint that I want to attend :)
[16:44] <zyga> SpamapS, about command-not-found improvements
[16:45] <zyga> SpamapS, could you tell me briefly what you'd like to see happen?
[16:48] <SpamapS> zyga: With command-not-found, its somebody else's idea, but basically, instead of just doing a string match on the files in packages, have common misunderstandings resolved by offering alternatives that maybe aren't spelled at all the same.
[16:49] <zyga> SpamapS, hmm, could you be more specific? I don't understand you exactly
[16:49] <SpamapS> zyga: the example is to suggest tracepath when somebody types 'traceroute' and its not installed.
[16:49] <zyga> yes, I remember that issue
[16:49] <SpamapS> or you could also suggest 'mtr'
[16:49] <zyga> I worked to resolve it but I did not finish my rewrite
[16:49] <damascene> What do you think of having Ubuntu Fedora testers? many bugs will be discovered there before it land in Ubuntu if there were enough testers.
[16:49] <zyga> so you'd like to see a general suggestion framework?
[16:50] <zyga> damascene, ?
[16:50] <SpamapS> zyga: yes, my hope is we can embed the suggestions somewhere in the packaging information.
[16:50] <SpamapS> zyga: please excuse me, I have to run out and move my car to the other side of the street...
[16:50] <mneptok> damascene: Fedora should be reporting their bugs upstream (and do for GNOME at least) at which point the bug becomes distro-agnostic.
[16:50] <zyga> SpamapS, that would be awesome, it also aligns with other changes linaro would like to do there (delcarative alternatives) but it's an big volume of work in _Debian_
[16:51] <zyga> SpamapS, I'd love to help that to happen
[16:51] <zyga> SpamapS, but we can do something else before such extensive features land
[16:51] <zyga> SpamapS, we might extend the control files with some attidional meta-data that c-n-f could pick up
[16:51] <zyga> SpamapS, did you see how c-n-f data is obtained?
[16:51] <damascene> mneptok: zyga. I think testing fedora could help Ubuntu stability but I think the problem is their lack of tester. you might know better.
[16:52] <damascene> *lack of testers.
[16:52] <zyga> damascene, lack of testers might be translated to lack of automatic tests that make sense - I'd love to see that fixed
[16:52] <zyga> damascene, especially very _high level_ tests
[16:52] <dholbach> geser, so I got the fix reviewed, now I just wait for somebody in IS to deploy it
[16:53]  * mneptok tacklehugs dholbach 
[16:53] <zyga> SpamapS, do you plan on working on that blueprint? (who will be the asignee)
[16:54] <damascene> zyga: I'm a simple user and when I was testing Ubuntu beta, some fedora release user were having the same bug.
[16:54] <dholbach> hey mneptok
[16:56] <SpamapS> zyga: no I haven't dug into the internals of c-n-f yet. I do intend to work on it, or maybe kirkland, I know he's interested in it as well.
[16:56] <azeem> have there been many complaints that the "admin" group is too similar to the "adm" group?
[16:56] <zyga> SpamapS, I'd love to be a part of that as I wrote the program and have a vastly improved version on my disk (based on different architecture and dbus)
[16:57] <damascene> would you like to have the domain upaste.org instead of the paste.ubuntu.com/
[16:58] <damascene> I find it is easier to use fpaste for Ubuntu than it's own.
[16:59] <SpamapS> zyga: cool! Will you be in attendance then?
[16:59] <zyga> SpamapS, yes, I subscribed myself as essential
[16:59] <zyga> SpamapS, I'd also like to see some interaction between mvo's software center as the data source seems to be getting similar
[17:00] <zyga> SpamapS, and getting a common API for everything would benefit people using ppa's/other repos (currently there is no way to support this in c-n-f without a dedicated package that the repo contains and someone has to install
[17:00] <SpamapS> zyga: awesome. Make sure to introduce yourself at the beginning so I don't cut you off as a blowhard wannabe when you start schooling all of us on how it works. ;)
[17:00] <zyga> hehe :D
[17:01] <zyga> I'll stay silent and bash you as newbies at the end ;-)
[17:01] <zyga> SpamapS, it's awesome you are working on this, I'd love to see this happen and will definitely help you, see you at the session
[17:04] <kirkland> Spads: what is c-n-f?
[17:04] <zyga> mvo, do you imagine we could work on getting some extra metadata into dpkg this cycle and have a centralized service that would allow you to access that metadata from aptd somehow?
[17:04] <zyga> kirkland, command-not-found
[17:04] <kirkland> ah
[17:04] <SpamapS> kirkland: we were discussing bug 508606 and the blueprint its attached to https://blueprints.launchpad.net/ubuntu/+spec/packageselection-server-n-commandline-userfriendly
[17:05] <SpamapS> kirkland: I seem to recall you had an interest in that bug, though I may be mistaken.
[17:05]  * zyga just needs some motivation to finish his new-and-shiny branch
[17:08] <tkamppeter> pitti, mvo, hi
[17:08] <mvo> zyga: command-not-fond as additional data into the pakcages file? that would be doable
[17:09] <mvo> hey tkamppeter
[17:09] <zyga> mvo, that would be perfect but the point here is to be able to query a single service for it _and_ to make it work with custom repos with new packages
[17:10] <zyga> mvo, it sounds like some extra data that'd need to be visible at apt level _or_ some hook similar to what you do with software center metadata in extra repos (but I don't know how that works)
[17:11] <tkamppeter> mvo, we talked earlier here in the IRC also with pitti about the needed changes in Jockey and for the keys to be shipped with Ubuntu so that manufacturer-supplied printer drivers from OpenPrinting can be autom,atically downloaded. Do you remember?
[17:11] <zyga> mvo, essentially two tasks 1) make each repo  drop a file somewhere  + 2) proposal to have better API for getting that data
[17:11] <jmelis> hi, I have some doubts regarding uploading packages to a PPA. I have created a package and uploaded it successfully to the PPA, but I realised it doesn't have the suffix of ~lucid1 (I need that suffix because the package needs to be recompiled for each Ubuntu version) so I erased it from the PPA. My question is, where do I have to add this suffix ~lucid1? renaming the changes file is enough?
[17:11] <mvo> tkamppeter: vaguely
[17:12] <mvo> zyga: 0) extract the data from the repo on build/publishing time
[17:12] <zyga> mvo, correct
[17:12] <mvo> zyga: there is a long term plan for this, with this step solved I think the rest is trivial
[17:12] <mvo> zyga: it requires soyuz hook in the way I envision it
[17:12] <mvo> zyga: I would love to discuss this at uds
[17:12] <zyga> mvo, and -0.5) decide if this data is declerative or somehow automatically guessed which is a deeper dpkg problem
[17:12] <zyga> mvo, during which session?
[17:13] <mvo> heh :)
[17:13] <zyga> declarative even
[17:13] <tkamppeter> mvo, we did not get this implemented in Maverick, but in Natty we should do it.
[17:14] <mvo> tkamppeter: will you be at uds?
[17:14] <tkamppeter> mvo, should we have a meeting to coordiante this on the UDS? Should it only be  pitti and you or perhaps someone else to participate in the meeting?
[17:15] <tkamppeter> mvo, I will be on UDS, as always since fall 2006.
[17:16] <kirkland> Spads: thanks, i just subscribed to it
[17:16] <kirkland> SpamapS: ^
[17:16] <kirkland> Spads: gah
[17:17] <mvo> tkamppeter: great, lets schedule a meeting there
[17:18] <SpamapS> tkamppeter: Did you want to add it to the spec about improving the command line experience? Or is this much bigger than that?
[17:18] <mvo> zyga: I think its worthwhile to have a session about this (maybe even informal)
[17:18] <mvo> zyga, tkamppeter: I need to leave for dinner now, sorry
[17:18] <zyga> mvo, shall I schedule it?
[17:18] <SpamapS> kirkland: did you have other stuff you want to throw in there? I always appreciate the compassion for users that your ideas bring. ;)
[17:18] <zyga> mvo, k, see you
[17:19]  * kirkland blushes
[17:19] <kirkland> SpamapS: aw, SpamapS
[17:20] <SpamapS> kirkland: well lord knows somebody has to care about them.. most of us are more the "send them over the hot coals, the ones that come out the other side can keep talking to us" types. ;)
[17:20] <pitti> tkamppeter, mvo: quick meeting is fine for me
[17:21] <tkamppeter> SpamapS, which spec about command line experience? I think it has nothing to do with command line experience. Automatic printer driver download should happen if the user plugs in a printer and system-config-printer does not find a driver for the printer on the local system.
[17:21] <pitti> ogra_ac: qt4-x11> ah, that already hit us in an OEM project; nice catch
[17:21] <SpamapS> tkamppeter: ahh, yeah, thats a bit out of scope.
[17:22] <zyga> tkamppeter, apple did that for snow leopard, since they also use cups maybe we might see some common code that they have
[17:22] <tkamppeter> pitti, who should participate and how should I obtain a slot? "Informal" Blueprint?
[17:22] <pitti> tkamppeter: not sure who planned UDS for desktop this time; we already have a bug report, so a non-blueprint meeting will do
[17:23] <pitti> rickspencer3, seb128: hey, how's the sprint going? wo planned UDS for desktop?
[17:23] <rickspencer3> pitti, uh, no one?
[17:23] <rickspencer3> pitti, are there things missing?
[17:24] <pitti> tkamppeter: Till was asking for a new meeting above
[17:24] <rickspencer3> ah
[17:24] <rickspencer3> well, with the new theme-based tracks, it's a bit more complicated
[17:24] <rickspencer3> pitti, if someone makes a blueprint and pastes me a link, I'll take care of it
[17:24] <tkamppeter> pitti, rickspencer3, I have also scheduled a meeting for something else and had to put it under "Other" because there was no desktop track.
[17:25] <pitti> rickspencer3: we have a bug report for it so far
[17:25] <rickspencer3> ah
[17:25] <ogra_ac> pitti, yeah, hits me hard on the ac100 atm ... :)
[17:25] <rickspencer3> well, without a blueprint, it'll be hard to schedule, with a blueprint it will be easy to schedule ;)
[17:25] <ogra_ac> (tegar2 , no neon... just got sound working ... mumble is Qt :p)
[17:26] <pitti> tkamppeter: ^ seems we do need a BP then :)
[17:26] <ogra_ac> *tegra
[17:27] <tkamppeter> pitti, so I will make one, referring to the bug report, and making you and mvo required participants. Anyone else who should participate?
[17:27] <pitti> tkamppeter: I think the three of us will be fine
[17:27] <tkamppeter> pitti, OK.
[17:28] <seb128> pitti, hey, sprint going well
[17:39] <jml> james_w: I just noticed your bug at https://bugs.edge.launchpad.net/launchpad-code/+bug/603606
[17:40] <jml> james_w: would you have been ok with a fix that addressed all of your concerns but didn't follow the binary build failures as closely?
[17:42] <tkamppeter> pitti, I have forgotten the naming convention for the BP, would should I do? Forget it and start over? Or can one rename it?
[17:46] <tkamppeter> pitti, sorry, I have found the solution.\
[17:53] <tkamppeter> pitti, still there?
[18:11] <james_w> jml, abentley and I discussed that in depth, as he felt that following the binary build failure mails was too constrictive, and that they weren't as useful as they could be. I encouraged him to improve both of them to keep them consistent and have them both be useful. He said that he wasn't happy modifying another team's code, and wanted to just fix that particular email.
[18:12] <jml> james_w: ok, thanks. I'm inclined to agree with you.
[18:12] <smoser> anyone able to confirm this for me ?  i know that binary package previously 'P' existed at version 'V' in one of <suite>, <suite>-updates or <suite>-security.
[18:12] <smoser> there is no guaranteed way to convert that binary package to a source package and version
[18:14] <james_w> jml, as to your original question, the mail were pretty awful, so any improvement would have been good. I was keen to follow the spirit of the other emails, but wouldn't have kicked up a big stink if that wasn't the way that it was going to go. I think it's unfortunate that nobody ended up happy with the eventual fix.
[18:15] <jml> james_w: *nod*
[18:15] <micahg> smoser: you can grab the source from LP
[18:15] <smoser> archive data can only provide me with the most current version in any of those pockets. and since source version != binary version, i'm stuck.
[18:15] <smoser> micahg, but i can't even definitively determine which source to grab
[18:15] <jml> james_w: I'm going through the daily builds stuff now, trying to identify things that need to be done before we consider it to be finished
[18:16] <jml> james_w: most of it is polish on things like this.
[18:16] <micahg> smoser: not sure what you're asking for
[18:16] <tkamppeter> pitti, the CUPS SRU has broken the build servers. see http://launchpadlibrarian.net/57980548/buildlog_ubuntu-maverick-i386.hplip_3.10.6-1ubuntu10.1_FAILEDTOBUILD.txt.gz
[18:16] <james_w> jml, that's good to know
[18:17] <smoser> micahg, i know that at one time, a installed system contained binary package 'P' at version 'V'. and I need to determine what *source* (and version) built that.
[18:18] <micahg> smoser: if you know the version, you can go to LP and grab the source that built it
[18:18] <micahg> smoser: build logs are available as well so you can see what deps were usedc
[18:19] <smoser> micahg, but i dont know the version
[18:19] <smoser> i know the binary version
[18:20] <smoser> assuming i can convert binary package to source package (which assumes that a binary package didn't move source packages) binary version != source version
[18:20] <micahg> smoser: huh? binary should be the same as the source version
[18:20] <smoser> no. i made that assumption.
[18:20] <micahg> smoser: all packages in teh archive are built from a source version and the binary packages inherit that source package version
[18:20] <smoser> current lucid dmsetup is dmsetup 2:1.02.39-1ubuntu4
[18:21] <smoser> which was built by lvm2 version 2.02.54-1ubuntu4
[18:21] <smoser> (read backscroll for others giving me help to that)
[18:22] <micahg> wow, I see that, weird
[18:23] <micahg> smoser: is that the package you're looking for?
[18:23] <smoser> i'm looking to solve the general problem
[18:23] <smoser> i can manually determine it for a given package
[18:25] <micahg> smoser: there might be something in the LP API to help, idk
[18:49] <tkamppeter> Can it be that the buildds for maverick is broken?
[19:16] <barry> ls
[19:33] <nemo> Hey guys. I'm trying to find bugs on Xorg memory usage - is this a known issue in maverick?
[19:33] <nemo> (mine seems to be steadily climbing.  an increase of 50 megs in just the past hour)
[19:51] <_Groo_> hi/2 all
[19:52] <_Groo_>  just a quick notice, alsa-utils (1.0.23-2ubuntu3.3) post install script is broken
[19:58] <didrocks> doko: hey
[19:58] <didrocks> doko: do you know a little about cython?
[20:12] <nemo> And since I asked that question about 40 minutes ago, memory has gone up another 32 megs
[20:12] <nemo> guess I'm going to have to log out and restart X
[20:13] <ogra_ac> crimsun, hmm, what did i mess up ?
[20:13]  * ogra_ac doesnt see the issue 
[20:14] <ogra_ac> oh my !
[20:14] <ogra_ac> pitti, still around ?
[20:15]  * ogra_ac now sees it 
[20:28] <seb128> ScottK, there is no need to play close, reopen with bugs
[20:28] <seb128> it's usually not an useful way to get what you want
[20:30] <nemo> aaand one reboot later.  memory usage is at 132m
[20:45] <cjwatson> smoser: you could iterate through all versions of the source package known to build that binary, and look at which binaries they generate
[20:46] <cjwatson> smoser: (obviously LP should be enhanced to give you a more efficient lookup mechanism, but the information is all available)
[20:46] <smoser> cjwatson, i dont think it is exposed via lp
[20:46] <smoser> just talked some with lifeless and james_w in #launchpad and opened https://answers.launchpad.net/launchpadlib/+question/130600
[20:46] <ogra_ac> cjwatson, could you let alsa-utils_1.0.23-2ubuntu3.4 into proposed ? the alsa guys drown in bugs due to a mistake i made in 3.3
[20:46] <smoser> i was going to attempt what you were proposing
[20:47] <ogra_ac> (pitti seems to not be around and i want to stop the bug flooding asap)
[21:03] <cjwatson> smoser: each source_package_publishing_history object has a getPublishedBinaries method, and the binary_package_publishing_history objects that returns each have binary_package_name and binary_package_version properties.  So you can work it out, it's just slow
[21:04] <smoser> oh.
[21:04] <smoser> i guess i left something out (i think)
[21:04] <smoser> build.current_source_publication_link is empty for anything not in current archive
[21:07] <cjwatson> smoser: you can't go backward from the build, no, I didn't say you could
[21:07] <cjwatson> that was why I was saying that unfortunately AFAIK you have to go forward from every possible source
[21:07] <cjwatson> might want to build a cache :-)
[21:07] <smoser> yeah.
[21:08] <smoser> i guess i'm confused.
[21:08] <smoser> how do i get a list of source_package_publishing_history
[21:13] <cr3> what would be the best practice for packaging web projects which include html and js files? could they go under /usr/lib/python2.6/site-packages... or should they really go under /usr/share/project?
[21:14] <seb128> cr3, hey
[21:14] <cr3> seb128: ahoy, matey!
[21:14] <seb128> cr3, how are you?
[21:15] <cr3> seb128: working hard... you'd think that it might be more relax once releases become stable but it just continues :)
[21:15] <cr3> seb128: and you, looking forward to uds?
[21:16] <seb128> yes
[21:27] <cjwatson> smoser: getPublishedSources() on an archive object (probably lp.distributions['ubuntu'].main_archive)
[21:28] <cjwatson> cr3: non-python files shouldn't go in /usr/lib/python*/, as far as I'm aware
[21:28] <cjwatson> /usr/share/<package> would be better
[21:28] <cr3> cjwatson: what about /usr/share/pyshare, same thing as /usr/lib/python*?
[21:32] <cjwatson> cr3: but they aren't python files, so shouldn't go in python directories
[21:32] <cjwatson> /usr/share/pyshared/ is a directory used by one of the python helpers to organise python files across multiple versions of the interpreter
[21:33] <cr3> cjwatson: understood, I was using launchpadlib as an example which has /usr/share/pyshared/launchpadlib/wadl-to-refhtml.xsl
[21:34] <chrisccoulson> kees - any thoughts on this gcc/FF issue? I'm starting to get really stuck now ;)
[21:35] <kees> chrisccoulson: I haven't had time. we can pick doko's brain at UDS, though
[21:35] <chrisccoulson> kees - sure, that's ok
[21:35] <chrisccoulson> thanks
[21:36] <kees> chrisccoulson: sure thing. :)
[21:45] <smoser> cjwatson, it appears you are correct.
[21:50] <cjwatson> cr3: hm!  well, evidently there is prior art; all I can say is that I certainly wouldn't have done it that way
[22:27] <doko> chrisccoulson, kees: yes, please lets delay until next week
[22:27] <chrisccoulson> doko - thanks
[22:28] <jmelis> Hi, can someone give me a hand with the upload of a package to a PPA? last version was 1.2-0ubuntu5. Since there is a new upstream version the new version should be 2.0-0ubuntu1 BUT it needs to be recompiled for each release, so it's unclear if it should be 2.0-0ubuntu1~lucid1
[22:32] <statik> jmelis: yep, that is what I would use
[22:34] <jmelis> statik: problem is, I'm trying to upload the changes file with dput and it says "unable to find ...orig.tar.gz in upload or distribution"
[22:38] <ansgar> jmelis: The first upload has to include the upstream tarball. Pass -sa to debuild/svn-buildpackage/... to include it. (You can check the .changes file to be sure.)
[22:39] <jmelis> ansgar: great!
[22:40] <slangasek> pitti: postgresql-common accepted, sorry for the delay
[22:40] <slangasek> pitti: btw, why is the bzr-vcs branch for this pointing at a personal branch?  Should this be lp:ubuntu/postgresql-common instead?
[23:01] <BUGabundo> guud evening everyone. may the moon shine over you
[23:20] <TheMuso> Oh, my, goodness. Sooo many people have maverick-proposed enabled when they *probably* shouldn't.
[23:21] <ajmitch> TheMuso: getting a few alsa bugs?
[23:22] <TheMuso> ajmitch: urm yeah, alsa-utils to be precise.
[23:23] <ajmitch> at least you know that people are testing the uploads to -proposed :)
[23:24] <ajmitch> looks like a new version was published for -proposed 5 minutes ago
[23:24] <TheMuso> Yeah I know.
[23:25] <poolie> yeah, i just saw that too
[23:25] <poolie> a version that fixes it was pushed?
[23:26] <TheMuso> ...until then, more bugs will come in as people who use laggy mirrors hit the bug.
[23:26] <poolie> TheMuso: how do you dispose of the dupes?
[23:26] <poolie> i mean, do you do it through the web ui, or by mail, or ...?
[23:28] <TheMuso> poolie: I do as much via mail as I can. Especially with dupes like this, its 10 times faster, particularly since mutt caches my GPG passphrase for a short time.
[23:28] <poolie> you can try using hydrazine's bugclient if you want
[23:28] <TheMuso> I knocked over about 6-7 dupes just then, probably taking me about 3-4 minutes.
[23:28] <poolie> it's a text mode interactive too
[23:28] <poolie> *tool
[23:28] <TheMuso> Hrm will have to check that out at some point, but I am used to the email interface atm.
[23:28] <poolie> it does have the drawback that atm it makes synchronous api calls which can be slow
[23:28] <TheMuso> Thanks for the suggestion.
[23:28] <poolie> sure, just though i'd mention it
[23:29] <poolie> 'bug 664815' 'duplicate 664807' etc
[23:29]  * poolie pets the bot