[00:08] <Flannel> !recovery
[00:08] <Flannel> Do we not have any more information?  What does that do actually?
[01:19] <elkeee> why does offtopic have a 'robot roll call' in the topic? are we encouraging bots now or something equally stupid?
[01:20] <Pici> elkeee: Have you not seen Mystery Science Theater 3000?
[01:20] <Pici> Its from the show... but I'll change it if its confusing.
[01:21]  * Pici fires up fortune -s
[01:21] <elkeee> i have not, no
[01:30] <Pici> Ah, found something that made me chuckle.
[03:25] <Flannel> Mmmm, -ot
[03:26] <Flannel> Anyone awake with -ot stuffs?  He's coming back
[07:08] <Mez> ?
[07:09] <PriceChild> Mez: almost 4 hours ago.
[07:09] <Mez> oops ;)
[07:09] <nickrud> ah, just the guy I need
[07:09] <nickrud> PriceChild, what's with this ubuntu-ops user I just was informed about? How/when should we use it?
[07:10] <PriceChild> nickrud: how were you informed about it?
[07:10] <nickrud> PriceChild, in a memo from ljl
[07:10] <PriceChild> nickrud: timestamp?
[07:11] <nickrud> hm, don't have that anymore. I saved the info on the 12th
[07:11] <nickrud> it's functional, I tested that today.
[07:11] <PriceChild> functional?
[07:11] <nickrud> I was recognized with the password I was given
[07:12] <nickrud> that's as far as I took it, just logged back off
[07:12]  * Mez hasnt been given a password :D
[07:12] <PriceChild> It doesn't appear to have any special access anywhere afaik.
[07:12] <PriceChild> Well I haven't heard of it having any anyway.
[07:13] <nickrud> if it's not to be in my hands, that's fine and dandy. I understood it was to be given access by loco admins as they chose, but I'm fuzzy otherwise
[07:13] <PriceChild> ahh ok
[07:13] <PriceChild> I've probably lost an email again sorry.
[07:14] <nickrud> ok, sometime in the next few weeks/months I'm sure it'll get sorted ;)
[07:15] <PriceChild> nickrud: dude its Christmas, get off of irc!
[07:15] <Mez> PriceChild: not anymore :D
[07:15] <nickrud> nah, day after. I had a rough day at work, I'm unwinding by teasing #ubuntu :)
[07:15]  * Mez had to work over christmas :D
[07:16] <nickrud> lucky man. We took christmas off, but I had the whole darned office load by myself today.
[08:48] <bazhang> nickrud, how did you get that user working?
[08:49] <bazhang> would have been handy in -ot the the last couple of days with the influx of ban-evaders/stalkers
[12:13] <elkeee> hrm, myrtti still hiding from irc?
[12:14] <jpds> She was here yesterday.
[12:17] <Tm_T> elkeee: mostly still in vacation yes
[12:17] <Tm_T> elkeee: if any urgent thing, I can give her a call
[12:19] <elkeee> Tm_T, nah, i just miss her
[12:19] <elkeee> and she's on jaiku if anything is so desperate
[12:23] <Tm_T> heh
[12:23] <Tm_T> we all miss her
[12:25] <Tm_T> awwww, so beautiful when sleeping
[12:25]  * Tm_T <3 Ronja
[12:38] <elkeee> ronja being?
[12:38] <elkeee> the baby or the missus?
[12:39] <Tm_T> Baby
[12:41] <elkeee> it's a sweet name :)
[12:41] <Tm_T> indeed
[12:42] <topyli> makes you a robber! :)
[12:42] <Tm_T> topyli: I am
[12:42] <topyli> ooh i'm sure i'm the first to say that too :\
[12:42] <Tm_T> topyli: actually her second name consists Jussintytär
[12:42] <topyli> sweet!
[12:42] <Tm_T> second names
[12:45] <topyli> my brain is smoking while trying to figure that out
[12:45] <Tm_T> good
[14:21] <bazhang> Amblnb, how may we help you
[14:23] <Amblnb> bazhang @: А фиг ево сказали сюда зайти чтоб #ubuntu-ua  ожывить ))
[14:23] <bazhang> Amblnb, #ubuntu-irc please
[14:23] <bazhang> Amblnb, please /part this channel
[14:25] <bazhang> * [eleos2] (n=chatzill@athedsl-4406484.home.otenet.gr): New Now Know How sken is unbanned? ikonia
[14:26] <Amblnb> bazhang @: Куда это вставлять?
[14:26] <bazhang> Amblnb, ----> #ubuntu-irc (not here)
[14:35] <bazhang> Garfeild, #ubuntu-irc for this please
[14:37] <nickrud> bazhang, it doesn't have access there; I just tested that I could identify as it
[14:37] <bazhang> nickrud, ok thanks :)
[14:49] <elkeee> this again?
[14:50]  * nickrud looks around for the noun
[14:50] <bazhang> what again elkeee
[15:01] <elkeee> bazhang, russian hoodlums
[15:02] <bazhang> elkeee, it was a misunderstanding; amblnb was banned in -ua and thought this was the place to receive help
[15:02] <bazhang> the other one garfeild is an operator in -ru
[15:04] <elkeee> and both coincidentally joined here?
[15:05] <bazhang> amblnb joined here assuming he could be helped; garfeild may have misunderstood and joined
[15:06] <bazhang> it has been resolved in -irc finally
[15:07] <nickrud> bazhang, how many languages do you speak?
[15:07] <bazhang> nickrud, not enough apparently; even knowing russian, seems sometimes misunderstandings arise
[15:08] <elkeee> all except klingon
[15:08] <nickrud> rflol, I've been speaking english fluently for 52 years, and still have daily misunderstandings ;)
[15:08] <bazhang> hehe
[15:09] <elkeee> haha
[15:09] <bazhang> loco channels have much less stringent behaviour filters it would seem
[15:11] <elkeee> well yes. we allow a degree of autonomy, but they're all expected to stick to the code of conduct
[15:12] <elkeee> every single part of the ubuntu community is expected to abide by that. no exceptions.
[15:12] <elkeee> unofficial or not. no exceptions.
[15:13] <elkeee> if they don't, they have absolutely no right to call themselves part of the ubuntu community
[15:14] <jpds> The code is more like... a guideline.
[15:16] <elkeee> it is, and those who choose to not be guided by it choose to not be part of this community
[15:21] <elkeee> there's no point in defining a community by a set of values if people who urinate on those values are allowed to identify as the same as us. it lessens the integrity and relevence of those values
[15:25] <bazhang> very true.
[15:25] <bazhang> and -ot is a perfect of example of abrogation of those values
[15:25] <jpds> bazhang: 15:25:01 [!] wececw (CM bot<EMAIL_ADDRESS>has joined #ubuntu
[15:26] <bazhang> the topic in -ot may as well be: ban evaders and stalkers welcome!
[15:26] <elkeee> bazhang, yes, but not only.
[15:27] <bazhang> jpds, yep, they were joining all day yesterday
[15:29] <elkeee> you may kill unofficial bots on sight
[15:30] <nickrud> bazhang, you should (if you could) change to that topic. Not enough people with clout hang out there
[15:32] <bazhang> nickrud, not that loco channels dont have plenty of problems (they do); but the main channel referenced from #ubuntu (ie #ubuntu-offtopic) for chat is such a cesspool at times reflects very badly on the main channel imo
[15:33] <bazhang> almost worried to send new users into that sharkpit at times
[15:36] <elkeee> i'm equally concerned about the other cesspool that falsely advertises being the first/best ubuntu channel which is closer to an sex and hate channel than an ubuntu channel
[15:36] <elkeee> anyway, i need sleeps
[16:25] <bazhang> wow alsa has gone unhelpful of late
[16:25] <bazhang> or at least that fellow copper
[16:26] <nickrud> I can understand their frustration with becoming a dumping ground
[16:26] <bazhang> he did not try to help anton at all.
[16:26] <bazhang> he basically said 'ubuntu sucks, next!'
[16:27] <nickrud> no telling what prior experience brought that on. probably hit the overload point prior to this
[16:27] <nickrud> I can relate to beating on an innocent simply because he came after the breaking point
[16:28] <bazhang> the helper gnubien was helpful; just bad luck to get that copper fellow
[16:29] <bazhang> I simply back away from irc when I get to that point
[16:29] <nickrud> I was nice to him: maybe he'll be nicer to the next ubuntu newbie, even if he doesn't help much. I keep saying that someday I'll study up on pulse audio, but will probably not
[16:31] <bazhang> sudobash seems to be trolling
[16:31] <nickrud> nah, he was told he was wrong about something and is puffing up
[16:32] <bazhang> heh
[16:32] <nickrud> see?
[16:32] <bazhang> thats never happened before
[16:34] <sudobash> Abuser of power and Anal retentive FUCKS
[16:36] <Jack_Sparrow> And as polite in PM as in here
[16:46] <nickrud> he's close to apologizing I think
[16:49] <Jack_Sparrow> nickrud, You have him in PM
[16:49] <nickrud> no, I'm inferring from his quick join then part. Sorta like starting towards a person, then turning around ;)
[16:50] <Jack_Sparrow> Ah.. Hope your Holiday went well.  Ours was fantastic
[16:50] <nickrud> I've talked to him in pm before though, seemed rational and funny
[16:51] <nickrud> Jack_Sparrow, yeah, it was fine. Family's in Seattle area, so it was kinda remote though
[16:51] <Jack_Sparrow> We have a house on the penninnsula, so I know what you mean
[18:08] <bazhang> heh
[18:09] <bazhang> took him a while to actually ask a question
[18:25] <bazhang> crosspost flooding
[18:49] <bazhang> ban-evader/stalker extreme yes-man-1 (aka sp0rtily, z, patchpocket) in -ot
[18:49] <bazhang> Pici, jussi01_ Mez ^^
[18:50] <bazhang> * [yes-man-1] (n=eee@<IP_ADDRESS>): purple
[18:52] <jussi01> bazhang: are certain, how do you know?
[18:53] <bazhang> jussi01, the way he is stalking, his speech patterns, referencing certain films as did patchpocket et al, acknowledging that he 'could be' though the IP is not stable, and more
[19:25] <bazhang> nickrud, that was not the context he was asking in though.
[19:26] <Flannel> bazhang: re: WoW?
[19:26] <nickrud> and counterstrike has a free version, http://www.soft32.com/download_2541.html
[19:26] <bazhang> Flannel, re: getting pirated games in general
[19:27] <Flannel> bazhang: You can't "pirate" WoW.  The game is free for download,you need an account to play, etc.
[19:27] <bazhang> he had a whole list
[20:21] <jpds> @btlogin
[20:21] <jpds> ubottu: ping
[20:21] <jpds> Oh, so you are alive.
[20:21] <jpds> @login
[20:21] <jpds> @btlogin
[23:22] <runescapemastr55> guys
[23:22] <runescapemastr55> i know a glitch i think
[23:22] <runescapemastr55> so you can talk whail your banned
[23:23] <nickrud> runescapemastr55, there's lots of ways ... please don't educate people about it
[23:23]  * nickrud smiles
[23:23] <runescapemastr55> im not
[23:23] <runescapemastr55> im tryin to report it
[23:24] <runescapemastr55> nickrud?
[23:24] <runescapemastr55> oh nevermind!!!
[23:24] <runescapemastr55> forget it
[23:24] <nickrud> runescapemastr55, we're listening, and thanks for moving here. I'm a lowly op, not particularly intersested but others might be
[23:30] <runescapemastr55> guys
[23:31] <runescapemastr55> i wanna describe a glitch to you
[23:31] <runescapemastr55> if you type "/msg #ubuntu <your message>" it will send it to the channel ven if your not in the channle
[23:32] <PriceChild> runescapemastr55: #ubuntu is +n so I don't believe that true.
[23:32] <runescapemastr55> whats +n?
[23:33] <PriceChild> runescapemastr55: http://freenode.net/using_the_network.shtml
[23:33] <runescapemastr55> im not reading yhat
[23:34] <runescapemastr55> an op made me read 3
[23:36]  * genii-around sips


[00:07] <jdong> james_w: yeah, certainly the tricky part will be coordinating all plugins to be compatible with bzr 1.3 and I will have to look into that the most.
[00:11] <james_w> well bzrtools and bzr-builddeb have just had releases, so should be fine.
[00:11] <james_w> bzr-svn just had an upload that jelmer acked as being compatible, so it's only bzr-gtk that I am unsure about.
[00:15] <thekorn> hi, I try to integrate bzr in some of my scripts, is there an easy way to find out wheather a file/dir is in a bzr-branch or not?
[00:15] <thekorn> and return the related branch object?
[00:16] <nekohayo> hmm, any reason why bzr-gtk in ubuntu hardy only seems to provide olive, no nautilus integration?
[00:27] <james_w> thekorn: 'from bzrlib import branch; b = branch.Branch.open(dir)' Does that do what you want?
[00:27] <james_w> thekorn: something like "errors.NotBranchError" is thrown if it's not a branch.
[00:28] <james_w> there's also open_containing if you may be given a path below a branch, this returns a tuple (branch, relpath).
[00:28] <james_w> thekorn: or do you have a branch and want to know if the given path is versioned in that branch?
[00:29] <yacc> abentley: still there? It seems to be dependant on the svn repo too, a push to a local file:// url worked fine.
[00:29] <abentley> yacc: kinda here.
[00:29] <thekorn> james_w, yes, lets say I'm somewhere, and I want to now if this location is in a branch, and if so, get the branch root
[00:30] <abentley> I would expect it even works with more permissive SVN repos.
[00:34] <yacc> abentley: well, I'll be checking that now, gonna switch back first to bzr 1.3/bzr-svn stable for the experimenting.
[00:35] <abentley> thekorn: The branch root is Branch.base
[00:35] <james_w> thekorn: so you don't care what branch it's in, just that it is in one?
[00:36] <thekorn> james_w, I would like to have a similar behaviour than 'bzr info' - if i call this somewhere in a branch i get the branch root, if I call this command outside a branch I get "Not a branch Error ...."
[00:36] <james_w> thekorn: do branch.Branch.open_containing(path)[0] then
[00:37] <james_w> that gets you the branch, if any, that contains path. You can then get the base.
[00:37] <james_w> If you want you can catch the NotBranchError.
[00:37] <james_w> do you also want to ensure that the path you were given is versioned by the branch that you get returned?
[00:37] <thekorn> james_w, abentley , thanks alot this works
[00:38] <thekorn> no i only need the branch root
[00:38] <james_w> thekorn: cool, you should be all set then.
[00:38] <james_w> thekorn: how are you finding it transitioning to use the API?
[00:40] <thekorn> james_w, well I just started using bzrlib,
[00:40] <thekorn> to be honest: it's hard without a real public API reference
[00:41] <thekorn> but ipython does a good job
[00:41] <james_w> yeah, that's understandable.
[00:41] <james_w> #bzr is the API reference that I tend to reach for.
[00:42] <yacc> Ahhhh, how do I make bzr not check SSL certificates?
[00:43] <james_w> yacc: use urllib+ as a prefix for the URL.
[00:43] <james_w> yacc: although is this connecting to svn?
[00:43] <thekorn> james_w, http://bazaar-vcs.org/Integrating_with_Bazaar is a good starting point to understand the general workflow, but needs some improvements
[00:43] <yacc> Oh, don't you curl is the solution :)
[00:44] <yacc> james_w: yeah, but I guess bzr checks the url first for a bzr target?
[00:44] <james_w> thekorn: yeah, I think it's quite new. It would be great to improve it.
[00:44] <james_w> yacc: yes I think so.
[00:44] <james_w> yacc: if you prefix the URL with svn+ then bzr doesn't probe it first.
[00:44] <thekorn> for example the last part is switsching between 'branch' as a modul and 'branch' as a Branch-object
[00:45] <james_w> ah, that should be avoided.
[00:46] <yacc> Ok, it fails with my private https host too :(
[00:47] <james_w> thekorn: thanks, fixed.
[00:48] <yacc> james_w: what's the prefix for svn over ssh?
[00:49] <thekorn> james_w, thanks, but same in "Getting a Revision object from a revision id"
[00:50] <james_w> yacc: svn+ssh:// I think
[00:51] <yacc> james_w: found it already ;)
[00:51] <yacc> abentley: svn+ssh:// does work against the same host where https:// does not work :(
[00:51] <james_w> thekorn: thanks again.
[00:52] <abentley> yacc: so you've actually got a solution, then?
[00:52] <yacc> No.
[00:53] <yacc> The svn repo I need to push to is hosted by a provider, so no ssh access ;(
[00:53] <yacc> But it might help figuring out why it does not work.
[00:53] <abentley> "the same host" as what?
[00:54] <yacc> abentley: I've tried it against a repo hosted on my private colo server, and it fails as usual against the https url, but works fine when doing the access over ssh.
[00:54] <yacc> Which suggests all kind of interesting things.
[00:55] <abentley> Seems quite strange.  Maybe the security settings are different on ssh?
[00:58] <yacc> abentley: probably not. I have fine grained access controls on https, OTOH, svn+ssh has no access controls at all.
[00:58] <yacc> abentley: well, unix permissions, but if you don't have full write access to the whole repo, well, then usually even read-only operations break against that repo.
[01:04] <jelmer> abentley: pong
[01:04] <jelmer> yacc: hi
[01:05] <abentley> jelmer: yacc is running into some problems with bzr-svn and properties.
[01:05] <yacc> jelmer: I'm trying to track down the svn push problem.
[01:05] <yacc> I'm just pasting the apache logs from my server for the failing svn-push
[01:07] <yacc> jelmer: #190568
[01:07] <yacc> The funny thing is that it's depending upon the transport layer.
[01:07] <yacc> Pushing to exactly the same repository via svn+ssh works fine.
[01:07] <yacc> Pushing via https breaks.
[01:08] <jelmer> bug 190568
[01:08] <ubotu> Launchpad bug 190568 in bzr-svn "bzr-svn exception plugin error in commit" [Undecided,Incomplete] https://launchpad.net/bugs/190568
[01:08] <jelmer> yacc: interesting
[01:08] <jelmer> yacc: do you have wireshark handy?
[01:08] <yacc> ethereal?
[01:08] <yacc> but it's https.
[01:09] <jelmer> ah, ouch
[01:09] <yacc> I can install the repo on http too.
[01:09] <yacc> No sure, you are in the same timezone, how fresh are you.
[01:10] <yacc> btw, I've done the last tests with 1.3rc1 + tip of bzr-svn stable
[01:10] <yacc> but bzr 1.1rc1 + bzr-svn 0.4.7 has basically shown exactly the same behaviour through the day.
[01:12] <asabil> yacc: on windows ?
[01:13] <asabil> if so, you could use oSpy (and API level sniffer) to sniff https traffic
[01:13] <jelmer> yacc: please update your bzr-svn checkout
[01:13] <jelmer> yacc: and add -Dcommit during push
[01:13] <yacc> It's 2 hours or so old.
[01:13] <yacc> I've already done the -Dcommit.
[01:14] <yacc> It just produces the files + 3 properties.
[01:14] <yacc> jelmer: email address?
[01:14] <jelmer> yacc: I just added the -Dcommit bit 5 seconds ago :-)
[01:14] <yacc> Well, def mutter checked for commit already in the old code?
[01:15] <jelmer> yeah, but I just added some extra output for it
[01:15] <yacc> Ok, pulling the stuff.
[01:16] <yacc> I've changed the repo to http, so I can also run ethereal. :)
[01:16] <yacc> asabil: Technically, I've written an API level sniffer for Linux myself, but I don't like to use it, as I've written it for a customer so I cannot really distribute it, nor should I officially use it ;)
[01:17] <asabil> oh oki
[01:18] <yacc> asabil: well, at least the code generator for the intercepting stubs was written in Python ;)
[01:18] <yacc> jelmer: paste is ok for you?
[01:19] <jelmer> yacc: yeah
[01:19] <yacc> http://rafb.net/p/Yy0yfm50.html
[01:19] <yacc> asabil: and guess what, the main usage was intercepting OpenSSL calls ;)
[01:20] <yacc> SSL can make debugging webstuff quite a PITA.
[01:20] <jelmer> yacc: Ah, think I figured it out
[01:20] <yacc> jelmer: really? :))))))
[01:20] <jelmer> / is invalid in a file property
[01:20] <yacc> property name?
[01:20] <jelmer> yeah
[01:20] <jelmer> bzr-svn is using it
[01:20] <yacc> Why did it work via svn+ssh then?
[01:21] <yacc> *wonder*
[01:21] <jelmer> subversion doesn't do validation
[01:21] <yacc> Oh, apache does ;)
[01:21] <yacc> probably because the name gets embedded somewhere in the URL ;)
[01:21] <yacc> And one / to much can break stuff.
[01:21] <jelmer> but a / in a xml tag name messes with the subversion apache module
[01:22] <yacc> Anyway, any chance for a quick fix?
[01:22] <yacc> Just throwing a .encode("base64") would solve it in a completely incompatible way I guess ;(
[01:26] <jelmer> I'm looking at it
[01:26] <jelmer> yacc: it's not as simple as that
[01:26] <jelmer> yacc: that will break older bzr-svn implementations
[01:26] <yacc> Yeah, I said incompatible.
[01:27] <yacc> but there is basically no way you can keep it compatible, because you cannot address these properties via http. So that calls probably for an config.ini option?
[01:30] <jelmer> hmm, actually
[01:30] <jelmer> this should be fixable without any changes
[01:30] <yacc> How so?
[01:31] <yacc> entity encoding in the XML? *wonder*
[01:31]  * yacc burns to test it out, I have four branches to deliver today ;)
[01:36] <yacc> jelmer?
[01:37] <yacc> Just curious what's your solution idea is.
[01:41] <jelmer> yacc: trying to debug this, give me a few minutes
[01:42] <yacc> no problem :)
[01:42] <yacc> Anyway I can help?
[01:45] <asabil> jelmer: is there any bzr-svn to be used with 1.2 ?
[01:59] <jelmer> yacc: not really atm
[01:59] <jelmer> asabil: 0.4.7
[01:59] <asabil> 0.4.8 you mean ?
[02:00] <asabil> jelmer: shall I also update the wiki page to add a link to 0.4.8 ?
[02:00] <jelmer> asabil: 0.4.8 isn't out yet
[02:01] <jelmer> asabil: I really mean 0.4.7
[02:01] <asabil> http://samba.org/~jelmer/bzr/bzr-svn-0.4.8.tar.gz ?
[02:01] <yacc> Despite the fact that the wiki claims it's for 1.1 only?
[02:01] <jelmer> asabil: Ah, crap
[02:02] <jelmer> asabil: that should be gone now
[02:02] <jelmer> asabil: It shouldn't be up there because it doesn't pass a few tests
[02:02] <jelmer> yacc: yes, 0.4.7 works with 1.2 although it will warn you it may be out of date
[02:02] <asabil> :/
[02:02] <jelmer> asabil: you should be able to just use 0.4.7 though
[02:02] <asabil> jelmer: then the ppa package should be installable
[02:04] <jelmer> asabil: I haven't had time for that, instead focussing on releasing a bzr-svn compatible with bzr 1.3
[02:04] <asabil> okidoki
[02:07] <yacc> jelmer: as you are the source of all bzr-svn knowledge, is it useable for the daily usage as svn replacement?
[02:07] <yacc> When working against svn repos?
[02:07] <yacc> I think I've seen even support for svk:merge properties in the code :)
[02:12] <jelmer> yacc: yeah, I use it for that
[02:13] <yacc> jelmer :)
[02:17] <yacc> jelmer: just wondering, on what time zone are you?
[02:41] <jelmer> yacc: CET
[03:11] <jelmer> I'll look into this further tomorrow
[09:53] <rindolf> Hi all.
[09:53] <rindolf> I'm trying to do bzr export planet http://www.gnome.org/~jdub/bzr/planet/2.0/
[09:54] <rindolf> But it dies with {{{ bzr: ERROR: Connection error: Couldn't resolve host 'www.gnome.org' (-2, 'Name or service not known') }}} after downloading a few files.
[09:54] <rindolf> Why does it do another hostname lookup?
[09:54] <rindolf> And it's very slow.
[10:47] <nubbun> in bzr.dev lightweight checkout, I did "bzr --version" and it output "Bazaar (bzr) 1.4dev" then stalled and did much network access and then continued output.  Can someone explain that?  Is that unexpected?
[11:09] <nubbun> which only has patches approved by the PQM:  bzr.dev or lp:bzr?
[11:40] <nubbun> i386: in bzr.dev lightweight checkout, I did "bzr --version" and it output "Bazaar (bzr) 1.4dev" then stalled and did much network access and then continued output.  Can someone explain that?  Is that unexpected?
[11:40] <nubbun> i386: which only has patches approved by the PQM: bzr.dev or lp:bzr?
[11:41] <i386> huh?
[11:41] <i386> I dont know
[11:45] <nubbun> i386: "huh?"  did you not understand the first question?
[11:45] <i386> dude, I dont know who you were talking to before
[11:45] <i386> but it was not me
[11:46] <i386> and I have jack idea about what your saying
[11:46] <nubbun> I wasn't talking to anyone before.  You're the first person to write anything to this channel since I 've been here.
[11:46] <i386> right
[11:46] <i386> I joined the room
[11:46] <dato> nubbun: PQM is bzr.dev
[11:47] <i386> And im not necessarily qualified
[11:47] <nubbun> thanks dato
[11:47] <i386> Perhaps ask your question of the mailing list?
[11:47] <nubbun> dato: and lp:bzr is?
[11:47] <dato> nubbun: and lightweight checkouts are not designed to be useful over network; mostly, to save space locally
[11:47] <dato> nubbun: a mirror, I guess
[11:49] <nubbun> I did a lightweight checkout of bzr.dev .   When I do any operation using it, it accesses the network.
[11:49] <luks> nubbun: dev versions of bzr always print some debugging info about the branch it's from
[11:49] <nubbun> bzr version          does a lot of network activity.
[11:49] <luks> and to get that info from a lighweight checkout, it needs to ask the remote branch
[11:49] <luks> it shouldn't do that much traffic, though
[11:50] <nubbun> luks: do you know how I shut off network access from the dev branch?  I'm usually offline.
[11:50] <luks> don't use a lighweight checkout
[11:50] <luks> or don't use bzr --version :)
[11:50] <dato> or don't use the .dev branch :)
[11:50] <nubbun> other operations also do network access, but not so much.  bzr info also does network.
[11:51] <nubbun> I think   bzr version takes over a minute over dialup
[11:51] <luks> only if you use a checkout of _your_ branch
[11:51] <luks> bzr version is the same as bzr --version, which is about the bzr branch
[11:52] <nubbun> I'm anticipating  bzr branch lp:bzr  will take forever.
[11:52] <luks> really, if you are mostly offline, don't use checkouts
[11:53] <nubbun> So I guess I just can't do it.  I'll archive the .bzr directory, remove it and put it back when I wish to update.
[11:53] <luks> nubbun: the dev branch talks to it's remote branch only on bzr --version
[11:54] <luks> I guess you don't really need bzr --version for your work, do you?
[11:54] <nubbun> bzr info also does net access.
[11:54] <luks> for other comm
[11:54] <luks> er
[11:54] <nubbun> but that's expected
[11:54] <luks> but that's not bzr.dev net access
[11:54] <nubbun> well not really expected, but not surprizing.
[11:54] <luks> that's network access for your branch
[11:54] <nubbun> yes.
[11:55] <luks> if you use lightweight checkouts, basically all commands will require network access
[11:55] <luks> (not talking about bzr.dev and bzr --version here)
[11:55] <nubbun> Thanks for your help, luks, nato!  I'm going for now.
[12:04] <awilkins> jelmer: Which version of pyrex are you using?
[12:08] <awilkins> Hmph, obviously not 0.9.3, 0.9.6 works much better
[12:10] <jelmer> awilkins: probably the most recent one
[12:10] <awilkins> Yes, the most recent one actually manages to get to the hug elist of compiler errors
[12:21] <awilkins> strings are immutable in python, so you can't adjust an array of them by doins for thing in array: sthing = sthing + 'stuff' no?
[12:21] <dato> you can't modify an existing string (value)
[12:22] <dato> but you can assign to a name a new value
[12:22] <dato> so sthing = sthing + 'stuff'  is legal
[12:22] <awilkins> FOudn what I want, enumerate()
[12:34] <Lo-lan-do> Hi all
[12:35] <Lo-lan-do> I'm stuck with bzr 1.1~rc1-1...
[12:36] <ubotu> New bug: #204607 in bzr "crash in 'bzr pull' when the network connection breaks" [Undecided,New] https://launchpad.net/bugs/204607
[12:38] <Lo-lan-do> (Due to more recent versions being incompatible with bzr-svn)
[12:39] <dato> Lo-lan-do: guess who you have to prod :-P
[12:41] <Lo-lan-do> I know, but I figure he's tired of being prodded.
[12:49]  * yacc wonders if jelmer is a nightowl.
[12:50]  * grutte_pier has been wondering the same for some time
[13:02] <clarby> hmm, I'm experiencing some trouble with push, is there any way to increase the level of verbosity?
[13:03] <luks> ~/.bzr.log might have more info
[13:14] <clarby> Only thing I'm seeing in the log is "45.348  not updating child fraction", but that's probably not what's causing my problems.
[13:14] <clarby> It's always like this: I push, have to ssh to my repository, break-lock and then push again and it works.
[13:14] <clarby> And I'm not getting any feedback that something's awry.
[13:24] <chadmiller> clarby: Those "-Dxxxx" parameters may be of use.
[13:29] <chadmiller> clarby: -Dlock -Devil -Dfetch
[13:29] <chadmiller> clarby: They're all listed in bzrlib/debug.py .
[13:30] <clarby> Ah, great
[13:30] <clarby> Thank you chad
[14:13] <james_w> (and bzr help global-options)
[14:44] <jelmer> abentley: ping
[14:58] <mib_v2v62hnc> Unable to load plugin 'multiparent' from 'bzrlib/plugins'
[14:58] <ashyg> anyone ever see that? the bytecode file is in there
[14:59] <dato> ashyg: the multiparent plugin was dropped a while ago
[15:00] <ashyg> then why is it trying to load it/why did it pull it when i rsynces
[15:00] <ashyg> rsynced
[15:01] <ashyg> rsync -av --delete bazaar-vcs.org::bazaar-ng/bzr/bzr.dev bzr.dev
[15:02] <ashyg> ls bzr.dev/bzrlib/plugins shows__init__.py  __init__.pyc  launchpad  multiparent.pyc
[15:03] <ashyg> running bzr whoami "myname<EMAIL_ADDRESS>results in multiparent error
[15:06] <ashyg> also can't bzr merge, says unable to load plugin multiparent
[15:06] <nubbun> If I have a
[15:06] <nubbun> bzr checkout http://bazaar-vcs.org/bzr/bzr.dev
[15:06] <nubbun> why can't I do a
[15:06] <nubbun> bzr pull lp:bzr
[15:06] <nubbun> I get the error message
[15:06] <nubbun> bzr: ERROR: Not a branch: "/path/bzr.dev/lp:/bzr/"
[15:07] <nubbun> ashyg: are you specifically trying to use the multiparent plugin?
[15:07] <ashyg> no
[15:07] <ashyg> i just rsynced the latest version
[15:07] <nubbun> do you have that plugin in the plugins directory?
[15:07] <ashyg> yeah it came when i rsynced
[15:07] <ashyg> should i rm it
[15:07] <nubbun> the bzr.dev or 1.3?
[15:08] <ashyg> i'm seeing usage of it other places though build/lib.linux-i686-2.5/bzrlib/versionedfile.py:        mpvf = multiparent.MultiMemoryVersionedFile()
[15:08] <ashyg> bzr.dev
[15:09] <ashyg> i'll try 1.3
[15:09] <nubbun> ashyg: I think all the plugins have corresponding code in bzr even if they aren't shipped together.
[15:09] <nubbun> as much as that is not what one would expect.
[15:10] <ashyg> hey cool 1.3 works
[15:10] <ashyg> alright thanks
[15:10] <nubbun> ashyg: are you new to bzr?
[15:10] <fullermd> The multiparent plugin has been gone for a long time.
[15:10] <fullermd> (well, FSVO; a couple months, I think)
[15:11] <nubbun> perhaps someone ( ashyg ) should file a bug?
[15:12] <ashyg> yes i am new to bzr as of this morning, and yes perhaps a bug should be filed to have that pyc removed
[15:12] <fullermd> I dunno.  The bug might equally be that we still publish rsync instructions for it (if we do).
[15:12] <fullermd> It's not standalone anymore.
[15:13] <ashyg> ah. yes there are rsync instructions on the install wiki page
[15:14] <fullermd> That's probably historical.  Pull should be faster than rsync (at least, if the tree were still standalone, which is the main case where rsync made sense to begin with)
[15:14] <nubbun> http://bazaar-vcs.org/Download
[15:14] <nubbun> has instructions for rsync. Seems to be current use.
[15:15] <nubbun> fullermd: pull not faster, but checkout --lightweight faster, right?
[15:15] <nubbun> pull would get history info.
[15:16] <fullermd> No, pull is faster than rsync on pack trees, because rsync ends up retransferring huge chunks of the history on a regular basis.
[15:16] <nubbun> I guess it could still be faster if rsync also gets history inf.
[15:16] <fullermd> bzr.dev used to be a standalone tree precisely SO that rsync would get the history down.
[15:16] <ashyg> i don't have bzr on my system yet :)
[15:16] <nubbun> oh, you mean for updates.
[15:16] <ashyg> so i wget'd the tarball
[15:17] <fullermd> Urf.  Those rsync instructions SHOULD be dumped.  The WT there is really, really, really old.
[15:18] <nubbun> fullermd: do you know the answer to my question about pulling for a checkout?
[15:19] <fullermd> Well, lightweight checkouts via a dumb server conceptually still require significant data transfer.  Less than a full branch, but still a fair hunk.
[15:19] <nubbun> If I have a
[15:19] <nubbun> bzr checkout http://bazaar-vcs.org/bzr/bzr.dev
[15:19] <nubbun> why can't I do a
[15:19] <nubbun> bzr pull lp:bzr
[15:19] <nubbun> ?  I get the error message
[15:19] <nubbun> bzr: ERROR: Not a branch: "/path/bzr.dev/lp:/bzr/"
[15:19] <fullermd> A smart server can conceptually do it straight, but that cap isn't in place.
[15:19] <nubbun> I wish to update my checkout from lp:bzr
[15:20] <luks> because you hit a bug, that has been fixed in 1.3
[15:20] <fullermd> Well, pulling into a checkout is the wrong answer anyway.  Even if it worked, it would fail.
[15:20] <luks> but you really don't want pull in a checkout
[15:20] <luks> just run "bzr update"
[15:20] <fullermd> Why would you want to pull from the LP mirror in this case anyway?
[15:20] <nubbun> luks: I just got the checkout of bzr.dev .  Shouldn't it have the bugfix?
[15:21] <luks> are you running bzr.dev?
[15:21] <nubbun> yes.
[15:21] <luks> hm, then yes
[15:21] <luks> weird
[15:22] <luks> I though the directory service stuff was added specifically to fix this
[15:22] <luks> thought
[15:24] <nubbun> in a checkout of bzr.dev, what _should_ a pull of lp:dev do?
[15:24] <nubbun> I mean pull of lp:bzr
[15:24] <dato> you shouldn't be pulling on a checkout
[15:24] <fullermd> It would try to pull into the bzr.dev branch, which you can't write to, and so blow up.
[15:25] <dato> but alas, you shouldn't have a checkout over a read-only transport in the first place
[15:25] <nubbun> can't pull into because there is no working tree?
[15:25] <fullermd> Oh, there are lots of good reasont to pull on a checkout; just none of them apply in this case   :)
[15:25] <dato> fullermd: yes
[15:25] <nubbun> no, there is a working tree, but no history data
[15:26] <nubbun> Why should one not do a checkout from a readonly transport?
[15:27] <nubbun> (like https?)
[15:27] <fullermd> One could.  There's just rarely a particularly compelling case for it; the main use of checkouts implies writing.
[15:28] <nubbun> I think the compelling case is that when you update, you don't need to re-download all files
[15:28]  * fullermd blinks.
[15:29] <fullermd> That's like saying "We need pickles so that you don't die when falling out of an airplane"
[15:31] <nubbun> There is a relation.  To describe update from ro transport:  read checksums or version identifiers or changesets or whatever.  Compare with local archive to see what needs updating.    That's what I said.
[15:32] <fullermd> 'update' != 'pull'
[15:33] <nubbun> pull affects versioning info & working tree, update only working tree, right?
[15:33] <fullermd> Roughly, yah.
[15:35] <nubbun> so a bzr update over http reduces data transfer compared to downloading a new version as an archive via http.  That's the compelling reason to do a checkout over a readonly transport rather than other download via the readonly transport.
[15:36] <fullermd> In that sense, maybe.  But the usual question isn't "checkout vs. wget", it's "checkout vs. branch".
[15:36] <fullermd> I'd lay odds the majority of published repos don't have WT's (or have wildly out of date WT's, like bzr.dev) in the first place.
[15:36] <nubbun> to quote dato: but alas, you shouldn't have a checkout over a read-only transport in the first place
[15:37] <nubbun> and I don't know why he would say that.
[15:37] <fullermd> Because there's little point in using a checkout in that case; you'd just use branch.
[15:37] <nubbun> the branch requires more downloading.
[15:37] <fullermd> Oh, you're talking about a _lightweight_ checkout?
[15:37] <nubbun> yes.
[15:38] <nubbun> sorry
[15:38] <fullermd> Doing that across the internet over a dumb server is suicide.  You'll probably end up with MORE downloading over the long term.
[15:39] <nubbun> Why?  Wouldn't it mainly just retransfer changed files?
[15:39] <fullermd> It has to read a potentially huge amoung of history information to find the changes.
[15:39] <fullermd> (and even a huge amount, if ere khan tipe)
[15:40] <nubbun> unfortunate.  Not what I'd expect.
[15:40] <nubbun> and there's no RO smart server?  None is listed on the download page.
[15:41] <fullermd> The smart server exists, but I don't know that any of the extant verbs help all that much in the lightweight checkout case.
[15:41] <fullermd> Where they do, it's probably more fallout than intent; I don't think anybody's bothered trying to add to it for that use-case.
[15:52] <abentley> nubbun: The smart server is part of bzr and can be run in read-only mode
[15:53] <nubbun> abentley: will updating a lightweight checkout via smart server reduce data transfer compared to downloading the next tar.gz?
[15:54] <nubbun> For that matter will updating via HTTP?
[15:54] <jelmer> abentley: hi
[15:54] <jelmer> abentley: is there anything blocking Repository.get_revision_graph() from being deprecated in favor of Repository.get_graph() ?
[15:54] <abentley> nubbun: No one's run any tests on that.
[15:56] <abentley> jelmer: I don't know.
[15:57] <abentley> It get_revision_graph doesn't seem to be used in very many places.
[15:58] <nubbun> If I have a lightweight checkout (say from bzr.dev) and I wish to update from another source, which may be another branch, is rebasing the right and only way to do that?
[16:00] <fullermd> nubbun: Rebasing has nothing to do with checkouts or working trees.  You want more like 'switch'.
[16:00] <nubbun> fullermd: thank you.
[16:04] <abentley> nubbun: lightweight checkouts are intended to be used when you have local (LAN or hard disk) access to the source branch.  Using them over the internet is going to be a world of pain.
[16:13] <yacc> jelmer: :)
[16:14] <yacc> jelmer: any hints how you plan to solve the / property problem?
[16:17] <yacc> Ah, something got commited to bzr-svn :)
[16:17] <yacc> The suspense is unbearable, ...
[16:18] <yacc> :( still an assert error :(
[16:26] <ubotu> New bug: #183824 in bzr-svn "Use only one connection simultaneously to a Subversion repository" [Wishlist,Triaged] https://launchpad.net/bugs/183824
[16:27] <thekorn> hi all, I try to write sme scripts using bzrlib and i've got one question:
[16:27] <thekorn> when should I /do i have to lock_read() a tree?
[16:28] <thekorn> what's the reason behind this locks?
[16:36] <yacc> jelmer: could you please explain your ideas how to solve the bug in a compatible manner? This way I'd be able to quick&dirty code up something.
[16:52] <james_w> thekorn: I think they are to make sure that no-one messes the tree while you are reading it.
[16:52] <james_w> thekorn: I can't remember the current state of the lock infrastructure, but certainly at one point some of the lock_read() calls were no-ops.
[16:57] <thekorn> james_w, whenever I do 'tree.get_file_text()' without the lock I get an Exception, so i added it there,
[16:58] <james_w> thekorn: it's probably a good idea to just grab the tree, and then lock it and try: finally: the rest of the code with the unlock in the finally block.
[16:58] <james_w> that should avoid you any problems.
[16:59] <thekorn> right
[16:59] <Qhestion> ehm, i am reading bazaars sourcecode, and in msgeditor.py line 70 (in _run_editor), there is a check for an exit code of 127 (results in a continue statement, so that the next editor is tried). what does that code mean? as far as i know exit codes are not standardized, so --?
[17:00] <james_w> $ does-not-exist
[17:00] <james_w> $ echo $?
[17:00] <james_w> 127
[17:00] <Qhestion> ah
[17:00] <james_w> I don't know if it's part of POSIX or something.
[17:01] <Qhestion> anyway, now it makes sense
[17:01] <Qhestion> bazaars source code is better than any book :)
[17:02] <Qhestion> oh and why does it else:break? shouldnt that be else:continue?
[17:03] <Qhestion> no it should not
[17:03] <Qhestion> nevermind
[17:03] <james_w> no, that's for the case when your editor runs but dies for some reason.
[17:04] <Qhestion> yeah, i had the weird idea of just trying another editor in that case. not a good idea...
[17:05] <james_w> nope
[17:08] <walters> hi, can someone point me to the bits of the bzrlib API I'd need to extract metadata from a working directory?  In particular, say to parse the log stream
[17:09] <luks> http://bazaar-vcs.org/Integrating_with_Bazaar
[17:09] <james_w> walters: sorry, can you clarify what you mean by the log stream?
[17:09] <walters> luks: that looks really useful, thanks!
[17:09] <walters> james_w: output of "bzr log"
[17:09] <luks> but if you have any specific questions, just ask
[17:10] <luks> bzr log has fairly complex code behind it
[17:10] <dato> james_w, Qhestion: I don't think "x == 127" is going to happen, call() would raise ENOENT instead
[17:11] <james_w> walters: so you can follow the revision pointers to get each individual revision and then read the message etc, or you can use show_log if you just want a formatted output like "bzr log".
[17:11] <james_w> walters: I'd be happy to give you pointers to help with either
[17:11] <james_w> hi dato
[17:12] <james_w> dato: it seems to check for ENOENT as well, so that's a little odd.
[17:12] <dato> (well, it could happen if your editor is (as script that is) then exec'ing something which does not exist)
[17:13] <dato> s/as/a/
[17:13] <james_w> ah, thanks.
[17:22] <walters> hm, how do i get the revision number from a Revision object?
[17:23] <james_w> walters: ah, that's harder, as a revision number is only defined relative to a particular mainline.
[17:23] <james_w> are you walking the mainline?
[17:23] <walters> i have a working directory
[17:23] <james_w> anyway, give me one second and I should have a more helpful answer.
[17:23] <luks> branch.revision_id_to_revno(r.revision_id)
[17:23] <walters> i need to operate in terms of that, because my code is trying to generate statistics over the working tree for each revision
[17:24] <walters> conceptually:  for revision in reversed(revisions): bzr_revert(revision); generate_statistics()
[17:24] <walters> luks: cool, thanks
[17:24] <luks> where is "revisions" comming from?
[17:25] <james_w> walters: that's not the best way.
[17:25] <walters> branch.revision_history()
[17:25] <luks> then you don't need it at all
[17:25] <luks> revision_history is linear
[17:25] <luks> for revno, revision in enumerate(reversed(revisions))
[17:26] <walters> ah, that makes sense
[17:26] <fredreichbier> hello
[17:26] <luks> (or reversed, I'm not sure right now)
[17:26] <james_w> there's also iter_reverse_revision_history
[17:27] <james_w> which will return the first one to you quicker.
[17:28] <james_w> luks: did you see that jam put a version of your patch up for review?
[17:28] <luks> yes
[17:28] <james_w> are you happy with how it ended up?
[17:29] <luks> heh, no I was unhappy for very different reasons
[17:29] <luks> the patch was there since december last year, completely ignored
[17:29] <james_w> yeah, I just wondered if you had any opinions on the final version.
[17:29] <luks> now emacs developers complained how slow it is
[17:29] <luks> and things happen...
[17:29] <james_w> yeah
[17:30] <luks> but yeah, the patch looks much better than mine version
[17:31] <james_w> cool, at least we get a good improvement in the end, so it's not all bad.
[17:51] <awilkins> jelmer: I got those pyrex bindings to build
[17:52] <awilkins> Now to test the buggers.....
[17:53] <james_w> awilkins: nice work.
[17:58] <awilkins> james_w: You have to hold it's hand and feed it all the library includes manually because Win32 doesn't have LOADLIB or whatever it is Linux uses
[17:59] <james_w> 403 Forbidden - Reading tree failed
[18:00] <james_w> there's still a pristine-tar branch there though, is that just old?
[18:00] <james_w> oops, sorry, wrong channel.
[18:01] <walters> james_w, luks: thanks for the help, got my script working
[18:02] <james_w> walters: great.
[18:06] <james_w> jdong: bzr 1.3 just got ACCEPTED.
[18:06] <dato> jdong: bzr 1.3-1 in Debian (currently in incoming.d.o). you'll have to check with james_w/jelmer what's up with bzr-svn
[18:06] <james_w> thanks dato
[18:06] <dato> james_w: gaah, I was typing :-P
[18:06] <james_w> :-)
[18:14] <jelmer> awilkins: ah, cool
[18:16] <james_w> jelmer: hi. Would you be happy for the latest bzr-svn in Debian to go in to Hardy?
[18:17] <awilkins> jelmer: Alas, it doesn't complete the selftest
[18:17] <awilkins> jelmer: It seems to have a deadlock in bzrlib.plugins.svn.tests.test_commit.RevpropTests.test_change_revprops
[18:17] <dato> james_w: hardy has sid's
[18:17] <jelmer> james_w: Yeah, that'd be fine
[18:17] <dato> james_w: 0.4.8 hasn't been uploaded yet
[18:17] <james_w> jelmer: this is with 1.3 btw.
[18:18] <jelmer> james_w: oh, there is nothing compatible with 1.3 out yet
[18:18] <jelmer> james_w: 0.4.7 does not work with 1.3
[18:18] <jelmer> it breaks in quite a few cases
[18:18] <james_w> ah, ok, sorry.
[18:18] <jelmer> 1.2 should be fine though
[18:19] <james_w> we'll wait for you then.
[18:19] <jelmer> awilkins: oh, I'm not aware of any deadlocks
[18:19] <jelmer> awilkins: it just segfaults here at the moment
[18:19] <james_w> I've got a patch waiting to be sponsored that removes the warning when used with 1.2, so either way hardy will end up with a working set.
[18:23] <jelmer> james_w: yeah, I noticed. thanks for taking care of that
[18:26] <james_w> jelmer: no problem. It would be good to get this round of updates in, but if it doesn't at least it should all work well together.
[18:29] <jdong> dato / james_w: thanks for the update. Let me know how the plugins go :)
[18:29] <jdong> I know bzrtools is ready
[18:31] <james_w> jdong: yeah, we'll wait a few days to see if a 1.3 compatible bzr-svn arrives in time for it to be reasonable for hardy.
[18:32] <jdong> that sounds like a plan.
[18:39] <awilkins> jelmer: That's odd, if you run just the test on it's own, it breaks into the debugger, but it just locks solid as part of the suite
[18:39] <awilkins> Is it supposed to break into the debugger?
[18:39] <awilkins> Or is that the CPython Win32 equivalent of a SEGFAULT
[18:39] <jelmer> I may've left a "import pdb; pdb.set_trace()" statement somewhere
[18:40] <awilkins> Aha, yes
[18:40] <awilkins> Is that why the suite locks solid?
[18:41]  * awilkins starts suite again
[18:47] <ubotu> New bug: #204759 in bzr-svn "AssertionError when committing" [Undecided,New] https://launchpad.net/bugs/204759
[18:52] <awilkins> jelmer: Are tests run sequentially from the source?
[18:54] <jelmer> awilkins: yes
[18:55] <awilkins> Just hit a segfault (or whatever causes a process to die)
[18:56] <jelmer> that's a known issue
[18:56] <awilkins> But I can't seem to reproduce it - would something that causes a "WindowsError" exception do that?
[18:56] <jelmer> I actually also know what is causing it but I haven't found a way around it yet
[18:56] <jelmer> awilkins: Not sure, I don't have too much experience with python on windows
[18:56] <awilkins> And do the test names show up before or after they execute? Because the test named on STDERR passes if you run it solo
[18:57] <awilkins> The one after causes a WindowsError
[18:57] <jelmer> test names show up before they execute
[18:57] <awilkins> That's weird then
[18:58] <jelmer> it may not have printed all test names yet though
[18:58] <jelmer> are you running with -v ?
[18:59] <awilkins> no
[19:00] <awilkins> I'm just running the whole of TestFetchWorks now
[19:04] <awilkins> Ok, it seems to be test_fetch_trunk1 but it passes fine when run on it's own
[19:06] <ubotu> New bug: #160335 in bzr-svn "--prefix could be determined from specified url" [Wishlist,Fix committed] https://launchpad.net/bugs/160335
[19:08] <awilkins> jelmer: It passes on its own but dies when you run it with the others
[19:09] <awilkins> test_fetch_trunk1
[19:36] <jelmer> re
[19:37] <awilkins> Ok, question ; Python2.5 sources have a "VS2005" build folder, if I use that to run python in debug mode, will it work with my extensions built on the 2003 compiler?
[19:37] <awilkins> (probably not, eh?)
[19:41] <jelmer> Not sure, sorry
[20:09] <jelmer> Ah, I think I finally found the bug that was blocking 0.4.8
[20:19] <asabil> awilkins: I don't think so, unless you manage to get them to link against the same C Runtime (which is damn hard to do)
[21:33] <yacc> jelmer: ping
[21:34] <jelmer> yacc: pong
[21:34] <yacc> Any progress?
[21:34] <yacc> Or a description of your clever idea?
[21:35] <yacc> I just pulled stable, and I'm getting still the assert exception.
[21:37] <yacc> jelmer: I'd be happy to help, but you claimed last night that you have a cool idea how to fix it in a backwards compatible way, ...
[21:39] <jelmer> yacc: not really in a backwards compatible way but in a way that makes older clients not able to retrieve the revision but not corrupt them either
[21:40] <jelmer> yacc: this problem only occurs for the single- branching scheme, which not a lot of people appear to be using
[21:40] <yacc> How can I switch the schema?
[21:40] <jelmer> yacc: see "bzr help svn-branching-scheme"
[21:41] <yacc> So by switching the schema I could avoid this AssertionError?
[21:41] <jelmer> yacc: the idea would be to start base64-ing the path in the single path branching scheme
[21:41] <jelmer> and look at for both the base64-encoded name and the non-base64 encoded name to be able to deal with older revisions
[21:41] <yacc> yeah, assuming that one does not work through http.
[21:42] <yacc> I'd presume that one cannot get at the non-base64 property through http anyway ;(
[21:42] <jelmer> yacc: yeah, that's correct
[21:42] <jelmer> it seemed possible at some point to set / in properties over http but not possible to retrieve them later
[21:42] <yacc> but to help prioritize my work, switching the schema would make the assert go away?
[21:44] <jelmer> Switching the scheme makes it impossible to push to your current branch in svn
[21:44] <yacc> jelmer: well, yeah, checking the "old" property name and converting it to the "new" property name would make sense to me.
[21:44] <yacc> Well, I have no current branch in svn ;)
[21:44] <jelmer> yacc: in that case, using a different branching scheme should be fine
[21:45] <yacc> That's stuff that has started it's life in bzr, I just need to push it so the rest of the devels working with svn see it.
[21:46] <yacc> So what other branching schema can I switch to?
[21:46] <jelmer> see "bzr help svn-branching-scheme" for details
[21:51] <yacc> Yeah, but I'm not completely grasping what options I do have. (I grasp the basic problem/idea, but I have no idea what over kind of schemes might make sense for me.
[21:52] <yacc> none/dir1/dir2/PackagePathWhereIPush
[21:52] <yacc> ?
[21:53] <jelmer> yacc: not sure I understand what you mean
[21:54] <yacc> Well, I've got a path something like that: trunk/logs/LookeryBase <= LookeryBase does not exist yet. Nobody is using branches inside svn (that would not make much sense you know, branches and svn in one sentence evoke pain)
[21:54] <jelmer> yacc: so, the branching scheme is basically list of branches inside the repository
[21:56] <yacc> No, actually, there are no branches, just trunk in the repository.
[21:56] <yacc> Now the bzr branch that I created locally, is "logically" part of the overall trunk of the svn repo.
[21:56] <jelmer> yacc: In that case, just put "trunk" as single line in the branching scheme
[21:57] <yacc> thanks.
[21:57] <jelmer> yacc: You can only push branches, you can't push into branches
[21:57] <yacc> Can I edit subversion.conf directly?
[21:57] <jelmer> yeah, sure
[21:57] <yacc> What do you mean by " You can only push branches, you can't push into branches"?
[21:58] <yacc> I fear we have a term-overloading going on here between svn branches and bzr branches.
[21:58] <jelmer> well, you can't push a bzr branch into /trunk/foo if you have /trunk as a branch
[21:58] <jelmer> you can only push it into /trunk
[22:00] <yacc> Well, I want to push my local bzr branch that has not yet any representation in the svn world, to /trunk/logs/LookeryBase ?
[22:00] <james_w> why don't you push to /branches/whatever?
[22:01] <yacc> james_w: because my bzr is logically not a branch, just a new package inside the logical svn trunk.
[22:01] <yacc> My whole bzr branch are basically "files to add to the svn trunk, in some subdirectory".
[22:01] <jelmer> yacc: in that case, /trnk/logs/LookeryBase is your branch in svn
[22:03] <yacc> Yeah, but where do I put that in subversion.conf?
[22:03] <yacc> Well, let me try it out.
[22:04]  * yacc was clever and created a complete throwaway https repo just for playing.
[22:09] <yacc> jelmer: http://rafb.net/p/ixuk7u60.html
[22:12] <yacc> Ok, setting the schema to None does not help either.
[22:28] <yacc> jelmer: list-xxxx does not help either :(
[22:38] <jelmer> re
[22:43] <jelmer> yacc: please try again with new 0.4
[22:53] <yacc> I just pulled from stable? Or do you mean something else?
[22:54] <yacc> jelmer: http://people.samba.org/bzr/jelmer/bzr-svn/stable/
[23:00] <jelmer> yacc: yeah, stable
[23:00] <jelmer> stable is a symlink to 0.4
[23:00] <jelmer> I loosened the assertion a little bit
[23:01] <yacc> Should list-XXXX include paths like /test, /test/, test or test/?
[23:02] <yacc> Basically do I need slashes at the start/end?
[23:08] <yacc> jelmer: still the assert error, with no scheme selected in subversion.conf
[23:08] <yacc> :(
[23:08] <jelmer> yacc: what version of the 0.4 branch are you using?
[23:08] <jelmer> yacc: No scheme selected?
[23:08] <jelmer> yacc: that probably means it's going to use the same scheme you were using earlier
[23:08] <jelmer> there is no such thing as no scheme..
[23:13] <yacc> jelmer:
[23:13] <yacc> Tree is up to date at revision 969.
[23:13] <yacc> no scheme:
[23:13] <yacc> [40f52546-0a3c-0410-aace-d8ec0cfe4f10]
[23:13] <yacc> locations =<EMAIL_ADDRESS>[23:14] <yacc> I just removed the repo completely from subversion.conf, and bzr-svn did not enter a scheme when it detected the repo.
[23:14] <jelmer> yacc: It still uses a branching scheme though
[23:15] <jelmer> yacc: try "bzr svn-branching-scheme <repo-url>"
[23:18] <yacc> andreas@andi-lap:~/lookery/lookery> bzr svn-branching-scheme<EMAIL_ADDRESS>[23:18] <yacc> andreas@andi-lap:~/lookery/lookery>
[23:18] <yacc> Funny thing, got lost in the paste.
[23:18] <yacc> the above outputs exactly two empty lines.
[23:20] <jelmer> yacc: in that case it will probably refuse to push anywhere
[23:21] <yacc> jelmer: yeah, but what should I do?
[23:23] <jelmer> yacc: You can change the branching scheme using the svn-branching-scheme subcommand
[23:23] <yacc> I've do I need to set the scheme myself?
[23:23] <yacc> To what?
[23:24] <yacc> trunk => would make only /krit/repo/ a branch that I can push to, which is wrong.
[23:25] <yacc> list-XXXX? I don't think it's meant this way, importing scheme.py and str(ListBranchingScheme(["path1", "path2"]))?
[23:26] <jelmer> yacc: Use bzr svn-branching-scheme --set <url>
[23:27] <yacc> What url should I provide?
[23:27] <yacc> http://host/repopath/pathinrepo?
[23:27] <jelmer> no, just the repo url
[23:28] <jelmer> in the editor that then opens you can list the paths in the repo bzr-svn should consider branches
[23:28] <Peng> Oh no!
[23:28] <jelmer> Peng: ?
[23:28] <Peng> Python has an official mirror of some of their svn branches in bzr two days after I do it myself.
[23:28] <Peng> http://www.python.org/dev/bazaar
[23:29] <jelmer> ooh, nice
[23:30] <yacc> jelmer: should I also list paths that I plan to use as a branch that do not exist yet?
[23:31] <jelmer> yacc: yes
[23:31] <yacc> jelmer: ok, new try ;(
[23:31] <yacc> still the assert error.
[23:31] <jelmer> yacc: what's the revno of stable you have?
[23:31] <Peng> Hmmm.
[23:32] <Peng> If those were done with bzr-svn, they have the same revids as my local conversion, right?
[23:32] <yacc> It updated to 970 now, before it was 969
[23:33] <yacc> jelmer: still the same.
[23:33] <yacc> :(
[23:33] <jelmer> Peng: Yep, should be
[23:33] <yacc> 7.861  adding branch dir 'testB'
[23:33] <yacc> 8.898  open dir 'lookery'
[23:33] <yacc> 8.898  open dir 'lookery/scripts'
[23:33] <yacc> 8.899  open file 'lookery/scripts/llfp.py'
[23:33] <yacc> 9.082  Traceback (most recent call last):
[23:33] <jelmer> yacc: Please try with 971
[23:33] <jelmer> that should print the property name that failed
[23:34] <yacc> :)
[23:34] <yacc> jelmer: I'm using a fresh path on each test, ...
[23:35] <yacc> you forgot %s
[23:35] <yacc> Now I get a TypeError:
[23:35] <yacc>     assert is_valid_property_name(prop), "Invalid property name" % prop
[23:35] <yacc> TypeError: not all arguments converted during string formatting
[23:35] <jelmer> ah, crap
[23:35] <jelmer> r972 :-)
[23:37] <yacc> AssertionError: Invalid property name 'bzr:revision-id:v3-single-test/lookery'
[23:37] <jelmer> yacc: Looks like you're still using a branching scheme with a single branch, i.e. the bit that's failing
[23:37] <yacc> Which is funny, because lookery is not even there in the path I'm trying to push to, guess it's a branch nick or something.
[23:37] <jelmer> yacc: please specify more than one path so it uses the list- one
[23:37] <yacc> I've specified 5 paths.
[23:38] <yacc> test9 .. testD
[23:38] <yacc> on seperate lines.
[23:38] <Peng> Yep, they do seem to have the same revids. Yay.
[23:38] <jelmer> yacc: and you're pushing to one of those?
[23:38] <yacc> branching-scheme = list-QlpoOTFBWSZTWdCduU8AAAzNgAAQACA8AAIADAAgACEkA0IMmIyavGI5DQ0eLuSKcKEhoTtyng..
[23:38] <yacc> yes.
[23:38] <Peng> I don't have to download the whole repo again then.
[23:38] <jelmer> yacc: what url are you pushing to?
[23:38] <jelmer> you're runinng something like "bzr push <repo-url>/test9" ?
[23:39] <yacc> I've put in testD and I'm pushing to<EMAIL_ADDRESS>[23:39] <yacc> svn-push
[23:39] <yacc> but yes.
[23:39] <yacc> leaving off the last slash does not help either.
[23:39] <jelmer> right, that shouldn't matter
[23:40] <yacc> AssertionError: Invalid property name 'bzr:revision-id:v3-single-test/lookery'
[23:40] <yacc> running bzr svn-branching-scheme on the URL gives the test9-testD lines, and one empty line at the end.
[23:42] <yacc> jelmer: would the Apache log help?
[23:42] <jelmer> yacc: no, that's not at all relevant
[23:43] <yacc> Well, bzr-svn did set branching-scheme-mandatory = True this time, ...
[23:43] <jelmer> yacc: I wonder what is setting that property since it doesn't appear to be related to your branching scheme
[23:43] <yacc> It looks like the nick of my bzr branch?
[23:43] <yacc> How can I check that?
[23:44] <yacc> The branch is in a directory named lookery.
[23:45] <yacc> jelmer, let's see what properties get added.
[23:45] <jelmer> yacc: it looks like it's thinking you're trying to push to test/lookery inside of the svn repository
[23:46] <yacc> http://rafb.net/p/l3S2si25.html
[23:46] <yacc> jelmer no such thing.
[23:47] <jelmer> yacc: I mean, in svn
[23:47] <jelmer> yacc: There doesn't happen to be a branch in svn with that name?
[23:48] <yacc> Yes there is.
[23:48] <yacc> But it's not a branch afaik.
[23:49] <yacc> andreas@andi-lap:~/lookery/lookery> svn ls https://heaven.kostyrka.org/krit/repo/test/lookery/
[23:49] <yacc> svn: PROPFIND Anfrage fehlgeschlagen auf »/krit/repo/!svn/bc/9/test/lookery«
[23:49] <yacc> svn: PROPFIND von »/krit/repo/!svn/bc/9/test/lookery«: 207 Multi-Status (https://heaven.kostyrka.org)
[23:49] <yacc> Now isn't that peachy?
[23:49] <yacc> Guess a svnadmin create would be now a good idea?
[23:49] <jelmer> yacc: right, that happens if a property is set once with a bad character in it
[23:50] <yacc> jelmer: yeah, but I'm not refering to /test/lookery at all.
[23:50] <yacc> I'm trying to push to /test?
[23:50] <yacc> Should I nuke the repo?
[23:50] <jelmer> yacc: it may still remember you had a revision there
[23:50] <yacc> Who would remember that?
[23:50] <jelmer> yacc: Yeah, I would recommend recreating it
[23:50] <yacc> bzr-svn?
[23:50] <jelmer> yacc: ~/.bazaar/svn-cache/
[23:51] <yacc> Well, I can try to nuke svn-cache first?
[23:51] <jelmer> sure
svn must be really quite fast. svk has an internal hidden cache too.</rant>
[23:53] <yacc> It pushes, it seems ;)
[23:53] <yacc> revision 2/6
[23:53] <yacc> 3/6
[23:53] <yacc> 4/6
[23:53] <Peng> Haha, bzr missing between two copies of Python's bzr branch took several minutes.
[23:53] <yacc> 5/6
[23:54] <yacc> Cool it worked :)
[23:54] <jelmer> Peng: yeah, I don't think it has been performance tuned yet
[23:54] <yacc> jelmer: btw, do I need to specify a password on the push URL, or does bzr-svn use the svn "password caching" mechanisms?
[23:55] <jelmer> yacc: it uses the svn password caching
[23:55] <Peng> jelmer: Wait, when bzr-svn switches to Pyrex, what will the build dependencies be?
[23:56] <jelmer> Peng: A C compiler and libsvn-dev
[23:56] <yacc> jelmer: what are you planning to use Pyrex (or probably Cython) for?
[23:57] <jelmer> yacc: for bzr-svn own python bindings of subversion
[23:57] <jelmer> yacc: rather than using python-subversion
[23:57] <yacc> jelmer: :)
[23:58] <yacc> jelmer: my experience suggests that you should probably prefer Cython over Pyrex, but beside that sounds like a plausible idea ;)
[23:59] <jelmer> yacc: cython generates larger files, which is why I prefer pyrexc as long as I don't need any of the features pyrex lacks
[23:59] <jelmer> so far it looks like both should work with the bzr-svn .pyx files though
[23:59] <yacc> jelmer: like a nice package support?


[18:13] <genii> http://loco.ubuntu.com/events/ubuntu-ca/3330-toronto-xenial-xerus-release-party/
[18:57] <azend|vps_> Hey genii
[18:57] <genii> Hiya azend|vps_ :)
[18:57] <genii> You guys doing a Saturday event after the Thursday release?
[21:40] <azend|vps_> genii: not that I know of
[21:40] <azend|vps_> Maybe in kw
[21:40] <azend|vps_> I've been out of that scene for a while now
[21:42]  * genii makes a note to bug Bob


[19:35] <pleia2> did someone here creat this? :) https://floss.social/@xubuntu
[19:35] <pleia2> create
[19:35] <bluesabre> It was me
[19:35] <pleia2> ok cool
[19:36] <bluesabre> I can send you the creds if you want them
[19:36] <pleia2> sure, and I can help get some of those profile links gree
[19:36] <pleia2> green
[19:36] <pleia2> wow, typing today
[19:36] <bluesabre> :D
[19:44] <pleia2> there, green!
[19:44] <pleia2> the trick is you have to remove the link from the profile and then add it again after the rel="me"
[19:47] <bluesabre> Oh, nice!
[19:47] <bluesabre> Add Mastodon Master to your list of titles
[19:52] <pleia2> lol


[02:51] <enrico> hornbeck: hei!
[02:51] <enrico> hornbeck: I'm about to read the mail: excited to see what happened
[03:31] <enrico> W.E.
[03:31] <enrico> M.I.G.R.A.T.E.D. ! ! !
[03:31] <enrico> W00T
[03:31] <enrico> W00T
[03:31] <enrico> W00T!
[05:25] <hornbeck> glad it went ok
[05:34] <enrico> yup!!
[08:15] <sivang> enrico: do you remember how to make nice colorful tables in the wiki?
[09:18] <enrico> sivang: I'd say just look at the source of ConferenceAgenda
[09:55] <sivang> enrico: yes right I noticed that
[09:55] <sivang> thanks anyway :)


[23:25] <teddy-dbear> I'mmm baaack!
[23:26] <teddy-dbear> did you miss me?
[23:26] <waltman> I just came back too!
[23:26] <teddy-dbear> did you even notice I was gone?
[23:27] <waltman> Sorry, I lost all my history when I rebooted.
[23:29] <waltman> during the storm my UPS decided the battery needed to be replaced, and decided to keep reminding me of this every few hours.
[23:29] <waltman> very loudly
[23:31] <rmg51> our power was out for about 24 hours
[23:31] <rmg51> came back on about an hour ago
[23:32] <waltman> Ugh. I never lost power, but had a lot of spikes.
[23:32] <waltman> It's unclear if I can get it to do another self test without pressing the power button, and it's also unclear if it still keeps feeding power to the devices when it's off.
[23:33] <waltman> But ubuntu had gotten itself into a weird state, so it seemed like a good time to reboot.
[23:40] <swift110> hey all
[23:47] <waltman> yo


[03:49] <[reed]> asac: um, NM is doubling my network interfaces
[09:29] <asac> [reed]: only 3G devices?
[09:29] <asac> oh intrepid?
[09:29] <asac> then its not NM, but udev and hal
[10:22] <asac> mconnor: so seems there is something public - finally: https://wiki.ubuntu.com/NotificationDesignGuidelines
[10:23] <asac> there also is https://wiki.ubuntu.com/NotifyOSD for the new notification daemon, but i guess only the design guidelines matter to you
[10:35] <gnomefreak> is gdm broken for anyone else?
[10:41] <asac> hmmm .... havent re-logged in
[10:41] <asac> gnomefreak: ask on -desktop
[10:41] <asac> ?
[10:42] <gnomefreak> i will im trying a few things but since gdm is crashing i doubt anythink else will help
[12:05] <fta2> dtchen, help! after a fresh upgrade (no ppa), i lost sound completely, p-a just sees a "null output" device. http://paste.ubuntu.com/120087/
[13:49] <fta2> d'oh
[13:49] <fta2> E: alsa-util.c: snd_pcm_avail_update() returned a value that is exceptionally large:<PHONE_NUMBER>5282159680 bytes<PHONE_NUMBER>87 ms) Most likely this is an ALSA driver bug. Please report this issue to the PulseAudio developers.
[13:49] <fta2> Soft CPU time limit exhausted, terminating.
[13:49] <fta2> Hard CPU time limit exhausted, terminating forcibly.
[13:49] <fta2> Abort
[13:57] <asac> fta2: are you using all defaults?
[14:02] <fta2> on this box, yes
[14:02] <BUGabundo> good afternoon everyone
[14:02] <BUGabundo> asac: I "accidently" removed NMs DHCP entrie
[14:02] <BUGabundo> I made a new one, but its not default anymore!
[14:02] <BUGabundo> how can I fix it?
[14:03]  * BUGabundo h@tes the new gwibber notifies popups for jaunty :(
[14:03] <asac> BUGabundo: best way is to go and remove the connection you dont want to connect to anymore
[14:03] <asac> BUGabundo: that will be fixed once archive admins push it through
[14:04] <asac> or use latest gwibber bzr
[14:04] <BUGabundo> I have the daily
[14:04] <BUGabundo> let me check for updates
[14:04] <BUGabundo> asac: but I have 4 connections in there
[14:05] <BUGabundo> I can't delete them all, just to make (manual) DHCP be the 1st
[14:06] <asac> BUGabundo: just disable autoconnect for the others
[14:07] <BUGabundo> ah
[14:07] <BUGabundo> but that also comes in handy when NM detects the same network
[14:09] <asac> BUGabundo: if its wireless and multiple APs withauto connect on are detected
[14:09] <asac> its supposed to connect to the last used
[14:09] <asac> if notits a bug
[14:09] <BUGabundo> its wired
[14:43] <BUGabundo> asac: I complain from having 300+ bugs
[14:43] <BUGabundo> but you have 1611         results
[14:43] <BUGabundo> xiiii
[14:46] <BUGabundo> oh come on
[14:46] <BUGabundo> there's a https://edge.launchpad.net/~canonical-smokers ?!?
[14:46] <BUGabundo> I bet gnomefreak is in it too
[14:46] <BUGabundo> smoke is bad... you guys should do your best to stop!
[15:01] <asac> BUGabundo: not sure what "bug" means ;)
[15:01] <asac> in this count
[15:01] <BUGabundo> eheh
[15:01] <BUGabundo> sub to....
[15:01] <BUGabundo> I guess
[15:01] <asac> i that the number of bugs still open that one has touched?
[15:01] <BUGabundo> as team or package manager
[15:02] <BUGabundo> AFAIK its bugs you are notified of
[15:02] <BUGabundo> I would think
[15:02] <asac> no i think its a bug you have touched or either are explicitly subscribed to
[15:03] <asac> and that is still open
[15:03] <asac> you can go to advanced search and search for all states and unhide duplicates
[15:03] <BUGabundo> ahh
[15:03] <BUGabundo> sure, it won't count dups
[15:09] <fta2> how can i enter a ♥ or a ♲ in gwibber??
[15:11] <asac> hehe
[15:12] <asac> ok i am out for a few hours running some errands
[16:15] <fta2> how come fta is not here?
[16:19] <BUGabundo> ahahahahahahahahahah
[16:19] <BUGabundo> DOA ?
[16:35] <fta2> i see no difference /wrt the notifications, is it supposed to be a new default that i missed or should I install something?
[16:46] <asac> fta2: notify-osd
[16:47] <asac> do you have that installed/running?
[16:48] <BUGabundo> I don't
[16:48] <BUGabundo> not even installed
[16:48] <BUGabundo> I didn't have ubuntu-desktop lol
[16:49] <BUGabundo> I thought I fixed that
[16:57] <fta2> asac, nope, should I
[16:59] <BUGabundo> hummm fta2 if it comes with ubuntu-desktop, yes
[17:00] <BUGabundo> fta2: gwibber DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name :1.86 was not provided by any .service files
[17:00] <BUGabundo> tells you anything?
[17:01] <fta2> nope, it's running fine here
[17:02] <fta2> but i only use identi.ca
[17:02] <BUGabundo> humm its running fine here too
[17:02] <BUGabundo> but it just crashed
[17:02] <BUGabundo> prob failed to parse something
[17:02] <BUGabundo> oh and you gonna "kill" me again
[17:02] <BUGabundo> I installed from bzr
[17:02] <BUGabundo> ehehe
[17:03] <BUGabundo> couldn't handle all those popups
[17:03] <BUGabundo> lets see if the next daily will run, or will I have to purge it
[17:11] <fta2> for me, it sometimes crashes when i start to write something but forget to submit it
[17:11] <BUGabundo> ehe
[17:12] <BUGabundo> mine tends to crash if I'm TOO FAST
[17:12] <BUGabundo> buffer bug
[17:12] <BUGabundo> ?
[18:05] <asac> ok ... out for another two hours or so.
[18:06] <asac> (again)
[18:06] <asac> cu later
[19:43] <fta> SEAMONKEY_2_0a3_RELEASE
[19:43] <fta> FIREFOX_3_0_7_BUILD2
[22:01] <ezzieyguywuf> i would like to write an extension for thunderbird but dont know where to start as far as documentation for developing for thunderbird. can anyone provide me with some resources?
[22:02] <BUGabundo> asac: ping
[22:02] <BUGabundo> are you around?
[22:02] <BUGabundo> would like to discuss something with you, before emailing -discuss ML
[22:03] <ezzieyguywuf> any help guys?
[22:04] <BUGabundo> ezzieyguywuf: this is a calm time now
[22:05] <ezzieyguywuf> ok
[22:05] <BUGabundo> please email the mozilla team ML
[22:05] <BUGabundo> if you can't stay around
[22:23] <BUGabundo> fta2: is this that you see https://bugs.edge.launchpad.net/gwibber/+bug/331805
[22:26] <fta2> ahh, at last!
[22:26] <fta> :)
[22:27] <BUGabundo> yay
[22:27] <fta> power down, my whole office, probably a fried fuse
[22:27] <BUGabundo> you got your clone back
[22:27] <BUGabundo> fta2: is this that you see https://bugs.edge.launchpad.net/gwibber/+bug/331805
[22:27] <fta> caused by the power adapter of my laptop
[22:27] <BUGabundo> ahah... really lucky then
[22:28] <fta> no idea if it's a fuse, the plug in the wall is dead
[22:28] <fta> i had to recable everything
[22:28] <fta> and fsck all the disks in my desktop :P
[22:29] <fta2> ++
[22:29] <fta> so, what about gwibber?
[22:32] <BUGabundo> ehe
[22:32] <BUGabundo> fta2: is this that you see https://bugs.edge.launchpad.net/gwibber/+bug/331805
[22:32] <BUGabundo> for the 3rd time
[22:32] <BUGabundo> humm you burned the wall socket with the power adpatar?
[22:32] <fta> sorry, i'm still booting all my stuff
[22:32] <fta> yes
[22:32] <BUGabundo> damn... what does it use ? lolol
[22:32] <BUGabundo> np, just kidding
[22:33] <BUGabundo> take most of what I say with an hand of salt (joke)
[22:33] <fta> donno what happened, the laptop was fine in another room, i move it close to my desktop, plugged the power, boom, everything dead
[22:34] <fta> checked everything, the wall socket is dead
[22:34] <BUGabundo> yeah
[22:34] <fta> tried the power module in another plug, huge spark
[22:34] <BUGabundo> be carful
[22:34] <BUGabundo> those can hurt you if you don't know what u are doing
[22:34] <BUGabundo> I have some experience with it
[22:35] <BUGabundo> my dad is an electritian
[22:36] <fta> i'm an engineering in electronics ;)
[22:36] <fta> and in advanced CS too btw
[22:36] <fta> but i hate electronics
[22:37] <fta> BUGabundo, nope, never experienced 331805
[22:37] <BUGabundo> yeah
[22:38] <BUGabundo> I was 4 years in university on Computer Electronics and Electricity
[22:38] <BUGabundo> but then changed to computer science eng
[22:39] <BUGabundo> had my last exam today (SGRAI = OpenGL)
[22:43] <fta> when i was still at school, opengl was in its infancy, i used GL a bit on Irix, i never used openGL
[22:44] <BUGabundo> I really don't enjoy it
[22:44] <BUGabundo> I know its trully powerfull
[22:45] <BUGabundo> I made an homer go around in the world
[22:45] <BUGabundo> LOL
[22:45] <fta> eh?
[22:45] <BUGabundo> but I don't enjoy coding all that much
[22:47] <fta> i only enjoy it when it's for myself, that includes opensource
[22:48] <BUGabundo> yeah
[22:48] <BUGabundo> I understand
[22:48] <BUGabundo> the power to do it yourself
[22:48] <BUGabundo> improve stuff that you need / like
[22:54] <asac> BUGabundo: what discussion?
[22:54] <BUGabundo> ah??
[22:54] <BUGabundo> asac: ahhh now I remmember what
[22:54] <BUGabundo> lol
[22:54]  * BUGabundo has really bad memory
[22:55] <asac> as long as you have remembory its ok ;)
[22:55] <BUGabundo> what would you say to a proposal of having some of the packages that are on PPA, from CoreDevs on Universe?
[22:55] <BUGabundo> during devel period
[22:55] <BUGabundo> and who knows even after release
[22:55] <BUGabundo> but with a diff name
[22:55] <BUGabundo> pic NM
[22:55] <BUGabundo> stable branch on Main
[22:56] <asac> i dont see the benefit ;)
[22:56] <BUGabundo> and a replacble version (maybe NM-dev or something) on universe
[22:56] <asac> why would you want to do that?
[22:56] <BUGabundo> two things
[22:56] <BUGabundo> mirroring from archive mirrors (PPAs are not mirrored)
[22:57] <BUGabundo> and having easy access to users, without adding PPAs
[22:57] <asac> i dont buy any of those
[22:57] <asac> i mean mirroring is not a problem
[22:57] <asac> i doubt that there is any significant load/bottleneck in bandwidth
[22:58] <asac> and coredevs would put their stuff in archive instead of PPA if they would consider it ready for broader distribution
[22:58] <BUGabundo> humm I do notice it
[22:58] <BUGabundo> my local/national mirrors are way faster
[22:58] <asac> yes, but even if there is a bottleneck in bandwidth ;) ... there are many approaches besides from puttin it into the universe
[22:59] <asac> ask your mirror to mirror popular PPAs ;)
[23:00] <asac> but the important part is really, that when i put stuff into PPA, I dont want it in the archive
[23:00] <asac> one main usecase is obviously backports
[23:01] <asac> there is ubuntu-backports, but what i understood a few dont like to enable backports
[23:01] <asac> hence i use PPAs
[23:01] <asac> maybe thats the wrong approach though
[23:01] <asac> let me relogin
[23:01] <asac> a minute
[23:02] <BUGabundo> I enable backports
[23:03] <BUGabundo> but I don't for proposed
[23:03] <BUGabundo> and that's what I say on my FOSS class...
[23:03] <BUGabundo> by the away new ones start 7 of march
[23:03] <BUGabundo> yay
[23:06] <asac> BUGabundo: ok the notification things are now fixed in latest nm-applet from today
[23:06] <asac> gwibber probably takes another day
[23:07] <asac> ask the gwibber team to update their ppa ;)
[23:07] <BUGabundo> using trunk seems to fix it
[23:07] <asac> yeah
[23:07] <asac> it landed everywhere
[23:07] <BUGabundo> and ppl are complaining about NM lolol
[23:08] <BUGabundo> now I just miss exaile, firefox, and pidgin, kmail, and im done
[23:08] <BUGabundo> LOL
[23:08] <asac> firefox?
[23:08] <BUGabundo> basicly that what I use
[23:08] <asac> firefox should be fine
[23:08] <BUGabundo> plus a few bt clients
[23:08] <asac> firefox will still keep its own thing
[23:08] <BUGabundo> humm haven't seen any FF show up in there
[23:08] <BUGabundo> ahh ok
[23:09] <asac> BUGabundo: interesting that people complain a lot ... i wanted t close a bug on upload and had to file one,  because there was non reported
[23:09] <asac> so i didnt really get many complains ;)
[23:09] <BUGabundo> LOL
[23:09] <BUGabundo> yah
[23:09] <asac> but well. most dont upgrade daily if they run jaunty
[23:09] <BUGabundo> ppl talk much do little
[23:09] <asac> too much disruption
[23:09] <asac> more like once a week
[23:09] <BUGabundo> hey, I can't open any more bugs
[23:09] <asac> and especially not short before FF ;)
[23:09] <asac> where everything goes in
[23:09] <BUGabundo> I do it 2/4 times a day
[23:09] <asac> thats ok
[23:10] <asac> i dont need many bugs.
[23:10] <asac> just the most important ones ;)
[23:10] <BUGabundo> I love to see coments from ppl saying " hay 200 MiBs of updates"
[23:10] <BUGabundo> eehe
[23:10] <BUGabundo> I get way more!
[23:10] <BUGabundo> btw I haven YET received a single email over the NM bug mail
[23:10] <BUGabundo> strange!
[23:10] <BUGabundo> thought it would be more
[23:10] <asac> what did you do?
[23:11] <asac> subscribed to nm?
[23:12] <asac>  BUGabundo you seem to be not subscribed to the package
[23:13] <asac> BUGabundo: look in 47379
[23:13] <asac> you should be in the "Also notified" list
[23:13] <asac> thats who is subscribed in general mostly
[23:13] <BUGabundo> yeah
[23:13] <BUGabundo> I subs to the team bug mail
[23:13]  * BUGabundo checks to be sure
[23:13] <BUGabundo> not the package it self
[23:13] <asac> BUGabundo: yeah thats not it
[23:13] <asac> go to the bugs page
[23:13] <BUGabundo> yeah
[23:13] <asac> and subscribe
[23:13] <BUGabundo> now I get it
[23:14] <asac> https://bugs.edge.launchpad.net/ubuntu/+source/network-manager/
[23:14] <asac> there is "subscribe to bugmail"
[23:14] <asac> https://bugs.edge.launchpad.net/ubuntu/+source/network-manager/+subscribe
[23:14] <BUGabundo> shouldn't the team be subs to bug mail of the package?
[23:14] <asac> no please not
[23:14] <asac> thats good as it is ;)
[23:14] <BUGabundo> DONE
[23:15] <asac> https://bugs.edge.launchpad.net/ubuntu/+source/network-manager-applet
[23:15] <asac> https://bugs.edge.launchpad.net/ubuntu/+source/network-manager-openvpn/+subscribe
[23:15] <asac> https://bugs.edge.launchpad.net/ubuntu/+source/network-manager-pptp
[23:15] <asac> https://bugs.edge.launchpad.net/ubuntu/+source/network-manager-vpnc
[23:15] <BUGabundo> see team was easier
[23:15] <BUGabundo> LOL
[23:16] <asac> well ... better not force that on team members
[23:16] <asac> should be opt in what everyone likes
[23:17] <BUGabundo> 4x DONE
[23:18] <asac> welcome
[23:19] <asac> i think its more effective to use website and do like
[23:19] <asac> 1 day New processing
[23:19] <asac> 1 day incomplete
[23:19] <asac> 1 day confirmed
[23:19] <BUGabundo> humm I use email a lot
[23:19] <asac> or something
[23:19] <BUGabundo> and started to learn the LP api
[23:19] <asac> well ... problem is that if you have too many bugs combined with bad memory
[23:19] <BUGabundo> so maybe I can get a few stuff on queue for when I'm offline
[23:19] <asac> you will not get anything done ;)
[23:19] <BUGabundo> most of my day...
[23:19] <asac> just mail that causes more mail and so on ;)
[23:20] <asac> going through new mail list is much more efficient ;)
[23:20] <asac> personal work style dependent of course
[23:20] <asac> you could also use mail and focus on like 20 bugs
[23:20] <asac> and then finish them and go for another ;)
[23:20] <asac> but i cannot do that
[23:21] <BUGabundo> let me see how it goes
[23:21] <asac> for me that would require some more advanced bug flow tool
[23:21] <BUGabundo> if I can't handle it, I just leave you with more work
[23:21] <BUGabundo> lol
[23:21] <asac> yes
[23:21] <asac> i just want to prevent traffic without moving forward ;)
[23:21] <BUGabundo> and the API could be fun
[23:21] <asac> you can do whatever you want of course
[23:21] <BUGabundo> I have to test with it a but
[23:21] <BUGabundo> *bit
[23:22] <asac> just try to remember what i said so you know what to do when you think things are not moving as quick as they could ;)
[23:22] <asac> sure
[23:23] <asac> BUGabundo: so the ideal mix is like dong the website style batches like i said regularly
[23:23] <asac> and if there ar ebugs that you are interested in particular you subscribe and filter that mail to a higher prio mailbox
[23:23] <asac> so you get quicker turnarounds
[23:23] <BUGabundo> yeah
[23:23] <fta> i just updated the gwibber-team ppa with 0.8
[23:24] <BUGabundo> wasn't it 1.0?
[23:24] <asac> so you can combine the "focus on 20 bugs" with the "bug triaging by states on website"
[23:24] <asac> fta: thanks
[23:24] <asac> that was much needed
[23:24] <fta> BUGabundo, nope, there's no such thing as 1.0
[23:24] <dtchen> fta: the error that you pasted WRT 0.9.14 means hw:0 couldn't be opened. Are the sound drivers loaded? Is your user in the audio group?
[23:25] <fta> dtchen, this problem disappeared by itself
[23:25] <dtchen> mmkay
[23:26] <asac> fta: did you upload to jaunty ppa?
[23:26] <fta> dtchen, it started after today's massive update + a reboot
[23:26] <asac> i think i still have intrepid url in there
[23:26] <asac> can i update tat to jaunty?
[23:26] <fta> asac, yes, why not?
[23:27] <fta> i'm using gwibber-daily btw
[23:27] <asac> not sure ... i think when i added that jcastro said they had no jaunty
[23:27] <asac> fta: i got bzr 200
[23:27] <asac> thats probably outdated?
[23:27] <fta> https://edge.launchpad.net/~gwibber-team/+archive/ppa
[23:28] <BUGabundo> yeah asac
[23:28] <BUGabundo> im on 245
[23:29] <asac> probably wait till its build then
[23:29] <asac> me
[23:29] <asac> ok taking a break
[23:34] <BUGabundo> fta: will the jaunty gwibber be kept in sync with PPA?
[23:35] <fta> yes, all my stuff are in sync, whatever PPA combination you may have, the best version wins, that's it.
[23:36] <BUGabundo> yeah
[23:36] <BUGabundo> ill keep daily, plus ocassional bzr trunk for quick fix
[23:37] <fta> why bzr trunk? can't you wait 24h max?
[23:37] <BUGabundo> example: todays annoying bug with popups: answer: NO
[23:37] <fta> there's a problem with the dailies though, the version is lower than 0.8 :( upstream should bump the version in trunk
[23:38] <BUGabundo> humm????
[23:38] <fta> 0.8~bzr < 0.8
[23:39] <fta> trunk should be 0.8.1 or 0.9 or whatever > 0.8
[23:40] <BUGabundo> ah
[23:40] <BUGabundo> but why?
[23:40] <fta> to be ahead
[23:40] <fta> according to apt
[23:41] <BUGabundo> so bzr trunk _should_ be ahead of package versions
[23:41] <fta> once 0.8 is in universe, the daily ppa will be useless, as versions will be lower
[23:41] <BUGabundo> is that it?
[23:42] <fta> yes
[23:42] <BUGabundo> ok got it
[23:42] <BUGabundo> have you let know them that?
[23:42] <BUGabundo> do you want me to email/file a bug about that?
[23:42] <BUGabundo> or ping guys on #gwibber irc #?
[23:42] <fta> i asked oldmanuk already, nada
[23:43] <fta> i'm not on their network, i should probably file a bug
[23:45] <BUGabundo> sub me to it when you do
[23:46] <fta> gnome-do 0.8.1~trunk+r1005-0~8.10~ppa1  yeah, funny version
[23:46] <fta> open-vm-tools 2008.08.08-109361-1ubuntu2.2~andersk4 lol
[23:46] <BUGabundo> hehe
[23:47] <fta> network-manager-applet 0.7.1~rc1+20090219+bzr974-0ubuntu1 :)
[23:48] <asac> fta: heh :) ... yeah i took 0.7.1~rc1 + 1 commit
[23:50] <BUGabundo> http://www.funtasticus.com/20090219/t-shirts-can-tell-you-important-stuff/
[23:50] <BUGabundo> ROFL
[23:51] <asac> slow
[23:53] <BUGabundo> time to hit the sack! see you guys (and galls if any around) tomorrow. don't you ever sleep? its late on your timezone
[23:54] <asac> heh
[23:54] <asac> cu
[23:54] <asac> ill sleep soonish


[01:07] <djst> BenC: hello. do you know if there are any plans on including the shfs module in the kernel?
[01:07] <djst> currently, you need to compile it yourself using module-assistant, and it's a bit buggy
[01:07] <djst> (Fabio told me to ping you about this, but he warned me that you had connection problems today)
[01:09] <zul> heylo
[11:09] <CataEnry> hi
[02:39] <zul> heylo
[02:56] <CataEnry> hi all :)
[07:21] <zul> i love fire alarms
[11:19] <lamont> hrm... what is the least-crackful, currently-purchasable-retail, 802.11 card for breezy?
[11:21] <lamont> BenC: ?? ^^
[11:21] <lamont> mjg59 - you laptop god you?
[11:22] <mjg59> lamont: Uhm. No real idea.
[11:22] <lamont> feh.
[11:22] <mjg59> The best supported laptop stuff is probably Intel kit, and that's not available in anything other than minipci


[12:53] <studio-user266> hey
[14:06] <d1g1t4Lnrg> hello
[14:07] <d1g1t4Lnrg> anyone know the command from terminal for the shotwell install?
[14:08] <d1g1t4Lnrg> using ubuntu studio 16.04
[14:10] <d1g1t4Lnrg> Anyone here?
[16:44] <maenk> hello, could someone tell me, does Ubuntu Studio offer support for Sound Blaster ZxR sound cards?
[16:48] <zequence> maenk: Ubuntu Studio itself does not offer any support for sound devices. That is done by ALSA for PCI and USB
[16:48] <zequence> ffado for Firewire
[16:49] <zequence> Ubuntu Studio is a distribution of packages. We don't actually develop the software in the packages (except for a very few)
[16:53] <maenk> all right, i guess that explains my question, thank you :) I was looking to transfer to linux as I've always enjoyed it in the past but my sound card is pulling me back