[06:55] -SwissBot:#ubuntu-news- ::Softpedia:: Microsoft Edge Stable Now Available on Linux @ https://news.softpedia.com/news/microsoft-edge-stable-now-available-on-linux-534315.shtml (by Bogdan Popa)
[09:52] -SwissBot:#ubuntu-news- ::Planet:: Full Circle Magazine: Full Circle Weekly News #232 @ https://fullcirclemagazine.org/podcast/full-circle-weekly-news-232/
[09:52] -SwissBot:#ubuntu-news- ::Planet:: The Fridge: Ubuntu Weekly Newsletter Issue 706 @ https://fridge.ubuntu.com/2021/10/25/ubuntu-weekly-newsletter-issue-706/
[09:52] -SwissBot:#ubuntu-news- ::Planet:: Podcast Ubuntu Portugal: Ep 166 – Hacktoberfest IV – Marcos Marado @ https://podcastubuntuportugal.org/e166/
[09:52] -SwissBot:#ubuntu-news- ::Planet:: Jonathan Riddell: OpenUK Open Technology for Sustainability and OpenUK Awards 2021 @ https://jriddell.org/2021/10/28/openuk-open-technology-for-sustainability-and-openuk-awards-2021/
[09:52] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Blog: Taking Ubuntu for a spin (literally) @ https://ubuntu.com//blog/taking-ubuntu-for-a-spin-literally-autonomous-vehicles
[09:52] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Blog: OpenStack vs AWS: which one is better for you? @ https://ubuntu.com//blog/openstack-vs-aws
[09:52] -SwissBot:#ubuntu-news- ::Planet:: Full Circle Magazine: Full Circle Magazine #174 @ https://fullcirclemagazine.org/2021/10/29/full-circle-magazine-174/
[11:13] <guiverc> I'm removing #ubuntu-fridge from https://wiki.ubuntu.com/ContributeToUbuntu as the room is empty
[16:39] <Montresor> But can I apt install edge yet?!


[13:49] <tsimonq2> arraybolt3: Still interested in dotnet? Looks like it could be all yours. :)
[18:53] <sudip> any idea why autopkgtest accepted my resquest - https://autopkgtest.ubuntu.com/running#pkg-ganeti ?
[18:53] <sudip> I didn't know I have such powers
[19:05] <arraybolt3> sudip: are you a per-package uploader? I *think* you can request autopkgtests for packages you have upload rights to, and if you have PPU rights then you have some powers. Not certain that's what's happening,  but I seem to remember doing something similar in Lubuntu-land once.
[19:06] <arraybolt3> hmm, looks like you aren't a PPU though
[19:06] <arraybolt3> in that instance :shrug: beats me :P
[19:06] <sudip> arraybolt3: no, I was planning to apply for PPU. but the wiki was little confusing  :(
[19:07] <arraybolt3> I dunno then. I don't think I've ever triggered something like that before. To be clear, you clicked on an autopkgtest triggering link and that happened?
[19:07]  * arraybolt3 is a bit hazy on how the autopkgtest guts work there
[19:07] <sudip> arraybolt3: yes
[19:09] <arraybolt3> if no one here knows how you have those rights, you could ask in #canonical-sysadmin about it. (Or #launchpad, not sure which one of those two teams controls the autopkgtest infra, I would *guess* #canonical-sysadmin though)
[19:09] <sudip> well, I dont mind having such powers :)
[19:09] <arraybolt3> heh :)
[19:38] <arraybolt3> shoot, cdbs doesn't exist anymore and now it's jamming up TigerVNC in Focal.
[19:39] <arraybolt3> so... I guess now I spin up a minimalistic Focal VM.
[20:11] <sudip> waveform: sorry, I again missed updating maintainer, even though I now have a script in "--post-build-commands" warning me about it :'(
[20:16]  * sudip has now modified the script to fail the build if maintainer is not updated
[20:45] <sergiodj> schopin: hey, let me know if you have more FTBFSes there. I fixed two out of the three you mentioned this morning (cp2k is more involved and will require more time/investigation)
[20:57] <dbungert> sergiodj: have you seen this report? https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20231215-noble-glibc-noble.html
[20:58] <sergiodj> dbungert: I have, but I was under the impression that schopin had a different list
[21:00] <ravikant_> the ftbfs report analysis resulted in this list - https://bugs.launchpad.net/ubuntu/+source/glibc/+bugs?field.tag=test-rebuild-glibc-noble
[21:01] <ravikant_> most of them are unassigned.
[21:02] <sergiodj> ravikant_: thanks
[21:03] <ravikant_> sergiodj: you're welcome
[21:07] <ravikant_> sergiodj: following are some for universe, these are not glibc related.
[21:07] <ravikant_> https://bugs.launchpad.net/ubuntu/+source/php-symfony-polyfill/+bug/2049901
[21:07] <ravikant_> https://bugs.launchpad.net/ubuntu/+source/r-bioc-savr/+bug/2049910
[21:07] <ravikant_> https://bugs.launchpad.net/ubuntu/+source/taurus/+bug/2049914
[21:07] <ravikant_> https://bugs.launchpad.net/ubuntu/+source/taurus-pyqtgraph/+bug/2049915
[21:07] -ubottu:#ubuntu-devel- Launchpad bug 2049901 in php-symfony-polyfill (Ubuntu) "php-symfony-polyfill FTBFS on noble" [Undecided, New]
[21:07] -ubottu:#ubuntu-devel- Launchpad bug 2049910 in r-bioc-savr (Ubuntu) "r-bioc-savr FTBFS on noble" [Undecided, New]
[21:07] -ubottu:#ubuntu-devel- Launchpad bug 2049914 in taurus (Ubuntu) "taurus FTBFS on noble" [Undecided, New]
[21:07] -ubottu:#ubuntu-devel- Launchpad bug 2049915 in taurus-pyqtgraph (Ubuntu) "taurus-pyqtgraph FTBFS on noble" [Undecided, New]
[21:09] <sergiodj> I'll take a look at them
[21:17] <adrien> It's late but I was cleaning up some things (and, well, testing a new version of svt-av1); looking at https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html#gnutls28 , I see that exim4 on armhf uses 4.96-17ubuntu2.1,
[21:17] <adrien> on ppc64el 4.97-3ubuntu1, and elsewhere 4.97-3ubuntu2 but why does it use differ
[21:17] <adrien> ent versions? and how do we make tests use the same version everywhere?
[21:46] <tsimonq2> adrien: #u-release is a general spot for p-m generally speaking :)
[21:47] <adrien> huh, right, I tend to ask on the same channel as my last message too much :P
[21:48] <adrien> now is bedtime, I'll see that tomorrow, thanks :)
[21:48] <tsimonq2> Sorry, finding the best answer for you, we can followup there if you'd like?
[21:48] <tsimonq2> Not a prob :)
[22:23] <dbungert> sergiodj: I'm close to done with tinyxml2, looking at hiredis next


[00:04] <slangasek> Keybuk: this doesn't sound like an improvement to me
[00:04] <slangasek> at best, it sounds like needless churn...
[00:04] <Keybuk> slangasek: if the backup program runs as a known user, you can grant that in PK as a permanent authorisation
[00:04] <Keybuk> therefore it always has an ACL
[00:05] <slangasek> yes, you can - but why do that?
[00:05] <slangasek> what's the pk equivalent to adduser --system?
[00:05] <Keybuk> I don't understand, sorry?
[00:06] <slangasek> you're installing a backup package. you want the backup package to set itself up in the correct group when added.  Today, you do that by adding a system user and putting it in the disk group using standard commands.
[00:06] <Keybuk> ah, we're talking about different cases
[00:06] <ion_> I guess adduser --system ...; polkit-auth ...
[00:07] <Keybuk> sorry, I was thinking of a random user running a backup program
[00:07] <slangasek> ah
[00:07] <Keybuk> if they weren't authorised to access the disk, it would require some kind of better authorisation
[00:07] <Keybuk> ie. it'd pop up a dialog asking for the root password, or something
[00:07] <Keybuk> if they're an admin, it would instead ask for their password
[00:07] <Keybuk> etc.
[00:08] <Keybuk> but without setuid helpers
[00:08] <Keybuk> which are evil
[00:08] <slangasek> but I don't think giving end users full read access to the disks is ever the right thing either, whether it's brokered through policy kit or otherwise
[00:08] <Keybuk> you say "I want to access this device", and if you are allowed (by implicit, explicit or obtained authorisation) you get an ACL on it
[00:09] <Keybuk> the problem with the group-per-device model is that you need a group per device
[00:09] <Keybuk> e.g. that scard group
[00:09] <Keybuk> we have yet another class of device "smartcards"
[00:09] <Keybuk> so someone invents yet another system group
[00:09] <Keybuk> and then grants some application implicit access to those kinds of devices
[00:09] <Keybuk> or expects you to grant access to all users, etc.
[00:09] <ion_> Does policykit modify the actual filesystem ACLs and then reset them when the authorization expires?
[00:09] <Keybuk> ion_: HAL does that
[00:09] <slangasek> for devices where you routinely want to grant end-users access, I agree that the ACL model is better
[00:10] <slangasek> but you listed the 'disk' group, and I think that's a bug :)
[00:10] <Keybuk> slangasek: I think we can both agree background daemons are a special case
[00:10] <Keybuk> yeah disk was, I was typing dialout actually, then came back and saw "di" so finished with disk
[00:10] <Keybuk> obviously we don't normally place users in the disk group right now
[00:10] <slangasek> aha :)
[04:27] <fabbione> superm1: congrats on the mythtv release
[04:27]  * fabbione tests
[04:27] <superm1> thanks fabbione.  went surprisingly smooth :)
[04:27] <superm1> i need to pester someone in ~ubuntu-backporters now
[04:27] <superm1> and get it in gutsy
[04:27] <superm1> and we'll be done
[04:28] <fabbione> i hope they have fixed the .iso/dvd playback
[04:28] <fabbione> because i tested also normal DVD playback using Cars from Disney in a normal dvd player and it was royal crap
[04:29] <fabbione> and yes the dvd was original..
[04:31] <jdong> fabbione: Disney and Sony DVD's are horrendously awful to play on computers because of the ARCcOS crap they use
[04:31] <jdong> I can't even get mplayer to play some of these discs
[04:31] <fabbione> jdong: it used to play fine with older version of Mythtv
[04:31] <jdong> superm1: I'm no sick break, so no!
[04:31] <jdong> fabbione: ah, then you aren't affected
[04:31] <superm1> on sick break?
[04:31] <jdong> fabbione: but for the record High School Musical 2 is ARCcOS protected ;-)
[04:31] <fabbione> jdong: this is a regression i already discussed with superm1
[04:32] <jdong> (little sister. I swear.)
[04:32] <superm1> jdong, being on sick break is even more of a reason to ack such backport bugs :)
[04:32] <jdong> superm1: yes, no backporting while I'm vomiting :)
[04:32] <superm1> bah.
[04:32] <superm1> that
[04:32] <superm1> s boring
[04:32]  * Fujitsu strangles jdong for mentioning such a vile, vile movie.
[04:32] <jdong> superm1: not when it's possibly due to contamination of food utensils
[04:32] <superm1> wow that's horrible.
[04:33] <fabbione> jdong: i was able to reproduce that problem with several others non sony nor disney dvd's
[04:33] <jdong> Fujitsu: lol, I know. I scrubbed the images off my computer.
[04:33] <fabbione> jdong: some just don't start play.. others only audio.. other times only video
[04:33] <jdong> fabbione: ah different problem then
[04:33] <fabbione> and i am sure they used to work before 0.21*
[04:33] <fabbione> yup indeed
[04:33] <jdong> fabbione: I've had different issues with media players getting stuck in copy protection pits
[04:33] <jdong> annoying as hell, takes 30+ minutes to dig itself out and continue playing
[04:34] <jdong> ah the lengths the movie industry goes for annoying the consumer
[04:35] <fabbione> jdong: thing is that both mplayer and xine plays those DVD's just fine on the same machine
[04:35] <slangasek> their target audience is too young to have taken a civics class
[04:35] <fabbione> only mythtv interal player doesn't
[04:36]  * jdong kicks fglrx.
[04:36] <jdong> *cry* My tummy hurts, my head hurts, and fglrx corrupted my screen. How could my day get any worse?
[04:36] <superm1> it took your GPG key with it?
[04:36] <fabbione> your hd will die in a few minutes
[04:37] <jdong> lol you guys are evil
[04:37] <jdong> click.
[04:37] <fabbione> i don't remember any part of the CoC that explicity requires me _NOT_ to be evil :P
[04:38] <fabbione> oh speaking of GPG.. need to revoke a few uid's
[04:38] <superm1> jdong, well i'm doing the legwork on the backport and attaching the build logs and such.  so it will just need a shiny +1 attached from you when you are alive again
[04:39]  * Fujitsu revokes fabbione.
[04:39] <jdong> superm1: alright, that sounds good, thanks
[04:39] <ion_> fabbione: Please do not revoke mine.
[04:40] <fabbione> ion_: ?
[04:40] <fabbione> i can only remove uid's from my keys...
[04:40] <ion_> Just a poor attempt at a joke. :-)
[04:40] <fabbione> it's like 5:40am here.. have been awake all night cleaning my son's vomit and poking at xml
[04:40] <ion_> (Yeah, unless you’re a Chuck Norris.)
[04:41] <fabbione> ask yourself how much humor i have left in my body
[04:41]  * ChuckNorris bashes ion_
[04:41] <ion_> Better than cleaning your son’s xml and poking at vomit.
[04:41] <ion_> And i’m sorry your son is sick. :-(
[04:41] <fabbione> not your fault dude..
[04:41] <fabbione> he got somekind of bug 2 days ago
[04:42] <fabbione> high fever and all that crap
[04:42] <ion_> Sorry, as in feeling sorry for him.
[04:42] <fabbione> yeah
[04:42] <fabbione> thanks
[04:42] <ion_> How old is he?
[04:43] <fabbione> 18 months
[04:43] <jdong> aww poor kid
[04:44] <jdong> somehow, though, I think the parents suffer more than the kids
[04:44] <fabbione> jdong: you are so right on this
[04:44] <jdong> not in the sense of cleaning up, but watching a helplessly miserably toddler
[04:44] <fabbione> indeed
[04:45] <ion_> About the age of my nephew.
[04:45] <jdong> well, hope he gets better soon...
[04:45] <fabbione> yeah so do i
[04:45] <fabbione> also because when he is sick he hangs on my neck all the time like a little monkey
[04:45] <fabbione> he doesn't go to mummy at all
[04:48] <Hobbsee> fabbione: bet mummy's happy with that
[04:48] <jdong> fabbione: aww surely you've gotta feel some inner sense of satisfaction with that :)
[04:48] <fabbione> Hobbsee: indeed :)
[04:49] <fabbione> jdong: only when i am not dead tired
[04:54] <superm1> jdong, okay its bug 200044.  i'll subscribe ubuntu-backporters though in case someone else decides to grab it.
[04:55] <ubotu> Launchpad bug 200044 in gutsy-backports "MythTV 0.21 Suite backport" [Undecided,New] https://launchpad.net/bugs/200044
[04:55] <jdong> superm1: mmkay, the perl module is a new hardy package?
[04:55] <superm1> yeah
[04:55] <Hobbsee> what's up with tzdata?
[04:55] <superm1> i wanted to get it to debian too, but i dont have a sponsor yet for it in debian
[04:56] <Hobbsee> pitti: ping?
[04:56] <Hobbsee> Setting up tzdata (2007k-0ubuntu<IP_ADDRESS>) ...
[04:56] <Hobbsee> dpkg: error processing tzdata (--configure):
[04:56] <Hobbsee>  subprocess post-installation script returned error exit status 10
[04:56] <Hobbsee> Errors were encountered while processing:
[04:56] <Hobbsee>  tzdata
[04:58] <jdong> Hobbsee: guess it's too late!
[04:59] <Hobbsee> jdong: this is gutsy.  i'ts not supposed to break!
[04:59] <jdong> Hobbsee: it seemed to work fine for me when I applied it earlier today (as a data point)
[04:59] <Hobbsee> hmmm
[04:59] <superm1> an older release breaking from an update?  blasphemy !
[05:00] <Hobbsee> ahhh
[05:00] <Hobbsee> it's because i've changed the default timezone
[05:02] <Hobbsee> yeah, there we go.
[05:10] <superm1> jdong, er yeah you probably wanted a build log from the perl module too. i'll attach that.
[05:11] <jdong> superm1: nah I trust your word
[05:23] <dbmoodb> in case you don't know - broadcom pcmcia laptop card freezes on eject - have not given it the firmware yet - i assume this is to do with networking manager ....
[05:24] <jdong> is there a bug filed on this?
[05:24] <dbmoodb> --- i don't know i have just installed hardy and was testing it out
[05:24] <jdong> randomly coming into IRC with bugs rarely allows the message to reach the right people...
[05:25] <dbmoodb> yes i was hoping i would be told if some one was aware of one
[05:25] <dbmoodb> i am tired and was hoping that a bug had already been filed
[05:26] <jdong> :)
[05:26] <dbmoodb> sorry - wrong room should have joined ubuntu+1
[05:26] <jdong> not a problem
[05:26] <`Xenocide> the odds of someone else reporting this AND paying attention to IRC are low
[05:26] <dbmoodb> - should i repost it in there or are most people in both
[05:26] <`Xenocide> you might as well use launchpad itself to find similar bugs
[05:28] <dbmoodb> well i am not involved with ubuntu that much at this stage and have previously made a noise and a blah of my self in #ubuntu so i don't really want to do work for you guys - in a major form i am just testing hardy out of interest.
[05:29] <`Xenocide> well, the only way it gets fixed is if the people with the problem communicate with the people who can fix it
[05:29] <slangasek> I don't understand why you would want to test hardy and bother to report issues, but not report them in the manner than will get them fixed?
[05:31] <dbmoodb> because i don't want to get recognition for them because an attempt to contribute in an extended manner is not what i can do for the ubuntu community. i will give our cds but i am not wanting recognition online
[05:32] <`Xenocide> recognition, or responsibility?
[05:32] <dbmoodb> recognition
[05:36] <LaserJock> that didn't make a whole lot of sense
[05:50] <slangasek> LaserJock: clearly he's a famous Microsoft employee who doesn't want us to recognize him when he files bug reports :)
[05:51] <LaserJock> yeah ...
[05:52] <Hobbsee> he's not.
[05:52] <Hobbsee> (thank goodness)
[05:52] <Hobbsee> he's at my uni
[05:57] <slangasek> Hobbsee: oh. why is he being weird about bugfiling? :)
[05:58] <fabbione> slangasek: because the water spins the opposite direction in Down Under
[05:58] <Hobbsee> slangasek: nfi.
[05:59]  * fabbione starts to have nightmares about xml
[06:27] <Hobbsee> so, this is strange.
[10:52] <tjaalton> hm, what happened to the fonts.. they look "bigger" and fuzzier now
[10:56] <zdzichu_1> tjaalton: check workaround at second-to-last comment in https://bugs.launchpad.net/ubuntu/+bug/153521
[10:56] <ubotu> Launchpad bug 153521 in ubuntu "fonts are blurred with subpixel rendering" [Undecided,New]
[10:57] <afflux> Is this intended or will this be fixed eventually?
[10:58] <zdzichu_1> AFAIK this won't be fixed.
[10:59] <afflux> :(
[11:13] <tjaalton> zdzichu_1: thanks!
[11:13] <tjaalton> maybe that bug should be reassigned..
[11:13] <tjaalton> it's not against any package atm
[12:01] <Hobbsee> !ping
[12:01] <ubotu> ping yourself ;-) really the diodes all down my left side are sore
[14:37] <ompaul> !ops | sorry to be a pain - ubotu is currently lagged like crazy can't be fixed due to auth issues - please people in #ubuntu-ops and I'll can a spare bot to join and please mute ubotu
[14:38] <ompaul> ohh like that is going to be fun -- there will be a 20 min lag on reply or there abouts
[14:52] <ubotu> sorry to be a pain - ubotu is currently lagged like crazy can't be fixed due to auth issues - please people in #ubuntu-ops and I'll can a spare bot to join and please mute ubotu: Help! bhale, infinity, Hobbsee, jdub, thom, fooishbar, fabbione, mdz, lamont, or Keybuk
[14:55] <highvolt1ge> ubotu: ping?
[14:55] <ubotu> Sorry, I don't know anything about ping? - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[15:02] <ompaul> highvolt1ge, it was 20 mins before that we seem to be getting waves of this
[15:02] <ompaul> since yesterday
[15:03] <ompaul> seveas said he can't get secure access for a couple of days if it is problematic drop into #ubuntu-ops and request ubotwo if ubotu is muted
[15:25] <highvolt1ge> ompaul: ok thanks, doesn't seem serious (yet) though
[15:25] <ompaul> (tm) ;-)9
[16:10] <xsystemx>  Xlibs not found at -L/usr/X11R6/lib - How can I find out what package is required ?
[16:12] <crimsun> xsystemx: fix the build system; that path is deprecated
[16:13] <crimsun> xsystemx: in any case, you'd want at least libx11-dev, possibly more.  Check the log.
[16:14] <xsystemx> crimsun - just trying to install virtualbox from source?
[16:15] <xsystemx> crimsun - install all imaginable binary packages and still getting the error?
[16:16] <crimsun> xsystemx: you'd need some subset of "apt-get build-dep virtualbox-ose"
[16:17] <crimsun> xsystemx: may be better directed to #ubuntu-motu, in fact
[16:17] <xsystemx> crisum - motu = ?
[16:29] <pochu> jcastro: hello, I have a question regarding UDS, do you have a moment for a /msg ?
[16:44] <afflux> Apport is doing weird things these days. ubuntu-crashes-* isn't subscribed to some bugs (for example bug 199846, which was reported by myself), some bugs just don't have the "need-*-retrace" tags (bug 199911) the retracer simply removes the "need-*-retrace" tags (also bug 199846). Anyone knows what's going on?
[16:44] <ubotu> Bug 199846 on http://launchpad.net/bugs/199846 is private
[16:44] <ubotu> Launchpad bug 199911 in emerald "emerald crashed with SIGSEGV in gdk_gc_new_with_values()" [Undecided,New] https://launchpad.net/bugs/199911
[16:44] <ubotu> Bug 199846 on http://launchpad.net/bugs/199846 is private
[16:44] <afflux> (I manually added the need-i386-retrace tag to 199911)
[16:51] <Adri2000> who takes care of https://lists.ubuntu.com ? I doubt ubuntu-qa is a loco team :)
[16:52] <LaserJock> depends on which "loco" they're talking about ;p
[16:53] <Adri2000> :p
[19:01] <m8ram> is this the right place for general questions on developing packages?
[19:01] <james_w> m8ram: not really. #ubuntu-motu may be better.
[19:01] <m8ram> thx, will check it
[19:10] <m8ram> james_w: ubuntu-motu is specific for ubuntu, do you have an idea where I can get some directions on how to become an upstream developer as well?
[19:12] <andrea-bs> m8ram: you should contact the upstream developers
[19:13] <m8ram> andrea-bs: that's exactly the problem: I'd like to work on/help with the abcde package but the upstream developer (who is also the debian maintainer) appears to have abandoned the project
[19:13] <andrea-bs> m8ram: did you try to contact him?
[19:14] <m8ram> andrea-bs: I have sent him an email several months ago requesting him where to send feature requests but got no reply, this afternoon I sent an email to<EMAIL_ADDRESS>to see if he is considered MIA or not
[19:15] <m8ram> andrea-bs: in any case the package has not been touched since sarge, even though various patches are available in the debian bug tracker system
[19:16] <m8ram> for ubuntu the maintainer is set to Ubuntu MOTU developers
[19:19] <andrea-bs> m8ram: the project has a Mailing List, did you know?
[19:20] <m8ram> andrea-bs: haven't found it yet
[19:20] <m8ram> andrea-bs: the SVN repos gives an error 503 service unavailable...
[19:20] <jdong> yay svnadmin recover.
[19:21] <andrea-bs> m8ram: I'm reading the readme from the ubuntu package
[19:22] <m8ram> andrea-bs: the archives of the old mailing list appear to have been taken offline
[19:22] <m8ram> andrea-bs: and the readme itself says that the new list was at that time not activley used
[19:23] <m8ram> andrea-bs: last message on this list is from March 2007
[19:24] <m8ram> andrea-bs: and it's in spanish...
[19:24] <andrea-bs> m8ram: I can see that it's developed in debian, did you try to contact debian developers?
[19:25] <m8ram> andrea-bs: not yet, other than the mail I sent to<EMAIL_ADDRESS>(not .com as I wrote earlier)
[19:26] <m8ram> andrea-bs: but the maintainer at debian is also Jesus Climent, the upstream author
[19:27] <andrea-bs> m8ram: I know, but this package is not maintained in ubuntu so I think you will have more chances with debian devs
[19:28] <m8ram> andrea-bs: ok, do you know where I could find them?  I couldn't find an IRC channel for debian devel yet (I'm not really used to IRC)
[19:29] <andrea-bs> m8ram: maybe #debian, but I'm not sure
[19:29] <m8ram> andrea-bs:and debian-qa was really quiet earlier today
[19:29] <m8ram> andrea-bs: thx, will check
[19:45] <pochu> m8ram: irc.debian.org, #debian-devel
[19:45] <m8ram> pochu: thx, will check it
[20:12] <m8ram> thx: the original author appears to be on #debian-devel, hasn't responded yet but at least I'm at the right place
[21:55] <pwnguin> is there a wiki for summer of code ideas yet?
[22:30] <Amaranth> pwnguin: brainstorm.ubuntu.com
[22:34] <pwnguin> the fun part about brainstorm is taking what they say and interpreting what they really want / need
[22:42] <pwnguin> it's a bit like those GIMP / GNOME makeovers where the mockup is just a photoshop of what they want, with no considerations for what's feasible.
[23:32] <TheMuso> Wow! Nice that the config file prompting is now via debconf. Slick. :)
[23:57] <TheMuso> 5~/c


[00:14] <ogasawara> jjohansen: could you help take a look at bug 624915
[00:14] <ubot2> Launchpad bug 624915 in linux (Ubuntu Maverick) (and 3 other projects) "maverick kvm guests not seeing virtio disks (affects: 1) (heat: 6)" [High,Confirmed] https://launchpad.net/bugs/624915
[00:23] <RAOF> ogasawara: Yeah, those (or specifically the intel ones) are the patches I'm thinking of.
[00:24] <ogasawara> RAOF: I've been trying to find the irc logs to back up what I remember, but I've been unsuccessful.  Basically what I "recall" is that we purposely didn't carry those kms-disablement patches forward to Maverick as they appeared to be a temporary work around at the time and we were hoping to see a proper fix in Maverick.
[00:24] <ogasawara> RAOF: Obviously if that's not the case I'm can reapply them to Maverick.  Just let me know.  And I assume you'd want all 6 patches reapplied
[00:24] <ogasawara> ?
[00:26] <ogasawara> or just the intel ones?
[00:26] <RAOF> All the intel ones, certainly; we've given up on them working properly.
[00:27] <RAOF> (For Maverick, at least.  Maybe, *maybe* the “throw a flock of writes at the GTT and wait untill they stick” patch will be in Natty's kernel)
[00:27] <ogasawara> RAOF: do you want the radeon ones too just for good measure?
[00:28] <RAOF> This is where I want an inverse-launchpad.
[00:28] <RAOF> Where I can go and see “hey, everyone with a ES1000 is doing fine” :/
[00:29] <jjohansen> ogasawara: sure
[00:29] <ogasawara> jjohansen: thanks
[00:30] <ogasawara> RAOF: I can get these applied no problem.  we are in beta freeze though so the actual upload will have to wait till post beta.  we can add a beta release note though.
[00:31] <RAOF> ogasawara: So, I haven't found any new bugs on the ES 1000 for Maverick.  Maybe that means kms is working for it now.
[00:31] <ogasawara> RAOF: hrm, so maybe we still leave that patch out then
[00:32] <RAOF> Yeah.  Keep an eye on it, but leave it out for now.
[00:32] <ogasawara> RAOF: ack
[01:32] <jj-afk> back on later
[12:07]  * amitk smiles at GregKH poking fun at Ubuntu's colors: http://lwn.net/Articles/402328/rss
[13:06] <lamont> Found Xen hypervisor 3.2,  kernel: /boot/vmlinuz-2.6.24-28-xen.dpkg-tmp
[13:06] <lamont> giggle
[13:07]  * smb is not sure he wants to know how that happened
[13:09] <lamont> it went away before the end of the package install
[13:09] <lamont> that was just apt-get dist-upgrade
[13:09] <smb> Ah, then I guess I can relax again :)
[13:10] <lamont> well, it probably shouldn't notice .dpkg-* kernels
[13:12] <smb> Maybe, but it would be a update-grub problem which is nothing I need to immediately worry. At least not enough to cause a Friday boc delay.
[13:13] <lamont> correct
[13:13] <lamont> boc?
[13:13] <smb> beer o clock
[13:13] <lamont> beer on
[13:14] <smb> not yet
[13:14] <smb> About 3hrs away, though
[14:30] <tseliot> mjg59: do you know if there are any additional power savings that we could do with radeon and RS880 (e.g. in the Northbridge) so as to make laptops run cooler? (The RS780 guides on AMD's website should also be relevant for the RS880)
[14:32] <tseliot> mjg59: I'm using kernel 2.6.35 (and I've also tried some patches to disable plls for display controllers that are not in use, without heat reduction though)
[15:13] <rafael_n_azevedo> good morning
[15:14] <rafael_n_azevedo> i'd like to know if i compile a kernel vanilla i will lose something ?
[15:16] <rafael_n_azevedo> because i'm using lucid n i'd like to compile it
[15:23] <bjf> rafael_n_azevedo: if you get the right sources and build correctly you shouldn't "lose" anything  https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
[15:23] <bjf> rafael_n_azevedo: why do you want to build your own kernel?
[15:24] <rafael_n_azevedo> just to compile it on my laptop to "run better"
[15:24] <rafael_n_azevedo> or u think isn't necessary
[15:24] <bjf> rafael_n_azevedo: that implies that you are going to change something and that you know what to change to make it "run better"
[15:25] <bjf> rafael_n_azevedo: i don't think it's necessary
[15:26] <rafael_n_azevedo> the realy thing it that i would like to learn it
[15:26] <rafael_n_azevedo> to learn to compile a kernel
[15:27] <bjf> rafael_n_azevedo: well, see the link i posted above and give it a shot
[15:27] <rafael_n_azevedo> ok thanks a lot
[15:44] <ogasawara> GrueMaster: hiya, thanks for jumping in here, just wanted to inquire about bug 605488
[15:44] <ubot2> Launchpad bug 605488 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "BUG: scheduling while atomic: mmcqd/46/0x00000002 (affects: 2) (heat: 12)" [High,In progress] https://launchpad.net/bugs/605488
[15:45] <ogasawara> GrueMaster: seems like the original conditions (ie swap enabled) to trigger the bug are not the same with the latest images
[15:45] <ogasawara> GrueMaster, lag: do either of you know if swap will be re-enabled in later images?
[15:45] <GrueMaster> Unfortunately we haven't had a properly working image since Alpha 3 to test this.
[15:45] <ogasawara> GrueMaster: ah
[15:46] <GrueMaster> And ogra would know more about whether or not swap will be reenabled.
[15:46] <ogasawara> GrueMaster: for now then I'm going to leave the bug open for tracking purposes.
[15:46] <ogra> i only disabled it because of the existing bugs
[15:47] <ogra> but it appears nobody can reproduce it anymore
[15:47] <GrueMaster> I'm pulling today's images.  If I can get them to work somewhat, I will reenable swap and test this.
[15:47] <ogasawara> ogra: so would you consider if ok to close the bug for now?  or would you rather we leave it open into better testing can be done.
[15:48] <ogra> close it and lets see if it comes up again ... we can always re-open
[15:48] <ogasawara> ogra: ack, thanks
[15:48] <ogasawara> GrueMaster: if it re-appears after your testing, re-open the bug.
[15:48] <GrueMaster> ok
[18:36]  * smb is out
[19:44]  * ogasawara lunch
[21:48] <MarkKohler> I'm tracking down a mostly repeatable crash in ath5k, but when I switched from the Lucid kernel to the packaged mainline kernel, I stopped getting crash dumps. Any ideas on why that would be, or how I can get crash dumps with the mainline kernel?
[23:15] <nUboon2Age__> I'm having trouble with trying to run 2.6.32-24.  I get "Error: cannot read the Linux header.. error: you need to lead the kernel first.  Failed to boot both default and fallback entries.  Press any key to continue."  If i press a key it just gives the same error.  I'm with Jono at a Global Jam and he recommended you all might be of help.
[23:20] <nUboon2Age__> JFo-swap: we're listening to "Cooking by the Book".. Jono shared it w/ us
[23:48] <[reed]> I'm trying to get the packages from bug 554099 for lucid, but I'm having a hard time. I added ppa:kernel-ppa/pre-proposed, but now I'm getting errors complaining about symbol module_layout version disagreement and such
[23:48] <ubot2> Launchpad bug 554099 in linux-backports-modules-2.6.32 (Ubuntu Maverick) (and 9 other projects) "Qualcomm Gobi 2000 3G (gobi_loader/qcserial) broken (affects: 56) (dups: 4) (heat: 341)" [Undecided,Invalid] https://launchpad.net/bugs/554099
[23:48] <[reed]> should I have only pulled a specific package or something?
[23:49] <[reed]> or what exactly


[00:00] <LaserJock> so i think somebody in LP made the other branches
[00:00] <LaserJock> because as bad as 1 branch is, i really want 4 of them
[00:00] <abentley> spiv: Were there any bugs in the format detection in 1.2?
[00:00] <spiv> abentley: I'm not sure.  I don't see anything in NEWS about it.
[00:01] <LaserJock> abentley: can I force it?
[00:01] <bob2> co uses the bzr default branch format, instead of the remote format
[00:01] <spiv> abentley: I do vaguely recall something got fixed in that area, but I think before 1.2?
[00:02] <abentley> Oh, doh.  I forgot I defaulted checkout to --lightweight.
[00:03] <LaserJock> ohh
[00:03] <abentley> Yeah, I get that failure too.
[00:04] <LaserJock> k, so I'm not nuts
[00:04] <LaserJock> doing the checkout now
[00:05] <abentley> The way to force it is: bzr init --dirstate-with-subtrees $DIR; cd $DIR; bzr pull bzr+ssh://bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy;
[00:05] <schierbeck> hey guys
[00:05] <jml> something weird just happened to me
[00:06] <ubotu> New bug: #206886 in bzr "bazaar send should support inlined content" [Undecided,New] https://launchpad.net/bugs/206886
[00:06] <jml> I tried branching using 'bzr+ssh' from a server -- worked fine. Then I did branch using 'sftp' from the same server and got an authentication error.
[00:06] <warren> Can a bzr smart server prevent clients from deleting tags?
[00:07] <jml> the same machine appears under a different hostname & using a different port in my .ssh/config
[00:07] <LaserJock> abentley: but will that be fast? doing a bzr pull?
[00:07] <jml> and when I use sftp://hostname:22/, branch works.
[00:07] <warren> BTW, does pack-92 automatically mean you also have dirstate-tags?  (or the ability to do bzr tagging)
[00:08] <jml> is Bazaar using one mechanism for bzr+ssh and another for sftp?
[00:08] <bob2> warren: yes, pack-0.92 includes tag support
[00:08] <abentley> LaserJock: It certainly ought to be.
[00:08] <spiv> jml: it shouldn't, IIRC
[00:09] <LaserJock> abentley: and it won't let me do --dirstate-with-subtrees
[00:09] <abentley> my bad, no 's' on the end.
[00:09] <lifeless> LaserJock: the training trees were meant to be getting upgraded by tetet
[00:10] <lifeless> LaserJock: setup a local repository for them, then the cost of all 4 is minimally more than the cost of 1
[00:10] <jml> maybe it's a bug in openssh
[00:10] <warren> bob2, thanks for the clarification.
[00:10] <LaserJock> lifeless: can I do that with an existing branch?
[00:11] <spiv> ValueError: invalid literal for int() with base 10: '# Loom'
[00:11] <spiv> http://rafb.net/p/PiTZ3863.html  has the full error.
[00:13] <lifeless> LaserJock: yes; make the repo locally, then bzr branch your existing branch into it
[00:13] <LaserJock> lifeless: oh!
[00:13] <LaserJock> I have an edubuntu-docs branch right here
[00:14] <spiv> lifeless: I just got an error pulling the loom trunk into my local copy, but it was resolved when I upgraded my local branch from dirstate to pack-0.92.
[00:14] <lifeless> spiv: bizarre
[00:14] <spiv> lifeless: full traceback in the pastebin above
[00:15] <lifeless> just looks like a corrupt file
[00:15] <spiv> lifeless: want a copy of the troublesome branch?  Or a bug report?
[00:16] <lifeless> spiv: it looks like the knit code being handed a loom current file
[00:16] <lifeless> spiv: which is really bizaare
[00:17] <lifeless> spiv: uhm, if you can make it reproducable sure
[00:17] <spiv> lifeless: yep, I can reproduce.
[00:18] <lifeless> cool <damn>
[00:18] <spiv> :)
[00:18] <lifeless> then I'd like enough stuff to reproduce it please :)
[00:18] <abentley> I can't reproduce spiv's error, though I think I've seen it before.
[00:19] <spiv> lifeless: http://people.ubuntu.com/~andrew/loom-pull-case.tar.gz has the branch
[00:19] <LaserJock> hmm, so how do I make a share repository?
[00:19] <spiv> lifeless: I simply did "bzr pull", which pulled from bzr+ssh://bazaar.launchpad.net/~bzr-loom-devs/bzr-loom/trunk/
[00:20] <warren> lifeless, btw, if I'm converting a huge repository from dirstate to pack-92, should I use bzr-1.3 or is 1.1 fine?
[00:20] <lifeless> LaserJock: for a svn converted project, bzr init-repo --rich-root-pack path
[00:20] <lifeless> warren: 1.1 is fine
[00:20] <ubotu> New bug: #206890 in bzr "Help pages for merge and pull should tell users about bundles" [Undecided,New] https://launchpad.net/bugs/206890
[00:20] <lifeless> warren: after the conversion, just run bzr reconcile
[00:22] <warren> Do tags come across in merges?
[00:23] <warren> foo-trunk> pull ../foo-bar (which has its own tags); bzr merge; bzr ci, are tags from foo-bar visible in foo-trunk now?
[00:25] <LaserJock> lifeless: so does a shared repo mean that a new branch will take common revisions from the local repo?
[00:26] <abentley> lifeless: PQM has committed my last merge request, but not published it.
[00:26] <abentley> Could you give it a whack please?
[00:27] <lifeless> abentley: 'log' ?
[00:27] <lifeless> abentley: was the merge request for yoru log changes ?
[00:28] <abentley> No, it was for pulling lp: locations
[00:28] <lifeless> so if pqm didn't publish, it will have rolled back
[00:28] <lifeless> let me look for an error
[00:29] <abentley> Last time I tried, it told me "nothing to merge".
[00:29] <lifeless> ok; weird then
[00:33] <LaserJock> dang, even a local branch takes quite some time
[00:33] <LaserJock> I seriously wonder if we shouldn't just start over
[00:34] <abentley> LaserJock: You're branching from a location in your shared repo into another location in your shared repo?
[00:34] <LaserJock> no
[00:34] <LaserJock> from a branch I already had outside my shared repo into the shared repo
[00:35] <LaserJock> but it's still local
[00:35] <abentley> A branch in a different format?
[00:35] <LaserJock> no
[00:35] <LaserJock> I don't think so
[00:35] <abentley> lifeless told you to use rich-root-pack.  You didn't?
[00:35] <LaserJock> yep, same formate
[00:36] <LaserJock> oh, you're right
[00:36] <LaserJock> ok, that makes sense then
[00:36] <abentley> So what you are hitting is an unoptimized conversion path.
[00:36] <LaserJock> can two bzr instances run at the same time?
[00:36] <abentley> Sure.
[00:37] <abentley> They can't both write to the same thing at the same time, of course.
[00:37] <LaserJock> I started doing the local branch at the same time I'm doing a bzr pull
[00:37] <LaserJock> and the bzr pull doesn't seem to be doing anything
[00:37] <abentley> You should probably wait until the local branch is done anyhow.
[00:38] <abentley> But bzr+ssh doesn't give great progress indicators.
[00:38]  * LaserJock notes that after 26 min :-)
[00:39] <LaserJock> so it looks like it's gonna be about 40 min to do the local branch
[00:39] <abentley> How big is this data?
[00:40] <LaserJock> well, the branch is 217MB
[00:40] <LaserJock> .bzr is 211MB
[00:41] <LaserJock> that's why I'm wondering about starting over
[00:41] <LaserJock> we're carrying so much history around for like 6MB
[00:43] <abentley> That seems extremely disproportionate.
[00:43] <LaserJock> well, the size of the "working tree" has grown and shrunk quite a bit with time
[00:44] <LaserJock> the size of the files in my branch probably won't ever get over ~20MB
[00:44] <LaserJock> but the ubuntu-docs branch is probably more like 100-150MB
[00:47] <LaserJock> it's just a frustration because it used to take < 5min or so to do a SVN checkout and that worked well for us
[00:47] <LaserJock> we're trying to get to the same level with bzr
[00:47] <LaserJock> but I think our project is not a great example :/
[00:48] <lifeless> LaserJock: once you have your repo seeded, upgrade it to rich-root-pack, because that is lots faster :>
[00:49] <LaserJock> you mean push the new branch back up to LP?
[00:49] <spiv> LaserJock: with a shared repo locally and rich-root-pack as the format, it'll be much snappier.  The coming stacked branches feature will also help.
[00:51] <LaserJock> spiv: I hope so :-)
[00:52] <lifeless> LaserJock: no, I don't mean push
[00:53] <LaserJock> I guess I didn't get it then
[00:53] <LaserJock> what branch do I want to upgrade?
[00:53] <LaserJock> the one I'm making should be already rich-root-pack right?
[00:54] <lifeless> abentley: your patch is published
[00:54] <abentley> lifeless: tx
[00:54] <lifeless> LaserJock: what does bzr info on the repository you created say its format is ?
[00:56] <LaserJock> lifeless: just a sec, it's just finishing branching
[00:57] <LaserJock> Shared repository with trees (format: rich-root-pack)
[00:57] <LaserJock> that's the share repo obviously
[00:57] <LaserJock> and the new branch is:
[00:57] <LaserJock> Repository tree (format: rich-root-pack)
[00:57] <LaserJock> so that took about 36min to branch locally, just FYI
[00:59] <LaserJock> now I'm trying a bzr branch of one of the other branches
[01:01] <LaserJock> ohh, that's much better
[01:08] <lifeless> james_w: so, were did we get to
[01:09] <lifeless> james_w: right, file ids. are they deterministically allocated? do you generate correct merge graphs? (that is, does 'bzr check' give no errors on an imported branch)
[02:23]  * igc food
[02:24] <nir> where is bzr 1.3 for ubuntu?
[02:25] <nir> https://launchpad.net/~bzr/+archive contains only 1.2.1
[02:25] <kgoetz> aiui, coming
[02:46]  * mneptok jumps up and down on kgoetz
[02:46]  * kgoetz bruises painfully
[02:48] <mneptok> how's tricks, Kaiserlicious?
[02:49] <kgoetz> mneptok: pretty good. gobuntu is a bit quiet atm, but other things i;m involved in a fairly lively :)
[02:51] <kgoetz> how is the support hotseat these days?
[02:56] <mneptok> kgoetz: getting hotter as more customers don;t like the fact we don't officially support Hardy yet
[02:58] <jamesh> mneptok: I'd have thought they'd have moved on to Intrepid by now.
[02:58] <kgoetz> mneptok: hehe. and i assume it'll keep warming up until well after release
[02:58] <mneptok> kgoetz: you got that right
[02:59] <mneptok> jamesh: usually that's ~3m after libc drops into the next release ;)
[02:59] <kgoetz> ;)
[03:08] <eugeneoden> anyone here familiar with bzr-loom?
[03:08] <spiv> Several, including me.
[03:10] <lifeless> yay get_parents hath died
[03:14] <eugeneoden> spiv: hello.  you helped me with bzr-svn branch problem last monday at the sprint.  on the plane i started working on a deloomify command for bzr-loom and was wondering if anyone else was interested in that functionality.
[03:15] <jelmer> lifeless: btw, if you think setting the inventory_sha1 to "" in bzr-svn is a bad idea, please speak up :-)
[03:16] <lifeless> jelmer: its a terrible idea
[03:16] <spiv> eugeneoden: I think so, jam filed some bugs on bzr-loom including one asking for a command to deloomify.
[03:16] <lifeless> eugeneoden: I think you'll find that that is in the TODO already :)
[03:17] <spiv> eugeneoden: https://bugs.edge.launchpad.net/bzr-loom/+bug/203285
[03:17] <ubotu> Launchpad bug 203285 in bzr-loom "unable to "de-loom" a branch" [Undecided,New]
[03:17] <eugeneoden> cool.  i might have seen it somewhere - i'm not familiar enough with this stuff to come up with changes on my own.
[03:18] <jelmer> lifeless: worse than using a sha1 from a semi-random serializer?
[03:18] <lifeless> jelmer: well, perhaps you might be more clear about what you mean
[03:18] <lifeless> jelmer: do you mean 'when you call repository.get_revision(X) on a SvnRepository, the inventory_sha1 will be blank'
[03:19] <lifeless> jelmer: or do you mean 'the revisions in a pack repository pulled from SvnRepository have an inventory_sha1 of ""' ?
[03:22] <lifeless> jelmer: or perhaps you mean both
[03:22] <lifeless> jelmer: so for the former, I think None is appropriate if svn has no validator
[03:23] <lifeless> jelmer: for the latter it must be the validator returned by add_inventory (which will be the case if you use anything other than the lowest level apis for inserting into the pack repository)
[03:26] <eugeneoden> spiv, lifeless: i took a brute-force approach to start with - deleting last-loom and reverting the branch format.  ran into locking issues - LoomSupport.unlock() attempts to record any changes before calling the superclass unlock() and fails if last-loom has been deleted.
[03:28] <lifeless> eugeneoden: I suggest: lock(); write new format, unlock(), delete last-loom in that order
[03:28] <lifeless> it will have to be a valid loom at unlock time
[03:28] <eugeneoden> makes sense
[03:30] <eugeneoden> lifeless: would it be better to insist that all threads have been combined except for the last implicit one or should deloomify combine all threads, leaving the contained changes as uncommited modifications?
[03:31] <jelmer> lifeless: But add_revision takes an inventory already - there should be no need to call add_inventory
[03:32] <lifeless> jelmer: right, add_revision(...,inventory=X) does sha1 = self.add_inventory(X); revision.inventory_sha1=sha1; self._add_revision...
[03:32] <lifeless> jelmer: but! you shouldn't be calling add_revision anyhow, we built CommitBuilder just for you :>
[03:33] <lifeless> eugeneoden: I would say that you must have one and only one thread or supply a --force.
[03:33] <lifeless> eugeneoden: and on force it wouldn't need to do any complex stuff, just skip the check.
[03:34] <eugeneoden> ok, sounds good.
[03:34] <jelmer> lifeless: heh, commit builder is only used for the other way around :-)
[03:35] <jelmer> lifeless: add_revision doesn't appear to set revision.inventory_sha1
[03:35] <spiv> jelmer: I'm getting 'bzr: ERROR: Revision {('svn-v3-trunk0:bbbe8e31-12d6-0310-92fd-ac37d47ddeeb:trunk:22922',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x8c7c74c>".' when I try to update my Twisted import with current bzr-svn stable
[03:37] <jelmer> spiv: does "bzr selftest svn" pass?
[03:37] <jelmer> spiv: if not, please file a bug
[03:37] <jelmer> I'm getting some sleep :-)
[03:38] <lifeless> bbiab
[03:39] <spiv> jelmer: ok
[03:39] <spiv> jelmer: thanks
[03:41] <lifeless> yay internode suckage
[03:41] <lifeless> jelmer: if you replied to me, I missed it
[03:41] <lifeless> 14:30 < jelmer> lifeless: But add_revision takes an inventory already - there should be no need to call add_inventory
[03:41] <lifeless> 14:31 < lifeless> jelmer: right, add_revision(...,inventory=X) does sha1 = self.add_inventory(X); revision.inventory_sha1=sha1; self._add_revision...
[03:41] <lifeless> 14:32 < lifeless> jelmer: but! you shouldn't be calling add_revision anyhow, we built CommitBuilder just for you :>
[03:41] <lifeless> 14:32 < lifeless> eugeneoden: I would say that you must have one and only one thread or supply a --force.
[03:41] <lifeless> 14:32 < lifeless> eugeneoden: and on force it wouldn't need to do any complex stuff, just skip the check.
[03:41] <lifeless> 14:33 < lifeless> bbiab
[03:41] <lifeless> 14:38 -!- lifeless<EMAIL_ADDRESS>has joined #bzr
[03:43] <spiv> lifeless: he replied:
[03:43] <spiv> 14:34 < jelmer> lifeless: heh, commit builder is only used for the other way around :-)
[03:43] <spiv> 14:35 < jelmer> lifeless: add_revision doesn't appear to set revision.inventory_sha1
[03:43] <spiv> And he also said < jelmer> I'm getting some sleep :-)
[03:43] <spiv> lifeless: and with that, I think you're back in sync
[03:44] <lifeless> yay bugs
[03:44] <lifeless> jelmer: thats clearly a bug; care to fix ?
[03:53] <poolie> lifeless: nice response to sjturnbull
[03:54]  * lifeless bows
[04:08] <LaserJock> lifeless: so in the end I the branching into the shared repo too 36 min and a subsequent bzr branch of another ubuntu doc branch took 90 min
[04:09] <LaserJock> if that makes any sense
[04:11] <lifeless> LaserJock: into the same shared repo ?
[04:11] <LaserJock> yeah
[04:11] <lifeless> LaserJock: what does 'bzr info' on the second branch (in the repo) say
[04:11] <LaserJock> Repository tree (format: rich-root-pack)
[04:12] <LaserJock> and it said it's part of the shared repo
[04:12] <lifeless> ok
[04:12] <lifeless> 90 minutes - I have to guess that the remote format is knits
[04:13] <LaserJock> it's interesting that there is such a difference in repo sizes
[04:13] <LaserJock> the edubuntu-docs branch (the one I did the local branch into the shared repo) is 5.5MB
[04:14] <LaserJock> the ubuntu-docs branch which is the one I did the bzr branch on afterwards is 205MB
[04:14] <lifeless> LaserJock: did you do that one into the shared repo ?
[04:15] <LaserJock> yes
[04:15] <LaserJock> I guess the .bzr is small though
[04:15] <lifeless> can you ls .bzr/ on that one ?
[04:15] <LaserJock> the first is 108K and the second is 1.4M
[04:16] <LaserJock> so it's just a difference in "working tree" size
[04:16] <LaserJock> and the shared repo .bzr is 198MB
[04:16] <lifeless> ok
[04:17] <LaserJock> so it looks like the shared repo is working well
[04:17] <lifeless> perhaps the svn conversion used silly svn 'branch' layers, and grabbed too much data.
[04:18] <LaserJock> 90 min isn't great, but at least it's a lot better than doing the whole stinkin' thing
[04:18] <LaserJock> I believe it only had to get 178 revisions to do the ubuntu-docs branch
[04:18] <LaserJock> seems like 90 min for 178 revisions is a lot
[04:20] <LaserJock> we're at revision 3781 so if that scaled that means it would take almost 32 hrs to do the full branch
[04:20] <LaserJock> so it must take a lot to do the conversion between formats
[04:20] <lifeless> whats the url of the second branch you made? the launchpad url I mean
[04:20]  * igc bbl - school pickup today
[04:21] <LaserJock> http://bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy/
[04:26] <LaserJock> lifeless: btw, I really do appreciate your help and all the effort the bzr team puts into bzr and the LP hosting
[04:27] <LaserJock> sorry if my frustration and inability to "get" bzr sometimes made me seem cranky
[04:33] <lifeless> LaserJock: bzr info http://bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy/
[04:33] <lifeless> Standalone branch (format: dirstate-with-subtree)
[04:33] <lifeless> Location:
[04:33] <lifeless>   branch root: http://bazaar.launchpad.net/%7Eubuntu-core-doc/ubuntu-doc/ubuntu-hardy/
[04:33] <lifeless> LaserJock: ^ its in knit format, which means lots of round trips
[04:33] <lifeless> LaserJock: as I thought :>
[04:33] <lifeless> chat to tetet about this :)
[04:34] <LaserJock> so maybe we can get that changed on the LP server?
[04:35] <LaserJock> this shared repo stuff is fantastic
[04:45] <lifeless> ;)
[04:48] <LaserJock> now, is it right that I can remove everything from a branch but the .bzr/ without ill effect?
[04:49] <lifeless> LaserJock: 'bzr remove-tree'
[04:49] <LaserJock> hot dog
[04:50] <abentley> bad lifeless: please promote "reconfigure --branch" instead.
[04:50] <LaserJock> so now I have  both edubuntu-docs and ubuntu-docs branches and it's 14MB *smaller* than my previous edubuntu-docs branch
[04:51] <lifeless> abentley: perhaps 'bzr remove-tree' could do that advertising for me :)
[04:52] <lifeless> jelmer: thanks
[04:52] <LaserJock> abentley: how would I then get the tree back, reconfigure --tree?
[04:53] <abentley> LaserJock: Right.
[04:55] <LaserJock> I'm kinda confused/amazed. How can the ubuntu-hardy .bzr only be 40K?
[04:55] <LaserJock> there's 178 revisions difference between the edubuntu-hardy and ubuntu-hardy branches
[04:55] <lifeless> LaserJock: the .bzr in a shared repository only contains the branch pointer
[04:55] <LaserJock> does it store all revisions in the shared repo and then the individual branches only hold what revisions belong to the branch
[04:56] <LaserJock> I was thinking it would hold the revisions that were not in common
[04:58] <lifeless> that would reqire continual shuffling to keep that property
[04:58] <lifeless> all it does is move the database out of the branch and to a centralised location
[05:29] <poolie> abentley: i haven't read all of all the threads, but i don't think there is a standard way to launch them
[05:30] <poolie> it is basically like unix MUAs
[05:31] <poolie> in that to control them in detail, you need to use which one you're calling
[05:31] <poolie> i may be out of date though
[05:31] <abentley> poolie: But at least Gnome and KDE provide a standard way of launching them, to say nothing of Windows and Mac.
[05:31] <lifeless> gnome and kde focus on usability though
[05:31] <lifeless> the standard way to configure emacs is to write lisp
[05:32] <abentley> I just don't want to wind up with an endless proliferation of mail clients.
[05:32] <lifeless> me neither
[05:33] <lifeless> We could say 'get your client registered with xdg-mail'
[05:33] <poolie> well
[05:33] <lifeless> but that doesn't deliver a fix to the users in the short term
[05:33] <abentley> That requires a GUI desktop, I think.  I could see backlash.
[05:33] <lifeless> we could promote a 'sensible-mail' alias for debian* systems :>
[05:34] <abentley> Does debian not provide a "sensible-editor"?
[05:34] <bob2> it does
[05:34] <abentley> I meant "sensible-mail".
[05:34] <abentley> It's late.
[05:34] <lifeless> it does, but editor & mail client are different I thought :>
[05:34] <lifeless> there is no sensible-mail on my system
[05:34] <jdong> sensible-editor Conflicts: emacs *ducks*
[05:34]  * TFKyle wonders what it is, nano or something?
[05:34] <abentley> jdong: Hey, play nice.
[05:34] <jdong> :)
[05:35] <abentley> They're Bazaar users now, we should make them feel welcome.
[05:35] <lifeless> let me register right now
[05:36] <lifeless> that if php switches to bzr
[05:36] <lifeless> I will _not_ stop trolling
[05:36] <LaserJock> :-)
[05:37] <bob2> check out the flock() page in the user-editable php docs sometime
[05:37] <TFKyle> think it'd be very hard to convert their cvs repo to bzr anyway (well, need a bit of automagic encoding detection iirc, the commits are in various encodings)
[05:37] <TFKyle> s/commits/commit messages/
[05:38] <bob2> how does cvs handle that?
[05:38] <bob2> just throw raw bytes at the terminal with 'cvs log'?
[05:38] <lifeless> cvs spits at encodings
[05:38] <TFKyle> think so
[05:38] <lifeless> TFKyle: if you detected each one well, you could stuff it into bzr just fine
[05:39] <lifeless> TFKyle: unless a single commit had multiple encodings :>
[05:52] <lifeless> k gents, thats all she wrote;
[05:54] <bob2> that emacs patch unfairly discriminates against gnus users, anyway
[05:56] <abentley> lifeless: What if MySQL switches?
[06:04]  * abentley clocks out of the channel just after an Oz resident.
[06:16] <ufuntu> hello :)
[08:25] <mdke> hi there. We at the ubuntu-doc project have completed our first release cycle of using bzr, it's gone relatively well! However our branch history is pretty huge so we're just trying to decide whether to start a fresh branch for the next cycle. I'd like feedback on potential advantages and disadvantages
[08:26] <mdke> as I see it the advantages are that we can move to the new bzr format (we are currently using a bzr-svn format) and that the branch will be (much) quicker to download
[08:26] <mdke> obviously the disadvantage is that we lose the history but we can probably live with that. Are there any other disadvantages?
[08:27] <Peng> "new bzr format"?
[08:28] <Peng> mdke: You can use rich-root-pack, which is (a variation of) the new pack format.
[08:29] <Peng> mdke: I hate losing history, so I'd say don't do that. If performance is really that bad, grit your teeth until there are further improvements, or switch to git or hg or something. :P
[08:29] <mdke> Peng: right, I meant the pack format which comes with bzr 1.0
[08:30] <mdke> Peng: what are the reasons you hate losing history?
[08:30] <Peng> mdke: OTOH, if svn's history didn't import well, starting with a clean slate might be nice.
[08:30] <Peng> mdke: "Because.". It's...history. You're not supposed to lose it.
[08:32] <mdke> Peng: alright...
[08:32] <Peng> mdke: So, in summary, I'm no help at all. :P
[08:32] <mdke> we'd have the history in the branches for the previous releases, I guess
[08:33] <mdke> we wouldn't abandon those
[08:33] <Peng> mdke: I'd say that you shouldn't throw out the history unless you really, really need to.
[08:33] <Peng> Would you be maintaining the previous branches in svn or bzr?
[08:33] <mdke> in bzr, we imported all of them
[08:34] <mdke> the branch size is currently 200MB on disk
[08:37] <Peng> Ouch.
[08:38]  * igc dinner
[08:38] <Peng> That's about the size of the entire history of Python imported into bzr.
[08:38] <mdke> there ya go.
[08:38] <Peng> And that has *really* bad performance.
[08:39] <Peng> (35 or 38k revisions per branch, some large number of files.)
[08:39] <Peng> (Oh, 36k.)
[08:39] <mdke> we're only at 3700 revisions
[08:39] <TFKyle> mnm, I should try branching that
[08:39] <mdke> although I suppose it might not be comparable, given that our material is all text
[08:39] <mdke> and translations of text
[08:40] <Peng> 4000 files.
[08:40] <mdke> Peng: do you know whether if members download the branch without revision history, they can still push to our master branch on launchpad?
[08:41] <Peng> mdke: What do you mean? Bzr needs the history.  Well, you can use lightweight checkouts, but that would be slow.
[08:41] <mdke> yeah, I meant lightweight checkouts
[08:41] <Peng> TFKyle: They distribute it as a tarball. :(
[08:41] <mdke> so that would be corresponding slow to push?
[08:42] <Peng> mdke: Well, there's zero history stored on the client. Even "bzr status" would have to get some information from the server. And, obviously, that's slower than the local disk..
[08:42] <TFKyle> Peng: indeed, hadn't completely read the page yet (just read bcannons post mentioning it a little while ago)
[08:43] <mdke> Peng: yeah, not great. So I think the answer is either to drop the history, or figure out why it's so damn huge
[08:43] <mdke> and do something about it
[08:43] <Peng> mdke: Huge number of files?  The working tree is 200MB... I wasn't counting the history before
[08:48] <mdke> I've got that in a shared repo
[08:48] <mdke> which is around 1.6GB
[08:49] <mdke> my .bzr directory is 635MB
[08:49] <mdke> I'll come back tomorrow and have a chat with lifeless
[08:49] <mdke> thanks all
[08:54] <poolie> >  With regard to writing style, I agree with Steven Turnbull - the
[08:54] <poolie> yeh
[08:54] <poolie> bad paste
[08:55] <poolie> mdke: if you branch out of that repository into a new one it will carry only the relevant history
[08:57] <awilkins> Does the "new" format support rich roots?
[08:58] <awilkins> I'm in a similar situation, large SVN repo (~1.5GB), large number of medium - large files, about 13000 revisions... I've not finished converting mine over yet though
[08:58] <awilkins> Just finishing off the trunk, then I shall work on the branches
[08:58] <awilkins> THen I can see what kind of performance is available
[09:06] <Peng> awilkins: pack-0.92 has a rich-root variant called rich-root-pack and a subtree variant called pack-0.92-subtree. Even if you're currently using dirstate-with-subtree, you can probably upgrade to only rich-root-pack.
[09:11] <dato> Peng: to pack-0.92-subtree, you mean. and possibly to rich-root-pack, but it'll be very ver slow afaik.
[09:12] <Peng> Oops, I should've said "If you're currently using dirstate-with-subtree *with bzr-svn*".
[09:12] <Peng> dato: What would be slow? Why?
[09:12] <dato> -subtree -> -rich-root is slow, I think
[09:12] <Peng> Oh.
[09:15] <Peng> You may be correct. I'm branching ubuntu-doc's dirstate-with-subtree branch over bzr+ssh into a rich-root-pack right now, and it's going about as fast as a bzr-svn conversion (thankfully without the svn memory leaks though ;) ).
[09:15] <Peng> into a rich-root-pack repo*
[09:15] <awilkins> Peng: I meant the "dev" format ; I'm already using rich-root-pack
[09:15] <Peng> awilkins: Oh. Shrug. That's equivalent to packs right now, isn't it?
[09:15] <awilkins> I don't know what the benefits are...
[09:16] <awilkins> Aside : what's the custom-merge support like ATM?
[09:16] <awilkins> i.e. per-file merge handler?
[09:16] <Peng> Yeah, there isn't a rich-root variant of the development format, because having three different variants of it would be a pain for little benefit.
[09:18] <jml_> *sigh*
[09:18] <Peng> ?
[09:18] <jml_> mischan
[09:35] <Peng> Haha, it's pulling one revision every 2-3 seconds.
[09:36] <Peng> It just took 39 seconds for one.
[10:04] <gioele> hello
[13:29] <Arturik> http://www.meine-nackte-ex.net/?uid=143312
[13:31] <Arturik> http://www.meine-nackte-ex.net/?uid=143312
[13:35] <gioele> hello
[13:40] <gioele> do latest bzr versions maintain the concept of "revision ghosts"?
[13:43] <fullermd> I think they have to, since bzr has them.
[13:53] <gioele> bloody modem
[13:54] <gioele> so, revision ghosts are still present
[13:55] <gioele> http://bazaar-vcs.org/Revision (now old and outdated ;)) says that revision can be saved in .bzr/repository and .bzr/branch . Do you have an example of when revisions are saved in branches and not in repositories?
[13:56] <fullermd> I don't think that's what it says.
[13:56] <fullermd> (that is, not what it means by what it's saying)
[13:57] <fullermd> It's using 'repo' in reference to a shared repo, contrasted with a non-shared colocated repo.
[13:57] <gioele> what does it mean then?
[13:57] <gioele> ah
[13:57] <fullermd> Cue back to my grumpings over the years about the plethora of overloadings of 'branch'.
[13:58] <gioele> but...
[13:59] <gioele> should I read it as "when bazaar is given the option of deciding how to store a revision, it uses the shared repository"
[13:59] <fullermd> I didn't say the page was particularly _clear_   :)
[13:59] <gioele> but then, does that mean that you can have a standalone tree inside a shared repository?
[14:00] <fullermd> I'm not sure what that sentence is talking about anyway.  It's either getting way too deep into internals, or referring to something ancient, or just plain double-talking.
[14:00] <gioele> just to make sure: revisions are never stored under .bzr/branch
[14:00] <fullermd> Sure.  Just take a standalone tree, and mv it into the repo.  Or create a repo above it.
[14:00] <fullermd> Correct.
[14:01] <fullermd> There's no way using bzr to make a branch in a repo become standalone currently (reconfig should grow that and its complement), but the construct itself is perfectly possible.
[14:01] <gioele> ok, .bzr/branch does not store revisions. I'll go ahead and forget that that wiki page exist ;)
[14:16] <gioele> anyway. I make a little test. If you move a standalone tree inside a shared repo, a commit will store the new revision in the standalone tree, not in the shared repo.
[14:18] <abentley> gioele: I have updated http://bazaar-vcs.org/Revision.  Is it clearer now?
[14:21] <gioele> abentley: yes
[14:24] <gioele> now, if I get it correctly, http://bazaar-vcs.org/StandaloneBranch is wrong when it says «Standalone branches contain two components: The RCS data and a working tree.» To have or not to have a working tree is not inherent to a standalone branch
[14:25] <abentley> gioele: right.
[14:36] <abentley> gioele: I've tried to clean up http://bazaar-vcs.org/StandaloneBranch
[14:36] <gioele> how come a shared repo (bzr init-repo) contains .bzr/branch-{format,lock}?
[14:39] <fullermd> Well, it's gotta have something declaring it a bzrdir.  Specific naming is historical.
[14:39] <gioele> abentley: I'd change the last part of the last sentence with something like "by grouping them under a shared repository as repository branches"
[14:40] <gioele> ah, branch-format is really bzrdir-format, not related to the concept of branch
[14:42] <abentley> gioele: Good suggestion.
[14:46] <yacc> Aahh!
[14:46] <yacc> bzr: ERROR: Installed bzr version 1.3 is too old to be used with bzr-svn, at least 1.4 required
[14:47] <yacc> Guess that means that I need a "build-from-source" bzr?
[14:47] <abentley> yacc: where do you get your bzr-svn from?
[14:48] <yacc> bzr-svn: from a bzr co (stable branch)
[14:48] <yacc> bzr from Debian
[14:48] <abentley> Then you should also get your bazaar from there.
[14:48] <abentley> We also have our own deb repository, if you prefer.
[14:49] <yacc> We do?
[14:49] <yacc> :)
[14:49] <abentley> Hmm.
[14:49] <yacc> Ok, let me google for it :)
[14:49] <abentley> Or does that only support ubuntu?
[14:50] <jelmer> yacc: if you use bzr-svn from its development branch, use bzr.dev
[14:50] <gioele> abentley: ppa is ubuntu only
[14:50] <gioele> abentley: you left "turning them" in the last sentence of http://bazaar-vcs.org/StandaloneBranch ;)
[14:50] <yacc> jelmer: http://people.samba.org/bzr/jelmer/bzr-svn/stable/ is the devel branch of bzr-svn then?
[14:52] <abentley> yacc: If you're using debian sid or lenny, those also contain bzr-svn.
[14:53] <abentley> gioele: Actually, I like turning them better, because "grouping them" implies that just moving the branches will make them use the shared repo.
[14:53] <yacc> abentley: yeah, but, I'm not sure if that dusty taste is that great. ;)
[14:53] <gioele> abentley: «speed up operations by turning them grouping them under a shared repository as repository branches»
[14:53] <gioele> you have to choose one :P
[14:55] <abentley> gioele: Okay, fine.
[14:56] <jelmer> yacc: yes
[14:56] <yacc> abentley: guess I'll checkout bzr.dev then, deinstall bzr from Debian, and install from bzr.dev. Which makes me btw wonder if easy_install has a way to get releases from bzr branches as it has for svn? *wonder*
[14:57] <james_w> yacc: you can run bzr from source really easily
[14:57] <james_w> yacc: though is there a reason you are using bzr-svn later than 0.4.9?
[14:59] <yacc> james_w: good question, let say I had some fun last week push to some hosted svn repos. I'm not sure if jelmers good work solved the issue, or if I've got it configured differently which would mean that 0.4.9 might work for me.
[15:01] <james_w> yacc: well you can either switch to the 0.4.9 branch, or use bzr from source
[15:01] <james_w> which is "bzr branch lp:bzr", and then make the bzr script from that be in your path ahead of /usr/bin, or use an alias.
[15:09] <yacc> lp:bzr?
[15:09] <yacc> Not http://www.bazaar-vcs/bzr/bzr.dev/ ?
[15:09] <james_w> grabs the trunk from launchpad, you can use the full URL if you like.
[15:10] <james_w> yeah, that's fine as well.
[15:10] <gioele> spam: http://bazaar-vcs.org/jackcity
[15:11] <gioele> bye bye, thank you for the clarifications
[15:11] <yacc> james_w: no need to install the bzr branch stuff beside a symlink?
[15:12] <james_w> nope, bzr figures it all out.
[15:17] <yacc> nice, now I just need to pull bzr.dev via UMTS, which seems to take time, time, time,
[15:17] <yacc> At least it's a bandwidth limitation and not latency that I see here :)
[15:27] <mw-home> anybody in here using the nautilus plugin for bzr?  I installed it, now what?  I don't see those fancy icons.
[15:37] <yacc> Ah :)
[15:37] <yacc> james_w: where is the plugins directory of such a "devel" bzr?
[15:37] <mw-home> maybe I need to enable the nautilus plugin/
[15:39] <james_w> yacc: either ~/.bazaar/plugins
[15:40] <james_w> or in the plugins directory within the branch
[15:40] <james_w> bzrlib/plugins/
[15:40] <mw-home> thanks
[15:40] <yacc> so /usr/lib/python2.4/site-packages/bzrlib/plugins just has to move ;)
[15:40] <warren> Anyone know how to upgrade the repository format of my repo in launchpad?
[15:41] <warren> bzr get FOO; bzr upgrade --pack-0.92; bzr push (doesn't work)
[15:44] <asabil> warren: push --overwrite ?
[15:44] <james_w> warren: bzr upgrade <url>
[15:45] <asabil> oh didn't know that was possible
[15:45] <warren> [warren@newcaprica mkdst]$ bzr upgrade<EMAIL_ADDRESS>[15:45] <warren> bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format.
[15:45] <warren> (but it isn't)
[15:46] <james_w> what happens if you pass --pack-0.92
[15:46] <warren> same error message
[15:47] <warren> asabil, push --overwrite means everyone has to blow away their tree and pull again from scratch?
[15:47] <asabil> warren: yes am afraid
[15:48] <james_w> only if a push without --overwrite says that they have diverged
[15:48] <jelmer> warren: you'd want to upgrade over sftp
[15:49] <james_w> and they could use merge to get back on track, but the change that you overwrite would then still be present.
[15:50] <warren> jelmer, will upgrade over sftp be REALLY slow if you have a huge repository?
[15:50] <warren> jelmer, and afterward they will need to pull from scratch anyway?
[15:51] <jelmer> warren: it will be pretty slow, yes
[15:51] <jelmer> warren: but no need for anybody to pull from scratch afteewards
[15:51] <warren> too bad there's no button on launchpad to do conversion
[15:51] <warren> I'm converting a small repository first
[15:52] <warren> but soon I'm doing a huge one
[16:01] <mw-home> Anyone running the nautilus plugin?  I can't get it to work.  More specifically, I don't see the bzr icons inside nautilus.
[16:03] <mw-home> brb
[16:06] <warren> hmm
[16:06] <warren> should I worry about this?
[16:06] <warren> repository converted
[16:06] <warren> bzr: ERROR: No such file: '/~ltsp-upstream/ltspfs/ltspfs-trunk/.bzr/branch/last-revision': [Errno 2] /~ltsp-upstream/ltspfs/ltspfs-trunk/.bzr/branch/last-revision
[16:06] <james_w> warren: doing what?
[16:06] <warren> james_w, that was at the end of bzr upgrade --pack-0.92<EMAIL_ADDRESS>[16:07] <james_w> hmm, that sounds pretty bad.
[16:07] <james_w> is the branch still usable?
[16:08] <warren> no idea
[16:08] <james_w> "bzr log -r 1<EMAIL_ADDRESS>should tell you
[16:08] <james_w> ah, without mailto:, sorry
[16:09] <yacc> jelmer: Any idea what this can mean: bzr: ERROR: Revision {('svn-v3-list-QlpoOTFBWSZTWTtPdCgAACpRgAAQAAK3r94gIABIbVT1Mj0QeptEEpAAANMcdP3o3SqXf2KNSpL4ShxMTeA8adCslybHoqgxGgqoZA-LuSKcKEgdp7oUAA..:3e2713fb-81e7-48d5-8ee4-88d6b0cf85af:trunk%2Flogs:44',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x8c3db6c>".
[16:09] <warren> james_w, seems to be OK
[16:09] <warren> james_w, so far I've only upgraded two of our smaller repos, I'm afraid what will happen with our larger repos...
[16:10] <james_w> warren: could you pastebin the relevant part of ~/.bzr.log please?
[16:12] <warren> james_w, uh... where would that log go?
[16:12] <warren> oh, i see.
[16:13] <warren> james_w, oh damn, it was a traceback
[16:14] <james_w> I'm interested in all of the output for that command, so before the traceback as well please.
[16:17] <warren> james_w, http://people.redhat.com/wtogami/temp/bzrcrash.txt
[16:19] <james_w> warren: can you file a bug with that information please? It looks pretty serious to me.
[16:19] <james_w> though it may be harmless, but it's not a good thing to happen.
[16:20] <warren> james_w, this is bzr-1.1 because somebody here yesterday said it should be fine.  should I use 1.3?
[16:21] <warren> james_w, I don't know where/how to file bugs
[16:22] <james_w> warren: https://bugs.launchpad.net/bzr/+filebug
[16:22] <james_w> 1.3 may have it fixed I guess, would you be able to try that?
[16:22] <warren> I can upgrade
[16:23] <warren> james_w, should I revert my launchpad repo?  how?
[16:25] <warren> james_w, is there a way I can check the integrity of my repository?
[16:27] <warren> [warren@newcaprica ltspfs-trunk]$ bzr info
[16:27] <warren> Standalone tree (format: unnamed)
[16:27] <warren> what does unnamed mean?
[16:28] <james_w> bzr check is for checking
[16:29] <warren> james_w, if I can revert my repo, I can test 1.3 to see if the same problem happens.  How do I revert it on the launchpad server?
[16:30] <james_w> you would need to ask a launchpad admin I think.
[16:38] <warren> james_w, if bzr check doesn't complain I shouldn't worry?
[16:38] <james_w> warren: correct
[16:39] <warren> ok
[16:39] <james_w> but please still report it, as even if it doesn't cause a problem it is still worrying for users
[16:41] <ubotu> New bug: #207201 in bzr-svn "bzr branch against https svn url breaks" [Undecided,New] https://launchpad.net/bugs/207201
[16:43] <jelmer> yacc: hmm, sounds like you hit the same problem that spiv was seeing
[16:44] <yacc> jelmer: what can I help to debug it?
[16:45] <yacc> guess the fact that I get no branch means that I cannot run bzr check on it ;(
[16:47] <jelmer> yacc: not sure, I should probably try to reproduce it first
[16:47] <yacc> jelmer: I can retry it it with -Dcommit?
[16:47] <jelmer> yacc: this is a regression in the 0.4 branch btw
[16:48] <jelmer> yacc: can you perhaps confirm this problem doesn't occur with 0.4.9?
[16:49] <yacc> jelmer: how can I get the needed versions via bzr?
[16:49] <jelmer> yacc: the 0.4 branch should have a bzr-svn-0.4.9 tag
[16:49] <yacc> I have branches of bzr-svn stable and bzr.dev on my laptop, so I was thinking along the idea of not apt-get installing the revisions you want me to try ;)
[16:50] <jelmer> yacc: you can update to bzr-svn 0.4.9 by running something like "bzr pull --overwrite -rtag:bzr-svn-0.4.9" I think
[16:53] <yacc> jelmer and how do I switch it back to have the newest revision?
[16:54] <yacc> btw, you have forgotten to tag 4.9, 0.4.7 is the newest one.
[16:55] <james_w> jelmer: nice job on the performance improvements.
[16:56] <jelmer> james_w: thanks
[17:03] <ubotu> New bug: #207211 in bzr "upgrade --pack-0.92 sftp:// failed (but worked...)" [Undecided,New] https://launchpad.net/bugs/207211
[17:04] <barry> hello folks!  i have some shelved changes that no longer apply cleanly to the working tree.  i don't want to lose my shelved changes.  what's the cleanest way to view or merge them?
[17:04] <barry> what will bzr unshelve --force do?
[17:04] <james_w> thanks warren
[17:06] <james_w> barry: I believe it will run patch such that it leaves the .failed files around or whatever they are called.
[17:06] <ubotu> New bug: #207216 in bzr ""bzr tags" should take URL argument" [Undecided,New] https://launchpad.net/bugs/207216
[17:07] <james_w> i.e. it will apply the hunks it can, and those it can't will be left for you to merge by hand.
[17:07] <barry> james_w: ok, i can handle that :)  thanks!
[17:07]  * barry gives it a try...
[17:09] <barry> okay, unshelve --force doesn't change the shelve.  is there a way to manually discard the shelve, since i don't need it any more?
[17:13] <james_w> it will be a subcommand of "shelf"
[17:13] <james_w> I suspect "shelf delete"
[17:13] <james_w> "shelf delete PATCH"
[17:13] <james_w> "shelf ls" will give you the name.
[17:15] <barry> james_w: thanks!
[17:17] <jelmer> yacc: strange, I don't see the tag here either
[17:17] <fullermd> Mmph.  Do we really want to say "straight-jacket" in the Guide?
[17:17] <jelmer> yacc: I assumed that "bzr merge" brought them in
[17:18] <jelmer> I don't have my tree here at the moment
[17:18] <jelmer> but I'll see if I can fix that later tonight
[17:18] <jelmer> yacc: for now, please use the 0.4.9 tarball
[17:19] <yacc> jelmer: will take some time, have to go hunt the family dinner.
[17:20] <james_w> fullermd: in reference to another system?
[17:20] <fullermd> Well, the usage I saw was in reference to centralized development patterns...
[17:21] <james_w> I would prefer not to, but I don't think it's necessarily that bad.
[17:21] <fullermd> Oh, I don't mean conceptually or tone-wise.
[17:21] <fullermd> I mean that it's a really common misspelling, and it seems actually sufficiently common that some places accept it, but it always looks crappy to me.
[17:22] <james_w> ah, I never knew how it was spelt.
[18:44] <rexbron> hello, would anyone be able to tell me the best way to merge two branches (or working trees) via bzrlib?
[18:45]  * rexbron also thinks this would be a good section on the Integrating with bzr page on the wiki
[18:45] <james_w> it would, yes
[18:46] <james_w> my first guess is WorkingTree.merge(other_branch), but I'll have to look
[18:46] <james_w> close
[18:47] <james_w> from bzrlib import workingtree
[18:47] <james_w> from bzrlib import branch
[18:47] <james_w> other_branch = branch.Branch.open('wherever')
[18:47] <james_w> tree = workingtree.WorkingTree.open('wherever')
[18:48] <james_w> other_branch.lock_read()
[18:48] <james_w> try:
[18:48] <james_w>   tree.lock_write()
[18:48] <james_w>   try:
[18:49] <james_w>     conflicts = tree.merge_from_branch(other_branch)
[18:49] <james_w>   finally:
[18:49] <james_w>      tree.unlock()
[18:49] <james_w> finally:
[18:49] <james_w>   branch.unlock()
[18:49] <james_w> you can then do something with conflicts, let me look what it is
[18:49] <rexbron> james_w: does tree get locked automatically?
[18:49] <rexbron> sorry
[18:50] <rexbron> I forgot the lock_read() was for tree
[18:50] <james_w> conflicts is a number, so you can just check for > 0
[18:50] <james_w> if you need to know what they are, ask the tree
[18:51] <james_w> merge_from_branch can take a revision to merge, otherwise it just defaults to the tip of other branch.
[18:55] <rexbron> ok thanks
[18:58] <rexbron> james_w: the workingtree method rever is undocumented, but i think I can appy similar logic. Could you tell me what the old_tree varriable is for?
[18:58] <rexbron> s/rever/revert/
[19:00] <james_w> it's the tree to revert to I believe.
[19:00] <james_w> leaving it as None will mean that it uses the basis tree.
[19:00] <james_w> i.e. like "bzr revert"
[19:01] <rexbron> james_w: kk
[19:02] <rexbron> james_w: can revert(filenames) accept a list?
[19:03] <rexbron> hey andrea-bs
[19:03] <andrea-bs> hi rexbron
[19:03] <james_w> rexbron: it should be a list
[19:03] <rexbron> ok
[19:03] <james_w> so a single filename should be a list of a single value
[19:04] <james_w> I can't remember whether it's [] or None for all files.
[19:04] <abentley> It's None
[19:04] <james_w> ah, None
[19:04] <james_w> thanks abentley
[19:05] <rexbron> james_w: would it be interchangeable with a set?
[19:05] <james_w> should be I guess.
[19:05] <rexbron> I guess it might be worth creating a test case
[19:06] <james_w> yep :-)
[19:06] <james_w> I don't see why there would be any ordering *required*
[19:06] <james_w> whether the current implementation assumes it or not I'm not so sure about.
[19:07] <rexbron> james_w: I am working on an existing codebase that uses sets, I am not sure atm if I would be able to use lists instead
[19:08] <rexbron> I could always just filenames=list(set)
[19:08] <abentley> rexbron: "best" way to merge depends on context.  WorkingTree.merge is probably the simplest.  merge.Merger.from_revision_ids is the most powerful.
[19:08] <rexbron> abentley: In my case, I just need to merge the latest revision
[20:04] <lifeless> rexbron: A set should be fine
[20:04] <rexbron> lifeless: cool
[20:19] <awmcclain> Hi all... anyone have a rough sense when the smart server will accept -u -p ?
[20:23] <james_w> awmcclain: sorry, can you explain what you mean by that?
[20:26] <awmcclain> james_w: So, right now I'm using bzr with capistrano to manage our entire server farm. RIght now I'm sharing our repo via http:// (since I don't want to automatically create and setup new SSH key for each new machine). The http:// is restricted by domain, but we're running into DNS propogation issues for new boxes. Long story short, I'm waiting for a time when I can just pass in a user/password via command line to the bzr server.
[20:26] <james_w> ah, so you want an authenticated smart server over bzr://
[20:26] <james_w> ?
[20:26] <malept> hi, does anyone know when the PPA is going to be updated for bzr/bzrtools 1.3?
[20:27] <awmcclain> Exactly!
[20:27] <james_w> malept: I don't know, sorry, what release are you running?
[20:27] <james_w> awmcclain: I know some people are nervous about adding authentication to the smart server
[20:27] <awmcclain> Really, I'm just wondering if that's in the roadmap.
[20:28] <awmcclain> Becuase they feel that bzr+ssh:// handles it fine?
[20:28] <james_w> I'm not sure what the reasons are
[20:28] <awmcclain> +)
[20:28] <james_w> I think one may be that getting it right would be hard.
[20:29] <james_w> as in adding an authentication system opens a whole can of worms
[20:29] <awmcclain> Ah.
[20:30] <awmcclain> Ok, I can look into different roads around this then.
[20:30] <james_w> however, it keeps coming up, so I definitely wouldn't rule it out.
[20:30] <awmcclain> Right.
[20:30] <james_w> if you wanted to take it a step forward then contributing some use cases and design ideas would be good.
[20:31] <awmcclain> Oh, great. I see if I can work on that this weekend.
[20:31] <awmcclain> Seems like the type that could leverage existing design patterns, at least.
[20:31] <awmcclain> *type of thing
[20:32] <awmcclain> Maybe borrow from oAuth. I dunno. I'm talking from a point of naîveté
[20:32] <awmcclain> ok, great.
[20:33] <james_w> yeah, I'm sure there's stuff we can re-use
[20:39] <lifeless> awmcclain: you could use https + password auth
[20:42] <lifeless> awmcclain: authentication is tricky to get right; don't want to design our own (duh), but even implementing (say) rfc2617 digest is a pita
[20:43] <lifeless> awmcclain: so *if* we can avoid rolling our own, and still satisfy our users: thats a win.
[20:43] <lifeless> vila: do we support http/digest ?
[20:43] <awmcclain> lifeless: Very true... but could bzr pass in the u/p on the command line?
[20:44] <warren> how do you bzr push if your only change is a new tag?
[20:44] <awmcclain> lifeless: It has to be non-interactive
[20:44] <vila> lifeless: yes
[20:44] <lifeless> awmcclain: https://user:pass@host/
[20:44] <bob2> awmcclain: in the url
[20:44] <lifeless> vila: ^ that still works right ?
[20:44] <awmcclain> lifeless: You just made my day! Perfect!
[20:44] <lifeless> awmcclain: or you can write to the cached credentials file yourself before running bzr
[20:45] <lifeless> awmcclain: or you can provide a UI plugin for bzr that will supply passwords from an arbitrary source
[20:45] <vila> lifeless: yes
[20:45] <awmcclain> lifeless: Or just put it in the url. ;)
[20:45] <lifeless> warren: you may have found a bug
[20:45] <james_w> warren: I think there is currently a bug open saying that you are not able to do that from the UI
[20:45]  * warren vaguely recalls reporting this a long time ago
[20:46] <warren> oh, no, I reported a different bzr tag bug, since fixed.
[20:46] <awmcclain> Thank you so much for your help, everyone. I say this every time, but, the community and IRC is why I evangelize bzr
[20:47] <lifeless> :P
[20:47] <james_w> thanks awmcclain
[20:48]  * warren commits a worthless change in order to tag it
[20:49] <james_w> lifeless: hi
[20:49] <james_w> sorry I disappeared during out fast-import chat.
[20:50] <james_w> I'm around now if you want to have another go
[20:51] <warren> lifeless, wow!
[20:51] <warren> lifeless, bzr push did push the tag upstream but it didn't say anything happened
[20:54] <warren> lifeless, so it actually is pushing and pulling tags properly, it just is not informative so the user thinks is isn't happening.
[20:58] <jelmer> yacc: the tags for 0.4.8 and 0.4.98 should be present now
[20:58] <jelmer> it looks like bzr doesn't add the tags to the master branch when merging but only to the local branch
[21:14] <lifeless> james_w: hi yes
[21:14] <james_w> hi lifeless
[21:18] <james_w> so, you asked about deterministic file-ids or something? sorry, I lost the scrollback.
[21:21] <lifeless> james_w: well
[21:22] <lifeless> james_w: I am concerned about how file ids are being handled by fast-{im,ex}port
[21:23] <lifeless> james_w: your comment on the list suggests some fundamental design issues, and they can lead to extremely poor conversions, or at worst an inconsistent distributed datbase
[21:24] <james_w> the cache is buggy, and I'm going to rip it out and use the parent inventories as you suggested. I wonder if your concerns run deeper than that though>
[21:26] <lifeless> well, the presence of the cache suggests some misunderstanding of what commit has to do (and thus what a converter has to do)
[21:26] <lifeless> so I'd rather dig a little deeper :)
[21:26] <james_w> perhaps
[21:27] <james_w> I'm happy to do that, as I'm sure we'll get a better system out of it.
[21:28] <lifeless> how do you allocate file ids in import revisions ?
[21:29] <james_w> currently the cache looks up based on the path and returns a file-id if any previously imported revision has that path, otherwise it generates a new random id.
[21:30] <james_w> that is buggy for separate branches as I explained, so the alternative is to have a per-branch cache, or to just use the parent inventories
[21:31] <james_w> the former means that a file can be deleted and resurrected, which I'm not sure is a desirable property
[21:32] <mc__> is it possible to push over http?
[21:33] <james_w> mc__: not unless you have the smart server set up for http, or the webdav plugin.
[21:34] <mc__> hm alright, we have bzr installed on our vserver. we 2 core devs push over sftp. someone else made some changes. he does not have ssh access to our server. how can he send us his changes?
[21:34] <james_w> bzr send --mail-to your-email
[21:35] <james_w> then you can save the attachment and run "bzr merge attachment"
[21:35] <james_w> check the results, commit and then push
[21:35] <mc__> does that require smtp/sendmail on the server where bzr is installed?
[21:36] <james_w> no, he's emailing you
[21:36] <lifeless> james_w: per branch cache would be buggy, because fastexport streams can represent renames :>
[21:36] <mc__> so he needs to have smtp installed on his machine?
[21:36] <james_w> so you can receive it on your workstation, save it there, commit there, and then push to your central server
[21:37] <james_w> mc__: he needs an email client.
[21:37] <james_w> it will use the default linux or windows client, or can be set to certain other clients
[21:37] <james_w> (mac as well I think)
[21:38] <james_w> lifeless: it may be possible to avoid problems there, but I don't know the ordering constraints on the stream well enough to say whether it will always be avoidable.
[21:39] <james_w> lifeless: but the parent inventories should be the easier solution anyway
[21:39] <lifeless> yup
[21:39] <mc__> alright,thank you
[21:40] <james_w> however we still have the issue that we are importing in to a file-id based system from a stream that isn't based on file-ids, and which comes with recommendations to not generate rename entries.
[21:40] <james_w> so I think we need some rename detection somewhere along the line.
[21:40] <james_w> mc__: no problem. Please feel free to ask if you have any more queries.
[21:42] <lifeless> james_w: why ?
[21:43] <lifeless> james_w: or to put it another way, we don't do rename detection for cvs. why should we do it for git ?
[21:43] <james_w> I think we should do it for all systems.
[21:43] <james_w> git is currently the least likely to be imported this way I think.
[21:44] <james_w> it's just that the documentation says something like "add and delete is just as efficient for the importer as rename entries, so use the former"
[21:44] <lifeless> so file a bug
[21:44] <james_w> so, it's possible the exporter will discard information.
[21:44] <james_w> that's true, I'll bring it up with Shawn.
[21:45] <lifeless> saying that its not true for all importers; exporters should not discard information they don't have to
[21:45] <james_w> yep
[21:46] <lifeless> as for applying heuristics during import conversion; this precludes any opportunity for incremental or repeatable imports
[21:46] <lifeless> unless some very hairy tricks are pulled (ask jelmer about svn mappings and revision ids)
[21:48] <james_w> I'm not sure that's entirely true is it?
[21:48] <james_w> it would require that the import heuristics be stable across releases though
[21:49] <lifeless> it requires they be stable forever for the same source tree
[21:49] <lifeless> forever is a long time
[21:49] <james_w> yes, which is a big commitment
[21:49] <james_w> I agree with your argument.
[21:49] <lifeless> I have a negative aleph-nought I prepared earlier for voting on this commitment :)
[21:50] <james_w> :-)
[21:50] <james_w> so, that leaves bzrlib, but I'm a long way away from trying to put it in there.
[21:50] <lifeless> now, at some point it may be worth doing; in which case we break existing imports and do mapping versioning
[21:51] <lifeless> or we add heuristics to the deterministic stuff we already have (and there is no reason we can't do this). file ids are a tool not a straight jacket
[21:51] <spiv> lifeless: thanks for the review of the protocol version query change.  Do you think that I should deprecate Transport.get_smart_client now?
[21:52] <lifeless> spiv: With Extreme Prejuidice
[21:52] <spiv> lifeless: excellent :)
[21:52] <spiv> lifeless: thanks
[21:54] <abentley> lifeless: Does that mean yelling racist insults at it while deprecating it?
[21:56] <mw-home> does anyone know how I could use vimdiff with bzr diff?
[21:56] <abentley> mw-home: bzr diff --using vimdiff
[21:57] <abentley> There is also a vimdiff plugin.
[21:58] <james_w> lifeless: Repository.get_revision_graph
[21:59] <mw-home> abentley: that failed.
[21:59] <mw-home> $ bzr diff --using vimdiff templates/administer/myaccount.kid
[21:59] <mw-home> bzr: ERROR: no such option: --using
[21:59] <mw-home> do i need the vimdiff plugin first?
[21:59] <lifeless> james_w: just nuked it, what about it ?
[21:59] <abentley> mw-home: What version of bzr do you have?
[21:59] <james_w> you said there is no replacement, but is the replacement .get_graph() and use graph methods?
[21:59] <mw-home> 1.0.0
[21:59] <abentley> It was added in 1.1
[22:00] <lifeless> james_w: there isn't a direct replacement
[22:00] <mw-home> oh, whoops
[22:00] <abentley> But you can use the plugin instead.
[22:00] <mw-home> ok, now i will learn how to use plugins.
[22:00] <lifeless> james_w: get_graph().get_parents_map returns ghost parents
[22:00] <james_w> lifeless: but it should be graph based now right?
[22:01] <james_w> I'm just interested in what the recommended way to get history information is.
[22:01] <lifeless> james_w: same as its been since 0.9x
[22:01] <lifeless> james_w: repository.get_graph()
[22:01] <mw-home> how do i install a plugin?
[22:02] <james_w> great. I've not dealt with this sort of thing until recently, I've only used the highest level stuff.
[22:02] <james_w> lifeless: thanks for the clarification.
[22:02] <mw-home> ignore me.
[22:03] <malept> james_w: wrt to your PPA distro inquiry, I'm running Feisty. (sorry about the delayed answer...was AFK)
[22:03] <mw-home> should i checkout or branch a plugin?
[22:03] <james_w> malept: that's cool, was just wondering if you were on hardy, as that will hopefully get a direct update soon.
[22:04] <malept> james_w: yeah...the box in question is a production machine, so it probably won't be upgraded to hardy until may-ish.
[22:04] <abentley> mw-home: probably branch.
[22:04] <james_w> fair enough.
[22:05] <james_w> malept: hopefully someone will push the updates to the PPA soon.
[22:05] <lifeless> poolie: ^ is 1.3 in the ppa?
[22:08] <mw-home> thanks for the help.  I got the plugin working.  plugins are neat.
[22:20] <mw-home> I'm not sure I understand how to share a repository over the intarweb.  Do I just set up a repository in the docroot of my webserver?
[22:20] <lifeless> mw-home: that will do just fine
[22:21] <mw-home> lifeless: but how do i accept inputs?
[22:21] <lifeless> spiv: I'm curious, what will
[22:21] <lifeless> source = target = source do ?
[22:21] <mw-home> is that when I also need to allow sftp access?
[22:21] <lifeless> mw-home: you have folk publish them themselves, or send them to you with 'bzr send'
[22:22] <mw-home> lifeless: wow.  now i get the difference between svn and bzr.  everybody can run their own web-accessible read-only server, and we all pull from each other.
[22:22] <lifeless> spiv: I *think* it binds the current value of target to source and that is all
[22:22] <spiv> lifeless: in python?  It does right-to-left, IIRC, so I think you're right.
[22:24] <spiv> lifeless: I'm pretty sure it takes the right-most thing, and assigns it to each of the "foo =" parts.  I forget if it does that left-to-right or right-to-left, but I guess it doesn't matter in your case :)
[22:25] <spiv> lifeless: ah, yes, it does evaluate the right-hand expression, then assigns it to each target left-to-right.
[22:26] <lifeless> so if target = source returned the old value of target
[22:26] <lifeless> then that would be a nice one liner :>
[22:26] <spiv> lifeless: so anyway, yes, in your case it's like you just did "target = source"
[22:28] <spiv> lifeless: the canonical way to swap two variables is "a, b = b, a".  I'm not sure if that's the fastest. (Ideally the compiler would optimise that idiom, though...)
[22:28] <lifeless> clever
[22:48] <oleavr_> is there a way to disable bzr-svn integration on a specific branch?
[22:49] <jelmer> oleavr: "bzr --no-plugins"
[22:51] <igc> morning all
[23:03] <poolie> spiv: call now?
[23:04] <spiv> poolie: dialling now
[23:11] <Peng> Haha, it took 5.5 hours to branch lp:~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy.
[23:12] <oleavr> jelmer: so there's no way to set some metadata on a branch for that?
[23:13] <bob2> what does bzr-svn do when dealing with bzr branches?  I'd've thought it only kicked in when a svn branch was involved.
[23:13] <jelmer> bob2: it does
[23:13] <jelmer> oleavr: why would you want that, anyway?
[23:18] <oleavr> jelmer: in order to have the SVN data (.svn) stored so that I can manage it manually without bzr-svn interfering (I want to handle merging from upstream by hand, typically 'quilt pop -a', 'svn up', 'quilt push')
[23:18] <lifeless> oleavr: you might consider looms :P
[23:19] <jelmer> oleavr: yeah, sounds like you could use bzr-svn and looms fine there..
[23:19] <jelmer> oleavr: if you're running svn up in that directory anyway, why do you care if bzr uses bzr-svn ?
[23:28] <jml> lifeless: how do I get a loomified branch such that I get the loom info?
[23:30] <oleavr> lifeless: it's a very promising project (TBH I hate quilt, not very usable when at times when you're forced to use a crappy OS), it's just that my first experience involved a major screw-up that was all my own fault, and because it all felt very 'magic' I wasn't sure how I could revert :) (I made a commit in the wrong thread and discovered it a little later) I should've spent some time to read the source figuring out how to do it, but I was runni
[23:31] <oleavr> jelmer: well, I've had some bad experiences with the svn integration in the past, so it was just for playing things 'safe'
[23:33] <jelmer> oleavr: what sort of things?
[23:42] <oleavr> jelmer: when I think about it it wasn't actually with bzr-svn screwing up, just the initial get/branch phase taking ages, patience running out, ditching the integration, doing an svn checkout ready to just handle it myself, and then getting annoyed by bzr-svn thinking it's dealing with a bzr-svn branch..
[23:53] <spiv> jml: "bzr branch" ought to do it.
[23:53] <spiv> jml: the loomified branch may need "bzr record" done in it first, perhaps.
[23:53] <jml> spiv: with which bzr version?
[23:54] <spiv> jml: whatever version, I think.
[23:55] <spiv> jml: it's possible you're seeing something like https://bugs.edge.launchpad.net/bzr-loom/+bug/201613
[23:55] <ubotu> Launchpad bug 201613 in bzr-loom "pushing looms does not work properly" [Critical,Triaged]
[23:55] <spiv> jml: or https://bugs.edge.launchpad.net/bzr-loom/+bug/193893
[23:55] <ubotu> Launchpad bug 193893 in bzr-loom "branching over bzr+ssh does not propogate loom threads" [High,Triaged]
[23:55] <jml> http :)
[23:55] <jml> but yeah
[23:56] <lifeless> jml: so, this will work:
[23:57] <lifeless> loomify + record + branch
[23:58] <jml> ok.
[23:58] <jml> lifeless: so how do I get the looms for http://people.ubuntu.com/~robertc/baz2.0/shallow-branch?
[23:59] <lifeless> well, the problem there is I'm using push
[23:59] <lifeless> :[
[23:59] <lifeless> so step 1: fix the push bug; step 2: get me to push using it
[23:59] <lifeless> its likely as simple as overriding push and calling self.pull in some manner


 I found this tree while on a walk by my house
 Wth
 That's creepy
 I sort of like it
 It is at the canal by my house
 On a related note. The Note 9 does an amazing job of low light photos
 @KMyers think I can pay for 2 sets of this? https://www.thingiverse.com/thing:1693029
 each set would have 4 so 8 total.
 @KMyers, You should really try the Nexus.  It's not a Samsung! And that's what really matters in the world.
 I can do that
 @KMyers We'll talk about pricing.
 Good.  I'm glad you have finally come to your senses about Samsung @KMyers .  It's really great to bring the gospel of Android to another person.  You have been saved.  Haliluja
[20:06] <maxolasersquad> If you made a purchase from Newegg between August 14 and September 18 then your CC data may have been leaked.
[20:06] <maxolasersquad> https://techcrunch.com/2018/09/19/newegg-credit-card-data-breach/
 So I found that I can transfer the rick roll call to someone else at work today.
 @KMyers @AdamOutler
 @ahoneybun, Ha
 @maxolasersquad, Another one bites the dust