21:00:01 <ignatenkobrain> #startmeeting Rust SIG (2017-03-01)
21:00:01 <zodbot> Meeting started Wed Mar  1 21:00:01 2017 UTC.  The chair is ignatenkobrain. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
21:00:01 <zodbot> The meeting name has been set to 'rust_sig_(2017-03-01)'
21:00:05 <ignatenkobrain> #meetingname rust-sig
21:00:05 <zodbot> The meeting name has been set to 'rust-sig'
21:00:08 <ignatenkobrain> #chair ignatenkobrain jistone
21:00:08 <zodbot> Current chairs: ignatenkobrain jistone
21:00:11 <ignatenkobrain> #topic Agenda
21:00:14 <ignatenkobrain> #link https://docs.pagure.org/fedora-rust.sig/meetings/2017-03-01.html
21:00:17 <ignatenkobrain> #info (1) Roll Call
21:00:21 <ignatenkobrain> #info (2) Current state of affairs
21:00:23 <ignatenkobrain> #info (3) Packaging Guidelines
21:00:26 <ignatenkobrain> #info (4) Integration of system registry
21:00:29 <ignatenkobrain> #info (5) Open Floor
21:00:32 <ignatenkobrain> #topic Roll Call
21:00:36 <ignatenkobrain> .hello ignatenkobrain
21:00:36 <Pharaoh_Atem> .hello ngompa
21:00:37 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <ignatenko@redhat.com>
21:00:40 <zodbot> Pharaoh_Atem: ngompa 'Neal Gompa' <ngompa13@gmail.com>
21:00:49 <jistone> .hello jistone
21:00:50 <zodbot> jistone: jistone 'Josh Stone' <jistone@redhat.com>
21:01:13 <ignatenkobrain> mich181189: are you around? :)
21:01:18 <Pharaoh_Atem> Akien: you here?
21:01:25 * jwf idles in the back :)
21:01:30 <Akien> .hello
21:01:30 <zodbot> Akien: (hello <an alias, 1 argument>) -- Alias for "hellomynameis $1".
21:01:34 <jwf> .hello jflory7
21:01:35 <zodbot> jwf: jflory7 'Justin W. Flory' <jflory7@gmail.com>
21:01:35 <Akien> (half there)
21:01:37 <Akien> .hello akien
21:01:41 <zodbot> Akien: akien 'Rémi Verschelde' <rverschelde@gmail.com>
21:02:06 <msehnout> .hello msehnout
21:02:08 <zodbot> msehnout: msehnout 'Martin Sehnoutka' <msehnout@redhat.com>
21:02:11 <ignatenkobrain> hi msehnout
21:02:11 <mich181189> hey!
21:02:22 <Pharaoh_Atem> hi msehnout, mich181189!
21:02:39 <ignatenkobrain> #topic Current state of affairs
21:02:44 <ignatenkobrain> #info 80 SRPMs, 91 RPMs: rustfilt, ripgrep, rustfmt are packaged
21:02:47 <ignatenkobrain> #info Migrated from COPR to fedorapeople.org due to mock limitations
21:02:51 <ignatenkobrain> #link https://fedorapeople.org/groups/rust
21:02:56 <ignatenkobrain> #info mich181189 has implemented dual-bootstrap feature to support using non-system RPM
21:02:59 <ignatenkobrain> #link https://github.com/rpm-software-management/mock/pull/51
21:03:08 <Pharaoh_Atem> yay!
21:03:15 <jistone> ignatenkobrain is a packaging machine!
21:03:22 <jistone> mich181189++ too
21:03:22 <zodbot> jistone: Karma for mich181189 changed to 2 (for the f25 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
21:03:32 <Conan_Kudo> ignatenkobrain++
21:03:32 <zodbot> Conan_Kudo: Karma for ignatenkobrain changed to 19 (for the f25 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
21:04:08 <ignatenkobrain> I've talked to clime and we can try patched mock with COPR next week
21:04:15 <Pharaoh_Atem> awesome
21:04:18 <mich181189> ah great!
21:04:43 <ignatenkobrain> so if it works fine and msuchy merges stuff, then in couple of weeks we can switch back to COPR
21:04:52 <msehnout> What exactly is the problem with mock?
21:04:58 <jistone> remind me, what's the timeline for getting the necessary rpm/dnf/etc changes into Fedora proper?
21:05:04 <Pharaoh_Atem> mock fundamentally relies on system rpm/dnf
21:05:08 <ignatenkobrain> jistone: F27
21:05:14 <Pharaoh_Atem> which causes problems when attempting to rely on new functionality
21:05:28 <mich181189> msehnout: rust packages use the "with" rich dependency
21:05:28 <ignatenkobrain> jistone: RPM 4.14 will support all necessary stuff for us
21:05:47 <msehnout> ok thanks for clarifying
21:05:48 <ignatenkobrain> s/will/should (I expect to)/
21:05:58 <Pharaoh_Atem> on the Mageia side, if there won't be backports to RPM 4.13 supported by Fedora, I expect that Fedora 27 and Mageia 7 will line up on this front
21:05:58 <ignatenkobrain> and 4.14 is planned for F27
21:06:25 <ignatenkobrain> jistone: but I'll be maintaining backported patches for F24+
21:06:27 <Pharaoh_Atem> and even if there were, we have our legacy package manager as a noose around our necks
21:06:48 <Pharaoh_Atem> so Mageia 7 will be the earliest on our front, as I hope I can get us to fully move to DNF for MGA7
21:06:53 <ignatenkobrain> so even we can't get it in fedora for those releases, we can support it meanwhile in COPR
21:07:01 <jistone> ignatenkobrain, is it too intrusive to backport officially?
21:07:17 <ignatenkobrain> jistone: problem is fedora infra mostly
21:07:34 <Pharaoh_Atem> pungi needs its new dnf based resolver merged
21:07:35 <ignatenkobrain> while it is possible to backport RPM features, infra can't be changed for stable releases
21:07:41 <Pharaoh_Atem> and koji needs to be ported to DNF
21:07:53 <ignatenkobrain> Pharaoh_Atem: all this is planned for F27
21:07:56 <Pharaoh_Atem> yep
21:08:04 <Pharaoh_Atem> and that will line up nicely for Mageia 7, too
21:08:07 <jistone> ok
21:08:30 <ignatenkobrain> and one thing which should be outcome from today's meeting is me understanding what to tell relengs
21:08:54 <ignatenkobrain> I promised that I will describe everything what we will need for F27
21:09:23 <Pharaoh_Atem> well, the mock thing is coming Real Soon Now(TM), so there's that
21:09:45 <Pharaoh_Atem> pungi just needs a final pass to make sure it's richdep compatible, then it can be merged in and supported
21:10:13 <Pharaoh_Atem> mash is "officially" going to be dead, since the "final version" of the signed repos stuff is awaiting final review for koji
21:10:32 <Pharaoh_Atem> so after that is merged, the priority should be making it possible for Koji to use DNF instead of Yum
21:10:56 <Pharaoh_Atem> the ARM and Live Media composes are already using DNF
21:11:35 <Pharaoh_Atem> though livecd-tools and Anaconda need to be checked over to be richdep compatible
21:11:42 <mich181189> Pharao_Atem: what's missing there? Is it just koji stuff, or are there DNF features missing that koji would need?
21:12:01 <Pharaoh_Atem> mich181189: Koji uses createrepo and Yum to parse and generate information about RPMs, as well as create repodata
21:12:35 <Pharaoh_Atem> Koji will crash if it attempts to process rich deps on Requires and Recommends (and maybe Suggests, too)
21:12:43 <Pharaoh_Atem> because Yum crashes when it encounters them there
21:12:48 <ignatenkobrain> tl;dr koji contains a lot of `import yum` inside :P
21:12:55 <mich181189> aha ok
21:13:09 <ignatenkobrain> but let's move to next topic
21:13:11 <ignatenkobrain> #topic Packaging Guidelines
21:13:16 <ignatenkobrain> #link https://pagure.io/fedora-rust/sig/issue/5
21:15:39 <ignatenkobrain> thoughts on this? what should I mention?
21:15:58 <jistone> do we anticipate the "target(windows)" patching to be a long-term requirement?
21:16:10 <Pharaoh_Atem> I'd hope we'd eventually do away with that
21:17:07 <ignatenkobrain> jistone: someone has to write that tokenizer and automagically strip stuff from Requires
21:17:12 <mich181189> should the whole not making dynamic libraries thing be mentioned?
21:17:15 <ignatenkobrain> probably I will do that over next week
21:17:47 <Pharaoh_Atem> it probably should be...
21:17:51 <jistone> mich181189, probably...
21:18:03 <Pharaoh_Atem> it's not a default policy thing, so it's probably quite important to mention
21:18:14 <jistone> it's sort of implicit already, because you'll be missing deps if you try to link libstd dynamically
21:18:23 <jistone> (they are filtered from Provides)
21:18:38 <mich181189> if nothing else the guidelines would be a good place to explain the policy
21:18:41 <jistone> cdylib is fine though
21:18:48 <Pharaoh_Atem> so number80 doesn't like the idea of giving Rust SIG only an exception for the SPDX thing
21:19:04 <ignatenkobrain> Pharaoh_Atem: I don't like exceptions either
21:19:04 <Pharaoh_Atem> which I agree, I would actually prefer if we were generally allowed to start using SPDX
21:19:08 <Pharaoh_Atem> and that we could just be first :)
21:20:11 <ignatenkobrain> jistone: cdylib?
21:20:21 <ignatenkobrain> how do we package that?
21:20:24 <jistone> *.so made for ffi use
21:20:31 <jistone> I don't know if we package that yet...
21:20:48 <Pharaoh_Atem> doesn't that mean we need to take special care when doing the dep generation for that?
21:20:58 <msehnout> Do we package librsvg?
21:21:18 <Pharaoh_Atem> we do
21:21:22 <jistone> librsvg is simpler, cargo builds as a staticlib, then that's linked into the full librsvg.so
21:21:22 <ignatenkobrain> msehnout: I suppose that we do and I guess that tere are a lot of bundled stuff
21:21:34 <jistone> iirc
21:21:38 <Pharaoh_Atem> librsvg is already in the distro, though
21:21:47 <Pharaoh_Atem> it's just going to start pulling in cargo+rust
21:21:51 <Pharaoh_Atem> for build
21:22:00 <mich181189> I'd imagine the fact it would make the package archful rather than noarch is a bigger headache than deps...
21:22:03 <msehnout> yes, it was just the only library that came to my mind
21:22:36 <ignatenkobrain> so for cdylib I would just mention that we just don't support it for now
21:22:39 <jistone> 2.41 added rust, looks like it was attempted once: https://koji.fedoraproject.org/koji/packageinfo?packageID=274
21:23:35 <jistone> I don't see build logs, but they probably need to vendor dependencies for now
21:23:54 <mich181189> I don't see a problem with cdylib in theory - just need to work out the details of how :-)
21:24:01 <ignatenkobrain> yeah
21:24:17 <ignatenkobrain> so far I didn't got into that point, so..
21:24:44 <jistone> I don't even know of any cdylib crates yet
21:24:50 <jistone> just something we should expect eventually
21:25:07 <ignatenkobrain> jistone: once we will encounter, we can take a look
21:25:31 <mich181189> makes sense. If I get really bored I might try writing a dummy one to play with
21:25:57 <ignatenkobrain> okay, anything else to mention in guidelines?
21:26:17 <Pharaoh_Atem> do we have like some kind of generic example template for guidelining with?
21:26:25 <Pharaoh_Atem> like how we do for Python, et al
21:26:29 <ignatenkobrain> Pharaoh_Atem: yes, look in the code :D
21:26:33 * ignatenkobrain is joking
21:26:40 <Pharaoh_Atem> heh
21:26:43 <ignatenkobrain> let me find
21:27:04 <Pharaoh_Atem> basically, for the published guidelines, having examples of a "library" and a "program" help quite a bit
21:27:06 <jistone> do we expect folks to always use rust2rpm?  or just suggest this
21:27:20 <Pharaoh_Atem> like the golang guys, we will strongly recommend rust2rpm
21:27:38 <ignatenkobrain> https://pagure.io/fedora-rust/playground/blob/master/f/serde/rust-serde.spec
21:27:41 <Pharaoh_Atem> but some people are automation haters, so we should give them the ability to work themselves to the bone :)
21:28:11 <ignatenkobrain> jistone: I would like to force people to use rust2rpm
21:28:32 <ignatenkobrain> because writing those version range dependencies
21:28:35 <Pharaoh_Atem> once they've worked themselves to the bone on doing it by hand, they'll eagerly use rust2rpm :)
21:28:35 <ignatenkobrain> with "features"
21:28:41 <ignatenkobrain> it's just too much time-consuming
21:29:01 <jistone> cdylib might be a case that makes more sense to do by hand
21:29:11 <ignatenkobrain> for example,
21:29:12 <ignatenkobrain> BuildRequires:  ((crate(syn) >= 0.11.0 with crate(syn) < 0.12.0) with crate(syn/visit))
21:29:17 <mich181189> even then it might be a good starting point
21:29:38 <mich181189> I don't think it matters what people use as long as the output is the same.
21:30:05 <ignatenkobrain> mich181189: what scares me more is that people will tend to omit versions
21:30:12 <ignatenkobrain> in (Build)Requires
21:30:16 <Pharaoh_Atem> yeah
21:30:18 <ignatenkobrain> which will lead always to problems
21:30:18 <msehnout> I think most people love automation when it comes to RPM packaging :-D
21:30:29 <Pharaoh_Atem> msehnout: RemiFedora doesn't
21:30:45 <Pharaoh_Atem> he doesn't even like the concept of dependency generators for php stuff :(
21:30:47 * ignatenkobrain never uses any automation tools for packaging apart from rust2rpm
21:30:59 <msehnout> Pharaoh_Atem, ok that's the first one I know about
21:31:10 <ignatenkobrain> because all of them generate useless specfile
21:31:21 <Pharaoh_Atem> gofed and rust2rpm are the only two I use
21:31:24 <mich181189> ignatenkobrain: hmm. Sounds like a guideline should be versions should be done this way then!
21:31:27 <msehnout> ignatenkobrain, :-)
21:31:27 <Pharaoh_Atem> gofed because... golang is insane
21:31:34 <Pharaoh_Atem> and rust2rpm because it actually works
21:31:48 <ignatenkobrain> Pharaoh_Atem: gofed produces 300 lines for simple thing
21:31:50 <Pharaoh_Atem> pyp2rpm is getting there, but it's not quite there yet
21:31:54 <mich181189> I don't think you can force people because that just causes people to copy/paste and make more subtle mistakes if they're determined
21:31:55 <ignatenkobrain> because they don't know what is RPM macro
21:32:01 <Pharaoh_Atem> ignatenkobrain: I blame the Docker team
21:32:22 <Pharaoh_Atem> the Docker packaging guys made gofed and made it impossible to read any golang package spec
21:32:42 <Pharaoh_Atem> good ideas, horrid implementation
21:32:54 <ignatenkobrain> that's what I wanted to avoid. and I think we're in good shape with this
21:33:13 <ignatenkobrain> at least, I like ripgrep's spec: https://pagure.io/fedora-rust/playground/blob/master/f/ripgrep/ripgrep.spec
21:33:29 <Pharaoh_Atem> and lo, a readable, autogenerated spec
21:33:36 <Pharaoh_Atem> I've only seen that with pyp2rpm and rust2rpm :)
21:33:42 <mich181189> yeah. I think it should be strongly advised to use it, with a packaging guideline that dependencies must be used as rust2rpm would
21:34:03 <Pharaoh_Atem> which means we're going to have to actually document how rich deps work
21:34:14 <Pharaoh_Atem> because no one in Fedora understands them, because most people are stuck in ~2009 :(
21:34:18 <ignatenkobrain> #agreed to strongly advise usage of rust2rpm
21:34:41 <ignatenkobrain> #action ignatenkobrain to prepare draft until next meeting
21:34:51 <ignatenkobrain> #topic Integration of system registry
21:34:55 <ignatenkobrain> #link https://pagure.io/fedora-rust/sig/issue/6
21:34:57 <ignatenkobrain> #link https://pagure.io/fedora-rust/sig/issue/6
21:35:20 <Pharaoh_Atem> this seems like a "cargo need change" kind of thing
21:35:23 <jistone> yes
21:35:30 <ignatenkobrain> I have no idea how to do that and whether it's possible at all :D
21:35:30 <Pharaoh_Atem> it's an excellent idea, though
21:35:35 <ignatenkobrain> but this would be very cool
21:35:35 <jistone> ISTR a cargo issue on this already, but couldn't find it
21:35:44 <Pharaoh_Atem> the Java guys do this now with gradle and a few other build tools
21:35:50 <mich181189> what exactly are the issues here? as I understand it we already kinda have this with the config hack. How would this go beyond that?
21:36:10 <mich181189> java has a mvn-local package for this purpose I think
21:36:10 <ignatenkobrain> mich181189: config hack works when building packages
21:36:20 <ignatenkobrain> but I want to have proper integration in cargo
21:36:23 <Pharaoh_Atem> we want to make our registry preferred
21:36:29 <Pharaoh_Atem> like how Java does it
21:36:33 <ignatenkobrain> so if it will find package in local registry, it will use it
21:36:36 <mich181189> ok yeah I got it
21:36:37 <Pharaoh_Atem> ^
21:36:50 <ignatenkobrain> Pharaoh_Atem: yeah, mizdebsk does a lot of good stuff :)
21:36:57 <Pharaoh_Atem> mizdebsk is amazing
21:37:03 <mich181189> I guess it needs to be a prefers rather than the hack's replace as well
21:37:06 <Pharaoh_Atem> and supremely helpful
21:37:26 <Pharaoh_Atem> for package builds, it should be a full-on replace
21:37:43 <Pharaoh_Atem> for development purposes, it should be a preference thing
21:37:48 <mich181189> Pharaoh_Atem: agreed
21:38:58 <mich181189> So I guess what we want is some sort of config block to specify repos to check first. We could then install a config file to point it at the local repo
21:39:12 <ignatenkobrain> jistone: so, can you find/open issue for cargo about this and cross-link it to pagure issue?
21:39:37 <jistone> yeah, looking again now, but if I don't find it I'll open one
21:39:38 <ignatenkobrain> not now, but when you will have time :)
21:39:59 <Pharaoh_Atem> jistone: I don't see one on rust-lang/cargo
21:40:07 <Pharaoh_Atem> so I think you'll have to open one
21:40:12 <jistone> np
21:40:25 <ignatenkobrain> #action jistone to find/open cargo issue for system-wide registry and cross-link it to pagure
21:40:32 <ignatenkobrain> #topic Open Floor
21:40:45 <ignatenkobrain> so, I forgot to mention about packaged applications
21:41:00 <ignatenkobrain> you don't need any patched RPM/dnf, you can enable repo and just install binaries
21:41:07 <ignatenkobrain> since they don't have any fancy dependencies
21:41:13 <Pharaoh_Atem> it's only needed for building, right?
21:41:24 <ignatenkobrain> for -devel packages and for building, yes
21:42:03 <Pharaoh_Atem> coolness
21:42:08 <ignatenkobrain> jistone: do you know whether debuginfo is generated correctly nowadays?
21:42:29 <jistone> it should be
21:42:38 <Pharaoh_Atem> afaik, it should be now, since mjw did the fixes and they're in Fedora now
21:42:42 <Pharaoh_Atem> have been for a little while
21:42:43 <ignatenkobrain> when I build, I get bunch of "Missing source for librust.a" or such
21:42:55 <ignatenkobrain> didn't remember real error
21:43:00 <ignatenkobrain> (well, warning)
21:43:11 <Pharaoh_Atem> you need up to date elfutils, I think
21:43:12 <jistone> oh, well, there may be some oddness around source paths
21:43:37 <msehnout> I was just thinking, we are having an event for students in Brno Red Hat's office, do you think it would be worth proposing a talk about Rust in Fedora? Is there enough things to talk about for 20-30 minutes?
21:43:59 <ignatenkobrain> Reading symbols from /usr/bin/rg...Reading symbols from /usr/lib/debug/usr/bin/rg.debug...done. done. warning: Invalid entry in .debug_gdb_scripts section
21:44:04 <jistone> rpm debuginfo rewrites paths to /usr/src/debug/... but this doesn't help for things you get from an rlib
21:44:05 <Pharaoh_Atem> I think ignatenkobrain could chat up a room all day :)
21:44:14 <jistone> ignatenkobrain, for that, use the rust-gdb wrapper
21:44:20 <ignatenkobrain> jistone: I use it :)
21:44:27 <ignatenkobrain> $ rust-gdb --args /usr/bin/rg foo
21:44:40 <jistone> ah, then maybe that's broken...
21:44:45 <jistone> file a bug please?
21:45:18 <jistone> and really, I need to get this into /etc/gdbinit.d/ so the wrapper isn't needed
21:45:23 <ignatenkobrain> #action ignatenkobrain to file a bug about broken(?) generated debuginfo for new binaries
21:45:46 <ignatenkobrain> msehnout: what kind of talk?
21:46:25 <jistone> Pharaoh_Atem shared slides from a talk he gave recently
21:46:28 <Pharaoh_Atem> yes
21:46:30 <ignatenkobrain> msehnout: though establishing local Rust group would be nice
21:46:32 <msehnout> Not sure yet. Maybe something about what is Rust and how to make a RPM package from it
21:46:33 <Pharaoh_Atem> I was about to share them again
21:46:37 <ignatenkobrain> Pharaoh_Atem: remind me link?
21:46:47 <Pharaoh_Atem> here are my slides from my talk back at the beginning of February: https://files.norwalklinux.space/presentations/2017/mtg2017-02-01-rust-and-fedora.pdf
21:47:01 <ignatenkobrain> #info Pharaoh_Atem has nice slides -- https://files.norwalklinux.space/presentations/2017/mtg2017-02-01-rust-and-fedora.pdf
21:47:21 <ignatenkobrain> msehnout: I'm planning to make talk about this on Flock
21:47:32 <ignatenkobrain> which should be this August in US
21:47:35 <ignatenkobrain> IIRC
21:47:43 <ignatenkobrain> hopefully, jistone will join :)
21:47:48 <ignatenkobrain> and all others
21:48:03 <Pharaoh_Atem> I'd love to be there :(
21:48:13 <Pharaoh_Atem> sadly, outlook not so good
21:48:22 <jistone> I'd like to, but my August plans are very tentative right now
21:48:26 <Pharaoh_Atem> I'll be at Red Hat Summit, but I dunno about Flock
21:48:50 <msehnout> ignatenkobrain, this would be much shorter talk, anyway you are from Brno office right?
21:48:51 <ignatenkobrain> msehnout: golang guys have Coding Dojo every week, so probably we should become their competitors
21:48:54 <jistone> rustconf is also in August, which is a higher priority for me
21:49:15 <ignatenkobrain> msehnout: yes, I am
21:49:24 <ignatenkobrain> though I tend to work from home :)
21:49:57 <msehnout> ignatenkobrain, that would be very nice to meet some people also interested in Rust
21:51:34 <Pharaoh_Atem> jistone: if you're at Summit, we should meet up :)
21:51:43 <ignatenkobrain> msehnout: yeah, so let's discuss local things offline :) w/ some beer
21:51:45 <Pharaoh_Atem> as far as I know, I shouldn't expect ignatenkobrain there :P
21:51:54 <jistone> redhatters, please make sure to join our internal #rust community too :)
21:52:25 <ignatenkobrain> jistone: also, what's important that internal #rust community should join #fedora-rust community :)
21:52:38 <Pharaoh_Atem> Yes!
21:52:48 <jistone> Pharaoh_Atem, I'm not sure about Summit... haven't ever attended before
21:52:51 <Pharaoh_Atem> more Rustaceans(?)
21:52:54 <Pharaoh_Atem> !
21:53:23 <Pharaoh_Atem> jistone: I find it to be a very fascinating event, so if you have the chance, you should go
21:54:52 <Pharaoh_Atem> they also have a developer-y track, which is interesting
21:56:35 <ignatenkobrain> jistone: btw, any news about [workspace] stuff and path thing?
21:56:57 <ignatenkobrain> kinda annoying to fix Cargo.toml everytime :)
21:57:01 <jistone> uh, no.  jeez, I need to check my backlog
21:57:20 <ignatenkobrain> although with -p option, it's very easy
21:57:35 <ignatenkobrain> it opens file automagically and when I save it, it creates patch
21:58:40 <ignatenkobrain> jistone: not urgent, but just reminding :)
21:59:32 <ignatenkobrain> anything else?
21:59:36 <ignatenkobrain> we have half minute ;)
22:00:01 <ignatenkobrain> #endmeeting