13:00:32 #startmeeting Workstation WG 13:00:32 Meeting started Mon Jul 6 13:00:32 2015 UTC. The chair is mcatanzaro. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:32 Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:00:38 #meetingname workstation 13:00:38 The meeting name has been set to 'workstation' 13:00:45 #topic Roll call! 13:00:56 * rdieter waves 13:01:31 #chair rdieter mclasen_ 13:01:31 Current chairs: mcatanzaro mclasen_ rdieter 13:03:24 * mclasen_ actually makes it to a meeting for a change 13:03:53 Paul and Kalev said they would not be here today. 13:04:07 We're missing Ryan, Jens, Christian, and Owen. 13:04:11 yay vacation season 13:05:40 Well let's see what we can accomplish today; don't feel like canceling two meetings in a row. 13:05:56 * mclasen_ apologizes retroactively for last week, I was travelling 13:05:59 #topic DisabledRepos and Software Center 13:06:13 mclasen_: Put on your hughsie and kalev hats again. 13:06:34 (Apology accepted; not like you're unique in missing. ;) 13:06:38 https://lists.fedoraproject.org/pipermail/devel/2015-July/211915.html 13:06:58 ^ This question was send to devel@ last week, relating to GNOME Software, and got no response. 13:07:24 thanks for pointing it out, I didn't see it in my mail skim this morning 13:07:41 mclasen_: Do we have an answer already, or is it something we need to discuss? 13:08:10 I know we don't want Coprs replacing core system components, but we haven't defined that well, and I'm pretty sure GNOME Software doesn't enforce that currently. 13:10:08 #chair cschalle 13:10:08 Current chairs: cschalle mcatanzaro mclasen_ rdieter 13:10:46 my answer would be that I don't think we want to be in those situations, really 13:11:13 anyway, let me quickly run over and see if cschalle is now free 13:12:14 So we don't want Coprs with enabled_metadata=1 to contain packages that are already in Fedora? That seems reasonable to me, but it does defeat a use-case of the Copr developers; they might not be thrilled. 13:12:17 I can think of 2 approaches wrt copr's: provide .repo's for only well-known/trusted ones 13:12:49 or ... just allow all of them, but then you have no quality assurance 13:12:50 thats what I thought we want to do - only enable search for handpicked ones 13:13:08 sorry for missing the start, but if we are talking about corps vs core packages, I think we might want GNOME Software in some cases to prefer the copr, as it might be a fix for the main package. We had such a discussion for instance about PiTiVi for this release, where the PiTiVi we ship is broken, but we could get a working one done as a copr 13:13:40 cschalle: Why can't we fix our official build of pitivi? 13:14:11 mcatanzaro, packaging issues, the development was in such a flux that you needed misc git snapshots of a lot of deps etc. 13:14:13 i assume that was just a theoretical example, point being... copr should generally offer an upgrade path from fedora pkgs 13:15:12 in regards to coprs in general I do think we should handpick the ones we want to offer, offering the universe of coprs might be just asking for our users to get low quality/prototype stuff 13:15:25 * mclasen_ puts out the provocative thesis that we shouldn't be shipping a broken pitivi in fedora 13:15:50 cschalle: I agree with mclasen_ on this one. I don't think it's a good idea for installing pitivi to replace random packages provided by Fedora with git snapshots from a copr. I guess it could work if we are very careful about compatibility.... 13:15:55 I'll followup onlist to recommend that copr devs not offer universe of copr .repo's either, for the same reason 13:16:05 mclasen_, agreed, that said I don't think we ever been good at identifying and disabling packages that used to work to some degree and dropping them for a given release 13:16:07 rdieter: Thanks. 13:16:32 mcatanzaro, no replacement, the idea was that the pitivi copr would bundle copies of all these libs 13:16:34 in the pitivi case, breaking out ges as a separate package was simply a mistake... 13:16:58 cschalle: That would be better. 13:17:39 so the idea was to ship a copr bundling all needed libs in the right versions, and then go back to the proper fedora builds once development stabilized 13:19:23 if we do the 'bundling' here properly, it should not interfere with the core os 13:19:38 ie the libraries would be private to the copr build 13:20:05 of course, thats more work for the person maintaining the copr 13:20:54 I've always been hesitant about coprs because I came to Fedora from openSUSE, where their equivalent of coprs (they don't call them coprs of course) are very popular, and there is tons of breakage. There it's normal for users to have 5-10 different coprs installed, some providing newer versions of critical system packages like GNOME packages, others that break the upgrade path because they were not kept up-to-date with openSUSE (co 13:20:56 mparatively) very slow pace of updates.... But I think all of those problems would be avoided if we encourage bundling needed packages. 13:21:02 yeah, so the idea was just for the copr package to replace the core one, but leave all deps untouched 13:21:35 to avoid two pitivis appearing in peoples menu 13:21:45 Our guideline could be: .repo files for coprs should not use enabled_metadata=1 if they replace packages provided by Fedora. How does that sound? 13:22:13 (Then in this specific case, we would retire the Fedora pitivi package in F22, and the copr one would be used automatically.) 13:23:03 sounds good 13:23:09 mcatanzaro: other than leaf packages, maybe ? 13:23:20 it seems we want to allow for the application itself to be replaced ? 13:23:30 in general though I don't think we should offer any coprs that replace a system library, only applications 13:23:39 OK, replacing leaf packages seems fine to me. 13:24:38 I think we should have an exception for system applications, though (the ones that are unremovable in Software). If a copr replaces a system application, it should not have enabled_metadata=1. 13:25:07 pardon my ignorance, what's the formal definition of "system application"? 13:25:26 mcatanzaro: seems like a nice distinction to make 13:26:20 rdieter: I don't think there is a formal definition, and I am not 100% sure how gnome-software decides what is 13:26:51 rdieter: It is rather arbitrary right now, but it represents the boundary between what we consider the "operating system" and extra applications that just happen to be provided by Fedora. 13:27:02 its meant to cover things that could be considered 'part of the os' as opposed to add-ons 13:27:25 We need to do a better job of defining it 13:27:49 if you want to make some rule/guideline using it, yes, it should be defined better :) 13:28:40 but I agree with the general idea 13:28:51 https://git.gnome.org/browse/gnome-software/tree/data/modulesets/system.xml <-- there is the "definition" 13:29:20 Except, in Fedora we replace Epiphany with Firefox. 13:29:51 Well, there are a couple more changes in Fedora: http://pkgs.fedoraproject.org/cgit/gnome-software.git/tree/gnome-software-system-apps.patch 13:30:45 thx 13:31:18 #idea We need a better definition for the set of software that is considered System Applications by GNOME Software. 13:32:46 mcatanzaro: those other changes ought to be upstream (removing dictionary and gnome-system-log) 13:33:34 #proposal Any .repo files for Coprs that are installed by default in Fedora Workstation with enabled_metadata=1 should not point to Coprs that contain packages provided by Fedora, unless that repository contains only a single leaf package. 13:34:12 why the "single" there? 13:34:12 I guess that is not a real meetbot command; whatever. 13:34:28 I'd be ok with a single repo having multiple leaf pkgs 13:35:16 maybe the ideal is one-copr-per-app, not sure we need to enforce that 13:35:51 #idea Any .repo files for Coprs that are installed by default in Fedora Workstation with enabled_metadata=1 should not point to Coprs that contain packages provided by Fedora, unless that repository contains only leaf packages. 13:35:51 and I thought it would be ok to replace applications 13:36:44 but if you want to start small, your proposal is a good first step 13:36:59 Well I think this proposal would allow replacing applications, since applications should be leaf packages. 13:37:33 ok, I think I was misreading it 13:37:40 Although our packaging guidelines don't currently require it, GNOME Software already does (otherwise you get applications appearing from nowhere, like this stupid Links browser I didn't install and can't remove). 13:37:40 +1 to proposal 13:38:05 I think ideally we want the 1 repo to 1 app setup as it makes it easier to add/remove stuff without side effects ie. dropping the copr for app A, and losing app B as a consequence 13:38:15 +1 from me too 13:39:25 I think mclasen is +1 to this too ;) 13:39:32 yes 13:39:37 #agreed Any .repo files for Coprs that are installed by default in Fedora Workstation with enabled_metadata=1 should not point to Coprs that contain packages provided by Fedora, unless that repository contains only leaf packages. 13:40:23 Ready to move on to xdg-app? 13:40:39 #topic How will Workstation use xdg-app? 13:41:21 Relevant WIP plans for a proposal from Environments and Stacks: https://fedoraproject.org/wiki/Env_and_Stacks/Projects/PackageReviewProcessRedesign 13:45:29 The Aleph proposal would allow us to say, for instance, that applications can be allowed into lower alephs without meeting our packaging guidelines, but only if they are sandboxed xdg-apps. 13:45:40 looks like xdg-app would fix into their 4th or 5th tier 13:47:42 * mclasen_ cringes at the aleph terminology 13:48:30 I'm not sure what "aleph" is referring to. It must mean "tier" I guess. 13:48:48 aleph as in cardinal arithmetic 13:49:19 aleph_0 is the first infinite cardinal, aleph_1 is the second 13:49:36 aleph_1 = 2^aleph_0 is the continuum hypothesis 13:50:00 its a 'game of words' on the fedora logo resembling 13:50:04 \infty 13:50:24 * mcatanzaro has not been exposed to cardinal arithmetic before. 13:50:39 * mclasen_ spent 10 years of his life in a math department 13:52:00 neat, hopefully the terminology won't confuse people... though I would've prefered simpler terms like tier or rings 13:53:31 Anyway, Alex has a working Fedora runtime for xdg-app. The question is, what if anything do we do with it. I guess the intent behind that was to allow us to start shipping Fedora applications as xdg-apps? 13:53:50 anyway, apps shipped via xdg-app are not rpms, so it really only fits into tier 4 and 5, according to that classification 13:54:39 mclasen_, or maybe they would be acceptable since their built from rpms? 13:55:01 But you can ship an xdg-app via RPM, right? (I thought Alex was working on that too?) We wouldn't expect upstreams to use RPMs to distribute xdg-apps, but we could do so ourselves for our own packages. (Not suggesting we should.) 13:55:35 We'll have to come back to this at the next meeting, since we're running out of time. 13:56:55 rdieter, you volunteered to follow up with the devel@ thread on enabled_metadata, right? 13:57:11 mcatanzaro: yes 13:57:34 #action rdieter to respond to devel@ thread regarding enabled_metadata for coprs. 13:57:43 mcatanzaro: we haven't really pursured that, but at the end of the day an xdg-app installed app is just a bunch of content at a certain place in the file system 13:57:53 so yes, you could ship that in an rpm 13:58:10 OK 13:58:58 I am going to endmeeting, unless someone has anything else to say? 13:59:23 * mclasen_ waves goodbye 13:59:48 OK, thanks folks. 13:59:50 #endmeeting