16:02:56 <itchka> #startmeeting
16:02:56 <chwido> Woof! Let's start the meeting. It's Wed Nov 18 16:02:56 2015 UTC. The chair is itchka. Information about me at https://wiki.openmandriva.org/en/Chwido.
16:02:56 <chwido> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:02:56 <chwido> You should add extra chair(s) just in case, with #chair nick.
16:02:56 <chwido> Have a good meeting, don't bark too much!
16:03:23 <itchka> #chair bero
16:03:23 <chwido> Current chairs: bero itchka
16:06:16 <itchka> who's here ashledombos avokhmin ben79 bero crisb fedya gmoro itchka jclv mdawkins n3npq nicco oiram73 OnlyHuman Pharaoh_Atem radix_pm
16:06:29 <mdawkins> here
16:06:32 <itchka> Here
16:06:34 <radix_pm> here
16:07:18 <OnlyHuman> chwido: bark headboy
16:07:18 * chwido barks at headboy and somehow gets glowing eyes.
16:07:44 <itchka> OnlyHuman: :)
16:07:50 <OnlyHuman> :
16:07:55 <OnlyHuman> :)
16:08:25 <itchka> Hi crisb_mob
16:08:30 <OnlyHuman> chwido: bark whowantsthecane
16:08:30 <chwido> refuses to bark at such a nice soul.
16:08:37 <radix_pm> for review/consideration/edits as needed -- https://project.openmandriva.org/work_packages/173
16:09:36 <itchka> Thank you radix_pm
16:09:50 <radix_pm> my pleasure. please amend/augment as needed.
16:10:05 <Pharaoh_Atem> here
16:10:15 <itchka> bero: ping
16:11:43 <crisb_mob> Hi
16:12:06 <Pharaoh_Atem> radix_pm: how in the world did apt-rpm get on the list of proposed solutions?
16:12:15 <Pharaoh_Atem> it's totally dead, with no work done in three years
16:12:18 <radix_pm> did i misread notes?
16:12:57 * radix_pm does make mistakes on occasion ;)
16:13:04 <Pharaoh_Atem> afair, the proposed options were dnf, zypper, and smart
16:13:29 <radix_pm> ty. will edit.
16:13:32 <Pharaoh_Atem> smart being dead-ish (semi alive), and dnf and zypper being actively developed by rpm.org and openSUSE
16:13:36 <Pharaoh_Atem> , respectively
16:14:04 * n3npq is here
16:14:33 <mdawkins> i've talked to anders the past week
16:14:55 <mdawkins> smart is more alive than apt-rpm, but he's pretty much done with devel
16:15:05 <Pharaoh_Atem> I'd cut smart off the list then
16:15:17 <mdawkins> but in all honesty, smart is in better form that most afaict
16:15:19 <n3npq> and -- unlike apt-rpm -- smart is used by poky/yocto.
16:15:21 <Pharaoh_Atem> the whole point is to *not* adopt something that's not actively developed
16:15:32 <n3npq> apt-rpm isn't used anywhere that I know of
16:15:33 <radix_pm> done
16:15:36 <mdawkins> Pharaoh_Atem: not so quick, it's still doing better than most
16:15:54 <Pharaoh_Atem> n3npq: by the same token, apt-rpm is used by pclos, but I prefer not to think about that too much
16:15:57 <mdawkins> n3npq: pclos  still uses it afaik
16:16:15 <radix_pm> do we have the manpower and resources to build/test all four @bero?
16:16:35 <n3npq> mdawkins: good for pclos
16:16:47 <Pharaoh_Atem> all three alternative options work with rpm-md data, so as long as we can reliably generate that, we can test them fairly
16:17:05 <Pharaoh_Atem> all three also prefer it, as it is the most well-supported option
16:17:38 <itchka> Clears throat; If we are to discuss this subject now we should do it under the agenda item so we can record the actions.
16:18:04 <itchka> Ahenda here https://project.openmandriva.org/meetings/43
16:18:19 <n3npq> poky/yocto uses rpm5, needs no changes, has fewer politics, than other choices. meanwhile, depsolvers for oma is an entirely different question than whether projects are dead (or whether they Just Work w rpm5). choose whatever you wish
16:18:21 * radix_pm supports robert's rules of order (or bob's rules of semi-anarchic order) -- agendas do help ;)
16:18:30 <itchka> #item 3
16:19:00 <itchka> #topic  RPM, the plan (Bero)
16:19:18 <itchka> bero: ping
16:20:04 <Pharaoh_Atem> well, I've figured out how to get DNF going on rpm5
16:20:24 <Pharaoh_Atem> most of the patches from PLD appear to be up to date for the base stuff, and just a bit of tweaking is necessary for the higher level patches
16:20:46 <n3npq> Pharaoh_Atem: good. meanwhile dnf is unlikely to be willing to accept patches from rpm5.
16:20:57 <Pharaoh_Atem> n3npq: perhaps
16:21:02 <Pharaoh_Atem> I don't know for sure if that's the case
16:21:10 <n3npq> certainly they will not accept patches from me.
16:21:14 <Pharaoh_Atem> I've been on pretty good terms with Honza
16:21:22 <n3npq> I do know that is the case
16:21:42 <Pharaoh_Atem> that said, the actual patches required are pretty non-invasive
16:21:45 <Pharaoh_Atem> which is pretty good, too
16:21:58 <Pharaoh_Atem> basically switching out a few definitions
16:22:11 <radix_pm> i'm happy to help broker the negotiation, if one is possible, re: opening the dialogue again between dnf and rpm5, fwiw.
16:22:14 <mdawkins> n3npq: don't be pessimisstic, play well and hopefully we can mend old bridges
16:22:35 <Pharaoh_Atem> indeed
16:22:59 <itchka> it's all in the presentation...
16:23:05 <n3npq> mdawkins: I am not pessimistic … I can point to public statements … and I am moderated (as in censored) for going on 7y now on mailing lists.
16:23:20 <Pharaoh_Atem> and I've established a good rapport with the DNF devs as part of my work to bring DNF to Mageia as well
16:23:43 <n3npq> the political issues are real … and pertinent to a discussion of changing depsolver from urpmi -> ??? in oma
16:23:56 <mdawkins> n3npq: i know, but if we keep mucking around in the past and dredging up the ol' he said she said and you you you pointing the finger, none of us are going to move forward
16:23:59 <radix_pm> i believe we can accomplish this if it's a messaging/branding issue and a few bridges need to be mended. again, happy to help ... but will likely need a soft handoff and some assistance w/tech details.
16:24:26 <oiram73> ?
16:24:49 <radix_pm> if this were a yoga class, we'd start with a moment of intention and focus on our breathing. agreed @mdawkins, @pharaoh_atem @itchka
16:25:03 <mdawkins> i agree
16:25:13 <Pharaoh_Atem> regardless, getting DNF working on OpenMandriva will not be as challenging as I first imagined
16:25:26 <mdawkins> Pharaoh_Atem: good!
16:25:36 <itchka> indeed yoga breathing is vey calming
16:25:36 <radix_pm> that's great news -- can you sum up, @pharaoh_atem?
16:25:41 <n3npq> the issues are real … now. meanwhile choose a depsolver fro whatever reason. one depsolver (two is worser than either). and then whatever issues that need solving in rpm, up to and including forking any project that will not accept patches
16:26:08 <Pharaoh_Atem> radix_pm: so basically there are only a few things that need patching, and they mostly live at the C library layer
16:26:23 <Pharaoh_Atem> basically that's libhif and hawkey
16:26:33 <radix_pm> @n3npq -- let's suspend disbelief (and hx) for the moment and prepare for the worst, but aim for the best. i'm increasingly persuaded by people included here that such a bridge is possible.
16:27:02 <Pharaoh_Atem> I believe there are some small patches required to support the RPM information from rpm5 in dnf itself too, but those aren't very substantial
16:27:07 <mdawkins> is there a reason we shouldn't consider zypper?
16:27:19 <mdawkins> just being devils advocate here
16:27:27 <Pharaoh_Atem> mdawkins: the development of zypper has stalled since the Leap effort started
16:27:27 <radix_pm> iirc, it's on the list.
16:27:27 <n3npq> Pharaoh_Atem: post the patches and I'll tell you what else needs doing.
16:27:52 <Pharaoh_Atem> n3npq: I'm on my work computer atm, so I don't have them on hand
16:28:10 <n3npq> rpm-devel@rpm5.org is ready when you are
16:28:12 <mdawkins> n3npq: Pharaoh_Atem something that can be done a little later no?
16:28:13 <Pharaoh_Atem> mdawkins: in the last year or so, it's really only been translation updates and little weird thigns for SUSE-isms
16:28:23 <mdawkins> ok
16:28:35 <mdawkins> is dnf+yumex the combo?
16:28:47 <Pharaoh_Atem> yumex is only if you don't want to use a PK based GUI frontend
16:29:06 <Pharaoh_Atem> libhif is supported by PackageKit directly
16:29:10 <n3npq> mdawkins: Poky/Yocto dropped zypper for smart … ask Mark Hatle @windriver if you wish to know the reasoning.
16:29:39 <Pharaoh_Atem> n3npq & mdawkins: also, recent versions of zypper seem to be non-portable
16:29:48 <Pharaoh_Atem> I failed to get libzypp and zypper to build properly outside of SUSE
16:29:56 <n3npq> but dnf -- because used by RHEL/CentOS etc seems likeliest to be undead going forward
16:30:10 <mdawkins> n3npq: ok, i'm just asking the questions to make sure we're not blindly going in one direction
16:30:11 <n3npq> portabilty is usually easily fixed
16:30:16 <Pharaoh_Atem> they seemed to turn their focus inward and making Zypper tightly coupled with YaST and SUSE stuff
16:30:43 <Pharaoh_Atem> in the past, Zypper had code switches for handling other options, but that seems to be gone now
16:31:05 <n3npq> that devel line is analogous to yum being closely integrated with anaconda … which is partly the reason that dnf was started
16:31:26 <Pharaoh_Atem> in any case, the effort to bring up and maintain zypper is non-trivial and increasingly difficult
16:31:32 <radix_pm> right @n3npq. iirc, we have tentative consensus re: dnf likely > than alternatives, but the #action item per @itchka last week pending build/test via @bero et al was to let the data drive the decision. i suspect that dnf will also win out, but it seems reasonable to let the results determine the commit -- not necessarily per upstream, but per OM-specific needs. pls correct if i'm mistaken.
16:32:00 <mdawkins> where is bero?
16:32:05 <n3npq> again, rpm5 "worked" with zypper in Poky/Yocto, I'm sure the portability problems are easily fixed by resurrection
16:32:17 <radix_pm> i can't connect w/him on google hangouts. idk.
16:33:00 <mdawkins> n3npq: are you saying we should keep zypper on the table?
16:33:04 <itchka> I do not know
16:33:05 <n3npq> radix_pm: dnf is more desirable based on current user base … which makes the decision "likely" no matter what the consequences or costs
16:33:56 <crisb_mob> Mdawkins: I think we should still consider
16:34:20 <n3npq> mdawkins: I'll recuse myself from any decisions of depsolving in oma … until there is a decision, its not clear what efforts are needed.
16:35:52 <mdawkins> i'll speak for myself here, but in my past experience, i think tools that are not tied specifically to a distro, but more towards a goal for overall progress are more desirable
16:36:06 <n3npq> I am saying that smart is currently using rpm5 and "known good" and in python … zypper was ditto even if changed in the past few years. and that politics with dnf are going to be problematic (but the code base can be easily forked to get back to engineering rather than politics).
16:36:24 * proyvind would btw. prefer urpmi metadata to be kept unless better alternatives has been proven as worthy gains in the event of migrating away from urpmi..
16:36:27 <mdawkins> is dnf an independent project?
16:36:28 <n3npq> and apt-rpm is dead dead dead … god help plcos
16:37:22 <mdawkins> agreed
16:37:24 <n3npq> mdawkins: RHT would like you to think "independent" yes
16:37:34 <proyvind> maintenance cost of genhdlist2 isn't much, and I'd like to rewrite a much faster and easier maintenable implementation in C...
16:37:54 <proyvind> which should reduce it further.
16:37:55 <proyvind> ..
16:38:02 <mdawkins> proyvind: if we can take that and make it an independent project in github, why not?
16:38:23 <mdawkins> let's get away from omv/mdv/mdk branding
16:38:42 <Pharaoh_Atem> mdawkins: dnf has a mix of RHT and community members maintaining it
16:39:14 <mdawkins> Pharaoh_Atem: who calls the shots?
16:39:14 <radix_pm> @mdawkins -- i suspect that's the longer-term goal, but the project parameters (as i understand them per @itchka) are to focus on OM first, upstreaming second.
16:39:21 <n3npq> proyvind: urpmi metadata needs file dependencies … there are better representations of metadata with more complete information that permit better tools
16:39:29 <proyvind> mdawkins: in all distro specific tools, I've pretty much removed distro branding and given tools better names..
16:39:55 <proyvind> n3npq: but do we *really* need file dependencies..?
16:40:05 <n3npq> meanwhile, I don't believe (but just a savvy guess) that dnf knows anything about urpmiu metadata
16:40:30 <proyvind> we've had policies against it since almost the very beginning, worked out quite well enough so far..
16:40:46 <proyvind> n3npq: hm, IIRC Pharaoh_Atem told me that DNF already supports it :)
16:40:49 <Pharaoh_Atem> mdawkins: Richard Hughes (C libs) Honza Silhan (dnf core) and Igor Gnatenko (community plugins) along with Michael Schoeder (depsolver)
16:40:51 <proyvind> not that it would be hard to add
16:41:00 <Pharaoh_Atem> proyvind: it does not support hdlists currently
16:41:04 <proyvind> parsing urpmi metadata is simple as fuck
16:41:07 <n3npq> proyvind: see file conflict discussion in scrollback … until the metadata contains filelists, tools that detect and automate file conflict detection cannot be developed
16:41:09 <Pharaoh_Atem> not hard to add, probably, but not supported currently
16:41:21 <Pharaoh_Atem> n3npq: rpm-md supports all of those
16:41:33 <mdawkins> proyvind: this is why projects like that need to be pushed out of omv
16:41:36 <proyvind> Pharaoh_Atem: we don't use hdlists for dep solving anymore, but you might be confusing it with synthesis?
16:41:49 <Pharaoh_Atem> proyvind: yeah, I mean synthesis
16:41:49 <mdawkins> bbiab, will catch up
16:42:12 <proyvind> Pharaoh_Atem: I thought you said earlier that it was supported? :p oh well, I can prolly' take a stab at
16:42:28 <Pharaoh_Atem> proyvind: it *is* supported in libsolv
16:42:35 <Pharaoh_Atem> but hawkey and libhif don't expose that functionality
16:43:01 <Pharaoh_Atem> hawkey is being merged into libhif right now, and that will be completed next week
16:43:27 <n3npq> Pharaoh_Atem: there are different meanings for "supported" here
16:43:42 <proyvind> Pharaoh_Atem: dnf isn't using libsolv?
16:43:45 <Pharaoh_Atem> it is
16:43:56 <n3npq> because you cannot support what isn't present, i.e. file lists in urpmi metadata
16:44:06 <Pharaoh_Atem> think of libhif like libzypp for Zypper
16:44:16 <proyvind> so sounds like rather trivial to expose to dnf? :)
16:44:25 <Pharaoh_Atem> proyvind: probably
16:44:36 <Pharaoh_Atem> n3npq: rpm-md has file lists
16:44:58 <Pharaoh_Atem> and dnf processes those as part of the depsolving mechanism
16:45:14 <n3npq> yes (but filtered). and urpmi metadata does not have file lists. so different things are being talked about.
16:46:24 <proyvind> n3npq: well, is it really *required*? I mean, we have a distribution with policies against file dependencies, so would it be all that required for any particular purpose? there's always files.xml.lzma, but that one certainly lacks crucial file attributes etc. to make it usable for dep solving etc..
16:48:09 <proyvind> implementing/fixing separate metadata (of actual use beyond purely informal) for files is something I've had in mind for a while..
16:48:47 <n3npq> yoiu tell me … bullets aren't required for a gun if you never pull the trigger. so non-existent file-list data won'tt ever be used by dnf … yo tell me what is "supported" or "required"?
16:49:12 <Pharaoh_Atem> libsolv *requires* file lists currently
16:49:31 <proyvind> n3npq: true, the difference between "supported" vs "required" is of essence
16:49:39 <proyvind> Pharaoh_Atem: how come? for what purpose?
16:49:39 <n3npq> Pharaoh_Atem: and the file list could be empty.
16:50:41 <Pharaoh_Atem> n3npq: right
16:50:59 <Pharaoh_Atem> proyvind: the solv cache needs to know everything it can to pick *optimal* solutions
16:51:02 <fedya> meeting started?
16:51:23 <Pharaoh_Atem> I spoke to Honza about it, and he's looking into rearchitecting DNF to make it possible to be non-mandatory at least in DNF
16:51:29 <fedya> what's new?
16:51:34 <n3npq> fedya: chattering waiting for bero to report "rpm plan" as action item #3 yes
16:51:39 <itchka> Is it possible that we could look at this a different way? As an example the time taken to run genhdlist2 at abf is considerable and controls the rate of package publication and ultimately the efficiency of abf itself. Should we not be considering these tools on the basis of the tasks that they need to do in the real world.
16:52:13 <itchka> bero: ping
16:52:15 <fedya> well ABF status already reported?
16:52:17 <Pharaoh_Atem> n3npq: there's also createrepo_c, which does generate large sets of rpm-md metadata very quickly and correctly
16:53:07 <itchka> fedya: No we started at item 3 on agenda
16:53:21 <n3npq> Pharaoh_Atem: yes I know what is available. itchka: genhdlist2 could be speeded up by reimplementing rather than ignoring files certainly.
16:53:44 <proyvind> itchka: as said, I've had plans for doing a rewrite in C that prefetches all headers from files in one run, while processing metadata in separate threads, rather than current implementation which does no prefetching or anyother fanciness, making it dead slow
16:53:48 <Pharaoh_Atem> n3npq: eck, sorry, meant to say to itchka
16:53:59 <itchka> fedya: https://project.openmandriva.org/meetings/43 if you don't have it
16:54:40 <proyvind> I wrote a proof of concept implementation for the most time consuming part (parsing rpm file headers) in very short time earlier, speedup was insane for large like main & contrib..
16:54:47 <proyvind> large repos*
16:55:08 <Pharaoh_Atem> I guess the other advantage of rpm-md vs mdkrepo format is that there are more tools that support it
16:55:13 <proyvind> so getting it to perform at nice speeds isn't all that hard
16:55:14 <Pharaoh_Atem> but that may not matter to you guys
16:56:37 <proyvind> in general, we've implemented support for it in such tools ourself over the years without big problems, the synthesis format is extremely easy & lightweight to parse, while being incredible slim as well
16:56:42 <n3npq> Pharaoh_Atem: re "solv cache" ,,, rpm5 is well positioned to memoize data while streaming. you know memoization as a "solv cache" where basically pointers *always* point to a unique string/value.
16:56:55 <proyvind> and it's kinda part of our cultural heritage.. ;)
16:57:17 <n3npq> but that is a deeper question that I won't know until I see your patch on <rpm-devel@rpm5.org> … no hurry ;-)
16:57:53 <Pharaoh_Atem> n3npq: the solv cache is a libsolv thing, intentionally above rpm/dpkg/whatever
16:59:03 <n3npq> proyvind: your "cultural heritage" was a perl dump knocked out in a weekend by a perl hacker ;-) meanwhile the format (rpm-md, synthesis, json, xml, etc) is nowhere near s important as the content (i.e. missing file lists needs to be fixed)
16:59:59 <Pharaoh_Atem> n3npq: my *real* question at this point is how quickly could we get abf generating rpm-md with either createrepo_c or the older python based createrepo?
17:00:09 <n3npq> Pharaoh_Atem: yup … and memoization forces all headers to read and memory resident in order to use libzolv.
17:00:17 <n3npq> libsolv
17:00:40 <Pharaoh_Atem> because I *do not* have the disk space to test everything locally by mirroring all of OMV
17:01:02 <n3npq> the memoization and the SAT solver are very parts of libaolv et al
17:01:06 <Pharaoh_Atem> or at least, not anymore
17:01:11 <n3npq> … are very different ...
17:02:30 <n3npq> Pharaoh_Atem: you clearly do not use rpm5. there is a rpm option to generate rpm-md for any set of packages
17:03:03 * Pharaoh_Atem sighs
17:03:03 <itchka> I think we need to summarise here since bero appears to be unavailable. Would you like to do that n3npq?
17:03:16 <Pharaoh_Atem> n3npq: I am totally aware of what rpm5 can do
17:03:30 <Pharaoh_Atem> but testing them fairly means we need the metadata somewhere on a server
17:03:42 <Pharaoh_Atem> n3npq: and don'
17:03:46 <Pharaoh_Atem> and don't be a jerk
17:03:50 <radix_pm> hey -- @proyvind -- this isn't ronda rousey vs. holly holm. reset/breather, please. let's keep this on point. MMA we're not.
17:04:37 <n3npq> Pharaoh_Atem: jerk? I answered your question (mostly) … abf could execute an existing command easily
17:05:21 <Pharaoh_Atem> the tone for "you clearly do not use rpm5" is not very nice
17:05:39 <n3npq> itchka: I cannot speak to an "rpm plan" … which is actually a misnomer since the discussion is switching urmi to Something Else Instead
17:06:12 <n3npq> Pharaoh_Atem: add a ;-) have you generated rpm-md using rpm5?
17:06:48 <Pharaoh_Atem> n3npq: no, because I wasn't sure of the correctness of the implementation
17:06:58 <Pharaoh_Atem> well, sort of
17:08:42 <n3npq> correctness is de facto … rpm-md continually changes and is modified by distros as needed … when implemented, the generated metadata was identical to what createrepo produced and tools like smart where using rpm5 generated metadata
17:10:33 <n3npq> at the time (2008) the generated rpm-md was able to read headers remotely (so you don't need to mirror) and was 20% faster than createrepo. createrepo_c is of course multi-threaded
17:11:10 <n3npq> current state is unknown … I don't look at tools that noone uses ...
17:13:22 <mdawkins> createrepo never worked well afair
17:13:58 <mdawkins> anyways... where are we at?
17:13:58 <n3npq> mdawkins: performance sucjed, yes. meanwhile createrepo is the de facto "standard"
17:14:00 <mdawkins> stalled?
17:14:02 <Pharaoh_Atem> no, it didn't, which is why I never proposed using it with mageia
17:14:10 <mdawkins> n3npq: i agree
17:14:48 <Pharaoh_Atem> I worked with the author of createrepo_c to add some specific things (mainly xz compression) to make it suitable for Mageia
17:14:56 <Pharaoh_Atem> stuff that isn't in old createrepo
17:15:19 <radix_pm> are any of these issues related to backwards compatibility, btw?
17:16:04 <Pharaoh_Atem> radix_pm: there are some differences between createrepo_c and createrepo: https://github.com/rpm-software-management/createrepo_c#differences-in-behavior-between-createrepo_c-and-createrepo
17:16:23 <Pharaoh_Atem> but they are mainly related to fixing issues with how createrepo did things and correcting broken behavior
17:16:43 <radix_pm> thanks @pharaoh_atem -- query: which are critical to OM and which are upstream-specific, or are they one and the same problem?
17:16:58 <mdawkins> so.... no bero?
17:17:03 <n3npq> Pharaoh_Atem: just fyi: rpm-md format has to do with the xml (or sqlite) not the cdata values encoded or the compression used (or the names of the generated files: I never bothered to implement the new file names based on hashes)
17:17:12 <radix_pm> so far, no bero. can't find him on google. anyone want to try the facebook? ;)
17:17:20 <Pharaoh_Atem> radix_pm: one and the same basically
17:17:36 <mdawkins> we have a decision to make, use rpm-md bc yes it is a gold standard
17:17:43 <n3npq> radix_pn: so perhjaps you should summarize the "rpm plan" action items
17:17:52 <mdawkins> patch to make it usable to our liking
17:18:12 <mdawkins> let pok take genhdlists2 off as a separate project and for to C
17:18:22 <Pharaoh_Atem> fwiw, Mageia will also soon start using rpm-md too
17:18:40 <Pharaoh_Atem> which will mean that Fedora, openSUSE, and Mageia will all be using it
17:18:55 <mdawkins> Pharaoh_Atem: when I was rolling Unity Linux, we used rpm-md, heavily patched, but it worked
17:19:16 <mdawkins> rpm5+smart+rpm-md all heavily patched
17:19:18 <n3npq> mdawkins: add an action item … this thread started when proyvind wished to continue using synthesis … truly, if the same content is included, the formats (and compressions and file naming etc) can be translated as needed
17:20:06 <Pharaoh_Atem> createrepo_c supports xz compressed rpm-md (see https://bugs.mageia.org/show_bug.cgi?id=17057 for "optimal" config)
17:20:12 <mdawkins> well lets find out what the people think
17:20:12 <n3npq> mdawkins: resurrect the patches onto <rpm-devel@rpm5.org> please. no hurry
17:20:21 <Pharaoh_Atem> if you'd rather use rpm5'
17:20:32 <Pharaoh_Atem> *rpm5's own ability to generate rpm-md, that's fine as well
17:20:49 <Pharaoh_Atem> as long as it's technically valid rpm-md and the performance is acceptable, then go for it
17:21:24 <radix_pm> @n3npq -- thus far, https://project.openmandriva.org/work_packages/173-- the rpm5-specific PM map does need to be updated, and i need to collaborate with you re: that update offline later this week.
17:21:28 <mdawkins> n3npq: rpm5's createrepo never worked was what i meant, we used upstream
17:22:52 <n3npq> Pharaoh_Atem: afaik, createrepo_c can be run on rpm5 generated pkgs. at worst there are some rather straightforward portability changes since headerGet() is different between rpm.org and rpm5.org
17:23:20 <Pharaoh_Atem> n3npq: cool
17:24:14 <n3npq> mdawkins: likely yes. note that rpm-python in rpm5.org is _NOT_ a drop-in replacement for rpm.org version. expect difficulties
17:24:59 <Pharaoh_Atem> n3npq: the C API between rpm5 and rpm.org is pretty similar, right?
17:25:04 <n3npq> createrepo access packages using rpm-python (which is likely where the "works" issues were). butr createrepo_c is C
17:25:06 <Pharaoh_Atem> so createrepo_c might be easier to work with
17:25:23 * n3npq has no love of the snajke
17:25:57 <itchka> Gentlemen I think this topic has had a good airing and would like to call it to a close since the meeting has other business. It will be on the agenda of next weeks meeting where it can be discussed further if necessary.
17:26:27 <Pharaoh_Atem> in any case, as soon as I have some free time and access to my devstation, I'll start the work of building dnf for omv
17:27:02 <itchka> I will record one agtion aginst it for future reference and that what was raised by Pharaoh_Atem atem about testing his work on abf.
17:27:25 <Pharaoh_Atem> yeah, need rpm-md data for omv repositories being generated
17:27:34 <itchka> #action: Investigate practicality of abf testing of Pharaoh_Atem code.
17:27:36 <Pharaoh_Atem> afaik, abf *can* do it, but it doesn't for omv target
17:28:21 <radix_pm> @itchka -- clarification? testing for migration, testing for data reliability ...?
17:28:40 <itchka> radix_pm: The latter
17:29:13 <itchka> Pharaoh_Atem: Perhaps we can liase on this outside the meeting.
17:29:17 <radix_pm> iirc, @Xu_R had a few concerns re: commits, but @mdawkins did not.
17:29:27 <Pharaoh_Atem> itchka: cool
17:30:08 <mdawkins> n3npq: how possible is getting nosql metadata going ?
17:31:42 <itchka> mdawkins: Please we need to move on
17:31:57 <itchka> #item 1
17:32:00 <mdawkins> itchka: sure...
17:32:20 <itchka> #topic ABF new, progress, needs
17:32:47 <itchka> mdawkins: You can pick that one up under AOB ok
17:32:57 <mdawkins> sure ... go on
17:33:05 <fedya> well
17:33:07 <fedya> abf
17:33:12 <radix_pm> as i understand it, abf is partially back online but with a few hiccups. @n3npq was generous to allocate some hardware/VMs, IIRC, to assist with this.
17:33:15 <itchka> fedya: Will you report please.
17:34:30 <fedya> glusterfs for file-store - working, abf.openmandriva.org - working via https, postgresql, errbit, mongodb, redis - working too. Second server with oma2014.0 and latest kernel is very stable and fast
17:35:05 <itchka> Still to do?
17:35:08 <fedya> Well generally abf is ready to work
17:35:36 <fedya> todo: rewrite abf git parts to use github instead of internal git-server
17:35:50 <mdawkins> do we need to freeze and lock the current abf builds and git?
17:35:52 <fedya> and second point is rewrite rpm-worker-daemon
17:36:04 <fedya> but i believe that's easy task
17:36:17 <mdawkins> ETA?
17:36:27 <Pharaoh_Atem> fedya: could you add support for gitlab, too?
17:36:36 <fedya> https://abf.openmandriva.org/ http://file-store.openmandriva.org
17:36:45 <fedya> Pharaoh_Atem need to ask avokhmin
17:37:00 <fedya> He's author of abf
17:37:02 <Pharaoh_Atem> as gitlab is foss and it'd be nice to have support for fossy things
17:37:19 * Pharaoh_Atem is surprised OMA doesn't have a gitlab.com mirror, actually
17:37:24 <n3npq> fedya: has this issue been resolved? http://ml.openmandriva.org/pipermail/om-cooker-openmandriva.org/2015-November/001436.html
17:37:25 <fedya> i'm just know how to setup it and how rpm-builders work
17:37:46 <fedya> n3npq resolved with --no-verify-rpm
17:38:14 <n3npq> um, no. and someone ought to configure rpm sufficiently to stop using RSA/SHA1
17:39:00 <fedya> now for abf avokhmin need to find a time to rewrite it
17:39:20 <fedya> Pharaoh_Atem: github, bitbucket, gitlab
17:39:57 <fedya> but at first need to plug github
17:40:00 <Pharaoh_Atem> fedya: GitLab is snazzy and FOSS, so that's why I brought it up :P
17:42:12 <crisb_mob> Well if nothing else we ought to have learned to have at least some automatic mirror of git
17:42:45 <mdawkins> crisb_mob: +1
17:42:56 <itchka> crisb_mob: A most important point!!
17:43:21 <Pharaoh_Atem> crisb_mob: most def
17:43:36 <itchka> #action: Make sure abf git implementation has a mirror.
17:44:39 <crisb_mob> Now why hasn't someone started oldgit.org ;-)
17:45:40 <itchka> #action Start old_git.org asap?
17:45:56 * Xu_R thinks that was sarcasm?
17:46:03 <itchka> supposed to be !! not ?
17:46:38 <itchka> Xu_R: Hi
17:46:40 * Xu_R is on a slow connection - apparently the wifi decided to not work today... (also reading up and seeing the mess is mindboggling)
17:46:59 <crisb_mob> Oh Itchka now you need another action to countermand the first joke one
17:47:53 <n3npq> itchka: another abf point: bero/rxu have logins here, and I resurrected my RAID array yesterday. I am also on hook to setup a proof-of-concept OpenNMS server to track machine availabilitry (basically you look at opennms instead of asking me if a machine is unavail). a deployment plan of x86_64 first (and aarch64 next, its trickier because of jtag consoles and power cycling remoting) needs to be congealed
17:48:11 <itchka> crisb_mob: I'm losing the will to live :)
17:49:42 <itchka> n3npq: Thank you. I hope we can get the best adavantage from you hardware soon
17:50:31 <Xu_R> n3npq: bero and I will be working out a deployment plan and we should have it ready after we solidify all the details of what we need
17:51:31 <Pharaoh_Atem> radix_pm: welcome back
17:52:34 <radix_pm> btw, update from elia pinto -- reimported the cvs rpm in github https://github.com/devzero2000/RPM5 again using  https://github.com/rcls/crap -- seems to be working, fwiw and for whom it's relevant.
17:54:05 <n3npq> fwiw: rpm5 has a git repository already: meanwhile my development is in cvs and will remain there until there is some reason (like more developers) to change
17:54:40 * Pharaoh_Atem screams in horror
17:54:44 <Pharaoh_Atem> tarballs in git!
17:54:51 <n3npq> git.rpm5.org … created solely to focus on rpm engineering, not whatever VCS happens to be used
17:55:36 <n3npq> Pharaoh_Atem: what are you objecting to?
17:55:37 <mdawkins> Pharaoh_Atem: if your are talking about our git, you can blame rosa squarely there
17:56:01 <mdawkins> when we converted over to git with removed all binary formats
17:56:14 <mdawkins> and then rosa merged they're shizzy over ours
17:56:20 <n3npq> if cpu-os-macros.tar.gz, that is there solely to document functionality that was retired in 2007.
17:56:34 <Pharaoh_Atem> mdawkins: oh jeez
17:56:47 <Pharaoh_Atem> n3npq: I was trolling through the repos
17:57:13 <n3npq> Pharaoh_Atem: then don't be a jerk, ask ;-)
17:57:25 <radix_pm> milk and cookies for everyone.
17:57:34 * Pharaoh_Atem takes some cookies and eats
18:01:10 <radix_pm> so to repitch, the dependency on abf and assumption of reliability/continuity for any long-term planning is a gamble given rosa's shaky status. how/can/should do we want to move toward an alternative solution? @itchka, i believe that you had a few ideas about this.
18:03:56 <itchka> radix_pm: There are some aspects of the way building is done with abf which could be more efficient. I hope that the rpm workers for the new abf will be capable of being more widely distributed than the previous implementation.
18:07:23 <itchka> As a very basic example may of use use the abf-console-client to interact with abf. The client allows local builds of packages (if you are building the same arch). Packages built sucessfully are wasted  but there is no reason why they should not be sent to abf, tested and placed into the repository.
18:07:33 <radix_pm> cloud? distributed? another server cluster?
18:08:33 <itchka> abf already has a distributed architecture but we are not really taking advantage of it.
18:09:21 <fedya> itchka: why? even abf.io working distributed
18:09:31 <fedya> i have at my home 2 arm boards connected to abf
18:09:37 <fedya> and 7 arm boards not in home
18:09:56 <itchka> fedya yes and I have a hikey64
18:10:00 <fedya> right
18:11:44 <itchka> fedya: As I said abf already has a distributed architecture we need to take better advantage of it.
18:13:13 <Xu_R> itchka: Your example of using local builds and sending them to abf - the purpose is to build on machines we trust, right? So -1 for that
18:13:46 <itchka> Xu_R: That all depends on how you manage trust.
18:14:02 <itchka> It doesn't preclude the method
18:15:11 <itchka> If someone has an account on abf and has placed ssh keys they have direct access to git so what's the difference.
18:16:05 <itchka> If the build is verifies against a public key then I don't see aproblem.
18:16:10 <n3npq> Xu_R: please suggest better "trust" specifically so that issues can be resolved
18:16:26 <radix_pm> docker -- managed sudo, perhaps?
18:17:09 <Xu_R> itchka: yeah, but git can be reverted. My concern is if someone manages to inject into this process a bad toolchain or one with a security risk
18:18:15 <Xu_R> n3npq: I suppose "trust" would be to have servers under our control, or VM images that would be used to do this? Least surface area for interference, maybe?
18:18:36 <n3npq> Xu_R: every set of packages built by rpm is signed *when built* with the public key included.
18:20:28 <n3npq> there are other attacks if the tools used are compromised. but tampering during the xfer from local build to remote server is always with a digital signature
18:20:43 <Pharaoh_Atem> itchka: local builds should never be more than "scratch" builds
18:21:03 <Pharaoh_Atem> unless you have a way to guarantee security during the build on an infinite number of machines out of your control
18:21:04 <Xu_R> n3npq: yeah, the tools are the main concern.
18:21:07 <Pharaoh_Atem> you don't really want to do that
18:22:44 <n3npq> Pharaoh_Atem: running in a VM, installing packages with signature verification from known remote servers using build deps, then building goes a long way towards setting up an environment "securely". sure there are always other attacks
18:24:10 <n3npq> similarly, running rpm --verify before and after a build ensures tools are not compromised.
18:24:26 <Pharaoh_Atem> n3npq: it would also help if you have a way to establish secure tunnels for transferring build artifacts
18:24:59 <Pharaoh_Atem> the open build service uses just basic https, but they don't allow local outputs to be used for more than scratch builds
18:25:09 <radix_pm> hey guys! why don't we just move everything to aws and be done with it? /kidding
18:25:25 <fedya> radix_pm aws takes money for load
18:25:28 <itchka> I am sure there are ways where the process can be subverted but they all imply deliberate sabotage. After all the recent issue with abf proves that you can have as many servers as you like under your control but there's still a problem. It's just a question of how high you want to set the bar.
18:25:32 <n3npq> but sure there are always other attacks. what if the disk firmware and/or kernel currently running are compromised … the list goes on and on and on … and there are approaches to all of those problems, including SElinux etc
18:25:53 <Pharaoh_Atem> Koji allows both local and remote stuff for scratch builds, and *technically* you could submit build artifacts into the generated repository
18:26:04 <Pharaoh_Atem> but it's not usually used
18:26:35 <Pharaoh_Atem> then there's also CI chaining, if you want to support that
18:26:43 <Xu_R> radix_pm: that sounds like a blessing and a curse in disguise
18:26:55 <Pharaoh_Atem> it's going to be really hard to coordinate if you have lots of uncontrolled instances
18:27:09 <Pharaoh_Atem> and lag can play a factor too
18:27:17 <n3npq> Pharaoh_Atem: and then there is the Debian efforts for "reproducible builds" … build on several servers and check identical results. doable but there just are not the resources
18:27:21 * radix_pm was mostly joking.
18:27:57 <bero> back
18:27:58 <crisb_mob> Back
18:28:12 <bero> sorry for coming in this late, had some urgent Linaro stuff I couldn't put off
18:28:23 <bero> (which involved going to the valley to get some hardware)
18:28:39 <Pharaoh_Atem> n3npq: both the Koji and OBS enforce the reproducible builds structure, while Debian's builder framework doesn't quite yet
18:28:45 <itchka> Pharaoh_Atem: Yes it's an interesting problem but even on a small scale this kind of thing can improve efficency.
18:28:45 <n3npq> the important "trust" comes from the process of releasing a distro. users "trust" that all due diligence has been performed on the final product (which is indicated by signing with the release key)
18:28:46 <Pharaoh_Atem> they're working on it (kudos to them!)
18:28:48 * bero reads back
18:29:05 <itchka> bero: Hi
18:29:16 <Pharaoh_Atem> bero: hello
18:30:31 * bero essentially agrees with all that has been said so far
18:30:51 <radix_pm> we saved some cookies for you, too ;)
18:31:46 <itchka> The point is that there is nothing fundamentally against it and it is relevent to tools equivalent to genhdlist (it probably needs to be faster) which is why it needs to be examined.
18:32:34 <crisb_mob> Sorry against what?
18:34:20 <itchka> crisb_mobile:  Submitting builds from abf-console-client.
18:34:38 <itchka> to abf
18:34:59 <bero> I always do that, way too much trouble to use anything remotely GUI related
18:35:31 <crisb_mob> Me too
18:35:35 <itchka> bero: I am talking now of the built package.
18:35:50 <itchka> not of the request
18:35:56 <itchka> to build
18:36:06 <bero> you mean just upload a locally built binary?
18:36:14 <itchka> yes
18:36:24 <bero> problem with that is that it would make it even more likely that the different arches get out of sync
18:36:27 <crisb_mob> Sounds fraught with difficulty
18:36:31 <bero> and in the worst case there's no matching src.rpm
18:36:56 <itchka> I did not say it would be easy.
18:37:11 <crisb_mob> Well it's fine if you only have one arch
18:37:26 <crisb_mob> But then nothing to say that you didn't have so
18:37:44 <crisb_mob> Something installed that isn't specified in the spec
18:38:07 <crisb_mob> Leading to unintended options in the program etc or differences between arches
18:38:35 <bero> or just a missing BuildRequires: that makes the build non-reproducable in a fresh setup
18:38:54 <itchka> any more?
18:40:07 <crisb_mob> Unless you have a whole build node locally with a sync of the repo which builds all the arches in a chroot
18:40:17 <crisb_mob> That could work
18:40:25 <itchka> So perhaps a docker instance.
18:41:05 <n3npq> bero: buildid's do not need srpm (and are included in deps by rpm5). compare 2 buildids with some confidence that -- if identical -- the build was identical. do that on 2 machines and (if you can stand the process pain) you have confidence in "reproducible"
18:42:03 <n3npq> missing buildrequres will surely change the buildid if important.
18:43:08 <bero> n3npq: The primary concern for the src.rpm is not so much the verification as the idea that a user needs to be able to download matching src.rpm -- easiest way to make absolutely sure we don't accidentally violate the GPL
18:43:51 <n3npq> crisb_mob: generated files (like in /usr/include) should be arch independent. this is true for RHEL/Fedora but not for Mandriva* (which has a concept of per-arch includes during build).
18:45:14 <n3npq> bero: put a time limit on the GPL adjusted by resources and save SRPM's (or reference specs/patches/urls in git as you are already doing).
18:46:06 <n3npq> not being able to produce the srpm from which a package was built has little to do with GPL or reproducibility
18:49:01 <mdawkins> so is this meeting dead?
18:49:18 * radix_pm hums "... and now we drink."
18:50:03 <itchka> No Matt people taking a breather
18:51:43 <itchka> Ok lets think about this one. There could be gains to be had and perhaps the pitfalls can be avoided.
18:52:38 <itchka> Does anyone have anything more to say about abf before we move on?
18:53:27 <crisb_mob> A fairly simple thing to do would be some extension to the client that does a chroot build on your arch and submits the results if successful and then starts the build on the other arches
18:53:42 <itchka> Five minutes and we move on to the release report.
18:53:54 <crisb_mob> I don't see that as much worse than what exists already
18:54:25 <crisb_mob> Plus there are a lot of times we submit on all arches and fail on all thus wasting resource on all
18:59:21 <itchka> crisb_mobile: A useful observation.
18:59:59 * radix_pm is looking for waldo.
19:00:19 <mdawkins> there's always tons of things that could be improved on with abf
19:00:22 <bero> crisb_mob: yes, that sounds reasonable... just need to make sure stuff doesn't get published unless it built on all arches
19:00:28 <mdawkins> the question is, who's gonna do it?
19:03:22 <crisb_mob> Bero: but it doesn't wait for all right now!
19:03:55 <mdawkins> crisb_mob: you know what we used to do at UL, we'd build in sequence
19:03:56 <itchka> I think that the next stage. This is an important change and it needs to be voted on. Can I sugget that a proposal be put on Loomio to try for this and if approved we'll do that bit next.
19:04:00 <mdawkins> 64, then 32
19:04:13 <mdawkins> if one failed we'd erase the binaries
19:04:20 <itchka> whoops
19:04:40 <mdawkins> we'd need a mechanism to detect noarch builds
19:04:44 <bero> crisb_mob: and that's why the secondary arches are in such a bad shape
19:04:58 <bero> yes, currently abf is really wasteful building noarch packages once per arch
19:05:37 <mdawkins> can we do a rpm -q --specfile foobar.spec and determine what to build?
19:05:55 <Pharaoh_Atem> bero: Koji and OBS pick a random builder to do noarch packages and just reuse those results across the board, could abf be set up to do that?
19:06:14 <bero> Pharaoh_Atem: it currently can't, but that's exactly what it should do
19:06:29 <Pharaoh_Atem> bero: eek
19:07:12 <radix_pm> levity break: https://youtu.be/sc0mi0Ei1CQ
19:08:14 <crisb_mob> Bero: sure but also those arches break regularly and it would be hugely frustrating to have to successfully build on all as it stands
19:08:40 <crisb_mob> Not to say it shouldn't but we're not in that position now
19:09:03 <mdawkins> crisb_mob: what do you mean?
19:09:41 <bero> we need to start fixing that at some point though... (I'd agree that that point isn't necessarily right now)
19:09:46 <bero> at least bug the user...
19:09:59 <bero> "Your change just broke ARM, are you sure you want to publish it?"
19:10:09 * n3npq points out that a single separate noarch vm builder is far easier to diagnose than a random machine pick. there just aren't that many noarch packages to realize any significant scheduling gain by queing to an apparently unused builder
19:10:19 * radix_pm away -- brb 20 min.
19:10:50 <crisb_mob> I'm saying right now even if you have all the deps which is far from likely it's also very likely your build will fail on one of the arm arches for some reason
19:11:06 <proyvind> in the past, we used to have the noarch packages between archs hardlinked..
19:11:15 <proyvind> on kenobi
19:11:17 <proyvind> before abf
19:11:19 <Pharaoh_Atem> most distros still do this
19:11:35 <mdawkins> for some reason rosa seemed to ignore this
19:12:00 <proyvind> mdawkins: most likely out of initial obliviousness I guess
19:12:08 * mdawkins shrugs
19:12:13 * Pharaoh_Atem shrugs
19:12:17 <mdawkins> they ignored a lot of good advice
19:12:57 <mdawkins> well, we need to be honest with ourselves here, do we need to build all arm arches?
19:13:10 <proyvind> only two built for now AFAIK
19:13:21 <mdawkins> same with ix86
19:13:25 <proyvind> aarch64 & armv7h(n)l
19:13:36 <crisb_mob> I think it's becoming more important yeah
19:13:47 <mdawkins> what's becoming more important?
19:13:48 <itchka> I agree
19:13:51 <proyvind> armv7l is no longer being built for
19:13:53 <proyvind> mdawkins: both
19:14:03 <proyvind> or
19:14:04 <proyvind> hum
19:14:07 <mdawkins> more and more i see all 64bit both IA and ARM
19:14:07 <proyvind> I was talking about archs
19:14:25 <mdawkins> no 32bit chips are being shipped
19:14:33 <crisb_mob> Most enthusiast arm is 32 bit
19:14:34 <mdawkins> not even in arm products
19:14:45 <mdawkins> really?
19:14:49 <proyvind> mdawkins: yupp
19:14:49 <crisb_mob> Rpi etc
19:15:29 <crisb_mob> Only fairly recently could someone get a cheapish aarch64
19:15:36 <proyvind> mdawkins: just like x86_64 systems usually shipped with 32 bit operating systems for it's (rather many) first years
19:16:01 <proyvind> i
19:16:04 <n3npq> mdawkins: there is still often a 4-6 week wait to get an aarch64 board. improving, but its easier and cheaper to get 32bits
19:16:40 <mdawkins> ok ok, on arm 32, but ix86?
19:16:50 <mdawkins> do we really have a good reason
19:16:59 <crisb_mob> We had this debate already
19:17:07 <crisb_mob> People said they wanted it
19:17:12 <proyvind> legacy compatibility, both hardware wise and software wise are speaks in favour of x86
19:18:05 <n3npq> its pretty clear that aarch64 will follow the x86_64 pathway, and likely faster because there is less desktop legacy with a need to preserve value in say, monitors and disks and floppies and dvds and ...
19:18:15 <proyvind> even keeping a broken x86 port around, it would be easier to maintain for 32 bit package repos on x86_64 than starting to build those fuggly multilib blobs you'll find in fedora..
19:18:21 <mdawkins> crisb_mob: and we had infra before.... now look where we are? and ppl want everything you can't always provide it
19:18:49 <crisb_mob> I think providing ix86 is easy compared to arm
19:18:52 <bero> mdawkins: I've proposed to kill off 32 bit x86 around 100 times, but the community consistently screams no
19:19:28 <bero> armv7 will likely remain relevant for longer than x86_32 simply because you can get a Cortex-A7 for $5 these days
19:19:31 <mdawkins> bero: gimme a break... how many? and what if we just made 2014.x the last supported 32bit
19:20:16 <bero> mdawkins: we had a poll about dropping x86_32 for 2015 again, more than 60% screamed NO
19:20:26 <crisb_mob> No point asking the community then ignoring the answer
19:20:32 <n3npq> proyvind: that's an argument to make fedora just like centos and move to 64bit rather than otherwise. x86 software investments cannot be voided out so multilib remains. but there are few large software investments on armv7
19:20:49 <proyvind> mdawkins: what about software compatibility? cooker has always had it's own separate packaging of libraries etc., avoiding the blobs mentioned before
19:20:56 <bero> I think to some extent it's caused by people who have 64bit hardware and simply don't know that fact because they've been using 32bit Windoze forever
19:21:33 <n3npq> bero: then the NO sayers should be asked to get more actively involved.
19:21:44 <itchka> I'm pretty sure we said that we would review this anuualy as there will come a time where it will be a curiosity only.
19:21:47 <bero> I'm pretty sure that sooner or later we'll see aarch64 SOCs that don't implement 32bit mode anymore
19:22:10 <bero> but OTOH Cortex-M will likely remain ARMv7 forever, not much of a point in putting a 64bit processor in something designed to operate a lightbulb or so
19:22:13 <mdawkins> my point is this, ppl will drag you under water even if they see you drowning....
19:22:34 <mdawkins> there's a point where we shouldn't want to maintain 32bit anymore... this is pretty much now
19:22:47 <proyvind> mdawkins: as I said above, even if the x86 port would be in a persistantly broken state leaving it unusable for 32 bit hardware, you'd still have a lesser maintenance cost of just continue adhering to our multilib scheme than those horrible blobs..
19:23:10 <n3npq> proyvind: there are 2 alternatives to 32/64 on same machine. RHEL chose to have one great big pot with both, SuSE chose 3 distros, 1 for each of 32/64 and one multilib and you signed onto whatever you chose.
19:23:10 <mdawkins> proyvind: again... what apps are you keeping it around for?
19:24:01 <n3npq> in practice, the packaging is mostly the same, but you can tell from the number of downloads how many people need the purity
19:24:25 <proyvind> mdawkins: well, 32 bit wine? 32 bit dosbox with vm mode for x86, that were removed from x86_64, various old proprietary stuff, be it games or what not..
19:24:26 <itchka> Guys we are wander off the subject of abf now so I think it's time to move on to the next item.
19:24:57 <itchka> If you want to debate the matter I can put it on next weeks agenda.
19:25:44 <mdawkins> the point is we hold on to legacy for what gain?
19:25:57 <mdawkins> just to keep playing old dos games
19:26:00 <crisb1> Users who want it
19:26:09 <mdawkins> then let em contribute
19:26:27 <mdawkins> ie maintain a 32bit 2014.0 repo
19:26:32 <crisb1> It's really not such a massive burden
19:26:46 <n3npq> bero: while kinda pointless to use aarch64 to turn off a light bulb, similarly can be said for Cortex-M. cost will drive the switch when aarch64 is as cheap as Cortex-M (which may never happen)
19:26:56 <mdawkins> no?
19:27:06 <mdawkins> we have massive disparity between all arches
19:27:39 <itchka> We need to move on now.
19:27:52 <itchka> #item 2
19:28:06 <itchka> #topic Release Report
19:28:26 <itchka> bero: I'm sure it won't take long :)
19:28:47 <ben79> Y'all may have no idea how many with 64 hardware use 32 bit because it's more "stable". Seriously
19:31:38 <mdawkins> ben79: it scares me that you're not joking....
19:31:52 <bero> Yes, essentially only little progress because of ABF downtime
19:31:54 <ben79> me too...
19:32:11 <bero> but some fixes and LXQt 0.10 are back...
19:32:21 <mdawkins> if you take away the option, sure we might here a bit of fussing, but that will be it
19:32:31 <mdawkins> hear*
19:33:09 <itchka> bero: Is the screen lock  issue fixed yet?
19:33:12 <mdawkins> ppl will be like, well i guess it was time to move on
19:33:30 <bero> It should be pretty clear from the wording of our question whether or not we can drop x86_32 that it is inherently unstable because stuff breaks all the time...
19:33:33 <mdawkins> like old vid card drivers in xorg
19:33:39 <bero> itchka: no, we have a pretty good idea what's causing it though
19:34:14 * bero doubts anyone would notice if we dropped e.g. the Cirrus Logic Xorg driver
19:34:40 <mdawkins> bero: has anyone tested it in years? it might not even work
19:34:59 <mdawkins> ie most of the printer drivers
19:35:58 <proyvind> also preserving x86 compatibility back to i586 makes the distro serve a niché market as other distros drops support or simiilar (ie. fedora has started building for i686), with parts of feets still set in ie. brazil and decission of staying at i586 when the subject was raised about switching to i686 related to manbo labs, we chose to stay with i586 because the abundance of legacy hardware that's still in use inn developing countries tha
19:36:43 <mdawkins> proyvind: cerca what year?
19:37:27 <mdawkins> look, that ain't a niche market worth dumping resources into esp bc there are several better legacy hardward niche distros
19:38:14 <proyvind> that discussion was way back, but the issue of legacy hardware still widely in use still remains..
19:38:49 <itchka> mdawkins: This decision was not set in stone and the poll will be taken again next year and until then we must abide by the wishes of our community.
19:38:55 <mdawkins> have you seen a p3 stil running lately?
19:39:31 <mdawkins> itchka: ok, i'm just saying the circumstances have changed drastically
19:39:42 <mdawkins> and 3 or 2015 was supposed to be out by now
19:41:25 <proyvind> mdawkins: yet, is maintenance of x86 port taking up much time & priority? does continued maintenance really hold back/block release development of any significance?
19:42:03 <mdawkins> proyvind: i'd say we get hung up on maintaining the two arches yes....
19:42:16 <itchka> The subject is closed we are on another agenda item now. Please observe the meeting protocol.
19:42:20 <mdawkins> esp with how finicky ABF can be
19:42:42 <mdawkins> itchka: the meet was dead an hour ago when i rejoined
19:42:47 <mdawkins> go ahead
19:44:03 <proyvind> mdawkins: :p
19:44:04 <itchka> With regard to release of 2015 it looks like the recent delays are going to push us well into the new year.  Would anyone like to hazard a guess as to when?
19:44:27 <mdawkins> 2017
19:44:29 <bero> Let's take that guess when abf is back in working state
19:44:50 <bero> right now with it essentially being impossible to get anything done, it's hard to tell
19:45:00 <bero> There's not that much missing, it does work pretty well
19:45:16 <bero> A couple of known bugs, probably quite a few bugs that will be found only when we release a beta...
19:45:33 <itchka> I think we need to put something on the blog.
19:45:33 <bero> But other than that current cooker is already looking pretty good
19:45:54 <proyvind> no clue, you''re blocking my contributions, involvement and any ability to help or much..
19:46:12 * proyvind isn't even running cooker
19:46:51 <mdawkins> yeah me neither
19:47:11 <itchka> Ok last item on the agenda
19:47:19 <itchka> #item4
19:47:28 <mdawkins> i'd like to make cooker chroots but afaik, the sync of MD was off yesterday
19:47:28 <itchka> #topic Meeting Time.
19:49:00 <itchka> Last week I published a spreadsheet showing the results of a survey I did of ideal meeting times. With all the differing timeszones it proved impossible to find a core time that would suit everyi individual polled.
19:50:10 <itchka> Studying the adjusted times shows that todays start time is about the optimal to get everyone here for at least some of the time.
19:50:26 <mdawkins> ok
19:52:23 <itchka> I propose therefore that the start time remains at 16:00 UTC for the forseeable future. Since not everybody can be here for ant decisions that require voting we will refer all major decisions to Loomio.
19:53:14 <bero> works for me usually
19:53:19 <mdawkins> +1
19:53:38 <itchka> Any "show of hands" in the meeting wil need to be ratified by a  Loomio proposal and voting.
19:56:05 <mdawkins> +1
19:56:08 <mdawkins> :P
19:56:16 <mdawkins> can we get back to B & M ing?
19:56:27 <proyvind> what about adding a requirement to have the proposals announced to vote for posted on cooker list so they don't pass "everyone" by so easily?
19:56:42 <itchka> crisb: I hope that's ok by you
19:57:22 <mdawkins> no response obviously means a yes if that's what you want and no if that's what you really wanted
19:58:23 <itchka> mdawkins: It's really not that simple.
19:58:25 <proyvind> mdawkins: you're commenting on my suggestion?
19:58:49 <crisb1> Sorry yeah guess it will have to be
19:58:54 <mdawkins> i'm kidding, i'm trying to point out that it's hard to be present all the time
19:59:10 <proyvind> mdawkins: yeah, hence the importance of my suggestion ;)
19:59:44 <mdawkins> yes, but on the flip side of that can be burdensome too pok
19:59:52 <mdawkins> just keep that all in mind
20:00:37 <proyvind> mdawkins: sure, but just even making the simplest posts referring to like only the topic that's being voted for and where shouldn't be such a great burden
20:00:39 <mdawkins> look at that shizzy!!! --> Build has been done successfully!
20:00:57 <itchka> Proposals are welcome on cooker ml but only those that are ratified on Loomio will be implemented.
20:01:42 <proyvind> itchka: I'm talking about the announcement proposals that are to be voted on, not about suggesting proposal
20:01:48 <proyvind> itchka: I'm talking about the announcement of proposals that are to be voted on, not about suggesting proposal
20:02:19 <proyvind> s
20:02:39 <mdawkins> it seems like a decent request
20:03:00 <proyvind> :)
20:03:01 <itchka> Hmm Loomio already sends out notifications can't see any point in duplicating them.
20:03:14 <proyvind> if it already sends out notifications
20:03:40 <proyvind> then it shouldn't be too much of a problem adding cooker list to recipients for such particular notifications, should there?
20:04:25 <mdawkins> you mean add cooker as a recipient?
20:04:53 <proyvind> sounds like something that's already quite easy enough to implement and automize, without any manual work required by anyone to post it to cooker list
20:04:59 <proyvind> mdawkins: yeah
20:05:16 <itchka> I can see little point in that since everyone is notified anyway but then again I don't see any reason why not.
20:05:46 <proyvind> yeah... "everyone"..
20:05:51 <mdawkins> itchka: only ppl on the recipient list are notified, not all of cooker
20:06:08 <mdawkins> itchka: or am I wrong?
20:06:25 <mdawkins> Loomio recipient list != cooker ML
20:06:34 <proyvind> public disclosure of stuff being voted on should be motivation enough alone..
20:06:35 <itchka> Yes that is correct as far as I'm aware.
20:06:43 <mdawkins> Loomio Recipient List < Cooker ML no?
20:07:02 <OnlyHuman> I vote for chwido as next president
20:07:17 <mdawkins> OnlyHuman: that's not helpful
20:07:36 <mdawkins> itchka: if we wanna be transparent, that'd be a good start
20:08:32 <itchka> as I said I don't see any reason why Loomio sheouldn't send a mail to cooker-ml.
20:08:54 <mdawkins> oh itchka ok, cool!! who can make this happen then?
20:09:07 <mdawkins> glad we all agree
20:09:45 <itchka> Probalbly infra I will have to enquire.
20:10:10 <mdawkins> cool!
20:10:14 <mdawkins> are we done?
20:10:44 <itchka> There's aob but we are done withe main agenda.
20:11:44 <mdawkins> it seems everyone has checked out....
20:15:19 <itchka> Indeed I doubt if anyone has the energy for AOB but i'll leave it up there for 5 minutes and then close that meeting.
20:15:47 <mdawkins> did we accomplish anything today?
20:15:59 <mdawkins> really i don't remember any decisions being made
20:16:13 <mdawkins> or definite answers to ETA questions
20:17:40 <itchka> mdawkins: It's not always about decisions it's as much about exploration of ideas and issues and I think we have covered plenty of those today.
20:18:46 <mdawkins> itchka: i kinda agree, but no direction was taken afterwards... that's why i'm not sure that is very productive
20:18:46 <crisb> indeed, and we didnt even cover world affairs
20:19:54 <crisb> i think the rpm issue we dont need to make any immediate decisions on because it's not something for 3 anyway
20:20:12 <crisb> and that seemed like it was a looong part of the meeting
20:20:54 <mdawkins> crisb: rpm or the PM?
20:20:54 <itchka> Well let me see. We have so far today explored two ideas which will be passed to the new abf team for consideration. Both ideas could significantly improve it's performance if implemented.
20:21:10 <itchka> Is that not progess?
20:21:20 <crisb> mdawkins: the pm
20:22:21 * mdawkins shrugs
20:22:31 <mdawkins> idk how do you two feel about the PM situ
20:23:02 <crisb> i think we need to take an honest look and then see
20:23:15 <crisb> but then i dont think it's hugely pressing vs other matters
20:23:27 <mdawkins> my personal opinion and this is for me, i'm gonna keep maintaining smart in the BG
20:23:39 <mdawkins> for the distro.... dnf+yumex seems pretty viable
20:24:06 <crisb> then why maintain smart?
20:24:21 <mdawkins> proyvind: if you fork genhdlist2 off to C, that'd be kewl
20:24:52 <mdawkins> crisb: bc afaict, dnf is good for l-users, but smart does better for me for devel
20:25:08 <proyvind> mdawkins: yeah, let's name it genhdlist-ng :o)
20:26:04 <mdawkins> +1 proyvind
20:26:43 <mdawkins> crisb: i'd love to spend a day with most devs and show them how to be utilize smart+rpm and show them why and how i can make certain decisions
20:27:32 <proyvind> well
20:27:40 <proyvind> I gotta go
20:27:51 <proyvind> bye
20:28:30 <mdawkins> c ya
20:28:40 <crisb> well if you can do that maybe it can be of interest
20:28:57 <mdawkins> crisb: i'm not saying for l-users
20:29:02 <mdawkins> i'm saying as a dev tool
20:30:15 <crisb> surely a luser just wants to say smart install <package> or more than likely click on a package in a list and say install
20:30:21 <mdawkins> why are my perl builds all of sudden blocked from being published?
20:30:23 <crisb> surely everything serves that purpose
20:30:51 <crisb> probaby because abf is borked
20:31:08 <mdawkins> nope, this was manually done by TPG
20:32:01 <mdawkins> hmm what is he doing?
20:32:30 <mdawkins> those are older builds that didn't pass tests
20:32:57 <crisb> he's probably done it to stop them being published by accident
20:33:22 <Pharaoh_Atem> mdawkins: is the repograph stuff what you want? because there's a plugin for it in dnf
20:33:47 <mdawkins> Pharaoh_Atem: no, it's part of the gui and your can string things together at the CLI
20:34:30 <itchka> #endmeeting