[01:16] <lifeless> abentley: hi. I would like to still see the branch nickname from the bundle, in BB. is that possible/easy?
[01:17] <abentley> lifeless: I think so.
[01:17] <abentley> This would have to be the head revision branch nick.
[01:20] <lifeless> hmm maybe it wasn't the nick. There was a field in the bundle header I used to read when you showed the bundle
[01:36] <igc> morning
[01:41] <tetron> quick Q, is there an easy way in bzr to have it embed the current repository revision to a file?
[01:41] <tetron> i.e. so an "about" dialog has the current build rev
[01:41] <fullermd> Not automatically, via keyword expansion.
[01:42] <fullermd> You can do it manually via sed'ery.  Depending on language, you can use the version-info command to generate a source file containing it.
[01:48] <tetron> fullermd: great, thanks
[01:50] <poolfool> Um ... does bzr support any type of keyword expansion (ala CVS)?
[01:50] <fullermd> Nyet.
[01:51] <poolfool> Ok ... is that on the roadmap to 1.0 land?
[01:51] <fullermd> Don't think so...   that path is pretty full of performance and suchlike.  It's post-1.0.
[01:51] <poolfool> Thanks.
[01:52] <poolfool> Or what is thanks in Russian?
[01:52] <fullermd> Urg.  Now you're straining my knowledge of the language   :p
[01:52] <fullermd> Spasibo?
[03:01] <abentley> lifeless: perhaps you're thinking of the branch's public location?  that is already shown.
[03:31] <lifeless> abentley: could be
[03:31] <lifeless> abentley: hey, got time to chat about merge base?
[03:33] <abentley> I'm not feeling well.
[03:41] <lifeless> abentley: oh, thats a shame. Get well soon.
[03:41] <lifeless> abentley: I feel that we have a regression on merge base selection, and I'd be happy to fix it if we can chat about it at some point.
[04:03] <poolie> spiv, hi
[04:03] <spiv> poolie: Hello
[04:06] <spiv> lifeless: have you looked at my reconcile patch from Friday?
[04:08] <lifeless> spiv: no I haven't, thanks for reminding me
[04:08] <lifeless> I will be pairing with poolie much of today
[04:10] <lifeless> hi poolfool, welcome back :)
[04:10] <poolie> spiv, i was thinking about the default port number thing
[04:10] <lifeless> vila: hola
[04:10] <poolfool> Thanks ... How is life?
[04:11] <lifeless> vila: what is transportstats?
[04:11] <lifeless> poolfool: good :)
[04:12] <poolfool> poolie: Hey, I sent you an email earlier today (chaffinMichael@gmail) about the redhat SPEC file ... hope it helps.
[04:13] <spiv> poolie: did you come to any conclusions?
[04:45] <bigdog> I have a question for you guys,  I have some use cases, and am not sure if bzr would work.
[04:46] <bigdog> I have binary files 100meg-1gb
[04:46] <lifeless> food time
[04:47] <lifeless> but yes, bzr will work, ifyou have enough ram
[04:47] <bigdog> lifeless: happy eating
[04:47] <beuno> bigdog, I use bzr to keep track of big files, one thing to keep in mind, bzr needs to put everything in memory
[04:47] <lifeless> we're starting to address teh amount of ram needed.
[04:47] <beuno> so 1gb file means at least 2gb available  :D
[04:47] <bigdog> ok, I did not realize the files needed to be in memory, just the history info.
[04:47] <beuno> lifeless, my gfx guys will be happy to hear they can start wasting space again on 1gb files  :p
[04:48] <bigdog> beuno: these are 3d modeling files
[04:48] <beuno> bigdog, right, I get my guys to zip 'em up
[04:48] <beuno> split them if needed
[04:48] <beuno> not convenient, but works
[05:01] <bigdog> guys: thanks for the info
[05:03] <beuno> bigdog, :D
[05:28] <lifeless> bigdog: np
[05:45] <lifeless> spiv: thanks for the trivia
[05:46] <lifeless> spiv: My pointy haired side wonders if it was really worth looking at the python source to find out though ;)
[05:50] <fullermd> Wha?  Of course it is.  It's like spending $200 to win a $10 bet; you gotta keep your priorities straight.
[06:00] <bialix> fullermd: I'm impressed
[06:00] <fullermd> Hmm?
[06:01] <bialix> Spasibo is indeed thanks in russian
[06:02] <fullermd> Oh, good.  My memory still occasionally works   :)
[06:04] <poolie> mark used "spasibo" the other day and i was wondering what it meant
[06:04] <fullermd> Oh, don't be _too_ impressed.  I have a Russian vocabulary of maybe a half dozen words, and I'm useless with the alphabet   :p
[06:04] <bialix> mark sabdfl?
[06:04] <bialix> he was in Moscow
[06:05] <poolie> yes
[06:05] <poolie> and Zvyozdny Gorodok
[06:06] <fullermd> I know only moderately more German, have forgotten much of the French I knew (which was only ever good enough to pidgin-talk my way about at its peak), can count to 6 in Korean and 10 in Spanish...
[06:06] <bialix> yes, star town
[06:06] <fullermd> Luckily, I'm American, so nobody expects me to handle anything but English anyway   ;>
[06:07] <bialix> that's why I'm impressed (a bit)
[06:07] <lifeless> fullermd: Americans don't speak English though ;)
[06:08] <fullermd> lifeless: I speak the King's English.  It was good enough for Elvis, it's good enough for me!
[06:12] <lifeless> fullermd: do you have Blue Suede Shoes ?
[06:13] <fullermd> They're out in my pink Cadillac.
[06:13] <lifeless> then I guess you're good enough for the language
[06:14] <lifeless> :)
[06:16] <fullermd> I'm glad you think so.  Otherwise, I'd'a had to don a gold lame suit and start hopping around the channel.
[06:16] <fullermd> And NOBODY wants that...
[06:16] <lifeless> hmmm
[06:21] <ubotu> New bug: #150820 in bzr "hashcache is invalidated when a file's containing directory is	renamed" [Wishlist,Confirmed]  https://launchpad.net/bugs/150820
[06:23] <lifeless> ciaoish, going off net for battery
[06:42] <i386> lifeless: we should do beer sometime
[07:18] <lifeless> i386: definately
[07:19] <vila> lifeless: a transport decorator as a plugin that will be published RSN
[07:20] <vila> I wanted to play a bit with some ideas in a sandbox
[07:20] <lifeless> vila: cool; have you seen the trace+ decorator ?
[07:21] <vila> yup, give me a good laugh :) Looks like we were partly on the same track
[07:21] <lifeless> heh
[07:21] <vila> the intents are a bit different though, transportstats collect every transport method call, the analysis being done later
[07:22] <lifeless> hmm
[07:22] <vila> well nearly every
[07:22] <lifeless> like get_transport() ?
[07:22] <vila> no
[07:22] <vila> like has, get, get_bytes, put_bytes, etc
[07:23] <lifeless> so every Transport method call :)
[07:23] <vila> with some exceptions like put_non_atomic_file that are written in terms of other methods
[07:23] <lifeless> I'd like to flesh trace+ out
[07:23] <lifeless> hmm, I don't think they should be exceptions, because a given transport may choose to implement it natively
[07:24] <vila> the big part was to serialize without being to much a resource hog
[07:24] <vila> honestly, there are some problems, so far I aimed at something simple so that I can display bytes read bytes written latency etc
[07:25] <lifeless> sure
[07:25] <lifeless> sounds nice
[07:26] <vila> and even for that a simple decorator may not be enough, readv and open_write_stream may need specific implementations to measure latency more correctly or real bytes read too
[07:27] <vila> but I think the serialization part is mostly good so far, I have to profile a bit to see if a C implementation is needed, but the API is quite cool to use :)
[07:29] <vila> let say I want to add a new method 'get_half_file(relpath, start, middle)' all I have to do is add: 'register_stat('Transport.get_half_file', TransportGetHalfFile, "%(relpath)us %(start)L %(middle)L")
[07:30] <vila> and the serialization is taken care of, an TransportGetHalfFile object will be created at deserialization time with attributes (base, relpath, start, middle)
[07:30] <vila> anyway I shouldn't talk that much before coffee, bbl :)
[07:34] <lifeless> lol
[07:36] <igc> time to complete the gutsy upgrade - bbl
[07:37] <lifeless> may the repo be with you
[07:37] <lifeless> are you running on the real hardware yet ?
[07:37] <igc> I am on my server and it upgraded ok last night
[07:37] <igc> still running on Parallels on my MacBook
[07:38] <igc> I'll try on the raw hardware in the next week or two hopefully
[07:39] <lifeless> for a frozen distro the churn rate is humungous
[07:41] <igc> and sadly, my patch to the help explaining how to use bzr got dropped
[07:42] <igc> sigh
[07:45] <lifeless> igc: :(
[08:21] <ubotu> New bug: #150834 in bzr-pqm "Make STARTTLS and AUTH work better" [Undecided,New]  https://launchpad.net/bugs/150834
[08:21] <poolie> igc, which patch?
[08:42] <poolie> lifeless: back now?
[08:43] <lifeless> yes
[08:43] <lifeless> meetings over
[08:44] <poolie> in a bit of searching i cannot find a dirstate bug that is fixed by this
[08:44] <lifeless> ok
[08:45] <poolie> which i am a bit surprised by
[08:45] <lifeless> I would assume it was only erroroneous on the cache side then
[08:46] <poolie> so now i'm trying to decide whether to
[08:46] <poolie> 0- just put it up to merge
[08:47] <poolie> 1- run under kcachegrind
[08:47] <poolie> 2- think harder about what kind of failure that could cause
[08:47] <lifeless> I don't think 1 will help
[08:47] <poolie> i have confirmed that it's not rereading them
[08:47] <poolie> so, yeah, it seems redundant
[08:48] <lifeless> I think its passing all tests
[08:48] <lifeless> so this is fine in terms of our quality metric
[08:48] <poolie> it would have been nice to have closed off additional bugs
[08:48] <poolie> ok
[08:48] <lifeless> it would be nice if you do think of a 'X should break under the old code' to come back to it
[08:48] <lifeless> but I think we're at diminishing terms
[08:49] <lifeless> *returns*
[08:49] <poolie> agree - just one thing - can you look at _cmp_path_by_dirblock_py and confirm for me that
[08:49] <poolie> the docstring is backwards
[08:49] <poolie> wrt negative vs positive
[08:52] <lifeless> do you mean cmp_by_dirs ?
[08:52] <poolie> both of them
[08:53] <poolie> they all have similar docstrings and i think they're all wrong
[08:53] <lifeless> well
[08:53] <lifeless> only one is exposed
[08:54] <lifeless> >>> import bzrlib.dirstate
[08:54] <lifeless> >>> bzrlib.dirstate.cmp_by_dirs
[08:54] <lifeless> <function cmp_by_dirs_py at 0x2b178b89db90>
[08:54] <lifeless> >>> bzrlib.dirstate.cmp_by_dirs('foo', 'bar')
[08:54] <lifeless> 1
[08:54] <lifeless> >>> bzrlib.dirstate.cmp_by_dirs('bar', 'foo')
[08:54] <lifeless> -1
[08:54] <lifeless> I haven't read the code
[09:00] <bialix> poolie: are you here?
[09:01] <poolie> hi bialix
[09:01] <bialix> hi poolie. when next feature freeze planning?
[09:02] <poolie> i'm leaving it open for a couple more days to try to land pack changes
[09:03] <poolie> i should send mail about that
[09:03] <bialix> I'd like to fix bug 129298 for 0.92
[09:03] <ubotu> Launchpad bug 129298 in bzr "Windows standalone installer should create plugins directory" [Low,In progress]  https://launchpad.net/bugs/129298
[09:03] <poolie> that would be good
[09:04] <bialix> I'm thinking about providing standalone installers for some plugins, like bzrtools
[09:04] <bialix> so this bug is show stopper for me
[09:04] <bialix> I think I'll send merge request in next couple of days
[09:10] <poolie> k
[09:11] <poolie> bialix: maybe there should be just one installer and it should ask you which plugins you want?
[09:11] <bialix> pollie: it's possible, but I'm slightly worried about size of all-in-one installer
[09:12] <bialix> even though now I have radiomodem and moderate quality of internet, I'm still remember dial-up days
[09:12] <poolie> yes, i see
[09:12] <bialix> bzrtools is pretty small though
[09:12] <poolie> right
[09:13] <bialix> QBzr is bigger (+3MB to installer) because it carries Qt libraries
[09:13] <poolie> if bzr-gtk needed to install the gtk libraries that could make it a lot bigger
[09:13] <poolie> exactly
[09:13] <bialix> yeah, that's why I think QBzr is better choice for win32: it's much smaller
[09:13] <poolie> oh, interesting
[09:13] <igc> my leaning is toward one installer. Can we see what size it would be first before taking another path?
[09:14] <bialix> ok, it's doable
[09:14] <poolie> maybe one big one and one smaller one
[09:14] <bialix> I'll do sone experimenting tonight and post result tomorrow
[09:14] <igc> thanks
[09:15] <bialix> anyway as sane solution, I could provide bare installer (only bzr.exe) and rich installer (with batteries included)
[09:15] <bialix> but I understand that there is already zoo of installers for win32
[09:15] <igc> I know it seems a small detail but multiple installers means cross-checking versions match, etc.
[09:15] <igc> anything we can do to lower the barrier to entry is very valuable I think
[09:16] <igc> and one installer fits into that camp IMHO
[09:16] <bialix> IMO, rich installer with plugins is the sane answer to hsn_ who 2 days ago complains about bzr is hard to install on windows
[09:17] <bialix> but I'm not planning to include bzr-gtk
[09:17] <bialix> I dislike PyGTK bloat
[09:17] <igc> sounds like QBzr is shaping up nicely though
[09:17] <poolie> it does
[09:17] <poolie> it's kind of a shame to have the duplication
[09:17] <bialix> well it lacks QOlive, otherwise it's very good
[09:18] <bialix> it's inevitable
[09:18] <bialix> Lukas did very nice work with side-by-side diff
[09:18] <poolie> in Q or G?
[09:18] <bialix> Q
[09:19] <bialix> but I'm using bzr-gtk about a year ago, may be they more similar than different
[09:19] <bialix> now
[09:20] <bialix> my point about Q vs G is: Q more windows-alike than G
[09:46] <poolie> spiv: hi, what's new with hpss?
[09:48] <Peng> What interesting branches are there, for someone useless who just likes reading changelogs?
[09:49] <poolie> Peng, https://code.launchpad.net/
[09:50] <Peng> Sure, but there are a lot of them, I don't know what they're all for, and I don't know which ones have been merged into bzr.dev and abandoned.
[09:51] <bialix> what colors means
[09:51] <bialix> ?
[09:51] <bialix> green and blue?
[09:51] <poolie> one is 'uses bzr natively' and one is 'imported from cvs or svn'
[09:52] <poolie> Peng, i'm not sure what you're looking for
[09:52] <Peng> Interesting changelogs.
[09:53] <poolie> on bazaar, or something else?
[09:53] <poolie> hello mwh_
[09:53] <mwhudson> poolie: hi
[09:54] <poolie> mwhudson, Peng's question is something i'd like code to answer more
[09:54] <poolie> 'show me some interesting code'
[09:54] <poolie> or interesting changes
[09:56] <Peng> I guess I'm curious what's going on with Bazaar.
[09:56] <poolie> https://code.edge.launchpad.net/~bzr/bzr/trunk plus http://bundlebuggy.aaronbentley.com/ gives a good picture
[09:56] <bialix> umm, packs?
[09:56] <poolie> http://bundlebuggy.aaronbentley.com/?selected=pending&unreviewed=n http://bundlebuggy.aaronbentley.com/?selected=merged
[09:57] <Peng> What about the hpss stuff?
[09:58] <poolie> ping spiv
[09:59] <mwhudson> poolie: there's https://code.edge.launchpad.net/+recently-changed-branches
[10:21] <vila> lifeless: transportstats pushed on launchpad bazaar.launchpad.net/~v-ladeuil/bzr/transportstats
[10:25] <ubotu> New bug: #150860 in bzr "Transports should explicitly track whether a port was specified" [Undecided,New]  https://launchpad.net/bugs/150860
[11:07] <egx0r> I'm using Emacs 23.0.0.x and the bundled vc isn't all that good with bzr. Are you guys aware of any bzr plugins for Emacs or should I just start making my own?
[11:09] <quicksilver> DVC
[11:11] <egx0r> quicksilver: Thanks! I'll look into it
[11:41] <AnMaster> $ bzr branch http://leaves.freeshell.org/envbot emerge-trunk
[11:41] <AnMaster> bzr: ERROR: http://leaves.freeshell.org/envbot/.bzr/checkout/format is redirected to http://myspace.com/redmartian
[11:41] <AnMaster> hum
[11:41] <AnMaster> how do I branch it, I can pull from it but not branch from it
[11:41] <AnMaster> odd
[11:41] <AnMaster> there is no checkout of it on server as far as I know
[11:42] <Peng> It's normal for there not to be checkouts on the server.
[11:42] <Peng> All that's needed is the ".bzr" directory.
[11:42] <AnMaster> so why this error?
[11:42] <AnMaster> and yes the .bzr is there
[11:42] <AnMaster> ...
[11:43] <Peng> ...
[11:43] <Peng> Well, http://leaves.freeshell.org/envbot/.bzr/checkout/format redirects to http://myspace.com/redmartian.
[11:43] <AnMaster> Peng, yes I wonder why I get this error when trying to pull another developer's branch
[11:43] <Peng> That would be why you get the error.
[11:43] <AnMaster> Peng, it seems that server redirect any non-existing file to there
[11:43] <Peng> That's dumb.
[11:44] <Peng> Is that branch using some ancient format or something?
[11:44] <Peng> That file isn't new.
[11:44] <Peng> Oh.
[11:44] <Peng> No .bzr/checkout at all. Which makes sense.
[11:44] <Peng> I don't know why Bazaar cares about that file.
[11:45] <Peng> But redirecting 404s to MySpace is the dumbest thing I've ever heard of.

[11:45] <AnMaster> Peng, I agree
[11:55] <AnMaster>  http://pastebin.ca/730542
[11:55] <AnMaster> anyone got any idea about that?
[11:57] <AnMaster> Peng, maybe you?
[11:59] <Peng> AnMaster: Not sure. Is it a checkout or a branch?
[11:59] <AnMaster> this is a branch of that repo
[11:59] <Peng> I know I've heard of this, I just don't remember it.
[11:59] <Peng> Augh, Barney.
[11:59] <AnMaster> Repository checkout (format: dirstate-tags)
[11:59] <AnMaster> Location:
[11:59] <AnMaster>   repository checkout root: .
[11:59] <AnMaster>         checkout of branch: http://www.vmlinux.org/jocke/bzr/bzrweb/
[11:59] <AnMaster>          shared repository: /usr/home/envbot/bzrweb
[11:59] <Peng> It's a checkout.
[11:59] <AnMaster> hm what
[11:59] <AnMaster> odd
[11:59] <Peng> bzr unbind
[12:00] <Peng> I think there's a bug filed on that locking error, and it might've been fixed.
[12:00] <AnMaster> interesting
[12:02] <AnMaster> is there any plugin or something for cherrypicking, while other version control systems support it, they don't support other features that bzr got (like support for "dumb" static pages only web servers)
[12:02] <AnMaster> Peng, so I need some combination of mercurial and bzr it seems
[12:05] <Peng> I have no idea. :P
[12:07] <mwhudson> mercurial doesn't have any more support for cherrypicking than bazaar does, does it?
[12:08] <jelmer> don't think so. darcs is the king of cherrypicking
[12:08] <jelmer> I mean, I don't think mercurial supports cherrypicking mor ethan mercurial
[12:08] <Peng> Mercurial has the transplant extension.
[12:08] <Peng> Not sure how well it does it.
[12:09] <mwhudson> bzr has the rebase plugin, too :)
[12:18] <AnMaster> is there anything like git bisect for bzr?
[12:22] <jelmer> AnMaster: there is bzr-bisect
[12:22] <AnMaster> ah, link?
[12:24] <jelmer> https://launchpad.net/bzr-bisect
[12:24] <AnMaster> as for cherrypicking, I need something comparable to svnmerge http://www.orcaware.com/svn/wiki/Svnmerge.py
[12:29] <jelmer> that's not possible yet as Bazaar does not have per-file properties yet
[12:29] <jelmer> although I guess it is possible to set revision properties with that information
[12:29] <AnMaster> jelmer, hm
[12:30] <AnMaster> easy handling of back/forward merging between stable and development branch and ability to ignore some changesets from list of changes to merge back to stable branch
[12:30] <AnMaster> that is what I need
[12:31] <AnMaster> and tracking what changes have been merged back of course
[12:31] <AnMaster> jelmer, so what distributed version control systems can handle that?
[12:32] <Zindar> you want partial merges?
 as for cherrypicking, I need something comparable to svnmerge http://www.orcaware.com/svn/wiki/Svnmerge.py
[12:33] <Zindar> oki.. darcs is the best at that.. but sucks in many other ways
[12:33] <Zindar> but .. it's made to do exactly that
[12:33] <Zindar> bzr isn't... it is planned
[12:33] <AnMaster> yes so I understood, but bzr got several other nice features
[12:33] <AnMaster> Zindar, any idea when
[12:33] <Zindar> it's the one feature I really really want
[12:33] <Zindar> post 1.0 sometime I would think
[12:33] <AnMaster> and when will that be?
[12:33] <AnMaster> this year?
[12:34] <Peng> AnMaster: Mercurial puts changes in their stable branch then merges them into the development branch.
[12:34] <Zindar> 1.0 will be I think.. but.. when the cherrypicks will come.. no idea
[12:34] <Peng> (I mean that's how the Mercurial project handles it.)
[12:34] <Zindar> peng: hg, git, bzr all can do it...
[12:34] <AnMaster> Peng, I need to be able to both handle forwardport and backport
[12:34] <Zindar> but the tracking is less then optimal
[12:35] <AnMaster> and yes I understood that darcs got many other problems and I would prefer to stay with bzr, but I need this feature quite fast
[12:41] <Zindar> AnMaster: you CAN handle it in bzr.. but it doesn't track the log, and you'll get the same thing twice when you go back and forward
[12:41] <Zindar> so.. less then optimal
[12:48] <AnMaster> indee
[12:48] <AnMaster> indeed*
[12:48] <AnMaster> so I'm looking for a usable solution
[12:49] <AnMaster> as I can't handle it with maybe 200 changes ignored and 50 ones spread out between them that have been merged back
[12:49] <AnMaster> because it is not merging forward that is most common, merging back is
[12:51] <luks> do you ever merge the backported branches (complete branch, not just cherry picking) back to the dev branch?
[12:52] <AnMaster> probably not but could happen
[12:53] <luks> I don't see the problem with bzr/hg/git-like cherry picking then
[12:53] <AnMaster> they may diverge, for example if some bug fix that affects backported branch but not dev branch because dev branch have rewritten that entire module or such
[12:54] <luks> but then you need a new fix, not the cherry-picked one from the dev branch
[12:56] <AnMaster> indeed
[12:56] <AnMaster> luks, but a lot of the time changes can be backported by cherry-picking
[12:57] <luks> so, bzr merge -rbefore:X..X && bzr commit
[12:57] <AnMaster> that doesn't keep track of what changes I merged back last I tried
[12:58] <AnMaster> wait, before: ?
[12:58] <luks> yep, but my point is that you don't need that
[12:58] <AnMaster> luks, I do when I need to see if I merged back some change or not, and if I decided to not merge it back
[12:58] <luks> before: is the left-most parent revision
[12:59] <luks> AnMaster: well, you see the commit message
[12:59] <AnMaster> because I can't keep track of something like what 50 revisions out of maybe 200 revisions were merged back in my head
[12:59] <luks> but you still do the merges manually
[12:59] <luks> cherry-picking tracking is only useful for automatic merges
[01:00] <luks> (when you merge the whole branch)
[01:00] <AnMaster> svnmerge is manual (http://www.orcaware.com/svn/wiki/Svnmerge.py), yet I would call it much more useful than your suggestion
[01:00] <luks> how is it more useful?
[01:01] <AnMaster> as in "possible to handle with a lot of changes"
[01:01] <AnMaster> afk
[01:01] <luks> the cherry picked changes will have different revnos in svn
[01:02] <luks> so you still can't see which changes were merged
[01:03] <AnMaster> yes I can, because it is stored in svn properties
[01:03] <luks> svnmerge is only useful if you go the other way around, that is if you decide to merge the branch with cherry-picked stuff back to the dev branch
[01:03] <AnMaster> read the link I gave
[01:03] <luks> I know about svnmerge, I
[01:03] <luks> I've used it a lot
[01:03] <luks> but then I found out bzr-svn :)
[01:05] <AnMaster> example:
[01:05] <AnMaster> svnmerge avail
[01:05] <AnMaster> 8074,8079-8080,8082-8083,8088-8089,8097-8098,8101-8103,8107,8109-8112,8115-8118,8121-8127,8129-8130
 svnmerge is only useful if you go the other way around, that is if you decide to merge the branch with cherry-picked stuff back to the dev branch <-- so yes I can see what ones can be merged
[01:06] <AnMaster> $ python ./svnmerge.py integrated
[01:06] <AnMaster> 132-7508,7510-7516,7519-7525,7527-7536,7538,7553,7557-7560,7573-7576,7580-7586,7601-7603,7605,7607-7613,7615-7620,7622,7624,7626,7628,7632,7634-7664,7667-7669,7671-7675,7677-7692,7694-7714,7717-7722,7726-7727,7729-7732,7734-7741,7744-7752,7755,7762-7766,7770-7794,7796,7798-7806,7809,7814-7819,7821-7828,7832,7838,7852,7877,7879,7952,7982,7995,8003,8005,8009,8019,8023,8029,8031,8035,8037,8040,8042,8044,8066,
[01:06] <AnMaster> 8069,8071-8072,8075,8077,8084,8086,8090,8092,8099,8113,8119,8131-8132,8134,8136
[01:09] <AnMaster> luks, so what do you mean with "<luks> so you still can't see which changes were merged"
[01:10] <luks> I didn't know about 'svnmerge.py integrated'
[01:10] <AnMaster> there you are then
[01:10] <luks> but this approach would really not work well in and DVCS
[01:11] <luks> any
[01:11] <AnMaster> indeed
[01:12] <AnMaster> but really that is an example from inspircd's stable branch. luks could you keep track of that without something like svnmerge avail/integrated? if you could, I'm impressed by your memoru
[01:12] <AnMaster> memory*
[01:13] <luks> I prefer to not keep track of things like this myself
[01:13] <luks> if I have a bug, and I need to backport it, then I backport it
[01:13] <AnMaster> exactly, so I need bzr to keep track of it for me
[01:13] <quicksilver> I've never wanted to have cherry-picking on that kind of scale
[01:13] <quicksilver> maybe I just haven't worked on projects like that
[01:13] <luks> and forget about it (in my head, not in my VCS)
[01:14] <luks> in bzr you can have custom per-revision properties
[01:14] <luks> so theoretically you could write a plugin that remembers which revisions were merges
[01:14] <AnMaster> luks, no I can't because I don't know python
[01:14] <luks> the problem is that this info wouldn't be very useful if you have more than one branch
[01:15] <luks> it works in svn, because you have incremental per-repo revnos
[01:15] <AnMaster> but I need some way to keep track of cherry picking on this scale and even larger
[01:16] <luks> or even better you could always associate commits with bug IDs
[01:16] <luks> and then check for fixed bug IDs, not revisions
[01:17] <AnMaster> sure but some bugs you discover when coding something else, then you fix it without first opening a bug
[01:17] <AnMaster> anyway didn't know you could integrate bzr with trac in such a way
[01:17] <luks> well, not with trac
[01:17] <luks> but there is 'bzr commit --fixes'
[01:17] <AnMaster> luks, and I use trac
[01:18] <AnMaster> and that doesn't work with ci --fixes afaik?
[01:18] <AnMaster> + what about reopened bugs
[01:18] <luks> trac would need to be tweaked to understand this data
[01:18] <luks> but yeah, it wouldn't work for reopened bugs
[01:18] <AnMaster> indeed
[01:19] <AnMaster> luks, but why are you so much against cherry-picking?
[01:19] <AnMaster> I can't see why
[01:19] <luks> I'm not against cherry-picking at all
[01:21] <luks> the problem is that in DAG-based systems it's not trivial to implement true cherry-picking, because it breaks the graph
[01:21] <AnMaster> still it is a feature I need :)
[01:21] <quicksilver> There is an objection to cherry-picking which is that it is unsound, because revisions potentially depend on all preceding revisions
[01:21] <hsn_> i need cherry pick as well
[01:22] <quicksilver> however, if the programmer is prepared to deal with the unsoundness then that's his problem
[01:22] <AnMaster> quicksilver, maybe, but what would you suggest instead to handle stuff like the example above
[01:22] <luks> AnMaster: I think you need a list of manually merges changes, not a true cherry-picking
[01:23] <quicksilver> AnMaster: I would bzr merge in the changes I wanted; or in some cases apply diffs by hand if the commit was not atomic enough
[01:23] <quicksilver> AnMaster: and I'd make notes of what I was doing in the commit message
[01:23] <luks> e.g. I use https://code.edge.launchpad.net/~luks/+junk/bzr-pick for semi-automatic cherry-picking
[01:23] <quicksilver> AnMaster: if the scale of the problem grew larger, I would structure my commit messages in some standard way
[01:23] <quicksilver> AnMaster: and then write tools to gnerate the right messages and parse the log file
[01:23] <luks> it would be trivial to add revision properties to remember the origianl revision IDS
[01:23] <luks> and give you the list later
[01:24] <luks> but I don't think the list would be useful to you
[01:24] <AnMaster> luks, something like svnmerge indeed, and I normally merge 1) from other developers stable branch to my stable, and other developers trunk to my trunk. 2) from my trunk to my stable and from my stable to my trunk
[01:24] <AnMaster> not really from other devlopers trunk to my stable
[01:24] <AnMaster> luks, "+junk"?
[01:25] <luks> "+junk" = no product in launchpad
[01:25] <AnMaster> ah
[01:25] <luks> the plugin does nothing else but: bzr merge -r before:X..X && bzr commit
[01:25] <luks> but it's nice to have it in one step, and don't have to copy&paste commit messages
[01:26] <quicksilver> AnMaster: mind you, I wasn't actually *objecting* to cherry picking
[01:26] <quicksilver> AnMaster: I was just letting you know what an objection might be
[01:26] <AnMaster> hm
[01:26] <quicksilver> it's not clear that it has a sound semantic model :)
[01:27] <AnMaster> ok, still it is clear to me that not having some system to handle the problem is unsound for developers
[01:27] <AnMaster> ;P
[01:28] <quicksilver> generally speaking, I don't share changesets between branches to that extent
[01:28] <quicksilver> if they are that close, I merge them
[01:28] <quicksilver> if they're not close, I don't bother to keep back and forward porting stuff :P
[01:29] <AnMaster> depends. for inspircd (using svn), it is about 1.1 is stable and there are new maintenance releases of it, while 1.2 (trunk) is rewriting some core parts, still code in many of it's modules is mostly the same
[01:29] <quicksilver> certainly there are many different ways to organise projects
[01:30] <quicksilver> and many different ways to use your VCS
[01:30] <AnMaster> 1.2 changes how it handles nicks for example by changing to using UUIDs for users to track them instead of using nick for it
[01:31] <AnMaster> and my irc related project that uses bazaar is now about first stable version too, and we would benefit from the same development model, apart from that we also need to be distributed
[03:13] <zorg_the_false> q. i use eclipse 3.3 for a c++ code of around 330kline, what is the status of the eclipse plugin ?
[03:14] <schierbeck> jelmer: hello
[03:15] <corporate_cookie> Is the default python interpreter usually specified with a symlink ?
[03:18] <quicksilver> on debian that's certainly typical
[03:18] <corporate_cookie> thanks quicksilver
[03:18] <quicksilver> debian (and debian-derived OSes) symlink binaries via /etc/alternatives
[03:19] <corporate_cookie> this is what i thought ..however i changed the symlink on RHEL4..and the default interpreter did not change
[03:19] <corporate_cookie> alas : )
[03:21] <quicksilver> to be honest, default is a fiddly concept
[03:21] <quicksilver> what actually *matters* is what the #! line says
[03:21] <quicksilver> if your #! says /usr/bin/python2.3 then it's going to use that
[03:21] <quicksilver> if #! says /usr/bin/python and /usr/bin/python is a symlink, then that's fine
[03:22] <zorg_the_false> q. i run kubuntu feisty, any suggestion for a 'good' ui frontend ?
[03:25] <corporate_cookie> quicksilver: ...alas I'm just a lazy bum who doesn't want to change quite a few #! lines
[03:27] <zorg_the_false> sudo apt-get install bzr-gtk -> "bzr-gtk: Depends: bzr (< 0.91~) but 0.91-2 is to be installed"
[03:28] <quicksilver> corporate_cookie: then blat a symlink over whatever the #! is pointing at
[03:28] <zorg_the_false> but0.91-2 is the one provided by the repository
[03:28] <quicksilver> corporate_cookie: so if the #! is /usr/bin/python2.3, make that a symlink to what you want
[03:29] <corporate_cookie> thanks quicksilver
[03:29] <zorg_the_false> ah ok the repository doesnt contains the last version of bzr-gtk
[03:29] <zorg_the_false> it is only available from source
[04:26] <jelmer> schierbeck, hi
[05:38] <AnMaster> hm launchpad seems quite ubutntu specific, it should really be more distro neutral
[05:38] <AnMaster> to be any useful
[05:39] <AnMaster> of course not sure what is the right place to complain about that
[05:39] <mrevell> jelmer: Hi - can you answer a quick question about lp:
[05:39] <mrevell> AnMaster: Hi
[05:39] <mrevell> AnMaster: I work for the Launchpad team
[05:40] <mrevell> AnMaster: What changes would you like to see to Launchpad to make it more distro neutral?
[05:40] <AnMaster> mrevell, I'm a FreeBSD user so all the ubutntu stuff in the settings for user account seems a bit offending
[05:40] <eolo> hi all. I have a dramatic problem with official docs!! Is there a straightforward 'howto' to start a bzr smart server accessed via bzr+ssh?
[05:40] <AnMaster> like ubuntuwiki, why would I want that
[05:41] <AnMaster> if you want a wiki, why not a launchpad wiki instead
[05:41] <Peng> eolo: The only setup needed is bzr in the PATH ..
[05:41] <AnMaster> why force it to be ubuntu wiki
[05:41] <AnMaster> "This is your wiki name in the Ubuntu wiki. You cannot remove it because without it you won't be able to login there."
[05:41] <AnMaster> ...
[05:41] <AnMaster> I have no plans to login there
[05:41] <radix> AnMaster: I use Launchpad without doing anything related to Ubuntu at all, and it doesn't get in the way at all
[05:42] <AnMaster> "Ubuntero:  No (apply now)  "
[05:42] <AnMaster> what is that btw?
[05:42] <eolo> Peng: what do you mean, bzr is by default in the path: /usr/bin/bzr
[05:42] <mrevell> AnMaster: Right, I see. The Ubuntu wiki uses Launchpad to authenticate users. Does it get in your way?
[05:42] <mrevell> AnMaster: An Ubuntero is someone who has signed the Ubuntu Code of Conduct.
[05:42] <AnMaster> mrevell, not really I guess but why not make it distro neutral.
[05:43] <AnMaster> ok so what about <other distro> wiki/code of conduct
[05:43] <luks> eolo, then it should just work, no need to 'start' anything except your ssh server
[05:43] <AnMaster> do you support that too?
[05:43] <AnMaster> :)
[05:43] <eolo> Peng: The server starts but i cannot connect to it to branch
[05:43] <eolo> perhaps i'm using wrong addresses
[05:44] <AnMaster> mrevell, if you did fine, it is this ubuntu fixation that gets irritating for non-ubuntu users
[05:44] <AnMaster> mrevell, by the way, is the code for launchpad open source?
[05:44] <mrevell> AnMaster: You can add other wikis to your Launchpad profile. I'll post a message to the launchpad-users list with your comments. Ubuntu has obviously been a major user of Launchpad since the beginning but more and more projects are now using Launchpad. I'll raise your concerns with the LP team.
[05:44] <Peng> eolo: Well then, it should work.
[05:45] <eolo> i shouldn't issue the command bzr serve?
[05:45] <luks> bzr serve is for bzr://
[05:45] <eolo> and for bzr+ssh?
[05:45] <mrevell> AnMaster: Launchpad isn't yet open source but I know that our aim is to release it as open source.
[05:45] <luks> eolo, a ssh server
[05:46] <AnMaster> mrevell, ah nice. oh and at least it shouldn't list ubuntu wiki at contact details
[05:46] <AnMaster> or at least be possible to disable that
[05:46] <AnMaster> can't find where to disable it
[05:46] <mrevell> AnMaster: I think the wiki is listed under contact details as it's an opportunity to tell more people where to find out more about you.
[05:47] <AnMaster> mrevell, and the way you do wiki user pages indicate they should be in root namespace of wiki
[05:47] <luks> mrevell, not if it's wiki.ubuntu.com and the person doesn't use it :)
[05:47] <AnMaster> some people use mediawiki and such where that is not the case
[05:47] <mrevell> AnMaster: You mean rather than MediaWiki's User:Name?
[05:47] <AnMaster> exactly
[05:48] <AnMaster> then my username is still Name and base url is still http://foo.whatever  but url to user page is not http://foo.whatever/Name
[05:48] <eolo> so if i have a bzr repo in /home/user/django-projects an a remote host which command should i use to branch from there?
[05:48] <mrevell> AnMaster: You could type User:YourName in the box, that's no problem.
[05:48] <mrevell> luks: I think we have a bug about this actually. Let me find it
[05:49] <AnMaster> mrevell, and really as luks said, that wiki I never visited or plan to visit
[05:49] <eolo> ?? Should i have initialized the repo in a special way?... sorry about silly question
[05:50] <luks> eolo, bzr branch bzr+ssh://example.com/home/user/django-projects/project
[05:50] <AnMaster> mrevell, and another detail, some developers may not be tied to any specific os/distro
[05:50] <AnMaster> even though FreeBSD is my primary OS
[05:50] <AnMaster> I also use OpenSolaris and OpenBSD
[05:51] <AnMaster> and sometimes even linux (Slackware mainly then)
[05:51] <mrevell> AnMaster: Here's a link to a bug report that deals with your complaint: https://bugs.launchpad.net/launchpad/+bug/29542 Would you mind adding your comments there? I'll still raise your issue with the LP team
[05:51] <ubotu> Launchpad bug 29542 in launchpad "Launchpad pages have hardcoded references to Ubuntu" [Medium,Confirmed]
[05:52] <AnMaster> ubotu? argh this place is infected ;)
[05:52] <eolo> luks: ERROR: Not a branch: ????
[05:52] <luks> eolo, do you have a branch there?
[05:52] <AnMaster> elmo, try sftp too instead of bzr+ssh I guess
[05:53] <AnMaster> mrevell, is pasting parts of irc log ok? I'm not motivated to write it down once again
[05:53] <mrevell> AnMaster: So long as it's edited to be specific to the issue, that's fine.
[05:54] <AnMaster> indeed I will cut out other bits of course
[05:55] <mrevell> AnMaster: thanks :)
[05:57] <AnMaster> mrevell, btw you don't need to highlight me on every line, once every now and then works fine
[05:57] <AnMaster> ;P
[06:00] <AnMaster> mrevell, for bug tracker, any special stuff needed to make it not mess up newlines
[06:00] <AnMaster> like {{{ }}} of trac
[06:00] <AnMaster> or <pre> or whatever of others
[06:01] <mrevell> There isn't a pre-formatted option for the LP bug tracker.
[06:01] <AnMaster> no preview button I notice
[06:01] <radix> LP bug comment text is already pre-formatted, it won't mess up your new lines
[06:01] <AnMaster> ah seems to be pre-formatted anyway good
[06:01] <radix> (and description text)
[06:01] <AnMaster> radix, well I see that now, but other systems are not the same
[06:02] <AnMaster> mrevell, anyway added comment with what I think is relevant
[06:02] <mrevell> AnMaster: Thanks!
[06:02] <AnMaster> mrevell, what language is launchpad in?
[06:03] <mrevell> Python
[06:03] <AnMaster> would it work with fastcgi or does it depend on a LAMP setup or such?
[06:04] <AnMaster> something to note for when you make it open source
[06:04] <AnMaster> mrevell, :)
[06:07] <AnMaster> mrevell, hm this "ppa" seems ubuntu specific too
[06:08] <mrevell> AnMaster: Launchpad is built around a PostgreSQL, modified Zope and Apache setup.
[06:08] <AnMaster> should be called "uppa" then ;)
[06:09] <mrevell> as for PPA, yes right now it is Ubuntu specific but it may well be made available for other distros in the future. I think the plan is to complete the beta and get it into production and then to look at what might come next.
[06:09] <AnMaster> mrevell, so ppa is a server side build system to build for different arches?
[06:10] <AnMaster> C/C++ and a few more sure
[06:10] <mrevell> PPA is a build system, yes, but also an apt repository hosting service. It supports x86 and AMD64 atm
[06:10] <mrevell> AnMaster: We should probably take this to #launchpad if we carry on. Don't want to hijack the bzr channel :)
[06:11] <AnMaster> ah ok didn't know about that channel
[06:11] <AnMaster> mrevell, just one thing: <ubotu> Your edit request has been forwarded to #ubuntu-ops.  Thank you for your attention to detail
[06:11] <AnMaster> huh?
[06:12] <mrevell> Where did you see that?
[06:12] <AnMaster> in /msg here on freenode
[06:13] <AnMaster> I didn't say anything to it in /msg or anything
[06:13] <AnMaster> so I don't know what it is on about
[06:13] <AnMaster> mrevell, any idea?
[06:13] <mrevell> AnMaster: Let me look into that for you
[06:14] <AnMaster> I did not enter any irc info into my profile, or rather I did, and then removed it directly
[06:18] <AnMaster> mrevell, so what caused it?
[06:20] <mrevell> AnMaster: I'm not all that familiar with Ubotu but there's a page that explains more about it at https://wiki.ubuntu.com/UbuntuBots The person that maintains ubotu - seveas - appears to be offline atm
[06:20] <AnMaster> mrevell, well I can't be bothered to try to find that person, so if you like you said will handle it, fine for me
[06:20] <AnMaster> :)
[06:21] <mrevell> I'll see what I can find out for you
[06:22] <AnMaster> as far as I know I didn't give it any command...
[06:22] <AnMaster> mrevell, btw, the message was at 17:52:23 (UTC+2)
[06:23] <mrevell> ok, thanks
[06:23] <AnMaster> hm
 ubotu? argh this place is infected ;)
[06:23] <AnMaster> was at that point
[06:23] <AnMaster> silly of it to react on that if that is what it did
[06:40] <LarstiQ> 6/names
[06:40] <LarstiQ> meh
[06:41] <LarstiQ> :)
[06:56] <acuster> Hey all, how do I cleanup a bzr branch? i.e. bzr branch trunk working, then I want to blow away working?
[06:58] <mwhudson> rm -rf
[06:58] <jaavaaguru__> rm -rf working?
[06:58] <acuster> and the shared repository doesn't mind?
[06:58] <acuster> how does it clean itself up?
[06:59] <mwhudson> ah, you can end up with some unreferenced revisions in there
[06:59] <mwhudson> my general approach to that is to not care
[07:00] <mwhudson> though i think there's a plugin that can remove them
[07:03] <acuster> that kind of cruft has a way of coming back to bite me
[07:04] <acuster> ah, so bzr needs a remove-branch command
[07:25] <zorg_the_false> q. i use eclipse 3.3 for a c++ code of around 330kline, what is the status of the eclipse plugin ?
[07:57] <james_w> zorg_the_false: I'm not sure. I think it has basic functionality.
[07:58] <zorg_the_false> james_w: ok. i dont need big funky. but i do need stability...
[07:58] <zorg_the_false> aka this is my text editor when i code :)
[07:58] <zorg_the_false> let me code, dont crash :)
[08:20] <ubotu> New bug: #151027 in bzr "[bug]  RepoFetcher run between the same location" [Low,Triaged]  https://launchpad.net/bugs/151027
[08:35] <dennda> hi there
[08:35] <dennda> i have a problem with pushing my updates
[08:36] <dennda> http://pastebin.ca/731020
[08:36] <dennda> any idea why that is
[08:38] <fullermd> http isn't writable, so you can't push over it.
[08:38] <dennda> thats https. and if i am not totally mistaken, this worked once
[08:39] <dennda> anyways: how can I solve this then?
[08:39] <fullermd> https is just http with bits scrambled  ;p
[08:39] <james_w> dennda: you need to use sftp://
[08:39] <fullermd> You want to use bzr+ssh instead (or sftp, but bzr+ssh is better)
[08:39] <fullermd> The LP page for that branch should tell you the URL via that scheme.
[08:40] <dennda> bzr +ssh says Permission denied (publickey).
[08:42] <dennda> err
[08:42] <dennda> no ssh key
[08:42] <dennda> that's probably it
[08:42] <fullermd> LP only does key auth.
[08:49] <joes2> hi. any sysadmins around for the apache server which hosts the wiki?
[08:50] <joes2> i'm the sysadmin for apache.org, and would like to help you with your spam problem
[08:51] <james_w> joes2: great, thanks. I'm not sure who the admins are. There was some discussion on the list about the spam problem recently.
[08:51] <james_w> I think the admins are canonical's sysadmin tead.
[08:51] <james_w> s/tead/team/
[08:53] <Peng> tead: team lead? :)
[08:54] <joes2> those guys don't hang out here?
[08:55] <james_w> sometimes, I'm not sure who all the team are, so I can't say for sure.
[08:55] <james_w> joes2: if you would post to the list I am sure you would get somewhere. I don't think there is anyone who really knows online at the moment.
[08:55] <joes2> which list?
[08:55] <james_w> unless you want to wait a couple of hours for lifeless or poolie
[08:56] <james_w><EMAIL_ADDRESS>at least someone will know who to contact.
[08:56] <joes2> it's not urgent.  at apache.org i think we've managed to drive the spammer off.
[08:56] <joes2> i was wondering if the same thing would work for your wiki
[08:57] <james_w> that's good, it would be great to use your skills. Sorry I can't give you the information that you need right now.
[08:57] <joes2> are they on .eu time?
[08:57] <james_w> .au
[08:58] <joes2> ok. i'll try back later then. thanks for the info
[08:58] <james_w> thanks.
[09:09] <baijiutong> does anyone know if it's possible to use bzr-svn to only push to svn repos when you tell it to?
[09:10] <baijiutong> when i do a 'ci' on a repo that i've cloned from a svn repo, it pushes it to the svn repo
[09:12] <baijiutong> i'm almost brand new to bazaar, so maybe that's not the right workflow for things.
[09:31] <james_w> baijiutong: you probably want to run 'bzr unbind'
[09:31] <baijiutong> okay
[09:32] <baijiutong> will that allow me to push back to the svn repo, or should i be using branches and merges for that?
[09:32] <james_w> baijiutong: in future if you use 'bzr branch' instead of 'bzr checkout' then you will get what you want.
[09:33] <james_w> see 'bzr help checkouts' for some more information on the difference.
[09:33] <baijiutong> i figured that out playing about just now, sorry :)
[09:34] <james_w> baijiutong: no problem.  I'd like to make a new branch and commit those changes to that branch, instead of the current one.
[09:51] <dash> is there an obvious command for doing that?
[09:51] <dash> or should I branch first, commit, then rename the directories? :)
[09:51] <fullermd> branch ; merge --uncommitted
[09:51] <dash> aha.
[09:51] <dash> i sort of remember that now.
[09:51] <fullermd> Well, that way works too, and may be easier.
[09:51] <fullermd> Or even commit, branch the old rev, and rename the dirs.


[00:20] <RAOF> blackboxsw:Me is actually mid-morning. Let's get some cloud-init happening!
[00:29] <blackboxsw> schweet RAOF
[00:29] -queuebot:#ubuntu-release- Unapproved: ibm-java80 (xenial-proposed/partner) [<IP_ADDRESS>-0ubuntu1 => <IP_ADDRESS>-0ubuntu1] (no packageset)
[00:39]  * RAOF grins at `safeyaml`
[00:45] <RAOF> blackboxsw: It would be nice to explicitly mention that the Debian patch dropped was dropped because it's in the new upstream release, rather than me trawling through the long upstream changelog ;)
[00:46] <blackboxsw> Ahh excellent, yes, will amend that in the descr, and of future SRUs
[00:46] <blackboxsw> RAOF: should that be the debian/changelog text that says that
[00:46] <blackboxsw> ?
[00:46] <blackboxsw> we can fixup our tooling to emit that
[00:47] <RAOF> Yeah, ideally.
[00:47] <blackboxsw> ok will do
[00:47] <blackboxsw> will ammend that for all subsequent SRUs
[00:47] <RAOF> Changelogs for SRUs are kinda annoying, in that they have two distinct audiences.
[00:47] <RAOF> Developers working on the package, and users working out whether to upgrade the package :)
[00:48] <blackboxsw> RAOF: which debian/changelog entry text are we talking about changing?
[00:49] <blackboxsw> I'm trying to find an unclear one that doesn't already say dropped due to upstream inclusion
[00:49] <RAOF> Oh! Xenial's.
[00:49] <blackboxsw> ok moving to xenial to check
[00:49] <blackboxsw> there I see   * refresh patches:
[00:49] <blackboxsw>    + debian/patches/ec2-classic-dont-reapply-networking.patch
[00:49] -queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [19.3-41-gc4735dd3-0ubuntu1~16.04.1]
[00:50] <blackboxsw> and previous SRUs had   * drop the following cherry-picks now included:
[00:50] <blackboxsw>     + cpick-1d5e9aef-azure-Add-apply_network_config-option-to-disable
[00:50] <blackboxsw> ohhhh      - drop cherry picks included in upstream/master commit 7d5d34f3
[00:51] <RAOF> Hm.
[00:51] <blackboxsw> I see, sorry about that. I think this was a one off case RAOF, I'll make sure we adhere to our typical cherry pick dropping (we have tooling that does that and write the appropriate debian/changelog and I think that wasn't used on xenial
[00:52] <RAOF> It also appears to be missing from bionic.
[00:54] -queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (bionic-proposed) [19.3-41-gc4735dd3-0ubuntu1~18.04.1]
[00:55] -queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (disco-proposed) [19.3-41-gc4735dd3-0ubuntu1~19.04.1]
[00:55] <blackboxsw> RAOF: that patch wasn't needed bionic I believe. and this SRU should sync both xenial and bionic to be equivalent
[00:56] <RAOF> Hm. It's actually been dropped from all series, and not mentioned explicitly.
[00:57] <blackboxsw> hrm, ok I need to figure out why that's happened
[00:57] -queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (eoan-proposed) [19.3-41-gc4735dd3-0ubuntu1~19.10.1]
[00:57] <blackboxsw> thanks for this
[00:57] <RAOF> You might want to see if there's something about that patch which your current tooling fails to pick up.
[00:58] <blackboxsw> yep I think in all cases it was a git cherry-pick manually run instead of our tooling 'cherry-pick'
[00:58] <blackboxsw> which would have added the appropriate debian/changelog entry
[00:58] <blackboxsw> ok I'll talk to our team tomorrow to make sure that's not repeated
[00:58] <blackboxsw> #newguys ;)
[00:58] <RAOF> :)(
[00:59] <blackboxsw> not so new, just newer to our team :)
[00:59] <blackboxsw> and had different tooling on their team.\
[05:39] -queuebot:#ubuntu-release- New: accepted hypopg [amd64] (focal-proposed) [1.1.3-1]
[05:39] -queuebot:#ubuntu-release- New: accepted hypopg [armhf] (focal-proposed) [1.1.3-1]
[05:39] -queuebot:#ubuntu-release- New: accepted hypopg [s390x] (focal-proposed) [1.1.3-1]
[05:39] -queuebot:#ubuntu-release- New: accepted hypopg [arm64] (focal-proposed) [1.1.3-1]
[05:39] -queuebot:#ubuntu-release- New: accepted hypopg [ppc64el] (focal-proposed) [1.1.3-1]
[06:03] <cpaelzer> bdmurray: open-vm-tools  has only went to -updates for Eoan
[06:03] <cpaelzer> bdmurray: the block-proposed that I added was for Bionic and Disco
[06:04] <cpaelzer> I thought that should work for those two, or is the tag non-functional as soon as it was released for one series?
[06:07] <cpaelzer> apw: vorlon: seb128: is one of you around to set the phasing of open-vm-tools 2:11.0.1-2ubuntu<IP_ADDRESS> in Eoan back to 0%
[06:08] <cpaelzer> currently at 70%
[06:08] <cpaelzer> reasons https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1844834/comments/19  https://github.com/vmware/open-vm-tools/issues/390
[06:08] <gitbot> vmware issue 390 in open-vm-tools "Crash in HostinfoLsbRemoveQuotes" [Open]
[09:39] <apw> cpaelzer, the tools say it is at 0%
[09:41] <cpaelzer> apw: hmm, yeah it says it now
[09:41] <cpaelzer> was saying 70% this morning
[09:41] <cpaelzer> Ah here, I got a mail about 2h ago
[09:41] <cpaelzer> maybe some AA already responded but didn't ping
[09:42] <apw> perhaps, not sure who is awake but ok
[10:07] <rbalint> hi, rbasak please take a look at wslu in your sru cycle
[10:13] -queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi3 [Eoan 19.10.1] has been updated (20191203)
[10:13] -queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi3 [Eoan 19.10.1] has been updated (20191203)
[10:25] <LocutusOfBorg> sforshee, of course testing is appreciated :)
[10:49] <LocutusOfBorg> mdeslaur, can clamav go in sync now?
[10:50] <LocutusOfBorg> I mean, the patch is in stable releases, it is not needed anymore, right?
[10:59] <LocutusOfBorg> any AA, please move golang-1.12-race-detector-runtime to universe and golang-1.13-race-detector-runtime to main, thanks
[12:14] -queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (disco-proposed/main) [5.0.0-1027.28] (core, kernel)
[12:15] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-171.200] (core, kernel)
[12:44] -queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (disco-proposed) [5.0.0-1027.28]
[12:45] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-171.200]
[12:51] <sforshee> LocutusOfBorg: virtualbox-guest-dkms 6.0.14-dfsg-4 builds fine with 5.4, thanks!
[12:54] <ahasenack> hello, could an archive admin please take a look at the haproxy i386 failure in https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#haproxy ?
[12:54] <ahasenack> is this a case where the i386 package has to be removed, as per vorlon's email to ubuntu-devel a few days ago?
[12:57] <jdstrand> vorlon: thanks!
[13:07] <ahasenack> for my case, neutron-metadata-agent exists for i386, but it wants haproxy, which wasn't built for i386
[14:15] <cpaelzer> apw: seb128: doko: pinging AAs for a removal as described in bug 1853003
[14:26] <seb128> cpaelzer, apw, doko, done now
[14:27] <cpaelzer> thank you
[14:27] <seb128> cpaelzer, can you get it removed from https://people.canonical.com/~ubuntu-archive/seeds/platform.focal/supported-misc-servers , I overlooked that before removing it :-/
[14:27] -queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1051.54] (kernel)
[14:27] <cpaelzer> yes I'll open an MP for that, just a sec
[14:27] <seb128> thx
[14:27] -queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (disco-proposed/main) [5.0.0-1009.14] (core, kernel)
[14:29] -queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (disco-proposed) [5.0.0-1009.14]
[14:30] <cpaelzer> seb128: https://code.launchpad.net/~paelzer/ubuntu-seeds/+git/platform/+merge/376334
[14:31] <cpaelzer> arr merge target might mismatch
[14:31] <seb128> cpaelzer, wrong... right
[14:32] <cpaelzer> looks much saner https://code.launchpad.net/~paelzer/ubuntu-seeds/+git/platform/+merge/376335
[15:29] <vorlon> ahasenack: the haproxy i386 binaries were removed; the triggering of the test for the non-existent haproxy binaries is the annoying britney behavior.  I've added a round of badtest hints
[15:34] -queuebot:#ubuntu-release- Unapproved: python-stdlib-extensions (bionic-proposed/main) [2.7.16-2~18.04 => 2.7.17-1~18.04] (kubuntu, ubuntu-desktop)
[15:34] -queuebot:#ubuntu-release- Unapproved: python2.7 (bionic-proposed/main) [2.7.15-4ubuntu4~18.04.2 => 2.7.17-1~18.04] (core)
[15:52] -queuebot:#ubuntu-release- Unapproved: swift (eoan-proposed/main) [2.23.0-0ubuntu1 => 2.23.1-0ubuntu<IP_ADDRESS>] (openstack)
[16:28] <ahasenack> vorlon: thanks
[16:43] <RikMills> imagemagick needs a no change rebuild against libopenexr24 to get nearer to completing that transition. could any core-dev lurking be kind enough to oblige?
[17:38] <ahasenack> vorlon: neutron also needs a badtest for i386? https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#haproxy
[17:38] <ahasenack>  neutron-metadata-agent : Depends: haproxy but it is not installable
[17:39] <ahasenack> or should neutron stop being built for i386
[18:31] -queuebot:#ubuntu-release- New binary: ldb [amd64] (focal-proposed/main) [2:2.0.7-4] (core, i386-whitelist)
[18:31] -queuebot:#ubuntu-release- New binary: ldb [s390x] (focal-proposed/main) [2:2.0.7-4] (core, i386-whitelist)
[18:32] -queuebot:#ubuntu-release- New binary: ldb [ppc64el] (focal-proposed/main) [2:2.0.7-4] (core, i386-whitelist)
[18:33] <ahasenack> hi archive admins, the new binary above is a soname change: libldb1 -> libldb2
[18:33] <ahasenack> could someone let it through please?
[18:33] -queuebot:#ubuntu-release- New binary: ldb [i386] (focal-proposed/main) [2:2.0.7-4] (core, i386-whitelist)
[18:34] <ahasenack> although it's still building for arm
[18:37] -queuebot:#ubuntu-release- New binary: ldb [armhf] (focal-proposed/main) [2:2.0.7-4] (core, i386-whitelist)
[18:37] -queuebot:#ubuntu-release- New binary: ldb [arm64] (focal-proposed/main) [2:2.0.7-4] (core, i386-whitelist)
[18:39] <ahasenack> ok, all built now
[18:41] <cjwatson> This sort of new-on-import-from-Debian is semi-automatic, but done anyway
[18:41] -queuebot:#ubuntu-release- New: accepted ldb [amd64] (focal-proposed) [2:2.0.7-4]
[18:41] -queuebot:#ubuntu-release- New: accepted ldb [armhf] (focal-proposed) [2:2.0.7-4]
[18:41] -queuebot:#ubuntu-release- New: accepted ldb [ppc64el] (focal-proposed) [2:2.0.7-4]
[18:42] -queuebot:#ubuntu-release- New: accepted ldb [arm64] (focal-proposed) [2:2.0.7-4]
[18:42] -queuebot:#ubuntu-release- New: accepted ldb [s390x] (focal-proposed) [2:2.0.7-4]
[18:42] -queuebot:#ubuntu-release- New: accepted ldb [i386] (focal-proposed) [2:2.0.7-4]
[18:45] <ahasenack> thanks!
[18:45] <ahasenack> I have two other uploads that need this ldb version, so this speeds that up
[19:58] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-73.82~16.04.1] (kernel)
[19:58] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-73.82~16.04.1] (kernel)
[20:46] <kanashiro> smartmontools is not a candidate to migrate from proposed because of a missing build on i386, could someone please help me with that?
[21:06] <vorlon> kanashiro: I was just working my way through the proposed-migration list down to that one; the i386 binaries will be removed shortly
[21:07] <kanashiro> thanks vorlon
[21:20] <vorlon> kanashiro: mm.  the revdep tree of this package is deep (I just hit qemu), this may wind up waiting until I do the mass i386 binary removals
[21:25] <kanashiro> vorlon, ok
[21:25] <vorlon> actually the qemu revdeps weren't so bad, almost done pruning
[21:32] -queuebot:#ubuntu-release- Unapproved: mdadm (bionic-proposed/main) [4.1~rc1-3~ubuntu18.04.2 => 4.1~rc1-3~ubuntu18.04.3] (core)
[21:32] -queuebot:#ubuntu-release- Unapproved: mdadm (eoan-proposed/main) [4.1-2ubuntu3 => 4.1-2ubuntu3.1] (core)
[21:32] -queuebot:#ubuntu-release- Unapproved: mdadm (disco-proposed/main) [4.1-1ubuntu1 => 4.1-1ubuntu1.1] (core)
[21:32] -queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1051.54]
[21:32] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-73.82~16.04.1]
[21:32] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-73.82~16.04.1]


[01:06] <johnlittle> dugg
[01:08] <johnmark> woo
[04:52] <poningru> yarr
[05:03] <johnlittle> eh
[06:47] <MitchM_> ls -l
[06:47] <MitchM_> ping ?
[06:48] <tonyyarusso> pong
[06:55] <Whit3Rabbit__> *shrugs*
[06:55] <Whit3Rabbit__> internet problems ^.^
[06:56] <Mitch> so has jenda been running around tonight?
[06:56] <nixternal> jenda is gone again for a week or so
[06:56] <Mitch> bah.
[06:56] <Mitch> thanks =)
[06:57] <tonyyarusso> Speaking of whom, what were the 'complaints' that made ubuntupeople.com shut down, and will the site ever come back up under new administration?
[06:57] <nixternal> guy who ran it didn't like the fact he wasnt' in control..and no it will never come back
[06:57] <poningru> tonyyarusso: the point of that was to bring marketing more into lp/ubuntuforums
[06:57] <Burgundavia> tonyyarusso: we are better we off without a duplicative forum
[06:57] <nixternal> ubuntupeople was to become spreadubuntu
[06:58] <Burgundavia> who was running it again?
[06:58] <Mitch> off to go play my nightly dos of video games.
[06:58] <Mitch> cheers
[06:58] <tonyyarusso> poningru: Ah.  Shouldn't the page just go away entirely then, rather than having that message?  Or maybe "See <link to lp>"?
[06:58] <nixternal> something lloyd i think
[06:58] <nixternal> i can't remember his name
[07:02] <ormiret> whois says Lloyd Hardy, and it is up to him what the page says not us.
[07:02] <nixternal> ya
[07:14] <Burgundavia> https://wiki.ubuntu.com/LloydHardy?action=diff&rev2=11&rev1=1
[07:24] <johnlittle> wtf
[07:36] <nixternal> hey, watch that tone of voice in here ;)
[10:19] <livingdaylight> YO!
[10:19] <livingdaylight> mornin Folks
[10:19] <livingdaylight> G'day to ya Alz!
[10:20] <livingdaylight> is this another dead ubuntu channel?
[10:21] <Madpilot> actually, this is usually a fairly active channel - just not tonight, I guess
[10:21] <livingdaylight> i was wondering where i might get a leaflet ?
[10:22] <Madpilot> a leaflet explaining Ubuntu?
[10:22] <livingdaylight> in the Examples folder there is a Kubuntu 'leaflet' and i wanted an Ubuntu version to print off so i could put my extra ubuntu discs i ordered in a library
[10:24] <livingdaylight> hmmmm......
[10:24] <Madpilot> livingdaylight, looks like a cool leaflet - don't think there's an Ubuntu version yet
[10:25] <livingdaylight> Madpilot: if i was a bit of a gimp mage i coult just replace the k with the u but that would be beyond my gimp skills repertoire
[10:26] <livingdaylight> why put a kubuntu leaflet and not the ubuntu version when that has to be more popular version
[10:26] <Madpilot> well, there are other differences between Kubuntu & Ubuntu aside from the one consonant ;)
[10:26] <Madpilot> livingdaylight, because someone made the Kubuntu one, and there was no Ubuntu one
[10:27] <livingdaylight> let me see: as far as i recall its a basic intro to linux and ubuntu
[10:28] <Madpilot> most of that would be a straight cut-n-paste to produce a Ubuntu version
[10:29] <Madpilot> livingdaylight, if you want to help produce an Ubuntu version of that, that would be cool
[10:35] <livingdaylight> Madpilot: sorry, got disconnected
[10:36] <Madpilot> np. did you see my last comment, about helping to produce an Ubuntu version of that pamphlet?
[10:36] <livingdaylight> sure i'd like to make an Ubuntu version, i think it would be nice. But like i said i am not a Gimp Mage
[10:36] <livingdaylight> it goes beyond my reportoire of gimp skills
[10:37] <livingdaylight> which are basically reducing an image to an acceptable Avatar size  :D
[10:37] <Madpilot> actually, Inkscape would be better for that type of project. It handles text far better than the GIMP
[10:37] <livingdaylight> ok!
[10:38] <livingdaylight> well, it would be a very steep learning-curve for me
[10:38] <livingdaylight> but you sound like somone who could knock it out in 5 minutes
[10:39] <livingdaylight>  :D
[10:40] <Madpilot> if you write the text and email it to me, I could have it prettied up in Inkscape in an hour or so, I think ;)
[10:41] <livingdaylight> woah! ok, but the text is just a matter of replacing kubuntu with ubuntu pretty much isn't it?
[10:42] <Madpilot> most of it is
[10:43] <Madpilot> the stuff at the top of the righthand column would have to be re-written
[10:45] <livingdaylight> the paragraph of what Kubuntu includes?
[10:46] <livingdaylight> yes, aguess ubuntu doesn't include Konqueror or Kontact
[10:46] <Madpilot> no
[10:46] <livingdaylight>  ;)
[10:46] <Madpilot> Evolution for email, Nautilus for file management, Firefox for browsing
[10:47] <livingdaylight> so, just replace those three words, huh?
[10:50] <Madpilot> not sure, have a look thru the text properly first
[10:54] <livingdaylight> so, ok, descriptions for evolution, Nautilus and Firefox are differnt from those corresponding kubuntu ones. but no big deal. just a brief explanation of each application
[10:54] <livingdaylight> i'd be happy to do it but gimp and inkscape are not within my repertoire
[10:54] <livingdaylight> i'm looking at it from inkspace now
[10:55] <livingdaylight> how would i take out a section and replace it with my own write up?
[10:55] <livingdaylight> especialy teh logo ubuntu wants to be inteh same font as teh rest to remain congruent with the rest of teh leaflet
[10:58] <Madpilot> livingdaylight, if you want to do the writing & email it to me -<EMAIL_ADDRESS>- I'll do the design from scratch in Inkscape
[10:59] <KenSentMe> Madpilot: i wouldn't paste your email in here, this channel is being logged
[10:59] <Madpilot> pfft.
[10:59] <Madpilot> Gmail has awesome spam filters :)
[11:00] <KenSentMe> Madpilot: good way to test them ;)
[11:00] <Madpilot> it's not like it isn't already all over the web
[11:00] <KenSentMe> Madpilot: it was just a tip
[11:00] <Madpilot> I know, but it's not something I worry about, personally.
[11:01] <KenSentMe> Well, that's up to you
[11:01] <livingdaylight> i can vouch for gmail's powerful spam filters
[11:01] <livingdaylight> my box is full!
[11:02] <livingdaylight> Madpilot: ok, i'll be in touch
[11:04] <Madpilot> http://www.warbard.ca/temp/ubuntu-pamphlet01.png
[11:04] <Madpilot> basic graphics done
[11:04] <livingdaylight> wow, NICE!
[11:05] <livingdaylight> i gotta learn that stuff. cant be hard right?
[11:05] <Madpilot> Inkscape is awesome, and not that hard to get into
[11:05] <Madpilot> far easier to learn than the gimp, I think
[11:06] <livingdaylight> is there a good tutorial for beginners?
[11:06] <Madpilot> there are several - just a sec, I'll find the URLs
[11:06] <Madpilot> http://tavmjong.free.fr/INKSCAPE/
[11:07] <livingdaylight> Thank you, i've bookmarked that
[11:07] <Madpilot> that one ^^^, and check the onboard help files inside Inkscape - they're very well done, and almost all in SVG, so you can learn by rearranging the entire help file :)
[11:08] <livingdaylight> and the text: is there an Ubuntu font or do you just copy and paste and then rearrange the size?
[11:08] <Madpilot> no, there's an Ubuntu font
[11:08] <livingdaylight> ok, why havn't i got that in my font dropdown then?
[11:08] <livingdaylight> do i need to install that extra?
[11:09] <livingdaylight> i'd a thought that comes default
[11:09] <Madpilot> it's in the repos, actually. search Synaptic for ubuntu font
[11:09] <livingdaylight> k
[11:10] <Madpilot> found it - ttf-ubuntu-title
[11:10] <livingdaylight> Yea, now we're talking  ;)
[11:11] <livingdaylight> ... it
[11:11] <livingdaylight> was made available by Canonical under the LGPL to make rebranding
[11:11] <livingdaylight> of Ubuntu easier.
[11:11] <livingdaylight> isn't that sweet?
[11:12] <Madpilot> very useful
[11:17] <Madpilot> livingdaylight, don't worry about fonts - just send me the text, I'll do the formatting on this ned
[11:17] <Madpilot> end, even
[11:21] <livingdaylight> and even?
[11:22] <Madpilot> just correcting my misspelling of 'end' on the previous line
[11:22] <livingdaylight> sorry :)
[11:22] <livingdaylight> k
[11:30] <Madpilot> anyway, it's 0230 and I need sleep.
[11:30] <Madpilot> livingdaylight, email me that text when you've got it, we can edit back and forth then I'll fire it into Inkscape.
[11:31] <livingdaylight> ok, Madpilot
[11:31] <Madpilot> night
[11:31] <livingdaylight> nite
[05:55] <Ckenyon> ,
[06:35] <nixternal> Burgwork: you realize there is a UWN team on LP? ;)  first time i just noticed it
[06:37] <Burgwork> nixternal, no, never noticed it
[06:37] <nixternal> https://launchpad.net/people/ubuntu-newsletter
[06:37] <nixternal> heh, it is the originators of the UWN i guess
[06:38] <nixternal> also, have we decided to switch the template on the UWN as well to the one you used originally?  i know it got swapped back here by mistake
[06:38] <nixternal> i want to edit the main template to prevent that from happening again
[06:38] <Burgwork> sure, sounds good
[06:38] <nixternal> k..i will do that here in a few, and fire up the next edition as well while im at it
[06:38] <nixternal> i will start contributing some stuff today
[06:39] <Burgwork> excellent
[10:13] <nixternal> http://www.youtube.com/watch?v=rEgUTkWi-zU
[10:14] <nixternal> that is cool!
[11:19] <nixternal> Burgwork: you know where the Ubuntu California people got their booth setup?  there could possibly be a tradeshow in Chicago in the near future called "Uberfest"
[11:19] <nixternal> it is something the LUGs are currently puting together
[11:19] <Burgwork> nixternal, their stuff came from canonical
[11:19] <Burgwork> they only had one banner
[11:19] <nixternal> i seen the nice lookin' setup they had in the pictures..looked like more than 1 banner...
[11:20] <Burgwork> that was canonicals booth
[11:20] <nixternal> ahhh
[11:20] <Burgwork> the large wall banner?
[11:20] <nixternal> well then, i will strike up conversation with Canonical and let htem know that there is an interest here in Chicago for a FOSS tradeshow, and right now Red Hat and Google have expressed their interest since they are in Chicago
[11:21] <nixternal> i didn't see the california setup..i was referring to the canonical setup
[11:22] <Burgwork> the ca setup was one banner that canonical brought with them
[11:23] <nixternal> who would you recommend i contact at canonical to see if they would even be interested first off?
[11:24] <nixternal> it is easy for us to create banners, as we have a couple of "Printers" on the team
[11:24] <Burgwork> jane
[11:24] <nixternal> kind of thought she would be..cool..thank you sir
[11:25] <Burgwork> in the future, this kind of thing will be jono's
[11:25] <nixternal> ooh good point
[11:25] <nixternal> will keep that in my mind..as this isn't happening for probably another 3 to 6 months
[11:25] <nixternal> im leaning towards the 6 months
[11:28] <Burgwork> nixternal, you tell adam that he is rich and should help finance it
[11:28] <nixternal> heh, he is helping me possibly with a booth already ;)


[01:18] <traderbrew> Hello everyone. Is there anyone in here that uses the raspberry pi with Ubuntu Mate?
[01:30] <traderbrew> Anyone around?


[00:59] <spagewmf> The touchpad My MacBook Air running 12.04 keeps jumping into a hyper-sensitive window move mode. I turned off "Unity MT Grab Handles" in  CompizConfig Settings Manager, but I want to disable three-finger swipe [00:59] <spagewmf>  judging from Google there is *no way* to turn off three-finger swipe [01:01] <spagewmf> https://wiki.ubuntu.com/Multitouch/TouchpadSupport is out-of-date, it mentions Synaptic settings that don't exist in 12.04


[10:33] <om26er> is there a banner that says "Precise Release Party" ???
[10:33] <om26er> could anyone please point me to that ?