[01:28] <igc> morning
[01:55] <poolie> spiv, hi
[01:56] <poolie> igc, spiv, so in looking at the codebrowse stats it's interesting that the tags file is very hot
[01:56] <poolie> we may be accessing it too much over plain http
[01:57] <spiv> Huh, that is interesting.
[01:58] <spiv> Separately, I've noticed the get_tags_bytes RPC sometimes gets called more than is strictly necessary, perhaps due to the same root cause.
[01:59] <poolie> probably
[01:59] <poolie> while i was at the hospital cafe the other day i started adding the test-factory concept
[01:59] <poolie> i might call it test subjects to avoid touching any sore points about lp test factories
[03:15] <luke-jr> jelmer: my bzr-svn problem seems to be rooted in it deciding old-old paths are not branches
[03:15] <luke-jr> is it possible to tell it *tags* are tags and anything else is a branch? :/
[03:17] <mwhudson> luke-jr: you can set up a custom layout in ~/.bazaar/subversion.conf
[03:18] <luke-jr> mwhudson: bzr-svn doesn't like it
[03:18] <luke-jr> branches = armagetronad/trunk/armagetronad;armagetronad/branches/*/armagetronad;armagetron/trunk;armagetron/branches/*;armagetronad/trunk;armagetronad/branches/*;armagetronad/armagetronad/trunk;armagetronad/armagetronad/branches/*
[03:18] <luke-jr> tags = armagetronad/tags/*/armagetronad;armagetron/tags/*;armagetronad/tags/*;armagetronad/armagetronad/tags/*
[03:19] <mwhudson> ah i see you're ahead of me then :-)
[03:34] <lifeless> poolie: so what are you and igc hacking on ?
[03:34] <lifeless> poolie: re test-factories, I wish you could explain better what you mean there.
[03:41] <igc> lifeless: a few things ... poolie is helping me get lp running in a chroot
[03:42] <lifeless> igc: I found a VM was much easier
[03:42] <lifeless> FWIW
[03:42] <igc> lifeless: and we're hoping to clean out the loggerhead merge queue as well
[03:42] <poolie> lifeless: there was a thread from about september last year
[03:42] <poolie> 'rfc testfactory' or something like that
[03:42] <lifeless> poolie: yes, I remember that thread
[03:43] <poolie> basically i was going to get around to doing the consensus position from that
[03:43] <lifeless> ah, I didn't remember a consensus other than 'caring about test quality matters'
[03:43] <poolie> which was to make setup of test data "shorter, standardized and declarative"
[03:43] <poolie> i think that was aaron's description
[03:44] <igc> lifeless: and poolie's explaining hydrazine and the nice work you're doing on improving lp-pqm integration - sounds really promising IMO
[03:45] <lifeless> igc: its fixes some process bugs for us
[03:45] <lifeless> should let us add more committers more easily
[03:45] <lifeless> and makes it easier to migrate to tarmac if/when we do that
[03:46] <igc> lifeless: right. I'd like to leverage all the above to make it easier to land stuff from Explorer
[03:46] <poolie> lifeless: where does the failure message go to?
[03:46] <lifeless> poolie: subunit-filter -> lp merge proposal
[03:47] <lifeless> poolie: bugs filed about getting binary safe attachments on mp's
[03:47] <igc> lifeless: IIUIC, if a user can toggle the status of a MP from inside Explorer via launchpadlib, then your magic will take care of landing the associated branch from there?
[03:47] <poolie> k
[03:47] <poolie> igc, yes, it should
[03:48] <poolie> and it should be trivial to set it
[03:48] <poolie> finding the right mp may be slightly harder
[03:49] <igc> poolie: for a given repository, I'll simply list the MPs for the matching lp project in a panel
[03:49] <igc> with some action buttons next to each one say
[03:51] <lifeless> igc: yes
[03:51] <lifeless> finding the right mp is pretty easy.
[03:51] <lifeless> you can crib from pqm/queue/lp.py - take you ~ 5 minutes
[03:51] <lifeless> listing all the mp's makes sense though, to let them choose the branch
[03:52] <lifeless> igc: one [important] thing is to show the diff, because NEWS in particular will often require a manual fixup before PQM submission, to move entries to the right stanza
[03:53] <igc> lifeless: good point
[03:54] <lifeless> this is a significant sticking point on using MP's to control things
[03:54] <lifeless> we kindof end up having to:
[03:55] <lifeless> make a new branch
[03:55] <lifeless> fixup
[03:55] <lifeless> submit that as an mp
[03:55] <lifeless> self approve as 'fixup for xxx'
[03:55] <lifeless> queue
[03:56] <igc> lifeless: so having an integration branch remains a part of the workflow puzzle
[03:56] <lifeless> igc: when releases happen, or things sit for a while, yes.
[04:13]  * igc lunch
[04:14] <lifeless> spiv: btw your branch is pretty certain to be erroring, its just blowing up in the exception handler handler
[04:14] <lifeless> spiv: I think its fixed [reporting] now - this run should do better
[04:25] <mkanat> mwhudson: Hey hey. Any chance of getting the logs that I wanted?
[04:26] <mwhudson> mkanat: do you have the times to hand?
[04:28] <mkanat> mwhudson: They're in the attachment, I could go find them.
[04:28] <mwhudson> i guess i can too
[04:34] <mwhudson> yay i think the times in the attachment are in NZST
[04:35] <lifeless> rot12 is fun ? :)
[04:38] <mwhudson> ah, actually not
[04:40] <luke-jr> hmm, one-liner patch to svn-bzr likely to get in as a bugfix? :p
[04:42] <luke-jr> lp:~luke-jr/bzr-svn/bzr-svn-longest-branch-path
[04:42] <lifeless> luke-jr: submit that via launchpad ;)
[04:45] <luke-jr> any way to go back and add parent revids to revisions?
[04:45] <luke-jr> I can add revprops on the svn end if needed, I think
[04:50] <lifeless> http://bouillon.math.usu.ru/articles/ctre.pdf
[04:50] <lifeless> ^- rev ctrl geek alert
[04:50] <lifeless> luke-jr: in general, no.
[04:50] <luke-jr> :/
[04:50] <lifeless> you could rebase/rewrite
[04:51] <mwhudson> mkanat: i commented on the bug report
[04:51] <mkanat> mwhudson: Thanks.
[04:52] <mwhudson> mkanat: i hope it's useful
[04:57] <luke-jr> lifeless: I don't want to rebase or write anything
[04:57] <luke-jr> just add missing metadata
[04:57] <lifeless> luke-jr: so bzr revisions are immutable
[05:18] <luke-jr> lifeless: why?
[05:18] <luke-jr> I'm going to have to change all the file-ids sometime too
[05:19] <lifeless> why?
[06:06] <poolie> spiv, thanks for the tribunal mp
[06:06] <poolie> how did it work aside from that?
[06:13] <luke-jr> lifeless: to maintain compatibility with existing branches if possible
[06:14] <lifeless> luke-jr: but existing branches will have the current file ids
[06:15] <lifeless> luke-jr: so I don't follow
[06:18] <luke-jr> lifeless: the existing branches are all based on a bzr-svn screwup
[06:18] <luke-jr> I am trying to recreate our Bazaar HEADs properly
[06:19] <lifeless> ah
[06:19] <luke-jr> so we can actually merge between stable and trunk
[06:19] <luke-jr> and useful things like that
[06:20] <luke-jr> right now, the Bazaar HEADs start revision 1 at the import to Subversion
[06:20] <luke-jr> rather than at the original import into CVS
[06:21] <luke-jr> also, side note: I will need to ensure I can repeat this again later, since Bazaar STILL can't mirror Subversion losslessly at the moment :/
[06:21] <luke-jr> so a third import will be needed when Bazaar *can* losslessly contain the history
[06:22] <spiv> poolie: it's pretty slow when fed a full test run from bzr
[06:22] <spiv> poolie: I haven't got to the point of profiling
[06:24] <spiv> poolie: I've got some other changes in https://code.edge.launchpad.net/~spiv/tribunal/experimental that I'm less certain about, but made it a little nicer for me
[06:24] <poolie> yeah it does seem a bit slow
[06:24] <poolie> or like it gets stuck
[06:24] <spiv> poolie: io_add_watch seems to basically be a wrapper around poll(2) on an fd, and so feeding it a file doesn't really work well because they always report as ready for reading
[06:25] <poolie> for me it works to give it a plain file but not a pipe atm
[06:25] <spiv> poolie: So I ripped that out (although it might be more appropriate for reading from a pipe?), and also used add_idle or something instead of timeout_add(1, ...)
[06:26] <poolie> folding together "neither success nor failure" probably makes sense
[06:26] <spiv> poolie: and borrowed some progress code from subunit2gtk to give more info in the statusbar
[06:26] <poolie> i see
[06:26] <poolie> that looks nice
[06:26] <spiv> Oh, and changed it to filter xfails with skips
[06:27] <poolie> right that's what i meant about folding them together
[06:27] <spiv> And added a separate filter for unknowns (which in my use were just flickering on/off as tests loaded)
[06:27] <poolie> mm
[06:27] <spiv> Although I don't think that's a great change.
[06:27] <poolie> that actually needs to be handled a different way i think
[06:27] <spiv> But it did prove I knew how the ui.glade file worked :)
[06:28] <poolie> i mean if we're really getting unknown test results that's one thing
[06:28]  * luke-jr mutters.
[06:28] <poolie> but the case of a test just being in progress is different
[06:28] <spiv> It's really "incomplete" in this case, rather than "unknown"
[06:28] <spiv> Right.
[06:28] <poolie> you know there is a gui for glade? :)
[06:28] <spiv> I do :)
[06:28] <poolie> i guess i'd be surprised but happy if the input code can be as simple as you have it
[06:28] <spiv> But it seemed quicker & easier to do this change via XML hacking, and I think I was right :)
[06:29] <spiv> I'm not sure that the input code as I have it will cope well with a pipe that hasn't got the full stream ready to read yet.
[06:31] <spiv> One effect of removing the timeout_add calls is that Ctrl-C on the console now works as expected.
[06:50] <lifeless> poolie: in case it wasn't clear, its safe to merge: approve in email/the web ui
[06:50] <lifeless> poolie: pqm looks for merge: queue, not merge: approve
[06:50] <poolie> that's what i understood now, but i think this is not clear to everybody
[06:51] <poolie> or whether that's going to start happening in the future
[06:51] <lifeless> poolie: I'm going to update the merge docs once the glitches are gone
[06:51] <lifeless> poolie: for now I want to keep email as the 'official' way to submit stuff
[06:51] <poolie> ok
[06:51] <poolie> that makes sense
[06:56] <lifeless> poolie: so https://code.edge.launchpad.net/~songofacandy/bzr/fix-523746-dev/+merge/20537
[06:58] <lifeless> poolie: looking at it, I made it in progress because vila had decided to hand the writing of the tests back to INADA; I was following suit but setting the metadata
[07:23] <vila> hi all !
[07:23] <fullermd> Eek!
[07:23]  * fullermd hides.
[07:25] <poolie> hi vila
[07:29] <poolie> lifeless, vila, so basically i think if someone has half a patch and doesn't seem to be getting the tests (or cleanups or whatever) finished
[07:29] <poolie> we should actively help them
[07:29] <poolie> if necessary by writing the tests
[07:30] <lifeless> I think we should only do that after discussing with them unless we particularly want the patch
[07:30] <vila> poolie: sure, I will look at it today (and to brian's append_revisions_only one)
[07:31] <lifeless> poolie: particularly as you seem to mean this to apply to non-staff contributions [or something, I'm unclear what the heuristic you use is]
[07:33] <vila> lifeless: you seem to be patch piloting quite well so far, do you intend to make it official ? :)
[07:33] <lifeless> vila: I'm not patch piloting; if I was I'd be implementing stuff as needed; thats part of the pp definition atm
[07:34] <vila> was worth a try :)
[07:35] <lifeless> vila: I'd be happy to if I wasn't moving house this weekend
[07:36] <vila> lifeless: thanks for the cleanup anyway !
[07:36] <vila> lifeless: tada ! Happy moving !
[07:36] <lifeless> parthm: we could use tempfile.mkstemp to make .bzr.log perhaps
[07:36] <igc> hi vila!
[07:37] <vila> lifeless: I would have help if I wasn't that far :0)
[07:37] <poolie> lifeless: if somebody's done some work on a patch, and it has value, and we think they won't finish it off themselves, we should finish it
[07:38] <poolie> you can get an idea from someone's history of whether they can/will finish it
[07:38] <vila> poolie: fully apply to brian's one, I'm a bit less comfortable with naoki's one but I think it's still a step in the right direction
[07:38] <poolie> fully apply?
[07:39] <lifeless> poolie: I kindof agree, but I think your dials are overly sensitive, or something.
[07:39] <vila> poolie: your comment " it has value"
[07:39] <parthm> lifeless: i thought of that earlier. rename is guaranteed to work on posix but not on windows (IIRC it errors on windows) so the update from martin_gz seemed good to me.
[07:39] <vila> fully applies ?
[07:39] <poolie> i see what you mean
[07:39] <lifeless> parthm: oh, right, we can't specify the full name. Ignore my suggestion :)
[07:40] <poolie> yes, we have a difference of opinion as to what's worth doing
[07:40] <vila> lifeless: Are there updates to your feed-pqm branch ? What is the consensus around it ?
[07:42] <lifeless> poolie: I want to help folk over a hump they can't get over when any of a few conditions are true: they are likely to come back and do more; they are struggling and pointers won't be enough; we would be working on teh patch anyhow
[07:43] <parthm> lifeless: thanks for the review of bug #529930 mp. i have updated the testcase to use user_encoding.
[07:44]  * parthm is new to unicode but dislikes unicode errors
[07:45] <poolie> join the club
[07:48] <lifeless> that was incredibly bad reception - or transmission, can't tell
[07:48] <lifeless> I had 3 bars
[07:48] <poolie> srsly
[07:49] <lifeless> yes, except more like
[07:49] <lifeless> ssy
[07:54] <lifeless> poolie: I'm thinking of either: changing the behaviour of pull --remember when there is a locations.conf, to remove configuration from locations.conf if it would override the --remember, or to have branch.conf win for local branches
[07:54] <lifeless> ditto push --remember
[07:55] <vila> lifeless, poolie : Where are we with https://code.edge.launchpad.net/~lifeless/hydrazine/cron/+merge/23213 ?
[07:55] <poolie> sounds good
[07:55] <lifeless> vila: you can use it to submit things to pqm
[07:55] <vila> lifeless: I now I can, I'd like to know if I *should* :-)
[07:55] <poolie> heh, the last commit on the cron branch is "remove cron mode?"
[07:55] <vila> s/now/know/
[07:56] <lifeless> vila: sure; its merging robustly, but it has issues showing errors
[07:56] <lifeless> vila: debugging is a long winded thing (need a LP instance to talk to yada yada), so its high latency, even though its not high-staff-time
[07:56] <poolie> issues meaning it can't show them at all? :)
[07:56] <lifeless> vila: once the quirks are gone, I'm thinking to put the changes into bzrlib.plugins.launchpad
[07:57] <lifeless> vila: and have hydrazine call into that on a per-branch basis
[07:57] <vila> Is it the 44M mail spiv was referring to ?
[07:57] <lifeless> poolie: some of the time :(
[07:57] <lifeless> vila: no
[07:57] <vila> lifeless: that would be lovely for my use case :)
[07:57] <lifeless> vila: thats subunit
[07:57] <poolie> vila: it gives you something like "IndexError: None"
[07:58] <lifeless> poolie: thats on success ;)
[07:58] <lifeless> poolie: but is, I think, fixed.
[07:58] <poolie> if that's success i'd hate to see failure :)
[07:58] <poolie> :)
[07:58] <lifeless> poolie: indeed. Failure was spmdo tail pqm.log
[07:58] <vila> lifeless: I had failures last week and never got any mail, we tried to diagnose it with Chex, but never concluded, in the end I fixed the problem and sucessfully merged
[07:58] <lifeless> which is very suboptimal
[07:58] <lifeless> vila: that would be the 44M email
[07:59] <vila> lifeless: do you which server is blocking that ?
[07:59] <lifeless> vila: thats fixed, but the fix isn't robust yet; have just had spm rollout a pqm to gather the output and let us analyze for the reason of teh failure
[07:59] <parthm> does it seem reasonable to ignore java class files by default? if so i could try to create a merge proposal for bug #564605
[07:59] <vila> lifeless: ok cool
[07:59] <lifeless> poolie: yes, --cron became obsolete with pqm.queue.lp
[08:00] <poolie> lifeless: so atm i think i should merge that branch but give you a choice of two commands
[08:00] <poolie> 'queue by email' and 'queue in launchpad'
[08:00] <poolie> since you do in fact have these two options now
[08:00] <spm> you should have a third : "queue by sheer awesomeness"
[08:01] <lifeless> poolie: ok, I can reinstate a separate command, but I'm not really game to try and eliminate all the cruft
[08:01] <lifeless> poolie: by which I mean there will be duplicate code
[08:01] <vila> lifeless: mark it as deprecated :-P
[08:01] <vila> lifeless: and spam the users about the alternative
[08:02] <poolie> i'll try
[08:02] <lifeless> vila: no, thats not reasonable when we're still supporting email submission
[08:02] <poolie> two commands in one program seems better than two branches
[08:02] <lifeless> poolie: I know what I changed, I'm happy to do it
[08:02] <lifeless> poolie: it would be nice to have hydrazine look at the conflicts list too
[08:08] <lifeless> what I need is the self user id from launchpadlib
[08:10] <parthm> poolie: does it seem reasonable to ignore java class files by default? if so i could try to create a merge proposal for bug #564605
[08:13] <poolie> lifeless: so in short, in case we don't catch up
[08:13] <poolie> i do want you to adjust that knob upwards
[08:13] <lifeless> poolie: hydrazine 'e' command added and pushed to the cron branch.
[08:14] <poolie> ok thanks
[08:14] <lifeless> poolie: I want to discuss that with you; I'm pretty sure we will not be doing as best we can for the project by doing that
[08:15] <poolie> happy to discuss it but please also just do it for now
[08:16] <vila> lifeless: lifeless missing ':' line 182
[08:17] <lifeless> vila: bah, thanks
[08:17] <poolie> great, thanks
[08:18] <lifeless> vila: pushed
[08:20] <vila> lifeless: pulled
[08:55] <lifeless> jelmer: what should format.open(name='xxx') raise on a non-supporting colocated-things format ?
[09:17] <speakman> morning folks
[09:18] <james_w> lifeless: how did this bzr-builddeb change work???
[09:19] <james_w> I even think we've discussed this change before
[09:42] <lifeless> james_w: does it not work for you ?
[09:43] <lifeless> james_w: oh right, global scope commands. bah
[09:44] <lifeless> clearly I have '' in my path inappropriately
[09:57] <jelmer> lifeless: NoColocatedBranchSupport
[10:26] <lifeless> jelmer: and name!=None is thr right condition ?
[10:27] <lifeless> well, is not
[10:29] <MvG> lifeless: wrt bug #560030, what exactly are you proposing? Should we get all major distros to provide a bzr-bash-completion package before we drop stuff from the bzr main tree?
[10:30] <lifeless> MvG: debian and redhat certainly
[10:30] <jelmer> lifeless: yeah
[10:30] <lifeless> MvG: not necessarily wait for them to be done, but have the maintainer ack and be prepared
[10:31] <MvG> lifeless: Do you want to contact them? If I do, it might seem like I'd simply trying to maneuver for a larger audience for my plugin. If you say that's the future, they are more likely to take it serious.
[10:32] <lifeless> MvG: the bug and review feedback are pretty clear
[10:32] <lifeless> MvG: I think they will take you seriously ;)
[10:32] <MvG> OK, got a point there.
[10:35] <lifeless> I'd just say something like
[10:36] <lifeless> 'hi, this is a heads up, we're about to merge a branch deleting xxx, there are replacement, better, scripts at yyyy, we wanted to make sure that this is known now, rather than at the last minute'
[10:36] <MvG> Do you have contact addresses for maintainers of the RedHat package?
[10:36] <lifeless> he hangs out here :P
[10:36] <lifeless> don't remember the name offhand
[10:37] <james_w> abadger1999 will at least know who it is if it is no longer him
[10:39] <spiv> Ooh, I think my shiny new news_merge logic is working.  The prototype doesn't blow up in manual testing at least...
[10:39] <MvG> jelmer: How about Debian? Should I write to<EMAIL_ADDRESS>or is it enough that you read the above?
[10:39] <lifeless> spiv: cool
[10:39] <lifeless> spiv: hey
[10:39] <lifeless> spiv: I have a further Commands cleanup issue
[10:39] <spiv> Time to write some proper automated tests for it, but right now it's dinner time :)
[10:39] <lifeless> spiv: subclasses  - super().
[10:39] <lifeless> spiv: food for thought.
[10:39] <spiv> Super-duper.
[10:40] <speakman> I've got yet another workflow question comming. Hold on. :-)
[10:40] <spiv> lifeless: I guess the current answer is "don't upcall"?
[10:40] <lifeless> spiv: Not entirely sausagefestfactory
[10:41] <MvG> By the way, I've got another merge request for which I'd like comments here: https://code.launchpad.net/~gagern/bzr/bug387117/+merge/23750 about ListOption(..., param_name=...) which is currently broken.
[10:41] <spiv> Anyway, food time.
[10:42] <spiv> lifeless: btw, the better-news-merge branch, while still rather messy, can read a template file from a configurable location (rather than using the hard-coded list).
[10:42] <lifeless> spiv: sounds nice
[10:42] <spiv> lifeless: as well as having a more capable parser
[10:43] <speakman> Me and my coworker are about to make a facelift to one of our application. The current stable version is in trunk, and we suppose all facelift work should be done in a separate branch of trunk. But how do we work together on this branch in best practice? Beside our own workstations we also have a bzr smart server set up on a dedicated server machine. Any recommendation how to proceed?
[10:44] <lifeless> speakman: just do it ?
[10:44] <MvG> speakman: I'd say create a branch off trunk on the smart server, and let contributors decide whether they want to check it out or branch from it.
[10:46] <jelmer> MvG: Sorry, I think I missed the context :-)
[10:46] <speakman> We're only two working on this, but we will be working with overlapping things i guess.
[10:47] <MvG> speakman: In terms of http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/bazaar_workflows.html you two either use the centralized approach (with or without local commits) or the decentralized with shared mainline. In both cases, mainline would be the facelift branch, not trunk.
[10:47] <MvG> jelmer: Bug #560030 plans dropping bash completion scripts, and lifeless wants distros made aware of this upcoming change up front.
[10:48] <speakman> So the preffered workflow in this scenarios is the centralized (SVN) type?
[10:48] <jelmer> lifeless: still around?
[10:49] <lifeless> very
[10:50] <MvG> speakman: Depends on your personal preference. In particular whether you want to resolve possible merge conflicts and share your changes at almost every commit, or whether you'd rather keep your stuff to yourself until you decide it's ready for sharing.
[10:52] <MvG> jelmer: So I'd still like to know whether the people maintaining bzr for debian are now sufficiently aware of the fact that bash completions are about to go, and that there is my bzr-bash-completion plugin as suggested and superior solution. If not, I'd write a mail about it.
[10:52] <speakman> I don't actually have any preference, and every time I just choose one workflow, I always hit issues one way or another :)
[10:53] <speakman> That's why I'm asking the pro's before starting the facelift project :)
[10:53] <lifeless> speakman: don't don't choose one workflow - use many :)
[10:53] <lifeless> speakman: seriously, different strokes for different issues
[10:53] <lifeless> speakman: clearly you want a facelift branch; make one, work on it.
[10:54] <MvG> speakman: In that case I assume that your edits overlap in a way that is bound to cause extra work unless you strictly serialize them. Might be an indication of bad code design or bad task assignments.
[10:54] <speakman> Earlier I think I've seen something where each user had their own branches on the smart server, like /srv/bzr/ourproject/mybranch and /srv/bzr/ourproject/coworkerbranch
[10:54] <lifeless> If you are getting lots of big conflicts, merge more often with each other (the ultimate example of that is per-commti)
[10:54] <speakman> lifeless: but we will be two working on the same "feature" :-/
[10:54] <lifeless> speakman: so ? I don't see why you feel that make a difference
[10:54] <MvG> lifeless: "don't choose one workflow" might apply to bzr usage in general, but for working on one specific task I'd prefer not to change workflow too often... :-P
[10:55] <speakman> MvG: You're hitting the spot; it's *very* bad code design, but the facelife project is the last resort for that codebase though :)
[10:56] <speakman> lifeless: but if we're supposed to merge often - then the checkout/centralized workflow is pretty much it?
[10:56] <MvG> speakman: If edits overlap so often, then as lifeless points out, you might want to merge for almost every commit, in which case the centralized svn-stype approach would indeed be best.
[10:56] <lifeless> speakman: the more often you merge, the smaller conflicts are; dial-up the number of merges you do to match the work you're doing.
[10:57] <speakman> I think the centralized workflow will be it then. Thanks :-)
[10:57] <speakman> And then - how "often" should one commit? Are there any rules of thumb?
[10:58] <lifeless> speakman: often
[10:58] <mathrick> speakman: merging doesn't necessarily imply a centralised workflow
[10:58] <mathrick> you can just cross-merge from each other's branch
[10:59] <lifeless> speakman: ifyou're using centralised to avoid conflicts, you want to be committing a lot, otherwise you're no different than just merging every now and then
[10:59] <mathrick> speakman: how many people will *not* be working on the facelift?
[10:59] <speakman> lifeless: ok, thanks alot!
[10:59] <speakman> mathrick: not working? :-)
[10:59] <lifeless> by a lot, I mean multiple times an hour
[10:59] <mathrick> yeah, how many developers are there who don't participate in the facelift?
[10:59] <speakman> mathrick: we're just two programmers, and both will be working on the facelift :)
[10:59] <mathrick> oh
[11:00] <mathrick> speakman: then you just do bzr branch stable facelift; bzr branch facelift facelift-speakman; bzr branch facelift facelift-coworker
[11:01] <jelmer> MvG, lifeless: I'm not exactly sure what's expected of me here
[11:01] <mathrick> and then facelift becomes your integration branch, with stable still being there in case you need it
[11:01] <jelmer> MvG, lifeless: Does removing this completion script cause shell completion to break for existing users?
[11:01] <lifeless> jelmer: a decision about what to do in debian when bzr drops its included completion scripts; ideally package up the rplacement.
[11:01] <lifeless> jelmer: it depends, how do we deploy them at the moment?
[11:02] <lifeless> like, do users have it on by default, or do they source it, or copy it, or ...
[11:02] <mathrick> lifeless: wouldn't making their personal branches bound to the main facelift branch be best for merging here? This way they'll always be sure to have a single codebase
[11:02] <MvG> bzr deploys them in contrib, debian places them in /etc/bash_completion.d/ , from there on I'm less than sure.
[11:03] <MvG> But I'd assume there is some kind of framework for selecting thise completion scripts you want to enable on a per-user basis.
[11:03] <lifeless> mathrick: doesn't really make any difference; regular merges are regular merges
[11:03] <mathrick> yeah, I mean just for code hygiene and not forgetting to push
[11:03] <lifeless> mathrick: whatever works for the individuals involved
[11:03] <lifeless> mathrick: I don't think there is a gold standard 'best' here
[11:03] <mathrick> lifeless: the decision about completions is usually global, you either enable it and then get all installed completions, or not and then you don't.
[11:03] <lifeless> jelmer: ^
[11:04] <mathrick> lifeless: fair enough
[11:04] <MvG> In that case I wonder why Debian installs BOTH bash completion scripts, bzr and bzr.simple... :-/
[11:04] <lifeless> jelmer: ideally we'd have replacement packaged and recommended: on by the bzr package
[11:04] <MvG> I don't have a Debian/Ubuntu at my fingertips just now, otherwise I'd investigate this more thoroughly.
[11:05] <mathrick> speakman: anyway, you can make your personal branches checkouts, this way every commit you do locally will be instantly mirrored on the integration branch. And ideally, you want to sit next to each other and inform clearly what you are about to commit and what you'll be working on next
[11:11] <speakman> mathrick: that's pretty much how it works practically. We're sitting next to each other, and due to the (lack of) code design we really need to work tight on this.
[11:12] <mathrick> right
[11:12] <speakman> final conclusion; bzr branch bzr://smartserver/ourproject/trunk bzr://smartserver/ourproject/facelift, and then "bzr checkout bzr://smartserver/ourproject/facelift" on each of our workstations.
[11:13] <speakman> Then go buy intercom :)
[11:13] <jelmer> MvG, lifeless: ok, thanks
[11:13] <mathrick> speakman: yup; you might also consider tagging the starting point of the facelift
[11:13] <jelmer> MvG, lifeless: I'll file a RFP when I do the next upload
[11:13] <MvG> jelmer: Please expand RFP.
[11:14] <lifeless> request for package
[11:14] <MvG> Thx.
[11:15] <MvG> Debian done, Ubuntu by inheritance hopefully done as well. RedHat maintainer still unknown. I haven't even found a redHat package database online, only one for Fedora. https://admin.fedoraproject.org/pkgdb/acls/name/bzr lists 3 users with commit privileges, one of them the owner.
[11:16] <jelmer> MvG: abadger1999 is (one of?) the Fedora maintainer
[11:16] <mathrick> MvG: I thought RH doesn't have a non-fedora package list anymore, given how RH is basically fedora + support + very long release cycle
[11:19] <lifeless> MvG: redhat is fedora as far as we're concerned
[11:21] <MvG> So we'll wait for abadger1999 to react.
[11:22] <MvG> In the meantime I'll go for lunch.
[11:29] <speakman> mathrick: hm... I don't get it - why tagging when working in a branch..?
[11:30] <mathrick> speakman: to have an easy reference to the starting point
[11:30] <mathrick> speakman: otherwise you'll have to remember the first revision you branched from
[11:31] <speakman> oh yes, you're absolutely right! thanks!
[11:32] <lifeless> mathrick: I don't get the tag either
[11:32] <lifeless> mathrick: whats it for ?
[11:32] <speakman> Hm looking at the commit history my coworker seems to have commited with wrong email address (login@machine). Is there any way to change that retrospectively?
[11:32] <mathrick> lifeless: seeing the full extent of what you've done for example
[11:32] <mathrick> speakman: no
[11:32] <speakman> ok :(
[11:32] <mathrick> other than fast-replay
[11:33] <mathrick> err, fast-import
[11:33] <mathrick> but it'll be a different repository then
[11:33] <lifeless> or rewrite (in principle)
[11:33] <speakman> ok, it's okey as is :)
[11:34] <speakman> about tagging; when working explicitly in the facelift branch you can easily see which commit was the first in the new feature branch. I guess?
[11:34] <mathrick> lifeless: in general I find having a clear idea of where I started useful. And if the trunk moves in the meantime (because of a critical bugfix say), you won't have any easy way to say "where I started"
[11:34] <lifeless> mathrick: well, bzr knows
[11:34] <mathrick> speakman: depends, how do you define "first in the feature branch"? Revisions don't belong to any branch, branches contain them
[11:34] <mathrick> lifeless: howso?
[11:34] <lifeless> mathrick: revisions in your branch not in trunk
[11:35] <mathrick> unless you backport / merge
[11:35] <speakman> About trunk changing - is "merging" considered default about "rebase" in bzr?
[11:35] <lifeless> mathrick: the topologically oldest of them, has a single parent, the starting point.
[11:35] <speakman> about/above
[11:35] <mathrick> lifeless: and how do you say that?
[11:36] <lifeless> mathrick: bzr missing --mine-only etc, I'm not sure there is a query for that rev at the moment
[11:39] <mathrick> lifeless: but that's potentially a moving target. Tags by definition aren't
[11:40] <mathrick> and they're easy to spell as revspecs too
[11:40] <lifeless> mathrick: sure, if you're happy great. I've just never ever needed it ;P
[11:41] <speakman> We all learn something each day :)
[11:56] <speakman> Each time I need to reach my smart server I have to type "bzr://servername.local/project/trunk" -- is there an easy way to make a alias, like "ss:project/trunk" (like launchpad "lp:") ?
[11:58] <lifeless> speakman: instal bzr-bookmarks
[11:59] <lifeless> vila: ping
[11:59] <lifeless> vila: do you remember, does WeaveMerger write BASE files now ?
[12:08] <lifeless> it does
[12:30] <vila> lifeless: sorry, had lunch
[12:30] <lifeless> vila: tsk, eating now. What next? Breathing?
[12:30] <vila> or sleeping :)
[12:47] <speakman> I currently did a merge from trunk into a feature branch. Now "bzr missing" tells me that the merge commit is missing in trunk. How will this show in history when the feature branch is finally merged into trunk?
[12:49] <lifeless> speakman: have a look at the bzr trunk log
[13:09] <speakman> lifeless: bzr trunk log..? the log of my trunk branch?
[13:10] <bialix> no, lp:bzr
[13:14] <millun> hi
[13:15] <millun> i am a noob. working on a project (colocated branch) and would like to create a copy of this project so i could have 2 repos and be working on both
[13:16] <speakman> lifeless: changeset 5153?
[13:18] <millun> i guess i could 'cp -R stuff' and then delete .bzr dir?
[13:19] <speakman> why not branch and work on both?
[13:19] <speakman> what more specifically are you trying to do?
[13:19] <MvG1> abadger1999: ping?
[13:20] <millun> speakman: just be able to separate 2 projects and then work on both without mixing anything
[13:21] <MvG> millun: Just because branches were made from a common ancestor doesn't mean you'll HAVE to mix anything in the future.
[13:21] <MvG> millun: And doing a branch now will preserve full history for both new projects, which should be a good thing to have
[13:22] <millun> ok
[14:36] <abadger1999> MvG: pong
[14:45] <MvG> abadger1999: you're maintaining the bzr package for Fedora, right?
[14:46] <abadger1999> abadger1999 == toshio in the Fedora pkgdb btw
[14:46] <abadger1999> MvG: I am comainaining it -- hno handles the day-to-day these days.
[14:46] <abadger1999> MvG: What's up?
[14:46] <MvG> abadger1999: In response to bug #560030 we're gonna drop the bash completion script, and suggest the bzr-bash-completion plugin as replacement.
[14:47] <MvG> So we'd like distros to provide a package for it, be ready for the time when the scripts disappear from the bzr source releases.
[14:47] <abadger1999> MvG: Okay.  No chance of getting that plugin into core?
[14:47] <MvG> Not up to me, I'm only developing the plugin and offering the off fix for inclusion.
[14:48] <MvG> I'd be happy to see it in core, but lifeless didn't exactly jump to that offer.
[14:48] <MvG> And I can think of a million places where bzr would be required but bash completion not, so it might make sense to keep things distinct.
[14:49] <abadger1999> Hmm... bzr-bash-completion doesn't need bash completion installed, though?  It just generates the script that would be used by bash completion?
[14:50] <MvG> abadger1999: Correct. but it does ship a lazy.sh that can be installed as bash completion script and generates the full completion function upon first invocation.
[14:50] <MvG> So that's file is what I'd suggest as a replacement, in cases where the plugin is installed.
[14:52] <abadger1999> Ah.  Okay, we'd drop that into place without making a hard requirement on bash-completion so it wouldn't matter if it was in bzr core.
[14:53] <MvG> abadger1999: I was a bit imprecise: the script assumes that the plugin is installed. It is intended for cases where the plugin is installed, but doesn't check if that actually is the case, but will fail noisily if it isn't.
[14:54] <abadger1999> MvG: <nod>  I'm talking -- if it was in Core, bzr still wouldn't need to suck in a bash completion package.
[14:55] <abadger1999> MvG: A few years ago poolie wasa interested in getting more plugins into core.
[14:55] <MvG> Agreed. So suggestion would be for bzr to suggest but not require bzr-bash-completion, and for bzr-bash-completion to suggest but not require bash-completion, and for bzr-bash-completion to install lazy.sh under a file name that was provided by bzr so far.
[14:56] <abadger1999> I ask this because there's only two of us packagers who are interested in bzr in Fedora... so additional packages kinda suck.
[14:56] <abadger1999> Which is why we don't have bisect, pipelines, or a lot of other bzr plugins packaged :-(
[14:57] <MvG> abadger1999: I understand, but my package shouldn't be too complicated: simple distutils from proper release tarball, and the lazy.sh file installed via custom install command copied from the bzr package spec.
[14:57] <MvG> And if there is anything I can do to make life easier for you downstream, let me know.
[14:59] <MvG> abadger1999: BTW, is hno occasionally here on irc as well, and if so, using what nick?
[14:59] <abadger1999> MvG: <nod>  Yeah... but maintaining packages is the problem... The front end load is fairly simple, when free time > 0: create new package from template, submit for review, have bzr comaintainer review, commit to package SCM, build and release.
[15:01] <abadger1999> MvG: The maintainance is the problem: When New upstream release || new Fedora release || bug reported: stop other work to work on issue (minimal for updating package, much more for fixing bugs); submit patches upstream, build new packages, push to all relevant Fedora branches.
[15:01] <abadger1999> MvG: his nick is hno, so he's easy to spot
[15:02] <abadger1999> MvG: He's almost always on #fedora-devel if you need him.
[15:03] <MvG> abadger1999: bzr-bash-completion should in no scenario be mission-critical, so nothing should be urgent. For the "bug reported" case, I'd suggest reporting upstream first, waiting some amount of time for me to come up with a fix and release it (the benefit of independent package is that I can have short and independent release cycles), then simply bump the fedora package.
[15:03] <abadger1999> MvG: Hehe -- true.  I like to be an active packager that helps out, rather than just a packager that demands fixes, though :-)
[15:04] <MvG> I guess I'll include a comment in the bug report, stating that you are now aware of the situation, but not entirely happy with it, and see if that makes core devs reconsider the core inclusion.
[15:04] <MvG> abadger1999: And I'd welcome you to be, but I'd rather have a packager demanding fixes than no packager at all due to lack of time. :-)
[15:05] <abadger1999> yeah -- Just mention that getting more plugins into core will make bzr look better when people are comparing the features that bzr vs $OTHER_SCM has within a distro.
[15:05] <abadger1999> MvG: :-)  Thanks!
[15:06] <abadger1999> I'll try to get hno to package/maintain this as I use zsh rather than bash (or maybe I'll take a look at your plugin and try adding a zsh output as well).
[15:07] <MvG> abadger1999: zsh does ship a completion script for bzr. It's prety outdated as well, but not as much as the one in the bzr source tree.
[15:07] <MvG> I've had a look at it as well, and wondered whether augmenting my script might be feasible.

[15:08] <abadger1999> The thing I miss most in the zsh script is no support for plugins -- a lot of commands from bzrtools don't have completions.
[15:08] <MvG> For lists of options it should be easy. For registry option values it should be feasible. For help strings it might at times become difficult. For arbitrary argument type completions there isn't enough information in the bzr classes to provide completions the way the hardcoded zsh script currently does.
[15:09] <MvG> In other words: all versions of bash completion currently complete option names and registry values, but leave everything else to standard file name completion. All versions of zsh completion try to be clever and complete much more, like revision numbers, versioned and unversioned files, and so on. The latter is diffiocult to do generically.
[15:10] <MvG> And expensive in terms of performance as well.
[15:10] <abadger1999> Okay.  That summary gives me a head start on what work would need doing, at least.
[15:11] <MvG> So if I were using zsh, I'd drop most of the zsh cleverness, and instead have it do what the bash script does, except for perhaps a few more help messages. But I'd need a regular zsh user to work with me on that.

[15:13] <abadger1999> MvG: Could you link to your plugin in the bug?  it'll make it easier for people to tell what they need to be packaging.
[15:15] <MvG> Will do. For you it's here: https://launchpad.net/bzr-bash-completion and http://pypi.python.org/pypi/bzr-bash-completion
[15:16] <abadger1999> Thanks!
[15:37] <MvG> abadger1999: In case you really wanna tweak the bzr-bash-completion plugin towards zsh, have a look at http://zsh.git.sourceforge.net/git/gitweb.cgi?p=zsh/zsh;a=history;f=Completion/Unix/Command/_bzr or your local installed copy of it. The format doesn't look too complicated.
[15:37] <MvG> abadger1999: I've just commented on bug #560030; maybe you and/or hno want to subscribe, so you stay in the loop.
[15:38] <abadger1999> MvG: Yeah -- hno hasn't responded to me yet -- waiting to see if he'll take the package.
[15:54] <millun> can i set "/home/millun/work/bzr" as my default push directory for more projects?
[16:00] <millun> oops. i obviously can't :)
[16:04] <MvG> millun: It should be possible, though I'm not sure it would make a lot of sense, as you'd have diverging branches preventing pushes for all projects except one.
[16:41] <vila> I need help from a losa
[16:42] <vila> lifeless: A funny one for you: pqm is looping...
[16:43] <vila> lifeless: I submitted with feed-pqm, got a failure (reported on lp, not by mail) but nothing to give me a clue about why
[16:43] <vila> lifeless: so I submitted by mail
[16:43] <vila> lifeless: no it appears that pqm is still failing but it keeps trying to process the same submission...
[16:44] <Chex> vila: hi there, what do you need help with?
[16:44] <vila> Chex: as explained above, it seems pqm is looping on the same submission and doesn't give me *any* hint about what is failing
[16:45] <vila> Chex: AIUI lifeless and spm have been working on pqm since last week, so be aware that things may have changed there
[16:46] <Chex> vila: ok, let me check the logs for you
[16:46] <vila> Chex: the urgency here is to kill this submission so that the other ones can be processed
[16:46] <Chex> vila: ah ok, thats easy, hang on
[17:02] <Chex> vila: ok, I have cleared out your submission, and cleared the pqm-bzr procs, should restart now on a new submission
[17:03] <vila> Chex: any hint of *what* was failing ?
[17:04] <vila> Chex: http://pqm.bazaar-vcs.org/ says 503
[17:05] <Chex> vila: sorry, try now
[17:06] <vila> Chex: ok, it now says 0 scripts
[17:06] <vila> Chex: any hint about why my submission failed ?
[17:07] <vila> Chex: I briefly saw a summary saying 1 error but no details
[17:08] <Chex> vila: right,  that is what I am seeing in the pqm.log file, too.. let me pastebin for you
[17:10] <Chex> vila: https://pastebin.canonical.com/30964/
[17:11] <vila> Chex: and nothing after that ? There is not even an error mentioned there :-/
[17:11] <Chex> I know.. nothing
[17:11] <Chex> vila: I think we may want to try to turn on more logging, if possible to see whats going on
[17:12] <Chex> vila: but I am not sure how to go about doing that
[17:12] <vila> Chex: Isn't there a log file for each submission ?
[17:13] <vila> Chex: at least the other submissions are being processed right now...
[17:14] <Chex> vila: yes there are indiv. log files, but they dont seem to get created until the job is finished..
[17:14] <Chex> vila: and for some reason, your patches aren't.
[17:14] <vila> Chex: AIUI, my submission has been run 3 times, you killed the last one
[17:15] <vila> Chex: ooooh, if it's only mine, then .. fine, I'll  talk with pqm :)
[17:15] <Chex> vila: talk with.. pqm? you guys have a special friendship?
[17:16] <vila> Chex: joke aside, the first submission was from the lp queue while the second (and the others) came from a direct mail
[17:16] <Chex> vila: aha, ok, I see.
[17:16] <lfaraone> Can I get a remote branch's history without branching it?
[17:16] <vila> come to think of it, I wonder if the mail one didn't trigger *3* (and not 2) runs
[17:17] <vila> lfaraone: branching *is* getting the remote history
[17:17] <lfaraone> vila: sorry, I just want the log.
[17:17] <vila> Chex: doesn't the log mention several submissions for this patch ?
[17:18] <vila> lfaraone: bzr log should accept remote urls
[17:18] <vila> lfaraone: 'bzr log lp:bzr' works
[17:19] <lfaraone> vila: okay. that will work without using SSH, right?
[17:20] <vila> lfaraone: it depends on what protocol you're using to access the branch... http ?
[17:20] <MvG1> lp uses ssh if it knows a login name, http otherwise.
[17:21] <lfaraone> looks like it works with http too, I just su'd to nobody, and it worked.
[17:23] <lfaraone> looks like it works with http too, I just su'd to nobody, and it worked.
[17:32] <lfaraone> If I have a lp: URI, how should I pass that to bzrlibb.branch.Branch in the way it expects it? ("a = bzrlib.branch.Branch('lp:ubuntu/lucid/gnome-do')" gives me an error()
[17:35] <vila> lfaraone: use Branch.open_containing()
[17:35] <vila> lfaraone: as a general rule: looking into bzrlib.builtins.py will give you many hints
[17:39] <donri> How can I add to the last commit?
[17:43] <maxb> donri: By 'bzr uncommit'ing and then committing your modified commit
[17:43] <donri> uncommit wont touch my non-committed changes since the last commit?
[17:45] <maxb> correct
[17:46] <donri> Thanks.
[18:18] <Boingo> Hello all.  I have done a bit of searching, but not a lot of finding.  I am having some very slow commits over FTP.  Even a single character change in a single file, with a fresh commit to a remote repo over FTP can take 30+ minutes.  Is there something I am doing wrong?
[18:21] <jam> Boingo: using FTP
[18:21] <jam> especially if your server doesn't support APPE (append to an existing file)
[18:22] <Boingo> My only real option is FTP in this case.
[18:22] <Boingo> I think.
[18:22] <Boingo> godaddy hosting.
[18:25] <Boingo> Why does editing even a simple small file take that long though?
[18:25] <dash> Boingo: one reason is that bzr uses compressed files to store version history, so updating via ftp can involve replacing an entire file
[18:26] <dash> Boingo: which can be a good bit bigger than the one you edited
[18:26] <Boingo> Oh.
[18:26] <Boingo> That makes sense.
[18:26] <Boingo> Is there anything I can do then?
[18:27] <dash> the easy thing to do is use some other host for your bzr repo, like launchpad or sourceforge or something :)
[18:27] <Boingo> I need something that is private.
[18:27] <Boingo> Can lp do that?
[18:27] <Boingo> Would sftp or ssh speed it up?
[18:27] <jpds> Boingo: Yes, Launchpad offers commerical subscriptions.
[18:29] <jpds> Boingo: https://launchpad.net/+tour/join-launchpad#commercial - not sure if it's what you want though.
[18:29] <Boingo> I am reasonably happy with what we have, minus the abysmal speed for commits.
[18:32] <Boingo> Will sftp or ssh speed it up?
[18:32] <dash> sftp might, ssh definitely will, if bzr is installed on the remote server
[18:33] <Boingo> It would not be.
[18:33] <Boingo> Well, at least not in the current context.
[18:33] <dash> well if you can ssh there you can install it
[22:13] <lifeless> vila: to stop it looping, you just unqueue it from launchpad
[22:14] <lifeless> vila: go to the merge proposal, click on the edit icon beside 'queued' and change to 'approved'


[02:31] <mhall119> paultag: done
[02:31] <paultag> mhall119: ♥
[13:46] <s-fox> Hi :)
[13:50] <paultag> hi, s-fox :)
[13:50] <s-fox> Hey paultag :) how's you?
[13:50] <paultag> s-fox: well, thanks, just getting the booze out
[13:50] <paultag> s-fox: I'm officially a debian developer :)
[13:50] <s-fox> paultag,  i've entered the ubuntu app competition!
[13:50] <paultag> wooot!
[13:50] <s-fox> Nice!
[13:51] <s-fox> paultag,  http://serial-coder.co.uk/blog/my-shortcuts/
[13:51] <paultag> whatcha doin?
[13:51] <s-fox> ^ project is DONE :D
[13:51] <paultag> cool :)
[13:51] <s-fox> i've had to learn loads of "new stuff"
[13:51] <paultag> totally!
[13:51] <paultag> what's it written in?
[13:51] <s-fox> yep
[13:51] <paultag> gtk / python?
[13:51] <s-fox> gtk / python
[13:52] <paultag> legit
[13:52] <paultag> all sorts of legit :)
[13:52] <s-fox> i had to learn more python, how to build a  ui, signals, ppa's,  pgp keys and getting stuff into the software center.
[13:52] <paultag> mmmm!
[13:52]  * s-fox has had massive headache of stuff to learn
[13:55] <s-fox> oh and packaging
[13:55] <s-fox> what is legit paultag ?
[13:55] <paultag> s-fox: like the word, or what I was saying it about?
[13:55] <s-fox> i said gtk / python
[13:55] <s-fox> and then you went "legit"
[13:55] <paultag> yep :)
[13:56] <paultag> legit is american slang for "cool" or "great" (besides legitimate)
[13:56] <s-fox> um, i used glade to build the UI if that might make it less legit
[13:56] <s-fox> lol
[13:56] <paultag> that's fine :)
[13:56] <s-fox> oh and i gimped up all my pics (i'm more of a photoshop person)
[13:57] <paultag> :D
[13:57] <s-fox> so yes, lot's of new stuff (for me) going on.
[13:57] <paultag> totally :)
[13:58] <s-fox> this is where someone with more than 5 days experience kicks my butt in the competition. lol
[14:00] <s-fox> so what you doing with debian paultag?
[14:05] <s-fox> wb paultag :)
[14:05] <s-fox> what you doing with debian anyway?
[14:05]  * s-fox is a fan
[14:06] <paultag> s-fox: ty :)
[14:06] <paultag> s-fox: Oh, lotsa stuff.
[14:06] <paultag> Mostly package work there
[14:07] <s-fox> cool
[15:10] <s-fox> Hi toddy  :)
[15:36] <toddy> hi s-fox
[15:47] <paultag> cjohnston: thanks for that http://chrisjohnston.org/tech/my-favorite-irssi-scripts, I jacked some of those
[15:47] <paultag> came up on the GOOG
[15:48] <cjohnston> ;-)
[15:48] <cjohnston> do you have any that arent on there that you like?
[15:48] <s-fox> hi cjohnston  :)
[15:48] <paultag> cjohnston: I use fnotify
[15:49] <paultag> cjohnston: and some local scripts to glob up and show libnotify bubbles when I get punged
[15:49] <cjohnston> hey s-fox
[15:49] <cjohnston> i want notify bubbles, but mine runs on a remote server so i have never been able to make it work
[15:49] <paultag> mine does too
[15:49] <cjohnston> ooo.. then you will have to teach me :-)
[15:49] <paultag> sec
[15:50] <paultag> cjohnston: https://github.com/paultag/dot-bin/blob/master/irc-uplink
[15:50] <paultag> cjohnston: https://github.com/paultag/dot-bin/blob/master/notifyd
[15:50] <paultag> using fnotify, it tails the log over ssh
[15:50] <cjohnston> i use a script that gives me notifications on my phone.. thats pretty col
[16:15] <nhandler> cjohnston: I've still been trying to find a nice way to replace prowl for my android
[16:15] <nhandler> I also had my irssi notify script reading certain notifications using festival for a period of time
[16:16] <cjohnston> nhandler: nma
[16:16] <cjohnston> notify my android
[16:16] <cjohnston> its awesome
[16:16] <cjohnston> i had to change some of my irssi notify script
[16:16] <cjohnston> but it works
[16:18] <nhandler> cjohnston: Alright, I wasn't positive if it would work the same way, and I didn't want to pay until I was sure. I might have to look into it
[16:18] <cjohnston> nhandler: it works close enough.. like I said, I did have to change some stuff, but it works for me
[16:19] <nhandler> I'll have to look into it some more cjohnston. Thanks
[16:19] <cjohnston> np.. if you want my notify script, just let me know
[16:19] <cjohnston> I tried switching to weechat a few months ago, just couldnt do it.. i  like the fact that its more activly maintained than irssi tho
[17:33] <cjohnston> paultag: so you just have the ircuplink on a cron or something?
[17:33] <paultag> cjohnston: Nah, that uses tail -f :)
[17:33] <cjohnston> ok, so its a constant conenction
[17:33] <paultag> cjohnston: it'll keep it open. It'll get killed after a while, I use the `irc' script in my dot-bin
[17:33] <paultag> yeah
[17:33] <paultag> let me get you the script
[17:33] <cjohnston> i see it
[17:33] <paultag> great :)
[17:33] <paultag> so I connect via `irc'
[17:35] <cjohnston> paultag has too much foo
[17:35] <paultag> cjohnston: UNIX Power Tools
[17:35] <paultag> cjohnston: if you read that, you won't ever have to fight your computer ever again
[17:35] <paultag> seriously
[17:36] <cjohnston> I'm just sayin cause you have 4 scripts with their messsssage as foo
[17:36] <paultag> ah
[17:37] <paultag> well, blame THD for that
[17:38] <cjohnston> if i dont use empathy for anything will it still work
[17:40] <paultag> oh it just uses it's icon
[17:40] <paultag> wanted a chat-ey icon
[17:40] <cjohnston> ok
[19:15] <bkerensa> UPS and U.S. Customs are a joke ;p
[19:40] <jussi> Some people here might be interested to know we just opened #ubuntu-discuss - from the channel topic: "Welcome to #ubuntu-discuss. This is a channel for high quality on-topic non-support discussions about Ubuntu."
[20:40] <popey> mhall119, http://mhall119.com/2012/06/my-app-developer-showdown-entry/ is excellent
[20:40] <AlanBell> yeah, I like that a lot
[20:41] <popey> now, make an app that writes all the code too
[20:43] <cjohnston> imbrandon: what happened to your posts about saving omg?
[20:43] <imbrandon> what do you mean ?
[20:44] <cjohnston> didnt you have posts on your blog about your configs and stuff?
[20:44] <imbrandon> oh where did they go ? they are still there, one is published, but when i moved hosts i did not import them all aghain
[20:44] <imbrandon> i can tho if you are looking for some of those configs
[20:44] <imbrandon> wouldent take me long, just been lazy :)
[20:45] <cjohnston> I'm switching to nginx this weekend. so just tryin to get things as good as I can without being a rockstar
[20:45] <imbrandon> give me about an hour to wrap up what i got going and it will take aanother 30 min past that to shove em back into WP, so if you dont see them in about 2 hours then poke me and make sure i dident flake out
[20:45] <imbrandon> :)
[20:46] <cjohnston> sure.. ty
[20:46] <imbrandon> yea totally, and if you run into any snaggs let me know, i'm actually working on the nginx charm this weekend
[20:46] <imbrandon> infact thats was the thing i needed an hour to wrap up on
[20:46] <imbrandon> liek got it half uploaded to LP :)
[20:46] <imbrandon> heh
[20:47] <imbrandon> but i can for this minute pastebin the two configs that i blog posted about , that will get you a head start but the blog still explains line by line
[20:47] <imbrandon> so later you'll still want those
[20:47] <imbrandon> but yea , one sec
[20:47] <ajmitch> popey: it is great, now is there a magic way to get all these app submissions through the ARB? :)
[20:51] <imbrandon> ok , cjohnston please ignore the rest of this charm, as the rest of it is very very old and has changed alot since then BUT nginx hasent and these configs are identical to now
[20:51] <imbrandon> cjohnston: http://bazaar.launchpad.net/~imbrandon/+junk/omg-bzr/files/head:/files/nginx/
[20:51] <cjohnston> ok
[20:51] <cjohnston> ty
[20:51] <imbrandon> that dir has 4 configs, ignore the "admin" one
[20:52] <cjohnston> k
[20:52] <imbrandon> it wont apply to u, but you need the other 3, one is the main nginx, one is the LB on port 80, and other serves php or python on 8080
[20:52] <imbrandon> should be able to get the basic setup goign from that, and i'm arround if ya need as well as i'll dig my posts back up
[20:52] <imbrandon> cheers!@
[20:53] <cjohnston> thanks dude
[20:53] <imbrandon> ( and sorry all for barginf in heheh )
[20:53]  * imbrandon waves to popey and ajmitch
[20:53] <imbrandon> np
[20:53]  * ajmitch waves
[20:53] <popey> :)
[20:53] <ajmitch> yay, monday mornings
[20:53] <imbrandon> heh
[20:54] <imbrandon> btw if you replace the _ in the file names it gives you the default paths those should go in
[20:54] <imbrandon> if that wasent obvious
[20:54] <imbrandon> heh
[20:56] <imbrandon> and you need the nginx ppa apt-ass-repo lp:nginx/stable , then install "nginx-extras" for php or python, and nginx-extras + nginx-passenger if you need rails
[20:56] <imbrandon> ok and thats all
[20:56] <imbrandon> heh
[20:56] <imbrandon> ( even the 12.04 pkgs is too old for some of the configs i use, but that ppa is run by upstream and only stable releases so u should be good )
[20:57] <AlanBell> there really should be an apt-ass-repo command
[20:57] <imbrandon> hahaha
[20:57] <imbrandon> i dident even notice, whoops
[20:57] <imbrandon> :)
[20:57] <imbrandon> ok ok, seriously i am done now all, sorry for the interuptions :)
[20:58]  * imbrandon goes back into a corner
[20:59] <imbrandon> ajmitch: btw i totaly failed at trying to use fabric on a php deploy , you wouldent have a fabfile that wouldent be to hard to sanitize enough to share with me to learn from would you ?
[21:00] <imbrandon> i'd like to try and use it from certain hooks in side of juju charms
[21:01] <imbrandon> when you read back , I totaly understand if not since its work stuff etc etc, dont wanna riskin ur neck
[21:01] <imbrandon> :)
[21:02] <ajmitch> not quite community team stuff, let's discuss elsewhere ;)
[21:02] <imbrandon> bah, yea , i'm terrible uwire ?
[21:03] <ajmitch> sure
[23:08]  * s-fox waves
[23:09] <cjohnston> o/
[23:09] <s-fox> o/ cjohnston , how are you?
[23:09] <cjohnston> doin good.. yourself?
[23:09] <cjohnston> I've had a busy past couple days learnin tons of stuff
[23:09] <s-fox> not bad, just got back in from an evening at the bar
[23:10] <cjohnston> jealous
[23:10] <s-fox> don't be
[23:10] <s-fox> being the taxi sucks
[23:10] <s-fox> :)
[23:10] <cjohnston> ahh
[23:10] <cjohnston> yes
[23:10] <cjohnston> I still wouldn't mind getting out
[23:10] <s-fox> :)
[23:11] <s-fox> what have you been learning?
[23:11] <cjohnston> packaging
[23:11] <cjohnston> I uploaded a package to try to get it into debian, thereby into Ubuntu
[23:11] <s-fox> ohh, i did some of that earlier funnily enough
[23:11] <cjohnston> cool
[23:11] <cjohnston> its taken me 3 days
[23:11] <cjohnston> heh
[23:11] <s-fox> oooh.....
[23:12] <s-fox> it took me about 20 minutes to package, a day to get the ppa stuff sorted. lol
[23:12] <cjohnston> this was my first time doin any of ti
[23:12] <cjohnston> it
[23:12] <s-fox> what does your app do?
[23:13] <cjohnston> its not my app.. I'm just getting it into debian.. it does admin logging in django
[23:13] <s-fox> neat
[23:13]  * s-fox has entered the ubuntu app competition thing
[23:13] <cjohnston> oh sweet
[23:13] <cjohnston> whats your app do
[23:14] <s-fox> being a complete novice to desktop application development i am ideally suited ;) lol
[23:14] <s-fox> cjohnston,  http://serial-coder.co.uk/blog/my-shortcuts/
[23:15] <s-fox> i knocked up a webpage explaining the whats, how and whys my application exists
[23:15] <s-fox> :D
[23:16] <cjohnston> sweet
[23:16] <cjohnston> looks nice
[23:16] <s-fox> thanks :)
[23:16] <s-fox> i had to learn loads of stuff to build it
[23:17] <cjohnston> I bet
[23:17]  * s-fox works as web dev, so everything was literally new and i had to do a lot of reading
[23:19] <s-fox> it isn't going to win the competition, but that is not the point :)
[23:22] <cjohnston> you learned.. and thats more than can be said about me
[23:22] <cjohnston> ;-)
[23:23] <s-fox> lol :)
[23:25] <s-fox> it is currently being reviewed by the people who allow stuff into the software center.  i know it isn't a complicated app, but maybe i would be sad if it were rejected
[23:25] <s-fox> i mean, i tried and did my best.


[13:57] <mitya57> Our artful builds started failing with “E: The repository 'file:/home/buildd/work/apt ./ Release' is not signed.” recently. Does anybody know what causes this?
[13:57] <mitya57> https://launchpadlibrarian.net/326489859/buildlog.txt.gz
[14:08] <cjwatson> mitya57: https://bugs.launchpad.net/launchpad-buildd/+bug/1701826
[14:09] <mitya57> cjwatson, thank you, subscribed


[12:22] <LaserJock> ok, I'm confused. What's the difference between kde4libs and kdelibs5?
[12:43] <mhb> LaserJock: kde4libs doesn't exist
[12:45] <LaserJock> mhb: hmm, interesting, I wonder why synaptic is showing it to me then
[12:45] <stdin> update your package list? it was the old name for it
[12:45] <LaserJock> interesting, it just deps on kdelibs5
[12:46] <LaserJock> must be a transitional package
[12:46] <LaserJock> that's kinda confusing
[12:46] <mhb> LaserJock: there's no such package in my repos
[12:47] <LaserJock> mhb: feisty universe
[12:47] <mhb> LaserJock: ah, feisty. Well, it's not in gutsy anymore.
[12:48] <LaserJock> why was it renamed? it seem quite inconsistent when everything else seems to be kde4* and I would at least expect it to be kdelib4
[12:48] <mhb> LaserJock: it's totally confusing, I'm saying that all the time.
[12:49] <mhb> LaserJock: there was the debian package kdelibs4, which contained kde3 libraries ... so they just ++ it.
[12:49] <LaserJock> blah :-)
[12:51] <mhb> LaserJock: silly, I know. The best thing you can do is tell your opinion to Riddell or some other maintainer involved with kde4.
[12:52] <LaserJock> I just wondered what the reasoning was, I figured it must be something like that
[12:55] <LaserJock> alrighty, installing now, we'll see what all this KDE4 stuff is all about ;-)
[12:57] <mhb> LaserJock: about being unstable, mainly :o)
[12:57] <LaserJock> heh, well I only have a few apps I'm interested in
[12:58] <LaserJock> I'll be running it in Gnome, so we'll see
[12:58] <LaserJock> I don't mind some stability
[01:11] <LaserJock> geeze, kdelib5 is almost 100MB
[02:30] <bddebian> Heya
[02:32] <DaSkreech> yo yo
[02:32] <bddebian> Hi DaSkreech
[02:32] <DaSkreech> How goes?
[02:33] <bddebian> Fair to midland thanks. You?
[02:35] <mhb> manchicken|away: remember when I sent you the suggestion on how the adept-batch caption should be called?
[04:01] <manchicken> mhb: Yeah, I haven't been able to get that done yet.
[04:18] <DaSkreech> Wheee
[04:18] <DaSkreech> Lots of work to be done on kss
[04:27] <TheInfinity> hmm ...
[04:28] <TheInfinity> knetworkmanager does not like me :(
[04:29] <Hobbsee> oh, i've just had a thought
[04:29] <ScottK2> Uh oh.
[04:29] <Hobbsee> knetworkmanager seems to hate unencrypted networks, with ipw2945 cards.
[04:29] <ScottK2> ;-)
[04:29] <Hobbsee> there's a bug on it
[04:29] <ScottK2> Yes.
[04:30] <Hobbsee> so *that's* why i always have to use the old manual method while at uni
[04:30] <ScottK2> That would make sense.
[04:30] <TheInfinity> knetworkmanager does not like my ethernet adaper at all :/
[04:30] <TheInfinity> he does not even show my rj45 lan
[04:30] <Hobbsee> ScottK2: heh :)
[04:31] <ScottK2> It works fine with my D-Link DWL-G650 rev C2.
[04:32] <Hobbsee> no, it seems to be a ipw3945 thing
[04:32] <Hobbsee> and those are nice cards (the dlinks)
[07:37] <mhb> manchicken_: adept_notifier is in reality adept_notifier_and_also_apport_handler ?
[07:37] <mhb> manchicken_: now I didn't know that
[07:41] <fdoving> mhb: how is your grub-config-project going?
[07:41] <fdoving> hi btw. :)
[07:44] <mhb> fdoving: hi, xerosis (who's not here atm) took over it because I am pretty busy with SoC this summer... but I haven't heard from him lately
[07:44] <mhb> fdoving: I'll ask him
[07:45] <fdoving> ok, just curious. jhutchins suggested we should have such a tool and your project came to mind. :)
[07:49] <mhb> fdoving: hmm, xerosis hasn't done much with it in the last few weeks
[07:49] <fdoving> ok.
[07:50] <mhb> fdoving: OTOH, one of the SoCers is developing a similar tool for Ubuntu and I gave him a backend I created, so I wonder if we could merge it back and create a quick frontend for it
[07:51] <fdoving> that would be cool.
[07:51] <mhb> LaserJock should be mentoring him, I'll ask him when he's around
[08:15] <mhb> manchicken__: has one of you manchickens noticed my question or did I ask in a bad time?
[09:05] <nixternal> howdy people!
[09:05] <mhb> howdy nixternal
[09:06] <nixternal> I slept way to long
[09:06] <nixternal> I shut the blinds in the room so the sun wouldn't wake me, and I did close to 12 hours of sleep
[09:06] <mhb> nixternal: you slept all the way to Long?
[09:06] <nixternal> hehe
[09:07] <nixternal> usually I am a 6 or 7 hour sleeper...but I caught up on some sleep from Friday night I guess
[09:07] <mhb> nixternal: by the way, about Konqueror tricks: do you happen to know why Kubuntu's Konqueror always displays the tab bar?
[09:07] <mhb> nixternal: all the other browsers hide it if there's just one window
[09:07] <nixternal> I believe we make that a default
[09:08] <nixternal> I am not 100% positive though...maybe KDE makes that a default
[09:08] <mhb> nixternal: well, I wanted to know the rationale
[09:08] <nixternal> if I use other browsers, I change it to mock konqui
[09:09] <mhb> nixternal: I prefer the tab bar to be hidden so there's more space for content when I have only one tab open... I may be the only person in the world, though :o)
[09:09] <nixternal> hehe
[09:09] <nixternal> I guess I have just gotten used to it
[09:18] <nixternal> how do you change the resolution of the KDM window?
[09:18] <ScottK> Riddell: I noticed that lighttpd 1.4.11-3ubuntu3.2 is still sitting in dapper-proposed even after you released lighttpd 1.4.11-3ubuntu3.3 to dapper-updates.  Dunno if that needs cleanup or not, but thought I'd mention it just in case.
[09:19] <mhb> nixternal: you mean the background one?
[09:20] <nixternal> well the resolution at the login screen is what I need to change
[09:20] <nixternal> it is huge right now
[09:20] <mhb> not sure
[09:20] <nixternal> it needs to be at 1440x900...i thought you could do it in kcontrol as I know I have done it before..but I cannot remember
[09:20] <mhb> ryanakca played with kdm some time back but he's on vacation now
[09:21] <nixternal> campin' with the bears
[09:22] <ScottK> nixternal: I thought it was "da Bears" where you are?
[09:23] <Riddell> ScottK: it can just stay there
[09:23] <ScottK> Riddell: OK.  Thanks.
[09:27] <fdoving> nixternal: i belive kdm will just use what is your default X resolution. if you change it with randr or something when you login that won't affect kdm.
[09:28] <nixternal> I changed it with System Settings and it didn't change..there is probably something stuck
[09:48] <manchicken> mhb: I didn't know about the apport support.
[09:48] <manchicken> That's interesting.
[10:32] <nixternal> anyone familiar with ksensors and/or hddtemp?
[11:23] <mhb> ScottK: that guy you're dealing with on bug tracker probably encountered an amd64 adept breakage
[11:23] <ScottK> AH.
[11:23] <mhb> ScottK: because that's what has happened to me & nixternal today
[11:23] <ScottK> Is it fixed?
[11:23] <nixternal> nope
[11:23] <nixternal> FTBS
[11:24] <ScottK> Argh.
[11:24] <mhb> 23:02 < Riddell> pitti: could you give back adept on amd64, libept should be installable now
[11:24] <mhb> ScottK: ^^
[11:25] <ScottK> But it hasn't happened yet?
[11:25] <mhb> ScottK: not yet, I'm afraid
[11:26] <ScottK> ? http://launchpadlibrarian.net/8699343/buildlog_ubuntu-gutsy-amd64.adept_2.1.3ubuntu4_FULLYBUILT.txt.gz
[11:26] <ScottK> I'm now confused.
[11:26] <ScottK> LP seems to think it's built.
[11:27] <mhb> 23:01 < Riddell> "gutsy amd64  Failed to build"  do you have an amd64 mhb?
[11:27] <mhb> ^^ jr said it wasn't, at least it seems so to me
[11:29] <Riddell> ScottK: it's just been (re)built
[11:29] <Riddell> should be in the archives soonish
[11:30] <ScottK> Cool.
[11:30] <nixternal> not, cool!
[11:30] <nixternal> GROOVY!
[11:30] <nixternal> ;)
[11:36] <mhb> anyone here ready for some testing?
[11:40] <mhb> nixternal: if you could check out https://code.launchpad.net/~martin.bohm/restricted-manager/k-r-m , debuild it, install it and try it, that'd be groovy
[11:40] <nixternal> roger that
[11:40] <mhb> nixternal: unfortunately it needs adept to install :o(
[11:41] <nixternal> I will do it on my 32bit box
[11:41] <nixternal> well if I build it I can use trusty ol' cli
[11:41] <nixternal> fetching it now
[11:42] <mhb> nixternal: it needs to be tested extensively, because if it gets uploaded tomorrow it might be one of the highlights for the next tribe
[11:42] <mhb> nixternal: err, intesively :o)
[11:42] <nixternal> roger that
[11:46] <nixternal> howdy imbrandon
[11:46] <imbrandon> heya nix
[11:46] <nixternal> how goeth the life?
[11:46] <imbrandon> brb , got some server issues to work on, bbiab
[11:46] <nixternal> ooh fun
[11:46] <imbrandon> good good, just a busy night
[11:46] <imbrandon> ;)
[11:46] <imbrandon> brb
[11:47] <nixternal> roger dodger
[11:48] <imbrandon> nixternal, know of a decient cpu-z replacement ( and no i dont mean "cat /proc/cpuinfo" is good nuff ) full GUI etc etc etc
[11:48] <nixternal> KSensors
[11:48] <nixternal> err
[11:48] <nixternal> might be more than you want
[11:49] <imbrandon> nah, even more, i might just have to clobber a python-qt/kde app togather as a proof of concept
[11:49] <imbrandon> all the info is there its just spread out in /proc/* and other places
[11:49] <imbrandon> heh
[11:50] <nixternal> imbrandon: funny you say that, I was going to start working on one similar
[11:50] <nixternal> isn't cpu-z a windows only app? or is that what you are looking for?
[11:50] <imbrandon> nice, go for it, i'll test and maybe code a line or two if i get an itch, i really dont have the time to put into it
[11:50] <imbrandon> yea its a windows only app, but i want it for (k)ubuntu
[11:51] <imbrandon> should be simple, all the same info is explosed somewhere in the proc tree, it just needs to be gui-ified
[11:51] <nixternal> I will have to isntall it on Windows and check it out...create a gui that is similar and then rock from there
[11:51] <nixternal> KSensors is about the closest thing that I know of right now
[11:51] <imbrandon> there is probably screenshots somewhere, its a simple 2 or 3 tab app with no interaction
[11:52] <nixternal> KSensors is a dupe of Motherboard Monitor if you remember that
[11:52] <imbrandon> you only run it and it outputs comp info to the screen, like windows device manager for your motherboard and cpu on crack
[11:52] <nixternal> ahh
[11:52] <imbrandon> ok, sorry , got to run, back in a bit
[11:53] <nixternal> oh ya, I remember cpu-z
[11:53] <nixternal> as a matter of fact, someone kde-apps has written one with kommander I believe
[11:54] <imbrandon> nixternal, ahh yea, here we go, just like this ( and the other tabs ) http://news.softpedia.com/images/reviews/large/CPU-Z_01large.png
[11:54] <nixternal> haha, that is what I am reading right now
[11:54] <imbrandon> cool, i'll dig on kde-apps later
[11:57] <nixternal> ScottK: remember we were talking about project yesterday or what not? well the other app I was trying to think of was TaskJuggler...it is very similar as well...very nice app
[12:01] <ScottK> Ah.
[12:01] <ScottK> Thanks.


[00:23] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3803 Failed to build (eoan/tracker). Pending binary packages (eoan/tracker-miners)
[01:03] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3803 Diff missing (eoan/tracker-miners). Failed to build (eoan/tracker)
[05:44] -queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3804 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[06:08] -queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3804 Pending binary packages
[06:28] -queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3804 Diff missing
[07:27] -queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3804 Currently building (eoan/baloo-kf5, eoan/bluez-qt, eoan/kconfig, eoan/kconfigwidgets, eoan/kcoreaddons, eoan/kdeclarative, eoan/kded, eoan/kdelibs4support, eoan/kdesignerplugin, eoan/kdesu, eoan/kdewebkit, eoan/kdnssd-kf5, eoan/kdoctools, eoan/kemoticons, eoan/kfilemetadata-kf5, eoan/kglobalaccel, eoan/kholidays, eoan/khtml, eoan/kiconthemes, eoan/kimageformats, eoan/kinit, eoan/kio, eoan/kirig
[07:48] -queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3804 Currently building (eoan/khtml, eoan/kwayland, eoan/modemmanager-qt, eoan/networkmanager-qt, eoan/prison-kf5, eoan/solid, eoan/sonnet). Diff missing (eoan/attica-kf5, eoan/bluez-qt, eoan/breeze-icons, eoan/kapidox, eoan/kconfig, eoan/kcoreaddons, eoan/kdesignerplugin, eoan/kdewebkit, eoan/kidletime, eoan/ksyntax-highlighting). Failed to build (eoan/kinit, eoan/kio, eoan/kmediaplayer, eoan/knews
[08:08] -queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3804 Diff missing (eoan/attica-kf5, eoan/baloo-kf5, eoan/bluez-qt, eoan/breeze-icons, eoan/extra-cmake-modules, eoan/frameworkintegration, eoan/kactivities-kf5, eoan/kactivities-stats, eoan/kapidox, eoan/karchive, eoan/kauth, eoan/kbookmarks, eoan/kcmutils, eoan/kcodecs, eoan/kcompletion, eoan/kconfig, eoan/kconfigwidgets, eoan/kcrash, eoan/kdbusaddons, eoan/kded, eoan/kdesignerplugin, eoan/kdewebki
[08:28] -queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3804 Currently building (eoan/kio). Diff missing (eoan/attica-kf5, eoan/baloo-kf5, eoan/bluez-qt, eoan/breeze-icons, eoan/extra-cmake-modules, eoan/frameworkintegration, eoan/kactivities-kf5, eoan/kactivities-stats, eoan/kapidox, eoan/karchive, eoan/kauth, eoan/kbookmarks, eoan/kcmutils, eoan/kcodecs, eoan/kcompletion, eoan/kconfig, eoan/kconfigwidgets, eoan/kcoreaddons, eoan/kcrash, eoan/kdbusaddon
[08:48] -queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3804 Diff missing (eoan/attica-kf5, eoan/baloo-kf5, eoan/bluez-qt, eoan/breeze-icons, eoan/extra-cmake-modules, eoan/frameworkintegration, eoan/kactivities-kf5, eoan/kactivities-stats, eoan/kapidox, eoan/karchive, eoan/kauth, eoan/kbookmarks, eoan/kcmutils, eoan/kcodecs, eoan/kcompletion, eoan/kconfig, eoan/kconfigwidgets, eoan/kcoreaddons, eoan/kcrash, eoan/kdbusaddons, eoan/kdeclarative, eoan/kded
[09:28] -queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3804 Diff missing (eoan/attica-kf5, eoan/baloo-kf5, eoan/bluez-qt, eoan/breeze-icons, eoan/extra-cmake-modules, eoan/frameworkintegration, eoan/kactivities-kf5, eoan/kactivities-stats, eoan/kapidox, eoan/karchive, eoan/kauth, eoan/kbookmarks, eoan/kcmutils, eoan/kcodecs, eoan/kcompletion, eoan/kconfig, eoan/kconfigwidgets, eoan/kcoreaddons, eoan/kcrash, eoan/kdbusaddons, eoan/kdeclarative, eoan/kded
[09:48] -queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3804 Diff missing (eoan/attica-kf5, eoan/baloo-kf5, eoan/bluez-qt, eoan/breeze-icons, eoan/extra-cmake-modules, eoan/frameworkintegration, eoan/kactivities-kf5, eoan/kactivities-stats, eoan/kapidox, eoan/karchive, eoan/kauth, eoan/kbookmarks, eoan/kcmutils, eoan/kcodecs, eoan/kcompletion, eoan/kconfig, eoan/kconfigwidgets, eoan/kcoreaddons, eoan/kcrash, eoan/kdbusaddons, eoan/kdeclarative, eoan/kded
[10:08] -queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3804 Currently building (eoan/ktexteditor, eoan/plasma-framework). Diff missing (eoan/attica-kf5, eoan/baloo-kf5, eoan/bluez-qt, eoan/breeze-icons, eoan/extra-cmake-modules, eoan/frameworkintegration, eoan/kactivities-kf5, eoan/kactivities-stats, eoan/kapidox, eoan/karchive, eoan/kauth, eoan/kbookmarks, eoan/kcmutils, eoan/kcodecs, eoan/kcompletion, eoan/kconfig, eoan/kconfigwidgets, eoan/kcoreaddon
[10:48] -queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3804 Diff missing
[12:28] -queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3804 Diff missing
[12:37] -queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3804 Generating diffs
[12:48] -queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3804 Successfully built
[17:04] -queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3804 Publishing packages
[17:26] -queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3804 Proposed pocket
[19:46] -queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3804 Proposed pocket (eoan/akonadi, eoan/attica-kf5, eoan/baloo-kf5, eoan/bluez-qt, eoan/breeze-icons, eoan/extra-cmake-modules, eoan/frameworkintegration, eoan/kactivities-kf5, eoan/kapidox, eoan/karchive, eoan/kauth, eoan/kbookmarks, eoan/kcmutils, eoan/kcodecs, eoan/kcompletion, eoan/kconfig, eoan/kconfigwidgets, eoan/kcoreaddons, eoan/kcrash, eoan/kdbusaddons, eoan/kdeclarative, eoan/kded, eoan/
[22:46] -queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3804 Proposed pocket (eoan/attica-kf5, eoan/baloo-kf5, eoan/bluez-qt, eoan/breeze-icons, eoan/extra-cmake-modules, eoan/frameworkintegration, eoan/kactivities-kf5, eoan/kapidox, eoan/karchive, eoan/kauth, eoan/kbookmarks, eoan/kcmutils, eoan/kcodecs, eoan/kcompletion, eoan/kconfig, eoan/kconfigwidgets, eoan/kcoreaddons, eoan/kcrash, eoan/kdbusaddons, eoan/kdeclarative, eoan/kded, eoan/kdelibs4suppor


[11:18] <`6og> does -news allow derivatives anouncements? (i'm thinking INX 1.0 which was offically released about 24 hrs ago)
[12:18] <Kamping_Kaiser> for that matter, any hints on where to ... spam... would be cool too