[04:07] <Mirv> rsalveti: I really just package it, I haven't looked at the code (qtsystems). Renato was working on qtpim, not qtsystems, so I think there isn't anyone truly familiar with it.
[04:12] <rsalveti> Mirv: right, no worries, I can take a better look once this multimedia stack lands
[05:50] <ScottK> ^^^ security fix.
[06:09] <slangasek> ScottK: do you need someone to review it, then?
[06:09] <ScottK> Yes.  Review/accept since it's my uplaod.
[06:10] <ScottK> It's closely based on what the security team did for precise where the package is in Main.
[06:11]  * ScottK sleeps (since the alarm goes off in < 3 hours).
[06:14] <slangasek> accepted
[07:00] <infinity> slangasek: Gold star for the insighttoolkit
[07:00] <infinity> ... upload
[07:17] <slangasek> infinity: I'm sure I don't know what you're talking about; it's the middle of the night and I'm asleep
[07:17] <infinity> slangasek: Are you claiming the NSA backdoored your PGP key?
[07:17] <infinity> slangasek: (... and used that backdoor to fix bugs in... Ubuntu?)
[07:18] <slangasek> no, merely suggesting that you're asleep
[07:18] <slangasek> and dreaming
[07:18] <infinity> I'm neither elated, confused, or terrified, I can't be dreaming.
[07:18] <slangasek> and while the dream me is flattered to be included, this is probably not healthy
[07:20] <slangasek> ok, off to bed. 'night. :)
[07:21] <infinity> slangasek: Toodles.
[08:27] <sgran> is this the right place to ask questions about the cloud-archive?
[08:27] <sgran> I expect not, but I can't find a link to an IRC channel
[08:35] <smartboyhw> Ubuntu Release Team: I'm not understanding something. After UIF and DocStringFreeze we are supposed to send emails to ubuntu-doc and ubuntu-translators right? I didn't see any of these e-mails sent to these mailing lists, and I don't believe there has been uploads without UI changes in the past few days
[08:40] <smartboyhw> s/has been uploads without UI changes/all uploads are without UI changes/
[08:40] <Laney> if you have an example, please raise it
[08:42] <xnox> smartboyhw: do note, e.g. packages on ubuntu touch images have a standing exception, so those do still change.
[08:42] <smartboyhw> xnox, I know
[08:45] <smartboyhw> Laney, I don't know if I'm correct, but I saw gnomeradio having icons removed (does that deserve a UIF?)
[08:46] <Laney> it's not installed by default, so no
[08:46] <smartboyhw> Um, - Added option to disable audio loopback mode in Preferences settings. looks like a much better one
[08:46] <smartboyhw> Laney, ^
[08:46] <Laney> which package?
[08:47] <smartboyhw> Laney, gnomeradio
[08:47] <Laney> not installed by default: not covered by UIF
[08:47] <Laney> https://wiki.ubuntu.com/UserInterfaceFreeze
[08:47] <smartboyhw> Hmm
[08:48] <xnox> smartboyhw: typically UIFe are for things which have screenshots in documentation from default installs (ubuntu, edubuntu, xubuntu, lubuntu, kubuntu, etc) which blindly rewrite complete UI and thus confusing help / documentation readers. But minor tweaks and bugfixes are ok, "e.g. remove broken button" and etc.
[08:48]  * smartboyhw needs to check something then
[08:48] <smartboyhw> Hmm, I might not need a UIFe then
[08:49] <smartboyhw> xnox, any good tools to check if one package is in the seeds/metas?
[08:49] <smartboyhw> (all of them)
[08:50] <cjwatson> seeded-in-ubuntu
[08:51] <smartboyhw> Default install != supported (I believe). Yeah, no need UIFe:P
[08:51] <smartboyhw> (supported seeds)
[09:00] <cjwatson> sgran: #ubuntu-server would probably know more - the cloud archive is a kind of bolt-on thing and the release team proper doesn't run it
[09:06] <sgran> cjwatson: thanks, I'll ask there
[09:26] <ScottK> slangasek: Thanks.
[10:23] <doko> infinity, the mpfr issue is a wrong-code issue. in th works ...
[10:24] <Riddell> kde 4.11.2 going up, here comes the flood
[10:24] <Laney> queue mute #ubuntu-release
[10:25] <Laney> worth a go
[10:25] <Laney> queue mute unapproved #ubuntu-release
[10:25]  * Laney goes away
[10:25] <cjwatson> Hm, better rebalance i386/amd64 builders then
[10:26] <cjwatson> (done)
[10:27] <Riddell> cjwatson: why the need for a rebalance and what elite powers enable you to do that?
[10:27] <infinity> doko: Awesome, thanks.
[10:27] <infinity> Riddell: We had all but one builder on i386 to finish the test rebuild.
[10:27] <cjwatson> Riddell: we had 7 i386 / 1 amd64 in order to try to finish the test rebuild faster
[10:27] <cjwatson> Riddell: powers> ~launchpad-buildd-admins
[10:27] <cjwatson> Riddell: this is all a workaround for not having cross-architecture builder pooling in LP, though
[10:28]  * Riddell learns new things
[10:28] <infinity> I think I'll work on fixing that around release week, or the week after.
[10:29] <cjwatson> The main thing I can't quite work out is how to calculate/represent queue lengths with pooled builders
[10:29] <cjwatson> Since the queues would no longer be per-architecture, and would sort of overlap in complicated ways
[10:29] <infinity> cjwatson: Queue lengths shouldn't be hard to estimate, it's just the general potential uglification of /builders I haven't quite figured out how to deal with.
[10:30] <cjwatson> I think the processor column has to just become a list of architectures per builder, but I have no idea how to adjust the "build status" sections
[10:31] <cjwatson> The actual dispatch bit is easy enough ...
[10:32] <infinity> cjwatson: The queue status, you mean?  That should still be per-arch.  I don't see it changing much, except that the number of builders per arch will go up, as it'll account for every builder that can build that arch.
[10:32] <infinity> cjwatson: The math to sort out the actual queue time isn't rocket surgery and shouldn't lead to results that are any more of a lie than the current lies.
[10:32] <cjwatson> infinity: But if we have 8 builders that can do either i386 or amd64, saying "amd64 8; i386 8" is grossly misleading
[10:32] <cjwatson> infinity: Even worse for the PPA case where (IIRC) some of the builders can do i386 amd64 and some can do i386 amd64 armhf
[10:33] <infinity> cjwatson: Nah, it's true.  There are 8 builders capable of building that arch.
[10:33] <infinity> cjwatson: Also, all the PPA machines are x86_64 now.
[10:33] <infinity> cjwatson: Pretty sure I checked that last time this came up.
[10:33] <cjwatson> Yeah, but I think only the multi-guest ones can do armhf
[10:33] <cjwatson> It may be true, but I think it needs some refinement to be intelligible
[10:33] <infinity> cjwatson: Nope, everything can do armhf.  It's built into lp-buildd (well, if the qemu-user-static bits are installed)
[10:34] <infinity> That doesn't mean we want to allow all of them to do it, mind you.
[10:34] <cjwatson> And are they installed everywhere?  I thought I understood from wgrant that that wasn't true.
[10:34] <cjwatson> Right, so whether it's policy or capability, the effect is the same
[10:34] <infinity> cjwatson: Not sure if everything has qemu-user-static installed, but that's easy to fix if that's the result we want.
[10:35] <infinity> cjwatson: Anyhow, I'm okay with the reporting of "builders that are allowed to build this arch", even if it has overlap.  And calculating potential queue depth from there is not particularly hard, with a bit of fudging.  And that algorithm is all about fudging already.
[10:35] <cjwatson> I think I'd prefer a refactored build status table, separating "number of builders" from "queue length"
[10:35] <cjwatson> Perhaps
[10:36] <cjwatson> Or perhaps with some indication of how many builders are shared
[10:36] <cjwatson> Something like that ...
[10:36] <infinity> Well, we can redesign the page whenever.  That's less interesting than doing the pooling and making the queue not be completely inaccurate.
[10:37] <infinity> The dispatch bit is ridiculously easy, since build records already come out in the order we want them.
[10:37] <cjwatson> I wonder if that's actually true
[10:37] <infinity> cjwatson: It is in all cases except a missing build created post-upload.
[10:37] <cjwatson> Are we sure that, given long i386 and amd64 queues, it wouldn't do all of one architecture first and then the other?
[10:37] <cjwatson> There's nothing today that would prove that one way or another
[10:38] <infinity> cjwatson: But on a fresh upload, when 5 builds are created, the records are sequential (or close enough) and have the same score.
[10:38] <infinity> cjwatson: So, if you use the score and the ID, you can get them out in the order that's sane.  Score alone isn't enough.
[10:38] <cjwatson> If it's score then id, or similar, then fine
[10:39] <cjwatson>         order_clause = " ORDER BY buildqueue.lastscore DESC, buildqueue.id"
[10:39] <cjwatson> Yeah, that looks OK
[10:40] <infinity> cjwatson: It actually has the curious side-effect, if dispatched correctly, to fix arch skew issues that you have on mismatches builder pools.
[10:40] <infinity> cjwatson: Cause all arches should always dispatch for the same source at almost the same time on pooled arches.
[10:41] <cjwatson> Well, in that case the work is something like (a) add many-to-many builder/processor DB table (b) add model/browser code to represent that and let us edit it in the API/UI (c) populate production data (d) change dispatch code and /builders to look at many-to-many table rather than single-processor mapping (e) clean up old DB bits at leisure
[10:41] <cjwatson> infinity: Yeah
[10:42] <cjwatson> I guess I'm spending today retrying KDE dep-waits in the right order
[10:42] <infinity> Someone should have muted queuebot.
[10:43] <cjwatson> At least the ones that aren't automatically determined
[10:43] <Laney> I tried and floundered
[10:43] <Laney> there's still time if you know the syntax
[10:44] <cjwatson> mute queue saucy-proposed
[10:44] <infinity> Hah, Google just got me there.  2 seconds late.
[10:45] <infinity> doko: How long did the full rebuild test take on armhf?
[10:46] <infinity> (Not counting esys-particle)
[10:46] <infinity> I need to patch that to build a -data/-common/whatever package and put all those images in it.  Crazy build times.
[10:47] <cjwatson> Or NO_PNG_PKG_MANGLE=1 if it doesn't make much size difference
[10:48] <infinity> Oh, or that, even if it does. :P
[10:48] <cjwatson> Well, if it does, optimise things statically first
[10:48] <infinity> But duplicating all that data in every arch:any package is Wrong(tm) anyway.
[10:48] <cjwatson> Not that I care that much since it isn't on images
[10:48] <infinity> A proper patch submitted to Debian seems saner.
[10:49] <cjwatson> Yeah
[10:49] <infinity> esys-particle_2.2.u1-2_armhf.deb (200.4 MiB)
[10:49] <infinity> It ain't tiny.
[10:49] <cjwatson> Hah
[10:49] <infinity> Curious how much the png optimisation saves.
[10:51]  * infinity grabs the source and tries a no-mangly build.
[10:51] <cjwatson> Riddell: What are the deepest bits of the build-dep chain here, and I'll accept them first?
[10:51] <infinity> kdelibs, usually.
[10:51] <cjwatson> It'd save a lot of time not to have to go round retrying things later because Kubuntu people never do :-P
[10:51] <cjwatson> infinity: IME there are several, though
[10:52] <infinity> cjwatson: kdelibs, kdepimlibs, kde-runtime are the ones I recall.
[10:52] <cjwatson> all the kdepim stuff, kde-workspace - I just don't know the ordering
[10:53] <infinity> And I don't actually see a kdelibs upload...
[10:53] <infinity> Well, kde4libs.
[10:53] <infinity> Ahh, cause it was done 18h ago.
[10:54] <infinity> Yay for that.
[10:54] <cjwatson> So kdepimlibs is probably pretty much at the bottom
[10:55] <cjwatson> Oh, there's akonadi, soprano, nepomuk in those build-deps
[10:56]  * cjwatson goes for nepomuk-core first
[10:57] <Riddell> cjwatson: I already accepted them
[10:58] <Riddell> https://wiki.kubuntu.org/Kubuntu/Ninjas/DependencyGraph for the gory details
[10:58] <Riddell> a widescreen monitor helps with that one
[10:59] <cjwatson> Ah
[11:00] <cjwatson> Well, let me know if there's anything you particularly don't want accepted early
[11:00] <cjwatson> w/g 23
[11:00] <cjwatson> oops
[11:16] <cjwatson> infinity: I tried a full britney analysis run on universe, which has now been running for 14 hours (and there's no way to tell how far it's got).    It really shouldn't take that long to run, I'd think?
[11:21] <doko> infinity, didn't look that close. below one week
[11:21] <infinity> cjwatson: Did you try on just a single arch first?
[11:21] <cjwatson> No
[11:21] <cjwatson> Not sure I believe time's output
[11:21] <cjwatson> real    849m23.490s
[11:21] <cjwatson> user    0m1.236s
[11:21] <cjwatson> sys     0m0.200s
[11:21] <cjwatson> It was sitting at 100% CPU for most of that time
[11:22] <infinity> doko: Hrm.  Kay.  I might still try to get a glibc 2.18 done this week, then, and we could do an armhf-only rebuild to see if there are any obvious regressions.
[11:22] <cjwatson> infinity: I probably need to rebase that britney instance on top of the one in proposed-migration, which has Debian's performance work
[11:22] <infinity> doko: Sadly, there are glibc testsuite regressions on 2.18 on armhf that I'd like to try to sort.  Not sure if they'll bubble through to packages, though.
[11:22] <cjwatson> infinity: But, easier approach: just get proposed-migration to dump out a list of uninstallables as well as the count
[11:22] <cjwatson> It already has that information to hand
[11:25] <infinity> cjwatson: Oh sure, that wouldn't be a bad start.  If we clean that up, maybe your full run won't take 17 days. :P
[11:25] <cjwatson> Hm, in fact it seems to have an option for that already
[11:26] <infinity> cjwatson: So, if you're curious, a non-mangled esys-particle is about 60MB larger.  And builds in 26 minutes instead of 8 hours on x86.
[11:26] <infinity> Probably worth doing the split and submitting to Debian.
[11:26] <cjwatson> Mm, yeah, and probably worth optimising the PNGs statically then
[11:26] <infinity> Eating one x86 buildd for 8 hours is alright.  Eating one on every arch hurts.
[11:26] <infinity> (Or pre-optimising in the source, sure)
[11:27] <cjwatson> So, most of the uninstallables are because britney doesn't understand udebs
[11:27] <infinity> cjwatson: She doesn't?  In what sense?
[11:27] <cjwatson> Claims they're uninstallable
[11:28] <cjwatson> I don't know exactly why but this tallies with mutterings I've heard from the Debian release team :)
[11:29] <cjwatson> The uninstallables report takes an extra 30 seconds to generate, but I think that's acceptable :)
[11:29] <infinity> The udeb thing shouldn't be that hard to solve, one would think?
[11:30] <cjwatson> (And it doesn't block promotion)
[11:30] <cjwatson> infinity: Probably not
[11:30] <infinity> It is because there are some base deps provided by the d-i initrd that britney just doesn't know about?
[11:30] <infinity> I mean, ultimately, they're just debs.
[11:30] <infinity> Just really sketchy ones.
[11:31] <cjwatson> It probably needs the same algorithms germinate has to follow dependencies in the right world
[11:31] <infinity> I like how they're almost the inverse of click packages, in the sense that many udebs are nothing BUT maintainer scripts with complex dependencies.
[11:33] <cjwatson> infinity: http://people.canonical.com/~ubuntu-archive/proposed-migration/saucy_uninst.txt
[11:34] <cjwatson> I'll see if I can work out the udeb thing - it might just be a matter of inserting faux packages
[11:34] <infinity> And the very top of the list is something that should be arch-restricted.
[11:34] <cjwatson> It's Architecture: all
[11:35] <infinity> Yes, I know.  I'm arguing it probably shouldn't be.
[11:35] <cjwatson> There'll probably be several of those showing up on i386
[11:35] <cjwatson> Yeah, perhaps
[11:35] <infinity> Sadly, the crossbuild stuff fails due to britney not groking multiarch.
[11:35] <infinity> And wine is in that camp too, IIRC.
[11:36] <infinity> Overall, though, this isn't as bad as I thought it would look.
[11:36] <cjwatson> The udeb things might actually come down to incorrect kernel Provides
[11:36] <infinity> I thought we'd mostly fixed the kernel provides issues?
[11:36] <cjwatson> Ahaha no not for udebs
[11:36] <infinity> Cause when they go wrong, component-mismatches has a hissy fit and tries promoting random universe kernels.
[11:37] <cjwatson> kernel-image-BLAH is meant to provide FOO-modules for the various things that would be in *-modules-BLAH but are actually built in
[11:37] <cjwatson> But the Ubuntu kernel team has never got this right
[11:37] <infinity> apw: ^
[11:37] <infinity> I know someone who'd be happy to get it less wrong. :P
[11:38] <cjwatson> I wonder if I can figure out the proper list
[11:38] <cjwatson> (Please wait a week while I update my saucy kernel remote :P)
[11:38] <infinity> Anyhow, a good chunk of this goes away when we clean up the last of NBS.
[11:38] <cjwatson> Yep
[11:38] <infinity> And the udebs things are mentally filterable.
[11:38] <infinity> All in all, it's way less ugly than I thought it would be.
[11:40] <apw> infinity, i am listening
[11:40] <cjwatson> I can certainly work on cleaning some of this up
[11:40] <infinity> apw: The two lines above where I paged you. :)
[11:40] <apw> and yes if there is something linux-image-foo.udeb should be providing to make your life easier we can do that
[11:40] <cjwatson> kernel-image-foo.udeb but yeah
[11:40] <cjwatson> I'll hopefully be able to come up with a patch shortly ...
[11:41] <apw> so i assume that is any udeb which becomes empty, we should provide ... ish
[11:41] <apw> cjwatson, well i am in testing mode for various things, so now is a very good time
[11:41] <cjwatson> Anything that's depended on by other udebs and that is built in
[11:41] <cjwatson> In practice, mostly filesystems
[11:42] <cjwatson> That's very probably what all the partman-* output there is for, along with all the other stuff that's in stages of d-i after partitioning
[11:42] <cjwatson> Since they tend to depend on (virtual package meaning that partman is done)
[11:42] <apw> we have typically not understood the udebs relationship to d-i well enough, and made a hash of it as a result
[11:42] <cjwatson> I'm at 11% of "git remote update saucy" :)
[11:43] <apw> this is a good time to repair that and once done to get some knowledge transfer into the team to keep it fixed
[11:43] <cjwatson> So, here's my logic
[11:43] <apw> in the good-old-days (tm) i would have suggested a bar session at UDS for this
[11:43] <cjwatson> view http://archive.ubuntu.com/ubuntu/dists/saucy/main/debian-installer/binary-i386/Packages.gz
[11:43] <cjwatson> After a bit of "what's the underlying problem" you get to (say) partman-basicfilesystems
[11:43] <cjwatson> Depends: cdebconf-udeb, dosfstools-udeb, e2fsprogs-udeb, ext2-modules, fat-modules, partconf-mkfstab (>= 1.09)
[11:44] <infinity> And nothing provides ext2-modules, fat-modules, and the world explodes?
[11:44] <cjwatson> cdebconf-udeb, dosfstools-udeb, e2fsprogs-udeb, partconf-mkfstab are real packages not listed as uninstallable
[11:45] <cjwatson> fat-modules-3.11.0-9-generic-di Provides: fat-modules
[11:45] <cjwatson> But nothing Provides: ext2-modules
[11:45] <infinity> Oh, fat's not built in?
[11:45] <cjwatson> Not on i386 anyway
[11:45] <cjwatson> Maybe on other architectures - the kernel-wedge framework has plenty of provision for this being arch-specific
[11:45] <apw> infinity, on arm probabally but here not so much
[11:45] <cjwatson> ext2 is probably built into the kernel, and the way you tell d-i this is by having kernel-image Provides: ext2-modules
[11:46] <cjwatson> Similar to the way that fs-core-modules Provides: *-modules for the filesystems it builds
[11:46] <cjwatson> d-i has probably actually been warning about this for ages but it hasn't mattered so much
[11:46] <infinity> Hah, no.  fat-modules-udeb exists solely to ship msdos.ko, I think.
[11:46]  * apw wonders if the d-i logs have the info one needs to fix and validate soame
[11:46] <cjwatson> But if we can get it consistent then we can make proposed-migration have better behaviour - it could enforce that we don't accidentally make udebs uninstallable
[11:47] <infinity> The rest (fat, vfat, etc) are built in.
[11:47] <cjwatson> infinity: Mm, well, I think that can stay as it is
[11:47] <cjwatson> apw: http://people.canonical.com/~ubuntu-archive/proposed-migration/saucy_uninst.txt should be enough
[11:47] <cjwatson> That's where I'm starting here
[11:47] <infinity> cjwatson: I think that's just a happy accident of poor configs. :)
[11:48] <apw> infinity, doesn't that mean there is someting other than fat in that udeb so that it actually still exists
[11:48] <cjwatson> apw: Right, msdos.ko
[11:48] <infinity> apw: Yeah, like I said, msdos... What he said.
[11:48] <cjwatson> There are probably a few other similar cases; I see efi-modules in a similar situation
[11:49] <apw> so you would make britney check udebs as well, and then we would be unable to break it again
[11:49] <cjwatson> Just trawling
[11:49] <cjwatson> apw: It actually does right now - I think I was mistaken in saying it didn't
[11:49] <infinity> It's just that it's allowing things to be "as broken as before" (which is what it always does), so if it's always been broken...
[11:49] <cjwatson> Right
[11:50] <cjwatson> This has been broken since before proposed-migration existed, and so was grandfathered
[11:50] <apw> heh ok perfect
[11:50] <infinity> But if we reach the goal of making the whole archive installable, and then hit people with large sticks when they try to force things in, britney can do its job much better.
[11:50] <apw> works for me, i don't like being an outlier, which is why we now have the lists of udebs udebs and the like
[11:51] <apw> i am all for sanity
[11:51] <cjwatson> I plan to spend a bunch of the rest of the cycle analysing and zeroing all this
[11:52] <apw> cjwatson, so are you doing these udebs for me, or do you awnt me to
[11:52] <cjwatson> I'll come up with something
[11:52] <apw> ack
[11:52] <cjwatson> Since I'll need to do the analysis anyway, I guess :)
[11:52] <cjwatson> It's kind of a pain to expect anyone else to do
[11:52] <infinity> There should probably be some automated way of doing it.
[11:52] <apw> i was wondering the same
[11:53] <infinity> If we know all the udebs we could produce, and know all the udebs we did produce.
[11:53] <apw> presumable i can look at the Depends in this package-list
[11:53] <cjwatson> Meh, analyse once and it'll be way easier from then on
[11:53] <cjwatson> Won't take that long
[11:53] <apw> and for those which arn't in the list, and arn't packages in saucy, fail
[11:53] <infinity> Though, that assumes that all the ones we didn't produce are built-in, rather than a victim of anemic configs that lack features.
[11:53] <cjwatson> I'll check for that
[11:54] <apw> well when cjwatson sends me over a patch for the missing one, i can check, or ... he can do everything and i can get a coffee
[11:54] <cjwatson> I used to help maintain the kernel udeb handling in Debian, it's no harder :)
[11:54] <infinity> apw: Get me one too.  I think I've given up on sleep tonight being a thing.
[11:54] <apw> heh, i bet we make it harder
[11:56] <cjwatson> Other problems not mentioned above: btrfs-modules, crypto-dm-modules, ext3-modules, ext4-modules, ufs-modules
[11:56] <cjwatson> I think that's the lot
[12:53] <cjwatson> Not all of KDE is through, but the bulk is, so unmuting
[12:53] <cjwatson> unmute queue saucy-proposed
[12:57] <Riddell> thanks cjwatson
[13:24] <cjwatson> apw: I think http://paste.ubuntu.com/6179577/ would be a fine start
[13:24] <cjwatson> apw: I expect the ARM and PowerPC variants would need something similar
[13:29] <apw> cjwatson, ok are you sending a patch or shall i suck that in from the pastebin
[13:29] <cjwatson> kernel-team@ is it still?
[13:30] <apw> cjwatson, yep thats the one
[13:33] <cjwatson> apw: https://lists.ubuntu.com/archives/kernel-team/2013-October/033011.html
[13:34] <cjwatson> apw: Er, sending a followup
[13:34] <cjwatson> apw: Should be correct with the typo fix in https://lists.ubuntu.com/archives/kernel-team/2013-October/033012.html
[13:35] <cjwatson> (I can send a new patch if you need it)
[13:35] <apw> cjwatson, na i can wangle it out
[13:35] <cjwatson> ta
[13:47] <cjwatson> Urgh, proposed-migration is crashing.  Looking into it.
[13:47] <cjwatson> Should be happier once kcron builds, so I've just scored that up ...
[13:47] <cjwatson> kcron/i386 that is
[13:48] <cjwatson> Though maybe I can fix it otherwise ...
[13:52] <didrocks> can we get someone looking at mir? we would need it for image build #75? (it's in the unapproved queue)
[13:52] <didrocks> tested on desktop and touch
[13:53]  * didrocks wonders why unity-mir is blocked though in update_output.txt, no trace of success
[13:53] <stgraber> didrocks: I'll do queue reviews once I'm 1) done with the current issue 2) actually awake ;)
[13:53] <didrocks> (there is no new dependency, unity-mir should be enough on its own)
[13:53] <didrocks> stgraber: thanks!
[13:54] <cjwatson> didrocks: It seems quite clear why it's blocked
[13:54] <cjwatson>     * i386: indicators-client, libunity-mir-dev, libunity-mir1, unity8, unity8-autopilot
[13:54] <cjwatson>  libunity-mir1 : Depends: libmirserver4 (>= 0.0.12+13.10.20131001) but 0.0.12+13.10.20130926.1-0ubuntu1 is to be installed
[13:55] <cjwatson> Which is presumably because it needs the new mir
[13:55]  * infinity looks at the new mir.
[13:55] <didrocks> cjwatson: this is in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt?
[13:55] <cjwatson> Yes
[13:55]  * cjwatson fixes the proposed-migration crash
[13:55]  * didrocks doesn't see libunity-mir1 : Depends: libmirserver4 (>= 0.0.12+13.10.20131001)…
[13:55] <cjwatson> didrocks: The first line is in update_output.txt
[13:55] <infinity> didrocks: That's from him trying to install it.
[13:56] <cjwatson> didrocks: The second line was from "chdist apt-get saucy-proposed-i386 install libunity-mir1" as ubuntu-archive@snakefruit
[13:56] <didrocks> cjwatson: ah, so it's not clear from update_output.txt, you need to try to chdist it, ok :)
[13:57] <didrocks> Mirv told me there was no ABI break though…
[13:57] <cjwatson> It tells you that that package is uninstallable, just not exactly why
[13:57] <infinity> +  [ Michael Terry ]
[13:57] <infinity> +  * merge latest dev branch.
[13:57] <infinity> +
[13:57] <infinity> +  [ Kevin DuBois ]
[13:57] <infinity> +  * merge latest dev branch.
[13:57] <infinity> +
[13:57] <cjwatson> For that matter sometimes apt takes some persuasion to tell you exactly why
[13:57] <infinity> +  [ Daniel d'Andrada ]
[13:57] <infinity> +  * merge latest dev branch.
[13:57] <didrocks> cjwatson: hum libmirserver4 is in suacy
[13:57] <infinity> Most.  Informative.  Changelog.  Ever.
[13:57] <infinity> didrocks: Not in a high enough version.
[13:57] <didrocks> infinity: I know… already told upstream they need to change their commit message in the future
[13:57] <cjwatson> libmirserver4 | 0.0.12+13.10.20130926.1-0ubuntu1 |         saucy | amd64, armhf, i386
[13:57] <cjwatson> 0.0.12+13.10.20130926.1-0ubuntu1 < 0.0.12+13.10.20131001
[13:58] <didrocks> oh right, I'm so used they don't have any kind of compatibility
[13:58] <didrocks> cjwatson: ok, so, I'll try chdist next time I don't see it installing
[13:58] <didrocks> thanks
[13:59] <cjwatson> Riddell: Um, what is this kate upload
[14:00] <cjwatson> +       $(overridden_command) -- -DKDE4_BUILD_TESTS=false -DPYTHON_LIBRARY=/usr/lib/x86_64-linux-gnu/libpython2.7.so.1
[14:00] <cjwatson> Riddell: That really isn't a sensible thing to put in debian/rules for all architectures :-)  Rejecting
[14:00] <cjwatson> shadeslayer: ^-
[14:02] <shadeslayer> ack
[14:02] <shadeslayer> Riddell: I didn't realize 4.11.2 was out?
[14:02] <Riddell> cjwatson: good point
[14:03] <Riddell> shadeslayer: ftp is open
[14:03] <shadeslayer> okay
[14:03] <cjwatson> I'm guessing you want $(DEB_HOST_MULTIARCH) there, with "DEB_HOST_MULTIARCH := $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)" at the top if tat isn't done already
[14:03] <shadeslayer> I didn't see a release announcement
[14:03] <didrocks> (thanks)
[14:04] <xnox> cjwatson: /me prefers "include /usr/share/dpkg/architecture.mk" to get all the DEB_{BUILD|HOST}_* vars with caching and for free =)
[14:04] <cjwatson> xnox: whatever :-)
[14:04] <Riddell> shadeslayer: no they open ftp the night or the morning before the announcement
[14:04] <cjwatson> xnox: (note my version isn't lacking caching)
[14:04] <shadeslayer> okay :)
[14:05] <xnox> cjwatson: it's always executed though, even when not needed. architecutre.mk only execs on demand & then caches.
[14:05] <xnox> (not that it matters, it's not that expensive to call)
[14:06] <shadeslayer>  /join #kde-devel
[14:06] <smartboyhw> shadeslayer, the whole channel? ;)
[14:07] <shadeslayer> yep
[14:07] <smartboyhw> shadeslayer, er, you do realize where you are talking right? ....
[14:07] <shadeslayer> yep
[14:07] <smartboyhw> ;O
[14:07] <shadeslayer> wait
[14:07] <shadeslayer> eh
[14:07] <shadeslayer> no no no
[14:07] <smartboyhw> LOL
[14:07] <shadeslayer> smartboyhw: I read that as "The wrong channel"
[14:08] <shadeslayer> and then went "yep"
[14:08] <smartboyhw> shadeslayer, sure;)
[14:08] <smartboyhw> Well, we welcome everybody anyway
[14:09] <xnox> cjwatson: \o/ thanks for removals.
[14:10] <cjwatson> np
[14:19] <shadeslayer> xnox: cjwatson -DPYTHON_LIBRARY=/usr/lib/$(DEB_HOST_MULTIARCH)/libpython1.7.so.1
[14:19] <shadeslayer> look better?
[14:22] <xnox> shadeslayer: actually you want `python-config --ldflags` & -lpython2.7
[14:22] <xnox> shadeslayer: cause there list libpython2.7.so in the proper /usr/lib/python2.7/config-$triplet/ directory, and will enable you to e.g. do python2.7 debug build.
[14:23] <xnox> shadeslayer: which is then e.g. under /usr/lib/python2.7/config-x86_64-linux-gnu_d/, vs /usr/lib/python2.7/config-x86_64-linux-gnu/ (_abi suffix)
[14:29] <shadeslayer> xnox: I don't quite follow, but the problem is that kate can't find the python lib causing python plugins in kate to not work
[14:29] <xnox> shadeslayer: ah, if you need the runtime library, you are correct.
[14:30] <shadeslayer> correct
[14:31] <cjwatson> mir/unity-mir passed proposed-migration now, I see
[14:32] <shadeslayer> btw did the swith to xmir happen already? because I don't think I saw it running on the Beta 2
[14:33] <cjwatson> no
[14:33] <shadeslayer> okay
[14:59] <stgraber> Riddell: can you confirm that the "a" in the version number for kate is intentional (not seeing it in the others, so wondering)
[14:59] <Riddell> stgraber: yes it is, upstream rerolled the tar
[14:59] <stgraber> ok
[15:15] <stgraber> Riddell: hmm, kdeartwork contains what looks like a feature change (disabling a bunch of slideshow transitions)
[15:16] <Riddell> stgraber: are you really reviewing every package? I'm quite impressed
[15:18] <stgraber> Riddell: I sure am ;)
[15:19] <stgraber> most of those take just a few seconds though as they're just re-versioning and updates to debian/control
[15:19] <Riddell> stgraber: kdeartwork change is for bug http://bugs.kde.org/182104
[15:19] <ubot2`> KDE bug 182104 in general "Specific transition effect of the slideshow screensaver is extremely slow" [Normal,Resolved: fixed]
[15:19] <Riddell> Bug 182104 - Specific transition effect of the slideshow screensaver is extremely slow
[15:20] <Riddell> it's removing a feature not adding it
[15:21] <stgraber> Riddell: feature freeze also covers feature removal ;)
[15:21]  * stgraber looks at the bug report
[15:21] <Laney> introducing a negative feature
[15:22] <stgraber> fine, I'll consider that fixing a nasty performance bug and let it through ;)
[16:52] <jamespage> infinity, balloons: rbasak just raised that someone from the server team needs to signoff on server images
[16:52] <jamespage> I'll pickup that honour for this cycle :-)
[16:53] <balloons> jamespage, :-) wonderful. I've already got a task for you then
[16:53] <jamespage> nice
[16:54] <jamespage> balloons, what do I need todo?
[16:54] <balloons> jamespage, Can you review the current tests and make sure they are all still valid and needed? In particular we have a few questions about the jeos tests
[16:54] <balloons> jamespage, http://iso.qa.ubuntu.com/qatracker/milestones/270/builds/54674/testcases
[16:54] <balloons> plars, if you around, let's sort this out with jamespage now for the final images ^^
[16:55] <jamespage> I see we are oversized as well
[16:55] <jamespage> I guess that needs looking at
[16:56] <balloons> jamespage, umm, is server still trying to fit on a cd? the other images are not longer constrained to that size
[16:56] <jamespage> whilst I'm here - we have a bit of a problem with python-lesscpy  (bug 1233749)
[16:56] <ubot2> Launchpad bug 1233749 in python-lesscpy (Ubuntu Saucy) "lesscpy command fails" [High,Triaged] https://launchpad.net/bugs/1233749
[16:56] <jamespage> there are fixes stuck in the Debian NEW queue for this; is there precedent/process for pushing a package from the debian git repositories directly into Ubuntu?
[16:57] <jamespage> balloons, the honest answer is I don't know
[16:57] <jamespage> but I can find out
[16:58] <cjwatson> I've been meaning to review the sizes and clear the warnings
[16:58] <jamespage> if its OK then we should probably drop " Warning: This image is oversized (which is a bug) and will not fit onto a standard 703MiB CD. However, you may still test it using a DVD, a USB drive, or a virtual machine."
[16:58] <balloons> jamespage, sure thing.. if you and team can review the tests and prune anything not needed it would greatly help. Checking on the oversize issue is a good idea also. Thanks!
[16:58] <plars> balloons: there are automated tests for a fair chunk of those. I don't have esx server so I'm not able to do the optional one, and maas usually gives me problems, but jamespage and smoser were really helpful in testing that during previous cycles.
[16:58] <cjwatson> I don't think it's something the server team needs to spend much time on, though obviously if there's stuff you can rip out for free then do it
[16:58] <jamespage> cjwatson, I'll not put it at the top of the list then
[16:58] <jamespage> I think roaksoax is about to add a couple more things anyway for maas
[16:59] <balloons> yes, I know maas is important. I wonder about the rest
[16:59] <balloons> it seems like we're always spending the last days spinning around on maas
[17:00] <rbasak> Would it be sufficient to automatically test most of the tasks with preseeds?
[17:00] <balloons> imho, yes
[17:00] <rbasak> And then focus on a basic install and maas?
[17:00] <balloons> that's the direction I would like to see it go
[17:02]  * infinity decides it's finally time to nap.
[17:03] <balloons> so rbasak plars jamespage can we confirm what we have automated tests for? I can then remove them from mandatory manual testing on the tracker. We can mark them as optional or remove them altogether
[17:03]  * rbasak isn't sure
[17:05] <plars> balloons: it's most of the install scenarios there, but I usually give them a look by hand as I'm doing other installs too, so just leave them
[17:06] <plars> balloons: ideally, I'd love to see manual and automated results all grouped together in a single view for the image, but we don't have that yet
[17:06] <balloons> plars, of course.. But I'd like to at least mark them as optional
[17:06] <plars> balloons: having them on the list though, ensures that someone either tries it by hand, or actually looks at the results and confirms they look ok
[17:06] <balloons> there's 18 mandatory tests for server, which adds up
[17:09] <doko> infinity, gcc-4.8 uploaded
[17:09] <jamespage> balloons, I'll review tomorrow AM
[17:12] <balloons> jamespage, plars rbasak thank you :-)
[17:48] <ogra_> stgraber, did systemd just go through without any queuebot message ?
[17:49]  * ogra_ sees it built and all, i tought the binary would show up here
[17:50] <stgraber> ogra_: why would the binary show up there?
[17:50] <stgraber> ogra_: AFAICT the source go blocked in Unapproved and accepted 1h50 ago
[17:50] <ogra_> dunno, i see others show up in the backlog
[17:50] <ogra_> ah, k
[17:50] <stgraber> the only ones that show up in New are those that introduce new binaries
[17:51] <ogra_> oh, ok, i thought durign freeze all held binaries would show up too
[17:51] <ogra_> anyway, then i should be good to build an image
[17:51] <stgraber> nope, only source packages get caught in unapproved
[17:51]  * ogra_ fires off a build
[19:09] <stgraber> jamespage: hey, looking at the horizon upload, should there be any kind of migration code in postinst to move the key between locations?
[19:14] <rsalveti> can anyone review the gstreamer related packages ^? this is a new upstream bugfix release, and final for the 1.2 series
[19:18] <stgraber> yep, will take care of that in a few minutes, slowly going through the queue
[19:18] <rsalveti> awesome, thanks
[19:30] <stgraber> infinity: around? (if you're, I'll leave the kernel upload to you, if not, I'll process it in a couple minutes)
[19:38] <stgraber> Laney: do you have a FFe for gst-plugins-good? looking at the upstream changelog, it doesn't really look like bugfix only to me...
[19:39] <stgraber> (I don't think we need a FFe for bad => good, those are fine, but I noticed a few new codecs and other random features in the upstream changelog bundled in the source)
[19:43] <rsalveti> let me check good
[19:47] <rsalveti> stgraber: which new codecs did you noticed in good?
[19:47] <rsalveti> looking here at the git log and seems it only got fixes
[19:49] <rsalveti> but there are indeed some new features inside a few plugins
[19:50] <stgraber> rsalveti: +2013-06-18 13:27:20 +0100  Alex Ashley<EMAIL_ADDRESS>[19:51] <stgraber> may be changes to an existing codec (AVC) though if that's the case, that's rather massive changes
[19:51] <rsalveti> hm, 06-18 is before 1.1.4, let me find the commit for that
[19:51] <stgraber> I didn't look at the code change itself, only the diff of the upstream changelog in the source
[19:53] <rsalveti> http://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/?id=a965185dee339da89f833b10cc2e5ac1108381b2
[19:53] <rsalveti> right, that's post 1.1.4 indeed
[19:54] <stgraber> how interdependent are those gstreamer packages?
[19:54] <stgraber> because we already have half of them through, so wondering what happens if -good is stuck for a while
[19:55] <rsalveti> seems only bad depends on -good
[19:56] <rsalveti> gstreamer <- base <- ugly / good
[19:56] <rsalveti> abd bad depends on good, base and gst
[19:56] <rsalveti> *and
[19:56] <stgraber> based also contains feature changes...
[19:56] <stgraber> *base
[19:56] <rsalveti> I can put a FFe bug in place
[19:57] <stgraber> would be good. I don't think it's a problem, but may be worth a generic, update everything to 1.2.0 tracking bug with all affected packages
[19:57] <rsalveti> yeah
[19:57] <rsalveti> let me do that
[19:57] <stgraber> because I realistically won't go through the whole code diff as even the changelog looks scary ;)
[19:58] <rsalveti> yeah, even if mainly fixes, that's a lot of fixed all around, hard to track them down
[19:58] <rsalveti> *fixes
[20:30] <rsalveti> stgraber: bug 1233832
[20:30] <ubot2> Launchpad bug 1233832 in gstreamer1.0 (Ubuntu) "[FFe] Updating gstreamer 1.0 stack to the final 1.2 release" [Undecided,New] https://launchpad.net/bugs/1233832
[20:32] <rsalveti> stgraber: let me know if you need any other info in there
[20:33] <stgraber> rsalveti: granted and I've let the two remaining packages in now
[20:34] <rsalveti> stgraber: great, thanks
[21:07] <jamespage> stgraber, I suppose for the sake of not leaving clutter in the filesystem that makes sense
[21:07] <jamespage> stgraber, if you want to reject I'll prepare a revised upload tomorrow
[21:08] <stgraber> jamespage: ok, will do that. thanks!


[12:03] <daftykins> \o
[12:03] <daftykins> time to do it all again, Tuesday style
[12:19]  * zxm-pi presses nose to window and waits for ups... psion day has come
[12:26] <daftykins> oooh exciting
[12:27] <zxm-pi> haven't been this excited for a delivery since.... my last psion :-)
[12:41] <MattJ> What Psion?!
[12:41] <zxm-pi> https://www.retrocoding.uk/psion-series-3mx/
[12:42] <MattJ> 3mx, cutting edge
[12:42] <MattJ> 3c was as far as I got
[12:43] <daftykins> me too, in fact zxm-pi is motivating me to sort it out a bit - might try and get the battery
[12:45] <daftykins> hmm CR1620 seems too niche for B&Q to stock
[12:45] <zxm-pi> local pharmacy perhaps?
[12:47] <daftykins> hrmm not sure
[12:59] <daftykins> magic, a hardware store off in the middle o' the rock has some
[13:01] <zxm-pi> the restoration of a psion deserves a prilgrimage :-)
[13:02] <zxm-pi> i believe the chant as you walk there is 'where the flip did i leave my serial adapter'
[13:04] <daftykins> :D
[13:04] <daftykins> armed with a fully functional floppy drive, loading up PsiWin should be a breeze
[13:05] <zxm-pi> and yay it was ordained that it was in the bottom of the bag you were sure it wasn't in
[13:05] <daftykins> my good pal is going to post me a nice RAM upgrade, so things are really shaping up for that retro PIII
[13:05] <zxm-pi> up to how much ram?
[13:06] <daftykins> he's got some super special 512MB modules that he wants me to try, but most signs online claim that's too much for a PIII 800MHz E B - so he's going to include 2 x 256MB modules as well
[13:06] <zxm-pi> that's a lot of ram for a piii
[13:06] <daftykins> >:)
[13:06] <zxm-pi> when i had one it was at 64mb?
[13:06] <daftykins> i went from 128 to 256MB i believe
[13:07] <zxm-pi> it was mad that my 286 was more responsive in daily use and it had only 1mb
[13:07] <zxm-pi> windows just sucked up all the cpu and ram
[13:08] <daftykins> what was the 286 running?
[13:08] <daftykins> or walking ;)
[13:09] <zxm-pi> dos, qbx 4-7, all console apps
[13:10] <daftykins> did the Psions ever behave with rechargables, or are they best with some single use alkalines?
[13:11] <zxm-pi> last time i had a psion it was 5mx and i only ever used alkalines in it. i did try nimh in palmos devices. i seem to remember sticking with alkalines eventually
[13:11] <zxm-pi> mind nimh was slightly more primative back then :-)
[13:12] <daftykins> hehe
[13:12] <zxm-pi> lost twice the charge per day sitting idle compared to todays ones
[13:17] <daftykins> maybe i'll try out some of the ones i have for my games console controllers and see how they behave :)
[13:17] <daftykins> i'm always so put off buying single use batteries, seems like 99% of the places that took spent ones over here have stopped doing so now
[13:20] <zxm-pi> all required here by law to accept used batteries. pesky eu :-)
[13:23] <daftykins> heh
[13:24] <zxm-pi> though so people hang on to things a little too long :-P https://twitter.com/angryearthling/status/1120968970142715904/photo/1
[13:24] <daftykins> xD
[13:24] <zxm-pi> spotted those in a recycle box. i HAD to take a pic.
[13:26] <daftykins> absolutely
[13:40] <zxm-pi> i have a psion again!
[13:41] <zxm-pi> batteries in, press on. one beep and ready to go.
[13:43] <zxm-pi> all apps running 197k used, 1851 free :-)
[13:45] <daftykins> \o/
[13:54] <daftykins> bah, wracked with indecision over picking a Dell Outlet system for a client employee
[13:54] <zxm-pi> which will give you least grief?
[13:54] <daftykins> none xD
[13:55] <daftykins> have to get something down here and then post it up to Manchester
[13:55] <zxm-pi> here's a pencil. good luck :-)
[13:55] <daftykins> <post office> that sir is a weapon, BANNED
[13:56] <zxm-pi> a rubber bendy pencil?
[13:56] <daftykins> they'll have to look that up in the postal handbook
[13:58] <zxm-pi> is that under pencil, bendy rubber or pencil, rubber bendy. cause there's 2000 pages on pencils alone :-P
[13:59] <daftykins> :D
[14:00] <daftykins> last time i took a chance on Guernsey Post to get the last laptop up to a new employee, they said they couldn't take the VAT up front so i had to just warn the employee it might get held up and the VAT expected to be paid before it was released
[14:00] <daftykins> in the end, it made it over without a problem - ridiculous
[14:00] <daftykins> i bet you if i tried it again it wouldn't happen that way
[14:02] <daftykins> probably try DHL this time, they're the ones that shipped over the mammoth rackmount Dell R820 for me :D
[14:02] <zxm-pi> they mention your name everytime the doctor pokes their hernia :-P
[14:02] <daftykins> haha
[14:03] <zxm-pi> mention/curse
[14:34] <daftykins> haha, got to the checkout - pal's employee with business card details on a call - suddenly the basket added up to £1,100 instead of £500, yet the basket showed empty
[14:34] <daftykins> had to cache clear the browser in a hurry, log back in and start over to find a suitable machine again and get it bought
[14:35] <zxm-pi> the fun of online shopping.
[14:35] <daftykins> ooh yes
[14:43] <zxm-pi> here's the 20 things you've looked at and thought you'd cleared out of your basket :-)
[14:47] <daftykins> yikes the broken pieces of hinge just fell out from one side of my 3c
[14:48] <zxm-pi> eek
[14:50] <daftykins> still turns on though, i'll go and pick up that battery and look for a magic eraser then i'll be in business
[14:51] <daftykins> can i ask what you had to pay to snag yours? wondering if it was less than i got quoted to put a new case on mine
[14:53] <zxm-pi> this one https://www.psionex.co.uk/en/product/pda/series3/models/s3mx-2mb.html
[14:53] <zxm-pi> euros 280 plus vat plus delivery
[14:53] <daftykins> hrmm
[14:54] <daftykins> they wanted £135 and then spoke of VAT, hrmm
[14:54] <daftykins> same company in fact
[14:55] <zxm-pi> i think there is another company doing sales and repairs but i can't find their details right now
[14:55] <daftykins> i always wanted to check out a 5 because they look so darn sexy
[14:55] <zxm-pi> was techno lusting at listings there for last few years :-)
[14:55] <daftykins> yeah i think you're right, i may've dropped an email and not received a reply iirc
[14:56] <daftykins> ok bbs, magical mystery tour time
[14:56] <daftykins> 'bout time i hopped on the bike in the sun!
[14:56] <zxm-pi> i had a 5mx. great machine. but the keyboard was missing a little magic the 3 has. the base of the 5 is flat and the keyoard slides out and hangs over the base. using it on sofa or bed it made the unit bob when you typed as lower row keys pressed down
[15:51] <daftykins> success!
[15:55] <daftykins> forgot to take my bike lock though, so couldn't try other places for the magic eraser :( true schoolboy error
[15:56] <daftykins> on arriving at the battery place, some school lads were very taken by my bike so i answered a few questions before heading inside xD
[15:57] <daftykins> that cell is working fine, only complains about the main batteries at power on now :D (none inside)
[15:57] <daftykins> time to brave the wrecked hinges to pop some in
[16:02] <zxm-pi> must dig out my broken 3a 512k and send for repairs.
[16:05] <daftykins> i think maybe i will ask RMC's Neil on youtube if he's got any interest in doing a segment on Psion, then maybe pursue the repair and loan it his way for fun
[16:06] <daftykins> gotta love the way this set of rechargables are dead to a console controller but to the Psion it just says they're a bit on the low side ;)
[16:06] <zxm-pi> psion is the rolls royce of mobile devices. they just worked
[16:06] <zxm-pi> a ridiculous amount of functionality in a tiny case
[16:08] <daftykins> too right
[16:12] <daftykins> https://i.imgur.com/JpT8yuO.jpg - here she is
[16:12] <daftykins> left hinge now AWOL
[16:19] <zxm-pi> shiny... https://i.imgur.com/6DCPT1C.jpg
[16:24] <daftykins> ooh all your apps are still bold so that means loaded iirc, i reclaimed some mem by exiting all - Psion key + shift + A
[16:24] <daftykins> mine did the same on its' first power on
[16:24] <daftykins> must be a sort of primed-for-launch mode to impress you with application launch speed
[16:25] <zxm-pi> it's amazing how muscle memory helps you remember the shortcuts. just another reason to always use keyboards
[16:25] <daftykins> indeed!
[16:25] <zxm-pi> from pressing on to beep was ~2-3 seconds with all apps started
[16:26] <zxm-pi> will have to see if it means less battery life as it's running much faster. used to get about 40hours of 2 duracell aa's
[16:26] <daftykins> https://www.youtube.com/watch?v=i4-lBU881q8
[16:27] <zxm-pi> well if the post office can't find it :-P
[16:28] <daftykins> xD
[16:28] <daftykins> this is rockist
[16:37] <zxm-pi> you'll need to build a doomsday device to make everyone aware of guernsey's location :-P
[16:37] <zxm-pi> psion controlled to render it immune to hacking of course
[16:37] <daftykins> lol
[16:38] <zxm-pi> send 12 beelion dollars and a pack of energizers 2025s...
[16:53] <daftykins> there we go, dropped Neil an email so we'll see if he fancies covering Psions
[17:45]  * daftykins nudges diddledan gently
[19:19] <daftykins> yay he replied to my email \o/
[20:39] <daftykins> zxm-pi_: had a couple of rounds of Patience, aww yeah :D
[20:42] <zxm-pi_> i do remember playing patience a lot on earlier psions. not sure it'll replace sodoku or boggle or snake on nokia 3310 java phone
[20:43] <daftykins> :D
[20:43] <zxm-pi_> still miss sim city, reptoids or submarine on palmos.
[20:43] <zxm-pi_> but my main game these days is shattered pixel dungeon on android
[20:44] <zxm-pi_> and on kaios gems is the one to beat. such a catchy tune
[20:51] <zxm-pi_> so so many mobile oses :-)
[20:51] <zxm-pi_> symbian, sharp zaurus linux


[09:47] <teddy-dbear> Morning peoples, critters and everything else
[11:57] <icey> ahoy
[12:01] <teddy-dbear> \o
[12:35] <lazyPower> o/


[06:46] <dholbach> good morning
[06:52]  * Noskcaj wonders just how many channels dholbach says "good morning" on. And it's 5pm ;)
[06:54] <dholbach> Noskcaj, I just wanted to say "hi" to everyone :)
[06:54] <Noskcaj> nothing wrong with that
[07:03] <ESphynx> dholbach: good morning ;)
[07:03] <ESphynx> Good night for me, 3 AM :P
[07:03] <dholbach> hi ESphynx
[07:03] <Unit193> Here too. \o/
[07:05] <ESphynx> yet another very productive 40 hours work day.
[08:16] <highvoltage> One day dholbach will be on holiday and we'll still get a good morning and then we'll know he's just a script :p
[08:16] <smartboyhw> highvoltage, +1
[08:17] <highvoltage> (just joking)
[08:17] <smartboyhw> highvoltage, I asked him how he says good morning in many channels, he says that he justs copy and paste:P
[08:18] <Laney> James Tait gives you a good morning /and/ tells you what "day" it is today
[08:18] <Laney> BEAT THAT
[08:19] <dholbach> haha
[08:19] <dholbach> yeah, James Tait is awesome
[09:06] <geser> smartboyhw: if he uses irssi, he could use http://scripts.irssi.org/html/hello.pl.html :)
[19:32] <davromaniak> ,,
[19:32] <davromaniak> sorry, I need to take off my boxing gloves :/
[19:45] <ESphynx> xnox: ping :)