16:10:53 <itchka> #startmeeting
16:10:53 <chwido> Woof! Let's start the meeting. It's Wed Nov 16 16:10:53 2016 UTC. The chair is itchka. Information about me at https://wiki.openmandriva.org/en/Chwido.
16:10:53 <chwido> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:10:53 <chwido> You should add extra chair(s) just in case, with #chair nick.
16:10:53 <chwido> Have a good meeting, don't bark too much!
16:11:01 <bero|2> chwido is here too, but he's fast asleep... I won't wake him up unless it gets down to really complicated questions only a woof can answer ;)
16:11:53 <OnlyHuman> hi Colin :)
16:12:15 <itchka> I thought Chwido never slept and that he was the embodiement of hyperactivity :)
16:12:41 <OnlyHuman> :)
16:13:03 <OnlyHuman> chwido: bark itchka
16:13:03 * chwido barks at itchka in minor chords.
16:13:29 <bero|2> He got a lot quieter lately
16:15:41 <itchka> :) I'll post the agenda. One moment
16:15:57 <itchka> 1: Deprecation Path i686: Planning; identify steps.
16:15:59 <itchka> 2: Kahinah: Progress toward rolling release
16:16:01 <itchka> 3: Progess on bugfixes for re-spin
16:16:02 <itchka> 4: AoB
16:16:35 <itchka> #item 1
16:16:51 <itchka> #topic Deprecation Path i686: Planning; identify steps
16:17:23 * jbj adds to AOB fyi: http://rpm5.org/community/rpm-users/1102.html
16:19:15 <bero|2> So as far as I'm concerned:
16:19:21 <bero|2> 1. Switch to i686
16:19:24 <itchka> As agreed last week we will switch to i686 as soon as we can find someone to flip the necessary switches. The next step is to plan the retirement  (I don't like the word deprecation) of the ix86 architecture from the distribution.
16:19:58 <bero|2> 2. Think about how ABF can handle building the compat packages we need to keep stuff like wine and steam running without having to support the whole arch
16:20:12 <itchka> The hope is to provide a clear path and timetable for this to happen and what needs to be put in place before it can be acheived.
16:20:44 <bero|2> 3. Make the installer scream at people who install the i686 iso on 64-bit capable hardware (while still allowing it)
16:21:18 <bero|2> 4. Announce at some point (maybe with the 4.0 release?) that i686 is no longer fully supported (as in, we still build stuff, but stuff that fails may not get fixed)
16:21:36 <bero|2> 5. At some point later, drop it except for the compat packages
16:22:08 <bero|2> 6. Start thinking about doing the same for armv7hl as aarch64 takes over
16:22:35 <bero|2> (note 6. shouldn't even be starting yet, armv7hl is still VERY common -- but in the long run it'll very likely go the same way)
16:22:41 <Pharaoh_Atem> it's unlikely to see that happen with armv7hl, simply because of the IoT mess
16:23:12 <bero|2> yes, it'll take a longer time... But I fully expect that
16:23:49 <bero|2> - 5 years (probably less) from now, even the smallest new IoT devices that are arm based will be based on some variant of aarch64 (64-bit Cortex-M or so)
16:23:59 <Pharaoh_Atem> how difficult would it be to enable ABF's multilib repository configuration for x86_64?
16:24:16 <bero|2> - we won't care about super low end boards anyway because they won't have enough RAM and/or storage space
16:24:54 <Pharaoh_Atem> where only 32-bit library packages will get merged into the x86_64 repository, so that both 32-bit and 64-bit repos don't need to be enabled for multilib
16:25:03 <itchka> Ok bero|2 they are certainly the main points but I think the order could be a little different I would see item 3 moved to 2 the sooner we get people used to the idea of using 64bit the quicker we can do the job.
16:25:28 <bero|2> right, makes sense...
16:25:35 <bero|2> The 3.1 installer should start doing the screaming
16:25:46 <bero|2> but 2. can run in parallel
16:26:05 <itchka> Ok I'm good with that..
16:26:09 <bero|2> Pharaoh_Atem: we aren't ignoring you, but chances are nobody here right now can answer that question ;)
16:26:16 * Pharaoh_Atem shrugs
16:26:36 <Pharaoh_Atem> as far as I'm aware, ABF has the code to do it already, since ROSA does it for building their RHEL-derived product
16:26:44 <jbj> Pharaoh_Atem: creating a mixture of 32&64 bit packages is a management mess, particularly if one wishes to deprecate/retire 32 bit packages
16:27:03 <Pharaoh_Atem> jbj: I specifically want only libraries for compat
16:27:13 <jbj> same deal: management mess
16:27:15 <Pharaoh_Atem> the mdv-style packaging helps us here, as the process is a lot simpler
16:28:24 <jbj> you will need to supply more details instead of just blanket claims
16:29:20 <Pharaoh_Atem> well, the idea is that when packages are built for both architectures, if there are library subpackages, those packages for i686 will also be copied into the x86_64 repo upon publish
16:29:40 <itchka> jbj: For those of us who are not so clever what are the pitfalls?
16:30:00 <Pharaoh_Atem> that will allow us to eliminate the dependence of having a full i686 repo for supporting things like wine and other apps that require 32-bit libs
16:30:03 <bero|2> jbj: different package names help (e.g. libfreetype6 vs. lib64freetype6)
16:31:54 <jbj> for better or worse: rpm supplies a single architecture for each build. performing multiple arch (and sub-arch like PAE wrto kernels) leads to a great deal of complexity (like all package lists need to be filtered with attributes every time, every application) solely for the purpose (your claim) of removing an extra “unneeded” repository configuration.
16:32:22 <itchka> Pharaoh_Atem: So we can build the 32bit packages in a 64bit environment?
16:32:32 <Pharaoh_Atem> itchka: sure, but that's not what this is supposed to do
16:32:47 <jbj> bero|2: same argument: appending attributes to names forces filtering everywhere. consider a separate directory
16:32:49 <Pharaoh_Atem> what this is supposed to do is remove the runtime requirement for the full i686 repository to run 32-bit applications
16:33:15 <bero|2> jbj: yes, makes sense to have both different names and different directories
16:33:18 <Pharaoh_Atem> that also would allow us to make the decision to simply not publish the 32-bit repositories
16:33:32 <Pharaoh_Atem> while still retaining compat for 32-bit apps on 64-bit OS
16:33:45 <jbj> so create i686-minimal and i686-full. creating a single steaming pile of packages is a management mess
16:34:47 <jbj> consider the endless discussions about “noarch” duplication … noarch SHOULD be a spearate directory too
16:35:18 <jbj> directory == repository == url path component
16:35:35 <jbj> and better than appebnding attributes to package names
16:35:57 * bero|2 agrees
16:36:06 <bero|2> the current noarch duplication doesn't make sense at all
16:36:19 <bero|2> and just eats up a lot of cpu resources with packages being built 4 times
16:36:32 <itchka> So do we take the opportunity to correct that at the same time?
16:39:16 <bero|2> I hope so...
16:39:31 <bero|2> but ultimately, that's a task for the abf guys
16:39:40 <bero|2> so really can't talk about that without them here
16:40:11 <itchka> So would we just have a noarch repo like we have for the individual arches and the under the x86_64 repo we have a compat32 repo?
16:40:28 <Pharaoh_Atem> I guess so
16:40:55 <itchka> jbj: Does that make sense to you?
16:41:35 <jbj> if you are going to attempt to correct, then I suggest focusing on package lists containing paths/urls instead of attempting The One True Directory Hierarchy for Mirroring. that provides a great deal of flexibility for collecting disparate components without the need for filtering unwanted from on great big steaming pile of packages
16:43:34 <jbj> with lists, one isn’t talking about noarch repositories, but rather collections of packages inteended for some purpose. this easily accomodates Pharaoh_Atem’s desire to include 32&64 bit in one dialect of a collection without forcing every application to filter every time.
16:43:55 <itchka> jcj: You mean use redirection? I don't know enough to see how that would work with mirrors..
16:44:32 <jbj> the collection list generator(s) can/will apply multiple criteria including filtering and depclosure and whatever else is desired
16:45:32 <jbj> personally I’d use flat files: redirection assumes an ability to remap paths and one is right back to a management mess
16:47:01 <jbj> a flat file list can contain multiple urls, and can be structured to have sections with different baseurl’s if one wishes.
16:47:32 <itchka> jbj: So you are talking about what I know as "task" packages which contain lists of files to install?
16:48:00 <jbj> the existing conventions for static hierarchies are due to rsync mirroring from last century
16:48:38 <bero|2> yes, but that's what mirrors still need/use
16:48:47 <jbj> no: I’m talking about abstract lists as a collection, not a “super-package” or “task-package”
16:49:58 <Pharaoh_Atem> you're talking about stuff like metalinks
16:50:01 <Pharaoh_Atem> ?
16:50:33 <Pharaoh_Atem> or like how repomd.xml works (pointing to alternate files for specific entries)?
16:50:35 <jbj> bero|2: I’m not suggesting the existing status quo. I am suggesting moving the focus of toos to flat file lists, not defacto structures. consider all the pain that happens when multiple versions of single package end up being mirrored. teach the tools lists
16:51:12 <jbj> teach the tools to use flat file lists, not implicitly traverse hierarchies
16:52:05 <bero|2> we have to remain realistic here -- we don't control what tools mirrors etc. use/have installed
16:52:12 <bero|2> and we can't be picky about who gets to mirror us
16:52:18 <jbj> metalinks is about redirection. meanwhile its trivial to create metalinks or redirections or whatever web goo one wioshes if the focus is on a collection list
16:53:11 <jbj> meanwhile my comments are in response to itchka’s question “Should we do …” not otherwise
16:54:10 <jbj> bero|2: sure you control what is mirrored: add a list to the mirror
16:57:00 <jbj> and teach the tools to recurse through a list picking up what is needed instead of downloading metadata from a single file. consider the hysterisis in current tools generating metadata in a single file …
16:58:02 <jbj> *shrug* … back to the original comment … combining 32&64 bit packages forces filtering into every application every time
16:59:31 <jbj> and attaching attributes through url components (rather than in package naming) is easier to manage.
17:00:09 <jbj> lists/collections can be used to hide/simplify structure
17:01:49 <Pharaoh_Atem> brb
17:05:35 <itchka> I get the metadata point and it's a consideration even if we structure in the conventional sense just a single noarch repo would be a big improvement and combining ix86 and x86_64 repos would be worse than having separate directories.
17:07:33 <bero|2> itchka: agreed with that
17:10:49 <jbj> truly, all I’m suggesting is to attach attributes like arch to the url, not in package names/contents. adding complexity like multilib (a form of filtering) or arch scoring in rpm was _NOT_ simple and has numerous flaws. it SHOULD have been done by attaching attributs to paths instead
17:14:35 <itchka> That would blow fuses in search engine like rpmfind.
17:16:15 <jbj> itchka: rpmfind is very very ancient history for starter. meanwhile rpmfind can search multiple remote url’s to find packages last I checked
17:17:01 <itchka> Let me get this clear jbj what you are suggesting is that all packages have a single name. There is no arch component. The arch component is identified by the url that points to the directory containing that arch?
17:18:40 <jbj> no: I am suggesting that slopping 32&64 bit packages into a single directory/repository is a managemenht mess. the positive alternative is to insert “32bit” or “64bit” into the retrieval path. no other change is needed
17:20:53 <jbj> I would also split “noarch” into its own directory/repository if you choose to handle 32bit/64bit in their own directory/repository
17:21:02 <itchka> Ok thanks for the clarification
17:24:57 <itchka> That's pretty much the conclusion I came to. There is another thing that is very much against have a combined directory as while we are in the transition phase there is the potential for ix86 and a combined ix86/x86_64 bit repos to get out of sync with each other and ythis seem like bad news to me.
17:26:14 <bero|2> yes -- essentially what we have right now isn't so bad except noarch should be treated correctly
17:26:28 <bero|2> of course it isn't optimal, but it's "good enough" and the currently existing tools can deal with it
17:26:58 <jbj> historically, there were 2 approaches to multilib: RedHat chose to slop everything into a single directory, SuSE chose 3 releases: ix86-only, x86_64-only, and both ix86/x86_64
17:27:31 <jbj> the SuSE product is/was easier to understand and manage than RHEL5
17:28:18 <jbj> the same issues apply to i586 -> i686 and arm7hl -> aarch64 standalone or mixed
17:31:32 <bero|2> agreed
17:33:53 <itchka> Ok so we need to decide what should happen when ix86 is fully retired. Do we 1: Keep the existing structure or 2: Create a compat32 repo within the x86_64 repo
17:34:26 <bero|2> I'd say 1. -- keep them separate to make handling easier
17:34:49 <bero|2> also makes it easier for people who for whatever reason want to keep updating ix86 installations after we officially drop support
17:34:54 <itchka> Ok probably best..less code changes in abd too.
17:35:00 <itchka> abd=abf
17:36:14 <bero|2> and in all the updating tools
17:36:28 <itchka> I think we need to get this done asap the noarch must be wasting very large amounts of machine cycles for no benefit whatever.
17:38:30 <bero|2> and space on the server and mirrors
17:39:03 <itchka> Creating a noarch repo will require users to update their urpmi.cfg how would we manage this?
17:39:15 <jbj> itchka: noarch wastes few machine cycles imho. most noarch packages are standalone: change your “build everything” procedures to add “noarch” to *.src.rpm paths
17:39:37 <bero|2> itchka: %post script
17:39:54 <jbj> noarch subpackages, and faux-noarch like java, need to be handled differently.
17:40:53 <jbj> noarch subpkgs are usually documentation, which needs to handled very differently, like structuring a web site and preparing what is distributed from the web site, not from the build
17:41:47 <jbj> and lots of java is implicitly per-arch: e.g. you can’t run both 32&64 bit in the same JVM last I checked.
17:42:54 <jbj> then there is localization as “noarch” … again needs to be handled very differently than current “noarch” bloat with a hidden attribute that affects what is actually installed.
17:44:13 <jbj> itchka: re urpmi.cfg … who is expected to manage urpmi.cfg: users or OMA? answer that question and you will know what to do
17:46:23 <jbj> if the answer is “both”, then split urpmi.cfg into 2 pieces, load the OMA portion first, and permit user overrides of OMA specified configuration. the split clarifies wheich entity is responsible for the configuration
17:47:40 <bero|2> true, makes sense
17:48:13 <bero|2> I don't expect users to modify urpmi.cfg and friends a lot (except to indicate whether or not they want to receive non-free/restricted packages)
17:48:22 <bero|2> but they must have a place to add e.g. their personal abf spaces
17:51:32 <jbj> bero|2: looking fwd …. git forces per-package git repositoiries. one can add distribution membership tags to spec files (with appropriate default inheiritance to boot strap the mess) to *.spec to start self assembling git repositories -> ABF -> distro repositories
17:52:29 <bero|2> right
17:53:34 <jbj> already arch can be included into paths that rpm writes (if ABF and distro tools are preapared for another directory level in globs etc)
17:55:59 <jbj> I suspect that %PLATFORM can be added as Yet Another Attached Attribute through existing rpm configuration too. please: a hierarchy, not some more-gook-appednded-to-directory-paths-because-everything-ends-up-the-same-pot-anyways-simplicity.
17:56:24 <jbj> think through your hierarchy for whatever efficiencies one wants carefully
18:00:41 <Pharaoh_Atem> back
18:03:38 <itchka> We need a "what needs doing" document for this as it's not as simple as first appears.
18:04:27 <jbj> itchka: is a path forward, avoiding mixing 32&64&noarch&distepoch into a single directory/repository clear?
18:05:58 <itchka> Yes to me that seems by far the best way to go.
18:06:34 <jbj> instead create a hierarchy with leaf nodes being “pure” in the sense of “all 32bit”
18:06:41 <jbj> good
18:09:18 <itchka> jbj: I'm still struggling in the head a bit with the noarch subpackages I can't quite see how these will end up in the noarch repo or indeed whether they should.
18:11:31 <jbj> itchka: rpm (default config usually ovverridden by tools) traditionally writes to /usr/src/rpm/RPMS/%ARCH/foo*.rpm when building
18:12:45 <itchka> jbj: Ok I gedditt!!
18:13:11 <jbj> tools typically want all produced *.rpm in one directory, and then copy based on filtering of some sort (like *.%ARCH.rpm globs)
18:14:45 <jbj> this naive simplicity propagates all the way through to the installer that is expected to deal with multiple versions of same packge, and —excludeddocs and multilib etc. which rpm does, but its voo-doo complexity that cannot possibly please everybody
18:18:37 <itchka> Thinking aloud here should the noarch repo should have sub-repos like man pages, internationalisation, java32 and java64 ?
18:20:23 <Pharaoh_Atem> uhh
18:20:28 <Pharaoh_Atem> why would java be noarch?
18:20:34 <jbj> itchka: think trough your hierarchy carefully … meanwhile every Mewer! Better! Bestest! change to package internals requiring filtering invariably leads to RPM (and urpmi and dnf and …) SHOULD DO ….
18:20:41 <jbj> through
18:21:40 <jbj> Pharaoh_Atem: because java byte code was actively marketed as being universal and jpackage.org was sompolicit in Sunacle marketing
18:21:55 <jbj> complicit
18:21:56 <Pharaoh_Atem> oh, right, I forgot about that
18:22:20 <Pharaoh_Atem> it's been way too long since I've dealt with the leftovers from jpackage.org mess
18:24:30 <jbj> it would be rather easy to add a distingusished “java_faux_noarch” to rpm except it leads to aliasing confusion. meanwhile arch is a stoopid attribute to split packages on, even GNU uses CPU-VENDOR-OS-GNU (i.e. 4 attributes, not one) by design
18:25:33 <jbj> too bad that “linux” chose to honk its warez without version like every other OS on the planet. in fact, “linux” == “kernel”, not OS
18:28:27 <jbj> the attribute name space needs to be +/- SSE2, not {i586.i686} etc. look at ARM CPU attributes. its kinda silly to do aarch64 <-> armv7hl when {32,64} are the primary attributes.
18:30:00 <itchka> We have got a bit off the point here though it's certainly been a worthwhile discussion and the noarch thing certainly needs doing even though it's not essential for the i686 retirement plan. As far as I can see we have ended up with the result that we keep the existing repositories during and after retirement.
18:31:29 <itchka> Though there may be some streamlining of the ix86 repo once retirement is done.
18:32:46 <jbj> itchka: depends on what “existing” means. sure existing url patsh have usefully managed attributes in path like {i586,i686,x86_64,updates,testing,cooker,etc} there is no need to eliminate what is known to work.
18:34:07 <jbj> but isolating i586 (and i686,x86_64} into “pure” (i.e. all packages have the same attribute echoed into URL) is necessary to manage end-of-life cleanly
18:36:18 <jbj> the simplity comes from using different URL’s … the complexity comes from having to filter the big steaming pile of packagfes repeatedly everywhere every time.
18:39:58 <itchka> Filtering is implicit in package selection, it cannot be avoided all that can be done is to ensure that the data structure is such that it is fast and easy to traverse or is that an oversimplification?
18:40:52 <jbj> filtering != selection … filtering is assumed to be globally configurable and automatic. selction is conscious intent
18:42:05 <jbj> choosing based on paths is preferred to that based on package naming. patsh are far easier to change than rpm file naming conventions
18:43:22 <itchka> makes sense
18:46:32 <itchka> The only issue I see here referring to the "pure" aspect of the ix86 repo is that we will if we flip the switch to i686 have bothe i586 and i686 packages in the same repo but I'm not entirely sure whether the package names will reflect this.
18:47:56 <itchka> If they don't then I'm not sure of the implications of this.
18:48:28 <jbj> this wandering thread started with a request to add “compat32” library packages to existing x86_64 repositories to avoid an extra line of configuration.
18:49:21 <jbj> if you do add “compat32” to x86_64, then you continue to follow the RHEL5 ratrher than the SuSE model.
18:50:22 <itchka> I was not suggesting adding compat32
18:50:52 <jbj> all works, your choice(s). but policies like “I want urpmi to remove all i586 packages.” will surely show up as bugs.
18:53:06 <jbj> yes removal will need custom tools … but “I wish to prevent all updates of retired i586 packages.” are rather easily selected by deleting repsotories with “i586” in path. which is harder with filtering on names/attributes in the x86_64 repository
18:55:32 <jbj> note that cross-arch Obsoletes: (as currently implemented) has no well defined semantic, and its entirely unclear how to add a usefully workable policy or configuration.
18:58:33 <itchka> Ok noted.
19:01:15 <itchka> If it's ok with everyone I think we need to end this agenda item for this week. I will use beros 6 points as at the basis for the agendas for the coming weeks and add any additional ones that come out of the discussions.
19:01:31 <jbj> sorry to hijack your meeting … meanwhile, there is active interest in a dnf port with yocto here: http://rpm5.org/community/rpm-users/1102.html
19:02:11 <jbj> I gotta go do Wndows10 & AVR consulting to make $$$. I’d much rather be doing linux packaging
19:03:48 <itchka> Ok Jeff tahnks for your input.
19:04:49 <itchka> Ok lets move on
19:04:58 <itchka> #item 2
19:05:58 <itchka> #topic Kahinah progress towards rolling release
19:06:56 <itchka> Ok not much to say here I've not seen a review from avokhmin yet so I guess he has been too busy.
19:07:20 <jbj> git status
19:08:26 <itchka> The good news is though is that Xu[m] has implemented the change to GitHub authentication and apart from a small glitch which will be fixed tonight it works fine.
19:15:39 <HisShadow> jbj: fatal: Not a git repository
19:15:56 <itchka> We do need keep this moving but it seems all our abf experts are busy at this time. Not much more to say on this
19:16:22 <itchka> So moving on
19:16:37 <itchka> #item 3
19:17:07 <itchka> #topic Progess on bugfixes for re-spin
19:27:34 <itchka> There has been good progress on bugs; crisb has fixed the grub configuration utility and I have fixed the segfaulting efibootmgr utility. I would also like to set up grub to restore default menu choice option  which was disabled to cure a cosmetic bug when booting with btrfs and f2s filesystems. A patches to f2s filesystems have been applied to grub2 for some time which should address the f2s filesystem.
19:27:35 <itchka> Automatically disabling the SAVEDEFAULT functionality in grub2 when btrfs is chosen as the default bootdisk is relatively straightforward.
19:29:03 <itchka> We still need to address the issue of buttons being off screen with the lower resolution screens used on netbooks.
19:31:55 <itchka> Any ideas for a way forward on this issue would be welcomed. It seems that Calamares uses a fixed window size and it's this that's part of the problem at install
19:33:08 <itchka> christann: Has TPG fixed the Plasma menu config yet?
19:34:34 <christann> I am not sure. I believe that he has, but will try it out soon.
19:35:02 <christann> My new PC is uptodate and working fine.
19:37:00 <itchka> Ok let me know when you are happy and we'll start trying to release the packages from Kahinah. I know TPG is working on kdeapps right now so it won't be long before everything is ready.
19:37:39 <itchka> Hopefully we will be able to respin next week.
19:38:32 <itchka> As always folks please fix bugs.
19:38:59 <itchka> Final Item
19:39:08 <itchka> #item 4
19:39:16 <itchka> #topic AOB
19:40:19 <itchka> I'd like to close the meeting at a quarter to the hour so there's 5 minutes to raise any other items.
19:43:46 <Pharaoh_Atem> jbj: it's awesome to see that there's interest in dnf from Yocto
19:44:15 <Pharaoh_Atem> I'd briefly spoken to one of the Yocto guys last year about it, but I'm glad to see that there's more interest now
19:46:41 <itchka> We should have a topic on dnf at some point I think.
19:48:09 <bero|2> can't hurt
19:49:14 <itchka> Folks I have to feed the family so I'm going to end the meeting now. Thanks to everyone for their contributions. We'll continue the the i686 retirement planning next week so keep your thinking caps on.
19:50:16 <itchka> Pharaoh_Atem: Would you be willing to do a presentation of dnf?
19:51:02 <itchka> give us all a bit of insight into it.
19:57:57 <itchka> #share Item 1: i686 retirment plan. bero gave a 6 points which we will use as an agaenda over the coming weeks. Today we discussed how we would structure the repositories to accomodate the 32 bit compatibility libraries once ix86 has gone. A wide ranging discussion branched out to include the creation of a noarch repository to reduce abf overhead the final decision on repo changes were to introduce a noarch repo
19:57:58 <itchka> and retain the existing 32 bit repository structure to store the 32 bit compatibility libraries.
20:00:45 <itchka> #share Item 2: Kahinah: Progress toward rolling release. The overall design has not yet been reviewed by avokhmin so there was little progress with the implementaion however the kahinah tool has now been updated to use the GitHub authentication structure moving us away from the soon to be defunct Persona.
20:01:53 <itchka> #share Item 3 Progess on bugfixes for re-spin. Some progress has been made but there are stil a few outstanding issues.
20:04:03 <itchka> #share Item 4: AOB. jbj brought the fact that Yocto are showing interest in dnf to our atytention. Pharaoh_Atem was particularly intersted in this. It was thought that we should have this as a topic in the TC at some point.
20:04:12 <itchka> #endmeeting