=== salem_ is now known as _salem
hallynbug 129223403:54
ubottubug 1292234 in qemu (Ubuntu) "qcow2 image corruption in trusty (qemu 1.7 and 2.0 candidate)" [High,Confirmed] https://launchpad.net/bugs/129223403:54
hallynarges: yeah, sure, that'd be good.  if you end up giving up you can alwyas assign it back to me.03:55
hallynogra_: wedensday is my only day on keyboard this week.  what's up?03:55
argeshallyn: yea, i ran 15 iterations of the reproducer today on my x220 with ext3/lvm and no luck, will try some other approaches here soon04:33
argeshallyn: assigned myself04:37
hallynarges: gah!04:38
hallynarges: thanks04:38
ScottKNice to see Randall's blog given over to advertising now.05:27
darkxstmitya57, http://pastebin.com/ayU04vHz05:58
dholbachgood morning07:52
LocutusOfBorg1hi dholbach :)08:22
dholbachhi LocutusOfBorg108:22
ubottuPlease don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience08:24
darkxstMasterPiece, sometimes people say hi to others they know ;) guess it a social thing ;)08:36
MasterPiecedarkxst, I know, my purpose of command was detecting the bot08:37
MasterPieceHi all :)08:37
darkxstthe bot is always here, except when he breaks ;)08:38
LocutusOfBorg1I like to say "hi" to dholbach, because I should never stop to thank him for all the merges he does for me :)08:43
* dholbach hugs LocutusOfBorg108:50
dholbachthanks a lot for all your hard work!08:50
LocutusOfBorg1s/hard/easy :)08:51
LocutusOfBorg1I hope to become soon a DD, to become after an ubuntu developer :)08:51
dholbachall the best! :)08:57
xnoxGuten Morgen!09:15
highvoltageguten morgen xnox09:20
LocutusOfBorg1xnox, too difficult :) morning to you too :D09:24
frechdachs69anyone who knows how to check for installed Qt5 plugins using cmake with Ubuntu 14.04? e.g. Qt5Gui_PLUGINS is just empty09:24
frechdachs69according to cmake no plugins are available at all09:26
LocutusOfBorg1frechdachs69, do you have your find_package issued correctly?09:27
LocutusOfBorg1sorry I usually use .pro files with qt09:27
LocutusOfBorg1anyway, I encoundered some cmake 3.0 problems about a bad "find_package"09:28
frechdachs69LocutusOfBorg1: I've checked the installed cmake files: the referenced Qt5Gui_*.cmake files are missing inside package 'qtbase5-dev'09:41
frechdachs69which package do I have to install to get 'Qt5Gui_QGifPlugin.cmake' ?09:44
LocutusOfBorg1I don't think you need it, why you think you should have one?09:48
LocutusOfBorg1you use the find_package and it fills the vars for you09:48
pittistgraber: I'm confused by bug 1346734 -- I now have the cgroups writable for "ubuntu" in all controllers, but it still complains with some weird rmdir errors09:53
ubottubug 1346734 in systemd (Ubuntu) "Unprivileged LXC containers don't work under systemd" [Medium,Triaged] https://launchpad.net/bugs/134673409:53
pittistgraber: I followed up to the bug with some details; would be nice if you could have a look?09:54
pittistgraber: ah, the old "got the solution only after asking" effect again, unping09:58
pittistgraber: yay, I have my first user container running under systemd :)09:58
ogra_crazy talk09:58
=== doko_ is now known as doko
mitya57darkxst, thanks, I got it. Will try to include this in Debian upload.10:36
mitya57darkxst, or, maybe it'll be better to just depend on mutter-common.10:41
darkxstmitya57, don't add dependencies for retarded code10:42
mitya57Well, mutter-common is just 4MB and doesn't depend on anything else10:43
darkxstmitya57, it really should be fixed upstream, but apparently they don't care10:46
mitya57I still think that it would be better to add dependency than carry a patch never-accepted-upstream10:47
darkxstmitya57, sure, and I am still shocked how that code could make it into a release10:54
=== _salem is now known as salem_
darkxstits up there with the most convulted piece of python code I have ever seen in a real project10:55
darkxstand certainly my intention of patching was for them to fix it, not ignore it10:57
pittidoko: wrt. http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#binutils, the new binutils indeed changes/breaks the lintian test for "apparently-corrupted-elf-binary"; I suppose the lintian test needs to be adjusted10:57
dokopitti, have't looked yet, wasn't that eager to get it migrated10:59
pittidoko: there's no change in Debian's git yet (http://anonscm.debian.org/cgit/lintian/lintian.git/log/t/tests/binaries-from-other-arch)10:59
pittidoko: oh, ok, I thought you were; I'll file a Debian bug then, the lintian guys are usually very fast10:59
mitya57darkxst, I have seen Python code that is a *lot* worse10:59
mitya57So, for now I'll add the mutter-common dependency in Debian, and will remove it when/if they accept your patch11:00
darkxstmitya57, I have as well, but not under the GNOME umbrella, although admittly  not much python there11:00
mitya57(and I am going to upload it when debian #770969 is approved)11:00
ubottuDebian bug 770969 in release.debian.org "unblock: gnome-tweak-tool/3.14.2-1 (pre-approval)" [Normal,Open] http://bugs.debian.org/77096911:00
darkxstmitya57, ok, doubt it will ever be approved anyway11:02
darkxstI was never able to even get a review, even after pinging relevent people on IRC11:05
jamespagedidrocks, apologies - I thought I'd covered you update to docker but apparently not11:07
didrocksjamespage: no worry, I was just wondering if this was on purpose. Once your package moves out from -proposed, I'll readd this :)11:10
jamespagedidrocks, let me sort that out now so next time I merge it I know what I'm mean't to be doing11:11
didrocksjamespage: sure!11:13
jamespagedidrocks, you fix was the ensure_socket_activation_only.patch right?11:15
didrocksjamespage: yeah11:16
didrocksjamespage: newer packages ships a WantedBy= target11:16
didrocksyou need to remove it11:16
didrocks(in docker.service)11:17
didrocksas the pointed targeted (multi-user.target) is started as part of the boot process11:17
didrocksand so, this is starting docker.io at boot11:17
jamespagedidrocks, sorry for the dumb questions but why don't we want it to start on boot?11:18
didrocksjamespage: because it's socket activatable11:19
didrocksjamespage: so, if you call docker <something>, it will start the service11:20
didrocksonly when needed then11:20
jamespagedidrocks, that seems related to https://github.com/docker/docker/commit/053c3557b3198466ecfbe066fefdbab2a78771d511:22
jamespageif we don't start it on boot, the --restart=always flag can't be obeyed?11:22
cjwatsonrbasak: \o/ I tracked down bug 139383211:24
ubottubug 1393832 in dpkg (Ubuntu) "Modules fail to enable when configured after apache2 is configured" [Undecided,New] https://launchpad.net/bugs/139383211:24
cjwatsonwill update bug shortly :)11:24
didrocksjamespage: hum, indeed, that one seems sensible (the second should be fixed with something else)11:24
didrocksjamespage: is there any flags on the file system to know which containers have --restart=always flag?11:25
jamespagedidrocks, hostconfig.json contains the restart policy for a container11:28
didrocksjamespage: ok, let it that way then, but I think we should investigate to only start the unit if there are some with those flags11:29
jamespagedidrocks, that sounds efficient11:30
didrocksthanks for digging in!11:30
pittidoko: I sent debian bug 771054 FYI11:37
ubottuDebian bug 771054 in lintian "lintian: FTBFS: binaries-from-other-arch fails with latest binutils" [Serious,Open] http://bugs.debian.org/77105411:37
dokopitti, did you have a look which input file has this warning emitted?12:19
pittidoko: it's generated by "sh t/tests/binaries-from-other-arch/debian/debian/dumpobj > /tmp/elfobj"12:22
pittidoko: the binary-from-other-architecture is correctly determined, and "file" confirms that it's an ARM binary; not sure why it's a "corrupted" binary (it's just a base64 dump of something)12:23
=== frechdachs69_ is now known as frechdachs69
=== MacSlow is now known as MacSlow|lunch
fabbioneivoks: ping12:52
fabbioneivoks: not sure who is in charge of pcmk your side, but if you are not looking at the upstream ml, we will have a HA Summit in Feb in brno12:53
fabbioneivoks: might want to consider having your maintainer there12:53
ogra_hey, the godfather is around ...12:53
fabbionehey ogra_12:54
ogra_how is life ?12:54
fabbioneyeah they didn't kill me yet12:54
fabbionenot too bad, you?12:54
ogra_great ... phones everywhere12:54
fabbionenerd :)12:55
ivoksfabbione: hey, how are you? :)12:59
fabbioneivoks: usual man, usual :)13:00
ivoksfabbione: i'll pass on the information, thanks13:01
ivoksi'm personally not that much invovled anymore13:01
fabbioneivoks: wfm13:02
cjwatsonrbasak: ... and that fixed the broken autopkgtests that I noticed (mod-wsgi and puppet); excellent13:48
=== salem_ is now known as _salem
=== MacSlow|lunch is now known as MacSlow
pittistgraber: I added some debugging, and attaching a process to /user.slice/user-1000.slice in the "cpuset" controller fails with "No space left on device"; does that happen to ring a bell?14:15
pittihallyn: ^ or to you, from your cgmanager work? I get that when trying to attach a pid to a cgroup in cpuset; it works for all other controllers14:15
pittibut it seems LXC is quite insistant on getting that controller, too14:16
pittiin the interwebs I found "Cpuset always require initializing cpuset.cpus and cpuset.mems,14:17
pittibecause they are empty by default, this fact block task attaching with -ENOSPC"14:17
pittiindeed /sys/fs/cgroup/cpuset/cpuset.mems is "0-3" on my workstation (where it works), and "0" in my test VM (where it fails)14:18
=== Guest68049 is now known as rcj
hallynpitti: if you get no space left ondevice, it sounds like your cpuset.cpus or cpuset.mems is unset14:20
hallynpitti: '0' would be ok.  that means you get '0'.14:20
hallyn(cpu 0, not 0 cpus)14:20
pittihallyn: cpuset.mems is "0" in both situations, so I guess it's the "0" in cpuset.cpus?14:20
hallynwhat is cpuset.cpus?14:20
=== rcj is now known as Guest36844
hallynno that sounds fine actually14:21
pittihallyn: oh, but /sys/fs/cgroup/cpuset/user.slice/user-1000.slice/cpuset.cpus is indeed empty14:22
pitti(where I want to attach to)14:22
hallynpitti: oh, ok, then yes that needs to be initialized.  if you set clone_children=1 you'll be fine14:23
hallyncgmangaer would do that for you, but doesn't when systemd is running14:23
pittihallyn: ah, thanks14:24
pittihallyn: indeed /sys/fs/cgroup/cpuset/cgroup.clone_children is "1" on my workstation and "0" in my VM14:25
pittihallyn: I don't know what set that, might that be LXC or so? I don't have cgmanager running, and systemd doesn't touch it either14:25
hallynlxc does also set it14:26
hallynjust on /lxc14:26
hallynhm, or maybe not just on lcx, but i thought so14:26
pittithe fun thing is that lxc-checkconfig says "Cgroup clone_children flag: enabled" when it's not14:26
pittithat's the only hit that grep find14:26
pittihallyn: anyway, so in order to do that "attach to all controllers" thing, I need to set clone_children to 1 during startup; do you know if that could negatively affect anything else?14:27
pittiaccording to what https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt says about it it seems fairly harmless14:27
pittihallyn: and I guess that's what we've done until now anyway, so it wouldn't be a regression either way, right?14:28
hallynpitti: rihgt, the only thing i tmight do is upset systemd at some point14:30
hallynpitti: i know of nothing that depends on those not being initialized14:30
hallynanything that does, could set it lcoally for the workloads it's trying ot confine14:31
pittihallyn: not really; systemd upstream does not touch any controller except the custom "systemd" one14:31
pittiI'm just patching all that in :)14:31
hallyndoesn't it handle other controllers contingent on a /etc/systemd/logind.conf setting?14:32
didrockspitti: yeah, cpu controller is 0 by default, it's weird because lennart's blog post told that he's using at least the cpu one by default14:32
pittihallyn: that was <= 20414:32
pittididrocks: indeed, "0" is the first one; empty file means "none"14:32
hallynoh.  i'm behind the times as usual14:32
pittihallyn: and indeed my login shell is now in all controllers including cpuset \o/14:33
pittiblimey! my container starts!14:33
pitti♩ rock'n'roll tune ♪ ♫14:33
pittihallyn: thanks for your help!14:33
* pitti aims a spear towards bug 134673414:34
hallynnp - hopefully we get al lthis straightened out this cycle14:34
ubottubug 1346734 in systemd (Ubuntu) "Unprivileged LXC containers don't work under systemd" [Medium,In progress] https://launchpad.net/bugs/134673414:34
hallynthanks - ttyl14:34
=== roadmr is now known as roadmr_afk
xnoxdoko++ hammerhead - BOOM! =)14:57
=== charles_ is now known as charles
=== cmagina_ is now known as cmagina
stgraberpitti: actually, it does15:25
pittistgraber: hallyn already responded, we figured it out (cpuset's cgroup.clone_children)15:26
stgraberpitti: oh, looks like hallyn answered15:26
pittistgraber: it's working now with the patch set in http://people.canonical.com/~pitti/tmp/systemd-unpriv-lxc/15:26
pittistgraber: I'm backporting them to our 215 package as we speak15:26
=== roadmr_afk is now known as roadmr
=== _salem is now known as salem_
cjwatsonCould somebody have a look at https://launchpad.net/ubuntu/+source/glib2.0/2.43.1-1/+build/6596956 ?  It's causing collateral damage further up the build stack.15:47
cjwatsonI've already retried it once.15:47
pittiLaney: ^ that's the thing you are currently discussing with desrt in #u-desktop, right?15:47
cjwatsonOK, cool, thanks15:47
LaneyHe's about to pop up in #is to get porter access, so if you want it fixed get them to action it quickly ;-)15:47
stgraberpitti: on the other side of the story, I just sent an e-mail to lxc-devel detailling our plan for systemd container support. I actually got an almost working container here using a very hackish prototype.15:59
pittistgraber: oh, nice! you mean for systemd as pid 1 in the guest? what's actually missing there?15:59
pittistgraber: or do you mean for unprivileged containers?16:00
pittistgraber: as they seem to work reasonably well with root containers16:00
stgraberpitti: systemd as pid1 in a lxc container, both privileged and unprivileged16:00
stgraberand without having to turn off any crazy apparmor option (like allowing cgroupfs mounts or anything like that)16:00
pittistgraber: hm, that's bug 1347020?16:01
ubottubug 1347020 in lxc (Ubuntu) "systemd does not boot in a container" [High,Triaged] https://launchpad.net/bugs/134702016:01
stgraberI guess so16:01
stgraberwe also have a dozen more on github16:01
pittistgraber: ah right, I had to weaken apparmor for the cgroup mounting16:01
stgraberso the current plan is to write lxfs (fuse filesystem) to take care of the cgroup part, implement unprivileged lxc.autodev, implement init system detection code so we can turn on autodev, turn off kmsg redirect and set lxc.mount.auto appropriately if the container's init system is systemd and also add a new lxc.init_cmd option so you can set a different init path in there.16:02
cjwatsonbdmurray: Where's the best place to get package-team-mapping in a machine-readable form?16:03
cjwatsonbdmurray: I've found https://bazaar.launchpad.net/~bryce/arsenal/2.x/view/head:/reports/package-team-mapping.csv, but not exactly current16:11
cjwatsonbdmurray: Or is there a version that comes out of bug subscriptions now?16:12
bdmurraycjwatson: there are teams that should be subscribd to packages for which they are responsible, although I haven't looked at it in a bit, e.g. foundations-bugs, desktop-packages, ...16:13
cjwatsonbdmurray: Right, so what I'm trying to do is work out how we might generate subdivided reports from things like proposed-migration, component-mismatches, etc. that are divided down by teams16:14
bdmurraycjwatson: this report should cover most of teams - http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-u-tracking-bug-tasks.html16:14
cjwatsonbdmurray: Intersecting those with the team mapping seems like the right first step16:14
cjwatsonbdmurray: But I don't really want to have to scan through for the mapping every time16:14
bdmurraycjwatson: I'm looking around. fwiw unsubscribed-packages in ubuntu-archive-tools has the team names16:16
cjwatsonbdmurray: I guess I kind of want https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/package-sub-json/+merge/193321 except not limited to main and restricted?16:16
bdmurraycjwatson: oh yeah, that'd make sense16:17
cjwatsonbdmurray: Are you particularly attached to that being limited to main/restricted (and the output file prefixed with m-r-)?  I know you probably don't want to scan through every source package in the archive, but it should be possible to just dump out the subscriptions of those teams16:18
bdmurraycjwatson: No, having it include the archive seems fine.16:19
cjwatsonbdmurray: cool, I'll sort that out and have it dump regularly to somewhere under ~ubuntu-archive, then16:20
bdmurrayno problem16:22
cjwatson"unsubscribed" will still just be main and restricted, I guess that's OK16:23
cjwatsonit's the other entries I care about :)16:23
pittibdmurray: I salvaged the ddebs tarball for now; indeed the two binary packges don't get published for some reason, I'll investigate this more closely tomorrow morning16:30
cjwatsonbdmurray: http://people.canonical.com/~ubuntu-archive/package-team-mapping.json is now updated hourly16:47
=== happyaron is now known as Guest11916
rbasakcjwatson: thanks! I had just assumed that not matching the grep meant it was not installed and never considered actually checking the output.18:34
rbasakNice one :)18:35
=== Guest36844 is now known as rcj
=== rcj is now known as Guest84698
=== Guest84698 is now known as rcj_ghost
mdeslaurxnox: I could have wrapped it with a few gtk version checks, but then would have had to modify autoconf to support being called with the gtk version as a parameter20:40
mdeslaurand then being built twice20:40
ScottKMuch better.  Thanks.20:40
xnoxmdeslaur: yeah yeah.20:40
xnoxmdeslaur: i'll twiddle with it a bit and check things.20:41
=== salem_ is now known as _salem
mdeslaurxnox: and it sucks to have to test it twice for every gtk3 fix :P20:44
mdeslaurin fact, I wonder why we package this separately at all, maybe we should just add the plugin to the xchat/xchat-gnome packages directly20:45
mdeslaurhrm, dependencies on non-unity desktops maybe20:45
xnoxmdeslaur: upstream build-system supports drop-in plugins, however that would make it non-syncable package (w.r.t. new upstream releases)20:55
xnoxmdeslaur: i ponder if indicator plugin would be accepted e.g. hexchat upstream.20:56
xnoxjdstrand: slangasek: i would like to build ia32 & x64 OVMF images, from that same package20:56
* xnox rolls up his sleeves.20:56
mdeslaurxnox: oh, maybe20:56
slangasekxnox: yes; I'm not sure the right way to do this, fwiw I've already received requests for ARM OVMF images to be installable on x86 which makes it more fun to figure out multiarch co-installability vs. cross-build all-in-one21:02
slangasekxnox: would native-build-everywhere, apt-get install ovmf:i386 ovmf:amd64 work, you think?21:02
xnoxslangasek: i believe the current procedure to resolve that is to open more bug reports for technical comittee.21:02
xnoxslangasek: i think "apt-get install ovmf:i386 ovmf:amd64 " etc is an excellent idea!21:03
xnoxslangasek: and makes the build machinery so much easier.21:03
slangasekxnox: what's the right way to arch-qualify the filenames on disk? have you worked that part out?21:04
slangasekfor compatibility I guess amd64 should keep /usr/share/ovmf/OVMF.fd and /usr/share/qemu/OVMF.fd21:04
xnoxslangasek: yes. I'd follow the UEFI boot/ naming convention that is suffix the name with the uefi-arch tag?21:05
=== roadmr is now known as roadmr_afk
xnoxand then OVMF.fd can become a symlink to OVMFX64.fd or some such.21:05
slangasekcan we put some separator char in there too, please? :)21:06
stgraberotherwise I'm going to get very very confused when I've got both X64 and AARCH64 (or whatever abreviation we end up with) :)21:06
slangasekxnox: and yeah, that's a reasonable convention, but I'm more concerned that the things which consume ovmf know about it21:06
xnoxbecause you'll sick of grubx64.efi & shimx64.efi ?! =)21:06
slangasekno, because having it in all caps makes it hard to read21:07
xnoxfor a long time, i though it was "shim - mex" rather than just "shim"21:07
jrwrenis anyone aware of an sbuild like tool which uses cloudimg as its base and lxc ?21:08
xnoxjrwren: you can boot cloudimages in lxc, in the cloud-init config preseed to install sbuild & mk-sbuild, and make post-script setup chroots you want.21:15
xnoxjrwren: you still want to jump into lxc -> jump into sbuild chroot. As cloud-image has more things installed, than a minimal build chroot.21:16
xnoxjrwren: we have juju charms to deploy "sbuild" ready units -> but after deployment these are ready for interractive use.21:16
xnoxjrwren: rather than spin up, build this dsc, copy artifacts / buildlog & tear down.21:17
xnoxslangasek: hallyn: edk2 git repository is behind packaging.....21:18
xnoxmaybe this is not repository i'm looking for21:19
xnoxslangasek: $ git ls-remote git://anonscm.debian.org/pkg-qemu/edk2.git HEAD21:21
xnox$ git ls-remote https://anonscm.debian.org/git/pkg-qemu/edk2.git HEAD21:21
xnox... the two hashes no match....21:22
jrwrenxnox: thanks. I'm going to have to study what you just wrote for a bit :)21:24
xnoxjrwren: ok =)21:32
=== roadmr_afk is now known as roadmr
hallynxnox: with apologies to slangasek, i've horribly neglected edk221:57
jrwrenxnox: my thought was more to use lxc instead of schroot.22:05
xnoxjrwren: ok, but why cloud-image as well?22:06
jrwrenxnox: no reason. its my go to minimal.22:06
xnoxjrwren: you'd then want to construct lxc container with (a) unpacked debian source package (b) build-dependencies installed (c) do something like lxc-start -- dpkg-buildpackage -b22:07
jrwrenxnox: I was trying sbuild-createchroot and having issues and hence thinking of alternatives. Now that I've switched to mk-sbuild and not having issues, I think I'll be fine with the schroot22:07
xnoxjrwren: cloud-image is small, but it's huge compared to a minimal build-chroot as used for official builds.22:07
xnoxjrwren: yeah, mk-sbuild is awesome.22:07
xnoxjrwren: schroot is enough protection.22:08
jrwrenxnox: I'll keep using mk-sbuild and sbuild and forget what I said about lxc :)22:08
xnoxstgraber: have you though of making launchpad-sbuild thing use lxc containers? or possibly does it already do that?22:08
xnoxjrwren: ;-)22:08
stgraberxnox: thought of it, yes, had time to do it, no22:09
jrwrencalling sbuild-createchroot directly complained about debootstrap, and had a warning mounting proc. I think the proc warning was a red herring. It made me think lxc wouldn't have the proc mount issue.22:11
jrwrennow that I've moved passed that, by using mk-sbuild, I no longer think I need lxc  :)22:11
jrwrenxnox: huge thanks for the quick response.22:11
=== rcj_ghost is now known as rcj
xnoxdoko: edk2 writes crazy c which no longer builds with gcc-4.9 =(23:33
xnoxdoko: do you want to see crazy C or do you want an extra package hard-code using gcc-4.8?23:33
sarnoldmy curiosity is piqued to discover what kind of crazy C won't build with newer gcc but builds fine with newish gcc... :)23:34
robert_ancellblr, hey, nice to have another person online in the quiet timezone!23:36
slangasekxnox: is that true for upstream trunk as well?23:37
xnoxslangasek: i believe so, yes. I'll test that out.23:38
blrrobert_ancell: hi from Dunedin! thanks :)23:40
xnoxslangasek: and EfiShellLib fails to build for 32bit =(23:41
slangasekwell, that's fun23:44
xnoxslangasek: i think build machinery expects "Ia32" subdirs for arch specific things, and it's using "IA32" in a couple of places.23:55
xnoxslangasek: clearly this all just works on case-agnostic filesystems.....23:56
slangasekxnox: no problem, please build depend on mtools + lxc23:56
xnoxslangasek: i'll try to fudge it.23:57
slangasekxnox: I think I hit a similar problem before for the amd64 build, that got fixed upstream before it became a problem for me23:57
slangasekunless I'm still carrying bletcherous case-fixing patches somewhere23:58

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!