 https://www.reddit.com/r/kde/comments/dus5sn/janayugom_the_south_indian_daily_newspaper_has/
 Big Daddy linux are doing Kubuntu as their distro challenge this week. They have asked if anyone from Kubuntu will be available to go on their live streem on Saturday?
 (a) I don't do livestream appearences, (b) it will be about 2am UK time, and (c) I DON'T DO LIVE STREAM APPEARENCES!
 so maybe someone US side can?
 I can't
 @Valoriez
[20:25] <valorie> Saturday? I'll be at SeaGL
 Yep, I can do it
 Who do I need to be put InTouch with at Big Daddy


[09:39] <mup> Bug # changed: 1685619, 1782035, 1789648, 1811234
[09:42] <mup> Bug # opened: 1685619, 1782035, 1789648, 1811234
[09:45] <mup> Bug # changed: 1685619, 1782035, 1789648, 1811234
[09:48] <mup> Bug #1821694 changed: MAAS should alert the user if a needed power driver is missing <MAAS:Invalid> <https://launchpad.net/bugs/1821694>
[09:54] <mup> Bug #1821694 opened: MAAS should alert the user if a needed power driver is missing <MAAS:Invalid> <https://launchpad.net/bugs/1821694>
[09:57] <mup> Bug #1821694 changed: MAAS should alert the user if a needed power driver is missing <MAAS:Invalid> <https://launchpad.net/bugs/1821694>
[10:00] <mup> Bug #1821694 opened: MAAS should alert the user if a needed power driver is missing <MAAS:Invalid> <https://launchpad.net/bugs/1821694>
[10:03] <mup> Bug #1821694 changed: MAAS should alert the user if a needed power driver is missing <MAAS:Invalid> <https://launchpad.net/bugs/1821694>
[10:09] <mup> Bug # changed: 1825053, 1826277, 1836404, 1841499
[10:12] <mup> Bug # opened: 1825053, 1826277, 1836404, 1841499
[10:18] <mup> Bug # changed: 1825053, 1826277, 1836404, 1841499


[09:30] <czajkowski> wgrant: you about ? having issues logging into LP :( keeps asking for 2FA device, but none associated wiht my account
[09:30] <wgrant> czajkowski: That's an SSO issue. #canonical-sysadmin are the best people to sort it out.
[09:31] <czajkowski> bah
[09:32] <czajkowski> wgrant: cheers
[09:32] <cjwatson> czajkowski: You probably need to ask a sysadmin to remove you from the ~sso-2f-testers team.
[09:33] <czajkowski> cjwatson: I could have sworn I was
[09:33] <czajkowski> was able to log in fine up to recently
[09:34] <cjwatson> czajkowski: I believe that the SSO configuration changed recently so that anyone in that team has 2FA forced
[09:34] <cjwatson> But at any rate you definitely shouldn't be in that team if you don't have a second factor available.
[09:35] <czajkowski> cjwatson: cheers
[10:25] <Robe> I was wondering - is it possible to build directly from a public git repo or do I always have to go through the debuild -S && dput route?
[10:28] <cjwatson> Robe: We hope to have recipe support soonish, but it's not available yet.
[10:28] <cjwatson> (So, for now, the latter)
[10:28] <Robe> thanks! :)
[10:29] <Robe> recipes are things that are run before a build to prepare the source artefacts?
[10:29] <cjwatson> https://help.launchpad.net/Packaging/SourceBuilds/Recipes
[10:30] <cjwatson> A way to automatically build source packages from (currently only) Bazaar branches
[10:33] <Robe> ahh
[10:33] <Robe> still new to the whole ubuntu shebang
[10:33] <Robe> avid debian user
[10:39] <cjwatson> They're certainly not mutually exclusive :-)
[12:40] <Robe> cjwatson: heh, totally
[12:40] <Robe> cjwatson: and I dig the build infra, it's a boon
[23:30] <mapreri> "For a bug to have several thousands duplicates is normal." well...
[23:31] <wgrant> Damn, those bugs must be hiding from the database :(
[23:32] <wgrant> I'm glad our users have a better view of our dataset than our database.
[23:36] <cjwatson> what do the top 10 or so look like?
[23:36] <wgrant> There are about 10 bugs with more than 200 duplicates.
[23:36] <wgrant> One has more than 1000, and it's the bug in question.
[23:37] <cjwatson> those bugs are kind of perpendicular if you plot them as a histogram.
[23:37] <cjwatson> so you could argue that they're normal in that sense.
[23:37] <wgrant> Heh
[23:38] <mapreri> lol
[23:42] <wgrant> I also really wish people's response to timeouts wasn't "let's retry it twice a second".
[23:42] <wgrant> "for 6 hours"
[23:42] <wgrant> "and then whine in bugs when other things relating to the bug you're taking hundreds of locks on isn't working"


[00:38] <sarnold> nicoz: you know it :D I'm always preaching the "a low end vm in a datacenter is pretty cheap and reliable" gospel to any who will listen :)
[02:35] <Unit193> sarnold: https://www.vultr.com/pricing/ those micro ones. :3
[02:36] <sarnold> Unit193: yes!   I knew about the latter, but neat.
[02:41] <Unit193> ...OK I've gotten side tracked.
[02:45] <sarnold> $372/mo for their silliest :) heh
[02:58] <leftyfb> I prefer containers on my own physical in-house servers :)
[02:59] <sarnold> i still haven't gotten around to containers yet
[02:59] <sarnold> some day
[02:59] <leftyfb> Just picked up another R620 which will be a mirror for the one running everything at the moment. I'll do periodic snapshots of the containers nightly
[02:59] <leftyfb> love me some lxd
[03:00] <leftyfb> yesterday setup a full lab environment to test out some deployment code. Got a router and "metal" server providing DHCP and DNS and containers on that "metal" container for the deployments just like we do in the field
[03:01] <leftyfb> lxc launch ubuntu:22.04 new-server
[03:01] <leftyfb> that's it
[03:01] <leftyfb> then mess with lxd bridges and profiles if you need to do the fancy stuff I was doing
[03:03] <leftyfb> lxc list # to list your servers and lxc shell <server> # to bootstrap it with ssh and such. OR do what I do and use ansible to create, bootstrap and deploy everything to it in a matter of minutes
[03:04] <sarnold> that's so cool
[03:05] <Unit193> Never used lxd, but I have lxc for autopkgtests.
[03:05] <leftyfb> lxd is better for managing multiple containers and allows more orchestration
[03:06] <leftyfb> you can also create and manage kvm/qemu vm's with lxd
[03:07] <Unit193> Oh dang, it's actually in the repos.  Huh.
[03:07] <leftyfb> I just set that up for our support engineers. They're all still running 18.04 because they need to support customers on older versions. But I wrote an ansible playbook to spin up the 20.04 VM, copy over all their keys and creds and runs a full engineer deployments on it
[03:08] <leftyfb> Unit193: lxd is snap only btw
[03:08] <Unit193> !info lxd unstable
[03:08] <sarnold> \o/
[03:09] <leftyfb> I can't believe you guys haven't messed with lxd. It's trivial and so easy to spin one up for quick tests and then just stop it or delete it if needed
[03:09] <sarnold> "messed with', a bit, yeah
[03:09] <leftyfb> it's how I check package versions and such on releases I'm not running all the time to help in #u
[03:10] <sarnold> well, okay, lxc list just now is taking its sweet time.. I think I've got one for every supported release, and some of them have esm configured, etc
[03:10] <sarnold> oh i've got debians going too
[03:10] <leftyfb> oh man, are they all running?
[03:10] <sarnold> no, all stopped right now
[03:11] <leftyfb> how many you got?
[03:11] <sarnold> but they're all so cheap that I often forget I start them, and I might at some point wonder why i've a thousand processes running
[03:11] <sarnold> 12
[03:11] <leftyfb> lol
[03:11] <leftyfb> I wouldn't call that "haven't gotten around to containers yet" :)
[03:12] <sarnold> well, some folks really live and breathe containers, organizae their entire workloads in them, orchestrate them together, etc..
[03:12] <leftyfb> that's sort of me
[03:12] <sarnold> I just have a few sitting around for easy question answering, like yours
[03:12] <leftyfb> though we're going to be moving to ESXi at some point in the near future. Gotta rewrite all my ansible for that next
[03:12] <sarnold> but no ansibles to create and configure them on a whim, etc
[03:12] <sarnold> aww ;(
[03:13] <sarnold> I thought with the broadcom aquisition everyone was moving *away* from esxi
[03:13] <leftyfb> yeah, they need HA and support
[03:13] <leftyfb> hm
[03:14] <leftyfb> didn't know about this
[03:14] <sarnold> ah, I dunno about lxd's HA, but I wouldn't be shocked if esxi has *better* HA regardless
[03:14] <sarnold> another 15 years on the market will do that :)
[03:14] <leftyfb> lxd's sort of have HA but it takes a bit of work
[03:15] <leftyfb> you need to strap on some other pieces to do the heavy lifting
[03:15] <sarnold> broadcom has a history, as it were .. https://www.techtarget.com/searchdatacenter/news/252521669/Broadcoms-acquire-and-axe-history-concerns-VMware-users
[03:18] <leftyfb> welp, I was waiting for "smee" to come back but apparently it take multiple hours to install a single package. I can't wait any longer
[03:18] <leftyfb> cyas
[03:19] <sarnold> gnight leftyfb ;)


[12:18] <tristanbob> I'll always be around with Ubuntu - and documentation is one of the ways that I can contribute
[12:18] <tristanbob> that and advocacy
[12:18] <mdke> go for it!
[12:18] <mdke> feel free to dive into our repository too :)
[12:20] <tristanbob> mdke: I can't seem to join the wiki team myself
[12:20] <mdke> you can apply
[12:21] <tristanbob> looks like I was a member and then left, now I don't get the option to apply again
[12:23] <mdke> tristanbob: really?
[12:24] <mdke> ok, reactivated
[12:25] <tristanbob> thanks mdke
[02:45] <robotgee1> nixternal: sorry, i havent been able to do any work on the kubuntu docs
[02:46] <nixternal> that's alright, I have been working little by little, but I have been tied up with some KDE Docs and KHelpCenter
[02:47] <robotgeek> nixternal: work + school is leaving me no time at all, i think i should officially take a hiatus
[02:47] <nixternal> hehe
[02:47] <nixternal> i hear you there
[02:47] <nixternal> school starts back up next week
[02:47] <nixternal> 20 credits, so i will be pretty busy as well
[02:48] <robotgeek> i only have 9, but i got to study (an almost entirely new area) for me, so that is a time sucker
[02:48] <robotgeek> i had lots of time when i was doing research, lol
[02:48] <nixternal> ya, i have anthropology and philosophy this semester and both of them are new to me as well
[02:48] <nixternal> ya, most of my classes are research and field based this time around
[02:49] <nixternal> those will be fairly easy, since i use some of the stuff i do here as field based
[02:49] <robotgeek> i dont want to leave the teams, but i dont want to give the impression that i will get anything done
[02:52] <nixternal> well, jsgotangco is on a hiatus now, and checks in every now and then
[02:53] <nixternal> mgalvin took a little break, it happens, everyone needs a break every now and then
[02:53] <nixternal> everytime i start to burn out a little bit i get involved with something new to respark my interest
[02:53] <robotgeek> yeah, i will keep checking back in, hopefully i will start back work during summer
[02:54] <robotgeek> i already spend > 14 hours in front of the computer, it doesn't feel very nice to work after that :P
[02:54] <nixternal> hehe, i definitely know that feeling
[02:56] <crimsun> now imagine what I go through.
[02:56] <nixternal> no doubt, you spend 26 hours a day on the computer
[02:56] <crimsun> closer to 76, it feels like
[02:56] <robotgeek> i am a mere mortal, crimsun :)
[02:56] <crimsun> robotgeek: I'm not even a mortal; I'm a peon.
[02:57] <robotgeek> anyways, i gotta run. maybe catch some extra sleep for tomorrow
[02:57] <robotgeek> later guys!
[02:57] <crimsun> cya
[02:58] <nixternal> later
[03:07] <glatzor> ping mdke
[03:07] <glatzor> mdke: do you know when there will be a new version of the translated edgy documentation?
[05:10] <willvdl> hi folks, https://help.ubuntu.com/community/ThinClients refers ti EdubuntuInstallNotes which is blank..
[08:36] <mdke> glatzor: none planned atm. You think it would be advisable?
[08:37] <glatzor> mdke: for sure. it was quite an effort to translate the desktop guide.
[08:38] <glatzor> mdke: and the end of edgy comes nearer every day.
[08:38] <mdke> glatzor: well, not the "end" :) But sure, we'll consider it then
[08:39] <mdke> glatzor: do you know if all those errors were fixed?
[08:41] <glatzor> mdke: wait, I will check it.
[08:42] <mdke> I don't know if we should update it on a per-language basis, or for all languages
[08:46] <glatzor> mdke: are there any other languages that made good progress?
[08:46] <glatzor> you could drop a mail to ubuntu.translators which teams would like to see a release
[08:47] <glatzor> mdke: the bugs don't affect the desktop guide. and I am sorry, but I don't have the patience to fix typos at the moment.
[08:47] <mdke> glatzor: I meant the validation errors...
[08:47] <glatzor> mdke: I could do this at Sunday.
[08:48] <glatzor> mdke: http://files.glatzor.de/dg/desktopguide/de/
[08:48] <mdke> that sounds like a yes
[08:49] <glatzor> I haven't build it in the last three weeks or so.
[08:50] <glatzor> But we only fixed minor typos in this phase.
[08:53] <mdke> glatzor: ok, good job
[08:55] <mdke> nixternal: our policy until now has been to avoid using xrefflags
[09:09] <nixternal> why is that?
[09:09] <nixternal> they work great for linking w/o getting the 'the section blah blah'
[09:14] <nixternal> mdke: do you recommend using <link linkend='blah'>Blah</link> isntead?
[09:39] <mdke> nixternal: you should use xref, I think
[09:39] <mdke> what's wrong with "the section"?
[09:39] <nixternal> i don't want the words "the section" for some of the links im doing
[09:40] <mdke> nixternal: why?
[09:40] <nixternal> because im using htem in a list, to link to another section w/in the document
[09:41] <nixternal> they are fine when using the "See <xref linkend="blah"/>"
[09:41] <mpt> nixternal, actually, I don't think "the section" is ever appropriate
[09:41] <mpt> so maybe report a bug asking for it to be removed
[09:41] <nixternal> i have no problem rewording the document though to make them work in order to follow along with the policy though
[09:41] <mdke> mpt: in Kubuntu, he can remove it himself
[09:41] <mpt> cool
[09:42] <mdke> in the build stage
[09:42] <mdke> nixternal: tbh, I can't remember the reason that we decided to avoid them. I bet there was a really good one though
[09:42] <mdke> we never take wrong decisions
[09:42] <mdke> >_>
[09:42] <mdke> <+<
[09:42] <nixternal> hehe
[09:42] <nixternal> lol
[09:42] <mpt> We just take circuitous routes to victory
[09:42] <LaserJock> that's right
[09:42] <nixternal> couldn't have said it better myself
[09:43] <nixternal> i will go through and doctor them up, there is a still a "TON" of work to do in that section
[09:43] <nixternal> i scoured the forums (Ubuntu & Kubuntu), the wiki, and used strigi on my lists to come up with an entire list of questions
[09:43] <LaserJock> I dislike those "the section" things
[09:43] <LaserJock> I'd rather use my own wording
[09:44] <nixternal> same here LaserJock
[09:44] <nixternal> anybody want to take a couple of sections of the Kubuntu TBH :)
[09:44] <LaserJock> TBH?
[09:44] <mdke> nixternal: i will look through the archive because I'm curious now
[09:45] <mdke> LaserJock: can you remember?
[09:45] <mdke> LaserJock: iirc, it was in relation to the packaging guide that it came up
[09:45] <LaserJock> which topic?
[09:45] <mdke> LaserJock: xreflabels v. no xreflabels
[09:45] <LaserJock> why we went to xrefs instead of linend or something
[09:46] <LaserJock> oh, well it was because of translatablility
[09:46] <mdke> OH YEAH!
[09:46] <LaserJock> because the labels are in the tag
[09:46] <mdke> I KNEW IT!
[09:46] <mdke> always a good reason
[09:46] <mdke> LaserJock: you're a genius, nice one
[09:46] <LaserJock> but I'd rather it default to putting no lanuguage in
[09:47] <LaserJock> heh, I'm surprised my brain coughed that one up ;-)
[09:47] <LaserJock> now where did my pen go ...
[09:47] <mdke> the absent minded genius...
[09:47] <LaserJock> yeah
[09:47] <LaserJock> I got the absent minded professor thing down really well
[09:48] <LaserJock> Quantum Mechanics is ok, it's just remembing how to add that gets me some times ;-)
[09:49] <mdke> mpt: I took your name in vain on bug 77033, by the way
[09:49] <Ubug2> Malone bug 77033 in gnome-panel "Remove "Online Documentation" from System/Help menu" [Wishlist,Unconfirmed]  https://launchpad.net/bugs/77033
[09:51] <mdke> we need to get cracking on integrating material from the book so that we can get that other superfluous menu entry removed
[09:54] <nixternal> who wants to come to chicago in april and give a talk along side Chris Dibona at Flourish? (an OSS event)
[09:54] <nixternal> well then, come on down ;)
[09:54] <mdke> I wish :(
[09:55] <nixternal> Ubuntu Chicago is going to have a booth, and they want me (or somebody) to give a talk about Feisty and the future
[09:56] <mdke> invite sabdfl
[09:57] <nixternal> heh, i will CC him in an email to spark interest
[09:57] <nixternal> i mean, Chris Dibona, we need someone BIG
[10:04] <mdke> what's a good subdomain for webmail? mail and webmail are ruled out
[10:04] <mdke> I was thinking maybe postbox
[10:06] <nixternal> loveletters.mdke.org
[10:06] <dsas> presuming the other subdomains are in use by others and won't get confused, what's wrong with "email"  ?
[10:06] <mdke> dsas: yes, maybe that's the way forward
[10:07] <dsas> mailbox could also be good.
[10:07] <mdke> mailboxes is used, maybe mailbox is free
[10:18] <mpt> mdke, btw, "System Documentation" is a load of syllables, I'd much prefer "Ubuntu Help"
[10:24] <mdke> mpt: that repeats the higher menu title... "Documentation" is what I'd suggest
[10:25] <mdke> it contrasts nicely with Community/Commercial support
[10:25] <mdke> mpt: by the way sabdfl has posted again :(
[10:27] <nixternal> im not getting wiki messages anymore, something is broke (wiki edit messages)
[10:43] <nixternal> i take that back, further research indicates that gmail has began marking Wiki messages and ubuntu-marketing-owner messages as SPAM
[10:43] <nixternal> nice
[10:52] <dsas> nixternal: They've made their spam filter more aggressive this week apparently
[10:52] <nixternal> obviously
[10:52] <nixternal> they have a lot of "Ubuntu" email in there
[10:54] <mpt> mdke, yes, but using jargon synonyms isn't really better than repetition :-P
[10:55] <mdke> mpt: the problem with help is that it isn't distinguished with the other entries in the menu, that's *why* it's the title of the menu
[10:56] <mpt> "System Documentation" isn't distinguished either
[10:56] <mpt> at least, not in a way that anyone would understand.
[10:57] <mpt> (And yes, this is a symptom of the problem of trying to explain the various types of help in something as small as a menu.)
[10:57] <mdke> mpt: I suggested "Documentation"
[10:57] <mpt> Nobody wants documentation.
[10:57] <mpt> ok, I should clarify that
[10:57] <mdke> hell, I'd be in favour of abolishing the help menu too and including links on the front page, but can you please convince Mark?
[10:57] <mpt> No non-geeks want documentation
[10:58] <mdke> are you good at leaning on Mark?
[10:59] <mpt> mdke, I think the most likely way of doing that is forcing him to watch people try to use it. I don't think that will happen soon, though.
[10:59] <mdke> :(
[10:59] <mdke> what I'd like is if the docteam got trusted on things like the help menu
[11:00] <mdke> but he seems pretty resistant
[11:00] <mdke> I'll go round his house with some heavies
[11:00] <mpt> uhhhh
[11:00] <mpt> Never mind the heavies
[11:01] <mdke> he has bodyguards?
[11:01] <mpt> You live in the same city, why not call him up and ask if you can meet face-to-face?
[11:01] <mdke> ah, that's a serious suggestion
[11:01] <mdke> good plan
[11:02] <mpt> I really need to go out now, but I'll e-mail you later
[11:02] <mdke> mpt: :)


 I saw it happen but when i tried the second time it started to work and now it does not break anymore
[10:04] <nik90> zbenjamin: hmm, I will recheck it again in the evening. For now, I usually just run on device and tell qtC not to uninstall.
[10:04] <zbenjamin> nik90: hmmm could be a problem with the cmake projects again , i tried qmake
[10:05] <nik90> zbenjamin: ah yes that could be. I tried only cmake.
[10:05] <nik90> will confirm in the evening.
[10:11] <zbenjamin> nik90: yeah its cmake  related, there was a constant changed upstream that i missed
[10:11] <zbenjamin> nik90: thanks for fining!
[10:11] <zbenjamin> finding
[10:11] <zbenjamin> nik90: fixed :)
[10:12] <zbenjamin> nik90: will be released soon i hope, also the bug where the runconfigs are not created should be gone soon
[10:13] <nik90> zbenjamin: oh awesome. Thnx for the fix :)
[10:14] <zbenjamin> nik90: btw the version you have now features desktop debug support for scopes, just in case you work on scopes :D
[10:14] <nik90> zbenjamin: I haven't yet entered the world of scopes development (yet)
[10:14] <zbenjamin> nik90: just sayin :D
[10:14] <nik90> ;)
[12:02] <mzanetti> ogra_, did you make any progress with kodi on snappy?
[12:02] <ogra_> mzanetti, nope, too many other things to fix atm
[12:24] <didrocks> sounds like an interesting and visual project (can work on this next week)
[12:51] <ogra_> didrocks, note that the main focus for me is currently to make kodi work on the RPi
[12:51] <ogra_> mzanetti, ^^^
[12:52] <didrocks> ogra_: ah ok, didn't know about it, nice!
[12:52] <mzanetti> ogra_, what do you mean?
[12:52] <mzanetti> I guess having it working with Mir is one part of the challenge
[12:52] <mzanetti> and then make it work confined somehow
[12:53] <ogra_> i dont care about Mir, kodi can talk directly to GLES
[12:53] <mzanetti> ah ok... that works for me too
[12:53] <mzanetti> sooo, what's the problem then?
[12:53] <mzanetti> it's not that kodi doesn't run on rpi...
[12:53] <ogra_> time ... dependencies ...
[12:54] <ogra_> making the GLES drivers work in the first place
[12:54] <mzanetti> right...
[21:18] <shirpymode> quit


[07:09] <chibihogoshino> !time
[10:35] <cyberanger> chibihogoshino: it is time to get a bot that does more than listen I thin
[10:35] <cyberanger> but the cost of a clock is minimal, usually ships with the computer ;-)
[10:45] <chibihogoshino> clock ?
[10:55] <cyberanger> last message, 02:09 am, !time
[10:56] <cyberanger> a clock is the simplest of programs, guantreed to be right at least twice a day
[10:56] <cyberanger> and I have to admit, much simpler than an IRC bot
[11:07] <chibihogoshino> oh
[11:08] <chibihogoshino> i was marking how long it was that this channel would be silent
[11:49] <cyberanger> heh
[11:49] <cyberanger> and at two am, bad time
[11:49] <cyberanger> four hours of sleep
[12:42] <chibihogoshino> sleep ?
[12:56] <wrst> good morning
[13:04] <cyberanger> chibihogoshino: 2am to 6am, granted I'm not most people, but most people would be asleep
[13:04] <cyberanger> morning wrst
[13:05] <wrst> cyberanger: good morning
[13:13] <chibihogoshino> i guess
[13:13] <chibihogoshino> oh hi chan
[13:17] <cyberanger> wrst: how's it going?
[13:17] <wrst> going well cyberanger, you?
[13:18] <cyberanger> chibihogoshino: I sleep when I hit the bed, how long I sleep varies too much, hence not most people
[13:18] <cyberanger> wrst: even pokes fun at that from time to time ;-)
[13:18] <cyberanger> wrst: not too bad
[13:18] <chibihogoshino> me too
[13:18] <cyberanger> weather clears further, then it'll be better
[13:18] <chibihogoshino> i think i slept for a hour last night
[13:19] <cyberanger> last night was odd, perhaps 8 or perhaps zero
[13:19] <cyberanger> woke up so much, kinda hard to call what it really was
[13:20] <chibihogoshino> i hate when that happens
[13:20] <chibihogoshino> id rather be up than drifting
[13:20] <chibihogoshino> or surfing the dream scape
[13:20] <cyberanger> wasn't drifting, which would have been a little better
[13:20] <cyberanger> it was down and up, abrupt
[13:20] <chibihogoshino> oh damn..
[13:21] <chibihogoshino> thats worse
[13:21] <cyberanger> yeah, adreline kick in the process, higer heart beat
[13:21] <cyberanger> fine in under 5 minutes, but annoying process
[13:23] <chibihogoshino> any dreams ?
[13:24] <cyberanger> none, probally 8 years or so since the last
[13:24] <chibihogoshino> wow
[13:25] <cyberanger> well, regularly that is
[13:31] <cyberanger> a few since, but easily heads south
[13:50] <cyberanger> chibihogoshino: you and I, we seem to be the bit of the group that just has that weird sleep routine (or lack of)
[13:51] <chibihogoshino> yeah
[13:52] <chibihogoshino> i have no routine at all for sleeping
[13:52] <chibihogoshino> sometimes i sleep for 20 hours and sometimes i sleep a hour a night
[13:53] <cyberanger> same, and allways seem to wake up before 6am
[13:53] <cyberanger> at some point in the night
[13:54] <cyberanger> I may fall back asleep, might not
[13:55] <chibihogoshino> yeah
[13:56] <chibihogoshino> i hate that when i dont have a job.. i still cant sleep in
[13:57] <cyberanger> lol, that isn't necessarlly bad, allows you to spend time working
[13:57] <cyberanger> and proving you get up early
[13:58] <chibihogoshino> i have nothing to work on tho ..
[13:58] <cyberanger> funny thing is, for me I'll wind up nights, try and stay up all day, so I'll sync back up
[13:59] <cyberanger> and wake up at 2am or somthing, curse in an empty room after a few hours trying to sleep
[13:59] <cyberanger> wind up right back on nights
[13:59] <cyberanger> when I'm working that doesn't happen (easy to prevent at least)
[13:59] <cyberanger> hey Xpistos
[14:00] <cyberanger> chibihogoshino: so yeah, no logic at all, some friends have that too, but with mortar fire at night, patrols in the day, it's expected
[14:00] <cyberanger> not expected in me
[14:02] <Xpistos> hey yal
[14:02] <Xpistos> wrst
[14:03] <chibihogoshino> cyberanger: past life memories
[14:04] <cyberanger> hey Xpistos how's it going
[14:04] <wrst> Xpistos: i think you were asking about natty (11.04) ?
[14:04] <cyberanger> chibihogoshino: you mean that was your life before?
[14:04] <Xpistos> Yes
[14:05] <Xpistos> I wanted to know  if it was safe for me to install natty right now?
[14:05] <chibihogoshino> cyberanger: the reason for yours now
[14:05] <Xpistos> my system is acting to goofy and I need a fresh install
[14:05] <wrst> Xpistos: useable, not perfect but making strides with every upgrade, but I don't know :)
[14:05] <Xpistos> what version are they on?
[14:05] <Xpistos> beta what?
[14:05] <wrst> for me Xpistos it works pretty good
[14:05] <wrst> its alpha 3 Xpistos
[14:06] <Xpistos> oh
[14:06] <cyberanger> chibihogoshino: I've never been near a mortar though
[14:06] <chibihogoshino> not in this life
[14:07] <Xpistos> when is the official release day
[14:07] <Xpistos> cause I am installing like the next day
[14:07] <Xpistos> too many issues with my 10.04 install right now and I want a freash start
[14:09] <cyberanger> chibihogoshino: buddist just isn't common in TN, even with my zen leanings, I didn't catch on
[14:12] <Xpistos> ok here is another question. I want a 'landscape-esq' program to manage the computers on my network. Any suggestions?
[14:12] <cyberanger> makes sense actually considering how much of this life has been that way (and the boarding schools didn't help)
[14:12] <cyberanger> Xpistos: I thought landscape was only servers, not desktops
[14:12] <cyberanger> so what is it your aiming to manage
[14:12] <Xpistos> no, you can install it on a server
[14:13] <Xpistos> or on a desktop rather
[14:13] <cyberanger> yes, but can it truely manage a desktop
[14:13] <Xpistos> it actually makes it easier to manage my wife's comptuer
[14:13] <Xpistos> more or less
[14:13] <cyberanger> ok, so it's code is geared for both, mostly
[14:14] <cyberanger> um, I'm config file, cron job and ssh loyal, what's the goals
[14:14] <cyberanger> does her computer roam
[14:16] <Xpistos> no
[14:19] <cyberanger> and what are you wanting to manage
[14:19] <cyberanger> apt-get, samba, avahi?
[14:20] <Xpistos> whatever
[14:20] <Xpistos> yesterday all of a sudden her flash up and quit
[14:20] <cyberanger> oh, well that's flash
[14:21] <cyberanger> http://www.linuxjournal.com/content/flash-102-found-be-crashy
[14:21] <cyberanger> not sure how to really automate that
[14:22] <cyberanger> wrst: what can webmen manage on a desktop
[14:23] <cyberanger> Xpistos: I would think an apt cronjob would handle updates, if you keep her off betas
[14:23] <cyberanger> but not much you can do with flash
[14:24] <cyberanger> kill the browser and restart, worst option
[14:24] <cyberanger> or kill flash and restart, better, but rarer
[14:24] <wrst> hmm cyberanger webmin is good, pretty much everythign updates the whole deal
[14:24] <Xpistos> nope had to reinstall flash
[14:25] <wrst> Xpistos: what do you need to manage?
[14:26] <cyberanger> Xpistos: so, sudo apt-get purge/remove flashplugin-installer && sudo apt-get install flashplugin-installer
[14:26] <Xpistos> just basics, updates, logs, NFS anti-virus and firewall
[14:27] <cyberanger> firewall is easy for a true non-mobile desktop setup your describing
[14:27] <cyberanger> nothing is  listening but dhcp
[14:27] <cyberanger> and your router is NAT'd and firewalled
[14:28] <cyberanger> as for AV on linux, rarely utilized, you could cronjob her home I suppose
[14:28] <cyberanger> but not sure what you'd catch that'd get her, if she can't install
[14:28] <cyberanger> updates I cronjob, and ssh into later to apply them
[14:29] <cyberanger> sudo apt-get update && sudo apt-get -d dist-upgrade (and later run sudo apt-get dist-upgrade to apply them, after checking for issues)
[14:29] <cyberanger> would that work for you?
[14:29] <cyberanger> you could further automate it, with minute risk
[14:29] <Xpistos> it would help yes
[14:30] <Xpistos> how do you check for issues
[14:30] <cyberanger> will you be on later tonight?
[14:30] <Xpistos> no
[14:30] <Xpistos> tonight my daughter is in a singing competition here in town
[14:30] <Xpistos> but I will revisit this with you later.
[14:30] <Xpistos> just curious
[14:30] <cyberanger> ok (was gonna pull a blog off my desktop for a step by step)
[14:31] <Xpistos> first up is I have to redo my network setup
[14:31] <cyberanger> as for issues, usually I'm lax for checking on my own rigs
[14:31] <cyberanger> but usually google the packages
[14:32] <cyberanger> ones I know cause me more issues than most (firefox, chrome, flash, openoffice, top 4)
[14:32] <Xpistos> I have one Modem/wireless router that keeps messing up so I want to use it only as a modem and then use a different netgear wireless router for my other stuff but not sure how to disable to wireless router part of the modem
[14:33] <cyberanger> a combo, ouch
[14:33] <cyberanger> honestly, it might not be doable
[14:34] <Xpistos> I know it is, it is just access from outside is the potential problem
[14:34] <cyberanger> some have replaced it for just a regular modem, others move it on a rarely used subnet and gave the new router a static assignment, and shove it in a DMZ
[14:34] <Xpistos> telling the modem to port forward to the rouder
[14:35] <cyberanger> and generate the biggest wpa2 key possible, kinda aiming to make it worth hell
[14:35] <chibihogoshino> hmm.. this isnt beeping when someone says my name
[14:35] <cyberanger> DMZ being a step below port forwarding usually, but this case, dual firewall and all, yeah
[14:36] <cyberanger> with the strong wpa2 key making it true desperation if they get through
[14:36] <cyberanger> chibihogoshino: shame, client?
[14:37] <chibihogoshino> xchat
[14:37] <cyberanger> Xpistos: locking down a network is simple, in your case, just a home lan
[14:38] <cyberanger> the automation of ubuntu, for a desktop, don't put her user in the sudo group (hence no root) and then between that and strong wifi and firewall
[14:39] <cyberanger> and maybe some cron'd bash scripts, should be reasonably hands off
[14:39] <cyberanger> chibihogoshino: hrm
[14:39] <Xpistos> i don't know how to setup crons either. I have to do that in the next few weeks.
[14:40] <cyberanger> chibihogoshino: open a terminal and launch alsamixer in it, put all max and check for mute
[14:41] <cyberanger> Xpistos: that's not too hard, It wasn't the simpliest thing for me to learn it's time syntax
[14:42] <Xpistos> right
[14:42] <cyberanger> and if your just wanting apt up to date, we're talking once a day when asleep (3am?)
[14:43] <cyberanger> maybe only every sunday, or just keeping apt's sources up to date, and downloading packages to be appled later, manually (to check for issues)
[14:43] <cyberanger> there's options, and I can guide you through that
[14:44] <cyberanger> the one thing that confused the daylights out of me, was actually simple, if you know, you allways want one full blank line at the end
[14:45] <cyberanger> or it will not launch your cron script (I presume it's a polite way to disable a script, or an old error checking method, never knew why they did that for sure)
[14:46] <cyberanger> Xpistos: are you wanting to handle your network first?
[14:47] <Xpistos> yes
[14:48] <Xpistos> the modem/router keeps loosing wireless connection so if I don't get that fixed first I am going to break something and my wife is going to hurt me
[14:48] <Xpistos> Plus I think I is cause problems with skype and that is a no no with recording the podcast
[14:50] <cyberanger> heh, if it's already at that point break IT, then tell her a power surge caused it to look like a brick smashed it, followed by a sledgehammer and a semi
[14:51] <cyberanger> not sure how a surge could look that bad, but I'll worry about that later ;-)
[14:51] <cyberanger> the added latency with skype should be minimal, but present
[14:52] <cyberanger> a line would be better, but maybe unrealistic
[14:52] <cyberanger> personally, I use skype as a last resort
[14:52] <cyberanger> and I mean last
[14:59] <cyberanger> but if it
[15:00] <cyberanger> s the tool you use, it needs to work
[15:00] <cyberanger> or be replaced with something that will, and wifi seems to cause a little issue in any choice
[15:20] <cyberanger> heading out, will bbl to chat
[16:35] <Xpistos> wrst
[16:36] <wrst> yes Xpistos1
[16:36] <wrst> err yes Xpistos!
[17:22] <cyberanger> back
[18:03] <orias> front
[18:17] <cyberanger> who was in here looking at 1tb 2.5 HDD's?
[18:33] <chibihogoshino> me
[18:34] <chibihogoshino> cyberanger: ^^
[18:34] <cyberanger> chibihogoshino: seems some 1.5 and 2TB showing up
[18:35] <chibihogoshino> yeah i saw those..
[18:35] <chibihogoshino> its crazy now
[18:35] <cyberanger> unfortunately not cheap (well, worse than 1TB, which still aren't real cheap)
[18:35] <chibihogoshino> i could have 4tb in here
[18:35] <chibihogoshino> 90 bucks for 1tb isnt bad tho
[18:35] <wrst> 90 bucks didn't used to get you a GB :)
[18:35] <chibihogoshino> 2.5 too
[18:36] <cyberanger> long overdue if you ask me, 3.5's have been out for too long, to still be waiting on 2.5
[18:36] <chibihogoshino> yeah
[18:36] <cyberanger> and for 1TB it's double, still off scale for the amount of market time
[18:36] <chibihogoshino> people i guess dont want that much on a laptop
[18:36] <wrst> Xpistos: alpah 3 of natty seems to be much much improved, broadcom wireless is totally screwed up but that's the biggest thing i have found so far
[18:37] <cyberanger> wrst: and you don't need linux for that, winblows will doo
[18:38] <wrst> linux for what?
[18:38] <wrst> cyberanger: ^
[18:39] <cyberanger> your broadcom issues
[18:39] <Xpistos> broadcome is the deal braker
[18:39] <wrst> well beleive it or not it "just works" with win 7
[18:40] <wrst> never had an issue with ubutnu just something with the new kernel i'm sure it will be fixed before final release
[18:40] <wrst> Xpistos: you can however use the firmware cutter and you will be find
[18:40] <wrst> *fine
[18:40] <wrst> just don't use jockey to install the broadcom driver
[18:47] <cyberanger> wrst: how's jockey failed you?
[18:47] <cyberanger> did you have a selection of drivers and pick the best one
[18:48] <wrst> jockey hasn't but the driver it installs has failed me and it doesn't give the option for the firmware cutter any moer yet the package exist all part of the alpha experience :)
[18:48] <cyberanger> lol
[19:01] <Xpistos> T-Mobile is going to be sorry they messed with the wrong person
[19:01] <wrst> Xpistos: having fun yet?
[19:01] <Xpistos> oh hell yeah
[19:02] <Xpistos> I just wrote a script that will post all the chat logs I have from t-mobile in their chat
[19:02] <Xpistos> FLOOD!
[19:02] <wrst> :)
[19:02] <Xpistos> end with " NOW GET ME A DAMN SUPERVISOR!"
[19:02] <Xpistos> I may have to change that
[19:02] <wrst> :)
[19:27] <cyberanger> may
[20:11] <Xpistos> wrst
[20:12] <Xpistos> having some trouble sending as x@ae from gmail any tips?
[20:12] <wrst> hmm it has always worked, what happens?
[20:13] <Xpistos> it says it is sending, but I don't recieve it and the webmail doesn't so it as sent from ae
[23:44] <wrst> chibihogoshino: i'm liking the way unity is startingto stackup
[23:44] <wrst> sorry chibihogoshino meant to send that to chris4585 :)
[23:44] <wrst> chris4585: i'm liking how unity is starting to stack up  :)
[23:49] <wrst> and the new ubuntu one logo is smashing!


[00:08] <yacoob_> Hello there. Any information about 1.13 packages for osx coming soon?
[00:11] <lifeless> yacoob_: the mac folk are pretty responsive, so I'd expect something within a day or two
[00:12] <yacoob_> hit #335528:
[00:12] <yacoob_> This report is public
[00:13] <yacoob_> erp.
[00:13] <yacoob_> hit bug#335528, looked for any other version out there available.
[00:13] <lifeless> bug 335528
[00:13] <lifeless> yacoob_: upgrade your loom package
[00:13] <lifeless> yacoob_: you can also run 'bzr --builtin status' or 'bzr --no-plugins status'
[00:14] <yacoob_> ha, let's see.
[00:17] <thumper> bzr shelve rocks!
[00:18] <yacoob_> btw, I must be tired, I haven't noticed the 'dup-of' line describing the problem in detail... :)
[00:55] <yacoob_> hehe. Good thing: bzr gives you many possible models of development, to pick one that suit your needs. Bad thing: bzr gives you many possible models of development, and you need to worry which one to choose, if you don't have that much experience in the area... :)
[01:15] <Peng_> At least it's easy to switch models.
[01:17] <yacoob>  True... I think. :)
[01:18] <yacoob> for the moment I'm playing with a small pet projec, that only I work on... but I don't like that much idea of keeping my source in just working dir
[01:19] <yacoob> so I've just pushed whole branch to external drive... and now if something happens to my copy, I'll just pull from there
[01:22] <yacoob> hm, assuming I'm working with a centralized model and do some local commits - would later commit push everything as a single change, or will I have whole history pushed together?
[01:35] <lifeless> yacoob: it has all the history
[01:50] <yacoob>  any way to "crunch" it down to single change?
[01:52] <lifeless> yes - its in the user guide. May I ask why though?
[01:52] <yacoob> no real reason, just looking at the possibilities
[01:53] <lifeless> ok
[01:53] <lifeless> so our log shows it crunched down
[01:53] <lifeless> even while the full detail is preserved under the covers
[01:58] <yacoob> I wonder how painful a checkout is, when the history is large... assuming we do want the history
[02:26] <lifeless> jml: so, we can do push of a revision in 18 seconds now
[02:26] <lifeless> jml: which makes 11seconds a rather large fraction :P
[02:27] <Peng_> It takes 18 seconds to push 1 revision? What are we talking about?
[02:27] <lifeless> Peng_: its not 36 for two, if thats concerning you :P
[02:27] <jml> lifeless: I was looking at our data on this today
[02:27] <lifeless> Peng_: 'bzr push' in an existing branch with one new commit on it
[02:27] <lifeless> Peng_: via bzr+ssh
[02:28] <spiv> Peng_: pushing 1 new revision to an existing branch in a shared repo via bzr+ssh, including SSH handshake, from Sydney->London.
[02:28] <spiv> 18s, but also 18 HPSS calls, co-incidentally.
[02:28] <Peng_> Oh, from Sydney to London.
[02:29] <spiv> Yeah, that part is rather key :)
[02:29] <mwhudson> spiv: 18s includes ssh set up time?
[02:30] <spiv> Also, there are actually two SSH handshakes there, it was a push to people.ubuntu.com.
[02:30] <spiv> mwhudson: yes.
[02:30] <mwhudson> spiv: oh good :)
[02:30] <spiv> mwhudson: if launchpad had 1.13 I'd use it ;)
[02:31] <mwhudson> spiv: bazaar.staging.launchpad.net will soon enough
[02:31] <mwhudson> staging can be really slow for other reasons though
[02:31] <spiv> mwhudson: that would be lovely.
[02:48]  * fullermd frowns.
[02:48] <fullermd> Is this redirect of distfiles to launchpadlibrarian new?
[02:49] <lifeless> fullermd: I don't think so; its to prevent XSS
[02:49] <jml> is there a builtin command that does 1 hpss call?
[02:49] <lifeless> jam has one in a plugin I think
[02:49] <jml> 1 r/o call preferably
[02:50] <fullermd> Hm.
[02:50] <lifeless> https://code.edge.launchpad.net/~bzr/bzr-hello/trunk
[02:50] <jml> lifeless: thanks
[02:50] <fullermd> It's breaking the port download, which explicitly doesn't follow redirects   :|
[02:50] <fullermd> Never did that before, even earlier this week.
[02:50] <lifeless> oh. have ports changed then ? ::P
[02:51] <jml> whomp!
[02:52] <lifeless> ?
[02:52] <fullermd> I don't think so...   I'm checking as fast as I can swallow the bile from running cvs ann...
[02:52] <jml> lifeless: bzr hello stacktraces
[02:52] <lifeless> ouch
[02:52] <spiv> I have one too, https://launchpad.net/bzr-ping :P
[02:53] <fullermd> Not in a couple years at least...   the line setting that arg hasn't been touched since 07.
[02:53] <spiv> jml: and mine doesn't backtrace ;)
[02:53] <fullermd> And it worked earlier this week when I tested the RC.
[02:53] <lifeless> AFAIK there hasn't been a rollout this week
[02:53] <lifeless> spm: ^
[02:54] <lifeless> fullermd: given today is monday and all
[02:54] <jml> spiv: thanks.
[02:54] <fullermd> Are the librarian links stable (or stable enough 'till the next release)
[02:54] <fullermd> It was probably Wed or Thur when I did it...
[02:54] <fullermd> mtimes say Thurs.
[02:54] <spiv> jml: FWIW I just got 6.477s to bzr ping bzr+ssh://bazaar.launchpad.net/
[02:55] <jml> spiv: that's roughly what I get.
[02:55] <jml> (5.6, 5.8, 6.2)
[02:55] <lifeless> jml: how long do you get for 'bzr ping lp:bzr'
[02:55] <spiv> fullermd: which librarian links?
[02:55] <jml> using the lp: url takes it up to 7.6, 7.8, 8.0
[02:56]  * igc lunch
[02:56] <fullermd> The 302 to launchpadlibrarian.net for the release tarball.
[02:56] <spiv> Which 302?
[02:56] <spiv> (I think I'm missing some context)
[02:57] <jml> lifeless: so, uhh, I guess that means that launchpad page loads are expensive :P
[02:57] <lifeless> fullermd: what url are you giving ports today
[02:57] <lifeless> jml: but but but these are not full pages, they are ajaxy, they must be faster right?
[02:57] <lifeless> oh damn, there goes my sarcastic side again. Meep
[02:58] <fullermd> http://pastebin.ca/1361926
[02:58] <fullermd> (does the same with code.launchpad, which is what bzrtools is using; it's failing now too)
[02:58] <spiv> fullermd: ah, on Launchpad, as opposed to bazaar-vcs.org or something
[02:58]  * jml files a bug on bzr-ping
[02:58] <fullermd> Well, last I heard release tarballs weren't going on b-v.o anymore anyway   :)
[02:59] <jml> oh, it doesn't use lp as its bug tracker
[02:59]  * jml uses IRC instead
[02:59] <jml> spiv: ping should also be able to send N hpss requests
[02:59] <lifeless> jml: thats just a bad default, assume  it uses it
[03:00] <spm> lifeless: we did have a rollout to crowberry on friday. Was a CP for jml/mwh's bzr connections fix. Is possibly related?
[03:00] <lifeless> spm: what else was included though? the main app is at issue, not code hosting per se
[03:00] <poolie> hi all
[03:00] <spiv> fullermd: AFAIK /bzr/1.13/1.13/+download/bzr-1.13.tar.gz should be a stable URL.  Also, the target of that redirect should exist for as long as the Launchpad web UI offers bzr-1.13.tar.gz for download.
[03:01] <spiv> fullermd: does that tell you what you want to know?
[03:01] <lifeless> jml: ping 'fixed' to use lp
[03:01] <fullermd> I guess...   I'll just have to resolve it manually and use the librarian links.
[03:01] <fullermd> Port fetch explicitly disables redirect-following.
[03:02] <lifeless> fullermd: how does port fetch handle sf?
[03:02] <spiv> It would be nice if Launchpad served that data to you directly rather than giving a redirect.
[03:03] <fullermd> It just lists the mirror explicitly.
[03:04]  * fullermd grabs a random example.
[03:04] <lifeless> fullermd: can you just turn it on for this, I mean, sha1 isn't trivially broken [yet]
[03:04] <fullermd> Not really, no.
[03:04] <spiv> Then using the librarian URL directly seems about the same.
[03:04] <fullermd> I mean, I probably COULD override the fetch args in the port Makefile, but that's REALLY unfriendly to the layering.
[03:05] <spiv> But ideally I think port fetch would rely on the checksum rather than lack of HTTP redirect...
[03:05] <lifeless> fullermd: args = echo $args | sed -e ....
[03:05] <lifeless> :P :] :>
[03:05] <fullermd> Too late, due to make's makeage  :p
[03:06] <fullermd> It does use a checksum to verify the file after download.  The comments suggest one reason redirects are flat disabled is because of sides that use a 302 to implement their 404's.
[03:06] <lifeless> fullermd: ugh, breaking a standard to deal with broken sites
[03:06] <lifeless> FAIL
[03:07] <lifeless> turn it on, sites with 404 as 302 will get a sha fail, everyone wins
[03:07] <fullermd> That's slightly above my paygrade   :p
[03:07] <lifeless> [I appreciate its not trivial to do this, but really. HTTP Nazi hat on now]
[03:09] <fullermd> Ah, there's where it started.  1.306, 1999-03-08.
[03:09] <fullermd> Now I can avoid touching cvs ann for another 5 years, hopefully...
[03:20] <AfC> I have today discovered that in Red Hat land they use the term "re-base" to mean upgrading the version of a package they are shipping to a newer (sometimes even latest!) release.
[03:20] <AfC> This is exciting.
[03:20] <lifeless> its analagous at least
[03:21] <AfC> Well, seeing as how I never figured out what Git rebase did, nor how Bazaar's implementation of same worked, really, it's all the same to me :)
[03:21] <AfC> I'm just pleased to hear that they do, from time to time, upgrade their packages.
[03:22] <fullermd> Sounds like a scurrilous rumor to put you off your guard.
[03:25] <AfC> fullermd: very likely
[03:25] <AfC> fullermd: but still, given that it looks like I'm going to be building, deploying, and maintaining a largish enterprise installation on RHEL over the next few months, I'll happily take false hopes.
[03:27] <Peng_> The more hope you have, the more you can be disappointed.
[03:28] <AfC> I know. Isn't the universe a wonderful place?
[03:28] <fullermd> Yeah.  I've tried crushing the spirit of a pessimist before.  It just has no flavor.
[03:34] <lifeless> fullermd: did you add all-spice?
[03:38] <fullermd> Nah, that's a little coarse for the usage.  Cumin and paprika, more like.
[05:30] <fullermd> Ah, found What Changed to cause the redirect issue.  Pfeh.
[05:33] <lifeless> fullermd: ...
[05:33]  * lifeless shakes his mind reading gizmo, its bust
[05:34] <fullermd> Upgraded by system over the weekend.
[05:34] <fullermd> Which fixed a bug in fetch(1) that cause the "don't-follow-redirects" arg to have no affect on http_s_
[05:35] <fullermd> And no effect, either.
[05:35] <fullermd> Just goes to show, fixing bugs always screws things up...
[05:37] <lifeless> :)
[05:37] <lifeless> it also shows that the don't-follow-redirects setting wasn't affecting you :P
[05:37] <fullermd> Yah.  It was only working on http.
[05:38] <fullermd> Which didn't have any effect on grabbing bzr{,tools}, so it was masked.
[05:38] <lifeless> I know
[05:38] <lifeless> just saying, delete the setting entirely, it'll be fine :)
[05:39] <fullermd> That promises a very long discussion.  I'm not sure I have the gumption to try and ram that through...
[06:36] <BasicOSX> Looks like release announcement did not make it to -announce, someone needs to approve it?
[06:36] <BasicOSX> sleep
[07:03] <Kamping_Kaiser> Would this be enough information to file a bug with? its me trying to commit using bzr in an svn repo http://paste.debian.net/30664/
[07:04] <Kamping_Kaiser>  /seems/ to be reproduceable - cd into svn dir -> try and commit -> segfault.
[07:04] <lifeless> Kamping_Kaiser: sure, on bzr-svn please
[07:04] <Kamping_Kaiser> lifeless, ok, thanks.
[07:04] <lifeless> Kamping_Kaiser: jelmer will want your subvertpy version, platform (i386/adm64 etc) and libsvn versions I suspect
[07:05] <Kamping_Kaiser> lifeless, ok, i'll be sure to include them. are bugs filed 'announced' here or should i link after filing it?
[07:09] <lifeless> they aren't, because folk get mailed
[07:15] <lifeless> spiv: LOL I broke the retry-tests by making packs much more efficient :P
[07:21] <spiv> lifeless: :)
[07:21] <spiv> lifeless: I was wondering what happened to your merge...
[07:21] <lifeless> specifically I got rid of a reset() call in _refresh_data
[07:22] <lifeless> so now it merges. hmm
[07:28] <Kamping_Kaiser> lifeless, thanks for the help, bug is now filed.
[07:32] <lifeless> Kamping_Kaiser: my pleasure
[07:32] <lifeless> spiv: so, fixed by 'reset; refresh_data()' :P
[07:32] <lifeless> spiv: hate this too-good code.
[07:34] <lifeless> spiv:   File "/home/robertc/source/baz/integration/bzrlib/tests/test_remote.py", line 1934, in test_ok_with_real_repo
[07:34] <lifeless>     client._calls)
[07:34] <lifeless> AssertionError: not equal:
[07:34] <lifeless> a = [('call', 'PackRepository.autopack', ('quack/',)),
[07:34] <lifeless>  ('pack collection reload_pack_names',)]
[07:34] <lifeless> b = [('call', 'PackRepository.autopack', ('quack/',))]
[07:34] <lifeless> from bzrlib.tests.test_remote.TestRemotePackRepositoryAutoPack.test_ok_with_real_repo
[07:35] <Peng_> That eliminated a round-trip?
[07:35] <lifeless> Peng_: changed from a private interface to a public one, round trips are the same
[07:35] <lifeless> Peng_: this is test fallout I fear
[07:36] <lifeless> mock objects, your best friend, your worst enemy
[07:41] <lifeless> spiv: do you want to see these test changes?
[07:41] <lifeless> :!bzr diff | diffstat
[07:41] <lifeless>  test_knit.py       |   34 ++++++++++++++++------------------
[07:41] <lifeless>  test_remote.py     |   10 +++++++---
[07:41] <lifeless>  test_repository.py |    1 +
[07:41] <lifeless>  test_smart.py      |    4 ++++
[07:41] <lifeless>  4 files changed, 28 insertions(+), 21 deletions(-)
[07:45] <lifeless> spiv: no answer == land it :P so am
[07:52] <spiv> lifeless: sorry, was busy thinking about pork like a tyrant day... :P
[07:54] <spiv> lifeless: if it's just adjusting tests in obvious ways (e.g. I imagine that the test_remote fix was pretty trivial), then +1
[07:56] <lifeless> spiv: mmm bacon explosion mmm
[07:57] <lifeless> spiv: not entirely, let me pastebin the deed
[07:57] <lifeless> http://paste.ubuntu.com/131855/
[08:00] <spiv> lifeless: hmm, please adjust the test_remote change to append something like 'pack repository refresh_data' rather than reload_pack_names.  It's just an arbitrary string, but I'd rather it more-or-less described the direct action...
[08:01] <lifeless> spiv: yeah. I'll have to land that later though
[08:01] <spiv> lifeless: but otherwise it looks ok to me.
[08:25] <CaMason> hi guys. Is there any nice way to do a visual diff on Windows? I have BeyondCompare installed, but using `bzr diff --using=BCompare.exe` gives me 1 file at a time
[08:26] <SuperMMX> Hi, guys, I just upgraded to 1.13 to try the filtered view, but it seems that it has no effect at all. In my understanding, filtered view will only generated some part of the working tree, right ?
[08:28] <SuperMMX> Will it only show the the contents in a directory DIR if I do "bzr view --name MyView DIR" ?
[08:31] <lifeless> CaMason: I thought bzr had visual diffing builtin on windows
[08:32] <CaMason> via the tortoisebzr thing? That doesn't work for me (64-bit)
[08:32] <lifeless> SuperMMX: it currently only affects what the commands *do* not what is put on disk; also make sure you have followed ian's notes about it as it needs a in-development tree format
[08:32] <lifeless> CaMason: oh :(
[08:32] <CaMason> although bizarely, the icons do show up if I use a file browser within an application :o
[08:33] <SuperMMX> lifeless: sure, the working tree format is upgraded to development-wt5.
[08:34] <SuperMMX> lifeless: ... it seems that I misunderstand the feature totally  at first
[08:35] <sabdfl> what's the best format for brisbane-core tests?
[08:35] <SuperMMX> I thougth it will reduce the diskspace which is with very hight priority in my feature wishlist for bzr.
[08:39] <lifeless> sabdfl: we're currently looking at gc-chk255{,-big}, not that you need to set NO_LABELS in the code to avoid parsing a lookup table that we're going to either remove or have partial-parsing on soon
[08:39] <lifeless> s/not/note/
[08:39] <SuperMMX> But I think it should not be very hard to add that function. It will be great to only work with a small set of files in the same tree.
[08:40] <lifeless> gnight all
[08:41] <spiv> lifeless: g'night
[08:41] <spiv> lifeless: btw, with my patch landed, tests all pass with InterOtherToRemote removed
[08:41] <Peng_> lifeless: Good night.
[08:42] <mwhudson> Peng_: do you ever sleep?
[08:44] <fullermd> Sleep is for wimps.
[08:45] <fullermd> Happy, healthy, well-rested wimps, but wimps nonetheless.
[08:52] <jml> so, my flatmate got a cold the day I got back from travel
[08:52] <jml> I may well be cursed.
[09:14] <Peng_> mwhudson: Disturbingly frequently.
[10:06] <fullermd> Oh blah, merge --force is still broken.
[10:18] <thrope> i have a bzr-svn co of a svn repo which contains a move (everything was moved into a sub directory). now bzr log on a file only gives entries up to the move, but svn log on the same file in a svn checkout shows the full history (including before the move)
[10:18] <thrope> is there a way to get bzr to track the full history?
[10:19] <thrope> (i thought bzr should handle renames well - git shows the full log correctly in a git-svn branch if i give it the --follow option, is there something similar for bzr?
[10:30]  * SamB would suggest that thrope file a bug -- if only he were still here
[10:31] <SamB> thrope: ah!
[10:31] <SamB> file a bug, maybe?
[10:31] <thrope> hi - sorry having some computer issues
[10:31] <SamB> I'm pretty sure bzr-svn is supposed to handle that fine
[10:32] <thrope> i thought so - but I thought i'd check first
[10:32] <SamB> well, oh, but does SVN give the full log?
[10:32] <thrope> yep
[10:32] <SamB> good
[10:32] <SamB> git isn't really an indication since it doesn't track renames ...
[10:33] <SamB> ... it just figures them out after the fact
[10:35] <Peng_> thrope: Is the repo public?
[10:35] <thrope> yep
[10:35] <thrope> http://pyentropy.googlecode.com/svn/trunk/
[10:35] <Peng_> thrope: Ask jelmer (when he comes online) and/or file a bug.
[10:35] <thrope> ok
[10:35] <thrope> i'll wait for jelmer
[10:36] <thrope> the file is trunk/pyentropy/pyentropy/pyentropy.py (I am just learning about python packages - it hink this will change)
[10:36] <SamB> hehehe
[10:37] <SamB> pyentropy.pyentropy.pyentropy?
[10:37] <thrope> first one is just a dir
[10:37] <thrope> because I keep something else in the repository
[10:37] <thrope> guess it should be pyentropy/trunk/pyentropy/pyentropy.py
[10:38] <wgrant> I don't think bzr-svn does do svn 'renames' at the moment.
[10:38] <wgrant> As svn doesn't do renames.
[10:38] <SamB> what else (besides the wiki) do you keep in the repository?
[10:38] <wgrant> It copies and deletes.
[10:38] <thrope> wgrant: it was a svn move
[10:38] <thrope> another small module call femaxent
[10:38] <wgrant> svn move is copy + delete.
[10:38] <thrope> it is related
[10:39] <Peng_> bzr-svn could detect copy+delete as a rename.
[10:39] <wgrant> And bzr can't track copies.
[10:39] <wgrant> It could.
[10:39] <wgrant> There's a bug about it.
[10:39] <SamB> I guess you should subscribe?
[10:39] <thrope> yep trying to find it
[10:40] <thrope> got it
[10:41]  * SamB personally errs on the side of reporting Invalid bugs, on the theory that most Invalid bugs are actually problems with the documentation ;-)
[10:42] <SamB> (or other code)
[10:43] <SamB> thankfully, jelmer seems to agree with me so far
[10:46] <thrope> also I was wondering if I can push two related bzr native branches into svn in such a way that they share history properly
[10:46] <thrope> (ie donthave doubled up commits)
[10:47] <SamB> thrope: did you try?
[10:47] <thrope> I figured it would involve pushing up to where they diverged to one place is svn, doing an svn copy, rebasing the branches to that copy
[10:47] <thrope> or something like that
[10:47] <thrope> I tried the naive way - pushing them both to different dirs, but there was no shared history (all the common commits appeared twice in svn)
[10:47] <Peng_> "bzr native branches"? Why deal with svn at all then?
[10:47] <SamB> oh
[10:48] <SamB> Peng: well ... is that any reason for it not to work?
[10:48] <thrope> I thought you could store bzr branches in svn with bzr-svn
[10:48] <thrope> started as a seperate thing, but now I want to put it in the main repo (which is svn)
[10:48] <thrope> I guess it doesn't really matter about the repeated commits - I will just push the two branches
[10:48] <thrope> but I wondered if it would be possible
[10:49] <SamB> file a bug?
[10:49] <thrope> its a question really
[10:49] <thrope> i dont think it should work the naive way -  i think i have to push the common bits, then do a rebase or something
[10:49] <SamB> I think maybe there should be a command for that?
[10:50] <SamB> or at least commands to help
[10:53]  * Peng_ goes to bed.
[11:00] <Leonidas> bzr log --format gnu-changelog
[11:00] <Leonidas> bzr log --format gnu-changelog
[11:00] <Leonidas> bzr: ERROR: no such option: --format
[11:00] <Leonidas> Well, something's broken with 1.13
[11:08] <fullermd> Has log ever had a --format?  It's got a --log-format...
[11:10] <spiv> fullermd: Not AFAIK.
[11:10] <spiv> Leonidas: I think that's a typo in the NEWS file :(
[11:11] <spiv> ISTR a patch on the list about it, but I guess it didn't make it in.
[11:11] <Leonidas> ok.
[11:12] <spiv> Leonidas: Leonidas it's bzr log --log-format gnu-changelog, as fullermd says.
[11:13] <spiv> Leonidas: "bzr log --gnu-changelog" works too, as "bzr help log" says.
[11:22] <spiv> lifeless: http://people.ubuntu.com/~andrew/bzr/simplify-interrepo-stack removes InterRemoteToOther and InterOtherToRemote and has all tests passing.
[11:22] <spiv> lifeless:  2 files changed, 4 insertions(+), 78 deletions(-)
[11:22] <spiv> lifeless:  :)
[12:50] <Leonidas> spiv: yes, indeed.
[13:11] <vadi2> How can I make it so when I merge and commit, the commit(s) message from the merged branch show up in the main one?
[13:16] <jpds> vadi2: It does, as subcommits.
[13:16] <vadi2> Where?
[13:17] <vadi2> Ah, just lp is not displaying it
[13:17] <vadi2> okay thanks
[13:18] <jpds> eg, http://paste.ubuntu.com/131965/ - but yeah, LP doesn't show it.
[15:00] <newz2000> Hi, can I add a bzr branch inside another project I'm working on which is also version controlled?
[15:00] <newz2000> (bzr add seems to do nothing in this case)
[15:18] <beuno> newz2000, right, it ignores any branches inside branches
[15:19] <newz2000> is there a way around that?
[15:23] <beuno> no, abentley is going to work on nested trees soon
[15:23] <beuno> which is what you want
[15:24] <newz2000> :-(
[15:24] <newz2000> That'll be a cool feature when it's done.
[15:25] <abentley> beuno: I've already started work, in fact.
[15:25] <beuno> ah, that's even better!
[15:25] <beuno> hi abentley
[15:25] <abentley> beuno: hi
[15:41] <lamont> when will https://edge.launchpad.net/~bzr/+archive/ppa have 1.13 (bzr and bzrtools)?
[16:07] <Kobaz> you're killing me
[16:08] <Kobaz> er
[16:08] <Kobaz> wrong channel
[16:08] <Kobaz> what's the recommended commit/push emailer plugin
[16:54] <jam> vila: good evening
[16:55] <vila> jam: hi ! How do you know I'm jetlagging :-)
[16:55] <jam> I'm doing pretty good, all things considered
[16:55] <jam> I managed to sleep on the plane at an appropriate time, and then stay up to ~9pm my first day back
[16:55] <jam> So I'm probably 95% transitioned by now.
[16:56] <jam> vila: I just remembered that we had talked about doing a phone call everyday
[16:57] <jam> of course we missed the original time by about 3hrs, but I  wondered if you were still interested today
[16:57] <vila> I couldn't resist and slept 16hours yesterday, yet, I fall sleeping looking the perfmeter while toying with parallelized selftest (truth is watching the 8 curves is pretty hypnotic)
[16:57] <jam> :)
[16:57] <vila> jam: not today, I'm abot to stop, but tomorrow certainly
[16:57] <jam> ok
[16:59] <vila> jam: regarding parallel selftest, lifeless sketch is working, some rough edges (unavailable feature and know failures are missed and the test suite doesn't seem to end)
[17:04] <jam> wow....
[17:04] <jam> good news for LP folks
[17:04] <jam> I just did a test conversion of LP branch to CHK255-big
[17:04] <jam> Orig source was 861MB, right after conversion, it dropped to 248MB, after doing "bzr pack" I'm down to 133MB
[17:08] <vila> jam: wow, now *that* is significant  :-)
[17:08] <jam> I'm running 'repo-details' to make sure it is all accurate, but yeah, nice results
[17:11] <rockstar> jam, that's awesome.
[17:13] <NfNitLoop> what's chk255-big?  :)
[17:14] <jam> NfNitLoop: the 'brisbane-core' work we've been working on for the past 6-8 months
[17:14] <jam> split-inventory + groupcompress delta compression + a specific page layout
[17:15] <NfNitLoop> aah, cool.
[17:15] <NfNitLoop> sorry, just eavesdropping and was curious. :)
[17:15] <jam> yeah
[17:15] <jam> Its something we'll probably be moving into a 'development' format in bzr.dev in the next month or two
[17:15] <NfNitLoop> cool. :)
[17:16] <jam> bzr.dev itself packed from something like 100MB down to ~25MB, IIRC
[17:16] <jam> not quite as impressive, though still nice
[17:31] <Tak> if I have credentials stored in authentication.conf, shouldn't bzr automagically use them when I try to branch or whatever?
[17:32] <zsakr> I need to write a hook script that will notify me by email every time someone commits a file in /trunk. I already have the email part working, but I'm not sure how to make the conditional statement to check if the commit is in /trunk.
[17:33] <jam> Tak: there may be times when using a user in a URL triggers the code that tries to use a password
[17:33] <jam> I certainly agree it is a bug if you need user@, but it may be a workaround you can use
[17:33] <Tak> I can't get it to use it with or without user@
[17:34] <Tak> this is for sftp transport
[17:34] <Tak> at least, I'm testing with sftp transport
[17:35] <jam> Tak: well, if you are using openssh as your ssh provider (the common case), we have no way to pass it a password
[17:35] <jam> you might try "BZR_SSH=paramiko"
[17:35] <jam> for security, openssh uses a direct connection to your terminal to prompt for a password
[17:36] <zsakr> jam: any idea?
[17:36] <jam> zsakr: Can you just check the branch url?
[17:36] <jam> if thebranch.base.endswith('/trunk') ?
[17:36] <Tak> interesting
[17:38] <jam> Tak: I would certainly recommend using ssh keys and an ssh-agent under those circumstances, rather than paramiko
[17:38] <jam> but you can use a password if you prefer
[17:40] <Tak> well, I'm attempting to use the authentication api generically - I just happen to be testing with an sftp transport because that's what I have on hand that's passworded
[17:41] <Tak> it appears to fail with paramiko as well
[17:43] <jam> Tak: did you use "export BZR_SSH" ?
[17:43] <Tak> yeah, and the console output is different, signifying that it's not using openssh
[17:48] <jam> Tak: I don't use it myself, so I'm not 100% sure how to configure everything. Though I know that http and ftp get more testing, since there aren't many alternatives there
[17:48] <jam> I would have you chat with vila, since he implemented most of the auth work, but I think he stopped for today
[17:48]  * Tak nods
[17:48] <Tak> vila: ping ;-)
[19:24] <rockstar> Is there a branch format register somewhere that will let me get all the current formats?
[19:28] <beuno> man, bzr's progress bar is so awesome now
[19:28] <LarstiQ> rockstar: bzrlib.bzrdir.format_registry?
[19:29] <LarstiQ> rockstar: or specifcally branch formats?
[19:29] <jelmer> 'evening beuno, larsitq
[19:29] <jelmer> *larstiq
[19:30] <rockstar> LarstiQ, anything I can iterate over will do.
[19:31] <beuno> hey hey jelmer
[19:31] <beuno> how's it going?
[19:31] <LarstiQ> rockstar: [] ;P
[19:32] <LarstiQ> hey jelmer, beuno :)
[19:32] <LarstiQ> jelmer: I started an identi.ca account!
[19:32] <beuno> jml, thank you again for lp-open
[19:32] <beuno> hola LarstiQ!
[19:32] <LarstiQ> beuno: and indeed, mbp deserves much kudos for the progress bars
[19:33] <LarstiQ> rockstar: the thing is, every domain object (the big three) has it's own formats, and then a combination of those is also known as a format
[19:33] <jelmer> beuno: pretty good, looking at finally putting that first bzr-git release out
[19:33] <jelmer> LarstiQ: whoa
[19:33] <beuno> jelmer, a lot of excitement around that
[19:34] <LarstiQ> rockstar: so, for formats in that registry, bzrlib.bzrdir.format_registry.get('default').get_branch_format()
[19:34] <LarstiQ> rockstar: but you might miss non-bundled branch formats
[19:34] <rockstar> LarstiQ, is 'default' a format string?
[19:35] <LarstiQ> rockstar: yeah, from the format_registry.keys() list
[19:36] <LarstiQ> rockstar: if you are sure it is branch formats, and not repository or workingtree ones, I think only 6 and possibly 5 are 'current'
[19:36] <LarstiQ> ie, bzrlib.branch.BzrBranchFormat{6,5}
[19:37] <rockstar> LarstiQ, so I need to be able to specify a format string, and determine whether a branch with that format string needs upgrading.  Maybe that'll help you give me clues.
[19:37] <mwhudson> LarstiQ: isn't it branch7 that adds stacking?
[19:37] <rockstar> mwhudson, the source would say so
[19:37] <LarstiQ> mwhudson: if it does, it's hiding
[19:38] <LarstiQ> hmm, maybe import didn't get to it properly
[19:38] <rockstar> LarstiQ, bzrlib.branch.BranchFormat7 is the first that overrides supports_stacking to return True
[19:38]  * LarstiQ quizzicaly looks at ipython
[19:38] <rockstar> LarstiQ, so you see my dilemma.
[19:38] <LarstiQ> rockstar: I sit corrected.
[19:39] <LarstiQ> rockstar: ok, I'd look at the code in bzrlib that detects when things need upgrading.
[19:40] <rockstar> LarstiQ, yeah, looking at BzrDir.needs_format_conversion right now
[19:40]  * LarstiQ assmebles dinner
[20:01] <mwhudson> abentley: good morning, bundlebuggy seems to be down
[20:02] <abentley> mwhudson: restarted
[20:02] <mwhudson> abentley: thanks
[20:19] <schmichael> hm, committed a 45MB json file, pulled it into another repo & its empty
[20:19] <schmichael> the second repo is 1.13rc is that makes a difference
[20:30] <Peng_> schmichael: What's empty? The entire repo?
[20:30] <Peng_> schmichael: Maybe the branch doesn't have a working tree? Run "bzr checkout".
[20:32] <schmichael> Peng_: oh sorry, turns out i'm crazy
[20:32] <schmichael> turns out piping nothing to a file overwrites it ;)
[20:32] <schmichael> so um... bzr is fine
[20:32] <Peng_> Ah.
[20:32] <schmichael> better than fine really
[20:32] <schmichael> the .bzr directory is only 6.7MB!!!
[20:41] <Peng_> mwhudson: ping?
[20:42] <mwhudson> Peng_: hi
[20:42] <mwhudson> Peng_: what's broken in launchpad trunk now? :)
[20:42] <Peng_> mwhudson: The changelog page. :)
[20:42] <mwhudson> Peng_: how so?
[20:42] <Peng_> (You meant Loggerhead, right?)
[20:43] <mwhudson> er, yeah
[20:43] <Peng_> mwhudson: When I click the down arrow, it doesn't display anything. +revlog gives back an error page.
[20:43] <mwhudson> hm
[20:43] <mwhudson> saying what?
[20:44] <Peng_> List index out of range on changes[0].
[20:44] <Peng_> mwhudson: http://paste.pocoo.org/show/jE4QV4sihEBPkHGle9p2/
[20:44] <mwhudson> that means the revid is wrong
[20:45] <mwhudson> oh god, is this a bzr-svn branch or something?
[20:45] <mwhudson> i wonder if there are quoting issues
[20:45] <Peng_> mwhudson: Yeah, it is.
[20:45] <mwhudson> bing!
[20:45] <mwhudson> ok, should be easy to fix
[20:46] <mwhudson> Peng_: http://pastebin.ubuntu.com/132182/ <- try this?
[20:48] <Peng_> Hold on.
[20:54] <Peng_> mwhudson: Didn't help.
[20:54] <mwhudson> Peng_: did you reload the changelog page before trying again?
[20:55] <Peng_> mwhudson: I should have.
[20:55]  * mwhudson goes hunting for a bzr-svn branch
[20:56] <mwhudson> Peng_: it works for me :/
[20:56] <Peng_> Yes, I did reloa.d
[20:57] <mwhudson> Peng_: i guess it's going to be long and painful, but can you paste the +revlog url that lh is trying to access?
[20:58] <Peng_> mwhudson: /loggerhead/imports/lighttpd/bzr-svn-0.5/lighttpd-1.4.x/%2Brevlog/svn-v4%3A152afb58-edef-0310-8abb-c4023f1b3aa9%3Abranches/lighttpd-1.4.x%3A2418
[20:58] <Kobaz> what's the recommended commit/push email plugin
[20:58] <Peng_> Wait.
[20:59] <Peng_> mwhudson: Well, that was the original bad URL from before I patched it.
[21:00] <mwhudson> Peng_: the patch definitely fixes browsing a bzr-svn branch for me
[21:00] <Peng_> Hum.
[21:00] <mwhudson> (even proxied through apache)
[21:05] <Kobaz> noone has a favorite commit emailer?
[21:06] <LarstiQ> Kobaz: bzr-email if mail from the location where you work is fine
[21:06] <Kobaz> what about when someone does a push to a central repo
[21:07] <LarstiQ> Kobaz: bzr-email if that's done via a smartserver
[21:07] <Kobaz> k
[21:07] <Kobaz> i have bzr going to apache with some funky python somethingorother module
[21:07] <Kobaz> i think it's smartserver
[21:07] <LarstiQ> Kobaz: bzr-hookless-email if not. Nicholas Allen has recently been doing work in this area too (I still have to read and reply to those threads..)
[21:07] <LarstiQ> Kobaz: right, that then should be able to execute server side hooks
[21:08] <Kobaz> PythonHandler bzr-smart::handler
[21:09] <Kobaz> so anyways
[21:09] <Kobaz> i've never installed a plugin
[21:09] <Kobaz> there's a bazillion files when you click on 'code' on launchpad
[21:10] <LarstiQ> Kobaz: two approaches:
[21:10] <LarstiQ> Kobaz: 1) an OS provided bzr-email 2) cd ~/.bazaar/plugins; bzr branch bzr-email email; bzr plugins | grep email
[21:10] <Kobaz> are there debian packages?
[21:10] <LarstiQ> Kobaz: basically, if you installed bzr via a package management system, do the same for bzr-email
[21:11] <LarstiQ> Kobaz: yes
[21:11] <Kobaz> k
[21:11] <Kobaz> bzr-email - Notification email plugin for Bazaar
[21:11] <Kobaz> oooOooOoo
[21:11] <Kobaz> okay, installed
[21:11] <Kobaz> now what
[21:12] <Kobaz> how would i configur eit
[21:12] <Kobaz> heh
[21:12] <Peng_> mwhudson: Oddly enough, another bzr-svn branch works even without your patch.
[21:12] <LarstiQ> Kobaz: `bzr help email` should be a start
[21:12] <Peng_> mwhudson: (It works with the patch, too.)
[21:13] <mwhudson> Peng: which is the one that fails?
[21:13] <LarstiQ> Kobaz: or /usr/share/doc/bzr-email/README
[21:13]  * mwhudson hopes it's fairly small
[21:13] <Kobaz> k
[21:13] <LarstiQ> Kobaz: either set the options in the branch.conf you care about, or the ~/.bazaar/{bazaar,locations}.conf of the user the smartserver runs as
[21:14] <Peng_> mwhudson: http://bzr.mattnordhoff.com/loggerhead/imports/lighttpd/bzr-svn-0.5/lighttpd-1.4.x/ (but I reverted that Loggerhead install to an older version to work around this)
[21:14] <Kobaz> k
[21:14] <Peng_> mwhudson: Is 2100 revisions small?
[21:14] <mwhudson> Peng: if i bzr branch from that url, will i be talking to loggerhead?
[21:15] <mwhudson> Peng_: small enough i guess
[21:15] <Peng_> mwhudson: You can "bzr branch" from it, though Bazaar will warn about some wacky redirects.
[21:15] <mwhudson> Peng_: i guessed http://bzr.mattnordhoff.com/bzr/imports/lighttpd/bzr-svn-0.5/lighttpd-1.4.x/, seems to work
[21:16] <Peng_> mwhudson: fwiw, the branch passes "bzr check"
[21:16] <Peng_> mwhudson: Both should work.
[21:16] <mwhudson> ok
[21:21] <Kobaz> i broke it
[21:21] <Kobaz> http://pastebin.com/m2b818964
[21:24] <LarstiQ> Kobaz: that's very weird
[21:24] <mwhudson> Peng_: ok, can reproduce
[21:24] <LarstiQ> Kobaz: you branch, commit, push, and they're not compatible?
[21:24] <Kobaz> apparently
[21:24] <Peng_> mwhudson: Oh, cool.
[21:25] <LarstiQ> Kobaz: /tmp isn't secretly in a shared repository?
[21:25] <Kobaz> nope
[21:25] <LarstiQ> Kobaz: relevant ~/.bzr.log entries?
[21:25] <Kobaz> nothing interesting that i can see
[21:25] <Kobaz> i'll paste it
[21:26] <Peng_> mwhudson: So does that mean your escaping patch is unnecessary?
[21:26] <mwhudson> Peng: no, it's wrong :)
[21:27] <Kobaz> http://pastebin.com/m4970ae9a
[21:27] <Peng_> Wait, no it's not necessary or no it is necessary?
[21:27] <mwhudson> >>> bzrlib.urlutils.escape('/')
[21:27] <mwhudson> '/'
[21:27] <mwhudson> Peng_: a different patch is necessary
[21:27] <Peng_> mwhudson: Ah.
[21:27] <mwhudson> that ^ surprises me
[21:28] <Kobaz> LarstiQ: both are Repository branch (format: pack-0.92)
[21:28] <LarstiQ> Kobaz: what version of bzr and the apache foo?
[21:28] <Kobaz> Bazaar (bzr) 1.10 Python interpreter: /usr/bin/python 2.5.2
[21:28] <Kobaz> on both
[21:29] <Kobaz> apache 2.2.9
[21:29] <Kobaz> using bzr-smart.py and modpywsgi.py
[21:30] <Peng_> mwhudson: So escaping / as well would fix it?
[21:30]  * LarstiQ looks at bug reports
[21:30] <mwhudson> yes
[21:30] <mwhudson> i think so
[21:31] <Peng_> mwhudson: urllib.quote(s, safe='')
[21:32] <mwhudson> except that freaking 404s
[21:32] <mwhudson> what's going on
[21:32] <mwhudson> !?
[21:32] <mwhudson> apache is 404ing me
[21:34] <Kobaz> [Mon Mar 16 17:33:31 2009] [error] [client <IP_ADDRESS>] File does not exist: /home/web/bzr/playground/.bzr/checkout
[21:34] <Kobaz> i'm getting that in my apache logs
[21:34] <Kobaz> maybe that's bad?
[21:34] <LarstiQ> Kobaz: it's not bad per se
[21:35] <LarstiQ> Kobaz: does -Dhpss reveal anything?
[21:35] <Kobaz> what am i giving that to?
[21:36] <Kobaz> bzr?
[21:36] <LarstiQ> Kobaz: yeah, with the push
[21:36] <Kobaz> KnitPackRepository('file:///usr/home/tmp/playground/.bzr/repository/')
[21:36] <Kobaz> (no details)
[21:36] <Kobaz> HPSS calls: 9 <bzrlib.transport.http.SmartClientHTTPMedium object at 0x84f9eec>
[21:37] <LarstiQ> Kobaz: (from `bzr help debug-flags`)
[21:37] <Kobaz> ah
[21:37] <LarstiQ> Kobaz: the details should be in ~/.bzr.log
[21:38] <mwhudson> Peng_: i think i hate paste
[21:38] <Kobaz> oh
[21:38] <Kobaz> whoops
[21:38] <Kobaz> i was using https://
[21:39] <Kobaz> i need to use bzr+https://
[21:39] <Kobaz> maybe there should be a note about that in the error output
[21:39] <Kobaz> Pushed up to revision 18.
[21:39] <LarstiQ> Kobaz: that, or fix it so that isn't necessary
[21:39] <Kobaz> i forgot i needed to use bzr+https... i haven't played with a new repo in a while
[21:39] <Kobaz> true
[21:39] <Peng_> mwhudson: You could switch back to CherryPy. :D
[21:39]  * Peng_ hides
[21:39] <LarstiQ> Kobaz: if that is still in the case in 1.13, please file a bug
[21:40]  * LarstiQ falls asleep
[21:40] <mwhudson> Peng_: maybe cherrypy3 would induce less homicidal rage
[21:42] <mwhudson> but also apache is screwing me over here
[21:42] <mwhudson> http://localhost:10101/bzr/lighttpd-1.4.x%2Fchanges gets me the same page as http://localhost:10101/bzr/lighttpd-1.4.x/changes
[21:42] <mwhudson> which is annoyting
[21:42] <mwhudson> but http://localcode.dev/bzr/lighttpd-1.4.x/changes proxies to the above just fine
[21:43] <mwhudson> but http://localcode.dev/bzr/lighttpd-1.4.x%2Fchanges gets me an apache 404 page
[21:43] <mwhudson> despite
[21:43] <mwhudson> <Location "/bzr/">
[21:43] <mwhudson>         ProxyPass http://<IP_ADDRESS>:10101/bzr/
[21:43] <mwhudson> being in my apache config
[21:44] <Kobaz> okay
[21:44] <Kobaz> 1.13 is okay with https://
[21:44] <Kobaz> oh wait
[21:44] <Kobaz> no
[21:44] <Kobaz> it died
[21:44] <Kobaz> it looked like it was going
[21:48] <Peng_> mwhudson: Apache isn't even proxying it back?  :D
[21:50] <Kobaz> lifeless: yeah i set up the branch/branch.conf with some of the options
[21:50] <Peng_> I wonder if Lighttpd does the same thing?
[21:50] <Kobaz> lifeless: i added: post_commit_sender and post_commit_to
[21:50] <Kobaz> is there anytnig else i need
[21:51] <mwhudson> that works
[21:51]  * mwhudson sighs
[21:52] <Kobaz> would i have to reload apache?
[21:52] <yacoob> hm... I can't checkout/branch/pull part of the tree, can I?
[21:54] <mwhudson> Peng: try this barrel of fun: http://pastebin.ubuntu.com/132206/
[21:57] <Kobaz> lifeless: are there any other config files i need to monkey with other than branch.conf
[21:58] <mwhudson> Peng_: yeah, it's some lame security thing, as predicted<EMAIL_ADDRESS>[21:59] <lifeless> Kobaz: are  you using it locally or ona server? On a server bzr-email doesn't see 'commit' as such, rather it seespushes
[22:00] <Peng_> mwhudson: Why is this only impacting +revlog, not anything else? Luck?
[22:00] <mwhudson> Peng_: we don't stick revids in urls very often any more
[22:00] <Kobaz> lifeless: server
[22:00] <igc> morning all
[22:00] <Kobaz> i push to the server and nothing happens except the push
[22:00] <Peng_> mwhudson: Sure, but you used to do it all the time.
[22:01] <Peng_> mwhudson: This patch works for me (just over localhost, no web server)
[22:01] <mwhudson> Peng_: yes, but now bzr-svn changed the way it does revids
[22:01] <lifeless> Kobaz: you need to set post_commit_push_pull=True as well
[22:01] <Peng_> mwhudson: Ah.
[22:01] <lifeless> Kobaz: run 'bzr help email' - if it does not document the post_commit_push_pull setting then you need a newer bzr-email plugin
[22:01] <Kobaz> do i need to put it under a specific section?
[22:01]  * Peng_ notes that Lighttpd doesn't do this security thing.
[22:02] <Kobaz> i dont have post_commit_push_pull in the help
[22:02] <lifeless> Kobaz: lastly, you need to be using the native bzr protocol - bzr:// or bzr+ssh:// or bzr+http:// for this to work
[22:02] <Kobaz> yeah, i a
[22:02] <Kobaz> m
[22:02] <Kobaz> okay, i upgraded bzr-email
[22:03] <Kobaz> still no workey
[22:03] <lifeless> did you add post_commit_push_pull=True ? (you put that where your other settings are)
[22:03] <Kobaz> yea
[22:03] <lifeless> hmm, odd
[22:04] <Kobaz> post_commit_sender, post_commit_to, post_commit_push_pull
[22:04] <lifeless> hi igc
[22:04] <Kobaz> are the only things i have in branch.conf
[22:04] <Kobaz> do they need to be under a specific section?
[22:04] <Kobaz> or just anywhere in the file
[22:04] <lifeless> top level, no sections at all
[22:05] <Kobaz> any kind of debugging on the server i can turn on?
[22:05] <Kobaz> to make sure it's actually loading the plugin, and etc
[22:05] <lifeless> the ~/.bzr.log file will have some info
[22:05] <lifeless> (on the server)
[22:07] <lifeless> hmm, looks like we don't list all the found plugins
[22:07] <lifeless> well, you can ssh to the server - "ssh <server> bzr plugins"
[22:07] <Kobaz> nothing in the log
[22:07] <Kobaz> k
[22:07] <Kobaz> email is listed in plugins
[22:07] <lifeless> ok, its finding it
[22:08] <Kobaz> i'm using apache with smartserver... if that makes a difference
[22:08] <lifeless> Kobaz: ah; hmm
[22:08] <lifeless> Kobaz: johnf-inodes did the same config as you a week or so ago
[22:09] <lifeless> he came up with this patch: https://code.edge.launchpad.net/~johnf-inodes/bzr-email/server_support
[22:09] <lifeless> I haven't reviewed it yet, but as he's using it at his organisation, I'm fairly sure it works :P
[22:11] <Kobaz> mm
[22:15] <Kobaz> okay so, i have that in now
[22:15] <Kobaz> still doesn't do anything :(
[22:16] <lifeless> uhm
[22:16] <lifeless> you're running under apache
[22:16] <lifeless> does the account apache is runnign bzr as, have the plugin installed (or did you install it globally?)
[22:16] <Kobaz> globally
[22:16] <Kobaz> i backed up the original one
[22:17] <Kobaz> oooo
[22:17] <Kobaz> i restarted apache
[22:17] <Kobaz> there it goes
[22:17] <lifeless> yay
[22:23] <poolie> lifeless, spiv, igc, for myself, i'm going to send the sprint report, finish the ui-related branches i did while travelling and on friday and generally pick up pieces
[22:23] <Kobaz> i'm a gonna have to go and learn python now
[22:24] <Kobaz> the bzr-email output isn't as purty as svnmailer
[22:24] <igc> poolie: can you re-review my/jam's dirstate patch please?
[22:24] <poolie> sure
[22:27] <lifeless> Kobaz: yes, thats true, there is probably a patch in https://code.edge.launchpad.net/bzr-email somewhere
[22:27] <lifeless> I didn't realise how many branches had collected :P
[22:28] <lifeless> igc: have you considered changing ls instead ?
[22:28] <lifeless> so that it does non-recursive by default
[22:29] <Kobaz> i should update my loggerhead too, i broke it somehow
[22:30] <igc> lifeless: ?
[22:31] <lifeless> igc: re: 'ls is slow'
[22:31] <igc> lifeless: my goal is a faster iter_entries() and ...
[22:32] <igc> to find places where iter_entries() could be replaced by a faster method, e.g. one not calculating paths if the path is never used
[22:32] <lifeless> igc: both iter_entries and iter_entries by dir can do partial tree as well as full tree
[22:32] <lifeless> igc: via the from_dir and specific_file_ids parameters; it may need more work than just paging the full thing in
[22:32] <igc> lifeless, but they have explicit constraints on order
[22:33] <igc> lifeless: sure
[22:33] <lifeless> also, I'm confused, because I would have thought its the same amount of work either way - or are the pages being read multiple times?
[22:34] <igc> lifeless: iter_changes explicitly walks from the root down - it's the children calculations that are the slow bit
[22:36] <igc> lifeless: I'm yet to look at jam's code but I'm not surprised he got much faster results by calculating children in one pass rather than each time
[22:36] <lifeless> igc: All I'm saying, is its surprising that .children is slow, its meant to be fast, and that iter_entries is not just-full-tree.
[22:36] <lifeless> igc: beyond that its in your court :)
[22:36] <lifeless> separately, I'm sorry, but I had to bb:resubmit your check patch
[22:37] <lifeless> it removes a downwards sha1 validation
[22:37] <igc> lifeless: I didn't see that and just submitted it to pqm. Can you cancel it for me.
[22:37] <igc> please?
[22:38] <CardinalFang> Er, what am i doing wrong?  make new project. ... "bzr init .; bzr add .; bzr commit -m 'Initial import.';"
[22:38] <lifeless> I've wanted to make check faster too, but I stopped at that point; it needs something like a text_key->sha1 mapping held open
[22:38] <lifeless> igc: stopped it
[22:38] <CardinalFang> -> bzr: ERROR: No such file: ('TREE_ROOT', 'foo@bar-1234-1234blahblah')
[22:39] <lifeless> then we can get all the texts, get their sha1, and make sure it matches
[22:39] <igc> lifeless: I'm confused. I didn't take out the call to ie.check()
[22:39] <lifeless> CardinalFang: get rid of the '.'s, you don't need them
[22:39] <CardinalFang> Huh.  I do for "add", I think.  Okay.  Retrying.
[22:39] <lifeless> igc: oh. I may have misread, let me read again
[22:40] <lifeless> CardinalFang: you don't for add, or for init
[22:40] <lifeless> CardinalFang: in general bzr assumes ., or $(bzr root) for any command that takes a path
[22:40] <lifeless> CardinalFang: with a few key exceptions
[22:41] <CardinalFang> ("revert")
[22:41] <lifeless> CardinalFang: and in fact, 'bzr revert .' is != 'bzr revert' because the '.' says the tree only, and that means we don't revert metadata
[22:41] <CardinalFang> :)
[22:42] <lifeless> igc: oh totally my bad
[22:42] <igc> lifeless: if you prefer, I could walk the inventory via "entry in inv" and use id2path() to find paths. That might be safer?
[22:42] <lifeless> igc: go for it, its good. I was indulging in wishful thinking it appears
[22:42] <igc> in check_revision_tree
[22:42] <igc> lifeless: np. I'll resubmit
[22:42] <CardinalFang> lifeless: Hrm, could my problem be a shared repo I have in the parent?
[22:43] <lifeless> igc: I was hoping you'd removed the key issue I have
[22:43] <lifeless> CardinalFang: possibly, is it a rich root format by chance?
[22:43] <lifeless> CardinalFang: you tried with no '.''s?
[22:44] <CardinalFang> lifeless: Yes, same thing.
[22:44] <lifeless> CardinalFang: please run with -Derror, you'll get a backtrace
[22:44] <CardinalFang> /usr/local/lib/python2.5/site-packages/bzrlib/revisiontree.py(82)iter_files_bytes()
[22:44] <CardinalFang> -> raise errors.NoSuchFile(e.revision_id)
[22:45] <CardinalFang> top of stack.
[22:45] <lifeless> CardinalFang: thats all?
[22:45] <CardinalFang> (I have BZR_PDB set -- assuming that does the same.)
[22:45] <lifeless> CardinalFang: no, it doesn't
[22:45] <CardinalFang> Er, no.
[22:45] <lifeless> BZR_PDB puts you into a debugger
[22:45] <lifeless> hit bt
[22:45] <lifeless> and you'll get the full stack
[22:47] <CardinalFang> Ah, okay.  Not your fault.  It's in my stuff.  Thanks, lifeless.  Sorry for the noise.
[22:49] <lifeless> CardinalFang: you have a plugin or some such ?
[22:50] <CardinalFang> Yes.  It lacks the special case for first revision in some diff code.
[22:50] <lifeless> heh
[22:52] <thrope_> is launchpad supposed to be open for public use?
[22:52] <lifeless> thrope_: it is
[22:52] <thrope_> I tried to create a project there to mirror a google code svn repo but it just says 'pending review'
[22:52] <lifeless> thrope_: anyone can use it for open source projects
[22:52] <thrope_> who reviews it and when?
[22:52] <lifeless> code imports require a review
[22:52] <CardinalFang> All after I updated bzr on two machines at once, and horrors! one of my first operations broke!  Silly me.
[22:52] <lifeless> the code import team
[22:53] <thrope_> lifeless: but if I push it from a bzr branch no review is needed?
[22:54] <lifeless> thrope_: right; when we import we do a lot of traffic to other sites, and we're the ones grabbing the code - we need to confirm the details, check the licence etc
[22:54] <thrope_> ok
[22:54] <lifeless> if you push you are required to meet the terms of service
[22:54] <lifeless> which include only pushing code you legally can etc etc
[22:54] <thrope_> but the import will track the svn repo automatically, so I guess its better to wait
[22:55] <lifeless> anyhow, if you ask a question on answers.launchpad.net/launchpad-bazaar, one of the guys will get to it soon
[23:16] <Peng_> mwhudson: Thanks for figuring out and fixing my Loggerhead issue. :)
[23:16] <mwhudson> Peng_: thanks for being the loggerhead canary :)
[23:17] <mwhudson> Peng_: i don't suppose you want to test the new trunk with IE?
[23:31] <Peng_> mwhudson: Sorry, no Windows boxes, and I'm not installing WINE. :P
[23:31] <mwhudson> Peng_: fair enough :)
[23:32] <rockstar> mwhudson, later today I can try it with the Windows VM.
[23:32] <mwhudson> rockstar: cool, don't stress about it
[23:32] <mwhudson> but if you have time, neat!
[23:33] <Peng_> mwhudson: I suppose I could break into my father's place and steal his laptop... :)
[23:33] <mwhudson> i can usually use my other half's work laptop
[23:33] <mwhudson> but she's not here this week
[23:34] <mwhudson> um what
[23:34] <mwhudson> xchat just fell over :(
[23:34] <Peng_> Well, you didn't miss anything.
[23:38] <lifeless> 10:29 < mwhudson> but she's not here this week
[23:38] <lifeless> 10:29 -!- mwhudson [n=mwh@canonical/launchpad/mwhudson] has quit [Remote closed the connection]
[23:38] <lifeless> 10:30 -!- mwhudson [n=mwh@canonical/launchpad/mwhudson] has joined #bzr
[23:38] <lifeless> 10:30 < mwhudson> um what
[23:38] <mwhudson> cool
[23:41] <mwhudson> do you have to give Repository.iter_files_bytes a revision id that touched the file you're asking for?
[23:41] <lifeless> yes
[23:42] <lifeless> generally, don't use iter_files_bytes
[23:42] <lifeless> use RevisionTree.iter_files_bytes
[23:43] <mwhudson> fair enough
[23:43] <lifeless> because RevisionTree knows what you need :P
[23:43] <mwhudson> i was hoping to avoid loading the inventory
[23:43] <mwhudson> but yes, working first
[23:43] <lifeless> well
[23:43] <lifeless> how would you figure out the text you want without the inventory
[23:44] <lifeless> develop on chk formats, you'll get a much better picture
[23:44] <mwhudson> yeah, fair enough
[23:50] <jml> so, I'm pulling down bzr.
[23:51] <jml> err, launchpad.
[23:51] <jml> and the progress bar says 6MB (& it's around 50% complete). what does this number mean?
[23:52] <jml> I find it strange to think that ten hours worth of changes to trunk could total more than 12MB
[23:54] <lifeless> jml: well, there's nearly 50% overhead in the plain vfs methods
[23:55] <jml> lifeless: it ended up being ~25MB
[23:55] <jml> lifeless: I guess that'll go down once Launchpad upgrades its bzr
[23:55] <lifeless> yes
[23:55] <jml> lifeless: is the number total throughput or just downloaded bytes?
[23:55] <lifeless> total
[23:56] <lifeless> up + down for-all transports
[23:56] <lifeless> so total IO except local-disk isn't reported
[23:56] <jml> *nod*


[14:14] <hggdh> when will libvirt as fixed by bug 1055658 be promoted to precise-updates?
[14:14] <ubot2`> Launchpad bug 1055658 in libvirt (Ubuntu Precise) "Under load, libvirt fails to start VMs concurrently" [High,Fix committed] https://launchpad.net/bugs/1055658
[14:15] <Mirv> I'll echo once more the mterry's queue plea to SRU team before going: < mterry> infinity, I just uploaded a new compiz to precise-proposed.  I was hoping to get it in before end of week/end of year to enable more testing and hopefully get it into 12.04.2
[16:40] <infinity> hggdh: When someone can reproduce and verify https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1027987
[16:40] <ubot2`> Launchpad bug 1027987 in libvirt (Ubuntu Precise) "Starting libvirtd takes too long because of "udevadm settle" timeout" [Medium,Fix committed]
[16:44] <hggdh> infinity: ah, it is tied to this bug also. Well, I will upgrade it on some of our servers; I wil check if they use storage pools and, if they do so, I will go ahead and mark this one -done as well
[16:53] <infinity> hggdh: The problem seems to be that no one can reproduce the original bug to verify it's fixed.  If you can actually do that, that would be helpful.
[16:55] <hggdh> infinity: I am not sure I will find storage pools in use, but I will try; if at all possible, I will get a scratch server and try it
[17:01]  * xnox has lvm-pool backed libvirt but not running precise on the host. maybe i can downgrade... libvirt to test this