[00:00] <jonoxer> http://pastebin.com/d3b0caad4
[00:01] <jonoxer> I've seen references to a couple of other tools that specifically do repo conversion, but not found the scripts themselves (docs point to defunct pages, etc)
[00:02] <lifeless> 32 or 64 bit python build ?
[00:03] <jonoxer> 32
[00:03] <lifeless> ok
[00:03] <jonoxer> Aha, I hadn't thought of that
[00:03] <lifeless> so, it physically can't fill swap to run out of memory
[00:03] <lifeless> it could be
[00:03] <lifeless> a) some form of fragmentation; in which case continuing from where it left off may work
[00:04] <lifeless> b) a single object too big to handle (we currently require any single text to be < ~1/3 usable memory)
[00:04] <jonoxer> Mmm, I'll give it a try on a 64 bit machine
[00:04] <lifeless> c) a bug
[00:05] <jonoxer> It'll take half the day to find out if that helps though!
[00:05] <lifeless> jonoxer: I'd try continuing in the first instance
[00:06] <lifeless> jonoxer: did you run 'bzr branch' ?
[00:06] <lifeless> jonoxer: if so, cd to the output dir, run 'bzr reconfigure --branch', then 'bzr pull svn://.....'
[00:06] <jonoxer> lifeless: problem is I don't know what commit it failed on. The progress bar vanishes when it does the traceback, and unless I was looking at that exact moment I wouldn't know. Is there a way to find out?
[00:07] <lifeless> jonoxer: you don't need to know :P
[00:07] <jonoxer> Ahh, I see
[00:08] <lifeless> thats the sort of housekeeping bzr is meant to do for you
[00:09] <Peng_> In the future, you could also set up a loop to pull, say, 1000 revisions at a time.
[00:10] <jonoxer> Woot! It started again, and thinks it only has 8435 revs to pull, so it must be going from the point it died. Thanks lifeless
[00:10] <jonoxer> Peng_: good idea
[00:10] <spiv> jonoxer: if you're not already doing so, you could try running the latest bzr-svn release.  I think some major memory leaks have been fixed.
[00:11] <spiv> jonoxer: did you figure out your problem from Friday?  (file permissions?)
[00:11] <Peng_> That's right. (The leaks were more svn's fault than bzr-svn's, but in any case, the situation has been improved with svn 1.5 or the latest bzr-svn release.)
[00:12] <jonoxer> spiv: not yet, the sftp error was a good clue but I was away in Sydney on the weekend shooting a new TV show (lots of fun) and just got home at 1am today, so I haven't had a chance to try again yet
[00:15] <lifeless> poolie: you've marked 282402 as invalid; I don't think its invalid - its just a faulty try:finally: rather than a try:finally:except: block on WT.commit.
[00:15] <poolie> bug 282402
[00:16] <lifeless> poolie: this may have contributed to other commit bugs, where exceptions damaged the dirstate
[00:16] <poolie> are you sure?
[00:16] <lifeless> mutabletree.py has @needs_write_lock\ndef commit(...)
[00:17] <lifeless> I think that should be altered to call
[00:17] <lifeless> (looking for method name)
[00:17] <lifeless> uhm, I think its self._reset_data()
[00:17] <lifeless> in the event of an exception
[00:19] <lifeless> poolie: I am sure that we shouldn't save changes to the dirstate if the commit is cancelled; I'm reasonably sure the same applies to errors
[00:19] <poolie> yes, you're right
[00:45] <davidstrauss_> I have a question about the "decentralized with shared mainline" workflow. After branching, it seems like "bzr commit" would only be local, but the diagram on the workflows page shows "bzr commit" going back to the central repository.
[00:45] <davidstrauss_> Is there a page with clearer documentation of the workflow?
[00:55] <spiv> aaaa
[00:57] <spiv> davidstrauss_: well, if the users have a checkout of the shared mainline (in addition to their other branches), then commit in that would go back to the central location.
[01:17] <davidstrauss_> spiv: But what if it's a branch?
[01:17] <lifeless> davidstrauss_: the point of a branch is not to flow back automatically
[01:17] <davidstrauss_> http://bazaar-vcs.org/Workflows#head-ca3ccf73574776b36453b2213789731549e54167
[01:17] <davidstrauss_> lifeless: yes, but what's the proper way to send your changes back from your branch to the shared mainline?
[01:18] <lifeless> davidstrauss_: have a checkout of the mainline; merge your changes and commit
[01:18] <lifeless> davidstrauss_: (which is exactly what a maintainer of a non-shared mainline would do, but you're able to do it yourself because its shared)
[01:26] <lifeless> why does bzr.dev only have an IMPROVEMENTS section in NEWS?
[01:33] <davidstrauss_> Is there a way to have Bazaar default to local commits?
[01:41] <lifeless> davidstrauss_: I am going to guess that you're trying to avoid having both a branch and a checkout of the mainline
[01:42] <davidstrauss_> lifeless: yes
[01:42] <lifeless> davidstrauss_: probably because of disk space used/wanting to reuse build products
[01:42] <davidstrauss_> lifeless: no, it's mostly an interest in limiting complexity
[01:42] <lifeless> davidstrauss_: anyhow, 'bzr unbind' will temporarily convert a heavyweight checkout to a regular branch
[01:42] <lifeless> just 'bzr bind' will restore the binding
[01:43] <lifeless> myself, I'd use a single working tree but still have two branch objects, because its handy when offline to be able to see exactly what the mainline looked like
[01:52] <davidstrauss_> lifeless: thank you. your comments really help develop my team's bazaar workflow
[01:53] <lifeless> davidstrauss_: my pleasure
[01:56] <davidstrauss_> lifeless: What is the process for improving this documentation on the Bazaar website?
[01:56] <lifeless> davidstrauss_: I believe that that page is versioned in the bzr tree, in doc/ somewhere
[01:56] <davidstrauss_> ok
[01:57] <lifeless> davidstrauss_: *if* it is, then a patch to that. If its not, then edit the wiki page directly/mail the list if you are not sure you'd be improving it :>
[01:59] <ferringb> lifeless: don't suppose you know what gurantees there are for revision_history()?  specifically ordering of the resultant sequence?
[01:59] <lifeless> ferringb: Branch.revision_history ?
[01:59] <ferringb> yep
[01:59] <lifeless> ferringb: its strictly the left hand history
[01:59] <ferringb> ok
[02:00] <lifeless> ferringb: its a bad api to use though -
[02:00] <ferringb> alternatives?
[02:00] <lifeless> -Devil will report on its use
[02:00] <lifeless> ferringb: Repository.get_graph()
[02:00] <ferringb> guessing that's not just left hand?
[02:01] <lifeless> ferringb: there are various other alternatives; what are you doing, perhaps I can be more specific :P
[02:01] <ferringb> trac-bzr
[02:01] <lifeless> timeline view?
[02:01] <ferringb> among other things
[02:01] <lifeless> so the graph object returned should have enough methods on it
[02:01] <lifeless> but there are also iter_ methods on branch and repository
[02:02] <ferringb> one thing I was playing with for speed reasons was pulling revision_history, finding the rev from the inventory object I get file path2id, then limiting the revs I inspect for changes via starting at that rev
[02:02] <ferringb> don't suppose oyu have a specific method to recommend in that case?
[02:03] <lifeless> well
[02:04] <lifeless> iter_revision_deltas should be solid
[02:04] <lifeless> but the basic speed problem is deep within bzrlib
[02:04] <ferringb> heh.  my next question was going to be "how fast is it" ;)
[02:04] <lifeless> the inventory representation is not conducive to fast delta generation
[02:04] <lifeless> see log -v for instance
[02:04] <lifeless> anyhow, I'm working on that at the moment, in my repository branch
[02:05] <ferringb> yeah, I skanked my current code out of log -v's implementation actually
[02:05] <ferringb> then got bit by the lefthand nature of revision_history
[02:06] <ferringb> aside from loggerhead, any other sources you're recommend (alternatively api walkthroughs rather then docs)?
[02:06] <ferringb> *you'd.  english and I are not getting along it seems
[02:08] <lifeless> log -v and loggerhead are likely the most tuned things around today
[02:08] <lifeless> oh
[02:08] <lifeless> bzr-search too
[02:09] <lifeless> bzr-search has some stuff thats ten times faster than regular bzrlib
[02:09] <ferringb> delta searching, or
[02:09] <lifeless> it generates multiparent deltas on every revision to determine what to index
[02:10] <ferringb> denormalizes it into a cache I'm guessing
[02:10] <lifeless> nope
[02:21] <Peng_> Oh, you rebased the 'repository' branch?
[02:22] <lifeless> Peng_: huh?
[02:22] <lifeless> Peng_: don't think so, previous work was merged
[02:23] <Peng_> Eh. I just pulled it (for the first time in like a year), and there are removed revisions.
[02:23] <lifeless> Peng_: do you mean the revno has dropped ?
[02:24] <lifeless> Peng_: if so thats just because it had run way ahead of bzr.dev's revno, and when bzr.dev merged it, and I pulled back, we're back along with bzr.dev's revnos.
[02:25] <Peng_> Oh. If you pulled back from bzr.dev to it, that messes with what's on the left-hand side of the graph or whatever the term is, right?
[02:25]  * Peng_ shrugs.
[02:26] <lifeless> Peng_: if I had rebased you would have had a diverged-branches message
[02:27] <Peng_> Oh. Right. Sorry, my mistake in using the wrong term.
[02:29] <jonoxer> spiv: I've done more testing to figure out the permissions problem, and I'm stumped. Unless the repo is owned by the user doing the push it just won't work. Even with the user in the correct group and "chmod -R 775 repo" done. It's like bzr+ssh and sftp methods are ignoring group membership.
[02:29] <jonoxer> I'll see if I can get any more clues
[02:29] <Peng_> Isn't there an OpenSSH bug about ignoring group ownership or permissions or something?
[02:30] <lifeless> jonoxer: openssh's sftp-server ignores the sticky bit
[02:30] <Peng_> ...What he said.
[02:30] <jonoxer> Aha, that sounds exactly like the problem
[02:30] <lifeless> more specifically
[02:30] <lifeless> it masks it out on chmod() calls made over the wire
[02:33] <jonoxer> Any good / bad experiences with vsftpd? Any particular suggestions for an sftpd to use for a bzr repo?
[02:34] <lifeless> jonoxer: bzr+ssh should work though, because sftpd isn't involved
[02:34] <jonoxer> lifeless: that seems to exhibit the same problem, but I'll try again with a clean setup in case I've broken things with all my mucking around
[03:28] <jonoxer> Success: starting from scratch with a clean repo and setting group write perms and the sticky bit makes bzr+ssh work for me   :-)
[03:28] <jonoxer> thanks lifeless
[03:28] <bob2> for an ldap account?
[03:29] <jonoxer> That test used local users, I'll test now with LDAP users...
[03:30] <jonoxer> ...and it works
[03:33] <lifeless> my bet: sftp borked the sticky bit, then you tested bzr+ssh after and it was already broken
[03:34] <jonoxer> lifeless: certainly plausible
[03:34] <jonoxer> This'll work nicely anyway, since all the devs are already in LDAP
[03:34] <arjenAU> jonoxer: horay!
[03:36] <spiv> jonoxer: excellent
[03:36] <jonoxer> To ease the svn-bzr transition I'm thinking of doing something like the discussion above with a shared mainline and personal branches. That way devs can operate the mainline the same way we currently use svn, with their branches giving the added bzr flexibility
[03:36] <poolie> hm, vila has no valid gpg key?
[03:41] <spiv> jonoxer: sounds good
[03:41] <jonoxer> I don't want to change their workflow too much in one go so if I can swap out svn for bzr and just tell them "instead of svn commit, from now on do bzr commit" etc that's step 1. Then getting them working in personal branches and merging to mainline is step 2, etc
[03:47] <poolie> hm so apparently there is no way at all to persuade gpg to trust me just a bit
[03:47] <poolie> short of patching it i suppose
[03:48] <lifeless> poolie: how to do you mean?
[03:48] <poolie> to encrypt to an expired key
[03:48] <lifeless> poolie: is it your key?
[03:48] <poolie> it's vila's key
[03:48] <lifeless> yah no
[03:48] <lifeless> he has to update the expiry date and resign it
[03:48] <poolie> he'll just have to wait til he makes a new one
[03:49] <poolie> can you renew it?
[03:50] <lifeless> I'm pretty sure he has to do it
[03:55] <poolie> heh, 'you'!=you
[03:55] <poolie> i meant, i was wondering if it's possible for the owner to renew an expired key, not would you please do it for me :)
[03:56] <poolie> and yes you can > http://www.gnupg.org/gph/en/manual/c235.html#AEN328
[03:57] <lifeless> oh yes, owners can
[03:57] <lifeless> thats why  I said he has too :>
[03:58] <lifeless> to
[04:10] <poolie> you should now be able to get to kerguelen btw
[04:10] <poolie> except that i have two sessions open
[04:48] <jonoxer> I've started writing a little "svn to bzr without pain" guide as I work through things. It's not really about the tech aspects of moving repos, more about the process of replacing one workflow with another. Rough beginning here: http://jon.oxer.com.au/svntobzr/
[04:48] <jonoxer> I'll flesh it out / fix things as I go. Maybe eventually it'll be useful to someone
[05:12] <lifeless> jonoxer: cool
[05:13] <jonoxer> lifeless: It might sound backwards, but I actually find it good to write docs while I'm trying to figure things out rather than later when I'm an "expert" and have too many subconscious assumptions
[05:20] <lifeless> jonoxer: you only learn something once
[05:20] <poolie> jonoxer: that's a great idea
[05:21] <teratorn> jonoxer: no I reckon that's pretty smart... I have a theory that the people most knowledgeable about a piece of software are often the least capable of understanding what new users need in terms of documentation
[05:21] <poolie> overall what are you finding good or bad so far?
[05:23] <jonoxer> poolie: I haven't found anything inherently bad so far, all the badness I've experienced has been related to migration. I'm coming to BZR with a lot of baggage (mental and infrastructure) to convert
[05:25] <jonoxer> The good is definitely slick branching/merging. Other things like having full local history are nice, but I haven't felt the benefits yet
[05:29] <lifeless> poolie: NEWS is a little odd at the moment
[05:29] <lifeless> poolie: its missing all the normal sections
[05:29] <poolie> because i added a main heading but no sections?
[05:29] <lifeless> yah
[05:30] <lifeless> I think its likely to promote merge conflicts; and it definitely won't work with my auto editing script
[05:34] <lifeless> poolie: its also very confusiong
[05:34] <lifeless> poolie: because - do I use API BREAKS
[05:34] <lifeless> or CHANGES
[05:34] <lifeless> or INTERNALS or what
[05:34] <lifeless> I don't know what the current intended sections are anymore
[05:34] <poolie> they're different things
[05:35] <poolie> how would having the headers help if you don't know what they mean? :-)
[05:35] <lifeless> I would have a menu
[05:35] <lifeless> all the headings are approximations anyhow; there was a thread about reducing them recently
[05:36] <lifeless> as it is I'm grovelling through the file to find what was used 'recently' and hoping its correct
[05:37] <poolie> anyhow
[05:37] <poolie> API breaks are things that will break plugins (etc) currently using the api
[05:37] <lifeless> poolie: uhm, I do know what an API BREAK is
[05:37] <poolie> INTERNALS similar but without implying the code will break - eg when it's deprecated
[05:38] <lifeless> poolie: but as far as I can tell we now call them 'api changes'
[05:38] <poolie> CHANGES are things that users need to know about - fe that there's a new format or a default has changed
[05:38]  * lifeless thinks poolie has missed lifeless' point
[05:38] <lifeless> I know what should be included under each header
[05:40] <poolie> you asked "do i use ... or what"
[05:41] <lifeless> poolie: there are N headers in used through NEWS
[05:41] <lifeless> and M < N that we have decided to use
[05:42] <lifeless> I need to determine which of the N headers are members of M to determine the menu that I have available to categorise my change.
[05:42] <lifeless> poolie: but this whole conversation is moot; I've stabbed in the dark and review can catch it. What I'd like is for us to always include all the sections when a new version is opened.
[05:59] <Peng_> That is usually done.
[05:59] <Peng_> It didn't always used to be, but I think it has for the last few releases.
[05:59] <lifeless> Peng_: define 'it' please
[06:00] <Peng_> :P
[06:00] <Peng_> Including all of the sections when adding a new version to NEWS.
[06:00] <lifeless> ah yes
[06:01] <poolie> i'll just do it now...
[06:01] <lifeless> poolie: thank you, I'd really appreciate that
[06:02] <Peng_> Oh, I don't think it has always been done recently.
[06:03] <Peng_> Or maybe annotate is just confused.
[06:04] <lifeless> Peng_: cat -r would be the easiest way to tell
[06:04] <lifeless> Peng_: annotate will be confused, because the headers are not unique
[06:04] <Peng_> I was gonna use annotate to see which -r to cat.
[06:08] <poolie> lifeless: i see a thread where I suggested creating the headings at the start of the release ;-)
[06:08] <poolie> i don't see any discussion of which headings should be there
[06:08] <poolie> um
[06:08] <lifeless> poolie: cool, consider this a + 1 :P
[06:08] <poolie> i just didn't do it
[06:08] <lifeless> poolie: I felt the previous conversation was angsty
[06:08] <lifeless> poolie: and I didn't mean for that
[06:08] <poolie> agree on both counts
[06:09] <poolie> anyhow..
[06:09] <poolie> i think the main point of them is so that people know how far through the file they ought to read - whether they're a user, a developer, etc
[06:10] <lifeless> poolie: the script I am writing, to autoupdate NEWS, can be simpler if it doesn't need to understand 'dev area' vs 'rest of file'
[06:10] <lifeless> poolie: that is, if it can just look for the first matching header
[06:10] <poolie> i'm saying that i do consider the ordering of headers to matter
[06:10] <poolie> they shouldn't just be alphabeticalized
[06:10] <lifeless> poolie: agreed, I don't think they should be either. I think the items should be alpha though
[06:11] <poolie> unless of course we add numeric prefixes or something to let that work
[06:11] <poolie> the items within each category, sure
[06:11] <lifeless> poolie: so my intent with the script is to never create headers
[06:11] <lifeless> poolie: which avoids the ordering of headers question
[06:11] <poolie> would it help if i made them more verbose, like "user-visible changes"?
[06:11] <lifeless> poolie: it might help readers
[06:11] <poolie> will there be no headers, or will they come from somewhere else?
[06:12] <lifeless> poolie: I want the headers to be seeded by the RM
[06:12] <poolie> i was also thinking of helping developers know where to put their news
[06:12] <poolie> ok
[06:12] <lifeless> poolie: then the script just inserts items under a header
[06:12] <poolie> how does the script know where to file them?
[06:12] <lifeless> the items will be (section, content) tuples
[06:15] <lifeless> so it just has to scan for the header matching section
[06:15] <lifeless> then scan for an item that comes after content, or the end of the section
[06:15] <lifeless> and insert there
[06:16] <poolie> lifeless, http://paste.ubuntu.com/56894/
[06:17] <lifeless> poolie: the remote change seems unrelated
[06:17] <poolie> it is
[06:18] <lifeless> poolie: the headers list is ok, I do feel we perhaps have too much granularity; but thats a separate discussion
[06:26] <lifeless> spiv: I haven't seen your patch to usertest; is it my eyesight?
[06:44] <poolie> meow
[07:02] <mlh>  jonoxer: you want setgid not sticky to preserve group
[07:02] <mlh> chmod g+s ...
[07:05] <jonoxer> mlh: oops, yes, corrected in my local copy (along with some other things about repo creation)
[07:07] <jonoxer> Thanks
[07:10] <vila> hi all
[07:16] <mlh> jonoxer: you may have this fxed too, but you'll need chmod -R g+wX MyRepo (note additional uppercase X meaning do x if x for user otherwise not)
[07:32] <lifeless> wow
[07:32] <lifeless> thats quite a difference
[07:32] <lifeless> real    0m5.555s
[07:32] <lifeless> real    0m3.006s
[07:32] <jonoxer> mlh: that sounds reasonable. I didn't need it (AFAIK only write privs matter in the repo, other than execute on dirs of course)
[07:36] <lifeless> poolie: I'm done for the day
[07:51] <Peng_> What's the 5.5 -> 3.0 second difference?
[07:52] <lifeless> see the list
[07:57] <Peng_> Oh! Cool. Thanks.
[08:05] <sabdfl> lifeless: is that split inventory work trunked?
[08:17] <mwhudson> sabdfl: no
[09:12] <lifeless> sabdfl: most of it isn't, its not suitable for trunk yet - still developing good answers and designs; every bit that is solid is in trunk or in review for trunk
[09:21] <poolie> hey vila, sabdfl
[09:25] <sabdfl> howdy
[11:02] <Kamping_Kaiser> hi all. i'm using bzr 1.5 on debian lenny, and its crashing trying to branch from launchpad. coudl someone look at this ( http://paste.debian.net/19120/ )and let me know if i should be filing a bug. (i see dbus/x11 errors, so itsprobably relevent that i'm trying to use it via ssh)
[11:07] <luks> Kamping_Kaiser: looks like the dbus plugin is broken, try to uninstall it
[11:11] <Kamping_Kaiser> luks: i'm trying it out, i'll let you know if it works
[11:11] <Kamping_Kaiser> i'll also try removing the gtk plugin
[11:11] <luks> that shouldn't be necessary
[11:11] <luks> just the dbus one
[11:13] <Kamping_Kaiser> luks: removing the dbus plugin makes the checkout work, thanks. i'll check debians bts
[11:19] <Kinnison> Anyone here use/work-on the loom plugin?
[11:20] <Kamping_Kaiser> luks: thanks for the help, i'll file a bug with debian - should i also file one in launchpad?
[11:21] <luks> Kamping_Kaiser: I don't know, it's likely it's already fixed in the latest version
[11:21] <Kamping_Kaiser> luks: roger.
[13:45] <gorgapor> although it's a know problem, can anyone suggest a workaround to the permissions issues with bazaar+sftp? right now we have a cron job going in and fixing the permissions every minute, which seems to me like an ugly hack
[13:46] <bob2> is using bzr+ssh an option?
[13:48] <gorgapor> well, all of our developers have ssh access to the server, is the setup on the client end any different?
[15:37] <james_w> jelmer: hey, there are a few duplicates of bug 271636 coming in from apport, do you know what the issue is going to be?
[18:34] <gour> hi, short question...how is bzr good in keeping binary files? (i'm thinking to put my wammu's with phonebook entries under vcs)
[19:42] <Peng_> gour: Sure, why not?
[19:43] <Peng_> gour: Remember that compressed formats like JPEG won't compress well and may delta badly, so you might waste some disk space, but it's not like anything will explode.
[21:40] <arjenAU> hmm
[21:41] <arjenAU> adding a tag on its own is not regarded as a change?
[21:41] <arjenAU> had to to commit --unchanged to get it pushed
[21:47] <jam> arjenAU: I think doing "bzr push" will push it anyway, even though it says "nothing to push"
[21:47] <arjenAU> jam: look that's not shiny ;-)
[21:47] <arjenAU> so I just made an empty commit for it. but that's not pretty either
[21:52] <Peng_> Yeah, new tags will be pushed even if it says "Nothing to push".
[21:52] <Peng_> Tags are unversioned, and pushing/pulling them is a bit messy.
[21:52] <Peng_> IMO, they feel rather tacked on.
[22:21] <lifeless> jam: ping
[22:21] <lifeless> jam: I wonder if you saw my repository stats mail; I know you have been doing repo size analysis ..
[22:22] <arjenAU> Peng_: well here's the thing. while launchpad recommends branching for a release, it's actually just as sane to tag it. thats actually how mysql used to do it with bitkeeper and it works very well. easy to find, easy to use.
[22:33] <lifeless> poolie: I've stopped the usertest run that was going... 7.5G    work_root_for-bzr.inv-branchAndFix
[22:33] <lifeless> I'll either have a faster fetch up today, or remove the 'inv' flavoured tool for now
[22:33] <poolie> hey lifeless
[22:34] <poolie> do you want to reenable the cronjob?  i put in a mutex
[22:34] <lifeless> great, doing so
[22:34] <lifeless> will they backlog or just exit early?
[22:34] <lifeless> [crontab reenabled]
[22:49] <jam> lifeless: my analysis was done by looking at the output of -Dhpss and determining how many bytes were transferred after .iix, not exactly what you are looking for
[22:50] <lifeless> jam: oh! ok
[23:22] <mlh> what's a PPA?
[23:23] <beuno> personal package archive
[23:23] <beuno> archive for .deb files
[23:23] <beuno> which Launchpad provides
[23:24] <mlh> thanks beuno
[23:24] <beuno> :)


[05:24] <AuroraAvenue> err, and where was the canonical badge ?
[05:25] <AuroraAvenue> https://twitter.com/theleaddev/status/1012362857617481733
[06:53] <AuroraAvenue> #random https://www.amazon.com/gp/offer-listing/0749452633/


[01:35]  * penguin42 comes to the conclusion Evri have just stopped delivering here
[12:44]  * zxmpi breaks out the last of the crimbo jaffa cakes
[12:45] <daftykins> :O
[12:46] <daftykins> they will lay down their lives for a worthy sacrifice
[13:01] <zxmpi> now pondering whether supervalu, tescos, aldi or lidl shall win the bid to replace them
[13:03] <daftykins> hmm sounds like you need penguin42's price tracking to extend its' coverage to Ireland! :D
[13:03] <penguin42> I dunno, perhaps zxmpi needs wholesale levels
[13:04] <daftykins> could be, he might begin to act as international broker to davef
[13:04] <daftykins> lots of money to be made there
[13:05] <zxmpi> ::listens to lawyer whispering in my ear:: there's no jaffa smuggling opertation here
[13:08] <zxmpi> and i'll airdrop a tonne of jaffa cakes on the person who keeps making these acqusations if i ever find them
[13:10] <daftykins> death by jaffa-airdrop!
[13:11] <zxmpi> do it enough times and davef will be at the scene of all the crimes and get blamed :-P
[13:17] <davef> 🤨
[13:18] <daftykins> *ahem* alleged crimes
[13:18] <daftykins> ooh a bit of rain for a change
[13:19] <daftykins> but still below average they say! http://water.gg/waterstoragegraph
[13:20] <zxmpi> ireland has caught up on the rainfall average after a dry spell
[13:23] <daftykins> just noticed my water co. doesn't do TLS, shocking!
[13:25] <daftykins> and my electric co. deleted their non-www A record, not the first time either o0
[13:26] <zxmpi> the internet is a series of tubes and they know their tubes :-P
[13:50] <daftykins> i like the animated characters on the Guernsey Water vans, featuring for example "Fiona Fatberg"
[14:08] <zxmpi> sounds like a fun bunch, do they have timothy typhus? :-P
[14:10] <daftykins> haha, i will have to check!
[14:14] <zxmpi> and of courseand they should have a tribute to the birmingham lion :-P https://www.bbc.com/news/uk-england-39799098
[14:16] <daftykins> wowzer
[14:20] <zxmpi> just so you remember the chance of been mauled to death on the toilet by a lion is low but never 0 :-)
[14:22] <daftykins> if you'd have told me that in the pub without evidence, i'd have thought you were... Lion
[14:25] <zxmpi> it's the tooth
[14:27] <daftykins> :D
[15:01] <davef> So when can I expect the first airdrop?
[15:03] <zxmpi> arranging a lease on santas sleigh now it's finished it's yearly run
[15:04] <daftykins> my advice, don't kick the tires
[15:07] <davef> We want to be sure that the airdrop will function as expected for the next run. Therefore we must perform a number of dry runs with actual product so we can test and to make sure it drops without a hitch on the day.
[15:08] <zxmpi> that's easy, just use the unused coal still in the sleigh for a strafing run
[15:08] <daftykins> sign me up for an early short-haul test run, i will be sure to verify the product
[15:09] <davef> No, it has to be actual product. Real jaffa cakes. The parachute must be properly calibrated.
[15:09] <daftykins> i concur
[15:10] <zxmpi> i never mentioned parachutes...
[15:11] <daftykins> you're going to just let those poor jaffas fall to their deaths? D:
[15:11] <zxmpi> i was aiming for there to be something soft on the ground to break their fall
[15:12] <daftykins> oh yeah like a Brit expat
[15:12] <zxmpi> can you think of anything softer? :-P
[15:14] <daftykins> hmm...
[15:16] <davef> https://usercontent.irccloud-cdn.com/file/T9utEa0I/WaitWhatSomethingsNotRightGIF.gif
[15:27] <zxmpi> you could use the inherent aerodynamicness of jaffa cakes to make a jaffa launching cannon...
[15:28] <penguin42> they'd make good flying suacers
[15:28] <zxmpi> discs of dooooom
[15:29] <penguin42> transmitting beams of orange power
[15:50] <zxmpi> i was thinking kinetic shrapnel but ok...
[21:49] <zxmpi> jaffa cake stash at 50%
[21:50] <daftykins> at least those Dublin orphans are getting a good education in the phases of the moon
[21:58] <zxmpi> even the poorest orphan in ireland has access to jaffa cakes. we are a civilised land...


[00:15] <Capum321> hello how to install book antiqua and garamond fonts?
[00:26] <Capum321> is book antiqua / garamond proprietary fonts? does the free downloadable ttf files would come with embedded bad bitmaps?
[19:54] <romsin> hello
[21:34] <LuMint> hi


[10:15] -queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3534 Needs rebuild due to higher version at destination (focal/ceph). Pending binary packages (focal/openvswitch)
[10:23] -queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2162 Needs rebuild due to higher version at destination (zesty/aethercast). Ready to build (/:, /: Failed to update local lp:aethercast cache., xenial/Failed, xenial/cache., xenial/isc-dhcp, xenial/local, xenial/lp:aethercast, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/isc-dhcp, zesty/local, zesty/lp:aethercast, zesty/to, zesty/update). Successfully built (xenial/aethercast)
[10:34] -queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2393 Failed to build (xenial/aethercast). Needs rebuild due to higher version at destination (zesty/aethercast). Ready to build (/:, /: Failed to update local lp:aethercast cache., xenial/Failed, xenial/cache., xenial/local, xenial/lp:aethercast, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/local, zesty/lp:aethercast, zesty/to, zesty/update)
[10:43] -queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2162 Needs rebuild due to new commits (zesty/aethercast). Ready to build (/:, xenial/Failed, xenial/cache., xenial/isc-dhcp, xenial/local, xenial/lp:aethercast, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/isc-dhcp, zesty/local, zesty/lp:aethercast, zesty/to, zesty/update). Successfully built (xenial/aethercast)
[10:54] -queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2393 Failed to build (xenial/aethercast). Needs rebuild due to new commits (zesty/aethercast). Ready to build (/:, xenial/Failed, xenial/cache., xenial/local, xenial/lp:aethercast, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/local, zesty/lp:aethercast, zesty/to, zesty/update)
[10:54] -queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3534 Needs rebuild due to higher version at destination
[12:34] -queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2393 Failed to build (xenial/aethercast). Needs rebuild due to higher version at destination (zesty/aethercast). Ready to build (/:, /: Failed to update local lp:aethercast cache., xenial/Failed, xenial/cache., xenial/local, xenial/lp:aethercast, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/local, zesty/lp:aethercast, zesty/to, zesty/update)
[12:38] -queuebot:#ubuntu-ci-eng- andyrock, https://bileto.ubuntu.com/#/ticket/3658 Failed to build (disco/nux). Ready to build (/:, /: Failed to update local lp:nux cache., disco/Failed, disco/cache., disco/local, disco/lp:nux, disco/to, disco/update)
[12:42] -queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2162 Needs rebuild due to higher version at destination (zesty/aethercast). Ready to build (/:, /: Failed to update local lp:aethercast cache., xenial/Failed, xenial/cache., xenial/isc-dhcp, xenial/local, xenial/lp:aethercast, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/isc-dhcp, zesty/local, zesty/lp:aethercast, zesty/to, zesty/update). Successfully built (xenial/aethercast)
[12:59] -queuebot:#ubuntu-ci-eng- andyrock, https://bileto.ubuntu.com/#/ticket/3658 Failed to build (disco/nux). Ready to build (/:, disco/Failed, disco/cache., disco/local, disco/lp:nux, disco/to, disco/update)
[13:03] -queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2162 Needs rebuild due to new commits (zesty/aethercast). Ready to build (/:, xenial/Failed, xenial/cache., xenial/isc-dhcp, xenial/local, xenial/lp:aethercast, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/isc-dhcp, zesty/local, zesty/lp:aethercast, zesty/to, zesty/update). Successfully built (xenial/aethercast)
[13:15] -queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2393 Failed to build (xenial/aethercast). Needs rebuild due to new commits (zesty/aethercast). Ready to build (/:, xenial/Failed, xenial/cache., xenial/local, xenial/lp:aethercast, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/local, zesty/lp:aethercast, zesty/to, zesty/update)
[15:14] -queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3534 Needs rebuild due to higher version at destination (focal/ceph). Ready to build (focal/openvswitch)