15:44:45 <bero> #startmeeting
15:44:45 <chwido> Woof! Let's start the meeting. It's Wed Aug 28 15:44:45 2019 UTC. The chair is bero. Information about me at https://wiki.openmandriva.org/en/Chwido.
15:44:45 <chwido> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:44:45 <chwido> You should add extra chair(s) just in case, with #chair nick.
15:44:45 <chwido> Have a good meeting, don't bark too much!
15:44:52 <bero> chwido: pingall meeting
15:44:52 <chwido> meeting
15:44:52 <chwido> Aberts10[m] AngryPenguin ashledombos[m] ben779 ben79 bero ChanServ christann chwido crazy Eighth_Doctor fdrt Github[afsanemat Github[m]1 gmoro herde[m] HisShadow Izaic[m] JLP King_InuYasha Pharaoh_Atem ptaknielot[m]1 RingtailedFox RSSBot[afsanema4 RubberSoul[m]
15:44:52 <chwido> rugyada ruru[m] vinzv Xu_R xulike[m]
15:44:52 <chwido> meeting
15:44:59 * bero barks at ChanServ
15:45:01 <bero> and at chwido
15:46:13 <bero> so... Agenda:
15:46:18 <bero> State of Rolling
15:46:18 <bero> OMLx 4.1 release plan, workflow, milestones
15:46:18 <bero> Github replacement
15:46:27 <bero> #topic State of Rolling
15:46:44 <bero> As far as I'm concerend, cooker is in good enough shape to push to rolling now...
15:46:45 <christann> Hi all. I am back from holidays.
15:46:50 <bero> wb christann!
15:46:56 <christann> Thanks
15:47:21 <rugyada> hi christann, WB
15:47:58 <bero> So I'd propose we push cooker to rolling, run some tests, build an iso, and when we're more or less satisfied, announce rolling publicly (while pointing out that it's only being started now and some glitches are still expected to occur)
15:48:03 <bero> Other thoughts?
15:49:37 <AngryPenguin> need few rebuilds for iso
15:49:43 <AngryPenguin> falkon plugins
15:49:49 <AngryPenguin> for example
15:50:10 <AngryPenguin> anyway I agree
15:52:14 <bero> Let's do those first... Anything else that needs to be rebuilt?
15:53:02 <bero> and what's wrong with current falkon-plugins? Seems to work fine here and has been rebuilt a few days ago
15:53:19 <bero> but can't hurt to rebuild again...
15:53:34 <AngryPenguin> http://file-store.openmandriva.org/api/v1/file_stores/a7e602bf5806f0a211347ce1c3855dbb3b7ac4ca.log?show=true
15:53:44 <AngryPenguin> nothing provides libshiboken2.cpython-37m-x86_64-linux-gnu.so.5.12()(64bit) needed by falkon-plugins-3.1.0-6.x86_64
15:54:29 <AngryPenguin> and when you touch falkon you see this http://file-store.openmandriva.org/api/v1/file_stores/ac3182aeb004faad338b9e1cc07205cfcab9691d.log?show=true
15:55:29 <bero> ah... that explains things, I have some local builds here
15:55:44 <bero> shiboken is updated to 5.13 but pyside2 failed to build with it
15:55:54 <bero> so fixing that should make the falkon thing go away by itself
15:56:07 <bero> fixing...
16:00:34 <AngryPenguin> ruru[m] added gnome-tweaks package
16:01:43 <AngryPenguin> unfortunately, along with it, unknown dependency pulls several -devel packages to installation
16:02:36 <itchka> Back. 4G signal interruption
16:02:52 <ruru[m]> AngryPenguin:  ok, ty
16:03:05 <bero> wb itchka
16:03:46 <bero> itchka: meeting is on, currently talking about pushing cooker to rolling -- are you done with the kahinah testing you wanted to do before?
16:06:19 <novichok_agent> i need to go away soon  for a time
16:06:24 <novichok_agent> than ask your questions
16:06:27 <itchka> I have managed to establish that we can clear all the files from kahinah. Unfortunately my attempts to test it by pushing a package through testing failed because publish to QAis set to zero. This needs to be changed for rolling so that all packages go though testing.
16:06:44 <novichok_agent> btw cooker image for RaspberryPi3 b+ working fine
16:07:08 <bero> novichok_agent: that's great news, what did you have to change for hdmi?
16:07:18 <novichok_agent> nothing
16:08:00 <bero> novichok_agent: can we have a modification in abf that allows setting publish to QA without setting to released? (rolling --> should not go to updates/, but still need kahinah)
16:08:27 <novichok_agent> i asked hisshadow
16:10:08 <itchka> We can't really move forward unless this is done.
16:10:18 <novichok_agent> hissahdow said that he in gypsum now and can't type a lot of letters
16:10:25 <novichok_agent> but wil do it on the next week
16:11:12 <novichok_agent> https://github.com/OpenMandrivaSoftware/rosa-build/issues make issue
16:11:18 <bero> good...
16:11:26 <itchka> Is that you fedya?
16:11:30 <novichok_agent> yes
16:11:47 <itchka> Intersting new handle!!
16:11:50 <novichok_agent> No it's a special agent Boshirov :D
16:12:08 <itchka> HeHe :)))
16:13:25 <novichok_agent> just make an issue
16:13:48 <itchka> Ok will do
16:13:53 <ben79> So for rolling to be maintained we really need Kahinah working and we really need for packages to publish to testing repo by default don't we?
16:14:38 <bero> https://github.com/OpenMandrivaSoftware/rosa-build/issues/86
16:15:37 <bero> ben79: we just have to be extra careful before it's there, we can publish to testing even when it's not enabled by default
16:16:08 <itchka> bero: Can you do that from the abf web page?
16:17:21 <bero> itchka: yes, change the "Automated publishing" setting from "Default" to "Into 'testing'"
16:17:53 <itchka> Ok thanks. I'll run a quick kahinah test
16:18:42 <ben79> bero: Yes, and base on that I suppose we should go ahead and copy cooker to rolling when whatever package builds are done.
16:19:33 <bero> yes, IMO we should go ahead with that to start testing rolling properly
16:23:22 <Pharaoh_Atem> bbs, getting lunch
16:28:11 <itchka> Building a package for rolling will test with current repo if ok I guess we can go ahead with copy process
16:31:14 <ben79> publishing packages "Into testing" should work it has been done a lot already
16:32:19 <rugyada> shall we do an action for this?, like: We need to be extra careful while publishing for Rolling: change the "Automated publishing" setting from "Default" to "Into 'testing'"
16:32:53 <itchka> It's not that bit I'm testing. I want to see whether a. kahinah picks up the package and b. Whether it actually processes it properly.
16:34:46 <bero> yes, we need to verify kahinah does the right thing...
16:34:58 <bero> other than that it's just a matter of being careful to make sure the testing options are enabled
16:35:59 <itchka> Well the packages are published to the right place...lets see whether kahinah picks them up.
16:58:29 <itchka> Well so far kahinah has not picked up the packages. I know it polls but I don't know how often.
16:59:46 <ben79> I usually takes hours before Kahinah picks up a new package
17:01:24 <itchka> Ok I guess we will just wait.
17:04:37 <ben79> ah what fun!
17:08:12 <ben79> But we should be able to confirm whether Kahinah is/isn't working properly and if not what isn't working
17:08:29 <ben79> So these tests a kind of a big deal.
17:08:42 <bero> right...
17:08:49 <bero> but I presume we can't wait forever with the meeting
17:08:56 <bero> let's check again before we're closing it...
17:09:03 <bero> and in the mean time move on to the next topic?
17:09:34 <bero> Or does anyone have anything to add to the Rolling topic that doesn't require kahinah?
17:10:47 <ben79> No, just that when ever developers are ready go ahead and do it.
17:11:09 <ben79> I presume this means we wipe all rolling repos and copy all cooker to rolling?
17:12:05 <itchka> Not as far as I know
17:12:28 <bero> ben79: yes
17:12:46 <bero> minus the distro-release package obviously, if we copied that one over rolling would update to cooker
17:14:18 <ben79> OK
17:14:47 <ben79> I'm thinking it is very important to get all the redundant packages out of testing repos.
17:15:23 <itchka> ben76: I already did that
17:15:47 <ben79> And then in future QA has to be mindful of paying attention to whether Kahinah is moving packages out of testing, if it doesn't we need to do it manually or the testing repos get clogged up
17:16:48 <itchka> If it's doing that ben79 the priority is to get Xu_R to fix kahinah if its broken
17:16:52 <ben79> itchka: there are still packages in unsupported, restricted and non-free, testing
17:17:05 <ben79> QA has to maintain all repos not just main
17:18:57 <AngryPenguin> just one question, after copy cooker to rolling, we should build packages for rolling "manually" or script care about it automatically?
17:19:55 * ben79 Excellent question,
17:20:36 <ben79> My guess: Initially manually or the packages will publish directly to release repos which we don't want to do.
17:21:12 <bero> AngryPenguin: we have the script that will do it automatically, but we have to maintain the list of packages that will NOT go to rolling
17:21:31 <bero> (and of course push the blacklisted ones manually when they're ready)
17:22:37 <ben79> So in theory, if all is working properly, after we get this all set up and working then QA maintenance workflow would be like:
17:24:25 <ben79> Move packages from testing to rolling/release with Kahinah, if packages aren't blacklisted for stable use rolling2<what> script of move packages to stable/testing and then use Kahinah again to move them to stable/updates
17:26:15 <ben79> rolling2rock looks like
17:27:34 <ben79> I can report that if our forum posters are any indication there is massive confusion among users about what repos to enable, particularly we see many that enable Rock and Cooker repos together.
17:28:31 <ben79> Not sure what to do about that except to keep correcting them as it comes up, but I'm sure we will emphasize this in our blog post announcing the Release Plan and Rolling release
17:30:40 * Pharaoh_Atem is back
17:31:03 <bero> IMO most packages should not go to rock
17:31:10 <bero> rock is for people who want dinosaurs
17:32:03 <bero> nobody should have more than one of 4.0, rock, rolling or cooker enabled
17:32:10 <bero> mixing them will break things
17:34:06 <ben79> bero: If that is not clearly stated here then I can
17:34:23 <ben79> bero: If that is not clearly stated here then I can't state it clearly: https://wiki.openmandriva.org/en/OpenMandriva_Release_Plan_and_Repositories
17:35:46 * ben79 Definition of documentation >>> Documentation is something users complain about if you don't have, but if you do have no one reads it!
17:36:43 <ben79> But by all means if I did not make this clear in that OM-Wiki page please let me know or re-write the sections that need it
17:36:57 <bero> IMO it's clear...
17:37:05 <bero> but people apprently don't read it
17:37:33 <bero> and they don't use om-repo-picker either (the tool doesn't allow selecting multiple versions)
17:39:12 <itchka> Ok python-click has appeared in kahinah :)
17:39:37 <itchka> Lets see what happens if I Qa push it.
17:43:14 <AngryPenguin> bero what wrong here https://github.com/OpenMandrivaAssociation/task-xfce/blob/master/task-xfce.spec#L60
17:44:03 <AngryPenguin> L60: %ifnarch %{ix86}
17:44:17 <bero> AngryPenguin: nothing... looks exactly right... What's not working?
17:44:36 <AngryPenguin> so package thunar should be installed only on not i686 arch right
17:44:43 <AngryPenguin> but i686 dont pass test
17:44:53 <AngryPenguin> package task-xfce-minimal-2:4.14-1.noarch requires thunar-volman, but none of the providers can be
17:45:04 <bero> It's required again in line 66, but only as Recommends...
17:45:35 <AngryPenguin> recommends - so should be fine even if package is not available/installable
17:45:53 <bero> yes
17:45:59 <bero> it shouldn't require it (at least not directly)
17:46:08 <AngryPenguin> or I misunderstand "recommends"
17:46:15 <bero> maybe one of the gazillion other packages it requires requires thunar-volman as well
17:47:13 <itchka> Well it looks as if kahinah doesn't delete the published rpms so it is definately broken in some way.  Perhaps it's because it relies on some aspect of the repository being released.
17:50:27 <bero> Xu_R: ^^^ any idea?
17:51:33 * ben79 Added this to Release Notes: https://wiki.openmandriva.org/en/4.0/Release_Notes#About_Repositories
17:53:21 <bero> ben79: good... might make sense to point out that you can switch to cooker though (but if you do, disable rock) -- or just use om-repo-picker which supposedly does the right thing if you tell it to switch to cooker
17:56:43 <ben79> Um, that will require some thought, but based on the level of dialog I'm seeing on our forum I don't want to give most users to many options.
17:57:29 <ben79> They already do mind numbingly stupid things
17:58:36 <ben79> but my sincere hope is that forum posters are not representative of our users
18:11:00 <bero> I think they are...
18:11:18 <bero> 3 people on the forum, 3 users total --> 100% of users represented
18:11:51 <bero> Chwido needs to go outside (or is pretending to, one of the dogs in the neighborhood is in heat, so he currently tries to escape at every opportunity)... brb
18:58:53 <ben79> jjjvvvvvv
19:01:47 <rugyada> ben79:  whatever it means, I tend to agree
19:03:43 <rugyada> btw chwido must be a true playboy :)
19:28:02 <bero> back
19:32:31 <bero> has kahinah made any progress already?
19:32:37 <bero> And/or can we move to the next topic?
19:33:46 <ben779> next topic
19:34:11 <ben779> itchka has verified that there is a problem with Kahinah
19:35:42 <ben779> Kahinah does not remove packages from testing repo when it moves package to release repo
19:35:44 <bero> #topic OMLx 4.1 release plan, workflow, milestones
19:36:17 <bero> So for those who aren't on the Council or weren't in last week's meeting, the topic of 4.1 has come up there and the thought is having a 4.1 release quickly
19:36:56 <bero> A lot of the things we wanted for 4.1 are done, it's significantly better than 4.0, essentially there's not a lot of things holding back releasing 4.1 and starting the 4.2 process
19:37:16 <bero> this isn't 5.0, so it doesn't have to be as huge a change as 4.0 was...
19:37:49 <bero> I've been thinking that once cooker is moved to rolling and we've had a week to test it and iron out rough edges, we could build a 4.1 alpha 1 release from the rolling tree
19:38:14 <bero> it would also keep us in the news -- announcement of rolling now, 4.1 alpha release a week or maybe 2 later
19:38:41 <ben79> works for me
19:41:34 <ben79> In view of that I've already been testing Cooker as if it were Rolling and as if were were going to become a development release
19:42:12 <ben79> all the default packages I checked at least open, I did not find anything not working
19:44:05 <AngryPenguin> maybe with  announcement of rolling we should mention also new deskops?
19:45:37 <ben79> In Cooker lxqt does not want to install
19:45:59 <ben79> I don't know if we really have made lumina an official OM desktop
19:47:05 <ben79> I thought lxqt was "Officially" supported
19:47:58 <bero> lxqt currently needs fixing, looks like some perl stuff hasn't been rebuilt for 5.30 yet
19:48:03 <bero> that should be easy to fix though
19:48:08 <bero> let me fix it right now
19:48:25 <bero> Haven't tried lumina yet
19:48:42 <AngryPenguin> lumina, lxqt, xfce, gnome, cinnamon, mate
19:49:25 <ben79> Um, this is border line funny: - nothing provides fluxbox needed by lumina-1.5.0p-1.x86_64
19:49:34 <ben79> Cooker ^^^
19:50:01 <bero> nothing too funny about it -- fluxbox is one of the packages that got cleaned out by removing anything with a 3.x release tag
19:50:10 <AngryPenguin> bero I really want deepin desktop :)
19:50:27 <bero> AngryPenguin: no reason not to try building it...
19:50:43 <bero> it's less atrocious than xfce, gnome, cinnamon or mate
19:52:04 <ben79> I think there should be separate announcements for officially supported desktops (when they are ready) and community supported desktops? Or same announcement with 2 lists?
19:52:25 <bero> either announcement would work for me
19:52:27 <ben79> do xfce, gnome, cinnamon, and mate all work now?
19:53:02 <ben79> because if the do that is certainly something well worthy of announcing, and blogging
19:53:49 <AngryPenguin> xfce should work, need to check one issue reported by ruru
19:53:53 <AngryPenguin> gnome work
19:53:56 <AngryPenguin> cinnamon too
19:54:04 <AngryPenguin> mate not tested from last month
19:54:06 <AngryPenguin> need check
19:54:23 <rugyada> I wish I could find a desktop I *may* like, except Plasma
19:54:29 <rugyada> no luck so far
19:54:36 <AngryPenguin> trinity xD
19:55:02 <ben79> Illumos is the Oracle desktop of the future!
19:55:25 <ben79> Illumos is the Solaris desktop of the future!
19:55:46 <rugyada> AngryPenguin:  will test deepin when/if available
19:56:29 <AngryPenguin> good but to build this desktop we
19:56:34 <AngryPenguin> need baro help
19:56:40 <AngryPenguin> *bero
19:56:53 <bero> just let me know what needs to be done
19:57:02 <ben79> Nothing is perfect in Linux, that's why OM Lx 5.0 should switch to ____________
19:57:35 <bero> lxqt is fixed btw
19:58:03 <bero> Well, we could build a new OS based on the recent release of DOS source code... ;)
19:58:54 <ben79> yeah, that's it, that's the ticket!
19:59:14 <bero> Then port GTK to it so we have a nice API ;)
20:00:35 <ben79> Well any way we seem to have some agreement about 4.1 release?
20:01:06 <ben79> And some agreement that we need to do some announcing and blogging about different desktops.
20:01:38 <bero> Guess so...
20:01:52 <bero> #action copy cooker to rolling
20:02:11 <ben79> And give a big thanks to the persons who make these available.
20:02:12 <bero> #action announce rolling (with caveats of the whole thing being beta for now)
20:02:20 <bero> #action announce desktops
20:02:29 <bero> #actions get ready for 4.1 alpha release
20:02:35 <bero> #action get ready for 4.1 alpha release
20:03:06 <bero> #action stop adding too many actions for  the topic ;)
20:05:29 <bero> https://liri.io/ -- may be another desktop to look at, I think we've even built parts of it before
20:09:09 <ben79> that does look interesting
20:11:33 <ben79> FWIW: Just quick check in Rock/VBox LXQt shows a different error than Cooker: - nothing provides lxmenu-data needed by task-lxqt-0.14.0-1.noarch
20:12:02 <AngryPenguin> need rebuild
20:12:09 <bero> another package that was removed in the 3.x purge apparently
20:12:13 <ben79> Rock > Lumina: shows same error as cooker needs flubox
20:12:30 <bero> both are fixed in cooker
20:12:35 <bero> (as of a few minutes ago)
20:13:15 <bero> Anything else on 4.1?
20:13:24 <ben79> Maybe we should announce that we purged repos of all packages built on rpm5 so if users find anything missing they need to make a package request in Bugzilla?
20:13:47 <AngryPenguin> on 4.1 we should release iso spins xD
20:13:53 <ben79> That's OT from 4.1 so excuse me.
20:15:34 <ben79> As far as ISO spins if we do that right it is a good way to get additional publicity.
20:16:33 <ben79> Do the Official 4.1 release and 2 weeks later do a Community spin of XFCE then in 2 more weeks or so Community spin of Gnome and so on
20:17:24 <AngryPenguin> yes but for now we need working iso building script with unsupported repo
20:17:28 <ben79> Guess I do have one more thing for 4.1 > Can we do a LXQt release of 4.1 also? Lumina?
20:18:06 <ben79> Or is to much to soon?
20:18:28 <AngryPenguin> we can release all this desktop
20:19:05 <bero> IMO we should, but of course the desktops need some more testing
20:19:31 <bero> adding unsupported support to the iso builder should be easy enough, I'll probably get around to it tomorrow
20:20:37 <AngryPenguin> good
20:20:38 <AngryPenguin> thanks\
20:24:43 <ben79> bero: Well we could transmorgity what I said to OM Lx 4.1 release: Do Official Plasma release and then 2 weeks later add LXQt release and another 2 weeks add Lumina release?
20:25:00 <rugyada> AngryPenguin: what is the command to install cinnamon, exactly?
20:25:05 <ben79> Anyway just thought for getting us more attention in Linux media.
20:25:10 <bero> yes, works for me...
20:26:07 <AngryPenguin> rugyada: cinnamon or task-cinnamon
20:26:21 <rugyada> AngryPenguin:  ty
20:26:23 <ben79> If AngryPenguin has done the work and has these other desktops ready I'd sure like to see some spins of those as well.
20:27:19 <ben79> but sounds like our ISO builder is not so happy with that
20:29:34 <ben79> If those desktops are available in 4.1 then that certainly should be announced and blogged
20:30:53 <ben79> anyway we should probably move on to Github replacement
20:33:56 <AngryPenguin> +
20:37:16 <bero> right
20:37:20 <bero> #topic Github replacement
20:37:43 <bero> so also at the council meeting we've decided we need to make sure we don't suffer from outages when moving to our own infrastructure
20:38:16 <bero> our git repositories being inaccessible for days would certainly slow us down badly
20:38:51 <bero> so I've been looking at options to make sure it doesn't happen even though our infrastructure is... let's say "cost optimized"
20:39:57 <bero> Good news to report there -- I've been able to set up a git repository that fully automatically mirrors itself to github.com, gitlab.com and any other public servers we may want to use (nothing wrong with using them as backups -- the only problem with them is that we can't depend on them because of export restrictions etc)
20:40:34 <bero> If anyone wants to try it out, send me a ssh public key so I can add you to the committers of the test repo
20:41:37 <bero> It currently lives at git@filzbach.lindev.ch:test-for-git-mirroring.git and is mirrored to https://github.com/OpenMandrivaSoftware/test-for-git-mirroring and https://gitlab.com/berolinux/test-for-git-mirroring
20:42:21 <bero> What I have for mirroring isn't perfect yet, we need to make it more generic (right now it's a script that has to be copied to every repository -- not exactly scalable), but the good news is it's doable and we know how to do it
20:42:51 <bero> so we can migrate to our own infrastructure and if it breaks down for some reason, just switch over to one of the mirrors and sync the changes from there back to our infra when it comes back
20:47:27 <ben79> So that's some good work and very important for security of the distro
21:03:43 <bero> we can also do some more powerful things if we want to...
21:04:04 <bero> now that we know when something is being committed, we could also do things like automatically triggering a package build when a change to the package is committed
21:04:17 <bero> not sure if we want to do that though given people sometimes commit stuff that isn't ready
21:04:41 <bero> but we could add a keyword in the commit message that would prevent the build trigger from firing
21:04:47 <bero> not sure, what are people's thoughts?
21:06:41 <AngryPenguin> good idea
21:06:53 <bero> we could even automatically reject a commit if it breaks building the package -- not sure if we could also just redirect it to a different branch or so, some things remain to be tested
21:36:44 <bero> anything else?
21:37:15 <christann> AngryPenguin: Am running cinnamon now (on ROCK) and it appears to work. Plan to upgrade to Rolling tomorrow.
21:39:13 <rugyada> christann: not the best idea upgrade to rolling right now
21:39:33 <christann> Okay. Thanks.
21:40:27 <ben79> chwido bark humans
21:40:28 * chwido barks at humans.
21:41:10 <ben79> chwido bite gtk_engineers
21:41:11 * chwido thinks about biting gtk_engineers but decides to not to.
21:41:22 <ben79> come on chwido bite
21:44:28 <ben79> anyway the human is barking and I need to let him out for a walk...
21:45:28 <AngryPenguin> bugs now?
21:45:49 <ben79> do you have any?
21:46:45 <AngryPenguin> yes
21:46:54 <ben79> go ahead
21:47:14 <ben79> the human can wait a few minutes
21:48:12 <AngryPenguin> 2536 - crash at wayland session
21:48:36 <AngryPenguin> 2534 - broken typelib generator
21:49:52 <ben79> http://issues.openmandriva.org/show_bug.cgi?id=2534
21:50:04 <ben79> http://issues.openmandriva.org/show_bug.cgi?id=2536
21:52:25 <ben79> Does anyone work on wayland other than TPG?
21:52:59 <AngryPenguin> wayland session works fine on plasma
21:53:02 <AngryPenguin> few weeks ago
21:53:06 <AngryPenguin> now is broken
21:54:40 <ben79> wayland never worked fine for me on Intel HW, when you can login to it things crash and freeze, or freeze and crash
21:55:34 <ben79> I actually check that every so often.
21:56:06 <AngryPenguin> well, worked for me on radeon
21:56:35 <ben79> Usually to get out of wayland for me is Ctrl>Alt>BkSp
22:00:51 <AngryPenguin> wayland session should works fine on radeon hardware
22:01:00 <AngryPenguin> and worked few weeks ago
22:01:07 <AngryPenguin> now sometings is broken
22:01:38 <ben79> I'm no help so
22:01:55 * ben79 I'll be back in a while
22:02:03 <AngryPenguin> fortunately this is not the main session, but I think it's worth looking at it
22:02:59 <AngryPenguin> more and more people are starting to use this session, so we need to put more care on it
22:48:17 <ashledombos[m]> bero for git mirroring it should be able to do this for a whole organization (github name)
22:48:38 <ashledombos[m]> in OMAssociation, we have around 20000packages
23:23:39 <ashledombos[m]> I did not see #endmeeting
23:27:47 <ben79> #chair
23:28:49 <ben79> #chair nick
23:28:55 <ben79> chwido bite nick
23:28:56 * chwido thinks about biting nick but decides to not to.
23:29:04 <ben79> #chair ben79
23:41:09 <ben79> I just wonder if novichok_agent ever got Civ III working. That looks like an actual interesting game.
23:43:00 <AngryPenguin> civ v better xD
00:01:42 <bero> ashledombos[m]: we've been mirroring those packages from github for months, the change now is that we can do it the other way and we can trigger the mirroring instantly on commit, not by a cronjob
00:02:28 <bero> ben79: Civ III works, the wine bug novichok_agent pointed at actually has a patch attached
00:02:41 <bero> not sure we want to apply that patch in the package though given it might break other stuff
00:02:47 <bero> I'll take a closer look when I have time
00:02:51 <bero> #chair ben79
00:02:51 <chwido> Current chairs: ben79 bero
00:02:54 <bero> #chair ben779
00:02:54 <chwido> Current chairs: ben779 ben79 bero
00:03:00 <bero> #chair itchka
00:03:00 <chwido> Current chairs: ben779 ben79 bero itchka
00:25:27 <ben79> #endmeeting